OCCT 사용법: 증상에 맞는 테스트를 고르고 오류를 읽는 방법

게임을 하다가 바탕화면으로 튕기는 PC와 CPU 작업 중 재부팅되는 PC는 점검할 항목이 다르다. OCCT의 각 검사가 어떤 부품에 어떤 부하를 주는지 알면, 증상에 맞는 검사를 고르고 결과에 따라 다음 점검을 정할 수 있다.

OCCT는 CPU·RAM·GPU 등에 부하를 걸어 연산 오류와 시스템 불안정을 확인하는 도구다. 평소에는 기본 설정으로 시작해 증상에 맞는 항목부터 하나씩 돌려보며 원인을 좁혀 간다.

증상에 맞는 OCCT 검사 선택

처음부터 모든 메뉴를 차례대로 실행하기보다, 문제가 생기는 작업과 시점을 먼저 적어 두면 좋다.

영상 인코딩도 CPU로 처리할 때와 GPU 하드웨어 인코더를 쓸 때가 다르다. 프로그램 이름만 보지 말고 실제로 어떤 장치를 쓰는 작업인지 확인한다. 화면 깨짐 역시 모니터·출력 케이블 문제인지, 게임 안에서만 생기는 그래픽 오류인지부터 구분해야 한다.

검사에서 오류가 나면, 해당 부하와 관련된 부품과 설정을 하나씩 확인하며 원인을 좁혀 간다.

OCCT 다운로드와 첫 검사

OCCT 공식 다운로드 페이지에서 운영체제에 맞는 실행 파일을 내려받으면 별도 설치 없이 바로 켜진다. 현재 배포 중인 Personal Stable 버전은 17.1.9다.

아래 화면 캡처는 직접 촬영해 둔 17.0.8 버전 기준이다.

Personal은 개인 용도다. 조립PC 검수나 수리 등 업무에 사용하는 경우에는 Pro 등 업무용 라이선스를 확인해야 한다.

검사 전에는 작업 중인 파일을 저장하고, 증상이 발생하는 프로그램·시점과 현재 BIOS·UEFI(메인보드 설정 화면)의 튜닝 상태를 기록한다. 팬이 돌지 않거나 쿨러 장착이 잘못된 상태, 타는 냄새나 비정상적인 소음이 나는 상태라면 부하 시험부터 시작하지 않는다. 저장장치 고장이 의심되고 중요한 데이터가 남아 있다면 데이터 보존이 먼저다.

CPU 검사를 예로 들면 실행 순서는 다음과 같다.

1. 왼쪽 큰 메뉴의 System Info에서 CPU·GPU·메모리 정보가 점검 대상과 맞는지 확인한다. GPU가 여러 개라면 나중에 검사 화면의 장치 선택에서도 대상 모델명을 확인한다.
2. Stability Test를 누르고, 옆에 펼쳐지는 목록에서 CPU처럼 검사 이름을 누른다. 가운데 제목이 CPU Configuration으로 바뀌는지 본다. Benchmark는 성능을 수치로 비교하는 별도 메뉴다.
3. 검사 화면의 현재 설정을 확인한다. 예를 들어 CPU라면 Mode·Load Type·Instruction Set·Thread Settings를 각각 읽는다. 이전에 바꾼 설정이 남아 있을 수 있으므로, 기본값으로 시작하더라도 선택값은 기록한다. 처음부터 Extreme을 고를 필요는 없다.
4. 검사 목록 위의 시계 아이콘과 시간 표시를 눌러 Duration을 연다. 공식 문서의 Infinite는 직접 중지할 때까지, Fixed는 지정한 시간 동안 실행하는 방식이다. 고정 시간을 고르면 시·분·초를 확인한다. 오류가 나면 멈추도록 하는 Stop on error 설정도 확인한다. 무료 Personal은 공식 안내상 한 번의 검사가 최대 1시간으로 제한된다.
5. 설정을 기록한 뒤 아래쪽 초록색 Start를 누른다. 시작 전 대기 화면이 표시되는 에디션도 있다. 실제 검사 화면으로 넘어오면 오른쪽의 검사 이름·설정 요약과 시간을 본다. 공식 문서상 위쪽 시간은 경과 시간, 아래쪽은 예정 시간 또는 무한 표시다.
6. 가운데 센서 표와 그래프, 오른쪽 상태·로그를 함께 본다. 중지하려면 오른쪽 아래 Stop을 누른다. 종료 뒤 로그를 먼저 남기고 Go Back으로 설정 화면에 돌아간다. 보고서 저장 방법은 뒤의 ‘로그와 보고서를 저장한다’에서 설명한다.

