GPT-5.6 Responses API 비용 최적화: retained reasoning·compaction·tool calling 적용 순서

OpenAI의 GPT-5.6 builder guide에서 개발팀이 바로 가져올 만한 포인트는 모델 이름보다 아키텍처입니다. 공식 글은 GPT-5.6 계열의 가격 대비 성능 개선을 강조하지만, 실제 비용 절감은 모델 교체만으로 끝나지 않습니다. retained reasoning, native compaction, multi-agent orchestration, programmatic tool calling, prompt caching을 같이 설계해야 효과가 납니다.

특히 장시간 실행되는 에이전트는 토큰 비용이 한 번의 응답에서만 발생하지 않습니다. 작업을 이어가며 이전 맥락을 계속 다시 읽고, 도구 결과를 통째로 컨텍스트에 넣고, 중간 판단을 반복하면서 비용이 쌓입니다. GPT-5.6이 더 싸졌더라도 이 구조를 그대로 두면 절감 폭은 제한됩니다. 반대로 작은 모델과 낮은 reasoning effort를 쓰면서 컨텍스트 관리와 도구 실행을 정리하면 성능과 비용을 동시에 잡을 수 있습니다.

OpenAI는 ARC-AGI-3 예시에서 retained reasoning과 compaction 적용 후 점수가 13.3%에서 38.3%로 올라가고 출력 토큰은 약 6배 줄었다고 설명했습니다. 벤치마크 숫자를 그대로 제품에 대입할 수는 없지만 방향은 분명합니다. 에이전트 성능은 이제 모델 성능만이 아니라 ‘이전 작업을 얼마나 잘 재사용하고, 불필요한 중간물을 얼마나 컨텍스트 밖으로 빼는가’에 달려 있습니다.

1단계: 비싼 모델을 전체 파이프라인에 쓰지 않는다

가장 쉬운 비용 절감은 모델 라우팅입니다. 모든 요청을 최고 성능 모델로 보내는 방식은 단순하지만 비쌉니다. 문서 추출, 표준화, JSON 변환, 분류, 중복 제거처럼 판단이 적은 단계는 더 작은 모델이나 낮은 reasoning effort로 충분한 경우가 많습니다.

예를 들어 법무 리서치 에이전트를 만든다고 가정해봅시다. 원문 PDF에서 조항을 추출하는 단계, 날짜와 당사자를 정규화하는 단계, 관련 문서를 필터링하는 단계, 최종 위험 판단을 내리는 단계가 있습니다. 이 네 단계를 모두 고성능 모델에 맡기면 비용이 크게 올라갑니다. 추출과 정규화는 작은 모델이나 프로그램 로직으로 처리하고, 최종 판단만 높은 reasoning 모델에 맡기는 편이 낫습니다.

모델 선택 기준은 ‘중요도’가 아니라 ‘판단 밀도’로 잡는 것이 실무적입니다. 많은 토큰을 읽지만 규칙이 명확한 단계는 프로그램이나 작은 모델에 넘깁니다. 입력은 짧지만 책임이 큰 결정은 강한 모델을 씁니다.

2단계: retained reasoning은 장기 작업에만 켠다

retained reasoning은 이전 호출에서 수행한 추론 상태를 다음 호출에서 재사용하도록 돕는 기능입니다. 장점은 명확합니다. 에이전트가 긴 작업을 진행할 때 매번 처음부터 맥락을 재구성하지 않아도 됩니다. 하지만 모든 요청에 켜는 것이 정답은 아닙니다.

고객 문의 분류처럼 독립 요청이 많은 시스템에서는 retained reasoning의 이점이 작습니다. 반대로 코드베이스 탐색, 데이터 리서치, 장문 보고서 작성, 멀티스텝 분석처럼 같은 목표를 여러 번 호출로 이어가는 작업에서는 효과가 큽니다.

적용 기준은 간단합니다. 한 작업이 3회 이상의 모델 호출로 이어지고, 각 호출이 이전 판단을 참조해야 한다면 retained reasoning 후보입니다. 반대로 각 요청이 독립적이고 재사용할 판단이 없다면 프롬프트 캐싱이나 일반 컨텍스트 최적화가 우선입니다.

3단계: compaction으로 오래된 맥락을 압축한다

