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

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

비교 기준을 바꿀 필요가 있습니다. 수준은 기능이 몇 개 포함되는가로 나뉘지 않습니다. 책임이 어디로 이전되는가로 나뉩니다. 이 글은 그 기준이 실제 계약에서 어떤 모습으로 나타나는지를 항목별로 정리합니다.

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

포함 항목을 세면 왜 비교가 맞지 않는가

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

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

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

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

수준을 구분하는 것은 책임의 이전입니다

운영 위탁의 수준을 낮은 수준부터 높은 수준 순으로 놓으면, 늘어나는 것은 항목이 아니라 동사입니다.

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

동사가 하나 늘어난다는 것은 그 일을 수행하는 주체가 고객사에서 업체로 바뀐다는 뜻입니다. 그래서 상위 수준의 가치는 “기능이 더 많다”가 아니라 고객의 운영 부담이 더 많이 넘어온다입니다. 빌드업웍스의 서비스 페이지도 등급을 같은 기준으로 소개합니다 — 등급은 기능이 아니라 책임으로 구분됩니다.

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

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

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

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

수준에 따라 달라지는 것은 알림이 발생한 다음입니다.

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

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

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

실제로 달라지는 항목을 나란히 놓기

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

표에서 실제로 정보를 주는 것은 변경 작업부터 인프라 코드까지 여섯 줄입니다. 자동 감시와 야간·주말·공휴일 대응 두 줄은 수준에 따라 달라지지 않는 항목이고, 그래서 비교에서 빼야 하는 항목입니다. 등급표를 받으셨을 때 이 두 줄이 상위 등급의 장점처럼 적혀 있다면, 그 표는 차이가 아닌 것을 차이로 보여 주고 있는 것입니다.

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

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

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

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

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

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

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

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

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

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

지금 어느 수준이 맞는지 판단하는 질문

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

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

둘째, 보고서를 받으면 무엇이 일어납니까. 개선 권고를 받고도 실행되지 않은 채 다음 보고서가 오는 상태가 반복된다면, 부족한 것은 정보가 아니라 실행입니다. 이 경우 낮은 수준을 유지하는 것은 비용을 들여 실행되지 않는 권고만 축적하는 일이 됩니다.

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

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

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

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

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

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

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

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

다음 단계

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

이미 다른 업체에 맡기고 있고 범위를 다시 보려는 단계라면, 먼저 이어받기 진단으로 넘겨받을 자료를 확보했는지 확인하실 수 있습니다. 이 진단은 AWS 계정 권한 없이도 답할 수 있습니다.

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

참고 자료

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