데이터 파이프라인 아키텍처란 무엇인가요?

데이터 파이프라인 아키텍처는 데이터가 소스 시스템에서 수집, 처리, 저장되어 이를 사용하는 사람, 애플리케이션, 모델로 전달되는 방식에 대한 엔드투엔드(end-to-end) 설계입니다. "아키텍처"라는 단어는 파이프라인 자체가 아니라 청사진을 의미합니다. 이는 데이터가 어떻게 흐르고, 어디서 변환되며, 각 단계를 어떤 도구로 처리할지에 대한 선택을 포괄합니다.

좋은 아키텍처는 기성품을 고르는 것이 아니라 유스케이스에 맞춤화되어야 합니다. 실시간 이상 거래 탐지를 위해 구축된 데이터 파이프라인은 소스에서 목적지로 데이터를 이동시킨다는 점은 같지만, 매일 밤 판매 보고서를 생성하는 파이프라인과는 매우 다르게 보입니다. 이 용어 사전 페이지에서는 모든 파이프라인이 공유하는 핵심 레이어, 일반적인 단계 모델, 주요 아키텍처 패턴, 그리고 파이프라인이 확장됨에 따라 안정성을 유지하는 모범 사례를 다룹니다.

데이터 파이프라인 아키텍처는 어떻게 작동하나요?

데이터 파이프라인은 일련의 단계를 통해 데이터를 이동시키며, 각 단계는 데이터 수집, 정제, 저장, 사용 가능한 상태로 만들기 등 구체적인 작업을 수행합니다. 아키텍처는 이러한 단계들이 어떻게 연결되는지에 대한 계획입니다. 이는 각 단계에서 데이터에 어떤 일이 일어나는지, 어떤 순서로, 어떤 규칙에 따라 진행되는지를 정의합니다.

아키텍처 결정은 두 가지 수준에서 이루어집니다. 논리적 설계는 어떤 단계가 존재하고 각 단계가 무엇을 하는지 정의하는 "무엇을(what)"에 해당합니다. 물리적 설계는 각 단계를 실행하는 구체적인 도구와 인프라를 정의하는 "어떻게(how)"에 해당합니다. 오케스트레이션(각 단계의 자동 예약 및 조정)과 모니터링은 단일 단계에만 속하지 않으며, 전체 파이프라인에 걸쳐 실행됩니다. 현대적인 플랫폼은 과거의 경계를 허물었습니다. Databricks는 Lakeflow를 통해 배치 및 스트리밍 파이프라인을 단일 기반으로 통합하므로, 팀이 두 개의 병렬 시스템을 구축하고 유지 관리할 필요가 없습니다.

데이터 파이프라인의 핵심 레이어

팀이 어떤 패턴을 선택하든 모든 데이터 파이프라인은 동일한 4개의 레이어를 기반으로 구축됩니다. 각 레이어는 데이터에 대한 서로 다른 질문에 답합니다. 즉, 데이터가 어떻게 들어오는지, 어떻게 유용해지는지, 어디에 저장되는지, 누가 소비하는지입니다.

수집

수집은 데이터베이스, 애플리케이션, API, 클라우드 스토리지의 파일, 이벤트 스트림, 센서 등의 소스 시스템에서 파이프라인으로 데이터를 가져옵니다. 데이터 수집에는 두 가지 방식이 있습니다. 배치 수집은 매시간 또는 매일 밤과 같이 일정에 따라 데이터를 가져옵니다. 스트리밍 수집은 이벤트가 발생할 때마다 지속적으로 데이터를 캡처합니다. 또한 많은 파이프라인이 소스 데이터베이스의 행 수준 변경 사항을 추적하는 방법인 CDC(change data capture)를 사용하여, 모든 데이터를 다시 로드하는 대신 새로 추가되거나 업데이트된 데이터만 이동시킵니다.

처리 및 변환

