Dify 도입, 무엇부터 확인해야 할까? 기능·사례·라이선스·도입 판단 총정리

직답 요약

사내 AI 도입을 고민한다면 기능보다 먼저 볼 것이 있습니다. 일본 Kakaku.com은 Dify로 직원 75%가 사내 앱 950개를 만들었지만, 무료판이 아니라 권한을 나눌 수 있는 Enterprise를 썼습니다. 도입 성패는 "어떤 기능이 있나"보다 "우리 인원과 권한 구조에 맞나"에서 갈립니다.

사내에 AI를 도입하려는 기업이 부쩍 늘었습니다. 그런데 도구를 고르는 단계에서 담당자들이 대체로 비슷하게 멈추더군요. 기능 목록은 다 비슷해 보이는데, 정작 "우리 회사에 맞나"는 잘 나오지 않습니다.

그래서 이 글에서는 기능을 나열하는 대신, 실제로 Dify를 대규모로 써본 회사가 무엇을 어떻게 선택했는지부터 봅니다. 남의 도입기를 따라가 보면, 우리가 무엇을 먼저 따져야 하는지가 드러납니다.

직원 75%가 AI 앱을 만든 회사는 Dify를 어떻게 썼을까?

먼저 규모부터 보겠습니다. Dify는 코드를 거의 쓰지 않고 사내 AI 애플리케이션을 만들고 운영하는 오픈소스 LLMOps 플랫폼입니다. 2023년 3월 중국 개발자 커뮤니티 LangGenius가 오픈소스로 내놓았고, GitHub 스타 13만 개, 배포된 앱 100만 개, 개발자 18만 명을 넘겼습니다(2026년 4월 기준). 오픈소스만의 이야기도 아닙니다. 상용 버전을 쓰는 곳이 2,000개 팀, 280개 기업에 이르는데 머스크와 ETS, 앵커 이노베이션스, 노바티스 같은 회사가 여기 포함됩니다. 2026년 3월에는 3천만 달러 규모의 시리즈 Pre-A 투자도 유치했습니다(기업가치 약 1억 8천만 달러, HSG 주도).

가장 구체적인 도입 사례는 일본의 가격 비교와 맛집·구인 정보를 함께 운영하는 인터넷 기업 Kakaku.com입니다. Dify 공식 사례에 따르면, 이 회사는 흩어져 있던 AI 실험을 실제 서비스로 바꾸려고 Dify Enterprise를 도입했습니다. 결과는 이렇습니다.

• 도입 첫 달에만 직원 30%가 가입해 앱 70개 이상을 만들었고, 이후 전체 직원의 75%가 Dify에 가입해 사내 앱을 약 950개까지 늘렸습니다.

• 상품 데이터를 뽑아내는 앱 하나는 3시간 만에 배포돼 매일 대량의 상품 데이터를 처리하고 있습니다. 사람 손이 많이 가던 반복 작업이 앱 하나로 대체된 셈입니다.

• 만들어진 앱은 맛집 리뷰 서비스 타베로그(Tabelog)의 매장 소개글 작성 지원, Kakaku.com의 상품 정보 등록 자동화처럼 실제 서비스 업무에 붙었습니다.

• 예전에는 한 달씩 걸리던 워크플로우 구성이 하루로 줄었습니다.

여기서 눈여겨볼 대목이 있습니다. Kakaku.com은 무료 버전이 아니라 Enterprise의 멀티워크스페이스를 썼습니다. 팀마다 앱과 사용자, 예산을 나누고 접근 권한을 좁게 잡아야 했기 때문입니다. 직원들은 이미 쓰던 Azure AD 계정으로 SSO 로그인해 따로 비밀번호를 만들지 않았고, 누군가 퇴사하면 접근 권한도 자동으로 사라지도록 했습니다. 권한과 계정 관리를 회사의 기존 보안 체계에 그대로 얹은 것입니다. 대규모로 잘 쓴 회사조차 무료판을 두고 권한을 나눌 수 있는 유료 버전을 골랐다는 점, 이게 뒤에서 다시 중요해집니다.

왜 지금 기업들은 사내 AI를 온프레미스로 두려 할까?

한 회사만의 이야기는 아닙니다. 시장 전체의 흐름이기도 합니다. 온프레미스(On-premise)는 소프트웨어를 외부 클라우드가 아니라 자체 보유 서버에 두고 운영하는 방식을 말합니다.

