AI 제안서가 자꾸 빠뜨리는 것들: 작성과 검토를 나누는 법

자료가 충돌할 때 무엇을 작성 기준으로 삼을까요?

이번 요구와 과거 문서의 쓰임을 구분합니다

제조기업의 사내 교육 운영 제안서를 만든다고 해보겠습니다. 아래는 역할을 나눠 설계하는 방법을 설명하기 위한 교육용 사례입니다. 작성에 사용할 자료는 고객의 제안요청서(RFP)[1], 사전 미팅 메모, 지난해 다른 고객에게 제출한 제안서입니다.

요청서에는 교육 6회, 총 600명, 종료 후 결과보고서 제출이 적혀 있습니다. 미팅 메모에는 “일부 온라인 전환 검토”와 “교육 효과도 보고 싶다”가 남아 있죠. 지난해 제안서는 교육 4회, 400명을 기준으로 작성됐습니다.

세 파일을 넣고 “참고해서 제안서를 써줘”라고 하면 어떤 문제가 생길까요. 예전 문서의 완성도 높은 문장을 가져오면서 횟수까지 따라 쓰거나, 온라인 전환을 확정된 조건으로 바꿔 쓸 수 있습니다. 겉으로는 제안서가 완성돼도 실제로 맡을 업무 범위는 달라진 셈입니다.

요청서에는 6회·600명과 완료보고가 필요합니다. 과거 문서의 조건을 가져온 초안에서 수치와 누락을 확인하는 교육용 장면입니다.

이때 목차와 말투만 고쳐달라고 하면 잘못된 조건을 더 매끄럽게 설명하게 됩니다. 먼저 세 자료가 각각 무엇의 근거가 되는지 구분해야 합니다.

담당자는 이번 요청서의 확정 요구를 기준으로 삼고, 미팅 메모의 검토 사항은 별도로 남깁니다. 과거 제안서는 구성 참고용으로 지정하죠. 이후 정식 변경 요청이 오면 기준을 갱신합니다. 단순히 날짜가 가장 최신인 파일을 우선하는 방식으로는 구두 아이디어와 확정 요구를 구별하기 어렵습니다.

요구마다 원문 위치와 확인 기준을 붙입니다

계획·생성·평가는 이 작업을 세 역할로 나누는 관점입니다. 계획은 고객이 요청한 업무와 검토 기준을 정하고, 생성은 그 기준으로 초안을 만들며, 평가는 초안이 요구를 충족했는지 원문과 대조합니다. 같은 모델에 순서대로 맡길 수도 있고, 자동화할 때 호출[2]을 나눌 수도 있습니다.

다음 단계에 넘길 자료가 역할 이름보다 중요합니다. Anthropic은 작업을 단계별 호출로 연결하는 방식을 프롬프트 체이닝[3]으로 설명하며, 문서의 개요를 검사한 뒤 본문을 쓰는 예를 듭니다. 여기서는 개요 앞에 요구와 근거를 정리하는 단계를 두겠습니다. Anthropic의 워크플로 설계 설명

실제 파일에서는 각 행에 원문 페이지나 문단 위치도 붙입니다. 예를 들어 R2가 “요청서 7쪽, 산출물 항목”으로 연결되면 나중에 AI의 요약이 맞는지 바로 확인할 수 있습니다. 담당자는 이 표를 원문과 한 번 맞춘 뒤 작성 단계로 넘깁니다.

초안 작성과 검토는 어떻게 나눌까요?

작성 단계에서는 미정인 조건도 남깁니다

작성 단계에는 요구표와 원문을 주고, 문단마다 어떤 요구를 다루는지 표시하게 합니다. 고객에게 보낼 최종본에서는 지울 수 있는 내부 검토용 표시입니다. 이렇게 하면 “교육을 체계적으로 운영합니다”라는 문장이 구체적으로 무엇에 답하는지 물을 수 있죠.

온라인 전환이 아직 검토 중인데 “교육 6회를 온라인으로 운영합니다”라고 쓰면 범위를 임의로 확정한 것입니다. 이 사례의 초안은 “교육은 총 6회, 600명 규모로 설계하며, 일부 회차의 온라인 전환은 대상과 운영 조건을 협의해 별도 제안합니다” 정도로 구분할 수 있습니다.

