[Claude 활용 24회 — AI에게 일을 위임하는 법] 7/24화: 컨텍스트 관리 5단계 — 100만 토큰 시대의 절약 기술

2026년 08월 07일 13 Min Read

3줄 요약

/context 명령 하나로 지금 내 세션이 토큰을 얼마나 먹고 있는지 실시간으로 읽을 수 있다.
/compact는 토큰이 80% 찰 때 쓰는 게 아니라, 작업 단위가 끝났을 때 쓰는 것이다.
실패한 시도가 컨텍스트에 남으면 AI가 같은 실수를 반복한다 — 리셋이 정답인 순간이 있다.

컨텍스트 관리. 솔직히 말하면 6개월 전까지 이 단어를 진지하게 생각해 본 적이 없었다. 100만 토큰이면 책 한 권을 통째로 넣는 크기 아닌가. 그냥 대화하다 보면 알아서 되겠지 — 라고 생각한 게 지난달 새벽 3시에 3시간짜리 작업을 날린 직접적인 원인이었다.

4화에서 작업 지시서를 잘 쓰는 법, 5화에서 CLAUDE.md로 저장소의 헌법을 세우는 법, 6화에서 권한과 훅으로 사고를 막는 법을 다뤘다. 그 세 가지를 완벽하게 갖춰도 컨텍스트를 관리하지 못하면 세션 후반부에 AI가 헛소리를 시작한다. 이번 화에서는 그 원인과 해법을 파헤친다.

어젯밤 3시간이 증발한 이유

무중단이 기본인 시스템의 결제 모듈을 리팩터링하고 있었다. 기존 코드는 5년 전에 작성된 것이라 인터페이스가 뒤엉켜 있었고, Claude Code에 작업을 맡기기로 했다. CLAUDE.md도 잘 써놨고, 작업 지시서도 4화에서 배운 대로 맥락·제약·완료조건·검증방법 네 가지를 다 넣었다.

처음 1시간은 순조로웠다. 기존 인터페이스를 분석하고, 새 설계를 제안받고, 합의했다. 2시간째에 구현이 진행됐다. 테스트도 하나씩 붙었다. 그런데 3시간째 접어들면서 이상한 조짐이 보였다.

30분 전에 합의하고 삭제한 함수를 다시 만들겠다고 했다.
1시간 전에 버린 인터페이스 구조를 기준으로 테스트를 짜기 시작했다.
“이 방식은 아까 논의해서 폐기했잖아”라고 말하면 “맞습니다, 죄송합니다” 하고는 — 5분 뒤에 또 같은 걸 했다.

원인을 찾는 데 10분이면 충분했다. /context를 쳐보니 이런 화면이 나왔다.

> /context

Context window usage:
  System prompt:        12,847 tokens (CLAUDE.md + tools + instructions)
  Conversation:        184,291 tokens
  ─────────────────────────────
  Total:               197,138 / 200,000 tokens (98.6%)

⚠ Context is almost full. Consider using /compact to free up space.

98.6%. 거의 꽉 차 있었다. 3시간 동안의 모든 대화 — 초반에 시도했다 실패한 접근 3번, 중간에 바꾼 설계 방향, 버린 코드 조각들 — 이 전부 컨텍스트에 남아 있었다. Claude는 그 모든 것을 ‘참고’하느라 정작 최근의 합의사항을 놓치고 있었던 것이다.

결국 새 세션을 열고 최종 합의 사항만 정리해서 다시 지시했다. 같은 작업이 40분 만에 끝났다. 3시간 중 2시간 20분이 컨텍스트 관리 실패로 인한 순수 낭비였다.

이날 이후로 컨텍스트 관리를 진지하게 공부하기 시작했다. 그리고 깨달은 것은, 이건 단순한 ‘토큰 아끼기’가 아니라 AI에게 일을 위임하는 방식 자체를 바꾸는 기술이라는 점이었다.

컨텍스트 윈도우는 ‘방 크기’가 아니라 ‘작업 기억’이다

