컨텍스트 컴팩션과 리셋: 긴 에이전트 작업의 대화 이력 관리법

긴 작업 중간에 코딩 에이전트가 Conversation compacted라는 한 줄을 띄웁니다. 작업은 끊기지 않고 이어집니다. 그런데 몇 턴 뒤 에이전트가 앞에서 안 된다고 결론 내린 방법을 다시 꺼내 듭니다. 고친 적 있는 파일 경로를 한 글자 틀리게 부르기도 합니다.

요약은 제대로 돌았습니다. 대화가 한도를 넘지도 않았습니다. 그런데도 무언가가 사라졌습니다. 이 틈을 설명하는 것이 대화 이력 관리입니다.

요약을 용량 문제로만 볼 때 놓치는 것

흔히 대화 이력 관리를 「한도에 닿기 전에 요약해서 줄이는 일」로 이해합니다. 이렇게 보면 할 일은 두 가지뿐입니다. 언제 요약할지 정하고, 요약을 잘 하게 만드는 것입니다.

이 이해로는 앞의 장면이 설명되지 않습니다. 요약이 무언가를 빠뜨린 것이 아니라, 요약이라는 방식 자체가 특정한 종류의 정보를 잘 남기지 못하기 때문입니다. 저는 요약이 「무엇을 했는가」는 잘 남기고 「무엇을 하지 않기로 했는가」는 잘 남기지 못한다고 봅니다. 시도했다가 버린 방법, 그 방법을 버린 이유, 정확한 식별자 같은 것들입니다. 결론만 남은 요약을 읽은 쪽은 그 결론에 이르기까지 지운 선택지를 모릅니다. 그래서 같은 길을 다시 걷습니다.

그래서 대화 이력 관리는 용량 문제가 아니라 설계 문제입니다. 핵심 질문은 「얼마나 줄일까」가 아니라 「무엇이 살아남아야 하는가」입니다.

한도에 닿기 전부터 시작되는 비용

한도가 넉넉하면 관리할 필요가 없을 것 같습니다. 하지만 길이는 한도에 닿기 훨씬 전부터 대가를 치르게 합니다.

Lost in the Middle(Liu 외, 2023)은 같은 정보라도 놓인 위치에 따라 모델이 다르게 쓴다는 것을 보였습니다.

Performance is often highest when relevant information occurs at the beginning or end of the input context, and significantly degrades when models must access relevant information in the middle of long contexts.

쌓인 대화는 정확히 이 가운데를 채웁니다. 처음에 준 지시는 앞에 있고 방금 한 말은 뒤에 있습니다. 그 사이에 한 시간 분량의 도구 출력이 놓입니다. Anthropic도 컨텍스트 엔지니어링 글에서 컨텍스트를 수확 체감이 있는 유한한 자원으로 다루라고 말합니다. 한도는 마지막 벽일 뿐이고, 비용은 그 앞에서 이미 오르고 있습니다.

줄이는 방법마다 버리는 것이 다르다는 사실

대화를 짧게 만드는 방법은 여럿이고, 각각 버리는 것이 다릅니다. 이 차이가 선택의 기준입니다.

방법	남는 것	사라지는 것	실제 구현 예
오래된 도구 결과 지우기	대화의 흐름과 판단	다시 불러올 수 있는 원본 출력	Claude API 컨텍스트 편집의 clear_tool_uses_20250919
요약(컴팩션)	요약을 만든 쪽이 중요하다고 본 것	버린 선택지, 정확한 문자열, 판단의 이유	Claude Code /compact
비우고 새로 시작(리셋)	대화 밖에 적어 둔 것만	대화 안의 전부	Claude Code /clear

첫 번째는 손실이 가장 적습니다. 도구 결과는 대개 다시 실행하면 다시 얻을 수 있기 때문입니다. 파일 내용이나 검색 결과가 그렇습니다. 대화의 판단은 그대로 둔 채 부피만 덜어 냅니다.

두 번째는 손실의 모양을 고를 수 있다는 것이 장점입니다. Claude Code 문서에 따르면 /compact는 대화를 구조화된 요약으로 바꾸고, /compact focus on API changes처럼 무엇에 집중할지 지시를 받습니다. 저는 이 인자를 훨씬 더 적극적으로 써야 한다고 봅니다. 버린 선택지를 남기라고 적어 주기만 해도 앞의 장면은 상당 부분 막힙니다.

