AI에게 짧게 시키면 얕게 나온다

2026년 10월 13일, 방치형 RPG 게임 문서 묶음을 AI 에게 맡겼다. 처음 받은 판은 AI 가 혼자 한 번에 쓴 것이었다. 돌아간 평은 한 줄이었다. 「충분히 디테일하지 않다」.

같은 주제를 다시 시켰다. 이번에는 조사 4, 바이블 1, 집필 15, 검토 4, 그다음 수정과 최종 대조. 에이전트가 약 40개 돌았고 한 시간이 넘게 걸렸다. 그 판을 받고 나서야 「앞으로도 이렇게」라는 말이 나왔다.

모델이 바뀐 것도 아니다. 바뀐 건 시키는 법이었다. 그 차이를 /deep 이라는 스킬 하나로 굳혀 두었다. 무엇이 달랐을까?

「자세하게」에는 끝이 없다

「자세하게 써 줘」라고만 쓰면 AI 는 적당한 데서 멈춘다. 어디까지가 자세한 건지 정해 주지 않았으니 멈춘 자리가 곧 끝이다. 탓할 일도 아니다.

그래서 규모를 숫자로 준다. 「시중의 무엇만큼」에 핵심 개수를 붙인다.

브로타토급, 캐릭터 40에 무기 80
납품사양서급, 60쪽에 장 15개
버섯커 키우기급, 캐릭터 60에 스테이지 300

제일 짧게 쓰면 이 한 줄이다.

코드

/deep 「주제」 — 「시중의 무엇」급, 「핵심 개수들」

숫자가 있으면 셀 수 있고, 셀 수 있으면 빠뜨린 걸 나중에 잡는다. 「60종 전부 표로」라고 써 두면 최종 대조에서 표의 행을 세어 보면 된다. 59행이면 하나가 빠진 거다.

/deep 은 인자에 규모 숫자가 없으면 딱 하나만 묻는다. 「시중의 무엇만큼, 핵심 개수는 몇?」 숫자가 있으면 묻지 않고 바로 간다. 결과물 형식을 안 정했으면 기본값을 쓴다. 밝은 바탕에 머리줄 표가 많은 사양서 형식이다. 형식까지 매번 물으면 시키는 쪽이 먼저 지친다.

혼자 한 번에 쓰게 두지 않는다

깊이를 만드는 두 번째 장치는 분업이다. 프롬프트에 「use a workflow」 한 줄이 있어야 AI 가 혼자 쓰지 않고 여러 에이전트에게 나눠 맡긴다. /deep 을 불렀다는 것 자체가 그 허락이다. 뼈대는 이렇게 생겼다.

단계	몇 개	하는 일
조사	병렬 3~5	갈래별로 조사하고 결과를 파일로 남긴다. 출처와 날짜 필수
바이블	1	조사를 다 읽고 이름·개수·수치·용어 같은 고정값을 한 파일에 정한다
집필	문서 하나에 하나	문서마다 최소 쪽 수와 반드시 들어갈 표를 숫자로 박는다
검토	서로 다른 눈 4	만드는 사람·숫자·팩트체크·독자
수정	문서별 병렬	지적을 문서별로 묶어 그 문서 담당이 고친다
최종 대조	1	표 행 수를 파이썬으로 세서 약속한 개수와 맞춘다

집필 단계의 계산은 파이썬으로 실제로 돌린 값만 쓴다. 에이전트가 머릿속으로 곱한 숫자는 믿지 않는다. 큰 표도 손으로 치지 않는다. 데이터를 JSON 으로 두고 파이썬이 HTML 표를 만든다. 그래야 최종 대조에서 행을 셀 때 원본과 화면이 같은 숫자를 낸다.

바이블이 없으면 열다섯 명이 각자 다른 이름을 쓴다

집필자 15명이 동시에 쓰면 이름과 숫자가 문서마다 어긋나기 쉽다. 각자 조사를 읽고 각자 정하기 때문이다. 그래서 쓰기 전에 고정값부터 한 파일로 정한다. 이게 바이블이다.

이 블로그를 독립 사이트로 옮길 때도 같은 걸 썼다. 집필자 넷(core, client, content, integration)이 동시에 코드를 쓰는 판이었다. 바이블 맨 앞에는 실측 숫자 표가 있었다. 살아 있는 글 124편, 개발 글 80편, 사이트맵 URL 88개. 표 위에는 「이 숫자가 나오지 않으면 빌드가 틀린 것이다」라고 적혀 있었다.

몇 가지 규칙이 더 있었다. 파일마다 주인을 정해 두고 자기 파일만 쓴다. 바이블과 다르게 판단해야 하면 고치지 말고 결과 보고 맨 위에 「바이블과 다름: 무엇 / 이유」를 적는다. 남의 파일에 고칠 게 보이면 직접 손대지 않고 「훅 요청: 무엇」으로 보고만 한다. 결정은 메인이 내린다. 여럿이 동시에 쓰는 판에서는 누가 무엇을 바꿀 수 있는지가 내용만큼 중요했다.

검토는 쓴 쪽이 아닌 다른 눈 넷에게

