운영을 맡기기로 했다면, 어느 수준으로 계약해야 합니까

운영을 맡기기로 정하고 나면 질문이 한 칸 옮겨 갑니다. 맡길 것인가가 아니라, 어느 수준으로 계약할 것인가입니다. 그런데 이 질문은 대개 여러 업체의 등급표를 나란히 펴 놓고 항목을 세는 방식으로 풀리고, 항목 수가 비슷해 보이면 결국 값이 결정을 대신합니다.

이 글은 그 비교의 축을 바꾸자고 제안합니다. 수준은 기능이 몇 개 포함되는가로 나뉘지 않습니다. 책임이 어디로 이전되는가로 나뉩니다. 이 문장이 이 글의 전부이고, 아래는 그것이 실제 계약에서 어떤 모습으로 나타나는지를 항목별로 펼친 것입니다.

맡길지 말지를 아직 정하지 못하셨다면 AWS 운영을 맡긴다는 것의 범위를 먼저 보시고, 직접 운영과의 값 비교가 필요하시면 자체 운영과 위탁의 총비용이 그 계산을 따로 다룹니다. 이 글은 그 두 질문이 끝난 다음의 자리에 있습니다.

포함 항목을 세면 왜 값이 맞지 않는가

등급표를 비교할 때 가장 자연스러운 방법은 체크 표시를 세는 것입니다. 그런데 이 방법은 두 가지 이유로 어긋납니다.

첫째, 같은 이름의 항목이 서로 다른 깊이를 가리킵니다. “비용 관리”라는 한 줄이 어떤 수준에서는 청구 내역을 읽고 어디가 늘었는지 알려 드리는 일이고, 다른 수준에서는 확인된 항목을 실제로 손대어 줄이는 일입니다. 두 줄은 표에서 똑같이 한 칸을 차지하지만, 그 칸을 채우는 일의 양은 전혀 다릅니다.

둘째, 어떤 항목은 수준과 무관하게 늘 포함됩니다. 자동 감시가 그렇습니다. 세 수준의 표에 모두 같은 표시가 들어가는 항목은 비교에 아무것도 보태지 않는데, 항목 수를 세는 방식에서는 그것이 세 번 다 점수로 계산됩니다.

그래서 항목을 세면 얕은 계약과 깊은 계약이 비슷한 점수를 받고, 남는 판단 근거가 값밖에 없게 됩니다. 실제로 물어야 할 질문은 다릅니다 — 이 계약을 맺으면 우리 팀이 지금 하고 있는 일 중 무엇을 더 이상 하지 않아도 됩니까.

수준을 가르는 것은 책임의 이전입니다

운영 위탁의 수준을 아래에서 위로 놓으면, 늘어나는 것은 항목이 아니라 동사입니다.

• 감시와 보고까지 맡는 형태 — 확인하고, 감시하고, 검토하고, 권고합니다. 상태를 알려 드리는 데까지가 업체의 일이고, 무엇을 할지 정하고 실제로 손대는 일은 대체로 고객사에 남습니다. 여기에 가벼운 운영 작업이 함께 붙습니다.
• 변경 작업까지 맡는 형태 — 위의 동사에 운영과 개선이 더해집니다. 계약된 범위 안의 변경을 업체가 직접 수행하므로, 고객사에 남는 일은 무엇을 바꿀지 정하는 쪽으로 옮겨 갑니다.
• 운영과 개선을 더 넓게 맡는 형태 — 대응·설계·최적화·보안까지 동사가 늘어납니다. 중요한 서비스 환경에서 상태를 유지하는 것을 넘어 계속 나아지게 만드는 일까지 넘어옵니다.

동사가 하나 늘어난다는 것은 그 일을 하던 사람이 우리 쪽에서 업체 쪽으로 바뀐다는 뜻입니다. 그래서 상위 수준의 값어치는 “기능이 더 많다”가 아니라 고객의 운영 부담이 더 많이 넘어온다입니다. 저희 서비스 지면이 등급을 소개하는 문장도 같은 말을 합니다 — 등급은 기능이 아니라 책임으로 갈립니다.

