왜 폴더가 없는가

한 줄 요약

오브젝트 스토리지에 디렉터리는 없다. img/2026/logo.png 는 슬래시가 든 하나의 긴 키일 뿐이고, 그 사실이 확장성의 근거다.

왜 이게 필요했나

파일시스템은 트리입니다. 디렉터리마다 inode 가 있고, 파일 하나를 열려면 경로를 따라 내려가며 각 단계의 권한과 존재를 확인합니다. 이 구조가 로컬 디스크에서는 훌륭합니다. 그런데 노드 100대에 걸쳐 파일 100억 개를 두려고 하면 문제가 됩니다. 트리의 상위 노드가 모든 접근의 경합 지점이 되고, 디렉터리 하나에 파일 100만 개를 넣으면 ls 가 몇 분씩 걸립니다.

오브젝트 스토리지는 트리를 버립니다. 평평한 키-값 공간만 있습니다. 키는 그냥 문자열이고 슬래시는 특별한 의미가 없습니다. mc ls 나 콘솔이 폴더처럼 보여 주는 것은 접두어로 그룹핑한 화면일 뿐입니다.

이 단순화가 무엇을 사 주냐면, 키를 해시해서 어느 노드에 둘지 정할 수 있습니다. 중앙 디렉터리 서버가 필요 없고, 노드를 추가하면 용량과 처리량이 함께 늡니다.

어떻게 동작하나

대신 포기하는 것도 분명합니다.

첫째, 부분 수정이 없습니다. 객체는 통째로 쓰거나 통째로 읽습니다. 1GB 파일의 가운데 1바이트를 바꾸려면 1GB 를 다시 올려야 합니다. 그래서 로그 파일처럼 계속 덧붙이는 데이터에는 맞지 않습니다.

둘째, 이름 바꾸기가 없습니다. 이름 변경은 복사 후 삭제입니다. img/ 접두어를 images/ 로 바꾸려면 그 아래 모든 객체를 복사하고 지워야 합니다. 접두어 설계를 처음에 잘 해야 하는 이유입니다.

셋째, POSIX 의미론이 없습니다. 파일 잠금, 하드링크, 원자적 이름 변경 같은 것이 없습니다. 데이터베이스 파일을 오브젝트 스토리지에 두면 안 되는 이유입니다.

넷째, 목록 조회가 비쌉니다. 접두어 기반 목록은 가능하지만 "크기가 1MB 이상인 것"이나 "어제 수정된 것"을 찾으려면 전부 훑어야 합니다. 메타데이터 검색이 필요하면 별도 색인을 둡니다.

현장에서 만나는 모습

접두어 설계에서 자주 하는 실수가 날짜를 맨 앞에 두는 것입니다. 2026-08-20/user/... 로 하면 그날 들어오는 모든 쓰기가 같은 접두어 범위에 몰립니다. 파티셔닝이 키 순서에 기반한 구현에서는 이것이 핫스팟이 됩니다. 앞자리에 흩어지는 값(사용자 ID 해시 앞 두 글자 등)을 두는 편이 안전합니다.

그리고 오브젝트 스토리지에 진짜로 맞는 워크로드를 기억해 두면 좋습니다 — 한 번 쓰고 여러 번 읽는 크고 불변인 데이터입니다. 이미지, 동영상, 백업, 학습 데이터셋, 빌드 산출물. 반대로 자주 부분 수정되는 작은 데이터는 데이터베이스가 맞습니다.

다음 실습에서 할 것

로컬 S3 호환 서버에 별칭을 붙이고 버킷을 만들고 객체를 올리고 접두어로 정리합니다. ETag 가 무엇인지 로컬 md5 와 비교해 확인하고, 서버 사이드 복사와 Content-Type 지정까지 다뤄 봅니다.