처음 화면 구성을 익힐 때는 시간을 1분(00:01:00) 정도로 짧게 두고 경과 시간과 로그가 어디에 찍히는지 먼저 살펴보면 편하다. 짧은 테스트라도 실제 부하가 걸리므로 온도가 비정상적으로 치솟으면 바로 멈춘다.

안정성을 점검할 때는 평소 증상이 나타나기까지 걸리는 시간을 고려해 검사 시간을 정한다. 가령 게임 시작 후 15~20분에 튕긴다면, 30분을 첫 비교 시간으로 잡을 수 있다.

물론 30분이나 1시간 동안 오류가 뜨지 않았다고 해서 간헐적인 튕김까지 모두 해결됐다고 단정할 수는 없으니, 테스트 후에는 원래 문제가 생겼던 게임이나 작업을 다시 돌려보며 확인하는 게 좋다.

오류 표시와 검사 종료 상태 읽기

미검출 표시와 정상 완료는 다르다

화면에 No errors detected가 떠 있더라도 오른쪽 위의 실제 경과 시간과 종료 로그를 함께 봐야 한다. 위 화면처럼 막 시작해 12초만 지난 상태와 목표 시간을 끝까지 채운 상태는 구분해서 본다.

정상 완료 여부는 검사 이름·설정, 실제 실행 시간, 종료 로그를 함께 보고 확인한다. 예정된 시간을 채웠는지, 오류·경고가 있었는지 기록한다. 계획한 검사를 끝내도 증상이 나타나지 않았다면 원래 문제를 일으키던 게임이나 작업에서 같은 조건을 다시 확인한다. 완료 화면의 검사 이름이 Benchmark였다면 안정성 검사 결과와 구분한다.

계산 오류·WHEA·온도 경고가 나타났다면

공식 실행 문서는 초록 체크를 미검출, 노란 표시를 경고, 빨간 표시를 계산 오류나 검사 프로세스 비정상 종료로 설명한다. 색만으로 원인을 정하지 말고 오른쪽 로그의 해당 메시지와 시각을 읽는다.

• 계산 오류: 검사에서 기대한 계산 결과와 다른 값이 나온 경우다. 검사 이름·옵션·첫 오류 시각과 메시지를 남긴다. 코어·스레드·GPU 번호가 표시된다면 함께 기록한다. CPU라면 튜닝 설정과 냉각, Memory나 CPU + RAM이라면 메모리 프로필과 구성을 비교한다. 오류가 찍힌 코어나 항목을 단서 삼아 클럭·전압·메모리 설정부터 차례로 확인한다.
• WHEA 경고: WHEA는 Windows의 하드웨어 오류 보고 체계다. 계산 오류가 0이어도 별도로 나타날 수 있다. OCCT 로그의 시각을 남기고, Windows 이벤트 뷰어의 Windows 로그 → 시스템에서 같은 시각의 WHEA-Logger 기록을 확인한다. 오류 원본·구성요소 등 표시된 세부 정보를 남긴 뒤, 직전에 바꾼 CPU·메모리 설정 등과 대조해 다음 점검을 정한다.
• 온도 경고: 설정된 온도 한계에 도달한 센서가 있는지 확인한다. 센서 이름·최고 온도·설정된 한계와 당시 클럭을 남긴다. 이때는 검사 시간을 늘리기보다 중지하고 팬·쿨러 장착·통풍·전력 설정부터 점검한다. 어느 센서가 경고에 참여하는지는 센서 선택과 경고 설정에 따라 달라진다.

직접 중지·비정상 종료·강제 재부팅을 구분한다