다만 여기서 한 가지를 분명히 해 두셔야 합니다. 넘어가는 것은 수행 책임입니다. AWS 책임 공유 모델에서 고객이 지는 영역 자체는 어느 수준을 택해도 사라지지 않고, 위탁은 그 영역의 수행을 대신 맡을 뿐입니다. 수준을 올리는 일은 최종 책임을 넘기는 일이 아니라, 그 책임을 감당하기 위해 매일 해야 하는 일을 넘기는 일입니다.

감시는 수준을 가르지 않습니다

가장 자주 오해되는 항목이 감시입니다. 등급표에서 자동 모니터링 행을 보면 세 수준 모두 같은 표시가 들어 있습니다. 저희 비교표도 그렇습니다 — 가용성·성능·비용·보안 이벤트를 상시로 자동 감시하고 이상 시 알리는 일은 모든 수준에서 동일합니다.

이유는 단순합니다. 감시는 기계가 하는 일이라 수준에 따라 늘리거나 줄일 성질이 아닙니다. 임계치를 넘으면 알림이 나가는 구성은 한 번 세워 두면 시간대와 무관하게 계속 돌아갑니다.

수준이 갈리는 자리는 알림이 울린 다음입니다.

• 그 신호를 누가 읽고 어디까지 파고드는가
• 원인이 확인되면 누가 손을 대어 고치는가
• 같은 일이 반복되지 않도록 구성을 바꾸는 일까지 맡는가

이 세 줄이 수준의 실체입니다. 감시 항목이 같아 보인다고 두 계약이 같은 계약인 것은 아닙니다. 조직 안에서 이 신호를 누가 먼저 보고 누가 결정하는지를 나누는 문제는 AWS 장애 대응에 필요한 역할과 기록에서 따로 다룹니다.

여기에 하나를 덧붙여야 합니다. 야간·주말·공휴일에 엔지니어가 실제로 대응하는 것은 어느 수준에서도 기본 포함이 아닙니다. 감시와 알림은 시간대를 가리지 않지만, 사람이 로그를 읽고 판단하고 손대는 일은 계약된 지원 범위를 기준으로 이뤄집니다. 저희는 24시간 사람이 상주하는 관제를 직접 수행하지 않으며, 그 대응이 필요한 환경은 별도 계약으로 구성합니다. 그러니 야간 대응이 필요해서 수준을 한 칸 올리는 판단은 목적에 닿지 않습니다 — 그것은 다른 축의 항목입니다.

실제로 갈리는 축을 나란히 놓기

수준을 비교할 때 봐야 하는 축은 그리 많지 않습니다. 아래 표는 각 축에서 책임이 어디까지 넘어오는가의 방향만 정리한 것이고, 구체적인 포함 범위와 값은 AWS 관리 대행 서비스 범위와 AWS 운영 플랜과 요금에 나뉘어 적혀 있습니다.

표에서 실제로 정보를 주는 것은 위의 여섯 줄입니다. 아래 두 줄은 수준에 따라 달라지지 않는 항목이고, 그래서 비교에서 빼야 하는 항목입니다. 등급표를 받으셨을 때 이 두 줄이 상위 등급의 장점처럼 적혀 있다면, 그 표는 차이가 아닌 것을 차이로 보여 주고 있는 것입니다.

운영 범위에 들어오는 AWS 계정의 수도 수준에 따라 달라집니다. 계정을 여러 개 쓰고 있다면 이 축을 먼저 확인하셔야 하는데, 계정이 늘어나면 축마다의 작업량이 함께 늘어나기 때문입니다.

어느 수준에서도 넘어오지 않는 것

수준을 올리면 운영의 폭이 넓어집니다. 그러나 폭이 넓어진다고 프로젝트가 포함되지는 않습니다. 이 경계는 수준과 무관하게 그대로 있습니다.

