DSC로 Windows를 선언적으로 구성 관리하기 ── dsc.exe로 시작하는 IaC

새 PC의 셋업 절차서, 서버 구축 절차를 적은 Excel, 퇴사자가 남긴 비전의 BAT 파일 ── Windows의 구성 관리는 지금도 많은 현장에서 “절차를 적은 문서”와 “절차를 실행하는 스크립트”로 돌아가고 있습니다. 이 방식의 약점은 분명합니다. 절차는 실행한 순간부터 현실과 어긋나기 시작하고, 스크립트는 두 번째 실행에서 망가집니다.

Linux나 클라우드에서는 Terraform이나 Ansible 같은 선언적 IaC(Infrastructure as Code)가 당연한 것이 되었습니다. 그렇다면 Windows 클라이언트나 서버 자체를 같은 발상으로 관리하려면 무엇을 쓰면 될까요. Microsoft의 답이 DSC(Desired State Configuration)이며, 2025년에 PowerShell 비의존 명령줄 도구로 다시 작성된 Microsoft DSC v3(dsc.exe)로 마침내 “평범하게 시작할 수 있는” 형태가 되었습니다.¹

대상 독자는 Windows 단말과 서버의 구성을 절차서와 스크립트로 관리하고 있으면서 선언적 관리로 옮겨 가고 싶은 개발자와 정보시스템 담당자입니다. 전제 환경은 Windows 10/11과 DSC 3.0 이상이고, PowerShell의 기본 조작을 배경 지식으로 삼습니다. 난이도는 중급입니다.

1. 먼저 결론

DSC에서는 “실행할 절차”가 아니라 “있어야 할 상태”를 YAML로 씁니다. 현재 상태와의 차이 감지(test)와 적용(set)은 리소스가 맡으므로, 같은 파일을 몇 번 실행해도 안전(멱등)하고, 구성은 Git에서 리뷰할 수 있는 데이터가 됩니다. 지금부터 시작한다면 Microsoft DSC v3(dsc.exe) 하나뿐입니다.

절차서 스크립트와 선언적 구성의 차이는 “망가지는 방식”에서 드러납니다. 절차를 적은 스크립트는, 도중에 실패한 단말이나 이미 설정이 끝난 단말에 다시 한 번 흘려보내면 이중 적용이나 오류로 멈춥니다. 선언적 구성은 “있어야 할 상태”만 적혀 있으므로, 몇 번을 흘려보내든, 어떤 중간 상태에서 흘려보내든 같은 결과로 수렴합니다.²

flowchart TB
    accTitle: 명령형 절차서와 선언형 구성의 대비
    accDescr: 명령형 스크립트는 절차를 위에서부터 실행하므로 재실행하면 이중 적용이나 중단이 일어나는 데 비해, 선언형 DSC는 있어야 할 상태를 선언하고 차이만 적용하므로 몇 번을 실행해도 같은 상태로 수렴한다
    imp["명령형: 절차를 쓴다 (BAT, 절차서)"] --> i1["위에서부터 차례로 실행"]
    i1 --> i2["재실행하면 이중 적용, 오류"]
    dec["선언형: 상태를 쓴다 (DSC)"] --> d1["현재와의 차이를 감지"]
    d1 --> d2["차이만 적용, 몇 번이든 안전"]

그림1: 명령형 스크립트는 “실행 횟수”에 민감하지만, 선언형 구성은 몇 번을 실행해도 같은 상태로 수렴합니다.

그림의 실선은 항상 성립하는 관계, 점선은 조건이 붙는 관계입니다(성립 조건은 상세 페이지의 관계별 설명에 적혀 있습니다). 관계 전체 목록(총 17건, 근거와 확신도 포함)과 주요 개념의 정의는 지식 맵 상세 페이지에 정리되어 있습니다(일본어). 데이터: JSON-LD / Turtle

2. “DSC”라는 이름의 혼란을 정리한다 ── 네 갈래

DSC를 배울 때 가장 먼저 걸려 넘어지는 것은 기술 자체가 아니라 검색 결과의 혼란입니다. “DSC”라는 이름을 가진 구조는 네 갈래가 있고, 쓰는 법도 실행 방법도 호환성도 다릅니다.³

