서버 이중화 구축: 계약 전 확인할 운영 기준

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

장애를 전제로 서버 이중화 범위를 먼저 정합니다

멈추면 안 되는 업무부터 고르기

서버 이중화는 장비를 두 대 사는 일이 아니라 어떤 업무를 어느 수준까지 계속 살릴 것인지를 정하는 작업입니다. 사내 ERP, 그룹웨어, 파일 공유, 생산관리, 영업관리처럼 멈췄을 때 손실이 바로 발생하는 시스템과, 몇 시간 지연되어도 되는 시스템은 같은 기준으로 설계하면 예산이 빠르게 커집니다.

구매 상담을 시작하기 전에는 서버의 역할을 먼저 분류해야 합니다. 서버의 기본 개념처럼 중앙에서 데이터를 제공하는 장비는 단순 저장소가 아니라 업무 흐름의 중심이기 때문에, 장애 영향도를 업무 단위로 보는 것이 좋습니다.

• 즉시 복구 대상: 주문, 결제, 생산, 인증처럼 중단 시간이 곧 손실로 이어지는 업무
• 단기 대기 대상: 내부 결재, 문서 공유처럼 1~2시간 지연은 가능하지만 하루 이상은 위험한 업무
• 수동 복구 대상: 테스트 서버, 임시 분석 서버처럼 장애 시 담당자가 순차 복구해도 되는 업무

이 구분이 없으면 모든 서버를 같은 등급으로 묶게 됩니다. 그 결과 정작 중요한 업무에는 복구 자동화가 부족하고, 중요도가 낮은 서버에는 과한 장비와 라이선스가 배치되는 일이 생깁니다.

이중화 견적서에서 가장 먼저 볼 항목은 서버 대수보다 “어떤 장애를 자동으로 넘길 수 있는가”입니다.

RTO와 RPO를 숫자로 써야 견적이 정확해집니다

복구 시간과 데이터 손실 허용치를 나누기

기업 IT시스템에서 이중화 수준을 판단할 때는 감으로 “빨리 복구”라고 표현하면 안 됩니다. RTO는 장애 후 업무가 다시 가능한 시간, RPO는 장애 시 잃어도 되는 데이터의 시간 범위입니다. 두 값을 정하면 서버, 스토리지, 네트워크, 백업 방식이 훨씬 현실적으로 결정됩니다.

예를 들어 회계 시스템은 30분 전 데이터까지 복구되어도 업무 조정이 가능할 수 있지만, 주문 시스템은 5분 전 데이터 손실도 고객 클레임으로 이어질 수 있습니다. 같은 서버 이중화라도 데이터 복제 주기와 장애 전환 방식이 달라지는 이유가 여기에 있습니다.

구매 전 질문 목록

1. 장애가 발생했을 때 사용자가 몇 분 안에 다시 접속해야 합니까?
2. 마지막 저장 데이터가 몇 분 전으로 돌아가도 업무상 허용됩니까?
3. 야간 장애도 자동 전환이 필요합니까, 아니면 담당자 확인 후 전환해도 됩니까?
4. 복구 후 데이터 정합성 검증을 누가, 어떤 기준으로 수행합니까?

이 질문에 답하면 단순한 고사양 서버 구매가 아니라 운영 가능한 인프라 설계로 논의가 바뀝니다. VL시스템처럼 서버와 네트워크 운영 경험을 함께 보는 업체에 문의할 때도, RTO와 RPO가 있으면 견적 비교가 훨씬 선명해집니다.

스토리지와 네트워크는 이중화의 숨은 병목입니다

서버만 두 대면 끝난다는 오해 줄이기

서버 두 대가 있어도 스토리지가 한 곳에만 있거나 네트워크 경로가 하나뿐이면 실제 장애 상황에서는 서비스가 멈출 수 있습니다. 특히 가상화 환경에서는 물리 서버보다 공유 스토리지, 스위치, 방화벽, 회선 구성이 병목이 되는 경우가 많습니다.

따라서 이중화 견적을 받을 때는 서버 사양표만 보지 말고 데이터가 지나가는 경로 전체를 확인해야 합니다. 서버 CPU와 메모리는 넉넉한데 스토리지 IOPS가 부족하면 장애 전환 후 모든 업무가 느려질 수 있고, 스위치가 단일 구성이라면 서버는 살아 있어도 사용자는 접속하지 못합니다.

• 스토리지: RAID 구성, 복제 방식, 스냅샷 보관 기간, 장애 시 읽기·쓰기 가능 여부 확인
• 네트워크: 스위치 이중화, 링크 집성, 방화벽 HA, 회선 백업 여부 확인
• 전원: UPS 용량, PDU 분리, 서버실 전원 계통 분리 가능 여부 확인
• 랙 구성: 두 장비가 같은 전원, 같은 스위치, 같은 장애 지점에 묶여 있지 않은지 확인

IT자산관리시스템 관점에서도 장비 목록과 연결 관계를 문서화해 두면 이중화 설계의 빈틈을 찾기 쉽습니다. 어떤 서버가 어떤 스위치, 어떤 스토리지, 어떤 전원에 연결되어 있는지 표시하면 단일 장애 지점이 한눈에 드러납니다.

