OpenAI Agents SDK 선택 기준: Responses API와 구분해 운영하는 실전 설계법

요약: OpenAI 문서는 “Responses API는 루프를 직접 소유하고 싶을 때, Agents SDK는 SDK가 에이전트 루프를 실행하게 하고 싶을 때”라고 구분한다. 실제 제품에서는 이 문장을 기준으로 상태, 도구, 승인, 추적 책임을 나누면 된다.

에이전트 기능을 붙이려는 개발팀이 가장 자주 헷갈리는 질문은 “Responses API로 충분한가, Agents SDK를 써야 하나”다. 둘 다 모델을 호출하고 도구를 붙일 수 있다. 하지만 운영 책임의 위치가 다르다. OpenAI Agents SDK 가이드는 SDK를 “typed application code, direct control over tools, MCP servers, runtime behavior, custom storage, server-managed conversation strategies”에 적합한 경로로 설명하면서도, Responses API와의 차이를 명확히 둔다.

문서의 핵심 문장은 이렇다. “Use the Responses API when you want to own the loop. Use the Agents SDK when you want the SDK to run it.” 이 한 줄을 제품 설계 언어로 바꾸면, 모델 호출 루프·도구 반복·전문가 전환·승인 재개·추적을 누가 책임질 것인가의 문제다. 단순 챗봇이면 차이가 작지만, 환불 승인, 장애 조사, 데이터 수정처럼 여러 단계를 거치는 업무에서는 차이가 크게 난다.

Responses API가 맞는 경우

Responses API는 애플리케이션이 루프를 직접 제어해야 할 때 맞다. 예를 들어 사용자가 질문하면 서버가 검색하고, 검색 결과를 모델에 넣고, 답변을 저장하는 흐름은 Responses API로 충분하다. 함수 호출이 필요해도 애플리케이션이 function call을 받아 실행하고, 결과를 다시 모델에 넘기는 구조를 직접 구현하면 된다.

이 방식의 장점은 예측 가능성이다. 상태 저장, 재시도, 캐시, 권한, 로깅을 기존 백엔드 패턴으로 처리할 수 있다. 이미 NestJS, FastAPI, Next.js API route 안에 비즈니스 로직이 있고, 모델은 그중 한 단계라면 Responses API가 자연스럽다. 모델이 자율적으로 여러 도구를 돌기보다, 서버가 명확한 순서로 일을 시키는 구조다.

예를 들어 “고객 문의를 요약하고 관련 문서를 찾아 답변 초안을 만든다”는 기능을 생각해보자. 1단계는 티켓 조회, 2단계는 문서 검색, 3단계는 모델 답변 생성, 4단계는 상담원 승인이다. 각 단계가 고정되어 있고, 승인 UI도 기존 시스템에 있다면 SDK가 루프를 관리할 필요가 없다. Responses API로 명시적인 파이프라인을 만드는 편이 디버깅이 쉽다.

Agents SDK가 맞는 경우

Agents SDK는 반복되는 도구 호출, 분기, handoff, guardrail, trace가 핵심일 때 맞다. OpenAI 문서는 SDK가 agent loop를 수행하고, handoff 뒤에는 에이전트를 전환하며, 완료되거나 승인을 기다릴 때 멈춘다고 설명한다. 즉 “모델 한 번 호출”이 아니라 “작업 실행 단위”가 추상화다.

대표적인 예시는 지원 요청 조사다. 처음에는 triage agent가 요청을 읽고, 결제 문제면 billing agent로 넘기고, 환불이면 refund agent가 내부 시스템을 조회한다. 특정 금액 이상 환불은 사람 승인을 기다린다. 승인 후 같은 run이 다시 이어져 기록을 남긴다. 이 흐름을 직접 구현하면 상태 머신, 도구 루프, 권한 체크, 재개 토큰, 로그 추적을 모두 만들어야 한다.

SDK를 쓰는 이유는 코드를 줄이기 위해서만이 아니다. specialist마다 instructions, tools, policy를 분리할 수 있다. 결제 에이전트에는 결제 조회 도구만 주고, 환불 에이전트에는 환불 요청 도구와 승인 규칙을 붙인다. 이 분리는 보안과 평가에도 유리하다. 어떤 에이전트가 어떤 도구를 왜 호출했는지 trace로 확인할 수 있어야 운영이 된다.

멀티 에이전트는 언제 나눠야 하나

OpenAI orchestration 문서는 “가능하면 하나의 에이전트로 시작하고, capability isolation, policy isolation, prompt clarity, trace legibility가 실제로 좋아질 때만 specialist를 추가하라”고 말한다. 이 조언은 중요하다. 많은 팀이 데모 단계에서 에이전트를 너무 빨리 쪼갠다. 이름이 멋있어 보이지만 운영은 더 복잡해진다.

나눠야 하는 기준은 명확하다. 첫째, 서로 다른 도구 권한이 필요할 때다. 읽기 전용 조사 에이전트와 결제 변경 에이전트는 분리하는 게 맞다. 둘째, 안전 정책이 다를 때다. 초안 작성과 실제 발송은 다른 승인 규칙을 가져야 한다. 셋째, 프롬프트가 너무 커져서 역할이 섞일 때다. 넷째, trace를 봤을 때 한 에이전트가 모든 일을 해서 실패 원인을 분리하기 어려울 때다.