컨텍스트 윈도우를 처음 접하면 “이 안에 들어가는 글자 수”로 이해한다. 틀린 말은 아닌데, 이 이해만으로는 실전에서 쓸모가 없다. 20년간 시스템을 운영하면서 배운 것 중 하나는, 용량이 충분해 보여도 관리하지 않으면 반드시 문제가 생긴다는 것이다. 메모리도 그렇고, 디스크도 그렇고, 컨텍스트도 그렇다.

100만 토큰이면 충분하지 않나요?

2026년 7월 현재, Claude의 컨텍스트 윈도우는 200K 토큰이 기본이고, 확장 모드에서 훨씬 더 긴 컨텍스트를 처리할 수 있다. 1화에서 다뤘듯이 이건 책 한 권 분량이다. “이 정도면 관리 안 해도 되지 않나?” 싶을 수 있다.

문제는 용량이 아니라 품질이다. Nelson Liu 등의 연구(“Lost in the Middle: How Language Models Use Long Contexts”)가 보여줬듯이, 대형 언어 모델은 컨텍스트의 처음과 끝에 있는 정보에 가장 강하게 주의를 기울이고, 중간에 있는 정보는 상대적으로 놓치기 쉽다. 컨텍스트가 길어질수록 이 현상은 심해진다.

이걸 실무 언어로 바꾸면 이렇다:

시스템 프롬프트(CLAUDE.md 등): 컨텍스트 맨 앞에 위치. 가장 잘 참조된다.
가장 최근 대화: 컨텍스트 맨 뒤. 역시 잘 참조된다.
2시간 전의 실패한 시도 내역: 컨텍스트 중간 어딘가. 참조는 되는데, 정확하게 참조된다는 보장이 없다.

내 리팩터링 세션에서 정확히 이 일이 일어났다. 중간에 묻힌 ‘폐기된 설계’와 맨 끝의 ‘현재 합의’가 충돌했고, 모델은 양쪽을 왔다 갔다 하면서 일관성을 잃었다.

자동 압축은 만능이 아니다

Claude Code는 컨텍스트가 가득 차면 자동으로 압축(auto-compaction)을 수행한다. 오래된 대화를 요약해서 토큰을 확보하는 방식이다. “그러면 알아서 관리해 주는 거 아닌가?” 라고 생각할 수 있는데, 여기에 함정이 있다.

자동 압축이 일어나면 이런 일들이 벌어진다:

세부 사항이 소실된다 — 코드의 특정 라인 번호, 변수명, 에러 메시지의 정확한 문구 같은 것들이 요약 과정에서 뭉개진다.
맥락의 우선순위가 뒤섞인다 — 내가 “이건 중요하다”고 표시하지 않은 정보는 압축 과정에서 비중이 줄어든다. 하지만 실제로 중요한 게 뭔지는 나만 안다.
실패한 시도와 성공한 시도가 같은 가중치로 요약된다 — “A 방식을 시도했다가 실패해서 B 방식으로 전환했다”가 “A와 B를 시도했다”로 압축될 수 있다. 그러면 Claude는 다시 A를 시도한다.

자동 압축은 안전망이다. 비행기의 비상 산소마스크 같은 것이지, 평소에 의존할 호흡 장치가 아니다. 컨텍스트가 자동 압축될 지경까지 가기 전에 내가 직접 관리해야 한다.

컨텍스트 = 작업 기억

나는 컨텍스트 윈도우를 사람의 작업 기억(working memory)에 비유한다. 인지심리학에서 작업 기억의 용량은 대략 “7±2 항목”이라고 한다. 용량이 한정돼 있고, 쓸데없는 것이 들어차면 정말 필요한 것을 처리하지 못한다.

AI의 컨텍스트 윈도우도 마찬가지다. 용량은 수십만 토큰으로 훨씬 크지만, 핵심 원리는 같다:

관련 없는 정보가 많으면 → 관련 있는 정보를 놓친다.
모순된 정보가 공존하면 → 일관성 있는 응답이 불가능하다.
오래된 정보가 새 정보와 충돌하면 → 어느 쪽을 따를지 예측할 수 없다.

