OpenAI Agents SDK vs LangGraph 실전 비교: 언제 대체하고 언제 유지할까

한 팀이 LangGraph 로 고객 지원 Agent 프로토타입을 만들었습니다. 실행해 보니 그래프 안의 대부분 노드는 같은 일을 하고 있었습니다. 모델을 호출하고, 이어서 도구 하나를 호출합니다. 코드는 깔끔하지만 boilerplate 가 적지 않습니다. 그래서 누군가 묻습니다. OpenAI Agents SDK 로 바꾸면 이 계층을 줄일 수 있을까요?

다른 상황은 더 까다롭습니다. 리포트 Agent 는 매일 20 분 동안 실행되고, 중간에 SQL 승인을 기다려야 계속 진행할 수 있습니다. 이때는 “코드가 적다”가 유일한 기준이 아닙니다. 일시정지, 재개, 감사가 더 중요합니다. OpenAI Agents SDK 에 sessions 와 guardrails 가 있지만, LangGraph 의 checkpoint 와 interrupt 를 대체할 수 있을까요?

두 상황은 같은 질문으로 이어집니다. OpenAI Agents SDK 는 가벼워 보이지만, LangGraph 를 대체할 수 있을까요, 아니면 일부 작업에만 맞을까요? 실제로 판단해야 할 것은 Agent 가 모델, 도구, 위임만 필요로 하는지, 아니면 이미 지속 상태, 사람의 일시정지, 재개 가능한 실행, 감사 replay 가 필요한지입니다.

먼저 계층을 분리합니다: 같은 추상화가 아닙니다

대체를 논하기 전에 두 프레임워크의 위치를 분리해야 합니다. OpenAI 는 Agents SDK 를 agentic app 구축을 위한 가볍고 사용하기 쉬운, 추상화가 적은 toolkit 으로 설명합니다. 중심은 agent loop, tool call, handoff 위임, guardrails, tracing 입니다. LangGraph 는 long-running stateful workflow 를 위한 저수준 오케스트레이션 인프라입니다. 중심은 명시적 상태 그래프, checkpoint 영속화, interrupt, resume, time travel, fault tolerance 입니다.

하나는 대화와 위임 runtime 에 가깝고, 다른 하나는 방향 그래프 기반 상태 기계에 가깝습니다. 추상화 계층을 표로 보면 다음과 같습니다.

이 표에서 보듯 Agents SDK 는 agent runtime 프리미티브에 가깝고, LangGraph 는 stateful workflow orchestration 에 가깝습니다. 도구를 호출하고 가끔 전문가 agent 에 위임하는 agent loop 만 필요하다면 Agents SDK 로 충분할 수 있습니다. 작업이 일시정지, 재개, 감사, 장애 후 계속 실행을 요구한다면 LangGraph 의 checkpoint 와 interrupt 가 핵심입니다.

이건 “어느 쪽이 더 강한가”의 문제가 아닙니다. 두 도구는 다른 계층에서 움직입니다. Agents SDK 는 agent 를 실행하는 SDK 와 tracing 에 가깝습니다. LangGraph 는 상태 기계 엔진과 영속화 계층에 가깝습니다. 프로세스를 명확한 상태 전이로 그릴 수 있다면 LangGraph 가 더 적합합니다. 거의 “모델 + 도구 + 가끔 escalation”이라면 Agents SDK 가 더 가볍습니다. prompt 가 상태 기계를 대체하기 어려운 이유는 Agent 상태 기계와 workflow 경계도 참고할 만합니다.

기능 매트릭스: 10 가지 실무 차원

추상화 계층이 다르다고 해도 구체 기능은 비교할 수 있습니다. 아래 표는 10 가지 엔지니어링 차원에서 두 프레임워크를 비교합니다.

