이 글의 목적은 Windows 10·Windows 11에서 배달 최적화의 피어 캐시(P2P) 기능이 다른 캐시 기능·정책·네트워크 환경과 충돌하여 업데이트가 느려지거나 실패하는 문제를 원인별로 진단하고, 현장에서 바로 적용 가능한 복구 절차와 재발 방지 기준을 체계적으로 제공하는 것이다.
1. 배달 최적화 피어 캐시 충돌이 발생하는 구조
배달 최적화는 Windows 업데이트·앱 업데이트 등 다운로드 트래픽을 줄이기 위해, Microsoft 서버(HTTP/HTTPS)에서 받는 방식과 같은 네트워크의 다른 PC(피어)에서 받는 방식을 함께 사용하는 기능이다. 기본 설정에서는 같은 NAT(일반적으로 같은 공유기·같은 사무실 라우터 구간) 안에서 피어 공유가 동작할 수 있다.
문제는 피어 캐시가 “네트워크 경로, 포트, 방화벽 규칙, 캐시 저장소, 정책(그룹 정책/MDM), 다른 캐시 솔루션(예: 구성 관리자 피어 캐시, BranchCache, 연결된 캐시 서버)”와 맞물려 동작한다는 점이다. 이 요소 중 하나라도 엇갈리면 피어 검색은 시도하지만 실제 전송이 실패하거나, 캐시 데이터가 꼬이거나, 정책이 서로 다른 값을 강제로 적용하면서 충돌이 발생할 수 있다.
대표적인 충돌 시나리오
| 시나리오 | 현상 | 핵심 원인 |
|---|---|---|
| VPN 사용 중 피어 캐시 시도 | 다운로드 0% 정체, 매우 느림, 반복 재시도 | VPN 경로로 피어 검색/연결이 차단되거나 지연됨 |
| 사내 방화벽/엔드포인트 보안이 피어 포트 차단 | 로컬에서만 느리거나 피어 수신이 전혀 안 됨 | 피어 통신 포트 또는 NAT 통과 트래픽이 차단됨 |
| 구성 관리자(예: ConfigMgr) 피어 캐시/경계 그룹 설정과 혼재 | 일부 PC만 실패, 특정 서브넷에서만 실패 | DO 그룹/경계 그룹/대체 다운로드 URL 정책 충돌 |
| 캐시 저장소 손상 또는 용량 제한 과도 | 다운로드가 반복 실패, 디스크 사용량 급증 후 롤백 | 캐시 DB/파일 손상, 최소 디스크/캐시 크기 정책 불일치 |
| 프록시/SSL 검사 장비와 바이트 범위 요청 충돌 | 특정 업데이트만 실패, 끊김이 잦음 | 부분 다운로드(바이트 범위) 처리 제한 또는 변조 |
2. 증상으로 빠르게 분류하는 진단 체크
피어 캐시 충돌은 한 번에 모든 원인을 찾기 어렵다. 현장에서는 “어느 단계에서 막히는지”를 먼저 분류하면 복구 시간이 크게 줄어든다. 아래 체크는 관리 권한 기준이며, 사내 정책에 따라 일부 명령이 제한될 수 있다.
2-1. 서비스 상태 확인
배달 최적화의 핵심 서비스는 DoSvc(Delivery Optimization Service)이다. 서비스가 중지되어 있으면 피어 캐시뿐 아니라 다운로드 경로 자체가 비정상화될 수 있다.
sc query DoSvc sc query wuauserv rem 실행 중이 아니면 시작 시도 net start DoSvc net start wuauserv2-2. 피어 포트 리스닝 여부 확인
피어 캐시는 기본적으로 TCP 7680 포트를 사용한다. 같은 망에서 피어 공유가 활성화된 PC라면, 특정 조건에서 7680 포트를 리스닝(대기)할 수 있다. 리스닝이 전혀 없고 정책상 피어가 켜져 있다면 방화벽/보안 제품 또는 정책 충돌을 의심해야 한다.
netstat -ano | findstr :7680 rem PID 확인 후 프로세스 매핑 tasklist /fi "PID eq 1234"2-3. 피어 캐시가 원인인지 확인하는 가장 빠른 방법
가장 빠른 분기 방법은 “피어 기능을 일시적으로 끄고 업데이트가 정상화되는지”를 확인하는 것이다. 단, 완전 비활성화가 아니라 ‘피어 공유만 잠시 끄는’ 방식으로 테스트해야 한다.
설정 경로는 Windows 버전에 따라 표기가 다르지만 일반적으로 다음 흐름이다.
| 항목 | 경로 | 테스트 목적 |
|---|---|---|
| 피어 공유 끄기 | 설정 > Windows 업데이트(또는 업데이트) > 고급 옵션 > 배달 최적화 > 다른 PC에서 다운로드 허용 끔 | 피어 통신이 문제인지 즉시 분리 |
| 다운로드는 유지 | 동일 화면에서 다운로드 자체를 막지 않음 | 업데이트 기능은 정상 유지 |
이 상태에서 업데이트가 즉시 정상화되면 “피어 통신(포트/방화벽/VPN/그룹/정책)” 축으로 집중 진단하는 것이 효율적이다. 반대로 계속 실패하면 “Windows Update 구성 요소, 프록시/WSUS/네트워크, 캐시 손상” 축으로 옮겨야 한다.
3. 1차 복구: 캐시 초기화로 충돌 제거
피어 캐시 충돌의 상당수는 캐시 파일/메타데이터가 꼬이거나, 정책 변경 후 기존 캐시가 남아 충돌하는 형태로 발생한다. 이때 가장 효과적인 1차 조치는 “캐시 초기화 + 서비스 재시작”이다.
3-1. GUI로 배달 최적화 파일 삭제
사용자 PC에서 빠르게 적용해야 할 때는 GUI 삭제가 안전하다.
| 단계 | 작업 | 기대 효과 |
|---|---|---|
| 1 | 설정 > 시스템 > 저장소 | 임시 파일 관리로 이동 |
| 2 | 임시 파일 > “배달 최적화 파일” 선택 | DO 캐시 정리 대상 선택 |
| 3 | 파일 제거 실행 | 캐시 데이터 삭제로 충돌 완화 |
3-2. PowerShell로 캐시 완전 초기화(관리자 권한)
대량 PC에 적용하거나, GUI가 막혀 있거나, 캐시가 재발하는 환경에서는 명령 기반 초기화가 유리하다. 아래는 캐시를 삭제하고 관련 데이터 정리를 유도하는 방식이다.
PowerShell -NoProfile -ExecutionPolicy Bypass -Command ^ "Get-Command Delete-DeliveryOptimizationCache -ErrorAction SilentlyContinue | Out-Null; ^ if (Get-Command Delete-DeliveryOptimizationCache -ErrorAction SilentlyContinue) { ^ Delete-DeliveryOptimizationCache -Force; ^ } else { ^ Write-Host 'Delete-DeliveryOptimizationCache cmdlet not found on this OS build.'; ^ }"cmdlet이 없는 빌드에서는 다음 “서비스 중지 후 캐시 폴더 삭제” 방법을 사용한다.
3-3. 서비스 중지 후 캐시 폴더 수동 삭제
rem 1) 서비스 중지 net stop DoSvc rem 2) 캐시 경로(대표 경로) 삭제 rem 환경에 따라 하위 폴더 구성이 다를 수 있음 rd /s /q "C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Microsoft\Windows\DeliveryOptimization\Cache" rd /s /q "C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Microsoft\Windows\DeliveryOptimization\State" rem 3) 서비스 시작 net start DoSvc초기화 이후에는 업데이트를 한 번 실행해 캐시가 재생성되는지 확인해야 한다. 재생성은 정상이며, 동일 증상이 반복되면 다음 장의 “정책 충돌” 또는 “네트워크 충돌”로 넘어가야 한다.
4. 2차 복구: 정책 충돌(다운로드 모드/그룹/최소 사양) 정합성 맞추기
현장에서 가장 흔한 재발 원인은 “정책 값이 PC마다 다르게 적용되거나, 한 장치에서는 MDM이, 다른 장치에서는 그룹 정책이 덮어쓰는” 상황이다. 피어 캐시를 정상 운영하려면 최소한 다운로드 모드, 그룹 범위, 캐시 참여 조건이 일관되어야 한다.
4-1. 다운로드 모드로 충돌을 즉시 안정화하기
다운로드 모드는 배달 최적화가 “피어를 어느 범위에서 찾을지”를 결정한다. 충돌 상황에서는 우선 범위를 좁혀 안정화한 뒤 점진적으로 확대하는 전략이 실무적으로 안전하다.
| 운영 목표 | 권장 설정 | 설명 |
|---|---|---|
| 장애 복구 우선(피어 일시 중지) | HTTP만 사용(피어 공유 끔) | 피어 통신을 배제하여 충돌 범위를 즉시 축소한다. |
| 사내 동일 VLAN만 피어 허용 | 로컬 네트워크 범위 | 같은 NAT/근거리에서만 공유하여 방화벽 이슈를 최소화한다. |
| 도메인/조직 단위로 그룹 제한 | 그룹 기반 구성 | 그룹 ID 또는 조직 정책으로 공유 범위를 통제한다. |
4-2. 그룹 정책/레지스트리로 현재 적용값 확인
정책 진단은 “현재 PC에 무엇이 적용되었는지” 확인이 먼저이다. 그룹 정책 결과(gpresult)와 레지스트리 값을 함께 보면 충돌 지점을 빠르게 찾을 수 있다.
rem 그룹 정책 결과(컴퓨터 정책) 확인 gpresult /h "%TEMP%\gpresult.html" rem 정책 레지스트리(있으면 정책으로 강제 중인 상태) reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\DeliveryOptimization" /s같은 조직에서 특정 PC만 값이 다르게 나오면, OU 링크/보안 필터링/MDM 적용 범위/로컬 정책이 원인일 가능성이 높다. 이 경우 “정상 PC 1대와 문제 PC 1대의 결과를 비교”하면 가장 빨리 해결된다.
4-3. 최소 RAM/디스크 조건으로 인한 ‘참여 불가’ 충돌 제거
피어 캐시는 일정 조건(최소 RAM, 최소 디스크, 배터리 상태 등)에서만 참여하도록 제한할 수 있다. 일부 PC에서 이 조건을 충족하지 못하면, 한쪽에서는 피어를 제공한다고 생각하지만 다른 쪽은 참여하지 못해 “피어 탐색 재시도”가 늘어나고 체감 성능이 떨어질 수 있다.
실무에서는 다음 기준을 권장한다.
| 항목 | 권장 운영 기준 | 설명 |
|---|---|---|
| 최소 RAM 조건 | 사내 표준 PC 사양 이하로 설정하지 않음 | 저사양 PC를 피어로 삼지 않아 성능과 안정성을 확보한다. |
| 최소 디스크 조건 | OS 드라이브 여유 공간 고려 | 캐시가 디스크를 압박하면 업데이트 실패가 재발한다. |
| 캐시 크기 제한 | 업데이트 규모에 맞는 최소치 확보 | 기능 업데이트가 큰 환경은 캐시 제한이 너무 작으면 반복 재다운로드가 발생한다. |
5. 3차 복구: 방화벽·포트·VPN·프록시로 인한 피어 통신 충돌 해결
피어 캐시는 내부적으로 피어 요청 수신을 위해 특정 포트를 사용한다. 또한 피어 범위를 넓히는 구성에서는 NAT 통과 트래픽이 추가로 필요할 수 있다. 이 부분이 차단되면 “피어 캐시를 켠 순간부터” 업데이트가 더 느려지는 역효과가 발생할 수 있다.
5-1. 필수 포트 기준 정리
| 구분 | 프로토콜/포트 | 용도 | 차단 시 영향 |
|---|---|---|---|
| 업데이트 다운로드 | TCP 80/443 | Microsoft 서버에서 HTTP/HTTPS 다운로드 | 업데이트 자체가 실패하거나 지연된다. |
| 피어 캐시(로컬 피어) | TCP 7680 | 피어 간 콘텐츠 요청/전송 | 피어 기능이 동작하지 않고 서버 다운로드로만 진행된다. |
| NAT 통과(일부 구성) | UDP 3544 | 피어 범위를 그룹/인터넷으로 확장 시 NAT 통과 | 교차 네트워크 피어 연결이 불안정해진다. |
5-2. Windows 방화벽 규칙 점검(기본 점검)
로컬 PC에서 빠르게 확인할 때는 방화벽 프로필(도메인/개인/공용)과 인바운드 규칙을 함께 확인해야 한다. 사내 보안 정책에 따라 규칙 이름은 다를 수 있으나, 핵심은 “TCP 7680 인바운드/아웃바운드가 허용되는지”이다.
rem 방화벽 프로필 상태 확인 netsh advfirewall show allprofiles rem 7680 관련 규칙 탐색(영문/국문 환경에 따라 결과는 다를 수 있음) netsh advfirewall firewall show rule name=all | findstr /i 76805-3. VPN 사용 시 피어 캐시 예외 처리
VPN이 켜진 상태에서 피어 캐시를 시도하면, 피어 탐색이 VPN 인터페이스를 타거나(정책/라우팅에 따라), VPN이 로컬 브로드캐스트/피어 연결을 차단하여 재시도가 증가할 수 있다. 이 경우 운영 정책으로 다음 중 하나를 선택해야 한다.
| 선택지 | 권장 상황 | 운영 효과 |
|---|---|---|
| VPN 연결 중 피어 캐시 비활성화 | 재택/외근 비중이 높고 VPN이 항상 켜짐 | 충돌을 근본적으로 제거하고 안정성을 확보한다. |
| VPN 예외(로컬 네트워크 허용) 정책 적용 | 사내망에서도 VPN을 상시 사용하는 보안 설계 | 정책 설계 난이도는 높지만 피어 효과를 유지할 수 있다. |
5-4. 프록시 환경 점검(바이트 범위 요청 충돌)
업데이트 콘텐츠는 대용량이며, 중단 재개를 위해 부분 다운로드(바이트 범위 요청)를 활용하는 경우가 많다. 프록시 또는 SSL 검사 장비가 이를 제한하면 특정 업데이트만 실패하거나 재시도가 반복될 수 있다. 다음 명령으로 WinHTTP 프록시 상태를 우선 확인한다.
netsh winhttp show proxy프록시가 불필요하게 설정되어 있다면(조직 정책과 불일치) 해제 후 재시도한다.
rem 프록시 초기화(조직 정책에 반하지 않는 경우에만 수행) netsh winhttp reset proxy6. 구성 관리자 피어 캐시·BranchCache·연결된 캐시와의 충돌 분리 전략
기업 환경에서는 배달 최적화 외에도 다음과 같은 캐시/배포 최적화 구성 요소가 함께 존재할 수 있다.
- 구성 관리자 피어 캐시(클라이언트 간 콘텐츠 공유)
- BranchCache(지점 캐싱)
- 연결된 캐시(캐시 서버/어플라이언스 기반)
문제는 “기술이 나쁘다”가 아니라, 서로 다른 철학의 캐시가 같은 단말에서 동시에 활성화되면 정책·포트·콘텐츠 소유권이 충돌할 수 있다는 점이다. 실무에서는 다음 원칙이 가장 안전하다.
6-1. 한 구간에 한 가지 공유 메커니즘을 우선 적용
| 환경 | 권장 우선순위 | 설명 |
|---|---|---|
| 소규모 사무실(서버 없음) | 배달 최적화 로컬 피어 | 구성 단순, 효과 빠름, 운영 부담 낮음 |
| 대규모/다지점(대역폭 민감) | 연결된 캐시 또는 중앙 캐시 + 배달 최적화 보조 | 서버 기반 캐시로 트래픽을 예측 가능하게 관리 |
| 구성 관리자 중심 배포 | 경계 그룹 설계 후 DO 통합 또는 피어 캐시 중 택1 | 경계 그룹/정책 혼재를 최소화해야 장애가 줄어듦 |
6-2. 충돌이 의심될 때의 분리 테스트 순서
기술 요소가 많을수록 “한 번에 다 고치려다” 시간이 늘어난다. 다음 순서로 하나씩 분리 테스트하면 원인 추적이 빠르다.
| 순서 | 테스트 | 판단 |
|---|---|---|
| 1 | 피어 공유만 끄고(HTTP 다운로드 유지) 업데이트 재시도 | 정상화되면 피어 통신/정책 충돌이다. |
| 2 | 캐시 초기화(3장 절차) 후 동일 정책에서 재시도 | 정상화되면 캐시 손상/정책 변경 잔재이다. |
| 3 | 방화벽/포트/VPN 조건을 바꾸어 재시도 | 조건에 따라 변하면 네트워크 경로 충돌이다. |
| 4 | 구성 관리자 피어 캐시/BranchCache 등 다른 공유 기능을 일시 중지 후 재시도 | 정상화되면 다중 캐시 혼재 충돌이다. |
7. 긴급 안정화: 피어 캐시를 끄고도 업데이트는 정상 유지하는 방법
업무에 즉시 영향을 주는 장애라면, 피어 캐시를 잠시 끄고 업데이트를 서버(HTTP/HTTPS)에서만 받도록 전환하는 것이 가장 빠른 완화책이다. 이는 “배달 최적화 자체를 완전 제거”가 아니라 “피어 공유만 제한”하는 접근이다.
7-1. 사용자 설정 기반(개별 PC)
설정 화면에서 “다른 PC에서 다운로드 허용”을 끄면 된다. 이 조치는 피어 공유만 제한하며, 업데이트 기능을 막지 않는다.
7-2. 정책 기반(조직)
조직 운영에서는 그룹 정책 또는 MDM으로 다운로드 모드를 “피어 없는 모드”로 고정하여 편차를 제거해야 한다. 또한 정책이 바뀐 뒤에는 3장의 캐시 초기화를 함께 수행해야 잔재 충돌이 줄어든다.
rem 정책 레지스트리(예시 확인용) reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\DeliveryOptimization" /v DODownloadMode정책 적용 후에는 재부팅 또는 정책 갱신이 필요할 수 있다.
gpupdate /force8. 재발 방지 운영 체크리스트
피어 캐시 충돌은 “한 번 고치고 끝”이 아니라, 네트워크/정책/보안 제품 변경 때 재발하기 쉽다. 아래 체크리스트를 표준 운영 문서로 만들어두면 같은 문제가 반복되는 것을 크게 줄일 수 있다.
| 점검 항목 | 권장 기준 | 점검 주기 |
|---|---|---|
| 정책 정합성 | 다운로드 모드/그룹 범위/최소 사양 조건이 조직 표준과 일치 | 분기 1회 또는 정책 변경 시 |
| 포트/방화벽 | 동일 VLAN 내 TCP 7680 허용 여부 확인, 필요 시 범위 제한 | 보안 정책 변경 시 |
| VPN 예외 정책 | VPN 연결 중 피어 캐시 사용 여부를 조직 표준으로 확정 | VPN 솔루션 변경 시 |
| 캐시 용량 | 기능 업데이트 규모를 고려해 캐시 제한이 과도하지 않음 | 반기 1회 |
| 다중 캐시 혼재 | 구성 관리자 피어 캐시/BranchCache/연결된 캐시와 역할 분담 명확화 | 배포 구조 변경 시 |
| 장애 대응 표준 | 캐시 초기화(3장) + 피어 제한 테스트(2-3) 절차를 문서화 | 상시 |
FAQ
피어 캐시 충돌인지, Windows Update 자체 문제인지 어떻게 구분하나?
가장 빠른 방법은 “피어 공유만 끄고 업데이트를 재시도”하는 것이다. 이때 업데이트가 정상화되면 피어 통신(포트/방화벽/VPN/정책) 축의 문제일 가능성이 높다. 반대로 동일하게 실패하면 Windows Update 구성 요소, 프록시/WSUS, 네트워크 DNS 등 다른 원인을 우선 점검해야 한다.
캐시를 지우면 다운로드가 더 느려지지 않나?
일시적으로는 다시 내려받아야 하므로 느려질 수 있다. 그러나 충돌 상태에서는 캐시가 남아 있을수록 재시도와 실패가 반복되어 총 소요 시간이 더 늘어난다. 장애 복구 관점에서는 캐시 초기화가 평균 복구 시간을 줄이는 경우가 많다.
7680 포트를 열면 보안상 위험하지 않나?
무조건 전체 네트워크에 개방하는 방식은 권장하지 않는다. 실무에서는 도메인/개인 프로필에서만 허용하거나, 사내 업데이트 VLAN 내부로만 제한하는 방식으로 운영한다. 또한 피어 캐시가 불필요한 구간(게스트망, 외부망, 민감 구역)에서는 피어 공유를 끄는 것이 안전하다.
VPN을 켠 상태에서도 피어 캐시를 쓰고 싶다. 가능하나?
가능하지만 네트워크 설계 난이도가 높다. VPN이 로컬 브로드캐스트/피어 연결을 차단하거나 라우팅을 바꾸면 피어 탐색이 실패할 수 있다. 운영 안정성을 우선하면 VPN 연결 중에는 피어 캐시를 끄고, 사내망 접속 시에만 피어 캐시를 허용하는 표준이 가장 흔하다.
일부 PC에서만 계속 재발한다. 어떤 점을 먼저 봐야 하나?
첫째는 정책 적용 편차이다. 정상 PC와 문제 PC의 gpresult 및 정책 레지스트리를 비교하면 OU 링크, 보안 필터, MDM 적용 범위 차이를 빠르게 찾을 수 있다. 둘째는 디스크 여유 공간과 캐시 제한이다. 특정 PC만 용량이 부족하면 기능 업데이트에서 반복 실패가 발생하기 쉽다.
피어 캐시를 완전히 끄려면 DoSvc 서비스를 꺼도 되나?
긴급 상황에서 서비스 비활성화를 고려할 수는 있으나, 업데이트 경험 전반에 부작용이 생길 수 있어 권장되지 않는다. 실무에서는 우선 “피어 공유만 끄고” 서버 다운로드로 정상화한 뒤, 정책으로 일관되게 관리하는 방식이 안전하다.
조직에서 표준 운영을 하려면 무엇을 문서화해야 하나?
다운로드 모드(피어 범위), 포트/방화벽 허용 범위, VPN 예외 원칙, 캐시 크기 기준, 장애 발생 시 캐시 초기화 및 분리 테스트 절차를 한 장짜리 운영 표준으로 만들면 재발 대응 시간이 크게 줄어든다.