에이전트를 위한 Responses API와 Chat Completions 비교: 계약 방식 선택하기

에이전트 워크로드의 경우, Responses API가 더 나은 기본 선택지입니다. 이 API는 previous_response_id를 통한 서버 측 대화 상태 관리, 단일 메시지 블록 대신 타입이 지정된 출력 항목, 그리고 의미론적(semantic) 스트리밍 이벤트를 제공합니다. 이러한 기능들은 오케스트레이션 계층에서 직접 처리해야 했던 번거로운 작업들을 줄여줍니다. Chat Completions는 메시지 기록을 완전히 제어하고 싶거나 OpenAI 채팅 메시지 형식을 기반으로 구축된 도구와 통합할 때 여전히 유효한 선택지이지만, 다중 턴(multi-turn) 도구 호출 에이전트에게는 Responses가 더 직접적인 적합성을 가집니다.

두 엔드포인트 모두 GPT-5.6 및 GPT-5.5의 현재 모델 참조 페이지에 문서화되어 있으며, Responses의 공유 요청/응답 계약은 Responses 생성 참조에 명시되어 있습니다.

핵심 요약

• Chat Completions는 호출자 관리 방식입니다. 매 요청마다 전체 messages 배열을 전송하고 기록을 직접 재구성해야 합니다.
• Responses는 서버 지원 방식입니다. input과 선택적 instructions를 보내며, 기록을 다시 보낼 필요 없이 previous_response_id를 사용하여 턴을 이어갈 수 있습니다.
• 도구 호출은 구조적으로 다릅니다. Chat Completions는 choices[0].message.tool_calls 하위에 호출을 중첩하지만, Responses는 평면적인 output 배열 내에 타입이 지정된 항목으로 출력합니다.
• 도구 결과는 Chat Completions의 경우 tool_call_id로, Responses의 경우 function_call_output 항목의 call_id로 매칭됩니다.
• 스트리밍은 Chat Completions의 경우 청크 기반 델타(delta) 방식이며, Responses는 명명된 의미론적 이벤트 방식입니다.
• 호스팅된 도구 지원(웹 검색, 코드 인터프리터, 파일 검색 등)은 두 API 모두 모델에 따라 다르므로, 사용 가능 여부를 확인하기 전에 해당 모델의 페이지를 참조하십시오.

필드 수준 비교

구분	Chat Completions	Responses
엔드포인트	POST /v1/chat/completions	POST /v1/responses
주요 입력	messages: [] (매 호출 시 전체 배열)	input (문자열 또는 항목 배열)
시스템 스타일 가이드	messages[0].role = "system"	최상위 instructions 필드
다중 턴 연속성	호출자가 전체 messages 기록을 재전송	previous_response_id가 서버 측에서 이전 턴을 참조
출력 형태	choices[0].message (단일 메시지 객체)	output: [], 타입이 지정된 항목 배열(메시지, function_call 등)
도구 호출 위치	choices[0].message.tool_calls[]	type: "function_call"인 output 내 항목
도구 결과 제출	role: "tool", tool_call_id를 포함한 새 메시지	type: "function_call_output", call_id를 포함한 항목
스트리밍	chunk.choices[0].delta 조각	명명된 이벤트 (response.output_text.delta, response.completed 등)

previous_response_id: 실제 작동 방식

Chat Completions에서 대화 메모리는 전적으로 사용자의 책임입니다. 모든 요청에는 전체 메시지 기록이 포함되어야 하며, 서버는 이전 턴에 대한 개념이 없습니다. 반면 Responses API는 모든 응답 객체에 id를 반환합니다. 애플리케이션이 해당 id를 유지하고 다음 호출 시 previous_response_id로 전달하면, 서버가 이전 대화 상태를 서버 측에서 재구성합니다. 사용자는 현재 턴의 새로운 input과 (선택적으로) 새로운 instructions만 보내면 됩니다. 이는 상태 관리를 애플리케이션 계층에서 OpenAI 인프라로 이전하며, 이는 순차적인 도구 호출 턴을 많이 수행하는 에이전트에게 중요합니다. 매 홉(hop)마다 커지는 기록을 재직렬화하고 재전송할 필요가 없기 때문입니다.

