blog.ruahverce Vol · 2026 · Issue 005 — A field log of LLMs, RAG, and ML systems

Field Log · Entry

OpenAI SDK vs Temporal vs LangGraph — LLM 에이전트 백엔드 비교 2026

OpenAI SDK·LangGraph·Temporal 세 박스가 위에서 아래로 쌓인 계층도 — 만드는 도구·판단 흐름·운영 엔진

OpenAI SDK는 에이전트를 만드는 도구, Temporal은 실행이 끊기지 않게 책임지는 운영 엔진, LangGraph는 에이전트 머릿속 판단 흐름을 그리는 도구 — 셋은 경쟁이 아니라 다른 층입니다. 이 글은 LLM 에이전트를 데모까지 만든 뒤 “그래서 이걸 어떻게 운영하지?”에서 막힌 분들을 위해 그 세 자리를 한 장으로 정리합니다. 사내 RAG를 굴리다 보면 이 세 층이 자연스럽게 보입니다.

이 글이 답하는 질문

  • OpenAI SDK만으로 충분한가, 무엇이 깨질 수 있는가?
  • Temporal은 결국 RabbitMQ나 FastAPI랑 무엇이 다른가?
  • LangGraph가 있는데도 Temporal이 또 필요한 이유는?

”코드는 잘 돌아갔는데 왜 50번째에서 죽었지?”

데모는 잘 도는데, 사용자가 50번째 질문을 던지자마자 컨테이너가 재배포되고 대화 상태가 사라집니다. 30초짜리 LLM 호출 도중 네트워크가 끊기면 에이전트는 어디서부터 다시 시작할지 모릅니다. 새벽에 비용 알람이 울리고, 뜯어보면 도구 호출이 같은 자리에서 빙빙 돌고 있습니다.

문제는 모델이 아니라 인프라와 아키텍처입니다. 한 개발자가 약 5시간 동안 LLM 에이전트가 무한 루프에 빠져 16억 토큰 가까이 소비했다는 보고가 있습니다(Medium 분석). 금액 추정치는 사람마다 다르게 옮기지만, “에이전트가 죽거나 멈추지 않는다”는 운영 위험은 모두 인정합니다.

여기서부터는 SDK 한 줄로 풀리지 않는 영역입니다. 오래 도는·중간에 죽어도 다시 일어나는·비용을 통제하는 에이전트가 되려면 누군가 실행 과정을 끝까지 책임져야 합니다.

30초 용어 사전

이 글에서 반복해서 쓰는 단어들입니다. 한 번만 읽고 본문으로 가셔도 됩니다.

용어한 줄 정의
Workflow”이 일의 시작부터 끝까지” 전체 시나리오. Temporal에서는 결정적(deterministic) 코드로 작성된 오케스트레이션 로직.
Activity외부 세계와 부딪히는 한 단계 — API 호출, DB 쓰기, LLM 호출 등. 실패 시 자동 재시도 대상.
Durable Execution워커가 죽거나 네트워크가 끊겨도 워크플로우의 진행 상태가 보존되어 끝까지 실행되는 성질.
Event Sourcing / Event History모든 단계를 append-only 로그로 기록해두는 방식. 워커가 죽으면 이 로그를 재생(replay)해서 상태를 복원.
Node / EdgeLangGraph 용어. 노드는 “상태를 받아 상태를 반환하는 함수”, 엣지는 “다음에 어느 노드로 갈지”.
CheckpointerLangGraph가 노드 경계마다 상태를 외부 저장소에 적어두는 컴포넌트. 노드 사이에서만 동작.
Agent LoopOpenAI Agents SDK의 Runner가 도는 루프 — LLM 호출 → 도구 실행 → 다음 행동 결정을 반복.

용어가 헷갈리는 건 정상입니다. 이 단어들이 같은 개념을 다른 층에서 부르는 이름이라는 점만 잡고 가시면 됩니다.

셋은 같은 층이 아니다 — 한 장으로 보는 계층도

가장 헷갈리는 건 “셋 중 무엇을 골라야 하나”라는 질문 자체입니다. 골라야 할 게 아니라, 각자 다른 층에 살고 있다고 봐야 합니다.

[ 사용자 / 외부 시스템 ]
        │
        ▼
[ FastAPI ]                ← 요청을 받는 API 입구
        │
        ▼
[ Temporal Workflow ]      ← 운영 엔진 (실행이 죽지 않게 책임짐)
        │
        ▼