• Stop으로 직접 중지했다면 중지 이유와 실제 실행 시간을 적는다. ‘화면 확인 후 수동 중지’와 ‘증상이 나타나 중지’를 구분해야 다음 비교에 쓸 수 있다. 계획한 시간보다 일찍 멈춘 것을 정상 완료로 바꾸어 적지 않는다.
• 검사 프로세스가 비정상 종료됐다면 OCCT가 남긴 메시지를 저장한다. OCCT 창까지 사라졌다면 Windows 신뢰성 기록과 응용 프로그램 이벤트 로그에서 같은 시각의 충돌 기록도 확인한다. 사용 버전·드라이버·설정과 충돌 기록을 먼저 대조하고, 원인 확인 없이 같은 부하를 반복하지 않는다.
• 시스템이 강제로 재부팅됐다면 마지막으로 본 검사·시각·증상과 블루스크린 여부를 적는다. 결과 저장 단계에 도달하지 못했을 수 있으므로 보고서가 없다는 것을 오류 없음으로 읽지 않는다. 재부팅 뒤에는 Windows의 BugCheck·WHEA·Kernel-Power 기록과 덤프가 남았는지 확인한다. 전원 꺼짐이라면 뒤의 Power 설명처럼 연결·냉각·개별 부하 조건도 나눠 점검한다.

센서 표에서 볼 항목을 고른다

Monitoring 표의 Value는 현재값, Min·Max·Average는 최저·최고·평균값이다. 센서를 선택하면 그래프로 시간에 따른 변화를 볼 수 있다.

CPU 쪽은 온도·클럭·패키지 전력, GPU 쪽은 온도·클럭·전력·사용률을 함께 보면 온도가 오르는 시점과 클럭 변화의 관계를 파악하기 쉽다. 표시되는 센서 이름과 지원 항목은 장치마다 다르다.

모든 CPU·GPU를 같은 온도 기준으로 판단하지 않는다. 해당 모델의 동작 한계와 냉각 상태를 확인하고, 과열이나 전력 제한에 따라 클럭을 낮추는 스로틀링이 나타나는지도 함께 본다.

테스트 중 타는 냄새나 비정상적인 소음, 팬 정지가 보이면 즉시 중단하고 하드웨어 장착 상태부터 점검해야 한다.

전압 센서는 참고 자료다. 메인보드가 보고하는 +12V 수치를 보는 것과 파워서플라이 출력을 직접 계측하는 것은 다르다. 센서 숫자 하나로 PSU 정상·불량을 판정하지 않는다.

CPU 부하에서 오류나 재부팅이 생길 때

CPU: 연산 부하와 냉각 상태를 본다

CPU 렌더링처럼 CPU를 많이 쓰는 작업에서 오류가 생긴다면 CPU 검사를 선택할 수 있다. CPU 내부 연산에 집중하는 부하이므로, 오류뿐 아니라 온도·전력·클럭의 변화를 함께 본다.

공식 CPU 문서는 Mode Normal, Load Type Variable, Instruction Set Auto, Thread Settings Auto를 기본값으로 설명한다. 실행할 때도 각 항목이 어떻게 선택돼 있는지 확인한다.

• Mode의 Normal과 Extreme은 연산·오류 검사 방식의 차이다. 일반적인 안정성 확인은 기본값인 Normal부터 시작하면 된다.
• Load Type의 Variable은 연산에 사용하는 값을 주기적으로 바꾸고, Steady는 정해진 연산 조건을 유지한다.
• Instruction Set은 SSE·AVX·AVX2 같은 연산 명령어 방식이다. Auto로 두어도 CPU가 지원하는 명령어에 따라 전력 소모와 발열이 크게 올라간다.
• Threads는 계산에 참여하는 실행 스레드다. Auto와 고정 개수 지정, 코어를 번갈아 검사하는 Core Cycling을 구분한다. Core Cycling은 코어별 조건을 따로 살펴볼 때 쓰는 기능이다.

검사 직후 온도가 급격히 오르고 클럭이 제한된다면, 더 강한 설정으로 바꾸기보다 냉각 장착·팬 동작과 전력 설정부터 확인한다. 계산 오류가 검출되면 CPU 오버클럭(클럭을 높인 설정)·언더볼팅(전압을 낮춘 설정) 등 변경한 설정을 기록하고 기본 상태와 비교한다. 메모리 설정까지 여러 항목을 한 번에 바꾸면 무엇이 결과를 바꿨는지 알기 어렵다.

