에이전트가 느려지거나 비용이 많이 들 때, 단순히 모델만을 살펴보는 유혹에 빠지기 쉽습니다. 하지만 “회귀를 찾고, 수정하고, 테스트를 실행하라”와 같은 작업은 컨텍스트(context), 도구 실행(tool execution), 네트워크 전송(network transport), 토큰화(tokenization), 보안 필터(security filters), 라우팅(routing) 및 GPU와 같은 전체 시스템에 의존합니다.

ByteByteGo의 기사인 How ChatGPT Optimizes its Agent Loop는 이 시스템을 harness, API, 추론(inference)의 세 가지 계층으로 구성하며, 에이전트를 구축하는 사람들에게 유용한 아이디어를 제공합니다. 즉, 거의 모든 관련 최적화는 시스템이 이미 수행한 작업을 다시 하지 않도록 방지하는 것입니다.

에이전트 루프는 세 가지 계층을 가집니다

• Harness: 히스토리를 유지하고, 컨텍스트를 구성하며, 도구 호출(tool calls)을 해석하고, 승인 정책을 적용하며, 결과를 모델에 반환합니다.
• API: 구조화된 대화를 수신하고, 인증하며, 제한 사항(limits)을 적용하고, 콘텐츠를 토큰화하며, 요청을 전달합니다.
• 추론 (Inference): 가속기(accelerators)에서 모델을 실행하고, 생성을 위해 필요한 상태를 보존하며, 다음 토큰을 생성합니다.

단일 작업은 이 사이클을 여러 번 반복할 수 있습니다. 수십 개의 도구, 긴 결과물, 그리고 새로운 추론 단계가 있을 때 각 호출에서의 1초 추가는 더 이상 사소한 문제가 아닙니다.

1. Harness에서는 변경된 사항만 전송하세요

상태가 없는(stateless) HTTP 흐름에서는 매 라운드마다 지침, 도구 스키마(tool schemas) 및 전체 히스토리를 다시 보내는 경향이 있습니다. ByteByteGo는 지속적인 WebSocket 사용과 증분 요청(incremental requests)을 설명합니다. 첫 번째 호출 이후, 클라이언트는 도구의 새로운 결과와 이전 응답에 대한 참조를 보낼 수 있습니다. 연결과 서버는 이미 나머지 정보를 알고 있기 때문입니다.

동일한 원칙이 프롬프트 캐시(prompt cache)에도 적용됩니다. 캐시는 접두사(prefix)가 토큰 단위로 완전히 일치할 때만 재사용됩니다. 따라서 도구 정의를 결정론적(deterministic)으로 정렬하고 히스토리를 append-only 시퀀스로 취급하는 것은 단순한 구현상의 기호가 아니라, 각 라운드의 비용을 변화시키는 중요한 요소입니다.

2. 컨텍스트 내 도구 최소화, 필요할 때만 도구 호출 (On-demand)

수백 개의 통합 스키마 (Integration Schemas)를 매 호출마다 로드하는 것은 거의 사용되지 않더라도 컨텍스트 (Context)를 소모합니다. 이 논문에서 설명하는 대안은 프롬프트 (Prompt)에 핵심적인 도구들과 도구 검색 기능만을 남겨두는 것입니다. 에이전트가 특정 사항이 필요할 때, 카탈로그를 검색하여 관련 정의를 받아옵니다.

여기에는 중요한 세부 사항이 있습니다. 이러한 상황에서는 정교함보다 단순함이 승리할 수 있습니다. 예시에서는 임베딩 (Embeddings) 레이어를 크리티컬 패스 (Critical Path)에 추가하는 대신, 설명으로부터 도구를 검색하기 위해 BM25 lexical search (어휘 검색)를 사용합니다.

라운드 수를 줄이는 또 다른 방법은 코드 모드 (Code Mode)입니다. 여러 개의 독립적인 호출을 내보내고 각각의 결과를 기다리는 대신, 모델이 이를 실행할 작은 프로그램을 작성하여 가능한 부분을 병렬화하고, 통합된 결과만을 컨텍스트에 반환합니다. 이는 지연 시간 (Latency)과 대화에 누적되는 노이즈 (Noise)를 모두 줄여줍니다.

