SAN (Storage Area Network) - 블록 단위 전용 네트워크 접근

핵심 인사이트 (3줄 요약)

본질: SAN(Storage Area Network)은 일반적인 인터넷/사무용 TCP/IP 랜선을 타지 않고, 오직 서버(Host)와 거대 스토리지(Storage) 덩어리들만을 연결하기 위해 '블록(Block) I/O 통신' 명령어 전용의 광케이블(Fibre Channel)과 특수 고속 스위치망을 별도로 완전히 구축한 "초고속 스토리지 전용 지하 고속도로 망" 모델이다.

가치: 대중적인 NAS가 편리한 '파일'을 던져줄 때 발생하는 심각한 포장지 오버헤드 랙(TCP/IP 프로토콜 병목)을 전면 삭제하고, 오직 CPU가 "1번 디스크 0섹터에 0과 1 데이터 내놔!" 하는 원초적인 SCSI 블록 명령만 고속으로 꽂아버려 사실상 내 배 속의 로컬 C 드라이브를 쓰는 것과 100% 동일한 무결점 다이렉트 속도 지연(Zero-latency) 파워를 이끌어낸다.

한계: 엄청나게 비싸고 독자적인 규격의 HBA(Host Bus Adapter) 카드, 광 스위치, FC 케이블 등 광 인프라 공사를 따로 처발라야 하는 끔찍한 CAPEX(도입 예산 규모)가 발생하지만, 대규모 결제 RDBMS(Oracle) 등 수백만 건의 깡 스루풋 트랜잭션을 찰나에 쳐내야 하는 1티어 엔터프라이즈 센터에서는 결코 포기할 수 없는 스토리지 절대 권력의 축이다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념: SAN은 이름 그대로 "Storage(저장소)를 위해 Area(우리들만의 구역)로 Network(망)를 파버림" 이다. 컴퓨터 본체를 열어보면 메인보드와 하드디스크가 'SATA' 케이블 끈으로 직접 연결되어 있다. SAN은 그 본체 안의 짧은 끈의 길이를 수천 미터짜리 빛의 속도 광케이블(FC, Fibre Channel)로 쭈우욱 늘려서 건물 밖 거대한 데이터 창고 박스에 다이렉트로 길게 꽂아버린 확장 형태다. 놀랍게도 윈도우/리눅스 OS 입장에서는 이게 저 멀리 있는 창고장비인지, 자기 배 속에 꽂혀있는 로컬 하드인지 전혀 구분조차 하지 못하고 완벽하게 다이렉트로 로컬 블록(Block Device /dev/sdb)으로 인식하게 된다.
필요성: 직원들이 느긋하게 보는 엑셀 파일 공유는 NAS(파일 단위 접속)로 충분하지만, 초당 10만 건 이상의 입출력을 처리하며 주식 거래를 체결하는 거대 데이터베이스 서버(DB)에게 있어 NAS가 발생시키는 TCP/IP 네트워크 딜레이(오버헤드 랙)은 암 선고와 같다. DB 입장에서는 "야, 파일명이나 폴더 그딴 구조를 왜 네가 알아서 짜 놔? 난 그딴 거 필요 없어. 그냥 백지장 같은 블록 깡통 바닥을 줘! 거기에 내가 내 자체 파일시스템(ASM 등)으로 직접 이진수를 밀어 넣고 빼고 제일 미친 속도로 다이렉트로 할 거야!" 라는 갈증이 있었기 때문에 이 극강의 무대포 속도 전용 통로인 블록 채널 어프로치(FC SAN) 인프라가 필수적으로 탄생했다.
💡 비유: NAS가 복잡다단한 시내버스를 타고 정류장(라우터)을 거쳐서 "도서관 파일 찾으러 가는 길(IP망)" 이라면, SAN은 아예 우리 집 안방 문을 열었더니 창고 도서관 앞마당까지 뻥 뚫려있는 나만을 위한 '지하 직통 KTX 고속터널(Fibre Channel)'을 수백만 원 들여 뚫어놓은 것입니다! 다른 사람 간섭도 없고, 신호등(TCP/IP 락)도 없어서 그냥 눈 감고 돌진하면 바로 내 서랍(블록 스토리지)에 닿을 수 있는 압도적 다이렉트 깡스피드 특권이죠.
SAN 의 논리적 블록 통신 스택 메커니즘 (NAS 와의 극단적 대조): OS가 데이터를 호출할 때 스택이 얼마나 가볍고 초고속으로 떨어지는지 차이를 ASCII 다이어그램으로 시각화하면 다음과 같다.

  ┌────────────────────────────────────────────────────────────────────────────────────┐
  │                 SAN (Storage Area Network) 블록 다이렉트 통신 계층도               │
  ├────────────────────────────────────────────────────────────────────────────────────┤
  │                                                                                    │
  │   [ 앱 서버 (Windows / Linux) 클라이언트 ]                                         │
  │      ┌───────────────────────────┐                                                 │
  │      │ DB 어플리케이션 구동 중 쿼리 폭주│                                          │
  │      ├───────────────────────────┤                                                 │
  │      │ 로컬 OS 파일시스템 (NTFS, XFS)│ ◀──(OS는 자기가 파일관리자라고 착각함)      │
  │      ├───────────────────────────┤              (Fibre Channel 광망)               │
  │      │ HBA (Host Bus Adapter 광카드) │ ──(SCSI 블록명령)──▶ ▣ 광 스위치            │
  │      └───────────────────────────┘                      │                          │
  │                                                         │                          │
  │   [ 거대 SAN 스토리지 어레이 어플라이언스 ]                       ▼                │
  │      ┌───────────────────────────────────────────────────────┐                     │
  │      │ 1️⃣ 광 포트 수신 (이더넷 TCP 헤더 같은 쓰레기 껍데기 없음. 걍 직통명령)│    │
  │      │ 2️⃣ SAN 스토리지 컨트롤러 (캐시 매니저만 치고 블록 덩어리째 냅다 패스!) │   │
  │      │    [경고] NAS처럼 저 안의 파일이 뭔지 해석 신경 끄기. 걍 빈 상자임! │       │
  │      │ 3️⃣ 수백 개의 물리 디스크 군락 (LUN 배정 번호에 맞춰서 우당탕 쓰기작렬)│    │
  │      └───────────────────────────────────────────────────────┘                     │
  │                                                                                    │
  │  * 결과: NAS에서는 4단계를 포장 뜯느라 허덕이던 과정을 모두 생략하고,              │
  │         디스크 암(Arm)을 긁는 행위 그 자체(SCSI명령)만을 스위치로 날려버림!        │
  └────────────────────────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 앞 단원 NAS와 이 SAN을 완벽하게 가르는 단 하나의 키워드는 "누가 파일(File/Folder) 개념을 이해/관리하는가?" 이다. 그림에서 보듯 거대한 수천만 원짜리 스토리지 본체 깡통은 자기 뱃속에 들어온 데이터 조각이 엑셀 파일인지 윈도우 OS 시스템 파일인지 알 길이 전혀 없다 (해석 안 함). 해석은 오직 선 끝에 달린 접속 호스트(앱 서버)의 OS 파일시스템 패널에서만 관리하고, 스토리지 본체는 그저 "몇 번 섹터 블록에 이거 박아, 지워" 하는 무식하고 솔직한 입출력 블록(Block) I/O 임무만을 대리할 뿐이다. 머리(연산)를 비우고 육체(디스크 컨트롤)만 작동하니까 TCP IP 프로토콜 지연 그딴 늪 없이 미친 듯한 극한의 0 지연 무결점 직통 I/O 스피드가 창출 파산된다.

