환경 탐침 큐레이션: 메모리를 쓰기 전에 환경을 다시 열어 보게 했더니 통과율이 39%에서 73%로 올랐다

마이크로소프트 연구진은 2026년 9월 10일 arXiv에 공개한 논문 2609.11060에서 에이전트의 장기 메모리를 기록하기 전에 큐레이터가 읽기 전용 도구로 환경을 직접 확인하는 환경 탐침 큐레이션(environment-probing curation)을 제안했다. CLBench 데이터베이스 탐색 과제에서 이 방식은 통과율을 39%에서 73%로, 보상을 8.60에서 22.60으로 올리면서 문항당 질의를 8.8개에서 4.7개로, 작업 에이전트 비용을 3.38달러에서 1.68달러로 낮췄다. 핵심은 작업 에이전트의 능력을 키우지 않았다는 점이다. 모델도 검색기도 메모리 표현도 쓰기 권한도 그대로 두고 큐레이터에게만 읽기 전용 도구를 준 결과이며, 저자들은 이를 쓰기 시점 증거 품질의 개선이라고 부른다. ASAP은 논문 원문에 적힌 수치와 설계만으로 무엇이 검증됐고 무엇이 열려 있는지 정리한다.

완료된 궤적만 보고 쓴 메모리는 세 가지 방식으로 틀린다

논문이 지목한 문제는 메모리의 표현이나 검색이 아니라 증거의 경계다. 과제가 끝난 뒤 메모리를 정리하는 큐레이터는 보통 완료된 궤적과 채점 결과만 본다. 궤적 하나는 환경에 대한 부분적이고 실수가 섞인 단일 관측이므로, 그 위에서 만들어진 기록은 절차 대신 특정 문제의 답을 외우거나, 비효율적인 경로를 그대로 물려받거나, 확인할 수 없는 적용 범위를 주장하거나, 방문하지 않은 영역을 빈칸으로 남기거나, 환경이 바뀌면 낡은 정보가 된다. 검증을 나중으로 미루면 다음 과제를 맡은 에이전트가 자기 도구 예산을 불확실한 메모리를 다시 확인하는 데 쓰게 된다.

환경 탐침 큐레이션은 여기에 한 단계를 끼워 넣는다. 과제가 끝나면 비동기 큐레이터가 원본 궤적과 증류된 궤적과 채점 결과를 받고, 후보 기록을 제안한 뒤 읽기 전용 도구로 그 주장만 확인하고 나서 생성하거나 수정하거나 범위를 좁히거나 삭제하거나 건너뛴다. 제안과 탐침과 커밋으로 이어지는 순서다. 탐침은 답이 불확실한 지점을 겨냥한다. 우연한 답과 재사용 가능한 관계를 구분하고, 관찰된 절차와 더 짧은 경로를 비교하고, 주장한 관계를 다른 구간에서 시험하고, 절차의 전제 조건을 확인하고, 궤적이 건너뛴 상태를 들여다보고, 드리프트가 의심되면 현재 환경에 다시 질의한다.

권한 설계가 이 방법의 절반이다

큐레이터가 받는 것은 기존 커넥터나 MCP 도구의 최소 권한 읽기 전용 부분집합이다. 탐침은 환경을 바꿀 수 없고, 작업 궤적에 들어가지 않으며, 작업 에이전트의 예산을 쓰지 않고, 앞으로 나올 과제나 정답을 볼 수 없다. 사용자 응답 경로 밖에서 비동기로 돌기 때문에 지연도 늘리지 않고, 플랫폼의 인증과 감사 체계를 그대로 물려받는다. 안전한 읽기 표면이 없는 환경에서는 궤적만 보는 기존 큐레이션으로 자동 복귀한다.

