Windows에서 프로그램 버전별 속도를 올바르게 비교하는 방법

Windows에서 프로그램 버전 A와 B를 비교하고 싶습니다. 그때 가장 해서는 안 되는 일은, 같은 머신에서 한 번씩만 실행하고 “B가 8% 더 빠른 것 같다”고 말해 버리는 것입니다.

그 8%는 정말로 코드 차이일 수도 있습니다. 하지만 실제로는 Power mode(전원 모드), Power plan(전원 플랜), 열, 백그라운드 업데이트, 검색 인덱스, 바이러스 스캔, affinity, 실행 순서, 캐시 상태 중 하나였던 경우가 Windows 벤치마크에서 흔합니다. 조건을 하나씩 제거해 나가는 눈에 띄지 않는 작업이 됩니다.

flowchart TB
    accTitle: “8% 더 빠른 것 같다”의 정체
    accDescr: 한 번씩 실행해 나온 차이는 코드 차이일 수도 있지만, 전원이나 열, 백그라운드나 캐시 중 하나였던 일이 흔하며, 조건을 하나씩 제거해 나가는 작업이 필요하다는 점을 나타내는 그림.
    one1["한 번씩 실행해 비교한다"] --> dif2["8% 더 빠른 것 같다, 가 나온다"]
    dif2 -->|"일 수도 있다"| code1["정말로 코드 차이"]
    dif2 -->|"흔한 정체"| env1["전원·열·노이즈·캐시"]
    env1 --> crush1["조건을 하나씩 제거해 나간다"]

그림1: 한 번만 나온 차이는 코드 차이라고 단정할 수 없으며, 조건을 제거한 뒤에야 말할 수 있다.

이 글에서는 Windows에서 서로 다른 버전의 프로그램 실행 속도를 가능한 한 코드 차이에 가깝게 비교하는 방법을 정리합니다. 대상은 주로 Windows 11이지만, powercfg나 start 등 대부분은 Windows 10에서도 동일하게 사용할 수 있습니다.

먼저 알아 둘 용어

본문에는 영어 그대로 나오는 용어가 있습니다. 처음 볼 때 막히지 않도록 먼저 정리합니다.

먼저 결론

재현성을 높이는 요령은, 핵심만 추리면 다음 여섯 가지입니다.

1. “무엇을 비교하고 싶은지”를 먼저 정한다 코드 차이를 보고 싶은지, 실제 사용자 경험을 보고 싶은지에 따라 맞춰야 할 환경이 달라집니다.

2. Power mode(전원 모드)와 Power plan(전원 플랜)을 별개로 기록한다 Windows에서 여기를 대충 다루면, 비교가 OS의 절전 정책 비교가 되기 쉽습니다.

3. 식은 첫 회와, 데워진 뒤의 정상 상태를 나눈다 첫 회만 빠르거나 후반만 느린 일은 드물지 않습니다.

4. A→B→A→B처럼 번갈아 돌린다 A를 먼저 전부 돌린 다음 B를 돌리면, 열이나 백그라운드 상태의 치우침을 그대로 받습니다.

5. 평균뿐 아니라 중앙값과 흩어짐을 본다 이상치가 하나 있기만 해도 전체 그림이 크게 왜곡됩니다. 평균은 생각보다 취약합니다.

6. 차이가 작으면 ETW / WPR로 원인까지 파고든다 체감만으로 논의하면, 어느 쪽 주장도 근거 없이 평행선을 긋게 됩니다.

이 글의 지식 맵

이 글은 Windows에서 프로그램 버전 간의 속도를 비교할 때의 재현성을 주제로, Power mode(오버레이)와 Power plan이라는 2개 층의 전원 설정을 고정·기록하는 것이 전제가 된다는 것을 보여줍니다. Power mode의 차이는 코어 주차 등 PPM의 동작을 좌우하며, Modern Standby 대응 디바이스에서는 Power plan의 선택지 자체가 Balanced 계열로 제한됩니다. 검색 인덱스나 Defender의 스캔, 알림 같은 백그라운드 처리는 측정값의 편차 원인이 될 수 있으므로, 제외 설정이나 clean boot, 알림 억제로 줄입니다. Wall-clock time·CPU time·Cycle count를 QueryPerformanceCounter·GetProcessTimes·QueryProcessCycleTime으로 각각 측정하고, 차이가 작고 이유를 읽을 수 없을 때는 WPR로 ETW 트레이스를 얻어 WPA로 비교하는 것이 권장됩니다.

