AI 코딩 에이전트 (AI Coding Agent)를 일상적으로 장기 운용하다 보면, 하나의 세션 안에서 화제가 여러 번 바뀝니다. 구현 상담이 조사로 바뀌고, 그다음은 문서 정비로 이어지는 식입니다. 화제가 바뀔 때마다 컨텍스트 (Context)를 어떻게 처리할지가 계속 고민이었는데, 최근 그 해결책을 /rewind의 'Summarize up to here'로 정했습니다. 제 환경에서의 측정값과 시산(試算)을 곁들여 기록해 둡니다.

화제가 바뀔 때마다, 세 가지 선택지 모두 손해였다

이 고민의 정체를 분석해 보면, 화제가 바뀌는 시점에 취할 수 있는 방법이 세 가지밖에 없었다는 결론에 도달합니다. /clear는 전부 버립니다. 직전 화제의 결과물뿐만 아니라, 세션 전체에 쌓인 문맥이 사라집니다.

/compact는 대화 전체를 압축하기 때문에, 지금 바로 다루고 있는 파일의 내용이나 에러의 세부 사항까지 요약되어 뭉개집니다. 끝난 화제와 진행 중인 화제를 구분해 주지 않습니다. 세 번째 방법인 별도 세션 시작은 언뜻 깔끔해 보이지만, 시스템 프롬프트 (System Prompt) 층과 프로젝트 문맥 (Project Context) 층을 다시 불러와야 합니다. 이 재호출 비용은 제 환경에서의 실측 결과, 세션 첫 번째 요청의 총 입력이 55,000~63,000 토큰이었습니다 (구성 방식에 따라 다르므로 다른 환경에 그대로 적용되는 숫자는 아닙니다). 게다가 인수인계 메모를 작성해서 읽히는 왕복 과정이 필요합니다. 세 가지 방법 모두 대화 전체를 하나의 단위로 취급한다는 점에서는 동일했습니다.

Summarize up to here는 선택한 지점의 앞부분만 압축한다

압축하는 단위가 대화 전체밖에 없다는 것이 전절의 문제였습니다. 'Summarize up to here'는 바로 그 단위를 나누어 줍니다. /rewind (Esc를 두 번 입력)로 히스토리를 열고, 화제가 바뀐 지점의 프롬프트를 선택해 이 작업을 실행하면, 그 앞부분만 요약으로 교체되고 선택한 메시지 이후는 원문 그대로 남습니다. 실행 후에는 대화의 끝에 머물며, 입력창은 빈 상태로 작업이 계속됩니다.

동작 측면에서 중요한 것은 압축할 위치를 직접 지정할 수 있다는 점입니다. 진행 중인 화제에서 읽은 파일이나 스택 트레이스 (Stack Trace)는 원문 그대로 수중에 남고, 끝난 화제만 요약이 됩니다. 압축 단위가 '대화 전체'에서 '화제의 끊김 지점'으로 이동했다는 것이 제 이해입니다.

압축하면 비용이 많이 든다는 것은 첫 번째 턴뿐이다

단위를 화제의 끊김 지점으로 옮길 수 있다는 것을 알게 된 후, 다음에 확인한 것은 비용 구조였습니다. 프롬프트 캐시 (Prompt Cache) 문서에 나와 있듯이, 요청은 매번 풀(Full)로 전송되며, 맨 앞부분부터의 완전 일치 (Prefix Match)로 캐시가 대조됩니다. 내용은 크게 '시스템 프롬프트 층 / 프로젝트 문맥 층 / 대화 층'의 세 가지로 나누어 생각할 수 있으며, 대화 층의 변화는 상위 두 층의 캐시를 깨뜨리지 않습니다. 고정비의 대부분은 상위 두 층이 차지합니다.

"중간을 삭제하면 프리픽스 (Prefix)가 바뀌어 재처리된다"라는 지적은 옳습니다. 다만 바뀌는 것은 대화 층의 프리픽스이므로, 재처리되는 것은 그 이후뿐입니다. 게다가 캐시가 유지되는 한 딱 한 번뿐이며, 이후의 턴은 짧아진 히스토리를 캐시 읽기 (API 요금표에서는 통상 입력의 약 10% = 약 0.1배) 비용으로 지불하게 됩니다.

여기서부터는 실측이 아닌 계산입니다. 대화 층 100,000 토큰을 15,000 토큰으로 압축하면, 차이인 85,000 토큰이 매 턴의 캐시 읽기 대상에서 사라져, 1턴당 약 8,500 토큰 상당의 절약이 지속됩니다. 반면 일시 비용은 압축 직후의 첫 번째 턴에, 새로워진 히스토리 15,000 토큰을 캐시 없이 다시 지불하는 비용입니다. 압축하지 않았다면 그 턴도 100,000 토큰의 캐시 읽기 (약 10,000 토큰 상당)로 끝났을 것이므로, 손해는 차액 약 5,000 토큰 상당입니다. 1턴당 절약분이 8,500 토큰 상당이므로, 다음 턴에는 이를 회복한다는 계산이 나옵니다. 어디까지나 대화 층만을 본 단순화 모델이며, 캐시 쓰기 측의 할증도 고려하지 않았기 때문에 실제 손익 분기점은 요금 체계나 캐시의 TTL (Time To Live)에 따라 달라집니다. 그럼에도 방향성은 명확하며, 작업이 계속될수록 압축하는 것이 더 저렴합니다.

압축 방식에 따라 결과가 달라지는 2가지 점

"계속된다면 압축하는 것이 더 저렴하다"를 판단 기준으로 삼아 운용에 도입해 보니, 결과를 좌우하는 점이 두 가지 있었습니다. 첫 번째는 실행 방식입니다. 제가 사용하는 버전에서는 메뉴에서 숫자 키를 누르면 즉시 실행되므로, 화살표 키로 하이라이트한 뒤 'add context (optional)'로 진행하여 무엇을 남기고 싶은지 작성한 후 실행합니다. 요약에 무엇을 남길지를 여기서 지정하느냐에 따라 압축 후의 작업 지속성이 달라집니다.

두 번째는, 압축하더라도 원문이 세션의 트랜스크립트(transcript)에 남아 있다는 점입니다. 제 환경에서는 세부 사항이 필요할 때 나중에 다시 참조할 수 있었기에, 요약 과정에서 정보가 사라지면 끝이라는 상황은 아니었습니다.

여담이지만, 반대 방향인 'Summarize from here'는 용도가 반대입니다. 이는 옆길로 샌 후반부 내용을 압축하여 버리고, 초기 지시 사항을 원문 그대로 남기고 싶을 때 사용합니다.

이 두 가지 점을 파악하고 나서, 압축할 위치와 요약에 남길 정보도 스스로 결정할 수 있게 되었습니다.

작성자: Map. AI 코딩 에이전트(AI coding agent)의 장기 운용과 기억·위임(delegation) 관련 설계를 실천하며 기록하고 있습니다. 에이전트로부터의 승인 요청을 한곳으로 모아 처리하는 okgate를 만들어 매일 직접 사용하고 있습니다 (무료로 시작할 수 있습니다).

Discussion