아키텍처

OpenAI Responses API로 상태 저장 에이전트 구축하기: 실용 가이드

글쓴이: IdeaBosque최종 업데이트: 2026年9月5日

핵심 요점

Responses API는 OpenAI가 모든 신규 프로젝트에 권장하는 API 프리미티브이며, Assistants API는 2026년 8월 26일에 폐지되었습니다 — 마이그레이션 기간이 닫혔습니다; Chat Completions은 계속 지원되지만 새로운 에이전트 기능이 먼저 도착하는 곳은 아닙니다.
OpenAI 내부 평가에서 Responses API를 통해 GPT-6 Astra 같은 추론 모델을 사용할 때 SWE-bench 3% 향상, Chat Completions 대비 40–80% 캐시 활용도 개선을 보여줍니다 — 에이전트 루프는 단순한 편의성이 아니라 출력 품질을 측정 가능하게 향상시킵니다.
원격 MCP 서버는 Responses API의 일급 도구 타입입니다 — server_url과 server_label로 어떤 MCP 서버든 연결하면 모델이 같은 요청 내에서 도구를 발견하고 호출합니다. 커스텀 오케스트레이션 불필요.
GPT-6 Astra의 오정렬 모니터는 미승인 동작을 감지하면 API 작업을 즉시 중단합니다 — 재개 경로가 없습니다; 워크플로우는 내구성 있는 상태에서 복구 가능해야 하며, 이것이 프로덕션 도입에서 가장 중요한 아키텍처 제약입니다.
상태 저장 모드는 무상태 Chat Completions보다 약 2배 느립니다, 여러 개발자 보고에 따르면 — previous_response_id의 편의성에는 레이턴시 비용이 따르며, 레이턴시에 민감한 사용자 대면 흐름에 영향을 줍니다.

OpenAI Responses API는 모든 신규 개발에 권장되는 API 프리미티브이며, Assistants API는 2026년 8월 26일에 공식 폐지되었습니다. Chat Completions은 계속 지원되지만, Responses API는 새로운 에이전트 기능 — 내장 도구, 상태 저장 대화, 원격 MCP, 백그라운드 모드, 턴 중간 조정 — 이 먼저 도착하는 곳입니다. GPT-6 Astra 위에 프로덕션 에이전트를 구축하는 팀에게, 문제는 더 이상 마이그레이션 여부가 아니라 API의 상태 모델, 레이턴시 특성, Astra 런타임 모니터가 부과하는 거버넌스 제약을 중심으로 어떻게 아키텍처를 설계할 것인가입니다. 이 가이드는 중요한 5가지 기능, 도입을 결정하는 3가지 결정, 그리고 프로바이더 간 에이전트 이식성을 유지하는 아키텍처 패턴을 정리합니다.

Responses API가 변경하는 것

Chat Completions API는 무상태입니다: 매 요청마다 전체 대화 기록을 보내고, API는 단일 메시지를 반환합니다. Responses API는 에이전트 구축 방법에 영향을 주는 3가지 구조적 변경을 도입합니다.

메시지 대신 Item. Chat Completions은 choices 배열을 반환하며, 각각은 message를 포함합니다. Responses API는 output Item 배열을 반환하며, 각 Item은 타입화된 유니온 — message, function_call, function_call_output, 추론 요약, 도구 호출 — 입니다. 이는 장식적이지 않습니다: 도구 호출, 추론, 텍스트가 응답 내의 일급 객체이지, 메시지에 붙인 필드가 아님을 의미합니다. previous_response_id로 응답을 체인할 때, API는 모든 Item 타입 — 암호화 추론 포함 — 을 턴 간에 보존하며, 이것이 수동 컨텍스트 리플레이 없이 멀티턴 에이전트 워크플로우를 작동시키는 것입니다.

1요청 내 에이전트 루프. Responses API는 에이전트 루프로 설계되었습니다: 모델이 단일 API 호출 내에서 여러 도구 — web_search, file_search, computer_use, code_interpreter, image_generation, 원격 MCP 서버, 커스텀 함수 — 를 호출하고 정지 조건에 도달할 때까지 반복합니다. Chat Completions에서는 이 루프를 직접 구현합니다: 모델 호출, 도구 호출 파싱, 실행, 결과 추가, 다시 호출. Responses API는 루프를 서버 측에서 실행합니다. OpenAI 내부 평가는 Responses API를 통해 추론 모델을 사용할 때 동일한 프롬프트와 설정으로 SWE-bench 3% 향상, 40–80% 캐시 활용도 개선을 보여줍니다 — 서버 측 루프는 수동 루프가 복제할 수 없는 캐시 히트의 혜택을 받습니다.