핵심 차이는 상태 영속화, 실패 복구, replay 가능한 workflow 에 모입니다. Agents SDK 의 sessions 는 대화 연속성을 위한 것입니다. LangGraph 의 checkpointers 는 노드 실행 기록, 중간 변수, 대기 중인 외부 입력을 포함한 전체 그래프 상태를 저장합니다. 리포트 Agent 가 중간에 갑자기 죽으면 Agents SDK 는 보통 처음부터 다시 실행해야 합니다. LangGraph 는 마지막 checkpoint 에서 이어서 실행해 완료된 단계를 반복하지 않을 수 있습니다.

또 다른 차이는 HITL 구현입니다. Agents SDK 에는 guardrails 와 HITL API 가 있어 입력과 출력 검증에 적합합니다. 하지만 guardrails 의 중단은 tripwire 입니다. 발동하면 전체 실행이 멈춥니다. LangGraph 의 interrupt 는 상태 기계 수준의 일시정지입니다. interrupt() 는 특정 노드 안에서 멈추고, checkpointer 가 현재 상태를 저장하며, 이후 외부 입력을 받은 뒤 Command(resume=...) 로 재개합니다. 따라서 LangGraph 는 tool call 전에 멈추고 사람 승인을 기다린 뒤 계속할 수 있습니다. Agents SDK guardrails 는 “입력이 범위를 벗어나면 멈춘다”에 더 맞고, “사람 검토를 기다렸다가 계속한다”에는 별도의 상태 계층이 필요합니다. 더 넓은 승인 경계는 Human-in-the-loop Agent 승인 설계에서 볼 수 있습니다.

Vultr - 고성능 NVMe 클라우드 서버, 전 세계 32개 노드, Docker 원클릭 배포

요금 보기 →광고

세 번째 차이는 replay 입니다. LangGraph 의 time travel 은 임의의 checkpoint 로 돌아가 당시 상태와 실행 경로를 확인할 수 있습니다. 감사, 장애 분석, 재현에 적합합니다. Agents SDK 는 tracing 으로 실행 경로를 시각화할 수 있지만, 과거 상태로 돌아가 다시 실행할 수는 없습니다. “2 시간 전에 왜 이 분기로 갔는가”를 설명해야 한다면 LangGraph 가 더 적합합니다.

Agents SDK 가 제공하는 것: 핵심 프리미티브

OpenAI Agents SDK 의 핵심 프리미티브는 Agents, Handoffs, Guardrails, Tracing, Sessions/HITL/MCP 다섯 가지입니다. 실무 관점에서는 다음과 같습니다.

Agents: Agent 는 LLM, instructions, tools, 선택적 runtime behavior 의 조합입니다. Runtime behavior 에는 다른 agent 로의 handoffs, input/output 검증 guardrails, 특정 형식 반환을 강제하는 structured outputs 가 포함됩니다. Agent 와 Runner 가 함께 동작해 SDK 가 agent loop, turns, tool call, guardrail check, handoff 위임을 관리합니다.

Handoffs: handoff 는 한 agent 가 다른 agent 에게 작업을 위임하는 구조입니다. 본질적으로 대상 agent 가 LLM 에 tool 형태로 노출됩니다. handoff() 는 대상 agent, tool name/description, on_handoff, input_type, input_filter, is_enabled 를 설정할 수 있습니다. 고객 지원 agent 가 문제 유형을 판단한 뒤 기술 지원이나 주문 조회 전문 agent 로 넘기는 specialist 구성에 맞습니다.

Guardrails: guardrails 는 input 과 output 두 단계에서 동작합니다. Input guardrails 는 사용자 입력이 agent 에 들어가기 전에 검사하고, output guardrails 는 agent 응답이 반환되기 전에 검사합니다. tripwire 가 발동하면 실행을 중단합니다. “입력이 예상 범위를 벗어나면 멈추기”나 “출력에 민감 정보가 있으면 차단하기”에 적합합니다. 공식 예시는 더 빠른 모델로 사용자 요청이 범위 안에 있는지 확인합니다.