flowchart LR
    accTitle: Windows 벤치마크 비교 재현성의 지식 맵
    accDescr: Power mode와 Power plan이라는 2개 층의 전원 설정을 고정·기록하는 것이 벤치마크 재현성의 전제가 된다는 것, 검색 인덱스나 Defender 스캔 같은 백그라운드 처리가 측정값의 편차를 낳으며 제외 설정이나 clean boot로 줄일 수 있다는 것, Wall-clock time·CPU time·Cycle count를 각각 전용 API로 측정하는 것, 차이가 작을 때 WPR과 WPA로 원인을 파고드는 흐름을 보여주는 그림
    benchmark_reproducibility["벤치마크 재현성"]
    power_mode["전원 모드/전원 관리 옵션(PPM)"]
    power_plan["Power plan(전원 관리 옵션)"]
    powercfg["powercfg"]
    modern_standby["Modern Standby 지원 디바이스"]
    core_parking["Core Parking"]
    search_indexing["검색 인덱스 생성"]
    benchmark_result_variance["벤치마크 결과 편차(변동)"]
    exclusion_setting["제외 설정(폴더 제외)"]
    clean_boot["클린 부트(clean boot)"]
    do_not_disturb["방해 금지 모드(알림 억제)"]
    wpr["Windows Performance Recorder(WPR)"]
    etw["ETW(Event Tracing for Windows)"]
    wpa["Windows Performance Analyzer(WPA)"]
    inconclusive_benchmark_result["차이가 작거나 원인을 알 수 없는 벤치마크 결과"]
    wall_clock_time["Wall-clock time(경과 시간)"]
    queryperformancecounter["QueryPerformanceCounter(QPC)"]
    cpu_time["CPU 시간(사용자 + 커널 시간)"]
    getprocesstimes["GetProcessTimes"]
    cycle_count["CPU 사이클 수"]
    queryprocesscycletime["QueryProcessCycleTime"]
    process_priority["우선순위 클래스(priority class)"]
    start_command["start 명령"]
    processor_affinity["프로세서 선호도(affinity mask)"]
    processor_groups["프로세서 그룹(Processor Groups)"]
    benchmark_reproducibility -->|"전제로 한다"| power_mode
    benchmark_reproducibility -->|"전제로 한다"| power_plan
    power_plan -->|"에서 구성할 수 있다"| powercfg
    modern_standby -.->|"양립하지 않는다"| power_plan
    core_parking -.->|"에서 구성할 수 있다"| power_mode
    search_indexing -.->|"원인이 될 수 있다"| benchmark_result_variance
    exclusion_setting -.->|"완화한다"| benchmark_result_variance
    clean_boot -->|"완화한다"| benchmark_result_variance
    do_not_disturb -.->|"완화한다"| benchmark_result_variance
    wpr -->|"이용한다"| etw
    wpa -->|"이용한다"| etw
    wpa -.->|"전제로 한다"| wpr
    wpr -->|"권장되는 대응"| inconclusive_benchmark_result
    wall_clock_time -->|"에서 확인할 수 있다"| queryperformancecounter
    cpu_time -->|"에서 확인할 수 있다"| getprocesstimes
    cycle_count -->|"에서 확인할 수 있다"| queryprocesscycletime
    process_priority -->|"에서 구성할 수 있다"| start_command
    processor_affinity -->|"에서 구성할 수 있다"| start_command
    processor_affinity -.->|"전제로 한다"| processor_groups
    benchmark_reproducibility -.->|"이용한다"| wall_clock_time
    benchmark_reproducibility -.->|"이용한다"| cpu_time
    benchmark_reproducibility -.->|"이용한다"| cycle_count
    benchmark_result_variance -->|"양립하지 않는다"| benchmark_reproducibility
    benchmark_reproducibility -.->|"원인이 될 수 있다"| inconclusive_benchmark_result
    benchmark_reproducibility -.->|"이용한다"| start_command

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

무엇을 비교하고 싶은지를 먼저 정한다

“속도 비교”라고 한 마디로 말해도, 실제로는 두 종류가 있습니다.

1. 코드 차이를 보고 싶은 비교

알고리즘 변경, 데이터 구조 변경, 컴파일러 최적화, 런타임 업데이트 등에 의해 구현 자체가 빨라졌는지를 알고 싶은 비교입니다.

이 경우에는 환경 노이즈를 가능한 한 깎습니다. 벤치 전용 세션, Power mode(전원 모드) 고정, 알림 중지, 검색 인덱스나 동기화 억제, 필요하면 clean boot까지 합니다.

2. 실제 사용자 경험을 보고 싶은 비교

배포 후에 사용자가 평소 Windows에서 느끼는 속도를 알고 싶은 비교입니다.

이 경우에는 현실에 있는 노이즈를 전부 지워서는 안 됩니다. OneDrive 동기화, Defender, 알림, 평소 전원 설정 등을 포함한 “그럴듯한 일상 환경”에서 비교하는 편이 현실에 가까운 결과가 됩니다.

이 둘을 섞으면 결론이 뒤틀립니다. “랩에서는 12% 빠른데 현실에서는 오차” “현실에서는 빠른데 CPU 시간은 같다” 같은 일이 흔히 일어납니다.

flowchart TB
    accTitle: 두 종류의 비교를 섞지 않는다
    accDescr: 코드 차이를 보고 싶은 비교에서는 환경 노이즈를 가능한 한 깎고, 실제 사용자 경험을 보고 싶은 비교에서는 현실 노이즈를 남긴 일상 환경에서 재야 하며, 둘을 섞으면 결론이 뒤틀린다는 점을 나타내는 그림.
    q5["무엇을 비교하고 싶은가"] -->|"코드 차이"| lab1["노이즈를 깎은 랩 환경"]
    q5 -->|"실제 사용자 경험"| real1["노이즈를 남긴 일상 환경"]
    q5 -.->|"섞으면"| twist2["결론이 뒤틀린다"]

그림2: 목적에 따라 맞춰야 할 환경이 반대가 되므로, 먼저 어느 쪽 비교인지 정한다.

Windows에서 결과가 흔들리는 주된 원인

먼저, 무엇이 결과를 흔드는지 거칠게 목록으로 잡아 둡니다.

요컨대 “같은 Windows 머신”이라도 조건이 맞지 않으면 다른 실험입니다.

flowchart TB
    accTitle: 조건이 맞지 않으면 다른 실험
    accDescr: 같은 Windows 머신에서 재더라도, 하드웨어부터 전원, 열, 백그라운드, 빌드 조건까지 여러 층의 조건이 맞지 않으면 실질적으로 다른 실험이며, 조건을 고정해야 비로소 비교가 된다는 점을 나타내는 그림.
    same1["같은 Windows 머신에서 잰다"] -.->|"조건이 맞지 않다"| oth1["실질적으로 다른 실험"]
    same1 -->|"여러 층의 조건을 고정·기록"| cmp1["비로소 비교가 된다"]

그림3: 머신이 같아도, 층을 가로지르는 조건이 맞지 않으면 비교로 성립하지 않는다.

Power mode(전원 모드)와 Power plan(전원 플랜)은 나눠서 생각한다

