전체 대본

데이브: 안녕하세요, 저는 로블록스의 창립자이자 CEO인 데이브 바주키입니다. 여러분은 지금 '테크 토크'를 듣고 계시거나 시청하고 계실 겁니다. 오늘은 2세대 게임 엔진의 구성 요소, 클라우드와의 연계 방식, 그리고 사용자들이 고해상도로 즉시 접속할 수 있도록 지원하는 방법에 대해 이야기해 보겠습니다. 로블록스의 일원으로서, 여기 기술 분야의 드림팀이 모여 있습니다.

바룬 마니, 세르게이 마키예프, 츠베탄 츠베타노프가 함께하며, 스트리밍에 관한 모든 것을 깊이 있게 다룰 예정입니다. 슬림(Slim)과 자산 트랜스코딩 등, 로블록스가 궁극적으로 10만 명의 플레이어를 지원할 수 있게 해주는 모든 요소에 대해 이야기할 것입니다. 지난 10년에서 20년 간의 게임 산업을 살펴보면,

이 모든 3D 콘텐츠가 여러분 앞에 나타나는 데는 전통적인 방식이 있습니다. 음, 그리고 이 전통적인 방식에는 몇 가지 문제가 있습니다. 왜냐하면 저희 로블록스에서 추구하는 것은 '즉시 접속'이기 때문입니다. 음, 우리는 휴대폰에서도 거대한 PC와 똑같은 경험을 제공하려고 합니다. 음, 우리는 지연 시간 없이 이를 실현하려 하고 있는데, 기존 게임이 작동하는 방식을 보면 상황이 좀 다르죠, 그렇죠?

제 기억에, 음, 제가 어렸을 때는 플로피 디스크라는 매체로 배포되곤 했죠. 하지만 오늘날에도 여전히, 게임을 큰 DVD로 배포하고 있잖아요. 제 말이 맞나요? 

바룬: 네. 그리고 핵심은 모든 게 하나로 묶여 있다는 점인 것 같아요. 네. 그렇죠? DVD든, 요즘 게임을 다운로드하든, 분할할 수 없는 하나의 거대한 패키지로 제공되니까요.

그래서 4.7기가나, 경우에 따라서는 10기가가 완전히 다운로드될 때까지 기다려야 게임을 시작할 수 있죠. 

세르게이: 네. 바룬이 말했듯이, 어떤 게임들은 20~40기가 정도 될 수도 있어서, 게임을 시작하기까지 정말 오랫동안 기다려야 하죠. 그게 좀, 아시다시피, 흐름을 끊어버리는 거잖아요?

그래서 말이에요, 퇴근 후 한두 시간 정도 게임하고 싶은데, 업데이트가 되는 동안 30분에서 40분 정도 기다려야 하잖아요. 제 경험상 거의 다 그런 식이에요. 

데이브: 그거 우리가 비디오나 영화에서 보던 것과 어느 정도 비슷하지 않나요?

예전에는 영화가 DVD로 배포되던 시절도 있었고, 예를 들어 비트토렌트(BitTorrent)가 유행하던 시절도 기억나요. 그때는 전체 파일을 다 다운로드해야 했죠. 그러다 마침내 아마존이나 넷플릭스, 훌루, 투비 같은 서비스에 접속하면 바로 볼 수 있게 되었잖아요. 하지만 게임 시장에서는 아직 그런 변화가 완전히 일어나지 않은 것 같아요.

아직은 아니죠. 아직은. 제 생각엔 아직은 아닌 것 같아요. 

츠베탄: 우리가 유일하게 목표로 삼고 있는 건 

데이브: 그런 걸 목표로 하는 건 우리뿐이에요. 그래서, 역사적으로 보면 로블록스는 그런 방식으로 작동해 왔고, 음, 뒤에서 말이죠. 대부분의 사람들은 눈치채지 못할 수도 있지만, 로블록스 홈페이지에 가서 '플레이'를 클릭하면 바로 참여할 수 있거든요. 이건 사실 매우 비전통적인 방식이에요. 왜냐하면 제가 아주 정교한, 음, 게임 플랫폼들을 이용할 때는 플레이하기 전에 최대 200기가바이트나 되는 다운로드가 발생하는 걸 본 적도 있으니까요.

그러니까, 우린 이미 이 즉시 플레이 기능을 제공하고 있는 건가요? 네. 

츠베탄: 음, 제가 알기로는 로블록스가 이런 즉시 접속 및 플레이를 허용하는 유일한 플랫폼이에요. 아, 맞아요, 

바룬: 네, 죄송해요. 그리고 아까 비디오 스트리밍 얘기하셨잖아요? 영화 전체를 다운로드하고 싶지 않고, 그냥 눈앞에 보이는 부분만 다운로드하는 비디오 스트리밍을 할 때 실제로 무슨 일이 일어나는지 말이에요. 우리는 그걸 버퍼링이라고 부르죠.

저는 영화를 스트리밍하고 있는 거죠. 맞죠? 그래서 그건 맞지만, 그건 단지 한 차원에 불과해요. 거기에는 시간 차원만 존재하니까요. 네, 그게 여기서 핵심적인 차이점이에요. 로블록스에서 이걸 구현하기 어려운 이유가 바로 그거죠. 로블록스는 완전히 상호작용이 가능한 3D 세계라서, 인스턴스와 에셋을 모두 스트리밍해야 하는데, 이건 로블록스 내 모든 것의 기본 구성 요소라고 할 수 있으니까요. 

데이브: 로블록스 A와... 음, 제 생각에는 이게 상황을 더 어렵게 만들었다고 봐요. 왜냐하면 전통적인 비디오 게임 시장에서는...

저는 보통 고사양 PC용과 저사양 모바일용 같은 다양한 버전의 게임을 보게 되거든요. 제가 이를 해석하는 방식은 이렇습니다. 고사양 PC에서는 수백 기가바이트를 다운로드할 수 있으니까 정말 크고 복잡한 에셋을 사용할 수 있고, 모바일의 경우 제작자들이 거의 별도의 버전을 

세르게이: 어느 정도는요.

음, 네. 그, 그, 그건 정말 좋은 지적이네요. 왜냐하면 전통적인 게임의 경우, 아시다시피, 음, '애셋 쿠킹'이라고 불리는 과정이 있거든요. 그래서 그들은, 음, 플랫폼별로 매우 최적화된 버전을 준비하죠. 그리고 좀 더, 아시다시피, 비디오 스트리밍, 스트리밍 관점에서 생각해 보면, 그건 마치 DVD와 같아요.

음, 영상은 한 번만 인코딩되잖아요? 네. 그런데 스트리밍 플랫폼에서는 같은 영상이라도 여러 가지 인코딩 버전을 제공하죠. 그래서 사용자의 기기에 자동으로 맞춰지는 거예요. 그리고 요즘 게임들은 자산을 미리 준비해 두고, 아주 구체적인 사양으로 패키징해서 출시하잖아요.

그래서 우리는 클라우드에서 플랫폼별로 하나의 자산에 대한 최적화된 버전을 생성할 수 있습니다. 맞아요. 

데이브: 그 얘기는 잠시 미뤄두죠. 왜냐하면 얼마 전, 우리는 젊은 크리에이터가 만든 콘텐츠가 어떤 언어로든 실행될 수 있다는 비전을 가졌었거든요. 어떤 기기에서든, 다양한 해상도로 실행될 수 있다는 비전이었습니다.

자, 그 부분에 대해 좀 더 깊이 파고들어 볼게요. 그래서, 그래서, 그래서 전통적인 게임 시장은, 아시다시피 패키지나 다운로드로 제공되죠. 음, 우리는 모든 기기에서 즉시 접근 가능하고, 낮은 지연 시간 등 모든 문제를 한꺼번에 해결하고자 합니다. 그래서 오늘 우리가 이야기할 주제는 말 그대로 '3D 및 40 스트리밍'이라는 것입니다.

