견고한 데이터 엔지니어링

데이터 엔지니어링이란, 조직의 데이터가 단순히 저장되는 수준을 넘어 분석과 머신러닝 같은 실제 비즈니스 활용이 가능하도록 준비하는 과정이라고 정의할 수 있습니다. 실제 현업 상황을 가정해보면, 기업은 수많은 원시 데이터를 수집하지만, 이 데이터가 정제되지 않으면 분석가나 데이터 과학자가 제대로 활용할 수 없습니다. 그래서 데이터 엔지니어는 데이터가 생성되는 시점부터 수집, 변환, 저장, 그리고 최종적으로 서빙까지 이어지는 엔드 투 엔드 데이터 파이프라인을 책임집니다.

또한 데이터 엔지니어링은 단순한 ETL 작업이 아니라 보안, 거버넌스, 데이터옵스, 아키텍처 설계, 오케스트레이션, 소프트웨어 엔지니어링까지 포괄합니다. 즉, 데이터 엔지니어는 조직의 데이터 인프라를 안정적으로 운영하면서도, 분석가와 과학자가 바로 활용 가능한 고품질 데이터 환경을 제공하는 역할을 합니다.

추가적으로 말씀드리자면, 데이터 엔지니어링은 오늘날 클라우드 환경, 대규모 분산 시스템, 스트리밍 처리 등과 맞물려 점점 더 고도화되고 있습니다. 따라서 단순한 데이터 준비를 넘어서 확장성과 신뢰성을 갖춘 데이터 플랫폼 구축이 데이터 엔지니어링의 핵심이라고 생각합니다.

💬 데이터 엔지니어의 진화 과정

데이터 엔지니어의 진화는 크게 데이터 웨어하우스 시대 → 빅데이터 시대 → 현대 데이터 엔지니어링으로 구분할 수 있습니다. 각 시기는 데이터 기술 패러다임의 변화를 반영하며, 데이터 엔지니어의 역할 역시 점점 더 고도화되어 왔습니다.

먼저 1980년대부터 2000년대 초반까지는 데이터 웨어하우스 시대로, 오라클(Oracle), 인포매티카(Informatica), 테라데이터(Teradata), MPP 데이터베이스 같은 전통적인 DW 기술이 중심이었습니다. 이 시기에는 주로 BI 개발자와 ETL 전문가가 활동했으며, 정형 데이터를 대상으로 정기적 배치 처리를 통해 리포트를 생성하는 것이 핵심이었습니다.

이후 2000년대 중반부터 데이터의 폭증과 함께 구글의 GFS 및 맵리듀스(MapReduce) 논문이 발표되고, 이를 기반으로 한 아파치 하둡(Apache Hadoop)이 오픈소스로 등장하면서빅데이터 엔지니어링 시대가 열렸습니다. 이 시기에는 HDFS, 하이브(Hive), 스파크(Spark) 같은 분산 처리 프레임워크가 등장하며, 대규모 데이터 병렬 처리와 확장성이 데이터 엔지니어링의 핵심 주제가 되었습니다.

2010년대에 들어서는 배치 중심의 워크플로우를 넘어 실시간 스트리밍 처리로 패러다임이 이동했습니다. 이를 통해 카프카(Kafka), 스톰(Storm), 플링크(Flink)와 같은 이벤트 기반 기술이 각광받았고, 데이터 엔지니어는 단순한 적재·변환을 넘어서 실시간 데이터 파이프라인 구축 및 장애 대응 능력을 요구받게 되었습니다.

마지막으로 2020년대의 현대 데이터 엔지니어링은 저수준 하둡 클러스터 운영보다 클라우드 네이티브 아키텍처와데이터옵스(DataOps), 그리고 GDPR/CCPA 기반 데이터 거버넌스를 중심으로 발전하고 있습니다. 즉, 데이터 엔지니어는 이제 인프라 구축보다는 데이터 수명주기 전체를 관리하고, 데이터 품질·보안·비즈니스 가치 극대화에 초점을 맞추는 역할로 진화했습니다.

💬 데이터 엔지니어링의 기술과 활동

데이터 엔지니어의 핵심 활동은 데이터 파이프라인의 설계와 운영을 통해 안정적이고 활용 가능한 데이터를 제공하는 것입니다. 조직이 원시 데이터를 다양한 소스에서 수집했다고 할 때, 데이터 엔지니어는 업스트림으로부터 받은 데이터를 정제·변환하여 분석가나 머신러닝 엔지니어 같은 다운스트림 직무가 즉시 활용할 수 있는 형태로 전달해야 합니다.

이를 위해 데이터 엔지니어는 데이터 수명 주기 관리(수집, 저장, 변환, 서빙)의 전 과정에 관여하며, 동시에 보안·데이터 거버넌스·확장성을 고려해야 합니다.

1️⃣ 데이터 아키텍처 설계를 통해 비용 효율적이면서도 확장 가능한 인프라를 구축하고,

2️⃣ 데이터옵스(DataOps)와 오케스트레이션을 적용하여 파이프라인의 자동화·모니터링·배포를 수행합니다.

3️⃣ 데이터 품질을 확보하기 위해 데이터 카탈로그·계보(Lineage) 관리·메타데이터 시스템을 활용하며,

4️⃣ 내부 BI·ML 지원을 위한 API 및 서빙 계층을 최적화합니다.

또한 데이터 엔지니어는 A형(추상화 중심)과 B형(구축 중심) 역할 모두 수행할 수 있으며, 상황에 따라 SaaS 기반 관리형 서비스를 빠르게 도입하거나 맞춤형 데이터 플랫폼을 직접 개발하기도 합니다.

더불어, 내부 이해관계자(데이터 분석가·데이터 과학자)와 외부 시스템(소셜 미디어, IoT 등) 모두를 고려해 데이터 소비자와 생산자를 잇는 허브역할을 수행하기도 합니다.

결국 데이터 엔지니어의 활동은 단순한 파이프라인 구축을 넘어, 조직의 데이터 성숙도를 끌어올리고 데이터 기반 의사결정을 가능하게 만드는 전략적 실행이라 할 수 있습니다.

데이터 생성은 데이터 엔지니어링 파이프라인의 시작점으로, 원천 시스템에서 최초로 데이터가 만들어지는 과정을 의미합니다. 기업 환경을 가정해보면, 데이터는 IoT 센서에서 실시간 이벤트로 발생하거나, 애플리케이션 로그와 메시지 큐를 통해 스트리밍되기도 하며, 트랜잭션 DB에 정형 데이터로 축적되기도 합니다. 따라서 데이터 엔지니어는 단순히 데이터가 존재하는 사실을 아는 것을 넘어, 데이터가 어떤 속도와 구조로 생성되는지, 품질 이슈 가능성이 있는지 이해 하는 것이 중요합니다. 이러한 이해는 이후의 수집, 저장, 변환 단계에서 설계 의사결정의 핵심 기준이 됩니다.

예를 들어, IoT 센서 데이터처럼 초당 수천 건의 이벤트가 발생하는 경우에는 스트리밍 파이프라인과 실시간 처리 가 필요하지만, ERP 시스템의 트랜잭션 데이터처럼 하루 단위로 집계되는 경우에는 배치 수집만으로 충분 할 수 있습니다. 따라서 데이터 생성 단계에서 발생원과 특성을 명확히 정의하는 것은 전체 데이터 파이프라인의 안정성과 품질 보장 에 핵심적인 역할을 합니다.

👉 키워드 → 원천시스템 / 데이터속성

💬 데이터 엔지니어링의 수명 주기: “데이터 저장”

데이터 저장은 생성된 데이터를 안정적으로 보관하고, 향후 분석과 처리 과정에서 효율적으로 활용할 수 있도록 관리하는 단계입니다. 예를 들어, 금융 서비스 기업에서는 실시간 결제 데이터를 빠르게 조회하기 위해 데이터 웨어하우스 를 사용하고, 장기 로그 데이터는 객체 스토리지 에 적재하여 비용 효율성을 확보할 수 있습니다.

데이터 저장에서 중요한 근거는 선택한 스토리지 시스템이 읽기·쓰기 성능 요구사항을 충족하고, 확장성에 대응하며, 다운스트림 프로세스에서 병목을 발생시키지 않는가 에 있습니다. 또한 데이터의 온도(Hot, Warm, Cold)를 고려하여 자주 쓰이는 데이터는 고성능 스토리지에, 잘 쓰이지 않는 데이터는 아카이브 스토리지에 배치하는 것이 중요합니다.

추가적으로 스키마 진화, 메타데이터 관리, 데이터 계보 추적 은 단순 저장을 넘어 데이터 거버넌스와 규제 준수를 가능하게 하며, 이는 장기적으로 데이터 플랫폼의 신뢰성과 활용성 을 결정짓는 요소가 됩니다. 따라서 데이터 저장 단계는 단순한 보관이 아니라, 아키텍처 전체의 성능과 거버넌스 수준을 좌우하는 전략적 선택 이라고 할 수 있습니다.

👉 키워드 → 스토리지 / 성능 / 확장성 / Hot,Cold Data

💬 데이터 엔지니어링의 수명 주기: “데이터 수집”

데이터 수집은 원천 시스템에서 발생한 데이터를 안정적이고 효율적으로 취합하여 다운스트림 시스템에서 활용할 수 있도록 전달하는 단계입니다. 예를 들어, 실시간 금융 거래 모니터링 시스템에서는 스트리밍 수집 을 통해 밀리초 단위로 이벤트를 처리하고, 반대로 리포트용 고객 데이터 분석에서는 하루 단위 배치 수집 을 활용할 수 있습니다.

데이터 수집의 핵심 근거는 수집 방식(배치 vs 스트리밍), 수집 모델(푸시 vs 풀), 그리고 CDC 와 같은 기법을 어떤 아키텍처에 적용하느냐에 따라 데이터 신뢰성, 지연 시간, 운영 안정성 이 달라진다는 점입니다. 또한 수집된 데이터가 다운스트림 시스템의 처리 속도와 포맷 요구사항을 충족해야 하며, 장애 상황에서도 안정적으로 전달될 수 있는 내결함성 을 갖추는 것이 중요합니다.

현대 데이터 엔지니어링에서는 카프카(Kafka), 플링크(Flink), 스파크 스트리밍 과 같은 분산 스트리밍 플랫폼이 핵심 도구로 자리 잡고 있으며, 관리형 서비스(Pub/Sub, Kinesis) 를 통해 운영 복잡도를 줄이는 전략도 활용됩니다. 따라서 데이터 수집은 단순 데이터 이동이 아니라, 전체 데이터 파이프라인의 신뢰성과 실시간성을 결정짓는 핵심 단계 라고 할 수 있습니다.

👉 키워드 → 배치 / 스트리밍 / 푸시 / 풀 / CDC / 카프카

💬 데이터 엔지니어링의 수명 주기: “데이터 변환”

데이터 변환은 원천 데이터를 분석, 머신러닝, 비즈니스 활용에 적합한 형태로 가공하고 정제하는 과정입니다. 예를 들어, 이커머스 기업에서 고객 로그 데이터를 수집했을 때, 이를 단순한 JSON 원시 로그로는 분석하기 어렵기 때문에 정규화된 테이블 구조 로 변환하고, 불필요한 컬럼을 제거하거나 파생 컬럼 생성 과 같은 과정을 거칠 수 있습니다.

데이터 변환의 핵심 근거는 비즈니스 규칙과 분석 목적에 맞춰 데이터를 일관성 있게 가공 함으로써, 다운스트림 단계에서 즉시 활용 가능하도록 만드는 것입니다. 또한 변환 로직은 단순하고 모듈화 되어야 유지보수성이 높으며, 불필요한 연산을 줄여 성능과 비용 효율성 을 확보할 수 있습니다.

추가적으로, 데이터 변환은 배치 기반 ETL뿐만 아니라 실시간 스트리밍 파이프라인 에서도 적용되며, Spark, Flink, dbt 같은 도구를 통해 자동화되고 관리됩니다. 나아가 스키마 진화와 데이터 품질 검증 을 통합하면 변환 단계는 단순한 가공을 넘어 데이터 신뢰성 보장 의 핵심 역할을 합니다.

👉 키워드 → ETL / Spark / Flink / dbt

💬 데이터 엔지니어링의 수명 주기: “데이터 서빙”

데이터 서빙은 데이터 엔지니어링 수명 주기의 마지막 단계로, 수집되고 저장된 데이터를 일관성 있고 유용한 구조로 변환한 뒤 실제 비즈니스 현장에서 활용할 수 있도록 제공하는 과정입니다. 이 단계의 핵심은 단순히 데이터를 보관하는 데 그치지 않고, 다양한 소비자가 데이터를 실제로 사용하여 가치로 전환하도록 만드는 것 에 있습니다.

