Wired의 Michael Calore 씨가 IE 팀이 참석한 "전문가에게 묻습니다" 웹 채팅에 대한 글을 작성하셨습니다.

주요 사항은 이렇습니다.
  • IE8은 CSS 2.1에 대한 완전한 전체 스펙 지원을 목표로 하고 있습니다.
  • IE8에서 가능한 CSS3는 쓰기 모드뿐입니다(세로 쓰기 지원을 위한 것입니다). IE는 이 기능을 5.x 버전때부터 지원해왔으며, 앞으로도 계속 지원할 것입니다.
  • IE8은 CSS의 border-radius을 지원하지 않습니다. 이 속성은 이미지를 사용하지 않고 경계선 모서리를 둥글게 만들 때 사용합니다. Microsoft의 Chris Wilson씨는 border-raduis가 "꽤 높은 순위로 배정되어있다"라고 했지만, IE8이 릴리스 된 후에나 진행될 듯 합니다.
  • IE9에 대한 공식적인 로드맵은 없습니다만, 네이티브 SVG 지원에 대한 가능성이 있습니다.
  • 새로운 자바스크립트 엔진도 나타날 것 같습니다. 사용자들은 이렇게 요구했습니다. "다른 브라우저들처럼 이제는 자바스크립트 컴파일에 대해서 고려해주세요. 사파리는 SquirrelFish를 도입했고 지난 주 SquirrelFish의 반응 V8에 육박하고 있죠. Mozilla는 ScreamingMonkey에 대한 작업을 시작했고요. IE9도 새 자바스크립트 엔진을 가지게 되나요?". 그에 대한 대답은 이렇습니다. "우리는 IE8과 그 이후 버전부터 자바스크립트 성능을 개선하는 일에 매우 집중하고 있습니다. 이 노력에 대한 뛰어난 앞으로의 결과물을 기대하고 있습니다."
SVG가 지원된다면 멋지겠네요. 제발 캔버스 지원이 되면 좋겠습니다. 부탁합니다, 크리스씨. 그 일을 돕기 위해 제가 Ajaxian에 뭐라고 쓰면 될까요? ;)

from What is coming up with IE8 and 9?
Posted by 행복한고니 트랙백 0 : 댓글 0

IE 8 Beta 2 Ajax 기능

2008.10.08 08:54 from [IT] Web Tech
Sunava Dutta씨가 XDR, XDM/postMessage, DOM 스토리지, 오프라인 검출 등의 Ajax 개발자를 위한 IE 8 beta 2의 확장 기능에 대해서 상세히 기술하셨습니다.

XDomainRequest(XDR)
이것은 클라이언트 사이드에서 크로스 도메인 호출을 보안성있고 쉽게 호출할 수 있도록 작성된 객체입니다. 의도하지 않은 크로스 도메인 접근을 줄이기 위해 이 객체는 클라이언트 스크립트와 서버로부터 크로스 도메인 호출에 대한 명시적인 허용를 요구합니다. 아울러, 사이트가 매시업을 위해  서드 파티의 스크립트를 직접 병합하는 위험한 방법에 대한 필요성을 감소시킵니다. 이런 방법은 서드파티에서 전체 DOM에 접근할 수 있기에 위험합니다. 이 모든 것들은 개선된 클라이언트 사이드 성능과 낮아진 서버 유지 비용으로 인해 프록시를 위한 서버군이 필요하지 않은 덕분에 가능했습니다.

Beta1 기간 동안에는 크로스 사이트 XMLHttpRequest와 Acesss Control 프레임웍을 사용하는 서드 파티 데이터의 크로스 도메인 접근과 관련한 많은 보안 정책들이 있었습니다. Beta1 때부터, 우리는 서버 사이드의 경험과 W3C의 Access Control 프레임웍의 보안을 개선하기 위해 다른 브라우저와 W3C 대면 회의의 참가자들과 함께 일할 기회를 가지게 되었습니다. 그 결과, 우리는 XDR을 클라이언트 상의 단순한 공용 서드파티 데이터 익명 요청에 대해 Access Control 영역의 문법과 지시문을 가진 명시적인 규약을 가지도록 업데이트 할 수 있었습니다(Access Control Process Model의 섹션 5.1.3).

Beta1의 XDR 업데이트로 인해 IE 8은 요청자의 직렬화된 출처값을 Origin 헤더로 전송하는 것으로 것으로 도메인의 서버로부터 데이터를 요청할 수 있게 되었습니다. IE8 Beta2 는 Beta1의 XDomainRequestAllowed:1 대신 Access-Control-Allow-Origin: *을 서버 응답으로 돌려받게 될 것입니다. 그 외 사항으로는 open 메소드에서의 상대 경로 지원과 HTTP와 HTTPS 로의 접근 제한이 있습니다.

Cross-document Messaging(XDM)
크로스 문서 메시징제가 이전에 블로깅했던 또 다른 강력한 크로스 도메인 기능입니다. 이 기능은 원격 웹 서비스에 백엔드 요청을 만드는 것보다는 사이트가 IFrame 기반으로 된 써드파티 "가젯"이나 컴포넌트가 동일출처정책(same site origin policy)을 불안전하게 위배하지 않고도 부모 문서와 직접 통신할 수 있도록 하는 것에 목적이 있습니다. 이것은 개발자들이 브라우저간에 서로 다른 방법에 의존하고 원하지 않는 부작용에 괴로워하지 않아도 되도록 함으로써 성능을 개선하고 신뢰성을 높이는 등의 장점이 있습니다. 이 기술은 또한 여러분의 페이지에서 서드 파티 스크립트를 포함할 필요가 없도록 만들어 민감한 데이터(소셜 네트웍 프로필 정보)가 여러분의 동의없이 서드 파티로 새나가는 것과 같은 잠재적인 정보 유출 취약성을 감소시킵니다.

Beta2 업데이트에서 onmessage 핸들러는 업데이트된 HTML 5.0 초안에 잘 맞도록 document 객체에서 window 객체로 옮겨졌습니다.
window.attachEvent("onmessage", HandleMessage);
또한 "scheme" + "호스트" + "기본이 아닌 포트" 의 직렬화된 형태인 e.URIe.origin으로 바꾸었습니다. 이는 수신측에서 허용 여부를 결정하는데 필요하지도 않는 민감할 수도 있는 정보를 출처 사이트로부터 URI를 통해  나르는 것보다 더 안전합니다.
if (e.origin == 'http://www.contoso.com')
{
    // 메시지 텍스트 처리
}
끝으로, HTML 5.0 초안에서 postMessage 메소드에서 targetOrigin 파라미터가 이전과 달리 필수 파라미터로 변경되었습니다. 이는 출처 <URL>이나 와일드카드 <*>를 지정함으로써 메시지의 목적지를 명시적으로 표시하도록 하는 것으로 개발자들이 에러를 덜 내도록 했습니다.
frameOther.postMessage("This is a message", "http://example.com");

DOM Storage
현재, 웹 페이지는 로컬 머신에 데이터를 저장하기 위해 document.cookie 속성을 사용하고 있습니다. 쿠키는 사이트가 도메인당 50개의 키/값의 쌍을 저장하지 못한다는 용량의 한계가 있습니다. 게다가, 쿠키 프로그래밍 모델은 귀찮고 데이터를 얻기 위해 쿠키 문자열을 파싱해야 합니다. 쿠키가 요청 헤더에 최대 4KB의 데이터를 함께 보내 서버로 클라이언트 상의 변화나 변동사항을 알려주는 것에 유용하긴 하지만, IE8은 클라이언트 상의 데이터를 영구적으로 유지할 때와 다른 탭에서 세션을 유지할 때를 대비한 보다 나은 대안을 제시합니다. W3C의 HTML 5 DOM 스토리지 객체가 그것으로, 키/값 쌍의 문자열 데이터를 위한 훨씬 간단한 전역과 세션 저장 모델을제공합니다. 사이트는 탭 또는 사이트가 살아있는 동안 혹은 사용자가 데이터를 제거할 때까지 데이터를 저장할 수 있습니다.

