MemComposer: 기억을 고르는 게 아니라 조립하는 에이전트

MemComposer: Learning to Assemble Memories for LLM Agents via Reinforcement Learning는 arXiv에 공개된 논문으로, 식별자는 2610.21091입니다. 이 논문이 내세우는 주장은 한 문장으로 정리할 수 있지요. 과거 경험을 닮은 순서대로 꺼내는 일이 아니라, 지금 질문에 맞춰 어떤 기억을 몇 개 어떤 순서로 건넬지를 강화학습으로 직접 배우면 에이전트의 과제 성공률이 올라간다는 것입니다. 그래서 이번 글에서는 그 주장을 따라 검색과 조립이 어디에서 갈라지는지, 그리고 그 차이가 실험에서 어떻게 확인됐는지를 살펴보겠습니다. 원문은 제목 아래에 걸어두었습니다.

많이 넣어준 기억이 왜 도움이 안 될까요

에이전트에게 지난 경험을 꺼내 건네면 일을 더 잘할 거라고 기대하기 쉽습니다. 저도 처음에는 그렇게 생각했지요. 파라미터를 고치지 않고도 경험을 재사용한다는 말이 듣기만 해도 효율적이라서, 손대지 않고 똑똑해지는 방법처럼 들렸기 때문입니다. 그런데 막상 시스템을 만져보면 이상한 장면이 자주 나타납니다. 기억을 다섯 개 넣었을 때보다 열 개 넣었을 때 답이 더 흔들리고, 분명 관련 있어 보이는 사례를 줬지만 에이전트는 엉뚱한 방향으로 가곤 하니까요.

왜 그럴까요. 생각해보면 사람도 비슷합니다. 시험을 앞두고 오답 노트를 열 권째 펼쳐두면 오히려 머릿속이 복잡해지지요. 어떤 페이지를 먼저 볼지, 어디까지 읽을지 정해지지 않으면 자료는 짐이 되기 때문입니다. 에이전트도 이 점에서는 다르지 않습니다. 그런데도 그동안 많은 논의는 어디에 어떤 기억을 저장할지, 어떻게 빨리 찾을지에 머물렀습니다. 정작 실행기 앞에서 펼쳐지는 장면, 그러니까 지금 질문 앞에서 기억을 어떻게 엮어서 보여줄지는 상대적으로 덜 다뤄졌지요.

제가 이 논문에서 가장 흥미롭게 본 부분은 바로 그 빈틈입니다. 검색이 잘 되면 에이전트도 잘할 거라는 믿음에 논문은 조용히 의문을 제기합니다. 닮았다는 점수와 도움이 된다는 점수는 다른 문제인데도, 우리는 오랫동안 앞의 점수로 뒤를 대신해 왔기 때문입니다. 그렇다면 무엇을 바꿔야 할까요. 이 질문에서 MemComposer 이야기가 시작됩니다.

검색 점수가 높으면 좋은 기억일까요

검색 시스템은 대개 닮음으로 말합니다. 지금 질문과 문장이 비슷하거나 같은 단어를 많이 품고 있으면 위로 올리지요. 이 방식은 빠르고 구현하기 쉽습니다. 그래서 많은 메모리 에이전트가 이 순서를 그대로 믿고 위에서부터 몇 개를 잘라 프롬프트에 붙였습니다.

하지만 닮음은 도움이 된다는 뜻과 어긋날 때가 있습니다. 표현은 비슷해도 풀어야 할 절차가 다르면 그 기억은 오히려 방해가 되지요. 겉보기에는 같은 환불 요청처럼 보여도, 한쪽은 주소 변경이 얽혀 있고 다른 한쪽은 결제 수단 변경이 얽혀 있으면 에이전트가 참고해야 할 행동 순서는 완전히 달라집니다. 반대로 표현은 달라도 순서 감각이나 실패 패턴을 알려주는 기억은 큰 도움이 됩니다. 닮음만 보면 앞의 기억을 올리고 뒤의 기억을 버리게 되지만, 과제 성공이라는 눈으로 보면 순위가 뒤집혀야 합니다.

