2026년 AI Agent 엔지니어링 가이드: LangGraph와 OpenAI Agents SDK 선택 기준

고객 조사용 Agent demo는 이미 문서를 검색하고, 결과를 요약하고, Lark 메시지를 보낼 수 있습니다. 문제는 프로덕션으로 올리려는 순간 시작됩니다. 큐, 승인, 실패 복구, 로그, 비용 상한, 회귀 테스트가 아직 없습니다. 제품 매니저가 “다음 주부터 운영팀이 쓸 수 있나요?”라고 묻는 순간, 개발자는 LangGraph와 OpenAI Agents SDK 선택이 demo가 얼마나 빨리 도는지의 문제가 아니라는 것을 깨닫습니다. 핵심은 상태 영속화, 사람 승인, 관측성, 비용 예산, 권한 모델, eval dataset, 실패 복구라는 7가지 엔지니어링 기준입니다.

OpenAI Agents SDK: 가벼움을 우선할 때의 선택

OpenAI Agents SDK는 OpenAI 모델과 도구 호출 생태계에 가까운, 가볍고 코드 중심인 Agent 구축 도구입니다.

핵심 원어는 다음과 같습니다.

원어	설명	경계
Agents	instructions, model, tools, MCP servers, handoffs, guardrails를 조합한 실행 단위	명시적 상태 그래프가 아니며, 비즈니스 상태는 직접 설계해야 합니다
Handoffs	한 Agent가 다른 Agent에게 작업을 넘길 수 있는 multi-agent 전달 메커니즘	장시간 workflow 제어 자체는 아닙니다
Guardrails	input/output guardrails가 병렬로 검사하고 tripwire가 발생하면 예외를 던집니다	완전한 권한 모델, 감사 로그, 컴플라이언스 승인 흐름은 아닙니다
Tracing	traces/spans를 내장하고 custom processor와 민감 데이터 제어를 지원합니다	완전한 모니터링, 알림, 비용 예산, rollback 시스템은 아닙니다
Tools	OpenAI Hosted tools, 사용자 정의 함수 도구, MCP servers를 지원합니다	구체적인 도구 유형과 MCP 지원 범위는 공식 문서에서 확인해야 합니다
Sessions / HITL	공식 문서에는 sessions, human-in-the-loop, sandbox agents 등의 입구가 있습니다	LangGraph식 graph checkpoint, time travel, replay는 아닙니다

가벼운 코드형 Agent를 빠르게 만들고 싶고, 주로 OpenAI 모델과 도구 호출 생태계에 의존하며, multi-agent handoff, 입출력 guardrails, SDK 내장 tracing, 낮은 프레임워크 복잡도가 필요하다면 OpenAI Agents SDK가 더 가벼운 선택입니다. 예를 들어 고객 지원 Q&A, 문서 검색 + 요약, 여러 Agent가 순서대로 처리하는 흐름이 여기에 해당합니다.

대가와 경계도 있습니다. Guardrails는 입력과 출력을 검증할 수 있지만, 복잡한 승인 흐름, 권한 분리, 감사 로그는 비즈니스 계층에서 구현해야 합니다. Tracing은 OpenTelemetry나 custom processor에 연결할 수 있지만, 팀의 로그, 메트릭, 알림, 비용 예산, 회귀 테스트는 별도로 붙여야 합니다. Sessions와 HITL은 대화와 사람 개입의 일부를 보완합니다. 하지만 명시적 상태 그래프, checkpoint, resume/replay, time travel, 장시간 workflow 제어가 필요하다면 LangGraph, Temporal, 또는 비즈니스 상태 계층을 평가해야 합니다.

맞지 않는 경우도 분명합니다. 복잡한 상태 분기, 승인 후 재개해야 하는 일시 중지 흐름, 실패 후 retry, rollback, 추적 가능성을 보장해야 하는 강한 SLA 업무, 상태 replay와 장시간 workflow 제어가 필요한 경우입니다.

변하기 쉬운 사실에 대한 주의: OpenAI Agents SDK의 API, 기본 모델, Hosted tools, MCP 지원, sessions, sandbox agents, tracing 기본 동작, 가격은 바뀔 수 있습니다. 통합 전에 OpenAI Agents SDK 공식 문서를 확인하세요.

LangGraph: 명시적 상태와 영속화에 강한 선택

LangGraph는 stateful agents를 위한 low-level orchestration framework입니다. durable execution, HITL, memory, time travel을 강조합니다.