Beta2 업데이트에서는 영구 globalStorage 속성의 이름이 localStorage로 바뀌고, localStorage를 사용할 때 도메인 이름을 지정하지 않아도 되도록 했습니다.
// 키-값 쌍 저장.
localStorage.setItem("이름", "Sunava");
또한 저장소가 변경되었을 때 반환되는 업데이트된 onstorage HTML 5.0 이벤트를 개선했습니다. 지금은 로컬 저장소가 변경되면 URI를 반환하며 따라서 페이지의 핸들러는 저장 공간에 누가 마지막 트랜잭션을 보냈는지를 알 수 있고, 출처 창에 원본을 제공할 수도 있습니다. 더 좋은 소식은, HTML 5.0 Working Group이 우리가 Beta 1에 포함시켰던 clear 메소드를 초안에 포함시켰다는 것입니다. 이는 스크립트가 모든 키에 대해 반복하지 않고도 저장소의 접근할 수 있는 모든 데이터를 삭제할 수 있도록 합니다.

Connectivity Event
navigator.onLine 속성과 online/offline 이벤트는 현재 Windows XP/Vista에서 동작하고 있습니다. Windows XP의 접속 알림이 Windows Vista만큼 진보되어있지 않아서 이를 가능하게 하는 것이 쉬운 일은 아니었습니다. 즉, 이것은 우리가 OS 차이에 대해 걱정할 필요가 없다고 믿는 개발자들에게 많은 이점이 될 것입니다. 접속 이벤트의 값은 네트웍이 불가능한 경우에 데이터를 캐시하도록 localstorage와 연동해 사용될 때 매력적입니다.

XMLHttpRequest
IE8에서의 XDomainRequest 객체 도입을 했다고 해서 같은 도메인 상의 통신에 계속 사용될 객체인 XMLHttpRequest의 개선과 조정에 대한 우리의 관심이 사라진 것은 아닙니다. Beta1 이전의 에너지는 신뢰성을 위해 몇몇 버그를 수정하고, 초안 명세와 우리의 규약을 개선하고 명확하게 하기 위해 Web Apps Working Group과 작업하는 것에 집중되어 있었습니다. Beta1에서 개발자들의 편의를 위해 도입된 timeout 메소드는 현재 XMLHttpRequest 스펙에 적용되어 있습니다.
// Sets timeout after open to two seconds.
xhr.timeout = 2000;

ToStaticHTML, to JSON, and fromJSON
XDomainRequet나 Cross-document Messaging을 이용해 서드 파티로부터 받은 문자열로 무엇을 하시겠습니까? 오늘날 스크립트 인젝션과 크로스 사이트 스크립팅(Cross-site Scripting : XSS) 공격이 증가함에 따라 이들을 안전한 파서를 통해서 받는 방법이 환영받고 있습니다. Erix Lawrence씨가 IE 8 보안을 위한 Comprehensive Protection이라는 글에서 기술했듯이, toStaticHTML은 실행가능할 수 있는 컨텐트를 제거함으로써 문자열을 무해하게 만드는 강력한 방법을 제공합니다.
// Calling:
window.toStaticHTML("This is some <b>HTML</b> with embedded script following... <script>alert('bang!');</script>!");

// will return:
This is some <b>HTML</b> with embedded script following...!
추가로, IE8 Beta2의 toJSON과 fromJSON 메소드는 네이티브가 아닌 JavaScript 시리얼라이저와 디시리얼라이저에 비해 개선된 성능을 제공합니다. 구현체는 Douglas Crockford씨의 json2.js API를 사용한 네이티브 JSON 핸들링에 대한 ECMAScript 3.1 제안에 기반하고 있습니다. 네이티브라는 성능상의 이점외에도 JSON 파서는 eval() 메소드의 안전한 대안을 제공합니다. 이 메소드는 JSON 객체를 되살리는 일반적이고도 위험한 방법이어서, 임의의 스크립트 함수가 실행되도록 할 수 있었습니다.
From IE 8 beta 2 Ajax features

'[IT] Web Tech' 카테고리의 다른 글

alert()에게 작별을  (3) 2008.10.17
웹 에디터 비교  (4) 2008.10.14
iPhone in Action 일부 챕터 다운로드  (0) 2008.10.10
Pyjamas: Python을 위한 GWT  (0) 2008.10.08
IE 8 Beta 2 Ajax 기능  (0) 2008.10.08
JavaScript로 만든 팩맨  (0) 2008.09.20
iPhone에서도 SVG를 사용할 수 있습니다  (0) 2008.09.19
리눅스에서도 AIR를!!  (0) 2008.09.18
iPhone Web App: Spin the Bottle  (0) 2008.09.18
Posted by 행복한고니 트랙백 0 : 댓글 0
Firefox3 정식 공개이벤트 덕분에 다른 브라우저 소식은 묻힌 것 같습니다. PPK씨가 몇가지 소식을 쓰셨네요.

IE

새로 릴리스 된 것은 없지만 지난 2주간 중요한 질문에 대한 답변이 달렸습니다. IE8b2이 8월에 출시된다라는 것과 새로운 IE=EmulateIE7이 <meta> 로 변경할 수 있도록 추가된 것입니다.

Firefox

Firefox 3 최종판이 공개되었습니다.

추가로, Firefox 3.1 알파 (FTP)가 다운로드 가능해졌고, 이 버전에서는 모든 CSS3 셀렉터에 대한 지원이 추가되었다고 합니다.

Safari

Apple에서 Apple Developer Connection을 통해 Safari 4 개발자 프리뷰를 공개한 것 같습니다. 하지만, 실제 다운로드 링크는 어디있는지 모르겠습니다. 애플에서는 언급도 없군요.

다운로드 경로를 알게되면, 코멘트를 남겨주셨으면 합니다.

Opera

예상했던 대로, Opera 9.5 버전이 릴리스되었습니다; 보다 자세한 정보는 이 기사를 참고하시기 바랍니다.


from Browser News: IE, FF, Safari, and Opera
Posted by 행복한고니 트랙백 0 : 댓글 0
IE팀이 IE 8의 IE=EmulateIE7 이라는 글을 통해 X-UA-Compatible 이라는 새로 작성한 헤더에 대해 말했습니다.

우리는 이미 "IE7 표준 모드"로 페이지를 표시하도록 하는 IE=7 이 있습니다. 이것은 해당 경로에 있는 모든 페이지에 quirks와 표준 모드를 강제하는 것이어서 사람들이 일부만 non-quirks로 사용할 수 있는 방법을 문의했었습니다. 그래서 새로운 옵션이 만들어진 것이죠:
우리가 받은 IE8 Beta 1에 대한 피드백에 대한 응답으로, 우리는 이 문제를 처리하기 위해  "IE-EmulateIE7" 태그를 도입했습니다. EmulateIE7은 IE8에 표준 DOCTYPEs을 IE7 모드에서 보여주고, Quirks DOCTYPE은 Quirks 모드에서 보여달라고 요구합니다. 우리는 이것이 대부분의 경우에 선호하는 IE7 표준모드가 될 것이라고 생각합니다. IE=EmulateIE7의 지원은 IE8 Beta 1에 대한 6월 IE 보안 패치의 일부가 되었습니다. 이 업데이트를 설치하시면 사이트를 정상적으로 보이게 하기 위한 EmulateIE7 태그를 적용했는지 검증할 수 있습니다.

HTTP 헤더를 구현하는 것은 컨텐트를 업데이트 하지 않고 사이트의 대부분을 IE7에서 했던 것과 같이 보여주고 싶을 때 유용합니다. 이 헤더를 포함하면 사이트에 속한 어떠한 Quirks 모드 페이지라도 지켜줍니다.

각각의 페이지에 메타 태그를 사용하는 것은 발행자가 특정 페이지만 IE7에서와 같이 렌더링하고 싶을 때 유용합니다.

X-UA-Compatible 태그와 헤더는 현재 있는 DOCTYPE을 덮어씁니다. 또한, 페이지에 의해 정의된 모드는 HTTP 헤더보다 우선합니다. 예를 들어, EmulateIE7 HTTP 헤더를 사이트에 추가하고, IE8 모드로 보여주고 싶은 특정 페이지를 설정할 수도 있습니다(content="IE8"이라는 메타태그 사용).

IE=EmulateIE7 호환 태그를 사용하는 것은 사이트의 컨텐트를 보다 표준 호환적인 컨텐트로 업데이트하기 전까지 사용자의 현재 경험을 지속할 수 있는 가장 간단한 방법입니다. 비록 이 태그를 추가하는 것이 대부분의 표현 이슈를 방지할 수 있을 지는 모르나 사이트에서 IE8인지 올바르게 탐지하는 것도 필요해지게 됩니다. IE8 문서 호환성과 브라우저 탐지에 대해 보다 많은 정보는 IE 호환성 센터를 방문해보시기 바랍니다.

