프로젝트/05
제안서 작성 시스템
규칙·검증·감사까지 설계한 문서 자동화
작성 시간의 대부분이 내용이 아니라 형식·검증에 들어간다면, 그건 자동화 대상입니다.
한 줄
공고가 나오면 구조화 → 회사자산 자동매칭 → 배점 기반 초안 → 출처·일관성 검증 → 읽기 전용 감사 → 제출 전 모의평가까지, 대외 문서 작성 전 과정을 규칙과 에이전트로 묶은 시스템입니다.
문제
정부 R&D 제안서는 형식이 정해져 있습니다. 목차, 절 번호, 표 규격, 행정 문서 위계(□ → ○ → -)가 공고마다 반복됩니다. 그런데 매번 처음부터 쓰고, 같은 실수를 반복합니다. 표 폭 합계가 맞지 않아 한글에서 깨지고, 폰트를 지정하지 않아 문서 전체가 다른 서체로 열립니다.
형식만 문제가 아니었습니다. 더 위험한 것은 내용의 근거입니다. 시장 규모·실적·특허 수치를 초안에서 무심코 지어내거나, 여러 절의 수치가 서로 어긋난 채 제출되면 평가장에서 반드시 질문을 받습니다. 작성 시간의 대부분이 내용이 아니라 형식과 검증에 들어간다는 것을 입사 초기 몇 건을 쓰면서 확인했습니다. 그렇다면 그 둘은 자동화·강제 대상입니다.
내가 한 일
문서 유형별 스킬에서 시작해, 지금은 제안서·인증 신청·조달 등록·수출 서류 등 대외 문서 작업 전체를 한 저장소·한 규칙 체계 안에서 처리하는 시스템으로 키웠습니다. 핵심은 각 단계를 Claude Code 스킬(슬래시 명령)로 만들어, 규칙을 기억하지 않고 호출만 하면 되게 한 것입니다.
- 구조화 — 공고문을 읽어(스캔본은 OCR 포함) 평가 배점·지원 자격·제출 요건으로 분해하고, 자격 미달 여부를 가장 먼저 대조합니다.
- 회사자산 자동매칭 — 기술·실적·특허·인력·TRL·사업화 자료를 정본 데이터에서 자동 조회해 요구조건 대응표를 만듭니다. 사실관계는 정본에서만 가져오고 초안에서 창작하지 않습니다.
- 배점 기반 초안 — 배점이 높은 장부터 골격을 생성합니다. 각 절에 역할을 할당하고 중복을 제약으로 검사합니다. 같은 내용이 여러 절에 반복되면 분량만 늘고 점수는 오르지 않기 때문입니다.
- 검증 2종 — 모든 수치에 출처 태그를 의무화하고, (1) 태그 누락·수치 모순을 잡는 검사와 (2) 절 사이 수치 일관성 검사를 둡니다. 0 오류가 아니면 제출본으로 올리지 못하게 막았습니다.
- 읽기 전용 감사 — 쓰기 권한이 없는 별도 감사 에이전트가 출처 태그를 원문까지 역추적해 "그 문장이 실제로 그 자료에 있는가"를 대조합니다. 형식 검사와 내용 검사를 분리했습니다.
- 제출 전 모의평가 — 평가위원 역할의 서브에이전트를 병렬로 띄워 채점하되 감점 사유만 회수합니다. 제출 전에 약점을 먼저 듣는 구조입니다.
- 한글 양식 채우기 — 제출본은 기관이 준 한글(HWPX) 양식을 그대로 채웁니다. 빈 문서에서 새로 만들면 서식이 흔들려, 양식의 칸 위치를 읽어 원고를 채워 넣는 경로를 따로 만들었습니다.
- 공고 전용 스킬 생성 — 부처와 양식이 매년 바뀌어서, 공고문과 양식을 넣으면 그 공고 전용 작성 스킬을 만들어 내는 메타 스킬을 뒀습니다.
설계 판단
검증을 부탁이 아니라 차단으로 만들었습니다. 규칙에 "반드시"라고 적어두는 것만으로는 지켜지지 않습니다. 그래서 검증이 통과하지 않으면 제출본 커밋 자체가 막히고, 주민번호·개인 연락처·계좌번호가 섞이면 커밋이 거부되도록 git 훅으로 강제했습니다. 지켜야 하는 것은 실행이 불가능하게 만듭니다.
형식 검사와 내용 검사를 다른 주체에 맡겼습니다. 자동 검사는 태그가 있는지·수치가 모순되는지(형식)를 보고, 읽기 전용 감사 에이전트는 태그가 가리키는 원문이 실제로 그 말을 하는지(내용)를 봅니다. 쓰기 권한을 뺀 이유는, 검수하는 쪽이 고치기 시작하면 검수가 아니기 때문입니다.
평가를 제출 전으로 당겼습니다. 떨어지고 나서 평가의견을 받는 대신, 평가위원 서브에이전트를 병렬로 돌려 제출 전에 감점 사유를 먼저 확인합니다. 결과를 받은 뒤에는 평가의견 원문을 그대로 기록해 다음 제안의 근거로 남깁니다.
스킬은 템플릿이 아니라 판단 규칙입니다. 빈칸 채우기 양식이 아니라 "이 절에 무엇이 들어가야 하고 무엇이 중복되면 안 되는가"를 담았습니다. 공고가 바뀌면 개별 스킬을 손보는 것보다 스킬을 만드는 스킬로 새로 찍어내는 쪽이 빠릅니다.
결과와 한계
제안서 초안 작성 시간이 크게 줄었고, 형식 오류로 인한 재작업이 사라졌습니다. 무엇보다 근거 없는 수치나 절 사이 모순이 제출본에 남는 경로를 구조적으로 막았습니다. 다만 정확한 단축 시간은 별도로 측정하지 않았습니다.
한계는 분명합니다. 첫째, 시스템은 초안과 검증까지입니다. 기술 내용의 타당성과 수요처 논리는 사람이 씁니다. 둘째, 이 체계가 채택률을 올려 주지는 않습니다. 실제로 이 시스템을 쓰고도 여러 과제에서 탈락했습니다. 자동화가 해결한 것은 형식과 검증이지 전략이 아닙니다.
소유 구분
스킬 아키텍처, 검증·감사 파이프라인, 자동화 스크립트는 제가 설계·구축한 개인 산출물입니다. 이를 사용해 작성된 제안서·신청서의 내용과 권리, 그리고 회사 정본 데이터는 각 소속 기관에 있으며, 이 페이지에는 문서 내용·회사 자료·기관 식별 정보를 포함하지 않습니다.
화면과 시연
촬영 예정 목록. 모든 화면은 회사 자료·기관명·제안서 내용이 보이지 않게 마스킹합니다.
- 영상 — 공고 투입 → 구조화 → 초안 → 검증 0 오류까지의 워크플로 배속 시연 (내용은 더미)
- 스크린샷 — 스킬(슬래시 명령) 목록 트리
- 스크린샷 — 검증 미통과 시 커밋이 차단되는 화면 (출처 태그 누락 경고)
- 스크린샷 — 생성된 HWPX를 한글에서 연 화면 — 목차·표 서식 정상 렌더 (더미 내용)