📢 섹션 요약 비유: NAS가 식당 주문 앱(TCP/IP)을 켜서 주방장이 다 만들어둔 "김치찌개(파일)" 완제품을 배달받는 긴 과정이라면, SAN 은 내 식탁(서버) 바로 구멍 밑이 거대한 도축장 고기창고(LUN 블록 스토리지)와 전용 리프트(가스관, 광케이블)로 직결되어 있어서 고기 덩어리(블록)만 깡으로 팍팍 올려받은 뒤 요리와 양념 조리(파일시스템 조립 해석) 는 전부 내 식탁 위(Host OS)에서 맹속으로 내가 직접 해치우는 생 원자재 깡 스피드 다이렉트 방식입니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

1. Fibre Channel (FC) vs iSCSI (블록 전송을 지지하는 두 가지 길)

SAN 환경을 구축하려면 "이 블록을 어떻게 쏠 것인가" 매개체 규약을 정해야 하는데 예산 쩐의 전쟁을 가르는 두 가지 파이프라인 무기가 있다.

네트워크 전송 프로토콜 스펙	전용성 및 칩셋 매커니즘 (아키텍처 인프라)	평가 / 도입 타겟 대상
FC SAN (Fibre Channel)	순도 100% 광케이블 전용 도로망 별도 굴착. 서버 등 뒤에 랜카드 대신 엄청 비싼 FC HBA 칩 카드를 꽂고, 서버실 천장으로 주황색 광케이블 선을 수십 개 엮어 전용 광 스위치(Brocade 등)에 연결해 무지막지한 수백 기가 스피드를 전담.	CPU 오버헤드 0%. 지구상 가장 강력하고 무결점의 속도와 극저 지연 보장이지만 인프라 싹 다 전용 장비 비싼 장비 깔아야 해서 예산 출혈 극악(대기업 1티어 전유물)
IP-SAN (iSCSI)	"블록을 쏘고 싶은데 광케이블 공사비용이 없어 랜선으로 보낼게!" SCSI 하드디스크 블록 명령어 구조체를 구형 이더넷 TCP/IP 봉투(LAN선)에 억지로 우겨 넣고 IP 주소로 날려 스토리지 박스 입구에 꽂는 방식 타협안.	당연히 랜선 위를 달리니 충돌 랙(TCP 오버헤드)이 발생해 속도는 FC에 안됨. 하지만 기존 사무실/서버실 IP 이더넷 스위치 허브를 그대로 공짜 재활용 가능하므로 초가성비 폭발 (중소기업형 블록 매핑)