아래 영상은 CPU 검사를 눌렀을 때 대기 화면을 거쳐 실제 부하 측정이 시작되는 모습이다.

CPU + RAM: CPU와 메모리 경로를 함께 검사한다

CPU 검사만으로 원인을 좁히기 어렵거나 CPU와 메모리 설정을 함께 점검하려면 CPU + RAM을 사용할 수 있다. CPU 코어·캐시에서 CPU 내부 메모리 컨트롤러(IMC), 메모리 모듈(DIMM)로 이어지는 경로에 부하를 준다.

Data Set은 연산에 쓰는 데이터의 크기를 정하는 항목이다. 데이터 크기에 따라 캐시와 메모리를 사용하는 조건도 바뀐다. 공식 CPU + RAM 문서는 Medium·Large를 설명하고 Large를 기본값으로 제시한다. 캐시와 메모리 중 어디에 더 부하를 줄지에 따라 선택하면 된다.

예를 들어 CPU 검사에서는 문제가 없는데 CPU + RAM에서만 오류가 검출된다면, CPU가 완전히 정상이라고 결론 내리기보다 메모리 프로필·모듈 구성·IMC 등 추가된 조건을 확인한다. 반대로 두 검사에서 모두 오류가 나면 공통으로 영향을 주는 CPU 설정·냉각·전원 조건도 조사 대상이다.

Linpack 검사와 계산·검증 단계

Linpack은 행렬 연산을 반복하며 계산 결과를 검증하는 검사다. 무거운 계산 단계와 상대적으로 가벼운 검증 단계가 있어 부하와 온도가 단계에 따라 달라질 수 있다. 순간적으로 CPU 사용률이 내려갔다는 이유만으로 검사가 멈췄다고 보지는 않는다.

Memory 설정은 풀어야 할 문제의 규모에 영향을 준다. 용량을 많이 주면 한 단계가 길어지므로, RAM을 많이 할당하는 것이 무조건 유리한 검사는 아니다. 공식 Linpack 문서는 Memory 기본값을 2048MB로 안내한다. 실행할 때는 설치한 버전에 표시된 설정부터 확인한다.

CPU 검사와 다른 계산 부하를 주어 확인하고 싶을 때 사용할 수 있다. 오래된 버전에서 Linpack만 오류가 난다면 프로그램 버전도 기록한다. 참고로 17.1.4 버전 변경 내역을 보면 일부 최신 AMD CPU에서 AMD64 Linpack 오류가 잘못 검출되던 버그가 수정된 적이 있으니, 구버전을 쓰고 있다면 최신 버전에서 다시 확인해 보는 게 좋다.

XMP·EXPO 적용 뒤 멈추거나 메모리 오류가 의심될 때

Memory는 할당한 RAM 영역에 데이터를 쓰고 읽으며 오류를 확인한다. RAM만 독립적으로 떼어 검사하는 것은 아니며 CPU의 메모리 컨트롤러와 메모리 설정도 결과에 영향을 준다.

XMP·EXPO는 메모리의 속도와 타이밍 등을 묶어 적용하는 성능 프로필이다. 프로필 적용 뒤 불안정해졌다면 그 설정이 검사 결과에 미치는 영향을 비교할 수 있다. 운영체제가 사용 중인 영역까지 모두 검사하는 부팅형 메모리 검사와도 범위가 다르다.

1. Memory를 고르고, Memory 입력값의 단위를 확인한다. %는 오류 허용률이 아니라 검사에 쓸 메모리의 할당 비율이다. 공식 문서는 사용 가능한 메모리의 80%와 Threads Auto를 기본값으로 안내한다. 용량을 직접 입력할 때도 단위를 본다. 버전에 따라 단위가 MB 또는 MiB로 표시된다.
2. Legacy·Presets·Custom 중 현재 선택된 방식을 확인한다. 공식 문서상 기본 Test Type은 Legacy다. Presets는 준비된 검사 순서를 선택하는 방식이다. 처음부터 Custom을 만들어야 하는 것은 아니다.
3. 사용한 방식과 프리셋 이름, 할당량을 기록하고 시간을 정해 실행한다. 다른 프로그램이 쓸 메모리 여유도 남긴다. 운영체제가 쓸 여유 메모리를 조금 남겨 두는 편이 좋다.
4. 오류가 나면 먼저 당시의 XMP·EXPO와 메모리 튜닝 상태를 기록한다. 메모리 프로필을 해제한 조건과 비교해, 프로필 적용 여부에 따라 결과가 바뀌는지 본다.

