토큰 효율을 쥐어짜는 세 갈래가 같은 주에 쏟아졌습니다

모델이 코드를 아직 쓰고 있는데, 하네스는 벌써 툴을 발사합니다. CPU 설계의 오래된 기술인 투기 실행을 에이전트 하네스에 가져온 연구, sPTC(Speculative Programmatic Tool Calling)입니다. 발표 하루 만에 조회 18만을 넘겼어요.

같은 시기에 Pi 코딩 에이전트의 컨텍스트 압축을 놓고는 커뮤니티 플러그인 다섯 개가 각자 다른 답을 들고 나왔습니다. 이 판을 정리한 중국어권 개발자의 글이 하루 만에 조회 2만을 넘겼고요.

그리고 지난 주말, firstmate라는 오케스트레이터를 만드는 개발자 Kun Chen이 에이전트가 바빠서 주인 말을 못 듣는 병의 진단과 처방을 함께 공개했습니다. 공개 하루 만에 조회 5만을 넘겼습니다.

컨텍스트 토큰, 툴 대기 시간, 세션 구조. 방향은 셋인데, 쥐어짜는 대상은 하나예요. 에이전트를 오래 굴릴 때 새는 자원입니다.

컨텍스트 압축을 놓고 왜 유파가 다섯 개나 생겼나요?

Pi 본체의 압축 로직은 한 줄이에요. 컨텍스트가 거의 차면 → 옛 대화를 요약하고 → 최근 것만 남기고 → 계속 간다.

단순해서 좋지만, 커뮤니티는 이 단순함에 만족하지 않았습니다. 그래서 유파가 다섯으로 갈라졌어요.

**망각파(pai-acp)**는 컨텍스트가 찰 때까지 기다렸다가 뭉텅이로 누르는 대신, 어떤 기록이 더는 가치가 없는지 AI가 스스로 판단해 미리미리 접습니다. 필요하면 검색해서 복원할 수도 있어요. 잊는 것도 능력이라는 입장입니다.

**메모파(pi-smart-compact)**는 현재 목표, 고친 파일, 에러, 핵심 결정, 미완 과제를 우선 보존합니다. 자기 자신에게 남기는 쪽지에 가까워요. 지금 하던 일이 안 끊기는 게 최우선.

**깃파(pi-context)**는 컨텍스트를 깃 레포처럼 다룹니다. 체크포인트를 찍고, 타임라인을 보고, 돌아갈 지점을 골라 선택적으로 누릅니다. 기억을 버전 관리 대상으로 승격시킨 발상이에요.

**결벽파(Hypa)**의 주장은 이렇습니다. 최고의 압축은 쓰레기를 애초에 안 들이는 것. 컨텍스트가 찬 다음에 누르는 것보다, 들어올 때 거르는 게 토큰이 덜 든다는 거죠.

**선행파(pi-press)**는 압축을 앞당깁니다. 임계에 가까워지면 미리 요약을 만들어 두고, 진짜 눌러야 할 때 바로 갈아탑니다. 압축되는 동안 에이전트가 멈추는 시간을 줄이는 거예요.

정리자의 결론은 담백합니다. 적시에, 옳은 일을 하라. 다만 핵심 질문은 여전히 풀리지 않았어요. 에이전트 기억이란 대체 무엇인가. 아직 결론이 없다는 게 정직한 답입니다.

sPTC는 어떻게 툴 대기 시간을 없애나요?

저자 Alex Zhang의 문제 인식부터 정확합니다. "서브에이전트나 검색 API 같은 LLM 툴은 대개 고지연이고, 코드 실행형 하네스에서 보통 병목이다."

지금 하네스들의 순서는 이렇습니다. 모델이 코드를 끝까지 생성한다 → 하네스가 그 코드를 실행한다 → 툴을 부른다 → 기다린다. 토큰 생성 시간과 툴 대기 시간을 따로따로 전부 내는 구조예요.

sPTC의 답은 CPU가 수십 년 전에 찾은 답과 같습니다. 미리 짐작하고 먼저 달려라. 모델이 코드를 스트리밍하는 동안, 하네스가 부분적으로 완성된 코드를 파싱해서 툴 호출을 미리 읽어내고 먼저 발사합니다. 결과는 캐시에 담아두고, 실제 실행이 그 지점에 도달하면 즉시 반환해요.

코드 생성이 끝날 즈음엔 툴 결과가 이미 도착해 있는 겁니다. 덤도 있습니다. 코드에 비동기로 안 적혀 있어도, 서로 독립인 서브에이전트 호출들을 병렬로 실행해줍니다. 저자 표현으로는 "아주 순진한 JIT 컴파일러"처럼요.

함부로 미리 실행하면 사고가 나니까, 투기 실행의 고전적 문제에 대한 장치도 뒀어요. 그림자 REPL은 실제 실행 환경의 복제본에서만 미리 돌리고 실제 상태는 절대 안 건드립니다. 부작용 차단은 파일 열기처럼 되돌릴 수 없는 함수를 투기 대상에서 제외하고, 순수 함수만 안전하다고 표시된 의존성만 미리 계산합니다.

수치가 정직합니다. 연구 환경(RLM 벤치마크)에서 1~1.2배, 좋은 예시에서 2.4배. 저자 스스로 "정확한 추정은 어렵다"고 못 박았습니다. 툴 지연, 토큰 수, 서빙 부하에 다 달려 있다고요.

엄청난 가속이 아니라, 어차피 버려지던 시간을 공짜로 줍는 기법이라는 프레임입니다. 과장이 없어서 더 믿음이 가는 쪽이에요.

