프레임 생성

컴퓨터 그래픽스 게임 개발 소프트웨어 마지막 수정: 2026-08-15 04:23:47

1. 개요[편집]

프레임 생성 Frame Generation
목적	렌더하지 않은 프레임을 만들어 표시 프레임레이트를 올림
양대 방식	보간(양방향, 지연 증가) / 외삽(단방향, 지연 유지)
재료	엔진 모션 벡터 + 광학 흐름 + 깊이
대표 구현	DLSS 3 이상, FSR 3, ASW·ATW(VR)
주적	디스오클루전 홀, HUD 뭉개짐, 프레임 페이싱
오해	"fps가 두 배면 반응도 두 배" — 아니다

프레임 숫자는 두 배가 됐는데 왜 손맛은 그대로냐고 물으면, 그게 정상이라고 답해야 한다.

프레임 생성(frame generation)은 실제로 렌더된 프레임들 사이(또는 그 앞)에 렌더 파이프라인을 거치지 않은 프레임을 합성해 끼워 넣어 표시 프레임레이트를 높이는 기법이다. 새 프레임은 게임 로직을 한 번 더 돌려서 얻은 것이 아니라, 이미 있는 프레임을 화면 공간에서 움직임에 따라 워핑(warping)해 만들어낸 그림이다. 렌더 비용을 안 내고 프레임을 얻는다는 점에서 초해상도와 목적이 같지만, 초해상도가 한 프레임을 크게 만드는 공간축 조작이라면 프레임 생성은 프레임 사이를 메우는 시간축 조작이다.

이 구분이 왜 중요한지는 지연시간에서 드러난다. 초해상도는 프레임이 실제로 더 빨리 완성되므로 지연이 줄지만, 프레임 생성은 지연을 줄이지 않으며 보간 방식이라면 오히려 늘린다. “fps가 두 배가 됐는데 조작감은 그대로거나 조금 나빠졌다”는 흔한 체감은 착각이 아니라 구조적 귀결이다. 이 문서의 절반은 그 회계를 정확히 적는 데 쓴다.

2. 보간이냐 외삽이냐[편집]

시각적으로는 같아 보여도 지연 회계가 정반대인 두 갈래가 있다.

방식	필요한 입력	표시 지연	주 실패 모드
보간(interpolation)	앞뒤 두 프레임	늘어난다	없음(정보가 양쪽에 다 있음)
외삽(extrapolation)	직전 프레임(들)	늘지 않는다	새로 드러난 영역·급변 동작

보간은 프레임 $N$ 과 $N+1$ 을 모두 손에 넣은 뒤 그 중간 시각의 그림을 만든다. 양쪽 정보를 다 쓰므로 품질이 좋다. 대가는 명확한데, $N+1$ 이 완성되기 전에는 중간 프레임을 만들 수 없으므로 $N+1$ 의 표시를 미뤄야 한다. 데스크톱 게임의 DLSS 3 계열·FSR 3 계열이 전부 이쪽이다.

외삽은 과거만 보고 미래를 지어낸다. 기다릴 것이 없으니 지연이 늘지 않고, VR의 비동기 재투영처럼 최신 머리 자세를 반영해 재투영하면 체감 지연이 오히려 줄어든다. 대신 앞 물체가 비켜서며 드러나는 배경은 어느 프레임에도 존재한 적이 없어 통째로 지어내야 하고, 물체가 갑자기 멈추거나 방향을 바꾸면 예측이 그대로 틀린다. VR에서 이 방식이 표준인 이유는 화질 우위가 아니라 VR에서는 지연이 곧 멀미여서, 지연을 늘리는 선택지가 애초에 없기 때문이다.¹

3. 지연 회계 — 왜 fps는 늘고 지연은 안 주는가[편집]

보간 방식의 표시 지연 증가분을 직접 세어 보자. 렌더 간격을 $T_r$ 라 하고 렌더 프레임이 $t = 0,\ T_r,\ 2T_r,\ \dots$ 에 완성된다고 하자. 생성 프레임 $G_{0.5}$ 는 $R_0$ 과 $R_1$ 이 둘 다 있어야 만들어지므로 아무리 빨라도 $t = T_r$ 이후에 준비된다. 표시 순서는 $R_0,\ G_{0.5},\ R_1,\ G_{1.5},\ \dots$ 이고 간격은 균등하게 $T_r/2$ 여야 하므로, $G_{0.5}$ 를 $t = T_r$ 에 띄우면 $R_1$ 은 $t = 1.5\,T_r$ 에 밀린다. 즉

\Delta t_{\text{disp}} \;\approx\; \frac{T_r}{2} \;+\; t_{\text{gen}}

모든 렌더 프레임이 반 프레임씩 늦게 표시된다. 여기에 생성 자체가 잡아먹는 GPU 시간 $t_{\text{gen}}$ 때문에 $T_r$ 도 조금 늘어난다. 결과적으로 화면에 표시되는 프레임 수는 두 배가 되지만, 입력이 화면에 반영되기까지의 시간은 같거나 조금 나빠진다.

