DP-900 공식 출제 범위 도메인 4에는 "실시간 분석을 위한 Microsoft 클라우드 서비스 식별"이라는 항목이 있습니다. 이 항목을 준비하는 Microsoft Learn 학습 모듈은 이제 Microsoft Fabric Real-Time Intelligence와 Apache Spark Structured Streaming을 중심으로 설명합니다. Event Hubs와 Stream Analytics만 알고 시험장에 가면 Eventstream, Eventhouse, KQL 같은 용어가 나오는 문제에서 막히기 쉽습니다.
이 글은 DP-900 학습자료 중 실시간 데이터 분석 편의 후속편입니다. 배치와 스트리밍의 차이, Event Hubs·IoT Hub·Stream Analytics, 윈도우 함수는 그 글에서 다뤘습니다. 여기서는 스트림 처리 아키텍처의 공통 요소에서 시작해 Fabric Real-Time Intelligence의 구성 요소, Spark Structured Streaming과 Delta Lake, 그리고 상황별 서비스 선택 기준까지 정리합니다.
---
스트림 처리 아키텍처의 공통 요소
공항의 수하물 컨베이어를 떠올려 보세요. 가방이 체크인 카운터에서 올라오고, 컨베이어를 따라 흘러가는 동안 스캐너가 쉬지 않고 검사하고, 목적지별 출구로 나뉘어 나갑니다. 가방이 다 모일 때까지 기다리지 않고 들어오는 대로 처리하는 것이 스트림 처리입니다.
사용하는 기술이 달라도 대부분의 스트리밍 솔루션은 다음 네 단계로 이루어집니다.
이벤트가 데이터를 만듭니다. 센서 신호, 소셜 미디어 메시지, 로그 파일 한 줄처럼 무언가가 일어나 디지털 데이터가 생깁니다. 데이터가 스트리밍 소스에 수집됩니다. 단순하게는 클라우드 저장소의 폴더나 데이터베이스 테이블일 수 있고, 본격적인 솔루션에서는 이벤트 순서와 중복 없는 처리를 관리하는 큐를 씁니다. 데이터가 처리됩니다. 계속 실행되는 쿼리(영구 쿼리)가 특정 이벤트만 고르거나, 값을 뽑거나, 1분 단위 같은 시간 창으로 집계합니다. 결과가 출력(싱크)으로 나갑니다. 파일, 데이터베이스 테이블, 실시간 대시보드, 또는 다음 처리를 위한 또 다른 큐가 될 수 있습니다.
| 역할 | 자주 쓰이는 Azure 서비스 | |------|------| | 소스 (수집) | Azure Event Hubs, Azure IoT Hub, Azure Data Lake Storage Gen2, Apache Kafka | | 처리 | Fabric Real-Time Intelligence, Spark Structured Streaming, Azure Stream Analytics | | 싱크 (파일) | Azure Data Lake Storage Gen2, Microsoft OneLake, Azure Blob Storage | | 싱크 (테이블) | Azure SQL Database, Azure Databricks, Microsoft Fabric | | 싱크 (시각화·후속 처리) | Microsoft Power BI, Azure Event Hubs |
Event Hubs는 대량의 이벤트를 받아 두는 수집 서비스로, 같은 파티션 안의 이벤트는 순서대로 전달되고 최소 한 번 전달(at-least-once)을 보장합니다. IoT Hub는 비슷한 수집 서비스지만 IoT 디바이스 관리에 맞춰져 있습니다.
시험 팁: "계속 실행되면서 들어오는 이벤트를 시간 창으로 집계하는 쿼리" → 스트림 처리의 영구 쿼리. "처리 결과를 받는 쪽(파일·테이블·대시보드)" → 싱크.
---
배치와 스트리밍을 함께 쓰는 아키텍처
실제 분석 솔루션은 배치와 스트리밍 중 하나만 고르지 않는 경우가 많습니다. 도로 교통량을 예로 들면, 지금 이 순간 지나가는 차량 수는 실시간 대시보드로 보여 주고, 같은 데이터를 저장해 두었다가 지난 1년간의 교통량 추세는 배치로 분석합니다.
이렇게 두 방식을 함께 쓰는 대표적인 패턴이 람다 아키텍처입니다. 스트리밍 데이터는 실시간 계층에서 바로 처리해 대시보드로 보내고, 다른 소스의 데이터는 데이터 레이크에 모아 배치 계층에서 주기적으로 처리한 뒤 데이터 웨어하우스에 저장합니다. 실시간 처리 결과도 웨어하우스에 함께 저장해 과거 분석에 씁니다.
| 패턴 | 구조 | 특징 | |------|------|------| | 람다 아키텍처 | 실시간 계층 + 배치 계층을 따로 운영 | 실시간 결과와 정확한 과거 분석을 모두 제공, 계층이 둘이라 관리가 복잡 | | 카파 아키텍처 | 배치 계층 없이 모든 데이터를 스트림으로 처리 | 구조가 단순, 과거 데이터를 다시 처리할 때는 스트림을 재생 |
Microsoft Learn은 이 밖에 델타 아키텍처라는 이름도 언급하지만, DP-900에서 세부 구조까지 묻지는 않습니다. 실시간 분석이나 시각화가 필요 없더라도 스트리밍 기술로 데이터를 받아 저장소에 쌓아 두고 나중에 배치로 처리하는 경우도 흔합니다.
시험 팁: "실시간 처리 경로와 배치 처리 경로를 함께 두어 실시간 대시보드와 과거 분석을 모두 지원한다" → 람다 아키텍처.
---
Microsoft Fabric Real-Time Intelligence
Fabric Real-Time Intelligence는 스트리밍 데이터를 수집하고, 처리하고, 분석하는 도구 모음을 Microsoft Fabric 안에 하나로 묶어 둔 기능입니다. 이벤트 소스 연결부터 저장·쿼리, 라이브 대시보드, 조건이 맞을 때의 자동 작업까지 같은 Fabric 작업 영역 안에서 이어집니다. Azure 서비스 여러 개를 직접 엮어야 했던 일을 하나의 SaaS 경험으로 처리한다고 생각하면 됩니다.
이름에 "실시간"이 들어 있지만 데이터가 반드시 빠르고 많을 필요는 없습니다. 일정에 맞춰 돌아가는 작업이 아니라, 이벤트가 일어나는 대로 반응하는 솔루션을 만드는 도구라는 점이 핵심입니다.
Real-Time hub: 스트리밍 데이터 카탈로그
Real-Time hub는 조직 안의 스트리밍 데이터를 한곳에 모아 보여 주는 카탈로그입니다. 실행 중인 데이터 스트림, 연결할 수 있는 Microsoft 소스, Fabric 이벤트를 찾아보고 다른 팀과 공유할 수 있습니다.
Eventstream: 수집·변환·라우팅
Eventstream은 코드 없이 실시간 이벤트를 Fabric으로 가져오고, 필요하면 필터링·집계 같은 변환을 거쳐, 여러 대상으로 보내는 기능입니다. 소스로는 Azure Event Hubs, Azure IoT Hub, Azure SQL Database나 Azure Cosmos DB의 변경 데이터 캡처(CDC), Apache Kafka, Amazon Kinesis, Google Pub/Sub 등을 연결할 수 있습니다. 대상으로는 Eventhouse, Lakehouse(Delta Lake 형식으로 저장), Activator, 그리고 외부 앱을 위한 사용자 지정 엔드포인트를 지정합니다.
Eventhouse와 KQL: 이벤트 데이터 전용 데이터베이스
Eventhouse는 시간 기반 이벤트 데이터를 저장하고 분석하도록 설계된 데이터베이스로, 수십억 건의 이벤트를 몇 초 만에 쿼리할 수 있습니다. 하나의 Eventhouse 안에 여러 KQL 데이터베이스를 둘 수 있고, 정형 데이터뿐 아니라 JSON 같은 반정형 데이터와 자유 텍스트도 다룹니다. 원격 분석(텔레메트리), 로그, 시계열, IoT 데이터에 잘 맞습니다.
쿼리 언어는 KQL(Kusto Query Language)입니다. 로그와 텔레메트리를 빠르게 분석하도록 만든 언어로, Copilot이 자연어 질문을 KQL로 바꿔 주기도 합니다. Azure에서 같은 역할을 하는 독립 PaaS 서비스는 Azure Data Explorer이고, 마찬가지로 KQL을 씁니다.
실시간 대시보드와 Activator
실시간 대시보드는 들어오는 데이터를 라이브로 시각화합니다. Activator는 코드 없이 조건을 정해 두면, 데이터가 그 조건에 맞는 순간 이메일·Teams 알림을 보내거나 Power Automate 흐름, Fabric 파이프라인·노트북 같은 작업을 실행합니다. "센서 온도가 기준을 넘으면 담당자에게 알림"처럼 인사이트를 바로 행동으로 바꾸는 역할입니다.
!Fabric Real-Time Intelligence의 데이터 흐름
| 구성 요소 | 역할 | 시험에서 떠올릴 키워드 | |------|------|------| | Real-Time hub | 조직의 스트리밍 데이터 카탈로그 | 스트림 검색·공유 | | Eventstream | 노코드 수집·변환·라우팅 | 이벤트를 Fabric으로 가져오기 | | Eventhouse | 시간 기반 이벤트 데이터베이스 | KQL 데이터베이스, 로그·텔레메트리 | | KQL | Eventhouse의 쿼리 언어 | Kusto Query Language | | 실시간 대시보드 | 라이브 시각화 | 지금 이 순간의 상태 | | Activator | 조건 감지 후 자동 작업 | 알림, Power Automate, 노코드 |
시험 팁: "Fabric에서 스트리밍 이벤트를 코드 없이 수집해 변환하고 여러 대상으로 보낸다" → Eventstream. "로그·텔레메트리를 KQL로 빠르게 쿼리하는 Fabric 저장소" → Eventhouse. "데이터가 조건을 만족하면 자동으로 알림이나 작업을 실행" → Activator.
---
Spark Structured Streaming과 Delta Lake
Apache Spark는 큰 데이터를 여러 대의 컴퓨터(클러스터)에 나눠 병렬로 처리하는 엔진입니다. Azure에서는 Microsoft Fabric과 Azure Databricks에서 쓸 수 있고, Python·Scala·Java·R·SQL로 코드를 작성하며, 배치와 스트림 처리를 모두 지원합니다.
Structured Streaming의 동작 방식
Spark Structured Streaming은 Spark에 내장된 스트림 처리 라이브러리입니다. 실시간 스트림을 스프레드시트의 표처럼 다루되, 새 이벤트가 들어올 때마다 그 표에 행이 계속 늘어난다고 생각하면 이해하기 쉽습니다.
Azure Event Hubs 같은 메시지 큐, 파일 폴더, 네트워크 피드 등 스트리밍 소스에 연결합니다. 들어오는 데이터를 데이터프레임(행과 열로 된 표)으로 읽습니다. 이 표는 이벤트가 올 때마다 계속 채워집니다. 데이터프레임에 쿼리를 작성합니다. 예를 들어 분당 이벤트 수를 세거나 이동 평균을 계산합니다. 쿼리 결과를 파일, 데이터베이스, 대시보드 같은 싱크에 씁니다.
이미 Spark로 데이터를 처리하고 있고, 그 작업을 실시간 스트림까지 넓히고 싶을 때 좋은 선택입니다.
Delta Lake로 배치와 스트리밍 통합
데이터 레이크는 기본적으로 파일 모음일 뿐이라 데이터가 완전하고 일관된지 보장하는 장치가 없습니다. Delta Lake는 여기에 데이터베이스 같은 보장을 더하는 오픈소스 저장 형식입니다.
신뢰성: 변경 내용을 기록하므로 쓰기가 중간에 실패해도 데이터가 손상되지 않습니다. 스키마 강제: 정해진 구조에 맞는 데이터만 받아들입니다. 배치·스트리밍 통합: 같은 Delta 테이블이 스트리밍 결과를 받는 싱크이면서 배치 쿼리의 소스가 됩니다. 과거 데이터와 실시간 데이터를 따로 저장할 필요가 없습니다.
Fabric과 Azure Databricks의 Spark 런타임은 Delta Lake를 기본으로 지원합니다.
시험 팁: "이미 Spark를 쓰는 팀이 기존 처리를 실시간 스트림까지 확장" → Spark Structured Streaming. "스트리밍 싱크와 배치 쿼리 소스로 같은 테이블을 쓰고 싶다" → Delta Lake 테이블.
---
어떤 실시간 분석 서비스를 고를까?
Microsoft Learn이 실시간 분석 서비스로 소개하는 것은 세 가지입니다. 어느 것이 정답인지는 "어디서, 누가, 어떤 방식으로 만드느냐"로 가려집니다.
| 구분 | Fabric Real-Time Intelligence | Spark Structured Streaming | Azure Stream Analytics | |------|------|------|------| | 형태 | Fabric에 통합된 SaaS 도구 모음 | Spark의 오픈소스 라이브러리 | PaaS 스트림 처리 서비스 | | 만드는 방식 | 노코드(Eventstream, Activator) + KQL | Python·Scala·SQL 코드 | SQL과 비슷한 쿼리로 작업 정의 | | 실행 위치 | Microsoft Fabric | Azure Databricks, Microsoft Fabric | Azure (Fabric 밖) | | 잘 맞는 상황 | 수집부터 대시보드·알림까지 한곳에서 | 기존 Spark 작업 확장, 복잡한 처리 | Fabric 없이 독립형·하이브리드 스트리밍 |
수집 단계의 Event Hubs와 IoT Hub는 세 서비스 모두와 함께 쓸 수 있는 소스라는 점도 기억해 두세요. 두 서비스의 차이는 실시간 데이터 분석 글에서 표로 정리했습니다.
시험 팁: 문제에 "Microsoft Fabric 작업 영역"이 보이면 Real-Time Intelligence 쪽, "Spark"나 "노트북"이 보이면 Structured Streaming, "입력 → 쿼리 → 출력으로 구성된 스트리밍 작업"이 보이면 Azure Stream Analytics를 먼저 떠올리세요.
---
시나리오로 연습하기
시험 문제는 대부분 상황을 주고 서비스나 개념을 고르게 합니다. 먼저 답을 떠올린 뒤 오른쪽 열을 확인해 보세요.