Claude Code로 제안서 작성 파이프라인 만들기

공공 SI 사업 제안서 Claude Code로 RFP 분석부터 본문 작성·최종 검토까지 이어지는 파이프라인을 만들어봤다. 이틀간 실제로 돌려본 과정을 프로젝트 정보는 일반화해서 기록한다.

TL;DR: 제안서 작업 폴더를 Claude Code 프로젝트로 만들고(CLAUDE.md + prompts/ 모드별 프롬프트 5종), “RFP 분석·견적 → 목차 설계 → 섹션별 본문 작성 → 최종 검토”의 4단계 파이프라인으로 구성했다. 핵심은 단계마다 산출물을 파일로 남기고, 다음 단계가 이전 산출물을 입력으로 받게 하는 것. 제안서를 작성하기 위한 기초자료 분석과 검토 문서까지 만든 과정이다(클로드코드가 정리는 잘한다).

왜 파이프라인으로 만들었나?

제안서 작성은 “RFP를 읽고 → 요구사항을 정리하고 → 목차를 짜고 → 섹션별로 쓰고 → 원문과 대조 검토”하는 정형화된 흐름이다. 한 번의 긴 대화로 다 시키면 컨텍스트가 흐려지고 중간 결과를 재사용하기 어렵다. 그래서 각 단계를 모드별 프롬프트 파일로 분리하고, 단계별 산출물을 마크다운 파일로 남기는 구조를 잡았다. (클로드코드가 작업을 어떻게 관리하고 진행되는지도 확인고 싶었다.)

프로젝트 구조

제안작업폴더/
├── CLAUDE.md                  # 프로젝트 지침 (사업 개요, 작성 규칙, 단계 정의)
├── prompts/
│   ├── analyze_rfp.md         # 1단계: RFP 분석 + 기능×역할별 MM 견적
│   ├── design_toc.md          # 2단계: 제안서 목차 설계
│   ├── draft_section.md       # 3단계: 섹션별 본문 작성
│   ├── estimate_mm.md         # 3-1단계 : 견적 산출 규칙 (투입인원별 일정표 포함)
│   └── final_review.md        # 4단계: 원문 대조 최종 검토
├── 제안요청서/                # RFP 원문 (hwpx 등)
└── (단계별 산출물 .md)

프롬프트 초안은 먼저 손으로 대략 만들고, Claude Code에 “분석하고 검토해달라”고 시켜서 다듬었다. 이후 작업 중에 “MM 견적 단계 추가”, “투입인원별 일정표 항목 추가”처럼 프롬프트 자체를 계속 개정했는데, 각 단계를 파일로 분리해둔 덕분에 수정이 쉬웠다. (아직은 단계별로 확인이 필요하다)

4단계 파이프라인

1단계 — RFP 분석 및 견적

RFP 원문에서 요구사항을 추출해 매트릭스로 정리하고, 기능×역할별 MM(Man-Month) 견적과 투입인원별 일정표까지 산출한다. 견적을 별도 단계로 뒀다가 RFP 분석 단계에 통합했는데, 요구사항과 견적 근거가 한 문서에 있어야 대조가 쉽기 때문이다.

analyze_rfp.md의 핵심 구조 (일반화 발췌):

[mode]: analyze_rfp

[사업 고정정보] — (확정 사실이므로 재질문 없이 전제할 것)
- 발주처: {기관명} / 사업유형: 공공 SW 구축 / 기간: {n개월} / 금액: {금액}
- 평가배점: 기술 90(정량 10 + 정성 80) / 가격 10, 기술 85% 미만 협상제외
- 정성 세부배점(80): 전략·방법론(20) / 수행계획(25) / 수행기반(15) / 관리(10) / 지원(10)
- 컨소시엄: {주관사}(핵심 솔루션 영역) + {협력사}(인프라·보안)
- 핵심 리스크: 제안=계약 동일효력(과도 확약 주의), {필수 전제사항}

[rfp_text]: {RFP/과업지시서 전문 또는 요약}

