“예외케이스, 그게 중요해?" 문제는 늘 뒤늦게 온다.
어쩌다 보니 서비스 기획자가 되었습니다
이전 글 : 진짜로 오늘도 개발자가 "안 되는데요?" 했다.
1. 예외는 항상 존재하고, 그 예외는 문제를 만든다.
10인이 되지 않은 작은 스타트업에서, 나는 처음으로 ‘기획자’라는 정체성보다 ‘기획이라는 일’ 자체에 책임감을 느끼는 경험을 했다. 고작 1년 차 주니어 때의 일이었지만, 이 경험은 지금의 나에게 가장 큰 영향을 준 순간이기도 하다.
예측할 수 없는 예외는 반드시 있고 생기고,
그로 인한 문제는 반드시 발생하며,
그 문제를 ‘빠르게’가 아니라 ‘잘’ 해결하는 방법을 찾아야 한다.
아, 물론 빠른 대응도 중요하다. 핫픽스가 필요한 상황, 실시간 트래픽 대응, 운영 장애나 VOC 대응 등 즉각적인 조치가 필요한 순간도 많다. 하지만 그럴 때일수록 더 자주 물어야 한다고 생각한다.
내가 결정한 것에 확신이 들 때까지, 스스로에게 의문을 던지며 놓지 말아야 한다. 처음부터 알 수 있었다면 좋았겠지만, 직접 경험하면서 서비스가 휘청이는 걸 눈앞에서 봤기에, 진짜 ‘해결’이란 단어의 무게를 알게 되었다. 그래서 지금의 나는 어떤 액션을 하기 전, 항상 스스로에게 이 질문을 던진다.
"이게 진짜 최선일까?”
“이 해결 방식이 또 다른 문제를 만들진 않을까?”
“이게 진짜, 내가 할 수 있는 최선의 해결이야?”
해결이라는 단어의 사전적 의미는 '문제를 끝냈다' '처리했다'이다. 하지만 나는 이 단어를 ‘잘 예방했다’로 정의하고 있다. 같은 문제가 반복되지 않도록, 다른 문제가 생기지 않도록, 조금 더 멀리 내다보며 구조를 정리하는 일 말이다. 그리고 그게 기획자 혹은 PM이 해야 할 해결 방식이라고 생각하게 됐다.
2. 2020년, 커머스는 마케팅의 전쟁터였다
이 이야기를 꺼내기 위해선, 그 시점의 배경부터 짚고 가야 할 것 같다.
2020년, 코로나19가 터지며 e커머스는 말 그대로 온라인 마케팅 전쟁의 중심에 있었다. 소비자들의 소비 방식이 오프라인에서 온라인으로 급격히 이동했고, 그만큼 새로운 커머스 모델들이 우후죽순 생겨났다.
각 브랜드들은 자사만의 브랜딩을 구축하며 치열하게 시장 점유율을 쟁탈했다. 이제는 너무 익숙한 이름이 된 기업들이 그 시절, 전략적 투자와 마케팅으로 무섭게 시장을 키워가던 시기였다. 그리고 그 흐름을 읽고 미리 준비했던 스타트업들은 빠르게 부상하거나 혹은 기존의 비즈니스 모델을 전환하며 기민하게 그 흐름에 올라타기도 했었다.
그 시기를 돌이켜보면, 특히 기억에 남는 키워드는 두 가지 정도가 있다. 아마도 우리가 그때 “이걸 우리도 해보자”라고 했던 것들이라, 기억에 남는지도 모르겠다. 무엇보다 그 두 가지가 하나는 성공이었고, 하나는 회사를 흔드는 실패였기 때문에 더 그런 것 같다.
1) 배송 전쟁 - 성공
새벽배송이 본격적으로 각축전을 벌이기 시작했을 때가 바로 이때였다. 쿠팡, 마켓컬리, 쓱 닷컴 등은 새벽배송 서비스를 앞다퉈 강화했고, 대형마트는 ‘온라인 주문 → 매장 픽업’이라는 새로운 흐름을 만들었다.
우리도 당시 ‘빠른 배송’을 목표로 개선을 시작했다. D2C 구조라서 가능했던 동대문 직매입 → 오후 2시 전 주문 → 당일 발주 → 다음날 출고 루트를 만들었다. 물론, 이를 구현하기 위해 개발팀이 외부와 연동 작업을 맞추고, 물류/재고 담당자와 매일 물량을 체크하며 ‘2일 내 도착’ 기준을 지켜냈던 기억이 난다.
2) 이벤트 전쟁 - 실패
'이벤트만 노리는 체리피커여도 괜찮아’ 라는 분위기였다. 마케팅 비용 대비 매출을 뽑아내는 게 무엇보다 중요한 시기였고, 돈은 돈대로 쓰이는데 전환이 안 되면 의미가 없었기 때문이다.
이때 가장 많이 등장한 것이 바로 ‘추천 이벤트’였는데, 마켓컬리의 친구 추천 이벤트는 말 그대로 ‘혁명’이었다. 신규 가입자에게는 즉각적인 혜택을, 기존 회원에게는 바이럴 인센티브를 주는 구조였는데, 마케팅 예산을 들여 광고를 집행하는 것보다 바이럴이 더 빠르다는 걸 증명해 대표적인 사례였다. 이후 수많은 e커머스들이 이 구조를 가져다 썼고, 우리 역시 회의실에서 이 구조를 그대로 따라야 한다는 이야기가 나왔고, 결국 우리도 그 구조를 따랐갔다.
3. 문서 없이 시작된 개발, 그리고 고려되지 못한 예외
작은 조직은 장점과 단점이 뚜렷하다. 결정이 빠르고 실행이 빠르다. 하지만, 하나의 판단을 다양한 관점으로 비틀어 보기엔 여유가 없고 이번 일도 그랬다. 회의 중 누군가가 “우리도 친구 추천 이벤트 해보면 어때요?”라는 말로 의견이 나오기 시작됐다.
기능은 너무 단순했다. 추천인의 전화번호나 아이디를 입력하는 필드 하나, A 고객이 동일한 친구를 여러 번 추천하지 못하게 중복만 막으면 되는 정도였다. 아니? 보이는 게 그 정도였다는 게 맞겠다.
사실 언급된 정도 스펙의 기능은 개발자 입장에서도 구현이 복잡하지 않았기 때문에 기획 문서 없이 바로 작업이 가능했고 “이번 주 안에 라이브 하자”는 결론이 나왔다. 해야 하는 이유도 명확했고, 기능 자체도 복잡하지 않았다. 하지만 단 하나, 예외 케이스는 논의되지 않았다.
1) 어? 하면 안 될 것 같은데?
나는 그 기능에 반대했었다. 단순히 ‘이벤트 하지 말자’는 뜻은 아니었다.
그 이벤트가 가져올 수 있는 부작용들, 그리고 우리가 가진 자본 구조에서 그걸 감당할 수 있을지에 대한 우려였다. 우리는 고작 1.5억 원의 시드 투자를 받은 초기 스타트업이었고, 아직 안정적인 흑자 구조도 아니었다. 그런 상황에서, 몇 명이라도 지속적으로 적립 혜택을 반복해서 가져갈 수 있는 구조가 된다면? 그 리스크는 생각보다 클 수 있다고 판단이 들었다.
어쩌면 그 감각은, 내가 한 달에 50만 원 이상을 쓰던 ‘헤비 쇼퍼’였고, 그 당시 기준으로는 전형적인 체리피커였기 때문일지도 모른다. 사용자의 시선으로 봤을 때, 이벤트 구조 안에 허점이 있다는 걸 나도 모르게 느꼈던 것 같다.
하지만 그때에 나는 “이 기능엔 이런 예외 케이스가 있고, 이게 고려되지 않으면 이런 리스크가 있습니다”라고 명확하게 설명할 수 있을 만큼의 경험도, 지식도 부족했다. 그래서 결국 ‘근데 이걸 해도 괜찮아요? 남들이 한다고 다 따라 하면 안 될 것 같아요’ 같은 말밖에 할 수 없었다.
지금 돌이켜보면, 그건 단순한 막연함이 아닌, 경험 대신 감각이 먼저 반응했던 불안감이었는지도 모르겠다.
2) 그래도 괜찮겠지? (아니, 절대 아니야!)
그 우려는 결국 어떤 문서에도, 회의록에도 기록되지 않았다. 그때 내게 돌아온 말은 이랬다.
“다음 투자를 위해선 지금 트래픽이 상승하고 있다는 그래프가 중요해요.”
“커머스는 결국 마케팅 싸움인데, 우리도 한 번 해볼 만한 가치 있잖아요.”
사실 다 맞는 말이었다. 자금 사정이 넉넉하지 않은 초기 스타트업에게 ‘투자 가치’를 증명하는 건 굉장히 중요한 일이었고, 당시 그 가치를 보여줄 수 있는 대표 지표가 바로 트래픽이었다. 트래픽이 몰린다는 건 시장의 관심을 증명하는 일이고, 그 흐름을 유지한다는 건 우리 제품이 여전히 ‘살아 있다’는 신호였다.
그리고 “일단 해보고 문제 생기면 내리면 되잖아. 기능 막는 건 금방이지.” 이 말도, 유명하지 않은 초기 서비스이라 충분히 가능한 것이었기 때문에 틀린 말은 아니었다. 이벤트를 해야만 하는 의도는 충분히 공유되었고, 개발할 수 있는 조건도 됐기 때문에 그저 실행만 하면 됐었다. 그래서 나도 “그래, 뭐 큰 문제 생기겠어. 중복만 잘 막으면 되겠지.” 스스로를 납득시켰던 것 같다.
하지만 돌이켜보면, 그 막연함은 내가 정말 ‘기획자’라면 절대 품어선 안 되는 것이었다. ‘그래도 괜찮겠지’라는 마음이, 사실은 가장 위험한 출발점이었다는 걸 그때는 정말 몰랐었다.
많은 서비스들이 하나의 이벤트를 위해 얼마나 많은 고민과 테스트를 거치는지, 얼마나 다양한 예외 케이스와 리스크를 검토하는지, 그리고 어떤 방식으로 검증하고 조율한 뒤에야 비로소 라이브에 올리는지를, 그때는 미처 생각하지 못했었다.
정말 따라 할 거였다면, 겉모습만 보고 흉내 낼 게 아니라 내가 직접 컬리의 친구 추천 이벤트를 여러 방법으로 테스트를 해보고, 그걸로도 부족하다면 진짜 역기획이라도 했어야 했다.
“왜 이 구조를 썼을까?”
“어떤 조건을 두고, 무엇을 막으려고 했을까?” 최소한 우리 서비스에 맞게 설계는 못하더라도, 그들이 설계한 구조 안에 담긴 의도와 맥락까지 뜯어보고 실행했었어야 했다. 그게 아니라면, 그저 ‘잘 나가는 누가 하니까 우리도 해볼까?’라는 뱁새가 황새를 따라가는 마음으로 움직여선 안 되는 일이었다.
4. 예외는 문제가 되고, 그 문제는 항상 늦게 찾아온다
이때 진행했던 '친구 추천 이벤트'는 지금까지도 나에게 가장 큰 교훈을 주었던 경험으로 남아있다.
그리고 5년 차가 된 지금도 항상 느끼는 건 기획자나 PM이 모든 예외 케이스를 방어할 수는 없다는 사실이다.
나는 고작 한 명의 사람이고, 이 한 명의 사람이 모든 사용자 입장에서 서비스를 사용하는 행태를 상상해서 모든 상황을 예측할 수는 없기 때문이다. 그래서 세상에 완벽한 기획은 없다는 말에도 이 현실이 분명히 반영되어 있다고 생각한다.
실제로 많은 서비스들이 점차 고도화되면서, 프로모션 하나에도 방어적인 구조를 촘촘히 설계하고 있다는 것을 느낀다. 화면은 단순해지지만, 백엔드 로직은 점점 더 말도 안 되게 꼼꼼해지고 있다는 말이다. 하지만 그럼에도 불구하고, 사후 대응보다 사전 예방이 낫다는 말은 여전히 유효하다.
적어도 “이런 문제가 생길 수도 있겠다”는 상상 그리고 그 가능성을 구체적으로 세분화하려는 시도는 기획자 혹은 PM이라면 반드시 가져야 할 태도다. 나는 모든 사용자를 대변할 수 없지만, 내가 생각한 예외 케이스를 기준으로 다른 직군, 다른 기획자 혹은 PM과 리뷰와 논의를 거친다면 그 과정에서 새로운 예외를 발견할 수 있다. 그렇게 보완하고, 좁혀나가는 과정이 필요하다. 그래야 100개의 예외를 50개로, 25개로, 결국 1개로 줄일 수 있다.
하지만 그 과정을 거치지 않는다면, 내가 맡고 있는 제품에 어떤 일이 일어날지 예측조차 할 수 없다.
“최소한 50개는 막았으니까 괜찮겠지.” 그게 아니라,
“50개는 막았는데, 그 외엔 뭐가 남았지?”라는 질문이 이어져야 한다.
그렇지 않으면, 혹시 모를 충격을 완화할 단 하나의 대비책도 마련하지 못한 채 제품이 위험에 노출될 수 있고, 그 영향도는 어디까지 퍼질지 예측조차 할 수 없다. 딱 우리가 그랬다.
2편으로 이어집니다 (?)
