Windows의 프로세서 스케줄 설정 - 백그라운드 서비스와 P/E 코어

「앱을 전면에서 빼면 소리가 지직거린다」 「프로세서 스케줄을 백그라운드 서비스로 하면 안정됐다」

Windows에서는 예전부터 이런 이야기가 나옵니다. 특히 오디오, 영상, 계측, 송출, 상주 처리처럼 UI보다 연속 처리가 더 중요한 장면에서는 신경 쓰입니다.

다만 이 설정은 마법의 가속 스위치가 아닙니다. CPU 클럭을 직접 올리는 설정도, 앱을 Windows 서비스로 바꾸는 설정도, P 코어로 고정하는 설정도 아닙니다. 주로 바뀌는 것은 전면 앱과 뒤에서 도는 처리 사이에서 CPU 시간을 어떻게 나누는가입니다.

flowchart TB
    accTitle: 이 설정이 바꾸는 것
    accDescr: 프로세서 스케줄 설정은 클럭을 올리는 설정도 서비스화나 P 코어 고정 설정도 아니고, 전면 앱과 뒤의 처리 사이에서 CPU 시간을 나누는 방식을 바꾸는 설정임을 나타내는 그림.
    st1["프로세서 스케줄 설정"] -.->|"이들은 바꾸지 않는다"| notx["클럭·서비스화·코어 고정"]
    st1 -->|"바꾸는 것은"| shr1["전면과 뒤에 대한 CPU 시간의 배분"]

그림1: 가속 스위치가 아니라, CPU 시간 배분을 전환하는 설정으로 읽습니다.

이 글에서는 프로그램과 백그라운드 서비스로 무엇이 바뀌는지를 Windows 스케줄러의 기본, quantum(타임 슬라이스), foreground 우대, 그리고 P 코어 / E 코어를 가진 CPU의 동작까지 이어서 정리합니다.

1. 먼저 결론

요점만 먼저 적어 둡니다.

• 이 설정이 직접 바꾸는 것은 CPU의 「성능」보다 CPU 시간의 「배분 방식」입니다.
• 프로그램은 전면 앱을 우대하기 쉽고, 백그라운드 서비스는 전면과 뒤의 처리를 더 균등하게 다루는 방향입니다.
• 그래서 전면 UI보다 뒤에서 도는 연속 처리의 마감이 중요한 워크로드에서는 백그라운드 서비스가 효과가 있을 수 있습니다.
• 다만 P 코어 / E 코어 CPU에서 「어느 코어에 올리는가」는 이제는 이 설정뿐만 아니라 QoS, 전원 정책, hybrid scheduling, Intel Thread Director 쪽이 더 강하게 작용합니다.
• 즉 백그라운드 서비스로 했다고 해서 「배경 처리는 P 코어로」, 「서비스는 E 코어로」 같은 단순한 이야기가 되지는 않습니다.
• 오디오의 지직거림이나 드롭아웃이 DPC / ISR, USB 절전, 드라이버, thermal throttling, EcoQoS에서 비롯된 것이라면 이 설정만으로는 고쳐지지 않습니다.

한 줄로 말하면, 이 설정은 CPU의 주파수 설정이 아니라 대기열 규칙을 바꾸는 설정입니다.

flowchart TB
    accTitle: 효과가 있는 것과 없는 것의 큰 그림
    accDescr: 뒤에서 도는 연속 처리의 마감이 중요한 워크로드에는 백그라운드 서비스 쪽이 효과가 있을 수 있는 한편, P 코어/E 코어 중 어디에 올릴지는 QoS나 전원 정책 쪽이 더 강하게 작용함을 나타내는 그림.
    bgss1["백그라운드 서비스 쪽"] -->|"효과가 있을 수 있다"| dl1["뒤의 연속 처리의 마감"]
    bgss1 -.->|"정하는 것은 다른 메커니즘"| core1["P 코어 / E 코어 선택"]
    core1 --> qos1["QoS·전원 정책·hybrid scheduling"]

그림2: 마감에는 효과가 있을 수 있지만, 코어 선택은 이 설정 밖의 메커니즘이 정합니다.

1.1 먼저 잡아 둘 용어

이 글에서는 6장 근처까지 읽어야 실체가 보이는 용어가 앞쪽에 나옵니다. 먼저 모아 둡니다.

이 글의 지식 맵

프로세서 스케줄링 설정은 내부적으로 Win32PrioritySeparation이라는 레지스트리 값과 연결되어, foreground와 background에 나눠 주는 quantum의 길고 짧음과 우대 정도를 전환할 뿐이며, CPU의 클럭이나 코어 고정을 직접 바꾸는 설정이 아닙니다. 백그라운드 서비스 쪽은 전면 우대를 약화시키기 때문에, 마감에 쫓기는 음성 처리 등의 underrun을 줄이는 경우가 있지만, 이는 MMCSS가 담당하는 우선도 인상과는 별개의 구조입니다. 현대의 Windows, 특히 P 코어 / E 코어의 hybrid CPU에서는 실제로 어느 코어에 배치되는지가 이 설정보다 Windows QoS나 Intel Thread Director를 사용하는 heterogeneous scheduling 정책 쪽이 더 강하게 작용하며, 최소화나 배터리 구동만으로도 QoS가 내려가 efficient core 쪽에 놓이는 경우도 있습니다. 원인을 파악하려면 DPC/ISR 지연을 Windows Performance Recorder와 Analyzer로 관측하는 절차가 효과적입니다.