Tracing: SDK 는 agent run 안의 LLM generations, tool calls, handoffs, guardrails checks, custom events 를 추적하는 tracing 을 내장합니다. 각 span 은 시작 시간, 종료 시간, metadata 를 기록해 debug, visualize, monitor workflows 에 도움이 됩니다. Tracing 은 기본 활성화되어 있으며, trace_include_sensitive_data 로 민감 필드 기록 여부를 제어할 수 있습니다.

Sessions, HITL, MCP tools: Sessions 는 conversation continuity 를 위한 기능입니다. 같은 session_id 의 여러 run 이 대화 기록을 공유합니다. HITL API 는 실행 중 외부 입력을 기다릴 수 있지만, 중단 모델은 LangGraph interrupt 와 같은 추상화가 아닙니다. MCP tools 는 agent 가 MCP server 제공 도구를 호출할 수 있게 하며, function tools 와 비슷하게 SDK 가 관리합니다.

이 프리미티브들은 agent loop, tool calling, 위임, 검증, tracing, 대화 연속성을 커버합니다. 하지만 명시적 상태 그래프, checkpoint 영속화, interrupt, resume, time travel, fault tolerance 는 없습니다. 작업이 “모델 + 도구 + 가끔 위임”이라면 Agents SDK 로 충분할 수 있습니다. “승인 대기 일시정지 + 재개 + 장애 후 계속 실행 + 상태 감사”가 필요하면 LangGraph 가 더 잘 맞습니다.

LangGraph 의 강점: 상태 메커니즘

LangGraph 의 강점은 상태 관리와 복구에 있습니다. Checkpointers, Interrupts, Time travel, Fault tolerance, Stores 입니다. 실무 관점에서는 다음과 같습니다.

Checkpointers: checkpointers 는 thread graph state 를 checkpoints 로 저장합니다. 여기에는 노드 실행 기록, 중간 변수, 대기 중인 외부 입력, 현재 노드 위치가 포함됩니다. 각 checkpoint 는 conversation continuity, HITL, time travel, fault tolerance 에 쓰이는 완전한 상태 스냅샷입니다. 공식 문서도 Agents SDK sessions 와 LangGraph checkpointers 가 같은 개념이 아니라고 설명합니다. Sessions 는 대화 연속성이고, checkpointers 는 그래프 상태 스냅샷입니다.

Interrupts: interrupt() 는 graph node 안에서 실행을 일시정지할 수 있습니다. checkpointer 가 현재 상태를 저장하고 외부 입력을 기다립니다. 재개할 때는 Command(resume=...) 를 쓰고, 같은 thread_id 가 영속 커서 역할을 합니다. 공식 문서는 approval workflows, review/edit state, interrupting tool calls, validating human input 같은 패턴을 제시합니다. 이는 Agents SDK guardrails tripwire 와 다릅니다. interrupt 는 상태 기계의 일시정지이고, guardrails 는 실행 수준의 중단입니다.

Time travel: time travel 은 임의의 checkpoint 로 돌아가 당시 상태와 실행 경로를 볼 수 있게 합니다. 감사, 디버깅, 문제 재현에 유용합니다. 예를 들어 “2 시간 전에 왜 이 분기로 갔는가”를 확인할 수 있습니다. Agents SDK tracing 은 경로를 시각화하지만, 과거 상태로 돌아가 다시 실행할 수 없습니다.

Fault tolerance: fault tolerance 는 장애 후에도 계속 실행하는 능력입니다. 리포트 Agent 가 중간에 죽어도 LangGraph 는 마지막 checkpoint 에서 재개해 완료된 단계를 반복하지 않습니다. Agents SDK 에는 내장 fault tolerance 가 없으므로 보통 처음부터 다시 실행합니다.