기업은 이 단계에서 여러 형태의 서빙 방식을 사용합니다. 첫째, 비즈니스 인텔리전스(BI) 를 통해 경영진과 분석가가 기업의 과거와 현재 상황을 이해하고 전략을 수립할 수 있습니다. BI는 원시 데이터를 비즈니스 로직으로 가공하고, 리포트나 대시보드로 시각화하여 조직 전반에 배포합니다.

둘째, 운영 분석 은 재고나 웹 서비스 상태 같은 실시간 데이터를 모니터링하며, 사용자가 즉시 실행할 수 있는 행동을 촉진합니다.

셋째, 임베디드 분석 은 고객에게 직접 데이터를 제공하는 방식으로, 대규모 사용자에게 각자의 데이터만 안전하게 보여주는 것이 핵심입니다. 이 과정에서는 보안과 접근 제어 가 매우 중요합니다.

넷째, 머신러닝 서빙 에서는 데이터 과학자와 ML 엔지니어가 모델 학습과 예측에 활용할 수 있도록 품질 높은 데이터를 제공하는 것이 중요하며, 데이터셋이 실제 상황을 공정하게 반영하는지 와 편향 여부 가 검토 포인트가 됩니다.

특히 최근 데이터 서빙에서 점점 더 중요해지고 있는 개념은 역ETL 입니다. 역ETL은 데이터 웨어하우스나 데이터 레이크에서 처리된 분석 결과를 원천 시스템이나 SaaS 플랫폼으로 다시 공급하는 과정을 의미합니다. 예를 들어, 기업이 웨어하우스에서 고객 세분화 모델을 만든 뒤 CRM이나 CDP로 전달하여 영업팀이 마케팅 캠페인에 활용하거나, 광고 플랫폼에 맞춤형 데이터를 푸시하여 직접 광고 집행에 반영하는 경우가 있습니다. 역ETL은 단순 전송이 아니라 분석된 데이터를 비즈니스 프로세스 속으로 통합 하는 핵심 작업이며, SaaS 중심 현대 기업 환경에서 필수적인 요소입니다.

👉 키워드 → BI / 운영분석 / 임베디드분석 / ML서빙 / 역ETL / 데이터가치

💬 데이터 엔지니어링 수명 주기의 드러나지 않는 주요 요소

1️⃣ 보안 (Security)

데이터 엔지니어링에서 보안은 단순히 접근을 차단하는 것을 넘어 데이터를 안전하게 저장하고 전송하며, 사용자의 권한을 최소화하는 원칙을 실천하는 것을 의미합니다. 즉, 시스템이 맡은 역할을 수행하는 데 필요한 최소한의 데이터와 자원만 접근할 수 있도록 제한해야 합니다.

이를 위해 암호화(Encryption), 토큰화(Tokenization), 데이터 마스킹(Data Masking), 난독화(Obfuscation) 등의 기법을 적용하여 데이터가 이동 중이든 저장 중이든 원치 않는 가시성으로부터 보호합니다.

또한 IAM(Identity and Access Management), 네트워크 보안, 암호 정책, 역할 기반 접근 제어(RBAC) 같은 체계적 보안 모델이 필요합니다. 결국 보안은 단순한 기술적 장치가 아니라 데이터 엔지니어가 기본적으로 이해하고 실천해야 할 필수 문화이자 원칙입니다.

2️⃣ 데이터 관리 (Data Management)

데이터 관리는 데이터 자산이 전 생애주기 동안 가치 있게 활용되고 보호되도록 계획·감독하는 활동입니다. 단순 저장과 변환만으로는 품질과 신뢰를 보장할 수 없으므로, 이를 위해 거버넌스, 품질 관리, 보안, 규제 준수가 필요합니다.

핵심은 데이터 거버넌스(Data Governance)입니다. 이는 발견 가능성, 보안, 책임성을 확보하는 것으로, 메타데이터 관리와 마스터 데이터 관리(MDM)가 대표적입니다. 메타데이터는 비즈니스, 기술, 운영, 참조 메타데이터로 구분되며, 데이터 검색과 제어의 기반이 됩니다.

MDM은 고객, 제품 같은 핵심 엔터티를 조직 전반에서 일관되게 관리하여 ‘골든 레코드’를 보장합니다. 또한 데이터 품질 관리(Data Quality Management)를 통해 정확성·완전성·적시성을 검증하고,데이터 계보(Lineage)를 통해 생성·변환·활용 과정을 추적함으로써 오류 분석이나 규제 대응에 활용할 수 있습니다.

현대 환경에서는 다양한 SaaS·클라우드 간 API 기반 연동을 통해 Salesforce → S3 → Snowflake → Spark 와 같은 유연한 데이터 흐름을 구축하는 것도 중요합니다. 데이터는 단순히 저장되는 것이 아니라 연결되고 흘러야 합니다.

이와 더불어 수명 주기 관리(Lifecycle Management)와 윤리·보호(Ethics & Protection)도 필수입니다. 데이터는 수집·보존·파기까지 관리되어야 하며, GDPR·CCPA 같은 규제를 준수해야 합니다. 특히 PII(개인 식별 정보) 같은 민감 데이터는 암호화나 마스킹으로 보호해야 하며, 데이터 편향 여부 또한 검토 대상입니다.

결론적으로 데이터 관리는 거버넌스, 품질, 메타데이터, 계보, 통합, 수명 주기, 윤리와 보안을 종합적으로 다루는 활동으로, 조직이 데이터를 신뢰하고 비즈니스 가치를 창출할 수 있게 만드는 기반이라 할 수 있습니다.

3️⃣ 데이터옵스 (DataOps)

데이터옵스는 애자일(Agile) 방법론, 데브옵스(DevOps), 통계적 공정관리(SPC) 의 모범 사례를 데이터 관리에 적용한 접근법입니다. 소프트웨어 제품이 기능과 서비스를 제공하듯, 데이터 제품은 의사결정과 모델링에 필요한 정확한 비즈니스 로직과 지표를 제공합니다.

데이터옵스의 핵심은 자동화(Automation), 관찰 가능성(Observability), 사고 대응(Incident Response)입니다. 자동화를 통해 데이터 변환 및 파이프라인의 일관성과 신뢰성을 확보하고, CI/CD, 코드 기반 워크플로, 버전 관리 등을 통합합니다.

복잡한 파이프라인 환경에서는 Airflow, Dagster 같은 오케스트레이션 도구가 필요하며, 이는 업스트림 데이터 준비 여부를 인식해 종속 작업을 자동 실행합니다. 이를 통해 안정성과 효율성이 크게 향상됩니다.

또 다른 핵심은 DODD(Data Observability Driven Development)입니다. TDD(Test Driven Development)처럼 데이터 가치 사슬 전 단계에서 데이터를 가시화하고, 변경 사항을 추적하며, 문제를 사전에 감지할 수 있도록 설계하는 방법론입니다.

데이터옵스의 성숙한 조직은 이러한 자동화·관찰 가능성·사고 대응 체계를 바탕으로 데이터 품질 저하, 시스템 오류, 모델 드리프트 같은 문제를 사전에 최소화합니다.

4️⃣ 데이터 아키텍처 (Data Architecture)

데이터 아키텍처란 원천 시스템에서 데이터 수집, 저장, 변환, 서빙까지 데이터가 이동하고 활용되는 전체 구조를 설계하고 최적화하는 과정을 의미합니다. 여기에는 성능, 비용, 확장성, 유지보수성을 균형 있게 고려한 설계가 필요합니다.

중요한 것은 기술 중심이 아니라 비즈니스 가치 중심의 설계라는 점입니다. 처리 속도와 비용, 데이터 품질 사이의 트레이드오프를 이해하고, 새로운 요구사항에도 유연하게 대응할 수 있어야 합니다.

데이터 엔지니어는 데이터 아키텍트가 설계한 구조를 구현하면서 실무에서 발생한 문제와 개선점을 피드백하여, 전체 아키텍처를 지속적으로 발전시킵니다. 따라서 데이터 아키텍처는 기술·설계·비즈니스 가치·민첩성이 결합된 전략적 영역입니다.

5️⃣ 오케스트레이션 (Orchestration)

오케스트레이션은 여러 데이터 작업이 순서대로, 효율적으로, 안정적으로 실행되도록 조정하는 프로세스입니다. 일반적으로 DAG(Directed Acyclic Graph) 형태로 종속성을 정의하고, 작업이 완료될 때 후속 작업을 자동으로 실행하도록 스케줄링합니다.

고급 오케스트레이션 엔진은 실행 기록, 시각화, 경고 기능을 제공하며, 새로운 DAG나 작업이 추가될 때 백필(Backfill)과 시간 기반 종속성 관리도 지원합니다. 대표적인 예로 Prefect, Dagster, Argo, Metaflow등이 있으며, 이는 로컬 개발에서 운영 환경으로의 이식성과 유연성을 높여줍니다.

결국 오케스트레이션은 복잡한 데이터 파이프라인의 종속성과 실행 순서를 보장하며, 운영을 투명하고 안정적으로 만드는 핵심 기술입니다.

6️⃣ 소프트웨어 엔지니어링 (Software Engineering)

데이터 엔지니어링에서 소프트웨어 엔지니어링은 데이터를 효율적이고 안정적으로 처리할 수 있는 소프트웨어를 설계·구현·테스트·운영하는 기술과 방법론을 의미합니다. 과거에는 Java, C++로 MapReduce를 직접 구현했지만, 현재는 Spark, Beam, Flink 같은 고수준 프레임워크로 생산성과 안정성을 높입니다.

데이터 엔지니어는 수집, 변환, 서빙 등 데이터 처리 전반의 핵심 코드를 작성해야 하며, 단위 테스트, 회귀 테스트, 통합 테스트, E2E 테스트 등 다양한 테스트 방법론으로 코드 품질을 보장합니다.

또한 오픈소스 프레임워크 활용 능력과 IaC(코드형 인프라), 코드형 파이프라인 설계 역량이 필수입니다. Terraform, CloudFormation 등을 사용해 인프라를 자동 배포하고 관리하며, CI/CD 파이프라인을 통해 버전 제어와 배포의 일관성을 유지합니다.

마지막으로, 범용 문제 해결 능력도 데이터 엔지니어의 핵심 역량입니다. Airbyte, Fivetran, Matillion 같은 커넥터가 지원하지 않는 소스의 경우, API 분석과 데이터 풀링, 예외 처리를 직접 구현해야 합니다.

데이터 아키텍처 설계에서 가장 중요한 세 가지 핵심 요소는 Scalability, Availability, 그리고 Reliability 입니다.

Scalability 는 데이터 양이나 사용자 수가 증가하더라도 시스템 성능이 저하되지 않고 유연하게 확장될 수 있는 능력을 의미합니다. 특히 클라우드 환경에서는 자동 스케일링(Auto Scaling) 기능을 활용해 컴퓨팅 자원과 스토리지를 동적으로 조정함으로써, 비용 효율적이면서도 확장성 있는 인프라를 구현할 수 있습니다.

Availability 는 시스템이 언제나 안정적으로 서비스를 제공할 수 있는 능력을 의미하며, 장애가 발생하더라도 서비스 중단을 최소화해야 합니다. 이를 위해 멀티존 배포, 리던던시 구조, 클러스터링 등을 활용해 고가용성을 확보합니다.

Reliability 는 데이터 처리와 저장 과정에서 오류 없이 일관되고 신뢰성 있게 동작하는 능력을 말합니다. 이를 위해 백업 및 데이터 복제, 장애 복구(Disaster Recovery) 전략 등을 통해 데이터 손실이나 손상을 최소화해야 합니다.

따라서 데이터 아키텍처 설계는 클라우드 기반의 확장성, 가용성, 신뢰성을 균형 있게 확보하는 것 에 초점을 두어야 하며, 이를 통해 안정적인 데이터 플랫폼 운영과 지속 가능한 확장을 가능하게 합니다.

👉 키워드 → Scalability / Availability / Reliability

💬 엔터프라이즈 아키텍처(EA)란 ?

엔터프라이즈 아키텍처(EA)란, 기업의 변화를 지원하고 비즈니스 목표를 달성하기 위해 전략, 운용, 기술을 조정하는 시스템 설계를 말합니다. EA는 비즈니스, 기술, 애플리케이션, 데이터를 포함한 여러 하위 영역을 포괄하며, 기업 내 다양한 시스템과 기능 그룹 간 상호작용을 구조화합니다.