클라우드 기반 콘텐츠에 대해 이야기할 예정입니다. 그리고 '슬림(Slim)'이라는 기술에 대해서도 다룰 텐데, 이 부분은 여러분 모두 정말 흥미롭게 여기실 거라 생각합니다. 자, 그럼 본격적으로 들어가기 전에, 바룬 님, 먼저 '슬림'이 무엇인지, 그리고 우리가 '클라우드 트랜스코(Cloud Transco)'라고 부르는 것이 무엇인지에 대한 비전을 간단히 설명해 주시겠어요? 네. 그게 정확히 무엇을 의미하는지 말이죠. 

바룬: 자, 한 걸음 물러서서 생각해 보면, 저희의 전반적인 비전은 게임 시장의 10%를 점유하는 것입니다.

네. 그 목표를 달성하기 위한 방법은 크리에이터들이 제작하는 콘텐츠에 대해 완전한 자유를 부여하는 것입니다. 음, 그리고 우리가 성장하는 방식을 생각해보면, 두 가지 차원이 있습니다. 플랫폼 확장을 할 수도 있고, 장르 확장을 할 수도 있죠. 플랫폼 확장이란 동일한 콘텐츠를 어떤 플랫폼에서든 작동하게 만드는 방법입니다.

그러니까 한 번만 제작하면 됩니다. 로블록스에서는 어디서든 작동하도록 보장하죠. 그리고 장르 확장의 경우, 우리는 여러분이 점점 더 인상적이고, 점점 더 기발한 것들을 만들어내길 원합니다. 

데이브: '어디서나 실행된다'는 말이 말 그대로, 정말 거대하고 기발하며 재미있는 무언가를 상상해 보세요. '그랜드 테프트 오토', '레드 데드 리뎀션', 고사양 콘솔 게임 같은 것들 말이죠.

2GB 안드로이드 폰부터 그 사이의 모든 기기까지 구동되는 거죠. 맞습니다. 

바룬: PC부터 2GB 안드로이드 폰에 이르기까지, 제작자가 별도의 작업을 하지 않아도 그냥 작동해야 합니다. 그게 바로 비전입니다. 정확해요. 클라우드, 트랜스코딩, 그리고 슬림(Slim)은 우리가 그 길을 향해 내디딘 첫걸음 중 두 가지에 불과합니다.

데이브: 좋아요, 그럼 이건 일종의 예고편이네요. 슬림(Slim)이 무엇인지 설명할 거고, 트랜스코딩이 무엇인지에 대해서는 아마 당신이 설명해 주실 것 같지만, 우선 모두를 소개하는 것부터 시작해 볼까요? 자, 세르게이, 음, 돌아오셨네요. 엔진 최적화에 대한 당신의 배경을 조금 공유해 주실 수 있나요? 세상에서 가장 재미있는 일 중 하나죠, 그렇죠?

C++이나 어셈블리 언어, C/C++ 같은 것들 말이에요. 그동안 어떤 작업을 해오셨는지 조금만 소개해 주실 수 있나요? 

세르게이: 음, 네, 아까 말씀하신 대로, 네, 저는 거의 평생 게임이나 게임 관련 일을 해왔고, 지역 Xbox 같은 것부터 시작해서 온갖 최적화 작업을 해왔어요.

음, 그리고요. 아시다시피, 제가 처음 로블록스(Roblox)에 대해 알게 되었을 때, 한 번만 만들면 되는 게임, 아니 게임이라기보다는 어떤 경험 같은 걸 어디에서나, 어떤 플랫폼에서든, 어떤 기기에서든 추가적인 사용자 입력 없이 실행할 수 있다는 아이디어에 정말 큰 충격을 받았죠.

그리고 그건 정말 어려운 엔지니어링 문제죠. 음, 다들 상상할 수 있듯이 말이죠. 그래서, 음, 그건 많은, 음, 아시다시피, CMD나 멀티 트레이딩 같은 전통적인 최적화, 그리고 매우 세심한 GPU 스케줄링 등 모든 것이 필요하죠. 하지만 동시에, 아시다시피, 단일 기기에서 얼마나 확장할 수 있는지에 한계가 있죠.

다행히도 우리에겐 항상 클라우드가 있잖아요? 그래서 이 작업의 일부를 클라우드에 업로드해서, 디바이스들이 더 큰 벽을 더 효율적으로 렌더링할 수 있도록 도울 수 있죠. 어느 정도까지는, 예를 들어 물리적 디바이스 메모리에 다 들어가지도 않는 벽을 렌더링할 수 있게 되는 거죠. 왜냐하면 그 벽들이 서버 측에도 존재하고, 서버가 모든 클라이언트가 이를 효율적으로 렌더링할 수 있도록 도와주기 때문이에요.

데이브: 네. 그리고 요점을 말하자면, 우리가 이 아래에서 공유할 힌트 중 하나는 전통적인 게임 엔진은 보통 C++로 작성되고, 모든 에셋을 다운로드한다는 점이에요. 하지만 예를 들어, 플레이하고 싶은 게임이 '전 세계'라고 가정해 봅시다. 아무도 전 세계를 DVD 한 장에 담을 수는 없잖아요.

그래서 당신이 정말로 암시하는 바는, 구글 맵스나 그와 유사한 다른 서비스에서 이미 볼 수 있듯이... 음, 그 모든 것을 한곳에 담을 방법은 없습니다. 그래서 우리가 스트리밍이라고 말할 때 다룰 내용 중 일부는 게임과 엔턴에 대한 바로 그와 같은 것입니다. 로블록스에 오게 된 계기와 배경, 그리고 클라우드 트랜스코딩이 무엇인지에 대한 약간의 힌트를 좀 주실 수 있나요?

그래서, 

츠베탄: 음, 로블록스에 합류하기 전에는 두 가지 분야에서 경력을 쌓았습니다. 하나는 건축, 건설, 기계 공학을 위한 3D 설계 및 시뮬레이션 소프트웨어 분야였고, 두 번째는 대규모 분산 컴퓨팅 분야였습니다. 이 두 분야의 지식을 로블록스에 적용할 수 있는데, 사실 로블록스 자체가 그런 개념이기 때문이죠.

데이브: 네. 그럼 로블록스에서의 스트리밍으로 넘어가서 이야기해 봅시다. 음, 비디오 스트리밍이 뭔지는 다들 아시죠. 비디오 스트리밍은 일종의 선형적인 과정이죠, 맞나요? 그냥 프레임 하나씩만 있으면 되죠. 한 프레임이 끝나면 다음 프레임을 차례로 전송하는 식이고요. 3D 환경에서 실시간 스트리밍이 어떤 의미인지 설명해 주실 수 있나요? 

바룬: 사실 오늘날 로블록스 게임의 거의 모든 요소가 인스턴스나 에셋으로 구성되어 있다는 걸 아실 거예요.

인스턴스는 말하자면 세계의 구조 같은 거예요. 그리고 에셋은 실제 콘텐츠를 위해 그 인스턴스를 구동하는 요소죠. 음, 스트리밍을 생각해보면, 인스턴스를 스트리밍하고 그 에셋들도 스트리밍하는 것이죠. 그게 필수적인 과정이에요. 그러니까 비디오 스트림에서는 에셋이 하나만 있다면, 그게 바로 비디오인 셈이죠.

로블록스에서는 이 작업을 수천 번, 1만 번, 계속해서 반복하고 있습니다. 따라서 '인스턴트 스트리밍'이라고 할 때, 주변 세계의 충분한 부분을 스트리밍하려고 시도하는 것이지만 플레이어가 어떻게 행동할지는 알 수 없습니다. 플레이어가 이쪽으로 걸을 수도 있고, 저쪽으로 걸을 수도 있으니까요. 세계의 충분한 부분만 스트리밍하거나 버퍼링해야 합니다.

