애플의 선전포고는 Dawn 팀의 연구실을 거대한 분석실로 바꿔놓았다. 그들의 첫 번째 임무는 애플이 WWDC에서 선보인 바로 그 데모를, 자신들의 통제된 환경에서 완벽하게 재현하는 것이었다.
벤이 마침내 애플의 데모를 크롬에서 실행하는 데 성공했다. 그의 등 뒤로 팀원들이 숨을 죽인 채 모여들었다. 화면에는 수천 개의 반투명 객체들이 복잡하게 겹쳐지며 회전하는, 시각적으로 매우 부담스러운 장면이 펼쳐지고 있었다.
“자, 돌려본다.”
벤은 성능 프로파일러를 켠 채 데모를 실행했다.
결과는 냉혹했다.
크롬에서의 평균 프레임 속도는 초당 75프레임. 나쁜 수치는 아니었다. 하지만 곧바로 이어서 실행한 사파리에서의 결과는 초당 90프레임을 상회했다. 계산해보니 정확히 20%의 차이. 애플의 주장은 허풍이 아니었다.
“젠장… 진짜였어.”
누군가의 탄식이 연구실의 침묵을 깼다.
하지만 드미트리는 동요하지 않았다.
“숫자에 압도당하지 마. 이제부터가 시작이야. 저 20%라는 숫자가 어디서 오는지, 그 구성 요소를 하나하나 분해해야 해.”
팀은 곧바로 심층 분석에 돌입했다.
첫 번째 분석 대상은 CPU 사용량이었다. 양쪽 브라우저 모두에서 프로파일러를 돌렸지만, 결과는 의외였다. 자바스크립트 실행 시간이나 드로우 콜 준비에 소요되는 CPU 시간은 거의 차이가 없었다. 문제는 CPU가 아니었다.
“그렇다면 GPU 단에서 벌어지는 일이라는 건데…”
카이가 중얼거리며 Xcode에 내장된 그래픽 분석 도구, ‘Instruments’를 실행했다. 그는 사파리가 실행하는 데모의 Metal API 호출을 프레임 단위로 캡처했다. 그리고 동시에, 크롬의 Dawn이 생성하는 Metal API 호출도 캡처했다.
두 개의 거대한 호출 기록이 화면에 나란히 펼쳐졌다.
“드로우 콜의 개수는 동일하고… 셰이더도 같은 코드를 사용하고 있어. 파이프라인 상태 설정도 거의 일치하는데…”
마치 숨은 그림 찾기를 하는 기분이었다. 모든 것이 똑같아 보였다. 하지만 어딘가에, 분명 20%의 성능 차이를 만들어내는 결정적인 ‘다름’이 숨어 있을 터였다.
며칠간의 분석에도 실마리가 보이지 않자 팀은 지쳐갔다. 바로 그때, 드미트리가 새로운 접근법을 제시했다.
“우리는 지금 ‘무엇을’ 호출하는지만 보고 있어. 하지만 더 중요한 건 ‘어떻게’ 호출하느냐, 그리고 ‘얼마나 자주’ 하느냐야. 특히 데이터 바인딩 쪽을 집중적으로 파고들어 보게.”
그의 조언에 따라, 카이는 자원(버퍼, 텍스처)이 파이프라인에 연결되는 과정, 즉 Bind Group 관련 Metal 호출에 돋보기를 들이댔다.
그리고 마침내, 그는 아주 미세하지만 결정적인 차이점을 발견했다.
“찾았습니다…!”
그의 외침에 팀원들이 모두 그의 모니터로 모여들었다.
카이가 화면의 두 코드를 번갈아 가리키며 설명했다.
“애플의 데모는 매 프레임마다 수천 개의 객체에 대한 변환 행렬(Transform Matrix)을 업데이트해야 합니다. 이 행렬 데이터는 하나의 거대한 버퍼에 담겨 있죠. 사파리의 구현체는 이 버퍼가 한 번 설정되면, 그 내용이 바뀌더라도 버퍼 자체의 유효성에 대해서는 더 이상 깊게 검사하지 않습니다. 이미 신뢰하는 자원이라는 전제하에 최소한의 작업만 수행합니다.”
그는 이어서 Dawn의 호출 기록을 가리켰다.
“하지만 우리 Dawn은 다릅니다. 우리는 여러 백엔드(Vulkan, DX12)를 지원해야 하는 범용 엔진이기 때문에, 더 방어적으로 설계되어 있습니다. 버퍼의 내용이 업데이트될 가능성이 있다면, 매번 Bind Group을 설정할 때마다 해당 자원의 상태와 레이아웃이 여전히 유효한지 확인하는 추가적인 검증 로직을 거치고 있었습니다.”
그것은 아주 작은 차이였다. 하지만 그 작은 검증 로직이 프레임당 수천 번씩 반복되자, 눈덩이처럼 불어나 20%라는 무시할 수 없는 성능 차이를 만들어낸 것이었다.
“사파리는 지름길을 아는 현지인이고, 우리는 모든 신호를 지키는 모범적인 외지인 운전사였던 셈이군.”
벤이 허탈하게 웃었다.
드미트리는 원인이 밝혀지자 즉시 결정을 내렸다.
“이건 Dawn의 버그가 아니라, 아키텍처의 차이에서 오는 비효율이다. 하지만 해결할 수 있어. Dawn의 Metal 백엔드를 수정한다. 이미 검증된 자원에 대해서는 불필요한 재검증 로직을 건너뛰도록 최적화 패치를 준비해.”
다시 연구실의 키보드 소리가 바빠지기 시작했다. 이제 그들의 목표는 명확했다. 벤치마크의 비밀을 파헤친 지금, 그들은 더 이상 애플이 던진 숫자에 휘둘리지 않았다. 오히려 그들은 애플 덕분에 자신들의 엔진이 가진 숨겨진 비효율을 발견하고, 더 강해질 수 있는 기회를 얻은 것이다.
며칠 후, 최적화 패치가 적용된 새로운 Dawn 빌드가 완성되었다. 팀은 다시 한번, 떨리는 마음으로 벤치마크를 실행했다. 과연 그들은 왕좌를 노리는 자의 예봉을 꺾을 수 있을 것인가.