여기는 꽤 중요합니다.

Windows에는 설정 앱의 Power mode(전원 모드) 와, 기존의 Power plan(전원 플랜) (powercfg로 보이는 전원 플랜)이 있습니다. 겉모습이 비슷해서 한데 묶이기 쉽지만, 대충 다루면 비교 조건이 모호해지고 결과의 재현성이 사라집니다.

Windows 설정 앱에서는 Settings > System > Power & battery에서 Power mode를 고를 수 있습니다. Microsoft 문서에서는 Plugged in / On Battery마다 Best power efficiency, Balanced, Best performance를 바꿀 수 있다고 합니다. 나아가 Power mode가 바뀌면 이면의 전원 관련 설정과 PPM(Processor Power Management) 동작에도 영향을 줍니다. 즉, 여기만 달라도 코어 파킹이나 성능 스케일링 방침이 달라질 수 있습니다.

한편 Power plan은 Balanced, High performance 같은 전통적인 전원 플랜입니다. powercfg /list나 powercfg /getactivescheme로 확인할 수 있습니다.

여기서 복잡한 점은, Windows에 Power mode(전원 모드) 오버레이와 Power plan(전원 플랜) 둘 다 있다는 것입니다. 관계를 그림으로 그리면 다음과 같습니다.

flowchart TB
    subgraph upper["윗층: Power mode - 오버레이"]
        direction LR
        M1["Best power efficiency"]
        M2["Balanced"]
        M3["Best performance"]
    end

    subgraph lower["아랫층: Power plan - 전원 플랜"]
        direction LR
        P1["Balanced"]
        P2["High performance"]
        P3["custom plan"]
    end

    UI["설정 앱<br/>Power and battery의 Power mode"] --> upper
    CLI["powercfg /setactive로 전환"] --> lower
    upper --> PPM["실제로 적용되는 전원 설정<br/>PPM과 그래픽 서브그룹"]
    lower --> PPM
    AC["AC 전원인지 배터리인지"] --> PPM
    PPM --> RESULT["주파수 상한 / 코어 파킹 / 성능 스케일링"]

그림4: Power mode(오버레이)와 Power plan의 두 층과 AC/DC가 합쳐져, 실제로 적용되는 전원 설정이 정해진다.

윗층만, 아랫층만 봐서는 실제 동작이 정해지지 않습니다. 그래서 벤치 결과에는 최소한 다음을 기록하십시오.

• AC인지 배터리인지
• Power mode가 무엇인지
• Active power plan이 무엇인지

이 세 가지를 쓰지 않은 벤치 결과는, 나중에 다시 볼 때 조건을 복원할 수 없습니다.

flowchart TB
    accTitle: 최소한 기록할 세 가지
    accDescr: AC인지 배터리인지, Power mode가 무엇인지, Active power plan이 무엇인지 세 가지를 결과에 기록해 두지 않으면, 나중에 다시 볼 때 조건을 복원할 수 없다는 점을 나타내는 그림.
    r1["AC인지 배터리인지"] --> rec2["결과와 함께 기록한다"]
    r2["Power mode"] --> rec2
    r3["Active power plan"] --> rec2
    rec2 --> rst1["나중에 조건을 복원할 수 있다"]

그림5: 전원 쪽 세 가지는, 쓰지 않으면 결과째 재현 불능이 되는 최소한의 기록이다.

먼저 고정해야 할 전원 조건

1. 노트북은 반드시 AC 연결로 비교한다 배터리 운용은 의도하지 않은 제한이 들어가기 쉽습니다.

2. Power mode를 고정한다 벤치 용도라면 먼저 Best performance를 시도합니다.

3. Active power plan을 기록한다 powercfg로 현재 값을 남깁니다.

powercfg /list
powercfg /getactivescheme

powercfg /list 출력은 Microsoft 문서에서 다음 형태로 제시됩니다. 활성 플랜 행 끝에 *가 붙습니다. 일본어 환경에서는 제목과 플랜 이름이 일본어로 나옵니다.

Existing Power Schemes (* Active)
-----------------------------------
Power Scheme GUID: {guidPlan1}  (Balanced) *
Power Scheme GUID: {guidPlan2}  (Power saver)

여기서 나온 GUID를 그대로 결과 파일의 power_plan 칸에 옮겨 적습니다. 이름이 아니라 GUID를 남기는 것이 핵심입니다. 같은 “균형”이라도 복제나 사용자 지정을 한 다른 플랜인 경우가 있기 때문입니다.

1. 필요하면 High performance로 전환한다

# Balanced
powercfg /setactive 381b4222-f694-41f0-9685-ff5bb260df2e

# High performance
powercfg /setactive 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c

Power mode는 명령으로 바꿀 수 있는가

여기는 막히기 쉬운 지점입니다. powercfg의 공개된 명령줄 옵션 목록에는 Power mode(오버레이) 자체를 다시 고르는 옵션이 없습니다. 전환은 설정 앱의 Settings > System > Power & battery에서 하는 것이 정규 절차입니다.

한편 powercfg는 오버레이 구성(scheme)의 설정값 읽기·쓰기를 지원합니다. 문서에는 다음 서술이 있습니다.

• powercfg /q에 오버레이 별칭과 서브그룹을 넘기면 오버레이 쪽 설정을 읽을 수 있다
• powercfg /setacvalueindex와 /setdcvalueindex는 오버레이 구성에도 쓸 수 있다
• 구성을 지정하지 않은 경우에는 현재 활성 오버레이(오버레이가 없으면 현재 전원 플랜)가 대상이 된다
• 별칭 목록은 powercfg /aliases로 확인할 수 있다

