기존 시스템을 바꾸지 않고 전사 AI를 쓸 수 있을까? 반도체·글로벌 제조기업의 Dify 도입 사례
직답 요약
전사 AI를 도입한다고 기존 시스템을 먼저 통합하거나 모든 업무를 하나의 AI 앱으로 합칠 필요는 없습니다. 공개된 사례에서는 약 58,000명이 쓰는 글로벌 반도체 기업이 자체 LLM 위에 Dify를 얹어 54개 R&D 센터의 기술 문서를 통합 검색했고, Fortune 500 제조 그룹의 현지 법인은 20개가 넘는 기존 OA·지식·Workflow 시스템을 유지한 채 4개 사업영역이 하나의 프라이빗 Dify Enterprise를 공유했습니다. 두 사례의 공통점은 기존 자산을 걷어낸 것이 아니라 그 위에 공통 AI 운영 기반을 얹었다는 점입니다.
전사 AI를 도입하려고 부서별 요구사항을 모아보면 금방 복잡해집니다. 연구개발 조직은 기술 문서를 검색하고 싶어 하고, 영업과 고객 대응 조직은 제품 정보를 바탕으로 답변을 만들고 싶어 합니다. 이미 자체 LLM이나 사내 지식베이스, ERP, 그룹웨어를 운영하는 회사라면 새 AI를 도입하기 위해 기존 시스템을 어디까지 바꿔야 하는지도 문제가 됩니다.
모든 업무를 하나의 AI 앱으로 통일할 필요는 없습니다. 실제 Dify 사례를 보면 글로벌 반도체 기업은 자체 LLM과 54개 R&D 센터의 기술 지식을 하나의 Dify 플랫폼에 연결했고, Fortune 500 제조 그룹은 4개 사업영역에서 사용하던 20개 이상의 기존 시스템을 유지하면서 하나의 프라이빗 Dify Enterprise를 공통 AI 기반으로 운영했습니다.
사례 1: 58,000명이 자체 LLM과 54개 R&D 센터의 지식을 연결한 글로벌 반도체 기업
반도체 기업의 연구개발 조직을 생각해보겠습니다. 특정 제품의 과거 설계나 애플리케이션 사례를 확인해야 하는데 관련 자료가 어느 연구센터에서 작성됐는지 알기 어렵고, 찾더라도 다른 언어로 작성돼 있을 수 있습니다. 고객이 기술적인 질문을 하면 고객 엔지니어 역시 데이터시트, 애플리케이션 노트, 매뉴얼, 과거 지원 자료를 오가며 근거를 찾아야 합니다.
문제는 자료가 없어서가 아닙니다. 수십 년간 축적한 지식은 많은데 필요한 순간에 찾아 쓰기 어렵다는 데 있습니다. Dify의 반도체 산업 설명에서도 연구개발과 고객 엔지니어링 조직이 기술 사양, 애플리케이션 노트, 제품 로드맵, 고객 지원 이력처럼 방대한 자료를 여러 지역과 언어에 걸쳐 보유하면서 검색과 활용에 어려움을 겪는 상황을 주요 제약으로 꼽고 있습니다.
여기에 자체 LLM까지 이미 개발한 기업이라면 고민이 하나 더 생깁니다. 모델은 있는데 실무에서 어떻게 쓸 지가 숙제입니다. “우리 모델이 질문에 답할 수 있다”와 “연구원이 회사의 기술 문서를 검색하고 업무에 필요한 답을 얻는다” 사이에는 지식 검색, 프롬프트, 업무 흐름, 사용자 인터페이스 같은 별도의 계층이 필요합니다.
이 글로벌 반도체 기업은 그 사이에 Dify Enterprise를 배치했습니다. 약 58,000명의 임직원이 하나의 Dify 플랫폼을 사용하고, Dify Enterprise는 Red Hat OpenShift AI 위에서 회사의 자체 LLM과 연결돼 있습니다. 외부 모델로 기존 투자를 대체한 것이 아니라 회사가 이미 보유한 LLM을 실무의 검색·어시스턴트·콘텐츠 생성 업무에 연결하는 오케스트레이션 계층으로 Dify를 사용한 사례입니다.
자체 LLM이 있는데도 업무에 연결하는 플랫폼이 필요할까?
예를 들어 자체 LLM에 “이 제품의 전압 조건을 알려줘”라고 물을 수 있다고 해도 그것만으로는 업무용 AI가 완성되지는 않습니다. 어떤 내부 문서를 먼저 찾아야 하는지, 최신 자료와 과거 자료를 어떻게 구분할지, 검색된 내용을 모델에 어떻게 전달할지, 최종 결과를 어떤 형식으로 보여줄지까지 정해야 합니다.
Dify는 이 과정에서 지식 검색, Workflow, Agent, 프롬프트와 모델 호출을 연결합니다. 연구원이 질문하면 관련 기술 문서를 먼저 검색하고, 필요한 문맥을 자체 LLM에 전달한 뒤, 결과를 업무에 맞는 형태로 생성하는 식입니다. 즉 LLM을 새로 만드는 것이 아니라 이미 가진 모델을 여러 업무에서 사용할 수 있도록 연결하는 역할입니다.
저희가 자체 LLM을 보유한 기업의 Dify 도입을 검토할 때도 “어떤 모델로 바꿀 것인가”보다 “현재 모델이 실제로 어떤 업무까지 들어가 있는가”를 먼저 봅니다. 모델 개발은 끝났지만 실무에서는 여전히 Chat UI 정도로만 사용하고 있다면, 다음 과제는 모델 성능보다 업무와 데이터의 연결일 가능성이 높습니다.
여러 R&D 센터에 흩어진 기술 지식을 한곳에서 활용할 수 있을까?
이 기업에서는 54개 R&D 센터의 기술 문서를 Dify에서 통합 검색할 수 있도록 구성했습니다. 문서는 10개 이상의 언어로 존재하며 번역과 요약도 함께 활용합니다. 한 지역에서 만들어진 기술 자료를 다른 지역의 엔지니어나 고객 대응 조직이 필요한 순간에 검색해 사용할 수 있는 구조입니다.
이런 환경에서는 같은 지식을 사용한다고 해서 모두 같은 AI 앱을 쓸 필요도 없습니다. 연구원은 과거 기술 자료와 제품 사양을 찾는 검색 도구가 필요할 수 있고, 고객 엔지니어는 같은 자료를 바탕으로 고객 질문에 답하는 어시스턴트가 필요할 수 있습니다. 콘텐츠 담당자는 여러 언어로 기술 콘텐츠를 만드는 업무에 활용할 수도 있습니다.
그래서 이 기업은 Dify 위에서 정보 검색, 가상 어시스턴트, 콘텐츠 생성이라는 서로 다른 업무를 운영합니다. 반대로 코딩은 별도의 개발자 전용 도구에 남겼습니다.
여기서 전사 AI 통합의 범위를 생각해볼 수 있습니다. 전 직원이 같은 도구 하나로 모든 일을 하게 만드는 것이 아니라, 공통으로 활용할 모델과 지식은 연결하면서 업무에 따라 적합한 AI 애플리케이션을 나눠 운영하는 방식입니다. 이미 전문 도구가 더 잘 처리하는 업무까지 억지로 Dify 안에 넣을 필요도 없습니다.
사례 2: 4개 사업영역과 20개 이상의 기존 시스템을 연결한 Fortune 500 제조 그룹
제조기업에서 전사 AI를 추진하면 다른 장면이 펼쳐집니다. 사업부 A는 오래된 OA 시스템을 사용하고, 사업부 B는 별도의 지식관리 시스템을 운영하며, 또 다른 조직은 자체 Workflow를 사용하고 있을 수 있습니다. 각각은 이미 잘 돌아갑니다.
이 상태에서 부서별 AI 프로젝트를 각각 시작하면 새로운 문제가 생깁니다. 사업부마다 별도의 AI 환경을 만들고, 각자 모델과 권한을 관리하고, 기존 시스템과 연결하는 작업도 다시 해야 합니다. AI 업무가 늘어날수록 기존 시스템 위에 또 다른 사일로가 하나씩 생기는 구조가 될 수 있습니다.
반대로 “전사 AI를 할 테니 기존 시스템부터 하나로 통합하자”고 하면 프로젝트의 범위가 급격히 커집니다. 제조기업의 기존 IT 환경에는 오랜 기간 운영해 온 업무 시스템과 데이터가 있기 때문에 AI 도입을 위해 이를 모두 교체하는 접근도 현실적이지 않은 경우가 많습니다. Dify 역시 제조기업의 AI 확산에서 사업부별로 다른 시스템·프로세스·데이터와 기존 IT 자산을 주요 제약으로 설명합니다.
Fortune 500 제조 그룹은 이 문제를 기존 시스템을 없애는 대신 그 위에 공통 AI 계층을 추가하는 방식으로 풀었습니다.
전사 AI를 도입하려면 기존 시스템부터 바꿔야 할까?
이 그룹은 Dify Enterprise를 프라이빗 환경에 구축해 4개 사업영역이 함께 사용하는 중앙 AI 플랫폼으로 운영합니다. 현재 300명이 넘는 부서 횡단 사용자가 같은 환경에서 AI 애플리케이션을 만들고 운영하며, 20개가 넘는 기존 OA·지식·Workflow 시스템을 플러그인과 SDK로 Dify에 연결했습니다.
중요한 점은 기존 시스템을 Dify로 교체하지 않았다는 것입니다.
예를 들어 구매 관련 데이터가 기존 시스템에 있다면 AI 도입을 위해 그 데이터를 새로운 플랫폼으로 전부 옮기는 것부터 시작할 필요는 없습니다. 구매 관련 AI Workflow가 실행될 때 기존 시스템에서 필요한 정보를 가져오고, AI가 이를 다음 작업에 활용하도록 연결할 수 있습니다. 기존 지식베이스나 Workflow도 같은 방식으로 AI 업무의 일부가 될 수 있습니다.
물론 플러그인과 SDK가 있다고 해서 모든 시스템이 자동으로 연결되는 것은 아닙니다. 실제로는 API 제공 여부와 인증, 네트워크, 데이터 구조를 확인해 연동 범위를 정해야 합니다. 하지만 AI 도입을 기존 시스템 전체의 교체 프로젝트로 만들지 않아도 된다는 점은 큰 차이입니다.
사업부마다 업무가 다른데 AI 플랫폼도 따로 구축해야 할까?
4개 사업영역의 업무는 사용하는 데이터와 시스템도 다르고 필요한 AI 애플리케이션도 다릅니다. 그렇다고 각 사업부가 별도의 Dify 환경을 구축하면 모델, 인프라, 보안, 운영 정책도 사업부별로 다시 관리해야 합니다.
이 제조 그룹은 하나의 프라이빗 Dify Enterprise를 공통 기반으로 사용하면서 사업부별로 워크스페이스를 나눴습니다. 인프라와 모델, 거버넌스는 중앙에서 관리하고 실제 애플리케이션 로직과 데이터는 해당 업무를 아는 사업부에서 구성하는 방식입니다.
예를 들어 자동차 사업부와 에너지 사업부가 모두 문서 검색 AI를 사용한다고 해도 같은 자료를 볼 이유는 없습니다. 플랫폼은 공유하면서 각 사업부의 지식과 Workflow, 사용자를 따로 구성할 수 있습니다.
이 사례에서 Dify가 해결한 것은 “네 사업부의 업무를 하나로 통일하는 것”이 아닙니다. 서로 다른 사업부가 AI를 만들 때 매번 플랫폼부터 다시 구축하지 않아도 되는 공통 운영 기반을 만든 것에 가깝습니다.
전사 AI를 도입하려면 모든 업무를 하나로 통합해야 할까?
두 사례 모두 기존 자산을 없애기보다 공통 AI 운영 기반을 그 위에 추가했다는 점이 같습니다. 반도체 기업은 자체 LLM과 54개 R&D 센터의 지식을 연결했고, 제조 기업은 20개 이상의 기존 시스템을 유지하면서 4개 사업영역의 AI를 하나의 프라이빗 플랫폼에서 운영했습니다.
따라서 전사 AI 통합에서는 모든 업무를 하나로 맞추기보다 무엇을 공통으로 운영하고, 무엇을 기존 시스템이나 전문 솔루션으로 유지할 지를 먼저 정하는 편이 중요합니다. Dify Enterprise도 기존 모델·데이터·시스템을 대체하기보다 여러 부서가 함께 사용할 AI 운영 계층으로 구성할 수 있습니다.
AX를 추진해야 하는데 어디서부터 손대야 할지 막막하다면, 제품을 먼저 정하기보다 현재 환경부터 함께 정리해보세요. 이미 쓰고 있는 시스템과 모델은 무엇인지, 반복적으로 사람이 처리하는 업무는 무엇인지, 어떤 데이터까지 AI에 연결할 수 있는지, 부서별로 무엇을 공통화하고 무엇을 남겨야 하는지를 확인하면 Dify가 적합한 영역과 그렇지 않은 영역도 구체적으로 나눌 수 있습니다.
오픈네트웍시스템은 Dify 공식 국내 파트너로서 특정 제품을 먼저 끼워 맞추기보다 현재 인프라와 업무, 데이터, 기존 AI 자산을 함께 살펴보고 Dify가 실제로 해답이 될 수 있는 범위부터 종합적으로 검토합니다. 전사 AI를 어떻게 시작해야 할지, 기존 시스템을 어디까지 유지해야 할지, 사내 LLM이나 RAG가 필요한지 판단이 서지 않는다면 상담을 통해 현재 상황을 공유해 주세요. Dify Enterprise 도입 여부부터 필요한 아키텍처와 연동 범위까지 함께 검토해드리겠습니다.
자주 묻는 질문
이미 부서마다 ChatGPT나 별도의 AI 도구를 쓰고 있는데, 굳이 전사 플랫폼이 필요한가요?
부서별 AI 사용 자체가 문제는 아닙니다. 다만 사용 부서가 늘면서 각자 모델 계약과 권한, 내부 데이터 연결, 애플리케이션을 관리하기 시작하면 운영 대상도 함께 늘어납니다. 전사 플랫폼은 모든 AI 도구를 없애는 것이 아니라 공통으로 관리해야 할 모델·데이터 연결·권한·운영 기준을 한곳에서 관리할 필요가 생겼을 때 검토할 수 있습니다.
자체 LLM이 있으면 Dify와 역할이 겹치지 않나요?
역할이 다릅니다. LLM은 실제 추론과 생성을 담당하고, Dify는 해당 모델을 지식과 Workflow, Agent, 업무 시스템에 연결해 애플리케이션으로 구성하는 역할을 할 수 있습니다. 글로벌 반도체 기업도 자체 LLM을 유지한 상태에서 Dify를 그 위의 오케스트레이션 계층으로 사용합니다.
기존 ERP나 그룹웨어, 지식관리 시스템을 Dify로 옮겨야 하나요?
반드시 그럴 필요는 없습니다. Fortune 500 제조 그룹은 기존 시스템을 유지하면서 20개 이상의 OA·지식·Workflow 시스템을 Dify와 연결했습니다. 실제 연동 가능 여부와 개발 범위는 해당 시스템의 API와 인증 방식, 네트워크 구조를 확인해야 합니다.
하나의 Dify를 사용하면 모든 부서가 같은 데이터까지 보게 되나요?
플랫폼을 공유하는 것과 데이터를 공유하는 것은 별개의 문제입니다. 사업부별 워크스페이스를 구성하고 사용할 애플리케이션과 데이터의 범위를 나눌 수 있습니다. 전사 도입에서는 무엇을 전사 공통 지식으로 둘지, 무엇을 특정 부서 안에 남길지를 먼저 정하는 것이 중요합니다.
전사 AI라면 모든 AI 업무를 Dify에서 처리하는 편이 좋지 않나요?
그럴 필요는 없습니다. 반도체 사례에서도 검색, 어시스턴트, 콘텐츠 생성은 Dify에서 운영하지만 코딩은 별도의 개발자 전용 도구를 사용합니다. Dify가 잘하는 업무를 공통 플랫폼에 모으고 이미 목적에 맞는 전문 도구가 있는 영역은 유지하는 방식이 더 현실적일 수 있습니다.
58,000명이 사용하는 사례라면 대기업에만 적합한 플랫폼인가요?
58,000명은 해당 사례의 배포 규모이지 Dify 도입을 위한 최소 규모가 아닙니다. 실제 필요한 인프라는 전체 직원 수보다 예상 동시 사용자 수, Workflow 호출량, 연결할 LLM과 RAG 데이터 규모에 따라 달라집니다. 소수 부서에서 시작해 사용 범위를 확대하는 구성도 가능합니다.
전사 Dify 도입 전에 내부에서 무엇부터 확인하면 좋을까요?
부서별로 원하는 AI 기능을 먼저 수집하기보다 현재 사용하는 시스템과 모델, 반복적으로 발생하는 업무, 그 업무에 필요한 데이터, 부서별 접근 권한을 먼저 정리하는 편을 권합니다. 여기에 기존 전문 도구 중 계속 유지할 영역까지 표시하면 Dify가 담당해야 할 범위와 시스템 연동 범위를 훨씬 구체적으로 정할 수 있습니다.
출처
출처
Dify, Semiconductor
Dify, Dify Enterprise
오픈네트웍시스템, Dify Enterprise 도입 안내