DP-300 시험에서 자동화 파트는 "어떤 배포 모델에서 어떤 도구를 써야 하는가"를 묻습니다. SQL Server Agent는 Managed Instance에서, Elastic Jobs는 Azure SQL Database에서라는 경계선이 시험의 핵심입니다. ARM/Bicep, Azure PowerShell, Azure Automation까지 각 도구가 존재하는 이유를 시나리오로 살펴봅니다.
SQL Server Agent — 본사 전속 비서
회사에 전속 비서를 두면 사장님 일정을 속속들이 알고 모든 일을 척척 처리합니다. 하지만 그 비서는 다른 지점으로 파견되지 않습니다. SQL Server Agent가 딱 이런 존재입니다. Azure SQL Managed Instance와 SQL Server on Azure Virtual Machines에만 존재하며, Azure SQL Database에서는 사용할 수 없습니다.
SQL Server Agent의 핵심 구성은 네 가지입니다. 은 실행할 작업 단위고, 은 T-SQL, PowerShell, SSIS 패키지, CmdExec 중 하나를 유형으로 선택해 순서대로 실행됩니다. 은 실행 시점을 정의하고, 는 알림을 받을 담당자입니다.
Database Mail이 알림을 담당합니다. SMTP 프로필과 계정을 설정한 뒤 Agent Alert와 연결하면, Job이 실패할 때 담당자에게 이메일이 전송됩니다. Job, Schedule, Alert, Operator 메타데이터는 모두 시스템 데이터베이스에 저장됩니다. Proxy account를 쓰면 특정 Step을 최소 권한 계정으로 실행할 수 있으나, T-SQL Step에는 적용할 수 없고 외부 서브시스템에만 가능합니다.
Elastic Jobs — 지점 순회 감독관
혼자 사무실 하나를 관리하는 건 어렵지 않습니다. 하지만 전국 100개 지점에 동일한 점검표를 전달하고 결과를 한 번에 수집해야 한다면? Elastic Jobs는 여러 Azure SQL Database, Elastic Pool, 서버에 동시에 T-SQL 스크립트를 실행하는 도구입니다. Azure SQL Database에서만 동작하며, Managed Instance나 SQL on VM에서는 지원되지 않습니다.
구성 요소는 세 가지입니다. 는 작업 정의와 실행 이력을 저장하는 전용 데이터베이스입니다. 은 작업 대상의 모음으로, 개별 Database, Elastic Pool, 서버 전체를 포함하거나 제외할 수 있습니다. 는 이 모든 것을 조율하는 실행 엔진입니다.
수십 개의 테넌트 데이터베이스에 매월 새 컬럼을 추가해야 한다고 가정합니다. SQL Server Agent라면 각 데이터베이스에 하나씩 접근해야 합니다. Elastic Jobs는 Target group에 전체 테넌트 DB를 등록하고 Job 하나로 동시 실행합니다. 결과는 데이터베이스별로 기록되어 실패한 테넌트만 선별 재실행할 수 있습니다.
ARM 템플릿과 Bicep — 설계도로 짓는 건물
건물을 매번 현장에서 즉흥적으로 지으면 두 번째 건물이 첫 번째와 달라집니다. 설계도가 있으면 어느 현장에서 지어도 동일한 건물이 나옵니다. ARM 템플릿과 Bicep이 Azure 인프라의 설계도입니다.
ARM 템플릿은 Azure 리소스를 JSON으로 선언적으로 정의합니다. "이런 상태의 리소스들이 존재해야 한다"고 선언하면 Azure Resource Manager가 의존성을 분석해서 올바른 순서로 배포합니다. 핵심 장점은 멱등성(idempotency)으로, 동일한 템플릿을 여러 번 실행해도 항상 동일한 최종 상태가 보장됩니다. GitHub Actions나 Azure Pipelines에서 배포 단계로 직접 호출할 수 있습니다.
Bicep은 ARM 템플릿의 공식 DSL입니다. JSON 대신 간결한 문법으로 작성하며 컴파일 시 ARM JSON으로 변환됩니다. DACPAC은 스키마만, BACPAC은 스키마와 데이터를 모두 패키지화합니다.
Azure PowerShell과 Azure CLI — 현장 지휘봉
설계도가 목표 상태를 선언한다면, "지금 당장 이 작업을 실행해라"고 명령하는 도구가 따로 필요합니다. Azure PowerShell과 Azure CLI가 그 역할입니다.
모듈은 , , 같은 cmdlet으로 Azure SQL 리소스를 관리합니다. Azure CLI의 그룹은 동일한 기능을 크로스플랫폼으로 제공해, Linux 기반 CI/CD 에이전트에서도 쓸 수 있습니다. 두 도구 모두 Service Principal이나 Managed Identity를 통한 비대화형 인증을 지원합니다. 명령으로 기본 리소스 그룹을 설정하면 이후 모든 명령에서 인수를 생략할 수 있습니다.
Azure Automation — 하이브리드 세계의 자동화
온프레미스 서버가 남아 있는데 클라우드와 동일한 자동화 정책을 적용해야 한다면? Azure Automation이 그 다리를 놓습니다.
은 PowerShell이나 Python 스크립트를 클라우드에서 스케줄링하거나 이벤트로 트리거합니다. 를 사용하면 온프레미스 서버나 다른 클라우드의 VM에서도 동일한 Runbook을 실행할 수 있습니다. SQL Server Agent나 Elastic Jobs가 SQL 인스턴스 내부에서 작동하는 것과 달리, Azure Automation은 외부에서 리소스를 관리하는 조율자입니다. , , 기능을 통해 패치 추적·구성 감지·선언적 상태 유지도 지원합니다.
도구 선택 기준
공구함에 망치와 드라이버가 모두 있을 때, 나사 앞에서 망치를 들면 안 됩니다. 각 도구의 적용 범위를 명확히 구분하는 것이 시험과 실무 모두에서 핵심입니다.
: Managed Instance, SQL on VM 전용. 인스턴스 내 T-SQL Job, 야간 유지 관리, Database Mail 알림 : Azure SQL Database 전용. 다중 DB·Pool·서버 동시 T-SQL 실행 : 모든 Azure 리소스. 선언적 IaC, 환경 일관성, GitHub Actions 통합 : 모든 Azure 리소스. 명령형 스크립팅, CI/CD 단계 실행 : 클라우드 + 온프레미스. Runbook 스케줄링, Hybrid Worker, DSC
실무 함정 — 가장 자주 틀리는 선택
"여러 Azure SQL Database에 동시에 스키마를 배포해야 한다"는 시나리오에서 SQL Server Agent를 고르면 틀립니다. SQL Server Agent는 단일 인스턴스 범위를 벗어나지 못합니다. 정답은 Elastic Jobs입니다.
반대로 "Managed Instance에서 야간 인덱스 재구성 Job을 예약한다"는 시나리오에서 Elastic Jobs를 고르면 틀립니다. Elastic Jobs는 Azure SQL Database에서만 동작합니다. 동일한 환경을 반복 배포할 때는 ARM/Bicep, 기존 리소스 하나를 즉시 변경할 때는 CLI 명령 하나로 충분합니다. 선언적 도구와 명령형 도구를 함께 쓰는 것이 실무의 실제 패턴입니다.
시험 핵심 정리
"Managed Instance에서 야간 인덱스 Job" -- SQL Server Agent "Azure SQL Database에 SQL Server Agent를 설치" -- 불가능 (Database는 미지원) "100개 테넌트 DB에 동시에 ALTER TABLE 실행" -- Elastic Jobs "Job 실행 이력 저장소" -- msdb (Agent) / Job database (Elastic Jobs) "선언적 IaC, 멱등성 보장" -- ARM 템플릿 / Bicep "Bicep 컴파일 결과물" -- ARM JSON "GitHub Actions에서 SQL 서버 생성 자동화" -- Azure PowerShell 또는 Azure CLI "온프레미스 SQL Server에 Runbook 실행" -- Azure Automation Hybrid Runbook Worker "Database Mail SMTP 프로필, sp_send_dbmail" -- SQL Server Agent 알림 (MI/VM 전용) "DACPAC vs BACPAC" -- DACPAC = 스키마만, BACPAC = 스키마 + 데이터
SQL Server Agent = Managed Instance·SQL on VM 전속, Elastic Jobs = Azure SQL Database 전용