Day 2 - 스토리지 개요: S3(객체), EBS(블록), EFS·FSx(파일)

어제 컴퓨팅이 데이터를 "처리"하는 자리였다면, 오늘은 그 데이터를 "어디에 두느냐"의 이야기다. AWS의 스토리지는 종류가 많아 보이지만, 사실 데이터를 담는 방식이 세 가지뿐이다 — 객체(Object), 블록(Block), 파일(File). 이 세 가지가 각각 S3, EBS, EFS/FSx로 이어진다. CLF-C02 시험은 "어떤 데이터를 어떤 스토리지에 두는가"를 반복해서 묻는다.

오늘은 세 가지 스토리지 방식이 어떻게 다른지, 그리고 S3의 스토리지 클래스가 "얼마나 자주 꺼내 쓰느냐"에 따라 어떻게 나뉘는지를 정리한다.

클라우드 스토리지 이전에는 어땠나

지금은 "파일을 어디에 둘까"가 서비스 선택의 문제지만, 클라우드 이전에는 이게 하드웨어 구매의 문제였다.

사진 공유 서비스를 만든다고 해 본다. 사용자가 늘면 사진이 늘고, 사진이 늘면 디스크가 모자란다. 그래서 회사는 6개월 뒤 필요할 용량을 미리 추정해 디스크를 사 두었다. 적게 사면 어느 날 꽉 차 새 장비가 올 때까지 서비스가 멈추고, 많이 사면 쓰지도 않는 디스크에 돈을 몇 년씩 묶어 둔다. 게다가 디스크는 언젠가 고장 나므로 같은 데이터를 두세 벌 복제하고 그걸 관리할 사람까지 필요했다.

클라우드 스토리지가 바꾼 것은 이 구조 전체다. 용량을 미리 정하지 않고, 넣은 만큼만 내고, 복제는 AWS가 알아서 한다.

이 변화의 이름이 탄력성(Elasticity)이다. 스토리지에서 탄력성은 곧 "용량 계획(capacity planning)을 안 해도 된다"는 뜻이고, CLF-C02가 클라우드의 이점으로 반복해 묻는 항목이다.

세 가지 저장 방식: 객체 · 블록 · 파일

먼저 큰 그림이다. 데이터를 담는 방식은 세 가지로 나뉜다.

핵심 차이는 "무엇에 붙느냐, 누가 접근하느냐"다. 블록(EBS)은 EC2 한 대에 붙는 디스크이고, 파일(EFS)은 여러 EC2가 동시에 공유하는 폴더이며, 객체(S3)는 인터넷 어디서든 키(이름)로 꺼내는 사물함이다.

"객체 스토리지"가 전통적인 파일 시스템과 다른 점은 폴더 계층 구조가 없다는 것이다. S3는 사실 폴더가 없고 모든 객체가 평평한 공간에 키(고유 이름)로 저장된다. photos/2026/img.jpg 같은 경로처럼 보이는 것도 실은 폴더가 아니라 키 이름의 일부일 뿐이다.

세 방식을 일상 비유로 다시 보기

객체(S3) = 무인 물품보관소. 짐을 맡기면 번호표를 준다. 창고 안 어느 선반에 놓였는지는 알 필요가 없고, 번호표(키)만 있으면 통째로 꺼낸다. 대신 "짐 안에서 셔츠 소매만 3cm 줄여 주세요"는 안 된다 — 꺼내서, 고쳐서, 통째로 다시 맡겨야 한다.

블록(EBS) = 내 책상 서랍. 내 자리에 붙어 있고 나만 쓰지만, 서랍 안에서 종이 한 장만 바꿔 끼우는 것도 자유롭다. EBS도 EC2 한 대에 붙어 로컬 디스크처럼 보이고 파일 일부만 빠르게 고쳐 쓸 수 있다. 그래서 OS와 데이터베이스가 여기 산다.

파일(EFS) = 사무실 공용 캐비닛. 여러 사람이 같은 캐비닛을 열고 같은 서류철을 꺼내 보며, 서류가 늘면 칸이 자동으로 늘어난다.

