기업이 Azure를 본격적으로 도입할 때 가장 먼저 만들어야 할 것이 Azure 랜딩존(Landing Zone)입니다. 랜딩존을 잘 설계하면 이후 수백 개의 리소스가 배포돼도 일관성과 보안을 유지할 수 있지만, 잘못 설계하면 나중에 전체를 다시 구축해야 하는 상황이 발생합니다. 이번 글에서는 실제 엔터프라이즈 프로젝트에서 설계한 랜딩존의 구조와 고려사항을 공유합니다.
랜딩존이란 무엇인가
랜딩존은 워크로드를 배포하기 전에 갖춰놓는 기본 Azure 환경입니다. 구독, 관리 그룹, 네트워크, 보안, 거버넌스 등의 기반 요소를 미리 설계·구축해 두는 것입니다.
랜딩존의 8가지 설계 영역
- Identity and Access Management (IAM)
- Network Topology and Connectivity
- Security
- Resource Organization (구독, 관리 그룹, 태그)
- Governance (Policy, Blueprint)
- Management (Monitoring, Logging)
- Platform Automation and DevOps
- Business Continuity and Disaster Recovery
랜딩존 배포 옵션
옵션 1: Enterprise-Scale Landing Zone (권장)
Microsoft가 공식 제공하는 Bicep/Terraform 템플릿으로, 엔터프라이즈 요구사항을 반영한 완성도 높은 구조입니다. 처음 Azure를 도입하는 대기업에 적합합니다.
옵션 2: Azure Landing Zone Accelerator
Portal에서 마법사 형태로 랜딩존을 배포할 수 있는 도구입니다. GUI 기반이라 진입 장벽이 낮습니다.
옵션 3: 자체 설계
템플릿을 그대로 쓰지 않고 조직에 맞게 직접 설계하는 방식입니다. 시간과 전문성이 필요하지만 유연성이 최대입니다. 한국 금융권처럼 특수한 요구사항이 있는 조직에서 자주 선택됩니다.
실전 랜딩존 구조 (한국 엔터프라이즈 기준)
관리 그룹 계층
Tenant Root Group 아래에 다음 구조를 권장합니다.
- Contoso (회사명)
- Platform
- Identity: Active Directory 통합, Entra ID Connect 서버
- Management: Log Analytics Workspace, Automation Account, Key Vault
- Connectivity: ExpressRoute, VPN Gateway, Azure Firewall
- Landing Zones
- Corp: 내부 업무 시스템 (ERP, HR, 내부 웹)
- Online: 고객 대면 서비스 (웹, 모바일 API)
- Sandbox: 개발자 실험용 (예산 제한)
- Decommissioned: 폐기 예정 리소스
- Platform
구독 분리 원칙
- Platform 영역과 워크로드 영역 구독 분리 (청구·책임 구분)
- Production과 Non-Production 구독 분리 (실수 방지)
- 부서별 또는 사업부별 구독 분리 (Chargeback)
- 단일 구독에 너무 많은 리소스 금지 (Azure Resource Manager 한도 고려)
네트워크 설계
Hub-Spoke 또는 Virtual WAN 선택
규모에 따라 다음과 같이 결정합니다.
- 단일 리전, 소규모: 전통 Hub-Spoke
- 멀티 리전, 멀티 브랜치: Virtual WAN
IP 주소 계획
처음 배포할 때 신중하게 결정해야 합니다. 나중에 확장이 필요해도 주소를 바꾸기 매우 어렵습니다.
- Hub: /16 (예: 10.0.0.0/16)
- Production Spokes: 10.10.0.0/12 대역에서 분할
- Non-Production Spokes: 10.20.0.0/12 대역에서 분할
- 서브넷은 최소 /24 이상 (Azure 예약 주소 고려)
Private DNS
Private Link를 적극 활용하려면 Private DNS Zone을 미리 구성해야 합니다. Hub VNet에 Private DNS Resolver를 배치하고, 모든 Spoke가 참조하도록 설정합니다.
보안·거버넌스 기반 정책
Azure Policy 초기 적용 세트
랜딩존 배포 시 함께 적용할 필수 정책입니다.
- Storage Account에 HTTPS 필수
- SQL Database 감사 로그 활성화 필수
- 퍼블릭 IP 직접 생성 금지 (필요 시 Firewall 경유)
- 허용된 리전에만 리소스 배포 (Korea Central, Korea South)
- 태그 필수 (cost-center, environment, owner)
RBAC 역할 설계
- Platform Admin: Platform 관리 그룹에 Owner 권한
- Workload Contributor: Landing Zones 하위 구독에 Contributor
- Read-Only: 전체 Tenant에 Reader (감사, 모니터링 팀)
- Cost Reader: Cost Management만 접근 가능 (재무팀)
Privileged Identity Management(PIM)로 Owner·Contributor 권한은 Just-in-Time으로 부여하는 것이 권장됩니다.
관찰성(Observability) 구성
- 중앙 Log Analytics Workspace (Platform Management 구독)
- 모든 리소스의 Diagnostic Setting 자동 적용 (Azure Policy)
- Application Insights 표준화
- Azure Monitor 경고 템플릿 (VM CPU/메모리, Storage 한도 등)
- Microsoft Sentinel 연동 (보안 분석)
랜딩존 배포 후 첫 워크로드 수용 절차
랜딩존이 준비되면 신규 워크로드를 수용하는 표준 절차를 정립합니다.
- 워크로드 요청서 접수 (용도, 요구사항, 등급)
- 적절한 관리 그룹·구독 할당
- 신규 Spoke VNet 생성 및 Hub 연결
- RBAC 권한 부여
- 배포 승인 및 개발팀 인계
이 절차를 ServiceNow나 Jira 같은 ITSM 도구와 통합해 자동화하면 주간 10건 이상의 요청도 무리 없이 처리할 수 있습니다.
실전 배포 시 겪은 이슈
이슈 1: 관리 그룹 구조 변경의 어려움
관리 그룹 계층을 한 번 만들면 변경이 쉽지 않습니다. 특히 Policy Assignment가 많이 걸려 있으면 이동 자체가 오래 걸립니다. 초기 설계 시 향후 3~5년을 내다보고 구조를 잡아야 합니다.
이슈 2: Policy 과다 적용으로 배포 실패 연발
Deny 정책을 한꺼번에 적용하면 개발자들이 아무것도 배포하지 못합니다. 먼저 Audit 모드로 시작해 위반 현황을 파악하고, 점진적으로 Deny로 전환하는 것이 필수입니다.
이슈 3: IP 대역 부족
처음에 /22 정도로 작게 할당했다가 나중에 확장하려니 이미 다른 대역이 사용 중이어서 애를 먹은 경험이 있습니다. 엔터프라이즈 환경에서는 과하다 싶을 만큼 여유 있게 IP 대역을 잡는 것이 좋습니다.
랜딩존 배포 체크리스트
- 관리 그룹 계층 설계 및 배포 완료
- Platform 구독 분리 및 권한 설정
- Hub VNet 및 Gateway 배포
- Private DNS Zone 생성
- 필수 Azure Policy 적용 (Audit 모드)
- 중앙 Log Analytics Workspace 구성
- Tag 체계 정의 및 강제
- RBAC 역할 및 PIM 설정
- 첫 워크로드 수용 절차 문서화
- 운영 인수인계 및 교육
마무리
랜딩존은 한 번 잘 만들어 놓으면 이후 수년간 혜택을 봅니다. 반대로 대충 만들면 평생 고통의 원인이 됩니다. 조직의 규모와 특성을 반영해 신중하게 설계하고, Code로 관리해 재현 가능성을 확보하세요.