[ Activity (도구 단위) ]   ← 외부 호출 하나하나
        │ ├─ LLM 호출 Activity
        │ ├─ DB 쓰기 Activity
        │ └─ LangGraph 실행 Activity
        ▼
[ LangGraph ]              ← 에이전트 머릿속 판단 흐름 (노드·엣지)
        │
        ▼
[ OpenAI Agents SDK ]      ← LLM + 도구를 묶는 얇은 추상화
        │
        ▼
[ LLM (OpenAI / Anthropic 등) ]

한 줄 비교표로 옮기면 이렇게 됩니다.

도구역할한 마디로깨질 때 책임
OpenAI Agents SDKLLM + 도구를 묶는 추상화”요리사에게 도구 쥐어주기”깨지면 메모리에서 사라짐
TemporalDurable Execution Engine”끝까지 실행 보장”워커가 죽어도 상태가 살아남음
LangGraph에이전트 판단 흐름 그래프”레시피 그리기”노드 사이 상태만 저장
FastAPIHTTP API 입구”주문 카운터”요청 받고 핸들러에 넘김
RabbitMQ메시지 큐 (transport)“택배 회사”메시지는 전달, 워크플로우 상태는 모름

식당 비유로 한 번 더 정리하면 이렇습니다. FastAPI는 주문을 받는 카운터, LangGraph는 레시피, Temporal은 주방 전체가 안 죽도록 관리하는 운영 시스템, OpenAI SDK는 재료를 다루는 요리사 본인. 다섯이 다 한 식당에 필요한 자리입니다.

OpenAI Agents SDK는 무엇을 잘하고, 어디서 깨지는가

OpenAI Agents SDK는 LLM에 instructions와 tools를 묶고, Runner가 “LLM 호출 → 출력 처리 → 다음 행동”의 루프를 돌려주는 얇은 추상화입니다. 공식 문서는 핵심 요소를 Agents, Handoffs, Guardrails 세 가지로 정리합니다(OpenAI Agents Python).

미니 코드로 보면 SDK의 “얇음”이 더 잘 보입니다.

from agents import Agent, Runner, function_tool

@function_tool
def search_docs(query: str) -> str:
    return retrieve_from_db(query)

agent = Agent(
    name="rag-agent",
    instructions="사내 매뉴얼만 근거로 답한다.",
    tools=[search_docs],
)

result = await Runner.run(agent, "장비 A의 점검 주기는?")
print(result.final_output)

이 코드, 노트북에서는 잘 돕니다. 그런데 운영에 올리면 적어도 여섯 자리에서 부서집니다.

  1. 프로세스 크래시 — 컨테이너 재시작 시 진행 중이던 에이전트와 단일 프로세스 메모리의 Session이 함께 증발합니다.
  2. 레이트리밋·재시도 부재 — LLM API가 429를 뱉으면 SDK는 그대로 멈춥니다. backoff 전략은 직접 짜야 합니다.
  3. 네트워크 단절 — 30초짜리 도구 호출 도중 워커가 죽으면 “어디까지 했는지”를 기억해주는 사람이 없습니다.
  4. 배포 중 상태 소실 — kubectl rollout이 한 번 일어나면 진행 중이던 대화가 모두 끊어집니다.
  5. 세밀한 타임아웃 부재 — max_turns로 전체 루프는 막을 수 있지만, 도구 단위 SLA는 별도로 없습니다.
  6. 비용 폭주 — 도구가 같은 자리에서 빙빙 돌아도 SDK는 멈출 이유를 모릅니다. 무한 루프 한 번이 곧 청구서입니다.

SDK가 못 만든다는 얘기가 아닙니다. SDK가 책임지는 영역이 거기까지라는 뜻입니다. 공식 문서도 “the runtime to manage turns, tool execution, guardrails, handoffs, or sessions”까지를 SDK의 영역으로 명시합니다. 인프라 안정성은 이 목록에 없습니다.

Temporal: 에이전트가 죽어도 다시 시작하는 운영 엔진

Temporal은 “워크플로우가 죽지 않게 끝까지 끌고 가는 엔진”입니다. 공식 정의는 짧지만 약속이 무겁습니다.

“Durable Execution means a Workflow Execution maintains its state and progress despite failures or outages.” — Temporal Docs