메가존클라우드와 파운드리(구 IDC)가 국내 749명을 조사한 자료를 보면, 국내 기업의 생성형 AI 도입률은 55.7%(전사 도입 22.4%, 일부 부서 33.2%)이고 2026년에는 85%를 넘어설 전망입니다. 예산도 따라 늘어, 응답 기업의 79.3%가 2026년 생성형 AI 예산을 늘리겠다고 했고 그중 37.2%는 절반 이상 늘리겠다고 답했습니다. 그런데 돈을 더 쓰겠다는 분위기와 별개로, 도입을 막는 걱정도 뚜렷합니다. 응답자의 53.3%가 "보안과 개인정보 유출"을, 61.3%가 "잘못된 정보와 신뢰도"를 우려했습니다. 흥미로운 점은, 이미 전사적으로 AI를 쓰는 기업일수록 투자 대비 효과(ROI)에 대한 불확실성 우려가 오히려 낮았다는 것입니다(전사 활용 기업 13.1%). 써 보기 전에는 막연하던 걱정이 작게라도 굴려 보면 구체적인 판단으로 바뀐다는 뜻으로 읽힙니다.

특히 AI를 외부에 맡기지 않고 자체 운영하기로 한 기업의 45.9%가 "보안과 데이터 통제"를 가장 큰 이유로 꼽았습니다. 사내 데이터를 밖으로 내보내지 않으려는 것입니다. 같은 조사에서 도입 방식은 아직 SaaS형이 35.5%로 가장 많지만, 보안이 걸리는 업무일수록 자체 설치를 함께 저울질하는 흐름이 뚜렷합니다. Dify가 주목받는 이유도 여기 있습니다. 오픈소스라 사내 서버에 직접 설치할 수 있고, 이 경우 문서와 대화 데이터가 회사 네트워크를 벗어나지 않습니다. 예산은 늘고 도입도 빨라지는데 그 돈이 보안 걱정 위에서 움직인다는 점, 이것이 온프레미스 AI가 주목받는 배경입니다. 어떤 AI를 쓰느냐만큼 그 AI를 어디에 두느냐가 도입의 첫 갈림길이 되는 셈입니다. 온프레미스와 망분리 개념 자체가 낯설다면 온프레미스·망분리란 무엇일까에서 따로 다룹니다. 기능을 비교하기 전에 데이터를 어디 둘지부터 정해야 하지 않을까요?

코드 없이 만든다는 Dify, 실제로 뭘 만들 수 있을까?

Dify의 핵심은 개발자가 코드로 짜던 AI 앱을 화면에서 블록을 잇듯 만들게 해준다는 것입니다. 기능은 네 가지 축으로 요약됩니다.

• 비주얼 워크플로우. 프롬프트, 조건 분기, API 호출을 블록으로 잇습니다. Dify는 자체 코드베이스에서 LangChain을 걷어내고 핵심 기능을 15개 컴포넌트로 줄였습니다. 프레임워크 종속을 덜어 개발 속도를 높이려는 결정이었습니다.

• RAG 파이프라인 내장. RAG(Retrieval-Augmented Generation, 검색 증강 생성)는 사람이 답하기 전에 먼저 자료를 찾아보는 것과 같다고 생각하면 됩니다. 문서를 올리면 자동으로 벡터화해 검색 기반 답변을 만드니까요. RAG 자체가 낯설다면 RAG란 무엇일까를 참고하시면 됩니다.

• 멀티 모델 연결. GPT, Claude, Gemini 같은 상용 모델과 Llama·Mistral 오픈소스, 사내 로컬 모델을 모두 연결합니다. 작업별로 다른 모델을 지정할 수 있고, 나중에 모델을 바꿔도 앱을 다시 만들 필요가 없어 특정 모델에 묶이지 않습니다.

• 운영·모니터링. Dify는 Celery와 Redis 기반 워커로 긴 작업을 비동기로 돌리고, OpenTelemetry로 추적 데이터를 내보내 품질을 관리합니다.

실제로 기업들이 Dify로 만드는 것도 이 범위 안에 있습니다. Dify 측이 밝힌 대표 활용은 문서 검토 파이프라인, 사내 지식에 근거해 답하는 내부 코파일럿, 사람에게 넘기는 조건까지 갖춘 고객지원 자동화, 그리고 인보이스 감사나 문서 초안 작성 같은 운영 업무입니다. 앞의 Kakaku.com이 만든 앱들도 사내 문서를 아는 챗봇, 문서 자동 처리, 데이터 추출처럼 대부분 여기에 들어갑니다. 사내 문서 챗봇을 실제로 만드는 절차는 개발자 없이 사내 챗봇 만들기, 문서 검색·요약은 사내 문서 AI 검색에서 단계별로 다룹니다.

