모델이 자기 컨텍스트를 직접 관리하게 하는 건 ‘쓴 교훈(The Bitter Lesson)’에 충실한 접근임.
가장 큰 난관은 에이전트의 컨텍스트나 접두부를 자주 수정하면 캐시 적중률이 크게 떨어진다는 점임. 따라서 Anthropic API 같은 방식으로는 효율적으로 구현하기 어려움. 원리적으로 해결할 수 있지만, 트랜스포머 아키텍처 수정이 필요할 가능성이 높고 서빙 인프라 수정은 확실히 필요함.
관련 글: “KV Cache Rules Everything Around Me”: https://www.completeskeptic.com/p/kv-cache-rules-everything-....
컨텍스트 관리가 제한된 주의 자원을 소모한다는 점이 우려됨. 에이전트가 자기 기억 용량 문제를 해결하게 할 것인지, 실제 작업을 해결하게 할 것인지의 문제임. 둘을 동시에 할 수는 있겠지만, 무시하기 어려운 비용이 들 것으로 보임.
내 경험으로는 주 에이전트의 컨텍스트를 관리하는 별도 감독 에이전트를 두는 편이 훨씬 나음. 별도 주기로 실행할 수 있고, 주 에이전트는 컨텍스트 관리를 고민하는 데 토큰을 전혀 쓰지 않아도 됨. 캐시 미스가 발생하는 시점도 훨씬 쉽게 제어할 수 있음.
이 기법은 지금도 아무 모델에나 적용할 수 있지 않나? 파일을 다음 컨텍스트로 보내면 됨. 물론 얼마나 앞부분까지 수정하느냐에 따라 캐시 미스 비용을 내야 하는데, CLM은 그 재계산을 그냥 무시함.
아직 공개되지 않은 Codex의 실험적 컨텍스트 관리가 이와 비슷한 방향으로 가고 있음. 요약 압축에 의존하는 대신, 모델이 작업 중이나 컨텍스트 한도에 가까워질 때 메모를 유지함. 새 세션은 그 메모와 이전 세션을 가리키는 참조를 첨부한 새 컨텍스트로 시작함.
논문의 제안과 정확히 같지는 않지만, 턴 사이에 무엇을 어떻게 보존할지 모델이 결정한다는 점에서 비슷함. 이를 Pi에서 재현하면서 메모에 최대 토큰 한도를 두어 간결하게 쓰도록 유도했는데, 요약 압축보다 비용도 적게 듦.
내 맞춤형 코딩 실행 환경에서도 이런 식으로 작동하는 파일 시스템 도구를 만들었고, 요청당 한 턴만 실행할 예정인 다른 환경에서도 다시 구현 중임. 가장 자주 바뀌는 내용을 뒤쪽에 배치하면 캐시도 꽤 잘 활용할 수 있음.
컨텍스트 관리는 현대 LLM에 남아 있는 큰 골칫거리 중 하나라서, 이 접근의 파급력이 클 수 있음. 명백한 난관은 캐시 무효화인데, 그 해결책까지 연구했다니 기대됨.
가장 큰 발견은 오히려 일반적인 캐싱 규칙을 무시하고 유효하지 않은 캐시 뒷부분을 유지해도 성능이 떨어지지 않았다는 점일 수 있음.
회전 위치 인코딩 처리까지 통째로 생략하고, 직접 변경된 캐시 부분만 정확히 덮어쓰면 성능이 얼마나 나빠질지 궁금함. 모델이 망가지거나 혼란스러워질까? 아니면 내부적으로 보정할까?
결국 CLM은 실제 작업 모델과 공동 학습하는 별도 모델이 되지 않을까? 데이터베이스에서 자주 쓰는 페이지와 드물게 쓰는 페이지를 나누듯, 컨텍스트도 여러 개로 나뉠 것 같음.
그런 의미에서 1년 안에 “Context as a DB”라는 논문이 나올 것으로 예상함.
나도 처음엔 비슷하게 느꼈지만, 초록을 제대로 쓰지 못한 것 같음. 실제로 한 작업은 agents.md를 재발명하는 수준보다 훨씬 깊어 보임.
컨텍스트를 파일로 취급하고 모델이 자유롭게 수정하게 하면, 무엇을 유지해야 하는지 학습할 수 있고 여러 에이전트의 컨텍스트가 파일로 공존하는 구조로도 확장된다고 함.
그렇다면 LLM용 RAM 같은 것인가? LLM을 위해 MMU와 그에 딸린 모든 추상화까지 다시 발명해야 하는 건가?
이번에는 컨텍스트 관리에서 쓴 교훈(The Bitter Lesson) 이 또 드러나는 건가?