사업계획서를 AI 3명이 쓰고, 서로 리뷰하고, 투표했다#

사업계획서는 왜 이렇게 어려운가#

창업 지원프로그램에 지원해본 사람은 안다. 사업계획서 작성이 코딩보다 어렵다.

예비창업패키지 하나만 봐도 문제 인식, 해결 방안, 성장 전략, 팀 구성, 사회적 가치까지 평가 항목이 5~7개다. 각 항목마다 배점이 다르고, 글자 수 제한이 있고, "서술식 금지"처럼 암묵적 규칙도 있다. 기술 창업자에게 "당신의 사업이 사회적으로 어떤 가치가 있는지 서술하시오"는 코딩 인터뷰보다 당혹스러운 질문이다.

AI에게 "사업계획서 써줘"라고 하면? 그럴듯한 글이 나온다. 하지만 그럴듯하기만 한 글이 나온다. 실제 데이터 없이 "급성장하는 시장"이라 쓰고, 구체적 수치 없이 "혁신적인 기술"이라 쓴다. 평가위원은 하루에 수십 편을 읽는다. 그럴듯하기만 한 글은 3초 만에 걸러진다.

그래서 접근을 바꿨다. AI 하나에게 전부 맡기는 대신, 3개 AI가 경쟁하고, 서로 검증하게 만들었다.

핵심 아이디어: 경쟁 + 상호 리뷰 + 투표#

사업계획서의 각 문항(섹션)마다 이 과정을 반복한다.

┌─────────────────────────────────────────────────┐
│              문항: "문제 인식"                     │
│                                                  │
│  Phase A: 초안 작성 (3개 AI 동시)                  │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐         │
│  │ Claude   │ │ Gemini   │ │  Codex   │         │
│  │ 초안 작성 │ │ 초안 작성 │ │ 초안 작성 │         │
│  └────┬─────┘ └────┬─────┘ └────┬─────┘         │
│       │            │            │                │
│  Phase B: 상호 리뷰 (각 초안을 나머지 2명이 채점)   │
│  ┌──────────────────────────────────────┐        │
│  │ Claude 초안 ← Gemini 리뷰 + Codex 리뷰│        │
│  │ Gemini 초안 ← Claude 리뷰 + Codex 리뷰│        │
│  │ Codex 초안  ← Claude 리뷰 + Gemini 리뷰│        │
│  └──────────────────┬───────────────────┘        │
│                     │                            │
│  Phase C: 독립 투표 (3명 각각 최고를 선택)          │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐         │
│  │ Claude   │ │ Gemini   │ │  Codex   │         │
│  │ "B가 최고"│ │ "B가 최고"│ │ "A가 최고"│         │
│  └──────────┘ └──────────┘ └──────────┘         │
│                                                  │
│  결과: Gemini 초안 채택 (2:1)                      │
│                                                  │
│  Phase D: 보완                                    │
│  투표에서 나온 개선점 반영 → 최종본                  │
└─────────────────────────────────────────────────┘

이걸 모든 문항에 대해 반복한다. 5개 문항이면 5번의 경쟁-리뷰-투표가 돌아간다.

왜 3개 AI인가#

"가장 좋은 AI 하나로 하면 안 되나?"

안 된다. 이유는 세 가지다.

첫째, 같은 주제를 다르게 해석한다. "문제 인식" 문항에서 Claude는 시장 데이터를 앞세우고, Gemini는 사용자 페인포인트 스토리를 풀고, Codex는 기술적 한계점을 파고든다. 접근 자체가 다르니 결과물도 다르다. 하나만 쓰면 하나의 시각만 얻는다.

둘째, 자기 글은 자기가 못 본다. 사람도 마찬가지다. 본인이 쓴 글의 약점은 본인이 가장 못 찾는다. 다른 AI가 리뷰하면 "이 부분은 근거가 약하다", "여기 논리가 비약됐다"는 피드백이 나온다.

셋째, 투표는 합의를 만든다. 3명 중 2명 이상이 "이게 낫다"고 하면, 그건 꽤 믿을 만한 판단이다. 1명의 판단보다 3명의 합의가 편향을 줄인다.

각 AI의 성격#