프로필을 해제한 뒤 오류가 사라졌다면 두 설정에서 안정성이 다르다는 뜻이다. RAM 칩 자체의 불량인지, CPU IMC·BIOS·모듈 구성·슬롯과 관련된 문제인지는 추가로 확인해야 한다.

모듈을 다시 장착하거나 슬롯을 바꾸는 작업은 PC를 종료하고 전원을 분리한 뒤 메인보드 안내에 따라 진행한다. 모듈과 슬롯을 한꺼번에 바꾸지 말고, 하나씩 바꾸며 같은 검사 조건으로 비교한다.

따라 해 보기: 프로필 적용 뒤 블루스크린이 생기는 경우

예를 들어 XMP·EXPO를 켠 뒤부터 블루스크린이 떠서 메모리 쪽 안정성을 먼저 비교해 보는 순서는 다음과 같다.

1. 증상을 적는다. 프로필 적용 전후의 차이, 블루스크린의 정지 코드, BIOS 버전과 RAM 구성·설정을 기록한다. 중요한 파일을 저장하고 다른 부하 프로그램을 종료한다.
2. Stability Test → Memory를 고른다. 이전에 바꾼 설정이 남아 있을 수 있으니 현재 선택된 항목을 먼저 확인한다. 처음 비교할 구성으로는 공식 문서의 기본인 Legacy, 가용 메모리 80%, Threads Auto를 사용할 수 있다.
3. Duration을 정하고 Start를 누른다. 평소 증상이 나타나기까지 걸리는 시간을 고려해 실행 시간을 잡는다. 두 설정을 비교할 때는 검사 방식·할당량·시간을 같게 기록한다. 오류 시 중지 설정도 확인한다.
4. Memory라는 검사 이름과 로그를 확인한다. 할당량이 의도한 값인지 보고, 오류 수·WHEA 경고와 CPU·메모리 온도 센서를 살핀다. 오류나 블루스크린이 나면 해당 시점의 자료를 남기고 같은 부하를 무작정 반복하지 않는다.
5. 프로필을 해제한 조건과 비교한다. 기존 설정을 보존한 뒤 BIOS에서 XMP·EXPO만 해제하고, Windows로 돌아와 실제 메모리 설정을 확인한다. 다른 조건은 유지한 채 같은 검사를 실행해 프로필 유무에 따른 차이를 본다.
6. 결과에 따라 다음 점검을 고른다. 프로필을 켰을 때만 오류가 난다면 지원 조합·BIOS·튜닝 조건을 살펴본다. 기본 상태에서도 오류가 난다면 전원을 분리한 뒤 모듈을 하나씩 비교하고 메인보드 권장 슬롯·CPU 지원 조건도 확인한다. 필요하면 CPU + RAM으로 CPU와 메모리 경로에 다른 부하를 주어 비교한다. OCCT에서 재현되지 않으면 Windows 밖에서 실행하는 부팅형 메모리 검사도 보완 수단이 된다.

Custom으로 검사 순서를 직접 구성하려면

v17의 Memory는 16개 블록을 조합할 수 있도록 개편됐다. Custom에서 패턴을 쓰거나 옮기는 블록만 오래 실행해도 오류 검증이 되는 것은 아니다. Check 또는 오류 검사를 포함하는 All-in-one 블록이 필요하다. 직접 순서를 구성할 때는 공식 블록 구성 설명을 먼저 읽는다. 처음에는 준비된 검사 구성부터 익히면 된다.

게임 튕김·화면 깨짐은 3D Adaptive와 VRAM을 나눠 본다

3D Adaptive로 GPU 부하 변화를 검사한다

