�

jeffrey zeldman

제프리 젤드만의 웹표준 가이드웹 디자이너와 개발자, 그리고 사용자를 위한 올바른 선택

2ed

���목차

목차

서문 1

하나의 방법으로 모든 문제를 해결할 수 없다 2

이론과 실제 3

유연성 없는 규칙이 아닌 하나의 연속체 4

팔려고 하지 말고 보여주라 4

결과물 자체로 사업이 되게 하라 5

내부 작업에서의 사용 6

변화의 움직임 6

1부 이미문제는발생해버렸다 9

00장 시작하기전에 11

증가하는 비용, 줄어드는 효과 12

구식화의 악순환 끝내기 14

상위 호환성이란 무엇인가? 15

규정도 없고 정석도 없다. 16

이론이 아닌 실제 18

꼭 이 책을 읽어야 할까? 20

01장 웹사이트의99.9%는시대에뒤떨어진다 21

최신 브라우저들과 웹표준 22

새로운 작업을 위한 새로운 코드 24

�v

버전 문제 25

이전 버전에 대한 고려 27

구식 마크업: 비용의 증가 31

하위 호환성 33

사용자를 막으면 손해일 뿐이다 33

삼천포로 빠지기 38

나쁜 마크업에 좋은 일이 생길 때 39

해결책 41

02장 표준에맞춰디자인하고제작하기 43

고생담 45

표준화가 도입되기 이전의 디자인 비용 46

구시대적인 방법으로 만든 현대적인 웹사이트 47

비참한 왕국 51

웹표준의 세 가지 요소 53

구조 53

표현 56

동작 57

실행 57

전환형의 이점 58

웹표준화 프로젝트: 이식성 60

문서 하나로 모든 서비스를 한다 63

A List Apart : 하나의 페이지, 다양한 디자인 63

모니터 밖의 디자인 65

시간과 비용의 절약, 방문자수 증가 66

앞으로의 발전방향 67

전환형(transitional) 상위 호환성(혼합형 디자인) 67

엄격한(Strict) 상위 호환성 69

v목차

03장 표준화가어려운이유 73

보기에는 좋지만 실행하기는 끔찍하다 74

공동의 목표, 공동의 방법 76

실제와 대비되는 인식 77

2000년: 브라우저가 완성된 해 78

맥킨토시용 인터넷 익스플로러: DOCTYPE 전환 기능과 확대축소 기능 79

넷스케이프의 대담한 변화 82

브라우저들의 홍수 82

너무 적다? 너무 늦었다? 83

CSS: 처음에는 쓸모 없었다 84

나쁜 브라우저가 나쁜 습관을 만든다 84

넷스케이프 4에서 표현의 상속 문제 85

상속을 사용하자 87

잘못된 방식 87

오래 유지되는 표준화 기반 스크립트 88

혼동되는 사이트와 갈피를 잡을 수 없는 명칭들 89

학문이냐 이익이냐 90

협회에서 제안하고, 업체에서 판매 91

제품의 인지도와 표준의 인지도 91

플래시 92

플래시의 가치 94

플래시의 문제점 96

플래시의 또 다른 문제점 96

호환은 나쁜 것이다. 97

인지도를 만드는 언어의 힘 97

느낌의 문제 98

다른 문제들 99

v�

04장 파인더빌러티,발행,블로그,팟캐스트,롱테일,Ajax

(그리고표준화가대세가되는다른여러가지이유들) 101

범용언어 (XML) 103

XML과 HTML의 비교 104

한 부모, 여러 자손들 105

전문 소프트웨어나 일반 사용자용 소프트웨어의 필수 요소 105

가수보다 유명하다 106

강력한 데이터를 만드는 5가지 이유 108

발명의 모체 109

웹 저작툴 113

사용자가 원하는 대로 114

XML 애플리케이션과 웹 사이트 116

호환성 116

새로운 협력의 시대 117

기준 모음과 상세내역 117

얼마나 잘 맞는가 118

WHAT Working Group 119

인터넷 익스플로러 7과 웹표준화 프로젝트 119

웹표준과 저작 프로그램 120

CSS 레이아웃의 출현 122

브라우저 업그레이드 캠페인 123

홍수의 시작 126

변경한 수많은 사이트와 도움이 되는 사이트 128

최대의 CSS 지식 창고 131

목적 있는 유행 따라가기 131

웹표준의 주류 132

상업적인 사이트들의 진입 134

Wired Digital의 전환 135

v��목차

디자이너의 관심 끌기 137

충격은 계속된다 139

유효성 검사로 다져진 행복으로 가는 길 140

2부 디자인과제작 141

05장 최신마크업 143

낡은 마크업의 숨겨진 오점 148

재구성 150

주요 요약 152

어느 XHTML이 더 우리에게 맞을까? 152

XHTML 2 – 누구를 위한 것인가? 152

XHTML로 바꿔야 하는 이유 Top10 154

XHTML로 바꾸지 말아야 하는 이유 Top5 155

06장 XHTML:웹의재구성 157

XHTML로의 전환: 간단한 규칙과 손쉬운 가이드라인 158

적절한 DOCTYPE과 네임스페이스로 시작하라 158

컨텐츠 타입 선언 161

태그는 전부 소문자로 적는다 163

모든 속성값에 인용부호를 사용한다 165

모든 속성에는 값이 있어야 한다 166

모든 태그는 닫아준다 167

“내용 없는” 태그도 닫아준다 167

주석 안에 더블대시 사용금지 168

모든 < 와 &는 변환해 준다 168

실행 요약: XHTML 규칙 169

캐릭터 인코딩: 따분하고 더 따분하고 최고로 따분한 169

v���

구조적인 변화 171

스타일보다는 감각적인 마크업을 하자 171

비주얼 요소와 구조 175

07장 더빈틈없고견고한페이지를위하여:

엄격한마크업과혼합형마크업에서의구조와메타구조 177

모든 요소를 구조적으로 사용해야 할까? 178

div와 id 그리고 다른 여러 보조요소들 179

시멘틱 마크업과 재사용성 183

혼합형 레이아웃과 간결한 마크업: 해야 할 것과 하지 말아야 할 것들 187

안 좋은 방법들에 이름 짓기 187

혼합형 마크업에서의 자주 발견되는 실수들 188

div가 문제가 아니다 191

id를 사용하라 192

테이블 셀의 제거 194

구식 방법들 195

이미지 맵의 시대 195

맵의 단점 196

접근성이 없으면 구조도 필요 없다 197

자르고 나누기 197

이미지 자르기의 유행 197

지나치게 장황한 테이블 199

잘못 사용한 CSS의 등장 200

지속적인 발전 204

08장 XHTML예제:혼합형레이아웃(1부) 205

전환형 방법의 장점 206

자바스크립트를 대신하는 스타일시트 206

기본 접근법(개요) 206

�x목차

테이블 분리: CSS와 접근성 면에서의 장점 208

넘어가기 메뉴Sk�p Nav�gat�on와 이를 사용하는 이유 208

추가 id 213

초기 마크업: 최종 마크업과 같다 214

네비게이션 마크업: 첫 번째 테이블 215

표현, 시멘틱, 순수성 그리고 잘못 216

컨텐츠 마크업: 두 번째 테이블 217

09장 CSS기본 219

CSS 요약 220

CSS의 장점 220

스타일 분석 222

선택자, 선언, 속성 그리고 값 222

다중 선언 223

여백과 대소문자의 구분 224

대체가능하고 포괄적인 값 224

선택자들의 묶음 226

상속과 불만 226

자손 선택자 227

id 선택자와 자손 선택자 229

class 선택자 230

선택자들을 결합하여 세련된 디자인 효과 만들기 231

외부, 내부, inline 스타일 234

외부 스타일시트 234

inline 스타일 238

‘최고 브라우저 테스트’ 방식 238

내부 스타일에서 외부 스타일까지: 이중 스타일시트 방식 239

상대 경로, 절대 경로 240

최고 브라우저 테스트 방식과 이중 스타일시트 방식의 이점 240

x

10장 CSS활용:혼합형레이아웃(2부) 243

이미지 준비 244

기본 요소 설정하기 246

전체쓰기와 줄여쓰기, 그리고 margin 246

숨김과 블록지정 247

링크에 색상 주기(가상 클래스) 249

기타 요소 설정 251

폰트사이즈에 관한 그 외의 것들 253

페이지에 div 배열하기 256

네비게이션 요소 : 첫 번째 단계 259

네비게이션바 CSS: 두 번째 단계의 첫 번째 시도 262

네비게이션바 CSS: 마지막 단계 263

마지막 단계: 외부 스타일과 ‘현재위치’ 나타내기 268

11장 브라우저다루기1부:DOCTYPE전환과표준모드 271

DOCTYPE 전환의 전설 272

브라우저 성능 제어하기: DOCTYPE 전환 274

완전한 XHTML DOCTYPE의 전체 목록 277

브라우저 다양성에 축배를! 280

12장 브라우저다루기2부:BoxModel,버그,차선책 285

Box Model과 이에 대한 불만들 286

Box Model은 어떻게 작동하는가 287

Box Model은 어떻게 망가지는가 288

Box Model Hack: CSS의 사용을 안전하게 해준다 295

윈도우용 인터넷 익스플로러의 공백 버그 298

윈도우용 인터넷 익스플로러 ‘Float’ 버그 302

Float, Peek-a-Boo 그리고 다른 버그들 304

x�목차

플래시와 퀵타임: 고객의 요구에 의한 Object? 305

Embed가 가능한 객체: 오만과 복수에 관한 전설 305

이중방식: 멀티미디어 파일의 표준 지원 306

추가 문제: Object 로딩 실패 현상 308

회피법 309

13장 브라우저다루기3부:타이포그래피 311

크기 문제 311

사용자가 조절한다 312

구시대 사람들의 공포 312

단위의 차이 314

드디어 등장한 표준 사이즈 315

클릭 한번으로 되돌려지다 317

브라우저 판별: 변화에 대한 브라우저의 잘못된 반응 318

표준 사이즈와 최선의 방법 320

em 단위의 사용: 웃음과 눈물 320

사용자 선택과 em 단위 321

픽셀에 대한 열정 322

최소 단위: 절대적으로 상대적인 단위 322

픽셀의 문제점 323

폰트 사이즈 키워드 방법 324

키워드가 em이나 퍼센트보다 좋은 이유 325

키워드를 적용했던 초기의 문제들 326

최고의 시기 330

14장 접근성의기본 331

책에서의 접근 333

일반적인 혼란 334

천재들도 실수를 한다 334

x��

규정과 레이아웃 338

Section 508 설명 339

접근성에 관한 소문들의 진상 341

소문: 접근성을 지키기 위해서는 사이트를 두 개의 버전으로 만들어야 한다 341

소문: 동일하거나 상응하는 접근성을 지키기 위해서는 텍스트만으로

만들어진 버전이 필요하다 341

소문: 접근성에는 비용이 너무 많이 든다 341

소문: 접근성은 유치하고 싸구려 디자인밖에 나오지 않게 한다 343

소문 : Section 508에 따라서 만들면 사이트는

모든 브라우저와 사용자 환경에서 똑같이 보여야 한다 344

소문: 접근성은 ‘장애인을 위한 것’이다 344

소문: 드림위버 MX/Cynthia의 툴로

여기 나온 모든 접근성 문제를 해결할 수 있다 345

소문: 고객이 원하지 않으면 접근성은 무시해도 된다 346

요소별 접근성 팁 346

Image 346

애플 사의 퀵타임과 다른 동영상 미디어 349

매크로미디어 플래시 4/5 349

매크로미디어 플래시 MX와 플래시 8 349

색상 351

CSS 351

롤오버와 다른 스크립트 동작들 353

Form 355

이미지 맵 355

테이블 레이아웃 355

데이터를 표시하는 테이블 356

프레임, 애플릿 356

번쩍거리고 깜빡이는 요소 356

접근성에 도움이 되는 툴과 플러그인 357

x���목차

Cynthia Says™ 358

Tab의 연결: 우리의 친구, tabindex 속성 358

접근성 계획: 어떤 장점이 있을까 362

접근성은 우리한테도 도움이 된다 362

15장 DOM기반의스크립트로작업하기 365

DOM 관련 서적 366

DOM이란 무엇인가? 367

웹 페이지를 애플리케이션처럼 작동하게 만드는 표준 방식 367

그럼 사용 가능한 환경은? 370

DOM을 지원하지 않는 경우 371

스타일 변경: 접근성 지원, 선택의 폭 374

16장 CSS로디자인하기 379

조건의 정의 380

필수 조건 10가지 380

가상 레이아웃 설정 382

배너 386

마무리하기 390

찾아보기 391

x�v

저자 소개

제프리젤드만ㅣJeffreyZeldman

제프리 젤드만은 최초의 웹 디자이너 중 한 명이고 전문가들 사이에서

강력한 영향력을 지녔다. 1995년 전 아트 디렉터이자 카피라이터인 그

는 최초로 가장 영향력 있는 개인 웹 사이트 중의 하나(www.zeldman.

com)를 만들었고 웹 디자인의 방법과 원칙에 대한 유명한 튜토리얼을

쓰기 시작했다.

1998년 마이크로소프트와 넷스케이프에서 각각 자기들의 브라우

저에서 같은 기술을 지원하도록 설득한 기초 연합인 The Web Standards Project(www.

webstandards.org)를 공동 설립했다. 같은 해 A List Apart(www.alistapart.com)

‘for people who make websites’(웹 사이트를 만드는 사람들을 위하여)를 만들기 시작했다.

그리고 이 분야에서 가장 존중 받고 영향력 있는 잡지가 되었다.

제프리 젤드만은 웹 디자인 에이전시인 Happy Cog(www.happycog.com)의 설립자이고 제

작 감독이며 사용자 경험 전문가이다. 그는 많은 논설과 『Designing With Web Standards』

를 포함한 두 권의 책을 썼고 전세계적으로 가장 사랑 받는 강사이다. 2005년 제프리 젤

드만과 에릭 마이어는 디자인과 코드에 관한 순회 컨퍼런스인 An Event Apart(www.

aneventapart.com)를 공동 주최했다.

xv저자·기술 감수자 소개

기술 감수자 소개

이단마르코티ㅣEthanMarcotte(2판의기술에디터)

이단 마르코티는 십 년 가까이 온라인 디자인과 개발을 하고 있고, 배

울게 산더미 같이 많다는데 정말 놀라고 즐거워하고 있다. 그는 우아하

고 사용성 좋은 웹 사이트를 만드는 표준에 정통한 디자인 스튜디오인

Vertua Studios(www.vertua.com)의 공동 창립자이면서 수석 디자

이너이다.

이단 마르코티는 표준기반 웹 디자인 분야에서 매우 존경 받는 위치에

있다. 그는 Web Design World and the South by Southwest Interactive 컨퍼런스의

메인 발표자였고, 유명 웹 블로그 sidesh0w.com를 운영하고 있다. New York Magazine

과 Harvard University, Disney, State Street Bank의 제작을 담당했다.

이단 마르코티는 절대무적 닌자 로봇이 되는 것이 꿈이다.

J.데이비드아이젠버그ㅣ J.DavidEisenberg(초판의기술에디터)

J. 데이비드 아이젠버그는 캘리포니아의 산 호세에서 마르코와 빅 토

니라는 이름의 고양이 둘과 같이 살고 있다. 현재 Evergreen Valley

