📚 지식 노트

세 갈래: 무엇을 단위로 내주는가

SSD와 HDD 자체는 저장장치 노트에서 다뤘다. 서버에서는 같은 디스크라도 앱에 무엇을 단위로 내주느냐에 따라 세 갈래로 나뉜다. 블록 스토리지(block storage)는 번호 붙은 같은 크기 칸을, 파일 스토리지(file storage)는 폴더와 이름으로 짠 나무를, 오브젝트 스토리지(object storage)는 키로 찾는 데이터 덩어리를 내준다.

셋은 위아래로 쌓이기도 한다. 파일 시스템은 블록 위에 이름을 얹은 것이고, 오브젝트 스토리지 서버도 안에서는 블록 장치와 파일 시스템을 쓴다. 차이는 앱이 보는 약속이다. 무엇을 한 번에 바꿀 수 있는지, 여럿이 함께 쓸 수 있는지, 얼마나 멀리서 쓸 수 있는지가 그 약속에서 나온다.

블록 스토리지: 번호 붙은 칸

블록 장치는 같은 크기의 칸이 길게 늘어선 배열이다. 칸 번호를 LBA(Logical Block Address)라 하고, 명령은 "LBA 몇 번부터 몇 칸을 읽어라, 써라"뿐이다. 칸은 논리적으로 512바이트나 4096바이트이고, 요즘 디스크는 물리적으로 4KiB 단위로 기록한다. 장치는 칸에 무엇이 들었는지 모른다. 어느 칸이 어느 파일인지는 위층의 파일 시스템이나 데이터베이스가 안다.

그래서 블록은 가장 낮고 가장 자유롭다. 아무 칸이나 골라 4KiB만 고쳐 쓸 수 있고, 위에 어떤 파일 시스템을 올릴지도 마음대로다. 운영체제 부팅 디스크, 데이터베이스의 데이터 파일, 가상 머신 디스크처럼 작은 조각을 자주 고쳐 쓰고 지연이 짧아야 하는 곳이 블록의 자리다. 대신 보통 한 번에 서버 한 대만 붙인다. 두 대가 함께 쓰면 무슨 일이 나는지는 네트워크 스토리지 노트에서 다룬다.

클라우드에서는 네트워크 너머의 블록 장치를 가상 디스크로 붙인다. AWS EBS의 io2 Block Express 볼륨은 최대 64TiB, 256,000 IOPS이고 16KiB 입출력의 평균 지연을 500µs 아래로 설계했다. 네트워크를 거치는데도 1ms가 안 된다는 점이 블록이 앞자리에 서는 이유다.

파일 시스템: 블록 위에 이름과 폴더를 얹는다

파일 시스템은 블록 칸을 나눠 파일과 디렉터리를 만든다. 유닉스 계열 파일 시스템에서 파일 하나의 정보는 아이노드(inode)에 담긴다. 크기, 권한, 소유자, 시각, 그리고 내용이 든 블록의 위치다. 이름은 아이노드에 없다. 디렉터리도 일종의 파일이고, 그 내용이 "이름 → 아이노드 번호" 목록(디렉터리 항목)이다. ext4의 구조는 리눅스 커널 문서의 ext4 아이노드 절에 있다.

이름과 아이노드가 떨어져 있어 생기는 성질이 많다. 하드 링크는 같은 아이노드를 가리키는 이름을 하나 더 만드는 것이고, 같은 파일 시스템 안에서 이름 바꾸기(rename)는 내용을 옮기지 않고 디렉터리 항목만 바꿔 한 번에(원자적으로) 끝난다. 그래서 "임시 파일에 다 쓴 뒤 rename으로 바꿔치기"가 파일을 안전하게 갈아 끼우는 흔한 방법이다. 앱은 POSIX 함수(open, read, write, seek)로 파일의 아무 위치나 읽고 고쳐 쓰고, fcntl 잠금으로 같은 파일을 여러 프로세스가 나눠 쓴다.

