AWS 운영을 넘겨받기 전, 무엇을 확인해야 하는가

AWS 운영을 다른 곳에 맡기고 있다가 주체를 바꾸거나 내부로 들이기로 하면, 대개 “계정 정보만 넘겨받으면 되겠지”라는 생각에서 출발합니다. 실제로는 계정 접근은 넘겨받아야 할 것의 목록에서 한 줄에 불과하고, 나머지 줄들이 빠져 있으면 그 사실은 이관을 시작한 뒤에야 하나씩 드러납니다.

이 글은 업체를 바꾸라고 권하는 글이 아닙니다. 곧 주체를 바꿀지 검토 중인 사람이 인수인계 때 무엇을 요구할 수 있는지를 목록으로 정리한 글입니다. 전환 자체를 상의하고 싶으시면 AWS 운영 전환 — 환경은 그대로 두고 운영 주체만 이어받기 쪽이 그 논의를 다룹니다. 여기서는 어느 쪽으로 결정하든 먼저 확인해 두어야 할 항목만 다룹니다.

인수인계에서 가장 늦게 드러나는 것

인수인계는 계약이 끝날 때가 되어서야 빠진 것이 드러나는 대표적인 구간입니다. 운영이 정상으로 돌아가는 동안에는 계정 안에 무엇이 들어 있고 왜 그렇게 설정됐는지가 문제되지 않다가, 주체를 바꾸려는 순간 그 정보들이 한꺼번에 필요해지기 때문입니다.

특히 두 가지 정보가 늦게 발견됩니다. 하나는 구성이 왜 그렇게 되어 있는가입니다. 현재 상태는 조회해서 알 수 있지만, 그 설정이 어떤 판단으로 만들어졌는지는 사람의 머릿속에만 있는 경우가 많습니다. 그 사람이 자리를 떠나면 같은 정보를 되찾을 곳이 없습니다. 다른 하나는 종료 시 넘겨받을 산출물의 목록입니다. 계약서에 종료 절차가 적혀 있지 않으면, 넘겨받는 쪽은 무엇을 요구할 권리가 있는지조차 알지 못한 채 이관을 시작하게 됩니다.

그래서 순서를 뒤집는 것이 핵심입니다. 전환을 결정한 다음에 “무엇을 넘겨받아야 하지?”를 묻는 것이 아니라, 결정하기 전에 넘겨받을 목록을 먼저 확정해 두는 것입니다. 목록이 있으면 이관은 그 목록을 하나씩 채우는 절차가 되고, 목록이 없으면 이관 자체가 하나의 프로젝트가 됩니다.

먼저 가르는 한 가지 — 계정은 누구 명의인가

넘겨받을 목록을 만들기 전에 답해야 할 질문이 하나 있습니다. 지금 AWS 계정이 누구 명의인가입니다. 이 하나가 인수인계 난이도의 첫 갈림길을 만듭니다.

계정이 고객사 명의로 되어 있고 운영 업체는 교차 계정 역할 위임으로 접근하는 구조라면, 이관은 비교적 단순합니다. 소유는 처음부터 고객사에 있었으므로, 위임된 역할을 지우고 새 주체에게 필요한 권한을 다시 부여하는 것으로 접근이 정리됩니다. 계정 자체를 옮길 필요가 없습니다.

반대로 계정이 운영 업체의 조직 아래에 개설돼 있다면 이야기가 달라집니다. 여기서 조직은 여러 계정을 하나로 묶어 관리하고 결제하는 단위를 말합니다. 이 경우 접근 권한을 정리하는 것만으로는 끝나지 않고, 계정 자체를 조직에서 분리하는 절차가 추가로 필요합니다. 그리고 분리를 진행하려면 계정이 홀로 운영될 수 있는 상태여야 합니다. 예를 들어 계정 자체에 결제 수단과 연락처가 등록돼 있어야 분리가 막히지 않습니다.

운영을 맡긴다는 것이 소유와 어떻게 다른지, 계정과 데이터가 누구 것인지의 원칙은 AWS MSP란 무엇이고 언제 맡기는 것이 맞는가에서 더 자세히 다룹니다. 여기서 기억할 것은 하나입니다. 계정 명의를 모른 채 인수인계를 시작하면, 접근만 넘기면 될 일인지 계정 자체를 옮겨야 할 일인지조차 판단할 수 없습니다.

넘겨받을 산출물 체크리스트

