프롬프트 하나로는 부족하다 — 보고서 작성 AI를 스킬화한 과정

보고서 작성 AI의 스킬화 과정

한줄 요약

보고서를 AI로 자동화하려다 발견한 것: 빠른 초안보다 중요한 것은 기준과 게이트였다. 6개 스킬 6단계 라이팅 하네스를 통해 품질을 먼저 세운 뒤, 그 다음에 자동화를 붙였다.

바쁘시면 이것만 읽어도 돼요:

AI 초안은 최종본이 아니다. 그 앞에 5단계가 더 있다.
자동화보다 품질이 우선이면, 구조가 단순해진다.
1건을 제대로 처리하는 시스템이 100건을 빠르게 처리하는 시스템보다 더 안정적이다.
기준 없는 자동화는 오류 확산이다.
검증 게이트를 통과하지 못하면 자동화하지 않는다.

이런 분들께 도움돼요

AI로 업무 자동화를 하려는데 결과 품질이 흔들리는 분
프롬프트를 여러 번 고쳐도 원하는 결과가 안 나오는 분
보고서·문서 작성을 자동화하려는 팀 리더
"AI는 쓸 수 있는데 품질을 못 믿겠다"고 느끼는 분
반복 업무를 체계화하되 품질을 지키고 싶은 분

AI 초안의 한계와 단순 자동화의 위험

AI 초안의 한계

AI에게 "보고서 써줘"라고 하면 그럴듯한 문장은 생긴다. 하지만 실무 보고서에서 필요한 것은 그럴듯함이 아니다.

실제 문제:

❌ 원문 구조가 무너짐 (산업 표·수치·기관명)
❌ 근거가 추적 불가능 (어디서 이 정보가 나왔나)
❌ 수치·일정이 틀림 (검증 단계 없음)
❌ 문체가 내 보고서와 다름 (하이라키·표현·결론 형식)
❌ 결재권자가 설명할 수 없는 구조 (논리 흐름이 위험)

초안 1건을 받으면, 검수에 초안 작성 시간보다 훨씬 오래 걸린다.

게다가 검수자(나 또는 부장님)가 "이게 뭔가 이상한데"를 찾기 어렵다.

단순 자동화의 위험

"빨리 초안을 쓰는 것"을 목표로 하면, 이런 상황이 반복된다:

프롬프트 던짐
초안 검수
문제 발견
리비전 프롬프트
재초안
다시 검수
또 다른 문제 발견

속도만 빨라지고 품질이 안 따라온다. 더 나쁜 것은, 배치로 여러 건을 돌리면 오류가 더 빠르게 확산된다는 것이다.

품질을 우선하는 설계 원칙

품질을 먼저 세운다

이 프로젝트에서 가장 먼저 정한 원칙은 "자동화보다 품질이 우선"이라는 점이었다.

보고서 작성은 단순 반복업무처럼 보이지만, 실제로는:

원문 구조 보존
근거 추적 가능성
수치·일정·기관명 검증
문체 일관성
결재권자 입장에서의 설명 가능성

을 포함하는 고품질 판단 업무에 가깝다.

그래서 처음부터 대량 자동화를 목표로 하지 않았다.

대신 품질을 확인할 수 있는 단계와 게이트를 먼저 만들었다. 자동화는 그 다음 문제였다.

1건을 제대로 처리하는 시스템

보고서는 "빠르게 나온 글"이 아니라 "검증된 근거를 담은 문서"다.

따라서:

초안 단계에서 자동화를 전면에 두지 않음
대신 1건을 제대로 처리하고, 원문과 대조하고, 통과한 결과만 다음 단계로 넘기는 구조 설계
기준 없이 빨라지는 것은 효율이 아니라 리스크 확대

AI가 따를 기준의 중요성

AI에게 "보고서 써줘"라고 하면 결과물이 나온다.

하지만 실무 보고서에서 중요한 것은 결과물 자체가 아니라, 그 결과물이 다음 질문에 답할 수 있느냐다:

이 문장은 어떤 자료에서 나왔는가?
이 수치는 검증됐는가?
이 목차는 문서 유형에 맞는가?
이 결론은 결재권자가 판단할 수 있는 형태인가?
이 문체는 내가 평소 쓰는 보고서와 일관되는가?
이 내용은 부장님이 처장님께 설명할 수 있는가?

따라서 프라이드의 스킬은 결과물을 바로 만드는 구조가 아니라,

AI가 따라야 할 기준·절차·검증 게이트를 먼저 정의하는 방식으로 설계했다.

빠른 초안은 중간 산출물일 뿐

이 프로젝트에서 초안은 최종본이 아니다.

초안은 6단계 중 4단계에 불과하다.

pride-report-writing 기준으로 보면, 실제 보고서 작성 단계는:

1단계: 의도 합의 (사용자와 grill-me 대화)
  ↓
2단계: 자료 조사 (Wiki + 외부 + 팩트체크)
  ↓
3단계: 템플릿 참조 + 목차 제안
  ↓
4단계: 초안 작성 (AI)
  ↓
5단계: 검토 + 페르소나 크리틱
  ↓
6단계: 승인된 수정사항만 patch → 최종본 확정

"AI 초안"은 전체 공정의 한 지점일 뿐이다.

최종본은 검토와 승인, 수정 게이트를 통과한 뒤에야 만들어진다.

품질 게이트를 통과하지 못하면 자동화하지 않는다

자동화는 품질이 안정된 뒤에 붙일 수 있다.

품질이 불안정한 상태에서 자동화를 먼저 붙이면, 오류가 더 빠르게 확산된다.

그래서 이 시스템은 다음 상황에서는 자동화를 멈춘다:

❌ 원문 구조가 불명확할 때
❌ 작성 주체가 불분명할 때
❌ 표·박스·붙임 구조가 깨졌을 때
❌ 수치·일정·기관명 검증이 안 됐을 때
❌ 초안이 목적과 다르게 흘렀을 때
❌ 결재권자 관점에서 설명 가능성이 떨어질 때

이 경우 결과물을 방어하지 않고, 이전 단계로 되돌린다.

자동화보다 중요한 것은 되돌릴 수 있는 구조다.

보고서를 이해하는 시스템 만들기

폴더 9단계 — 보고서 작성 지식 파이프라인

이 프로젝트는 보고서 작성 과정을 하나의 지식 파이프라인으로 설계했다.

핵심은 "AI가 바로 보고서를 쓰는 것"이 아니라,

원문 보고서가 다음 보고서 작성에 재사용 가능한 자산으로 바뀌는 흐름을 만드는 것이었다.

원문 정제본 계층

HWP/HWPX/PDF/DOCX 원본을 Markdown으로 정제한다.

원문 문장·표·붙임·하이라키 보존
11_My_Reports: 내가 작성한 보고서
12_Reference_Reports: 외부·정부·타기관 참고 보고서
품질 기준: 원문 구조와 주요 문장 누락 없음, 표의 행·열 의미 보존

작성 양식 계층

기존 보고서에서 문체·구조·하이라키·표 사용 방식을 추출한다.

21_회사공통: 보편 규칙 (YAML, 제목, 개조식, 표)
22_부서별: 도메인 지식 (약어, 프로젝트명, 부서 이력)
23_문서종별: 문서 유형별 논리 흐름 (검토, 계획, 현황)
24_개별양식: 사용자 보고서 문체와 시그니처 (개인 문체 보호 구역)

역할: 새 보고서 작성 시 형식과 문체의 기준 제공

보고서별 의미 분석 계층

10_report의 정제본을 전체 독해해서 의미 단위로 재구성한다.

단순 요약이 아니라:

문서 요지 (3~5줄)
문서 구조 (핵심주장, 문제인식, 근거, 제안, 평가)
개념·개체·분석·사실·의사결정 후보로 분해

