두번째 글 입니다...Safari, not bad, but…

두번째 글 입니다...Safari, not bad, but… 정보

두번째 글 입니다...Safari, not bad, but…

paranbiz 홈페이지 자기소개 아이디로 검색 회원게시물 (125.♡.♡.62)
2006.07.17 22:44:15
2,033

본문

Safari, not bad, but…
macromic posted in / on July 17th, 2006

음 그다지 심각하게 토론을 한다거나, 그런 글은 아닌듯 합니다.

사실 토론을 하거나 다각도에서 고찰을 하는 글을 쓰고 싶지가 않습니다.

그냥 커피한잔 들고, 읽으면서 재미를 보셨으면 합니다...^^

그냥 푸념 이라 생각하시면 됩니다......그냥 페이퍼이니까요........

계속되는 웹 브라우저간 코드 수준 호환성 문제는 꽤 많은 시간 동안 저희를 괴롭혀왔습니다. 그나마 윈도우 또는 리눅스 환경에서 주로 사용하는 웹 브라우저의 경우야 이리저리 설치해서 돌려보고 테스트해 볼 수 있었지만, Safari의 경우는 도대체 어떻게 해야 할지 몰라 무척 애를 먹었던 기억이 있습니다.

보통 엔진이 서로 다른 웹 브라우저간이라면 문제가 발생할 가능성은 높지만, 엔진이 동일하거나 같은 뿌리를 두고 있는 경우에는 약간의 버전 차이로 문제가 발생하는 경우는 그다지 많지 않습니다. 상위 호환성(Forward Compatibility)라면 별 수 없이 발생하는 문제지만, 하위 호환성(Backward compatibility)은 더더욱 자주 발생하는 문제가 아닙니다. 아마 이 때문에 Microsoft는 Internet Explorer때문에 꽤나 골치를 썩이고 있을지도 모르는 일입니다. document.all로 처리하던 HTML Element문제를 getElementById 또는 getElementByTagName으로 전환시킨다는 것은 상당한 비용을 지출하지 않는 이상 어려운 문제이고, 그렇다고 두 가지 모두를 지원하자니 웹 브라우저의 Script Parser나 Engine이 동일한 기능을 별도의 코드로 지원해야 한다는 것, 벌써부터 머리가 아파지는 군요. 물론 저희도 비슷한 일을 하고 있습니다. 이 세상 모든 Cross Browsing 연구원들, 오늘도 파이팅입니다.

Safari가 어떤 웹 브라우저인지 잘 모르시는 분이 많을 거라 생각합니다. 저희도 잘은 모릅니다. 그럭저럭 알고 있는 내용이라면 이런 것입니다. Linux의 대표적인 데스크탑 환경(글쎄요, Windows의 시작메뉴 + 상태표시줄 같은 쉘 이라고 봐야 할까요? 사실은 플랫폼에 더 가까운 것 같은데)인 KDE의 구성물 중에 KHTML이라는 것이 있습니다. 이것은 Windows의 MSHTML.dll 또는 msxml??.dll과 같은 역할을 하는, 플랫폼/운영체제 차원의 HTML Parser입니다. 어째서 플랫폼/운영체제 차원의 HTML Parser가 존재해야 하는가? 이렇게 의문이 들 수도 있지만 이에 대해서는 별도로 이야기 하도록 하겠습니다.

아무튼 이 KHTML엔진을 기반으로 별도 엔진을 제작한 것이 AppleWebKit입니다. Safari는 Apple의 Mac OS X에서 작동하는, Internet Explorer와 같이 운영체제 내에 포함되어 공급되는 웹 브라우저입니다. Mac OS X가 BSD를 기반으로 작성되었을지 모른다는 것은 누군가의 입을 통하지 않더라도 알 수 있는 것이었고(설치시에 BSD계열의 이름들이 많이 보이더군요), Linux나 BSD 등에서 많이 채용되는 데스크탑 환경인 KDE를 바탕으로 Mac OS X를 구성했을지 모른다는 추측은 그다지 막 나가는 비약은 아니라고 생각합니다. 그러니까 KHTML기반으로 Safari를 제작했을거라는 생각은, 글쎄요. 너무 막연한가요?

국내 사정상 그다지 접할 기회는 없는 웹 브라우저입니다만, 국내 Mac 사용자가 그래도 1%는 되지 않겠냐는 막연한 생각과, 최근 바람이 불기 시작한 PC에서 Mac OS X 구동시키기와 같은 이슈때문에 앞으로 꽤 사용자가 많아질지도 모르는 웹 브라우저겠다 싶은 마음, 거기에 ‘우린 표준대로 구현했잖아? Safari가 잘못돌면 적어도 우리 잘못은 아니야!’라는 쓸데없는 호승지심에 별 생각없이 ‘테스트나 해보자’ 라는 심정으로 뛰어들었습니다.

