멀티턴 대화, 왜 갈수록 느려지고 비싸지는가
← 전체 목차 · 이전: 컨텍스트 요약은 틀리지 않았는데 왜 실행할수록 이탈하는가 · 다음: 사용자가 중간에 딴 질문을 끼워넣으면 Agent는 왜 주작업을 놓치는가
첫 턴은 순식간에 답한다. 열 몇 턴을 넘기면 응답이 눈에 띄게 느려지고, Token 청구서는 기하급수로 불어난다. 그런데 로컬 테스트에서는 이 증상이 재현되지 않는다 — 동시성과 턴수가 함께 쌓여야만 드러나는 문제라서, 디버거로 잡을 수 있는 버그가 아니라 규모에서만 나타나는 아키텍처 결함이다. 범인을 "모델이 느려서"로 지목하기 쉽지만, 같은 모델 같은 네트워크에서 턴수만 늘려도 재현되므로 병목은 모델이 아니라 링크에 있다.
네 가지 공통 원흉
비용 폭증과 응답 지연은 서로 다른 증상이지만 같은 뿌리에서 나온다.
| # | 원흉 | 메커니즘 | 결과 |
|---|
| 1 | 전체 이력 무차별 동반 전송 | 매 요청마다 대화 기록 전체를 그대로 다시 실어 보냄 | Payload가 턴수에 비례해 눈덩이처럼 불어남 → 발송/파싱/전처리 시간과 Token 비용이 함께 증가 |
| 2 | 무차별 재추론 | 매 턴 모델이 지나간 이력 전체를 처음부터 다시 이해·복기함 | 유효 질문 비중이 갈수록 낮아짐 → 같은 정보를 반복 계산하는 데 GPU와 돈이 새어나감 |
| 3 | 세션 캐시 무질서 적재 | 만료된 세션·중복 대화가 도태 정책 없이 계속 쌓임 | 메모리 압박 → 검색 지연 → 이 요청과 무관한 다른 모든 요청까지 간접적으로 느려짐, 피크 시간대에 가장 먼저 터짐 |
| 4 | 도구·연결 매턴 재구축 | 매 턴 도구 인스턴스를 새로 만들고, 연결을 재수립하고, 인증을 재검증 | 한 턴에서는 체감이 거의 없어 로컬 테스트로 못 잡지만, 여러 턴에 걸쳐 누적되면 뚜렷한 지연으로 드러남 |
네 원흉의 공통점은 **"모른다"가 아니라 "다시 한다"**는 것이다. 이미 알고 있는 것을 다시 계산하고, 이미 열었던 연결을 다시 열고, 이미 정리한 결론을 다시 복기한다. 성능 최적화의 첫 번째 원칙은 여기서 나온다 — 더 강한 모델이나 더 큰 서버를 사는 것이 아니라, 존재해서는 안 될 반복 비용을 삭제하는 것이다.
매 턴 전체 이력 동반 전송
↓ 턴수 증가
Payload 팽창 + 무차별 재추론
↓
발송/파싱/추론 시간 동반 상승, Token 비용 동반 상승
↓
세션 캐시가 정리되지 않고 적재
↓
검색 지연 + 도구 매턴 재구축 (단발로는 미미하지만 누적)
↓
TTFT 급등, 응답 체감 저하, 계정 비용 급등 — 로컬에서는 안 보이고 고동시성·고턴수에서만 드러남
네 가지 대응
| 대응 | 핵심 동작 | 겨냥하는 원흉 |
|---|
| 동적 컨텍스트 트리밍 | 잡담·중복 발화·유효기간 지난 결론을 의미 기반으로 걸러내고, 이번 턴이 실제로 의존하는 핵심 맥락만 남김 | 원흉 1, 2 |
| 구조화 스냅샷 증류 | 주기적으로 대화를 핵심 결론 / 사용자 선호 / 업무 규칙 같은 정형 슬롯으로 압축해 저장, 이후 턴은 원문 대신 스냅샷만 읽음 | 원흉 1, 2 |
| 결과 캐시 재사용 | 고빈도 도구 조회·추론 결론을 짧은 TTL로 캐시해 중복 요청은 재계산 없이 즉시 반환 | 원흉 2, 4 |
| 세션·연결 풀링 | 활성/유휴/좀비 세션을 구분해 정리하고, 도구 인스턴스·연결·인증 상태를 전역 풀로 재사용 | 원흉 3, 4 |
동적 트리밍과 스냅샷 증류를 함께 쓰면 무효 Token을 70~80% 수준까지 잘라낼 수 있으며, 이는 현업에서 보고되는 목표치다. 단, 잘라내는 기준은 "오래됐는가"가 아니라 "이번 턴이 의존하는가"여야 한다 — 시간 창으로 단순히 끊으면 아직 유효한 업무 규칙까지 함께 잘려 나간다. 복잡한 다단계 작업에서 어떤 정보를 반드시 원문으로 남겨야 하는지는 AGENT/24 컨텍스트 압축에서 잃으면 안 되는 것이 다루는 문제이며, 이 문서는 그 원칙을 지키는 선에서 얼마나, 어떤 메커니즘으로 실제로 크기를 줄이고 지연을 없애는가를 다룬다. 단순 작업/전형적 복기에는 경량 모델을, 복잡 추론에는 대형 모델을 배정하는 모델 계층화(모델 라우팅)는 비용 축을 한 번 더 눌러주지만 이 문서의 범위 밖이며 AGENT/05 모델 라우팅과 AGENT/33 모델 다운그레이드 전략에서 다룬다.
핵심 통찰
- 로컬에서 재현 안 되는 성능 문제는 "규모가 만드는 문제"라는 신호다 — 단발 요청 디버깅으로는 절대 못 잡는다. 턴수 × 동시성을 동시에 끌어올리는 압박 테스트만이 이런 결함을 드러낸다. "일단 배포하고 로그를 보자"는 전략이 여기서는 통하지 않는다.
- 비용 폭증과 지연 폭증은 증상만 다를 뿐 같은 병이다 — 둘 다 "전체 이력을 무차별로 다시 처리한다"는 하나의 설계 결함에서 갈라져 나온다. 그래서 해법도 하나의 세트(트리밍, 스냅샷, 캐시, 풀링)를 공유한다. 비용팀과 성능팀이 따로 문제를 풀면 같은 원인을 두 번 진단하게 된다.
- "컨텍스트가 많을수록 똑똑하다"는 직관은 착각이다 — 무차별 동반 전송은 정확도를 높이지 않는다. 오히려 유효 정보 비중을 희석시켜 판단 품질을 떨어뜨리면서 동시에 돈과 시간을 태운다. 상관관계가 아니라 반비례 관계에 가깝다.
- 단발로는 미미한 비용이 가장 위험하다 — 도구 매턴 재구축은 한 턴에서는 체감되지 않아 코드 리뷰에서 가장 잘 넘어가는 항목이다. 매 턴 실행되는 동작을 평가할 때는 반드시 전형적 대화 턴수를 곱해서 누적 비용으로 봐야 한다.
- 세션 캐시의 위험은 간접적이고 피크 시점에 집중된다 — 도태 정책 없는 캐시는 특정 요청을 직접 느리게 만들지 않고, 메모리 압박을 통해 이 요청과 무관한 모든 요청을 함께 느리게 만든다. 그리고 이 압박은 트래픽이 가장 몰리는 시점에 가장 먼저 터진다 — 정확히 시스템이 가장 안정적이어야 할 때.
- 트리밍의 판단 기준은 "시간"이 아니라 "의존성"이어야 한다 — 최근 N턴만 남기는 시간창 방식은 구현이 쉽지만, 아직 유효한 업무 규칙이 N턴보다 이전에 나왔다면 그대로 잘려 나간다. 의미 기반으로 "이번 턴이 실제로 참조하는가"를 판정해야 정확도 손실 없이 크기를 줄일 수 있다.
- 스냅샷은 압축이 아니라 지식화다 — 대화 원문을 계속 다시 읽게 하는 대신, 핵심 결론·선호·규칙을 정형 슬롯으로 한 번 추출해 두면 이후 턴은 O(n) 재복기 대신 O(1) 조회로 끝난다. 정보를 잃는 것이 아니라 매번 다시 배우는 비용을 없애는 것이다.
- 유효기간이 있는 자원은 전부 풀링 대상이다 — 도구 인스턴스, 연결, 인증 상태는 "만들기는 비싸고 재사용은 싸다"는 공통 성질을 가진 자원이다. 전통적인 커넥션 풀 사고방식이 Agent의 도구 계층에도 그대로 적용된다.
- 하드웨어 증설은 최후 수단이지 첫 번째 카드가 아니다 — 서버를 늘려도 무차별 동반 전송·무차별 재추론·무정리 캐시는 그대로 남는다. 단기적으로 증상을 가릴 뿐 근본 원인은 그대로이므로 비용은 선형으로 늘고 효과는 금방 한계에 부딪힌다.
엔지니어링 실전 Tips
- TTFT를 1급 지표로 볼 것. 총 응답 시간보다 사용자 체감에 더 가깝고, 네 원흉이 공통으로 악화시키는 지표이기도 하다.
- 압박 테스트는 반드시 "턴수 × 동시성" 두 축을 함께 올릴 것. 단일 요청 벤치마크는 이 계열의 결함을 절대 드러내지 못한다.
- 트리밍 판정은 규칙이든 모델 채점이든 "이번 턴 의존도"를 1급 신호로 삼을 것. 최신순 절단은 구현이 쉬운 대신 오탐이 구조적으로 발생한다.
- 스냅샷은 고정 슬롯(핵심 결론 / 사용자 선호 / 업무 규칙)으로 만들 것. 자유 서술 요약보다 어느 슬롯을 조회해야 할지 명확해 재사용성이 높다.
- 캐시 TTL은 짧게, 대신 히트율을 계측할 것. 고빈도·단주기 갱신 데이터에 긴 TTL을 걸면 절약한 비용을 낡은 데이터로 되갚는다.
- 세션은 활성/유휴/좀비 세 등급으로 나눠 각기 다른 정리 주기를 둘 것. 일괄 TTL 하나로는 활성 사용자를 오폭하거나 좀비 세션을 방치하거나 둘 중 하나로 치우친다.
- 매 턴 실행되는 초기화 동작은 전부 "전형적 턴수 × 1회 비용"으로 재환산해 리뷰할 것. 단발 체감이 적다고 지나치면 안 된다.
- 하드웨어 증설 전에 네 가지 원흉을 먼저 제거했는지 체크리스트로 확인할 것. 순서를 거꾸로 하면 비용은 늘고 근본 문제는 그대로 남는다.