여기서는 조금 조심해서 읽을 필요가 있습니다. 논문이 검색 자체를 부정하는 것은 아니기 때문입니다. 검색은 후보를 좁히는 일로는 여전히 쓸모가 있습니다. 문제가 되는 지점은 그다음입니다. 좁혀진 후보를 어떤 기준으로 최종 손님상에 올릴지를 검색 점수에만 맡겼다는 데 있지요. 저는 이 구분이 마음에 들었습니다. 찾는 일과 차려내는 일을 나눈 것인데, 찾는 일이 도서관 사서의 일이라면 차려내는 일은 손님 앞에서 메뉴를 고르는 주방장의 일에 가깝습니다.

그래서 조립한다는 말은 무슨 뜻일까요

MemComposer라는 이름에는 태도가 담겨 있습니다. Composer, 그러니까 작곡가나 편집자처럼 기억을 조립하는 별도의 역할이 있다는 것이지요. 실행기 에이전트는 그대로 두고, 그 앞에 어떤 기억을 건넬지를 정하는 작은 결정자를 둡니다. 이 결정자는 현재 질문 하나만 보지 않고, 질문과 함께 딸려온 후보 기억들을 나란히 놓고 봅니다.

이 장면을 그림으로 떠올리면 이해가 쉽습니다. 질문이 왼쪽에 있고 후보 기억이 오른쪽에 펼쳐져 있지요. Composer는 후보를 하나씩 따로 채점하지 않고 서로를 비교하면서 고릅니다. 이 기억을 넣으면 저 기억과 겹치지 않을까, 이 순서를 앞에 두면 실행기가 먼저 읽고 방향을 잡을 수 있을까 같은 판단을 함께 내리지요. 그래서 결정의 내용은 세 가지로 묶입니다. 무엇을 넣을지, 몇 개를 넣을지, 어떤 순서로 둘지입니다.

여기서 재미있는 질문이 생깁니다. 왜 세 가지를 따로 배우지 않고 함께 배울까요. 이유는 실행기가 보는 것이 결국 하나의 묶음이기 때문입니다. 포함 여부만 정하고 순서를 검색 점수에 맡기면 앞에서 본 닮음의 함정에 다시 빠지고, 개수를 정하지 않고 무조건 많이 넣으면 앞에서 본 짐의 문제가 돌아옵니다. 논문이 이 세 가지를 한 정책으로 묶은 것은 실행기가 실제로 읽는 단위가 낱개 기억이 아니라 조립된 맥락이라는 점을 받아들였기 때문입니다. 저희가 새로운 AI 아키텍처를 볼 때도 benchmark 숫자만 보지는 않고, 실제로 무엇이 바뀌었고 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 봅니다. 같은 눈으로 보면 이 설계는 숫자를 올리기 위한 장치가 아니라, 읽는 단위에 맞춘 자리 배치입니다.

개수를 정하는 일도 왜 배워야 할까요

개수는 사소해 보이지만 막상 만져보면 가장 손이 많이 가는 손잡이입니다. 고정된 개수를 쓰면 어떤 질문에는 모자라고 어떤 질문에는 넘치지요. 질문마다 필요한 배경의 양이 다르기 때문입니다. 간단한 조회에는 한두 장이면 충분하지만, 여러 단계를 거쳐야 하는 요청에서는 실패 사례 하나가 더 들어가야 방향이 잡히기도 합니다.

문제는 그다음입니다. 개수를 사람이 정하면 매번 시행착오가 따르고, 닮음 점수로 자르면 점수 분포가 질문마다 달라서 기준이 흔들립니다. 그래서 논문은 개수를 규칙이 아니라 학습의 대상으로 둡니다. 지금 질문과 후보들의 상태를 보고 몇 장까지가 도움이 될지를 그때그때 정하지요. 적게 주는 용기와 많이 주는 판단이 함께 필요한 자리입니다.

실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 개수를 줄이면 토큰이 아껴지지만, 성능은 어떻게 될까요. 보통은 둘 중 하나를 포기해야 한다고 생각하기 쉽습니다. 저렴하게 가면 성적이 떨어지고, 성적을 지키려면 비싸게 가야 한다는 믿음 때문이지요. 그런데 뒤에서 다룰 실험 결과는 이 믿음과 조금 다르게 나옵니다. 이 지점을 미리 기억해 두시면 뒤의 숫자가 더 또렷하게 읽힙니다.

