Day 1 - S3: 객체 스토리지의 철학과 스토리지 클래스 설계

Amazon S3가 처음 출시된 2006년 3월 14일, 창업자 Werner Vogels는 "저장 용량 걱정을 영원히 없애겠다"고 말했다. 그 선언이 실제로 어떤 기술 결정으로 이어졌는지를 이해하면 S3의 독특한 설계 원칙이 보이기 시작한다. S3는 파일 시스템이 아니다. 계층 디렉터리도, inode도, 파일 잠금도 없다. 있는 것은 오직 키-값 쌍의 무한한 공간뿐이다. 이 단순한 모델이 왜 20년이 지난 지금도 살아남았는지, 그리고 DVA-C02 시험에서 S3가 왜 중요한 출제 영역인지를 이 글에서 파헤친다.

S3는 왜 파일 시스템이 아닌가 — 설계 철학

1970년대 Ken Thompson이 Unix 파일 시스템을 설계할 때 목표는 단일 머신에서 여러 프로세스가 공유 자원에 접근하는 것이었다. 계층형 디렉터리, inode, 링크, 파일 잠금은 그 목표에 최적화된 구조다. 그러나 수십억 개의 객체를 수천 개의 서버에 분산 저장하는 문제에서 이 구조는 오히려 방해가 된다. 디렉터리 잠금은 병목이 되고, inode 테이블은 단일 장애점이 되며, 계층 탐색은 메타데이터 서버에 과부하를 준다.

S3의 해답은 flat namespace다. 버킷 이름과 키(key)만 있으면 어떤 객체든 O(1)에 가깝게 찾아낼 수 있다. /documents/2026/report.pdf 처럼 보이는 경로도 실제로는 슬래시가 포함된 단일 문자열 키일 뿐이다. 이 설계 덕분에 S3는 메타데이터 서버 없이 수십 페타바이트 규모로 수평 확장이 가능하다.

S3에는 실제 디렉터리가 없다. "디렉터리 목록"은 특정 prefix로 시작하는 키를 순서대로 나열해 흉내 낸 것이다. 그래서 수백만 객체가 있는 버킷에서는 LIST 작업이 선형 시간이 걸리고 비용도 더 든다.

버킷의 글로벌 이름 공간이 주는 의미

my-company-docs라는 이름의 버킷을 만들었다면, 전 세계 어떤 AWS 계정도 같은 이름을 사용할 수 없다. 이 규칙은 처음엔 불편해 보이지만 두 가지 강력한 이점을 준다. 첫째, 버킷 이름만으로 전 세계 어디서든 https://my-company-docs.s3.amazonaws.com이라는 DNS 이름이 자동으로 결정된다. DNS 서버 설정이 따로 필요 없다. 둘째, 서로 다른 AWS 계정의 교차 계정 접근 정책에서 버킷 ARN(arn:aws:s3:::my-company-docs)이 전역적으로 유일하게 식별된다.

버킷 이름 규칙은 단순하지만 시험에서 자주 함정으로 나온다. 소문자, 숫자, 하이픈, 점만 허용(3~63자)이며, IP 주소 형식(192.168.1.1)은 금지다. 그리고 점(.)이 포함된 이름은 HTTPS에서 와일드카드 인증서(*.s3.amazonaws.com)와 매칭이 깨지기 때문에 실무에서는 점 없는 이름이 권장된다.

