90DaysOfDevOps (Day 70)

고태규·2026년 1월 11일

devops

DevOps

목록 보기

65/75

해당 스터디는 90DaysOfDevOps
https://github.com/MichaelCade/90DaysOfDevOps
를 기반으로 진행한 내용입니다.

Day 70 - Simplified Cloud Adoption with Microsoft's Terraforms Azure Landing Zone Module

1. CAF와 WAF

클라우드 도입은 단순히 가상 머신 하나를 생성하는 것으로 끝나지 않는다.

엔터프라이즈 환경에서는 보안, 거버넌스, 확장성을 고려한 견고한 기반이 필수적이다.

따라서, 이러한 환경을 구축하기 위해 가장 먼저 접하게 되는 두 가지 프레임워크가 있는데
바로 CAF(Cloud Adoption Framework)와 WAF(Well-Architected Framework)이다.

이 둘은 일부 겹치는 부분이 있어 혼동하기 쉽지만 명확한 차이가 있다.

CAF (Cloud Adoption Framework):
- 클라우드 도입의 전체 여정을 다룬다.
- 전략 수립, 계획, 환경 구축, 채택, 거버넌스, 관리 등 조직이 클라우드를 도입하는 거시적인 프로세스다.
- 조직이 클라우드 기술을 시작하는 데 도움이 되는 일련의 모범 사례, 도구 및 지침
- 조직이 워크로드를 클라우드로 이전할 때 위험을 식별 및 완화하고 비용을 관리하며 규정 준수를 보장하는 데 도움이 된다.
WAF (Well-Architected Framework):
- 환경 위에서 구동되는 개별 워크로드에 집중한다.
- 단일 애플리케이션의 보안 강화, 비용 최적화, 성능 효율성 등 지속적인 개선을 목표로 한다.

해당 프레젠테이션에서 다룰 핵심 내용은 CAF의 여러 단계 중 준비 단계이다.

이는 애플리케이션을 마이그레이션하기 전, 환경을 구축하고 랜딩 존을 준비하는 과정을 의미한다.

2. 랜딩존이란?

랜딩 존(Landing Zone)이란 워크로드(애플리케이션, 데이터 등)가 클라우드 환경에 배포되기 전, 보안, 네트워크, 거버넌스 등이 사전에 프로비저닝된 격리된 클라우드 환경을 의미한다.

이는 단순한 리소스 집합이 아니라, 기업의 IT 정책과 컴플라이언스를 IaC로 구현한 표준화된 아키텍처 프레임워크이다.

2-1. 랜딩 존의 기술적 목적

클라우드 도입 초기 단계에서 발생하기 쉬운 수동 구축방식은 리소스가 증가함에 따라 관리 불가능한 상태(Brownfield)를 초래한다.

랜딩 존은 이러한 기술 부채를 방지하기 위해 존재하며, Azure뿐만 아니라 AWS(Control Tower), GCP(Foundation) 등 모든 엔터프라이즈 클라우드 플랫폼에서 공통적으로 요구하는 선결 요건이다.

2-2. 랜딩 존을 구성하는 4대 기술

성공적인 랜딩 존은 특정 벤더에 종속되지 않는 4가지 핵심 인프라 영역이 사전에 코드로 정의되어야 한다.

ID 및 접근 관리 (Identity and Access Management):
- 중앙 집중식 인증 및 권한 부여 체계를 구축한다 (예: Azure AD, Entra ID).
- RBAC(Role-Based Access Control) 모델을 통해 개발자, 운영자, 보안 관리자의 권한을 분리하고 최소 권한 원칙을 시스템 레벨에서 강제한다.
네트워크 토폴로지 (Network Topology):
- 온프레미스와 클라우드 간의 하이브리드 연결(VPN, ExpressRoute) 및
  인터넷 인바운드/아웃바운드 트래픽 흐름을 정의한다.
- 일반적으로 허브 앤 스포크(Hub and Spoke) 아키텍처를 채택하여, 중앙 허브 네트워크가 방화벽과 공유 서비스를 관리하고, 스포크 네트워크에 개별 워크로드를 배치하여 격리성을 확보한다.
보안 및 거버넌스 (Security & Governance):
- 조직의 규정 준수 요건을 정책 형태로 코드화하여 배포한다 (예: Azure Policy, AWS SCP).
- 데이터 암호화 강제, 특정 리전 배포 제한, 공용 IP 차단 등의 가드레일을 적용하여, 사용자가 보안 정책을 위반하는 리소스를 생성할 수 없도록 원천 차단한다.
관리 및 모니터링 (Management & Monitoring):
- 분산된 모든 구독/계정의 로그와 메트릭을 중앙 저장소(Log Analytics Workspace 등)로 집계한다.
- 비용 가시성을 확보하고, 이상 징후 발생 시 즉각적인 알림이 가능한 관제 시스템을 포함한다.