핵심 능력은 다음과 같습니다.

능력	설명	대표 용도
Durable execution	checkpointer를 통해 thread와 checkpoint/state snapshots를 영속화합니다	실패 후 checkpoint에서 resume 또는 replay
Human-in-the-loop	interrupt로 실행을 멈추고 Command resume으로 재개합니다. tool calls의 approve/reject/edit/review에 사용할 수 있습니다	복잡한 승인 흐름, 민감한 작업의 사람 확인
Memory	comprehensive memory로 단기/장기 컨텍스트를 저장할 수 있습니다	Agent 메모리 시스템 설계
Time travel	과거 checkpoint에서 replay 또는 fork할 수 있습니다	실패한 실행 재현, 다른 분기 결과 비교

영속화 메커니즘

LangGraph의 영속화는 단순한 채팅 기록이 아닙니다. thread와 checkpoint를 중심으로 설계됩니다.

Thread: 대화 또는 workflow의 실행 스레드입니다. Checkpoint: 특정 시점의 전체 상태 스냅샷이며 graph state, pending tasks, pending writes를 포함합니다. Resume/Replay: checkpoint에서 실행을 이어가거나 과거 실행 경로를 재생하는 것입니다.

이 메커니즘은 일시 중지와 재개, 실패 retry, 상태 replay가 필요한 상황에 적합합니다. 예를 들어 고객 지원 승인 흐름, 여러 단계의 비즈니스 workflow, 장시간 실행되는 조사 Agent입니다.

Human-in-the-loop(HITL)

LangGraph의 HITL은 상태가 있는 workflow의 일시 중지와 재개에 더 가깝습니다.

Interrupt: 특정 노드에서 실행을 멈추고 사람 입력을 기다립니다. Command resume: 사람이 approve/reject/edit한 뒤 Command 객체로 실행을 재개합니다. Tool call review: 특정 tool call 실행 전에 멈추고 사람 승인을 받을 수 있습니다.

OpenAI Agents SDK의 guardrails와 비교하면, Guardrails는 실행 전후 검증에 가깝고 LangGraph HITL은 workflow 중간에서 멈췄다가 재개하는 방식에 가깝습니다. 승인 흐름에 여러 턴, 상태 저장, replay, 분기가 필요하다면 LangGraph가 더 잘 맞습니다.

복잡한 상태 분기, 복구, 승인 대기, 상태 replay가 필요하다면 LangGraph는 프로덕션 오케스트레이션에 더 가까운 선택입니다. 고객 지원 승인 흐름, 여러 단계의 비즈니스 workflow, 장시간 실행되는 조사 Agent가 예입니다.

대가는 엔지니어링 복잡도입니다. 상태 그래프를 설계하고 유지해야 합니다. 또한 persistence backend를 선택해야 하며, 지원 범위는 바뀔 수 있으므로 통합 전에 공식 문서를 확인해야 합니다.

맞지 않는 경우는 짧은 작업, 상태가 적은 빠른 프로토타입, 주로 OpenAI 도구 생태계에 의존하고 영속화나 복잡한 승인이 필요하지 않은 경우입니다.

변하기 쉬운 사실에 대한 주의: LangGraph v1, Platform/Studio/Deployment, persistence backend 지원은 바뀔 수 있습니다. 통합 전에 LangGraph 공식 문서를 확인하세요.

LangGraph 상태 관리의 자세한 메커니즘은 사이트 내 글 LangGraph 상태 관리 실전과 LangGraph vs AutoGen 상태 추적 비교를 참고하세요.

AutoGen, CrewAI, Temporal: multi-agent와 durable execution의 보조선

선택지는 OpenAI Agents SDK와 LangGraph의 양자택일만이 아닙니다. 초점이 여러 역할 협업, 연구 프로토타입, 독립적인 workflow 인프라에 있다면 AutoGen, CrewAI, Temporal도 봐야 합니다.

AutoGen / AG2

AutoGen은 Core API, AgentChat API, Extensions, Studio를 포함하는 layered framework이며 multi-agent 대화와 협업 애플리케이션 구축을 대상으로 합니다.

Core API는 낮은 수준의 agent runtime과 메시지 라우팅입니다. AgentChat API는 대화와 협업을 위한 더 높은 수준의 추상화입니다. Extensions는 외부 도구, 모델, 플랫폼과의 통합 계층입니다. Studio는 시각적 구축과 디버깅을 위한 도구입니다.

