2007/03/23 23:09

출처 :MSDN Magazine

 

사용자 삽입 이미지
Get the sample code for this article.


사용자 삽입 이미지
목차

솔직히 말하면 필자가 웹 표준을 항상 중요하게 생각한 것은 아닙니다. 여러분들과 마찬가지로 필자 역시 웹 브라우저가 처음 출시된 시점부터 웹 페이지를 만들기 시작했습니다. 당시에는 모든 HTML 단락 태그를 닫게 되면 속도가 느려지고 소중한 28K 대역폭을 쓸데 없는데 사용하는 격이라고 생각했기 때문에 단락 태그를 닫지 않았습니다. 브라우저에서 이것이 문제가 되지 않는 한 필자는 이 방식을 고수했습니다.

그러나 이후 미래의 웹 및 웹 기반 소프트웨어 전반에 대해 웹 표준이 갖는 중요성을 인식하기 시작했습니다. 물론 웹 표준은 HTML 태그를 닫는 것 이상의 많은 내용을 다룹니다. 웹 표준은 소프트웨어 구성 요소가 미래의 컨텍스트에서 얼마나 잘 동작할지 결정하는 중요한 요소입니다.

웹 응용 프로그램은 XHTML, CSS(Cascading Style Sheets), XML 등에 대해 W3C 표준을 따르는 것 외에도, 검색 엔진에 친화적이어야 하고 액세스가 가능해야 하고 사람이 읽을 수 있는 URL을 가져야 하며 검색과 사용을 쉽게 해주는 다른 좋은 방법들도 도입해야 합니다. 웹 표준에서는 또한 이후 유지 관리가 쉽도록 웹 사이트 내부 코드 구조에 신중을 기할 것을 요구합니다. 이번 달 기사에서는 모든 사람들, 그 중에서도 특히 서버 컨트롤을 만드는 사람들이 웹 표준을 따라야 하는 이유에 대해 설명하겠습니다.


웹 표준 채택

웹 표준은 크게 네 가지 범주, 즉 코드 유효성, 사이트 탐색, 액세스 가능성, 콘텐츠와 디자인의 분리에 영향을 미칩니다(그림 1참조). 이러한 범주에서 큰 부분들을 처리하면 표준 호환 코드를 작성하는 작업은 상당 부분 이루어진 것입니다. 각 범주에 대해 차례로 살펴보겠습니다.

코드 유효성  컨트롤에서 유효한 XHTML 코드를 내보내는 것이 중요합니다. 즉, 무엇보다 코드 내 모든 태그가 닫혀 있어야 하고 올바른 DocType을 선택해야 하고 이미지에 대한 alt 태그를 만들어야 합니다. 최적의 결과를 위해서는 유효성 검사 서비스를 통해 모든 웹 페이지의 출력을 실행함으로써 표준 부합을 확인해야 합니다. W3C는validator.w3.org(XHTML)와jigsaw.w3.org/css-validator(CSS)의 두 가지 유용한 유효성 검사 서비스를 제공합니다. 이러한 서비스는 구축 프로세스의 일부로 자동화할 수도 있고 코드를 배포하기 전에 수동으로 수행할 수도 있습니다.

대부분의 브라우저는 점차 웹 표준을 따르도록 발전하고 있습니다. 2006년 말에 출시된 Internet Explorer®7.0과 Mozilla Firefox 2.0도 마찬가지입니다. 따라서 이러한 브라우저가 요구하는 웹 표준을 따르면 여러분의 코드가 최신 브라우저에서 올바르게 렌더링된다는 점을 더 확신할 수 있습니다.

사이트 탐색  많은 콘텐츠 관리 시스템은 콘텐츠를 내부화하고, 한 페이지가 나머지 페이지와 어떻게 연관되어 있는지 사용자에게 아무런 단서도 제공하지 않는 페이지 URL을 제공합니다. 게다가 동적으로 생성된 콘텐츠는 대개 생소한 URL을 생성하는데, 이는 고유 식별자와 같은 정보가 쿼리 문자열을 통해 URL에 전달되는 경우가 많기 때문입니다. 이러한 문제를 해결하려면 URL을 영역별로 구성하고 사용자에게 현재 위치를 알려 주어야 합니다. URL 재작성을 사용하면 동적으로 생성한 콘텐츠의 URL을 친숙하게 만들 수 있습니다. URL 재작성에서는 HTTP 요청이 처리될 때 HTTP 모듈이 생소한 URL을 친숙한 URL로 매핑합니다. URL 재작성은 Microsoft®.NET Framework에서 지원됩니다. 또한 친숙한 URL은 사용자가 콘텐츠를 더 쉽게 찾을 수 있게 해주며, 일부 검색 엔진에서는 친숙한 URL을 가진 페이지의 순위를 더 높게 지정합니다.

