AWS MSP란 무엇이고, 언제 맡기는 것이 맞습니까

제안서나 견적서에서 “MSP”라는 단어를 처음 보면 대개 두 가지가 동시에 궁금해집니다. 그 단어가 무엇을 뜻하는지, 그리고 계약하면 실제로 무엇이 달라지는지입니다. 단어의 뜻은 검색으로 금방 풀리지만, 무엇이 달라지는가는 대개 풀리지 않은 채 견적 비교로 넘어갑니다.

이 글은 용어 설명보다 계약의 경계선을 읽는 법에 무게를 둡니다. 업체를 고를 때 실제로 봐야 하는 것은 규모나 인원이 아니라, 무엇까지 맡는다고 적혀 있는가이기 때문입니다.

AWS MSP란 무엇인가

AWS MSP(Managed Service Provider)는 고객사 명의의 AWS 환경을 대신 감시하고 점검하며 운영해 주는 계약입니다. 서버를 빌려주는 계약이 아니라, 이미 쓰고 있는 환경을 맡아서 상태를 유지하는 계약입니다.

맡는 범위는 크게 두 층으로 나뉩니다.

• 감시와 보고까지 — 지표를 지속적으로 확인하고, 이상이 보이면 알리고, 정기적으로 상태를 정리해 보고합니다. 실제 변경은 고객사가 합니다.
• 변경 작업까지 — 감시와 보고에 더해 설정 변경, 패치, 구성 조정 같은 실제 손대는 일을 계약된 범위 안에서 수행합니다.

같은 “MSP”라는 이름으로 두 층이 모두 팔리기 때문에, 이름만 보고 비교하면 서로 다른 상품을 나란히 놓고 값만 견주게 됩니다.

한 가지 덧붙이면, AWS에는 파트너를 대상으로 한 AWS Managed Services Provider(MSP) Program이라는 별도의 심사 체계가 존재합니다. 다만 이 프로그램의 통과 여부와, 국내에서 통용되는 “MSP 업체”라는 호칭은 같은 것이 아닙니다. 업체가 어떤 파트너 자격을 갖고 있는지는 자격 이름 그대로 물어보는 편이 정확합니다.

SI와 MSP는 어디서 갈리는가

SI(시스템을 만들어 넘기는 구축 계약)는 끝나는 계약이고 MSP는 이어지는 계약입니다. 이 차이가 계약서의 거의 모든 항목을 다르게 만듭니다.

문제가 자주 생기는 지점은 두 계약 사이의 빈틈입니다. 구축 계약이 끝나면 시스템은 남고 그 계약의 관여도 함께 끝납니다. 그 시점에 운영을 이어받을 주체가 정해져 있지 않으면, 환경은 그대로인데 그것을 설명할 수 있는 사람만 사라진 상태가 됩니다. 몇 달 뒤 비용이 오르거나 장애가 반복될 때 원인을 추적할 출발점이 없는 이유가 대개 여기에 있습니다.

MSP 계약에 보통 포함되는 것

일반적인 AWS 운영 위탁 계약에는 감시·점검·보고·문의 대응이 공통으로 들어갑니다. 업체마다 이름은 다르지만 성격은 대체로 비슷합니다.

• 상시 감시와 알림 — 가용성·성능·비용·보안 이벤트를 자동으로 확인하고, 임계치를 넘으면 정해진 방식으로 알립니다.
• 정기 점검과 보고 — 구성 상태, 백업 동작 여부, 권한 설정, 사용량 추이를 주기적으로 확인해 정리합니다.
• 비용 확인 — 청구 내역을 읽고 어느 항목이 늘었는지 설명합니다. 절감 실행까지 포함되는지는 계약마다 다릅니다.
• 계약 범위 안의 변경 작업 — 설정 변경, 패치 적용, 자원 조정 등입니다. 무엇이 “범위 안”인지가 계약서에서 가장 자주 모호한 항목입니다.
• 문의 창구 — 질문을 접수하고 답하는 경로가 정해집니다.