이 레이어는 원시 데이터(raw data)를 정제, 재구성, 보강하여 사용할 준비를 하는 곳입니다. 일반적인 작업에는 누락된 값 처리, 형식 표준화, 데이터 세트 결합, 비즈니스 로직 적용 등이 포함되며, 이는 ETL의 핵심 작업과 동일합니다. 처리는 수집과 동일하게 분류됩니다. 배치 처리는 대량의 데이터를 한 번에 처리하는 반면, 스트림 처리는 레코드가 도착하는 대로 하나씩 또는 아주 작은 마이크로 배치 단위로 처리합니다.

저장

저장은 처리된 데이터가 쿼리되거나 분석되거나 모델에 입력될 수 있도록 도달하는 곳입니다. 대상은 일반적으로 데이터 레이크, 데이터 웨어하우스 또는 이 둘의 장점을 결합한 단일 시스템인 레이크하우스입니다. 위치만큼이나 형식도 중요합니다. Lakehouse Storage 및 Apache Iceberg와 같은 오픈 형식은 여러 도구가 시스템 간에 데이터를 복사하지 않고도 동일한 데이터를 읽을 수 있도록 합니다. Delta Lake는 또한 ACID 트랜잭션(쓰기가 완전히 성공하거나 완전히 실패하도록 보장하여 데이터 손상을 방지함) 및 타임 트래블(테이블의 이전 버전을 쿼리하는 기능)과 같은 안정성 기능을 추가합니다.

서빙 및 소비

마지막 레이어는 준비된 데이터를 필요로 하는 사람과 시스템에 전달합니다. 여기에는 SQL 쿼리를 실행하는 분석가, 대시보드에서 작업하는 비즈니스 사용자, 모델을 학습시키는 데이터 과학자, API를 호출하는 애플리케이션 등이 포함됩니다. 대상은 BI 도구부터 ML 플랫폼, 운영 시스템에 이르기까지 다양하며, 분석 워크로드의 중심에는 종종 데이터 웨어하우스가 위치합니다. 네 가지 레이어 전체에서 오케스트레이션과 관찰 가능성(observability)이 연결 작업을 수행합니다. 즉, 작업을 예약하고, 데이터 품질을 추적하며, 문제가 발생했을 때 알림을 보냅니다.

데이터 파이프라인에는 몇 개의 단계가 있나요? (3단계 vs. 4단계 vs. 5단계)

소스마다 데이터 파이프라인을 3단계, 4단계 또는 5단계로 설명하여 혼란을 야기하는 경우가 많습니다. 실제로는 더 간단합니다. 세 가지 모델 모두 동일한 기본 작업을 서로 다른 수준의 세부 정보로 설명합니다.

단계의 수는 분류상의 선택일 뿐입니다. 파이프라인이 수행하는 작업은 동일합니다.

일반적인 데이터 파이프라인 아키텍처 패턴

아키텍처 패턴은 팀이 파이프라인을 구축할 때 선택할 수 있는 정립된 설계 방식입니다. 적합한 패턴은 지연 시간 요구 사항, 데이터 볼륨 및 다운스트림에서 데이터가 어떻게 사용되는지에 따라 달라집니다.

배치 아키텍처

배치 아키텍처는 매시간, 매일 밤 또는 매주와 같이 예정된 청크 단위로 데이터를 처리합니다. 이는 보고서 작성, 이력 분석, ML 학습 데이터 및 몇 분 또는 몇 시간의 지연이 허용되는 모든 유스케이스에 적합합니다. 배치 파이프라인은 스트리밍 파이프라인에 비해 구축이 더 간단하고 운영 비용이 저렴하며 디버깅이 쉽습니다. 단점은 최신성(freshness)입니다. 몇 초 전에 발생한 상황에 따라 결정을 내려야 하는 경우 배치 방식은 이를 감당할 수 없습니다.

스트리밍 아키텍처

