Dify는 진지하게 살펴볼 가치가 있다. 가장 잘 맞는 대상은 두 부류다. 백엔드를 처음부터 만들지 않고 실용적인 AI 앱(사내 지원, 지식 Q&A, 승인 도우미)을 빠르게 만들고 싶은 팀, 그리고 데이터 주권을 지키며 AI를 자체 서버에서 돌리고 싶은 기업이다. GitHub에서 약 15만 스타를 받은 오픈소스 AI 앱 플랫폼으로, 비주얼 워크플로, 지식베이스, 에이전트, 모델 관리를 하나의 워크스페이스에 담았다. 다만 개인이 가볍게 써보려는 경우, 서버가 없거나 멀티테넌트 SaaS로 포장해 판매할 계획이라면 아래 주의점을 먼저 읽고 판단하길 권한다.
공식 저장소 정보
플랫폼: GitHub, 조직명: langgenius, 프로젝트명: Dify. 라이선스는 Dify Open Source License로, Apache-2.0을 기반으로 두 가지 추가 조건이 있다. 이 코드로 멀티테넌트 SaaS를 직접 운영하는 것(1테넌트=1워크스페이스)과 프론트엔드의 LOGO·저작권 표시를 제거하는 것은 금지된다. 직접 배포해 직접 쓰는 것——상용 목적이라도——은 명확히 허용된다.
Dify는 무엇을 하는가
"AI 앱의 운영체제"라고 이해하면 쉽다. 비주얼 캔버스에서 멀티스텝 워크플로(프롬프트 체인, 조건 분기, 도구 호출, 검색 단계)를 드래그 앤 드롭으로 조립하고, PDF·PPT·문서로 검색 가능한 지식베이스(RAG)를 구축한 뒤 에이전트 기능(함수 호출과 ReAct, 50개 이상의 내장 도구)을 얹는다. 만든 앱에는 자동으로 API가 붙어 자사 제품의 백엔드로 바로 넣을 수 있고, LLMOps 대시보드로 운영 트래픽 모니터링과 프롬프트 개선도 할 수 있다.
왜 인기가 많은가
이유는 실리적이다. 진입 장벽이 낮아 코드를 쓰지 않고도 동작하는 AI 앱을 만들 수 있다. 데이터 주권이 있어 민감 문서를 타사 클라우드에 올릴 필요가 없다. 프로토타입에서 운영까지 스택을 바꾸지 않고 이전할 수 있다. 운영팀에 중국어권 배경이 있어 핵심 문서에 중국어판이 있다. 100개 이상의 모델 제공업체를 지원해 모델을 바꿔도 앱을 다시 만들 필요가 없다.
맞는 사람, 맞지 않는 사람
맞는 경우: 서버가 있고 사내 AI 앱을 빠르게 전달하고 싶은 팀. 지식 Q&A나 AI 지원을 자체 데이터센터에서 돌리고 싶은 기업. 백엔드 인력이 부족해 Dify를 API 백엔드로 쓰고 싶은 개인 개발자. 맞지 않는 경우: AI와 대화만 하고 싶은 개인(공식 클라우드 버전이 편하다). 멀티테넌트 AI 앱 플랫폼을 만들어 판매하려는 회사(라이선스상 금지, 상용 라이선스 필요). Docker조차 만지고 싶지 않은, 운영 역량 제로인 팀. 셀프 호스팅이라는 점은 같지만 범용 자동화에 가까운n8n 셀프 호스팅 해설과 비교하면 둘의 포지션 차이를 알 수 있다.
셀프 호스팅 전 확인할 4가지
첫째, "돌리는" 비용. 공식 Docker Compose면 몇 줄의 명령으로 화면 기동까지 끝나고, 4코어·8GB 클라우드 서버로 데모 환경이 돌아간다. 아이디어 검증 비용은 낮다. 둘째, "운영화" 비용. Dify는 풀스택 구성으로 PostgreSQL·Redis·벡터 데이터베이스 등 여러 컨테이너를 한 번에 띄운다. 실제 운영은 8코어·16GB를 기준으로 하고, 오픈소스 모델을 로컬에서 돌리려면 GPU·VRAM은 별도로 필요하다——Ollama 로컬 배포 비용 해설도 참고하자. 셋째, "업그레이드와 유지보수" 비용. 버전을 건너뛰는 업데이트에서는 데이터 마이그레이션이 끼는 경우가 있어 운영 업데이트 전에는 반드시 데이터베이스를 백업할 것. 버전을 뛰어넘은 업데이트에서 마이그레이션이 멈춘 사례도 있다. 넷째, "라이선스 준수" 비용. Dify Open Source License는 순수 Apache-2.0이 아니다. 셀프 호스팅 상용 이용은 문제없지만 멀티테넌트 SaaS와 LOGO 제거는 금지이므로 기획 전에 법무 검토를 거쳐두자.
실제 주의점 4가지
첫째, 플러그인 생태계는 아직 초기 단계다. 공식 플러그인 마켓은 본체보다 늦게 시작했고, 틈새 수요는 직접 플러그인을 만들거나 API를 직접 호출하게 될 가능성이 크다. 둘째, 고급 자료는 영어 위주다. 핵심 문서에 중국어판은 있지만 문제 해결과 심층 튜닝은 영어 GitHub Discussions에 모여 있다. 셋째, 지식베이스가 커지면 벡터화와 embedding 비용이 눈에 띄게 늘어난다. 문서량이 많으면 벡터 데이터베이스 리소스를 따로 계획하자. 넷째, 커뮤니티판과 엔터프라이즈판의 기능 차이. SSO·RBAC 등 기업용 기능은 상용판이 필요하므로 커뮤니티판을 쓰는 소규모 팀은 기능 목록이 충분한지 먼저 확인하자.
배포 전 마지막 확인
"직접 관리하는 AI 앱 플랫폼"이 필요하다면 Dify는 현시점 가장 완성도 높은 오픈소스 선택지다. 먼저 클라우드 서버에서 Docker Compose로 실제 시나리오 하나를 돌려 워크플로와 지식베이스가 요건을 만족하는지 확인한 뒤 운영 리소스를 투입하자. 가볍게 써보는 용도라면 공식 클라우드 버전을 쓰고 셀프 호스팅은 피하는 편이 낫다.
