[Part1 기본 개념 3편] 스토리지 종류와 선택 기준 - Block, File, Object

들어가며: 다양한 스토리지 종류와 선택

Front, Backend 등의 Application 개발만 하다가 클라우드 설계/구현을 하다보면 선택 기준이 모호한 부분 중 하나가 스토리지입니다. AWS를 포함한 CSP(Cloud Service Provider)는 다양한 스토리지 옵션을 제공합니다. 아마 많은 서비스에서 S3(Simple Storage Service)를 사용하면 요구사항을 대부분 만족하긴 합니다만, 각 스토리지 서비스들의 특징을 알고 있어야 새로운 워크로드를 제대로 설계할 수 있습니다.

스토리지 서비스를 모두 외우고 있을 필요는 없습니다. 스토리지 서비스 의사 결정 시에는 Block,File,Object 의 차이만 이해하고 있으면 됩니다. AWS의 EBS, EFS, S3는 각각의 구현체일 뿐이고, 다른 서비스들은 이 셋의 변형이거나 아예 특수 목적으로 만들어진 서비스입니다.

그런데 왜 하필 세 종류일까요? 결국 데이터는 어딘가의 SSD에 적히는데 말이죠. 답은 클라우드가 아니라 운영체제 설계에 있습니다. 우리가 쓰는 open(), read(), write() 같은 시스템 콜이 보장하는 계약을 "분산 환경에서 어디까지 지킬 것인가"의 선택이 셋을 갈라놓았습니다.

이 글을 다 읽었을 때 POSIX 인터페이스 기반으로 각 클라우드 스토리지의 특징을 이해하고 운영 서비스에 어떤 스토리지를 써야 할지 결정할 수 있는 안목이 기를 수 있습니다.

POSIX

POSIX(Portable Operating System Interface)란

POSIX 는 IEEE가 1988년부터 정한 운영체제 표준 인터페이스를 말합니다. 이름만 보면 어려워보이는데, 사실 파일 읽기/쓰기 관련 구현을 해보셨다면 이미 쓰고 계셨던 인터페이스입니다.

1with open("data.txt", "r") as f:
2	content = f.read()
Copy

위 코드는 Python으로 파일을 읽을 때 사용하는 코드 예시입니다. 여기서 Python의 open()함수는 내부적으로 운영체제의 open()시스템 콜(system call: 사용자 프로그램이 커널에게 요청하는 함수)을 호출합니다. 이 시스템 콜의 이름과 매개변수, 동작 방식이 POSIX표준에 정의돼있습니다.
Java의 FileInputStream, Go의 os.Open, NodeJS의 fs.open이 사용하는 방식은 약간의 차이가 있지만 모두 POSIX open() 위에서 돌아가고 있습니다.

POSIX는 파일과 디렉터리, 프로세스, 시그널 등 OS의 거의 대부분을 정의했습니다. 하지만 이번 포스팅에서는 "파일과 디렉터리"와 관련된 부분만 살펴보겠습니다.

POSIX가 보장하는 것

리눅스에서 파일을 다룰 때 코드를 살펴보겠습니다.

1int fd = open("/data/users.db", O_RDWR);
2lseek(fd, 4096, SEEK_SET);     // 파일 중간으로 이동
3write(fd, buffer, 512);        // 512 바이트만 덮어쓰기
4fsync(fd);                     // 디스크에 강제 반영
5close(fd);
Copy

이 코드는 운영체제와 파일시스템이 매우 정교한 보장을 요구하고 있습니다. POSIX 시맨틱이 정의하는 수 많은 동작들 중 핵심을 추리면 다음과 같습니다.

1. 계층적 네임스페이스: /data/users.db같은 경로 트리 - 디렉터리, 하위 디렉터리, 파일 등
2. 부분 수정(in-place modification): 파일 중간에 1바이트만 바꿀 수 있음
3. 임의 접근(random access): lseek로 어디든 이동해서 읽고 쓸 수 있음
4. 메타데이터: 권한, 소유자, mtime, ctime - stat() 으로 즉시 조회
5. 락(lock): flock(), fcntl()로 두 프로세스가 같은 파일을 안정하게 수정
6. 원자성(atomic rename): rename()은 같은 파일 시스템 안에서 원자적으로 동작
7. 일관성: 한 프로세스가 쓴 직후 다른 프로세스가 같은 영역을 읽은 바뀐 값이 보임