문항 성격에 따라 유리한 AI가 다르다. "문제 인식"은 Gemini의 스토리텔링이 강하고, "기술 경쟁력"은 Codex의 아키텍처 설명이 강하다. 미리 정하지 않아도 투표가 알아서 가려준다.

실제 프로세스: 5단계#

Step 0: 공고문 분석#

사업계획서의 품질은 공고문을 얼마나 정확히 읽었느냐에서 결정된다. 공고 PDF를 읽고 핵심 정보를 추출한다.

추출 항목:
├── 지원 자격 (예비/초기 구분, 업종 제한)
├── 평가 항목 + 배점 (이게 핵심이다)
├── 작성 양식 (공고가 요구하는 정확한 섹션 구조)
├── 글자 수/페이지 제한
├── 제출 서류
├── 일정 (접수 기한, 발표일)
└── 지원 금액/조건

배점이 전략을 결정한다. "문제 인식"이 30점이고 "팀 구성"이 10점이면, 문제 인식에 3배의 공을 들여야 한다. 당연한 이야기지만 실제로는 모든 항목에 비슷한 분량을 쓰는 실수를 많이 한다.

Step 1: 실데이터 수집#

여기서 이 시스템의 진짜 차별점이 나온다. 우리는 이미 서비스를 운영하고 있다. 가상의 숫자가 아니라 실제 데이터를 사업계획서에 넣을 수 있다.

3개 데이터 소스에서 자동으로 수집한다.

PostgreSQL (서비스 DB)

-- 가입자 수
SELECT COUNT(*) FROM users;

-- 월별 성장 추이
SELECT DATE_TRUNC('month', created_at) AS month,
       COUNT(*) AS new_users
FROM users
GROUP BY 1 ORDER BY 1;

-- 콘텐츠 자산 규모
SELECT COUNT(*) FROM typefy_tests;
SELECT COUNT(*) FROM blog_posts;

Google Analytics 4

• DAU/MAU 추이 (최근 90일)
• 채널별 유입 비율 (Organic, Social, Direct)
• 서비스별 페이지뷰
• 사용자 리텐션

Microsoft Clarity

• 평균 세션 시간
• 스크롤 깊이
• 디바이스 분포

이 데이터가 "우리 서비스는 매월 X% 성장하고 있다", "사용자 평균 체류 시간은 Y분이다"라는 문장의 근거가 된다. 평가위원이 "이 수치의 출처가 뭐죠?"라고 물으면 "Google Analytics입니다"라고 답할 수 있다.

Step 2: 작성 전략 수립#

공고 분석 + 실데이터를 기반으로 전략을 세운다.

배점 30점 항목 → 가장 강력한 근거 + 구체적 수치 + 시각자료
배점 20점 항목 → 핵심 논리 + 데이터 1~2개
배점 10점 항목 → 간결하게 요점만

부족한 외부 데이터는 WebSearch로 보충한다. 시장 규모, 경쟁사 분석, 트렌드 자료 등을 신뢰할 수 있는 리서치 기관에서 가져온다.

Step 3: 멀티 에이전트 오케스트레이션#

이제 본게임이다. 각 문항마다 3 AI가 경쟁한다.

Phase A: 초안 작성

Claude는 오케스트레이터로서 직접 작성하고, Gemini와 Codex는 CLI로 호출한다.

# Gemini 호출
gemini -p "$(cat context.md)
위 컨텍스트를 읽고 [문항명]을 작성하라.
서술식 금지. 도표와 표 활용. 함축적 단문." -o text

# Codex 호출
codex exec "context.md를 읽고 [문항명]을 작성하라.
결과를 orchestration/[section]/drafts/codex.md에 저장하라."

3개가 동시에 돌아간다. 같은 컨텍스트, 같은 문항, 같은 규칙. 하지만 결과는 셋 다 다르다.

Phase B: 상호 리뷰

3개 초안이 나오면, 각 초안을 나머지 2개 AI가 리뷰한다. 총 6개의 리뷰가 생성된다.

리뷰 매트릭스:
┌──────────────┬───────────────┬───────────────┐
│ 초안 작성자    │   리뷰어 1    │   리뷰어 2     │
├──────────────┼───────────────┼───────────────┤
│ Claude       │   Gemini      │   Codex       │
│ Gemini       │   Claude      │   Codex       │
│ Codex        │   Claude      │   Gemini      │
└──────────────┴───────────────┴───────────────┘