그리고 버퍼링한 그 세계 안에서, 자산들을 정확히 적절한 품질로 버퍼링해야 합니다. 세르게이가 언급했듯이, 비디오에는 다양한 품질 레벨이 있습니다. 메쉬나 이미지도 마찬가지입니다. 

데이브: 그럼, 이를 세분화해 보면 인스턴스(instances)는 우리가 익숙한 것들, 예를 들어 자동차, 나무, 다른 사람, 언덕 같은 것들을 말하는 건가요?

자동차, 나무, 다른 사람, 언덕 같은 것들 말이죠. 그리고 '애셋'은 그런 인스턴스를 구성하는 기술적인 요소들입니다. 3D 오브젝트 내부에 있는 것들처럼요. 게임을 할 때 우리는 삼각형 덩어리나 텍스처 덩어리 같은 것들을 다루게 되는데, 우리는 그중 어떤 것을 언제 불러올지 선택하는 것에 대해 이야기하고 있는 겁니다.

언제든 실제로 불러오는 거죠. 

바룬: 네. 그리고 그것들의 어떤 표현을 사용할지도요. 그래서 여러분이 세계를 걸어 다닐 때, 마치 기기가 "좋아, 저 나무가 필요해"라고 말하는 것과 같아요. 그 나무는 수많은 메시와 텍스처로 구성되어 있고, 미래에는 애니메이션이나 오디오 등도 포함될 수 있겠죠.

그러면 기기가 판단을 내립니다. 좋아요. 그 나무의 위치, 중요도, 화면에서 차지하는 공간을 바탕으로 말이죠. 텍스처는 고화질로, 메시는 중간 화질로 처리하고 싶고요. 그리고 오디오는, 아직 필요 없을 수도 있으니 오디오는 보류하지 말라고요. 그래서 기기는 끊임없이 그런 결정을 내리고 있는 거죠, 

데이브: 그러니까 어떤 면에서는, 제가 매핑 프로그램을 사용할 때 지도의 작은 이미지나 일부만 불러오는 것과 비슷하죠.

우리는 그 3D 버전과, 아시다시피 인터랙티브 3D 구성 요소들에 대해 이야기하고 있는 거죠. 알겠습니다. 그리고 여기 뒤에서 정말 중요한 무언가가 있습니다. 제 생각에, 우리의 비전은 항상 어떤 기기나 어떤 환경에서든, 적절한 요소를 가능한 한 빨리 불러오려는 것이었습니다.

그리고, 때로는 사람들이 느끼는 '마법 같은 경험'을 극대화하기 위해 가능한 한 빨리 로드해야 한다고 말하기도 해요. 마치 "와, 세상이 내 눈앞에 나타났어!"라고 느낄 수 있도록 말이죠. 그래서 세르게이, 우리는 무엇을 로드하고 불러올지 어떻게 선택하고 분류하나요? 

세르게이: 네, 맞아요. 음, 최적화, 그러니까 사용자가 느끼는, 음, 지연 시간 같은 거 말이죠.

그건 정말 중요해요. 바룬이 방금 언급했듯이 말이죠. 우리는 화면 공간의 영역이나 오브젝트의 중요도를 끊임없이 측정하고 있어요. 예를 들어, 아주 가까운 거리에서 나무를 보거나, 아주 먼 거리에서 똑같은 나무를 본다면, 그건 마치 두 개의 다른 나무처럼 보일 수 있잖아요?

그래서 멀리서 보면, 세밀한 텍스처 디테일 같은 건 별로 신경 쓰지 않게 되죠. 그래서 우리는 나무 같은 경우 항상 저해상도 텍스처를 적용할 수 있어요. 음, 화면상으로는 구조물이 아주 작게 보이니까, 저해상도인지 고해상도인지 구분할 수 없을 거예요.

하지만 반대로, 데이터 양이 훨씬 적기 때문에 거의 즉시 불러올 수 있죠. 그런데 그 세 개에 가까워지면 점점 더 많은 데이터를 불러오게 되고, 더 디테일하게 보일 거예요. 그래서 전환되는 지점은 보이지 않을 거고, 차이를 구분할 수는 없겠지만, 그걸 즉시, 바로 보고 상호작용할 수 있게 될 거예요.

데이브: 그리고, 이 부분의 일부는 제가 2GB 안드로이드 폰이나 게이밍 PC를 사용하면서 무언가에 즉시 접속하고 싶을 때의 상황이에요. 인터넷 속도가 정말 빠르더라도, 우리에겐 대역폭이 충분하지 않죠. 마치 그 파이프를 통해 세상을 밀어 넣으려는 것처럼요. 초당 10메가비트든 100메가비트든 상관없이, 그 파이프를 통해 전송하는 양의 균형을 맞춰야 하죠.

그리고, 제가 가끔 이걸 생각할 때 드는 비유는, 제 근처에 있는 나무 한 그루가 멀리 있는 나무 백 그루와 같은 정보를 사용할 수 있다는 거예요. 음, 멀리 있는 그 백 그루의 나무가 제 근처에 있는 나무 한 그루만큼 시각적으로 중요할 수 있는데, 우리는 서로 다른 해상도로 그 나무들을 불러오죠.

가까운 나무는 멀리 있는 나무들보다 훨씬 더 고화질로 처리되는 것과 같습니다. 

세르게이: 네, 음, 정확히 맞습니다. 음, 그리고, 음, 당신이 언급한 중요한 점은, 우리가 단순히 객체의 중요도를 측정하는 것뿐만 아니라, 우리가 얼마나 많은 컴퓨터 자원을 가지고 있는지도 고려한다는 것입니다.

메모리는 얼마나 있는지, 네트워크 대역폭은 어떤지 등 모든 것을 고려합니다. 그래서 저희는 사용자 경험에 영향을 미치는 모든 요소, 즉 성능을 포함한 모든 것을 고려합니다. 메모리가 얼마나 있는지 등 모든 것을 말이죠. 

데이브: 자, 지금까지 인스턴스는 나무와 같고, 에셋은 메시나 텍스처와 같다고 이야기했죠.

이 둘이 어떻게 다른지, 그리고 실제로 자산 스트리밍을 통해 내부적으로 어떤 작업을 수행하고 있는지 좀 더 자세히 설명해 주실 수 있나요? 좋아요. 

츠베탄: 네. 음, 예를 들어 서버에서 스트리밍할 때, 어떤 사이트가 중요한가요? 네. 그리고 그 중요도에 따라, 음. G가 이 정보를 제공해서 모든 클라이언트에게 전달하고, 각 클라이언트는 상황에 따라 실제로 서로 다른 인스턴스를 받게 됩니다.

보이는가? 보이지 않는가? 인터랙티브 영역에 참여하고 있는가 아닌가? 자산 스트리밍의 경우, 실제로 월드에 있던 것을 스트리밍하는 것은 클라이언트입니다. 음, 세르게이가 말했듯이, 우리가 목표로 하는 품질과 기기의 성능에 따라, 우리는 품질과 기기의 성능에 기반하여 정확히 그 품질의 표현만을 대상으로 합니다.

대략 그런 식이에요. 음, 그래서 

데이브: 저 멀리 있는 나무들은 아주 압축되어 있겠죠? 해상도가 낮아서 용량을 많이 차지하지 않는 거죠. 그래서 더 가까이 있는 나무에 더 많은 시간과 컴퓨팅 자원을 할당할 수 있는 거고요. 그래서 저희는 콘텐츠 파이프라인 또는 자산 파이프라인이라고 부르는 시스템을 가지고 있습니다.

게임 제작자 입장에서 이 트랜스코딩 파이프라인이 어떻게 작동하는지 간단히 설명해 주실 수 있나요? 예를 들어, 제가 로블록스 스튜디오를 사용해서 정말 멋진 자동차를 만들었다고 가정해 봅시다. 그 뒤에서는 어떤 일이 일어나는 건가요? 