적합한 경우: multi-agent 대화/협업 연구와 프로토타입, 팀이 이미 AutoGen 생태계에 익숙한 경우입니다.

별도 평가가 필요한 항목: 상태 영속화, 실패 복구, 관측성, 권한, 배포입니다. AutoGen과 AG2의 버전 관계, API 안정성, 문서 입구도 AutoGen 공식 문서에서 확인해야 합니다.

변하기 쉬운 사실에 대한 주의: AutoGen과 AG2의 마이그레이션, Microsoft Agent Framework와의 관계, API 안정성은 바뀔 수 있습니다. 이 글은 AutoGen을 multi-agent 협업 후보로 다루며, 버전 로드맵을 강한 사실로 쓰지 않습니다.

CrewAI

CrewAI는 crews, agents, tasks, processes, flows 등의 개념으로 multi-agent 협업을 구성하고, Flows를 통해 더 구조화된 오케스트레이션을 제공합니다.

핵심 개념: Crews는 agents와 tasks의 묶음입니다. Agents는 역할 정의입니다. Tasks는 구체적인 작업입니다. Processes는 실행 흐름입니다. Flows는 더 구조화된 여러 단계 오케스트레이션입니다.

적합한 경우: 역할 협업형 Agent 애플리케이션, 빠른 오케스트레이션과 프로토타입입니다.

별도 평가가 필요한 항목: 제품 모듈, 호스팅 기능, pricing, enterprise 기능입니다. 통합 전에 CrewAI 공식 문서를 확인하세요.

변하기 쉬운 사실에 대한 주의: CrewAI의 제품 모듈, 호스팅 기능, pricing, enterprise 기능은 바뀔 수 있습니다. 이 글은 CrewAI가 “가장 강한지”를 평가하지 않고, multi-agent 협업 후보로 둡니다.

Temporal

Temporal은 Agent 프레임워크가 아닙니다. durable execution infrastructure입니다. workflow, activity, retry, timeout, visibility를 제공하며, “반드시 안정적으로 실행되어야 하는” 비즈니스 프로세스를 받치는 데 적합합니다.

핵심 능력: Workflow는 장시간 프로세스의 정의입니다. Activity는 실패할 수 있는 외부 작업을 감쌉니다. Retry/Timeout은 재시도 전략과 시간 제한 설정입니다. Visibility는 workflow 실행 상태를 조회하고 모니터링하는 기능입니다.

Agent 프레임워크와의 관계: Agent는 Temporal workflow 또는 activity 안의 한 단계가 될 수 있습니다. Temporal은 바깥쪽의 신뢰할 수 있는 비즈니스 프로세스를 맡고, Agent 프레임워크는 지능형 단계를 맡습니다.

적합한 경우: 실패 후 retry, rollback, 추적 가능성이 반드시 필요한 강한 SLA 업무 프로세스, 큐, retry, timeout, 감사가 필요한 복잡한 엔터프라이즈 workflow입니다.

아닌 것: 모든 로직을 Agent 프레임워크에 넣으라는 뜻은 아닙니다. Temporal + Agent SDK/LangGraph 조합이 더 깔끔한 책임 분리가 될 수 있습니다.

변하기 쉬운 사실에 대한 주의: Temporal Cloud pricing, SDK API, 배포 방식은 바뀔 수 있습니다. 통합 전에 Temporal 공식 문서를 확인하세요.

선택 매트릭스: 프로덕션 기준에서 본 프레임워크 차이

선택은 인기 순위가 아닙니다. 상태 영속화, HITL 승인, 관측성, 비용 예산, 권한 모델, eval dataset, 실패 복구라는 7가지 엔지니어링 기준을 확인하는 일입니다. 아래 표는 5가지 선택지를 이 기준과 경계로 비교합니다.