이러한 보장들은 1개의 컴퓨터에서는 비교적 지키기가 쉽습니다. 하지만 컴퓨터가 여러 대로 늘어나면 이 보장을 지키는 비용이 갑자기 비싸지고, 이 때문에 글 서두에 언급했던 "분산 환경에서 어디까지 지킬 것인가"에 대한 고민이 발생합니다.

분산 환경에서 POSIX 보장 비용

서버가 100대이고, 각 서버가 같은 파일 시스템을 공유한다고 가정해보겠습니다. 이 상황에서 POSIX 시맨틱을 보장하기 위해 생각해야하는 지점들이 다음과 같습니다.

- 서버 A가 파일의 중간 부분을 4096바이트 수저 중일때, 서버 B가 같은 영역을 읽는다면? -> 어딘가에서 락이 필요함
- 폴더에 1억 개 파일이 있을 때 ls 를 실행한다면? -> 분산된 메타데이터 서버에서 이 정보를 모두 모아야 함
- 서버 50개에 걸쳐 디렉터리가 분산돼 있다면? -> 분산 트랙잭션이 필요함
- 어느 서버에서 쓴 데이터가 즉시 모든 서버에 반영되어야 한다면? -> 동기 복제 고려

여기서 분산 시스템 이론의 CAP 정리(Consistency, Availability, Partition tolerance 중 2개만 만족)가 등장합니다. POSIX 시맨틱을 그대로 유지하려면 강한 일관성과 락이 필요한데, 분산 환경에서는 이 둘이 가용성·확장성에 한계를 가져옵니다.

그래서 클라우드 스토리지는 "어떤 부분을 얼마나 포기할 것인가" 에 따라 3가지로 분리했습니다.

Block, File, Object

아래의 레이어를 알고 있으면 각 스토리지의 차이를 쉽게 이해할 수 있습니다.

1┌─────────────────────────────────────────────────┐
2│              사용자 애플리케이션                     │
3└─────────────────────────────────────────────────┘
4        │  open / read / write / seek (POSIX)      
5        ▼                                          
6┌─────────────────────────────────────────────────┐
7│        파일시스템 레이어 (ext4, xfs, NFS 등)         │
8│         inode, dentry, journal, page cache      │
9└─────────────────────────────────────────────────┘
10        │  블록 I/O (블록 번호 + 오프셋)           
11        ▼                                          
12┌─────────────────────────────────────────────────┐
13│       블록 디바이스 (/dev/sda1, /dev/xvdf)         │
14└─────────────────────────────────────────────────┘
15        │                                          
16        ▼                                          
17┌─────────────────────────────────────────────────┐
18│           물리 스토리지 (디스크 / SSD)               │
19└─────────────────────────────────────────────────┘
Copy

클라우드에서 Block, File, Object 의 차이는 어느 층을 네트워크로 빼는가 의 차이입니다. Block -> File -> Object 로 갈수록 분산 친화적이지만 그만큼 POSIX 계약을 포기한다는 것이 핵심입니다.

Block 스토리지 - "디스크만 빌려주기"

- 가장 아래층(블록 디바이스)을 네트워크로 노출
- 클라이언트(EC2)는 이걸 일반 디스크처럼 생각하고, 자기가 직접 파일시스템을 만들어서 사용
- POSIX 시맨틱은 클라이언트 OS가 책임짐 -> 강한 일관성(Consistency), 모든 syscall 지원
- 만약 파일시스템이 클러스터링이 안 돼있으면 여러 서버가 동시에 마운트하기 어려움
- AWS EBS, GCP Persistent Disk, Azure Manged Disk

File 스토리지 - "파일시스템째로 공유하기"

