코딩 에이전트가 기록 파일을 직접 탐색하는 메모리, 정확도 72.5%에 질문당 약 2분

핵심 요약

1. 논쟁과 측정이 만나는 자리

10월 3일 Kevin Liao가 쓴 「Agents don't need memory, they need documentation」(10월 5일 수정)의 주장은 이렇습니다. 시중 메모리 플러그인은 대화에서 짧은 조각을 뽑아 벡터 DB에 넣고, 프롬프트마다 가장 비슷한 조각 다섯 개를 붙인다. 유사도는 어느 조각이 맞는지, 최신인지, 무엇이 빠졌는지 알려 주지 않는다. 그러니 에이전트가 읽고 고치는 문서 폴더를 두는 편이 낫다. 글쓴이는 이 방식을 구현한 자신의 오픈소스 플러그인(Operator Memory)을 함께 소개합니다. HN에서 380점·댓글 307개를 받았습니다(2026-10-08 HN API 조회).

이 블로그의 9월 21일 글 「에이전트 메모리는 파일로 간다」는 Karpathy의 LLM 위키부터 Google OKF 0.2까지 파일 기반 메모리 형식을 정리하면서, 파일 기반이 벡터 DB 기반보다 낫다는 통제된 비교는 읽은 자료 어디에도 없다고 적었습니다. LongMemEval-V2는 그 비교에 가장 가까운 공개 측정입니다. 같은 기록, 같은 질문, 같은 답변 모델로 벡터 검색 계열과 코딩 에이전트 계열을 나란히 쟀기 때문입니다. 아래에서 보듯 완전히 통제된 비교는 아닙니다.

2. 먼저 알아 둘 용어

• 실행 기록(trajectory)은 웹 에이전트가 과제 하나를 수행하며 거친 화면 상태와 행동의 연속입니다. 이 벤치마크에서는 각 상태의 접근성 트리(화면 구조를 텍스트로 나타낸 것)와 스크린숏이 들어 있습니다.
• 벡터 유사도 검색(RAG)은 기록을 조각으로 나눠 임베딩(의미를 숫자 벡터로 바꾼 값)으로 저장하고, 질문과 가장 비슷한 조각을 꺼내는 방식입니다. 이 논문의 RAG 방식은 Qwen3-Embedding-8B로 임베딩합니다.
• 제어 모델(memory controller)은 메모리 안에서 무엇을 찾을지 판단하는 모델입니다. RAG 방식에서는 검색어를 만들고, 코딩 에이전트 방식에서는 파일을 열고 명령을 실행합니다.
• 답변 모델(reader)은 메모리가 돌려준 근거만 받아 답을 쓰는 모델입니다. 모든 방식에서 Qwen3.5-9B로 고정했고, 답변 모델에 넘기는 근거는 최대 20만 토큰으로 자릅니다.
• 추론 강도(reasoning effort)는 OpenAI 모델이 답하기 전에 얼마나 오래 생각할지 정하는 설정입니다. low·medium·xhigh 순으로 길어집니다.

3. 무엇을 재는 벤치마크인가

2024년에 나온 LongMemEval(V1)은 사용자와 어시스턴트의 대화 기록을 다뤘습니다. V2는 대상을 웹 에이전트의 작업 기록으로 바꿨습니다. 질문은 같은 환경에서 오래 일한 동료라면 알 만한 것을 묻습니다. 어떤 작업을 하려면 어느 메뉴로 가야 하는지, 어떤 버튼이 화면의 무엇을 바꾸는지, 이 환경에서만 생기는 실패가 무엇인지 같은 것들입니다.

질문이 기록 없이는 풀리지 않는다는 점도 쟀습니다. 기록 없이 질문만 준 최신 모델들의 최고 정확도는 14.1%였고, 메모리 없이 답변 모델만 쓴 기준선은 1.3%였습니다.

4. 결과표

논문 Table 1에서 각 방식의 대표 행만 옮겼습니다. AgentRunbook-R과 AgentRunbook-C는 저자들이 이 논문에서 제안한 방식입니다.

초록의 72.5%·48.5%·69.3%는 Small과 Medium 값을 단순 평균한 것입니다. 초록이 비교 대상으로 든 "가장 강한 RAG 기준선 48.5%"는 요약 노트를 더한 RAG이고, 저자들이 제안한 AgentRunbook-R(평균 57.8%)은 빠져 있습니다. AgentRunbook-R과 비교하면 차이는 14.7%p입니다. 서론은 가장 단순한 RAG를 40.1%로 적었지만 표의 두 값을 평균하면 40.45%여서, 이 글은 표 값을 썼습니다.

