모질라 파이어폭스 4가 WebGL 지원을 공식화하자, 기술 커뮤니티의 모든 시선은 자연스럽게 구글로 향했다. 그들은 O3D라는 강력한 3D 기술을 이미 선보였던 전력이 있었다. 과연 구글은 자신들의 길을 고집할 것인가, 아니면 대세가 된 WebGL의 흐름에 합류할 것인가.
구글의 선택은 빠르고 단호했다.
파이어폭스 4 베타가 발표된 지 불과 몇 주 지나지 않아, 구글은 크롬 브라우저의 개발자 버전(현 Canary 빌드)에서 WebGL을 기본 활성화했다고 발표했다. O3D 프로젝트는 사실상 중단되고, 그 프로젝트에 투입되었던 핵심 엔지니어들이 대거 크롬의 WebGL 구현 팀으로 이동했다.
이는 WebGL 워킹 그룹의 완벽한 승리를 의미했다. 가장 강력했던 대안 기술을 만들던 회사가 스스로 그 기술을 접고 표준의 편에 선 것이다.
하지만 구글의 합류는 단순한 ‘따라가기’가 아니었다. 그들은 특유의 속도와 공격적인 자세로 WebGL 생태계의 판도를 뒤흔들기 시작했다.
크롬팀의 최우선 과제 역시 파이어폭스와 마찬가지로, 크로노스 그룹의 공식 적합성 테스트 스위트를 100% 통과하는 것이었다. 그들은 이 과정에서 자신들이 가진 막강한 자원을 총동원했다. 수백, 수천 대의 컴퓨터로 구성된 자동화된 테스트 팜(Test Farm)이 24시간 내내 돌아가며, 세상에 존재하는 거의 모든 종류의 그래픽 카드와 운영체제 조합에서 크롬의 WebGL 구현을 테스트하고 버그를 찾아냈다.
이 과정에서 그들은 파이어폭스팀이 미처 발견하지 못했던 새로운 드라이버 버그들과 마주쳤다.
한 예로, 특정 구형 인텔 그래픽 카드에서 복잡한 프래그먼트 셰이더를 컴파일할 때 드라이버가 다운되는 현상이 발견되었다. 크롬팀은 이 문제를 해결하기 위해, ANGLE(Almost Native Graphics Layer Engine) 프로젝트를 더욱 적극적으로 활용했다. ANGLE은 개발자가 작성한 GLSL 코드를 드라이버에 직접 전달하기 전에, 더 안전하고 단순한 형태의 코드로 ‘변환’하는 역할을 했다. 그들은 ANGLE에 문제의 드라이버 버그를 우회하는 로직을 추가함으로써, 개발자가 버그를 인지하지 못하게 하면서도 안정성을 확보했다.
이러한 발견과 해결책은 구글 내부에만 머물지 않았다. WebGL 워킹 그룹의 정신에 따라, 그들은 발견한 드라이버 버그 정보와 ANGLE의 해결책을 워킹 그룹 전체에 공유했다. 이 정보는 곧바로 모질라팀에게도 전달되었고, 파이어폭스의 안정성을 높이는 데에도 기여했다.
경쟁은 성능에서도 불붙었다.
구글은 크롬의 V8 자바스크립트 엔진과 WebGL 파이프라인 사이의 데이터 전달 속도를 최적화하는 데 막대한 노력을 기울였다. 그들은 ‘어떻게 하면 자바스크립트의 TypedArray를 CPU와 GPU 사이에서 가장 빠르게 복사할 수 있는가’와 같은 저수준의 최적화에 집착했다.
그 결과, 똑같은 WebGL 데모를 실행했을 때 어떤 데모는 파이어폭스에서 더 빨랐고, 어떤 데모는 크롬에서 더 빨랐다. 개발자 커뮤니티에서는 두 브라우저의 WebGL 성능을 비교하는 벤치마크 결과가 연일 화제가 되었다.
“크롬의 최신 빌드에서 행렬 연산이 15% 빨라졌습니다!”
“파이어폭스가 텍스처 업로드 속도를 개선해서 따라잡았네요.”
이 건강한 경쟁은 WebGL 기술 전체를 앞으로 나아가게 하는 강력한 엔진이 되었다. 한쪽이 새로운 최적화 기법을 도입하면, 다른 쪽은 그것을 분석하고 더 나은 방법을 찾아내려 애썼다. 블라디미르는 이 광경을 흐뭇하게 지켜보았다. 이것이야말로 그가 꿈꿨던 ‘표준’의 힘이었다. 하나의 독점 기술 아래에서는 결코 일어날 수 없는, 개방된 경쟁을 통한 상향 평준화.
파이어폭스가 문을 열고, 크롬이 그 뒤를 바짝 쫓으며 판을 키웠다. 웹 3D라는 새로운 운동장에는 두 명의 강력한 선수가 등장했다. 하지만 아직, 가장 중요한 선수 한 명이 벤치를 지키고 있었다. 아이폰과 맥의 제왕, 애플이었다.
