Sign in Subscribe
By paasup in Products —

DIP: 온프레미스에서 완성되는 데이터 인텔리전스 플랫폼

AI와 데이터는 클라우드에 올려야만 작동하는 게 아니다. 기업이 가장 중요한 데이터를 클라우드에 올리지 못하는 이유는 분명하다 - 규제, 보안, 주권. PAASUP DIP(Data Intelligence Platform)는 퓨어 오픈소스 기반의 현대적 빅데이터·지능화 서비스를 온프레미스에서 그대로 제공한다.

DIP: 온프레미스에서 완성되는 데이터 인텔리전스 플랫폼

1. 온프레미스의 딜레마 - 규제는 맞지만, 기존 방식으로는 안 된다

데이터 주권: 선택이 아닌 현실

기업의 83%가 소버린 AI를 전략적으로 중요하다고 판단한다.[1] 현재 144개국이 데이터 보호법을 시행 중이고, 60개국 이상이 데이터 현지화(localization)를 법적으로 요구한다. 10년 전에는 20개국도 되지 않았다.[2]

금융·의료·공공 분야의 핵심 데이터는 법률이 이동 경로를 제한한다. 한국 전자금융거래법은 금융회사의 개인 신용정보와 고유식별정보에 대해 클라우드 처리를 원칙적으로 금지한다.[3] GDPR은 EU 역외 데이터 이전에 적격성 결정이나 표준계약 조항(SCC)을 요구하며, 2025년 한 해만 23억 유로의 과징금이 부과됐다.[4] 2026년 8월 전면 발효되는 EU AI Act는 한 걸음 더 나아간다 — 데이터가 어디 있느냐가 아니라, 누가 스택 전체를 통제하느냐를 묻는다. 미국 CLOUD Act 때문에 EU 소재 서버라도 미국 기업이 운영하면 미국 사법 관할에 놓인다.[5]

데이터를 클라우드로 올릴 수 없다는 전제는 점점 더 많은 기업에 현실이 되고 있다. 문제는 온프레미스에서의 대안이 준비됐느냐다.

자체 구축의 현실: 시간, 인력, 운영 부담

오픈소스 스택을 직접 구축하는 방식은 자유도가 높지만, 실제 운영까지의 비용이 예상을 크게 벗어난다. Spark + Kafka + Airflow + MLflow를 프로덕션 수준으로 구축하는 데 드는 비용은 규모에 따라 5만 달러에서 200만 달러까지 달라지며, 하드웨어 조달부터 구성까지 통상 6개월 이상이 소요된다.[6]

운영도 쉽지 않다. Airflow 장애가 전사 운영을 중단시키는 상황을 경험한 기업이 46%에 달한다.[7] 문제를 해결할 인력을 구하는 것도 갈수록 어렵다. 2026년 현재도 채용 난이도는 낮아지지 않았다. 시니어 데이터 엔지니어 채용에 60~90일 이상이 소요되며, 아키텍처·AI 통합·거버넌스를 동시에 요구하는 포지션이 늘면서 적합한 인재는 더욱 희소해졌다.[8] 구인 속도가 인재 공급 속도를 앞서는 구조적 불균형은 여전히 해소되지 않고 있다.

버전 호환성도 지속적인 부담이다. 개별 오픈소스 프로젝트는 각자의 릴리스 주기를 따르기 때문에, 상호 연동되는 컴포넌트를 조율하는 것 자체가 엔지니어링 리소스를 잠식한다.

솔루션 기반 구축의 현실: 비용, 종속, 단종 리스크

벤더 솔루션은 통합 운영의 편의를 제공하지만, 다른 종류의 문제를 낳는다.

라이선스 비용이 가장 직접적인 부담이다. SAS 온프레미스는 단일 모듈 기준 연 2만~10만 달러, 엔터프라이즈 규모에서는 수백만 달러에 달한다.[9] 더 큰 문제는 플랫폼 종속이다. 벤더 고유의 포맷과 API에 맞춰 데이터 파이프라인과 거버넌스 체계를 구축하면, 이후 이전 비용이 사전 예방 비용의 16배에 달한다는 분석이 있다.[10]

단종 리스크도 현실화됐다. Hortonworks Data Platform(HDP) 3.1은 2022년 6월에 지원이 종료됐고, Cloudera Distribution Hadoop(CDH) 6.x도 같은 해 9월 서비스를 마쳤다.[11] 수년간 구축한 플랫폼 위에서 운영하던 기업들이 강제 마이그레이션을 맞이했다.