2. LUN (Logical Unit Number) 볼륨 할당과 MPIO 경합 다중화 다이렉트

SAN의 가장 핵심 단위는 LUN (디스크 논리 분할 포장) 이다. 스토리지 장비 깡통에 하드디스크 100개가 들어있어 총 1,000TB 라면, 이걸 관리자는 톱질하듯 잘라서 "1번 서버야 넌 이 LUN 0번 (10TB) 가져가서 써, 2번 서버야 넌 LUN 1번 가져가" 하고 떼어 배정해 준다.

차단 독립성의 원칙 (Masking/Zoning): NAS 폴더는 주소만 알면 여러 명이 동시다발적 같이 접속할 수 있지만, SAN의 블록 스토리지 LUN 1번은 지정받은 딱 1대의 1번 서버만이 독점해서 자기 로컬 드라이브 C: 처럼 장악 독식해야 한다. 다른 서버가 거기에 잘못 붙어서 블록을 덮어써 버리면 파일시스템 헤더 꼬임 인덱스가 파괴되어 10TB 데이터 전체가 영구 소거 포맷되는 대참사 비극 멸망이 일어난다! (이를 막는 것이 LUN Masking 기술이다)
MPIO (Multi-Path I/O): 블록 스토리지의 끈(Fibre 광 케이블)이 단 하나라면? 쥐가 갉아먹거나 관리자가 발이 걸려 선이 뽑히는 순간 고가용성 DB 서버가 통째로 프리즈 즉발 다운된다. 이를 방어 무결성 처리하기 위해 똑같은 LUN 으로 들어가는 광 길목 선을 무조건 두 개, 세 개 겹쳐 연결(이중화)해 놓고 한 통로 선이 터지면 즉각 0.1초 만에 다음 경로(우회 파이프)로 I/O 생존로 패킷을 타게 만드는 무중단 스루풋 연동 기술이다.
📢 섹션 요약 비유: 이 놀라운 배분 기술(LUN 지정)은 거대한 원룸 고시원(총 스토리지 볼륨)이 있으면, 복도에 CCTV(마스킹 제어 보안)를 달아서 딱 1번 방 열쇠(WWN 권한)를 가진 단 1명의 세입자(서버 머신)만이 그 원룸 공간 구조재산(블록 공간 자체)을 온전히 영구 전세 내 쓸 수 있게 절대 출입 독점 통제해버리는 프라이빗 장악 방식의 본질입니다.

