초당 144프레임을 그려도 느린 이유 — Tonsky가 파헤친 '완벽한 프레임 타이밍'의 비밀

요즘 모니터는 144Hz, 240Hz가 흔합니다. CPU는 옛날보다 수십 배 빨라졌고요. 그런데도 텍스트 에디터에 글자를 칠 때, 마우스를 움직일 때 묘하게 굼뜬 느낌을 받은 적 없으신가요. 개발자 Nikita Prokopov, 닉네임 Tonsky가 이 답답함의 정체를 끈질기게 파헤쳤습니다. 핵심은 프레임을 몇 개 그리느냐가 아니라, 언제 그리느냐였습니다.

참고로 이번 주제는 최근 30일 커뮤니티 데이터가 거의 없어, 원문 분석과 그동안 쌓인 논의를 토대로 재구성했다는 점을 먼저 밝혀둡니다.

프레임이 빨라도 느린 게 말이 되나요

먼저 직관과 어긋나는 사실부터 짚겠습니다. 초당 프레임 수, 즉 FPS가 높다고 반응이 빠른 건 아닙니다. FPS는 처리량이고, 우리가 체감하는 건 지연입니다. 둘은 다른 이야기입니다.

비유하자면 이렇습니다. 1분에 60대씩 버스가 출발하는 정류장이 있어요. 배차는 촘촘합니다. 그런데 내가 정류장에 도착한 직후 막 버스가 떠났다면, 다음 차까지 또 기다려야 합니다. 버스가 자주 와도 내 대기 시간은 들쭉날쭉한 거죠.

화면도 똑같습니다. 모니터는 정해진 주기로 프레임을 내보냅니다. 내 키 입력이 그 주기에 살짝 못 미쳐 도착하면, 다음 프레임까지 통째로 기다렸다가 그려집니다. 프레임을 아무리 많이 그려도 이 기다림 자체는 사라지지 않습니다.

Tonsky가 던진 질문: 입력은 언제 읽히는가

Tonsky가 집요하게 파고든 지점이 바로 여기입니다. 키를 누른 순간과 그 결과가 화면에 박히는 순간 사이에는 생각보다 긴 여정이 숨어 있습니다.

대략 이런 단계를 거칩니다. 키보드가 신호를 보내고, 운영체제가 이벤트로 만들고, 앱이 그 이벤트를 읽고, 화면을 다시 그리고, 모니터가 그 결과를 표시합니다. 각 단계가 자기만의 주기를 갖고 있습니다. 문제는 이 주기들이 서로 딱 맞아떨어지지 않는다는 데 있습니다.

가장 흔한 손실 구간이 입력과 렌더링 사이입니다. 앱은 보통 프레임을 그리기 직전에 한 번 입력을 모아서 읽습니다. 만약 키 입력이 그 ‘읽는 순간’ 바로 다음에 도착하면, 이번 프레임에는 못 타고 한 프레임을 통째로 흘려보냅니다. 60Hz 화면이라면 한 프레임이 약 16.7밀리초입니다. 운이 나쁘면 이 시간이 그냥 버려지는 거죠.

‘완벽한 프레임’이란 무엇인가

여기서 ‘Every Frame Perfect’, 즉 모든 프레임을 완벽하게라는 표현이 나옵니다. 이 말은 단순히 프레임을 안 끊기게 그리자는 뜻이 아닙니다. 입력을 가능한 한 늦게, 화면을 그리기 직전에 읽자는 발상에 가깝습니다.

언뜻 거꾸로 들립니다. 늦게 읽는 게 어떻게 빠른 걸까요. 핵심은 ‘최신성’입니다. 프레임을 그리기 직전에 입력을 읽으면, 그 프레임에는 가장 따끈한 입력이 반영됩니다. 반대로 프레임 맨 앞에서 미리 읽어두면, 그리는 동안 들어온 입력은 또 한 박자 밀립니다.

게임 개발자들은 이 원리를 오래전부터 알고 있었습니다. 입력을 늦게 샘플링해 지연을 줄이는 기법이죠. 그런데 Tonsky가 지적한 건, 일반 앱들은 이런 고민을 거의 하지 않는다는 점입니다. 텍스트 에디터, 브라우저, 채팅 앱 같은 평범한 소프트웨어 말입니다. 그래서 사양은 좋아졌는데 체감 반응성은 옛날 컴퓨터만 못한 역설이 벌어집니다.

옛날 컴퓨터가 더 빨랐다는 불편한 진실

실제로 입력 지연을 측정해보면 충격적인 결과가 나옵니다. 수십 년 전 단순한 기계들이 요즘 최신 기기보다 키 반응이 빠른 경우가 적지 않습니다. 화면도 단색, CPU도 굼떴는데 말이죠.

이유는 복잡도에 있습니다. 옛날 기계는 키를 누르면 거의 곧장 화면에 글자가 찍히는 단순한 경로였습니다. 지금은 그 사이에 합성기, GPU 가속, 이중 버퍼링, 운영체제의 이벤트 큐, 각종 추상화 계층이 겹겹이 쌓여 있습니다. 화면은 화려해졌지만, 키 입력이 통과해야 할 관문이 그만큼 늘어난 셈입니다.

Tonsky의 논점이 날카로운 건, 이게 물리 법칙의 한계가 아니라 설계의 선택이라는 점을 짚었기 때문입니다. 하드웨어가 느려서가 아니라, 우리가 지연을 신경 쓰지 않고 시스템을 쌓아 올렸기 때문에 느린 겁니다. 마음먹고 타이밍을 맞추면 지금 하드웨어로도 훨씬 빠르게 만들 수 있다는 뜻이기도 합니다.

그래서 우리는 무엇을 할 수 있나

평범한 사용자가 당장 코드를 고칠 수는 없습니다. 하지만 이 관점은 우리가 소프트웨어를 보는 눈을 바꿔줍니다.

첫째, FPS 숫자에 속지 않는 것입니다. 240Hz 모니터를 샀는데도 답답하다면, 문제는 화면이 아니라 입력이 처리되는 타이밍일 수 있습니다. 둘째, 도구를 고를 때 반응성을 하나의 기준으로 삼는 것입니다. 화려한 기능보다 키 입력이 손에 착 붙는 느낌이 생산성에는 더 크게 작용합니다. 실제로 많은 개발자가 가벼운 에디터를 고집하는 이유가 여기 있습니다.

만드는 쪽이라면 메시지는 더 분명합니다. 입력을 늦게 읽고, 프레임 직전에 반영하라는 것입니다. 한 프레임을 흘려보내지 않는 작은 정렬이, 사용자에게는 ‘뭔가 빠르다’는 인상으로 돌아옵니다.

결국 Tonsky가 말하려는 건 하나입니다. 빠름은 처리량이 아니라 타이밍의 문제라는 것. 여러분이 매일 쓰는 도구 중에 유난히 ‘손에 붙는’ 것과 ‘한 박자 느린’ 것이 있다면, 그 차이는 어쩌면 흘려보낸 단 한 프레임에서 시작됐을지도 모릅니다. 오늘 쓰는 앱들, 한번 그 눈으로 다시 느껴보시겠어요.