flowchart LR
    accTitle: 프로세서 스케줄링 설정과 QoS의 지식 맵
    accDescr: 프로세서 스케줄링 설정이 Win32PrioritySeparation과 연결되어 quantum 배분·foreground 우대를 전환하는 오래된 구조라는 것, MMCSS나 Windows QoS가 underrun이나 P 코어 / E 코어 배치에 효과가 있다는 것, Intel Thread Director나 heterogeneous scheduling 정책이 hybrid CPU의 코어 선택을 결정한다는 것, DPC/ISR 지연 확인 수단을 보여주는 그림
    processor_scheduling_setting["프로세서 스케줄링 설정"]
    windows_qos["Windows QoS(서비스 품질) 분류"]
    win32priorityseparation["Win32PrioritySeparation"]
    quantum["quantum(타임 슬라이스)"]
    foreground_boost["포그라운드 우대"]
    audio_underrun["언더런(underrun)"]
    mmcss["MMCSS(Multimedia Class Scheduler Service)"]
    efficient_core_placement["efficient core 위주 배치"]
    ecoqos["EcoQoS"]
    disableuserpresenceqos["DisableUserPresenceQos"]
    hybrid_scheduling_policy["heterogeneous scheduling 정책(SchedulingPolicy 등)"]
    intel_thread_director["Intel Thread Director"]
    p_core_e_core_cpu["P코어/E코어 구성(하이브리드 CPU)"]
    core_parking["Core Parking"]
    dpc_isr_latency["DPC/ISR 지연"]
    wpr_wpa["WPR/WPA(Windows Performance Recorder/Analyzer)"]
    processor_scheduling_setting -->|"에서 구성할 수 있다"| win32priorityseparation
    quantum -->|"에서 구성할 수 있다"| win32priorityseparation
    processor_scheduling_setting -->|"이용한다"| quantum
    processor_scheduling_setting -->|"이용한다"| foreground_boost
    processor_scheduling_setting -.->|"완화한다"| audio_underrun
    mmcss -->|"완화한다"| audio_underrun
    mmcss -->|"이용한다"| windows_qos
    windows_qos -.->|"원인이 될 수 있다"| efficient_core_placement
    ecoqos -->|"원인이 될 수 있다"| efficient_core_placement
    disableuserpresenceqos -.->|"방지한다"| efficient_core_placement
    hybrid_scheduling_policy -->|"이용한다"| windows_qos
    hybrid_scheduling_policy -.->|"이용한다"| intel_thread_director
    hybrid_scheduling_policy -->|"전제로 한다"| p_core_e_core_cpu
    intel_thread_director -->|"전제로 한다"| p_core_e_core_cpu
    hybrid_scheduling_policy -->|"이용한다"| core_parking
    dpc_isr_latency -->|"에서 확인할 수 있다"| wpr_wpa
    p_core_e_core_cpu -->|"에서 확인할 수 있다"| wpr_wpa
    dpc_isr_latency -.->|"원인이 될 수 있다"| audio_underrun

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

2. 애초에 이 설정은 무엇을 바꾸고 있는가

설정 화면의 프로세서 스케줄은 Windows에 예전부터 있는 스케줄링 방침 중 하나입니다. 내부적으로는 Win32PrioritySeparation과 연결된, 꽤 역사가 있는 설정입니다.

여기서 먼저 잡아 두고 싶은 것은 Windows가 CPU를 쓸 때의 기본입니다.

• 스케줄러는 먼저 실행 가능한 스레드 중에서 우선순위가 높은 것을 고릅니다.
• 같은 우선순위라면 일정 시간씩 차례로 실행합니다.
• 이 「일정 시간」이 quantum(타임 슬라이스)입니다.

flowchart LR
    ready["실행 가능한 스레드"] --> pick["스케줄러가 최우선 스레드를 고른다"]
    pick --> run["1 quantum만큼 실행한다"]
    run --> wait{"같은 우선순위의 대기 스레드가 있는가"}
    wait -- yes --> switch["컨텍스트 스위치"]
    switch --> pick
    wait -- no --> run

그림3: 스케줄러는 최우선 스레드를 고르고, 1 quantum씩 차례로 돌립니다.

프로세서 스케줄이 주로 건드리는 것은 이 quantum의 배분 방식과 foreground를 얼마나 우대할 것인가입니다.

여기서 말하는 foreground는 지금 사용자가 만지고 있는 전면 앱입니다. 반대로 뒤로 돌아간 처리, 다른 프로세스의 worker, Windows 서비스, 보조 프로세스, 상주 처리 등은 background 쪽으로 기울기 쉽습니다.

중요한 것은 백그라운드 서비스를 골라도 자기 앱이 Windows 서비스가 되는 것은 아니라는 점입니다. 바뀌는 것은 서비스라는 이름의 종류가 아니라 foreground와 background의 CPU 배분 규칙입니다. 여기, 이름이 꽤 헷갈립니다.

flowchart TB
    accTitle: 「백그라운드 서비스」라는 이름의 혼동
    accDescr: 백그라운드 서비스를 골라도 자기 앱이 Windows 서비스가 되는 것은 아니며, 바뀌는 것은 foreground와 background의 CPU 배분 규칙뿐임을 나타내는 그림.
    sel2["백그라운드 서비스를 고른다"] -.->|"이렇게는 되지 않는다"| svcx["앱이 Windows 서비스가 된다"]
    sel2 -->|"바뀌는 것은"| rule1["전면과 뒤의 CPU 배분 규칙"]

그림4: 이름과 달리, 바뀌는 것은 프로세스 종류가 아니라 배분 규칙입니다.

2.1 설정 화면까지 가는 길

이 설정은 제어판의 꽤 안쪽에 있습니다. 도달 경로는 두 가지입니다.

