AWS를 직접 운영하면, 실제로 무엇이 드는가

AWS 운영을 직접 할지 맡길지 정할 때, 비교는 대개 한 줄에서 시작됩니다. 매달 나가는 위탁료와 담당자 한 사람의 급여를 나란히 놓고 어느 쪽이 싼지를 보는 것입니다. 이 계산은 간단해서 빠르게 결론이 나지만, 두 숫자가 같은 성격의 값이 아니라는 점이 계산 밖에 남습니다.

이 글은 어느 쪽이 옳다고 말하기 위한 것이 아니라, 두 방식의 대장(帳簿)을 같은 칸에 정리해 두기 위한 것입니다. 자체 운영에는 청구서에 찍히지 않는 비용이 여럿 있고, 위탁에는 요금 외에 책임이 어디까지 넘어가는가라는 축이 하나 더 있습니다. 그 두 가지를 표에 올려야 값이 맞습니다.

왜 “월 위탁료 대 급여”로 비교하면 어긋나는가

위탁료와 급여를 직접 견주는 계산이 어긋나는 이유는, 두 숫자가 담고 있는 것이 다르기 때문입니다.

월 위탁료는 이미 여러 항목이 하나로 묶인 값입니다. 감시, 점검, 보고, 문의 대응, 그리고 계약 범위 안의 변경 작업까지가 그 안에 들어 있습니다. 반면 담당자 한 사람의 급여는 그 사람의 인건비 하나만을 가리킵니다. 채용에 든 비용, 교육 기간의 공백, 그 사람이 나갔을 때 사라지는 지식은 급여 숫자 어디에도 들어 있지 않습니다.

그래서 이 둘을 그대로 견주면, 위탁 쪽에는 이미 포함된 비용이 자체 운영 쪽에서는 계산에서 빠진 채로 비교가 됩니다. 위탁이 비싸 보이는 것은 사실 위탁의 값이 한 줄에 다 드러나 있고 자체 운영의 값은 여러 곳에 흩어져 있기 때문인 경우가 많습니다. 비교를 맞추려면, 자체 운영 쪽에 흩어져 있는 값을 먼저 한자리에 모아야 합니다.

자체 운영의 비용은 무엇으로 이뤄지는가

자체 운영의 총비용은 급여를 포함해 대략 네 가지 항목으로 이뤄집니다. 여기서 특정 금액을 말하려는 것이 아니라, 계산에 올려야 하는 항목이 무엇인지를 짚으려는 것입니다.

• 인건비 — 담당자의 급여와 그에 따르는 부대비용입니다. 이것은 대체로 잘 계산됩니다.
• 채용 비용 — 사람을 찾고, 검증하고, 합류시키기까지의 시간과 비용입니다. 적합한 사람을 찾는 데 걸리는 기간 동안 그 일은 누군가 대신 하거나 미뤄집니다.
• 공백 비용 — 담당자가 없는 기간, 또는 새 담당자가 환경을 파악하는 기간에 운영이 얇아지는 데서 오는 비용입니다. 이 기간에 생긴 문제는 나중에 더 큰 비용으로 돌아오기도 합니다.
• 지식 소실 위험 — 운영의 지식이 문서가 아니라 사람에게만 남아 있을 때, 그 사람이 떠나면 함께 사라지는 값입니다. 이것은 평소에는 비용으로 보이지 않다가, 담당자가 바뀌는 시점에 한꺼번에 드러납니다.

이 중 뒤의 세 가지는 청구서에도 급여 명세에도 나타나지 않기 때문에, 계산에서 조용히 빠지기 쉽습니다. 그런데 실제로 자체 운영을 어렵게 만드는 것은 대개 급여가 아니라 이 세 항목입니다.

한 가지 더 계산에 올려야 하는 것이 있습니다. 자체 운영을 택했다는 것은, 비용이 왜 늘었는지를 스스로 읽을 수 있는 역량도 안에 두겠다는 뜻입니다. AWS의 청구를 항목별로 들여다보려면 AWS Cost Explorer 같은 비용 관측 도구를 다룰 사람이 필요하고, 무엇을 봐야 하는지에 대한 감각도 필요합니다. 어떤 항목을 확인해야 하는지는 AWS 비용 점검 항목에 정리해 두었는데, 이 역량을 사내에 두는 일 자체가 자체 운영의 비용에 포함됩니다.

위탁의 비용은 무엇으로 이뤄지는가

위탁의 비용은 자체 운영보다 구조가 단순합니다. 크게 두 축입니다.

첫째는 월 요금입니다. 감시·점검·보고·문의 대응과 계약 범위 안의 변경 작업이 여기에 묶여 있습니다. 무엇이 이 범위에 들어가는지는 업체마다 다르므로, 요금 숫자보다 그 숫자가 무엇을 포함하는지가 실제 비교 대상입니다. 위탁이 무엇을 맡는 계약인지에 대한 설명은 AWS 운영을 맡긴다는 것의 범위에 따로 정리해 두었습니다.