핵심은 생성 프레임에는 새 게임 상태가 없다는 것이다. 시뮬레이션 틱도, 입력 샘플링도 한 번 더 돌지 않았다. 초당 120장이 보여도 그 안에 담긴 서로 다른 세계 상태는 여전히 60개다. 그래서 프레임 생성이 실제로 개선하는 것은 스터터 감소와 유지형 잔상(sample-and-hold blur) 완화 같은 시각적 부드러움이지 반응성이 아니다. 이 둘을 fps라는 숫자 하나가 합쳐 놓은 것이 오해의 근원이다.²

그래서 상용 구현들은 프레임 생성과 지연 저감 기술을 반드시 함께 켠다. 렌더 큐를 짧게 유지해 CPU가 GPU보다 여러 프레임 앞서 달리지 못하게 막는 기법(NVIDIA Reflex, AMD Anti-Lag 계열)이 그것이고, 이쪽에서 벌어들인 지연이 프레임 생성이 까먹은 지연을 상쇄하는 구조다. 비교표에서 “프레임 생성 켜도 지연이 비슷하다”고 나오는 이유가 이것인데, 대조군이 지연 저감 없는 기본 상태인 경우가 많으니 읽을 때 조심해야 한다.

4. 어떻게 만드는가 — 워핑과 홀[편집]

생성 프레임의 재료는 두 종류의 움직임 정보다.

모션 벡터 — 엔진이 직접 출력하는 화면 공간 변위장. 카메라 변환과 물체·스켈레탈 애니메이션 변형에서 정확히 계산되므로 기하학적 움직임에 대해서는 정답에 가깝다. 문제는 그림자, 반사, 굴절, 파티클, 반투명, UI, 셰이딩 변화에는 모션 벡터가 없거나 표면과 다르게 움직인다는 점이다.
광학 흐름 — 두 컬러 이미지만 보고 픽셀이 어디로 갔는지 추정한 흐름장. 모션 벡터가 놓치는 성분을 잡아낸다. 대신 저텍스처 영역·반복 패턴에서는 대응이 모호해 엉뚱한 흐름을 뱉는다. 최근 GPU들이 이 추정을 전담하는 고정기능 블록을 싣는 이유가 여기 있다.

둘을 합쳐 신뢰도 가중으로 섞은 흐름장으로 $R_0$ 을 앞으로, $R_1$ 을 뒤로 양방향 워핑한다. 양방향인 것이 결정적인데, 한쪽에서 가려져 있던 영역은 대개 반대쪽에서는 보이기 때문이다. 그러고도 남는 구멍 — 두 프레임 모두에서 가려진 영역 — 은 이웃에서 끌어오거나(inpainting) 가장 그럴듯한 배경으로 늘려 메운다. 워핑은 여러 소스 픽셀이 한 목적지에 겹치기도 하고 아무도 안 오기도 하므로, 깊이를 함께 들고 다니며 앞의 것이 이기게 하는 처리가 필수다.

HUD와 UI는 별도의 지옥이다. 조준선·체력바·자막은 화면에 고정돼 있는데 배경 모션 벡터를 따라 워핑되면 글자가 흐물거리고 조준선이 두 개로 갈라진다. 처방은 UI를 프레임 생성 이후에 합성하거나(엔진 통합이 필요하다), UI 마스크를 따로 넘겨 그 영역의 흐름을 0으로 고정하는 것이다. 드라이버 수준에서 게임 밖에서 덧씌우는 방식이 화질에서 늘 손해를 보는 지점이 정확히 여기다.

5. 프레임 페이싱[편집]

생성 프레임을 만들어 놓고도 표시 시각을 균등하게 배분하지 못하면 이득이 통째로 사라진다. 렌더 프레임과 생성 프레임을 만들어지는 즉시 내보내면 두 장이 거의 붙어 나오고 그다음 긴 공백이 생긴다. 계수기는 120 fps를 가리키는데 눈에는 60 fps 스터터로 보인다 — 프레임 페이싱이 무너진 상태다.

그래서 구현은 생성 프레임과 그 뒤의 렌더 프레임을 큐에 담고 목표 간격에 맞춰 내보낸다. 그런데 이 큐가 곧 앞서 계산한 $T_r/2$ 지연의 물리적 실체다. 페이싱과 지연은 같은 자원을 두고 다투는 관계이고, 어느 구현도 이 둘을 동시에 이기지 못한다. 여기에 가변 주사율(VRR) 디스플레이가 끼면 표시 시각 자체가 흔들리므로 페이서가 예측해야 할 것이 하나 더 늘어난다.