비유로 풀면 이렇습니다. RabbitMQ가 “이 박스를 저쪽으로 보내줘”라고 맡기는 택배 회사라면, Temporal은 “이 6단계 프로젝트를 끝까지 책임지고 끌고 가줘. 중간에 누가 죽으면 어디까지 했는지 기억하고 거기서부터 다시 시작해줘”라고 맡기는 프로젝트 매니저입니다. transport와 execution engine은 다른 층입니다.

작동 원리는 단순합니다. Workflow의 모든 단계가 append-only Event History에 기록되고, 워커가 죽으면 그 로그를 재생(replay) 해서 상태를 복원합니다(Event History).

그래서 Workflow 코드는 결정적(deterministic) 이어야 합니다. time.time(), random.random(), 네트워크·파일 I/O, DB·LLM·외부 API 호출처럼 비결정적인 작업은 Workflow 본문에서 금지되고, 모두 Activity라는 별도 단위로 빠집니다. Activity 결과만 Event History에 남고, 재시도도 Activity 단위에서 일어납니다. LLM 호출이 Activity로 빠져야 하는 이유는 여기서 자연스럽게 따라옵니다.

다만 Event History도 무한하지는 않습니다.

“The Workflow Execution’s Event History is limited to 51,200 Events or 50 MB and will warn you after 10,240 Events or 10 MB.” — Workflow Execution Limits

LLM 응답은 토큰이 무거워서 매 turn마다 전체 히스토리를 Activity 결과로 받으면 Event History가 빠르게 부풉니다. 커뮤니티에서 자주 권하는 패턴 두 가지: (1) 큰 페이로드는 S3·DB에 저장하고 Activity에는 reference ID만 반환, (2) 메시지 히스토리는 주기적으로 요약 Activity로 압축. 한도에 닿기 전이라면 continue_as_new로 새 Workflow Execution을 이어 붙입니다.

운영 사례도 풍부합니다. Netflix는 차세대 CI/CD의 토대로 Temporal을 선택했고(공식), Stripe·Snap·DoorDash·Coinbase도 in-use 페이지에 이름을 올렸습니다. 한국에서는 코빗(Korbit) 이 입출금 자동화 시스템 Chronos를 Temporal 위에 구축하며 “워크플로우의 실행 보장과 스케줄링까지 완벽하게 제공한다”고 정리했습니다(코빗 기술 블로그).

LangGraph: 에이전트 머릿속 판단 흐름을 그리는 도구

LangGraph는 에이전트가 무엇을 고민하고 어디로 분기하는지를 코드로 그리는 도구입니다. 공식 정의는 “long-running, stateful agents를 위한 low-level orchestration framework and runtime”입니다(LangGraph Overview).

핵심 구성요소는 단순합니다 — State(TypedDict·Pydantic으로 정의한 그래프 상태), Node(state를 받아 state를 반환하는 함수), Edge / Conditional Edge(노드 간 전이·분기), Checkpointer(MemorySaver, PostgresSaver 등이 노드 경계마다 상태를 외부에 적음).

LangGraph도 durable execution을 표방합니다. 다만 입자(granularity) 가 다릅니다.

“LangGraph’s durable execution creates checkpoints at node boundaries. When a workflow resumes after an interruption or failure, it restarts from the beginning of the node where execution stopped.” — Thinking in LangGraph

한 줄로 옮기면 체크포인트는 노드 사이에서만 만들어진다. 노드 안에서 30초짜리 LLM 호출 도중 워커가 죽으면 그 노드는 처음부터 재실행됩니다. Temporal이 Activity 단위로 결과를 영구 기록하고 재시도하는 것과 비교하면 입자가 굵습니다.

그래서 LangGraph는 “한 워크플로우 안에서 LLM이 어떤 판단 분기를 그리는가”를 표현하기에 적합하고, “이 그래프가 24시간 죽지 않고 돌아가야 한다”는 인프라 약속은 별개 층에서 받쳐줘야 합니다. 같은 단어(“durable execution”)를 쓰지만 가리키는 단위가 다릅니다(AgentMarketCap 2026-04-08이 이 차이를 잘 정리합니다).

셋이 합쳐진 실전 아키텍처

2026년 3월 23일 Temporal × OpenAI Agents SDK 통합이 GA로 풀리면서, 권장 조합이 또렷해졌습니다.

[사용자]
   │
   ▼
