2011년 10월 1일

이하의 글은 2011년에 쓴 것입니다. 오래된 글인 만큼, 현재의 생각과 전혀 다른 내용도 많이 포함되어 있고, 당시와는 상황이 많이 달라진 점도 있습니다. 또한, 그 당시에 잘못 알려졌던 정보도 포함되어 있을 수 있습니다. 어찌됐든 저는 제 오래된 글이 회자되는 것을 저어합니다. 읽기에 앞서 양해를 부탁드립니다.

두번째는 아마존의 웹킷 선택이다. 모바일 브라우저의 대다수를 차지하고 있는 웹킷을 선택함으로서 완전한 대세로 자리매김하게 될 예정이다. 모바일에서 또 다른 오픈소스 렌더링 엔진을 배포하고 있는 Mozilla의 입장에서는 조금 아쉬운 대목일수도…

—클라우드 브라우저의 탄생

사실상 WebKit이 웹 브라우저 렌더링 엔진 세계를 지배한 지는 이미 오래되었다. 이렇게 된 데에는 이유가 다 있다. Gecko 엔진을 WebKit처럼 쉽게 붙일 수는 없다. Mozilla Firefox는 좋은 소프트웨어 제품이지만, Gecko 엔진만 따로 제품처럼 쓰기는 상대적으로 까다롭다. 반면 WebKit은 매우 쉽게 붙일 수 있게 되어 있다. 엔진 자체만으로 하나의 완결된 소프트웨어 제품이다. Gecko와 WebKit의 차이는 사용자 인터페이스(UI) 디자인이 아니라 API 디자인이다. UI가 안 좋으면 사용자들이 쓰질 않듯이, API가 안 좋으면 개발자들이 갖다 쓰려고 하질 않는다.¹

물론 API가 좋다고 항상 승리하는 것은 아니다. API가 복잡해도 다른 제품에 비해 기능과 성능이 월등히 좋아서 어쩔 수 없이 쓰이는 라이브러리들도 있다. 하지만 Gecko가 WebKit에 비해 그런 확실한 우위점을 가지고 있냐고 하면… 그렇지 않은게 사실.

WebKit이 좋다고 찬양하는게 아니다. 나는 WebKit이 이렇게 잘되는 상황이 두렵기만 하다. 다가올 10년은 IE의 자리를 WebKit이 차지할 것이라고 생각한다. 이미 몇년 전부터 WebKit에서만 잘 나오면 땡이라는 웹 개발자들의 인식이 널리 퍼져있는 상태다. Google Chrome은 자기네 편한대로 웹 표준과 상관 없는 기능들을 때려넣고 있다. 좋지 않다. 렌더링 엔진 간에 마켓 밸런스가 맞아야 웹이 발전할 것이다. Mozilla의 목표가 바로 그런 것이라고 알고 있다. 그 목표를 잘 수행하려면 Mozilla Firefox의 UI를 개선하는 것도 중요하지만 Gecko 엔진의 API를 개선하는 것도 굉장히 중요하지 않나 싶다.