LangGraph 상태 머신으로 프로덕션 에이전트를 설계할 때 실제로 부딪히는 것들

LangGraph는 2025년 말 안정 버전 v1.0을 출시한 이후 엔터프라이즈 프로덕션 에이전트 프레임워크로 채택이 빠르게 늘고 있다. GitHub 스타 3만 개를 돌파했고 Klarna, LinkedIn, Uber, Replit 같은 기업들이 실제 프로덕션에 붙였다. 상태 머신 기반의 방향 그래프(directed graph) 설계가, 기존 선형 파이프라인이 풀지 못했던 멀티스텝 워크플로우의 안정성·제어 가능성 문제를 정면으로 다룬다.

사이클을 허용한다는 것의 의미

LangGraph의 핵심은 StateGraph다. 에이전트의 제어 흐름을 노드(node)와 엣지(edge)로 구성된 그래프로 모델링하는데, 각 노드는 함수나 LLM 호출을 실행하고 엣지는 다음 노드를 결정한다. DAG(방향 비순환 그래프)만 허용하는 기존 프레임워크와 결정적으로 다른 점은 사이클(cycle)을 지원한다는 것 — 에이전트가 루프를 돌며 재시도하거나 반성(reflection)할 수 있는 이유다.

상태(State)는 TypedDict 또는 Pydantic 모델로 정의되고, 모든 노드가 공유하는 불변(immutable) 스냅샷으로 관리된다. Annotated 리듀서로 병렬 브랜치 간 상태 병합 충돌을 막을 수 있다. LangChain의 2026 State of Agent Engineering 보고서에 따르면 프로덕션 에이전트 인시던트의 60% 이상이 상태 관리 문제에서 나오는데, 그만큼 상태 스키마 설계가 LangGraph 프로젝트에서 가장 무거운 아키텍처 결정이라는 뜻이다.

⤢✕

조건부 엣지(conditional edge)가 상태를 보고 동적으로 다음 노드를 고른다는 게 LangGraph를 단순 체인(chain)이 아니라 진짜 상태 머신으로 만드는 지점이다.

체크포인트가 지켜주는 것과 지켜주지 못하는 것

LangGraph의 체크포인팅 시스템은 노드 실행이 끝날 때마다 상태 스냅샷을 자동 저장한다. 프로세스가 재시작되거나 장애가 나도 마지막 체크포인트 지점부터 실행을 재개할 수 있다. 체크포인터 선택은 배포 규모를 따라간다 — 개발 환경은 별도 인프라가 필요 없는 InMemorySaver, 단일 서버 프로덕션은 경량 파일 기반의 SqliteSaver, 멀티 인스턴스 스케일에서는 수평 확장이 되는 AsyncPostgresSaver/PostgresSaver, 고가용성 환경에서는 RedisSaver/DynamoDBSaver를 쓴다.

여기서 놓치기 쉬운 한계가 있다. 체크포인터는 노드 사이(between nodes)의 상태만 저장하고, 노드 내부(inside a node)에서 실행 중인 중간 상태는 저장하지 않는다. 그래서 오래 걸리는 단일 노드 작업은 Temporal 같은 별도의 내구성 실행 레이어로 감싸야 한다. Kubernetes 환경의 프로덕션 배포는 PostgreSQL이나 Redis 체크포인터를 필수로 쓰고, FastAPI로 에이전트 엔드포인트를 래핑하며, HPA(Horizontal Pod Autoscaler)로 부하에 따라 자동 확장하는 패턴이 표준으로 굳어졌다.

사람이 끼어들어도 스레드는 블로킹되지 않는다

완전 자율 에이전트는 엔터프라이즈 환경에서 위험하다. LangGraph의 interrupt 메커니즘은 특정 노드에서 실행을 일시 중단하고 상태를 UI에 노출해 사람이 승인·거부·수정을 결정하게 한다. 중요한 건 이 대기 과정이 서버 스레드를 블로킹하지 않는다는 점이다 — 사람의 응답이 몇 초 후에 오든 몇 시간 후에 오든, 에이전트는 정확히 중단된 지점에서 실행을 재개한다.

⤢✕