• Win + R에서 SystemPropertiesPerformance.exe를 실행하면 「성능 옵션」이 바로 열립니다. 그 「고급」 탭에 프로세서 스케줄이 있습니다.
• 손으로 따라가면 「시스템 속성」>「고급」 탭 >「성능」의 「설정」>「고급」 탭 순서입니다. 「시스템 속성」 자체는 sysdm.cpl로 열 수 있습니다.

고른 결과는 레지스트리의 다음 값에 기록됩니다.

현재 값만 확인하려면 PowerShell로 읽을 수 있습니다. 설정을 되돌릴 수 있도록, 바꾸기 전의 값은 적어 두는 편이 안전합니다.

flowchart TB
    accTitle: UI 선택과 레지스트리의 관계
    accDescr: 성능 옵션 UI에서 고른 결과는 Win32PrioritySeparation이라는 레지스트리 값에 기록되고, 현재 값은 PowerShell로 읽을 수 있으므로 바꾸기 전의 값을 적어 둔 뒤 건드린다는 흐름을 나타내는 그림.
    uix2["UI에서 고른다"] --> regw1["Win32PrioritySeparation에 기록된다"]
    regw1 --> pr1["PowerShell로 현재 값을 읽을 수 있다"]
    pr1 -.-> keep2["바꾸기 전의 값을 적어 둔 뒤 바꾼다"]

그림5: UI 선택의 실체는 레지스트리 값이므로, 건드리기 전에 현재 값을 적어 둡니다.

Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\PriorityControl' -Name 'Win32PrioritySeparation'

2.2 대상이 되는 Windows와 값의 의미

「성능 옵션」의 프로세서 스케줄은 Windows 10 / Windows 11 클라이언트에도 Windows Server에도 있습니다. 다만 같은 값이라도 클라이언트와 서버에서 해석이 다르다는 점이 이 설정을 이해하기 어렵게 만듭니다.

Microsoft의 레지스트리 설명에서는 Win32PrioritySeparation을 6비트를 2비트씩 세 묶음(AABBCC)으로 나눈 비트마스크라고 설명합니다.

• 상위 2비트: quantum이 긴 편인지 짧은 편인지
• 중간 2비트: quantum이 가변인지 고정인지
• 하위 2비트: foreground를 background의 몇 배로 우대할지(가변일 때만 적용)

그 위에서 UI 선택이 각각 다음 값을 쓴다고 되어 있습니다(당시 UI 표기는 Applications와 Background services이며, 지금의 프로그램과 백그라운드 서비스에 해당합니다).

숫자로 한 걸음 더 들어가면, Microsoft 해설 기사에서는 0x26일 때 quantum은 foreground가 18, background가 6이고, 0x18일 때는 둘 다 36이라고 설명합니다. quantum은 clock tick의 3분의 1 단위이므로 tick으로 환산하면 전면 6 tick / 뒤 2 tick과 둘 다 12 tick입니다. 같은 기사에서는 x86 멀티프로세서 기기의 clock tick이 15.625밀리초였던 예를 들고 있으며, 이 경우 「전면이 약 94밀리초까지 연속으로 도는 설정」과 「전면도 뒤도 약 188밀리초씩 도는 설정」의 차이가 됩니다.

즉 백그라운드 서비스 쪽은 한 번에 도는 시간은 길지만 전면만 편애하지 않는 배분입니다. 뒤의 처리가 「차례가 돌아오지 않는」 상태가 되기 어려워집니다.

flowchart TB
    accTitle: 두 설정에서 quantum을 나누는 방식
    accDescr: 프로그램 설정에서는 전면이 6tick, 뒤가 2tick으로 전면이 길게 달리고, 백그라운드 서비스 설정에서는 둘 다 12tick씩으로 한 번에 도는 시간은 길지만 전면만 편애하지 않는 배분이 됨을 나타내는 그림.
    pg1["프로그램 설정"] --> fg6["전면 6 tick·뒤 2 tick"]
    bg2["백그라운드 서비스 설정"] --> eq12["전면도 뒤도 12 tick"]
    eq12 --> nofam1["뒤에 차례가 돌아오지 않는 상태가 되기 어렵다"]

그림6: 한쪽은 전면을 길게 돌리고, 다른 쪽은 긴 할당 시간을 균등하게 나눕니다.

또한 이 기본값의 해석에도 OS 차이가 있습니다. Microsoft의 Win32_OperatingSystem 설명에서는 클라이언트 Windows는 가변 길이 quantum으로 전면 앱의 quantum이 길다, Windows Server는 고정 길이 quantum이 기본이라고 되어 있습니다. 레지스트리 설명 쪽도 같은 기본값 0x2가 클라이언트에서는 「짧은 편·가변·전면 3배」, 서버에서는 「긴 편·고정·균등」을 의미한다고 적습니다. 서버가 처음부터 백그라운드 서비스에 가까운 쪽으로 기울어 있는 것은 이 때문입니다.

flowchart TB
    accTitle: 같은 기본값이라도 클라이언트와 서버에서 해석이 다르다
    accDescr: 같은 기본값이라도 클라이언트 Windows에서는 짧은 편·가변·전면 3배 우대, Windows Server에서는 긴 편·고정·균등으로 해석되어 서버가 처음부터 백그라운드 서비스에 가깝게 기울어 있음을 나타내는 그림.
    dv1["같은 기본값"] -->|"클라이언트"| cl2["짧은 편·가변·전면 3배"]
    dv1 -->|"서버"| sv4["긴 편·고정·균등"]
    sv4 -.-> lean1["처음부터 백그라운드 서비스에 가깝다"]

그림7: 값 자체가 아니라 OS 쪽이 기본 해석을 나눕니다.