컨텍스트 관리란 결국 “AI의 작업 기억에 무엇을 넣고, 무엇을 빼고, 언제 리셋할 것인가”를 결정하는 기술이다. AI에게 일을 위임하는 시대에, 이건 관리자가 팀원의 업무 컨텍스트를 정리해 주는 것과 같다. 좋은 관리자는 팀원에게 필요한 정보만 전달하고, 지난 회의에서 폐기된 안건을 다시 꺼내지 않는다.

실전 컨텍스트 관리 — 5가지 기술

이론은 충분하다. 이제 실제로 쓸 수 있는 기술 다섯 가지를 하나씩 짚어 보겠다. 모두 내가 매일 쓰고 있는 것들이고, 복사해서 바로 실행할 수 있는 형태로 정리했다.

기술 1: /context로 현재 상태 읽기

운전할 때 계기판을 안 보는 사람은 없다. 컨텍스트 관리의 첫 번째 기술은 현재 상태를 읽는 것이다.

> /context

이 한 줄이 보여주는 정보:

시스템 프롬프트 토큰 — CLAUDE.md, 도구 정의, 시스템 지시문이 차지하는 고정 비용. 5화에서 “500줄짜리 CLAUDE.md는 오히려 성능을 깎는다”고 했던 이유가 여기서 드러난다. CLAUDE.md가 크면 이 고정 비용이 커지고, 실제 대화에 쓸 수 있는 공간이 줄어든다.
대화 토큰 — 세션 시작부터 지금까지의 모든 대화(내 입력 + AI 응답 + 도구 호출 결과)가 누적된 양.
전체 사용률 — 몇 퍼센트를 쓰고 있는가. 내 경험상 70%를 넘으면 주의, 85%를 넘으면 즉시 조치가 필요하다.

나는 작업 시작 시, 그리고 큰 작업 단위가 끝날 때마다 /context를 친다. 습관을 만드는 데 일주일이면 충분하다. 이것만으로도 “갑자기 AI가 이상해졌는데 원인을 모르겠다”는 상황의 절반은 사라진다.

사용률별 행동 기준을 정리하면 이렇다:

컨텍스트 사용률별 행동 기준
──────────────────────────────
  0 ~ 50%   정상. 자유롭게 작업 진행.
 50 ~ 70%   주시. 큰 파일 붙여넣기는 자제.
 70 ~ 85%   /compact 고려. 완료된 작업 단위가 있으면 즉시 압축.
 85 ~ 95%   /compact 필수. 또는 세션 분할 검토.
 95% ~      새 세션 시작 권장. 자동 압축이 곧 발동하는 영역.

기술 2: /compact — 타이밍이 전부다

대부분의 사람이 /compact를 토큰이 부족해질 때 쓴다. 이게 가장 흔한 실수다. 토큰이 90% 찬 시점에 /compact를 치면, 이미 중요한 맥락과 불필요한 맥락이 뒤엉켜 있어서 압축 품질이 떨어진다.

/compact는 작업 단위(task boundary)가 끝났을 때 쓰는 것이다.

예를 들어 보겠다. “레거시 결제 모듈 리팩터링”이라는 큰 작업을 아래처럼 쪼갰다고 하자:

기존 코드 분석 및 인터페이스 설계
새 인터페이스 구현
기존 호출부 마이그레이션
통합 테스트

1단계가 끝나고 설계가 확정된 시점에 /compact를 친다:

> /compact 결제 모듈 리팩터링 1단계 완료. 핵심 합의: PaymentGateway 인터페이스를 
  process()와 refund() 두 메서드로 단순화. 기존 6개 메서드는 내부 private으로 
  이동. 타입은 PaymentResult(success: bool, transaction_id: str, error: str | None).

여기서 핵심은 /compact 뒤에 붙인 커스텀 지시문이다. 단순히 /compact만 치면 Claude가 “알아서” 요약하는데, 이때 내가 중요하다고 생각하는 것과 Claude가 중요하다고 판단하는 것이 다를 수 있다. 무엇을 반드시 기억해야 하는지를 명시적으로 알려주는 것이 압축 품질을 극적으로 높인다.