여기서 함께 정리해 둘 것이 AWS 자체 지원과의 관계입니다. AWS는 자체 Support 플랜을 별도로 판매하며, 이는 운영 위탁 업체와 계약하는 것과 다른 별개의 비용입니다. 또한 AWS와 고객 사이의 책임 경계는 AWS 책임 공유 모델로 정의돼 있고, 운영 위탁은 그중 고객 책임 영역을 대신 수행하는 것입니다. AWS가 책임지는 영역까지 업체가 보장해 준다는 뜻이 아닙니다. 경계를 대략 그려 보면 하드웨어와 물리 시설, 네트워크 같은 기반은 AWS 쪽이고, 서버의 운영체제 패치와 권한 설정, 데이터 관리는 고객 쪽입니다. 운영 위탁이 대신 맡는 것은 뒤쪽입니다.

포함되지 않는 것 — 계약 전에 확인할 다섯 항목

운영 위탁 계약에서 기본 범위 밖으로 두는 항목은 대체로 정해져 있습니다. 다음 다섯 가지는 별도 견적이나 별도 계약으로 다루는 것이 일반적입니다.

1. 대규모 마이그레이션 — 온프레미스나 타 클라우드에서 옮겨 오는 일, 대형 데이터베이스 전환은 운영이 아니라 프로젝트입니다.
2. 인프라 코드(IaC) 대전환 — 손으로 만들어진 환경을 코드로 전면 재정의하는 작업은 설계 과제이지 유지 과제가 아닙니다.
3. 애플리케이션 코드 개발 — 서비스 기능 개발, 버그 수정, 성능 튜닝 중 코드에 속한 부분은 개발 계약의 영역입니다.
4. 야간·주말·공휴일의 사람 대응 — 자동 감시는 계속되지만 사람이 즉시 손대는 것은 별도 구성 항목입니다.
5. 분량 제한 없는 변경 작업 — 기본 제공 범위와 초과 시 처리 방식이 어떻게 적혀 있는지가 핵심입니다. “무제한”으로 읽히는 문구가 있다면 그 문구의 정의를 문서로 받아 두셔야 합니다.

애플리케이션 코드를 두고 오해가 자주 생깁니다. 애플리케이션이 느려졌을 때 원인이 인프라 구성에 있는지 코드에 있는지는 미리 알 수 없고, 두 영역의 담당이 갈려 있으면 원인 규명 자체가 지연됩니다. 반복되는 장애의 원인을 먼저 확인하고 싶다면 상시 계약보다 장애 원인 규명처럼 단건으로 다루는 방식이 순서상 앞설 때가 있습니다.

“24시간 모니터링”은 “24시간 대응”이 아닙니다

자동 모니터링이 24시간이라는 말과 엔지니어가 24시간 대기한다는 말은 서로 다른 서비스를 가리킵니다. 이 두 문장을 하나로 읽으면 계약 후 첫 야간 장애에서 인식 차이가 드러납니다.

구분해서 보면 세 층입니다.

• 감시 — 기계가 지표를 계속 확인합니다. 시간 제약이 없습니다.
• 알림 — 임계치를 넘으면 정해진 경로로 통지가 나갑니다. 역시 시간 제약이 없습니다.
• 분석과 조치 — 사람이 로그를 읽고 원인을 판단하고 손을 댑니다. 여기에 지원시간이 걸립니다.

감시와 알림은 자동화할 수 있지만 분석과 조치는 사람의 시간입니다. 그래서 “24/7 모니터링”이라는 문구는 사실일 수 있으면서 동시에 야간 조치를 전혀 보장하지 않을 수 있습니다. 거짓말이 아니라 다른 층을 말하고 있는 것입니다.

계약서에서 확인할 것은 두 문장이 나뉘어 적혀 있는가입니다. 감시 대상과 알림 방식이 한 항목으로, 사람이 분석하고 조치하는 시간대와 범위가 다른 항목으로 적혀 있어야 합니다. 한 문장에 뭉쳐 있다면 그 문장을 나눠 달라고 요청하십시오. 빌드업웍스의 지원시간과 대응 범위는 AWS 관리 대행 서비스 범위에 나눠 적혀 있습니다.

