LangGraph로 운영 가능한 에이전트 만들기: 상태 전이·체크포인트·재시도 설계

LLM 서비스를 운영할 때 가장 먼저 무너지는 것은 모델 성능이 아니라 워크플로우 복잡도다.

이 글은 Agent 기반 서비스를 만들면서 툴 호출과 상태 흐름을 어떻게 오케스트레이션했는지 정리한 내용이다. 정리 기준 시점은 2024년 1월 이후 LangGraph 적용 운영 경험이다.

문제 정의

• 툴 호출이 늘수록 흐름 가시성이 급격히 떨어짐
• 실패 지점이 불명확하면 운영 대응이 느려짐
• 워크플로우를 코드 분기만으로 관리하면 유지보수 비용이 폭증함

선택

LangChain/LangGraph 기반으로 요청 처리 흐름을 노드/전이 관점에서 모델링했다.

핵심은 “모델 호출"이 아니라 “어떤 상태에서 어떤 도구를 호출할지"를 구조화하는 것이었다.

구현 패턴

1. 상태 객체를 명시적으로 선언
2. 노드별 입력/출력 계약 고정
3. 실패 노드는 재시도 정책 분리
4. 장기 작업은 체크포인트 저장 후 재개

간단한 흐름은 아래처럼 정의했다.

classify -> retrieve -> decide -> act -> summarize

운영에서 유효했던 점

1. 흐름 단위로 로그/실패를 추적 가능
2. 도구 추가 시 기존 경로 영향 범위를 예측 가능
3. 디버깅을 기능 단위가 아니라 상태 전이 단위로 수행 가능

체크포인트/재시도 기준

• 외부 API 호출 노드만 재시도 허용
• 모델 추론 결과는 같은 입력이면 재사용 가능하도록 캐시
• 실패 시 마지막 정상 체크포인트부터 재시작

이 기준을 고정해두면 “중간 노드 실패"가 전체 세션 실패로 번지는 경우를 크게 줄일 수 있다.

운영 지표

• node_success_rate
• node_retry_count
• graph_completion_rate
• checkpoint_resume_success_rate

그래프형 워크플로우의 안정성은 모델 정확도보다 “전이 실패를 얼마나 예측하고 복구했는가"로 판단하는 게 맞다.

실패 사례에서 얻은 기준

도구 호출 노드가 부분 실패할 때 전체 그래프를 실패 처리하면 사용자 체감 품질이 급격히 나빠졌다.

그래서 부분 성공 허용 노드와 필수 성공 노드를 구분해, 그래프 완료 조건 자체를 비즈니스 요구에 맞게 분리했다.

참고 및 인용

참고: LangGraph는 상태 기반 에이전트 워크플로우(노드/엣지/체크포인트)를 명시적으로 모델링한다. LangGraph Documentation

참고: ReAct 패턴은 추론과 도구 사용을 결합한 에이전트 실행 전략의 대표적 출발점이다. ReAct: Synergizing Reasoning and Acting in Language Models

참고: LangChain 문서는 에이전트 실행, 도구 바인딩, 관측(트레이싱) 통합 패턴을 제공한다. LangChain Docs