순서를 바꾸면 결과가 정말 달라질까요

순서는 미신처럼 들리기도 합니다. 같은 내용을 주는데 순서가 뭐 그리 중요하냐는 것이지요. 하지만 언어 모델을 오래 써본 분들은 경험으로 알고 있습니다. 앞에 나온 말이 뒤의 해석을 이끄니까요. 처음에 읽은 사례가 기준점이 되고, 나중에 읽은 것은 그 기준에 비춰서 읽힙니다.

그래서 같은 다섯 장이라도 배열이 달라지면 실행기의 첫걸음이 달라집니다. 쉬운 성공 사례를 앞에 두면 에이전트는 자신 있게 따라가다가 예외에서 미끄러질 수 있고, 실패와 복구 과정을 담은 기억을 앞에 두면 처음부터 조심스럽게 확인하면서 갑니다. 어느 쪽이 좋다는 정답은 질문마다 다릅니다. 그렇기 때문에 순서를 고정 규칙에 맡기기 어렵지요. 앞의 기억이 뒤의 기억을 어떻게 물들일지를 함께 고려해야 하니까요.

저는 이 대목을 읽으면서 편집자의 일을 떠올렸습니다. 글의 재료는 같아도 배열에 따라 독자가 받는 인상이 달라지지요. 에이전트의 프롬프트도 하나의 작은 지면이라서, 무엇을 먼저 보여줄지는 글의 첫 문장을 고르는 일과 비슷합니다. 논문이 순서까지 정책의 출력에 넣은 것은 그래서 꾸밈이 아니라 읽힘에 대한 판단이라고 봅니다.

성공이라는 보상으로 직접 배우면 뭐가 달라질까요

이제 배우는 방식으로 넘어가 보죠. 논문이 제안하는 학습 틀의 이름은 Experience Policy Optimization, 줄여서 ExPO입니다. GRPO 계열의 강화학습 틀을 가져와서 기억 조립이라는 문제에 맞췄다고 합니다. 이름에서 풍기는 감각 그대로, 경험을 재료 삼아 정책을 다듬는 방식이지요.

흐름은 이렇게 이해할 수 있습니다. Composer가 어떤 묶음을 만들면, 그 묶음을 받은 실행기 에이전트가 실제 과제를 끝까지 수행합니다. 그리고 그 상호작용 전체가 끝난 뒤에 성공했는지 실패했는지를 보지요. 중간에 검색 점수가 몇 점이었는지는 묻지 않고 마지막에 일이 풀렸는지를 묻습니다. 잘 풀린 묶음은 더 자주 만들도록, 빗나간 묶음은 덜 만들도록 정책이 움직입니다.

이 차이는 생각보다 중요합니다. 기존의 많은 방법은 닮음이라는 대리 목표를 올렸지요. 대리 목표는 편합니다. 점수가 바로 나오고 학습도 안정적이니까요. 하지만 대리 목표가 진짜 목표와 어긋나면 점수는 오르는데 일은 안 풀리는 이상한 상태에 갇힙니다. ExPO는 돌아가는 길을 택합니다. 보상이 늦게 오고 시끄럽더라도 진짜 목표를 직접 겨냥하지요. 표면적으로 보면 단순합니다. 성공하면 칭찬하고 실패하면 고치라는 말처럼 들리니까요. 실제로는 그렇지 않습니다. 어떤 기억의 어떤 선택이 성공에 기여했는지를 묶음 단위에서 거슬러 올라가야 해서, 설계가 꽤 조심스러워야 합니다.

여기서 한 가지 오해를 미리 걷어낼 필요가 있습니다. 강화학습이라고 해서 실행기 모델 자체를 다시 학습시키는 것은 아닙니다. 실행기는 얼려둔 채로 두고 기억을 고르는 정책만 배우지요. 이 분리는 실무적으로 마음에 드는 선택입니다. 무거운 모델을 매번 손대지 않고도 기억 쓰는 법만 갈아 끼울 수 있기 때문입니다. 좋은 건 알겠는데, 이걸 실제로 어떻게 서빙할까요. Composer 하나를 얹는 비용과 실행기 전체를 다시 학습시키는 비용을 나란히 두면, 답은 금방 보입니다.