실전에서는 위험도(risk level)에 따라 인터럽트 조건을 차별화하는 게 효율적이다. 낮은 위험도의 작업은 자동 진행시키고, 외부 API 호출·데이터 삭제·금융 거래처럼 높은 위험도의 작업만 인터럽트를 걸어야 승인 큐가 병목이 되지 않는다.

LLM 토큰, 도구 호출, 상태 업데이트, 노드 전환 이벤트는 모두 스트리밍으로 나온다. 프론트엔드는 보통 React + WebSocket이나 SSE(Server-Sent Events)로 이 진행 상황을 구독한다. 내구성 있는 SSE 구현에서는 EventSource Last-Event-ID와 서버 사이드 재생 버퍼(replay buffer)를 조합해 네트워크 단절 후 재연결 시 놓친 이벤트를 복원한다.

배포 필라와 계층형 모니터링

엔터프라이즈 LangGraph 배포의 프로덕션 필라(pillar)는 네 가지다. PostgreSQL을 활용한 영속적 상태 관리(체크포인팅), LangSmith 트레이싱 통합(관찰 가능성), 인터럽트 기반 Human-in-the-Loop(거버넌스), 그리고 LangGraph Platform이나 자체 호스팅 컨테이너(배포 대상)다.

모니터링 지표는 세 계층으로 나뉜다. 인프라 계층(CPU, 메모리, 레이턴시), 에이전트 계층(노드별 실행 시간, 상태 전환 빈도, 인터럽트 발생률), LLM 계층(토큰 사용량, 모델별 비용, P50/P99 응답 시간). 이 세 계층을 통합 대시보드로 묶어야 장애 지점을 빠르게 짚을 수 있다.

오류는 크게 세 유형으로 갈린다. 네트워크 타임아웃·API 속도 제한 같은 일시적 오류(Transient Error)는 지수 백오프(exponential backoff) 재시도로, 잘못된 상태 전환·스키마 불일치 같은 상태 오류(State Error)는 마지막 유효 체크포인트로의 롤백으로, 비즈니스 로직 실패·외부 시스템 불가용 같은 치명적 오류(Fatal Error)는 Dead Letter Queue 이관 후 알림으로 대응한다. 재시도 노드를 별도로 두어 오류 컨텍스트를 상태에 기록하고, 최대 재시도 횟수를 넘기면 인간 검토 큐로 넘기는 패턴이 가장 안정적이다. 재시도 횟수는 상태 필드로 관리해 무한 루프를 막아야 한다.

LangSmith는 2026년 기준 에이전트 엔지니어링의 사실상 표준 관찰 가능성 플랫폼이다. LangGraph와의 통합은 업계에서 가장 깊은 수준으로, 노드별 상태 diff, 전체 에이전트 실행 그래프, 모델·도구 호출 세부 내역, 새 모델 버전에 대한 리플레이를 제공한다. 트레이스 시각화로 병목 구간을 식별하고, 사용자 피드백을 트레이스와 연결해 품질 데이터셋을 쌓고, 워크플로우 단위로 LLM 비용을 집계하고, 프로덕션 트레이스를 테스트셋 삼아 자동화 평가를 돌린다. 데이터 주권(data residency) 요건이 있는 기업을 위해서는 자체 Kubernetes 클러스터(AWS, GCP, Azure)에 배포하는 BYOC(Bring Your Own Cloud) 옵션도 있다.

비결정론을 반영한 SLA

기존 소프트웨어 SLA와 달리 에이전트 SLA는 비결정론적(non-deterministic) 특성을 반영해야 한다.

지표	정의	목표 기준
TTFR (Time to First Response)	첫 번째 토큰 스트리밍까지 소요 시간	P99 < 3초
태스크 완료율	오류 없이 완료된 에이전트 실행 비율	> 99.5%
재시도 비율	전체 노드 실행 대비 재시도 비율	< 2%
인터럽트 해소 시간	Human-in-the-Loop 승인 대기 시간	P50 < 4시간
비용 per 태스크	태스크당 LLM 토큰 비용	정의된 예산 범위 이내

SLA를 위반하면 PagerDuty나 Slack 웹훅으로 즉각 알림을 보내고, 에이전트를 더 단순한 프롬프트나 더 빠른 모델의 폴백 모드로 자동 전환하는 조치까지 설계해야 실제로 쓸모가 있다.

