최근 몇 년간 “데이터는 자산”이라는 말이 당연하게 쓰이고 있지만, 막상 조직 안에서 데이터를 자산처럼 다루는 일은 생각보다 어렵습니다. 데이터가 어디에 어떻게 흩어져 있는지 파악하기도 힘들고, 같은 이름으로 부르던 데이터가 부서마다 다른 뜻으로 쓰이기도 합니다. AI와 머신러닝이 주류가 된 시대에는, 데이터의 질이 곧 결과의 질을 결정할 겁니다.
데이터를 잘 다루기 위해서는 먼저 데이터를 어떻게 구조화할 것인가에 대한 공통 언어가 필요합니다. 〈데이터 프로덕트와 아키텍처〉 시리즈는 조직이 데이터를 자산으로 다루기 위해 짚어야 할 두 가지 질문을 두 편에 나눠 다룹니다.
- 무엇을 관리할 것인가
- 그리고 어떤 기술 기반 위에 올릴 것인가
이번 글은 첫 번째 질문에 대한 이야기입니다. 조직 데이터 설계의 기본이 되는 세 가지 개념인 데이터 엘리먼트, 데이터 도메인, 데이터 프로덕트를 차례로 살펴보고, 데이터 품질을 평가하는 9가지 기준과 데이터 프로덕트를 식별하고 개발하는 6단계까지 이어서 다룹니다.
조직 내 데이터를 활용하기 위한 데이터 구성요소
어떤 니즈나 문제를 해결하기 위해 디지털 솔루션을 만들고자 한다면, 데이터를 잘 설계해야 기능 작동이나 제품 확장 단계에서 발생할 문제를 최소화할 수 있습니다.
데이터를 설계한다는 건 다음 사항을 고려한다는 뜻입니다.
- 구체적인 사용 사례(use case)들은 무엇인지
- 현재 사용 가능한 데이터는 무엇인지
- 추적해야 할 데이터는 무엇인지
- 이 데이터를 구성함으로써 발생하는 리스크는 무엇인지
- 데이터 자체에 대한 규제가 있는지
이 요소들을 정리하고 우선순위를 세운 뒤, 구조화해서 효과적인 솔루션을 만들 수 있도록 설계해야 합니다.
데이터 엘리먼트, 데이터 도메인, 데이터 프로덕트
데이터를 구조화한다는 건 다음과 같은 방식으로 확장된다는 뜻입니다.
- 데이터 엘리먼트(data element): 고유한 의미를 지닌 정보의 기본 단위. 예: 고객명, 고객 주소, 제품명, 날짜
- 데이터 도메인(data domain): 관련 데이터의 개념적 그룹. 데이터 거버넌스 활동이나 데이터 아키텍처를 짤 때 자주 쓰임
- 데이터 프로덕트(data product): 조직 구성원 누구나 쉽게 접근해 활용할 수 있는 고품질의 즉시 사용 가능한 데이터 세트. 일반적으로 데이터 도메인의 하위 집합
쉽게 비유하면, 엘리먼트는 재료, 도메인은 재료를 카테고리로 정리한 서랍, 프로덕트는 여러 서랍에서 재료를 꺼내 만들어둔 완성된 요리입니다. 각각의 개념은 아래 섹션에서 하나씩 상세히 다루겠습니다.
데이터 엘리먼트
데이터 엘리먼트는 그 자체로 의미를 지닌 정보의 최소 단위입니다. ‘고객 이름’, ‘거래 금액’, ‘가입 일자’처럼 더 쪼개면 의미를 잃어버리는 수준의 정보입니다. 은행에서 다루는 데이터 엘리먼트에는 ‘고객 이름’, ‘계좌번호’, ‘거래 금액’, ‘거래 일시’, ‘지점 코드’ 같은 것들이 있습니다. 각각은 하나의 값이지만, 혼자서는 할 수 있는 일이 많지 않습니다.
데이터 도메인이나 데이터 프로덕트처럼 상위 개념은 결국 엘리먼트들의 집합이기 때문에, 엘리먼트 수준에서 문제가 있으면 그 위에 쌓아 올린 모든 구조가 함께 흔들립니다. ‘고객 이름’ 필드가 어떤 시스템에서는 ‘홍길동’, 다른 시스템에서는 ‘Hong Gil-dong’, 또 다른 곳에서는 ‘HONG, GIL DONG’으로 저장되어 있다면, 이 세 시스템의 데이터를 합쳐 만든 고객 도메인과 고객 데이터 프로덕트는 처음부터 신뢰하기 어렵습니다.
그래서 데이터 엘리먼트를 다룰 때 가장 먼저 확인해야 하는 것이 두 가지입니다.
- 정의: 이 엘리먼트가 정확히 무엇을 뜻하는가. ‘가입 일자’가 서비스 회원가입 시점인지, 첫 거래 시점인지, 계약 체결 시점인지 같은 모호함이 없어야 합니다.
- 품질: 그 정의에 맞는 값이 실제로 얼마나 정확하고 일관되게 저장되어 있는가.
정의는 조직 내 합의로 잡으면 되지만, 품질은 별도의 기준과 절차를 통해 체계적으로 평가해야 합니다. 다음 절에서 살펴볼 ‘데이터 품질 9가지 기준’이 바로 이 평가를 위한 프레임워크입니다.
데이터 품질을 평가하는 절차와 9가지 기준
필요한 데이터가 없거나, 데이터가 있어도 품질이 낮다면 아무리 솔루션을 잘 만들어도 제대로 작동할 수 없습니다. AI 시대에 흔히 말하는 “쓰레기가 들어가면 쓰레기가 나온다(garbage in, garbage out)”와 같은 이치입니다. 실질적으로 데이터를 전처리하거나 사용하기 전에, 철저한 평가를 통해 데이터를 어떻게 구축해야 할지를 판단해야 합니다.
데이터를 평가하려면 크게 다음과 같은 세 가지 과정을 거칩니다.
- 첫째, 현재의 비즈니스 니즈와 앞으로 예상되는 니즈를 바탕으로 데이터 품질 규칙을 정의합니다.
- 둘째, 각 규칙마다 비즈니스 니즈를 충족할 목표값을 정합니다.
- 셋째, 데이터 품질을 측정하고, 앞서 정한 규칙 대비 성과가 어느 정도인지 보고합니다.
목표값을 측정하려면 다음 기준을 검토해보세요.
| 기준 | 핵심 질문 | 예시 상황 | 측정 방법 |
|---|---|---|---|
| 정확성 (Accuracy) | 데이터가 실제 사실과 맞는가? | 고객 DB의 주소가 실제 거주지와 일치하는가 | 샘플을 공식 출처와 대조해 일치하지 않는 비율을 계산 (예: 1,000건 중 942건 일치 → 94.2%) |
| 적시성 (Timeliness) | 데이터가 충분히 최신인가? | 고객이 주소를 변경했을 때 시스템에 반영되기까지 얼마나 걸리는지 | 실제 반영 시점이 어떻게 분포하는지 측정해 SLA 준수율을 산출 (예: 24시간 이내 반영 기준) |
| 일관성 (Consistency) | 같은 데이터가 여러 곳에서 같은 값을 갖는가? | CRM의 고객 전화번호와 대출 시스템의 전화번호가 동일한가 | 시스템 간 동일 고객의 동일 필드를 비교해 불일치 건수 집계 |
| 완전성 (Completeness) | 필요한 값이 다 채워져 있는가? | 필수 항목인 ‘생년월일’이 비어 있는 레코드가 몇 건인가 | 필드별로 null·공란이 차지하는 비율을 측정 (예: 생년월일 null 2.3% → 97.7%) |
| 유일성 (Uniqueness) | 같은 대상이 중복으로 저장돼 있지 않은가? | 동일 인물이 서로 다른 고객 ID로 두 번 등록되어 있지는 않은가 | 핵심 식별자(이름+생년월일+연락처 등)를 조합해 중복 레코드를 찾아냄 |
| 일관된 정의 (Coherence) | 같은 용어가 시간이 지나도 같은 의미인가? | 작년의 ‘활성 고객’과 올해의 ‘활성 고객’ 정의가 같은가 | 데이터 사전의 정의 변경 이력을 점검하고, 정의가 바뀐 시점 전후로 데이터를 비교할 수 있는지 확인 |
| 가용성 (Availability) | 필요할 때 꺼내 쓸 수 있는가? | 분석팀이 3년 전 거래 데이터를 조회하려 할 때 접근 가능한가 | 아카이브 정책, 접근 권한, 쿼리 응답 시간 점검 |
| 보안 (Security) | 접근 권한이 적절하고, 복구 가능한가? | 주민등록번호 접근 권한이 필요한 사람에게만 부여되어 있는가 | 접근 로그 감사, 암호화 적용 여부 점검, 백업·복구 테스트 수행 |
| 해석 가능성 (Interpretability) | 이 데이터가 뭘 의미하는지 누구나 이해할 수 있는가? | cust_stat_cd = 'A7'이 무엇을 뜻하는지 설명 없이 파악 가능한가 | 데이터 카탈로그의 정의 커버리지 — 즉, 전체 필드 중 설명이 달려 있는 필드의 비율 |
효율적인 데이터 소싱과 평가를 위해 사용할 수 있는 도구
데이터가 너무 많은 경우, Talend, Trillium Quality, Pherlink, Syncsort와 같은 머신 러닝 및 AI 도구를 기반으로 정제 과정을 효율적으로 만들 수 있습니다. 또한, 데이터를 최소한의 수준으로 구축한 뒤 데이터 보강(data enrichment)이라는 과정을 반복적으로 거쳐 보유한 데이터의 품질과 유형을 꾸준히 개선해 나가는 것도 하나의 방법입니다.
데이터 도메인
데이터 엘리먼트가 수천, 수만 개로 늘어나면 하나하나 관리하는 것이 불가능해집니다. 누가 어느 필드를 책임지는지, 어떤 데이터에 어떤 정책을 적용할지가 금세 엉켜버립니다. 그래서 관련 있는 엘리먼트들을 의미 단위로 묶어 관리하는데, 이 묶음이 데이터 도메인입니다.
데이터 도메인은 ‘같은 주제에 속한 데이터들’이라는 기준으로 엘리먼트를 묶은 개념적 단위입니다. 은행을 예로 들면 보통 이런 도메인들이 잡힙니다.
- 고객 도메인: 고객 ID, 이름, 생년월일, 주소, 연락처, 가입일 등
- 계좌 도메인: 계좌번호, 계좌 종류, 개설일, 잔액, 상태 등
- 거래 도메인: 거래 ID, 거래 일시, 거래 금액, 거래 유형, 상대 계좌 등
- 상품 도메인: 상품 코드, 상품명, 금리, 조건, 판매 기간 등
이 구분은 기술적 기준(어느 시스템에 저장되어 있느냐)이 아니라 비즈니스 의미를 기준으로 잡는 것이 원칙입니다. 같은 ‘고객 정보’라도 CRM, 대출 시스템, 모바일 앱에 흩어져 있을 수 있지만, 데이터 도메인 관점에서는 하나의 ‘고객 도메인’으로 묶어 바라봅니다.
도메인 단위로 데이터를 보면 세 가지가 명확해집니다.
- 소유권: 각 도메인에는 이를 책임지는 조직과 담당자(도메인 오너)가 정해집니다. 고객 도메인은 고객관리팀이, 거래 도메인은 리테일뱅킹팀이 소유하는 식입니다. 여기저기 흩어진 고객 정보의 최종 책임자가 한 명 있어야 정의 충돌이나 품질 문제가 제때 해결됩니다.
- 정책의 적용 범위: 데이터 보안, 보관 기간, 접근 권한, 품질 기준 같은 규칙을 도메인 단위로 묶어서 적용할 수 있습니다. 예를 들어 고객 도메인 전체에 개인정보 암호화와 접근 로그 의무를 적용하는 식입니다. 엘리먼트마다 개별 정책을 거는 것보다 훨씬 효율적입니다.
- 데이터 프로덕트의 재료: 뒤에서 다룰 데이터 프로덕트는 보통 하나의 도메인 전체 또는 여러 도메인의 조합으로 만들어집니다. 도메인이 잘 정의돼 있을수록 프로덕트 설계가 수월해집니다.
도메인은 곧 책임자와 출입 규칙을 정해두는 단위이기도 합니다. 이 구조가 있어야 다음 단계인 데이터 프로덕트가 가능해집니다.
데이터 로드맵
데이터 품질을 어느 정도 파악했다면, 현재 상태를 기반으로 어떻게 미래로 나아가야 할지에 대한 데이터 로드맵을 수립하는 것이 필요합니다. 즉, 디지털 솔루션이 고객의 니즈에 맞춰 발전해야 하는 것처럼, 이 가치를 제대로 구현하기 위해 데이터가 어떠한 형태로 구축되어야 할지와 어떤 리소스가 준비되어야 할지를 미리 계획해두는 일입니다.
데이터 로드맵은 크게 세 단계를 거칩니다.
- 현재를 위한 데이터 오퍼레이션 정의: 우선순위에 따라 데이터 엘리먼트를 확보하고, 해당 데이터를 조직이 어떻게 관리하고 사용할지를 정의합니다.
- 데이터 파이프라인 및 아키텍처 개발: 각 데이터 도메인에 필요한 데이터 파이프라인 및 아키텍처를 정의하고, 이후에 추가될 수 있는 데이터 도메인 및 엘리먼트에 대한 계획을 수립합니다.
- 데이터 거버넌스 구축: 데이터가 올바르게 관리되고, 새로운 데이터가 제대로 수집될 수 있는 규율을 확립하여 지속 가능한 구조를 만듭니다.
데이터 프로덕트
데이터도 하나의 프로덕트처럼 관리해야 합니다. 데이터는 시장의 고객뿐 아니라, 조직 내부에서도 사업적 의사결정이나 연구 목적으로 사용되기 때문에, 여러 사용자가 어떤 맥락에서 어떤 형태의 데이터를 필요로 하는지 제대로 파악하고 있어야 합니다. 그렇기에 데이터도 일종의 프로덕트로서 ‘데이터 프로덕트’의 개념을 적용해야 합니다.
데이터 프로덕트는 특정 도메인 또는 여러 도메인의 데이터를 조합해서 조직 구성원이 바로 꺼내 쓸 수 있게 정리해둔 ‘완제품’입니다. 예를 들어 ‘고객 360 데이터 프로덕트’는 고객 도메인의 기본 정보, 거래 도메인의 최근 거래 패턴, 상품 도메인의 보유 상품 정보를 이미 통합하고 품질까지 검증해둔 데이터 세트입니다. 마케팅팀은 캠페인에 쓰고, 리스크팀은 신용 평가에 쓰고, 앱 개발팀은 개인화 추천에 씁니다. 각 팀이 매번 원본 데이터를 끌어와 가공할 필요가 없다는 점이 핵심 차이입니다.
레거시 데이터 구조의 한계
레거시 데이터 구조를 이해하려면 먼저 다섯 단계의 구성 요소부터 짚어볼 필요가 있습니다.
| 단계 | 구성 요소 | 설명 |
|---|---|---|
| ① | 데이터의 원천이 되는 레코드 시스템 (Systems of record) | 데이터가 처음 생성되고 저장되는 자리. 거래·이벤트가 발생하는 운영 시스템, 외부에서 수집한 데이터, 문서·이미지·로그 같은 비정형 데이터가 여기에 해당합니다. |
| ② | 데이터 플랫폼 (Data platform) | 여러 레코드 시스템의 데이터를 한데 모아두는 중앙 저장소. 데이터 웨어하우스, 데이터 레이크, 운영 데이터 스토어 등이 함께 운영됩니다. |
| ③ | 유스케이스 전용 데이터셋 | 특정 용도에 맞게 따로 가공한 데이터 묶음. 이 지점부터 파이프라인이 갈라지기 시작합니다. |
| ④ | 유스케이스 전용 기술 | 각 데이터셋을 처리·분석하기 위해 유스케이스마다 따로 붙는 기술 스택. |
| ⑤ | 유스케이스 | 최종적으로 데이터를 활용하는 애플리케이션, 분석 모델, 리포트. |
많은 조직의 데이터 파이프라인은 파편화되어 있거나 중복되어 비용과 복잡성이 높은 경향을 보입니다.
[레거시 데이터 구조: 유스케이스마다 따로 만들어지는 파이프라인]
레코드 시스템 ──▶ 데이터 플랫폼
│
┌───────────────┼───────────────┬───────────────┐
▼ ▼ ▼ ▼
전용 데이터셋 A 전용 데이터셋 B 전용 데이터셋 C 전용 데이터셋 D
│ │ │ │
▼ ▼ ▼ ▼
전용 기술 A 전용 기술 B 전용 기술 C 전용 기술 D
│ │ │ │
▼ ▼ ▼ ▼
유스케이스 A 유스케이스 B 유스케이스 C 유스케이스 D
이 다이어그램의 핵심은 하나의 레코드 시스템에서 N개의 파편화된 파이프라인이 뻗어 나간다는 것입니다. 언뜻 보면 자연스러운 흐름 같지만, 한 번 가공한 데이터를 여러 유스케이스가 공유하지 못한다는 점이 본질적인 문제입니다.
예컨대 은행 조직에서 디지털 뱅킹 앱, 크로스셀링 예측 모델, 재무 보고서가 모두 ‘고객 데이터’를 필요로 한다고 해보겠습니다. 같은 고객 데이터가 필요한데도 각 유스케이스가 자기 기준으로 별도의 파이프라인을 파서, 서로 다른 포맷과 품질의 데이터셋으로 만들어냅니다. 결과적으로 세 가지 비효율이 쌓입니다.
- 중복 작업: 같은 레코드 시스템의 데이터를 유스케이스마다 따로 가공하기 때문에, 조직 전체로 보면 같은 일을 여러 번 반복합니다.
- 비용 증가: 유스케이스마다 기술 스택이 따로 붙으면서 라이선스·인프라·운영 인력이 몇 배로 들어갑니다.
- 품질 격차: 같은 ‘고객 ID’가 유스케이스마다 다르게 정의되고 품질 관리 방식도 달라지다 보니, 결과물 사이에 불일치가 생깁니다.
이 누적된 비효율을 해결하기 위해 등장한 접근법이 다음 절의 데이터 프로덕트 접근법입니다.
데이터 프로덕트 접근법
데이터 프로덕트란, 디지털 애플리케이션이나 내부 비즈니스 시스템이 데이터를 목적에 맞게 쓸 수 있도록 정리해둔 것을 말합니다. 데이터 프로덕트 접근법은 레거시 구조에 두 가지 새로운 개념을 더합니다.
| 단계 | 구성 요소 | 설명 |
|---|---|---|
| ① | 레코드 시스템 (Systems of record) | 앞 절과 동일. 데이터가 최초로 생성·저장되는 자리. |
| ② | 데이터 플랫폼 (Data platform) | 앞 절과 동일. 여러 레코드 시스템의 데이터를 모아두는 중앙 저장소. |
| ③ | 데이터 프로덕트 (Data products) | 특정 도메인(예: 고객, 거래, 상품 등)을 중심으로 품질·정의·포맷을 표준화해둔, 재사용 가능한 데이터 자산. 여러 유스케이스가 공통으로 꺼내 쓰는 ‘완제품’ 단위입니다. |
| ④ | 소비 아키타입 (Consumption archetypes) | 데이터 프로덕트를 어떤 식으로 활용하는지를 구분한 표준 유형. 구체적인 다섯 가지 유형은 다음 절에서 자세히 다룹니다. |
| ⑤ | 유스케이스 | 최종적으로 데이터를 소비하는 애플리케이션, 모델, 리포트. |
이 다섯 단계가 아래처럼 연결됩니다.
[데이터 프로덕트 접근법: 표준화된 자산을 여러 유스케이스가 공유]
레코드 시스템 ──▶ 데이터 플랫폼
│
▼
┌──────────────────────┐
│ 데이터 프로덕트 │
│ ┌──────────────────┐ │
│ │ 도메인 A (예: 고객) │ │
│ │ 도메인 B (예: 거래) │ │
│ │ 도메인 C (예: 상품) │ │
│ │ 도메인 D ... │ │
│ └──────────────────┘ │
└──────────┬───────────┘
│
┌───────────────┼───────────────┬───────────────┐
▼ ▼ ▼ ▼
아키타입 1 아키타입 2 아키타입 3 아키타입 4
(디지털 앱) (고급 애널리틱스) (리포팅) (외부 데이터 공유)
│ │ │ │
▼ ▼ ▼ ▼
유스케이스 A 유스케이스 B 유스케이스 C 유스케이스 D
이 다이어그램의 핵심은 데이터 플랫폼과 유스케이스 사이에 ‘데이터 프로덕트’라는 공유 계층이 생겼다는 점입니다. 그 결과 두 가지 변화가 일어납니다. 첫째, 도메인별로 한 번 제대로 정리해둔 프로덕트를 여러 유스케이스가 함께 꺼내 쓰게 되면서 중복 가공이 사라집니다. 둘째, 프로덕트와 유스케이스 사이에 소비 아키타입 층이 생기면서 “이 데이터가 어떤 용도로 쓰이는가”가 표준 유형으로 정리됩니다. 실시간 디지털 앱용인지, 머신러닝 모델용인지, 정기 리포트용인지에 따라 필요한 데이터 형태가 다르기 때문입니다.
데이터 프로덕트의 소비 아키타입 유형
데이터 프로덕트를 설계할 때는 “누가, 어떤 식으로 이 데이터를 쓸 것인가”를 함께 정해야 합니다. 같은 고객 데이터 프로덕트라도 실시간 앱에서 호출될 때, 분기별 리포트에서 쓰일 때, 머신러닝 모델의 학습 데이터로 쓰일 때, 저마다 필요한 데이터 형태·갱신 주기·품질 기준·거버넌스 수준이 전혀 다릅니다.
이 차이를 체계적으로 관리하기 위해, 맥킨지는 데이터 프로덕트가 쓰이는 방식을 다섯 가지 소비 아키타입으로 분류합니다. 아키타입은 단순한 ‘용도’ 목록이 아니라, 각 소비 방식에 필요한 데이터 구조와 운영 요건을 정형화한 템플릿에 가깝습니다. 아키타입을 먼저 정해두면 데이터 프로덕트를 어느 수준까지 가공·관리해야 하는지 기준이 명확해집니다.
| 아키타입 | 요건 | 활용 예시 |
|---|---|---|
| 디지털 애플리케이션 | 특정 형식과 주기로 정제·저장된 데이터(예: GPS나 센서 데이터 이벤트 스트림에 실시간으로 접근할 수 있게 제공) | 마케팅 트렌드 앱, 차량 추적 앱 |
| 고급 애널리틱스 시스템 | 특정 주기로 정제·제공되며 머신러닝·AI 시스템이 처리할 수 있도록 설계된 데이터 | 시뮬레이션 및 최적화 엔진 |
| 리포팅 시스템 | 정의가 분명하고 엄격하게 거버넌스되며, 품질·보안·변경 사항이 철저히 관리되고, 기본 수준으로 집계되어 감사 가능한 형태로 제공되는 데이터 | 운영 또는 규제 컴플라이언스 대시보드 |
| 디스커버리 샌드박스 | 원시 데이터와 집계 데이터의 조합 | 새로운 유스케이스 탐색을 위한 임시(ad hoc) 분석 |
| 외부 데이터 공유 시스템 | 데이터 위치와 데이터 관리·보안 프로세스에 관한 엄격한 정책과 협약을 준수하는 데이터 | 사기 인사이트를 공유하는 뱅킹 시스템 |
데이터 프로덕트 식별하기
모든 데이터 엘리먼트를 묶어 데이터 프로덕트화해야 하는 것은 아닙니다. 사용 사례가 반복적으로 일어나 재사용 가능성이 높고 사업적 가치도 높은 데이터에 한해 프로덕트로 구축하는 것입니다. 예를 들어, 특정한 하나의 사례에서만 사용되는 데이터라면, 해당 사례의 데이터 파이프라인에만 적용하는 식이죠.
프로덕트로 만들지 말지를 가르는 실질적 기준은 크게 세 가지입니다.
- 재사용 빈도
- 비즈니스 영향도
- 관리 난이도
이 세 기준이 큰 축이라면, 실무에서는 다음 질문을 던져보면서 구체적으로 판단할 수 있습니다.
“이 데이터들을 반복적으로 쓰는 서로 다른 유스케이스가 존재하는가?””이 데이터들을 반복적으로 쓰는 다른 유스케이스가 6개월 안에 새로 생길 것 같은가?”
답이 ‘그렇다’라면 프로덕트화 후보이고, 그렇지 않다면 당분간은 개별 유스케이스의 파이프라인으로 두는 것이 합리적입니다. 프로덕트 후보가 아니었던 데이터를 나중에 여러 곳에서 찾게 되면, 그때 프로덕트로 승격시켜도 됩니다.
핵심은 데이터 프로덕트는 ‘많을수록 좋은 것’이 아니라 ‘전략적으로 선택해 집중하는 자산’이라는 것입니다. 모든 데이터를 프로덕트로 만들려는 시도는 오히려 조직 리소스를 분산시키고, 정작 중요한 프로덕트의 품질과 운영 성숙도를 떨어뜨립니다.
데이터 프로덕트를 구축하는 것은 비용이 많이 들고 시간이 오래 걸리는 작업입니다. 그래서 구체적인 데이터 니즈, 사용 사례, 재사용 가능성, 사업적 가치에 대한 명확한 시각이 먼저 있어야 합니다.
데이터 프로덕트가 필요한지 판단할 때는 다음 질문이 도움이 됩니다.
- 이 데이터 프로덕트는 우리 조직만의 고유한 자산인가? ⇒ 내부에서 직접 만들지 않고 외부에서 합리적인 비용으로 구해올 수 있는지 살펴보세요.
- 이 프로덕트는 결국 사용하게 될 사람과 시스템에 쓸모가 있는가? ⇒ 조직 내부나 시장의 사용자가 반복해서 의미 있게 쓸 데이터인지 확인해보세요.
- “좋은 데이터”란 어떤 모습인가? ⇒ 데이터를 바로바로 얻는 것이 중요한지, 양이 적더라도 품질과 구체성이 뛰어난 것이 중요한지, 어떤 데이터가 어떤 형식으로 수집되어야 하는지에 따라 높은 품질의 기준은 달라집니다.
- 이 데이터 프로덕트가 지원할 수 있는 유스케이스는 몇 개이고, 그 가치는 얼마나 되는가? ⇒ 데이터 프로덕트는 데이터 자산의 활용도를 끌어올릴 수 있도록, 여러 사용 사례에서 두루 쓰일 수 있어야 합니다.
데이터 프로덕트 개발
데이터 프로덕트 개발은 크게 세 영역, 여섯 단계로 구성됩니다. 전체 흐름을 표로 정리하면 다음과 같습니다.
| 영역 | 단계 | 핵심 활동 | 주요 산출물 |
|---|---|---|---|
| 사전 계획 | ① 스코핑 (Scoping) | 프로덕트로 만들 집중 영역을 결정 | 우선순위가 매겨진 프로덕트 백로그 |
| ② 선정 (Selecting) | 선별하고 정리할 데이터 엘리먼트와 그 정의·형식을 결정 | 프로덕트 스펙 (포함 필드, 갱신 주기, 집계 수준 등) | |
| 반복 개발 | ③ 소싱 (Sourcing) | 데이터 확보와 현재 품질 측정 | 품질 기준선(baseline), 보강 계획 |
| ④ 구조화 (Structuring) | 유스케이스와 아키타입에 맞게 데이터 구조 설계 | 데이터 모델, 아키텍처, API, 파이프라인 | |
| ⑤ 공유 (Sharing) | 사용자가 꺼내 쓸 수 있게 배포 | 데이터 카탈로그 등록, 대시보드·리포트·API 엔드포인트 | |
| 운영 조율 | ⑥ 스티어링 (Steering) | 운영 점검, 역할·거버넌스 조율, 다음 릴리스 계획 | 오너십 정의, 개선 백로그, 다음 스프린트 계획 |
마무리
핵심은 데이터를 ‘관리해야 할 대상’이 아니라 ‘제품처럼 설계해야 할 자산’으로 바라보는 것입니다. 그리고 그 설계는 가장 작은 단위인 엘리먼트에서 출발해 의미 단위인 도메인으로 묶이고, 재사용 가능한 프로덕트로 완성됩니다.
다만 여기까지는 무엇을 관리할 것인가에 대한 이야기였습니다. 이렇게 설계한 데이터가 실제로 작동하려면 그것을 받쳐줄 기술 기반, 즉 데이터 아키텍처가 필요합니다. 데이터 레이크를 써야 할지, 레이크하우스로 가야 할지, 데이터 메시가 답이 될지는 조직의 규모와 성숙도에 따라 달라집니다. 다음 글 〈[데이터 프로덕트와 아키텍처] 데이터 아키텍처와 데이터 역량〉에서 이 선택의 기준과 조직이 갖춰야 할 데이터 역량을 다뤄보겠습니다.
데이터 프로덕트와 아키텍처 시리즈