from X-UA-Compatible: IE=EmulateIE7
Posted by 행복한고니 트랙백 0 : 댓글 0
IE 8 이 8월에 나올 예정이라고 빌 게이츠가 TechEd에서 개발자들을 향한 자신의 마지막 연설에서 밝혔습니다. 여러분이 어떻게 생각하든 그는 소프트웨어 산업의 창궐을 도운 하나의 아이콘입니다. 빌 게이츠와 스티브 잡스가 아니면 누가 그럴 수 있었겠습니까? :)

다시 IE 얘기로 가서 그는 Internet Explorer와 IE 8이 두 달간 어떻게 업데이트 될 것인지 말했습니다:
빌 게이츠는 또한 몇년에 걸쳐 회사의 자산이자 재앙이 되어버린 Microsoft의 중요한 웹 기술인 Internet Explorer(이하 IE)에 대해 강조했습니다. 비록 그것이 Microsoft로 하여금 Web 브라우징 기술에서 지배적인 지위를 가지도록 해주었지만, 또한 오늘날 Microsoft에 가장 많이 나타나는 반독점법 불행을 유발했습니다. IE는 또한 지난 몇년간 Mozilla Firefox라는 오픈소스 브라우저가 추종자들을 모으며 Microsoft가 자신들의 제품(=IE)을 발전시키고 보다 혁신적으로 만들도록 압박해옴에 따라 타격을 받은 바 있습니다.

빌 게이츠는 IE의 차기 버전, IE 8 beta 2가 8월에 출시될 것이라고 밝혔습니다. 그는 또한 그가 Microsoft에서 보낸 세월동안 흥미있어 했던 것들에 대해 말했습니다 -- 인간과 컴퓨터가 그들 각각이 자신들과 상호작용하는 것과 유사한 방식으로 상호작용할 수 있는 자연스러운 휴먼 인터페이스 기술입니다. 지난주에, Microsoft 는 Windows의 차기 버전인 Windows 7이 그가 연설에서 언급한 것과 같이 터치스크린 기술을 포함하게 될 것이라고 밝혔습니다.
IE 8이 멋진 모습으로 출시되었으면 좋겠습니다.

from IE 8 beta 2 coming in August on Ajaxian
Posted by 행복한고니 트랙백 0 : 댓글 0

IEBlog에 IE 8 이 postMessage지원한다는 글이 올라왔습니다. 멋진 소식이죠.

지원 사항과 사용 사례에 대한 것은 MSDN 기사를 보라고 링크해두었더군요.

Jeff Walden씨는 "현재의 IE 8 베타가 구현한 인터페이스는 하위 호환성을 보장하지 못하는 방법으로 여러 버전에 걸쳐 HTML5 스펙에 뒤쳐져 있습니다, 따라서 이를 경험해보고자 하신다면, 여러분이 작업한 것이 앞으로 나올 IE8에서 깨질 수도 있음에 주의하십시오."라고 주의시켰으며 차이점에 대해 상세히 설명했습니다.

현재의 스펙을 구현한 것은 Firefox 3 RC 1 와 Webkit Nightly 밖에 없는 것 같습니다.

from IE8 and Cross Domain Messaging on Ajaxian
Posted by 행복한고니 트랙백 0 : 댓글 0
from Martian Headsets on Joel on Software

이제 곧 웹 개발자들이 있는 커뮤니티에서 발생한 모든 플레임 전쟁(주: 격렬한 논쟁)의 대장을 보게 될 것입니다. (그것에 비하면) 스탈린 그라드의 전투쯤은 시누이가 할머니와 차마시다가 뛰쳐나가 머스탱(주: 자동차 상표)을 나무에 들이받은 것쯤으로 보일 겁니다.

다가올 이 전쟁은 Internet Explorer의 다음 버전, 8.0의 개발팀을 이끌고 있는 Microsoft의 Dean Hachamovitch 이 주도할 것입니다. IE8 팀은 결정을 내리는 중입니다. 세상을 바라보는 두 가지 방식 중간에 있는, 문제가 될 게 너무도 확실하고 뻔한 바로 그 결정을 말이죠. 그것은 보수주의자와 자유주의자의 차이이며, "이상주의자"와 "현실주의자"의 차이입니다. 또한 한 가족을 분단시키는 거대한 전세계적 지하드(주: 무슬림들의 성전聖戰)이며, 기술자와 컴퓨터 과학자, 렉서스와 올리브 나무입니다(주: Thomas Friedman씨의 책에서 차용한 것입니다).

그리고 답도 없습니다. 하지만 지켜보기에는 정말 정말 재밌을 겁니다. 플레임 전쟁에 참여하는 참여자의 99%는 자기가 무슨 말을 하고 있는지도 모르거든요. 단순한 흥미거리만은 아닙니다:  상호운용가능한(interoperable) 시스템을 설계해야할 개발자라면 반드시 읽어봐야 할 필요가 있습니다.

플레임 전쟁은 "웹 표준"이라 불리는 이슈에 초점이 맞추어져있습니다.
Dean이 이렇게 말하더군요:
모든 브라우저는 "표준" 모드가 있고 그것을 "표준 모드"라 부릅니다. 또한 브라우저에서 웹 표준을 잘 구현하기 위해 그것을 사용합니다. 서로 다른 브라우저의 각 버전들이 자신들의 (고유한) 웹 표준 지원을 발전시켰기 때문에 서로 다른 브라우저의 각 버전은 자신만의 표준모드가 있습니다. Safari3의 표준모드, Firefox2의 표준모드, IE6의 표준모드, IE7의 표준모드가 존재하며 그들은 모두 다릅니다. 우리는 IE8의 표준모드를 IE7의 표준모드보다 더욱 더 좋게 만들려고 합니다.
그리고 모든 문제는 IE8이 어떻게 하는지의 아주 사소한 결정에 달려있습니다. 아마도 IE7에서만 테스트되었을 "표준" 지원을 선언한 그 웹페이지를 만났을 때 말이죠.

젠장할 표준이 뭐죠?

모든 기술적 시도에 대한 표준이 없나요? (아니요. 있습니다)

보통은 잘 작동하지 않나요? (음.....)

왜 "웹 표준"이 이렇게 엉망으로 뒤죽박죽이 되어버렸을까요? (Microsoft만의 잘못은 아닙니다. 여러분의 잘못도 있어요. 그리고 Jon Postel(1943-1998)의 잘못도요. 그 부분은 조금 있다 설명하죠)

해결책이 없습니다. 각각의 해결책들은 굉장히 잘못됐습니다. ars technica의 Eric Bangeman는 이렇게 썼습니다 “IE팀은 W3C 표준의 완전 준수와 이전 버전의 IE와의 호환성 사이의 좋은 길로 가야합니다” 이 말은 틀렸습니다. 그건 좋은 길이 아닙니다. 그건 폭이 없는 길입니다. 걸을 곳이 없는거죠. 그들은 해도 욕먹고 안해도 욕먹을 겁니다.

그게 제가 이 문제에 대해서 한쪽편을 들지 않는 이유입니다. 하지만 최소한 모든 소프트웨어 개발자들은 표준이 어떻게 동작하고 어떻게 동작해야 하고 어쩌다 우리가 이런 곤경에 빠졌는지 알고 있습니다. 그래서 제가 이 글에서 그 문제를 조금 설명하려고 하는 것이고, 아마도 그게 Microsoft Vista 가 배를 산으로 몰고간 이유와 같다는 것을 알게될 것입니다. 그것은 제가 썼던 Microsoft의 Raymond Chen 진영(실용주의자) vs. MSDN 진영(이상주의자)의 대립과 동일한 이슈입니다. MSDN 진영이 이기고 아무도 Microsoft Office 2007에서 자기들이 즐겨쓰던 명령이 어딨는지 모르고, 아무도 Vista를 원하지 않습니다. 그건 다 같은 얘기입니다. 당신이 이상주의자("빨강")이건 실용주의자("파랑")이건 말이죠.

다시 처음으로 돌아가보죠. 먼저 같이 작동하는 것들을 생각해봅시다.

뭐가 있을까요? 사실, 뭐든지 가능하죠. 연필과 연필깎이, 전화와 전화시스템. HTML 페이지와 웹 브라우저. Windows GUI 응용프로그램과 Windows 운영체제. Facebook과 Facebook 응용프로그램. 스테레오 헤드폰과 스테레오.