게임을 실행한 직후, 메뉴로 나갈 때, 장면이 바뀔 때만 튕긴다면 일정한 최대 부하 검사 하나로 재현되지 않을 수 있다. 3D Adaptive는 Unreal Engine 기반 렌더링 부하를 이용해 GPU를 검사하며, 일정 부하와 변화하는 부하를 선택할 수 있다.

검사할 GPU를 확인하고 부하 방식을 정한다. Steady는 일정한 강도로 실행하고, Variable은 강도를 단계적으로 올린 뒤 원래 강도로 되돌린다. Switch는 두 강도를 빠르게 전환한다. 최대 부하일 때보다 메뉴를 전환할 때 문제가 더 잘 생긴다면 부하가 달라지는 조건을 비교해 볼 수 있다.

Intensity 50%는 GPU 사용률 50%나 소비전력 50%가 아니다. 같은 강도에서도 GPU 모델과 보호 동작에 따라 사용률·전력·클럭은 다르게 나타난다. 공식 Adaptive 문서에서도 안내하듯 이 숫자는 부하 강도 단계이며, 오류 검출 옵션이 켜져 있는지도 함께 확인한다.

실행 중에는 OCCT의 계산 오류뿐 아니라 화면 깨짐·검은 화면·드라이버 재시작이 발생하는지도 기록한다. GPU 오버클럭이나 언더볼팅을 적용했다면 원래 설정을 보존한 뒤 기본 상태와 비교한다. 드라이버 재설치 등 다른 조치까지 한꺼번에 섞지 않아야 어느 변경이 영향을 줬는지 볼 수 있다.

Windows가 GPU 응답 지연을 감지해 그래픽 장치를 재설정하는 기능을 TDR이라고 한다. 화면이 잠깐 검어졌다가 돌아오고 드라이버 복구 메시지가 보일 수 있다. 이런 증상이 보이면 GPU 클럭·전압 설정과 드라이버 버전, 보조전원 연결 상태를 함께 점검해 본다.

VRAM: 그래픽 메모리에 쓰고 읽는 검사

VRAM은 GPU가 사용하는 그래픽 메모리에 데이터 패턴을 쓰고 읽어 검증하는 검사다. 3D Adaptive의 렌더링 부하와 검사 초점이 다르다. 텍스처가 깨지거나 그래픽 메모리 관련 경로가 의심될 때 추가로 선택할 수 있다.

대상 GPU와 메모리 할당량을 확인한 뒤 실행한다. 공식 문서의 기본 할당량은 사용 가능한 메모리의 80%다. 화면 출력과 실행 중인 프로그램이 이미 쓰는 그래픽 메모리가 있어 가용 영역을 기준으로 검사한다.

오류가 검출되면 GPU 메모리 클럭·튜닝 설정·온도·드라이버 등 당시 조건을 기록하고 기본 상태와 비교한다. 3D Adaptive에서는 오류가 없고 VRAM에서 오류가 난다면 그래픽 메모리 관련 경로를 더 살펴볼 이유가 생긴다.

다만 공식 VRAM 설명에 따르면 GPU 내부의 전송 오류 검출·재전송 때문에 프로그램에 드러나지 않는 전송 문제도 있다. 따라서 VRAM 검사와 3D Adaptive 결과를 함께 비교해 보는 편이 정확하다.

따라 해 보기: 게임이 튕기거나 드라이버가 재시작되는 경우

게임 메뉴와 플레이 화면을 오갈 때 자주 튕기거나 화면이 깜빡이며 그래픽 드라이버가 복구되는 상황을 점검하는 순서는 다음과 같다.