Microsoft DSC v3는 그때까지의 PowerShell DSC(PSDSC)를 단순히 갱신한 것이 아니라, PowerShell에 대한 의존을 떼어 내고 다시 작성한 별개의 제품입니다. 구성은 PowerShell 스크립트가 아니라 JSON/YAML 데이터가 되고, 리소스는 어떤 언어로든 구현할 수 있으며, Linux, macOS, Windows에서 똑같이 동작합니다.¹

flowchart TB
    accTitle: DSC 네 갈래의 계보
    accDescr: Windows PowerShell 5.1에 내장된 PSDSC v1.1에서 PowerShell 7용 PSDSC v2와 Machine Configuration용 PSDSC v3 프리뷰가 갈라져 나오고, 그것들과는 별개로 PowerShell에 의존하지 않도록 다시 작성된 Microsoft DSC v3가 현행 주역이 되는 관계
    v11["PSDSC v1.1 (WinPS 5.1 내장)"] --> v2["PSDSC v2 (PowerShell 7)"]
    v2 --> v3ps["PSDSC v3 프리뷰"]
    v11 -.->|"다시 작성"| dsc3["Microsoft DSC v3 (dsc.exe)"]
    v3ps --> mc["Azure Machine Configuration"]
    dsc3 --> now["이 글의 주역"]

그림2: “DSC”를 검색하면 네 갈래의 정보가 섞여서 나옵니다. 글이나 자료가 어느 갈래의 이야기인지를 먼저 가려내는 것이 중요합니다.

이후 이 글에서 “DSC”라고 쓰면 Microsoft DSC v3를 가리킵니다. 이전 세대의 자산이 헛되지 않다는 점은 뒤에서(6절) 다룹니다.

3. 선언적이란 어떤 것인가 ── get·test·set과 멱등성

DSC의 중심 개념은 리소스입니다. 리소스는 “레지스트리 값”, “Windows 기능”, “환경 변수” 같은 구성 대상 한 종류마다 상태의 취득(Get), 판정(Test), 적용(Set) 조작을 제공합니다. Get은 모든 리소스가 구현합니다. Test는 구현을 갖지 않는 리소스에 대해 DSC가 취득 결과와 선언의 비교(합성 테스트)로 대신합니다. Set은 상태를 강제할 수 있는 리소스만 구현하며, OS 정보 같은 읽기 전용 리소스에는 없습니다.⁴ 이용자는 “어떻게 설정할지”를 리소스에 맡기고, “무엇이 어떠해야 하는지”만 데이터로 씁니다.

이 분업이 멱등성을 낳습니다. 구성 문서의 적용(dsc config set)에서는 DSC가 각 인스턴스를 먼저 test하고, 원하는 상태에 있지 않은 것에 대해서만 set을 호출합니다. 그래서 같은 구성을 몇 번 적용해도 안전합니다. 다만 리소스를 단독으로 dsc resource set할 때는 항상 set이 호출되고, 사전 테스트의 유무는 리소스 쪽 구현(implementsPretest)에 달려 있다는 차이가 있습니다.⁵

flowchart TB
    accTitle: get·test·set에 의한 수렴 루프
    accDescr: 구성 문서에 쓴 있어야 할 상태를 test가 현재 상태와 비교하고, 차이가 없으면 아무것도 하지 않으며, 차이가 있으면 set이 차이만 적용하고 get으로 결과를 확인할 수 있다는 멱등한 수렴의 흐름
    doc["구성 문서 (있어야 할 상태)"] --> test["test: 현재 상태와 비교"]
    test -->|"차이 없음"| ok["아무것도 하지 않음 (멱등)"]
    test -->|"차이 있음"| set["set: 차이만 적용"]
    set --> get["get: 결과 상태를 확인"]

그림3: DSC의 적용은 “비교한 다음, 필요한 만큼만 바꾸는” 루프이며, 실행 횟수라는 개념에서 해방됩니다.