대표적인 정의로는 TOGAF(The Open Group Architecture Framework)가 있으며, 이는 기업 내 주요 데이터 유형과 원천, 논리적·물리적 데이터 자산, 데이터 관리 자원의 구조와 상호작용을 설명합니다. 가트너는 EA를 기업이 파괴적 변화에 능동적이고 전체적으로 대응하도록 돕는 분야로 정의하며, EA는 비즈니스 리더와 IT 리더가 정책과 프로젝트를 조정해 목표한 사업 결과를 달성하도록 권장 사항을 제시함으로써 가치를 제공합니다. 그 외 정의로는 EABOK(Enterprise Architecture Book of Knowledge)가 있는데, EABOK에서는 EA를 전략, 운용, 기술을 조정하여 성공 로드맵을 만드는 추상적 조직 모델로 설명합니다.

EA의 핵심 요소 중 하나는 가역적 의사결정(Reversible Decision-Making)입니다. 기업 환경은 끊임없이 변화하며, 미래를 완전히 예측할 수 없기 때문에 되돌릴 수 있는 결정(Two-way Door)을 통해 새로운 정보나 변화에 맞춰 프로세스를 조정할 수 있어야 합니다. 반면 단방향 결정(One-way Door)은 되돌릴 수 없는 결정으로 인식해야 합니다. 이러한 가역성을 고려하면, 조직이 성장하면서 자연스럽게 발생하는 경직화(Ossification)를 완화하고 의사결정에 수반되는 위험을 줄일 수 있습니다.

또한 EA에서는 변경 관리(Change Management)가 필수적입니다. 아키텍트는 현재 상태의 문제(낮은 데이터 품질, 확장성 제한, 비용 손실)를 분석하고, 바람직한 미래 상태(민첩한 데이터 품질 개선, 확장성 있는 클라우드 데이터 솔루션, 비즈니스 프로세스 개선)를 정의한 뒤, 소규모 구체적인 단계로 실행함으로써 반복 가능한 개선을 수행합니다. 이 과정에서 기술 솔루션은 그 자체를 위한 것이 아니라 비즈니스 목표를 지원하기 위한 수단으로 설계됩니다.

마지막으로 EA에서 중요한 것은 트레이드오프 평가(Trade-off Evaluation)입니다. 데이터 엔지니어와 아키텍트는 시스템 설계 단계에서 다양한 선택의 장단점과 비용을 신중하게 평가하고, 값비싼 기술 부채를 최소화하면서 유연하고 유지 관리 가능한 최적의 아키텍처를 구현해야 합니다.

요약하면, 엔터프라이즈 아키텍처는 기업 변화 지원, 가역적 의사결정, 변경 관리, 트레이드오프 평가를 통해 비즈니스 목표 달성, 시스템 유연성, 유지보수 용이성을 동시에 달성하는기업 시스템 설계입니다.

👉 키워드 → Reversible Decision-Making / Change Management / Trade-off Evaluation

💬 엔데이터 아키텍처란 ?

데이터 아키텍처란 엔터프라이즈 아키텍처의 하위집합으로, 프로세스, 전략, 변경 관리, 트레이드오프 평가 등의 속성을 상속하며 기업의 데이터 요구 사항을 지원하는 시스템 설계를 의미합니다.

TOGAF(The Open Group Architecture Framework)에서는 기업의 주요 데이터 유형과 원천, 논리적 데이터 자산, 물리적 데이터 자산, 데이터 관리 자원의 구조와 상호 작용을 설명하고 있습니다.

DAMA(Data Management Association)는 구조와 관계없이 기업의 데이터 요구 사항을 파악하고 이를 충족할 마스터 청사진을 설계하고 유지 관리하며, 이를 통해 데이터 통합을 안내하고 데이터 자산을 제어하며 데이터 투자를 비즈니스 전략에 맞게 조정하도록 정의합니다.

데이터 아키텍처는 기업의 진화하는 데이터 요구 사항을 지원하기 위해 트레이드오프에 대한 신중한 평가를 거쳐 유연하고 되돌릴 수 있는 결정을 내림으로써 실현됩니다. 데이터 엔지니어링 아키텍처는 데이터 엔지니어링 수명주기의 핵심 부분을 구성하는 시스템 프레임워크로서, 운영 아키텍처와 기술 아키텍처로 나눌 수 있습니다.

운영 아키텍처는 인력, 프로세스, 기술과 관련된 필요 기능 요건을 포괄하며, 예를 들어 데이터가 어떤 비즈니스 프로세스를 지원하는지, 조직이 데이터 품질을 어떻게 관리하는지, 데이터 생성 시점부터 쿼리 가능한 시점까지의 지연 시간 요구사항이 무엇인지 등을 정의합니다.

기술 아키텍처는 데이터 엔지니어링 수명주기를 통해 데이터를 수집, 저장, 변환 및 제공하는 방법을 개략적으로 설명하며, 예를 들어 시간당 10TB 데이터를 원천 데이터베이스에서 데이터 레이크로 이동시키는 방법과 같은 구체적 실행 방안을 포함합니다. 요컨대, 운영 아키텍처는 무엇을 해야 하는지를, 기술 아키텍처는 어떻게 수행할지를 명확히 설명함으로써 전체 데이터 아키텍처를 완성합니다.

👉 키워드 → Operational Architecture / Technical Architecture

💬 우수한 데이터 아키텍처란 ?

우수한 데이터 아키텍처란 유연하고 유지 관리가 쉬우며, 적절한 트레이드오프를 실현하면서 광범위하게 재사용 가능한 공통 구성 요소를 활용해 비즈니스 요건을 충족하는 아키텍처를 말합니다. 반대로 나쁜 아키텍처는 권위주의적이고 획일적인 결정을 강제로 적용하며, 시스템을 과도하게 결합시키거나 경직되게 만들고, 중앙집중화가 심하거나 업무에 맞지 않는 잘못된 도구를 사용해 개발과 변경 관리를 방해합니다. 이상적인 데이터 아키텍처는 가역성(Reversibility)을 고려해 설계되어, 변경 비용을 최소화할 수 있어야 합니다. 따라서 우리는 다음의 9가지 원칙을 지켜야 합니다.

① 공통 컴포넌트를 현명하게 선택하라 — 데이터 엔지니어는 조직 전체에서 폭넓게 재사용할 수 있는 구성 요소와 표준을 선택해야 합니다. 예를 들어, 객체 스토리지(S3, GCS), 버전 관리 시스템(Git), 오케스트레이션(Airflow), 처리 엔진(Spark, Flink) 등이 이에 해당합니다. 검증된 컴포넌트를 재사용함으로써 개발 시간을 단축하고 보안 및 접근 제어를 강화할 수 있습니다.

② 장애에 대비하라 — 안정적인 시스템은 장애를 가정하고 설계되어야 합니다.가용성(Availability), 신뢰성(Reliability),복구 시간 목표(RTO), 복구 시점 목표(RPO)와 같은 지표를 기반으로 복구 전략을 수립하고, 장애 시나리오별 대응 절차를 문서화해야 합니다.

③ 확장성을 위한 설계 — 부하에 따라 시스템이 자동으로 확장(Scale-out) 또는 축소(Scale-in)되어야 합니다. 예를 들어, 스트리밍 데이터 수집 파이프라인은 트래픽 급증 시 자동 확장이 가능해야 하며, 서버리스 환경에서는 Scale to Zero 기능을 통해 유휴 자원 비용을 절감할 수 있습니다. 또한 미래 부하를 예측해 아키텍처 적합성을 지속적으로 평가해야 합니다.

④ 아키텍처는 리더십이다 — 데이터 아키텍트는 기술만이 아니라 조직의 비전과 방향을 제시해야 합니다. 기술 선택 시 비즈니스 목표를 고려하고, 엔지니어링 팀이 공통된 기준으로 협업할 수 있도록 교육과 리더십을 통해 모범 사례를 전파해야 합니다.

⑤ 항상 아키텍처에 충실하라 —기본 아키텍처(Baseline Architecture)를 명확히 이해하고,목표 아키텍처(Target Architecture)를 정의하며, 변화의 단계적 이행을 위한 시퀀싱 계획(Sequencing Plan)을 수립해야 합니다. 이는 무질서한 변경으로 인한 기술 부채를 방지하고, 일관된 방향성을 유지하기 위함입니다.

⑥ 느슨하게 결합된 시스템을 구축하라 — 팀 간 의존성을 줄이고 독립적으로 테스트, 배포, 변경이 가능한 구조를 만들어야 합니다. 메시징 버스(Kafka, Pub/Sub)나 API Gateway를 통한 인터페이스 추상화로 내부 구현을 캡슐화하고, 각 컴포넌트가 독립적으로 진화할 수 있도록 설계합니다.

⑦ 되돌릴 수 있는 의사결정을 하라 — 데이터 아키텍처는 가역적 의사결정(Reversible Decision-Making)을 기반으로 해야 합니다. 즉, 새로운 기술이나 패턴을 도입하더라도 언제든 철회하거나 대체할 수 있어야 하며, 이를 통해 빠른 실험과 안전한 롤백이 가능해집니다. 이 원칙은 조직의 민첩성(Agility)을 확보하는 핵심 요소입니다.

⑧ 보안 우선순위를 지정하라 —제로 트러스트 보안 모델(Zero-trust Security)은 내부 네트워크조차 신뢰하지 않고, 모든 접근 요청마다 인증과 권한 검증을 수행하는 모델입니다. 이는 내부자 위협과 외부 침입 모두에 효과적으로 대응할 수 있습니다. 또한 공동 책임 모델(Shared Responsibility Model)을 통해 클라우드 제공자(AWS, GCP 등)와 사용자의 보안 역할을 명확히 구분해야 합니다. 예를 들어, 클라우드 인프라 보안은 제공자가, 데이터 보호와 접근 제어는 사용자가 담당합니다.

⑨ 핀옵스(FinOps)를 수용하라 — 핀옵스는 클라우드 재무 관리 문화로, 엔지니어링·재무·비즈니스 팀이데이터 기반 의사결정(Data-driven Decision-making)을 통해 클라우드 비용을 최적화하는 것을 목표로 합니다. 예를 들어, AWS 스팟 인스턴스를 활용한 비용 절감, 예약 인스턴스로의 전환 시점 결정, 워크로드별 최적 인프라 선택 등은 핀옵스의 실질적 적용 사례입니다.

요약하면, 우수한 데이터 아키텍처는가역성(Reversibility)과 느슨한 결합(Loose Coupling)을 기반으로 하며, 보안·확장성·비용 효율성을 동시에 달성하여 변화에 강하고 지속 가능한 데이터 환경을 구축하는 것을 목표로 합니다.

👉 키워드 → Reversibility / Loose Coupling / Zero-Trust / FinOps

💬 도메인 지식이란 ?

특정 산업이나 업무 분야의 프로세스, 규칙, 데이터 구조, 관행을 깊이 이해하고 있는 지식을 의미합니다. 이는 단순한 기술 역량을 넘어, 해당 분야의 문제를 정확히 정의하고 데이터로 해결할 수 있는 능력을 포함합니다.

예를 들어, 금융 도메인에서는대출, 예금, 거래, 수수료, 이자 계산 등 금융 서비스의 구조를 이해하고, 금융 기관의 기간계, 정보계, 계정계 시스템이 어떤 역할을 하며 데이터가 어떻게 흐르는지를 파악하는 것이 핵심입니다.

👉 키워드 → 프로세스 / 규칙 / 기간계 / 정보계 / 계정계

💬 분산 시스템을 설계시 고려할 점

분산 시스템을 설계할 때는 확장성과 장애 대응 능력을 고려하는 것이 매우 중요합니다. 이러한 설계 원칙은 데이터 시스템의 성능, 안정성, 유지 관리성을 결정짓는 핵심 요인으로 작용합니다. 데이터 시스템에는 서로 밀접하게 연관된 네 가지 주요 특징이 존재합니다.

첫째, 확장성(Scalability)은 시스템의 용량을 늘려 성능을 개선하고, 증가하는 수요를 처리할 수 있는 능력을 의미합니다. 특히 수평 확장(horizontal scaling)을 통해 동일한 기능을 수행하는 노드를 여러 개 추가함으로써, 트래픽 급증 시에도 안정적인 성능을 유지할 수 있습니다. 예를 들어 데이터 파이프라인에서 처리량이 증가하면 새로운 워커 노드를 추가해 병렬 처리를 확장할 수 있습니다.

둘째, 탄력성(Elasticity)은 시스템이 현재 워크로드에 따라 리소스를 자동으로 조정하는 능력을 의미합니다. 즉, 부하가 높을 때는 스케일 업(Scale-Up) 또는 스케일 아웃(Scale-Out)을 수행하고, 부하가 낮을 때는 자동으로 스케일 다운(Scale-Down)합니다. 이는 엔지니어의 수동 개입 없이도 적절한 성능을 유지하며, 클라우드 환경에서 비용 효율적 운영을 가능하게 합니다.

