pi-optchat: 더 이상 압축은 없다 - 메모리 트리 형태의 무한 채팅

맞아. 프로필당 채팅 하나씩이고 절대 안 지워져. 난 '업무용'이랑 '개인용' 하나씩 있는데, 둘 다 끝없는 세션 하나로 유지 중이야. 업무용은 메시지가 수만 개 쌓여있는데(예전 Claude Code랑 Codex 세션에서 다 가져옴), 그냥 계속 거기다 타이핑하는 중이야 :)

맞아, 같은 맥락이야. 난 RLM을 정말 좋아해!
모델이 전체 기록을 다 불러오는 게 아니라, 작은 뷰를 보고 필요할 때 더 깊게 파고들 수 있는 도구를 쓰는 거지. 차이점은 RLM은 매번 추론할 때마다 원본 데이터 위에서 재귀적으로 수행한다는 거야. OptChat은 메시지가 들어올 때마다 증분 방식으로 트리를 미리 계산해둬. 각 줄이 들어올 때 요약되고, 쌍끼리 합쳐져서 저장되지. 그래서 질문을 던질 때 이미 '개요'가 존재하고 캐싱되어 있는 상태야. RLM의 아이디어를 질문할 때마다 비용을 내는 게 아니라, 채팅하는 내내 분할 상환한다고 생각하면 돼 :D

맞음, 순전히 시간순이고 영리한 주제 인덱싱은 없음. 데이터베이스라기보다는 오늘에 가까워질수록 더 상세해지는 목차가 있는 책이라고 생각하면 됨.

모든 메시지는 잎사귀임. 이웃한 쌍들은 하나의 요약으로 병합되고, 그 쌍들은 더 큰 요약으로 병합되는 식으로 루트까지 올라감. 각 턴 시작 시 에이전트가 보는 것은 그 트리의 단면임: 고대 역사는 몇 개의 굵직한 요약으로, 지난주는 더 세밀한 줄로, 지난 한 시간은 거의 원문 그대로 보임.
주제별로 무언가를 찾으려면 모델은 그냥 그 개요를 읽음. 요약에는 '배포 파이프라인 설정, Postgres와 SQLite 사이에서 논쟁, 결국 SQLite로 결정'처럼 무슨 일이 있었는지 적혀 있어서, 적절한 줄을 발견하면 zoom을 호출함. 그러면 그 줄이 구성된 두 개의 절반으로 열림. 몇 번 zoom을 하면 원본 메시지를 읽게 됨. 기본적으로 이진 탐색인데, 키 대신 요약이 이정표 역할을 하는 거임. '언제 X에 대해 이야기했지?'와 '그 주변 문맥은 뭐였지?'가 같은 질문이기 때문에, 트리에서 이웃한 것들은 시간상으로도 이웃해서 대부분의 경우 이걸로 충분함. PR 번호나 에러 문자열 같은 정확한 정보를 위해서는 원본에 대한 선택적 일반 텍스트 검색도 가능함. 물론 모든 툴 호출과 턴마다 요약하는 게 딱히 저렴하다고는 할 수 없다는 게 단점임.

흥미로워 보이는데, 몇 가지 명확하지 않은 점이 있음. 설명에 있었는데 내가 놓친 거라면 미안:

1. 서브에이전트가 항상 백그라운드에서 실행되는 거지? 이전 메시지를 더 압축하고 사용자가 보낸 프롬프트에 과거 문맥의 짧은 요약을 주입한다는 내 이해가 맞음?

2. 왜 'subagents'라고 복수형을 씀? 각 작업이 별도의 단기 서브에이전트라는 뜻임?

3. 이게 접두사 캐싱에 얼마나 영향을 줌?

좋은 질문들임. 포스트에서 아주 명확하게 설명하지 못한 것 같네.

1. 백그라운드 프로세스: 맞음, 하지만 서브에이전트가 아니라 그냥 요약기임. 네가 보내거나 받는 모든 메시지는 기록되고, 더 작은 모델(기본적으로 Sonnet)이 백그라운드에서 512바이트 요약 줄로 변환함. 이웃한 줄들은 하나로 병합되고, 그 쌍들은 더 큰 것으로 병합되는 식임. 이건 추가 전용(append-only)이라 아무것도 다시 쓰이지 않고 트리는 위로 자라기만 함. 최대 8개가 병렬로 실행되니까 활동이 몰린 후 몇 초 안에 따라잡고 나머지는 유휴 상태임.

이거 써봐야겠다! 공유해줘서 고마워, VRAM 낮은 나한테 딱 필요한 거 같아.

그러니까 기본적으로 https://arxiv.org/abs/2512.24601이랑 같은 트릭이네. RLM이랑 똑같이 결국 아무 성과도 없을 거야. 왜냐면 결국 '컨텍스트 문제'를 '검색 문제'로 치환하는 것뿐이니까. 중요한 정보는 다 모호함의 바다 속으로 사라질걸.

게다가 RLM이 네 구현체보다 훨씬 나은데, 그것조차 실패한다면 안 좋은 소식이 있네.

비난하려는 건 아니고, 다들 시간 낭비하지 말라고 하는 소리야. 이런 건 문헌에서도 이미 시도된 적이 있고, 주류가 되지 못한 데에는 다 이유가 있어.