GPT-5.6 프로그래밍 방식 툴 호출: 모델이 오케스트레이션 코드 자동 생성

클래식 함수 호출은 모든 에이전트 개발자가 잘 아는 형태를 가지고 있습니다. 모델이 하나의 도구 호출을 요청하고, 애플리케이션이 이를 실행하며, 결과를 추가하면 모델은 다음 호출을 요청합니다. 네 개의 도구라면 네 번의 왕복. 마흔 개의 도구라면 마흔 번의 왕복입니다. 각 단계마다 네트워크 지연과 다시 청구되는 컨텍스트가 추가됩니다. 2026년 7월 9일, OpenAI가 GPT-5.6을 일반에 공개했을 때, 이 반복적인 과정을 벗어날 방법인 Responses API의 프로그래밍 방식 도구 호출 기능을 함께 출시했습니다.

아이디어는 간단합니다. 모델은 코드가 루프에서 실행할 수 있도록 도구 호출을 한 번에 하나씩 반환하는 대신, 여러 도구 호출을 자체적으로 조율하는 JavaScript 코드를 작성합니다. 이 코드는 네트워크 액세스 없이 격리된 V8 런타임에서 실행됩니다. 개발자의 도구는 코드가 외부 세계에 접근할 수 있는 유일한 방법으로 남아 있으므로, OpenAI 함수 호출에서 이미 고려했던 보안 경계는 그대로 유지됩니다. 달라지는 것은 오케스트레이션입니다. 즉, 과거 애플리케이션에 존재했던 루프, 조건문, 집계가 모델 내부로 이동하는 것입니다.

버튼

이 변화는 API 측면에서도 나타납니다. 개발자가 노출하는 모든 도구는 이제 모델이 한 번에 수십 번 호출할 수 있는 계약이 됩니다. 매 턴마다 신중하게 한 번 호출하는 방식이 아닙니다. 스키마의 정밀도, 오류 형태, 그리고 호출 빈도 동작은 지난주보다 훨씬 중요해졌습니다. 이 글에서는 출시된 내용, 기존 루프 방식의 문제점, 변하지 않는 것, 그리고 모델에 넘기기 전에 Apidog으로 도구 엔드포인트를 준비하는 방법을 다룹니다.

버튼

요약

GPT-5.6은 2026년 7월 9일 일반에 공개되었습니다. 공개와 함께 Responses API는 OpenAI 개발자 문서에서 확인된 바와 같이 프로그래밍 방식 도구 호출 기능을 얻었습니다.
라운드트립당 하나의 도구 호출 대신, 모델은 개발자의 도구를 사용하여 루프, 조건문, 집계를 구성하는 JavaScript를 작성합니다.
생성된 코드는 네트워크 액세스 없이 격리된 V8 샌드박스에서 실행됩니다. 도구 정의는 외부 시스템으로 가는 유일한 경로로 유지되므로 보안 경계는 변경되지 않습니다.
지연 시간과 토큰 비용이 도구 호출 수에 따라 복합적으로 증가하는 현상이 사라집니다. 이는 기존 에이전트 루프의 약점이었습니다.
이 기능은 출시된 지 며칠밖에 되지 않았습니다. 정확한 요청 매개변수와 제한은 OpenAI의 API 레퍼런스에 있으니, 개발하기 전에 반드시 읽어보세요.
모델이 도구 엔드포인트를 오케스트레이션하기 전에 각 도구 엔드포인트를 테스트하고 모의(mock)하세요. 스키마 모호성은 루프에서 반복되는 버그가 될 수 있습니다.

7월 9일에 출시된 내용

GPT-5.6은 세 가지 계층으로 출시되었습니다. 가장 심층적인 추론을 위한 gpt-5.6-sol, 균형 잡힌 작업을 위한 gpt-5.6-terra, 그리고 빠르고 비용 효율적인 대량 작업을 위한 gpt-5.6-luna입니다. 기본 별칭인 gpt-5.6은 Sol로 라우팅됩니다. 이 세 가지 모델은 7월 8일 접근 제한이 해제된 2주간의 제한된 미리보기 이후, 요금제 제한 없이 API를 통해 모두 자체 서비스로 이용 가능합니다.