셋째, 가용성(Availability)은 IT 서비스나 컴포넌트가 정상적으로 작동 가능한 시간의 비율을 나타냅니다. 예를 들어 99.99%의 가용성(“four nines”)은 1년 중 약 52분 이하의 다운타임만 허용된다는 뜻입니다. 높은 가용성을 달성하기 위해서는 시스템의 중복 구성과 장애 복구 전략이 필수적입니다.

넷째, 신뢰성(Reliability)은 시스템이 일정 기간 동안 의도한 기능을 안정적으로 수행하고, 정의된 표준을 충족할 가능성을 의미합니다. 만약 시스템이 특정 시간 동안 성능 요건을 충족하지 못하거나 응답하지 않는다면, 이는 신뢰성 저하로 이어지며 결과적으로 가용성에도 부정적인 영향을 줍니다.

분산 환경에서는 이러한 신뢰성과 가용성을 확보하기 위해 리더 노드(Leader Node)와 워커 노드(Worker Node) 간의 역할 분담이 이루어집니다. 리더 노드는 워크로드를 인스턴스화하고 여러 워커 노드로 분배하며, 각 노드에서 수행된 작업 결과를 다시 수집합니다. 예를 들어 Spark나 YARN 같은 시스템에서 리더 노드는 드라이버 또는 리소스매니저로, 워커 노드는 실제 연산을 수행하는 Executor 또는 NodeManager로 동작합니다.

최신 분산 아키텍처는 중복성(Redundancy)을 기반으로 설계되어 있습니다. 특정 머신이 장애로 인해 중단되더라도 다른 머신이 자동으로 작업을 이어받을 수 있도록 데이터와 메타데이터가 복제(replication)됩니다. 또한 클러스터는 용량을 회복하거나 성능을 향상시키기 위해 새로운 노드를 동적으로 추가할 수 있으며, 이를 통해 확장성과 신뢰성을 동시에 확보합니다.

👉 키워드 → Scalability / Elasticity / Availability / Reliability

💬 Tight Coupling vs Loose Coupling

강한 결합과 느슨한 결합의 차이는 시스템 구성 요소 간 의존성의 정도와 변경 영향 범위에 있습니다. 강한 결합에서는 도메인과 서비스가 서로 필수적으로 의존하여 한 부분의 변경이나 장애가 전체 시스템에 영향을 미치지만, 느슨한 결합에서는 도메인과 서비스가 분산되어 독립적으로 운영 가능하며 한 부분의 변화가 다른 부분에 미치는 영향이 상대적으로 적습니다.

우수한 데이터 아키텍처를 설계하려면, 강한 결합과 느슨한 결합 사이에서 적절한 트레이드오프를 찾아야 하며, 시스템의 안정성과 유연성을 균형 있게 확보하는 것이 핵심입니다.

강한 결합에서는 도메인과 서비스의 모든 부분이 서로 필수적으로 의존하며, 중앙 집중화된 종속성과 워크플로가 형성됩니다. 이는 한 부분의 변경이나 장애가 전체 시스템에 영향을 미칠 수 있음을 의미합니다.

느슨한 결합에서는 각 도메인과 서비스가 서로 완전히 의존하지 않고 분산되어 있으며, 이를 통해 각 팀이 독립적으로 시스템을 운영할 수 있습니다. 다만 느슨한 결합 시나리오에서는 서로의 데이터를 활용하기 어려운 구조가 발생할 수 있으므로, 각 도메인과 서비스를 소유하는 팀에게 공통의 표준, 명확한 소유권, 책임, 의무를 부여하는 것이 중요합니다.

👉 키워드 → Tight Coupling / Loose Coupling

💬 아키텍처 계층

단일 계층(single-tier) 아키텍처는 데이터베이스와 애플리케이션이 밀접하게 결합되어 단일 서버에 상주하는 구조를 의미합니다. 강한 결합의 본질은 서버, 데이터베이스 또는 애플리케이션에 장애가 발생하면 전체 아키텍처가 영향을 받는다는 점입니다. 단일 계층 아키텍처는 프로토타이핑이나 개발 초기 단계에서는 적합하지만, 명백한 장애 위험 때문에 운영 환경에서는 권장되지 않습니다. 로컬 머신에서 시스템을 테스트하는 데는 유용하지만, 실제 서비스 환경에서는 사용하지 않는 것이 좋습니다.

이러한 문제를 해결하기 위해 다중 계층(multi-tier) 아키텍처가 사용됩니다. 다중 계층 아키텍처는 데이터, 애플리케이션, 비즈니스 로직, 프레젠테이션 등의 개별 계층으로 구성되며, 상향식(bottom-up) 계층적 구조를 가지면서 하위 계층은 상위 계층에 의존하지 않습니다. 반대로 상위 계층은 하위 계층에 의존하며, 이를 통해 애플리케이션에서 데이터를 분리하고 프레젠테이션과 애플리케이션을 독립적으로 관리할 수 있습니다.

특히, 3계층 아키텍처(three-tier architecture)는 데이터, 애플리케이션 로직, 프레젠테이션 계층으로 구성되며, 각 계층이 서로 격리되어 리스크를 분리할 수 있습니다. 이러한 구조에서는 모놀리식에 집중하지 않고도 각 계층에서 원하는 기술을 자유롭게 사용할 수 있습니다.

분산 시스템 환경에서는 계층을 분리하고, 계층 내에서 자원을 공유할지 여부를 결정해야 합니다.비공유 아키텍처(shared-nothing architecture)는 각 노드가 독립적으로 요청을 처리하며, 메모리, 디스크, CPU 등 자원을 서로 공유하지 않습니다. 데이터와 자원이 노드 단위로 격리되어 자원 경합을 최소화하지만, 다양한 노드가 여러 요청을 처리할 때 일부 경합이 발생할 가능성은 존재합니다. 반대로, 공유 디스크 아키텍처(shared-disk architecture)는 모든 노드가 동일한 디스크와 메모리에 접근할 수 있도록 설계되어, 임의의 노드에 장애가 발생하더라도 공유 자원을 활용할 수 있는 환경에서 사용됩니다.

👉 키워드 → Single-tier / Multi-tier / Shared-nothing / Shared-disk

💬 Monolith vs MicroService

이 두 방식은 현대 소프트웨어 아키텍처에서 많이 사용됩니다. 그렇지만 시스템을 구성하고 관리하는 방식에 있어 근본적인 차이가 있습니다.

모놀리스 아키텍처(monolithic architecture)는 가능한 많은 기능과 서비스를 한 시스템 안에 포함하는 구조로, 계층 간에는 기술 결합이, 도메인 간에는 도메인 결합이 발생합니다. 이런 특성 때문에 추론하기 쉽고 초기 개발 속도가 빠르며 단일 기술 스택으로 단순하게 관리할 수 있다는 장점이 있습니다. 예를 들어, 초기 스타트업이 한 명의 개발 팀으로 웹 애플리케이션과 백엔드 API, 데이터 처리 기능을 모두 단일 서버와 데이터베이스에서 운영할 때 모놀리스 구조가 효율적일 수 있습니다. 하지만 한 부분의 변경이나 장애가 전체 시스템에 영향을 미치고, 업그레이드나 배포 주기가 길어지며, 멀티테넌시 환경에서 리소스 경합이 생기는 등 확장성과 유연성 측면에서는 단점이 있습니다. 예컨대, 온프레미스 데이터 웨어하우스에서 특정 사용자 정의 함수가 다른 사용자의 쿼리 속도를 저하시킬 수 있는 상황이 발생할 수 있습니다.

반대로 마이크로서비스 아키텍처(microservices architecture)는 서비스를 기능 단위로 나누어 API를 통해 통신하게 하고, 각 서비스가 독립적으로 배포·운영되는 느슨한 결합 구조를 가집니다. 이 방식은 특정 서비스에 문제가 생겨도 전체 시스템에 영향을 주지 않고, 독립적인 확장과 새로운 기술 도입이 가능하다는 장점이 있습니다. 예를 들어, 글로벌 전자상거래 플랫폼에서 결제 서비스, 추천 서비스, 배송 서비스가 각각 독립적인 마이크로서비스로 운영된다면, 결제 서비스에 문제가 발생하더라도 추천 시스템이나 배송 시스템은 계속 정상적으로 동작할 수 있습니다. 다만 운영해야 할 서비스가 많아지면서 관리 복잡성이 커지고, 상호 운용성과 오케스트레이션이 중요한 과제가 된다는 점은 부담으로 작용합니다.

실제로는 두 방식 사이에 회색지대가 존재합니다. 예를 들어 하둡 클러스터나 아파치 에어플로 같은 경우는 분산 환경에서 동작하지만 여전히 공통 의존성과 코드베이스를 공유하기 때문에 전형적인 마이크로서비스라기보다는 분산형 모놀리스에 가깝습니다. 그래서 최근에는 컨테이너나 클라우드 기반의 임시 인프라를 활용하여 작업을 격리시키고, 모놀리스적 단순성과 마이크로서비스적 유연성을 절충하는 접근이 많이 사용되고 있습니다.

이러한 문제를 해결하기 위해 다중 계층(multi-tier) 아키텍처가 사용됩니다. 다중 계층 아키텍처는 데이터, 애플리케이션, 비즈니스 로직, 프레젠테이션 등의 개별 계층으로 구성되며, 상향식(bottom-up) 계층적 구조를 가지면서 하위 계층은 상위 계층에 의존하지 않습니다. 반대로 상위 계층은 하위 계층에 의존하며, 이를 통해 애플리케이션에서 데이터를 분리하고 프레젠테이션과 애플리케이션을 독립적으로 관리할 수 있습니다.

특히, 3계층 아키텍처(three-tier architecture)는 데이터, 애플리케이션 로직, 프레젠테이션 계층으로 구성되며, 각 계층이 서로 격리되어 리스크를 분리할 수 있습니다. 이러한 구조에서는 모놀리식에 집중하지 않고도 각 계층에서 원하는 기술을 자유롭게 사용할 수 있습니다.

분산 시스템 환경에서는 계층을 분리하고, 계층 내에서 자원을 공유할지 여부를 결정해야 합니다.비공유 아키텍처(shared-nothing architecture)는 각 노드가 독립적으로 요청을 처리하며, 메모리, 디스크, CPU 등 자원을 서로 공유하지 않습니다. 데이터와 자원이 노드 단위로 격리되어 자원 경합을 최소화하지만, 다양한 노드가 여러 요청을 처리할 때 일부 경합이 발생할 가능성은 존재합니다. 반대로, 공유 디스크 아키텍처(shared-disk architecture)는 모든 노드가 동일한 디스크와 메모리에 접근할 수 있도록 설계되어, 임의의 노드에 장애가 발생하더라도 공유 자원을 활용할 수 있는 환경에서 사용됩니다.

👉 키워드 → Single-tier / Multi-tier / Shared-nothing / Shared-disk

💬 중앙 집중화 vs 데이터 메시

데이터 아키텍처를 설계할 때 고려해야 할 중요한 사항 중 하나는 데이터 중앙 집중화(Centralized Data Architecture)와데이터 메시(Data Mesh) 접근 방식입니다.

중앙 집중화(Centralized Data Architecture)는 단일 팀이 조직 내 모든 도메인에서 데이터를 수집하고, 이를 통합하여 조직 전체에서 사용할 수 있도록 조정하는 방식입니다. 이 접근법은 전통적인 데이터 웨어하우스 설계에서 일반적으로 사용되며, 데이터 관리와 거버넌스를 일원화할 수 있다는 장점이 있습니다. 그러나 단일 팀에 책임이 집중되므로 확장성과 민첩성 측면에서 제한이 있을 수 있습니다.

반면, 데이터 메시(Data Mesh)는 조직 내 각 도메인이 자신이 소유한 데이터를 직접 관리하고, 다른 팀과 공유하는 분산형 데이터 아키텍처 패턴을 의미합니다. 데이터 메시 접근 방식에서는 각 소프트웨어 팀이 자신이 소유한 도메인에서 발생하는 데이터를 준비하고, 조직 전체에서 활용 가능하도록 책임을 집니다. 이를 통해 데이터 소유권과 책임이 분산되며, 각 팀이 자율적으로 데이터 품질과 접근성을 관리할 수 있어, 대규모 조직에서 데이터 활용의 민첩성과 확장성을 높이는 데 유리합니다.

👉 키워드 → Centralized Data Architecture / Data Mesh

💬 Single-Tenant vs Multi-Tenant

테넌트(Tenant)란, 클라우드나 SaaS(Software as a Service) 환경에서서비스를 사용하는 개별 고객이나 사용자 그룹을 의미합니다.

예를 들어, 하나의 애플리케이션을 여러 회사가 함께 사용할 때 각 회사를 하나의 테넌트로 구분하며, 테넌트마다 데이터와 설정이 논리적으로 분리되어 관리됩니다.

