매번 통째로 읽는 AGENTS.md, 무엇을 남기고 무엇을 뺄까

오늘 다룰 글은 Curating Always-Loaded Context for LLM Agents: A Capacitated Assortment Model with Censored Feedback라는 제목으로 arXiv에 공개된 연구로, 식별 번호 2610.11007로 올라와 있습니다. 이 연구가 내세우는 주장은 한 문장으로 정리할 수 있는데, 매번 통째로 불러오는 에이전트용 컨텍스트 파일은 용량 제한 안에서 골라 담는 문제로 다루어야 하며, 빠진 규칙에서는 해가 생길 때만 신호가 돌아오는 가려진 피드백까지 함께 생각해야 한다는 것입니다. 원문 링크는 이 글 제목 아래에 붙어 있습니다.

매일 아침 다시 읽는 그 파일이 이상했습니다

저는 이 논문을 읽기 전부터 AGENTS.md 같은 파일이 조금 이상하다고 느끼고 있었습니다. 세션이 시작될 때마다 에이전트는 그 파일을 처음부터 끝까지 다시 읽고, 그 다음 라운드에서도 매번 같은 토큰에 대해 다시 비용을 치르니까요. 사람이 매일 아침 출근해서 같은 운영 수칙을 처음부터 낭독하는 것과 비슷한데, 솔직히 말하면 낭독할 때마다 월급이 나가는 셈이죠. 그런데도 우리는 그 파일이 커지는 것을 별로 이상하게 여기지 않았습니다. 좋은 규칙이 생기면 그냥 한 줄 더 넣으면 된다고 믿었기 때문입니다.

그렇다면 파일이 두 배가 되면 에이전트는 두 배로 말을 잘 들을까요. 제 경험으로는 그렇지 않은 경우가 많았는데요. 어떤 날은 규칙을 세 개 지웠는데 오히려 빌드가 더 잘 돌았고, 어떤 날은 정성 들여 쓴 주의사항이 완전히 무시됐습니다. 이 논문이 눈에 들어온 이유도 바로 여기에 있습니다. 왜 더 넣었는데 더 못해지는지, 왜 뺐는데 나아지는지를 그냥 감이 아니라 고르는 문제로 설명해보겠다고 말하기 때문입니다. 그래서 오늘은 이 낯선 수식보다 그 뒤에 있는 운영 감각을 따라가 보려고 합니다.

왜 장바구니에 담는 문제로 보았을까요

이 연구는 컨텍스트 큐레이션을 용량 제한이 있는 구색 고르기 문제로 둡니다. 영어로 하면 capacitated assortment인데요, 처음 들으면 유통 용어 같아서 어색하게 느껴질 수 있습니다. 하지만 비유를 조금만 풀면 금방 감이 옵니다. 진열대가 좁은 편의점에서 어떤 상품을 내놓을지 고르는 일과 비슷하기 때문입니다. 공간이 한정돼 있으니 잘 팔릴 것 같은 것만 골라야 하고, 하나를 넣으면 다른 하나를 빼야 하니까요.

여기서 상품은 후보 지시문이고, 진열대는 세션 시작 때마다 항상 불러오는 파일이며, 가격은 토큰이고, 진열대 폭은 주의력 용량입니다. 다시 말하면 지시문마다 토큰을 차지하고, 에이전트가 한 번에 소화할 수 있는 주의력에도 한계가 있다고 보는 것입니다. 저는 이 비유가 마음에 들었는데요, 그간 우리가 AGENTS.md를 문서처럼 다루었기 때문입니다. 문서는 쌓을수록 풍부해지지만, 진열대는 쌓을수록 숨이 막힙니다. 그래서 관점을 문서에서 진열대로 바꾸는 것만으로도 질문이 달라집니다. 무엇을 더 쓸까가 아니라 무엇을 빼고 무엇을 남길까를 묻게 되니까요.

물론 비유가 전부는 아닙니다. 편의점 상품은 서로 독립적일 때가 많지만, 지시문은 서로의 효과를 갉아먹습니다. 그래서 다음 이야기로 넘어가야 합니다. 담은 것들끼리 서로 방해한다면, 고르는 계산은 어떻게 달라질까요.

