모델을 기억 장치로 사용하는 것을 멈추세요

저는 하루 중 대부분의 시간을 Claude Code와 함께 보냅니다. 저를 계속 괴롭혔던 문제는 모델이 멍청해지는 것이 아니었습니다. 그것은 모델이 우리가 이미 결정한 사항을 잊어버린 다음, 확신에 차서 그것을 틀리게 다시 수행하는 것이었습니다.

여러분도 아마 이런 경험이 있을 것입니다. CLAUDE.md를 작성하고, 노트를 남기고, 모델에게 "우리는 X라고 결정했다"라고 말합니다. 하지만 몇 번의 프롬프트(Prompt)가 지나면 모델은 X에 대해 다시 논쟁하거나, 한 시간 전에 고쳤던 무언가를 조용히 망가뜨립니다. 더 큰 컨텍스트 윈도우 (Context Window)도 저에게는 해결책이 되지 않았습니다. 1M(100만) 토큰의 윈도우는 그저 오래된 지침들이 부패할 수 있는 공간이 더 넓어졌음을 의미할 뿐입니다.

여기 실제로 효과가 있었던 관점의 전환이 있습니다. 모델을 상태(State)가 머무는 장소로 취급하는 것을 멈추는 것입니다.

모델은 작업자이지, 서류 보관함이 아닙니다

컨텍스트 윈도우 (Context Window)는 작업 기억 (Working Memory)이지, 기록 (Record)이 아닙니다. 그것은 손실이 발생하고, 표류하며, 매 새로운 턴 (Turn)마다 눈앞에 있는 정보로부터 세상을 다시 도출합니다. 만약 "완료된 것과 반쯤 망가진 것"이 오직 그 윈도우 안에만 존재한다면, 여러분은 시스템에서 가장 잘 잊어버리는 부분에 가장 중요한 것을 기억하도록 신뢰하고 있는 셈입니다.

그래서 저는 상태 (State)를 모델 밖으로 옮겨 작업 (Work) 속으로 넣었습니다.

두 가지 요소가 그 역할을 대부분 수행했습니다:

1. 에이전트 (Agent)가 다시 읽는 고정된 명세서 (Spec). 모델이 압축해 버릴 수도 있는 채팅 메시지가 아닙니다. 우리가 무엇을 만들고 있는지, 그리고 무엇이 이미 결정되었는지를 명시하는 실제 파일입니다. 모델이 표류하기 시작할 때, 진실의 원천 (Source of Truth)은 대화에 대한 모델의 기억이 아니라 이 명세서가 됩니다.

2. 무언가가 검증된 후에만 체크할 수 있는 체크리스트. 테스트를 통과하거나 제가 변경 사항을 확인했을 때만 [ ]가 [x]가 됩니다. 모델이 "다 했다고 생각해서" 체크하는 일은 결코 없어야 합니다. 체크리스트가 진행 상황을 담고 있습니다. 모델은 단지 검증된 단계를 한 번에 하나씩 앞으로 나아갈 뿐입니다.

이 차이는 미묘하지만 게임의 판도를 바꿉니다. 이전에는 작업이 대화의 부수적인 결과물(Side effect)이었습니다. 이후에는 대화가 작업의 부수적인 결과물이 됩니다. 에이전트는 전체 맥락을 놓치더라도 명세서와 체크리스트를 통해 다시 불러와서 기본적으로 중단된 지점부터 작업을 이어갈 수 있습니다.

저를 놀라게 한 숫자

제가 실제로 제 세션들을 측정했을 때, 제 토큰 중 거의 대부분이 새로운 입력(fresh input)이 아니었습니다. 대부분은 캐시 읽기(cache reads)와 변경되지 않은 지침을 다시 읽는 것이었습니다. 따라서 "맥락 문제(context problem)"는 더 많은 정보를 입력해야 한다는 것이 아니었습니다. 문제는 제가 한 번에 너무 많은 것을 유지하게 만들고 있었고, 유지되는 내용의 대부분이 오래된(stale) 정보였다는 점입니다.

단계별로 모델이 짊어져야 할 양을 줄이는 것이 그 어떤 프롬프트 기술(prompt trick)보다 효과적이었습니다. 더 엄격한 명세(spec), 더 좁은 범위(smaller surface), 그리고 검증 후 진행(verify-then-advance)하는 방식입니다.

이것이 나타나는 곳

동일한 문제가 프로덕션 에이전트(production agents)에서도 발생하며, 다만 더 눈에 띄게 나타날 뿐입니다. 로컬 데모는 전체 실행 과정이 하나의 윈도우(window)에 들어오기 때문에 통과됩니다. 하지만 실제 앱에서는 에이전트가 완전히 다시 불러올 수 없는 스레드(thread)로 돌아오게 되고, 결국 표류(drift)하게 됩니다. 에이전트에게 "내 컴퓨터에서는 잘 됐는데"라는 말은 보통 "하나의 맥락(one context)에서는 잘 됐는데"라는 뜻입니다.

만약 이 문제로 고군분투하고 있다면, 해결책은 더 나은 메모리 플러그인(memory plugin)을 찾는 것이 아닙니다. 모델이 상태를 유지할 필요가 없도록, 작업(work) 자체가 상태(state)를 운반하게 만드는 것입니다.

저도 여전히 이 방식의 한계(명세가 너무 커지면 그 자체로 부패(rot) 문제가 발생함)를 파악해 나가는 중입니다. 하지만 핵심 원칙은 몇 달 동안 안정적이었습니다. 모델은 작업자(worker)이고, 리포지토리(repo)는 메모리(memory)입니다.