계정과 데이터는 누구 것인가

AWS 운영을 위탁하더라도 계정과 데이터의 소유는 고객사에 있는 것이 원칙입니다. 업체는 소유권을 넘겨받는 것이 아니라 접근 권한을 위임받습니다.

기술적으로는 교차 계정 역할 위임이 일반적인 방식입니다. 고객사 계정에 업체가 맡을 역할을 만들고 필요한 권한만 붙여 두는 구조입니다. 계약이 끝나면 그 역할을 지우는 것으로 접근이 끊깁니다. 업체 직원 개인 계정을 만들어 주는 방식보다 회수가 명확합니다.

다만 실제로는 업체 조직 아래에 계정을 개설해 제공하는 형태도 있습니다. 결제나 할인 구조 때문에 그렇게 구성하는 경우인데, 여기서 말하는 조직은 AWS가 여러 계정을 하나로 묶어 관리하고 결제하는 단위입니다. 이때는 계약 종료 시 계정을 조직에서 분리하는 절차가 필요하고, 그 계정이 홀로 운영될 수 있는 상태여야 분리가 진행됩니다. 예를 들어 계정 자체에 결제 수단과 연락처가 등록돼 있어야 합니다. 어느 형태인지는 계약 전에 물어보셔야 합니다.

계약 전에 확인할 항목은 아래 「업체를 고를 때 계약서에서 확인할 것」에 함께 정리했습니다. 그중 가장 자주 빠지는 것이 종료 시 넘겨받는 산출물이고, 빠졌다는 사실은 계약을 끝낼 때가 되어서야 드러납니다.

직접 운영과 위탁, 무엇으로 판단하는가

판단은 회사 규모가 아니라 운영에 필요한 지식의 폭과 사용 빈도로 하는 편이 정확합니다. 필요한 기술의 폭이 넓고 사용 빈도가 낮으면 위탁이, 특정 영역을 매일 깊게 다뤄야 하면 채용이 대체로 맞습니다. 아래 다섯 가지 축은 그 판단을 나눠 본 것이고, 축들이 서로 다른 방향을 가리킬 때는 이 폭과 빈도의 기준으로 돌아오시면 됩니다.

• 담당자 유무 — 지금 AWS 환경의 구성과 비용을 설명할 수 있는 사람이 사내에 있습니까. 없는 상태가 몇 달째 이어지고 있다면 그 자체가 위험입니다.
• 변경 빈도 — 배포와 구성 변경이 잦다면 내부에 손이 필요하고, 만들어 둔 뒤 거의 바뀌지 않는다면 위탁이 맞습니다.
• 장애 영향도 — 멈췄을 때 매출이나 고객 신뢰가 즉시 깎이는 환경일수록 감시와 대응을 계약으로 확정해 둘 값어치가 커집니다.
• 비용 규모 — 청구 금액이 커질수록 잘못된 구성이 만드는 손실도 함께 커집니다. 청구서가 왜 올랐는지 설명할 사람이 없다면 AWS 비용이 갑자기 오르는 원인을 먼저 확인해 보시는 편이 좋습니다. 운영 위탁의 비용 기준은 AWS 운영 플랜과 요금에 정리돼 있습니다.
• 지속 기간 — 몇 달 뒤 구조를 크게 바꿀 예정이라면 상시 운영 계약보다 구축을 먼저 정리하는 순서가 맞습니다.

채용과 비교할 때 핵심은 폭과 깊이입니다. AWS 운영은 비용·네트워크·보안·데이터베이스가 각각 다른 지식을 요구하는데, 중소 규모 환경에서 그 지식들을 매일 쓰는 일은 드뭅니다. 낮은 빈도로 넓은 지식이 필요한 구조는 위탁이 잘 맞는 형태입니다. 반대로 특정 영역을 매일 깊게 다뤄야 한다면 그 영역은 내부에 두는 편이 낫습니다. 다만 넓은 영역을 한 사람에게 전부 맡기는 구성이라면, 그 사람이 퇴사할 때 환경을 설명할 수 있는 지식도 함께 사라진다는 점을 같이 보셔야 합니다.

