빅데이터 (Big Data)

#개념

빅데이터(Big Data)는 기존의 관계형 데이터베이스(Database)와 단일 서버 중심의 처리 도구로는 합리적인 시간과 비용 안에 수집·저장·처리·분석하기 어려운 데이터, 그리고 이를 다루기 위해 등장한 분산 저장·처리 기술과 방법론을 포괄하는 용어다. 빅데이터를 설명하는 가장 널리 알려진 틀은 2001년 META Group(현 Gartner)의 Doug Laney가 제시한 3V로, 다음 세 축으로 데이터 관리의 어려움을 정의했다.

빅데이터의 3V

규모(Volume): 테라바이트에서 페타바이트 이상으로 커진 데이터 양을 뜻한다.
속도(Velocity): 클릭 로그나 센서 데이터처럼 실시간에 가깝게 끊임없이 생성되는 특성을 뜻한다.
다양성(Variety): 정형 테이블뿐 아니라 JSON·로그·텍스트·이미지·영상 같은 반정형·비정형 데이터가 섞여 있음을 뜻한다.

이후 데이터의 신뢰성과 불확실성을 뜻하는 정확성(Veracity)과 데이터로부터 끌어낼 수 있는 비즈니스 가치(Value)가 더해져 5V로 확장되었으며, 이는 빅데이터의 핵심이 단순히 많은 데이터를 쌓는 것이 아니라 품질이 보장된 데이터에서 가치를 만들어내는 데 있음을 강조한다.

빅데이터라는 개념이 등장한 배경에는 2000년대 초 웹 검색, 전자상거래, 소셜 미디어의 급성장으로 데이터 생성량이 폭증했지만, 고가의 전용 하드웨어를 더 큰 장비로 교체하는 수직 확장(Scale-up) 방식으로는 비용과 물리적 한계에 부딪혔다는 사정이 있다. 그 해법으로 값싼 범용 서버 수천 대를 묶어 처리 능력을 늘리는 수평 확장(Scale-out)이 채택되었고, 이것이 빅데이터 기술의 출발점이 되었다.

수평 확장을 실용화한 결정적 계기는 Google이 발표한 두 편의 논문이다. Ghemawat 등(2003)의 Google File System(GFS)은 파일을 64MB 크기의 청크(chunk)로 나누어 여러 서버에 복제 저장하고, 단일 마스터가 메타데이터만 관리하면서 장비 고장을 예외가 아닌 일상으로 전제하여 자동 복구하는 분산 파일 시스템을 제시했다.

Dean과 Ghemawat(2004)의 MapReduce는 입력을 키-값 쌍으로 변환하는 Map 함수와 같은 키의 값을 모아 집계하는 Reduce 함수만 작성하면 데이터 분할, 작업 스케줄링, 장애 복구, 노드 간 통신을 프레임워크가 처리하는 프로그래밍 모델로, 분산 시스템 전문 지식이 없는 개발자도 수천 대의 클러스터를 활용할 수 있게 했다.

이 두 논문을 오픈소스로 구현한 것이 Apache Hadoop이며, 분산 파일 시스템 HDFS(Hadoop Distributed File System)와 MapReduce 실행 엔진, 그리고 클러스터 자원을 관리하는 YARN(Yet Another Resource Negotiator)으로 구성된다. HDFS는 데이터를 블록 단위로 쪼개 기본 3중 복제하여 저장하고, 계산을 데이터가 있는 노드로 보내는 데이터 지역성(data locality)을 활용하여 네트워크 병목을 줄인다. Hadoop 위에서는 SQL과 유사한 질의를 MapReduce로 변환하는 Hive, 스크립트 언어 Pig, 열 지향 저장소 HBase 같은 생태계가 형성되었다.

