Microsoft AZ-400: 애자일 계획 및 작업 관리 — 학습 가이드

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

다음의 일부입니다: Microsoft DevOps Engineer Expert AZ-400 — 학습 가이드. 검증된 답안으로 연습하기: Microsoft 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.

개요

Azure DevOps의 Agile 계획 및 작업 관리는 명확한 데이터 모델, 잘 정립된 흐름 및 반복 방식, 그리고 팀 간 가시성을 중심으로 이루어집니다. Azure Boards는 강력한 작업 항목 유형 계층 구조와 팀별 유연한 구성을 제공하며, GitHub Projects는 Issues 및 Pull Requests와 긴밀하게 통합된 최신 자동화 기반 계획을 제공합니다. 효과적인 도입은 엄격한 정의(완료의 정의, 인수 기준), 일관된 추정(스토리 포인트 및 상대적 크기 조정), 그리고 실행 가능한 인사이트(쿼리, 제공 계획, DORA를 포함한 메트릭)에 달려 있습니다. 다음 섹션에서는 이러한 방식을 대규모로 설계, 구현 및 운영하는 방법을 자세히 설명합니다.

Azure Boards 데이터 모델, 프로세스 템플릿 및 팀 구성

작업 항목 유형과 계층 구조는 계획의 근간을 이룹니다. 기본 Agile 프로세스에서 포트폴리오 계층 구조는 Epic > Feature > User Story이며, Task와 Bug는 실행 수준 항목입니다. 자식 링크는 분해(User Story → Task)를 나타내며, Bug는 User Story와 동일한 백로그 수준에서 관리하거나 팀 정책에 따라 독립적으로 분류할 수 있습니다. 링크 유형은 필수적입니다:

부모/자식: 분해 계층 구조를 나타내고 진행률 및 작업량의 롤업을 주도합니다.
선행/후행: 작업 항목 간의 일정 및 종속성 관계를 표현하며, 이는 Delivery Plans에서 종속성 라인으로 표시됩니다.
관련/중복/차단됨: 비계층적 관계 및 장애물을 모델링합니다.
아티팩트 링크: 작업 항목을 코드(커밋, 브랜치, PR), 빌드, 릴리스에 연결하여 엔드투엔드 추적성을 지원합니다.

Azure DevOps 프로세스 템플릿은 상태, 필드, WIT 이름 지정을 정의합니다:

Agile: 요구 사항 수준 항목은 User Story이며, 빠르게 움직이는 팀이 주로 선택합니다.
Scrum: 요구 사항 수준 항목은 Product Backlog Item(PBI)이며, 스프린트와 Scrum 아티팩트가 핵심 요소이고 Bug는 PBI처럼 작동하도록 구성할 수 있습니다.
CMMI: 요구 사항 수준 항목은 Requirement이며, Change Request, Risk, Review를 위한 WIT를 포함합니다. 위험과 공식적인 검토를 추적해야 할 때 선택합니다.
사용자 지정(상속된) 프로세스: Azure DevOps Services에서는 상속을 통해 시스템 프로세스를 확장하여 서비스 호환성을 유지하면서 사용자 지정 WIT, 상태, 규칙, 필드를 추가할 수 있습니다. 범주를 사용하여 사용자 지정 WIT를 올바른 백로그 수준에 배치합니다. 보고 체계를 무너뜨리는 과도한 사용자 지정을 피하고, Story Points 및 Remaining Work와 같은 필드를 표준화해야 합니다.

팀은 다음을 통해 구성되는 경량 파티션입니다:

영역 경로: 소유권 범위 및 백로그 필터링을 지정합니다. 팀은 하나 이상의 영역 경로를 선택(선택적으로 하위 영역 포함)하여 ‘자신들의’ 작업을 정의합니다.
반복 경로: 릴리스 주기와 스프린트를 나타냅니다. 팀은 계획을 위해 기본 및 현재 반복을 선택합니다.
팀 백로그 및 보드: 각 팀은 다른 팀에 영향을 주지 않으면서 표시할 포트폴리오 수준(Epic, Feature), 카드 스타일, 열 매핑을 선택합니다.
팀 대시보드: Velocity, Burndown/Burnup, 누적 흐름 다이어그램(CFD), 리드/사이클 타임 차트, 사용자 지정 분석 뷰용 위젯을 사용하여 공유 가시성을 확보합니다.

Kanban 및 거버넌스를 통한 흐름 기반 제공

