공유폴더가 필요해서 스토리지를 알아보는데 DAS, NAS, SAN이 함께 등장하면 무엇부터 비교해야 할지 막막해진다. 세 방식은 저장 용량의 크기나 장비의 등급을 뜻하지 않는다. 저장장치를 어디에 연결하고, 사용하는 시스템에 어떤 형태로 제공하는지가 핵심이다.
이 글은 사내 문서 공유, 단일 서버 증설, 가상화용 저장공간을 검토하는 담당자를 위한 비교다. 연결 구조를 이해한 뒤 업무의 접근 방식과 장애 영향을 기준으로 선택할 수 있도록 정리한다.
저장 매체와 접근 방식을 나누어 이해
HDD와 SSD는 데이터를 기록하는 매체다. DAS·NAS·SAN은 그 저장공간을 시스템에 연결하거나 제공하는 방식을 설명한다. 따라서 SSD를 사용했다고 SAN이 되는 것도 아니고, 디스크가 여러 개라고 NAS가 되는 것도 아니다.
일반적인 파일 저장 경로는 애플리케이션, 파일시스템, 블록 장치, 저장 매체로 이어진다. 파일시스템은 파일 이름·폴더·저장 위치를 관리하며, 블록 장치는 정해진 크기의 영역에 대한 읽기·쓰기를 제공한다. 블록 장치 위에 파일시스템을 두거나 데이터베이스 등이 직접 사용하는 방식은 구성에 따라 달라진다.
비교할 때는 두 가지를 구분한다. 첫째는 호스트에 직접 연결하는지 네트워크를 거치는지다. 둘째는 사용하는 쪽이 파일·폴더에 접근하는지, 디스크처럼 보이는 블록 장치에 접근하는지다. 파일 접근과 블록 접근의 구분은 Red Hat의 스토리지 설명과 파일시스템 문서에서 확인할 수 있다. [4][5]
DAS: 서버에 직접 연결하는 저장공간
DAS(Direct Attached Storage)는 저장장치를 호스트에 직접 연결하는 방식이다. 서버 내부 디스크와 직접 연결한 외장 저장장치가 대표적이다. SNIA 역시 서버에 로컬로 연결해 해당 서버에 전용으로 사용하는 저장장치라는 관점에서 정의한다. [1]
일반적인 디스크형 DAS는 운영체제에 블록 장치로 보이고, 호스트가 그 위의 파일시스템을 관리한다. 내부 NVMe SSD나 SATA·SAS 디스크, USB 외장 드라이브 등이 예다. 연결이 단순해 단일 서버의 저장공간을 늘리기 쉽지만, 확장 범위는 슬롯·포트·디스크 수와 해당 호스트의 구성에 영향을 받는다.
DAS에 담긴 파일을 서버가 SMB나 NFS로 공유할 수도 있다. 이때 다른 사용자는 서버가 제공하는 파일 서비스에 접속하며, DAS 자체가 독립적인 NAS로 바뀌는 것은 아니다. 그 서버가 멈추면 파일 서비스도 영향을 받을 수 있으므로 서버 장애까지 포함해 검토한다.
NAS: 네트워크로 파일과 폴더를 제공하는 방식
NAS(Network Attached Storage)는 네트워크를 통해 파일 단위 접근을 제공한다. 사용자는 공유폴더나 파일 경로에 접속하고, NAS 쪽에서 파일시스템과 공유 서비스를 관리한다. 대표적인 파일 공유 프로토콜로 SMB와 NFS가 있다. [3][5]
부서 문서와 이미지처럼 여러 사용자가 같은 파일 저장소를 이용하는 업무에 검토하기 좋다. 폴더 권한, 사용자 인증, 파일 잠금, 백업 기능은 제품과 설정에 따라 확인해야 한다. 공유폴더에 접근할 수 있다는 사실만으로 문서의 실시간 공동 편집이나 버전 관리까지 보장되지는 않는다.
성능이 부족할 때는 디스크뿐 아니라 NAS의 처리 자원, 네트워크 대역폭, 동시 접속, 작은 파일의 개수도 함께 살핀다. NAS라는 이름만으로 느리다고 판단할 수 없으며, 기업용 확장형 NAS와 소형 NAS의 구성도 같지 않다.
SAN: 네트워크 너머의 블록 장치를 서버에 제공하기
SAN(Storage Area Network)은 서버와 저장장치를 연결하는 스토리지 네트워크다. 일반적인 블록 스토리지 구성에서는 서버가 원격 저장공간을 로컬 디스크와 유사한 장치로 인식한다. Fibre Channel뿐 아니라 Ethernet 기반 방식도 있으며, iSCSI는 IP 네트워크로 블록 접근을 제공하는 대표적인 예다. [2][4]
서버에는 LUN 등으로 제공되는 논리 저장공간이 보이고, 호스트나 가상화 계층이 용도에 맞게 사용한다. 여러 서버에 저장공간을 배분하거나 데이터 경로를 이중화하는 구성을 설계할 수 있다. 다만 장비가 지원한다는 것과 실제 장애 전환이 검증됐다는 것은 별개다.
같은 LUN을 여러 서버에 연결했다고 일반 파일시스템을 동시에 읽고 써도 되는 것은 아니다. 동시 쓰기가 필요하면 클러스터 파일시스템이나 애플리케이션의 공유 접근 제어 등 지원되는 구성을 사용해야 한다. Red Hat 문서는 공유 블록 장치에서 일관성을 유지하려면 클러스터 전체의 잠금 조정이 필요하다고 설명한다. [5]
DAS·NAS·SAN 비교
아래는 일반적인 디스크 스토리지 구성을 비교한 표다. 하나의 장비가 파일 서비스와 블록 서비스를 함께 제공할 수도 있으므로, 제품명보다 실제로 사용하는 접속 방식을 확인한다. [4]
| 비교 항목 | DAS | NAS | SAN |
|---|---|---|---|
| 기본 연결 | 호스트에 직접 연결 | 파일 서비스를 네트워크로 이용 | 스토리지 네트워크로 연결 |
| 사용하는 쪽의 접근 | 일반적으로 블록 장치 | 파일·폴더 | 일반적으로 블록 장치 |
| 파일시스템 관리 위치 | 연결된 호스트 | NAS 서비스 측 | 호스트·가상화 계층 등 |
| 대표 연결·프로토콜 | SATA·SAS·NVMe·USB 등 | SMB·NFS 등 | Fibre Channel·iSCSI 등 |
| 검토할 업무 | 단일 서버 저장공간 | 부서 파일 공유 | 공유 블록 스토리지 기반 업무 |
| 주요 확인점 | 호스트 장애·확장 한계 | 공유 권한·동시 사용·네트워크 | 경로 관리·접근 통제·동시 쓰기 |
가상 예시로 보는 업무별 선택
다음은 특정 기업의 구축 사례가 아닌 가상 예시다. 같은 회사에서도 용도가 다르면 서로 다른 방식을 함께 사용할 수 있다.
- 부서 문서 공유: 여러 직원이 폴더에 접근하는 목적이라면 NAS 또는 파일 서버를 먼저 검토한다. 퇴사자 권한 회수, 부서 간 접근 제한, 삭제 파일 복구 방법을 함께 정한다.
- 독립적인 분석 서버: 파일을 다른 서버와 공유할 필요가 없고 분석 프로그램이 한 서버에서 실행된다면 DAS가 후보가 된다. 서버 고장 시 데이터를 어디에서 복원할지도 정한다.
- 여러 가상화 호스트: 공유 블록 저장공간이 요구되면 SAN을 검토한다. 플랫폼이 지원하는 NAS 데이터스토어도 후보가 될 수 있으므로, 가상화라는 이유만으로 SAN을 확정하지 않는다. [4]
실무자 관점: 장비 등급보다 장애 범위를 확인
도입 검토에서는 먼저 애플리케이션이 요구하는 접근 방식과 지원 구성을 확인하는 편이 효율적이다. 그다음 예상 동시 사용자, 읽기·쓰기 패턴, 허용 지연, 용량 증가를 적어 실제 업무와 비슷한 조건에서 검증한다. SAN이 항상 NAS보다 빠르다는 식의 서열로는 이 조건을 설명할 수 없다.
장애 검토는 디스크에서 끝내지 않는다. DAS는 연결된 호스트, NAS는 파일 서비스와 네트워크, SAN은 호스트 어댑터·스위치·컨트롤러·경로까지 추적한다. 이중 경로가 있더라도 한쪽을 끊었을 때 업무가 유지되는지와 복구 후 정상 경로로 돌아오는지 확인해야 한다.
접근 통제도 계층별로 나눈다. NAS의 공유폴더 권한과 SAN의 호스트별 볼륨 접근 통제는 역할이 다르다. SAN에서 저장공간을 특정 서버에만 보이게 해도, 그 서버 안의 사용자·애플리케이션 권한까지 자동으로 정해지지는 않는다.
이 글의 운영상 권고는 저장공간 구성과 별도로 복구 사본을 설계하는 것이다. RAID는 구성에 따라 일부 디스크 고장에 대비하지만 파일 오삭제나 랜섬웨어 피해의 이전 상태를 보관하는 백업을 대신하지 않는다. 복구 지점 목표(RPO: 허용 가능한 데이터 손실 시간)와 복구 시간 목표(RTO: 업무 복구까지의 목표 시간)를 정하고, 별도 보관 사본에서 실제 복원이 되는지 확인한다.
결론: 파일 공유와 블록 접근 요구부터 확정하기
선택의 출발점은 용량 견적서가 아니라 업무가 저장공간을 사용하는 방법이다. 단일 호스트에 직접 연결할 목적이면 DAS, 여러 사용자의 파일 공유가 목적이면 NAS, 네트워크를 통한 블록 장치 제공이 요구되면 SAN을 우선 검토할 수 있다.
최종 결정에는 애플리케이션의 지원 구성, 동시 쓰기 제어, 장애 영향, 복구 목표를 함께 반영한다. 요구사항을 충족하고 운영팀이 장애와 복구를 검증할 수 있는 구성이 적합한 선택이다.