싱글 테넌트(Single-Tenant) 환경은 보안과 성능 측면에서 예측 가능하고 격리된 환경을 제공하지만, 비용과 확장성 측면에서는 제한적입니다. 반면, 멀티 테넌트(Multi-Tenant) 환경은 비용 효율과 자원 활용 측면에서 유리하지만, 성능 격차와 보안 관리가 더 복잡하며,시끄러운 이웃 문제(noisy neighbor issue)가 발생할 수 있습니다 (CPU, I/O, 네트워크 등 리소스 경쟁).

먼저 개념을 정의하면,싱글 테넌트(Single-Tenant)는 한 테넌트(사용자나 고객)가 전용 서버와 데이터베이스를 독립적으로 사용하는 구조로, 다른 테넌트의 영향 없이 시스템을 운영할 수 있는 환경을 의미합니다. 반대로, 멀티 테넌트(Multi-Tenant)는 여러 테넌트가 하나의 서버와 데이터베이스를 공유하며 자원을 나누어 사용하는 구조로, 효율적인 비용과 자원 활용이 가능하지만, 테넌트 간 부하가 겹칠 때 특정 테넌트의 성능이 저하되는시끄러운 이웃 문제(noisy neighbor issue)가 발생할 수 있으며, 보안 관리도 더 복잡합니다.

근거를 살펴보면,싱글 테넌트는 각 테넌트가 전용 자원을 사용하기 때문에 다른 테넌트의 부하나 트래픽에 영향을 받지 않고, 테넌트별 맞춤 보안 정책을 적용하기 용이합니다. 반면, 멀티 테넌트 환경에서는 여러 테넌트가 동일 서버와 자원을 공유하기 때문에 트래픽 불균형이나 부하 스파이크가 발생하면 일부 테넌트의 성능이 저하될 수 있고, 데이터 격리와 접근 제어를 보다 정교하게 설계해야 합니다.

또한, 비용과 운영 측면에서멀티 테넌트는 자원을 공유함으로써 운영 비용을 절감할 수 있는 장점이 있으며,싱글 테넌트는 전용 자원을 유지해야 하므로 초기 구축과 유지보수 비용이 상대적으로 높습니다.

즉, 선택 기준은보안과 성능 우선이면싱글 테넌트,비용과 확장성 우선이면멀티 테넌트가 적합하며,멀티 테넌트의 경우 시끄러운 이웃 문제를 고려한 성능 관리가 필수적입니다.

시끄러운 이웃 문제(Noisy Neighbor Issue)란, 멀티 테넌트 환경에서 한 테넌트의 과도한 리소스 사용이 다른 테넌트의 성능 저하를 초래하는 현상을 의미합니다.

주로 CPU, 메모리, I/O, 네트워크 같은 공유 자원을 독점할 때 발생하며, 자원 격리와 성능 모니터링이 제대로 이루어지지 않으면 시스템 불안정으로 이어질 수 있습니다.

👉 키워드 → Single-Tenant / Multi-Tenant / Noisy Neighbor

💬 Event-Driven Architecture, EDA

이벤트 기반 아키텍처는 시스템 내 상태 변화나 비즈니스 활동을 이벤트 단위로 정의하고, 이를 중심으로 서비스 간 통신과 워크플로우를 구성함으로써 느슨한 결합, 확장성, 장애 내성을 제공하는 아키텍처 패턴입니다.

이벤트 기반 아키텍처에서 이벤트(Event)는 시스템 내에서 발생하는 중요한 상태 변화나 사건을 의미하며, 예를 들어 새로운 고객 가입, 고객의 신규 주문, 제품이나 서비스 주문 등이 모두 이벤트에 해당합니다. 이벤트는 생산자(Producer)에 의해 생성되고,이벤트 라우터(Event Router, 메시지 브로커 또는 이벤트 버스)를 통해 전달되며, 최종적으로 이벤트를 소비하는 소비자(Consumer)에게 전달됩니다. 이 과정에서 생산자와 소비자는 서로 직접적인 종속성에 얽매이지 않고, 이벤트를 통해 비동기적으로 통신할 수 있습니다.

기술적으로 이벤트 기반 아키텍처는 생산자-라우터-소비자 구조를 갖추고 있으며, 이벤트 중심 워크플로를 구현할 수 있습니다. 이벤트가 발생하면 생산자가 이를 이벤트 라우터로 전송하고, 라우터는 이를 적절한 소비자에게 전달합니다. 소비자는 이벤트를 수신하여 필요한 처리를 수행하며, 여러 소비자가 동일 이벤트를 구독하도록 설계할 수도 있습니다. 이러한 구조 덕분에 서비스 간 강한 결합이 제거되고, 각 서비스는 독립적으로 확장하거나 유지보수할 수 있습니다.

이벤트 기반 아키텍처의 장점 중 하나는 이벤트 상태를 분산 시스템 전반에 걸쳐 공유할 수 있다는 점입니다. 서비스가 일시적으로 오프라인 상태가 되거나, 분산 시스템 내 특정 노드에서 장애가 발생하더라도 이벤트는 이벤트 라우터를 통해 큐잉되거나 저장되어 나중에 소비될 수 있습니다. 또한, 동일 이벤트를 여러 소비자가 동시에 처리할 수 있어, 이벤트 처리의 유연성과 시스템 확장성이 높아집니다.

결론적으로, 이벤트 기반 아키텍처는 상태 변화를 이벤트 단위로 캡처하고, 이를 비동기적으로 라우팅하며, 소비자가 독립적으로 처리할 수 있게 함으로써확장성, 장애 내성, 서비스 간 느슨한 결합을 확보할 수 있는 현대 분산 시스템 설계의 핵심 패턴입니다.

👉 키워드 → Event-Driven Architecture / Event / Producer / Event Router / Consumer

💬 브라운필드 프로젝트 vs 그린필드 프로젝트

브라운필드 프로젝트(Brownfield Project)는 기존 아키텍처를 기반으로 점진적으로 리팩터링하고 개선하는 접근 방식이며,그린필드 프로젝트(Greenfield Project)는 기존 아키텍처의 제약 없이 완전히 새로운 시스템을 처음부터 설계하는 접근 방식입니다. 두 방식 모두 데이터 아키텍처 설계의 원칙을 준수하고, 유연하며 되돌릴 수 있는 결정과 긍정적인 ROI 달성을 목표로 해야 합니다.

브라운필드 프로젝트는 기존 시스템이나 아키텍처를 기반으로 재설계하거나 개선하는 프로젝트를 의미하며, 기존 아키텍처와 과거 기술 선택으로 인한 제약을 고려해야 합니다.스트랭글러 패턴(Strangler Pattern)이 자주 활용되며, 기존 시스템의 컴포넌트를 하나씩 점진적으로 새로운 시스템으로 대체하여 시스템 전체에 미치는 영향을 평가하고 안전하게 개선할 수 있습니다.

반면, 그린필드 프로젝트는 기존 시스템이나 레거시 제약 없이 완전히 새로운 환경에서 데이터 아키텍처를 설계하는 접근 방식입니다. 이전 아키텍처에 얽매이지 않고 최신 기술과 최적화된 설계를 자유롭게 적용할 수 있어 설계 유연성이 높지만, 초기 구축 비용과 설계 리스크가 상대적으로 큽니다.

결론적으로, 기존 시스템을 개선하고 안정성을 유지하며 점진적 전환이 필요하면 브라운필드,과거 제약 없이 완전히 새로운 시스템을 설계하고 유연성을 극대화하려면 그린필드 접근이 적합합니다. 두 접근 방식 모두 데이터 아키텍처의 우수한 원칙, 트레이드오프 평가, 되돌릴 수 있는 설계 결정, ROI 달성을 중심으로 진행해야 합니다.

👉 키워드 → Brownfield Project / Greenfield Project / Strangler Pattern

💬 아키텍처 관점에서의 "데이터 웨어하우스"

데이터 웨어하우스(Data Warehouse)는 분석과 보고용 중앙 데이터 허브로, 데이터를 주제 중심, 통합, 비휘발성, 시간 변형적 특성을 갖도록 구조화하여 대규모 데이터 분석과 비즈니스 의사결정을 지원하는 아키텍처입니다. 현대에는 클라우드 기반 데이터 웨어하우스와 데이터 마트 등을 포함한 확장된 생태계가 일반적입니다.

데이터 웨어하우스의 개념은 1989년 빌 인먼(Bill Inmon)이 고안했으며, 그는 이를 경영진의 의사결정을 지원하는주제 지향적(subject-oriented), 통합적(integrated), 비휘발성(non-volatile), 시간 변형적(time-variant) 데이터 모임으로 정의했습니다. 이러한 특성은 분석 활용 사례에 맞게 데이터를 고도로 포맷하고 구조화하는 전통적 데이터 아키텍처를 가능하게 합니다.

조직적 관점에서, 조직 데이터 웨어하우스 아키텍처는 특정 비즈니스 팀의 구조와 프로세스와 관련된 데이터를 구성하며,운영 데이터베이스(OLTP)와 분석 시스템(OLAP)을 분리함으로써 운영 시스템 부하를 줄이고 분석 성능을 향상시킵니다. 데이터 중앙 집중화와 구성은 ETL(Extract, Transform, Load)을 통해 애플리케이션 시스템에서 데이터를 가져오는 방식으로 전통적으로 수행됩니다.

기술적 관점에서는, 기술 데이터 웨어하우스 아키텍처는 MPP(Massively Parallel Processing)와 같은 기술적 요소를 포함합니다. MPP는 관계형 SQL 시맨틱을 지원하면서 대규모 데이터를 병렬 스캔하도록 최적화되어 고성능 집계와 통계 계산을 수행할 수 있습니다. 최근 클라우드 환경에서는 행 기반 아키텍처에서 열 기반 아키텍처(Columnar Storage)로 점점 전환되고 있으며, 이는 대규모 데이터와 고성능 쿼리 처리에 필수적입니다.

데이터 로딩과 처리 측면에서, ELT(Extract, Load, Transform) 아키텍처를 활용하면 데이터를 운영 시스템에서 직접 데이터 웨어하우스 스테이징 영역으로 이동시키고, 변환(Transform)은 데이터 웨어하우스 내부에서 수행됩니다. 이 방식은 클라우드 데이터 웨어하우스의 방대한 계산 능력을 활용할 수 있으며, CDC(Change Data Capture) 이벤트를 스트리밍하여 변환할 때도 효율적입니다.

현대 기업에서는 클라우드 데이터 웨어하우스가 점점 보편화되고 있습니다. AWS Redshift, Google BigQuery, Snowflake 등은 컴퓨팅과 스토리지를 분리한 아키텍처를 제공하며, 데이터를 객체 스토리지에 저장해 사실상 무제한 스토리지를 지원합니다. 사용자는 컴퓨팅 파워를 온디맨드로 스핀업하거나 필요하지 않을 때 삭제할 수 있어 비용 효율적이며, 단일 쿼리로 페타바이트 단위 데이터 처리도 가능합니다. 또한 행당 수십 MB 크기의 원시 텍스트 데이터나 복잡한 JSON 문서도 저장하고 분석할 수 있어 대규모 데이터 분석에 적합합니다.

마지막으로, 특정 부서나 라인 오브 비즈니스(LOB)를 위해 데이터 웨어하우스의 하위집합으로 설계되는데이터 마트(Data Mart)가 있습니다. 데이터 마트는 분석가와 보고서 개발자가 데이터를 더 쉽게 접근하도록 하며, 초기 ETL/ELT에서 제공하지 않는 추가 변환 단계를 수행할 수 있습니다. 이를 통해 보고서 또는 분석 쿼리에 복잡한 데이터 조인과 집계가 필요할 때 성능을 크게 향상시킬 수 있습니다. 데이터 마트는 라이브 쿼리 성능을 개선하기 위해 조인 및 집계된 데이터를 미리 채워 넣는 방식으로 운영될 수 있습니다.

👉 키워드 → Data Warehouse / OLTP / OLAP / ELT / Cloud Data Warehouse / Data Mart / MPP / Columnar Storage

💬 아키텍처 관점에서의 "데이터 레이크"

데이터 레이크(Data Lake)는 모든 크기와 유형의 원시 데이터를 중앙 집중화된 단일 저장소에 저장하고, 필요할 때 온디맨드로 컴퓨팅 자원을 활용해 처리할 수 있는 데이터 아키텍처로, 데이터 웨어하우스와 달리 스키마와 형식에 구애받지 않는 유연성을 제공하지만, 관리 및 데이터 품질 측면에서 상당한 도전과제를 안고 있습니다.