사실 Safari에 대해서 좀 더 구체적으로 알기 전에는 무척 단편적인 정보만 가지고 있어서, ‘Acid2를 최초로 통과한 웹 브라우저다’ 라든가, ‘KHTML 기반의 웹브라우저다’ 라든가, ‘그러니까 Konqueror(KDE 환경의 파일관리자, 웹 브라우저 역할을 맡고 있는, 말 그대로 Windows의 explorer.exe와 같은 존재라고 보시면 될 것 같습니다)에서 잘 돌면 Safari에서도 잘 돌거다’라는 생각을 하고 있었는데, 이것이 큰 실수였습니다.

일단 PWA2.0.PHP4.2.0.alpha.1835.20060716.macromic.unvalidated의 경우는 웹 브라우저 엔진 각각에 대해 서로 다른 액션을 취하도록 구성되어 있었는데, 이 경우 전혀 새로운 형태의 웹 브라우저가 코어에 접근해 오면 아무런 액션을 취하지 않는 문제가 있었습니다. (물론 이 문제는 다른 방식으로 구현하여, 적합한 User-Agent 정보가 없으면 무조건 Presto 호환 모드로 돌립니다) 원래 예측은 ‘아무 액션을 취하지 않고 그대로 있는다’ 였지만, ‘like Gecko’라는 User-Agent 정보 때문에 Gecko 엔진으로 인식되어 작동하더군요. Gecko 엔진도 그렇게까지 표준적인 JavaScript 엔진을 채택한 상황은 아니므로 JavaScript 처리 등에 대하여 꽤 많은 오류가 있었습니다.

그래서 KHTML에 대한 처리 코드를 심고, ‘처리 되었겠거니’하면서 방심한 채로 Safari를 돌렸는데

‘JavaScript가 활성화 되지 않았으니 JavaScript를 활성화 시키거나 다른 웹브라우저를 사용하라’는, 저희딴에는 만들면서 ‘설마 이런 메시지 얼마나 만나겠냐, 우린 안 만나겠지’ 라며 낄낄댔던 메시지를 보게 되었습니다. 물론 해당 코드는 noscript 태그 안에 있었지요. Safari 역시 JavaScript는 활성화된 상태였습니다. 도대체 무엇이 문제였을까요?

시간을 좀 거슬러 올라가보자면, XHTML에 대한 권고안은 1999년을 시작으로 2003년경 마무리 되었습니다. 저희의 단편적인 기억으로는 OS X가 대충 2001년 봄에 나왔지만(어쨌건 Windows XP보다는 먼저 출시), 무척 대중화된(?) 버전인 Tiger가 2005년 5월 데뷔니 요즘 같이 플랫폼/운영체제 차원의 HTML Parser가 중요한 시점에 XHTML 지원이 빠져있다는 것은 상당히 치명적인 사안이 아닐까 생각합니다. 물론 그렇다고 KHTML 또는 Mac OS X, Safari가 XHTML을 지원하지 않는다는 것은 아닙니다. 당연히, (시각에 따라서는)지원하는 것도 아닙니다.

W3C의 권고안 중에는, XHTML 1.1에 대한 Content-type이 정의되어 있습니다. 기존의 HTML 4.01이나 XHTML 1.0은 하던대로 text/html로 보내면 되지만, XHTML 1.1은 application/xhtml+xml이라는 Content-type으로 전송해야 합니다. 사실 여러분이 보고 계시는 이 페이지도 원래대로 하자면 application/xhtml+xml로 전송되어야 정확하다는 뜻이지요. 지금 이 글을 쓰는 시점에서 이 글은 Wordpress를 통해 작성되고 있고, Content-type을 바꾸기 위해 다른 사람이 제작한 것을 분석하기는 또 귀찮은 터라 (Metropolis Core Package중에 물론 설치형 블로그가 있습니다만, 그것은 그것대로 아직 알파버전인지라 일반 공개는 다소 꺼려지는군요) 그냥 text/html로 보내고 있습니다만, 정말로 XHTML 1.1을 준수하고 있다고 하려면 application/xhtml+xml로 보내고 있어야 합니다. 그런 의미에서, 저희 홈페이지도 반쪽 준수밖에는 하지 못하고 있는 실정입니다.