공통 한계: 현대 AI 워크로드를 감당하지 못한다

자체 구축이든 솔루션 기반이든, 현재 온프레미스 환경의 가장 큰 공백은 GPU 기반 AI 워크로드 지원이다. 온프레미스 GPU 클러스터를 구성하려면 50만 달러 이상의 초기 투자와 6~12개월의 도입 기간이 필요하다.[12] 막상 구축하더라도 GPU 활용률이 85%를 넘는 기업은 7%에 불과하다.[13] vLLM, NIM 같은 최신 LLM 서빙 기술은 기존 스택 위에서 그냥 올라가지 않는다.

결과적으로, 데이터 주권을 지켜야 하는 기업일수록 현대적 AI를 도입하기 어려운 역설에 놓인다. DIP는 이 역설을 해소하기 위해 설계됐다.

2. DIP가 만드는 것: Opensource as a Service 엔진

기업 환경에서 오픈소스 툴을 멀티테넌시로 운영하려면 툴마다 다른 결정이 필요하다. 어떤 툴은 하나의 인스턴스 안에서 테넌트를 논리적으로 분리할 수 있고, 어떤 툴은 테넌트마다 독립된 인스턴스를 배포해야 한다. 이 선택은 해당 오픈소스 프로젝트의 멀티테넌시 지원 범위, 라이선스 제약, 인증·인가 지원 수준, 도입 규모에 따라 달라진다. Gitea나 LiteLLM처럼 프로젝트 자체가 멀티테넌트를 지원하면 공유 인스턴스로 운영할 수 있지만, StarRocks나 KServe + vLLM처럼 Operator 기반으로 운영해야 하는 툴은 테넌트별 인스턴스 배포 전략이 따로 정의돼야 한다. 인증도 마찬가지다 — Airflow·Flowise처럼 게이트웨이에서 처리할 수 있는 툴이 있고, Kafka Connector처럼 클라이언트 자격증명으로 직접 연결해야 하는 툴이 있다.

이 결정을 툴마다 직접 설계하고 운영하는 것이 오픈소스 자체 구축의 실제 부담이다.

DIP의 OaaS 엔진은 이 복잡성을 카탈로그 수준에서 해결한다. 각 오픈소스의 특성에 맞는 배포 방식(네이티브 싱글테넌트·멀티테넌트 / Operator 싱글테넌트·멀티테넌트)과 인증 방식이 사전 정의되어 있고, 운영자는 카탈로그에서 툴을 선택하면 멀티테넌시 환경에 맞게 배포·연계가 자동으로 구성된다.

기업은 오픈소스의 복잡한 배포 결정 없이 퓨어 오픈소스 카탈로그를 멀티테넌시 환경으로 도입하고 운영할 수 있다. 배포는 클릭 한 번, 테넌트 구성은 자동, 벤더 종속성은 없다.

DIP 논리 모델

DIP 논리 모델 — 레이어 구성

데이터 저장 관리 → 컨테이너 운영 관리 → 데이터 실행엔진 → 라이프사이클 관리 → 데이터 지능화 서비스 → 데이터 분석 및 거버넌스의 6개 레이어로 구성된 DIP 논리 아키텍처

3. 퓨어 오픈소스 카탈로그 — 벤더 종속 없는 선택

DIP의 차별점은 스택의 각 레이어가 순수 오픈소스로 구성된다는 점이다.

DIP 오픈소스 카탈로그

DIP 아키텍처 — OaaS 엔진과 카탈로그 구조

DataOps(처리·분석·스토리지 관리)와 AIOps(개발·서빙·관리) 두 축으로 구성된 오픈소스 카탈로그. DIP Core(paasup Console·DIP API)가 Rancher·Keycloak과 연동해 멀티테넌시 환경을 관리한다.

DataOps

영역 구성요소
처리 Apache Airflow, Apache Spark, Apache Kafka, Apache Flink
분석 StarRocks, Apache Superset
스토리지 관리 Apache Iceberg, LakeKeeper

AIOps

영역 구성요소
개발 Kubeflow, MLflow, NVIDIA NeMo
서빙 KServe, vLLM, NVIDIA NIM
관리 FlowiseAI, OpenWebUI, VectorDB

플랫폼

영역 구성요소
클러스터 관리 Kubernetes (Rancher)
인증·인가 Keycloak
시스템 카탈로그 Gitea, Harbor, ArgoCD

