AI 에이전트 컨텍스트 관리: 요약 메모 검색을 나누는 기준

이 글에서 사용하는 주요 용어 정의

용어	정의
컨텍스트	모델이 이번 응답을 생성할 때 입력으로 받는 정보입니다.
압축·요약	긴 기록을 다음 판단에 필요한 내용으로 줄이는 작업입니다.
구조화 메모	목표·결정·진행 상태를 정해진 필드에 구분해 저장한 기록입니다.
검색	필요한 시점에 저장된 자료에서 관련 내용을 찾아오는 과정입니다.
원본 자료	요약이나 판단이 나온 근거를 다시 확인할 수 있는 기록입니다.

 

긴 작업의 컨텍스트를 관리하려면 이번 판단에 필요한 상태는 짧게 남기고, 근거가 되는 긴 자료는 다시 찾을 수 있게 보관해야 합니다. 반복 대화는 요약하고, 확정된 결정은 구조화 메모에 넣으며, 상세 로그는 경로와 검색 단서를 남기는 방식입니다.

기준일은 2026년 9월 8일입니다. 특정 제품의 자동 메모리 설정 대신, 여러 에이전트 도구에 적용할 수 있는 기록 설계를 다룹니다. 아래 예시는 설명을 위해 만든 로그 분석 도구 작업이며 실제 개발 경험이나 모델 성능 측정 결과가 아닙니다.

 

컨텍스트와 저장 파일의 역할을 구분해야 합니다

 

파일에 기록을 남겼더라도 다음 모델 호출에 그 내용을 전달하거나 검색할 절차가 필요합니다. 저장소에 자료가 존재하는 상태와 모델이 현재 그 자료를 입력으로 받은 상태를 구분해 설계해야 합니다.

Anthropic은 컨텍스트 엔지니어링을 설명하며 실행 중 필요한 자료를 가져오는 접근과 긴 작업을 위한 압축·구조화 메모 등을 소개합니다. 이를 참고해 이 글에서는 현재 판단에 필요한 정보와 나중에 불러올 정보를 나눕니다. 이는 특정 제품이 아래 JSON을 자동으로 읽는다는 뜻은 아닙니다. Anthropic: Effective context engineering for AI agents

예를 들어 CSV 로그를 JSON으로 요약하는 도구를 만든다고 가정해 보겠습니다. 작업 중 대화에는 출력 형식을 정한 결정, 실패한 실행 로그, 아직 읽지 않은 코드 경로가 함께 들어 있습니다. 이를 모두 “CSV 분석기 작업 중”으로 줄이면 다음 세션이 무엇을 이어 해야 하는지 판단하기 어렵습니다.

반대로 실패 로그 전체를 매번 붙이면 현재 결정이 어디 있는지 사람이 검토하기 번거롭습니다. 이 예제의 목표는 자료를 가장 짧게 만드는 일이 아니라, 작업을 이어받는 사람이 상태와 근거를 확인할 수 있게 만드는 것입니다.

 

반복 대화·확정 상태·상세 자료를 나누세요

세 가지 저장 방식을 자료의 성격에 맞춰 조합할 수 있습니다. 아래 분류는 이 글의 설계 제안이며 표준 프로토콜이 아닙니다.

원래 기록	남기는 방식	이유
같은 출력 형식을 여러 번 설명한 대화	최종 합의 한 문장으로 요약	반복은 줄이되 확정한 내용은 보존합니다.
외부 전송을 금지한다는 요구사항	제약 필드와 원문 위치	이후 구현에서도 확인할 조건입니다.
빈 CSV 처리가 맞는지 모르겠다는 메모	미확인 문제로 기록	검증 전에는 완료 상태와 구분합니다.
긴 오류 로그	파일 경로와 실패 지점	원인 분석 때 필요한 부분을 다시 읽습니다.
더 이상 쓰지 않는 구현 아이디어	현재 상태에서는 제외하고 원본에 보관	다시 검토할 때 근거를 찾을 수 있습니다.

 

요약에는 결정과 제약을 우선 남깁니다

