3개월 동안 AI 에이전트에게 내 코드베이스를 가르쳤지만, 매일 아침이면 모두 잊어버렸습니다
요약
AI 에이전트가 코드 작성 능력은 뛰어나지만, 프로젝트의 맥락과 과거의 결정 사항을 지속적으로 망각하는 '컨텍스트 유지' 문제를 다룹니다. 개발자가 겪는 반복적인 재설명 오버헤드를 해결하기 위해 직접적인 해결책을 모색하는 과정을 담고 있습니다.
핵심 포인트
- AI 에이전트의 뛰어난 코드 작성 능력 대비 낮은 맥락 유지력
- 매일 반복되는 재오리엔테이션으로 인한 생산성 저하(오버헤드)
- CLAUDE.md나 .cursorrules 등 기존 방식의 한계점
- 단순 저장 방식(Bucket)의 검색 성능 저하 및 노이즈 문제
3개월 동안 매일 아침, 제가 가장 먼저 한 일은 저 자신의 도구들에게 저 자신을 다시 설명하는 것이었습니다.
코드가 아니었습니다. 코드는 괜찮았습니다. 제 말은 그 주변의 모든 것들, 즉 지난 화요일에 우리가 무엇을 결정했는지, 왜 그 방식을 배제했는지, 이번 스프린트(sprint)의 실제 목적은 무엇인지, 우리가 구조를 어떻게 잡았고 그 이유는 무엇인지 같은 것들 말입니다. 업무가 매 24시간마다 새로운 직장에 들어온 것처럼 느껴지는 대신, 연속성을 느끼게 해주는 맥락(context) 말입니다.
그러던 어느 오후, 한계점이 찾아왔습니다. 저는 제 에이전트가 제가 2주 전에 거절했던 바로 그 API 구조를 — 아주 상세하게, 그리고 진심 어린 자신감을 가지고 — 제안하는 것을 지켜보았습니다. 똑같은 논리, 똑같은 사각지대였습니다. 그것은 이미 우리 대화의 일부였습니다. 단지 기억하지 못했을 뿐입니다.
저는 노트북을 닫고 산책을 나갔습니다.
이 내용을 공개적으로 쓰는 것은 이번이 처음이니 양해 부탁드립니다.
배경을 설명하자면: 저는 백엔드 엔지니어(backend engineer)로 경력은 약 6년 정도 되었고, 현재 대형 기술 기업 중 한 곳에 재직 중입니다. 이 모든 일이 일어나기 몇 달 전, 경영진은 우리가 AI 코딩 도구에 올인(all-in)하기로 결정했습니다. 내부 메모에는 "운영 효율성(operational efficiency)"과 "인력 최적화(headcount optimization)" 같은 단어들이 사용되었습니다. 그것이 의미하는 바는 이랬습니다: 더 적은 인원으로 더 많은 일을 하라, 그리고 여기 그것을 정당화하는 데 도움이 될 도구가 있다.
그리고 보세요 — 도구들은 그 가치를 증명했습니다. Claude Code는 진심으로 저를 감동시켰습니다. 실제 코드를 빠르게, 종종 제가 같은 시간 동안 작성했을 것보다 더 나은 수준으로 작성해냈습니다. 하지만 아직 아무도 이름을 붙이지 않은 비용이 있었습니다.
모든 세션은 첫 데이트와 같았습니다.
20분 동안의 재오리엔테이션(re-orientation), 그 후 아마 한 시간 정도의 몰입(flow), 그러다 컨텍스트 윈도우(context window)가 삐걱거리기 시작하면 에이전트가 맥락을 놓치는 것을 지켜보게 됩니다. 매. 일. 아침. 생산성 향상은 실재했지만, 이 보이지 않는 오버헤드(overhead) 또한 실재했습니다. 그리고 그것은 계속해서 쌓여갔습니다.
저는 해결책을 찾아 헤맸습니다. CLAUDE.md와 .cursorrules는 훌륭하게 작동합니다. 하지만 한계가 오기 전까지만 그렇습니다. 몇 달이 지나면 파일은 모순과 오래된 결정들로 가득 차게 되고, 무엇이 여전히 유효한지 아무도 확신할 수 없게 됩니다. 클라우드 메모리 제품들은 월간 구독료를 요구하며 여러분의 데이터를 자신들의 서버에 저장하길 원합니다. 제가 찾아낸 셀프 호스팅 (self-hosted) 옵션들은 단순히 워크플로우 문제를 해결하기 위해 실제 인프라를 구축해야 하는 것처럼 느껴졌습니다.
그 어떤 것도 제가 원하는 대로 작동하지 않았습니다. 제가 원한 것은 더 큰 컨텍스트 윈도우 (context window)가 아니었습니다. 제가 어떻게 일하는지에 대한 이해를 구축하고, 시간이 지날수록 그 이해가 더욱 정교해지는 무언가를 원했습니다. 온보딩 문서를 처음 읽는 계약직 직원이 아니라, 프로젝트에 6개월 동안 참여해 온 동료 같은 존재 말입니다.
그런 것을 찾을 수 없었습니다. 그래서 저는 직접 만들기 시작했습니다.
첫 번째 버전은 버킷 (bucket) 형태였습니다. 무언가를 저장하고, 나중에 그것을 찾는 방식이었죠. 단순했습니다.
작동은 했습니다, 한계에 부딪히기 전까지는 말이죠. 몇 주가 지나자 수백 개의 노트가 쌓였고, 유용한 것들은 노이즈 속에 파묻혀 버렸습니다. 제가 번복했던 오래된 결정들, 아무런 결론도 내지 못한 반쪽짜리 생각들, 마음을 바꾼 선호도 같은 것들 말입니다. 저장하면 할수록 검색 (retrieval) 성능은 오히려 나빠졌습니다. 정확히 정반대로 말이죠.
그러다 한 가지를 발견했습니다. 에이전트가 메모리를 불러오는 과정을 지켜보니, 항상 몇 가지 정해진 것들만 계속해서 불러오고 나머지 대부분은 무시하고 있었습니다. 실제로 저에게 도움이 되었던 것들은 계속 사용되었습니다. 노이즈들은 손도 대지 않은 채 그대로 남아 있었습니다.
그 관찰을 실제 행동으로 옮기기까지는 시간이 좀 걸렸습니다. 하지만 실행에 옮기자, 시스템 전체의 작동 방식이 바뀌었습니다.
저는 피드백 루프 (feedback loop)를 구축했습니다. 메모리가 호출될 때마다 점수가 매겨집니다. 이것이 실제로 도움이 되었는가? 유용한 것들은 더 높은 점수를 받습니다. 호출은 되지만 기여하지 못하는 것들은 점수가 낮아지기 시작합니다. 충분히 많은 실패를 겪으면, 그것들은 조용히 사라집니다. 시스템은 단순히 커지기만 하는 것이 아니라, 스스로를 필터링합니다.
그 고통스러웠던 첫 오후로부터 6개월이 지난 지금, 제가 매일 사용하고 있는 도구는 처음에 시작했던 그 '양동이'와는 거의 닮지 않았습니다. 단순히 내용물이 더 많아진 것이 아닙니다. 훨씬 더 날카로워졌습니다(sharper). 지난달에 검증한 내용들은 첫 주에 스치듯 지나간 생각보다 더 높은 우선순위를 갖게 되었고, 막다른 길(dead ends)들은 제가 수동으로 가지치기를 하지 않아도 스스로 정리됩니다.
그 나머지 대부분은 제가 수정할 때까지 저를 괴롭혔던 것들로부터 나왔습니다.
저장소에 무엇이 들어있는지조차 알 수 없을 때는 대시보드를 추가했습니다. 관련 있는 기억들이 서로를 찾아야 한다는 것을 깨달았을 때는 자동 연결(Auto-linking) 기능을 넣었습니다. 예를 들어, 우리의 API 컨벤션(conventions)에 관한 무언가와 에러 처리 패턴(error-handling patterns)에 관한 무언가를 저장한다면, 이 둘은 아마 서로를 알아야 할 것입니다. 여러 에이전트(agents)를 실행하기 시작했을 때 그들이 서로의 노트를 짓밟는 일이 발생하자 네임스페이스(Namespaces)를 도입했습니다.
계획된 것은 아무것도 없었습니다. 모든 기능 뒤에는 특정한 좌절감이 자리 잡고 있습니다.
벤치마크 결과는 준수합니다. 누구나 로컬에서 실행할 수 있는 오픈 소스 임베딩 모델(embedding model)을 사용하여 33ms의 속도로 상위 5개 결과에서 96.6%의 재현율(recall)을, 첫 번째 결과에서 84.6%를 기록했습니다. 클라우드도, 독점 모델(proprietary model)도, 지속적인 비용도 없습니다. 하지만 제가 실제로 추적하는 수치는 더 단순합니다. '오늘의 세션이 6개월 전의 세션보다 더 나은가?' 정답은 '예'입니다. 훨씬 더 낫습니다.
예상치 못했던 한 가지는, 에이전트들이 이것을 만드는 데 도움을 주었다는 점입니다.
제가 메모리(memory)를 구축해주고 있던 바로 그 도구들이, 동시에 이것을 구축하는 저의 주요 협력자이기도 했습니다. 검색 결과에 노이즈가 많아지면 우리는 함께 가중치(weights)를 조정했습니다. 도구 스키마(tool schema)가 투박하게 느껴질 때면, 에이전트들은 잘못된 호출, 우회 방법, 이상하게 표현된 쿼리(queries) 등 사용 방식을 통해 불만을 표시했고, 우리는 그것을 수정했습니다. 제품은 그들에게 문제가 되었던 것들에 의해 형상화되었습니다.
여전히 그것이 조금 이상하다고 생각합니다. 하지만 효과가 있었습니다.
이것의 이름은 Lorekeeper입니다. Apache 2.0 라이선스이며, 로컬에서 실행됩니다.
pip install lorekeeper-mcp
lorekeeper setup
lorekeeper
에이전트에게 무언가를 기억하라고 말해보세요. 내일 돌아와서 그것을 물어보세요. 그러고 나서 한 달 뒤에 다시 돌아와서, 에이전트가 얼마나 다르게 정보를 찾아내는지 확인해보세요.
그것이 제가 실제로 신경 쓰는 테스트입니다. 벤치마크 수치가 아니라, 당신의 프로젝트를 알고 있는 무언가와 함께 일할 때의 그 느낌 말입니다. 그것이 제가 산책을 나갔을 때 만들고자 했던 것입니다.
한번 시도해 보세요. 정말로 기억이 남는지 확인해 보세요.
GitHub: https://github.com/Jessinra/Lorekeeper
_Docs: https://jessinra.github.io/Lorekeeper/
Apache 2.0. 에이전트에 의해, 에이전트를 위해 만들어졌습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기