"기능부터 정의하는 기획은 토큰 낭비일 뿐입니다. 20년 차 리더가 제안하는 유저 저니(User Journey) 기반의 전략적 라이프사이클. ‘PM 젬(Gemini)'을 활용해 마케팅적 판단과 기술적 방어선을 동시에 구축하는 고해상도 기획법을 공개합니다. "
대부분의 개발자는 "뭐 만들까?"라는 질문에 "로그인 기능"부터 답합니다.
하지만 오케스트레이터는 달라야 합니다. 기능을 정의하기 전에 사용자가 겪는 문제점 분석부터 시작해야 합니다.
1. 순서의 반전: 기능보다 '여정(Journey)'이 먼저입니다
대부분의 빌더는 "뭐 만들까?"라는 질문에 기능부터 나열하려 합니다.
하지만 기능을 먼저 정하면 '기능을 위한 기능'이 생기고, 이는 토큰 낭비와 개발 공수 증가로 이어집니다.
- 유저 저니맵(User Journey Map) 우선: 사용자가 어떤 결핍을 느끼고 결과에 도달하는지 Claude와 먼저 그려야 합니다. 이 여정에서 살아남은 아이디어만이 '진짜 필요한 기능'이 됩니다.
- 기능의 생존: Journey를 먼저 그려야 '진짜 필요한 기능'만 남습니다. 기능을 정의하기 전에 사용자가 겪는 인지적 마찰(Friction)을 먼저 읽으십시오
2. 모델별 기획 오케스트레이션 전략
기획 단계별로 모델의 성향(Gemini: 구조화 vs Claude: 추론)을 적재적소에 배치하십시오.
| 단계 | 핵심 과업 | 추천 모델 | 전략적 이유 |
| 01. Ideation | 핵심 솔루션 도출 및 대안 탐색 | Claude 4.6 | 고해상도 사고와 비전형적 아웃풋 도출 탁월 |
| 02. Journey Map | 사용자 페인포인트 및 동선 설계 | Claude 4.6 | 인간의 인지적 마찰(Friction) 추론에 강점 |
| 03. Feature Def | MVP 범위 설정 및 우선순위 지정 | Gemini 3.1 Pro | 구조화, 분류 및 논리적 그룹화 역량 활용 |
| 04. Dev Planning | DB 스키마 및 API 설계 | Gemini (AI Studio) | 대규모 기술 지식 인덱싱 및 2M 컨텍스트 활용 |
| 05. Spec Review | 최종 기술 명세서(PRD) 확정 | Claude 4.6 | 논리적 모순 및 에지 케이스 최종 검토 |
3. 빌더의 필살기: '대립적 프롬프팅'
기획 단계에서 환각(Hallucination)을 줄이고 기술적 실현 가능성(Feasibility)을 검증하는 가장 강력한 방법입니다.
여기서는 '어떻게(How)'에 집중하여 시스템의 결함을 찾아냅니다
- 기술적 비판 (CTO 시각): 완성된 기획안을 Claude에게 던져 "20년 차 CTO의 시각에서 이 설계대로 구현했을 때 발생할 수 있는 데이터 정합성 문제나 성능 병목 지점을 집요하게 비판해 줘"라고 명령합니다.
- 에지 케이스(Edge Case) 해킹: 단순한 기능 작동 여부가 아니라, 예외 상황에서도 시스템이 견고하게 버틸 수 있는지 검증합니다.
- 팩트 체크: Claude가 제시한 기술적 대안이 최신 스펙에 맞는지 Gemini의 실시간 검색과 2M 컨텍스트를 활용해 최종 검증합니다
4. 비즈니스 검증: 'PM 젬(Gemini)' 가동하기
Gemini에서 맞춤형 'PM 젬'을 만들어,.기술적으로 완벽해진 기획에 '왜(Why)'와 '비즈니스 가치'라는 숨을 불어넣습니다
- 시장성 및 ROI 분석 (CPO 시각): 시장 데이터와 트렌드를 기반으로 "이 서비스가 실제 유저의 페인포인트를 해결하는가?"와 "비즈니스 모델(ROI)이 타당한가?"를 검토합니다.
- 전략적 추론: 단순히 기능을 나열하는 것이 아니라, 마케팅적 판단과 사용자의 심리적 허들을 넘어서는 '전략적 액션 플랜(Action Plan)'을 도출하는 지능형 에이전트로 활용합니다.
- 리스크 해킹: 개발자가 놓치기 쉬운 비즈니스적 구멍(Business Holes)을 AI가 전략가 모드에서 먼저 찾아내어 보완합니다.
5. 설계 자동화: API 규약을 직접 적지 마십시오
빌더가 API 호출 규약이나 기술 명세서를 직접 적고 있다면, 그건 AI 오케스트레이션의 실패 지점입니다.
- Spec Generator: 기능 정의가 완료되면 AI에게 "RESTful API 명세서와 DB 스키마를 JSON 형태로 출력해"라고 명령하십시오.
- 표준 지침(Pre-set) 주입: 기술 스택과 API 표준 가이드라인(가이드레일)만 미리 던져주면, AI가 규약에 맞는 코드를 '알아서' 뽑아내게 됩니다.
6. 요약: 지능의 인계(Handover)와 자산화
기획의 마지막 단계는 코딩 에이전트(Claude CLI)가 읽을 '시스템 프롬프트' 형태로 요약하는 것입니다.
- Handover Protocol: 모델이 바뀌어도 핵심 맥락이 기계가 읽기 좋은 형태로 전달되어야 빌더의 수동 개입이 최소화됩니다.
- 경험 자산화: 이 과정에서 사용된 성공적인 프롬프트와 결정 로그(ADR)는 반드시 저장하여 다음 프로젝트의 지능 복리 효과를 창출하십시오.
다음 편 예고: 4편: 개발 전야 - AI에게 '실행의 전권'을 넘기는 표준 지침(Pre-set) 설계
2026.04.21 - [AI 빌더] - 작동하는 AX를 설계합니다 — AX Studio by gtpmore 포트폴리오
작동하는 AX를 설계합니다 — AX Studio by gtpmore 포트폴리오
AI 도입이 작동하지 않는 이유는 구조의 문제입니다. AX 컨설턴트 gtpmore 포트폴리오 — 지식 구조화(RAG), 판단 기준 알고리즘, 자율 추론 엔진 3가지 축으로 실제 업무에 작동하는 AX를 설계합니다.
gtpmore.tistory.com
'AI 빌더' 카테고리의 다른 글
| [AI 빌더 실전 #5]실전 구현과 검증 - 에이전트 자율 구현과 루프 관리 (0) | 2026.04.15 |
|---|---|
| [AI 빌더 실전 #4]개발 전야 - AI에게 '실행의 전권'을 넘기는 표준 지침(Pre-set) 설계 (0) | 2026.04.14 |
| [AI 빌더 실전 #2]빌더의 무기고 - 왜 익스텐션을 벗어나 CLI로 가야 하는가? (1) | 2026.04.11 |
| [AI 빌더 실전 #1]바이브 코딩(Vibe Coding)의 재정의 - 느낌이 아니라 '시스템'이다 (0) | 2026.04.10 |
| [AI 빌더 실전 #0] 이 시리즈를 시작하기 전에:바이브 코딩, 삽질이 먼저였다 (0) | 2026.04.10 |
