요약:
Microsoft는 시작 프로세스 중에 불필요한 임시 프로세스를 취소하여 응용 프로그램이 사용자 작업에 더 빠르게 응답할 수 있도록 하는 Windows 11용 새로운 응용 프로그램 시작 가속화 메커니즘을 개발하고 있습니다. Microsoft Edge 브라우저는 이미 이 기술을 채택하는 데 앞장섰습니다. 브라우저가 여전히 백그라운드에서 실행 중이고 사용자가 작업 표시줄 아이콘, 시작 메뉴 바로 가기 또는 웹 링크를 다시 클릭하면 Windows는 임시 프로세스를 시작한 다음 요청을 프로세스에 전달할 필요 없이 이미 실행 중인 Edge 인스턴스에 직접 요청을 보낼 수 있습니다.
Windows 최신에서는 2026년 10월 17일에 이 변경 사항이 Microsoft에서 Windows Insiders용으로 출시한 최신 Release Preview 미리 보기 업데이트에 나타났다고 보고했습니다. Microsoft는 이를 보다 광범위한 Windows 플랫폼 기능의 첫 번째 단계로 보고 있습니다. 앞으로는 다른 응용 프로그램에서도 유사한 메커니즘을 사용하여 시작 경로를 단축할 수 있습니다.
이 개선 사항은 Microsoft가 10월 16일 Release Preview 채널에 출시한 KB5127936 업데이트에 포함되어 있습니다. 업데이트 설치 후 Windows 11 25H2의 시스템 버전 번호는 26200.9807로, 26H2의 시스템 버전 번호는 26300.9807로 올랐습니다. 하지만 이 기능은 단계적으로 출시되며, 업데이트를 설치하더라도 모든 사용자가 즉시 경험할 수 있는 것은 아닙니다.
애플리케이션이 시작될 때 Windows에서 추가 프로세스를 시작하는 이유는 무엇입니까?
이러한 최적화의 중요성을 이해하려면 먼저 Windows 애플리케이션의 인스턴스 실행 메커니즘을 이해해야 합니다.
많은 Windows 앱에서는 여러 개의 독립 인스턴스를 동시에 열 수 있습니다. 예를 들어, 사용자는 동시에 여러 개의 메모장 창을 시작할 수 있으며 각 창은 독립적으로 실행될 수 있습니다. 그러나 다른 응용 프로그램은 단일 인스턴스 디자인을 채택합니다. 즉, 사용자가 응용 프로그램 아이콘을 반복적으로 클릭하더라도 일반적으로 두 번째 완전한 인스턴스를 만드는 대신 이미 실행 중인 창만 활성화됩니다.
Edge 브라우저는 이러한 유형의 애플리케이션의 전형적인 예입니다. Edge가 이미 실행 중이고 사용자가 브라우저 아이콘을 다시 클릭하면 시스템은 일반적으로 기존 창을 직접 활성화해야 합니다. 클릭이 웹 링크인 경우 해당 링크는 처리를 위해 이미 실행 중인 브라우저로 전달되어야 합니다.
문제는 전통적인 시작 프로세스가 항상 이 작업을 직접적으로 수행하지 않는다는 것입니다.
사용자가 단일 인스턴스 애플리케이션을 다시 시작하면 Windows는 먼저 새 임시 프로세스를 생성할 수 있습니다. 이 프로세스는 애플리케이션이 이미 실행 중인지 확인한 다음 시작 요청을 기존 인스턴스로 전달하고 마지막으로 자체 종료됩니다.
기능적 관점에서 보면 이 임시 프로세스는 중개인 역할만 할 뿐 실제로 애플리케이션의 주요 작업을 수행하지는 않습니다. 그러나 프로세스 생성, 초기화 코드 실행, 실행 상태 확인 및 요청 전달에는 여전히 프로세서 시간과 시스템 리소스가 소비됩니다.
구성이 더 높고 시스템 부하가 낮은 컴퓨터에서는 이러한 추가 오버헤드가 눈에 띄지 않을 수 있습니다. 그러나 컴퓨터가 동시에 여러 프로그램을 실행 중이거나 많은 수의 백그라운드 작업을 처리하거나 약한 프로세서를 사용하는 경우 추가 시작 단계로 인해 응답 지연이 증가할 수 있습니다.
Microsoft 최적화의 핵심은 Windows가 이 중간 링크를 우회하고 이미 실행 중인 애플리케이션에 시작 요청을 직접 보낼 수 있도록 하는 것입니다.
Edge는 새로운 메커니즘을 최초로 채택했으며 백그라운드 시작 시나리오가 가장 많은 이점을 제공합니다.
Microsoft가 발표한 업데이트 노트에 따르면 Edge가 이미 백그라운드에서 실행 중인 경우 Windows는 이제 추가 임시 프로세스를 먼저 시작할 필요 없이 기존 브라우저 인스턴스에 직접 새로운 시작 요청을 보낼 수 있습니다.
Microsoft는 이 중간 단계를 제거하면 특히 컴퓨터가 동시에 여러 프로그램을 실행하고 시스템 부하가 높을 때 시작 경로가 단축되고 Edge가 사용자 작업에 더 잘 반응할 수 있다고 말했습니다.
그러나 이 최적화는 주로 이미 실행 중인 애플리케이션을 다시 시작하는 것을 목표로 하며, 이를 소위 "핫 스타트"라고 합니다.
Edge에는 Startup Boost라는 기능이 있습니다. 이 기능을 사용하면 사용자가 브라우저 창을 닫은 후에도 일부 핵심 프로세스가 백그라운드에서 계속 실행되어 다음에 시작할 때 더 빨리 사용 가능한 상태로 들어갈 수 있습니다. 따라서 사용자가 Edge를 다시 열 때 전체 애플리케이션을 처음부터 로드할 필요가 없는 경우가 많습니다.
이 시나리오에서 새로운 메커니즘은 추가 오버헤드를 더욱 줄여줍니다.
사용자가 방금 컴퓨터를 다시 시작했고 Edge가 백그라운드에서 실행되고 있지 않은 경우에도 처음 시작할 때 일반적인 초기화 및 로드 프로세스를 수행해야 합니다. 이 업데이트는 처음 실행 시 모든 오버헤드를 제거하지 않으므로 모든 경우에 Edge의 속도가 동일하게 향상된다고 단순히 이해할 수는 없습니다.
Microsoft는 이 최적화로 몇 밀리초를 절약할 수 있는지 발표하지 않았으며 일시적으로 다양한 프로세서, 저장 장치 및 시스템 로드 하에서 실제 이점을 정량화할 수 없습니다.
Microsoft는 가속 기능을 더 많은 Windows 애플리케이션으로 확장하기를 희망합니다.
Edge는 이 기술을 적용한 첫 번째 사례일 뿐입니다. Microsoft의 장기적인 목표는 단일 인스턴스 디자인을 사용하는 다른 Windows 응용 프로그램이 동일한 시작 가속 메커니즘을 사용할 수 있도록 하는 것입니다.
Microsoft는 이전에 Microsoft Learn 개발자 문서에 관련 기능을 도입했습니다. 문서 제목은 "가속된 웜 실행을 위해 애플리케이션 등록"입니다. 이는 애플리케이션에 대한 가속화된 웜 실행 기능을 등록한다는 의미입니다. 해당 문서는 2025년 10월 공개된 것으로 보아 이 기술이 최근에 개발된 것이 아님을 알 수 있다.
관련 설계에 따라 애플리케이션은 시작 요청을 수신하기 위해 Windows에 창을 등록할 수 있습니다. 사용자가 시작 메뉴, 작업 표시줄 또는 특정 링크에서 앱을 시작하면 시스템은 이미 실행 중인 인스턴스에 직접 요청을 보낼 수 있으므로 추가 중간 프로세스가 필요하지 않습니다.
이 방법의 핵심은 새 프로세스가 시작될 때까지 기다릴 필요 없이 어느 애플리케이션 인스턴스가 새 시작 요청을 넘겨야 하는지 운영 체제에 미리 알려주고 애플리케이션이 이미 실행 중인지 확인하도록 하는 것입니다.
그러나 개발자는 설치 시 이 기능이 자동으로 사용 가능하다고 단순히 가정할 수 없습니다.
Microsoft는 현재 관련 인터페이스를 제한된 액세스 기능으로 나열하고 있으며 개발자는 Microsoft에 토큰 잠금 해제를 신청해야 합니다. 또한 해당 시작 메뉴 및 링크 시작 시나리오를 지원하려면 실험적 인터페이스 IExperimentalAPIInvoker를 통해 애플리케이션을 등록해야 합니다.
또한 링크 시작 가속은 애플리케이션이 기본 핸들러로 설정된 프로토콜에만 적용됩니다. 예를 들어, 애플리케이션이 해당 연결 유형을 처리하는 경우에만 Windows는 이 메커니즘에 따라 애플리케이션에 직접 요청을 보낼 수 있습니다.
또한 Microsoft는 이 기능이 모든 시작 소스, 모든 애플리케이션 호출 방법 및 모든 Windows 버전을 포괄하지 않기 때문에 애플리케이션이 여전히 자체 단일 인스턴스 처리 논리를 유지해야 한다는 점을 개발자에게 상기시킵니다.
이는 Microsoft가 Edge가 새로운 메커니즘을 사용하도록 허용하더라도 Spotify, Discord 또는 기타 일반적인 소프트웨어가 즉시 동일한 시작 가속화 효과를 얻을 것이라고 가정할 수 없음을 의미합니다. 관련 애플리케이션은 기술 조건을 충족하고 개발자가 적용해야 합니다.
Microsoft가 향후 인터페이스 개방 범위를 확장한다면 더 많은 단일 인스턴스 애플리케이션이 이 메커니즘을 통해 시작 오버헤드를 줄일 수 있는 기회를 갖게 될 것입니다. 그러나 최종 홍보 속도는 여전히 Microsoft의 공개 정책과 소프트웨어 개발자의 실제 채택에 달려 있습니다.
백그라운드 사전 로딩과 달리 새로운 기술에는 추가 상주 프로세스가 필요하지 않습니다.
Windows에서는 애플리케이션 시작 속도를 높이기 위해 다양한 방법을 사용해 왔습니다. 일반적인 접근 방식 중 하나는 응용 프로그램이 일부 구성 요소를 미리 로드하도록 하고 사용자가 창을 열지 않을 때 관련 프로세스를 계속 실행하는 것입니다.
Edge의 Startup Boost는 이러한 유형의 메커니즘에 속합니다. 마이크로소프트는 사용자가 다시 시작할 때 더 빠르게 작업에 들어갈 수 있도록 브라우저를 닫은 후에도 일부 핵심 프로세스를 백그라운드에 계속 유지할 것이라고 설명했다.
Microsoft Office도 비슷한 아이디어를 채택했습니다. Microsoft는 한때 Office에 대한 시작 가속화 작업을 설정하여 Word가 적격 컴퓨터에 미리 로드되고 일시 중단된 상태에서 사용자가 호출할 때까지 기다릴 수 있도록 했습니다. 해당 프로그램은 메모리가 8GB 이상인 컴퓨터를 대상으로 합니다.
파일 탐색기도 사전 로드 메커니즘을 사용했습니다. Windows 최신의 이전 테스트에서는 Windows 11의 파일 탐색기가 사전 로드되어 있어도 여는 속도가 여전히 Windows 10의 관련 환경만큼 빠르지 않으며 사전 로드 프로세스가 약 35MB의 추가 메모리를 차지하는 것으로 나타났습니다.
미리 로드의 장점은 초기화 작업의 일부를 미리 완료할 수 있다는 점이지만, 일정량의 메모리와 시스템 리소스를 계속 점유한다는 비용이 듭니다. 메모리 용량이 제한된 컴퓨터의 경우 여러 응용 프로그램이 유사한 방법을 사용하면 백그라운드 상주 프로세스 수가 계속 증가할 수 있습니다.
이 가속화된 시작 메커니즘은 다른 접근 방식을 채택합니다. 즉, 시스템이 미리 더 많은 구성 요소를 실행할 필요는 없지만 시작 프로세스 중에 불필요한 작업을 수행하지 않으려고 노력합니다.
설계 관점에서 볼 때 이 최적화는 기존 프로세스 자체에 이미 요청을 처리할 수 있는 기능이 있고 운영 체제에서 간단한 전달 작업을 완료하기 위해 추가 프로세스를 만들 필요가 없기 때문에 이미 백그라운드에서 실행 중인 단일 인스턴스 애플리케이션에 특히 적합합니다.
물론 이것이 Microsoft가 모든 애플리케이션에 대한 백그라운드 사전 로드를 취소한다는 의미는 아닙니다. 애플리케이션마다 작동 메커니즘이 다릅니다. 일부 응용 프로그램은 실제로 사전 로드를 통해 이점을 얻을 수 있지만 새로운 메커니즘은 주로 특정 시작 프로세스를 대상으로 하며 해결되는 문제는 정확히 동일하지 않습니다.
Windows 11은 광범위한 성능 최적화를 진행 중입니다
이 업데이트는 Windows 11의 응답성을 개선하기 위한 Microsoft의 최근 지속적인 노력의 일환이기도 합니다.
Microsoft는 작동 지연과 메모리 사용량을 줄이기 위해 최근 몇 년간 시작 메뉴, 검색, 파일 탐색기 및 기타 시스템 인터페이스 작동 방식을 지속적으로 조정해 왔습니다. 일부 개선은 백그라운드 프로세스 수를 줄임으로써 달성되는 반면, 다른 개선은 사용자가 작업을 수행하는 동안 시스템이 필요한 컴퓨팅 작업을 더 빠르게 완료할 수 있도록 프로세서 스케줄링 전략을 조정하여 달성됩니다.
낮은 대기 시간 프로필이라는 메커니즘 중 하나는 애플리케이션 시작 및 시스템 인터페이스의 응답 속도를 향상시키려고 시도합니다. 사용자가 작업을 시작하면 짧은 시간 동안 프로세서의 작동 주파수를 높여 관련 작업을 더 빠르게 완료한 다음 프로세서를 저전력 상태로 되돌립니다.
이번 임시 프로세스 취소 최적화와는 분명히 다릅니다. 전자는 주로 프로세서 응답 모드를 조정하여 작업 실행 시간을 단축하는 반면, 후자는 시작 프로세스의 추가 작업을 직접적으로 줄입니다.
적절한 시나리오에서 두 기술을 함께 사용하면 속도를 높이기 위해 단순히 백그라운드 상주 프로세스 수를 늘릴 필요가 없이 사용자가 더 빠른 애플리케이션 응답을 경험할 수 있습니다.
그러나 구체적인 효과는 여전히 애플리케이션 자체의 시작 로직, 시스템 로드 및 하드웨어 조건에 따라 달라집니다. 시작 속도가 주로 디스크 읽기, 네트워크 연결 또는 대규모 데이터 로드의 영향을 받는 소프트웨어의 경우 임시 프로세스를 종료한다고 해서 반드시 상당한 개선이 이루어지는 것은 아닙니다.
정식적으로 대중화되는 것은 언제인가요?
현재 Microsoft는 모든 Windows 11 사용자가 이 기능을 사용할 수 있다고 발표하지 않았습니다. 윈도우 최신판의 판단에 따르면 마이크로소프트가 정기 업데이트 리듬을 따른다면 이번 최적화는 우선 10월 선택적 업데이트에 진입한 뒤 2026년 11월 10일 패치 화요일 업데이트로 점진적으로 추진될 가능성이 있다.
그러나 이 기능은 단계적으로 푸시되므로 사용자가 해당 업데이트를 설치했더라도 Microsoft의 추가 활성화를 기다려야 할 수도 있습니다. Microsoft는 아직 모든 장치에 대한 정확한 출시 날짜를 발표하지 않았습니다.
일반 사용자의 경우 이 단계에서 시스템 설정을 수정하거나 이 기능을 강제로 활성화할 필요가 없습니다. 기사 제목에 언급된 "강제로 활성화할 수 없습니다"는 주로 일반 사용자가 이 새로운 메커니즘을 수동으로 안정적으로 켤 수 있는 공개 방법이 현재 없다는 사실을 나타냅니다.
사용자가 최신 Release Preview 업데이트를 설치한 경우 백그라운드에서 실행되는 동안 Edge를 다시 여는 반응을 관찰할 수 있습니다. 하지만 마이크로소프트는 통일된 성능 테스트 데이터를 공개하지 않기 때문에 주관적인 느낌만으로는 개선 정도를 정확하게 측정하기는 어렵습니다.
전반적으로 이 변경의 가치는 모든 앱이 즉시 시작된다는 것이 아니라 Microsoft가 Windows 자체 시작 프로세스에서 항상 필요하지 않은 일부 오랜 단계를 제거하기 시작했다는 것입니다. 이미 백그라운드에서 실행 중인 애플리케이션의 경우 임시 프로세스를 만든 다음 요청을 전달하는 것보다 직접 요청을 전달하는 것이 더 합리적입니다.
Microsoft가 향후 더 많은 개발자에게 관련 인터페이스를 공개한다면 단일 인스턴스 애플리케이션은 사소한 변경으로 시작을 가속화할 수 있는 기회를 갖게 될 것입니다. 지속적으로 늘어나는 백그라운드 프리로딩 작업과 비교하면 불필요한 작업을 줄인다는 이런 생각은 시스템 리소스 오버헤드를 줄이는 방향에도 더 부합한다.
다음으로 주목해야 할 점은 Microsoft가 언제 이 기능의 범위를 확장할 것인지이며, Edge 외에도 일반적으로 사용되는 다른 Windows 애플리케이션이 이 메커니즘을 가장 먼저 채택하게 될 것입니다.
댓글