계정·조직 거버넌스

담당 역할: 클라우드 플랫폼/인프라 아키텍트

3.1 배경과 목적#

계정/조직 거버넌스를 가장 먼저 설계하라. 권한·재무·보안 정책은 모두 계정이나 OU 같은 경계 위에 부착된다. 이 경계를 잘못 그으면 이후 모든 정책이 잘못된 범위에서 작동한다.

AWS는 계정을 이렇게 정의한다. “AWS 계정은 사용자 계정과 다른 개념으로, 리소스 컨테이너이자 격리 경계로 기능한다.” 계정은 누가 로그인하는가의 문제가 아니라, 어디까지가 하나의 폭발 반경(blast radius)인가를 정하는 단위다.

3.2 필요 지식#

• 격리 경계(Isolation Boundary): 계정·구독·프로젝트는 보안 사고나 설정 오류의 영향이 다른 워크로드로 번지지 못하게 막는 물리적 경계다.

• 랜딩존(Landing Zone): 잘 설계된 환경은 랜딩존에서 시작한다. 계정을 만들 때마다 네트워크·보안·로깅을 수동으로 설정하는 대신, 표준 기준선을 자동으로 갖춘 상태로 계정을 발급한다.

• OU/Management Group/Folder: 정책이 실제로 부착되는 지점이다. 조직도가 아니라 정책이 필요한 최소 단위를 기준으로 설계하라.

• Hub-Spoke 토폴로지: 중앙화에서 이익을 얻는 것(보안·인터넷 이그레스·DNS·비용 가시성)은 Hub 계정에 모으고, 격리에서 이익을 얻는 것(폭발 반경·IAM 경계·과금)은 Spoke 계정에 나눈다.

3.3 표준 체계# AWS — Control Tower / 멀티 계정 전략#

AWS가 권고하는 well-architected 환경은 세 요소로 이루어진다 — 다중 계정, 다중 OU, 잘 계획된 구조. 표준 OU는 다음과 같다.

계정을 나누는 이유는 다섯 가지다. 보안 통제는 감사인에게 특정 워크로드를 계정 단위로 제시할 수 있게 한다. 격리는 위협의 폭발 반경을 계정 경계에서 막는다. 팀 분리는 자원 충돌을 없앤다. 데이터 격리는 GDPR 같은 규제 대응에 필요한 접근자 범위를 줄인다. 비즈니스 프로세스 분리는 사업부별로 다른 운영 리듬을 반영한다.

Azure — Cloud Adoption Framework의 Govern 방법론#

Microsoft CAF는 Govern 방법론 아래 5개 규율을 정의한다.

Azure Policy가 집행 엔진이다. Audit(감사), Deny(차단), DeployIfNotExists(자동 교정) 세 가지 effect를 지원하며, 관련 정책을 Initiative로 묶어 배포한다. Azure Blueprints는 2026년 7월 폐지되어 Azure Deployment Stacks로 이관되므로, 신규 설계에는 Blueprints를 쓰지 마라.

GCP — 리소스 계층과 Organization Policy Service#

GCP는 Organization → Folder → Project → Resource 계층에서 상위 정책이 하위로 자동 상속된다. Organization Policy Service는 100개 이상의 내장 제약으로 API 전반을 통제한다. compute.requireOsLogin은 전 Compute Engine VM에 OS Login을 강제하고, iam.disableWorkloadIdentityClusterCreation은 통제되지 않은 Workload Identity 사용을 막는다. 규제 워크로드는 Assured Workloads로 데이터 거주지와 인력 접근을 자동 제한한다.

3.4 실무 적용 단계#

1. 1단계 — 계정 구조 설계 — 사업부·환경(prod/staging/dev/sandbox)·규제 요건을 기준으로 최소 OU 구조를 그려라. 조직도를 그대로 옮기지 마라.

2. 2단계 — 랜딩존 구축 — Control Tower, Landing Zone Accelerator, 또는 Terraform 기반 랜딩존으로 Hub 계정(관리·네트워크·보안)을 먼저 구축하라.

3. 3단계 — 계정 발급 자동화 — 새 팀이 요청하면 네트워킹·보안·CI/CD 아이덴티티까지 포함된 계정을 단일 워크플로우로 발급하는 체계(Account Vending Machine)를 만들어라. 클릭옵스를 완전히 대체하는 것이 목표다.

4. 4단계 — 필수 가드레일 부착 — LeaveOrganization 차단, 루트 사용자 차단, 허용 리전 제한 같은 SCP를 계정 생성 시점부터 붙여라.

5. 5단계 — 태깅·백업 정책 표준화 — Environment, Project 같은 필수 태그와 백업 주기를 조직 정책으로 강제하라.

6. 6단계 — 지속적 유지관리 — OU 구조는 한 번 만들고 끝나지 않는다. 조직이 성장하면 분기·반기 단위로 재검토하라.

3.5 실전 패턴 — Hub-Spoke와 Account Vending Machine#

Hub-Spoke AWS Landing Zone — Hub 계정(Management/Network Hub/Security Hub)에 Transit Gateway·Egress VPC·중앙 보안 포스처를 모으고, Spoke 계정(팀별 워크로드)은 3-AZ 프라이빗 VPC로 TGW에 연결한다. 핵심은 “역방향 와이어링(Reverse Wiring)”이다 — Hub가 자신의 TGW ID를 SSM Parameter Store에 게시하면 Spoke가 이를 읽어 스스로 연결하므로, Hub의 Terraform 상태에 대한 직접 의존을 없앤다.

Account Vending Machine(AVM) — 새 워크로드 계정을 네트워킹·보안·CI/CD 아이덴티티까지 완전 구성해서 단일 워크플로우 실행(약 8분, 완전 멱등)으로 발급한다. 팀 이름을 입력하면 완전한 AWS 계정이 나오는 자판기에 비유된다. Spoke 계정은 3-AZ 프라이빗 VPC, TGW 연결, GitHub OIDC 기반 CI/CD 아이덴티티(정적 크리덴셜 없음), 암호화된 Terraform 상태 버킷을 자동으로 받는다.

3.6 체크리스트#

• 모든 환경(prod/staging/dev/sandbox)이 서로 다른 계정으로 분리되어 있는가?

• OU 구조가 조직도가 아니라 정책 요구사항 기준으로 설계되었는가?

• 새 계정을 표준화된 랜딩존 템플릿으로 만드는가, 수동 클릭옵스로 만드는가?

• 모든 계정에 최소한의 필수 SCP(루트 사용자 차단, 조직 이탈 차단, 리전 제한)가 붙어 있는가?

• 계정 소유자·용도·생성일이 중앙 인벤토리에 기록되어 있는가?

• 휴면 계정을 분기마다 검토하고 회수하는가?

3.7 흔한 함정#

• 조직도를 그대로 OU 구조에 옮긴다: 부서를 개편할 때마다 OU를 다시 설계하는 악순환에 빠진다.

• OU를 과도하게 중첩한다: 5단계까지 기술적으로는 가능하지만, 깊은 중첩은 정책 관리 복잡도만 늘린다. 최소 OU에서 시작해 필요할 때만 확장하라.

• Sandbox를 프로덕션 네트워크에 연결한다: 격리의 의미가 사라진다.

• 계정 발급을 여전히 수동으로 처리한다: 팀이 늘어날수록 병목이 되고, 사람이 개입하는 단계마다 설정을 빠뜨릴 위험이 커진다.