츠베탄: 

데이브: 

츠베탄: 엔진 성능이 향상됨에 따라, 저희는 디자이너와 게임 개발자들의 예술적 의도를 그대로 보존하고 싶었습니다.

그래서 저희는 클라우드 트랜스코딩이라는 아이디어를 고안해 냈습니다. 이를 통해 크리에이터 스토어에서 콘텐츠를 가져와 저장하고, 클라이언트가 필요로 하는 개발 기기, 즉 기기와 성능에 따라 최적화할 수 있게 되었습니다. 그리고 이 파이프라인은 종단 간(end-to-end)이며, 필요에 따라 지연 처리(lazy on demand)됩니다. 즉, 클라이언트가 특정 표현을 요청했을 때, 해당 표현이 없는 경우에만 연산을 시작합니다.

그렇지 않다면, 이미 존재할 경우 바로 반환합니다. 따라서 클라이언트에게 제공하는 대역폭과 컴퓨팅 자원을 매우 효율적으로 활용하고 있습니다. 그래서 

데이브: 음, 제가... 그리고 우리도, 이 기능이 없던 아주 오래전, 혹은 사실 꽤 최근까지만 해도, 이런 자산의 정밀도에 제한을 두어야 했었죠.

예를 들어, 자동차에 사용할 수 있는 삼각형의 수를 제한하고, 삼각형이 많을수록 자동차가 더 정밀해 보인다고 말했을 겁니다. 아니면 텍스처 크기에 사용할 수 있는 픽셀 수를 제한하기도 했죠. 지금 우리가 말하는 건, 여러분이 만든 그대로 그 자동차를 업로드할 수 있고, 그 뒤에서 트랜스코딩이 이루어진다는 것입니다.

삼각형 수를 점점 줄여가며 그 자동차의 다양한 버전을 만들어내는 거죠. 

츠베탄: 네, 맞습니다. 아니면 사실 앞으로는 더 늘어날 수도 있고요. 네. 그리고, 음, 이제 우리는 엔진 개선 상황과 우리가 보유한 컴퓨팅 성능에 따라, 음, 삼각형 수나 텍스처, 맵, 오디오, 비디오, 애니메이션 등 필요한 모든 요소의 표현을 개선할 수 있는 능력을 갖추게 되었습니다.

그래서, 

데이브: 그러니까 이건 온디맨드 방식이고, 세르게이, 아까 말씀하신 게 바로 그거죠. 예전에는 베이킹이라는 걸 해서 고해상도 모델을 미리 구워두곤 했잖아요. 우리는 본질적으로 온디맨드 방식으로 베이킹을 하고 있는 셈이죠. 다양한 해상도의 그 자동차 버전이 여러 개 준비되어 있는 거죠. 그 모든 게 거기에 저장되어 있고요. 그러면 제가 멀리서 볼 수 있는 그 자동차는 그중에서 해상도가 낮은 버전 중 하나일 수 있는 거죠.

그리고 이게, 음, 제가 알기로는 우리가 트랜스코딩이라고 부르는 것 같아요. 네. 그럼 트랜스코딩은 어떻게 작동하나요? 예를 들어 백만 개의 삼각형을 어떻게 천 개의 삼각형으로 바꾸나요? 제 말은, 음. 

츠베탄: 음, 인제스트(ingestion) 단계죠. 네. 스튜디오에서 저희는, 음, 실제로 그 100만 개의 삼각형으로 된 메쉬를 인제스트합니다. 그런 다음 저희 백엔드, 음, 콘텐츠 플랫폼, 음, 백엔드 시스템에 저장하죠.

그리고, 음, 요청이 들어오면, 저희는 실제로 LOD 처리를 실행하는데, 

데이브: LOD라는 건 디테일 레벨(Level of Detail)을 뜻하죠. 디테일 레벨이란, 

츠베탄: 상황에 따라, 제한된 메쉬 표현이나 텍스처에서 가능한 한 품질을 유지하려고 노력하는 거죠. 

데이브: 자, 음, 바룬, 이 기능이 다양한 기기에서 어떻게 작동하는지 생각해 보면, 음, 당신은 제작자입니다.

당신은 이 거대한 고해상도 자동차를 넣었어요. 저는 저사양 안드로이드 기기를 쓰고 있고, 당신은 고사양 PC 게이밍 기기를 쓰고 있죠. 그래도 우리가 같은 게임을 할 수 있으면 좋겠네요. 맞아요. 우리 둘에게 어떤 일이 일어나는 걸까요? 그리고, 

바룬: 그러니까, 기본적으로 제 클라이언트가 온라인에 접속하면, "저기, 전 저사양 안드로이드 기기예요. 이걸 원해요"라고 말하는 거죠. 사실 우리가 언급하지 않은 한 가지가 있는데, 이건 단순히 디테일 수준에 관한 게 아니라 플랫폼별 표현 방식에 관한 문제이기도 하거든요.

그래서 안드로이드, iOS, 이런 각기 다른 플랫폼마다 매우 구체적인 표현 방식이 있어서 텍스처를 압축하거나, 훨씬 더 최적화되도록 조정할 수 있죠. 그래서 제 안드로이드 기기가 온라인에 접속하면 "저기, 저 나무에 대한 저사양 텍스처의 안드로이드 버전을 원해요"라고 말하고, 그러면 클라우드 트랜스크립트가 작동해서 저를 위해 그걸 만들어 주고, 캐시해 둬서 다음에 안드로이드 기기가 온라인에 접속할 때

다시 만들 필요가 없죠. 제가 만든 버전을 그대로 보내면 됩니다. PC가 연결되면, "이봐, 나한테는 세상 모든 리소스가 다 있어. 고화질 버전 줘, 압축 안 풀린 버전 줘. 그냥 최고 수준의 화질을 원해"라고 요청하죠. 그러면 시스템이 바로 그걸 캐싱해 둡니다. 즉, 이건 미래에도 영원히 유효한 방식이라는 뜻이죠.

데이브: 게다가 무한히 즉각적이죠. 전 '그랜드 테프트 오토'를 정말 좋아하는데, 곧 정말 놀라울 정도로 멋진 새 버전이 나온다고 하더라고요. 정말 기대되네요. 만약 제가 아티스트로서, 음, 어떤 에셋을 수정하고 싶다면요. 우리, 바라건대 미래의 시스템에서는, 약 5초 만에 다시 업로드할 수 있을 거예요.

당신과 제가 플레이하는 게임이 그 자산에 대한 새로운 트랜스코딩을 트리거할 테니까요. 말 그대로, 아시다시피, 최대 동시 접속자 수, 예를 들어 2,500만 명이 '가든 가드닝' 같은 걸 하는 상황에서도 5~10초 만에 그 모든 신규 유저들이, 아마도 그 새로운 자산을 받아볼 수 있을 겁니다. 이것이 제가 이 기술이 어느 정도 미래형이라고 생각하는 이유입니다. 왜냐하면, 음, '그랜드 테프트 오토'의 매력 중 하나는, 그들이 엄청난 퀄리티를 미리 구워 넣는다는 점이라고 생각하기 때문이죠.

거대한 DVD에 담아야 하니까요. 완벽해야 하고, 그 과정에서 수정할 여지가 없죠. 그 자리에서 완벽하게 만들어야만 해요. 그래서, 음, 마지막으로 말하자면, 미래 대비 측면에서 즉각적인 변경 외에도 예술적 의도를 저장하는 것, 즉 원본 예술 작품을 보관하는 데는 뭔가 장점이 있는 것 같아요.

어떤 면에서, 그게 우리에게 어떻게 도움이 될지 말씀해 주실 수 있나요? 음, 