스트리밍 아키텍처는 데이터가 생성되는 대로 레코드 단위로 지속적으로 처리합니다. 이는 이상 거래 탐지, 실시간 개인화, IoT 모니터링과 같이 1분 미만의 빠른 응답이 중요한 유스케이스에 사용됩니다. 단점은 비용입니다. 스트리밍 파이프라인은 항상 켜져 있는 인프라가 필요하기 때문에 일반적으로 배치 파이프라인보다 실행 및 운영 비용이 더 많이 듭니다.

Lambda 아키텍처

Lambda 아키텍처는 두 개의 병렬 경로를 실행합니다. 배치 경로는 정확한 이력 데이터를 제공하고, 스트리밍 경로는 빠르고 최신의 데이터를 제공하며, 서빙 레이어에서 결과를 병합합니다. 이 설계는 효과적이지만 잘 알려진 단점이 있습니다. 두 개의 파이프라인을 유지 관리한다는 것은 코드와 로직의 중복, 그리고 두 배의 운영 부담을 의미합니다.

Kappa 아키텍처

Kappa 아키텍처는 모든 작업에 단일 스트리밍 파이프라인을 사용하여 Lambda를 단순화합니다. 이력 분석이 필요한 경우 스트림이 처음부터 다시 재생됩니다. Kappa는 두 개의 병렬 시스템을 유지 관리하는 비용 없이 스트리밍 수준의 최신성을 원하는 팀에 적합합니다.

메달리온 아키텍처(레이크하우스 패턴)

메달리온 아키텍처는 레이크하우스 플랫폼에서 널리 사용되는 패턴으로, 데이터를 브론즈(Bronze, 수집된 그대로의 원시 데이터), 실버(Silver, 정제 및 정합성 검증 완료), 골드(Gold, 정제되어 비즈니스에 바로 사용 가능)의 세 가지 품질 계층으로 구성합니다. Databricks 문서에 명시된 것처럼, "메달리온 아키텍처는 브론즈, 실버, 골드의 세 가지 레이어를 사용하며, 각 레이어는 파이프라인에서 고유한 목적을 수행합니다." 각 계층은 자체 파이프라인으로 실행될 수 있으므로 문제가 단일 레이어에 격리되어 예약, 모니터링 및 문제 해결이 더 쉬워집니다.

ETL vs. ELT: 변환 순서가 아키텍처를 형성하는 방식

ETL과 ELT는 데이터가 변환되는 시점에서 차이가 있습니다. ETL(extract, transform, load)은 데이터를 저장소에 로드하기 전에 변환합니다. ELT(extract, load, transform)는 먼저 원시 데이터를 로드한 다음 목적지 내부에서 변환합니다. Databricks, Snowflake, BigQuery와 같은 현대적인 클라우드 플랫폼은 클라우드 스토리지와 컴퓨팅이 제자리에서 데이터를 변환할 수 있을 만큼 저렴하고 유연해졌기 때문에 ELT를 지배적인 패턴으로 만들었습니다. 더 자세한 비교는 ETL vs. ELT를 참조하세요.

ETL은 데이터 파이프라인과 동일한가요?

아닙니다. ETL은 데이터 파이프라인의 한 종류이지만, 모든 데이터 파이프라인이 ETL인 것은 아닙니다. 데이터 파이프라인은 데이터를 한 곳에서 다른 곳으로 이동시키는 모든 시스템을 아우르는 광범위한 범주입니다. ETL은 이 범주 내의 특정 접근 방식으로, 데이터가 저장소에 저장되기 전에 변환하는 과정을 거치는 것이 특징입니다. 파이프라인은 ELT, 스트리밍, 복제 전용(변환 없이 데이터만 이동), 또는 역ETL(웨어하우스 데이터를 다시 운영 시스템으로 전송) 방식이 될 수도 있습니다.

데이터 파이프라인 아키텍처를 위한 모범 사례

확장 가능한 파이프라인과 쉽게 망가지는 파이프라인을 결정짓는 10가지 설계 원칙은 다음과 같습니다.

