PC에서 30프레임으로 제한해놓고 플레이해본 사람이라면, 이렇게 느껴본 적 있을 겁니다.
"프레임 수치는 잘 고정돼있는데 왜 이리 끊기지?"
물론 대부분은 그저 프레임레이트 수치가 적어서 끊긴다고 넘어가겠죠.
하지만 저는 여기에 항상 의문을 가지고 있었습니다.
'왜 콘솔에선 같은 30프레임인데도 훨씬 더 부드럽게 느껴질까? 왜 이런 차이가 생기는 걸까?' 라고요.

결론부터 말하면, 그건 '프레임 페이싱(Frame Pacing)' 때문이었습니다.
그리고 더 구체적으로는, 콘솔은 시스템 수준에서 프레임 페이싱을 자동으로 잡아주는 API를 제공하는 반면, PC는 대부분 그걸 안 쓰고, 개발자 재량에 맡겨져 있기 때문이었습니다.

그렇다면 '프레임 페이싱'이란 대체 뭘까요?
쉽게 말해, '화면에 한 프레임이 얼마 동안 머무르냐'입니다.

예를 들어, 30프레임이라면 1초에 30장의 그림이 순서대로 화면에 표시되니까, 한 장당 정확히 33.3ms 동안 보여야 하죠.
그런데 어떤 프레임은 28ms만 머물고, 어떤 프레임은 38ms나 붙잡고 있으면 어떻게 될까요?
프레임 수치는 평균적으로 30fps가 나와도, 체감상 겁나 끊깁니다. 이게 바로 '프레임 페이싱 문제'입니다.

그렇다면 콘솔의 30프레임은 왜 더 부드러워 보일까요?
플스, 엑박, 닌텐도에는 '시스템 수준의 프레임 제한 API'를 제공합니다.
이건 OS 차원에서 프레임을 정확한 타이밍에 뿌려주는 기능인데요,
예를 들어, 플스4는 내부적으로 60Hz 주사율에 맞춰서 33.33ms 간격으로 프레임을 강제로 띄우는 시스템이 있습니다.
이걸 쓰면 개발자가 따로 복잡한 계산을 하지 않아도, 프레임 간의 간격이 정확히 일정하게 유지됩니다.
그러니 눈으로 볼 때 훨씬 더 안정적이고 일관된 느낌을 주는 거죠.

더 구체적으로 어떤 API가 있는지 설명하면,
플스에는 'sceVideoOutSetFlipRate()' 이 API가 특정 프레임 주기를 설정하는데, 예를 들어 60Hz 디스플레이에서 2를 지정하면 30fps로 고정되고, 그래서 프레임을 정확히 일정한 간격으로 출력해주는 하드웨어 수준 프레임 타이밍을 보장하며, 내부적으로는 이중/삼중 버퍼링과 VSync(수직동기화) 조합으로 처리됩니다.
엑박에는 마이크로소프트가 자체 프레임 타이밍 컨트롤 API를 제공합니다. Direct3D 계열에 통합되어 있고, 타이밍이 시스템 수준에서 강제로 조율됩니다. 대부분 UWP 기반이기 때문에 일정한 프레임 간격 보장이 쉽습니다.
닌텐도 스위치에는 '닌텐도 SDK'를 통해 제공되는 Swap Interval 설정 API가 존재합니다. 기본적으로 VSync(수직동기화) 기반으로 움직이며, 정확한 프레임 타이밍을 보장하려는 구조죠. 둠(2016)을 스위치로 이식했던 Panic Button의 인터뷰에 따르면, 이 API 위에서도 성능에 따라 페이싱 문제는 생길 수 있다고 하긴 했습니다.