모델 제품군은 출시 당일 대부분의 주목을 받았지만, 새로운 API 표면은 에이전트 개발자들에게 더 큰 의미를 가집니다. MarkTechPost의 출시 보도와 OpenAI 자체 문서에 따르면, Responses API는 일반 공개 시점(GA)에 네 가지 기능을 추가했습니다. 프로그래밍 방식 도구 호출, 다중 에이전트 베타, 턴 간 지속되는 추론, 그리고 원본 이미지 치수를 보존하는 비전 세부 설정입니다.

프로그래밍 방식 도구 호출이 핵심입니다. OpenAI는 이를 모델이 도구 호출을 조율하기 위해 JavaScript를 작성하고, 네트워크 액세스 없이 격리된 V8 런타임에서 실행하는 것으로 설명합니다. 모델은 더 이상 턴마다 요청하는 역할을 넘어, 오케스트레이션 레이어의 작성자가 됩니다.

프로그래밍 방식 도구 호출이 대체하는 루프

다음은 현재 거의 모든 프로덕션 에이전트가 사용하는 방식인 Responses API를 사용한 클래식 함수 호출입니다.

import OpenAI from "openai";
const client = new OpenAI();

const tools = [
  {
    type: "function",
    name: "get_flight_status",
    description: "IATA 항공편 번호로 항공편의 실시간 상태를 반환합니다.",
    parameters: {
      type: "object",
      properties: {
        flight_number: {
          type: "string",
          description: "IATA 항공편 번호, 예: SQ317"
        }
      },
      required: ["flight_number"]
    }
  }
];

let response = await client.responses.create({
  model: "gpt-5.6",
  input: "Which of these 12 flights are delayed: SQ317, BA15, UA857...",
  tools
});

모델은 데이터 없이는 답변할 수 없으므로 함수 호출을 발생시킵니다. 개발자의 코드는 조회를 실행하고, function_call_output 항목을 추가한 다음, API를 다시 호출합니다:

// 도구 호출당 하나의 왕복. 이 루프가 비용입니다.
while (hasFunctionCalls(response)) {
  const outputs = await executeToolCalls(response); // 개발자의 코드, 개발자의 인프라
  response = await client.responses.create({
    model: "gpt-5.6",
    previous_response_id: response.id,
    input: outputs,
    tools
  });
}

12개의 항공편에 대해 이 루프는 12번 실행될 수 있으며, 각 반복마다 두 배의 비용을 지불합니다. 첫째는 지연 시간입니다. 호출 N+1은 모델이 결과 N을 보는 것에 의존하므로, OpenAI까지의 완전한 네트워크 왕복 시간과 모델 시간이 직렬화되어 추가됩니다. 둘째는 토큰입니다. 도구 결과가 컨텍스트에 누적되므로, 후반부 반복은 초기 반복에서 생성된 모든 것을 다시 처리합니다. 에이전트를 연결하면 이 복합적인 비용이 매우 커집니다. 각 단계가 10회 호출 루프를 포함하는 5단계 에이전트는 50번의 모델 호출로 청구됩니다.

이 루프의 어느 부분도 지능이 아닙니다. 이것은 단순한 파이프라인 작업이며, 이번 주까지 모델은 이 파이프라인 작업을 직접 작성할 방법이 없었습니다.

프로그래밍 방식 모드가 형태를 바꾸는 방법

프로그래밍 방식 도구 호출을 사용하면 모델은 항공편 질문에 다르게 답변합니다. 12개 항공편 번호를 반복하고, 각 항공편에 대해 get_flight_status를 호출하고, 지연 상태를 필터링하고, 지연 시간에 따라 정렬한 다음, 집계된 결과를 반환하는 짧은 JavaScript 프로그램을 작성합니다. 샌드박스가 이 프로그램을 실행합니다. 개발자의 도구는 여전히 실제 작업을 수행하지만, 이제 도구를 둘러싼 제어 흐름은 모델에 속합니다.

