코딩 에이전트에게 필요한 것은 메모리 엔진이 아니라 기록자(Scribe)입니다

지난 몇 주 동안, 저는 AI 코딩 에이전트에게 지속적인 메모리 (persistent memory)를 부여하는 올바른 방법에 대해 여러 차례 대화를 나누었습니다.

어떤 개발자들은 AgentMemory에 대해 묻습니다. 다른 이들은 제가 직접 구축하고 유지 관리하는 Qiju에 대해 묻습니다.

저의 일반적인 답변은 이렇습니다.

그것은 다음과 같은 구조화된 인계 기록 (handoff record)을 생성합니다:

title:         Selected token refresh strategy
tags:          auth, architecture
search_terms:  refresh token, 401 retry
...

이 기록은 개발자의 로컬 머신에 일반 JSONL 파일로 저장됩니다. 아무것도 임베딩(embedded)되지 않습니다. 아무것도 머신 외부로 나가지 않습니다. 검색(Retrieval)은 결정론적인 키워드 및 태그 검색 방식입니다.

다음 세션에서 에이전트(agent)는 자신에게 필요한 것을 검색합니다. 개발자는 무엇이 왜 기록되었는지 정확하게 확인할 수 있습니다.

실질적인 차이점

AgentMemory를 "자동화된 Qiju"라고 부르거나, Qiju를 "수동 AgentMemory"라고 설명하고 싶은 유혹이 생길 수 있습니다. 하지만 이는 정확하지 않습니다.

두 도구는 서로 다른 질문에 답하고 있습니다.

AgentMemory는 다음과 같이 묻습니다: 에이전트가 이전 세션 동안 무엇을 관찰했는가?

Qiju는 다음과 같이 묻습니다: 개발자가 이 프로젝트에서 보존할 가치가 있다고 판단한 것은 무엇인가?

모든 도구 호출(tool call)에 대한 내부 로그는, 왜 특정 결정이 내려졌는지, 어떤 근거가 이를 뒷받침했는지, 그리고 어떤 접근 방식이 이미 거부되었는지에 대한 구조화된 기록과는 다릅니다.

메모리 엔진 (memory engine)은 일어난 일을 축적합니다.
기록 레이어 (record layer)는 중요한 것을 포착합니다.

이 차이점이 실무적으로 중요한 이유

제가 인증 버그를 조사하면서 세 가지 접근 방식을 시도했고, 두 번째 방식이 회귀(regression)를 일으킨다는 것을 발견하여, 변경 사항을 롤백(roll back)하고 아키텍처 노트에 특정 경계 조건(boundary condition)을 기록하기로 결정한 세션을 상상해 보십시오.

자동 메모리 캡처(automatic memory capture)는 다음과 같은 내용을 생성할 것입니다:

• 읽은 모든 파일에 대한 관찰 (observations)
• 실행된 모든 명령에 대한 관찰
• 모든 테스트 실패에 대한 관찰
• 압축된 세션 요약

이것은 유용한 배경 정보입니다.

의도적인 Qiju 기록은 다음과 같은 내용을 생성할 것입니다:

• 현재의 진실(ground truth)이 되는 특정 파일
• 결정 사항과 그 이유
• 거부된 두 가지 접근 방식과 그것들이 실패한 이유
• 다음 에이전트를 위한 다음 단계

다음 에이전트에게는 전체 관찰 추적(observational trace)이 필요하지 않습니다. 무엇이 결정되었는지, 증거를 어디에서 찾을 수 있는지, 그리고 무엇을 반복하지 말아야 하는지를 알 필요가 있습니다.

이것들은 서로 다른 산출물 (artefacts)입니다.

구체적인 예시 (A concrete example)

Codex의 SQLite 로깅 문제에 대해 작성했던 포스트에서, 저는 다음과 같은 종류의 기록을 설명했습니다:

Ground truth:  design/pypi-packaging-execution-plan.md
Decision:      Use one canonical src/qiju package for source and PyPI installs.
Verified:      Wheel and sdist passed artifact inspection and installed-wheel smoke tests.
...

전체 세션 트랜스크립트 (session transcript)에는 이러한 결론들을 둘러싼 수만 단어의 내용이 포함될 수 있습니다. 하지만 영구적인 프로젝트 기록 (durable project record)은 이보다 훨씬 작습니다.

다음 에이전트에게는 세션 전체가 필요하지 않습니다. 적절한 기록이 필요할 뿐입니다.