프레임워크	상태 영속화	HITL 승인	관측성	비용 예산	권한 모델	Eval dataset	실패 복구
OpenAI Agents SDK	Sessions로 대화 컨텍스트를 유지할 수 있지만 graph checkpoint나 time travel은 아닙니다	HITL/guardrails 입구는 있지만 복잡한 승인 흐름은 비즈니스 계층에서 설계해야 합니다	내장 tracing이 있지만 로그/메트릭/알림은 별도로 붙여야 합니다	완전한 내장 예산 시스템은 없으며 직접 구현해야 합니다	Guardrails는 완전한 권한 모델, 감사 로그, 컴플라이언스 승인 흐름이 아닙니다	직접 구현해야 합니다	일반 retry, 복구, rollback은 비즈니스 계층에서 설계해야 합니다
LangGraph	Checkpointer + thread + checkpoint/state snapshots로 resume/replay가 가능합니다	Interrupt + Command resume으로 approve/reject/edit/review tool calls가 가능합니다	OpenTelemetry에 연결할 수 있지만 로그/메트릭/알림은 별도로 붙여야 합니다	내장되어 있지 않으며 직접 구현해야 합니다	graph 노드 또는 비즈니스 계층에서 구현합니다	직접 구현해야 합니다	checkpoint에서 resume 또는 replay하며 retry와 replay 패턴을 지원합니다
AutoGen	상태 영속화 능력을 별도로 평가해야 합니다	HITL 능력을 별도로 평가해야 합니다	관측성 통합을 별도로 평가해야 합니다	별도 평가가 필요합니다	별도 평가가 필요합니다	별도 평가가 필요합니다	별도 평가가 필요합니다
CrewAI	상태 영속화 능력을 별도로 평가해야 합니다	HITL 능력을 별도로 평가해야 합니다	관측성 통합을 별도로 평가해야 합니다	별도 평가가 필요합니다	별도 평가가 필요합니다	별도 평가가 필요합니다	별도 평가가 필요합니다
Temporal	Workflow + activity로 장시간 workflow 상태를 다룰 수 있습니다	Workflow는 사람 입력을 기다리며 멈출 수 있고 승인 흐름을 workflow 계층에서 구현할 수 있습니다	내장 visibility가 있으며 OpenTelemetry에 연결할 수 있습니다	workflow/activity 계층에서 예산 제어를 구현할 수 있습니다	workflow/activity 계층에서 권한 검사를 구현할 수 있습니다	직접 구현해야 합니다	내장 retry/timeout이 있으며 안정적 실행과 복구에 적합합니다

핵심 해석은 이렇습니다. 상태 영속화, HITL 승인, 실패 복구에서는 LangGraph와 Temporal이 더 강합니다. OpenAI Agents SDK는 더 가볍지만 복잡한 프로덕션 거버넌스는 여전히 직접 만들어야 합니다. 관측성 측면에서는 모든 선택지가 팀의 로그, 메트릭, 알림을 필요로 합니다. OpenAI Agents SDK와 LangGraph에는 tracing 추상화가 있고, Temporal에는 visibility 추상화가 있습니다. 비용 예산, 권한 모델, eval dataset은 모든 프레임워크에서 직접 책임져야 합니다. Agent 프레임워크가 이미 모두 해결했다고 가정하지 않는 편이 안전합니다. AutoGen과 CrewAI는 여러 역할 협업과 프로토타입에 적합하지만, 프로덕션 기준은 별도 평가가 필요합니다.

경계도 분명히 해야 합니다. Tracing은 완전한 관측성이 아닙니다. Guardrails는 완전한 권한 모델, 감사 로그, 컴플라이언스 승인 흐름이 아닙니다. Checkpoint/thread가 있어도 큐, 데이터베이스, workflow engine이 필요 없어지는 것은 아닙니다.

의사결정 트리: demo가 동작한 뒤 프로덕션으로 가는 길

Agent demo가 이미 동작한다면, 실제 사용자에게 내보내기 전에 이 판단 흐름을 통과해야 합니다.

1단계: 작업 복잡도를 판단합니다

질문: 이 Agent는 짧은 작업/적은 상태로 충분한가요, 아니면 분기와 일시 중지/재개가 필요한가요?

짧은 작업/적은 상태: 단발성 Q&A, 문서 검색 + 요약, 일회성 데이터 처리 등이 예입니다. OpenAI Agents SDK를 추천합니다. 이유는 가볍고 OpenAI 모델과 도구 생태계에 가까우며 복잡한 상태 관리가 필요하지 않기 때문입니다.

분기/일시 중지와 재개 필요: 고객 지원 승인 흐름, 여러 단계의 비즈니스 workflow, 장시간 실행되는 조사 Agent 등이 예입니다. 2단계로 넘어갑니다.

2단계: 도구 생태계와 상태 요구사항을 판단합니다

질문: Agent가 주로 OpenAI 도구 생태계에 의존하나요, 아니면 명시적 상태 그래프가 필요한가요?