Ⅲ. 실무 융합 적용 및 기술사적 진단 (아키텍처 전술과 착각)

도입의 대참사 - 스토리지 용도의 폭망적 착각 안티패턴

엔터프라이즈 서버 입찰 프로젝트를 하던 주니어 엔지니어가 "가장 비싸고 고사양이니까 당연히 SAN을 사면 무조건 좋겠지" 라며 파일 공유 서버(File Share)로 쓸 몫인데 NAS 가 아니라 FC SAN 스토리지 어플라이언스를 덜컥 구매 발주했다고 가정하자. 이건 IT 재앙의 서막이다.

치명적 한계의 도달 직면발생: 1억을 주고 산 그 거대 SAN 깡통에서 LUN 을 뽑아 디자인팀, 회계팀 서버PC 5군데에서 랜카드(iSCSI / FC)로 접속을 강제로 물렸다 (Shared 붙임).
증상: 디자인팀이 "테스트.docx" 파일을 저장 누른다. 블록 헤더에 "이거 썼음" 하고 비트가 박힌다. 근데 옆방 회계팀 OS 는 디자인 PC가 방금 그 블록에 자국을 냈는지 어쨌는지 알 권한이 전혀 없으므로(SAN 은 블록이지, 파일 잠금 폴더 권한 시스템 관리를 안 해주므로!) 자기도 똑같은 자리에 "결제수정.xlsx" 덮어쓰기 블록을 냅다 갈겨 부셔 버린다.
폭발: 양쪽 서버의 파일시스템 NTFS 헤더 인덱스가 산산조각 붕괴 꼬여서 전체 디스크가 '포맷되지 않은 볼륨 RAW 깨짐' 상태로 돌변 폴더 채로 통째 증발 증상 발생!

💡 해법의 이주 트리: SAN 은 기본 철학이 "나 혼자 쓰는 내 C드라이브 생짜 공간 떼오기"다. 이걸 다수의 PC가 하나의 풀로 같이 비비고 지지며 쓰려면, 위에 반드시 "NAS 게이트웨이 기기 머리(파일 잠금 조율사)"를 한 겹 덮어 씌우거나, VM웨어의 VMFS (클러스터 파일시스템) 같은 초고도 특수 코디네이팅 클러스터 공유 S/W를 덧칠로 결합해 주어야만 파괴를 면한다.

최적의 결합 황금 비율 시나리오