결과보고서도 이름만 목차에 넣어서는 부족합니다. 출결·만족도·운영 이슈를 담겠다고 제안하고, 교육 효과는 사전·사후 설문을 적용할 수 있을지 확인 질문으로 남깁니다. 제출 기한과 담당자가 자료에 없다면 내부 결정이 필요한 항목으로 표시합니다. 제안한 내용과 고객이 확정한 내용을 분리해 써야 뒤의 일정과 견적을 검토할 수 있습니다.

구조도 크게 보기 ↗

검토할 때는 요구표뿐 아니라 원문도 직접 확인합니다. 조건을 고쳤다면 그에 따라 일정과 견적도 바꿔야 하는지 살펴봅니다.

이 흐름에서 요구표는 중간 작업물입니다. 원문을 대신하는 최종 정답으로 취급하면, 표를 만들 때 빠진 요구가 작성과 검토를 그대로 통과할 수 있습니다.

검토 단계는 초안 밖의 원문을 봅니다

검토 단계에 초안만 주고 “전문가처럼 평가해줘”라고 하면 문장과 구성 중심의 의견을 받기 쉽습니다. 요구표만 추가해도 R2가 애초에 표에서 빠졌다면 결과보고서 누락을 놓칠 수 있죠. 검토할 때는 원래 요청서와 미팅 메모도 직접 읽고 초안과 대조할 수 있어야 합니다.

검토 요청도 결과물에 맞춰 좁힙니다. “원문에서 필수 요구를 다시 확인하고, 초안의 대응 위치·충족 여부·근거·고칠 내용을 적어줘. 미확정 사항을 확약한 문장도 찾아줘”라고 요청하는 방식입니다. 각 요구는 충족, 미흡, 누락으로 나누고, 판단에 필요한 정보가 없으면 확인 필요로 남깁니다.

가령 초안에 결과보고서 제목만 있다면 검토 결과는 이렇게 구체적이어야 합니다. “R2 미흡: 5절에 보고서 제출은 있지만 담당자와 제출 일정이 비어 있음. 내부 담당자를 정하고 제출 시점을 제안할 것.” 이 기준은 앞서 요구표에서 정한 제안서 완성 조건입니다. AI가 그럴듯한 지적을 썼는지보다 실제로 수정을 지시할 수 있는지가 중요합니다.

검토 단계도 먼저 시험합니다. 결과보고서 문단을 지우거나 온라인 전환을 확정한 초안을 주고 잡아내는지 보세요. 문제를 놓치면 원문이 제대로 전달됐는지, 판정 기준이 모호하지 않은지부터 확인합니다.

검사 방법도 나눌 수 있습니다. 운영표의 회차 수와 견적 수량은 표 계산으로 맞추고, “검토”가 “확정”으로 바뀐 문맥은 AI가 원문과 비교하게 합니다. 고객에게 약속할 일정과 제공 범위가 실제로 가능한지는 업무 담당자가 판단합니다. Anthropic의 평가 가이드도 코드·모델·사람의 평가를 용도에 맞게 조합하고, 모델의 판정을 사람의 판단과 맞춰볼 것을 설명합니다. Anthropic의 평가 방법 가이드

수정은 어디까지 하고 언제 멈출까요?

검토 의견을 받을 때마다 제안서 전체를 다시 쓰면 맞았던 내용도 바뀔 수 있습니다. R2 문제라면 결과보고서 문단과 관련 일정부터 고치고, 수정 전후를 남깁니다. 반대로 교육 횟수를 4회에서 6회로 바로잡았다면 인력 투입과 견적 수량도 함께 확인해야 합니다. 수정 단위는 문단 하나가 아니라 그 조건에 영향을 받는 범위입니다.

수정 후에는 지적한 문제가 해결됐는지와 기존 확정 조건이 유지됐는지를 함께 검사합니다. 고객 답변이 있어야 정할 수 있는 온라인 운영 조건은 질문 목록으로 넘기죠. 모델에게 같은 자료로 계속 생각하게 한다고 새로운 합의가 생기지는 않습니다.

처음에는 자동 수정 1회 뒤 미해결 항목을 담당자에게 넘기는 식으로 한도를 둡니다. 채팅으로 시험할 때는 담당자가 멈추고, 자동화할 때는 실행 프로그램이 실제 호출 횟수를 제한해야 합니다. Anthropic도 명확한 평가 기준과 측정할 수 있는 개선을 반복 적용의 조건으로 설명합니다. 오류가 줄었는지 본 뒤 횟수를 늘려도 됩니다. 작성·평가 반복 방식의 적용 조건

