Cloud Digital Leader의 2026년 8월 개정 출제 범위에서 도메인 2(약 18%)의 마지막 항목은 스마트 분석, 비즈니스 인텔리전스(BI) 도구, 스트리밍 분석이 비즈니스에 어떤 가치를 더하는지입니다. Looker가 데이터 접근을 어떻게 민주화하는지, BigQuery 데이터를 Looker로 분석해 실시간 보고서와 대시보드를 만들고 업무 흐름에 통합하는 가치, 실시간 스트리밍 분석이 왜 중요한지, 그리고 데이터 파이프라인을 현대화하는 Pub/Sub, Dataflow, Managed Service for Apache Spark를 묻습니다. 문제은행에서도 Dataflow와 Pub/Sub는 자주 나오는데, Dataproc은 2026년 4월 Managed Service for Apache Spark로 이름이 바뀌었습니다.
이 글은 배치 처리와 스트리밍 처리의 차이에서 시작해 실시간 분석이 중요한 이유, 파이프라인을 현대화하는 제품, Looker가 데이터를 민주화하는 방식, BigQuery와 Looker로 만드는 실시간 보고서와 워크플로 통합 순서로 정리합니다. 파이프라인의 큰 그림은 데이터 트랜스포메이션에서, 생성부터 활성화까지의 데이터 공급망은 데이터 기초 개념에서 먼저 다뤘습니다.
---
배치 처리와 스트리밍 처리
우체국을 떠올려 보세요. 하루 동안 모인 우편물을 저녁에 한꺼번에 분류하는 것이 배치 처리이고, 택배가 도착하는 즉시 분류해서 바로 배송 차량에 싣는 것이 스트리밍 처리입니다.
| 구분 | 배치 처리 | 스트리밍 처리 | |------|------|------| | 처리 시점 | 데이터를 모아 두었다가 정해진 시간에 한꺼번에 | 데이터가 들어오는 즉시 계속 | | 결과가 나오기까지 | 몇 시간에서 하루 | 몇 초 안팎 | | 예 | 월말 정산, 일일 매출 보고서, 대량 데이터 이전 | 이상 거래 탐지, 실시간 재고, IoT 경보 | | Google Cloud 예 | Dataflow 배치 작업, Managed Service for Apache Spark, BigQuery | Pub/Sub와 Dataflow 스트리밍, BigQuery 연속 쿼리 |
시험 팁: "데이터가 발생하는 즉시 처리해서 몇 초 안에 대응"은 스트리밍, "하루치를 모아 밤에 처리"는 배치입니다. Dataflow는 같은 프로그래밍 모델로 둘 다 처리할 수 있다는 점이 특징입니다.
---
실시간 스트리밍 분석이 중요한 이유
어떤 데이터는 우유처럼 유통 기한이 짧습니다. 결제가 일어나는 그 순간에는 사기를 막을 수 있지만, 다음 날 아침 보고서로 알게 되면 이미 피해가 난 뒤입니다. 출제 범위가 실시간 스트리밍 분석을 현대 비즈니스에 필수라고 설명하는 이유입니다.
| 산업 | 실시간 분석이 하는 일 | 늦으면 생기는 일 | |------|------|------| | 금융 | 결제 순간에 이상 거래를 탐지 | 사기 피해가 커짐 | | 소매 | 재고와 가격을 실시간으로 조정하고 개인화 추천 | 품절과 판매 기회 손실 | | 제조 | 센서 데이터로 설비 이상 징후를 감지 | 설비 고장과 생산 중단 | | 물류 | 차량 위치와 도착 예정 시간을 갱신 | 배송 지연과 고객 불만 | | 미디어와 게임 | 이용자 행동에 맞춰 콘텐츠와 이벤트를 바꿈 | 이용자 이탈 |
시험 팁: "고객이 매장에 있는 동안 맞춤 쿠폰을 보낸다", "기계가 고장 나기 전에 미리 알린다"처럼 "지금"이 중요한 문제는 스트리밍 분석이 답입니다.
---
파이프라인을 현대화하는 제품: Pub/Sub, Dataflow, Managed Service for Apache Spark
실시간 분석 파이프라인은 보통 이벤트를 받는 Pub/Sub, 처리하는 Dataflow, 저장하고 분석하는 BigQuery, 보여 주고 연결하는 Looker로 구성됩니다. 기존에 Spark나 Hadoop으로 만든 작업이 있다면 Managed Service for Apache Spark로 그대로 옮겨 처리할 수 있습니다.
!이벤트 출처에서 Pub/Sub, Dataflow, BigQuery, Looker로 이어지는 실시간 분석 파이프라인과 Managed Service for Apache Spark 경로
| 제품 | 역할 | 특징 | 맞는 상황 | |------|------|------|------| | Pub/Sub | 메시지를 받아 전달 (게시자와 구독자) | 비동기 방식, 보통 100밀리초 수준의 지연, 보내는 쪽과 받는 쪽을 분리 | 수많은 기기와 앱의 이벤트 수집, 시스템 간 연결 | | Dataflow | 스트림과 배치를 함께 처리 | Apache Beam 기반, 작업 VM을 자동으로 만들고 지우는 완전 관리형, 기본적으로 각 레코드를 정확히 한 번 처리 | 실시간 변환과 집계, ETL | | Managed Service for Apache Spark | Spark, Hadoop 같은 오픈 소스 처리 (옛 Dataproc) | 클러스터 방식과 서버리스 방식, 클러스터를 빠르게 만들고 필요 없을 때 끔 | 기존 Spark·Hadoop 작업 이전, 데이터 과학 | | BigQuery 연속 쿼리 | BigQuery 안에서 SQL을 계속 실행 | 들어오는 데이터를 SQL로 실시간 분석해 Pub/Sub나 Bigtable 등으로 내보냄 | SQL만으로 간단한 실시간 처리 |
Pub/Sub가 왜 필요한지 궁금할 수 있습니다. 보내는 시스템이 받는 시스템을 직접 부르면, 받는 쪽이 잠시 멈추기만 해도 보내는 쪽까지 멈춥니다. Pub/Sub가 가운데에서 우체통 역할을 하면 보내는 쪽은 그냥 넣기만 하고, 받는 쪽은 자기 속도로 꺼내 가면 됩니다. 이렇게 서로를 분리하면 시스템 전체가 더 유연하고 튼튼해집니다.
시험 팁: "수천 개의 기기에서 오는 이벤트를 받아 여러 시스템에 전달"은 Pub/Sub입니다. "스트림과 배치를 하나의 코드로, 서버 관리 없이 처리"는 Dataflow입니다. "기존 Hadoop과 Spark 작업을 최소한의 변경으로 클라우드로"는 Managed Service for Apache Spark입니다.
---
Looker: 데이터 접근을 민주화한다
데이터 민주화란 데이터 전문가만이 아니라 조직의 누구나 데이터를 이해하고 업무에 쓸 수 있게 만드는 것입니다. 문제는 사람마다 숫자를 다르게 계산하면 회의가 "누구 숫자가 맞느냐"로 끝난다는 점입니다. Looker는 모두가 같은 사전을 쓰게 해서 이 문제를 풉니다.
| Looker의 방식 | 설명 | 효과 | |------|------|------| | 시맨틱 레이어(LookML) | "매출", "활성 고객" 같은 지표를 한곳에서 한 번 정의 | 부서마다 숫자가 달라지는 혼란을 없앰 | | 셀프서비스 탐색 | SQL을 몰라도 클릭으로 데이터를 탐색하고 차트를 만듦 | 분석팀에 요청하고 기다리는 시간이 줄어듦 | | 데이터베이스에 직접 연결 | 데이터를 복사하지 않고 BigQuery 같은 데이터베이스에 바로 질의 | 항상 최신 데이터를 봄 | | 대시보드와 공유 | 대시보드를 만들고 예약 전송하거나 공유 | 같은 숫자를 경영진과 현장이 함께 봄 | | 임베딩과 API | 대시보드를 다른 앱과 포털에 넣고, 데이터를 다른 시스템으로 보냄 | 분석이 업무 화면 안으로 들어감 |
시험 팁: "조직 전체가 일관된 지표 정의로 데이터를 직접 탐색하게 한다", "데이터 접근의 민주화"는 Looker입니다. LookML이라는 단어가 보이면 Looker를 떠올리세요.
---
BigQuery와 Looker: 실시간 보고서와 워크플로 통합
출제 범위는 BigQuery의 데이터를 Looker로 분석하고 시각화하는 가치를 세 가지로 표현합니다. 실시간 보고서, 대시보드, 그리고 데이터를 업무 흐름에 통합하는 것입니다.
| 활용 | 예 | |------|------| | 실시간 보고서 | 스트리밍으로 BigQuery에 들어온 주문이 몇 초 안에 보고서에 반영 | | 대시보드 | 지역별 매출과 재고 현황을 경영진과 현장이 같은 숫자로 확인 | | 워크플로 통합 | 재고가 기준 아래로 떨어지면 담당자에게 알림, 영업 포털 안에 고객별 대시보드 삽입, 분석 결과를 다른 업무 시스템으로 전달 |
데이터가 대시보드에서 끝나지 않고 사람의 다음 행동으로 이어지는 것, 이것이 데이터 공급망의 마지막 단계인 활성화입니다.
Looker와 Data Studio 구분하기
Google에는 이름이 비슷한 BI 도구가 둘 있습니다. 2022년에 Data Studio에서 Looker Studio로 바뀌었던 무료 시각화 도구는 2026년 4월 다시 Data Studio라는 이름으로 돌아왔습니다. 개인용 시각화 도구와 엔터프라이즈 BI 플랫폼인 Looker를 혼동하지 않게 하려는 것이 이유입니다.
| 구분 | Looker | Data Studio (옛 Looker Studio) | |------|------|------| | 성격 | 거버넌스 중심의 엔터프라이즈 BI 플랫폼 | 개인과 팀을 위한 시각화와 보고 도구 | | 지표 관리 | LookML 시맨틱 레이어로 중앙에서 정의 | 보고서마다 데이터 소스를 연결해 구성 | | 맞는 상황 | 전사 표준 지표, 임베디드 분석, 업무 흐름 통합 | 빠른 임시 보고서, 마케팅 대시보드 | | 요금 | 유료 | 무료 (유료 Data Studio Pro 별도) |
시험 팁: "전사적으로 일관된 지표 정의"와 "거버넌스"가 나오면 Looker, "무료로 빠르게 보고서를 만들고 공유"가 나오면 Data Studio입니다.
---
시험 핵심 정리
시험장 가기 전 마지막으로 확인할 핵심 포인트입니다.
| 구분 | 핵심 암기 사항 | |------|------| | 배치 vs 스트리밍 | 모아서 한꺼번에 vs 들어오는 즉시 계속 | | 스트리밍이 필요한 이유 | 사기 탐지, 실시간 재고, 설비 이상 감지처럼 "지금"이 중요한 결정 | | Pub/Sub | 비동기 메시징, 보내는 쪽과 받는 쪽을 분리, 이벤트 수집 | | Dataflow | 스트림 · 배치 통합 처리, Apache Beam, 완전 관리형 | | Managed Service for Apache Spark | 옛 Dataproc, 기존 Spark · Hadoop 작업, 클러스터 또는 서버리스 | | BigQuery 연속 쿼리 | SQL로 들어오는 데이터를 실시간 분석 | | 대표 파이프라인 | Pub/Sub → Dataflow → BigQuery → Looker | | 데이터 민주화 | 전문가가 아닌 사람도 데이터를 직접 이해하고 사용 | | Looker | LookML 시맨틱 레이어, 일관된 지표, 셀프서비스 BI, 임베딩 | | BigQuery + Looker | 실시간 보고서, 대시보드, 워크플로 통합 | | Data Studio | 옛 Looker Studio, 무료 시각화 · 보고 도구 |
---
다음 단계
데이터 영역을 마쳤다면 이제 그 데이터와 시스템을 지키는 방법을 정리할 차례입니다. 제로 트러스트, 암호화의 세 가지 상태, Cloud Armor와 IAP는 보안 개념과 제품 지도에서 이어집니다. 데이터베이스 선택은 데이터베이스·스토리지 선택과 마이그레이션과 함께 복습하세요.
분석 문제는 "언제 처리하나(배치·스트리밍), 무엇으로 처리하나(Dataflow·Spark), 누가 보나(Looker·Data Studio)" 세 질문으로 정리됩니다. CDL 모의고사에서 데이터 파이프라인 문제를 풀며 확인해 보세요.