2-3. 아키텍처 분리 전략

랜딩 존 아키텍처의 핵심은 기능적 분리에 있다. 이를 통해 확장성과 안정성을 동시에 확보한다.

플랫폼 랜딩 존 (Platform Landing Zones):
- 중앙 IT 팀이 관리하는 영역이다.
- ID, 관리(로깅/모니터링), 연결성(네트워크 허브)과 같은 공유 서비스가 배치된다.
애플리케이션 랜딩 존 (Application Landing Zones):
- 실제 비즈니스 애플리케이션이 구동되는 영역이다.
- 플랫폼 랜딩 존과는 논리적으로 분리된 별도의 구독(Subscription) 또는 계정으로 생성된다.
- 구독 벤딩 자동화를 통해, 새로운 프로젝트나 팀이 생성될 때마다 표준화된 정책이 적용된 구독을 무제한으로 복제하여 제공한다.

결론적으로 랜딩 존은 마이그레이션 대상이 안착할 수 있는 불변의 인프라 기반을 제공함으로써, 이후 배포되는 모든 워크로드가 자동으로 보안 및 운영 표준을 준수하도록 보장하는 기술적 토대이다.

3. Terraform을 활용한 랜딩 존 구축 방법

랜딩 존을 구축하는 방법에는 Azure Portal, Bicep, Terraform 등이 있다.

포털은 배포 내용을 파악하기 어려운 블랙박스와 같아 권장하지 않으며, 해당 프레젠테이션에서는 Terraform을 중점적으로 다룬다.

3-1. 랜딩 존 도입초기의 어려움

Azure 랜딩 존을 위한 Terraform 모듈은 아키타입(Archetypes), 연결성, ID, 관리 등으로 세분화되어 제공된다.

GitHub의 Wiki를 통해 기본부터 허브 앤 스포크 네트워크까지 단계별 가이드를 볼 수 있다.

하지만 문서의 양이 방대하고 예제가 복잡하여 처음부터 직접 코드를 짜는 것은 진입 장벽이 높다.

3-2. 해결책: Azure Landing Zone Terraform Accelerator

이 복잡함을 해결하기 위해 CAF 팀은 Azure Landing Zone Terraform Accelerator를 제공한다.

이는 복잡한 초기 설정을 자동화해 주는 도구다.

액셀러레이터 (Accelerator)란, 클라우드 인프라르 처음부터 IaC로 작성하는 것은 매우 복잡하기 때문에 이를 해결하기 위해 등장한 개념이다.

AWS (Landing Zone Accelerator), Google Cloud (Fabric) 등 주요 클라우드 벤더들이 공통적으로 사용하는 이 용어는 이제 업계의 사실상 표준(De Facto Standard)으로 자리 잡았다.

액셀러레이터란 방대한 기술 문서와 이론으로 존재하는 프레임워크 (CAF)를 실행 가능한 코드 형태로 패키징하여, 초기 구축 단계를 비약적으로 단축시켜 주는 자동화 도구이자 부트스트래핑 솔루션을 의미한다.

Microsoft CAF 팀 역시 이러한 접근 방식을 채택하여 Azure Landing Zone Terraform Accelerator를 제공한다.

