긴 논쟁에 마침표를 찍은 것은 ‘프로그래머블 셰이더(Programmable Shader)’라는 개념이었다.
과거의 OpenGL(Fixed-function Pipeline, 고정 기능 파이프라인)은 마치 정해진 코스 요리만 제공하는 레스토랑과 같았다. 개발자는 ‘조명을 켠다’, ‘재질을 설정한다’ 와 같이 미리 정의된 몇 가지 기능들을 조합하여 그래픽을 설정했다. 편리했지만, 독창적인 효과를 만들어내는 데에는 한계가 명확했다.
하지만 시대가 변했다. GPU가 발전하면서, 개발자가 직접 GPU 위에서 실행될 작은 프로그램을 작성하여 그래픽 렌더링 과정에 직접 개입할 수 있게 되었다. 이것이 바로 ‘프로그래머블 셰이더’였다. 개발자는 이제 점의 위치를 어떻게 계산할지(Vertex Shader), 픽셀의 색상을 어떻게 결정할지(Fragment Shader) 직접 코드로 제어할 수 있게 되었다. 이것은 그래픽 표현의 자유도를 폭발적으로 증가시킨 혁명이었다.
데스크톱 OpenGL은 이 두 가지 방식을 모두 지원했다. 과거의 고정 기능 방식과 현대적인 프로그래머블 셰이더 방식이 공존했다. 이는 하위 호환성을 위한 선택이었지만, API를 복잡하게 만드는 주된 원인이었다.
반면, OpenGL ES 2.0은 과감한 결정을 내렸다. 과거의 고정 기능 파이프라인을 완전히 폐기하고, 오직 프로그래머블 셰이더 방식만을 지원했다. 더 단순하고, 더 일관성 있으며, 개발자가 GPU의 능력을 더 직접적으로 활용할 수 있는 현대적인 구조였다.
블라디미르는 바로 이 지점을 파고들었다.
“우리가 웹에 가져와야 할 것은 OpenGL의 모든 기능이 아닙니다. 미래의 그래픽스 프로그래밍 모델 그 자체입니다. 그리고 그 미래는 명백히 프로그래머블 셰이더에 있습니다. 그렇다면 굳이 과거의 유산을 웹이라는 새로운 세상에까지 끌고 들어올 필요가 있겠습니까?”
그의 주장은 강력한 논리적 기반을 가지고 있었다.
첫째, 단순성. 고정 기능을 제거함으로써 WebGL API의 복잡도를 크게 낮출 수 있었다. 이는 브라우저 제조사가 구현하기에도, 웹 개발자가 배우기에도 훨씬 유리했다.
둘째, 보안. 예측 불가능한 여러 기능의 조합을 허용하는 것보다, 명확하게 정의된 셰이더 프로그램의 입출력만 검증하는 것이 보안 모델을 수립하기에 훨씬 더 안전했다.
셋째, 호환성. 당시 출시되던 거의 모든 스마트폰의 GPU는 OpenGL ES 2.0을 지원하고 있었다. 데스크톱 GPU 역시 상위 호환으로 ES 2.0을 지원하는 것은 당연했다. 즉, OpenGL ES 2.0을 기반으로 삼는 순간, 데스크톱과 모바일을 아우르는 가장 넓은 하드웨어 호환성을 확보할 수 있었다.
마침내, 데스크톱 진영을 지지하던 엔지니어들도 한발 물러섰다. 최고의 성능을 일부 포기하더라도, 웹이라는 플랫폼의 본질인 ‘보편성’과 ‘안전성’을 지키는 것이 더 중요하다는 대의에 동의하기 시작한 것이다.
길었던 논쟁 끝에, 워킹 그룹은 역사적인 합의에 도달했다.
“WebGL 1.0은 OpenGL ES 2.0 명세를 기반으로 한다.”
이것은 WebGL의 운명을 결정한 가장 중요한 선택이었다. 이 결정으로 인해 WebGL은 태생부터 ‘모바일 퍼스트’와 ‘셰이더 중심’이라는 명확한 정체성을 갖게 되었다.
이 선택은 훗날 엄청난 결과를 낳았다. 스마트폰이 세상을 지배하는 시대가 왔을 때, WebGL은 이미 모바일 환경에 완벽하게 대비된 기술이 되어 있었다. 만약 그때 워킹 그룹이 데스크톱 OpenGL의 화려함에 눈이 멀어 다른 선택을 했다면, WebGL은 지금처럼 널리 쓰이지 못하고 일부 PC에서만 돌아가는 기술로 전락했을지도 모른다.
이제 WebGL이 나아갈 큰 길이 정해졌다. 남은 것은 OpenGL ES 2.0의 수많은 기능들 중에서 어떤 것을 가져오고, 어떤 것을 버리고, 또 웹 환경에 맞게 어떻게 변형할 것인지를 결정하는, 지루하고도 험난한 세부 작업들이었다. WebGL이라는 거대한 조각상의 윤곽이 잡혔고, 이제부터는 조각칼을 들고 정교하게 깎아나갈 시간이었다.
