기업 스토리지, 무조건 SAN을 선택하지 않아도 되는 이유

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

파일 서버 용량이 부족해지면 가장 먼저 “SAN을 도입해야 하나?”라는 질문이 나옵니다. 하지만 저장할 데이터의 성격과 장애 허용 범위를 확인하지 않은 채 고가 장비부터 선택하면, 성능은 남고 운영비만 늘어나는 스토리지가 될 수 있습니다.

기업 스토리지는 단순히 디스크를 많이 꽂는 장비가 아닙니다. 사용자가 공유 문서를 여는 방식, 가상서버가 데이터를 읽는 패턴, 백업 보존 기간, 담당자의 운영 역량까지 함께 설계해야 합니다. 서버의 기본 개념은 서버 용어 설명에서도 확인할 수 있지만, 실제 구축에서는 서버와 저장장치 사이의 연결 구조가 서비스 품질을 크게 좌우합니다.

스토리지 종류보다 먼저 업무 데이터를 구분해야 합니다

같은 10TB라도 필요한 장비는 달라집니다

설계의 출발점은 전체 용량이 아니라 데이터가 생성되고 사용되는 방식입니다. 디자인 원본 10TB를 여러 직원이 공유하는 환경과 데이터베이스 10TB에서 초당 수천 건의 거래가 발생하는 환경은 숫자만 같을 뿐 요구 조건이 전혀 다릅니다. 전자는 파일 공유와 권한 관리가 중요하고, 후자는 지연시간과 다중 경로, 쓰기 안정성이 우선입니다.

먼저 데이터를 업무 문서, 가상머신, 데이터베이스, 백업, 영상·로그처럼 나눠 보십시오. 사용자가 직접 파일을 열어야 하는지, 애플리케이션이 블록 단위로 접근하는지, 장기 보존이 목적인지에 따라 NAS·SAN·오브젝트 스토리지·HCI 가운데 적합한 선택지가 자연스럽게 좁혀집니다.

• 공유 문서와 설계 파일: 폴더 권한, 파일 잠금, SMB·NFS 호환성을 우선합니다.
• 가상화와 데이터베이스: 낮은 지연시간, IOPS, 이중 경로와 스냅샷 성능을 확인합니다.
• 백업과 아카이브: 원본 복구 속도, 보존 정책, 변경 불가능 저장 기능을 살펴봅니다.
• 영상과 대규모 로그: 수평 확장성과 메타데이터 처리 방식, API 연동성을 비교합니다.

실무 팁: “현재 몇 TB인가”보다 “3년 뒤 유효 용량이 얼마이며, 업무 시간에 어느 정도의 읽기·쓰기가 몰리는가”를 먼저 적으면 과잉 투자를 줄일 수 있습니다.

NAS·SAN·오브젝트·HCI는 무엇이 다른가요?

네 가지 방식의 핵심 차이

NAS는 네트워크를 통해 파일 단위로 저장 공간을 공유하므로 사내 파일 서버를 교체하거나 부서별 폴더를 통합하기 좋습니다. SAN은 서버에 블록 스토리지를 제공해 데이터베이스와 고성능 가상화 환경에 유리하지만, 전용 스위치와 다중 경로 등 설계 요소가 많습니다.

오브젝트 스토리지는 데이터를 객체와 메타데이터로 관리해 대규모 비정형 데이터와 장기 보관에 강합니다. HCI는 서버의 컴퓨팅과 로컬 디스크를 소프트웨어로 묶는 방식이어서 가상화 인프라를 노드 단위로 확장할 때 효율적입니다. 다만 저장 용량만 필요해도 컴퓨팅 자원을 함께 증설해야 할 수 있습니다.

• 직원 중심의 공유 폴더가 핵심이면 NAS가 현실적인 출발점입니다.
• 트랜잭션 지연이 매출이나 생산에 직접 영향을 주면 SAN을 우선 검토합니다.
• 수백만 개의 영상·로그를 장기간 축적한다면 오브젝트 방식이 유리합니다.
• 가상화 호스트와 스토리지를 동시에 교체한다면 HCI의 통합 효과가 커집니다.

구매 가격만 비교하면 실제 비용을 놓칩니다

3년 운영비를 만드는 여섯 가지 항목

스토리지 견적에서 장비 가격만 보면 NAS가 가장 저렴하고 SAN이 가장 비싸 보입니다. 그러나 실제 판단에는 디스크의 원시 용량이 아니라 RAID, 복제, 스냅샷, 여유 공간을 제외한 유효 용량당 비용을 사용해야 합니다. 중복 제거와 압축률도 데이터 종류에 따라 크게 달라지므로 제안서의 최대 절감률을 그대로 적용해서는 안 됩니다.