핵심 RDBMS (Oracle, MS-SQL 원본) 스토리지: 무조건 무식한 FC SAN 이다. 다른 잡동사니 스루풋 없이 오직 오라클 엔진이 블록 0, 블록 1 단위를 마이크로타임 초속으로 갈구며 I/O를 찢어발기는 데 있어서 전 세계 범접 대체 불능의 원 톱 스탠더드 교과서 전용 도로다.
가상화 스웜 인프라 풀 (VMware ESXi, Hyper-V Hypervisor): 가상머신 통째로 떨어지는 파일 파편 풀(.vmdk)을 보관하는 백엔드 공간으로 가장 무음 초고속 파워풀 안정성을 갖는다.
📢 섹션 요약 비유: 이 비싼 다이렉트 구조체계는 사실 회사 운동장에다가 여러 명이 같이 쓸 공용 수도꼭지(NAS)를 뚫어 놓은 게 아니라, 회장님실 전용 개인 변기(SAN LUN)에다가 정수 처리장 호스 파이프 전체를 혼자 직결시켜버린 초호화 사치 인프라 다이렉트 수압과 같습니다. 돈은 오지게 들지만 절대 수압 다운타임 쫄림이 없죠! 하지만 그 화장실에 직원 여러 명이 동시에 볼일 보러(동시 파일 폴더 접근 쉐어) 밀고 들어오면 구조적 통제 시스템이 없어서 화장실이 폭발하는 사태와 동치 됩니다!

Ⅳ. 기대효과 및 결론

아키텍처 SLA 및 통합 지표 체계

시스템 운영 아키텍처 레이어	NAS 기반 트랜잭션 RDB 구축시 한계	SAN 백플레인 무결점 융합 시	도입 TCO 기대 파장
정량 (Random Write 지연시간 ms)	TCP/IP 패킷 생성 소모, 이더넷 버퍼 병목, 파일 잠금 오버헤드 늪에 빠져 10ms 이상 수시 타임아웃 튀김 지연	패킷 껍데기 0, SCSI 변환 0, 광속 스루풋 직결. 거의 0.1ms 언더컷 로컬 플래시 스피드 다발 I/O 흡수	어플리케이션 DB 초당 TPS 스루풋 극단 한계 폭발 돌파 우위
정량 (네트워크 상호 간섭 충돌)	파일 백업 시 사무실 PC 트래픽 대역폭이랑 섞여서 다운로드 병목 나고 난리 스위치 랙 체증 브로드캐스트 작렬	사내 랜선과 완전히 분리 격리된 뒷단 지하실 '자기들만의 보라색 광케이블 리그 도로' 구축	서버 트래픽 혼잡도 0% 완벽한 인프라 독립 결함 격리 달성
정성 (자본 집약 투자 TCO 확정)	이더넷 포트 랜선만 꼽음 땡, 100만 원.	HBA 카드장당수백 FC 스토리지장비 수억 광스위치장비 수천만... 억대 지출 각오해야 함	초호화 비용 출혈, 돈을 발라 가장 안전한 생존 타협선 획득 구축

미래 전망 진화 계통

FC SAN은 그 무식한 속도로 기업의 심장을 지켜왔으나, 클라우드 (Cloud Native)와 100기가짜리 저렴한 이더넷(Ethernet) 랜선 장비 시장 인프라의 폭발적인 대역폭 상승으로 인해 비싼 전용선(FC) 유지 명분이 점점 궁지에 몰려 줄어드는 추세다.
최근 모든 데이터센터의 절대반지 1군단 지휘는 NVMe-oF (NVMe over Fabrics) 라는 돌연변이 규격이 집어삼키고 있다. 굳이 광케이블 공사를 안 해도, 로컬 서버 PCI 슬롯 통로에 꽂히던 초고속 NVMe 플래시 명령어 스택 자체를 그대로 그냥 이더넷 인터넷망(RoCE 통신/TCP망 등) 위에 태워서 전 세계 광 대역폭으로 날려버리는(이론상 SAN이던 NAS던 경계를 무너뜨리는 통합 통신 블록 파밍) 궁극의 종착 체계로 거대하게 기술 체인지 마이그레이션을 이루고 있다.