[FastAPI] ── POST /agents/run ──▶ [Temporal Client.start_workflow]
                                       │
                                       ▼
                         ┌──── [Temporal Workflow] ─────┐
                         │  결정적 오케스트레이션         │
                         │  ├─ Activity: 사용자 권한 검사 │
                         │  ├─ Activity: LangGraph 실행  │
                         │  │     └─ 내부에서 OpenAI SDK │
                         │  ├─ Activity: 결과 저장       │
                         │  └─ Activity: 알림 전송       │
                         └──────────────────────────────┘
                                       │
                                       ▼
                            [Event History (durable)]

핵심 두 가지 도구가 통합 패키지에 들어 있습니다. OpenAIAgentsPlugin 은 Temporal Client에 붙어 LLM 호출을 자동으로 Activity로 래핑하고, activity_as_tool 은 Temporal Activity를 OpenAI Agent의 tool 스키마로 자동 변환합니다(Temporal AI Cookbook).

# Temporal Client + OpenAIAgentsPlugin
from datetime import timedelta
from temporalio.client import Client
from temporalio.contrib.openai_agents import (
    OpenAIAgentsPlugin,
    ModelActivityParameters,
)

client = await Client.connect(
    "localhost:7233",
    plugins=[
        OpenAIAgentsPlugin(
            model_params=ModelActivityParameters(
                start_to_close_timeout=timedelta(seconds=30),
            )
        ),
    ],
)
# Workflow 내부에서 Activity를 tool로 노출
from temporalio import workflow
from temporalio.contrib.openai_agents import activity_as_tool
from agents import Agent

@workflow.defn
class RagAgentWorkflow:
    @workflow.run
    async def run(self, question: str) -> str:
        agent = Agent(
            name="rag-agent",
            instructions="사내 매뉴얼만 근거로 답한다.",
            tools=[activity_as_tool(search_docs_activity)],
        )
        result = await agent.run(question)
        return result.final_output

Temporal 공식 표현으로 통합의 의미는 “every agent interaction, including LLM calls, tool executions, and external API requests, is captured as part of a deterministic workflow”입니다(InfoQ 보도).

LangGraph를 끼우는 자리도 명확합니다. LangGraph 자체는 비결정적이므로 Workflow 본문이 아니라 Activity 안에서 호출됩니다. Workflow는 “이 Activity가 끝까지 가도록 책임”만 지고, Activity 내부에서는 LangGraph가 노드·엣지를 따라 LLM과 도구를 자유롭게 호출합니다. macro-level은 Temporal, micro-level은 LangGraph라는 분업이 자연스럽게 나옵니다(Two-layer 아키텍처).

언제 무엇을 쓰나 — 의사결정 매트릭스

질문은 보통 셋 중 하나입니다. “OpenAI SDK만으로 갈까?”, “LangGraph까지 갈까?”, “Temporal을 진지하게 도입할까?”. 아래 표가 결정을 단순화해줍니다.

상황OpenAI SDK 단독+ LangGraph+ Temporal
단발 호출, 1~2 turn✅과함과함
도구 5개 이상, 분기 다수가능하지만 복잡✅◯
실행 시간 분~시간 단위△ (위험)△✅
휴먼 인 더 루프어려움가능✅
여러 서비스에 걸침어려움어려움✅
24/7 무중단·재시도 보장✗△✅
감사 로그·재현성 요구✗△✅
비용 폭주 가드레일 직접 짤 여유 없음위험위험✅

요약: 분기가 많아지면 LangGraph, 죽지 않아야 하면 Temporal. 이 두 축이 의사결정을 거의 다 가릅니다.

솔직한 이야기: Temporal 안 써도 되는 경우

Temporal을 권하는 글이 많아서 균형을 잡습니다. 다음 중 하나에 해당하면 Temporal은 오버킬입니다.

  • 워크플로우가 길어야 1~2분, 실패해도 “다시 눌러주세요”가 허용되는 경우
  • 단일 사용자 도구, 사이드 프로젝트, 사내 PoC 단계
  • 팀이 1~2명이라 Temporal Service 운영 부담이 신뢰성 요구보다 큰 경우
  • 이미 잘 작동하는 Celery·RQ·BullMQ 큐가 있고 “메시지 단위 신뢰성”만 필요한 경우

비용 감각도 짚어둡니다. Temporal은 Apache 2.0 OSS라 라이선스는 무료지만 self-hosted 운영 부담이 큽니다. Temporal Cloud는 Essentials $100/월 또는 사용량의 5% 중 큰 값, Business는 $500/월 또는 10%부터 시작합니다(Temporal Pricing). 토이 프로젝트에선 “월 10만 원대를 신뢰성에 쓸 가치가 있는가”가 진짜 질문입니다.