기저 프레임레이트가 낮을수록 모든 것이 나빠진다는 점도 중요하다. 기저 30 fps라면 $T_r = 33$ ms이므로 추가 지연이 16 ms를 넘고, 프레임 사이 움직임이 커서 워핑 오차와 홀 면적도 함께 커진다. **“프레임 생성은 이미 잘 돌아가는 게임을 더 부드럽게 만드는 도구이지, 안 돌아가는 게임을 구제하는 도구가 아니다”**는 권고가 여기서 나온다.

6. 판정과 공정성[편집]

경쟁 게임에서 프레임 생성이 논쟁적인 이유는 화질이 아니라 표시된 화면이 서버가 아는 세계와 다르다는 데 있다. 생성 프레임 속 적의 위치는 두 실제 상태를 섞은 중간값이고, 그 시각에 플레이어가 입력해도 서버에는 다음 틱에서야 도달한다. 즉 눈에 보이는 것이 최대 반 렌더 프레임만큼 낡았거나, 애초에 존재한 적 없는 중간 상태다. 지연 보상(lag compensation)이 클라이언트 시각을 되감아 판정하는 구조에서는 이 반 프레임이 그대로 오차로 들어간다.

품질 평가도 초해상도와 마찬가지로 정지 프레임 지표로는 잡히지 않는다. PSNR·SSIM은 생성 프레임 한 장이 참조와 얼마나 다른지는 재지만, 깜빡임·페이싱 불균일·홀이 나타났다 사라지는 리듬 같은 시간축 결함을 거의 벌하지 않는다. 그래서 실측에서는 프레임 시간 분포(1% low, 프레임 시간 분산)와 마우스 클릭-투-포톤 지연을 함께 재는 것이 표준이 됐다. 숫자 하나로 요약하려는 시도가 실패하는 대표적인 사례다.³

7. 여담[편집]

프레임 보간 자체는 새 기술이 아니다. TV의 “모션 스무딩”이 수십 년째 하던 일이고, 영화 팬들이 그토록 싫어하는 “소프 오페라 효과”의 정체가 바로 그것이다. 게임 쪽 구현이 다른 점은 모션 벡터와 깊이라는 엔진 내부 정보를 공짜로 받는다는 것 하나뿐인데, 그 하나가 품질 차이를 만든다.
생성 프레임 여러 장을 한 번에 끼워 넣는 확장(렌더 프레임 한 쌍 사이에 2~3장)도 나왔다. 같은 방식으로 세어 보면 $n$ 장을 끼울 때 렌더 프레임의 표시 지연은 $\frac{n}{n+1}T_r$ 이 되어, $n = 1$ 의 $T_r/2$ 에서 출발해 $T_r$ 에 점근한다. 즉 장수를 늘려도 지연이 비례해 폭발하지는 않지만 조금씩 나빠지기는 한다. 대신 각 생성 프레임의 워핑 거리가 짧아져 아티팩트는 오히려 줄어드는 면이 있다.
벤치마크에서 프레임 생성을 켠 fps와 끈 fps를 같은 축에 그리는 것은 사실상 단위가 다른 두 양을 겹쳐 놓는 것이다. “표시 프레임레이트”와 “시뮬레이션 갱신률”을 나눠 적자는 제안이 계속 나오지만, 마케팅 숫자가 큰 쪽을 좋아하는 한 정착되기 어려울 듯하다.

8. 관련 문서[편집]

VR의 비동기 시간 워프(ATW)는 회전만 보정하는 사실상 무료 재투영이고, 비동기 공간 워프(ASW)는 여기에 모션 벡터 기반 병진 보정과 프레임 외삽을 얹은 것이다. 렌더가 90 Hz를 못 맞추면 45 Hz로 렌더하고 나머지를 외삽으로 채우는데, 이때 손이 빠르게 움직이면 컨트롤러 주변이 젤리처럼 일그러진다. 그래도 멀미보다는 낫다는 것이 이 바닥의 합의다. ↩
표시 프레임레이트를 올려서 실제로 좋아지는 것 하나는 있다. 현대 디스플레이는 픽셀을 프레임 내내 켜 두는 sample-and-hold 방식이라 눈이 움직이는 물체를 따라갈 때 그 유지 시간만큼 망막에 잔상이 번진다. 프레임을 더 자주 갱신하면 유지 시간이 짧아져 이 흐림이 준다. 즉 프레임 생성은 눈의 적분 시간에 대한 처방이지 손가락에 대한 처방이 아니다. ↩
이건 검증 및 확인의 오래된 교훈과 같다. 하나의 스칼라 지표는 그 지표가 보지 않는 방향의 실패를 절대 잡지 못한다. fps 평균은 스터터를 안 보고, PSNR은 시간축을 안 보며, 지연 평균은 꼬리를 안 본다. 셋 다 재야 하는데 셋 다 재면 마케팅 슬라이드가 복잡해진다는 것이 진짜 장애물이다. ↩