세르게이: 네. 그러니까 저희는 가능한 한 많은 원본 예술적 콘텐츠를 포착하려고 노력하고 있고, 이를 위해 모든 자산의 소스 버전, 맞아요. 소스 버전을 저장하고 있습니다. 그리고 아시다시피, 저희는...

텍스처의 단순화된 버전을 생성하여 다운샘플링할 수 있을 뿐만 아니라, 향후 업샘플링도 가능합니다. 왜냐하면 우리는 이미 원본의 의도나 의미 정보를 포착해 두었기 때문에, 나중에 이 자산을 업스케일할 수 있죠. 게다가 사용자의 개입 없이도 말이죠.

더 나은 품질로 만들 수 있죠. 

데이브: 그거요, 그건 우리가 미래로 나아갈 때 큰 단서가 될 거예요. 음, 그럼, 음, 지금까지 이야기한 내용에 두 번째 요소를 추가해 봅시다. 그러니까 우리는 스트리밍을 하고, 즉각적인 수정을 하고, 클라우드 트랜스코딩을 통해 어떤 LOD든 전달합니다. 그리고 처음에 암시했던 것처럼, 우리는 '슬림(Slim)'이라는 것으로 이를 보완할 겁니다.

슬림(Slim)은 운동 프로그램이 아닙니다. 로블록스(Roblox)와도 다르고, 우리 모두를 기분 좋게 만들고 머리를 맑게 해줄 로블록스 스낵(Roblox snacks) 같은 것도 아닙니다. 음, 로블록스 엔진 맥락에서 슬림이란 무엇일까요? 

세르게이: 네, 맞아요. 음, 그러니까. 음, 잠시 뒤로 돌아가서, 음, 아까 나무 예시를 다시 들어볼게요, 알겠죠?

그래서, 음, 나무가 하나 있고, 제가 말했듯이 멀리서 보면 여러 그루의 나무가 있을 수 있잖아요. 음, 슬림은 그런 개별 나무들을 마치 숲처럼 바꾸고 최적화하는 거예요. 더 이상 개별적으로 처리하는 게 아니라, 더 큰 무언가, 개별 라이선스의 집합 같은 것으로 최적화하는 거죠.

이것이 바로 슬림 기술입니다. 이 기술은 항상 특정 맥락에서 이러한 자산을 최적화합니다. 예를 들어, 건물이 있다고 가정해 봅시다. 그리고 그 건물 안에는 여러 개의, 음, 방들이 있다고 칩시다. 건물 밖에 있다면 건물 안의 방들은 신경 쓰지 않잖아요. 슬림은 이런 맥락을 인지하고 있어서, 그 경우처럼 건물 내부의 모든 요소를 매우 효율적으로 제거하고, 최적화하여 그 자산의 가장 효율적인 버전을 생성해 줍니다.

데이브: 음, 이걸 설계해 오시는 동안 제가 생각해 온 세 가지 사용 사례가 있거든요. 첫 번째는 사람들이 점점 더 복잡한 아바타를 만들고 있다는 점이에요. 예전 로블록스에서는 옷을 몇 겹이나 입을 수 있는지, 보석을 얼마나 달 수 있는지, 물건을 얼마나 달 수 있는지 등에 대해 매우 신중했었죠.

하지만 미래에는 아바타에 100개나 되는 수많은 아이템이 달릴 수도 있겠죠. 그리고 우리 크리에이터들은 성능에 대해 매우 잘 알고 있다고 생각해요. 그들은 성능을 극대화하기 위해 아바타의 디테일 수준을 일부 제한할 수도 있고요. 첫째는 복잡한 아바타입니다. 둘째는, 당신이 언급했듯이, 저 멀리 떨어진 곳에 나무가 백 그루나 있을지라도 아무도 그 나무들과 상호작용하지 않는 경우죠.

그리고 세 번째는 내부에 방이 있는 건물일 수도 있겠죠. 음, 제가 생각하기에, 음, 우리가 여기서 시도하려는 것은 그것이 무엇이든, 움직이는 아바타든, 수많은 나무든, 건물이든, 이 똑같은 시스템이 본질적으로 하나의 오브젝트, 하나의 메시, 하나의 텍스처로 합성될 것이라는 점입니다. 그리고 그건 정말 믿기 힘들 정도로 놀라운 일이죠.

음, 

세르게이: 네, 정확히 맞습니다. 정말 적절한 표현이네요. 이 시스템은 여러 에셋을 조합하여 컴포지션(composite) 표현을 동적으로 생성하는 것과 같고, 이 컴포지션의 경계나 디테일 수준을 동적으로 결정하며, 항상 이러한 월드 컨텍스트 내에서 작동합니다.

그래서 마치 두 가지 다른 경험에서처럼, 사용 환경이나 대상 기기에 따라 다르게 최적화될 수 있는 것과 정확히 같아요. 음, 그리고 저희는 해당 콘텐츠에 대한 동적 업데이트도 지원해요. 그러니까 항상 정적인 최적화만 하는 건 아니라는 거죠.

시간이 지남에 따라 무언가가 변경되면, 저희가 동적으로 업데이트할 수 있기 때문에 슬림한 표현에 그 변경 사항이 반영됩니다. 

데이브: 음, 제가 이 기능을 정말 좋아하는 이유 중 하나는 마치 제가 로블록스 개발자인 것처럼 느껴지기 때문이에요. 저는 정말 대규모의, 예를 들어 정말 복잡한 아바타를 원했거든요.

이건 제 꿈일 수도 있겠지만, 예를 들어, 제 곁에 있는 사람에게 다가가면, 그 사람이 모자를 벗거나 새로운 장신구를 착용할 수 있는 거죠. 이 시스템은 가까운 물체에 대해 일반적인 고화질로 작동할 거예요. 그리고 그 아바타가 멀어지면, 하나의 객체로 합쳐지죠.

그리고 LOD(세부 수준)에 따라 점점 더 멀어질수록요. 음, 우린 농담 삼아 말하곤 하는데, 궁극적인 형태는 아주 멀리 있는 아바타가 삼각형 12개로 이루어지고, 정말 작은 텍스처를 가진 모습일 거라고요. 그래서 이건, 이건 거의 개발자가 꿈꿔왔던 것과 비슷하다고 생각해요. 그리고 제 생각에, 음, 이것이 가능하게 하는 것 중 하나는 더 큰 세계입니다.

다양한 기기에서 말이죠. 

바룬: 맞아요. 제 말은, 슬림(Slim)이 본질적으로 하는 일은 우리에게 확장성의 새로운 축을 제공한다는 거예요. 우리는 다양한 디테일 레벨에서의 클라우드 트랜스코딩에 대해 많이 이야기했죠. 이제 여기에 또 다른 축, 즉 합성(compositing)과 관련된 차원을 추가하고 있는 거죠. 맞죠? 그리고 여기서 2x2 격자 구조를 생각해 볼 수 있는데, 그 격자상의 어느 지점이든 유효한 경험이 될 수 있어요.

맞습니다. 따라서 고화질에 낮은 합성 수준을 선택할 수도 있고, 매우 저사양 기기나 다른 기기를 사용할 경우 고화질에 높은 합성 수준을 선택할 수도 있습니다. 그리고 그 모든 지점이 타당합니다. 따라서 거대한 세계를 이야기한다면, 그 전체 세계가 12개의 삼각형으로 구성될 수도 있습니다. 또한, 충분히 멀리 떨어져 있거나, 차이가 없다면 말이죠.

데이브: 그리고 사용자 경험과 Slim이 어떻게 더 나은 사용자 경험으로 이어질 수 있을지 생각해 봅시다. LOD를 생각하면 클라우드 트랜스코딩이 떠오르고, Slim을 생각하면 현재 또는 1년 전의 Roblox와 비교했을 때 스트리밍이 떠오르는데요. 이것이 사용자 경험에 어떤 영향을 미칠 수 있을까요? 