즉 명령으로 할 수 있는 것은 “지금 적용 중인 오버레이 내용을 읽거나 조정하는 것”이지, “어느 오버레이를 고를지”를 바꾸는 것이 아닙니다. 벤치 재현 절차로는 설정 앱에서 Power mode를 손으로 고정하고, 그 값을 결과에 남겨 두는 것이 현실적입니다. 절차서에는 “Power mode = Best performance로 설정했다”고 명시하고, 실행할 때마다 화면에서 확인합니다.

flowchart TB
    accTitle: powercfg로 할 수 있는 일과 할 수 없는 일
    accDescr: powercfg는 지금 적용 중인 오버레이의 설정값 읽기·쓰기는 지원하지만, 어느 오버레이를 고를지를 바꾸는 옵션은 없으므로, Power mode는 설정 앱에서 손으로 고정하고 값을 남겨 두는 것이 현실적이라는 점을 나타내는 그림.
    pc1["powercfg"] -->|"할 수 있다"| rw1["오버레이 내용을 읽거나 조정한다"]
    pc1 -.->|"할 수 없다"| sel1["어느 오버레이를 고를지의 변경"]
    sel1 --> hand1["설정 앱에서 손으로 고정하고 기록"]

그림6: 오버레이 선택은 명령으로는 바꿀 수 없으므로, 손으로 고정하고 기록한다.

“High performance가 안 나온다”는 흔하다

여기도 빠지기 쉬운 지점입니다. Microsoft 문서에서는 Modern Standby를 지원하는 디바이스에서는 Balanced, 또는 Balanced에서 파생된 플랜만 허용된다고 합니다. 그래서 “High performance가 안 보인다, 고장인가?”가 아니라 그 기종 설계상 그렇게 되어 있을 가능성이 있습니다.

또한 Microsoft는 “Power mode를 바꿀 수 없는 경우, custom power plan이 선택되어 있을 수 있으니 먼저 Balanced를 골라 보라”고 안내합니다. Power mode UI가 움직이지 않을 때는 여기를 의심하는 것이 빠릅니다.

flowchart TB
    accTitle: High performance가 안 나올 때의 보는 법
    accDescr: Modern Standby를 지원하는 디바이스에서는 Balanced 또는 그 파생 플랜만 허용되므로 High performance가 안 나오는 것은 설계이며, Power mode UI를 바꿀 수 없을 때는 custom plan이 선택되어 있을 가능성을 먼저 의심한다는 점을 나타내는 그림.
    nohp1["High performance가 안 보인다"] --> ms1["Modern Standby 지원 기기면 설계대로"]
    nomv1["Power mode UI가 움직이지 않는다"] --> cst1["custom plan 가능성을 의심한다"]
    cst1 --> bl1["먼저 Balanced를 골라 본다"]

그림7: 플랜이 안 나오거나 UI가 움직이지 않는 것은 고장이라고 단정할 수 없으며, 기종 설계와 플랜 선택을 먼저 본다.

백그라운드 노이즈를 줄인다

Windows는 이쪽이 조용히 재고 싶을 때도 뒤에서 업데이트나 인덱스 작성이나 스캔을 돌립니다. 먼저 그 양을 줄입니다.

일단 다시 시작한 뒤, 가라앉을 때까지 기다린다

설정 변경 후에는 한 번 다시 시작하고, 로그인한 직후가 아니라 몇 분 기다립니다. 시작 직후에는 업데이트, 인덱스, 동기화, Defender, 각종 상주가 아직 활발합니다.

flowchart TB
    accTitle: 다시 시작하고 가라앉을 때까지 기다린다
    accDescr: 설정 변경 후에는 한 번 다시 시작하고, 시작 직후에는 업데이트나 인덱스, 동기화, Defender 등이 움직이므로 로그인한 직후가 아니라 몇 분 기다린 뒤에 잰다는 절차를 나타내는 그림.
    chg1["설정을 변경한다"] --> rb1["한 번 다시 시작한다"]
    rb1 --> wt1["로그인 후 몇 분 기다린다"]
    wt1 --> ms2["그다음에 측정을 시작한다"]
    rb1 -.-> nzz1["시작 직후에는 상주가 아직 활발하다"]

그림8: 측정을 시작하는 것은, 다시 시작한 뒤 백그라운드 활동이 가라앉은 다음이다.

엄밀한 비교라면 clean boot를 쓴다

Microsoft는 clean boot로 최소한의 시작 구성으로 만드는 절차를 안내합니다. msconfig에서 Microsoft 이외의 서비스를 멈추고, Task Manager에서 Startup apps를 사용하지 않도록 하는 방법입니다.

이것은 노이즈를 줄이는 데는 강력합니다. 다만 일상 이용 환경과는 멀어지므로, “코드 차이를 보기 위한 랩 비교”에 쓰는 편이 맞습니다.

알림을 끈다

Windows 알림 배너는 가볍게 보이지만 의외로 방해입니다. 시각적으로 방해일 뿐 아니라, 실행 타이밍이나 포커스, 백그라운드 앱 활동을 바꾸기도 합니다.

Do not disturb를 수동으로 켜거나, 적어도 벤치 중에는 알림을 끕니다.

검색 인덱스와 동기화를 줄인다

벤치 대상이 대량 파일을 읽고, 생성물을 대량으로 쓰고, 소스 트리를 여러 번 다시 만드는 유형이라면, 검색 인덱스나 클라우드 동기화가 은근히 파고듭니다.

• 벤치용 디렉터리를 검색 대상에서 뺀다
• OneDrive / Dropbox / Google Drive 등의 동기화를 멈춘다
• 브라우저, Teams, Discord, Slack을 닫는다

이쪽은 화려하지는 않지만, 효과가 있을 때는 꽤 큽니다.