/compact 사용의 황금률:

Do: 작업 단위가 끝났을 때 쓴다. “분석 끝 → compact → 구현 시작” 처럼.
Do: 핵심 합의사항을 compact 지시문에 명시한다.
Do: compact 직후 /context로 확보된 공간을 확인한다.
Don’t: 토큰이 꽉 찬 후에야 급하게 쓴다.
Don’t: 한 세션에서 5번 이상 compact한다. 그 정도면 세션을 나눠야 한다.
Don’t: 디버깅 중간에 compact한다. 에러 맥락이 날아간다.

기술 3: 세션 분할 — 마이크로서비스처럼 생각하기

20년간 모놀리스를 마이크로서비스로 쪼개는 작업을 해왔다. 컨텍스트 관리에서도 같은 원리가 적용된다. 하나의 거대한 세션보다 목적이 명확한 여러 세션이 낫다.

세션 분할이 필요한 신호:

작업이 2시간 이상 걸릴 것으로 예상될 때
서로 독립적인 서브태스크가 3개 이상일 때
/context에서 70%를 넘었고, 아직 절반도 안 했을 때
작업 방향이 중간에 크게 바뀌어서 이전 맥락이 오히려 방해될 때

실전 세션 분할 패턴을 보겠다. 아래는 내가 실제로 쓰는 방식이다:

# 세션 1: 분석 및 설계
# 목표: 기존 코드를 분석하고 새 인터페이스를 확정한다.
# 산출물: DESIGN.md (새 인터페이스 명세, 마이그레이션 계획)

"src/payments/ 아래 결제 관련 코드를 분석해 줘.
 현재 인터페이스 목록, 각 메서드의 호출 빈도(git log 기준),
 의존 관계를 정리하고, 리팩터링 설계를 DESIGN.md로 만들어 줘."

# → 세션 1 끝. DESIGN.md가 파일 시스템에 남아 있다.

# 세션 2: 구현
# 목표: DESIGN.md에 따라 새 인터페이스를 구현한다.
# 입력: DESIGN.md (세션 1의 산출물)

"DESIGN.md를 읽고, 거기 적힌 설계에 따라 PaymentGateway를 구현해 줘.
 기존 코드는 건드리지 말고, 새 파일에 먼저 만들어."

# → 세션 2 끝. 새 구현체가 파일 시스템에 남아 있다.

# 세션 3: 마이그레이션 + 테스트
# 목표: 기존 호출부를 새 인터페이스로 전환하고 테스트를 통과시킨다.

"PaymentGateway 새 구현체가 src/payments/gateway_v2.py에 있어.
 기존 호출부를 하나씩 전환하고, 각 전환마다 테스트를 돌려 줘."

핵심은 세션 사이의 인터페이스를 파일 시스템에 남기는 것이다. DESIGN.md, TODO.md, 또는 코드 자체가 세션 간 통신 채널 역할을 한다. 마이크로서비스가 API로 통신하듯이, 세션은 파일로 통신한다.

이 방식의 장점:

각 세션이 깨끗한 컨텍스트로 시작하므로 “중간에 묻힌 정보” 문제가 없다.
세션 1에서의 실패한 시도가 세션 2에 전파되지 않는다.
각 세션의 작업 지시가 간결해진다 — 4화에서 배운 좋은 지시서의 특성이다.
병렬 처리도 가능하다 — 8화에서 다룰 Git worktree와 결합하면 여러 세션을 동시에 돌릴 수 있다.

기술 4: 프롬프트 캐시가 작동하는 조건

프롬프트 캐시(prompt cache)는 토큰 비용과 응답 속도를 동시에 줄여 주는 기능이다. Anthropic의 프롬프트 캐싱 문서에 따르면, 동일한 프롬프트 접두어(prefix)가 반복될 때 캐시가 적중하면 해당 부분의 처리 비용이 대폭 줄어든다.

Claude Code에서 프롬프트 캐시가 작동하는 원리를 단순화하면 이렇다:

