100K 컨텍스트면 충분하다: 더 큰 창을 사는 대신 기억을 압축하기

창 크기가 문제가 아니다

몇 달에 한 번씩 어떤 랩이 더 큰 컨텍스트 창을 가진 모델을 내놓고, 대화는 리셋된다. 20만 토큰, 그다음 100만, 그다음 200만. 은근한 약속은 이렇다. 기억은 하드웨어 문제이고, 누군가 계속 키워줄 것이다.

billion-context는 ranxianglei가 만든 TypeScript 프로젝트로, 9월 말부터 순위가 계속 올라왔다. 이 프로젝트의 슬로건은 정반대 입장을 취한다. 100K 컨텍스트면 충분하다. "지금은 충분"이 아니다. 충분하다. 대화를 덧붙이기만 하는 로그로 취급하지 않는다면.

코딩 에이전트와 모델 API 사이에 앉는 프록시다. 요청이 여기를 지나 압축되고 전달된다. 응답은 돌아오는 길에 다시 쓰인다. 모델 쪽은 아무것도 바뀌지 않는다. 비싼 건 애초에 창 크기가 아니라, 우리가 계속 그 안에 밀어 넣던 것이라는 주장이다.

압축은 어떻게 작동하나

프록시는 각 요청을 Anthropic 또는 OpenAI 형식으로 파싱하고, 대화 전체에 압축 커널을 돌린 뒤, 모델이 스스로 호출할 수 있는 도구 네 개를 주입한다. 메시지 범위를 요약으로 압축하기, 정확한 세부가 다시 필요할 때 범위를 압축 해제하기, 압축된 요약과 보이는 메시지를 키워드로 검색하기, 컨텍스트 사용량 확인하기.

중요한 설계 선택은 언제 압축할지를 모델이 스스로 정한다는 점이다. 고정 임계값이 아니다. 호스트에 내장된 요약기는 보통 창이 꽉 찰 때 작동해서, 잘라낸 지점 이전의 모든 것을 되돌릴 수 없는 요약 하나로 바꾼다. billion-context는 작은 범위로 압축하고, 되돌릴 수 있게 유지하며, 프리픽스 캐시를 그대로 둔다.

마지막 부분이 신경 써야 할 엔지니어링 디테일이다. 프리픽스 캐시가 있어야 긴 에이전트 세션을 감당할 수 있다. 압축할 때마다 대화 앞부분을 다시 쓰면 캐시가 빗나가고, 전체 히스토리에 대해 다시 정가를 지불한다. 프로젝트는 건강한 세션이면 프리픽스 캐시 적중률이 95-97%로 유지되고, 압축 자체의 오버헤드는 2%를 넘지 않는다고 주장한다. 모두 자체 보고 수치이고, 적중률 하락을 원인에 귀속시키는 명령도 함께 제공한다. 원인은 대개 업스트림 캐시 TTL 만료이거나 모델 교체다.

이 주장을 믿게 만드는 숫자

벤더들은 늘 토큰 절감을 외친다. 여기서 특이한 건 코드와 함께 묶인 종단 연구다. 4개월 반, 호스트 3개, 모델 호출 174,327회, 호스트 하나에서 누적 입력 토큰 18.76B, 전체로는 약 24.7B. 보고서에 따르면 가장 긴 세션은 8,584회에서 12,049회 호출까지 이어졌고, 204,800 토큰 모델에서 컨텍스트 창 위반은 0건이었다.

중요한 문장은 "창 위반 0건"이다. 대화가 모델보다 커져서 죽은 세션이 하나도 없다는 뜻이니까. 연구의 나머지 모든 것은 그 문장의 하류에 있다.

"긴 세션"의 의미도 바뀐다. 대부분은 컨텍스트 한계를 서서히 나빠지는 것으로 경험한다. 에이전트가 점점 흐릿해지고, 두 시간 전의 제약을 잊고, 이미 읽은 파일을 다시 읽기 시작한다. 창이 실제로 꽉 찰 때쯤이면 세션은 이미 한참 나빠져 있다. 계속 돌아가는 압축이 다루는 건 그 열화이지, 딱 멈추는 지점만이 아니다.

당신의 워크로드에서 광고대로 작동하는지는 별개의 문제다. 주장은 자기 보고이고, 벤치마크는 저자 자신의 사용량이며, "토큰 5분의 1"은 세션이 얼마나 반복적인지에 전적으로 달려 있다. 파일 40개를 읽고 세 군데를 고치는 세션은 아름답게 압축된다. 거대한 파일 하나를 읽고 줄 단위로 추론하는 세션은 접을 중복이 훨씬 적다.

일상 루프에서 달라지는 것