유지보수 갱신비, 네트워크 스위치, 광 모듈, 랙 공간, 전력, 백업 소프트웨어와 관리자 교육비도 포함해야 합니다. SAN은 높은 성능과 이중화가 필요한 조직에서는 비용을 정당화할 수 있지만, 30명이 문서를 공유하는 사무실에서는 10GbE 기반 NAS 두 대가 더 단순하고 합리적일 수 있습니다. 반대로 핵심 ERP를 저가 NAS 한 대에 올리면 장애 손실이 장비 절감액을 단번에 넘어설 수 있습니다.

1. 유효 용량: 장애 보호와 스냅샷을 적용한 뒤 실제 사용할 수 있는 공간을 계산합니다.
2. 연결 비용: 스위치, NIC·HBA, 케이블과 포트를 포함합니다.
3. 지원 비용: 3년 또는 5년의 기술지원과 부품 교체 조건을 확인합니다.
4. 소프트웨어 비용: 복제, 백업, 암호화, 모니터링 라이선스를 따로 표시합니다.
5. 운영 인력: 장애 분석과 증설에 필요한 담당자의 시간을 비용으로 봅니다.
6. 중단 손실: 한 시간의 서비스 중단이 만드는 매출·생산성 손실을 추산합니다.

예산을 비교할 때는 “장비 한 대의 가격”이 아니라 보호된 데이터 1TB를 3년간 운영하는 비용으로 환산하는 것이 좋습니다. 공급사마다 포함 범위가 달라지는 설치·마이그레이션 비용도 동일한 조건으로 맞춰야 합니다.

업무 상황별로 선택하면 답이 선명해집니다

규모가 아니라 병목과 복구 목표를 보십시오

직원 수가 많다고 반드시 SAN이 필요한 것은 아닙니다. 300명이 주로 오피스 문서를 읽고 쓰는 조직이라면 캐시와 네트워크가 충분한 이중화 NAS가 적합할 수 있습니다. 반면 직원이 20명이어도 생산 설비의 데이터베이스가 밀리초 단위 응답을 요구한다면 올플래시 SAN이나 검증된 고성능 HCI가 더 안전합니다.

선택 전에 RPO와 RTO를 정해야 합니다. RPO는 장애 발생 시 어느 시점까지 데이터를 되돌릴 수 있어야 하는지, RTO는 몇 시간 안에 업무를 재개해야 하는지를 뜻합니다. 이 기준이 없으면 스냅샷이 있으니 안전하다는 말과 즉시 복구할 수 있다는 말이 뒤섞입니다. 기업 IT 서비스는 저장장치만으로 완성되지 않으며, IT 서비스 시스템의 구성 관점처럼 운영 절차와 연계 체계까지 함께 봐야 합니다.

• 중소 사무실: 이중 컨트롤러 또는 두 대 복제형 NAS와 별도 백업을 추천합니다.
• ERP·DB 중심 기업: 성능 검증을 거친 SAN과 다중 경로, 별도 복구 저장소가 적합합니다.
• 가상화 통합 프로젝트: 컴퓨팅과 저장 용량 증가율이 비슷하면 HCI를 추천합니다.
• 영상·로그 보관 조직: 오브젝트 스토리지와 수명주기 정책을 조합하는 편이 효율적입니다.
• 지점이 많은 기업: 지점 HCI 또는 소형 NAS와 중앙 백업을 결합해 관리 지점을 줄입니다.

혼합 구성이 더 나은 경우

한 종류로 모든 데이터를 처리하려 하지 않아도 됩니다. 운영 DB는 SAN, 협업 파일은 NAS, 장기 백업은 오브젝트 스토리지에 배치하는 계층형 구성이 오히려 비용과 복구성을 함께 개선합니다. 중요한 것은 장비 수를 늘리는 일이 아니라 데이터의 중요도에 맞춰 성능 계층과 보호 계층을 분리하는 것입니다.

제품 사양표에서는 보이지 않는 운영 차이를 확인합니다

데모보다 장애 시나리오가 더 중요합니다

제품 비교표에 표시된 최대 처리량은 특정 블록 크기, 캐시 적중률, 압축 가능한 데이터 등 유리한 조건에서 측정되는 경우가 많습니다. 실제 업무에서는 작은 파일이 무수히 생성되거나 백업과 사용자 접속이 같은 시간대에 겹칩니다. 따라서 평균 IOPS만 보지 말고 95·99백분위 지연시간, 캐시가 소진된 뒤의 쓰기 성능, 컨트롤러 하나가 멈췄을 때의 성능을 확인해야 합니다.

운영 화면의 편의성도 장기 비용을 바꿉니다. 장애 원인이 디스크인지 네트워크인지 한 화면에서 구분되는지, 펌웨어 업데이트 중 서비스를 유지할 수 있는지, 용량 예측 알림이 제공되는지 살펴보십시오. 서버와 스토리지의 관계를 이해할 때는 서버 관련 참고 설명을 바탕으로 실제 애플리케이션 연결 구조까지 도식화하면 누락을 줄일 수 있습니다.