특정 벤더의 독점 기술에 의존하지 않는다. 어느 구성요소든 대안 오픈소스로 교체 가능하다. 선택지는 항상 기업에 있다.

4. 현대적 빅데이터 관리: 세 가지 처리 방식

DIP의 빅데이터 레이어는 배치·실시간·가상화 세 축으로 구성된다. 스토리지 기반은 S3 오브젝트 스토리지 위의 Apache Iceberg(Bronze / Silver / Gold)이며, LakeKeeper가 Iceberg 카탈로그를 관리한다. 분석 서빙은 StarRocks가 담당한다.

DIP 데이터 처리 레퍼런스 모델

DIP 레퍼런스 모델

원천 시스템(정형·비정형)에서 S3 Iceberg(Bronze/Silver/Gold)를 거쳐 StarRocks MART·MRT로 서빙되는 배치·실시간 처리 흐름. PaaS 컨테이너 환경 내에서 Spark·Flink·Kafka가 각 처리 경로를 담당한다.

배치 처리 — 멀티스테이지 Spark 파이프라인

Oracle, MySQL, PostgreSQL 등 원천 시스템의 데이터를 Spark가 수집 지지 → 정제·가공 → 분류·집계 → 적재의 단계별 잡으로 처리한다. 각 단계 결과는 S3 Iceberg의 Bronze·Silver·Gold 레이어에 Parquet 포맷으로 누적된다. Bronze는 원천 그대로의 적재 영역, Silver는 정제·통합 영역, Gold는 분석 목적에 맞게 집계된 MART 영역이다. 최종 Gold 레이어는 StarRocks MART로 서빙되어 Superset 등 BI 도구에서 조회된다. Airflow가 파이프라인 전체의 스케줄링과 단계 간 의존 관계를 오케스트레이션한다.

성능 계획 (TPC-DS SF-100) 배치 적재 3시간 이내 · 10K rows/sec 이상 · 쿼리 Geometric Mean 60초 이내 · 동시 4사용자 저하 3배 미만
DIP 플랫폼 벤치마크 계획 — 배치 ELT·CDC·쿼리 성능 기준

성능 결과 (TPC-DS SF-100, 9.6억 rows) 배치 ELT 296K rows/sec · 적재 54분 · 쿼리 Geometric Mean 1.474초 · 동시 4사용자 2.48× — 전 기준 초과 달성
DIP 플랫폼 TPC-DS SF-100 벤치마크 — 배치 ELT·StarRocks 쿼리 성능

성능 결과 (TPC-DS SF-1000, 63억 rows) 배치 ELT 1,451K rows/sec · 적재 73분 · 쿼리 Geometric Mean 2.198초(Warm) · Trino 대비 3.09배 우위(97/99 쿼리) — 서브-리니어 스케일링 달성
DIP 플랫폼 TPC-DS 1TB 벤치마크 — 배치 ELT·StarRocks 쿼리 성능

실시간 처리 — Flink CDC · Kafka CDC · Flink 스트리밍

원천 DB의 변경을 실시간으로 포착하는 CDC 경로로 Flink CDC와 Kafka CDC를 모두 지원한다.

  • Flink CDC: PostgreSQL 등 운영 DB에 직접 연결해 변경 이벤트를 캡처하고 Iceberg로 적재한다. 별도의 메시지 브로커 없이 단일 파이프라인으로 구성되며, 체크포인트 기반으로 동작한다.
  • Kafka CDC: Debezium이 운영 DB의 변경 이벤트를 Kafka 토픽으로 발행하고, Kafka Sink가 Iceberg로 수신한다. 스트리밍 분석 경로에서는 Kafka 이벤트를 Flink가 정제·집계한 뒤 StarRocks MRT(실시간 MART)에 적재해 분석 레이어에 즉시 반영한다.

두 경로는 레이턴시 요구사항과 운영 복잡도 수용 수준에 따라 선택하거나 혼합 구성한다.

성능 참고 PostgreSQL → Iceberg CDC 9.6억 건 기준 경로별 초기 적재 속도·레이턴시 비교 실측
DIP 플랫폼 TPC-DS 벤치마크 Part 2 — 실시간 CDC 성능 비교(Flink CDC · Kafka CDC)

참고 Kafka → StarRocks → Superset 파이프라인으로 API Gateway 로그를 실시간 수집·파싱·시각화하는 구축 사례 — Fluent-bit·Fluentd 수집, Materialized View 기반 쿼리 최적화
실시간 API Gateway 로그 수집·분석 구축 사례

가상화 — StarRocks 기반 데이터 연합 조회

