2. 스토리지 아키텍처 기초 — DAS / NAS / SAN / Object Storage
DAS, NAS, SAN, Object Storage의 구조와 차이를 아스키 도표와 함께 정리한다. 어떤 워크로드에 어떤 방식을 선택하는가의 판단 기준과 벤더별 제품 포지셔닝까지.
"이 서버에 스토리지 연결해 주세요."
이 요청을 받으면 가장 먼저 드는 질문이 있다. "어떤 방식으로?" DAS로 붙일 건지, NAS로 공유할 건지, SAN으로 블록을 줄 건지. 이 판단이 뒤에 오는 모든 설계를 결정한다. 프로토콜, 네트워크 구성, 이중화 방식, 성능 특성, 심지어 장애 대응 방법까지 다 달라진다.
스토리지 아키텍처의 네 가지 기본형을 정리해본다. 교과서적인 정의보다는 "어떤 상황에서 뭘 선택하는가"에 초점을 맞춘다.
DAS — 서버에 직접 꽂는다
DAS는 Direct Attached Storage. 말 그대로 서버에 스토리지를 직접 붙이는 거다.
┌──────────┐ SATA/SAS/NVMe ┌──────────┐
│ 서버 A │◄══════════════════════►│ 디스크 │
└──────────┘ └──────────┘
서버 하나에 디스크가 직접 연결된다.
다른 서버는 이 디스크에 접근할 수 없다.내장 디스크가 DAS의 가장 단순한 형태다. 서버 안에 HDD나 SSD를 꽂으면 그게 DAS다. 외장 JBOD(Just a Bunch Of Disks)를 SAS 케이블로 연결하는 것도 DAS다.
DAS의 장점은 명확하다. 단순하고 빠르다. 중간에 네트워크가 없으니 레이턴시가 낮다. NVMe SSD를 직접 꽂으면 마이크로초 단위 응답이 나온다.
단점도 명확하다. 공유가 안 된다. 서버 A에 붙은 디스크를 서버 B에서 접근할 수 없다. 서버가 죽으면 디스크에 접근할 방법이 없다. 확장도 서버 내부 슬롯 수에 제한된다.
DAS가 여전히 쓰이는 곳은 확실하다. 단일 서버 DB에서 최저 레이턴시가 필요할 때, 빅데이터 클러스터에서 데이터 로컬리티가 중요할 때(HDFS가 대표적), GPU 서버에서 로컬 NVMe로 학습 데이터를 캐싱할 때.
SAN — 블록을 네트워크로 공유한다
SAN은 Storage Area Network. 스토리지 전용 네트워크를 구축해서 서버들이 스토리지의 "블록"에 접근하는 방식이다.
┌──────────┐ ┌─────────────────┐
│ 서버 A │──FC/iSCSI──┐ │ 스토리지 │
└──────────┘ │ │ ┌───────────┐ │
▼ │ │ LUN 001 │ │
┌──────────┐ ┌──────────────┐ │ ├───────────┤ │
│ 서버 B │────►│ FC Switch │◄────────►│ │ LUN 002 │ │
└──────────┘ │ (Fabric) │ │ ├───────────┤ │
└──────────────┘ │ │ LUN 003 │ │
┌──────────┐ ▲ │ └───────────┘ │
│ 서버 C │──FC/iSCSI──┘ └─────────────────┘
└──────────┘
각 서버는 FC Switch(Fabric)를 통해 스토리지의 LUN에 접근한다.
블록 레벨 접근이므로, 서버가 직접 파일시스템을 올린다.핵심 개념은 "블록 레벨"이다. 스토리지가 서버에 제공하는 건 "디스크처럼 보이는 블록 디바이스"다. 서버 입장에서는 로컬 디스크처럼 보인다. 파일시스템(ext4, XFS)을 직접 만들고, 직접 마운트한다. 스토리지는 블록만 제공하고, 파일시스템은 서버의 영역이다.
SAN의 전송 프로토콜은 크게 두 가지다.
┌─────────────────────────────────────────────────────┐
│ SAN 프로토콜 비교 │
├──────────────┬──────────────────┬────────────────────┤
│ │ FC (Fibre │ iSCSI │
│ │ Channel) │ │
├──────────────┼──────────────────┼────────────────────┤
│ 네트워크 │ 전용 FC Fabric │ 기존 이더넷 │
│ 속도 │ 16/32/64 Gbps │ 10/25/100 GbE │
│ 레이턴시 │ 매우 낮음 │ FC보다 약간 높음 │
│ 비용 │ 높음 (전용장비) │ 상대적으로 낮음 │
│ 관리 복잡도 │ Zoning 필요 │ IP 기반, 친숙함 │
│ 주 사용처 │ 미션 크리티컬 DB │ 중소규모, 가상화 │
└──────────────┴──────────────────┴────────────────────┘FC SAN은 여전히 대규모 엔터프라이즈 환경의 표준이다. 전용 네트워크라 다른 트래픽과 간섭이 없고, 레이턴시가 예측 가능하다. 대신 FC Switch(Brocade, Cisco MDS)를 별도로 구매하고 관리해야 하니 비용이 든다.
iSCSI는 기존 이더넷 위에서 돌아간다. FC Switch를 살 필요가 없다. 올플래시 시대에 들어오면서 "iSCSI 성능이 FC에 비해 떨어진다"는 인식이 많이 바뀌었다. 25GbE 이상이면 대부분의 워크로드에서 충분하다.
하지만 단점도 분명하다. TCP/IP 위에서 돌아가기 때문에 프로토콜 오버헤드가 FC보다 크고, 네트워크 혼잡(congestion) 시 IO 레이턴시가 급격히 튀는 문제가 있다. 장애 관점에서 가장 큰 차이는 경로 장애 감지 속도다. FC는 Fabric 레벨에서 수 초 이내에 경로 단절을 감지하지만, iSCSI는 TCP 타임아웃에 의존하기 때문에 경로 전환에 수십 초가 걸릴 수 있다. 미션 크리티컬 DB처럼 IO 중단이 치명적인 워크로드에서 iSCSI를 쓸 때는 이 점을 반드시 고려해야 한다. 또한 전용 VLAN을 안 잡고 일반 트래픽과 섞어버리면 성능이 들쭉날쭉해진다.
NAS — 파일을 네트워크로 공유한다
NAS는 Network Attached Storage. 파일 레벨로 공유한다는 게 SAN과의 핵심 차이다.
┌──────────┐ ┌──────────────────┐
│ 서버 A │──NFS/SMB──┐ │ NAS 스토리지 │
└──────────┘ │ │ │
▼ │ /share/project │
┌──────────┐ ┌────────────┐ │ /share/home │
│ 서버 B │────►│ 이더넷 │◄──────►│ /share/backup │
└──────────┘ │ 스위치 │ │ │
└────────────┘ │ NAS가 파일시스템 │
┌──────────┐ ▲ │ 을 직접 관리한다 │
│ 서버 C │──NFS/SMB──┘ └──────────────────┘
└──────────┘
SAN: 서버가 파일시스템을 관리한다 (블록만 받음)
NAS: 스토리지가 파일시스템을 관리한다 (파일/디렉토리를 공유)SAN에서는 서버가 블록을 받아서 직접 파일시스템을 올린다. NAS에서는 스토리지가 파일시스템을 관리하고, 서버는 네트워크를 통해 파일과 디렉토리에 접근한다. 이 차이가 생각보다 크다.
NAS의 장점은 여러 서버가 동시에 같은 파일에 접근할 수 있다는 거다. SAN의 블록 디바이스를 두 서버에 동시에 마운트하면 파일시스템이 깨진다(클러스터 파일시스템 없이는). NAS는 그런 걱정 없이 여러 서버가 같은 디렉토리를 공유할 수 있다.
단점도 있다. SAN(블록)에 비해 레이턴시가 높다. 파일시스템 레이어가 스토리지 측에 한 겹 더 있으니 당연하다. 랜덤 IO가 심한 OLTP DB에 NAS를 쓰면 성능이 안 나올 수 있다. 또한 파일 수가 수백만 개를 넘으면 메타데이터 처리가 병목이 된다. 디렉토리 하나에 파일 100만 개를 넣고 ls를 치면 한참 걸린다. 장애 관점에서는 NFS 서버가 응답을 멈추면 클라이언트 측에서 IO hang이 발생하는데, hard mount일 경우 무한 대기 상태에 빠질 수 있다. 이건 서비스 장애로 직결된다.
NAS 프로토콜은 크게 NFS와 SMB다.
┌─────────────────────────────────────────────────────┐
│ NAS 프로토콜 비교 │
├──────────────┬──────────────────┬────────────────────┤
│ │ NFS │ SMB │
├──────────────┼──────────────────┼────────────────────┤
│ 주 환경 │ Linux/Unix │ Windows │
│ 현재 버전 │ NFSv4.1/4.2 │ SMB 3.1.1 │
│ 인증 │ Kerberos/AUTH_SYS│ AD 연동 │
│ 잠금(Lock) │ v4부터 상태 유지 │ 기본 지원 │
│ 멀티채널 │ pNFS (v4.1) │ SMB 멀티채널 │
│ 사용 예 │ 웹서버 콘텐츠, │ 파일서버, │
│ │ VMware NFS 데이터│ Windows 홈폴더, │
│ │ 스토어, 개발환경 │ Hyper-V 스토리지 │
└──────────────┴──────────────────┴────────────────────┘NAS가 쓰이는 대표적인 곳은 홈 디렉토리 공유, 개발 환경의 소스코드 공유, 미디어 파일 저장, VMware의 NFS 데이터스토어 등이다. "여러 서버가 같은 파일에 접근해야 하는" 워크로드에서 NAS가 답이다.
Object Storage — 파일도 블록도 아닌, 오브젝트
Object Storage는 비교적 새로운 패러다임이다. 파일 시스템의 계층 구조(디렉토리/폴더)를 버리고, 모든 데이터를 "오브젝트"라는 단위로 플랫하게 저장한다.
┌───────────────────────────────────────────────────────┐
│ 전통 파일시스템 vs Object Storage │
├─────────────────────────┬─────────────────────────────┤
│ 파일시스템 (NAS) │ Object Storage │
│ │ │
│ / │ ┌──────────────────────┐ │
│ ├── home/ │ │ 버킷: my-bucket │ │
│ │ ├── user1/ │ │ │ │
│ │ │ └── doc.txt │ │ obj-001 (doc.txt) │ │
│ │ └── user2/ │ │ obj-002 (image.jpg) │ │
│ ├── var/ │ │ obj-003 (log.gz) │ │
│ │ └── log/ │ │ obj-004 (backup.tar)│ │
│ └── backup/ │ │ │ │
│ └── 2024/ │ │ → 계층 구조 없음 │ │
│ └── dump.tar │ │ → HTTP/S3 API 접근 │ │
│ │ └──────────────────────┘ │
│ → 디렉토리 트리 구조 │ → 플랫한 Key-Value 구조 │
│ → POSIX API │ → REST API (S3 호환) │
└─────────────────────────┴─────────────────────────────┘접근 방식이 근본적으로 다르다. 파일시스템에서는 /home/user1/doc.txt라는 경로로 접근한다. Object Storage에서는 GET https://s3.example.com/my-bucket/doc.txt 같은 HTTP 요청으로 접근한다.
왜 이런 구조를 만들었을까? 스케일 때문이다. 파일시스템의 디렉토리 트리는 파일이 수억 개가 되면 메타데이터 관리가 병목이 된다. Object Storage는 플랫한 구조 덕분에 페타바이트, 수십억 개의 오브젝트까지 수평 확장이 가능하다.
Object Storage가 쓰이는 대표적인 곳은 백업 타겟(스토리지 스냅샷 → S3 아카이빙), 비정형 데이터(이미지, 영상, 로그), 클라우드 네이티브 애플리케이션의 데이터 저장소, 장기 보관(아카이빙/컴플라이언스)이다.
단점도 명확하다. 레이턴시가 높다. HTTP REST 기반이라 블록이나 파일 프로토콜에 비해 수~수십 밀리초의 오버헤드가 있다. 실시간 트랜잭션 DB에는 쓸 수 없다. POSIX 호환이 안 되기 때문에 기존 애플리케이션을 그대로 올릴 수 없고, S3 API에 맞게 애플리케이션을 수정해야 한다. 또한 대부분의 Object Storage는 eventual consistency 모델이라, 쓰기 직후 읽기에서 최신 데이터가 보장되지 않을 수 있다(AWS S3는 2020년부터 strong consistency를 지원하지만, 온프레미스 구현은 다를 수 있다). 오브젝트 수정도 제약이 있다 — 파일의 일부만 바꾸는 게 안 되고, 전체를 다시 업로드해야 한다.
온프레미스에서도 S3 호환 Object Storage를 쓸 수 있다. MinIO, NetApp StorageGRID, Dell ECS 같은 것들이다.
통합 스토리지 — SAN + NAS를 한 장비에서
현실에서는 SAN도 필요하고 NAS도 필요한 경우가 대부분이다. DB는 블록 스토리지(SAN)가 필요하고, 파일 공유는 NAS가 필요하다. 장비를 따로따로 사면 관리 포인트가 두 배가 된다.
그래서 나온 게 통합 스토리지(Unified Storage)다.
┌──────────────────────────┐
│ 통합 스토리지 │
│ │
서버A ──FC──────► │ ┌──────┐ ┌──────────┐ │
│ │ SAN │ │ │ │
서버B ──iSCSI───► │ │ 블록 │ │ 공통 │ │
│ └──────┘ │ 스토리지 │ │
서버C ──NFS─────► │ ┌──────┐ │ 풀 │ │
│ │ NAS │ │ │ │
서버D ──SMB─────► │ │ 파일 │ │ │ │
│ └──────┘ └──────────┘ │
└──────────────────────────┘
하나의 장비에서 블록(FC/iSCSI)과 파일(NFS/SMB)을 동시에 서비스한다.NetApp ONTAP이 통합 스토리지의 대표 주자다. 하나의 장비에서 FC, iSCSI, NFS, SMB를 다 서비스할 수 있다. Dell PowerStore도 통합 스토리지를 지향한다. 반면 Pure Storage FlashArray는 블록 전문, FlashBlade는 파일/오브젝트 전문으로 나뉜다.
통합 스토리지의 장점은 관리 포인트가 줄어든다는 거다. 장비 한 대, 관리 도구 하나, 유지보수 계약 하나. 단점은 "모든 걸 잘하기는 어렵다"는 거다. 블록 전문 장비에 비하면 블록 성능이 약간 떨어질 수 있고, NAS 전문 장비에 비하면 파일 성능이 약간 떨어질 수 있다. 이건 워크로드에 따라 판단해야 한다.
어떤 워크로드에 뭘 쓰는가
이 질문이 결국 가장 중요하다. 의사결정 흐름을 정리하면 이렇다.
워크로드 특성은?
│
├── 블록 디바이스 필요 (DB, 가상화 VMDK)
│ │
│ ├── 최저 레이턴시, 단일 서버 ──────► DAS (NVMe)
│ │
│ ├── 여러 서버 공유, 미션 크리티컬 ──► SAN (FC)
│ │
│ └── 여러 서버 공유, 비용 중시 ──────► SAN (iSCSI)
│
├── 파일 공유 필요 (다수 서버가 동시 접근)
│ │
│ ├── Linux 환경 위주 ────────────────► NAS (NFS)
│ │
│ └── Windows 환경 위주 ──────────────► NAS (SMB)
│
├── 대용량 비정형 데이터 (이미지, 로그, 백업)
│ └──────────────────────────────────► Object Storage (S3)
│
└── HPC / AI 학습 (대규모 병렬 IO)
└──────────────────────────────────► 병렬 파일시스템 (3편)현실에서는 하나만 쓰는 경우가 드물다. 대부분의 데이터센터에는 SAN, NAS, Object Storage가 공존한다. DB는 SAN에, 파일 공유는 NAS에, 백업 아카이빙은 Object Storage에. 이 구조를 이해하는 게 출발점이다.
┌───────────────────────────────────────────────────────┐
│ 벤더별 제품 포지셔닝 │
├──────────┬────────────┬──────────┬──────────┬─────────┤
│ │ Dell EMC │ NetApp │ HPE │ Pure │
├──────────┼────────────┼──────────┼──────────┼─────────┤
│ SAN │ PowerStore │ AFF/FAS │ Alletra │ Flash │
│ (블록) │ PowerMax │ (ONTAP) │ MP │ Array │
├──────────┼────────────┼──────────┼──────────┼─────────┤
│ NAS │ PowerScale │ AFF/FAS │ Alletra │ Flash │
│ (파일) │ (Isilon) │ (ONTAP) │ MP │ Blade │
├──────────┼────────────┼──────────┼──────────┼─────────┤
│ Object │ ECS │ Storage │ — │ Flash │
│ │ │ GRID │ │ Blade │
├──────────┼────────────┼──────────┼──────────┼─────────┤
│ 통합 │ PowerStore │ ONTAP │ Alletra │ — │
│ │ │ (기본) │ MP │ (분리) │
└──────────┴────────────┴──────────┴──────────┴─────────┘
NetApp ONTAP은 태생이 통합(NAS+SAN).
Pure Storage는 블록(FlashArray)과 파일(FlashBlade)을 분리.다음 편에서는 SAN/NAS로 커버가 안 되는 영역 — 병렬 파일 시스템과 분산 스토리지를 다룬다. Lustre, GPFS, HDFS, Ceph. HPC와 빅데이터, 그리고 AI 학습 워크로드에서 왜 이것들이 필요한지 이야기한다.
이 글이 어떠셨나요?
관련 포스트
1. 스토리지, 왜 어렵고 왜 중요한가
서버는 죽어도 살리면 되지만 스토리지는 잃으면 끝이다. 10년차 시스템 엔지니어가 스토리지가 어렵고 중요한 이유, 스토리지 담당자의 실제 업무, 기술의 진화 흐름을 현장 경험 기반으로 풀어본다.
2026. 03. 30. 오후 10:00Infrastructure시스템 엔지니어를 위한 NVIDIA 서버 GPU 세대별 가이드 — Tesla에서 Rubin까지, 꼭 알아야 할 개념들
NVIDIA 서버 GPU의 역사를 세대별로 따라가며, 각 세대에서 등장한 핵심 개념(CUDA, Tensor Core, NVLink, MIG, Transformer Engine, HBM)이 왜 중요하고 시스템 엔지니어에게 어떤 의미가 있는지를 정리한 글.
2026. 04. 04. 오후 01:20Infrastructure서버가 켜지는 동안 무슨 일이 벌어지는가 — 시스템 엔지니어를 위한 OS 부팅 과정
전원 버튼을 누르고 SSH가 될 때까지 2분. 그 사이에 HW와 SW가 어떻게 제어권을 주고받는지, BMC부터 systemd까지 각 단계가 왜 존재하고 무슨 일을 하는지를 정리한 글.
2026. 04. 03. 오후 10:00뉴스레터 구독
새 글이 올라오면 이메일로 알려드려요.