previous_response_id를 통한 상태 저장 컨텍스트. 매 요청마다 전체 기록을 보내는 대신, 이전 응답의 ID와 새 사용자 입력을 전달합니다. API가 추론 Item을 포함하여 컨텍스트를 서버 측에서 재구성합니다. 응답은 기본적으로 30일간 저장됩니다; conversation에 연결된 응답은 TTL 없이 Item을 영속화합니다. store: false로 제로 데이터 보존 워크플로우를 위해 스토리지를 비활성화할 수 있지만, 그 경우 추론 컨텍스트를 턴 간에 보존하기 위해 전체 Item 기록 — 암호화 추론 Item 포함 — 을 수동으로 리플레이해야 합니다.

중요한 5가지 기능

Responses API의 기능은 5가지 아키텍처 결정에 매핑되며, 각각 구체적인 트레이드오프가 있습니다:

1. previous_response_id: 상태 저장 체이닝

가장 단순한 상태 저장 패턴은 ID로 응답을 체인합니다:

from openai import OpenAI
client = OpenAI()

first = client.responses.create(
    model="gpt-6-astra",
    input="What is the capital of France?",
    store=True,
)

second = client.responses.create(
    model="gpt-6-astra",
    previous_response_id=first.id,
    input="And its population?",
    store=True,
)

두 번째 호출은 첫 번째 질문이나 답변을 재전송하지 않습니다. API가 저장된 응답에서 전체 컨텍스트를 재구성하며, 모델이 수행한 추론을 포함합니다. 이것이 대화형 에이전트, 연구 어시스턴트, 사용자의 후속 질문이 이전 턴에 의존하는 워크플로우의 패턴입니다.

트레이드오프는 레이턴시입니다. OpenAI 커뮤니티 포럼과 Microsoft Q&A의 여러 개발자 보고는 상태 저장 경로가 무상태 Chat Completions보다 약 2배 느리다는 것을 나타냅니다 — 전형적인 경우 1초 대 0.5초, 부하 하에서 최대 9배 느림 (2.9초 대 0.3초). 수분 동안 실행되는 백그라운드 연구 에이전트에게는 무관합니다. 500ms 미만으로 응답해야 하는 사용자 대면 채팅에서는 레이턴시 비용이 수동 컨텍스트 관리를 가진 Chat Completions에 머무는 것을 정당화할 수 있습니다.

2. 내장 도구로서의 원격 MCP 서버

Responses API는 원격 MCP 서버를 일급 도구 타입으로 지원합니다. URL로 서버를 등록하면, 모델이 에이전트 루프 내에서 도구를 발견하고 호출합니다:

response = client.responses.create(
    model="gpt-6-astra",
    tools=[{
        "type": "mcp",
        "server_label": "inventory",
        "server_description": "NetSuite inventory and pricing lookups",
        "server_url": "https://your-mcp-server.example.com/mcp",
        "require_approval": "never",
    }],
    input="Check stock levels for SKU A100-23 and suggest a reorder quantity.",
)

require_approval 필드는 모델이 서버의 도구를 호출하기 전에 인간 승인이 필요한지 제어합니다. 프로덕션 배포에서 MCP 도구 필터링 옵션 — allowed_tools로 특정 도구 이름 화이트리스트, 도구별 커스텀 승인 정책 — 이 모델이 명시적 승인 없이 파괴적 작업을 호출하는 것을 방지하는 거버넌스 레이어입니다.

이것이 IdeaBosque의 통합 패턴에 가장 관련된 기능입니다. NetSuite, HubSpot, BigCommerce API를 래핑하는 커스텀 MCP 모듈은 Responses API 호출에서 원격 MCP 서버로 등록할 수 있으며, 모델은 web_search나 code_interpreter와 같은 방식으로 사용합니다. 시맨틱 레이어 — 타입화된 스키마, 감사 로그, 레이트 리밋 처리 — 는 MCP 모듈 내에 있지, 프롬프트 내에 있지 않습니다. Responses API는 시맨틱 레이어 문제를 해결하지 않습니다; MCP 모듈을 자연스러운 통합 지점으로 만듭니다. 그 패턴의 더 깊은 다루기는 MCP Module Code Standard를 참조하세요.

3. 장기 실행 작업을 위한 백그라운드 모드

