70%에서 끊는 것이 더 빠르다 — 업무 분해 3패턴과 컨텍스트 예산

앞 편의 프롬프트 7패턴이 "한 번의 지시를 잘 쓰는 법" — 목적·맥락·제약·형식 네 요소를 채우고, 반복되는 지시는 커맨드로 저장하고, 이미 파일로 있는 맥락은 @나 파이프로 연결하는 것 — 이었다면, 이 글의 3패턴은 "복잡한 업무를 어떻게 나눠 시킬 것인가" 다.

그리고 나눠 시키기 시작하면 곧바로 다음 문제가 온다. 대화가 길어지고, 길어진 대화는 매 턴 전량이 다시 전송되며, 어느 지점부터 AI가 앞의 결정과 모순된 답을 내놓기 시작한다. 뒤의 절반은 그 지점을 어떻게 감지하고 무엇을 남긴 채 끊을 것인가를 다룬다.

이 글이 옮긴 원 자료의 작성 기준일은 2026-07-26이다. 명령 이름·임계값·옵션은 그 시점의 것이다.

이 글의 예시 업무·메모리 항목·하루 시나리오는 원 자료의 실습 예제이며 특정 조직의 실제 운영 사례가 아니다. 개념·용어·판단 프레임 층위에서 읽어야 한다.

용어 정리

첫 편의 용어표에서 이 글이 쓰는 행만 추렸다.

업무지시 패턴 3가지

패턴 A — 단계별 업무 분해

큰 업무를 3~5개 단계로 쪼개 순차 지시한다. 각 단계의 결과가 다음 단계의 입력이 된다.

세 이점 중 뒤의 둘은 사실상 같은 것의 앞뒤다. 사람이 중간에 확인하니까(검증 가능) 틀어진 지점에서 멈출 수 있고(방향 수정), 그래서 되돌리는 비용이 한 단계분으로 제한된다.

# Step 1 — 경쟁사 분석
우리 시장의 상위 경쟁사 3곳을 분석해줘.
각 경쟁사의 가격 체계, 핵심 기능, 타겟 고객을 비교 표로 정리해.

# Step 2 — 차별화 도출 (같은 대화에서 이어서)
이 분석 결과를 바탕으로 우리 제품의 차별화 포인트 3가지를 도출해줘.
경쟁사가 약한 영역이나 미충족 니즈 중심으로 찾아줘.

# Step 3 — 마케팅 문구
이 차별화 포인트를 기반으로 랜딩 페이지 문구를 작성해줘.
히어로 헤드라인, 3개 피처 설명, CTA 버튼 문구를 포함해.

# Step 4 — 종합
위 내용을 종합해서 런칭 체크리스트를 작성해줘.
카테고리별로 나누고 담당자 칸과 마감일 칸을 넣어 마크다운 표로.

단계 간 연결어("이 분석 결과를 바탕으로", "위 내용을 종합해서")가 이전 컨텍스트를 명시적으로 지목하는 장치다.

패턴 B — 파일 기반 지시

구두 질문과 데이터 첨부의 차이다. 팀장이 "올해 매출 어때?"라고만 물으면 직원은 기억에 의존해 대충 답하고, 파일을 넘기면 숫자 기반 분석이 나온다. 메커니즘은 앞 편에서 본 @참조(대화형) 와 파이프(비대화형) 두 가지다.

패턴 C — 반복 업무 자동화

프롬프트 구조는 고정, 입력만 교체한다. SOP를 AI에 적용하는 방식이다.

# 고정 구조
다음 고객 정보를 보고 맞춤 온보딩 이메일을 작성해줘.
- 업종: [업종]
- 회사 규모: [규모]
- 주요 관심사: [관심사]

작성 규칙:
- 톤: 친근하되 전문적
- 분량: 200단어 이내
- 구조: 환영 인사 → 업종별 가치 제안 → 시작 가이드 CTA
- 업종별 성공 사례 1개 포함

# 입력만 교체
고객 A — IT 서비스 / 50명 / 반복 업무 자동화
고객 B — 제조업 / 200명 / 품질 관리 프로세스 개선
고객 C — 교육 기관 / 10명 / 콘텐츠 제작 자동화

