LangGraph vs AutoGen 상태 추적 비교: checkpoint 메커니즘, 타임아웃 복구와 선택 기준

30단계짜리 연구 문헌 정리 Agent가 무려 2시간 40분 동안 실행되었습니다.

25단계에서 데이터베이스 인터페이스가 타임아웃으로 무너졌습니다.

앞선 24단계는 전부 헛수고가 되었습니다. API 호출 비용, 대기 시간, 이미 생성한 문헌 요약까지 모두 0으로 돌아갔습니다.

드문 사례가 아닙니다. 저는 AutoGen으로 복잡한 워크플로를 만든 적이 있는데, 상태를 제어하기 어려웠고 Agent가 엉뚱한 방향으로 달렸으며 문제를 추적하는 데 개발 시간의 3배를 썼습니다. 이후 LangGraph로 바꿨더니 간단한 프로토타입에도 상태 정의 코드가 100줄 넘게 필요했습니다. 두 프레임워크 모두에서 함정을 밟아본 셈입니다.

LangGraph vs AutoGen의 상태 관리는 설계 철학부터 완전히 다릅니다. 하나는 명시적 상태 머신으로 흐름을 제어하고, 다른 하나는 대화형 프로토콜로 Agent가 자유롭게 협상하게 합니다. 프레임워크를 잘못 고르면 Agent 프로젝트의 80%는 대형 모델 능력이 부족해서 실패하는 것이 아닙니다. 상태 추적이라는 길을 처음부터 잘못 들어섰기 때문입니다.

이 글은 Checkpoint 메커니즘, 타임아웃 복구, 분산 지원 등 12개 차원에서 두 프레임워크를 비교하고, 실제 시행착오 사례, 선택 의사결정 트리, 실행 가능한 코드를 함께 제공합니다. 읽고 나면 당신의 프로젝트에는 과연 어느 쪽이 맞는지 빠르게 판단할 수 있을 것입니다.

상태 관리의 생명선: 왜 Checkpoint는 Agent의 생명줄인가

저는 고객을 위해 연구 문헌 정리 Agent를 만들었습니다. 학술 데이터베이스 API를 10번 연속 호출하고, 논문 200편의 초록을 정리한 뒤, 리뷰 보고서를 생성하는 작업이었습니다.

예상 실행 시간은 3시간이었습니다. 전체 30단계 중 25단계까지 갔을 때 데이터베이스 인터페이스가 타임아웃으로 무너졌습니다.

전통적인 Agent는 상태가 없습니다. 앞선 24단계가 전부 헛수고가 됩니다. 이미 생성한 문헌 요약, API 호출 비용, 2시간 40분의 대기 시간이 모두 사라집니다. 다시 실행하려면 처음부터 시작해야 하고 API 비용도 한 번 더 태워야 합니다.

고객이 물었습니다. 25단계부터 이어서 실행할 수는 없나요?

대답은 불가능이었습니다. 전통적인 Agent의 상태는 메모리에만 존재하고, 프로세스가 끊기면 함께 사라집니다.

전통적인 무상태 Agent의 5가지 치명적 문제

저도 이 함정을 겪었습니다. 당시 AutoGen으로 복잡한 애프터서비스 티켓 처리 흐름을 만들었는데 상태가 제어되지 않았고, Agent가 흐름을 벗어났으며, 문제를 추적하는 데 개발 시간의 3배를 썼습니다. 나중에 LangGraph로 상태 그래프를 정의했더니 간단한 프로토타입에도 100줄이 넘는 코드가 필요했습니다.

정리하면 전통적인 무상태 Agent에는 치명적인 문제가 5가지 있습니다.

1. 서비스 재시작 후 모든 대화 기록이 손실됩니다

새 버전 배포, 서버 유지보수, 예기치 않은 장애 등 어떤 프로세스 종료도 상태를 비웁니다. 사용자가 진행 중이던 대화는 순식간에 끊깁니다.

2. 다중 턴 작업이 중간에 끊기면 복구할 수 없습니다

긴 흐름의 작업, 예를 들어 연구 문헌 정리나 데이터 처리 파이프라인은 실패하면 처음부터 다시 실행해야 합니다. 30단계 작업의 25단계에서 무너지면 앞선 24단계가 전부 사라집니다.

3. 다중 사용자 동시성을 지원하기 어렵고 상태가 서로 간섭합니다

같은 Agent 인스턴스가 여러 사용자를 서비스하면 상태가 섞입니다. 사용자 A의 대화 기록이 사용자 B의 조작에 의해 덮어써지고 데이터가 오염됩니다.