단점은 애플리케이션이 턴 사이에 id를 어딘가(세션 저장소, 데이터베이스 행 등)에 영구적으로 저장해야 한다는 점입니다. API는 무제한 보관이나 과거 응답 검색 기능을 제공하지 않으며, 단지 바로 이전 응답을 연속성 지점으로 참조할 수 있게 해줄 뿐입니다.

현재 요청 예시 (gpt-5.6)

Chat Completions: 전체 기록을 직접 관리:

{
  "model": "gpt-5.6",
  "messages": [
    { "role": "system", "content": "You are a support agent." },
    { "role": "user", "content": "Check order #4471 status." }
  ],
  "tools": [
    {
      "type": "function",
      "function": {
        "name": "get_order_status",
        "parameters": { "type": "object", "properties": { "order_id": { "type": "string" } } }
      }
    }
  ]
}

Responses: instructions와 input을 포함한 첫 번째 턴:

{
  "model": "gpt-5.6",
  "instructions": "You are a support agent.",
  "input": "Check order #4471 status.",
  "tools": [
    {
      "type": "function",
      "name": "get_order_status",
      "parameters": { "type": "object", "properties": { "order_id": { "type": "string" } } }
    }
  ]
}

Responses: 기록 재전송 없는 후속 턴:

{
  "model": "gpt-5.6",
  "previous_response_id": "resp_abc123",
  "input": "What about order #4472?"
}

함수 호출(Function-Call) 수명 주기

Chat Completions:

1. 모델이 choices[0].message.tool_calls를 반환하며, 각 항목은 id와 함수 이름/인수를 포함합니다.
2. 로컬에서 함수를 실행합니다.
3. 어시스턴트 메시지(tool_calls 포함)를 messages 배열에 추가한 다음, 새 메시지 { "role": "tool", "tool_call_id": "<id>", "content": "<result>" }를 추가합니다.
4. 전체 업데이트된 messages 배열을 다시 전송하여 대화를 이어갑니다.

Responses:

1. output 배열에 call_id, name, arguments를 포함하는 type: "function_call" 항목이 포함됩니다.
2. 로컬에서 함수를 실행합니다.
3. 이전 응답의 id로 설정된 previous_response_id와, call_id 및 결과를 포함하는 type: "function_call_output" 항목을 담은 input으로 새 요청을 보냅니다.
4. 서버가 이미 함수 호출 컨텍스트를 유지하고 있으므로 이전 턴을 재전송할 필요가 없습니다.

평면적인 타입 지정 출력 항목과 중첩된 배열을 가진 단일 메시지 간의 구조적 차이는 Responses의 파싱 로직을 단순화하는 경향이 있습니다. 메시지의 선택적 필드를 파헤칠 필요 없이 output을 반복하며 type에 따라 분기할 수 있기 때문입니다.

결정 체크리스트

• 도구 호출을 사용하는 다중 턴 에이전트를 구축 중인가요? Responses를 기본값으로 사용하세요. previous_response_id가 기록 관리 부담을 제거합니다.
• 기록 내용에 대한 정확한 제어가 필요한가요? (수정, 사용자 정의 요약, 비표준 메시지 삽입 등) Chat Completions는 사용자가 직접 messages를 구성하므로 명시적인 제어권을 제공합니다.
• 기존 Chat Completions 통합을 마이그레이션 중인가요? 리팩토링 비용과 상태 관리 절감 효과를 비교하세요. 단기적인 단일 턴 호출의 경우 이점이 적습니다.
• 호스팅된 도구(검색, 코드 인터프리터, 파일 도구)에 의존하나요? 모델과 엔드포인트에 따라 가용성이 다르므로, 결정하기 전에 특정 모델 페이지에서 지원 여부를 확인하세요.
• 세밀한 이벤트 의미론을 가진 스트리밍이 필요한가요? (예: 델타 형태를 검사하지 않고 텍스트 델타와 도구 호출 델타를 구분) Responses의 명명된 이벤트가 Chat Completions의 일반적인 델타 청크보다 더 명시적입니다.
• 채팅 메시지를 중심으로 구축된 기존 프레임워크나 SDK를 사용 중인가요? 프로젝트 도중에 계약을 변경하기 전에 해당 SDK의 Responses 지원 성숙도를 확인하세요.

다중 공급자 에이전트와 계약 변환