데이터 레이크의 시작은 HDFS(Hadoop Distributed File System) 기반으로, 대규모 데이터 처리와 저장을 지원하는 오픈소스 환경에서 이루어졌습니다. 이후 클라우드 컴퓨팅과 객체 스토리지의 발전으로, 데이터 레이크는저비용, 사실상 무제한 스토리지 용량을 갖춘 클라우드 기반 객체 스토리지로 이동하였으며, 스토리지와 컴퓨팅이 강하게 결합된 단일 데이터 웨어하우스 구조에 의존하지 않고, 데이터 처리 요구에 따라 클러스터를 온디맨드로 스핀업하여 거의 무제한에 가까운 컴퓨팅 성능을 활용할 수 있습니다.

데이터 처리 기술 측면에서는 맵리듀스(MapReduce), 스파크(Spark), 레이(Ray), 프레스토(Presto), 하이브(Hive) 등 원하는 도구와 프레임워크를 선택해 데이터 변환, 집계, 분석 작업을 수행할 수 있습니다. 이를 통해 데이터 레이크는 구조화, 반구조화, 비구조화 데이터를 모두 저장하고, 필요에 따라 유연하게 처리할 수 있는 환경을 제공합니다.

그러나 데이터 레이크에는 중요한 단점이 존재합니다. 많은 조직에서 초기 설계와 관리 부족으로 인해 데이터 늪(Data Swamp), 다크 데이터(Dark Data) 현상이 발생했고, 스키마 관리, 데이터 카탈로그, 검색 도구가 부족한 상태에서 데이터가 관리 불가능한 규모로 증가했습니다. 또한 데이터 레이크는 본래 쓰기 전용으로 설계되어 GDPR과 같은 규제 하에서 레코드를 삭제하거나 갱신하기 어렵고, 대부분 완전히 새로운 테이블을 생성하는 방식으로 해결해야 했습니다.

초기 데이터 레이크 환경에서 데이터 처리는 맵리듀스 기반 코딩이 필요했기 때문에, 조인과 같은 기본 데이터 변환 작업조차 복잡하고 비용이 많이 들었습니다. 이후 피그(Pig)와 하이브(Hive) 같은 프레임워크가 등장하여 일부 처리가 개선되었지만, 데이터 관리와 품질 문제의 근본적 해결에는 한계가 있었습니다. 이 때문에 많은 기업은 원시 아파치 코드베이스를 직접 다루기보다는맞춤형 하둡 배포판을 벤더로부터 구매하거나, 클라우드 기반 데이터 레이크를 활용해 관리 부담을 줄이는 선택을 하게 되었습니다.

결과적으로, 데이터 레이크는 무제한 데이터 저장, 유연한 데이터 처리, 다양한 데이터 형식 지원이라는 장점을 제공하지만,데이터 관리 부재, 데이터 품질 저하, 높은 초기 처리 비용으로 인해 잘못 운영되면 낭비와 비용 증가의 원인이 될 수 있습니다. 따라서 데이터 레이크를 운영할 때는 데이터 카탈로그, 스키마 관리, 거버넌스, 컴플라이언스 준수 등 관리 체계를 반드시 갖추는 것이 필수적입니다.

👉 키워드 → Data Lake / HDFS / Cloud Object Storage / MapReduce / Spark / Ray / Presto / Hive / Data Swamp / Dark Data

💬 아키텍처 관점에서의 차세대 데이터 환경

차세대 데이터 환경에서는데이터 웨어하우스와데이터 레이크의 장점을 융합한데이터 레이크하우스(Data Lakehouse)와 이를 중심으로 한 통합 데이터 플랫폼(Data Platform)이 핵심 아키텍처로 자리잡고 있으며,ACID 트랜잭션, 확장성, 다양한 데이터 형식 지원, 유연한 분석 처리를 동시에 제공합니다.

데이터 레이크하우스는데이터 웨어하우스에서 제공하는 제어(Control), 데이터 관리(Data Governance), 데이터 구조(Data Structure) 기능을 통합하면서도, 데이터 레이크처럼 객체 스토리지에 데이터를 저장하고 다양한 쿼리 및 데이터 변경 엔진을 지원합니다. 본래의 데이터 레이크와 달리 ACID 트랜잭션(원자성, 일관성, 독립성, 내구성)을 지원하여 신뢰성 있는 데이터 처리를 가능하게 하며, 데이터 레이크와 데이터 웨어하우스의 융합을 의미합니다.

클라우드 기반 데이터 웨어하우스는 컴퓨팅과 스토리지를 분리하고, 페타바이트 규모의 쿼리 처리,비정형 및 반정형 객체 데이터 저장,스파크(Spark)나 빔(Beam)과 같은 고급 데이터 처리 기술과의 통합을 지원합니다. 이를 통해 온디맨드 컴퓨팅, 자동 확장, 고성능 분석 쿼리 수행이 가능하며, 데이터 레이크의 유연성과 데이터 웨어하우스의 구조적 장점을 모두 활용할 수 있습니다.

데이터 플랫폼은 데이터 레이크와 데이터 웨어하우스 기능을 통합한 종합 환경으로, 여러 벤더가 제공합니다. AWS, Azure, Google Cloud, Snowflake, Databricks 등은관계형부터 완전한 비정형 데이터까지 처리할 수 있는 통합 도구 세트를 제공하며, 데이터 수집, 저장, 처리, 분석, 거버넌스까지 강하게 통합된 워크플로우를 지원합니다.

👉 키워드 → Data Lakehouse / Cloud Data Warehouse / Data Platform

💬 Modern Data Stack

모던 데이터 스택은클라우드 기반의 모듈식 데이터 아키텍처로, 비용 효율적으로 데이터 파이프라인·스토리지·변환·거버넌스·시각화를 통합하여 복잡성을 줄이고 빠른 변화에 대응할 수 있는 현대적 데이터 운영 환경을 제공합니다.

과거 데이터 환경이 비싸고 변경이 어려운 모놀리식(monolithic) 도구에 의존했다면, 모던 데이터 스택은 Plug-and-Play(PnP) 방식의 기성 컴포넌트들을 기반으로 각 구성 요소를 독립적으로 교체·확장할 수 있는모듈식(modular) 구조를 제공합니다. 이를 통해 기술 선택의 자유도와 비용 효율성을 크게 확보할 수 있습니다.

구성 요소는데이터 파이프라인(Data Pipeline), 스토리지(Storage), 변환(Transformation), 데이터 관리·거버넌스(Data Governance), 모니터링(Monitoring), 시각화·탐색(Visualization) 등으로 이루어져 있으며, 목표는 복잡성 최소화, 셀프 서비스 분석, 신속한 데이터 운영입니다.

또한 모던 데이터 스택은명확한 가격 모델을 가진 오픈소스 또는 단순한 SaaS 기반으로 구성되며, 커뮤니티 생태계와 사용자 피드백을 통해 도구가 빠르게 발전합니다. 덕분에 데이터 엔지니어와 분석가가 직접 스택을 구축하고 운영할 수 있는 환경을 제공합니다.

👉 키워드 → Modern Data Stack / Modular

💬 Lambda Architecture 와 Kappa Architecture

람다 아키텍처는배치 계층과 스트리밍 계층을 분리하여 정확성과 실시간성을 동시에 제공하는 구조인 반면,카파 아키텍처는 스트림 처리 플랫폼을 단일 백본으로 사용하여 배치 계층 없이 실시간과 일괄 처리를 통합하는 구조입니다.

람다 아키텍처는배치(Batch), 스트리밍(Streaming), 서빙(Serving) 계층을 독립적으로 운영하여 대규모 데이터에 대해 저지연 실시간 분석과 정확한 배치 처리를 동시에 제공하는 데이터 처리 아키텍처입니다. 2010년대 초중반 Storm, Samza 등 스트리밍/실시간 분석 프레임워크와Kafka 같은 확장성 높은 메시지 큐 등장으로 발전했습니다.

람다 아키텍처에서는 원천 데이터 소스가 변경 불가(immutable)하며, 데이터가 입력되면 배치 계층과 스트리밍 계층으로 동시에 전송됩니다. 스트리밍 처리 계층은 NoSQL 기반 속도 계층(Speed Layer)을 사용하여 낮은 지연 시간으로 실시간 분석과 인사이트 제공에 집중하고, 배치 계층은 데이터 웨어하우스에서 사전 계산(precomputed) 및 집계(view) 처리를 수행하여 정확성과 안정성을 확보합니다. 최종적으로 서빙 계층(Serving Layer)이 배치와 스트리밍 결과를 결합하여 집계된 통합 뷰를 생성합니다.

카파 아키텍처는 스트림 처리 플랫폼을 데이터 처리, 저장, 서빙의 단일 백본으로 사용하여 실시간과 배치 처리를 통합하는 접근 방식입니다. 제이 크랩스(Jay Kreps)가 제안했으며, 람다 아키텍처의 배치 계층 중복과 유지보수 복잡성을 제거하고 모든 데이터 처리(수집, 변환, 저장, 서빙)를 스트리밍 플랫폼 중심으로 수행합니다. 실시간 이벤트 스트림을 직접 읽고 필요 시 데이터 청크를 재생(replay)하여 배치 처리 효과를 얻을 수 있습니다.

그러나 카파 아키텍처는스트리밍 기반 처리의 복잡성, 높은 구현 비용, 유지보수 어려움으로 인해 널리 채택되지 못했습니다. 반면, 전통적 배치 기반 처리와 스토리지는 대규모 데이터셋 처리에 효율적이고 비용 대비 성능이 우수합니다.

👉 키워드 → Lambda Architecture / Kappa Architecture

💬 데이터 흐름 모델과 통합 배치·스트리밍 처리

데이터 흐름(Data Flow) 모델은배치 처리와 스트리밍 처리를 단일 통합 프레임워크에서 동일한 코드로 관리할 수 있도록 설계된 접근 방식으로, 배치와 스트림 처리 관리의 복잡성을 줄이고 일관성을 확보할 수 있습니다.

배치(Batch) 및 스트림(Stream) 처리에서 주요 문제 중 하나는여러 코드 경로를 통합하는 것입니다. 전통적인 카파 아키텍처는 통합 큐잉과 스토리지 계층을 사용하지만, 실시간 통계 수집이나 배치 집계 작업 수행 시 별도의 도구를 사용해야 하므로 코드와 시스템 관리가 분리되고 복잡해집니다.

이를 해결하기 위해 구글은 데이터 흐름 모델(Data Flow Model)과 이를 구현한 아파치 빔(Apache Beam) 프레임워크을 개발했습니다. 데이터 흐름 모델의 핵심 개념은 모든 데이터를 이벤트(Event)로 간주하고, 다양한 유형의 윈도(Window)를 통해 집계가 수행된다는 점입니다. 지속적인 실시간 이벤트 스트림은 무한 데이터(Unbounded Data)로 간주되며, 배치 처리 시에는 단순히 경계가 있는 유한 데이터(Bounded Data)로 취급됩니다. 이때 경계가 자연스러운 윈도 역할을 합니다.

엔지니어는 실시간 집계를 위해 슬라이딩 윈도(Sliding Window),텀블링 윈도(Tumbling Window) 등 다양한 윈도 전략을 선택할 수 있으며, 배치 처리와 실시간 처리는 거의 동일한 코드와 시스템에서 수행됩니다. 이를 통해 배치와 스트리밍 처리를 별도로 관리하는 복잡성을 줄이고, 시스템 유지보수와 코드 일관성을 크게 개선할 수 있습니다.

슬라이딩 윈도우(Sliding Window)는 윈도우가 일정 간격으로 겹치면서 이동하는 방식입니다. 같은 이벤트가 여러 윈도우에 포함될 수 있으며, 실시간 트렌드나 최근 변화량 분석에 유용합니다. 예를 들어 5초 크기의 윈도우가 2초 간격으로 이동하면, 0~4초 이벤트와 2~6초 이벤트가 각각 집계되어 2~4초 구간 이벤트는 두 번 계산됩니다.

텀블링 윈도우(Tumbling Window)는 윈도우가 겹치지 않고 연속적으로 나뉘는 방식입니다. 각 이벤트는 정확히 한 번만 포함되며, 일정 시간 또는 개수 단위로 구간이 분리됩니다. 예를 들어 5초 크기의 텀블링 윈도우라면, 0~4초 이벤트는 첫 번째 윈도우, 5~9초 이벤트는 두 번째 윈도우에 각각 집계되어 중복이 발생하지 않습니다.

👉 키워드 → Data Flow Model / Apache Beam / Sliding Window / Tumbling Window / Batch & Stream Processing

💬 IoT용 아키텍처

사물인터넷(IoT)은 컴퓨터, 센서, 모바일 기기, 스마트홈 장치처럼 인터넷에 연결된 다양한 장치들의 집합으로 이루어진 분산 환경입니다. 이러한 장치들은 보통 저전력·저자원·저대역폭 조건에서 동작하며, 주변 환경을 감지해 데이터를 수집하고 이를 다운스트림 시스템으로 전송합니다. 소비자 예시로는 초인종 카메라, 스마트워치, 온도 조절기 등이 있습니다.

