Claude Code는 어떻게 장기 작업을 버티는가

Claude Code도 모든 대화를 한꺼번에 읽을 수는 없습니다. AI가 한 번에 읽고 참고할 수 있는 범위를 컨텍스트 윈도우라고 합니다. 대화가 이 한도에 가까워지면 Claude Code는 앞선 내용을 요약하고, 그 과정에서 대화에만 있던 정보가 빠지기도 합니다. 그런데 앤트로픽은 바로 이 도구에 몇 시간씩 이어지는 작업을 맡길 수 있도록 만들었습니다. Claude Code는 이런 한계를 안고도 어떻게 장기 작업을 이어 갈까요.

문서와 실제 동작을 함께 놓고 보면, 답은 모든 정보를 컨텍스트 윈도우 안에 계속 쌓아 두는 데 있지 않습니다. 필요한 정보를 대화 밖에 남겨 두고, 필요할 때 다시 불러오는 구조에 있습니다. 압축은 다음 작업을 위한 인계서를 남기고, 태스크와 메모리는 대화 밖에 원본을 두며, 서브에이전트는 부피가 큰 탐색을 별도의 작업 공간에서 처리합니다.

앤트로픽은 2025년 9월 엔지니어링 블로그에서 장기 작업을 이렇게 설명했습니다. 작업에 필요한 토큰이 컨텍스트 윈도우의 한도를 넘어, AI가 작업 전체를 한꺼번에 볼 수 없는 경우입니다. AI의 성능이 아무리 좋아도 이 한계는 사라지지 않습니다. 앤트로픽은 이를 예외 상황으로 보지 않고, 처음부터 감안해야 할 조건으로 삼아 세 가지 해법을 제시했습니다. 압축(compaction), 구조화된 노트 작성(structured note-taking), 서브에이전트 구조(sub-agent architectures)입니다.

문서에 적힌 설계가 Claude Code 안에서 실제로 어떻게 움직이는지도 확인했습니다. 이 글의 실험은 2026년 7월 20일과 21일 Windows 11에서 Claude Code v2.1.211을 claude -p 자동 실행(headless)으로 구동해 얻은 결과입니다. 공식 문서도 같은 기간에 열람한 내용을 기준으로 삼았습니다.

장기 작업은 AI와 하네스가 함께 만든다

Claude Code 안에서 답을 만들고 판단하는 AI 모델과, 그 모델을 실제로 일하게 만드는 Claude Code는 같은 것이 아닙니다. 공식 문서는 Claude Code를 "Claude를 감싼 에이전트 하네스(agentic harness)"라고 부릅니다. 하네스는 모델에 도구와 컨텍스트 관리, 실행 환경을 붙여 실제로 일할 수 있게 만드는 바깥 장치입니다.

작업 흐름은 단순합니다. 맥락을 모으고, 행동하고, 결과를 검증합니다. 이 흐름을 되풀이하다 컨텍스트가 차오르면 하네스가 개입합니다. 오래된 도구 출력부터 비우고, 그래도 자리가 부족하면 대화를 요약합니다.

여기서 모델과 하네스의 역할이 갈립니다. 모델 성능은 눈앞에 보이는 정보를 얼마나 잘 처리하는지를 정합니다. 하네스는 어떤 정보를 눈앞에 남기고, 무엇을 다시 불러올지를 정합니다. 컨텍스트 윈도우 밖으로 밀려난 정보는 좋은 모델도 저절로 되살릴 수 없기 때문입니다. 장기 작업은 이 둘이 함께 만듭니다. 공식 문서의 표현을 그대로 옮긴 것은 아니지만, 세 가지 설계를 이해하는 데 필요한 구분입니다.

앤트로픽의 엔지니어링 블로그도 세 해법을 설명할 때 Claude Code를 거듭 예로 듭니다. 압축은 대화 기록을 모델에 넘겨 요약하게 하는 방식으로 구현한다고 설명하고, 구조화된 노트 작성의 예로는 Claude Code가 만드는 할 일 목록과 CLAUDE.md를 듭니다. 공식 Cookbook은 Claude Code가 이 전략 가운데 여러 가지를 실제 제품에 적용해 쓰고 있다고 밝힙니다. 세 해법은 논문 속 구상이 아니라, 지금 Claude Code가 장기 작업을 이어 가는 방식입니다.

압축은 대화를 인계서로 바꾼다

수동으로 /compact를 실행하자 122,426토큰이던 대화가 요약 하나로 바뀌었습니다. 그러나 이 요약은 지나간 내용을 짧게 줄인 줄글이 아니었습니다. 일정한 틀을 갖춘 문서였고, 다른 실험 세션에서도 같은 틀이 반복해서 나타났습니다.