┌─────────────────────────────────────────────┐
│ 시스템 프롬프트 (CLAUDE.md + 도구 정의)       │ ← 캐시 대상 ①
├─────────────────────────────────────────────┤
│ 대화 이력 (이전 턴들)                         │ ← 캐시 대상 ② (접두어가 같을 때)
├─────────────────────────────────────────────┤
│ 현재 사용자 입력                              │ ← 매번 새로움
└─────────────────────────────────────────────┘

캐시 적중 조건:
  1. 시스템 프롬프트가 이전 요청과 동일하다.
  2. 대화 이력의 앞부분이 이전 요청과 동일하다.
  3. 캐시 TTL(수 분) 이내에 다음 요청이 왔다.

→ 세 조건이 모두 맞으면: 캐시 적중. 빠르고 저렴.
→ 하나라도 깨지면: 캐시 미스. 처음부터 처리.

실전에서 캐시를 깨뜨리는 흔한 행동:

세션 중간에 CLAUDE.md를 수정한다 — 시스템 프롬프트가 바뀌므로 캐시 전체가 무효화된다. CLAUDE.md를 고치고 싶으면 현재 세션을 끝낸 뒤 수정하고 새 세션을 여는 것이 낫다.
오랜 시간 아무 입력 없이 방치한다 — 캐시 TTL이 만료된다. 점심 먹고 돌아와서 이어 작업하면 첫 응답이 느릴 수 있다. 이건 피할 수 없으니 알고만 있으면 된다.
세션을 너무 자주 리셋한다 — 새 세션마다 시스템 프롬프트부터 다시 처리해야 한다. 불필요한 리셋은 캐시 효율을 떨어뜨린다.

1화에서 다뤘던 2026년 7월의 변화 중 하나가 “대화 중 도구 교체 시 프롬프트 캐시 유지”였다. 이전에는 MCP 서버를 연결하거나 도구 세트를 바꾸면 캐시가 깨졌는데, 이제는 도구가 바뀌어도 시스템 프롬프트의 나머지 부분에 대한 캐시가 유지된다. 이건 특히 MCP 서버를 여러 개 쓰는 환경에서 큰 차이를 만든다 — 10화에서 자세히 다룰 예정이다.

캐시를 최대한 활용하는 습관:

CLAUDE.md는 세션 사이에만 수정한다.
연속 작업은 세션을 유지하면서 /compact로 관리한다 — 세션 리셋보다 캐시 친화적.
큰 파일을 읽을 때는 처음에 한 번 읽고 이후 참조하게 한다. 같은 파일을 반복 요청하면 컨텍스트만 낭비된다.

기술 5: /effort — 상황에 맞는 토큰 배분

모든 질문에 같은 수준의 노력을 기울일 필요는 없다. 간단한 문법 질문에 200K 토큰을 태우고, 복잡한 아키텍처 설계에도 200K 토큰을 태우는 건 비효율적이다.

/effort 명령으로 Claude의 응답 수준을 조절할 수 있다:

> /effort low      # 간단한 질문, 빠른 답변. 토큰 최소 사용.
> /effort medium   # 기본값. 대부분의 작업에 적합.
> /effort high     # 복잡한 분석, 설계, 대규모 리팩터링.

나는 이런 기준으로 쓴다:

low: “이 에러 메시지 뭔 뜻이야?”, “이 함수 시그니처 바꿔 줘”, 코드 포맷팅 같은 단순 작업.
medium: 일반적인 기능 구현, 버그 수정, 테스트 작성.
high: 아키텍처 설계, 복잡한 리팩터링, 성능 최적화처럼 “깊이 생각해야 하는” 작업.

세션 초반에 빠른 질문들은 /effort low로 처리하고, 핵심 구현에 들어갈 때 /effort high로 올리면 같은 컨텍스트 안에서도 토큰 분배가 효율적이 된다.

컨텍스트 오염 — 리셋이 정답인 순간

이 글에서 가장 중요한 섹션이다. 위의 5가지 기술을 다 써도, 리셋해야 할 순간을 놓치면 나머지가 다 무의미해진다.

