Cloud Modernization · 26

AWS Organizations와 SCP로 다중 계정 최대 권한 제어하기

계정을 여러 개 만들면 관리가 더 복잡해질 것 같은데 왜 다중 계정이 필요한지 감이 오지 않는다.

근거 · 교안 p116-p120

1장: 다중 계정, 왜 복잡성을 감수해야 할까?

솔라는 노트북 화면 한쪽에 떠 있는 메모를 보며 미간을 찌푸렸다. 깔끔하게 정리된 글머리 기호 아래, ‘다중 계정을 사용하는 이유’라는 제목과 함께 여러 항목이 나열되어 있었다.

• 여러 팀
• 보안 및 규정 준수
• 결제 격리
• 비즈니스 프로세스

분명 중요한 내용 같았지만, 솔라의 머릿속에서는 고개가 갸우뚱거렸다. 계정을 하나만 쓰는 것도 신경 쓸 게 많은데, 이걸 여러 개로 나누면 관리할 것만 두세 배로 늘어나는 것 아닌가? 로그인 정보도, 보안 설정도, 비용 청구서도 모두 제각각일 텐데. 이건 일을 줄이는 게 아니라 오히려 복잡하게 만드는 길처럼 보였다.

“언니.”

마침 거실 소파에서 조용히 책을 읽던 루나에게 솔라가 말을 걸었다.

“AWS 공부하다가 궁금한 게 생겼는데. 왜 굳이 계정을 여러 개 만들어서 쓰는 거야? 그냥 계정 하나에서 사용자(IAM)만 잘 나눠서 쓰면 되는 거 아니야? 계정이 많아지면 관리하기만 더 힘들어질 것 같은데.”

루나는 책에서 눈을 떼고 솔라의 노트북 화면을 잠시 들여다보았다. 화면 속 메모를 훑어본 루나는 잠시 생각에 잠기더니, 옆에 놓인 빈 노트를 솔라 쪽으로 밀어주었다.

“하나의 큰 방이 있다고 상상해볼까?”

루나는 노트에 큼지막한 네모 하나를 그렸다.

“이게 우리 회사의 유일한 AWS 계정, 즉 모두가 함께 쓰는 하나의 큰 작업실이야. 솔라 너는 이 방 한쪽에서 중요한 그림을 그리고 있어. 개발 환경이지. 그리고 다른 쪽에서는 동생들이 물감 놀이를 하고 있네. 마음껏 실험하고 테스트하는 공간이야.”

솔라는 루나가 그리는 그림을 흥미롭게 지켜보았다.

“그리고 방 저편에서는 부모님이 중요한 서류 작업을 하고 계셔. 고객 데이터나 결제 정보 같은 민감한 정보가 담긴, 절대 실수하면 안 되는 운영 환경인 셈이지.”

루나는 네모 안의 각기 다른 구역에 ‘솔라-개발’, ‘동생들-테스트’, ‘부모님-운영’이라고 적어 넣었다.

“어느 날, 물감 놀이하던 동생이 실수로 물감 통을 엎질렀어. 물감이 바닥을 타고 흘러서 부모님의 중요한 서류까지 몽땅 적셔버렸다면 어떨까?”

“아… 큰일 나지.”

솔라는 자기도 모르게 작게 탄식했다.

“그렇지? 테스트 환경에서 일어난 실수가 운영 환경에 직접적인 영향을 준 거야. 반대로, 부모님이 ‘이 방에서는 아무도 위험한 도구를 쓰면 안 돼!’ 하고 가위나 칼을 전부 치워버리면, 솔라 네가 그림을 그리는 데 필요한 도구까지 전부 사라져 버릴 수도 있고.”

루나의 말에 솔라의 머릿속에 흐릿했던 그림이 조금씩 선명해졌다. 하나의 공간에 모든 것을 두었을 때 생기는 문제들이었다. 누가 어떤 도구를 썼는지, 누가 방을 어지럽혔는지 구분하기도 어렵다. 결국 한 달 치 ‘방 사용료’가 나왔을 때, 누가 얼마큼 썼는지 따지기도 애매해진다.

“알겠다. 그래서 방을 나누는 거구나.”

솔라는 루나가 그려준 큰 네모 옆에 작은 네모 여러 개를 직접 그리기 시작했다. 그리고 각각 ‘개발팀 방’, ‘운영팀 방’, ‘보안팀 방’이라고 이름을 붙였다.

“이렇게 각자의 방을 만들어주면, 테스트 방에서 무슨 일이 생겨도 운영 방에 있는 중요한 서류는 안전하겠네. 개발팀 방에서는 필요한 도구를 마음껏 쓰면서도 다른 방에 영향을 주지 않고. 이걸 ‘격리’라고 하는구나.”

