긴 코딩 세션을 코딩 에이전트로 진행해 본 사람이라면 한 번쯤 '컴팩션(compaction)'을 겪었을 것이다. Pi, Claude Code, Codex 같은 도구를 오래 붙잡고 있으면 어느 순간 대화가 압축되는데, 이는 대규모 언어 모델(LLM)이 안고 있는 근본적인 제약에서 비롯된다. 이 글에서는 왜 컴팩션이 필요한지, 그리고 Pi가 이를 구체적으로 어떻게 처리하는지를 정리한다.
컨텍스트 윈도가 차오르는 구조
LLM은 응답을 만들어 낼 때 '볼 수 있는' 입력의 양이 정해져 있다. 트랜스포머 아키텍처의 특성상 한 번에 처리할 수 있는 입력 길이가 제한되며, 이 한계를 컨텍스트 윈도라고 부른다. 문제는 코딩 에이전트 세션의 입력이 계속 불어난다는 점이다. 에이전트가 LLM에 보내는 요청에는 시스템 프롬프트, AGENTS.md 같은 로딩된 파일, 도구 정의, 그리고 지금까지의 대화 기록 전체가 담긴다.
동작 방식을 따라가 보면 누적 구조가 분명해진다. 첫 요청에는 이 초기 컨텍스트와 사용자의 첫 메시지가 함께 들어간다. 여기서 한 '턴'이 시작된다. LLM이 도구 호출이 담긴 어시스턴트 메시지를 돌려주면, 에이전트 프로그램이 그 도구를 실행한 뒤 도구 결과까지 포함한 전체 대화를 다시 LLM에 보낸다. 어시스턴트가 출력을 마치면 턴이 끝난다. 사용자가 다음 메시지를 보낼 때마다 이 과정이 반복되고, 턴이 쌓일수록 대화는 계속 길어진다. 결국 기록이 컨텍스트 한계를 넘어서면 다음 요청은 '요청이 최대 크기를 초과했다'는 식의 오류로 되돌아온다.
이 지점에서 선택지는 둘로 좁혀진다. 대화를 그대로 이어갈 수 없으니 무언가를 버려야 한다. 이론적으로는 대화의 일부를 남기고 나머지를 버리는 결정론적 함수를 짤 수도 있지만, 실제 컴팩션 구현들은 대부분 LLM에게 대화 기록을 요약시키는 방식을 쓴다. 컴팩션은 기록의 일부를 압축된 표현으로 대체해, 새로운 메시지와 도구 호출이 들어갈 자리를 확보하는 작업이다.
Pi의 컴팩션은 '교대 인수인계'를 지향한다
Pi는 대화가 지나치게 길어지면 오래된 내용을 요약하되 최근 작업은 그대로 보존하는 방식으로 컴팩션을 수행한다. 컴팩션은 컨텍스트 사용량이 윈도 전체 크기에 근접할 때 자동으로 발동되며, /compact 명령으로 수동 실행할 수도 있다. 자동 컴팩션 여부는 턴이 끝난 뒤에 점검한다. 턴이 끝나기 전까지는 각 요청이 기존 프롬프트를 연장하는 형태여서 캐시된 접두부를 재사용할 수 있기 때문이다. 다만 턴 도중 컨텍스트 초과 오류를 만나면 턴 중간에도 컴팩션이 일어날 수 있다.
컴팩션 시 Pi는 최근 메시지 일부를 손대지 않고 그대로 남긴다. 남기는 메시지 수가 고정값이 아닌 이유는 설정 가능한 토큰 예산을 기준으로 삼기 때문이다. 현재 기본값인 2만 토큰은 대략 5~20턴에 해당한다. 이 절단점 이전의 메시지들은 모두 추출·직렬화되어 요약 대상이 된다.
좋은 요약의 이상적인 결과는 한 근무조가 다음 근무조에게 넘기는 인수인계 브리핑과 같다. Pi의 컴팩션 프롬프트는 기존 컨텍스트에 더 이상 유효하지 않은 내용이 많다는 전제에서 출발해, 다음 LLM 요청에 여전히 중요한 맥락만 골라 남기는 데 초점을 둔다. 그래서 Pi는 일반 대화와는 다른 형태의 요청을 컴팩션 전용으로 보낸다. 그 결과물은 컴팩션 항목으로 세션에 덧붙고, 이후 세션은 압축된 컨텍스트 위에서 계속 이어진다.
캐시가 깨지는 대가, 그리고 확장 가능성
실무 관점에서 주목할 부분은 프롬프트 캐싱과의 관계다. LLM 제공자들은 같은 대화 안에서 반복되는 요청 비용을 낮추기 위해 프롬프트 캐싱을 쓴다. 이미 모델이 생성한 컨텍스트는 다음 요청에서 더 싸게 처리된다는 뜻이다. 그런데 이 캐싱은 접두부가 정확히 일치해야 작동한다. 컴팩션은 앞부분을 요약본으로 갈아치우므로 캐시를 깨뜨린다. 남겨 둔 최근 턴들은 토큰 자체는 동일하지만 이제 다른 접두부 뒤에 놓이기 때문에 기존 캐시 상태를 재사용할 수 없다. 다행히 컴팩션 이후의 새 요청부터는 다시 캐싱의 이점을 받는다. 즉 컴팩션은 한 번의 비용 손실을 감수하고 세션 수명을 연장하는 거래인 셈이다.
Pi는 컴팩션 요약을 세션에 일반 텍스트로 저장한다. 덕분에 압축된 컨텍스트를 사람이 읽을 수 있고 이식성도 확보된다. Pi 안에서 모델을 바꾸더라도 같은 요약을 그대로 이어서 쓸 수 있다는 점은 실무에서 의미가 크다. 특정 모델의 요약 포맷에 묶이지 않고 도구·모델을 갈아탈 여지를 남기기 때문이다.
끝으로 Pi는 확장성과 유연성을 표방하는 만큼, 기본 컴팩션을 사용자가 직접 만든 방식으로 대체할 수 있다. 다른 컴팩션 메커니즘을 시험해 보고 싶다면 Pi에게 커스텀 컴팩션 프롬프트를 담은 확장을 만들어 달라고 요청하면 된다. 다만 원문은 이 커스터마이징이 실제로 어떤 성능 차이를 내는지, 요약 품질을 어떻게 검증하는지까지는 다루지 않는다. 요약 과정에서 어떤 정보가 유효 맥락으로 남고 무엇이 버려지는지에 대한 판단은 결국 프롬프트 설계에 달려 있어, 긴 세션을 다루는 실무자라면 토큰 예산과 유지 턴 수를 자신의 작업 패턴에 맞게 조정해 보는 실험이 필요하다.