PC 윈도우즈에는 DirectX 9에 'D3DPRESENT_PARAMETERS' 이런 API가 존재합니다. 'PresentationInterval' 값으로 Vsync(수직동기화)를 설정할 수 있고, 'D3DPRESENT_INTERVAL_ONE'은 한번마다 출력하여 60fps가 되고, 'D3DPRESENT_INTERVAL_TWO'는 두번마다 출력하여 30fps가 됩니다. 하지만 이것만으론 완벽한 프레임 간격 제어가 어렵습니다.
DirectX 11~12에 'DXGI_PRESENT / DXGI_SWAP_CHAIN_DESC' API가 있는데, 'SwapEffect'와 'SyncInterval'로 프레임을 제한 할 수 있습니다. 물론 이 또한 드라이버에 따라 결과가 다르고, 완전한 타이밍 제어를 보장하지 않습니다.
'Sleep()' 또는 'QueryPerformanceCounter()' 등으로 직접 타이밍을 조절할 수도 있는데, 많은 인디 게임이나 이식 게임에서 이 방식을 많이 사용합니다. 단, 타이밍 정확도가 OS 스케줄러에 따라 들쭉날쭉해지는 게 치명적인 문제입니다.
외부 툴로는 RTSS와 그래픽카드 소프트웨어가 있는데, RTSS가 현재 PC에선 가장 완벽하게 정밀한 프레임 타이밍 제어가 되는 소프트웨어입니다. RTSS를 깔고 프론트 엣지 싱크로 설정하고 프레임 제한을 하면 전혀 끊기지 않아요. 단, 그래픽카드 소프트웨어(엔비디아 제어판 등)의 자체 프레임 제한은 페이싱 품질이 랜덤에 가깝고, 정확한 간격을 거의 보장하지 않습니다.

PC 리눅스/스팀OS에는 'Gamescope frame limiter'가 있는데, 스팀덱의 프레임 제한이 이걸로 통해 구현됩니다. 실제로 매우 정밀한 프레임 간격을 유지하며, 콘솔 수준의 페이싱이 가능한 걸로 유명합니다. 단, 현재는 인풋렉을 줄이면서 살짝 타이밍 품질이 떨어졌다는 보고가 있습니다.

그럼 PC도 똑같이 하면 끊기지도 않고 눈도 편할텐데 왜 안 하는 걸까요?
여기서 문제가 하나 생깁니다. '입력 지연(Input Lag)'이요.
이 시스템 API는 삼중 버퍼링 방식이라서, 프레임을 깔끔하게 정렬해주는 대신 입력 반응이 느려집니다.
키보드나 패드 입력에 대한 반응이 한두 프레임 늦게 나올 수 있다는 뜻입니다. 물론 도파민 디톡스하는 것처럼 엄청 느려지지는 않습니다만...

그래서 많은 개발자들이 PC판에서는 이 시스템 콜을 아예 쓰지 않거나, 자체적으로 만든 프레임 제한 로직을 많이 사용합니다.
이 방법은 입력 지연은 줄이지만, 프레임 간 간격이 고르지 않기 때문에 끊김과 스터터링이 남고요.

분명 프레임 수치는 잘 고정되는데 스터터링이 느껴지는 건 왜 그럴까요?
CapFrameX나 애프터버너, RTSS 같은 툴로 프레임 타임을 확인해 보면,
프레임 수치는 잘 고정되어 있지만, 프레임 타임 그래프를 보면 요동치고 있을 겁니다.
P5/P95/P99 수치는 멀쩡해 보여도, 체감은 '이상하게 끊김'이 남아요.
이건 실제 프레임 간의 간격이 일정하지 않기 때문이고, PC에서는 그걸 OS나 드라이버가 보정해주지 않습니다.
지싱크/프리싱크는 프레임타임이 너무 심하게 요동치는 것을 살짝 보정만 해줄 뿐이지 프레임타임 자체를 안정화 시켜주지도 않고요.