각 IoT 장치는 최소한의 데이터 수집 및 전송 기능을 갖추며, 필요할 경우에지 컴퓨팅(Edge Computing)으로 사전 처리나에지 머신러닝(Edge ML)을 수행할 수 있습니다. 데이터 엔지니어는 장치 내부 구현까지 알 필요는 없지만, 어떤 데이터를 수집하는지, 어떤 전처리가 수행되는지, 전송 주기와 네트워크 환경에서 발생 가능한 장애가 어떤 영향을 미치는지 이해할 필요가 있습니다.

장치와 인터넷 사이에는 IoT 게이트웨이가 위치해 장치들을 인터넷에 연결하고 데이터를 적절한 목적지로 라우팅합니다. 게이트웨이는 저전력 장치의 연결을 지원하며, 임시 저장 기능과 인터넷 연결 관리 기능을 제공해 안정적인 데이터 전송을 가능하게 합니다. 장치를 인터넷에 직접 연결할 수도 있지만, 게이트웨이를 사용하면 연결 효율과 안정성이 크게 향상됩니다.

IoT 데이터 수집은 대개 게이트웨이에서 시작되며, 이후 이벤트 수집 시스템으로 유입된 데이터는 스트림 처리, 저장소 적재, 머신러닝 파이프라인, 분석 및 리포팅 등 다양한 다운스트림 경로로 전달됩니다. 이를 통해 실시간 대시보드, 예측 모델 적용, 사용자 서비스 개선 등 다양한 활용이 가능합니다.

👉 키워드 → IoT / Edge Computing

💬 데이터 메시

데이터 메시(Data Mesh)는 중앙 집중식 데이터 레이크나 데이터 웨어하우스 같은 거대한 모놀리식 데이터 플랫폼과 운영 데이터와 분석 데이터 사이에서 발생하는데이터 격차(Data Gap)를 해결하기 위해 등장한 현대적 데이터 아키텍처 접근 방식입니다. 데이터 메시의 핵심 목표는 중앙 집중형 아키텍처의 한계를 극복하고,분산과 탈중앙화(Decentralization)를 통해 데이터 소유권과 책임을 도메인 단위로 이전하는 것입니다.

데이터 메시에서는 기존처럼 모든 데이터를 중앙 플랫폼으로 모아 관리하는 대신,각 도메인이 소유한 데이터셋을 쉽게 소비할 수 있는 방식으로 호스팅하고 제공하도록 설계합니다. 이를 통해 데이터 소비자는 중앙 레이크에 의존하지 않고도 필요한 데이터를 바로 활용할 수 있으며, 데이터 제공자와 소비자 간의 상호작용이 보다 효율적으로 이루어집니다.

데이터 메시의 핵심 구성 요소는 다음과 같습니다. 첫째, 도메인 지향 분산형 데이터 소유권 및 아키텍처로, 각 도메인이 자신의 데이터에 대한 책임과 권한을 갖습니다. 둘째, 제품으로서의 데이터(Data as a Product) 개념을 적용하여, 데이터셋이 단순한 저장물이 아니라 명확한 소비자를 위한 제품처럼 설계되고 관리됩니다. 셋째, 플랫폼으로서의 셀프서비스 데이터 인프라(Self-serve Data Infrastructure as a Platform)를 제공하여, 도메인이 데이터 파이프라인을 쉽게 구축하고 관리할 수 있도록 지원합니다. 넷째, 통합 컴퓨팅 거버넌스(Integrated Compute Governance)를 통해 분산된 데이터 환경에서도 보안, 규제, 품질을 일관되게 관리할 수 있습니다.

데이터 메시 외에도 데이터 아키텍처에는 데이터 패브릭(Data Fabric),데이터 허브(Data Hub), 확장 아키텍처(Scalable Architecture),메타데이터 우선 아키텍처(Metadata-First Architecture),이벤트 기반 아키텍처(Event-driven Architecture),라이브 데이터 스택(Live Data Stack) 등 다양한 접근 방식이 있으며, 각기 다른 요구와 환경에 맞게 선택될 수 있습니다.

👉 키워드 → Data Mesh / Data Product / Decentralization / Governance / Data Fabric

💬 데이터 엔지니어링의 핵심 목적

데이터 엔지니어링의 핵심 목적은 데이터 수명 주기 전체를 관리하며 데이터를 안전하고 신뢰성 있게 운반하고, 최종 사용자의 요구에 따라 제공할 수 있는 시스템 설계입니다. 이를 달성하기 위해 데이터 아키텍처와 도구를 구분하여 이해하는 것이 중요합니다. 아키텍처는 전략적 관점에서 무엇을, 왜, 언제 구축할지를 결정하며, 도구는 전술적 관점에서 어떻게 구축할지를 결정합니다.

그러나 종종 팀들은 아키텍처 설계보다 기술 선택에 먼저 치우치는 실수를 범합니다. 이는 샤이니 오브젝트 신드롬(shiny object syndrome),이력서 주도(resume-driven) 개발, 아키텍처 전문 지식 부족 등 여러 요인 때문입니다. 특히 소규모 팀이나 경험이 부족한 팀에서는 카고-컬트 엔지니어링(cargo-cult engineering) 현상이 발생하기 쉽습니다. 이는 최신 기술이나 사례를 무작정 모방하다가 시간과 비용만 낭비하고 실제 가치는 거의 얻지 못하는 상황을 의미합니다. 따라서 가능한 한 관리형 도구와 SaaS 기반 도구를 활용해 팀의 제한된 역량을 비즈니스 가치 창출에 집중하는 것이 현명합니다.

팀 구성원의 선호와 역량을 고려한 기술 선택도 중요합니다. 예를 들어, 팀이 로우코드 도구를 선호하는지, 코드 우선 접근 방식을 선호하는지, 특정 언어(Java, Python, Go 등)에 능숙한지 평가하고, 이미 익숙한 기술과 워크플로를 우선 활용하는 것이 바람직합니다. 이를 통해 시장 출시 속도를 높이고, 고품질 표준과 보안을 유지하면서도 기능과 데이터를 신속하게 제공할 수 있습니다.

데이터 엔지니어링에서 중요한 또 다른 원칙은 상호 운용성(interoperability)입니다. 다양한 시스템과 기술이 서로 연결되고 데이터를 교환할 수 있어야 하며, 이를 위해 JDBC, ODBC 같은 표준 연결 방식이 활용됩니다. 그러나 REST API 등 일부 기술은 표준화가 완전히 이루어지지 않았기 때문에, 원활한 통합은 벤더나 오픈 소스 프로젝트의 지원에 달려 있습니다.

비용 측면에서는 총소유비용(TCO),자본적 지출(CAPEX),운영비용(OPEX), 그리고총소유 기회비용(TOCO)를 고려해야 합니다. CAPEX는 초기 투자와 장기적 계획을 반영하며, OPEX는 점진적이고 유연한 운영비용입니다. 클라우드 환경에서는 대부분 OPEX 모델을 따르며,핀옵스(FinOps) 방식을 적용해 시스템을 모니터링하고 동적으로 비용과 가치를 관리함으로써 재무적 책임과 비즈니스 가치를 최적화할 수 있습니다.

결론적으로, 데이터 엔지니어링은 단순히 기술 선택이 아니라전략적 아키텍처 설계와 전술적 도구 선택을 통합하고, 팀 역량과 비용 구조를 고려하며, 시장 요구와 비즈니스 가치를 동시에 충족하는 복합적 과정이라 할 수 있습니다.

👉 키워드 → 데이터 수명 주기 / 아키텍처 vs 도구

💬 불변의 기술 vs 일시적 기술

데이터 엔지니어링에서는 불변의 기술과 일시적 기술을 구분하고, 전략적 의사결정에서 불변의 기술에 집중하는 것이 장기적 안정성과 유지보수 효율을 높이는 핵심입니다.

불변의 기술(immutable technology)은 시간이 지나도 안정적으로 유지되며, 클라우드 환경의 핵심 컴포넌트나 오랜 세월 검증된 언어와 패러다임을 포함합니다. 예를 들어, 객체 스토리지, 네트워킹, 서버, 보안 등이 이에 속합니다. 이러한 기술은 린디 효과(Lindy effect)의 혜택을 받는데, 이는 기술이 이미 확립된 기간이 길수록 앞으로도 오래 지속될 가능성이 높다는 것을 의미합니다.

반면, 일시적 기술(transitory technology)은 등장했다가 단기간 내 사라지거나 다른 기술로 대체되는 경향이 있습니다. 예를 들어, 2010년대 초 하이브(Hive)는 엔지니어와 분석가가 복잡한 맵리듀스 작업을 수동 코딩하지 않고 대규모 데이터를 처리할 수 있도록 빠르게 도입되었으나, 이후 단점을 개선한 프레스토(Presto) 등으로 대체되면서 현재는 주로 레거시 환경에서만 사용됩니다. 대부분의 기술이 필연적으로 이러한 변화와 쇠퇴의 주기를 겪습니다.

따라서 데이터 시스템 설계와 기술 선택 시, 단기적인 유행 기술에 지나치게 의존하기보다는불변의 기술을 중심으로 안정적이고 확장 가능한 아키텍처 구축이 바람직합니다.

👉 키워드 → 불변의 기술 / 일시적 기술 / 린디 효과(Lindy Effect) / 안정적 아키텍처 / 확장 가능성

💬 온프레미스 vs 클라우드 vs 하이브리드 클라우드 vs 멀티 클라우드

온프레미스는 기업이 직접 하드웨어와 소프트웨어를 소유하고 운영하는 방식이고,클라우드는 외부 클라우드 제공업체로부터 인프라와 서비스를 임대하여 유연성과 확장성을 확보하는 방식입니다.하이브리드 클라우드는 온프레미스와 클라우드를 혼합해 각각의 장점을 취하는 접근이며,멀티클라우드는 여러 퍼블릭 클라우드를 동시에 활용해 특정 서비스나 벤더 종속성을 줄이고 최적 조합을 얻는 방식입니다.

각각에 대한 설명을 추가로 드리면,

온프레미스는 기업이 자체 데이터센터나 코로케이션 공간에서 하드웨어와 소프트웨어를 직접 운영하고 관리하는 구조입니다. 이 방식은 보안과 통제가 강력하지만, 장애 발생 시 수리와 교체를 직접 처리해야 하고, 몇 년마다 하드웨어 업그레이드 주기를 관리해야 한다는 부담이 있습니다. 또한 최대 부하를 고려해 과잉 구매를 하거나 반대로 자원이 부족해지는 위험이 존재합니다.

클라우드는 AWS, Azure, GCP 같은 외부 제공업체로부터 서버와 서비스를 임대하는 방식입니다. VM은 1분 이내에 실행할 수 있고 초 단위로 과금되며, 서버리스 서비스는 부하에 따라 자동 확장됩니다. 이를 통해 기업은 초기 하드웨어 투자 비용을 절감하고 빠르게 확장할 수 있습니다. 하지만 기존 시스템을 그대로 옮기는 리프트 앤 시프트 방식으로 장기 실행 서버를 두면 오히려 온프레미스보다 비용이 더 많이 드는 경우가 발생할 수 있습니다. 따라서 클라우드의 가치는 사용 패턴에 맞춘 최적화와 자동 확장, 예약 인스턴스 활용에 있습니다.

하이브리드 클라우드는 온프레미스와 클라우드를 함께 사용하여 워크로드 특성에 따라 배치하는 방식입니다. 예를 들어, 평소에는 온프레미스에서 운영하다가 대규모 데이터 분석이 필요할 때만 클라우드로 확장할 수 있습니다. 데이터가 주로 클라우드로 흘러가고 다시 온프레미스로 가져오는 경우가 적어 이그레스 비용도 줄일 수 있고, 운영 부담 완화에도 도움이 됩니다.

멀티클라우드는 여러 퍼블릭 클라우드에 워크로드를 분산하는 전략입니다. 각 클라우드가 제공하는 최고의 서비스를 조합해 활용할 수 있고 특정 벤더 종속을 피할 수 있습니다. 예를 들면, 금융사는 AWS를 고객 관리·분석 플랫폼에, Azure를 내부 문서 관리 및 Microsoft 365 같은 SaaS 통합에 사용합니다. 지역별 보안 규제와 컴플라이언스가 달라 특정 데이터는 AWS, 다른 워크로드는 Azure로 분산하는 게 합리적이기 때문입니다. 하지만 클라우드 간 네트워킹 병목, 데이터 이동 비용, 운영 복잡성이 커지는 단점도 존재합니다. 이런 문제를 줄이기 위해 여러 클라우드를 단일 창에서 관리하는 차세대 멀티클라우드 플랫폼도 등장하고 있습니다.

👉 키워드 → 온프레미스 / 클라우드 / 하이브리드 클라우드 / 멀티클라우드

