해결할 문제부터 찾는 해법처럼 보임. 에이전트와 일상적인 작업에서 메모리뿐 아니라 저장 계층 전체가 드러나지 않아야 함. 누구도 저장 기능이 훌륭하다는 이유로 에이전트를 만들거나 팔지는 않으며, 그것으로 무엇을 할 수 있는지가 핵심임.
메모리 자체가 목적은 아니지만 에이전트는 그 위에 구축됨. 사용자가 실제 업무 문제에 집중할 수 있도록 해법을 단순하게 만들면 됨. 살짝 홍보하자면 몇몇 운영 환경에서 https://github.com/Polign/recall을 쓰고 있는데, 가장 자주 듣는 평은 그냥 잘 작동한다는 것임.
이게 그렇게 큰 문제인가? AI의 ‘텍스트 형식’ 문제마다 해법이 15개씩 나오는 듯하지만, 결국 비정형 영어에 구조를 씌우는 정도임. 트랜스포머는 그런 구조를 공통 형태로 환원할 수 있다고 보며, 인터넷 전체로 학습할 수 있었던 것도 그 덕분이라고 생각함.
스킬 사용법을 배우거나 “특정한 중요 정보를 메모리에 저장하라”, “구현 전에 계획하라”처럼 잘 구조화된 지시를 받는 것은 도움이 됨. 하지만 메모리 해법들은 사실상 폴더만 다를 뿐, 어느 것이 더 나은지는 모르겠음. CLAUDE.md에서 AGENTS.md를 참조하고, AGENTS.md에서 .agent/memories/에 기록하라고 해도 기본 CLAUDE.md와 .claude/memories를 쓰는 것과 거의 같은 성능일 듯함. 측정 결과가 있다면 보고 싶음.
AI가 나보다 확실히 잘하는 것 하나는 ‘완벽한’ 해법에 강박적으로 매달리지 않는 것임.
LLM을 블랙박스로 취급하면 주변에 늘 비슷한 것을 만들게 됨. 개에게 의도를 이해시키려는 것과 비슷함. 재주를 가르칠 수 있고 특정 보상 패턴도 알아보지만, 대부분의 개는 기본적인 자극 외에는 무슨 말을 하는지 이해하지 못함.
내 claude.md에는 몇 줄만 들어 있음. 그중 하나가 agents.md를 주 파일로 취급하고, .agents 폴더의 스킬을 갱신하며 그곳을 스킬의 원본으로 쓰라는 지시임. 지금까지는 잘 작동함.
블로그 글 전체에서 LLM이 쓴 티가 남. LLM 작성 텍스트를 충분히 신뢰할 만하게 탐지할 수 있다면, 통째로 걸러내는 브라우저 확장 프로그램을 만들고 싶음.
Pangram을 써봤는가? 말한 용도에는 꽤 신뢰할 만함.
AI 탐지는 학생의 에세이를 평가하고 AI 표절이라고 몰아붙이는 데 쓰면 문제가 되므로 여기서도 비판을 많이 받음. 하지만 웹을 보다가 가끔 확인하는 용도라면 적극 추천함.
나도 그렇게 느꼈고 순위가 높아서 놀랐음. 이제 LLM 문체를 넘어 아이디어 자체를 보기 시작한 걸까? 이 글의 핵심 아이디어는 탄탄함. 까다로운 HN 독자들도 이를 넘어갈 수 있다면 다른 독자층도 대체로 괜찮게 받아들일 듯함.
LLM은 아키텍처를 제대로 설명하지 못함. 겉으로는 일관돼 보이지만 모호하고 엄밀함이 부족함. 개념을 정의하고 이름을 붙이는 대신 “주소와 키는 메모리가 참인 곳” 같은 표현을 반복하는데, 도대체 무슨 뜻인가? 각 개념에 이름을 붙이고 설명해야 함.
사람이 설계한 부분과 LLM이 즉석에서 지어낸 세부 사항을 구분할 수 없으니 가치가 없음. 일회성 웹페이지 생성이라면 몰라도, 모두가 기반으로 삼을 표준 제안이라면 받아들이기 어려움.
현실 세계에서는 스마트 안경과 Pangram의 새 이미지 탐지 기능을 결합해도 좋겠음. 재촬영한 이미지에서도 잘 작동하는 듯하니, 영화 They Live의 안경처럼 쓸 수 있을 것 같음.
기본 취지에는 동의하지만 표준화할 시점은 아직 아님. 맥락과 메모리를 어떻게 다루고 얼마나 오래 유지해야 하는지도 충분히 이해하지 못함. 성급하게 추상화를 표준화했다가 SOAP나 SGML처럼 되는 것은 피해야 함.
SGML보다 나은 것은 무엇인가? XML과 HTML이 그것을 기반으로 했다면 어떤 모습이었을까?
지금의 해법들은 아마도 틀린 가정 위에서 작동하고 있을 가능성이 큼. 변화 속도도 여전히 매우 빠름.
정말 필요한가? LLM의 강점은 자연어 해석이므로, 프로젝트가 어떤 형식을 쓰든 흡수할 수 있음. 미리 정한 형식이 꼭 필요하지는 않음.
사용자 A의 에이전트 메모리와 사용자 B의 메모리를 한데 두고 싶은 것도 아님. 적어도 코딩 에이전트에서는 협업과 공유를 내세울 근거가 약함. 저장소별 맥락은 에이전트 이전에도 그랬듯 docs/나 architecture/ 디렉터리에 기록하면 됨.
배포된 에이전트의 감시에는 필요할 수도 있음. 이를 위해 나도 메모리 관리 도구 slivingdoc.dev를 만들었고, 모든 에이전트의 지속적으로 보관되는 맥락을 내려받을 수 있게 했음. 하지만 이것은 분산 시스템 문제이지 메모리 형식의 문제는 아님.
이런 구조화된 메타데이터는 LLM이 아니라 도구 계층, 주로 에이전트 실행 환경을 위한 것임. 예를 들어 매번 토큰을 쓰지 않고도 여러 형식을 해석할 수 있게 해줌.
통일된 형식이나 명세의 필요성은 에이전트 메모리에서는 훨씬 작음. 애초에 에이전트가 읽는 것이고, 에이전트는 이미 여러 형식의 메모리 파일을 읽도록 지시받거나 프로그래밍되어 있음. 그런 지시가 없더라도 필요한 맥락을 얻으려고 파일을 탐색하는 데 매우 능숙함.
실제로 그래도 괜찮을 가능성이 크지만, 어떤 텍스트 파일을 읽을지 알아내는 데 추론 능력과 컨텍스트 윈도를 낭비하게 하고 싶지는 않음. 사람이 일을 하려는데 참고 자료의 형식이 매번 제각각이라면 몹시 답답할 것임.
정작 에이전트는 메모리를 읽지 않고, 상당 부분 무시함. Anthropic이 최근 자화자찬한 글에도 주입된 메모리는 귀중한 토큰을 소모하고 잘못된 기록이 매 세션에 따라붙을 수 있다고 적혀 있음. 기록을 불러와도 Claude가 따르리라는 보장은 없으며, Claude Code 문서에서도 지시 파일이 길수록 준수율이 떨어진다고 경고함.
또 MEMORY.md의 첫 200줄 또는 25KB만 불러온다고 함. https://www.anthropic.com/research/components-of-agent-memor...에서 확인할 수 있음.
요즘 이 문제를 어떻게 해결하는지 궁금함. 저장소 수준에서는 AGENTS.md와 프로젝트 이력을 정리한 추가 문서로 버틸 수 있지만, 그 밖의 맥락까지 다루려면 Hindsight, Graphiti 등 선택지가 너무 많음. 직접 만들어야 할까? Postgres나 S3로 구동하면서 .md 파일을 기록하고 개체 간 관계도 어느 정도 유지하는 도구를 원함. 하지만 기존 구현은 지나치게 복잡하거나 특이한 데이터베이스를 요구하는 경우가 많아서 아직 단순한 해법이 없어 보임. 어떤 에이전트에도 연결할 수 있는 최소한의 도구를 아는지 궁금함.
내가 찾은 가장 간단한 방법은 AGENTS.md에 지식 기반 디렉터리를 관리하고 참조하라는 지시를 추가하는 것임. 훅 등을 붙여 AWS CLI로 해당 디렉터리를 S3와 동기화할 수도 있음.
에이전트는 실제로 이를 꽤 잘 관리했고 grep으로 검색도 잘했음. 많은 메모리 시스템이 너무 큰 목표를 좇고 있으며, 코딩 용도로는 이미 투입 대비 효과가 좋은 지점을 한참 넘어선 것 같음.
참조 대상의 동일성은 어떻게 할 것인가? 지금 메모리와 회상은 생성 당시 환경에 종속된 로컬 대상을 가리킴. @message100Line10-50, sessionsabc@100-300, ./yourfiles/thisfile.mb처럼 맥락 공간을 최대한 아끼는 참조를 쓰기도 함.
메모리를 옮길 수 있게 만들려면 메모리가 가리키는 대상도 함께 옮길 수 있어야 함.
사람이 코드를 어떻게 기억하는지도 생각해볼 만함. 찾는 코드가 파일 A의 10~50줄에 있다고 기억하기보다는, 파일 이름의 일부로 유사 검색을 하거나 기억나는 함수·변수 이름을 찾음. 그래도 못 찾으면 파일 전체를 빠르게 훑으며 관련 이름을 살펴봄.
정확한 참조를 저장하면 조회는 효율적이겠지만 환경은, 특히 요즘은 너무 자주 변함. 메모리 시스템은 어디서 무엇을 찾을지에 대한 출발점과 코드베이스는 변하며 변해야 한다는 전제를 갖추는 편이 좋겠음. 참조 대상의 이동성과 양립할 수는 있지만, 거기에 들이는 노력이 과연 보람이 있을지는 모르겠음.
openviking을 6개월 넘게 자체 호스팅해서 쓰고 있으며 잘 작동함. 오픈소스이고 자체 호스팅이 가능하며, 원하는 LLM과 임베딩 모델을 연결할 수 있음.
ByteDance 팀이 만들었는데, 중국산이라 미국에서 관심을 받지 못하는 것은 아닌지 종종 궁금해짐.
애초에 메모리를 텍스트 파일에 저장하는 게 맞는가? 사람이 넘쳐나는 메모장을 들고 다니며 사실을 확인하거나 만났던 사람을 떠올릴 때마다 뒤져야 한다면, 지치고 비효율적일 것임.
로컬 모델에 메모리를 직접 넣는 방법이 열리면 좋겠음. 다만 대형 연구소들이 이 방향에서 유용한 것을 만들어줄 것 같지는 않음.