Vol.08 - 주니어 기획자의 좋은 기획 찾아 삼만리

안녕하세요, 제로백데브 프로덕트 매니저 서희정입니다!

제로백데브 Lab 포스팅을 통해 처음 인사드리네요. 잘 부탁드립니다!

저는 지난 8월 대학교를 졸업하고, 제로백데브에서 바로 첫 커리어를 시작하게 되었는데요.

학부 시절 여러 프로젝트를 경험했지만, 실제 SI 에이전시에서 마주한 기획 환경은 생각보다 훨씬 달랐습니다.

고려해야 할 이해관계자도, 챙겨야 할 정책과 예외 케이스도 많았어요. 그러다 보니 입사 후에는 ‘좋은 기획은 어떻게 해야 하지?’라는 고민을 정말 많이 했습니다.

주니어 중에서도 따끈따끈한 막내 주니어인 만큼, 처음부터 다시 고민하면서 저만의 방법을 하나씩 만들어가고 있는데요!

이번 글에서는 제가 실무에서 어떤 시행착오를 겪었는지, 그 과정에서 어떤 방법을 시도했고 지금은 어떻게 기획하고 있는지를 이야기해보려고 해요.

저와 비슷한 고민을 하고 있는 예비 프로덕트 매니저와 주니어 기획자분들에게 작은 힌트가 되었으면 합니다!

주니어 기획자들의 가장 큰 어려움 : 확신이 없다

주니어 PM으로 처음 기획을 맡았을 때, 저에게는 "이 기획이 제일 베스트입니다!"라고 말할 자신이 없었어요.

그래서 떠오르는 관점마다 시안을 하나씩 만들었죠. 돌아보면 시안의 개수는 제 불안의 크기였던 것 같아요.

그런데 시안을 여러 개 만드는 것보다 더 어려운 게 있었어요. 바로 그중 무엇을 남길지 정하는 일이었습니다.

이 글에서는 개인화 영역을 기획했던 경험을 중심으로, 시안을 어떻게 만들고 어떤 기준으로 좁혀나갔는지 공유해볼게요.

1단계. 문제를 찾는 것보다, 빠짐없이 쪼개는 게 더 중요했다

시안을 만들기 전에 가장 먼저 한 일은 사용자가 이 페이지에 왜 들어오는지, 즉 방문 목적을 정의하는 것이었습니다. 목적이 흐리면 어떤 시안이 더 좋은지 판단할 기준도 함께 흐려지기 때문이에요.

다음으로는 As-Is의 Pain Point를 정리했어요. RFP에 적힌 요구사항만 분석한 것이 아니라, 직접 사용자가 되어 서비스를 이용해보고 고객센터 Q&A도 꼼꼼히 살펴봤습니다.

요구사항 문서에는 ‘무엇을 만들어달라’가 적혀 있었지만, 고객센터 문의에는 사용자가 실제로 ‘어디에서 막히는지’가 드러나 있었기 때문이에요.

그런데 Pain Point를 문장으로만 정리해두니 문제 자체는 이해할 수 있어도, 정확히 어느 단계에서 왜 불편이 발생하는지는 한눈에 보이지 않았어요.

그래서 사용자가 서비스를 이용하는 흐름을 플로우 차트로 그리고, 각 단계에서 어떤 문제가 발생하는지 하나씩 짚어보기 시작했습니다. 막연했던 Pain Point를 사용자 행동의 흐름 위에 올려두니, 문제가 발생하는 지점과 원인을 훨씬 구체적으로 볼 수 있었어요.

플로우로 펼쳐보니 문장에서는 잘 보이지 않던 것들도 드러났습니다. 불필요하게 반복되는 단계, 사용자의 불편이 발생하는 단계, 그리고 아무리 단순화하더라도 반드시 남겨야 하는 필수 단계가 구분되기 시작했어요.

이 과정을 통해 ‘사용자 입장에서는 최대한 단순하지만, 필요한 절차는 빠짐없이 거치는 흐름’을 설계 초안으로 정리할 수 있었습니다.

Tip) 플로우 분석은 Draw.io나 FigJam을 추천드려요!

기획에서 가장 중요한 것은 문제 정의다’라는 말은 꽤 상투적으로 들릴 수 있어요. 하지만 실무에서 느낀 문제 정의는 단순히 문제를 한 문장으로 정리하는 일이 아니었습니다.

같은 기능을 사용하더라도 사용자 유형과 상황에 따라 겪는 문제는 달라질 수 있어요. 그래서 페르소나와 상황별 케이스를 나누고, 서로 겹치거나 빠지는 부분이 없도록 문제를 계속 세분화해야 합니다.

