## 📝 한줄 요약
회사 보고서 작성에 매번 반나절~하루씩 빠지는 게 아까워서, AI 보고서 자동화 파일럿을 시작했습니다. 회사 문서를 그대로 학습 데이터로 쓸 수 없어 구조가 비슷한 정부 보고서 41개를 샘플로 모으고, 양식 라이브러리·위키·검수 워크플로우까지 4일 만에 골격을 잡았습니다.
바쁘시면 이것만 읽어도 돼요:
- AI 보고서 자동화는 모델 선택보다 양식 데이터와 검수 절차가 본질입니다.
- 회사 문서를 못 쓸 땐 같은 구조의 정부 문서로 파일럿을 돌리면 됩니다.
- 41개 변환을 Sonnet/Opus/GPT-5.5로 다 돌려봤지만, 결국 검수 절차를 끼워 넣어야 품질이 잡혔습니다.
- AI 도구는 한 번 쓰고 끝내는 게 아니라, 결함을 발견할 때마다 스킬에 박제해서 다음 작업에 자동 반영되게 해야 합니다.
- 이번 글은 결과 자랑이 아니라 구조 잡기 4일 기록입니다. 아직 회사 보고서 적용 전 단계입니다.
## 🎯 이런 분들께 도움돼요
- 반복되는 회사 보고서·기안문·계획서 작성에 시간 많이 뺏기는 직장인
- 보안·기밀 때문에 회사 문서를 AI 학습/예시로 직접 못 쓰는 환경
- AI에게 보고서 시켜봤지만 양식(특히 ㅁ/ㅇ 하이라키, 표, 붙임)이 무너져 결국 손으로 다시 다듬는 분
- 정부·공공·대기업처럼 양식이 보수적인 조직에서 일하는 분
## 😫 문제 상황 (Before)
회사 보고서 한 건 쓰는데 반나절~하루가 빠집니다. 그것도 새 보고서마다 양식·문체·구조를 처음부터 다시 잡아야 하는 게 가장 비효율적이었어요.
- "Ⅰ. 추진 배경 / Ⅱ. 추진 경과 / Ⅲ. 추진 내용..." 같은 정형화된 목차
- ㅁ → ㅇ → - → * 로 이어지는 개조식 하이라키
- 부처·기관·부서별로 미묘하게 다른 표현과 프레이밍
이걸 매번 새로 잡고, 더 답답한 건 AI에게 시키면 양식이 다 무너진다는 점이었습니다. 결국 처음부터 다시 손으로 다듬게 되니, "AI 안 쓰는 게 더 빠른 거 아닌가" 하는 생각까지 들었습니다.
올해는 본사 근무 이동 전 마지막 해라 골든타임입니다. 단발성 자동화가 아니라, 내년 본사에서도 그 다음에도 쓸 수 있는 구조를 만들고 싶었습니다. 그게 이번 보고서 자동화 파일럿의 출발점입니다.
다만 회사 보고서를 그대로 학습 데이터나 양식 샘플로 쓸 수는 없습니다. 보안 이슈가 있고, AI 도구에 직접 회사 문서를 넣는 것 자체가 부담입니다. 그래서 회사 보고서와 구조·문체·하이라키가 동일한 정부 보고서를 대체 샘플로 쓰기로 결정했습니다. 정부 보도자료에 첨부되는 기본계획·추진계획·검토보고서 같은 문서들은 회사 보고서와 양식이 거의 같거든요.
## 🛠️ 사용한 도구
- 프라이드 (Hermes 텔레그램 봇) — 업무문서·프로젝트 관리 전담 AI 봇
- 모델: Claude Sonnet / Opus, GPT-5.5 (변환 품질 비교용)
- 환경: WSL Ubuntu, Windows G드라이브 공유 폴더
- 데이터 소스: korea.kr 등 정부 공식 보도자료의 첨부 원문 (HWP/HWPX/PDF)
## 🔧 작업 과정
### Day 1 — 샘플 모으기와 표준화: "일단 데이터부터 깔끔하게"
처음에는 폴더에 모아둔 정부 보도자료 zip 파일이 60개 가까이 됐습니다. 파일명은 "별첨1_2026년_OOO_기본계획.hwpx" 같이 정리 안 된 상태였고, HWPX와 PDF가 같은 문서로 중복되는 것도 많았습니다.
프라이드에게 다음과 같이 요청했습니다.
```
샘플에 있는 파일명을 앞에 숫자, 별첨 이런거 다 지우고 제목만으로 수정해줘
```
```
제목을 2026-11_문제제목_부처 형식으로 정리해줘
```
```
중복은 삭제해줘. 그럼 hwpx랑 pdf 둘다 있는거는 하나로 쳐서 총 샘플 몇개나 모았지
```
이 과정에서 "같은 논리 문서가 PDF/HWP/HWPX로 중복될 때는 1건으로만 친다", "대표 원천은 HWPX > HWP > PDF 우선" 같은 규칙이 자연스럽게 정해졌습니다. 그렇게 최종 41개로 줄었습니다.
폴더 구조는 이렇게 잡았습니다.
| 폴더 | 용도 |
|---|---|
| 00_inbox | 검증 전 원천 자료 |
| 80_archive | 원문(HWPX/PDF) 보관 |
| 10_report | 검수 통과된 md 변환본 |
| 30_Wiki | source-level 위키 노트 |
| 20_Templates | 부처별·문서유형별 양식 |
| 50_workplace | 작업 중간물 |
| 70_outputs | 최종 보고서 |
한국어 웹사이트 스크린샷
이 구조는 단순해 보이지만, 나중에 보고서 작성 단계에서 "어디서 작업하고 어디로 승격할지"가 흐릿해지지 않게 잡아주는 역할을 했습니다.
---
### Day 2 — 변환 모델 비교: "Sonnet, Opus, GPT-5.5 다 써봤지만..."
41개 원문을 markdown으로 변환하는 게 다음 단계였습니다. 처음엔 단순히 "어느 모델이 제일 잘하나"를 보려고 같은 협동조합 문서를 세 모델로 돌렸습니다.
```
오제 협동조합 문서 소넷으로 md 파일 변환했잖아. 그 문서 제목에 소넷 표시하고 오푸스와 GPT-5.5로도 변환해서 비교해줘
```
결과는 좀 충격이었습니다. 세 모델 다 비슷하게 깨졌습니다. 표는 선형 텍스트로 풀리고, ㅁ/ㅇ 하이라키는 일부 무너지고, "<참고>" 박스 같은 건 알아볼 수도 없는 형태로 나왔습니다.
```
다 좀 마음에 안드는데 특히 참고 부분은 알아 볼 수가 없네
```
```
그러면 변환하고 니가 한번 수정해야 하는거야? 이거를 어떻게 하는게 가장 좋아?
```
이 시점에 깨달은 게 핵심이었습니다. 모델만 바꿔서는 해결 안 된다. AI 출력을 그대로 믿지 말고, 검수 절차를 끼워 넣어야 한다는 거였죠.
```
pdf나 hwpx를 한글변환 하는데 가장 중요한 거는 원문과 내용 그리고 하이라키 유지야.
```
이 한 줄을 룰로 못 박았습니다. 그리고 워크플로우를 이렇게 바꿨습니다.
1. Sonnet으로 빠르게 초벌 변환 (속도/비용 우선)
2. 내가 직접 한 건씩 검수 (원문 대조 + 하이라키 확인)
3. 통과본만 10_report로 승격
4. G드라이브로 동기화
모델 한 방에 다 맡기지 않고, "초벌 받는 동료"로 쓰는 방식입니다. 이렇게 한 결과물은 만족도가 훨씬 좋았습니다 (스스로 "9차 변형 수준의 품질"이라고 이름 붙일 정도였어요).
한국어의 다양한 유형을 보여주는 다이어그램
---
### Day 3 — 41개 변환 완료 + 위키·양식 추출
이렇게 잡은 워크플로우로 41개를 한 건씩 돌렸습니다. 시간은 더 걸렸지만 통과본 품질이 안정적이었습니다.
```
시간 오래 걸려도 되니까 한번에 빨리 다하지 말고 천천히 제대로 해줬으면 좋겠어
```
41개 변환을 마친 뒤, 위키 인제스트와 양식 추출을 동시에 진행했습니다.
- 위키 (`30_Wiki`): 각 보고서를 source-level 노트로 정리. 발간 부처, 문서 유형, 요약, 주요 섹션, 관련 개념(위키 링크)까지.
- 양식 라이브러리 (`20_Templates`):
- common/ — 공통 문서 골격 (`Ⅰ/Ⅱ/Ⅲ` → 1./2. → □ → ㅇ → - → * 계층)
- ministries/ — 부처별 빈출 표현 (예: 교육부는 "지원/운영/평가/추진/구축" 동사 다용)
- document_types/ — 문서 유형별 목차 (종합·기본계획형, 추진·시행계획형 등)
이때 깨달은 게 또 있었는데, AI에게 좋은 결과를 받으려면 모델보다 "양식 데이터" 자체가 중요하다는 점이었습니다. 부처별 빈출 동사·목차·표제어를 정리해두면, AI가 그걸 참고해서 만든 결과물은 양식이 안 무너집니다.
---
### Day 4 — 보고서 작성 스킬 만들고 실전 보고서로 검증
마지막 날은 그동안 쌓인 자산을 실제로 쓸 수 있는 보고서 작성 스킬로 묶었습니다.
스킬에 박은 핵심 규칙:
- 30_Wiki 우선, 외부 자료는 보강용
- 본문은 보고서답게 (학술논문식 인용 금지)
- 출처는 별도 *_sources.md 파일로 분리
- Drill Interview: 작성 전에 독자/문서유형/결론 방향/자료 범위를 한 번에 한 질문씩 확정
- 양식은 20_Templates 3계층 (공통 → 부처 → 문서유형) 순서로 적용
이 스킬로 첫 실전 보고서 #1을 작성했습니다. "2026년 전문대학 지원계획 검토보고서". 잘 나왔지만 한 가지 결함이 보였습니다.
```
ㅁ, ㅇ 하위에 설명이 붙으면 표나 주석처리(*)라도 해야 하는데 최종 보고서에 그런게 좀 빠져있어. 스킬 개선해줘
```
여기서 사례글의 핵심 메시지 하나가 나옵니다. 결함을 발견하면 그 자리에서 스킬에 박제한다. 프라이드는 pride-report-writing 스킬을 v1.1.2로 패치하고, 같은 주제로 보고서 #2를 새로 작성했습니다. 보고서 #2는 단순 중첩 bullet 잔여 0건으로 나왔습니다.
| 항목 | 보고서 #1 | 보고서 #2 (스킬 패치 후) |
|---|---|---|
| ㅁ/ㅇ 하위 단순 bullet | 다수 | 0건 |
| 비교·구분 항목 | 평문 나열 | 표로 정리 (8개 표) |
| 짧은 부연 | 하위 bullet | > * 주석으로 처리 |
같은 실수가 다음 작업에서 반복되지 않습니다. 이게 AI를 단발 도구가 아니라 워크플로우로 만든다는 의미입니다.
## ✅ 결과 (After)
이번 4일은 결과 자랑보다는 앞으로 쓸 골격 구축 단계입니다.
### Before vs After
| 항목 | Before | After (구조 잡기 완료) |
|---|---|---|
| 정부 보고서 샘플 | 0건, 폴더에 zip만 | 41개 표준 명명, 위키·양식까지 정리 |
| 보고서 자동화 시도 | "AI 시켜봤지만 양식 무너짐" | 검수 워크플로우 + 양식 라이브러리 결합 |
| AI에게 요청하는 방식 | "보고서 써줘" 한 마디 → 결과 들쭉날쭉 | Drill Interview로 요구사항 4축 확정 후 작성 |
| 결함 발견 시 | 다음에도 같은 실수 | 스킬 패치 → 다음 작업부터 자동 반영 |
### 산출물
| 자산 | 위치 | 용도 |
|---|---|---|
| 정부 보고서 41개 변환본 | 10_report/ | 양식 학습용 코퍼스 |
| Source-level 위키 | 30_Wiki/개체/ | 보고서 작성 시 1차 근거 |
| 양식 라이브러리 | 20_Templates/{common,ministries,document_types} | 보고서 작성 시 양식 |
| 보고서 작성 스킬 v1.1.2 | pride-report-writing | Drill Interview + 검수 + 출력 분리 |
| 실전 보고서 #1, #2 | 70_outputs/ | 스킬 검증 결과물 |
## 💬 이 과정에서 배운 AI 활용 팁
### 1. "AI 시켜서 한 번에 끝낸다"는 환상을 버려라 — 검수 절차가 본질
Sonnet/Opus/GPT-5.5 다 돌려 봤지만, 모델만 바꿔서는 해결 안 됐습니다. 결국 답은 검수 절차를 끼워 넣는 것이었습니다. AI 출력을 "초벌"로 보고, 한 건씩 검수해서 통과본만 다음 단계로 보내는 파이프라인이 모델 선택보다 훨씬 중요했습니다.
### 2. AI에게 줄 "양식 데이터"를 먼저 모아라
좋은 양식 샘플 30~40개만 부처/유형별로 정리해두면, 같은 모델이라도 출력 품질이 달라집니다. 모델 성능보다 양식 데이터 자체가 결과 품질을 좌우합니다. 이번 파일럿에서 가장 큰 발견이었습니다.
### 이렇게 하면 안 돼요
1. "AI한테 한 방에 다 시킨다" 마인드 — 한 번에 좋은 결과 안 나옵니다. 초벌+검수가 정답.
2. 모델 비교에 시간 너무 쓰기 — 어차피 비슷합니다. 그 시간에 양식 데이터부터 정리하세요.
3. 결함 발견하고 그냥 넘어가기 — 다음에도 똑같이 틀립니다. 그 자리에서 스킬·프롬프트에 박제하세요.
## 🌍 다른 업무에 적용한다면?
이 골격은 양식이 정형화된 모든 반복 문서에 적용 가능합니다.
- 계약서·약관 검토 — 표준 조항 라이브러리 + 검수 워크플로우
- 사업 제안서 작성 — 제안서 양식 라이브러리 + 회사별 톤 가이드
- 회의록·주간보고 — 정형 목차 + 핵심 추출 검수 절차
- 공문·민원 회신 — 부처/기관별 표현 라이브러리
핵심은 같습니다. 샘플 → 양식 추출 → 위키화 → Drill Interview + 검수 절차 → 스킬화.
## 🚀 앞으로의 계획
1. 다음 주: 디테일 보강 — 양식 라이브러리에서 빠진 표·박스·붙임 패턴 추가, source 노트의 사실/분석 단위 확장.
2. 그 다음 주: 한글 변환(HWPX) + 상사 의도 검수 과정 추가 — md → HWPX 변환 파이프라인 정착. 그리고 AI 검수 후 상사가 무엇을 원할지 미리 체크하는 단계를 워크플로우에 끼워 넣을 예정. 보고서는 결국 사람이 결재합니다.
3. 그 후: 실제 회사 보고서 적용 — 정부 문서 파일럿에서 검증된 골격 위에, 회사 보고서 양식을 얹어 본격 운영 시작.
## 📋 재사용 가능한 프롬프트
### 프롬프트 1: 파일 정리·표준 명명
> 샘플 폴더에 있는 [문서 종류] 파일들을 정리해줘.
> 1. 파일명 앞의 숫자·"별첨"·"붙임" 같은 표시는 제거
> 2. [YYYY-MM]_[제목]_[기관] 형식으로 통일
> 3. 같은 논리 문서가 [HWPX/PDF] 등으로 중복되면 1건으로 처리 (HWPX > HWP > PDF 우선)
> 4. 최종 개수와 변경 내역 알려줘
[문서 종류]·[연월 형식]은 본인 상황에 맞게 수정하세요.
### 프롬프트 2: 변환 + 검수 워크플로우 요청
> [원문 파일]을 markdown으로 변환해줘. 다만 이렇게 해줘:
> - 원문 문장과 내용, 하이라키(`ㅁ/ㅇ/-/*` 계층)를 그대로 유지
> - 표·박스·붙임 구조는 깨지 않게
> - 변환 후 한 건씩 검수하고, 통과본만 [통과 폴더]로 옮겨줘
> - 빠르게 한 번에 다 하지 말고 천천히 제대로 해줘
### 프롬프트 3: Drill Interview 방식 보고서 작성 요청
> [주제]로 보고서 써줘. 작성 시작 전에 다음 4가지를 한 번에 한 질문씩 물어봐주고, 각 질문에는 너의 추천 답변도 같이 제시해줘:
> 1. 최종 독자와 사용 장면
> 2. 문서유형 (검토 보고서 / 정책보고서 / 계획보고서 / 제안서 등)
> 3. 결론 방향 (현황 요약 / 대안 추천 / 의사결정 요청)
> 4. 자료 범위 (내부 자료만 / 공식자료 보강 / 외부 자료 허용)
---
이번 사례글은 결과 자랑 글이 아닙니다. AI 보고서 자동화의 골격을 4일에 잡은 기록입니다. 다음 단계 — 디테일 보강 — 까지 마치면 다시 정리해 올리겠습니다.
