우리가 매일 마주하는 대용량 데이터 처리 시스템은 하루아침에 뚝딱 만들어진 게 아닙니다. 인프라의 한계, 폭발하는 비즈니스 요구, 그리고 이를 극복하려는 개발자들의 치열한 삽질과 아키텍처 혁신이 얽히고설킨 한 편의 거대한 서사시죠.
구글의 논문 한 장에서 출발해 AI 시대의 벡터 DB에 이르기까지, 빅데이터 생태계를 뒤흔든 7가지 결정적 터닝 포인트를 순서대로 풀어봅니다.
1. 노란 코끼리의 등장: 분산 처리의 민주화
2000년대 초, 전 세계 웹페이지를 긁어모으던 구글은 거대한 벽에 부딪혔습니다. “이 무지막지한 데이터를 어디에 저장하고, 어떻게 계산하지?”
구글이 찾아낸 답은 비싼 슈퍼컴퓨터가 아니었습니다. 값싼 일반 서버(Commodity Hardware) 수천 대를 묶어 함께 굴리는 것이었습니다. 그 설계 원리를 정리해 2003~2004년에 세상에 공개한 것이 GFS(Google File System)와 MapReduce 논문입니다.
문제는 구글이 논문만 냈을 뿐, 소스코드는 꽁꽁 숨겨뒀다는 것. 이때 등장한 인물이 더그 커팅(Doug Cutting)입니다. Yahoo!의 전폭적인 지원을 받아 이 논문을 바탕으로 오픈소스 프레임워크를 직접 구현해 냈고, 그것이 바로 하둡(Hadoop) 입니다.
노란 코끼리의 이름은 어디서 왔을까
‘하둡’이라는 이름과 노란 코끼리 마스코트는 더그 커팅의 어린 아들이 가지고 놀던 장난감 코끼리 인형에서 유래했습니다. 만약 하둡이 독점 상용 솔루션으로 출시됐다면, 지금의 빅데이터 생태계는 거대 테크 기업들의 전유물이 됐을지도 모릅니다.
하둡은 대규모 분산 처리를 모두의 기술로 만든 민주화의 상징이었습니다. 야후, 페이스북, 링크드인 같은 기업들이 앞다투어 하둡 클러스터를 구축하기 시작했고, 빅데이터라는 단어 자체가 세상에 퍼져나갔습니다.
2. NoSQL의 습격: RDBMS로는 더 이상 버틸 수 없다
하둡이 디스크 기반 대규모 배치(Batch) 처리 문제를 해결하는 동안, 2010년 전후로 스마트폰과 SNS가 폭발하면서 전혀 다른 종류의 문제가 터졌습니다.
“초당 수십만 건씩 쏟아지는 실시간 데이터를 어떻게 바로 읽고 쓸 것인가?”
전통적인 RDBMS(관계형 데이터베이스)는 데이터 무결성을 지키기 위해 단일 서버를 전제로 설계됩니다. 서버를 늘려가며 처리량을 키우는 수평 확장(Scale-out)이 구조적으로 불가능합니다.
여기서 데이터베이스 세계의 대전환이 일어납니다. “완벽한 데이터 일관성(Consistency)을 포기하더라도, 일단 서버를 늘려서 터지지 않게 만들자!” 데이터의 스키마(Schema, 틀)를 과감히 없앤 NoSQL(Not Only SQL) 이 쏟아져 나왔습니다.
- HBase: 구글의 Bigtable 논문을 기반으로 한 하둡 진영의 컬럼형 저장소
- Cassandra: 아마존의 Dynamo 구조를 따른, 쓰기 성능에 극도로 최적화된 DB
- MongoDB: 개발자 친화적인 문서(Document) 기반 DB, 스타트업의 선택지
데이터 레이어는 바야흐로 춘추전국시대를 맞이했습니다.
NoSQL이 등장한 배경에는 CAP 이론이 있습니다. “분산 시스템에서 일관성(Consistency), 가용성(Availability), 분단 내성(Partition Tolerance) 세 가지를 동시에 완벽히 만족하기란 불가능하다”는 이론으로, NoSQL은 일관성을 일부 희생해 가용성과 확장성을 얻는 쪽을 선택했습니다.
3. SQL의 화려한 귀환: 코끼리에 날개를 달다
하둡이 널리 퍼졌는데 문제가 하나 있었습니다. 하둡으로 데이터 분석을 하려면 자바(Java) 코드를 수백 줄씩 짜야 했습니다. 데이터 분석가들은 절규했습니다.
“우리는 SQL밖에 모르는데, 이 복잡한 코딩을 매번 해야 한다고?”
이 절망 속에서 페이스북(현 Meta)이 구원투수로 등판합니다. SQL을 작성하면 하둡의 MapReduce 코드로 자동 변환해주는 Hive(하이브) 를 오픈소스로 공개한 것입니다.
Hive와 함께 데이터의 구조 정보를 모아 관리하는 Metastore(메타스토어) 개념도 정립됩니다. 파일 덩어리에 불과하던 하둡이 비로소 거대한 ‘데이터웨어하우스’의 면모를 갖추기 시작했습니다.
하지만 Hive도 내부적으로는 MapReduce를 거치기 때문에 속도가 느렸습니다. “MapReduce 없이 메모리를 활용해 즉시 SQL 질의를 할 수 없을까?” 이 고민에서 나온 것이 클라우데라(Cloudera)의 Impala(임팔라) 와 페이스북의 Presto(프레스토) 입니다. 고성능 대화형(Interactive) 분산 SQL 엔진의 등장으로, 빅데이터 분석 속도는 비로소 실용적인 수준으로 빨라졌습니다.
4. 디스크에서 메모리로: Apache Spark의 시대
하둡은 훌륭했지만 치명적인 약점이 있었습니다. 연산 중간 결과를 반드시 하드디스크에 쓰고 읽어야(Disk I/O) 했기 때문에, 반복 연산이 많은 머신러닝 작업 등에서 속도가 처참했습니다.
2014년 등장한 Apache Spark(아파치 스파크) 는 모든 중간 연산 결과를 메모리 위에서 처리하는 In-Memory 컴퓨팅을 들고나와, MapReduce 대비 최대 100배 빠른 속도를 증명했습니다.
더 중요한 건 범용성이었습니다. SQL 질의, 스트리밍 처리, 머신러닝(MLlib), 그래프 분석을 하나의 프레임워크에서 모두 처리할 수 있었습니다. 언어도 Scala, Python, Java, R을 지원했고요.
스파크가 하둡을 대체한 것은 아닙니다
정확히는 스파크가 MapReduce 엔진을 대체했습니다. 스파크 자체가 처음에는 HDFS(하둡 파일 시스템) 위에서 돌아갔습니다. 하둡의 저장 계층은 살아있었고, 느린 처리 엔진만 교체된 것입니다. 이 구분이 다음 챕터로 이어집니다.
스파크는 단숨에 빅데이터 분산 처리의 절대 강자로 자리잡았고, 스칼라(Scala)를 데이터 엔지니어링의 핵심 언어로 끌어올리는 데도 결정적 역할을 했습니다.
5. 클라우드의 습격: 스토리지와 컴퓨팅의 결별
초기 하둡의 철칙은 Data Locality, 즉 “네트워크가 느리니, 데이터가 저장된 바로 그 서버에서 연산도 함께 돌린다”는 것이었습니다. 데이터를 옮기는 것보다 코드를 옮기는 게 낫다는 발상이었죠.
그런데 AWS, GCP 같은 클라우드 인프라가 급속도로 발전하고 네트워크 대역폭이 비약적으로 늘어나면서, 이 공식이 흔들리기 시작했습니다.
기업들은 비싸고 관리가 까다로운 HDFS를 걷어내고, 사실상 무제한으로 저렴하게 저장할 수 있는 클라우드 오브젝트 스토리지(AWS S3, GCS 등) 에 데이터를 전부 던져놓기 시작했습니다. 그리고 분석이 필요할 때만 컴퓨팅 클러스터(Spark, Kubernetes 등)를 띄워 연산한 뒤 꺼버리는 구조가 됐습니다.
| 항목 | 기존 하둡 | 클라우드 시대 |
|---|---|---|
| 저장소 | HDFS (온프레미스) | S3, GCS (오브젝트 스토리지) |
| 컴퓨팅 | 상시 가동 클러스터 | 필요 시 On-demand 기동 |
| 비용 구조 | 고정 인프라 비용 | 사용한 만큼 과금 |
| 확장성 | 노드 증설 필요 | 스토리지·컴퓨팅 독립 확장 |
이 ‘Storage & Compute 분리’ 아키텍처가 현대 데이터 엔지니어링의 표준으로 자리잡았습니다. 하둡 전문 기업이었던 클라우데라(Cloudera)와 호튼웍스(Hortonworks)가 합병 후에도 고전을 면치 못한 이유이기도 합니다.
6. 레이크하우스 전쟁: Delta Lake vs Apache Iceberg
S3 같은 데이터 레이크(Data Lake)에 대용량 파일을 저장하는 건 좋았는데, 새로운 문제가 수면 위로 떠올랐습니다. RDBMS에서는 당연한 기능들이 없었습니다.
- 특정 행(Row)을 수정(Update)하거나 삭제(Delete)할 수 없음
- 여러 작업이 동시에 일어날 때 데이터가 꼬임 (ACID 트랜잭션 미지원)
- 실수로 잘못된 데이터를 덮어썼을 때 되돌릴 수 없음
이를 해결하기 위해 데이터 레이크의 유연함과 데이터웨어하우스(DW)의 꼼꼼한 관리 기능을 결합한 데이터 레이크하우스(Data Lakehouse) 개념이 탄생합니다. 파일 위에 일종의 ‘가상 SQL 테이블 레이어’를 올려, ACID 트랜잭션과 타임트래블(Time Travel, 과거 상태 조회) 기능 등을 구현한 것입니다.
현재 이 시장은 두 강자가 맞붙고 있습니다.
- Delta Lake: 스파크의 대부 Databricks가 주도. Spark와 긴밀하게 통합.
- Apache Iceberg: 넷플릭스(Netflix)에서 시작해 Snowflake, AWS, Google 등의 지지를 받으며 사실상 오픈소스 표준으로 부상 중.
테이블 포맷 삼국지
실제로는 Delta Lake, Apache Iceberg 외에 Hudi(후디, Uber에서 시작)까지 3파전 구도입니다. 다만 현재 커뮤니티 모멘텀과 업계 지지도를 보면 Iceberg가 오픈소스 표준으로 자리잡는 흐름이 뚜렷합니다.
7. AI 시대: 분산 처리의 새로운 프론티어
이제는 AI와 LLM(대규모 언어 모델, Large Language Model)의 시대입니다.
과거의 빅데이터가 텍스트, 로그, 정형 테이블에서 패턴을 찾는 것이었다면, 지금의 빅데이터는 이미지, 오디오, 고차원 텍스트를 컴퓨터가 이해하는 숫자의 배열 — 임베딩 벡터(Embedding Vector) — 로 변환해 처리해야 합니다.
문제는 기존 스파크나 분산 SQL 엔진으로는 수억 개의 벡터 중에서 유사한 것을 초고속으로 찾는 ANN(Approximate Nearest Neighbor) 검색을 효율적으로 처리하기 어렵다는 것입니다.
이에 따라 Pinecone, Milvus, Qdrant 같은 벡터 데이터베이스(Vector DB)가 빅데이터 생태계의 새로운 주인공으로 급부상하고 있습니다.
역사는 반복됩니다. 구글이 논문을 냈을 때 하둡이 등장했듯, LLM이 세상을 바꾸고 있는 지금, AI 인프라를 지탱할 새로운 분산 처리 시스템이 또 한 번 역사를 새로 쓰고 있습니다.
빅데이터 15년의 흐름
| 시대 | 핵심 기술 | 해결한 문제 |
|---|---|---|
| ~2008 | Hadoop (HDFS + MapReduce) | 대용량 데이터 저장 & 배치 처리 |
| ~2012 | HBase, Cassandra, MongoDB | 실시간 읽기/쓰기, 수평 확장 |
| ~2014 | Hive, Presto, Impala | SQL로 빅데이터 분석 |
| ~2016 | Apache Spark | 빠른 인메모리 처리, 범용 엔진 |
| ~2019 | S3 + 클라우드 | Storage/Compute 분리, 비용 효율화 |
| ~2022 | Delta Lake, Iceberg | 레이크하우스, ACID 트랜잭션 |
| 2024~ | Vector DB, AI 파이프라인 | 임베딩 검색, LLM 인프라 |
빅데이터의 역사는 결국 “비즈니스가 요구하는 데이터의 스케일을, 엔지니어들이 아키텍처로 깨부수며 버텨온 투쟁의 역사” 입니다.
다음 패러다임은 또 어떤 기술이 우리를 흔들어 놓을지, 그게 기대되면서도 조금은 두렵습니다.