문제를 한 번 정의했다고 끝나는 것도 아니었어요. 정의한 문제를 다시 쪼개고, 그 안의 문제를 또 쪼개면서 ‘사용자가 정확히 어느 상황에서, 어떤 이유로 어려움을 겪고 있는지’를 찾아가는 과정이 필요했습니다.

결국 제가 실무에서 배운 문제 정의는 ‘문제를 빠짐없이 잘게 나누는 것’이었습니다.

2단계. 같은 업계, 그리고 다른 업계의 답안지

문제를 정의한 다음에는 다른 서비스들이 비슷한 문제를 어떻게 풀고 있는지 살펴봤어요. 먼저 유사 서비스의 레퍼런스를 최대한 많이 모으고, 각 화면에 어떤 요소와 기능이 들어가 있는지 하나씩 뜯어봤습니다.

그런데 같은 업계의 서비스만 보다 보니 비슷한 방식의 답이 반복해서 보이더라고요. 그래서 업종은 다르더라도 비슷한 기능과 사용자 행동을 가진 서비스까지 레퍼런스 범위를 넓혔어요.

이때 UI Bowl과 같은 레퍼런스 사이트를 활용했습니다. 다른 분야에서는 등급이나 성취도를 어떻게 보여주는지, 사용자가 다음 행동을 하도록 어떤 방식으로 유도하는지 등을 UX 관점에서 분석했어요.

이 과정에서 얻은 건 하나의 정답이 아니라 여러 개의 선택지였습니다. 같은 문제도 생각보다 훨씬 다양한 방식으로 풀 수 있다는 걸 알게 됐고, 이렇게 모은 선택지들은 다음 단계에서 여러 시안을 만들어보는 데 중요한 재료가 됐어요.

3단계. 정해진 사고에서 벗어나기 위해, 시안 제작 방식부터 달리했다

와이어프레임을 만들 때는 먼저 필수 기능을 한 화면에 전부 올려뒀어요. 어떤 시안을 만들더라도 반드시 포함해야 하는 ‘공통 분모’를 먼저 정한 거죠.

그다음에는 같은 필수 기능을 가지고 여러 버전의 와이어프레임을 만들었습니다. 이때 일부러 시안을 만드는 방식도 다르게 가져갔어요.

직접 그린 시안: 앞서 분석한 내용을 바탕으로, 머릿속에 가장 먼저 떠오른 구조를 그대로 옮겼습니다.
레퍼런스를 활용한 시안: 다른 서비스에서 발견한 좋은 기능이나 UX 패턴을 가져와 우리 서비스의 맥락에 맞게 변형했습니다.
AI와 함께 만든 시안: Figma 에이전트와 Claude에게 문제 정의와 필수 기능을 충분히 설명한 뒤, 제가 생각하지 못했던 구성안을 받아 비교했습니다.

경험이 많지 않은 제가 혼자 시안을 만들다 보면 결국 제가 익숙한 사고 안에서만 답을 찾게 되더라고요. 그래서 일부러 접근 방식을 달리했습니다.

제가 직접 생각한 답, 다른 서비스가 찾은 답, AI가 제안한 답을 나란히 놓고 비교하면서 제 사고방식 바깥의 선택지를 최대한 많이 만들어보려 했어요.

중요했던 건 AI나 레퍼런스에서 ‘정답’을 찾는 것이 아니라, 제가 미처 생각하지 못한 선택지를 늘리는 것이었습니다.

4단계. 시안은 그럴듯했고, 데이터는 솔직하다

와이어프레임과 상세 기획안을 나란히 놓고 비교하는 것만으로는 좋은 기획안을 판가름하기 어려웠어요. 이때 겪었던 시행착오를 개인화 영역 기획 경험을 토대로 설명해볼게요.

기준을 세우고, 실제 데이터에 직접 적용

개인화 영역에서 처음 제안했던 방식 중 하나는 사용자의 활동 수준을 단계별로 보여주는 레벨링이었어요.

먼저 레벨을 나누는 기준이 될 데이터를 직접 확인하고, 제가 세운 기준을 적용했을 때 기존 사용자들이 각각 어느 단계에 속하는지 분포를 살펴봤습니다.

그런데 문서 위에서는 그럴듯했던 기준이 실제 데이터에서는 예상과 다르게 움직였어요. 특정 단계에 사용자가 지나치게 몰리기도 했고, 반대로 거의 도달할 수 없는 단계가 생기기도 했습니다.

레벨이 사용자에게 성취감과 다음 단계에 대한 동기를 주려면 일부 구간에 과도하게 쏠리지 않고, 단계별 차이가 의미 있게 느껴지는 분포가 필요했어요. 그래서 실제 분포를 확인하면서 기준값을 조정하고, 다시 데이터를 적용해보는 과정을 여러 번 반복했습니다.

당연히 사용할 수 있을 거라 생각했던 데이터가 그렇지 않았을 때