인수인계에서 요구할 산출물은 대체로 여섯 갈래로 정리됩니다. 각 항목마다 왜 중요한가 / 없으면 무엇이 문제인가 / 확인 방법을 함께 두었습니다. 항목 이름만 받아 두는 것이 아니라, 그 항목이 실제로 채워졌는지를 확인하는 것이 목적입니다.

1. 구성 문서 — 무엇이 어떻게 세워져 있는가

• 왜 중요한가: 네트워크 구성, 어떤 자원이 무슨 역할을 하는지, 서로 어떻게 연결돼 있는지가 정리돼 있어야 넘겨받은 쪽이 손을 대도 되는 곳과 대면 안 되는 곳을 구분할 수 있습니다.
• 없으면: 현재 상태는 조회할 수 있어도 왜 그렇게 설정됐는지는 알 수 없어, 함부로 바꿨다가 다른 곳이 멈추는 일이 생깁니다. 의도를 모르는 구성은 손대기 두려운 구성이 됩니다.
• 확인 방법: 구성도나 아키텍처 설명 문서를 요청하고, 문서가 실제 계정 상태와 일치하는지 대조하십시오. 문서가 없다면 아래 「문서가 없는 환경을 이어받기」의 방식으로 현행을 역으로 정리해야 합니다.

2. 권한·계정 목록 — 지금 누가 접근하는가

• 왜 중요한가: 계정에 어떤 사용자와 역할이 있고 각각 무슨 권한을 갖는지가 있어야, 넘겨받은 뒤 회수할 접근과 유지할 접근을 가릴 수 있습니다.
• 없으면: 이전 운영 주체가 알고 있던 접근 경로가 그대로 열린 채 남습니다. 빠뜨린 접근은 빠뜨렸다는 사실 자체가 드러나지 않습니다.
• 확인 방법: 사용자·역할·접근 키의 목록과 각각의 권한 범위를 문서로 받고, 외부에 위임된 역할이 있는지 함께 확인하십시오.

3. 비용·결제 정보 — 어디로 청구되고 있는가

• 왜 중요한가: 결제 수단, 진행 중인 약정, 남은 크레딧이 계정에 묶여 있으면 소유를 옮길 때 이 축을 함께 정리해야 합니다.
• 없으면: 계정을 넘겨받았는데 청구는 여전히 이전 주체로 나가거나, 약정이 어디에 걸려 있는지 몰라 이관이 중간에 막힙니다.
• 확인 방법: 결제 수단이 계정에 직접 등록돼 있는지, 진행 중인 약정과 크레딧의 조건이 무엇인지 확인하십시오. 상세는 아래 「비용·결제가 넘어오는 방식」에서 다룹니다.

4. 백업·복구 — 무엇이 어떻게 보관되는가

• 왜 중요한가: 백업 정책과 보관 위치, 복구가 실제로 되는지를 확인해야 넘겨받은 직후 사고가 나도 되돌릴 수 있습니다.
• 없으면: 백업이 돌고 있다고 적혀 있어도 실제로 복구가 되는지는 별개입니다. 복구를 시도해 본 적이 없는 백업은 사고가 났을 때 처음 시험하게 됩니다.
• 확인 방법: 백업 대상과 주기, 보관 기간, 그리고 복구를 실제로 검증한 이력이 있는지를 물어보십시오. 검증 이력이 없다면 인수인계 직후 한 번 복구를 시험해 두는 편이 안전합니다.

5. 모니터링·알림 — 무엇을 보고 누구에게 알리는가

• 왜 중요한가: 어떤 지표를 감시하고 이상이 생기면 누구에게 알리는지가 있어야, 감시가 끊기지 않고 새 주체로 이어집니다.
• 없으면: 넘겨받은 뒤 알림이 여전히 이전 담당자에게만 가거나, 아무에게도 가지 않는 구간이 생깁니다. 감시는 돌고 있는데 아무도 안 보는 상태가 가장 위험합니다.
• 확인 방법: 설정된 경보의 목록과 각 경보의 알림 수신처를 받고, 인수인계 시점에 수신처를 새 주체로 옮기는 것을 계획에 넣으십시오.

6. 운영 이력 — 그동안 무슨 일이 있었는가

• 왜 중요한가: 과거에 어떤 변경이 있었고 어떤 장애가 반복됐는지를 알면, 넘겨받은 뒤 같은 문제를 다시 처음부터 파악하지 않아도 됩니다.
• 없으면: 몇 달 뒤 같은 장애가 다시 나도 그것이 처음인지 반복인지 알 수 없어, 원인을 매번 새로 추적하게 됩니다.
• 확인 방법: 정기 보고서, 변경 이력, 과거 장애와 그 조치 기록을 요청하십시오. 이런 이력이 남아 있지 않다면 앞으로는 남기는 체계부터 세우는 것이 인수인계의 일부가 됩니다.

