PLG와 SLG 사이, B2B SaaS 프로덕트 디자이너의 역할 찾기
지난 글에서 이야기했듯, 처음에는 세일즈 주도 성장(SLG) 방식에 다소 거리감을 느꼈지만, 점차 그 필요성과 작동 원리를 이해하게 되었습니다. 하지만 그 이해가 곧 혼란을 해소해주진 않았습니다. SLG 환경에서 할 수 있는 역할에 제한이 있다고 느껴졌거든요.
새로운 기능을 출시한다고 가정해 볼게요. 우리가 알고 있는 UX 디자인의 정석적인 프로세스는 다음과 같습니다.
사용자 리서치 및 인터뷰 → 문제 정의 → 솔루션 도출 → 사용성 테스트 → 개선 → 반복
하지만 SLG 환경에서는 이 과정을 온전히 따라가기 어렵거나, 축약되거나 변형된 형태로 작동하는 경우가 많습니다. 그렇게 정석에서 하나둘 벗어나기 시작하면, 디자이너로서는 어느 순간 세일즈의 요구사항을 디자인에 반영하는 일만 하고 있다는 생각이 들기도 합니다. 사용자의 맥락과 문제를 더 깊이 이해하는 데서 출발하고 싶었는데, 실제로는 “이거 필요하대요, 넣어주세요”라는 말로 기획이 시작되는 것만 같은 거죠.
저도 똑같이 느낀 적이 있습니다. 사용자는 점점 더 멀게 느껴지고, 제품 팀에서 문제를 정의하기도 전에 세일즈에서 솔루션이 내려오는 것 같은 느낌을 받았습니다. 디자이너의 역할은 문제를 해결하는 건데, 정작 문제를 보기도 전에 답이 나와있는 느낌이랄까요.
비즈니스 관점에서 SLG가 필요한 건 이해했지만 이런 문제로 실무에서 디자이너가 할 수 있는 액션이 제한된다고 생각했어요. 그리고 지난 글에서 언급한 ‘디자이너의 소외감'을 강하게 느끼게 되었어요.
돌이켜보면 (다른 여러 이유도 있었지만) 이건 SLG 환경 자체의 문제라기보다 그 안에서 디자이너로서의 역할을 어떻게 재정의해야 하는지를 몰랐던 저의 혼란에서 비롯된 것이기도 했습니다.
제약과 단점만 생각하며 내가 하고 싶은 일을 가로막는 구조라고만 생각했죠. 문제와 현실은 인식했지만, 어떻게 대응해야 할지, 어떤 방식으로 풀어나가야 할지를 몰랐던 상태였어요. 그래서 이런 생각이 계속 머릿속을 맴돌았습니다.
“비즈니스가 세일즈 주도로 가는 게 전략적으로 맞다는 건 알겠어. 근데, 그래서 프로덕트 디자이너로서 나는 뭘 할 수 있지?”
“내가 만들고 싶은 경험과 UX 디자인 프로세스가 이런 방식에서 불가능한 걸까?”
우선 제가 SLG 환경에서 경험한 프로덕트 디자이너의 역할을 축소시키는 몇 가지 어려움에 대해 이야기해 볼게요.
1. 세일즈가 문제를 대신 해결한다
고객이 제품 사용 중 혼란을 겪더라도, 그 문제가 디자이너에게 UX 개선의 기회로 이어지지 않을 수 있습니다. SLG에선 고객사의 요구가 제품 요구사항의 출발점이 됩니다. 이 구조에선 세일즈팀이 이미 고객과의 접점을 선점하고 있죠. 따라서 세일즈 팀이 바로 고객의 문제를 듣고, 가능하면 설명으로 해결하거나, 그렇지 않으면 기능 요청으로 이어지는 흐름이 자연스럽게 자리 잡게 됩니다.
결국 디자이너가 문제에 개입하기도 전에 '이미 해결된 것처럼 보이는 상황'을 마주하게 되고, 더 깊이 파고들 기회를 놓치기 쉽습니다.
예를 들어, 플로우나 정책이 사용자가 이해하기 어려운 경우, 디자이너가 더 쉽고 명확하게 개선할 가능성이 있음에도 불구하고, 세일즈나 CS가 "이건 이렇게 쓰시면 돼요"라고 설명으로 문제를 해결해 버리는 일이 종종 발생합니다. 겉으로는 해결된 것처럼 보이지만, 실상은 ‘불편한 서비스를 불편하게 사용하는 방법’을 알려준 것에 가깝습니다. 이런 대처가 반복되면 누적된 불편이 어느 순간 제품 전체의 경험을 망칠 수도 있습니다.
더 큰 문제는, 이 과정이 디자이너에게 전달되지 않아 문제의 존재 자체를 알지 못하게 되는 구조입니다. 사용자 목소리가 제품 개발팀에게까지 닿지 않는 구조 속에서 디자이너는 개선 아이디어를 낼 기회조차 잃게 됩니다.
결과적으로, 사용자 경험을 개선하고 문제를 해결해야 하는 디자이너의 역할은 흐려지고, '디자이너로서 내가 어떤 가치를 만들고 있는가'에 대한 회의감이 커질 수밖에 없습니다.
2. ‘문제’가 아닌 ‘기능 리스트’로 전달되는 요구사항
세일즈팀은 고객의 니즈를 종종 ‘이런 기능이 필요해요’라는 형태로 전달합니다. 고객과 직접 맞닿아 있는 만큼 빠르게 피드백을 수렴해 전달하는 과정은 자연스러운 일이죠. 그런데 그 기능이 왜 필요한지, 어떤 맥락이 있는지, 어떤 사용자에게 발생한 문제인지에 대한 설명은 생략되기 쉽습니다.
이렇게 되면 디자이너는 문제를 정의하고 해결하는 역할보다, 명세된 기능을 단순히 시각화하는 역할에 머물게 되는 경우가 생깁니다.
저는 이런 것들이 디자이너를 점점 더 수동적인 위치에 두고, 단순히 화면을 그리는 사람처럼 느껴지게 만들 수 있다고 생각했어요. 무엇보다 기능의 목적과 근거가 아쉬운 채 작업하게 되면, 결과에 대해 스스로 납득하기 어려운 순간들이 찾아옵니다. 자연히 성취감도 떨어지고, '문제를 해결하는 사람'이라는 정체성도 희미해지는 것이죠.
3. 사용성 개선보단 수익성과 직결된 기능이 우선되기 쉽다
SLG 환경에서는 고객 요청이 곧 계약과 직결되다 보니, 제품개발팀의 리소스가 수익성이 명확한 요구사항에 집중됩니다. 반대로, 전반적인 사용성 개선이나 UX 과제는 ‘하면 좋지만 당장은 급하지 않은’ 일로 분류되어 후순위로 미뤄질 수 있습니다. (특히 리소스가 제한적인 상황에서는 이런 경향이 더 뚜렷하게 나타날 수밖에 없는 것 같아요)
물론 비즈니스 성장을 위해 우선순위를 조정하는 것은 당연하고 필요한 일입니다. 다만 디자이너 입장에서는 제품의 완성도와 사용자 경험을 함께 고민하고 싶어도 그런 기회를 충분히 확보하기 어려운 순간들이 생기게 되는 것이죠.
결과적으로 디자이너가 주도적으로 사용성 개선을 탐색하거나, UX 관점에서 문제 해결 역량을 확장할 수 있는 여지가 줄어들 수 있습니다. 이는 성취감이나 직무 성장의 기회도 제한할 수 있다고 생각해요.
4. 좋은 제품의 정의가 흐려진다
좋은 제품을 만들겠다는 마음으로 시작했지만, SLG 환경에서 점차 다른 판단 기준이 자리 잡는 순간들이 생깁니다. 고객 미팅을 거듭하다 보면, 특정 기능의 유무가 계약 여부에 영향을 주는 상황을 마주하게 되죠. 그러다 보면 "세일즈가 잘 팔 수 있는 제품인가?"라는 관점이 자연스럽게 앞서게 되는 경우도 있습니다.
물론 시장 요구를 반영하고, 필요한 기능을 빠르게 제공하는 것도 훌륭한 제품의 중요한 요소라고 생각해요. 하지만 디자이너 입장에서의 '좋은 제품'은 단순히 계약을 성사시키는 기능 제공을 넘어, 실제 사용자의 문제를 정확히 해결하고, 일관된 경험과 사용성까지 고려된 설계일 때 완성된다고 느끼는 경우가 많습니다.
이런 관점의 간극이 커지면, 제품의 완성도에 대한 자부심이 점점 흐려지는 경험을 하게 되고, 디자이너로서의 정체성이나 성취감에도 영향을 줄 수 있다고 생각해요.
초기에는 직관적인 불편함이 컸습니다. 사실 원인을 명확하게 이해하기 전까지는 ‘내 커리어에 어떤 영향이 있을까?’보다 ‘이렇게 해서 과연 제품에 도움이 될까?’라는 고민이 더 컸던 것 같아요.
하지만 역할을 제대로 수행하고 싶다는 마음에 이것저것 시도해 보면서 깨달았습니다.
반복적인 요청 대응, 맥락이 부족한 요구사항, 근거가 약한 디자인, 그리고 그 모든 과정 속에서도 더 깊이 고민하고 싶다는 제 안의 욕구까지.
주어진 일에 휩쓸리게 되면 내가 해결한 문제나 내가 만든 가치를 명확히 설명하기 어려운 상황이 생길 수 있겠구나 하는 것을요. 그때 이 혼란이 단순한 업무 방식의 문제가 아니라, 프로덕트 디자이너로서의 역할과 방향성을 다시 생각해봐야 할 중요한 신호임을 분명히 인식하게 되었습니다.
결국 제가 느낀 위기감은 디자이너로서의 정체성을 지키고 싶다는 절실함에서 비롯되었다고 생각해요. 단순히 기능을 그리는 사람이 아니라, 문제를 정의하고 해결 방향을 설계하는 사람으로 일하고 싶었거든요. 그게 제가 믿는 프로덕트 디자이너의 역할이고, 스스로 납득할 수 있는 디자인이었습니다.
그래서 현실 안에서 할 수 있는 UX 프로세스를 어떻게든 끌어오려고 노력했어요. 비록 이상적인 흐름을 온전히 적용하긴 어렵더라도, 가능한 한 맥락을 이해하고, 근거를 찾고, 목적을 되짚어보려는 시도를 이어갔어요.
요구사항을 UX 문제로 재해석하기
세일즈팀이나 고객이 “A 기능이 필요해요”라고 했다면 “왜?”라고 묻는 게 중요합니다. 요구사항을 있는 그대로 받아들이기보다 그 아래에 숨겨진 맥락과 UX 문제를 파악하려는 시도가 필요해요. 즉, 기능 요청을 UX 문제로 번역하는 사고 전환을 해 보는 거예요.
예를 들어 세일즈 요청이 “최적화 보고 기능 만들어주세요” 였다면,
디자이너는 이렇게 질문할 수 있어요:
왜 이 기능이 필요한가요?
어떤 사용자가, 어떤 상황에서 이걸 쓰게 되나요?
기존에는 어떤 프로세스로 일을 했나요?
지금 방식에서 불편한 점이 뭐였나요?
이런 질문을 던져서 단순한 기능 요청을 이렇게 재구성할 수 있어요:
“고객의 승인 프로세스를 반영한 최적화 보고 및 승인 흐름이 필요하다”
만약 이 요청을 그대로 받아들였다면 '그 기능에 뭐랑 뭐가 들어가야 한대요?' 정도로 질문했을 것 같아요. 하지만 요구사항을 UX 문제로 재해석하면, 단순한 비즈니스 요청이라고 느껴졌던 것도 리서치 기반의 UX설계 과정의 일부로 전환됩니다. 그 결과, 사용자의 니즈를 고려한 설계가 가능해지고 궁극적으로는 ‘디자이너도 제품 전략에 기여한다’는 인식까지 생길 수 있어요.
비즈니스 팀과 적극적인 소통하기
'근거 있는 디자인'을 하려면 고객 요구의 맥락을 이해하는 것이 가장 중요하더라고요. 그렇기 때문에 세일즈팀, CS팀과 더 자주, 더 자발적으로 이야기하려고 노력했어요.
기능 요청이 왔을 때 위에서 언급한 것처럼 여러 가지 질문을 던지면서 단순한 기능 설명을 넘어 고객의 실제 상황과 언어를 이해하려는 자세를 유지했습니다. 이런 태도는 단지 디자인 완성도를 높이는 데 그치지 않고, 제안의 신뢰도를 높이고 팀 내에서 디자이너가 소외되지 않도록 중심에 서는 데 중요한 역할을 한다고 생각해요.
그리고 저는 디자이너가 문제를 들여다보기도 전에 종결이 된 것처럼 보이는 것이 가장 힘들었어요. 그래서 특히나 많이 노력한 부분이 '프로덕트 디자이너니까 안 돼'라는 선을 스스로 긋지 않는 것이었습니다. 가능한 한 고객 피드백을 직접 들을 수 있는 구조를 마들고, 고객 미팅이 생기면 "저도 참여할게요", "제가 들어가도 될까요"라고 먼저 말하면서 적극적으로 자리를 만들었어요.
실제로 고객 이야기를 직접 들었을 때, 문서로는 알 수 없었던 뉘앙스, 우선순위, 맥락 등 더 구체적이고 생생한 정보를 얻을 수 있었습니다. 그 경험 덕분에 어떤 기능을 개발하기 시작할 때 '무엇을 어떻게 설계해야 할지' 흐릿한 시기를 짧게 줄일 수 있었고 뚜렷한 방향성으로 바뀌는 경험도 자주 하게 되었어요.
디자이너가 사용자 경험을 설계하는 사람이라면, 사용자에 가장 가까운 사람들과의 소통에 더 적극적으로 다가가야 한다는 걸 이 과정을 통해 확신하게 됐어요. 그리고 문제를 먼저 해결해 버리는 세일즈팀!이라는 생각에서 사용자 경험 설계의 든든한 파트너로 생각도 바뀌었습니다.
디자인 설득은 비즈니스 언어로
B2B 제품을 SLG 환경에서 만들면서 특히 중요하게 느낀 건, 디자인 개선의 목적에 비즈니스 효과도 함께 담아야 한다는 점이에요.
디자이너 입장에서 '더 나은 UX'를 만드는 일은 최우선순위의 일이고 당연한 일이지만, 비즈니스 관점에서 보면 모든 개선은 리소스와 비용이 드는 일이더라고요. 그래서 단순히 "이걸 개선하면 UX가 좋아집니다"라고 말하는 것만으로는 충분하지 않다는 걸 많이 느꼈어요.
"왜 지금 이걸 해야 하는가?", "이 개선이 어떤 비즈니스 효과로 이어지는가?" 이 질문에 답할 수 있어야 설득력이 생기더라고요.
그래서 점점 더 이런 식으로 말하려고 노력했어요:
“이 기능을 개선하면 고객 이탈률을 줄이고, 마이크로 전환 목표를 더 효과적으로 달성할 수 있어요.”
UX 개선을 '사용자 만족'만으로 설명하는 게 아니라, 그 만족이 어떻게 비즈니스에 영향을 줄 수 있는지를 연결해 설계하고 설명하는 거죠.
이런 연결 고리를 만들어가는 일은 비즈니스 팀과의 협업에도 도움이 되고, 디자이너가 전략적 기여자로 인식되는 데에도 큰 역할을 했습니다. 저는 비즈니스 언어로 말하고 설득할 줄 아는 디자이너가 되는 것, 그것도 문제 해결자로서의 중요한 역량 중 하나라고 생각해요.
돌이켜보면, 제가 느꼈던 위기감은 단순히 환경의 문제가 아니라 '내가 어떤 디자이너로 일하고 싶은가'에 대한 질문에서 비롯된 것이었던 것 같아요. 단순히 요청을 받아 화면을 예쁘게 구현하는 것이 아니라(아마 프로덕트 디자이너들이 가장 좋아하지 않는 프로덕트 디자이너에 대한 묘사 아닐까요?), 문제를 정의하고 더 나은 방법과 방향을 제안하는 사람, 그게 제가 생각하는 디자이너의 역할이었기에 처음에는 SLG 환경에서 디자이너의 역할이 제한적으로 느껴졌고 그에 대한 고민도 더욱 크게 다가왔던 것 같습니다.
하지만 그 환경에서도 스스로 역할을 재정의하고, 조직 내에 UX 중심 사고를 자연스럽게 끌어오기 위한 방법들을 하나씩 실천해 보며 조금씩 균형을 찾아갈 수 있었어요. 모든 프로세스를 바라는 대로 바꿀 수는 없었지만, 주어진 조건에서 내가 납득할 수 있는 방식으로 일하고 있다는 감각이 들었을 때, 비로소 디자이너로서의 중심을 되찾을 수 있었습니다.
이번 1, 2 편의 글은 B2B SaaS Maker's Gathering 행사에서 얻은 인사이트를 계기로, 그동안 마음속의 고민들을 정리할 수 있는 기회가 되었습니다. 역시 다른 분들의 이야기를 듣고 서로의 시선을 나누는 건 큰 자극이 되는 것 같아요.
며칠 후에는 Figma의 Maker Collective: Seoul에 참석할 예정인데요, 또 어떤 인사이틀 얻게 될지 기대가 됩니다. 기회가 된다면 그 이야기도 나눠보겠습니다.