PART 05-17. 아이디어를 PRD로 - Codex와 기획하기

좋은 바이브 코딩은 키보드가 아니라 문서에서 시작된다. 많은 사람이 Codex를 열자마자 "당근마켓 같은 중고거래 앱 만들어줘"라고 말한다. 그러면 Codex도 열심히 일한다. 문제는 너무 열심히 일한다는 데 있다. 없는 요구사항은 추정하고, 빠진 조건은 상상으로 메우고, 결국 개발자는 며칠 뒤 "내가 원한 건 이게 아닌데"라는 가장 비싼 문장을 말하게 된다.

이 장의 목적은 단순하다. 머릿속 아이디어를 바로 코드로 던지지 않고, Ask 모드와 리서치 도구를 이용해 PRD(Product Requirements Document, 제품 요구사항 문서)와 구현 계획으로 바꾸는 흐름을 만드는 것이다. 한마디로 정리하면 이렇다.

아이디어는 감정에서 나오고, PRD는 언어로 다듬어지며, 구현 계획은 행동으로 바뀐다.

Codex는 이 세 단계 중 특히 마지막 단계에서 강력하다. 하지만 첫 번째와 두 번째가 흐릿하면 마지막 단계도 흔들린다. 그래서 실전에서는 "코드부터"가 아니라 "문서부터"가 더 빠르다.

왜 코드보다 문서가 먼저인가

바이브 코딩이 망하는 대표적인 이유는 모델 성능이 아니라 요구사항의 모호함이다. 기능이 많아서가 아니다. 방향이 없어서다. OpenAI의 Codex 베스트 프랙티스도 복잡하거나 애매한 작업이라면 먼저 Plan 모드로 맥락을 수집하고, 질문을 받고, 더 강한 계획을 세우라고 권한다.¹ 즉, 좋은 에이전트 사용법의 출발점은 "잘 시키는 법"이지 "세게 시키는 법"이 아니다.

여기서 중요한 전환이 하나 있다. 많은 사람은 문서를 귀찮은 사전 작업으로 생각한다. 하지만 Codex 시대의 문서는 보고용 산출물이 아니다. 에이전트에게 주는 실행 계약서다. 무엇을 만들지, 무엇을 만들지 않을지, 어디까지가 MVP인지, 어떤 성공 기준을 통과해야 하는지 문서로 정리해두면 에이전트는 훨씬 덜 헤맨다.

문서가 없는 개발은 운전대 없이 내리막길을 내려가는 것과 비슷하다. 처음엔 빨라 보이지만, 끝은 대개 비슷하다.

Ask 모드는 검색창이 아니라 인터뷰어다

이 장에서 말하는 Ask 모드는 단순 Q&A 모드가 아니다. 제대로 쓰면 아이디어를 캐내는 인터뷰어에 가깝다. 사용자의 막연한 생각을 구체적인 제품 언어로 바꾸는 데 가장 먼저 써야 하는 도구다.

예를 들어 당신이 만들고 싶은 것이 "한국 직장인을 위한 식단 기록 앱"이라고 하자. 이 상태로는 아직 개발을 시작하면 안 된다. Ask 모드에서 먼저 이런 질문을 받아내야 한다.

• 누가 쓰는가

• 왜 기존 앱 대신 이 앱을 쓰는가

• 첫 주에 꼭 필요한 기능은 무엇인가

• 절대 넣지 말아야 할 기능은 무엇인가

• 성공을 무엇으로 측정할 것인가

좋은 Ask 세션은 정답을 주는 세션이 아니라, 빠진 질문을 드러내는 세션이다. Codex 커뮤니티와 실전 가이드들에서도 계획 단계에서 인터뷰형 질문 흐름과 자유형 탐색이 모두 중요하다고 본다.² 애매한 아이디어일수록 Ask 모드는 "대답 기계"보다 "반문 기계"로 써야 한다.

실제로는 이렇게 시작하면 좋다.

"나는 한국 직장인용 식단 기록 SaaS를 만들고 싶다. 아직 요구사항이 흐릿하니 먼저 내 가정을 의심하고, PRD를 쓰기 위해 꼭 필요한 질문만 우선순위대로 해줘. 답변이 끝나기 전까지 구현 제안은 하지 마."

이 프롬프트가 좋은 이유는 세 가지다. 첫째, 아직 구현 단계가 아니라는 경계를 분명히 한다. 둘째, 질문의 목적이 PRD 작성이라는 점을 못 박는다. 셋째, 모델이 섣불리 기능 목록부터 뽑는 습관을 줄인다.