S3 URL에는 두 가지 형식이 공존한다. 가상 호스팅 스타일(https://bucket.s3.region.amazonaws.com/key)과 경로 스타일(https://s3.region.amazonaws.com/bucket/key)이다. AWS는 2019년에 경로 스타일을 deprecated 예고했으나 기존 고객 영향으로 아직 유지 중이다. 신규 코드는 가상 호스팅 스타일을 써야 한다. SDK는 기본적으로 가상 호스팅 스타일을 사용하므로 별도 설정이 필요 없다.

11 nines 내구성의 비밀 — 분산 복제와 erasure coding

"99.999999999% 내구성"은 S3 마케팅의 핵심이다. 이 숫자가 구체적으로 무엇을 의미하는지 이해해야 시험 문제를 정확히 풀 수 있다. 내구성이란 데이터 손실 확률이다. 객체당 연간 손실 확률이 0.000000001%라는 뜻이라, 객체 1,000만 개를 저장하면 평균 1만 년에 한 개를 잃는 수준이다. 이 수준의 내구성은 어떻게 달성되는가?

S3 Standard는 데이터를 최소 3개의 AZ에 걸쳐 저장한다. 단순히 3벌 복사(replication)가 아니라, erasure coding 기법을 사용한다. 데이터를 k개의 조각으로 나눠 m개의 패리티 조각을 추가로 만들면, k+m개 중 임의의 m개가 손상되어도 k개로 원본 복구가 가능하다. erasure coding은 같은 내구성을 단순 복제보다 적은 저장 공간으로 얻는 기법이다. S3가 쓰는 구체적인 부호화 방식과 오버헤드 비율은 공개되지 않았다.

One Zone-IA는 왜 11 nines인가 — 가용성과 내구성의 차이

내구성(durability) 과 가용성(availability) 은 헷갈리기 쉬운 짝이다. S3 One Zone-IA는 내구성이 여전히 11 nines(99.999999999%)이지만, 가용성은 99.5%밖에 되지 않는다. 왜 그런가?

One Zone-IA는 단일 AZ에만 데이터를 저장한다. 그 AZ 안에서는 erasure coding으로 11 nines 내구성을 달성한다. 그러나 AZ 전체가 재난(화재, 홍수, 전력 차단)으로 완전히 오프라인이 되면 데이터에 접근할 수 없다 — 데이터 자체가 손상된 것은 아니지만 읽을 수가 없는 것이다. 이것이 가용성 99.5%의 의미다. 만약 AZ 장애가 스토리지 하드웨어 손실로 이어진다면 데이터 자체가 영구 손실될 수도 있다. 그래서 재생성 가능한 데이터(이미지 썸네일, 변환된 데이터)에만 One Zone-IA를 사용해야 한다.

⚠️ 함정: One Zone-IA를 선택하는 문제에서 "AZ 장애 시 데이터 손실 가능성"이 있다는 점에 유의한다. 시험에서 "재생성 가능한 데이터"라는 힌트가 있으면 One Zone-IA가 정답이고, "어떤 상황에서도 데이터 보존"이라는 힌트가 있으면 Standard 또는 Standard-IA가 정답이다.

S3 스토리지 클래스 — 비용과 접근 패턴의 트레이드오프

스토리지 클래스의 선택은 단순히 "싼 것"을 고르는 게 아니라, 저장 비용 vs 검색 비용 vs 접근 지연 시간의 세 축을 최적화하는 문제다.

최소 저장 기간은 중요한 시험 포인트다. Standard-IA에 데이터를 15일 저장 후 삭제해도 30일치 요금이 청구된다. 실제 삭제는 됐지만 AWS는 30일 최소 기간에 해당하는 저장 비용을 청구한다. Glacier Deep Archive의 최소 저장 기간은 180일이므로, 아카이브 데이터를 규정 보존 기간 없이 마구 집어넣으면 오히려 비용이 올라간다.

접근 빈도가 낮을수록 저장 단가는 낮아지지만 실제로 접근할 때의 복구 비용은 높아진다. Glacier Deep Archive의 저장 비용은 Standard의 1/23이지만, Bulk 검색 시 GB당 $0.0025가 추가된다. 자주 접근하는 데이터를 Glacier에 넣으면 총 비용이 오히려 높아질 수 있다.

S3 Intelligent-Tiering — 접근 패턴으로 자동 분류

Intelligent-Tiering은 2018년에 출시된 스토리지 클래스로, 객체의 접근 패턴을 S3가 자동으로 모니터링하여 최적 티어로 이동시킨다. 추가 검색 비용 없이 자동화된다는 것이 핵심이다.

Intelligent-Tiering의 내부 구조를 보면 5개 티어로 구성된다. Frequent Access 티어(Standard와 동일), Infrequent Access 티어(30일 미접근 시 자동 이동, Standard-IA와 동일), Archive Instant Access 티어(90일 미접근, Glacier Instant와 동일)가 기본이다. Archive Access 티어(최소 90일, 최대 730일까지 설정)와 Deep Archive Access 티어(최소 180일, 최대 730일까지 설정)는 선택 활성화한다. 주의할 점은 객체 수에 비례하는 월 모니터링·자동화 요금이 붙는다는 것이다. 128KB 미만 객체는 모니터링 대상이 아니라 이 요금이 없는 대신 자동 티어링도 되지 않고 항상 Frequent Access 티어에 머문다. 그래서 작은 객체가 대부분인 버킷은 Intelligent-Tiering으로 얻는 절감이 거의 없다.

S3 Intelligent-Tiering은 각 객체의 마지막 접근 시점을 S3가 추적해 티어를 정한다. 내부 구현은 공개되지 않았고, 이 추적 정보를 S3 API로 직접 조회할 수는 없다. 접근 패턴을 직접 분석하고 싶다면 S3 Storage Class Analysis를 사용해야 한다 — 이 도구는 Standard와 Standard-IA 간의 전환 시점을 추천해주고, Intelligent-Tiering이 적합한지도 알려준다.

S3 Express One Zone — 2023년의 새로운 카테고리

2023년 re:Invent에서 발표된 Express One Zone은 기존 S3 클래스와 근본적으로 다르다. 일반 S3가 General Purpose Bucket을 사용하는 반면, Express One Zone은 Directory Bucket이라는 새로운 버킷 유형을 사용한다. Standard보다 최대 10배 빠른 한 자릿수 밀리초 접근 지연은 AI/ML 학습 중 반복적으로 같은 데이터셋에 접근할 때 극적인 차이를 만든다. GPU가 데이터를 기다리는 시간을 줄이는 것이 학습 비용을 줄이는 핵심이기 때문이다.

단, 단일 AZ에만 저장되므로 영구 보존이 필요한 데이터에는 적합하지 않다. AI 학습용 임시 데이터, HPC 중간 결과물, 분석 중에만 필요한 스테이징 데이터가 주요 사용 사례다.

Express One Zone은 저장 단가가 높지만, 학습 파이프라인처럼 GPU가 데이터를 기다리는 시간이 긴 워크로드에서는 대기 시간이 줄어 EC2 GPU 인스턴스 비용까지 포함한 전체 비용이 낮아질 수 있다.

2020년 강력한 일관성 업데이트 — 역사적 맥락

2020년 12월 이전까지 S3는 새 객체에 대해서만 read-after-write 일관성을 보장하고, 기존 객체의 업데이트/삭제에는 eventual consistency만 보장했다. 즉, 객체를 덮어쓰거나 삭제한 직후 다른 요청이 이전 버전 데이터를 받을 수 있었다. 이 동작이 많은 개발자에게 버그처럼 보였지만, 사실 S3 설계의 트레이드오프였다 — eventual consistency가 초당 수십만 요청을 처리하는 분산 시스템의 성능을 가능하게 했다.

2020년 12월, AWS는 모든 S3 읽기/쓰기/삭제/목록 작업에 대해 강력한 일관성(Strong Consistency) 을 추가 비용 없이 제공하기 시작했다. 이 변경은 S3의 내부 메타데이터 계층을 재설계한 결과였으며, 성능 저하 없이 일관성을 달성했다는 점이 업계에서 큰 주목을 받았다.

⚠️ 함정: 오래된 학습 자료나 시험 문제 은행에 "S3는 eventual consistency"라고 나오면 틀린 내용이다. 2020년 12월 이후 모든 S3 작업은 Strong Consistency다. 시험에서 이 변경점을 묻는 문제가 나오면 "2020년 이후로 Strong Consistency"가 정답이다.

비용 구조 전체 이해하기

S3 비용을 계산할 때 저장 비용만 보면 실수하기 쉽다. 실제 비용은 4가지 구성 요소로 이루어진다.

S3 총 비용 = 저장 비용 + 요청 비용 + 데이터 전송 비용 + 관리 기능 비용

저장 비용: GB/월 기준, 스토리지 클래스별 차등
요청 비용: PUT이 GET보다 비쌈 (PUT ~$0.005/1000, GET ~$0.0004/1000)
데이터 전송:
  - IN(업로드): 무료
  - OUT to 인터넷: 첫 100GB/월 무료, 이후 GB당 $0.09
  - OUT to 같은 리전 AWS 서비스: 무료 (예: S3 → EC2 같은 리전)
  - OUT to 다른 리전: GB당 $0.02
관리 기능: S3 Inventory, Storage Class Analysis, Object Lambda, Replication

IA 클래스는 최소 저장 기간과 최소 객체 크기(128KB) 요건 때문에 "숨겨진 비용"이 생긴다. 128KB 미만 객체를 Standard-IA에 저장하면 항상 128KB 기준으로 과금된다. 수백만 개의 작은 파일을 IA에 넣으면 실제 데이터보다 훨씬 많은 비용이 나올 수 있다.

CLI로 직접 확인하기

# 버킷 생성 (서울 리전)
aws s3api create-bucket \
  --bucket my-unique-bucket-12345 \
  --region ap-northeast-2 \
  --create-bucket-configuration LocationConstraint=ap-northeast-2
 
# 객체 업로드 시 스토리지 클래스 지정
aws s3 cp archive.zip s3://my-bucket/archives/ \
  --storage-class GLACIER
 
# 객체 메타데이터 확인 (스토리지 클래스 포함)
aws s3api head-object \
  --bucket my-bucket \
  --key archive.zip
 
# 특정 prefix의 객체 목록
aws s3 ls s3://my-bucket/documents/ --recursive
 
# 스토리지 클래스 변경 (실제로는 복사 + 삭제)
aws s3 cp s3://my-bucket/old-file.txt s3://my-bucket/old-file.txt \
  --storage-class STANDARD_IA

S3의 "스토리지 클래스 변경"은 실제로 같은 키로 복사하는 작업이다. 이 점이 중요한 이유는 복사 작업이 API 요청 비용을 발생시키기 때문이다. 수백만 객체의 클래스를 변경하려면 수동 복사 대신 S3 Lifecycle Policy나 S3 Batch Operations를 사용해야 한다.

오늘 살펴본 S3의 철학 — flat namespace, 분산 복제, 스토리지 클래스의 비용 트레이드오프 — 은 DVA-C02의 S3 관련 문제 전반에 깔려 있는 기반 지식이다. 다음 day에서는 이 기반 위에서 버전 관리와 수명 주기 정책이 어떻게 데이터 관리를 자동화하는지 살펴본다.