AZ-400 시험에서 CI/CD 파이프라인 파트는 코드가 개발자 로컬을 떠나 프로덕션에 도달하기까지의 자동화 과정을 어떻게 설계하는지를 묻습니다. Azure Pipelines와 GitHub Actions의 기능 차이, YAML 구조, 트리거 필터링, 재사용 메커니즘, 러너 선택 기준이 핵심입니다. 두 플랫폼 모두 Microsoft 생태계에 속하지만 철학이 달라서 시험은 '이 상황에 어느 쪽을 쓰겠는가'를 반복해서 묻습니다. 정답은 항상 상황 조건 안에 있습니다.
CI와 CD — 조립 라인에 센서를 달다
자동차 공장 조립 라인에서 부품이 검수 없이 그냥 다음 공정으로 넘어간다면, 문제는 완성차 검사에서야 드러납니다. 10명이 동시에 같은 코드를 수정하다 월요일에 합쳐보니 충돌투성이라면? CI(Continuous Integration)는 코드를 합칠 때마다 자동으로 빌드와 테스트를 돌려 '통합 지옥'을 막습니다.
CD는 두 가지입니다. Continuous Delivery는 검증된 산출물을 스테이징까지 자동 전달하되 수동 승인 게이트를 남겨둡니다. Continuous Deployment는 승인 없이 프로덕션까지 자동 배포합니다. 시험에서 두 개념의 차이가 나오면 수동 승인이 남아 있으면 Delivery, 없으면 Deployment입니다.
Azure Pipelines vs GitHub Actions — 선택 기준
두 매장이 나란히 있습니다. 하나는 대형 백화점 안의 엔터프라이즈 전문관(Azure Pipelines), 하나는 개발자 커뮤니티 한가운데 있는 편집숍(GitHub Actions)입니다. 어느 쪽을 고를지는 이미 무엇을 가지고 있느냐에 달려 있습니다.
Azure Pipelines는 Azure DevOps 플랫폼의 일부로 Azure Repos, Azure Boards, Azure Artifacts와 통합됩니다. Bitbucket, GitHub, GitHub Enterprise, Azure Repos를 모두 소스로 연결해 특정 Git 호스팅에 종속되지 않습니다. deployment group, variable group, service connection, multi-stage 파이프라인이 내장되어 있습니다.
GitHub Actions는 GitHub 저장소와 완전 통합된 워크플로 자동화 플랫폼입니다. YAML 파일로 정의하고 GitHub Marketplace의 15,000개 이상 Action을 활용합니다. push, pull_request, schedule, workflow_dispatch 등 GitHub 이벤트 전체를 트리거로 씁니다.
| 상황 | 추천 | |------|------| | 소스가 GitHub, 오픈 소스 환경 | GitHub Actions | | Azure DevOps 기존 도입, Git 호스팅 독립 | Azure Pipelines | | 온프레미스 소스 | Azure Pipelines | | PR 기반 검증 워크플로 중심 | GitHub Actions |
!Azure Pipelines vs GitHub Actions
YAML 구조와 트리거
레스토랑 주방을 떠올려보세요. 주문이 들어오면 전채 → 메인 → 디저트 파트가 순서대로 일하고, 각 파트 안에서는 여러 요리사가 동시에 움직입니다. CI/CD 파이프라인의 계층 구조가 이와 같습니다.
Azure Pipelines YAML은 계층입니다. Stage는 빌드·테스트·배포 같은 논리 단계, Job은 에이전트 위의 실행 단위, Step은 Script 또는 Task 형태의 개별 명령입니다. GitHub Actions는 구조로 Stage 없이 키워드로 Job 간 의존성을 표현합니다.
트리거는 Azure Pipelines에서 (브랜치 push), (Pull Request), (정기 실행)로 구분하고, GitHub Actions에서는 하위에 이벤트를 나열합니다. 필터는 모노레포에서 특정 경로 변경에만 파이프라인이 실행되도록 좁힙니다. 글롭 패턴에서 는 건넙니다. 는 에 매칭되지만 는 안 됩니다.
이 없으면 Job은 기본 병렬 실행입니다. 는 이전 단계가 실패해도 실행하고, 는 취소 상태만 제외합니다. 테스트 결과 게시처럼 반드시 실행해야 하는 Step에는 를 씁니다.
재사용 — 템플릿, 재사용 워크플로, environment
회사 공문 양식처럼, 파이프라인 공통 단계를 매번 처음부터 쓰는 대신 중앙 파일에 정의하고 불러 씁니다.
Azure Pipelines 템플릿은 별도 YAML 파일로 Stage·Job·Step·Variable을 정의하고 키워드로 참조합니다. 템플릿 저장소를 별도 운영할 때는 블록으로 연결하고, 또는 커밋 SHA로 버전을 고정합니다. 메인 브랜치를 직접 참조하면 검증 전 변경이 모든 프로덕션 파이프라인에 즉시 전파됩니다.
GitHub Actions의 reusable workflow는 이벤트로 호출하고 ·로 매개변수를 받습니다. composite action은 여러 Step을 하나의 Action으로 패키징합니다.
environment는 배포 대상을 논리적으로 표현합니다. Job과 연결해 배포 이력을 추적하고, approvals·required template check·pipeline permissions·business hours check를 환경마다 독립 설정합니다. 특정 파이프라인만 프로덕션에 배포하도록 제한하려면 environment pipeline permissions를 씁니다. service connection security는 연결 자체의 사용 주체를 제한하므로 목적이 다릅니다. variable group을 Azure Key Vault와 연결하면 시크릿이 런타임에 동적으로 로드되어 YAML에 평문으로 남지 않습니다.
러너 선택 — Microsoft-hosted vs Self-hosted
렌터카(Microsoft-hosted runner)를 빌리면 정비·보험을 렌터카 회사가 처리하지만, 사옥 지하주차장에만 들어가는 특수 차량은 직접 소유해야 합니다(self-hosted runner). 어느 쪽이 낫냐는 어디에 가야 하느냐에 달려 있습니다.
Microsoft-hosted runner는 매 빌드마다 새 VM을 프로비저닝하고 완료 후 폐기합니다. OS 패치·가용성을 Microsoft가 관리합니다. Windows Server, Ubuntu, macOS 이미지를 선택할 수 있고 빌드 도구가 사전 설치되어 있습니다. 단, 사내 네트워크 리소스에는 직접 접근할 수 없습니다.
Self-hosted runner는 조직이 직접 관리하는 머신에 설치해 방화벽 내 리소스에 접근합니다. 에이전트는 Azure DevOps에 아웃바운드 HTTPS 443 풀(pull) 방식으로 연결해 인바운드 방화벽 규칙이 필요 없습니다. Scale set agent는 VM Scale Set 기반으로 에이전트 수를 빌드 큐에 맞게 자동 조정합니다. Container jobs는 self-hosted runner 위에서 각 Job을 지정된 Docker 이미지 안에서 실행해 의존성을 격리합니다.
시험 핵심 정리
"소스가 GitHub, 오픈 소스 환경" -- GitHub Actions "Azure DevOps 기존 도입, Git 호스팅 독립" -- Azure Pipelines vs -- 는 단일 세그먼트만 "테스트 실패해도 결과 게시 필요" -- "이전 Stage 없이 즉시 실행" -- "특정 파이프라인만 프로덕션 배포 허용" -- environment pipeline permissions (service connection security 아님) "시크릿을 YAML에 저장하지 않으려면" -- variable group + Azure Key Vault 연동 "템플릿 변경이 프로덕션에 바로 전파되지 않게" -- 태그 또는 커밋 SHA로 버전 고정 "사내 네트워크 리소스 접근 필요" -- self-hosted runner "운영 오버헤드 최소화, 자동 확장" -- Microsoft-hosted runner 또는 scale set agent "reusable workflow 호출 트리거" -- 이벤트 CI = 매 커밋마다 빌드·테스트 자동화 / CD Delivery = 스테이징까지 자동 + 수동 승인 / CD Deployment = 프로덕션까지 완전 자동