도입

클로드 코드에게 경쟁사 분석을 맡기고, 이런저런 수정 사항을 주고받다 보니 대화가 길어졌습니다. 처음에는 정확한 차트와 깔끔한 PDF를 만들어 주던 에이전트가, 어느 순간 이상한 데이터를 끌어오기 시작합니다. 분명 앞에서 알려 준 브랜드 색상을 무시하고, 이미 답한 질문을 다시 묻습니다.

화면 하단에 눈길을 돌리면 "23% of your context remaining"이라는 문구가 보입니다. 에이전트의 메모장이 거의 꽉 찬 것입니다. 이 현상을 이해하려면, 에이전트가 우리의 말을 어떻게 읽는지부터 알아야 합니다.

모델이 세는 글 조각이란 무엇인가

사람은 글을 단어 단위로 읽습니다. AI는 다릅니다. AI는 모델이 세는 글 조각(Token)이라는 조각 단위로 읽습니다.

모델이 세는 글 조각 하나가 정확히 단어 하나는 아닙니다. 대략 3에서 4개의 영문 글자가 하나의 모델이 세는 글 조각에 해당합니다. 쉼표 하나도 모델이 세는 글 조각 하나이고, "in"이라는 짧은 전치사도 모델이 세는 글 조각 하나입니다. 공백조차 모델이 세는 글 조각 계산에 포함됩니다. 일관된 규칙이 있는 것처럼 보이지만, 실제로는 꽤 들쭉날쭉합니다.

대략적인 기준을 하나 제시하면, 영어 기준으로 모델이 세는 글 조각 하나는 단어의 약 75%에 해당합니다.

한국어는 상황이 조금 다릅니다. 한국어 한 글자가 여러 모델이 세는 글 조각으로 쪼개지는 경우가 잦아서, 같은 의미를 담은 문장이라도 영어보다 모델이 세는 글 조각을 더 많이 소모합니다.

왜 이것이 중요합니까? 모델이 세는 글 조각은 돈이기 때문입니다. 클로드 코드를 포함한 모든 큰 규모의 언어 모델은 모델이 세는 글 조각 단위로 비용을 계산합니다. 구독 요금제를 사용하더라도, 일정 기간 내에 사용할 수 있는 모델이 세는 글 조각 총량에는 한계가 있습니다. 모델이 세는 글 조각을 낭비하면 한도를 빨리 소진합니다.

[그림 7-1] 영어 문장이 모델이 세는 글 조각으로 분해되는 예시. "Hello, how are you?"가 ["Hello", ",", " how", " are", " you", "?"]로 쪼개지는 시각적 도해]

한 번에 읽는 범위의 크기와 한계

클로드에게 메모장이 하나 있다고 상상해 보겠습니다. 대화를 시작하면, 클로드는 이 메모장에 사용자가 말한 것, 자기가 답한 것, 시스템 프롬프트, MCP 도구 목록, 프로젝트 파일 내용을 전부 빼곡히 적어 넣습니다. 이 메모장이 바로 한 번에 읽는 범위(Context Window)입니다.

이 메모장의 크기에는 물리적 한계가 있습니다. 현재 클로드 모델의 표준 한 번에 읽는 범위는 약 200,000모델이 세는 글 조각입니다. 숫자만 보면 꽤 커 보이지만, 생각보다 빠르게 채워집니다. 메모장에 들어가는 항목을 나열해 보겠습니다.

• 시스템 프롬프트: claude.md 파일 전체
• MCP 연결 서버: 연결된 각 MCP 연결 서버의 도구 정의와 설명
• 대화 기록: 사용자가 보낸 모든 메시지와 에이전트의 모든 응답
• 파일 내용: 에이전트가 읽은 코드, 워크플로우, 데이터 파일
• 도구 호출 결과: 스크립트 실행 결과, 검색 결과, 웹 웹 정보 수집 결과