여기서 든 구체적인 수치는 Windows 2000 / XP 세대의 Microsoft 문서와 해설 기사에 바탕을 둔 것입니다. 레지스트리 값과 UI의 대응은 지금도 같지만, 실제 quantum 취급은 OS 버전에 따라 달라질 수 있으므로 수치는 「어느 자릿수 이야기인가」의 가늠으로 읽으면 됩니다.

3. 프로그램과 백그라운드 서비스로 무엇이 바뀌는가

둘의 차이는 표로 나란히 보면 잘 보입니다.

클라이언트용 Windows는 기본적으로 전면 앱을 쾌적하게 돌리는 방향입니다. 그래서 평범한 데스크톱 조작에서는 프로그램이 자연스럽습니다.

한편 이야기가 달라지는 경우도 있습니다.

• 뒤에서 계속 버퍼를 채우는 오디오 처리
• UI는 가볍지만 다른 스레드 / 다른 프로세스에서 연속 실행하는 캡처나 분석
• 전면에 브라우저나 IDE를 띄워 두어도 뒤 처리의 마감을 지키고 싶은 경우
• 서버 쪽, 서비스 쪽, 상주 쪽에 가까운 워크로드

이런 때에는 전면만 강하게 우대하기보다, 뒤의 처리가 CPU를 되찾기 쉬운 쪽이 안정됩니다. 그 의미에서 백그라운드 서비스는 이치에 맞을 수 있습니다.

flowchart TB
    accTitle: 어느 배분이 맞는지
    accDescr: 대화 중심의 데스크톱 조작이면 전면 우대의 프로그램 설정이 자연스럽고, 뒤의 연속 처리 마감이 중요한 워크로드에서는 뒤가 CPU를 되찾기 쉬운 백그라운드 서비스 설정이 이치에 맞음을 나타내는 그림.
    wl1["워크로드의 성격"] -->|"대화 중심의 조작"| pgn1["프로그램이 자연스럽다"]
    wl1 -->|"뒤의 마감이 중요하다"| bgn1["백그라운드 서비스가 후보"]
    bgn1 --> back2["뒤의 처리가 CPU를 되찾기 쉽다"]

그림8: 전면의 쾌적함과 뒤의 마감 중 무엇을 지킬지에 따라 고르는 쪽이 바뀝니다.

4. 왜 음성이나 연속 처리에서 효과가 있는 경우가 있는가

오디오의 지직거림이나 드롭아웃을 예로 들면 이해가 쉽습니다.

음성 처리는 「평균적으로 빠르다」만으로는 부족합니다. 수 밀리초마다, 혹은 더 짧은 단위로 필요한 타이밍까지 버퍼를 채워야 합니다. 평균 CPU 사용률이 낮아도, 마침 그 순간에 돌지 못하면 음이 끊깁니다.

구체적인 상황을 하나 들어 보겠습니다.

• 전면에는 브라우저나 DAW의 UI나 다른 앱이 있다
• 뒤에서는 음성 처리 스레드가 일정 주기로 돌아 버퍼를 공급한다
• 음성 처리 스레드는 우선순위가 너무 높지 않고, MMCSS나 QoS도 충분히 쓰지 못한다
• CPU가 어느 정도 혼잡하다

이때 프로그램이면 전면 앱 쪽이 더 길게 달리기 쉬워, 뒤의 음성 처리가 「평균으로는 문제없는데 그 순간만 늦는」 일이 있습니다. 이것이 이어지면 underrun이 되고 지직거림으로 이어집니다.

반대로 백그라운드 서비스로 넘기면 뒤의 연속 처리가 CPU를 되찾기 쉬워져, 마감을 놓치기 어려워질 수 있습니다.

즉 효과가 있을 때 일어나는 일은 「CPU가 빨라졌다」가 아니라,

• 전면 앱의 우대가 조금 약해진다
• 뒤의 연속 처리가 끼어들 수 있는 횟수나 타이밍이 나아진다
• 결과적으로 deadline miss가 줄어든다

는 흐름입니다.

flowchart TB
    accTitle: 소리 지직거림이 줄어드는 흐름
    accDescr: 프로그램 설정에서는 전면이 더 길게 달려 뒤의 음성 처리가 그 순간만 늦어 underrun이 될 수 있고, 백그라운드 서비스로 넘기면 전면 우대가 약해져 뒤가 끼어들기 쉬워져 deadline miss가 줄어든다는 흐름을 나타내는 그림.
    fgl1["전면이 더 길게 달린다"] --> late1["음성 처리가 그 순간만 늦어진다"]
    late1 --> ur1["underrun으로 지직거린다"]
    even2["배분을 균등 쪽으로 넘긴다"] --> take1["뒤가 끼어들기 쉬워진다"]
    take1 --> less1["deadline miss가 줄어든다"]

그림9: 효과가 있을 때는 CPU가 빨라진 것이 아니라, 뒤의 처리가 마감에 맞춰지고 있는 것입니다.

5. 원리 - quantum과 foreground 우대

조금 더 낮은 층으로 보면, 효과가 나는 경로는 이렇게 됩니다.

5.1 quantum이 길면 같은 우선순위의 상대는 기다리기 쉽다

같은 우선순위 대역에서 경쟁하는 스레드가 여럿일 때, 한 스레드가 긴 편인 quantum을 받을수록 다른 스레드는 그만큼 기다리기 쉬워집니다.

전면 앱이 우대되는 설정에서는 foreground 쪽이 더 길게 연속 실행하기 쉬워집니다. 그러면 비슷한 우선순위의 background 쪽은 그만큼 「지금은 아니다」를 당하기 쉬워집니다.

음성, 영상, 주기 계측, 폴링, 감시처럼 조금씩이라도 정기적으로 돌고 싶은 처리에서는 이 차이가 작용합니다.

