r/langchain•4개월 전•20•66

LangGraph가 기업용 프로덕션 환경에 적합할까요? (수천 명의 사용자)

Is LangGraph suitable for enterprise production? 1000s of users

핵심 요약

기존 Java/SpringBoot 환경에 익숙한 개발자가 엔터프라이즈급 서비스에 LangGraph 도입 가능성을 질문함.

엔터프라이즈 도입 고민 — 기존 Java/SpringBoot 환경과 비교하여 LangGraph의 안정성 및 기능 지원 여부를 질문함.
기능적 한계 지적 — 세션 관리, 인증, 재시도 등 엔터프라이즈 필수 기능이 부족하다는 의견이 많음.
복잡성 논란 — 과도한 추상화와 디버깅의 어려움 때문에 프로덕션 환경 사용을 반대하는 의견이 지배적임.
도구 활용론 — LangGraph의 트레이싱 도구는 유용하며, 설계 방식에 따라 충분히 활용 가능하다는 반론도 존재함.

제가 이전에 작업했던 모든 엔터프라이즈 프로젝트는 Java와 SpringBoot 기반이었습니다. 이제 고객 지원 에이전트를 구축하려고 하는데, LangGraph가 좋은 선택이 될지 고민 중입니다.

SpringBoot는 세션 관리부터 재시도 메커니즘, 인증, 그리고 수천 명의 사용자로 확장하는 데 필요한 모든 빌딩 블록을 제공합니다.

LangGraph가 이런 모든 빌딩 블록을 제공하나요? 수천 명의 사용자를 동시에 처리하는 엔터프라이즈 수준에서 LangGraph를 배포해 본 분 계신가요? 실제로 잘 버티나요?

원문

커뮤니티 목록

r/langchain•4개월 전•20•66

LangGraph가 기업용 프로덕션 환경에 적합할까요? (수천 명의 사용자)

Is LangGraph suitable for enterprise production? 1000s of users

핵심 요약

기존 Java/SpringBoot 환경에 익숙한 개발자가 엔터프라이즈급 서비스에 LangGraph 도입 가능성을 질문함.

엔터프라이즈 도입 고민 — 기존 Java/SpringBoot 환경과 비교하여 LangGraph의 안정성 및 기능 지원 여부를 질문함.
기능적 한계 지적 — 세션 관리, 인증, 재시도 등 엔터프라이즈 필수 기능이 부족하다는 의견이 많음.
복잡성 논란 — 과도한 추상화와 디버깅의 어려움 때문에 프로덕션 환경 사용을 반대하는 의견이 지배적임.
도구 활용론 — LangGraph의 트레이싱 도구는 유용하며, 설계 방식에 따라 충분히 활용 가능하다는 반론도 존재함.

SpringBoot는 세션 관리부터 재시도 메커니즘, 인증, 그리고 수천 명의 사용자로 확장하는 데 필요한 모든 빌딩 블록을 제공합니다.

주요 댓글

r/langchain

대부분의 사용자는 LangGraph가 프로덕션 환경에서 과도한 추상화와 복잡성을 야기한다고 비판하며, 단순한 API 호출 방식의 시스템 엔지니어링을 선호하는 경향을 보입니다.

저는 에이전트가 LangChain/LangGraph 기반으로 구축된 회사에서 일합니다. 조언하자면: 절대 쓰지 마세요. 거의 20년 동안 소프트웨어 엔지니어로 일하면서 이렇게 불필요하게 복잡한 라이브러리 세트는 처음 봅니다. 제 경우엔 제가 결정한 게 아니었지만(제가 오기 전에 이미 결정됨), 2년 동안 작업해 본 결과, 이 쓰레기 프레임워크를 설계한 멍청이들에게 '엿 먹어라'라는 말밖에 할 게 없네요.

진짜 최악임. 누가 소프트웨어 공학 책 읽고 나서 '오 이거다' 하고 만든 느낌인데, 절대 그렇게 짜면 안 됨. 쓸데없는 추상화 계층이 너무 많아. 진심으로.

