Dify 사용법, 워크플로 만들기부터 자체 호스팅까지

TL;DR

• Dify 사용법의 출발점은 앱 종류를 고르는 것이다. 챗봇, 워크플로, 에이전트, 그리고 문서를 붙이는 RAG 파이프라인이 각각 다른 만들기 방식을 갖는다.
• 클라우드에는 무료 Sandbox가 있고, Professional은 워크스페이스당 연 $590이다. 메시지 크레딧을 다 쓰면 자기 API 키로 전환할 수 있다.
• 오픈소스 커뮤니티 에디션을 Docker Compose로 자기 서버에 올릴 수 있다. 데이터를 밖에 둘 수 없는 조직이 고르는 경로다.

Dify 사용법을 찾는 시점은 대개 프롬프트를 코드에 박아 넣는 방식이 한계에 부딪혔을 때다.
프롬프트를 고칠 때마다 배포해야 하고, 어떤 문서를 참조했는지 추적이 안 되고, 모델을 바꾸면 손볼 곳이 여러 군데다.
Dify는 이 부분을 화면으로 끌어내 워크플로와 지식 베이스, 모델 설정을 한곳에서 다루게 만든 플랫폼이다.

이름부터가 성격을 드러낸다.
공식 문서에 Dify가 “Do It For You”에서 왔다고 적혀 있다.
오픈소스로 공개돼 있어 깃허브 별이 15만 개를 넘겼고, 클라우드와 자체 호스팅을 같은 코드베이스로 제공한다.
아래는 계정을 만든 다음 첫 앱을 만들고, 지식 베이스를 붙이고, 자체 호스팅으로 옮기는 데까지를 공식 문서와 요금표 기준으로 정리한 것이다.

Dify가 다루는 네 가지 만들기 방식

Dify에서 만드는 것은 크게 넷이다.

• 챗봇: 대화형 인터페이스. 프롬프트와 변수, 참조할 지식만 지정하면 바로 쓸 수 있다.
• 워크플로: 단계를 노드로 이어 붙이는 방식. 조건 분기, 반복, 코드 실행, 외부 도구 호출을 노드로 놓는다.
• 에이전트: 도구를 주고 스스로 순서를 정하게 하는 방식. 어떤 도구를 언제 쓸지 모델이 판단한다.
• 지식 파이프라인: 문서를 넣어 검색 가능한 지식 베이스로 만드는 과정. RAG의 앞단이다.

이 넷은 서로 배타적이지 않다.
워크플로 안에서 지식 베이스를 참조하고, 에이전트가 워크플로를 도구처럼 부르는 구성이 가능하다.
처음에는 챗봇으로 감을 잡고, 단계가 필요해지면 워크플로로 옮기는 순서가 자연스럽다.

Dify 사용법, 첫 앱을 만드는 순서

1. Dify Cloud에 가입합니다. 무료 Sandbox 플랜이 포함돼 있어 설치 없이 시작할 수 있습니다.
2. 워크스페이스에서 앱을 새로 만들고 종류를 고릅니다. 처음이라면 챗봇이 가장 짧습니다.
3. 모델을 지정합니다. OpenAI, Anthropic, Gemini 등을 고를 수 있고, 무료 크레딧으로 먼저 시험해볼 수 있습니다.
4. 프롬프트를 작성하고 변수를 정의합니다. 사용자 입력으로 받을 값을 변수로 빼두면 나중에 화면이 깔끔해집니다.
5. 오른쪽 미리보기에서 바로 대화해봅니다. 프롬프트를 고치고 즉시 결과를 확인하는 반복이 이 도구의 핵심 흐름입니다.
6. 문서를 붙일 거라면 지식 베이스를 만들어 파일을 올리고 인덱싱 방식을 고릅니다.
7. 앱을 게시합니다. 웹 링크로 공유하거나 REST API로 자기 제품에 붙일 수 있습니다.

프롬프트를 코드 밖으로 꺼낸 효과는 이 단계에서 바로 체감된다.
문구를 고치는 데 배포가 필요 없고, 누가 언제 무엇을 바꿨는지 워크스페이스 안에 남는다.

지식 베이스를 붙일 때 정해야 하는 것

