AI 에이전트 메모리 설계: 긴 작업을 로그 파일처럼 검색하는 법

긴 작업을 하는 AI 에이전트가 실패하는 이유는 종종 추론 능력 부족이 아니라 이미 본 사실을 다시 찾지 못하거나, 반대로 너무 많은 과거를 한꺼번에 들고 와 현재 판단을 흐리는 데 있다. 나는 에이전트 메모리를 “대화 내용을 오래 보관하는 기능”으로만 보면 이 문제가 반복된다고 본다. 7월 22일 공개된 PRO-LONG 연구는 완전한 구조화된 상호작용 기록을 남기고, 코딩 에이전트가 그 기록을 검색하게 하는 방식으로 이 선택지를 다시 제시했다. 공개 ARC-AGI-3 게임 세트에서 기반 코딩 에이전트보다 평균 18.0%p 높았고, 특화 하네스와 같거나 더 높은 최대 76.1% pass@1을 4.2~5.8배 적은 토큰으로 달성했다고 보고했다. 아직 사전 공개 연구의 결과라 모든 제품에 그대로 적용할 수는 없다. 하지만 운영 원칙은 실용적이다. 긴 작업의 기억은 프롬프트에 계속 붙이는 요약문이 아니라, 재검증할 수 있는 전체 기록과 지금 필요한 증거를 고르는 검색 절차로 설계해야 한다.

긴 컨텍스트는 기억이 아니라 혼잡이 되기 쉽다

장기 작업에서 가장 쉬운 대응은 이전 메시지, 도구 출력, 파일 내용, 실패 로그를 계속 대화 맥락에 넣는 것이다. 시작은 편하다. 문제는 세션이 길어질수록 오래된 가설과 폐기된 오류가 현재 과제와 같은 무게를 갖는다는 데 있다. 모델은 입력이 길어질수록 비용이 늘고, 관련 없는 정보에 주의가 분산되며, 무엇이 마지막으로 검증된 사실인지 구별하기 어려워진다.

LangChain의 LangGraph 문서도 이 구분을 명확히 한다. 짧은 메모리는 스레드별 상태와 체크포인트로 유지해 재개에 쓰고, 장기 메모리는 사용자나 애플리케이션 수준의 namespace에 둔다. 또한 긴 대화는 컨텍스트 창을 넘지 않더라도 stale 정보 때문에 성능·응답 시간·비용 문제가 생길 수 있다고 설명한다. 여기서 중요한 점은 “더 오래 저장하라”가 아니라 어떤 범위의 기억을 어떤 순간에 읽을지 정하라는 것이다.

긴 조사 작업을 예로 들어 보자. 에이전트가 저장소를 읽고, 에러를 재현하고, 의존성을 확인하고, 세 번의 수정안을 버렸다면 네 종류의 정보는 같은 방식으로 기억할 대상이 아니다.

• 현재 작업 상태: 마지막 실행 명령, 실패 여부, 다음 재개 지점은 스레드 체크포인트에 둔다.
• 사실 증거: 파일 경로, 커밋, 테스트 출력, 원문 URL은 나중에 다시 열 수 있는 참조로 남긴다.
• 실패 이력: 이미 반증된 가설과 실패 조건은 같은 길을 반복하지 않게 구조화한다.
• 운영 규칙: 권한 경계, 리뷰 기준, 배포 금지 같은 절차는 프로젝트 범위의 별도 규칙으로 관리한다.

완전한 기록은 남기고, 모델에는 작은 증거 묶음만 준다

PRO-LONG의 흥미로운 선택은 긴 상호작용을 요약 하나로 압축하지 않고 complete, structured interaction log로 유지한다는 점이다. 그리고 최근 코딩 에이전트의 파일 탐색 능력을 이용해 그 기록에서 필요한 부분을 찾는다. 이 구조는 요약의 편리함을 부정하지 않는다. 대신 요약이 원본을 대체하지 않도록 만든다. 누락되거나 잘못 일반화된 요약이 발견되면, 운영자와 에이전트 모두 원래 관찰·명령·출력을 다시 확인할 수 있기 때문이다.

실무에서는 작업 이벤트를 JSON Lines 같은 append-only 형식으로 남겨도 충분히 시작할 수 있다. 아래 명령은 실패한 테스트 이벤트만 좁혀 보기 위한 최소 예시다. memory/events.jsonl은 작업 실행 중 생성한 내부 기록이어야 하며, 비밀값·원문 자격 증명·개인정보를 넣지 않는다는 전제가 필요하다.

python3 - <<'PY'
import json
from pathlib import Path

for line in Path("memory/events.jsonl").read_text().splitlines():
    event = json.loads(line)
    if event.get("kind") == "test" and event.get("status") == "failed":
        print(event["at"], event["target"], event["summary"])
PY

