장기 실행 에이전트의 기억은 왜 대화 기록이 아닐까

• 카테고리: ai_dev
• 예상 읽기 시간: 10분
• 오늘의 질문: 에이전트가 오래 일하게 만들 때 무엇을 컨텍스트에 남기고, 무엇을 메모리나 체크포인트로 빼야 할까?
• 핵심 출처:
  • Managing context on the Claude Developer Platform - 2025-09-29, 2026-06-24 확인
  • Memory tool - Claude API Docs - 게시일 미표기, 2026-06-24 확인
  • Context editing - Claude API Docs - 게시일 미표기, 2026-06-24 확인
  • From model to agent: Equipping the Responses API with a computer environment - 2026-03-11, 2026-06-24 확인
  • Enabling Claude Code to work more autonomously - 2025-09-29, 2026-06-24 확인

1. 왜 지금 봐야 하나

에이전트 앱을 만들 때 가장 흔한 첫 설계는 “대화 기록을 계속 붙이면 되겠지”다. 처음 몇 턴은 잘 된다. 모델은 방금 사용자가 한 말, 방금 읽은 파일, 방금 실행한 명령 결과를 보고 다음 행동을 고른다. 문제는 작업이 길어질 때 시작된다. 검색 결과, 파일 내용, 테스트 로그, 도구 호출 파라미터, 중간 추론 메모가 계속 쌓이면 컨텍스트 창은 금방 꽉 찬다. 더 나쁜 점은 꽉 차기 전에도 품질이 흔들린다는 것이다. 오래된 로그와 지금 필요한 사실이 같은 공간에 섞이면 모델의 주의가 분산된다.

최근 Anthropic과 OpenAI의 공식 자료는 같은 방향을 가리킨다. Anthropic은 Claude Developer Platform에 context editing과 memory tool을 도입하며 “context windows have limits, but real work doesn’t”라고 설명한다. Claude API 문서는 memory tool을 “모든 정보를 미리 컨텍스트에 넣는 대신, 필요한 것을 나중에 꺼내 쓰는 just-in-time context retrieval primitive”로 다룬다. Context editing 문서는 오래된 tool result나 thinking block을 선택적으로 지우는 기능을 설명하면서 “context is a finite resource with diminishing returns”라고 말한다. OpenAI도 Responses API의 컴퓨터 환경 글에서 장기 실행 작업은 컨텍스트를 채우기 때문에 compaction이 필요하다고 설명한다.

오늘의 핵심은 이것이다.

장기 실행 에이전트의 기억은 긴 대화 기록이 아니라, 작업 기억(context), 지속 메모리(memory), 실행 상태(checkpoint/artifact)를 나누는 상태 관리 설계다.

2. 핵심 개념

LLM의 컨텍스트 창은 데이터베이스가 아니다. 더 정확히 말하면 작업 기억에 가깝다. 지금 답을 만들기 위해 모델이 바로 참고해야 하는 정보가 들어가는 공간이다. 여기에 모든 과거를 넣으면 세 가지 문제가 생긴다.

첫째, 비용과 지연이 증가한다. 긴 입력은 매 요청마다 처리해야 하므로 비용과 latency를 키운다. prompt caching이 일부를 줄여도, 캐시가 맞으려면 prefix 구조가 안정적이어야 하고 토큰 한도는 여전히 존재한다.

둘째, 주의 오염이 생긴다. 모델은 오래된 검색 결과와 최신 파일 상태를 모두 보게 된다. 과거 테스트 실패 로그가 이미 해결된 버그를 계속 중요한 문제처럼 보이게 만들 수 있다.

셋째, 상태 복구가 어렵다. 대화 기록만 있으면 “무엇이 현재 사실인지”, “무엇은 임시 관찰이었는지”, “어디로 되돌릴 수 있는지”가 불분명하다.

그래서 장기 실행 에이전트에는 최소 세 층이 필요하다.

