블록, 파일, 객체 — 스토리지 3종류를 제대로 이해하기

이 글은 AWS S3, MinIO등의 스토리지 서비스를 학습하기 전 선행 지식을 정리한 시리즈 1편입니다. RDB/NoSQL은 써봤지만 "스토리지"라는 단어가 생소하게 느껴져 학습한 내용을 정리한 글입니다.

---

"모든 데이터는 결국 0과 1의 조각"

우리가 사진을 저장하거나 코드를 커밋할 때, 데이터는 어디로 갈까요? HDD나 SSD 같은 물리적 장치는 오직 '블록(Block)'이라는 단위로만 데이터를 인식합니다. 하지만 우리는 "몇 번 블록을 읽어줘"라고 하지 않고 "보고서.docx를 열어줘"라고 말합니다.

이 간극을 메워주는 것이 바로 스토리지 기술입니다.

AWS S3나 MinIO와 같은 서비스는 "객체 스토리지"기반으로 이루어져 있습니다.

본 글은 데이터 저장의 가장 밑바닥인 스토리지의 세가지 종류에 대해 다룹니다.

 

---

스토리지(Storage)

• RDB(MySQL), NoSQL(MongoDB) 등을 사용해봤다면, 데이터를 "저장한다"는 개념은 익숙할 것
• 그러나 스토리지(Storage) 는 다른 관점에서 데이터를 다룸

RDB, NoSQL과 Storage의 차이

구분	RDB, NoSQL	Storage
저장 목적	구조를 파악하고, 내용 기반으로 조회/가공	데이터 자체를 있는 그대로 보관/전달
내용 기반 조회	가능 (SQL, Query, Index)	불가능 (Key 기반 접근만 가능)
저장 대상	숫자, 문자열, 문서 등 구조화된 데이터	이미지, 동영상, 로그, 바이너리 등
수정 단위	특정 컬럼/필드 단위 수정 가능	파일 통째로 덮어쓰기만 가능

• RDB, NoSQL: 데이터의 구조를 파악하고 저장하기 때문에, 내용을 기반으로 조회/가공이 가능
• Storage: 데이터를 구조 파악 없이 있는 그대로 저장. Key 기반으로만 접근 가능하며, 파일 보관/전달이 목적

둘은 경쟁 관계가 아니라 항상 같이 쓰는 관계
예: 게시판 서비스에서 게시글 텍스트는 DB에, 첨부 이미지는 Storage에 저장

---

스토리지의 3가지 종류

"데이터를 어떤 방식으로 관리할 것이냐"에 따라 세 가지로 나뉨

모든 스토리지의 물리적 기반은 블록 스토리지이며, 그 위에 어떤 소프트웨어(엔진)를 올리느냐에 따라 방식이 결정됨

블록 스토리지 (물리 계층)
        ↓
어떤 엔진을 올리냐?
        ├── 파일 시스템 (ext4, NTFS 등)  →  파일 스토리지
        └── 객체 엔진 (MinIO, Ceph 등)   →  객체 스토리지

 

1️⃣블록 스토리지 (Block Storage) - 직접 관리

• 구조: 애플리케이션 ↔ 파일 시스템(NTFS/EXT4) ↔ 블록 스토리지
• 개념: 데이터를 고정된 크기의 블록(Block) 단위로 저장하는 가장 하위 계층
• 특징:
  • 파일 시스템이나 객체 엔진이 그 위에 올라가는 물리적 기반
  • 로컬 디스크(SSD/HDD)뿐만 아니라, 네트워크로 연결되지만 블록처럼 동작하는 원격 스토리지도 포함 (예: AWS EBS)
  • OS나 애플리케이션이 직접 블록 단위로 접근
• 사용 예: 서버에 직접 붙은 디스크, AWS EBS

---

2️⃣파일 스토리지 (File Storage) - 네트워크 공유

• 구조: 애플리케이션 ↔ 네트워크 프로토콜(NFS/SMB) ↔ [원격 서버: 파일 시스템 ↔ 블록 스토리지]
• 개념: 파일 시스템이 올라간 서버의 저장 공간을 네트워크를 통해 공유해서 쓰는 방식
• 특징:
  • 파일 시스템은 내 컴퓨터가 아닌 원격 서버에서 실행됨
  • 디렉토리/파일의 계층 구조(트리 구조)로 데이터 관리
  • 여러 서버가 동일한 스토리지를 동시에 마운트해서 사용 가능
• 사용 예: NAS, AWS EFS

---

3️⃣객체 스토리지 (Object Storage) - API 기반 확장

• 구조: 애플리케이션 ↔ HTTP API (S3/MinIO) ↔ 객체 엔진 ↔ 블록 스토리지
• 개념: 파일 시스템이라는 개념 자체를 버리고, HTTP API와 Key로 데이터를 주고받는 방식
• 특징:
  • 폴더 계층 구조 없음. 모든 데이터는 평면(Flat) 구조로 저장
  • 파일 경로처럼 보이는 A/B/file.txt도 실제로는 하나의 문자열 Key에 불과함
  • 대규모 비정형 데이터(이미지, 동영상, 로그 등) 처리에 최적
