AZ-400 시험에서 작업 추적과 메트릭 파트는 '어떤 도구로 어떤 흐름을 설계하는가'를 묻습니다. Azure Boards 안에서 Epic부터 Task까지 어떻게 나뉘는지, GitHub Issues와 어떻게 연결되는지, 그리고 팀의 생산성을 숫자로 보여주는 DORA 메트릭이 무엇인지가 핵심입니다. 이 영역은 단순 암기보다 '왜 이 도구를 고르는가'를 이해하면 빠르게 정리됩니다.
작업 항목 계층, 어디까지 쪼개야 할까
건물을 짓는다고 생각해 보세요. 전체 건물 프로젝트가 있고, 1층·2층 같은 단위로 나뉘고, 각 층에는 방마다 작업 목록이 생깁니다. Azure Boards의 작업 항목 계층도 이와 같습니다. 가장 큰 단위는 이고, 그 아래 , 팀이 한 스프린트 안에서 완료할 수 있는 , 그리고 개발자 단위 작업인 와 로 내려갑니다.
이 계층은 프로세스 템플릿마다 명칭이 조금씩 다릅니다. 템플릿은 User Story를, 템플릿은 Product Backlog Item(PBI)을 팀 단위 작업으로 사용합니다. 템플릿은 Change Request, Requirement, Risk, Review를 기본 work item으로 제공하는 유일한 템플릿으로, ISO 9001 같은 감사 요건이 있는 조직에 어울립니다. 템플릿은 Issue와 Task만 있어 소규모 팀이 빠르게 시작할 때 씁니다.
시험에서 '팀 자율성과 스프린트 추적' 시나리오가 나오면 Agile 템플릿의 User Story를, '규제 기관 감사 대비'라면 CMMI 템플릿을 떠올리면 됩니다.
보드, 백로그, 스프린트 — 세 가지 뷰의 역할
회사 창고에 재고가 쌓여있는데 어떤 물건이 어디에 있는지 모른다면 어떻게 될까요? 배송 담당자는 혼란스럽고, 구매팀은 이미 있는 물건을 또 주문합니다. Azure Boards의 세 가지 뷰는 팀 작업을 같은 이유로 다르게 보여줍니다.
뷰는 Kanban 방식입니다. 칸 사이를 이동하는 카드로 작업 상태를 한눈에 봅니다. 각 칸(컬럼)에 WIP(Work in Progress) 제한을 걸어 한꺼번에 너무 많은 작업이 진행되는 것을 막을 수 있습니다.
뷰는 우선순위가 매겨진 전체 작업 목록입니다. 팀이 다음에 무엇을 할지 결정하는 기반이 됩니다. Sprint Backlog는 현재 스프린트에 할당된 작업만 필터링해서 보여줍니다.
는 조건을 걸어 work item을 필터링하는 기능입니다. 같은 쿼리를 저장해 두면 팀원이 빠르게 자신의 작업 목록을 확인할 수 있고, 쿼리 결과를 대시보드 위젯으로 붙여둘 수도 있습니다.
work item 상태 흐름도 시험에 자주 나옵니다. Agile 기준으로 순서입니다. 코드를 merge했지만 QA 검증이 남아있다면 , 모든 검증이 끝나면 입니다. Sprint velocity는 항목만 계산에 포함합니다.
GitHub Issues와 AB연결
개발자가 코드를 짜는 곳은 GitHub입니다. 이슈와 코드가 같은 공간에 있으면 컨텍스트 전환 없이 흐름을 이어갈 수 있습니다. GitHub Issues + GitHub Projects 조합이 그 역할을 합니다. GitHub Projects는 Issues를 Board·Table·Roadmap 세 가지 뷰로 시각화하는 Kanban 레이어입니다.
Azure DevOps와 GitHub을 함께 쓰는 조직에서는 멘션이 핵심입니다. GitHub commit 메시지나 PR 본문에 를 넣으면 PR이 병합될 때 Azure Boards의 해당 work item 상태가 자동으로 로 바뀝니다. 반대로 Azure Boards work item 안에서는 GitHub PR 링크가 자동으로 표시됩니다. 이 양방향 연결이 추적성(traceability)의 핵심 메커니즘입니다.
어떤 도구를 선택할지는 팀 구성에 달렸습니다. GitHub 중심 개발팀이라면 GitHub Issues + Projects가 자연스럽고, Azure DevOps를 이미 쓰는 조직이라면 Azure Boards가 더 강력한 계층 구조와 쿼리를 제공합니다.
DORA 4대 메트릭 — 팀 건강을 숫자로
병원에서 환자 상태를 확인할 때 혈압·체온·맥박 같은 지표를 씁니다. 감이 아니라 측정 가능한 숫자로 상태를 판단하는 것입니다. DORA 4대 메트릭은 DevOps 팀 건강을 같은 방식으로 측정합니다.
는 팀이 얼마나 자주 프로덕션에 배포하는지입니다. 하루 여러 번이면 Elite, 주 1회면 Low 수준입니다.
는 코드 커밋이 프로덕션까지 도달하는 데 걸리는 시간입니다. 코드 작성부터 배포까지의 전체 사이클을 봅니다. 이 시간이 짧을수록 팀이 빠르게 가치를 전달합니다.
는 장애 발생 후 서비스가 복구되기까지 걸리는 평균 시간입니다. Elite 수준은 1시간 미만입니다.
는 배포 중 장애·롤백·핫픽스가 필요한 비율입니다. 배포 100번 중 몇 번이 문제를 일으켰는지를 봅니다. 낮을수록 좋습니다.
이 네 지표는 쌍으로 기억하면 쉽습니다. 와 은 '얼마나 빠른가(속도)', 과 는 '얼마나 안정적인가(안정성)'를 각각 나타냅니다. 좋은 DevOps 팀은 속도와 안정성을 동시에 잡습니다.
!DORA의 4가지 지표
대시보드 설계 — 숫자를 보이게 만들기
아무리 좋은 데이터도 눈에 보이지 않으면 의미가 없습니다. 차량 계기판이 속도와 연료 상태를 운전자에게 실시간으로 보여주듯, Azure DevOps Dashboards는 팀 메트릭을 한 화면에 모아줍니다.
Azure DevOps Dashboards는 위젯 기반입니다. 위젯, 위젯, work item 쿼리 결과 위젯 등을 조합해 팀 상황판을 만듭니다. 쿼리 위젯은 앞서 만든 Query 결과를 그대로 가져오기 때문에, 잘 설계된 Query가 대시보드 품질을 좌우합니다.
대시보드 생성·관리에는 권한이 필요합니다. 팀원(Contributors)은 대시보드를 조회할 수 있지만 위젯을 추가하거나 레이아웃을 변경할 수는 없습니다. Stakeholder 액세스 레벨은 일부 위젯에 제한이 있습니다.
GitHub 기반 팀은 GitHub Insights를 활용합니다. Pull Request 사이클 타임, 리뷰 반응 시간 같은 지표를 레포지토리 단위로 제공합니다. Azure DevOps Dashboards가 조직 전체 뷰를 제공한다면, GitHub Insights는 레포지토리 레벨 개발 흐름에 초점을 맞춥니다.
시험 핵심 정리
"팀 단위 스프린트 추적, 비즈니스 가치 최소 단위" -- Agile 템플릿의 User Story
"규제 감사 요건, Change Request·Risk 공식 추적" -- CMMI 템플릿
"WIP 제한 설정 가능한 뷰" -- Board (Kanban)
"Sprint velocity 계산에 포함되는 상태" -- Closed
"GitHub 커밋/PR → Azure Boards work item 자동 연결" -- AB#<id> 멘션 (예: fixes AB#1234)
"코드 커밋 → 프로덕션 도달까지의 시간" -- Lead Time for Changes
"장애 발생 후 서비스 복구 평균 시간" -- MTTR (Mean Time to Restore)
"배포 중 장애·롤백 비율" -- Change Failure Rate
"얼마나 자주 프로덕션에 배포하는가" -- Deployment Frequency
"대시보드 생성·위젯 관리 권한" -- Project Administrators
"레포지토리 레벨 PR 사이클 타임 확인" -- GitHub Insights
DORA 4대 메트릭 = 속도(Deployment Frequency + Lead Time) + 안정성(MTTR + Change Failure Rate)