flowchart TB
    accTitle: 파일을 많이 다루는 벤치에 파고드는 노이즈
    accDescr: 대량 파일을 읽고 쓰는 유형의 벤치에서는 검색 인덱스와 클라우드 동기화와 상주 앱이 측정에 파고들므로, 제외 설정이나 중지로 노이즈를 줄인다는 점을 나타내는 그림.
    ix1["검색 인덱스"] --> hit1["파일을 많이 다루는 벤치에 파고든다"]
    sy1["클라우드 동기화"] --> hit1
    ap2["상주 앱"] --> hit1
    hit1 --> cutn1["제외·중지로 노이즈를 줄인다"]

그림9: 파일을 대량으로 읽고 쓰는 벤치일수록, 인덱스와 동기화 중지가 효과가 크다.

열을 맞추지 않은 비교는, 대개 열을 비교하고 있다

CPU나 GPU는 식어 있을 때와 데워진 뒤에 동작 클럭이 달라집니다. 같은 코드라도 실행할 때마다 조건이 바뀐다는 뜻입니다. 특히 노트북, 슬림 미니 PC, 소형 데스크톱에서 두드러집니다.

flowchart TB
    accTitle: 열로 조건이 바뀌는 구조
    accDescr: CPU나 GPU는 식어 있을 때와 데워진 뒤에 동작 클럭이 달라지므로, 같은 코드라도 실행할 때마다 조건이 바뀌고, 열을 맞추지 않은 비교는 대개 열을 비교하게 된다는 구조를 나타내는 그림.
    cold1["식은 상태에서 실행"] --> hot1["데워지면 클럭이 바뀐다"]
    hot1 --> vary1["실행할 때마다 조건이 바뀐다"]
    vary1 -.-> heatc1["맞추지 않은 비교는 열을 비교하고 있다"]

그림10: 클럭은 열에 따라 움직이므로, 열 조건을 맞추지 않으면 코드가 아니라 냉각을 비교하게 된다.

지켜야 할 규칙

• 실온을 가능한 한 맞춘다
• 노트북 놓는 방식을 고정한다
• AC 어댑터, 도크, 외부 디스플레이 구성을 고정한다
• 벤치 전에 무거운 작업을 하지 않는다
• 첫 실행과 정상 상태를 나누어 잰다

실행 순서는 번갈아 한다

A를 10번 한 다음 B를 10번은 피합니다. 열, 캐시, 백그라운드 활동의 치우침이 실리기 때문입니다.

추천은 다음 중 하나입니다.

• A B A B A B ...
• A B B A A B B A ...
• 무작위 순서를 미리 만들어, 그 순으로 돌린다

flowchart TB
    accTitle: 실행 순서에 따라 치우침이 실리는 방식이 달라진다
    accDescr: A를 먼저 전부 돌린 다음 B를 돌리면 열이나 캐시, 백그라운드 활동의 치우침이 한쪽에만 실리므로, 번갈아 또는 무작위 순으로 돌려 치우침을 양쪽에 분산시킨다는 점을 나타내는 그림.
    seq1["A를 전부 → B를 전부"] --> bias1["치우침이 한쪽에만 실린다"]
    alt1["A B A B로 번갈아·무작위 순"] --> even1["치우침이 양쪽에 분산된다"]
    even1 --> fair1["순서의 영향을 차이에서 제거할 수 있다"]

그림11: 순서를 몰아서 하면 치우침까지 비교하게 되므로, 번갈아 또는 무작위로 돌린다.

무엇을 재느냐에 따라 “빠르다”의 의미가 달라진다

“빠르다”를 숫자 하나에 밀어 넣으면, 대개 사고가 납니다. Windows에서 봐야 할 대표적인 지표는 다음 세 가지입니다.

1. Wall-clock time(경과 시간)

사용자가 기다리는 시간입니다. 엔드투엔드 체감에 가장 가까우므로, 먼저 보는 값은 이것입니다.

Windows에서는 QueryPerformanceCounter(QPC)를 고해상도 시각을 얻는 데 쓸 수 있습니다. managed code라면 Stopwatch 계열을 쓰는 것이 기본입니다. DateTime.Now로 밀리초를 보는 것은, 역시 조금 무방비입니다.

2. CPU time(사용자 + 커널 시간)

GetProcessTimes로 얻을 수 있는, 프로세스가 실제로 CPU를 쓴 시간입니다.

이것은 계산 효율을 보는 데 편리합니다. 예를 들어 wall-clock은 빨라졌는데 CPU time이 그대로라면, 캐시, I/O, 대기 시간, 스케줄링이 영향을 주고 있을 가능성이 있습니다.

3. Cycle count(CPU 사이클 수)

QueryProcessCycleTime으로 프로세스 전체 CPU 사이클 수를 얻을 수 있습니다.

이것도 CPU work를 보는 지표이지만, wall-clock과는 다른 면을 보여 줍니다. 특히 “대기 시간은 같은데 계산 부분은 가벼워졌는지”를 보고 싶을 때 편리합니다.

flowchart TB
    accTitle: 세 지표가 보는 면의 차이
    accDescr: wall-clock time은 사용자가 기다리는 시간, CPU time은 프로세스가 실제로 CPU를 쓴 시간, cycle count는 CPU 사이클 수라는 다른 면을 보이며, 조합해야 비로소 빠름의 속을 읽을 수 있다는 점을 나타내는 그림.
    spd1["“빠르다”의 속을 본다"] --> w1["wall-clock: 기다리는 시간"]
    spd1 --> u1["CPU time: 쓴 CPU 시간"]
    spd1 --> cy1["cycle: 계산 부분의 무게"]
    w1 -.-> mixr1["조합으로 이유를 추정한다"]

그림12: 숫자 하나에 밀어 넣지 않고, 세 지표의 조합으로 빠름의 의미를 읽는다.

priority, affinity, NUMA는 마지막 수단

이쪽은 효과가 있을 때가 있습니다. 하지만 효과가 있다고 처음부터 건드리면, 다른 현상을 만들기 쉽습니다.

