프레임률이 높은데도 게임이 끊기는 이유

게임에 초당 90프레임 이상이 표시되는데도 시점을 돌리거나 새 구역에 들어가면 잠깐 멈출 수 있습니다. 평균 FPS가 쓸모없어진 것은 아닙니다. 평균은 해당 구간에서 프레임이 얼마나 많이 만들어졌는지라는 대략적인 질문에 답합니다. 프레임이 일정한 간격으로 도착하는지는 각각의 시간을 살펴봐야 알 수 있습니다.

프레임 타임부터 확인한 뒤 무엇을 더 측정할지 결정하세요. 병목 비율 하나나 GPU 사용률이 한 번 떨어진 현상만으로 교체할 부품을 판단할 수는 없습니다.

괜찮은 평균 뒤에 긴 프레임이 숨을 수 있습니다

출력이 이상적으로 균일하다면 밀리초 단위 프레임 간격은 대략 1,000 ÷ FPS입니다. 따라서 60 FPS는 약 16.67 ms, 120 FPS는 약 8.33 ms에 해당합니다. 이는 시간 환산이며 컴퓨터 벤치마크 결과가 아닙니다.

100프레임을 기록했다고 가정해 보겠습니다. 99프레임은 각각 10 ms, 한 프레임은 100 ms라면 총시간은 99 × 10 + 100 = 1,090 ms입니다. 총프레임 수를 총시간으로 나누면 약 91.74 FPS가 나옵니다. 평균은 괜찮아 보여도 한 번의 대기는 훨씬 깁니다.

그림: 가상 프레임 타임 계산과 확인 절차입니다. 실제 게임 벤치마크 화면이 아닙니다.

프레임별 순간 FPS의 산술평균도 총프레임 수를 총시간으로 나눈 값과 다릅니다. 표본 구간, 로딩 화면 포함 여부, 도구의 통계 정의에 따라서도 최종 수치는 달라집니다.

느린 프레임이 차지하는 시간도 유용한 지표입니다. 가상의 60초 기록에 100 ms 프레임이 여섯 개 있다면, 이 프레임만으로 0.6초, 즉 구간의 1%를 차지합니다. 이 역시 가상 계산이지만 백분위수에서 빠질 수 있는 드문 멈춤을 남겨 줍니다.

그림: 가상 프레임 100개입니다. 가로축은 같은 간격의 시간이 아니라 프레임 번호입니다. 50번째 프레임은 100 ms, 나머지 99개는 각각 10 ms입니다.

어떤 프레임을 기록했는지부터 확인하세요

NVIDIA의 FrameView 공식 페이지는 프레임률, 프레임 타임, 전력 측정과 로그 저장 기능을 설명합니다.[1] 로그는 사건 전후의 데이터를 보존하지만, 기록 도구만으로 CPU 병목을 입증할 수는 없습니다.

보고서를 비교하기 전에 렌더링된 프레임과 표시된 프레임, 프레임 생성, 수직 동기화, FPS 제한을 확인하세요. 생성 프레임과 기본 렌더링 프레임을 섞으면 입력 반응이 같은 비율로 개선되지 않아도 숫자는 커질 수 있습니다. 표시 경로의 문제는 렌더링 로그 밖에 있을 수도 있으므로, 매끄러운 로그만으로 눈에 보이는 모든 끊김을 배제할 수는 없습니다.

‘1% low’는 느린 프레임 성능을 살피는 데 도움이 되지만 소프트웨어마다 계산법이 다를 수 있습니다. 수치와 함께 도구 이름, 버전, 지표 정의, 기록 시간을 남기세요. 가장 느린 단일 프레임이라고 가정하거나 서로 다른 도구의 수치를 섞어 순위를 매기지 마세요.

CapFrameX는 프레임을 순서대로 정렬한 백분위수와 실제 경과 시간을 명확히 구분합니다.[3] 느린 프레임 몇 개가 상당한 시간을 차지할 수 있으므로 ‘프레임의 99%가 기준을 충족한다’를 곧바로 ‘플레이 시간의 99%가 부드럽다’로 바꿀 수 없습니다. 백분위수 값과 가장 느린 일정 비율을 집계한 값의 차이도 설명합니다. 보고서가 계산법 없이 ‘1% low’라고만 적었다면 그 한계를 유지해서 해석해야 합니다.

어떤 로그 필드를 함께 읽어야 할까요?

CSV를 열고 먼저 열 이름을 확인하세요. PresentMon 콘솔 문서는 다음 필드를 정의하며, 실제 출력은 버전과 캡처 옵션에 따라 달라집니다.[2]

이 필드들은 서로 다른 구간을 나타내며 CPU와 GPU 작업은 겹칠 수 있습니다. 열을 단순히 더한 값이 전체 프레임 시간과 같아야 한다고 생각하지 마세요. MsGPUBusy는 작업 관리자의 GPU 사용률이 아닙니다. 두 수치를 비교할 수 있는지는 정의를 읽고 판단해야 합니다.

