오래된 기억을 그대로 두지 않고 세상에 다시 물어보는 법

Grounding Agent Memory: Environment-Probing Curation for Enterprise Agents는 arXiv 2609.11060으로 공개된 연구입니다. 이 연구는 완료된 궤적만 읽는 비동기 큐레이터가 오류를 굳히고 부분 증거를 넓게 일반화하며 오래된 지식을 남기는 문제를 진단하고, 같은 큐레이터에게 최소 권한 읽기 전용 세계 도구를 주어 후보 기억을 확인하고 범위를 좁히고 새로 고치자고 제안합니다. 원문은 제목 아래 연결된 링크에서 볼 수 있습니다.

제가 이 논문을 처음 펼친 것은 기억 저장소가 커질수록 답이 좋아진다는 말을 현장에서 그대로 믿기 어려웠기 때문입니다. 저장한 문장이 많아지면 검색 결과는 그럴듯해지는데, 막상 에이전트가 돌리는 쿼리는 그대로 헤매는 장면을 여러 번 봤기 때문입니다. 그래서 기억을 더 모으는 이야기가 아니라 기억을 다듬는 이야기에 마음이 갔습니다. 이 글에서는 그 다듬는 과정이 어떻게 달라졌는지, 그리고 숫자가 어디까지 말해주는지를 차례로 따라가겠습니다.

왜 이 기억 이야기가 자꾸 눈에 밟혔을까

오래 일하는 에이전트를 떠올리면 대개 세션이 끊겨도 이어지는 경험을 상상합니다. 어제 풀던 데이터베이스 구조를 오늘 다시 설명하지 않아도 되고, 지난주에 헤맸던 스키마를 이번 주에는 피해 가는 모습이죠. 그런데 이런 그림은 저장만으로 완성되지 않습니다. 저장된 문장 가운데 틀린 추론이 섞여 있으면 에이전트는 다음 세션에서도 같은 곳에서 넘어지기 때문입니다.

저는 여기서 멈칫했습니다. 보통은 리트리버를 고치거나 임베딩을 바꾸는 쪽을 먼저 생각하는데, 이 연구는 저장 직전의 손을 주목하고 있기 때문입니다. 이미 돌아가고 있는 태스크 에이전트와 리트리버, 기억 표현은 그대로 두고, 뒤에서 기억을 고르는 큐레이터의 일하는 방식을 바꾸자는 것이죠. 모델을 다시 학습하지 않으니 도입 부담이 작아 보이고, 운영 중인 파이프라인을 뜯지 않아도 된다는 점에서 실무적인 냄새가 났습니다.

그렇다면 궁금해집니다. 궤적만 읽던 큐레이터에게 세상을 만질 도구를 쥐여주면 무엇이 달라질까요. 오늘은 그 질문을 끝까지 들고 가겠습니다.

세션이 끝나면 경험은 어디에 남을까

엔터프라이즈 에이전트에서 오래 가는 기억은 대개 세션 사이를 잇는 형태로 들어옵니다. 한 세션에서 얻은 교훈을 문장으로 적어두면 다음 세션에서 검색되어 답에 스며드는 구조죠. 이런 흐름에서 큐레이터는 경기가 끝난 뒤 기록을 정리하는 사람과 비슷합니다. 어떤 문장을 남기고 어떤 문장을 버릴지 고르는 것이죠.

문제는 그다음입니다. 경기 기록에만 의존하면 기록에 찍힌 착각까지 함께 남게 됩니다. 완료된 궤적에는 에이전트가 우연히 맞힌 답도 있고, 특정 데이터베이스에서만 통하는 관찰도 있고, 이미 바뀐 스키마를 전제로 한 추론도 있습니다. 궤적 밖을 보지 못하는 큐레이터는 이런 차이를 가리기 어렵고, 그래서 오류를 굳히거나 부분 증거를 넓게 펼치거나 낡은 지식을 살려두는 일이 생깁니다.