이 명령의 목적은 메모리 시스템을 새로 만드는 것이 아니다. 현재 질문에 필요한 증거를 좁히는 데 있다. 같은 원칙으로 에이전트는 kind, status, repo, task_id, artifact_path, source_url 같은 필드로 검색할 수 있다. 검색 결과에는 원문 전체보다 “어디에서 어떤 사실을 확인했는가”를 먼저 돌려준다. 그 뒤 필요한 파일·로그·URL만 다시 읽으면, 모델은 과거를 잊지 않으면서도 과거 전체에 묻히지 않는다.

기록 스키마는 작게 시작하는 편이 낫다.

at            : 관찰 또는 실행 시각
kind          : research | command | test | decision | artifact
status        : started | passed | failed | rejected
summary       : 재검색 가능한 짧은 설명
evidence      : 파일 경로, commit, URL, 로그 위치
supersedes    : 새 판단이 대체한 이전 event id

특히 supersedes나 rejected를 남기는 습관이 중요하다. 에이전트는 성공 기록만 모으면 같은 실패 가설을 다시 시도한다. 반증된 경로를 명시해야 다음 실행이 “무엇을 더 할까”뿐 아니라 “무엇을 더 하지 않을까”도 안다.

메모리의 핵심 품질은 회상률보다 재검증 가능성이다

에이전트 메모리 논의는 종종 벡터 검색 정확도나 저장량으로 흘러간다. 물론 검색 품질은 중요하다. 하지만 운영에서 먼저 확인할 질문은 이 기록을 사람이 다시 열어 검증할 수 있는가다. “사용자가 A를 선호함” 같은 문장이 기억에 남아 있어도 언제, 어떤 맥락에서, 어느 범위에 적용되는지 모르겠다면 자동화 판단의 근거가 되기 어렵다.

그래서 좋은 기억 항목은 결론과 근거를 분리한다. 예를 들어 배포 보류라는 결론만 저장하지 말고, 테스트 X 실패, 변경 파일 Y, 재현 명령 Z, 승인 필요자를 연결한다. LangGraph 문서가 말하는 semantic·episodic·procedural 메모리 구분도 여기서 쓸모가 있다. 사실은 semantic, 과거 실행은 episodic, 승인된 규칙은 procedural에 가깝다. 한 벡터 인덱스에 전부 넣는 대신, 각 타입의 작성자·보존 기간·조회 권한을 다르게 두는 편이 더 안전하다.

운영 체크는 세 가지면 시작할 수 있다.

1. 출처 확인: 검색 결과가 파일·URL·커밋·로그 위치 중 하나를 가리키는가.
2. 범위 확인: 이 기억이 현재 사용자·프로젝트·작업에만 적용되는가.
3. 폐기 확인: 새 증거가 이전 판단을 뒤집으면 이전 항목을 supersede하거나 만료시키는가.

내 의견: 요약을 똑똑하게 만드는 것보다 원본으로 돌아갈 길을 남겨야 한다

내 의견은 분명하다. 긴 작업 에이전트의 메모리에서 가장 위험한 설계는 매 단계의 기록을 그럴듯한 한 문단 요약으로 덮어쓰는 방식이다. 요약은 빠른 재개에 좋지만, 실패한 가설과 예외 조건을 조용히 지울 수 있다. 가벼운 반론도 있다. 완전한 로그와 검색 인덱스를 관리하면 작은 자동화에는 과한 비용일 수 있다. 맞다. 한 번 답하고 끝나는 FAQ 봇에 이벤트 원장을 만들 필요는 없다. 다만 코드 수정, 리서치, 브라우저 자동화, 데이터 변환처럼 여러 단계가 연결되고 나중에 판단 근거를 물을 수 있는 작업이라면, 저장 비용보다 재조사 비용과 반복 실패 비용이 더 빨리 커진다. 이때 메모리는 개인화 기능이 아니라 실행 품질을 복구하는 운영 인프라다.

한국 개발자에게 남는 실무 원칙

김덕환 운영자 관점에서는 에이전트가 길게 일할수록 “무엇을 기억했나”보다 “그 기억이 어디서 왔고 다시 확인할 수 있나”를 묻는 것이 중요하다. 처음부터 거대한 기억 플랫폼을 도입할 필요는 없다. 작업별 event log, 프로젝트별 승인 규칙, 검색 결과의 파일·URL 참조 세 가지만 분리해도 다음 작업은 이전 요약을 믿는 대신 이전 증거를 이어받을 수 있다. 긴 실행을 믿을 수 있게 만드는 것은 더 긴 프롬프트가 아니라, 필요할 때 원본으로 되돌아가는 짧고 명확한 경로다.

참고 자료

• PRO-LONG: Programmatic Memory Enables Long-Horizon Reasoning — arXiv:2607.20064, 2026-07-22
• LangGraph Docs — Memory overview: short-term checkpoints and long-term namespaces
• arXiv cs.AI recent submissions — 2026-07-23, PRO-LONG 포함