1. 수집과 변환 분리하기. 원시 데이터 수집과 데이터 정제를 서로 다른 단계로 분리하여 한 단계의 문제가 다른 단계로 전이되지 않도록 하세요.
2. 멱등성을 고려한 설계. 중복 레코드를 생성하거나 결과를 손상시키지 않고 안전하게 재실행할 수 있도록 파이프라인을 설계해야 합니다. 이는 장애 처리 및 백필(backfill) 작업에 매우 중요합니다.
3. 데이터 품질 검사 내장하기. 강력한 데이터 품질 검사를 통해 각 단계에서 스키마, 값의 범위, null 개수, 최신성을 검증하고, 문제가 발생했을 때 잘못된 데이터가 다운스트림으로 흘러가지 않도록 즉시 명확하게 오류를 알려야 합니다.
4. 스키마 드리프트에 대비하기. 소스 시스템은 언제든 변경될 수 있습니다. 파이프라인은 열이 추가, 삭제 또는 이름 변경될 때 이를 감지하고, 오류로 중단되는 대신 유연하게 대처할 수 있어야 합니다.
5. 오픈 스토리지 포맷 사용하기. Delta Lake 및 Apache Iceberg와 같은 포맷은 특정 벤더에 종속되는 현상(lock-in)을 방지하고, 여러 도구에서 복사본 없이 동일한 데이터를 읽을 수 있도록 지원합니다.
6. 파이프라인 레이어 분리하기. 메달리온 아키텍처 단계(Bronze, Silver, Gold)를 별도의 파이프라인으로 분리하면 각 단계를 독립적으로 예약, 모니터링 및 트러블슈팅하기가 훨씬 쉬워집니다.
7. 모든 것을 버전 관리하기. 파이프라인 코드와 구성을 Git에 저장하여 변경 사항을 검토하고 추적하며, 필요한 경우 이전 상태로 되돌릴 수 있도록 하세요.
8. 거버넌스를 최우선 과제로 취급하기. 마지막에 거버넌스를 억지로 끼워 맞추기보다는, Unity Catalog와 같은 도구를 사용하여 모든 단계에서 일관된 권한 부여, 리니지 추적 및 감사 제어를 적용하세요.
9. 스트리밍과 배치 적절히 선택하기. 데이터의 최신성이 정말로 중요한 경우에만 스트리밍을 사용하고, 그 외에는 비용 절감을 위해 배치를 기본값으로 설정하세요.
10. 엔드투엔드 모니터링 수행하기. 데이터 최신성, 볼륨, 품질 및 파이프라인 실행 시간을 추적하여 다운스트림 사용자가 알아차리기 전에 문제를 먼저 파악하세요.

데이터 파이프라인 아키텍처가 중요한 이유

파이프라인 아키텍처는 팀이 데이터를 신뢰할 수 있는지, 최신 정보에 기반해 의사 결정을 내릴 수 있는지, 그리고 AI 및 ML 프로젝트가 프로토타입에서 프로덕션 단계로 성공적으로 전환될 수 있는지를 결정합니다. 이는 가치가 지속적으로 누적되는 데이터 플랫폼과 끊임없이 지원 요청 티켓을 생성하는 플랫폼의 차이와 같습니다.

취약한 아키텍처는 오래된 대시보드, 서로 충돌하는 메트릭, 실패한 ML 배포, 그리고 새로운 구축 작업보다 문제 해결(소방 작업)에 더 많은 시간을 허비하는 엔지니어 등 실질적인 비용을 초래합니다. 현대적인 레이크하우스 접근 방식은 이러한 근본적인 원인을 해결합니다. 배치와 스트리밍, 분석과 AI, 그리고 거버넌스를 Databricks Platform과 같은 단일 플랫폼으로 통합함으로써, 기존 아키텍처를 무너뜨리던 시스템 간의 불안정한 데이터 인계 과정을 제거할 수 있습니다.

Databricks 기반의 데이터 파이프라인 아키텍처