⚠️ 함정: "S3에 데이터베이스를 올리면 되지 않나?"는 흔한 오해다. 데이터베이스는 파일의 아주 작은 부분을 초당 수천 번 고쳐 쓰는데, 객체 스토리지는 통째로 올리고 내리는 구조라 맞지 않는다. DB 데이터는 EBS(또는 관리형 DB 서비스), 사진·백업·로그는 S3 — 이 짝을 뒤집은 보기가 오답이다.

S3: 사실상 무한한 객체 스토리지

S3(Simple Storage Service)는 AWS에서 가장 널리 쓰이는 스토리지다. 사진, 동영상, 백업, 로그, 정적 웹사이트 파일 등 무엇이든 객체 단위로 저장한다. 객체들은 버킷(Bucket)이라는 통에 담긴다.

S3의 특징:

• 사실상 무한한 용량: 용량을 미리 정할 필요가 없다. 넣는 만큼 늘어난다.
• 높은 내구성: 11 9s(99.999999999%)라는 내구성을 목표로, 데이터를 여러 곳에 자동 복제한다.
• 인터넷 접근: 각 객체는 고유 URL로 접근할 수 있다(권한 설정에 따라).
• 서버 불필요: EC2 없이도 그 자체로 존재한다(서버리스 스토리지).

"내구성(Durability)"과 "가용성(Availability)"은 다른 개념이다. 내구성은 "데이터를 잃어버리지 않을 확률"이고, 가용성은 "지금 당장 접근할 수 있을 확률"이다. S3는 11 9s의 내구성을 자랑하는데, 이는 데이터를 여러 가용 영역(AZ)에 자동 복제하기 때문이다.

정적 웹사이트(HTML·CSS·이미지)를 S3 버킷에 올리고 그 자체로 호스팅할 수 있다. 서버를 한 대도 띄우지 않고 웹사이트를 운영하는 것이다. 트래픽이 늘어도 S3가 알아서 감당하므로 확장 걱정이 없다.

버킷 · 키 · 객체 — S3의 세 단어

S3를 처음 만나면 세 단어만 정리하면 된다.

s3://my-company-photos/2026/07/seoul.jpg를 뜯어보면 my-company-photos가 버킷, 2026/07/seoul.jpg가 키, 그 키가 가리키는 이미지 파일이 객체다. 2026/07/은 폴더가 아니라 키 이름에 포함된 슬래시 문자일 뿐인데, 콘솔이 폴더처럼 보여 주기 때문에 사람 눈에만 폴더로 보인다.

버킷 이름에는 특이한 규칙이 하나 있다. 버킷 이름은 전 세계에서 유일해야 한다. 누군가 이미 photos라는 버킷을 만들었다면 나는 그 이름을 쓸 수 없다. 그래서 실무에서는 acme-invoice-prod-ap-northeast-2처럼 길게 짓는다.

S3는 실제로 어디에 쓰이나

"무엇이든 저장한다"는 설명은 막연하니, 회사들이 S3를 쓰는 대표 장면 네 가지를 본다.

• 백업과 아카이브: 데이터베이스를 매일 밤 덤프해 올리고, 오래된 백업은 자동으로 더 싼 클래스로 내려보낸다.
• 정적 웹사이트·이미지 호스팅: 소개 페이지, 프로필 사진, 제품 이미지처럼 "한 번 올리고 여럿이 읽기만 하는" 파일들의 집. 앞에 CloudFront(내일 다룬다)를 붙여 전 세계에 뿌린다.
• 로그 수집소: 서버가 100대여도 로그의 종착지는 버킷 하나다.
• 데이터 레이크(Data Lake): 여러 시스템의 원시 데이터를 형식 불문하고 쌓아 두고 나중에 분석 도구가 읽어 간다. 무한에 가까운 용량과 저렴한 보관료가 이걸 가능하게 했다.

버전 관리(Versioning)를 켜면 같은 키에 새 파일을 덮어써도 이전 버전이 함께 보관되어, 실수로 덮어쓰거나 삭제해도 되돌릴 수 있다. "버전 관리 = 실수 복구용 안전장치"로 기억하면 된다.

⚠️ 함정: S3 버킷은 기본적으로 비공개다. "S3에 올렸으니 자동으로 인터넷에 공개된다"는 서술은 틀렸다. 오히려 공개 설정을 잘못 열어 민감한 파일이 노출되는 사고가 잦기 때문에 AWS는 퍼블릭 액세스 차단(Block Public Access)을 기본값으로 켜 둔다.

