[KOR][30]Integrated-Insights--Automating-Performa

질문이 있으시면 모두 적어 주시기 바랍니다. 행사 마무리 무렵에도 질문하실 수 있도록 저희가 자리를 지킬 예정입니다.

"Marvel 1943 Rise of Hydra'의 Performance Capture 자동화 및 인사이트 통합"이라는 제목의 발표를 시작하도록 하겠습니다.

저는 Virtuos의 엔지니어링 디렉터 Marios입니다. 저희 스튜디오 Black Shamrock의 테크니컬 디렉터인 Steven과 함께 이 자리에 섰습니다.

오늘 우리는 continuous monitoring이 optimization 및 performance 접근 방식을 어떻게 transform 할 수 있는지 논의하고자 합니다.

Skydance Games와의 협업을 통해 얻은 학습 내용과, 특정 난관을 해결하기 위해 툴이 어떻게 발전했는지 공유하겠습니다.

본 강의를 통해 유사한 시스템을 구축하는 방법과 이를 여러분의 프로젝트에 어떻게 적용할 수 있는지에 대한 아이디어를 얻어가시기를 바랍니다.

Virtuos에 대한 간략한 정보입니다. 저희는 규모가 큰 코드 개발 회사로서 다양한 팀과 개발 방식에 노출되어 있습니다. 1,500개 이상의 게임에 참여했으며, 최근에는 Oblivion Remastered를 출시했습니다. 지금까지 경험한 바로는 Stability tracking이 프로젝트 전반에 걸쳐 상당히 일반적인 것으로 보입니다.

성능 추적이 지연되고 있는 상황입니다. Marius가 언급했듯, 저는 Technical Director입니다. 제가 이 직업에서 가장 좋아하는 것 중 하나는 정말 흥미로운 기술들을 공유할 수 있다는 점입니다.

저희 팀이 작업하고 구축하는 것들을 보여드리겠습니다. 오늘 그 내용을 공유하고자 합니다. 몇 가지 툴(tool)을 소개할 예정입니다.

저희가 얻은 몇 가지 학습 내용을 공유하고자 합니다. 이를 통해 여러분께서 각자의 프로젝트에 performance monitoring을 어떻게 적용할지에 대한 생각에 작은 변화를 드릴 수 있기를 바랍니다.

참석하신 분들의 소개로 시작하도록 하겠습니다. 혹시 에너지가 넘치신다면, 손을 들어 질문에 답해주십시오. 프로젝트를 진행하며 이러한 말들을 들어보신 경험이 있으신 분이 계십니까?

아마 여러분께서도 직접 사용해 보셨을 것이라 생각합니다. 현재는 다소 미흡한 부분이 있지만, 콘텐츠가 확정되면 최적화 작업을 진행할 예정입니다. 현재 몇 가지 문제점이 있습니다. Frame rate가 저하되고 있으나, 우선은 기능 구현에 집중할 것입니다.

검색 제출 전에 이 문제를 처리해야 할 것입니다. 그것이 바로 유명한 마지막 말이 될 것입니다.

여러분께서도 프로젝트에서 이러한 (기술)을 접하신 분들이 계신 것을 알겠습니다. 이는 저희의 모든 codec project 경험과도 매우 일치합니다. 이를 통해 개발자들이 어떻게 접근하는지를 폭넓게 확인할 수 있었습니다.

솔직히 말씀드리면, performance는 늘 어려운 문제입니다. 따라서 저희는 production cycle 전반에 걸쳐 performance를 염두에 두고 이 문제를 미리 해결하고자 합니다.

하지만 조기 최적화가 모든 악의 근원이라는 말씀을 들으셨을 것입니다. 이는 컴퓨터 과학 분야에서 저명하신 Donald Knuth(도널드 커누스)가 한 말입니다. 그는 이 분야의 대가이며, 관련 서적을 다수 집필하셨습니다.

저는 여러분 앞에 서서 다른 이야기를 할 자격이 없습니다. 하지만 여러분께, 혹은 적어도 저에게는 좋은 소식이 있습니다. 저는 Newt가 이 대화에서 처음부터 우리 편이었다고 생각합니다. 이 인용구는 'Structured Programming'이라는 책에서 발췌되었습니다.

GoToStatements를 사용하며, 이는 다소 시대가 느껴지는 부분입니다. 하지만 해당 서적을 자세히 살펴보고 Newt가 말한 내용을 좀 더 깊이 분석하면 명확해집니다. Newt는 프로그램에서 중요하지 않은 코드의 속도에 대해 프로그래머들이 과도하게 시간을 낭비한다고 말했습니다. 따라서 대부분의 경우 사소한 효율성에 집착하지 말아야 합니다. 왜냐하면 성급한 최적화(premature optimization)는 모든 악의 근원이기 때문입니다.

하지만 그는 훌륭한 프로그래머라면 중요하다는 critical code를 파악한 후에는 해당 코드를 면밀히 살펴봐야 한다고 말합니다. 1974년에 출판된 이 책은 오늘날에도 여전히 유효하다고 생각합니다. 또한, 복잡성이 엄청나게 증가했음에도 불구하고, 우리 코드의 performance를 이해하는 것은 여전히 대부분 수동적인 과정이며, 시간이 지나도 크게 변하지 않았다는 사실도 진실입니다.

우리의 툴은 개선되었으나, 개발 과정 자체는 크게 다르지 않습니다. 그렇기에 개발 주기 전반에 걸쳐 Performance Tracking을 옹호하는 이유가 무엇이겠습니까? 변화가 필요하다고 생각합니다. 핵심은, Critical Code에서 Performance Issue를 식별하는 과정을 자동화할 수 있다면, 프로젝트의 적절한 시점에 최적화할 수 있는 가시성을 확보하게 된다는 것입니다. 그렇다면 어떻게 이것이 가능할까요?

저희는 당연히 툴을 개발하고 있습니다. 보여드릴 내용의 간단한 미리보기입니다. 여러분의 프로젝트에 대한 상세한 metrics를 이해하고, 게임 전반에 걸쳐 핵심 health를 유용한 방식으로 시각화할 수 있도록 하는 것을 목표로 합니다.

프로젝트 전반에 걸쳐 시간 경과에 따른 성능을 추적합니다.

본 발표는 여섯 개 섹션으로 구성됩니다. 우선, 최적화에 대한 접근 방식이 '반응적(reactive)'에서 '능동적(proactive)'으로 변화하는 사고방식에 대해 논하겠습니다. 이어서 Skydance와의 협업 경험과 'performance'를 최우선으로 고려하는 방안에 대해 말씀드리겠습니다.

Goliath를 구성하는 주요 컴포넌트와 여러분의 프로젝트에 적용할 수 있는 아이디어에 대해 논의하겠습니다. 주요 기능 중 하나인 Unreal Insights와의 통합에 대해 자세히 살펴볼 것입니다. 더불어 해당 툴의 향후 발전 방향을 조망하고, 마지막으로 종합적인 의견을 제시하며 마무리하겠습니다.

본 발표에서는 프로젝트 최적화에 대한 여러분의 인식을 변화시키고자 합니다. 저희의 아이디어를 공유하고, 더 나아가 지속 가능한 개발 환경을 조성하고자 합니다. 이는 모든 게임 개발자에게 더 나은 경험을 제공하고, 궁극적으로는 게임의 재미를 찾는 데 더 많은 시간을 할애하실 수 있도록 돕기 위함입니다.

최적화 문제들에 대해 고민하기보다는, 지금은 예시를 들어보겠습니다.

프로덕션이 시작되고 다양한 기능이 추가되며, 프로덕션 단계가 깊어집니다. 새로운 렌더링 기술, AI 로직, 리워크 작업, 다수의 에셋이 지속적으로 투입됩니다. 이때 성능 저하가 점진적으로 발생하지만, 기술 부채는 숨겨진 채 빙하 아래에 잠겨 있습니다. 사소한 FPS 드랍과 끊김 현상이 나타나며, 이 모든 것이 문제의 징후입니다.

더 깊이 살펴보면, Poor Thread Utilization, 올바르지 않은 Memory Allocators, 비효율적인 Asset Streaming 등이 발견될 수 있습니다. 이러한 문제들은 프로덕션 후반으로 갈수록 수정 비용이 기하급수적으로 증가합니다. 따라서 Performance는 단순히 효율성뿐만 아니라 Stability와 Predictability를 확보하는 것과도 직결됩니다. 특히 Alpha나 Beta 단계에 진입했을 때, 미래를 내다보는 가시성 확보가 중요합니다. Stephen이 이미 질문했듯이, 여러분의 프로젝트 중 얼마나 많은 수가 최적화를 너무 늦게 고려하여 어려움을 겪었습니까?

저희는 게임 플레이를 심각하게 저해하는 버그가 포함된 게임을 출시하지 않습니다. 이는 저희가 매우 중요하게 여기는 부분입니다. 그렇다면 최적화(optimization)는 왜 위험을 감수하면서 진행해야 할까요? 따라서 여기서 진정한 과제는 개발 초기 단계부터 나중에 발생할 수 있는 문제들을 어떻게 예측하고 대비하느냐입니다.

개발자로서 우리는 시인이 아닙니다. 따라서 문제점을 조기에 발견하고 신속하게 수정해야 합니다. 이를 통해 프로젝트의 위험을 크게 줄일 수 있습니다. 팀원들의 스트레스를 완화하고, 다른 중요한 부분에 집중할 시간을 확보할 수 있습니다.

해당 feature dev 과정에서 처음부터 visibility를 확보할 수 있습니다. 이를 통해 나중에 발생하는 avalanche of bugs를 피할 수 있습니다. 혹은 적어도 해당 avalanche of bugs에 대한 visibility를 가지고 이에 맞춰 계획을 세울 수 있습니다. 따라서 performance를 stability처럼 다루십시오.

일상적인 프로세스에 **bake it into your daily processes** 해 두시면, 예측 불가능한 상황이 줄어들어 더욱 원활한 프로덕션 사이클을 경험하실 수 있습니다.

Codev는 수많은 프로젝트들의 어려움과 반복되는 문제들을 직면해 왔습니다. 이러한 문제들을 해결할 방안을 모색하고자 합니다. 이를 위해 세 가지 관점 또는 세 가지 핵심 사항으로 구조화하였습니다. 첫째, 모든 것을 관리할 단일 대시보드를 구축하는 것입니다.

모든 사람이 접근할 수 있는 단일 진실 공급원(single source of truth)이 존재합니다. 여기저기 흩어진 보고서나 각기 다른 커스텀 툴 없이 모든 정보가 한곳에 통합됩니다.

두 번째로, Performance는 정적이지 않고 시간에 따라 변화합니다. 따라서 Performance를 추적하고, 변경 사항에 대한 관계, 원인 및 결과를 이해하는 것이 중요합니다.

마지막으로, Efficiency와 Consistency를 확보할 수 있습니다. 반복적인 작업을 줄여 엔지니어에게 프로파일링이나 캡처를 요청하는 과정을 생략할 수 있습니다.

자동화함으로써 모든 것이 쉬워지고 항상 이루어집니다. 이를 통해 Goliath가 탄생했습니다. 프로젝트의 이 시점에서 저희는 다양한 사람들과 협력해왔습니다.

저희는 구현하고자 하는 MVP(Minimum Viable Product)를 확보하였으며, 이러한 제품으로 나아가고자 하는 방향에 대한 이해도 또한 갖추고 있습니다.

이것의 핵심 기둥들을 적어도 파악하고 있었습니다. 저희는 여러 스튜디오와 팀에서 겪는 어려움들을 목격했기에, 이 아이디어가 실현 가능성이 있다는 것을 알고 있었습니다. 하지만 이 단계에서는 이를 실제로 구현할 적절한 파트너가 필요했습니다. 저희는 바로 이때 이 팀과 연락을 주고받기 시작했습니다.

Skydance Games는 저희와 유사한 Performance Monitoring에 대한 사고방식을 공유하고 있었습니다. 그들은 이미 같은 방식으로 이를 고려하고 있었으며, Feature Development와 함께 Performance Monitoring 및 Tracking의 가치를 잘 이해하고 있었습니다.

더욱이, 이들은 일회성으로 자체 도구를 구축하는 데 그치지 않고, 다른 팀과 커뮤니티 전체에 이익이 될 수 있는 도구를 함께 만들어가는 협업 아이디어를 적극적으로 수용했습니다. 이러한 협력이 있었기에 이 모든 과정이 가능했습니다.

이 영상이 재생되기를 바랍니다.

지붕 위만 이용하십시오. 조심하십시오. 제가 있었던 곳은 제게로 향하고 있었습니다. 제가 언제부터 그랬던가요?

이 부분은 제가 혼자 처리하는 것이 좋겠습니다. 당신은 누구이십니까? 거기까지만 하십시오. 제 앞을 막지 마십시오. 자, 게임의 짧은 맛보기였습니다만, 멋지지 않습니까?

작년 언리얼 페스트 또는 스테이트 오브 언리얼 행사에서 이 영상을 보셨기를 바랍니다. 당시 짧은 클립만으로도 다음과 같은 점을 확인할 수 있었습니다.

이 게임은 AAA급 시네마틱 경험을 선사합니다. 액션으로 가득하며 창의적으로 과감한 시도를 보여줍니다. 기술적인 측면에서는 Unreal Engine의 한계를 뛰어넘고 있습니다. 최신 기능을 활용하여 게임 출시 시점에 필요한 모든 순간, 모든 컷씬, 모든 액션 연출을 구현하고 있습니다.

이는 저희 접근 방식을 테스트하기에 완벽한 환경입니다. 높은 수준의 결과물을 요구하며, 팀은 시각 및 게임플레이의 기준을 끊임없이 높여가고 있습니다. 이러한 상황에서 Performance는 부차적인 고려 사항이 될 수 없습니다. 개발 첫날부터 내재되어야 합니다.

이제 Rise of Hydra 제작 과정에 Performance Tracking을 어떻게 통합했는지 살펴보겠습니다. 영상을 다시 재생해 보겠습니다.

성능 파이프라인 구축 시, 게임의 주요 지점에서 상세한 성능 데이터를 지속적으로 수집할 방안이 필요했습니다. 임시방편적인 테스트에 의존하는 대신, 개발 전반에 걸쳐 일관되게 실행할 수 있는 구조화되고 자동화된 접근 방식을 원했습니다. 이를 설정하는 데는 네 가지 핵심 단계가 포함됩니다.

첫 번째 단계는 성능이 매우 중요한 게임의 핵심 부분을 파악하는 것입니다. 이러한 순간들은 반드시 안정적이어야 합니다. Cinematic, 격렬한 Gameplay, 복잡한 Lighting, 고밀도 Scene 등이 이에 해당합니다. 이는 단순한 기술적 접근 방식만이 아닙니다. Design, Art, Animator 등 게임의 어느 부분이 가장 큰 부하를 받을지 아는 모든 사람들의 의견을 경청해야 합니다.

예를 들어, 트레일러에 나온 다리 Scene을 살펴보겠습니다. Captain America와 Black Panther가 충돌하는 장면으로, 시각적으로 강렬하며 Gameplay에서도 매우 중요한 순간이므로 완벽하게 실행되어야 합니다. 이 Scene을 핵심적인 순간으로 선정하고 표시하여 추적합니다. 초기 빌드부터 Production 종료 시점까지 말입니다.

여기 레이저 포인터가 있다면 이 작은 캡슐을 주목해 주십시오. 곧 다시 돌아올 것입니다. 물론 이와 같은 게임에는 성능 요구 사항이 많은 대상들이 있습니다. 넓은 Draw Distances를 가진 옥상 Scene 등도 포함됩니다.

빠른 템포의 액션과 매우 상세하고 조명 효과가 뛰어난 캐릭터들을 구현하였습니다. 또한, 전용 테스트 환경을 위한 자동화 및 테스팅 설정에 가치가 있습니다. AI, 물리, 조명을 통제된 공간에서 격리하여 테스트하는 것 등이 포함됩니다.

핵심은 게임의 주요 영역에 대해 광범위하면서도 목표가 명확한 프로파일을 구축하는 것입니다. 현실적으로 모든 시점에 게임 전체를 프로파일링할 수는 없으므로, 정말 중요한 부분에 집중하고 있습니다.

시간이 지나도 일관되고 반복 가능한 측정값을 확보하며 체계적인 방식으로 이를 수행하고 있습니다.

관심 지점을 정의한 후에는 이를 레벨에 직접 체크리스트로 설정합니다. 방금 설명드린 캡슐이 레벨에 바로 삽입되는 방식입니다. 각 체크포인트는 게임 내에서 특정 위치를 표시하며, 해당 위치에서 성능 데이터를 캡처하고자 합니다. 체크포인트는 다른 레벨 요소와 동일하게 배치됩니다. 위치, 바라보는 방향, 그리고 캡처할 시간(duration)이 지정됩니다.

이 사항들을 고려하셔야 합니다. Checkpoints는 playlists로 묶이게 되며, playlists는 필요에 따라 트리거할 수 있는 논리적인 그룹입니다. 중요한 점은 이 방식이 lightweight하고 invasive하지 않으며, 쉽게 적용하고 유지 관리할 수 있다는 것입니다.

체크포인트가 설정되면 전체 프로세스를 자동화합니다. 새로운 빌드가 생성될 때마다 동일한 씬을 거치며 같은 체크포인트와 데이터를 캡처합니다. 이는 전적으로 자동화되어 수동 작업이 필요 없습니다.

개발자에게 추가적인 절차는 없습니다. 테스트 실행을 잊을 가능성도 사라집니다. 시스템은 그저 작동할 뿐입니다. 그리고 매번 동일하게 작동하기에, 기존의 의문점이었던 performance capture 문제는 피할 수 있습니다. debug build였는지 production이었는지, 혹은 physics tweak를 되돌렸는지, 심지어 camera 방향은 제대로 맞춰졌는지 등의 고민을 할 필요가 없습니다.

이전에 performance capture를 진행했을 때 프레임 안에 있던 바로 그 나무 말입니다. 이러한 일관성은 데이터를 신뢰할 수 있다는 것을 의미하며, 이는 잡음이 아닌 실제 추세를 파악할 수 있게 해 줍니다.

이러한 시스템의 가치는 해당 데이터가 지속적으로 검토될 때 비로소 실현됩니다. Skydance에서는 여러 팀이 이러한 대시보드에서 과거 성과 트렌드를 모니터링하고 있습니다.

이러한 데이터를 기반으로 task를 할당합니다. 일부 팀은 주간 단위로 key performance를 확인하고, 다른 팀은 특정 문제가 발생했을 때 trend를 심층 분석합니다. 어떤 방식이든, 수동 데이터 수집 과정 없이도 data를 항상 활용할 수 있다는 점이 핵심 이점입니다.

이것이 본 접근 방식을 진정한 game changer로 만드는 이유입니다. 우리는 reactive approach에서 proactive approach로 전환하여, production 전반에 걸쳐 performance가 모니터링되고 최적화되도록 보장하고 있습니다.

이것이 전체적인 아이디어입니다. 그렇다면 실제로 이것이 어떻게 구현될까요? 저희의 툴인 Goliath(이름을 언급했는지 확실치 않으나, Goliath라고 명명했습니다)는 시각적이고 직관적이며 즉시 활용 가능하도록 만들고자 했습니다.

성능 엔지니어든 프로젝트 현황을 확인하는 프로듀서든 관계없이, 여러분에게는 프로젝트 전반을 한눈에 혹은 심층적으로 파악할 수 있는 간결하고 풍부하며 접근하기 쉬운 정보가 필요합니다. 이제 그 모습이 어떠한지 살펴보겠습니다.

이 화면은 게임의 개괄적인 정보를 보여주는 High-level overview screen입니다. 이 화면은 'Rise of Hydra'의 실시간 맵이 아니라, 'Goliath'의 일반적인 예시임을 명확히 말씀드립니다. 게임을 함께 보기 전까지는 공유해 드리기 어렵지만, 구조는 동일합니다.

화면 오른쪽에는 활성화된 체크포인트(active checkpoints)를 나타내는 맵이 있습니다. 파란색은 예산 내에 있음을, 노란색은 예산 초과에 가까워짐을, 빨간색은 예산을 초과하여 조치가 필요함을 의미합니다. 이는 게임의 현재 상태를 즉각적으로 파악할 수 있도록 돕습니다.

무언가 빨간색으로 표시되면 어디를 봐야 할지 정확히 알 수 있습니다. 프로젝트 전반의 문제를 즉시 파악할 수 있습니다. 좌측 상단에서는 씬의 추가적인 metadata를 추적하며, 그 아래로는 주요 performance metrics의 breakdown을 볼 수 있습니다. Render, game thread 등이 포함됩니다. 중요한 점은 profiler를 열 필요가 없다는 것입니다.

이 툴은 웹 프론트엔드로 제작되어 모든 부서에서 접근 가능합니다. QA, 리드, 프로듀서 등 게임의 현재 상황과 추세를 확인하고 싶은 누구나 이 툴을 사용할 수 있습니다. 별도의 커스텀 툴 설치 없이 사용할 수 있다는 장점이 있습니다.

다음은 디버그 스크린샷입니다. 언리얼 엔진에서 퍼포먼스 캡처 작업을 해보신 분이라면 익숙한 장면일 것입니다. 표준적인 언리얼 디버그 뷰로, 오버드로우 히트맵, 복잡도, 라이팅 버퍼 등을 포함합니다. Golight는 각 체크포인트마다 이 모든 것을 자동으로 캡처합니다.

이 기술의 강력함은 체크포인트에서 다른 모든 데이터 및 메트릭과 함께 캡처된다는 점입니다. 단순히 시각 정보만을 얻는 것이 아니라, 전체 캡처 지점의 맥락 속에서 이를 파악할 수 있습니다. 이 상관관계가 중요합니다. 성능이 급증할 때 체크포인트를 불러와 어떤 메트릭, 어떤 장면, 그리고 어떤 시각적 변화가 성능 급증을 야기했는지 확인할 수 있습니다.

Goliath는 시각적 기록을 저장하므로, 빌드 간 해당 데이터를 추적하고 성능 트렌드와 직접 비교할 수 있습니다. 이 모든 것을 한 곳에서 확인할 수 있습니다.

이제 Goliath의 좀 더 심층적인 분석 단계에 들어가 보겠습니다. 초기에는 기본적인 CSV profiler 데이터를 활용하여 주요 스레드 및 시스템의 최소, 최대, 평균 프레임 시간을 확인했습니다. 단순하지만 효과적인 접근 방식이었습니다. 이 단계를 통해 변화를 시각화할 구조를 확보할 수 있었습니다.

하지만 이를 실제 프로덕션에 적용하면서 한계점을 발견했습니다. 근본적인 원인과 문제를 디버깅하는 데 필요한 데이터의 깊이가 부족했던 것입니다. 결국 생태계 데이터를 통합하지 못하고 하나의 대시보드라는 초기 목표를 달성하지 못하게 되었습니다. 이러한 문제점을 해결하기 위해 첫 번째 주요 업데이트로 Insights 통합을 진행하게 되었습니다. 이 부분은 나중에 다시 자세히 다루겠습니다.

Damaris가 언급한 또 다른 핵심 요구사항은 시간에 따른 추적 기능입니다. 이는 선택 사항이 아니라 이러한 도구에 필수적인 기능입니다. Goliath는 Unreal Insights에서 수집된 데이터를 기반으로 빌드별 주요 지표를 플로팅하고, 이를 'event groups'라고 부르는 그룹으로 묶습니다. 이는 방대한 Insights 데이터의 의미를 파악하기 위한 내부적인 방식입니다.

조금 있다가 더 자세히 살펴보겠습니다. 여기서 핵심 목표는 간단합니다. 초기에 친구들을 초대하여 문제의 정확한 시작점을 확인하고, 해당 변경 사항과 프로젝트를 연결하는 것입니다. 만약 performance가 감소하면, 추측하는 대신 곧바로 graph로 이동하여 spike를 찾고, 그것이 발생시킨 build와 system까지 추적할 수 있습니다.

이러한 가시성은 신속한 대응을 가능하게 하며, 진정으로 중요한 곳에 노력을 집중하도록 합니다. 또한, 기존 툴을 대체하려는 의도는 없습니다.

이 도구들은 매우 훌륭하며 저희 모두 사용하고 있습니다. 그래서 저희는 이러한 도구들과 함께 작업하고 싶습니다. Goliath에서 의심스러운 점을 발견하면, 해당 Unreal Insights trace file로 바로 이동할 수 있습니다. 버튼을 클릭하여 Utrace를 다운로드하고 Insights에서 열면 됩니다. 어떤 trace file이 일치하는지, 어떤 checkpoint인지 추측할 필요가 없으며, 누군가가 capture를 실행하고 spike를 얻기를 바라는 일도 더 이상 없을 것입니다.

대시보드의 Red Flag에서 Insights, Insights tooling, Unreal Zone tooling으로 끊김 없이 바로 이동하실 수 있습니다. 이것이 바로 이러한 시스템의 진정한 힘이 발휘되는 지점입니다. 전체적인 명확한 뷰에서 세부적인 로우레벨 디테일까지, 모든 것을 하나의 통합된 워크플로우 안에서 경험하실 수 있습니다.

이러한 접근 방식의 명확성으로 얻게 되는 변화에 대해 이야기해보겠습니다. 먼저, 근본 원인을 격리하는 것에 대해 말합니다.

PC Gamer에 게재된 재미있는 기사를 접했습니다. Skyrim 개발자 중 한 분이 게임 내 특정 지역에 개미를 추가하고 싶어했는데, 이는 게임에 깊이를 더하는 훌륭한 아이디어였습니다. 하지만 각 개미가 그림자를 드리우는 바람에 해당 지역의 performance가 크게 저하되었습니다.

이처럼 structured tracking 없이 개발이 진행되면, 이러한 변경 사항은 수일, 수주간 발견되지 않을 수 있습니다. 문제가 감지되어 조사할 때에는 이미 모든 맥락이 사라지고 처음부터 다시 시작해야 하는 상황이 발생합니다.

이제 Goliath를 활용하는 시나리오를 상상해 보십시오.

해당 지역의 checkpoint는 answer 추가 후 변경 사항을 감지합니다. 다음 날, red flag를 확인하고 data를 점검하면 비교적 짧은 변경 목록에서 누군가 ads 작업을 했는지 확인할 수 있습니다. 이를 검토하여 문제를 해결합니다. 이 feedback loop는 일주일이나 한 달이 아닌, 하루 만에 완료됩니다.

두 번째 이점은 본인이 작업한 결과물의 영향을 평가할 수 있다는 점입니다. 개발자들은 기능 구현에 집중하고 싶어하며, 특히 기능 개발 초기 단계에서는 성능에 대한 지속적인 걱정을 하고 싶어 하지 않습니다. 따라서 저희는 이 과정을 쉽게 만들었습니다. 코드를 체크인하면 Goliath가 다음 자동화 작업을 진행합니다.

데이터가 준비되면 대시보드를 빠르게 확인합니다. frame time이 폭증하지 않았습니까? 그렇다면 좋습니다. 업무를 계속 진행할 수 있습니다. 이는 workflow의 사소한 변화지만 강력합니다. performance 이해에 대한 friction을 제거하고, 일상 workflow의 자연스럽고 effortless한 부분으로 인식을 가져옵니다. costly한 작업을 commit할 때, late-stage 위험한 optimization problem으로 눈덩이처럼 불어나기 전에 조기에 수정할 수 있습니다.

모든 팀원이 동일한 data point를 기준으로 작업할 때 collaboration이 극적으로 향상됨을 발견했습니다. "오늘 좀 느린 것 같은데"와 같이 막연한 표현 대신, lead는 "checkpoint가 빨간색으로 변했어. 한번 살펴봐 줄래?"라고 직접적이고 actionable하게 지시할 수 있습니다. 이는 시간 절약에 크게 기여합니다.

And once the team sees the value in that and they start engaging, you know, QA flags an issue. Designers have a way to share their concerns. Engineers have threads to pull on and explore. The whole team rallies around that shared data instead of assumptions and blame and all of the other negative things that come along with this. It's not just delegation, it's a better conversation,

it's better decisions and a smoother path to fixing those problems together. And finally, there comes tracking all that weird stuff that just happens in the game sometimes.

간헐적으로 발생하는 문제들이 있습니다. 가끔 발생하는 히치(hitch)나 스파이크(spike) 말입니다. 수동 테스트로는 이를 놓치기 쉽고, 일회성으로 치부하거나 제한된 테스트 데이터에 기반하여 우연한 현상에 과민 반응할 수도 있습니다. 하지만 데이터를 꾸준히 캡처한다면,

패턴이 시각화되면, 산발적인 현상이 언제 시작되었는지, 얼마나 자주 발생하는지, 그리고 악화되고 있는지 정확히 파악할 수 있습니다. 이를 통해 실제 문제와 노이즈를 구분하고, 시스템적인 문제의 본질을 이해하고 식별하는 데 도움이 됩니다.

Goliath를 제작할 때

본 시스템은 모듈식으로 설계되었으며, 엔진 agnostic합니다. 시스템의 한계를 테스트함에 따라 필요에 따라 교체 가능한 표준 컴포넌트들이 존재합니다. 이는 저희의 개발 철학이며, 실제 적용 시에는 프로젝트의 특성과 목표에 따라 결과가 달라질 수 있습니다. 이제 프론트엔드 부분부터 살펴보겠습니다.

Blazor 기반의 웹 애플리케이션으로, accessibility를 위한 솔루션입니다. 설치나 버전 동기화가 필요 없으며, 표준 보안을 유지할 수 있어 IT 부서에서도 만족할 것입니다. 유연한 tech stack 또한 장점입니다.

As we've made Goliath more robust over time, we really started to reach the limits of the frontend that we chose. However, since we took this modular approach, we can move it over to another frontend as needed, such as Grafana. Then there's the UE5 plugin. This is what's used to collect the data by automatically capturing the performance metrics.

개발자들은 test points를 배치하고, 이를 통해 static scenes, gyms, action sequences 등 원하는 장면을 캡처할 수 있습니다. Cinematics, VFX 등 모든 것이 가능합니다. 이 plugin의 가장 큰 장점은 game assets 수정이 필요 없으며, 모든 test points가 자동으로 처리된다는 점입니다.

다음은 **cruncher**입니다. 이는 Unreal Engine ecosystem과 외부 프로세스 간의 다리 역할을 합니다. raw data captures를 받아 structured data로 변환합니다.

본 C# standalone executable은 frame time fluctuations, memory usage trends, rendering performance bottlenecks 등의 주요 지표를 자동으로 정리합니다. 이를 통해 performance data가 신속하게 처리되도록 보장합니다.

새로운 빌드가 배포되면, cruncher는 모든 test point를 처리하고 dashboard를 업데이트하여 performance bottleneck을 거의 실시간으로 확인할 수 있습니다. 더 이상 수동으로 profiling할 필요가 없습니다. 이제 backend를 살펴보겠습니다.

이것은 캡처된 모든 데이터를 관리하는 역할을 합니다. ASP.NET 기반으로 구축되었으며 MongoDB를 활용하여 수집된 모든 데이터의 구조화되고 효율적인 저장을 보장합니다. 사용자가 원하는 방식으로 구축할 수 있습니다. 주요 책임은 플러그인으로부터의 API 요청을 처리하는 것입니다.

성능 데이터를 저장하고, 팀들이 과거 기록을 검색하고 비교할 수 있도록 하며, 실시간으로 핵심 성능 인사이트에 빠르게 접근할 수 있도록 지원합니다. 이는 다수의 SKU에도 확장 가능하며, Pi까지도 캡처할 수 있습니다. MongoDB는 유연한 데이터 저장소로서 빠른 쿼리 속도를 제공합니다.

다만, 제약 사항이 있습니다. 이 공간은 원본 데이터(raw data)가 빠르게 증가합니다. Insights에 따르면 100MB 이상일 때, Capturer에서 데이터 관련 문제가 빠르게 발생하기 시작합니다. 오픈 월드(open world) 환경에서는 10개, 100개, 심지어 수천 개의 테스트 포인트(test points)가 있을 수 있습니다. 이는 저희가 현재 적극적으로 검토 중인 문제입니다.

Once again, automation. Consistency matters. Every day, get a new change list. This can be integrated into any CICD system you have So we decided to use a Jenkins pipeline but honestly just use whatever you have in So this is a framework that allows us to innovate on, and it allows us to look at performance in an integrated way. And we're looking at things from a new perspective. So really, myself, I love sitting in a meeting room

'aha moment' 또는 그러한 논의를 듣는 경험은 매우 중요합니다. "아, 이런 문제가 있었지만, 이것과 이것을 통해 해결했습니다." 또는 "문제를 더 쉽게 파악할 수 있는 방법을 발견했습니다." 와 같은 깨달음은 큰 성취감을 줍니다. "이것으로 끝인가요? 시스템이 완벽해진 건가요?" 물론 그렇지 않습니다. 잠시 뒤로 물러나 생각해 봅시다. 처음에는 CSV profiler로 시작했습니다.

이후 Insights Captors를 통합하였습니다. Steven, 이제 말씀해 주시죠. 좋습니다. Goliath는 생산 환경에서 작동하고 있었고, 제 역할을 수행하며 데이터를 캡처하고 트렌드를 보여주며 문제를 발견했습니다.

하지만 좋은 도구가 그렇듯, Marius가 말한 것처럼 아직 완성되지 않았습니다. 이러한 기능은 계속 발전하며, 특히 프로덕션 환경에 적용될 때 더욱 그렇습니다. 본질적으로 기본적인 프로파일링만으로는 충분하지 않았습니다. CSV 데이터는 개괄적인 개요를 제공해주었습니다.

당사에서는 이러한 복잡한 문제를 해결하는 데 필요한 만큼의 깊이를 확보하지 못했습니다. 이에 따라 저희는 툴을 한 단계 발전시켰습니다. Unreal Insights를 통합하여 활용하게 되었습니다. 해당 여정에 대한 세부 사항을 간략히 공유해 드리고자 합니다.

CSV Profiler는 빠르고 간편하지만, 깊이 있는 분석이 어렵습니다. 문제가 무엇인지 알려주지만, 구체적인 원인을 파악하기는 힘듭니다. 우리는 더 많은 정보와 프레임 수준의 상세 분석을 연결할 방법이 필요했습니다. 바로 이러한 지점에서 Unreal Insights가 뛰어난 성능을 발휘합니다. 시스템의 타이밍을 완벽하게 시각화하여 제공합니다.

퍼포먼스가 기대만큼 나오지 않고 까다로운 디버그 문제가 발생할 때 필요한 기능입니다. 하지만 에디터에 종속되어 있어 자동화에는 적합하지 않다는 제약이 있습니다. Data 파일이 빠르게 커지고 Goliath로 가져오는 데 시간이 좀 걸렸습니다.

하지만 실제로 그 이후의 모든 것을 가능하게 하였으며, 툴을 더욱 발전시켰습니다. 시작하기에 앞서, 우리는 먼저 이해할 필요가 있었습니다.

Unreal Insights를 자동화 파이프라인에서 실행하는 방안을 모색하였습니다. Insights는 에디터에 종속되어 로컬 디버깅에는 유용하지만, headless 자동화 환경에서는 제약이 있습니다. 저희의 목표는 이러한 외부 종속성을 제거하고, Goliath가 직접 호출할 수 있는 standalone executable을 만드는 것이었습니다.

이는 언리얼 엔진 빌드 전반을 조사하고, 코드를 분석하여 불필요한 부분을 제거하는 작업을 의미했습니다. 이를 통해 명령줄 trace analysis tool을 구현할 수 있었습니다. 핵심은 에디터 없이 서버에서 해당 툴을 실행할 수 있도록 하는 것이었습니다. 이는 CFCD pipeline에서 실행 가능한 파일이 없으면 작업 진행이 불가능하기 때문에 매우 중요했습니다. 다음은 그 작동 방식입니다.

저희는 가능한 모든 dependencies를 추출하였습니다. 이제 nightly builds를 실행합니다. Goliath는 저희가 playlists에 설정한 게임 내 performance checkpoints들을 캡처합니다. 각 checkpoint에 대한 Utrace 파일을 생성합니다. 이 파일은 저희 custom insights processor로 전달될 수 있습니다. 프로세서는 실행되어 모든 trace를 파싱합니다.

Insights는 그림자 깊이(shadow depth), 렌더링 속도(render velocities)를 포함하여 수만 개의 라벨링된 타이머를 추출하는 데 탁월합니다. 이 모든 데이터는 구조화된 메트릭스(structured metrics) 형태로 Goliath로 전달됩니다. 이제 단순한 스냅샷 수집을 넘어, 엔진의 전체 작동 과정 또는 엔진이 수행했던 작업을 상세히 파악할 수 있습니다.

체크포인트 시점에, 거대한 U 트레이스를 수천 개의 개별 타이머로 효과적으로 변환합니다.

잠시 숨을 고르고 현재 상황을 되짚어 보겠습니다. 지금까지 우리는 방대하고 매우 혼란스러운 데이터 묶음을 만들어냈습니다. 이제 '곤도 마리에'의 도움을 빌려 정리할 시간입니다. 사실, 우리에게는 매우 유용한 데이터들이 많이 있습니다.

현재 데이터가 매우 체계적이지 않은 상태입니다. Insights GUI는 명확한 목적을 가지고 있으며, 해당 목적을 매우 잘 수행합니다. 이러한 유형의 데이터를 표시하는 데 탁월합니다.

이 데이터는 처리 후에는 누구에게도 보여주기에 적합하지 않습니다. 따라서, 데이터를 처리한 후에는 'joy'를 불러일으킬 수 있는 형태로 재구성해야 합니다.

So the next step, basically, is to make it make sense. We start out by filtering the noise. Timers that appear in every frame, but don't actually contribute in a meaningful way. Things like those housekeeping calls, placeholder events, and my ever useful favorite of unknown in the corner here, we can get that out of the way. What we want is to, or what we do is we maintain

Goliath 쇼의 데이터에서 관련 없는 정보(red herrings)를 동적으로 제거하여, 항상 유용한 데이터만을 유지합니다. 이로써 12페이지 분량의 불필요한 정보 속에서 단 하나의 단서를 찾는 수고를 덜 수 있습니다. 이러한 노이즈 필터링을 통해,

쓰레드별로 첫 번째 그룹핑을 수행합니다. 게임, 렌더, RHI, GPU를 대상으로 합니다. 이는 고수준의 분류 작업입니다. 쓰레드 분류는 문제 공간을 좁혀 우선순위를 정하고, 추측 없이 정확한 영역으로 파고들 수 있도록 돕기 위함입니다. 분류 후에는 쓰레드별로 레이블링된 타이머의 좁혀진 집합을 얻게 됩니다. 하지만 이를 다른 방식으로 살펴보고자 합니다.

다음 단계에서는 더 깊고 섬세한 그룹핑을 고려할 수 있습니다. 필터링 및 첫 번째 패스를 완료하면 여전히 타이머의 원시 목록이 남아 있습니다. 다음 단계는 이를 'event'라고 부르는 것으로 그룹화하는 것입니다.

이전에 간략히 언급한 바와 같이, event group은 논리적으로 함께 속하는 관련 timer들을 동적으로 정의한 container라고 할 수 있습니다. 저희가 정의한 event group의 예시로는 다음과 같은 것들이 있습니다.

이곳의 예시에는 PSO, Niagara, physics, textures가 포함되어 있습니다. 각 항목은 명확한 성능 이야깃거리와 실행 가능한 최적화 경로를 제시하므로 함께 묶는 것이 합리적입니다. 목표는 20,000개 이상의 항목을 줄이는 것입니다.

개별 타이머를 최대 30개의 유의미한 그룹으로 축소했습니다. 유용할 만큼 세분화되었지만, Goliath 내에서 시각화하기에 충분히 깔끔합니다.

각 그룹은 pattern matching을 사용하여 관련 timers를 캡처합니다. 예를 들어, Niagara 그룹은 particle, NS candle, emitter와 같은 pattern을 matching할 수 있습니다. 이러한 그룹들은 hierarchical하며, 특정 timer가 Niagara와 같이 구체적인 항목에 matching되면 textures와 같은 broader category에서는 제외됩니다.

That way, each timer ends up in its most relevant place, but we also make sure that it is captured somewhere and nothing falls through the cracks. So to wrap that up, here we see those matches.

NSCandle flame을 NSCandle group을 기반으로 Niagara group으로 통합하는 방식입니다. 이 과정은 상당히 간결하지만, 프로젝트에 적합한 방식으로 데이터를 구성하는 데 있어 매우 큰 유연성을 제공합니다.

궁극적으로 이 모든 것은 하나의 통합된 dashboard에서 완성되며, 앞서 말씀드렸던 생태계를 벗어나야만 했던 문제를 해결합니다. 이것이 바로 우리의 single source of truth입니다. high-level budgets, time series graphs, 그리고 low-level insights data를 하나의 일관된 시스템으로 연결합니다. 그러나 이러한 결과를 얻기까지는 단순히 filtering하는 것을 넘어, 데이터를 핵심적인 방식으로 interpreting하고 structuring하는 과정이 필요했습니다.

궁극적으로 저장하기 용이하고, 시각화하기 쉬우며, 개발자가 활용하기 더욱 편리하게 만듭니다.

여기까지 왔습니다. 좋습니다. 흥미로운 툴을 구축하는 것에는 분명 수요가 따를 것입니다.

기능 요청이 인력 월 단위보다 많으며, 품질 향상 요청, 웹 인터페이스에서의 플레이리스트 관리, 향상된 그래프 관리 등 다양한 개선 사항이 존재합니다. 현재는 몇 가지 더욱 근본적인 업그레이드에 집중하고 있습니다.

저희가 많이 다루지 않았던 부분이 있는데, 수동으로 큐레이션된 optimization advice를 제공하는 작은 시스템이 있습니다. 예를 들어, Lumen bottleneck이 발생하면 특정 CVars 또는 debug views를 추천해 드립니다. 이 조언은 인터넷에서 수집한 데이터와 저희 자체 optimization 경험을 프로젝트에 적용한 결과를 기반으로 합니다.

그러나 AI 또는 large language models를 활용하여 이 performance advice system을 강화할 수 있다면 매우 좋을 것입니다. 이를 통해 과거 데이터와 developer notes를 모두 읽고, context aware optimization advice를 실시간으로 생성할 수 있습니다.

둘째로, 디버그 이미지에 대한 통합 이미지 분석 기능을 구현하고자 합니다. 이를 통해 엔지니어들이 직접 이미지를 판독해야 하는 번거로움을 없앨 수 있습니다. 예를 들어, Flux Capacitor 변경, ChatGPT 질문, 혹은 양봉업으로의 새로운 진로 모색과 같은 제안을 자동화하여, 자연과 함께하는 삶을 추구하는 데 도움을 줄 수 있습니다.

이 발표를 준비하는 동안 엔지니어들은 실제로 이 기능을 구현했습니다. 이제 픽셀 레벨에서 등급 분류가 가능하며, 디버그 이미지에 대한 자동 채점 기능이 추가되었습니다. 픽셀 단위 분석을 통해 종합적인 성능 점수가 생성되며, 기본적인 최적화 권장 사항도 제공됩니다. 이러한 분석을 통해

이를 통해 빠르고 실행 가능한 제안을 제공할 수 있으며, 이는 전체 팀에게 가시성을 부여합니다. 다시 한번 강조하지만, 이것이 힘의 원천입니다. 왜냐하면 데이터를 해석할 수 있는 매우 특정적인 소수의 인원으로 제한되는 대신, 이제는 성능 논의에 참여하는 더 넓은 범위의 인원이 존재하기 때문입니다.

Unreal Engine의 기존 Legend가 이미지에 포함된 경우, 해당 Legend가 직접 통합됩니다. 그렇지 않은 경우, 시스템은 컨텍스트를 제공하기 위한 맞춤 Legend를 생성할 것입니다. 중요한 점은 기존 파이프라인이 이미 구축되어 있었기 때문에 이 기능을 추가하는 것이 상대적으로 간단했다는 것입니다. 저희가 해야 할 일은 scoring logic을 통합하는 것뿐이었습니다. 이것이 바로 robust tool set의 진정한 힘입니다. 새로운 아이디어는 신속하게 플러그인될 수 있습니다.

amplifying everyone's ability to tackle performance head-on. We're also looking at integrating third-party tools, such as PIX and Razor, for an even robust data set. I think there might even be GPU insights coming in. The possibilities are limitless. As long as we ensure that the data we capture is crunched in a meaningful way, we can continue to improve the power of the tool and ensure developers get useful, immediate feedback.

다시 한번, 팀은 가장 중요한 '재미'를 찾는 데 역량을 집중할 수 있습니다. Performance capture 또는 performance issues는 사라지지 않을 것이므로, 이 모든 것을 마무리하겠습니다.

게임의 규모가 커지고, 팀은 더욱 분산되며, 기술 스택은 그 어느 때보다 복잡해지고 있습니다.

성능 추적을 제작 과정의 일부로 포함시키고, 후반부에 부가적으로 추가하는 것이 아니라 처음부터 고려하면 전반적으로 더 나은 결과를 얻을 수 있다는 것을 배웠습니다.

궁극적으로, 본 세션을 통해 많은 분들이 귀하의 프로젝트에서 Performance Tracking을 좀 더 일상적인 절차이자 표준화된 프로세스로 고려하시게 되기를 바랍니다. 더 이상 마지막 순간에 허둥지둥하는 일이 없도록 말입니다. 아직 확신이 서지 않으셨다면, 이제 여러 이해관계자들의 입장에서 몇 가지 사례를 살펴보겠습니다.

각 스튜디오에서 이 접근 방식을 어떻게 활용하고 어떤 이점을 얻는지 설명합니다. EP(Executive Producer)들은 예측 가능성을 확보하여, 제품 진행 상황을 명확히 파악하고 잠재적인 문제를 조기에 감지하여 해결 방안을 모색할 수 있습니다. 필요하다면 신속하게 전략을 수정하여 문제에 대처할 수 있습니다.

Tech Director의 경우, 문제 발생 지점을 정확히 인지하고 개발자들에게 더 명확하고 구체적인 과제를 할당하기 용이해집니다. 이를 통해 문제 해결을 더욱 신속하고 효과적으로 진행할 수 있습니다.

궁극적으로 제가 집중하고 싶은 것은 혁신과 게임을 돋보이게 만드는 요소들을 구축하는 것입니다. 이를 통해 워크플로우를 개선할 수 있습니다. 그러면 프로젝트의 개별 기여자들은 자신들의 커밋이 성능에 어떤 영향을 미치는지 꾸준히 파악하게 될 것입니다. 결과적으로 게임의 성능에 더 깊이 관여하게 되며, 이는 공동의 책임으로 이어집니다. 결국 프로젝트의 사기와 협업을 증진시키는 것입니다. 따라서 이러한 단기적인 목표를 넘어, 지속적인 성능 개선을 추구합니다.

모니터링을 통해 어려운 대화를 조기에 진행할 수 있습니다. 결국, 이는 궁극적으로

이는 프레임 단위의 예산 책정을 넘어선 문제입니다. 최적화가 두렵거나 신비로운 과정이 아닌, 게임 개발의 일부가 되는 문화를 구축하는 것입니다. 이를 강조하기 위해 스카이림 시나리오를 살펴보겠습니다.

물론, 이 부분이 이상적인 경우일 수 있다는 점은 인정합니다. 하지만 저희의 접근 방식이 이러한 논의를 어떻게 변화시킬 수 있는지 생각해 보십시오. 저희의 열정적인 개발자는 게임 전체, 즉 게임 속 모든 개미에 대한 그림자를 켜는 작업을 수행합니다.

But unfortunately, I have to step in as a tech director and say, well, that's cool, it looks great, but performance is dying, it's too expensive. But in this scenario, it's mid-production, I have time, I have some resources available to me, and I can say, well, it's not usable as is, but let me assign a dev to the challenge, and we can work together to find a solution for this. And ultimately, our superstar developer invents a new shadowing technique that works amazingly for thousands of ants in the game and that part of the map. And so, as I said, maybe this is idealized. We're not going to invent a new technology and solve the problems every time. But this is the healthy type of discussion

이러한 문제들을 조기에 발견하면, 시각적인 미세 조정(visual tweaks), 기능(features) 및 성능(performance)에 대한 균형을 더 깊이 있게 잡을 수 있습니다.

이제 귀하의 팀에서 이러한 종류의 대화를 나누고 싶으실 것입니다. 하지만 다소 부담스럽게 느껴질 수도 있습니다. 저희의 유일한 조언은 매우 간단합니다. 작은 단계부터 시작하십시오. 매일의 캡처를 찾아보십시오. 간단한 대시보드를 구축하십시오. 이 단순한 활동들이 실제로 관점을 바꿀 수 있다는 사실에 놀라실 것입니다.

이러한 시스템의 투자 수익률(ROI)에 대해 질문하시는 분들이 계실 수 있습니다. 하지만 위기 감소나 팀 사기 증진에 대해 정확한 금액으로 환산하는 것은 매우 어려운 일입니다.

막대한 무형의 이점들이 있습니다. 초과 근무가 줄어들고, 긴급 패치 횟수가 감소하며, TRCXRs 실패 위험이 줄어들고, 막바지 기능 삭감 위험도 낮아집니다.

궁극적으로 게임 품질은 물론, 프로덕트와 팀의 건강까지 향상될 것입니다. 이 데이터는 다른 의사 결정권자나 퍼블리셔에게 제시하는 데에도 활용될 수 있습니다. 이를 통해 여러분이 performance landscape를 잘 파악하고 있으며, 모든 것이 순조롭게 진행되고 있음을 보여줄 수 있습니다.

이는 시간과 비용 절감에 대한 이야기가 아닙니다. 궁극적으로 저희는 팀이 잠재력을 최대한 발휘하도록 지원하고자 합니다. 개발 과정에 Performance Monitoring을 통합함으로써, 팀원들은 혁신하고, 창작하고, 잊을 수 없는 경험을 선사하는 본연의 업무에 집중할 수 있습니다.

이 툴은 여러 가상 스튜디오 간의 협업으로 개발되었습니다. 특히 몽펠리에(Montpellier)에 위치한 스튜디오와 Skydance Games, 그리고 ML이 참여하였습니다. 마지막으로 그의 명언을 인용하며 마무리하겠습니다.

이 툴은 엔지니어, QA, 아티스트 등 최적화 작업을 수행하는 모든 개발자들의 업무를 효율적으로 돕기 위해 설계되었음을 기억해야 합니다.

개발자의 니즈를 최우선으로 하는 휴머니즘 기반 툴이므로, 답답함이 줄어들 것입니다. 대단히 감사합니다.