클라우드 운영 대행 업체 선정 가이드

제안서마다 적힌 대응 시간은 비슷해 보입니다. 그 시계가 언제부터 도는지에서 갈립니다. 감지 시각인지, 고객이 전화한 시각인지, 대행사 접수 시스템에 등록된 시각인지에 따라 같은 30분이 전혀 다른 약속이 됩니다. 접수 창구가 이메일 한 곳뿐이면 새벽 장애에서 시계는 담당자가 출근한 뒤에 돕니다.

응답과 복구도 갈라 읽습니다. 대부분의 약정은 초동 응답 시간이고 복구 시간을 약속하는 곳은 드뭅니다. 초동 응답만 지키고 복구가 며칠 걸려도 약정 위반이 아닌 계약이 실제로 있습니다. 응답 뒤 무엇을 하기로 했는지, 몇 시간마다 경과를 알리는지, 등급을 누가 올릴 수 있는지를 같은 표에 적어 받습니다. 이 표가 없으면 장애가 길어지는 동안 우리 쪽에서 상황을 묻는 일이 업무가 됩니다.

약정을 못 지켰을 때 무엇이 일어나는지도 확인합니다. 대개는 월 요금의 일부를 크레딧으로 돌려주고 끝납니다. 서비스가 멈춰 생긴 손해에 비하면 작은 값이므로 이 조항은 배상이 아니라 대행사가 스스로에게 매기는 벌점으로 읽는 편이 정확합니다.

등급 정의를 우리 서비스 기준으로 다시 씁니다. 대행사 표준 등급표는 서버가 죽었는지를 기준으로 쓰여 있는 경우가 많은데, 결제만 실패하고 나머지가 멀쩡한 상태가 우리에게는 최상위 장애입니다. 우리 서비스에서 무엇이 멈추면 1등급인지를 계약서 부속 문서에 적어 두면 새벽에 등급을 두고 다투지 않습니다.

약정이 실효가 있는지는 사람 배치로 확인합니다. 야간 당직이 교대 근무인지 호출 대기인지, 한 사람이 동시에 몇 개 고객사를 보는지, 우리 서비스를 아는 사람이 몇 명인지 물어봅니다. 24시간이라고 적혀 있어도 밤에 깨어 있는 사람이 없으면 그 문장은 전화를 받겠다는 약속에 가깝습니다.

운영을 맡긴다는 것은 접근 권한을 넘긴다는 뜻입니다. 최상위 관리자 계정까지 넘기면 대행사가 우리 계정에서 무엇이든 할 수 있고 반대로 권한을 지나치게 좁히면 장애 때마다 승인을 기다리다 복구가 늦습니다. 경계는 역할로 긋습니다. 조회와 재기동은 상시로 열고 자원 생성과 삭제, 권한 변경은 승인 절차 뒤에 둡니다. 장애 상황에서만 열리는 임시 권한을 따로 두면 평시 권한을 넓히지 않고도 복구가 늦지 않습니다.

계정 명의가 더 중요합니다. 대행사 명의 계정 안에 우리 자원이 들어가 있으면 계약이 끝날 때 자원을 옮겨야 하고 그 이전 작업이 새 프로젝트만큼 커집니다. 계정은 고객사 명의로 만들고 대행사는 관리 권한을 받아 쓰는 구조가 나중을 위해 안전합니다. 도메인과 인증서, DNS도 같은 원칙을 따릅니다. 대행사 계정에 등록된 도메인은 계약이 틀어졌을 때 협상 카드가 됩니다. 청구까지 대행사가 대신 처리하는 구조를 고른다면 원본 청구 내역을 매달 받아 둡니다.

누가 언제 무엇을 했는지 기록이 남는지도 봅니다. 감사 로그가 대행사 계정에만 쌓이면 사고가 났을 때 우리는 기록을 요청하는 쪽이 됩니다. 로그는 우리 계정에 저장되게 하고 보관 기간을 계약서에 적습니다.

접속 수단의 관리 방식도 같은 자리에서 묻습니다. 서버 접속 키와 데이터베이스 비밀번호를 어디에 보관하는지, 대행사 담당자가 바뀔 때 권한을 며칠 안에 회수하는지, 재하도급이 있는지 확인합니다. 하도급이 있으면 실제로 우리 계정에 들어오는 사람은 계약서에 이름이 없는 회사의 인력입니다.

장애보다 잦은 것이 변경입니다. 패치와 구성 수정, 자원 증설이 매주 일어나고 장애 원인의 상당수가 직전 변경입니다. 정기 작업 창이 언제인지, 긴급 변경은 누가 사후 승인하는지, 우리 쪽 승인자가 몇 명인지를 먼저 정합니다. 마감이나 정산처럼 멈출 수 없는 일정은 달력에 먼저 올려 두고 그 기간에는 작업 창을 열지 않습니다. 승인자가 우리 조직에 없으면 대행사가 스스로 바꾸고 스스로 기록하는 상태가 됩니다.

기록의 형식도 정합니다. 변경 이력이 대행사 담당자의 메신저 대화로만 남으면 담당이 바뀌는 순간 사라집니다. 무엇을 언제 왜 바꿨고 되돌리려면 어떤 순서를 밟는지가 한곳에 남아야 장애 조사에서 직전 변경을 찾아낼 수 있습니다.