EBS: EC2에 붙이는 블록 스토리지

EBS(Elastic Block Store)는 EC2 인스턴스에 붙이는 하드디스크다. 물리 컴퓨터에 SSD를 꽂는 것과 같은 개념이다. OS를 설치하거나, 데이터베이스 파일을 두거나, 빠른 읽기·쓰기가 필요한 곳에 쓴다.

EBS의 핵심 특징:

• 한 인스턴스에 연결: 기본적으로 EBS 볼륨 하나는 같은 가용 영역(AZ)의 EC2 한 대에 붙는다.
• 수명 분리 가능: EC2를 종료해도 EBS 볼륨은 남길 수 있어 데이터가 보존된다.
• 스냅샷 백업: 특정 시점의 볼륨을 S3에 스냅샷으로 백업할 수 있다.

함정: EBS 볼륨은 특정 가용 영역(AZ)에 묶여 있다. 그래서 다른 AZ의 EC2에 그대로 붙일 수 없다. AZ를 넘기려면 스냅샷을 떠서 다른 AZ에 새 볼륨으로 복원해야 한다. 이 "AZ 종속성"이 시험에 종종 나온다.

스냅샷 — 볼륨의 사진 한 장

스냅샷(Snapshot)은 EBS 볼륨의 특정 시점 상태를 S3에 복사해 두는 백업으로, "지금 이 순간의 디스크를 사진 찍어 두는 것"에 가깝다. 쓰임은 둘이다. 복구 — 볼륨이 망가지거나 실수로 데이터를 지웠을 때 새 볼륨으로 되돌린다. 이동 — 스냅샷은 볼륨과 달리 AZ에 묶이지 않아, 다른 AZ나 리전에서 복원하면 사실상 "이사"가 된다.

즉 EBS의 AZ 종속성을 푸는 열쇠가 스냅샷이다. "EBS 볼륨을 다른 AZ/리전으로 옮기려면?"의 답은 거의 항상 스냅샷이다.

인스턴스 스토어 — 붙어 있지만 사라지는 디스크

EC2에 붙는 디스크가 EBS만 있는 것은 아니다. 인스턴스 스토어(Instance Store)는 EC2가 실제로 돌아가는 물리 서버에 직접 달린 디스크다. 물리적으로 붙어 있어 대단히 빠르지만, 결정적인 성질이 하나 있다 — 인스턴스를 중지하거나 종료하면 데이터가 사라진다(휘발성).

함정: "빠른 디스크가 필요하다"는 조건만 보고 인스턴스 스토어를 고르면 안 된다. 문항에 "데이터가 영구히 보존되어야 한다"는 표현이 있으면 답은 EBS다.

EFS와 FSx: 여러 서버가 공유하는 파일 스토리지

EBS가 한 대에 붙는 디스크라면, EFS(Elastic File System)는 여러 EC2가 동시에 같이 쓰는 공유 폴더다. 네트워크 드라이브를 떠올리면 된다. 여러 서버가 같은 파일을 읽고 써야 할 때 쓴다.

EFS는 용량을 미리 정할 필요 없이 파일을 넣는 만큼 자동으로 늘어나고, 여러 AZ에 걸쳐 접근할 수 있다는 점에서 EBS와 다르다.

EBS와 EFS의 결정적 차이는 "동시 접근"이다. EBS는 보통 한 EC2 전용 디스크(1:1), EFS는 여러 EC2가 동시에 마운트하는 공유 폴더(1:다)다. "여러 서버가 같은 파일을 공유해야 한다"는 키워드가 나오면 EFS, "한 서버의 OS·DB 디스크"라면 EBS다.

사내 콘텐츠 관리 시스템(CMS)을 웹 서버 5대로 운영한다고 가정한다. 편집자가 어느 서버에 접속하든 같은 첨부파일 목록을 봐야 한다. 각 서버에 EBS를 따로 붙이면 파일이 제각각이 되지만, EFS를 5대가 함께 마운트하면 어디서 올리든 하나의 공유 폴더에 반영된다. 반면 각 서버의 OS 디스크는 따로 있어야 하니 EBS다. 한 서버가 EBS와 EFS를 동시에 쓰는 것이 오히려 자연스럽다.