파일 하나를 늘리는 데도 디스크 여러 곳을 고쳐야 한다. 데이터 블록, 아이노드의 크기, 빈 블록 비트맵이다. 중간에 전원이 끊기면 아이노드는 새 블록을 가리키는데 비트맵은 그 블록이 비었다고 하는 식으로 어긋난다. 예전에는 부팅 때 디스크 전체를 훑어(fsck) 고쳤다. 저널링(journaling)은 바꿀 내용을 먼저 따로 둔 영역(저널)에 적고 커밋한 뒤 제자리에 반영해, 재시작 때 저널만 보고 끝낸다. ext4는 기본으로 메타데이터만 저널에 적고 데이터는 그 전에 제자리에 쓰는 ordered 모드를 쓴다(ext4 저널 문서).

ZFS와 Btrfs는 다른 길을 간다. 고칠 블록을 제자리에 덮어쓰지 않고 새 자리에 쓴 뒤 맨 위의 포인터 하나만 바꾸는 쓰기 시 복사(copy-on-write)다. 옛 블록이 그대로 남으니 지금 상태를 얼려 두는 스냅숏이 거의 공짜다. 이 성질은 NAS의 스냅숏(네트워크 스토리지 노트)과 RAID-Z(중복과 분산 노트)로 이어진다.

파일 스토리지는 이 파일 시스템을 네트워크 너머에서 여럿이 함께 쓰게 한 것이다. 파일 시스템은 서버(NAS) 쪽에 있고, 클라이언트는 NFS나 SMB로 "이 경로의 이 범위를 읽어라" 하고 파일 단위로 묻는다. 여러 서버가 같은 디렉터리를 함께 열고 잠금을 나눠 쓸 수 있다는 것이 블록과 가장 큰 차이다.

오브젝트 스토리지: 키로 찾는 통째 덩어리

오브젝트 스토리지는 폴더도 칸 번호도 없이, 버킷(bucket)이라는 통 안에 키(key)와 데이터, 메타데이터를 한 묶음으로 둔다. 키는 버킷 안에서 유일한 문자열이고, 메타데이터는 Content-Type 같은 시스템 값과 사용자가 붙인 이름=값 쌍이다. 앱은 HTTP로 다룬다. PUT으로 올리고, GET으로 받고, HEAD로 메타데이터만 보고, DELETE로 지우고, LIST로 키를 나열한다. 이 모양을 굳힌 것이 Amazon S3이고, S3 사용자 안내서가 버킷·키·버전의 기본을 설명한다.

이름 공간은 평평하다. photos/2026/cat.jpg의 슬래시는 그냥 글자이고, 콘솔이 폴더처럼 보여 주는 것은 접두사와 구분자로 LIST 결과를 묶은 것이다. 그래서 "폴더 이름 바꾸기"는 그 접두사의 키를 모두 복사하고 지우는 일이 된다. 파일 시스템의 rename 한 번과 비용이 전혀 다르다. 접두사는 성능 단위이기도 하다. S3는 접두사 하나에 초당 쓰기 3,500건, 읽기 5,500건 이상을 내고 접두사를 늘리면 그만큼 늘어난다고 S3 성능 안내에 적혀 있다.

가장 큰 제약은 부분 수정이 없다는 것이다. GET은 Range 헤더로 일부만 읽을 수 있지만, 쓰기는 오브젝트를 통째로 다시 올리는 것뿐이다. 1GB 로그 끝에 한 줄을 붙이려면 1GB를 다시 쓴다. 대신 이 단순함 덕에 서버 수천 대에 오브젝트를 흩어 놓고 거의 끝없이 늘릴 수 있다. 오브젝트 하나의 최대 크기는 2025년 12월에 5TB에서 50TB로 늘었다(AWS 발표).

S3 API는 사실상 표준이 됐다. Ceph RGW나 MinIO 같은 자체 구축 저장소와 여러 클라우드가 S3 호환을 내세우므로, S3 SDK로 짠 코드를 주소만 바꿔 다른 곳에 붙이는 일이 흔하다. 다만 호환 범위는 제품마다 다르니 쓰는 기능(버전, 잠금, 조건부 쓰기)이 되는지 확인해야 한다.