Medium에서 AgentRunbook-C(70.1%)는 기본 Codex(68.7%)보다 높았지만, 논문 표에는 통계적으로 유의하다는 표시(쌍체 부트스트랩 검정, p<0.05)가 붙지 않았습니다. 같은 표에서 조회 스크립트를 뺀 변형이 71.8%로 전체 구성보다 높았습니다.

5. 72.5% 대 48.5%에서 함께 바뀐 것

표의 두 계열은 저장 방식만 다르지 않습니다. 제어 모델이 오픈 가중치 9B 모델과 OpenAI의 GPT-5.4-mini(추론 강도 xhigh)로 다릅니다. 논문 본문에도 저장 방식과 모델을 따로 떼어 본 실험, 곧 GPT-5.4-mini로 RAG를 돌린 행은 없습니다. 저자들의 8월 후속 공개에서도 찾지 못했습니다. 그래서 24.0%p 가운데 얼마가 파일 탐색 덕이고 얼마가 모델 덕인지는 이 자료로 나눌 수 없습니다.

같은 모델끼리 비교한 값은 두 군데 있습니다.

근거를 미리 좁혀 준 예비 실험

논문은 본 실험 전에 정답이 담긴 기록만 골라 주는 예비 실험을 했습니다(거짓 전제 질문 제외). 정답 기록을 통째로 넣으면 GPT-5.4-mini(추론 강도 medium)도 65.3%에 그쳤습니다. 정답이 담긴 상태와 그 앞뒤 상태 조각, 요약 노트만 넘기면 86.3%로 올랐고, 같은 기록을 파일로 둔 뒤 Codex(GPT-5.4-mini, xhigh)가 직접 탐색하게 하면 89.7%였습니다. 찾아야 할 범위가 이미 좁혀진 상태에서는 프롬프트에 넣는 방식과 파일 탐색의 차이가 3.4%p였고, 이 비교도 추론 강도는 달랐습니다. 본 실험의 큰 차이는 1억 토큰 안에서 정답 기록을 찾아내는 단계에서 생긴 것으로 읽힙니다. 이 해석은 이 글의 추론이고, 논문의 오류 분석은 코딩 에이전트 두 방식이 RAG보다 "검색 실패와 읽기 실패가 모두 적었다"고만 적었습니다.

저자들의 8월 후속 공개 — 추론 강도별 비교

2026-08 프로젝트 사이트에 올라온 AgentRunbook-C V2 업데이트에는 같은 GPT-5.4-mini로 추론 강도만 바꾼 Small 결과가 있습니다. 논문과 같은 xhigh 값(69.9%·177.2초, 74.9%·108.3초)은 논문 표와 일치합니다.

모델이 오래 생각하지 않을수록 작업 지침·목록 파일·조회 스크립트를 함께 더한 효과가 컸습니다. 다만 이 표는 코딩 에이전트 계열 안의 비교이고, RAG와 같은 모델로 맞춘 값은 여기에도 없습니다. 같은 페이지는 새 구성(V2)의 결과를 그래프와 표에 서로 다른 값으로 실어(medium에서 72.06%와 72.73%) 이 글에서는 옮기지 않았습니다.

6. 무엇을 빼면 점수가 떨어졌나

논문은 구성 요소를 하나씩 뺀 변형도 실었습니다. 같은 모델 안에서 비교한 값이라 "무엇이 효과를 냈나"에 가장 직접적인 근거입니다.

• 검색 순서를 적은 문서의 효과가 가장 컸습니다. 작업 지침을 빼면 두 규모 모두 5%p 안팎 떨어지고 조회 시간은 1.5배 넘게 늘었습니다. 기록을 요약한 목록 파일은 정확도보다 시간을 줄이는 쪽에 효과가 있었습니다.
• 요약만으로는 부족했습니다. AgentRunbook-R에서 원본 상태 조각을 빼자, Small의 화면 상태 질문 정확도는 66.1%에서 28.6%로 떨어졌습니다. 요약 노트는 기록이 많은 Medium에서 효과가 컸습니다(빼면 7.1%p 하락).
• 환경 특유의 함정은 모든 방식이 약했습니다. 가장 높은 값은 Small 58.6%(기본 Codex, 그리고 AgentRunbook-C에서 작업 지침을 뺀 변형), Medium 51.7%(기본 Codex)였고, 지침을 더한 AgentRunbook-C는 오히려 48.3%·44.9%로 낮았습니다. RAG에 요약 노트를 더하면 Small 함정 정확도가 20.7%에서 41.4%로 올랐습니다.

7. 정확도의 값은 시간으로 치렀다

AgentRunbook-C의 질문당 조회 시간은 평균 124초로, AgentRunbook-R(평균 26초)의 약 4.7배, 요약 노트 RAG(0.2~0.3초)의 수백 배입니다. 기본 Codex는 평균 약 182초였습니다. 논문은 제어 모델의 추론 강도가 조회 시간을 가장 직접적으로 좌우했다고 적고, 초록에서도 "코딩 에이전트 방식은 지연 비용이 크고, 개선 여지가 크게 남아 있다"고 밝혔습니다.