• 사용 예: AWS S3, MinIO, Google Cloud Storage

---

블록 스토리지 접근 방식 - 파일 시스템과 객체 엔진

위 구조에서 보면 블록 스토리지를 직접적으로 컨택하는 것은 파일 시스템 혹은 객체 엔진이라는 것을 알 수 있음.
차이는 블록 스토리지 위에서 데이터를 어떤 구조로 관리하느냐.

가장 큰 차이는 데이터를 찾는 방식에 있음

• 파일 시스템: 경로를 따라 탐색 (지도를 보고 길을 찾아가는 방식)
• 객체 엔진: Key로 즉시 검색 (고유 번호로 바로 찾는 방식)

 

파일 시스템 (File System) - 계층형 관리 방식

• 데이터를 계층(Hierarchy) 구조로 관리
• 저장 시점에 이미 경로가 결정됨

저장 구조:

• 데이터 블록: 실제 파일 내용을 쪼개어 저장
• 아이노드(inode): 파일의 메타데이터(크기, 생성일 등)와 데이터가 저장된 블록 번호 목록을 보유
• 디렉토리(Directory) 파일: [파일명 - 아이노드 번호] 가 적힌 주소록 파일. 파일 시스템에서 폴더의 실체

조회 방식 (Traversal — 경로 탐색):

• /A/B/file.txt를 찾으려면 root → A 주소록 → B 주소록 순서로 실제 파일을 하나씩 열어보며 경로를 추적
• 마지막에 찾은 아이노드 정보를 기반으로 블록 스토리지에서 데이터를 가져옴

각각의 파일은 모두 아이노드를 가지며, 폴더도 하나의 파일로 취급

/root
  └── A/          ← 주소록 파일 (A 아이노드 번호 포함)
        └── B/    ← 주소록 파일 (B 아이노드 번호 포함)
              └── file.txt  ← 실제 데이터 블록

 

파일 시스템 - 아이노드(inode)

아이노드 구조

• 모든 파일/폴더는 위와 같은 아이노드라고 부르는 정보를 가지고 있음.
• 파일 시스템 포맷(생성) 시점에 하드디스크의 일정 영역을 아이노드 테이블 영역으로 따로 빼놓고 사용.

---

파일 아이노드 vs 폴더 아이노드

• 파일과 폴더의 차이는 데이터 블록에 들어가는 데이터
• 파일의 경우 실제 데이터가 있는 디스크의 주소
• 폴더의 경우 파일 - 아이노드 번호 쌍

모든 조회는 루트(/)에서 시작하며, 파일 시스템의 루트 아이노드 번호는 #2라는 상수를 사용.
경로만 주어지면 파일을 조회할 수 있는 이유는 루트 경로의 아이노드 번호가 고정되어 있기 때문.

---

객체 엔진 (Object Engine) - 평면형 관리 방식

• 계층 구조를 버리고, 모든 데이터를 대등한 위치에 두는 평면(Flat) 구조 ※다른 말로 Logical Hierarchy라고도 부름.
• 저장 시점에 전체 경로 이름을 Key로 등록

저장 구조:

• 데이터 객체: 파일 내용과 메타데이터를 하나로 묶어 저장
• Key(ID): A/B/file.txt 전체 경로 문자열 자체가 하나의 고유 식별자
• 인덱스 DB: 내부적으로 Key-Value Store를 보유. Key를 주면 데이터 위치를 즉시 반환

조회 방식 (Lookup — Key 검색):

• A/B/file.txt를 요청하면 중간 폴더 A, B를 거치지 않음
• 엔진이 인덱스 DB에서 A/B/file.txt라는 Key 자체를 검색하여 위치를 즉시 반환

[인덱스 DB]
"A/B/file.txt"   →  블록 위치 0x00FF
"C/data.csv"     →  블록 위치 0x04AB
"image.png"      →  블록 위치 0x09CC

파일 시스템처럼 경로 깊이에 따른 체이닝이 없어,
경로 깊이와 무관하게 단일 조회로 처리 가능!

---

최종 정리

구분	블록 스토리지	파일 스토리지	객체 스토리지
엔진	없음 (raw)	파일 시스템 (ext4, NTFS)	객체 엔진 (MinIO, Ceph)
접근 방식	블록 단위 직접	경로 탐색 (계층)	Key 검색 (평면)
프로토콜	없음	POSIX, NFS, SMB	HTTP (PUT/GET/DELETE)
사용 예	AWS EBS, 로컬 디스크	NAS, AWS EFS	AWS S3, MinIO

 

모든 데이터의 물리적 기반은 블록 스토리지이며, 그 위에 어떤 소프트웨어를 두느냐에 따라 방식이 나뉜다.

1. 전통적인 방식은 파일 시스템(NTFS/EXT4) 이 블록을 관리하고
2. 이를 네트워크로 공유해서 쓰면 파일 스토리지(NFS/SMB) 가 되며
3. 파일 시스템을 거치지 않고 API로 관리하면 객체 스토리지(S3/MinIO) 가 된다