하나를 더 넣으면 나머지가 흐려지는 이유

이 논문에서 제가 가장 흥미롭게 본 부분은 아주 짧은 성질 하나인데, 지시문을 하나 추가해도 다른 지시문들의 수행도는 절대 올라가지 않는다는 것입니다. 영어 표현을 빌리면 adding an instruction never raises the compliance of the others 정도 됩니다. 직관적으로는 당연해 보이지만, 막상 파일에 적용하면 꽤 차갑게 느껴집니다. 내가 아끼는 규칙 한 줄이 다른 아끼는 규칙들의 힘을 조금씩 깎는다는 뜻이니까요.

생각해보면 사람도 비슷하게 행동합니다. 아침 조례에서 전달 사항이 세 개일 때는 다 기억하다가도, 열 개가 넘어가면 앞에서 말한 것도 까먹죠. 에이전트도 같은 식으로 주의가 흩어지고, 어떤 지시를 따를지 고르는 과정에서 서로 대체하거나 방해하는 효과가 생깁니다. 연구가 말하는 대체와 산만 효과가 바로 이것인데요, 규칙끼리 잘 어울리면 함께 빛나는 것이 아니라 규칙끼리 자리를 놓고 다투는 것에 가깝습니다.

여기서 재미있는 질문이 생기는데, 그렇다면 좋은 규칙만 골라 넣으면 되지 않을까요. 얼핏 답처럼 보이지만, 문제는 그다음입니다. 좋은 것들을 모아놓은 파일이 꼭 좋은 파일은 아니기 때문입니다. 왜 그런지는 다음 대목에서 숫자의 감각으로 풀어보겠습니다.

좋은 것만 모아도 왜 나빠질 수 있을까요

저희가 새로운 운영 문서를 볼 때도 흔히 하는 실수가 있습니다. 각 항목이 따로 보면 좋아 보이면 그냥 다 넣는 것이죠. 이 항목도 맞고 저 항목도 맞으니, 다 넣으면 더 맞을 거라고 믿는 것이죠. 그런데 이 논문은 그 믿음에 제동을 겁니다. 따로 보면 이득이 있는 지시문이라도 전부 이어 붙이면, 잘 고른 부분집합보다 얼마든지 나빠질 수 있다는 것인데요. 영어로는 arbitrarily worse라는 강한 표현이 붙습니다. 조금 나빠진다는 말이 아니라, 조건에 따라서는 걷잡을 수 없이 나빠질 수 있다는 뜻입니다.

이 차이는 생각보다 중요합니다. 각 규칙의 점수를 따로 매겨서 합격점만 모으는 방식이 통하지 않기 때문입니다. 맛있는 반찬을 열 가지 늘어놓으면 상이 풍성해지는 것이 아니라, 젓가락이 어디로 가야 할지 모르게 되는 것과 비슷합니다. 각 반찬은 맛있지만, 합쳐진 식사의 만족도는 떨어질 수 있죠. 에이전트 파일도 같은 일을 겪습니다. 토큰 비용은 쌓이고, 주의는 흩어지고, 서로 다른 지시가 같은 상황에서 조금씩 다른 행동을 요구하면서 에이전트는 머뭇거리게 됩니다.

그래서 저는 이 대목을 읽으면서 기존의 운영 습관을 돌아보게 됐습니다. 우리는 규칙을 추가할 때 그 규칙 자체의 옳고 그름만 따졌지, 이미 들어 있는 규칙들과 부딪히면 어떻게 되는지는 잘 묻지 않았죠. 반면 이 연구는 처음부터 합친 묶음의 순가치를 묻습니다. 하나하나의 점수가 아니라 함께 있을 때의 점수를 보는 것이죠. 그렇다면 묶음을 아무리 크게 만들어도 괜찮을까요. 그 답은 의외로 크기에 한계가 있다는 쪽에 가깝습니다.

후보가 산더미여도 답의 크기는 정해져 있습니다