위 정보를 기반으로 "1단계: RFP 분석"을 수행해줘. 출력 구조:
1. 사업 개요 요약 (제안 관점의 함의 포함)
2. 필수 요구사항 및 제외사항 — 요구사항 카테고리(SFR/PER/SER/ECR/DAR/INR/COR)별
   그룹화, 각 항목에 컨소시엄사별 대응 가능 여부·역할 명시
3. 평가항목 및 배점 구조 — [평가항목/배점/공략 포인트] 표
4. 형식·제출 요건 체크리스트
5. 주요 리스크 및 유의사항 (기술·일정·인력·계약)
6. 다음 단계 제안 (한 줄)

견적 프롬프트(estimate_mm.md)는 기능(모듈) 분해 목록과 역할(Role) 컬럼을 미리 정의해두고 표 형식을 강제하는 것이 포인트다:

[역할 컬럼 정의] PM·PMO / 아키텍트 / AI·LLM개발 / 검색·RAG / 데이터 /
  응용개발 / 연계 / 인프라 / 보안 / QA / 기술지원

[출력 구조]
1. 산정 전제·가정 (기간·등급 구성·생산성·범위 경계 명시)
2. 기능×역할별 MM 상세표 — 각 MM 소수 1자리, 산정근거·리스크 컬럼 포함
3. 집계표 — 역할별 / 수행주체별 / 총 MM
4. 투입인원별 일정표 — 역할×월 M/M 부하 스케줄 표.
   행 합계 = 역할별 총 MM 일치, 표준 S-커브 배분(착수 소수 → 개발 피크 →
   안정화 감소), PM은 상시·QA는 후반 집중

2단계 — 목차 설계

1단계 산출물을 입력으로 평가 배점표와 요구사항 커버리지를 고려한 목차를 설계한다. 이 단계가 끝나면 RFP 원문·공고문과 다시 대조하는 중간 검토를 한 번 돌렸다. 실제로 원문 대조에서 목차 누락이 발견되어 목차 프롬프트와 산출물을 함께 수정했다.

design_toc.md에서 중요한 규칙은 두 가지다 — RFP가 목차를 지정하면 그대로 준용할 것, 페이지 배분은 배점에 비례할 것:

[mode]: design_toc

[제안서 규격 — 원문 확정, 준수 필수]
- 제안서 단면 {n}p 내외 + 제안요약서 {n}p 내외(별책)
- RFP가 제안서 목차(Ⅰ~Ⅶ)를 지정 → 반드시 준용
- 요구항목 참조표(조견표) 필수 (미등록 시 비교평가 불가)

[rfp_summary]: {1단계 RFP 분석 요약 붙여넣기}

"2단계: 목차 수립"을 수행해줘.
1. 전체 구조 — RFP 지정 목차를 그대로 채택하고, 각 목차가 어떤
   평가항목·배점에 대응되는지 매핑. 배점표 세부항목이 하위 절에
   빠짐없이 대응되도록 구성
2. 장/절별 상세 목차와 페이지 배분 — [목차/절 | 제목 | 예상 페이지 |
   관련 평가항목·배점 | 핵심 메시지] 표. **페이지 배분은 배점에 비례**,
   과소·과다 시 비고에 사유 명시
3. 제안요약서(별책) 구성 — 평가위원 직관 소구 포인트 반영
4. 다음 단계 제안 (한 줄)

3단계 — 섹션별 본문 작성

목차의 장(章) 단위로 본문을 작성한다. 한 번에 전체를 쓰지 않고 “Ⅲ-2 기능요구사항 진행”, “Ⅳ 수행기반 진행”처럼 섹션 단위로 지시하는 것이 품질 관리에 유리했다. 특히 기능요구사항은 처음에 개요 수준으로 나왔는데, “각 세부 항목별 구현방안을 상세설계서 수준으로” 다시 지시해 SFR/PER/INR(기능/성능/인터페이스) 요구사항별 상세설계 문서로 재작성했다.