토큰을 덜 쓰면서 더 잘한다는 건 무슨 뜻일까요

평가 이야기로 들어가 보겠습니다. 논문은 세 개 영역으로 이뤄진 tau2-bench에서 실험했고, 두 종류의 얼려둔 실행기 에이전트를 썼다고 합니다. 기억을 쓰는 여러 기준선과 견줘서 가장 강한 기준선을 넘는지를 봤지요. 결과는 성공률과 비용이 함께 움직였다는 데 있습니다. 한 실행기에서는 평균 기억 토큰을 16.9% 줄이면서 넘었고, 다른 실행기에서는 4.9% 줄이면서 넘었다고 합니다.

숫자가 아니라 구조를 봐야 하는 이유가 여기 있습니다. 저는 이 숫자보다 그 뒤의 구조가 더 중요하다고 봅니다. 토큰을 덜 썼다는 말은 기억을 더 적게 넣었다는 뜻이기도 하지만, 더 정확히는 필요 없는 기억을 빼고 남는 기억을 더 잘 앉혔다는 뜻에 가깝기 때문입니다. 많이 넣어서 가리는 방식이 아니라, 가려서 넣는 방식으로 이겼다는 것이지요.

이 대목은 그대로 믿기 전에 조건을 봐야 합니다. 평균이라는 말이 들어 있어서, 어떤 질문에서는 더 많이 쓰고 어떤 질문에서는 훨씬 적게 썼을 수 있습니다. 논문이 말하는 절감은 매번 같은 양을 깎았다는 뜻이 아니라, 질문에 맞춰 개수를 조절한 결과로 평균이 내려갔다는 뜻에 가깝습니다. 그래서 저는 이 결과를 다이어트 성공담처럼 읽지 않았습니다. 덜 먹어서가 아니라, 몸에 맞게 먹어서 오래 버텼다는 이야기로 읽었지요. 운영 측면에서 보면 이 차이는 상당히 큽니다. 매 요청마다 프롬프트가 길어지면 대기열이 밀리고 비용이 쌓이는데, 평균 토큰이 내려가면서 성공률이 올라갔다면 그건 단순한 절약이 아니라 여유를 버는 일이기 때문입니다.

처음 보는 환경에서도 통할까요

배운 정책이 배운 자리에서만 통한다면 반쪽짜리 성과겠죠. 그래서 제가 논문에서 눈여겨본 또 하나의 대목은 전이에 대한 보고입니다. 학습 때 보지 못한 영역, 학습 때 쓰지 않은 실행기, 학습 때 쓰지 않은 기억 저장소에서도 배운 조립 방식이 통했다고 합니다.

왜 이 보고가 눈에 띌까요. 보통 검색 기준은 저장소가 바뀌면 손을 봐야 할 때가 많기 때문입니다. 말투가 바뀌고, 기록의 길이가 바뀌고, 쌓인 경험의 밀도가 바뀌면 닮음의 감각도 함께 흔들리지요. 그런데 조립 정책이 낯선 곳에서도 통했다는 말은 정책이 외운 것이 표면의 말이 아니라 묶음을 만드는 요령에 가깝다는 뜻입니다. 무엇을 앞에 두고 무엇을 빼는지에 대한 감각이, 무대를 옮겨도 어느 정도 살아남았다는 것이지요.

다만 여기서는 조금 조심해서 읽을 필요가 있습니다. 전이가 됐다는 말이 어디서든 똑같이 잘 된다는 뜻은 아니기 때문입니다. 논문이 전한다는 범위는 실험이 닿은 범위 안에서의 이야기인데, 저장소의 성격이 극단적으로 달라지거나 실행기의 버릇이 크게 다르면 결과는 달라질 수 있습니다. 저는 그래서 이 부분을 가능성으로 읽었습니다. 한 번 배운 손맛이 다른 주방에서도 통했다는 보고로는 충분히 고무적이지만, 모든 주방에서 같은 맛이 난다는 보증으로는 읽지 않는 편이 좋겠습니다. 그렇다면 다음 질문은 자연스럽게 이어집니다. 기억의 질이 달라지면 이 조립자는 어떻게 반응할까요.