반대로 단순 요약, 분류, 문장 다듬기, 키워드 추출처럼 bounded task는 별도 handoff보다 agents as tools 패턴이 낫다. manager agent가 최종 답변 책임을 유지하고, specialist를 도구처럼 호출하는 방식이다. 사용자는 대화 상대가 바뀌었다고 느끼지 않고, 내부적으로만 도움을 받는다.

Handoff와 agents as tools의 차이

handoff는 specialist가 해당 branch의 대화를 이어받는 방식이다. 사용자의 다음 응답까지 specialist가 책임져야 한다면 handoff가 맞다. 예를 들어 환불 상담에서 refund agent가 정책 설명, 추가 질문, 승인 요청까지 맡아야 한다면 control을 넘기는 게 자연스럽다.

agents as tools는 manager가 계속 최종 답변을 책임지는 방식이다. specialist는 요약, 검증, 코드 리뷰, 분류 같은 제한된 작업만 수행한다. OpenAI 문서 예시도 summarizer agent를 tool로 붙이는 형태를 보여준다. 이 패턴은 trace가 단순하고, 사용자 경험도 안정적이다.

실무에서는 기본값을 agents as tools로 두는 편이 안전하다. handoff는 대화 소유권이 바뀌기 때문에 승인 표면, 메모리 범위, 사용자 톤, 오류 복구가 복잡해진다. “이 specialist가 다음 사용자 응답을 직접 받아야 하는가?”라는 질문에 예라고 답할 수 있을 때만 handoff를 쓴다.

상태 저장과 재개 설계

에이전트 운영에서 가장 많이 터지는 부분은 상태다. 단일 API 호출은 실패하면 재시도하면 되지만, 에이전트 run은 중간에 도구 호출, 승인 대기, 외부 시스템 변경을 포함한다. 같은 작업을 두 번 실행하면 중복 환불, 중복 이메일, 중복 티켓 업데이트가 생길 수 있다.

따라서 Responses API든 Agents SDK든 idempotency key를 먼저 설계해야 한다. 사용자 요청 ID, 대상 리소스 ID, 작업 유형을 조합해 중복 실행을 막는다. 도구 호출 결과는 원본 응답과 함께 저장하고, 외부 변경 도구는 dry-run과 commit 단계를 분리한다. 사람 승인이 필요한 단계는 승인 전 payload와 승인 후 실행 payload가 달라지지 않도록 해시를 남긴다.

Agents SDK를 쓰면 resumable approval flow 같은 기능을 활용할 수 있지만, 제품 DB에는 여전히 업무 상태를 저장해야 한다. SDK trace만 믿고 비즈니스 상태를 복원하려고 하면 운영자가 보기 어렵다. 고객 티켓, 주문, 환불, 배포 같은 도메인 객체에는 “에이전트가 무엇을 제안했고 사람이 무엇을 승인했는지”가 남아야 한다.

운영 기준표

작은 기능은 Responses API로 시작한다. 루프가 고정되어 있고, 도구 호출 순서가 명확하고, 승인·전문가 전환이 거의 없다면 SDK는 과하다. 반대로 도구 호출이 몇 번 반복될지 모르고, 역할별 권한 분리가 필요하고, 사람이 중간 승인한 뒤 이어서 실행해야 한다면 Agents SDK가 낫다.

평가 기준도 다르게 잡아야 한다. Responses API 기능은 latency, cost, answer quality, retrieval precision을 보면 된다. Agents SDK 워크플로우는 task completion rate, tool error recovery, approval turnaround time, handoff accuracy, trace inspectability까지 봐야 한다. 운영 대시보드가 달라진다.

마지막으로 조직 역량도 고려해야 한다. 에이전트 프레임워크는 기능보다 운영 문화가 더 중요하다. 도구 권한 설계, 로그 보관, 승인 UI, 실패 재처리, eval 데이터셋이 없으면 SDK를 붙여도 데모에서 멈춘다. 반대로 이 기반이 있으면 SDK는 반복 업무 자동화 속도를 크게 올린다.

실행 체크리스트

• 모델 호출 루프를 애플리케이션이 직접 통제해야 하면 Responses API를 우선 검토한다.
• 반복 도구 호출, handoff, guardrail, resumable approval이 필요하면 Agents SDK를 검토한다.
• specialist는 권한, 정책, 프롬프트, trace 중 하나 이상이 실제로 분리될 때만 만든다.
• handoff 전에는 “이 에이전트가 다음 사용자 응답을 직접 소유해야 하는가”를 확인한다.
• agents as tools를 기본값으로 두고, manager가 최종 답변 책임을 유지하게 한다.
• 모든 외부 변경 도구에는 idempotency key와 dry-run 결과를 붙인다.
• 승인 전 payload와 승인 후 payload의 해시를 저장한다.
• SDK trace와 별도로 제품 DB에 업무 상태와 사람 승인 기록을 남긴다.