r/langchain•4개월 전•12•12
LangGraph를 프로덕션 수준으로 확장하려면 어떻게 해야 할까요?
How to scale LangGraph to be prod ready?
핵심 요약
LangGraph로 구축한 멀티 에이전트 워크플로우를 프로덕션 환경으로 전환할 때 겪는 안정성 및 감사 문제에 대한 조언을 구하는 글입니다.
- 침묵의 실패 — 에이전트의 환각 현상과 실행 경로 추적의 어려움으로 시스템 안정성 저하됨
- 거버넌스 및 감사 — 규제 준수가 중요한 핀테크 환경에서 에이전트 의사결정의 근거 확보가 어려움
- 엔터프라이즈 전환 — 오픈소스 프레임워크의 한계를 극복하기 위한 커스텀 래퍼 도입이나 플랫폼 전환 고민 중
- 프로덕션 준비 — LLM-as-a-judge 외에 비용 효율적으로 신뢰성을 확보할 수 있는 실무적인 방법 모색
지난 몇 달 동안 핀테크 분야의 고객사와 함께 멀티 에이전트 워크플로우를 개발해 왔습니다. 규정 준수 규칙이 매우 많은 환경이었죠. LangGraph를 사용한 프로토타이핑은 정말 빨랐지만, 이제 파일럿 단계를 넘어 프로덕션으로 넘어가려니 악몽이 따로 없네요.
현재 두 가지 주요 문제가 발생하고 있습니다:
- 침묵의 실패: 12단계에서 에이전트가 도구 출력을 환각(hallucination)해내면 전체 워크플로우가 이를 그대로 수용해 버립니다. 실행 경로를 추적하려고 해도 거의 점괘를 보는 수준으로 어렵습니다.
- 거버넌스/감사: 규정 준수 팀은 에이전트가 왜 그런 결정을 내렸는지에 대한 절대적인 추적 가능성을 요구합니다. 오픈소스 프레임워크는 규모가 커지면 블랙박스처럼 느껴집니다.
여러분은 상태 관리와 거버넌스를 처리하기 위해 프레임워크 주위에 커스텀 래퍼를 직접 작성하시나요? 아니면 어느 시점에 기본 오케스트레이터를 버리고 실제 엔터프라이즈 플랫폼으로 넘어가시나요?
에이전트 파일럿 프로젝트의 80%가 프로덕션에서 실패한다는 통계를 계속 읽었는데, 이제 그 이유를 알 것 같습니다.
링크를 걸거나 자사 제품을 홍보하는 것 말고, 이럴 때 어떻게 하는지 알려주실 분 계신가요?
비용 효율적인 방법을 찾고 있으며, LLM-as-a-judge 같은 기법은 이미 알고 있습니다. 프로덕션 준비를 위한 다음 단계를 찾고 있습니다.