그런데 Dify가 안 맞는 경우는 언제일까?

장점만 보고 도입하면 실제 운영에서 막힙니다. 어떤 도구든 잘하는 것과 못하는 것이 있고, Dify도 예외가 아닙니다. 도입 전에 알아 두면 견적과 구성에서 미리 대비할 수 있는, 검증된 한계는 세 가지입니다.

1. 무료 셀프호스팅은 세부 권한 관리가 안 됩니다. 무료 버전의 접근 제어는 사실상 전부 아니면 전무입니다. 역할별 권한(RBAC), SSO, 감사 로그는 유료 클라우드나 Enterprise에서만 제공됩니다. 앞서 Kakaku.com이 Enterprise를 쓴 이유가 바로 이것입니다. "기획자 세 명은 읽기만, 엔지니어 두 명은 쓰기까지"처럼 권한을 나눠야 하는 조직이라면 무료판으로는 부족합니다.

2. 기능 자체에도 상한이 있습니다. 2025년 초 기준으로 Dify의 벡터 검색은 세밀한 메타데이터 필터를 지원하지 않았고, SQL 데이터베이스에 직접 연결하는 노드도 없었습니다. 프레임워크 안에서 커스터마이징할 수 있는 한계선도 분명히 있습니다.

3. 여러 시스템을 잇는 자동화에는 다른 도구가 낫습니다. Dify는 AI 앱 자체에 강하지만, 외부 서비스 연동이나 스케줄 실행 같은 넓은 업무 자동화는 n8n 같은 도구가 더 넓게 지원합니다.

특히 첫 번째 한계 때문에 무료판과 Enterprise를 이렇게 갈라 보면 됩니다.

Dify는 사내 AI 앱과 RAG에는 분명 강합니다. 다만 협업 권한이나 복잡한 시스템 연동이 핵심이라면 구성을 다시 봐야 합니다.

그래서 우리 회사에 Dify가 맞는지 어떻게 판단할까?

사례와 한계를 붙여 보면 판단 순서가 나옵니다. 대규모로 잘 쓴 Kakaku.com조차 무료판을 두고 Enterprise를 골랐다는 사실이 힌트입니다. 도구의 기능 목록보다 우리 조직의 조건이 먼저라는 뜻입니다. 필자는 다음 세 가지를 순서대로 따져보길 권합니다.

첫째, 인원과 권한을 먼저 셉니다. 이 앱을 몇 명이 쓰고, 그 사이에 권한을 나눠야 하는지부터 확인합니다. 실사용자가 한 자릿수이고 모두 같은 권한이면 무료 Community로 충분합니다. 반대로 부서나 직군별로 "읽기만·편집·관리자"를 갈라야 하거나 팀별로 예산을 따로 잡아야 하면 무료판으로는 안 됩니다. 무료판의 접근 제어가 전부 아니면 전무라, SSO나 감사 로그가 필요한 보안팀 요구도 여기서 유료 영역으로 넘어갑니다. 앞서 Kakaku.com이 팀마다 워크스페이스와 예산을 나누려고 Enterprise를 쓴 것이 정확히 이 경우입니다. 확인은 질문 하나로 끝납니다. "누가 어떤 데이터에 접근하면 안 되는가"를 목록으로 뽑아보고, 그 목록이 비어 있지 않으면 처음부터 Enterprise나 별도 구축을 견적에 넣습니다.

둘째, 만들려는 것이 'AI 앱'인지 '시스템 자동화'인지 가릅니다. 사내 문서 Q&A, 문서 요약·분류, 상담 응대처럼 AI의 답변 자체가 결과물이면 Dify가 강합니다. 반대로 "메일이 오면 → 요약해서 → Slack에 알리고 → CRM을 갱신하고 → 실패하면 재시도"처럼 여러 외부 시스템을 오가는 흐름이 핵심이면 n8n 같은 자동화 도구가 더 맞습니다. 이럴 때는 Dify 단독보다 자동화는 n8n, AI 파트는 Dify로 나눠 붙이는 구성을 검토합니다. 이 업무에서 AI가 '두뇌'인지, 아니면 '여러 톱니 중 하나'인지를 보면 어느 쪽을 먼저 검토할지 가려집니다. 앞서 본 Kakaku.com이 만든 950개 앱도 대부분 문서를 읽고 답을 만드는 쪽이었지 여러 시스템을 오가는 자동화는 아니었습니다. Dify를 대량으로 쓴다고 해서 모든 자동화를 Dify로 한다는 뜻은 아닌 셈입니다.