💬 구축 vs 구매

구축과 구매의 가장 큰 차이는 통제권과 자원 제약에 있습니다. 구축은 솔루션을 엔드투엔드로 제어할 수 있는 반면, 구매는 제한된 리소스와 전문성을 고려해 빠르고 안정적인 가치를 확보하는 접근 방식입니다. 최종 결정은 TCO, 운영 비용, 그리고 솔루션이 조직에 경쟁 우위를 제공할 수 있는지에 달려 있습니다.

구축을 선택하면 아키텍처와 기능을 원하는 대로 맞춤화할 수 있으며 벤더나 커뮤니티 로드맵에 종속되지 않는 장점이 있습니다. 하지만 전문 지식과 유지 관리 인력이 충분하지 않으면 오히려 비용과 리스크가 증가할 수 있습니다.

반대로 구매는 상용 솔루션이나 관리형 서비스를 활용하는 방식으로, 엔지니어링 역량이 부족하거나 빠른 도입이 필요한 상황에서 효과적입니다. 다만 장기적으로는 벤더 종속성이나 라이선스 비용 문제가 발생할 수 있습니다.

예를 들어 오픈소스를 직접 구축하면 자유롭게 기능을 확장할 수 있지만 버전 관리, 보안 패치, 운영 자동화 등 모든 책임이 내부 팀에 있습니다. 반면 Databricks(스파크)나 Confluent(카프카) 같은 상용 OSS(COSS)를 구매하면 운영 부담을 벤더에게 넘기고 추가 기능도 바로 활용할 수 있습니다.

따라서 중요한 것은 단순히 "구축할 수 있는가"가 아니라,내부 역량과 운영 리소스를 고려했을 때 어떤 선택이 더 높은 ROI를 만들어내는가 입니다.

👉 키워드 → 통제권 / 자원 제약

💬 서버리스 vs 서버

이 두 방식은 클라우드 기반 애플리케이션 운영에서 많이 사용됩니다. 그렇지만 인프라 관리와 비용 모델, 유연성 측면에서근본적인 차이가 있습니다.

서버리스 아키텍처는 개발자와 데이터 엔지니어가 백그라운드에서 서버를 직접 관리하지 않고도 애플리케이션을 실행할 수 있는 구조를 의미합니다. 서버리스에서는 작은 코드 단위를 이벤트에 따라 실행하며, 코드가 호출될 때만 비용이 발생하는 종량제 모델을 사용합니다. 예를 들어 AWS 람다나 구글 빅쿼리는 서버 관리 없이도 자동 확장되며, 데이터 로드와 쿼리 실행만으로 대규모 작업을 처리할 수 있습니다.

서버리스의 장점은 초기 비용이 낮고, 개발자가 인프라 관리에 신경 쓰지 않아도 된다는 점이며, 적절한 사용 사례에서는 빠르게 가치를 제공할 수 있습니다. 하지만 서버리스는 복잡한 워크로드, 장시간 실행, 높은 메모리 요구, 특정 런타임 제약 등에는 적합하지 않을 수 있으며, 이벤트가 많아질수록 비용이 급증할 위험이 있습니다. 또한 VPC 설정이나 맞춤 네트워킹, 사용자 정의 런타임 지원이 제한되는 점도 고려해야 합니다.

반대로 서버 기반 아키텍처는 개발자가 직접 서버를 관리하고 애플리케이션을 배포·운영하는 구조입니다. 서버를 직접 제어하기 때문에 사용자 정의 기능을 설치할 수 있고, 성능·확장성·보안 정책 등을 세밀하게 제어할 수 있습니다. 예를 들어 쿠버네티스 클러스터에서 여러 컨테이너를 운영하며, 필요한 리소스에 따라 수평 확장이나 오토스케일링을 적용할 수 있습니다.

서버 기반 운영은 특히 컴퓨팅 집약적이거나 장시간 실행되는 워크로드에서경제적이고 안정적입니다. 다만, 서버 관리와 유지보수, CI/CD 배포, 보안 패치 등 운영 부담이 서버리스보다 훨씬 높다는 단점이 있습니다.

실제로는 두 방식 사이에 회색지대도 존재합니다. 예를 들어 AWS 파게이트나 구글 앱 엔진은 컨테이너 기반 환경에서 서버 관리 부담을 줄이면서도 서버리스의 편의성을 제공합니다. 이런 방식은 이벤트 기반 실행과 임시 컨테이너 사용을 통해서버리스의 비용 효율성과서버 기반 운영의 유연성을 절충한 형태라고 볼 수 있습니다.

따라서 단순한 이벤트 처리에는 서버리스를, 복잡하고 장기 실행되는 워크로드에는 서버 또는 컨테이너 기반 환경을 선택하는 것이 실무에서 효과적입니다.

👉 키워드 → 서버리스 / 서버

💬 최적화, 성능, 벤치마크 사례

최적화와 성능 평가는 데이터베이스나 빅데이터 시스템을 선택할 때 중요한 기준입니다. 그러나 실제 운영 환경과 동떨어진 벤치마크가 사용되면서 성능 비교가 왜곡되는 사례가 자주 발생합니다.

예를 들어, 벤치마크 전쟁에서는 “페타바이트 규모를 처리한다”는 주장을 하면서도 실제로는 매우 작은 데이터셋으로 성능을 측정하는 일이 흔합니다. 이 경우 데이터가 RAM이나 SSD 캐시에 모두 상주한 상태에서 동일 쿼리를 반복 실행해 비현실적으로 높은 성능을 보여줍니다. 하지만 현실에서는 데이터가 캐시에 전부 들어오지 않으며 다양한 쿼리가 지속적으로 발생하기 때문에 벤치마크 성능과 실제 운영 성능 간에는 큰 차이가 발생합니다.

또한 비용 비교 역시 의미가 왜곡되는 경우가 많습니다. 전통적인 MPP 시스템은 한 번 구축하면 몇 년 동안 계속 실행되는 구조이고 쉽게 생성·삭제하기 어렵습니다. 반면 일부 클라우드 네이티브 DB는 쿼리당 혹은 초 단위 과금 모델을 지원합니다. 이런 시스템들을 단순히 “초당 비용” 기준으로 비교하는 것은 현실적으로 무의미하지만 벤치마크 자료에서는 여전히 흔히 사용되는 방식입니다.

비대칭 최적화 사례도 존재합니다. 일부 벤더는 자사의 행 기반 MPP 시스템이 유리한 정규화 데이터 모델을 벤치마크에 사용합니다. 행 기반 시스템은 이런 모델에서 성능이 잘 나오기 때문입니다. 그러나 열 기반 DB는 스키마 설계나 구체화 뷰 등 추가 튜닝이 필요함에도, 벤더가 경쟁 제품에는 동일한 수준의 최적화를 적용하지 않아 성능 격차를 의도적으로 부각시키기도 합니다.

따라서 벤치마크를 실제 의사결정에 활용하려면 벤더가 제공하는 수치를 그대로 받아들이기보다, 실제 데이터 규모와 쿼리 패턴을 시뮬레이션해 직접 성능과 비용을 검증하는 과정이 중요합니다.

👉 키워드 → 벤치마크 왜곡 / 최적화 편향 / 실사용 검증

💬 기술 선택 관점에서의 DE 수명주기의 드러나지 않는 요소들

데이터 엔지니어링 수명 주기에서 드러나지 않는 요소들은 기술 선택 과정에서 장기적인 안정성과 효율성을 결정하는 핵심 기준입니다. 단순히 성능이나 확장성만 보고 기술을 선택하면 실제 운영 환경에서 규제 준수, 품질 보장, 장애 대응 문제로 인해 더 큰 비용을 치르게 됩니다.

첫 번째로 중요한 요소는 데이터 관리입니다. 데이터 보호 체계, 내부·외부 침해 대응, GDPR·CCPA 같은 규제 준수 여부, 리전별 데이터 호스팅 요구사항을 모두 검토해야 합니다. 예를 들어 유럽 고객 데이터를 처리한다면 GDPR 요건을 충족하는 유럽 리전에 저장해야 합니다. 또한 데이터 품질 관리 체계가 없다면 잘못된 데이터가 파이프라인 전체를 무의미하게 만들 수 있습니다.

두 번째 요소는 데이터 옵스(DataOps)입니다. 새로운 기술 도입 시 배포 제어 수준, 장애 발생 시 알림 체계, 사고 대응 프로세스 성숙도를 반드시 점검해야 합니다. OSS를 사용할 경우 모니터링·호스팅·배포 설정 모두 사용자가 책임지지만, 관리형 서비스를 사용할 경우 SLA·알림·문제 해결 ETA 제공 여부 등을 벤더 기준으로 검증해야 합니다.

마지막 요소는 오케스트레이션 기술입니다. 예를 들어 Airflow는 활발한 커뮤니티와 다양한 관리형 서비스가 존재하는 장점이 있습니다. 그러나 스케줄러나 메타데이터 DB 같은 확장 불가능한 컴포넌트에 의존하기 때문에 병목이 발생할 수 있습니다. 또한 분산형 모놀리스 아키텍처를 따르기 때문에 완전한 확장성을 제공하지 않으며, 스키마 관리·데이터 계보·카탈로그 같은 기능도 기본적으로 지원하지 않습니다.

👉 키워드 → 데이터 관리 / DataOps / 오케스트레이션

💬 일반적으로 데이터는 어떻게 생성되는가

일반적으로 데이터는 현실 세계에서 발생하는 사건과 활동이 기록되거나 변환되는 과정을 통해 생성됩니다. 이는 크게 아날로그 데이터와 디지털 데이터로 구분할 수 있습니다.

먼저 아날로그 데이터는 인간의 언어, 수화, 종이에 적은 글, 악기 연주와 같은 실제 세계에서 자연스럽게 발생하는 데이터입니다. 이런 데이터는 대체로 일시적이며 직접적으로 활용하기 어렵기 때문에 디지털 형식으로 변환해야만 저장·전송·분석이 가능합니다. 예를 들어, 음성을 문자 메시지로 변환하는 모바일 앱은 아날로그 음성을 디지털 텍스트로 바꾸는 대표적인 사례입니다.

반대로 디지털 데이터는 디지털 시스템에서 직접 생성되거나 아날로그 데이터가 변환되어 생성됩니다. 전자상거래 플랫폼에서 발생하는 신용카드 결제 기록, 웹사이트 로그, 모바일 앱 사용 내역 같은 것들이 디지털 데이터의 예입니다. 또한 IoT 센서가 측정한 온도, 주식 거래 플랫폼의 거래 내역, 망원경에서 수집한 천체 관측 정보 등도 모두 디지털 데이터로서, 구조적으로 저장되고 다양한 분석에 활용될 수 있습니다.

즉, 데이터는 아날로그적 현실을 디지털화하거나, 디지털 시스템에서 자동으로 기록되는 과정을 통해 생성되며, 데이터 엔지니어는 이러한 원천 데이터의 생성 방식을 이해하고 특성을 파악해야 이후의 수집·처리·분석 단계를 안정적으로 설계할 수 있습니다.

👉 키워드 → 아날로그 데이터 / 디지털 데이터

💬 정형, 비정형, 반정형 데이터

정형 데이터와 비정형 데이터는 데이터가 저장되는 구조와 활용 방식에서 근본적인 차이가 있습니다.

먼저 정형 데이터는 사전에 정의된 스키마와 고정된 형식을 가지는 데이터입니다. 보통 행과 열의 형태로 구조화되어 있어 데이터베이스나 스프레드시트에서 쉽게 저장, 검색, 분석이 가능합니다. 예를 들어 엑셀(Excel) 파일, CSV 파일은 열과 행이 명확하게 정의되어 있기 때문에 SQL 쿼리와 같은 정형적 질의를 통해 효율적으로 처리할 수 있습니다.

반대로 비정형 데이터는 고정된 스키마나 명확한 구조를 가지지 않는 데이터입니다. 텍스트 문서(TXT), 이미지, 오디오, 동영상 파일처럼 일정한 틀에 맞지 않고 내용이나 형식이 다양하게 변하는 데이터가 여기에 속합니다. 비정형 데이터는 사람에게는 의미 있게 해석될 수 있지만, 기계가 바로 처리하기는 어렵기 때문에 추가적인 전처리, 태깅, 자연어 처리(NLP), 컴퓨터 비전 등의 기술이 필요합니다.

두 방식 사이에는 반정형 데이터라는 회색지대도 존재합니다. 예를 들어 JSON, XML 같은 데이터는 겉으로 보기에는 계층적 구조를 가지며 어느 정도 규칙성을 띠지만, 열과 행으로 완벽히 정형화되지 않아 분석 전에 스키마 정의나 변환 과정이 필요합니다.

👉 키워드 → 정형 / 비정형 / 반정형