“출력을 JSON으로 하자. CSV도 검토했지만 JSON으로 정했다. 키 이름은 level과 count다”라는 합성 대화는 “출력은 JSON이며 필드는 level, count로 확정”으로 줄일 수 있습니다. 사용자가 정한 제약은 결정 옆에 분명하게 남깁니다.

다만 “아마 빈 입력도 될 것 같다”는 말을 “빈 입력 지원 완료”로 바꾸면 안 됩니다. 자신감 있는 문장으로 다듬는 과정에서도 확인 여부는 그대로 보존해야 합니다. 원문에서 확인하지 못한 판단은 미확인 항목으로 옮깁니다.

 

구조화 메모에는 상태와 근거를 연결합니다

완료 목록은 실행 계획과 구분합니다. “테스트를 실행할 예정”은 다음 행동이고, “테스트를 실행했고 결과 파일을 확인함”은 해당 근거가 있을 때만 완료 기록입니다.

Anthropic의 장기 실행 에이전트 사례는 세션 사이 진행 파일과 Git 기록을 활용합니다. 이 글의 상태 메모는 그 접근을 참고한 자체 형식입니다. 실제로 어떤 파일을 읽고 갱신할지는 사용하는 실행 환경에 연결해야 합니다. Anthropic: Effective harnesses for long-running agents

 

상세 자료에는 다시 찾을 단서를 남깁니다

긴 자료의 경로만 적으면 어떤 목적으로 열어야 하는지 알기 어렵습니다. “설치 오류 로그”보다는 “의존성 설치가 실패한 로그, 마지막 오류 구간 확인”처럼 목적을 함께 남깁니다.

파일이 자주 바뀌는 프로젝트라면 마지막으로 확인한 시점이나 버전 식별자를 기록하도록 설계할 수 있습니다. 갱신 시점이 없으면 원문을 다시 읽은 뒤 메모를 최신 상태로 맞추는 쪽을 권합니다.

 

작업을 이어받기 위한 상태 JSON 예제

아래는 앞의 합성 작업을 기록한 state.json 전체입니다. notes/request.md와 src/summarize.py는 가상의 경로이며, 실제 파일이나 완료된 프로젝트가 있다는 의미는 아닙니다.

{
  "objective": "CSV 로그를 읽어 JSON 요약을 만드는 로컬 도구 구현",
  "constraints": [
    "입력은 CSV, 출력은 JSON",
    "로그 및 결과를 외부로 전송하지 않음"
  ],
  "decisions": [
    {
      "id": "D1",
      "text": "출력 필드는 level, count로 정함",
      "source": "notes/request.md#output",
      "status": "confirmed"
    }
  ],
  "completed": [
    {
      "text": "출력 형식에 관한 요구사항 확인",
      "source": "notes/request.md#output"
    }
  ],
  "open_questions": [
    {
      "text": "빈 CSV 입력의 동작은 아직 검증하지 않음",
      "source": "src/summarize.py"
    }
  ],
  "next_actions": [
    "출력 형식 요구사항과 현재 코드를 대조",
    "빈 CSV 입력 테스트를 실행하고 결과 기록"
  ],
  "sources": [
    {
      "path": "notes/request.md",
      "purpose": "사용자 요구사항",
      "checked_at": "2026-09-08"
    },
    {
      "path": "src/summarize.py",
      "purpose": "검토할 구현",
      "checked_at": null
    }
  ]
}

 

이 형식에서 objective는 작업의 목적, constraints는 작업 중 지킬 조건입니다. 결정은 decisions, 확인이 끝난 상태는 completed에 둡니다. 아직 검증하지 않은 빈 입력 처리는 open_questions에 남겼습니다.

checked_at: null은 해당 구현 파일을 아직 확인하지 않았다는 예시입니다. 이 값만으로 파일이 잘못됐다는 결론을 내리지는 않습니다. 다음 실행자는 요구사항 원문과 구현을 먼저 읽고, 빈 CSV 동작을 테스트한 뒤 결과에 맞게 상태를 갱신합니다.

최상위 갱신 날짜만 두는 방식도 가능하지만 자료마다 확인 시점이 다를 수 있습니다. 이 예제는 그 차이를 보이기 위해 출처별 시점을 넣었습니다. 실제 업무에서는 필요한 필드만 유지하고, 갱신할 수 없는 정보를 형식적으로 채우지 않는 편이 낫습니다.

 

