얼마 전 AMCP 관련 글을 올렸습니다.
그 글을 올리고 보니, 그 전에 먼저 설명했어야 하는 이야기가 하나 있었습니다. 바로 에이전트가 실제로 컨텍스트를 어떻게 다루고, 왜 대화가 길어질수록 흔들리기 시작하는가 입니다.
요즘 많은 분들이 “컨텍스트 윈도우가 100만 토큰이면 사실상 다 기억하는 것 아닌가?”라고 생각합니다. 그런데 실제로 코딩 에이전트를 오래 써보면 꼭 그렇지만은 않습니다.
오히려 세션이 길어질수록,
- 갑자기 중요한 맥락을 놓치고
- 방금 전에는 알던 설정을 다시 묻고
- 조금 전까지 잘하던 작업 흐름을 잃고
- 결국 새 세션을 열게 되는 경험을 자주 하게 됩니다
왜 이런 일이 생길까요?
1. 대화가 길어질수록 보내는 양은 계속 커집니다
우리가 흔히 채팅하듯 질문을 주고받는다고 해도, 모델에 실제로 전달되는 정보는 생각보다 훨씬 큽니다.
예를 들어:
- 질문 1을 하면 → 질문 1이 전송됩니다
- 질문 2를 하면 → 질문 1 + 답변 1 + 질문 2가 전송됩니다
- 질문 3을 하면 → 질문 1 + 답변 1 + 질문 2 + 답변 2 + 질문 3이 전송됩니다
이런 식으로 대화가 이어질수록, 현재 질문만 보내는 것이 아니라 지금까지의 대화 묶음 전체가 다시 같이 전송됩니다.
그래서 컨텍스트 윈도우가 아무리 커 보여도, 중간에 200줄짜리 에러 로그 하나만 들어와도 사용 가능한 여유는 생각보다 빠르게 줄어듭니다.
중요한 점은, 컨텍스트 윈도우가 크다는 것과 항상 안정적으로 필요한 정보를 유지한다는 것은 같은 말이 아니라는 점입니다.
2. 코딩 에이전트의 컨텍스트는 보통 세 층으로 이뤄집니다
실제로 코딩 에이전트의 컨텍스트는 대체로 세 개의 레이어로 생각할 수 있습니다.
레이어 1. 모델 제공자가 넣어둔 시스템 프롬프트
예를 들면 Claude, OpenAI, Google 같은 모델 제공자가 기본 동작을 위해 넣어둔 시스템 수준 지침입니다.
사용자는 이 레이어를 직접 제어하기 어렵습니다.
레이어 2. 사용자가 중요하다고 생각해 넣은 지속 컨텍스트
예를 들면:
CLAUDE.mdAGENTS.md.cursorrules- 팀 규칙
- 프로젝트 구조 설명
- 작업 방식
이 레이어는 “이 작업을 어떤 방식으로 해야 하는가”를 알려주는 중요한 맥락입니다.
레이어 3. 현재 세션에서 쌓인 질문과 답변
이 레이어가 가장 빠르게 커집니다.
- 질문
- 답변
- 에러 로그
- 수정 요청
- 재질문
- 도구 실행 결과
이런 것들이 계속 누적됩니다.
3. 우리가 실제로 제어할 수 있는 것은 2번과 3번입니다
문제는 여기서 시작됩니다.
사용자가 실질적으로 컨트롤할 수 있는 것은:
- 레이어 2: 지속 컨텍스트
- 레이어 3: 세션 중 대화 내용
그런데 모델은 긴 입력을 완전히 균등하게 다루지 않습니다. 대체로 앞부분과 뒷부분의 영향이 상대적으로 크고, 중간에 끼어 있는 정보는 약해지기 쉽습니다.
그래서 이런 현상이 생깁니다.
- 방금 한 질문에는 잘 반응합니다
- 하지만 중간에 들어 있는
CLAUDE.md,AGENTS.md,.cursorrules같은 중요한 지침은 무시되기 쉽습니다 - 심지어 “아까 환경변수 이름이 뭐였지?”처럼 아주 단순한 질문에도, 그 질문 하나만 가는 것이 아니라 위의 세 레이어가 다시 묶여 전송됩니다
즉, 사소한 질문 하나도 전체 컨텍스트 비용 위에 올라타게 됩니다.
이게 쌓이면 결국:
- 컨텍스트가 빠르게 찹니다
- 오래된 정보는 잘리거나 약하게 압축됩니다
- 일부 정보는 손실된 채로 재구성됩니다
- 모델이 슬슬 헛소리를 하기 시작합니다
- 결국 새 세션을 열게 됩니다
4. 그런데 새 세션을 열면 기억은 끊깁니다
새 세션을 열면 보통 문제가 하나 해결됩니다.
바로 세션이 가벼워진다는 점입니다.
하지만 동시에 더 큰 문제가 생깁니다.
이전 세션의 중요한 맥락이 사라집니다.
예를 들면:
- 어떤 방향으로 구현하기로 했는지
- 어떤 제약을 두기로 했는지
- 사용자가 싫어하는 방식이 무엇인지
- 이미 한 번 실패했던 접근이 무엇인지
- 이 프로젝트에서 중요한 규칙이 무엇인지
이런 것들은 사실 다음 세션에도 계속 살아 있어야 합니다. 그런데 지금 대부분의 시스템에서는 이 정보가 세션이 끝나면서 같이 사라지거나, 특정 제품 내부 메모리에만 갇혀 있습니다.
5. 그래서 필요한 것이 “대화”가 아니라 “기억”입니다
여기서 구분해야 하는 것이 있습니다.
에이전트에게 필요한 것은 단순히 긴 대화 기록이 아닙니다. 정말 필요한 것은 그 대화에서 중요한 것만 따로 남기는 기억 계층입니다.
예를 들어:
- 사용자의 선호
- 프로젝트 규칙
- 중요한 결정
- 실패한 시도와 해결 방법
- 다음 세션에도 살아 있어야 하는 작업 맥락
이런 것들은 전체 대화 로그와는 다릅니다. 오히려 전체 로그에서 추려낸 지속 가치가 있는 정보에 가깝습니다.
즉,
- 모든 대화를 영원히 다시 보내는 것이 아니라
- 중요한 것만 구조화해서 저장하고
- 다음 세션이나 다른 에이전트가 필요할 때 다시 꺼내오는 구조
가 필요합니다.
6. Nexus는 그 기억 계층을 만들기 위해 만들었습니다
저희가 만든 Nexus는 바로 이 문제를 풀기 위한 메모리 인프라입니다.
핵심은 이겁니다.
- 중요한 대화 내용을 구조화해서 저장하고
- 세션이 바뀌어도 다시 불러오고
- 심지어 Claude Code에서 Codex로, 또는 다른 클라이언트로 옮겨가더라도
- 필요한 기억을 이어서 가져올 수 있게 하는 것
즉 Nexus는 “지금 대화창 안에만 갇혀 있는 컨텍스트”를 세션 밖으로 꺼내서 관리 가능한 기억으로 바꾸는 계층입니다.
7. 그리고 그 저장과 이동을 위한 표준이 필요했습니다
여기서 자연스럽게 다음 질문이 생깁니다.
“그럼 이 메모리 저장 방식도 특정 제품 안에만 갇히면 결국 같은 문제 아닌가?”
맞습니다. 그래서 메모리 저장과 이동에도 공개된 표준이 필요하다고 봤습니다.
그 결과 제안한 것이 AMCP(Agent Memory Continuity Protocol) 입니다.
AMCP는 에이전트 메모리에 대해 최소한의 공통 계약을 제시합니다.
- 어떤 shape로 저장할지
- 어떻게 recall 할지
- 어떤 scope를 가질지
- retention과 delete를 어떻게 다룰지
- 다른 시스템으로 어떻게 export / import 할지
이 표준이 있으면, 기억이 특정 모델 회사나 특정 제품 안에만 갇히지 않고 다른 구현체와 런타임으로도 이동할 가능성이 생깁니다.
8. 정리하면
에이전트가 흔들리는 이유는 단순히 모델이 멍청해서가 아닙니다.
문제는:
- 대화가 길어질수록 매번 보내는 양이 커지고
- 중요한 지침은 긴 컨텍스트 안에서 묻히기 쉽고
- 새 세션을 열면 과거 맥락이 끊긴다는 점입니다
그래서 필요한 것은 더 긴 대화창이 아니라, 중요한 것을 분리해서 저장하고 다시 가져올 수 있는 기억 계층입니다.
그리고 그 기억 계층을 특정 제품 종속이 아니라 공개된 방식으로 다루기 위해 Nexus와 AMCP를 만들고 있습니다.
관심 있으시면 아래에서 이어서 보실 수 있습니다.