Codex vs Claude Code / Cowork — 서비스 기획자를 위한 프롬프트 전략 비교
“우리 서비스는 B2B SaaS야. 사용자들이 대시보드에서 리포트를 만드는데 불편함을 느끼고 있어. 어떻게 개선할 수 있을까?”
1
2
3
4
5
6
7
8
9
10
11
12
13
14
**올바른 패턴 — CLAUDE.md를 먼저 설계:**
```markdown
# [제품명] Product Context
## 제품 개요
[제품명]은 [타겟 사용자]를 위한 [제품 유형]이다.
## 사용자 페르소나
### [페르소나 1]: [역할], [핵심 불편점], [인용구]
## 절대 사용하지 말 것 (Immutable Rules)
- [용어A] 대신 [용어B] 사용
- 원론적 UX 개선안 금지
## 현재 집중하는 문제
- [문제 1]
- [문제 2]
CLAUDE.md는 프로젝트의 헌법이다. 임시 프롬프트를 무시하고 적용되는 불변 규칙들을 담는다. 프롬프트는 유연한 요청이지만, CLAUDE.md는 프로젝트의 최고 규범을 확립한다.
2-3. 오류 3 — 검증을 팩트 체크로 축소하기
세 번째 오류는 AI 응답 검증의 방식에 관한 것이다. 많은 기획자들이 AI의 답변을 검증할 때 사실관계부터 확인한다. “이 수치가 맞나?”, “이 회사가 실제로 이 전략을 쓰나?” 같은 방식으로. 그런데 시장 구조나 전략 방향 같은 문제에서는 사실 여부만으로는 부족하다. 어떤 전제를 깔고 그 사실을 배열했는지를 봐야 한다.
Codex의 Best Practices 공식 문서조차 이 문제를 인식하고 있다. 작업 결과에 대한 검증을 자동화할 수 있지만, 그 검증 기준 자체 — 즉 “좋은 결과”가 무엇인지 — 는 프롬프트나 AGENTS.md에서 기획자가 직접 정의해야 한다. AI는 기획자가 정의한 기준 내에서만 검증한다. 그 기준 자체가 잘못된 방향을 가리키고 있다면, 검증 결과도 잘못된 방향을 향한다.
기획자가 전제 점검을 팩트 체크로 축소하는 오류는, Codex와 Claude Code 모두에서 동일하게 나타난다. 두 도구 모두 기획자가 정의한 방향 안에서 성실하게 작동하도록 설계되어 있기 때문이다. 방향 자체를 의심하는 것은 기획자의 몫으로 남는다.
3. 도구별 프롬프트 설계 전략
이제 각 도구의 철학에 맞는 프롬프트 전략을 구체적으로 살펴본다. 핵심은 도구를 선택하기 전에, 지금 자신이 어떤 국면에 있는지를 먼저 판단하는 것이다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
┌───────────────────────────────────────────────────────────────────┐
│ 국면 판단 흐름 │
│ │
│ 지금 이 작업은... │
│ │ │
│ ┌─────┴──────────────────────────────────────────┐ │
│ │ │ │
│ ▼ ▼ │
│ 무엇을 물어야 하는지 무엇을 해야 하는지 │
│ 아직 모름 이미 알고 있음 │
│ (탐색/전제점검 국면) (실행/산출물 국면) │
│ │ │ │
│ ▼ ▼ │
│ Claude Code Codex │
│ (컨텍스트 + 사각지대 질문) (위임 명세서 방식) │
└───────────────────────────────────────────────────────────────────┘
3-1. Codex — 위임 명세서 설계의 기술
Codex에게 보내는 프롬프트는 위임 명세서다. Codex는 작업을 검증할 수 있을 때 더 높은 품질의 결과를 낸다. 이슈를 재현하는 단계, 기능 검증 방법, 린팅 및 커밋 전 체크 실행 방법을 포함해야 한다. Codex는 작업을 더 작고 집중된 단계로 쪼갤 때 복잡한 작업을 더 잘 처리한다.
서비스 기획자에게 이것이 의미하는 바는 명확하다. Codex에게 던지는 프롬프트는 다음 세 가지 요소를 반드시 포함해야 한다. 첫째, 산출물의 형태 (무엇을 만들어야 하는가). 둘째, 검증 기준 (어떻게 확인할 수 있는가). 셋째, 경계 조건 (무엇을 하면 안 되는가).
기획자용 Codex 위임 명세서 템플릿:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
작업: [정확한 작업 이름]
배경:
- 현재 상황: [현재 상태 설명]
- 해결하려는 문제: [구체적인 문제]
- 이 작업이 완료되면: [완료 기준]
산출물:
- 파일 형식: [.md / .csv / PR 등]
- 위치: [어디에 저장할 것인가]
- 형식: [구체적인 출력 형식]
검증 기준:
- 성공 조건 1: [확인 방법 포함]
- 성공 조건 2: [확인 방법 포함]
금지 조건:
- [하면 안 되는 것 1]
- [하면 안 되는 것 2]
기획 실무 적용 예시 — 경쟁사 분석 위임:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
작업: CTV 광고 플랫폼 경쟁사 분석 문서 작성
배경:
- 현재 상황: 광고 플랫폼 기획 초기 단계,
경쟁사 포지션 이해 필요
- 해결하려는 문제: Roku, Amazon, Google의
광고 수익 구조와 밸류체인의 차이가 불분명
- 완료 기준: C레벨 보고에서 질문에 답할 수 있는 수준
산출물:
- 파일: competitive-analysis.md
- 형식: 각 플레이어별 (1) 수익 구조, (2) 밸류체인
포지션, (3) 최근 전략 변화 3가지
검증 기준:
- 각 주장마다 공식 출처 (블로그 포스트 / IR 자료)
제목과 발행일 명시
- 2024년 이후 전략 변화가 반드시 포함될 것
금지 조건:
- 2023년 이전 정보만으로 구성된 분석 금지
- 링크 없이 수치만 인용하는 방식 금지
Codex 공식 Best Practices는 이 방향을 명확히 권장한다. 반복적으로 같은 프롬프트를 재사용하거나 동일한 워크플로우를 수정하고 있다면, 그것은 스킬이 되어야 한다는 신호다. 기획자가 반복적으로 수행하는 작업들 — 주간 경쟁사 업데이트, 사용자 인터뷰 요약, 릴리즈 노트 작성 — 은 모두 AGENTS.md 또는 스킬로 전환할 수 있다.
기획자를 위한 AGENTS.md 스킬 예시:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# .agents/skills/competitive-brief/SKILL.md
name: competitive-brief
description: |
특정 시장의 경쟁사 현황을 기획서에 쓸 수 있는 형태로 정리.
시장 구조 분석이나 전략 보고서 초안 작성 전에 사용.
trigger: "경쟁사", "시장 분석", "플레이어 비교"
instructions: |
1. 최근 6개월 이내 변화를 중심으로 정리
2. 각 주장마다 공식 출처 제목과 날짜 명시
3. 구조 변화 (기존 밸류체인이 흔들리는 지점) 반드시 포함
4. 금지: 원론적 설명, 2년 이상 된 수치만 인용
output_format:
- 플레이어별 현재 포지션 (2문장 이내)
- 최근 전략 변화 (공식 출처 포함)
- 구조적 긴장 지점 (누가 기존 룰을 깨고 있는가)
- 재확인 필요 주장 (출처 유형 명시)
3-2. Claude Code — 컨텍스트 설계가 프롬프트보다 먼저다
Claude Code를 사용하는 기획자에게 가장 중요한 전제는 하나다. 좋은 프롬프트는 좋은 컨텍스트에서 나온다. 아무리 정교한 프롬프트를 던져도 CLAUDE.md가 없거나 부실하면, Claude Code는 매 세션마다 다른 방향으로 달려간다.
Claude Code가 탁월한 티켓 100장을 몇 분 만에 만들어낸 것은, 그 전에 상세한 로드맵과 함께 사용자 피드백 라이브러리와 최근 사용 보고서에 접근할 수 있었기 때문이다. 컨텍스트가 결과를 만든다.
기획자를 위한 CLAUDE.md는 기술 스택 명세서가 아니다. 제품과 사용자와 기획 방향에 대한 헌법이다.
기획자를 위한 CLAUDE.md 완전 템플릿:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
# [제품명] — 기획 컨텍스트
## 제품 정의
[제품명]은 [핵심 사용자]가 [핵심 문제]를 해결하는 [제품 유형]이다.
경쟁사 대비 우리가 다른 점: [차별화 포인트 1~2개]
## 사용자 페르소나 (실제 인터뷰 기반)
### 페르소나 A — [역할명]
- 역할: [직책 및 맥락]
- 핵심 불편점: [실제 인터뷰에서 나온 표현]
- 우리 제품 사용 맥락: [언제, 어떻게 사용하는가]
- 절대 쓰지 않는 표현: [기술 용어 등]
## 현재 집중하는 문제
1. [문제 1] — 왜 지금 중요한가
2. [문제 2] — 왜 지금 중요한가
## 용어 규칙 (절대 위반 금지)
- "[용어A]"를 사용, "[대체 표현]" 금지
- "[기능명]" 대신 "[사용자 관점 표현]" 사용
## 기획 원칙 (불변 규칙)
1. 원론적 해결책 금지 ("UX를 개선한다", "사용성을 높인다" 류)
2. 기술 난이도를 무시한 제안 금지
3. 모든 기능 제안은 "어떤 사용자의, 어떤 상황에서, 왜" 구조로
## 현재 시장 인식
- 우리가 확신하는 것: [근거 있는 판단]
- 우리가 의심해야 하는 것: [전제 점검 필요한 부분]
- 최근 구조 변화: [시장에서 일어나는 변화]
## 이해관계자 컨텍스트
- [이름] — [역할], 가장 관심 있는 지표: [KPI]
- [이름] — [역할], 반드시 피해야 할 주제: [민감 사항]
CLAUDE.md가 설계된 이후에야 프롬프트가 비로소 힘을 발휘한다. 그리고 이 시점에서 Claude Code에게 던지는 가장 강력한 프롬프트 유형은 전제 점검형 질문이다.
전제 점검형 프롬프트 구조 (탐색 국면):
1
2
3
4
5
6
7
8
9
"[제품/시장/기능]에 대해 내가 현재 [접근 방식]으로
접근하고 있어.
먼저 이 접근 방식에 깔린 전제 3가지를 짚어줘.
그 전제들 중 최근 [업계 변화/사건]으로 인해
흔들리고 있는 것이 있다면 무엇인지 설명해줘.
그리고 내가 이 방향으로 계속 가면 나중에
틀렸다는 걸 알게 될 시나리오를 하나 만들어줘."
이 프롬프트의 핵심은 AI에게 답을 요청하는 것이 아니라 의심을 요청하는 데 있다. AI가 나 대신 전제를 점검해주고, 내가 지금 어떤 프레임 안에 갇혀 있는지를 먼저 드러내도록 요청한다. 이것이 Claude Code가 “전제 점검 도구”로 기능하는 방식이다.
3-3. Cowork — 탐색과 실행의 경계에서
Cowork는 채팅 인터페이스를 통해 모든 작업을 시작하며, 터미널이 필요 없다. 기획자가 Cowork를 쓸 때의 핵심 오류는 이 쉬운 인터페이스 때문에 탐색과 실행을 구분하지 않고 동일한 방식으로 프롬프트를 던진다는 것이다.
Cowork는 장시간 실행 태스크를 안정적으로 처리하고, Claude Code와 동일하게 복잡한 작업을 관리 가능한 단위로 쪼개며 진행 상황을 보고한다. 즉, Cowork는 탐색형 대화 도구가 아니라 실행 자동화 도구다. 인터페이스가 대화형이라고 해서 전제 점검이나 방향 탐색에 적합한 도구는 아니다.
Cowork를 기획 실무에서 효과적으로 사용하는 방식은 다음과 같다. 탐색 국면에서 Claude Code나 claude.ai의 채팅 인터페이스로 방향을 먼저 확인한다. 방향이 확인되면, 그 방향에 따라 반복 실행이 필요한 작업들을 Cowork에게 넘긴다.
Cowork에 적합한 작업들과 프롬프트 패턴:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# 적합한 작업 유형
- 폴더 안의 인터뷰 녹취 파일들을 읽고 공통 불편점 정리
- 여러 경쟁사 웹사이트의 가격 페이지를 수집하고
비교표 작성
- 지난 분기 사용자 피드백 파일들에서 카테고리별
이슈 분류
# Cowork 프롬프트 패턴
"[폴더경로]에 있는 [파일 유형] 파일들을 모두 읽고,
[목적]을 위해 [출력 형식]으로 정리해줘.
결과는 [저장 위치]에 [파일명]으로 저장해줘.
조건:
- [조건 1]
- [조건 2]
- 모호한 항목은 '확인 필요'로 표시하고 넘어갈 것"
각 도구는 독립적으로 작동한다. Claude.ai 대화 컨텍스트와 Cowork의 작업 메모리 사이에는 현재 네이티브 핸드오프가 없다. 이 제약을 인식하고, 탐색 결과를 파일로 저장해 Cowork에게 전달하는 “파일 기반 핸드오프” 방식을 구조화해두면 이 간극을 효과적으로 메울 수 있다.
4. 두 도구를 병렬로 쓸 때의 전제 해부 전략
가장 강력한 프롬프트 전략은 두 도구를 동시에 사용해서 서로의 전제를 해부하게 만드는 것이다. 이것은 단순한 결과 비교가 아니다. 각 도구의 응답에 내재된 프레임을 드러내는 작업이다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
┌─────────────────────────────────────────────────────────────────┐
│ 병렬 전제 해부 워크플로우 │
│ │
│ 동일한 주제 │
│ │ │
│ ┌────┴─────────────────────────────────┐ │
│ │ │ │
│ ▼ ▼ │
│ Codex Claude Code │
│ (위임 명세서 방식) (전제 점검 방식) │
│ → 구조 정리형 응답 → 전제 드러내기 응답 │
│ │ │ │
│ └──────────────┬───────────────────┘ │
│ │ │
│ ▼ │
│ 한 쪽의 응답을 다른 쪽에게 넘기기 │
│ "이 분석의 숨은 전제 3가지를 짚어줘. │
│ 그 전제들이 지금 흔들린다면 어떻게 달라지는가?" │
│ │ │
│ ▼ │
│ 내가 갇혀 있던 프레임이 보인다 │
└─────────────────────────────────────────────────────────────────┘
병렬 전제 해부 프롬프트:
1
2
3
4
5
6
7
8
9
10
11
12
13
"다음은 [Codex / 다른 AI]가 정리한 [주제] 분석이야.
[분석 내용 붙여넣기]
이 분석이 암묵적으로 깔고 있는 전제 3가지를 짚어줘.
각 전제에 대해:
1. 이 전제가 지금 시점에 유효한지 판단
2. 흔들리고 있다면 어떤 근거에서인지 설명
3. 이 전제가 틀렸다면 결론이 어떻게 달라지는지
마지막에:
- 지금 그대로 보고서에 쓰면 위험한 문장 2개
- 추가로 확인이 필요한 공식 출처 유형 (제목/발행일 기준)"
이 전략이 강력한 이유는 두 도구의 설계 철학 차이가 오히려 장점이 되기 때문이다. Codex는 태스크 위임형 구조로 현재의 사실관계를 잘 정리한다. Claude Code는 전제 점검형 구조로 그 정리가 어떤 프레임 안에서 이루어진 것인지를 드러낸다. 두 결과를 나란히 놓으면, 자신이 어떤 질문 프레임 안에 갇혀 있었는지가 보이기 시작한다.
5. 단계별 기획 업무에서의 프롬프트 설계
서비스 기획의 각 단계별로, 어떤 도구에 어떤 종류의 프롬프트를 던져야 하는지를 구체적으로 정리한다.
5-1. 시장 탐색 단계 — Claude Code가 먼저
시장을 처음 탐색하는 단계에서는 Claude Code에게 전제 점검형 프롬프트를 먼저 던져야 한다. 방향이 확인되기 전에 Codex에게 위임하면 잘못된 방향을 더 빠르게 달려가게 된다.
시장 탐색용 Claude Code 프롬프트 (4단계 구조):
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
① AI 역할 지정:
"너는 [시장]을 담당하는 서비스 기획자야.
② 나의 현재 접근 드러내기:
내가 지금 [접근 방식]으로 이 시장을 이해하려 하고 있어.
③ 전제와 사각지대 먼저:
이 접근에 깔린 전제와 내가 놓치고 있는 관점을
먼저 짚어줘.
④ 변화와 기존 구조의 충돌:
특히 최근 [업계 변화]가 기존 [구조]를 어떻게
흔들고 있는지 중심으로 정리해줘.
아직 답을 주지 말고, 내가 먼저 물어봐야 할 질문
5개를 순서대로 제시해줘."
5-2. 경쟁사 분석 단계 — 병렬 운용
방향이 어느 정도 잡혔다면, Codex에게 구조 정리를 위임하고 Claude Code에게는 그 결과의 전제를 해부하게 한다.
경쟁사 분석 Codex 위임 프롬프트:
1
2
3
4
5
6
7
8
9
10
11
12
13
작업: [경쟁사 A, B, C]의 최근 12개월 전략 변화 분석
산출물: competitive-changes.md
형식:
- 각 회사별: 변화 내용 / 발표 출처 (제목+날짜) /
이 변화가 기존 구조에 미치는 영향
검증 기준:
- 모든 주장은 공식 블로그/IR/컨퍼런스 출처 명시
- "변화 없음"도 명시적으로 기록
금지: 출처 없는 수치 사용, 2년 이상 된 정보만으로
구성된 분석
Claude Code에게 전제 해부 요청:
1
2
3
4
5
6
7
8
9
10
"위 Codex 분석을 바탕으로, 이 분석이 깔고 있는
전제 3가지를 짚어줘.
특히:
- '경쟁사 비교' 프레임 자체가 지금 시장에서
유효한지 판단
- 기존 밸류체인 구조를 '우회'하고 있는 플레이어가
있다면 누구인지
- 내가 지금 '경쟁'이라고 부르는 것이 실제로는
'구조 재편'인 사례가 있다면"
5-3. 서비스 정의 단계 — Claude Code + CLAUDE.md
신규 서비스를 정의할 때는 반드시 CLAUDE.md에 현재 이해하고 있는 사용자 컨텍스트를 먼저 담아야 한다. 그 이후에 정의 작업을 시작한다.
서비스 정의를 위한 Claude Code 프롬프트:
1
2
3
4
5
6
7
8
9
10
11
12
13
"CLAUDE.md의 [페르소나 A] 맥락을 바탕으로,
[기능 아이디어]를 서비스로 정의하려 해.
먼저 이 정의에 내가 숨기고 있는 가정들을
드러내줘:
- '사용자가 이걸 원할 것이다'는 가정
- '이 흐름이 자연스럽다'는 가정
- '이 문제가 충분히 크다'는 가정
각 가정마다:
1. 현재 근거가 있는가 (있다면 무엇인가)
2. 검증하려면 무엇이 필요한가
3. 이 가정이 틀렸을 때 서비스 방향이 어떻게 달라지는가"
5-4. 정책/기준 설계 단계 — Cowork + 제약형 프롬프트
정책이나 기준을 설계할 때는 충분한 탐색 이후에 Cowork나 Claude Code에게 제약형 프롬프트를 사용한다. 이 단계에서는 “넓게 묻는 것”이 아니라 “좁혀서 구체화하는 것”이 목표다.
정책 설계용 제약형 프롬프트:
1
2
3
4
5
6
7
8
9
10
11
12
"[서비스명]의 [정책 영역] 정책 초안을 작성해줘.
반드시 지킬 조건:
- 각 정책은 '어떤 상황에서, 어떤 이유로,
어떤 기준을 적용한다' 구조로
- '고도화한다', '유연하게 대응한다' 같은
원론적 표현 금지
- 엣지 케이스 (예외 상황) 2가지 이상 포함
- 이해관계자 충돌 가능 지점 명시
출력 형식:
정책명 / 적용 조건 / 기준 / 예외 / 이해관계자 충돌"
6. 출처 검증 — 두 도구에서 공통으로 작동하는 원칙
Codex와 Claude Code 모두에서, 출처 검증의 방식을 바꾸는 것이 결과물 품질을 높이는 데 결정적이다.
잘못된 방식:
1
"이 내용의 출처를 알려줘."
이 방식은 AI가 그럴듯한 URL을 생성하는 결과를 만든다. 특히 Codex의 경우, 태스크 완료를 위해 출처를 만들어내는 경향이 있다.
올바른 방식:
1
2
3
4
5
6
7
8
9
10
11
"이 주장들의 근거가 되는 공식 출처를 아래 형식으로 알려줘.
출처 형식:
- 출처 유형: [공식 블로그 / IR 자료 / 컨퍼런스 발표 / 논문]
- 발행 주체: [회사명 / 기관명]
- 제목 (영어 원제목): [...]
- 발행일: [YYYY-MM]
- 내가 검색할 수 있는 키워드: [...]
내가 직접 검색해서 실존 여부를 확인할 수 있어야 해.
확인할 수 없는 출처는 '출처 불명'으로 표시해줘."
이 방식의 핵심은 검증의 주체를 기획자 자신으로 되돌리는 것이다. 링크를 받는 것이 아니라, 제목과 날짜를 기준으로 기획자가 직접 확인하는 방식으로 전환한다. 이 과정이 번거로워 보여도, 보고서 방향이 틀려서 전면 재작성해야 하는 비용과 비교하면 훨씬 싸다.
7. 비판적 보완 — 이 방법론의 한계
이 글에서 제시하는 방법론은 강력하지만 몇 가지 중요한 한계가 있다.
첫째, 도구 선택 자체도 전제가 필요하다. “탐색 국면이냐 실행 국면이냐”를 판단하는 능력 자체가 도메인 이해에서 나온다. 처음 접하는 분야에서 이 판단을 내리는 것은 어렵다. 이 순환 문제에 대한 현실적인 해결책은, 처음에는 반드시 전제 점검형 프롬프트를 먼저 사용하고, 방향이 어느 정도 확인된 이후에야 태스크 위임형 프롬프트로 이동하는 것이다.
둘째, CLAUDE.md는 기획자의 편향을 고착화할 수 있다. CLAUDE.md가 프로젝트의 헌법 역할을 한다는 것은 강점이지만, 동시에 잘못된 전제가 헌법으로 굳어버리면 교정이 어렵다. CLAUDE.md를 작성할 때 “우리가 의심해야 하는 것” 섹션을 반드시 포함하고, 주기적으로 업데이트해야 하는 이유가 여기에 있다.
셋째, 병렬 AI 교차 검증의 효과는 제한적일 수 있다. Codex와 Claude Code가 서로 다른 전제를 갖는다고 해도, 둘 다 동일한 학습 데이터의 편향을 공유할 수 있다. 이 교차 검증은 기획자의 내부 프레임을 드러내는 데는 효과적이지만, AI 생태계 전반에 공통된 맹점은 드러내지 못한다. 인간 동료의 다른 관점, 현장 인터뷰, 실제 데이터가 여전히 필수적인 이유다.
넷째, 도구 자체가 빠르게 변한다. 실제 빌더들은 2026년에 Claude Code를 어려운 추론에 사용하고, Codex를 빠른 전술적 작업에 사용하며, 때로는 저비용 반복을 위해 로컬 모델을 동일 프로젝트에 함께 사용한다. 어떤 도구가 어떤 강점을 갖는지는 계속 바뀐다. 특정 도구에 고착하지 않고, 각 도구의 철학적 특성을 이해한 채로 유연하게 조합하는 능력이 장기적으로 더 중요하다.
마치며 — 질문 설계자로서의 기획자
두 도구를 아우르는 공통된 결론이 있다. AI가 성실하게 답할수록, 그 답의 전제를 먼저 의심하는 것이 기획자의 핵심 역할이 된다.
Codex는 명확히 정의된 태스크를 병렬로 위임받아 수행한다. 태스크가 잘 정의될수록 결과물이 좋아진다. 기획자의 역할은 좋은 위임 명세서를 작성하는 것이다. Claude Code는 컨텍스트를 이해한 상태에서 전제를 점검하고 방향을 탐색하는 파트너다. CLAUDE.md가 잘 설계될수록, 그리고 전제 점검형 질문이 먼저 던져질수록 결과물이 좋아진다. Cowork는 방향이 확인된 이후 반복적인 실행을 자동화하는 도구다.
세 도구 모두, 기획자가 해야 할 가장 중요한 일은 도구를 사용하기 전에 먼저 이루어진다. 어떤 국면인지 판단하고, 어떤 전제를 점검해야 하는지 확인하고, 어떤 종류의 질문을 먼저 던져야 하는지를 설계하는 것. 그 설계가 완료된 이후에야, 어떤 도구에 무엇을 위임할지가 결정된다.
AI가 넘치는 시대에 기획자의 경쟁력은 더 많이 묻는 것에서 오지 않는다. 언제 넓히고 언제 좁힐지, 언제 위임하고 언제 의심할지를 아는 것에서 온다.
작성일: 2026년 5월 4일