아이디어를 PRD로 바꾸는 4단계 흐름

실전에서는 다음 흐름이 가장 안정적이다.

• 아이디어 탐색

• 문제 정의

• PRD 작성

• 구현 계획 분리

겉으로 보면 단순하지만, 이 순서를 지키는 것만으로 결과물의 품질이 크게 달라진다.

아이디어 탐색: 하고 싶은 것 말고 풀고 싶은 문제를 찾기

처음부터 "어떤 앱을 만들까"로 들어가면 기능 수집으로 흐르기 쉽다. 대신 "어떤 불편을 줄일까"부터 잡아야 한다. 식단 기록 앱 예시를 이어가보자.

나쁜 출발은 이렇다.

"칼로리 기록, AI 추천, 친구 초대, 배지 시스템, 랭킹, 챗봇까지 다 넣자."

좋은 출발은 이렇다.

"한국 직장인은 점심과 야근 식단이 자주 무너진다. 사진 몇 장과 짧은 메모만으로 일주일 식습관 패턴을 보게 만들자."

이 차이가 중요하다. 첫 문장은 기능 묶음이고, 두 번째 문장은 제품의 존재 이유다. PRD는 기능의 목록이 아니라 문제와 해결 방식의 문서여야 한다.

문제 정의: 누구의 어떤 순간을 바꿀 것인가

문제 정의에서는 사용자와 상황을 함께 적어야 한다. 그냥 "다이어트하는 사람"이라고 쓰면 너무 넓다. 대신 "회사 근처에서 점심을 급하게 먹고, 저녁에는 편의점으로 때우는 20~30대 직장인"처럼 실제 장면이 떠오르도록 써야 한다.

이 단계에서 Ask 모드에 시키면 좋은 일은 다음과 같다. 사용자의 하루를 쪼개고, 기존 대안의 한계를 정리하고, 정말 중요한 순간을 고르게 하는 일이다. 좋은 PRD는 기능 설명보다 사용자 문장으로 더 잘 써진다.

예를 들어 Ask 모드에 이렇게 요청할 수 있다.

"이 서비스의 핵심 사용자 2명만 정의해줘. 한국 직장인 현실에 맞게 페르소나를 만들고, 각자가 왜 기존 식단 앱을 오래 못 쓰는지 설명해줘."

이렇게 만든 페르소나는 UI 문구, 회원가입 흐름, 리텐션 기능까지 연쇄적으로 영향을 준다. 결국 PRD는 화면 설계보다 먼저 사용자 설계에서 시작한다.

PRD 작성: 무엇을 만들고 무엇을 안 만들지 명문화하기

좋은 PRD에는 화려한 템플릿보다 중요한 몇 가지 축이 있다. 여러 실전 자료가 조금씩 다르게 말하지만, 공통분모는 분명하다. 목적, 대상 사용자, 핵심 기능, 제약, 비기능 요구사항, 성공 기준, 제외 범위다.³

특히 초보자가 가장 자주 빼먹는 것이 제외 범위다. "이번 MVP에서는 하지 않음"을 쓰지 않으면 에이전트도, 사람도, 욕심도 계속 기능을 불린다. PRD에서 가장 싸게 막을 수 있는 재앙이 바로 범위 폭주다.

식단 기록 SaaS라면 PRD 초안의 핵심은 이런 식으로 잡을 수 있다.

PRD 최소 골격

1. 제품 한 줄 설명

사진과 한 줄 메모로 식습관 패턴을 빠르게 기록하고, 주간 리포트로 자기 인식을 돕는 웹 앱.

2. 타깃 사용자

점심과 야근 식단 관리가 어려운 한국 직장인.

3. 해결하려는 문제

기존 식단 앱은 입력이 귀찮아서 3일 안에 이탈한다. 사용자는 정밀한 영양 분석보다 "내가 이번 주에 얼마나 무너졌는지"를 빠르게 확인하고 싶다.

4. 핵심 기능

• 사진 업로드 1장

• 짧은 메모 입력

• 식사 시간대 자동 분류

• 주간 기록 리스트

• 주간 패턴 리포트

5. 비기능 요구사항

• 모바일 웹 우선

• 첫 화면 진입 3초 이내

• 한국어 UI 기본

