윈도우는 부팅할 때마다 걸린 시간을 밀리초 단위로 기록해 두고, 그 시간을 커널·드라이버·서비스가 올라오는 구간(MainPathBootTime)과 바탕화면이 뜬 뒤 낮은 우선순위 프로그램이 올라오는 구간(BootPostBootTime) 둘로 쪼개 놓는다. 시작 프로그램을 꺼서 줄일 수 있는 쪽은 뒤쪽 구간뿐이다. 윈도우 내부 기준으로 뒤쪽 구간이 문제로 분류되기 시작하는 경계는 30초, 앞쪽 구간은 60초다. 부팅이 90초 걸리는데 그중 62초가 앞쪽 구간이라면 시작 앱을 전부 꺼도 줄일 수 있는 산술적 상한은 28초, 전체의 31%다. 어느 구간이 긴지 보지 않고 시작 프로그램부터 끄는 조치가 자주 헛도는 이유가 이것이다.
아래는 마이크로소프트 공식 문서에 적힌 필드 정의와 임계값을 기준으로, 자기 PC의 로그 값을 넣으면 어떤 조치에 몇 초의 상한이 걸리는지 계산하는 절차다. 기준일은 2026년 10월 3일이며, 윈도우 10·11의 이벤트 뷰어에서 그대로 확인할 수 있다.
윈도우가 이미 재 둔 숫자부터 읽는다
부팅 성능 진단 이벤트는 Microsoft-Windows-Diagnostics-Performance/Operational 로그에 쌓인다. 이벤트 뷰어에서는 응용 프로그램 및 서비스 로그 → Microsoft → Windows → Diagnostics-Performance → Operational 경로다. 관리자 권한 PowerShell에서는 한 줄로 최근 10회분을 꺼낼 수 있다.
Get-WinEvent -LogName "Microsoft-Windows-Diagnostics-Performance/Operational" |
Where-Object { $_.Id -eq 100 } | Select-Object -First 10 TimeCreated, LevelDisplayName, Message
여기서 읽어야 할 값은 세 개다. BootTime은 전체 부팅 시간, MainPathBootTime은 시스템이 상호작용 가능한 상태가 되기까지 커널 드라이버와 서비스를 모두 올리는 데 걸린 시간, BootPostBootTime은 그 뒤 낮은 우선순위 프로세스와 서비스를 올리는 데 걸린 시간이다. 세 값의 관계는 단순하다.
MainPathBootTime = BootTime − BootPostBootTime
이 관계는 Diagnostics-Performance 이벤트 100의 등급 산정 로직을 설명한 마이크로소프트 포럼 아카이브 문서에 그대로 적혀 있다. 같은 문서가 이벤트 등급을 “MainPathBootTime 기준 판정”과 “PostBootTime 단독 판정” 두 가지로 계산한 뒤 더 심각한 쪽을 이벤트 수준으로 붙인다고 밝히고 있다. 즉 이벤트 100이 ‘오류’로 떠 있다 해도 그게 어느 구간 때문인지는 등급만 봐서는 알 수 없고, 두 숫자를 직접 봐야 한다.
이벤트 100 자체의 뜻은 마이크로소프트 TechNet 위키 아카이브의 이벤트 100 항목에 “Windows has started up”으로 정의돼 있다. 부팅 성능 진단은 이벤트 100부터 110까지가 한 묶음이다.
30초·60초·120초 — 윈도우가 쓰는 경계값
이벤트 등급을 가르는 임계값은 레지스트리 HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Diagnostics\Performance\Boot에 들어 있고, 기본값은 네 개다. 앞서 언급한 포럼 아카이브 문서에 소스 코드 상수 이름과 함께 그대로 공개돼 있다.
| 상수 | 기본값 | 적용 구간 | 넘으면 |
|---|---|---|---|
| PostBootMinorThreshold_Sec | 30초 | BootPostBootTime | 경미한 문제로 분류 |
| PostBootMajorThreshold_Sec | 60초 | BootPostBootTime | 심각한 문제로 분류 |
| BootMinorThreshold_Sec | 60초 | MainPathBootTime | 경미한 문제로 분류 |
| BootMajorThreshold_Sec | 120초 | MainPathBootTime | 심각한 문제로 분류 |
경계가 구간마다 다르다는 점이 중요하다. 뒤쪽 구간은 30초만 넘어도 윈도우가 눈여겨보지만, 앞쪽 구간은 60초까지는 같은 취급을 받지 않는다. 바꿔 말해 MainPathBootTime이 55초인 PC는 이벤트 등급상 멀쩡해 보이지만, 체감 부팅 시간의 대부분을 이미 그 구간이 먹고 있다.
내 로그 값을 넣어 조치별 상한을 계산한다
조치를 고르기 전에 계산해야 할 것은 “그 조치가 손댈 수 있는 구간이 몇 초인가”다. 시작 프로그램 정리·지연 실행은 BootPostBootTime 안에서만 효과가 있고, 저장장치 교체나 드라이버 교체는 주로 MainPathBootTime에 작용한다. 그래서 효과 상한은 이렇게 나온다.
시작 프로그램 정리의 효과 상한 = BootPostBootTime ÷ BootTime × 100(%)
드라이버·저장장치 쪽 조치의 효과 상한 = MainPathBootTime ÷ BootTime × 100(%)
아래 표는 BootTime을 90초로 고정하고 두 구간의 분배만 바꿔, 같은 조치가 PC마다 몇 초짜리 일이 되는지 계산한 것이다. 특정 기기를 측정한 값이 아니라 분배 비율을 달리한 예시이며, 독자는 자기 이벤트 100의 실제 값을 같은 식에 넣으면 된다.
| 사례 | MainPathBootTime | BootPostBootTime | 시작 앱 정리 상한 | 드라이버·디스크 쪽 상한 |
|---|---|---|---|---|
| A — 앞쪽이 긴 PC | 62초 | 28초 | 28초 (31%) | 62초 (69%) |
| B — 반반 | 45초 | 45초 | 45초 (50%) | 45초 (50%) |
| C — 뒤쪽이 긴 PC | 25초 | 65초 | 65초 (72%) | 25초 (28%) |
| D — 둘 다 짧은 PC | 18초 | 12초 | 12초 (40%) | 18초 (60%) |
A 사례에서 시작 프로그램을 전부 비활성화해도 90초가 62초 아래로는 내려가지 않는다. 더구나 28초를 전부 없애는 일은 현실적으로 불가능하므로 실제 감소분은 그보다 작다. 반대로 C 사례는 BootPostBootTime이 65초로 PostBootMajorThreshold_Sec(60초)까지 넘겼으니, 시작 프로그램 정리가 가장 큰 단일 조치가 된다. D 사례는 전체 30초로 두 임계값을 모두 밑돌아, 손댈 이유 자체가 약하다.
101~110 이벤트로 범인을 좁힌다
구간을 갈랐으면 그 구간에서 누가 시간을 먹었는지는 같은 로그의 후속 이벤트가 알려준다. 이벤트 101 문서와 앞의 이벤트 100 문서가 100~110번의 의미를 표로 정리해 두었다.
| 이벤트 ID | 의미 | 주로 작용하는 구간 |
|---|---|---|
| 101 | 이 애플리케이션이 평소보다 오래 걸려 시작됨 | BootPostBootTime |
| 102 | 이 드라이버의 초기화가 오래 걸림 | MainPathBootTime |
| 103 | 이 시작 서비스가 예상보다 오래 걸려 시작됨 | MainPathBootTime |
| 106 | 백그라운드 최적화 작업이 오래 걸림 | BootPostBootTime |
| 107 / 108 | 컴퓨터 정책 / 사용자 정책 적용이 부팅을 늦춤 | 주로 도메인 환경 |
| 109 | 이 장치의 초기화가 오래 걸림 | MainPathBootTime |
| 110 | 세션 관리자 초기화가 부팅을 늦춤 | MainPathBootTime |
이 이벤트들에는 원인이 된 실행 파일·드라이버 이름과 함께 늘어난 시간이 밀리초로 들어간다. 최근 20회 부팅분을 ID별로 모아 합산하면 반복해서 올라오는 범인이 드러난다.
Get-WinEvent -LogName "Microsoft-Windows-Diagnostics-Performance/Operational" |
Where-Object { $_.Id -ge 101 -and $_.Id -le 110 } |
Group-Object Id | Sort-Object Count -Descending
주의할 점은 101~110이 임계값을 넘겼을 때만 기록된다는 것이다. 로그가 비어 있다고 해서 문제가 없다는 뜻은 아니고, 각각은 작지만 수십 개가 모여 느려지는 경우는 여기에 잡히지 않는다. 그런 경우에도 이벤트 100의 두 구간 값은 남으므로 판정의 출발점은 여전히 100번이다. 윈도우 업데이트 직후 부팅이 느려졌다면 107·108과 함께 업데이트 자체의 실패 여부도 같이 봐야 하는데, 이 부분은 윈도우 업데이트 오류의 원인별 대응 순서에서 따로 다뤘다.
‘빠른 시작’을 둘러싼 오해 두 가지
부팅이 느릴 때 가장 많이 권해지는 조치가 빠른 시작(Fast Startup) 설정 변경인데, 공식 문서와 어긋나는 대목이 두 군데 있다.
첫째, 빠른 시작은 ‘다시 시작’에 적용되지 않는다. 마이크로소프트 지원 문서 KB 3211190은 “빠른 시작 설정은 다시 시작에 적용되지 않는다”고 명시한다. 윈도우는 다시 시작 시 드라이버 교체 등을 위해 전체 부팅 주기를 수행하며, 빠른 시작의 성능 이득 없이 돈다. 빠른 시작을 켜 두고 다시 시작으로만 부팅 시간을 재면 효과가 보이지 않는 게 당연하다. 비교하려면 종료 후 전원을 켜는 쪽으로 재야 한다.
둘째, 마이크로소프트는 빠른 시작을 끄는 것을 권장하지 않는다. 같은 문서가 “빠른 시작을 비활성화하는 것은 권장되지 않는다”고 적고 있다. 다만 같은 문서는 빠른 시작이 켜져 있을 때 메모리 덤프 구성 초기화 실패로 종료·최대 절전이 실패하고 잠금 화면으로 되돌아가는 증상을 설명하며, 이 경우 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\CrashControl의 DumpFilters 값에 dumpfve.sys만 남기라고 안내한다. 즉 끄는 게 해법이 아니라 원인을 고치는 쪽이다. 한 번만 완전 종료하고 싶다면 설정을 바꾸지 않고 Shutdown /s /t 0으로 충분하다.
빠른 시작이 하는 일은 마이크로소프트 드라이버 문서에 분명하게 적혀 있다. 콜드 부팅은 부트 로더가 커널 파일의 섹션을 메모리에 올려 커널 이미지를 구성하고 장치를 열거해 드라이버를 올리지만, 빠른 시작은 최대 절전 파일(Hiberfil.sys)을 메모리로 읽어 들일 뿐이다. 종료 시점에 모든 사용자 세션을 로그오프한 뒤 커널 메모리 이미지와 커널 모드 드라이버만 저장해 두기 때문에, 전체 최대 절전보다 파일이 작다.
그래서 빠른 시작의 체감 속도는 Hiberfil.sys를 읽는 속도, 곧 시스템 드라이브의 순차 읽기 성능에 직접 묶인다. 파일 크기는 powercfg 명령줄 옵션 문서에 따라 powercfg /hibernate /size로 총 메모리 대비 백분율로 지정하며, 기본 크기는 50 미만으로 내릴 수 없다. 레지스트리 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power의 HiberFileSizePercent가 40 이상이면 전체(full) 최대 절전 파일로 간주된다. 빠른 시작만 쓸 생각이라면 powercfg /hibernate /size 0 후 powercfg /hibernate /type reduced로 축소형 파일을 쓸 수 있다. 16GB 메모리 PC에서 전체형이 기본 설정상 메모리의 40% 이상을 차지한다고 보면 6.4GB 이상을 디스크에서 차지하는 셈이고, 32GB 메모리라면 같은 비율로 12.8GB, 곧 2배가 된다. 축소형으로 바꾸면 그만큼이 줄어든다.
상황별로 먼저 할 일
BootPostBootTime이 30초를 넘는 경우 — 시작 프로그램 정리가 효과 상한이 가장 큰 조치다. 작업 관리자의 시작 앱 탭보다 이벤트 101·106을 먼저 보고, 반복해서 올라오는 실행 파일부터 끈다.
MainPathBootTime이 60초를 넘는 경우 — 시작 앱은 손대 봐야 상한이 낮다. 이벤트 102·109·110을 확인해 특정 드라이버·장치가 반복 등장하는지 보고, 해당 제조사 드라이버를 갱신한다. 특정 범인이 없이 전반적으로 느리면 시스템 드라이브의 읽기 성능이 병목일 가능성이 크다.
둘 다 임계값 아래인데 느리게 느껴지는 경우 — 부팅 자체가 아니라 로그인 후 응답성 문제일 수 있다. 이벤트 100의 BootTime이 30초대인데 체감이 2분이라면, 측정 대상이 틀린 것이다.
이벤트 100이 아예 기록되지 않는 경우 — 앞의 포럼 아카이브 문서에는 7회 부팅 중 2회만 기록됐다는 보고를 비롯해 미기록 사례가 여러 건 남아 있고, 어떤 조건에서 생략되는지는 마이크로소프트 쪽 설명이 없어 추정에 머문다. 5회 이상 부팅해 샘플을 모은 뒤 평균으로 판단하는 편이 안전하다.
기준일과 이 계산이 맞지 않는 경우
임계값 30·60·120초는 레지스트리 기본값이며, 조직 정책이나 제조사 이미지에서 변경돼 있을 수 있다. 위 경로의 값을 직접 확인하면 된다. 이벤트 100~110의 의미를 정리한 마이크로소프트 문서 두 건은 적용 대상이 Windows Server 2008·Windows 7로 표기된 아카이브 문서이고, 임계값 상수를 공개한 문서도 2010년 포럼 스레드의 마이크로소프트 직원 답변이 출처다. 로그 경로와 필드 구성은 현재 윈도우 10·11에서도 동일하게 유지되고 있으나, 수치가 최신 빌드에서 재조정됐을 가능성은 배제할 수 없다. 반면 빠른 시작의 동작·권장 사항·powercfg 옵션은 현행 문서 기준이며, 빠른 시작 문서는 2026년 2월 12일, 드라이버 문서는 2025년 2월 21일이 최종 갱신일이다.
표의 90초 분배 사례는 조건을 고정한 예시 계산이지 특정 기기의 측정값이 아니다. 효과 상한은 어디까지나 상한이며, 해당 구간의 시간을 0으로 만들 수 있다는 뜻이 아니다. 실제 감소분은 그 안에서 어떤 항목을 제거했느냐에 달려 있다. 이 글의 모든 수치는 2026년 10월 3일에 확인했다.