일단 그대로 잰다

기본 상태에서 차이가 나면, 그 차이 자체에 가치가 있습니다. 처음부터 /high나 /affinity를 넣으면 “실제 Windows에서는 일어나지 않는 조건”을 끌어들이게 됩니다.

flowchart TB
    accTitle: priority와 affinity는 마지막 수단
    accDescr: 먼저 기본 상태에서 재고, 차이가 나면 그 차이 자체에 가치가 있으며, 처음부터 우선순위나 affinity를 고정하면 실제 Windows에서는 일어나지 않는 조건을 끌어들이게 되므로, 쓸 때는 목적을 명확히 하고 마지막에 쓴다는 점을 나타내는 그림.
    def1["먼저 기본 상태에서 잰다"] --> val1["차이가 나면 그 차이에 가치가 있다"]
    early1["처음부터 /high나 /affinity"] -.-> art1["현실에는 없는 조건을 끌어들인다"]
    val1 -->|"필요해지면 목적을 정해"| lastr1["마지막 수단으로 고정한다"]

그림13: 우선순위와 affinity는, 기본 상태 측정을 마친 뒤에 목적을 갖고 쓴다.

쓸 때는 목적을 명확히 한다

• /high: 다른 프로세스의 방해를 덜 받고 싶다
• /affinity: CPU 배치를 고정해 비교하고 싶다
• NUMA 제어: 대규모 머신에서 메모리 지역성까지 맞추고 싶다

Windows의 start 명령은 priority class나 affinity mask를 붙여 시작할 수 있습니다.

start "" /high /wait myapp.exe --bench case1.json
start "" /affinity F /high /wait myapp.exe --bench case1.json

다만 /realtime은 그만둔다

/realtime은 쓸 수 있지만, 쓰지 않는 편이 낫습니다. 노이즈 제거가 아니라 다른 사고를 만드는 쪽으로 움직이기 쉽습니다.

측정 절차 추천

여기까지를 바탕으로, 실무에서 쓰기 쉬운 절차를 정리합니다.

랩에 가까운 비교 절차

1. 비교 대상을 고정한다
   • commit hash / build number
   • compiler / runtime version
   • Debug / Release
   • 로그, assert, 트레이스 유무
2. 머신 조건을 고정한다
   • Windows build
   • BIOS / UEFI version
   • driver version
   • AC 연결
   • 실온, 거치 방법
3. 전원 조건을 고정한다
   • Power mode를 정한다
   • Active power plan을 기록한다
4. 다시 시작한다
5. 벤치 전에 몇 분 기다린다
6. 필요하면 clean boot
7. warm-up을 넣는다
8. A / B를 번갈아 돌린다
9. 횟수를 확보한다
10. 중앙값·최소·최대·p95를 남긴다
11. raw data를 저장한다
12. 차이가 작으면 ETW / WPR을 잡는다

몇 번 돌릴까

9번의 “횟수를 확보한다”의 기준도 정해 둡니다. 아래는 통계적으로 엄밀한 해가 아니라, 실무에서의 타협점입니다.

소요 시간은 1회 실행 시간 × 횟수 × 버전 수 + warm-up으로 어림잡을 수 있습니다. 1회 30초 처리를 A / B 각각 30회라면, warm-up을 넣어 35분 전후라는 계산입니다. 이것이 현실적이지 않을 때는 횟수를 깎기보다 재는 대상을 작게 자르는 것(무거운 공정만 잘라 내기)이 낫습니다.

멈출 지점이 헷갈리면, 횟수를 늘리며 중앙값 추이를 보고, 늘려도 움직이지 않게 된 지점에서 멈추는 것이 알기 쉬운 방법입니다.

flowchart TB
    accTitle: 횟수의 멈출 지점
    accDescr: 횟수를 늘리며 중앙값 추이를 보고, 늘려도 중앙값이 움직이지 않게 된 지점에서 멈춘다는, 실행 횟수의 실무적 정하는 법을 나타내는 그림.
    add2["횟수를 늘려 돌린다"] --> mdz1["중앙값 추이를 본다"]
    mdz1 -->|"아직 움직인다"| add2
    mdz1 -->|"늘려도 움직이지 않는다"| stop1["거기서 멈춘다"]

그림14: 횟수는 처음부터 고정하지 못해도, 중앙값이 가라앉은 지점을 멈출 지점으로 삼을 수 있다.

기록해 두면 나중에 도움이 되는 항목

벤치 CSV나 JSON에는 적어도 다음을 남겨 두면 강합니다.

timestamp,version,scenario,elapsed_ms,user_ms,kernel_ms,cycles,power_mode,power_plan,ac_or_dc,room_temp_c,notes

가능하면 다음도 있으면 편리합니다.

cpu_package_temp_start_c,cpu_package_temp_end_c,affinity_mask,priority_class,windows_build,driver_version

벤치는 재는 것보다 나중에 해석할 수 있는 것이 더 중요할 때가 있습니다.

평균뿐 아니라, 중앙값과 분포를 본다

평균은 편리하지만, Windows 벤치에서는 쉽게 깨집니다. 한 번만 Defender가 들어왔거나, 알림이 떴거나, 다른 프로세스가 SSD를 두드린 것만으로 평균이 끌려갑니다.

flowchart TB
    accTitle: 평균은 이상치에 끌려간다
    accDescr: 한 번만 Defender 스캔이나 알림이나 다른 프로세스 I/O가 들어가도 평균은 끌려가므로, 중앙값을 축으로 p95나 p99, min/max를 조합해 분포로 본다는 점을 나타내는 그림.
    once3["한 번만 노이즈가 들어온다"] --> avg1["평균이 끌려간다"]
    med2["중앙값을 축으로 한다"] --> dist1["p95 / p99와 min / max도 본다"]
    dist1 --> robust1["이상치에 강한 읽기가 된다"]