세 번째가 가장 과감해 보이지만, 저는 조건만 맞으면 가장 정직한 방법이라고 봅니다. 그 조건이 다음 이야기입니다.

리셋이 안전해지는 조건, 대화 밖의 기록

리셋은 대화 안에 있던 것을 전부 버립니다. 그러니 리셋이 안전한지는 리셋 자체가 아니라 대화 밖에 무엇이 적혀 있는지가 정합니다.

Anthropic의 긴 작업 에이전트 하네스 글이 이 구조를 그대로 씁니다. 세션마다 컨텍스트를 새로 시작하고, 이어받을 것은 claude-progress.txt 같은 진행 파일과 git 이력에 둡니다. 글은 이 문제를 교대 근무에 빗댑니다. 이전 작업의 기억이 없으면 새 세션은 매번 이해를 처음부터 다시 쌓아야 하고("each new session must rebuild understanding"), 그 모습이 기억 없이 출근하는 교대 근무자와 같다는 것입니다.

교대 근무가 돌아가는 것은 사람의 기억 덕분이 아니라 인수인계 장부 덕분입니다. Claude Code의 CLAUDE.md가 같은 역할의 일부를 맡습니다. 메모리 문서는 프로젝트 루트의 CLAUDE.md가 컴팩션 뒤에도 디스크에서 다시 읽혀 들어간다고 적고 있습니다. 대화 밖에 둔 것이라 요약의 손실을 받지 않습니다.

리셋에도 강도가 있습니다. /clear는 대화를 비우지만 이전 세션을 지우지는 않아서, /resume이나 claude --resume으로 돌아갈 수 있습니다. 여러 에이전트를 묶어 돌리는 OpenRig는 이것을 더 분명하게 나눕니다. 새로 시작한 대화는 정해 둔 시작 컨텍스트를 다시 받고, 옛 기록은 보관하되 이어 붙이지는 않습니다. 저는 이것을 보관형 리셋이라고 부르는 것이 정확하다고 봅니다. 작업 맥락은 비우고, 책임을 따질 기록은 남깁니다.

설계 질문의 순서가 바뀌는 이유

이 개념을 받아들이면 질문의 순서가 바뀝니다. 「언제 요약할까」보다 먼저 「끝까지 살아남아야 하는 것이 무엇인가」를 정하게 됩니다.

저라면 세 종류를 대화 밖으로 뺍니다. 내린 결정과 그 이유, 시도했다가 버린 방법, 그리고 정확해야 하는 식별자입니다. 파일 경로, 브랜치 이름, 테이블 이름 같은 것들입니다. 이것들이 파일이나 커밋 메시지에 있으면 요약이 무엇을 빠뜨리든 상관없어집니다. 리셋도 두렵지 않게 됩니다.

반대로 대화 안에만 있어도 되는 것은 다시 얻을 수 있는 것들입니다. 도구 출력, 탐색 중에 열어 본 파일, 중간 계산이 그렇습니다. 이것들은 가장 먼저 지워도 됩니다.

이웃 개념과의 경계도 여기서 보입니다. 「컨텍스트 예산」은 무엇을 넣을지의 문제이고, 대화 이력 관리는 이미 쌓인 것 가운데 무엇을 버릴지의 문제입니다. 앞은 입구에서, 뒤는 출구에서 같은 자원을 다룹니다.

아직 정해지지 않은 부분

Claude Code가 자동 컴팩션을 언제 시작하는지는 공식 문서에 숫자로 나와 있지 않습니다. 한도에 가까워지면 관리한다는 정도만 적혀 있습니다. 다른 도구의 기준도 같다고 가정할 근거는 없습니다.

요약의 질도 구현마다 다릅니다. Anthropic은 컴팩션을 「높은 충실도로 증류하는 것」이라고 설명하지만, 무엇을 충실하게 남길지는 결국 요약을 만드는 쪽의 판단입니다. 그 판단이 내 작업에서 무엇을 중요하게 볼지는 저도 미리 알 수 없습니다. 그래서 저는 요약을 믿기보다 요약이 빠뜨려도 되는 구조를 만드는 쪽이 낫다고 봅니다.

이 개념이 어디쯤 놓이는지는 AI 제품 개발 핵심 개념 지도에 정리해 두었습니다.