WebGL 1.0 명세서의 윤곽이 거의 완성되어 갈 무렵, 워킹 그룹의 엔지니어들은 이론의 세계를 떠나 현실의 진흙탕으로 발을 들여야 했다. 바로 각자의 브라우저에 WebGL을 실제 코드로 구현하는 작업이었다.
그리고 그 순간, 보이지 않던 적들이 모습을 드러내기 시작했다.
가장 큰 적은 ‘그래픽 드라이버’ 그 자체였다.
엔비디아, AMD, 인텔. 이 3대 제조사의 그래픽 카드는 저마다 다른 하드웨어 아키텍처와 드라이버 소프트웨어를 가지고 있었다. 워킹 그룹이 아무리 명세서를 꼼꼼하게 작성했더라도, 그것을 해석하고 실행하는 드라이버의 동작은 미묘하게 달랐다.
모질라의 한 엔지니어가 밤새 작성한 텍스처 업로드 코드가 있었다. 그의 엔비디아 그래픽 카드가 장착된 컴퓨터에서는 완벽하게 동작했다. 하지만 옆자리의 AMD 그래픽 카드를 쓰는 동료의 컴퓨터에서 실행하자, 브라우저가 아무런 경고도 없이 다운되어 버렸다.
원인을 찾는 데 꼬박 이틀이 걸렸다. 문제는 특정 해상도의 이미지를 특정 텍스처 포맷으로 업로드할 때만 발생하는 AMD 드라이버의 버그였다. WebGL 명세서의 문제가 아니었다. 드라이버의 문제였다.
“우리가 드라이버를 고칠 수는 없지 않습니까!”
한 엔지니어의 절규에 가까운 외침이 회의실에 울려 퍼졌다.
그들의 선택지는 제한적이었다. 버그가 수정된 새 드라이버가 나올 때까지 무작정 기다릴 수는 없었다. 그들이 할 수 있는 일은, 해당 버그를 유발하는 특정 코드 경로를 피하도록 브라우저 코드를 수정하는 것, 즉 ‘우회(Workaround)’하는 것뿐이었다.
브라우저의 WebGL 구현 코드는 이런 우회 로직으로 점점 누더기가 되어갔다.
// 의사 코드
if (isNvidiaDriver() && driverVersion < 3.1) {
// 엔비디아 구형 드라이버 버그 우회 코드
...
} else if (isAmdDriver() && os == "Windows7") {
// AMD 윈도우7 드라이버 버그 우회 코드
...
} else {
// 표준 코드
...
}
엔지니어들은 전 세계의 온갖 그래픽 카드와 운영체제 조합을 테스트하며 이런 보이지 않는 지뢰들을 하나씩 찾아내고 피해 가야 했다. 그것은 끝이 보이지 않는 싸움이었다.
두 번째 적은 ‘브라우저 자체의 차이’였다.
비록 같은 워킹 그룹에 속해 있었지만, 모질라의 게코(Gecko) 엔진과 구글-애플 연합의 웹킷(WebKit) 엔진은 태생부터 다른 코드 기반을 가지고 있었다.
예를 들어, 이미지 데이터를 처리하는 방식, 자바스크립트 엔진의 동작 속도, 메모리 관리 정책 등이 모두 달랐다. 똑같은 WebGL 코드가 파이어폭스에서는 초당 60프레임으로 부드럽게 돌아가는데, 크롬의 초기 빌드에서는 30프레임으로 뚝뚝 끊기는 현상이 발생했다.
원인을 추적해보니, 크롬의 프로세스 분리 아키텍처에서 GPU 프로세스와의 통신 과정에 예상치 못한 병목 현상이 있었기 때문이었다. 크롬팀은 이 문제를 해결하기 위해 내부 아키텍처를 뜯어고쳐야 했다.
이런 문제들은 워킹 그룹 회의를 다시 한번 정치의 장으로 만들었다.
“파이어폭스에서는 잘 되는데, 왜 당신네 브라우저에서는 안 되는 겁니까? 명세서에 문제가 있는 게 아니라 당신들의 구현에 문제가 있는 것 아닙니까?”
이런 식의 날 선 공방이 오갔다. 블라디미르와 다른 엔지니어들은 기술적인 문제를 해결하는 동시에, 각 회사의 자존심이 걸린 미묘한 감정 싸움까지 중재해야 했다.
디버깅은 단순히 버그를 잡는 행위가 아니었다.
그것은 엔지니어들의 인내심을 시험하고, 경쟁사 간의 협력 정신을 테스트하는 거대한 과정이었다. 그들은 보이지 않는 적과 싸우며 밤을 새웠고, 서로의 코드를 들여다보며 날카로운 피드백을 주고받았다.
이 고통스러운 과정을 통해, WebGL은 단순한 명세서가 아니라 실제로 동작하는 강력한 기술로 단련되고 있었다. 엔지니어들의 키보드 소리와 깊은 한숨 속에서, 웹의 새로운 차원이 한 땀 한 땀 엮이고 있었다. 그들은 어둠 속에서 더듬거리며, 서서히 하나의 빛을 향해 나아가고 있었다.