그러나 MapReduce는 각 단계의 중간 결과를 디스크에 기록하기 때문에 반복 연산이 많은 머신러닝(Machine Learning)이나 대화형 분석에는 느리다는 한계가 있었다. Zaharia 등(2012)이 제안한 Apache Spark는 탄력적 분산 데이터셋(Resilient Distributed Dataset, RDD)이라는 추상화를 통해 데이터를 메모리에 유지한 채 변환 연산의 계보(lineage)를 기록하고, 장애 시 계보를 따라 손실된 파티션만 재계산하는 방식으로 내결함성과 속도를 동시에 확보했다.

Spark는 이후 DataFrame과 Spark SQL, 스트리밍(Structured Streaming), 머신러닝 라이브러리(MLlib), 그래프 처리를 하나의 엔진으로 통합하여 사실상 빅데이터 처리의 표준 엔진이 되었다.

처리 방식의 관점에서 빅데이터 워크로드는 배치 처리(Batch Processing)와 스트림 처리(Stream Processing)로 나뉜다. 배치 처리는 일정 기간 쌓인 데이터를 한꺼번에 읽어 처리하는 방식으로 처리량이 높고 구현이 단순하지만 결과가 나오기까지 수십 분에서 수 시간이 걸린다. 스트림 처리는 데이터가 도착하는 즉시 레코드 단위 또는 작은 윈도 단위로 처리하여 초 이하의 지연 시간(Latency)으로 결과를 내는 방식이다.

스트리밍 아키텍처의 중심에는 Apache Kafka 같은 분산 메시지 브로커가 있다. Kafka는 이벤트를 토픽(topic)이라는 추가 전용(append-only) 로그에 파티션 단위로 분산 저장하고, 생산자(producer)와 소비자(consumer)를 분리하여 여러 시스템이 같은 이벤트 스트림을 독립적으로 읽을 수 있게 하며, 데이터를 일정 기간 보존하므로 장애 시 재처리가 가능하다.

Apache Flink는 이벤트 시간(event time) 기반 윈도 연산, 워터마크(watermark)를 통한 지연 도착 데이터 처리, 분산 스냅샷에 기반한 정확히 한 번(exactly-once) 상태 일관성 보장을 제공하는 스트림 처리 엔진으로, 배치를 유한한 스트림의 특수한 경우로 다루는 통합 모델을 지향한다. 과거에는 정확한 배치 결과와 빠른 스트리밍 결과를 별도의 경로로 계산해 합치는 람다 아키텍처(Lambda Architecture)가 사용되었지만, 동일한 로직을 두 번 구현해야 하는 부담 때문에 하나의 스트림 처리 엔진으로 두 요구를 모두 충족하는 카파 아키텍처(Kappa Architecture)가 대안으로 제시되었다.

저장 계층에서는 클라우드의 등장과 함께 큰 변화가 일어났다. HDFS는 저장과 계산이 같은 서버에 결합되어 있어 둘을 독립적으로 확장하기 어려웠지만, Amazon S3, Google Cloud Storage, Azure Blob Storage 같은 클라우드 오브젝트 스토리지(Cloud Object Storage)는 사실상 무제한의 용량을 저렴한 비용으로 제공하면서 계산 자원과 분리된 저장·계산 분리(Separation of Storage and Compute) 구조를 가능하게 했다. 이러한 저장소에 원시 데이터를 형태에 관계없이 그대로 적재해 두고 필요할 때 스키마를 적용하는 읽기 시점 스키마(Schema-on-Read) 방식의 저장소가 데이터 레이크(Data Lake)다.

데이터 레이크는 유연하지만 트랜잭션과 스키마 강제가 없어 품질이 관리되지 않은 데이터가 쌓이는 "데이터 늪(data swamp)"이 되기 쉬웠고, 분석을 위해서는 다시 데이터 웨어하우스(Data Warehouse)로 복사해야 하는 이중 구조가 문제였다. 이를 해결하기 위해 Armbrust 등(2021)이 정식화한 레이크하우스(Lakehouse)는 오브젝트 스토리지 위의 개방형 파일 포맷에 ACID 트랜잭션, 스키마 강제, 시간 여행(time travel), 인덱싱 같은 웨어하우스의 관리 기능을 더한 아키텍처로, Delta Lake, Apache Iceberg, Apache Hudi 같은 오픈 테이블 포맷(Open Table Format)이 이를 구현한다.

