조직이 한 계정에서 시작해 두 계정, 다섯 계정을 거쳐 수십 개 계정으로 자라는 과정을 지켜보면 어느 순간 같은 질문에 부딪힌다. "개발자가 새 서비스를 만들 때마다 플랫폼 팀이 계정을 깎고, 파이프라인을 짜고, 보안 베이스라인을 손으로 심어야 한다면, 팀은 곧 자기 시간의 전부를 '남의 인프라 셋업'에 쓰게 된다. 어떻게 표준을 강제하면서도 개발자를 기다리게 하지 않을 것인가." 이 긴장 — 거버넌스(통제)와 셀프서비스(속도) 사이의 줄다리기 — 이 멀티 계정 엔터프라이즈 CI/CD의 본질이다. 오늘은 50개 마이크로서비스, 60개 넘는 AWS 계정, 100명 개발자에 플랫폼 엔지니어 5명이라는 현실적인 비율의 조직을 놓고, 그 줄다리기를 어떤 구조로 푸는지 — Landing Zone과 Account Factory, Tooling 계정 중심의 Hub-Spoke, Service Catalog 셀프서비스, Permission Boundary와 SCP의 권한 봉투 — 를 그 밑에 깔린 분산 시스템·조직 이론과 함께 판다.
DOP 시험에서 이 영역은 "수백 개 계정에 동일 베이스라인을 자동 적용하려면", "개발자가 만든 IAM Role이 회사 정책을 넘지 못하게 하려면", "50개 서비스에 표준 파이프라인을 셀프서비스로 제공하려면" 같은 시나리오로 반복 등장한다