액세스 가능성  신체가 불편한 사용자도 액세스할 수 있도록 코드를 작성하거나 렌더링하는 것은 휠체어가 다닐 수 있는 문을 만드는 것만큼이나 기업에게 중요한 일입니다. 웹 사이트 방문자 중에는 신체가 불편한 사용자도 있을 수 있기 때문입니다. 예를 들어 전체 남성 중 5 ~ 10%는 색맹입니다. 다행히 웹 사이트의 액세스 기능을 강화하는 몇 가지 쉬운 방법이 있습니다. 테이블을 사용하면 시력이 약한 사용자에게 화면을 읽어 주는 화면 판독기에서 테이블 레이아웃으로 인한 혼동이 발생하므로 테이블은 사용하지 않는 것이 좋습니다. 폼에 대한 액세스 기능도 중요합니다. 예를 들어 하나의 열에는 레이블이, 또 다른 열에는 HTML 폼 요소가 포함된 2열 테이블을 만드는 것은 잘못된 방법입니다. 올바른 방법은 레이블이 설명하는 폼 요소의 ID를 나타내는 "for" 특성을 사용하는 것입니다(그림 2참조).

액세스 가능성 향상을 위한 다른 방법으로는 링크 및 단추와 같은 중요한 항목은 쉽게 구별할 수 있는 색상을 사용하고, 글꼴 크기를 확대할 수 있도록 지원하되 글꼴을 확대해도 페이지가 올바른 형태를 유지하도록 하고, alt 특성을 사용하여 이미지를 설명하는 방법 등이 있습니다. alt 사용으로 얻는 부수적인 효과는 설명 내용이 검색 엔진에 인덱싱될 수 있다는 점입니다.

마지막으로 웹 사이트를 보다 장치 독립적으로 디자인하면 더 많은 사람들이 이 사이트에 액세스할 수 있습니다. 사용자는 휴대폰, PDA, Smartphone 등의 장치를 통해 웹에 액세스합니다. 사이트가 모바일 장치를 지원하지 않기 때문에 필요한 데이터에 액세스할 수 없다면 모바일 장치 사용자에게는 실망스러운 일입니다.

콘텐츠와 디자인의 분리  웹 페이지는 XML이 오늘날 광범위한 표준으로 자리잡기 오래 전부터 사용되었습니다. XML에서는 HTML과 달리 스타일 정보와 콘텐츠를 혼합할 수 없기 때문에 XML을 사용하면 콘텐츠와 디자인이 명확히 구분됩니다.

이렇게 콘텐츠와 디자인이 분리되면 많은 이점을 얻을 수 있습니다. CSS 스타일시트에 모든 레이아웃과 스타일 정보를 저장하면 여러 장치를 지원할 수 있으며 내보낸 XHTML의 크기도 더 작아집니다. XHTML은 더욱 명확하고 체계적으로 구성되므로 편집과 디버깅이 훨씬 수월합니다. XHTML이 명확할수록 화면 판독기가 웹 페이지의 콘텐츠를 더 쉽게 읽을 수 있고 검색 엔진이 페이지를 더 정확하게 인덱싱할 수 있습니다.


XHTML의 유형

지금까지 웹 표준의 중요성에 대해 설명했으니 이제 이러한 표준을 구현하는 웹 페이지를 만들어 보겠습니다. 첫 번째 단계는 올바른 문서 유형을 선택하는 것입니다. 문서 유형 정의(DOCTYPE)는 사용 중인 XHTML 유형을 브라우저의 유효성 검사기에 알려 줍니다. XHTML 1.0에는 Strict, Transitional, Frameset의 세 가지 유형이 있습니다. XHTML 1.1은 디자인과 관련된 HTML 요소의 사용을 제한하는 한 가지 유형만 제공합니다. 이러한 유형은그림 3에 나와 있습니다.

XHTML 1.1 또는 HTML 1.0 Strict DocType을 사용하는 것이 좋은데, 이렇게 하면 모든 디자인 관련 요소를 XHTML에서 스타일 시트로 옮겨 넣을 수 있기 때문입니다. 그러나 여전히 XHTML 테이블을 사용하여 콘텐츠를 배치할 수 있으므로 이러한 유형을 따른다고 해서 웹 페이지가 웹 표준에 호환된다는 점을 완전히 보장할 수는 없습니다. 즉, 테이블을 사용한다는 이유만으로 유효성 검사가 실패하지는 않으므로 유효성 검사에만 전적으로 의존할 수는 없습니다.