권한 회수와 재부여 순서

권한 정리는 끊긴 접근과 남은 접근을 둘 다 막아야 하는 작업입니다. 한쪽만 신경 쓰면 다른 쪽이 열립니다.

가장 흔한 실수는 순서를 뒤집는 것입니다. 이전 주체의 접근을 먼저 끊고 새 접근을 나중에 여는 순서로 하면, 그 사이에 아무도 손댈 수 없는 공백이 생깁니다. 반대로 새 접근이 정상 동작하는 것을 확인한 뒤에 기존 접근을 닫으면 공백 없이 넘어갑니다. 계정이 고객사 명의라면 이 전환은 위임된 역할을 새로 만들고 이전 역할을 지우는 것으로 정리되고, 계정을 옮겨야 하는 구조라면 조직 분리 절차와 맞물려 진행됩니다.

정리 대상은 사람 계정만이 아닙니다. 서드파티에 부여한 교차 계정 역할, 오래전 만들어져 잊힌 접근 키, 특정 프로그램에 붙어 있는 권한까지 함께 훑어야 합니다. 누가 무엇에 접근할 수 있는지를 AWS 책임 공유 모델 기준으로 보면, 이 접근 통제는 고객 책임 영역에 속하므로 넘겨받는 쪽이 직접 확인해야 하는 부분입니다. 무엇을 회수하고 무엇을 새로 부여했는지 목록으로 남겨 두면, 나중에 빠뜨린 자리를 되짚을 수 있습니다.

문서가 없는 환경을 이어받기

구성 문서가 넘어오지 않는 경우가 실제로 적지 않습니다. 이때는 문서를 받는 대신 현재 상태에서 문서를 역으로 만드는 작업이 인수인계에 포함됩니다.

두 갈래로 접근합니다. 하나는 현행 구성을 조회해 지금 무엇이 어떻게 세워져 있는지를 목록으로 정리하는 것입니다. 다른 하나는 계정에 남아 있는 변경 이력을 읽는 것입니다. AWS CloudTrail 같은 기록이 켜져 있었다면 언제 누가 무엇을 바꿨는지를 되짚어, 현재 구성이 어떤 순서로 만들어졌는지를 상당 부분 복원할 수 있습니다.

다만 이 방식으로도 복원하지 못하는 것이 있습니다. 왜 그렇게 설정했는가라는 의도입니다. 현재 상태와 변경 순서는 기록에 남지만, 그 판단의 배경은 사람의 설명 없이는 채워지지 않습니다. 그래서 문서가 없는 환경일수록, 가능한 범위에서 기존 담당자의 인수 설명을 함께 받아 두는 것이 좋습니다. 그것이 어렵다면 현행 구성부터 AWS 무료 점검으로 정리해, 넘겨받은 상태를 먼저 파악하는 순서가 앞섭니다.

비용·결제가 넘어오는 방식

비용 축은 소유 이관과 별개로 따로 챙겨야 하는 부분입니다. 계정 접근을 넘겨받았다고 청구가 자동으로 새 주체로 옮겨 오지는 않습니다.

확인할 것은 대략 이렇습니다. 첫째, 결제 수단이 계정에 직접 등록돼 있는지, 아니면 조직 단위로 묶여 있는지입니다. 조직 아래 계정이라면 앞서 말한 분리 절차에서 결제 수단과 연락처가 계정에 자체 등록돼 있어야 분리가 진행됩니다. 둘째, 진행 중인 약정입니다. 일정 기간 사용을 약속하고 할인을 받는 구조가 걸려 있으면, 그것이 어느 계정에 속하고 언제까지인지에 따라 이관 방식이 달라집니다. 셋째, 남은 크레딧입니다. 계정에 붙은 크레딧은 계정을 옮길 때 함께 따라가는지 확인해 두어야 합니다.

청구 내역을 읽는 축으로는 AWS Cost Explorer 같은 도구가 어느 항목에 얼마가 나가는지를 보여 줍니다. 인수인계 시점에 이 화면을 함께 열어 두면, 넘겨받은 뒤 비용이 어떻게 움직이는지의 출발점을 잡을 수 있습니다. 넘겨받은 뒤 운영을 계속 맡기실지 검토 중이라면 AWS 관리 대행 서비스 범위에서 비용 확인이 어디까지 포함되는지 나눠 적힌 부분을 보시고, 운영 플랜과 요금 기준은 AWS 운영 플랜과 요금에 정리돼 있습니다.