리뷰 형식은 통일했다.

1. 강점 3개 — 이 초안이 잘한 점
2. 약점 3개 — 개선이 필요한 점
3. 구체적 수정 제안 — 약점별 대안
4. 10점 만점 채점 — 공고의 평가 기준 기반

여기서 재미있는 패턴이 나타난다. Claude가 Gemini 초안을 리뷰할 때 "스토리는 좋은데 수치 근거가 부족하다"고 지적하고, Gemini가 Claude 초안을 리뷰할 때 "논리는 탄탄한데 읽는 사람이 지루할 수 있다"고 지적한다. 서로의 약점을 정확히 짚는다.

Phase C: 투표

모든 리뷰가 끝나면, 3개 AI가 각각 독립적으로 최고의 초안을 선택한다.

투표 결과 예시:
Claude: "B(Gemini)를 선택한다. 스토리텔링이 평가위원의 주의를 끌기에 효과적이다."
Gemini: "A(Claude)를 선택한다. 평가 기준에 1:1 매핑이 채점에 유리하다."
Codex:  "B(Gemini)를 선택한다. 사용자 시나리오가 문제의 심각성을 체감하게 한다."

→ Gemini 초안 채택 (2:1)

과반 득표한 초안이 해당 문항의 winner가 된다. 3표가 모두 갈리면? Claude가 결정권을 갖되, 사용자에게 알리고 확인을 받는다.

Phase D: 보완

winner가 결정되면, 투표 과정에서 나온 보완 제안을 반영한다. "Gemini 초안이 제일 좋지만, Claude가 지적한 수치 근거를 추가하면 더 좋겠다"는 식이다. 경쟁에서 진 초안의 장점을 흡수하는 단계다.

Step 4: 최종 조립#

모든 문항의 winner를 공고 양식 순서대로 합치면 완성이다.

문항별 결과 요약:
┌────────────────┬────────┬────────┬────────┬─────────┬──────┐
│ 문항            │ Claude │ Gemini │ Codex  │ Winner  │ 득표 │
├────────────────┼────────┼────────┼────────┼─────────┼──────┤
│ 1. 문제 인식    │ 7.5점  │ 8.0점  │ 7.0점  │ Gemini  │ 2:1  │
│ 2. 해결 방안    │ 8.5점  │ 7.5점  │ 8.0점  │ Claude  │ 2:1  │
│ 3. 기술 경쟁력  │ 7.0점  │ 7.5점  │ 9.0점  │ Codex   │ 3:0  │
│ 4. 성장 전략    │ 8.0점  │ 8.5점  │ 7.5점  │ Gemini  │ 2:1  │
│ 5. 팀 구성      │ 8.0점  │ 8.0점  │ 7.5점  │ Claude  │ 2:1  │
└────────────────┴────────┴────────┴────────┴─────────┴──────┘

재미있는 건, 하나의 AI가 모든 문항을 독식하지 않는다는 것이다. 문항 성격에 따라 winner가 달라진다. "문제 인식"은 스토리텔링이 강한 Gemini가, "기술 경쟁력"은 아키텍처 설명이 구체적인 Codex가, "해결 방안"은 논리 구조가 탄탄한 Claude가 이기는 패턴이 자주 나타난다.

결국 최종 사업계획서는 3개 AI의 장점만 모은 하이브리드가 된다.

모든 중간 결과물은 파일로 남는다#

이 시스템의 또 다른 특징은 투명성이다. 초안, 리뷰, 투표 내용이 전부 파일로 보존된다.

all-service-plan/startup/예비창업패키지/
├── orchestration/
│   ├── context.md                    ← 공통 컨텍스트
│   ├── problem-recognition/          ← 문항 1
│   │   ├── drafts/
│   │   │   ├── claude.md             ← Claude 초안
│   │   │   ├── gemini.md             ← Gemini 초안
│   │   │   └── codex.md              ← Codex 초안
│   │   ├── reviews/
│   │   │   ├── claude-reviewed-by-gemini.md
│   │   │   ├── claude-reviewed-by-codex.md
│   │   │   ├── gemini-reviewed-by-claude.md
│   │   │   ├── gemini-reviewed-by-codex.md
│   │   │   ├── codex-reviewed-by-claude.md
│   │   │   └── codex-reviewed-by-gemini.md
│   │   ├── votes/
│   │   │   ├── claude-vote.md
│   │   │   ├── gemini-vote.md
│   │   │   └── codex-vote.md
│   │   └── winner.md                ← 최종 채택본
│   ├── solution/                     ← 문항 2
│   │   └── ... (동일 구조)
│   └── ...
└── final-사업계획서.md                ← 모든 winner 합본