표의 RAG 조회 시간에는 기록을 넣을 때 드는 비용이 들어 있지 않습니다. AgentRunbook-R은 기록을 넣을 때 인접한 상태 전이마다 제어 모델로 설명을 생성하고, 기록마다 절차·주의 노트를 두 개씩 만듭니다. AgentRunbook-C는 기록을 파일로 저장만 합니다. 논문은 이 저장 단계의 비용이나 시간을 보고하지 않았습니다.

공식 리더보드는 정확도 하나로 순위를 매기지 않고, 1초~200초 사이의 지연 예산마다 도달할 수 있는 최고 정확도를 평균한 지표(LAFS)로 매기도록 설계됐습니다. 2026-10-08 기준 리더보드는 Small·Medium 모두 "Leaderboard entries coming soon" 상태로 비어 있습니다.

8. HN 논쟁에 비춰 보면

Liao의 글이 비판한 것은 "프롬프트마다 유사도 상위 다섯 조각을 자동으로 붙이는" 방식입니다. LongMemEval-V2의 결과는 그 방식이 기록이 많고 질문이 구체적인 환경에서 약하다는 쪽과 맞습니다. 가장 단순한 RAG는 Small 42.8%, Medium 38.1%였습니다.

반대로 이 벤치마크가 측정한 파일 방식은 Liao가 말한 "문서" 방식과 다릅니다. 코딩 에이전트가 연 것은 사람이나 에이전트가 정리한 명세·결정 기록이 아니라 원본 실행 기록 JSON과 스크린숏이었고, 위에 얹은 것은 기록 목록과 검색 순서를 적은 지침이었습니다. 문서에 가장 가까운 요소는 RAG 쪽의 요약 노트, 그리고 8월 V2가 질문을 처리할 때마다 갱신하는 검색 전략 노트입니다. 정리된 문서 폴더가 원본 기록 탐색이나 벡터 검색보다 나은지는 이 벤치마크가 재지 않았습니다.

또 하나, 이 벤치마크의 기록은 쇼핑몰 관리·사내 업무 시스템 같은 웹 환경에서 나왔습니다. 논문의 한계 절도 코딩 에이전트·컴퓨터 사용 에이전트는 메모리 요구가 다를 수 있다고 적었습니다. Liao의 논쟁은 코드 저장소에 관한 것이어서, 결과를 그대로 옮기기 어렵습니다. 같은 메모리 분야의 다른 벤치마크는 10월 4일 글 「DolphinBench, 과제 에이전트 비용은 총비용의 13.1% 이하」에서 다뤘습니다.

9. 체크리스트

10. 아직 결론이 아닌 것

• 저장 방식과 모델의 효과를 나눈 실험이 없습니다. RAG를 GPT-5.4-mini로, 또는 코딩 에이전트를 Qwen3.5 9B로 돌린 결과는 논문과 8월 업데이트 어디에도 없었습니다.
• 웹 에이전트 기록만 다룹니다. 논문의 한계 절은 코딩 에이전트·컴퓨터 사용 에이전트·기업 전용 에이전트는 다룬 범위 밖이라고 밝힙니다. 환경은 모두 합성 데이터의 영어 웹 화면입니다.
• 미리 모아 둔 기록으로 잽니다. 에이전트가 일하면서 기록이 계속 쌓이는 상황은 재현하지 않았습니다. 고정된 답변 모델이 맞혔는지를 재며, 실제 작업 성공률은 재지 않았습니다(한계 절).
• 벤치마크를 만든 연구진이 1위 방식도 제안했습니다. 외부 제출로 같은 결과가 재현됐는지는 리더보드가 비어 있어 알 수 없습니다.
• 심사를 거친 논문이 아닙니다. arXiv v1(2026-05-12) 하나뿐이며, 8월 업데이트는 프로젝트 사이트의 연구 노트입니다. 이 글은 그 페이지에서 Codex와 AgentRunbook-C 값만 옮겼습니다.
• 함정·전제 질문은 LLM이 채점합니다. 판정 모델은 GPT-5.2(추론 강도 medium)이고, 사람 채점과의 일치도는 이 글에서 대조하지 못했습니다.
• 문서 폴더 방식은 측정 대상이 아닙니다. HN 원글이 권하는 "에이전트가 관리하는 문서" 방식의 효과는 이 벤치마크로 판단할 수 없습니다.

참고자료

논문은 arXiv의 LaTeX 원본으로 받아 본문·부록·한계 절과 결과표를 2026-10-08에 대조했습니다.

논문이 개정되거나 리더보드에 외부 제출이 올라오면 이 글을 고치고 개정 날짜를 적겠습니다.