둘째는 범위 밖의 별도 견적입니다. 대규모 이전 작업, 애플리케이션 코드에 속한 개발, 야간·주말·공휴일의 사람 대응 같은 항목은 대체로 기본 범위 밖에 있고, 필요할 때 별도로 다뤄집니다. 위탁을 검토하실 때 확인해야 할 것은 월 요금 한 줄이 아니라, 무엇이 기본에 들어 있고 무엇이 별도인지의 경계입니다.

이 글에서는 금액과 플랜명을 다루지 않습니다. 환경마다 달라지고, 지면과 문서가 갈라지면 잘못된 값이 남기 때문입니다. 빌드업웍스의 AWS 관리 대행 서비스 범위에 무엇을 감시하고 어디까지 대응하는지가 나뉘어 적혀 있고, 요금 기준은 AWS 운영 플랜과 요금에서 확인하실 수 있습니다.

두 방식을 같은 표에 놓기

두 방식을 제대로 비교하려면, 값이 아니라 비용 항목과 책임의 위치를 정렬해야 합니다. 아래 표는 어느 쪽이 싸다는 결론이 아니라, 같은 질문을 두 방식에 던졌을 때 답이 어디에 있는지를 정리한 것입니다.

표의 마지막 두 줄이 이 비교의 핵심입니다. 수행 책임은 방식에 따라 옮겨 가지만, 최종 책임은 어느 쪽을 택해도 고객사에 남습니다. 다음 절에서 그 이유를 봅니다.

책임은 어디서 갈리는가

비용 다음으로 봐야 할 축은 책임입니다. 그리고 책임에는 성격이 다른 두 가지가 있습니다. 수행 책임과 최종 책임입니다.

수행 책임은 실제로 손을 대어 작업하는 책임입니다. 이것은 위탁으로 옮길 수 있습니다. 감시하고, 점검하고, 계약 범위 안의 변경을 실행하는 일을 업체가 대신 맡는 것이 위탁의 본질입니다. 기술적으로는 고객사 계정에 업체가 맡을 역할을 만들어 권한을 위임하는 방식이 일반적이며, 이 위임의 범위가 곧 수행 책임의 범위입니다.

최종 책임은 다릅니다. 서비스가 멈췄을 때 고객과 시장에 대해 책임지는 주체는 여전히 고객사입니다. AWS와 고객 사이의 경계는 AWS 책임 공유 모델로 정의돼 있는데, 이 모델에서 고객이 지는 영역은 운영을 위탁해도 사라지지 않습니다. 위탁은 그 영역의 수행을 대신 맡는 것이지, 영역 자체를 업체에 넘기는 것이 아니기 때문입니다. 경계를 대략 그려 보면, 하드웨어와 물리 시설 같은 기반은 AWS 쪽이고, 운영체제 패치·권한 설정·데이터 관리는 고객 쪽입니다. 위탁이 대신 맡는 것은 뒤쪽의 수행이며, 그 결과에 대한 최종 책임은 그대로 고객사에 있습니다.

그래서 계약서에서 확인해야 할 것은 업체가 책임을 다 진다는 문구가 아닙니다. 어떤 작업을 어느 범위까지 수행하는지, 그리고 그 범위 밖의 일이 생겼을 때 누가 무엇을 하는지가 나뉘어 적혀 있는지입니다. 책임을 다 넘긴다고 읽히는 문장이 있다면, 그 문장의 실제 뜻을 문서로 받아 두시는 편이 안전합니다.

담당자 한 명 구조의 숨은 값

자체 운영을 택할 때 가장 자주 지나치는 비용이 담당자 한 명 구조의 위험입니다. 이것은 평소에는 비용으로 보이지 않다가 사람이 바뀌는 시점에 한꺼번에 드러납니다.

AWS 운영은 비용, 네트워크, 보안, 데이터베이스가 각각 다른 지식을 요구합니다. 중소 규모 환경에서 이 지식들을 매일 쓰는 일은 드물지만, 필요할 때는 반드시 있어야 합니다. 그래서 한 사람에게 넓은 영역을 전부 맡기는 구성이 흔히 나옵니다. 이 구성은 평시에는 문제없이 돌아갑니다.

위험은 그 사람이 자리를 비울 때 나타납니다. 환경은 그대로인데 왜 그렇게 설정됐는지 아는 사람만 사라진 상태가 되고, 남은 팀은 문서 없이 설정을 되짚어야 합니다. 몇 달 뒤 비용이 오르거나 장애가 반복될 때 원인을 추적할 출발점이 없는 이유가 대개 여기에 있습니다.

