AZ-400 시험에서 패키지 관리와 테스트 파트는 '어떤 버전의 패키지를 누가 언제 쓸 수 있는가'와 '코드가 배포되기 전에 얼마나 검증됐는가'를 묻습니다. 두 주제는 파이프라인 안에서 같은 목표를 공유합니다. 빌드 결과물이 신뢰할 수 있는지 자동으로 보장하는 것입니다. Azure Artifacts와 GitHub Packages가 패키지 공급 측을 담당하고, 테스트 피라미드와 Quality Gate가 품질 검증 측을 담당합니다.
Azure Artifacts — 피드, 뷰, 업스트림 소스
동네 도서관을 떠올려 보세요. 책이 여러 곳에 흩어져 있으면 찾기도 어렵고 누가 빌려갔는지도 모릅니다. Azure Artifacts는 팀의 패키지 도서관입니다. NuGet, npm, Maven, Python, Universal Packages를 한 곳에서 호스팅하며 세 가지 개념으로 패키지 생명주기를 관리합니다.
는 패키지 컨테이너입니다. organization-scoped와 project-scoped 두 가지 범위로 생성합니다. 공개·내부 패키지의 접근 범위를 분리하려면 별도 feed를 운영해야 합니다. 하나의 feed 안에서 패키지별 접근 범위 분리는 불가능합니다.
는 패키지 성숙도를 추적합니다. → → 세 단계가 기본입니다. CI가 에 게시하고, QA 후 , 최종 승인 후 로 승격합니다. 뷰 이동은 재게시가 아닌 로만 이루어집니다.
는 외부 레지스트리(npmjs.com, NuGet.org)를 내부 feed로 프록시합니다. 시 내부 feed를 먼저 거치므로 보안 심사와 버전 고정이 한 곳에서 이루어집니다. upstream 저장 최소 권한은 이며, 는 다운로드만 가능합니다.
GitHub Packages는 GitHub 생태계 레지스트리로 또는 PAT로 인증합니다. Azure Artifacts가 Azure Pipelines와, GitHub Packages가 GitHub Actions와 각각 네이티브 통합됩니다.
SemVer — 버전 번호가 전달하는 메시지
약 이름만 적혀 있고 용량이 없는 처방전을 받으면 어떨까요? 버전 번호는 소비자에게 보내는 메시지입니다. SemVer는 MAJOR.MINOR.PATCH 세 자리로 변경의 성격을 표준화합니다.
: 버그 수정만, API 변경 없음. 소비자 코드 수정 불필요. (예: 3.5.2 → 3.5.3) : 새 기능 추가, 기존 API 유지. PATCH 0 초기화. deprecated 표시도 MINOR. (예: 2.5.3 → 2.6.0) : Breaking Change, 하위 호환 깨짐. MINOR·PATCH 모두 0 초기화. (예: 3.4.9 → 4.0.0)
deprecated 표시만 하고 제거하지 않으면 MINOR, 실제 제거하거나 시그니처 변경 시 MAJOR입니다. Azure Artifacts는 동일 버전 재배포를 금지(immutable)하므로 버그 수정 후에도 버전 번호를 올려야 합니다.
테스트 피라미드 — 어느 단계에 어떤 테스트를
공장 컨베이어 벨트를 생각해 보세요. 부품 불량은 조립 초반에 잡을수록 수정 비용이 낮습니다. 완제품에서 발견하면 전체를 분해해야 합니다. 테스트 피라미드는 파이프라인의 각 단계에 어떤 테스트를 배치할지 결정합니다.
는 기반입니다. 외부 의존성을 격리해 밀리초 단위로 실행합니다. .NET은 → 결과 파일, 에서 지정 필요. PowerShell은 표준 (는 정적 분석 도구, 테스트 프레임워크 아님).
는 실제 데이터베이스·외부 API와의 상호작용을 검증합니다. 빌드 이후, 배포 이전에 배치합니다.
는 실제 브라우저에서 사용자 시나리오 전체를 검증합니다. 는 Chromium·Firefox·WebKit을 단일 API로 통제하며 built-in auto-wait 제공. 은 레거시 브라우저 광범위 지원. 는 Chromium 전용으로 WebKit 미지원 — 크로스 브라우저 요구 시 탈락.
는 Azure Load Testing(JMeter 기반)으로 응답 시간·처리량·오류율을 측정합니다. Load testing = 예상 최대 부하 범위 내 검증, Stress testing = 한계 초과 후 시스템 반응 확인.
에서 OWASP ZAP의 두 모드가 자주 출제됩니다. 은 Passive Scan만 실행하므로 운영 환경에 안전합니다. 은 Active Scan 포함으로 실제 공격 페이로드를 전송하며 스테이징 전용입니다.
!테스트 피라미드
Quality Gate — 배포 판단을 자동화하다
물류 창고에서 출고 품질 검사를 사람이 매번 하면 규모가 커질수록 병목이 됩니다. 자동화된 검사 라인이 기준을 충족한 물건만 통과시키듯, Quality Gate는 배포 판단을 자동화합니다.
/ 는 SAST·코드 커버리지 등을 분석해 Quality Gate 기준으로 파이프라인 통과 여부를 결정합니다. Maven 기반 Java는 , Gradle은 을 사용합니다. 코드 커버리지 도구는 언어별로 다릅니다: Java → , .NET → , JS/Node.js → .
는 배포 전후 자동 조건 검사를 수행합니다. 주요 유형은 다음과 같습니다.
: Azure Boards 쿼리로 활성 버그 존재 시 배포 차단 : KQL로 오류율·응답 시간 기준 미달 시 차단 : 외부 시스템 상태 확인 범용 게이트
는 stage 시작 전 조건 검증, 는 완료 후 상태 확인입니다. Gate(자동)와 Manual approval(사람 승인)의 차이도 출제 포인트입니다.
러너 선택 — 셀프호스티드 vs MS 호스티드
회사 셔틀버스는 고정 노선이지만 사내망에 접근할 수 있고, 택시는 어디든 가지만 사내망에는 못 들어갑니다. 러너 선택도 같은 트레이드오프입니다.
Microsoft 호스티드 러너는 매 실행마다 새 가상 환경을 제공하고 유지 관리가 필요 없습니다. 그러나 프라이빗 네트워크 내부 자원에는 접근할 수 없어, 내부 시스템 연동이 필요한 통합·부하 테스트에는 한계가 있습니다.
셀프호스티드 러너는 내부 네트워크 자원에 자유롭게 접근할 수 있습니다. Azure Artifacts NuGet feed 인증 자동화에는 를 에이전트 머신에 설치하는 것이 공식 권고 방법입니다.
시험 핵심 정리
'feed 내 패키지 성숙도 단계 관리, 재게시 없이 이동' -- Release views + promote '외부 레지스트리를 내부 feed로 프록시' -- upstream source 'upstream 저장 최소 권한' -- Collaborator '패키지 직접 게시 최소 권한' -- Contributor 'deprecated 표시, 실제 제거 안 함' -- SemVer MINOR 'API 시그니처 변경 또는 엔드포인트 제거' -- SemVer MAJOR 'WebKit native 지원 + auto-wait' -- Playwright 'WebKit 미지원, 크로스 브라우저 탈락' -- Cypress 'Passive Only, 운영 환경 안전' -- OWASP ZAP Baseline Scan 'Active Scan 포함, 스테이징 전용' -- OWASP ZAP Full Scan 'stage 시작 전 자동 조건 검증' -- Pre-deployment gate '배포 완료 후 자동 상태 확인' -- Post-deployment gate
Azure Artifacts = 버전 제어 패키지 공급망, 테스트 피라미드 = 계층적 품질 보증, Quality Gate = 자동화된 배포 판단.