1. 스토리지, 왜 어렵고 왜 중요한가

서버가 죽으면 다시 켜면 된다.

OS가 날아가면 다시 설치하면 된다. 이미지 떠놓은 게 있으면 30분이면 복구된다. 클러스터로 묶어놨으면 자동으로 페일오버되고, 사용자는 눈치도 못 챈다. 서버는 그런 거다. 대체 가능하고, 복구 가능하다.

스토리지는 다르다.

스토리지가 죽으면 데이터가 날아간다. 데이터가 날아가면 끝이다. OS는 다시 설치하면 되지만, 고객 데이터 10년치를 다시 만들 수는 없다. 이게 서버와 스토리지의 근본적인 차이다. 서버는 "컴퓨팅 자원"이고, 스토리지는 "데이터 그 자체"다.

그래서 스토리지 앞에서는 누구나 겸손해진다. 경력 10년차 엔지니어도 스토리지 펌웨어 업그레이드 전날 밤에는 잠이 잘 안 온다. 혹시 뭔가 잘못되면? 컨트롤러가 안 올라오면? 데이터가 날아가면? 이 불안감은 경력이 쌓인다고 사라지지 않는다. 오히려 경험이 많을수록 "무엇이 잘못될 수 있는지"를 더 많이 알게 되니까, 불안은 더 구체적이 된다.

스토리지가 어려운 진짜 이유

시스템 엔지니어에게 스토리지가 어려운 이유는 기술 자체의 복잡성 때문만은 아니다. 몇 가지 구조적인 이유가 있다.

첫째, 블랙박스 문제다.

서버는 열어볼 수 있다. CPU가 뭔지 보이고, 메모리가 몇 장 꽂혀있는지 보인다. OS에 들어가면 top, iostat, vmstat으로 속을 다 들여다볼 수 있다. 리눅스를 10년 다뤘으면 서버 안에서 무슨 일이 벌어지는지 대략 감이 온다.

스토리지는 그게 안 된다. 벤더가 만든 전용 OS가 돌아간다. NetApp은 ONTAP, Dell은 PowerStore OS, Pure는 Purity. 이 안에서 어떻게 IO가 처리되고, 캐시가 어떻게 동작하고, RAID 리빌드가 내부적으로 어떤 순서로 진행되는지를 엔지니어가 완전히 이해하기는 어렵다. 벤더 SE한테 물어봐도 "내부 로직이라 상세 공개가 어렵습니다"라는 답이 돌아올 때가 많다.

결국 스토리지 운영은 어느 정도 "믿음"에 기반한다. 벤더를 믿고, 펌웨어를 믿고, 매뉴얼을 믿는 거다. 이 믿음이 배신당하는 순간이 올 때 — 그러니까 장애가 터졌는데 원인을 알 수 없을 때 — 엔지니어는 무력감을 느낀다.

둘째, 성능과 안정성의 트레이드오프다.

서버에서 성능을 올리는 건 비교적 단순하다. CPU를 더 빠른 걸로 바꾸거나, 메모리를 더 꽂거나, 수평 확장하거나. 대부분의 경우 안정성과 충돌하지 않는다.

스토리지에서는 이 둘이 자주 충돌한다. RAID 5가 성능은 좋지만 대용량 디스크에서는 리빌드 중 두 번째 디스크가 나갈 확률이 생각보다 높다. 씬 프로비저닝을 쓰면 용량을 효율적으로 쓸 수 있지만, 실제 물리 용량이 부족해지면 갑자기 볼륨이 오프라인된다. 압축과 중복제거를 켜면 실효 용량은 늘어나지만 컨트롤러 CPU 부하가 올라간다.

모든 선택에 트레이드오프가 따라온다. 이 트레이드오프를 이해하고 판단하는 게 스토리지 엔지니어링의 핵심이다.

셋째, 벤더 종속성이다.

리눅스 서버는 어떤 벤더 하드웨어든 같은 리눅스를 설치할 수 있다. HP 서버든 Dell 서버든 Lenovo든, 운영 방법이 크게 다르지 않다. 스토리지는 완전히 다르다. NetApp을 10년 운영한 경험이 Dell EMC로 갈 때 절반은 버려야 한다. CLI가 다르고, 개념이 다르고, 아키텍처가 다르다.

NetApp에서는 "애그리게이트 위에 볼륨을 만들고, 볼륨 안에 LUN을 만든다." Dell PowerStore에서는 "스토리지 풀에서 바로 볼륨을 만든다." Pure Storage는 "그냥 볼륨 만들면 된다. 나머지는 우리가 알아서 한다." 같은 "볼륨"이라는 단어를 쓰지만 내부적으로 돌아가는 구조가 전혀 다르다.