이 연구에서 두 번째로 눈이 간 결과는 고른 파일의 크기에 상한이 있다는 점입니다. 후보 지시문이 수백 개든 수천 개든, 잘 고른 파일의 크기는 그 수와 상관없이 일정한 선을 넘지 않는다는 것인데요. 처음에는 믿기 어려울 수 있습니다. 고를 게 많으면 답도 커져야 하는 것 아닌가 싶으니까요. 하지만 진열대 비유로 돌아가면 이해가 쉬워집니다. 손님이 한 번에 볼 수 있는 양이 정해져 있으면, 창고에 재고가 아무리 많아도 진열대 자체를 무한히 늘리지는 않기 때문입니다.

이유는 앞서 본 두 가지 힘 때문입니다. 토큰을 쓰면 매 라운드 비용이 나가고, 규칙을 더하면 기존 규칙의 수행도가 깎입니다. 그래서 어느 지점을 넘어서면 새로 넣는 규칙이 벌어주는 이득보다 기존 규칙들을 갉아먹는 손해와 토큰값이 더 커집니다. 그 지점이 바로 상한이 가리키는 곳인데요, 후보가 많아진다고 그 지점이 뒤로 밀리지는 않습니다. 후보가 많아지면 고를 선택지는 늘어나지만, 담을 수 있는 양 자체가 늘어나는 것은 아니기 때문입니다.

실제 시스템 관점에서 보면 다음 질문이 바로 생기는데, 그 상한이 정확히 몇 토큰인지는 환경마다 다르겠지만 방향 자체는 분명합니다. 파일을 키우는 쪽이 아니라 고르는 쪽에 시간을 써야 한다는 것이죠. 저는 이 결과를 일종의 운영 면허처럼 읽었습니다. 파일이 커질수록 언젠가는 손해라는 것을 증명해 보이니, 이제는 무엇이든 넣자는 요청을 받을 때 조금 더 단호해질 수 있으니까요. 그런데 여기서 또 다른 현실적인 걱정이 남습니다. 토큰값을 우리가 잘못 매기면 어떻게 될까요.

토큰값을 잘못 매겨도 버티게 만드는 장치

에이전트를 운영하다 보면 토큰값을 정확히 매기기 어렵다는 것을 금방 알게 됩니다. 토큰 하나가 얼마짜리인지는 모델 요금만이 아니라 지연과 재시도, 사람이 고치는 시간까지 얽혀 있기 때문입니다. 그래서 이론적으로는 맞는 선택도 막상 돌려보면 비싸게 느껴질 때가 있죠. 이 논문은 이럴 때를 대비해 토큰 예산이라는 안전장치를 둡니다. 쓸 수 있는 토큰의 총량을 미리 묶어두면, 토큰값을 낮게 잡았을 때 생기는 손실을 일정한 선 안에서 묶을 수 있다는 것입니다.

이 장치는 자동차의 속도 제한과 비슷합니다. 연료값이 오를지 내릴지 몰라도, 속도를 묶어두면 최악의 연비는 어느 정도 가늠할 수 있죠. 토큰 예산도 같은 역할을 합니다. 토큰값 추정이 빗나가서 평소보다 규칙을 많이 담고 싶어져도, 예산이 천장 역할을 하면서 무한정 커지는 것을 막아줍니다. 그래서 추정이 틀렸을 때의 후회가 예산이 없을 때보다 훨씬 작아집니다.

여기서는 조금 조심해서 읽을 필요가 있는데, 예산이 만능이라는 말이 아니기 때문입니다. 예산을 너무 빡빡하게 잡으면 정작 필요한 규칙까지 못 담을 수 있고, 너무 넓게 잡으면 안전장치로서 의미가 옅어집니다. 저는 이 대목을 읽으면서 예산을 일종의 자신감 표시로 이해했습니다. 토큰값에 자신이 없으면 예산을 조이고, 측정이 쌓여서 감이 생기면 조금씩 넓히는 것이죠. 그렇다면 이제 시선을 돈에서 신호로 옮겨보겠습니다. 담은 규칙과 빼놓은 규칙은 우리에게 같은 방식으로 말을 걸까요.

빠진 규칙은 아플 때만 말을 겁니다

