제목: How ChatGPT Optimizes its Agent Loop: Harness, API, and Inference
(ChatGPT는 에이전트 루프를 어떻게 최적화하는가: 하네스, API, 추론)
발신자
ByteByteGo (bytebytego@substack.com)
발행일
2026-07-29
원문 링크
https://blog.bytebytego.com/p/how-chatgpt-optimizes-its-agent-loop
아래 내용은 원문의 저작권을 고려해 문장 단위 직역이 아니라, 원문 구조(헤더 순서)를 따라가며 핵심 내용을 정리·해설한 노트입니다.
배경: 왜 "성공한 작업당 비용"이 중요한가
Anthropic의 Fable 5, OpenAI의 GPT-5.6 패밀리(GPT-5.6 Sol 포함), Kimi K3, Opus 5 등 프론티어 모델들이 최근 연이어 출시되면서 모델 성능 경쟁은 그 어느 때보다 치열하다. 하지만 ByteByteGo는 성능만큼 중요한 지표로 "성공한 작업당 비용(cost per successful task)"을 꼽는다. 실제로 max reasoning 모드의 GPT-5.6 Sol은 Artificial Analysis Coding Agent Index에서 Fable 5보다 높은 점수를 기록하면서도 비용은 절반 이하다. 이 기사는 OpenAI 엔지니어(Joe, Ahmed, Steve, Matthew, Philippe)와의 인터뷰를 바탕으로, Codex와 ChatGPT Work를 뒷받침하는 시스템에서 어떤 효율화 기법이 쓰이는지 다룬다.
에이전틱 AI 애플리케이션의 3단 구조
사용자가 Codex 같은 에이전트에 "버그를 고쳐줘" 같은 작업을 던지면, 그 요청은 곧바로 LLM에 가지 않는다. LLM 자체는 토큰 시퀀스를 입력받아 다음 토큰을 예측할 뿐, 셸 명령 실행이나 파일 편집, 호출 간 기억을 전혀 할 수 없기 때문이다. 그래서 요청은 세 개의 레이어를 거친다.
- 하네스(Harness) — 사용자 머신에서 실행되며, 대화 히스토리의 신뢰 원천(source of truth) 역할을 한다. 어떤 지시사항·도구 정의·히스토리를 컨텍스트에 담을지 결정하고, 모델의 도구 호출(tool call)을 승인 정책에 따라 샌드박스에서 실행한 뒤 결과를 다시 대화에 붙여 LLM에 보낸다.
- API 레이어 — 하네스와 추론 엔드포인트 사이의 애플리케이션 레이어. 인증, 요청 제한(rate limit), 텍스트↔토큰 ID 변환 등을 담당하며 일반 CPU에서 동작한다.
- 추론(Inference) 레이어 — GPU 무리(fleet)가 뒷받침하는 원격 엔드포인트로, 실제 모델 연산이 일어나는 곳이다.
예시로 "체크아웃 리그레션을 추적, 패치, 테스트 실행"이라는 작업이 들어오면 ①하네스가 요청 조립 → ②API가 파싱·검증·rate limit·전처리 → ③API가 토큰화 후 추론 요청과 안전성 검사를 동시에 시작 → ④추론이 프롬프트를 처리하고 도구 호출(예: 코드 검색)을 출력 → ⑤토큰이 API를 거쳐 텍스트로 변환·스트리밍 → ⑥하네스가 도구 호출을 실행하고 결과를 다시 대화에 붙여 API로 재전송. 무거운 작업은 이 루프가 100회 넘게 반복될 수 있고, 매 반복마다 히스토리 재전송·재토큰화·프롬프트 재처리 같은 중복 작업이 발생한다. 이 중복을 제거하는 것이 최적화의 핵심 기회다.
하네스 레이어 최적화
하네스 레이어의 지연은 네트워크, 프롬프트 처리, 컨텍스트 내용, 루프 왕복이라는 네 가지 원천에서 나온다.
1) 지속적 WebSocket + 증분 요청 — 기존 HTTPS/SSE 방식은 한 턴 안에 모델 호출이 여러 번 일어나는 에이전트 워크로드에서 매번 TCP/TLS 핸드셰이크 비용과, 상태를 저장하지 않는(stateless) HTTP 특성상 지시사항·도구 정의·전체 히스토리를 매번 재전송하는 비용을 동시에 치른다. Codex는 하나의 WebSocket을 턴 전체에 걸쳐 유지해 핸드셰이크 반복을 없애고, previous_response_id로 이전 응답을 참조하며 새로운 항목(예: 도구 실행 결과)만 전송해 페이로드 반복도 없앤다. 서버는 보관해 둔 상태로 전체 컨텍스트를 재구성한다.
2) 안정적인 프롬프트 프리픽스(prefix) — 프롬프트 캐싱은 토큰 단위로 정확히 일치하는 앞부분만 캐시를 재사용하므로, 프롬프트 앞쪽 토큰 하나만 바뀌어도 그 뒤 전체가 재계산된다. Codex는 한때 MCP 도구 정의를 순서 보장이 안 되는 해시맵에 저장해 요청마다 도구 순서가 달라지며 캐시가 깨지는 문제가 있었다. 해법은 히스토리를 추가 전용(append-only)으로 다루고, 승인 설정 같은 변동성 있는 런타임 상태는 프롬프트 밖에서 별도로 적용하는 것이다.
3) 지연된 도구 탐색(Deferred tool discovery) — 연결된 통합과 MCP 서버를 합치면 세션 하나에 수백 개 도구 스키마가 노출될 수 있다. OpenAI는 핵심 도구(셸, 파일 편집 등)와 tool_search 하나만 프롬프트에 담고, 나머지는 필요할 때 BM25(어휘 기반 랭킹) 검색으로 카탈로그에서 불러온다. 추가로 스키마 압축(설명 제거·구조 축약)과 대화 압축(긴 히스토리 요약)으로 컨텍스트를 더 줄인다.
4) Code Mode — 여러 도구 호출을 순차적으로 하나씩 보내면 매번 모델 왕복이 필요하고 중간 결과가 계속 컨텍스트에 쌓인다. Code Mode에서는 모델이 도구 호출들을 수행하는 작은 프로그램을 작성하고, 하네스가 이를 내장 자바스크립트 런타임에서 실행한다(모든 도구가 함수로 노출됨). 독립적인 호출은 병렬로 처리하고, 중간 데이터는 런타임에만 머물며 최종 결과만 컨텍스트에 들어간다.
API 레이어 최적화
API는 요청 버퍼링 → JSON 파싱/검증 → 의미론적 검증(모델-기능 호환성) → 사전 점검(인증, rate limit, 이미지 검사) → 렌더링/토큰화 → 추론 요청과 안전성 검사 동시 시작 → 생성 토큰 스트리밍의 순서로 동작한다. API는 GPU 자체 속도를 바꿀 수 없으므로, 그 주변 오버헤드를 줄이는 데 집중한다.
1) 델타(변경분)만 토큰화 — stateless HTTP에서는 호출마다 전체 대화가 재토큰화되어 스무 번째 도구 호출쯤에는 수천 토큰을 다시 읽게 된다. WebSocket 기반으로 토큰화된 대화를 서버 메모리에 보관하면, 이후 요청은 새 항목만 토큰화해 이어붙이면 되므로 호출당 비용이 대화 길이가 아니라 새로 추가되는 입력 길이에만 비례하게 된다(사실상 O(1)에 가까워짐).
2) 안전성 검사와 추론의 병렬 실행 — 사이버공격·생물무기 관련 콘텐츠를 걸러내는 분류기 검사를 추론 시작 전에 순차 실행하면 대부분 무해한 요청까지 첫 토큰 지연(TTFT)이 늘어난다. 대신 모델이 프롬프트를 처리하는 대기 시간 동안 안전성 검사를 동시에 돌리고, 검사 실패 시 모델 민감도에 따라 스트림을 즉시 끊거나 아예 출력을 보류한다.
3) 최신 CPU로 트래픽 라우팅 — 같은 머신 라벨 뒤에 실제로는 구형 Broadwell과 신형 Ice Lake 칩이 섞여 있었고, 구형 칩은 동일 트래픽 처리 시 TTFT가 약 20% 더 나쁘고 CPU 사용량은 약 2배였다. OpenAI는 CPU 세대를 용량 계획의 명시적 변수로 삼아 신형 머신 쪽으로 트래픽을 더 배분했다.
추론 레이어 최적화
추론 레이어의 낭비는 잘못된 머신 라우팅, 잘못된 상태를 붙든 메모리, 순차 생성 중 유휴 상태가 되는 병렬 하드웨어, 서로 다른 두 워크로드가 같은 머신을 공유하는 문제 등 네 가지 지점에서 발생한다.
1) 캐시 인지 라우팅(cache-aware routing) — 라우터는 "가장 한가한 머신으로 분산"과 "이 대화의 캐시를 이미 가진 머신으로 되돌리기"라는 두 목표를 동시에 저울질한다(지리적 위치·가용 용량도 함께 고려). 이 부하 분산 개선만으로 서빙 비용이 크게 줄었다.
2) KV 캐시 관리 — 트랜스포머는 매 토큰 생성 시 이전 토큰 전체에 대한 어텐션 상태(KV 캐시)를 가속기 메모리에 유지한다. 이 캐시는 대화 길이와 동시 처리 대화 수에 비례해 커지며 긴 컨텍스트에서는 모델 가중치 크기에 맞먹기도 한다. OpenAI는 프로덕션 트레이스를 분석해 재사용 가능성이 높은 상태를 데이터 기반으로 판단하고, 그에 맞춰 축출(eviction) 정책과 메모리 계층 간 이동을 최적화한다.
3) 추측 디코딩(speculative decoding) — 토큰 생성은 본질적으로 순차적이라 다음 토큰이 뻔한 경우(예: "the capital of France is" 다음은 "Paris")에도 대형 모델이 전체 연산을 거쳐야 한다. 작은 드래프트 모델이 다음 여러 토큰을 미리 제안하면 대형 모델이 이를 한 번의 병렬 패스로 검증·수락하거나, 틀렸을 때만 직접 생성한다. 평가 지표는 평균 수락 길이(average acceptance length)다.
4) Prefill과 Decode 분리 — Prefill(프롬프트 전체를 병렬 처리해 KV 캐시 구축)은 연산 집약적이고, Decode(토큰 단위 순차 생성)는 메모리 집약적이라 워크로드 특성이 완전히 다르다. 두 단계를 같은 머신에서 돌리면 어느 쪽에도 최적화되지 않은 하드웨어를 쓰는 셈이다. OpenAI는 fleet을 prefill 전담과 decode 전담으로 나누고, prefill이 끝난 요청의 KV 캐시를 decode 머신으로 옮겨 처리한다.
OpenAI가 얻은 교훈
- 설계를 단순하게 유지하라: 도구 탐색에 임베딩 대신 어휘 기반 검색(BM25)을, 여러 압축 경로 대신 하나의 압축 경로를 쓰는 식으로. LLM 앞에 장치를 더 쌓는다고 항상 가치가 늘지는 않는다. 통하는 가장 단순한 것부터 만들고 그다음 확장하라.
- 에이전트로 자기 자신의 스택을 최적화하라: Codex는 자신을 서빙하는 API의 마이그레이션 작업 상당 부분을 직접 작성해 몇 년 걸릴 일을 엔지니어 두어 명이 몇 달로 끝냈다. 추론 팀도 트레이스 분석과 커널 프로토타이핑에 에이전트를 활용한다. 에이전트가 코드를 짜면 "사람이 쓰기 쉬운 언어"가 아니라 "실행에 가장 효율적인 언어"를 고르면 된다.
- 처음부터 끝까지(end-to-end) 최적화하라: 한 가지 기법에만 집중하면 다른 부분 투자가 부족해진다. 큰 성과는 작은 개선들을 여러 개 이어 붙일 때 나온다. 오프라인에서 좋아 보이는 변경도 실제 프로덕션 트래픽 패턴으로 반드시 검증해야 한다.
핵심 요약 (20줄)
- 이 글은 OpenAI 엔지니어 인터뷰를 바탕으로 Codex/ChatGPT Work가 성공한 작업당 비용을 어떻게 낮추는지 다룬다.
- 최신 모델(GPT-5.6 Sol, Fable 5, Kimi K3, Opus 5)의 경쟁은 성능뿐 아니라 비용 효율로도 옮겨가고 있다.
- 에이전틱 AI 애플리케이션은 하네스(Harness) → API → 추론(Inference) 3단 레이어로 구성된다.
- 하네스는 사용자 머신에서 실행되며 대화 히스토리의 신뢰 원천이자, 도구 호출을 샌드박스에서 실행·승인하는 에이전틱 루프의 주체다.
- API 레이어는 인증, rate limit, 텍스트↔토큰 변환 등 제품 운영에 필요한 작업을 담당한다.
- 추론 레이어는 GPU fleet에서 실제 모델 연산을 수행하고 토큰을 생성한다.
- 무거운 작업은 이 3단 루프를 100회 넘게 반복할 수 있어, 반복마다 발생하는 중복 작업 제거가 최적화의 핵심이다.
- 하네스는 지속적 WebSocket으로 TCP/TLS 핸드셰이크 반복을 없애고,
previous_response_id로 변경분만 전송한다. - 안정적인 프롬프트 프리픽스 유지가 중요하며, 도구 정의 직렬화 순서 변화 같은 사소한 차이도 프롬프트 캐시를 깨뜨릴 수 있다.
- **지연된 도구 탐색(deferred discovery)**으로 수백 개 도구 스키마 대신 핵심 도구 +
tool_search(BM25 검색)만 프롬프트에 남긴다. - Code Mode는 도구 호출들을 자바스크립트 프로그램으로 묶어 병렬 실행하고, 중간 결과는 컨텍스트에 넣지 않는다.
- API는 델타만 토큰화해 호출당 비용을 대화 길이가 아니라 새 입력 길이에 비례하게 만든다(O(1)에 근접).
- 안전성 검사와 추론을 병렬 실행해, 검사 대기 시간이 첫 토큰 지연(TTFT)에 추가되지 않도록 한다.
- 같은 머신 라벨 뒤에 섞인 구형/신형 CPU 차이(TTFT 20% 저하, CPU 2배 사용)를 발견하고 신형 CPU로 트래픽을 유도했다.
- 추론 레이어는 캐시 인지 라우팅으로 부하 분산과 캐시 재사용(동일 대화를 같은 머신으로)을 동시에 노린다.
- KV 캐시는 프로덕션 트레이스 기반으로 재사용 가능성을 판단해 축출 정책과 메모리 계층 이동을 최적화한다.
- 추측 디코딩은 작은 드래프트 모델이 여러 토큰을 미리 제안하고 대형 모델이 한 번에 검증·수락한다.
- Prefill(연산 집약)과 Decode(메모리 집약)를 별도 머신으로 분리해 각 워크로드에 맞는 하드웨어를 쓴다.
- OpenAI의 교훈: 설계는 단순하게, 에이전트로 자기 자신의 스택을 최적화하고, 항상 end-to-end로 최적화하며 실제 트래픽으로 검증하라.
- 결론적으로 세 레이어 모두 "같은 작업에 두 번 비용을 치르지 않는다"는 원칙으로 수렴하며, 하네스·API의 캐시 개선이 곧 GPU 비용 절감과 사용자 비용 절감으로 이어진다.
주요 키워드
Harness, Agent Loop, WebSocket, Prompt Caching, Deferred Tool Discovery, Code Mode, KV Cache, Speculative Decoding, Prefill/Decode Separation, Cost per Successful Task
🔗 메타데이터
- 태그: #뉴스레터 #ByteByteGo #AI에이전트 #LLM인프라
- MOC: [[_ontology/주제/AI 에이전트|AI 에이전트]]