프로젝트 규모가 커질수록, MCP 연결 서버를 여러 개 연결할수록, 이 항목들이 메모장을 빠르게 잠식합니다. /context 명령어를 입력하면 현재 모델이 세는 글 조각 사용 내역을 확인할 수 있습니다. 예를 들어, 한 세션에서 모델이 클로드 오퍼스 4.6이고 모델이 세는 글 조각이 22,000/200,000이라면, 이미 전체의 11%를 소비한 셈입니다.

[그림 7-2] /context 명령어 실행 결과 예시. 시스템 프롬프트, 시스템 도구, MCP 도구, 대화 기록이 각각 몇 모델이 세는 글 조각을 차지하는지 막대그래프로 보여주는 화면 캡처]

맥락이 새는 현상

메모장이 절반쯤 차면 미묘한 변화가 시작됩니다. 처음에는 정확하던 에이전트가 점차 엉뚱한 답을 내놓습니다. 이미 제공한 정보를 다시 요청하거나, 없는 사실을 지어내기도 합니다. 이 현상을 컨텍스트 로트(Context Rot)라고 부릅니다.

원인은 큰 규모의 언어 모델이 긴 문맥을 처리하는 방식에 있습니다. 모델이 세는 글 조각이 쌓일수록 모델의 품질과 정확도가 눈에 띄게 떨어집니다. 대화의 맨 처음과 맨 끝에 있는 정보는 비교적 잘 기억하지만, 중간에 있는 정보는 묻히기 쉽습니다. 이것을 "중간 소실(Lost in the Middle)" 현상이라고 합니다.

그래프를 하나 그려 본다면, 가로축은 모델이 세는 글 조각 사용량이고 세로축은 응답 품질입니다. 사용량이 50%를 넘어서면 품질 곡선이 완만한 내리막을 타다가, 70%를 지나면 가파르게 추락합니다. 이 현상은 클로드뿐 아니라 모든 큰 규모의 언어 모델에서 관찰됩니다.

[그림 7-3] 컨텍스트 사용량(가로축)과 응답 품질(세로축)의 관계를 보여주는 곡선 그래프. 60% 지점에 수직 점선을 그어 "경고 구간" 표시]

실제 작업 중에 겪는 증상은 이렇습니다. 에이전트가 갑자기 허구의 정보를 만들어 냅니다. 앞서 저장해 둔 파일의 경로를 엉뚱하게 기억합니다. 같은 질문을 반복합니다. 이런 신호가 포착되면, 모델이 세는 글 조각 메모장을 정리할 때가 된 것입니다.

60% 규칙

경쟁사 분석 워크플로우를 실행하고, 결과를 검토하고, 수정 사항을 주고받다 보면 화면 하단의 컨텍스트 잔여량 표시가 어느새 50% 아래로 내려가 있습니다. "45% of your context remaining until auto-compact"라는 문구를 본 적이 있을 것입니다.

실무에서 유용한 기준이 하나 있습니다. 컨텍스트의 60%가 채워지면 정리를 시작하라는 것입니다. 이것을 60% 규칙이라 부릅니다.

왜 하필 60%입니까? 그 시점을 넘기면 컨텍스트 로트가 실질적으로 체감되기 시작하기 때문입니다. 물론 클로드 코드에는 자동 압축(Auto-compact) 기능이 내장되어 있어서, 한계에 도달하면 스스로 대화를 압축합니다. 하지만 자동 압축은 에이전트가 어떤 정보를 보존하고 어떤 정보를 버릴지 자체적으로 판단합니다. 중요한 결정 사항이 압축 과정에서 소실될 수 있습니다.

따라서 능동적으로, 60% 지점에서 직접 정리를 수행하는 편이 안전합니다. 그렇다면 정리는 어떻게 합니까? 두 가지 도구가 있습니다.

/compact: 대화를 압축하되 기억은 남긴다

/compact 명령어를 입력하면, 클로드 코드는 지금까지의 대화 기록을 요약본으로 압축합니다. 긴 대화가 핵심만 추린 짧은 요약으로 바뀌면서, 모델이 세는 글 조각 사용량이 크게 줄어듭니다. 마치 장문의 회의록을 핵심 결정 사항 목록으로 정리하는 것과 비슷합니다.