작동 원리 및 사용법
- 액셀러레이터는 복잡한 초기 설정을 자동화하여 사용자에게 준비된 코드를 배달해 준다.
- 입력값: 사용자는 GitHub 개인 액세스 토큰 (PAT)과 최소 3개의 구독 정보 (ID, 연결성, 관리)만 입력하면 된다.
- 옵션 선택: 조직의 규모와 요구사항에 따라 Basic, Standard Networking, Complete 중 하나를 선택하여 스크립트를 실행한다.
- 결과물: 스크립트 실행이 완료되면 사용자의 GitHub에 새로운 리포지토리가 생성되며, 그 안에는 즉시 배포 가능한 Terraform 코드(main.tf, config.yaml 등)가 생성되어 있다.
액셀러레이터의 핵심 역할: 투명성 확보
- Portal을 통한 배포는 클릭 몇 번으로 끝나지만, 내부에서 어떤 리소스가 어떻게 연결되는지 알 수 없는 블랙박스와 같다.
- 반면, 액셀러레이터는 글래스 박스(Glass Box) 접근 방식을 취한다.
- 코드 가시성: 생성된 코드가 내 리포지토리에 저장되므로, 인프라의 모든 구성 요소를 눈으로 직접 확인할 수 있다.
- 커스터마이징: 자동 생성된 코드는 수정 불가능한 결과물이 아니다. 예를 들어, BGP 설정이 불필요하다면 생성된 Terraform 코드에서 해당 모듈을 주석 처리하거나 제거하는 등 즉각적인 수정이 가능하다.

결론적으로 Azure Landing Zone Terraform Accelerator는 완벽한 최종 제품을 던져주는 것이 아니라, 사용자가 마음대로 커스텀할 수 있는 최적의 코드 Baseline을 제공함으로써, 맨땅에서 시작하는 막막함을 해소하고 구축 속도를 가속화하는 핵심 도구이다.

4. Production 준비를 위한 Customizing

액셀러레이터로 배포된 랜딩 존은 배관과 전기 공사만 끝난 상태다.

실제 운영을 위해서는 각 조직에 맞는 커스터마이징이 필요하다.

4-1. 필수 구현 요소

구독 벤딩(Subscription Vending): 새로운 구독 요청 시, PR 하나로 정책과 네트워크가 설정된 구독을 자동으로 생성하는 자동화 시스템 구축
액션 그룹 및 Azure Advisor 연동: 각 구독마다 액션 그룹을 생성하고 Azure Advisor 알림을 연결하여, 워크로드 소유자가 직접 비용, 보안, 성능 이슈를 인지하도록 설정
태그 상속(Tag Inheritance): Azure 리소스 중 수동 태깅이 가능한 것은 약 30%에 불과하다. Azure Policy를 통해 리소스 그룹의 태그를 하위 리소스가 상속받도록 강제하여 비용 관리를 투명하게 한다.
기본 가드레일: Budget 설정, 필수 보안 정책 적용 등을 통해 치명적인 실수나 비용 과다 발생을 방지한다.

4-2. 유용한 도구 및 리소스

멀티 테넌트 가이드: Microsoft 문서에서 제공하는 멀티 테넌트 구축 가이드는 매우 간결하고 정확하므로 이를 따른다.
AzGovViz (Azure Governance Visualizer): 현재 배포된 정책 상태, 상속 관계 등을 시각화해 주는 도구다. 특히 기존 환경에서 정책을 변경하기 전 분석용으로 필수적이다.
Azure Monitor Baseline Alerts (AMBA): 모니터링을 위해 무엇을 설정해야 할지 고민할 필요 없다. 해당 리포지토리는 Microsoft 제품 팀들이 기여한 모니터링 모범 사례와 정책을 제공한다. patterns.alz 폴더를 참고하여 정책을 가져다 쓰면 된다.
FastTrack Review Checklist: Microsoft FastTrack 팀 (클라우드 마이그레이션 전문가 그룹)이 사용하는 검토 체크리스트를 활용하여, 라이브 배포 전 누락된 사항이 없는지 검증한다.

5. 정리

클라우드 도입의 성패는 워크로드를 안정적으로 수용할 그릇인 랜딩 존의 완성도에 달려 있다.

Azure, AWS, GCP 등 플랫폼을 막론하고 ID, 네트워크, 보안 거버넌스가 사전에 IaC로 정의된 격리 환경은 선택이 아닌 필수다.

따라서 맨땅에서 모든 것을 직접 구축하기보다는, 각 벤더가 표준으로 제공하는 액셀러레이터를 활용해 기술 부채 없는 명확한 Baseline을 신속하게 확보해야 한다.

처음부터 완벽한 설계를 고집하기보다 자동화된 도구로 핵심 인프라를 먼저 구축하고, 이후 조직의 특성에 맞춰 정책을 지속적으로 고도화해 나가는 것이 가장 효율적이다.

이러한 접근 방식은 확장성과 보안을 동시에 담보하며, 성공적인 엔터프라이즈 클라우드 환경으로 나아가도록 돕는다.

6. 개인적인 정리: 스타트업에게 랜딩존은?

많은 엔지니어와 의사결정권자가 "랜딩 존이나 액셀러레이터는 복잡한 컴플라이언스가 필요한 대기업의 전유물"이라고 오해한다.

스타트업은 빠르게 개발해서 배포하기도 바쁜데, 언제 거버넌스를 구축하고 있냐는 것이다. 하지만 클라우드 엔지니어링의 트렌드는 정반대로 흐르고 있다.

6-1. 스타트업이 액셀러레이터를 써야 하는 진짜 이유: '인력 대체'

대기업은 수십 명의 클라우드 아키텍트가 모여 며칠이고 회의를 하며 랜딩 존을 커스텀한다.

반면, 중소/스타트업은 인프라 담당자가 1명이거나, 개발자가 인프라까지 겸업(DevOps)하는 경우가 많다.

바로 이 지점에서 액셀러레이터의 진가가 발휘된다.

전문성 아웃소싱: 액셀러레이터는 Microsoft나 AWS의 수석 아키텍트들이 검증한 코드를 모아놓은 것이다. 이를 사용한다는 것은 전담 아키텍트 팀을 무료로 고용하는 것과 같은 효과를 낸다.
시간 단축: 맨땅에서 보안 설정을 하나하나 검색하며 구축하려면 몇 주가 걸리지만, 액셀러레이터의 Basic 옵션을 돌리면 30분 만에 보안이 적용된 기본 환경이 나온다.

즉, 스타트업에게 액셀러레이터는 이상적인 아키텍처를 위한 도구가 아니라, 부족한 맨파워를 기술로 메우는 효율화 도구다.

6-2. 대기업 vs 스타트업: 사용 패턴의 차이

두 그룹 모두 액셀러레이터를 사용하지만, 그 활용 방식은 확연히 다르다.

구분	대기업 (Enterprise)	중소/스타트업 (SMB/Startup)
접근 방식	Heavy Customization	Out-of-the-Box (그대로 사용)
목표	기존 사내 레거시 규정 준수 및 복잡한 하이브리드 연결	빠르고 안전한 클라우드 진입 및 기술 부채 최소화
액셀러레이터 활용	생성된 코드를 기반으로 50% 이상 뜯어고침	생성된 코드를 90% 이상 그대로 사용 (Basic/Standard 옵션)
네트워크	복잡한 허브 앤 스포크, 전용선(ExpressRoute) 연결	단순한 허브 앤 스포크 또는 단일 VNet 구조

스타트업은 액셀러레이터가 제공하는 기본값을 업계 표준으로 받아들이고, 별도의 수정 없이 그대로 사용하는 것이 가장 효율적이다.

6-3. 클릭 옵스 (Click-Ops)의 함정과 기술 부채

"일단 콘솔(포털)에서 클릭해서 빠르게 만들고 나중에 고치자"는 생각은 스타트업이 가장 경계해야 할 함정이다. 이를 클릭 옵스(Click-Ops)라 부른다.

현실: "나중에 고치자"는 순간은 절대 오지 않는다.
결과: 서비스가 성장해 트래픽이 터지는 순간, 구조적 한계로 인해 서버를 늘리지 못하거나 보안 사고가 발생한다. 이때 아키텍처를 변경하려면 서비스를 중단하고 대공사를 해야 한다.

액셀러레이터를 통해 초기에 IaC로 기반을 잡아두면, 나중에 서비스가 커졌을 때 변수 몇 개만 수정(예: env: prod, scale: large)하여 인프라를 확장할 수 있다.

6-4. 결론

과거에는 랜딩 존 구축에 높은 비용과 전문 컨설팅이 요구되었으나, 최근에는 Terraform Accelerator와 같은 자동화 도구의 등장으로 접근성이 크게 향상되었다.

이제 스타트업에게도 랜딩 존은 더 이상 먼 미래의 이야기가 아니며, 액셀러레이터를 활용해 표준화된 환경을 빠르게 구성하여 초기 개발 효율을 높일지, 아니면 필요한 부분부터 수동으로 구축해 나갈지에 대한 선택의 문제이다.

다만, 초기 구축 속도와 향후 발생할 수 있는 기술 부채 관리 측면을 고려한다면, 액셀러레이터 활용은 리소스가 제한적인 조직에게 충분히 합리적인 접근 방식임이 확실하다.

고태규

이전 포스트

90DaysOfDevOps (Day 69)

다음 포스트