이런 두 가지 물건 사이의 접촉점에는, 서로 일치해야만 하는 것들이 있습니다, 그렇지 않으면 같이 사용할 수 없거든요.

간단한 예를 들어 설명해보죠.

당신이 화성에 갔는데 거기 살고 있는 존재들에겐 휴대용 뮤직 플레이어가 없는 것을 상상해보세요. 그들은 여전히 붐박스(주: 아주 큰 테입 카세트)를 사용하고 있습니다.

엄청난 대박 찬스인 것을 알아챈 당신은 휴대용 MP3 플레이어(화성에선 Qxyzrhjjjjukltks라 부르지만 그건 잠시 잊으세요)와 호환되는 헤드폰을 팔기 시작합니다. MP3 플레이어에 헤드폰을 접촉하기 위해서, 당신은 다음과 같은 금속 잭의 일종을 발명합니다:

검은색 금속 잭


당신이 플레이어와 헤드폰을 제어할 수 있기 때문에, 당신은 당신의 플레이어와 당신의 헤드폰이 잘 동작할 것이라는 것을 보증할 수 있습니다. 이런 것이 ONE TO ONE 시장입니다. 한 개의 플레이어와 한 개의 헤드셋이죠.
One to One 시장

어쩌면 당신은 명세서를 쓸지도 모릅니다. 새로운 업자가 다른 색상의 헤드폰을 만들어주기를 바라면서 말이죠. 화성인들은 자기 귀에 꽂는 물건의 색깔에 예민하거든요.
명세서 샘플 이미지
그리고 당신은 명세서를 쓰다가 1.4볼트여야 한다고 적는다는 것을 잊어버린 겁니다. 그만 깜빡해버린거죠. 그래서 의욕에 찬 첫번째 제조업자가 100% 호환되는 헤드폰을 만들었는데, 스피커는 0.014 볼트를 기준으로 만들어졌습니다. 그가 시제품을 시험하면 그의 헤드폰이나 듣는 사람의 고막이 다 날아가버리는거죠. 그러면 그는 또 몇번의 조정을 통해 우연히 알맞게 잘 동작하는 헤드폰, 당신의 헤드폰보다 2 옹스트롬 정도 거친, 을 얻게 됩니다.

점점 많은 제조업자들이 호환 헤드폰을 내놓으며, 이내 우리는 ONE TO MANY 시장으로 진입합니다.
One to Many 시장
아직까지는 좋습니다. 이제 우리는 헤드폰 잭에 대한 de-facto 표준을 가지게 되었습니다. 기술된 명세는 완벽하지도 충분하지도 않지만 호환 헤드폰을 만들고 싶은 사람은 단지 당신의 개인 오디오 장치에 잭을 꽂아보고 테스트 해보고, 잘 동작하면 다 잘된 것이고, 그 뒤에 그걸 팔 수 있고, (그 제품은 또) 정상적으로 작동할 것입니다.

당신이 새로운 버전 - Qxyzrhjjjjukltk 2.0 - 을 제작하겠다고 마음먹기 전까지는 말이죠.

Qxyzrhjjjjukltk 2.0은 전화 기능을 넣기로 합니다(화성인들에게 휴대폰이 없는 것을 알아차린거죠). 그래서 헤드폰은 한 개의 추가 컨덕터를 필요로 하는 내장 마이크가 필요하게 됐습니다. 당신은 새 커넥터를 호환이 전혀 되지 않는, 멋지지도 않은, 확장 공간은 넉넉한 녀석으로 재작업합니다:
새 커넥터
Qxyzrhjjjjukltk 2.0이 완성되었지만 시장에서 처참하게 실패하고 맙니다. 네, 좋은 전화기는 맞아요, 하지만 아무도 그걸 중요하게 생각하지 않습니다. 고객이 중요하게 여기는 것은 헤드폰의 커다란 연결부였죠. 아까도 말했지만 화성인들은 자기들 귀에 꽂는 물건의 색깔에 매우 민감합니다. 이 때쯤 대부분의 일반적인 화성인들은 폼나는 헤드폰들을 보관함에 가득 모아놓았거든요. 당신이 보기엔 다 같은 빨간색으로 보일지 몰라도, 화성인들은 빨간색의 농도에 당신은 상상도 못할만큼 매우 매우 민감합니다. 화성의 최신 하이엔드 부품은 헤드폰 보관함이 될 터입니다. 농담아닙니다.

새 잭이 히트치지 못하자 당신은 재빨리 새로운 형태를 생각해냅니다
새로운 형태의 잭

이제 당신이 마이크 신호를 위한 컨덕터를 하나 더 제공하기 위해 메인 축을 분리해냈음을 명심하세요. 하지만 문제는 당신의 Qxyzrhjjjjukltk 2.1 은 헤드셋에 마이크가 있는지 없는지 알 수 없다는 겁니다. 전화기능의 사용여부를 판단하기 위해서는 그걸 알아야 하는데 말이죠. 그래서 당신은 작은 프로토콜을 만듭니다. 새 장치는 마이크 핀에 신호를 보내서 즉시 마이크를 찾고 만약 있다면 그건 세개짜리 컨덕터 플러그일 것입니다. 그러므로 헤드셋에 마이크가 없으면 단지 음악만을 재생하는 하위 호환성 모드로 가는거죠. 간단하지만, 이것이 프로토콜 절충(protocol negotiation)입니다.

이젠 더이상 ONE-MANY 시장이 아닙니다. 모든 스테레오 장치들은 같은 회사에서 만들어지고, 줄줄이 여러개가 있는 형태이죠, 그래서 저는 이를 SEQUENCE-MANY 시장이라고 부르겠습니다:
Sequence to Many 시장
여러분이 이미 알고 있는 SEQUENCE-MANY이 몇 개 있습니다:
  1. Facebook | 약 20,000 개의 Facebook 응용프로그램
  2. Windows | 약 1,000,000 개의 Windows 응용프로그램
  3. Microsoft Word | 약 1,000,000,000 개의 Word 문서
이 외에도 수백가지의 다른 예가 있습니다. 기억해야할 핵심은 왼편의 장치가 새 버전을 출시할 때, 오른편에 있는 예전 버전의 제품과 작동하던 구버전의 악세사리들과 자동-하위-호환성을 유지해야 한다는 것입니다. 이런 오래된 악세사리들은 새 제품을 염두에 두고 설계된 것이 아니기 때문이죠. 화성의 헤드폰은 이미 만들어졌습니다. 당신은 그들 모두를 되돌리거나 바꿀 수 없죠. 새로 만들어진 제품을 옛날 제품이 옛날 헤드폰과 작동하던 그대로 되도록 바꾸는 것이 훨씬 더 쉽고 훨씬 더 현명합니다.

또한 제품을 개선하고 새로운 기능을 추가하고 싶어하는 당신은 새로운 장치에 걸맞는 새 프로토콜을 필요로 할 것입니다. 가장 현명한 방법은 두 종류의 제품이 모두 그들이 최신의 프로토콜을 지원하는지 여부를 결정함에 있어 조금의 융통성을 두는 것입니다.

SEQUENCE-MANY는 Microsoft가 성장한 세상입니다.

하지만 살짝만 뒤틀면, MANY-MANY 시장이 기다리고 있습니다.

몇년이 지났습니다; 당신은 여전히 Qxyzrhjjjjukltks을 미친 듯 팔고 있습니다; 하지만 이제는 시장에 Qxyzrhjjjjukltk의 유사품들이- 오픈 소스 FireQx와 수많은 헤드폰 등 - 많이 나와있고, 모두들 헤드폰 잭을 바꿔야만 하는 새 기능을 계속 개발하고 있으며, 이런 사실은 헤드폰 제조사들을 미치게 합니다. 모든 유사품을 테스트 하는 것은 힘들고 시간이 많이 필요하거든요. 솔직히 대부분의 업체들은 시간이 없어서 가장 많이 사용되는 Qxyzrhjjjjukltk 5.0으로 테스트해보고 작동하면 좋아합니다. 하지만, FireQx 3.0에 헤드폰을 꽂으면 스펙의 애매한 부분, 아무도 제대로 이해하지 못한 hasLayout(모두가 우천시 hasLayout 속성이 true가 되고 와이퍼 기능을 위해 전압을 증가시켜야 한다고는 알고 있지만 스펙에 써있지 않아서 우박이나 눈도 비로 가정할 것인지에 대해 논란이 있는)에 대한 아주 작은 오류때문에 다 날려먹는거죠. FireQx 3.0 은 눈을 비로 취급합니다(당신은 눈이 내릴 때도 와이퍼가 필요하기 때문에 Qxyzrhjjjjukltk 5.0 은 그렇게 동작하진 않습니다). 그 기능을 만든 프로그래머는 눈이 없는 화성의 온대지방에 살고 있는데다가 운전면허도 없거든요. 아, 화성에도 운전면허는 있습니다.