츠베탄: 네, 슬림은, 음, 개발자들이 더 풍부하고 거대하며 복잡한 세계를 만들 수 있도록 지원한다는 아이디어로 개발되었죠.

음, 최종 사용자와 상호작용하고 반응하는 세상을 말이죠. 시멘스? 음, 네, 아주 쉽게요. 마치, 음, 최종 사용자에게는, 음, 가장 강력한 기기를 사용하는 것과 똑같은 사용자 경험을 제공하듯이요. 그리고, 음, 슬림은, 음, 현재 정적 모델을 지원하는 시스템입니다. 그리고 우리는, 음, 아시다시피. 앞으로 아바타와 동적 모델을 계층적으로 생성할 수 있게 함으로써, 최종 사용자에게 시스템을 최대한 빠르게 제공할 수 있도록 하고 있습니다. 

데이브: 이는 최종 사용자에게는 저사양 기기에서도 더 풍부한 세계를 경험할 수 있게 해줄 것입니다.

제 저사양 휴대폰에서도 가능할 수 있죠. 제가 당신의 게이밍 PC에서 당신과 함께 게임을 즐길 수 있는 거죠. 음, 크리에이터들은 더 높은 수준의, 음, 아바타의 옷 층 수 같은 건 걱정하지 않아도 됩니다. 더 복잡한 차량이나, 음, 정교한 기계적 오브젝트들도 슬림(Slim)을 통해 압축될 테니, 정말, 정말 멋질 거예요.

그리고 말이죠. 음, 이 기술들이 어떻게 상호 작용할지 생각해 볼 필요가 있겠네요. 클라우드 트랜스코딩에 대해 이야기했는데, 음, 더 낮은 LOD를 제공하는 거죠. 그리고 정말 가벼운 모델인 슬림(Slim)에 대해서도 이야기했죠. 이 두 기술이 함께 작동할까요? 

바룬: 정말 맞는 말씀이에요. 제가 '접근성'에 대해 언급했을 때 바로 그 점을 의미했죠. 모든 슬림 모델도 정확히 동일한 클라우드 트랜스코딩 파이프라인을 거치거든요.

왜냐하면 일단 합성하고, 컨텍스트와 콘텐츠를 기반으로 슬림 모델이 결정되면, 이것이 바로 합성 결과물이 되어야 하니까요. 동일한 트랜스코딩 파이프라인을 거쳐 모든 콘텐츠에 대해 저화질 버전, 고화질 버전, 안드로이드 버전, iOS 버전을 생성하게 됩니다.

그래서, 음, 이 두 가지가 서로 정말, 정말 잘 보완되는 관계죠, 

데이브: 그래서 제작자 입장에서는 거의 일석이조 같은, 아주 복잡한 아바타를 원격으로 슬림 모델에 합성한 다음 트랜스코딩하는 과정이죠. 그 아바타는 다시 말해 12개의 삼각형에 단색으로만 이루어져 있을 수도 있고요. 그리고, 그리고 

바룬: 우리가 기대하거나, 제가 예상하는 것은 일종의 1차적인 목표입니다.

기존의 모든 경험이 점점 더 저사양 기기에서도 실행될 수 있게 되는 거죠. 

데이브: 네. 

바룬: 하지만 정말 흥미로운 점은 2차적인 효과들이죠, 그렇죠? 크리에이터들은 '아, 세상에 더 많은 것을 담을 수 있구나. 아, 추가할 수 있구나'라고 깨닫기 시작할 거예요. 음, 생각해 보세요 

데이브: 음, 제가 영상을 제작한다고 생각해 보세요. 마치 카메라가 꽤 철저하게 설계된 것과 같아요.

알다시피, 4K 카메라를 쓰면 어디를 향하든 내가 원하는 대로 영상을 찍을 수 있어서 전혀 걱정할 필요가 없잖아요. 하지만 오늘날 우리 크리에이터들은 그런 카메라를 가지고 있지 않아요. 만약 카메라를 잘못된 곳을 향하게 하면 세상이 뒤집힐 수도 있잖아요? 해상도가 너무 높아서, 예를 들어 1만 명이나 되는 군중을 향해 카메라를 돌리면, 마치... 그래서 이건 몰입형 3D 카메라의 제약을 풀어주는 것과 같으면서도, 

바룬: 크리에이터들에게 자유를 주는 셈이죠.

그래서 플랫폼 확장을 하고, 그다음 장르로 나아갈 수 있죠. 네, 

데이브: 그리고, 음, 언젠가는—정확한 시점은 모르겠지만—무어의 법칙에 따른 컴퓨팅 성능, 슬림 3D, 스트리밍 AI, 로컬 업샘플링 기술 등이 결합되어 이 카메라가 더 이상 제약이 되지 않는 시점이 올 거라고 생각해요. 거대한 경기장에 10만 명의 사람들이 포토리얼리스틱하게 친구들과 어울리는 모습을, 로우엔드 기기에서 낮은 지연 시간으로 스트리밍해도 정말 자연스럽게 느껴지는 그런 시점이요.

그게 바로, 제 생각에 우리가 '몰입형 40대 카메라'가 성숙했다고 말할 때, 음, 좋은 소식이자 나쁜 소식은 아직 해야 할 일이 많다는 거예요. 그래서 우리 일이 꽤 흥미로워지죠. 그리고 저는, 음, 그 궁극적인 3차원 및 4차원 카메라를 향해 우리가 얼마나 빠르게 나아가고 있는지에 대한 주제와 관련해서, 음, 세르게이, Slim의 다음 단계는 무엇이며, 이 다음에는 무엇을 최적화해야 할까요?

그래서 

세르게이: 슬림의 경우, 음. 우리 앞에 몇 가지 큰 단계가 남아 있습니다. 예를 들어, 바로 다음 단계는 슬림을 아바타, 이동하는 차량, 움직이는 메커니즘 등 모든 것을 지원하는 완전한 동적 시스템으로 만드는 것입니다. 하지만 그 다음으로 더 중요한 단계는, 배런이 언급했듯이, 슬림을 계층적으로 만드는 것입니다. 아시다시피, 슬림은 일반 자산과 거의 동일한 자산을 생성합니다.

이것들은 정확히 똑같은 스트리밍 파이프라인을 거치죠. 각 슬림 모델마다 고유한 올로지 같은 게 있어서 최적화를 거치긴 하지만요. 그런데 만약 이걸 더 발전시켜서, 여러 슬림을 하나로 합쳐서, 말하자면 '메가 슬림' 같은 걸 만들고, 그런 식으로 프랙탈처럼 계속해서 반복할 수 있다면 어떨까요?

데이브: 그래서 이것이 우리 디자인의 핵심 질문 중 하나였습니다. 제가 처음 슬림을 제안했을 때, 우리는 아바타를 연구하고 있었고 별도의 프로젝트도 진행 중이었거든요. 어떻게 하면 아바타 100개를 하나로 묶을 수 있을지, 그리고 경기장에 모인 10만 명의 사람들을 어떻게 시뮬레이션할지 고민하고 있었죠. 정말 흥미로웠던 날이 있었는데, 당신이 말했잖아요. '슬림 아바타를 활용해서, 똑같은 기술로 100개의 아바타를 하나의 집합체로 만들 수 있을지도 몰라.'

그게 바로 우리가 생각했던 부분이었죠. 그 계층적 구조에 정말 깜짝 놀랐잖아요? 

세르게이: 음, 네, 음, 정확히 맞아요. 이 예를 극단적으로 확장해 보면, 예를 들어 우리 가상 카메라가 지구 전체를 볼 수 있다고 생각해 보세요. 지구 전체가 마치 텍스처가 입혀진 구처럼 보이죠.