멀티브레인은 왜 뇌를 둘로 쪼개나요?

에이전트를 오래 굴려본 사람만 만나는 병이 있습니다. 에이전트가 바빠서 내 말을 못 듣는 상태.

시작은 백그라운드 루프입니다. PR을 하나 돌보게 시키면, 에이전트는 5분마다 확인해야 합니다. CI가 깨졌나. 사람 피드백이 달렸나. 이 루프 하나는 아무 문제가 없어요.

문제는 이런 루프가 쌓일 때입니다. PR 셋을 돌보고, 배포를 감시하고, 함대의 다른 에이전트 보고를 받는 순간부터 에이전트의 하루는 이벤트 판정으로 가득 찹니다. 그러다 주인이 말을 걸면, 줄 서서 기다려야 하는 거예요.

Kun Chen이 여러 접근을 실험한 끝에 도달한 구조가 멀티브레인입니다. 에이전트 하나가 세션 두 개를 병렬로 돌립니다. 메인 세션은 사용자와 대화하는 뇌, 백그라운드 세션은 루프 이벤트만 받는 뇌예요. 더 싼 모델을 써도 됩니다.

뒤쪽 뇌가 하는 일은 판정 하나입니다. 이 이벤트로 메인을 깨울 것인가, 말 것인가.

백미는 버리지 않고 병합한다는 점이에요. 깃 브랜치 머지처럼요. 안 깨우기로 한 이벤트는 메인 세션에 병합돼서, 메인이 다음 턴을 잡을 때 자연스럽게 읽힙니다. 조용히 사라지는 이벤트가 없어요. 사람 주의가 필요한 이벤트는 메인을 즉시 깨웁니다.

반대 방향도 흐릅니다. 메인 세션의 사용자·에이전트 메시지(툴콜 제외)가 백그라운드 세션에 병합돼요. 판정하는 뇌가 주인의 의도를 알고 판정하게 됩니다.

돈 계산까지 돼 있습니다. 이 병합 과정에서 양쪽 세션의 프롬프트 캐시를 깨지 않아요. 캐시가 살아 있으니 요청 비용이 계속 쌉니다.

결과는 제작자 표현으로 "꽤 놀랍다"예요. 루프를 잔뜩 돌리면서도 메인 에이전트는 언제든 사용자 응대가 가능한 상태.

Pi 위에서 구현한 이유도 한 줄로 남겼습니다. "이걸 매끄럽게 할 수 있는 메인스트림 하네스는 사실상 Pi뿐이다. 깊은 커스터마이즈 가능성 덕분에." 자기 하네스를 직접 만드는 사람도 이 구조를 적용할 수 있다며 아키텍처 도해까지 붙여 설계를 공개했고요.

세 갈래는 어디서 만나나요?

압축 유파는 컨텍스트 토큰을 아낍니다. sPTC는 토큰 생성 시간과 툴 대기 시간이 따로 나가던 구조를 겹쳐서, 버려지던 시간을 줍습니다. 멀티브레인은 프롬프트 캐시를 지키면서 판정에 더 싼 모델을 배정합니다.

셋 다 모델이 아니라 하네스 쪽에서 자원을 캐는 작업이에요. 모델 속도는 모델 회사의 일이지만, 하네스 안의 낭비 시간은 하네스 만드는 사람의 일입니다.

sPTC가 나온 곳도 눈에 익습니다. 잠들지 않는 에이전트 헤드롱과 같은 Laude 연구 생태계예요. 헤드롱의 shellm이 바로 재귀 언어모델(RLM)의 Bash 구현이고, sPTC는 그 RLM의 속도를 캐는 연구입니다.

이 낭비를 찾아내는 연구가 이제 하나의 장르가 되고 있어요. 클로드가 렌더러에서 체감 4배를 캐냈듯, 툴 호출 타이밍에서도 시간을 캐는 겁니다.

압축 쪽도 혼자가 아닙니다. 같은 주에 지식 위키(pi-llm-wiki), 세션 이사 도구(session-migrate), 멀티브레인 세션 분리까지 전부 이 언저리에서 나왔어요.

남는 생각

저는 유파가 다섯이나 갈라져 싸운다는 것 자체를 신호로 읽습니다.

모델 컨텍스트 창은 계속 커지는데, 에이전트를 오래 굴릴수록 창 크기로는 해결이 안 됩니다. 무엇을 기억하고 무엇을 잊을지의 문제는 용량 문제가 아니라 판단 문제라서요.

받은 이벤트를 다 처리하는 것도 성실이 아니라 병목입니다. 어떤 이벤트가 주인의 주의를 받을 자격이 있는가를 판정하는 층이 따로 필요하고, 그 판정에도 맥락이 필요하다는 것.

에이전트 하나를 쓰는 동안에는 안 만나는 문제들이에요. 그런데 에이전트가 에이전트를 부리는 순간, 모두가 만나게 될 문제입니다. 기억이, 그리고 토큰 효율이 에이전트판의 다음 격전지예요.

---

원문·소스

• 컨텍스트 압축 유파 정리: @xiaomovps 2026-08-25 X 게시물 (전문·도해 2장, 인용트윗 Pi 토큰 절약 5수)
• sPTC 블로그 원문: https://alexzhang13.github.io/blog/2026/spec-ptc/
• sPTC 발표 트윗: @a1zhang
• 멀티브레인 하네스 공개: @kunchenguid 2026-08-25 X 게시물 (원문·도해), firstmate