- 파일시스템 레이어를 네트워크 너머에 두고 (NFS, SMB), 여러 클라이언트가 같이 마운트
- POSIX 시맨틱을 약하게 유지 (락, 캐시 일관성에 제약이 있음)
- 여러 서버가 동시에 같은 파일을 읽고 쓸 수 있음
- AWS EFS, GCP Filestore, Azure Files

Object 스토리지 - "POSIX를 포기한다"

- 파일시스템 자체를 쓰지 않고, HTTP API + key-value 모델을 사용
- 부분 수정이 없고 객체 전체를 덮어씀
- 디렉터리가 없음 (key 안에 / 가 있을 뿐이지, 진짜 트리와는 다름)
- 락이 없고, 원자성(atomic rename)이 없음
- 무한에 가까운 확장성, 11 nines durability, 글로벌 접근이 가능함
- AWS S3, GCP Cloud Storage, Azure Blob Storage

EBS, EFS, S3

AWS에서 Block,File,Object 를 각각 어떤 서비스로 제공하는지, 어떤 워크로드에 사용해야 하는지 살펴보겠습니다. 핵심만 알고 싶은 분들은 아래의 표를 참고해주세요.

EBS - 하드 디스크의 클라우드 버전 (Block)

EBS (Elastic Block Store) 는 한마디로 정리하면 EC2에서 사용하는 가상 하드디스크입니다. 그래서 EC2의 OS안에서 확인할 수 있습니다. OS에서 dev/xvdf같은 블록 디바이스로 인식이 되고, mkfs로 파일시스템을 만들어 mount하면 사용할 수 있습니다.

EBS 특징

적합한 워크로드

- DB 데이터 디렉터리: DB데이터의 경우 부분 수정, fsync 등 POSIX를 기반함
- OS 부트 디스크: EC2의 root volume
- 트랜잭션 로그: WAL, redo log 같이 sequential write가 핵심인 파일들
- 단일 인스턴스가 단독으로 쓰는 데이터

EFS - 여러 컴퓨터가 같이 쓰는 파일 시스템 (File)

EBS의 분산 환경에서 "여러 인스턴스가 동시에 못 쓴다"는 한계점을 가지고 있습니다. 이 한계 때문에 EBS는 다음과 같은 요구사항을 만족시키기 어렵습니다.
- 여러 웹 서버가 같은 업로드 폴더를 공유해야 한다. (CMS, 워드프레스 등)
- CI 빌드 서버 N대가 같은 cache 디렉터리를 봐야한다.
- ML 학습 노드 여러 대가 같은 데이터셋을 마운트해서 사용한다.

이 문제를 해결하고자 등장하는 것이 NFSv4 프로토콜 기반의 매니저드 네트워크 파일시스템인 EFS입니다.

EFS 특징

적합한 워크로드

- 앱의 공유 디렉터리: 워드프레스 wp-content, Drupal site/default/files 등
- 사용자 홈 디렉터리 공유: 다중 SSH 게이트웨이, JupyterHub 등
- CI 캐시, 빌드 산출물 공유
- 컨테이너 task 가 공유하는 read-mostly 데이터셋

NFS(Network File System)의 한계

얼핏 보면 EFS는 EBS대비 만능처럼 보입니다. POSIX를 호환하지만, 분산 환경에서는 아직도 한계점이 존재합니다.

- 락: NFSv4는 byte-range lock 을 지원하지만 latency가 단일 디스크 대비 훨씬 큼
- 캐시 일관성: 클라이언트마다 page cache가 따로 있기 때문에 close-to-open consistency 정도만 보장함
- 메타데이터 비용: ls로 큰 디렉터리를 조회하면 모든 inode를 네트워크로 가져오기 때문에 매우 느림

S3 - 단순함의 극단. 객체 스토리지의 등장

공식적인 통계를 찾아본 건 아니지만 AWS에서 가장 사랑받는 서비스는 S3라는 생각을 할 정도로 많은 편의성과 기능을 제공하는 AWS 대표서비스입니다. 2026년 기준으로 S3는 AI시대에 발맞춰 많은 편의 기능이 추가되어왔고, 추가되고 있습니다. 이번 포스팅은 기본 개념만 다루기 때문에 다양한 기능은 차후 포스팅에서 다뤄보겠습니다.

