스토리지의 양대 산맥: HDFS와 S3를 비교해봅니다.

과거 On-premise 환경에서는 Hadoop 생태계의 HDFS(Hadoop Distributed File System)가 절대적인 표준이었습니다. 하지만 Cloud Native 환경과 Modern Data Stack이 발전하면서 현재는 Amazon S3와 같은 Object Storage가 대세로 자리 잡았습니다.

오늘 포스팅에서는 두 스토리지의 근본적인 아키텍처 차이부터 데이터 수정 방식, Network I/O의 딜레마, 그리고 데이터를 완벽하게 보호하는 Fault Tolerance 메커니즘까지 모두 종합하여 파헤쳐 보겠습니다.

1. Storage Paradigm: Hierarchical vs. Flat Namespace

두 스토리지의 가장 큰 차이는 데이터를 구조화하고 식별하는 방식에 있습니다.

HDFS: Hierarchical Directory Structure

HDFS는 우리가 흔히 쓰는 Linux File System과 동일한 Hierarchical(계층형) 구조를 가집니다. 디렉토리를 만들고 그 안에 파일을 넣는 방식입니다. 큰 파일은 보통 128MB 크기의 Block 단위로 쪼개져 여러 대의 서버(DataNode)에 분산 저장됩니다.

S3: Flat Namespace와 Key

반면 S3는 Object Storage입니다. S3에 저장되는 object key를 보면 logs/2026/02/21/app.log 처럼 폴더 구조가 있는 것 같지만, 이는 시각적인 렌더링에 불과합니다. 실제 S3 내부는 디렉토리 개념이 없는 완벽한 Flat Namespace입니다.

💡 기술적 차이: Metadata Bottleneck과 Namespace 구조

파일이 수억 개 이상으로 늘어나는 Big Data 환경에서 스토리지를 평가할 때, 가장 눈여겨봐야 할 기술적 차이는 Namespace 구조에 따른 Metadata 처리 방식입니다.

• HDFS (Hierarchical Tree의 한계): HDFS는 전통적인 파일 시스템처럼 디렉토리 기반의 Tree 구조를 가집니다. 따라서 특정 파일에 접근하려면 마스터 서버(NameNode)가 Root 디렉토리부터 하위 폴더들을 순차적으로 타고 내려가며(Traversal) 권한과 위치를 확인해야 합니다. 파일 개수가 수억 개로 급증하면 이 Tree를 순회하고 관리하는 메타데이터 연산 자체가 엄청난 Bottleneck(병목)을 유발하며, NameNode의 메모리 한계가 곧 클러스터 전체의 용량 한계가 됩니다.

• S3 (Flat Namespace와 $O(1)$ 접근): 반면 S3는 디렉토리라는 개념 자체가 없는 평면적인(Flat) 구조의 Object Storage입니다. logs/2026/02/21/app.log 처럼 폴더 경로처럼 보이는 전체 문자열은 사실 경로가 아니라, 그 자체로 단일하고 고유한 Key(식별자)에 불과합니다. S3는 디렉토리를 순회할 필요 없이 이 Key 값을 통해 Hash Table처럼 Object의 물리적 위치에 $O(1)$ 시간 복잡도로 직접 접근합니다. 이 덕분에 단일 마스터 노드의 병목 없이, 무한에 가까운 극단적인 Scale-out 환경을 안정적으로 지원할 수 있습니다.

2. Data Update Mechanism: Append-only vs Immutable

데이터를 어떻게 수정하고 갱신하는지도 아키텍처 선택에 큰 영향을 미칩니다.

HDFS (Append-only)

• 한 번 쓰인 데이터의 중간을 수정(Update)할 수 없습니다. 파일의 끝에 새로운 데이터를 이어 쓰는 Append-only 연산만 지원합니다.

• 구체적인 예시: Debezium 같은 CDC 툴로 RDBMS의 변경 사항을 캡처할 때, user_id: 1의 이름이 “A”에서 “B”로 바뀌면 기존 “A”를 찾아 덮어쓰지 않습니다. 파일 맨 끝에 {"user_id": 1, "name": "B", "op": "update"} 로그를 추가(Append)합니다. 이후 연산 엔진(Spark, Flink 등)이 최신 Timestamp를 기준으로 최종 상태를 병합(Merge)합니다.

S3 (Immutable)

• 데이터가 아예 불변(Immutable)합니다. 데이터의 일부만 수정하는 것은 불가능하며, 수정이 필요하면 전체 Object를 새로운 데이터로 덮어씌워야(Overwrite) 합니다.

3. Data Locality와 Network I/O의 딜레마

성능에 가장 큰 영향을 미치는 것은 데이터와 컴퓨팅 리소스의 물리적 위치입니다.

HDFS의 무기: Data Locality

HDFS는 Coupled(결합된) 아키텍처입니다. Spark Executor가 연산을 수행할 때, 자신이 떠 있는 바로 그 서버의 로컬 디스크에서 데이터를 직접 읽습니다. 이 Data Locality 덕분에 Network를 타지 않고 순수 Disk I/O만 발생하여 속도가 매우 빠릅니다.

S3의 문제점: Network I/O

S3는 Separation of Compute and Storage(컴퓨팅과 스토리지의 분리) 아키텍처입니다. Spark가 S3에 있는 데이터를 읽으려면 반드시 REST API를 통해 네트워크를 타고 패킷을 다운로드해야 하는 Network I/O가 발생합니다.