생각해보면 사람도 비슷하게 배웁니다. 회의록만 읽고 현장을 한 번도 밟아보지 않은 사람이 다음 회의 자료를 고르면, 회의록에 적힌 오해까지 정리가 되어버리기 쉽습니다. (물론 회의록이 정확한 날도 있지만, 그 정확함을 누가 보증할까요.) 그래서 저는 이 문제를 저장 용량의 문제가 아니라 검증 통로의 문제로 읽었습니다.

궤적만 읽는 큐레이터는 왜 자꾸 틀릴까

궤적만 읽는 방식은 얼핏 합리적으로 보입니다. 실제 일이 어떻게 풀렸는지를 그대로 복기하니 현장감이 있고, 추가 시스템을 붙이지 않아도 되니 가볍기 때문입니다. 그런데 논문이 짚는 지점은 이 가벼움이 곧 맹점이 된다는 데 있습니다. 궤적은 결과가 아니라 과정의 흔적이고, 그 흔적에는 운과 편향이 함께 묻어 있기 때문입니다.

예를 들어 특정 질문에서 에이전트가 잘못된 조인으로 우연히 정답 행을 건졌다고 해봅시다. 궤적만 보면 성공 사례처럼 보이고, 그래서 잘못된 조인 규칙이 기억으로 남을 수 있습니다. 또 어떤 관찰은 그날의 데이터베이스 상태에서만 맞았는데, 문장으로 적히는 순간에는 조건이 떨어져 나가면서 일반 규칙처럼 굳기도 합니다. 시간이 지나 스키마가 바뀌면 예전에는 맞던 기억이 조용히 틀린 기억으로 바뀌는데, 궤적 안에서는 그 변화를 알아챌 방법이 없습니다.

여기서 재미있는 질문이 생깁니다. 기억의 품질은 모은 문장의 개수로 정해질까요, 아니면 남기기 전에 다시 확인한 횟수로 정해질까요. 저는 후자에 가깝다고 봅니다. 이 연구가 큐레이터를 기록 정리 담당에서 현장 확인 담당으로 옮겨놓은 것도 같은 판단으로 읽혔습니다.

세상을 직접 두드려 보라는 제안은 무엇이 다른가

이 연구가 제안하는 환경 탐색 큐레이션은 말을 바꾸면 꽤 직관적입니다. 후보 기억을 확정하기 전에, 큐레이터가 직접 세상을 두드려보고 오라는 것이죠. 이미 있는 비동기 큐레이터는 그대로 두되, 그 손에 세상과 상호작용하는 읽기 전용 도구를 쥐여주는 방식입니다. 그래서 태스크 에이전트의 동작도, 검색기의 동작도, 기억의 표현 방식도 바뀌지 않습니다.

저는 이 숫자보다 그 뒤의 구조가 더 중요하다고 봅니다. 새로 배우는 모델이 아니라 새로 확인하는 절차를 도입했기 때문입니다. 다시 학습하지 않으니 실험실이 아니라 운영 환경에서도 붙여볼 수 있고, 기존 쓰기 권한 체계도 그대로 유지되니 거버넌스 입장에서도 설명이 쉽습니다. 저희가 새로운 AI 아키텍처를 볼 때도 점수만 보지는 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 봅니다.

그렇다면 이 방식은 단순한 필터일까요. 다음 흐름을 보면 그렇게 부르기에는 하는 일이 많습니다. 확인하고, 범위를 좁히고, 새로 고치는 세 가지 움직임이 서로 이어지기 때문입니다.

다시 학습하지 않고 그대로 두는 선택은 왜 필요했을까

이 제안에서 제가 인상 깊게 본 부분은 바꾼 것보다 바꾸지 않은 목록입니다. 태스크 에이전트는 그대로 두고, 리트리버도 그대로 두고, 기억 표현도 그대로 두며, 운영 쓰기 권한도 큐레이터에게 넘기지 않습니다. 큐레이터가 얻는 것은 세상을 어지럽히지 않는 읽기 도구뿐입니다. 그래서 이 설계는 새로운 기억 시스템을 도입하자는 말이 아니라, 이미 있는 큐레이터의 눈을 하나 더 뜨게 하자는 말에 가깝습니다.

