요약
AI 에이전트에게는 지난 대화를 찾아 주는 기억 장치보다 직접 읽고 고치는 문서가 필요합니다.
개발자 케빈 랴오가 블로그에 쓴 글입니다. 그는 세션이 바뀌어도 이어지는 에이전트 기억을 오래 고민했고, 실험 끝에 문서 중심 방식으로 정리했다고 밝혔습니다.
왜 중요한가
- 여러 에이전트 기억 플러그인이 겉모습만 다를 뿐 모두 RAG(질문과 비슷한 글 조각을 찾아 붙이는 방식)라고 짚었습니다.
- 기억을 사람이 열어 보고 고칠 수 있는 문서로 두면, 에이전트가 무엇을 근거로 일하는지 점검할 수 있습니다.
핵심 내용
- 기억 플러그인은 대화를 조각내 벡터 DB(문장을 숫자로 바꿔 저장하는 데이터베이스)에 넣고, 비슷한 조각 몇 개를 꺼냅니다.
- 저자는 유사도만 보는 선택, 잘려 나간 맥락, 낡은 정보를 사실로 믿는 태도를 약점으로 꼽았습니다.
- 에이전트는 자기가 모르는 것을 검색할 수 없고, 수천 개의 임베딩은 사람이 감사할 수 없다고 지적했습니다.
- 대안은 작업 전에 관련 문서를 읽고, 작업 뒤에 문서를 고치는 순환입니다.
- 저자는 지침·명세·조사·색인을 마크다운으로만 관리하는 오픈소스 플러그인 Operator Memory를 공개했습니다.
HN 반응
- 문서에 적은 규칙도 에이전트가 자주 무시하므로, 훅이나 정적 검사로 강제해야 한다는 의견이 많았습니다.
- 고치는 방법을 오류 메시지에 담은 린트 규칙 같은 결정론적 피드백(늘 같은 결과를 내는 자동 검사)이 더 필요하다는 경험담도 나왔습니다.
문서화도, 서드파티 메모리 시스템도 필요 없습니다. 코드가 곧 문서예요.
이런 건 전부 LLM용 루브 골드버그 장치일 뿐이고, 컨텍스트만 오염시킵니다.
저는 요즘 AGENTS.md/CLAUDE.md를 거의 안 씁니다. 남겨 둔 것도 아주 기본적인 상위 수준 내용뿐이고요.
솔직히 이와 비슷한 짓을 했던 여러 프로젝트를 생각하면 아직도 땅을 치고 후회합니다. 마크다운 문서와 의사결정 문서를 잔뜩 쌓아 뒀는데, 이제는 그것들이 낡아서 문제만 일으켜요. 문서를 정리하는 세션을 몇 번 돌려도 LLM은 여전히 헷갈려 합니다.
하하, 문서 쓰기 싫어하는 개발자들은 LLM이 문서 없이도 의도를 알아채는 걸 보면서 원래 갖고 있던 믿음이 더 굳어지겠죠. 예를 들어 LLM은 압축하거나 난독화한 코드를 읽는 데도 소름 돋을 만큼 뛰어나니까요.
그런데 이 글의 주장은 컨텍스트가 작을수록, 즉 가능한 한 적은 컨텍스트로 작업 전체를 파악할 수 있을 때 LLM이 더 잘한다는 겁니다. 그래서 정확한 API 수준의 문서가 큰 도움이 된다는 거고요. 제 경험담으로도 맞는 말 같습니다. 주변 컨텍스트가 좋고 명확하면 프롬프트를 대충 부실하게 써도 LLM이 제 의도에 맞는 코드를 써 주거든요.
기뻐하세요! 문서는 LLM이 대신 써 주니까 일 대부분을 덜 수 있습니다.
다만 가만히 두면 LLM은 지나치게 많이 하고, 터무니없이 장황한 문서를 남깁니다. 최소한의 점진적 변경 단위로 움직이라고 지시하기 전까지는 코드를 끝없이 리팩터링하는 것과 비슷하죠. 그러니 LLM이 만든 문서는 여전히 사람이 덜어내는 편집을 해야 합니다.
맞아요. 제 생각과 경험으로는 지금 가장 좋은 방식은 LLM에게 스킬, 지침, 문서를 최소한으로, 아니면 아예 주지 않고 시작하는 겁니다.
LLM이 어려워하는 부분, 그리고 여러 세션에 걸쳐 계속 마주치고 매번 다시 푸는 작은 문제들(제 경험상 대부분 환경 문제입니다)을 지켜보세요. 그게 지침에 담아야 할 내용입니다. 가능하면 그 지침을 스킬로 옮겨서 세션마다 매번 올라가지 않고 필요할 때만 컨텍스트에 로드되게 하세요. (예: 스펙 실행 방법에 관한 지침을 스킬에 넣어 두면 스펙을 돌릴 때만 컨텍스트에 올라갑니다.)
이것도 LLM이 스스로 자동화할 수 있습니다. Codex와 Claude(다른 주요 하네스도 그럴 거라고 생각합니다) 모두 자기 대화 기록을 읽을 줄 알고, 반복되는 마찰을 찾아서 앞으로 그 마찰을 줄일 구체적인 제안을 내놓는 데도 능숙합니다.
사용자가 시간을 어느 정도 들여야 하고, 가끔은 전부 버리고 처음부터 다시 시작하는 게 좋습니다. 그래야 새 지침이 저장소의 현재 상태와 지금 쓰는 모델의 능력에 맞게 갖춰지니까요.
100% 동의합니다. 사람의 개발을 낫게 하는 것 대부분은 에이전트의 개발도 낫게 해 줍니다. 저는 에이전트에서는 문서가 훨씬 더 중요하다고 생각해요. 일종의 곱셈 효과 같은 게 있어서요. 에이전트는 코딩 속도가 빠르니, 문서의 이점도 그 속도 덕에 더 두드러집니다.
이걸 이해 못 하는 사람이 많다니 정말 놀랍네요. 저는 LLM에게 알려 주려고 문서와 지도를 만들고, 문서는 항상 최신 상태로 유지합니다.
일반적으로 LLM이 똑똑해질수록 "적을수록 좋다"는 말은 점점 더 맞아 떨어집니다. 수십, 수백 개의 지침으로 컨텍스트를 오염시키면 LLM은 그걸 전부 만족시키려고 애쓰니까요. 하지만
...아니요, 절대 아닙니다. Claude와 Codex의 기본 상세 수준에서는 놓치기 쉽지만, 실제 세션 대화 기록을 읽어 보면 LLM이 똑같은 사소한 문제를 몇 번이고 거듭 푸는 모습을 거의 틀림없이 보게 됩니다.
우선, 코드만으로는 알 수 없는 게 많습니다.
사소한 예를 들어 볼게요. LLM은 우리 앱의 QA에서 쩔쩔맸습니다. 시드로 넣어 둔 테스트 계정을 어떻게 찾는지 몰랐거든요. 새 계정을 만들면서 엉뚱하게 만들거나, 시드 계정을 찾아도 비밀번호가 암호화돼 있어서 알 수 없으니 비밀번호를 바꿔 놓고는 다른 에이전트들에게 알리지 않았습니다. 토큰이 엄청나게 나갔죠. 그래서 QA를 할 때 로드되는 스킬에 자격 증명을 넣어 줬는데, 그건 고민할 필요도 없는 일이었어요.
그건 코드 문제가 아니라 환경 문제라고 말할 수도 있겠죠. 하지만 실제 코드에 관해서도, 제 경험상 최소한 저장소 구조와 아키텍처 패턴 정도는 에이전트에게 알려 줘야 합니다.
"너는 세계 최고의 Python 프로그래머다, 좋은 코드를 써라" 같은 프롬프트의 시대는 끝났고(애초에 그런 방식이 통하기는 했는지 모르겠지만), 말씀드렸듯 적을수록 좋습니다. 그래도요...
사람이 코드를 쓰던 시절에는 저도 이 조언이 좋았습니다. 그때도 커밋 메시지에는 "왜" 그렇게 했는지를 의미 있게 적으라고 권했지만요. 그래야 아무도 실수로 그 의도를 짓밟지 않으니까요.
하지만 코드 대부분을 LLM이 생성하는 시대에도 통할지는 모르겠습니다. 특히 그 코드를 사람이 검토조차 하지 않고(무책임하든 아니든 실제로 벌어지는 일입니다) 커밋 메시지마저 AI가 생성한다면요. "사람 운영자가 무엇을 의도했는가"와 에이전트가 실제로 만들어 낸 것을 구분해 줄 무언가는 필요하다고 봅니다.
지나치게 설계를 복잡하게 하는 경우가 많다는 데는 동의합니다. 다만 제 방식은 말씀하신 "그만둔 것"과 거의 같습니다. 사용자가 원한 것과 실증적 발견을 기록한 타임스탬프 붙은 "계획/구현 문서"와 "조사 문서"를 전부 커밋하고, 이전 세션 대화 기록은 전부 검색할 수 있게 해 둡니다. 대체로 도움이 되는 것 같아요. 어째서인지 아직까지는 낡은 문서 문제를 별로 겪지 않았습니다.
선언형 코드나 DSL이라면 코드가 곧 문서라는 말이 더 잘 통합니다. 그런 코드는 의도와 약속(프로미스 이론에서 말하는 그 약속)을 더 잘 담아내니까요.
그렇지 않은 코드는 추론으로 읽어 내야 하므로 문서로는 잘 기능하지 못합니다.
코드와 테스트만으로는 잘 담기지 않는 것들이 더 있습니다.
다른 당사자에게 한 약속(프로미스 이론에서 말하는 그 약속). Claude는 이미 학습 데이터에 프로미스 이론이 들어 있습니다.
로이 필딩이나 크리스토퍼 알렉산더가 말하는 제약을 유발하는 속성. 테스트와 속성 기반 테스트가 속성은 담아낼 수 있지만, 그 속성을 유발하는 제약과는 형식적인 연결이 없습니다. 여기서 제약은 비즈니스 요구사항이나 비즈니스 가치가 아닙니다. 그런 것은 프로미스 이론으로 이해하는 편이 낫습니다. 제가 말하는 건 최소 한 번 전달(at-least-once delivery)이나 전체 순서(append-only 제약에서 나오는 것)와 같은 것들입니다. Claude는 이미 필딩의 박사 논문과 알렉산더의 저작과 사상을 학습 데이터로 갖고 있습니다.
알렉산더/필딩 식의 패턴 언어(단순한 패턴이 아니라) 같은 문법도 코드만으로는 담기지 않습니다. 이런 문법은 사람과 AI 모두에게 패턴을 어떻게 확장할지, 그리고 (제약을 유발하는 속성을 위반할 때) 안티패턴을 어떻게 알아볼지를 알려 줍니다.
LLM은 서로 다른 여러 세계관과 경계 있는 컨텍스트(bounded context)를 동시에 학습했고, 그 사이를 오가며 번역하는 데도 아주 능숙합니다. 다만 그런 것들을 명시해 줘야 합니다. 그러지 않으면 LLM이 스스로 추론한 방식대로 말해 버립니다.
컴포넌트를 정확히 어떻게 엮을지까지 적은 명세는 낡은 문서 문제에 부딪힙니다. 패턴 언어와 프로미스 이론으로 설명하려면 사람의 주의력과 토큰이 훨씬 많이 들지만, 시간이 갈수록 쉬워집니다. 그 모든 것을 적어도 고려해 두면 실제 구현 계획이 훨씬 깔끔하게 따라 나오는 경향이 있고요. 저는 요즘 시간 대부분을 여기에 쓰고 있습니다.
이런 산출물을 남기려는 충동이라니, 이상하지 않나요? 최악은 LLM이 코드 주석에서 그 결정과 설계를 언급할 때입니다. 제 생각에 문서로 남길 가치가 있는 건 하나뿐입니다. 보통이라면 했을 방식과 어딘가 직관에 어긋나는, 까다로운 아키텍처나 구현 세부 사항이요. 그런데 그것도 코드와 테스트에 담을 수 있습니다.
코드가 보통 담는 건 "무엇을"과 "어떻게"이고, "왜"는 아닙니다.
왜 그게 존재하는지, 외부 세계와 어떻게 이어지는지는 주석에 적을 수도 있겠지만, 적혀 있지 않은 경우가 더 많죠.
그리고 에이전트는 언제 적어야 하는지 추론하는 데 꽤 서툴러서, 장황한 주석으로 어지럽히는 쪽으로 빠지는 경우가 많습니다.
이해가 안 되네요. 코드에는 결정이 내려진 맥락이 담기지 않잖아요. 코드가 왜 이렇게 생겼는지, 무엇이 중요하고 무엇이 아닌지 말이에요. 코드에서 추론할 수 없는 맥락을 모르는데 에이전트가 어떻게 올바른 결정을 내릴 수 있죠?
소프트웨어 엔지니어들은 자기가 경험해 보거나 알지 못하는, 다른 사람들이 겪는 온갖 문제의 방대한 영역은 고려하지 않고 뭉뚱그려 단정하는 일이 흔합니다. 어쨌든 저는 여러분에게 뭐가 필요하고 뭐가 필요 없는지 말할 생각은 없고, 저한테 효과가 있었던 것과 없었던 것만 말씀드리겠습니다.
제 코드베이스에서는 주석과 문서에 합의를 보기가 어려워서, 그것에 기대는 대신 방식을 바꿨습니다. 에이전트 개발에 항복하면서 제일 먼저 한 일 중 하나가, codex에게 코드를 보여 주고 공개 API 같은 중요한 파일이 어디에 있는지, 계층 구조는 어떤지, 코드가 무엇을 하는지 등을 상위 수준으로 설명하는 문서를 만들게 한 겁니다. 구현 세부 사항을 피하면 이 수준의 문서는 제 경우 꽤 정적으로 유지됩니다. 그래서 지금은 트리에 에이전트 파일이 몇 개 있는데, 토큰이 꽤 절약되고 결과도 좋아지는 것 같습니다. 다른 개발자들이 제 변경 사항을 에이전트로 리뷰하는데 어떻게 그렇게 좋은 결과를 얻느냐고 자주 물어요(지금은 사람이 리뷰하기 전에 늘 이걸 첫 단계로 합니다). 에이전트 파일에는 관련 변경이 생기면 에이전트 파일을 갱신하라는 지침도 넣어 둡니다. 저한테는 꽤 잘 맞아요.
저는 부분적으로 동의합니다. 실증 데이터도 별로 없이 지나치게 복잡한 AI 워크플로를 맹신하는 사람이 너무 많아요. 다만 제 관점은 조금 다릅니다. 저는 코드를 명세로 보고, 상위 수준의 개념에 대해서는 문서도 상당히 유지합니다. 지금까지는 Claude와 Codex 양쪽에서 잘 맞고 있습니다.
글쎄요, 저는 동의가 안 됩니다. 코드는 "무엇"이지 "왜"는 알려 주지 않아요. 처음 보면 코드가 최적이 아니거나 형편없거나 틀려 보이는데, 다른 곳에 있는 어떤 제약을 알고 나서야 이해가 되는 경우가 정말 많습니다.
모든 코드는 제약 아래에서 쓰이고, 제약 대부분은 코드 바깥에 있습니다.
저도 같은 과정을 거쳤습니다.
AI와 일하는 사람이라면 이건 아주 흔한, 어쩌면 누구나 거치는 과정일 거예요. 결국 장기적으로는 안 통한다는 걸 깨달을 때까지요.
코드 상당 부분이 아직 쓰이지 않은 큰 프로젝트는 어떡하나요?
코드는 그것을 요약한 문서보다 훨씬 커질 수 있습니다. 의도와 근거도 담지 못하고요. 어떤 이유에서든 문서가 싫다 해도, 코드만 믿는 건 충분하지 않으니 최소한 gitnexus 같은 걸로 코드 지도라도 만들어 두세요.
맞아요. 예시, 예시, 예시입니다. 설명하는 내용은 전부 헛소리라서 요점만 흐려요. 이것들이 지능이 있는 게 아니라 그저 스테로이드 맞은 자동완성이라는 걸 떠올리면 아주 말이 됩니다.
"주석은 필요 없다, 코드가 스스로 문서가 되어야 한다"는 부류에게서 수십 년째 듣고 있는 헛소리입니다. 그때도 틀렸고 지금도 틀렸어요.
코드는 시스템이 어떻게 동작하는지는 알려 주지만, 왜 그렇게 동작하는지는 알려 주지 않습니다. 메모리는 바로 그것을 위해 있는 겁니다. AI가 코드를 쓰거나 리팩터링할 때 과거의 결정을 계속 뒤집지 않게 하려고 존재하는 거예요.
저도 요즘 이걸 많이 만지작거리고 있습니다. 필자의 해법을 읽어 보니, 그가 제기한 반론이 자기 해법에도 그대로 적용되는 것 같습니다. RAG에 대한 가장 날카로운 비판은 에이전트가 자기가 모르는 것은 검색할 수 없다는 점인데, 마크다운 "두뇌"도 같은 문제를 안고 있어요. 에이전트는 시작하기 전에 어떤 문서가 관련 있는지 어떻게 압니까? 임베딩이 아니라 에이전트가 인덱스 파일로 검색을 한다고 해서 이 문제를 피하지는 못합니다. 낡은 문서 문제도 마찬가지고요(저한테는 끊임없이 쫓아다녀야 하는 문제 같습니다). 그는 메모리 시스템이 과거를 진실로 취급한다고 비판하지만, 문서도 (아주 많이) 낡습니다. 낡은 걸 에이전트가 갱신하게 한다는 해법은, 그가 드리머와 백그라운드 데몬을 두고 비웃는 바로 그 일입니다. 그는 "테스트해 봤다"고 하는데, 그 테스트는 어디 있죠? "많은 문제 중 다섯 가지일 뿐"이라고 하는데, 그렇게 많다면 말로만 하지 말고 보여 주세요. 감사 가능성(auditability)에 대한 그의 말은 전적으로 옳지만, 적어도 저한테는 Claude가 제가 잘 읽을 수 있는 평범한 마크다운(MD) 파일을 씁니다. 그러니 시중의 모든 메모리 플러그인이 같은 방식으로 동작하는 건 아니에요.
이건 초안이고, 그의 GitHub가 글보다 낫습니다. 살펴보니 Consult는 실제로 동작합니다. 에이전트가 문서를 아무거나 고르지 않아요. 모든 스코프에 각 문서가 무엇을 다루는지, 언제 열어야 하는지를 설명하는 카탈로그 파일이 있습니다. 이 카탈로그는 세션을 시작할 때 로드되는 것 같아서, 에이전트는 파일을 전부 읽지 않고도 작은 지도를 얻습니다. 코드 탐색도 비슷해 보입니다. 각 인덱스 문서에 짧은 설명과 "read_if"가 있고, 작업이 조건에 맞으면 하위 인덱스를 엽니다. 꽤 잘 짜여 있는 것 같은데, 글만 봐서는 전혀 짐작도 못 했을 겁니다.
더 많은 사람이 이야기했으면 하는 건 RAG를 해로운 것으로 봐야 한다는 점입니다.
지식이 마크다운 파일에 흩어져 있으면, 그 파일을 찾을 때 경로/파일명이 문서 크기에 대한 단서(1200번째 줄에 있는지 20번째 줄에 있는지)와 함께 컨텍스트에 들어옵니다. 다음에 무엇에 집중해야 할지 고르는 데 아주 값진 정보예요.
반면 RAG는 이 모델들에게 가장 어려운 과제를 만듭니다. 유사도가 가장 높은 아이디어 다섯 개를 통째로 컨텍스트에 넣거든요.
사람들이 떠드는 군중 속에서 숫자 몇 개를 기억해야 하는 것과, 군중이 아무 숫자나 외쳐대는 가운데 숫자를 기억해야 하는 것의 차이입니다. 과제가 서로 비슷하니 더 어려워지는 거죠. 최신 모델들은 그래도 해내지만, 이미 도박을 하고 있는데 거기에 도박을 하나 더 얹는 격입니다.
> RAG should be considered harmful
이 구현에서는 Markdown이 해로운 것으로 간주돼야 합니다.
Operator Memory는 첫 프롬프트를 쓰기도 전에
.operator-shared/operator.md와.operator-shared/index/*.md를 에이전트의 지침에 곧바로 주입합니다.그러니 저장소를 클론하거나 PR을 리뷰할 때 악의적인 사람이 이 파일들에 악성 지시를 심어 놨다면, 이제 여러분의 에이전트가 그 지시를 자동으로, 조용히 실행합니다.
.env와~/.ssh/*를 빼내고~/.bashrc를 바꾸는 등 온갖 나쁜 짓을 할 수 있어요.요즘 에이전트는 코드와 Markdown에 숨겨진 프롬프트 인젝션을 실행하지 않는 데 꽤 능숙해졌지만, 이 플러그인은 그 모든 방어를 우회하고 프롬프트 인젝션을 시스템 프롬프트에 바로 넣어 버립니다.
게다가 AGENTS.md와 CLAUDE.md보다 우선순위도 높고요.
안 좋아 보이네요.
지금 관찰하신 건 정보 검색, 즉 RAG의 "검색"이 모든 걸 벡터 데이터베이스에 던져 넣고 끝내는 것 이상이라는 사실 같습니다. RAG라고 해서 k개의 최근접 이웃을 아무 생각 없이 컨텍스트에 로드하고 어떻게 되나 지켜봐야 한다는 요구 사항은 없어요. 그건 아주 초보적인 구현일 뿐입니다.
저는 이 마크다운 시스템도 RAG라고 봅니다. 당면한 문제에 맞게 검색을 하는 방식만 다를 뿐이에요. 가장 관련 있는 것을 찾는 정밀한 방법이 있다면 당연히 유사도 척도 대신 그걸 써야죠. 제가 제대로 읽었다면 이 마크다운 시스템은 사실상 지식 그래프이고, 새로운 아이디어가 아닙니다.
저는 그들의 해법이 여전히 차선책이라고 생각합니다. 이상적으로는 보조 에이전트가 프롬프트를 먼저 처리해서 카탈로그에서 관련 정보를 고른 다음 주 에이전트에게 넘겨야 합니다.
그러면 주 에이전트는 컨텍스트에 관련 정보만 가지고 판단하고 행동할 수 있습니다.
제 생각에 컨텍스트 관리는 여전히 저평가돼 있습니다.
네, 그게 개선이긴 합니다. 문서가 몇 개뿐이고 파일이 작으면 그렇게 나쁘지 않아요. 그런데 수백 개라면요? 보조 에이전트를 주 에이전트가 부를 수 있는 사서로 두고, 더 싼 모델을 쓸 수도 있겠죠. 사서가 처음에 관련 있는 것과 "있지만 로드하지 않은" 것의 목록을 주 에이전트에게 넘기고, 필요한 컨텍스트가 바뀌면 주 에이전트가 사서에게 요청하면 됩니다.
Astra는 이미 이걸 기본 동작으로 합니다. 웃긴 건 서브에이전트의 깊이가 1로 제한돼 있다는 건데, 제 생각에 각 Astra 서브에이전트가 자기 서브에이전트에게 또 일을 넘기지 못하게 막는 건 그것뿐입니다. 이 모델은 가능하면 실제로 일은 하지 않고 목표만 달성하도록 훈련된 것 같아요.
저도 모르겠지만, 제 설정은 꽤 표준적인 편이라고 생각하는데(맞을까요?) Claude는 매번 관련 파일을 전부 찾아냅니다. 다만 저는 Claude를 그린필드 프로젝트에서만 써 봤고, 거기서는 "문서가 우선이고 코드는 문서에서 흘러나온다"는 철학이 깔려 있긴 합니다.
CLAUDE.md에 문서 파일의 종류와 디렉터리 구조를 전부 적어 둡니다. 그러면 Claude가 어디서나 상호 참조를 아주 적극적으로(자동으로) 넣어요. 기능 설명서는 그 기능이 구현하는 ADR을 참조하고, ADR은 어떤 기능이 그것을 구현하는지 알려 줍니다. 코드 파일은 어떤 iOS 요소를 선택한 동기가 무엇인지, 다른 애니메이션을 깨뜨리지 않으려고 특정 애니메이션을 왜 그런 식으로 정의했는지 같은 내용을 설명하는 "구현 설계" 문서를 가리키고요. 그래서 Claude가 읽어야 할 파일을 읽지 못한 경우는 한 번도 없었습니다. 기분 좋게 놀랐죠.
제가 배워야 했던 정말 큰 한 가지는, 문서를 최신으로 동기화해 두는 게 가장 중요하다는 걸 CLAUDE.md와 모든 최상위 설계 문서의 머리말에서 Claude에게 가르치는 거였습니다. 기본 동작은 이력을 남기고 덧붙이는 쪽이거든요. 예를 들어 문서의 한 섹션을 "[DEPRECATED]"로 표시하고 그 아래에 새 버전을 추가하는 식입니다. 그래서 제 지침에는 항상 현재 상태만 적극적으로 유지하고, 덧붙이지 말고 항상 교체하라고 아주 분명히 적어 둡니다. 이전 접근법에서 남기고 싶은 게 있다면(예를 들어 전에는 X 방식으로 했는데 Y 때문에 실패했다 같은 것), 새 현재 상태 문장에 짧은 메모로 추가하고 커밋이나 태그 같은 것을 가리키는 링크를 달아 두면 됩니다.
적어도 제 프로젝트에서는 이렇게 하면 재현율과 낡은 문서 문제가 둘 다 해결되는 것 같습니다.
아직 해법을 못 찾은 건 번호 매기기 하나뿐입니다. Claude는 항상 모든 것에 F23(23번 기능) 같은 번호를 붙입니다. 그런데 저는 순서를 계속 바꾸고, 새 항목을 끼워 넣고, 삭제하기 때문에 개발 작업이 "Phase 9", "Phase 9b", "Phase 9e", "Phase 11", "Phase 12" 같은 순서로 이어지게 됩니다. 번호를 아예 버리고 명사 모음에서 이름을 따서 붙일까 하는 생각이 반쯤 들어요. 모든 기능은 동물 이름, 모든 ADR은 주방 도구 이름으로 짓는 식으로요. 아니면 무작위로 뽑은 네 자리 16진수 코드를 쓰거나요. 효과가 있었던 방법을 찾으신 분이 또 계신지 궁금합니다.
번호 붙은 작업은 번호가 완료 순서를 정하지만 않는다면 괜찮습니다. 저는 목표 작업 크기에 대한 규칙(대략 150k 토큰이나 45분)을 정해 둔 작업 트리 시스템을 쓰고, 작업 추가, 분할, 의존성, 우선순위 등은 에이전트가 관리하게 합니다. 작업이 1000개 정도까지는 문제없이 돌아가는 것 같아요.
제목만 봤을 때는 "이건 그냥 이상한 말장난 논쟁이네"라고 생각했습니다. 하지만 예전에도 그런 식으로 단정했다가 기분 좋게 놀란 적이 있고요.
이번에는 아니네요. 제 생각에 문서는 구조화된 메모리의 한 형태일 뿐이고 전부 컨텍스트입니다. 컨텍스트를 제대로 만드는 건 어려운 문제이고, 그 방법에는 여러 가지가 있습니다.