AI에게 문서 초안을 맡긴다는 것

요즘 문서를 쓰는 방식이 바뀌고 있다. 빈 화면에 첫 문장부터 적어 내려가던 일을, 이제는 AI(인공지능)에게 초안을 먼저 시키는 일이 흔해졌다. 기획서, 보고서, 제안서, 요구사항 정의서까지 종류를 가리지 않는다.

그런데 막상 "초안 써줘"라고 시켜보면 결과가 묘하다. 형식은 멀쩡하다. 문제 정의도 있고, 목표도 있고, 항목도 가지런하다. 그런데 실제로 쓰려고 들면 어딘가 어긋난다. 우리 조직이 쓰는 용어와 다르고, 검토자가 기대하는 디테일과 다르고, 실제 운영 기준이나 예외와 맞지 않는 경우도 많다. 결국 거의 새로 쓰다시피 고치게 된다.

이 글은 그 간극의 정체를 따져본다. AI가 만드는 첫 문서는 왜 "어딘가 평균적인 문서"에 가까운지, 우리 조직의 작성 방식을 알려주면 왜 나아지는지, 그리고 그 방법이 무엇을 줄여주고 무엇은 끝내 사람에게 남기는지.

1왜 첫 초안은 '평균치 문서'가 되는가

언어모델은 학습한 데이터의 분포를 따라 다음에 올 단어를 예측한다. 특별한 맥락이 주어지지 않으면, 가장 그럴듯하고 흔한 형태로 수렴한다. 인터넷 곳곳에 흩어진 수많은 표준 양식의 평균을 향해 가는 것이다.

이것은 인상비평이 아니라 여러 연구에서 측정된 경향이다. 같은 모델로 글을 쓰면 서로 다른 사람의 글이 점점 닮아간다는 보고가 누적되어 있다. 한 통제 실험에서는 모델과 함께 작성한 글이 단독으로 쓴 글보다 어휘와 내용의 다양성이 줄고, 저자마다의 개성이 옅어졌다. 대학 입학 에세이 2,200편을 분석한 다른 연구는, 사람이 쓴 글은 편수가 늘수록 새로운 발상이 계속 더해지지만 모델이 생성한 글은 그렇지 않아 모일수록 서로 비슷해진다는 것을 보였다.

요점은 이렇다. 맥락이 없는 모델의 기본 출력은 '가능한 문서들의 공간' 가운데 가장 붐비는 한 점으로 쏠린다. 아래 그림이 그 차이를 보여준다.

2맥락을 주면 왜 나아지는가

그래서 필요한 것은 더 화려한 프롬프트 한 줄이 아니라 맥락이다. 2025년 들어 업계의 무게중심은 '프롬프트 엔지니어링'에서 '맥락 엔지니어링(context engineering)'으로 옮겨갔다. 질문을 어떻게 다듬느냐보다, 모델이 답하기 전에 무엇을 쥐여줄지가 더 중요하다는 인식이다. 안드레이 카파시 같은 연구자나 가트너 같은 분석기관이 비슷한 시기에 이 전환을 명시적으로 짚었다.

방법은 어렵지 않다. 이미 잘 통과된 사내 문서 한두 건을 준비해, AI에게 '그대로 따라 쓰라'가 아니라 '구조와 작성 방식을 분석하라'고 시킨다. 공통 목차, 요구사항을 적는 방식, 정책과 예외를 정리하는 패턴, 권한·이력·운영 항목을 다루는 방식, 자주 쓰는 표현을 추려 하나의 작성 가이드로 만든다.

한 번 뽑은 규칙을 매번 다시 붙여넣지 않으려면 파일로 남긴다. Claude Code(명령줄 기반 코딩 에이전트)를 쓴다면 CLAUDE.md에 작성 규칙을, 별도 템플릿 파일에 실제 양식을 둔다. 그러면 다음부터는 "우리 양식에 맞춰 작성해줘"라는 짧은 요청만으로도 출력이 회사 쪽으로 당겨진다.