이런 선택은 오해를 줄여줍니다. 기억 큐레이션이라고 하면 흔히 임베딩을 바꾸거나 스키마를 갈아엎는 큰 공사를 떠올리기 쉬운데, 여기서는 그런 공사가 없습니다. 표현이 바뀌지 않으니 기존 검색 품질이 흔들릴 이유가 줄고, 쓰기 권한이 그대로 있으니 누가 최종 기록을 책임지는지도 흐려지지 않습니다. 운영 측면에서 보면 이 차이는 상당히 큽니다. 밤사이 스키마가 바뀌거나 권한 체계가 손질되는 와중에도, 읽기 확인 절차는 옆에서 조용히 돌 수 있기 때문입니다.

그런데 읽기만으로 충분할까요. 현장 답사가 지도 제작을 대신할 수는 없듯이, 탐색도 만능은 아닙니다. 다만 기억을 남기기 전에 한 번이라도 현장을 밟아본 문장과 한 번도 밟지 않은 문장은 이후 검색에서 다르게 행동할 가능성이 큽니다. 저는 그래서 이 절제를 일종의 안전장치로 읽었습니다.

확인하고 좁히고 고치는 일은 어떻게 이어질까

탐색 큐레이터의 움직임은 세 단계로 풀어볼 수 있습니다. 먼저 후보 기억이 지금 세상에서 맞는지 확인하고, 이어서 그 기억이 통하는 범위를 좁히며, 마지막으로 바뀐 세상에 맞게 내용을 새로 고칩니다. 확인과 범위 조정과 새로 고침이 한 흐름으로 이어지는 것이죠.

구체적인 장면을 그려보겠습니다. 월요일 오전에 분석 에이전트가 고객 테이블과 주문 테이블을 엮는 문장을 남기려 한다고 해봅시다. 궤적만 읽는 큐레이터라면 그 문장이 성공한 궤적에서 나왔다는 이유로 그대로 두기 쉽습니다. 반면 탐색 큐레이터는 읽기 도구로 지금의 스키마를 조회해보고, 그 조인이 여전히 성립하는지 따져보며, 특정 지역 코드에서만 통하는 관찰이라면 문장 안에 조건을 함께 남깁니다. 컬럼 이름이 바뀌었다면 바뀐 이름을 반영해 문장을 고칩니다.

이 흐름이 마음에 드는 이유는 각 단계가 서로의 빈틈을 메우기 때문입니다. 확인이 없으면 낡은 사실이 남고, 범위 조정이 없으면 부분 관찰이 일반 규칙으로 부풀며, 새로 고침이 없으면 맞는 말도 표현이 낡아 검색에서 멀어집니다. 세 가지가 함께 돌 때 기억은 조금씩 현재에 붙어 있게 됩니다. 그렇다면 다음 질문은 자연스럽습니다. 이렇게 확인하는 손은 얼마나 조심스럽게 설계되어야 할까요.

읽기 전용이라는 제약이 오히려 힘이 되는 이유

읽기 전용과 최소 권한이라는 말은 얼핏 소극적으로 들립니다. 뭔가 대단한 능력을 준 것이 아니라 권한을 깎은 것처럼 보이기 때문입니다. 그런데 실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 큐레이터가 운영 데이터를 마음대로 바꿀 수 있다면, 그 확인 절차를 누가 감시할까요.

이 설계는 그 걱정을 구조로 푼 셈입니다. 큐레이터는 세상을 읽어서 검증할 수 있지만, 운영 기록을 직접 고치는 권한은 갖지 않습니다. 그래서 탐색하다가 실수해도 운영 테이블이 더러워지지 않고, 감사 입장에서도 읽기 로그만 보면 되니 추적이 쉽습니다. 권한이 작으니 붙이기 쉽고, 붙이기 쉬우니 자주 돌릴 수 있으며, 자주 돌리니 기억이 현재에 붙어 있을 확률이 올라갑니다.

