서비스 기획자 이력서 작성법 - 담당자는 출시 이후를 봅니다

서비스 기획자는 이력서로 실력을 보여주기 어려운 직무입니다. 개발자는 코드가 남고 디자이너는 화면이 남는데 기획자의 결과물인 정책 문서와 화면 정의서는 회사 밖으로 들고 나올 수 없습니다. 그래서 많은 기획자 이력서가 "OO 서비스 개편을 기획했습니다", "신규 기능을 출시했습니다" 같은 문장으로 채워집니다. 문제는 이 문장들이 담당자에게 거의 정보를 주지 못한다는 데 있습니다. 기획하고 출시하는 건 기획자의 기본 업무 사이클이라 그 자체로는 변별력이 없습니다. 담당자가 서류에서 찾는 건 그 사이클을 얼마나 주도적으로 돌렸는지의 흔적입니다. 서비스 기획자 이력서에서 그 흔적이 어디서 드러나는지를 정리해봤습니다.

화면 수가 아니라 문제 정의가 신호다

주니어와 미들을 가르는 첫 번째 기준은 문제 정의를 누가 했느냐입니다. 위에서 내려온 요건을 화면 정의서로 옮기는 일과 데이터를 보고 문제를 스스로 발견해 기능을 제안하는 일은 서류에서 완전히 다르게 읽힙니다. "마이페이지 개편을 기획했습니다"라고 적으면 담당자는 이 사람이 실행자였는지 제안자였는지 알 수 없습니다. 같은 일을 "결제 완료 후 이탈률이 높은 구간을 분석해 주문 내역 진입 동선을 재설계했습니다"라고 적으면 문제를 발견한 사람이 자신이라는 게 문장 안에 들어 있습니다. 담당자는 이런 문장에서 요건 수신자가 아니라 문제 소유자의 신호를 읽습니다. 근거의 출처를 적는 것도 같은 효과를 냅니다. 유저 인터뷰를 몇 건 했는지, 어떤 데이터를 봤는지, VoC에서 어떤 패턴을 찾았는지가 한 줄이라도 붙어 있으면 감이 아니라 근거로 기획하는 사람으로 읽힙니다.

출시 다음 문장이 있는가

기획자 이력서 상당수가 출시에서 문장을 끝냅니다. 그런데 담당자가 정말 궁금한 건 출시 다음입니다. 그 기능이 지표를 움직였는지, 움직이지 않았다면 무엇을 배웠는지가 서류에서 연차 대비 수준을 가르는 가장 확실한 신호입니다. 출시 후 전환율이나 리텐션 변화를 추적해 적은 이력서는 생각보다 드뭅니다. 측정 인프라가 없는 회사도 많고 출시하면 바로 다음 과제로 넘어가는 조직도 많기 때문입니다. 그래서 역설적으로 지표 변화가 적힌 한 줄이 강하게 작동합니다. "개편 후 해당 구간 이탈률이 몇 주에 걸쳐 어떻게 변했다"는 서술은 이 사람이 자기 기획의 결과를 끝까지 지켜보는 사람이라는 증거가 됩니다. 숫자가 좋지 않았던 경험도 쓸 수 있습니다. 가설이 틀렸다는 걸 지표로 확인하고 다음 개선에서 방향을 바꾼 이야기는 실패담이 아니라 검증 사이클을 돌려본 경험담으로 읽힙니다. 지금 다니는 회사에 측정 체계가 없다면 자기 기능의 지표라도 스스로 추적해 기록을 남겨두는 게 다음 이직 때의 재료가 됩니다.

협업 능력은 형용사가 아니라 장면으로

기획자 이력서에서 가장 흔하게 낭비되는 칸이 "원활한 커뮤니케이션 능력"류의 자기 평가입니다. 담당자는 이 문장을 읽지 않습니다. 협업은 기획자의 환경 그 자체라서 잘한다는 주장이 아니라 구체적인 장면이 있어야 믿습니다. 서류에서 통하는 장면은 이런 것들입니다.

• 개발 리소스가 부족한 상황에서 스코프를 어떻게 잘라 우선순위를 합의했는지
• 출시 일정과 품질이 충돌할 때 무엇을 근거로 어느 쪽을 선택했는지
• 유관 부서가 반대하던 정책을 어떤 데이터로 설득했는지

이런 서술에는 협업이라는 단어가 한 번도 안 나오지만 담당자는 협업 능력을 정확히 읽어냅니다. 문서 표준화 경험도 같은 계열의 신호입니다. PRD 템플릿이나 QA 체크리스트를 정비해 팀의 반복 실수를 줄였다는 경험은 혼자 일 잘하는 단계를 지나 팀의 작업 방식을 만드는 단계로 넘어갔다는 근거가 됩니다.

신입과 주니어는 역기획으로 깊이를 증명한다

경력이 없거나 짧다면 보여줄 지표도 협상 장면도 없습니다. 이때 포트폴리오 대신 흔히 쌓는 게 앱 화면을 캡처해 나열한 분석 문서인데 화면 소개 수준의 분석은 몇 개를 쌓아도 담당자의 판단을 바꾸지 못합니다. 통하는 건 깊이입니다. 기존 서비스 하나를 골라 역기획 문서를 쓰되 화면 뒤에 있는 정책까지 파고드는 방식입니다. 쿠폰 중복 적용은 어떻게 막았는지, 환불 중 재주문이 들어오면 어떻게 처리되는지 같은 엣지 케이스를 추정하고 그 설계 의도를 해석한 문서는 화면 캡처 열 장보다 강하게 작동합니다. 기획자의 일이 화면 그리기가 아니라 정책 설계라는 걸 이해하고 있다는 증거이기 때문입니다. 직접 만들어보는 것도 이제 현실적인 선택지입니다. 노코드 도구나 AI 코딩 도구로 작은 서비스를 출시하고 기획 의도부터 출시 후 지표까지의 사이클을 기록하면 회사 경력 없이도 검증 사이클을 완주해봤다는 증명이 됩니다. 규모는 작아도 됩니다. 담당자가 보는 건 사용자 수가 아니라 사이클이 닫혀 있는지입니다.

정리하면

서비스 기획자 이력서에서 담당자가 확인하는 건 기획서를 몇 장 썼는지가 아니라 문제 정의를 소유했는지, 출시 후 지표까지 닫았는지, 이해관계 조정을 구체적인 장면으로 보여줄 수 있는지입니다. 경력이 짧다면 정책 깊이가 있는 역기획이나 완결된 사이드 프로젝트 사이클이 그 자리를 대신합니다. 이 재료들은 대부분 일하는 중에는 기록되지 않고 이직을 결심한 뒤에는 복원이 안 됩니다. 자기가 낸 제안과 출시 후 숫자를 평소에 적어두는 습관이 결국 이력서의 원천이 됩니다. GridResume의 커리어 기록에 그때그때 남겨두면 이력서로 옮길 때 문제 정의부터 결과까지의 흐름을 다시 짜는 일이 훨씬 가벼워집니다.