College에서 HTML과 XML, Perl, 자바스크립트를 가르치고 있으며

온라인 튜토리얼을 즐겨 쓰고 있다. 또 『SVG Essentials』(O’Reilly &

Associates)과 『OASIS OpenDocument Essentials』(Friends of

OpenDocument, Inc.)의 저자이다.

J. 데이비드 아이젠버그는 PLATO 컴퓨터 보조 교육 프로젝트에 참여한 일리노이즈 대학

Un�vers�ty of Ill�no�s을 다녔고, Burroughs와 애플 사에서도 일을 했다.

xv�

기술 감수자 소개

에릭마이어ㅣEricMeyer(초판의기술에디터)

에릭 마이어는 국제적으로 알려진 CSS와 웹표준 전문가이고 1993년

후반부터 웹에 종사해왔다. 베스트셀러 CSS 서적의 저자이고 세계 최

고의 CSS 권위자이다. 그가 저술한 일곱 권의 책은 여섯 개의 언어로

번역되어 수십 만권이 팔려나갔다.

에릭 마이어는 현재 고객이 표준을 사용하여 비용을 절감하고 사용

자 경험을 증대하도록 도와주는데 초점을 맞추는 Complex Spiral

Consulting(www.complexspiral.com)의 사장이다. 그리고 이 자격으로 대학에서부터 정

부 연구소나 포츈지 선정 500대 기업들에 이르는 단체들에 조언을 주고 있다.

[의견을보내주세요]

이 책의 독자로서 여러분은 가장 중요한 비평가이자 논평자입니다. 여러분의 의견은 높은 가치

를 지니고 있으며 여러분이 어떻게 하고 있는지, 우리가 어떻게 해야 할지, 어떤 분야에 관해서

출판을 해야 할지 그리고 여러분이 어떤 다른 생각들을 가지고 있는지 알려주시기 바랍니다.

Email: errata@newriders.com

xv��감사의 말씀·문의

감사의 글

에린 키세인Er�n K�ssane은 이 감사의 글을 제외한 이 책의 모든 단어를 수정해 주었다. 이보다 더 훌

륭한 에디터는 없다고 생각한다. 에린씨 감사합니다.

기술 에디터 이단 마르코티는 진흙투성이 같은 나의 글에 화려한 포장을 해주었다. 큰 감사를

보낸다.

에릭 마이어와 J. 데이비드 아이젠버그가 초판의 기술 에디터로 훌륭한 작업을 해주었고 아직

도 그 통찰력과 영감은 이 새 책에서도 울려 퍼지고 있다. 여러분 큰 신세를 졌습니다.

마이클 놀란M�chael Nolan, 이 사람이 없었다면 이 책의 두 번째 판은 나오지도 못했을 것이다. 그

우정에 감사한다.

조 클락Joe Clark과 탄텍 셀릭Tantek Çel�k은 아직도 나에게 가르침을 주고 있다.

파너Fahrner, 자전거 그만 타고 웹으로 돌아와주길 바랍니다.

Happy Cog의 고객들과 동료들, 이 책 때문에 가끔 회의에서 집중을 못했습니다.

A List Apart의 모든 독자들, 진정한 감사의 말고 존경을 보냅니다.

다양한 고객들과 독재자 사장님들 그리고 대립하는 직장 동료들과 웹표준과 접근성 때문에 조

용하게 논의를 하거나 거칠게 논쟁을 해본 모든 분들, 전 세계가 여러분께 감사를 드리고 나 또

한 감사를 드립니다. 그리고 부족하지만 이 책을 여러분께 바칩니다.

나에게 우주를 만들어준 캐리Carr�e와 빛이 되어준 아바Ava에게 감사한다.

xv���

x�x서문

역 자 서 문

벌써 ‘웹’이라는 분야에 몸 담은 지가 7년이 되어가고 있는데도 모르는 것들과 배워야 할 것들은

점점 더 많아지는 것처럼 느껴지고, 실제로도 더 많아지고 있다. 웹은 항상 우리보다 한발 먼저

앞서나가며 우리가 알고 있는 것보다 항상 더 많은 것을 요구한다. 하지만 이제 더 많은 것을

알아가기 위해 허덕이면서 따라가는 것에만 급급했던 시절은 지나고, 웹이 안정되어 가고 있다

는 말을 하면서 (혹은 어떤 이들은 쇠약해지고 있다는 말을 하기도 한다) 다시 한 번 우리가 지

나온 길을 돌아봐야 할 시점이 되지 않았나 생각해 본다.

이에 웹표준은 바로 과거를 되짚어보는 계기가 될 수 있을 것이다. 우리가 그동안 지키지 않았

던 것들과 그로 인해서 생겨난 문제점, 우리가 대충 미봉책으로 사용하던 방법들이 우리를 옭

아매고 있다. 그리고 그 올가미가 우리를 점점 더 조여오기 전에 다시 이전으로 돌아가서 매듭

을 풀어야 할 때가 온 것이다.

웹표준의 대가인 제프리 젤드만은 웹표준을 만들어서 전 세계에 널리 알리고 브라우저를 만

드는 기업들을 설득하여 웹표준을 지키도록 하는 데 가장 큰 공헌을 한 사람이다. 우연찮게

도 이 책을 번역하고 있는 시기에 BusinessWeek에서 Jeffrey Zeldman: King of Web

Standards라는 2007년 8월자 기사를 게재했다. 그의 업적 중에서 가장 손꼽을 수 있는 것은

무질서한 웹에 질서를 가져다 준 것이 아닌가 생각한다. 이제 웹표준은 기준이 되고 규정이 되

고 나아가서는 법률이 되고 있다. 처음에 웹이 만들어진 목적으로 다시 돌아가서 웹은 이제 서

로 가지고 있던 장벽을 깨고 좀 더 많은 사람들을 위해서 좀 더 편리하게 만들어지는 도구를 얻

게 되었다. 그것이 웹표준이다.

xx

이 책은 제프리 젤드만이 집필한 두 권의 유명한 책 중에서 2003년에 써서 베스트 셀러가 된

『Designing With Web Standards』의 초판을 완전히 새롭게 다시 펴낸 책이다.

이 책을 읽고 나면 이제 웹표준은 지켜야 하는 것만이 아니라 지키고 싶은 것으로 바뀌게 될 것

이다. 처음에 웹표준을 접하는 사람들은 그 규칙이라는 말에서 위압감을 가지고 거부감을 가지

게 된다. 하지만 웹표준은 절대적인 규범이 아니다. 웹표준은 내가 지키고 싶은 만큼 또는 지킬

수 있는 만큼, 지킬 수 있는 것부터 하나씩 지키는 것이다. 웹표준은 일하는 사람을 귀찮게 하

는 것이 아니고 일하는 사람이 더 편하고 빠르게 일을 할 수 있도록 도와준다.

이 한 권의 책으로 누군가가 웹표준의 대가가 되기를 바라는 것은 아니다. 하지만 이 책은 여러

분이 웹표준이 무엇인지 알게 되고 호감을 가지게 된다고만 해도 충분히 읽을 만한 가치가 있을

것이다.

1서문

서 문

한때 자동차 운전자들이 빈 병을 창 밖으로 버리는 것을 아무렇지 않게 생각 하던 시절이 있었다.

몇 년 뒤에 이 사람들은 창 밖으로 쓰레기를 버리는 일이 아무렇지 않은 일이 아니라는 사실을

알게 되었다. 웹디자인 커뮤니티가 지금 이와 비슷한 상황을 겪고 있으며 웹표준이 바로 이러

한 변화의 열쇠가 된다.

웹은 오늘날의 문제를 풀어 나가면서 내일이 되면 대가를 치를 방법을 사용하고 있다. 이 책에

서는 지금 벌이는 일을 나중에 해결하려는 방식이 생산적이지도 않고 그렇게 할 필요도 없다는

것과, 현재 직면한 문제를 점점 더 골치 아픈 상황으로 몰아가지 않고 풀어내는 방법을 알려줄

것이다. 또 웹표준에 의한 디자인이 일부 사용자에게는 불편하다는 생각도 없애줄 것이다. 사

실 이와 반대로 웹표준을 사용하지 않으면 일부 사용자가 불편해지는 것이 보통이다.

2

하나의방법으로모든문제를해결할수없다

이 책에서는 표준을 사용하여 웹디자인과 제작의 일반적인 문제들을 해결하는 몇 가지 방법을

살펴볼 것이다. 모든 문제와 그에 대한 해결책을 다룰 수 있는 책은 없고, 아마도 다른 저자가

쓴 책에서는 이 책에서 언급된 방법과 전혀 다른 방법으로 문제에 접근할 수도 있다. 사실 이

책의 초판에서 웹표준을 세상에 소개한 뒤로 ‘웹표준’이라는 말을 제목으로 사용한 책들이 매주

새로 나오는 듯하다. 이렇게 나오는 책들 중에서 많은 책들이 지금 이 책에서 얘기하는 내용과

거의 같은 내용이다. 어떤 책에서는 이 책에서 나온 내용에 반박을 하기도 한다. 다른 문제에는

다른 기술이 필요한 것이다.

이 책은 미래에 필요하리라고 예상되는 현실적이고 즉각적인 필요성에 초점이 맞추어져 있다.

이 책에서 다루어진 기술과 방법들은 나의 에이전시에서 디자인하고 제작한 방법 중에서 이미

테스트를 해보고 실용성이 입증된 것들이며, 이 방법들 또는 여기서 파생된 방법들은 수천 개

의 진보적인 사이트에서 사용되었다. 더 많은 디자이너들이 이 방법을 사용할수록 새롭고 더

좋은 기술들이 생겨나고 공유된다. 이 책의 목적에는 이러한 새로운 방법들을 소개하고 최악의

경우에 대한 경고를 하는 것도 포함돼 있다.

모든 독자들이 이 책에서 다루는 새로운 방법들을 곧바로 사용하지는 않을 것이다. 특히 그래

픽적인 효과나 포스터 같은 레이아웃에 중점을 두는 사이트를 주로 작업하는 사람이라면 절대

시멘틱 마크업을 사용하지는 않을 것이다. 하지만 시멘틱 마크업을 디자인 습관에 접목시켜서

작업해두면 검색엔진에서 그 사이트가 상위에 검색이 되는 것을 알게 될 것이다. 혹시 사이트

가 4.0 브라우저에서도 요즘 사용하는 브라우저에서 보이는 것과 거의 똑같이 보여야 한다면-

그리고 하기 싫다고 해서 그만두거나 고객과의 거래를 끊기 힘들다면-아마도 8장과 9, 10장

에서 다루는 혼합형CSS/table 레이아웃을 사용할 수 있을 것이다. 보통 다른 독자들은 고맙게도 이

책의 초판이 나왔을 당시에 비하면 이 혼합형 레이아웃을 사용할 필요가 거의 없을 것이다.

현명한 디자이너나 개발자, 사이트의 소유주는 누구든지 이 책에서 제시하는 의견에 찬성할 것

이다. 표준은 어느 매체에서든지 가장 중요한 요소이다. 웹에서 보이는 소프트웨어가 결국에는

표준을 지원하기 때문에 당연히 이에 대해서 연구하고 정확하게 사용해야 하는 것이 정석이기

때문이다. 이렇게 해서 시간과 돈을 절약하고 총비용을 낮추어 사이트의 사용기한을 늘리면서

동시에 컨텐츠에 대한 접근성을 증대시킬 수 있다.

3서문

마지막에 언급된 항목은 더 많은 사용자를 원하는 사람이라면 누구에게나 중요한 사항이다-특

히 일반적이지 않은 새로운 방식의 인터넷 사용이 늘어가는 지금은 더욱 그렇다. 또한 점점 더

많은 나라와 미국의 각 주에서 접근성에 관한 법률을 시행하고 있기 때문에 법적으로도 밀접한

관련이 있다. 웹표준과 접근성은 이 법에 저촉되지 않게 해준다.

실무 디자이너가 다른 방식으로 생각하는 계기를 한 번 경험하고 무언가를 깨닫기만 하면, 시

멘틱 마크업과 CSS 레이아웃은 그 사람이 더 현명하고 빠르게 일을 할 수 있게 해준다. 정보

구조적인 면에서, 표준 기반의 디자인은 컨텐츠를 좀 더 검색하기 쉽게 만든다-그리고 기존에

는 컴퓨터를 통해 그냥 웹사이트에서 클릭만 하는 사용자들이 대다수였던 시절에서 이제는 무

선기기를 사용하는 환경의 웹 사용자들이 점점 증가하게 되면서, 파인더빌리티(findability,

검색엔진에서 검색이 더 잘 되는 문서를 파인더빌리티가 있다 또는 높다고 표현한다-옮긴이주)

의 중요성이 커지고 있다. IT 업계에서, 표준 기반의 디자인은 컨텐츠를 좀 더 이동이 편리하

고 대역폭과 노동력을 줄일 수 있게 해준다. 그리고 회계사의 입장에서는 말할 것도 없다.

이론과실제

물론 이 책에서 다루는 일부 특정 아이디어와 기술은 아직 논쟁이 필요한 것도 있다. 정말 표준

에 집착하는 사람들은(좋은 의미의 집착을 말한다) 모든 브라우저가 XHTML 문서를 text/

html이 아닌 application/xhtml+xml로 전송하는 것을 제대로 지원하기 전까지 XHTML

을 사용하고 싶어하지 않을 것이다. 자세한 것은 이안 힉슨Ian H�ckson의 “XHTML을 text/html

처럼 전송하는 것은 위험하다”를 참조하라(www.hixie.ch/advocacy/xhtml).

이안 힉슨의 의견에 동의한다면 인터넷 익스플로러 7이 나오기 전까지는 HTML 4.01

을 사용해야 할 것이다(인터넷 익스플로러 7에서는 MIME 문제를 제대로 수정할 것이라

는 전제하에서). 아니면 웹서버에 application/xhtml+xml을 이해하는 브라우저에게

는 application/xhtml+xml로 전송하도록 설정하고 그렇지 않은 브라우저에게는 text/

html로 전송하도록 설정할 수도 있다(http://lists.w3.org/Archives/Public/www-

archive/2002Dec/0005.html).

이 책에서는 이러한 문제들은 제외시켰는데 그 이유는 현재의 상황에서 문제를 해결하는 것에

무게를 두고 싶었기 때문이다-이 책을 읽는 대부분의 사람들은 아마도 이 의견에 동의할 것이다.

4

유연성없는규칙이아닌하나의연속체

이 책에서 강조하듯이, 웹표준은 유연성 없는 규칙이 아니라 하나의 연속체이다. 웹표준으로

전환하는 과정에서 첫 번째 사이트나 어쩌면 대여섯 번째 사이트에서도 구조에서 표현을 완벽

하게 분리해 내는 것은(2장 참조) 힘들 것이다. 아마도 초반에는 접근성(14장)도 겨우 WAIWeb

Access�b�l�ty In�t�at�ve의 1단계 정도나 맞출 수 있을 것이고 전부 정확하게 지키지는 못할 것이다(WAI

의 1.0 조항을 만든 사람들도 어떤 사항들은 잘못 적용하고 있고 지금은 2.0 조항을 만드는데

바쁘다).

중요한 점은 시작하는 것이다. 군살을 보여주는 것이 두려워서 운동하러 가지 못하는 것처

럼 무엇인가 불완전에 대한 두려움은 하려는 것을 막는다. 하지만 두려움과 실수를 감내해 가