역할: 보고서 한 건을 다음 단계에서 쓸 수 있는 의미카드로 변환

재사용 지식 계층

30_Extracts의 의미카드를 위키 페이지로 승격한다.

개념, 개체, 분석, 사실, 판단 5개 물리 폴더만 사용
같은 개념·개체는 중복 페이지 생성 금지
source 연결로 원천 추적 가능

역할: 다음 보고서 작성 시 검색·참조 가능한 지식베이스

작업·검수 계층

실제 보고서 작성, 인박스 변환, 템플릿 분석, 검수 작업이 이루어지는 공간이다.

단계별 산출물:

01_brief.md (1단계: 의도 합의)
02_research_wiki.md (2단계-A: Wiki 조사)
03_outline_proposal.md (3단계: 목차 제안)
04_draft_* (4단계: 초안)
05_review_factcheck.md (5단계: 검토·팩트체크)
06_final.md (6단계: 최종본)

역할: 자동 생성 결과를 바로 최종본으로 두지 않고, 중간 검수와 승인 흐름을 남기는 작업 공간

개정 이력 계층

최종본 이후 수정 요청과 검수본을 보관한다.

초안·검수본·최종본을 차분 대조해 반영
어떤 수정이 언제 들어갔는지 추적 가능

역할: 보고서가 한 번에 끝나지 않는다는 실무 현실 반영

최종 산출물 계층

최신 최종본 1개만 flat하게 유지한다.

폴더를 복잡하게 만들지 않음
사용자가 실제로 확인하고 배포할 최신본

역할: 현재 결재용·배포용 최신본 보관

처리 완료 원본 보관 계층

원문 파일과 처리 완료된 원본을 보관한다.

10_report 정제본 하단에서 원본을 추적할 수 있게 연결
나중에 원문 대조가 필요한 경우를 대비

역할: 추적성 확보

설계·운영 기준 계층

설계문서, 운영 스크립트, 백업, 수량 로그, 품질 기준을 보관한다.

역할: 파이프라인 자체의 기준과 변경 이력 관리

스킬 6개의 역할과 단계

이 구조 위에서 6개 스킬이 각 단계를 담당한다.

각 스킬은 "자동화 기능"이 아니라 "품질 게이트" 관점으로 설계했다.

원문 정제 게이트

역할: 원본 문서를 정제된 Markdown으로 변환하되, 구조를 먼저 확인한다.

1단계: 파일 확인 및 분류
  - 원본 1건 선택 (배치 금지)
  - 작성 주체 판단 (내 보고서 vs 참고)
  - 문서유형 태깅
2단계: 원문 추출 및 준비
  - 페이지 이미지 생성
  - 텍스트 추출 (후보)
  - 표 구조 확인
3단계: Markdown 초안
  - 페이지 이미지로 전체 구조 확인
  - 텍스트 후보를 구조에 매칭
  - (텍스트부터 시작하지 않음)
4단계: 프라이드 검수
  - 원문 대조 (구조 무너지지 않았나)
  - 표·붙임·참고박스 보존 확인
  - 수치·기관명·일정 오류 확인
5단계: 승격 + 동기화
  - 검수 통과본만 10_report에 저장
  - 원본은 80_Archive로 이동
  - GDrive 동기화 및 원격 검증

핵심: 구조 우선 + 1건 단위 + 원문 대조 검수

의미 분석 게이트

역할: 보고서를 전체 독해해서 다음 보고서 작성에 쓸 수 있는 의미카드로 분해한다.

1단계: 전체 독해
  - 핵심 주장, 문제 인식, 근거, 제안, 평가 파악
2단계: 문서 구조 파악
  - 요지 (3~5줄)
  - 구조 5요소 정리
3단계: 의미카드 분해
  - 개념 (원자 단위)
  - 개체 (부처, 사업, 기관)
  - 분석 (문제 구조, 원인)
  - 사실 (수치, 일정, 예산)
  - 의사결정 (채택 방식)