작업 에이전트 쪽은 반대로 잠겨 있다. 작업 에이전트는 memory_read로만 메모리에 접근하고 생성이나 수정이나 삭제 도구를 갖지 않으므로 과제 수행 중에 공유 메모리를 바꿀 수 없다. 쓰기 권한은 큐레이터에게만 있고, 큐레이터는 다음 과제가 공개되기 전에 작업을 마치므로 미래 과제가 메모리로 새지 않는다. 재학습도 필요 없다. 이 설계 덕분에 실험의 증분은 작업 에이전트의 능력 변화가 아니라 기록에 들어간 증거의 품질 변화만 가리킨다.

CLBench 40문항에서 네 가지 구성이 갈린 지점

주 실험은 GPT-5.4로 돌린 40문항 드리프트 일정이다. SQLite 스키마가 20번 문항 뒤에 바뀌도록 숨겨져 있어 재사용과 낡은 메모리 복구를 함께 시험한다. 조인 관계가 감춰져 있고 타임스탬프와 가격 인코딩이 섞여 있으며, 드리프트에서는 필드 이름이 바뀌고 소프트 삭제가 추가된다. 비교 대상은 메모리 없는 GHCP, 이전 궤적을 통째로 앞에 붙이는 Full ICL, 색인형 메모리인 GHCP + Mem, 그리고 환경 탐침을 더한 구성이다. 각 구성은 짝지은 시드로 5회씩 돌렸다.

메모리를 붙인 세 구성은 모두 기준선보다 나았다. 통과율은 39%에서 61~73%로, 총 보상은 8.60에서 20.00~22.60으로 올랐고, 이는 기준선의 2.3~2.6배다. 동시에 문항당 질의는 8.8개에서 3.0~5.6개로, 작업 에이전트 비용은 3.38달러에서 1.68~2.01달러로 내려갔다. 정확도를 힘으로 밀어 올린 것이 아니라 이미 알아낸 스키마와 인코딩과 도구 관례를 다시 발견하는 데 쓰던 예산이 줄었다는 뜻이다.

구성별로 성격이 다르다. Full ICL은 질의를 3.0개로 가장 적게 쓰지만 문맥이 스트림 길이에 비례해 늘어나 입력 토큰을 5.42M 소비했다. 색인형 메모리는 통과율 70%에 입력 2.13M이고, 환경 탐침을 더한 구성은 통과율 73%와 보상 22.60으로 가장 높으면서 입력은 1.69M으로 가장 적다. 드리프트 구간에서는 마이그레이션 경계에서 이미 누적 보상 0.541 대 0.486으로 앞섰고 최종 0.565 대 0.500으로 끝났으며, 메모리 없는 구성은 0.215에서 멈췄다.

드리프트를 뺀 30문항 일정은 모델을 바꿔 가며 확인했다. Opus 4.7에서 궤적 전용 메모리는 짝지은 기준선 대비 0.252, 환경 탐침은 0.263을 올렸고, Sonnet 4.6에서는 각각 0.351과 0.421을 올렸다. 평균 보상 자체도 탐침 쪽이 두 모델에서 모두 높다(0.721과 0.748).

APEX 90과제에서는 비용 대비 이득이 갈렸다

두 번째 벤치마크는 컨설팅 분석 업무를 옮긴 APEX 90과제로, 6개 문서 월드에서 PDF와 XLSX와 DOCX와 PPTX를 찾아 정량 분석까지 수행한다. 6개 월드와 3개 메모리 구성을 교차한 18개 비교에서 평균 보상 이득은 전부 양수였고, 작업 에이전트 도구 호출은 16~75% 줄었다. 달러당 보상 이득으로 보면 환경 탐침이 6개 월드 중 5개에서 가장 좋았고 남은 한 곳에서는 궤적 전용 메모리가 근소하게 앞섰다.

