3개월간 내 코드베이스 AI 에이전트에게 가르쳤지만, 매일 아침 잊어버려요

출처: Dev.to

매일 아침 3개월 동안, 나는 첫 번째로 내 도구들에게 자신을 다시 설명하는 것이 들었다.
코드 자체는 괜찮았다. 나는 모든 것을 둘러싼 맥락을 말한다: 어제 화요일에 우리가 결정한 것, 왜 그 방식을 배제했는지, 스프린트는 실제로 어떤 것이었는지, 구조를 어떻게 잡았는지, 그리고 이유까지. 24시간마다 새로운 일처럼 느껴지는 작업이 아니라 연속적으로 진행되는 느낌이 들게 만드는 맥락 말이다.

어느 오후, 나는 터졌다. 내 에이전트가 최근에 내가 두 주 전에 배제했던 정확한 API 구조를 상세히 설명하며 진정한 확신으로 제안하는 것을 보았다. 같은 논리, 같은 맹점. 그것은 우리 대화의 일부였지만 기억하지 못했다.

노트북을 닫고 산책 나갔다.
이것은 처음 공개적으로 이 이야기를 쓰는 것이니 양해 바란다.

맥락: 나는 백엔드 엔지니어이며 약 6년차 경력이다. 현재는 대기업에서 일하고 있다. 그 전 몇 달 동안, 리더십은 우리가 AI 코딩 도구에 전면적으로 집중하기로 결정했다. 메모지는 “운영 효율성”과 “인력 최적화” 같은 단어를 사용했다. 의미는: 더 많은 것을 더 적은 인력으로 accomplish하고, 이 도구가 그 정당성을 돕는다는 것이었다.

그리고 보라 — 도구들은 그 목표를 달성했다. Claude Code는 진정으로 나를 놀랐고, 실제 코드를 빠르게 만들며, 동일한 시간에 내가 썼을 것보다 훨씬 나은 결과를 내는 경우가 많았다. 하지만 아무도 명명하지 않은 비용이 있었다.

매번 세션은 첫 만남 같았다.
20분 동안 재배치하고, 그다음에 흐름이 시작되어 1시간 정도 지속되지만, 컨텍스트 창이 삐걱거리며 에이전트가 실을 놓친다. 매. 일. 일일. 생산성 향상은 진실했지만, 이 보이지 않는 부담도 존재했으며, 계속해서 쌓였다.

나는 해결책을 찾았다. CLAUDE.md와 .cursorrules는 훌륭하게 작동하지만, 때때로 그렇지 않다. 몇 개월 지나면 contradictions와 오래된 결정을 담은 파일이 쌓이고, 무엇이 여전히 유효한지 확신이 서지 않는다. 클라우드 메모리 제품들은 월 구독과 데이터를 그들의 서버에 저장하려 한다. 내가 찾은 자체 호스팅 옵션들은 실제 인프라를 배포하는 것이Workflow 문제를 해결한다는 느낌을 주었다.

그것들이 내 목적을 충족시키지 못했다. 나는 더 큰 컨텍스트 창을 원하지 않았다. 나는 내가 어떻게 일하는지 이해하고, 시간이 지남에 따라 개선되는 something을 원했다. 마치 프로젝트에 6개월 동안 함께한 동료처럼, 초보자가 온보딩 문서를 읽는 것처럼가.

그걸 찾을 수 없었다. 그래서 나는 직접 구축하였다.

첫 번째 버전은 버킷이었다. 저장하고 나중에 찾아내는 간단한 형태.
그것이 작동했다가 안 될 때까지. 몇 주 만에 메모리 수가 늘어나 유용한 것이 소음 속에 잠기게 되었다 — 내가 되돌린 오래된 결정들, 진행되지 않은 반성들, 그리고 내가 다시 바꾼 선호도들. 저장할수록 검색이 나빠졌다. 정반이었다.

그럼 나는 깨달았다. 에이전트가 기억을 꺼낼 때마다 같은 몇 가지 항목만 계속 끌어올리고 나머지는 무시했다 — 실제로 도움이 되는 것이 계속 사용된다. 소음은 그대로 방치되었다.

이 관찰을 행동으로 옮기는 데 시간이 걸렸다. 하지만 그렇게 했을 때 전체 시스템이 어떻게 변했는지 바꾸었다.
피드백 루프를 구축하였다. 메모리가 검색될 때마다 평가를 받는다 — 이걸 실제로 도왔는가? 유용한 것은 점수가 높다. 기여하지 않으나 꺼내는 것이 점수가 낮아져 조용히 사라진다. 충분한 실패 후,它们悄然消失。 시스템은 단순히 성장하는 것이 아니라 스스로 필터링한다.

첫 번째 painful afternoon 이후 6개월이 지나, 내가 매일 사용하는 도구는 처음 만든 버킷과 거의 닮지 않는다. 그것은 단순히 가득 찬 것이 아니라 날카롭다 — 지난 달에 검증한 내용이 한 주 전의 가벼운 생각보다 위에 있고, 마감되는 것들은 내가 직접 정리하지 않아도 스스로 청소된다.

나머지는 대부분 내가 불편함을 느끼면서 해결한 것이다.

대시보드를 추가하여 무엇이 저장되어 있는지 알 수 없게 되었을 때
자동 연결: API 규칙과 오류 처리 패턴 메모리를 저장하면Those should know about each other.
네임스페이스: 여러 에이전트를 실행하면서 충돌이 발생했을 때

아무것도 계획되지 않았다. 모든 기능은 특정 불편함에서 비롯되었다.

벤치마크는 decent — 상위 5개 결과의 회상률 96.6%, 첫 번째 결과 84.6%, 33ms에 오픈소스 임베딩 모델로 로컬 실행이 가능하다. 클라우드, 특허 모델, 지속적인 비용 없이.
하지만 내가 실제로 추적하는 수치는 더 간단하다: 오늘 세션이 6개월 전보다 나은가? 예. 훨씬 낫다.

한 가지는 예상치 못했다: 에이전트가 직접 도구를 구축에 도움을 주었다.
내가 기억을 위한 도구로 사용하던 동일한 도구들이 내가它를 구축하는 데 주요 협력자였다. 검색 결과가 노이즈가 많으면 우리는 가중치를 함께 조정하였다. 도구 스키마가 불편하면, 그 사용 방법으로 불만을 표출하였다 — 잘못된 호출, 우회책, 이상한 표현된 쿼리 — 그리고 우리는 이를 수정했다. 제품은 그들이 부러진 것을 기반으로 형성되었다.

이것이 여전히 약간 이상하게 느껴진다. 하지만 효과적이었다.
그 이름은 Lorekeeper다. Apache 2.0, 로컬 실행.

pip install lorekeeper-mcp
lorekeeper setup
lorekeeper

에이전트에게 기억할 것을 말하고 내일 되돌아와서 물어보라. 그리고 한 달 뒤에 다시 돌아와서 어떻게 다른 방식으로 찾는지 알아차려라.
그것이 내가 진정으로 신경 쓰는 테스트다. 벤치마크 숫자가 아니라 — 오늘 세션이 6개월 전보다 더 나은 느낌이 드는가? 예. 훨씬 낫다.

그걸 위해 만들기 위해 산책 나갔다.

GitHub: https://github.com/Jessinra/Lorekeeper
Docs: https://jessinra.github.io/Lorekeeper/
Apache 2.0. Built by agents, for agents.