더 좋은 기억이 생기면 다시 배워야 할까요

마지막 실험 보고 가운데 실무자의 마음을 움직이는 대목이 있습니다. 더 강한 모델이 만든 기억이 생겼을 때, Composer를 다시 학습시키지 않고도 덕을 봤다는 것이지요.

이 말의 뜻을 풀어보면 이렇습니다. 기억을 만드는 일과 기억을 차리는 일을 나눠뒀기 때문에, 재료가 좋아지면 차리는 솜씨는 그대로 둔 채로도 상이 더 좋아진다는 것입니다. 주방 비유를 이어가면, 장보는 곳이 바뀌어 재료가 좋아졌는데 조리법을 바꿀 필요가 없었다는 말에 가깝습니다. 분리가 잘 되어 있다는 증거이기도 하지요.

실제 시스템 관점에서 보면 이 성질은 운영의 아침을 지켜줍니다. 기억 저장소는 살아 움직이는데, 좋은 사례가 쌓이고, 기록 방식이 바뀌고, 더 똑똑한 모델이 만든 요약이 들어옵니다. 그때마다 조립 정책을 처음부터 다시 배워야 한다면 운영은 금방 지치지요. 다시 배우지 않고도 좋아진다는 말은 이 장치가 저장소의 성장과 함께 늙지 않고 같이 자랄 수 있다는 뜻입니다. 물론 이것도 조건이 있습니다. 재료가 완전히 다른 종류가 되면 이야기가 달라질 수 있지요. 하지만 같은 결 안에서 질이 올라가는 경우에는 다시 배움 없이 이득을 본다는 보고만으로도, 분리의 값어치는 충분히 드러납니다.

그래서 에이전트에게 기억이란 무엇일까요

앞에서 미뤄뒀던 질문으로 돌아올 차례입니다. 에이전트에게 기억이란 무엇일까요. 저장된 문장일까요, 아니면 건네는 방식일까요. 이 논문의 답은 분명히 뒤쪽에 가깝습니다. 기억은 꺼내는 순간에 완성되는 것이 아니라, 지금 질문 앞에서 어떤 묶음으로 차려내느냐에 따라 도움이 되기도 하고 짐이 되기도 한다는 것이지요.

이런 시각은 평가의 눈도 바꿉니다. 그동안 우리는 기억 시스템을 검색의 눈으로만 봤습니다. 얼마나 빨리 찾는지, 얼마나 닮은 것을 찾는지요. 그런데 MemComposer가 던지는 질문은 다릅니다. 그래서 그 기억을 받은 에이전트가 실제로 일을 풀었는가 하는 것이지요. 잣대가 닮음에서 성공으로 옮겨가면 설계의 우선순위도 바뀝니다. 무엇을 저장할지보다 어떻게 건넬지가 앞으로 나오고, 몇 개를 넣을지와 어떤 순서로 둘지가 일등 시민이 됩니다.

제가 앞으로 보고 싶은 것은 이 조립이라는 생각이 어디까지 뻗어 나갈지입니다. 지금은 과거 경험을 재료로 삼았지만, 같은 눈으로 보면 도구 설명이나 정책 문서 같은 다른 맥락도 조립의 대상이 될 수 있기 때문입니다. 실행기는 그대로 두고 앞에 차리는 법만 배우는 방식이 다른 재료에서도 통할까요. 그 이야기는 아직 열려 있습니다. 다만 한 가지는 분명해 보입니다. 에이전트의 똑똑함은 머릿속에만 있지 않고, 눈앞에 차려지는 상 위에도 있다는 것이지요. 그래서 저는 이 논문을 점수표가 아니라 상차림에 대한 이야기로 기억하려 합니다. 적게 차리되, 더 잘 차리는 법에 대한 이야기 말이죠.