친구에게 만든 게임을 건넸습니다. 내 컴퓨터에서는 캐릭터가 잘 달렸는데, 친구 컴퓨터에서는 느리게 움직입니다. 그래픽 설정을 낮추자 이번에는 달리는 속도까지 빨라집니다.
“프레임이 올라가면 게임도 빨라지는 게 맞는 건가?”
이 질문에는 서로 다른 두 가지가 섞여 있습니다. 게임 속 시간이 얼마나 흐르는가, 그리고 그 시간을 화면으로 얼마나 자주 보여주는가입니다. 이 둘을 구분하면 FPS부터 프레임 생성까지 한 흐름으로 이해할 수 있습니다.
달리는 캐릭터도 멈춰 보면 한 장의 그림이다
애니메이션의 한 장면을 멈추듯 게임을 멈춰봅시다. 캐릭터도, 배경도, 효과도 그 순간에는 한 장의 이미지입니다. 이런 한 장을 프레임이라고 부릅니다. 조금씩 다른 프레임을 시간에 맞춰 보여주면 움직이는 화면을 보게 됩니다.
FPS는 Frames Per Second, 즉 초당 프레임 수를 뜻합니다. 단, 어떤 단계를 세는지 함께 봐야 합니다. 게임이 직접 그린 프레임 수인지, 생성 프레임까지 포함해 화면으로 내보낸 수인지에 따라 같은 숫자도 의미가 달라질 수 있습니다. 우선은 프레임 생성이 없는 단순한 경우부터 생각합시다.
캐릭터가 정확히 1초 동안 6미터를 달립니다. 30 FPS라면 그 움직임을 약 30번, 60 FPS라면 약 60번의 간격으로 보여줄 수 있습니다. 일정한 속도와 간격을 가정하면 한 번에 보이는 위치 변화는 각각 약 20센티미터와 10센티미터입니다. 둘 다 1초 뒤에는 같은 곳에 도착합니다.
그림 1 · 원본 01:10. 같은 시간·같은 거리를 30 FPS와 60 FPS로 표현한 자체 제작 비교. 차이는 이동 속도가 아니라 시간 사이를 보여주는 촘촘함입니다. 정지된 캡처로 부드러움 자체를 체험할 수는 없지만, 본문의 거리 계산으로 표본 간격의 차이를 이해할 수 있습니다.
프레임이 높아지면 캐릭터가 두 배 빨리 달려야 하는 것은 아닙니다. 같은 달리기를 더 촘촘하게 보여줄 수 있는 것입니다. 이 원칙을 구현에서 놓치면 친구 컴퓨터에서 생긴 문제가 나타납니다.
1초를 잘게 나눌수록 한 장에 쓸 시간은 줄어든다
1초는 1,000밀리초입니다. 1초에 60장을 일정하게 보여주려면, 새 프레임을 약 16.67밀리초마다 준비하는 흐름이 필요합니다. 30장이면 약 33.33밀리초, 120장이면 약 8.33밀리초입니다.
그림 2 · 원본 01:32. 목표 FPS별 시간 간격. 30 → 약 33.33ms, 60 → 약 16.67ms, 120 → 약 8.33ms. 높은 FPS는 더 많은 시간을 주는 설정이 아니라 더 짧은 간격으로 일을 마쳐야 하는 목표입니다.
이를 프레임 예산이라고 생각할 수 있습니다. 게임은 입력을 처리하고, 캐릭터와 적을 움직이고, 충돌을 확인하고, 화면을 그립니다. 조명과 그림자, 반사 같은 효과에도 계산이 들어갑니다. CPU와 GPU의 작업은 겹쳐 진행되기도 하므로 모든 시간을 단순히 더하는 것만으로 전체를 설명할 수는 없습니다. 그래도 목표 간격을 어느 단계가 넘는지 확인해야 한다는 원리는 같습니다.
60 FPS를 목표로 하는데 어떤 장면의 중요한 처리 단계에 25밀리초가 걸린다면, 그 상태로 매번 16.67밀리초 간격을 지키기는 어렵습니다. 프레임 예산은 “이 정도 그래픽이면 괜찮겠지”라는 감각을 측정할 질문으로 바꿔줍니다. 어디에 시간이 많이 드는지부터 봐야 합니다.
평균은 괜찮은데 왜 덜컥거릴까
기차가 평균 시속 60킬로미터로 달린다고 해봅시다. 일정하게 60으로 가는 기차와, 멈췄다가 급히 달리기를 반복해 평균 60을 맞춘 기차는 승차감이 다를 것입니다. 프레임도 비슷합니다.
프레임 타임은 프레임 한 장의 처리 시간이나 프레임 사이 간격을 살펴보는 지표입니다. 16밀리초 근처로 이어지던 그래프가 갑자기 70밀리초로 솟으면, 플레이어에게는 잠깐 멈칫한 것처럼 느껴질 수 있습니다. 일정 기간의 평균 FPS 하나로는 그 순간이 잘 보이지 않을 수 있습니다.
그래서 적이 많이 등장하는 장면, 새 구역을 불러오는 순간, 이펙트가 겹치는 때의 프레임 타임도 봅니다. 성능을 고칠 때는 똑같은 장면과 조건에서 바꾸기 전후를 비교해야 합니다. 빈 방에서 나온 높은 수치가 실제 전투를 대신해주지는 않습니다.
화면이 늦어져도 게임 속 1초는 1초여야 한다
처음의 버그를 다시 봅시다. 개발자가 화면 한 장을 그릴 때마다 캐릭터를 1만큼 이동시켰다면, 30번 그린 컴퓨터에서는 30만큼, 60번 그린 컴퓨터에서는 60만큼 이동합니다. 이동 속도를 초가 아니라 화면 횟수에 묶어버린 것입니다.
이번에는 속도를 초당 6미터로 정하고, 지난 시간을 곱합니다. 약 1/30초가 흘렀다면 0.2미터, 약 1/60초가 흘렀다면 0.1미터를 움직입니다. 1초 동안의 이동량을 모으면 둘 다 약 6미터가 됩니다. 이때 사용하는 시간 간격을 흔히 deltaTime이라고 부릅니다. Unity의 시간 간격 설명도 이 개념을 다룹니다.
그림 3 · 원본 02:15. 프레임마다 고정 거리를 더하는 방식과 속도에 지난 시간을 곱하는 방식을 비교합니다. 핵심은 ‘한 번에 얼마’에서 ‘1초에 얼마’로 기준을 옮기는 것입니다.
이번에 이동할 거리 = 초당 속도 × 지난 시간
새 위치 = 현재 위치 + 이번에 이동할 거리
Plain Text
복사
이것만으로 모든 물리 문제가 해결되는 것은 아닙니다. 한 번에 너무 큰 시간 간격을 적용하면 충돌이나 시뮬레이션이 불안정해질 수 있습니다. 그래서 물리 계산을 고정된 시간 간격으로 여러 번 진행하고, 화면은 별도 속도로 그리는 구조도 사용합니다. 화면 갱신과 게임 세계의 계산이 반드시 일대일일 필요는 없습니다.
과거 지역별 TV 규격에 맞춘 일부 게임에서 50Hz와 60Hz 환경의 속도가 달랐던 사례도 이런 결합을 이해하는 데 도움이 됩니다. 다만 모든 옛 게임이 같은 방식으로 동작했던 것은 아닙니다. 게임 시간과 표시 주기를 어떻게 연결하고 보정했는지가 차이를 만듭니다.
모니터의 Hz와 게임의 FPS는 각자 다른 일을 센다
FPS가 프레임의 빈도를 말한다면, Hz는 이 문맥에서 모니터가 화면을 갱신하는 빈도입니다. 120Hz 모니터를 연결했다고 게임이 자동으로 120개의 새 장면을 계산하는 것은 아닙니다. 반대로 게임이 빠르게 그려도 모니터의 표시 능력과 동기화 방식에 따라 눈에 전달되는 결과가 달라집니다.
게임의 품질 모드와 성능 모드도 같은 예산을 어디에 쓸지 고르는 선택으로 볼 수 있습니다. 더 높은 해상도나 복잡한 효과에 시간을 쓸지, 더 자주 화면을 갱신하는 데 쓸지의 문제입니다. 실제 목표 FPS와 해상도는 게임과 기기에 따라 다르므로 ‘품질은 무조건 30, 성능은 무조건 60’으로 외우지는 맙시다.
4K UHD 화면은 3,840 × 2,160, 약 829만 픽셀입니다. 해상도가 높아지면 많은 그래픽 작업의 부담이 커질 수 있습니다. 다만 전체 비용이 언제나 픽셀 수와 정확히 비례하는 것은 아닙니다. 장면의 복잡도와 사용한 효과, CPU 쪽 작업도 함께 영향을 줍니다.
적게 그려 크게 만드는 일과, 사이 장면을 만드는 일
여기서 화면 재구성 기술이 등장합니다. 낮은 내부 해상도로 그린 정보를 활용해 더 높은 출력 해상도의 이미지를 만드는 방식이 있습니다. DLSS Super Resolution은 여러 낮은 해상도 이미지와 움직임 정보, 이전 프레임 정보를 활용합니다. 초점은 한 장의 픽셀을 재구성하는 데 있습니다. NVIDIA의 기술 구분
그림 4 · 원본 04:38. 낮은 내부 해상도의 정보를 높은 출력 해상도로 재구성하는 도식. 원래 화면을 단순히 크게 늘리는 것과는 다르며, 새 시간의 프레임을 끼워 넣는 기술과도 구분합니다.
프레임 생성은 다른 축의 작업입니다. 이미 렌더링한 장면과 움직임 정보를 바탕으로 추가 화면을 만들어 표시 흐름에 넣습니다. 영상 도식의 R은 직접 렌더링한 화면이고, G는 생성한 화면입니다.
그림 5 · 원본 05:07. 위쪽은 직접 렌더 프레임 R의 흐름, 아래쪽은 그 사이에 생성 프레임 G를 더하는 과정입니다. 생성 화면이 늘어났다는 사실과 게임 세계를 새 입력으로 계산한 횟수가 늘었다는 사실은 서로 다릅니다.
DLSS 4는 Multi Frame Generation을 도입했고, DLSS 4.5에서는 생성 배율을 동적으로 조절하는 방식으로 확장되었습니다. 구체적인 생성 수와 지원 범위는 버전·기기·게임에 따라 달라집니다. 처음 공부할 때는 특정 배수를 외우기보다, 픽셀 재구성과 추가 프레임 생성이 서로 무엇을 바꾸는지 구분하는 편이 좋습니다. NVIDIA 공식 설명, 2026-09-17 확인
숫자가 커졌다고 손끝의 반응까지 같은 비율로 빨라지지는 않는다
버튼을 누르는 순간부터 그 결과가 화면에 보일 때까지 시간이 걸립니다. 입력을 읽고, 게임 상태를 계산하고, 화면을 그리고, 표시 장치에 전달하는 과정을 거칩니다. 이를 살펴보는 값이 입력 지연입니다.
그림 6 · 원본 06:20. 직접 렌더링한 빈도, 생성 프레임을 포함한 표시 빈도, 버튼에서 화면까지의 지연을 세 칸으로 나눴습니다. FPS는 횟수의 빈도이고 입력 지연은 걸린 시간이므로 같은 지표가 아닙니다.
생성 프레임은 움직임을 더 촘촘하게 보이도록 도울 수 있지만, 그 프레임마다 새로운 입력을 받아 게임 세계를 계산한 것은 아닙니다. 표시 FPS가 두 배가 되었다고 입력 지연이 절반이 되었다고 계산할 수는 없습니다. 반응성을 판단하려면 기본 렌더 속도와 지연을 따로 확인해야 합니다.
친구의 컴퓨터로 돌아가 봅시다. 먼저 이동이 실제 시간에 맞춰 계산되는지 확인합니다. 그다음 같은 장면에서 프레임 타임을 봅니다. 프레임 생성이 켜져 있다면 직접 렌더한 수치와 표시 수치를 구분합니다. 이제 “느려요”라는 한마디를 여러 구체적인 문제로 나눌 수 있습니다.
오늘 해볼 작은 실험
초당 일정한 속도로 달리는 캐릭터를 만들고 목표 프레임을 30과 60으로 바꿔봅시다. 같은 시간 뒤에 같은 위치에 도착하는지 확인합니다. 위치는 같아도 중간 움직임의 촘촘함은 달라질 수 있습니다.
다음에는 적이나 효과를 조금 늘리고 프레임 타임을 기록합니다. 평균 숫자만 보지 말고 갑자기 긴 프레임이 생기는 구간을 찾습니다. 마지막으로 그 구간에서 입력·게임 계산·그리기 중 어디에 시간이 걸리는지 추적합니다. 프레임을 이해한다는 것은 높은 숫자를 고르는 데서 그치지 않고, 플레이어에게 전달되는 시간의 흐름을 설명할 수 있다는 뜻입니다.
자료와 그림
얌얌코딩 「게임 FPS란 무엇일까? — 30·60·120 FPS부터 DLSS 프레임 생성까지」의 실제 7분 25.7초 영상과 대본을 문서로 재구성했습니다. 모든 그림은 해당 영상의 자체 제작 설명 화면이며, 제조사의 성능 측정 그래프가 아닙니다. 캡처 시간은 실제 영상 기준으로 기록했습니다.