데이터를 밖에 보내지 않고 AI를 쓸 수 있을까? 금융·공공의 Dify 도입 사례

직답 요약

데이터를 밖에 보내지 않으려면 Dify를 사내에 설치하는 것만으로는 부족하고 모델과 검색, Embedding, 외부 API까지 데이터가 실제로 이동하는 경로를 전부 확인해야 합니다. 공개된 사례에서는 한 글로벌 은행이 약 3,000명의 RM과 80개 이상의 워크플로우를 하나의 Dify Enterprise 플랫폼 위에 올렸고, 한 광역자치단체는 관할 62개 기초지자체가 같은 플랫폼을 쓰면서 데이터와 작업 공간만 분리했습니다. 두 사례의 공통점은 좋은 모델을 설치한 것이 아니라 반복되는 실제 업무와 내부 데이터를 안전한 범위 안에서 연결했다는 점입니다.

고객 문서를 정리하거나 내부 규정을 검색하려면 AI가 조직의 자료를 읽을 수 있어야 합니다. 금융기관이나 공공기관에서는 여기서 바로 데이터 문제가 생깁니다. 외부 AI 서비스에 고객 정보나 내부 문서를 그대로 보낼 수 없는 경우가 많기 때문입니다. 그래서 이들 조직의 AI 도입에서는 모델 성능만큼 내부 데이터를 어떤 환경에서 어떻게 연결하고 운영할 것인지가 중요합니다.

공개된 Dify 사례를 보면 이 문제가 실제 조직에서는 어떻게 해결되는지 확인할 수 있습니다. 한 글로벌 은행에서는 약 3,000명의 RM이 80개 이상의 AI 워크플로우를 사용하고 있고, 한 광역자치단체에서는 본청과 관할 지역의 62개 기초지자체가 하나의 Dify Enterprise 환경을 공유하면서도 데이터와 작업 공간은 지자체별로 분리해 운영하고 있습니다.

사례 1: 약 3,000명의 RM이 80개 이상의 AI 워크플로우를 사용하는 글로벌 은행

기업금융 RM은 고객과 상담하는 일만 하는 것이 아닙니다. 미팅 전에는 CRM, 거래 내역, 과거 보고서와 시장 자료를 확인하고 이를 고객 도시에(dossier, 고객 기본 자료)나 어카운트 플랜 형태로 다시 정리해야 합니다. 여신 업무가 포함되면 고객 자료에서 필요한 내용을 추출하고 심사에 필요한 문서까지 준비해야 합니다. McKinsey는 복잡한 기업 고객의 경우 RM이 한 번의 미팅을 준비하는 데 반나절을 사용할 수도 있다고 설명합니다. 결국 문제는 문서 하나를 작성하는 시간이 아니라 여러 시스템에 흩어진 정보를 찾고 다시 정리하는 과정입니다.

Dify의 글로벌 은행 사례는 이런 업무를 AI 워크플로우로 옮겼습니다. 이 은행은 Dify Enterprise를 6개 사업부에 배포했고, 국제금융 부문에서는 약 3,000명의 RM이 80개 이상의 워크플로우를 사용합니다. 고객 도시에와 어카운트 플랜 작성부터 여신 심사 지원, 경쟁사 분석, 실시간 업무 데이터 조회까지 실제 RM의 업무 흐름 안에서 사용되고 있습니다.

예를 들어 고객 미팅을 준비할 때 담당자가 여러 자료를 직접 찾아 복사하고 정리하는 대신, 워크플로우가 필요한 데이터를 조회하고 정해진 형식에 맞춰 내용을 구성하도록 만들 수 있습니다. 여신 업무에서도 고객 자료에서 필요한 항목을 추출하고 관련 내용을 정리한 뒤 여신 메모의 초안을 만드는 과정까지 연결할 수 있습니다.

여기서 중요한 것은 여신 판단 자체를 AI에 맡긴 것이 아니라는 점입니다. 자료 검색과 정보 추출, 요약, 초안 작성처럼 반복할 수 있는 부분은 AI가 처리하고 고객이나 리스크에 관한 최종 판단은 담당자가 맡습니다. 저희가 금융기관의 AI 업무를 설계할 때도 자동화를 어디까지 할 수 있느냐보다 어디까지 자동화해도 되는 업무인가를 먼저 구분합니다. 이 사례가 흥미로운 이유 역시 챗봇 하나를 만든 것이 아니라, RM이 실제로 반복하던 업무 단위를 하나씩 AI 워크플로우로 전환했다는 데 있습니다.

80개의 AI를 따로 구축한 것도 아닙니다