에이전트가 한 공급자에만 머무르는 경우는 드뭅니다. 코딩 에이전트는 구현 작업을 위해 Claude Sonnet 5나 Kimi K2.7 Code로 라우팅하고, 저렴한 초안 작성을 위해 DeepSeek V4 Flash나 Gemini 3.5 Flash로 전환하며, 때때로 비용 제어를 위해 GLM-5.2나 Qwen3.7 Plus를 호출할 수 있습니다. 이러한 공급자 중 어느 곳도 OpenAI의 Chat Completions나 Responses 계약을 기본적으로 노출하지 않을 수 있습니다.

이 지점에서 라우팅 계층이 필요합니다. TokenLab 문서(docs.tokenlab.sh)는 여러 모델 공급자에 도달하기 위해 사용하는 단일 API 표면과 키를 설명하며, 이는 공급자 계약마다 별도의 클라이언트 통합을 직접 작성할 필요를 없애줍니다. 계약 호환성을 위한 헤더 별칭에 관한 관련 기사에서는 한 계약 형태에 맞춰 작성된 코드가 해당 계약을 기본적으로 지원하지 않는 모델에 도달할 수 있도록 요청 헤더를 매핑하는 방법을 다룹니다. 하나 이상의 모델 제품군을 호출해야 하는 챗봇이나 에이전트를 구축 중이라면, 하나의 API 키로 AI 챗봇 구축하기 가이드에서 더 구체적인 설정을 확인할 수 있습니다.

프론티어, 코딩, 저비용 라우팅 옵션을 포함하여 TokenLab을 통해 도달할 수 있는 전체 모델 목록은 모델 페이지를 참조하십시오. 모델 라인업은 API 계약보다 더 자주 변경되므로, 아키텍처를 확정하기 전에 현재 가용성과 계약별 참고 사항을 확인하십시오.

제한 사항

이 기사는 두 계약에 대한 OpenAI의 정확한 필드 수준 API 참조를 다시 설명하지 않습니다. 해당 세부 정보는 버전이 지정되어 있으며 변경될 수 있기 때문입니다. 위의 요청 형태 예시를 프로덕션용 코드로 취급하지 마십시오. 또한 모든 공급자의 기본 계약을 심층적으로 다루지는 않았습니다. Claude, Gemini, DeepSeek, GLM은 각각 자체 API 참조를 게시하며, 그중 어느 것도 OpenAI의 Chat Completions나 Responses 형태와 일치할 의무가 없습니다. 에이전트가 도구 호출 순서, 스트리밍 이벤트 형식 또는 배치 처리 동작에 대한 보장이 필요한 경우, 이 기사가 아닌 해당 공급자의 현재 문서를 확인하십시오.

FAQ

Responses API가 Chat Completions를 대체하나요? OpenAI의 퀵스타트 문서는 에이전트 사용 사례를 포함한 새로운 개발 경로로 Responses API를 제시하는 반면, Chat Completions는 여전히 문서화된 API 표면의 일부로 남아 있습니다. Chat Completions가 특정 시점에 지원 중단(deprecated), 종료(sunset) 또는 단순히 레거시가 될지 여부는 지원 상태가 변경될 수 있으므로 OpenAI의 현재 문서에서 직접 확인해야 합니다.

Claude, Gemini, DeepSeek와 같은 다른 공급자도 동일한 계약을 사용하나요? 그렇지 않습니다. 각 공급자는 자체적인 요청 및 응답 형태를 정의합니다. OpenAI 모델과 Claude Sonnet 5 또는 DeepSeek V4 Pro와 같은 공급자 전반에서 에이전트를 실행해야 한다면, 공유 계약을 가정하기보다는 변환 계층을 계획하십시오.

계약을 전환하면 모델 출력 품질이 변경되나요? 아니요. 계약은 요청과 응답의 전송 및 구조일 뿐 모델 자체가 아닙니다. 출력 품질은 Chat Completions를 사용했는지 Responses API를 사용했는지 여부가 아니라, 어떤 모델을 호출했는지(예: GPT-5.5 대 Claude Sonnet 5)에 의해 결정됩니다.

에이전트에 어떤 계약과 모델이 적합한지 평가 중이라면, TokenLab의 문서화된 엔드포인트를 대상으로 작은 테스트 빌드를 수행하여 오케스트레이션 오버헤드를 직접 비교해 보십시오. docs.tokenlab.sh에서 시작하여 자신의 워크로드에 대한 비교를 수행해 보시기 바랍니다.