콘텐츠로 이동

Cross-Device Resume 끄는 방법

목차

간단한 답변

섹션 제목: “간단한 답변”

Cross-Device Resume는 Windows MDM 정책을 통해 비활성화할 수 있습니다. 우리의 실험에서 이를 적용하고 재부팅한 뒤 로그인한 후, CrossDeviceResume.exe는 153초의 관찰 시간 동안 실행되지 않았습니다. 기능을 다시 허용하고 재부팅하자 프로세스가 다시 나타났습니다.

BoosterX → 최적화 → 트윅 → Cross-Device Resume를 통해 설정을 적용하는 것이 더 간단합니다: 비활성화를 선택하고 **«적용»**을 누른 뒤 PC를 재부팅하십시오. 이 연구는 BoosterX의 구현이 아니라 Windows의 공개된 메커니즘을 검증한 것입니다: 프로그램이 설정을 어떻게 적용하는지는 이 시리즈에서 시험되지 않았으며 기사에서도 주장하지 않습니다. 적용 및 되돌리기에 대한 자세한 내용은 설정 페이지에 있습니다.

무엇을 검증했는가

섹션 제목: “무엇을 검증했는가”

우리는 Resume 알림의 사라짐뿐만 아니라 Windows 로그인 시 별도 프로세스의 정상 실행이 방지되는지에도 관심이 있었습니다. 이는 서로 다른 결과입니다: 프로그램은 실행되었다가 즉시 종료될 수도 있고, 알림 없이 계속 작동할 수도 있으며, 실행 요청 자체를 받지 않을 수도 있습니다.

Microsoft는 DisableCrossDeviceResume를 휴대폰에서의 작업 이어가기 알림을 끄는 사용자 정책으로 설명하며 재부팅이 필요하다고 명시합니다. 문서화된 것: 정책의 용도와 적용 시점. 우리 실험에서 관찰된 것: 별도 프로세스의 실행 부재. Microsoft 설명.

연구 범위

섹션 제목: “연구 범위”
조건 검증된 환경
시스템 Windows 11 Pro 25H2, 빌드 26200.9445
구성 요소 CrossDeviceResume 2607.27000.0.0
스탠드 VMware 가상 머신 한 대
시나리오 동일 사용자의 재부팅 및 대화형 로그인
관찰 프로세스 목록 및 생성 감사, 이벤트 4688
실험 날짜 2026-09-17

이것은 FPS나 메모리 소비 테스트가 아닌 기능 실험입니다. 물리적 CPU 모델, 가상 리소스 구성 및 드라이버 버전은 게시된 표본에 포함되지 않았습니다. 검증 없이 물리적 PC, 다른 빌드 또는 다른 실행 방식에 결과를 전이해서는 안 됩니다.

어떻게 검증했는가

섹션 제목: “어떻게 검증했는가”

먼저 작동 중인 프로세스와 정책의 초기 상태를 기록했습니다. 그런 다음 Windows의 로컬 관리 메커니즘을 통해 금지 정책을 적용하고, 작업의 성공 여부를 확인하고 상태를 다시 읽었습니다. 재부팅 후 대화형 로그인과 셸 시작을 기다린 뒤 프로세스와 생성 로그를 확인했습니다.

역방향 대조를 위해 Resume를 허용하고 로그인과 함께 재부팅을 반복했습니다. 별도로 기능을 다시 금지하고 이미 작동 중인 프로세스를 명시적으로 종료한 뒤 가능한 재실행을 관찰했습니다. 프로세스 종료는 독립적인 행위였으며, 이를 정책의 결과로 돌릴 수 없습니다.

레지스트리 기록이 아직 비활성화를 증명하지 않는 이유

섹션 제목: “레지스트리 기록이 아직 비활성화를 증명하지 않는 이유”

레지스트리에 필요한 값이 존재한다고 해서 Windows가 이를 유효한 MDM 정책으로 받아들였다는 것이 확인되지는 않습니다. 따라서 «값은 기록되었지만 CrossDeviceResume 가 여전히 실행된다»는 상황은 이 연구의 결과와 모순되지 않습니다.