은행 안에서도 사업부마다 필요한 AI는 다릅니다. 기업금융은 고객과 여신 자료를 다루고, 리스크 부서는 규정과 심사 정보를 확인하며, 다른 사업부에서는 시장 분석이나 고객 상담이 필요할 수 있습니다. 그렇다고 새로운 업무가 생길 때마다 AI 플랫폼까지 별도로 만들면 모델 연결, 계정과 권한, 로그, 배포 환경도 함께 늘어납니다.

이 은행은 반대로 6개 사업부가 하나의 Dify Enterprise 플랫폼을 공유하도록 구성했습니다. 플랫폼과 인프라, 운영 기준은 공통으로 관리하고 각 사업부는 자신에게 필요한 워크플로우와 데이터를 연결하는 방식입니다. 따라서 ‘80개 이상의 워크플로우’는 80개의 독립적인 AI 시스템을 구축했다는 의미가 아닙니다. 하나의 관리 가능한 AI 플랫폼 위에 80개 이상의 실제 업무를 올렸다는 의미에 가깝습니다.

전사 AI 플랫폼에서 중요한 차이입니다. 모든 부서가 같은 AI를 사용할 필요는 없지만, 각 부서가 AI 업무를 하나 만들 때마다 플랫폼부터 다시 구축할 필요도 없습니다. 공통 인프라와 모델 연결, 계정·권한, 로그와 배포 기준은 함께 운영하면서 실제 업무 애플리케이션과 연결 데이터는 사업부에 맞게 달리 구성할 수 있습니다.

AI도 은행의 핵심 시스템처럼 검증한 뒤 배포했습니다

약 3,000명의 RM이 실제 업무에서 사용하려면 워크플로우가 잘 작동하는 것만으로는 부족합니다. 새로운 기능을 검증해 안전하게 배포할 수 있어야 하고, 동시에 많은 사용자가 접속해도 안정적으로 처리할 수 있어야 합니다. 이 은행은 Dify Enterprise를 Red Hat OpenShift 위에서 운영하면서 `Dev → SIT → UAT → Test → Production`의 다섯 개 환경을 구성했습니다. 개발한 워크플로우를 바로 직원에게 공개하지 않고 시스템 통합과 사용자 검증을 거친 뒤 실제 운영 환경에 반영했습니다.

사용 규모가 커지면서 처리 용량도 함께 확장했습니다. 공개된 사례에서는 데이터베이스 튜닝과 마이크로서비스 구조를 통해 동시 처리 용량을 초기 5에서 50 이상으로 높였습니다. 업무를 검증해 배포하는 체계를 갖추는 동시에, 수천 명의 사용량을 감당할 수 있도록 인프라도 함께 확장한 셈입니다.

전사가 사용하는 AI 플랫폼 도입을 위해서는 워크플로우를 만들 수 있는 것만으로는 충분하지 않습니다. 변경된 기능을 검증하고, 운영 환경에 배포하고, 사용자가 늘어나면 처리 용량까지 확장할 수 있어야 실제 업무 시스템으로 사용할 수 있습니다. 이 사례는 Dify가 이런 엔터프라이즈 운영 요구사항을 기존 은행 시스템의 운영 방식 안에서 충분히 수용할 수 있음을 보여줍니다.

사례 2: 62개 기초지자체가 하나의 AI 플랫폼을 공유한 광역자치단체

지방자치단체에서는 서로 비슷한 행정 업무가 반복되는 경우가 많습니다. 회의록을 정리하고 내부 정책이나 규정을 검색하며 각종 행정 문서를 처리하는 업무가 대표적입니다.

필요한 AI 기능은 비슷하지만 실제 사용하는 내부 문서와 업무 데이터, 접근 권한은 지자체마다 다릅니다. 각 지자체가 AI 환경부터 별도로 구축하면 비슷한 기능을 계속 다시 만들어야 하고, 그렇다고 여러 지자체의 데이터를 하나의 작업 공간에 모아 운영하는 것도 보안 상 적절하지 않습니다.

Dify의 공공 부문 사례에서는 이 문제를 하나의 공통 플랫폼과 지자체별 워크스페이스로 나눠 해결했습니다. 광역자치단체가 설립한 디지털 전담기관이 Dify Enterprise 기반의 공유 생성형 AI 플랫폼을 운영하고 있으며, 광역자치단체 본청과 관할 지역의 62개 기초지자체가 같은 플랫폼을 이용합니다. 각 지자체에는 서로 분리된 워크스페이스가 제공되며, 문서 업무 효율화와 내부 데이터 기반 질의응답, 업무 전용 AI 어시스턴트 등이 실제 업무에 활용되고 있습니다.