명령형 스크립트와의 차이를 코드로 봅니다. 예를 들어 “레지스트리에 이 값을 넣는다”는 처리는, 스크립트에서는 존재 확인, 생성, 갱신을 전부 직접 나누어 써야 합니다.

# 명령형:"절차"를 쓴다. 분기와 순서를 전부 스스로 관리한다
$path = 'HKCU:\Software\MyCompany\App'
if (-not (Test-Path $path)) {
    New-Item -Path $path -Force | Out-Null
}
Set-ItemProperty -Path $path -Name 'Mode' -Value 'standard'

DSC에서는 같은 일을 “있어야 할 상태”의 선언으로 씁니다. 존재 확인도 분기도 없습니다.

# 선언형:"상태"를 쓴다. 만들고 고치는 절차는 리소스의 몫
- name: 애플리케이션의 동작 모드
  type: Microsoft.Windows/Registry
  properties:
    keyPath: HKCU\Software\MyCompany\App
    valueName: Mode
    valueData:
      String: standard

4. dsc.exe를 설치하고 리소스를 단독으로 두드려 본다

DSC의 설치 방법은 두 가지입니다. GitHub의 릴리스에서 아카이브를 풀어 PATH에 추가하거나, Windows라면 Microsoft Store 소스를 거쳐 winget으로 설치합니다.¹

# Microsoft Store 소스에서 안정판을 검색, 설치
winget search DesiredStateConfiguration --source msstore
winget install --id 9NVTPZWRC6KQ --source msstore

설치했다면 먼저 지금 이 머신에서 쓸 수 있는 리소스를 나열합니다.

dsc resource list

구성 문서를 쓰기 전에, 리소스는 하나씩 단독으로도 호출할 수 있습니다. 이 “작게 시험할 수 있다”는 점이 v3의 학습을 편하게 만들어 줍니다.⁶

# 현재 상태를 취득한다(get)
dsc resource get --resource Microsoft.Windows/Registry `
  --input '{"keyPath":"HKCU\\Software\\MyCompany\\App","valueName":"Mode"}'

# 원하는 상태인지를 판정한다(test) ── 변경은 일절 하지 않는다
dsc resource test --resource Microsoft.Windows/Registry `
  --input '{"keyPath":"HKCU\\Software\\MyCompany\\App","valueName":"Mode","valueData":{"String":"standard"}}'

flowchart TB
    accTitle: dsc resource 명령의 네 가지 조작
    accDescr: dsc resource 명령 아래에 리소스 목록을 보여 주는 list, 현재 상태를 취득하는 get, 원하는 상태인지를 변경 없이 판정하는 test, 상태를 적용하는 set (Set을 구현한 리소스만) 네 가지 조작이 매달린 구조
    cli["dsc resource 명령"] --> l["list: 리소스 목록"]
    cli --> g["get: 현재 상태의 취득"]
    cli --> t["test: 판정만, 변경 없음"]
    cli --> s["set: 적용 (Set 지원 리소스)"]

그림4: 리소스는 구성 문서를 쓰지 않아도 단독으로 호출할 수 있습니다. 우선 get과 test만으로 관찰부터 시작하는 것이 안전한 입문 경로입니다.

set에 의한 변경을 수반하는 조작이나 HKLM, 시스템 설정을 다루는 리소스에는 관리자 권한이 필요합니다. 시도는 쓰기 대상이 사용자 아래(HKCU 등)인 예제부터 시작하는 것이 안전합니다.

5. 구성 문서 ── YAML로 “있어야 할 상태”를 쓴다

여러 리소스를 한데 모아 선언하는 것이 구성 문서입니다. YAML 또는 JSON으로 쓰고, 최소한 $schema와 resources 두 가지를 정의합니다. 각 리소스 인스턴스는 name(문서 안에서 고유한 표시 이름), type(리소스의 정규화된 이름), properties(원하는 상태)를 가집니다.²

# standard-pc.dsc.config.yaml ── 표준 단말이 있어야 할 상태
$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
parameters:
  appMode:
    type: string
    defaultValue: standard
resources:
  - name: 애플리케이션의 동작 모드
    type: Microsoft.Windows/Registry
    properties:
      keyPath: HKCU\Software\MyCompany\App
      valueName: Mode
      valueData:
        String: "[parameters('appMode')]"