4. 과거 실행 과정을 감사하거나 재생할 수 없습니다

운영 환경에서 문제가 생겼을 때 당시 Agent가 어떻게 판단했는지 보고 싶어도 기록이 없습니다. Bug를 재현하고 싶어도 과거 상태가 없습니다.

5. 장시간 작업은 한 번 실패하면 전부 다시 해야 합니다

몇 시간짜리 작업, 예를 들어 데이터 처리나 일괄 생성은 실패 비용이 매우 큽니다. API 비용, 시간 비용, 사용자 경험이 모두 손상됩니다.

LangGraph vs AutoGen: Checkpoint 성숙도 비교

LangGraph와 AutoGen의 Checkpoint 능력에는 뚜렷한 차이가 있습니다.

차원	LangGraph	AutoGen
Checkpoint 네이티브 지원	각 노드마다 스냅샷 자동 저장	Roadmap에서 진화 중
운영 성숙도	⭐⭐⭐⭐⭐(2026년 사실상 표준)	⭐⭐⭐(아직 진화 중)
API 안정성	LangChain 생태계 기반으로 안정적	v0.2에서 v0.5로 큰 마이그레이션, 프로젝트 재작업 필요

LangGraph는 설계 초기부터 Checkpoint 메커니즘을 내장했습니다. 각 노드 실행이 끝날 때마다 State 스냅샷을 자동 저장합니다. 장애 후에는 중단 지점부터 복구하며, 이미 완료한 노드를 반복 실행하지 않습니다.

AutoGen의 상태 관리는 아직 진화 중입니다. 2024년 4월 Microsoft는 Persistence roadmap을 발표했고, 2025년 3월에야 Save/Load 능력(AgentChat.NET)이 생겼습니다. AutoGen v0.2로 개발한 프로젝트는 v0.5로 올리면 API가 모두 깨지고 코드를 다시 써야 할 수 있습니다.

Checkpoint는 있으면 좋은 기능이 아닙니다. Agent의 생명줄입니다. 운영 환경에서 상태 지속화가 없다면 사실상 보호 장비 없이 뛰는 것과 같습니다.

LangGraph Checkpoint 메커니즘 심층 해설

Checkpoint의 본질: 메시지를 저장하는 것이 아니라 그래프의 전체 상태를 저장한다

많은 사람이 Checkpoint를 오해합니다. 단순히 대화 기록을 저장하는 기능이라고 생각합니다.

실제로는 그렇지 않습니다.

Checkpoint가 저장하는 것은 특정 실행 단계에서 Graph의 전체 상태 스냅샷입니다. 여기에는 다음이 포함됩니다.

• 모든 Channel, 즉 State의 각 필드 현재 값
• 현재 어느 노드를 실행 중인지
• 부모 체크포인트 ID, 즉 버전 체인
• 타임스탬프와 메타데이터

Git의 commit 히스토리에 비유할 수 있습니다. 각 노드 실행은 하나의 commit을 만들고, 원하는 과거 노드로 checkout해 다시 실행할 수 있습니다. 이는 대화 기록 백업이 아니라 전체 워크플로의 상태 스냅샷입니다.

Checkpoint v4 데이터 구조 자세히 보기

LangGraph는 현재 Checkpoint v4를 사용하며 7개의 핵심 필드를 포함합니다. LangChain 공식 문서의 정의는 다음과 같습니다.

class Checkpoint:
    v: int                  # 버전 번호(현재 4)
    ts: str                  # ISO 형식 타임스탬프
    id: str                  # UUID, 스냅샷의 고유 식별자
    channel_values: dict     # State의 각 필드 현재 값
    channel_versions: dict   # 각 필드의 버전 번호, 충돌 감지에 사용
    versions_seen: dict      # 각 노드가 본 버전을 기록해 중복 처리를 방지
    pending_sends: list      # 발송 대기 중인 메시지 큐

여기서 channel_versions가 중요합니다. 그냥 남는 필드가 아닙니다.

LangGraph는 버전 번호로 특정 노드를 다시 실행해야 하는지 판단합니다. 이것이 중단 지점 재개의 하위 기반입니다. 복구할 때 각 Channel의 버전 번호를 검사하고 이미 실행한 노드는 건너뜁니다.

thread_id: 다중 세션 격리를 위한 평행우주 좌표

하나의 Graph 인스턴스는 수많은 대화 스레드를 서비스할 수 있습니다.

각 스레드는 독립적인 Checkpoint 시퀀스를 가지며 서로 간섭하지 않습니다. 구분 기준은 thread_id입니다.