또 다른 개인화 기능에서는 사용자의 학습 성취를 여러 기준으로 세분화해 단계별 배지를 제공하려고 했어요.

이 과정에서 가장 큰 시행착오를 겪었습니다. 배지 산정에 활용하려던 데이터가 대부분의 사용자에게는 정상적으로 존재했지만, 일부 사용자에게는 운영 방식에 따라 데이터가 축적되지 않는 예외 케이스가 있었어요. 전체 사용자 중 소수에 해당하는 케이스라 초기 분석 과정에서 미처 발견하지 못했던 거죠.

당장 현재 사용자만 놓고 보면 별도의 예외 처리로 해결할 수도 있었어요. 하지만 서비스를 계속 운영하고 대상 사용자가 늘어난다면, 지금은 소수인 케이스가 앞으로도 계속 예외로 남아 있을지는 알 수 없었습니다. 정상적으로 학습한 사용자가 개인화 기능에서 제외되는 구조 역시 그대로 둘 수 없었고요.

그래서 단순히 예외 케이스를 하나 더 분기하는 데서 끝내지 않았어요. 이 사용자를 별도로 처리하는 것이 맞는지, 서비스가 확장된 이후에도 같은 분기가 유효할지, 아니면 애초에 더 많은 사용자를 포괄할 수 있도록 산정 기준 자체를 바꾸는 것이 맞는지를 다시 검토했습니다.

결국 특정 예외 케이스에만 대응하는 방식보다, 더 다양한 사용자 상황을 포괄할 수 있도록 기준 데이터를 다시 선정하고 배지 산정 방식을 재설계했어요.

이 경험 이후에는 예외 케이스를 발견하면 단순히 ‘어떻게 처리할 것인가’만 고민하지 않으려고 합니다. 지금은 예외인 케이스가 앞으로 얼마나 커질 수 있는지, 그때도 별도 분기로 관리하는 것이 맞는지, 현재의 기준이 서비스가 확장된 이후에도 유효할지를 함께 봐야 했어요.

예외를 처리하는 것에서 한 걸음 더 나아가, 그 예외가 앞으로도 예외일지를 고민하는 것. 그것 역시 기획에서 데이터를 바라보는 중요한 관점이라고 배웠습니다.

5단계.좋은 기획을 가려내는 질문

데이터 검증을 거친 시안들은 세 가지 질문을 기준으로 하나씩 좁혀갔어요.

예외 케이스까지 MECE하게 고려했나요?
일반적인 상황에서 잘 작동하는 건 기본이에요. 데이터가 없는 사용자, 경계에 걸리는 값, 신규 사용자처럼 실제 서비스에서 마주칠 수 있는 예외 상황까지 빠짐없이 고려하는 것이 제일 중요했어요.
(MECE : Mutually Exclusive, Collectively Exhaustive, 서로 겹치지 않으면서도 빠지는 경우가 없도록 나누는 것)
처음 정의한 Pain Point를 관통하나요?
앞에서 정리한 Pain Point로 다시 돌아가, 각 시안이 문제를 얼마나 본질적으로 해결하는지 비교했어요. 불편을 완화하는 수준인지, 아니면 핵심 원인을 직접적으로 해소하는 시안인지 살펴봤습니다.
얻는 효용에 비해 필요한 리소스가 합리적인가요?
좋은 아이디어라고 해서 모두 구현할 수 있는 것은 아니었어요. 개발 공수와 일정은 한정되어 있기 때문에, 사용자가 얻는 효용에 비해 지나치게 많은 리소스가 필요한 시안은 우선순위를 낮췄습니다.

이 세 가지 질문을 거치면서 한 가지를 깨달았어요. 어떤 시안을 남기고 어떤 시안을 제외할지 판단하는 과정에서 오히려 기획 의도가 더 선명해진다는 것이었어요.

또한 처음에는 여러 기획 중 ‘가장 좋아 보이는 것’을 고르는 것이 제일이라고 생각했지만, 결국 좋은 기획은 주어진 조건 안에서 최선의 선택을 만들어가는 것에 더 가까웠습니다.

마무리

SI 에이전시에서 최종 의사결정은 고객사의 몫이기에 처음에는 PM으로서 기획안을 어디까지 좁혀서 제시해야 하는지, 또 얼마나 많은 선택지를 보여줘야 하는지 고민이 많았습니다.

하지만 고객사가 최선의 선택을 할 수 있도록 판을 만드는 것은 PM의 몫입니다.

문제를 해부하고, 고객사의 운영 상황을 고려하고, 데이터로 검증하며 선택지를 좁혀갑니다. 그렇게 고객사가 만족할 수 있는 최적의 후보를 제안하는 것이 SI 에이전시 기획자의 역할이라고 생각합니다.

앞으로 더 프로페셔널한 기획자로 성장해갈 제 여정을 지켜봐주세요!