AI 도입의 병목은 모델이 아니라 데이터라는 디노도의 주장

• 디노도코리아가 AI WAVE 2026에서 던진 메시지는 꽤 단순함. “AI 성공은 결국 데이터가 AI와 얼마나 잘 말이 통하느냐”에 달렸다는 얘기임

  • 좋은 모델, GPU, 클라우드, 인력도 중요하지만 기업 현장에서는 데이터가 여기저기 흩어져 있는 순간 AI 프로젝트가 바로 느려짐
  • 발표자는 로마가 길을 잘 깔아서 제국을 운영했듯이, 기업 데이터도 AI로 가는 길을 제대로 만들어야 한다고 비유함

• 지금 기업들이 힘든 이유는 모델이 없어서가 아니라, 모델이 너무 많아서임

  • 발표 기준 3주 전 허깅페이스에 등록된 AI 모델 수가 282만8727개라고 언급됨
  • 그런데 실제 PoC나 프로젝트에서 평가해볼 수 있는 모델은 적게는 3개, 많아야 6개 정도라서 “우리 업무에 뭐가 최선인가”를 판단하기가 빡셈
  • 오픈소스 기반 AI 모델은 계속 늘어날 전망이라, 모델 선택 문제는 더 복잡해질 가능성이 큼

• 기존 해법 중 하나는 데이터를 중앙에 다 모아 AI에게 먹이는 방식이었음

  • 데이터 중앙집중화는 성능 좋은 단일 환경에서 연산 속도를 끌어올릴 수 있다는 장점이 있음
  • 대신 구축 시간이 길고 운영 비용이 높으며, 완전한 마이그레이션을 끝까지 밀어붙이기도 쉽지 않음
  • 레거시 시스템이 많은 기업이면 “다 옮기자”는 말이 곧 프로젝트 지옥문이 될 수 있음

• 반대로 업무별 AI를 고르고 필요한 데이터만 분산 통합하는 방식도 만능은 아님

  • 필요한 데이터만 골라 물리적으로 옮기는 데 시간이 들고, 반복 가공이 늘어나며, 클라우드 사용량도 증가할 수 있음
  • 관리 채널이 늘어날수록 보안 취약점도 같이 늘고, 운영 난도도 올라감
  • AI 프로젝트가 몇 개일 때는 버틸 만해도, 조직 전체로 퍼지는 순간 관리 비용이 기하급수적으로 커지는 구조임

• 디노도의 답은 데이터 가상화임. 물리적 이동 대신 논리적 연결을 중심에 둔 접근법임

  • 레이크하우스나 SAP 애플리케이션 데이터, 오라클 데이터베이스 같은 소스가 AI와 직접 붙는 게 아니라 디노도를 통해 소통하는 구조를 제안함
  • 이렇게 하면 개발계로 불필요한 데이터를 옮기는 시간이 줄고, 접근 정책과 의미 체계도 한 계층에서 다루기 쉬워짐
  • 데이터가 어디 있든 AI 입장에서는 단일한 논리 공간처럼 보이게 만드는 게 목표임

• 디노도는 특히 레이크하우스의 현실적 한계를 겨냥하고 있음

  • 기업들이 겪는 문제로 분산된 데이터 환경, 파편화된 접근 권한과 시맨틱스, 보안, 데이터 탐색 복잡성, 최신성 제한을 꼽음
  • 디노도 액셀러레이터는 오픈소스 실행 엔진을 내장해 빠른 쿼리 성능과 CPU·메모리 효율을 제공한다고 설명됨
  • 고급 분석과 AI 워크로드를 확장하는 쪽에 초점이 맞춰져 있음

• 사례로는 인텔이 나옴. 숫자가 꽤 세다

  • 인텔은 디노도에서 4000개 이상 데이터 모델을 운영·관리 중이라고 함
  • 2014년부터 현재까지 단 한 차례의 다운타임 없이 서비스를 운영 중이라는 설명도 붙음
  • 단순 데모가 아니라 장기 운영 사례를 강조한 셈임

---

기술 맥락

• 여기서 중요한 선택은 데이터를 AI 쪽으로 복사해 모으는 대신, 데이터 접근 계층을 따로 두는 거예요. 기업 데이터는 SAP, 오라클 데이터베이스, 레이크하우스처럼 여러 시스템에 흩어져 있거든요. 이걸 전부 옮기면 비용도 크고, 권한 관리도 다시 짜야 해서 일이 커져요.

• 데이터 가상화가 게이트키퍼 역할을 하는 이유는 AI가 직접 원천 시스템을 찌르지 않게 만들기 위해서예요. 중간 계층에서 어떤 데이터에 접근할 수 있는지, 어떤 의미로 해석해야 하는지, 최신 데이터는 어디서 가져와야 하는지를 관리하면 운영 리스크를 줄일 수 있어요.

• 중앙집중형 데이터 플랫폼이 나쁜 선택이라는 얘기는 아니에요. 다만 완전 마이그레이션이 어려운 기업, 특히 레거시와 클라우드가 섞인 조직에서는 논리적 통합이 더 현실적인 출발점이 될 수 있어요. AI 프로젝트가 PoC를 넘어 운영으로 가면 데이터 이동 비용보다 접근 통제와 일관성이 더 크게 터지거든요.

• 인텔의 4000개 이상 데이터 모델 운영 사례가 의미 있는 건 규모 때문이에요. 데이터 모델이 몇십 개일 때는 수작업 관리도 가능하지만, 수천 개 단위가 되면 중앙 정책, 쿼리 성능, 다운타임 관리가 플랫폼 선택의 핵심 기준이 돼요.