마이너가 된 IE 8, 그리고 생각해 봐야 할 하위호환성 문제

 

마이크로소프트의 IE 8 이 드디어 베타 테스트에 들어 갔네요.

요즘 회사 일로 UI 에 관심이 많아 IE 8 의 달라진 UI를 구경하기 위해 바로 설치했습니다.

XP SP2 PC에서 설치하는데, 정품인증 과정을 거치라는 좀 귀찮은 과정이 있었고 2번 리부팅해서 겨우 설치 했습니다. 브라우저 하나 설치 하는데 부팅을 2번 하는 건 좀 심하네요. 워낙 IE 자체가 마이크로소프트 시스템 내부와, 특히 탐색기 쪽과 관련이 많고, IE Control 을 지원하기 위한 부분도 많아서 그런 것으로 보이는데, 이러한 것들이 오히려 일반 사용자들에게는 타 브라우저와 비교대상으로 보여질 가능성도 커 보입니다.

 

마이너가 된 IE 8

 

웹 브라우저 시장에서 독보적인 존재였던 MS 가 IE 8을 내 놓으면서 이제는 마이너로 돌아간 느낌입니다. 프로그램 설치하자 마자 타 브라우저의 즐겨찾기를 가져오겠냐고 물어봅니다. 여태껏 불여우나, 오페라를 설치할 때는 이러한 기능을 본 적이 있지만, 웹 브라우저의 최강자가 되어 버린 IE 를 설치하면서 이러한 설정을 해 본 기억이 없네요.

하나의 어플리케이션이 경쟁 어플리케이션의 설정을 읽어 들일 수 있는 것은, 그만큼 경쟁사를 의식하고, 경쟁사의 고객을 끌어오겠다는 의지가 강하다는 반증입니다. 마이크로소프트는 1990년대 당시 최고의 히트 프로그램인 Lotus 123 스프레드시트로부터 자사의 소프트웨어 엑셀로 고객을 끌어들이기 위해 엑셀에 Lotus 123 스프레드시트 읽기 기능을 넣었습니다. 그뿐만 아니라 Lotus 123 로부터 엑셀로 넘어 온 고객을 위해 Lotus 123 방식의 키 입력방식까지 그대로 제공했고 심지어 Lotus 123 파일 포맷으로 저장하기 기능까지 제공해서, 고객을 자사의 프로그램으로 손쉽게 넘어 올 수 있도록 했습니다(조엘 온 소프트웨어 참조) 이제는 메이저가 되어 그러한 경쟁사 고객 끌어오기에 관심이 없어 보였던 마이크로소프트가 IE 8 을 개발하면서 어지간히 급했던 모양입니다. 하긴 오페라로부터 웹 표준도 제대로 못 지킨다는 소송까지 당했고,  탭 브라우징의 편리성이나 기능면에서 불여우 등의 다른 웹 브라우저에 비해 한참 뒤져 있는 IE 7 을 업그레이드하면서 실추된 명예를 회복하기 위해서는 체면 차릴 필요 없이 과거처럼 철저하게 경쟁사를 벤치마킹하고 고객이 손쉽게 자사의 소프트웨어로 넘어올 수 있도록 최선을 다하는 방법 밖에 없었을 거라 생각됩니다.

 

 

IE 8 과 하위호환성

 

이번에 베타버전으로 공개된 IE 8 은 최근 얼마 안 되는 기간 동안 웃지 못할 우여곡절을 겪었습니다.

원래 마이크로소프트의 전략은 IE 8을 웹 표준과는 거리가 멀지만 이전 IE 버전과 호환되는 버전을 디폴트로 제공하고, 사용자가 원할 경우 추가 설정을 통해, 최신 웹 표준에 따르는 모드로 제공할 수 있는 브라우저를 준비했습니다.

 

IEBlog : Compatibility and IE8

 

하지만 이러한 발표를 한지 얼마 지나지 않아 이전 정책과 180도 반대되는 정책을 채택했다고 다시 공지했더군요.

IEBlog : Microsoft's Interoperability Principles and IE8

 

처음 마이크로소프트가 하위호환버전으로 오픈한다고 했을 때 국내외 여러 블로거들로부터 많은 비난을 받았습니다. 그도 그럴 것이 웹 표준에 맞지 않아 수많은 웹 개발자를 고생시키고 있는 마이크로소프트의 IE 가 새 버전에서조차 기본적으로 이전 호환 모드로 작동한다고 하니, 얼마나 맥이 빠졌을까요?

하지만 마이크로소프트입장에서, 아니 기존에 IE6 과 IE7 에 최적화되도록 제공되고 있는 웹 서비스 회사들도 역시 이 결정에 반대했을까 궁금합니다.