솔라는 깨달았다는 듯 고개를 끄덕였다. 다중 계정은 단순히 관리 포인트를 늘리는 복잡한 일이 아니었다. 오히려 서로 다른 목적과 책임, 위험 수준을 가진 환경들을 분리해서 더 큰 혼란과 사고를 막는 현명한 방법이었다.

“맞아. 각 방의 목적에 맞게 규칙을 정하고, 사용 내역도 명확하게 분리할 수 있지. 개발팀 방에서 나온 비용은 개발팀이, 운영팀 방에서 나온 비용은 운영팀이 책임지는 거야.”

솔라는 다시 자신의 노트북 화면 속 메모를 보았다. 아까는 이해할 수 없었던 글자들이 이제는 전혀 다른 의미로 다가왔다.

• ‘여러 팀’ → 각 팀에 독립적인 작업 공간(방)을 주기 위해
• ‘보안 및 규정 준수’ → 중요한 서류가 있는 방(운영 환경)에 더 강력한 잠금장치를 달기 위해
• ‘결제 격리’ → 각 방에서 쓴 비용을 명확히 나누기 위해

다중 계정의 필요성을 이해하자 솔라의 표정이 한결 밝아졌다. 복잡성을 감수하는 게 아니라, 위험한 복잡성을 다루기 쉬운 복잡성으로 바꾸는 전략이었던 것이다. 하지만 동시에 새로운 의문이 고개를 들었다.

“그런데 언니, 이제 이유는 알겠어. 격리가 정말 중요하구나. 그런데… 만약 회사가 커져서 이 방이 수십, 수백 개가 된다고 생각해봐. 사장님이 모든 방의 규칙이 잘 지켜지는지 확인하고, 월세도 한꺼번에 내고 싶은데, 일일이 모든 방을 돌아다녀야 하는 걸까? 결국 관리자가 할 일이 엄청나게 많아지는 건 똑같잖아?”

솔라의 손가락이 자신이 그린 여러 개의 작은 네모들을 가리켰다. 하나하나가 독립된 방이라는 점은 분명한 이점이었지만, 그 개수가 늘어났을 때의 관리 문제는 여전히 해결되지 않은 숙제처럼 보였다.

2장: 분산된 계정들을 어떻게 한눈에 관리할까?

솔라는 이전 대화의 흔적이 남은 노트를 물끄러미 내려다봤다. 각기 다른 목적으로 분리된 여러 개의 ‘방(계정)’ 그림들. 격리의 필요성은 분명히 이해했지만, 수십, 수백 개의 방을 일일이 돌아다니며 관리해야 하는 사장님을 상상하자 머리가 지끈거렸다. 아무리 목적이 좋아도 결국 관리의 복잡성이란 벽에 부딪히는 것 같았다.

그때, 옆에 있던 루나가 솔라의 노트북을 손가락으로 가리켰다. 솔라의 노트북 바탕화면에는 수많은 파일과 폴더가 어지럽게 널려 있었다.

“솔라, 네 컴퓨터에 있는 파일이 몇 개쯤 될 것 같아? 사진, 과제, 그림 파일 전부 합쳐서.”

“음… 글쎄? 세어본 적은 없지만 수천, 어쩌면 만 개는 넘지 않을까?”

“그럼 그 파일들을 찾거나 정리할 때, 만 개의 파일을 하나씩 다 확인해?”

루나의 질문에 솔라는 당연하다는 듯 고개를 저었다. 그녀는 마우스를 움직여 파일 탐색기 창을 열었다. 왼쪽에는 ‘문서’, ‘사진’, ‘다운로드’ 같은 큰 분류가 있었고, ‘사진’ 폴더 안에는 ‘2023_유럽여행’, ‘가족사진’, ‘드로잉’ 같은 하위 폴더들이 계층적으로 정리되어 있었다.

“아니, 당연히 폴더로 정리하지. 이렇게 ‘여행’ 폴더 안에 ‘2023년’ 폴더를 만들고, 그 안에 또 ‘파리’, ‘로마’ 폴더를 만들어서 사진을 넣어두면 나중에 찾기 쉽잖아. ‘파리’ 폴더에 있는 사진을 전부 선택해서 한 번에 지우거나 옮길 수도 있고.”

솔라가 직접 자신의 파일 정리 방식을 설명하는 순간, 그녀의 눈이 동그래졌다. 방금 자신이 한 말이, 조금 전까지 고민하던 문제에 대한 실마리처럼 느껴졌다.

“잠깐… 설마?”

솔라는 고개를 들어 루나를 쳐다봤다. 루나는 빙그레 웃으며 고개를 끄덕였다.

“수많은 AWS 계정을 관리하는 것도 똑같아. 사장님이 수백 개의 방을 일일이 돌아다닐 필요가 없는 거지. 대신, 그 방들을 담는 더 큰 ‘폴더’를 만들면 되니까.”