StarRocks의 External Catalog 기능을 활용해 S3 Iceberg에 적재된 데이터를 물리적으로 이동시키지 않고 직접 쿼리한다. Oracle·MySQL·PostgreSQL 등 이기종 원천 시스템도 External Table로 등록하면 StarRocks 단일 인터페이스에서 통합 조회가 가능하다. 데이터를 복제하지 않으므로 거버넌스와 위치 통제를 유지하면서 통합 뷰를 제공한다.

참고 StarRocks 아키텍처 및 MPP 쿼리 엔진 개요
StarRocks 아키텍처 — 분산 MPP 분석 엔진의 구조

5. 지능화 서비스: 온프레미스 AI의 완성

AI 서비스를 온프레미스에서 운영한다는 것이 불가능하거나 어렵다는 인식이 있다. DIP는 세 개의 레이어로 이를 구현한다.

NVIDIA Enterprise AI — NIM · NeMo

NVIDIA NIM(Inference Microservices)은 GPU 가속 추론 서비스를 컨테이너 단위로 패키징해 제공한다. TensorRT-LLM과 SGLang 백엔드를 지원하며, 온프레미스 GPU 클러스터 위에서 클라우드와 동일한 추론 인터페이스를 구성한다. NVIDIA NeMo는 기업 도메인 특화 모델의 파인튜닝·평가·배포를 온프레미스에서 전 과정 처리하는 LLM 개발 프레임워크다. NeMo Evaluator는 GSM8K 등 표준 벤치마크부터 커스텀 평가(유사도·툴 콜 정확도·LLM-as-Judge)까지 LLM 평가를 체계화하고 자동화한다.

참고 DIP 환경에서 NIM으로 Llama 모델을 프라이빗 환경에 배포하고 Flowise로 연결하는 구성
엔터프라이즈 LLM 서빙 가이드: NVIDIA NIM

참고 NeMo Evaluator로 LLM을 표준 벤치마크부터 커스텀 기준까지 평가하는 엔드투엔드 가이드
NeMo Evaluator로 LLM 평가하기

참고 NeMo Curator로 LLM 학습용 데이터셋을 클리닝·품질 필터링·중복 제거·언어 분류까지 처리하는 데이터 큐레이션 가이드 — GPU 가속(RAPIDS cuDF)으로 CPU 대비 최대 100배 성능
NeMo Curator로 LLM 학습 데이터 큐레이션하기

서버리스 vLLM — KServe 기반 온디맨드 LLM 서빙

vLLM은 PagedAttention 메모리 관리와 연속 배치(Continuous Batching) 기술로 GPU 처리량을 극대화하는 LLM 서빙 엔진이다. DIP에서는 vLLM을 KServe 서버리스 아키텍처 위에서 운영해 요청량에 따라 자동 스케일링되도록 구성한다. OpenAI API 호환 인터페이스를 제공하므로 기존 애플리케이션 코드 변경 없이 사내 LLM으로 전환할 수 있다.

참고 폐쇄망 환경의 KServe + vLLM 서버리스 구성 방법
서버리스 vLLM 온프레미스 배포 가이드

참고 DIP 플랫폼에서 KServe + vLLM 배포 후 Jupyter·OpenWebUI·Flowise 세 가지 인터페이스로 접근하는 엔터프라이즈 LLM 서빙 실전 가이드
DIP 플랫폼 엔터프라이즈 LLM 서빙 가이드 — KServe·vLLM·OpenWebUI·Flowise

LLMOps — 모델 생애주기 관리

MLflow가 모델 실험 추적·버전 관리·배포 파이프라인을 담당한다. 파인튜닝 실험부터 A/B 테스트, 프로덕션 배포, 롤백까지 LLM 생애주기 전체를 단일 인터페이스에서 운영한다. Kubeflow가 분산 학습과 파이프라인 오케스트레이션을 지원하며, FlowiseAI와 OpenWebUI가 현업 팀을 위한 노코드 AI 워크플로우 인터페이스를 제공한다.

6. 소버린 데이터·AI를 위한 설계

DIP의 아키텍처는 처음부터 온프레미스를 기준으로 설계한다.

에어갭 환경 지원

DIP의 OaaS 엔진은 외부 네트워크 없이도 완전히 동작한다. 배포 전략 결정부터 서비스 연계 관리·롤백까지 전 과정이 프라이빗 네트워크 경계 안에서 자립적으로 실행되도록 설계됐다. 오픈소스 이미지와 패키지는 인가된 내부 레지스트리를 통해 반입하고, 이후 배포·연계·갱신·장애 복구는 클러스터 내부에서 완결된다. 폐쇄망 환경에서 소프트웨어 공급망 전체를 온프레미스 경계 안에서 통제할 수 있다.