배치 처리로 확장하면 파일 개수만큼 산출물이 자동 생성된다.

for file in customer_*.json; do
  claude -p "$(cat .claude/commands/onboarding-email.md)" < "$file" \
    > "email_$(basename $file .json).md"
done

3패턴 비교와 진화 경로

마지막 행이 다음 그림의 출발점이다. 세 패턴 모두 사람이 매번 손을 대야 한다는 한계를 공유하고, 그 한계를 한 칸씩 밀어내면 아래 경로가 된다.

컨텍스트 윈도우와 세션 전략

왜 관리해야 하는가

컨텍스트 윈도우는 AI의 업무 책상이다. 크기가 정해져 있으므로 서류가 쌓이면 넘친다. 결정적으로 매 턴마다 이전 대화 전체가 다시 전송된다.

Turn 1: [시스템 프롬프트] + [사용자 메시지 1]
Turn 2: [시스템] + [사용자 1] + [AI 응답 1] + [사용자 2]
Turn 10: 10턴 전체 이력이 매번 재전송

토큰 감각

1M 토큰은 영어 기준 소설 10~15권, A4 약 2,000장 분량이다. 넓지만 무한하지 않다.

한국어 약 2배의 용도. 이 값은 영어 대비 토큰 소비 비율이며, 한국어 문서 작업의 비용을 산정하는 근거로 쓰인다. 같은 분량의 문서라도 한국어로 작업하면 예산이 대략 두 배로 잡힌다는 뜻이다.

여기서 "같은 대화 분량이면 한국어 쪽이 아래의 임계에 먼저 닿는다"까지 이어 읽을 수 있지만, 그 연결은 이 글의 정리다. 원 자료가 이 값에 붙인 칸은 "영어 대비 토큰 소비"와 "한국어 문서 작업 비용 산정 근거" 둘뿐이고, 뒤에 나오는 70%·85% 임계와 잇지는 않았다.

무엇이 컨텍스트를 먹는가

일곱 행 중 한 번의 조치로 가장 크게 줄어드는 것이 셋째 행이다. 대화 이력이 가장 크지만 그건 일을 하면 쌓이는 것이고, MCP 서버 정의는 쓰지도 않는데 자리를 차지한다. 둘째 행도 줄일 수 있다 — 첫 편의 80~120줄 권장과 @import 모듈화가 그 방법이다. 다만 그쪽은 파일을 다시 쓰는 일이라, 서버 몇 개를 끄는 것만큼 즉각적이지는 않다.

서버당 최대 18,000 토큰의 용도. 이 값은 MCP 도구 정의가 차지하는 소비량이며, 서버를 정리했을 때의 효과를 가늠하는 근거로 쓰인다. 연결만 해 두고 안 쓰는 서버 몇 개를 끄는 것만으로 수만 토큰이 회수되는 계산이 여기서 나온다.

/context로 분해를 확인한다.

> /context
Context Usage Breakdown:
System overhead:     12,000 tokens (1.2%)
MCP tools:           45,000 tokens (4.5%)
Memory files:         8,000 tokens (0.8%)
Conversation:       235,000 tokens (23.5%)
Free:               700,000 tokens (70.0%)

MCP tools 비중이 크면 /mcp에서 불필요한 서버를 비활성화한다. 이것만으로 수만 토큰이 회수된다.

컨텍스트 소모의 5가지 징후

다섯 징후는 드러나는 자리가 서로 다르다. 앞의 둘은 대화에서 바로 들리고, "응답 속도 저하"는 기다리는 동안 체감되며, "엉뚱한 파일 접근"은 도구 호출을 지켜보면 그 자리에서 보인다. 반면 "코드 품질 저하"는 결과물을 봐야 드러나서, 눈치챘을 때는 이미 그 상태로 만들어 둔 코드가 쌓여 있다. 이렇게 나누는 것은 이 글의 정리이며, 원 자료는 다섯을 "관찰되는 현상"이라는 한 열에 나란히 두었을 뿐이다.