두 가지 단서를 덧붙인다. 첫째, 실제 사내 문서를 외부 도구에 그대로 넣는 일은 주의가 필요하다. 고객 개인정보, 내부 시스템명, 보안 정보는 제거하고 구조와 표현 방식만 추려 쓰는 편이 안전하다. 둘째, 규칙 파일은 짧게 유지하는 편이 낫다. 모델이 매 작업 첫머리에 읽는 파일이라, 길어질수록 핵심이 묻힌다. 양식 전문을 통째로 박기보다 "자세한 건 이 파일을 보라"는 식의 포인터로 두고, 양식이 바뀌면 해당 템플릿 파일만 고치는 구조가 관리하기 쉽다.

3그래서 실제로 무엇이 줄어드는가

여기서 흔한 오해 하나를 짚어야 한다. "하루 걸리던 문서를 10분에"라는 식의 표현은 절반만 맞다. 줄어드는 것은 '작업 시간 전체'가 아니라 특정 구간이다.

문서 작업을 단계로 쪼개 보면 대략 넷이다. 빈 화면 앞의 막막함, 목차를 잡고 요구사항을 나누고 예외를 펼치는 구조화, 무엇이 진짜 문제이며 어디까지를 범위로 둘지·어떤 예외를 정책으로 막고 어떤 것은 운영으로 받을지 결정하는 판단, 그리고 유관부서와 개발이 검토할 수준으로 다듬는 작업.

AI가 크게 압축하는 것은 앞의 두 단계다. 빈 페이지 문제를 없애고, 구조화를 순식간에 끝낸다. 그러나 뒤의 두 단계, 곧 판단과 다듬기의 길이는 거의 그대로 남는다.

빈 문서 앞에서는 생각이 흩어지지만, 초안이 있으면 빠진 것과 이상한 것이 훨씬 잘 보인다. AI의 진짜 효용은 '완성본'을 만들어주는 데 있지 않다. 반응하고 고칠 수 있는 첫 구조물을 빠르게 세워준다는 점에 있다.

4그래도 남는 네 가지 함정

1. 1샘플이 너무 적다

   우수 문서 한두 건만으로 '회사 문법'을 뽑으면 그 표본에 과적합되기 쉽다. 좋은 문서 한두 개에 조직의 암묵적 관례가 다 드러나지도 않는다. 추출된 가이드는 출발점일 뿐이며, 어긋난 부분이 보일 때마다 규칙을 한 줄씩 고쳐 채워야 비로소 쓸 만해진다.

2. 2정형 문서엔 강하고, 새로운 결정엔 약하다

   권한·상태·이력이 반복되는 내부 관리 화면 개선처럼 패턴이 굳은 문서에는 잘 맞는다. 반대로 선례가 없는 신규 제품·전략 결정에서는 모델의 '평균치 경향'이 오히려 길을 흐린다. 이런 작업은 맥락을 주입하는 비용 대비 효과가 떨어진다.

3. 3템플릿은 조용히 낡는다

   Claude Code 운용에서 가장 흔한 실패는 '맥락 표류(context drift)'다. 양식이 바뀌었는데 규칙 파일이 따라오지 못하면, 출력 품질이 티 나지 않게 떨어진다. 이 방식의 진짜 부담은 처음 한 번 만드는 데 있지 않고, 계속 동기화하는 데 있다.

4. 4첫 초안이 생각을 가둔다

   빈 페이지를 없애주는 첫 구조물은 동시에 닻이 된다. 사람은 AI가 먼저 내놓은 '완성형처럼 보이는' 아이디어에서 멀리 벗어나기 어렵다는 연구가 있다. AI가 짠 목차와 프레임을 의심 없이 받아들이면, 더 나았을 다른 구조를 아예 시도하지 않게 된다.

5역설: 좋은 맥락을 만들려면 이미 판단이 필요하다

결국 한 바퀴를 돌아 제자리로 온다. AI가 좋은 초안을 쓰게 하려면 좋은 맥락을 줘야 한다. 그런데 좋은 맥락을 만드는 일, 곧 어떤 문서가 우수한지 고르고 무엇이 핵심 규칙인지 가려내는 일에는 이미 '무엇이 좋은 문서인가'에 대한 판단이 필요하다. 자동화가 절약해 준다는 바로 그 판단력이, 자동화가 작동하기 위한 전제인 셈이다.

그러니 진짜 질문은 "AI가 문서를 대신 써주는가"가 아니다. "내가 가진 문제의식과 조직의 작성 방식을, 도구가 참고할 수 있도록 얼마나 잘 옮겨 담을 수 있는가"다.