flowchart TB
    accTitle: 긴 quantum이 동급 상대를 기다리게 한다
    accDescr: 같은 우선순위 대역에서 경쟁하는 스레드가 여럿일 때 한쪽이 긴 편인 quantum을 받을수록 다른 스레드는 기다리기 쉬워지고, 조금씩이라도 정기적으로 돌고 싶은 처리에서는 이 차이가 작용함을 나타내는 그림.
    comp1["같은 우선순위 대역에서 경쟁한다"] --> long1["한쪽이 긴 quantum을 받는다"]
    long1 --> wt2["다른 스레드는 기다리기 쉽다"]
    wt2 -.-> perio1["정기적으로 돌고 싶은 처리일수록 차이가 난다"]

그림10: quantum의 길이는 동급으로 경쟁하는 상대의 대기 시간으로 그대로 되돌아옵니다.

5.2 Windows는 foreground에 여러 형태로 신경을 쓴다

Windows는 원래 foreground에 꽤 신경을 씁니다. 대표적인 것은 이 정도입니다.

• 전면으로 온 프로세스의 우대
• 입력을 받은 창을 가진 스레드의 우대
• I/O 완료 후 스레드에 대한 동적 우선순위 부스트

즉 앱을 전면에서 빼는 것만으로 스케줄링상의 취급은 평범하게 바뀝니다. 백그라운드 서비스는 이 foreground 우대 가운데 특히 CPU 시간 배분의 치우침을 작게 하는 방향이라고 보면 이해하기 쉽습니다.

flowchart TB
    accTitle: Windows가 foreground에 신경을 쓰는 형태
    accDescr: Windows는 전면으로 온 프로세스의 우대, 입력을 받은 창의 스레드 우대, I/O 완료 후 동적 우선순위 부스트 등 여러 형태로 foreground에 신경을 쓰므로 전면에서 빼는 것만으로 취급이 바뀜을 나타내는 그림.
    fgc1["전면 프로세스의 우대"] --> chg2["전면에서 빼는 것만으로 취급이 바뀐다"]
    fgc2["입력 창의 스레드 우대"] --> chg2
    fgc3["I/O 완료 후 동적 부스트"] --> chg2
    chg2 -.-> shrink1["이 설정은 배분의 치우침을 작게 하는 쪽"]

그림11: 전면 우대는 여러 메커니즘의 겹침이며, 이 설정은 그중 배분의 치우침에 작용합니다.

5.3 「CPU를 놀리지 않는다」는 반은 맞고 반은 어긋난다

「CPU를 놀리지 않는다」는 말은 감각으로는 이해가 됩니다. 뒤의 처리가 뒤로 밀리기 어렵다는 뜻에서는 분명 그렇습니다.

다만 기술적으로는 조금 더 정확하게 말하는 편이 좋고, 실제로 바뀌는 것은 CPU의 유휴 제어나 주파수 자체보다 스레드를 어떤 순서로, 얼마나 길게 돌릴지입니다.

그래서 이 설정은

• turbo boost를 올리는 설정이 아니다
• C-state를 끄는 설정이 아니다
• core parking을 직접 바꾸는 설정이 아니다
• P 코어 고정 설정이 아니다

가 됩니다.

flowchart TB
    accTitle: 「놀리지 않는다」의 정확한 의미
    accDescr: 이 설정에서 실제로 바뀌는 것은 CPU의 유휴 제어나 주파수가 아니라 스레드를 어떤 순서로 얼마나 길게 돌릴지이며, turbo나 C-state, core parking, P 코어 고정 설정이 아님을 나타내는 그림.
    sabo1["CPU를 놀리지 않는다는 감각"] -->|"실제로 바뀌는 것은"| ord2["돌리는 순서와 길이"]
    sabo1 -.->|"바뀌지 않는 것은"| pw2["turbo·C-state·core parking·코어 고정"]

그림12: 「놀리지 않는다」의 실체는 전원 제어가 아니라 순서와 할당 시간의 변경에 있습니다.

6. P 코어 / E 코어 CPU에서는 어떻게 작용하는가

여기가 가장 오해되기 쉬운 지점입니다.

백그라운드 서비스로 했다고 해서 Windows가 「배경 처리이니 E 코어」, 「전면이니 P 코어」라고 단순하게 정하는 것은 아닙니다. 현대 Windows, 특히 Windows 11의 hybrid CPU에서는 P 코어 / E 코어 선택이 더 여러 단계입니다.

6.1 이름은 비슷하지만 별개

먼저 비슷한 이름의 별개가 둘 있습니다.

1. 프로세서 스케줄의 백그라운드 서비스
   • 오래된 UI에 있는 설정
   • 주로 foreground / background의 CPU 시간 배분에 작용한다
   • quantum과 foreground boost 계통의 이야기
2. QoS의 Utility / Eco / Low 등
   • 현대 Windows의 power / performance 분류
   • core 선택이나 주파수 제어에도 작용한다
   • P 코어 / E 코어 동작에 직접 관련되기 쉽다

이 둘은 같지 않습니다.

flowchart TB
    accTitle: 비슷한 이름의 별개
    accDescr: 프로세서 스케줄 설정은 오래된 UI 설정으로 quantum과 foreground 우대 계통에 작용하고, QoS는 현대의 power/performance 분류로 코어 선택이나 주파수 제어에 작용하는 별개임을 나타내는 그림.
    old2["프로세서 스케줄 설정"] --> qt1["quantum과 foreground 우대 계통"]
    newq1["QoS 분류"] --> cs2["코어 선택·주파수 제어 계통"]
    old2 -.->|"같지 않다"| newq1

