AI 에이전트가 긴 작업을 끝까지 해내는 법 — 컨텍스트 압축 전략 완전 정리

AI 에이전트로 긴 작업을 시키다 보면 이런 일이 생겨요.

"분명히 앞에서 결정한 내용인데 에이전트가 또 같은 실수를 하네?"

컨텍스트 창이 꽉 찼거나, 중요한 정보가 밀려나버린 거예요. 이 문제를 어떻게 해결하느냐가 프로덕션 수준의 에이전트를 만드는 핵심입니다. 이번 글에서는 컨텍스트 압축의 세 가지 전략과 실제로 어떻게 조합해서 쓰는지 정리해 드릴게요.

---

왜 컨텍스트 관리가 중요한가

모델의 컨텍스트 창은 유한해요. 긴 작업을 하다 보면 툴 출력, 중간 대화, 오류 메시지들이 쌓여서 창을 잠식합니다. 새로운 정보가 들어올 자리가 없어지고, 중요한 정보가 창 밖으로 밀려나기 시작하면 에이전트가 앞서 한 결정을 기억하지 못하거나 같은 실수를 반복해요.

이걸 **컨텍스트 표류(Context Drift)**라고 해요. 실제로 2025년 기업 AI 실패 사례의 65%가 컨텍스트 표류나 메모리 손실 때문에 발생했다는 연구 결과가 있어요. 컨텍스트 창 자체가 꽉 차서 생긴 문제가 아니라, 창이 꽉 차기 전에 이미 중요한 정보가 노이즈에 묻혀버린 거예요.

컨텍스트가 커질 때 나타나는 실패 패턴은 두 가지예요.

컨텍스트 오염(Context Poisoning) — 잘못된 정보나 할루시네이션이 컨텍스트에 들어오면 에이전트가 그걸 계속 참고하면서 오류가 누적됩니다. 컨텍스트 산만(Context Distraction) — 과거 정보가 너무 많아지면 에이전트가 새로 추론하는 대신 과거 패턴에 의존하게 돼요.

그리고 컨텍스트 창이 크면 해결된다고 생각하기 쉬운데, 연구에 따르면 대부분의 모델이 32K 토큰을 넘어가면 성능이 급격히 떨어지는 "중간 부분 망각(Lost-in-the-Middle)" 현상이 나타나요. 창 크기를 늘리는 것만으로는 해결이 안 돼요.

---

전략 1: 요약 (Summarization)

오래된 대화나 툴 출력을 모델이 직접 요약해서 원본을 대체하는 방식이에요.

[원본 툴 출력 - 2,000 토큰]
파일 목록: src/index.ts, src/api/users.ts, src/api/posts.ts...
(300개 파일 전체 경로)

↓ 요약 후

[요약 - 80 토큰]
총 300개 파일. 주요 구조: src/api (라우터), src/models (DB 스키마),
src/services (비즈니스 로직). 진입점은 src/index.ts.

장점 — 토큰을 극적으로 줄일 수 있어요. 맥락의 흐름은 유지되면서 세부 내용만 압축돼요. 이론적으로는 반복 요약을 통해 무한한 턴 수도 처리할 수 있어요.

단점 — 요약 과정에서 손실이 생겨요. 모델이 "중요하지 않다"고 판단한 내용이 나중에 필요해질 수 있어요. 특히 코드 작업에서 특정 에러 메시지나 파일 경로 같은 세부 정보가 사라지면 이후 디버깅이 어려워져요.

Anthropic이 직접 밝힌 Claude Code의 요약 로직이에요.

"메시지 히스토리를 모델에 넘겨서 중요한 세부사항을 요약·압축하게 해요. 아키텍처 결정, 미해결 버그, 구현 세부사항은 보존하고, 중복 툴 출력이나 메시지는 버립니다. 에이전트는 이 압축된 컨텍스트와 가장 최근에 접근한 5개 파일을 가지고 계속 작업해요."

Claude Code의 적용 — /compact 명령이 이 방식이에요. /compact focus on API changes처럼 보존할 포커스를 지정하면 그 부분은 세부 내용을 유지하고 나머지를 더 적극적으로 압축해요.

핵심 팁 — 요약 프롬프트를 잘 튜닝해야 해요. Anthropic의 권장 방식은 먼저 리콜(recall)을 극대화해서 모든 관련 정보를 캡처하게 하고, 그 다음 정밀도(precision)를 높여서 불필요한 내용을 제거하는 순서로 반복 개선하는 거예요.

---

전략 2: 선택적 삭제 (Selective Eviction)

전부 요약하는 게 아니라 "이건 더 이상 필요 없다"고 판단되는 항목을 통째로 버리는 방식이에요.

삭제 우선순위 기준이 몇 가지 있어요.

시간 기반(LRU) — 가장 오래된 것부터 제거해요. 단순하지만 "오래됐어도 중요한 정보"를 구분하지 못해요.

타입 기반 — 툴 출력은 버리고 사용자-모델 대화는 남겨요. 툴 출력은 대부분 중간 과정이라 결과만 남기면 되지만, 대화는 목표와 제약사항이 담겨 있어서 더 중요한 경우가 많아요.