1. Active context: 이번 턴 의사결정에 필요한 지시, 최근 사용자 목표, 최근 도구 결과, 현재 파일 diff 같은 작업 기억
2. Persistent memory: 다음 세션에도 쓸 수 있는 프로젝트 규칙, 사용자 선호, 이미 검증한 API 제약, 반복되는 실패 교훈
3. Execution state: 실제 파일, 생성 산출물, 실행 중인 프로세스, 체크포인트, 롤백 가능한 변경 이력

이 셋을 구분하지 않으면 메모리 기능은 금방 “무한 대화 로그 저장소”가 된다. 반대로 잘 구분하면 컨텍스트는 가볍게 유지하고, 중요한 사실은 오래 보존하며, 위험한 변경은 되돌릴 수 있다.

3. 최신 이슈와 연결

Anthropic의 context management 발표는 이 구분을 제품 기능으로 보여준다. Context editing은 오래된 tool call과 result를 컨텍스트 창에서 자동으로 제거해 장기 실행 agent가 토큰 한도에 덜 막히도록 한다. Memory tool은 Claude가 /memories 디렉터리 안에 파일을 만들고 읽고 수정하며, 세션을 넘어 프로젝트 지식이나 이전 학습을 보존하게 한다. 문서상 memory tool은 client-side 도구다. 즉 Claude가 메모리 작업을 제안하고, 실제 저장 위치·권한·암호화·보존 기간은 애플리케이션이 통제한다.

Claude API의 context editing 문서는 더 구체적이다. clear_tool_uses_20250919 전략은 입력 토큰이 임계값을 넘으면 오래된 tool result를 지우고 placeholder를 남긴다. 필요하면 tool call 입력까지 지울 수 있지만, 기본은 result 중심이다. clear_thinking_20251015는 extended thinking block을 관리한다. 중요한 운영 포인트는 “클라이언트는 전체 원본 대화 기록을 유지하고, 편집은 Claude에 도달하기 전에 server-side로 적용된다”는 점이다. 즉, 모델이 보는 작업 기억과 시스템이 보관하는 원본 로그는 다를 수 있다.

OpenAI의 Responses API 글도 같은 문제를 다른 방식으로 푼다. Shell tool, hosted container, filesystem, SQLite 같은 실행 환경을 제공하면서, 장기 실행 작업이 컨텍스트 창을 채우지 않도록 compaction을 이야기한다. 여기서 핵심은 도구 결과를 전부 대화에 붙이는 대신, 파일과 실행 환경을 상태 저장소로 쓰고 필요한 요약만 모델에 되돌리는 흐름이다.

또 Anthropic의 Claude Code 업데이트는 checkpoints를 강조한다. Claude Code는 변경 전 코드 상태를 자동 저장하고, /rewind로 코드·대화 또는 둘 다 되돌릴 수 있게 한다. 이 기능은 “기억”이라기보다 실행 상태의 안전장치다. 에이전트가 더 오래, 더 넓게 작업할수록 메모리보다 먼저 필요한 것이 되돌릴 수 있는 경계라는 점을 보여준다.

4. 개발자 관점 해석

에이전트 메모리를 설계할 때 가장 위험한 질문은 “무엇을 기억하게 할까?”다. 더 좋은 질문은 “이 정보는 어느 층에 있어야 하나?”다.

예를 들어 코드 에이전트가 테스트를 실행했다. 전체 로그 3,000줄은 active context에 오래 남기면 안 된다. 현재 실패 원인을 판단하는 몇 줄은 active context에 필요하지만, 해결 후에는 제거 대상이다. “이 프로젝트는 테스트 전에 pnpm generate가 필요하다”처럼 반복적으로 유효한 교훈은 persistent memory 후보가 된다. 실제 수정된 파일과 diff는 execution state다. 되돌릴 수 있어야 하므로 체크포인트나 Git commit 경계와 연결해야 한다.

RAG와도 다르다. RAG는 외부 지식을 검색해 현재 질문에 붙이는 방식이다. Memory는 에이전트가 작업 중 배운 것을 다음 작업에서 다시 꺼내 쓰는 방식에 가깝다. 둘 다 retrieval을 쓰지만, 실패 모드는 다르다. RAG의 주요 실패는 검색 누락, 잘못된 chunk, stale 문서다. Memory의 주요 실패는 잘못 배운 사실을 오래 보존하거나, 사적인 정보를 과도하게 저장하거나, 과거 선호를 현재 요구보다 우선하는 것이다.