게임 저장 슬롯에 비유할 수 있습니다. 각 thread_id는 독립적인 저장 파일입니다. 사용자 A의 대화 상태는 사용자 B에게 영향을 주지 않습니다.

config = {"configurable": {"thread_id": "user-001"}}
result = graph.invoke(input, config)

thread_id를 바꾸면 완전히 다른 평행우주가 됩니다.

Super-Step 실행 흐름

LangGraph의 실행 흐름은 Super-Step이라고 부릅니다. LangChain 공식 문서의 설명에 따르면 흐름은 다음과 같습니다.

[이전 Checkpoint 읽기]
  ↓
[현재 노드 실행, State 업데이트]
  ↓
[새 Checkpoint(스냅샷) 쓰기]
  ↓
[다음 단계 결정: 계속/대기/종료]

각 노드 실행이 끝나면 Checkpoint가 자동 저장됩니다. 장애 후 복구할 때는 중단 지점부터 계속합니다.

세 가지 Checkpoint 저장 백엔드 비교

저장 유형	적합한 상황	특징
MemorySaver	개발 및 디버깅	메모리 저장, 재시작 시 손실
SqliteSaver	단일 머신 운영	SQLite 지속화, 가벼움
PostgresSaver	분산 운영	PostgreSQL, pause/resume 및 분산 지원

개발 단계에서는 MemorySaver가 디버깅에 편합니다. 운영 환경에서는 PostgresSaver를 사용하면 분산 배포를 자연스럽게 지원할 수 있습니다.

RedisSaver는 고동시성 상황에 적합하며 읽기와 쓰기 속도가 빠릅니다.

중단 지점 재개 실전

처음 사례로 돌아가 보겠습니다. 30단계 연구 문헌 정리 Agent가 25단계에서 타임아웃으로 실패했습니다.

LangGraph의 Checkpointer를 사용하면 중단 지점에서 복구할 수 있습니다.

# 7단계 실패 후 복구
config = {"configurable": {"thread_id": "research-001"}}
recovered_state = compiled_graph.invoke({"step": 7}, config)
# 앞선 6단계를 자동으로 건너뛰고 7단계부터 계속

같은 thread_id로 가장 최근 Checkpoint를 불러와 계속 실행합니다.

앞선 24단계는 반복 실행되지 않습니다. API 비용과 생성된 내용이 모두 보존됩니다.

AutoGen 상태 추적의 현재: Roadmap 진화가 만든 비용

상태 관리 Roadmap의 진화 과정

AutoGen의 상태 관리는 아직 진화 중입니다.

GitHub Issue #2358 기록에 따르면 Microsoft는 2024년 4월 Persistence and state management roadmap을 발표했습니다. AutoGen v0.2에서 v0.5로 API가 크게 이동하면서 프로젝트를 다시 손봐야 하는 경우가 생겼습니다.

저도 이 함정을 밟았습니다. AutoGen v0.2로 개발한 프로젝트를 v0.5로 업그레이드하자 API가 전부 무효가 되었습니다. ConversableAgent, GroupChat 같은 핵심 클래스의 인터페이스가 바뀌었습니다. 코드를 다시 써야 했습니다.