이 논문의 또 다른 축은 가려진 피드백입니다. 영어로 censored feedback이라고 부르는데요, 말이 어려워서 그렇지 뜻은 단순합니다. 파일에 넣어둔 규칙은 이득도 보고 해로움도 보지만, 넣어두지 않은 규칙은 빠졌기 때문에 해가 생겼을 때만 눈에 띈다는 것입니다. 들어 있는 규칙은 매일 시험대에 오르지만, 빠진 규칙은 사고가 나야 존재감을 드러내죠.

일종의 출석부와 비슷합니다. 매일 나오는 학생은 잘하는 날도 못하는 날도 기록이 남지만, 나오지 않은 학생은 시험을 망친 뒤에야 왜 안 불렀는지 이야기가 나오니까요. 그래서 운영자는 자연스럽게 들어 있는 규칙 위주로 배우게 됩니다. 이 규칙을 두면 무엇이 좋아지고 무엇이 나빠지는지는 데이터가 쌓이지만, 빼놓은 규칙이 있었다면 어땠을지는 좀처럼 알 수 없습니다. 눈에 보이는 것만 고치다 보면, 눈에 안 보이는 쪽의 손해는 계속 쌓이죠.

그렇다면 우리는 어떻게 배워야 할까요. 연구가 던지는 질문은 바로 이것인데요, 빠진 규칙의 가치를 알려면 일부러 넣어보거나 흉내를 내볼 수밖에 없다는 쪽으로 이어집니다. 물론 매번 실험할 수는 없으니, 언제 시험하고 언제 그냥 둘지를 정하는 일이 남습니다. 이 대목은 다음 이야기와 바로 맞닿아 있습니다. 피드백이 이렇게 가려져 있는데, 에이전트가 안 지킨다는 이유만으로 규칙을 지워도 될까요.

안 지킨다고 지우면 진짜 필요한 것도 함께 나갑니다

현장에서 자주 듣는 말이 있는데, 에이전트가 그 규칙을 안 지키니 지우자는 것이죠. 얼핏 합리적으로 들리지만, 안 지키는 규칙에 토큰을 쓸 이유가 없으니까요. 하지만 이 논문은 그 직관에 브레이크를 겁니다. 무시된 것처럼 보이는 규칙을 지우는 일은 도움이 되는 규칙을 함께 지울 위험을 피할 수 없다는 것인데요. 무시된다는 관찰 자체가 불완전한 신호이기 때문입니다.

이유를 풀어보면 이렇습니다. 에이전트가 규칙을 안 지킨 것처럼 보여도, 실제로는 그 규칙이 없어졌을 때 비로소 해가 드러나는 경우가 있습니다. 평소에는 조용히 받쳐주다가, 빠지고 나서야 빈자리가 느껴지는 기둥과 비슷하죠. 그런데 가려진 피드백 때문에 우리는 그 받쳐주는 효과를 평소에 잘 못 봅니다. 눈에 보이는 것은 안 지키는 장면뿐이니, 도움이 되는 기둥을 장식용으로 오해하고 뽑아버리기 쉽습니다.

저는 여기서 멈칫했는데, 저도 운영하면서 안 지켜지는 규칙부터 정리한 적이 있기 때문입니다. 그런데 그 정리가 사실은 실험이 아니라 추측이었다는 점을 이 연구는 짚습니다. 무시된다는 것은 그 규칙이 쓸모없다는 증거가 아니라, 다른 규칙들에 묻혀 있거나 지금 조건에서만 조용하다는 뜻일 수도 있으니까요. 그렇다면 지우기 전에 무엇을 확인해야 할까요. 연구가 가리키는 방향은 의외로 단순합니다. 지우기 전에 빼봤을 때의 손해를 조금이라도 관찰하라는 것입니다. 그리고 이 관찰 이야기는 실제 파일 실험으로 이어집니다.

쓸데없는 한 줄이 전체를 흔든다는 실험