게시된 문서에는 이 정책에 대한 일반적인 Registry 설정의 기성 대응이 없습니다. 우리 시리즈에는 모든 직접 기록 변형에 대한 별도의 통제된 비교가 없습니다. 직접 기록은 정책 적용의 대체로 확인되지 않았습니다, 그러나 어떤 레지스트리 수정이든 항상 무의미하다고 단정할 근거도 없습니다. 작동 결과는 정책 관리 메커니즘을 통해 얻어졌으며, 상태 확인과 로그인 후 실제 실행 확인이 이루어졌습니다.

시스템 DLL과 실험실 우회의 역할

섹션 제목: “시스템 DLL과 실험실 우회의 역할”

실험에서는 내장된 mdmlocalmanagement.dll를 사용했습니다. 이것은 로컬 관리 인터페이스인 RegisterDeviceWithLocalManagement와 ApplyLocalManagementSyncML를 제공합니다. 이들의 선언은 공개 Windows SDK 헤더에서 확인할 수 있습니다. 시스템 라이브러리가 정책 적용 요청을 받아들였으며, 서드파티 DLL을 다운로드하거나 Windows 파일을 교체하거나 실행 코드를 패치할 필요가 없었습니다. Intune과 클라우드 관리는 실험에서 사용되지 않았습니다.

검증된 Windows Pro에서 일반적인 로컬 등록은 «지원되지 않음»을 반환했습니다. 실험실에서는 Embedded Mode를 일시적으로 활성화하여 이 제한을 통과한 뒤, 정책을 적용하고 모드의 원래 매개변수를 복원했습니다. Microsoft는 Embedded Mode를 특수 장치 Windows IoT의 맥락에서 설명합니다. Pro에서의 이러한 사용은 Microsoft가 확인한 지원 시나리오가 아닙니다.

임시 모드 복원은 로컬 관리 등록 및 할당된 정책을 삭제하지 않았습니다. 검증된 시나리오를 벗어난 임시 모드 활성화의 부작용은 연구되지 않았습니다. 여기에는 실험의 원리가 설명되어 있으며; 명령, 요청 내용 및 우회 재현 순서는 게시되지 않습니다.

결과

섹션 제목: “결과”
검증 결과 및 결론의 경계
금지 정책 적용 작업 성공, 역방향 읽기로 상태 확인
이미 작동 중인 프로세스 자동으로 종료되지 않음
금지 상태에서 재부팅 및 로그인 프로세스 부재; 셸 시작 후 153초 동안 실행이 등록되지 않음
허용, 재부팅 및 로그인 프로세스 나타남, 생성이 로그로 확인됨
재차 금지 및 별도 프로세스 종료 10초 후 프로세스 부재; 120초 관찰 동안 재실행이 발견되지 않음
스탠드 완전 롤백 VM 스냅샷으로 초기 상태 복원 및 확인

표본에는 VM 한 대와 검증 순서 하나가 있습니다. 120초 간격 내의 반복 관찰은 독립적인 실험이 아닙니다. 두 번째 컴퓨터에서의 독립적 재현은 없습니다.

확인된 것

섹션 제목: “확인된 것”
  • 검증된 시나리오에서 정책은 재부팅 및 로그인 후 별도 프로세스의 정상 실행을 방지했습니다.
  • 기능의 역방향 허용은 동일한 스탠드에서 실행을 되돌렸습니다.
  • 정책 적용 자체만으로는 이미 작동 중인 프로세스를 종료하지 않습니다.
  • 얻은 결과를 위해 시스템 DLL 교체나 EXE 패치가 필요하지 않았습니다.

방지된 실행은 관찰된 시나리오에서 이 프로세스의 작동을 배제합니다. 이는 FPS 측정 없이도 불필요한 백그라운드 기능을 비활성화한 구체적인 효과입니다.

확인되지 않은 것

섹션 제목: “확인되지 않은 것”

FPS 증가, frametime 변화, 총 CPU 부하 및 RAM 절약은 측정되지 않았습니다. EXE 수동 실행, 모든 대체 활성화 방식, ShellHost 내부의 Resume 배치 및 다른 계정 또는 SYSTEM에서의 작동은 검증되지 않았습니다. 이 시리즈에는 기성 BoosterX 인터페이스를 통한 적용에 대한 별도의 쌍대 시험이 없었습니다: 표는 실험실 Windows 메커니즘을 설명합니다.