감소폭이 가장 큰 곳은 기준선의 탐색 비용이 가장 비싼 월드였다. 941eba66 월드에서 도구 호출은 71.6회에서 17.7~19.3회로, 입력 소비는 53.92M 토큰에서 6.56~7.67M으로, 실행당 비용은 54.30달러에서 7~9달러로 내려갔다. 전체적으로는 기준선 평균 30.0~71.6회이던 도구 호출이 13.9~28.4회로 줄었다. 반면 Full ICL은 개별 월드에서 원 보상을 이길 때도 있으나 문맥이 계속 커져 비싸고, 한 월드에서는 메모리 없는 기준선보다도 비용이 컸다.

기록의 문장이 달라지는 방식이 결과를 설명한다

논문이 제시한 대표 사례는 기록 문장 자체의 성격 차이를 보여준다. 궤적만 본 큐레이터는 답에 묶인 경고를 남겼다. 널이 아닌 행에 대해 AVG(items_g2.prc_usd)로 답하지 말라는 것, 그렇게 하면 약 52.96이 나오는데 정답은 96.23이므로 다른 가격 필드나 행 부분집합이 필요하다는 것이다. 탐침을 거친 큐레이터는 실행 가능한 절차를 남겼다. items_g2를 ref_id로 taxn_g2에 조인하고, cat_lvl이 1인 행과 정확한 cat_nm으로 거르고, items_g2.prc가 0보다 큰 행만 남긴 뒤 걸러진 AVG(prc)와 비교하라는 문장이다. 스키마가 바뀐 뒤 attrs_g3를 쓰라던 낡은 기록도 product_attributes_g3를 쓰라는 문장으로 브랜드 필터와 집계 단위와 함께 갱신됐다.

짝지은 궤적 비교도 같은 이야기를 한다. CLBench의 한 과제에서 메모리 없는 구성은 질의 7개를 쓰고 실패했고, 궤적 전용 메모리는 9개를 쓰고 통과했으며, 탐침으로 검증된 ref_id 관계를 받은 구성은 질의 2개로 통과했다. 어려운 APEX 과제에서는 메모리 없는 구성이 96회 호출로 두 기준을 모두 놓쳤고, 궤적 전용 메모리는 인당 매출 계산 절차를 옮겨 받아 11회로 통과했으며, 검증된 워크북 지도를 받은 탐침 구성은 6회로 끝냈다. 논문은 이 사례들이 집계 효과를 증명하지 않는다고 스스로 못 박았다.

이 숫자에서 인상적인 쪽과 신중히 볼 쪽은 다르다

인상적인 쪽은 정확도와 비용이 같은 방향으로 움직였다는 점이다. 보통 통과율을 올리려면 더 많은 탐색과 더 긴 문맥을 허용해야 하고 비용이 따라 오른다. 여기서는 통과율이 39%에서 73%로 오르는 동안 입력 토큰이 3.14M에서 1.69M으로, 비용이 3.38달러에서 1.68달러로 내려갔다. 환경 탐색이라는 반복 작업을 작업 시점에서 큐레이션 시점으로 옮긴 결과이고, 옮겨진 쪽은 사용자 대기 시간 밖에 있다.

신중히 볼 쪽은 회계와 불확실성이다. 논문의 비용 수치는 작업 에이전트 비용이며 증류와 큐레이션 단계는 따로 추적해 제외했다고 명시돼 있다. 탐침이 추가로 소비하는 호출과 토큰이 포함된 총소유비용 비교는 이 논문이 답하지 않는 질문이다. 신뢰구간도 겹친다. 궤적 전용 메모리의 통과율은 70±16이고 탐침 구성은 73±5이므로, 두 구성의 평균 차이보다 변동 폭이 크다. 실제로 탐침 쪽의 더 큰 기여는 평균값이 아니라 분산이 줄었다는 데 있다.