Content-Type을 application/xhtml+xml로 정의하면, Presto나 Gecko에서는 기존의 JavaScript와는 차원이 틀리게 제한을 적용합니다. document.write또는 element.innerHTML의 사용은 거의 포기해야 한다고 보시는 것이 좋습니다. ‘HTML 코드를 동적으로 삽입하여 새로운 Element를 생성하거나 기존의 Element를 삭제한다’는 것은 적어도 XHTML 1.1의 관점에서는 허용될 수 없는 것인가 봅니다. (뭐랄까, 권고안을 제대로 읽어보지 않고 작업했던 것이 이제와서 문제를 많이 일으키더군요) 그런데 Safari는 아예 application/xhtml+xml을 text/xml또는 application/xml과 동일하게 처리합니다. 아시다시피 XML문서는 JavaScript를 처리하는 경우가 없습니다. 기존에 테스트했던 환경인 Koqueror 3.5.3 (KHTML 3.5.3 엔진)에서는 아무런 문제가 없었기 때문에 마음을 놓고 있다가 참 당혹스러운 경우를 당해서 눈앞이 아찔하더군요.

그러나 아쉬운점은 여기서 그치지 않습니다. Safari, 아니 Mac OS X, 더 나아가 Apple이라는 회사는 기본적으로 사용자와 관계가 없거나 알 필요가 없는 정보면 표현하지 않는 것 같습니다. 가령 HTML 문서에 어떤 오류가 있다고 해도 그것을 제대로 Report해주지는 않습니다. Safari는 개발도구라기보다는 일반적인 어플리케이션이기 때문에 아마 JavaScript 오류도 내부적으로 기록만 해두고 별다른 경고 메시지를 보내지는 않으려고 했던 모양입니다.

이것이 틀린 것은 아닌 것 같고, 어쩌면 맞는 행동일지도 모릅니다. 장문의 경고메시지를 보여줄 것이 아니라면 (그것을 띄운다고 해서 읽을 침착한 사용자도 몇 없는 것 같고) 경고메시지는 아예 안 보여주는 것이 나을지도 모르지요. 그것을 본다고 웹 서비스를 사용하는 사용자가 고칠 수 있는 문제도 아니니까요. 그러나 웹 어플리케이션은 그것을 테스트 할 수 있는 환경이 특별하게 마련되어 있는 것도 아니고, 최소한 디버깅 정보를 볼 수 있는 메뉴 정도는 있어야 한다고 봅니다.

그러나 Safari는 ‘콘솔창에서, 애플 개발자 센터에서 찾아볼 수 있는’ 특별한 명령을 입력하지 않으면 안됩니다. 물론 활성화되었을 때 나타나는 메뉴는 여타 브라우저 못지 않게 많은 디버깅 옵션을 제공합니다. 어떤 쪽이 좋은 걸까요? 오류가 발생했지만 아무 이야기 없이 그냥 다음 작업 진행하는 프로그램과 그나마 조그만 아이콘이라도 표시해주는 프로그램. 전체적으로 Mac OS X의 UI는 감탄할만 했지만 사용자에 대한 Warning이나 Notification은 (그것이 설령 일부분에 대한 이야기일지라도) 어째 좀 아니다는 생각이 들었습니다.

엔지니어란 사람들의 특성 중의 하나가 일이 해결되면 어쨌든 기분은 상쾌하다는 것입니다만, 그렇다고 덮어놓고 좋아하는 것은 아닙니다. 여러가지 의미에서 뒷맛이 씁쓸한 경우였습니다. 분명 프로그램, 특히 하나의 플랫폼 또는 운영체제에서 중심적인 위치를 차지하는 프로그램들은 상당한 철학(혹은 개똥철학)을 바탕으로 구성됩니다. Microsoft가 왜 그동안 Internet Explorer에 Tab Browsing 기능을 넣지 않았는지, Linux 계통은 반대로 왜 Tab Browsing 기능이 그토록 활성화되고 웹 브라우저 UI의 근간이 되었는지, Windows Vista의 Aero Glass등은 무슨 생각으로 넣었는지(정말로 신작 게임 Vista가 되려는 것인지) 이러한 것들은 단지 당시에 생각을 못했기 때문일 수도 있지만, 대부분은 그보다 더 중요한 다른 무엇 때문에 그렇게 진행되었을 가능성이 있습니다.

그러나 저러나 Safari는 역시 멋진 웹 브라우저였습니다. 일단 Mac OS X라는 운영체제가 충실한 보조를 맞춰주었기 때문이겠지만, 이만큼 깔끔하고 효율성있는 UI는 쉽게 찾기 어려울 것 같습니다. 앞으로도 좋은 웹 브라우저로 발전하는 마음 뿐입니다.

출처 : http://paranbiz.com/metro/blog/