이 연구가 책상 위의 이야기로 끝나지 않는 이유는 실제 파일에서 가져온 무관한 규칙을 넣어봤기 때문입니다. 그 결과는 꽤 직설적입니다. 관련 없는 규칙이 섞이자 다른 규칙들의 수행도가 떨어졌는데요, 앞서 말한 대체와 산만 효과가 실험에서도 그대로 나타난 셈입니다. 쓸데없는 한 줄이 그냥 토큰만 먹는 것이 아니라, 필요한 줄들의 힘까지 함께 깎는 것이죠.

주방 비유로 바꾸면 더 잘 와닿습니다. 국에 설탕을 한 숟갈 넣으면 단맛만 더해지는 것이 아니라 간 전체가 흔들리죠. 빼면 그만이라고 생각하지만, 이미 들어간 뒤에는 어느 재료가 문제인지 찾기도 어렵습니다. 실제 AGENTS.md도 비슷해서, 여기저기서 주워 담은 규칙이 쌓이면 나중에 어느 줄이 발목을 잡는지 알기 어렵습니다. 특히 파일이 커질수록 원인을 특정하기 어려워지니, 처음에 담는 단계에서 더 깐깐해져야 합니다.

개인적으로 인상 깊었던 점은, 무관해 보이는 규칙도 그냥 중립이 아니라는 것입니다. 중립이라면 토큰값만 물면 되는데, 실제로는 주의력을 나눠 가지면서 전체 수행도를 끌어내립니다. 그래서 저는 이제 파일을 볼 때 각 줄의 옳고 그름보다 먼저 묻게 됩니다. 이 줄이 지금 팀의 일과 정말 관계가 있는가, 다른 줄과 같은 상황에서 다른 말을 하지는 않는가 하고요. 그렇다면 마지막으로 남는 질문은 하나입니다. 내 파일에는 무엇을 남겨야 할까요.

그래서 내 AGENTS.md에는 무엇을 남길까요

앞에서 미뤄뒀던 질문으로 돌아올 차례인데, 항상 불러오는 파일에는 무엇을 남겨야 할까요. 연구가 주는 답을 운영 언어로 바꾸면 세 가지 정도로 정리되는데요, 먼저 묶음의 순가치를 보고 고르라는 것입니다. 각 규칙의 단독 점수가 아니라 함께 있을 때의 점수를 보고, 토큰값과 주의력 희석까지 함께 계산하라는 것입니다. 다음으로는 크기에 욕심을 내지 말라는 것입니다. 후보가 아무리 많아도 답의 크기는 묶여 있으니, 짧고 단단한 파일을 목표로 삼는 편이 낫습니다. 마지막으로는 지우기를 실험처럼 대하라는 것입니다. 안 지킨다는 이유만으로 지우지 말고, 빼봤을 때의 손해를 짧게라도 관찰하라는 것입니다.

저희가 새로운 운영 문서를 볼 때도 이제는 같은 잣대를 씁니다. 숫자가 아니라 그 뒤의 묶음 효과를 먼저 묻고, 토큰 예산을 따로 두어 추정 실수에 대비하며, 빠진 규칙의 손해는 일부러라도 눈에 보이게 만들려고 합니다. 물론 이 연구가 모든 답을 주지는 않습니다. 상한의 정확한 값은 환경마다 다르고, 규칙끼리의 상호작용을 매번 재는 일도 여전히 손이 많이 가니까요. 그럼에도 방향은 분명해 보입니다. 문서를 쌓는 일이 아니라 진열대를 고르는 일로 봐야 한다는 것입니다.

제가 앞으로 보고 싶은 것은 이 고르기를 실제 운영 루프에 넣는 방법입니다. 어떤 주기로 묶음을 다시 고를지, 빼본 규칙의 손해를 어떻게 싸게 관찰할지, 토큰 예산을 팀의 속도에 맞춰 어떻게 움직일지가 궁금합니다. 당장 내일 아침 세션이 열리면 에이전트는 다시 그 파일을 통째로 읽을 것입니다. 그때 읽히는 매 줄이 자기가 왜 거기 있어야 하는지 설명할 수 있다면, 그 파일은 이미 반쯤 고른 셈이라고 봅니다. 여러분의 AGENTS.md는 지금 그 질문에 답할 수 있나요.