결국에는 어떤 지루하고 짜증나는 사람이 자기 블로그에 장문의 글을 써서 Qxyzrhjjjjukltk 5.0가 가진 버그를 이용해서 Qxyzrhjjjjukltk 5.0을 FireQx 3.0처럼 동작하도록 하는 사용법 - 눈을 조금 녹여서 비로 인식하게 하는거죠 - 을 설명합니다. 웃기지만, hasLayout 호환성문제를 해결해야만 하니까 다들 그렇게 합니다. 후에 Qxyzrhjjjjukltk 팀이 6.0에서 그 버그를 고치면 당신은 다시 엉망이 되겠죠. 그럼 다시 와이퍼 달린 헤드폰이 두 장치에서 동일하게 동작하도록 하기 위해 새로운 버그를 찾아야만 할 것입니다.

자. 이것이 MANY-MANY 시장입니다. 왼편에는 서로 비협조적인 다수의 플레이어들이 있고, 오른쪽에는 플레이어와 관련된 수없이 많은 물건들이 있죠. 또한 그들 모두는 결점이 있습니다. 사람은 실수를 하기 마련이니까요.
Many to Many 시장
물론 이것이 바로 HTML 에서 우리가 처한 상황입니다. 여러개의 브라우저와 문자 그대로 억소리 나는 웹페이지들이요.
Many to Many 시장 : 웹브라우저와 웹페이지
수년간 MANY-MANY 시장에서 일어난 일은 “모든 플레이어”(=휴대용 플레이어)에게 8억개의 웹페이지를 정확하게 표시할 수 있는 공평한 기회를 주기 위한, 심지어 더 중요한 것은, 이런 8억개의 페이지를 만드는 디자이너들이 한개의 브라우저에서만 테스트하기 위한 “표준”에 대한 외침과 부르짖음이었습니다. “웹표준”을 사용하면 모든 페이지를 모든 브라우저에 대해 테스트하지 않아도 다른 브라우저에서도 잘 동작하게 되는 거였죠.
Many to Many 시장과 웹 표준
보다시피 이론적으로는 many-many 테스트 대신에, many-표준, 표준-many 테스트만 있고, 당신은 원래는 약간의 테스트만 하면 됩니다. 이상적인 세계에선 버그란 존재하지 않으므로 각각의 브라우저에 있는 버그를 피해가기 위해 당신이 웹페이지에 작성한 브라우저 종속적인 코드에 대해서는 언급하지 않겠습니다.

위의 얘기는 꿈입니다.

웹에서의 실상은 문제가 조금 있습니다: 여기서만 동작하면 모든 브라우저에서도 정상적으로 동작한다고 보증해줄 레퍼런스 구현체가 없기 때문에, 웹 페이지를 표준에 맞춰 테스트 할 방법이 없습니다. 이런 일은 존재하지 않는 것이죠.

그러니 당신은 읽어보지도 못했거나 완벽히 이해하지 못한(설혹 이해했다쳐도) 표준 문서 뭉치들에 대해서 완전히 당신 머리속의 사고(思考) 실험을 통해 테스트 할 수 밖에 없는 겁니다.

그런 문서들은 상당히 혼동스럽습니다. 스펙 선언은 이런 식이죠. “블럭 박스(유동하지 않고 절대적으로 위치되지 않는) 다음에 선행 박스가 따라오면, 그 선행 박스는 블럭 박스의 첫번째 인라인 박스가 된다.(주 : trio에서 유사부분 발췌)” 저는 그런 것을 읽을 때마다 대체 어떻게 스펙에 맞추는 사람이 있는지 놀라워했습니다.

만약 스펙에 딱 맞는 페이지를 코딩했다한들 그걸 체크할 방법이 없습니다. 유효성 검사기가 있긴 하지만, 당신에게 페이지가 어떻게 보일 것인지를 알려주지 못합니다. 텍스트가 겹치고 줄은 맞지도 않으며 아무것도 볼 수 없는 "유효"한 페이지는 있으나 마나죠. 사람들이 한 두개의 브라우저로 자신들의 페이지를 체크한다는 것은 페이지가 제대로 보이는지 확인하는 것입니다. 그러므로 설혹 실수를 했다하더라도 IE와 Firefox에서 제대로만 보이면 실수를 알아차리지 못하고 넘어가게 됩니다.

그들의 웹 페이지는 새로운 웹 브라우저가 출시되면 깨져보이는거죠.

당신이 예루살렘의 극정통파 유대인 커뮤니티 - 법전 한글자 한글자를 집착할 정도로 율법을 전적으로 준수하는 - 를 한 번이라도 경험해본 적이 있다면, 율법에 맞는 일반적인 식사 규칙들이 있음에도 불구하고 타 극정통파 커뮤니티 소속 랍비의 집에서 식사하고자 하는 랍비는 단 한 명도 찾아볼 수 없었을 것입니다. 그리고 웹 디자이너들은 Mea Shearim 유대인들이 수십년 동안 알고 있었던 것을 지금 깨달아가고 있습니다. 책 한 권을 따른다고 동의했다고 해서 호환성이 보장되는 것은 아니라는 것을 말입니다. 왜냐하면 포함된 함정과 지뢰에 한 번도 안 걸리고 빠져나가기에는 그 규칙들이 너무 복잡하고 난해하게 뒤얽혀 있거든요. 차라리 식사는 말고 그저 과일이나 달라고 하는 편이 좋겠지요(주: 과일 얘기는 앞의 유대인 얘기에 이어집니다. 일반적인 식사 규칙에도 불구하고 극정통파 유대인들조차 다른 극정통파에서 식사하는 것은 [아마도 서로 다른 부분들때문에] 부담스럽게 여긴다는 것이죠. 그러니 식사는 됐고 과일이나 달라고 하는 편이 낫다는 뜻입니다).

물론, 표준은 훌륭한 목표입니다. 하지만 표준의 환상에 빠지기 전에 인간의 불완전함으로 인해 표준이 때론 오해되거나 또 때론 혼동되거나 모호할 수도 있음을 이해해야만 합니다.

지금의 정확한 문제는 표준은 하나라고 당신을 기만하고 있지만, 표준에 대해 테스트할 수 있는 방법이 없기 때문에 진정한 표준은 없다는 것입니다. 꿈같은 얘기이고, 오해 덩어리인거죠. 표준은 MANY-MANY 시장에서는 테스트 범위를 줄여줄 수가 없습니다.

DOCTYPE 은 몽상입니다.

DOCTYPE 태그를 웹페이지에 붙이고 "이게 표준 HTML이예요"라고 말하는 현세의 웹 디자이너의 행동은 오만함의 극치입니다. 그들이 알 턱이 없습니다. 그들이 진짜로 말한 것은 그 페이지가 표준 HTML이 될 의도였다는 것입니다. 그들이 진짜로 아는 것은 그 페이지가 IE, Firefox 어쩌면 Opera, Safari 에서 테스트 되었고, 잘 동작하는 것처럼 보인다는 것뿐입니다. 혹은 그게 의미하는 것도 모르면서 DOCTYPE 태그를 책에서 베껴다 썼을 수도 있고요.

완벽한 사람이 없는 현실세계에서는 스펙만 있는 표준은 없습니다. 절대적으로 엄격한 레퍼런스 구현체가 있고, 모든 사람이 레퍼런스 구현체에 대해 테스트해야하죠. 17개의 "표준"이 있을 바에는 차라리 하나도 없는게 낫습니다.