RAG를 붙일 때 결정할 항목은 두 가지다.
문서를 어떻게 쪼갤지, 그리고 어떤 인덱싱 방식을 쓸지.

인덱싱 방식은 요금과 직접 연결된다.
고품질 인덱싱 모드로 처리한 문서는 지식 데이터 저장 용량을 소모한다.
Professional 플랜 기준으로 지식 문서는 500건, 저장 용량은 5GB가 한도다.
한도에 닿으면 새 문서를 넣을 수 없으므로, 넣을 문서의 성격과 양을 먼저 계산하는 편이 낫다.

문서를 쪼개는 단위도 검색 품질을 좌우한다.
너무 잘게 쪼개면 맥락이 끊기고, 크게 잡으면 관련 없는 내용이 함께 딸려 온다.
매뉴얼처럼 구조가 뚜렷한 문서라면 제목 단위로 자르는 쪽이 대체로 낫다.

요금제와 크레딧이 소모되는 방식

연 결제로 17% 절약된다고 표기돼 있다.
메시지 크레딧은 여러 모델을 손쉽게 시험해보라는 용도로 제공되고, 모델 종류에 따라 소모량이 다르다.
크레딧을 다 쓰면 자기 API 키를 넣어 계속 쓸 수 있다.
이 구조 덕분에 요금이 두 겹으로 나뉜다.
플랫폼 사용료는 Dify에, 모델 사용료는 모델 제공사에 낸다.

자체 호스팅으로 옮기는 경로

커뮤니티 에디션은 오픈소스로 공개돼 있고 Docker Compose로 배포한다.
공식 문서가 이 경로를 별도로 안내한다.

자체 호스팅을 고르는 이유는 대개 데이터 위치다.
문서를 외부 서비스에 올릴 수 없는 조직이라면 이 방식이 전제가 된다.
실제 도입 사례로 공개된 산업군을 보면 제조, 금융, 제약, 공공처럼 데이터 반출이 까다로운 쪽이 눈에 띈다.

대가도 있다.
서버와 데이터베이스, 벡터 저장소를 직접 운영해야 하고 버전 업그레이드를 챙겨야 한다.
관측 기능도 직접 붙인다.
Dify는 Opik, Langfuse, Arize Phoenix 같은 관측 도구 연동을 지원하므로 그중 하나를 골라 연결하는 식이다.

CLI도 준비돼 있다.
difyctl로 터미널이나 스크립트, CI에서 Dify 앱을 부를 수 있어서, 에이전트가 Dify 워크플로를 도구처럼 호출하는 구성도 가능하다.

워크플로가 커질 때 관리하는 법

노드가 스무 개를 넘어가면 화면에서 흐름을 따라가기 어려워진다.
몇 가지 습관이 도움이 된다.

첫째, 워크플로를 잘게 나누고 서로 부르게 한다.
Dify에서는 워크플로를 도구처럼 호출할 수 있으므로, “문서 요약”이나 “분류” 같은 단위를 따로 두고 상위 흐름에서 부르는 구성이 가능하다.
고칠 때 한 곳만 고치면 된다.

둘째, 분기 조건을 노드 이름에 드러낸다.
조건 노드에 기본 이름을 그대로 두면 나중에 어느 쪽이 무엇인지 다시 열어봐야 한다.

셋째, 실패 경로를 만든다.
모델 호출이 실패하거나 예상과 다른 형식을 돌려주는 경우가 실제로 생긴다.
그때 무엇을 할지 정해두지 않으면 워크플로가 중간에서 멈춘다.

넷째, 변경 전후를 같은 입력으로 비교한다.
프롬프트를 고치면 다른 입력에서 결과가 나빠지는 일이 흔하다.
대표 입력 몇 개를 정해두고 매번 같은 것으로 확인하는 습관이 회귀를 줄인다.

한계와 안 맞는 경우