Stores: stores 는 사용자 선호, 기록, 업무 상태처럼 thread 를 넘어가는 장기 데이터를 저장합니다. 공식 문서는 stores 와 checkpointers 를 구분합니다. checkpointers 는 thread graph state 를 저장하고, stores 는 thread 간 장기 데이터를 저장합니다. 여러 agent run 사이에 상태를 공유해야 한다면 stores 가 더 적합합니다.

KiloClaw - 기업용 매니지드 OpenClaw, AI Agent 오케스트레이션 및 스마트 라우팅

시작하기 →광고

이 메커니즘 덕분에 LangGraph 는 long-running, stateful workflow 에 적합합니다. 장시간 작업, 다중 분기, 재개 가능한 실행, 감사 가능한 상태, 사람 개입이 필요한 workflow 입니다. 이미 이런 요구사항이 있다면 LangGraph 의 복잡도는 정당합니다. 단순한 tool agent 나 specialist handoff 라면 Agents SDK 가 더 가볍습니다.

Agents SDK 를 쓰기 좋은 경우

앞의 기능 매트릭스와 프리미티브를 기준으로 보면 Agents SDK 는 다음 상황에 더 잘 맞습니다.

1. 단순한 tool agent: 검색, 요약, 필요 시 사람에게 escalation 하는 정도의 상황입니다. 예를 들어 내부 지식베이스 Q&A Agent 는 관련 문서를 검색하고 답변을 요약하며, 확신이 없으면 사용자가 지원팀에 문의하도록 안내할 수 있습니다. 복잡한 상태 복구나 승인 흐름이 필요하지 않아 Agents SDK 의 tools + handoffs + guardrails 로 충분할 수 있습니다.

2. 여러 specialist handoff: 여러 전문 agent 에게 위임해야 하는 상황입니다. 고객 지원 Agent 가 문제 유형을 먼저 판단하고 기술 지원, 주문 조회, 환불 지원으로 넘기는 예가 있습니다. Agents SDK 의 handoffs 는 본질적으로 “agent as tool”이므로 이런 위임 패턴과 잘 맞습니다.

3. 빠른 프로토타입: 처음부터 명시적 상태 그래프를 그리지 않고 아이디어를 빠르게 검증해야 하는 경우입니다. Agents SDK 는 코드량이 적고 시작이 빠릅니다. 프로토타입을 돌린 뒤 checkpoint 나 interrupt 가 실제로 필요 없다는 것이 확인되면 Agents SDK 로 바로 운영할 수 있습니다.

4. OpenAI 생태계와의 적합성: 프로젝트가 주로 OpenAI 모델, Responses API, OpenAI hosted tools 를 사용한다면 Agents SDK 는 공식 toolkit 이라 통합이 더 자연스럽습니다. 실시간 음성 agent, sandbox agents, OpenAI 호스팅 도구가 예입니다.

5. 이미 다른 상태 계층이 있는 경우: 비즈니스 DB, queue, 다른 workflow engine 이 상태를 관리하고 있다면 Agents SDK 는 agent loop 만 맡아도 됩니다. 특정 노드에서 Agents SDK 가 도구를 호출하고, 상태는 비즈니스 DB 와 메시지 queue 가 소유하는 식입니다.

공통점은 명시적 상태 그래프, checkpoint 영속화, interrupt + resume, time travel 이 필요 없다는 것입니다. 이런 특징에 맞는 프로젝트라면 Agents SDK 로 시작하는 편이 더 간단합니다.

LangGraph 를 유지해야 하는 경우

아래 상황에 해당한다면 LangGraph 의 복잡도는 충분히 가치가 있습니다.

1. 장시간 작업(20 분 이상): 리포트 Agent, 데이터 처리, 복잡한 분석은 20 분 이상 실행될 수 있고 중간에 장애나 timeout 이 날 수 있습니다. LangGraph 의 checkpointers 와 fault tolerance 는 마지막 checkpoint 에서 계속 실행하게 해 처음부터 다시 돌리는 일을 피합니다. Agents SDK 는 내장 fault tolerance 가 없어 재실행이 필요합니다.

