안녕하세요.
강준수입니다.
오늘은 헷갈렸던 용어를 정리해보겠습니다.
1. 파일 스토리지와 객체 스토리지
파일 스토리지와 객체 스토리지는 데이터를 저장하고 관리하는 방식(Architecture) 자체가 완전히 다릅니다.
보안 설계나 클라우드 인프라를 구축할 때 이 차이를 아는 것이 매우 중요한데요,
가장 쉬운 비유로 시작해 보겠습니다.
- 파일 스토리지: 도서관의 서가 (계층 구조)
- 객체 스토리지: 발렛 파킹의 주차권 (평면 구조)
1. 파일 스토리지 (File Storage)
우리가 윈도우나 맥에서 사용하는 '폴더' 방식입니다.
- 구조: 폴더 안에 폴더가 있는 계층적(Hierarchical) 구조입니다. 데이터를 찾으려면 경로(Path)를 알아야 합니다. (예: /Users/Documents/Project/security_plan.pdf)
- 장점: 인간이 이해하기 직관적이고, 파일의 일부분만 수정(수정 모드)하는 것이 빠릅니다.
- 단점: 파일이 수백만, 수천만 개로 늘어나면 경로를 찾는 속도가 급격히 느려집니다. (성능의 한계)
- 사용 예시: NAS(Network Attached Storage), 공유 문서함, 로컬 하드 드라이브.
2. 객체 스토리지 (Object Storage)
클라우드 시대에 가장 각광받는 방식입니다. (AWS S3, Google Cloud Storage 등)
- 구조: 데이터를 '객체(Object)'라는 단위로 쪼개서 평면적인(Flat) 공간에 무작위로 던져 넣습니다. 대신 각 객체는 고유한 **ID(Key)**와 상세한 메타데이터를 가집니다.
- 장점: * 무한 확장성: 데이터가 몇 조 개가 되어도 ID만 알면 바로 찾을 수 있어 성능 저하가 없습니다.
- 풍부한 메타데이터: 파일 이름 외에도 '누가 만들었는지', '보안 등급은 무엇인지' 등 커스텀 정보를 무제한으로 넣을 수 있어 데이터 분석에 유리합니다.
- 단점: 파일의 일부분만 수정하는 것이 불가능합니다. 점 하나만 찍어도 전체 파일을 다시 업로드해야 합니다. (수정보다는 '읽기' 위주에 적합)
- 사용 예시: 사진/동영상 스트리밍 서비스, 로그 백업, 빅데이터 분석용 데이터 레이크.
요약 및 비교표
| 구분 | 파일 스토리지 (File) | 객체 스토리지 (Object) |
| 저장 구조 | 계층적 (폴더/트리) | 평면적 (버킷/ID) |
| 접근 방식 | 파일 경로 (Path) | 고유 ID (Key/API) |
| 확장성 | 제한적 (규모가 커지면 복잡) | 거의 무제한 |
| 데이터 수정 | 부분 수정 가능 | 전체 덮어쓰기만 가능 |
| 비용 | 상대적으로 고가 | 매우 저렴 |
| 주요 용도 | 업무용 문서 공유, OS 구동 | 대규모 미디어 파일, 백업, AI 학습 데이터 |
사실 기존 IDC(데이터 센터) 환경에서는 객체 스토리지보다는
파일 스토리지(NAS)나 블록 스토리지(SAN)가 압도적으로 많이 쓰였습니다.
객체 스토리지는 IDC 시절에도 존재는 했지만, 지금처럼 '대세'는 아니었죠.
그 이유를 세 가지 측면에서 짚어보겠습니다.
1. 기술적 성격: "속도보다는 용량"
과거 IDC 환경의 핵심은 정형 데이터(DB)와 빠른 파일 처리였습니다.
- 파일/블록 스토리지: 서버와 직접 연결되어 아주 빠른 입출력(I/O) 성능을 보여줍니다. 윈도우나 리눅스 OS가 바로 인식할 수 있는 형태라 호환성도 좋았죠.
- 객체 스토리지: 데이터가 수만 개일 때는 파일 스토리지보다 느립니다. 과거엔 지금처럼 페타바이트(PB) 단위의 비정형 데이터(영상, 이미지, 로그)가 쏟아지는 환경이 드물었기 때문에, 굳이 복잡한 API 방식의 객체 스토리지를 쓸 이유가 적었습니다.
2. 접근 방식의 차이: "드라이브 vs API"
- 기존 방식: 서버에 하드디스크를 꽂거나 네트워크 드라이브(NFS, SMB)를 연결(Mount)해서 썼습니다.
- 객체 방식: 데이터를 가져오려면 HTTP 통신(REST API)을 해야 합니다. 예전 개발 환경에서는 파일을 읽고 쓸 때 File.open() 같은 시스템 명령어를 썼지, 웹 호출을 통해 파일을 주고받는 방식은 번거로운 작업이었습니다.
3. 하이퍼스케일러(클라우드)의 등장
객체 스토리지가 '필수'가 된 건 구글, 아마존 같은 클라우드 기업들이 등장하면서부터입니다.
- 전 세계에서 쏟어지는 데이터를 저장하려면 기존 NAS 장비로는 확장에 한계가 있었습니다.
- 그래서 구글은 GCS, 아마존은 S3라는 이름으로 객체 스토리지를 서비스화했고, 이것이 클라우드 네이티브 환경의 표준이 되었습니다.
물론 IDC에서도 객체 스토리지를 쓰는 경우가 있었는데, 주로 다음과 같은 특수 목적이었습니다.
- 컴플라이언스 백업: 금융권 등에서 법적 근거로 데이터를 5~10년 이상 보관해야 할 때, 저렴한 비용으로 대용량을 저장하기 위해 도입했습니다. (WORM: Write Once Read Many 기능 활용)
- 대규모 웹 서비스: 대량의 이미지 파일(예: 포털 사이트의 썸네일)을 사용자에게 빠르게 뿌려줘야 하는 서비스들은 IDC 내에 OpenStack Swift나 Ceph 같은 오픈소스 기반 객체 스토리지를 직접 구축해서 사용했습니다.
파일 스토리지와 객체 스토리지의 차이점을 알아봤습니다.
오늘은 이만 여기서 마치겠습니다.
'IT거버넌스' 카테고리의 다른 글
| 개념이 헷갈리는 용어 정리 (0) | 2026.04.23 |
|---|---|
| 데이터 레이크, 데이터 웨어하우스... 이게 다 뭔지. (0) | 2026.04.21 |
| 재택근무 늘었는데… 회사 보안은 괜찮을까? (실제 해킹 흐름으로 보는 현실) (0) | 2026.04.08 |
| 2026년 보안 아키텍트의 숙제: AI-Native 시대의 방어 전략 (0) | 2026.04.07 |
| VPN과 ZTNA, 비교 분석 하기 (0) | 2026.04.05 |