이 부분이 Jon Postel 씨가 문제를 일으킨 부분입니다. 1981년에 그는 굳건함 원칙(robustness principle)이라는 신조어를 만들었습니다: "자신이 수행하는 작업은 보수적으로 다른 사람들로부터 신호를 받을 때에는 좀 더 자유를"(주: SK에 있는 글을 참고했습니다). 모든 사람이 매우 매우 주의깊게 명세서를 따랐다면 그가 말한 것은 굳건하게 동작하는 프로토콜을 만드는 가장 좋은 방법입니다. 하지만 당신은 명세를 정확히 따르지 않은 파트너에게 말할 때는 그들의 의도를 알아차리는 만큼 그들을 용서해야만하죠.

기술적으로는 작은 글씨로 쓰는 문단은 <p><small>과 같이 쓰여야하지만 많은 사람들이 <small><p>와 같이 대부분의 웹개발자들이 이해할 수 없는 기술적 실수를 저지릅니다. 웹 브라우저는 이들의 의도가 분명하므로 이런 실수를 포용하기로 했고 어쨌거나 작은 글씨를 표현합니다.

모든 초창기 웹 브라우저 개발자들이 만든 여러분이 누구여도 사랑해주고 어떤 실수를 해도 이해해주는 초자유적이고 친근하며 마음씨 넓은 웹 브라우저들 덕분에, 이제는 에러를 가진 웹페이지들이 널려있게 되었습니다. 그리고 수없이 많은 실수들도 존재합니다. Postel의 “굳건함” 원칙은 실제로는 소용없습니다. 그 문제는 수년간 발견되지 않았습니다. 2001년에서야 Marshall Rose가 이렇게 썼습니다:
반직관적으로, Postel의 굳건함 원칙은(“자신이 수행하는 작업은 보수적으로 다른 사람들로부터 신호를 받을 때에는 좀 더 자유를”) 종종 배치의 문제를 야기했습니다. 왜냐고요? 새로 구현된 것을 처음 실무에 적용할 때, 기존 버전의 일부와 충돌하게 될 것입니다. 기존에 구현된 결과물이 굳건함 원칙을 따른다면 새로 구현한 부분의 에러는 알기 힘들겠죠. 나중에 약간은 알게 되겠지만 전체는 아니죠. 이런 과정은 몇몇 새로운 구현 결과물들을 적용할 때마다 반복됩니다. 결국, '완전히 정확하지 않은' 구현 결과물들이 최초로 구현된 것보다 덜 자유로운 구현 결과물과 마주치게 되는 것이죠. 그 뒤에 일어날 일은 말씀드리지 않아도 상상할 수 있겠죠?
Jon Postel 씨는 인터넷의 발명에 대한 막대한 공헌으로 존경을 받아 마땅하며, 악명높은 굳건함 원칙으로 그를 비난할 이유는 정말로 없습니다. 1981년은 역사가 생기기 전인걸요. 만약 당신이 Postel 씨에게 웹페이지를 만드는 9천만의 기술자가 아닌 비전문가들이 있고, 그들이 끔찍한 일을 할 수도 있으며, 잘못된 사랑으로 인해 초기 웹 브라우저 제작자들이 이런 오류를 허용해버려 어쨌든 웹 페이지가 출력되도록 할 수도 있었다고 말했다면, 그는 아마도 이것이 잘못된 이론이었다고 시인했을 것입니다. 또한 실제로는 웹 표준 이상주의자들이 옳았으며, 웹은 “반드시” 매우 매우 엄격한 표준을 기반으로 만들어졌어야 하고, 당신은 정확히 표준을 지키지 않는 모든 웹 브라우저에 대해 절대적으로 불쾌해했어야 하며, "자신의 작업은 보수적으로" 할 방법을 모르는 웹 개발자들이 제대로 하기 전까지는 어디서도 웹페이지가 표시되지 않도록 했어야 할 거라고 말이죠.

물론, 그런 일이 일어났었으면 절대로 웹이 이런 식으로 시작하지도 않았을 것이고, 아마도 대신에 우리 모두는 AT&T가 운영하는 거대한 Lotus Notes 네트웍을 사용하게 되었을 것입니다. 떨리는 일이죠.

그렇게 됐으면 좋을 뻔 했죠. 알게 뭡니까. 이렇게 되버린 것을요. 우리는 과거를 바꿀 순 없습니다. 미래만 가능하죠. 쳇, 우린 미래도 겨우 바꿀 수 있습니다.

당신이 Internet Explorer 8.0팀에 있는 실용주의자였다면 아마 Raymond Chen의 다음 문장이 뜨끔할 겁니다. 그는 어째서 WindowsXP가 구버전 Windows의 버그도 에뮬레이션해야 했는지에 대해서 썼습니다:
고객의 관점에서 시나리오를 한번 봅시다. 당신은 X, Y, Z 라는 프로그램을 샀습니다. 그리고 운영체제를 Windows XP로 업그레이드 했죠. 당신의 컴퓨터가 종종 다운되고, Z 프로그램은 아예 동작을 안하는 겁니다. 그럼 친구한테 말하게 될겁니다. "Windows XP로 업그레이드 하지마. 다운도 잘되고 Z 프로그램은 실행도 안 돼" 사실은 프로그램 X가 다운의 원인이고 프로그램 Z가 동작하지 않는 것은 문서화 되어있지 않은 윈도우 메세지를 사용했기 때문인 것을 알기 위해 당신이 시스템을 디버깅할까요? 당연히 아니죠. 당신은 Windows XP 박스를 들고 가 환불받을 겁니다. (프로그램 X, Y, Z는 몇달전에 구입한 것입니다. 30일 교환 기간이 지나버렸어요. 환불가능한 것은 Windows XP뿐입니다)

흠... 생각 중이시군요, 요즘에 맞게 바꿔볼까요:

고객의 관점에서 시나리오를 한번 봅시다. 당신은 X, Y, Z 라는 프로그램을 샀습니다. 그리고 운영체제를 Windows XPVista로 업그레이드 했죠. 당신의 컴퓨터가 종종 다운되고, Z 프로그램은 아예 동작을 안하는 겁니다. 그럼 친구한테 말하게 될겁니다. "Windows XPVista로 업그레이드 하지마. 다운도 잘되고 Z 프로그램은 실행도 안 돼" 사실은 프로그램 X가 다운의 원인이고 프로그램 Z가 동작하지 않는 것은 문서화 되어있지 않은 윈도우 메세지를 사용했기 때문인 것을 알기 위해 당신이 시스템을 디버깅할까요? 당연히 아니죠. 당신은 Windows XPVista 박스를 들고 가 환불받을 겁니다. (프로그램 X, Y, Z는 몇달전에 구입한 것입니다. 30일 교환 기간이 지나버렸어요. 환불가능한 것은 Windows XPVista뿐입니다)

제가 2004년에 포스팅했던 Microsoft의 이상주의자들이 실용주의자들로부터 거둔 승리비스타가 최악의 리뷰를 받고 잘 팔리지도 않는 이유를 직접적으로 설명해주고 있습니다.

윗 글을 어떻게 IE 팀에 적용할 수 있을까요?

고객의 관점에서 시나리오를 한번 봅시다. 당신은 하루에 100개의 웹사이트를 방문합니다. 그리고 IE8 으로 업그레이드 했습니다. 그런데 그 중 절반은 페이지가 엉망이 되고 Google Maps는 아예 동작을 안하는 겁니다.



그럼 친구한테 말하게 될 겁니다, "IE 8으로 업그레이드 하지마. 모든 페이지가 엉망이 되고 Google Maps는 아예 실행도 안 돼". 사실 X 사이트가 비표준 HTML을 썼기 때문이고 Google Maps가 동작하지 않는 것은 예전 버전의 IE에 있던 (표준이 되지 못한) 비표준 JavaScript 객체때문이라는 것을 알아내기 위해 소스 보기를 할까요? 물론 아니죠. 당신은 IE 8을 언인스톨 할겁니다(그 웹사이트들은 당신이 어찌할 수 없습니다. 그들 중 일부는 제작자가 지금은 죽었을겁니다. 당신이 할 수 있는 유일한 일은 IE 7으로 되돌아가는 것 뿐입니다).

만약 당신이 IE 8 팀의 개발자라면, 처음에는 SEQUENCE-MANY 시장에서 늘 해왔던 것과 똑같이 행동했을 것입니다. 약간의 프로토콜 절충을 하고 새 기능을 바란다고 분명하게 밝히지 않은 모든 사이트를 위해 과거 작동방식을 계속 에뮬레이션했을 것입니다. 그럼 기존의 웹 페이지들은 계속 잘 동작할 것이고, 당신은 “와! IE 8 좋아! IE 8 여신님의 모든 것을 알려줘!” 라고 말하는 페이지를 위한 새로운 기능을 제공하기만 하면 되는 것이죠.