컨텍스트 오염이란

컨텍스트 오염(context pollution)은 세션 내에 축적된 잘못된 정보가 이후 응답의 품질을 떨어뜨리는 현상이다. 내가 이 용어를 자주 쓰는 이유는, 이게 데이터베이스의 데이터 오염과 정확히 같은 패턴이기 때문이다.

데이터베이스에서 잘못된 레코드 하나가 들어가면, 그 레코드를 참조하는 모든 쿼리가 잘못된 결과를 낸다. 컨텍스트도 마찬가지다. 실패한 시도가 컨텍스트에 남아 있으면, Claude는 그 실패를 “참고”해서 같은 방향으로 (또는 과도하게 반대 방향으로) 움직인다.

구체적인 오염 패턴:

패턴 A — 실패 반복: “이 방법으로 해 봤는데 에러가 났어” → Claude가 같은 방법의 변형을 계속 시도. 근본적으로 다른 접근이 필요한데 이전 시도에 끌려간다.
패턴 B — 유령 제약: 세션 초반에 “이건 하지 마”라고 말했는데, 나중에 상황이 바뀌어서 그게 필요해진 경우. Claude는 초반 제약을 기억하고 있어서 명시적으로 풀어줘도 소극적으로 행동한다.
패턴 C — 코드 유령: 이미 삭제한 파일이나 함수를 Claude가 계속 참조. 컨텍스트에는 “그 파일이 존재했을 때”의 대화가 남아 있기 때문.
패턴 D — 방향 혼란: “A 방식으로 가자” → 중간에 “아니다, B로 바꾸자” → Claude가 A와 B를 섞어서 하이브리드(=아무도 원하지 않는) 결과물을 낸다.

리셋이 정답인 순간 5가지

다음 중 하나라도 해당되면, /compact보다 새 세션 시작이 정답이다:

같은 에러를 3번 이상 만났다 — Claude가 이전 실패를 변형해서 재시도하는 루프에 빠진 것이다. 새 세션에서 에러 메시지만 깨끗하게 전달하면 전혀 다른 해법이 나온다.
작업 방향이 180도 바뀌었다 — “REST API로 만들자”에서 “아니다 GraphQL로 가자”로 바뀐 경우. 이전 세션의 REST 관련 대화가 전부 오염원이 된다.
“아까 얘기한 그 함수”를 Claude가 못 찾는다 — 컨텍스트 중간에 묻혀서 참조 정확도가 떨어진 상태. 자동 압축을 거쳤다면 더욱 그렇다.
/context에서 85%를 넘었고, 아직 핵심 작업이 남아 있다 — 여기서 /compact를 써도 얼마 못 간다. 중요한 결정을 문서로 남기고 새 세션에서 재시작.
Claude의 응답 톤이 바뀌었다 — 이건 미묘한 신호다. 초반에는 자신감 있게 코드를 짜던 Claude가 후반에 “이렇게 해 볼 수 있을 것 같습니다…”, “확실하지는 않지만…” 식으로 말하기 시작한다면, 컨텍스트 내의 모순된 정보 때문에 확신을 잃은 것일 수 있다.

리셋할 때의 체크리스트

새 세션을 열기 전에 반드시 해야 할 것:

새 세션 전 체크리스트
──────────────────────────────
□ 현재까지의 핵심 결정사항을 파일로 저장했는가?
  (DESIGN.md, TODO.md, 코드 주석 등)
□ 작업 중인 코드의 현재 상태가 파일 시스템에 반영됐는가?
  (커밋하지 않았더라도 최소한 저장)
□ 새 세션에 전달할 컨텍스트를 한 문단으로 정리할 수 있는가?
□ 이전 세션에서 실패한 접근법을 명시적으로 기록했는가?
  ("A 방식은 X 이유로 실패. B 방식으로 전환함")

마지막 항목이 중요하다. 새 세션에 “A 방식은 안 돼”라고만 말하면 Claude가 왜 안 되는지 모른 채 다른 길을 찾는다. “A 방식은 X 이유로 안 된다”고 말하면 X를 피하면서 근본적으로 다른 접근을 한다.

