1인칭 스크롤러

저는 오랜 세월 동안 비디오 게임을 아주 많이 해왔는데, 그에 대해 정말 완전히 놀라운 점은 모든 프레임이 처음부터 다시 그려진다는 사실입니다. 그러니까 초당 30프레임으로 실행되는 게임에서는, 한 프레임에서 다음 프레임으로 넘어가며 얼마나 적게 혹은 많이 바뀌었는지와 상관없이 장면의 모든 것이 33밀리초마다 계산되고 그려져야 합니다. 현대 게임에서는 사용자가 일반적으로 초당 60프레임을 요구합니다. 그래서 화면에 보이는 모든 것은 16밀리초 안에(혹은 그보다 더 짧게) 계산되고, 배치되고, 색이 입혀지고, 텍스처가 적용되고, 음영 처리되고, 기타 등등이 이루어집니다. 그리고 다음 16밀리초 안에(혹은 그보다 더 짧게), 그 모든 일을 처음부터 다시 해내야 합니다. 게다가 장면 전체를 한 자릿수 밀리초 안에 렌더링하는 게임도 있습니다!

제 말은, 저도 예전에 간단한 3D 렌더 코드를 좀 작성해본 적이 있다는 겁니다. 취미로 비디오 게임 개발도 해봤고요. 예를 들어 Gravity Wars를 보세요. (이건 정말로 다시 손봐서 사용자에게 덜 불친절하게 만들어야 합니다.) 그러니 이런 개념에 익숙해져 있을 법도 한데, 이상하게도 저는 아직도 거기에 완전히 적응하지 못합니다. 제 DOS 이전 시대의 뇌는 모든 것을 매 프레임마다 처음부터 다시 계산해야 한다는 생각에 반발하고, 그런 일이 그렇게 미세한 시간 조각 안에서 가능하다는 점에는 두 배로 더 반발합니다.

그래서 웹 브라우저 가 정확히 같은 방식으로, 그리고 같은 성능 요구사항 아래에서 동작한다는 사실에 대해 제가 어떻게 느끼는지 상상하실 수 있을 겁니다.

어쩌면 이것은 놀랄 일이 아닐지도 모릅니다. 결국 우리는 사용자 상호작용도 있고, 임베드된 비디오도 있고, 크기 조절 가능한 창도 있고, 페이지 스크롤도 있고, 그런 여러 가지가 있죠. CSS 애니메이션과 DOM 조작은 말할 것도 없고요. 그래서 뷰포트는 현재 상태를 반영하기 위해 자주 다시 렌더링될 필요가 있습니다. 그리고 그 모든 것이 버터처럼 매끄럽게 느껴지게 하려면, 브라우저 엔진은 최소한 초당 60프레임으로 웹 페이지를 표시할 수 있어야 합니다.

솔직히 말하면, 이것은 소셜 미디어를 탐색하기에 인기 있는 UI가 될 것입니다.

이 요구사항은 절대적으로 모든 것 에 닿아 있으며, 제가 생각하기에 우리가 충분히 인식하지 못하는 방식으로 웹 기술의 진화를 형성합니다. 새로운 선택자 유형을 추가하고 싶다고요? 성능이 좋아야 합니다. 이것이 :has()(그리고 비슷한 제안들)가 그렇게 오랫동안 막혀 있었던 이유입니다. 조상 요소를 선택하는 방법을 알아내는 것이 어려웠던 것은 아니었습니다. 그것을 정말, 정말 빠르게 수행해서 일반적인 렌더링 속도를 그 마법 같은 60fps 아래로 떨어뜨리지 않는 방법을 알아내는 것이 매우 어려웠던 것입니다. 같은 논리는 뷰 트랜지션 같은 새 기능이나, 새로운 필터 함수, 요소 제외, 혹은 여러분이 꿈꿔낼 수 있는 무엇이든에도 적용됩니다. 아이디어가 아무리 멋져도 렌더링을 지나치게 무겁게 만든다면, 시작조차 할 수 없습니다.

덧붙이자면, 이 모든 말이 브라우저를 60fps 아래로 떨어뜨리는 것이 불가능하다는 뜻은 아닙니다. 계산 비용이 큰 작업을 충분히 많이 쌓아 올리면 여전히 미친 듯이 버벅일 수 있습니다. 오히려 핵심은 어떤 새 기능이 단독으로든, 혹은 이미 존재하는 기능들과 결합해서든, 합리적인 상황에서 렌더링 성능을 너무 많이 끌어내리지 않게 하는 데 있습니다. 무엇이 “너무 많이”에 해당하고 무엇이 “합리적인 상황”인지에 대해서는 솔직히 조금 불투명하지만, 그건 다음 기회에 할 대화이자 치열한 논쟁거리입니다.

브라우저 엔진 작업을 해온 사람들은 렌더링 속도를 지키기 위해 내부적으로 무엇을 하는지, 그리고 성능을 죽이는 요소라서 포기해야 했던 아이디어가 무엇이었는지에 관한 흥미로운 이야기를 분명 많이 갖고 있을 거라고 생각합니다. 혹시 BigCo 개발자 관계 팀들이 팟캐스트 아이디어를 찾고 있거나 Igalia Chats에 게스트로 나오고 싶다면, 저는 정말 그런 이야기들을 듣고 싶습니다. (저희는 여러분을 정말 기쁘게 맞이할 겁니다!)

아무튼 제가 하고 싶은 말은, 성능이 단지 에셋 크기를 낮추고 스크립트를 튜닝하고 서버 효율을 높이는 문제만은 아니라는 점입니다. 어떤 이유로 무엇이 바뀌든, 렌더링에 영향을 줄 수 있는 것들을 적절히 예측하면서, 뷰포트의 내용을 15밀리초마다 계속해서, 계속해서, 계속해서, 계속해서, 계속해서 다시 그려낼 수 있는 엔진의 능력도 또한 문제입니다. 우리가 웹 페이지를 매끄럽게 스크롤할 수 있게 하려고 말이죠. 이건 좀 어처구니없을 정도지만, 동시에 또 말이 되기도 합니다. 웹에 오신 것을 환영합니다.