진짜로 오늘도 개발자가 "안 되는데요?" 했다.
어쩌다 보니 서비스 기획자가 되었습니다
이전 글 : 마케터로 시작해서, 서비스 기획자가 되기까지③
1. '기획자'는 이런 사람인데요? 목표 겨냥을 잘하고, 그걸 잘 맞추는 사람!
10인 미만의 작은 스타트업.
나는 마케팅과 기획 두 역할을 동시에 맡으며, 이제 막 ‘기획’이라는 세계에 발을 뗀 주니어였다.
새로운 일을 시작할 때마다 원론부터 파고드는 편이었기 때문에 먼저 스스로에게 물었다.
1) 과연 기획은 뭘 하는 사람일까?
난 기획자를 ‘과녁을 맞추는 사람’이라고 생각한다. 목표가 하나면 거기에 딱 맞는 기획이 따라야 하고, 그 과정엔 숫자(정량)와 이야기(정성) 근거가 꼭 붙어야 해. 그래야 내가 던진 기획에 확신을 갖고, 팀원을 설득하고, 나중엔 사용자까지 납득시킬 수 있으니까.
양궁 선수가 10점을 노리듯, 기획자도 목표를 제대로 맞추려면 준비가 꽤 많다. 시장 조사, 데이터 분석, 벤치마킹… 이 모든 과정이 ‘과녁 한가운데’를 위한 훈련이더라. 그리고 실제 서비스에서 결과가 나오면 비로소 “아, 내 방식이 통했구나” 하고 스스로 확신을 얻는 거 아닌가 싶었다. 결국 기획자는 “새 서비스 만드는 사람”이 아니라, 비즈니스 목표에 가장 잘 꽂히는 화살을 골라 정확히 쏘는 사람이라고 생각했었다. 그러고 나서는 관련된 책들을 많이 읽기 시작했고 내가 생각한 결론과 맞닿아 있다는 것을 확인하며 '내가 되고 싶은 기획자'의 방향성을 잡았던 것 같다.
2) 나는 좋은 기획자였을까?
내 정의가 틀렸던 건 아니라고 생각한다. 하지만 방법이 틀렸던 것은 인정한다.
그때 내 머릿속엔 “커머스의 결과는 ‘구매’다”라는 생각이 꽉 들어차 있었다. 그리고 GA랑 Amplitude만 있으면 사용자의 동선을 실시간으로 읽어 내고, 남겨 놓은 모든 흔적을 줍줍해서 액션으로 바꿀 수 있을 거라 확신했었다.
사실 그전까지 했던 작은 개선들이 성과가 꽤 잘 나왔기 때문에, 자존감 풀차지 상태였달까?
“이번에도 과녁 한가운데 찍는다!”는 기대감으로 기획서를 미친 듯이 써 내려갔다. 명확한 액션을 통해 결과를 내는 사람, 그래서 비즈니스를 목표에 맞게 점진적으로 성장시키는 사람이 기획자니까. 그리고 7개월 간, 나는 책에서 그리고 강의에서 들었던 '기획자'라는 정의에서 벗어나지 않는다고 여겼다. 작은 규모의 회사지만 제너럴리스트로서 여러 역할을 하면서, 그리고 그 안에서 나만의 기획 경험을 쌓으며 스스로 잘 성장하고 있다고 생각했고, 이대로만 가면 된다고 생각했다.
하지만 모수가 늘어나면서 새 기능·개선 요청이 쌓이기 시작했고, 기능 스펙은 점점 덩치가 커졌다.
생각해 보니 이때부터였던 것 같다. “이건 회사에 꼭 필요해, 무조건 해야 해!”라며 속도전에 돌입했다. 기능 정의, 참고 레퍼런스, 데이터 지표 등등 필요한 부분을 챙겼기에 지금 내 방법에 문제점이 없다고 생각했다.
‘뇌피셜 아니야. A/B 테스트도 돌렸고, 숫자 근거도 다 챙겼잖아?’
그땐 정말, 내 기획서에 문제 따윈 없다고 믿어 의심치 않았다. 그리고 ‘기획 → 개발 → QA → 배포’라는 정상적인 프로세스에 따라 당연히 개발자에게 구현을 요청했다.
“사용자가 A 단계에서 이탈하니, 이를 방지하려면 B 기능을 개발해야 합니다.”
“리마인드 메시지 반응이 좋아서, 개인별 리마인드 메시징 기능을 추가해야 합니다.”
“1년 치 마케팅 플랜을 짜보니 설날 즈음에 B 기능이 필요할 것 같아 기획했는데, 이렇게 진행해도 될까요?”
하지만 돌아오는 대답은 거의 대부분 “안된다”, “그 시기에는 불가능하다”, “너무 명확하지 않다”, “다른 방향이 더 나을 것 같다”는 식이었다.
2. 왜 안된다고만 하는지 모르겠어요.
1) 기획자는 기획을 하는 사람이고, 개발자는 개발을 하는 사람인데 왜 안 해준다는 거야? 왜?
그냥 마냥 억울하고 속상한 마음만 가득했다. 왜 도대체 안된다고만 하는 거야? 진짜 왜 그러는 거야?
나는 개발자와 함께 일을 하면서 기획을 시작했기 때문에, 그리고 완전 전공이 먼 영역도 아니었기에 '개발'이라는 직무를 조금은 이해하고 있고, 타당한 근거와 가능한 액션이라 생각했는데 반복되는 거절이 너무 좌절스러웠다. 그때, 타 회사의 CFO를 만나서 이야기를 나누게 되는 기회가 있었다.
“제 기획의 이유는 너무 명확한데, 왜 개발자들은 제 기획을 실행하기 싫어하는 걸까요?”
“기획자는 기획을 하고, 개발자는 그것을 실현하는 사람이 아닌가요?”
그 말을 듣던 CFO님께서 최근에 나온 책이 하나 있는데, 이 책을 좀 읽어보면 도움이 될 것 같다고 말했다.
그 책이 바로 오늘도 개발자가 안 된다고 말했다였다. 이 책이 나온 시점은 2021년 3월 경이었던 것 같다.
2) 개발자가 '안 된다' 말하는 이유가 따로 있다고?
평소엔 그 개발자랑 꽤 잘 지냈다.
내 기획서만 보면 “오, 센스 있네!” 하며 박수 쳐주고, 엄지까지 들어주니까 나도 든든했지. 어느 날은 먼저 팔로업까지 해 주면서 개발 태스크를 뚝딱 만들어 줄 정도라 “이 정도면 문제없다” 싶었다.
추천해 주신 책을 좀 살펴보자는 마음으로 서점에 갔다. 그리고 서점에서 표지를 보며 ‘이걸 읽는다고 뭐가 달라질까?’ 싶었지만, 결국 나오는 길에 내 손에는 이 책이 들려있었다. 출퇴근길에 틈틈이 읽으면 되고, 어차피 나보다 경험 많은 사람이 권한 액션이라면 한 번쯤 따라 해 보는 게 빠른 길이니까. 한 번 읽어나 보지 뭐라는 생각이었다.
3. 내 기획서의 문제점을 찾는 순간
생각해 보면, 예전 내 기획서엔 숫자도, 근거도, 우선순위도 없이 ‘그냥 필요해 보이니까’라는 말만 잔뜩이었던 것들이 많았다. 당연히 개발자 입장에선 ‘이거 왜 하지?’부터 막히니, 안 된다고 할 수밖에 없었던 거다.
1) 왜 또 “안 돼요”냐
개발자는 ‘귀찮아서’가 아니라 시간·리스크·우선순위를 종합해 불가 판단을 내린다.
먼저 문제 정의·가치·근거를 제시해 주면 대화가 풀린다.
일단, 내 기획서는 '이탈률이 높다' '기간은 2주 정도 예상'과 같은 정확한 수치적 근거가 빠진 부분이 많았다.
이탈률이 얼마나 높은데? 그들이 액션을 취하기 위해서 문제와 함께 그 수치를 제공해 주었다면 좀 더 설득력이 있었고, 심각하다 판단이 되는 수준이면 빠른 실행을 해줬을 것이다.
2주를 추정할 때는 출처의 근거가 있어야 하는데, 우리가 지금까지 개발해 왔던 기능의 스펙과 유사하다고 생각해서 대~충 산정했던 일정이 그에게는 와닿지 않았던 것이다. 나는 기획이라는 일감을 만들기만 했지, 커뮤니케이션을 위해서 그리고 이 기획을 구현하는 개발자의 입장에서 'why'를 해결해줘야 한다는 것을 고려하지 않았던 적이 많았던 거다.
2) 개발 언어보다 ‘개발 구조 이해’
HTML · API 이름을 전부 외우는 것보다,
‘프런트–백엔드–DB–배포’ 흐름을 상위 레벨에서 파악하는 편이 협업 효율이 높다
"앱 실시간 알림을 보내려면 그냥 프런트에서 푸시 띄우면 되지 않나요?”라는 애매한 물음에 개발자는 어떤 생각을 했을까? 푸시는 FCM/APNs + 백엔드 토큰 관리가 필수인데, 프런트와 백엔드의 명확한 업무의 구분조차 하지 못하고 기획서를 전달했으니 당연히 그들 머리에는 물음표만 가득했을 것이다.
“배포는 금요일 오후에 하면 안 되나요? 그때가 사람이 제일 적은데!" 사실상 금요일 오후는 릴리즈 금기 시간(장애 시 복구 인력 없음)이다. 배포 정책이 어떻게 되는지도 모르는 새내기 기획자가, 사용자의 데이터에만 초점을 맞춰서 배포 일자를 언급하는 것이 굉장히 당혹스러운 일이었을 수 있다. "그럼 이거 에러 대응은 어떻게 해야 하지?"라는 생각이 머리를 지배하지 않았을까?
3) 커뮤니케이션은 기획서로 완성
기획서는 지시서가 아니라 ‘대화 도구’.
왜·무엇을·언제 가 먼저 보이고, 화면 설계서에는 제목·스토리라인·우선순위가 읽혀야 한다.
나는 기획을 하고 그 기능이 왜 필요한지, 그 근거는 무엇인지에 대한 리뷰를 많이 진행했었다.
하지만 솔직히 말해, 기획은 열심히 했지만 ‘작은 기능’쯤은 절차를 생략해도 된다고 생각했다. 그래서 리뷰도 건너뛰고 완성된 문서만 들고 갔던 적이 좀 있었다. 문제는 그 문서가 하나도 친절하지 않았다는 점이다. 첫 페이지에 배경이나 목표는 없고, 와이어프레임만 덩그러니 놓여 있으니 개발자 입장에선 “이게 왜 필요한 건데?”가 먼저였겠지.
오류·Empty State 화면도 꼼꼼하게 체크가 되지 않았다.
메인 플로우야 탄탄했더라도, 예외 상황이 정의되지 않았으니 데이터가 비었을 때 UI/UX가 무너지는 건 뻔한 일. 결국 개발 일정이 뒤틀릴 걸 미리 본 사람들은, 그저 “안 돼요”라고 말할 수밖에 없었을지도 모른다.
4. 정말 미안하다. 개발자야.
이 책을 읽고, 내 기획서를 뜯어보면서 새삼 깨달았다. 나와 함께 일했던 개발자들은 그래도 5년 이상의 연차를 가진 사람들이었다. 그리고 그들이 던진 “안 돼요”는 귀찮음이 아니라 위험 신호였다.
나는 작은 기능이라며 과정을 생략했고, 배경·목표·예외 케이스가 빠진 반쪽짜리 문서를 건넸다. 불확실한 스펙 그대로 코드를 짜는 일, 얼마나 답답했을까? 생각해 보면 거절을 하는 액션을 보일 때 줬던 문서에 유독 그런 부분들이 많았다.
다른 때는 "아직 처음이니까."라는 생각으로 자기들이 유추개발을 하면서 맞춰줬을 것이다. 유추를 하다가도 이해가 안 되는 부분들이 계속 생기니 나에게 질문을 많이 하게 되고, 비효율적인 시간을 소모하면서까지 내가 만든 기획을 개발해 주려고 최대한의 노력을 해왔던 거다. 하지만 정말 이건 아니다 싶으니까, 그리고 임팩트가 큰 기능이니까, 코드에 많은 영향을 주는 기능이니까 "안돼!"를 외쳤을 걸 생각하니 정말 미안한 감정이 밀려왔다.
이 책을 다 읽고, 월요일에 출근을 해서 자리에 앉아 그들과 인사하는 순간 ‘그동안 얼마나 답답했을까?’라는 생각이 먼저 스쳤고, 괜히 남 탓만 했던 게 너무 미안하고 창피했다. 그래서 주간 회의 때 이렇게 털어놨다.
“그동안 제 반쪽짜리 기획서를 보고도 묵묵히 개발해 준 거 정말 고마워요.
앞으로는 Why부터 쓰고, 흐름·오류·Empty State 다 챙길게요. 일정도 ‘급해요!’ 대신 캘린더부터 같이 열어보고 정하도록 할게요. 백엔드 그리고 프론트 각각 어디에 리소스가 얼마나 드는지도 먼저 파악해서 현실적인 기간을 함께 산정하는 방법을 배워갈게요.
무엇보다 다음엔 ‘지시서’ 아니라 ‘대화의 시작’ 같은 기획서를 줄 수 있도록 저도 개발 쪽 공부 더 열심히 해 보겠습니다. 그동안 “안 돼요”만 듣는다고 섭섭해했는데, 사실 제 부족함이 컸어요. 불평 한마디 없이 좋은 기능 만들어 줘서 정말 고마워요.”
그리고 회의실을 나오면서 마음속으로 다짐했다.
“언젠가는 진짜로 ‘이 정도면 바로 됩니다!’라는 말을 듣고야 말겠다. 그러려면 내가 먼저 변해야지.”
개발자 급까지 갈 필요는 없지만, 개발이 어떻게 돌아가는지는 제대로 이해해 보기로 했다. 그리고 그 테크니컬 백그라운드가 내가 정말 '좋은, 일 잘하는 기획자'로 성장하는데 가장 중요한 요소가 될 테니까.
시스템 흐름 – 프런트·백엔드·DB·배포 파이프라인이 어떻게 이어지는지 큰 그림부터 잡기.
REST·API 스펙 – 내가 적은 한 줄이 코드 한 줄이 되기까지 어떤 약속이 필요한지 공부하기.
Git & PR 문화 – “버전 관리가 뭔데요?”라던 예전의 나와 작별하고, 오히려 버전 관리를 제안하기
간단한 SQL·로그 읽기 – 장애가 터졌을 때 최소한 원인을 짐작할 수 있을 만큼만.
테스트·오류 케이스 – Happy Path뿐 아니라 “데이터가 없을 때 UI가 어떻게 깨지는지”까지 상상하기.
무조건 멋진 기능을 ‘빨리’ 달라고 조르는 대신, 왜 필요한지 설명하고, 구현 난이도를 함께 가늠하고, 캘린더를 나란히 열어 현실적인 일정을 짜는 기획자가 되는 것을 목표로 삼기 시작했다.
모든 걸 한 번에 배우고 익힐 수는 없겠지만, 3년 5년 그렇게 기획이라는 일을 하면서, 개발자와 함께 협업을 하면서 그 과정에서 필요한 부분을 따로 공부하고 쌓아가다 보면 언젠가 개발자들이 먼저 “네, 바로 되죠!”라며 대답해 주는 날만 있지 않을까 꿈꾸면서 말이다.
