My Words, Your Memory

#0 FF에 추후 탑재될 Trace Monkey 엔진과 V8 엔진에 대한 벤치 마크 결과는, Trace Monkey 엔진이 아직 근소하게 앞선다는 것 같다. 어차피 JS를 VM에서 돌리면서 JIT를 적용하는 건 '트렌드'이고, V8 자체도 BSD 라이센스로 오픈되어있기 때문에 정 V8이 좋으면 그냥 갖다 쓰면 될 일. JS 수행 속도를 빼고 말하면, gecko 가 webkit 보다 낫다. 덩치가 관건이지만 솔직히 멀티 프로세스 모델을 택할 때 부터 이미 메모리 분야에 있어선 포기하고 들어갔다고 봐야 하지 않을까.

#2 부분적인 ActiveX 지원이 되긴 한다. Firefox 에서 했던 것과 마찬가지로 Plugin 기반의 접근 방식인데, ActiveX Container Plugin 은 DLL 로 분리되어있지 않다. (DLL로 분리해서 빌드할 수는 있는 것 같아보인다) 개인적으로 ActiveX 지원은 ActiveX를 돌려주는 Plugin을 쓰는 방식 보다는 엔진 내부에서 Netscape Plugin 과 '동등한' 레벨에서 지원해주는게 이상적이라고 본다.

#3 적어도 우리나라에서는, 관건은 결국 인터넷 뱅킹, 전자 정부등 관공서 사이트, 각종 카드 결제용 ActiveX들, 그리고 VB나 델파이로 짰던 프로그램들을 고스란히 웹상에서 재현한 소위 X-Internet 이라는 걸로 만든 인트라넷 사이트들- 정도를 지원할 수 있느냐의 문제로 수렴될듯 하다. 물론, IE 전용으로 코딩된 그 많고 많은 개떡같은 웹사이트들을 웹표준에 맞춰서 다시 만들도록 하는 것도 문제지만, IE8 문제도 있고 하니 결국 시간이 해결해줄 것이다. X-Internet 이라는 것도 유행 지나면 없어질 잡동사니들에 불과한 것이다. 결국 '공인 인증서'를 위시하여 보안 기준을 충족하기 위한 온갖 개떡같은 컨트롤들을 어떻게 지원하느냐- 가 관건.

#4 ActiveX Plugin이 OLE Container 로서 얼마나 완벽하게 동작하느냐- 라는 것과는 별도로, (이건 구글이니까 어떻게든 해낼 것이다) Control 이 Plugin 을 통해  IWebBrowser 계열 인터페이스라든지 IHTMLElement 계열 인터페이스를 취해서 직접 브라우저 동작에 개입하려고 하는 경우에 문제가 복잡해진다. 이 계열의 인터페이스를 완벽하게 다 구현하면 그야말로 배꼽이 배만해질 공산이 크다. (웹킷 내부의 DOM 구현은 IE 와는 전혀 다르다. 전혀!) 키보드 보안의 경우 text input 을 받는 윈도우의 핸들을 직접 받아다 암호화 채널을 수립하고, form submit 에 개입하는 식으로 동작하는 경우엔 대략 답이 잘 안보인다.

@ 개떡같은 공인 인증서 뭐시깽이 때려치우고 그냥 https쓰자. 키보드 보안 같은건 좀 ActiveX 로 하지 말고 다른 걸로 하고, 진작 돌고 있는 방화벽 위에 방화벽 두개 세개씩 또 띄우는 삽질도 작작 좀 하자. (그지랄을 해도 뚫리는 건 뚫리더라) 제발 우리도 '인간의 얼굴을 한 인터넷' 좀 써보자. 대한민국을 언제까지 MS의 봉으로 놔둘텐가?

#5 적어도 한국에서는, 단기간내로 구글 크롬이 IE의 아성을 위협하는 일은 결코 없을 것이다. 같은 기간 내에 FF의 점유율을 깎아먹을 공산이 크지만 우리나라에선 원체 FF 자체가 점유율이 낮아서 깎아 먹으나 마나. 게다가 FF의 개방적이고 유연한 아키텍쳐는 아직까지, 그리고 앞으로도 구글 크롬과는 궁합이 맞지 않는 영역이다. (구글 크롬 첫페이지- 를 만들어주는 FF Extension이 곧 등장하리라고 본다 ^^) 진짜 불여우 팬이라면 크롬으로 넘어갈 이유가 많지 않다. (오페라쪽이라면 차라리 몰라도)

#6 그럼에도 불구하고 구글 크롬을 환영한다. 많이들 썼으면 좋겠다. 써보고 구글 찬양을 하든 욕을 하든- 최소한 IE 보다 '나은' 브라우징 환경이 존재한다는 것을, 그리고 IE로만 쓸 수 있는 웹은 웹이 아니다(!) 라는 것을 이해하는 사람들이 늘어났으면 좋겠다. 구글 크롬이 다른 브라우저들을 자극해서 훌륭한 기능들이 앞으로 많이 쏟아져 나오길 바란다. 신나는 계절이 오고 있다. 구글 만세다.