그림13: 이름의 분위기는 비슷해도, 작용하는 레이어가 전혀 다릅니다.

6.2 Windows 11의 QoS와 visibility

현대 Windows에서는 priority만이 아니라 QoS도 작용합니다. 특히 heterogeneous processor, 즉 P 코어 / E 코어 같은 구성에서는 QoS가 어떤 종류의 코어를 선호할지에 영향을 줍니다.

Windows 11의 대략적인 분류는 이렇습니다.

이 표는 Microsoft Learn의 「Quality of Service」에 있는 두 표, 즉 QoS 레벨 목록(High / Medium / Low / Utility / Eco / Media / Deadline)과 QoS 분류(창 표시 상태에서 QoS를 정하는 대응)를 다시 묶은 것입니다. 관측에서 끌어낸 분류가 아닙니다. 같은 문서에는 소리를 내고 있다고 판정된 프로세스는 High로 다룬다는 규정과, 위에 해당하지 않는 스레드는 우선순위 등의 휴리스틱으로 자동 할당한다는 설명도 있습니다.

하나 더, 측정하는 사람에게 중요한 기술이 있습니다. 배터리 구동 중에 일정 시간 사용자 입력이 없으면 전면 앱의 QoS가 Medium으로 내려갈 수 있다는 기능입니다. 문서에는 배터리로 성능을 측정할 때는 이 기능을 꺼야 한다는 주의가 있고, 끄는 방법으로 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\PowerThrottling의 DisableUserPresenceQos(REG_DWORD)에 1을 설정하는 절차가 안내되어 있습니다. 입력이 없는 자동 테스트에서 「배터리일 때만 느리다」가 나오면 먼저 여기를 의심하는 편이 빠릅니다.

여기서 중요한 것은 최소화한 것만으로 QoS가 바뀔 수 있다는 점입니다. 즉 hybrid CPU 노트북에서는

• 앱을 전면에서 뺐다
• 게다가 최소화했다
• 그 결과 QoS가 내려갔다
• efficient core 쪽에 놓이기 쉬워졌다
• 체감이나 마감이 나빠졌다

는 일이 흔히 일어납니다.

flowchart TB
    accTitle: 최소화에서 마감 악화까지의 연쇄
    accDescr: hybrid CPU 노트북에서는 앱을 전면에서 빼고 최소화하면 QoS가 내려가고, 배터리 시에는 efficient core 쪽에 놓이기 쉬워져 체감이나 마감이 나빠지는 연쇄가 흔히 일어남을 나타내는 그림.
    mn2["전면에서 빼고 최소화"] --> qd1["QoS가 내려간다"]
    qd1 -->|"배터리 시에는 특히"| ec1["efficient core 쪽에 놓인다"]
    ec1 --> ws1["체감이나 마감이 나빠진다"]

그림14: 최소화라는 조작만으로 코어 배치까지 닿는 연쇄가 일어날 수 있습니다.

6.3 Thread Director와 hybrid scheduling

Intel 12th Gen 이후 hybrid CPU에서는 Intel Thread Director가 OS에 힌트를 줍니다. Windows 11은 이를 써서 P 코어 / E 코어 할당을 더 똑똑하게 정합니다.

여기에 더해 Windows 쪽에는 heterogeneous scheduling 정책이 있습니다.

• SchedulingPolicy
• ShortSchedulingPolicy
• ShortThreadRuntimeThreshold

이들은 Automatic으로 두면 QoS와 시스템 구성을 보고 OS가 정하는 메커니즘입니다. 그 뒤에서는 processor power management 쪽의 core parking engine이나 performance state engine도 움직입니다.

전체 그림은 대략 이렇게 보면 이해하기 쉽습니다.

flowchart TD
    t["Thread"] --> p["Priority / dynamic priority"]
    t --> q["QoS (High / Medium / Low / Utility / Eco / Deadline)"]
    t --> v["Visibility / audible / input state"]
    t --> h["Hybrid scheduling policy<br/>SCHEDPOLICY / SHORTSCHEDPOLICY"]
    t --> td["Intel Thread Director hints<br/>Windows 11 on Intel hybrid"]
    v --> q
    p --> s["Windows scheduler + Processor Power Management"]
    q --> s
    h --> s
    td --> s
    s --> c["P 코어 / E 코어와 주파수가 정해진다"]

그림15: 우선순위·QoS·가시 상태·scheduling 정책·Thread Director 힌트가 모여 코어와 주파수가 정해집니다.

7. 어떤 때에 효과가 있고, 어떤 때에는 효과가 없는가

실무에서는 효과가 나기 쉬운 경우와 별개 문제인 경우를 나눠 보는 편이 빠릅니다.

7.1 효과가 나기 쉬운 경우

이런 때에는 백그라운드 서비스가 괜찮은 대책이 될 수 있습니다.

• 전면 앱으로 포커스를 옮기면 뒤의 연속 처리만 불안정해진다
• CPU 사용률은 포화하지 않았는데 주기 처리의 마감만 떨어진다
• 중요한 처리가 legacy app / helper process / worker thread 쪽에 있고, MMCSS나 QoS 사용이 충분하지 않다
• 서비스나 상주 처리가 주역이고, 전면 UI의 쾌적함보다 뒤 처리의 안정이 중요하다

7.2 효과가 나기 어렵거나 별개 문제인 경우

반대로 이 설정만으로는 부족한 문제도 있습니다.

• DPC / ISR 지연이 크다
• USB controller나 audio driver의 불량
• USB selective suspend나 장치 절전의 영향
• thermal throttling
• battery saver나 power throttling, EcoQoS의 영향
• 버퍼 크기가 너무 작다
• 앱이 이미 MMCSS / Deadline을 바르게 쓰고 있고, 문제는 다른 곳에 있다