제한 사항

섹션 제목: “제한 사항”

검증 날짜 기준으로 Microsoft는 이 정책을 Windows Insider Preview에 적용 가능한 것으로 표시합니다. 명시된 Windows 11 Pro 25H2에서의 관찰은 공식 지원 매트릭스를 대체하지 않습니다. 계획되었던 다른 VM에서의 검증은 이루어지지 않았으므로 그에 대한 결과는 없습니다. 153초 동안 이벤트가 없다고 해서 모든 실행이 영구히 금지된다는 의미는 아닙니다: 확인된 효과는 재부팅 및 로그인 후의 정상 실행에 관한 것이며, 다른 방식의 프로세스 실행은 이 연구에서 다루지 않았습니다.

이 기사는 BoosterX가 자체 설정을 어떤 방식으로 적용하는지 확립하지 않습니다. BoosterX 카드와 여기서 검증된 MDM 정책 사이의 연관성은 실험 계획에 포함되지 않았습니다; 프로그램이 이와 동일한 메커니즘을 사용하는지에 대한 판단은 애플리케이션의 실제 동작에 대한 별도의 검증이 필요합니다.

비활성화는 Resume에 관한 것입니다. 이를 전체 «휴대폰 연결» 또는 Windows의 전체 장치 간 인프라 비활성화로 설명할 수 없습니다.

실용적 결론

섹션 제목: “실용적 결론”

휴대폰에서의 작업 이어가기를 사용하지 않는다면 Resume 비활성화는 타당합니다. 검증된 스탠드에서 MDM 정책은 정상 실행을 피할 수 있게 했습니다. 사용자에게는 정책 저장소를 수동으로 실험하는 것보다 BoosterX의 기존 설정을 선택하고 PC를 재부팅하는 것이 더 간단합니다. 자신의 Windows 버전에서 결과를 확인하십시오.

상태 복원

섹션 제목: “상태 복원”

실험에서 기능 허용과 재부팅은 프로세스 실행을 되돌렸습니다. 그런 다음 VM을 원본 스냅샷에서 완전히 복원했습니다: 검증 중 할당된 정책의 부재, 모드의 초기 상태, 임시 자동 로그인의 취소 및 프로세스의 복귀를 확인했습니다.

BoosterX에서 동일한 카드의 활성화는 적용 및 재부팅 후 Resume를 허용합니다. 이는 스냅샷 롤백의 완전한 대응물이 아닙니다: 실험실 정책 적용으로 생성된 로컬 관리 등록은 다른 도구의 이전에 적용된 제한과 마찬가지로 유지됩니다. 되돌리기에 대한 자세한 내용은 설정 페이지에 있습니다.

공개 1차 출처

섹션 제목: “공개 1차 출처”

연구와 사용된 도구는 BoosterX 개발자에게 속하므로, 개발자는 결과에 직접적인 이해관계가 있습니다. 방법론과 적용 가능성의 경계는 위에 설명되어 있으며, 결론은 공개 데이터와 나열된 공개 출처를 통해 검증할 수 있습니다. Microsoft는 이 연구의 저자가 아니며 그 결론을 확인하지 않았습니다.

검증 날짜 및 변경 이력

섹션 제목: “검증 날짜 및 변경 이력”

2026-09-17: 첫 번째 버전; 공개 출처 검증, VM 한 대의 결과, 결론의 경계 및 실행 역방향 검증 게시.

2026-09-19: 독립적 대조 후 결론의 틀 수정: BoosterX의 구체적인 메커니즘에 대한 주장 제거. 연구는 프로그램에서의 설정 구현이 아니라 Windows의 공개 MDM 정책과 그 적용의 실험실 경로를 검증합니다; 실험 결과, 결론의 경계 및 출처는 유지되고, 확인된 효과의 한계에 대한 유보 사항이 명확해졌습니다.

2026-09-20: 이해충돌 면책 조항 강화: 연구와 도구를 소유한 개발자의 직접적인 이해관계를 명시적으로 인정; description 축약.