AI 에이전트 메모리를 더 늘려도 똑똑해지지 않는 진짜 이유: 취향과 맥락공학이 성능을 만든다
AI 에이전트 메모리를 더 늘려도 똑똑해지지 않는 진짜 이유: 취향과 맥락공학이 성능을 만든다
결론부터: AI 에이전트 메모리는 늘리는 게 아니라 고르는 겁니다
AI 에이전트를 똑똑하게 만드는 건 더 많이 기억시키는 것(양)이 아닙니다. 무엇을 남기고 무엇을 버릴지 고르는 판단력, 즉 '취향(taste, 무엇이 중요하고 무엇이 소음인지 가려내는 안목)'입니다. 자료를 계속 쌓아 넣을수록 오히려 에이전트의 답은 흐려집니다.
이건 감상이 아니라 Anthropic과 앤드레이 카파시(Andrej Karpathy)가 공식 문서에서 짚은 '맥락공학(context engineering, AI에게 매 순간 알맞은 정보만 골라 주는 기술)'의 핵심입니다. AI 에이전트 메모리를 무한정 키우는 것은 만병통치약이 아니라는 이야기죠.
이 글은 2026년 7월 7일 공개된 한 논지("AI 에이전트에게 필요한 건 더 많은 메모리가 아니라 취향이다")에서 출발하지만, 원문 본문은 접근이 막혀 있어 추측하지 않습니다. 대신 같은 주제를 Anthropic·Karpathy·arXiv 공식 자료로 다시 검증해 풀어드립니다.
AI 에이전트 메모리는 무한 자원이 아닙니다 (Anthropic 공식)
Anthropic이 2025년 9월 29일 공개한 엔지니어링 문서 "Effective context engineering for AI agents"는 맥락(context, AI가 한 번에 참고하는 정보 묶음)을 유한 자원으로 규정합니다. 창을 무작정 키운다고 성능이 좋아지지 않는다는 뜻입니다.
문제는 루프를 도는 에이전트입니다. 매 턴마다 데이터가 계속 쌓이면서 모델의 한정된 '주의 예산(finite attention budget, 한 번에 집중할 수 있는 정보의 총량)'을 압도합니다. 규율 없이 관리하면 더 큰 창은 곧 더 많은 잡음과 품질 저하로 이어집니다.
그래서 Anthropic이 내놓는 처방은 명확합니다. 추론하는 동안 '최적의 토큰 집합을 큐레이션하고 유지하는 것(curating and maintaining the optimal set of tokens)'입니다. 중요한 건 이게 한 번으로 끝나지 않고 매 스텝 반복된다는 점입니다. AI 에이전트 메모리 설계가 '얼마나 담을까'가 아니라 '매 순간 무엇을 남길까'의 문제인 이유입니다.
컨텍스트 로트: 더 넣을수록 정확도가 떨어집니다
토큰 수가 늘어날수록 모델이 정확히 회수(recall, 필요한 정보를 다시 찾아 쓰는 것)하는 능력은 오히려 떨어집니다. 건초 더미에서 바늘 찾기(needle-in-haystack) 계열 관측에서 여러 모델에 걸쳐 재현되는 현상이죠. 흔히 '컨텍스트 로트(context rot, 맥락이 커질수록 품질이 썩듯 나빠지는 현상)'라고 부릅니다.
이걸 학술적으로 형식화한 것이 arXiv에 2025년 10월 14일 올라온 논문 "Memory as Action"입니다. 이 논문은 병목이 '메모리 용량을 늘리는 것'에서 '내용을 능동적으로 큐레이션하는 것(선택·통합·가지치기)'으로 이동한다고 못 박습니다. 긴 맥락의 가운데 정보가 묻혀 버리는 '로스트 인 더 미들(lost-in-the-middle)'도 이 흐름 위에 있습니다.
정리하면 이렇습니다. 메모리를 늘리는 것 자체는 목표가 아닙니다. 무엇을 넣고 무엇을 뺄지 고르는 일이 성능을 만듭니다.
프롬프트 공학에서 맥락공학으로 (Karpathy)
앤드레이 카파시는 2025년 6월 25일 본인 계정을 통해 흐름의 전환을 짚었습니다. '프롬프트 공학(prompt engineering, 좋은 질문 문장을 짓는 기술)'보다 '맥락공학'이라는 것이죠. 그는 맥락 창을 "다음 단계에 딱 필요한 정보로 채우는 섬세한 기술이자 과학"이라고 정의했습니다.
이제 좋은 에이전트의 조건은 '잘 쓴 한 문장 프롬프트'에서 '매 순간 알맞은 맥락 구성'으로 옮겨갔습니다. 업계 용어로도 굳어진 흐름입니다. 결국 AI 에이전트 메모리를 다루는 실력은 곧 맥락을 고르고 다듬는 실력과 같은 말이 됐습니다.
'취향'이란 무엇인가 — 판단을 점수화하는 큐레이션
여기서 말하는 '취향'은 감성적 표현이 아닙니다. 무엇이 중요하고 무엇이 소음인지 판단하는 능력, 사람으로 치면 편집자의 안목입니다. 저울 한쪽에 태그 없는 원시 메모 산더미(양적 축적)를, 다른 쪽에 태그를 붙여 큐레이션한 소수의 고품질 항목을 올려 보면 가치의 무게는 큐레이션 쪽으로 기웁니다.
이 '취향'을 실제로 점수화하는 사례가 GBrain입니다. GBrain은 개리 탄(Garry Tan)이 오픈소스로 공개한 지식그래프 메모리 서버(MCP, 여러 도구와 자료를 AI에 연결해 주는 표준 방식)입니다. 이번 리서치에서 GBrain을 직접 연결해 살펴봤습니다(버전 0.42.40, 페이지 695개, 청크 1,346개 기준).
단순 저장고와 다른 지점은 세 가지 메커니즘입니다.
- takes: 판단을 유형과 가중치로 저장합니다(fact/take/bet/hunch = 사실/견해/베팅/직감).
- calibration profile(보정 프로필): 베팅이 맞았는지 확인하며 브라이어 점수(Brier score, 예측이 얼마나 정확했는지 재는 지표)와 정확도·편향 태그를 계산합니다. 해소된 베팅이 5건 이상 쌓이면 생성됩니다.
- salience(중요도): 최신성·중요도·판단 밀도로 무엇이 주목할 값인지 점수를 매깁니다.
즉 GBrain은 "다 기억"하는 게 아니라 "당신의 판단이 얼마나 좋은지를 점수화하고 보정"합니다. 이것이 곧 '취향 지수(Taste Index)'의 실체입니다. 참고로 원문 제목의 다른 축인 'Hermes'는 이 판단 메모리를 소비하는 에이전트 런타임(자율 실행 프레임워크)으로 보는 편이 아키텍처상 자연스럽습니다. 다만 원문을 확인하지 못했으니 특정 모델로 단정하지는 않겠습니다.
실전 처방 세 가지: 입력 큐레이션·메모리 감쇠·취향 지수
그래서 무엇을 하면 될까요. 콘텐츠와 실무에 바로 녹일 수 있는 처방은 세 가지입니다.
첫째, 넣기 전에 거릅니다(입력 큐레이션). 에이전트에게 자료를 통째로 밀어넣지 말고, 문맥에 들어가기 전에 걸러 냅니다. Anthropic이 말한 '최적의 토큰 집합 큐레이션'과 같은 결입니다.
둘째, 오래된 맥락은 요약하고 폐기합니다(메모리 감쇠). 지난 정보를 계속 끌고 다니면 주의 예산만 좀먹습니다. 오래된 맥락은 압축해 요약본만 남기거나 아예 버리는 규칙을 둡니다.
셋째, 판단의 적중을 기록해 보정합니다(취향 지수). 에이전트가 내린 판단이 맞았는지 사후에 기록하고 점수화하면, 다음 판단이 조금씩 나아집니다. GBrain의 보정 프로필이 하는 일이 바로 이것입니다.
한 가지 균형은 잡아 두겠습니다. "취향이 유일한 해자(moat, 경쟁자가 넘기 어려운 진입장벽)"라는 말은 2025~2026년 업계에서 도는 담론이지 검증된 법칙은 아닙니다. 모델이 흔해질수록 가치가 생성에서 큐레이션·편집·거절로 옮겨간다는 관점은 설득력이 있지만, 단정하기보다 하나의 유력한 방향으로 읽는 편이 정확합니다.
자주 묻는 질문 (FAQ)
Q. AI 에이전트 메모리를 크게 키우면 성능이 좋아지나요?
꼭 그렇지는 않습니다. 맥락은 유한 자원이고 토큰이 늘수록 정확히 회수하는 능력이 떨어지는 '컨텍스트 로트'가 나타납니다. 창을 키우는 것보다 무엇을 남기고 버릴지 큐레이션하는 편이 성능을 만듭니다.
Q. 맥락공학(context engineering)이 정확히 무슨 뜻인가요?
맥락공학은 AI에게 다음 단계에 딱 필요한 정보만 골라 채워 주는 기술입니다. 카파시가 '프롬프트 공학'의 다음 단계로 제시한 개념으로, 좋은 한 문장을 짓는 것을 넘어 매 순간 알맞은 맥락을 구성하는 일을 말합니다.
Q. '취향 지수(Taste Index)'는 어떻게 만드나요?
판단을 유형과 가중치로 저장하고, 그 판단이 맞았는지 사후에 확인해 점수화·보정하는 방식으로 만듭니다. GBrain은 takes(판단 저장)·calibration profile(보정)·salience(중요도)로 이 과정을 구현합니다.
Q. 당장 적용할 수 있는 방법은 무엇인가요?
세 가지입니다. 입력을 넣기 전에 거르고(입력 큐레이션), 오래된 맥락은 요약·폐기하고(메모리 감쇠), 판단의 적중을 기록해 보정합니다(취향 지수). 각각 Anthropic의 큐레이션, 메모리 감쇠 정책, GBrain의 보정에 대응합니다.
참고자료
- Anthropic, "Effective context engineering for AI agents" (2025-09-29): https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
- Andrej Karpathy, context engineering 관련 게시 (2025-06-25): https://x.com/karpathy/status/1937902205765607626
- arXiv, "Memory as Action" (2025-10-14): https://arxiv.org/abs/2510.12635
- Awesome LLM Apps (오픈소스 저장소): https://github.com/Shubhamsaboo/awesome-llm-apps
- GBrain 생태계 (지식그래프 메모리 MCP): https://github.com/topics/gbrain
- 발상의 출처가 된 X Article "Build a Taste Index with Hermes and GBrain" (2026-07-07, 본문 미확인): https://x.com/saboo_shubham_/status/2074526361159626959
면책: AI 보조 리서치입니다. 발상의 출처가 된 원문 본문은 접근이 막혀 확인하지 못했으며, 저자의 구체 주장을 인용·재현하지 않았습니다. 본문은 주변 사실을 공식 소스로 검증해 재구성한 것입니다.