2. 사람 승인이 필요한 경우: 데이터 삭제, 이메일 발송, 권한 변경 같은 고위험 tool call 은 계속 진행하기 전에 사람 승인이 필요합니다. LangGraph 의 interrupt 는 tool call 전에 멈추고, checkpointer 가 상태를 저장하며, 승인 후 Command(resume=...) 로 재개할 수 있습니다. Agents SDK guardrails 는 “발동하면 멈춤”이지 “검토를 기다렸다 계속함”이 아닙니다.

3. 상태 감사가 필요한 경우: 과거 상태를 replay 하고, 실행 경로를 확인하거나, 결정 이유를 감사해야 하는 상황입니다. 예를 들어 컴플라이언스 요구로 “2 시간 전에 왜 이 분기로 갔는가”를 설명해야 한다면 trace 만으로는 부족합니다. LangGraph time travel 은 checkpoint 로 돌아갈 수 있습니다. Agents SDK tracing 은 경로를 보여주지만 과거 상태에서 다시 실행할 수 없습니다.

4. 장애 후 계속 실행해야 하는 경우: Agent 가 중간에 죽거나 네트워크가 끊겨도 처음부터가 아니라 이어서 실행해야 하는 상황입니다. LangGraph fault tolerance 는 checkpoint 에서 계속합니다. Agents SDK 는 처음부터 다시 시작합니다. API 호출, DB 쓰기처럼 반복 실행하면 안 되는 외부 의존성이 있으면 이 차이가 중요합니다.

5. 다중 분기, 조건부 routing, 업무 상태 기계: 명시적 상태, 조건 분기, 업무 상태 전이가 필요한 workflow 입니다. 예를 들어 주문 처리에서는 결제 성공 -> 배송, 결제 실패 -> 취소, 결제 timeout -> 사람 개입 같은 흐름이 있습니다. 이런 흐름은 LangGraph 의 명시적 상태 그래프가 더 명확하며, Agents SDK handoffs 는 복잡한 routing 을 그리기에 적합하지 않습니다.

공통점은 명시적 상태 그래프, checkpoint 영속화, interrupt 와 resume, time travel, fault tolerance 가 필요하다는 것입니다. 이런 요구가 있다면 LangGraph 의 복잡도는 부담이 아니라 필요한 안전장치입니다.

대체 판단: 4 단계 체크리스트

적합한 상황을 봐도 판단이 애매할 수 있습니다. 아래 4 단계로 확인합니다.

1 단계: 핵심 요구사항을 나열합니다

요구사항을 구체적 항목으로 나눕니다. tool calling, 상태 복구, 사람 승인, 장시간 작업, 다중 분기 routing, 감사 replay, 장애 복구입니다. “agent 가 필요하다”라고만 쓰지 말고 기능으로 분해해야 합니다. 예를 들어 “리포트 Agent 가 20 분 실행되고, 중간에 SQL 승인을 기다리며, crash 후에도 계속해야 한다”는 장시간 작업, 승인, 장애 복구라는 3 가지 요구사항입니다.

2 단계: 강한 요구사항을 기능 매트릭스에 매핑합니다

1 단계에서 나열한 요구사항을 앞의 10 가지 차원에 대입합니다. 예를 들어 “장시간 작업 + 승인 + 장애 복구”는 상태 영속화, HITL, 실패 복구에 해당합니다. 이 3 가지는 Agents SDK 에서는 없거나 약하고, LangGraph 에서는 강합니다. 강한 요구사항이 Agents SDK 의 약점에 집중되어 있다면 대체는 적합하지 않습니다.

3 단계: 명시적 상태 그래프가 필요한지 판단합니다

질문은 하나입니다. 내 프로세스를 명확한 상태 전이로 그릴 수 있는가? 그릴 수 있다면, 예를 들어 주문 처리처럼 결제 성공/실패/timeout 과 후속 단계가 명확하다면 LangGraph 의 명시적 상태 그래프가 더 맞습니다. 고정 흐름이 거의 없고 “모델 + 도구 + 가끔 위임”이라면 Agents SDK 가 더 가볍습니다.