세 가지 특성 덕분에 이 기능은 우려할 만한 것이 아니라 실용적입니다:

런타임은 격리되어 있습니다. OpenAI는 생성된 JavaScript를 네트워크 액세스 없이 V8 샌드박스에서 실행합니다. 코드는 URL을 가져오거나, 소켓을 열거나, 자체적으로 어떤 것도 유출할 수 없습니다.
도구가 유일한 출구입니다. 모든 외부 영향은 개발자가 정의한 도구 표면을 통해 라우팅됩니다. delete_record 도구를 노출하지 않았다면, 생성된 코드는 레코드를 삭제할 수 없습니다.
제어 흐름이 표현력이 풍부해집니다. 루프, 조건문, 조기 종료, 결과 집계 등 N번의 왕복을 필요로 했던 패턴들이 이제 단일 응답 주기 내에서 발생합니다.

	클래식 함수 호출	프로그래밍 방식 도구 호출
제어 흐름 작성 주체	개발자의 애플리케이션	모델 (JavaScript로)
N번의 도구 호출을 위한 왕복 횟수	N번 (직렬화)	하나의 응답 주기
오케스트레이션 실행 위치	개발자의 인프라	격리된 V8 샌드박스 (네트워크 없음)
도구 실행 방식	개발자의 코드가 호출	선언된 도구 표면을 통해 여전히 실행
보안 경계	도구 정의	도구 정의 (변경 없음)

변함없는 것

개발자는 위 코드에서와 동일하게 이름, 설명, JSON 스키마 매개변수를 사용하여 도구를 정의합니다. 모델은 개발자가 선언한 도구에 대해서만 호출을 구성할 수 있습니다. 이는 "이 에이전트가 내 시스템에 무엇을 할 수 있는가"라는 질문에 대한 답변이 이전과 동일하다는 것을 의미합니다. 즉, 개발자의 도구 표면이 허용하는 모든 것, 그리고 그 외에는 아무것도 할 수 없습니다.

스키마 품질은 이제 덜 중요한 것이 아니라 더 중요합니다. 기존 루프에서는 모호한 매개변수 설명이 다음 왕복 전에 개발자가 감지하고 수정할 수 있는 하나의 잘못된 호출을 생성했습니다. 프로그래밍 방식 모드에서는 동일한 모호함이 루프에 내장되어 단일 결과를 보기 전까지 모든 반복에서 반복될 수 있습니다. 구조화된 출력을 위해 구축했던 습관이 그대로 적용됩니다. 엄격한 타입, 닫힌 집합에 대한 열거형, 단위와 형식을 명시하는 설명, 그리고 정직하게 필수적인 필드 등입니다.

제한 사항 및 미해결 질문

이 기능은 출시된 지 며칠밖에 되지 않았습니다. 이 기능을 중심으로 에이전트 스택을 재구축하기 전에 몇 가지 주의사항이 있습니다:

정확한 요청 매개변수, 실행 제한 및 타임아웃 동작은 OpenAI의 API 레퍼런스 및 모델 가이드에 명시되어 있습니다. 일반 공개(GA) 이후의 개선 과정에서 매개변수 이름이 변경될 수 있으므로, 이 기능을 사용하여 코드를 작성하기 전에 레퍼런스를 읽으십시오.
디버깅은 새로운 영역입니다. 오케스트레이션이 개발자의 저장소에 있을 때는 중단점을 설정할 수 있었지만, 이제 제어 흐름의 일부가 요청당 새로 생성됩니다. 샌드박스가 만드는 도구 호출 시퀀스를 로깅하는 것이 핵심 관측성 작업이 됩니다.
아직 프로덕션 환경에서의 실적은 없습니다. Simon Willison의 GPT-5.6 출시 첫날 노트는 독립적인 테스트에서 드러나는 문제점들을 잘 기록하고 있습니다. 공식 문서에 언급되기 전에 여기서 문제점들이 나타날 것으로 예상됩니다.
합리적인 배포 순서: 읽기 전용 도구부터 시작하고, 생성된 오케스트레이션을 관찰하며, 기존 루프에 대한 토큰 계산을 검증한 후에야 부작용이 있는 도구를 노출하세요.