셋째, 운영을 감당할 사람이 있는지 봅니다. 온프레미스 Dify는 Docker로 설치 자체는 어렵지 않지만, 서버와 데이터베이스, 벡터 저장소를 계속 돌리고 새 버전이 나올 때마다 업그레이드와 보안 패치를 따라가야 합니다. 이 운영 부담이 도입 견적에 잘 안 잡히는 숨은 비용입니다. 특히 Dify는 LangChain을 걷어내고 컴포넌트를 정리하는 식으로 꾸준히 구조를 바꿔 왔는데, 이렇게 활발히 업데이트되는 오픈소스일수록 새 버전을 따라가는 손이 계속 듭니다. 전담할 사람이 없다면 둘 중 하나를 고릅니다. 매니지드나 클라우드로 시작해 운영 부담을 미루거나, 구축과 유지보수를 맡아줄 파트너를 두는 것입니다. 확인 질문은 이겁니다. "여섯 달 뒤 새 버전이 떴을 때 누가 적용하나."

이 세 질문에 답이 막힌다면, 아직 도구를 고를 단계가 아니라 PoC로 작게 확인할 단계라 생각합니다.

Dify 도입은 어떻게 진행될까?

ONS는 Dify 한국 공식 파트너로서 도입 전 과정을 다음 단계로 지원합니다.

• 진단. 어떤 업무에 AI를 적용할지, 위 세 가지 조건(인원·권한, 자동화 범위, 운영 인력)은 어떤지 먼저 확인합니다. 여기서 무료판으로 될지, Enterprise나 별도 구축이 필요한지가 갈립니다.

• PoC(개념 검증). 실제 업무 하나를 골라 작게 Dify를 적용해 효과를 봅니다. 반복이 잦고 검수가 쉬운 업무를 첫 대상으로 삼는 것이 정착에 유리합니다.

• 구축. 온프레미스 설치, 사내 데이터 연결, 워크플로우 설계, 권한 체계를 잡습니다. 데이터를 회사 안에 두는 구성은 이 단계에서 확정합니다.

• 교육. 현업이 스스로 앱을 만들고 운영하도록 사용법을 전합니다. Kakaku.com처럼 결국 직원 다수가 직접 앱을 만들 때 도입 효과가 커집니다.

• 유지보수. 운영 중 오류 대응, 성능 개선, 버전 업데이트를 돕습니다. 새 버전 적용과 보안 패치를 누가 맡을지 미리 정해 두어야 합니다.

핵심은 PoC로 검증한 뒤 확장하는 흐름입니다. 한 번에 크게 벌였다가 성과를 못 보는 것이 도입 실패의 흔한 이유이니까요.

Dify 도입 비용은 얼마나 들까?

비용은 크게 세 항목입니다. 도구 자체(오픈소스 Community 버전은 무료, RBAC나 SSO 같은 Enterprise 기능은 별도), 설치할 서버와 인프라, 그리고 구축과 교육 비용입니다. 서버와 인프라에는 Dify를 돌릴 서버뿐 아니라 데이터베이스와 벡터 저장소를 상시 운영하는 몫이 들어갑니다. 구축과 교육에는 사내 데이터 연결과 권한 체계 설계, 그리고 현업이 직접 앱을 만들도록 사용법을 전하는 몫이 포함됩니다.

일반적으로 온프레미스는 초기 구축 비용이 있는 대신, 사용량이 늘어도 구독료가 쌓이지 않습니다. 그래서 규모가 커질수록 클라우드 SaaS보다 총비용이 낮아지는 경우가 많습니다. 앞서 본 조사에서도 아직은 SaaS형 도입이 35.5%로 가장 많았습니다. 매달 구독료를 내는 방식이라 시작이 가볍기 때문입니다. 다만 쓰는 사람이 늘고 앱이 쌓일수록 구독료도 함께 불어나므로, 전사로 넓힐 계획이라면 초기 구축비를 감수하고 온프레미스로 가는 편이 길게 봐서 유리한 편입니다. Kakaku.com이 직원 75%, 앱 950개 규모로 키운 것도 자체 설치형 Enterprise 위에서였습니다. 정확한 견적은 업무 범위와 인원, 서버 사양에 따라 달라지니 진단 단계에서 산출합니다.