실질적인 차이는 긴 작업의 지루한 중반부에서 드러난다. 리팩터링을 하는 에이전트에게는 세 종류의 기억이 있다. 무엇을 결정했는지, 무엇을 읽었는지, 무엇을 시도했다 버렸는지. 원본 트랜스크립트는 이 셋을 같은 해상도로 유지한다. 그래서 파일 40개짜리 리팩터링이 이제는 상관없는 스택 트레이스로 창을 채운다.

압축을 쓰면 에이전트는 결정을 원래 해상도로 남기고, 근거는 요약으로 접고, 필요할 때만 정확한 줄로 돌아간다. 사람이 일하는 방식과 거의 같다. 검증을 미들웨어로 옮겼다는 건 기억하지만, 처음에 실패한 여섯 번의 시도는 기억하지 못한다.

실패 방식도 인간적이다. 요약이 유일하게 중요했던 제약, "이 엔드포인트는 하위 호환성을 유지해야 한다"를 떨어뜨리면, 에이전트는 40분 뒤에 아주 유쾌하게 그것을 깨뜨린다. 압축 레이어는 비용을 아껴주고 그 대가로 버그 하나를 얹어준다. 이걸 견딜 만하게 만드는 것이 되돌림 가능성이다. 압축을 풀어서 요약이 실제로 뭐라고 했는지 확인할 수 있다.

왜 지금 하나의 카테고리인가

같은 문제를 두고 적어도 세 가지 접근이 경쟁한다. 하나는 랩의 답, 더 큰 창을 만드는 것. 다른 하나는 하네스의 답, 기억하는 대신 검색하고 컨텍스트에는 작업 세트만 두는 것. 세 번째가 billion-context가 대표하는 것으로, 대화를 유지한 채 그 자리에서 되돌릴 수 있게 압축하는 것이다.

트레이드오프는 실재한다. 더 큰 창은 가장 단순하고 가장 통제하기 어렵다. 히스토리가 관련 있든 없든 매 호출마다 비용을 낸다. 검색은 가장 싸지만 연속성을 잃는다. 에이전트가 자기가 무엇을 잊었는지 모르기 때문이다. 제자리 압축은 연속성과 비용을 동시에 잡으려 하고, 그 대가로 당신의 요청 경로 안에 앉는다.

생각해볼 것은 마지막 비용이다. 중간에 끼는 프록시는 모든 프롬프트와 모든 완성을 본다. 1인 개발자에게는 괜찮다. 데이터 취급 규정이 있는 회사에서는 컴플라이언스 대화가 되고, "소스 읽어봤는데 괜찮습니다"는 감사와 같지 않다.

라이선스라는 작은 문제도 있다. 기술 논문은 MIT이고 저장소에 들어 있다. 저장소 자체의 라이선스는 표준 OSI 라이선스가 아니라 "Other"로 보고된다. 회사 안에 배포한다면 이 구분은 반드시 나온다.

불편한 함의

압축이 충분히 잘 작동해서 100K면 충분하다면, 컨텍스트 창 마케팅의 상당 부분은 소프트웨어로 더 싸게 풀 수 있는 문제를 겨냥하고 있는 셈이다. 그렇다고 큰 창이 무용해지지는 않는다. 400페이지짜리 문서 하나는 어딘가에 들어가야 한다. 다만 "우리는 100만 토큰이 있다"는 말이 들리는 것보다 약한 세일즈 포인트라는 뜻이다. 연비 대신 더 큰 연료 탱크를 광고하는 것과 같다.

에이전트를 어떻게 써야 하는지도 바뀐다. 기억이 압축 가능하다면, 에이전트가 배운 것을 구조화된 형태로 적어두도록 유도해야 한다. 구조화된 메모는 원본 로그보다 훨씬 잘 압축된다. "인증 미들웨어는 테넌트를 쿠키가 아니라 header에서 읽는다"는 한 줄이 스택 트레이스 천 줄의 값어치를 한다. 압축 레이어는 좋은 기록 습관에 보상을 준다. 도구로서 좋은 성질이다.

이 프로젝트는 별 1천 개가 넘고, npm 월간 다운로드는 약 400,000, 20개가 넘는 클라이언트 배지가 붙어 있다. 취미 규모의 설치 기반이 아니다. 문제가 실제이고 널리 공유된다는 것, 그리고 사람들이 손을 뻗는 답이 창 크기 뒤에 0을 하나 더 붙이는 것이 아니라는 것을 보여준다.

어떤 도구를 쓰든 그게 쓸 만한 결론이다. 컨텍스트는 용기가 아니라 예산이다. 그렇게 다루는 팀은 달러당 더 많은 일을 하고, 더 큰 창을 기다리는 팀은 "무엇이 중요한지 결정하지 않을 특권"에 계속 비용을 낸다.