코드에서 모든 디자인 관련 요소를 완전히 제거할 수 없는 경우에는 Transitional DocType을 사용하여 페이지가 웹 표준에 완벽하게 호환되지는 않으며 나중에 리팩터링이 필요하다는 점을 알려야 합니다.

프레임은 XHTML 1.0 사양에서는 지원되지만 XHTML 1.1에서는 제거되었습니다. 앞으로 iframe 및 object는 XFrame 사양으로 대체될 가능성이 높습니다. 일반적으로 프레임은 사용성 측면에서 문제를 일으키므로 넣지 않는 것이 좋습니다. 프레임이 있는 웹 페이지에서 뒤로 단추를 클릭해 본 적이 있다면 무슨 말인지 아실 것입니다.


웹 표준 플랫폼으로서의 ASP.NET 2.0

ASP.NET 1.1에는 잘 알려진 몇 가지 단점이 있었는데, 기본 제공되는 컨트롤에서 생성한 코드가 유효성 검사를 통과하지 못한다는 문제도 여기에 포함됩니다. 이는 주로 ASP.NET 1.1에서 ViewState가 처리되는 방식으로 인한 문제입니다. 즉, 다음과 같이 블록 표시 내에 포함되지 않은 숨겨진 입력 태그를 사용하는 것입니다.

<input type="hidden" name="__VIEWSTATE" value="dDwtMTU1NzQzNDgy..." />

이러한 부분이 다른 구문상의 문제와 결합되어 ASP.NET 1.1은 비호환성에 대한 불명예를 얻게 되었습니다.

ASP.NET 2.0에서는 많은 웹 표준 문제가 해결되었습니다. 예를 들어 ASP.NET 2.0으로 생성한 웹 페이지의 소스를 살펴보면 다음과 같이 호환성을 위해 ViewState가 이제 div 태그에 래핑되어 있음을 볼 수 있습니다.

<div> <input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value dDwtMTU1NzQzNDgy..." /> </div>

Microsoft는 ASP.NET 2.0의 목표 중 하나는 웹 표준에 더 부합하는 것임을 공개적으로 밝혔으며, 실제로 ASP.NET 2.0에서는 웹 표준과 호환되는 웹 사이트 및 컨트롤을 만들 수 있습니다. 표준 호환 웹 사이트 구축에 대한 좋은 리소스로는 Stephen Walther가 쓴 MSDN®기사 "웹 표준을 이용한 ASP.NET 2.0 웹 사이트 구축"이 있습니다. 78 페이지 분량의 이 기사는 웹 표준에 따라 웹 사이트를 구축하는 방법에 대해 상세히 설명해 줍니다.


CSS Control Adapters

ASP.NET 2.0은 호환성 측면에서 큰 발전을 이루었지만 아직도 몇 가지 문제가 남아 있습니다. 예를 들어 일부 ASP.NET 2.0 컨트롤은 HTML 테이블을 사용하면 안 되는 경우에 이러한 테이블을 렌더링하는 문제가 있습니다. 몇몇 경우 GridView 또는 DataList와 같은 컨트롤은 테이블 내에 출력을 렌더링해야 하는데, 이는 컨트롤의 특성상 테이블 형식의 데이터를 사용해야 하기 때문입니다. 메뉴 컨트롤과 같은 다른 컨트롤은 테이블로 렌더링하면 안 됩니다.그림 4는 메뉴 컨트롤의 메뉴 항목에 대해 렌더링되는 HTML 테이블 부분을 보여 줍니다. 이 코드는 테이블, 그리고 테이블의 여러 스타일 특성으로 인해 최적의 코드는 되지 못합니다.

테이블 내의 데이터가 대체로 테이블 형식이 아님에도 불구하고 HTML이 테이블로 렌더링되므로 이 코드는 웹 표준과 호한된다고 할 수 없습니다. HTML 테이블을 사용하여 메뉴 항목 목록을 렌더링하는 것은 대개 문자열 배열 또는 컬렉션을 사용하는 작업에서 DataSet을 사용하는 것과 같습니다. 이와 같은 계층적인 데이터를 렌더링하는 경우 널리 사용되는 방법은 순서 없는 HTML 목록을 사용하는 방법인데, 메뉴가 사실 일련의 중첩된 목록이라는 점을 생각해 보면 이해할 수 있을 것입니다.

