블록·파일·오브젝트 스토리지의 데이터 접근방식
1. 개요
가. 정의
데이터를 저장·접근하는 최소 단위(Unit of Access) 와 인터페이스에 따라 스토리지를 블록(Block)·파일(File)·오브젝트(Object) 로 구분하며, 각기 접근 방식·확장성·용도가 다르다.
세 방식의 본질적 차이는 "누가 데이터를 어떤 단위로 다루느냐"에 있다. 블록은 파일시스템이라는 구조를 스토리지가 제공하지 않고 원시(raw) 블록만 노출해 상위 OS가 직접 구조를 얹는다. 파일은 스토리지가 이미 파일시스템을 갖고 경로·계층을 제공한다. 오브젝트는 계층 구조 자체를 버리고 고유 ID와 메타데이터로 객체를 통째로 다룬다. 이 "추상화 수준의 차이"가 성능·확장성·공유성의 차이를 낳는다.
나. 등장 배경 및 필요성
초기에는 서버에 직접 붙는 블록 스토리지(DAS)만 있었으나, 여러 사용자가 파일을 공유해야 하는 요구가 커지며 파일 스토리지(NAS)가, 이어 웹 규모의 비정형 데이터(사진·로그·백업)를 사실상 무한히 저장해야 하는 요구가 커지며 오브젝트 스토리지가 등장했다. 즉 세 방식은 우열 관계가 아니라 워크로드 특성(성능·공유·확장·비용)에 맞춰 선택하는 대상이다. 데이터베이스처럼 낮은 지연이 생명인 워크로드, 팀이 문서를 함께 편집하는 워크로드, 페타바이트급 미디어를 값싸게 쌓아두는 워크로드는 각각 다른 접근 단위를 요구한다.
2. 접근방식 비교
flowchart TB
B[블록 스토리지<br/>블록 단위·SAN]
F[파일 스토리지<br/>파일/디렉터리·NAS]
O[오브젝트 스토리지<br/>객체+메타데이터·HTTP]
접근 단위가 커질수록(블록→파일→객체) 개별 요청이 담는 문맥은 풍부해지지만 그만큼 오버헤드가 커져 지연이 늘고, 반대로 구조적 결합이 느슨해져 수평 확장은 쉬워진다. 아래 표의 성능·확장성 차이는 모두 이 원리에서 파생된다.
| 구분 | 블록 | 파일 | 오브젝트 |
|---|---|---|---|
| 접근 단위 | 고정 크기 블록(LBA) | 파일(경로/계층) | 객체(고유 ID+메타데이터) |
| 인터페이스 | iSCSI·FC(SAN) | NFS·SMB(NAS) | REST API(HTTP) |
| 구조 | 논리 볼륨 | 계층적 디렉터리 | 평면적(Flat) 네임스페이스 |
| 성능 | 최고(저지연) | 중간 | 상대적 낮음(고지연) |
| 확장성 | 제한적 | 중간 | 매우 높음(무한 확장) |
| 용도 | DB·VM·트랜잭션 | 파일 공유·협업 | 백업·아카이브·미디어·빅데이터 |
3. 유형별 특징 상세
가. 블록 스토리지
블록 스토리지는 디스크를 LBA(Logical Block Address)로 지정되는 고정 크기 블록의 배열로만 제공한다. 파일이라는 개념도, 디렉터리도 스토리지 계층에는 없으며, 이를 어떻게 쓸지는 전적으로 상위 OS의 파일시스템(ext4·NTFS 등)이나 DBMS가 결정한다. 이렇게 스토리지가 최소한의 일만 하기 때문에 부가 처리가 적어 지연이 가장 낮고, 임의 위치 읽기/쓰기(random I/O)에 강하다. 대신 하나의 블록 볼륨은 원칙적으로 한 호스트에 마운트되어 동시 공유가 어렵다. iSCSI·FC 기반 SAN으로 연결하며, 데이터베이스 데이터 파일, 가상머신 부트 디스크처럼 낮은 지연과 트랜잭션 무결성이 필요한 곳에 쓴다.
나. 파일 스토리지
파일 스토리지는 스토리지 장비 자체가 파일시스템을 갖고 경로(예: /home/user/report.docx)와 디렉터리 계층을 통해 접근하게 한다. NFS·SMB 프로토콜로 네트워크에 노출(NAS)하므로 여러 클라이언트가 같은 파일시스템을 동시에 마운트해 공유·협업할 수 있고, POSIX 파일 권한·잠금을 그대로 활용한다. 계층 구조를 탐색하는 오버헤드와 네트워크 파일 프로토콜 처리 때문에 블록보다 지연이 크며, 디렉터리가 깊고 파일 수가 수억 개로 늘면 메타데이터 관리 부담으로 확장에 한계가 온다. 부서 공유 폴더, 개발 소스 공유, 미디어 편집 협업 등에 적합하다.
다. 오브젝트 스토리지
오브젝트 스토리지는 계층 구조를 버리고 데이터를 고유 식별자(키)로 접근하는 객체 단위로 다룬다. 각 객체는 데이터 본문 + 사용자 정의 메타데이터 + 고유 ID로 구성되며, 평면적(flat) 네임스페이스에 저장된다. 디렉터리 트리를 유지·탐색할 필요가 없어 수평 확장이 사실상 무한하고, 노드를 늘리는 것만으로 페타바이트급까지 확장된다. 접근은 HTTP 기반 REST API(GET/PUT)로 하며, 파일의 일부만 수정하는 것이 아니라 객체 단위로 통째 쓰기를 한다. 요청마다 HTTP·메타데이터 처리 오버헤드가 있어 지연은 가장 크지만, 대용량·비정형·읽기 위주 데이터(백업, 로그, 이미지·영상, 데이터레이크)에는 저비용·고내구성으로 최적이다. AWS S3가 대표 사례로, 여러 데이터센터에 자동 복제해 99.999999999%(11 nines)급 내구성을 제공한다.
4. 선택 기준
접근 단위의 원리를 이해하면 선택은 자연스럽게 도출된다. 낮은 지연·랜덤 I/O가 필요하면 블록, 동시 공유·POSIX 시맨틱이 필요하면 파일, 대규모·비정형·저비용 확장이 필요하면 오브젝트다.
| 요구 | 적합 | 이유 |
|---|---|---|
| 고성능 트랜잭션(DB·VM) | 블록 | 최소 오버헤드·저지연·랜덤 I/O |
| 다중 사용자 파일 공유 | 파일 | 파일시스템·POSIX 공유 기본 제공 |
| 대규모 비정형·아카이브 | 오브젝트 | 무한 확장·메타데이터·저비용 |
5. 고려사항 및 시사점
클라우드는 이 세 방식을 각각 EBS(블록)·EFS(파일)·S3(오브젝트) 로 제공하며, 실무에서는 하나만 쓰기보다 워크로드별로 혼합(하이브리드) 하는 것이 일반적이다. 예컨대 애플리케이션 서버 DB는 블록, 팀 공유 자료는 파일, 사용자 업로드·백업은 오브젝트에 둔다. 오브젝트 스토리지는 객체 불변성(WORM)·버전 관리·수명주기 정책(Lifecycle) 으로 오래된 데이터를 저비용 계층(콜드/아카이브)으로 자동 이동시켜 비용을 최적화할 수 있다는 점이 기술사 관점의 핵심이다. 다만 오브젝트는 부분 수정·강한 트랜잭션 일관성이 약하므로, "값싸고 크게 쌓되 자주 고쳐 쓰지 않는" 데이터에 한정해 적용해야 한다.
한 줄 요약: 블록은 블록 단위(SAN)로 고성능 DB·VM, 파일은 파일 단위(NAS)로 공유, 오브젝트는 객체+메타데이터(HTTP)로 대규모 아카이브 에 적합하며, 접근 단위가 커질수록 지연은 늘고 확장성은 좋아지는 트레이드오프가 인터페이스·용도 차이를 만든다.