compact vs. reset — 판단 기준 정리

마지막으로 둘 사이의 판단 기준을 표로 정리한다:

상황                                    → /compact    → 새 세션
────────────────────────────────────────────────────────────────
작업이 순조롭고 단위만 바뀜              ✅            
실패한 시도가 1~2회                      ✅            
실패한 시도가 3회 이상                                 ✅
작업 방향이 완전히 바뀜                                ✅
사용률 70~85%                            ✅            
사용률 85% 이상                                        ✅
Claude 응답 품질이 눈에 띄게 떨어짐                     ✅
파일 구조가 크게 바뀜 (삭제/이동 다수)                  ✅
빠른 질문을 이어서 하고 싶음             ✅

6화에서 “프롬프트로 ‘하지 마’는 통제가 아니다”라고 했던 것을 떠올려 보라. 비슷한 원리다. 컨텍스트에 남은 오염 데이터에게 “무시해”라고 말하는 건 통제가 아니다. 오염원을 제거하는 것만이 통제다. 그리고 오염원 제거의 가장 확실한 방법은 새 세션이다.

실전 시나리오: 2시간짜리 작업을 세션 3개로 나누기

앞에서 다룬 기술들을 하나의 시나리오에 엮어 보겠다. 가상의 여행 예약 시스템에서 검색 기능을 개선하는 작업이다.

세션 1: 탐색과 설계 (약 30분)

# 세션 시작 직후 /context 확인
> /context
Total: 11,240 / 200,000 tokens (5.6%)   ← 깨끗한 시작

# /effort 설정: 탐색이므로 medium
> /effort medium

# 작업 지시
"src/search/ 아래 코드를 읽고 현재 검색 로직을 분석해 줘.
 병목 지점, 개선 가능한 부분, 권장 구조를 SEARCH_REDESIGN.md로 정리해."

# ... 30분 작업 ...

# 작업 완료 후 /context 확인
> /context
Total: 67,891 / 200,000 tokens (34.0%)   ← 여유 있음

# 산출물 확인: SEARCH_REDESIGN.md가 파일 시스템에 생성됨
# 세션 1 종료

세션 2: 핵심 구현 (약 50분)

# 새 세션 시작 — 깨끗한 컨텍스트
> /context
Total: 11,240 / 200,000 tokens (5.6%)

# 핵심 구현이므로 effort 올림
> /effort high

# 세션 1의 산출물을 입력으로 사용
"SEARCH_REDESIGN.md를 읽고, 거기 적힌 '방안 B: 역인덱스 기반 검색'을 구현해 줘.
 기존 코드는 건드리지 말고 src/search/engine_v2.py에 새로 만들어.
 단위 테스트도 함께."

# ... 구현 진행 ...
# 중간에 한 번 실패 (인덱스 구조 문제) → 수정

# /compact로 실패 시도 정리
> /compact 역인덱스 구현 진행 중. 초기에 trie 구조를 시도했으나 메모리 초과로
  해시맵 기반으로 전환 완료. 현재 engine_v2.py 구현 80%, 테스트 3개 통과.

> /context
Total: 48,210 / 200,000 tokens (24.1%)   ← compact 후 여유 확보

# 나머지 구현 완료
# 세션 2 종료

세션 3: 통합과 정리 (약 40분)

# 새 세션
> /effort medium

"src/search/engine_v2.py가 새 검색 엔진이야.
 기존 search_handler.py의 호출부를 engine_v2를 사용하도록 마이그레이션하고,
 통합 테스트를 돌려서 전부 통과시켜 줘.
 마이그레이션 완료 후 engine_v1.py는 삭제해."

# ... 40분 뒤 완료 ...
# 총 소요: 약 2시간. 세션당 평균 사용률 30~40%.
# 3시간 단일 세션 → 2시간 3세션으로 시간도 줄고 품질도 올랐다.