승인에도 시간 약속이 필요합니다. 우리 승인이 늦어 작업이 밀린 건과 대행사가 늦어 밀린 건을 구분해 기록하지 않으면 지연의 책임이 매번 흐려집니다. 변경이 실패했을 때 되돌리는 작업까지 정액에 포함인지도 여기서 정합니다.

월간 리뷰는 이 기록을 읽는 자리입니다. 지난달 장애와 변경, 미처리 과제를 같은 문서로 보고받고 다음 달에 할 일을 정합니다. 리뷰가 지표 몇 장을 읽고 끝나는 회의라면 대행사는 개선을 팔지 않고 유지만 팝니다.

대행사가 자기 도구로 감시하면 계약 기간에는 편합니다. 문제는 끝날 때입니다. 대시보드와 경보 규칙, 임계값이 대행사 구독 안에 있으면 계약이 끝나는 날 관측이 함께 꺼집니다. 우리 서비스를 어떤 눈으로 봐 왔는지가 통째로 다른 회사에 남습니다. 몇 년치 지표 이력도 같이 사라집니다.

도구 계정을 누가 소유하는지, 경보 규칙과 대시보드 정의를 내보낼 수 있는지, 지표 이력을 넘겨받을 수 있는지를 계약 전에 확인합니다. 런북도 같습니다. 장애 유형별 확인 순서와 조치 명령이 적힌 문서는 운영 자산이며 대행사가 만들었더라도 우리 저장소에 함께 쌓이도록 정하는 편이 낫습니다.

경보는 개수로 보지 않습니다. 경보가 많다고 더 안전해지지 않으며 오히려 무시당하기 쉬워집니다. 지난달 발생한 경보 가운데 실제 조치로 이어진 비율을 물어보면 대행사가 경보를 설계해 왔는지 켜 두기만 했는지가 드러납니다. 조치 없이 닫히는 경보가 대부분이면 당직자는 이미 알림을 읽지 않고 있습니다.

견적은 정액과 종량 두 갈래로 나옵니다. 정액은 예산을 세우기 쉽지만 그 값에 무엇이 들어 있는지가 계약마다 다릅니다. 월 몇 건까지의 요청이 포함인지, 야간 호출이 포함인지, 인원 몇 명 기준인지가 적혀 있지 않으면 바쁜 달마다 추가 청구가 붙습니다.

종량은 실제 쓴 만큼 냅니다. 대신 조용한 달에는 싸고 장애가 잦은 달에는 비싸므로 가장 필요한 순간에 비용을 이유로 호출을 망설이게 됩니다. 어느 쪽을 고르든 별도 청구 항목은 목록으로 받아 둡니다. 이전과 재구축, 신규 구축, 보안 사고 대응, 정기 리뷰 참석은 운영 정액에서 빠지는 일이 흔합니다. 목록을 받아 보면 정액이 비싼 제안이 오히려 총액에서 싼 경우가 나옵니다.

클라우드 사용료를 대행사가 재판매하는 구조라면 마진율을 묻습니다. 사용료와 운영비가 한 장의 청구서로 오면 어느 쪽이 올랐는지 보이지 않습니다. 비용 절감을 함께 맡기는 경우에는 이해가 어긋나는 지점도 확인합니다. 사용료에 마진이 붙는 구조에서는 사용량이 줄면 대행사 매출도 줄어듭니다.

계약 조건 자체에도 값이 있습니다. 온보딩 비용이 따로 붙는지, 최소 계약 기간이 몇 개월인지, 자동 갱신 조항이 있는지, 해지 통보를 몇 주 전에 해야 하는지가 갈아탈 자유의 값을 정합니다. 첫 달 견적이 싼 대신 해지 통보 기한이 석 달인 계약은 싼 계약이 아닙니다.

운영 대행 계약은 시작보다 끝이 어렵습니다. 그래서 종료 조항을 계약 전에 읽습니다. 인수인계 범위와 기간, 병행 운영을 몇 주 하는지, 문서와 스크립트를 어떤 형식으로 넘기는지, 권한 이전을 누가 언제 수행하는지가 적혀 있어야 합니다. 인수인계를 별도 비용으로 청구하는 조항이 있는지도 이때 봅니다.

잘못 고른 계약이 끝나면 환경은 남고 설명이 사라집니다. 왜 이 자원이 있는지 아무도 모르고 경보는 꺼져 있고 복구 절차는 대행사 담당자의 기억에만 있던 상태가 됩니다. 다음 대행사는 그 상태를 파악하는 데만 몇 달을 씁니다. 그 시간이 우리가 낸 값의 일부였습니다. 대행사가 나쁜 회사여서 벌어지는 일이 아니라 남길 것을 계약에 적지 않아서 벌어지는 일입니다.

그래서 고르는 기준은 매달 받는 보고서보다 남는 자산에 가깝습니다. 계약 첫 달에 무엇을 받고 마지막 달에 무엇을 돌려받는지를 제안서에 적게 하면, 값이 비슷한 두 제안이 서로 다른 물건이었다는 사실이 드러납니다.

짧게 시작하는 방법도 있습니다. 한 분기짜리 범위로 먼저 맡기고 그동안 남는 문서와 응답 기록을 보고 확장 여부를 정하면, 판단 근거가 제안서가 아니라 실제 운영이 됩니다. 시범 기간을 거절하는 대행사보다 시범 기간에 무엇을 남길지 먼저 적어 오는 대행사가 대개 계약 종료도 깔끔합니다.