특히 Windows 11 + hybrid CPU 노트북에서는 visibility와 QoS의 변화가 꽤 크게 작용합니다. 최소화에서 느려지거나 배터리에서만 나빠지는 경우라면 프로세서 스케줄보다 QoS / power 쪽을 의심하는 편이 맞을 가능성이 높습니다.

flowchart TB
    accTitle: 증상에서 무엇을 의심할지
    accDescr: 포커스를 옮기면 뒤의 연속 처리만 불안정해지면 이 설정이 후보가 되고, 최소화나 배터리에서만 나빠지면 QoS나 power 쪽, DPC/ISR 지연이나 드라이버에서 비롯되면 별개 문제로 판다는 가려내기를 나타내는 그림.
    smp2["증상이 나오는 방식을 본다"] -->|"전면으로 옮기면 뒤가 불안정"| this1["이 설정이 후보가 된다"]
    smp2 -->|"최소화·배터리에서만 악화"| qsp1["QoS / power 쪽을 의심한다"]
    smp2 -->|"DPC / ISR·드라이버에서 비롯"| oth2["이 설정으로는 고쳐지지 않는 별개 문제"]

그림16: 증상이 조건에 따라 달라지는 모습이 이 설정·QoS·별개 문제 중 어디인지를 알려 줍니다.

8. 실무에서의 보는 법

실제로 가려낸다면 순서는 다음이 이해하기 쉽습니다.

1. 조건을 고정한다
   • AC 전원인지, 배터리인지
   • 전원 모드
   • 버퍼 크기
   • foreground / visible / minimized 상태
2. 프로그램과 백그라운드 서비스를 같은 조건에서 비교한다
   • 체감만이 아니라 dropout 횟수, glitch 횟수, 처리 지연을 기록한다
3. Windows 11 / hybrid CPU라면 QoS 쪽을 의심한다
   • 최소화에서만 나빠지는가
   • audible 상태에서 바뀌는가
   • 배터리에서만 나빠지는가
4. 음성이나 영상이라면 MMCSS를 먼저 본다
   • 중요 스레드가 Windows에 「이것은 마감이 중요하다」고 전달되고 있는가
5. 그래도 고쳐지지 않으면 DPC / ISR / USB / driver를 판다
   • 여기는 스케줄러 이전의 이야기가 된다

flowchart TB
    accTitle: 가려내는 순서
    accDescr: 먼저 조건을 고정하고, 프로그램과 백그라운드 서비스를 같은 조건에서 비교하고, hybrid CPU라면 QoS 쪽을 의심하고, 음성이나 영상이라면 MMCSS를 확인하고, 그래도 고쳐지지 않으면 DPC/ISR이나 드라이버를 판다는 가려내기 순서를 나타내는 그림.
    o1["조건을 고정한다"] --> o2["두 설정을 같은 조건에서 비교"]
    o2 --> o3["hybrid CPU라면 QoS 쪽을 의심"]
    o3 --> o4["음성·영상이라면 MMCSS를 확인"]
    o4 --> o5["남으면 DPC / ISR·드라이버를 판다"]

그림17: 가려내기는 조건 고정부터 시작하고, 스케줄러 이전의 층은 마지막에 팝니다.

8.1 각각 무엇을 어떻게 확인하는가

「의심한다」에서 멈추지 않도록, 확인하는 수단을 적어 둡니다.

wpr은 Windows Performance Recorder 명령이며 Windows ADK에 들어 있습니다. 관리자 권한 콘솔에서 실행합니다.

실무에서는 평균 CPU 사용률보다 「마감에 맞았는가」가 더 중요합니다. 여기가 꽤 본질입니다.

flowchart TB
    accTitle: 봐야 할 지표는 마감
    accDescr: 이런 종류의 문제에서는 평균 CPU 사용률보다 주기 처리가 마감에 맞았는지가 더 중요한 지표임을 나타내는 그림.
    avg2["평균 CPU 사용률"] -.->|"이것만으로는 부족하다"| judge1["안정되어 있는지의 판단"]
    ddl1["마감에 맞았는가"] -->|"이쪽을 본다"| judge1
    ddl1 -.-> cnt1["dropout이나 glitch 횟수로 센다"]

그림18: 평균이 낮아도 마감은 떨어질 수 있으므로, 맞았는지를 세어 판단합니다.

9. 정리

프로세서 스케줄을 백그라운드 서비스로 바꾸면 무엇이 일어나는지를 꽤 짧게 다시 말하면 이렇습니다.

• 바뀌는 것은 CPU 속도 자체가 아니라, foreground와 background 사이의 CPU 시간 배분
• 프로그램은 전면 앱을 쾌적하게 만들기 쉽다
• 백그라운드 서비스는 뒤의 연속 처리가 밀리지 않기 쉬워진다
• 그래서 음성, 영상, 캡처, 감시, 상주 처리처럼 뒤의 마감이 중요한 경우에는 효과가 있을 수 있다
• 다만 P 코어 / E 코어 CPU에서는 실제 core 배치에 QoS, power policy, hybrid scheduling, Thread Director도 강하게 작용한다
• 그래서 요즘 Windows에서는 이 설정은 효과가 있을 수는 있지만 단독 주역은 아니다고 보는 것이 자연스럽다

결국 이것은 CPU 성능을 올리는 손잡이가 아니라, 일의 배분을 바꾸는 손잡이입니다.

전면 앱의 경쾌함을 우선할지, 뒤의 연속 처리 마감을 지키기 쉽게 할지. 그 균형을 조금 background 쪽으로 기울이는 설정이라고 보면 꽤 납득이 됩니다.