면서 운동을 시작하지 않으면 살이 빠지는 일은 절대 일어나지 않을 것이다. 마찬가지로 사이

트도 무엇인가 시작하지 않으면 상위 호환은 생기지 않을 것이다. <font> 태그를 없애는 것

이 아마도 시작이 될 수 있을 것이다. 또는 무의미한 마크업을 지우고 대신에 <h1>~<h6>와

<p> 태그를 사용할 수 있다. 이것이 보통 시작하는 좋은 방법이고 결국에는 현대적인 마크업과

XHTML을 사용하게 될 것이다.

팔려고하지말고보여주라

디자이너들은 가끔 표준을 제공하는 부분에서 난항을 겪는다. 몇 년간 표준을 사용하고 싶어하

는 디자이너들에게서 “고객들이 표준을 원하지 않습니다” 라는 내용의 편지를 수도 없이 받았다.

표준이 약간 섞여 있더라도, 표준의 사용을 반대하는 고객은 거의 없을 것이다. 예를 들어, 테

이블 레이아웃을 사용하는 사이트에서도 HTML 4.01이나 XHTML 1.0 Transtional에서

유효하고 WAI 1단계를 준수할 수 있다.

대부분의 디자이너들이 웹표준을 적용해서 프로젝트를 수행하려고 할 때 자신들이 원하는 수

준까지 표준에 대한 적용을 하지 못할 것이라는 걱정을 한다. 예를 들어 고객이(또는 상급자가)

넷스케이프 4나 인터넷 익스플로러 5.0을 사용하기 때문에 특정 프로젝트에 순수 CSS 레이아

웃을 사용할 수 없다고 말한다. 맞는 말이기는 하지만 그렇다고 해서 유효한 마크업이나 정확

한 CSS를 사용하고 9장에서 나오는 이중 스타일시트 방식을 사용해서 여러 개의 브라우저들

에서 적절하게 보이도록 하는 등의 작업을 못하는 것은 아니다.

나의 에이전시에서는 웹표준과 접근성을 숭배하지만 우리가 사용하는 방법이나 어떤 표준의 기

준에 의해서 작업을 하는지는 상관없다. 프로젝트에 가장 적합한 방법을 사용하는 것뿐이다.

영업을 위해서는 두 가지만 한다.

5서문

제안서에 어떤 기술이 사용될지를 정확하게 명시하고, 설명을 간단하고 직설적으로

해둔다. 예를 들면 “마크업에는 현재의 표준인 XHTML 1.0 Transitional이 사용

된다.” 고객이 이 제안서를 받아들이고 계약서에 사인을 하면, 명시된 표준을 사용하

는 ‘허가’를 받은 것이고 더 이상의 억지를 부릴 필요는 없다. 구식 브라우저에서 보이

는 결과에 대한 영향도 역시 제안서에 상세하게 명시되어 있어야 한다.

작업을 시작하면서 여러 가지를 고객에게 보여주지만 기술적인 면을 잘 알고 있는 고

객과 상대를 할 때에도 기술적인 부분에 대한 것은 최소한으로만 다룬다. 디자인을 개

편하고 나서 대역폭은 이전의 사이트보다 1/3정도로 줄었고 몇 번을 수정하거나 업데

이트해도 포맷을 유지하는(오히려 더 나아진 포맷이 된) 결과물을 만들어 내도 우리는

“CSS로 만들어서 가능합니다” 같은 소리는 하지 않고 대신 “포맷을 보호하는 시스템

을 만들어서 적용하고 대역폭은 현저히 적어졌습니다” 라고 말을 한다. 고객이 우리가

일을 잘 처리한다고 생각하고 지속적인 거래를 하고 싶어한다면 그것으로 사업은 유

지되는 것이다.

결과물자체로사업이되게하라

Hillman Curtis, Inc와 Happy Cog가 Fox Searchlight Pictures 사이트 개편 작업

을 공동으로 진행했을 때 고객과 가장 많이 만난 사람은 선임 웹디자이너겸 개발자였다. 우리

가 사용한 혼합형 CSS/table 방식 중에 일부는 그에게 다소 생소해서 “사이트가 굉장히 빠

르네요” 라고 하면서 계속 놀라움을 감추지 못했다. 기본적으로 최종작업을 하고 나서 스타일

가이드를 같이 넣어주는데 이 스타일 가이드는 사이트의 기술에 대한 부분을 명확하게 설명해

두었다. 하지만 이 경우에서 보듯이 실제로 우리가 영업을 하지 않아도 결과물이 알아서 영업

을 한다.

일을 하면서 어느 정도 유명해지기 시작하면 고객은 바로 여러분을 찾기 시작하고 영업은 이제

점차 줄어들게 된다. 어떤 경우에는 포토샵에서보다도 CSS로 디자인을 하는 것이 더 쉽다는

것을 발견하기도 한다. 시간과 단계를 줄여주기 때문이다.

최근에 했던 한 프로젝트에서는 다른 대부분의 프로젝트가 그렇듯이 몇 번의 디자인 수정이

추가되었다. 고객에게 이렇게 말했다. “우리는 CSS 레이아웃을 사용했습니다.” 그러자 고객

이 “알고 있습니다” 라고 대답했다. 이 방식이 점점 늘어가서 일반적으로 되면 아무런 언급도

필요가 없어질 것이다-지금 GIF나 JPEG 이미지를 전혀 이의 없이 사용하듯이 사용하게 될

것이다.

•

•

6

내부작업에서의사용

작업을 맡긴 웹 에이전시에서 벌어지는 상황을 설명했지만 내부작업에서도 마찬가지이다. 기

본브라우저와 다른 오래된 문제에 빠져서 허덕이는 것을 피해야 한다. 적절한 항목들을 결정하

고 간단하게 문서에 설명하고 바로 작업에 착수하는 것이다. 몇 년 전에 큰 규모의 미국 정부

조직에서 몇 명의 웹개발자들에게 강연을 했다. 그 사람들도 표준에 관심이 있기는 했지만, 그

들의 회사에서는 흔히 표준을 사용하는 것을 절대 불가능하게 만든다고 믿고 있는 오래된 비표

준 브라우저에(굳이 밝히자면 넷스케이프 4에) 기준을 두고 있는데 불만을 가지고 있었다. 그

생각은 근거 없는 생각이다. 기억하자: 웹표준은 계속 변한다.

이 책의 초판을 쓰고 있을 때 또 한 번의 기회가 있어서 그 회사를 방문했는데, 그때는 분위기

가 바뀐 것을 알 수 있었다. 대부분의 사람들이 넷스케이프 7을 사용하고 있었다. 내부에서

개발한 몇 개의 애플리케이션에서 document.layers를 사용하고, 넷스케이프 4에서만 사

용되는 DHTML의 기능을 사용하기 때문에 몇 명은 아직도 넷스케이프 4를 사용하고 있었고,

이 애플리케이션들은 일부 팀원들에게는 필수였다. 하지만 거기서 포기하지 않고 그 강연의

참석자들은 어떻게 이 애플리케이션들을 W3C DOM으로 변경할 수 있는지에 대해서 토론하

고 싶어했다.

아마도 지금 그들은 넷스케이프 7의 자매품인 유명한 오픈소스 모질라 파이어폭스를 사용하

고 있을 것이고, 그 내부개발 애플리케이션은 웹표준의 방법으로 다시 만들어졌거나 버려졌을

것이다.

변화의움직임

이러한 변화들은 곳곳에서 어떤 경우에는 빠르게 어떤 경우에는 느리게 일어나고 있다. 이 변

화들은 웹컨텐츠를 만들거나 업데이트 작업을 해야 하는 사람들에게 나타나기 시작한다. 웹이

어떻게 작동하는지와 어떻게 만들어져야 하는지에 대한 생각들이 눈에 보이지는 않지만 깊고

끊임없이 만들어져 가고 있다. 웹표준은 곧 디자인과 사용성, 정보구조 면에서 광범위하게 논

의되고 탐구가 될 것이고, 거의 학문의 한 분야처럼 중요하게 생각될 것이다-이것들이 우리 사

이트와 우리가 몸담고 있는 웹에 없어서는 안 되는 것들이기 때문이다.

이 책은 방대하고 주의를 기울여 만들어져 있기는 하지만 표준이 웹에서 시사하는 바를 겨우 소

개하는 정도에 불과하다. 이 책이나 다른 참고 서적들에서 다루는 내용들보다 CSS나 접근성,

구조적인 마크업, 그리고 DOM에 관한 내용은 엄청나게 더 많다. 그리고 앞에서 언급한 것처

럼 문제에 대한 해결책은 이 책에서 보여주는 방법보다 훨씬 더 많이 있다.

7서문

두 명의 디자이너를 하나의 방에 두면 분명히 세 가지의 의견을 들을 수 있다. 어느 디자이너도

텍스트나 브랜딩이나 레이아웃 또는 색상에 대해서 서로 찬성하지 않는다. 표준에서도 마찬가

지이다.

어떤 책도 모든 사람에게 전부를 알려줄 수는 없고 이 책도 단순히 일반적인 방향을 정해줄 뿐

자신의 길은 자신이 찾아야 한다. 이 책의 역할은 어떻게 웹표준 기술들이 맞물려서 상위 호환

이 되는 사이트를 만드는지를 이해하는데 도움을 주는 것뿐이다-그리고 그 방법을 따라가는데

약간의 팁을 주는 것도 있다.

이전에 사용하던 방법으로 사이트를 디자인을 하면서 3년이 지났을 때 방황을 한 적이 있었고

그 뒤로 이 책의 기본이 되는 이해의 단계에 도달하는데 8년이 걸렸다. 어쩌면 여기서 다룬 내

용들의 일부나 또는 전부를 반대할지도 모른다. 중요한 것은 작은 차이점에 집착하거나 한두

가지 사소한 문제에 대해서 확신이 없다는 이유로 전부를 거부하지는 말아야 한다는 것이다.

그리고 현재의 웹프로젝트가 최대한 많은 사람에게 오랫동안 그리고 최저의 비용으로 만들어질

수 있도록 하는 것이 중요한 점이다.

지금 시작하지 않는다면, 언제 시작할 수 있을까? 당신이 하지 않는다면, 누가 할 것인가?

8

9서문

part

시작하기 전에 11

웹사이트의 99.9%는 시대에 뒤떨어진다 21

표준에 맞춰 디자인하고 제작하기 43

표준화가 어려운 이유 73

파인더빌러티, 발행, 블로그, 팟캐스트, 롱테일, Ajax 101

이미 문제는 발생해 버렸다

I

10

11시작하기 전에

시작하기 전에

이 책은 최신 브라우저와 스크린리더, 무선기기뿐만 아니라, 향후 미래까지 포함하여, 보다 적

은 비용으로 효율적으로 사이트가 운영되고, 보다 많은 사람들이 접속하기를 바라는 디자이너,

개발자, 그리고 사이트 관리자를 위한 책이다.

우리들 대부분은 빠르게 발전하는 웹 기술로 인해, 기존의 웹과 웹 기술이 어쩔 수 없이 진부해

져 버리는 것을 경험한 적이 있다. 기능이 향상된 브라우저나 새로운 인터넷 기기가 나오게 되면,

이제 막 작업을 끝낸 (혹은 작업하고 있는) 사이트라 하더라도 새롭게 만들어져야 할 정도이다.

우리가 하는 것은 단순히 재구축하는 작업이다. 방문자가 요청한 사항을 추가하거나 사용성을

높이기 위한 작업이 아니라, 단지 기획과 개발주기보다 훨씬 앞질러 예산을 초과하게 만드는

새로운 브라우저와 기기에 맞추기 위한 작업을 너무나 자주 하고 있다.

다행스럽게도, 새로운 브라우저나 기기가 사이트를 망가뜨리지 않는 경우도 있지만, 모든 브라

우저에서 똑같이 보이고 동작되게 하기 위한 ‘하위 호환성’이라 불리는 기술은 상당한 인력과 비

용을 필요로 하게 된다.

우리는 웹에서 사업을 하는데 드는 이러한 비용에 너무 익숙해져 있다. 하지만 이제 더 이상 이

많은 비용을 다 감당할 수가 없게 되었다.

Intro

12

증가하는비용,줄어드는효과

정리되지 않은 코드, 복잡하게 중첩된 테이블 레이아웃, <font> 태그와 필요 없는 소스들로

인해 웹사이트의 전송량은 두세 배로 증가하게 된다. 방문자들은 페이지가 로딩될 때까지 한없

이 기다리면서 그 비용을 지불하게 된다. 아니면 기다리다 지쳐서 떠나버리기도 한다. 일부 방

문자들은 참을성 있게 기다려 로딩된 사이트를 접하게 되지만, 여러 가지 이유로 인해 접근이

가능하지 않을 수도 있다.

서버들은 겨우 20명 정도를 만족시킬 만한 60 킬로바이트 용량의 페이지를 천천히 로딩하는데

비용을 지불한다. 또한 사이트의 대역폭을 유지하기 위해 호스팅 업체에게 돈을 낭비하고 있다.

우리가 끌어들인 더 많은 방문자들은 보다 많은 비용을 발생시킨다. 사이트에 맞는 특별한 디

자인에 부응하기 위해서는 데이터베이스도 현재의 용량보다 더 많은 쿼리를 처리해야 하는데,

이는 단계적인 비용 상승을 가져오게 된다. 결국, 이러한 요구(증가한 방문자뿐 아니라 증가된

마크업과 코드)들을 해결하기 위해 추가적으로 서버들을 빌리거나 구입해야 하는 것이다.

또한, 몇가지 다른 방식(다양한 방문자의 환경에 맞춰 여러 가지 버전으로 적절하게 제공하는)

으로 코딩하는 프로그래머들에게 지불되어야 하는 비용은 고스란히 개발 비용의 증가로 이어져

예산을 낭비하게 될 수도 있다. 새로운 버전의 브라우저와 무선기기가 등장함에 따라, 그런 디

바이스(브라우저나 무선기기)들까지 포용하기 위한 작업 비용 때문에 예산은 남아나질 않을 것

이고, 이러한 악순환은 계속 반복되게 된다.

최신 버전의 브라우저로 사이트를 방문했을 때, 그 브라우저보다 구 버전의 브라우저에 최적

화되어 있으니 사용을 권장한다는 문구를 보게 되는 어이없는 경험을 우리들은 이미 많이 해왔

다. 물론 사이트 관리자들이 멍청하거나 생각이 없는 것이 아니다. 단지 ‘끝없이 반복되는 업그

레이드’에 예산을 낭비하고 더 이상 지불할 돈이 없게 된 것이다.

예산 부족이 아닌 또 다른 문제는, 무엇이 투자에 대한 최적의 결과물로 나타날지에 대한 지식

이 부족하거나 혹은 그것을 잘못 알고 있는 경우이다. 얼마 전 보고된 바에 따르면, ‘커뮤니케

이션이 세상을 바꾼다’라는 슬로건을 가진 ‘Conntected Earth’에서 100만 파운드(글 쓰는 시

점 기준, 약 180만 달러)의 비용을 들여 사이트를 개편했다. 사이트 개발로 예산이 낭비되었음

에도 불구하고, 그 사이트는 현재 존재하는 거의 모든 최신 브라우저에서 호환되지 않는다. 모

질라[01]와, 넷스케이프 6/7버전, 오페라[02]에서 접근이 거부되었다. 이유는 운이 없게도, 이