1. 운영 데이터와 비슷한 파일 크기·읽기/쓰기 비율로 성능을 시험합니다.
2. 컨트롤러, 경로, 디스크를 하나씩 차단해 서비스 영향과 알림 시간을 기록합니다.
3. 스냅샷에서 파일 한 개와 가상머신 전체를 각각 복구해 봅니다.
4. 랜섬웨어 상황을 가정해 관리 계정 분리와 변경 불가 스냅샷을 검증합니다.
5. 용량을 70~80%까지 채운 상태에서 성능과 재구축 시간을 다시 측정합니다.
6. 지원 요청 접수 방식, 현장 출동 조건, 부품 도착 목표 시간을 계약서에서 확인합니다.

백업과 스냅샷을 혼동하지 않습니다

스냅샷은 빠른 되돌리기에 유용하지만 같은 장비 안에만 존재하면 장비 전체 장애나 관리자 계정 탈취에 함께 노출될 수 있습니다. 운영 스토리지와 물리적·논리적으로 분리된 백업, 다른 자격 증명, 복구 테스트를 마련해야 합니다. 복제본이 있다는 사실보다 그 복제본으로 업무를 다시 열어 본 기록이 더 강한 안전 근거입니다.

• 스냅샷 보존 기간과 잠금 기능을 확인합니다.
• 백업 관리 계정을 일반 인프라 계정과 분리합니다.
• 월별 표본 복구와 분기별 서비스 복구 훈련을 일정에 넣습니다.

설계회사 60명의 스토리지 교체 과정을 따라가 봅니다

비싼 SAN 대신 역할을 나눠 해결한 사례

가상의 A설계회사는 직원 60명이 18TB의 CAD 도면과 렌더링 결과물을 공유하고 있었습니다. 기존 단일 파일 서버는 월요일 오전마다 느려졌고, 디스크 한 개에 경고가 발생하자 경영진은 SAN 도입 견적을 요청했습니다. 조사 결과 병목은 디스크 용량 자체보다 1GbE 네트워크, 오래된 HDD의 임의 읽기, 백업 작업과 업무 시간의 중첩에 있었습니다.

운영팀은 일주일 동안 접속량을 측정해 활성 프로젝트 6TB와 완료 프로젝트 12TB를 분리했습니다. 활성 데이터는 10GbE 연결과 SSD 캐시를 갖춘 이중화 NAS에 배치하고, 완료 프로젝트는 용량 중심의 보조 NAS로 이동했습니다. 보조 장비의 데이터는 야간에 별도 오브젝트 저장소로 복제했으며, 사용자에게는 기존 드라이브 문자와 폴더 구조를 유지해 업무 변화도 줄였습니다.

1. 1주 차: 파일 수, 시간대별 처리량, 사용자별 동시 접속, 백업 소요 시간을 수집했습니다.
2. 2주 차: 활성·완료·백업 데이터를 나누고 각 계층의 RPO와 RTO를 합의했습니다.
3. 3주 차: 실제 도면 복사와 렌더링 작업으로 NAS 두 후보를 시험했습니다.
4. 4주 차: 변경분 동기화 후 부서별로 전환하고 구형 서버는 즉시 폐기하지 않고 읽기 전용으로 유지했습니다.
5. 전환 후: 대용량 파일 열기 시간, 네트워크 사용률, 스냅샷 성공 여부와 복구 시간을 매주 점검했습니다.

이 회사는 SAN이 나쁜 제품이라서 제외한 것이 아닙니다. 파일 공유가 중심인 업무에 블록 스토리지와 전용 패브릭을 추가해도 체감 효과가 제한적이라는 시험 결과를 근거로 선택했습니다. 대신 네트워크를 개선하고 저장 계층과 백업 계층을 분리해 단일 장애 지점을 줄였습니다.

석 달 뒤 활성 프로젝트가 예상보다 빠르게 늘자 운영팀은 전체 장비를 교체하지 않고 고성능 NAS의 디스크 풀만 확장했습니다. 이후 데이터베이스 기반 프로젝트 관리 시스템을 도입할 때는 해당 워크로드만 별도의 고성능 블록 스토리지 후보로 검토했습니다. 업무별로 NAS와 SAN의 역할을 나눈 결정 덕분에 처음부터 모든 데이터를 가장 비싼 계층에 넣지 않고도 성능, 복구 시간, 향후 확장성을 함께 확보할 수 있었습니다.

• 전환 기준은 제품 이름이 아니라 측정된 병목이었습니다.
• 사용자 경로를 유지해 마이그레이션에 따른 혼란을 줄였습니다.
• 구형 서버의 읽기 전용 유지 기간을 두어 누락 파일을 확인했습니다.
• 복구 시험 결과를 다음 증설과 IT 시스템 구축의 기준 자료로 남겼습니다.