draft_section.md는 이전 단계 산출물을 입력 슬롯으로 받고, 공공 제안서 특유의 작성 규칙을 강제한다:

[mode]: draft_section

[target_section]: {예: Ⅲ-2. 기능요구사항}
[approved_toc]: {2단계 확정 목차와 페이지 배분 표}
[rfp_summary]: {1단계 RFP 분석 요약}
[company_profile]: {제안사 소개·유사 실적·핵심 솔루션 요약}

지정된 장/절의 본문 초안을 작성해줘. 요청 사항:
- 구조는 [목표 → 현황/문제 → 제안 내용 → 기대 효과] 순서
- 공공기관 제안서에 맞는 격식 있는 한국어(개조식 병용)
- 해당 절이 대응하는 RFP 요구사항 ID를 본문에 매핑해 추적성 확보
- 겨냥하는 평가항목을 의식해 차별성·구체성·실현가능성을 명시적으로
- 성능·수치는 목표값과 달성·측정 방법을 함께 제시하되,
  제안=계약 효력 리스크를 고려해 과도 확약 금지
- (조직도 표 위치), (아키텍처 구성도 위치)처럼 시각화 아이디어 병기
- 분량은 A4 기준 {n}페이지 상정

4단계 — 최종 검토와 파생 산출물

전체 산출물을 요구항목 조견표(요구사항 ID ↔ 제안서 목차 매핑)와 함께 최종 검토한다. final_review.md는 커버리지 전수 점검과 제안서 감점요인 점검이 핵심이다:

[mode]: final_review

[rfp_summary]: {1단계 요약} / [proposal_toc]: {확정 목차}
[proposal_text]: {작성된 본문 전체 또는 핵심 부분}

"4단계: 최종 검토"를 수행해줘.
1. 요구사항 충족 여부 — 전체 요구사항의 카테고리별 전수 커버리지 점검,
   각 항목이 제안서 어느 장/절에서 다뤄졌는지 매핑, 누락 항목은
   보완 위치·문단까지 제안
2. 평가항목 관점 — 배점 항목별 강점·약점, 약점은 협상적격 기준
   (기술 85% 미만 탈락) 방어 관점에서 우선순위를 매겨 보완 제안
3. 형식·분량·제출요건 — 지정 목차 준용, 배점=분량 균형, 조견표·
   붙임서식 누락 점검
4. 표현·객관성 — '할 수 있다/고려' 등 모호표현(=불가능 간주) 사용 여부,
   계량화 가능 항목의 수치화 여부, 주장의 입증가능성 점검
5. 전반적 개선 제안 5개 이내

검토 결과에서 파생 산출물도 자연스럽게 나온다:

고객사 확인 필요 항목 정리 → 서면 질의서 양식으로 변환
컨소시엄 구성 시 주관사-컨소사 간 협의 필요 기능 항목 정리

해보고 느낀 점

프롬프트를 파일로 관리하면 재사용된다. 다음 제안에서는 prompts/ 폴더만 복사해서 시작하면 된다. 사업마다 다른 부분은 CLAUDE.md에만 반영한다.
중간 검토(원문 대조)를 파이프라인에 넣어야 한다. 2단계 후 원문 대조에서 잡은 누락이 3단계 전체 품질을 좌우했다. 마지막에 한 번만 검토하면 되돌리기 비싸다(토큰이 얼마나 소요되는지 감잡기).
섹션 단위 진행이 긴 문서의 정답이다. “다음 단계 진행”만으로 이어갈 수 있도록 단계·섹션 정의를 프롬프트에 명시해두면, 방향 지시와 품질 판단에만 집중할 수 있다.
LLM 산출물은 초안이다. 견적 수치, 요구사항 해석은 반드시 직접 검증해야 하고, 확인 불가한 항목은 “고객사 확인 필요”로 분리해서 질의로 넘기는 흐름이 안전하다.
잘 정리되면 스킬로 만들 계획이다.