좋은 건 알겠는데, 이걸 실제로 어떻게 서빙할까요. 비동기라는 말이 바로 그 답에 가깝습니다. 큐레이터는 태스크 에이전트가 답을 내는 길목에 서 있지 않고, 일이 끝난 뒤 옆에서 조용히 확인 작업을 돌립니다. 그래서 답변 지연에 직접적인 짐을 얹지 않으면서도, 다음 세션의 검색 품질에는 미리 영향을 줄 수 있습니다. 저는 이 배치를 점수보다 눈여겨봤습니다. 빠르게 답하는 길과 오래 남을 기억을 고르는 길이 서로를 막지 않게 나눠져 있기 때문입니다.

데이터베이스 탐사에서 숫자는 어떻게 달라졌을까

이제 숫자를 볼 차례입니다. 평가는 GitHub Copilot의 SDK 위에 올린 실제 운영 같은 하네스에서 이뤄졌고, 무대는 데이터베이스 탐사 과제인 CLBench와 컨설팅 과제 90개를 고쳐 만든 APEX였습니다. 실험실 장난감이 아니라 운영에 가까운 자리에서 돌렸다는 점이 먼저 눈에 들어옵니다.

CLBench에서는 변화가 한 번에 드러납니다. 통과율이 39퍼센트에서 73퍼센트로 올랐고, 통과 여부를 반영한 보상은 8.60에서 22.60으로 뛰었습니다. 저는 통과율 자체보다 헤매는 움직임이 함께 줄었다는 대목에 더 오래 눈이 갔습니다. 질문당 조회가 8.8회에서 4.7회로 줄었고, 태스크 에이전트 비용이 건당 3.38달러에서 1.68달러로 내려갔기 때문입니다. 맞히는 비율이 올랐는데 헤매는 움직임은 줄었다는 뜻이고, 그래서 정확도와 효율이 같은 방향으로 움직였습니다.

여기서는 조금 조심해서 읽을 필요가 있습니다. 비용이 줄었다는 말이 곧바로 전체 운영비가 줄었다는 뜻은 아니기 때문입니다. 큐레이터가 뒤에서 탐색하는 데에도 비용이 들고, 그 비용을 어디에 잡느냐에 따라 표가 달라질 수 있습니다. 그럼에도 태스크 에이전트의 발품이 절반 가까이 줄었다는 점은 실무적으로 묵직합니다. 현장에서 가장 비싼 것은 대개 답을 내는 에이전트의 시행착오이기 때문입니다.

여섯 개의 컨설팅 세계에서는 무슨 일이 생겼을까

APEX 쪽 결과는 결이 조금 다릅니다. 여섯 개의 세계에서 90개 컨설팅 과제를 돌렸는데, 기억을 쓴 쪽과 쓰지 않은 쪽을 견준 18개 평균 보상 비교가 모두 양수였습니다. 하나만 좋아진 것이 아니라 여섯 세계를 가로질러 고르게 앞섰다는 뜻입니다. 동시에 태스크 에이전트의 도구 호출이 16퍼센트에서 75퍼센트까지 줄었습니다. 세계마다 폭은 달랐지만 방향은 같았습니다.

비용 대비 관점도 눈에 띕니다. 다섯 개 세계에서 탐색 방식이 달러당 태스크 에이전트 보상 증가가 가장 좋았습니다. 돈을 쓸 때 어디에 쓰는 게 남는지를 따지는 셈인데, 기억을 확인하는 데 쓴 비용이 답을 내는 쪽의 헤매짐을 줄여 전체 효율을 끌어올린 것으로 읽힙니다. 모델을 바꾼 실험에서도 탐색 방식은 Sonnet 4.6과 Opus 4.7 모두에서 GHCP에 기억을 얹은 조합보다 평균 보상이 높았고, 스키마 이탈도 없었습니다.

개인적으로는 스키마 이탈이 없었다는 대목이 오래 남았습니다. 기억을 고치다 보면 표현이 멋대로 늘어나는 경우가 많은데, 여기서는 그런 흐트러짐 없이 보상이 올라갔기 때문입니다. 물론 여섯 개 세계가 현실의 모든 엔터프라이즈를 대신할 수는 없습니다. 다만 방향이 한쪽으로 쏠리지 않고 고르게 나왔다는 점에서, 다음에 물을 질문의 무게가 달라졌습니다. 이 방식이 통하지 않는 세계는 어떤 모습일까요.