2025년 3월에는 Save/Load for AgentChat.NET PR(#5841)이 발표되었습니다. AgentChat agents와 teams는 snapshots로 롤백할 수 있게 되었고(Issue #4100), SingleThreadedAgentRuntime state serialization도 문서화되었습니다(Issue #4108).

상태 관리 능력은 생겼지만 성숙도는 LangGraph에 미치지 못합니다.

종료 조건 제어: 네 가지 차단 메커니즘

AutoGen에는 고통스러운 지점이 있습니다. 두 Agent가 단일 따옴표를 쓸지 이중 따옴표를 쓸지 두고 50라운드 논쟁하면서 API 비용 5달러를 태울 수 있습니다.

또는 야간 자동 작업이 대화 종료 없이 8시간 동안 계속 실행되고, 다음 날 청구서가 터진 것을 발견할 수도 있습니다.

AutoGen v0.4는 이벤트 기반 아키텍처를 사용하며 메시지 루프가 계속 수신 대기합니다. 종료 조건이 없으면 리소스 블랙홀이 됩니다.

AutoGen 공식 문서에 따르면 네 가지 종료 조건을 제공합니다.

종료 유형	제어 차원	적합한 상황
MaxMessageTermination	라운드 제어	전체 메시지 수를 10개 이하로 제한
TextMentionTermination	내용 제어	TERMINATE 키워드 감지
TimeoutTermination	시간 제어	장시간 대기로 연결을 점유하는 상황 방지
TokenUsageTermination	비용 제어	예산 초과 방지

조합해서 사용할 수 있습니다.

from autogen_agentchat.conditions import (
    MaxMessageTermination,
    TimeoutTermination,
    TokenUsageTermination
)

# 종료 조건 조합
termination = (
    MaxMessageTermination(max_messages=20)
    | TimeoutTermination(timeout_seconds=3600)
    | TokenUsageTermination(max_tokens=10000)
)

어느 하나의 조건에 도달하면 대화가 종료됩니다. 이 차단 메커니즘이 무한 루프를 막습니다.

대화형 프로토콜 vs 상태 머신: 암묵성과 명시성의 철학 차이

AutoGen과 LangGraph의 설계 철학은 완전히 다릅니다.

AutoGen은 대화형 프로토콜(Conversational Programming)을 사용합니다.

• ConversableAgent: 대화 가능한 Agent 기본 클래스
• GroupChat: 여러 Agent를 하나의 그룹 대화에 넣는 구조
• GroupChatManager: 다음 발화자를 결정, 라운드로빈, 자동 선택, 사용자 정의 전략 지원

Agent는 대화할 수 있는 주체이며 자연어 대화로 협업합니다. 상태는 대화 흐름 속에 암묵적으로 들어가 있고 LangGraph처럼 명시적으로 관리되지 않습니다.

LangGraph는 상태 머신(State Machine)을 사용합니다.

• State TypedDict: 상태 구조를 명시적으로 정의
• Node: 각 노드의 처리 로직
• Edge: 노드 간 연결과 조건 분기

각 단계에서 상태가 어떻게 바뀌는지, 다음에 어디로 가는지 모두 명시적으로 정의합니다.

AutoGen은 유연한 대화 흐름에 적합합니다. 다음에 누가 말해야 할지 확실하지 않을 때 Agent가 자유롭게 협상하게 합니다.

LangGraph는 정밀 제어에 적합합니다. 조건 분기가 명확하고 흐름 경로를 예측할 수 있습니다.

Checkpoint 직렬화 능력(AgentChat.NET)

AutoGen의 Checkpoint 능력은 직렬화를 통해 구현됩니다.

GitHub PR #5841에 따르면 AgentChat.NET은 Agent 상태 저장과 불러오기를 지원합니다.

# 상태를 파일에 저장
team.save_state("checkpoint.json")

# 파일에서 복구
team.load_state("checkpoint.json")

이는 파일 직렬화이지 데이터베이스 지속화가 아닙니다. 단일 머신 상황에는 적합하지만 분산 배포에는 추가 적응 작업이 필요합니다.

관측성 측면에서 AutoGen은 OpenTelemetry의 세 축인 Logs, Metrics, Traces를 사용합니다. 이벤트 스트림 모니터링과 Replay 재생 디버깅 덕분에 문제 위치 파악이 편합니다.

핵심 비교와 기술 선택: 12개 차원 정량 비교

프레임워크 선택은 결혼 상대를 고르는 일과 비슷합니다. 절대적으로 최고인 것은 없고, 당신에게 가장 잘 맞는 것이 있을 뿐입니다.

LangGraph와 AutoGen은 Agent 프레임워크의 두 가지 큰 기술 노선을 대표합니다. 하나는 상태 머신 우선의 워크플로 오케스트레이션이고, 다른 하나는 대화 우선의 다중 역할 협업입니다.

12개 차원 정량 비교표

차원	LangGraph	AutoGen	점수 차이
상태 관리 모델	명시적 State TypedDict	암묵적 대화 흐름	LangGraph +2
Checkpoint 메커니즘	네이티브 지원, 각 노드 자동 저장	Roadmap에서 진화 중, 직렬화 의존	LangGraph +3
복구 능력	Super-Step 수준 복구	대화 롤백, 발전 중	LangGraph +2
종료 제어	조건부 Edge	TerminationCondition 클래스	동점
지속화 매체	Memory/SQLite/Postgres/Redis	파일 직렬화	LangGraph +2
시간 여행	임의 과거 롤백 지원	Replay 재생	LangGraph +1
Human-in-the-Loop	interrupt() + Command(resume=)	UserProxyAgent 인적 대리	LangGraph +1
분산 지원	PostgresSaver가 자연스럽게 지원	이벤트 기반 아키텍처로 분산 적응	LangGraph +1
개발 유연성	세밀한 제어, State+Edge 정의 필요	대화 구동, 빠른 프로토타입	AutoGen +1
학습 곡선	높음, 그래프 상태 머신 이해 필요	중간, 대화 패턴 이해 필요	AutoGen +1
API 안정성	LangChain 생태계 기반 안정	v0.2에서 v0.5로 큰 마이그레이션	LangGraph +2
운영 성숙도	⭐⭐⭐⭐⭐	⭐⭐⭐	LangGraph +2

총평은 이렇습니다. LangGraph는 상태 관리 능력에서 앞서고(+14점), AutoGen은 대화 유연성에서 장점이 있습니다(+2점).

이 말은 LangGraph가 무조건 더 좋다는 뜻이 아닙니다. LangGraph가 정밀한 상태 제어가 필요한 상황에 더 적합하다는 뜻입니다. AutoGen은 유연한 대화 흐름 협업이 필요한 상황에 더 잘 맞습니다.

적용 상황 의사결정 흐름도

어떻게 고를까요? 요구사항을 보면 됩니다.

요구사항 분석
  ↓
명확한 조건 분기 흐름이 있는가?
  ├─ 예 → LangGraph
  └─ 아니오 → 여러 Agent의 자유 협상이 필요한가?
      ├─ 예 → AutoGen
      └─ 아니오 → 장기 작업의 장애 복구가 필요한가?
          ├─ 예 → LangGraph
          └─ 아니오 → 빠른 프로토타입인가?
              ├─ 예 → AutoGen
              └─ 아니오 → 기본값은 LangGraph(운영 수준)

LangGraph가 강한 상황

LangGraph는 다음 상황에 적합합니다.

1. 복잡한 조건 분기 워크플로

애프터서비스 티켓 처리 흐름을 예로 들 수 있습니다. 문제 유형 판단 → 서로 다른 처리 경로로 분기 → 결과 취합. 조건 분기가 명확하므로 LangGraph의 Conditional Edge로 정밀하게 제어할 수 있습니다.

2. 정밀한 상태 제어가 필요한 장기 작업

연구 문헌 정리 Agent는 데이터베이스를 10번 연속 호출하고, 문헌 200편을 정리하며, 리뷰 보고서를 생성합니다. 실행 시간은 3시간이고 중간 장애가 나면 Checkpoint에서 복구해야 합니다. LangGraph의 Super-Step 수준 복구는 이미 완료한 노드를 반복 실행하지 않습니다.

3. 운영 수준 Human-in-the-Loop 검토 흐름

계약 검토나 민감한 이메일 검토처럼 초안을 생성한 뒤 일시 중지하고 사람의 확인을 기다리는 상황입니다. LangGraph의 interrupt() + Command(resume=) 조합은 일시 중지와 복구를 우아하게 처리합니다.

4. 시간 여행 디버깅이 필요한 상황

Bug 재현이나 A/B 테스트처럼 임의의 과거 버전으로 롤백하고 분기 탐색을 해야 하는 경우입니다. LangGraph의 Checkpoint 시퀀스는 원하는 노드로 checkout할 수 있습니다.

5. 분산 배포형 고동시성 Agent 시스템

고객지원 시스템처럼 여러 인스턴스를 배포하고 상태를 공유해야 하는 상황입니다. PostgresSaver는 분산을 자연스럽게 지원하며 상태 경쟁을 줄입니다.

AutoGen이 강한 상황

AutoGen은 다음 상황에 적합합니다.

1. 여러 Agent의 자유 대화 협상

추리 게임이나 토론 장면처럼 다음에 누가 말할지 확실하지 않은 상황입니다. Agent가 자유롭게 협상하도록 두면 됩니다. GroupChat의 자동 발화자 선택 전략이 유연한 대화 흐름을 지원합니다.

2. 빠른 프로토타입 개발

개념 검증 Demo를 빠르게 만들 때 좋습니다. State+Edge를 정의하지 않아도 되고, 대화 구동 방식이라 시작이 빠릅니다.

3. 역할극형 협업

카피라이터, 디자이너, 운영자가 함께 논의하는 장면처럼 서로 다른 역할의 Agent가 협업하고 실제 팀 대화를 흉내 내는 상황입니다.

4. 코드 생성과 실행의 폐쇄 루프

Code Executor + UserProxyAgent 조합으로 코드를 생성하고, 실행하고, 피드백을 받고, 수정할 수 있습니다. AutoGen은 코드 실행 폐쇄 루프를 네이티브로 지원합니다.

5. 유연한 대화 흐름이 필요한 상황

다음 단계가 확실하지 않을 때 GroupChatManager가 발화자를 결정합니다. 미리 흐름을 모두 정해둘 필요가 없습니다.

실전 코드 예시: 같은 요구사항을 두 프레임워크로 구현하기

같은 요구사항으로 두 프레임워크의 구현 차이를 비교해 보겠습니다.

요구사항 정의: 장기 흐름 연구 문헌 정리 Agent

작업 설명:

• 학술 데이터베이스 API를 10번 연속 호출
• 문헌 200편의 초록 정리
• 리뷰 보고서 생성

실행 시간: 약 3시간

장애 허용 요구사항:

• 7단계에서 데이터베이스 인터페이스 타임아웃 실패
• Checkpoint에서 복구하고 앞선 6단계를 반복하지 않아야 함

Human-in-the-Loop:

• 초안 생성 후 일시 중지
• 사람의 확인 후 최종본 생성

LangGraph 구현

from langgraph.checkpoint.sqlite import SqliteSaver
from langgraph.graph import StateGraph, END
from typing import TypedDict, Annotated
from operator import add

# State 구조 정의
class ResearchState(TypedDict):
    papers: Annotated[list, add]  # 누적, 덮어쓰지 않음
    summaries: Annotated[list, add]
    draft: str
    final_report: str
    step: int
    human_approved: bool

# 노드 함수 정의
def fetch_papers(state: ResearchState):
    """학술 데이터베이스 API 호출"""
    step = state["step"]
    papers = call_database_api(step)  # 가상의 API 호출
    return {"papers": papers, "step": step + 1}

def summarize_papers(state: ResearchState):
    """문헌 요약 생성"""
    papers = state["papers"]
    summaries = generate_summaries(papers)  # 가상의 요약 생성
    return {"summaries": summaries}

def generate_draft(state: ResearchState):
    """초안 생성"""
    summaries = state["summaries"]
    draft = generate_report(summaries)  # 가상의 보고서 생성
    return {"draft": draft}

def human_review(state: ResearchState):
    """인간 검토 노드(interrupt 후 resume 대기)"""
    return {"human_approved": True}

def generate_final(state: ResearchState):
    """최종본 생성"""
    draft = state["draft"]
    final_report = refine_report(draft)
    return {"final_report": final_report}

# Graph 구성
graph = StateGraph(ResearchState)

# 노드 추가
graph.add_node("fetch", fetch_papers)
graph.add_node("summarize", summarize_papers)
graph.add_node("draft", generate_draft)
graph.add_node("review", human_review)
graph.add_node("final", generate_final)

# Edge 정의
graph.add_edge("fetch", "summarize")
graph.add_edge("summarize", "draft")
graph.add_edge("draft", "review")
graph.add_edge("review", "final")
graph.add_edge("final", END)

# 진입점 설정
graph.set_entry_point("fetch")

# Checkpointer 추가(핵심)
checkpointer = SqliteSaver.from_conn_string("research_checkpoints.db")
compiled_graph = graph.compile(
    checkpointer=checkpointer,
    interrupt_before=["review"]  # review 노드 전에 일시 중지
)

# 작업 실행
config = {"configurable": {"thread_id": "research-session-001"}}
result = compiled_graph.invoke({"step": 0}, config)

# 7단계 실패 후 복구
# 같은 thread_id를 사용하면 앞선 6단계를 자동으로 건너뜀
recovered_state = compiled_graph.invoke({"step": 7}, config)

# Human-in-the-Loop 복구
# 초안 생성 후 일시 중지, 사람 확인 후 계속
compiled_graph.invoke(
    Command(resume={"human_approved": True}),
    config
)

핵심 특성:

• SqliteSaver가 각 노드 실행 후 State를 자동 저장
• thread_id로 서로 다른 세션을 격리
• 복구 시 이미 실행한 노드를 자동으로 건너뜀(channel_versions로 판단)
• interrupt_before로 Human-in-the-Loop 일시 중지 구현

AutoGen 구현

from autogen_agentchat.agents import AssistantAgent
from autogen_agentchat.teams import RoundRobinGroupChat
from autogen_agentchat.conditions import (
    MaxMessageTermination,
    TimeoutTermination,
    TokenUsageTermination
)
from autogen_core.models import ChatCompletionClient

# Agent 정의
research_agent = AssistantAgent(
    name="researcher",
    model_client=ChatCompletionClient(model="gpt-4"),
    system_message="당신은 연구 문헌 정리 어시스턴트입니다.\
        데이터베이스를 연속 호출하고, 요약을 정리하고, 보고서를 생성하세요.\
        완료 후 'TERMINATE'라고 말하세요."
)

human_agent = AssistantAgent(
    name="human_reviewer",
    model_client=ChatCompletionClient(model="gpt-4"),
    system_message="당신은 검토자입니다. 초안을 검토한 뒤 'APPROVED' 또는 'REJECT'라고 말하세요."
)

# 종료 조건 설정(무한 루프 방지)
termination = (
    MaxMessageTermination(max_messages=50)
    | TimeoutTermination(timeout_seconds=10800)  # 3시간
    | TokenUsageTermination(max_tokens=50000)
    | TextMentionTermination(text="TERMINATE")
)

# Team 구성
team = RoundRobinGroupChat(
    participants=[research_agent, human_agent],
    termination_condition=termination
)

# 작업 실행
async def run_research():
    result = await team.run(
        task="문헌 200편의 초록을 정리하고 리뷰 보고서를 생성하세요"
    )
    return result

# Checkpoint 저장(AgentChat.NET)
team.save_state("research_checkpoint.json")

# Checkpoint에서 복구
team.load_state("research_checkpoint.json")

# 계속 실행
async def resume_research():
    result = await team.run()
    return result

핵심 특성:

• TerminationCondition으로 무한 루프 방지, 즉 차단 메커니즘 제공
• Save/Load로 상태를 파일에 저장, 직렬화 방식
• 이벤트 기반 아키텍처로 분산에 적응
• 대화형 프로토콜: Agent가 자연어로 협업

두 구현 비교 요약

특성	LangGraph	AutoGen
상태 정의	명시적 TypedDict	암묵적 대화 흐름
Checkpoint	노드 자동 저장, 데이터베이스	파일 직렬화
복구 메커니즘	Super-Step 수준에서 이미 실행한 노드 건너뜀	대화 롤백
Human-in-the-Loop	interrupt 일시 중지 + resume 복구	UserProxyAgent 개입
종료 제어	조건부 Edge 라우팅	TerminationCondition 차단
코드량	약 60줄, State+Edge 정의 필요	약 30줄, 대화 구동

LangGraph는 세밀한 제어가 가능하며 정밀한 상태 관리에 적합합니다.

AutoGen은 빠른 프로토타입과 유연한 대화 협업에 적합합니다.

운영 수준 배포 제안: 개발에서 운영까지의 완전한 경로

LangGraph 운영 배포 핵심

지속화 방안:

PostgresSaver + RedisSaver 조합을 권장합니다.

PostgreSQL은 지속화 저장을 담당하며 분산 배포를 자연스럽게 지원합니다. Redis는 캐시 계층으로 사용하며 고동시성 상황에서 읽기와 쓰기가 빠릅니다.

from langgraph.checkpoint.postgres import PostgresSaver
from langgraph.checkpoint.redis import RedisSaver

# 운영 수준 구성
postgres_saver = PostgresSaver.from_conn_string(
    "postgresql://user:pass@host:5432/db"
)
redis_saver = RedisSaver.from_conn_string(
    "redis://host:6379/0"
)

# 조합 사용: Redis 캐시 + Postgres 지속화
compiled_graph = graph.compile(
    checkpointer=postgres_saver
)

관측성:

LangSmith tracing + OpenTelemetry 통합.

LangSmith에서는 호출 체인 추적을 볼 수 있습니다. 어느 노드가 느린지, 어느 부분에서 Token을 많이 쓰는지 확인할 수 있습니다. OpenTelemetry는 기존 모니터링 체계와 연결합니다.

성능 최적화:

스트리밍 출력: 사용자가 첫 token을 즉시 보고 체감 지연을 1초 미만으로 줄입니다.

병렬 Tool 호출: LangGraph는 여러 도구를 동시에 실행하는 기능을 네이티브로 지원합니다.

Prompt 사전 컴파일: LLM 추론 시간을 약 30% 줄입니다.

비용 최적화:

전략	비용 감소 폭	적합한 상황
Prompt 압축	30-50%	일반 상황
다중 Provider 라우팅	40-60%	운영 환경 failover
Cache 메커니즘	50-80%	반복 조회 상황

다중 Provider 라우팅은 운영 수준의 기본 구성입니다. API Gateway로 failover를 구현하면 GPT-4가 장애를 내도 Claude로 자동 전환할 수 있고 비용도 40%까지 낮출 수 있습니다.

AutoGen 운영 배포 핵심

관측성:

OpenTelemetry의 세 축인 Logs, Metrics, Traces를 사용합니다.

• EventLogger + 구조화 로그: 문제 위치 파악과 감사 추적
• OpenTelemetry Meter: 성능 모니터링과 용량 계획
• OpenTelemetry Tracer: 호출 체인 분석과 지연 최적화

from autogen_core.telemetry import (
    enable_telemetry,
    EventLogger
)

# 관측성 활성화
enable_telemetry(
    logger=EventLogger(),
    meter=OpenTelemetryMeter(),
    tracer=OpenTelemetryTracer()
)

이벤트 스트림 모니터링:

Replay 재생 디버깅 기술을 사용할 수 있습니다. 모든 Agent 행동이 이벤트 스트림을 생성하므로 문제를 재생해 재현할 수 있습니다.

분산 적응:

이벤트 기반 아키텍처는 분산을 자연스럽게 지원합니다. Agent 간 메시지는 이벤트로 전달되며 상태 경쟁을 줄일 수 있습니다.

비용 제어:

TokenUsageTermination 차단: 예산 상한에 도달하면 자동 종료합니다.

from autogen_agentchat.conditions import TokenUsageTermination

# 비용 차단 설정
termination = TokenUsageTermination(max_tokens=10000)

구조화 로그로 Token 소비를 분석할 수 있습니다. 어떤 대화가 많이 소비하는지, 어느 Agent 비용이 높은지 볼 수 있습니다.

운영 배포 비교표

차원	LangGraph	AutoGen
지속화	PostgresSaver 분산 지원	파일 직렬화, 별도 적응 필요
관측성	LangSmith tracing	OpenTelemetry 세 축
비용 제어	다중 Provider 라우팅	TokenUsageTermination 차단
성능 최적화	스트리밍 출력 + 병렬 Tool	이벤트 스트림 모니터링
분산	PostgresSaver가 자연스럽게 지원	이벤트 기반 적응

핵심 교훈: 운영 환경에는 반드시 AI Gateway가 필요하다

LangGraph를 선택하든 AutoGen을 선택하든 운영 환경에는 반드시 AI Gateway를 붙여야 합니다.

왜 그럴까요?

1. 다중 Provider failover

API가 장애를 내면 자동 전환합니다. GPT-4가 중단되면 Claude로 바꿉니다. 단일 장애점을 제거합니다.

2. 비용 모니터링

어느 Agent가 많이 쓰는지, 어떤 대화 비용이 높은지 실시간으로 모니터링합니다. 예산을 넘으면 자동으로 차단합니다.

3. 속도 제한

API rate limit에 걸리지 않도록 합니다. 요청을 대기열에 넣고 자동으로 재시도합니다.

4. 로그 추적

모든 호출을 중앙에서 기록합니다. 문제 위치 파악과 감사 추적에 필요합니다.

AI Gateway는 선택 기능이 아닙니다. 운영 수준 Agent의 필수 구성입니다.

결론

LangGraph와 AutoGen은 Agent 프레임워크의 두 가지 큰 기술 노선을 대표합니다.

LangGraph는 상태 머신 우선의 워크플로 오케스트레이션입니다. State+Node+Edge를 명시적으로 정의하고 각 단계를 제어할 수 있습니다. Checkpoint를 네이티브로 지원해 장애 복구 시 반복 실행을 피합니다. 복잡한 조건 분기, 장기 작업, 분산 배포에 적합합니다.

AutoGen은 대화 우선의 다중 역할 협업입니다. Agent가 자연어로 협상하고 유연한 대화 흐름을 만듭니다. 종료 조건 차단으로 무한 루프를 방지합니다. 빠른 프로토타입, 여러 Agent의 자유 협상, 역할극형 상황에 적합합니다.

선택 기준은 어느 쪽이 더 좋은가가 아니라 어느 쪽이 당신의 상황에 더 맞는가입니다.

명확한 조건 분기 흐름이 있나요? LangGraph입니다. 여러 Agent의 자유 협상이 필요한가요? AutoGen입니다. 장기 작업에 장애 복구가 필요한가요? LangGraph입니다. 빠른 프로토타입 검증이 필요한가요? AutoGen입니다.

저는 두 프레임워크 모두에서 함정을 밟았습니다. AutoGen은 상태가 제어되지 않았고 API 마이그레이션 때문에 코드를 다시 써야 했습니다. LangGraph는 상태 그래프를 정의하느라 100줄 넘게 작성해야 했습니다.

핵심 교훈은 하나입니다. 운영 환경에는 반드시 AI Gateway를 붙이세요. 다중 Provider failover, 비용 모니터링, 속도 제한. 이 세 가지 기능은 Agent 안정 운영의 기본선입니다.

다음 단계는 이렇습니다. 프로젝트가 복잡한 워크플로라면 LangGraph를 선택하세요. 빠르게 다중 Agent 프로토타입을 만들고 싶다면 AutoGen을 선택하세요. 그런 다음 LangGraph 상태 관리 실전, 즉 시리즈 39번 글을 읽고 Checkpoint 메커니즘의 실제 사용법을 더 깊게 확인하세요.