예를 들어 한 지자체에서 회의록을 요약하고 후속 조치 항목을 추출하는 워크플로우를 만들었다고 해보겠습니다. 처리 방식이 검증됐다면 다른 지자체에서도 같은 워크플로우를 재사용할 수 있습니다. 하지만 실제 회의록이나 내부 자료까지 공유할 필요는 없습니다. A지자체는 A지자체의 자료를 연결하고, B지자체는 B지자체의 자료를 연결해 같은 업무 구조를 각자의 데이터로 사용할 수 있습니다.

즉 AI가 일하는 방식은 재사용하고, AI가 읽는 데이터와 접근 권한은 지자체별로 분리하는 구조입니다. 62개 지자체가 같은 기능을 각각 처음부터 개발하는 대신 검증된 AI 업무는 공통 자산으로 활용하고, 각 지자체에서 달라야 하는 데이터와 사용자 권한만 별도로 관리할 수 있습니다.

기업에서도 같은 구조를 적용할 수 있습니다. 인사팀과 구매팀 모두 사내 규정 검색이 필요하다면 검색 Workflow 자체는 공통으로 활용하면서 인사팀에는 인사 규정을, 구매팀에는 구매 규정을 연결하면 됩니다. 이 공공 사례가 보여주는 핵심은 단순히 여러 조직이 하나의 AI를 함께 사용했다는 것이 아니라 공통으로 재사용할 AI 기능과 조직별로 분리해야 할 데이터·권한을 나눠 운영했다는 점입니다.

Dify를 사내에 설치하는 것만으로 충분할까?

Dify를 사내에 설치하더라도 외부 LLM API를 연결하면 모델에 전달되는 질문과 참고 문서 일부는 외부 인프라에서 처리될 수 있습니다. 여기서 한 가지는 구분해야 합니다. Dify는 LLM 자체가 아니라 모델과 데이터, 업무 시스템을 연결해 AI 애플리케이션을 만드는 플랫폼입니다.

데이터 반출 제한이 엄격하다면 LLM만 확인해서도 안 됩니다. RAG 환경에서는 문서 Embedding, Vector DB, Reranker를 사용할 수 있고 Workflow에서 외부 API나 Tool을 호출할 수도 있습니다. 따라서 저희가 온프레미스나 폐쇄망 환경을 검토할 때는 “Dify가 내부에 설치됐는가”에서 끝내지 않고 데이터가 실제로 이동하는 전체 경로를 기준으로 아키텍처를 확인합니다.

‘모델 학습에 사용하지 않는다’는 조건과 ‘외부로 전송하지 않는다’는 조건도 구분해야 합니다. 외부 모델 사업자가 API 입력을 학습에 사용하지 않더라도 답변을 생성하려면 해당 데이터가 외부 인프라에서 처리될 수 있습니다. 고객 정보나 내부 문서의 외부 전송 자체가 제한된다면 모델뿐 아니라 검색과 Embedding, 외부 API까지 내부에서 처리할 수 있는지를 함께 확인해야 합니다.

중요한 것은 내부 데이터를 실제 업무에 연결하는 것입니다

두 사례의 공통점은 명확합니다. 글로벌 은행은 고객 도시에와 어카운트 플랜, 여신 심사 지원 자료 준비처럼 RM의 실제 업무를 AI 워크플로우로 만들었고, 공공 부문에서는 여러 지자체가 반복해서 사용하는 문서 처리와 내부 정보 검색 업무를 재사용 가능한 AI 자산으로 만들면서 데이터와 권한은 지자체별로 분리했습니다.

결국 사내 AI의 가치는 좋은 모델을 하나 설치하는 데서 나오기보다 우리 조직의 데이터와 반복되는 업무를 어디까지 안전하게 연결할 수 있는가에서 결정됩니다. 저희가 Dify 도입을 검토할 때도 모델부터 선정하기보다 어떤 업무를 줄일 것인지, 어떤 데이터가 필요한지, 그중 외부로 보낼 수 없는 데이터가 무엇인지, 그리고 AI와 사람이 각각 어디까지 처리할지를 우선적으로 확인합니다.

오픈네트웍시스템은 Dify 공식 국내 파트너로서 Dify Enterprise 구축과 기술 지원을 제공하고 있습니다. 금융·공공처럼 데이터 반출 조건이 중요한 환경에서는 업무와 데이터의 흐름을 먼저 확인한 뒤 Dify, LLM, RAG와 필요한 인프라를 함께 설계합니다.

AI 도입을 검토하고 있다면 민감한 원문부터 준비할 필요는 없습니다. 현재 반복해서 처리하는 업무와 사용하는 문서, 원하는 결과물, 외부로 나갈 수 없는 데이터의 범위부터 정리하면 어떤 구조가 필요한지 검토할 수 있습니다.

자주 묻는 질문