그림15: 평균은 한 번의 노이즈로 깨지므로, 중앙값과 분포의 조합으로 읽는다.

추천은 이 조합입니다.

• 중앙값: 먼저 이것을 본다
• p95 / p99: tail이 나빠지지 않았는지 본다
• min / max: 벗어나는 방식을 본다
• 상자 그림이나 산점도: 차이가 작을 때 도움이 된다

차이가 났을 때의 읽는 법

결과 해석은 조합으로 보면 알기 쉽습니다.

wall-clock만 빠르다

I/O, 대기 시간, 캐시, 스케줄링 개선일 수 있습니다.

CPU time도 cycle도 내려가 있다

구현 자체가 가벼워졌을 가능성이 높습니다.

첫 회만 느리거나 / 빠르다

cold / warm 차이입니다. 시작·초기화·캐시 생성·JIT를 의심합니다.

회를 거듭할수록 느려진다

열, 스로틀링, 메모리 압박, 백그라운드 활동을 의심합니다.

flowchart TB
    accTitle: 차이 패턴에서 원인을 읽는다
    accDescr: wall-clock만 빠르면 대기나 I/O 계열, CPU time도 cycle도 내려가면 구현이 가볍다, 첫 회만 다르면 cold와 warm 차이, 회를 거듭해 느려지면 열이나 백그라운드를 의심한다는 읽는 법을 나타내는 그림.
    pt2["차이가 나는 방식을 본다"] -->|"경과 시간만"| c1a["대기·I/O 계열"]
    pt2 -->|"CPU 시간도 감소"| c2a["구현이 가볍다"]
    pt2 -->|"첫 회만"| c3a["cold / warm"]
    pt2 -->|"후반에 느리다"| c4a["열·백그라운드 활동"]

그림16: 차이 자체보다 차이가 나는 방식의 패턴이, 원인 후보를 알려 준다.

ETW / WPR로 “왜 빠른지”까지 파고든다

차이가 작거나, 이유를 읽기 어려울 때는 Windows의 ETW(Event Tracing for Windows) 계열 도구로 가는 것이 정석입니다.

Microsoft의 Windows Performance Recorder(WPR)는 ETW 기반 기록 도구이며, Windows ADK에 포함됩니다. CPU, I/O, context switch, 페이지 폴트 등을 한데 잡을 수 있습니다.

최소한은 이런 식입니다.

wpr -start CPU -filemode

REM 여기서 벤치를 실행한다

wpr -stop trace.etl

WPA에서 연 뒤, 먼저 보는 그래프는 대개 정해져 있습니다.

비교할 때는 같은 시나리오에서 A와 B 트레이스를 하나씩 잡고, 같은 그래프를 나란히 보는 것이 기본입니다. 하나만 봐서는 “이것이 느린가”를 판단할 수 없습니다.

이 단계까지 오면, “B가 3% 빠르다”가 아니라, “B는 lock 대기가 줄어 ready time이 내려갔다” “A는 file open이 늘어 cold start가 느리다” 처럼, 이유를 붙여 이야기할 수 있게 됩니다.

flowchart TB
    accTitle: 숫자만의 차이에서 이유 있는 차이로
    accDescr: 차이가 작거나 이유를 읽기 어려울 때는 WPR로 같은 시나리오의 트레이스를 A와 B에서 하나씩 잡고, WPA에서 같은 그래프를 나란히 비교함으로써, 몇 % 빠르다가 아니라 이유를 붙여 이야기할 수 있게 되는 흐름을 나타내는 그림.
    small2["차이가 작다·이유를 읽기 어렵다"] --> tr1["WPR로 A와 B 트레이스를 잡는다"]
    tr1 --> cmp2["WPA에서 같은 그래프를 나란히 본다"]
    cmp2 --> rsn1["이유를 붙여 이야기할 수 있게 된다"]
    cmp2 -.-> onen1["하나만으로는 느린지 판단할 수 없다"]

그림17: ETW까지 파고들면, “몇 % 빠르다”가 “왜 빠른지”로 바뀐다.

한 장으로 모은 체크리스트

마지막으로, 그대로 절차서에 붙일 수 있는 형태로 남겨 둡니다.

고정한다

• 비교 대상을 고정했다(commit hash / build number / Debug인지 Release인지 / PGO 등 빌드 조건 / 로그나 assert 유무)
• 노트북은 AC 연결로 했다
• Power mode를 설정 앱에서 고정했다
• Active power plan을 powercfg /getactivescheme로 확인했다
• 알림을 껐다. 검색 인덱스와 클라우드 동기화를 멈췄다
• 필요하면 clean boot로 했다
• 다시 시작하고, 몇 분 기다린 뒤 시작했다

실행한다

• warm-up을 넣었다
• cold(첫 회)와 warm(정상)을 나누어 쟀다
• A / B를 번갈아, 또는 무작위 순으로 돌렸다
• 횟수를 정해 돌렸다(기준은 위의 표)

기록한다

• 1실행 1행의 raw data를 남겼다(elapsed_ms / user_ms / kernel_ms / cycles)
• AC인지 DC인지, Power mode(전원 모드), Power plan(전원 플랜)의 GUID, Windows build, driver version을 남겼다
• 실온과 거치 상태를 남겼다
• 고정하지 않은 조건도 적어 남겼다

해석한다

• 중앙값을 봤다. 평균만으로 판단하지 않았다
• p95 / p99로 tail을 봤다
• min / max로 이상치를 확인했다
• wall-clock / CPU time / cycle 조합으로 이유를 추정했다
• 차이가 작을 때는 ETW / WPR까지 파고들었다

정리

