IT기업들의 영원한 딜레마 - SaaS개발 or 매출?
SaaS 조직의 개발과 비즈니스, 서로 다른 관점에서 본 우선순위
개발과 비즈니스 조직은 왜 이렇게 자주 부딪힐까?
B2B SaaS 업계에서 일하다 보면 유독 개발팀과 비즈니스팀(세일즈·마케팅)이 자주 충돌하는 걸 목격하게 돼요. 처음 마케터로 일할 때는‘왜 이렇게 티격태격할까? 우리 회사만 그런 건가?’ 하고 의아해 했죠. 그런데 여러 회사를 만나보고, 동종업계 사람들과 얘기해보니 다들 비슷한 ‘갈등 포인트’가 있더라고요.
[참고] (브런치 북 12화 : SaaS 기업의 마케팅과 세일즈팀의 관계가 어색한 이유)
가장 큰 이유는 각 팀의 우선순위가 다르다는 데 있어요. 개발팀은 '올해 로드맵에 잡힌 신규 기능 A, B, C를 일정에 맞춰 완성도 높게 구현하자!'라는 목표가 뚜렷해요. 반면 비즈니스팀은 '지금 발등에 불이 떨어진 고객 요청부터 처리해서 매출을 만들어야 한다!'는 목표가 최우선이죠. 둘 다 회사 성장에는 중요한 목표지만, ‘언제, 어떻게’ 우선순위를 두느냐가 달라서 격돌이 일어납니다.
IT 기업의 마케터로 일해오면서 이 갈등의 양쪽을 모두 지켜봐 왔는데요. 서로가 회사 전체를 위한다는 마음은 똑같지만, ‘제품 완성도’와 ‘즉각적인 매출 확보’라는 서로 다른 길을 향해 달리고 있어 이들 중 하나가 목표를 멈추지 않고서는 부딪칠 수밖에 없다는 걸 알게 됐습니다.
개발의 마음: “우린 로드맵이 있고, 단계별 고도화가 중요해요!”
제가 비즈니스조직 소속이다 보니 편향적인 글쓰기를 지양하기 위해.. 먼저 개발의 입장에서 이야기 해볼게요.
우리는 1분기에 기능 A, 2분기에 기능 B를 만들기로 로드맵을 다 세워놨어요.
그런데 갑자기 영업에서 ‘이번에 큰 고객사가 이 기능을 원하니 즉시 개발이 필요하다’고 연락이 오면, 기존 스케줄이 전부 꼬여요.
그리고 로드맵이 자꾸 바뀌다 보면, ‘우리가 원래 가고자 했던 방향이 맞나?’ 싶어 개발자들 동기부여도 떨어집니다.
개발자분들을 만나보면 본인들이 이미 머릿속에 그려놓은 ‘개발 청사진’이 있어요. 이런 순서대로 작업을 해야 효율이 오르고, 코드 안정성도 높아진다 라는 나름의 원칙이 존재하거든요. 그런데 외부(비즈니스 조직)에서 갑작스럽게 요구사항이 들어오면 그걸 받아줄 수는 있지만 일이 계속 끊기고, 코드 구현 맥락이 바뀌고, 심지어 우선순위가 한밤중에 바뀌기도 하니 스트레스가 쌓이는 거죠.
게다가 기존 로드맵이 자꾸 무너지면 어떤 일을 먼저 해야 할지 헷갈려서 생산성이 떨어지기도 해요. 비즈니스팀은 '이거 하나만 빨리 해달라'며 부탁하지만, 개발팀은 '아니, 그것만 하는 게 아니라 다른 것도 줄줄이 우선순위가 달라지거든요'하고 답답해합니다. 서로의 업무 방식이 다르다 보니 입장을 이해하는 것부터가 난관이죠.
세일즈, 마케팅, CS의 마음: “지금 고객이 불만이라는데, 이거보다 중요한게 어딨어요? 이탈하면요?”
비즈니스팀이 계속 ‘긴급 요청’을 넣는 이유는 대부분 다음과 같아요.
고객이 계속 요구하는 걸 무시하면, 매출을 놓치는 건 물론이거니와, 고객사의 불만이 커져요.
당장 응대하지 않으면, 다른 솔루션으로 갈아타겠다는 말이 나와요. 그럼 회사 매출이 타격받아요.
개발팀이 얼마나 힘든지 알지만, 고객 이슈는 미룰 수가 없죠. 지금이 승부처예요.
특히, 비즈니스조직 중에서도 세일즈는 소프트웨어 영업 최전선에서 매일 ‘오늘 계약할까, 말까’라는 긴장 상태에 놓여 있어요. 고객이 요구하는 기능이 우리 SaaS 소프트웨어의 핵심이 될 수도 있고 사소한 문제가 계약 성패를 좌우하기도 하죠. 그러니 '로드맵에 없으니 힘들다'라는 말을 듣고도 어쩔 수 없이 '그래도 이거 빨리 만들어줘야 지금 거래가 가능하겠다'라고 재촉할 수밖에 없어요.
저도 마케팅 업무를 하다 보면, 유료 고객전환으로 이어지기 위핸 온보딩 프로세스 기획을 할 때가 있는데 이때마다 개발팀에 기능 개발을 전달해야 할 때가 많았어요.
[참고](브런치북 13화 : SaaS 제품 투어(온보딩)기획에 마케터 참여는 필수!)
'우리 제품은 가입 이후 유저 온보딩 절차가 미흡해서, 사용자 경험 입장에서 불친절하다. 유료 전환을 유도하려면 이 프로세스가 필요한데 개발 가능할까요?'와 같은 경우죠. 물론, 전달할 때마다 개발에서는 그리 반기지 않는 소식이었던 것 같아요. 사실, 이미 제품이 잘 돌아가고 정기적으로 가입자도 생기고 있는데 다른 개발 우선순위 제쳐두고 실행할 사안은 아니거든요.
마케터로서 보고 느낀 갈등의 현장
제가 마케터로 일하면서 가장 많이 느낀 건 두 팀이 사실 서로의 어려움을 알 기회가 적다는 점이에요. 모르려 하기보다는 알 기회가 별로 없달까?
개발팀은 하루 종일 코드와 씨름하면서 내부 협업 툴, 기술 문서, 버그 트래킹 등으로 바쁘고, 비즈니스는 새로운 고객을 찾고, 기존 고객을 만족시키는 데 뛰어다니고, 마케팅 캠페인 기획·집행하느라 정신없이 지내거든요.
그러다 보니 자신의 입장에서 상대 팀에게 '왜 그걸 이해 못 하지?'하는 순간 갈등이 퍽퍽 터져 나오는 거예요. 감정이 격해진 양팀의 중간에서 저는 갈등 중재 비슷한 역할을 하고는 했는데요. '개발팀은 이 일정을 이만큼 미루면서까지 당장 이 기능을 넣으려면 엄청난 리소스를 써야 한다고 하더라. 대신, 이 기능을 어느 정도 MVP(최소 기능) 형태로만 구현해주면, 비즈니스 쪽에서도 시간표가 맞을 것 같다고 하지 않았냐?” 이런 식으로 중간에서 조율을 했죠.
중재자 역할을 하다보면 갈등 상황을 직접 다뤄야 해서 피곤하기도 하지만, 그렇다 보니 더 양측의 입장을 이해할 수 있었던 것 같아요. 상황이 닥쳤을 때가 아니라 '조금만 더 일찍, 제품에 대해 깊이 있게 대화해봤다면 어땠을까?'하는 아쉬움이 컸죠. 서로가 전혀 악의 없이, ‘우리 회사가 잘 되도록’ 노력하는 건 동일한데, 관점의 차이로 생긴 문제잖아요. 서로가 감정 상할게 전혀 아니니까요.
갈등의 실마리는 결국 '서로를 이해하는 태도'
양 팀의 갈등을 해결하기 위해서는 결국 서로의 우선순위를 이해하고 받아들이려 해야 해요. 예를 들어, 개발팀에서 '우리 못해요. 지금 쌓인 개발만 이렇게 많아요'가 아니라, '지금은 신기능 업데이트가 한창이라 우선순위를 바꾸기 어려워요. 그래도 꼭 필요한 기능이라면, 어느 범위까지가 타협점인지 논의해보시죠?'라고 제안할 수 있어요. 세일즈나 CS도 '우리도 고객사 입장에선 시급한 문제이긴 한데, 꼭 전부를 완벽하게 구현해야 하는 건 아니에요. 급한 부분만 MVP 형태로 우선 넣고, 나머지는 차차 확장하면 어떨까요?'라는 식으로 응답해준다면 이야기가 훨씬 부드럽게 풀리죠.
이렇게 서로의 입장을 이해해보면 누구 하나 게으르거나 불성실해서 생긴 갈등은 아니에요. 전부 우리 회사가 빨리 성장하길 바라며 열심히 일하는 사람들이 잖아요. 적이 아니라는거죠. 갈등이 생기는 순간, '왜 당신들은 그렇게 내 말을 안 들어줘요?'보다는, '제가 알기로 이런 이유로 중요하다고 들었는데, 혹시 어떻게 생각하세요?'라고 물어보면, 의외로 좀 더 순탄하게 협의가 진행될 수 있어요.
결국은 함께 성장하는 게 목표잖아요
개발팀이 있어야 제품이 존재하고,
그 제품이 있어야 고객에게 팔 수 있으며,
팔기 위해선 비즈니스팀이 열심히 영업·마케팅을 해야 한다.
이 세 박자가 고루 갖춰져야 회사가 굴러가는 거지 어느 한쪽만으로는 회사가 성장하기 어려워요. 그런데 팀마다 ‘회사 성장’을 위한 우선순위가 다르고, 그 과정에서 갈등이 생기는 건 너무 당연하니까요. 이 갈등을 문제로 보기보다 '아, 우리가 성장하고 있구나'로 받아들이면 쉬워요.
갈등 자체를 놓고 보기보다 '갈등을 어떻게 풀고, 다시 회사의 성장 엔진으로 삼느냐'가 더 중요하죠.
제 경험상, 갈등이 ‘전혀 없다’면 소통이 안 되고 있는 신호일 수도 있더라 고요. 그만큼 서로 말다툼이 싫으니 참고 일하고, 안해주고, 요청하지 않게 되니까요.
이런 갈등을 줄이는 최고의 방법은 끊임없는 커뮤니케이션이에요. 이게 가장 흔한 얘기면서도 현장에선 제일 잘 안 되거든요. 오늘이라도 바로 세일즈 동료에게 '왜 자꾸 고객 요청사항을 컷하지 못하고 우리한테 가져오는거지'와 같이 생각하기 보다,
"고객이 많이 힘들게 해서 피곤하시겠어요. 저희도 저희가 할 수 있는 최대한의 일정을 산출해 볼게요. 죄송하지만 그 기간만큼만 조금 고객을 설득해주실 수 있을까요?"
위와 같이 배려의 말을 전해보고,
또, 옆의 개발팀 동료에게, '고객이 빨리 해달라고 해서 급해요. 왜이렇게 계속 해결이 늦는거에요?'가 아니라,
'혹시 지금 말씀드린 고객사의 요청이 어떤 리소스가 필요한지, 어느 정도 일정 조정이 가능한지'를 먼저 물어보면 어떨까요?
회사는 어차피 함께 성장해야 해요. 개발, 비즈니스 할 것 없이 모든 조직들이 어우러져야 가능한 일이죠. 그러니 우리, 갈등이 생길 때마다 '이건 직무가 다름에서 오는 충돌이지, 서로를 감정 상하게 아니야'라는 사실을 잊지 않았으면 좋겠어요.
오늘도 IT 기업들의 회의실에선 '이 기능 당장 필요합니다!'와 '개발 로드맵 다 뒤집혀요. 지금 못해요'라는 목소리가 튀어나올지 모르지만 부디 그 끝엔 서로 한발짝씩 물러서며 '맞아.. 이럼 우리 둘다 업무 말아먹겠네.. 우리 사이에 다른 타협안이 뭐가 있을까?'도 웃으면서 이야기할 수 있길 바랍니다. 그리고 그렇게 갈등의 타협이 웃으며 진행되는 순간 회사도, 제품도 또 한 뼘 자라나 있을거예요.