숫자를 그대로 믿기 전에 무엇을 더 물어야 할까

여기까지 읽으면 탐색이 만능처럼 느껴질 수 있습니다. 그래서 잠시 속도를 늦추고 싶습니다. 겉보기에 좋아 보이는 평균 뒤에는 늘 조건이 있기 때문입니다. 여섯 세계에서 고르게 앞섰다는 말은 든든하지만, 그 여섯 세계가 어떤 편향을 공유하는지는 따로 물어야 합니다. 데이터베이스와 문서가 잘 갖춰진 세계에서는 읽기 확인이 힘을 내기 쉽고, 반대로 접근 권한이 촘촘하거나 상태가 자주 바뀌는 세계에서는 같은 절차가 다른 비용을 낼 수 있습니다.

달러당 보상이라는 잣대도 그대로 받아들이기 전에 구성을 봐야 합니다. 태스크 에이전트의 이득을 분모에 무엇을 두었는지, 큐레이터의 탐색 비용을 어디까지 포함한 것인지에 따라 해석이 달라지기 때문입니다. 다섯 개 세계에서 가장 좋았다는 결과는 분명 강한 신호지만, 여섯 번째 세계에서 무엇이 달랐는지를 아는 편이 다음 도입을 판단하는 데 더 도움이 됩니다. 스키마 이탈이 없었다는 점도 마찬가지입니다. 표현이 흐트러지지 않았다는 것은 반가운 소식이지만, 그 안정이 어떤 guardrail 덕분인지가 다음 설계의 재료가 됩니다.

그렇다면 이 흐름은 어디에서 끊길까요. 읽기 확인은 세상이 읽을 수 있을 때만 작동합니다. 권한 때문에 볼 수 없는 곳, 로그가 남지 않는 구두 결정, 자주 바뀌어 어제 확인이 오늘 보증이 되지 않는 곳에서는 같은 절차도 헛돌 수 있습니다. 저는 그래서 이 결과를 성공 선언이 아니라 사용 설명서에 가깝게 읽었습니다. 잘 통하는 자리에서는 깊게 쓰고, 잘 통하지 않는 자리에서는 무엇이 막히는지부터 적어야 하는 것이죠.

그래서 현장의 기억 설계는 어디로 가야 할까

처음으로 돌아가 보겠습니다. 기억을 많이 모으는 일과 기억을 현재에 붙여두는 일은 서로 다른 일입니다. 이 연구는 후자에 손을 댔고, 그 손은 뜻밖에도 거창하지 않았습니다. 이미 있는 큐레이터에게 세상을 읽는 도구를 주고, 확인하고 좁히고 고치는 절차를 돌리며, 쓰기 권한과 표현과 검색기는 그대로 두는 방식이었기 때문입니다.

제가 앞으로 보고 싶은 것은 이 절차가 더 지저분한 현장에서 어떻게 버티는지입니다. 권한이 자주 바뀌는 조직, 스키마가 밤사이 바뀌는 창고, 사람의 구두 결정이 자주 끼어드는 업무에서는 읽기 확인의 비용과 효과가 달라질 수밖에 없습니다. 그때도 통과율과 보상과 도구 호출이 같은 방향으로 움직일까요. 아니면 어떤 세계에서는 차라리 확인을 줄이고 범위를 좁히는 쪽에 힘을 실어야 할까요.

그렇다면 사람의 역할은 무엇일까요. 저는 기억을 남길지 말지를 고르는 마지막 판단에 사람이 계속 있어야 한다고 봅니다. 기계가 세상을 읽어주는 속도는 빨라져도, 어떤 기억이 조직의 판단으로 남을 만한지는 결국 사람이 정해야 하기 때문입니다. 오래된 기억을 버리지 않고 세상에 다시 물어보는 일, 그 반복이 에이전트를 조금씩 현장에 붙어 있게 만들 것입니다.