성격으로 나누면 이렇습니다. 운영은 이미 돌아가는 환경의 상태를 유지하고 개선하는 일이고, 프로젝트는 없던 것을 만들거나 있던 것을 전면적으로 바꾸는 일입니다. 다른 곳에서 옮겨 오는 대규모 이전, 새 시스템을 통째로 세우는 구축, 애플리케이션 코드에 속한 개발, 손으로 만들어진 환경을 코드로 전면 재정의하는 작업은 모두 뒤쪽입니다. 침해가 실제로 일어났을 때의 사고 대응과 포렌식도 마찬가지로 별도 영역입니다.

이 구분을 미리 알아 두시면 실망을 줄일 수 있습니다. 위 항목이 필요해서 수준을 한 칸 올리면, 올린 만큼의 값은 치르는데 필요한 일은 여전히 별도 견적으로 다뤄집니다. 그런 일이 예정돼 있다면 운영 수준을 올리는 대신 그 일을 별도 항목으로 세우는 편이 맞고, 문제 하나를 끝내는 것이 목적이라면 원인 규명을 단건으로 다루는 방식이 순서상 앞설 때도 있습니다.

시간이 아니라 범위로 정하는 이유

등급을 고르실 때 “월에 몇 시간까지 해 주는가”를 먼저 물으시는 경우가 많습니다. 그 질문에 숫자로 답하지 않는 데는 이유가 있습니다.

환경마다 필요한 작업의 성격과 양이 크게 다릅니다. 어떤 달은 요청이 거의 없고 어떤 달은 구성을 여러 번 바꿔야 합니다. 여기에 일률적인 시간을 정해 두면 어느 한쪽에는 반드시 맞지 않습니다. 게다가 표에 박힌 숫자는 고객에게 **“여기까지만 해 준다”**로 읽힙니다. 실제로는 그 숫자 아래에서 여유롭게 처리되던 일도, 숫자가 있는 순간 분 단위를 다투는 대화로 바뀝니다.

그래서 저희는 요금표에 획일적인 시간 수치를 걸어 두지 않고, 플랜별로 어떤 작업을 맡는지를 범위로 정합니다. 무제한이라는 뜻은 아닙니다. 그 자리를 대신하는 것은 절차입니다 — 계약된 운영 범위를 넘는 작업이나 별도 프로젝트 규모의 변경은 사전에 범위와 비용을 안내하고 고객 승인 후 진행합니다. 모르는 사이에 비용이 늘어나지 않도록 하는 것이 이 절차의 목적입니다.

같은 이유로 세부 SLA와 장애 등급은 지면이 아니라 계약에서 확정합니다. 서비스의 중요도와 환경에 따라 달라지는 값이기 때문입니다. 공개된 초기 응답·확인 시간을 보실 때도 그것이 목표이지 해결시간의 보장이 아니라는 점을 함께 보셔야 합니다. 업체를 비교하실 때 이 구분이 문서에서 흐려져 있다면, 그 문장의 뜻을 먼저 확인해 두시는 편이 안전합니다.

지금 어느 수준이 맞는지 가르는 질문

수준은 회사 규모로 정해지지 않습니다. 아래 네 가지가 실질적인 판단 축입니다.

첫째, 지금 변경을 누가 하고 있습니까. 설정을 바꿔야 할 때 사내에서 처리할 사람이 있다면 감시와 보고까지 맡는 형태로 충분할 수 있습니다. 반대로 바꿔야 한다는 것은 알지만 손댈 사람이 없어 미뤄 두는 일이 쌓이고 있다면, 그 자리가 곧 변경 작업까지 넘겨야 하는 자리입니다.

둘째, 보고서를 받으면 무엇이 일어납니까. 개선 권고를 받고도 실행되지 않은 채 다음 보고서가 오는 상태가 반복된다면, 부족한 것은 정보가 아니라 실행입니다. 이 경우 아래 수준을 유지하는 것은 값을 치르고 정보를 사서 쌓아 두는 일이 됩니다.

