Cloud Digital Leader의 2026년 8월 개정 출제 범위에서 도메인 2(약 18%)는 "데이터가 조직의 디지털 트랜스포메이션에서 하는 역할"로 시작합니다. 데이터베이스·데이터 웨어하우스·데이터 레이크의 구분, 1자·2자·3자 데이터, 데이터 공급망, 데이터 거버넌스, 그리고 데이터 사일로와 벤더 종속을 피하기 위한 개방성까지 개념 문제가 여럿 들어 있습니다. 제품 이름보다 개념을 먼저 이해해야 풀리는 문제들입니다.
이 글은 데이터가 왜 가치 있는지에서 시작해 저장소의 세 가지 유형, 데이터의 종류, 데이터 공급망, 데이터 거버넌스, 개방성과 상호 운용성 순서로 정리합니다. 정형·반정형·비정형 데이터와 Cloud Storage, BigQuery 같은 저장 서비스의 기본은 데이터 트랜스포메이션에서 먼저 다뤘습니다.
---
데이터는 왜 가치가 있나
데이터는 조직의 나침반과 같습니다. 지금 어디에 있는지, 어느 방향으로 가고 있는지, 어디로 가야 하는지를 알려 줍니다. 출제 범위는 데이터가 가치 있는 이유로 네 가지를 듭니다.
| 가치 | 의미 | 예 | |------|------|------| | 실시간 비즈니스 인사이트 | 지금 일어나는 일을 바로 보고 대응 | 결제 이상 징후를 즉시 발견해 사기를 막음 | | 추세 파악 | 시간에 따른 변화와 패턴을 발견 | 계절별 판매 추세로 재고를 미리 준비 | | 전략적 의사 결정 | 직감이 아니라 근거로 방향을 정함 | 지역별 수익성 분석으로 신규 매장 위치 결정 | | AI의 연료 | 좋은 데이터가 좋은 AI 모델을 만듦 | 상담 기록으로 고객 응대 에이전트를 학습 |
시험 팁: "AI 모델의 성능을 높이는 가장 중요한 요소"를 묻는다면 대부분 양질의 데이터입니다. 데이터는 분석의 대상이면서 동시에 AI를 움직이는 연료라는 점을 기억하세요.
---
데이터베이스, 데이터 웨어하우스, 데이터 레이크
세 저장소는 목적이 다릅니다. 데이터베이스는 매장의 계산대처럼 거래를 빠르게 기록합니다. 데이터 웨어하우스는 잘 정리된 도서관처럼 분석하기 좋게 다듬어진 데이터를 모아 둡니다. 데이터 레이크는 거대한 창고처럼 원본 데이터를 형식에 상관없이 일단 다 쌓아 둡니다.
| 구분 | 데이터베이스 | 데이터 웨어하우스 | 데이터 레이크 | |------|------|------|------| | 주된 목적 | 일상적인 거래 처리(OLTP) | 대규모 분석(OLAP)과 보고 | 원본 데이터를 그대로 대량 보관 | | 데이터 형태 | 주로 정형 | 정리하고 통합한 정형·반정형 | 정형·반정형·비정형 모두 | | 구조를 정하는 시점 | 저장하기 전 | 저장하기 전 (정제 후 적재) | 읽을 때 (일단 저장) | | 주 사용자 | 애플리케이션 | 분석가와 경영진 | 데이터 과학자와 데이터 엔지니어 | | Google Cloud 예 | Cloud SQL, AlloyDB, Spanner, Firestore | BigQuery | Cloud Storage |
요즘은 레이크의 유연성과 웨어하우스의 관리 기능을 합친 레이크하우스도 많이 씁니다. Google Cloud에서는 BigQuery와 Lakehouse(2026년 4월 BigLake에서 이름 변경)를 이용해 Apache Iceberg 같은 오픈 테이블 형식의 데이터를 BigQuery와 Spark 같은 여러 엔진이 함께 씁니다.
시험 팁: "주문을 받고 재고를 차감하는 앱의 저장소"는 데이터베이스, "여러 시스템의 데이터를 모아 경영 보고서를 만든다"는 데이터 웨어하우스(BigQuery), "로그, 이미지, 센서 데이터를 가공 없이 일단 저렴하게 쌓아 둔다"는 데이터 레이크(Cloud Storage)입니다.
---
데이터의 종류: 누가 모았나, 어떤 모양인가
출처에 따른 분류: 1자, 2자, 3자 데이터
| 종류 | 뜻 | 예 | 특징 | |------|------|------|------| | 1자 데이터(first-party) | 우리 조직이 고객과의 접점에서 직접 수집 | 웹사이트 방문 기록, 구매 이력, 앱 사용 데이터 | 가장 정확하고 신뢰도가 높음, 고객 동의 관리가 필요 | | 2자 데이터(second-party) | 다른 조직의 1자 데이터를 협약에 따라 직접 공유받음 | 항공사와 호텔이 제휴해 공유하는 고객 데이터 | 출처가 분명한 파트너에게서 받음 | | 3자 데이터(third-party) | 원래 수집자와 관계없는 제3자가 여러 출처에서 모아 판매 | 데이터 업체가 파는 인구 통계와 관심사 데이터 | 범위는 넓지만 정확성과 출처를 확인하기 어려움 |
형태에 따른 분류: 정형, 반정형, 비정형
| 종류 | 특징 | 예 | |------|------|------| | 정형 데이터 | 행과 열로 정해진 표 형식 | 주문 테이블, 매출 데이터 | | 반정형 데이터 | 표는 아니지만 태그나 키-값으로 어느 정도 구조가 있음 | JSON, XML, 이벤트 로그 | | 비정형 데이터 | 정해진 형식이 없음 | 이미지, 동영상, 음성, 이메일 본문 |
시험 팁: "제휴사가 자기 고객 데이터를 계약에 따라 직접 공유했다"는 2자 데이터입니다. "우리 앱에서 직접 모은 데이터"는 1자, "외부 업체에서 구매한 데이터"는 3자입니다.
---
데이터 공급망: 생성부터 활성화까지
농산물이 밭에서 수확되어 선별, 포장, 보관을 거쳐 식탁에 오르듯, 데이터도 생겨나서 실제 가치를 만들기까지 여러 단계를 거칩니다. 출제 범위는 이 흐름을 데이터 공급망이라고 부르고 여섯 단계로 나눕니다.
!데이터 공급망 6단계: 생성, 수집, 처리, 저장, 분석, 활성화와 단계별 Google Cloud 제품
| 단계 | 하는 일 | Google Cloud 예 | |------|------|------| | 생성(Genesis) | 데이터가 처음 만들어짐 | 앱 클릭, 결제, IoT 센서, 시스템 로그 | | 수집(Collection) | 여러 출처에서 데이터를 모음 | Pub/Sub, Storage Transfer Service, BigQuery Data Transfer Service | | 처리(Processing) | 정제하고 변환하고 결합 | Dataflow, Managed Service for Apache Spark | | 저장(Storage) | 용도에 맞는 저장소에 보관 | Cloud Storage, BigQuery, Cloud SQL | | 분석(Analysis) | 질문을 던져 패턴과 인사이트를 찾음 | BigQuery, BigQuery ML | | 활성화(Activation) | 인사이트를 실제 행동과 업무에 연결 | Looker 대시보드, 알림, 개인화 추천, AI 에이전트 |
가장 놓치기 쉬운 단계가 활성화입니다. 분석 결과가 보고서로만 끝나면 가치가 생기지 않습니다. 이탈 가능성이 높은 고객을 찾았다면 그 목록이 마케팅 시스템으로 넘어가 할인 쿠폰이 발송되어야 비로소 비즈니스 가치가 됩니다.
시험 팁: "분석 결과를 실제 업무 시스템과 의사 결정에 연결하는 단계"는 데이터 활성화입니다. 단계 순서를 묻는 문제도 나오므로 생성 → 수집 → 처리 → 저장 → 분석 → 활성화 순서를 기억하세요.
---
데이터 거버넌스: 믿고 쓸 수 있는 데이터
데이터 거버넌스는 도서관의 사서와 같습니다. 어떤 책이 어디에 있는지 목록을 관리하고, 누가 빌릴 수 있는지 정하고, 훼손된 책을 골라내 모두가 믿고 쓸 수 있게 합니다. 데이터가 많아질수록 이 관리가 없으면 아무도 데이터를 믿지 못하게 됩니다.
| 거버넌스 영역 | 하는 일 | Google Cloud 예 | |------|------|------| | 발견과 카탈로그 | 어떤 데이터가 어디에 있는지 목록을 만들고 비즈니스 용어를 정리 | Knowledge Catalog (옛 Dataplex Universal Catalog) | | 데이터 품질 | 정확성과 완전성 같은 품질을 점검 | Knowledge Catalog의 데이터 품질 기능 | | 계보(Lineage) | 데이터가 어디서 와서 어떻게 변환됐는지 추적 | Knowledge Catalog의 계보 기능 | | 접근 제어 | 누가 어떤 데이터를 볼 수 있는지 정함 | IAM, BigQuery의 열·행 수준 보안 | | 보호와 규정 준수 | 민감 정보를 찾아 가리고 보관 기간을 관리 | Sensitive Data Protection |
데이터 거버넌스가 중요한 이유는 다음과 같습니다.
개인정보 보호 같은 규정을 지킬 수 있음 같은 지표를 부서마다 다르게 계산하는 혼란을 막아 의사 결정의 신뢰도를 높임 AI 학습에 쓰는 데이터의 품질과 출처를 보장 민감한 데이터가 엉뚱한 사람에게 노출될 위험을 줄임
시험 팁: "데이터가 어디서 왔고 어떤 변환을 거쳤는지 추적한다"는 데이터 계보입니다. "조직 전체의 데이터를 찾아 목록화하고 품질을 관리한다"는 Knowledge Catalog 같은 데이터 거버넌스 도구입니다.
---
개방성과 상호 운용성: 사일로와 벤더 종속 피하기
데이터 사일로는 부서마다 데이터를 따로 쌓아 서로 볼 수 없는 상태입니다. 영업팀의 고객 정보와 고객 지원팀의 문의 기록이 연결되지 않으면 고객 한 명을 온전히 이해할 수 없습니다. 벤더 종속(vendor lock-in)은 특정 공급업체의 독점 형식과 도구에 묶여 다른 곳으로 옮기기 어려워진 상태입니다.
출제 범위는 데이터 관리 플랫폼의 개방성과 상호 운용성이 이 두 문제를 없애는 데 중요하다고 강조합니다. 먼저 두 용어를 구분하세요.
오픈 소스: 소스 코드가 공개되어 누구나 쓰고 고치고 배포할 수 있는 소프트웨어 (예: Apache Spark, Kubernetes, PostgreSQL) 개방형 표준: 누구나 구현할 수 있도록 공개된 규격 (예: SQL, HTTP, Apache Iceberg 테이블 형식)
| 방법 | Google Cloud 예 | 효과 | |------|------|------| | 오픈 테이블 형식 | Lakehouse(옛 BigLake)와 Apache Iceberg | 같은 데이터를 BigQuery, Spark, Flink, Trino 같은 여러 엔진이 복사 없이 함께 사용 | | 멀티클라우드 분석 | BigQuery Omni | Amazon S3나 Azure Blob Storage의 데이터를 옮기지 않고 BigQuery로 분석 | | 오픈 소스 호환 | Managed Service for Apache Spark, AlloyDB(PostgreSQL 호환) | 기존 코드와 기술을 그대로 활용 | | 통합 카탈로그 | Knowledge Catalog | 흩어진 데이터를 한곳에서 찾고 관리 |
시험 팁: "다른 클라우드에 있는 데이터를 옮기지 않고 분석한다"는 BigQuery Omni입니다. "특정 공급업체 형식에 묶이지 않게 한다"는 오픈 소스와 개방형 표준을 고르면 됩니다.
---
시험 핵심 정리
시험장 가기 전 마지막으로 확인할 핵심 포인트입니다.
| 구분 | 핵심 암기 사항 | |------|------| | 데이터의 가치 | 실시간 인사이트, 추세 파악, 전략적 의사 결정, AI의 연료 | | 데이터베이스 | 일상 거래 처리(OLTP), Cloud SQL · AlloyDB · Spanner · Firestore | | 데이터 웨어하우스 | 정리된 데이터의 대규모 분석(OLAP), BigQuery | | 데이터 레이크 | 원본 데이터를 형식 그대로 저렴하게 보관, Cloud Storage | | 레이크하우스 | 레이크의 유연성 + 웨어하우스의 관리, Lakehouse(옛 BigLake)와 Iceberg | | 1자 · 2자 · 3자 데이터 | 직접 수집 · 파트너가 직접 공유 · 제3자가 모아 판매 | | 정형 · 반정형 · 비정형 | 표 · JSON과 XML · 이미지와 동영상 | | 데이터 공급망 | 생성 → 수집 → 처리 → 저장 → 분석 → 활성화 | | 데이터 활성화 | 인사이트를 실제 업무와 행동에 연결하는 마지막 단계 | | 데이터 거버넌스 | 카탈로그, 품질, 계보, 접근 제어, 보호와 규정 준수 | | Knowledge Catalog | 옛 Dataplex Universal Catalog, 데이터 발견·품질·계보 | | 데이터 사일로 · 벤더 종속 | 부서별로 단절된 데이터 · 특정 업체 형식에 묶임 | | 오픈 소스 vs 개방형 표준 | 공개된 소스 코드 vs 누구나 구현할 수 있는 공개 규격 | | BigQuery Omni | 다른 클라우드의 데이터를 옮기지 않고 분석 |
---
다음 단계
데이터의 개념을 정리했다면, 이제 상황에 맞는 저장소를 고를 차례입니다. Cloud SQL, AlloyDB, Spanner, Bigtable, Firestore 중 무엇을 고를지와 스토리지 클래스, 데이터베이스 마이그레이션은 데이터베이스·스토리지 선택과 마이그레이션에서 이어집니다. 저장 서비스의 기본은 데이터 트랜스포메이션과 함께 복습하세요.
데이터 개념 문제는 "어디에 쌓나, 누가 모았나, 어느 단계인가, 믿을 수 있나" 네 질문으로 정리됩니다. CDL 모의고사에서 데이터 문제를 풀며 이 질문들을 적용해 보세요.