LLM으로 문서를 자동 생성하기 시작하면 처음에는 Prompt 개선에 대부분의 시간을 쓴다.
역할을 더 자세히 써보고
출력 형식을 더 엄격하게 만들고
좋은 예제를 넣고
Reviewer Prompt도 추가한다초기에는 확실히 효과가 있다.
문서 형식이 정리되고, 빠뜨리는 항목도 줄어든다.
하지만 어느 시점부터 품질이 잘 오르지 않는다.
그때 문제는 Prompt가 아닐 수 있다.
LLM이 참고할 실제 근거가 부족한 것이 병목일 수 있다.
1. 템플릿 일치와 내용 품질은 다르다
LLM은 형식을 맞추는 데 강하다.
예를 들어 다음은 쉽게 자동화할 수 있다.
제목
목차
표
섹션 구성
용어 정의
결론하지만 문서의 실질적 품질은 다른 문제다.
예를 들어 API 문서를 만든다고 해도 실제 엔드포인트 정의가 없으면 모델은 일반적인 REST API 설명을 채워 넣게 된다.
형식은 맞지만 프로젝트 문서는 아니다.
2. 좋은 프로젝트 문서는 실제 Evidence가 필요하다
고품질 문서를 만들려면 최소한 다음과 같은 근거가 필요하다.
Requirements
Source Code
API Spec
DB Schema
Test Results
ADR
Issue / Ticket
Meeting Decision
Change History이 정보가 없으면 모델은 추론할 수밖에 없다.
그리고 추론 비율이 높아질수록 hallucination 가능성도 높아진다.
3. Evidence Library를 별도 계층으로 만든다
문서 자동화 구조를 다음처럼 생각할 수 있다.
Project Sources
↓
Evidence Extraction
↓
Evidence Library
↓
Document Generator
↓
Reviewer
↓
Correction여기서 핵심은 생성 이전 단계다.
문서를 만들기 전에 근거를 먼저 구조화한다.
4. Evidence는 문장보다 구조가 중요하다
Evidence Library에 원문 파일만 던져 넣는 것으로 끝내면 검색 품질이 떨어질 수 있다.
예를 들어 요구사항 evidence라면 다음처럼 구조화할 수 있다.
{
"type": "requirement",
"id": "REQ-014",
"source": "requirements.md",
"status": "approved",
"text": "...",
"related_code": ["..."],
"related_test": ["..."]
}중요한 것은 출처와 관계다.
5. Evidence Lineage를 유지한다
생성된 문장마다 “어디서 나온 사실인지” 추적 가능하면 품질 관리가 쉬워진다.
예:
Document Claim
↓
Evidence ID
↓
Source File
↓
Original Context이 구조가 있으면 Reviewer가 다음을 판정할 수 있다.
SUPPORTED
PARTIALLY_SUPPORTED
UNSUPPORTED6. 근거가 없으면 쓰지 않는 규칙
가장 중요한 규칙 중 하나다.
근거 있음 → 작성
근거 일부 → 한계 명시
근거 없음 → UNKNOWN / TODO문서를 “빈칸 없이 완성하는 것”보다 근거 없는 내용을 쓰지 않는 것이 더 중요하다.
이건 감으로만 판단할 문제는 아니다. 생성된 문장이 주어진 근거에서 나온 것인지를 재는 공개 지표가 있다 — RAGAS의 faithfulness는 답변을 개별 주장으로 쪼갠 뒤 각 주장이 검색된 근거로 뒷받침되는 비율을 낸다. 문서 생성 파이프라인에도 같은 방식을 붙일 수 있다. 통과·반려 기준을 사람 눈이 아니라 숫자로 두면, 근거 규칙이 실제로 지켜지는지를 회귀로 감시할 수 있다.
특히 다른 사람이 그 문서를 근거로 판단을 내리는 문서에서는 그렇다.
7. Reviewer도 문체보다 근거를 본다
Reviewer에게 단순히:
문서를 검토해서 개선해줘라고 하면 문장 스타일만 좋아질 수 있다.
더 좋은 질문은 다음이다.
각 주요 주장에 Evidence가 있는가?
요구사항과 설계가 연결되는가?
설계와 테스트가 연결되는가?
출처 없는 사실이 있는가?즉 Reviewer가 문서 편집자가 아니라 Evidence auditor 역할을 해야 한다.
8. 추적 가능성은 표가 아니라 그래프다
요구사항에서 결과까지 이어지는 추적 관계는 보통 표로 그리지만, 실제 구조는 표가 아니다.
다음 관계를 연결하는 graph에 가깝다.
Requirement
→ Design
→ Implementation
→ Test
→ Result이 관계가 Evidence Library에 있으면 여러 종류의 문서를 같은 근거에서 생성할 수 있다.
9. Prompt의 역할도 바뀐다
Evidence가 충분하면 Prompt는 더 이상 사실을 “생성”하게 할 필요가 없다.
대신 다음을 지시한다.
어떤 Evidence를 선택할지
어떤 순서로 배열할지
어떤 문서 형식으로 표현할지
불확실성을 어떻게 표시할지즉 Prompt는 지식 저장소가 아니라 작성 정책이 된다.
실무 체크리스트
[ ] 문서 작성 전 Evidence inventory
[ ] 각 Evidence에 source 정보 유지
[ ] Requirement-Code-Test 관계 연결
[ ] Unsupported claim 차단
[ ] Reviewer가 Evidence를 검증
[ ] UNKNOWN/TODO 허용
[ ] 생성 문서에서 lineage 추적 가능결론
문서 자동화에서 일정 수준까지는 Prompt 개선이 효과적이다.
하지만 그 이후 품질을 결정하는 것은 대부분 실제 프로젝트 Evidence의 양과 구조다.
LLM은 없는 사실을 만들어내는 도구가 아니라:
존재하는 근거를 올바른 문서 구조로 재조립하는 도구
로 사용하는 편이 훨씬 안정적이다.