현대 웹이 발전하면서 웹 규모(web scale)의 데이터를 다룰 때 POSIX 시맨틱이 문제가 되었습니다. EBS, EFS도 결국 파일시스템 기반으로 동작하기 때문에 web scale 데이터를 다루기엔 적합하지 않았습니다.

예를 들어 사진 1조장을 저장한다고 가정해보겠습니다.
- 디렉터리 트리에 1조개 inode 가 있다면? -> 메타데이터 서버 폭발
- 사진 1장 부분 수정한다면? -> 사진은 immutable 한 경우가 대부분이기 때문에 새 버전을 올림
- 이미지 수정 시 누군가 락 걸일이 없기 때문에 파일 락이 굳이 필요하진 않음
- 이름 변경 시에 새 키로 PUT 하고 기존 거를 DELETE 하면 되기 때문에 원자적 rename 이 필요없음

이러한 배경 때문에 POSIX 계약을 대부분 버린 S3(Simple Storage Service)가 등장하게됐습니다.

S3의 데이터 모델과 연산

1[Bucket]                    ← 글로벌 유니크 이름
2   └── Object Key (/와 함께 쓸 수 있지만 진짜 디렉터리는 아님)
3         ├── Object Body   (최대 5 TB)
4         ├── Metadata      (HTTP 헤더 + 사용자 정의)
5         └── Version ID    (versioning 활성화 시)
Copy

연산도 위 표에 나왔있는 것처럼 5개가 전부라고 봐도 무방합니다. 부분 쓰기 (offset 기반 update)는 없습니다. 즉, 100GB 객체의 1바이트만 바꾸려면 100GB 전체를 다시 PUT 해야하는 구조입니다.

S3의 장점

- 내구성 (durability): 99.999999999% (소위 "11 nines"). 객체 1천만 개를 1만 년 보관해도 평균 1개 잃을 확률
- 가용성 (availability): Standard 클래스 99.99%
- 단일 객체 최대 크기: 5 TB (단, 단일 PUT은 5 GB까지. 그 이상은 multipart upload)
- 확장성: 단일 prefix당 초당 3,500 PUT/COPY/POST/DELETE, 5,500 GET/HEAD. 대신 prefix를 잘 분배하면 거의 무한 스케일
- 강한 일관성 (strong consistency): 2020년 12월 업데이트 이후로 read-after-write, list-after-write 모두 강한 일관성을 가짐. 간혹 과거 글 중에 "S3는 eventual consistency"라고 명시되어 있는 경우가 있는데 이는 모두 옛날 얘기입니다.

적합한 워크로드

- 정적 에셋: 이미지, 비디오, JS/CSS. CloudFront와 짝궁
- 백업, 스냅샷: EBS 스냅샷, RDS 백업, 로그 아카이브
- 데이터 레이크: Athena/Spark/EMR이 직접 S3를 쿼리
- 로그/이벤트 저장: CloudTrail, ALB access log.
- ML 데이터셋, 모델 파일.
- 소프트웨어 배포 산출물: 컨테이너 이미지의 레이어 (ECR도 내부적으로 S3).

Storage Class

S3는 객체별로 storage class를 지정할 수 있습니다. class별로 비용이 다르기 때문에 표의 액세스 패턴을 참고해 선택하시면 됩니다.

Under the Hood

S3가 부분 수정이 안 되는 이유

S3는 POSIX를 포기하고 11 nines를 얻었습니다. 이게 가능했던 메커니즘은 다음과 같습니다.

1PUT s3://bucket/key
2        │
3        ▼
4[Front-end fleet] — 인증, 라우팅, multipart 조립
5        │
6        ▼
7[Index 서비스] — bucket+key → location 매핑 (분산 KV)
8        │
9        ▼
10[Storage 노드들] — erasure coding으로 쪼개 분산 저장
11        │  ├─ AZ-a: 데이터 + 패리티 일부
12        │  ├─ AZ-b: 데이터 + 패리티 일부
13        │  └─ AZ-c: 데이터 + 패리티 일부
14        ▼
15[Async durability 검증] — checksum, scrubbing
Copy