이 벤더 종속성 때문에 스토리지 엔지니어는 특정 벤더에 깊이 파고들수록 다른 벤더로 이동하기 어려워진다. 그래서 이 시리즈에서는 특정 벤더에 종속되지 않는 범용적인 개념과, 벤더별 차이를 함께 다루려고 한다.

그래서 스토리지 담당자는 뭘 하는가

"스토리지 담당이라 그러는데, 볼륨 좀 할당해 주세요."

이 말을 얼마나 많이 듣는지. 서버팀이나 DBA팀에서 보면 스토리지 담당자의 일은 "볼륨 만들어주는 사람" 정도로 보일 수 있다. 실제로 운영의 상당 부분이 그렇기도 하다. 하지만 그게 전부는 아니다.

스토리지 담당자의 일을 대략 나열해보면 이렇다.

  스토리지 담당자의 업무 비중 (체감 기준):
  
  볼륨 할당/확장/변경   ████████████████████░░░░░  40%
  모니터링/용량 관리     ████████████░░░░░░░░░░░░  25%
  장애 대응             ██████░░░░░░░░░░░░░░░░░░  15%
  변경 작업(계획된)      ████░░░░░░░░░░░░░░░░░░░░  10%
  벤더 미팅/기타         ████░░░░░░░░░░░░░░░░░░░░  10%

• 일상 업무 — 볼륨 할당 요청 처리, 볼륨 확장, 호스트 연결, Zoning 변경. 이게 하루의 절반 이상을 차지한다. 매일 들어오는 ITSM 티켓을 처리하는 거다. 단순해 보이지만, 잘못된 호스트에 볼륨을 매핑하면 데이터가 날아갈 수 있으니 매번 긴장한다.
• 모니터링과 용량 관리 — 스토리지 성능 메트릭을 보고, 용량 추이를 분석하고, "이 추세면 3개월 뒤에 공간이 부족하겠다"는 판단을 한다. 주간/월간 리포트를 만들어 보고한다. 갑자기 레이턴시가 튀면 원인을 분석한다.
• 장애 대응 — 새벽에 디스크 장애 알람이 오면 일어나서 확인한다. 컨트롤러가 페일오버됐다는 알람이 오면 심장이 뛴다. 벤더 서포트에 SR을 열고, 로그를 수집하고, 필요하면 현장에 부품 교체를 요청한다.
• 변경 작업 — 펌웨어 업그레이드, 설정 변경, 복제 정책 변경 같은 계획된 작업. 변경 관리 프로세스에 따라 RFC를 작성하고, 승인을 받고, 야간이나 주말에 작업한다. NDU(Non-Disruptive Upgrade)라 서비스에 영향이 없다고 하지만, 그래도 작업 중에는 모니터링 화면을 뚫어지게 쳐다본다.
• 기타 — 벤더 미팅, 신규 장비 도입 검토, 설계 리뷰, 마이그레이션 계획, 유지보수 계약 갱신, EOS/EOL 대응 계획 수립.

"서버팀이 보는 스토리지"와 "스토리지팀이 보는 스토리지"는 상당히 다르다. 서버팀에서는 "/dev/sdb1이 마운트 안 된다"가 문제고, 스토리지팀에서는 "왜 이 경로가 안 보이는지, Fabric에서 뭐가 끊겼는지, ALUA 상태가 어떤지"를 추적한다. 같은 현상을 보는 시야의 깊이가 다른 거다.

스토리지 기술은 어떻게 변해왔나

스토리지를 처음 다루게 됐을 때, 가장 혼란스러웠던 건 용어였다. DAS, NAS, SAN, FC, iSCSI, RAID, LUN, 볼륨, 애그리게이트, 스토리지 풀. 이 단어들이 어디서 왔고, 왜 이렇게 복잡한지를 이해하려면 역사를 조금 알아야 한다.

아주 간단하게 흐름만 짚으면 이렇다.

  스토리지 기술 진화 흐름:
  
  1970~80s         1990~2000s         2010s            2020s~
  ┌───────┐      ┌───────────┐    ┌──────────┐    ┌───────────┐
  │  DAS  │ ───► │ SAN / NAS │ ──►│ 올플래시  │ ──►│ SDS /     │
  │       │      │ (FC,NFS)  │    │ (SSD혁명) │    │ 클라우드   │
  └───────┘      └───────────┘    └──────────┘    └───────────┘
  서버에         스토리지를        HDD→SSD로       소프트웨어로
  직접 연결      네트워크로 분리   성능 패러다임    스토리지 구현
                                  전환             (Ceph,vSAN,S3)