• 로그인은 카카오 또는 이메일 매직 링크

6. 제외 범위

• 칼로리 자동 계산

• 운동 기록 연동

• 친구 초대와 소셜 피드

• 결제 기능

7. 성공 기준

• 첫 기록 완료까지 60초 이내

• 7일 내 재방문율 30% 이상

• 주간 리포트 열람률 50% 이상

이 정도만 있어도 Codex는 갑자기 훨씬 덜 헤맨다. 이유는 간단하다. 만들 앱이 아니라 만들지 않을 앱도 알게 되기 때문이다.

구현 계획 분리: PRD와 TODO를 섞지 말기

여기서 많은 사람이 한 번 더 미끄러진다. PRD를 쓰다가 곧바로 "먼저 Next.js 설치하고, auth 만들고, Supabase 붙이고..."로 넘어간다. 이건 자연스럽지만 위험하다. PRD와 구현 계획은 문서의 역할이 다르기 때문이다.

PRD는 무엇과 왜를 다루는 문서다. 구현 계획은 어떻게와 어떤 순서로를 다루는 문서다. 두 문서를 한 파일에 섞으면 나중에 요구사항이 바뀔 때 수정 범위가 엉망이 된다.

OpenAI는 긴 작업에 대해 세션이 끊겨도 이어갈 수 있도록 PLANS.md 같은 지속형 실행 문서를 쓰는 방식을 소개한다.⁴ 이건 아주 중요하다. PRD는 비교적 안정적으로 유지하고, 구현 계획은 살아 있는 작업 문서로 운영하는 편이 훨씬 낫다.

시장 리서치를 Codex에 시키는 법

아이디어를 문서로 바꾸려면 자기 생각만으로는 부족하다. 경쟁 서비스, 유사 패턴, 사용자의 기대치를 확인해야 한다. 이때 Ask 모드와 리서치 도구를 함께 쓰면 좋다.

다만 한 가지 원칙은 꼭 기억하자. 리서치는 기능 복붙을 위한 과정이 아니다. 차별화 지점을 찾기 위한 과정이다.

Ask 모드로 시장 가설부터 검증하기

리서치의 첫 단계는 웹에서 자료를 긁는 게 아니라, 무엇을 확인할지 질문을 세우는 일이다. 예를 들어 식단 기록 서비스라면 이런 가설을 먼저 만들 수 있다.

• 사용자는 정밀 분석보다 기록 편의성을 더 중요하게 본다.

• 국내 사용자는 소셜 기능보다 개인 리포트를 선호한다.

• 모바일 웹만으로도 MVP 검증이 가능하다.

이 가설을 Ask 모드에 던져서 검증 질문으로 바꾸게 하자.

"이 아이디어의 시장 가설을 검증하기 위한 리서치 질문 10개를 만들어줘. 사용성, 리텐션, 국내 사용자 기대치, 과한 기능 여부를 포함해줘."

이렇게 하면 리서치가 "찾아보기"가 아니라 "판단하기"로 바뀐다.

경쟁 서비스 분석은 화면보다 흐름을 보라

경쟁 서비스 리서치에서 초보자는 대개 디자인만 본다. 하지만 진짜 중요한 것은 사용자 흐름이다. 첫 진입에서 무엇을 요구하는지, 첫 기록까지 몇 번 탭하는지, 리포트는 언제 보여주는지, 유료 전환은 어느 순간에 거는지 같은 흐름을 봐야 한다.

여기서 브라우저 기반 도구나 Playwright 계열 도구를 쓰면 경쟁 서비스를 직접 열어 탐색하고, 온보딩과 핵심 플로우를 기록하게 할 수 있다. 이런 도구는 시각적인 클릭 경로를 재현하고, 화면별 차이를 비교하며, 리서치 노트를 구조화하는 데 유리하다.⁵

예를 들면 다음처럼 요청할 수 있다.

"경쟁 서비스 3개의 첫 사용자 흐름을 비교해줘. 회원가입부터 첫 기록 완료까지 필요한 단계 수, 입력 부담, 리포트 노출 시점, 유료 유도 위치를 표로 정리해줘."

이 요청의 핵심은 예쁜 화면이 아니라 행동 구조를 분석하게 만드는 것이다. 좋은 제품은 대부분 스크린샷보다 플로우가 더 영리하다.

한국형 서비스 기획에서는 현지 맥락이 더 중요하다