운영상의 차이점 (The operational differences)

철학적인 측면을 넘어, 두 도구는 서로 다른 운영상의 가정을 가집니다.

AgentMemory의 요구 사항:

• 백그라운드 데몬 (background daemon)으로 실행되는 Rust 바이너리 (iii-engine)
• Node.js 설치
• 로컬 또는 구성된 API 제공업체의 임베딩 모델 (embedding model)

외부 임베딩 제공업체가 구성된 경우, 콘텐츠가 기기를 벗어나게 됩니다. 로컬 all-MiniLM-L6-v2 모델을 사용하면 이를 방지할 수 있지만 설정 단계가 추가됩니다. AgentMemory는 Claude Code, Codex, Cursor, Cline, Gemini CLI 등을 포함하여 20개 이상의 에이전트를 지원합니다. macOS, Linux, Windows에서 실행됩니다.

Qiju의 요구 사항:

• Python 3.11 이상
• 그 외에는 필요 없음

기록은 개발자의 기기에 일반 JSONL 파일로 남습니다. 이 파일들은 코드와 함께 git에 커밋될 수 있습니다. Qiju는 Claude Code, Codex, Kiro, Cursor를 지원합니다. macOS와 Linux에서 실행됩니다. Windows는 아직 지원되지 않습니다.

결합되는 방식 (Where they compose)

저는 이 도구들을 경쟁 관계로 생각하지 않습니다.

한 팀은 에이전트가 무엇을, 언제, 어떤 파일에서 수행했는지에 대한 자동 백그라운드 캡처를 위해 AgentMemory를 실행하고, 무엇이 왜 결정되었는지에 대한 의도적인 레이어 (intentional layer)를 위해 Qiju를 실행할 수 있습니다.

AgentMemory는 에이전트가 무엇을 했는지 회상(recall)합니다.

Qiju는 개발자가 무엇을 결정했는지 기록(record)합니다.

이것이 자연스러운 책임의 분할입니다.

두 도구의 현재 한계 (Current limits of both)

AgentMemory의 자동화는 노력이 조금이라도 들어간다면 대부분의 개발자가 아무것도 기록하지 않을 것이라는 점 때문에 매우 가치 있습니다. 하지만 PostToolUse (도구 사용 후) 단위의 자동 캡처는 방대한 양을 생성합니다. 압축 단계가 이를 줄여주지만, 신호 대 잡음비 (Signal-to-noise ratio)는 LLM이 무엇이 중요한지를 얼마나 잘 식별하느냐에 달려 있습니다. 데몬 (Daemon)과 임베딩 파이프라인 (Embedding pipeline)은 운영 복잡성을 더합니다.

Qiju의 의도적인 캡처는 어떤 개발자에게는 기능(Feature)이지만, 다른 개발자에게는 마찰 지점(Friction point)이 됩니다. 만약 무언가를 기록하는 것을 잊어버리면 기록되지 않습니다. 다만 에이전트 설정의 Stop hook을 사용하면 세션이 종료되기 전에 에이전트가 qiju-log를 실행하도록 지시할 수 있으며, 이를 통해 기록되지 않는 세션이 발생할 가능성을 줄일 수 있습니다. 시맨틱 검색 (Semantic search) 기능은 없습니다. 검색 (Retrieval)은 기록 시점에 좋은 키워드와 태그를 사용하는 것에 의존합니다. 기록의 품질은 그것을 작성하는 데 들인 노력만큼만 보장됩니다.

두 도구 모두 모든 문제를 해결하지는 못합니다. 두 도구 모두 현재의 한계에 대해 솔직하게 밝히고 있습니다.

두 도구 모두 모든 문제를 해결하지는 못합니다. 두 도구 모두 현재의 한계에 대해 솔직하게 밝히고 있습니다.

나의 결론 (My conclusion)

에이전트 메모리 (Agent memory) 문제는 아직 해결되지 않았습니다. 툴링 (Tooling)은 초기 단계이며 빠르게 변하고 있습니다.

마찰이 없는 자동 캡처가 가장 중요하고 운영 요구 사항을 감당할 수 있다면, AgentMemory를 탐색해 볼 가치가 있습니다.

의도적이고 감사 가능한 (Auditable) 파일 기반 기록이 가장 중요하며, 백그라운드 서비스나 외부 의존성이 없는 것을 원한다면, Qiju가 그 모델에 더 적합합니다.

만약 두 가지 모두 중요하다면 — 도구들을 조합하면 됩니다.