오브젝트의 규칙: 통째로, 조건부로, 버전으로

큰 오브젝트는 멀티파트 업로드(multipart upload)로 올린다. 조각은 5MiB~5GiB, 최대 10,000개이고, AWS는 100MB쯤부터 이 방식을 권한다(멀티파트 한도). 5GiB × 10,000이 약 48.8TiB라서 이것이 실제로 올릴 수 있는 최대 크기다.

일관성은 한때 오브젝트 스토리지의 약점이었다. S3는 처음에 덮어쓰기와 삭제가 잠시 늦게 보이는 최종 일관성(eventual consistency)이었고, 2020년 12월부터 모든 리전에서 강한 쓰기 후 읽기 일관성(strong read-after-write consistency)을 기본으로 준다(AWS 발표). PUT이 성공했다는 답을 받은 뒤의 GET과 LIST는 새 내용을 본다. 키 하나의 갱신은 원자적이어서 읽는 쪽은 옛 것이나 새 것을 받지, 반쯤 쓴 것을 받지 않는다. 그러나 키 여러 개를 한꺼번에 바꾸는 트랜잭션은 없고, 같은 키에 동시에 쓰면 나중 것이 이긴다(last-writer-wins). 버킷 설정 변경은 여전히 최종 일관성이다.

동시에 쓰는 문제를 앱이 직접 막으려면 조건부 쓰기를 쓴다. PUT에 If-None-Match: *를 붙이면 "그 키가 없을 때만", If-Match: ETag를 붙이면 "내가 읽은 그 버전일 때만" 쓰고, 조건이 틀리면 412 Precondition Failed로 거절한다(S3 조건부 요청). 데이터베이스의 낙관적 잠금과 같은 생각이다(데이터베이스 노트).

버전 관리(versioning)를 켜면 덮어쓰기는 새 버전을 만들고 옛 버전은 남는다. 버전 ID 없이 지우면 실제로 지우는 대신 삭제 표시(delete marker)를 맨 위에 얹으니, 표시만 걷으면 되살아난다(S3 버전 관리). 여기에 오브젝트 잠금(Object Lock)을 걸면 정한 기간 동안 그 버전을 지우거나 덮어쓸 수 없는 WORM(write once, read many) 저장이 된다. 거버넌스 모드는 특별 권한이 있는 사용자가 풀 수 있고, 컴플라이언스 모드는 루트 계정도 기간이 끝나기 전에는 못 지운다(S3 오브젝트 잠금). 랜섬웨어가 관리자 권한을 쥐어도 지우지 못하는 백업을 만들 때 이 기능을 쓴다.

비교와 고르는 법

같은 클라우드 안에서도 세 갈래의 지연은 자릿수가 다르다. AWS 문서가 밝힌 값으로 보면 EBS io2는 0.5ms 미만, EFS는 읽기 약 1ms·쓰기 약 2.7ms(EFS 성능), S3는 작은 오브젝트에 약 100~200ms다. 오브젝트는 요청 하나는 느려도 동시에 수천 개를 보내면 전체 처리량은 오히려 가장 크다.

세 큰 클라우드는 같은 세 갈래를 이름만 달리해 판다. Azure는 Azure Storage 소개에서, Google Cloud는 Compute Engine 디스크, Filestore, Cloud Storage 문서에서 각각 설명한다.

고르는 기준은 앱이 데이터를 어떻게 고치느냐다. 작은 조각을 자주 고치고 서버 한 대가 쓰면(데이터베이스, VM) 블록이다. 여러 서버가 같은 파일을 경로로 열어야 하고 기존 프로그램을 고칠 수 없으면 파일이다. 한 번 쓰고 여러 번 읽으며, 양이 끝없이 늘고, 웹이나 여러 지역에서 접근하면(사진, 영상, 백업, 분석용 원본) 오브젝트다. 실무는 섞어 쓴다. 데이터베이스는 블록 위에서 돌고, 그 백업은 오브젝트로 보내며, 사람들이 나눠 보는 문서는 파일 공유에 둔다.