루나는 솔라가 그려놓은 여러 개의 네모(계정)들 주변에 더 큰 사각형을 그리기 시작했다.

“컴퓨터에서 파일을 폴더로 묶어 정리하는 것처럼, AWS에서는 AWS Organizations라는 서비스를 사용해서 여러 계정을 그룹으로 묶고 관리할 수 있어. 이때 우리가 만드는 폴더를 **조직 단위(Organizational Unit, OU)**라고 불러.”

루나는 ‘개발팀 방’, ‘테스트 방’이라고 적힌 네모들을 하나의 큰 사각형으로 묶고 ‘개발 OU’라고 적었다. 또 ‘운영팀 방’, ‘보안팀 방’을 묶어 ‘운영 OU’라고 이름 붙였다.

“아하! 그럼 아까 그 사장님은 각 방에 들어갈 필요 없이, ‘개발 OU’라는 폴더를 보고 ‘여기 소속된 방들은 전부 개발팀 거구나’ 하고 한눈에 파악할 수 있겠네. 비용 청구서도 각 방마다 따로 나오는 게 아니라, 회사 전체 이름으로 한 번에 통합해서 나오고!”

솔라는 자신이 겪어본 파일 정리의 편리함이 그대로 적용된다는 사실에 무릎을 쳤다. 수백 개의 파일을 하나하나 관리하는 것은 불가능하지만, 잘 분류된 열 개의 폴더를 관리하는 것은 훨씬 수월하다. 마찬가지로 수백 개의 계정도 목적에 맞게 OU로 묶어 계층 구조를 만들면, 관리의 복잡성이 극적으로 줄어드는 것이다.

“맞아. 그걸 **통합 결제(Consolidated Billing)**라고 해. 모든 계정의 비용이 관리 계정(마스터 계정)으로 통합 청구되니까 비용 관리가 훨씬 편해지지. 심지어 사용량이 많아지면 볼륨 할인을 받기도 더 쉬워지고.”

이제 솔라의 머릿속 그림이 완성되었다. 개별 계정은 ‘격리’라는 강력한 이점을 제공하고, AWS Organizations는 흩어진 계정들을 ‘계층 구조’로 묶어 중앙에서 효율적으로 관리할 수 있게 해주는 도구였다. 복잡성을 감수하는 것이 아니라, 현명하게 다루는 방법이 있었던 것이다.

솔라는 자신이 그린 그림을 만족스럽게 바라보았다. 그러나 이내 새로운 궁금증이 생겼다.

“언니, 그럼 폴더마다 규칙을 정할 수도 있는 거야? 예를 들어, ‘개발 OU’ 폴더에 속한 모든 방에서는 절대 특정 도구를 사용하지 못하게 막는 규칙 같은 거 말이야. 만약 내가 폴더 전체에는 ‘가위 사용 금지’ 규칙을 걸었는데, 그 폴더 안의 특정 방 주인에게는 내가 따로 ‘가위 써도 돼’라고 허락해줬다면… 둘 중 어떤 규칙이 적용되는 거지?“

3장: 계층 구조에서 권한은 어떻게 통제될까?

솔라는 자신이 그린 조직도 위에 볼펜을 든 채 허공을 맴돌았다. ‘개발 OU’, ‘운영 OU’라는 폴더 구조로 수많은 계정을 깔끔하게 정리한 것은 만족스러웠다. 하지만 펜 끝이 향하는 ‘개발 OU’ 폴더를 보며 새로운 질문이 맴돌았다. 폴더 전체에 적용하는 규칙과, 폴더 안의 개별 방(계정)에 적용하는 규칙이 서로 충돌하면 어떻게 될까? 관리자가 ‘개발 OU’ 폴더 전체에는 ‘가위 사용 금지’라는 큰 규칙을 걸었는데, 그 안의 한 방 주인인 내가 특정 사용자에게 ‘가위 써도 돼’라고 허락한다면, 그 사용자는 가위를 쓸 수 있을까, 없을까?

이 모순처럼 보이는 상황에 솔라의 생각이 멈췄다. 중앙에서 규칙을 강제하는 강력한 기능이 있는 건 좋은데, 그게 개별 계정의 자율성과 부딪힐 때의 작동 방식을 알 수 없었다.

루나는 솔라의 고민을 읽은 듯, 조용히 말을 꺼냈다.

“보안이 아주 철저한 연구소 건물을 상상해 보자.”

“연구소 건물?”

“응. 그 건물은 1층 로비로 들어갈 때 모든 방문객의 출입증을 확인해. 출입증에는 ‘이 사람은 우리 건물에 들어올 수 있음’이라고 적혀 있지. 이게 첫 번째 관문이야.”