개발자의 도구는 이제 다른 사람의 코드가 호출하는 API입니다

클래식 함수 호출 방식에서는 도구가 라운드트립당 한 번 호출되었고, 사람이 작성한 루프가 속도와 순서를 결정했습니다. 프로그래밍 방식 도구 호출에서는 생성된 코드가 개발자의 도구를 일시에 호출하고, 응답에 따라 분기하며, 출력을 집계합니다. 각 도구는 실행되기 전에 검토할 수 없는 기계가 작성한 클라이언트에 의해 사용되는 API 계약입니다.

이는 네 가지 측면에서 기준을 높입니다:

스키마 정밀도. 모든 매개변수 설명에 단위, 형식, 범위를 명시하십시오. 모호한 날짜 형식은 더 이상 한 번의 잘못된 호출이 아니라, 반복되는 오류의 루프가 됩니다.
오류 형태. 생성된 코드는 실패 시 분기할 것입니다. 문자열 내에 오류 메시지가 숨겨진 채 200을 반환하는 도구는 개발자의 스키마에 따라 작성된 모든 오케스트레이션을 오도할 것입니다. 정직한 상태 코드와 구조화된 오류 본문을 반환하십시오.
멱등성 및 호출 빈도 동작. 1분 동안 분산되어 도착하던 12번의 호출이 이제 한 번에 집중되어 도착할 수 있습니다. 모델이 직접 파악하기 전에 이 패턴에서 엔드포인트가 어떻게 작동하는지 파악하십시오.
지연 시간. 8초가 걸리는 도구는 턴당 한 번이면 용인될 수 있었습니다. 12번 반복하는 루프 내에서는 이것이 응답 시간을 결정합니다.

여기서 진정한 API 워크벤치의 가치가 드러납니다. 각 도구 엔드포인트의 사양을 정의하거나 가져오고, 이에 대해 테스트 요청을 보내고, 응답 스키마가 도구 정의에서 약속한 바와 일치하는지 확인하십시오. 그런 다음 한 단계 더 나아가십시오. 예측 가능한 가짜 데이터를 사용하여 프로덕션에 영향을 주지 않고 오케스트레이션을 연습할 수 있도록 도구 API를 모의(mock)하십시오. Apidog을 다운로드하면 내장된 모의 서버가 정의한 모든 엔드포인트에 대해 스키마 형태의 응답을 제공하므로, 단 하나의 실제 레코드도 건드리지 않고 모델에 완전한 도구 표면을 제공하고 모델이 어떻게 오케스트레이션하는지 관찰할 수 있습니다.

버튼

다른 일반 공개(GA) 기능 요약

프로그래밍 방식 도구 호출만 출시된 것이 아닙니다. Responses API의 두 가지 인접한 추가 기능도 중요합니다:

다중 에이전트 (베타): API가 관리하는 병렬 서브 에이전트 실행. 초기 단계이므로 성급하게 의존하기보다는 지켜볼 가치가 있습니다.
지속적인 추론: reasoning.context를 통해 턴 간에 추론 컨텍스트가 재사용되므로, 긴 에이전트 세션이 매 턴마다 동일한 결론을 다시 도출하는 것을 멈춥니다.

두 기능 모두 프로그래밍 방식 도구 호출과 결합됩니다. 턴 간에 추론을 유지하고 자체 오케스트레이션을 작성하는 에이전트는 작업당 훨씬 적은 중복 작업을 수행합니다.

프로그래밍 방식 도구 호출 vs 울트라 모드

이번 출시에는 울트라 모드도 포함되었으며, 둘 다 요청당 더 많은 작업을 수행하기 때문에 혼동될 수 있습니다. 이들은 서로 다른 병목 현상을 해결합니다.