셋째, 멈추면 무엇이 깎입니까. 서비스가 멈췄을 때 매출이나 고객 신뢰가 즉시 깎이는 환경일수록 장애 대응의 깊이가 중요해집니다. 초기 상태 확인까지만 계약해 둔 상태에서 원인 분석이 매번 별건이 된다면, 그 축을 기준으로 올리는 판단이 맞습니다.

넷째, 계정과 구성이 얼마나 넓습니까. 계정이 여럿이거나 네트워크 구성이 복잡하면 같은 작업도 확인해야 할 곳이 늘어납니다. 이때는 축마다의 깊이보다 폭이 먼저 문제가 됩니다.

네 축이 서로 다른 방향을 가리킬 때는 두 번째와 세 번째를 우선해 보십시오. 실행되지 않는 권고와 반복되는 장애는 시간이 지나도 저절로 해소되지 않고, 대개 더 큰 비용으로 돌아옵니다.

올려야 할 때는 무엇으로 알 수 있는가

처음 정한 수준이 계속 맞는 경우는 드뭅니다. 환경이 자라면 필요한 범위도 자라기 때문입니다. 다만 언제 올릴지는 숫자로 정해 두기 어렵고, 실제로는 다음과 같은 신호로 드러납니다.

• 범위 밖이라 별도로 다뤄지는 요청이 특정 유형에서 반복된다
• 요청을 보내고 답을 기다리는 시간이 업무의 병목으로 느껴지기 시작한다
• 보고서에서 같은 권고가 여러 번 반복되는데 실행은 미뤄져 있다
• 장애가 났을 때 원인 분석을 매번 별건으로 요청하고 있다
• 계정이나 서비스가 늘어 확인해야 할 곳이 처음 계약할 때보다 넓어졌다

이 신호들은 모두 기록으로 확인할 수 있는 것이라는 공통점이 있습니다. 그래서 수준을 올릴지 정하실 때는 감이 아니라 지난 몇 달의 요청 이력과 보고서를 펴 놓고 보시는 편이 정확합니다. 반복해서 범위 밖으로 나가는 항목이 보이면, 그 항목이 곧 넓혀야 할 범위입니다. 맡긴 뒤에도 상태와 이력을 직접 보고 싶으시면 운영 현황 대시보드처럼 화면으로 확인하는 구성을 함께 두실 수 있습니다.

반대의 경우도 있습니다. 넓게 계약해 두었는데 몇 달째 실제로 쓰이는 범위가 좁다면, 그것도 기록에 드러납니다. 수준은 한 방향으로만 움직이는 값이 아닙니다.

다음 단계

어느 수준이 맞는지는 결국 지금 환경을 봐야 정해집니다. AWS 무료 점검은 계정 접근 권한을 먼저 요구하지 않고 짧은 상담으로 지금 구조에서 무엇부터 봐야 하는지를 정리해 드립니다. 정리된 내용은 이어서 맡기지 않으셔도 그대로 가져가실 수 있습니다.

이미 다른 곳에 맡기고 있고 범위를 다시 보려는 단계라면, 먼저 이어받기 진단으로 넘겨받을 것이 손에 있는지 확인해 보십시오. 이 진단은 AWS 계정 권한 없이도 답할 수 있습니다.

각 축의 구체적인 범위를 항목으로 확인하고 싶으시면 AWS 관리 대행 서비스 범위의 비교표를, 값의 기준은 AWS 운영 플랜과 요금을 보십시오. 운영 상태가 실제로 어떤 화면으로 보이는지 먼저 눌러 보고 싶으시면 아래 데모를 열어 보시고, 우리 환경에서는 어느 수준이 맞는지 함께 보고 싶으시면 상담 신청으로 연락 주십시오.

참고 자료

• AWS 책임 공유 모델
• AWS Well-Architected — 운영 우수성 원칙
• AWS Support 플랜 비교
• AWS IAM — 서드파티에 계정 접근 권한 위임