parameters와 variables를 쓰면 환경별 차이(부서별 설정값 등)를 하나의 문서로 표현할 수 있습니다. 식을 쓰는 법은 ARM 템플릿 함수의 부분집합입니다.²

flowchart TB
    accTitle: 구성 문서의 구조
    accDescr: 구성 문서는 문서 스키마를 나타내는 schema, 환경 차이를 흡수하는 parameters와 variables, 리소스 인스턴스의 배열 resources로 이루어지고, 각 인스턴스가 name, type, properties를 가지는 구조
    docroot["구성 문서 (YAML / JSON)"] --> sch["$schema: 문서 스키마의 URI"]
    docroot --> par["parameters / variables"]
    docroot --> res["resources: 인스턴스의 배열"]
    res --> inst["name, type, properties"]
    par -.-> inst

그림5: 구성 문서는 “스키마+매개변수+리소스 선언”뿐인 담백한 데이터이며, 프로그램이 아닙니다.

적용하기 전에 반드시 “관찰”을 끼워 넣습니다. dsc config test는 변경 없이 차이의 유무를 보고하고, dsc config set --what-if는 “실행하면 무엇이 바뀌는지”의 예측을 표시합니다.⁷

# 1. 차이의 유무를 확인한다(변경 없음)
dsc config test --file .\standard-pc.dsc.config.yaml

# 2. 적용하면 무엇이 바뀌는지를 예측 표시한다(변경 없음)
dsc config set --file .\standard-pc.dsc.config.yaml --what-if

# 3. 납득한 다음 적용한다
dsc config set --file .\standard-pc.dsc.config.yaml

# 4. 적용 후의 상태를 확인한다
dsc config get --file .\standard-pc.dsc.config.yaml

반대 방향의 입구도 있습니다. dsc config export는 --file로 넘긴 입력 문서에 열거한 리소스(export를 지원하는 것만)에 대해, 시스템 위의 모든 인스턴스를 포함하는 구성 문서를 생성해 표준 출력으로 돌려줍니다. 기존 환경의 현황을 받아 적는 출발점으로 쓸 수 있습니다.⁸

# 대상 리소스를 열거한 입력 문서를 넘겨, 현황의 구성 문서를 저장한다
dsc config export --file .\export-targets.dsc.config.yaml > .\current-state.dsc.config.yaml

flowchart TB
    accTitle: 안전한 적용의 네 단계
    accDescr: 변경을 가하지 않는 dsc config test로 차이의 유무를 확인하고, dsc config set의 what-if 옵션으로 변경 내용을 예측 표시하고, 납득한 다음 set으로 적용하고, get으로 결과를 확인하는 안전한 순서
    t["dsc config test (차이의 유무)"] --> w["set --what-if (변경의 예측)"]
    w --> s["dsc config set (적용)"]
    s --> g["dsc config get (결과의 확인)"]

그림6: “관찰 → 예측 → 적용 → 확인”의 순서를 무너뜨리지 않으면, 선언적 구성의 적용에 단판 승부의 무서움은 없습니다.

구성 문서가 프로그램이 아니라 데이터라는 점은 운영 면에서 가장 큰 이점입니다. “이 단말에는 무엇이 설정되어 있어야 하는가”를 YAML의 차이로 리뷰할 수 있고, 변경 이력이 그대로 구성의 변경 이력이 됩니다.

6. 기존 자산을 살린다 ── PSDSC 리소스의 어댑터와 WinGet Configuration

“v3는 별개의 제품”이라는 말을 들으면 과거의 자산이 걱정되지만, DSC v3는 어댑터 리소스라는 장치로 이전 세대의 PSDSC 리소스를 호출할 수 있습니다. DSC 3.2 이상의 현행 이름으로는, PowerShell 7의 클래스 기반 리소스용이 Microsoft.Adapter/PowerShell, Windows PowerShell 5.1의 MOF 기반, 스크립트 기반 리소스용이 Microsoft.Adapter/WindowsPowerShell입니다(그 이전에는 Microsoft.DSC/PowerShell, Microsoft.Windows/WindowsPowerShell이라는 이름이었습니다).⁹ 오랜 세월 축적된 PSDSC 리소스 생태계에 v3의 구성 문서에서 그대로 닿을 수 있습니다.

또 하나의 접속처가 WinGet Configuration입니다. PC 키팅 글에서 소개한 .winget 파일은, v3 스키마(WinGet 1.11 이상)부터는 DSC v3를 그대로 실행 엔진으로 쓰게 되었습니다. 구성 파일의 metadata에서 실행 엔진으로 dscv3를 지정하면, 문서의 내용은 DSC v3의 구성 문서 그 자체가 됩니다.¹⁰

# WinGet Configuration v3 ── 내용은 DSC v3의 구성 문서
$schema: https://raw.githubusercontent.com/PowerShell/DSC/main/schemas/2023/08/config/document.json
metadata:
  winget:
    processor:
      identifier: dscv3
resources:
  - name: 애플리케이션의 동작 모드
    type: Microsoft.Windows/Registry
    properties:
      keyPath: HKCU\Software\MyCompany\App
      valueName: Mode
      valueData:
        String: standard

주의할 점이 하나 있습니다. 기존의 v2 형식(properties.configurationVersion: 0.2.0으로 리소스를 properties 아래에 넣는 서식) 파일이 그대로 dscv3 실행 엔진에서 동작하는 것은 아닙니다. v2 파일은 지금까지의 실행 엔진에서 계속 동작하지만, DSC v3에 올리려면 공식 변환 가이드(샘플 리포지터리의 “Convert to v3”)에 따라 서식을 옮겨야 합니다.¹⁰

flowchart TB
    accTitle: DSC v3를 중심으로 한 계층 구조
    accDescr: winget configure나 Azure Machine Configuration 같은 오케스트레이션 계층이 DSC v3를 호출하고, DSC v3는 네이티브 리소스를 직접, 기존 PSDSC 리소스는 어댑터 리소스를 거쳐 호출하는 계층 구조
    orch["winget configure, Machine Configuration"] --> dsc["dsc.exe (DSC v3)"]
    dsc --> native["네이티브 리소스 (Registry 등)"]
    dsc --> adapter["어댑터 리소스"]
    adapter --> psdsc["기존 PSDSC 리소스 (PowerShell 자산)"]

그림7: DSC v3는 단독 도구인 동시에 winget이나 Azure 같은 상위 도구의 공통 기반이기도 합니다. 기존 PSDSC 자산은 어댑터 아래에 매달립니다.

즉 v3로 익힌 지식과 구성은, 손에 있는 dsc.exe에서도, 키팅의 winget configure에서도, 클라우드 관리의 Machine Configuration에서도 통합니다. 다시 배우는 것이 아니라 합류입니다.¹

7. 운영에 올린다 ── Git으로 관리하고 드리프트를 감지한다

구성 문서를 둘 곳은 Git 리포지터리로 합니다. 이렇게 하면 구성 변경은 “풀 리퀘스트로 리뷰하고, 머지하고, 적용한다”는 소프트웨어 개발과 같은 흐름이 됩니다. 절차서 갱신 누락이라는 개념 자체가 사라집니다.

적용 후의 과제는 구성 드리프트(누군가 손으로 설정을 바꿔서 있어야 할 상태에서 어긋나 가는 것)입니다. DSC에서는 드리프트 감지가 그대로 dsc config test의 주기 실행이 됩니다. test는 변경을 가하지 않으므로 감지와 복구를 분리할 수 있다는 점이 중요한 성질입니다. 먼저 감지만 자동화하고, 복구(set)는 차이 내용을 확인한 다음에 하는 것이 안전한 운영입니다.

# 주기 실행용:test 자체의 실패, 리소스 단위의 오류, 드리프트를 구별하고 모두 0이 아닌 값으로 끝낸다
$json = dsc config test --file C:\config\standard-pc.dsc.config.yaml
if ($LASTEXITCODE -ne 0 -or -not $json) {
    Write-Error "dsc config test의 실행 자체가 실패했습니다(종료 코드: $LASTEXITCODE)"
    exit 2
}
$result = $json | ConvertFrom-Json
if ($result.hadErrors) {
    # 문서의 검증 실패나 일부 리소스의 0이 아닌 종료. 검사가 완주하지 않았으므로 건전하다고 보고하지 않는다
    Write-Error "일부 리소스의 검사가 오류가 되었습니다. messages를 확인하세요"
    exit 2
}
if ($result.results.result.inDesiredState -contains $false) {
    Write-Error "구성 드리프트를 감지했습니다"
    exit 1
}

주기 실행의 발판은, 단말이라면 작업 스케줄러(무인 실행의 설계는 다른 글에서 해설), 서버 무리라면 CI 러너를 쓸 수 있습니다. Azure에 관리를 모아 둔 조직이라면, Machine Configuration이 Azure VM과 Azure Arc를 거친 온프레미스 서버에 대해 감사와 적용을 관리형으로 해 주는 받침대가 됩니다.¹¹

flowchart TB
    accTitle: Git을 기점으로 한 구성 관리의 운영 사이클
    accDescr: Git 리포지터리에 둔 구성 문서를 풀 리퀘스트로 리뷰한 다음 적용하고, 작업 스케줄러나 CI에 의한 주기적인 test로 드리프트를 감지하며, 차이를 확인해 복구하거나 구성의 갱신으로 돌아가는 순환
    git["Git 리포지터리 (구성 문서)"] --> pr["변경은 풀 리퀘스트로 리뷰"]
    pr --> apply["dsc config set으로 적용"]
    apply --> sched["주기 실행: dsc config test"]
    sched -->|"드리프트 감지"| judge["차이를 확인해 대처를 판단"]
    judge -.->|"구성이 옳다"| fix["set으로 복구"]
    judge -.->|"현실이 옳다"| git

그림8: 드리프트에 대한 대처는 “복구”만이 아닙니다. 현장의 변경이 옳다면 구성 문서 쪽을 고쳐서 머지하는 것이 선언적 관리의 작법입니다.

그림8의 오른쪽 아래 분기는 놓치기 쉽습니다. 드리프트가 언제나 “악”인 것은 아니고, 현장에서 필요했던 변경이 구성에 반영되지 않았을 뿐인 경우도 있습니다. 그럴 때는 단말을 되돌리는 것이 아니라 구성 문서를 현실에 맞춰 갱신합니다. 정본은 어디까지나 Git 안의 선언이라는 규율만 지키면, 어느 쪽으로 기울든 관리는 무너지지 않습니다.

8. 제약과 함정

도입 전에 알아 두어야 할 제약을 있는 그대로 꼽아 봅니다.

LCM이 없다. v1.1에 있던 LCM(Local Configuration Manager)은 구성을 보존해 두고 주기 적용과 자동 복구를 하는 상주 에이전트였습니다. v3는 “불렸을 때만 움직이는 명령”이며, 서비스로 상주하지 않습니다.¹ 지속적인 강제가 필요하다면, 앞 절처럼 실행의 발판(작업 스케줄러, CI, Machine Configuration)을 스스로 골라야 합니다. 이것은 퇴화가 아니라 “실행시키는 방법”을 현대의 도구에 열어 준 설계 변경이지만, v1.1의 pull server 운영 감각으로 오면 당황하게 되는 지점입니다.

관리자 권한의 취급. 머신 전체에 관련된 리소스(HKLM, Windows 기능 등)의 set에는 권한 상승이 필요하고, Windows PowerShell 계열의 PSDSC 리소스를 어댑터를 거쳐 쓸 때도 관리자 실행이 전제입니다.⁶ 사용자 단위의 설정과 머신 단위의 설정을 구성 문서 단계에서 나눠 두면 실행 컨텍스트의 설계가 편해집니다.

시크릿을 구성에 쓰지 않는다. 구성 문서는 Git에 넣는 데이터입니다. 비밀번호나 API 키를 그대로 쓰지 말고, 매개변수화해서 실행 시에 넘기는 설계로 합니다.

남의 구성 파일은 읽고 나서 실행한다. 구성 문서는 리소스를 통해 시스템을 변경하는 힘을 가집니다. 공개 리포지터리에서 가져온 .winget 파일이나 구성 문서는, 내용과 참조하는 리소스의 신뢰성을 확인한 다음에 적용합니다. 이것은 공식 문서도 명시적으로 경고하는 운영상의 필수 사항입니다.¹²

flowchart TB
    accTitle: v1.1의 LCM 상주형과 v3의 명령형의 대비
    accDescr: PSDSC v1.1에서는 상주하는 LCM이 구성을 보존해 주기적인 pull과 자동 복구를 맡았던 데 비해, DSC v3는 명령으로 기동될 뿐이므로 주기 실행의 발판을 작업 스케줄러, CI, Machine Configuration 중에서 스스로 골라 마련해야 한다
    v1["PSDSC v1.1: LCM이 상주"] --> pull["구성을 보존하고 주기 pull, 자동 복구"]
    v3["DSC v3: 명령 기동만"] --> push["실행의 발판은 스스로 마련"]
    push -.-> ex["작업 스케줄러, CI, Machine Configuration"]

그림9: v3에는 “구성을 기억하고 알아서 고쳐 주는 누군가”가 없습니다. 그것을 불편으로 볼지, 실행 제어를 되찾았다고 볼지가 설계의 갈림길입니다.

9. 정리 ── 절차서를 리포지터리로 바꾼다

• Windows의 선언적 IaC를 지금부터 시작한다면 Microsoft DSC v3(dsc.exe)입니다. 네 갈래인 “DSC” 가운데 어느 갈래의 정보를 읽고 있는지를 항상 의식하세요.³
• DSC는 “절차”가 아니라 “있어야 할 상태”를 YAML/JSON으로 쓰고, test(비교)와 set(차이 적용)이 멱등한 수렴을 보장합니다. 먼저 dsc resource get/test에 의한 관찰부터 시작해, --what-if로 영향을 확인한 다음 적용하는 흐름이 안전합니다.⁷
• 기존 PSDSC 리소스는 어댑터를 거쳐, 키팅의 .winget 자산은 WinGet Configuration v3 스키마를 거쳐 각각 v3의 세계로 합류할 수 있습니다(v2 형식의 파일은 변환 가이드에 따른 서식 이행이 필요합니다).⁹¹⁰
• v3에 LCM은 없습니다. 구성의 정본을 Git에 두고, dsc config test의 주기 실행으로 드리프트를 감지하며, “구성이 옳으면 복구, 현실이 옳으면 구성을 갱신”이라는 규율로 돌리는 것이 운영의 뼈대입니다.

절차서의 숙명은 쓰는 순간부터 현실과 어긋나 간다는 것이었습니다. 선언적 구성 관리는 그 어긋남을 “감지할 수 있는 차이”로 바꿉니다. 우선은 자기 단말의 설정 몇 개를 구성 문서로 받아 적고 dsc config test를 흘려보내는 데서 시작해 보세요. 절차서가 리포지터리로 바뀌어 가는 감각을 잡을 수 있을 것입니다.

관련 글

• winget + PowerShell로 PC 키팅을 자동화한다 ── 절차서를 실행 가능하게 만들기
• BAT를 PowerShell로 옮겨야 하는가 ── 판단 기준과 이행의 실무
• 작업 스케줄러의 작업이 실행되지 않는다, 0x1로 끝난다 ── 원인 범위 좁히기와 안전한 운영 설계
• GPO에서 Intune으로의 이행 가이드 ── 중소기업의 현실적인 해답
• WSUS 지원 중단 이후의 Windows Update 관리

관련 상담 영역

합동회사 고무라소프트에서는 Windows 단말과 서버 구성의 선언적 관리로의 이행, 키팅이나 사내 표준 환경의 자동화, 속인화된 절차서의 실행 가능화를 지원하고 있습니다.

• 기술 상담, 설계 리뷰
• 기존 Windows 소프트웨어의 수정·유지보수
• 기존 자산 활용, 이행 지원
• 문의하기

참고 링크

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