• 메인프레임 시대 — 스토리지는 서버에 직접 붙어있었다. DAS(Direct Attached Storage). 서버 하나에 디스크 하나. 단순했다.
• SAN의 등장 — 서버가 많아지면서 "스토리지를 따로 빼서 여러 서버가 공유하면 안 될까?"라는 생각이 나왔다. Fibre Channel이라는 전용 네트워크를 깔고, 스토리지를 블록 레벨로 공유하는 SAN(Storage Area Network)이 등장했다. 2000년대 초반, 엔터프라이즈 인프라의 표준이 됐다.
• NAS의 진화 — 파일 단위로 공유하고 싶은 수요도 있었다. NFS나 SMB로 접근하는 NAS(Network Attached Storage)가 발전했다. 초기에는 성능이 좀 부족했지만, 네트워크 속도가 올라가면서 NAS도 미션 크리티컬 워크로드를 감당할 수 있게 됐다.
• 올플래시의 혁명 — SSD가 HDD를 대체하기 시작하면서 게임이 바뀌었다. HDD 시절에는 디스크 회전 속도(RPM)와 디스크 개수가 성능을 결정했다. IOPS를 올리려면 디스크를 더 많이 꽂아야 했다. 올플래시 시대에는 디스크 수가 아니라 컨트롤러 성능이 병목이 됐다. 스토리지 설계의 패러다임이 바뀐 거다.
• SDS와 클라우드 — 최근에는 소프트웨어 정의 스토리지(SDS)가 부상하고 있다. Ceph, MinIO, vSAN 같은 것들. 범용 서버에 소프트웨어를 올려서 스토리지를 만드는 방식이다. 클라우드에서는 AWS S3, EBS 같은 서비스가 물리 스토리지를 완전히 추상화했다.

이 흐름을 알면, 지금 현장에서 마주치는 기술들이 왜 그런 모양인지가 이해된다. FC SAN이 아직 쓰이는 이유, iSCSI가 대안이 되는 맥락, 올플래시에서 RAID 5가 위험하지 않은 이유, Object Storage가 백업 타겟으로 뜨는 배경. 다 이 역사의 연장선이다.

이 시리즈에서 다루는 것

이 시리즈는 스토리지의 라이프사이클을 따라간다.

장비를 검토하고, 설계하고, 구축하고, 인수시험하고, 일상적으로 운영하고, 장애에 대응하고, 수명이 다하면 마이그레이션하고 폐기하는 전 과정이다.

각 단계마다 "시스템 엔지니어가 실제로 해야 하는 일"에 집중한다. 이론적으로 완벽한 설명보다, 현장에서 바로 쓸 수 있는 지식을 담으려고 한다. 벤더별 차이점도 빼놓지 않는다. Dell, NetApp, HPE, Pure Storage — 같은 개념이라도 벤더마다 접근이 다르고, 그 차이를 아는 게 실력이다.

전체 구성은 이렇다.

기초 지식으로 아키텍처(DAS/NAS/SAN/Object), 병렬 파일 시스템(Lustre/GPFS/HDFS), 프로토콜(FC/iSCSI/NFS/SMB), RAID와 데이터 보호를 다루고, 라이프사이클을 따라 도입 검토, 설계, 구축, 인수시험, 일상 운영(볼륨 할당/변경 관리, 모니터링/성능 튜닝), 데이터 효율화, 백업, 보안, 장애 대응, 유지보수/수명 관리, 마이그레이션을 거쳐, 마지막으로 운영 자동화·문서화와 클라우드 시대의 전망까지. 총 20편이다.

한 편 한 편이 독립적으로 읽혀도 가치가 있도록 쓰되, 시리즈 전체를 따라가면 스토리지 운영의 전체 그림이 그려지는 구조를 목표로 한다.

누구를 위한 글인가

이 시리즈의 1순위 독자는 "스토리지를 처음 맡게 된 시스템 엔지니어"다.

서버나 네트워크는 어느 정도 아는데, 스토리지는 막연하게 느끼는 사람. "SAN이 뭔지는 알겠는데, 실제로 Zoning을 잡아본 적은 없다"는 수준의 사람. 이 사람이 시리즈를 다 읽으면 스토리지 장비 앞에 앉았을 때 뭘 해야 하는지 감이 잡히는 것. 그게 이 시리즈의 목표다.

2순위 독자는 이미 스토리지를 운영하고 있지만, 특정 벤더 경험만 있는 사람이다. NetApp만 10년 했는데 Dell도 알아야 하는 상황, 또는 그 반대. 벤더 비교 관점에서 시야를 넓히는 데 도움이 될 거다.

다음 편에서는 스토리지 아키텍처의 기초부터 시작한다. DAS, NAS, SAN, Object Storage. 이 네 가지가 왜 존재하고, 언제 뭘 쓰는지. 그 판단 기준을 잡는 게 모든 것의 출발점이다.