5개 문항이면 초안 15개, 리뷰 30개, 투표 15개가 생성된다. 총 60개의 파일이다.

왜 이렇게까지 남기는가? 피드백 반영 때문이다.

사용자가 "문제 인식 부분의 톤을 좀 더 공격적으로 바꿔줘"라고 하면, 해당 문항만 다시 오케스트레이션을 돌릴 수 있다. 또는 "Gemini가 winner인데, Claude 초안의 도입부가 더 나았어. 그걸로 바꿔줘"라고 하면 claude.md를 열어서 해당 부분만 가져올 수 있다. 중간 결과물이 없으면 이런 세밀한 조정이 불가능하다.

문체 규칙: "했습니다"를 쓰지 않는다#

사업계획서 작성에 하나의 핵심 규칙을 세웠다.

서술식 금지. 핵심을 타이틀로 드러낸다.

평가위원은 하루에 수십 편을 읽는다. "저희 서비스는 사용자의 구독 비용을 관리해주는 혁신적인 플랫폼입니다"라고 쓰면 눈이 미끄러진다. 대신 이렇게 쓴다.

❌ "저희 서비스는 사용자의 디지털 구독 비용을 한눈에 파악하고
   관리할 수 있도록 도와주는 혁신적인 웹 플랫폼입니다."

✅ 디지털 구독 비용 관리 플랫폼
   - 구독 서비스 자동 감지 + 월/연 비용 환산
   - MAU 2,000명, 월 평균 체류시간 4분 32초
   - 사용자 1인당 평균 관리 구독: 6.3개

함축적이고, 수치가 있고, 한눈에 들어온다. 이 규칙을 3개 AI 모두에게 동일하게 적용한다.

이 방식이 효과적인 이유#

1. 편향이 줄어든다#

AI 하나에게 맡기면 그 AI의 사고 패턴에 종속된다. Claude는 체계적이지만 딱딱할 수 있고, Gemini는 설득력 있지만 구조가 느슨할 수 있다. 3개가 경쟁하면 각각의 편향이 상호 보완된다.

2. 품질의 하한선이 올라간다#

최악의 경우도 "3개 중 제일 나은 것"이다. 하나만 쓸 때는 그날 AI의 컨디션(?)에 따라 품질이 들쭉날쭉하지만, 3개 중에서 고르면 최소 품질이 보장된다.

3. 의사결정이 투명하다#

"왜 이 문항에서 Gemini 초안을 선택했나?"에 대한 답이 투표 파일에 있다. Claude가 선택한 이유, Codex가 선택한 이유가 각각 기록되어 있다. 사용자가 동의하지 않으면 다른 초안으로 교체할 수 있다.

4. 실데이터가 설득력을 만든다#

DB, GA4, Clarity에서 뽑은 실제 지표가 사업계획서에 들어간다. "급성장하고 있습니다"가 아니라 "최근 3개월 MAU가 월평균 23% 증가했습니다(Google Analytics 기준)"가 된다. 평가위원이 가장 싫어하는 것은 근거 없는 낙관이다.

기술적으로 어떻게 돌아가는가#

이 시스템은 Claude Code의 Skills 시스템 위에서 동작한다. /bussiness-plan-creator라는 스킬 파일 하나가 전체 오케스트레이션을 정의한다.

실행 흐름:
사용자: "/bussiness-plan-creator 예비창업패키지 지원서 작성해줘"
   │
   ├── Step 0: 폴더 경로, 대상 서비스, 출력 형식 질문
   ├── Step 1: PDF 공고문 분석 + MAIN.md 읽기
   ├── Step 2: DB/GA4/Clarity 실데이터 수집
   ├── Step 3: 배점 기반 작성 전략 수립
   ├── Step 4: 문항별 3 AI 경쟁-리뷰-투표 (핵심)
   └── Step 5: 사용자 피드백 반영