멀티 클러스터 오케스트레이션

단일 운영자가 분산된 여러 클러스터를 중앙에서 관리한다. 99.99% 가용성 목표의 자동 페일오버를 지원한다.

데이터 토폴로지는 조직의 요구에 따라 유연하게 구성한다. 단일 클러스터에 데이터 저장소를 두고 개발·검증·운영 클러스터가 배치·가상화·실시간 처리를 나눠 실행할 수도 있고, 클러스터마다 독립된 저장소를 갖도록 구성할 수도 있다. S3 기반의 대규모 오브젝트 스토리지를 공유 저장소로 두고 개발·검증·운영이 네임스페이스로 분리해 사용하는 구성도 가능하다. 처리 워크로드(배치·가상화·실시간) 또한 클러스터 단위로 분리하거나 단일 클러스터 내에서 리소스 격리로 운영하는 방식 모두를 지원한다.

규제 환경 실증

금융·공공 규제 환경의 실제 운영에서 검증된 아키텍처다. 각 분야의 규제 요구사항을 기본 전제로 설계한다.

7. 유스케이스 — DIP 기반 구현 사례

DIP 스택이 실제 현장 문제에 어떻게 적용되는지 보여주는 구현 사례 모음이다.

실시간 처리

사례 Kafka → Flink 전처리 → StarRocks 파이프라인으로 API Gateway 로그 분석 최적화 — 쿼리 복잡도 90% 감소 · 대시보드 응답 70% 개선 · 저장 공간 50% 절약
Apache Flink ETL 최적화 — API Gateway 실시간 로그 분석 파이프라인

배치 처리 — 지하철 이용자 통계 분석 시리즈

사례 #1 10년 서울 지하철 이용 데이터 수집·탐색 — Spark + Delta Lake + Superset 기반 도시 교통 패턴 인사이트 도출
파스업DIP로 구현하는 현대적 데이터 파이프라인: 지하철 통계 분석 #1

사례 #2 Jupyter 개발 코드를 Airflow DAG로 전환해 운영 자동화 — Kubernetes Secret 기반 보안·Spark Kubernetes Operator 오케스트레이션
파스업DIP로 구현하는 현대적 데이터 파이프라인: 지하철 통계 분석 #2

사례 #3 73,692건 시간별 승하차 데이터 분석 — 상위 5개 환승역이 전체 교통량의 25% 담당, 러시아워 혼잡도 패턴 규명
파스업DIP로 구현하는 현대적 데이터 파이프라인: 지하철 통계 분석 #3

사례 #4 spark-batch 프레임워크 도입으로 개발 생산성 50% 향상 + Superset 기반 ELT 모니터링 대시보드 구축
파스업DIP로 구현하는 현대적 데이터 파이프라인: 프레임워크 적용·ELT 모니터링 #4

7. 마치며

1장에서 제기한 역설로 돌아가보자. 데이터 주권을 지켜야 하는 기업일수록 현대적 AI를 도입하기 어렵다. 규제가 데이터를 온프레미스에 묶어두는 동안, AI 인프라는 클라우드를 전제로 진화해왔기 때문이다. 자체 구축은 시간과 인력을 잠식하고, 솔루션은 비용과 단종 리스크를 남긴다.

DIP는 이 역설이 기술적으로 해결 가능한 문제라는 전제에서 출발한다. 배치·실시간·가상화로 구성된 DataOps 레이어가 온프레미스에서 현대적 빅데이터를 처리하고, NIM·vLLM·LLMOps로 구성된 AIOps 레이어가 그 위에서 LLM 추론과 파인튜닝을 실행한다. 전 스택이 퓨어 오픈소스로 구성되기 때문에 플랫폼이 바뀌어도, 벤더가 바뀌어도, 데이터와 모델은 기업 안에 남는다.

데이터와 모델을 기업 안에 두면서 현대적 AI를 운영해야 하는 기업이라면, DIP를 검토할 시점이다.

참조

데이터 주권 및 규제

온프레미스 구축 현황

플랫폼 및 기술 블로그

Subscribe to PAASUP IDEAS

Don’t miss out on the latest issues. Sign up now to get access to the library of members-only issues.
jamie@example.com
Subscribe