서버관리 회사 고를 때 운영 범위 확인하는 방법

서버 장애를 접수받아 보면 사양이 모자라서 멈춘 경우보다 백업이 안 되거나 설정 변경 기록이 없어 복구가 늦어진 경우가 더 많았다. 서버관리 회사를 찾을 때도 CPU와 메모리 숫자부터 비교하기 쉽다. 그런데 먼저 확인할 것은 누가 어디까지 운영하고, 문제가 생기면 어떤 순서로 움직이는지다.

현재 서버에서 맡길 일을 먼저 적는다

웹호스팅, VPS, 클라우드 서버는 운영자가 직접 챙겨야 하는 범위가 다르다. VPS라면 운영체제 보안 업데이트, 방화벽, 웹서버 설정, 데이터베이스와 백업까지 책임 주체를 확인해야 한다. Amazon Web Services도 가상 서버의 운영체제와 애플리케이션 패치는 이용자 책임으로 설명한다. 서버를 빌렸다는 사실만으로 관리까지 맡긴 셈은 아니다.

계약 전에 현재 환경을 한 장에 적어 두면 상담이 빨라진다. 서버 대수와 사양, 운영체제, 웹서버와 데이터베이스 종류, 배포 방식, 도메인과 SSL 인증서 만료일, 백업 위치와 보관 기간 정도면 된다. 접속 정보는 이 문서에 넣지 않는다. 관리 회사에는 목록을 보여주고 각 항목의 담당자를 지정해 달라고 요청하면 된다.

작은 기업 사이트 한 대라면 상시 운영 인력을 붙이는 비용이 과할 수 있다. 호스팅 업체가 제공하는 관리 기능과 자동 백업을 먼저 확인하고, 월간 점검이나 장애 대응만 별도로 맡기는 방식도 가능하다. 반대로 주문이나 예약이 밤에도 들어오는 서비스라면 야간 알림을 실제로 받을 사람이 있는지가 중요하다.

견적은 서버 사양보다 작업 범위로 비교한다

같은 ‘월 관리’라도 포함된 일은 업체마다 다르다. 모니터링만 하는 곳도 있고, 패치와 백업, 복구까지 맡는 곳도 있다. 견적서에는 운영체제와 웹서버 패치 주기, 데이터베이스 관리 범위, SSL 갱신 담당, 월간 보고 항목, 장애 대응 시간을 각각 적어야 비교가 된다. ‘24시간 모니터링’이라는 문구만으로 24시간 엔지니어 조치를 뜻한다고 받아들이면 곤란하다.

요금은 기본료와 추가 작업비를 나눠 본다. 월 관리비가 낮아도 야간 출동, 긴급 복구, 서버 이전이 모두 별도라면 실제 비용은 달라진다. 월 1회 점검 계약이라면 점검 밖의 장애 접수 비용과 작업 승인 절차도 확인해야 한다. 계약 해지 시 설정 파일, 백업 데이터, 계정 권한을 어떤 형태로 돌려받는지도 비용만큼 중요하다.

서버 증설 제안에는 측정값을 요청한다. 예를 들어 메모리 사용률이 높아 보여도 운영체제가 파일 캐시에 쓰는 용량인지, 실제로 메모리 부족으로 프로세스가 종료되는지에 따라 처방이 다르다. CPU 평균 사용률 하나보다 피크 시간대의 응답 시간, 오류율, 디스크 대기, 데이터베이스 연결 수를 함께 봐야 한다. 구글 클라우드의 안정성 안내도 요청 오류와 응답 시간 같은 서비스 지표를 인프라 지표와 함께 관찰하도록 권한다.

백업은 복원 시간까지 확인한다

‘매일 백업합니다’라는 답만으로는 부족하다. 자정에 한 번 백업한다면 오후 11시에 장애가 났을 때 최악의 경우 거의 하루치 변경분을 잃을 수 있다. 얼마나 오래된 데이터까지 되돌아갈 수 있는지를 복구 시점 목표인 RPO로, 서비스를 다시 열기까지 허용할 시간을 복구 시간 목표인 RTO로 적는다. 주문 데이터와 회사 소개 페이지의 목표가 같을 필요는 없다.

백업 파일이 원본 서버와 같은 디스크에만 있으면 디스크 장애나 계정 침해 때 함께 사라질 수 있다. 별도 저장 위치, 보관 기간, 삭제 권한을 확인한다. 데이터베이스 덤프가 만들어졌다는 기록만 보지 말고 시험 서버에 복원해 화면과 핵심 기능이 동작하는지 점검해야 한다. 큰 파일이 많은 사이트라면 내려받기와 복원에 걸리는 시간도 재야 한다.

서버 이전 견적도 이 기준으로 본다. 이전 전 전체 백업, 시험 이전, 변경 내용 동기화, 최종 전환, 문제가 생겼을 때 되돌릴 조건과 담당자를 순서대로 적어야 한다. 도메인 설정을 바꾸는 순간만 이전 작업으로 잡으면 데이터베이스 변경분이나 메일 기록을 놓치기 쉽다.

장애 대응은 실제 상황을 놓고 묻는다

상담할 때 ‘새벽에 사이트 접속이 안 되면 누가 어떤 순서로 확인하나요?’라고 물어보면 운영 방식이 드러난다. 외부 접속 확인, DNS와 인증서 상태, 웹서버 응답, 디스크 여유 공간, 최근 배포와 설정 변경, 데이터베이스 연결 상태를 차례로 확인할 수 있어야 한다. 장애 원인이 확인되지 않았는데 무조건 서버부터 재시작한다는 답은 신중히 볼 필요가 있다.

대응 시간을 약속받을 때는 접수 확인과 작업 시작, 서비스 복구를 구분한다. ‘30분 내 응답’은 30분 내 복구와 다르다. 월 가동률 99.9%도 30일 기준으로 환산하면 약 43분의 중단 시간을 허용하는 수치다. 이 숫자만 보고 선택하기보다 우리 서비스가 몇 시에 멈추면 가장 큰 피해가 나는지, 그 시간에 연락과 조치가 가능한지를 맞춰 봐야 한다.

내가 업체를 고른다면 화려한 관리 항목보다 최근 복원 시험 결과와 장애 기록 예시를 먼저 보겠다. 평소에는 작은 요금제와 단순한 구성으로 충분한 사이트가 많다. 대신 백업을 실제로 되돌릴 수 있고, 장애가 났을 때 책임질 사람이 분명해야 서버 비용도 제값을 한다.