4단계: 품질 검수
  - 금지어 제거 ("후속처리", "식별되는")
  - 오분류 보정
  - 원문 누락 확인

핵심: 단순 요약 아님 + 보고서 논리 보존 + 재사용 가능한 카드

템플릿 표준화 게이트

역할: 기존 보고서(11_My_Reports 31건)를 분석해 문체·구조·하이라키 기준을 정립한다.

Step 0: 3축 × 4주체 분석 (신규, v1.3)
  - Axis 1: 형식 (헤딩, 번호체계, 부호, 표)
  - Axis 2: 논리 (섹션 시퀀스, closer 라벨)
  - Axis 3: 문체 (종결어미, 연결사, 도메인 어휘)
  - 4주체: 공통 / 부서별 / 문서종별 / My(사용자)
Step 1: 백업
  - 기존 20_Templates 전체 복사
Step 2: 템플릿 갱신
  - 21_회사공통, 22_부서별, 23_문서종별, 24_개별양식 작성
  - 4계층 책임 분리 준수
Step 3: 자기검증
  - 27개 충돌 룰 검사
Step 4: 동기화
  - GDrive 업로드 + 검증

핵심: 문체 복제 기준 + 하이라키 체계화 + 실측 데이터 기반

위키 승격 게이트

역할: 30_Extracts 의미카드를 40_Wiki 지식 페이지로 정규화한다.

1단계: 위키 오리엔테이션
  - 기존 schema, index, log 확인
  - 중복 페이지 검색
2단계: source 연결
  - 30_Extracts를 직접 source로 사용
  - 중복 복사 금지
3단계: 페이지 생성/갱신
  - 개념 → 개념/ 폴더
  - 개체 → 개체/ 폴더 (+ entity_category)
  - 분석 → 분석/ 폴더 (+ analysis_subtype)
  - 사실 → 사실/ 폴더 (+ fact_category)
  - 판단 → 판단/ 폴더
4단계: wikilink 연결
  - 신규 페이지 2개 이상 링크
5단계: index/log 갱신
  - 페이지 등재
  - 인제스트 기록 추가
  - 동기화

핵심: 재사용 가능한 카드 + 정규화 + 링크 기반 지식망

라이팅 하네스 (핵심 스킬)

역할: 1단계 의도 합의부터 6단계 최종 확정까지 검증된 보고서를 작성한다.

1단계: 의도 합의 (대화형 grill-me 루프)
  - Q1~Q8 개별 질문 (의존 순서)
  - 각 Q마다 추천 + 근거 + 대안
  - 단축모드 폐기, 품질 우선
  - 1단계 잠금 후 2단계로
2단계: 자료 조사 (3가지 병렬)
  - 2-A: 내부 40_Wiki 최우선 조사
  - 2-B: 범용조사 방식 (조사질문→출처신뢰도→1차자료→쟁점정리)
  - 2-C: 수치·내용 사전 팩트체크
3단계: 양식 참조 + 목차 제안
  - 20_Templates 4계층 참조
  - 사용자 승인 전까지 작성 금지
  - 붙임 추천 동시 제시
4단계: 초안 작성
  - Claude Opus 서브에이전트 또는 프라이드 직접
  - 축D(내용 통찰) 체크리스트: 배경 트리거, 시사점 인과, 결과 액션, 결론 판단근거
5단계: 프라이드 검토
  - 5-A~C: 양식(축A)·논리(축B)·내용(축D) 검토
  - 5-D: 페르소나 크리틱 (부장님 5체크 + Q2최종독자)
  - 수정지시 구체화 (본문발췌+문제+구체수정)
  - 사용자 승인 후에만 6단계 진입 (수정본 자동생성 금지)
6단계: 프라이드 직접 최종 확정
  - 04_draft_* → 06_final.md 복사
  - 사용자가 승인한 수정 후보만 patch
  - 양식 자가검증 (번호·부호·헤딩 분리)
  - 70_Output 승격