Temporal, Airflow와는 어디서 갈리는가

LangGraph와 Temporal은 다른 문제를 풀도록 설계됐지만, 2026년 현재 많은 팀이 둘을 함께 쓰는 하이브리드 아키텍처를 택하고 있다.

⤢✕

구분	LangGraph	Temporal
설계 목적	LLM 에이전트 상태 머신	범용 내구성 실행 시스템
제어 흐름	모델이 결정 (동적)	개발자가 정의 (정적)
상태 저장 단위	노드 간 경계	액티비티(Activity) 단위
프로덕션 채택	Klarna, LinkedIn, Replit	OpenAI Codex (프로덕션)
학습 곡선	중간	높음
LLM 최적화	네이티브 지원	별도 통합 필요

Temporal의 강점은 노드 내부 실행까지 내구성을 보장한다는 것이다. OpenAI는 Codex 에이전트를 Temporal로 실행하는데, 며칠씩 인간 승인을 기다리거나 서버가 재시작돼도 워크플로우를 완벽히 재개한다. LangGraph만으로는 노드 내부 실행 중 장애가 나면 해당 노드 전체를 다시 실행해야 하는 한계가 있다.

Prefect와 Airflow는 결이 다른 도구다. 데이터/배치 파이프라인 오케스트레이터로, 정해진 스텝을 실행하고 재시도·스케줄링을 플랫폼이 처리한다. LangGraph는 그 안에서 모델이 다음에 어떤 도구나 모델을 호출할지 스스로 결정하는 에이전트 오케스트레이터다. AI 워크플로우 오케스트레이션은 세 개념으로 나눠 보면 헷갈리지 않는다 — 모델에 데이터를 공급하는 스케줄된 파이프라인은 데이터/배치 오케스트레이션(Airflow, Prefect), 장기 실행·장애 허용 멀티스텝 프로세스는 내구성 실행(Temporal), AI 애플리케이션 내부의 제어 루프는 에이전트 오케스트레이션(LangGraph)이다. Prefect는 데이터 팀·분석 워크플로우에 최적화된 코드 우선(code-first) 도구라 LangGraph와 경쟁 관계라기보다 상호 보완적이다.

전통적 설계 패턴이 그대로 들어맞는 이유

LangGraph의 상태 머신 에이전트 설계는 전통적인 SW 아키텍처 패턴과 직접 연결된다. StateGraph는 GoF 상태 패턴(State Pattern)의 구현체로, 상태에 따라 동작이 달라지는 에이전트 로직을 캡슐화한다. 각 노드 함수는 커맨드 패턴(Command Pattern)의 execute() 메서드에 해당하고, 취소(undo)와 재시도는 체크포인트로 구현된다. LangSmith 트레이싱은 에이전트 그래프의 이벤트를 구독하는 옵저버 패턴(Observer Pattern)이다. 선형 워크플로우는 파이프라인 패턴(Pipeline Pattern)의 체인으로 충분하지만, 동적 분기가 필요한 복잡한 워크플로우는 LangGraph로 넘어가는 게 맞다. 새 프레임워크를 배운다기보다, 익숙한 아키텍처 지식을 에이전트 시스템 설계에 그대로 옮겨 적용하는 셈이다.

하이브리드 스택으로 수렴하는 이유

2026년 중반 현재, 규모 있는 에이전트를 운영하는 팀들은 같은 벽에 부딪힌다. 프로세스 재시작 시 에이전트 상태가 사라지고, 도구 호출 타임아웃 후 재시도 루프가 이전 시도를 잊어버리는 문제다. 해법은 더 나은 단일 프레임워크가 아니라 각 계층에 최적화된 도구를 조합한 하이브리드 스택이다. 실용적인 2026 패턴은 에이전트 라우팅·컨텍스트 관리는 LangGraph StateGraph, 내구성 실행 보장은 Temporal(특히 장기 실행 워크플로우), 관찰 가능성은 LangSmith와 외부 APM 도구, 배포 인프라는 Kubernetes + PostgreSQL 체크포인터 + HPA로 나눠 맡기는 조합이다. LangGraph의 유연한 에이전트 로직과 Temporal의 내구성 실행 보장을 결합해야 엔터프라이즈 수준의 신뢰성에 도달한다.