Dify에서 OpenAgent로 에이전트 스택을 갈아탄 이유
Switched our agent stack from Dify to OpenAgent. Here's why we made the call.
핵심 요약
Dify와 Langflow의 프로덕션 한계를 극복하기 위해 더 가볍고 유연한 OpenAgent로 전환한 경험 공유.
- 생산 환경의 한계 — Dify와 Langflow는 프로덕션 배포 시 커스터마이징과 래퍼 코드 작성에 많은 어려움이 있음.
- OpenAgent의 장점 — REST 및 SSE 엔드포인트를 기본 지원하며, 별도의 래퍼 없이 바로 배포 가능한 구조를 갖춤.
- 효율적인 RAG 관리 — 내장된 데이터셋 관리와 버전 비교 기능으로 에이전트 워크플로우를 더 가볍게 운영 가능함.
- 통합 모델 레이어 — Atlas Cloud 연동으로 여러 API 키를 관리할 필요 없이 OpenAI 호환 엔드포인트 하나로 해결됨.
팀 에이전트 워크플로우를 운영하면서 대부분의 사람들처럼 우리도 뻔한 선택지부터 시작했음. 프로토타이핑 성능 때문에 Dify를, 캔버스 때문에 Langflow를 썼지. 둘 다 실제 프로덕션에 배포하려고 할 때 벽에 부딪혔음.
Dify는 파이썬 코드를 커스터마이징하거나 기존 시스템에 임베딩하려고 하면 문제가 생김. 독립형 SaaS 스타일 플랫폼으로 만들어져 있어서, 깊게 수정하려고 하면 사사건건 방해를 받거든.
Langflow는 내가 써본 것 중 가장 깔끔한 비주얼 캔버스를 가졌지만, 그래프에서 프로덕션급 API를 뽑아내려면 여전히 손이 많이 감. SSE 스트리밍, 에러 핸들링, 큐잉까지, 배포 가능한 상태로 만들기 전까지 래퍼 코드를 엄청나게 짜야 함.
지난달에 내부 워크플로우를 OpenAgent로 마이그레이션했음. Flask + Vue3 + LangChain 조합에 오픈소스고, Docker compose로 배포 가능함. 나를 설득한 결정적인 점은 캔버스에서 만드는 모든 것에 대해 POST /api/openapi/chat으로 적절한 REST + SSE 엔드포인트를 바로 노출해준다는 거임. 래퍼 레이어가 필요 없음.
데이터셋 관리와 RAG(Weaviate 또는 FAISS)는 대부분의 에이전트 워크플로우가 필요로 하는 기능을 다 커버함. Dify보다 가볍지만, Langflow에는 없던 프롬프트 버전 비교 기능이 내장되어 있음.
우리 설정에서 중요했던 부가적인 점은, 모델 레이어가 Atlas Cloud를 네이티브로 통합한다는 거임. 그래서 임베딩이랑 LLM용 API 키를 제공자별로 따로 관리할 필요가 없어졌음. 환경 변수 하나에 OpenAI 호환 엔드포인트면 끝임.
이 프로젝트랑은 아무 관련 없음. 그냥 에이전트 오케스트레이션 시장이 두 개의 큰 플랫폼에 잠식되어 있는데, 더 가볍게 배포하려는 팀들에게 실질적인 대안이 될 것 같아서 공유함. 저장소 링크는 댓글에 남김.