중요한 건 이것이 단순한 망각이 아니라 판단력 저하라는 점이다. 70%를 넘으면 이전 결정과 모순된 답변이 나오기 시작한다.

임계치 기준 — 70%와 85%

계획 문서(plan.md)가 승인 상태이면 세션 간 컨텍스트 브릿지가 확보되므로 임계값을 올려도 된다는 논리다.

70% / 85%의 유효 조건. 두 값은 각각 세션 분리 신호와 계획 승인 시 허용 상한이며, 원 자료가 도구 버전에 따라 달라질 수 있다고 단서를 붙인 수치다. 숫자 자체보다 "계획이 파일로 남아 있으면 임계를 올려도 된다" 는 규칙이 재사용되는 부분이다.

세 가지 관리 도구

마지막 열이 이 표를 읽는 기준이다. 지금 컨텍스트를 비워도 무엇이 남는가 — /compact는 흐름을 남기고, /clear는 규칙과 기억만 남기며, --continue는 아예 이전 세션을 통째로 되살린다.

/compact 실전 4단계는 다음과 같다.

# 1. 현재 사용량 확인
> /context

# 2. 60% 이상이면 압축
> /compact

# 3. 보존할 내용 지정 (focus 옵션)
> /compact focus on the API changes and database schema

# 4. 압축 후 상태 확인 (필수)
> 현재 작업 상태를 요약해줘. 어떤 파일을 수정 중이고, 다음에 뭘 해야 해?

4단계를 건너뛰면 안 된다. 압축이 무엇을 버렸는지 확인하지 않으면, 사라진 맥락 위에서 작업이 계속된다.

실무 3단계 패턴

세 패턴이 컨텍스트를 비우는 시점이 각각 다르다. 1번은 작업이 끝난 뒤에, 2번은 임계에 닿았을 때, 3번은 애초에 채우지 않는다.

Subagent — 컨텍스트 격리

Agent Teams는 여러 에이전트가 메시지로 협업하는 구조로, 전체 컨텍스트가 아니라 메시지만 오간다. "논의·협업이 필요한 복잡한 작업"에 적합하다. 팀을 실제로 띄웠을 때의 운용 규칙 — 스폰 순서, 비동기 메시지, 파일 소유권, 종료 프로토콜 — 은 팀을 굴리면 첫날 무엇이 멈추는가 편에서 따로 다뤘다.

긴 대화에서 망각을 막는 법

세션 연속성의 세 축

수명 열이 영구 → 프로젝트 → 1회분으로 짧아진다. 이 시리즈가 첫 편부터 다뤄 온 것이 맨 위 행이고, 이 절은 아래 두 행을 채운다.

MEMORY.md 작성 가이드

오른쪽 열의 네 항목 중 셋이 너무 많이 적는 실패다. 안 쓰는 것보다 다 쓰는 것이 흔한 실패라는 뜻이고, 그래서 기준이 분량("5초 안에 훑을 수 있는")으로 잡혀 있다.

실제 형태는 이렇다.

# {프로젝트} Memory

## 핵심 패턴
### 빌더 섹션 핸들러 구조
- 두 개의 빌더가 동일한 섹션 타입을 처리해야 함
- 새 섹션 타입 추가 시 양쪽 빌더 모두 핸들러 + 딕셔너리 등록 필요
- 미등록 타입은 폴백 핸들러로 빠져 콘텐츠 대부분 누락 (조용한 실패)

## 주의사항
- DOCX는 바이너리 → 직접 읽기 불가, 파서 경유 필요
- HTML escape로 raw 문자열 매칭이 실패할 수 있음

위 MEMORY.md는 원 자료가 가상 실습 소재로 명시한 예시다. 빌더 구조나 DOCX 처리 같은 내용은 어떤 프로젝트의 실제 기록이 아니라 항목이 어떤 입자도로 적히는가를 보여 주는 예시다. 옮겨 쓸 것은 내용이 아니라 형태다.

"조용한 실패(silent failure)" 같은 항목이 메모리의 진짜 가치다. 에러를 내지 않고 잘못되는 패턴은 문서에 남기지 않으면 반드시 재발한다.

