안녕하세요 엔지니어 창비입니다.
오늘은 하둡에 대해서 알려드릴께요
오늘은 빅데이터 하면 절대 빠질 수 없는 핵심 기술, 하둡(Hadoop)에 대해 가볍게 정리해 보려고 합니다.
하둡은 한 문장으로 간단하게 요약할 수 있습니다.
"데이터를 여러 서버에 저장하고, 여러 서버에서 읽어와 처리한다."
오늘은 복잡한 디테일보다 전체적인 흐름과 핵심 개념 위주로 살펴보겠습니다.
1. 하둡의 탄생배경
하둡의 직접적인 기원은 구글이 발표한 두 개의 논문, GFS(Google File System)와 MapReduce에서 출발합니다.
- GFS: 수천 대의 일반 서버에 데이터를 '분산 저장'하는 시스템입니다. 하드웨어 장애를 특별한 예외가 아니라 '언제든 일어날 수 있는 일상'으로 전제하고 설계했다는 점이 당시로선 아주 혁신적이었습니다.
- MapReduce: 이렇게 여러 서버에 분산된 대규모 데이터를 동시에 '분산 처리(연산)'하는 프레임워크입니다.
당시 더그 커팅(Doug Cutting)과 마이클 카파렐라(Mike Cafarella)는 오픈소스 웹 검색엔진인 '너치(Nutch)'를 개발하고 있었습니다. 전 세계 웹페이지를 크롤링하고 인덱싱하려다 보니, 단일 머신으로는 도저히 감당할 수 없는 스토리지와 연산 장벽에 부딪힌 상태였죠.
때마침 구글의 논문을 접한 두 사람은 이를 기반으로 직접 구현에 착수합니다.
초기에는 너치 프로젝트 내부의 서브 시스템인 NDFS(Nutch Distributed File System) 형태로 시작되었습니다.
그러다 2006년, 더그 커팅이 야후(Yahoo)에 합류하면서 이 분산 저장·처리 부문이 독립 프로젝트로 분리되었고, 그것이 바로 지금의 하둡(Hadoop)이 됩니다. (하둡이라는 이름은 더그 커팅의 아들이 가지고 놀던 노란색 코끼리 인형 이름에서 따왔다는 유명한 일화가 있죠.)
하둡의 핵심 철학은 명확합니다.
"비싼 고성능 서버 한 대를 쓰느니, 값싼 범용 서버 수천 대를 묶어서 쓰자"는 것. 그리고 네트워크로 대용량 데이터를 이동시키는 비용을 아끼기 위해 "연산(코드)을 데이터가 있는 서버로 보낸다(Data Locality)"는 발상입니다. 이 직관적인 아이디어가 빅데이터 시대의 서막을 열었습니다.
2. 하둡의 핵심 구성 요소와 역할
- HDFS (Hadoop Distributed File System)
- 파일을 저장할 때 '블록(Block)'이라는 큰 단위(기본 128MB)로 쪼개어 여러 서버에 나누어 저장합니다.
- 기본적으로 3 Copy(3중 복제) 설정을 주로 사용합니다. 똑같은 블록 복사본을 서로 다른 3대의 서버에 흩어놓는 방식이죠. 덕분에 서버 한두 대가 동시에 고장 나더라도 데이터 유실 없이 안전하게 시스템을 유지할 수 있습니다.
- YARN (Yet Another Resource Negotiator)
- 하둡 클러스터의 '자원 관리자이자 스케줄러'입니다.
- 수많은 서버가 묶여 있는 환경에서는 "어느 서버의 CPU와 메모리가 여유 있는지", "지금 들어온 작업을 어떤 서버에 배정해야 효율적일지"를 통제하는 중앙 관리자가 필수적입니다. YARN이 바로 그 역할을 맡아 클러스터 전체의 자원을 효율적으로 분배해 줍니다.
- MapReduce (맵리듀스)
- YARN이 나눠준 자원을 바탕으로, 데이터를 실제로 '분산 처리(연산)'하는 프레임워크입니다.
- 작업을 잘게 쪼개는 Map(맵) 단계와, 쪼개서 처리한 결과물을 다시 하나로 모으는 Reduce(리듀스) 단계로 나뉩니다.
- 예를 들어 10억 줄짜리 문서에서 단어 개수를 센다면, 서버 100대에 1,000만 줄씩 보내서 동시에 단어를 세게 한 뒤(Map), 그 결과만 한곳에 모아서 더하는(Reduce) 방식입니다. 앞서 언급한 'Data Locality(데이터가 있는 곳으로 연산을 보낸다)' 철학이 실제로 구현되는 핵심 메커니즘입니다.
3. 현재 하둡의 입지와 스토리지 트렌드
최근 인프라 트렌드를 보면 하둡(Hadoop)은 사실상 신규 도입이 거의 없는 레거시 단계로 들어선 게 맞습니다. 하지만 필드에서 완전히 지워진 건 아닌데, 현재 시장 구조를 크게 3가지 줄기로 요약해 볼 수 있습니다.
① 레거시로써 하둡
새로운 프로젝트의 아키텍처로 하둡을 선택하는 경우는 이제 거의 없습니다. 분석의 중심축은 이미 Spark, Trino, 그리고 현대적인 레이크하우스(Databricks 등)로 넘어갔기 때문이죠. 다만, 글로벌 통계를 보면 하둡 인프라의 약 60~62%는 여전히 온프레미스(On-Premise) 환경에 묶여 있습니다. 금융권이나 공공, 대기업처럼 데이터 주권(Data Sovereignty)과 보안 규제가 까다로운 곳들이 기존에 구축해 둔 수십~수백 페타바이트(PB) 규모의 HDFS 클러스터를 여전히 '운영 유지 및 점진적 이관(Modernization)' 형태로 들고 가고 있기 때문입니다.
② 고성능 AI/실시간 연산을 위한 Block Storage
전체 클라우드 스토리지 시장에서 매출 비중으로만 보면 블록 스토리지(EBS, NVMe 가상화 볼륨 등)가 약 68% 이상으로 여전히 가장 큰 파이를 차지합니다. 하지만 이걸 과거 하둡처럼 대용량 데이터 적재용 저장소로 쓰진 않습니다. 최근 트렌드는 AI/ML 모델 학습, LLM 서빙, 실시간 분산 DB 처리처럼 초고성능 IOPS와 극도의 저지연(Low-latency)이 필수적인 연산 전용 스토리지로 역할이 압축되고 있습니다.
③ 대형 데이터 레이크의 표준이 된 Object Storage
과거 HDFS가 담당하던 대용량 분산 저장의 지위는 완전히 오브젝트 스토리지(S3, MinIO 등)로 대체되었습니다. 매년 14~16%씩 가파르게 성장하는 영역이기도 합니다. 하둡 구조의 고질적 문제였던 '스토리지 늘릴 때 연산 노드도 같이 사야 하는 비효율'을 해결하기 위해, 시장은 Compute(연산)와 Storage(저장)를 완벽히 분리(Decoupling)하는 방향으로 정착했습니다. 비용이 저렴한 오브젝트 스토리지에 데이터를 다 던져두고, Iceberg나 Delta Lake 같은 오픈 테이블 포맷을 얹어서 Hive 카탈로그를 대체하는 방식이 현재 모던 데이터 아키텍처의 표준이 되었습니다.
4. 한 눈에 보는 아키텍처 요약 비교
- 과거 (Hadoop HDFS 구조)
- Storage + Compute 결합형 ➔ 데이터 위치 기반 연산(Data Locality)은 좋았으나 스토리지 확장 시 비용 부담이 같이 커지고, 3 Copy 복제로 인한 공간 낭비가 심함.
- 현재 (Modern Cloud-Native 구조)
- Storage(Object Storage) + Compute(Spark/Trino 등) 분리형 ➔ 무제한에 가까운 비용 효율적 저장이 가능하며, 필요할 때만 연산 자원(쿠버네티스 등)을 유연하게 띄워서 계산.
🌐 참고 자료 (References)
- 하둡 시장 및 온프레미스 비중 데이터: Mordor Intelligence / Coherent Market Insights (2026) 기준, 기존 글로벌 하둡 인프라의 온프레미스 잔존 점유율 약 60~62% 선 유지 및 점진적 클라우드 이관 추세 분석 참고.
- 블록 스토리지 비중 데이터: Precedence Research / Research and Markets (2026) 보고서 내 가상화 및 초고성능 AI/DB 워크로드용 매출 포지션(약 68%) 및 연평균 성장률 데이터 참고.
- 오브젝트 스토리지 트렌드: The Business Research Company (2026) 클라우드 오브젝트 스토리지 글로벌 마켓 리포트의 Compute-Storage 분리 아키텍처 전환 동향 참고.