파일 수준에서는 열 지향 포맷(Columnar Format)인 Apache Parquet가 표준으로 자리 잡았다. Parquet는 데이터를 행 그룹(row group)으로 나눈 뒤 각 열을 열 청크(column chunk)로 연속 저장하여, 분석 질의가 필요한 열만 읽을 수 있게 하고(projection pushdown), 열마다 최솟값·최댓값 통계를 저장하여 조건에 맞지 않는 행 그룹을 건너뛰며(predicate pushdown), 같은 열의 값은 유사하므로 사전 인코딩과 런렝스 인코딩, 압축 효율이 높다. Avro는 반대로 행 지향 포맷으로 레코드 단위 쓰기와 메시지 전송에 적합하다.

데이터 구조가 시간에 따라 바뀌는 스키마 진화(Schema Evolution)도 중요한 문제다. Parquet와 Avro는 열 추가와 기본값 지정, 열 이름 변경에 대한 규칙을 정의하고, 테이블 포맷은 메타데이터 수준에서 스키마 버전을 관리하여 과거 파일을 다시 쓰지 않고도 새 스키마로 읽을 수 있게 한다. 반정형 데이터의 스키마를 관리하기 위해 Kafka와 함께 스키마 레지스트리(Schema Registry)를 두고 호환성 규칙(전방·후방·완전 호환)을 강제하는 관행도 널리 쓰인다.

빅데이터의 규모가 커질수록 데이터 거버넌스(Data Governance)와 프라이버시의 중요성도 커진다. 수백 개의 테이블과 수천 개의 파이프라인이 얽힌 환경에서는 어떤 데이터가 어디서 왔고 누가 사용하는지를 추적하는 데이터 리니지(Data Lineage), 데이터의 의미와 소유자를 기록하는 데이터 카탈로그, 품질 검증, 접근 권한 관리가 없으면 데이터를 신뢰할 수 없게 된다.

개인정보 측면에서는 유럽의 GDPR과 한국의 개인정보 보호법처럼 수집 목적 제한, 삭제 요구권, 국외 이전 제한을 규정하는 법규가 빅데이터 시스템 설계에 직접 영향을 미친다. 추가 전용 로그와 불변 파일로 구성된 빅데이터 저장소에서 특정 개인의 데이터만 삭제하는 것은 기술적으로 까다롭기 때문에 다음과 같은 기법이 사용된다.

프라이버시 보호 기법

가명처리와 익명처리: 개인을 직접 식별할 수 없도록 데이터를 가공한다.
암호 삭제(crypto-shredding): 개인 식별 정보를 분리하여 암호화하고 키를 폐기하면 데이터가 무의미해지도록 한다.
차분 프라이버시(Differential Privacy): 집계 결과에 통계적 잡음을 더해 개인을 식별할 수 없게 한다.
접근 제어와 동적 마스킹: 열·행 수준 접근 제어와 동적 마스킹으로 노출을 제한한다.

데이터 수집 단계에서부터 보존 기간과 삭제 정책을 설계에 포함하는 프라이버시 중심 설계(privacy by design)가 요구된다.

"빅데이터"라는 용어는 2010년대 초반 Hadoop 생태계와 함께 산업계의 핵심 유행어였으나, 기술이 보편화되면서 이제는 특정 기술을 가리키는 말이라기보다 데이터 엔지니어링의 전제 조건이 되었다.

오늘날에는 클라우드 데이터 웨어하우스(Snowflake, BigQuery, Redshift)와 레이크하우스, 추출-적재 후 변환하는 ELT 패턴, SQL 기반 변환 도구(dbt), 워크플로 오케스트레이션(Airflow), 데이터 카탈로그와 관측성(observability) 도구가 결합된 현대 데이터 스택(Modern Data Stack)이 빅데이터 처리의 일반적인 형태이며, Hadoop 클러스터를 직접 운영하는 대신 관리형 서비스 위에서 Spark나 SQL 엔진(Trino, Presto)으로 오브젝트 스토리지의 Parquet 파일을 질의하는 방식이 주류가 되었다.

