Dify 요금제 선택: 함께 관리할 인원부터 세고 모델 비용을 계산하자

팀이 처음 Dify를 구매할 때는 모델 수부터 비교하기 쉽습니다. 하지만 요금제를 실제로 결정하는 요소는 작업 공간에 들어가 앱을 관리해야 하는 사람이 누구인지, 업무 요청 한 건에 모델을 몇 번 호출하는지인 경우가 많습니다. 한 사람이 내부 질의응답 흐름을 검증하는 정도라면 Sandbox부터 사용하세요. 동료 네 명 모두가 함께 관리해야 한다면 3인용 Professional을 장기적인 선택지로 생각해서는 안 됩니다.

아래 판단은 2026년 11월 3일에 확인한 공식 가격 페이지와 문서를 바탕으로 합니다. 부하 테스트 결과가 아니며, 특정 요금제가 실제 동시 처리 수요를 감당한다고 보장하지도 않습니다.

공식 가격 페이지의 작업 공간 구성원 한도는 Sandbox 1명, Professional 3명, Team 50명입니다. 이를 앱이 하루에 서비스할 수 있는 방문자 수로 그대로 이해해서는 안 됩니다. 구매할 때는 작업 공간에 로그인하거나, 흐름을 수정하거나, 지식 자료를 관리해야 하는 사람부터 적어 보세요. 그런 다음 앱 제공 방식에 따른 접근 요건을 별도로 확인해야 합니다.

예를 들어 업무 책임자, 흐름 관리 담당자, 지식 베이스 관리 담당자가 정확히 세 명이라면 Professional을 후보에 넣을 수 있습니다. 네 번째 사람도 작업 공간 관리에 지속적으로 참여해야 한다면 여러 사람이 관리자 계정 하나를 공유하기보다는 Team을 검토해야 합니다. 상사가 가끔 출력 결과만 보는 경우라면 먼저 제공 방식을 확인하고, 읽는 사람이 한 명 늘었다는 이유만으로 업그레이드하지 마세요.

현재 월 결제 정가는 작업 공간당 Professional 59미국 달러, Team 159미국 달러이며, 둘 다 적용되는 세금은 별도입니다. 두 요금제의 월 차액은 100미국 달러입니다. 이 차액을 지불할 가치가 있는지는 추가 협업자가 실제로 작업 공간 좌석을 필요로 하는지부터 살펴 판단해야 합니다. 구성원 수를 성능 지표로 볼 일은 아닙니다.

Dify의 크레딧은 모델 응답마다 차감됩니다. 응답 한 번은 모델 호출 한 번을 뜻하며, 업무 담당자가 제출하는 완결된 요청 한 건과 같지 않습니다. 복잡한 흐름은 먼저 분류하고, 검색 후 생성한 다음, 마지막에 형식을 검사할 수 있습니다. 이 세 단계가 각각 모델을 한 번씩 호출한다면 요청 한 건에 호출 세 번이 포함됩니다. 이는 비용 계산을 위한 예시이지, 모든 Dify 흐름이 항상 세 번 호출한다는 뜻이 아닙니다.

자체 모델 API key로 발생한 비용은 해당 공급자 계정에 청구됩니다. 따라서 예산은 적어도 Dify 작업 공간 구독료와 자체 key로 발생하는 모델 비용, 두 항목으로 나눠야 합니다. 공급자의 요청 속도 제한도 별도로 확인해야 합니다. Dify 요금제를 업그레이드했다고 해서 모든 모델 호출이 무제한이라고 판단할 수는 없습니다.

이미 사용이 허가된 제품 설명서를 바탕으로 고객 지원 답변 초안을 만드는 등 위험이 낮은 흐름을 선택하세요. 기준 답안이 있는 질문 스무 개를 준비하되, 자료가 부족하거나 표현이 모호하거나 범위를 벗어나는 질문도 포함하세요. 이 개수는 시범 운영을 위한 제안이지 공식 테스트 기준이 아닙니다.

동일한 흐름을 질문별로 실행하면서 답변을 채택할 수 있는지, 질문마다 모델 호출이 몇 번 발생하는지, 사람이 수정해야 하는지, 어느 단계에서 실패하는지 기록하세요. 시범 운영의 목적은 보기 좋은 평균값을 얻는 것이 아니라 두 종류의 문제를 구분하는 것입니다. 잘못된 자료를 자주 인용한다면 지식 베이스와 검색 로직부터 고쳐야 합니다. 답변은 이미 쓸 만하지만 협업 인원이나 자원 한도에 막힌다면 그때 유료 업그레이드를 검토하세요. 요금제 업그레이드가 콘텐츠 품질 개선을 대신할 수는 없습니다.

공식 Docker Compose 문서에 명시된 최소 하드웨어는 2코어 CPU와 4 GiB 메모리입니다. 이는 최소 배포 요건일 뿐, 운영 환경의 처리 용량을 보장하는 약속이 아닙니다. 또한 문서는 업그레이드할 때 새로 추가되거나 변경된 환경 변수를 확인하도록 요구합니다. 자체 호스팅이라고 해서 설치를 마친 뒤 관리가 필요 없어지는 것은 아닙니다.

팀에서 업그레이드, 백업 검증, 장애 처리를 누가 담당할지 명확히 할 수 없다면, 보통 클라우드 서비스를 먼저 구매하는 편이 책임과 투입 규모를 추산하기 쉽습니다. 운영 역량이 있다면 실제 데이터 흐름과 통제 요건에 맞춰 자체 호스팅을 검토하세요. 선택한 모델과 외부 서비스에서 데이터가 어디로 가는지도 확인해야 합니다. 앱이 자체 서버에 배포되어 있다는 이유만으로 모든 데이터가 내부에 남는다고 추정해서는 안 됩니다.

이제 시작하는 팀에 가장 안정적인 구매 순서는 작은 표본으로 흐름의 유용성을 입증하고, 실제 공동 관리 인원을 확인한 뒤, 플랫폼 구독료와 모델 청구액을 각각 예산에 반영하는 것입니다. 이미 쓸 수 있는 워크플로를 명확한 한도가 가로막을 때에야 업그레이드가 식별 가능한 편익을 사는 선택이 됩니다.