한국 사용자를 대상으로 하는 서비스는 해외 사례만 따라가면 어색해질 수 있다. 로그인은 카카오를 기대할 수 있고, 모바일 화면 밀도가 높아도 참는 편이며, 한글 라벨 길이 때문에 UI가 쉽게 무너진다. 또한 알림 빈도, 가격 민감도, 공유 문화도 다르다.

그래서 리서치 결과를 PRD에 반영할 때는 반드시 현지화 판단을 넣어야 한다. 예를 들어 해외 식단 앱이 "주간 리포트 이메일"을 잘 쓴다고 해도, 한국 사용자에겐 카카오 알림톡이나 앱 푸시가 더 자연스러울 수 있다. 리서치는 정답집이 아니라 참고 좌표다.

PRD는 이렇게 쓰면 잘 된다

이제 실제로 Codex와 함께 PRD를 쓰는 방식을 보자. 여기서는 한국 개발자가 실제로 만들 법한 예제로 설명하겠다.

예제 프로젝트는 다음과 같다.

프로젝트: Next.js + Supabase 기반의 "사내 회의록 요약 및 액션아이템 관리 SaaS"

이 서비스는 회의 메모를 업로드하면 요약, 담당자별 액션아이템 추출, 주간 진행 현황 정리를 제공한다. 한국 스타트업 팀이나 작은 에이전시가 쓸 법한 현실적인 주제다.

1단계: 아이디어 브리프를 먼저 만든다

PRD를 바로 쓰기 전에 10줄짜리 브리프를 먼저 만든다. 여기에는 제품의 목적, 사용자, 핵심 문제, MVP 범위만 담는다. 이 브리프는 Ask 모드에 넣을 재료이기도 하다.

예시는 이렇다.

한국 스타트업 팀을 위한 회의록 정리 SaaS를 만든다. 회의 후 노션이나 슬랙에 흩어진 메모를 붙여넣으면, 회의 요약과 액션아이템을 자동 정리해준다. 첫 번째 타깃은 5~30명 규모의 스타트업 팀장과 PM이다. MVP에서는 음성 녹음 업로드는 제외하고, 텍스트 입력만 지원한다. 핵심 가치는 회의 후 정리 시간을 줄이는 것이다.

이 정도면 이제 Codex가 질문을 던질 수 있다.

2단계: Ask 모드로 빠진 요구사항을 찾는다

이 단계에서는 "PRD를 써줘"보다 "먼저 질문해줘"가 더 좋다. 예를 들면 이런 식이다.

"이 브리프를 바탕으로 PRD를 쓰기 전에 확인해야 할 빠진 요구사항을 질문해줘. 우선순위 높은 것부터 8개만. 답을 받은 뒤 PRD 초안을 써줘."

이렇게 하면 모델이 스스로 구멍을 메우는 대신, 사용자에게 중요한 결정을 돌려준다. 이게 바로 좋은 협업이다.

3단계: 초안은 길게, 최종본은 짧게 만든다

처음부터 완벽한 PRD를 쓰려 하지 말자. 초안 단계에서는 길어도 괜찮다. 대신 최종본은 짧고 날카롭게 줄여야 한다. 에이전트가 실행에 쓸 문서는 소설보다 체크 가능한 규칙에 가깝게 써야 한다.

좋은 최종 PRD는 읽으면 바로 이런 질문에 답할 수 있어야 한다.

• 누가 쓸까

• 왜 이걸 쓸까

• 첫 버전에서 뭘 할까

• 절대 안 할 건 뭘까

• 성공 여부를 어떻게 판단할까

설명이 길다고 문서가 좋은 건 아니다. 실행 가능한 문장이 많은 문서가 좋은 문서다.

실행 계획은 별도 문서로 관리하라

PRD가 완성되면 이제 구현 계획으로 넘어간다. 이때 중요한 것은 PRD를 개발 체크리스트로 오염시키지 않는 것이다. 구현 계획은 별도 문서로 떼어야 한다.

구현 계획 문서에 꼭 들어가야 할 것

구현 계획은 기능 설명서가 아니라 작업 순서 문서다. 따라서 문체도 달라져야 한다. 좋은 구현 계획에는 보통 다음 항목이 들어간다.

• 목표와 비목표

• 단계별 작업 순서

• 영향 받는 파일과 시스템

• 테스트 방법

• 롤백 방법

• 완료 기준

