What If Your Coding Agent Could Remember What It Learned Yesterday?
코딩 에이전트가 어제 배운 것을 기억한다면? — AI 어시스턴트용 지식 저장 도구 Attic
Claude Code나 Codex CLI 같은 AI 코딩 어시스턴트는 세션이 끝나면 조사 중 발견한 지식을 잃어 같은 탐색을 반복하며 비용을 낭비합니다. 오픈소스 도구 Attic은 발견 내용을 프로젝트 내 .attic/ 디렉터리의 Markdown 파일로 저장하고 컴팩트한 인덱스만 컨텍스트에 주입해, 세션 재시작과 /compact 이후에도 지식을 재사용할 수 있게 합니다. 브라우저 확장을 통해 웹에서 읽은 내용도 같은 저장소에 클리핑할 수 있습니다.
- 주제
본문
AI 코딩 어시스턴트에게 버그 조사를 시키면 저장소를 검색하고 파일을 읽고 명령을 실행해 결국 원인을 찾아냅니다. 그런데 며칠 뒤 새 세션에서 같은 영역의 문제를 물어보면 어시스턴트는 같은 파일을 다시 검색하고 같은 경로를 다시 추적해 이미 알고 있던 사실을 재발견합니다. 저자는 이를 '같은 조사에 두 번, 세 번 비용을 지불하는 것'이라고 지적하며, 이 문제를 해결하기 위해 AI 코딩 어시스턴트용 오픈소스 지식 영속화 도구 Attic을 만들었다고 설명합니다.
왜 대화 기록만으로는 부족한가
예를 들어 JavaScript 모노레포에서 cloud 패키지 로딩 실패를 조사하면, 어시스턴트는 index.js에 default export가 두 개라는 구문 오류를 발견합니다. 코드베이스에는 수정된 코드가 남지만, 그 버그를 찾는 데 도움이 된 '추론'은 남지 않습니다. '데스크톱 서브윈도우는 인증 게이트가 완료되기 전에 생성될 수 있다' 같은 발견은 단순한 버그 리포트가 아니라 다음 조사가 어디를 봐야 하는지, 어떤 가정이 위험한지를 알려주는 지식입니다. 저자는 아키텍처 결정, 저장소 관례, 실패한 접근법, 성능상의 발견 등이 이런 지식에 포함된다며, '코드베이스가 구현의 서가라면 어시스턴트의 발견은 여백의 메모'라고 비유합니다.
카탈로그와 책 — 저장과 주입의 분리
Attic의 핵심 설계는 저장(storage)과 주입(injection)의 분리입니다. 지식은 .attic/ 아래 INDEX.md, DECISIONS.md, items/*.md 형태의 Markdown 파일로 디스크에 저장되고, 어시스턴트에게는 고정(pinned) 항목과 최근 발견을 우선하는 컴팩트한 인덱스만 주입됩니다. 200개의 발견이 있어도 매 프롬프트에 전부 실을 필요가 없고, 인증 관련 조사에는 인증 관련 항목만 /attic-recall로 불러오면 됩니다. 저자는 이를 '데이터베이스 대 인덱스', '도서관 대 카탈로그'에 빗대며, 어시스턴트가 도서관 전체를 짊어지게 할 필요가 없다고 설명합니다.
명령과 지식 라이프사이클
워크플로는 /attic-stash로 조사 후 발견을 저장하고, /attic-recall <topic>으로 검색하며, /attic-index로 인덱스를 확인하는 구조입니다. 모든 발견이 영구적 prominence를 가질 필요는 없으므로 /attic-pin, /attic-prune, /attic-archive로 생명주기를 관리합니다. 주목할 설계 결정으로 '편집은 교체(replace), stash는 추가(append)'라는 구분이 있습니다. 기존 항목을 수정할 때 새 사본을 덧붙이면 어시스턴트가 여러 버전을 조정해야 하는 노이즈가 생기기 때문입니다. 또한 삭제 엔드포인트를 두지 않고 archive와 prune을 제공하는데, 실수로 중요한 지식이 파괴되는 것을 막기 위한 의도적 선택입니다.
/compact를 넘어서는 기억
긴 세션 끝에 /compact를 실행하면 컨텍스트가 축소되어 초반 조사 내용이 사라질 수 있습니다. 하지만 발견을 .attic/items/f3.md 같은 파일로 저장해 두면 지식은 대화보다 오래 살아남습니다. 저자는 이를 '지식이 컨텍스트 윈도우보다 오래가야 한다'는 영속적 에이전트 메모리의 핵심 약속이라고 말합니다.
브라우저 컴패니언 — 터미널 밖의 학습
개발자는 GitHub 이슈, Stack Overflow 답변, 문서 페이지 등 브라우저에서도 많은 것을 배우지만, 그 정보는 탭을 닫는 순간 프로젝트 지식으로 들어오지 못합니다. Attic의 브라우저 확장은 유용한 내용을 클리핑해 같은 .attic/ 저장소에 넣습니다. 여기서 중요한 설계는 별도의 브라우저 저장소를 만들지 않고 기존 CLI writer를 재사용한다는 점입니다. '하나의 서가, 여러 입구'라는 원칙으로 저장 모델의 일관성을 유지하며, 브라우저에서 저장한 지식을 CLI에서도 recall할 수 있습니다.
로컬 우선과 보안 설계
브라우저 확장이 로컬 파일에 쓸 수 있다는 것은 보안이 필요하다는 뜻입니다. Attic은 루프백 통신, 요청 검증용 토큰, 승인된 프로젝트 루트만 쓰기를 허용하는 root allowlist, 오리진 검사를 설계에 포함합니다. 특히 클리핑 내용에 API 키 같은 자격 증명이 포함되면 거부하는 credential scan을 두지만, 저자는 모든 시크릿이 탐지되지는 않으므로 민감 정보는 직접 클리핑하지 말라고 당부합니다. 런타임은 Node.js fs와 path만 사용하고 플러그인 런타임에서 네트워크 호출이 없는 로컬 우선(local-first) 구조입니다.
팀 공유와 한계
.attic/을 Git에 커밋하면 클론과 함께 팀원에게 지식이 전파되지만, 무엇을 커밋하고 무엇을 로컬에 둘지, 오래된 발견을 어떻게 관리할지는 팀이 결정해야 합니다. 저자는 Attic이 소스 코드, Git 히스토리, 이슈 트래커, 문서를 대체하지 않으며, 저장된 항목이 항상 올바르다고 보장하지도 않는다고 명시합니다. '오래된 기억은 기억이 없는 것만큼 위험할 수 있다'며 편집·정리 워크플로의 필요성을 강조합니다.
더 나은 모델과 큰 컨텍스트에 집중되는 논의 속에서, '태스크가 끝난 뒤 유용한 지식은 어디로 가는가'라는 문제 의식을 제시하는 글입니다. GitHub 저장소(github.com/NishikantaRay/Attic)에서 확인할 수 있습니다.
원문: dev.to / 번역·요약: Trawling