인수인계 중 공백을 막는 법

인수인계에서 가장 조용히 새는 구간은 넘기는 쪽과 받는 쪽이 서로 상대가 보고 있다고 생각하는 시간입니다. 이 구간은 아무도 사고를 내지 않아도 위험이 쌓입니다.

이를 막으려면 전환의 시점들을 하나의 순서로 미리 합의해 두어야 합니다. 접근을 끊는 시점과 여는 시점, 감시와 알림의 수신처가 바뀌는 시점, 그리고 결제와 소유가 넘어가는 시점을 각각 언제 하는지 정해 두는 것입니다. 특히 알림 수신처는 잊기 쉽습니다. 권한만 넘기고 알림 설정을 그대로 두면, 이상이 생겨도 통지가 이전 담당자에게 가거나 아무에게도 가지 않는 구간이 생깁니다.

한 가지 원칙을 두면 대부분의 공백이 사라집니다. 새 경로가 정상 동작하는 것을 확인한 뒤에 이전 경로를 닫는다는 것입니다. 접근이든 알림이든 결제든, 새것이 확실히 도는 것을 본 다음에 옛것을 정리하면 사이에 빈 구간이 생기지 않습니다. 이 순서는 인수인계에 걸리는 기간과 무관하게 지킬 수 있고, 기간을 미리 며칠이라고 약속하기 어려운 이유이기도 합니다. 환경마다 넘겨받을 목록의 양이 다르기 때문입니다.

넘겨받은 첫 며칠 점검

이관이 끝났다고 인수인계가 끝난 것은 아닙니다. 넘겨받은 직후에 먼저 손봐야 할 것이 있습니다.

• 자격 증명 교체. 넘겨받았다는 것은 이전에 접근하던 사람들이 여전히 같은 키와 비밀번호를 알고 있다는 뜻입니다. 접근 키를 새로 발급하고, 로그인 비밀번호를 바꾸고, 다단계 인증을 다시 설정하십시오. 이 교체를 미루면 인수인계는 끝났는데 예전 접근 경로만 그대로 열려 있는 상태가 됩니다.
• 남은 권한 정리. 더 이상 쓰지 않는 사용자, 오래된 역할, 외부에 위임된 접근이 남아 있는지 다시 훑으십시오. 앞서 회수 목록을 만들어 두었다면, 그 목록과 현재 상태를 대조하면 됩니다.
• 알림 수신 확인. 경보가 실제로 새 주체에게 도착하는지 시험해 보십시오. 설정이 남아 있어도 수신처가 옛 주소면 아무 소용이 없습니다.
• 백업 복구 시험. 복구를 실제로 검증한 이력이 없었다면, 넘겨받은 직후 조용한 시점에 한 번 복구를 시험해 두는 편이 안전합니다.
• 비용 흐름 관찰. 넘겨받은 뒤 며칠간 청구가 예상대로 움직이는지 지켜보십시오. 이관 과정에서 자원이 중복으로 켜져 있거나, 옮긴 뒤에도 옛 구성이 남아 이중으로 과금되는 일이 이 시점에 드러납니다.

이 점검을 목록으로 두고 하나씩 지워 가면, 인수인계가 “접근을 넘겨받은 것”에서 “운영을 이어받은 것”으로 실제로 넘어갑니다.

다음 단계

지금 문서가 없거나 현재 구성부터 파악해야 하는 단계라면, AWS 무료 점검으로 지금 상태를 먼저 정리해 보시는 것이 순서상 앞섭니다. 계정 접근 권한을 먼저 요구하지 않고 짧은 상담으로 무엇부터 봐야 할지 짚어 드리며, 정리된 내용은 이어서 맡기지 않으셔도 그대로 가져가실 수 있습니다.

운영 주체를 바꾸는 쪽으로 방향이 기울었다면, 환경은 그대로 두고 주체만 이어받는 AWS 운영 전환에서 이관을 어떤 순서로 진행하는지 확인해 보십시오. 내부 인력으로 들일지 계속 위탁할지를 저울질하는 단계라면 자체 운영과 위탁의 비용·책임 비교가 그 판단을 나눠 놓았습니다. 우리 환경에 맞는 인수인계 목록을 함께 정리하고 싶으시면 상담 신청으로 연락 주십시오.

참고 자료

• AWS IAM — 서드파티에 계정 접근 권한 위임(교차 계정 역할)
• AWS Organizations — 조직에서 계정 제거하기
• AWS 책임 공유 모델
• AWS CloudTrail — 개념
• AWS Cost Explorer — 개요