스크립트가 아닌 체크포인트: AI 코딩 에이전트 메모리에 대한 재고

요약(TL;DR): AI 코딩 에이전트의 메모리는 채팅창이 아닌 리포지토리(Repository)에 존재해야 합니다. 더 큰 컨텍스트 윈도우(Context Window)와 벡터 데이터베이스(Vector Database)는 잘못된 문제를 해결하고 있습니다. 여기서는 리포지토리 자체를 지속 가능한 인지적 표면(Cognitive Surface)으로 취급해야 한다는 논거를 제시합니다.

현재 모든 이들이 AI 에이전트 메모리를 해결하려고 노력하고 있습니다. 더 긴 컨텍스트 윈도우(Context Window), 벡터 데이터베이스(Vector Database), 대화 재생(Conversation Replay), 시맨틱 검색(Semantic Retrieval), 무한한 스크립트(Transcripts) 등 말입니다. 하지만 Claude, Codex, Gemini, Cursor 및 기타 코딩 에이전트들을 활용해 워크플로우를 구축하며 수개월을 보낸 결과, 우리는 신뢰할 수 있는 원천(Source of Truth)으로서 잘못된 대상을 다루고 있을지도 모른다는 생각을 하기 시작했습니다.

문제는 "어떻게 하면 모델이 모든 것을 영원히 기억하게 만들 것인가?"가 아닙니다. 문제는 "소프트웨어 프로젝트가 세션, 압축(Compaction), 에이전트 전환 및 시간이 흐름에 따라 어떻게 인지적 일관성(Cognitively Coherent)을 유지할 것인가?"입니다. 이 둘은 매우 다른 문제입니다.

컨텍스트 윈도우(Context Window)는 지속 가능한 인프라가 아닙니다.

현대의 AI 코딩 워크플로우는 놀라울 정도로 취약합니다. 에이전트가 몇 시간 동안 작업합니다. 컨텍스트 윈도우(Context Window)가 가득 찹니다. 압축(Compaction)이 발생합니다. 그러고 나면 갑자기 다음과 같은 일이 벌어집니다:

• 아키텍처 추론(Architectural Reasoning)이 사라짐
• 해결되지 않은 작업이 잊혀짐
• 회귀(Regressions) 현상이 다시 나타남
• 에이전트들이 서로의 작업을 되돌림
• 인간이 동일한 컨텍스트(Context)를 반복해서 다시 설명함

지금까지 업계의 대응은 주로 "더 많이 저장하라"였습니다. 더 큰 컨텍스트 윈도우(Context Window), 벡터 데이터베이스(Vector Database), 호스팅된 메모리 서비스, 거대한 스크립트(Transcripts)에 대한 시맨틱 검색(Semantic Retrieval) 등이 그것입니다. 하지만 스크립트(Transcripts)는 이해(Understanding)가 아닙니다. 그리고 거대한 채팅 기록을 재생하는 것은 운영의 연속성(Operational Continuity)을 보존하는 것과 같지 않습니다.

실제로 대부분의 코딩 워크플로우는 정보가 완전히 사라져서 실패하는 것이 아닙니다. 중요한 상태(State)가 애초에 대화로부터 추출되지 않았기 때문에 실패하는 것입니다.

스크립트(Transcripts)가 아닌 체크포인트(Checkpoints)

제가 탐구해 온 아이디어는 꽤 간단합니다. 전체 대화를 영원히 보존하는 대신, 의미 있는 순간마다 구조화된 체크포인트(Checkpoints)를 보존하는 것입니다.

모든 토큰, 모든 생각, 모든 대화의 탈선을 저장하는 것이 아닙니다. 실제로 중요한 것들, 즉: 현재 상태 (current state), 아키텍처 결정 (architectural decisions), 해결되지 않은 스레드 (unresolved threads), 회귀 위험 (regression risks), 다음 권장 작업 (next recommended actions), 구현 추론 (implementation reasoning), 인수인계 컨텍스트 (handoff context)를 저장하는 것입니다. 체크포인트는 지속 가능한 진실의 원천 (durable source of truth)이 됩니다. 라이브 컨텍스트 윈도우 (live context window)는 일회성 작업 메모리 (disposable working memory)가 됩니다. 이 차이는 많은 것을 변화시킵니다.