Alibaba Cloud - 개발자 클라우드 1순위, Lighthouse 서버 15% 할인

15% 할인 받기 →광고

4 단계: 팀의 복잡도 수용도를 평가합니다

LangGraph 는 그래프, 상태, 노드 설계를 요구합니다. 팀이 복잡도에 민감하다면 Agents SDK 프로토타입부터 시작하고, 필요성이 확인될 때 상태 계층을 추가합니다. 팀이 이미 workflow 나 상태 기계 경험을 갖고 있다면 LangGraph 의 복잡도는 큰 부담이 아닐 수 있습니다.

이 4 단계를 마치면 Agents SDK, LangGraph, 또는 조합 중 무엇이 맞는지 판단할 수 있습니다. 더 넓은 프레임워크 선택을 보고 있다면 AI Agent 엔지니어링 2026 선택 체크리스트도 함께 볼 수 있습니다.

기존 LangGraph 프로젝트의 마이그레이션 경로

이미 LangGraph 프로토타입이 있고 Agents SDK 로 일부 복잡도를 줄이고 싶다면 아래 표로 판단할 수 있습니다.

반대로 Agents SDK 를 쓰다가 LangGraph 로 올라가야 할 시점을 알고 싶다면 아래 표를 봅니다.

하이브리드 패턴 예시: 모든 것을 대체할 필요는 없습니다. 외부 상태 그래프는 LangGraph 가 관리하고, 특정 노드만 Agents SDK 로 짧은 작업 agent 를 실행할 수 있습니다. 리포트 Agent 의 주 흐름을 LangGraph 로 두면 데이터 전처리 -> SQL 생성 -> 사람 승인 -> 쿼리 실행 -> 결과 내보내기 구조가 됩니다. 이 중 SQL 생성과 결과 내보내기 노드는 별도의 checkpoint 나 interrupt 가 필요 없으므로 Agents SDK 의 agent loop 와 tool call 을 사용할 수 있고, 상태는 LangGraph 가 계속 관리합니다.

핵심은 책임 경계입니다. 상태 계층은 LangGraph 가 관리하고, 짧은 작업 노드는 Agents SDK 가 실행합니다. 둘 중 하나만 고르는 문제가 아니라 각자의 강점에 배치하는 문제입니다.

결론

OpenAI Agents SDK 와 LangGraph 는 이분법으로 고를 대상이 아닙니다. 진짜 질문은 상태 계층이 필요한지입니다. 지식베이스 Q&A, 지원 triage, 빠른 프로토타입처럼 agent loop, tool call, 위임, 검증만 필요하다면 Agents SDK 로 시작하는 것이 가볍고 빠릅니다. 리포트 Agent, 주문 처리, 컴플라이언스 workflow 처럼 장시간 작업 복구, 사람 승인, 상태 감사, 장애 후 계속 실행이 필요하다면 LangGraph 의 checkpoint, interrupt, time travel, fault tolerance 는 필요한 능력입니다.

강제로 대체할 필요는 없습니다. 실무적인 조합은 LangGraph 가 외부 상태 그래프를 관리하고 Agents SDK 가 짧은 작업 노드를 실행하는 방식입니다. 판단은 요구사항에서 시작합니다. 핵심 요구를 나열하고, 강한 요구를 기능 매트릭스에 대입한 뒤, 유지할지, 대체할지, 조합할지 결정합니다.

다음 단계: 이미 LangGraph 프로토타입이 있다면 마이그레이션 판단표로 어떤 노드를 Agents SDK 로 옮길 수 있는지 확인합니다. 아직 프레임워크를 고르는 단계라면 4 단계 체크리스트로 먼저 명시적 상태 그래프가 필요한지 판단하세요.