Claude가 오케스트레이터다. 전체 프로세스를 관리하면서, 자기도 경쟁에 참여한다. 심판이면서 선수인 셈인데, 투표에서 1인 1표라 특별한 권한은 없다. (3표가 모두 갈릴 때만 결정권을 가진다.)

Gemini와 Codex는 각각의 CLI를 통해 호출된다. 같은 context.md를 받고, 같은 규칙을 따르고, 결과를 파일로 저장한다. 비동기로 동시에 돌리기 때문에 3개를 순차로 돌리는 것보다 빠르다.

운영하며 느낀 점#

문항마다 winner가 다르다는 게 가장 큰 수확#

처음에는 "아마 Claude가 대부분 이기겠지"라고 예상했다. 틀렸다. 문항 성격에 따라 winner가 고르게 분산된다. 이건 하나의 AI만 쓸 때는 절대 얻을 수 없는 다양성이다.

리뷰가 초안보다 가치 있을 때가 있다#

"Gemini 초안의 도입부는 좋지만, 세 번째 문단의 시장 규모 추정은 근거가 불충분하다. Statista의 2025년 보고서를 인용하면 설득력이 올라갈 것이다." 이런 리뷰가 나온다. 초안 자체보다 이 리뷰 내용이 최종 품질을 결정한다.

60개 파일이 부담이 아니라 자산이다#

처음엔 "파일이 너무 많은 거 아닌가?"라고 생각했다. 하지만 사용자가 "2번 문항을 다시 써줘"라고 할 때, 이전 초안과 리뷰를 참고해서 더 나은 결과를 낼 수 있다. 이 파일들이 없으면 매번 처음부터 다시 시작해야 한다.

비용은 감수할 만하다#

3개 AI를 동시에 돌리면 비용이 3배가 아니냐고? 맞다. 하지만 사업계획서 한 편이 수천만 원의 지원금을 결정한다. 컨설팅 업체에 맡기면 수백만 원이다. AI API 비용 몇 달러는 그에 비하면 무시할 수 있는 수준이다.

이 시스템의 한계#

솔직히 말하자.

AI가 "경험"을 만들어주진 않는다. 실제로 사업을 해본 사람의 인사이트를 대체할 수 없다. 특히 "왜 이 문제를 풀어야 하는가"에 대한 진정성은 AI가 생성할 수 없다.

면접(발표)은 별개다. 서류는 통과시킬 수 있지만, 면접에서 "이 수치는 어떻게 산출했나요?"라는 질문에 본인이 답해야 한다. AI가 써준 글의 모든 숫자와 논리를 본인이 이해하고 있어야 한다.

공고마다 맞춤 전략이 필요하다. 예비창업패키지, TIPS, 액셀러레이터는 평가 기준이 다르다. 같은 사업계획서를 여러 곳에 돌려쓰면 탈락 확률이 높아진다. 이 시스템은 공고별 맞춤 전략을 세우지만, 전략을 검증하는 건 결국 사람이다.

마무리#

정리하면 이렇다.

사업계획서를 AI 하나에게 통째로 맡기면 "그럴듯하지만 차별화 없는 글"이 나온다. 3개 AI가 경쟁하고, 서로 리뷰하고, 투표로 선별하면 "각 문항에서 가장 강한 접근법만 모은 글"이 나온다.

실제 서비스 데이터(DB + GA4 + Clarity)를 자동으로 수집해서 넣으면, "근거 없는 낙관"이 "데이터 기반 주장"으로 바뀐다. 평가위원이 보고 싶은 건 비전이 아니라 근거다.

모든 중간 결과물이 파일로 남기 때문에, 나중에 특정 문항만 다시 돌리거나, 진 초안의 장점을 가져오거나, "왜 이걸 선택했나"를 추적할 수 있다.

결국 이 시스템이 하는 일은, 혼자서는 불가능한 "쓰고 → 리뷰받고 → 고치기"의 3회 반복을 자동화한 것이다. 사업계획서뿐 아니라, 품질이 중요한 모든 글쓰기에 같은 패턴을 적용할 수 있다.

비슷한 고민을 하고 계시거나 같이 실험해보고 싶은 분은 커피챗 하고 싶습니다 ☕️

📩 ksy90101@gmail.com