위 매커니즘에서 핵심은 "객체는 immutable 이다" 입니다.

- 부분 수정을 허용하면 분산된 모든 복제본의 같은 offset으로 동기화해야하고 이 때문에 락이 필요해지며 가용성/성능이 하락함
- "PUT은 새 버전을 만든다"는 원칙으로 옛 객체와 새 객체는 별개의 immutable blob 이므로 락이 없어도 일관성을 보장할 수 있음.

분산 시스템에서 immutability는 단순히 "수정 못 함"이 아니라 동시성 문제를 줄이는 강력한 설계 도구입니다. 함수형 프로그래밍에서 immutable 자료구조가 thread safety를 공짜로 주는 것과 본질적으로 같은 아이디어죠.

Pitfalls & Anti-patterns

함정 1: S3를 파일시스템처럼 마운트해서 쓰기 (s3fs-fuse)

증상: 처음엔 잘 되는 듯하지만 트래픽이 늘면 갑자기 느려지고, 파일 일부 수정 시 전체 재업로드가 일어나며, 메타데이터 (ls, stat) 가 끔찍하게 느림.

원인: S3의 시맨틱은 POSIX와 본질적으로 다릅니다. FUSE 레이어가 POSIX → S3 API로 번역할 때 어쩔 수 없이 "전체 다운로드 → 수정 → 전체 업로드" 같은 비효율이 발생.

해결책: 진짜 공유 파일시스템이 필요하면 EFS를 쓰세요. S3는 HTTP API로 직접 접근하는 게 정상 사용법입니다. 굳이 마운트하고 싶으면 Mountpoint for Amazon S3 같은 read-mostly 최적화 도구가 더 안전합니다.

함정 2: EBS만 믿고 백업 전략 없이 운영

증상: AZ 장애 또는 실수로 볼륨 삭제 시 데이터 영구 손실.

원인: EBS는 AZ 단위 가용성이지, 자동 백업이 아님.

해결책: AWS Backup 또는 DLM (Data Lifecycle Manager) 으로 자동 스냅샷 정책을 설정하세요. 스냅샷은 S3에 저장되어 region 단위로 보호받습니다. 중요한 데이터는 cross-region 스냅샷 복사까지 검토.

함정 3: EFS에 DB 데이터 올리기

증상: TPS 급락, fsync latency 폭증, 락 경합으로 query timeout.

원인: NFSv4의 락과 cache 일관성 비용이 OLTP DB의 IO 패턴과 안 맞음. 작은 random write가 수만 건씩 발생하는데 매번 네트워크 RTT.

해결책: DB는 항상 EBS 또는 RDS/Aurora가 정답. EFS는 read-mostly 공유에 한정.

함정 4: S3 prefix를 시간 단위로만 쪼개기

증상: 2026/05/07/log-001.txt 같은 키로 초당 수천 건을 쓰다가 503 SlowDown 응답.

원인: S3는 prefix 단위로 파티션되는데, 모든 키가 같은 날짜 prefix를 공유하면 한 파티션에 부하 집중.

해결책: prefix 앞에 hash나 reverse timestamp를 넣어 분산. 예: <hash>/2026/05/07/log-001.txt. 참고로 AWS는 자동 분할도 하지만 burst 직전 구간에서는 직접 제어가 안전합니다.

함정 5: EFS 처음 쓰고 "왜 이렇게 비싸지" 충격

증상: 같은 1 TB인데 EFS 비용이 EBS의 3배 이상.

원인: EFS는 멀티 AZ 복제 + NFS 서버 운영 비용을 포함. 가격이 GB당 비싼 건 정상.

해결책: EFS Standard-IA, EFS Lifecycle Policy로 자주 안 쓰는 파일을 자동으로 IA로 이동. 또는 정말 read-mostly라면 S3 + CloudFront로 대체 검토.