자주 묻는 질문

사내 문서를 얼마나 다룰 수 있나요?

Dify의 RAG는 모델을 다시 학습시키는 방식이 아니라, 질문할 때마다 사내 문서를 찾아보는 방식이라 생각하면 됩니다. 문서를 추가하거나 고치면 바로 반영됩니다. 다만 2025년 초 기준으로 세밀한 메타데이터 필터는 지원되지 않았으니, 복잡한 조건 검색이 필요하면 미리 확인해야 합니다.

어떤 업무부터 적용하는 게 좋나요?

반복이 잦고 규칙이 분명하며 결과를 사람이 빠르게 검수할 수 있는 업무가 첫 대상으로 좋습니다. 사내 규정 질의응답이나 문서 요약, 상담 정리 같은 일이 여기에 해당합니다. Kakaku.com도 상품 정보 등록이나 매장 소개글 작성처럼 반복이 뚜렷한 업무부터 앱으로 만들었습니다. 반대로 예외가 많고 사람 판단이 자주 필요한 일은 뒤로 미루는 편이 안전합니다. 좁게 시작해 효과를 눈으로 확인한 뒤 옆 업무로 넓히는 순서가 정착에 유리합니다.

개발자가 없어도 우리가 직접 운영할 수 있나요?

앱 제작은 현업이 화면에서 할 수 있습니다. 다만 초기 설치와 사내 시스템 연동, 장애 대응은 기술 지원이 필요하고, ONS가 이 부분을 맡습니다.

지금 쓰는 GPT나 Claude를 그대로 쓸 수 있나요?

네. Dify는 여러 상용·오픈소스 모델을 연결하니, 작업별로 모델을 다르게 지정할 수 있고 나중에 바꿔도 앱을 다시 만들 필요가 없습니다.

Dify는 앞으로도 계속 발전할까요?

2026년 3월 3천만 달러 투자를 유치하면서 Dify는 엔터프라이즈 전담 제품팀 구성과 에이전트 기능 강화, 커뮤니티 지원 확대를 2026년 계획으로 밝혔습니다. 오픈소스 커뮤니티도 GitHub 스타 13만 개, 개발자 18만 명 규모로 계속 커지고 있어, 도입한 뒤 방치될 도구는 아니라고 생각합니다.

다음 단계

Dify가 우리 회사에 맞는지 확인하는 가장 빠른 방법은 업무 하나를 골라 PoC로 검증하는 것입니다. 그전에 인원과 권한 구조부터 점검하시길 바랍니다. 대규모로 잘 쓴 회사도 거기서부터 시작했습니다. Kakaku.com도 첫 달에는 직원 30%, 앱 70개로 시작해 지금의 950개에 이르렀습니다. 작게 시작하면 생각보다 어렵지 않습니다. ONS는 Dify 한국 공식 파트너로서 그 첫 검증부터 함께합니다.

출처

출처

• Kakaku.com 사례: Dify 공식 블로그 "Kakaku Accelerates AI Adoption with Dify" (dify.ai/blog, 2025-11-21). 직원 75% 가입·앱 950개·상품추출 앱 3시간 배포·Azure AD SSO·타베로그/Kakaku.com 서비스 앱·워크플로우 구성 1개월에서 1일로 단축.

• Dify 규모·구조: GitHub langgenius/dify (2026-04 기준) · Dify 공식 블로그

• Dify 투자·상용 도입: BusinessWire·VentureBeat "Dify Raises $30M Series Pre-A" (2026-03-09). 3천만 달러·기업가치 1억 8천만 달러·HSG 주도·상용 2,000팀·280기업(머스크·ETS·앵커 이노베이션스·노바티스)·2026 로드맵.

• Dify 기능 한계: Baytech Consulting, "What is Dify.ai" (2025)

• 국내 도입 통계: 메가존클라우드 × 파운드리(구 IDC) 749명 조사 (CIO Korea·ITWorld 보도, 2026). 도입 55.7%(전사 22.4%·일부 33.2%)에서 85% 전망·예산 증액 79.3%(50% 이상 증액 37.2%)·SaaS 35.5%·보안유출 우려 53.3%·신뢰도 61.3%·자체운영 보안데이터통제 45.9%·전사활용 ROI 우려 13.1%.

• 플랫폼 비교: Dify vs Langflow vs Flowise (elest.io) · 오픈소스 AI 에이전트 비교 (jimmysong.io)