IE팀이 1월 21일에 발표한 첫번째 결정은 실제로 그랬습니다. 웹 브라우저는 현존하는 웹 페이지들을 묵인해주었기 때문에, 웹개발자들이 증오해 마지 않는 오래되고 버그투성이의 IE7에서와 마찬가지로, 아무도 자신들의 웹 사이트를 바꿀 필요가 없었습니다.

실용주의적인 기술자는 IE 팀의 첫번째 결정은 옳았다는 결론에 도달할 것입니다. 하지만, 젊은 이상주의자 "표준" 인간들은 불섶으로 뛰어들고 있습니다.

IE는 그들이 말한대로 ”IE8으로 테스트되었음!”이라는 태그없이 웹 표준 경험을 제공해야 합니다. 모든 빌어먹을 웹페이지들은 대여섯개의 유명 브라우저에서 동작하게 하기 위해서 서른 일곱가지의 망할 핵을 써야만 합니다. 망할 핵은 충분합니다. 현존하는 8억개의 웹페이지들은 전부 젠장입니다.

IE팀은 흔들렸습니다. 그들의 두번째 결정, 제 생각엔 끝이 아닐 것 같은, 두번째 결정은 이상을 따랐으며, “표준-준수”를 선언한 모든 웹 사이트를 그 사이트가 IE8에 맞춰 설계되고 테스트했다고 가정합니다.

하지만, 제가 IE8으로 가본 대부분의 웹 사이트들은 어떤 식으로든 깨지더군요. JavaScript를 많이 사용했다 싶은 사이트들은 대부분 죽어버렸습니다. 상당히 많은 페이지들에는 시각적 문제가 있었습니다: 객체가 잘못된 위치에 있거나 팝업 메뉴가 아래로 뜨거나, 한 가운데에 있는 알 수 없는 스크롤바. 어떤 사이트는 더 이해하기 어려운 문제도 있었습니다: 겉모습은 괜찮아보였는데, 계속 사용하면 중요한 폼이 전송되지 않거나 빈 페이지가 나타나는 일이 발생했습니다.

에러가 없는 웹 페이지는 없습니다. 그 페이지들은 웹 표준을 준수해 작성된 보통의 웹사이트입니다. 하지만 IE6와 IE7은 스펙을 제대로 지키지 않았고, 그래서 이런 사이트들은 약간의 핵을 사용합니다, "Internet Explorer에서는... IE의 버그를 보정하려면 이 부분을 오른쪽으로 17 픽셀 움직여야합니다".

IE 8도 IE 입니다. 하지만 웹 표준에 따라 작성된 페이지에서 17 픽셀 왼쪽으로 이동한 버그는 더이상 없습니다. 그래서 사용된 코드은 이제 완벽히 합당한 이유로 더 이상 제대로 동작하지 않습니다.

IE 8은 "IE7 호환 모드로 동작" 버튼을 누르기 전까지 대부분의 웹 페이지를 정상적으로 표현하지 못합니다. 이상주의자들이야 신경안쓰겠죠: 그들은 페이지를 바꾸라고 합니다.

어떤 페이지들은 바꿀 수가 없습니다. CD-ROM 으로 구워진 것일 수도 있습니다. 또는 만든 사람이 죽었을 수도 있어요. 이들 중 대부분은 4년전에 디자이너에게 돈주고 만든 사이트가 왜 이제와서 제대로 동작안하는지, 무슨 일이 일어나는지 전혀 모르는 사람들에 의해 만들어졌습니다.

이상주의자들은 기뻐합니다. 수백명이 IE blog에 몰려가 자기들 생애 처음으로 Microsoft 가 좋은 일을 한다고 말할 겁니다.

시계를 봅니다.

틱, 틱, 틱

곧, 여러분은 포럼에서 이런 사람들을 보게 될 것입니다:
IE8을 다운받았는데 버그가 있습니다. "HP" 같이 제가 자주 가는 웹사이트가 너무 너무 작아서 글씨를 읽기 무지 힘듭니다. 어떤 때는 인터넷이 너무 느려지기도 하고요. Google Maps를 이용하려는데, 여기저기 겹쳐져서 사용할 수가 없습니다.

흐음. 당신들 자만가득한 이상주의자들은 이 초보/컴맹을 보면서 비웃겠지요. 고객은 바보가 아닙니다. 그녀는 당신 마누라예요. 그러니 그만 비웃으시죠. 세계의 98%가 IE8을 인스톨하고 이렇게 말할겁니다. "버그가 있어서 내 사이트를 볼 수가 없네요". 그들은 실제로는 어디에도 구현되어있지 않은 몽상적이고 관념적인 “표준”을 준수하는 웹 브라우저를 만드는 당신들의 광신도적인 추종을 탓하지 않습니다. 지저분한 핵에 대한 이야기를 듣고 싶어하지도 않습니다. 그저 실제 웹사이트가 웹 브라우저에서 잘 보였으면 할 뿐이죠.

보시다시피, 두 진영 사이 거대한 균열의 끔찍한 예를 들었습니다.

웹 표준 진영은 트로츠키주의자들처럼 보입니다. 당신은 그들이 좌파라고 생각하겠지만 당신이 웹표준에 맞추어 웹사이트를 만들었는데도 작동하지 않을 때 이상주의자들은 미국에서 가장 터프한 보안관인 Joe Arpaio가 됩니다 ”네가 잘못해서 사이트가 깨져보이는게 당연하다. 네 웹사이트의 80% 이상이 작동하지 않아도 난 상관안해. 분홍 잠옷을 입고 15센트짜리 샌드위치를 먹으며 쇠사슬에 묶여 일해야 하는 감옥으로 널 보내주지. 온 국민이 감옥에 있어도 상관없다. 법은 법이다”

반면에 우리가 감성적이고 열정적이고 경계가 모호한 타입인 실용주의를 선택했다면 이랬을 겁니다 “그냥 IE7 모드를 기본값으로 하면 안되? 한줄이면... 짠~ 해결했어!"

내막이요? 제 생각엔 이렇게 진행될 것 같습니다. IE8팀은 모든 사람들에게 IE8이 기본값으로 웹 표준을 지원한다고 알릴 것이고, 꽤 오랜 기간 동안 베타테스트를 하며 사람들에게 그들의 웹페이지가 IE8에서 잘 작동하는지 테스트해달라고 사정할 것입니다. 그리고 출시일이 다가오고 겨우 32%의 웹페이지만이 제대로 보이게 되면, 이렇게 말하겠죠, “여러분, 정말 죄송합니다. IE8 표준 모드를 기본으로 제공하고 싶었지만 제대로 동작하지도 않는 브라우저를 출시할 수는 없습니다”, 그러면서 실용주의적인 결정으로 되돌아가게 될 것입니다. 만약 그렇지 않는다면, Microsoft의 실용주의자들이 오랫동안 힘을 잃었기 때문일 겁니다. 그런 경우라면, IE는 시장 점유율을 많이 잃게 되겠죠. 이상주의자들을 헛되이 기쁘게 할 뿐입니다. 아마 Dean Hachamovitch 씨의 연말 보너스는 단 1센트도 줄지 않을 것입니다.

봤죠? 해결책은 없다니까요.

늘  그렇듯 이상주의자들이 원칙에선 100% 옳고 실무에선 실용주의자들이 늘 옳죠. 이 논쟁은 몇년은 갈 겁니다. 이 논쟁이 세상을 둘로 나누고 있습니다. 만약 인터넷 플레임 전쟁에 대비해 비상식량을 사둘 생각이라면, 바로 지금이 적기입니다.

_____________________

상당히 긴 글인데다가 구어 혹은 문화적 표현이 많아서 오역이 있을 수도 있습니다(사실 있을 거라고 확신합니다 -_-). 오역에 대해서는 의견주시면 즉시 반영하도록 하겠습니다. (__)

'[IT] Joel on Software' 카테고리의 다른 글

왜 테스터인가?  (0) 2010.02.04
화성의 헤드셋  (5) 2008.04.15
Posted by 행복한고니 트랙백 1 : 댓글 5

IE 8 보안 업데이트

2008.04.13 05:43 from [IT] Web Tech
from IE 8 Security Updates on Ajaxian