Databricks는 파이프라인 아키텍처의 모든 레이어를 단일 플랫폼에서 제공합니다. Lakeflow Connect는 데이터베이스, SaaS 애플리케이션, 파일 소스 및 이벤트 스트림으로부터의 데이터 수집을 처리합니다. Lakeflow Spark Declarative Pipelines는 데이터 품질 검사가 내장된 배치 및 스트리밍 ETL 파이프라인을 구축하며, Lakeflow Jobs는 플랫폼 전반에서 파이프라인 실행을 오케스트레이션하고 예약합니다. 그 하부에서는 Delta Lake가 ACID 트랜잭션 및 타임 트래블과 같은 안정성 기능과 함께 오픈 스토리지 포맷을 제공하며, Unity Catalog는 모든 단계에 걸쳐 거버넌스, 리니지 및 액세스 제어를 적용합니다.

배치 및 스트리밍 파이프라인이 동일한 엔진에서 실행되고 동일한 스토리지에 기록되므로, 팀은 람다(Lambda) 스타일의 병렬 시스템을 유지 관리할 필요가 없습니다. 단 하나의 파이프라인 정의만으로 야간 보고서와 실시간 대시보드를 모두 지원할 수 있습니다.

자주 묻는 질문

데이터 파이프라인 아키텍처를 쉽게 설명하면 무엇인가요?

데이터가 생성된 곳에서 유용하게 사용될 곳까지 어떻게 이동하는지에 대한 계획입니다. 이 계획에는 데이터의 수집 방법, 정제 및 준비 방법, 저장 위치, 그리고 이를 필요로 하는 사람과 애플리케이션에 전달하는 방법이 포함됩니다.

람다(Lambda) 아키텍처와 카파(Kappa) 아키텍처의 차이점은 무엇인가요?

람다 아키텍처는 배치와 스트리밍이라는 두 개의 병렬 파이프라인을 실행하고 서빙 레이어에서 그 결과를 병합합니다. 카파 아키텍처는 모든 작업에 단일 스트리밍 파이프라인을 사용하며, 과거 데이터 분석이 필요할 때 스트림을 재실행(replay)합니다. 카파는 운영이 더 간단한 반면, 람다는 배치와 스트리밍 경로가 개별적으로 발전해 온 환경에서 여전히 활용되고 있습니다.

배치 파이프라인과 스트리밍 파이프라인은 각각 언제 사용해야 하나요?

이상 거래 탐지, 실시간 개인화, 장비 모니터링과 같이 데이터의 가치가 수초 또는 수분 내에 급격히 떨어지는 경우 스트리밍을 사용하세요. 보고서 작성, 과거 데이터 분석, ML 학습 데이터 등 그 외의 모든 작업에는 배치를 사용하세요. 배치는 더 간단하고 비용이 저렴하므로, 실시간 데이터가 반드시 필요한 사용 사례임이 입증되기 전까지는 배치를 기본값으로 설정하는 것이 합리적입니다.

논리적 파이프라인 아키텍처와 물리적 파이프라인 아키텍처의 차이점은 무엇인가요?

논리적 아키텍처는 도구와 상관없이 파이프라인의 단계와 각 단계가 수행하는 작업을 정의합니다. 물리적 아키텍처는 이러한 단계들을 특정 기술 및 인프라에 매핑합니다. 일반적으로 팀은 논리적 설계를 먼저 확정한 다음, 이를 구현할 플랫폼을 선택합니다.

작업에 적합한 아키텍처 선택하기

데이터 파이프라인 아키텍처는 데이터가 이동하고 유용해지는 과정의 배후에 있는 설계입니다. 올바른 아키텍처는 야간 매출 보고서든 밀리초 단위로 실행되는 이상 거래 탐지든, 당면한 특정 작업에 맞춰 최신성, 비용, 안정성의 균형을 맞추는 아키텍처입니다.

Databricks가 단일 플랫폼에서 배치 및 스트리밍 파이프라인, 스토리지, 거버넌스를 어떻게 통합하는지 확인해 보세요.

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)