Windows에서 버전이 다른 프로그램을 비교할 때, 정말로 효과가 있는 것은 화려한 트릭이 아닙니다. 중요한 것은 다음과 같은 수수하지만 재현성을 높이는 방식입니다.

• AC / Power mode(전원 모드) / Power plan(전원 플랜)을 고정하고 기록한다
• cold와 warm을 나눈다
• A / B를 번갈아 돌린다
• 중앙값과 분포를 본다
• 필요하면 clean boot
• 차이가 작으면 ETW / WPR로 이유까지 파고든다

그리고 가장 중요한 것은, 무엇을 고정하고 무엇을 고정하지 않았는지를 결과와 함께 쓰는 것입니다. 벤치는 속도 비교인 동시에, 실험 조건의 기록이기도 합니다.

조건이 적혀 있지 않은 속도 개선 보고는, 같은 결과를 낼 수 있는지를 다른 사람이 확인할 수 없습니다. 숫자만 남고 재현 수단이 남지 않기 때문입니다. 반대로 조건이 제대로 적혀 있으면, 차이가 작더라도 그 결과에는 분명히 가치가 있습니다.

flowchart TB
    accTitle: 조건 기록이 결과의 가치를 정한다
    accDescr: 조건이 적혀 있지 않은 속도 개선 보고는 숫자만 남아 재현 수단이 남지 않고, 조건이 제대로 적혀 있으면 차이가 작더라도 가치가 있다는, 벤치가 실험 조건의 기록이기도 하다는 점을 나타내는 그림.
    norec1["조건을 쓰지 않은 보고"] --> onlyn1["숫자만 남는다"]
    onlyn1 --> norep1["다른 사람이 확인할 수 없다"]
    rec3["조건을 쓴 보고"] --> rep1["재현 수단이 남는다"]
    rep1 --> worth1["차이가 작더라도 가치가 있다"]

그림18: 벤치의 가치는 숫자보다, 무엇을 고정하고 무엇을 고정하지 않았는지의 기록에 있다.

참고 자료

• Microsoft Support: Change the power mode for your Windows PC
• Microsoft Learn: Power Policy Settings
• Microsoft Learn: Customize the Windows performance power slider
• Microsoft Learn: Powercfg command-line options
• Microsoft Support: How to perform a clean boot in Windows
• Microsoft Support: Notifications and Do Not Disturb in Windows
• Microsoft Support: Search indexing in Windows
• Microsoft Learn: Configure custom exclusions for Microsoft Defender Antivirus
• Microsoft Support: Device Security in the Windows Security App
• Microsoft Learn: QueryPerformanceCounter function
• Microsoft Learn: Acquiring high-resolution time stamps
• Microsoft Learn: GetProcessTimes function
• Microsoft Learn: QueryProcessCycleTime function
• Microsoft Learn: start command
• Microsoft Learn: SetPriorityClass function
• Microsoft Learn: SetProcessAffinityMask function
• Microsoft Learn: Processor Groups
• Microsoft Learn: Windows Performance Recorder
• Microsoft Learn: WPR Command-Line Options
• Microsoft Learn: CPU Analysis in Windows Performance Analyzer - 어느 그래프에서 무엇을 볼지.
• Microsoft Learn: Set the Default Power Plan - powercfg -LIST 출력 예.

관련 기사

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

관련 토픽

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

이 주제와 연결되는 서비스

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

자주 묻는 질문

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

Windows에서 벤치마크 결과가 흔들리는 주된 원인은 무엇인가요?

Power mode(전원 모드)나 Power plan(전원 플랜), 열, 백그라운드 업데이트, 검색 인덱스, 바이러스 스캔, 우선순위·affinity, 실행 순서, 캐시 상태 등 여러 층의 요인이 있습니다. 같은 Windows 머신이라도 이런 조건이 맞지 않으면 실질적으로 다른 실험입니다. 특히 노트북에서는 AC 연결인지 배터리 구동인지에 따라 동작이 크게 달라지므로, 반드시 AC 연결로 비교하고 조건을 기록하는 것이 중요합니다.

Power mode(전원 모드)와 Power plan(전원 플랜)은 무엇이 다른가요?

Power mode는 설정 앱의 Power & battery에서 고르는 Best power efficiency·Balanced·Best performance 전환이며, 이면의 전원 관련 설정과 PPM(Processor Power Management) 동작에 영향을 줍니다. Power plan은 powercfg로 확인할 수 있는 Balanced나 High performance 같은 전통적인 전원 플랜입니다. Windows에는 둘 다 있으므로, 벤치 결과에는 AC인지 배터리인지·Power mode·Active power plan 세 가지를 최소한 기록해 두어야 합니다.

High performance 전원 플랜이 보이지 않는 것은 고장인가요?

고장이 아닐 가능성이 높습니다. Microsoft 문서에서는 Modern Standby를 지원하는 디바이스에서는 Balanced, 또는 Balanced에서 파생된 플랜만 허용된다고 합니다. 즉 그 기종 설계상 High performance가 나오지 않는 일은 흔합니다. 또한 Power mode UI를 바꿀 수 없는 경우에는 custom power plan이 선택되어 있을 수 있으므로, 먼저 Balanced를 골라 보는 것이 빠릅니다.

버전 A와 B의 속도 비교는 어떤 순서로 실행해야 하나요?

A를 먼저 전부 돌린 다음 B를 돌리는 방식은 피해야 합니다. 열·캐시·백그라운드 활동의 치우침이 한쪽에만 실리기 때문입니다. A B A B처럼 번갈아 돌리거나, 미리 생성한 무작위 순서로 실행합니다. 또한 식은 첫 회와 데워진 뒤의 정상 상태를 나누어 측정하고, 평균뿐 아니라 중앙값·p95·최소·최대를 보면 이상치에 결과가 끌려가는 것을 막을 수 있습니다.

저자 프로필

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

Go Komura

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

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