이 패턴의 본질은 각 세션이 명확한 입력과 출력을 가진다는 것이다. 세션 1의 출력(SEARCH_REDESIGN.md)이 세션 2의 입력이 되고, 세션 2의 출력(engine_v2.py)이 세션 3의 입력이 된다. 파일 시스템이 세션 간의 메시지 큐 역할을 한다.

AI에게 일을 위임하는 시대에, 컨텍스트 관리는 팀원에게 브리핑하는 기술과 같다. 좋은 관리자는 팀원에게 필요한 정보만 전달하고, 지난 회의에서 폐기된 안건을 다시 꺼내지 않는다. 그리고 작업 범위가 바뀌면 새 미팅을 잡는다.

이번 회차의 수익화 지점

“컨텍스트 관리를 어떻게 팔 수 있냐”고? 의외로 직접적이다.

이번 화에서 다룬 세션 분할 패턴, /compact 타이밍 가이드, 리셋 판단 체크리스트 — 이것들을 특정 도메인에 맞게 구체화하면 “AI 활용 워크플로우 템플릿”이 된다. 예를 들어, “프론트엔드 리팩터링 5단계 세션 분할 가이드”, “레거시 마이그레이션 AI 협업 체크리스트”, “기술 문서 작성 3세션 패턴” 같은 것들이다.

많은 조직이 AI 도구를 도입했지만 “왜 20분 만에 AI가 이상한 소리를 하는지” 모른 채 포기한다. 컨텍스트 관리를 알려주는 것만으로도 — 그들의 도구 활용도가 2배는 올라간다. 이런 노하우를 조직 맞춤형 교육이나 가이드 문서로 만들어 팔 수 있다. 18화에서 다루겠지만 Microsoft Research의 연구에 따르면, 조직 내 AI 도구 정착률 격차가 크다. 그 격차를 메우는 교육 콘텐츠의 수요는 당분간 사라지지 않는다.

다음 화 예고: 8화에서는 체크포인트와 Git worktree를 다룬다. 리팩터링 3방향을 동시에 시도하고, 최선만 채택하는 방법 — Plan Mode에서 설계하고, 실행하고, /review로 검증하는 파이프라인을 완성한다. 컨텍스트를 잘 관리하는 게 이번 화였다면, 다음 화는 그 위에서 안전하게 실험하는 법이다.

📚 시리즈: Claude 활용 24회 — AI에게 일을 위임하는 법 (총 24화 중 7화)
◀ 이전 6화 (다음 차수는 아직 게시되지 않았습니다)

자주 묻는 질문

Claude Code에서 /context 명령어는 어떤 역할을 하나요?

/context 명령어를 입력하면 현재 세션의 컨텍스트 윈도우 사용량을 실시간으로 확인할 수 있습니다. 시스템 프롬프트, 대화 내용 등이 각각 몇 토큰을 차지하고 있는지, 전체 한도 대비 몇 퍼센트를 사용 중인지 한눈에 볼 수 있어 세션 관리의 출발점이 됩니다.

Claude Code /compact는 언제 사용하는 게 가장 좋나요?

/compact는 토큰이 80% 찼을 때 쓰는 것이 아니라, 하나의 작업 단위가 끝났을 때 사용하는 것이 효과적입니다. 컨텍스트가 거의 꽉 찬 상태에서 계속 작업하면 AI가 이전에 폐기한 접근법을 다시 시도하는 등 혼란을 일으킬 수 있으므로, 작업 전환 시점에 정리하는 습관이 중요합니다.

컨텍스트 윈도우가 꽉 차면 AI가 왜 같은 실수를 반복하나요?

컨텍스트에 실패한 시도, 버린 코드, 폐기된 설계 방향이 모두 남아 있으면 AI가 그것들을 여전히 유효한 참고 자료로 취급하기 때문입니다. 그 결과 최근에 합의한 사항보다 오래된 정보에 끌려가 이미 폐기한 방식을 다시 제안하게 됩니다. 이런 경우에는 새 세션을 열고 최종 합의 사항만 정리해서 다시 지시하는 리셋이 정답일 수 있습니다.