사이트는 윈도우 시스템 기반이 아닌, 맥킨토시 기반(맥킨토시에서 사용하는 인터넷 익스플로

러 포함)의 사용자들에게는 호환되도록 개발되지 않았기 때문이다.

13시작하기 전에

좋은 소식: 이 책에서 다루는 표준을 이용해 새롭게 사이트를 개편한 뒤로, Connected

Earth의 웹사이트는 그동안 접근할 수 없었던 수백만의 사용자들이 사용할 수 있게 되었다(나

쁜 소식? 회사는 웹표준으로 만세를 부르기 이전에 이미 100만 파운드(180만 달러)를 날렸다

는 것이다).

02

윈도우 XP에 설치된 오페

라 7에서 본(정확히 말하자

면 볼 수 없는) 같은 사이트.

Connected Earth의 기

술적인 문제들은 이 책에

설명된 방법들로 해결이 가

능했다. 회사도 진지하게

이를 수용했다.

01

엄청난 개발 비용을 들였음

에도 불구하고, Connec

ted Earth는 거의 모든 최

신 브라우저에서 호환되지

않는다. 다른 플랫폼의 모

질라, 넷스케이프 6/7버

전, 오페라 브라우저도 고

려하지 않았고, 맥킨토시

운영체제에서의 인터넷 익

스플로러나 다른 브라우저

를 사용하는 사용자도 고려

하지 않았다(www.con

nected-earth.com).

14

예산을 초과하는 재작업 비용의 부담으로 인한 폐물로 전락하건, 처음부터 구식의 사양을 가지

고 만들어진 사이트이건 간에, 결과는 마찬가지이다. 즉, 잠재적 고객의 꾸준한 증가 추세는

둔화된다는 것이다. 결국, 100만 파운드를 들였건 천 달러를 들였건, 목적은 정보를 보여주기

위한 것이 아닌 방문자를 오게 만드는 것이다. 다행스럽게도, 두 가지 문제를 풀 수 있는 해결

책 또한 같다.

구식화의악순환끝내기

월드와이드웹 컨소시엄(World Wide Web Consortium, ‘W3C는 무엇인가?’ 참조)과 여러

표준화 단체들이 함께 만들고, 최신 브라우저와 기기들이 지원하는 기술들은 표준과 브라우저

가 발전하더라도, 계속 사용할 수 있는 사이트 디자인을 가능하게 해준다. 고난을 겪어본 업

계의 베테랑들은 이러한 주장에 다소 회의적일 수도 있겠지만, 이 책에서 해결 방법을 알려 줄

것이다.

이 책은 머지않아 진부해질 수 있는, 통찰력 없이 제작된 ‘솔루션’을 위해 부족한 시간과 돈을

낭비할 필요 없이, 잠재적인 방문객들도 염두에 두고, 데스크탑을 넘어 현재와 미래의 웹을 위

한 디자인을 할 수 있으며, ‘만들고, 버리고, 다시 만드는’ 악순환의 고리에서 빠져 나갈 수 있

는 방법을 알려 줄 것이다.

이 책은 이론가를 위한 책이 아니라, 실질적으로 일을 해야 하는 작업자를 위한 책이다. 또한

현명한 조언과 증명된 기술을 찾아서 기술과 생각을 향상시키고, 더 많은 방문자와 고객들이

원하는 멋진 웹사이트를 만드는 창의적인 사업 전문가를 위한 책이다.

디자이너와 개발자들은 자신들이 가지고 있는 마크업과 코딩 기술이 시간이 지나면 진부해지

는 것을 피하며, 다양한 브라우저와 기기에서 작동할 수 있는 웹사이트를 만들 수 있게 될 것

이다.

사이트 관리자는 세부적인 업무에서 끊임없이 반복작업으로 발생하는 비용의 낭비를 막을 수

있을 것이다. 그리고 상위 호환이 가능한 사이트 제작을 위한 필수 문서들을 작성하는 방법도

알게 될 것이다.

15시작하기 전에

상위호환성이란무엇인가?

이 책에서 자주 ‘상위 호환성’이라는 말을 사용한다. 이것의 정확한 의미는 무엇일까? 여기서는

올바른 방법으로 디자인 되고 개발되어 웹 상에 퍼블리싱된 모든 페이지들이 다양한 브라우저

와 플랫폼 그리고 인터넷 기기들에서도 잘 작동한다는 것을 의미한다. 그리고 이는 새로운 브

라우저나 기기들이 생겨나도 마찬가지로 제대로 작동된다는 것을 의미한다. 공개표준Open Standards

이 이러한 것을 가능하게 해준다.

또 하나 매력적인 것은, 표준에 맞춰 디자인을 하게 되면, 특별한 요청이 있는 사람들에게는 더

높은 접근성을 부여할 수 있으며, 생산과 유지에 소요되는 비용은 낮출 수 있다(적은 비용으로

더 많은 사용자들에게 홍보 효과가 있고, 접근성에 관한 소송이 일어날 가능성을 줄일 수 있다

는 의미이다).

여기에서 말하는 ‘웹표준’은 어떤 의미일까? ‘웹표준화 프로젝트’에서 의미하는 바와 같다. 즉,

XHTML과 XML같은 구조적인 언어와, CSS와 같은 표현을 위한 언어, W3C DOM과 같은

객체 모델, 그리고 ECMAScript와 같은 스크립트 언어까지 이 책에서 다루게 될 이 모든 언

어들을 의미한다.

W3C는 무엇인가?