압축 이후에도 에이전트는 이전에 무슨 작업을 했는지 대략적으로 기억합니다. 만든 파일, 실행한 도구, 도달한 결론 — 이런 것들이 요약본 안에 남아 있어서, 대화를 이어 갈 수 있습니다.

그런데 여기서 한 걸음 더 나아갈 수 있습니다. /compact 명령어 뒤에 보존하고 싶은 정보를 직접 지정하는 것입니다.

/compact keep API decisions and schema

이렇게 입력하면, 에이전트는 API 관련 결정 사항과 스키마 정보를 압축 과정에서 우선적으로 보존합니다. 브랜드 자산 경로를 잃고 싶지 않다면 /compact keep brand asset paths라고 쓸 수 있습니다. 프로젝트의 핵심 맥락이 무엇인지 사용자가 직접 알려 주는 셈입니다.

이것이 선택적 보존 전략입니다. 에이전트에게 "전부 기억해"라고 하는 대신, "이것만은 반드시 기억해"라고 말하는 것이 훨씬 효과적입니다.

/clear: 완전한 초기화

때로는 압축이 아니라 백지 상태가 필요합니다. /clear 명령어는 대화 기록을 통째로 지웁니다. 에이전트는 이전 대화에서 무엇을 했는지 전혀 기억하지 못합니다.

하지만 중요한 점이 있습니다. /clear를 실행해도 프로젝트의 파일은 그대로 남습니다. claude.md 파일, 워크플로우 문서, 도구 스크립트, 비즈니스 프로필 JSON — 디스크에 저장된 모든 파일은 건드리지 않습니다. 에이전트가 새 대화를 시작하면, claude.md를 처음부터 다시 읽고, 필요한 파일을 다시 탐색합니다. 마치 새로 출근한 비서가 업무 매뉴얼을 펼치는 것과 같습니다.

/clear를 사용하기 좋은 시점은 다음과 같습니다.

• 작업의 맥락이 완전히 달라질 때 (경쟁사 분석에서 채용 공고 웹 정보 수집으로 전환하는 경우)
• 컨텍스트 로트가 심각하여 에이전트가 반복적으로 오류를 낼 때
• 새로운 워크플로우를 깨끗한 상태에서 시작하고 싶을 때

/compact와 /clear, 언제 무엇을 쓸 것인가

두 명령어의 차이를 정리합니다.

[그림 7-4] /compact와 /clear의 동작 차이를 좌우 비교로 보여주는 다이어그램. 왼쪽은 대화 기록이 요약본으로 압축되는 모습, 오른쪽은 대화 기록이 사라지고 claude.md만 남는 모습]

실전 패턴

실무에서 이 도구들을 활용하는 흐름은 이렇습니다.

작업을 시작합니다. 에이전트와 여러 차례 대화를 주고받습니다. 화면 하단의 잔여량 표시가 40% 아래로 내려갑니다. 여기서 /compact keep brand assets and competitor list를 실행합니다. 모델이 세는 글 조각이 확보되면 작업을 이어갑니다. 작업이 끝났습니다. 다음 작업은 전혀 다른 주제입니다. 이때는 /clear를 실행하고 새로 시작합니다.

이 리듬이 몸에 익으면, 에이전트의 품질이 대화 길이에 관계없이 일정하게 유지되는 것을 체감할 수 있습니다. 모델이 세는 글 조각과 한 번에 읽는 범위는 처음 접하면 기술적으로 보이지만, 핵심은 결국 하나의 습관입니다. 메모장이 반쯤 찼으면 정리한다.

에이전트의 기억을 관리하는 방법을 익혔으니, 이제 그 기억의 첫 페이지에 해당하는 문서 — 에이전트가 매번 가장 먼저 읽는 그 파일 — 를 어떻게 작성하면 좋을지 살펴볼 차례입니다.