Context editing도 만능이 아니다. 오래된 tool result를 지우면 비용과 토큰 압박은 줄지만, 나중에 필요한 근거가 사라질 수 있다. 그래서 “지워도 되는 결과”와 “보존해야 하는 근거”를 구분해야 한다. 보존할 근거는 active context에 계속 쌓아두기보다 요약해 memory나 artifact로 옮겨야 한다.

5. 내 프로젝트에 적용할 체크포인트

• 컨텍스트 예산을 숫자로 정했는가? 예: 최근 사용자 목표 1개, 최근 tool result 3개, 현재 diff 요약 1개만 active context에 유지한다.
• 메모리에 쓸 수 있는 정보의 종류를 제한했는가? 프로젝트 규칙, 검증된 운영 절차, 사용자 명시 선호는 가능. 비밀번호, 토큰, 민감한 고객정보, 임시 추측은 금지.
• 메모리 쓰기 전에 검증 단계가 있는가? 모델이 “배웠다”고 해서 바로 영구 저장하지 말고, 출처·시간·확신도·삭제 조건을 같이 남긴다.
• 도구 결과는 원본과 요약을 분리하는가? 원본 로그는 파일이나 object storage에 두고, 모델에는 현재 판단에 필요한 요약과 링크만 준다.
• 체크포인트와 메모리를 혼동하지 않는가? 메모리는 지식 저장소이고, 체크포인트는 실행 상태 복구 장치다. 코드 변경·데이터 변경·외부 API 호출 전에는 별도 롤백 전략이 필요하다.
• 삭제와 만료 정책이 있는가? memory는 쌓일수록 자산이 아니라 부채가 될 수 있다. TTL, 사용자 삭제, 프로젝트 종료 시 정리 정책을 둔다.

6. 오늘 10분 액션

지금 만들고 있는 AI 기능 하나를 골라 아래 표를 채워보자.

정보	Active context	Persistent memory	Execution state	버릴 것
사용자 목표	이번 작업의 목표 한 문장	장기 선호가 명시된 경우만	없음	과거 목표와 충돌하면 과거 목표
검색 결과	현재 판단에 필요한 3~5개 근거	반복적으로 유효한 문서 위치	원본 검색 로그 파일	중복 snippet
테스트 로그	실패 원인 요약	반복 절차/환경 제약	전체 로그 artifact	해결된 오류의 긴 로그
코드 변경	현재 diff 요약	프로젝트 규칙	Git diff/checkpoint	중간 시행착오
사용자 피드백	이번 수정 지시	명시적 선호와 금지사항	이슈/티켓 상태	감정적 표현의 과잉 일반화

그 다음 한 가지 규칙만 코드 주석이나 README에 적어보자.

“우리 에이전트는 전체 도구 로그를 다음 턴 컨텍스트에 보존하지 않는다. 로그는 artifact로 저장하고, 모델에는 현재 결정에 필요한 요약만 제공한다.”

이 한 줄만 있어도 에이전트 설계가 “대화 이어붙이기”에서 “상태 관리”로 이동한다.

7. 더 볼 자료

• Managing context on the Claude Developer Platform
• Memory tool - Claude API Docs
• Context editing - Claude API Docs
• From model to agent: Equipping the Responses API with a computer environment
• Enabling Claude Code to work more autonomously

중복 회피 메모

최근 ai_dev 글은 실시간 Live API 세션의 interrupt·session resumption·context compression, LLM 라우터의 prefix cache-aware scheduling, MCP Elicitation의 사용자 입력 경계, guardrail checkpoint, reasoning effort, prompt caching을 다뤘다. 이번 글은 특정 실시간 세션 API나 캐시 최적화가 아니라, 장기 실행 에이전트에서 active context, persistent memory, execution checkpoint를 분리하는 상태 관리 원리에 집중한다.