아직 맡기지 않아도 되는 경우

운영 위탁이 지금 필요하지 않은 상태도 분명히 있습니다. 필요하지 않은데 계약하면 매달 나가는 비용에 비해 실제로 일어나는 일이 적어, 몇 달 뒤 해지 검토로 돌아옵니다.

• 환경이 작고 거의 바뀌지 않을 때 — 서버 몇 대가 안정적으로 돌고 변경 요청이 분기에 한 번 수준이라면, 정기 점검을 단건으로 받는 편이 더 맞을 수 있습니다.
• 사내에 설명할 수 있는 사람이 이미 있을 때 — 그 사람이 판단할 수 있다면 필요한 것은 상시 계약이 아니라 어려운 국면에서만 함께 볼 상대일 수 있습니다.
• 지금 필요한 것이 운영이 아니라 단건 해결일 때 — 특정 장애를 끝내는 것이 목적이라면 원인 규명을 단건으로 다루는 방식을 먼저 보고, 운영 계약은 그 결과를 보고 정하는 순서가 낫습니다.
• 곧 구조를 크게 바꿀 예정일 때 — 재구축이 예정돼 있다면 지금 구조를 유지하는 계약에 값을 치를 이유가 크지 않습니다.

업체를 고를 때 계약서에서 확인할 것

업체 비교는 소개 자료보다 계약서와 서비스 명세를 나란히 놓고 하는 편이 정확합니다. 명세는 업체마다 확연히 다르고, 그 차이가 계약 후의 인식 차이로 이어집니다.

물어볼 항목입니다.

• 무엇을 감시합니까. 감시 대상 지표와 임계치가 문서에 적혀 있습니까
• 이상이 확인되면 누구에게 어떤 방식으로 알립니까
• 사람이 실제로 분석하고 조치하는 시간대는 언제입니까. 그 밖의 시간은 어떻게 처리됩니까
• 기본 제공되는 변경 작업의 범위는 무엇이고, 그것을 넘으면 어떻게 처리됩니까
• 계정 명의는 고객사입니까, 업체 조직 아래입니까. 업체에 부여되는 권한의 범위가 문서에 적혀 있습니까
• 보고는 어떤 주기로 어떤 형식으로 받습니까
• 계약 종료 시 권한 회수와 계정 이관 절차가 정해져 있습니까
• 계약을 끝낼 때 무엇을 넘겨받습니까. 구성 문서·계정 정보·운영 이력이 목록으로 명시돼 있습니까
• 일부 업무를 다른 회사에 재위탁합니까. 한다면 어느 부분입니까

답이 “상황에 따라 다릅니다”로 돌아오는 항목이 많다면, 그 항목들이 곧 협의로 정해지는 부분이라는 뜻입니다. 계약마다 달라지는 항목이 실제로 있기 때문에 그 답이 틀린 것은 아니지만, 협의로 정해지는 것일수록 우리 환경 기준으로는 어떻게 적히는지 문서로 받아 두셔야 합니다.

참고로 빌드업웍스는 AWS Select Partner입니다. AWS Managed Services Provider(MSP) Program과는 별개의 자격이며, 업체를 비교하실 때도 자격의 이름과 종류를 그대로 확인하시길 권합니다.

다음 단계

맡길지 말지 아직 정하지 못한 단계라면, 현재 환경에서 무엇부터 봐야 하는지 확인하는 것이 먼저입니다. AWS 무료 점검은 계정 접근 권한을 먼저 요구하지 않고 짧은 상담으로 우선순위를 정리해 드립니다. 정리된 내용은 이어서 맡기지 않으셔도 그대로 가져가실 수 있습니다.

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

참고 자료

• AWS 책임 공유 모델
• AWS Managed Services Provider (MSP) Program
• AWS Support 플랜 비교
• AWS IAM — 서드파티에 계정 접근 권한 위임
• AWS Organizations — 조직에서 계정 제거하기