시리즈를 여기까지 따라오셨다면 공통 패턴이 보일 겁니다. 컨텍스트 윈도우 안에 두는 것을 최소화하라는 것. 3편의 “/clear 전에 상태를 파일로”, 4편의 “본문 대신 포인터만”, 5편의 “과정은 서브에이전트에, 결론만 메인에”가 전부 같은 방향을 가리킵니다. 그런데 이 파일들, 그러니까 컨텍스트 밖으로 내려보낸 정보의 목적지를 아직 제대로 다루지 않았어요.
이번 편의 주제가 그 목적지입니다. 세션이 끝나도 살아남아야 하는 지식을 어디에 어떻게 두는가. 비유하자면 컨텍스트 윈도우는 작업대이고 파일 시스템은 창고입니다. 작업대는 좁고 비싸고 세션이 끝나면 치워집니다. 창고는 넓고 싸고 계속 남아요. 좋은 에이전트 운용은 결국 작업대와 창고 사이의 물류 설계입니다.
계획 파일, 긴 작업의 생명줄
가장 기본이 되는 외부화는 계획 파일입니다. 작업을 시작할 때 목표, 확정된 결정, 남은 단계를 PLAN.md 같은 파일로 만들게 하고, 진행하면서 갱신하게 하는 겁니다.
이 파일 하나로 여러 문제가 한 번에 풀립니다. 우선 세션 리셋에서 살아남습니다. 컨텍스트가 차서 /clear를 하든, 노트북을 덮었다가 다음 날 새 세션을 열든, 계획 파일을 읽히면 작업이 이어져요. 3편에서 본 auto-compact의 불확실한 요약과 달리, 뭘 남길지 직접 통제한 정확한 기록이라는 점이 다릅니다.
부수 효과도 있습니다. 에이전트가 매 단계마다 계획 파일을 갱신하고 다시 읽으면, 전체 목표가 컨텍스트의 최근 위치에 반복해서 나타납니다. 2편에서 본 대로 모델의 주의는 컨텍스트 끝부분에 강하게 쏠리는데, 이 성질을 역이용해 “지금 뭘 하던 중인지”를 계속 시야에 붙들어 두는 거예요. 수십 단계짜리 작업을 시키면 에이전트가 중간에 원래 목표를 잊고 삼천포로 빠지는 문제의 처방이 이것입니다. 실제로 긴 작업을 다루는 에이전트 제품들이 할 일 목록을 파일로 두고 끊임없이 고쳐 쓰는 패턴을 씁니다.
메모리, 세션을 넘어 쌓이는 지식
계획 파일이 작업 하나의 수명을 늘린다면, 메모리는 프로젝트 전체에 걸쳐 지식을 쌓습니다. Claude Code를 비롯한 에이전트들이 메모리 디렉터리 기능을 지원하는데, 원리는 소박합니다. 알게 된 사실을 파일 하나에 하나씩 적어두고 요약 인덱스만 상시 로드하고 본문은 관련 작업에서 필요할 때 읽습니다. 4편의 포인터 원칙이 여기에도 적용되는 거죠.
여기서 중요한 건 저장 기준입니다. 아무거나 적으면 메모리가 금방 쓰레기장이 되니까요. 합격선은 “다른 곳에서 파생할 수 없는 정보”입니다. 코드 구조는 코드를 읽으면 알 수 있으니 탈락, 과거 커밋 내역은 git이 기억하니 탈락. 반면 “이 프로젝트의 dev 서버는 반드시 main 워크트리에서 띄운다” 같은 운영 규칙, “사용자는 존댓말 문체를 원한다” 같은 선호, 삽질 끝에 알아낸 환경 특유의 함정. 이런 건 어디에도 기록돼 있지 않아서 메모리에 적을 가치가 있습니다.
낡은 메모리 문제도 계획에 넣어야 합니다. 반년 전에 적은 사실이 지금도 참이라는 보장이 없어요. 메모리를 읽고 쓰는 규칙에 “참조한 메모리가 현실과 어긋나면 갱신하거나 삭제한다”를 포함해야, 잘못된 기억이 2편의 context poisoning으로 되돌아오는 걸 막을 수 있습니다.
RAG, 창고가 도서관 크기일 때
계획 파일과 메모리는 수십 개 파일 수준의 이야기입니다. 그런데 창고가 도서관 크기라면 어떨까요. 사내 위키 수천 페이지, 논문 수만 건, 고객 문의 기록 수십만 건. 필요한 정보가 그 안 어딘가에 있는 건 확실한데, 통째로 컨텍스트에 실을 수는 없습니다.
이럴 때 쓰는 기법이 RAG(Retrieval-Augmented Generation, 검색 증강 생성)입니다. 질문이 들어오면 먼저 창고에서 관련 조각을 검색하고, 찾은 조각 몇 개만 컨텍스트에 올려 답을 만들게 하는 구조예요. 검색은 보통 임베딩(embedding)이라는 기법을 씁니다. 텍스트를 의미 공간의 좌표로 바꿔두면 “환불 규정”이라는 질문과 “결제 취소 정책”이라는 문서가 표현은 달라도 가까운 좌표에 놓여서 키워드가 안 겹쳐도 찾아낼 수 있습니다.
한동안 RAG는 긴 문서를 다루는 유일한 정답처럼 여겨졌는데, 코딩 에이전트 쪽에서는 재미있는 반전이 있었습니다. 도구를 쓸 수 있는 에이전트는 임베딩 검색 없이도 grep과 파일 탐색을 반복하며 필요한 코드를 꽤 잘 찾아낸다는 게 확인된 거예요. 그래서 요즘 실무 감각은 하이브리드입니다. 정확한 식별자가 있는 코드는 에이전트의 직접 탐색이 강하고 표현이 제각각인 자연어 문서 더미는 임베딩 검색이 강합니다. 어느 쪽이든 “전부 싣지 말고, 질의 시점에 관련분만 실어라”라는 원칙은 같습니다.
정리
- 컨텍스트는 작업대, 파일은 창고입니다. 세션이 끝나도 남아야 할 지식은 컨텍스트가 아니라 파일로 내려보내는 게 기본기입니다.
- 계획 파일은 긴 작업을 세션 리셋에서 살려내고, 목표를 컨텍스트 최근 위치에 반복 노출해 이탈을 막습니다.
- 메모리에는 파생 불가능한 정보만 적고, 인덱스만 상시 로드하며, 낡은 항목은 갱신·삭제 규칙으로 관리합니다.
- 창고가 아주 크면 RAG로 질의 시점에 관련 조각만 올립니다. 코드는 직접 탐색, 자연어 더미는 임베딩 검색이 강합니다.
이제 시리즈의 마지막 편이 남았습니다. 지금까지는 품질을 위해 컨텍스트를 관리했는데, 마지막은 돈 이야기입니다. 같은 컨텍스트라도 어떻게 쌓느냐에 따라 API 비용이 몇 배씩 달라지는 프롬프트 캐시의 원리, 그리고 컨텍스트 앞부분을 함부로 건드리면 안 되는 이유를 다룹니다.