그 안에는 "Pending Tasks"라는 섹션이 있었습니다. 진행 중이던 태스크 4개가 완료 1개와 미완료 3개로 나뉘어 실렸습니다. 압축을 마친 뒤 도구 사용을 금지하고 남은 태스크를 묻자, Claude Code는 미완료 3개를 정확히 답했습니다.

요약의 끝부분은 더 분명했습니다. "전체 기록은 여기서 읽어라"라며 세션 원본 파일(JSONL)의 절대 경로를 가리켰고, "중단이 없었던 것처럼 마지막 작업을 이어가라"는 지시로 끝났습니다.

압축은 대화를 지우고 새로 시작하는 기능이 아니었습니다. 다음 작업자가 일을 이어받을 수 있도록 인계서를 만드는 기능에 가까웠습니다. 무슨 일이 있었는지, 무엇을 마쳤고 무엇이 남았는지, 자세한 기록은 어디에 있는지를 함께 남깁니다. 대화 원문도 없어지지 않습니다. 디스크의 세션 파일에는 그대로 있고, 당장 모델이 보는 컨텍스트에서 빠질 뿐입니다.

다만 이 결과는 Fable 5를 부모 모델로 쓴 세션에서 수동 압축을 한 차례 실행해 얻었습니다. 요약의 틀이나 압축 시점이 앞으로도 같다고 보장되지는 않습니다. 버전과 모델에 따라 달라질 수 있습니다.

잃으면 안 되는 상태는 대화 밖에 둔다

두 번째 설계는 더 단순합니다. 사라지면 안 되는 상태는 대화에만 두지 않습니다. 대화 밖에 저장해 두고 필요할 때 다시 불러옵니다.

먼저 태스크가 그랬습니다. 앞선 실험의 태스크 4개는 요약에 잘 담겼기 때문에 살아남은 것처럼 보입니다. 하지만 압축 직후 태스크 목록 도구(TaskList)를 부르자 4개의 상태가 모두 그대로 돌아왔습니다. 세션 기록에는 압축 뒤 태스크 도구의 스키마, 곧 도구 사용법 정의를 다시 불러온 흔적도 남아 있었습니다. 태스크 상태 자체가 대화 기록 바깥에 있었던 것입니다. 요약이 인계서라면 태스크 목록은 인계서와 별개로 보존되는 원장에 가깝습니다.

메모리도 같은 원리로 움직였습니다. 공식 문서에 따르면 Claude Code의 auto memory는 Claude가 스스로 적어 두는 노트입니다. 목차 파일인 MEMORY.md의 첫 200줄, 최대 25KB를 세션이 시작될 때마다 불러옵니다. 이 경로를 확인하려고 MEMORY.md에 make zephyr-check라는 명령이 있다는 가짜 사실을 하나 심었습니다. 압축 뒤 도구 사용을 금지하고 물었을 때 Claude Code는 이 내용을 정확히 답했습니다.

이 결과만으로는 메모리가 요약에 담겨 살아남았는지, 별도의 경로로 다시 들어왔는지 알 수 없습니다. 둘을 가른 것은 /context 화면이었습니다. 압축 전후를 비교하자 대화(Messages)는 100.4k 토큰에서 11k로 줄었지만, Memory files 항목은 1.2k로 달라지지 않았습니다. 메모리가 요약 속에 접힌 것이 아니라, 요약과 다른 통로로 컨텍스트에 들어온다는 뜻입니다. 지난 글에서 확인했듯 CLAUDE.md도 압축 뒤 디스크에서 다시 불러옵니다.

공식 문서의 "압축에서 살아남는 것" 표도 이 구조를 보여 줍니다. 프로젝트의 CLAUDE.md와 auto memory는 "디스크에서 다시 불러옴"으로 분류합니다. 반면 특정 경로에만 적용되는 rule은 그 경로의 파일을 다시 읽기 전까지 컨텍스트에서 빠져 있다고 설명합니다. 이 표에는 태스크 목록이 따로 나오지 않습니다. 문서의 표가 미처 담지 않은 동작을 이번 실험에서 하나 더 확인한 셈입니다.

태스크와 메모리에 관한 결과 역시 같은 세션에서 한 차례 관측한 내용입니다. 자동 압축이나 다른 모델에서도 언제나 같은 결과가 나온다고 일반화할 수는 없습니다. 다만 상태를 대화 밖에 두는 구조는 요약이 얼마나 잘 쓰였는지와 무관하게 작동합니다.

큰 탐색은 다른 작업 공간에서 처리한다

세 번째 설계는 부피가 큰 정보를 부모 대화의 컨텍스트에 처음부터 넣지 않는 방법입니다. Claude Code는 큰 탐색을 서브에이전트에게 맡길 수 있습니다. 서브에이전트는 부모와 분리된 자기 컨텍스트에서 일하고, 결과를 요약해 돌려주는 또 하나의 Claude입니다.