session-summary — 인수인계 JSON

{
  "status": "success | failure | partial",
  "summary": "무엇을 했는지 1-2문장",
  "changes": ["변경된 파일 경로 목록"],
  "test_results": "테스트 실행 결과 요약",
  "next_steps": ["다음에 해야 할 작업 목록"],
  "blockers": ["해결 못한 이슈 목록"]
}

next_steps가 가장 중요하다. 다음 세션의 시작점이기 때문이다. 잘 쓴 것과 못 쓴 것의 차이는 명확하다.

왼쪽 셋의 문제는 목적어의 유무가 아니라 구체성이다. "계속 개발"과 "테스트"에는 대상이 아예 없고, "코드 수정"에는 대상이 있지만 원 자료가 옆에 적어 둔 대로 "어떤 코드인지 불명확"하다. 오른쪽 셋은 저마다 손댈 자리를 하나로 좁혀 둔다. 첫 행은 함수와 케이스 수(예외 3가지)까지, 셋째 행은 파일 이름(MEMORY.md)까지 내려가고, 둘째 행은 수를 세지 않는 대신 어느 문서의 무엇을 어디에 적용할지(설계 문서의 체크리스트 항목을 산출물 섹션에)를 지정한다. 셋 다 다음 세션이 읽는 즉시 착수할 수 있다.

재시작 후 자동 행동 순서를 규칙 파일에 박아두면 복구가 기계적으로 이뤄진다.

1. git status — 현재 파일 상태 확인
2. 계획 문서의 STATUS 확인 — APPROVED면 구현 계속
3. 진행 중 TODO 목록 상태 확인
4. 미완료 태스크 확인
5. 다음 단계 재개

체크포인트 주기

트리거 열의 성격이 네 가지로 갈린다. 사건 기반(결정 발생) · 시간 기반(30분) · 수치 기반(70%) · 상태 기반(세션 종료)이며, 하나만 쓰면 그 축에서 벗어난 상황을 놓친다.

하루 시나리오

09:00에 한 일(계획 문서 승인) 덕분에 11:00의 65%가 문제가 되지 않았다는 것이 이 표의 구조다. 임계를 올린 것은 오전에 파일을 하나 만들어 둔 행위다.

증상별 처방

위의 두 행이 서로 반대 방향의 실패라는 점을 같이 봐야 한다. 안 적어서 잃고, 다 적어서 못 찾는다. 처방이 둘 다 "핵심만"으로 수렴하는 이유다.

긴 작업 전 5가지 체크리스트

다섯 항목이 전부 작업을 시작하기 전에 하는 일이다. 컨텍스트가 터진 다음에 할 수 있는 것은 복구뿐이고, 복구 비용을 낮추는 조치는 전부 앞쪽에 있다.

시리즈를 닫으며

첫 편이 규칙 파일 한 장을 어디에 두고 얼마나 길게 쓸지 정했고, 앞 편이 그 옆에 서는 여덟 구성물과 지시 한 줄을 쓰는 법을 봤으며, 이 글이 그 지시를 나눠 시키고 대화를 끊는 규칙을 봤다.

세 편에서 반복된 원칙 하나만 남긴다면 이것이다. 상시로 지고 가는 것은 최소로 유지하고, 나머지는 필요할 때 불러오거나 파일로 밀어낸다. 규칙 파일에서는 @import로 상세를 밀어냈고, .claude/에서는 rules/·skills/가 조건부로 불려 왔으며, 세션에서는 /compact가 대화 이력을 요약으로 압축하고, 그 요약과 session-summary를 파일로 저장해 다음 세션에 넘기는 일은 압축 다음에 오는 별도 단계다. 셋 다 같은 문장의 다른 구현이다.

그래서 마지막 문장은 임계값이 아니라 저장 위치에 관한 것이 된다. 지금 컨텍스트를 날려도 상태가 어딘가에 남아 있는가. 남아 있으면 70%든 85%든 끊는 것이 더 빠르고, 남아 있지 않으면 그 숫자를 아무리 정확히 지켜도 언젠가 잃는다.