Dify를 사내에 설치하면 내부 데이터가 외부로 전혀 나가지 않나요?

Dify의 설치 위치만으로는 판단할 수 없습니다. Dify를 내부에 설치해도 외부 LLM API를 사용하면 모델에 전달되는 질문과 참고 데이터는 외부 인프라에서 처리될 수 있습니다. 데이터의 외부 전송을 제한해야 한다면 Dify뿐 아니라 LLM, Embedding 모델, Reranker, Workflow에서 호출하는 외부 API와 Tool까지 전체 데이터 흐름을 확인해야 합니다.

이미 사내 LLM이나 AI 인프라를 운영하고 있는데 Dify를 추가로 도입할 수 있나요?

가능합니다. Dify는 특정 LLM에 종속된 플랫폼이 아니기 때문에 이미 운영 중인 사내 LLM이나 별도의 모델 서빙 환경을 연결해 사용할 수 있습니다. 그 위에 RAG, Workflow, 업무용 AI 애플리케이션을 구성하는 방식입니다. 실제 구축에서는 기존 모델의 API 방식과 인증 구조, 네트워크 구간 등을 먼저 확인합니다.

CRM이나 ERP 같은 기존 업무 시스템의 데이터도 Dify에서 사용할 수 있나요?

기존 시스템에서 API나 데이터 접근 인터페이스를 제공한다면 Workflow와 연동할 수 있습니다. 모든 데이터를 Dify로 옮기기보다 필요한 업무가 실행될 때 해당 시스템에서 필요한 데이터만 조회하도록 구성할 수도 있습니다. 앞서 살펴본 금융 사례의 실시간 업무 데이터 조회처럼, 내부 시스템과 AI를 연결하면 문서 검색을 넘어 실제 업무 프로세스까지 확장할 수 있습니다.

부서마다 볼 수 있는 문서가 다른데 하나의 Dify 환경을 사용해도 괜찮을까요?

가능합니다. 다만 전사 도입이라면 처음부터 조직과 데이터의 분리 기준을 설계해야 합니다. 공공 사례처럼 공통 Dify 플랫폼을 사용하면서 조직별 워크스페이스를 분리하고, 각 조직에서 사용할 애플리케이션과 데이터의 범위를 나눌 수 있습니다. 이때 중요한 것은 워크스페이스를 나누는 것 자체보다 어떤 AI 기능은 공통으로 활용하고 어떤 데이터와 권한은 조직별로 분리할지 결정하는 것입니다.

금융·공공처럼 보안이 중요한 조직은 반드시 사내 LLM까지 구축해야 하나요?

반드시 그렇지는 않습니다. 어떤 데이터를 AI가 처리하는지와 조직의 외부 전송 정책에 따라 구성이 달라집니다. 외부 전송이 허용된 업무는 승인된 외부 LLM을 사용하고, 민감한 내부 데이터를 다루는 업무는 사내 LLM으로 분리하는 방식도 검토할 수 있습니다. 모든 AI 업무에 동일한 환경을 적용하기보다 데이터의 민감도와 업무 특성에 맞춰 처리 경로를 정하는 방식이 현실적입니다.

처음부터 전사 AI 플랫폼으로 크게 구축해야 하나요?

처음부터 모든 업무를 한꺼번에 적용할 필요는 없습니다. 내부 규정 검색, 고객 자료 정리, 반복 문서 작성처럼 사용할 데이터와 결과물이 명확한 업무부터 적용하고 실제 정확도와 처리 시간을 확인한 뒤 확대할 수 있습니다. 다만 이후 여러 부서와 사용자가 함께 사용할 계획이라면 초기 단계부터 사용자, 권한, 배포, 로그, 데이터 분리 구조가 확장 가능한지는 함께 확인하는 편이 좋습니다.

Dify 도입을 검토하기 전에 내부에서 무엇을 준비해야 하나요?

기술 스택부터 결정할 필요는 없습니다. 먼저 AI로 줄이고 싶은 업무, 해당 업무에 필요한 데이터, 데이터의 보안 수준, 현재 사람이 만드는 결과물을 정리하는 것이 좋습니다. 이 네 가지를 확인하면 외부 LLM을 사용할 수 있는지, 사내 LLM이 필요한지, RAG가 필요한지, 기존 시스템과 어떤 방식으로 연결해야 할지까지 구체적으로 설계할 수 있습니다.

출처

출처

• McKinsey & Company, Agentic AI is here. Is your bank's frontline team ready?

• Dify, Banking & Financial Services

• Dify, Public Sector

• Dify, Dify 제품 소개

• Dify, 모델 설정 안내

• 오픈네트웍시스템, Dify Enterprise 도입 안내