결론적으로 SAN은 TCP/IP라는 느려 빠진 뚱보 범용망 포장 굴레를 억지로 벗어 던지고, 본체 컴퓨터 메인보드 혈관 자체를 전산실 물리 케이블 망 밖으로 뽑아내 다이렉트로 직결 이은 "블록 스토리지 전용 다이렉트 입출력의 극한 완성체 뼈대" 다. 아무 곳에나 마우스로 달기는 끔찍하게 불친절하고 비싸지만, 절대적으로 무너지면 안 되는 메인 백본 결제 원장 시스템 속도를 사수하기 위한 20년간의 엔터프라이즈 하드웨어 장인들의 방패 요새였다.

📢 섹션 요약 비유: 요약하자면, NAS 가 아무 차나 섞여 달리는 막히는 시내 아스팔트 국도(TCP/IP LAN)를 탄다면, 비싸게 지은 SAN 은 철저하게 KTX 전용 기차 레일 선로(FC 광망)를 다시 땅에 깐 격입니다! 역도 필요 없고 신호등도 없고, 오직 기차와 화물(내 서버와 내 폴더 블록)만 목적지까지 미친 속도로 직진 쏘는 데 최적화된 돈 잔치 스위치 프리패스의 끝판왕 도로 결합체입니다.

📌 관련 개념 맵 (Knowledge Graph)

전조 기술 융합 컴포넌트	관계 통찰 설명 (진단 시너지)
LUN (Logical Unit Number) 볼륨 마스킹	SAN 장비가 만들어낸 1차 논리 파괴 쪼개기 단위 블록 박스. 이 번호의 쇠사슬 열쇠에 타겟 서버를 1:1로 꽉 독점 체결해주지 않으면 옆 서버가 들어와 덮어씌워 버리는 붕괴 박스 단일 공간 단위
iSCSI (Internet Small Computer System Interface)	"SAN 블록 스토리지 속도는 갖고 싶은데 망할 광케이블 공사 살 돈은 없어." 하고 타협해 만들어낸 가성비 서민형 꼼수 프로토콜. 랜선 위에 강제로 블록 명령을 씌워 오버헤드를 안고 랜선을 타고 날아 블록 매핑.
NAS (Network Attached Storage)	SAN 과 늘 붙어 다니며 비교되는 친절한 파일 폴더 접근 기반 대중 시스템 매커니즘. 공유 협업용. TCP 패킷 처리와 파일 락 제어 때문에 RDB 환경에선 병목으로 두드려 맞는 비교 약점 체계.
NVMe-oF (Network 블록 차세대 통합 망)	FC SAN 의 초고속 비전과 IP 랜선의 범용성을 합쳐버린 현대 클라우드의 최강 하드 역작! 구시대 스카시(SCSI) 명령어 버스 병목을 아예 병렬 초고속 PCIe 채널망으로 IP망까지 이산시켜버린 미친 진화 무중단 스루풋 패킷 망

👶 어린이를 위한 3줄 비유 설명

거실에 둔 만능 책장(NAS)은 다 같이 폴더를 보기 편하지만, 여러 명이 몰려들면 책 꺼내는 데 줄 서야 하고 택배 포장(TCP 통신망 포장지)을 뜯느라 되게 굼뜨고 느려져요.
하지만 아빠가 회사에서 엄청나게 중요한 비밀 계산 일기(대형 폭파 스피드 DB 데이터)를 1초에 만 번씩 읽고 써야 한다면? 아예 벽을 부수고 전용 파이프 배관 통로(광케이블 전용 SAN 망)를 아빠 책상부터 창고 끝까지 지하로 다이렉트 뚫고 만들었어요!
택배 포장지 뜯을 필요도 없고 줄 서서 신호등 건널 필요도 없이 쏘는 즉시 창고 빈칸 블록에 도장 쾅쾅 무적의 직결 다이렉트 타격을 꽂아버리는 아주 비싸지만 엄청 빠른 귀족 전용 철도망 창고 구조랍니다!