1994년에 설립된 월드와이드웹 컨소시엄 (W3C, http://www.w3.org)은 웹의 성장을 촉진시키고, 웹 기술들이 상호 협조

적으로 사용될 수 있도록 하기 위한 조항과 가이드라인을 제정한다. 이 조직에는 대략 500명 정도의 구성원들이 소속되어 있고,

디렉터는 1989년 웹을 창안한 팀 버너스리(Tim Berners-Lee, http://www.w3.org/People/Berners-Lee)이다.

W3C에 의해 만들어진 이 세부 사항에는 HTML, CSS, XML, XHTML 그리고 표준 Document Object Model(DOM) 등

을 포함하고 있다.

몇 년 동안 W3C는 의도한 것은 아니지만 넷스케이프나 마이크로소프트 같은 회원 업체들이 엄격하게 지키지 않아도 되는 ‘권고안’

을 적용해왔다. 1998년 설립된 ‘웹표준화 프로젝트(The Web Standards Project, www.webstandards.org)’는 W3C

의 주요 권고안을 ‘웹표준’이라고 명칭을 다시 정의하여, 모든 브라우저와 인터넷 기기의 중요한 구성요소로서 정확하고 완벽한

지원이 될 수 있도록 재조정하는 활동을 펼쳐왔다.

다른 표준화 단체로는 ECMAScript 언어로 잘 알려져 있는 유럽 컴퓨터 제조업자 협회(ECMA)가 있는데 보통 ‘표준 자바스크

립트’로 더 친숙하다.

16

작업 그룹의 전문가들에 의해 잘 다듬어진 이러한 기술들은 최대한 많은 수의 웹 사용자들에게

최고의 서비스를 제공하기 위해 주의 깊게 설계되었다. 이와 함께 이러한 기술들은 합리적이고,

접근성도 높으면서, 세련되고, 비용절감을 할 수 있는 웹 개발의 지표를 마련했다(사이트 관리

자: 여러분은 이 책에 있는 기술적인 부분은 신경 쓰지 않아도 된다. 단지 직원들과 업체가 이

러한 것들을 알 수 있도록 하면 된다).

표준을 지원하는 브라우저는 어떤 의미일까? 모질라Moz�lla의 파이어폭스f�refox(이하, 파이어폭

스), 오페라 소프트웨어Opera Software의 오페라(이하, 오페라), 애플Apple의 사파리Safar�(이하, 사파

리), 그리고 마이크로소프트의 인터넷 익스플로러(이하, 인터넷 익스플로러) 6버전 이상과 같

이 XHTML, CSS, ECMAScript, DOM을 지원하고 폭넓게 이해하고 있는 제품들을 말한

다. 이러한 브라우저들이 표준 사항들을 빠짐없이 완벽하게 지원할까? 물론 아니다. 지금까지

나온 어느 브라우저도 버그가 없는 것은 없다. 더욱이 표준들은 그것들 자체로 상당히 정교하

고 매우 복잡하게 서로 연관되어 있다.

표준을 지원한다는 측면에서 다른 것들에 비해 더 나은 브라우저가 있을까? 현업에 있는 모든 개

발자들은 이 질문에 대한 답을 알고 있을 것이다. 이 책이 출간되는 시점에서 인터넷 익스플로러

6은 파이어폭스나 오페라, 사파리만큼 표준을 지원하지 않는다. 하지만 인터넷 익스플로러가 브

라우저 시장을 잠식한지 5년이 지난 지금, 마이크로소프트는 이전 버전의 인터넷 익스플로러보

다 표준을 훨씬 더 많이 지원하는 새로운 버전의 인터넷 익스플로러를 출시하려고 하고 있다. 이

책을 읽고 있는 시점에는 이미 인터넷 익스플로러 7이 출시되어 컴퓨터에 설치되어 있을 것이다.

방문자가 인터넷 익스플로러 5.5버전 이후로 컴퓨터를 업그레이드 하지 않았다고 하더라도,

2000년 이후로 출시된 브라우저들은 구식 방법을 사용하지 않아도 될 만큼 잘 만들어져 있고,

더 잘 작동하고, 표준에 맞게 디자인되어, 더 많은 사용자를 만족시킨다. 그리고 표준은 애초

에 포괄적이기 때문에 상위 호환적인 방식이기는 하지만 오래된 브라우저나 기기들을 사용하는

사람도 수용이 가능하다.

규정도없고정석도없다.

이 책은 정석을 위한 책은 아니다. 웹사이트를 만드는데 정해진 최고의 방법은 없고, 자신의 작

업에 표준을 올바르게 적용하는 사람도 없다. 이 책은 어떤 사이트나 업무에 더 적합할 수 있는

과도기적인 접근을 버려가면서까지 엄격한 표준을 지키라고 주장하지 않을 것이다. 모든 W3C

의 권고안이 완벽하다고 느껴지는 것 때문에, 웹표준이 실제보다 높게 평가되지는 않을 것이다.

17시작하기 전에

(솔직히 필자도 완벽하게 웹표준으로 무장하고 있는 것은 아니다).

(이 책은) 작업을 진행하면서 알아야만 하는 인터넷 익스플로러와 다른 최신 브라우저에서 종

종 발생하는 일시적이고 거북한 문제들에 대해 알려줄 것이고, 일부 고지식한 방문자들이 사용

하는 오래된 브라우저에 대처할 수 있는 전략을 알려줄 것이다.

이 책이 여러분에게 거짓말을 하지는 않을 것이다. 일부 표준들은 조금 애매할 수도 있고, 그에

맞게 대처할 수 있는 ‘최선의 다른 방식’을 만들기도 하고, 브라우저 개발에 느슨하게 적용되도

록 하기도 한다. 내가 2002년에 이 책의 초판을 썼을 당시 사람들을 애타게 만들었던 CSS 2.1

버전은, 2006년 두 번째 책을 쓰는 지금도 여전히 완성되지 않았지만, CSS 2 버전을 수정해

서 좀 더 명확히 하겠다고 약속했다. WCAG 2.0도 마찬가지로 조금은 퇴색된 1.0의 접근성

스펙이 명확하게 정리되길 바란다. 이 책을 통해 표준의 모호한 부분과 표준화 커뮤니티가 합

의에 도달한 부분에 대해서 설명할 것이다.

또한, 시멘틱semant�c 마크업과 XHTML의 장점에 대해서 알아보기는 하지만, 모든 사이트의 모

든 페이지에 사용된 태그들 전부가 구조적이어야 한다고 말하는 것은 아니다. 그리고, 모든 사

이트들이 지금 당장 HTML에서 XHTML로 바뀌어야 한다고 주장하지도 않을 것이다. 단지,

그것을 실행하고 싶어하는 사람들에게 XHTML의 장점을 알려주고 싶을 뿐이다.

나는 웹 페이지의 레이아웃을 작업할 때는 기존의 HTML 테이블 방식보다 CSS로 작업할 것

을 꾸준하게 주장해왔다. CSS 표준은 개발자와 사이트 방문자 양쪽 모두를 위해 많은 문제를

해결해준다. 이 책의 초판이 나온 이후로 CSS 레이아웃은 대세로 기울었다. 개인 사이트보다

수천 배 많은 트래픽을 가진 사이트에서, 이러한 현상을 발견할 수 있을 것이다.

아직도 테이블 레이아웃은 사라지지 않았고, 일부 디자인에서는 더 적합하기도 하다. 마크업이

의미있지semant�c는 않아도, 그 안에 들어가는 내용은 의미있을 수도 있고, 표준을 준수하기도 한

다. CSS 자체의 장점은 더할 나위 없이 매력적이지만, 선택은 여러분의 몫이다.

일부 웹표준 지지자들은, 플래시나 퀵타임Qu�ckT�me 같은 유명한 기술들은 웹에서 설 자리가 없을

것이라고 생각한다. 이론가들에게 이러한 태도는 옳을지 모르겠지만, 그 외 나머지 작업자들에

겐 해야 할 일이 있고, 플래시나 퀵타임 같은 기술들이 어떤 작업에서는 최선의 방법이 되기도

한다. 이 책에서는 마크업과 접근성에 관련된 경우를 제외하고는 이러한 기술들에 대한 언급이

많지는 않을 것인데, 이는 단지 플래시나 퀵타임을 선호하지 않기 때문이 아니라 이 책의 범위

를 벗어나기 때문인 것이다.

18

GIF 포맷 이미지 사용을 반대하는 웹표준 지지자나, CSS로 스타일 정의된 XHTML 대신에

GIF 포맷의 텍스트로 제목(헤드라인)을 만드는 것을 잘못된 것이라고 지적하는 사람을 본 적이

있을 것이다. XHTML을 사용하여 제목(헤드라인)을 지정하는 것이 대부분 권장하는 방법이고,

최선의 선택이 되기도 한다. 하지면 실제로는 상표(브랜드)를 표현하는 데는 문제가 되기도 한

다. 자간이 조절된 보기 좋은 GIF 이미지(혹은 PNG)의 사용은 Arial, Verdana, Georgia

와 같은 시스템 폰트만을 사용하여 CSS로 작업한 것보다 훨씬 좋은 선택일 수도 있다. 여러분

의 사이트이니 선택은의 몫이다.

이론이아닌실제

웹표준으로 작업하는데 열정을 가진 사람들을 반대하는 것이 아니다. 실제로는 그 반대이다.

오히려 이런 사람들을 굉장히 존경하고, 친하게 지내는 것을 행운으로 여기기도 하고, 그들로

부터 많은 배움을 얻기도 한다.

03

하루 100만 명의 방문자

를 가진 ESPN.com은 실

험적인 디자인 기술을 사용

해보기는 힘들다. 그래서

ESPN.com이 이 책에서

권하는 방법과 CSS 레이

아웃을 사용하는 것이다.

19시작하기 전에

하지만 이 책은 직접 작업을 하는 디자이너와 개발자, 그리고 그들의 전문적 기술에 돈을 지

불하는 고객과 고용주를 위한 책이다. 웹표준에 대한 탐구는 디자인과 컨텐츠의 문맥, 그리

고 마케팅 이슈에서 비롯되었다. 나의 목표는 여러분을 웹표준의 세계로 인도하고, 여러분이

모든 디자이너와 고객이 만족할 수 있는 결정을 내리도록 도와주는 것이다.

(이 책에서) 한 가지 확고하게 고집하는 것이 있다면, 그것은 일반적으로 비즈니스에 투입되

는 비용이 너무 높다는 것이다. 이 책을 읽는 어느 누구도 과거의 단편적인 방법들을 사용하

여 오늘날의 웹사이트를 디자인 하는 것을 원하지 않는다.

오래된 기술들도 웹표준이 만들어지기 전까지는 설 자리가 있었고, 주요 브라우저에서도 미

약하게나마 지원을 했었다. 하지만 더 이상은 그렇지 않다.

마찬가지로 모든 사이트를 다양한 방문자의 환경에 맞춰 여러가지 버전으로 적절하게 제공하

는 다른 방식으로 코딩하는 것은 인터넷 붐이 한창이었던 때와 지나치게 부풀어 오른 예산을

전부 사용해 버려야 할 때에는 적절한 방법처럼 보였다, 하지만 그런 시절은 지나갔다.

여기에 XHTML, XML, CSS, ECMAScript 그리고 DOM이 있다. 그 자체로 끝이 아니

라, <blink> 태그가 사용될 때부터 사이트 관리자와 개발자에게 골칫거리로 여겨져 왔던

문제들에 대한 합리적인 해결책을 그 요소로 갖추고 있다.

웹표준화 프로젝트란 무엇인가?

1998년에 설립된 웹표준화 프로젝트(WaSP)는 사이트 제작 비용을 줄이고 복잡성을 단순화시키고, 간결하면서 접근성을 마련

해주는 스펙(표준)들을 지지하는 디자이너와 개발자들의 모임이다. 이 그룹은 넷스케이프와 마이크로소프트 그리고 다른 브라우

저 업체들에게 표준을 정확하고 완벽하게 지원하도록 설득하여 브라우저 전쟁을 종식시키는데 큰 역할을 했다. 이러한 노력 덕분

에 현재의 모든 브라우저는 당연한 결과로 웹표준을 지원하고 있다.

또한, 이 그룹은 개발 툴 제작업체(예를 들면, 드림위버를 제작한 사람들)나 사이트 관리자, 디자이너들과 함께 작업하고 있다. 웹

표준화 프로젝트(WaSP)는 주로 권고하는 활동을 하고, 영리를 목적으로 사업을 하지 않으며, 활동에 대한 금전적인 보상도 없

다. 나도 이 그룹의 공동 설립자이면서, 회사를 그만두기 전 몇 년간은 리더이기도 했다. 이제 더 이상 공식적인 리더는 없지만,

사실상의 리더는 데이브 시어Dave Shea와 공동 집필한 『Zen of CSS Design』을 포함해 여러 좋은 책을 집필한 몰리 홀즈쉬랙Molly

Holzschlag이다. 이 책이 출간될 즈음, 웹표준화 프로젝트(WaSP)는 새롭게 출시되는 인터넷 익스플로러 7버전의 CSS 버그를 발견

하고 제거하기 위한 작업을 마이크로소프트의 기술자들과 하고 있다.

20

꼭이책을읽어야할까?

낡은 웹의 재앙을 걷어내고 다음 단계로 전진하기 위해서 디자이너와 개발자들은 웹표준을 사

용하는 법을 배워야 하고, 사이트 관리자는 그들의 사업에 웹표준이 얼마나 도움이 되는지 알

아야 한다.

웹표준이라는 새로운 사실은 그것 자체로는 명확하다고 할 수 없을 것이다. 사업가들이 W3C

웹사이트를 꼼꼼하게 찾아보거나 숨겨진 문서를 판독할 리도 없고, XHTML이나 CSS와 같은

애매한 머리글자로 된 약어들이 어떻게 이익을 증대시켜 줄 수 있는지 찾아내기도 어려울 것이

다. 또한 과중한 업무에 시달리며 마감에 쫓기는 디자이너와 개발자들도 새로운 웹 기술을 알

기 쉽게 설명한 설명서나 메일링 리스트를 찾아볼 시간이 그리 많지 않다.

표준을 정착시키기 위해서는 적절한 책이 필요했고 웹표준화 프로젝트의 공동 설립자이자 수년

간의 리더로서 저자가 그 일을 하게 되었다.

아마도 이 책을 읽는 독자들은 웹의 기술적인 기반보다는 그래픽 디자인이나 정보 구조�nformat�on

Arch�tecture 혹은 사용성에 대해 더 알고 싶어할 것이다. 나 역시 그러한 것들에 대해서 쓰고 싶다.

하지만, 특정 브라우저나 기기에서 동작을 하지 않는다면, 디자인, 설계, 사용성에 대한 우리

의 노력은 헛수고에 불과할 것이다. 프레임 수와 렌즈, 녹음 기술에 관한 협의가 없으면 영화를

찍을 수가 없는 것과 마찬가지로 웹 디자인과 개발의 지속적인 성장은 웹표준의 도입에 달려있

다. 이러한 표준이 없다면 진정한 사용성이나 디자인으로의 일관된 접근법도 없을 것이다.

웹은 지금까지 나온 어떤 매체보다 빠른 성장을 해왔다. 하지만 웹의 상업적인 성공은 산업의

표준이 개발되기 이전에 이루어졌고, 이는 독점적 브라우저로 인해 시대에 뒤떨어진 제품(웹사

이트)을 꾸준히 개발하거나, 끊임없이 새롭게 개발되고 있는 기기의 출현이라는 위험한 위치로

우리 모두를 내몰았다. 우리 모두는 제품생산에 너무 바쁜 나머지 우리가 일하고 있는 방식에

대한 의문을 제기할 시간이 없었다. 하지만 계속 작업하고 제품을 생산하려고 한다면, 이제는

의문을 제기하고 방법을 바꿔야 할 때이다.

웹표준은 우리 모두가 오늘날 그런 것처럼 이후로도 제대로 동작할 수 있는 세련되면서 아름다

운 사이트를 만들 수 있게 해주는 도구이다. 이 책에서는 각각의 표준이 하는 역할을 설명하고

상위호환이 가능한 사이트를 만드는데 어떻게 협업이 가능한지를 설명할 것이다.

선택은 여러분의 몫이다.

2101장 ㅣ 웹사이트의 99.9%는 시대에 뒤떨어진다

웹사이트의 99.9%는 시대에 뒤떨어진다

01장

초라한 개인 홈페이지에서부터 수백만 달러 규모의 대기업 사이트까지, 오늘날 많은 웹사이

트들이 거의 똑같은 병으로 괴로워하고 있다. 이 병은 웹 산업에서 면역력이 강해진 규범처

럼 교묘하게 그 모습을 드러내지 않는다. 비록 웹사이트의 관리자들은 아직 모르고 있겠지만,

99.9%의 웹사이트는 시대에 뒤떨어져 있다.

이러한 사이트들은 평소 우리가 사용하는 컴퓨터의 브라우저에서는 제대로 보이고 작동한다.

하지만 결점을 관대하게 받아들이는 환경을 벗어나게 되면, 이 병의 징후와 현상을 금방 확인

할 수 있을 것이다.

인터넷 익스플로러, 오페라, 사파리, 그리고 모질라(파이어폭스, 카미노, 넷스케이프 네비게

이터를 만든 Gecko 기반의 오픈 소스 브라우저)의 최신 버전 브라우저에서 공들여 만든 레이

아웃은 망가지기 시작했고, 많은 비용을 들여 개발된 기능들은 동작을 멈추고 있다. 이러한 주

요 브라우저들이 발전해감에 따라, 사이트의 성능은 점점 더 악화되어 가고 있다.

‘비주류’ 브라우저나, 장애인들이 사용하는 스크린리더, 그리고 폭발적으로 증가하고 있는

PDA에서부터 인터넷 접속이 가능한 휴대전화에 이르기까지, 이러한 기기를 통한 사이트 접속

은 거의 불가능한 반면, 별로 중요하지 않은 기능들은 잘 작동된다. 사이트 관리자와 개발자들

은 일반적인 브라우저 중심의 개발을 위해 필요와 예산에 따라, ‘비주류’ 브라우저와 휴대 기기

등에 대해서는 완전히 무시하거나, 약간의 마크업과 코드를 추가하여 일부분만 지원하는 정도

이다.

22

이런 낡고 가치없는 업계의 관행들을 깨닫고, 의도했던 목적을 이루지 못하면서 증가하는 비용

과 웹개발의 복잡성을 이해하기 위해서는 현재 사용하는 브라우저를 살펴보고, 과거의 비표준

브라우저들과 어떻게 다른지 확인해봐야 한다.

최신브라우저들과웹표준

이 책에서 말하는 ‘최신’, ‘표준 지원’을 하는 브라우저는 HTML, XHTML, CSS,

ECMAScript, DOM을 인식하고 지원하는 브라우저들을 말한다. 그리고 이러한 요소들은 표

현을 위한 마크업이나 호환성 없는 스크립트 언어 등으로 인한 ‘끊임없는 진부화’를 극복하게 해

주는 표준들이다.

표준을 지원하는 최신 브라우저로는 최고의 찬사를 받은 오픈 소스 파이어 폭스 1.5와 그의 형

제격인 넷스케이프 네비게이터 8, 인터넷 익스플로러 6과 이후 버전, 애플의 사파리 2.0, 오

페라 8.5와 같은 브라우저들이다(혹시 다른 표준 지원 브라우저를 빠뜨렸다면, 일부러 무시한

것이 아니라 이 책이 쓰여진 시기가 오래 전이기 때문일 것이다). ‘표준 지원’이라는 표현을 사

용했지만, ‘시작하기 전에’ 장에서 언급했던 말을 기억하자. 어떤 브라우저도 완벽하게 표준을

지원하지 않고, 또 할 수도 없다.

하지만 브라우저가 완벽하게 지원할 수 없다는 것이 표준을 지원하지 않겠다는 이유가 될 수는

없다. 여전히 대다수의 사람들은 인터넷 익스플로러 5나 5.5를 사용하고 있다. 표준의 관점에

서 볼 때, 이런 브라우저들은 인터넷 익스플로러 6, 파이어폭스, 오페라, 사파리보다 뒤떨어진

다. 이러한 이유로 인터넷 익스플로러 5를 사용하는 방문객들을 포기해야만 할까? 아니면 인

터넷 익스플로러 5를 사용하는 방문객들에게 브라우저를 업그레이드하든가 사이트 방문을 하

지 말라고 할 것인가? 물론 아니다. 웹표준을 기반으로 하는 디자인과 개발은 ‘최신브라우저에

맞는 디자인’을 의미하지도 않고, 필요로 하지도 않는다.

2301장 ㅣ 웹사이트의 99.9%는 시대에 뒤떨어진다

또, XHTML, CSS를 사용한다고 해서 넷스케이프 4 사용자들을 포기해야 한다는 것은 아니

다. 하지만 표준에 맞게 제대로 디자인되고 개발된 사이트라고 해도 넷스케이프 4에서 표준을

지원하는 브라우저에서 보이는 것처럼 픽셀단위까지 똑같이 보이지는 않는다. 사실 그건 디자

인하는 방법에 따라 완전히 다르게 보일 수도 있다. 그래도 괜찮을 것이다(왜 그런지는 2부에

서 설명할 것이다).

맥Mac용 인터넷 익스플로러 5의 특이한 케이스

웹표준에 대한 지식이 있는 디자이너들에게 친숙하면서도 동시에 욕을 먹는 맥용 인터넷 익스플로러 5는 표준화의 역사에서 특별

한 위치를 점하고 있다. 1990년대 엔지니어 탄텍 셀릭Tantek Çel�k은 W3C CSS와 HTML 작업 그룹에서 마이크로소프트 사를 대

표하는 인물이었다. 그가 맥용 인터넷 익스플로러 5 개발팀 리더로 임명되었을 당시, 탄텍의 웹표준에 대한 지식과 열정은 대단

했다. 또 그는 웹표준화 프로젝트(WaSP)의 핵심 맴버로 웹표준의 최신기술을 연구하고 하나의 컬럼(single column)을 가진

CSS 레이아웃을 적용하기 위한 브라우저 호환 테스트 작업을 하였으며, 웹페이지의 접근성을 높이기 위한 사용자 인터페이스

강화에 힘썼다. 그 결과로 이전의 브라우저보다 더 정확하고 심도 있게 웹표준을 지원하는 브라우저가 나오게 되었다. 2000년도

에 폭넓은 사용을 위해 출시된, 맥용 인터넷 익스플로러 5는 최초의 표준 지원 브라우저였다.

하지만 맥용 인터넷 익스플로러 5의 표준화 지원은 윈도우용 인터넷 익스플로러를 너무 뒤쳐져 보이게 했다. 이런 이유로 마이크

로소프트는 탄텍에게 더 이상 브라우저 관련 업무를 맡기지 않았고, 브라우저의 버그는 그대로 남게 되었다. 이런 버그들은 다른

표준 지원 브라우저들이 시장에 나오면서 서서히 모습을 드러내게 되었고, 디자이너들은 CSS를 이전보다 더 엄격하게 사용하기

시작했다. 예상대로 다른 브라우저들이 발전하는 동안 맥용 인터넷 익스플로러 5는 더 이상 발전할 수 없게 되었고, 사용자는 점

점 줄어들었다. 결국 2006년 1월, 마이크로소프트는 공식적으로 맥용 인터넷 익스플로러 5의 개발을 중지하게 되었다.

오늘날 디자이너들은 맥용 인터넷 익스플로러 5의 이런 개척적인 면에 감동받기보다는 잘 만들어진 CSS 레이아웃을 제대로 지

원하지 못하는 것에 더 실망을 느낀다. 지금은 사라진 브라우저에 대해 평가를 하자면, 맥용 인터넷 익스플로러 5의 표준 지원은

마이크로소프트에게 윈도우용 브라우저에 더 많은 표준을 지원할 수 있도록 힘을 실어주었다. 그런 맥용 인터넷 익스플로러 5의

사례와 같은 일이 없었다면, 우리는 여전히 아무 생각 없이 테이블 레이아웃 작업을 하고 있을 것이다. 이와 더불어 텍스트 확대

기능과 같은 유용한 맥용 인터넷 익스플로러 5의 기술들이 비록 아직은 윈도우용 인터넷 익스플로러에는 탑재되지 않았지만, 파

이어폭스, 사파리 등 최신 브라우저에는 이 기술들이 사용되고 있다.

24

새로운작업을위한새로운코드

최신 브라우저들이 단순히 예전과 똑같은 브라우저의 새 버전만을 의미하지는 않는다. 이전 버

전의 브라우저와는 근본적으로 다르다. 많은 브라우저들이 기본부터 완전히 새롭게 만들어졌다.

모질라 파이어폭스, 카미노, 넷스케이프 7 그리고 Gecko 기반 브라우저들은 넷스케이프 4의

새로운 버전이 아니다. 맥용 인터넷 익스플로러 5는 맥용 인터넷 익스플로러 4에서 업데이트

된 것이 아니다. 오페라 7 같은 경우도 이전의 오페라 브라우저와 같은 코드로 만들어진 것이

아니다. 이런 브라우저들은 새로운 작업을 하기 위해 웹표준을 최대한 완벽하게 지원할 수 있

도록 새로운 코드로 만들어졌다.

반면, 1990년대 브라우저들은 독자적인 기술(넷스케이프 전용, 익스플로러 전용)에 중점을 두었

고, 웹표준에는 거의 신경쓰지 않았다. 비록 이전 브라우저들에서 몇몇 표준은 무시되었지만, 개

발상 큰 어려움은 없었다. 예를 들어, 만약 브라우저가 PNG 포맷을 지원하지 않았다면, 개발자

들은 PNG 포맷의 이미지를 사용하지 않는다. 문제될 것은 없다. 문제가 될 수 있는 부분은 이러

한 이전 브라우저들은 표준을 부분적으로 지원하거나 올바르지 않게 형식적으로만 지원하고 있다

는 것이다. HTML과 같은 기본적인 표준을 올바르게 지원하지 않음으로 인해, 검증되지 않은 웹

페이지 제작 방법에 기대어 도저히 지지할 수 없는 웹 개발 환경을 만들어 버렸다.

환자의 맹장이 터지면, 유능한 외과의사가 맹장수술을 하게 된다. 하지만 당장 수술할 외과의

사가 없다면 어떻게 될까? 만약 술에 취한 인턴이 맹장의 절반을 잘라내고, 다른 장기들도 막

찔러놓고, 마지막으로 봉합하는 것을 잊어 버린다면? 불쾌한 예를 들어 미안하지만, 이것이 건

강한 웹을 해칠 수 있는 위험할 정도로 쓸모없고, 불완전하며, 오래된 브라우저에서 표준을 지

원하는 것과 같은 상황이다.

만약 넷스케이프 4가 <body> 요소에 적용된 CSS 규칙을 무시하고, 페이지의 모든 구조적

인 요소에 무작위로 공백을 삽입하고, 인터넷 익스플로러 4는 <body>는 올바르게 표현하지

만 padding을 잘못 적용한다면, 어떤 CSS를 안심하고 사용할 수 있을까? 어떤 개발자들은

CSS를 전혀 사용하지 않았다. 또 어떤 개발자들은 인터넷 익스플로러 4의 결점을 보정하기 위

한 CSS를 사용했고, 넷스케이프 4를 위한 또다른 스타일 시트를 새롭게 만들어 사용했다. 모

든 브라우저에서 사용 가능하도록 각자 다른 UI와 폰트를 통합하려면, 개발자들은 사이트 방

문자들이 사용하는 시스템 운영체제(윈도우 혹은 맥)에 따라 다르게 작업해야만 한다. 일반적

으로 리눅스는 제외된다.

분명 CSS만 문제가 되는 것은 아니었다. 브라우저들은 HTML이나 테이블 렌더링 방식, 페이

지에 상호작용을 위한 스크립트 사용에 있어서도 일치하지 않았다. 페이지의 내용을 구조적으

2501장 ㅣ 웹사이트의 99.9%는 시대에 뒤떨어진다

로 만드는데 정답은 없다(사실 정답은 있지만, 지원하는 브라우저가 없었다). 페이지 디자인을

만드는 방식에도 정답은 없다(역시 있었으나 지원하는 브라우저가 없었다). 또 사이트에 세부

적인 움직임을 추가하는데 또한 정답은 없다(역시 있었으나 지원하던 브라우저가 없었다).

점점 늘어나는 비호환성에 맞서기 위해, 디자이너와 개발자들은 각기 다른 결함을 가진 브라우

저에 맞추기 위해 비표준 마크업과 코드를 사용하기에 이르렀다. 그것이 하나 이상의 브라우저

나 운영체제에서 작동할 수 있도록 하기 위한 방법이었다. 하지만 오늘날 같이 모든 브라우저

가 공개 표준을 지원하는 상황에서 그것은 올바른 방법이 아니다. 이런 잘못된 개발 방법이 여

전히 남아 있어서 부족한 자원을 잡아먹게 되고, 웹을 망가뜨리며, 접근성이 낮아지고 사용하

기 힘들게 되면서 의도했던 것보다 더 많은 비용이 발생하게 된다.

버전문제

비표준 마크업과 코드의 여러 버전들은 브라우저에서 비표준 유연qu�rk 모드로 적용되게 되는데,

이는 대부분의 사이트와 관리자들을 괴롭히는 반복되는 진부화의 원인이다. 골대는 계속 멀어

지고 게임의 법칙은 항상 변한다.

비록 비용도 많이 들고, 쓸모도 없고, 유지하기 힘들지만, 이러한 비표준 방법의 사용은 필요

없는 상황에서도 계속된다. 많은 개발자들이 웹표준을 지원하는 브라우저를 웹표준을 지원하

지 않는 브라우저처럼 사용한다. 그래서 인터넷 익스플로러 6을 인식하는지 체크하는 스크립

트를 사용하고, 인터넷 익스플로러 6이 표준 ECMAScript와 DOM을 지원함에도 불구하고

마이크로소프트의 전용 스크립트를 사용한다. 또한 ECMAScript와 DOM을 지원하는 최신

모질라 브라우저를 위해 스크립트 작업을 따로 해야 한다고 느낀다.

이러한 사례에서 알 수 있듯이, 여러 브라우저와 기기를 구분하거나 각 버전에 맞도록 스크립

트 작업을 하는 것은, 표준을 준수하는 최근에는 필요가 없다. 사실, 필요하지 않다 라기보다

나쁘다는 표현이 옳다. 사이트 관리자가 매번 할 수 있는 것은 아니지만 지속적인 업데이트를

하더라도, 이러한 스크립트는 자주 오작동을 일으키게 된다.

예를 들어, 맥과 윈도우에 설치되어 있는 오페라 브라우저는 스스로를 ‘익스플로러’로 인식한다.

여러 은행 사이트들과 같이 인터넷 익스플로러에서만 지원하는 사이트에 의해 차단되는 것을

피하기 위해 그렇다. 하지만 인터넷 익스플로러를 위해 실행되는 스크립트 같은 경우 오페라에

서는 작동하지 않는다. 오페라가 인터넷 익스플로러로 인식(설치 시 기본적으로 설정)되고 개

발자들이 인터넷 익스플로러 전용 스크립트를 쓰는 경우, 사이트는 작동하지 않게 되고 사용자

들은 혼란을 겪게 된다. 사용자설정을 변경하여 인터넷 익스플로러로 인식되지 않게 하고 오페

26

라로 인식되게 조정할 수 있다. 하지만 그런 옵션에 대해서 아는 사용자는 별로 없으며, 그렇게

설정을 바꿔야 할 필요성을 못 느끼고 있다.

개발자들은 독자적인 스크립트와 함께, 검색엔진, 비주류 브라우저나 기기에서 접근성이 떨어

지는 페이지를 만들면서, 페이지에 접근하기 위해 더 큰 대역폭을 사용해야 하는 ‘표현을 위한

마크업presentat�onal markup’을 사용한다(이 역시 잠재적인 사용자들이 사이트의 내용을 찾아오기 어렵

게 만든다). 이러한 전략들은 주로 브라우저마다 다르게 보이는 문제를 해결하려고 할 때 생기

는 또 다른 문제에서 비롯되었다[1.1, 1.2].

여러 버전의 브라우저를 사용하면 끊임없이 증가하는 비용과 알 수 없는 문제들이 생긴다.

‘DHTML’ 사이트는 넷스케이프 4와 인터넷 익스플로러 4의 독자적인 스크립트 스팩으로 만들

어졌는데, 최신 브라우저에서는 작동하지 않는다. 사이트 관리자가 비용을 더 투입하여 사이트

버전을 늘려야 할까? 새로운 버전의 사이트를 위한 예산이 없다면 어떻게 될까? 결국에는 많은

사용자들이 사용하지 못하게 될 것이다.

마찬가지로, 개발자들은 오랜 시간과 자원을 사이트의 ‘무선’ 버전 개발에 쏟아 붓게 되지만,

그들이 개발한 마크업이 곧 시대에 뒤떨어진 코드가 되고, 새로 나온 기기에서는 작동이 안된

다는 것을 발견하게 될 것이다. 몇몇 개발자들은 또 다른 버전을 만들어 이 문제를 해결하기도

한다. 그 외의 개발자들은 ‘빠른 시일 안에’ 새로운 기기에 대한 지원을 하겠다고 웹사이트에 낯

부끄러운 공지를 하게 된다.

1.1

2002년, MSN 게임

존(zone.msn.com/

blog.asp)에서 7가지 스

타일시트를 선보였는데, 여

전히거의 모든 최신 브라우

저에서 제대로 보여지지 않

는다. 또한 강력한 브라우

저 판별기능이 있는 스크립

트를 포함해 14개의 스크

립트를 선보였다. 하지만

그것 역시 여전히 작동하지

않는다. 다양한 버전의 코

드로 이러한 문제를 해결한

적은 거의 없다.

2701장 ㅣ 웹사이트의 99.9%는 시대에 뒤떨어진다

예전 방식에 익숙한 많은 디자이너와 개발자들은 XHTML, CSS와 같은 웹표준 기술들을 수

용하고 나서도 요점을 제대로 파악하지 못하고 있다. 다양한 버전 작업을 피하기 위해 웹표준을

사용하는 대신, 많은 보수적인 개발자들은 여전히 브라우저나 플랫폼에 맞게 여러 개의 CSS

파일을 만들어 사용하는데, 이는 작업을 스스로 망치는 일이다[1.1, 1.2].

이러한 방법들은 시간과 돈을 낭비시킨다. 또한 시간과 돈이 풍족한 적도 없었다. 더 나쁘게는

이러한 비경제적인 방법들로는 문제를 해결할 수 없다는 것이다. 사이트는 여전히 제대로 동작

하지 않고, 사용자들은 여전히 사용하지 못한다.

이전버전에대한고려

Amazon.com과 eBay.com과 같은 대규모 상업 사이트의 내부를 살펴보자. 복잡한 비표준

마크업, 전용 ActiveX와 스크립트(브라우저 판별 스크립트를 포함), 잘못된 CSS의 사용에

대해서 자세하게 살펴보자. 이런 사이트가 어떤 브라우저에서나 작동하고 있다는 것이 신기할

따름이다.

이러한 사이트들은 넷스케이프 네비게이터나 인터넷 익스플로러의 초기 4세대 브라우저들이

비표준 마크업과 특정 브라우저에 맞는 코드를 허용하지 않았기 때문에, 과거의 주요 브라우저

에서는 잘 작동한다. 사실 그들은 자신들의 영역을 넓히기 위한 터무니없는 전쟁에서 승리하기

위해 적당한 구축작업과 독자적인 스크립트 작업을 조장해왔다.

표준을 지원하지 않는 사이트들은 구버전 브라우저에서 잘 작동하는데, 그 이유는 앞서 설명한

‘버전 문제’ 해결을 위해 특정 브라우저나 플랫폼의 차이를 맞추기 위한 여러 개의 비표준 버전

1.2

솔직히 왼쪽의 스크린샷은

4년 전의 것이다. 최근의

이 웹페이지는 더 많은 코

드가 추가되면서 상태가 더

안좋아졌다. 마이크로소프

트가 처음으로 표준을 지원

하는 브라우저를 시장에 도

입한 지 6년이 지났지만,

아직까지도 마이크로소프

트 사이트의 여러 부분들이

웹표준으로 디자인되었던

처음의 의도대로 작업되지

않은 부분이 많다.

28

을 만들고, 브라우저들의 차이를 조절하기 위해 많은 비용을 들여 웹 개발툴을 도입했기 때문

이다.

내가 알고 있는 어떤 회사는 그럭저럭 쓸 만한 컨텐츠 관리 시스템(CMS)에 100만 달러 이상

의 비용을 소비했다. 이런 소프트웨어의 제작업체들은 CMS를 통해서 모든 양식의 비표준 코

드들을 한꺼번에 처리할 수 있는 능력을 내세우며, 쓸데없이 사용되는 비용을 부분적으로 정당

화하고 있다. 이런 엄청난 비용 낭비에 덧붙여, 이런 잘못된 행동들은 ‘의미있는 컨텐츠’를 ‘의

미없는 태그의 바다’에 빠뜨려 파인더빌리티(findability, 검색 엔진에서 검색이 잘되게 해주

는 web2.0과 연결되는 개념-옮긴이주)에 타격을 입힐 수도 있다[1.3]. 무엇보다도 가장 문제

가 되는 것은 인터넷 접속 환경이 좋지 않은 사용자들에게는 ‘코드의 분리’, ‘복잡하게 중첩된

테이블의 사용’, ‘투명 GIF 간격자 사용’, ‘기타 이미지 핵hack’, ‘업데이트되지 않는 컨텐츠’ 그리

고 ‘잘못된 태그와 속성의 사용’ 같은 요인들이 쥐약의 역할을 한다는 것이다.

1.3

2001년에 만들어진, 복잡

하면서 구조화 작업을 하지

않은 야후의 HTML 마크

업에서 중요한 컨텐츠인 ‘올

해의 인물(person of the

year)’을 찾아보자.

팁: 찾는데 오랜 시간이 걸

렸다면, 독자들이나 검색

엔진들도 마찬가지이다.

2901장 ㅣ 웹사이트의 99.9%는 시대에 뒤떨어진다

동시에, 이런 여러 개의 비호환 버전들은 사이트 대역폭을 증가시켜 자금을 담당하는 부서에서

당황할 만큼의 큰 비용을 발생시킨다. 사이트의 규모가 커짐에 따라 트래픽도 증가하게 되고,

서버의 증설과 이미지 핵, 불필요한 코드와 마크업으로 인해 더 많은 비용을 낭비하게 된다.

구체적인 수치로 말하기는 어렵겠지만, 마크업의 35% 가량을 줄이게 되면 거의 비슷한 비율

의 트래픽 비용을 감소시킬 수 있다. 연간 2,500달러를 지출하는 곳에서는 875달러를 절약

할 수 있고, 160,000달러를 지출하는 곳에서는 56,000달러를 절약할 수 있게 되는 것이다.

야후 초기 화면[1.4]은 하루에 수백만 번이 보여진다. 그럴 때마다 천문학적인 숫자의 페이지 뷰

로 지난outdated HTML 디자인 핵 파일이 증가하여 야후 서버에 기가바이트 급의 트래픽을 일으

켜 엄청난 비용을 발생시켰다. 만약 야후가 높은 전송량을 잡아먹는 <font> 태그[1.3, 1.5]를

CSS로 교체한다면, 페이지당 비용이 감소할 것이고, 자연스럽게 회사의 이익은 증대될 것이다.

이렇다면 야후가 페이지를 변경하지 않을 이유가 없다.

이는 기업이 1990년대 중반의 브라우저에서 보여지는 것이 최신 브라우저에서도 똑같이 보여

지길 바라기 때문이라는 결론을 내릴 수 있다. 아이러니한 것은 야후의 경영진 말고는 아무도

야후가 어떻게 보이든지 관심이 없다는 것이다. 사이트의 지속적인 성공 요인은 디자인의 아름

다움이 아니라, 사이트가 제공하는 서비스인 것이다.

다르게 생각해 본다면, 야후가 아무도 신경 쓰지 않는 웹사이트의 겉모습을 위해 막대한 대역

폭을 낭비하는 것은 웹사이트에 접속하는 이유나 사용성, 이익보다 ‘하위 호환성’을 더 높게 평

가해야 한다는 의지 있는 개발자의 마인드를 이해했기 때문일 것이다.

코드 분리란?

코드란 프로그래머들이 소프트웨어 제품, 운영체제 또는 디지털 세상에서 어떤 것을 창조하기 위해 쓰는 것이다. 하나 이상의 개

발자 그룹이 단일 프로젝트에서 일하게 되면, 코드는 중복적인 비호환 코드들로 분기되어 문제를 해결하기 힘들어지거나 처음 의

도하지 않았던 결과를 초래하기도 한다. 이러한 모순과 중앙 집중된 통제의 부재는 일반적으로 좋지 않은 것으로 받아들여진다.

책에서 말하는 ‘코드의 분기’는 표준 ECMAScript나 DOM을 지원하지 않는 브라우저를 제어하기 위해 여러 개의 비호환 버전

을 만드는 것을 가리킨다(위의 ‘버전 문제’ 참조).

30

1.4

Yahoo(www.yahoo.

com)의 단순한 첫 페이지.

1.5

야후의 껍데기를 한꺼풀 벗

겨보면(소스보기), 이 단순

하게 보이는 웹사이트를 만

들기 위해 사용한 코드와

마크업이 믿을 수 없을 만

큼 복잡하고 혼란스럽다는

것을 알 수 있을 것이다.

야후가 마침내 CSS를 사

용하기 시작했지만, 대역폭

을 낭비하는 거의 모든 방

식을 사용하고 있고, 여전

히 CSS 상단에 <font> 태

그를 사용하고 있다.

3101장 ㅣ 웹사이트의 99.9%는 시대에 뒤떨어진다

구식마크업:비용의증가

예전 방식으로 작업된 하나의 웹페이지의 코드와 마크업의 용량이 60K(킬로바이트)라고 가정

해보자. 기존 방식의 <font> 태그들, 표현만을 위한 속성, 단독적으로 개발된 코드들을 깔끔

하고 구조적이며 약간의 CSS가 추가된 마크업으로 바꾸게 되면 용량은 30K가 된다(경험상,

60K의 마크업은 종종 22K나 그 이하로 작업되는 경우도 많다. 대략적으로 보면 50% 정도

줄일 수 있는 것 같다). 다음의 두 가지 전형적인 사례를 생각해보자.

T1라인절약

시나리오: 직접 서버를 운영하는 소규모의 사업이나 끊임없이 방문자들이 접속하는 공공 웹사

이트. 표현을 위한 마크업을 간결하고 깔끔한 구조적인 XHTML로 바꾸게 되면 페이지의 용량

은 거의 절반으로 줄어들고, 매월 1,500달러를 절감하게 된다.

실행 방법: 방문자들을 최우선으로 생각한다면, 자체 호스팅을 하는 웹사이트는 2개의 T1라

인이 필요한데, 각각 하나의 라인은 한 달에 최소 1,500달러(1,544mps T1라인의 일반적인

비용)의 비용이 들어간다. 파일 사이즈를 50% 줄이게 되면, 하나의 T1라인을 절약할 수 있다.

따라서 운영 비용에서 매달 1,500달러를 줄일 수 있다. 대역폭을 줄일 수 있는 것과 함께 하드

웨어 지출 비용도 줄어들 것이다. 마크업이 단순해질수록 사용자들이 더 빠르게 접근할 수 있

게 된다. 더 빠르게 접근할 수 있게 되면 서버의 과부하도 줄일 수 있고, 운영하고 구입해야 하

는 서버의 개수를 줄일 수 있게 된다. 이는 모든 상업적 사이트(블로그 포함)에서 컨텐츠나 데

이터베이스와 동적으로 연결되어 있는 최신의 서버들에서 특히 그렇다.

전송량측정

시나리오: 상업적으로 운영되는 사이트가 유명해지면, 사이트 관리자는 생각하지도 못했던 수

백에서 수천 달러에 이르는 파일 전송 비용을 매달 부담하게 된다. 파일 사이즈를 반으로 줄이

게 되면, 매달 납득할 수 없을 만큼의 청구 비용을 내지 않아도 된다.

실행 방법: 많은 호스팅 업체들이 사용자들에게 매달 무료로 파일전송량을 최대 3기가까지 할

수 있게 해준다. 3기가 이하로만 유지된다면 평소 요금만 지출할 것이고, 초과를 하게 되면 더

많이 지출하게 될 것이다. 어떤 경우에는 지나치게 많아지기도 한다.

별로 알려지지 않은 예로는, 어떤 호스팅 업체는 프리랜서 디자이너인 알 사퀴Al Sacu�에게 비상업

적 사이트인 Nosepilot.com이 월간 파일 전송량 한계를 초과하게 되어 16,000달러를 부과

했다. 좀 극단적인 경우이고, 알 사퀴는 호스팅 업체가 변경된 약관을 소비자들에게 알리지 않

32

은 것을 증명해서 비용 지불을 피할 수 있었지만, 긴 시간 동안 법정 싸움을 해야만 했다. 어느

누구도 이런 부당한 비용의 지불이나 고약한 호스팅 업체와의 법정 싸움을 원하지 않을 것이다.

물론 모든 호스팅 업체가 제한된 파일 전송량을 초과했다고 부당한 금액을 부과하지는 않는다.

페어닷컴Pa�r.com의 경우, 초과분에 대해 기가당 4.95달러를 부과한다. 더 많은 트래픽을 발생시

키는 대규모의 사이트들은 파일의 사이즈를 줄여서 비용을 절감한다. 사이트의 규모가 크던 작

던, 수백만의 방문자가 있건, 약간의 방문자만 있건, 파일의 용량이 작아질수록 비용 대역폭도

줄어들고, 호스팅 업체와 파일전송 요금으로 옥신각신할 필요도 없어진다. 따라서, 호스팅 업

체를 선정하는 가장 좋은 방법은 사이트의 트래픽이 증가하는 이유로 페널티를 부과하는 업체

보다는 용량에 제한을 두지 않는 호스팅 업체를 고르는 것이다.

간결한 마크업 vs. 압축한 마크업

웹표준 관련 강의를 마친 후, 강의를 듣고 있던 한 개발자가 깔끔하고 구조화가 잘된 마크업의 대역폭 이점들이 압축된 HTML을

사용하는 회사들의 비용을 절감시켜주지 않는다는 주장을 했다.

마크업을 간결하고 깔끔하게(오래된 ‘HTML 디자인’ 방법보다는 시멘틱한 방법으로) 쓰는 것과 더불어 서버환경에서 마크업 파일

을 압축할 수도 있다. 예를 들어, 아파치 웹서버는 HTML을 서버 사이드에서 압축하는 mod_zip 모듈을 가지고 있다. 이렇게

압축된 HTML은 사용자의 브라우저를 통해 압축이 풀리게 된다.

나와 대화를 나누었던 개발자는 다음과 같은 예를 들었다: Amazon.com의 오래된 <font> 태그와 불필요한 요소들로 인해

40K를 낭비하고 있지만, mod_zip을 이용해서 20K로 줄이게 되면, Amazon.com은 마크업 파일이 강연에서 제안하는 비용

보다도 더 적은 비용이 들게 된다는 것이다.

확인해 보니, Amazon.com에서는 mod_zip을 사용하지 않고 있었다. 사실 그 방법은 상업적인 사이트에서는 거의 쓰이지

않았고, 혹시 페이지를 전송하기 전에 압축할 필요가 있을 때 사용되곤 했다. 하지만 이런 부가적인 것을 생각하지 않더라도, 파

일이 작을수록 압축도 작아질 것이다. 80K의 페이지를 40K로 압축해 비용을 절감했다면, 40K를 20K로 압축하면 비용을 더

절감할 수 있을 것이다. 페이지의 보이는 부분에서 절약되는 양은 작아 보일지 모르지만, 그 가치는 누적되어 시간이 지날수록 실

제 운영비용을 줄일 수 있고, 추가비용의 지출을 방지할 수 있다(예를 들면, 증가하는 트래픽을 커버하기 위해 추가적인 T1라인

을 증설할 필요가 없다).

대역폭 줄이기가 깔끔하고 구조화가 잘 된 마크업 사용의 장점이기도 하지만, 그것은 지출을 담당하는 부서, 고객, HTML을 압

축하는 사람들, 그리고 사용하는 우리들에게까지 장점이 되는 것이다.

3301장 ㅣ 웹사이트의 99.9%는 시대에 뒤떨어진다

하위호환성

‘하위 호환성Backward Compat�b�l�ty’이라는 말이 개발자들에게 의미하는 것은 무엇일까? 개발자들에게

물어보면, ‘모든 사용자를 지원하는 것’이라고 말할 것이다. 누가 이런 생각이 틀리다고 할 수

있겠는가.

하지만, 실제로 ‘하위 호환성’은 방문자들이 인터넷 익스플로러 2를 사용하건 파이어폭스 8.5

를 사용하건 똑같은 경험을 하도록, 표준이 아닌 독자적인 마크업과 코드 사용을 의미한다. 전

문적인 개발 방식의 성배처럼 여겨지는 ‘하위 호환성’은 이론적으로 그럴듯하게 들리지만, 비용

이 너무 높고, 실제적으로 개발할 때는 항상 이론과는 다소 차이가 생기게 된다.

진정한 하위 호환(성)은 존재하지 않는다. 항상 한계를 가지고 있다. 예를 들어, 모자익

(Mosaic, 최초의 비주얼 브라우저)이나 넷스케이프 1.0은 HTML 테이블 기반 레이아웃을

지원하지 않는다. 따라서 이런 초기 브라우저를 사용하는 사람들은 넷스케이프 1.1이나 마이

크로소프트 인터넷 익스플로러 2와 같이 조금 나중에 출시된 브라우저에서 보여지는 것과 똑같

은 화면을 볼 수는 없다.

개발자들과 하위 호환성을 원하는 고객들은 불가피하게 넷스케이프 3과 같은 브라우저를 ‘기본

브라우저’로 분류하고, 그 이전 브라우저에서도 사이트가 동작할 것이라고 생각한다 (넷스케이

프 2 사용자들은 버림받았다). 그들이 약속했던 기본 브라우저에 대한 충실한 지원을 위해 개

발자들은 각 브라우저에 맞춘 마크업이나 비표준 핵hack과 같이 전체 페이지를 무겁게 만들게 되

는 차선책을 추가하게 된다.

그와 동시에, 개발자들은 여러 브라우저들이 지원하기로 한 사항들을 충족시키기 위해 다양한

스크립트를 사용하고, 브라우저 판별을 위해 각각의 브라우저 별로 잘 맞는 코드를 추가하게

된다. 그렇게 해서 페이지의 용량이 더 커지고, 서버의 부하를 증가시키고, 사업의 자금이 모

두 없어질 때까지, 끊임없이 이러한 관행은 계속될 것이다.

사용자를막으면손해일뿐이다

어떤 회사들이 자사의 이익을 줄여 가면서까지 웹사이트가 최신 브라우저에서 보이는 것과 똑

같이 오래된 브라우저에서도 보이게 하기 위해서 노력할 때, 많은 다른 회사들은 오직 하나

의 브라우저만 신경 써 왔다. 비용을 줄이려는 의도가 잘못 이해된 사례로서, 인터넷 익스

플로러에서만, 심지어는 윈도우 기반에서만 작동하는 사이트가 증가하고 있고, 그런 이유로

15%~25%의 잠재 방문자와 고객들을 잃어 가고 있다[1.6, 1.7, 1.8, 1.9, 1.10, 1.11].

34

1.6

네비게이터에서 본 KPMG

홈페이지(2003년), 전혀

보이지 않는 것과 마찬가지

다. 인터넷 익스플로러 전

용 코드의 결과

1.7

넷스케이프 7에서도 전혀

사용할 수 없다.

3501장 ㅣ 웹사이트의 99.9%는 시대에 뒤떨어진다

1.8

사이트가 인터넷 익스플로

러 전용이라면, 맥에 설치

된 인터넷 익스플로러에서

는 어떨까? 전혀 좋아 보이

지 않는다.

1.9

윈도우에 설치된 인터넷 익

스플로러 6에서 본 같은 사

이트의 모습. 겨우 제대로

보인다.

36

1.10

오페라를 인터넷 익스플로

러로 인식하도록 설정하면

윈도우용 오페라 7에서 작

동한다(오페라로 인식하도

록 설정하면 사이트는 작동

하지 않는다).

1.11

사이트 개편 후, 현재의

KPMG 사이트는 괜찮아

보이고 다양한 브라우저와

플랫폼에서도 제대로 돌아

간다. 인터넷 익스플로러

전용을 탈피해서 새로 작

업된 마크업이 이룬 성과

이다.

3701장 ㅣ 웹사이트의 99.9%는 시대에 뒤떨어진다

잠재 고객의 1/4 정도를 포기하는 기업의 비즈니스 모델을 이해하려고 노력하지 않겠다. 이

런 근시안적인 접근으로 인해 잃게 되는 수많은 고객의 수는 합리적인 사업가들이나 공공을 위

해 봉사하는 비영리 기관의 마음을 일깨워 줄 것이다. NUA Internet Survey(www.nua.

ie/surveys)가 조사한 통계에 따르면, 2002년 9월 현재 6억 5060만이 넘는 사람들이 인터

넷을 사용하고 있다. 얼마나 엄청난 숫자인지 생각해 보라.

사이트 방문자의 25%를 잃고 싶지는 않을 것이다. 인터넷 익스플로러가 언제까지 웹(혹은 데

스크탑 브라우저 전체)에서 우위를 차지하게 될지 장담할 수 없기 때문에, ‘인터넷 익스플로러

전용’이라는 접근은 조금은 이해할 수 없는 부분이다. 그러한 근거 중에 하나로, 지금 이 순간

에도 파이어폭스가 지속적으로 인터넷 익스플로러의 시장을 잠식해 가고 있다. 또 다른 근거로

는, 휴대전화나 무선기기로 인터넷을 사용하고 있는 사람들이 늘고 있다는 것이다. 미국에서는

데스크탑을 통한 인터넷 접속이 휴대전화를 비롯한 무선기기로 접속하는 것보다 훨씬 많지만,

일본의 경우는 완전히 정반대이다. 그렇게 변화해가는 사람들이 늘어가면서 트렌드는 서서히

휴대전화를 비롯한 무선기기로 이동하고 있다(www.gotomobile.com). 유비쿼터스가 점차

도입되고, 새로운 시장을 형성해나가고 있는 시점에서, 여러 브라우저에 따라 다르게 작업한다

는 식의 개념은 시간이 지날수록 점점 퇴보하고 있는 듯하다.

이 책에서 보여지겠지만, 웹표준에 맞춰 작업하는 것은 모든 브라우저와 기기에 맞게 디자인

하는 것을 마치 하나의 디자인에 맞추어 작업하는 것처럼 쉽고 빠른 작업이 되도록 해줄 것이다.

하위 호환 버전 작업에 투입되는 비용의 증가와 하나의 브라우저에만 맞춰 작업하는 근시안적

인 방법 사이에서 웹표준은 올바른 웹 개발을 위한 방법을 제공한다.

비용 낭비를 초래하는 버전별 개발 방법이나 의도적으로 하나의 브라우저나 플랫폼을 지원하는

방법들 모두, 오늘날의 웹사이트가 미래의 브라우저나 데스크탑을 넘어 지속적으로 변하고 있

는 세상에 도움이 되지는 않을 것이다. 이러한 방법들이 계속된다면, 비용과 복잡함은 지속적

으로 증가해서 결국에는 거대한 기업들이나 웹 사이트를 만들어 사용하는 것이 가능해질 것이다.

비호환 브라우저 환경에서도 동등한 경험을 할 수 있게 하고, 데스크탑에서 보는 것과 같이 인

쇄를 위한 화면도 똑같이 보이게 하려는 우리의 수고로 인해, 다양하고 접근성이 높은 매체로

서의 진정한 가능성을 볼 수 있는 안목을 잃게 되었다.

인터넷 붐이 일어났던 시기에 디자이너와 개발자들이 앞다투어 비표준, 그리고 특정 브라우저

에 맞춘 사이트 제작 방법을 익혀 작업을 해오면서 안목을 잃게 되었고, 그로 인해 현재 우리는

사이트의 구식화라는 문제에 직면해 있다.

38

하지만, 웹 개발의 구식화는 여러분이 이 책을 읽는 동안 차츰 사라지고 있고, 수많은 사이트가

그런 오래된 방법에서 벗어나고 있다. 만일 웹사이트를 가지고 있고 직접 관리하고 디자인 한

다면, 지금이 바로 실천에 옮길 시점이다.

삼천포로빠지기

1997년 초, 넷스케이프 브라우저에서 자바스크립트를 사용하고, 마이크로소프트 인터넷 익스플

로러에서 Jscript를 쓰는 것은 당연한 일이었다. 자바스크립트와 ActiveX 컨트롤을 이용해 각

브라우저로 코드를 보내는 것 또한 당연한 일이었다. 이것이 3.0 버전을 위해 우리가 한 것들이다.

이러한 방식은 오페라 같은 ‘비주류’ 브라우저에겐 좋은 점이 없었고, 맥킨토시에 설치된 인터

넷 익스플로러 사용자에게도 제 기능을 보여주지 못했지만, ‘대부분의’ 웹 사용자들에게는 잘

작동했고, 빠르게 업계의 표준으로 자리 잡아갔다. 단순히 보기만 하는 예쁜 웹 페이지보다 좀

더 역동적인 웹 페이지를 만들려면 이러한 절차를 따를 수밖에 없었다.

1997년 후반에 넷스케이프와 마이크로소프트에서 DHTML 기능이 강화된 4.0 버전을 발표

하였는데, 두 버전은 서로 호환이 되지 않는다. 또한 각 브라우저들의 이전 버전(넷스케이프 4

에서 작동되지만, 넷스케이프 3 버전에서는 작동하지 않음)들과도 호환이 되지 않았으며, 각사

의 고유한 언어와 속성을 고수하는 대신 HTML 같은 기본적인 스펙을 지원하던 ‘비주류’ 브라

우저들과도 전혀 호환되지 않았다.

이런 독자적인 방법들을 만들 필요가 있었을까? 넷스케이프와 마이크로소프트는 그럴 필요가

있다고 생각을 했고, 많은 디자이너와 개발자들도 이에 동의했다. 이런 생각에 동의하지 않았

던 사람들도 어쩔 수 없이 ‘전문적인’ 사이트를 만들기 위해서는 피할 수 없는 선택이었다.

어떤코드들이있을까?한번세어보자

넷스케이프 4를 위한 DHTML이 있었다. 인터넷 익스플로러 4를 위한 호환이 되지 않는

DHTML이 있었는데, 오직 윈도우에서만 작동하였다. 넷스케이프 3을 위한 자바스크립트와 인

터넷 익스플로러 3을 위한 스크립트가 있었다. 비주류 브라우저들과 그 이전 시대의 브라우저를

위한 추가적인 스크립트가 있었을 수도 있고, 없었을 수도 있다. 간단히 말하자면, 아주 단순한

웹페이지라도 다양한 스킬보다 그것을 제대로 사용할 수 있게 하는 확실한 도구가 필요하다.

일부 개발자들은 두 가지 버전(인터넷 익스플로러 4와 넷스케이프 4)으로만 페이지를 만들어,

보다 많은 사용자의 방문을 그들 스스로 제한하였고, 4.0 버전의 브라우저들로 바꾸도록 강요

3901장 ㅣ 웹사이트의 99.9%는 시대에 뒤떨어진다

하였다. 개발 예산이 적은 곳에서는 오직 하나의 브라우저에만 맞춰 비용을 사용하고, 결과

적으로 투자한 것에 비해 얻은 것은 없는 꼴이 되어 버렸다.

양사의 4.0 버전 브라우저가 시장에 출시된 이후, 발족된 ‘웹표준화 프로젝트’에 따르면, 하

나의 웹사이트 개발에서 4가지 이상의 버전을 만드는 것은 최소 25% 이상의 비용이 추가되

는 것을 의미하며, 이는 전적으로 클라이언트가 부담해야 하는 비용이 되어 버린다고 했다.

일부 개발자들은 이러한 평가에 그냥 어깨를 으쓱해 보일 뿐이다. 웹이 한창 뜨고 있었고, 클

라이언트는 원하는 대로 돈을 지불하던 시절이었기 때문에, 대규모의 웹 에이전시에서는 다

양한 코드와 마크업 작업으로 인한 비용에 대해서는 고민할 필요가 없었다. 하지만 거품이

빠져버린 후, 웹을 위한 예산은 줄어들거나 동결되었고, 에이전시들은 규모를 줄이거나 서로

합병하게 되었다. 그러면서 더 이상 코드의 다양화를 위한 비용을 고려할 수 없게 되었다.

웹 산업이 감축과 폐업으로 흔들리면서, W3C에서 만든 DOM을 지원하는 차세대 브라우저

의 시대가 도래했다. 이는 어떤 의미였을까? 그것은 다양한 버전들의 시대는 가고 새로운 표

준 기반 디자인과 개발의 시대가 도래했다는 것을 의미했다. 이를 산업에서는 어떻게 받아들

였을까? 지속적으로 인터넷 익스플로러를 위해 코드를 나누어 작업을 하거나, 매크로미디어

(현재 어도비)의 플래시로 전환하게 되었다. 비전 있는 사람들로 넘쳐나는 사업분야이지만,

웹은 묘하게도 근시안적인 산업이다.

나쁜마크업에좋은일이생길때

컴퓨터 프로그래밍을 처음 배울 때, ‘재료가 나쁘면 결과물도 나쁘다’라는 문구를 터득하게

된다. C나 자바 같은 언어들을 배울 때 올바른 코딩 방법은 필수적으로 요구되는 사항이다.

마찬가지로, 그래픽 디자이너가 처음으로 배우게 되는 것은 품질 좋은 소스가 우수한 결과물

을 결정짓는다는 것이다. 고해상도, 고화질의 사진으로 작업을 하면 만족스러운 인쇄물이나

웹 그래픽을 얻어내게 될 것이다. 선명하지 않은 작은 스냅샷 이미지나 저해상도의 웹이미지

로 작업하게 되면, 최종 결과물도 보기에 좋지 않을 것이다. 고화질의 EPS 파일을 적절하게

최적화시켜 웹페이지의 로고로 만들 수 있지만, 저해상도의 GIF 이미지로 고화질의 웹이나

인쇄물, TV를 위한 이미지로 사용할 수 없다. 재료가 나쁘면 결과도 나쁘게 나올 수밖에 없

는 것이다.

하지만, 전통적인 주류 브라우저들은 이러한 방식과는 다르다. 잘못된 점에 너무나도 관대

한 이런 브라우저들은 깨진 마크업이나 잘못된 자바스크립트 소스파일 링크를 완전히 무시하

40

고, 거의 대부분을 제대로 작성된 것처럼 보여준다. 이러한 관대함이 아무도 모르는 사이에 화

면설계를 하는 디자이너나 개발자들에게 나쁜 습관을 심어주었다. 이와 함께, 미들웨어나 웹서

버 개발자들이 XHTML, CSS, 자바스크립트와 같은 기술들을 별로 중요하지 않은 기술로 여

기도록 만들었다.

툴을 중요하게 생각하지 않는 사람은 제대로 사용하지도 않는다. 다음과 같은 상황을 생각해보

자. 치열한 시장에서 많은 비용을 들여 전자상거래 사이트를 운영하고 있는 한 회사의 사이트

에서 발췌한 일명, ‘상처뿐인 영광의 코드’이다.

<td width=“100%”><ont face=“verdana,helvetica,arial” size=“+1”color=“#CCCC66”><span class=“header”><b>Join now!</b></span></ont></td>

무의미한 <ont> 태그는, W3C에서 사용을 권장하지 않는 <font> 태그를 그나마 철자를 잘

못 써서 사용한 것이다. 그리고 이 태그는 사이트에서 수천 번 넘게 반복되어 쓰여졌다. 참으

로 효율적인 마크업 툴이 아닐 수 없다. 이 에러는 그렇다 치고, 이 마크업은 아마도 많이 익숙

할 것이다. 어쩌면 여러분의 사이트에서도 비슷한 마크업이 있을지도 모르겠다. 이 웹 페이지

를 잘 살펴보면 실제로 필요한 부분은 다음과 같은 정도이다.

<h3>Join now!</h3>

스타일 시트에서 제대로 된 규칙으로 결합되고, 간결하면서 의미 있는 마크업은 서버의 부하를

줄이고 방문자의 대역폭을 늘리며, XML 기반의 마크업으로 만든 좀 더 유연한 사이트로 쉽게

변경할 수 있도록, 이전의 비표준이면서 유효하지 않던 마크업들이 했던 것을 더 정확하게 해

줄 것이다. 또한 이 사이트는 다음과 같은 잘못된 자바스크립트 링크도 포함하고 있다.

<script language=JavaScript1.1src=“http://foo.com/Params.richmedia=yes&etc”></script>

다른 많은 문제들 중에서도, 특히 인용부호를 안 붙인 language 속성에 소스 태그가 바로 붙

어있다. 즉 브라우저는 말도 안 되는 ‘JavaScript1.1src’라는 스크립트 언어를 사용하려고

하게 되는 것이다.

아마도 이 사이트는 합리적인 측정 방법으로 개발자에게 에러를 알려주고 즉시 고치게 하는데

는 실패한 것 같다. 최근까지도 이 사이트의 자바스크립트는 주요 브라우저에서 잘 작동했고,

계속해서 잘못된 사이트를 문제없이 잘 작동되는 것처럼 보이게 하는 이런 악순환은 이어지고

4101장 ㅣ 웹사이트의 99.9%는 시대에 뒤떨어진다

있다. 숙련된 개발자가 프론트 개발(화면설계)을 신경 쓸 가치가 없는 것으로 보는 것도 어쩌면

당연한 일이 아닐 수 없다.

터무니없는마크업은사이트의장기적인미래에위험요소가된다

하지만, 새로 나오고 있는 브라우저는 웹표준과 연동되어, 잘못된 마크업에 더 이상 관대하지

않으며, 디자이너와 개발자들이 작업하기에 점점 엄격해지고 있고, 이 점이 높이 평가받고 있다.

‘재료가 나쁘면 결과물도 나쁘다’라는 원리는 브라우저 시장에서 확고하게 자리잡아가고 있고,

웹 개발을 하는 사람들에게 웹표준에 대한 지식이 꼭 필요하다는 인식을 심어주고 있다.

수많은 브라우저와 플랫폼과 모바일 기기까지 포함해서 모두 작동되는 더 나은 웹사이트를 만

들 수 있고, ‘내재된 진부화bu�lt-�n obsolescence’의 문제와 접근성 문제를 해결할 수 있으며, 동시에 더

강력하고 접근성 높으며 합리적인 발전된 웹으로의 길을 닦을 수 있다.

내재된 진부화를 해결하는 방법은 우리가 공통적으로 ‘웹표준’이라 얘기되는 기술의 핵심에서

찾을 수 있다. 웹표준으로 디자인하고 제작하는 방법을 배움으로써, 앞으로 제작하는 모든 웹

사이트의 상위 호환문제를 보장할 수 있다.

‘한번 만들어서 어디든 사용한다’라는 웹표준의 약속은 단순히 희망적인 생각을 넘어서, 이 책

에서 다루는 방식을 통해 현재 달성되어 가고 있다. 오늘날의 주요 브라우저들이 이런 표준과

방법들을 이제서야 지원하기 시작했지만, 아직 상당수의 디자이너나 개발자들은 이 사실을 모

르고 있고, 새롭게 만들어지는 많은 사이트들이 아직도 비표준 마크업과 코드로 만들어지고 있

다. 이 책을 통해 조금이나마 변화될 수 있기를 바란다.

해결책

디자이너와 개발자들이 주요 브라우저 제작사에 대항한 긴 싸움 뒤에, 하나의 브라우저가 아니

라 모든 브라우저에서 웹사이트의 외관과 동작을 함께 커버하는 기술을 사용할 수 있게 되었다.

W3C의 맴버들과 다른 표준 조직이 함께 만들고, 2000년 이후에 만들어진 모든 브라우저에서

지원되는 CSS, XHTML, ECMAScript(자바스크립트의 표준 버전), 그리고 DOM은 디자

이너에게 다음과 같은 일들을 할 수 있게 해준다.

사용자의 요구에 맞게 표현을 변경할 수 있도록 하여, 데스크탑 브라우저에서 레이아

웃, 배치, 타이포그라피를 좀 더 정확하게 컨트롤 할 수 있게 해준다.

여러 브라우저나 플랫폼에서 작동되는 섬세한 동작을 개발할 수 있게 해준다.

•

•

42

디자인이나 기능의 희생 없이 접근성 규칙과 가이드라인을 적용할 수 있게 해준다.

며칠, 혹은 몇 주 걸리던 디자인 개편 작업을 몇 시간 안에 할 수 있고, 비용을 절감하

고, 쓸데없는 작업을 없앨 수 있다.

여러 버전을 만드는데 들어가는 불필요한 노력과 비용 없이 다양한 브라우저를 지원

할 수 있으며, 코드를 나누어야 하는 상황이 거의 없거나 전혀 없다.

청소년들이나 경영자들이 특히 관심을 가지고 있는 웹 접속이 가능한 휴대폰에서부터

무선기기나 장애인들이 사용하는 점자리더기, 스크린리더기 같이 새롭게 등장하는 기

기들에서도 불필요한 노력과 다양한 버전을 만드는 비용 없이 지원가능 하게 해준다.

‘프린트용’ 버전을 만들거나 이러한 버전들을 만들어주는 고가의 시스템에 의존하지

않고, 모든 웹페이지의 정교한 프린트용 버전을 만들 수 있다.

구조와 동작에서 스타일을 분리하여 엄격한 문서 구조에 기반을 둔 창의적인 레이아

웃을 만들고 개선된 작업환경으로 웹 문서의 재구성을 쉽게 해준다.

과거의 웹 언어인 HTML 기반에서 더 강력한 XML 기반의 마크업으로 전환이 가능

하다.

최근 표준을 지원하는 브라우저에 맞추어 만들어진 사이트가 정확하게 똑같이 보이는

것은 아니지만, 구식 브라우저에서도 만족스러운 정도의 성능을 보일 수 있게 해준다.

현재의 사이트가 미래의 브라우저나 기기에서도 정상적으로 작동하게 해준다. 이것은

‘상위 호환성’의 약속이다.

그리고 더 많은 것을 이 책에서 소개할 것이다.

표준이 이러한 목표들을 어떻게 이루게 해주는가를 배우기 전에, 수정되어야 할 오래된 방법들

을 찾아보고, 이 오래된 기술들이 어떻게 진부화의 악순환을 만들어 가는지 알아봐야 한다. 2

장에서 이 모든 것을 볼 수 있다.

•

•

•

•

•

•

•

•

•

•