작년 11월에 Digia는 Qt WebEngine이라 불리는 새로운 프로젝트를 시작했습니다. Google의 Chromium에 기반한 이 프로젝트는 현재의 Qt WebKit을 대체할 목적으로 만들어졌습니다. 대부분의 사람들은 Chromium을 쉽게 자신들의 프로젝트에 도입할 수 있게 된다는 사실을 크게 반겼습니다. Digia는 Qt WebEngine이 Qt WebKit과 가능한 한 최대한 호환되도록 만들겠다고 약속하였고, 당대에서는 Nokia의 환경에서도 Digia가 꽤 좋은 평가를 받았던지라 많은 사람들이 그 약속을 믿었습니다.
지난주에 Qt WebEngine 팀이 새로운 블로그를 올렸고, 저는 그 글의 댓글에서 API에 대한 약간의 “불평”을 발견했습니다. 위키를 확인해본 결과, 제가 web crawler 개발에 사용하는 핵심 기능인 QWebElement는 사용 불가로 낙인이 찍혀 있더군요 - 위키에 따르면, Chromium 자체가 멀티프로세스 기반이다보니 이 기능 자체가 비동기적으로 구성되어야 하는데, Qt WebEngine의 디자인은 동기화 구성이 기본이라 더이상 지원하지 않는다고 합니다.
QWebElement뿐만이 아닙니다. 제가 컨텐츠의 정상 여부를 활용하는데 사용하는 QNetworkAccessManager도 사용되지 않습니다. Qt WebEngine은 Chromium의 자체 네트워크 스택을 사용하며, 이렇게 되면 전 엔진의 네트웍에서 무슨 일이 벌어지는지 가늠할 수 있는 방법이 없어집니다.
덕분에 전 제 개발품에서 일부 기능을 부득이하게 삭제해야 되는 상황에 처했습니다. 일단 예측 가능한 미래만 놓고 본다면, Qt WebKit 자체는 9월 발표 예정인 Qt 5.4가 나오는 11월까지는 어떻게든 생존하겠지만, Qt 5.5 오픈소스 에디션이 발표되는 순간 무슨 일이 생길지는 아무도 모릅니다.
그간 WebKit이 유지보수에 손이 좀 많이 갔다고 하기도 하고, 저는 Digia의 개발팀을 좀 더 “효율적으로” 관리하고자 하는 의지 또한 존중합니다. 허나, 지난주 블로그 포스트에 달린 댓글들마냥 Qt WebEngine이 기대와 다르게 훨씬 더 적은 기능만을 갖고 출시된다면 아마 실망하는 사람이 적잖을 것 같아 우려됩니다.
현재 저는 현재의 개발환경을 대체할만한 무언가를 찾고 있습니다. Qt가 그동안 버전업을 하면서 셋업은 복잡해지고, QML 시작은 느려지고(빈 창 하나 띄우는데 최고 10초까지 소요) 하는 등의 상황을 보면서 뭔가 제 마음에 들만한 대체요소를 찾고 있긴 했습니다만, 울고 싶던 차에 Qt WebEngine이 뺨을 제대로 때려주는군요. 일단 현재는 wxWidgets+wxWebConnect(아니면 wxWebView) 컴보를 대체품으로 생각하고 있습니다.
어쨌든, Qt WebKit은 꽤나 위대한 프로젝트였습니다만, 이 프로젝트가 역사 속으로 사라질걸 생각하니 참 가슴이 아픕니다. 특히나 그렇게 사라지는 행위가 제 뒤통수를 크게 때리는 경우에는 더 그렇습니다.
No comments:
Post a Comment