FSx는 "특수한 파일 시스템이 필요할 때 AWS가 대신 운영해 주는 서비스"다. 오래 써 온 Windows 공유 드라이브를 그대로 옮길 때는 FSx for Windows File Server, 유전체 분석처럼 수백 대가 초고속으로 같은 데이터를 읽는 고성능 컴퓨팅(HPC)에는 FSx for Lustre를 쓴다. 시험에서는 "Windows·SMB" → FSx for Windows, "HPC·머신러닝 학습" → FSx for Lustre 정도면 충분하다.

데이터를 AWS로 옮기는 서비스들

지금까지는 "AWS 안에 데이터를 어디에 둘까"였다. 그런데 실무의 첫 관문은 종종 "이미 회사 서버에 있는 데이터를 어떻게 옮길까"다.

방송사가 수십 년치 영상 아카이브를 옮기려는데 회선으로 보내면 몇 달이 걸린다. Snowball 장치를 받아 데이터를 채워 반송하면 물리적으로 실어 나르는 편이 오히려 빠르다. "인터넷으로 보내기엔 너무 크다"가 Snowball의 시험 키워드다.

S3 스토리지 클래스: 얼마나 자주 꺼내 쓰는가

S3 안에서도 데이터를 "얼마나 자주 접근하느냐"에 따라 가격이 다른 스토리지 클래스를 고를 수 있다. 자주 안 꺼낼 데이터일수록 보관료는 싸지만, 꺼낼 때 시간이나 추가 비용이 든다.

스토리지 클래스 선택의 원리는 "보관료와 인출비의 교환"이다. 자주 꺼내면 Standard, 거의 안 꺼내면 Glacier Deep Archive가 싸다. 접근 패턴을 모르겠다면 Intelligent-Tiering이 알아서 옮겨 준다. 그리고 이 이동을 자동화하는 것이 수명 주기 정책(Lifecycle Policy)이다 — 예: "90일 지난 객체는 Glacier로, 1년 지나면 삭제."

🎯 시나리오: "법적 보관 의무로 7년간 보관해야 하지만 거의 꺼내 볼 일이 없는 감사 로그"를 어디에 둘까? → S3 Glacier Deep Archive. 보관료가 가장 싸고, 꺼내는 데 몇 시간 걸려도 "거의 꺼내지 않는" 조건에 부합하므로 비용 최적이다.

클래스를 고르는 두 개의 질문

표가 일곱 줄이라 외우려 들면 막막하다. 대신 "얼마나 자주 꺼내는가"와 "꺼낼 때 얼마나 빨리 필요한가" 두 질문으로 좁히면 거의 항상 답이 하나로 떨어진다.

  자주 꺼낸다?          → Standard        | 드물지만 즉시 필요 → Glacier Instant
  가끔(월 1~2회) 꺼낸다? → Standard-IA     | 몇 시간 기다려도 됨 → Glacier Flexible
  사본이라 한 AZ면 충분  → One Zone-IA     | 거의 안 꺼내고 최저가 → Deep Archive
  접근 패턴을 모르겠다   → Intelligent-Tiering

Intelligent-Tiering이 푸는 문제를 짚어 둔다. 위 질문들은 "얼마나 자주 꺼내는지 내가 안다"는 전제 위에 있다. 그런데 사용자가 올린 파일 중 어떤 건 매일 열리고 어떤 건 한 번 보고 잊힌다. 이걸 사람이 분류할 수는 없다. Intelligent-Tiering은 AWS가 객체별 접근 패턴을 관찰해 자동으로 계층을 옮겨 준다. "접근 패턴이 예측 불가능하다"는 표현이 보이면 이것이 답이다.

수명 주기 정책(Lifecycle Policy)은 반대로 "규칙이 명확할 때" 쓰는 자동화다. 로그처럼 패턴이 뻔한 데이터에는 30일 뒤 Standard-IA, 90일 뒤 Glacier, 1년 뒤 삭제 같은 규칙을 걸어 둔다.

둘은 경쟁 관계가 아니라 "패턴을 아는가"로 갈리는 선택지다. 패턴이 뻔하면 수명 주기 정책으로 못 박고, 모르면 Intelligent-Tiering에 맡긴다. 목적은 하나 — 사람이 손대지 않아도 비용이 알아서 줄게 만드는 것이다.