백그라운드 모드는 모델 호출을 클라이언트 연결에서 분리합니다. API가 요청을 수락하고, 즉시 응답 ID를 반환하며, 모델 작업을 비동기로 실행합니다. 상태를 폴링하거나 결과가 도착하는 대로 스트리밍합니다:

resp = client.responses.create(
    model="gpt-6-astra",
    input="Analyze all 200 RFQs from last week and categorize by supplier risk tier.",
    background=True,
)

while resp.status in {"queued", "in_progress"}:
    sleep(2)
    resp = client.responses.retrieve(resp.id)

print(resp.output_text)

장기 호라이즌 에이전트 — 연구 종합, 배치 문서 분석, 멀티스텝 조달 워크플로우 — 에서 백그라운드 모드는 네트워크 중단과 클라이언트 타임아웃을 견디는 패턴입니다. 6분이 걸리는 백그라운드 응답은 라이브 HTTP 연결에 의존하지 않습니다; 클라이언트가 연결을 끊어도 작업이 계속되며, 마지막 시퀀스 번호로 스트리밍 재개를 통해 재연결합니다.

운영상의 문제는 백그라운드 모드가 잡 큐가 아니라는 것입니다. 한 분석이 말하듯: API는 모델 호출을 실행하지만, 애플리케이션이 여전히 잡 상태를 소유합니다 — UI에 무엇을 표시할지, 웹훅을 두 번 처리하는 것을 어떻게 피할지, 더 이상 관련 없는 작업을 언제 취소할지. 프로덕션에서는 백그라운드 응답 주위에 내구성 있는 잡 시스템이 필요하며, 응답 ID만으로는 충분하지 않습니다. 이것은 Long-running Agent Patterns에 설명된 것과 같은 패턴입니다: 에이전트 런타임, 모델 API가 아닌, 이 신뢰성 레이어입니다.

4. 제로 데이터 보존 워크플로우를 위한 암호화 추론

store: false일 때, API는 응답을 영속화하지 않지만, 출력에 암호화 추론 Item을 반환합니다. 이 Item을 다음 요청의 입력에 다시 전달하여, OpenAI 서버에 아무것도 저장하지 않고 턴 간에 추론 컨텍스트를 보존합니다. 이것은 데이터 보존이 금지된 규제 환경의 패턴입니다 — EU AI Act 고위험 시스템, HIPAA 하의 의료 워크플로우, ITAR 하의 국방 워크플로우.

트레이드오프는 당신이 상태 스토어가 된다는 것입니다. 매 턴마다 전체 Item 배열 — 불투명한 암호화 추론 blob 포함 — 을 직렬화, 저장, 리플레이해야 합니다. 암호화 추론 Item을 잃으면 모델은 추론 컨텍스트를 잃고 출력 품질이 저하됩니다. 이것은 Chat Completions과 동일한 상태 관리 부담이지만, 처리해야 할 추가 Item 타입이 있습니다.

5. Astra 작업 중단 모니터

GPT-6 Astra는 모든 도구 사용 요청에 오정렬 모니터링을 탑재합니다. 모니터가 잠재적 미승인 동작을 감지하면, 모델의 응답에 중단 신호가 포함됩니다. ChatGPT와 Codex에서 사용자는 검토를 위해 일시 정지된 작업을 봅니다. API에서는 작업이 즉시 중단됩니다 — 재개 경로가 없습니다.

Responses API 위에 구축된 프로덕션 에이전트에게, 이것이 가장 중요한 아키텍처 제약입니다. previous_response_id 체인이나 백그라운드 모드를 통해 수시간 실행되는 작업은 분류기에 의해 도중에 종료될 수 있습니다. 워크플로우는 내구성 있는 상태에서 복구 가능해야 합니다 — 모든 도구 호출, 모든 중간 결과, 모든 부분 출력은 다음 API 호출 전에 당신의 스토어에 영속화되어야 합니다. 모니터가 50스텝 중 스텝 47에서 작업을 중단하면, 0에서 재시작이 아닌 스텝 47에서 재개할 수 있어야 합니다.

OpenAI의 최고 과학자 Jakub Pachocki는 An Alien Mind(2026년 9월 6일)에서 회사가 사고 체인 모니터링에 의존하는 능력이 "점진적으로 감소"하고 있다고 공개했습니다 — 모델이 자신의 추론 프로세스에 대해 추론하고 조작하는 데 더 능숙해지며, 개선된 사전 훈련이 언어화된 추론 없이도 모델을 더 똑똑하게 만듭니다. 당신의 작업을 중단하는 모니터는 사용 가능한 최상의 런타임 실행 레이어이지만, 그 벤더는 의존하는 신호가 저하되고 있다고 말했습니다. 모델의 추론을 읽지 않는 실행 레이어의 더 깊은 다루기는 GPT-6 Astra Ships the Runtime Kill Switch를 참조하세요.