Microsoft가 일련의 보안 업데이트를 내보냈습니다. 그 중에는 IE8 보안 Part I: DEP/NX 메모리 보호 에 언급된 것도 있었습니다.

다음 몇 주에 걸쳐, 우리는 안전 필터같은 Beta 1의 보안 개선과 보다 안전한 매시업을 위한 AJAX 기능(XDomainRequest과 XDM)에 대해 상세히 블로그에 올릴까 합니다. 이것이 릴리스의 보안 노력의 전체 목록은 아닙니다. 곧 앞으로의 마일스톤이 진행되는 동안 더 말할 기회가 있을 것입니다.

Internet Explorer 8 보안 기능은 보안 허점의 세가지 주요 원인에 주목했습니다: 소셜 엔지니어링(social engineering), 웹 서버, 그리고 브라우저 취약성. 이 글은 브라우저의 취약성을 보완해주는 기능인 IE 8의 데이터 실행 방지(DEP)에 대해 다룹니다.

Eric은 이어 DEP에 대해서 상세히 설명했습니다:

Windows Vista에서의 Internet Explorer 7은  인터넷 옵션에서 “온라인 공격 방지를 위해 메모리 보호 사용” 옵션이 꺼져있는 것이 기본값입니다. 이 옵션이 데이터 실행 방지(DEP) 혹은 실행 방지에 관련되어 있습니다.

Windows Server 2008과 Windows Vista SP1 혹은그 이후 버전에서 Internet Explorer 8는 기본값으로 이 옵션을 사용합니다.

DEP/NX는 실행 불가능으로 표시한 메모리에서 코드가 실행되는 것을 막음으로써 공격을 차단합니다. DEP/NX는 주소 공간 레이아웃 불규칙화(ASLR)같은 다른 기술과 조합되면 버퍼 오버런(overrun)과 같은 메모리 관련 취약성에 대한 공격을 어렵게 합니다. 가장 좋은 점은, 이러한 방지기술이 Internet Explorer와 로드된 추가 기능에도 적용된다는 것입니다. 이런 보호를 제공하기 위해 사용자의 추가 행동이나 입력창을 필요로 하지 않습니다.

그들은 또한 이런 글도 포스팅했습니다:

  • IE 자동 컴포넌트 활성화 가능: ActiveX를 포함하면 나타나던 "이 컨트롤을 활성화 하려면 클릭..."이라는 문구가 Internet Explorer에서 이제 완전히 사라지게 됐습니다.
  • IE 4월 보안 업데이트: 2008년 4월의 IE 누적 보안 패치가 Windows Update 사이트를 통해 사용 가능합니다.

Posted by 행복한고니 트랙백 0 : 댓글 0
from Getting feedback to the IE 8 team on Ajaxian

아래 메일은 Microsoft MVP들(이라 쓰고 친한 사람들이라 읽는다 :)이 보낸 메일이며, 피드백을 필요로 하는 모양입니다.

메일의 내용을 간단하게 요약하자면 이렇습니다.

IE8 표준 모드에 대한 내용인데, 커뮤니티 쪽에서는 어떻게 생각하는지, 고객이나 개발자에게 미칠 영향을 어떻게 보는지, 이러한 정보를 공유할 방법은 뭐가 있는지에 대한 의견을 묻고 있습니다. 그 외에도 자기들이 다른 웹사이트 혹은 개발자들과 컨택하고, 개발자 FAQ를 배포하고, 지식 DB를 구축할 것인데, 이에 대해서는 어떻게 생각하는지 묻고 있습니다.
Posted by 행복한고니 트랙백 0 : 댓글 1

Peter-Paul Koch씨가(quirksmod.org의 운영자) mousemove 이벤트 버그에 대해서 작성했습니다. 해당글은 quirksmode에서 읽을 수 있습니다.

새로운 mousemove 테스트를 하다가 이전까지 못알아차렸던 IE5~7까지의 버그를 발견했습니다. 사용자가 DOM엘리먼트 위에서 마우스를 움직이면 당연히 mousemove 이벤트가 여러번 일어납니다. 하지만, 사용자가 mouse 움직이는 것을 그만둘 때도 가끔 이벤트가 계속해서 발생합니다. 이럴 때는 마우스가 완전히 타겟 엘리먼트를 완전히 떠나야만 이벤트가 제대로 멈춰지더군요.

이건 확실히 버그입니다: 마우스를 움직이지 않으면 mousemove 이벤트가 일어나지 않는게 맞죠.

IE 팀이 수정을 했습니다: 이 버그는 IE8b1 에서는 해결되었습니다. 마우스를 움직이지 않으면 mousemove 이벤트도 일어나지 않습니다. 그게 맞는거죠.

그러나, 이 버그가 최근에 나온 Safari(Windows)와 Opera에도 있습니다!

Safari 3.0 과 Opera 9.26는 mousemove 이벤트를 정확하게 지원했었는데, Safari 3.1과 Opera 9.5b는 IE의 버그를 그대로 가져다 놨더군요.

Posted by 행복한고니 트랙백 0 : 댓글 0

from IE 8 strict mode doesn’t allow for CSS opacity? on Ajaxian

Howard Rauscher 씨가 opacity와 IE 8 strict 모드를 함께 사용할 수 없다고 말한 IE 8 ticket 을 알려왔다고 합니다:

Description

IE8 Strict 모드는 필터를 뺐습니다: IE8 이전 버전에서 비록 CSS3의 opacity는 구현되지 않았지만 사용자는 필터를 통해 CSS에서 alpha(opacity=xx)처럼 opacity를 설정할 수 있었습니다. 저는 opacity가 아직 최종확정되지 않은 CSS3 스펙의 일부라고 알고 있습니다. 그런데, css 요소에서 opacity를 바꾸는 것이 더이상 가능하지 않는데도 어처구니 없는 기능상 퇴보를 한겁니다(IE 5.5, IE6.0, IE7.0, Mozilla Firefox, Apple Safari 등에선 가능했습니다).

Comments

이것이 그런 식으로 설계되었다는 사실은 지난 10여년의 세월을 통틀어 IE8이 최고 strict한 모드에서 opacity를 지원하지 않은 유일한 브라우저가 될 거라는 것을 짐작케 합니다. 어처구니가 없죠. 저도 표준 준수에 대한 바람은 이해합니다만, CSS3의 opacity 태그를 인식하도록 구현하는 게 얼마나 어렵길래요(filter를 사용한다 해도 그건 나중에 호환성을 위해 남을건데).

어떤 점에서 표준은 사용성을 저해할 수 밖에 없습니다. Mozilla, Opera, Apple은 모두 아직까지 CSS2의 공식 스펙이 아닌 태그라도 사용할 수 있어야 한다는 것을 알아차렸습니다. IE8의 표준 준수 모드에서 주요 기능이 빠져있다면 누가 그것을 쓰겠습니까. 설령 표준을 준수한다 해도 말이죠.

당신들은 표준을 준수하지만 표준 준수모드에서 불가능한 기능이 필요한 웹사이트를 보게 될 것입니다. 이런 웹 사이트들은 IE7 모드를 이용해야겠죠. 그리고 IE9이 출시되면 당신은 또 다시 모든 표준 이슈를 처리해야 할 것입니다.

Posted by Ames on 3/17/2008 at 3:59 PM

IE8 걱정됩니다... 불만이 여기저기서 터져 나오네요.
Posted by 행복한고니 트랙백 0 : 댓글 1
from Internet Explorer 8 Beta 1 for Developers – Standards Highlights Part 2 on IEBlog


개발자들을 위한 Internet Explorer 8 Beta 1 이 릴리스되고, CSS에 대한 우리의 계획과 관련된 좋은 아이디어가 담긴 긍정적인 피드백을 받았습니다.

피드백에는 현재의 Beta 버전과 최종 릴리스될 IE8 표준모드에서의 CSS 지원 명세에 대한 요구가 많이 포함되어있었습니다.

이 정보를 통해 여러분, 개발자 커뮤니티, 에게 여러분의 사이트를 테스트해보고 현재의 베타 버전에 구현되어있는 기능에 대한 피드백을 주시길 바라는 바입니다.

자세한 사항은 MSDN에 올려두었습니다: CSS 호환성과 Internet Explorer.

다시 한번, 훌륭한 제품을 만들 수 있도록 많이 도와주시고 관심을 가져주셔서 감사드립니다.

Posted by 비회원 트랙백 1 : 댓글 0

티스토리 툴바