JSON 문법과 내용의 정확성은 별도로 확인합니다

파일을 저장한 디렉터리에서 아래 명령으로 JSON 문법을 확인할 수 있습니다.

python -m json.tool state.json

 

이 글에 포함된 JSON은 Python으로 파싱되는 것을 확인했습니다. 다만 문법 검사는 경로의 존재, 결정의 정확성, 모델의 기억 능력을 검증하지 않습니다. 원본과 대조하는 절차와 실제 에이전트 실험은 별도로 필요합니다.

JSON이 익숙하지 않다면 같은 항목을 Markdown 소제목으로 기록해도 됩니다. 이 예제에서 필요한 것은 특정 파일 확장자가 아니라 미확인 사항을 완료 목록에 섞지 않는 규칙입니다.

 

요약한 뒤 원문을 다시 읽을 조건을 정하세요

결정이 서로 충돌하거나 완료 근거가 없으면 해당 원문을 먼저 확인하도록 정할 수 있습니다. 에이전트에게 “필요하면 다시 읽기”만 맡기기보다, 다시 읽을 조건을 구체적으로 남기는 것이 이 설계의 제안입니다.

발견한 상태	다음 처리
메모와 최신 사용자 지시의 출력 형식이 다름	최신 지시와 변경 근거를 확인하고 결정을 갱신합니다.
완료라고 적혔지만 결과 파일이나 실행 기록이 없음	완료 근거를 찾고 없으면 미확인으로 돌립니다.
오류 요약만 있고 실패한 입력을 알 수 없음	원본 로그에서 입력 조건과 실패 지점을 확인합니다.
원문 경로가 사라지거나 변경됨	대체 위치를 찾고 출처 정보를 수정합니다.

충돌하는 결정을 발견했을 때 임의로 더 간단한 문장을 선택하면 요구사항이 바뀔 수 있습니다. 이 예제라면 CSV 출력과 JSON 출력 중 어느 쪽이 최종 결정인지 원문에서 확인한 뒤 D1을 수정합니다. 근거가 불충분하면 질문으로 남겨야 합니다.

요약에 포함된 내용도 현재 작업과 맞는지 읽어야 합니다. 이미 해결한 질문이 계속 남거나 새 제약이 빠져 있으면 다음 세션에 낡은 작업을 넘기게 됩니다. 상태를 갱신하는 시점을 작업 종료 또는 주요 결정 직후처럼 정해 두는 방식을 제안합니다.

 

효과를 확인하려면 같은 과제로 비교합니다

이 글에서는 요약 방식에 따른 모델 성능을 비교하지 않았습니다. 자기 환경에서 효과를 판단하려면 같은 과제와 같은 완료 기준을 준비하고, 기록을 전달하는 방식만 바꿔 관찰할 수 있습니다.

앞의 로그 분석 예제라면 “JSON 출력 유지”, “외부 전송 없음”, “빈 CSV 검증 여부를 정확히 보고”를 판정 항목으로 정할 수 있습니다. 전체 기록을 넘기는 경우와 상태 메모·원문 경로를 넘기는 경우에 각각 작업을 이어 보게 하고, 최종 파일과 실행 기록으로 판단합니다.

실패 이유도 나누어 기록하는 편이 좋습니다. 요약에서 제약을 빠뜨린 문제, 필요한 원문을 찾지 못한 문제, 자료는 읽었지만 구현을 잘못한 문제는 수정할 지점이 다릅니다. 입력 길이만 줄었다는 이유로 작업 품질도 좋아졌다고 결론 내릴 수는 없습니다.

지금 사용 중인 작업 기록 하나에서 목표·확정 결정·미확인 문제·원문 위치를 분리해 보세요. 다음 사람이 그 기록만 보고 무엇을 확인하고 이어 해야 하는지 설명할 수 있는지부터 점검하면 됩니다.

 

참고 자료

• Anthropic — Effective context engineering for AI agents, 2025-09-29 게시.
• Anthropic — Effective harnesses for long-running agents, 2025-11-26 게시.