저자들도 효과가 조건부라고 적었다. 탐침의 추가 이득은 2a87e5cb에서 1.77, 2f84c98b에서 1.09로 컸지만 941eba66에서는 0.04만큼 오히려 낮았고, 드리프트 없는 조건에서도 Sonnet 4.6의 추가 이득(0.075)이 Opus 4.7(0.025)보다 컸다. 궤적이 조인이나 파일 위치나 절차를 미해결로 남겼을 때 탐침이 쓸모 있고, 궤적만으로 이미 실행 가능한 기록이 나오는 경우에는 보탤 것이 적다는 해석이며, 논문은 불확실성 구간이 겹치므로 확정된 하위 집단 효과가 아니라 메커니즘 해석으로 다룬다고 밝혔다.

국내 팀이 이 설계를 옮길 때 먼저 볼 조건

첫 번째 조건은 큐레이터에게 열어 줄 안전한 읽기 표면이며, arXiv 2609.11060의 설계는 기존 커넥터나 MCP 도구의 최소 권한 부분집합을 전제한다. 사내 데이터베이스나 문서 저장소에 읽기 전용 커넥터가 이미 있고 감사 로그가 남는 환경이라면 이 방법은 기존 스택 위에 큐레이터 권한만 추가해 얹힌다. 읽기 전용 접근을 별도로 만들어야 하는 조직이라면 그 작업이 실질적인 도입 비용이고, 논문은 그런 경우 궤적 전용 큐레이션으로 물러선다고 적었다.

두 번째 조건은 과제 흐름의 성격이다. 실험은 같은 환경에서 관련 과제가 순차로 들어오고 과제가 반복되지 않으며 환경이 예고 없이 바뀔 수 있는 설정을 전제한다. 사내 데이터 분석 요청이나 반복되는 문서 기반 업무처럼 환경 구조를 계속 재발견하는 업무가 여기 해당한다. 반대로 매번 다른 환경을 다루는 일회성 작업에서는 메모리가 상환할 발견 자체가 쌓이지 않는다.

세 번째 조건은 회계 기준이다. 논문이 보상을 계산할 때 쓴 식은 통과 여부에 도구 호출 예산 대비 절약분을 곱하는 형태이고, 예산은 CLBench 15회 질의와 APEX 100회 호출로 고정돼 있다. 도입 검토에서 이 방식을 재현하려면 기준 예산을 자기 업무에 맞게 먼저 정해야 하고, 여러 채점 기준이 있는 과제는 전부 통과해야 1점으로 세는 엄격 통과 기준을 쓸지도 정해야 한다.

이 논문이 비워 둔 자리

첫 번째 공백은 총비용이다. 탐침 단계의 호출과 토큰이 비용 표에서 빠져 있으므로, 큐레이션까지 합쳤을 때도 궤적 전용 메모리보다 싼지는 이 논문으로 말할 수 없다. 두 번째 공백은 규모다. 실험은 CLBench 40문항과 30문항 일정, APEX 90과제라는 짧은 스트림에서 이뤄졌고, 기록이 수백에서 수천 건으로 쌓였을 때 큐레이터가 중복과 충돌을 어떻게 감당하는지는 다루지 않는다. 세 번째 공백은 쓰기 권한 경계의 안전성 자체다. 읽기 전용이면 안전하다는 전제는 설계 원칙으로 제시됐을 뿐, 탐침이 민감한 데이터를 메모리로 옮길 위험을 어떻게 막는지에 대한 실험은 없다.

정리하면 이 논문의 기여는 새 메모리 구조가 아니라 메모리를 쓰는 시점의 증거를 바꾼 데 있다. 작업 시점 인터페이스를 고정한 채 큐레이터에게만 읽기 전용 도구를 준 구성이라, 개선분이 어디서 왔는지가 드물게 분명하다. 다음 확인 지점은 큐레이션 비용까지 포함한 비교와 기록이 장기간 누적된 환경에서의 재현이다.

출처: Suresh·Mak·Bhatnagar·Methani·Gutierrez Munoz 'Grounding Agent Memory: Environment-Probing Curation for Enterprise Agents'(arXiv:2609.11060v1, 2026년 9월 10일, 마이크로소프트)