동시에 빅데이터는 딥러닝(Deep Learning)과 대규모 언어 모델(Large Language Models, LLM)의 토대로서 새로운 의미를 얻었다. 수조 개의 토큰에 이르는 웹 말뭉치, 수십억 장의 이미지-텍스트 쌍을 수집·중복 제거·필터링·토큰화하는 과정 자체가 대규모 분산 데이터 처리이며, 학습 데이터의 품질과 출처 관리, 저작권과 개인정보 문제는 거버넌스의 연장선에 있다.

또한 데이터 파이프라인(Data Pipeline)이 만든 특징을 피처 스토어(Feature Store)에 적재하고 모델 학습과 서빙에 공급하는 MLOps 체계는 빅데이터 인프라 없이는 성립하지 않는다. 결론적으로 빅데이터는 분산 저장과 병렬 처리라는 기술적 토대 위에서 배치와 스트리밍, 레이크와 웨어하우스의 경계가 허물어지며 진화해 왔으며, 현재는 데이터 플랫폼과 AI 시스템을 떠받치는 기반 기술로 자리 잡았다.

#관련 용어

데이터 레이크

원시 데이터를 형태에 관계없이 저렴한 저장소에 그대로 적재하고 읽는 시점에 스키마를 적용하는 대규모 저장소

데이터 웨어하우스

분석 질의에 최적화된 구조로 정제된 데이터를 통합 저장하는 시스템

데이터 파이프라인

데이터를 수집·변환·적재하여 분석과 모델 학습에 공급하는 자동화된 처리 흐름

ETL

원천 시스템에서 데이터를 추출하고 변환하여 목적지 저장소에 적재하는 과정

데이터 거버넌스

데이터의 품질·보안·접근 권한·리니지를 조직 차원에서 관리하는 체계

데이터베이스

데이터를 구조화하여 저장하고 질의·갱신할 수 있게 하는 관리 시스템

#직무 연관도

Data Analyst보통

데이터 웨어하우스와 레이크하우스에 적재된 대규모 데이터를 SQL로 질의하고, 데이터의 출처와 품질을 이해하는 데 필요한 배경 지식

Data Scientist높음

대규모 학습 데이터를 Spark 등으로 전처리·탐색하고, 분산 환경에서 특징을 계산하며 모델 학습 데이터셋을 구성하는 데 필수적인 기반 지식

Data Engineer밀접

분산 저장소와 처리 엔진, 배치·스트리밍 파이프라인, 레이크하우스와 파일 포맷을 선택하고 운영하는 핵심 영역

#사용 사례

인터넷 서비스전자상거래금융통신제조의료미디어

개요

빅데이터 기술은 사용자 행동 로그 분석, 추천과 검색 랭킹, 실시간 이상 거래 탐지, 통신망 품질 모니터링, 제조 설비 센서 데이터 기반 예지 정비, 유전체·의료 영상 분석, 그리고 대규모 언어 모델의 학습 데이터 구축에 이르기까지 대량의 데이터를 수집·저장·처리해야 하는 모든 영역에 적용된다.

사례

전자상거래 플랫폼에서 하루 수십억 건의 클릭·검색·구매 이벤트가 Kafka로 수집되면, Flink가 실시간으로 집계하여 인기 상품 순위와 이상 거래 경보를 갱신하고, 같은 이벤트가 오브젝트 스토리지에 Parquet 파일로 적재되어 Spark 배치 작업이 매일 새벽 추천 모델 학습용 특징과 매출 리포트를 생성한다. 분석가는 레이크하우스 테이블을 SQL로 직접 질의하고, 개인정보 열은 접근 권한에 따라 마스킹되어 제공된다.