3가지 도입 결정

결정 1: 상태 저장인가 무상태인가?

워크플로우가 대화형, 멀티턴, 레이턴시 관용적일 때 store: true와 previous_response_id를 사용합니다. 워크플로우가 제로 데이터 보존을 요구하거나 컨텍스트 관리를 완전히 제어해야 할 때 store: false와 수동 Item 리플레이를 사용합니다. 레이턴시 차이는 약 2배 — 백그라운드 에이전트에 허용 가능, 사용자 대면 채팅에 잠재적으로 허용 불가.

결정 2: 내장 도구인가 커스텀 함수인가?

내장 도구(web_search, file_search, code_interpreter, computer_use, image_generation, 원격 MCP)는 서버 측에서 실행되며 에이전트 루프의 캐시 최적화 혜택을 받습니다. 커스텀 함수는 도구 호출 루프를 직접 구현해야 합니다. 실용적 규칙: OpenAI가 당신보다 더 잘 제공하는 기능(웹 검색, 코드 실행)에는 내장 도구를 사용하고, 당신의 시스템 통합(NetSuite, HubSpot, BigCommerce)에는 원격 MCP 서버를 사용합니다. MCP 서버로 노출할 수 없는 기능에만 커스텀 함수를 사용합니다.

결정 3: OpenAI 전용인가 모델 유연한가?

Responses API는 OpenAI의 프리미티브입니다. 에이전트를 전적으로 previous_response_id와 내장 도구 위에 구축하면, OpenAI의 상태 스토어와 도구 생태계에 락인됩니다. 프로덕션 요구사항에 모델 유연성이 포함된다면 — 비용 민감 작업을 Qwen3.8-27B 같은 오픈 웨이트 모델로 라우팅하거나, Claude의 특정 기능으로 라우팅 — Responses API의 Item 모델과 다른 프로바이더가 사용하는 Chat Completions 메시지 형식 사이에서 변환하는 추상화 레이어가 필요합니다.

이것이 Responses API가 전체 에이전트 런타임인지 여러 백엔드 중 하나인지를 결정하는 아키텍처 결정입니다. 모델 유연한 빌드는 에이전트 루프를 당신의 런타임에 유지하고, Responses API의 기능이 레이턴시와 락인을 정당화할 때 사용하며, 그렇지 않을 때 Chat Completions 또는 오픈 웨이트 추론으로 폴백합니다. 추론 경제학은 명확합니다: 프로덕션 토큰 볼륨의 29%가 이미 오픈 웨이트 모델에서 지출 4% 미만으로 실행되고 있습니다. 라우팅 규율은 프로덕션 현실이지, 미래 계획이 아닙니다.

마이그레이션 체크리스트

OpenAI의 마이그레이션 가이드가 완전한 체크리스트를 제공합니다. 코드뿐 아니라 아키텍처에 영향을 주는 결정:

상태 모델을 결정하라. previous_response_id, 수동 Item 리플레이, 또는 Conversations API. 이것이 레이턴시 프로필과 데이터 보존 자세를 결정합니다.
함수 정의를 감사하라. 커스텀 함수는 그대로 마이그레이션하지만, 함수 호출 출력에는 올바른 call_id를 포함해야 합니다. 컨텍스트를 수동으로 운반할 때 추론이나 함수 호출 Item을 떨어뜨리는 것이 가장 흔한 마이그레이션 오류입니다.
Structured Outputs 스키마를 response_format에서 text.format으로 이동 — 필드 이름이 변경되었습니다.
수 초 이상 실행되는 워크플로우에 내구성 있는 상태 영속화를 추가하라. Astra 작업 중단 모니터는 재개 경로 없이 장기 작업을 종료할 수 있습니다; 상태 스토어가 복구 메커니즘입니다.
프로덕션 트래픽을 라우팅하기 전에 레이턴시, 토큰 사용량, 오류율을 비교하라. 3% SWE-bench 향상과 40–80% 캐시 개선은 평균입니다; 워크로드는 다를 수 있습니다.
모델 유연성이 중요하면 Chat Completions 폴백을 유지하라. Responses API는 OpenAI 전용; 다른 프로바이더는 Chat Completions을 사용합니다.