중복 제거 — 같은 파일을 여러 번 읽었으면 가장 최신 읽기 결과만 남기고 이전 것들은 버려요.

장점 — 요약처럼 손실 변환을 거치지 않아요. 남은 정보는 원본 그대로예요.

단점 — 버린 것은 완전히 없어져요. 요약은 최소한 "이런 내용이 있었다"는 흔적이 남지만, 삭제는 흔적도 없어요.

실제 연구 결과도 흥미로워요. JetBrains 연구팀이 코딩 에이전트를 대상으로 요약과 선택적 삭제(Observation Masking)를 비교했는데, 단순히 최근 N개의 관찰만 유지하는 마스킹 방식이 LLM 요약과 비슷하거나 더 나은 성능을 보이는 경우도 있었어요. 복잡한 요약보다 단순한 삭제가 오히려 낫다는 거예요.

실무 팁 — Letta의 권장 사항은 한 번에 전체를 버리지 말고 70% 정도만 제거해서 연속성을 유지하는 거예요.

Claude Code의 적용 — 컨텍스트 한계에 가까워지면 오래된 툴 출력을 자동으로 지워요. 대화 내용은 보존하고 툴 I/O를 먼저 제거하는 타입 기반 삭제를 기본으로 써요.

---

전략 3: 청킹 (Chunking)

긴 작업을 처음부터 여러 세션으로 나눠서 각 세션이 컨텍스트를 독립적으로 관리하게 하는 방식이에요. 압축이라기보다는 설계 단계에서 컨텍스트 폭발을 막는 예방 전략에 가까워요.

태스크 청킹 — 큰 작업을 작은 단위로 분해해서 각 서브에이전트가 자기 청크만 처리해요. Anthropic이 멀티에이전트 리서치 시스템을 구축하면서 발견한 내용이에요.

"각 서브에이전트는 수만 토큰을 쓰면서 깊이 탐색하지만, 리드 에이전트에는 1,000~2,000 토큰의 압축된 요약만 반환해요. 상세 검색 컨텍스트는 서브에이전트 안에 격리되고, 리드 에이전트는 결과 합성에만 집중합니다."

세션 청킹 — 체크포인트를 만들어서 세션을 끊고 다시 시작해요. Claude Code의 CLAUDE.md와 MEMORY.md가 이 역할이에요. 세션이 끝날 때 핵심 정보를 파일로 저장해두고, 다음 세션이 그 파일을 로드하면서 시작해요. 대화 기록 의존을 끊고 파일로 영속성을 관리하는 거예요.

장점 — 각 청크가 독립적이라 병렬 실행도 가능하고, 한 청크가 컨텍스트를 오염시켜도 다른 청크에 영향이 없어요.

단점 — 청크 간 의존성이 있는 작업은 조율 비용이 생겨요. 서브에이전트 A가 만든 파일을 B가 써야 한다면 전달 메커니즘이 필요해요.

---

세 전략의 비교

구분 요약 선택적 삭제 청킹

정보 손실	중간 (변환 손실)	높음 (완전 소멸)	낮음 (청크 내 완전)
토큰 절감	높음	높음	구조적으로 회피
구현 복잡도	중간	낮음	높음
적합한 상황	긴 대화, 중간 결과	툴 출력, 중복 데이터	대형 작업, 병렬 실행

---

Claude Code가 실제로 쓰는 방식 — 계층적 조합

세 전략을 독립적으로 쓰는 게 아니라 계층적으로 조합해요.

평상시
  └─ 선택적 삭제로 툴 출력 자동 정리

컨텍스트가 임계치에 가까워지면
  └─ 요약으로 대화 압축 (/compact)

처음부터 큰 작업이면
  └─ 청킹으로 서브에이전트 스폰 → 각자 독립 컨텍스트

세션 경계를 넘어서
  └─ CLAUDE.md + MEMORY.md로 영속 레이어 유지

---

가장 중요한 원칙 — 넣을 때 잘 설계하기

세 전략을 배웠는데, 사실 이것보다 더 중요한 게 있어요.

"무엇을 버릴 것인가보다 처음부터 컨텍스트에 무엇을 넣을 것인가를 잘 설계하는 게 더 중요하다."

나중에 압축하는 것보다 처음부터 컨텍스트에 노이즈를 덜 넣는 게 훨씬 효율적이에요. 앞 글에서 다룬 온디맨드 스킬 로딩이 툴 설계 원칙과 맞닿아 있는 이유가 여기 있어요. 필요할 때만 로드하면 애초에 압축할 게 줄어드니까요.

---

마무리

컨텍스트 관리는 단순히 "창이 꽉 차면 뭔가 버린다"는 수준을 넘어선 설계 문제예요.

요약으로 흐름을 유지하고, 선택적 삭제로 노이즈를 제거하고, 청킹으로 작업을 구조적으로 분리하는 세 전략을 상황에 맞게 조합하는 것이 프로덕션 수준의 AI 에이전트를 만드는 핵심입니다. 😄