그래서 한 명 구조를 택하더라도, 지식이 사람이 아니라 문서와 이력으로 남는가를 함께 보셔야 합니다. 구성이 문서로 남아 있고 변경 이력이 쌓여 있으면 담당자가 바뀌어도 이관이 짧아지지만, 그렇지 않으면 이관 자체가 하나의 프로젝트가 됩니다. 인수인계 시점에 무엇을 넘겨받아야 하는지는 AWS 운영 업체를 바꾸기 전 인수인계 항목에 따로 정리해 두었습니다.

섞어 쓰는 구성은 언제 맞는가

자체 운영과 위탁은 둘 중 하나를 고르는 문제로만 놓이기 쉽지만, 실제로는 섞어 쓰는 구성이 흔합니다. 사내에는 서비스와 배포 흐름을 아는 담당자를 두고, 상시로 쓰지 않는 넓은 판단만 외부와 함께하는 형태입니다.

이 구성이 맞는 경우는 대체로 이렇습니다. 매일 손대야 하는 영역이 분명히 있어서 그 부분은 내부에 두어야 하지만, 비용이나 보안처럼 자주 쓰지는 않으면서 넓은 지식이 필요한 영역이 함께 있는 경우입니다. 넓은 폭을 한 사람에게 전부 지우기보다, 자주 쓰는 부분은 내부에 두고 드물게 필요한 깊은 판단만 밖에서 가져오는 편이 값에 맞습니다.

이 구성을 택할 때 미리 정해 두어야 하는 것은 역할이 아니라 경계입니다. 어떤 변경을 사내에서 처리하고 어떤 변경을 요청으로 넘길지, 장애가 났을 때 누가 먼저 확인하고 언제 넘길지를 계약 전에 문서로 적어 두지 않으면, 양쪽 모두 상대가 보고 있다고 생각하는 구간이 생깁니다. 그 구간은 평소에는 드러나지 않다가 문제가 났을 때 정확히 그 자리에서 드러납니다.

계정을 업체 조직 아래에 두는 형태로 섞어 쓴다면, 계약이 끝날 때 계정을 조직에서 분리하는 절차가 별도로 필요하다는 점도 경계에 함께 적어 두시는 편이 좋습니다.

자체 운영이 오히려 맞는 경우

위탁이 늘 답은 아닙니다. 자체 운영이 더 맞는 상황도 분명히 있고, 그 경우 위탁은 실제로 일어나는 일에 비해 비용이 큰 선택이 됩니다.

• 특정 영역을 매일 깊게 다뤄야 할 때 — 배포와 구성 변경이 잦고 그 일이 서비스의 핵심에 붙어 있다면, 그 지식은 내부에 있는 편이 빠르고 정확합니다. 자주 쓰는 지식을 밖에 두면 매번 요청과 대기가 끼어듭니다.
• 이미 설명할 수 있는 사람이 사내에 있을 때 — 환경을 판단할 수 있는 담당자가 있다면 필요한 것은 상시 계약이 아니라 어려운 국면에서만 함께 볼 상대일 수 있습니다. 이때는 자체 운영을 기본으로 두고 부분만 밖과 함께하는 편이 맞습니다.
• 환경이 작고 거의 바뀌지 않을 때 — 서버 몇 대가 안정적으로 돌고 변경이 드물다면, 상시 위탁보다 정기 점검을 단건으로 받는 편이 값에 맞을 수 있습니다.
• 지식이 문서로 잘 남아 있을 때 — 구성이 문서화돼 있고 변경 이력이 쌓이는 팀이라면, 담당자 한 명 구조의 위험이 그만큼 줄어듭니다. 이 경우 자체 운영의 숨은 비용 중 가장 큰 항목이 이미 관리되고 있는 셈입니다.

이 절이 있어야 이 글이 정보 콘텐츠입니다. 어느 쪽이 맞는지는 회사 규모가 아니라 필요한 지식의 폭과 그 지식을 쓰는 빈도로 갈리며, 그 답은 환경마다 다릅니다.

다음 단계

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

비용 쪽부터 확인하고 싶으시면 AWS 비용·구조 1분 자가 진단으로 지금 청구가 어디서 늘고 있는지를 먼저 가늠해 보실 수 있습니다. 위탁 쪽으로 방향이 기울었다면 AWS 관리 대행 서비스 범위에서 감시 항목과 대응 범위가 어떻게 나뉘어 적혀 있는지 확인해 보시고, 운영 지표가 실제로 어떤 화면으로 보이는지 먼저 눌러 보고 싶으시면 아래 데모를 열어 보십시오. 우리 환경에 맞는 구성이 궁금하시면 상담 신청으로 연락 주십시오.

참고 자료

• AWS 책임 공유 모델
• AWS IAM — 서드파티에 계정 접근 권한 위임
• AWS Organizations — 조직에서 계정 제거하기
• AWS Cost Explorer란 무엇인가