다행히 Microsoft는 ASP.NET 2.0 CSS Friendly Control Adapters 1.0 도구 키트를 배포하고 있습니다. 이 도구 키트를 사용하면 컨트롤이 렌더링될 때 컨트롤의 기본 출력을 다시 정의하여 HTML을 제거, 대체 또는 추가할 수 있습니다. 여러 베타 버전을 거쳐 출시된 이 도구 키트는asp.net/CSSAdapters/Default.aspx에서 다운로드할 수 있습니다.

CSS Control Adapters를 사용하면 컨트롤의 소스 코드를 수정하지 않고도 ASP.NET 2.0에서 제공되는 컨트롤, 타사 컨트롤, 또는 사용자 지정 컨트롤 등의 모든 컨트롤 출력을 다시 정의할 수 있습니다. 개발자는 사용하는 모든 컨트롤에 대한 소스 코드를 갖고 있지도 않을뿐더러, 설령 갖고 있다 해도 기능을 다시 정의하는 데 있어 코드를 수정하는 방법이 항상 최선은 아닙니다. 특히 렌더링된 HTML만 수정하면 되는 경우라면 더욱 그렇습니다.

컨트롤 어댑터의 기반 아키텍처는 어댑터 또는 래퍼 디자인 패턴을 바탕으로 구축됩니다. 추상 클래스 ControlAdapter는 모든 어댑터의 기본 기능을 정의합니다. WebControlAdapter 클래스는 ControlAdapter 기능을 상속하며 개별 HTML 태그를 렌더링하기 위한 메서드를 추가합니다. Menu Adapter와 같은 클래스는 WebControlAdapter에서 상속되어 컨트롤 고유의 기능을 제공합니다.그림 5는 클래스 어댑터에 대한 클래스 다이어그램을 보여 줍니다.

사용자 삽입 이미지

그림 5 ASP.NET 2.0 컨트롤 어댑터 클래스 (더 크게 보려면 이미지를 클릭하십시오.)

이 아키텍처는 쉽게 구현되며 특히 이미 어댑터가 개발되어 있는 컨트롤의 경우 더욱 간단합니다. 다행히 대부분의 ASP.NET 컨트롤에는 어댑터가 있습니다. 예에서 볼 수 있듯이 MenuAdapter 클래스는 기본 HTML 테이블 레이아웃을 순서 없는 목록으로 다시 정의하는 데 사용됩니다.

이 작업의 첫 단계는 브라우저 정의 파일을 만들거나 사용자 지정하는 것입니다. 이 파일은 ASP.NET 2.0 웹 사이트에 액세스하는 브라우저를 감지하는데 사용되며 해당 브라우저에 고유한 기능을 제공합니다. 이는 모바일 장치를 이용하여 사이트를 방문하는 사용자에게 맞춤화된 환경을 제공하는 좋은 방법입니다. 하지만 CSS Control Adapters를 사용할 경우 브라우저 정의 파일을 통해 호환되는 브라우저가 하나 이상의 어댑터를 사용해야 한다는 것을 알려야 합니다.

그림 6의 XML은 전체 브라우저 정의 파일을 보여 줍니다. 이 파일은 기술된 기준에 부합하는 모든 브라우저에 대해 모든 MenuControl 클래스를 MenuAdapter에 라우팅하도록 ASP.NET에 알려 줍니다. 기준은 JavaScript와 CSS를 지원하는 모든 W3C 호환 브라우저로 기술되어 있습니다. 이는 오늘날 사용되는 대부분의 브라우저와 일치합니다. 또한 브라우저 정의 파일은 기타 모든 종류의 사용자 환경 맞춤화에 사용할 수 있는 정보를 제공합니다.

CSS Control Adapter를 구현하는 마지막 단계는 어댑터 클래스에서 파생된 클래스를 만드는 것입니다.그림 7은 ASP.NET 2.0 Control Adapter에 기본 제공되는 예제 메뉴 어댑터를 보여 줍니다. 이 클래스는 MenuAdapter 클래스에서 파생되며 컨트롤을 구성하는 모든 항목을 열거하고 적절한 태그로 HTML을 다시 정의합니다. 그림에는 BuildItems 메서드의 순서 없는 목록 시작을 렌더링하는 클래스 부분이 나와 있습니다.

그림 8의 HTML 소스를 보면 메뉴 컨트롤의 테이블이 순서 없는 목록으로 대체되어 있는 것을 알 수 있습니다. HTML 출력에서 주목할 만한 부분은 이러한 순서 없는 목록뿐이 아닙니다. 스타일 및 스크립트 코드로 인한 혼잡함이 없기 때문에 출력이 확실히 더 깔끔합니다. 이제 모든 위치 지정 및 스타일이 메뉴 CSS 파일에 들어가 있으며 메뉴는 웹 표준과 호환되는 것으로 간주됩니다.