거꾸로 말하면 결제 처리·사내 RAG·정산·승인 워크플로우처럼 한 번의 실패가 비용·법적 리스크로 이어지는 경우는 망설일 이유가 줄어듭니다. 무한 루프 한 번이 청구서로 돌아오는 LLM 영역도 점점 그쪽에 가까워지고 있습니다.

자주 묻는 질문 (FAQ)

Q1. Temporal을 무조건 써야 하나요? A. 아니요. 짧은 단발 호출·낮은 실패율·작은 팀이면 불필요합니다. (1) 워크플로우가 분시간일 단위로 길거나, (2) 중간에 죽으면 비용·신뢰 손실이 크거나, (3) 휴먼 인 더 루프가 있거나, (4) 여러 서비스에 걸쳐 있는 경우 — 이 중 둘 이상이면 진지하게 검토할 가치가 있습니다.

Q2. Celery / RabbitMQ / Airflow와 무엇이 다른가요? A. Celery·RabbitMQ는 transport(“메시지를 저쪽으로”), Airflow는 batch scheduler(“DAG를 매일 새벽 3시에”), Temporal은 durable execution engine(“이 워크플로우를 끝까지”)입니다. Temporal에서는 코드 자체가 상태입니다.

Q3. LangGraph만으로도 checkpoint가 되는데 Temporal이 또 필요한 이유는요? A. LangGraph checkpoint는 노드 경계에서만 만들어집니다. 노드 안에서 30초짜리 LLM 호출 도중에 죽으면 그 노드는 처음부터 재실행됩니다. Temporal은 Activity 단위로 결과가 Event History에 영구 기록되고, Temporal Service가 별도 프로세스로 운영되므로 신뢰성 수준 자체가 다릅니다.

Q4. OpenAI Agents SDK의 Session/Tracing은 Temporal과 겹치지 않나요? A. 다른 층입니다. Session은 “이 대화의 메시지 히스토리”를, Tracing은 “한 번의 실행 안의 이벤트”를 관리합니다. Temporal은 “워크플로우 전체의 실행 상태”를 워커가 죽어도 보존합니다. 공식 통합에선 Session도 Workflow state로 직렬화됩니다.

Q5. Temporal이 너무 비싸지 않나요? A. Self-hosted는 라이선스 무료이지만 운영 인건비가 듭니다. Cloud는 Essentials 약 $100/월부터 시작합니다(공식 가격). 기준은 “도입 비용”이 아니라 “대안의 실패 비용”입니다. 결제 한 건 중복 실행이 한 번이라도 청구서·법적 리스크로 이어지면 Cloud 한 달치보다 비쌉니다.

Q6. LangGraph + Temporal을 같이 써도 되나요? A. 가능하고 권장 패턴 중 하나입니다. Temporal Workflow가 매크로(retry·persistence·scheduling)를 잡고, 그 안의 Activity가 LangGraph 실행을 수행합니다. 단 LangGraph는 비결정적이므로 Workflow 본문이 아니라 Activity 안에서 호출해야 합니다.

Q7. 에이전트 무한 루프는 어떻게 막나요? A. 세 층에서 가드레일을 동시에 겁니다. (1) OpenAI SDK의 max_turns, (2) LangGraph 노드의 step 카운터·조건부 종료 엣지, (3) Temporal Workflow의 시그널·타임아웃·재시도 정책. 한 층만으로는 부족합니다.

마무리

세 가지만 가져가시면 됩니다.

  1. OpenAI Agents SDK는 만드는 도구입니다. 만드는 것까지만 책임지고, 끝까지 가는 일은 약속하지 않습니다.
  2. Temporal은 운영 엔진입니다. 워커가 죽고 네트워크가 끊겨도 워크플로우를 끝까지 끌고 갑니다.
  3. LangGraph는 판단 흐름을 그리는 도구입니다. 노드·엣지로 에이전트 머릿속을 표현하지만, 노드 안에서의 신뢰성은 별개 층에서 받쳐야 합니다.

사내 RAG를 운영하다 보면 SDK·LangGraph로 모델링한 흐름이 인프라 한 층 밑에서 무너지는 자리를 자주 만납니다. Temporal은 그 한 층을 사람이 안 들고 있도록 비워주는 도구라는 게 지금의 정리입니다. 같은 운영 관점의 연결 글로는 그래프 DB로 도메인 RAG 만들기 시리즈가 있습니다.

참고자료