함정: One Zone-IA의 "One Zone"은 사본이 하나의 가용 영역(AZ)에만 있다는 뜻이다. 더 싸지만 그 AZ가 손상되면 데이터를 잃는다. 다시 만들 수 있는 썸네일에는 좋아도 "이것 하나뿐인 원본"에는 쓰면 안 된다.

시험에 이렇게 나온다 — 키워드 → 정답 매핑

스토리지 문항은 대부분 "상황 설명 → 알맞은 서비스 고르기" 형태다. 아래 키워드가 보이면 반사적으로 답이 떠오르게 해 둔다.

함정: 보기에 "가장 비용 효율적인"이라는 수식어가 붙었는지 꼭 확인한다. 같은 상황이라도 성능이 최우선이면 Standard, 비용이 최우선이면 더 낮은 계층이 답이 된다. 문항이 무엇을 최적화하라 요구하는지를 먼저 찾는 습관이 정답률을 크게 올린다.

정리

오늘의 핵심은 세 갈래다. 첫째, 저장 방식은 객체(S3)·블록(EBS)·파일(EFS·FSx) 세 가지뿐이고, 각각 "사물함·붙이는 디스크·공유 폴더"로 기억하면 된다. 둘째, EBS는 한 EC2 전용 + AZ 종속, EFS는 여러 EC2 공유라는 점이 둘을 가르는 기준이다. 셋째, S3 스토리지 클래스는 "얼마나 자주 꺼내느냐"에 따라 보관료와 인출비를 교환하는 메뉴이고, 모르면 Intelligent-Tiering, 자동화는 수명 주기 정책이다.

여기에 오늘 더 붙인 것을 얹어 둔다. S3의 세 단어는 버킷(통)·키(이름)·객체(데이터)이고 버킷은 기본적으로 비공개다. EBS의 AZ 종속성을 푸는 열쇠는 스냅샷이며, 인스턴스 스토어는 인스턴스가 꺼지면 사라진다는 점에서 EBS와 갈린다.

마지막으로 하나만 기억한다. 스토리지 문항은 서비스 이름을 외웠는지가 아니라 "이 데이터의 성격이 무엇인가"를 읽어 냈는지를 묻는다. 자주 바뀌는가, 여럿이 함께 보는가, 잃어버려도 되는가, 언제 다시 꺼낼 것인가 — 이 네 질문에 답하면 서비스는 저절로 정해진다.

내일은 이 서버와 스토리지가 모여 사는 동네 — VPC와 네트워킹의 기초로 넘어간다.

📝 연습 문제

선택지를 클릭하면 정답·해설이 펼쳐집니다.

문제 1

여러 EC2 인스턴스가 동시에 같은 파일에 접근하여 읽고 써야 하는 Linux 기반 워크로드가 있다. 가장 적합한 스토리지는?

• AEBS
• BEFS
• CS3 Glacier Deep Archive
• D인스턴스 스토어

문제 2

법적 의무로 7년간 보관해야 하지만 거의 꺼내 볼 일이 없는 대용량 감사 로그를 가장 저렴하게 저장하려고 한다. 적합한 S3 스토리지 클래스는?

• AS3 Standard
• BS3 Standard-IA
• CS3 Glacier Deep Archive
• DS3 Intelligent-Tiering

문제 3

S3의 "내구성 11 9s(99.999999999%)"가 의미하는 것으로 가장 정확한 것은?

• A데이터에 언제나 즉시 접근할 수 있는 확률
• B저장한 데이터를 잃어버리지 않을 확률
• C데이터 전송 속도
• D한 달에 다운타임이 없는 비율

문제 4

EBS 볼륨에 대한 설명으로 옳은 것은?

• A여러 가용 영역(AZ)의 EC2에 자유롭게 동시 연결할 수 있다
• B특정 가용 영역(AZ)에 묶여 있어 그 AZ의 EC2에 연결된다
• C서버 없이도 HTTP로 직접 접근하는 객체 스토리지다
• D용량을 미리 정할 수 없고 무한히 자동 확장된다

문제 5

S3에서 객체의 접근 빈도가 시간이 지나며 줄어들 때, 비용 절감을 위해 더 저렴한 스토리지 클래스로 자동 이동시키는 메커니즘은?

• A수명 주기 정책(Lifecycle Policy)
• B보안 그룹(Security Group)
• CEBS 스냅샷
• D예약 인스턴스