Azure Boards의 Kanban은 약속에서 완료까지의 지속적인 흐름을 모델링합니다. 워크플로 상태에 매핑되도록 열을 구성하고, 선택적으로 중요한 상태를 진행 중/완료 하위 열로 분할하여 처리량 계산을 개선하고 숨겨진 큐를 줄입니다. 열별 및 스윔레인별로 명시적인 WIP(진행 중인 작업) 한도를 설정하고 운영상 이를 강제합니다. 한도를 초과하면 조용히 백로그가 증가하는 대신 개선을 위한 대화가 시작됩니다. 전용 스윔레인(예: 긴급 처리)을 사용하여 우선순위가 높은 항목을 시각적으로 분리하고 해당 레인에 더 엄격한 WIP를 설정합니다.

완료의 정의(DoD)는 품질과 예측 가능성을 보장합니다. 이를 보드 정책, 특정 전환 시의 필수 필드 또는 체크리스트, 인수 테스트 연결로 구체화합니다. 예를 들어, 완료 상태로 이동하기 전에 통과한 Test Case에 대한 ‘테스트한 사람’ 링크를 요구하고, 릴리스됨 상태로 이동할 때 배포 확인 단계를 기록합니다.

분석을 사용하여 흐름 상태를 관리합니다:

누적 흐름 다이어그램은 WIP 평형을 검증하고 밴드가 확장될 때 병목 현상을 감지합니다.
리드 타임은 생성부터 완료까지의 경과 시간을 측정합니다. 사이클 타임은 활성 상태 진입부터 완료까지의 시간에 초점을 맞춥니다. 사이클 타임 차트 위젯은 작업 항목이 활성 상태로 전환된 후의 경과 시간을 보고하여 병목 현상 분석에 활용됩니다.
처리량 차트는 기간별로 완료된 항목을 추적하며, 안정성과 추세를 모니터링합니다.

이터레이션 계획, 백로그 상세화 및 속도 기반 예측

스프린트 계획은 우선순위를 시간 제한이 있는 약속으로 변환합니다. 스프린트 백로그는 이터레이션으로 가져온 PBI 또는 사용자 스토리를 나열하며, 이는 시간 단위의 남은 작업(Remaining Work)이 있는 작업(Task)으로 분해됩니다. 스프린트 용량(Sprint Capacity)을 사용하여 인력 가용성을 모델링합니다:

활동(개발, 테스트, UX)별 개인의 일일 용량(시간 단위).
공휴일 및 휴가를 반영하기 위한 개인 및 팀 휴무일.
작업을 활동과 연결하고 용량 대 계획된 작업을 검토하여 활동 수준의 부하를 분산합니다.

속도(Velocity)는 스프린트당 완료된 스토리 포인트를 요약합니다. 속도 차트를 사용하여 안정적인 범위를 설정하고 “포인트 인플레이션"을 방지하세요. 제품 백로그에서는 예측(Forecasting) 기능을 활성화하여 팀의 과거 평균 속도(최근 여러 스프린트 기반)와 이터레이션 길이를 기준으로 백로그를 소진하는 데 필요한 향후 이터레이션 수를 예측합니다. 부분적으로 완료된 작업을 제외하고 엄격한 완료 조건(DoD)을 유지하여 예측을 정확하게 유지하세요.

백로그 상세화(Backlog refinement)는 명확성과 상대적 크기 산정을 강제합니다:

인수 조건(Acceptance criteria): 작업 항목의 인수 조건 필드에 명확하고 테스트 가능한 설명을 기록합니다. 모호성을 줄이고 테스트 설계를 가속화하기 위해 Given-When-Then 형식을 선호합니다.
스토리 포인트: 요구사항 수준에서 상대적 복잡성과 불확실성을 추정합니다. 포인트를 시간으로 변환하지 마세요. 작업(Task)은 남은 작업(Remaining Work)을 가집니다.
상대적 추정(플래닝 포커): 공유된 기준선과 수열(피보나치 또는 수정된 피보나치)을 사용하여 빠르게 합의에 도달합니다. 팀은 마켓플레이스 확장 프로그램을 사용하여 Azure Boards 내에서 플래닝 포커를 실행하고, 일관된 보고를 위해 Story Points/Effort 필드에 추정치를 기록할 수 있습니다.

버그는 분류(triage)되어야 하며, 요구사항처럼 처리(포인트로 추정하고 백로그에서 계획)되거나 스프린트 내에서 작업으로 처리되어야 합니다. 속도를 일관되게 유지하기 위해 팀별로 하나의 정책을 선택하세요.

팀 간 계획, 쿼리, 보고, GitHub Projects 및 DevOps 메트릭

대규모 프로그램은 여러 팀과 리포지토리에 걸친 가시성을 필요로 합니다:

Delivery Plans: 영역/반복 경로로 필터링된 여러 팀의 타임라인을 생성합니다. 종속성 라인(선행/후행 링크에서 가져옴)과 마일스톤(릴리스 날짜, 외부 약속) 마커를 사용하여 반복별 작업을 시각화합니다. Feature 및 Epic에 대한 롤업 진행률을 표시하고 거버넌스 검토를 위해 사용자 지정 필드(예: Risk)를 노출합니다.
쿼리 및 보고: “이 필터와 일치하는 항목은 무엇인가"에 답하기 위한 플랫 목록 쿼리, 롤업과 함께 계층 구조를 탐색하기 위한 작업 항목 트리, 그리고 하나의 링크 홉(예: Feature → Stories 또는 Bug → commits)을 분석하기 위한 직접 링크 쿼리를 작성합니다. 쿼리를 저장 및 공유하고, 차트(파이, 막대, 추세)를 추가하고, 대시보드에 고정합니다. 분석 수준의 보고를 위해서는 Azure DevOps Analytics 서비스와 Power BI를 사용한 OData를 활용하여 포트폴리오 번다운, 종속성 위험 히트맵, DORA 시각화를 생성합니다. 내장된 보고서에는 Velocity, Burndown/Burnup, CFD, Lead Time, Cycle Time, Sprint Capacity 사용량이 포함됩니다.

GitHub Projects는 계획을 Issue 및 PR과 통합합니다:

프로젝트 보드: 조직 또는 리포지토리 범위에서 Kanban 또는 테이블 뷰를 생성하고, 사용자 지정 필드(상태, 반복, 우선순위)를 정의하며, 팀별로 필터링합니다.
자동화 규칙: Issue 또는 PR이 열리거나, 병합되거나, 닫힐 때 상태를 설정하고, 완료된 항목을 자동 보관하며, 필드 변경에 따라 할당 또는 레이블을 지정하고, 뷰 간에 항목을 이동하는 내장된 워크플로를 구성합니다. 고급 자동화를 위해 GitHub Actions와 결합합니다.
Issue 및 PR 통합: Issue와 PR은 Projects에서 일급(first-class) 항목입니다. PR 설명에 키워드(Fixes #123)를 사용하여 Issue를 연결하고 자동으로 닫습니다. 상태와 검토자가 보드에 표시되어 코드에서 계획까지의 추적성을 가능하게 합니다.

DevOps 메트릭은 코드, 배포, 결과를 연결해야 합니다:

DORA 메트릭:
- 배포 빈도: 일/주당 프로덕션 배포 횟수를 계산합니다. 파이프라인 릴리스 이벤트에서 데이터를 가져옵니다.
- 변경 리드 타임: 코드 커밋(또는 PR 병합)부터 프로덕션 배포까지 측정합니다. 파이프라인이 배포 타임스탬프를 내보내고 이를 커밋과 연관시키도록 보장합니다.
- 변경 실패율: 고객에게 영향을 미치는 인시던트나 롤백을 초래하는 프로덕션 배포의 비율입니다. 인시던트 관리 태그 및 파이프라인 결과와 통합합니다.
- 평균 복구 시간(MTTR): 인시던트 시작부터 서비스 복원까지의 경과 시간입니다. 모니터링 경고 및 인시던트 종료 시간에서 도출합니다. DORA를 보드 분석(Lead/Cycle time)과 연관시켜 계획과 배포 중 어느 쪽이 제약 조건인지 감지합니다. 대시보드를 사용하여 지속적인 개선을 위해 동일한 대상에게 두 메트릭 세트를 모두 표시합니다.

실제 문제 시나리오

Microsoft의 광고 부서는 공유 캠페인 관리 플랫폼을 제공하는 8개의 교차 기능 팀을 조율하고 있습니다. 코드베이스는 GitHub에 있으며, 이 조직은 도구 확산을 추가하지 않으면서 신뢰할 수 있는 분기별 약속, 명확한 종속성 가시성, 실행 가능한 플로우 및 DORA 메트릭을 필요로 합니다.

Azure DevOps Agile 프로세스를 선택하고 팀 구성

이유: Agile은 단순성과 포트폴리오 롤업의 균형을 맞추는 Epic > Feature > User Story 계층 구조를 제공합니다. 8개의 팀을 만들고 각 팀에 고유한 영역 경로와 현재/미래 반복 경로를 할당하여, 조직 전체의 보고 기능을 유지하면서 보드와 대시보드에서 자율성을 확보할 수 있습니다.

Kanban 거버넌스 및 보드 구성 정의

이유: 스프린트 간의 지속적인 흐름은 대기 시간을 줄입니다. ‘진행 중(In Progress)’ 및 ‘코드 검토(Code Review)‘에 대해 ‘진행 중(Doing)’/‘완료(Done)’ 분할이 있는 상태에 매핑된 열을 구성합니다. 열별로 WIP(Work In Progress) 제한을 설정하고 더 낮은 WIP를 가진 ‘긴급(Expedite)’ 스윔레인을 추가합니다. ‘완료(Done)‘로의 이동을 제어하기 위해 완료의 정의(Definition of Done: 단위 테스트 통과, PR 승인, 배포 확인 체크리스트 완료)를 명시하는 보드 정책을 추가합니다.

백로그 구체화 및 추정 원칙 구현

이유: 예측 가능한 약속을 위해서는 일관된 규모 산정과 명확성이 필요합니다. User Story에 Given-When-Then을 사용하여 인수 기준을 명시합니다. Azure Boards 확장을 사용하여 Planning Poker(피보나치 1–13)를 통해 Story Point를 표준화하고, Sprint Capacity를 지원하기 위해 작업 추정치는 ‘남은 작업(Remaining Work)’ 시간으로 유지합니다.

Capacity 및 Velocity 기반 예측을 통한 스프린트 계획

이유: Capacity 계획은 과도한 약속을 줄입니다. 활동 및 휴무일별로 개인의 Capacity를 입력합니다. 지난 6개 스프린트의 Velocity 차트를 사용하여 현실적인 스프린트 목표를 설정합니다. 백로그 예측(Forecasting) 기능을 활성화하여 분기별 Epic 목표에 도달하는 데 필요한 스프린트 수를 예측하고 이해관계자의 기대치를 조정합니다.

팀 간 가시성을 위한 Delivery Plans 수립

이유: 종속성과 마일스톤은 단일 타임라인에서 보여야 합니다. 8개 팀 모두와 포트폴리오 수준을 포함하는 Delivery Plan을 생성합니다. 분기별 릴리스 날짜와 시장 이벤트를 위한 마일스톤 마커를 추가합니다. 선행/후행(Predecessor/Successor) 링크를 사용하여 종속성 라인을 표시하고, 항목이 여러 반복에 걸쳐 있을 때의 위험을 드러냅니다.

리포지토리 중심 실행 뷰를 위한 GitHub Projects 통합

이유: 개발자들은 GitHub에서 작업합니다. Projects는 실행 컨텍스트를 코드 가까이에 둡니다. 보드 및 테이블 뷰가 있는 조직 수준의 GitHub Project를 생성합니다. PR이 열리면 상태를 ‘진행 중(In Progress)‘으로, PR이 병합되면 ‘완료(Done)‘로 설정하고, 닫힌 Issue를 자동으로 보관하는 자동화 규칙을 추가합니다. PR에서 “Fixes #<id>“를 사용하여 연결된 Issue를 닫고 상태를 보드에 다시 반영합니다.

추적성을 위해 코드와 작업 연결

이유: 엔드투엔드 추적성은 정확한 보고 및 감사를 가능하게 합니다. 커밋 메시지와 PR 설명에 Azure Boards 작업 항목 ID를 참조하도록 강제합니다. 작업 항목에 아티팩트 링크를 사용하여 Delivery Plans 및 분석이 코드 활동으로부터 진행 상황을 롤업할 수 있도록 합니다.

대시보드에 플로우 및 DORA 메트릭 계측

이유: 공유되고 자동화된 메트릭은 개선을 주도합니다. 팀 대시보드에는 CFD, Lead Time, Cycle Time 차트를 고정하여 흐름을 관리합니다. 프로그램 대시보드에는 Velocity, Delivery Plan 요약, DORA 메트릭을 표시합니다. 프로덕션 스테이지의 파이프라인 배포 이벤트를 사용하여 배포 빈도와 리드 타임을 계산하고, 인시던트를 태깅하고 배포와 연관시켜 변경 실패율과 MTTR을 도출합니다. 이 통합된 뷰는 제약 조건이 계획(보드 리드/사이클 타임)에 있는지 아니면 배포(DORA)에 있는지를 강조합니다.

이 접근 방식은 팀 자율성(팀별 보드, Capacity, 대시보드)과 프로그램 거버넌스(Delivery Plans, 종속성, 마일스톤) 사이의 균형을 맞춥니다. Azure Boards는 계층적 계획 및 분석을 제공하고, GitHub Projects는 Issue 및 PR에 연결된 자동화를 통해 일상적인 개발자 추적을 간소화하며, DORA 메트릭은 신뢰할 수 있는 데이터 기반 약속을 위해 계획과 운영 결과를 연결합니다.

← 패키지 관리 및 아티팩트 관리 · 모든 도메인

이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →