• AWS Systems Manager CloudWatch 대시보드는 2026년 4월 30일 이후에는 더 이상 사용할 수 없습니다. 고객은 Amazon CloudWatch 콘솔을 계속 사용하여 현재와 마찬가지로 Amazon CloudWatch 대시보드를 보고, 생성하고, 관리할 수 있습니다. 자세한 내용은 [Amazon CloudWatch 대시보드 설명서](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)를 참조하세요.
# Linux 및 Windows Server 간 패치 작업 차이점
이 주제에서는 AWS Systems Manager의 도구인 Patch Manager의 Linux 패치와 Windows Server 패치 간 주요 차이점에 대해 설명합니다.
**참고**
Linux 관리형 노드에 패치를 실행하려면 노드가 SSM Agent 버전 2.0.834.0 이상을 실행 중이어야 합니다.
SSM Agent의 업데이트된 버전은 Systems Manager에 새 도구가 추가되거나 기존 도구가 업데이트될 때마다 릴리스됩니다. 최신 버전의 에이전트를 사용하지 못하면 관리형 노드에서 다양한 Systems Manager 도구를 사용하지 못할 수 있습니다. 이러한 이유로 시스템의 SSM Agent 상태를 최신 상태로 유지하는 프로세스를 자동화하는 것이 좋습니다. 자세한 내용은 [SSM Agent 업데이트 자동화](ssm-agent-automatic-updates.md) 섹션을 참조하세요. SSM Agent 업데이트에 대해 알림을 수신하려면 GitHub에서 [SSM Agent 릴리스 정보](https://github.com/aws/amazon-ssm-agent/blob/mainline/RELEASENOTES.md) 페이지를 구독합니다.
## 차이점 1: 패치 평가
Patch Manager는 Windows 관리형 노드와 Linux 관리형 노드에 적용되는 패치를 평가할 때 서로 다른 프로세스를 사용합니다.
**Linux**
Linux 패치의 경우 Systems Manager는 패치 기준 규칙과 *각* 관리형 노드에서 승인 및 거부된 패치 목록을 평가합니다. 서비스가 관리형 노드에 구성된 리포지토리에서 알려진 패치 및 업데이트 목록을 검색하기 때문에 Systems Manager는 각 노드에서 패치를 평가해야 합니다.
**Windows**
Windows 패치의 경우 Systems Manager는 패치 기준 규칙과 승인/거부된 패치 목록을 *직접 서비스에서* 평가합니다. Windows 패치는 단일 리포지토리(Windows 업데이트)에서 가져오기 때문에 이것이 가능합니다.
## 차이점 2: `Not Applicable` 패치
Linux 운영 체제에서는 사용할 수 있는 패키지가 매우 많기 때문에 Systems Manager가 [*해당 사항 없음(Not Applicable)*] 상태의 패치에 대해서는 세부 정보를 보고하지 않습니다. 예를 들어 `Not Applicable` 패치는 인스턴스에 Apache가 설치되어 있지 않은 경우 Apache 소프트웨어용 패치입니다. Systems Manager는 요약에서 `Not Applicable` 패치 수를 보고하지만 관리형 노드에 대해 [DescribeInstancePatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstancePatches.html) API를 호출하면 상태가 `Not Applicable`인 패치는 반환된 데이터에 포함되지 않습니다. Windows에서는 이러한 동작이 다릅니다.
## 차이점 3: SSM 문서 지원
`AWS-ApplyPatchBaseline` Systems Manager 문서(SSM 문서)는 Linux 관리형 노드를 지원하지 않습니다. Linux, macOS 및 Windows Server 관리형 노드에 패치 기준을 적용하기 위해 권장되는 SSM 문서는 `AWS-RunPatchBaseline`입니다. 자세한 내용은 [관리형 노드 패치를 위한 SSM 명령 문서](patch-manager-ssm-documents.md) 및 [패치를 위한 SSM 명령 문서: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md)(을)를 참조하세요.
## 차이점 4: 애플리케이션 패치
Patch Manager는 운영 체제를 패치하는 데 중점을 둡니다. 그러나 Patch Manager를 사용하여 관리형 노드의 일부 애플리케이션을 패치할 수도 있습니다.
**Linux**
Linux 운영 체제에서 Patch Manager는 업데이트를 위해 구성된 리포지토리를 사용하며 운영 체제와 애플리케이션 패치를 구분하지 않습니다. Patch Manager를 사용하여 업데이트를 가져올 리포지토리를 정의할 수 있습니다. 자세한 내용은 [대체 패치 소스 리포지토리를 지정하는 방법(Linux)](patch-manager-alternative-source-repository.md) 섹션을 참조하세요.
**Windows**
Windows Server 관리형 노드에서는 Microsoft Word 2016, Microsoft Exchange Server 2016과 같이 Microsoft에서 출시한 애플리케이션에 대해 *승인된* 패치와 *거부된* 패치 예외는 물론, 승인 규칙을 적용할 수 있습니다. 자세한 내용은 [사용자 정의 패치 기준 작업](patch-manager-manage-patch-baselines.md) 섹션을 참조하세요.
## 차이점 5: 사용자 지정 패치 기준의 거부된 패치 목록 옵션
사용자 지정 패치 기준을 생성할 때 **거부된 패치** 목록에 하나 이상의 패치를 지정할 수 있습니다. Linux 관리형 노드의 경우 패치가 기준에서 허용되는 다른 패치의 종속 항목인 경우 설치될 수 있도록 선택할 수도 있습니다.
하지만 Windows Server에서는 패치 종속성의 개념을 지원하지 않습니다. Windows Server에 대한 사용자 지정 기준선의 **거부된 패치** 목록에 패치를 추가할 수 있지만 (1) 거부된 패치가 관리형 노드에 이미 설치되어 있는지 여부와 (2) **거부된 패치 작업**에 대해 선택하는 옵션에 따라 결과가 달라집니다.
Windows Server의 거부된 패치 옵션에 대한 자세한 내용은 다음 표를 참조하세요.
| 설치 상태 | 옵션: “종속성으로 허용” | 옵션: “블록” |
| --- | --- | --- |
| 패치가 이미 설치됨 | 보고된 상태: INSTALLED\$1OTHER | 보고된 상태: INSTALLED\$1REJECTED |
| 패치가 아직 설치되지 않음 | 패치 건너뜀 | 패치 건너뜀 |
Microsoft에서 릴리스하는 Windows Server에 대한 각 패치에는 일반적으로 설치하는 데 필요한 모든 정보가 포함됩니다. 하지만 경우에 따라 수동으로 설치해야 하는 사전 필수 패키지가 필요할 수 있습니다. Patch Manager는 이러한 사전 필수 조건에 대해 정보를 보고하지 않습니다. 관련 정보는 Microsoft 웹 사이트의 [Windows 업데이트 문제 해결](https://learn.microsoft.com/en-us/troubleshoot/windows-client/installing-updates-features-roles/windows-update-issues-troubleshooting)을 참조하세요.