카메라가 가까이 다가오면 개별 대륙이 보이고, 그다음에는 개별 도시가 보이며, 결국 사람들로 가득 찬 경기장까지 내려갈 수 있어요. 왜냐하면 모든 시뮬레이션이 서버에서 실행되고 있어서 클라이언트는, 음, 전 세계에 대한 정보를 알 필요가 없거든요.

분명히, 아시다시피, 아무리 고성능 PC라 해도 이 행성 전체를 기기 메모리에 담을 수는 없잖아요. 하지만 저희 서버는 매우 강력하고, 이를 간결하게 표현하는 핵심 데이터를 생성함으로써, 행성 규모에서부터 방 규모, 심지어 마이크로 월드 수준까지 내려갈 수 있습니다.

데이브: 음, 맞아요. 우리나 당신이 차고 있는 시계 수준까지 내려갈 수도 있고, 시계의 작은 돌기 하나까지 들여다볼 수도 있고, 그보다 더 세밀한 수준까지 갈 수도 있겠죠. 그래서 이걸 생각해 보면, 사탄, 이게 창작자들이 하는 일을 어떻게 바꿀 수 있을까요? 맞아요. 우리는... 아, 이런, 아바타의 성능을 걱정해야 한다는 부담을, 바라건대 없앨 수 있게 될 거예요.

음, 그 외에 어떤 변화가 있을 거라고 생각하시나요? 

츠베탄: 제 생각에는, 이 기술이 오늘날 그들이 겪고 있는 모든 한계를 없애줄 거예요. 말씀하신 대로, 그들은 자신이 만들고 있는 세계가 얼마나 복잡한지에 대해 고민할 필요가 없어질 거예요. 그저 플레이어들에게 어떤 게임 역학을 보여주고 싶은지에 대해서만 생각하면 되죠.

그 외에는 아무것도 없어요. 나머지는 모두 저희가 자동으로 처리할 거예요. 

데이브: 그렇군요. 그 자동화 기능에 대해 좀 더 자세히 알아보는 것도 좋겠네요. 아시다시피, 예전의 전통적인 로블록스에서는 '텍스처 아틀라스'라는 방식을 사용했었죠. 실제로 텍스처용 템플릿이 있었고, 개발자가 직접 알아서 처리해야 했죠. 슬림 모델에서는 이 과정이 완전히 자동화될 거라고 생각해요.

음, 낮은 해상도에서 그 텍스처를 생성하는 것처럼요. 

츠베탄: 네. 그건 자동으로 처리될 거예요. 세르게이가 계층적 동적 세계에서 설명했던, 음, 빌딩 블록들을 결정하는 것뿐만 아니라요. 

데이브: 좋아요, 그럼 이제, 음, 이제 정말 놀라게 될 텐데, 음, 무언가가 더 단순해지는 건 상상하기 쉽잖아요?

마치 예술가라면, 어떤 식으로든 상상하기가 아주 쉬운 것과 비슷하죠. 더 투박하게 만들고 평면화하는 건 쉽지만, 해상도가 더 높아지는 건 상상하기가 훨씬 어렵잖아요. 그래서 저는, 음, AI의 미래에 대해 조금 짚어보고 싶은데요, 현재 AI 분야에서는 비디오 게임 생성, 실시간 몰입형 스트리밍, 월드 모델 등 다양한 연구가 활발히 진행되고 있습니다.

음, 그리고 저는 점점 더, 이것이 단일한 시스템이 아니라는 걸 알게 될 거라고 느껴요. 이건 3개, 4개, 5개, 혹은 6개의 모델이 모두 함께 작동하는 스택 형태가 될 거예요. 여기에는, 아시다시피, 우리가 4D에서 하듯이, 함께 있을 때 명령줄을 통해 간단히 말할 수 있는 기능도 포함되겠죠. 예를 들어, "워싱턴 기념비를 고질라로 바꿔줘"라고 말하면, 쾅, 바로 그 자리에서 일어날 거예요.

음, 그리고 궁극적으로는 오브젝트나 세계, 혹은 완성된 게임을 생성하게 될 거예요. 음, 가능하면 멀티플레이어 환경에서 말이죠. 그래서 우리 넷이서 함께 돌아다니면서, "이봐, 저기 봐"라고 말하며, 우리 넷이서 새로운 게임을 디자인하고, 그게 마법처럼 나타나게 할 수 있게 되는 거죠. 또 다른 측면이 있어요. 음, 방금 말씀하신 명령 프롬프트와 월드 생성, 3D 외에도, 음, 업샘플링이 있고, 그게, 음, 가끔 로블록스의 20년 된 게임인 클래식 크로스로드를 떠올려보면, 사실 거기엔 충분한 정보가 있어요.

만약 우리가 클래식 크로스로드(Classic Crossroads)를 가져와서, 세르게이 씨가 말씀하신 대로, 이걸 마치 사진처럼 사실적인 중세 버전으로 만들면 어떨까요? 게임플레이는 그대로 유지하면서요. 아시다시피, 그 재미난 작은 로켓 발사기 도구들 같은 건 모두 그대로인데, 갑자기 모든 것이 새로운 모습으로 바뀌는 거죠. 그럼 이런 맥락에서 어떻게 구현될 수 있을까요?

음, 누가 먼저 말씀해 주실지 모르겠네요. LOD에 대해서 말인데, 이제 LOD를 줄이는 게 아니라 늘려야 하니까요. 

바룬: 제 생각엔 세르게이가 아까 언급했던 요점 중 하나와 관련이 있는 것 같아요. 바로 향후 이런 작업을 할 수 있도록 원작의 예술적 의도를 최대한 많이 보존하는 거죠. 그리고 제가 가장 좋아하는 예시인데, 이건 그냥 무작위로 든 예시지만, 제가 텍스처를 사용하고 있다고 가정해 봅시다. 그런데 그 텍스처가 사실 누군가가 찍은 사진이라면, 제가 그 사진을 찍을 때의 조리개 값을 저장해 둔다면요.

크기, 그 사진을 찍을 때의 조리개 값을 저장했다면 말이죠. 그러면 제 'Uprising' 알고리즘이 훨씬 더 많은 맥락을 파악할 수 있게 되죠. 네. 그 텍스처가 어디에 사용되는지, 성에 사용되는 건지, 아니면 바닥에 사용되는 건지 안다면요? 제 'Uprising' 알고리즘은 고사양 PC나 아직 발명되지도 않은 미래의 PC에서 그 텍스처를 생성하고, 제작자의 원래 의도를 끝까지 유지하는 데 훨씬 더 똑똑해질 수 있습니다.

그래서 

데이브: RDC에서 이걸 시연했었죠. 제 기억엔 '크로스로드'가 업샘플링되는 15초짜리 영상을 보여드렸던 것 같아요. 음, 실제로 어떤 일이 일어날지 이야기해 볼까요? 자산, 즉 3D 오브젝트와 텍스처가 클라우드에 저장되어 있습니다. 음, 우리 콘텐츠 시스템으로 추가 프롬프트가 전송되는데, 그 내용은 '이 모든 자산은, 음, 상상할 수 있는 훨씬 더 사실적인 중세 세계의 일부여야 한다'는 것입니다.

그러면 그 모든 다양한 요소들이, 우리가 3D 업샘플러라고 부르는, 혹은 사실상 3D 생성형 크리에이터를 통해 포토리얼리스틱 버전에 훨씬 더 가깝게 재생성됩니다. 자, 그럼 예를 들어 성에 어떤 변화가 생길지 자세히 살펴볼 분 계신가요? 

세르게이: 저, 저, 제 생각에는 바론이 방금 언급한 것처럼, 아, 우리가 그 세계에서 훨씬 더 많은 의미적 정보를 포착하고 있는 것 같아요.

그게 정말 중요하죠. 예를 들어, 이 교차로 예시를 보시죠. 성을 보면요. 음, 개별 자산이라는 관점에서 보면, 그냥 블록 몇 개, 즉 상자일 뿐이에요. 맥락이 충분하지 않아서, 그 블록들을 더 멋지게 보이게 만들 수 없죠.

그리고 성은 그냥, 음, 개별 블록 그 이상이에요. 그것들의 총합이죠. 음, 그리고 슬림(Slim)은 이런 맥락에서 작동하니까, 슬림은 이걸 전체로서 인식해요. 그래서 이제 어떤 어셈블리든, 개별 자산이 아니라 성 전체에 대해 훨씬 더 많이 알게 될 거예요.

그래서, 그래서 훨씬 더... 음, 업샘플링된 그 성의 더 나은 버전을 만들 수 있는 거죠. 왜냐하면, 그게, 그냥, 그냥 그걸 이해하고 있으니까요. 

데이브: 음, 그리고, 어떤 의미에서는 기존에 있던 크로스로드 성이 없어도 상상할 수 있을 거예요. 참고로 크로스로드는 아주 오래된, 블록 모양이 두드러지는 로블록스 게임이에요.

그 성은 사실 '성 하나 지어줘'라는 프롬프트에 정말 좋은 참고 자료가 돼요. 저건 꽤 개방적인 프롬프트거든요. 무작위 모양의 성이 나올 수도 있으니까요. 하지만 크로스로드의 성, 특히 그 크기와 치수 같은 건, 고품질 성으로 업샘플링하는 데 정말 유용한 프롬프트 정보가 되죠.

세르게이: 음, 네. 음, 정확히 맞아요. 왜냐하면, 음, 음, 이 3차원적인, 음, 성의 구조 같은 건, 우선 게임플레이 관점에서 보면 정말 중요하잖아요? 그러니까 그냥 아무 성이나 생성해서 게임에 맞게 작동하게 할 수는 없는 거죠. 음, 왜냐하면. 하지만 모든 차원, 모든 의미론, 모든 맥락, 즉 그 세트가 사용된 상황을 포착할 수 있다면, 매우 효율적으로 업샘플링할 수 있습니다.

그리고, 이렇게 해도 게임이 망가지지는 않을 거예요. 왜냐하면, 또 다른 매우 중요한 점이 있거든요. 게임을 플레이할 수 없게 만들 수 있는 자산을 업샘플링하고 싶지는 않을 테니까요. 

데이브: 음, 글쎄요, 제 생각에는 모든 3D 정보에 더해, 3D 정보를 편집하거나 프롬프트를 편집할 수 있는 미래의 세계가 있을 것 같아요.

이 두 가지가 결합되어 그 세계를 생성하게 될 거예요. 그래서 우리가 이야기했던 5초 업데이트, 즉 미래의 자산 수정 작업은 5초짜리 프롬프트 업데이트와 프롬프트에 담긴 약간의 힌트로 대체될 수도 있겠죠. 그리고 필요에 따라 그 세계를 지연 로딩 방식으로 생성하는 거죠. 그리고, 음, 마지막으로 한 가지 더 생각해보면, AI가 어떻게 결합되어 이런 것들을 사실적으로 구현할 수 있는지에 대한 모든 차원을 고려할 때, 우리는...

거기, 마지막 레이어가 하나 더 있는데, 바로 2D 레이어입니다. 여러분의 게이밍 PC에서는 어떤 일이 일어나고 있을까요? 더 높은 수준의 업샘플링이 발생할 수도 있는 클라우드상의 비디오 어플라이언스에서는 어떤 일이 벌어질까요? 예를 들어, 제 머리의 완벽한 머리카락을 생각해 봅시다. 그 머리카락을 처리하기에 가장 좋은 곳은 2D 업샘플러를 사용하는 로컬 환경일 수 있습니다. 제가 알기로는 3D로 머리카락을 구현하려는 많은 게임 작업을 해오셨죠.

어떻게 생각하시나요? 언젠가는 모든 머리카락이 2D 업샘플링으로 처리될까요, 아니면 3D 머리카락이 될까요? 

세르게이: 네, 물론이죠. 제 생각엔 우리가 그런 방향으로 나아가고 있는 것 같아요. 왜냐하면 어떤 것들은 스크린 스페이스에서만 처리할 수 있고, 그게 더 효율적이거든요. 이렇게 말해볼게요, 스크린 스페이스에서 처리하는 게 더 효율적이에요.

예를 들어, 음, 머리카락 렌더링 같은 거 말이죠. 그래서, 아니면... 요즘 많은 게임 엔진들이 머신러닝(ML) 기반의 업샘플링을 하고 있잖아요. 1080p에서 4K로 업스케일하는 식으로요. 하지만 그보다 훨씬 더 많은 걸 할 수 있잖아요? 셰이딩을 바꿀 수도 있고, 사물의 외관을 바꿀 수도 있고요.

이 예를 극단적으로 가져가면, 게임 엔진이 단순히 어떤 의미론적 정보를 렌더링하고, 이를 ML 알고리즘에 입력하면, 그 알고리즘이 멋진 머리카락이나 멋진 재질을 생성해 낼 수도 있겠죠. 마치 스크린 스페이스에서 지시어를 사용하는 것처럼요.

데이브: 정말 훌륭하네요. 음, 그럼 이제 마무리하면서, 여기 계신 모든 C++ 프로그래머분들과 어셈블리 언어 프로그래머분들을 위해 말씀드리자면, 음, 저도 그랬으면 좋겠네요. 그건 세상에서 가장 재미있는 일 중 하나니까요. 우리는 여기서 정말 어려운 일을 하고 있는 거죠? 우리는 이 모든 기술을 모든 기기에서 실행되도록 만들려고 노력하고 있잖아요.

트랜스코딩에 대한 질문입니다. 트랜스코딩에 관한 질문인데, 많은 PC가 SIMD 레지스터 같은 걸로 최적화를 해서 이런 작업들을 더 빠르게 처리한다는 걸 알고 있습니다. 저희 트랜스코더 중 어느 것에서든 SIMD를 활용해 본 적이 있나요, 아니면 향후 최적화 계획인가요? 

츠베탄: 음, 우선 말씀드리자면, 트랜스코딩은 현재 엔진에서도 실행될 수 있습니다.

네. 훌륭하네요. 좋습니다. 그러니까 우리는 CMD 최적화를 활용하고 있지만, 그보다 더 나아가 GPU와, 음, 다른... 

데이브: 트랜스코딩 말이군요. 알겠습니다. GPU 기반 트랜스코딩이 도입될 가능성이 있군요. 

츠베탄: 네, 맞아요. 현재 검토 중입니다. 

데이브: 알겠습니다. 정말, 정말 흥미로운 일이네요. 자, 그럼, 음, 모두에게 좋은 소식입니다. 음, 음, 시각적인 자료를 원하시는 분들을 위해, 아마 RDC 메인 스테이지 프레젠테이션에서 다룰 수 있을 것 같습니다.

제 생각엔, 이 중 많은 부분에 대한 시각 자료가 있었으니, 그렇게 해야 할 것 같아요. 우리가 이야기한 모든 내용은 현재 진행 중입니다. 음, 저희는 이를 주의 깊게 지켜보고 있고, 저는 정말로, 음, 여러분 모두와 여러분 뒤에 있는 다양한 팀들이 제가 가끔 '게임 엔진 2.0'이라고 부르는, 클라우드에 크게 의존하는 기술에 정말로 기여하고 있다고 생각합니다.

이 모든 기술에서 트랜스코더의 강력한 지원을 받고 있습니다. 여러분 모두 감사합니다. 오늘 우리는 모두를 놀라게 한 것 같습니다. 정말 감사합니다. 

츠베탄: 감사합니다. 

데이브: 자, 안녕하세요. 데이브입니다. 음, 다시 한번 테크 토크였습니다. 다음 시간에 뵙기를 기대하겠습니다. 팀 전체를 대표해 감사드립니다. 감사합니다.