LangChain과 LangGraph란
LangChain은 LLM 애플리케이션을 구축하기 위한 MIT 라이선스의 Python 및 JavaScript 프레임워크입니다. 같은 팀의 LangGraph는 상태를 가진 에이전트를 위한 저수준 오케스트레이션 프레임워크로, 그래프를 코드로 정의하며 장애 후 재개되는 내구성 있는 실행과 에이전트 상태를 검사하고 수정할 수 있는 human-in-the-loop 체크포인트를 더합니다. LangSmith는 추적, 평가, 관측성을 위한 상용 제품이고, LangSmith Deployment는 장시간 실행되는 에이전트를 호스팅합니다. 통합 범위는 생태계에서 가장 넓습니다.
라이브러리 대 플랫폼의 문제입니다
EDDI는 경쟁하는 프레임워크가 아닙니다. EDDI는 내부적으로 LangChain의 Java 계열인 LangChain4j를 사용합니다. 진짜 질문은 어떤 추상화가 더 나은가가 아닙니다. 제어 흐름이 직접 작성하는 코드(LangGraph 그래프)에 있는지, 배포하는 선언적 구성에 있는지, 그리고 그 주변의 모든 것, 즉 REST 계층, 인증, 테넌시, 상태, 감사, 비개발자가 쓰는 인터페이스를 누가 만들고 소유하는지입니다.
직접 만드는 것과 배포하는 것
| 항목 | LangChain / LangGraph | EDDI |
|---|---|---|
| 형태 | 애플리케이션에 가져와 쓰는 라이브러리 | 배포 가능한 미들웨어, Docker가 동작하는 곳이면 어디서나 실행 |
| 오케스트레이션 로직 | 저장소에 있는 Python 또는 TypeScript 그래프 | JSON 구성과 결정론적 behavior rules, 재배포 없이 변경 |
| Human in the loop | Interrupt로 상태를 검사하고 수정할 수 있으며, 승인 UI와 정책은 직접 구축 | 턴, 도구 호출, 그룹 단계에 대한 게이트와 타임아웃 정책, Manager 및 Slack 승인 |
| 내구성 | 직접 구성하는 영속성을 갖춘 내구성 있는 실행 | 플랫폼이 영속화하는 대화 메모리와 AWAITING_HUMAN 같은 명시적 상태 |
| REST API와 라우팅 | 직접 구축하거나 LangSmith Deployment에서 호스팅 | 기본 제공, 그리고 OpenAPI 3.1, A2A 프로토콜, SSE 스트리밍 |
| 인증과 RBAC | 직접 구축 | eddi-admin 및 eddi-approver 역할을 갖춘 선택적 OIDC/Keycloak |
| 비개발자용 인터페이스 | 직접 구축 (LangSmith Studio는 개발자를 대상으로 함) | EDDI Manager, 11개 언어를 지원하는 프로덕션급 React UI |
| 시크릿 관리 | 직접 구축하거나 vault를 가져옴 | 내장 AES-256-GCM Secrets Vault, ${vault:key}로 참조 |
| 관측성 | LangSmith(상용) 또는 직접 구성한 계측 | Prometheus 메트릭과 자동 프로비저닝되는 Grafana 대시보드 |
| 감사 및 규정 준수 | 직접 구축 | HMAC 서명, 추가 전용, 순번 검증을 거치는 감사 원장, 정보 주체 권리 API, 15+개 프레임워크 대응 |
| 반복 개선 루프 | 코드 변경, 리뷰, 테스트, 배포 | UI 또는 API에서 구성 변경, 즉시 적용 |
| 제어의 상한 | 없음. 코드로 표현할 수 있는 것은 모두 가능 | 구성이 표현할 수 있는 범위로 제한됨, 의도된 설계 |
다른 도구에 대한 내용은 2026년 10월 기준으로 공식 문서와 저장소를 확인한 것입니다. 이러한 프로젝트는 변화가 빠르므로, 결정하기 전에 해당 벤더에서 최신 동작을 확인하세요.
둘 사이에서 고르기
LangChain과 LangGraph가 더 나은 선택인 경우
- 오케스트레이션 자체가 경쟁 우위이며, 구성 저장소가 아니라 코드베이스에 있어야 합니다.
- 사용자 정의 그래프 토폴로지, 맞춤형 재시도 의미론, 특이한 상태 머신처럼 선언적 구성으로 표현할 수 없는 제어 흐름이 필요합니다.
- Python 또는 TypeScript 중심 조직이며, 에이전트가 옆에 별도로 있기보다 기존 서비스 안에 있기를 원합니다.
- 새로운 통합이 나오는 바로 그 주에 필요합니다. LangChain은 어떤 플랫폼보다 빠르게 움직입니다.
- 팀이 한두 명의 엔지니어이고, 규정 준수 담당자도, 테넌시 요구사항도, 접근이 필요한 비개발자도 없습니다.
EDDI가 더 나은 선택인 경우
- Day 2 운영 목록이 제품을 만드는 대신 팀이 하고 있는 작업이라는 점이 눈에 들어옵니다.
- 프롬프트 엔지니어와 운영 담당자가 풀 리퀘스트 없이 에이전트 동작을 바꿔야 합니다.
- 여러 팀이나 고객이 하나의 배포를 공유하며 격리, 쿼터, 비용 귀속이 필요합니다.
- 조달 부서가 출시 전에 감사 추적, 데이터 레지던시, 프레임워크 적용 범위에 대한 답을 요구합니다.
- 오케스트레이션 계층이 직접 유지하는 코드베이스가 아니라 업그레이드하는 의존성이기를 원합니다.
LangChain 또는 LangGraph 애플리케이션 옮기기
로직은 대개 그대로 살아남고, 주변 인프라를 더 이상 유지하지 않게 됩니다. 체인 또는 그래프 정의에서 바깥쪽으로 작업하세요. 임의의 Python에 의존하는 제어 흐름은 behavior rules 또는 선언된 도구로 바꿔야 합니다.
| LangChain / LangGraph | EDDI |
|---|---|
| 체인 또는 LangGraph 그래프 | EDDI 파이프라인 구성과 behavior rules |
| 도구와 함수 호출 | MCP 도구 정의 또는 httpCall 선언 |
| 사람 검토를 위한 Interrupt | PAUSE_CONVERSATION 규칙 또는 toolApprovals glob, Manager 또는 Slack에서 승인 |
| Checkpointer와 메모리 클래스 | step, conversation, longTerm 범위를 갖춘 대화 메모리 |
| Retriever 및 벡터 스토어 설정 | 8개 임베딩 제공자와 6개 벡터 스토어에 걸친 RAG 구성 |
| 프롬프트 템플릿 | 버전 관리되는 프롬프트 스니펫, 이름으로 참조 |
| FastAPI 래퍼 | 내장 REST API, OpenAPI 3.1, SSE 스트리밍 |
| LangSmith 추적 | Prometheus 메트릭, Grafana 대시보드, 감사 원장 |
자주 묻는 질문
EDDI는 LangChain을 사용하나요?
EDDI는 내부적으로 Java 구현인 LangChain4j를 사용합니다. 경쟁하는 추상화가 아닙니다. EDDI는 그런 종류의 라이브러리를 중심으로 구축된 배포 가능한 플랫폼으로, 라이브러리가 의도적으로 사용자에게 맡기는 API 계층, 인증, 상태 관리, 관리 UI, 규정 준수 인프라를 제공합니다.
LangChain과 LangGraph의 차이는 무엇인가요?
LangChain은 LLM 애플리케이션을 위한 구성 요소와 통합을 제공합니다. LangGraph는 그래프로 정의되는, 상태를 가진 장시간 실행 에이전트를 위한 더 낮은 수준의 계층이며, 내구성 있는 실행과 human-in-the-loop 체크포인트를 갖춥니다. 둘 다 자체 서비스에 내장하는 라이브러리입니다. EDDI와의 비교는 둘 모두에 적용됩니다.
Day 2 운영 격차란 무엇인가요?
Day 1은 에이전트가 올바르게 응답하도록 만드는 것이며, 라이브러리가 이를 잘 처리합니다. Day 2는 그 이후의 모든 것입니다: 인증, 멀티 테넌시, 재시작 후에도 유지되는 대화 상태, 감사 로깅, 시크릿 교체, 수평 확장, 비용 추적, 그리고 Python을 쓰지 않는 사람들을 위한 인터페이스. 팀은 에이전트 자체보다 Day 2에 더 많은 시간을 쓰는 일이 흔합니다.
구성은 코드보다 덜 강력한가요?
그렇습니다. 그리고 이 거래는 의도된 것입니다. 구성은 코드가 표현할 수 있는 모든 것을 표현할 수 없습니다. 그 대가로 재배포 없는 변경, 비엔지니어도 검토할 수 있는 동작, 보안 리뷰에서 방어해야 할 런타임 코드 실행이 없다는 점을 얻습니다. 코드가 제공하는 상한이 필요하다면 라이브러리를 사용하세요.
LangChain을 유지하면서 EDDI도 쓸 수 있나요?
네. EDDI는 MCP 서버와 REST API를 제공하므로 LangChain 애플리케이션이 EDDI 에이전트를 도구로 호출할 수 있고, EDDI도 httpCall을 통해 LangChain 서비스를 호출할 수 있습니다. 차별화되는 부분과 인프라인 부분의 경계를 따라 나누는 것은 합리적인 설계입니다.