3. API에서 전체 대화를 다시 토큰화(Retokenize)하지 마세요

토큰화 (Tokenization)는 텍스트에 대한 선형적인 작업입니다. 만약 API가 도구 결과가 나올 때마다 전체 히스토리를 다시 토큰화한다면, 단 몇 줄을 추가하기 위해 수천 개의 토큰을 다시 읽어야 합니다. 서버 측 메모리에 대화를 토큰화된 상태로 유지함으로써, API는 델타 (Delta)만을 토큰화하여 기존 상태에 붙일 수 있습니다.

또한 이 논문은 첫 번째 토큰까지의 시간 (Time to First Token)을 줄이는 실용적인 방법을 강조합니다. 바로 추론 (Inference)과 병렬로 보안 검사를 시작하는 것입니다. 만약 제어 프로세스가 결과가 공개되어야 하는 시점 이전에 완료된다면, 사용자는 대기 시간에 대해 이중으로 비용을 지불하지 않습니다. 당연히 전제 조건은 검증이 실패할 경우 차단 또는 보류 정책을 유지하는 것입니다.

4. 추론 시, 이미 계산된 상태를 보호하세요

GPU 레이어에서 라우팅 (Routing)은 단순히 대기열 (Queue)만 바라봐서는 안 됩니다. 대화의 다음 라운드를 해당 상태를 여전히 보유하고 있는 머신으로 전달하려고 시도해야 합니다. 다른 머신으로 요청을 보내면 시스템이 이미 존재하던 캐시 (Cache)를 다시 구축해야 할 수도 있습니다.

이 상태가 바로 **KV 캐시 (KV cache)**이며, 트랜스포머 (Transformer)가 매 토큰마다 모든 어텐션 (Attention)을 다시 계산하지 않도록 하는 데 사용됩니다. 이 캐시는 컨텍스트 (Context)와 동시 대화 수에 따라 증가하므로, 유지 관리 및 전송 정책은 직관이 아닌 실제 사용 패턴에 따라 가이드되어야 합니다.

이 기사는 또한 알려진 두 가지 기술을 언급합니다:

• 투기적 디코딩 (Speculative decoding): 더 작은 모델이 여러 토큰을 제안하면, 더 큰 모델이 이를 병렬로 검증하고 출력 품질을 변경하지 않으면서 올바른 토큰만 수용합니다.
• 프리필 (Prefill)과 디코드 (Decode)의 분리: 전체 프롬프트를 처리하는 것과 토큰을 하나씩 생성하는 것은 서로 다른 부하입니다. 이를 분리하면 각 단계의 병목 현상에 맞춰 리소스를 구성할 수 있습니다.

올바른 지표는 완료된 작업당 비용입니다

가장 유용한 점은 개별 기술이 아닙니다. 전체 체인을 관찰하는 것입니다. 안정적인 접두사 (Prefix)는 프롬프트 캐시 (Prompt cache)를 돕고, 캐시는 API와 GPU의 작업량을 줄이며, 필요할 때 발견되는 도구는 불필요한 컨텍스트를 방지하고, 배치 실행 (Batch execution)은 루프의 회전 횟수를 줄입니다.

에이전트를 운영하는 사람들에게 실질적인 질문은 다음과 같습니다: 이 루프가 반복하고 있는 작업은 무엇인가? 실제 운영 환경과 유사한 트래픽으로 측정하고, 안전할 때 상태를 유지하며, 복잡성을 추가하기 전에 재계산을 제거하십시오. 이러한 작은 결정들의 합이 실제로 완료되는 작업당 지연 시간과 비용을 줄여줍니다.

출처: ByteByteGo — How ChatGPT Optimizes its Agent Loop: Harness, API, and Inference (2026년 7월 29일). 이 텍스트는 기사를 바탕으로 한 독창적인 분석이며, 복제물이 아닙니다.