On-premise S3를 구축한다면?

사내 망에 MinIO 같은 오픈소스로 S3를 직접 구축하면 AWS를 쓸 때보다 Latency는 대폭 줄어듭니다. 하지만 Compute 노드와 Storage 노드가 물리적으로 분리되어 있다는 사실은 변하지 않습니다. 초고속 Local Switch 망을 타야 하므로, 태생적인 Network Overhead는 여전히 존재합니다.

그럼에도 S3 구조를 선택하는 이유

현대의 100GbE 네트워크 대역폭은 일반적인 SSD의 Disk I/O 속도를 추월했습니다. Network Overhead가 예전만큼 치명적인 Bottleneck이 아니기 때문에, Compute와 Storage를 분리하여 필요한 리소스만 독립적으로 Scale-out 하는 유연성과 비용 효율성을 취하는 것이 실무적으로 압도적인 이득입니다.

4. Fault Tolerance: 3-way Replication vs Erasure Coding

서버에 불이 나거나 디스크가 파괴되는 “완전 손실” 상황에서 두 스토리지는 어떻게 데이터를 복구할까요?

HDFS: 3-way Replication

HDFS는 데이터 Block 하나를 서로 다른 3대의 DataNode에 똑같이 복사해 둡니다.

• 복구 방식: 특정 DataNode가 완전히 파괴되어 데이터가 손실되어도, 다른 노드에 똑같은 데이터가 살아있습니다. 살아있는 노드에서 새로운 노드로 데이터를 단순히 네트워크 복사(Copy)하면 복구가 끝납니다.
• 단점: Storage Overhead가 300%입니다. 1PB의 데이터를 저장하려면 3PB의 물리적 디스크가 필요할 정도로 극도로 비효율적입니다.

S3: Erasure Coding

Erasure Coding(EC)은 데이터를 $k$개의 Data Chunk로 쪼개고, 복구를 위한 $m$개의 Parity Chunk를 수학적으로 계산해 냅니다. 총 $n$ ($n = k + m$)개의 Chunk를 서로 다른 노드에 분산 저장합니다.

• 복구 방식: 특정 노드에 벼락이 떨어져 원본 Data Chunk가 완전히 손실되더라도 복구가 가능합니다. 살아남은 Data Chunk와 Parity Chunk 중 어떤 종류든 상관없이 $k$개만 온전히 살아있다면, 행렬 역연산을 통해 소실된 원본 데이터를 100% 완벽하게 재구성(Reconstruct)해 냅니다.
• 장점: Storage Overhead가 4+2 구성 기준 150% 수준으로 매우 낮습니다. 적은 디스크 용량으로도 HDFS 이상의 내결함성(Fault Tolerance)을 제공합니다. (단, 복구 시 CPU 연산 비용이 발생합니다.)

5. Modern Data Ecosystem: dbt와 S3의 만남

현재 실무에서 S3가 사실상 표준(De facto standard)으로 자리 잡은 이유는 생태계의 완벽한 지원 덕분입니다. HDFS는 유지보수 리소스가 엄청나게 드는 반면, S3는 Fully Managed 서비스이기 때문입니다.

특히 최근 Modern Data Stack의 핵심인 dbt(data build tool)를 보면 이를 명확히 알 수 있습니다. 과거에는 S3 데이터를 분석하려면 Data Warehouse로 복사(Load)해야 했지만, 지금은 dbt-spark, dbt-athena 등을 통해 S3를 First-class citizen(일급 시민)으로 대우합니다. 데이터 이동 없이 S3 raw 버킷을 직접 소스로 매핑하고, SQL 변환 결과를 다시 S3 위에 Apache Iceberg나 Parquet 포맷으로 직접 Materialize(구체화) 할 수 있습니다.

6. Summary: 실무 아키텍처의 최종 선택

비교 항목 (Category)	HDFS (Hadoop Distributed File System)	S3 (Object Storage)
Namespace (구조)	Hierarchical Tree (계층형 디렉토리 구조)	Flat Namespace (Key 기반 $O(1)$ 직접 접근)
Data Update (수정)	Append-only (데이터 이어쓰기만 가능)	Immutable (데이터 불변, 전체 덮어쓰기 필요)
Architecture (설계)	Coupled (Compute와 Storage 결합, Data Locality 활용)	Separated (Compute와 Storage 분리, 독립적 Scale-out)
I/O Type (입출력)	Disk I/O (로컬 디스크 직접 접근)	Network I/O (HTTP REST API를 통한 네트워크 통신)
Fault Tolerance (복구)	3-way Replication (단순 복사, Storage Overhead 300%)	Erasure Coding (수학적 복원, Storage Overhead 약 150%)
Best Use Case (추천)	기존 On-premise 환경, 극단적인 Low Latency가 필요한 Batch	현대적인 Data Lake 구축, Cloud Native 및 dbt 기반 파이프라인

결론

이미 거대한 On-premise 인프라를 운영 중이고 초고속 로컬 I/O가 필수적인 특수 환경이 아니라면, 확장성, 비용, 생태계 호환성을 모두 갖춘 S3 기반의 Separation Architecture를 채택하는 것이 현대 데이터 플랫폼 설계의 Best Practice입니다.