핵심: 의도→조사→게이트→초안→검토→승인→최종 / AI는 1단계 아니라 4단계

파일 변환 게이트

역할: 승인된 Markdown을 DOCX/HWPX/PDF로 변환한다.

1단계: 입력 확인
  - 변환할 Markdown 파일 확정
  - 기존 변환본 충돌 확인
2단계: 변환 전 검수
  - 표가 Markdown으로 유지되나
  - [확인필요] 코멘트 남아있나
  - 승인된 최종본인가
3단계: 파일 변환
  - DOCX (기본)
  - HWPX (한컴 실제 열림 검증 후)
  - PDF (필요 시)
4단계: 동기화 + 검증
  - GDrive 업로드
  - 원격 파일 크기·이름 확인

핵심: 내용은 건드리지 않음 / 변환은 별도 요청 필수 / 한컴 검증 필수

결과와 배운 점

Before vs After

항목

Before

After

초안 생성 시간

2~3시간 (프롬프트 여러 번)

같음

검수 시간

4~6시간 (문제 찾기 어려움)

1~2시간 (게이트 명확)

재작업 필요성

3~4회 반복

1회 이하

결재 투과율

~70% (돌려받는 일 빈번)

~95%

다음 보고서에 재사용

거의 안 함

40_Wiki에서 바로 검색

자동화 수준

"프롬프트 하나로"

"6단계 검증된 최종본"

효과

품질 예측 가능: 6단계를 거쳤으면 결재 통과 가능성이 높다
재사용 자산 축적: 의미카드·위키·템플릿이 쌓여 다음 보고서가 더 빠르다
원문 추적 가능: 언제 어디서 어떤 정보를 썼는지 알 수 있다
문체 일관성: 부서의 보고서 스타일이 표준화된다
리스크 관리: 오류가 발견되면 그 지점부터 되돌릴 수 있다

이 과정에서 배운 AI 활용 팁

효과적이었던 것

AI는 초안 담당, 검증은 사람
- AI가 최종본을 만들게 하지 않음
- 대신 기준과 게이트를 AI도 따르게 함
구조 우선, 창의 나중
- 원본 구조를 먼저 확인해야 AI가 방향을 잡는다
- 텍스트부터 시작하면 구조가 무너진다
단건 검수 루프가 배치 자동화보다 낫다
- 5건을 빨리 처리하되 3건이 오류인 것보다
- 1건을 느리지만 정확하게 처리하는 것이 낫다
기준을 먼저 세우면 자동화는 자동으로 따라온다
- "프롬프트를 뭐라고 할까" 고민할 필요 없음
- 기준만 명확하면 AI는 따라간다
검증 게이트를 임의로 건너뛰지 말 것
- 시간 절약이 된 것처럼 보이지만
- 나중에 검수 비용이 훨씬 크다

이렇게 하면 안 돼요

대량 자동화부터 시작
- "AI는 빠르니까 100건 한 번에"는 위험
- 1건을 검증한 후 그 기준으로 확대해야 함
AI 초안을 바로 최종본으로 두기
- 초안은 초안
- 검수 단계가 필수
기준 없이 프롬프트만 개선하기
- 같은 자료로 10번 프롬프트를 고쳐도 근본 해결 아님
- 기준을 먼저 정하고 그 안에서 프롬프트 최적화
결과물을 방어하기
- "이 정도면 괜찮지 않을까"는 위험
- 품질 게이트를 통과하지 못하면 되돌림

다른 업무에 적용한다면?

이 구조는 보고서 작성에만 한정되지 않는다.

비슷하게 적용할 수 있는 업무:

검사·감사 보고서: 근거 추적 + 항목별 체크리스트 게이트
제안서·계획안: 의도→조사→템플릿→초안→검토 흐름
회의 기록: 구조 우선(안건·논점·결정) + 원문 대조
기술 문서: 1단계 의도(독자누가)→구조→초안→review
정책·브리핑: 근거 조사(Wiki)→팩트체크→초안→스테이크홀더 리뷰

핵심 원칙은 같다:

자동화 전에 기준을 세운다. 검증 없이 통과시키지 않는다. 1건을 제대로 처리한 뒤 확대한다.

앞으로의 계획

현재는 보고서 작성 6단계가 확정됐고, 다음이 목표다:

더 많은 사례 축적: 현재 31건 분석을 50건, 100건으로 확대하면 템플릿 정확도가 더 올라감
의사결정 자동화 확대: 지금은 "기준이 있으니 기준을 따라라"인데, 향후 "어떤 상황에서는 이 기준을 쓴다"까지 자동화
조사 단계 고도화: 40_Wiki를 더 풍부하게 채우면, 초안 작성 전 조사 단계가 더 빨라짐
도메인 확대: 현재는 보고서 기준인데, 부동산·투자·정책 등 다른 도메인에 패턴을 옮기기

재사용 가능한 프롬프트

프롬프트 1: 1단계 의도 합의 (grill-me 루프)

너는 프라이드 AI 어시스턴트다.
사용자가 보고서 작성을 요청하면, 다음 순서로 의도를 확인한다.
한 번에 질문 하나만 물어본다.
Q1. 문서 목적?
Q2. 누가 읽을까?
Q3. 문서 유형 (검토/계획/현황/분석)?
Q4. 결론 방향은?
Q5. 분량과 번호체계는?
Q6. 논리 흐름과 무게중심은?
Q7. 외부자료 조사 범위는?
Q8. 포함·제외 항목은?
각 질문마다 "추천 + 근거 + 대안" 3블록을 제시하고,
사용자가 "추천대로"라고 하면 다음 질문으로 진행한다.
1단계가 끝나면 locked: true로 마크한다.

프롬프트 2: 4단계 초안 작성 (내용 통찰 체크)

너는 보고서 초안 작성 AI다.
01_brief, 02_research*, 03_outline_proposal, 03_writing_harness를 받았다.
초안을 작성할 때 반드시 다음 4가지를 확인한다:
1. §1 배경: "왜 지금 이 보고서를 쓰는가" 배경이 있나? 
   (1단계 brief의 목적 문장을 옮기지 말 것 — 동어반복)
2. §2 시사점: 표의 수치를 단순 반복하지 않나?
   (사실의 인과·맥락·해석이 있나)
3. §3 결과·결론: §2 시사점과 다른 층위인가?
   (시사점 = 해석, 결과 = 활용·액션·권고)
4. 전체: 본문이 "왜·그래서·어떻게" 중 하나 이상에 답하나?
위 4가지를 확인한 초안만 제출한다.

마치며

이 프로젝트가 보여주는 것은, AI를 빠르게 만드는 것이 아니라 AI를 믿을 수 있게 만드는 것의 중요성이다.

프롬프트 하나로는 부족했다. 대신 필요했던 것은:

원문 구조를 먼저 확인하는 습관
AI가 따를 기준을 명확히 정하는 설계
검증 게이트를 자동화하지 않는 원칙
1건을 제대로 처리하고 확대하는 인내
기준 없는 자동화는 리스크라는 깨달음

자동화의 속도보다, 자동화가 멈췄을 때 원인을 찾을 수 있는 구조가 더 중요하다.

그래서 이 여정은 "AI 자동화 프로젝트"가 아니라, "AI와 신뢰할 수 있게 일하는 법"을 배우는 과정이었다.

혹시 당신도 "AI 초안이 원하는 수준이 아니다"고 느낀다면, 초안 자체를 만드는 방법보다 초안이 따를 기준을 먼저 정의해 보자. 그것이 더 빠르고 더 믿을 수 있다.

🔥<24기 AI 스터디> 9/21 모집 마감 🔥