그리고 hybrid CPU 시대에는 그 위에 QoS와 P / E 코어 선택 층이 더 올라와 있습니다. 여기까지 포함해 보면 「왜 효과가 있는 경우가 있는지」「왜 효과가 없는 경우도 있는지」가 보입니다.

flowchart TB
    accTitle: 이 손잡이의 현대에서의 위치
    accDescr: 이 설정은 일의 배분을 background 쪽으로 조금 기울이는 손잡이이며, hybrid CPU 시대에는 그 위에 QoS와 P 코어/E 코어 선택 층이 올라가 있으므로 효과는 있을 수 있지만 단독 주역은 아님을 나타내는 그림.
    knob1["배분을 background 쪽으로 기울이는 손잡이"] --> base2["quantum과 우대의 층"]
    base2 -.->|"그 위에 올라온다"| upper1["QoS와 P / E 코어 선택의 층"]
    upper1 --> view1["효과가 있는 이유도 없는 이유도 보이게 된다"]

그림19: 이 손잡이는 아래 층에만 작용하고, 현대의 코어 선택은 그 위 층이 정합니다.

10. 참고 자료

• Sawady: 백그라운드 서비스를 우선하는 설정(CPU를 놀리지 않기)
• Microsoft Learn: Win32_OperatingSystem class
• Microsoft Learn: Win32PrioritySeparation 레지스트리 값 설명 - 비트의 의미와 UI 선택이 기록하는 값.
• Microsoft Learn: Master Your Quantum - Win32PrioritySeparation 값마다의 quantum.
• Microsoft Learn: Know Thy Tick - clock tick과 quantum의 관계.
• Microsoft Learn: CPU Analysis in Windows Performance Analyzer
• Microsoft Learn: Windows Performance Recorder
• Microsoft Learn: Priority Boosts
• Microsoft Learn: Window Features
• Microsoft Learn: Quality of Service
• Microsoft Learn: SetThreadInformation function
• Microsoft Learn: SetProcessInformation function
• Microsoft Learn: Multimedia Class Scheduler Service
• Microsoft Learn: Processor power management options overview
• Microsoft Learn: SchedulingPolicy
• Microsoft Learn: ShortSchedulingPolicy
• Microsoft Learn: ShortThreadRuntimeThreshold
• Intel Support: Is Windows 10 Task Scheduler Optimized for 12th Generation Intel Core Processors?
• Intel White Paper: Intel performance hybrid architecture & software optimizations, Part Two

관련 기사

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

관련 토픽

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

이 주제와 연결되는 서비스

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

자주 묻는 질문

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

「프로세서 스케줄」을 「백그라운드 서비스」로 바꾸면 무엇이 달라지나요?

달라지는 것은 CPU의 속도나 클럭이 아니라, 전면 앱과 뒤에서 도는 처리 사이에서 CPU 시간을 나누는 방식입니다. 내부적으로는 Win32PrioritySeparation과 연결된 설정으로, quantum(타임 슬라이스) 배분과 foreground 우대 정도에 영향을 줍니다. 「프로그램」은 전면 앱을 우대하기 쉽고, 「백그라운드 서비스」는 전면과 뒤를 더 균등하게 다루는 방향입니다. 이 설정을 골라도 자기 앱이 Windows 서비스가 되는 것은 아닙니다.

「백그라운드 서비스」로 바꾸면 소리가 지직거리는 현상이 고쳐지는 경우가 있는 이유는 무엇인가요?

음성 처리는 평균적으로 빠르기만 해서는 부족하고, 수 밀리초마다의 마감까지 버퍼를 채워야 하기 때문입니다. 「프로그램」 설정에서는 전면 앱 쪽이 더 길게 달리기 쉬워, 뒤의 음성 처리가 평균으로는 문제없어도 그 순간만 늦어 underrun이 될 수 있습니다. 「백그라운드 서비스」로 넘기면 뒤의 연속 처리가 CPU를 되찾기 쉬워져 deadline miss가 줄어들 수 있습니다. 다만 DPC/ISR 지연, USB 절전, 드라이버 불량, thermal throttling, EcoQoS에서 비롯된 문제는 이 설정으로는 고쳐지지 않습니다.

「백그라운드 서비스」로 하면 배경 처리가 P 코어에서 돌아가게 되나요?

되지 않습니다. P 코어와 E 코어 중 어디에 올릴지는 이 설정보다 QoS, 전원 정책, hybrid scheduling, Intel Thread Director 쪽이 더 강하게 작용합니다. Windows 11에서는 앱을 최소화한 것만으로 QoS가 내려가고, 배터리 구동 시에는 efficient core 쪽에 놓이기 쉬워지는 일도 흔합니다. 최소화에서만 느려지거나 배터리에서만 나빠지는 경우에는 이 설정보다 QoS나 power 쪽을 의심하는 편이 맞을 가능성이 높습니다.

음 끊김이나 드롭아웃의 원인은 어떻게 가려내면 되나요?

먼저 AC 전원인지, 전원 모드, 버퍼 크기, 전면·최소화 상태 같은 조건을 고정한 뒤 「프로그램」과 「백그라운드 서비스」를 같은 조건에서 비교해 dropout 횟수나 처리 지연을 기록합니다. Windows 11의 hybrid CPU라면 최소화나 배터리에서만 나빠지는지를 보고 QoS 쪽을 의심합니다. 음성이나 영상이라면 중요 스레드가 MMCSS를 쓰고 있는지를 먼저 확인하고, 그래도 고쳐지지 않으면 DPC/ISR·USB·드라이버를 파고듭니다. 여기까지 오면 스케줄러 이전의 이야기가 됩니다.

저자 프로필

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

Go Komura

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

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