리포지토리가 기억해야 합니다 (The Repo Should Remember)
여러 코딩 에이전트 (coding agents)를 가로질러 작업하면서 계속해서 깨달은 사실이 하나 있습니다: 리포지토리 (repository) 그 자체만이 실제로 지속되는 유일한 것입니다. 에이전트 (Agents)는 변합니다. 모델 (Models)은 변합니다. 세션 (Sessions)은 종료됩니다. 윈도우 (Windows)는 압축됩니다. 하지만 리포지토리는 남습니다. 그래서 저는 연속성 (continuity)을 채팅 세션 안에 갇힌 무언가로 취급하는 대신, 리포지토리 네이티브의 관심사 (repo-native concern)로 취급하기 시작했습니다. 이는 다음을 의미합니다:

• 연속성 아티팩트 (continuity artifacts)는 리포지토리에 존재합니다.
• 인수인계 (handoffs)는 리포지토리에 존재합니다.
• 운영 상태 (operational state)는 리포지토리에 존재합니다.
• 회귀 메모리 (regression memory)는 리포지토리에 존재합니다.
• 체크포인트 (checkpoints)는 리포지토리에 존재합니다.
  윈도우가 아니라 리포지토리가 기억하는 것입니다.

멀티 에이전트 개발 (Multi-Agent Development)은 이미 여기에 있습니다
많은 도구들이 여전히 '한 명의 인간, 한 명의 에이전트, 한 번의 세션'을 가정합니다. 하지만 이는 더 이상 많은 사람들이 실제로 일하는 방식이 아닙니다. 실제 워크플로우는 점점 다음과 같은 모습을 띠고 있습니다:

• 아키텍처 설계를 위한 Claude
• 구현을 위한 Codex
• 반복 작업을 위한 Cursor
• 탐색을 위한 Gemini
• 이 모든 것을 검토하는 인간
• 내일 작업을 이어가는 또 다른 세션
  연속성은 더 이상 단순한 메모리가 아닙니다. 그것은 교체 가능한 실행 표면 (interchangeable execution surfaces) 간의 조정 (coordination)입니다. 일단 그렇게 프레임을 짜고 나면, 채팅 창은 중요한 것을 저장하기에 적절한 장소처럼 보이지 않게 됩니다.

AI 에이전트는 일시적입니다. 리포지토리는 지속됩니다.
저는 소프트웨어 리포지토리 자체가 인지 시스템 (cognitive systems)이 되는 단계에 진입하고 있다고 생각합니다: 의사결정을 축적하고, 연속성을 보존하며, 작업을 조정하고, 에이전트 교체 (agent turnover)를 견뎌내며, 운영 메모리를 시간이 흐름에 따라 앞으로 전달하는 시스템 말입니다. 이는 모델이 무한히 똑똑해졌기 때문이 아닙니다. 연속성이 전적으로 모델 세션에 의존하는 것을 멈추었기 때문입니다.

그것이 바로 제가 에이전트 간의 저장소 네이티브 연속성 (repo-native continuity)을 위한 오픈 소스 CLI인 Holistic을 통해 탐구해 온 방향입니다: https://github.com/lweiss01/holistic 아직 초기 단계이며, 빠르게 진화하고 있습니다. 만약 여러분이 여러 코딩 에이전트 (coding agents)를 사용하면서 연속성 문제에 직면하고 있다면, 여러분이 이 문제를 어떻게 해결하고 있는지에 대한 피드백, 비판, 혹은 단순한 대화라도 진심으로 환영합니다. 기억하는 것은 윈도우 (window)가 아니라 저장소 (repo)입니다.