제출 간격이 길어지고 GPU의 실제 작업 시간도 크게 늘어난다면 그래픽 작업을 조사할 필요가 있습니다. GPU 작업은 짧지만 대기가 길다면 FPS 제한, CPU의 작업 공급, 스케줄링 등이 관여할 수 있습니다. 후자는 조사 범위를 좁혀 줄 뿐 CPU 성능 부족을 확정하지 않습니다. 프로젝트는 API와 하드웨어 스케줄링에 따른 제약도 설명합니다. 누락되거나 측정에 제약이 있는 필드는 그대로 취급하세요.[4]

반복 가능한 짧은 경로로 증거를 남기세요

반복할 수 있는 경로를 정하고 해상도, 그래픽 설정, 카메라 움직임, FPS 제한을 고정하세요. 원래 설정을 저장하고 기록을 시작한 뒤 결과 파일을 보관합니다. 나중에 비교할 수 있도록 파일에 게임 버전, 그래픽 드라이버, 장면, 설정을 표시하세요.

각 급등이 첫 진입 때인지, 갑자기 시점을 돌릴 때인지, 백그라운드 프로그램이 시작할 때인지, 같은 장소를 지날 때마다 생기는지 기록합니다. 확보한 CPU, GPU, 메모리, 저장장치 지표를 함께 살펴보세요. 수집하지 않은 센서 값을 0으로 채우면 안 됩니다.

우선 세 번 반복하고 모든 결과를 보관하세요. 차이가 크다면 측정을 늘리기 전에 장면, 온도, 캐시, 백그라운드 작업을 점검합니다. 가장 좋은 결과만 남기면 설명해야 할 변동 자체를 지워 버리게 됩니다.

다음은 시작용 기록 양식입니다. 60초와 세 번 반복은 예시이며 모든 게임에 충분하다는 보장은 없습니다.

콜드 스타트와 이미 방문한 장면은 나누어 비교하세요. 최초 로딩의 끊김은 별도 기록할 가치가 있습니다. 지속적인 그래픽 부하를 볼 때 한쪽은 첫 로딩, 다른 쪽은 준비된 캐시 상태의 데이터를 사용하면 안 됩니다.

PresentMon은 이름으로 프로세스를 선택하고, 캡처 시간을 정하고, CSV 출력 파일을 지정할 수 있습니다.[2] GUI나 명령줄 어느 쪽이든 대상 프로세스를 확인해 런처와 게임 프레임이 섞이지 않도록 하세요. 이 글에서는 실제 게임 캡처를 수행하지 않았으며, 이미지는 지표 설명용입니다.

한 번에 조건 하나만 바꾸세요

그래픽 부하가 의심된다면 특정 렌더링 부담 하나를 줄이고 같은 경로를 반복하세요. 백그라운드 간섭이 의심된다면 확인된 프로그램 하나를 닫고 다시 측정합니다. 드라이버, 그래픽 품질, FPS 제한을 동시에 바꾸고 게임까지 재시작하면 무엇이 개선을 만들었는지 알기 어렵습니다.

품질을 낮춰 평균 FPS는 올랐지만 같은 위치의 급등이 남는다면 평균 렌더링 부하와 그 멈춤은 서로 다른 문제일 수 있습니다. 첫 번째 이동에서 심하고 이후 줄어드는 끊김은 리소스 로딩이나 캐시와 관련될 수 있지만, 그 패턴만으로 원인을 특정할 수는 없습니다. 낮은 GPU 사용률은 제한, CPU 대기, 기타 제약을 반영할 수 있으며 그래픽카드 성능 부족을 직접 의미하지 않습니다.

‘PC에 30% 병목이 있다’ 대신 ‘세 번 모두 구역 진입 시 급등했고 그림자를 낮춰도 사라지지 않았다’처럼 조건이 붙은 결론을 저장하세요. 다음 측정은 추측에서 다시 시작하지 않고 해당 위치와 그림자 설정 차이를 조사할 수 있습니다.

참고 자료

1. NVIDIA FrameView 공식 페이지. 프레임률, 프레임 타임, 로그 기능의 근거입니다. 실제 테스트 수행, 모든 GPU의 동일한 전력 필드, 소프트웨어 설치를 뜻하지 않습니다.

2. PresentMon Console Application 문서. 2026-09-27에 확인한 main 브랜치입니다. CSV 필드, 대상 프로세스, 캡처 시간을 정의합니다. 필드는 버전에 따라 다르며 로컬 캡처를 뜻하지 않습니다.

3. CapFrameX: Explanation of different performance metrics. Taxxor, 2020-05-31. 백분위수와 x% low를 설명합니다. 지표 개념의 출처이며 현재 UI 스크린샷으로 사용하지 않았습니다.

4. PresentMon 프로젝트 문서와 제약. 2026-09-27 확인. API와 하드웨어 스케줄링이 측정에 영향을 줄 수 있으므로 병목을 바로 단정하지 말고 환경을 기록해야 합니다.