CSS Control Adapter에는 Tree 보기, Login, CreateUserWizard 등 테이블을 렌더링하지 않아야 할 때 렌더링하는 것으로 악명 높은 많은 컨트롤을 위한 어댑터가 제공됩니다. 이러한 샘플을 기존 프로젝트에 통합하고 원하는 방식대로 간단히 사용자 지정할 수 있습니다.


마스터 페이지 및 테마

이제 웹 표준에 따르는 컨트롤을 렌더링할 수 있는 도구가 있으므로 전체 웹 사이트를 표준과 호환되도록 만들 수 있습니다. 마스터 페이지와 테마의 결합은 웹 사이트에 강력하고 유연한 인프라를 제공합니다.

웹 개발자는 마스터 페이지를 사용하면 유연한 웹 페이지 템플릿을 만들 수 있습니다. 여러 웹 페이지에 걸쳐 재사용이 가능한 구성 요소를 만들 수 있는 강력한 도구인 마스터 페이지는 사이트 전체를 웹 표준과 호환되도록 하는 방법을 제공합니다. XHTML 1.1 DocType을 사용하는 마스터 페이지를 만드는 것은 사이트에 포함된 모든 웹 페이지가 웹 표준과 호환되도록 하는 좋은 방법입니다. 또한 마스터 페이지를 사용하면 XHTML 1.0 Transitional에서 XHTML 1.0 Strict로 사이트를 마이그레이션하는 등의 모든 DocType 변경 작업을 한 곳에서 편리하게 수행할 수 있습니다.

ASP.NET 2.0 테마를 사용하면 동일한 콘텐츠에 대해 여러 가지 디자인을 만들어 액세스 가능성을 강화할 수 있습니다. 예를 들어 테마를 적용하면 글꼴이나 이미지 크기를 확대할 수 있으므로 시력이 약한 사용자를 위한 액세스 가능성이 향상됩니다. 마스터 페이지 내에 테마 전환 기능을 배치해 두면 사용자가 각자의 필요에 따라 가장 적절한 방식으로 웹 사이트를 볼 수 있습니다.

사용자가 테마를 전환할 수 있도록 하는 유용한 기법 중 필자가 발견한 한 가지는 Page 클래스에서 파생된 클래스를 정의하는 것입니다. 테마 전환 기능은 ASP.NET 페이지 수명 주기의 매우 초기 단계인 OnPreInit 메서드에서만 사용할 수 있습니다.그림 9의 클래스는 사용자가 선택한 테마를 캡처하고 이를 다시 정의된 메서드에 적용하는 방법을 보여 줍니다.

이 클래스는 미리 정의된 이름을 가진 요청 폼 변수를 찾아 그 값을 theme 클래스에 전달합니다. 이 클래스를 구현하는 모든 웹 페이지는 다양한 테마를 구현하는 데 필요한 인프라를 제공합니다. 이는 사이트의 모든 페이지에 간단히 테마 기능을 추가할 수 있는 방법입니다.


건의 사항

이번 기사에서는 웹 표준이 중요한 이유를 설명하고 웹 표준과 호환되는 웹 사이트를 만드는 몇 가지 기술을 살펴보았습니다. 이러한 웹 표준을 따르기가 쉽지 않은 경우가 많기 때문에 웹 표준을 도입하는 것은 어려운 작업일 수 있습니다. 그러나 이렇게 하면 현재 구축하는 컨트롤과 HTML은 앞으로 더 광범위한 사용자들이, 더 다양한 장치를 통해 액세스할 수 있습니다. 브라우저는 점차 이러한 표준을 따르는 추세이며 이러한 추세는 앞으로도 계속될 것입니다. 이제 웹 표준 호환 코드를 만드는 것은 개발자 커뮤니티의 몫입니다.


사용자 삽입 이미지
NEW:Explorethe sample code online!- or -코드 다운로드 위치:WebStandards2007_04.exe(318KB)

Ben Waldron은 고객에게 다양한 웹 기반 솔루션을 제공하는 대화형 콘텐츠 에이전시인 Pop Art, Inc의 최고 기술 책임자입니다. Waldron은 현재 포틀랜드 오레곤에 거주하고 있으며 문의 사항이나 의견이 있는 경우Ben.Waldron@PopArt.com

크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by mari