울트라 모드는 기본적으로 네 개의 에이전트를 병렬로 실행하는 다중 에이전트 설정으로, 실제 시간을 단축하기 위해 의도적으로 더 많은 토큰을 사용합니다. OpenAI에 따르면, 이는 Terminal-Bench 2.1 점수를 88.8%에서 91.9%로 향상시킵니다. 이 기능은 Pro 및 Enterprise 요금제의 ChatGPT Work와 Plus 이상 요금제의 Codex에서 제공됩니다. 프로그래밍 방식 도구 호출은 하나의 에이전트가 코드로 도구를 조율하는 API 기능입니다. 울트라는 사고 과정을 병렬화하고, 프로그래밍 방식 도구 호출은 실행 왕복 횟수를 줄입니다. 자세한 내용은 GPT-5.6 울트라 모드 글에 있지만, 요약하자면 다음과 같습니다. 병목 현상이 도구 호출 지연 시간이라면 프로그래밍 방식 도구 호출을 원할 것이고, 어려운 문제에 대한 숙고 시간이라면 울트라 모드를 원할 것입니다.

버튼

자주 묻는 질문

기존 도구 정의를 다시 작성해야 하나요?

아닙니다. 도구는 위 코드에 표시된 것과 동일한 JSON 스키마 형태를 유지하며, 클래식 함수 호출용으로 작성된 정의는 그대로 사용할 수 있습니다. 가치 있는 작업은 이를 강화하는 것입니다. 열거형(enum)을 추가하고, 형식을 명시하며, 생성된 코드가 오해하지 않도록 설명을 충분히 구체적으로 만드십시오.

생성된 JavaScript가 인터넷에 접속할 수 있나요?

아닙니다. 코드는 네트워크 액세스 없이 격리된 V8 런타임에서 실행되며, 개발자가 선언한 도구만이 샌드박스 외부의 어떤 것에든 영향을 미칠 수 있는 유일한 방법입니다. 이는 개발자의 도구 표면이 전체 위험 모델이 됨을 의미하므로, 공개 API에 부여하는 것과 동일한 주의를 기울여 노출하는 도구를 감사하십시오.

어떤 GPT-5.6 모델이 프로그래밍 방식 도구 호출을 지원하나요?

OpenAI는 이를 GPT-5.6 제품군을 위한 Responses API 표면으로 문서화하며, 세 가지 계층(gpt-5.6-sol, gpt-5.6-terra, gpt-5.6-luna) 모두 모든 API 계정에서 자체 서비스로 제공됩니다. 특정 모델을 선택하기 전에 API 레퍼런스에서 계층별 세부 정보를 확인하십시오. 주요 설정 및 첫 번째 요청 안내는 GPT-5.6 API 사용 방법을 참조하십시오.

이것이 코드 인터프리터와 어떻게 다른가요?

코드 인터프리터는 분석, 차트, 파일 변환 등 코드를 결과물로 실행합니다. 프로그래밍 방식 도구 호출은 선언된 도구를 조정하는 것이 유일한 임무인 코드를 생성합니다. 결과물은 집계된 도구 결과이며 코드가 아닙니다.

이것이 남기는 것

왕복 루프는 개발자가 출시한 모든 에이전트에서 가장 흥미롭지 않은 부분이었고, GPT-5.6은 이를 선택 사항으로 만들었습니다. 오케스트레이션은 모델로 이동했으며, 깨끗하고 정확하며 잘 작동하는 도구 API에 대한 책임은 이전보다 더 큰 비중으로 개발자에게 돌아왔습니다.

다음 단계는 구체적입니다. 읽기 중심의 워크플로우 하나를 선택하여 필요한 도구 스키마를 작성하거나 강화하고, 버스트 호출 및 잘못된 입력에도 계약이 유지될 때까지 각 엔드포인트를 Apidog의 API 클라이언트 및 모의 서버를 통해 테스트하십시오. 모델이 개발자의 도구를 사용하는 코드를 작성하기 시작할 때, 그 코드가 이미 테스트된 표면에서 읽어 오기를 원할 것입니다.