Plan 모드를 다루는 실전 가이드들도 계획과 실행을 분리하고, 성공 기준과 검증 기준을 먼저 잠그는 습관이 AI 드리프트를 줄인다고 강조한다.⁶ 여기서 드리프트란, 처음 의도와 다른 방향으로 개발이 슬쩍 미끄러지는 현상이다. 에이전트 시대에는 이 드리프트를 막는 사람이 실력이 좋다.

예시: implementation-plan.md 초안

Goal

회의 메모 텍스트를 입력받아 요약과 액션아이템을 생성하고, 팀별 히스토리를 조회할 수 있는 MVP를 구축한다.

Non-goals

• 음성 파일 업로드

• 외부 캘린더 연동

• Slack 자동 전송

Steps

1. Next.js 앱 초기화 및 Supabase 프로젝트 연결

2. 팀, 회의, 액션아이템 테이블 설계

3. 이메일/소셜 로그인 구현

4. 회의 메모 입력 폼과 목록 화면 구현

5. 요약 및 액션아이템 생성 서버 액션 구현

6. 주간 히스토리 조회 화면 구현

7. 테스트 작성 및 배포 체크

Validation

• 로그인 후 회의 메모를 저장할 수 있다.

• 저장 직후 요약과 액션아이템이 생성된다.

• 이전 회의 기록을 팀 단위로 조회할 수 있다.

• 핵심 흐름의 E2E 테스트가 통과한다.

이 문서는 앞으로 작업이 진행될수록 업데이트된다. OpenAI의 ExecPlan 방식처럼 긴 작업에서는 진행 상황, 발견사항, 결정 로그까지 남겨두면 세션이 바뀌어도 흐름이 살아남는다.⁴

PRD 작성 스킬을 만들어두면 왜 편한가

이 책의 중요한 축 중 하나가 Skills다. 이 장에서도 스킬은 매우 유용하다. 매번 비슷한 방식으로 아이디어를 문서화한다면, PRD 작성 과정을 스킬로 고정해두는 편이 훨씬 낫다.

핵심은 길고 멋진 스킬이 아니라, 반복 가능한 질문 순서를 만들고 품질 기준을 고정하는 것이다.

예를 들어 PRD 작성 스킬은 이런 역할을 하게 만들 수 있다.

• 아이디어 브리프를 받으면 먼저 누락 질문을 한다.

• 답변이 모이면 PRD 초안을 작성한다.

• PRD 초안에서 제외 범위와 성공 기준을 반드시 분리한다.

• 구현 계획은 별도 문서로 분리해 제안한다.

이렇게 해두면 "PRD 작성해줘"라는 한 줄 요청이 훨씬 안정적으로 작동한다. 잘 만든 스킬은 모델을 더 똑똑하게 만드는 게 아니라, 당신의 작업 방식을 일관되게 만든다.

PRD 스킬에 넣기 좋은 규칙

아래 규칙은 특히 효과가 좋다.

• 먼저 질문하고, 바로 구현 제안하지 말 것

• 타깃 사용자와 문제 상황을 먼저 정리할 것

• 핵심 기능과 제외 범위를 분리할 것

• 성공 지표를 수치로 적을 것

• 구현 계획은 별도 문서로 분리할 것

이 다섯 줄만 있어도 결과가 훨씬 좋아진다. 기획이 흔들리는 가장 큰 이유는 모델이 아니라, 매번 다른 방식으로 일을 시키는 사용자 쪽에 있는 경우가 많다.

문서 중심 개발 흐름: 실전 워크플로

이제 이 장의 내용을 실제 흐름으로 묶어보자. 가장 추천하는 방식은 다음과 같다.

1. 아이디어 메모 작성

핵심 문제, 사용자, MVP 범위를 5~10줄로 적는다.

2. Ask 모드 인터뷰

빠진 요구사항을 질문받고 답한다. 이 단계에서는 구현 금지.

3. 리서치 수행

경쟁 서비스 흐름, 유사 도구, 사용자 기대치를 확인한다.

4. PRD 초안 작성

목적, 사용자, 문제, 핵심 기능, 비기능 요구사항, 제외 범위, 성공 기준을 정리한다.

5. PRD 압축

불필요한 설명을 줄이고 실행 가능한 문장만 남긴다.

6. implementation-plan.md 작성

단계, 테스트, 롤백, 완료 기준을 별도 문서로 분리한다.

7. 그 다음에야 Code 모드로 넘어간다