장기 에이전트에서 흔한 문제는 컨텍스트가 길어질수록 오히려 성능이 떨어진다는 점입니다. 도구 결과, 중간 메모, 실패 로그, 반복된 지시가 한꺼번에 쌓이면 모델은 중요한 정보를 찾기 어려워집니다. OpenAI가 말한 native compaction은 긴 대화와 작업 상태를 압축해 장기 작업의 coherence를 유지하는 데 초점을 둡니다.

실무에서는 compaction 기준을 명확히 해야 합니다. 모든 로그를 압축하면 디버깅이 어려워지고, 너무 늦게 압축하면 비용이 이미 나갑니다. 추천 기준은 세 가지입니다. 첫째, 도구 결과 원문은 저장소나 DB에 두고 컨텍스트에는 요약과 참조 ID만 넣습니다. 둘째, 실패한 시도는 원인과 다음에 하지 말 것만 남깁니다. 셋째, 최종 판단에 필요한 근거는 압축하지 않고 보존합니다.

4단계: programmatic tool calling으로 중간 데이터 처리를 코드로 뺀다

Programmatic tool calling은 에이전트가 도구 호출과 데이터 처리를 코드로 조율하게 하는 접근입니다. 핵심은 모델에게 100개의 검색 결과를 모두 읽히지 않는 것입니다. 필터링, 정렬, 집계, 중복 제거, 포맷 변환은 코드가 더 싸고 정확합니다. 모델은 기준 설정과 최종 판단에 집중해야 합니다.

예를 들어 채용 공고 분석 에이전트가 200개 공고를 가져왔다면, 모든 공고를 LLM 컨텍스트에 넣는 것은 낭비입니다. 먼저 코드로 날짜, 지역, 기술스택, 연봉 범위를 필터링합니다. 그 다음 상위 20개만 모델에 넣어 판단하게 합니다. 이렇게 하면 토큰 비용뿐 아니라 환각도 줄어듭니다. 모델이 보지 않아도 되는 데이터를 보지 않기 때문입니다.

5단계: prompt caching은 고정 prefix부터 설계한다

GPT-5.6 계열에서는 prompt cache TTL이 최소 30분으로 확장되고 deterministic cache breakpoint를 설정할 수 있다고 설명됐습니다. 이 기능은 시스템 프롬프트, 정책 문서, 도구 설명, 스키마처럼 반복되는 긴 prefix가 있는 서비스에서 유용합니다.

캐시를 잘 쓰려면 프롬프트를 아무렇게나 조립하면 안 됩니다. 고정 영역과 변동 영역을 분리해야 합니다. 시스템 정책, 도구 스펙, 출력 스키마는 앞쪽에 고정하고, 사용자 입력과 매번 바뀌는 데이터는 뒤쪽에 둡니다. 요청마다 timestamp나 랜덤 ID를 앞쪽에 넣으면 캐시 적중률이 떨어집니다.

실행 체크리스트

• 파이프라인 단계를 판단 밀도 기준으로 나누고, 작은 모델·코드·고성능 모델의 역할을 분리합니다.
• 3회 이상 이어지는 장기 작업에만 retained reasoning을 우선 적용합니다.
• 도구 결과 원문은 외부 저장소에 두고 컨텍스트에는 요약과 참조 ID를 넣습니다.
• 필터링, 정렬, 집계, 중복 제거는 programmatic tool calling이나 일반 코드로 처리합니다.
• prompt caching을 위해 고정 prefix와 변동 입력을 분리합니다.
• 비용 지표는 요청당 평균 비용이 아니라 작업 완료당 비용, 재시도율, latency p95로 봅니다.
• 모델 업그레이드 전후에 같은 harness로 품질과 비용을 비교합니다.

GPT-5.6 비용 최적화의 핵심은 ‘더 싼 모델이 나왔다’가 아닙니다. 에이전트가 반복해서 하던 일을 저장하고, 압축하고, 코드로 넘기고, 필요한 순간에만 강한 모델을 쓰는 구조로 바꾸는 것입니다. 이 구조를 먼저 잡아야 모델 가격 인하가 실제 운영비 절감으로 이어집니다.

참고: OpenAI, The builder’s guide to GPT-5.6.