탐색용 서브에이전트(Explore)에게 큰 파일 두 개를 정독하게 하자, 서브에이전트는 자기 컨텍스트에서 약 96,300토큰을 썼습니다. 부모 대화에 돌아온 것은 2,429자짜리 보고문이었습니다. 부모 컨텍스트의 증가분으로 따지면 약 1,440토큰이 전부였습니다. 조수에게 여러 책을 통째로 뒤지게 하고, 내 책상에서는 보고서 한 장만 받아 든 셈입니다.

이 수치는 해당 과제를 한 번 실행해 얻은 결과입니다. 어떤 일을 맡기느냐에 따라 서브에이전트가 쓰는 토큰과 보고 분량은 달라집니다.

서브에이전트가 일한 전체 기록도 없어지지 않습니다. 세션 폴더 아래 subagents/agent-<id>.jsonl이라는 별도 파일로 남습니다. 공식 문서는 이 기록이 부모 대화와 분리되어 있어 부모 쪽에서 압축이 일어나도 영향을 받지 않는다고 설명합니다. 서브에이전트도 자기 컨텍스트가 차면 같은 방식으로 압축합니다. 문서는 이처럼 컨텍스트를 분리하는 것이 서브에이전트가 오래 이어지는 세션에 도움이 되는 이유라고 설명합니다.

요약은 AI가 고르고, 상태는 구조가 지킨다

세 가지 설계가 모든 정보를 지켜 주는 것은 아닙니다. 무엇이 남는지를 보면 두 층이 뚜렷하게 갈립니다.

CLAUDE.md와 메모리 파일은 디스크에서 다시 불러옵니다. 태스크 상태는 대화와 별도로 저장되고, 서브에이전트의 작업 기록은 별도 파일에 남습니다. 이런 정보는 하네스의 구조가 지킵니다. 요약문에 우연히 잘 담기기를 바라지 않아도 됩니다.

반면 대화에만 있던 정보는 요약을 만드는 AI의 선택에 맡겨집니다. 지난 글의 Haiku 4.5 실험에서는 자동 압축이 일어난 뒤, 대화에만 있던 약속 단어와 결정 내용이 요약에서 빠져 사라졌습니다. 대화 속 사실이 살아남는지는 여전히 보장이 아니라 선택입니다.

다만 이 관측은 Fable 5로 수동 압축을 한 차례 실행한 실험에서 나왔습니다. 자동 압축이나 다른 모델에서도 같은 결과가 나온다고 일반화할 수는 없습니다. 그렇더라도 차이는 분명합니다. AI가 무엇을 요약할지는 달라질 수 있지만, 태스크와 메모리를 대화 밖에 보존하는 구조는 요약 결과에 좌우되지 않습니다.

하네스 설계는 AI의 판단에 기대도 되는 곳과 기대면 안 되는 곳을 나누는 일입니다. 인계서를 쓰는 일은 AI에게 맡기되, 잃으면 안 되는 상태는 그 판단 바깥에 둡니다. 공식 문서는 컨텍스트가 차는 것만으로도 성능이 낮아질 수 있다고 설명합니다. 컨텍스트 윈도우가 채워질수록 AI가 앞선 지시를 놓치기 시작할 수 있기 때문입니다. 압축하고, 밖에 기록하고, 나눠 맡기는 세 설계가 모두 컨텍스트를 아끼는 방향을 향하는 이유입니다.

원본은 디스크에, 대화는 작업 공간으로

세 가지 설계는 서로 다른 기능처럼 보이지만 같은 원리를 따릅니다. 원본은 디스크에 두고, 대화는 지금 필요한 정보를 펼쳐 놓는 작업 공간으로 씁니다.

압축은 작업 공간을 비우면서 다음 작업을 위한 인계서와 원본의 위치를 남깁니다. 태스크와 메모리는 처음부터 대화 밖에 기록해 두었다가 필요할 때 다시 불러옵니다. 서브에이전트는 부피가 큰 탐색을 별도의 작업 공간에서 처리하고 부모에게는 요약만 건넵니다.

지난 글에서는 중요한 내용을 대화에만 두지 말고 파일에 남기라고 권했습니다. 이것은 사용자가 Claude Code를 다루는 요령인 동시에, 앤트로픽이 제품 안에 구현한 설계 원리이기도 합니다. 잃으면 안 되는 계획과 결정은 파일·태스크·메모리에 남기고, 큰 탐색은 서브에이전트에게 맡기면 됩니다. 그러면 장기 작업에서 중요한 정보가 요약자의 선택이 아니라 구조의 보장 위에 놓입니다.

장기 작업을 버티는 힘은 모든 정보를 컨텍스트 안에 붙잡아 두는 데 있지 않습니다. 필요한 정보를 다시 불러올 수 있는 구조에 있습니다.