처음 Dify를 접했을 때 솔직히 “또 이런 거 나왔네” 싶었다. LangChain, n8n, Flowise에 이어 또 하나의 AI 워크플로우 빌더 아닌가 싶어서 별 기대 없이 열었다가, 한 시간쯤 지나서 탭을 닫지 못하고 있는 나를 발견했다.
구체적으로 어디서 충격을 받았냐면, 내가 LangGraph로 이틀 동안 구현하려고 씨름하던 RAG 파이프라인을 Dify에서 드래그앤드롭 30분 만에 뚝딱 돌아가게 만들었을 때였다. 물론 커스터마이징 깊이는 차이가 있다. 그런데 프로토타이핑 속도, 비개발자와의 협업 가능성, 배포까지의 거리는 비교가 안 되게 Dify가 앞섰다.
GitHub 스타가 현재 14만 개를 넘어섰다. LangChain을 넘어선 지 꽤 됐다. 이 숫자가 괜히 나온 게 아니다.
이 글은 Dify를 처음 보는 비개발자부터, 이미 어느 정도 써봤지만 깊은 기능은 안 들어가본 개발자까지를 모두 포함해서, 내가 실제로 쓰면서 배운 것들을 다 쏟아붓는 방식으로 썼다. 스크린샷 대신 판단 기준과 경험으로 채웠다.
Dify가 뭔지, 딱 한 문장으로 정리하면
“코드 없이 AI 앱을 만들고 배포하는 오픈소스 LLM 개발 플랫폼”이다.
여기서 포인트가 세 개 있다. 첫째 ‘코드 없이’. 둘째 ‘배포까지’. 셋째 ‘오픈소스’.
많은 노코드 AI 툴들이 “코드 없이 만든다”고 하는데, 그걸 실제 서비스로 배포하려면 결국 개발자가 붙어야 하는 경우가 많다. Dify는 만드는 것과 배포하는 것이 같은 화면 안에 있다. 버튼 하나면 웹앱, API, 임베드 코드가 자동 생성된다.
오픈소스라는 점도 중요하다. dify.ai에서 클라우드 버전을 쓸 수도 있고, GitHub에서 코드를 받아 직접 서버에 올릴 수도 있다. 기업 입장에서 데이터를 외부로 보내기 싫다면 완전히 사내 인프라에서만 돌릴 수 있다는 게 큰 차별점이다.
시작하기 전에 – 클라우드냐, 셀프호스팅이냐
Dify를 처음 쓴다면 가장 먼저 이 선택을 해야 한다.
클라우드 버전은 dify.ai에 회원가입하면 바로 시작할 수 있다. 무료 플랜에서 sandbox 모드로 제한된 토큰 내에서 기능 전체를 체험할 수 있다. 개인 학습이나 소규모 프로토타입이라면 클라우드로 충분하다.
셀프호스팅은 도커를 쓴다. 방법 자체는 단순하다.
git clone https://github.com/langgenius/dify.git
cd dify/docker
docker compose up -d이렇게 세 줄로 로컬에서 Dify가 뜬다. 포트 80을 열면 브라우저에서 접근 가능하다. 내부적으로는 Nginx, API 서버, Worker, PostgreSQL, Redis, Weaviate(벡터 DB)가 함께 올라온다. 처음에 이 컨테이너 구성을 보고 꽤 많다 싶었는데, 각각 역할이 명확히 분리돼 있어서 실제로 운영하다 보면 어디서 문제가 생겼는지 금방 파악이 된다.
기업 환경에서는 도커 컴포즈 대신 Kubernetes로 배포하는 방식도 공식 지원한다. 온프레미스를 검토 중이라면 Helm 차트도 준비돼 있다.
Dify의 전체 구조 – 메뉴를 이해해야 길이 보인다
Dify를 처음 열면 좌측 사이드바에 메뉴가 나온다. 이게 처음엔 약간 낯설 수 있다. 구성을 이해하고 들어가면 훨씬 쉽다.
스튜디오(Studio) 가 핵심 작업 공간이다. 여기서 AI 앱을 만든다. 챗봇, 텍스트 생성기, 에이전트, 워크플로우, 채팅플로우 다섯 가지 앱 유형을 선택해서 시작할 수 있다. 빈 캔버스에서 시작하거나, 미리 만들어진 템플릿을 불러올 수 있다.
지식베이스(Knowledge) 는 Dify의 핵심 경쟁력 중 하나다. 문서를 올리면 자동으로 청크 단위로 분할하고 임베딩해서 벡터 DB에 저장한다. PDF, Word, Markdown, 웹페이지 URL, Notion 페이지까지 소스 유형이 다양하다. 이 지식베이스를 앱에 연결하면 RAG가 완성된다. 코딩 없이.
플러그인(Plugins) 은 2025년 이후 Dify가 크게 강화한 영역이다. 마켓플레이스에서 구글 검색, 날씨 API, Slack 알림, GitHub 연동 등 다양한 도구를 설치할 수 있다. 자체 커스텀 툴도 만들어서 등록할 수 있다.
모니터링(Monitoring) 에서는 앱이 어떻게 사용되고 있는지 로그를 볼 수 있다. 어떤 쿼리가 들어왔고, 모델이 어떻게 응답했고, 얼마나 시간이 걸렸는지 실시간으로 확인된다. 프로덕션 운영할 때 이 기능이 생각보다 많이 쓰인다.
설정(Settings) 에서는 LLM 모델 연결, 팀 멤버 초대, API 키 관리, 사용량 제한 등을 관리한다. OpenAI, Anthropic Claude, Google Gemini, Azure OpenAI, Mistral, 그리고 Ollama를 통한 로컬 모델까지 연결 가능하다.
앱 유형 5가지 – 어떤 걸 골라야 하나
스튜디오에서 새 앱을 만들 때 유형 선택이 먼저 나온다. 이 선택이 이후 편집 환경 전체를 결정하기 때문에 처음에 제대로 이해하는 게 중요하다.
챗봇(Chatbot) 은 가장 단순한 형태다. 프롬프트를 작성하고, 모델을 선택하고, 필요하면 지식베이스를 연결하면 대화형 AI가 완성된다. 단일 LLM 호출로 충분한 상황에 맞다. 사내 FAQ봇, 제품 설명 봇, 간단한 고객 상담봇이 여기 해당한다.
텍스트 생성기(Text Generator) 는 단발성 입력을 받아 결과물을 출력하는 형태다. 대화가 필요 없는 경우, 예를 들어 블로그 초안 생성, 이메일 드래프트, 보고서 요약 같은 작업에 쓴다.
에이전트(Agent) 는 LLM이 도구를 선택하고 사용하면서 목표를 달성하는 형태다. Function Calling 방식과 ReAct 방식 중 선택할 수 있다. 웹 검색, 계산, API 호출 같은 외부 액션이 필요할 때 선택한다.
워크플로우(Workflow) 는 단계별 파이프라인을 명시적으로 설계하는 방식이다. 각 단계가 노드로 표현되고, 노드 사이를 선으로 연결한다. 실행 흐름이 예측 가능하고, 중간 결과를 다음 단계로 전달하는 구조다. 복잡한 자동화에 적합하다.
채팅플로우(Chatflow) 는 워크플로우에 대화 인터페이스를 얹은 것이다. 대화 맥락을 유지하면서 복잡한 파이프라인을 실행해야 할 때 선택한다. 단순 챗봇보다는 정교하고, 일반 워크플로우보다는 사용자 친화적인 중간 형태다.
내 경험상 처음 쓰는 분들이 가장 많이 하는 실수가 모든 걸 챗봇으로 만들려는 거다. 중간 결과를 통제해야 하거나, 조건 분기가 필요하거나, 외부 API를 여러 번 호출해야 한다면 워크플로우나 채팅플로우로 가야 한다.
RAG 지식베이스 – 사내 문서를 AI에게 먹이는 방법
Dify에서 내가 가장 자주 쓰는 기능이 지식베이스다. 이걸 잘 이해하면 Dify 활용의 절반은 해결된다.
지식베이스를 만드는 과정은 이렇다. Knowledge 메뉴에서 Create Knowledge를 클릭하고, 문서를 업로드하거나 URL을 입력한다. 그러면 Dify가 자동으로 텍스트를 추출하고, 청크로 분할하고, 임베딩 모델을 통해 벡터화해서 저장한다.
여기서 세부 설정이 중요하다. 청크 크기를 얼마로 할지, 오버랩을 얼마나 줄지가 검색 품질에 직접 영향을 미친다. 기본값은 청크 500토큰, 오버랩 50토큰으로 설정돼 있다. 문서 특성에 따라 조정이 필요한데, 짧은 FAQ 형태의 문서라면 청크를 작게, 긴 기술 문서라면 크게 잡는 게 일반적으로 낫다.
검색 방식도 선택할 수 있다. 시맨틱 검색만 쓸지, 키워드 검색(BM25)을 병행할지, 리랭킹 모델을 추가할지를 설정할 수 있다. 프로덕션 환경에서는 하이브리드 검색에 리랭킹 모델을 붙이는 게 가장 정확도가 높다. 리랭킹에는 Cohere Rerank나 BGE Reranker 같은 모델을 연결할 수 있다.
지식베이스를 앱에 연결하는 건 단순하다. 챗봇이든 워크플로우든, 앱 설정에서 Knowledge 탭을 열고 연결할 지식베이스를 선택하면 된다. 검색된 결과가 LLM 프롬프트에 자동으로 삽입된다.
한 가지 실제 경험을 공유하자면, 사내 인사 규정 PDF 약 200페이지짜리를 지식베이스에 올리고 HR 챗봇을 만들었다. 처음에는 답변 품질이 들쑥날쑥했는데, 청크 설정을 기본값에서 청크 200토큰으로 줄이고 하이브리드 검색으로 바꾸니까 훨씬 정확해졌다. 특히 “몇 조 몇 항”처럼 구체적인 조항을 참조해야 하는 질문에서 차이가 컸다.
에이전트 만들기 – 도구를 쓰는 AI 만드는 법
에이전트는 단순 LLM 호출과 다르다. AI가 질문을 받으면 어떤 도구를 쓸지 스스로 판단하고, 도구를 사용한 결과를 가지고 최종 답변을 만든다.
Dify에서 에이전트를 만드는 방법은 이렇다. 스튜디오에서 에이전트 유형을 선택하고, 시스템 프롬프트를 작성하고, 사용할 도구를 추가하면 된다.
도구 추가가 핵심이다. Dify 내장 도구로는 구글 검색, DuckDuckGo, 위키피디아, 날씨 조회, 계산기, 이미지 생성, 코드 실행기 등 50개 이상이 준비돼 있다. 설정화면에서 해당 API 키만 넣으면 바로 활성화된다.
커스텀 도구도 만들 수 있다. OpenAPI 스펙을 붙여 넣으면 Dify가 자동으로 도구 형태로 변환해준다. 자사 내부 API를 에이전트에게 도구로 쥐어주는 방법이 이거다. 예를 들어 사내 재고 조회 API가 있다면, 해당 API 스펙을 커스텀 도구로 등록하고 에이전트에 연결하면 “A제품 재고 지금 얼마야?”라는 질문에 에이전트가 스스로 API를 호출해서 답을 가져온다.
에이전트 전략도 선택 가능하다. Function Calling은 모델이 함수 호출 형식으로 도구를 선택하는 방식이다. GPT-4, Claude 같은 최신 모델에서 잘 동작한다. ReAct는 Thought → Action → Observation 사이클을 반복하면서 목표에 도달하는 방식으로, Function Calling을 지원하지 않는 모델에서도 쓸 수 있다.
직접 만들어 써본 에이전트 중에서 가장 실용적이었던 건 ‘경쟁사 리서치 에이전트’였다. 웹 검색 도구 + 지식베이스(자사 제품 정보) + 사용자가 입력한 경쟁사 이름을 조합해서, 경쟁사 최신 소식을 검색하고 자사 제품과 비교 분석하는 보고서를 자동으로 만들어주는 구조다. 혼자 이걸 LangChain으로 짰다면 하루는 잡았을 텐데 Dify에서는 두 시간이 안 걸렸다.
워크플로우 설계 – 노드를 연결해서 파이프라인 만들기
워크플로우가 Dify에서 가장 강력하고 유연한 기능이다. 시각적 캔버스에서 노드를 드래그해서 배치하고, 선으로 연결해서 실행 흐름을 만든다.
사용 가능한 노드 종류를 알아야 설계가 된다. 주요 노드는 이렇다.
시작(Start) 노드는 워크플로우의 입력 변수를 정의한다. 사용자가 입력할 값, 시스템에서 주입할 값을 여기서 선언한다.
LLM 노드는 프롬프트를 작성하고 모델을 호출한다. 이전 노드의 출력값을 변수로 프롬프트에 삽입할 수 있다. 프롬프트 안에서 {{변수명}} 형식으로 참조한다.
지식검색(Knowledge Retrieval) 노드는 지식베이스에서 관련 문서를 검색해서 결과를 반환한다. RAG 워크플로우에서 LLM 노드 바로 앞에 배치하는 게 일반적이다.
조건(IF/ELSE) 노드는 분기 처리다. 이전 결과값에 따라 다음 실행 경로를 나눈다. 예를 들어 언어 감지 결과가 한국어면 A 경로, 영어면 B 경로로 분기하는 식이다.
HTTP 요청 노드는 외부 API를 호출한다. GET, POST, PUT 모두 지원한다. 헤더, 바디, 인증 설정이 가능하다. 사내 시스템과 연동할 때 이 노드를 많이 쓴다.
코드(Code) 노드는 Python 코드를 직접 실행한다. 노코드 워크플로우이지만, 복잡한 데이터 변환이나 계산이 필요할 때 이 노드를 쓰면 해결된다. 개발자라면 이 노드가 있다는 것만으로도 Dify가 훨씬 유연해진다.
반복(Iteration) 노드는 배열 데이터를 하나씩 처리할 때 쓴다. 예를 들어 여러 URL을 입력받아 각각 요약하는 워크플로우를 만들 때, 이 노드로 각 URL을 순회하면서 처리한다.
병렬(Parallel) 노드는 여러 브랜치를 동시에 실행한다. 서로 독립적인 여러 LLM 호출을 동시에 돌리고 결과를 합치는 데 쓴다. 처리 시간을 줄이는 데 효과적이다.
실제로 내가 만든 워크플로우 중 하나를 예로 들면, 고객 문의 자동 분류 및 응답 초안 생성 시스템이 있다. 흐름은 이렇다. 시작 → 문의 내용 입력 → LLM으로 카테고리 분류(기술문의/결제문의/배송문의) → IF/ELSE로 분기 → 각 카테고리별 지식베이스에서 관련 내용 검색 → 해당 내용 기반으로 응답 초안 생성 → HTTP 요청으로 사내 CRM에 자동 저장 → 출력. 이걸 워크플로우로 만들어서 Slack 봇에 연결했더니, 담당자 응답 시간이 평균 4시간에서 30분으로 줄었다.
MCP 연동 – 2026년 Dify의 가장 큰 변화
2026년 들어 Dify에서 가장 주목할 업데이트가 MCP(Model Context Protocol) 지원이다.
두 방향으로 동작한다. 첫째, Dify가 MCP 클라이언트로 동작해서 외부 MCP 서버에 연결할 수 있다. 예를 들어 Brave Search MCP 서버, GitHub MCP 서버, Supabase MCP 서버 같은 것들을 Dify 에이전트의 도구로 붙일 수 있다. HTTP 기반 MCP 서비스를 플러그인으로 설치하면 된다.
둘째, 더 흥미로운 방향은 반대쪽이다. Dify에서 만든 워크플로우나 에이전트를 MCP 서버로 퍼블리시할 수 있다. 만들어놓은 AI 앱을 MCP 서버로 바꾸면, Claude Desktop이나 다른 MCP 클라이언트에서 그 앱을 도구로 호출할 수 있게 된다.
개발자 입장에서 이게 왜 중요하냐면, Dify로 만든 RAG 챗봇이나 자동화 워크플로우를 Claude Code나 다른 AI 코딩 에이전트의 도구로 등록할 수 있다는 뜻이기 때문이다. AI들이 서로 도구를 주고받는 생태계에서 Dify가 중간 레이어 역할을 할 수 있게 됐다.
MCP 서버 플러그인 설치는 Dify 플러그인 마켓플레이스에서 할 수 있다. Endpoint Name, App 선택, App Input Schema(JSON Schema)를 설정하면 된다. Auth Bearer Token을 비워두면 인증 없이 공개 서버로 동작하고, 토큰을 설정하면 인증 방식으로 보호할 수 있다.
기업에서 Dify를 도입할 때 알아야 하는 것들
Dify를 개인 학습용으로 쓰는 것과 기업에서 실제 업무에 쓰는 건 고려해야 할 것들이 꽤 다르다.
가장 먼저 고민해야 하는 게 데이터 주권이다. dify.ai 클라우드를 쓰면 데이터가 외부로 나간다. LLM API 호출도 마찬가지다. OpenAI나 Anthropic의 서버로 데이터가 전송된다. 금융, 의료, 공공기관처럼 데이터 외부 반출에 제약이 있는 조직은 셀프호스팅이 필수다. 셀프호스팅에 Ollama를 통한 로컬 모델을 연결하면 인터넷 연결 없이 완전 내부 환경에서 동작하는 AI 시스템이 된다.
사용자 권한 관리도 중요하다. Dify Enterprise 버전에서는 SSO 지원과 팀 단위 권한 관리, 개인 공간과 팀 공간 분리가 가능하다. 커뮤니티 버전에서는 이 기능이 제한적이라 대규모 조직에서 쓰려면 Enterprise 버전을 검토해야 한다.
어떤 부서에서 어떤 식으로 시작하는 게 좋을지도 경험에서 나온 판단이 있다. 처음에 너무 야심 찬 시스템을 만들려다가 실패하는 경우가 많다. 시작은 단순하게, 특정 반복 업무 하나를 자동화하는 것부터 가져가는 게 좋다. 예를 들어 고객 문의 초안 작성, 회의록 요약, 경쟁사 뉴스 모니터링 같은 것들이다. 이 하나가 성공하면 다른 부서들이 알아서 관심을 가지기 시작한다.
Dify가 특히 잘 맞는 기업 사례를 구체적으로 정리하면 이렇다.
사내 지식 검색 시스템이 대표적이다. 수백, 수천 페이지의 내부 문서를 지식베이스에 올리고 RAG 챗봇을 연결하면, 신입 직원이 첫날부터 사내 규정과 업무 프로세스를 빠르게 찾아볼 수 있다. 특히 직원이 많거나 지역이 분산된 조직에서 효과가 크다.
고객 지원 자동화도 잘 맞는다. 제품 매뉴얼, FAQ, 과거 처리된 상담 로그를 지식베이스로 만들고 챗봇에 연결하면, 반복되는 1차 문의의 상당 부분을 자동 응답으로 처리할 수 있다. 복잡한 경우만 사람이 처리하는 티어드 구조를 Dify로 구성할 수 있다.
보고서 자동 생성도 활용 빈도가 높다. 정해진 형식의 보고서가 주기적으로 필요한 부서라면, 데이터 API 호출과 LLM 생성을 결합한 워크플로우로 자동화할 수 있다. 판매 데이터를 받아 주간 보고서 초안을 생성하거나, 뉴스 API에서 키워드 관련 기사를 모아 일일 브리핑을 만드는 식이다.
다국어 콘텐츠 처리도 Dify가 빛나는 영역이다. 글로벌 비즈니스를 하는 기업이라면 번역, 현지화, 다국어 고객 응대를 워크플로우로 묶어서 처리할 수 있다.
개발자가 알아야 할 Dify API 활용
Dify로 만든 앱을 외부 시스템과 연결하는 방법이 API다. 앱을 게시하면 자동으로 REST API 엔드포인트가 생성된다.
챗봇 앱의 기본 호출은 이런 구조다.
POST https://api.dify.ai/v1/chat-messages
Authorization: Bearer {API_KEY}
Content-Type: application/json
{
"inputs": {},
"query": "사용자 메시지",
"response_mode": "streaming",
"conversation_id": "",
"user": "user-123"
}response_mode는 streaming과 blocking 두 가지다. 스트리밍은 SSE(Server-Sent Events) 방식으로 토큰이 생성될 때마다 전송된다. 실시간 타이핑 효과가 필요하다면 스트리밍, 완성된 결과가 필요하다면 블로킹을 쓴다.
conversation_id는 대화 연속성을 위한 ID다. 처음 호출할 때는 비워두면 새 대화 ID가 반환되고, 이후 대화를 이어가려면 그 ID를 넣으면 된다.
워크플로우 앱은 엔드포인트가 다르다. /v1/workflows/run을 쓰고, 시작 노드에서 정의한 변수를 inputs 에 넣으면 된다.
API를 활용하면 Dify를 사내 시스템에 임베드하거나, Slack 봇으로 연결하거나, 기존 웹앱의 AI 기능으로 붙이는 게 가능하다. 이 방식이 빠른 이유는 프론트엔드 UI를 따로 만들 필요가 없기 때문이다. Dify 앱을 API로 감싸고, 기존 시스템에서 호출만 하면 된다.
Dify를 써야 하는 이유와 한계
정리해보자.
Dify가 진짜 강한 영역은 세 가지다. 빠른 프로토타이핑, RAG 파이프라인 구성의 편의성, 그리고 배포까지 한 화면에서 해결되는 워크플로우. 여기에 MCP 지원이 더해지면서 AI 에이전트 생태계와의 연결도 열렸다.
한계도 있다. 복잡한 멀티에이전트 오케스트레이션은 LangGraph만큼 세밀하게 제어하기 어렵다. 실시간 음성·영상 처리는 맞지 않는다. 매우 특수한 커스텀 로직이 많이 필요한 시스템이라면 결국 코드 레이어가 필요해진다.
그래도 내가 Dify를 계속 쓰는 이유는 하나다. 아이디어가 떠올랐을 때 실제로 동작하는 것을 만들어서 팀에 보여주는 데까지 걸리는 시간이 극적으로 줄어든다는 것. 기획자와 함께 앉아서 캔버스를 보여주며 실시간으로 워크플로우를 수정하는 경험은 코드 에디터 앞에서는 불가능한 협업이다.
코드를 알면 Dify가 더 강해진다. 모르더라도 Dify는 충분히 쓸 만하다. 지금 당장 dify.ai에 가서 계정을 만들고, 지식베이스 하나 만들어서 RAG 챗봇을 띄워보는 데 30분이면 된다.