루나는 노트 위에 큰 사각형으로 ‘건물’을 그리고, 그 안에 들어가는 화살표 옆에 ‘출입증 확인’이라고 적었다.

“그런데 솔라, 네가 가려는 곳은 10층의 특수 실험실이야. 그 실험실 문 앞에는 별도의 카드 리더기가 또 있어. 10층 실험실 출입 권한이 있는 사람만 통과시키는 두 번째 관문이지.”

루나는 건물 사각형 안에 작은 ‘10층 실험실’ 네모를 그리고, 그 앞에 ‘실험실 카드 확인’이라는 두 번째 관문을 그렸다.

“자, 여기서 질문. 네 손에 10층 실험실 카드만 있다면, 실험실에 들어갈 수 있을까?”

솔라는 잠시 그림을 보더니 고개를 저었다. “아니. 일단 건물 1층 로비부터 통과할 수 없잖아. 건물 출입증이 없으니까.”

“정확해. 그럼 반대로, 건물 출입증만 있다면?”

“당연히 안 되지. 10층 실험실 문 앞에서 막힐 테니까.”

“바로 그거야. 특수 실험실에 들어가려면, 건물 출입증도 ‘허용’, 실험실 출입 카드도 ‘허용’이어야만 해. 둘 중 하나라도 ‘거부’하면 절대 들어갈 수 없어.”

이중 보안 시스템. 두 개의 관문이 모두 허락해야만 최종 통과가 되는 원리. 솔라는 이 비유를 듣는 순간, 자신이 궁금해했던 AWS 권한 문제의 구조가 보이기 시작했다.

“그럼… 아까 그 폴더 규칙이 건물 전체에 적용되는 첫 번째 관문이구나! 그걸 **서비스 제어 정책(Service Control Policy, SCP)**이라고 부르는 거고.”

솔라의 목소리에 깨달음이 묻어났다.

“그리고 내가 방 안에서 특정 사용자에게 주는 권한이 바로 10층 실험실 카드, 즉 IAM 정책인 거지. 맞지, 언니?”

루나는 고개를 끄덕였다.

“맞아. SCP는 각 계정이 사용할 수 있는 권한의 ‘최대 범위’를 정하는 가드레일 역할을 해. 절대로 넘을 수 없는 경계선이지. SCP가 ‘가위 사용 금지’라고 막아두면, 그 조직(OU)에 속한 어떤 계정에서도 IAM 정책으로 ‘가위 사용 허용’을 해봤자 소용없어. 건물 주인이 ‘10층은 아무도 못 들어가’라고 막아두면, 10층 실험실 카드가 아무리 많아도 의미가 없는 것처럼.”

SCP는 IAM을 대체하는 것이 아니었다. 오히려 IAM 위에 존재하는 더 큰 틀의 필터였다. IAM 정책이 아무리 많은 권한을 허용해도, 조직 전체에 적용된 SCP의 허용 범위를 벗어날 수는 없었다. 최종적으로 허용되는 권한은 SCP와 IAM 정책의 교집합인 셈이다.

“알겠다! 그럼 SCP는 뭔가를 ‘허용’하는 정책이 아니라, ‘무엇까지만 허용될 수 있는지’를 정의하는 울타리 같은 거구나. 실제 행동을 허가하는 건 여전히 계정 안의 IAM이고.”

솔라는 마침내 혼란을 정리하고 확신에 찬 얼굴로 펜을 들었다. 그녀는 자신이 그렸던 ‘개발 OU’ 폴더 옆에 새로운 주석을 달기 시작했다.

[개발 OU] - SCP: EC2, S3 서비스만 허용 (다른 모든 서비스는 금지)

그리고 그 폴더 안에 있던 ‘개발팀 A 계정’ 네모 안에도 글씨를 썼다.

[개발팀 A 계정] 사용자 '솔라' - IAM 정책: EC2, S3, DynamoDB 사용 허용

마지막으로, 솔라는 ‘DynamoDB’라는 단어 위에 빨간색으로 가로선을 쭉 그었다.

“이렇게 되는 거네. ‘개발 OU’의 SCP가 애초에 DynamoDB 사용을 막고 있으니까, 계정 안에서 IAM으로 허용해 줘도 나는 결국 EC2랑 S3만 쓸 수 있는 거야. 이중 보안 시스템에 완벽하게 걸러졌네.”

솔라는 자신이 완성한 그림을 보며 미소 지었다. 흩어져 있던 수많은 방들, 그것들을 묶는 폴더, 그리고 그 위에 씌워진 보이지 않는 강력한 필터까지. 이제야 복잡한 다중 계정 환경을 중앙에서 어떻게 안전하고 효율적으로 통제하는지, 그 전체 그림이 명확하게 보였다. 복잡성을 늘리는 게 아니라, 복잡성을 지배하는 방법이었다.