List
멀티플레인 데이터 플랫폼 아키텍처 - 사용자 경혐 기반의 플랫폼
데이터 메시(Data Mesh)를 조직 전반에 안착시키기 위해서는, 사용자 경험 중심의 플랫폼을 설계해야 합니다. 이번 글에서는 멀티플레인(Multiplane) 아키텍처의 구체적인 구성과, 데이터 메시 생태계에서 다양한 역할(개발자, 데이터 과학자, 분석가, 거버넌스 팀원 등)을 어떻게 지원할 수 있는지 살펴보겠습니다. 특히 데이터 메시 경험 플레인, 데이터 프로덕트 경험 플레인, 데이터 인프라 플레인으로 구성된 멀티플레인 플랫폼 구조가 사용자 여정을 어떻게 최적화하는지 중점적으로 다룹니다.
1. 사용자 경험 중심의 멀티플레인 플랫폼 설계
1) 왜 사용자 경험이 중요한가?
•
데이터 메시의 목표: 도메인 팀이 자율적으로 데이터 프로덕트를 제공하거나 소비함으로써, 데이터 활용과 혁신 속도를 높이는 것
•
플랫폼의 역할: 다양한 사용자(개발자, 데이터 과학자, 데이터 거버넌스 팀원, 애플리케이션 개발자 등)의 여정을 이해하고, 각 단계에서 필요한 기능과 접근 방식을 셀프 서비스로 제공
“어떤 기능을 제공해야 하나?”가 아니라, “사용자가 어떤 여정을 거치는가?”를 고민함으로써 플랫폼의 기능·인터페이스를 정의합니다.
2) 멀티플레인(Multiplane) 아키텍처란?
데이터 메시 플랫폼은 단일 모놀리식이 아니라, 개방형 인터페이스를 통해 느슨하게 연결된 플레인(Plane)이라는 논리적 영역들의 조합으로 설계됩니다. 대표적으로 데이터 메시 경험 플레인, 데이터 프로덕트 경험 플레인, 데이터 인프라 플레인 등이 존재하며, 각각 상호 보완적으로 작동합니다.
•
데이터 메시 경험 플레인:
◦
메시 전체 운영·거버넌스·모니터링 등, 조직 수준에서의 사용자 경험 최적화
◦
여러 데이터 프로덕트 간 연관 관계, 검색, 리니지(Lineage) 조회 등
•
데이터 프로덕트 경험 플레인:
◦
실제 데이터 프로덕트를 검색, 이해, 소비, 빌드 및 유지 관리하는 기능 제공
◦
API, CLI, UI 등을 통해 개발자·분석가가 작업
•
데이터 인프라 플레인:
◦
리소스(스토리지·컴퓨팅 등) 성능과 활용도 최적화
◦
각 도메인 팀에 자율성을 주면서도, 인프라 복잡성을 표준화된 인터페이스로 추상화
2. 사용자 여정 중심 플랫폼 설계
1) 데이터 메시 생태계 주요 사용자 유형
1.
데이터 프로덕트 개발자
•
기존 프로덕트를 활용하여 새로운 분석 데이터 프로덕트 개발
•
운영데이터 도메인에서 데이터를 가져와 ML 모델이나 ETL 파이프라인 작성
•
예) 플레이리스트팀이 휴일 시즌 맞춤형 플레이리스트 데이터 프로덕트를 생성
2.
애플리케이션 개발자
•
운영 데이터 도메인에서 데이터 기반 서비스(예: 추천 엔진) 애플리케이션 빌드
•
실시간 또는 준실시간 데이터를 소비해야 하는 경우가 많음
3.
데이터 프로덕트 오너
•
특정 도메인 데이터 프로덕트의 비즈니스 성공 책임
•
플랫폼을 활용해 프로덕트를 최신 상태로 유지하고, 품질·성능 관리
4.
데이터 거버넌스 팀원
•
보안, 법률, 규정 준수 등 주제별 전문가
•
플랫폼에서 분산된 거버넌스를 용이하게 하는 역할 수행
5.
데이터 플랫폼 프로덕트 오너
•
플랫폼 자체를 ‘하나의 프로덕트’로 보고, 사용자 경험(UX)과 기능적 요구를 충족시키는 서비스 제공
6.
데이터 플랫폼 개발자
•
플랫폼을 빌드·운영·개발
•
사용자 요구를 반영해 플랫폼 기능을 진화시킴
2) 데이터 프로덕트 개발자의 여정 예시
•
인셉트 & 탐색
1.
플레이리스트팀이 새 휴일 시즌 플레이리스트를 기획.
2.
데이터 메시 경험 플레인(search, knowledge-graph, lineage)을 활용해, 유사한 정보를 가진 기존 데이터 프로덕트와 소스 검색
3.
음악 프로파일링을 위한 소스 찾기 및 기존 데이터 프로덕트 연결
•
부트스트랩 & 소스 연결
1.
데이터 프로덕트 경험 플레인(/{dp}/discover, /{dp}/observe, /{dp}/connect) 인터페이스로 문서화·메타데이터 조회
2.
신뢰할 수 있는 소스인지 모니터링·보증 지표(observe) 확인
3.
/init{dp}나 /register API를 통해 새 데이터 프로덕트 초기화·등록
•
빌드 & 테스트 & 배포 & 실행
1.
/{dp}/build, /{dp}/test, /{dp}/deploy 등 API 활용
2.
변환 로직, 데이터 무결성, 업그레이드 프로세스 등 테스트
3.
프로덕션 환경에 배포 후, /start {dp}, /stop {dp}로 인스턴스 실행 관리
4.
메시 거버넌스(local-policies {dp}, global-policies)도 적용
•
유지관리, 진화, 폐기
◦
/status, /logs, /traces, /metrics 등으로 운영 상황 모니터링
◦
/migrate, /controls 등을 통해 인프라 이전, 고권한 행정 통제 등을 실행
3. 머신러닝 모델을 데이터 프로덕트로 배포하는 경우
1) 운영 플레인 & 분석 플레인 경계의 모호함
머신러닝 모델은 예측·분류 기능 등을 제공하기 때문에, 운영 데이터(실시간 이벤트)와 분석 데이터(히스토리컬 로그)가 모두 필요할 수 있습니다.
•
인셉트 & 탐색: 기존 데이터를 검색해 모델 개발을 위한 가설 수립
•
부트스트랩: 데이터 프로덕트 경험 플레인을 활용해 필요 소스 연결, 실험 환경 구축
•
빌드 & 테스트 & 배포: 업스트림 데이터 프로덕트의 출력 포트({dp}/{output}/query, subscribe)를 가져와 모델 학습
•
유지관리 & 진화: 모델 성능 모니터링, 새 데이터 리비전 대응, 버전 업그레이드 등
2) “피처를 생성하는 데이터 변환 파이프라인”도 또 다른 데이터 프로덕트
•
예를 들어, 월요일 플레이리스트를 위한 “휴일 분위기 피처”가 별도의 데이터 프로덕트가 되어, 소스 데이터를 변환 후 출력합니다.
•
데이터 메시 환경에서는 이러한 파이프라인이 독립적인 데이터 프로덕트로 등록되고, 버저닝·액세스 제어 등을 통해 체계적으로 관리됩니다.
4. 사용자 경험 중심 플랫폼: 세부 인터페이스 예시
1) 데이터 메시 경험 플레인
•
/search, /knowledge-graph, /lineage : 유사 데이터 소스 탐색, 시맨틱 모델 조회, 리니지 파악
•
/monitor, /notifications, /global-controls : 전역 모니터링, 이상 징후 알림, 권한 높은 행정 통제
2) 데이터 프로덕트 경험 플레인
•
/{dp}/discover, /{dp}/observe : 문서화, 데이터 품질·릴리즈 빈도 확인
•
/{dp}/connect : 소스 연결, 액세스 정책 검증
•
/{dp}/build, /{dp}/test, /{dp}/deploy : 프로덕트 수명 주기 관리(컴파일~배포)
3) 데이터 인프라 플레인
•
/input-ports, /output-ports : 다양한 포맷(스트림·파일·테이블)으로 입·출력 지원
•
/transformations : 변환 로직 실행 인터페이스
•
/containers, /controls, /storage, /models, /identities : 인프라 자원, 보안 정책, 스키마 모델, 고유 식별 체계 등 제공
마무리
이번 글에서는 멀티플레인 아키텍처가 어떻게 사용자 경험을 중심에 두고 데이터 메시 플랫폼을 설계·운영하는지 살펴보았습니다. 다양한 역할(데이터 프로덕트 개발자, 거버넌스 팀, 애플리케이션 개발자 등)이 각자의 필요에 맞춰 셀프 서비스 방식으로 협업할 수 있도록, 경험 플레인을 분리하고 개방형 API를 제공함으로써 조직 전반의 데이터 활용 역량을 극대화할 수 있습니다. 이를 통해 도메인 팀은 데이터 프로덕트를 쉽게 검색·빌드·배포·유지 관리하고, 플랫폼은 표준화된 거버넌스와 리소스 활용을 보장하면서도 민첩하게 변화에 대응할 수 있습니다.
다음 글에서는 행위 지원성(affordance)에 의한 데이터 프로덕트 설계로 넘어가, 사용자가 어떻게 데이터 프로덕트와 상호 작용하고, 데이터를 검색·변환·거버닝·디버깅하며, 궁극적으로 더욱 가치 있는 결과물을 도출할 수 있는지 구체적으로 살펴보겠습니다.