물론 예외도 있습니다.
스팀덱이나 일부 PC 환경에서는 '시스템 수준의 프레임 제한'을 적용할 수 있는 API가 있습니다.
예를 들어 스팀OS에서는 'Gamescope' 수준에서 프레임을 일정하게 제한할 수 있는데,
지금은 이마저도 입력 지연을 줄이기 위해 타이밍을 느슨하게 조정한 결과, 프레임 페이싱이 다시 망가져 버렸습니다.
즉, 시스템이 제공하는 API조차도 완벽하지 않습니다.

PC의 프레임 페이싱을 위한 완벽한 해결책은 뭘까요?
콘솔: 가끔 프레임 페이싱 망가져서 끊기는 게임이 생기긴 하지만 웬만하면 그냥 알아서 잘 해주기 때문에 별로 걱정할 게 없습니다.
PC: 개발자가 진짜로 신경 써서 구현해줘야 합니다. 옵션으로 시스템 API를 쓰게 해주거나, 입력 지연을 최소화하면서도 프레임을 일정하게 유지하는 자체 로직을 매우 잘 짜야 합니다.
그렇지 않으면, 30프레임의 매끄러움이 아닌, 끊기는 30프레임의 고통만 남으니까요.
그리고 그 고통은 '왜 이리 끊기고 눈 아프지?'라는 의문으로 돌아올 거고요.

PC에서 프레임 페이싱을 위해 절반(1/2) 수직동기화를 해법으로 제시하는 분들도 많이 있는데요,
하지만 절반 수직동기화가 프레임타임 안정화 방법이 되지 못 하는 이유가 있습니다.
모니터 주사율을 60Hz로 설정하고 절반(1/2) 수직동기화를 켜면, 이론적으론 콘솔처럼 프레임 타임이 일정해야 정상입니다.
하지만 이름만 '절반'이고, 윈도우즈는 윈도우즈대로 윈도우 스케줄러가 작업 스레드를 여기저기 돌려서,
'Sleep()'이나 타이머로 대충 시간 맞추려고 하고, 다른 백그라운드 작업이 들어오면 그 시간마저도 뒤로 밀어버립니다.

그래픽 드라이버는 드라이버대로 화면에 티어링은 안 생기는데, 프레임 타임 간격은 지멋대로 튀고, 결과적으로는 체감상 더 거슬리는 끊김이 발생하는 바람에 엔비디아가 1/2 Vsync를 넣었다가 뺐어요. 라데온도 상황은 비슷하고요.

게다가 'Sleep()' 함수 자체도 또 해상도가 정밀하지 못합니다.
윈도우에서 CPU 스레드를 일정한 밀리세컨드마다 쉬게 하려고 해도 정확히 그 시간에 깨우질 못합니다.
타이머 해상도 자체가 약간 느슨한 데다가, 다른 작업이 스케줄링되면 프레임이 밀리거나 당겨져 버립니다.
물론 이는 윈도우 운영체제 자체의 구조적 한계이기도 합니다. 리눅스에서는 비교적 정확하게 맞추는 게 가능하고요.

그리고 게임 엔진도 "정확한 프레임 타이밍 주기로 화면을 그릴게!" 라고 하지 않고,
"일단 빨리빨리 그려서 화면에 보내기나 하자!"라는 구조인 PC게임 엔진이 많습니다.
이러면 절반 수직동기화가 켜져있더라도 그 타이밍에 맞춰 뿌릴 준비가 되어 있지 않죠.
결국 화면은 VSync 타이밍대로 바뀌는데, 프레임은 준비가 안 돼서 중간중간 출력 지연이 생기고,
그럼 프레임타임이 요동치는 결과가 초래됩니다.

30프레임이 나쁜 게 아닙니다.
프레임 수치가 30이라서 끊기는 게 아닙니다.
일정하지 않은 프레임타임이 문제이며, 이는 60프레임도 마찬가지고, 120프레임도 마찬가지고, 240프레임도, 480프레임도 마찬가지입니다.
콘솔은 그걸 시스템적으로 해결해주고, PC는 여전히 개발자의 철학과 의지에 달려 있습니다.

출처