원문 정보
- 제목: Managing context on the Claude Developer Platform
- 링크: claude.com/blog/context-management
- 발행: 2025년 9월 29일 (Claude Sonnet 4.5 출시 동시)
- 카테고리: Product announcements
글의 요지
Claude Developer Platform에 두 가지 컨텍스트 관리 기능이 동시 추가됐다 — Context Editing 과 Memory Tool. Sonnet 4.5의 출시와 함께 공개된, 장시간 실행 에이전트를 위한 인프라.
1) Context Editing — 자동 정리
장시간 에이전트의 가장 큰 적은 컨텍스트 윈도우 고갈. 도구 호출이 늘어날수록 오래된 결과가 컨텍스트에 쌓이고, 결국 토큰 한도에 부딪힌다. 이전 해결책 — "트랜스크립트 잘라내기 vs 성능 저하" 사이의 선택.
Context Editing이 하는 것:
- 임계값(threshold) 설정 → 입력 토큰이 일정 수준 넘으면 자동 발동
- 오래된 도구 결과를 제거 (chronological order)
- 제거된 위치엔 placeholder 텍스트 — Claude가 인식
- 가장 최근 N개의 도구 결과는 유지 (
keep파라미터)
활성화: clear_tool_uses_20250919 strategy + 베타 헤더 context-management-2025-06-27
2) Memory Tool — 컨텍스트 외부 영구 저장
파일 기반 영구 메모리 시스템. Claude가 /memory 디렉토리에 CRUD 작업 (Create, Read, Update, Delete).
특징:
- 클라이언트 사이드 동작: 개발자가 저장소 직접 관리 (file system, DB 등)
- 세션 간 영속: 하나의 대화가 끝나도 메모리 유지
- 지식 베이스 누적: 시간에 따라 지식 축적
- 전체 통제: 데이터 어디에 어떻게 저장할지 개발자 결정
두 기능의 결합
본문이 강조하는 시너지:
- Context Editing: 오래된 도구 결과 정리 → 토큰 절감
- Memory Tool: 중요한 인사이트 저장 → 정리 후에도 보존
함께 사용 시 자동 트리거:
- 컨텍스트가 임계값 접근 시 Claude에게 자동 경고
- Claude가 중요한 정보를 메모리 파일에 저장
- 그 다음에 컨텍스트 정리 발동
- 필요할 때 메모리 파일에서 조회
평가 결과 (Anthropic 자체 측정)
100-turn 웹 검색 평가 (agentic search):
- Context Editing 단독: 베이스라인 대비 29% 향상
- Context Editing + Memory Tool: 베이스라인 대비 39% 향상
- 토큰 사용량: 84% 감소 (컨텍스트 고갈로 실패하던 작업이 성공)
사용 사례
Coding: Context editing이 오래된 파일 읽기·테스트 결과 정리, Memory가 디버깅 인사이트·아키텍처 결정 보존
Research: Memory가 핵심 발견 저장, Context editing이 오래된 검색 결과 제거 → 시간이 갈수록 강해지는 지식 베이스
Customer Service: Memory가 고객 선호도·과거 이슈 보존, Context editing이 오래된 대화 정리
출시 범위
- Claude Developer Platform 네이티브
- Amazon Bedrock
- Google Cloud Vertex AI
- 모두 public beta
2026년에 다시 읽으며 — 내가 본 것
1. "컨텍스트 부족"이라는 진짜 한계 인정
이 글이 솔직히 인정하는 것: 컨텍스트 윈도우는 정해진 한계가 있고, 무한히 늘려도 답이 안 된다.
2025년 8월 Sonnet 4의 1M 토큰 컨텍스트 출시 후 1개월 — Anthropic이 같은 회사로서 "1M도 부족해" 라고 인정한 셈이다. 이 인정의 배경에는 Context Rot 현상이 있다.
Anthropic 자체 엔지니어링 블로그가 정리한 개념:
"As the number of tokens in the context window increases, the model's ability to accurately recall information from that context decreases. Even before the hard context limit is reached, the agent may be getting less out of each token."
번역: "컨텍스트 토큰 수가 증가할수록 모델의 정확한 기억 능력은 감소한다. 하드 한계에 도달하기 전에도 토큰당 효용이 떨어진다."
이 사실이 의미하는 것: 컨텍스트 윈도우 키우기는 답이 아니다. 컨텍스트를 큐레이션하기가 답이다. Context Editing + Memory가 정확히 이 큐레이션 인프라다.
2. "감소 vs 누적"의 두 가지 방향
이 두 도구의 철학이 흥미롭다.
Context Editing: 빼는 도구 (subtractive)
- 오래된 정보 → 제거
- 컨텍스트 = 임시 작업 공간
- 단기 메모리
Memory Tool: 쌓는 도구 (additive)
- 중요한 정보 → 영구 저장
- 메모리 = 지속 지식 베이스
- 장기 메모리
이 이분법이 인간의 메모리 구조와 닮았다.
- 단기 기억: 작업 중 임시 정보 (Context Window)
- 장기 기억: 중요한 것만 선별 저장 (Memory File)
- 선별 메커니즘: 중요도 판단 → 장기 저장 (Memory Tool)
- 잊기 메커니즘: 사용 안 하면 사라짐 (Context Editing)
이 구조가 LLM이 시간이 지나도 점점 똑똑해질 수 있는 토대가 된다. 매 세션마다 처음부터 시작하는 게 아니라, 누적된 메모리 위에서 더 잘 일한다.
3. "84% 토큰 절감"의 비용 함의
100턴 웹 검색에서 토큰 사용량 84% 감소가 단순한 성능 메트릭이 아니다. 비용 메트릭이기도 하다.
기존:
- 100턴 웹 검색 = 약 500K~1M 토큰 누적
- Sonnet 4.5 입력 가격 $3/M
- 비용: $1.5~$3 per 100-turn task
Context Editing 적용:
- 같은 100턴 = 80~160K 토큰
- 비용: $0.24~$0.48 per task
- 5~10배 비용 절감
이 절감이 에이전트 경제성의 결정적 변수다. 24시간 자율 에이전트가 경제성을 가지려면 토큰 비용이 통제되어야 한다. Context Editing이 그 통제를 가능하게 한다.
4. "클라이언트 사이드 메모리"라는 결정
Memory Tool 설계의 가장 중요한 결정 — Anthropic 서버에 저장 안 함, 클라이언트가 저장.
대안 비교:
- OpenAI Memory (ChatGPT): 서버 저장, 사용자 통제 약함
- Mem0, Letta: 별도 서비스, 외부 의존
- Anthropic Memory Tool: 클라이언트 저장, 개발자 통제
이 선택의 이유:
1) 데이터 주권: 기업 고객이 자기 데이터를 자기 인프라에 저장
2) 컴플라이언스: GDPR, HIPAA 같은 데이터 거주 규제 대응
3) 유연성: 파일, DB, S3, 어디든 가능
4) 단순성: Anthropic이 메모리 호스팅 인프라 운영 안 해도 됨
이 결정이 엔터프라이즈 수용성에 결정적이었다. 의료, 금융, 정부 같은 규제 산업이 "데이터가 우리 환경에서만 머문다" 는 보장 없이는 도입 안 한다.
5. CLAUDE.md와의 연결고리
Memory Tool과 Anthropic 자체의 CLAUDE.md 패턴 사이의 관계가 흥미롭다.
- CLAUDE.md (2025년 7월~): Claude Code의 도메인 지식 파일
- Memory Tool (2025년 9월): 에이전트의 동적 지식 저장
- Skills (2025년 10월): 패키징된 도메인 능력
세 가지가 합쳐져서 Claude의 외부 지식 시스템을 형성한다.
Skills → 사전 정의된 능력 (정적)
CLAUDE.md → 프로젝트 컨텍스트 (정적)
Memory Tool → 대화 중 학습 (동적)
Context Editing → 단기 작업 공간 정리 (동적)이 4계층 구조가 2026년 현재 Claude 에이전트의 표준 컨텍스트 아키텍처다.
6. "Claude 플레이 포켓몬"의 흥미로운 사례
Anthropic 엔지니어링 블로그가 인용한 사례:
"The agent maintains precise tallies across thousands of game steps—tracking objectives like 'for the last 1,234 steps I've been training my Pokémon in Route 1, Pikachu has gained 8 levels toward the target of 10.'"
번역: "에이전트가 수천 단계의 게임 진행을 정확히 기록한다 — 'route 1에서 1,234 단계 동안 피카츄를 훈련 중, 목표 레벨 10 중 8 달성' 같이."
이게 보여주는 것: Memory Tool은 코딩 도구가 아니라 일반 에이전트 인프라. 게임, 시뮬레이션, 장기 프로젝트 어디든 적용 가능.
이 일반성이 2026년 다양한 응용을 낳았다:
- 장기 코칭 봇: 사용자의 진행 추적
- 연구 어시스턴트: 문헌 리뷰 누적
- 개인 비서: 사용자 선호 학습
- 게임 NPC: 플레이어와의 관계 기록
7. "Sonnet 4.5의 컨텍스트 인식" 통합
본문의 한 줄 — "Claude Sonnet 4.5 enhances both capabilities with built-in context awareness—tracking available tokens throughout conversations to manage context more effectively."
이게 결정적이다. Sonnet 4.5는 자기 컨텍스트 상태를 인식한다.
- 현재 사용 토큰 수 추적
- 한도까지 남은 여유 측정
- 임계값 접근 시 자체 알림
- Memory Tool에 미리 중요 정보 저장
즉 모델 자체가 컨텍스트 매니저 역할을 한다. 외부 시스템 없이도 자기 한계를 관리.
이 능력은 Claude 4 시리즈가 에이전트 친화적 모델로 설계된 증거다. 2026년 현재 Opus 4.6/4.7은 이 컨텍스트 인식이 더 정교해져, 30+ 시간 자율 작업을 가능하게 한다.
마무리
Context Editing + Memory Tool의 출시는 에이전트 시대의 인프라 완성을 알리는 신호다.
- 컨텍스트 윈도우 한계 인정: 1M도 부족하다
- 단기/장기 메모리 분리: 인간 인지 구조의 모방
- 84% 토큰 절감: 에이전트 경제성 확립
- 클라이언트 사이드 저장: 엔터프라이즈 수용성
- 모델 자체 컨텍스트 인식: 모델-인프라 통합 진화
2025년 9월 29일은 Sonnet 4.5 출시일이지만, 모델 그 자체보다 이 컨텍스트 관리 인프라가 더 큰 발전일 수 있다. 모델 성능 개선은 점진적이지만, 컨텍스트 관리 패러다임 변화는 에이전트의 가능성 자체를 바꿨다.
이 글 이후 6개월 — 2026년 4월 시점에서 보면 Memory Tool이 사실상 모든 진지한 에이전트의 기본 도구가 됐다. CLAUDE.md, Skills, Context Editing, Memory가 함께 짜내는 4계층 외부 지식 시스템 위에서 Claude는 진짜로 "기억하는 동료" 가 된다.
