LangGraph 1.0 출시 7개월, 다들 실무에서 어떻게 쓰고 계신가요?

LangGraph 에이전트를 위한 사전 액션 가드레일을 구현 중인데, HITL(Human-in-the-loop) 포인트가 딱 그 역할을 합니다. 제가 계속 부딪혔던 문제는 정형화된 워크플로우는 괜찮지만, 에이전트가 스스로 경로를 결정하는 순간 모든 분기에 체크포인트를 미리 작성할 수 없다는 점이었죠. 그래서 그래프 위치별로 체크포인트를 잡는 대신, '액션' 단위로 제어합니다. 결제나 위험한 SQL 실행 같은 되돌릴 수 없는 도구 호출 직전에 체크 로직이 점수를 매기고 LangGraph의 interrupt()를 호출해 멈추게 합니다.

메모리 문제를 3가지 옵션으로 나누는 건 좀 아니라고 봄. 내가 본 프로덕션 환경에선 stateless-with-external-store 방식이 제일 많이 쓰이는데, 이건 저 3가지 옵션 어디에도 안 들어가거든. 우린 세션 끝날 때마다 요약 노드 돌려서 구조화된 컨텍스트 블롭을 Postgres에 저장하고, 다음 세션 시작할 때 그래프 초기화하면서 그걸 주입하는 방식을 씀. LangMem은 아예 안 씀. 아무도 말 안 하는 숨겨진 비용이 있는데, 그 컨텍스트 블롭이 프롬프트 인젝션이 된다는 거임.

솔직히 말하자면, 1월부터 4노드짜리 조정 그래프 하나를 프로덕션에서 돌리고 있는데 다들 이걸 핵심 인프라처럼 다룹니다. 아주 지루할 정도로 안정적이죠. '에이전트가 스스로 경로를 결정한다'는 문제는 아예 배제했습니다. LangGraph는 구조화된 절반을 깔끔하게 해결해주고, 동적 오케스트레이션은 그냥 '스마트한 프롬프팅과 감'으로 때우고 있습니다. 사람마다 다르겠지만, 전혀 부끄럽지 않네요.

대부분은 단계가 고정되어 있고 예측 가능한 워크플로우에 LangGraph를 씀. 동적이고 오픈 엔드인 오케스트레이션은 여전히 까다롭고 메모리 선택이 진짜 중요함. 세션 간 컨텍스트 유지를 위해 LangMem을 고수하는 사람도 있고, 특히 유연한 브랜칭이 필요해서 직접 가벼운 커스텀 메모리 레이어를 만드는 사람들도 있음.

솔직히 내가 제일 아쉬운 건 그래프 토폴로지가 아니라 체크포인팅 기능임. 우리도 복잡한 라우팅 그래프가 말썽일 땐 그냥 선형 체인으로 평탄화해버렸지만, 상태 지속성 레이어는 유지했거든. 12단계 중 8단계에서 실패했을 때, 처음부터 다시 하는 것보다 마지막 체크포인트에서 재개하는 게 훨씬 나음. 장기 실행 실패를 한번 겪어보면 Bounded냐 Unbounded냐 하는 라우팅 고민은 거의 부차적인 문제가 됨.