[컨텍스트] 4. 기억 : 긴 대화의 컨텍스트 관리

(컨텍스트 엔지니어링 ④) 기억

짧은 질문 하나면 컨텍스트 관리랄 게 없다. 문제는 오래 도는 에이전트다. 수십 번씩 도구를 부르고 대화가 길어지면, 컨텍스트에 낡은 정보가 쌓이면서 응답이 점점 상한다. 이걸 다루는 도구가 세 가지 있는데, 셋의 성격이 다르다.

잘라내기(context editing)는 오래돼 더는 필요 없는 도구 결과나 지난 추론을 컨텍스트에서 그냥 지운다. 요약하지 않고 제거하는 거라, 트랜스크립트를 가볍게 유지하면서 대화 구조는 그대로 둔다. “이제 안 볼 옛날 조회 결과”를 치우는 데 쓴다.

Claude API에서는 이 잘라내기를 설정 한 줄로 켠다.

resp = client.beta.messages.create(
    model="claude-opus-4-8",
    max_tokens=1024,
    betas=["context-management-2025-06-27"],
    context_management={"edits": [{"type": "clear_tool_uses_20250919"}]},
    tools=tools,
    messages=messages,
)

요약(compaction)은 창이 꽉 차 갈 때 앞부분을 압축한 요약본으로 갈아끼운다. 잘라내기가 버리는 거라면, 요약은 줄여서 남기는 거다. 앞의 맥락이 뒤에도 계속 필요할 때 이걸 쓴다. 다만 요약은 손실 압축이라, ‘무엇은 꼭 남겨라'(결정 사항·미해결 이슈 등) 같은 지침을 함께 주는 게 좋다 — Claude Code가 긴 대화에서 하는 컨텍스트 압축이 정확히 이 방식이다.

메모리(memory)는 결이 다르다. 앞의 둘이 한 세션 안에서 컨텍스트를 정리하는 거라면, 메모리는 세션이 끝나도 남는 저장소다. 파일 같은 데 학습한 내용을 적어두고, 다음 세션에서 다시 읽어온다. 프로세스가 재시작돼도 살아남는 기억이다. 컨텍스트는 가볍게 유지하면서 ‘기억’은 사실상 무한히 늘릴 수 있는 셈이다.

고르는 기준은 간단하다. 세션 안에서 컨텍스트가 지저분해지는 게 문제면 잘라내기와 요약을, 세션을 넘어 상태가 이어져야 하면 메모리를 쓴다. 오래 도는 에이전트는 사실 이 셋을 다 섞어 쓴다. 정리할 건 잘라내고, 남길 건 요약하고, 넘길 건 저장하고.

실물로 보면 — 요약 지침과 메모리 파일

추상적이면 실물을 보자. 먼저 요약 지침 — 압축을 시킬 때 이런 뼈대를 주면 디테일이 덜 뭉개진다.

다음 대화를 요약하되 반드시 보존할 것:
- 사용자가 내린 결정과 그 이유
- 미해결 이슈·다음 할 일
- 파일 경로·명령어 등 정확해야 하는 문자열 (원문 그대로)
요약해도 되는 것: 중간 탐색 과정, 이미 해결된 시행착오

다음은 외부 메모리 파일의 전형적 구조. 인덱스 한 장 + 주제별 파일로 나누면, 매 세션 인덱스만 읽고 필요한 것만 파고들 수 있다.

memory/
  INDEX.md          ← 매 세션 로드되는 한 장짜리 목차
  project-goals.md  ← "지금 뭘 만들고 있나"
  decisions.md      ← 내린 결정과 이유 (날짜 포함)
  conventions.md    ← 코드·문서 규칙
# INDEX.md 예:
# - [프로젝트 목표](project-goals.md) — MVP 범위와 마감
# - [결정 기록](decisions.md) — DB는 SQLite로 확정(8/12)

포인트는 인덱스와 본문의 분리다. 전부 컨텍스트에 이고 다니지 않고, ‘무엇이 어디 있는지’만 상시 들고 있다가 필요할 때 꺼낸다 — 사람의 노트 정리와 똑같다.

셋을 언제 쓰나 — 조합이 핵심

도구	하는 일	쓰는 상황
잘라내기	낡은 도구 결과 제거	도구 호출이 많을 때
요약	핵심만 압축	대화가 길어질 때
외부 메모리	밖에 저장·소환	오래 도는 작업

실전에선 셋을 섞어 쓴다. 다 본 옛 조회 결과는 잘라내고, 길어진 히스토리는 요약하고, 꼭 지켜야 할 결정은 외부 메모리에 남긴다. 하나만 쓰는 게 아니라 상황마다 맞는 걸 겹쳐 쓰는 것이다.

무엇을 남기고 무엇을 버릴지가 진짜 실력

도구는 수단이고, 판단이 본체다. 지금 이 작업에 정말 필요한 정보가 무엇인지 가릴 줄 알아야 한다. 앞에서 본 context rot처럼, 많이 넣는 게 결코 좋은 게 아니다. 적게, 그러나 정확하게 — 이게 컨텍스트 관리의 전부다. 시리즈의 출발점이 궁금하면 컨텍스트 엔지니어링 개요로 돌아가 보자.

세 편을 관통한 얘기는 결국 하나다. 컨텍스트는 공짜가 아니고, 관리하지 않으면 저절로 나빠진다. 프롬프트 한 줄을 다듬는 것보다, 무엇을 넣고 무엇을 빼고 무엇을 남길지 설계하는 감각 — 그게 요즘 LLM을 다루는 실력의 핵심이다. 이걸로 컨텍스트 엔지니어링 시리즈를 마친다.

자주 묻는 질문 (FAQ)

대화가 길어지면 왜 성능이 떨어지나요?

컨텍스트 한도를 넘거나 오래된·불필요한 내용이 쌓여 중요한 정보가 묻히기 때문입니다. 요약·정리로 관리해야 합니다.

긴 대화의 기억은 어떻게 관리하나요?

핵심을 주기적으로 요약해 남기고, 필요할 때 외부 저장소에서 검색해 불러오는 방식(메모리)으로 한도를 넘겨 유지합니다.