기획서에 대한 고민

2026 All-Day-Project (066/365)

by Jamin

좋은 제품은 좋은 문서에서 시작된다

기획서를 잘 쓴다는 건 무엇일까요. 단지 요구사항을 깔끔하게 정리하는 일이 아닙니다. 문제의 본질을 꿰뚫고, 팀이 같은 방향을 보게 만들고, 결정의 맥락이 시간이 지나도 살아있게 하는 일입니다. AI가 일상이 된 지금, 이 과정에 지능형 파트너를 더하면 어떻게 될까요.


문서의 질이 달라지고, 팀의 학습 속도가 달라집니다.

아래는 제가 팀과 함께 다듬어온 6단계 기획 프로세스입니다. AI를 어디서 어떻게 쓰는지, 각 단계에서 무엇을 남겨야 하는지를 중심으로 정리했습니다.


1단계. 문제를 정의한다 — 요구사항 수집이 아니라 문제 프로파일링


기획의 출발점은 솔루션이 아닙니다. 고통입니다.


VOC, 로그 데이터, 현장 인터뷰 등 파편화된 재료들을 AI에게 건넵니다. "이 데이터에서 사용자의 핵심 고통점과 관련 지표를 뽑아줘"라고 요청하면, 숨어있던 패턴이 수면 위로 올라옵니다. 이 결과를 바탕으로 기획자가 직접 문제를 서사적으로 정의합니다.


"사용자는 X 상황에서 Y라는 고통을 겪고 있으며, 이로 인해 Z 지표가 악화되고 있다."


이 한 문장이 기획서 전체의 닻이 됩니다. 팀이 흔들릴 때마다 돌아올 자리가 생깁니다.

아이디어를 발산할 때는 AI에게 레드팀 역할을 줍니다. "이 방향의 가장 큰 맹점은 뭐야?", "우리가 놓친 대안은?" 내 생각의 틈을 AI가 먼저 찾아주면, 팀 논의가 훨씬 빨라집니다.


2단계. 문서를 검토한다 — 정답의 선언이 아니라 가설의 검증


기획서는 완벽한 답이 아니라 최선의 가설입니다. 검토 과정이 그 가설을 다듬습니다.


AI 사전 검토부터 시작합니다. 팀에 공유하기 전, AI에게 먼저 물어보세요. "논리적 허점이 있어?", "모호한 문장은 어디야?", "빠진 엣지 케이스는?" 이 한 번의 사전 점검이 팀의 시간을 지킵니다.


PO 그룹 검토에서는 한 가지 질문을 중심에 놓습니다. "이것이 대체 가능한 수준 이상의 최선인가?" 70%의 정보가 모였다면 결정합니다. 완벽한 정보를 기다리다 잃는 시간이 더 비쌉니다.


이해관계자 검토에서는 결정의 방향성을 구분합니다. 되돌릴 수 있는 결정은 빠르게, 되돌릴 수 없는 결정은 신중하게. 그리고 어떤 결정이든 왜 그렇게 결정했는지를 반드시 기록합니다. 이 '왜'가 쌓이면 팀의 판단 기준이 됩니다.


3단계. 구현을 설계한다 — 기획, 디자인, 개발이 함께 그리는 지도


문서가 현실이 되는 순간입니다. 기획자 혼자 설계도를 그리면 안 됩니다.


AI를 활용해 컴포넌트 간 인터페이스 초안을 먼저 만든 뒤, 개발 리더와 디자인 리더가 함께 앉아 기술적 제약과 디자인 가능성을 맞춥니다. 이 자리에서 기한도 확정합니다. 합의 없는 일정은 약속이 아닙니다.


한 가지 원칙을 지킵니다. WIP(진행 중인 작업) 제한. 동시에 너무 많은 일을 벌이지 않습니다. 팀의 집중력은 희소 자원입니다.


4단계. 인수조건을 작성한다 — 모호함은 품질의 적

구현이 시작되기 전, 모든 기능의 완료 기준을 명확히 정의합니다.


형식은 GWT(Given-When-Then)입니다.

Given — 어떤 초기 조건에서

When — 사용자가 어떤 행동을 하면

Then — 어떤 결과가 나와야 하는가


AI에게 기획 내용을 주고 GWT 형식으로 인수조건을 초안해달라고 요청합니다. 이렇게 작성된 조건은 QA의 기준이 되고, 나아가 AI 에이전트가 자동 검증을 수행하는 입력값이 됩니다. 잘 쓴 인수조건 하나가 커뮤니케이션 비용 수십 번을 줄여줍니다.


5단계. 변경을 기록한다 — 맥락 없는 결과는 반쪽짜리 지식


실행 중에는 반드시 변경이 생깁니다. 중요한 건 변경 자체가 아니라 왜 바뀌었는지입니다.


JIRA, GitHub, Figma 어디든 좋습니다. 변경 사항이 생기면 즉시, 맥락과 함께 기록합니다. "디자인이 바뀌었다"가 아니라 "사용자 테스트에서 첫 화면 이탈이 높아 진입 흐름을 단순화했다"처럼요. 이 맥락이 없으면 나중에 같은 실수를 반복합니다.


QA는 4단계에서 작성한 GWT를 기준으로 수행합니다. 발견된 버그는 단순한 수정 대상이 아닙니다. 우리가 어디서 놓쳤는지를 보여주는 신호입니다. 그 신호를 기록해두면 다음 기획이 달라집니다.


6단계. 릴리즈하고 배운다 — 끝이 아니라 다음의 시작


릴리즈 후에는 두 가지를 합니다.


첫째, 릴리즈 노트를 씁니다. 무엇이 바뀌었는지, 누가 기여했는지. 작은 기록이 팀의 성취를 가시화합니다.

둘째, 회고를 기획서에 연결합니다. 처음에 세운 가설과 실제 결과를 비교합니다. 맞았으면 왜 맞았는지, 틀렸으면 어디서 어긋났는지. 이 비교가 다음 기획의 출발점이 됩니다. 이렇게 쌓인 기록은 팀 전체의 판단력을 키웁니다. 개인의 경험이 조직의 지식이 되는 순간이 여기서 생깁니다.


기획서는 혼자 완성하는 작품이 아닙니다. 팀이 함께 보고, 함께 결정하고, 함께 배우는 매개체입니다. AI는 그 과정을 더 빠르고 촘촘하게 만드는 도구이고요.


오늘 남긴 명료한 한 줄이, 내일 팀이 더 나은 결정을 내리는 재료가 됩니다.


초고: 2024.07.17

최종 업데이트: 2026.02.25 (AI-Readiness & Knowledge Compound 강화 버전)

매거진의 이전글팀의 커리어하이