6. 도입 검토 — 요구사항 분석과 벤더 선정
스토리지 도입 시 워크로드 프로파일링 실패 사례, RAW vs 실효 용량과 리덕션 비율의 함정, 벤더 벤치마크 5가지 함정, PoC 진행법, TCO 숨은 비용, 벤더별 약점, CAPEX vs OPEX 비교, 유지보수 계약과 TPM 장단점까지. 장비를 사기 전에 알아야 할 모든 것.
글꼴
"스토리지 새로 사야 하는데, 뭘로 하면 좋을까요?"
이 질문을 경영진에게서 받으면, 엔지니어는 두 가지를 동시에 생각해야 한다. 하나는 기술적으로 뭐가 맞는가. 다른 하나는 예산 안에서 뭘 살 수 있는가. 벤더 영업이 가져오는 슬라이드는 다 좋은 말뿐이다. "업계 최고 성능", "5
데이터 리덕션", "99.9999% 가용성". 이 숫자들의 실체를 꿰뚫어 보는 게 도입 검토의 핵심이다.도입 검토의 전체 흐름을 먼저 보자.
스토리지 도입 검토 전체 흐름:
① 워크로드 프로파일링
"뭐가 돌아갈 건가?"
IOPS / Throughput / Latency / 읽기쓰기 비율 분석
│
▼
② 용량 산정
"얼마나 필요한가?"
RAW → 실효 용량 계산, 3~5년 성장률 반영
│
▼
③ 벤더 RFP / PoC
"어떤 제품이 맞는가?"
벤치마크 함정 읽기, PoC로 실제 워크로드 검증
│
▼
④ 벤더 선정 + 제품 결정
"Dell? NetApp? Pure? HPE?"
제품 라인업, 가격 구조, 로드맵 확인
│
▼
⑤ 라이선스/구매 모델 결정
"사는가? 빌리는가?"
CAPEX(구매) vs OPEX(구독/aaS) 비교
│
▼
⑥ 유지보수 계약 협상
"장애 나면 몇 시간 안에 오는가?"
SLA, 부품 배치, 비용 인상률 협상
│
▼
→ 다음 단계: 설계 (7편)워크로드 프로파일링 — 뭘 사려면 먼저 뭘 하는지 알아야 한다
스토리지를 고르기 전에 "이 스토리지 위에서 뭐가 돌아갈 건지"를 정확히 파악해야 한다. 워크로드 특성에 따라 중요한 지표가 다르다.
┌───────────────────────────────────────────────────────┐
│ 워크로드별 핵심 성능 지표 │
├──────────────────┬────────────┬───────────┬───────────┤
│ 워크로드 │ 핵심 지표 │ IO 패턴 │ 블록 크기 │
├──────────────────┼────────────┼───────────┼───────────┤
│ OLTP DB │ IOPS │ 랜덤 R/W │ 4~16KB │
│ (Oracle, MySQL) │ + Latency │ 읽기 70% │ │
├──────────────────┼────────────┼───────────┼───────────┤
│ OLAP/DW │ Throughput │ 순차 읽기 │ 64KB~1MB │
│ (분석, 리포트) │ │ │ │
├──────────────────┼────────────┼───────────┼───────────┤
│ VDI (가상 데스크톱)│ IOPS │ 랜덤 읽기 │ 4~8KB │
│ │ (Boot Storm)│ (아침 9시)│ │
├──────────────────┼────────────┼───────────┼───────────┤
│ 파일 서버 │ Throughput │ 순차 혼합 │ 가변 │
│ │ + 용량 │ │ │
├──────────────────┼────────────┼───────────┼───────────┤
│ 백업 타겟 │ Throughput │ 순차 쓰기 │ 256KB~1MB│
│ │ + 용량 │ │ │
├──────────────────┼────────────┼───────────┼───────────┤
│ AI/ML 학습 │ Throughput │ 순차 읽기 │ 가변(큰 │
│ │ + 동시접근 │ (다수 GPU) │ 파일 위주)│
└──────────────────┴────────────┴───────────┴───────────┘
IOPS가 중요한 워크로드 → 올플래시 SAN
Throughput + 용량이 중요한 워크로드 → NAS 또는 하이브리드
동시접근 + 처리량 → 병렬 파일 시스템 (3편 참고)기존 환경이 있다면 성능 데이터를 수집하는 게 가장 확실하다. 감이 아니라 숫자로 얘기해야 벤더와 대등한 대화가 된다.
리눅스 호스트에서 수집:
$ iostat -xmt 5 # 5초 간격 디스크 IO 통계
$ sar -d 5 60 # 5초 간격 60회 (5분간)
$ pidstat -d 1 # 프로세스별 IO
봐야 할 것:
┌──────────────────────────────────────────────┐
│ 지표 │ 의미 │ 주의 기준 │
├──────────────┼───────────────┼────────────────┤
│ r/s, w/s │ 초당 읽기/쓰기│ 합산이 IOPS │
│ rkB/s, wkB/s │ 초당 처리량 │ MB/s로 환산 │
│ await │ IO 대기 시간 │ >10ms면 주의 │
│ %util │ 디스크 사용률 │ >70%면 병목 │
│ avgqu-sz │ 평균 큐 길이 │ >4면 포화 가능 │
└──────────────┴───────────────┴────────────────┘
기존 스토리지에서 수집:
- 벤더 모니터링 도구 (Active IQ, Pure1, CloudIQ)
- SNMP 기반 히스토리 데이터
- 최소 1주일, 가능하면 1개월 데이터
- 피크 시간대(월요일 오전, 월말 마감)를 반드시 포함워크로드 프로파일링을 대충 하면 뭐가 벌어지는가.
프로파일링 실패 사례:
┌──────────────────────────────────────────────────────┐
│ 사례 1: "평균 IOPS"만 보고 장비를 샀다 │
│ │
│ 평균 IOPS: 10,000 → "이 정도면 미드레인지로 충분" │
│ 피크 IOPS: 80,000 → 월말 마감 때 8배 폭증 │
│ 결과: 월말마다 DB가 느려져서 야근 │
│ │
│ 교훈: 평균이 아니라 피크 기준으로 사이징해야 한다. │
│ 또는 피크를 버릴 수 있는 QoS/캐시 전략이 필요. │
├──────────────────────────────────────────────────────┤
│ 사례 2: IOPS만 보고 Throughput을 안 봤다 │
│ │
│ DB 워크로드는 IOPS 위주 → 올플래시 SAN 도입 │
│ 그런데 같은 스토리지에 백업도 받기로 함 │
│ 백업은 Throughput 위주 → 대역폭을 다 먹어서 │
│ DB IO까지 느려짐 │
│ │
│ 교훈: 워크로드를 섞을 때는 성능 특성이 다른 │
│ 워크로드가 서로 영향을 주지 않는지 확인해야 한다. │
├──────────────────────────────────────────────────────┤
│ 사례 3: 신규 시스템이라 데이터가 없다 │
│ │
│ 기존 환경이 없으면 수집할 데이터가 없다. │
│ 이때는 유사 시스템의 벤치마크 자료를 참고하거나, │
│ 애플리케이션 벤더의 사이징 가이드를 활용한다. │
│ Oracle이면 AWR 리포트 기반 예측, │
│ VMware면 VM당 평균 IOPS × VM 수로 추정. │
│ 어림짐작이라도 "근거 없는 숫자"보다는 낫다. │
└──────────────────────────────────────────────────────┘용량 산정 — RAW와 실효는 다르다
벤더가 "100TB 스토리지입니다"라고 하면, 그게 실제로 쓸 수 있는 100TB라는 뜻이 아니다.
RAW 용량에서 실효 용량까지:
RAW 용량 100 TB
─ RAID 오버헤드 -17 TB (RAID 6 기준, 약 17%)
─ 스페어 디스크 -5 TB (Hot Spare)
─ 시스템 영역 -5 TB (메타데이터, OS, 캐시)
─ 스냅샷 예약 -10 TB (스냅샷 공간 확보)
────────────────────────
실효 용량 63 TB (RAW의 63%)
+ 데이터 리덕션(중복제거+압축) 적용 시:
리덕션 비율 2:1 가정 → 논리 용량 126 TB
리덕션 비율 3:1 가정 → 논리 용량 189 TB데이터 리덕션 비율은 워크로드에 따라 천차만별이다. 벤더가 "5
보장합니다"라고 하면 반드시 물어야 할 것들이 있다. 데이터 리덕션 비율의 현실:
┌──────────────────────────────────────────────────────┐
│ 워크로드 │ 현실적 리덕션 비율 │
├───────────────────────┼────────────────────────────┤
│ VDI (가상 데스크톱) │ 3:1 ~ 5:1 (높음) │
│ → 동일 OS 이미지가 │ 중복제거 효과 큼 │
│ 수백 개 복제 │ │
├───────────────────────┼────────────────────────────┤
│ 일반 파일서버 │ 1.5:1 ~ 2:1 │
│ │ 파일 종류에 따라 편차 큼 │
├───────────────────────┼────────────────────────────┤
│ DB (Oracle, MySQL) │ 1.5:1 ~ 2.5:1 │
│ │ 인덱스가 많으면 높아짐 │
├───────────────────────┼────────────────────────────┤
│ 이미 압축된 데이터 │ 1:1 ~ 1.2:1 │
│ (영상, 이미지, 암호화) │ → 거의 효과 없음! │
│ │ 벤더가 이 사실을 안 말할 수 │
│ │ 있다. 반드시 확인. │
├───────────────────────┼────────────────────────────┤
│ 백업 데이터 │ 2:1 ~ 4:1 │
│ (전체 백업 반복) │ 반복 데이터 많아 효과 큼 │
└───────────────────────┴────────────────────────────┘
리덕션 비율 검증 방법:
┌──────────────────────────────────────────────────────┐
│ 1. 벤더에 "우리 워크로드로 PoC 해달라" 요청 │
│ → 실제 데이터로 측정한 비율이 가장 정확 │
│ │
│ 2. 벤더의 기존 고객 사례 중 유사 워크로드 참고 │
│ │
│ 3. 리덕션 "보장" 계약이 있는지 확인 │
│ Pure Storage는 리덕션 비율 보장 프로그램이 있음. │
│ 보장 미달 시 디스크 무상 추가. │
│ 다른 벤더는 "예상치"일 뿐 보장은 아닌 경우가 많다.│
│ │
│ 4. 용량 산정 시 보수적으로 접근 │
│ 벤더가 3:1이라 해도 2:1로 계산하라. │
│ 남으면 여유고, 부족하면 장애다. │
└──────────────────────────────────────────────────────┘용량 산정 시 3~5년 성장률도 반영해야 한다.
용량 성장 예측:
현재 사용량: 50TB
연간 증가율: 20%
1년 후: 60TB
2년 후: 72TB
3년 후: 87TB ← 도입 시 이 용량을 커버해야
5년 후: 124TB ← 증설 없이 5년 쓸 거면 이만큼
주의:
· 증가율은 "지금까지의 추세"로 추정하되,
신규 서비스 론칭, 데이터 보관 정책 변경 등
불연속적 증가 요인을 반드시 확인한다.
· "3년 뒤에 증설하지 뭐"라는 생각은 위험하다.
3년 뒤에 예산이 있을지, 같은 모델이 있을지 모른다.벤더 비교 — 숫자의 함정을 읽는 법
RFP를 보내면 벤더마다 화려한 제안서가 온다. 여기서 눈여겨봐야 할 포인트가 있다.
벤더 벤치마크의 함정:
마케팅 스펙: "최대 2,000,000 IOPS!"
이 숫자가 의미 없는 이유:
┌──────────────────────────────────────────────────────┐
│ 함정 1: 블록 크기 │
│ 512B로 테스트하면 IOPS가 엄청나게 높아진다. │
│ 실제 워크로드는 4K~16K. 블록이 커지면 IOPS 떨어짐. │
│ │
│ 함정 2: 읽기/쓰기 비율 │
│ 100% 읽기 테스트 결과일 수 있다. │
│ 쓰기가 섞이면 IOPS가 반 이하로 떨어진다. │
│ RAID 패리티 계산, 캐시 플러시 등 오버헤드 때문. │
│ │
│ 함정 3: 캐시 히트율 │
│ 워킹셋이 캐시에 다 들어가는 크기로 테스트한다. │
│ 실제 환경에서 캐시 히트 100%는 불가능. │
│ │
│ 함정 4: 레이턴시 미표기 │
│ IOPS만 높고 레이턴시가 10ms면 의미 없다. │
│ IOPS와 레이턴시는 반드시 함께 봐야 한다. │
│ │
│ 함정 5: 데이터 리덕션 후 IOPS │
│ "리덕션 적용 후 실효 IOPS"라며 숫자를 부풀리는 │
│ 경우가 있다. 물리 IOPS와 논리 IOPS를 구분해야. │
└──────────────────────────────────────────────────────┘
제안서에서 확인해야 할 것:
┌──────────────────────────────────────────────────────┐
│ 1. 혼합 워크로드 기준 (70% Read / 30% Write, 4K) │
│ 2. IOPS + 평균 Latency + p99 Latency 함께 │
│ 3. 실효 용량 기준 GB당 가격 (RAW 아닌 실효!) │
│ 4. 데이터 리덕션 전(before) / 후(after) 분리 표기 │
│ 5. 3년/5년 TCO (HW + SW + 유지보수 + 전력 + 랙) │
└──────────────────────────────────────────────────────┘PoC(Proof of Concept)를 해야 하는 이유와 방법:
PoC가 필요한 상황:
┌──────────────────────────────────────────────────────┐
│ · 제안서 스펙만으로 판단하기 어려운 경우 │
│ · 벤더 2~3곳이 비슷비슷해서 차이를 확인하고 싶을 때 │
│ · 특수한 워크로드 (Oracle RAC, SAP HANA 등) │
│ · 마이그레이션 호환성 검증이 필요할 때 │
└──────────────────────────────────────────────────────┘
PoC 진행 방법:
① 벤더에 PoC 장비 대여 요청 (보통 2~4주)
② 실제 워크로드 또는 유사 워크로드로 테스트
③ 측정: IOPS, Latency, Throughput, 리덕션 비율
④ 이중화 테스트: 컨트롤러 페일오버 시 IO 영향
⑤ 결과 비교표 작성
PoC의 장점:
· 제안서 숫자가 아닌 "내 환경에서의 실측"을 얻을 수 있다
· 벤더 관리 도구의 사용성을 직접 체험할 수 있다
· 벤더 SE의 기술력을 평가할 수 있다 (설치/설정 과정에서)
PoC의 단점/주의:
· 시간이 든다 (준비~완료까지 1~2개월)
· PoC 환경과 프로덕션 환경이 다를 수 있다
(PoC는 장비 1대인데 프로덕션은 2대 클러스터 등)
· 벤더가 PoC에 "최적화된 설정"을 해올 수 있다
→ 기본값(default) 상태에서도 테스트해봐야 한다
· 모든 도입에 PoC가 필요한 건 아니다
검증된 환경(VMware + NetApp 같은)이면 생략 가능TCO(Total Cost of Ownership) 비교가 특히 중요하다. 하드웨어 가격만 보면 안 된다.
TCO 구성 요소 (5년 기준):
┌──────────────────────────────┬────────────┐
│ 항목 │ 비중 (예시) │
├──────────────────────────────┼────────────┤
│ 하드웨어 (장비 본체) │ 40% │
│ 소프트웨어 라이선스 │ 15% │
│ 유지보수 (연간 계약) │ 25% │
│ 전력/쿨링 │ 10% │
│ 랙 공간 │ 5% │
│ 교육/인력 │ 5% │
└──────────────────────────────┴────────────┘
유지보수비가 해마다 올라가는 벤더도 있다.
5년차에 1년차의 1.5~2배가 되기도 한다.
→ 계약 시 단가 인상률 상한을 협상하라.
TCO 비교 시 자주 빠뜨리는 것:
┌──────────────────────────────────────────────────────┐
│ · 소프트웨어 라이선스 범위 — 복제 기능, 암호화, │
│ 스냅샷, 티어링 등이 기본 포함인지 추가 과금인지. │
│ NetApp은 번들이 많고, Dell은 기능별 라이선스 경향. │
│ │
│ · 증설 시 라이선스 추가 비용 — 디스크만 사면 되는지, │
│ 용량 증가분에 대한 라이선스도 추가인지. │
│ │
│ · 전력 비용 — 올플래시는 HDD 대비 전력 소모가 적지만│
│ 고성능 NVMe 장비는 의외로 전력을 많이 쓴다. │
│ U당 소비전력 × 전기 요금 × 5년으로 계산. │
│ │
│ · 숨은 비용 — 랙 공간(IDC 비용), 교육비, │
│ 마이그레이션 비용(기존→신규), 관리 인력 공수. │
└──────────────────────────────────────────────────────┘주요 벤더 포지셔닝
┌──────────────────────────────────────────────────────────┐
│ 주요 벤더 제품 라인업 (2025 기준) │
├──────────────┬───────────────────────────────────────────┤
│ Dell EMC │ PowerStore: 미드레인지 통합 (블록+파일) │
│ │ PowerMax: 하이엔드 블록 (미션 크리티컬) │
│ │ PowerScale: 스케일아웃 NAS (비정형 대용량) │
├──────────────┼───────────────────────────────────────────┤
│ NetApp │ AFF A-Series: 올플래시 (성능) │
│ │ AFF C-Series: QLC 올플래시 (용량 최적화) │
│ │ FAS: 하이브리드 (HDD+SSD) │
│ │ → ONTAP 통합 OS, NAS+SAN 둘 다 │
├──────────────┼───────────────────────────────────────────┤
│ HPE │ Alletra MP: 통합 블록+파일 │
│ │ InfoSight: AI 기반 예측 분석 강점 │
├──────────────┼───────────────────────────────────────────┤
│ Pure Storage │ FlashArray //X, //XL: 올플래시 블록 │
│ │ FlashArray //C: 용량 최적화 블록 │
│ │ FlashBlade //S, //E: 파일+오브젝트 │
│ │ → Evergreen 구독 모델, 심플함이 강점 │
├──────────────┼───────────────────────────────────────────┤
│ Hitachi │ VSP One: 통합 블록+파일 │
│ Vantara │ → 메인프레임 호환, 금융권 강세 │
└──────────────┴───────────────────────────────────────────┘벤더별 강점만 보면 다 좋아 보인다. 약점과 주의사항도 알아야 공정한 비교가 된다.
┌──────────────────────────────────────────────────────────┐
│ 벤더별 약점 / 주의사항 │
├──────────────┬───────────────────────────────────────────┤
│ Dell EMC │ 제품 라인업이 많아 통합이 과도기. │
│ │ PowerStore/Unity/VNX/XtremIO 등 레거시와 │
│ │ 신규 제품이 혼재. 어떤 제품이 장기 지원될지 │
│ │ 로드맵 확인 필요. 장비 간 마이그레이션 도구 │
│ │ 가 제한적일 수 있음. │
├──────────────┼───────────────────────────────────────────┤
│ NetApp │ 하이엔드(PowerMax급) 포지션이 약함. │
│ │ 초대형 OLTP에서 Dell/Hitachi 대비 선택지가 │
│ │ 제한적. ONTAP 학습 곡선이 타 벤더 대비 높음│
│ │ (SVM, 애그리게이트 등 개념 많음). 하드웨어 │
│ │ 장애 시 WAFL 파일시스템 특성상 복구가 │
│ │ 복잡해질 수 있음. │
├──────────────┼───────────────────────────────────────────┤
│ HPE │ 스토리지 시장 점유율이 Dell/NetApp 대비 │
│ │ 낮음. 제품 라인 재편이 잦아서 장기 로드맵 │
│ │ 불확실성 있음(3PAR→Primera→Alletra). │
│ │ 파트너/SE 인력풀이 상대적으로 작아 장애 시 │
│ │ 대응 속도가 Dell/NetApp보다 느릴 수 있음. │
├──────────────┼───────────────────────────────────────────┤
│ Pure Storage │ NAS/파일 기능은 FlashBlade로 커버하지만 │
│ │ NetApp ONTAP 대비 NAS 기능 성숙도가 낮음. │
│ │ Evergreen 모델이 매력적이지만, 벤더 종속이 │
│ │ 더 강해질 수 있음. 레거시/이기종 환경과의 │
│ │ 호환성 확인 필요. CLI보다 GUI 중심이라 │
│ │ 대량 자동화에서 불편할 수 있음. │
├──────────────┼───────────────────────────────────────────┤
│ Hitachi │ 금융/메인프레임 외 시장에서 존재감 약함. │
│ Vantara │ 가격이 비쌈. 국내 파트너/SE 인력이 다른 │
│ │ 벤더 대비 적어서 지방 사이트 대응이 느릴 │
│ │ 수 있음. 관리 도구 UI가 다소 올드. │
└──────────────┴───────────────────────────────────────────┘라이선스와 구매 모델
구매 모델 비교:
┌────────────────────┬──────────────────┬──────────────────┐
│ │ 전통 구매 (CAPEX)│ 구독/aaS (OPEX) │
├────────────────────┼──────────────────┼──────────────────┤
│ 비용 처리 │ 자산 (감가상각) │ 운영비 │
├────────────────────┼──────────────────┼──────────────────┤
│ 초기 비용 │ 큼 │ 작음 (월/연 과금)│
├────────────────────┼──────────────────┼──────────────────┤
│ 용량 유연성 │ 증설 시 추가구매 │ 필요 시 증감 가능│
├────────────────────┼──────────────────┼──────────────────┤
│ 기술 갱신 │ 5년 후 교체 │ 계약 중 하드웨어 │
│ │ │ 갱신 포함 (벤더별)│
├────────────────────┼──────────────────┼──────────────────┤
│ 5년 총비용 │ 보통 더 저렴 │ 보통 더 비쌈 │
│ │ (할인 협상 시) │ (편의비 포함) │
├────────────────────┼──────────────────┼──────────────────┤
│ 적합한 경우 │ 용량 예측 가능 │ 용량 변동 큼 │
│ │ 장기 사용 확실 │ 초기 투자 어려움 │
│ │ 자산 확보 필요 │ 기술 갱신 중요 │
└────────────────────┴──────────────────┴──────────────────┘
벤더별 aaS 모델:
Pure Evergreen — 컨트롤러 무상 교체. 구독 중 하드웨어 노후화 걱정 없음.
Dell APEX — 사용량 기반 과금. 온프레미스에 클라우드 같은 과금 모델.
NetApp Keystone — 약정 용량 기반. 초과 사용분 추가 과금.
HPE GreenLake — 소비 기반. 서버+스토리지 통합 aaS.
aaS 모델의 함정:
┌──────────────────────────────────────────────────────┐
│ · 최소 약정 기간이 있다 (보통 3년). 중도 해지 시 │
│ 위약금이 발생할 수 있다. │
│ │
│ · 약정 용량 미달이어도 최소 비용이 발생한다. │
│ "10TB 약정했는데 5TB만 써도 10TB 비용" │
│ │
│ · 계약 종료 시 데이터 이전 비용/기간을 확인해야 한다.│
│ "계약 끝나면 장비 수거합니다" → 데이터는? │
│ │
│ · Exit 조건(해지 절차, 데이터 반환, 위약금)을 │
│ 계약서에 반드시 명시해야 한다. │
│ │
│ · 5년 총비용을 CAPEX 모델과 반드시 비교하라. │
│ "월 비용이 작아 보여도" 5년 합산하면 더 비쌀 수. │
└──────────────────────────────────────────────────────┘SLA와 유지보수 계약 — 장비만큼 중요한 계약
스토리지를 살 때 장비만 보면 안 된다. 유지보수 계약이 장비만큼 중요하다. 새벽 3시에 디스크가 나갔을 때 4시간 안에 교체해주는 계약과, "영업일 기준 익일 방문" 계약의 차이는 크다.
유지보수 계약 체크포인트:
┌────────────────────────────────────────────────────┐
│ 항목 │ 질문 │ 주의사항 │
├────────────────┼──────────────────────┼────────────┤
│ 대응 시간 │ 24x7? 8x5? │ 미션 크리티│
│ │ 4시간 현장 대응? │ 컬이면 │
│ │ │ 24x7 필수 │
├────────────────┼──────────────────────┼────────────┤
│ 부품 재고 │ On-site Spare? │ 물류센터 │
│ │ 아니면 물류센터 발송?│ 에서 오면 │
│ │ │ 반나절 추가│
├────────────────┼──────────────────────┼────────────┤
│ 소프트웨어 │ 펌웨어 업데이트 포함?│ 미포함이면 │
│ │ 기능 라이선스 범위? │ 보안패치도 │
│ │ │ 유료 가능 │
├────────────────┼──────────────────────┼────────────┤
│ 기술 지원 │ 전화? 원격 접속? │ 원격 접속은│
│ │ 한국어 지원? │ 보안 정책과│
│ │ │ 충돌 가능 │
├────────────────┼──────────────────────┼────────────┤
│ 에스컬레이션 │ Sev1 대응 프로세스? │ 본사 엔지 │
│ │ 본사 투입 기준? │ 니어 투입은│
│ │ │ 시차 감안 │
├────────────────┼──────────────────────┼────────────┤
│ 비용 인상 │ 연간 인상률 상한? │ 명시 안되면│
│ │ 노후화 추가 비용? │ 매년 협상 │
└────────────────┴──────────────────────┴────────────┘제3자 유지보수(TPM, Third Party Maintenance)도 선택지다. 벤더 직접 계약보다 저렴한 대신 트레이드오프가 있다.
벤더 직접 유지보수 vs 제3자 유지보수(TPM):
┌───────────────────┬──────────────────┬──────────────────┐
│ │ 벤더 직접 │ TPM │
├───────────────────┼──────────────────┼──────────────────┤
│ 비용 │ 높음 │ 30~60% 저렴 │
├───────────────────┼──────────────────┼──────────────────┤
│ 펌웨어 업데이트 │ 포함 │ 미포함! │
│ │ │ 벤더가 TPM 고객에│
│ │ │ 펌웨어 제공 거부 │
│ │ │ 하는 경우 있음 │
├───────────────────┼──────────────────┼──────────────────┤
│ 부품 품질 │ 정품 보장 │ 호환/리퍼 부품 │
│ │ │ 가능성 │
├───────────────────┼──────────────────┼──────────────────┤
│ 기술력 │ 벤더 전문 SE │ 범용 엔지니어 │
│ │ (제품 깊이 이해) │ (깊이 부족 가능) │
├───────────────────┼──────────────────┼──────────────────┤
│ 적합한 경우 │ 현행 장비 │ EOS 지난 구형 │
│ │ 미션 크리티컬 │ 장비 연장 운영 │
│ │ │ 비용 절감 필요 │
├───────────────────┼──────────────────┼──────────────────┤
│ 장애 시 리스크 │ 낮음 │ 중~높음 │
│ │ (벤더가 책임) │ (펌웨어 미패치로 │
│ │ │ 알려진 버그에 │
│ │ │ 노출될 수 있음) │
└───────────────────┴──────────────────┴──────────────────┘
TPM 선택 시 반드시 확인:
· EOS 전에 마지막 펌웨어를 확보해둬야 한다.
TPM으로 전환하면 새 펌웨어를 못 받을 수 있다.
· 디스크/SSD 교체 시 정품 여부를 확인하라.
호환 부품이 스토리지 OS에서 인식 안 될 수 있다.도입 검토는 기술 역량과 비즈니스 감각이 모두 필요한 단계다. 좋은 장비를 사는 것도 중요하지만, 좋은 계약을 맺는 것도 그만큼 중요하다. 벤더 영업의 화려한 슬라이드 뒤에 숨은 조건들을 꼼꼼히 확인하는 게 도입 검토의 본질이다.
다음 편에서는 설계로 넘어간다. 장비를 결정한 후, 실제로 어떻게 구성할 것인가. LUN 레이아웃, 네트워크 이중화, 스냅샷 정책, DR 구성. 설계가 운영의 품질을 결정한다.
이 글이 어떠셨나요?
관련 포스트
Infrastructure
5. RAID와 데이터 보호 — 전통 RAID부터 이레이저 코딩까지
RAID 0/1/5/6/10의 동작 원리부터 대용량 디스크에서 RAID 5가 위험한 이유, 벤더별 독자 RAID 구현, 이레이저 코딩까지. 데이터를 지키는 기술의 본질을 현장 관점에서 정리한다.
2026. 04. 27. 오후 10:00Infrastructure2. 스토리지 아키텍처 기초 — DAS / NAS / SAN / Object Storage
DAS, NAS, SAN, Object Storage의 구조와 차이를 아스키 도표와 함께 정리한다. 어떤 워크로드에 어떤 방식을 선택하는가의 판단 기준과 벤더별 제품 포지셔닝까지.
2026. 04. 06. 오후 10:00Infrastructure1. 스토리지, 왜 어렵고 왜 중요한가
서버는 죽어도 살리면 되지만 스토리지는 잃으면 끝이다. 10년차 시스템 엔지니어가 스토리지가 어렵고 중요한 이유, 스토리지 담당자의 실제 업무, 기술의 진화 흐름을 현장 경험 기반으로 풀어본다.
2026. 03. 30. 오후 10:00뉴스레터 구독
새 글이 올라오면 이메일로 알려드려요.
댓글
댓글을 불러오는 중...