OpenAI 도구 생태계 우선: 주로 OpenAI Hosted tools, MCP servers, OpenAI 모델을 사용한다면 OpenAI Agents SDK를 추천합니다. 단, 복잡한 승인 흐름이나 상태 replay가 필요하다면 LangGraph 또는 Temporal + Agents SDK 조합을 검토합니다.

명시적 상태 그래프 필요: 복잡한 분기, 복구, 승인 대기, 상태 replay가 필요한 경우 LangGraph를 추천합니다. 엔지니어링 복잡도는 더 높고 상태 그래프의 설계와 유지가 필요합니다.

3단계: 프로덕션 거버넌스를 판단합니다

질문: 이 Agent는 연구 프로토타입인가요, 아니면 프로덕션 거버넌스가 필요한가요?

연구 프로토타입: multi-agent 대화/협업 연구 또는 팀이 AutoGen/CrewAI 생태계에 익숙한 경우 AutoGen과 CrewAI를 평가합니다. 다만 상태 영속화, 실패 복구, 관측, 권한, 배포는 별도로 확인합니다.

프로덕션 거버넌스: 강한 SLA가 있고 실패 후 retry, rollback, 추적 가능성이 필요한 경우 LangGraph + Temporal 조합을 검토합니다. Temporal은 바깥쪽의 신뢰할 수 있는 비즈니스 workflow를 맡고, LangGraph는 Agent 상태 그래프와 LLM 오케스트레이션을 맡습니다.

판단의 끝점

어떤 프레임워크를 선택하든 출시 전에 다음 능력을 보완해야 합니다.

능력	체크리스트
상태 영속화	checkpoint/thread가 있나요? resume/replay가 가능한가요?
HITL 승인	interrupt/Command resume이 있나요? 승인 흐름이 완성되어 있나요?
관측성	tracing이 팀의 로그/메트릭/알림에 연결되어 있나요?
비용 예산	예산 상한, 비용 추적, 알림이 있나요?
권한 모델	권한 분리, 감사 로그, 컴플라이언스 승인이 있나요?
Eval dataset	회귀 테스트, eval dataset, 지표 정의가 있나요?
실패 복구	retry 로직, rollback 계획, 사람 개입 흐름이 있나요?

다음 단계: OpenAI Agents SDK를 선택한다면 팀 로그/메트릭/알림, 비용 예산, 권한 모델, eval dataset, 실패 복구를 직접 연결해야 합니다. LangGraph를 선택한다면 상태 그래프를 설계하고 persistence backend를 고른 뒤, 관측성, 비용, 권한, eval을 연결해야 합니다. Temporal + Agent 프레임워크 조합을 선택한다면 workflow/activity를 정의하고 retry/timeout을 설정한 뒤 관측성, 비용, 권한을 연결합니다.

다음 단계와 더 읽을 글

프레임워크 방향을 정했다면 엔지니어링 기준별로 더 깊게 들어갈 수 있습니다.

사이트의 기존 글 중 AI Agent 개발 실전: 아키텍처 설계와 구현 가이드는 Agent 아키텍처의 기초로, 컴포넌트 경계, 도구 호출, 상태 설계를 다룹니다. LangGraph 상태 관리 실전은 checkpoint, thread, resume/replay 메커니즘을 설명합니다. LangGraph vs AutoGen 상태 추적 비교는 두 상태 추적 접근을 비교합니다. AI Agent 모니터링, 알림, 실패 복구는 로그, 알림, 실패 복구, 사람 개입으로 이어집니다. Agent 메모리 시스템 설계에서는 단기/장기 메모리와 컨텍스트 관리를 계속 확인할 수 있습니다.

이 시리즈의 후속 글에서는 컨텍스트 엔지니어링, HITL 승인 흐름, 비용 예산과 제어, 권한 모델, 상태 머신 설계, eval dataset과 회귀 테스트, demo에서 프로덕션까지의 전체 출시 체크리스트를 나눠 다룰 예정입니다.

아직 선택 중이라면 먼저 의사결정 트리를 통과하세요. 작업 복잡도, 도구 생태계, 상태 요구사항을 본 뒤 프레임워크를 정합니다. “demo가 동작한다”에서 멈추지 말고, 출시 전에 상태 영속화, HITL 승인, 관측성, 비용 예산, 권한 모델, eval dataset, 실패 복구라는 7가지 기준을 확인하세요.