너는 추천받고 나는 비추받는 게 웃기네.

대체로 동의함. 정해진 틀 안에서 놀 때는 프로토타입 빨리 뽑아내기 좋음. 인프라나 모니터링 같은 고민을 해결해 주는 비싼 제품들도 많고, 지금 시점에서는 에이전트 프레임워크의 표준이라 서드파티 제품들도 다 지원하니까. 하지만 깊게 파고들수록 가장 간단한 걸 하려고 해도 프레임워크랑 싸워야 한다는 걸 느끼게 될 거임. 가끔은 그들 스스로도 싸우고 있는 것처럼 느껴짐

길이 제한으로 뒷부분이 생략된 댓글입니다 · 원문에서 전체 보기 →

좋은 피드백 감사합니다.

-1

화가 많이 난 것 같네. 에이전트 프레임워크 하나 때문에 그렇게까지 화내는 건 건강에 안 좋아. 그래도 LangGraph가 LangChain보다는 바로 써먹기엔 낫지.

복잡한 쓰레기 코드 디버깅하느라 혁신에 쓸 시간 며칠씩 날려봐, 너도 화날걸. 특히 인터프리터나 그래프 실행 프레임워크 구현해 본 경험이 10년 가까이 되는 사람이라면, 이런 시스템이 얼마나 간단하고 직관적일 수 있는지 아니까 더 화가 나지. LangGraph는 그냥 쓰레기야.

마지막 말이 무슨 뜻인지 이해가 안 가네요.

회사에서 주로 쓰는 스택이 뭔가요? ML 엔지니어들이 이 선택을 한 건가요?

파이썬이랑 LangChain/LangGraph 써. 사실 ML 엔지니어들이 결정한 게 아니라(몇 년 전에 결정됨), 소프트웨어 엔지니어 몇 명이 결정한 거야. 제일 최악인 건 코드 위생에 대한 고려가 전혀 없다는 점이지. 우리가 강제로 써야 하는 클래스들 상당수가 LangChain/LangGraph 클래스를 직접 상속받아서 그걸 그대로 써야만 해. 위생적인 접근 방식이라면 내 코드와 사용하는 라이브러리 코드 사이에 깔끔한 경계를 만들어야지. 나중에 바꾸고 싶으면

벤더 종속에 빠지고 Lang 프레임워크 제작자들에게 큰돈을 지불하고 싶다면야 하겠죠. 추상화가 너무 심해서 디버깅하기 어렵습니다. 프로덕션 등급 프레임워크로 평가하자면 10점 만점에 2~3점 주겠습니다.

길이 제한으로 뒷부분이 생략된 댓글입니다 · 원문에서 전체 보기 →

-1

근데 오픈 소스 아닌가요?

LLM의 네이티브 API보다 더 오픈 소스인 게 어디 있어. 프로토타이핑 정도라면 써보라고 하겠는데, 프로덕션 환경이라면 절대 안 써. 내 코드 위에 추적 기능이랑 엉망진창으로 꼬인 메서드 호출을 덧씌우는 짓은 안 할 거야.

피드백 감사합니다. 솔직히 저도 LangGraph가 딱히 매력적이지 않네요. 에이전트 애플리케이션을 만드는 데 왜 웹 프레임워크 이상이 필요한지 이해가 안 가요. 컨텍스트(지시사항, 도구, 출력 스키마, 추가 관련 정보) 만들고, LLM의 REST API 호출하고, 돌아오는 JSON 파싱하면 끝인데. 나머지는 다 전통적인 시스템 엔지니어링이잖아요. 왜 프로덕션에서 검증되지도 않은 걸 써야 하죠?

-1

정확해. json_repair라는 라이브러리 한번 봐봐, 나한테는 도움 됐어. 그리고 팁 하나 주자면, LLM 호출하기 전에 어시스턴트 역할의 콘텐츠에 JSON 출력의 첫 번째 키를 주입해 봐. 보통 그러면 JSON 응답이 보장되더라.

원문r/langchain