이 순서가 좋은 이유는 명확하다. Ask 모드는 방향을 잡고, 리서치는 근거를 만들고, PRD는 경계를 만들고, 구현 계획은 순서를 만든다. 그 뒤에 Code 모드로 들어가면 비로소 Codex가 잘 달린다.

한 번에 좋은 PRD를 만드는 프롬프트 예시

다음은 한국 개발자 기준으로 바로 써먹기 좋은 프롬프트다.

예시 1: 아이디어 인터뷰 시작

"한국 소상공인을 위한 예약 관리 SaaS를 만들고 싶다. 아이디어가 아직 거칠다. PRD를 쓰기 전에 내 가정을 검증할 질문 10개를 우선순위 순으로 해줘. 기능 제안은 나중에 하고, 지금은 요구사항 구멍을 찾는 데 집중해줘."

예시 2: PRD 초안 생성

"지금까지의 답변을 바탕으로 MVP 기준 PRD 초안을 작성해줘. 반드시 다음 섹션을 포함해줘: 제품 목표, 타깃 사용자, 문제 정의, 핵심 사용자 흐름, 핵심 기능, 비기능 요구사항, 제외 범위, 성공 지표, 오픈 질문."

예시 3: 구현 계획 분리

"이제 PRD는 고정하고, 별도의 implementation-plan.md 초안을 작성해줘. 목표와 비목표, 단계별 작업, 테스트 전략, 롤백 방법, 완료 기준을 분리해서 써줘. PRD의 범위를 넘는 작업은 넣지 마."

이 세 개만 잘 써도 대부분의 입문자는 실패 확률을 크게 줄일 수 있다.

흔한 실수 5가지

문서 중심 개발로 전환할 때 자주 나오는 실수도 미리 짚고 가자.

1. PRD를 광고 문구처럼 쓰는 실수

멋있게 쓰는 건 쉽다. 하지만 에이전트는 감동보다 명확성을 좋아한다. "혁신적인 경험 제공" 같은 문장은 버리고, "사진 1장과 메모 1줄로 기록 완료" 같은 문장을 남겨라.

2. 제외 범위를 안 쓰는 실수

이건 진짜 자주 터진다. 제외 범위가 없으면 AI는 친절하게 기능을 더해준다. 그 친절이 보통 일정 파괴로 이어진다.

3. 성공 기준이 없는 실수

"잘 작동하면 됨"은 성공 기준이 아니다. 첫 기록 완료 시간, 전환율, 응답 시간, 재방문율 같은 숫자가 있어야 한다.

4. PRD와 구현 계획을 한 문서에 섞는 실수

요구사항이 바뀌면 작업 순서도 같이 흔들린다. 두 문서는 목적이 다르므로 분리해야 관리가 쉽다.

5. 리서치 없이 자기 머리로만 만드는 실수

내 아이디어는 늘 그럴듯해 보인다. 시장은 냉정하다. 경쟁 서비스와 사용자 기대치를 확인하지 않으면 "내가 좋다고 생각한 기능"을 만들 가능성이 높다.

이 장의 핵심 정리

Codex를 잘 쓰는 사람은 프롬프트를 화려하게 쓰는 사람이 아니다. 작업의 형태를 잘 나누는 사람이다. 아이디어 단계에서는 Ask 모드로 질문을 받고, 리서치 단계에서는 근거를 모으고, 문서 단계에서는 PRD로 범위를 잠그고, 실행 단계에서는 구현 계획으로 순서를 나눈다.

이 순서가 잡히면 바이브 코딩은 덜 불안해진다. "느낌대로 만들기"가 아니라 "문서로 의도를 고정한 뒤 빠르게 구현하기"가 되기 때문이다. 에이전트 시대의 개발자는 코드를 가장 빨리 치는 사람이 아니라, 문제를 가장 선명하게 쓰는 사람에 가깝다.

그리고 그 선명함은 거의 항상 PRD에서 시작된다.

참고

¹Best practices - Codex | OpenAI Developers

²Plan / Spec Mode · openai/codex · Discussion #7355 · GitHub

³2026 바이브코딩 실전 가이드: PRD 작성부터 Codex·Claude Code 워크플로우까지 - AI TREARC

⁴Using PLANS.md for multi-hour problem solving

⁵Top 10 Codex Skills You Do Not Want to Miss in 2026

⁶Complete Guide to Codex Plan Mode (2026): Stop AI Drift with Plan→Execute