데이터 아키텍처를 설계하거나 점검하는 자리에서 자주 나오는 질문이 있습니다. “우리 회사는 데이터 웨어하우스를 쓰고 있는데, 요즘 다들 레이크하우스로 간다고 하더라고요. 바꿔야 할까요?” 데이터 레이크, 데이터 웨어하우스, 레이크하우스, 데이터 메시, 데이터 패브릭 등등 선택지는 많은데 각각이 어떤 문제를 풀려고 나왔고 우리 조직에는 뭐가 맞는지 정리하기가 쉽지 않습니다. 유행을 좇아 도구를 바꾸다 보면 정작 핵심 문제는 그대로 남는 경우도 많죠.
이 글은 〈데이터 프로덕트와 아키텍처〉 시리즈의 두 번째 편입니다. 지난 글에서는 조직 데이터를 엘리먼트·도메인·프로덕트로 구조화하는 법을 다뤘다면, 이번 글에서는 그 설계를 실제로 돌아가게 할 기술 기반을 이야기합니다. 5가지 대표 아키텍처 아키타입이 각각 풀려는 문제와 잘 맞는 조건을 비교하고, 어떤 아키텍처를 선택하든 조직이 갖춰야 할 6개 레이어와 4개 횡단 영역의 데이터 역량 맵, 그리고 이를 실제로 끌어올리는 4가지 실천 원칙까지 정리했습니다.
데이터 아키텍처
데이터 프로덕트를 실제로 구현하려면 그것을 받쳐줄 데이터 아키텍처가 필요합니다. 아키텍처는 데이터를 어떻게 저장하고 처리하고 접근할지를 정하는 기술적 기반입니다.
본격적으로 살펴보기 전에 각 아키텍처를 이해하는 데 필요한 기본 개념부터 짚어보겠습니다.
기본 개념
| 용어 | 설명 | 대표 서비스·도구 |
|---|---|---|
| 오브젝트 스토리지 (Object Storage) | 파일을 ‘객체’ 단위로 저장하는 대용량 저장 방식. 정형이든 비정형이든 가리지 않고 저렴하게 대규모로 쌓을 수 있어 클라우드 시대의 기본 저장소로 자리 잡았습니다. | AWS S3, Azure Blob Storage, Google Cloud Storage |
| 컴퓨트 (Compute) | 데이터를 처리·분석하는 연산 자원. 최근 아키텍처는 ‘저장’과 ‘처리’를 분리해서 각자 독립적으로 확장할 수 있도록 설계됩니다. | AWS EC2, Google Compute Engine |
| 데이터 웨어하우스 (DWH) | 분석용으로 정제·구조화해둔 데이터를 저장하는 데이터베이스. SQL로 빠르게 질의할 수 있도록 최적화돼 있어 주로 BI 리포팅에 쓰입니다. | Snowflake, Google BigQuery, Amazon Redshift |
| 데이터 레이크 (Data Lake) | 정제되지 않은 원시 데이터를 저장하는 대규모 저장소. 정형이든 비정형이든 모두 담을 수 있어 유연하지만, 그대로는 분석에 쓰기 어렵습니다. | AWS S3 기반 레이크, Azure Data Lake Storage |
| ETL / ELT 도구 | 원천 데이터를 추출(Extract)·변환(Transform)·적재(Load)하는 파이프라인을 만드는 도구 | dbt, Matillion, Fivetran, Airbyte |
| 테이블 포맷 (Table Format) | 데이터 레이크 위에서 안전하게 데이터를 바꾸고 스키마를 관리할 수 있게 해주는 저장 포맷 | Delta Lake, Apache Iceberg, Apache Hudi |
| 메타데이터 관리 플랫폼 | 데이터의 스키마·출처·품질 지표 등을 모으고 연결해 통합 관리 환경을 만들어주는 도구 | Collibra, Alation, Atlan |
이 용어들을 바탕으로, 다섯 가지 아키텍처 아키타입은 다음과 같이 정리됩니다.
다섯 가지 아키텍처 아키타입
| 아키타입 | 풀려는 문제 | 잘 맞는 경우 | 잘 안 맞는 경우 | 대표 서비스·도구 |
|---|---|---|---|---|
| 클라우드 네이티브 데이터 레이크 | “형식이 제각각인 데이터를 일단 싸게 모아두고 싶다” | 원시 데이터를 값싸게 대량으로 쌓아두고, 아직 용도가 정해지지 않은 데이터를 탐색하는 일이 잦은 조직 | 정제된 BI 중심 워크로드만 있는 경우 — 구조화를 위한 별도 작업이 오히려 낭비가 됨 | AWS S3 + Athena, ADLS, GCS + BigLake |
| 클라우드 네이티브 데이터 웨어하우스 | “정해진 질문에 빠르게 답하고 싶다” | 지표와 리포트가 정형화돼 있고, 분석가 중심의 SQL 기반 운영 환경 | 비정형 데이터 처리나 대규모 ML 학습이 주요 워크로드인 경우 | Snowflake, BigQuery, Redshift 변환: dbt, Matillion |
| 레이크하우스 | “분석(BI)과 머신러닝을 같은 데이터 위에서 하고 싶다” | BI와 AI/ML을 모두 지원해야 하거나, IoT처럼 대량 스트리밍 데이터를 다루는 환경 | 운영 성숙도가 낮은 조직 — 아직 도구와 노하우 생태계가 안정화되는 중이라 학습 비용이 만만치 않음 | Databricks 테이블 포맷: Delta Lake, Iceberg, Hudi |
| 데이터 메시 | “중앙 IT가 병목이 됐다. 각 도메인이 자기 데이터를 직접 책임지게 하고 싶다” | 조직 규모가 커져 중앙집중 관리가 한계에 부딪혔고, 도메인별 책임 체계를 세울 여건이 되는 경우 | 조직 규모가 작거나 도메인 오너십을 부여할 체계가 없는 경우 — 분산만 되고 주인 없는 데이터만 늘어남 | 기술이라기보다 조직 모델 지원 도구: Starburst, Dremio, Denodo |
| 데이터 패브릭 | “데이터가 이미 여러 클라우드와 시스템에 흩어져 있다. 옮기지 않고 통합해서 보고 싶다” | 멀티클라우드 환경이라 데이터를 옮기는 게 현실적으로 어려운 대기업 | 중소 규모 조직이거나, 이미 데이터가 한 환경에 모여 있는 경우 | 완성된 상용 솔루션 부재, 대부분 자체 구축 부분 지원: IBM, Talend, Informatica 계열 |
각 아키타입이 등장한 배경과 선택 기준을 좀 더 풀어보면 다음과 같습니다.
클라우드 네이티브 데이터 레이크 (Cloud native data lake)
“데이터는 계속 쌓이는데 아직 어떻게 쓸지 모르겠다”는 경우입니다. 로그·이벤트·외부 수집 데이터처럼 형태가 제각각인 자료를 일단 보관해뒀다가, 나중에 필요할 때 꺼내 쓰려는 조직에 맞습니다. 저장 비용이 낮고 확장이 자유롭다는 점이 가장 큰 매력이지만, 바꿔 말하면 쓸 수 있는 형태로 정제하는 작업이 늘 뒤따른다는 뜻이기도 합니다. 최근에는 이 구조만으로는 부족하다는 인식이 퍼지면서, 다른 아키타입의 발판 역할로 재해석되는 추세입니다.
클라우드 네이티브 데이터 웨어하우스 (Cloud native data warehouse)
어떤 지표를 봐야 하고, 어떤 리포트가 정기적으로 나와야 하는지가 이미 정해진 상태에서 SQL로 빠르게 답을 얻고 싶을 때 효율이 높습니다. 분석가가 주축이고 데이터 작업의 대부분이 BI와 정형 리포팅이라면 DWH 중심 설계가 여전히 가장 합리적입니다. 다만 머신러닝이나 비정형 데이터 처리가 중심이 되는 워크로드라면 이 방식만으로는 한계가 있습니다.
레이크하우스 (Lakehouse)
“BI도 ML도 포기할 수 없다”는 조직의 요구에서 나온 구조입니다. 과거에는 분석팀은 DWH, 데이터 사이언스팀은 레이크를 따로 운영하느라 같은 데이터를 두 번 관리해야 했는데, Delta Lake나 Iceberg 같은 기술이 그 경계를 허물었습니다. 한 벌의 데이터를 양쪽 목적 모두에 쓸 수 있다는 점이 핵심 가치이며, 특히 센서 데이터나 이벤트 스트림을 대량으로 다뤄야 하는 환경에서 강점이 두드러집니다. 아직 관련 도구와 운영 노하우가 완전히 무르익었다고 보기는 어렵지만, 빠르게 표준으로 자리 잡아가는 중입니다.
데이터 메시 (Data mesh)
데이터 메시는 “어떤 저장소를 쓸 것인가”의 문제가 아니라 “누가 데이터를 책임질 것인가”라는 물음에 답하는 접근입니다. 조직이 일정 규모를 넘어서면 중앙 IT팀 하나가 모든 도메인의 데이터를 이해하고 관리하는 것이 사실상 불가능해집니다. 이때 각 비즈니스 부서가 자기 도메인 데이터의 주인이 되어 ‘데이터 프로덕트’로 공급하게 하자는 것이 데이터 메시의 아이디어입니다. 앞서 다룬 데이터 도메인과 데이터 프로덕트 개념을 조직 구조에 그대로 적용한 모델이라고 보면 됩니다.
데이터 패브릭 (Data fabric)
데이터 패브릭은 현실과 타협한 방식에 가깝습니다. 대기업은 이미 여러 클라우드에 데이터가 흩어져 있는 경우가 많은데, 이를 한 곳으로 옮기는 일은 비용·규제·시간 측면에서 현실적이지 않습니다. 그래서 “데이터를 옮기지 않고, 메타데이터를 연결해서 마치 한 곳에 있는 것처럼 다룬다”는 발상이 나왔습니다. 개념적으로는 매력적이지만, 이를 완전히 구현해주는 상용 솔루션은 아직 없어서 대부분의 조직이 직접 조합해 구축해야 한다는 점이 현실적인 장벽입니다.
데이터 역량 강화
데이터 프로덕트와 아키텍처가 ‘설계’의 영역이라면, 데이터 역량(data capabilities)은 조직이 실제로 갖춰야 할 ‘기능 목록’입니다. 데이터가 원천에서 흘러들어와 최종 소비되기까지의 전 과정에서, 어떤 기능들이 어느 계층에 존재해야 하는지를 체계화한 맵이 아래 다이어그램입니다.
데이터 역량의 흐름
먼저 전체 구조를 큰 흐름으로 정리하면 다음과 같습니다.
[데이터 역량의 전체 구조: 아래에서 위로 흐르는 6개 레이어 + 4개 횡단 영역]
┌──────────────────────────────────────────────┐
│ ⑥ 데이터 소비 (Data Consumption) │
│ · 분석(BI) · 고급 애널리틱스 · 애플리케이션 │
├──────────────────────────────────────────────┤
│ ⑤ 데이터 서비스 (Data Services) │
│ · API · 분석 최적화 데이터 · 피처 스토어 등 │
├──────────────────────────────────────────────┤
│ ④ 데이터 저장소 (Data Repositories) │ ┌────────────────┐
│ · 오브젝트 스토리지 · 데이터베이스 · DWH │ │ [횡단 영역] │
├──────────────────────────────────────────────┤ │ │
│ ③ 데이터 처리 (Processing) │ │ · 파이프라인 │
│ · AI/ML · 스트림 처리 · 배치 처리 │ │ 오케스트레이션 │
├──────────────────────────────────────────────┤ │ · 거버넌스 │
│ ② 데이터 수집 (Data Ingestion) │ │ · 데이터 보안 │
│ · 배치 수집 · 이벤트 스트리밍 · 민감 데이터 처리 │ │ · 인프라 운영 │
├──────────────────────────────────────────────┤ └────────────────┘
│ ① 데이터 소스 (Data Sources) │
│ · 정형 데이터 · 비정형 데이터 │
└──────────────────────────────────────────────┘
데이터 흐름: ① 하단에서 ⑥ 상단으로 ▲
횡단 영역: 6개 레이어 전체에 걸쳐 작동
데이터는 아래에서 위로 흐릅니다. 원천에서 수집돼 처리되고, 저장된 뒤 서비스 형태로 노출되어 최종적으로 소비됩니다. 이 수직 흐름 옆으로 전 레이어를 관통하는 네 가지 횡단 영역(파이프라인 오케스트레이션, 거버넌스, 보안, 인프라 운영)이 함께 작동합니다. 어느 한 레이어만 잘 갖춰서는 소용이 없고, 여섯 레이어가 모두 균형 있게 성숙해야 전체 역량이 제대로 작동합니다.
데이터 역량 레이어별 역량과 서비스
각 레이어에서 실제로 갖춰야 할 세부 역량과 업계에서 흔히 쓰는 대표 도구 카테고리를 정리하면 다음과 같습니다.
| 레이어 | 세부 역량 | 업계에서 쓰는 도구 |
|---|---|---|
| ① 데이터 소스 | 정형 데이터(거래/이벤트, 마스터 데이터, 외부 정형 데이터), 비정형 데이터(센서, 음성·이미지·영상, 텍스트, 소셜 미디어 콘텐츠) | 조직 내·외부의 운영 시스템, SaaS, IoT 디바이스, 외부 데이터 제공자 |
| ② 데이터 수집 | 배치 수집, 이벤트 스트리밍(CDC, 센서, 트랜잭션 이벤트), 민감 데이터 처리(PII 감지·보호) | 배치/ELT: Fivetran, Airbyte, Stitch 스트리밍: Apache Kafka, AWS Kinesis, Google Pub/Sub CDC: Debezium |
| ③ 데이터 처리 | AI/ML 학습·최적화(분산 학습, GPU 컴퓨트), 스트림 처리(실시간 변환·분석), 배치 처리(정제·변환·보강) | 배치 처리: Apache Spark, dbt 스트림 처리: Apache Flink, Spark Streaming AI/ML: SageMaker, Vertex AI, MLflow |
| ④ 데이터 저장소 | 오브젝트 스토리지(원시·정제·신뢰·서비스 존으로 계층화), 데이터베이스(관계형, NoSQL, 그래프 등), 데이터 웨어하우스 | 오브젝트 스토리지: S3, GCS, ADLS RDB: PostgreSQL, MySQL NoSQL: MongoDB, Cassandra, Neo4j(그래프) DWH: Snowflake, BigQuery, Redshift |
| ⑤ 데이터 서비스 | API 엔드포인트 및 관리, SQL 엔드포인트, 발행·구독, 분석 최적화 데이터, 피처 스토어, 데이터 페더레이션·가상화 | API 관리: Kong, AWS API Gateway 피처 스토어: Feast, Tecton 페더레이션/가상화: Starburst, Dremio, Denodo |
| ⑥ 데이터 소비 | BI·시각화·애드혹 SQL 분석, DS 개발 환경·모델 프로덕션, 운영 시스템·모바일/웹 앱 | BI: Tableau, Power BI, Looker DS 환경: Jupyter, Google Colab 애플리케이션: 사내 서비스·모바일·웹 앱 |
전체를 관통하는 횡적 레이어와 도구 예시
여기에 더해 전 레이어에 걸쳐 작동하는 네 가지 횡단 영역이 있습니다.
| 횡단 영역 | 주요 기능 | 업계에서 흔히 쓰는 도구 카테고리 |
|---|---|---|
| 데이터 파이프라인 오케스트레이션 | 파이프라인 작성과 스케줄링, 전 과정을 안정적·지능적으로 실행·관리 | Apache Airflow, Prefect, Dagster |
| 데이터 및 모델 거버넌스 | 데이터 카탈로그, 리니지·메타데이터 관리, 옵저버빌리티, 모델 거버넌스(MLOps) | 카탈로그: Collibra, Alation, DataHub, Atlan 옵저버빌리티: Monte Carlo, Bigeye MLOps: MLflow, Weights & Biases |
| 데이터 보안 | 인증·인가·암호화, 비밀 관리, 접근 제어 | ID 관리: Okta, Auth0, 클라우드 IAM 비밀 관리: HashiCorp Vault 접근 제어: Immuta, Privacera |
| 인프라 운영 | IaC(Infrastructure as Code), DevOps, 로깅·모니터링 | IaC: Terraform, Pulumi DevOps: GitHub, GitLab, CircleCI 모니터링: Datadog, Grafana |
이 맵을 놓고 조직의 현재 상태를 점검해보면, 거의 대부분의 조직이 특정 레이어만 유난히 발달하고 다른 레이어는 비어 있는 불균형 상태에 놓여 있습니다. 예를 들어 수집 레이어에는 투자를 많이 해 실시간 스트리밍까지 갖췄지만, 저장소나 서비스 레이어가 구식이라 수집된 데이터가 제때 활용되지 못하는 경우가 흔합니다. 이런 상태에서 특정 레이어에만 추가로 투자해서는 전체 역량이 올라가지 않습니다.
데이터 역량을 강화시키는 방법
데이터 역량을 실질적으로 끌어올리려면 네 가지 실천 원칙을 짚어볼 필요가 있습니다. 각 원칙이 어떤 문제의식에서 출발했고, 어떻게 실천해야 하며, 놓쳤을 때 실제로 무슨 일이 벌어지는지를 정리하면 다음과 같습니다.
| 원칙 | 문제의식 | 실천 방향 | 놓치면 생기는 일 |
|---|---|---|---|
| ① 라이프사이클 전반의 균형 | 특정 단계에만 투자가 몰리면 전체 흐름은 결국 가장 약한 지점에서 막힘 | 수집·처리·저장·서비스·소비 레이어를 함께 끌어올리고, 현 수준을 역량 맵으로 진단 | 실시간 수집은 갖췄지만 뒷단 처리가 배치에 머물러 효과가 반감됨 |
| ② 유연성 중심의 데이터 모델 | 테이블을 지나치게 잘게 쪼개면 오히려 탐색과 확장에 걸림돌이 됨 | 물리 테이블 수를 줄인 ‘스키마-라이트’ 접근으로 탐색 편의성과 확장 여지를 확보 | 새 유스케이스가 생길 때마다 스키마 변경 요청이 들어오고 쿼리가 복잡해짐 |
| ③ 모듈화된 진화형 아키텍처 | 특정 도구에 종속되면 기술을 바꿀 때 전체가 흔들림 | 컴포넌트 단위로 독립 교체가 가능하게 하고, API 기반 통합과 게이트웨이·워크벤치 활용 | 신기술을 들이려 할 때마다 전면 재구축으로 번지는 악순환 |
| ④ 비즈니스 도메인 정렬 시맨틱 레이어 | 같은 용어를 부서마다 다르게 해석하면 데이터 신뢰가 무너짐 | 도메인 기준의 단일 진실 공급원을 시맨틱 레이어로 구축하고, 그래프 DB 활용도 고려 | “매출”·”고객” 같은 기본 지표조차 부서마다 숫자가 다르게 나옴 |
이 네 원칙은 각각 따로 떨어진 처방이 아니라 서로를 떠받치는 구조입니다. 라이프사이클 균형(①)을 진단하려면 역량 맵이 필요하고, 그 맵을 유연하게 움직이려면 모듈 아키텍처(③)가 있어야 하며, 모듈 아키텍처가 제 역할을 하려면 그 위에 시맨틱 레이어(④)가 얹혀야 합니다. 그리고 이 모든 것은 유연한 데이터 모델(②) 위에서 돌아갑니다.
마무리
지금까지 5가지 데이터 아키텍처 아키타입(레이크, 웨어하우스, 레이크하우스, 데이터 메시, 데이터 패브릭)의 선택 기준과, 어떤 아키텍처에서든 조직이 갖춰야 할 6개 레이어와 4개 횡단 영역의 역량 맵, 그리고 이를 실천하는 4가지 원칙을 살펴봤습니다. 핵심은 어떤 아키텍처가 ‘최고’인지가 아니라, 우리 조직의 규모와 성숙도, 주요 워크로드에 어떤 것이 맞는지를 가리는 것입니다. 그리고 어떤 선택을 하든, 그 위에서 작동할 역량이 레이어별로 균형 있게 성숙해 있어야 한다는 점도 잊지 말아야 합니다.
데이터는 설계(프로덕트)와 구현(아키텍처) 어느 한쪽만 갖춰서는 의미가 없고, 두 축이 함께 성숙해야 조직이 데이터를 진짜 자산으로 쓸 수 있습니다. 〈데이터 프로덕트와 아키텍처〉 시리즈를 끝까지 읽어주셔서 감사합니다. 이 글이 조직의 데이터 기반을 점검하는 실마리가 되었기를 바랍니다.
데이터 프로덕트와 아키텍처 시리즈