운영 계약서에는 장애 전환 절차가 들어가야 합니다

장비 납품보다 운영 책임을 확인하기

서버 이중화 구축에서 자주 빠지는 부분이 운영 계약입니다. 구축 시점에는 데모 전환이 잘 되었더라도, 실제 장애가 주말 새벽에 발생했을 때 누가 알림을 받고 누가 전환을 승인하며 누가 데이터 정합성을 확인하는지가 정해져 있지 않으면 복구 시간이 길어집니다.

운영 계약서에는 모니터링 항목, 알림 기준, 장애 등급, 대응 시간, 원격 접속 방식, 현장 출동 조건이 구체적으로 들어가야 합니다. “장애 대응 포함”이라는 문구만으로는 부족합니다. CPU 임계치 경고와 서비스 중단 장애는 대응 방식이 전혀 다르기 때문입니다.

계약 전 확인할 문장

• 장애 감지는 24시간 자동 모니터링인지, 업무시간 수동 확인인지 확인합니다.
• 장애 전환은 자동인지, 담당자 승인 후 수동인지 문서에 남깁니다.
• 복구 후 보고서에는 원인, 조치 시간, 재발 방지 항목이 포함되는지 확인합니다.
• 정기 점검에는 로그 확인, 패치 현황, 백업 성공률, 전환 테스트가 포함되어야 합니다.

대규모 공공 IT 서비스도 시스템 운영 범위와 역할 정의가 중요합니다. 참고로 범정부 IT 서비스 시스템 같은 사례를 보면, IT 서비스는 단일 장비보다 서비스 체계와 운영 절차의 관점에서 이해하는 편이 현실적입니다.

장애 대응 SLA는 “언제까지 출동”보다 “언제까지 업무가 다시 가능한 상태가 되는가”로 읽어야 합니다.

비용표는 초기 구축비와 운영비를 분리해서 봅니다

예산이 새는 구간 찾기

서버 이중화 비용은 장비 가격만으로 판단하기 어렵습니다. 초기 구축비에는 서버, 스토리지, 스위치, 방화벽, 랙, UPS, 라이선스, 설치 작업비가 들어가고, 운영비에는 모니터링, 정기 점검, 장애 대응, 백업 관리, 보안 패치, 장비 유지보수가 포함됩니다.

중소기업 환경에서는 모든 항목을 최고 사양으로 맞추기보다 업무 중요도에 맞춰 단계적으로 구성하는 방식이 더 현실적입니다. 예를 들어 핵심 업무 서버는 실시간 복제와 빠른 장애 전환을 적용하고, 중요도가 낮은 내부 문서 서버는 백업 복구 중심으로 설계할 수 있습니다.

• 구축비만 낮은 견적은 운영 항목이 빠져 있는지 확인합니다.
• 운영비가 높은 견적은 실제 대응 범위와 보고서 품질을 비교합니다.
• 라이선스 비용은 가상화, 백업, 보안 솔루션별 갱신 조건을 따로 봅니다.

견적 비교 시에는 총액보다 항목별 역할을 보는 편이 안전합니다. 싸게 시작했지만 장애 전환 테스트, 백업 검증, 패치 작업이 모두 별도 비용이면 장기적으로 더 비쌀 수 있습니다.

내 서버실 사진 한 장으로 점검을 시작합니다

지금 바로 할 수 있는 현장 확인

전문 장비 도입 전에도 기업이 바로 할 수 있는 일이 있습니다. 서버실이나 통신함을 열고 사진을 찍은 뒤, 서버·스위치·방화벽·NAS·UPS가 어디에 연결되어 있는지 표시해 보십시오. 이 간단한 작업만으로도 네트워크 단일 장애 지점과 전원 취약 구간이 꽤 많이 드러납니다.

사진 점검은 담당자 한 명의 기억에 의존하던 인프라 정보를 문서로 바꾸는 첫 단계입니다. 케이블 라벨이 없거나, 장비명이 다르거나, UPS에 모든 장비가 한꺼번에 꽂혀 있다면 이중화 전에 정리해야 할 운영 리스크가 있다는 뜻입니다.

1. 서버실 정면 사진과 장비 후면 케이블 사진을 각각 촬영합니다.
2. 서버, 스위치, 방화벽, 스토리지, UPS 이름을 사진 위에 표시합니다.
3. 각 장비의 전원 연결과 네트워크 연결을 선으로 표시합니다.
4. 같은 장비 하나가 멈췄을 때 함께 멈추는 업무를 옆에 적습니다.
5. 이 자료를 기반으로 VL시스템 같은 IT 인프라 전문 업체에 현황 진단을 요청합니다.

이 과정에서 “서버는 두 대인데 스위치는 한 대”, “백업 장비는 있는데 복구 테스트 기록이 없음”, “인터넷 회선은 이중화되어 있지만 방화벽은 단일 장비” 같은 현실적인 문제가 나옵니다. 구매 상담 전 이 자료를 준비하면 불필요한 장비 추천을 줄이고, 회사 업무에 맞는 서버 이중화 설계를 더 빠르게 받을 수 있습니다.