자주 묻는 질문

이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.

DSC에는 버전이 여러 개 있는 것 같은데, 어느 것을 쓰면 되나요?

지금부터 선언적 구성 관리를 시작한다면 Microsoft DSC v3(dsc.exe)입니다. DSC에는 Windows PowerShell 5.1에 내장된 PSDSC v1.1, PowerShell 7용 모듈인 PSDSC v2, Azure Machine Configuration의 Linux 지원에 쓰이는 PSDSC v3(프리뷰), 그리고 PowerShell에 의존하지 않는 독립 명령으로 다시 작성된 Microsoft DSC v3까지 네 갈래가 있습니다. v3는 크로스 플랫폼이고, 구성을 PowerShell 스크립트가 아니라 YAML/JSON 데이터로 쓰며, 기존 PSDSC 리소스도 어댑터를 거쳐 재사용할 수 있습니다. 검색할 때 "DSC v3"나 "dsc.exe"를 붙이면 이전 세대의 정보와 구분하기 쉬워집니다.

DSC v3와 절차서 스크립트(BAT나 PowerShell)는 무엇이 다른가요?

절차서 스크립트는 "실행할 절차"를 쓰기 때문에, 두 번째 실행에서 이중 적용이나 오류가 생기지 않도록 멱등성을 직접 만들어 넣어야 합니다. DSC는 "있어야 할 상태"를 데이터로 쓰고, 현재 상태와의 비교(test)와 차이의 적용(set)은 리소스가 맡습니다. 같은 구성 문서를 몇 번 실행하더라도 이미 원하는 상태에 있는 항목에는 아무것도 하지 않으므로, 실행 횟수를 신경 쓰지 않고 배포하고 다시 실행할 수 있습니다. 또 구성이 YAML 데이터이므로 Git에서의 차이 리뷰나 세대 관리가 스크립트보다 훨씬 수월해집니다.

기존 PowerShell DSC 리소스나 WinGet Configuration 자산은 쓸모없어지나요?

쓸모없어지지 않습니다. DSC v3는 어댑터 리소스(DSC 3.2 이상은 Microsoft.Adapter/PowerShell과 Microsoft.Adapter/WindowsPowerShell, 그 이전에는 Microsoft.DSC/PowerShell과 Microsoft.Windows/WindowsPowerShell)를 통해 클래스 기반과 MOF 기반의 기존 PSDSC 리소스를 호출할 수 있습니다. 또 WinGet Configuration은 v3 스키마(WinGet 1.11 이상)부터 DSC v3를 실행 엔진으로 쓰게 되었습니다. 기존 v2 형식의 .winget 파일은 지금까지의 실행 엔진에서 계속 동작하지만, DSC v3의 실행 엔진에 올리려면 공식 변환 가이드를 따라 v3 형식으로 변환해야 합니다.

DSC v3에서 구성을 "지속적으로" 강제하려면 어떻게 해야 하나요?

DSC v3 자체는 명령으로 기동되는 도구이며, v1.1의 LCM(Local Configuration Manager) 같은 상주 에이전트나 자동 복구 장치를 갖고 있지 않습니다. 지속적인 적용과 감사가 필요하다면, 작업 스케줄러나 CI에서 dsc config test를 주기적으로 실행해 드리프트를 감지하는 구조를 직접 마련하거나, Azure의 Machine Configuration(Azure Arc를 거쳐 온프레미스 서버도 대상으로 삼을 수 있습니다) 같은 오케스트레이션 계층에 올립니다.

dsc config set을 바로 실행하기가 무서운데, 사전에 영향을 확인할 수 있나요?

가능합니다. dsc config test를 실행하면 어느 리소스 인스턴스가 원하는 상태에 있지 않은지를 변경 없이 확인할 수 있습니다. 여기에 더해 dsc config set에는 --what-if 옵션이 있어서, 실제로는 변경하지 않고 "실행하면 무엇이 어떻게 바뀌는지"의 예측을 표시할 수 있습니다. 먼저 test와 --what-if로 차이를 확인하고, 문제가 없으면 set을 실행하는 순서로 가면 안전합니다.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.