새로운 버전의 IE 가 나왔다고 해서 기존까지 멀쩡하게 제공되던 자사 홈페이지가 제대로 표시되지 않았다면, 웹 표준이 뭔지도 모르는 수 많은 클라이언트로부터 엄청난 항의에 시달렸을 게 뻔합니다.

아니나 다를까

IE 8을 설치하고 짧은 시간 자주 가는 몇 군데 사이트를 살펴 보았더니 가관이더군요.

 

• 포털 사이트인 다음은 페이지 레이아웃이 상당부분 많이 깨집니다.

• 티스토리에서는 기존 포스팅에 댓글 달기가 안보입니다.

• 네이트온에서 문자 보내기 하면, 문자 보내는 창에 아무런 키가 입력이 안됩니다.

• 구글 RSS 에서는 제대로 글을 볼 수 없을 정도로 버벅댑니다. (구글이 IE 에서 정상적으로 서비스 되지 않는 다는 건 참 아이러니합니다. MS 에서는 일부러 구글이 제대로 보이지 않게 출시하지는 않았겠지만, 당연히 구글 RSS 정도는 충분히 테스트하고 베타를 오픈했을텐데 이런 식이라니…… 구글의 문제인지 IE 8 베타가 문제인 건지 모르겠네요)

 

정말 다행스럽게도 IE 8 에서는 “Emulate IE7” 이라는 버튼을 두어(프로그램 재 시작 필요) 문제가 있을 경우 렌더링 엔진이 IE 7 상태로 작동할 수 있도록 하위호환성을 제공하고 있었습니다.

 

 

만약 이 기능이 없었다면 어땠을까요?

국내 사용자의 경우 파이어폭스나, 오페라에서 접근조차 안되는 사이트가 꽤 많습니다. 그런데 IE 8 에서 조차 접근이 어렵다면, 당장 처리해야 할 일을 하지 못하게 되어 사용자나, 서비스를 제공하는 수 많은 업체에게 엄청난 피해를 입혔을 게 뻔합니다. (물론 웹 표준에 맞도록 홈페이지를 수정하면 되겠지만, 반드시 고객이 새 버전의 IE 8 로 업그레이드 한다는 보장도 없으니 쉬운 결정이 아니지요)

마이크로소프트 입장에서는 IE 6 이나 IE 7을 사용하는 사용자도 보호해야 하고, 웹 표준도 지켜야 하는 모순된 선택의 상황을 강요당했습니다.

 

이러한 관점에서 보면(웹 표준에 부합하지 않기 때문에 전혀 다른 관점에서 볼 때 이것이 문제겠지만) 마이크로소프트가 디폴트 렌더링 엔진을 IE 7 호환모드로 가져가려고 했던 부분도 조금 이해는 갑니다.

 

다만 이왕 고생해서 힘들게 통과한 ACID2 테스트도 그렇고, 개발한 보람도 없이 디폴트를 이전모드로 가져간다면, IE 8 의 새로운 웹 표준 모드로 사용자를 유도하려는 의도가 없다고도 보여지는 항목이라, 디폴트를 웹 표준으로 가져가지 않은 것은 조금 이해가 가지 않는 부분이네요.

 

다행히, 오페라 측 소송이나, 기타 많은 웹 관련 개발자 분들의 지적으로 브라우저 시장에서 가장 많은 사용자를 가진 IE 가 웹 표준을 최우선으로 선택하고, 하위 호환 모드를 제공해서 개발자나 사용자에게 적응 할 수 있는 시간을 준 것은 대단히 환영할만한 결정이라고 생각합니다.

 

프로그램을 개발하다 보면 언제나 하위호환성이라는 무서운 어제의 자신과 만나게 됩니다.

완전히 새로운 뭔가를 만들었는데, 이 기능을 위해서는 이전과 완전히 다른 인터페이스를 가져가야 하거나, 기존 사용자가 뭔가 추가적인 작업을 해야 한다면 그 소프트웨어는 성공하기 힘들 것입니다.  그래서, 새로운 기능도 추가하고, 기존 사용자를 보호할 수 있는 중용의 길이 필요한데, 가급적 개발자 입장에서는 힘들게 개발한 새로운 기능을 고객에게 적용시키고 싶기 때문에, 디폴트는 새로운 기능으로 가고, 과거 호환성 모드를 지원하는 게 일반적이지 않나 싶습니다.  물론 과거를 포용하기 위해서는 프로그램의 크기가 2배가 되거나, 엄청난 노력이 필요할 수도 있어서 이것조차도 쉬운 결정은 아니겠지만요.

 

얼마 전부터 제가 새로 기획하고 있는 기능도 위와 같은 문제에 맞닥뜨렸습니다. 계속 된 회의와 언쟁을 주고 받고 결국은, 둘다 지원하는 방법으로 채택되었는데, 현실적으로 이보다 더 좋은 해결책은 없는 거 같네요. 참 어려운 문제입니다.