역할을 나눈 만큼 실제 부담도 줄었나요?

같은 완료 기준으로 준비·검수·수정 시간을 비교합니다

역할을 분리하면 읽고 쓰는 자료와 호출 수가 늘어납니다. 이미 단일 요청으로 충분한 초안을 얻는 업무라면 준비와 검사 단계가 추가 부담이 될 수 있습니다. 효과를 보려면 같은 자료로 한 번에 작성한 안과 역할을 나눈 안을 비교해야 합니다.

완료 기준은 동일하게 둡니다. 필수 요구 누락, 근거 없는 확약, 문서 내부 수치 불일치가 남았는지 확인하고, 그 상태에서 요구표 준비·검수·수정에 쓴 사람의 시간을 합산합니다. 자동화했다면 호출 비용과 재시도 비용도 기록합니다. 초안이 빨리 나왔어도 담당자가 원문을 다시 뒤지는 시간이 늘었다면 개선으로 보기 어렵습니다.

모델이 바뀌면 역할 분리도 다시 시험합니다

모델을 바꿀 때는 역할을 계속 유지할지도 다시 비교할 만합니다. Anthropic은 장시간 앱 개발 실험에서 Opus 4.6에 맞춰 일부 작업 분해와 중간 평가를 줄인 사례를 공개했습니다. 제안서 업무에서도 같은 효과가 나는지는 별도 확인이 필요하지만, 설계를 고정할 이유는 없습니다. 모델에 맞춰 실행 구조를 바꾼 개발 실험

원문과 완료 기준은 남기고 반복해서 누락되는 부분부터 작성과 검토를 나눠보세요. 그 분리가 사람의 최종 수정 부담을 줄일 때 운영 절차로 확장할 근거가 생깁니다.

제안서 자동화, 어떤 업체와 시작하면 좋을까요?

빠진 요구를 찾고 승인본을 관리해야 합니다

제안서 작성을 자동화할 때는 확정된 요청서를 먼저 가려내야 합니다. 초안에서 빠진 요구사항은 담당자가 확인할 수 있게 보여줘야 합니다. 업체를 찾을 때는 다음과 같은 경험을 살펴보세요.

• AI 문서 처리 업체: 문서에서 요구와 근거를 추출하는 기능을 만든 경험

• 업무 자동화 업체: 작성과 검토를 순서대로 실행하도록 만든 경험

• 맞춤 개발 업체: 수정 이력과 승인본을 관리하는 화면을 만든 경험

한 업체가 여러 분야를 함께 맡기도 하므로 실제 프로젝트 사례를 확인하는 것이 좋습니다.

문서 처리와 검토 경험을 갖춘 업체를 비교해보세요

크몽 AX에서는 여러 전문 업체의 분야와 경험을 살펴보고, 회사의 문서 형식과 검토 절차에 맞는 업체를 연결받을 수 있습니다.

민감 정보를 가린 요청서·미팅 메모·과거 제안서와 자주 틀리는 항목을 준비해보세요. 일부 요구를 뺀 초안으로 검토 기능이 누락을 찾는지 시험하고, 준비·검수·수정 시간을 함께 비교하면 도입 효과를 판단하기 좋습니다. 계약과 실제 구축은 선택한 전문 업체와 협의합니다. 크몽 AX에서 제안서 자동화 업체 찾기

용어 풀이

용어 1 제안요청서(RFP)

발주자가 맡길 업무의 목적·범위·요구 조건을 제안받기 위해 정리한 문서입니다. 이 사례에서는 교육 횟수·인원과 결과보고서 제출 요구를 확인하는 원문입니다.

용어 2 모델 호출

프로그램이 AI 모델에 입력을 보내 응답을 받는 한 번의 요청을 뜻합니다. 같은 모델에 작성과 검토를 따로 요청하면 호출도 나뉩니다.

용어 3 프롬프트 체이닝

앞 단계의 결과를 다음 단계의 입력으로 넘겨 여러 번의 AI 요청을 이어가는 방식입니다. 이 글에서는 요구와 근거를 정리한 뒤 초안을 작성하고 원문과 대조합니다.