쓴 쪽이 자기 글을 다시 보면 문제가 안 보인다. 그래서 검토를 따로 시키고, 그 눈도 넷으로 나눈다.

만드는 사람: 이 문서만 보고 실제로 만들 수 있나
숫자: 시뮬레이션과 계산을 다시 돌려서 재현되나
팩트체크: 출처, 법, 날짜가 맞나
독자·작가: 문체가 맞고 이야기에 개연성이 있나

넷은 각자 다른 걸 찾는다. 숫자 검토자는 문체를 보지 않고, 독자는 계산을 다시 돌리지 않는다. 눈마다 맡은 게 다르니 겹치지 않는다.

지적은 {slug, problem, fix, severity} 모양으로 받는다. 어느 문서의 무엇이 문제고, 어떻게 고치고, 얼마나 심각한지. 이렇게 받아 두면 수정 단계에서 문서별로 묶어 담당에게 돌려줄 수 있다. 끝나고 나면 high 가 몇 건이었는지까지 보고에 남는다.

하지 말 것을 프롬프트에 박아 둔다

에이전트 수십 개가 각자 일하면 엇나가기 쉽다. 그래서 모든 에이전트가 받는 공통 프롬프트에 금지 목록을 넣는다.

조사 안 된 숫자는 지어내지 않고 「미확인」이나 「추정(근거)」으로 쓴다
「적절히」「등」「~할 예정」 같은 뭉뚱그린 말을 쓰지 않는다
분량을 채우려고 같은 말을 반복하지 않는다
커밋·배포·git 은 메인만 한다
신원(실명·나이·소속)을 쓰지 않는다
돈 드는 곳(이미지 생성 API, 유료 모델, 유료 SaaS)에 접근하지 않는다. 그림은 코드로 그린다

「미확인」 표시는 모르는 숫자를 그럴듯하게 채우는 걸 막는다. 블로그를 옮길 때 바이블에도 이런 줄이 여럿 있었다. 페이지 무게 예산을 적어 놓고 「실제 값은 미확인」, 검색 인덱스 파일 크기도 「미확인 — 처음 빌드할 때 결과 보고에 적는다」. 모르는 걸 모른다고 적고, 누가 언제 재서 채울지까지 정해 둔 것이다. 빈칸이 빈칸으로 보이면 나중에 메우면 된다. 그럴듯한 가짜 숫자는 아무도 다시 보지 않는다.

/deep 을 못 쓰는 곳에서는 같은 내용을 템플릿으로 붙여 넣는다. 「」 자리만 채운다.

코드

use a workflow
[목표]
「무엇」을 「누가 이것만 보고 무엇을 할 수 있는」 수준으로 만들어 줘.
규모 기준: 「시중의 비슷한 것 1~2개」급.
[규모 — 이 숫자 밑으로 내려가면 실패]
- 문서 「몇」편, 각 최소 「몇」쪽
- 「항목 A」 「몇」개 전부 표로 (칸: 「이름·수치·…」)
- 숫자는 출처와 날짜, 추정이면 「추정」 표시
[에이전트 구성]
1. 조사(병렬): 「갈래 1」 / 「갈래 2」 / 「갈래 3」
2. 바이블: 이름·개수·수치 같은 고정값을 먼저 한 파일로
3. 집필(병렬): 문서 하나에 에이전트 하나
4. 검토(따로): 만드는 사람 눈 / 숫자 눈 / 팩트체크 / 「독자」 눈
5. 수정 → 최종 대조(개수 실측) → 배포
6. 보고: 고친 것, 「미확인」 남은 것
[하지 말 것]
- 조사 안 된 숫자 지어내기 → 「미확인」
- 분량 채우려고 같은 말 반복
- 「적절히」「등」「~할 예정」

깊게 시키는 데는 값이 든다

공짜는 아니다. 에이전트 수십 개가 도는 만큼 토큰을 많이 쓴다. 게임 문서 묶음은 약 40개에 한 시간 넘게 걸렸다. 그래서 /deep 은 끝나면 걸린 시간과 에이전트 수를 같이 보고한다. 시키는 사람이 비용 감을 잡아야 다음에 언제 쓸지 고를 수 있다. 중간에 실패한 에이전트가 있으면 전체를 다시 돌리지 않고 그 문서만 다시 돌린다. 분업해 둔 덕에 실패도 문서 단위로 끊긴다.

질문 하나, 파일 하나 고치기, 짧은 답에는 쓰지 않는다. 그건 그냥 시키면 된다. 부담되면 「조사만 먼저」처럼 단계를 끊어서 시키는 방법도 있다. 조사 결과를 보고 나서 집필까지 갈지 정하면 된다.

깊이는 결국 시키는 쪽 문장에서 정해진다. 숫자를 주고, 일을 나누고, 남의 눈으로 다시 보게 하는 것. 셋 중 하나만 빠져도 결과물은 처음 받은 그 얕은 판 쪽으로 돌아간다.

핵심 한 줄「자세하게」는 깊이가 아니다. 규모는 숫자로, 일은 여럿에게, 검토는 남의 눈에게 맡겨야 깊어진다.