Insights - 선언형으로 구성하여 안정성을 확보하고 운영 리소스 감소시킬 수 있다. - 데이터 제품 중심으로 만들면 가치를 중심으로 효율적으로 발전할 수 있다. - DDP 기반의 기본 구성 요소를 통해 유연하게 조합할 수 있다. - 운영체제처럼 데이터 인프라를 숨기고 사용자에 따라 다르게 활용할 수 있게 할 수 있다. - 추상화하여 빠르게 변화하는 트렌드에서도 틀을 잡을 수 있다.사용자를 정의할 수 있다.
✅ DataOS란?
데이터를 위한 운영체제(OS)로, 기존 시스템을 뜯어고치는 것이 아니라, 현재의 데이터 환경을 더 유연하고 효과적으로 운영하게 도와줍니다.
전통적인 테이블 중심 구조에서 벗어나, 데이터 제품(Data Products) 중심으로 진화하는 것을 의미합니다.
🎯 왜 DataOS가 필요한가?
기존 데이터 엔지니어들은 인프라 관리(plumbing)에 많은 시간을 씀 → 가치 창출보다 유지보수에 매몰됨
일반 운영체제처럼, DataOS는 저수준 인프라를 추상화하여 개발자들이 데이터 애플리케이션 개발에 집중할 수 있게 함
다양한 데이터 사용자(데이터 사이언티스트, 데이터 엔지니어, 비즈니스 사용자 등)가 자율적으로 사용 가능
👥 DataOS 사용자 = 다양한 목적을 가진 ‘시민’
운영체제처럼, 사용자마다 다른 목적으로 같은 플랫폼 사용 가능
예: 게이머는 게임, 회계사는 엑셀, 음악가는 미디어 작업 → 다양한 요구를 하나의 시스템이 수용
인프라 팀은 소수, 대부분의 팀은 가치 창출에 집중
🚨 기존 데이터 스택의 문제점
다양한 도구들로 구성된 조립식(Assembled) 구조 → 중복, 비효율, 사용자 혼란
데이터 접근하려면 여러 단계를 거쳐야 함 → 비즈니스 팀도 비효율 ↑
도메인별 데이터 팀 구성은 비현실적 (인력 부족, 예산 부족 등)
"완전한 분산(Decentralization)"보다 "자율성(Autonomy)" 필요
🛡️ DataOS는 변화에 강하다
데이터 업계는 트렌드 변화가 빠름 (ex: Data Fabric → Data Mesh → 다음은?)
DataOS는 이런 변화에 흔들리지 않도록 해주는 ‘완충제’
핵심 원칙(DDP 기반)의 기본 구성 요소(Primitives)로 어떤 구조든 유연하게 조합 가능
2. Architecture
Insights - 비즈니스 중심: ROI를 실현하는 것을 목표로 하려면 데이터와 비즈니스가 연결이 되어야 하고 측정이 필요하다. - 도구가 아닌 단위로 역할에 따라 서비스로 크게 분리할 수 있다. - 선언형으로 서비스를 사용하고 내부에서는 도구와 연결하는 방식으로 추상화하는 것이 큰 변화 없이 기능을 사용하면서 지속적으로 발전하는데 도움이 될 것 같다. - 내부에서 사용하는 Native Apps는 명확하게 따로 분리하였다. - DataOS의 철학을 활용하려면 추상화를 할 수 있는 인터페이스를 제공해줬으면 좋았을 것 같다.
비즈니스 중심: ROI를 실현하는 것을 목표로 하려면 데이터와 비즈니스가 연결이 되어야 하고 측정이 필요하다.
도구가 아닌 단위로 역할에 따라 서비스로 크게 분리할 수 있다. 선언형으로 서비스를 사용하고 내부에서는 도구와 연결하는 방식으로 추상화하는 것이 큰 변화 없이 기능을 사용하면서 지속적으로 발전하는데 도움이 될 것 같다.
내부에서 사용하는 Native Apps는 명확하게 따로 분리하였다.
DataOS는 Databricks 처럼 다 해주는 느낌이다. DataOS의 철학을 활용하려면 추상화를 할 수 있는 인터페이스를 제공해줬으면 좋았을 것 같다.
🧠 DataOS란?
도메인별 데이터 제품(Data Products)을 쉽게 만들고 운영하기 위한 데이터 전용 운영체제(OS)
데이터 개발자 경험을 개선하고, IT 의존도를 낮추며, 빠른 ROI 실현과 자율성을 목표로 함.
🧩 핵심 마이크로서비스
서비스명
역할 요약
Heimdall
접근 제어 및 정책 결정(PDP) 담당
Metis
기술/비즈니스 메타데이터 수집 및 관리
Gateway
쿼리 요청 처리, 데이터 필터링 및 마스킹 수행
Caretaker
컴퓨팅 리소스 상태 모니터링 및 기록 저장
Minerva
연합 쿼리 엔진 (Compute & Storage 분리로 확장성 확보)
🧬 운영체제로서의 설계 (3계층 구조)
계층
설명
Cloud Kernel
클라우드 벤더(AWS/GCP/Azure) 추상화. IaC 기반, 클라우드 무관성 제공
Core Kernel
리소스(CPU, 메모리 등) 관리. 시스템 수준 API 및 권한 제어 담당
User Space
개발자가 데이터 제품을 개발, 배포, 운영하는 공간. GUI/CLI/API 제공
3. Resources
Insights - DataOS를 이루는 기본 단위이다. - 워크스페이스 수준의 리소스와 인스턴스 수준의 리소스를 분리하였다. - 쿠버네티스와 유사한 형태로 구현되었다. (YAML, IaC)
🔍 DataOS Resources란?
DataOS의 핵심 구성 단위로, 데이터 제품(Data Products)을 구성하는 원자적이면서도 논리적인 리소스
각각은 독립적인 생명주기를 가지며, 조합하여 다양한 데이터 아키텍처 구현 가능
YAML 기반 구성 파일로 정의되며, 버전 관리 및 코드화 가능 (IaC)
🧱 리소스 분류
구분
설명
워크스페이스 수준 (Workspace-level)
사용자/팀 단위로 격리된 작업 공간에서 사용하는 리소스 (예: Cluster, Workflow, Service 등)
인스턴스 수준 (Instance-level)
전체 시스템에서 공유되거나 활용 가능한 리소스 (예: Depot, Policy 등)
🔧 주요 속성 (YAML 필드 예시)
필드
설명
필수 여부
name
리소스 이름
✅
version
버전 정보
✅
type
리소스 타입
✅
tags, description, owner, layer
메타 정보
<resource-type>
리소스 고유 설정
✅
⚙️ CRUD 명령어 (CLI 기준)
작업
명령어 예시
생성/업데이트
dataos-ctl apply -f config.yaml
조회 (Read)
dataos-ctl get -t workflow -n my-workflow
삭제
dataos-ctl delete -t workflow -n my-workflow
구문 검사 (Lint)
dataos-ctl apply -f config.yaml -l
로그 보기
dataos-ctl log -t workflow -n my-workflow
🧠 리소스 구성의 의미와 장점
리소스는 ‘의도의 기록(record of intent)’ → 시스템이 현재 상태를 자동으로 조정(reconcile)
리소스 간 조합(Composable) 가능 → 다양한 아키텍처 (예: Data Mesh, Lakehouse 등) 구현
시스템은 자동으로 컴퓨팅 리소스 할당, 배포, 상태 관리를 처리
🛠️ 데이터 개발자가 리소스를 통해 할 수 있는 것들
파이프라인(ETL/ELT), 워크플로우 구성
애플리케이션/서비스 배포
데이터 접근 제어(Heimdall), 메타데이터 관리(Metis), 쿼리 실행(Minerva)
팀/조직 단위로 자기주도적 데이터 운영 가능 (셀프서비스화)
4. Data Product
Insights - 최종 목적지인 데이터 제품에서 데이터 수집부터 제공까지의 흐름을 확인할 수 있다. - 데이터 제품이라는 이름으로 테이블의 묶음을 분석할 수 있게 해준다. - 데이터 제품은 자체 완결성을 가지고 있다. - 데이터 제품이라는 틀 안에서 기능이 제공된다. 더 유연하게 파이썬 패키지를 통해 구현할 수 있을 것 같다. - 라이프사이클의 상태를 5개로 정의한다. - 4가지 포트를 통해 들어오고 나갈 수 있다. - SLO를 사용할 수 있다. - 피드백을 받고 진화할 수 있다. - 데이터 품질을 정의하고 확인할 수 있다. - 유형을 Entity-first와 Model-first로 나눈다. - 페르소나를 명확하게 구분한다.
목적 지향적이고 완결된 분석용 데이터 유닛으로, 단순한 데이터셋이 아닌 고품질의 데이터 제품입니다. DataOS 플랫폼 위에서 개발, 운영, 배포되며, 데이터 수집 → 변환 → 제공까지의 전체 흐름을 포함합니다.
🎯 Data Product의 핵심 특징
자체 완결형(Self-contained): 필요한 모든 요소(데이터, 메타데이터, API, 문서 등)를 포함
재사용 가능(Reusable): 다양한 분석 및 서비스에 반복 활용 가능
조합 가능(Composable): 다른 데이터 제품과 결합하여 확장 가능
클라우드 무관(Cloud-agnostic): 특정 인프라에 종속되지 않음
소비자 중심(Consumption-ready): 분석, 공유, 통합, 서비스에 바로 활용 가능
지속적 관리 필요: 주기적 업데이트와 품질 유지 필요
🛠️ Data Product 개발 라이프사이클
Design: 목표 정의 및 설계
Develop: 개발 및 테스트
Deploy: 배포 및 운영
Iterate: 지속적 개선 및 피드백 반영
Deprecate: 폐기
📄 Data Product Manifest
Data Product의 구성, 메타데이터, 설정 등을 정의하는 설정 파일입니다.
Input Ports: 외부 데이터 수신 (CSV, JSON, JDBC 등 형식 & 프로토콜 명시)
Output Ports: 외부 시스템/사용자에게 데이터 제공 (REST API, SQL 등)
Control Ports: 모니터링, 로깅, 메타데이터 제공 (버전, 소유자 정보 등)
Experience Ports: BI 툴, AI 연동, 자연어 쿼리 등 다양한 방식으로 데이터 접근 가능(예: Talos API, Lens, LLM 등)