1. 재현 조건을 남긴다. 게임·드라이버 버전, 튕기는 장면과 대략적인 소요 시간, GPU 튜닝 여부를 기록한다. 같은 시각의 게임 로그·Windows 신뢰성 기록도 보존한다. GPU 설정과 드라이버를 한꺼번에 바꾸지는 않는다.
2. Stability Test → 3D Adaptive를 고른다. 장치 선택을 열어 게임에 쓰는 GPU를 확인한다. 공식 문서의 기본 동작은 Steady다. 먼저 현재 강도와 오류 검출 설정을 읽고 기록한다.
3. 증상에 맞춰 부하 방식을 정한다. 메뉴 전환처럼 부하가 바뀌는 상황을 확인하려면 Variable로 강도가 변하는 조건을 비교할 수 있다.
4. 시간을 정해 Start를 누르고 관찰한다. 조작 실습을 마쳤다면 원래 재현 시간을 포함하도록 Duration을 정하고, 정한 시간과 이유를 기록한다. 오류 표시·로그·GPU 온도와 클럭을 보고, 화면 깨짐·검은 화면·드라이버 복구가 생긴 시각도 기록한다.
5. 결과와 종료 이유를 저장한다. 계산 오류가 나면 첫 오류와 설정을 남긴다. 오류 수는 0이어도 드라이버가 재시작됐다면 그 사건을 따로 기록한다. 이상이 없어 계획한 검사가 끝났다면 그 조건에서 미검출로 기록하고 실제 게임을 다시 확인한다.
6. 필요한 다음 검사만 고른다. 텍스처 깨짐 등 그래픽 메모리 경로도 의심된다면 VRAM에서 대상 GPU와 할당량을 확인해 별도로 비교한다. GPU 튜닝 상태에서만 재현되면 기본 상태와, 특정 드라이버에서만 생기면 다른 드라이버 버전과 한 항목씩 비교한다. OCCT는 정상인데 특정 게임만 계속 튕기면 게임 파일·오버레이·게임 로그 쪽으로 점검을 이어간다.

CPU와 GPU를 함께 쓸 때만 전원이 꺼진다면

Power는 CPU와 GPU에 동시에 높은 부하를 주는 검사로, 시스템 전체 소비전력과 발열이 가장 크게 올라간다.

예를 들어 CPU 작업만 할 때와 GPU 작업만 할 때는 문제가 없는데 둘을 함께 쓰면 꺼진다면, 연결·냉각 상태와 개별 검사 결과를 확인한 뒤 Power로 그 조건을 비교할 수 있다. 특정 게임 하나가 튕긴다는 이유만으로 Power부터 오래 돌릴 필요는 없다.

검사 중에는 CPU·GPU 온도와 시스템 반응을 지켜본다. 꺼짐이나 재부팅이 재현되면 반복해서 같은 고부하를 걸기보다 당시 조건을 남기고 전원 케이블·커넥터, 파워 용량과 상태, 메인보드 전원부, 냉각 등을 나눠 점검한다. CPU·GPU 튜닝도 함께 영향을 줄 수 있다. PSU 내부를 열거나 익숙하지 않은 활선 계측으로 이어가지 않는다.

재부팅 뒤 Windows에 Kernel-Power 41이 남을 수 있다. Microsoft 설명에 따르면 이 이벤트는 정상 종료되지 않았음을 기록하며, 그 자체로 전원 공급 중단과 블루스크린 등 원인을 모두 구별해 주지는 않는다. Power에서 꺼졌다는 사실만으로 PSU 불량을 확정할 수는 없으므로 추가 점검이 필요하다.

Storage·Combined·Monitoring Only는 언제 쓰나

Storage는 저장장치에 작업 부하를 주는 검사이며, SMART 건강 정보만 읽는 기능과 다르다. 대상 경로와 시험 파일 크기 등 현재 버전의 설정을 확인해야 한다. 저장장치가 사라지거나 읽기 오류가 생기는 PC에 중요한 데이터가 남아 있다면, 고부하 검사보다 데이터 보존과 연결 상태·제조사 진단이 먼저다. Storage Benchmark 역시 저장장치 안정성 검사와 구분한다.

Combined는 여러 검사를 동시에 실행한다. 예를 들어 Memory와 3D Adaptive를 묶으면 함께 부하가 걸리는 조건을 만들 수 있다. 반면 CPU와 Memory를 무작정 동시에 켜면 자원을 서로 차지해 검사 조건이 달라진다. 개별 부하에서 문제가 없는지 확인한 뒤, 실제 증상과 비슷한 조합이 필요한 경우에 선택한다.