• 세밀한 제어가 필요한 경우. 노드로 표현되지 않는 로직은 코드 노드로 밀어 넣게 되는데, 그 비중이 커지면 코드로 짜는 편이 낫다.
• 소규모 팀이 오래 쓰려는 경우. Professional의 팀 멤버 3명 제한이 먼저 걸린다.
• 문서량이 많은 지식 베이스. 문서 500건과 저장 5GB 한도를 넘기면 상위 플랜이나 자체 호스팅이 필요하다.
• 이미 프레임워크로 에이전트를 짜고 있는 팀. 코드 기반 구성이 익숙하다면 LangChain 사용법 쪽 접근이 더 맞을 수 있다.

앱을 게시한 뒤에 정할 것

만든 앱을 게시하면 링크가 나오고 REST API가 열린다.
여기서부터는 운영 문제가 시작된다.

누가 쓸 수 있게 할지 먼저 정한다.
링크를 아는 사람 누구나 쓰게 열어두면 모델 호출 비용이 통제되지 않는다.
사내 도구라면 접근을 제한하고, 외부에 공개할 거라면 사용량 상한을 함께 설계한다.

대화 기록을 어떻게 다룰지도 정해야 한다.
사용자가 무엇을 물었는지가 쌓이면 개선에 쓸 재료가 되지만, 동시에 관리해야 할 데이터가 된다.
보관 기간과 접근 권한을 미리 정해두는 편이 낫다.

제품 만들 때 가져갈 설계

첫째는 같은 코드베이스로 클라우드와 자체 호스팅을 함께 제공한 결정이다.
도입 검토는 클라우드에서 빠르게 하고, 도입이 확정되면 자기 인프라로 옮긴다.
규제 산업 고객을 놓치지 않으면서 진입 장벽은 낮추는 구조다.

둘째는 요금을 플랫폼과 모델로 분리한 점이다.
크레딧을 다 쓰면 자기 API 키로 넘어가게 해두면, 사용자는 플랫폼 요금이 예측 가능하다고 느낀다.
모델 요금은 원래 자기가 내던 것이라 저항이 적다.

셋째는 템플릿 마켓플레이스다.
다른 사람이 만든 워크플로를 한 번에 가져와 쓰게 하면 처음 만드는 사람의 진입 시간이 줄고, 만드는 사람에게는 공유할 이유가 생긴다.

실행 체크리스트

1. 만들려는 것이 챗봇인지 워크플로인지 에이전트인지 먼저 정합니다.
2. 무료 Sandbox에서 앱 하나를 끝까지 만들어봅니다.
3. 모델을 고르고 크레딧 소모 속도를 확인합니다.
4. 프롬프트에서 사용자 입력으로 받을 값을 변수로 분리합니다.
5. 지식 베이스를 붙일 문서의 개수와 용량을 미리 계산합니다.
6. 인덱싱 방식을 고를 때 저장 용량 소모를 함께 봅니다.
7. 팀으로 쓸 계획이면 Professional의 멤버 3명 제한을 확인합니다.
8. 데이터 반출 제약이 있으면 커뮤니티 에디션 자체 호스팅을 검토합니다.
9. 자체 호스팅이면 관측 도구를 하나 골라 연결해 로그를 남깁니다.

자주 묻는 질문

Dify는 무료로 쓸 수 있나요

클라우드에 무료 Sandbox 플랜이 있고, 오픈소스 커뮤니티 에디션을 자기 서버에 올려 쓰는 방식도 무료입니다.
다만 모델 사용료는 별도로 발생합니다.

Dify 요금은 어떻게 계산되나요

클라우드 Professional은 워크스페이스당 연 $590이고 월 메시지 크레딧 5,000건이 포함됩니다.
크레딧을 소진하면 자기 API 키를 등록해 계속 사용할 수 있습니다.

자체 호스팅은 어떻게 하나요

오픈소스 커뮤니티 에디션을 Docker Compose로 배포합니다.
공식 문서에 설치 경로가 안내돼 있고, 데이터베이스와 벡터 저장소 운영은 직접 맡게 됩니다.

만든 앱을 다른 서비스에 붙일 수 있나요

REST API로 연동할 수 있습니다.
difyctl이라는 CLI도 제공돼 터미널과 스크립트, CI에서 앱을 호출할 수 있습니다.

참고한 곳

• Dify 공식 홈
• Dify Pricing
• Dify Documentation
• langgenius/dify GitHub