Monitoring Only는 OCCT 자체의 추가 연산 부하 없이 센서를 관찰할 때 쓸 수 있다. 실제 게임을 실행하면서 온도와 클럭이 어떻게 변하는지 보고 싶을 때도 이런 관찰이 도움이 된다. 고급 외부 프로그램 연동 모드도 있으므로, 단순 센서 관찰과 외부 테스트를 실행하도록 설정한 상태는 구분한다.

이 밖에 버전·에디션에 따라 기존 3D나 GPU Compute 같은 메뉴가 보일 수 있다. 기존 3D의 설정을 3D Adaptive에 그대로 적용하면 안 된다. GPU Compute는 현재 공식 Pro 안내에서 Enterprise+ 전용으로 구분한다.

검사 완료 화면에서 확인할 항목

결과를 캡처할 때는 검사 이름·설정·실제 실행 시간·종료 이유도 함께 남긴다. 시작 직후 수동으로 멈춘 검사와 설정한 시간을 모두 실행한 검사는 구분해서 기록한다.

로그와 보고서를 저장한다

결과 창을 닫기 전에 오른쪽 로그 영역 위쪽의 복사 아이콘(겹친 종이 모양)을 누르면 실행 로그를 텍스트로 복사해 둘 수 있다.

공식 실행 문서에 따르면 검사가 끝나거나 Stop으로 멈춘 뒤 실행 화면에 Save report가 나타난다. 보고서 기능을 이용할 수 있는 에디션이라면 이를 눌러 저장한다.

보고서 파일을 저장했다면 파일이 정상적으로 열리는지 확인하고, Go Back을 눌러 설정 화면으로 돌아가기 전에 로그와 캡처를 먼저 챙겨 둔다.

문서에 안내된 형식은 Personal 계열 PNG, Pro PNG·CSV, Enterprise HTML·CSV·JSON이다. PNG는 화면으로 결과를 남길 때, CSV는 센서값을 표나 그래프로 비교할 때 쓰기 좋다.

Enterprise의 HTML은 브라우저에서 열어 보는 보고서, JSON은 검사 정보를 프로그램에서 읽어 처리할 때 사용하는 형식이다. Enterprise의 세부 용도는 공식 에디션 안내에서도 확인할 수 있다.

다만 무료 버전에서는 보고서 파일 저장 기능이 제한될 수 있다는 점은 참고해야 한다. 현재 Personal 기능 안내는 Test Reports를 Supporter·Supporter+ 혜택으로 설명한다. 무료판에서 저장 버튼이 없거나 라이선스 안내가 나온다면 결과 화면 캡처와 로그 복사로 기록을 남긴다.

저장한 결과에서는 OCCT 버전·검사 이름·설정·실제 시간·종료 이유·오류/경고·센서 변화를 확인한다. 보고서에 없는 항목은 별도 메모로 보완한다. 파일 이름도 검사와 설정을 구분할 수 있게 붙이면 나중에 프로필 적용 전후를 찾기 쉽다. 외부에 공유하기 전에는 시스템 이름·식별 정보 등 공개할 필요 없는 내용이 포함됐는지도 살핀다.

OCCT에서는 정상인데 실제 게임에서는 계속 문제가 난다면

먼저 OCCT와 실제 작업의 조건을 비교한다. 검사한 GPU가 맞는지, 게임에서 문제가 생기기까지 걸리는 시간이 검사 시간보다 긴지, 일정 부하만 시험하고 부하 전환은 보지 않았는지 살펴본다. 검사에서 드러나지 않은 드라이버·게임·운영체제·저장장치 문제일 수도 있다.

특정 게임에서만 문제가 생기면 같은 시각의 Windows 신뢰성 기록과 이벤트 로그, 게임 로그를 확인한다. 게임 파일 검사, 드라이버 버전 비교, 오버레이나 튜닝 프로그램의 개입 여부 등을 하나씩 바꾸어 재현 조건을 비교할 수 있다. 그래픽 문제가 의심되더라도 CPU 인코딩·압축 같은 다른 작업에서도 오류가 나는지 확인하면 조사 범위를 나누는 데 도움이 된다.

검사 결과를 다음 점검에 활용하려면 어떤 조건에서 문제가 나타났고, 어떤 조건에서는 나타나지 않았는지를 기록해 둔다.