최근 케나다 아이폰 전화 플렌의 개선을 촉구하는 서명운동으로 스티브잡스에게 반대서명을 보낸일이 있었지만 아무튼 개개인의 서명과 함께 목소리를 높이는 좋은 시도 같습니다. 저는 미국인지라 어떻게 동참할수 있는건지는 모르겠지만 아무튼, 좋은 결과 있기를 바래봅니다.

요즘 웹표준이 부각되면서 사내에서 표준 세미나도 하시고 어렵게 어렵게 표준에 대해 노력을 힘쓰시는 분들에게 멋진 박수를 보내드리고 싶습니다. 쉽지 않은일 같지만 지금까지 변화되어 온걸 보면 그다지 먼 미래 같지는 않습니다. 화이팅을 외치면서, 이번에 웹표준 대회가 열린다고 해서 오랜만에 포스팅을 올립니다.

누군가가 시켜서 만드는 웹, 누구를 위해 만드는 것인지 알 수 없었던 웹은 이제 우리 자신과 보다 많은 사람들을 위해 개선되어 나가야 합니다. 더 많은 사람들이 더 좋은 방법을 이용하여 웹 사이트를 제작하고 사용할 수 있어야 하고, 시대가 이런 점을 이미 요구하기 시작했습니다. 이제는 가르치고 배우는 과정을 넘어 더 많은 사람이 보다 손 쉽게 이용할 수 있는 웹 표준으로 나아가야 할 것입니다. ‘규칙과 창조의 만남’이라는 슬로건처럼 웹 표준이라는 규칙을 지킴으로써 사이트가 얼마나 창조적으로 유연하게, 얼마나 더 편리해질 수 있는지를 많은 사람들이 알 수 있게 될 것입니다.

CSS Design Korea에서 주최하고, Hosting.kr, 에이콘출판사, 디지털미디어리서치가 후원하는 이번 대회는 2008년 5 월 1일부터 약 한달간 진행되며 2008년 6월 예정인 세번째 웹 표준의 날에 그 대미를 볼 수 있게 됩니다. 우리가 원하는, 모두를 위한 웹을 만들어가려는 이번 행사에 많은 분들의 참여를 기대합니다.

이번 웹표준 경진대회는 웹표준을 널리 알리고 웹표준의 멋진 프로젝트들이 여기저기 튀어나올수 있는 기회라고 생각됩니다. 많은 참여가 있으면 좋겠고 아마도 많은 학생들이 참여하지 않을까 하는 짐작을 해봅니다. 실무에서 뛰시는 분들은 시간내기가 쉽지 않겠죠? (를 뛰어넘어 밤새 제작하시는 분들이 머리속에 상상이 됩니다만…)

질문은 언제나처럼 CSS Design Korea 에 그리고 더 자세한 정보는 웹표준 경진대회 공식 사이트를 참고하시면 되겠습니다. 화이팅!

Translated with the permission of A List Apart Magazine and the author[s].
이하의 글은 A List Apart Magazine과 저자의 허락아래 번역되었습니다.

“Beyond DOCTYPE: Web Standards, Forward Compatibility, and IE8″

성장은 언제나 진통이 따른다. 브라우저도 개발자들이 특정 브라우저나 툴에 맞추게 되면 유저들이 진통을 격게된다. 새로운 브라우저 버전들이 공개되고 몇개의 버그들이나 스팩의 약간의 변화에 사이트들은 깨지게 되고 상사나 유저들이 실망하게 되는 것이다.

몇시간을 들여 왜 사이트가 깨졌는지 설명할수 있겠지만 아예 처음부터 깨지지 않는다면 더 낫지 않겠는가?

약간의 배경

CSS의 상당한 업글을 보여주었던 IE7 의 공개에 힘입어 IE팀은 완전히 새로운 렌더링을 탑제한 IE8(CSS2.1 을 최대한 따른) 개발을 시작했다. 그리고 Acid2 렌더링 테스트를 완벽하게 통과하는 기염을 토해내었다. 이것은 IE가 곧 generated content 와 data URL 을 지원한다는 것 뿐만이 아니라 hasLayout 이 완전히 사라진다는 것을 의미한다. Acid2 를 통과한 사파리나 iCab, Konqueror 그리고 오페라와 렌더링에 있어서 동격을 이룬다고 할수 있다. (Firefox3는 Acid2를 통과했지만 아직 출시되지 않았다.)

이번 새 엔진을 개발하는 동안 IE팀은 IE7 을 공개하면서 받은 여러 비판을 잊지 않았다. 몇몇 표준 구루들과 Microsoft의 몇몇 팬들까지도 IE7 이 버그나 CSS 지원에 있어서 충분하지 못했다고 생각했었고 상당수의 개발자들은 IE7 에서 깨지는 사이트들을 바라보며 불신에 속삭였다. 이에 Roger Johanssen은 자신의 블로그에 IE가 깨지는 3가지의 이유를 나열했지만 IE팀은 4번째 이유까지 발견했다. CSS 레이아웃을 가능케 하는 중요 부분인 Doctype 이 호환성을 지키기 위해서 너무나 부족함을 말이다.

DOCTYPE 스위치는 깨졌다

1998년, Todd Fahrner 가 개발자를 위한 모드와 그외의 사람들을 위한 2개의 랜더링 모드를 가능케 하도록 제안한다. 컨셉은 간단했다. 유저 에이전트(ex 브라우저) 가 표준에 적합한 DOCTYPE 을 포함한다면 제작자가 표준작업을 제대로 알고 한 문서라는 것을 가정하고 “표준”데로(W3C 박스모델을 사용하여) 렌더링을 하는 것이었다. 반대로 DOCTYPE이 명시되지 않았을 경우, “quirks” 쿽스 모드로 인식하여IE5.x/Windows 의 비표준 박스모델로 렌더링 되는 것이다.

이 컨셉은 2년후 IE5/Mac 브라우저에 처음 적용되어 타 브라우저들에 빠르게 퍼져갔다. 표준을 조금이라도 인식하는 개발자들은 이미 ‘validation’ 의 목적으로DOCTYPE 을 삽입하여 사용하고 있었으며 스펙에 따라 렌더링하는 데에는 그 이상을 따르지 않았다. 표준을 상관치 않는 개발자들에겐 DOCTYPE 을 상관치 혹은 몰랐기에 문서가 특별한 모드로 렌더링 되고 있었다.

불행하게도 다음의 두 중요한 사실이 DOCTYPE 이 표준 모드로의 스위치로써 지탱되지 못하도록 하였다.

1. A List Apart 이나 Web Standards Project 등을 통하여 표준을 자각한 개발자들은 완전한 DOCTYPE을 슬슬 삽입하게 되었고
2. IE6가 6년간 렌더링에 변동이 없었으므로 많은 개발자들이 자신들이 맞다고 생각 하게 되었다.

이 두 상황이 Doctype 스위치를 악화한 치명적인 이유는 개발자들이 Doctype을 맞게 쓰는 것이 표준을 올바로 이해하고 렌더링을 제대로 하는 것일 꺼라는 ‘가정’을 했기 때문이다. 왜 실패했는지 어떻게 아느냐고 묻는다면, 바로 IE7이 공개되었을때, 사이트들이 깨진것을 보면 알수 있다.

물론 Roger가 지적했듯이 IE6에 국한된 CSS 핵을 사용했기 때문이기도 하다. 하지만 대부분은 IE6 에서만 사이트 렌더링을 확인한 이유이거나 혹은 가장 많이 사용되는 대표적인 IE6에서만 잘 보여진다면 괜찮다고 생각했기 때문이다. IE6의 불완전함은 문서로 잘 나타나져 있었으니 개발자들이 좀 알고 있었어야 한다고 할지 모르지만 많은 개발자들은 “표준 모드” 의 옵션이 주어지지 않았거나 아예 그 존재조차 모르고 있었다.

IE의 플랫폼아키택인 Christ Wilson 은 IE의 개발의 핵심은 웹을 깨트리지 않는 것이라고 자주 이야기 하곤 했다. 하지만 슬프게도 IE7 은 많은 이들에게 바로 그것을 행해버리고 말았다. 똑같은 실패를 거듭하지 않고자 Microsoft는 Web Stands Project (저자 또한 멤버이다) 와 여러 표준을 인식한 개발자들에게 앞으로 개발자들이 올바른 표준을 준수할수 있도록 도울수 있는 방법에 대해 도움을 요청했다. 목표는 DOCTYPE 스위치 보다 더 뚜렷하며 IE뿐만이 아닌 여러 브라우저들에서도 적용이 가능한 ‘방법’ 을 찾는 것이었다.

완벽을 바라는 미래

작년 SXSW 에서 나는 운좋게도 뉴욕 공립 도서관의 Carrie Bickner 가 진행하는 토론회를 보게되었다. (Carrie Bickner, A List Apart의 Jefferey Zeldman의 부인) “디지털 유산과 Individual Collector 의 보호” 라는 주제 아래 도서관들과 개개인들이 디지털 아카이브를 유지하며 격는 문제점을 토론하고 있었는데, 대부분의 문제들은 꾸준히 업그레이드 되고 있는 파일 포멧들과 어플리케이션들에서 비롯된 것들이었다. Microsoft 오피스 2007을 예로 들면, Word1.0 버전의 문서를 그 당시 의도 했던 것처럼 렌더링, 보여주지 못한다는 것이다. 이 토론회는 나로 하여금 지금까지 웹이 얼마나 변해왔으며 앞으로 웹이 진화하며 얼마나 변화할 것인가에 대해 생각하게 하였다.

웹표준의 지지자의 한사람으로써 브라우저들의 꾸준한 발전과 함께 표준 이행을 꾸준히 개선하기를 원하지만 힘들게 만들어온 웹(테이블 레이아웃 조차도)을 보존하는 것 또한 중요하다고 생각한다. 아직까지는 Doctype 스위치가 괜찮게 돌아가니 그다지 “뒤로돌리는것” 이 어렵지 않겠지만 IE6 의 “표준” 에 맞춘 사이트는 어찌할 것인가? 많은 경우 IE7 이 제대로 렌더링 하지 못한다는걸 우리는 이미 잘 알고 있다. 그렇다면 저자가 원한데로 페이지를 보기위해서는 IE6 브라우저를 언제나 하나씩 가지고 있어야 한다는 말인가? 바로 그것이 수많은 도서관들이 옛 파일들을 보기 위해서, 보존하기 위해서 택한 방법이다. IE8이 점점 다가 오고 있는 가운데 IE7의 렌더링 엔진에 맞춘 문서들이 갖게될 문제들은 앞의 도서관들과 별반 다를 것이 없다. 과연 무엇이 해답인 것인가?

브라우저 버전에 맞추기

이상적인 세상에선 모든 스펙들이 시작에서 부터 유저에이전트들의 해석, 이행까지 완벽할것이다. 그보다 약간 덜 이상적인 버전의 세상에선 브라우저 밴더들이 꾸준히 업데이트 되는 표준들을 즉시 유저에이전트(브라우저)에 적용하여 유저들이 손가락 까딱 하지 않고 최신 버전의 브라우저를 사용 가능토록 할 것이다. 우리 개발자들 또한 최신의, 최고의 기술들을 사용하여 이전 버전 호환성의 걱정 없이 사이트나 어플들을 개발 할 것이다. 하지만 모두가 알다시피 우리의 현실은 그정도 레벨의 완벽에도 가깝지 않다.

표준은 힘들게 개발되고 발전하여 가끔은 몇년씩 걸려 “권고안” 에 상태에 이른다. 브라우저 공개의 사이클은 상품개발이나 마케팅 (보안, 기능 속도등) 과 긴밀하게 연관되어 벤더들이 표준에 직접 참여함에도 불구하고 표준 스펙의 준수는 먼 이야기가 되기 십상이다. 그리고 유저들은 특히 공공기관이나 회사들은 브라우저 업그래이드가 절대 빠르지 않다.

이 모든 요인들은 우리 웹개발자들을 사이트를 제작함에 있어서 곤란하게 한다. 우리가 원하는데로 브라우저가 보여준다는 보장이 어디있단 말인가?

CSS2.1이나 JS1.5 등의 언어의 버전을 명시하는 방법도 있긴 하다. 하지만 불행하게도 브라우저 벤더들은 몇몇 부분들의 스펙들을 적용하며 브라우저들 간의 해석이 다르기도 하니 두개의 동급의 브라우저들 에서 같은 CSS 인데도 완전히 다른 렌더링을 보여주기도 하며 같은 컨트롤이지만 완전히 다른 이벤트를 연출하기도 한다.

이러한 상황 가운데 우리 개발자들에게 주어지는 게런티, 보장, 5년 후나 지금이나 똑같이 해석될수 있는 옵션은 한가지 밖에 없다. 개발 배경이 된 브라우저들 리스트를 명시하게 한 후 해당 브라우저들을 이전 버전들도 지원케 하여 개발자가 원래 계획했던 모습들이 현재 뿐 아니라 미래에도 렌더링 되도록 하는 것이다.

이것이 바로 우리 그룹이 IE8에 제안하기로 결정한 것이며 타 브라우저들에도 적용되기를 바라는 것이다.

syntax 를 간편하게

이 “버전 지정”을 개발자들이 브라우저에 적용함에 있어서 중요하다 생각했던 부분중의 하나는 하드코딩이나 프로그램에 사용함을 쉽게 적응 할수 있도록 하는 것이었다. Conditional 코멘트나 XML 프롤로그, 혹은 HTML 프로필 형식등의 여러 syntax 옵션들을 고려해 보았고 그중 META 메타 엘리먼트 만큼 역할을 잘 수행하는 것이 없었다.

간단한 meta 선언을 삽입하여 우리는 IE8 이 어떠한 렌더링 엔진을 사용하는지 지정할수가 있다. 예를들어 이것을 head 부분에 삽입하면

<meta http-equiv="X-UA-Compatible" content="IE=8" />

IE8에서 새 “Standard Mode”를 사용하여 렌더링 하게 된다. 이 방법은 쉽게 다른 브라우저들도 포함할 수 있다.

<meta http-equiv="X-UA-Compatible" content="IE=8;FF=3;OtherUA=4" />

이 지정법을 쉽게 설명하자면 이 meta 엘리먼트를 사용을 character 인코딩을 지정해 주는것과 같은 방식이다. 이 “버전지정”이 작동하기 위해서는 meta 엘리먼트가 head안에 최대한 상위에 위치해야 하고 타 메타 엘리먼트나 타이틀 엘리먼트가 상위에 위치할수 있으나 타 엘리먼트들 보다 아래에 위치하면 안된다.

요목조목 살펴 보신 분들은 HTTP-equiv 형을 사용한것을 아셨을 것이다. 이 뜻은 서버쪽 해더에도 다음의 삽입시에 같은 효과를 볼수 있다는 것이다.

X-UA-Compatible: IE=8;FF=3;OtherUA=4

또한 함께 사용할수도 있다. 예를들어 header 방법으로 기본락을 전체 사이트에 적용시킨 후에 각각의 필요한 페이지에 meta 엘리먼트를 사용하여 적용 시키는 것이다.

Progressive enhancement은 어디로?

특정 브라우저 버전에 지정하는 “버전지정”은 미래까지도 확실한 사이트 렌더링의 보장이 있지만 그렇다면 progressive enhancement(1)의 콘셉을 깨뜨리는 것일까? 앞으로 우리가 사이트를 만드는 방식을 바꿔야 하는 것일까? 최신 CSS 속성들이 유효할때 즉시 사용할수 있는 것인가 말이다. 이 질문들은 우리가 처음 “버전명시” 를 논의할때 갖고 있었던 많은 질문들 이었다.

예를들어 IE8이 generated content(2) 을 지원하지 않는다고 한다고 가정한 후 (Acid2를 통과한만큼 지원하지만 그저 예를 든것임) IE8을 지정하여 generated content 를 사용한다면 IE외의 타 최신 브라우저들에서는 generated content가 보여질것이고 IE9가 generated content를 지원하더래도 사이트는 IE8에 지정되어 있기에 볼수 없을 것이다. 이 사이트에 “지정” 되어 있는 정보를 IE9로 업데이트 해야 비로소 generated content를 볼수 있는 것인데, 이것은 progressive enhancement의 코어 컨셉을 역행 하는 것이다.

이 progressive enhancement 부분을 포기해야 한다는 것이 상당한 고통인만큼 이 지침은 어찌보면 public-facing 임을 감안할때 최선일지도 모른다. 앞으로 브라우저들이 어떻게 작동할 것인지에 대한 “가정”을 내리면 안되기 때문이다. IE9로의 변화가 조금이라도 사이트의 레이아웃을 깨뜨리거나 스크립트의 지침의 해석을 바꾸게 된다면 유저들에게도 재난일 뿐 아니라 새 브라우저가 나오기전에 잘 보이던 상태로 돌리기 위하여 개발팀 또한 고생해야 할것이다.(이것이 현재 웹의 상태이기도 하다) “버전지정”은 개발팀이 원할때, 새 브라우저에 맞추어야 겠다고 결정을 내렸을때, 특히 새 브라우저 버전에 맞출 시간을 우리 팀이 정하여 원하는 만큼의 시간을 맞추고(새 브라우저 출시 시간에 맞추지 않고) 작업에 착수할수 있다.

그렇다면 “버전지정”은 progressive enhancement의 끝을 말하는 걸까? 현재로써는 no, 아니다. 일단 “버전지정”이 포함되지 않은 버전들의 브라우저들을 앞으로 몇년간 써야 하고 progressive enhancement은 여러 레벨의 CSS와 JS 를 지원하는데 필요한 방법이기 때문이다. 더 나아가 conditional 코멘트를 사용하여 스타일을 구현하고 스크립트를 덧붙여 IE 브라우저들을 사용하는 것을 몇년간 더 해야하기 때문이며 마지막으로 Progressive enhancement 테크닉을 사용한 JS 는 새 브라우저를 준비하는데에 재코딩의 시간을 줄여주기 때문이다.

보너스: “edge”

위험을 감수하며 무모함을 즐기는 이들을 위하여 IE는 “edge” 라는 값을 제공하기로 했다.

<meta http-equiv="X-UA-Compatible" content="IE=edge" />

이 옵션은 권장하지 않으며 사이트를 가장 최신의 IE브라우저로 렌더링을 지정하는 방법이다. IE=1000 이라는 편법을 써서 최신 IE 브라우저를 지정 하는 것 보다는 깨끗한 방법이지 않은가? 하지만 실험용 사이트에 적용 하는것 말고는 edge값을 적용 하는 것은 그리 실용적이지 않을 것이다. 이유는 Eric Meyer 라고 해도(렌더링의 지존) 새 브라우저가 가지고 올 레이아웃이나 스크립트 버그들을 예상할수 없기 때문이다.

미래의 희망

오랫동안 우리 디자이너들과 개발자들은 사이트를 제대로 출력이 가능한 신뢰할수 있는 방법을 고대하고 있었다. 크로스 플랫폼이 가능한 스타일과 스크립트를 짜야하는 두통에다 새 브라우저의 출시와 함께 손도 대 보지 못한곳이 깨지는 아픔을 견뎌야 하고 우리의 클라이언트들과 보스, 그리고 유저들에게 예상치 못한 곳이 깨지는 원인을 설명하는것이 절대 즐겁지도 않다. 하지만 IE8 의 버전지정의 소개와 함께 터널끝에 희망의 빛이 보인다. 나는 다함께 타 브라우저 벤더들도 마이크로소프트와 뜻을 같이 하여 이 기능을 적용했으면 하는 바램이다.

1. Progressive Enhancement - 기본 컨텐츠와 기본 기능들이 모든 브라우저들과 모든 이들에게 접근이 가능케 하며 접근성, 시멘틱 마크업 그리고 외부 css 와 스크립트를 강조하는 컨셉이다.
2. Generated Content - 생성된 컨텐츠. 예를들어 :before나 :after 를 사용하여 컨텐츠를 브라우저가 직접 생산하는 것을 일컫는다.

바락 오바마는 흑인 대통령 후보로써의 헤드라인 보다는 ‘변화’의 바람을 선전하는 케네디 스타일의 대통령 후보로써 더욱 명성을 날리고 있습니다. 최근 그의 ‘변화’의 슬로건에 맞게 2007년 말 그의 웹사이트가 업데이트 됬는데요 리포지셔닝이 아닌 완전한 리디자인으로 상당한 호응을 받고 있습니다.

깔끔한 디자인과 인지하기 쉬운 네비게이션 그에 걸맞는 정리된 컨텐츠가 돋보입니다. 특히나 Information Architecture 부분이 맘에 듭니다. 과감히 디테일을 죽이고 불필요한 부가설명 보다는 짧고 명료한 아이콘과 단어들로 표현하며 어느정도의 미니멀리즘 또한 볼수 있습니다. 물론 아쉬운 부분들도 많습니다. 대통령 선거 후보인 만큼 최대한 많은 이들과 다양한 환경의 이들에게 접근해야 함에 있어서 많은 자바스크립트와 약간은 무거운 디자인 이미지들로 겨냥한 방문자들은 어느정도의 인터넷 속도와 컴퓨터 환경을 갖추고 있는 중산층 이상으로 짐작할수가 있습니다. 상당한 발전을 한 인터넷 환경과 컴퓨터들을 감안 하여 어느정도의 과감한 결단을 내린 것으로 볼수도 있겠지만 충분한 리서치를 행한 후에 결정한 것이라 짐작하고 GOOD LUCK 을 외칠수 밖에요. 전화 모뎀이나 오래된 컴퓨터를 사용하는 이들에게는 버겨운 웹서핑일수 있겠습니다. 잠깐 여담을 하자면 타 사이트들에서 요즘 자주 눈에 띄는 IE7을 위한 핵이나 코드들을 여기서도 볼수 있군요. 접근성을 위한

<div style="display:none"><a href="#featurecontent">Skip To Content</a></div> 
<div style="display:none"><a href="#mainnav">Skip To Navigation</a></div>

코드도 보이고 말이죠. 둘러보면 볼만한 흥미로운것들이 좀 있네요.

오바마가 온힘을 다해 경쟁하고 있는 후보가 있죠. 바로 전 대통령 빌클린턴의 퍼스트 레이디 힐러리 클린턴 입니다. 그녀의 웹사이트 또한 그리 나쁘지 않은 디자인과 접근성을 갖추고 있는데요. 어찌보면 오바마의 예전 사이트와 그리 다르지 않은듯 합니다. 아이콘의 재구성과 베너들을 통일성 있게 줄이고 약간만 첫페이지 컨텐츠를 스크롤 다운 할수 있도록 나열 했다면 더욱 업그레이드된 사이트가 되지 않았을지.

그러고 보니 타 후보들의 사이트도 대충 비슷하군요.

누구나 지금즘 이면 ‘그럼 우리나라 대통령 후보들의 사이트는?’ 이라는 생각이 드셨을듯 합니다. 특별히 비방하고 싶은 후보나 사이트는 없지만 여러 후보들의 사이트를 볼아보며 아쉬운 부분이 많습니다. 뭐 힐러리나 타 미국 후보들 보다 좋은면도 많지만 솔직히 여러 해외의 ‘오늘의 플래쉬 사이트’에서 자주 보이는 한국 인터엑티브 디자이너들 개발자들을 보며 기술이 딸린다 라고 말하고 싶지 않군요. 플래쉬 남용이다 테이블 남용이다 크로스브라우징이 아니다 등의 이야기가 아닙니다. 하지만 전체적으로 복잡한듯 뒤엉킨 정보 나열을 보며 하나의 정보 사이트 라기 보다는 광고 사이트를 보는듯한 기분이었습니다. 한국적인 인터넷 문화에서 비롯된 디자인과 정보나열이긴 하지만 제가 기대를 많이 하는건지는 몰라도 (매일 듣던 인터넷 강국이라 최고만 바라는 걸까요) 더 잘할수 있지 않을까 라는 바램입니다. 지금도 괜찮지만 WHY NOT MORE? 대통령 후보들 사이트를 접속하면 ‘우와~’ 라고 감탄하고 싶은건 저 뿐인가요..

이명박 : www.mbplaza.net
정동영 : www.cdy21.net
문국현 : www.moon21.kr
이회창 : www.leehc.org
권영길 : www.ghil.net

물론…. 익스플로러로 접속하시기 바랍니다…
그러고보니 각 후보들께서 싸이월드와 네이버 블로그 다음 블로그를 갖고 계시는군요;; 워우

이번 2007년 6월1일이 첫 콘테스트 날입니다. CST 로 정오 12PM 이라고 했으니 한국 시간으로 6월2일 새벽 2AM 이 되겠군요.

시간이 허락하신다면 모두 참가하여 좋은 결과 있으시면 좋겠습니다.

저 참가합니다.

장점? 유용?

장점은 저자가 원하는 간단한 설명이나 간단한 주석 혹은 코멘트를 방문자가 쉽게 알아볼수 있도록 표현이 가능 하다는 것입니다. 책을 읽으면서 이러한 레이아웃을 볼 때에 블로그나 웹컨텐츠에 적용하면 좋겠다는 생각은 했었지만 깊게 생각해 본적은 없었습니다. 어느 특정 위치에 원하는 문구나 덧글은 넣을수 있지만 글을 쓰다가 아무곳이나 원하는 위치에 갯수에 관계받지 않고 side comment를 달아야 한다는 것이 issue 였습니다.

생각해보면 너무 간단 합니다만. ^^ 약간의 float과 negative margin을 넣어서 표현하는 방식입니다. 글을 써가면서 css나 다른것을 건드리지 않는점이 좋은점일수 있겠네요.

예제 페이지를 일단 보시면 이해하기 편하실듯 합니다. 왼쪽의 빨간 부분이 저자의 간단한 코멘트가 달린 부분입니다. 회색은 전체 글이 표현되는 부분이며 흰색은 p 의 문단 부분입니다. xhtml 코드를 직접 보시거나 style을 끄는것이 가능한 브라우저로 보시면 흐름이 어떻게 되는지 이해가 되실겁니다.

사용법

레이아웃에 삽입하는 방법은 간단 합니다. CSS에

.add {float:left; margin-left: -100px; width:80px;}

를 지정해 놓으시고, 글을 쓰다가 주석이나 덧글을 넣어야 하는 부분에 어느곳이나

<span class="add">덧글 내용</span>

를 삽입 하시면 됩니다. img를 삽입하신다면 img의 class 값만 add로 하시면 되겠습니다.

Side Comment에 왼쪽으로 여백을 -100을 주게되면 레이아웃 밖으로 -100px 위치하게 되고 float값 때문에 레이아웃에 영향을 주지 않게 됩니다. 물론 글을 담는 블락엘리먼트의 padding-left 값을 .add 의 margin-left값 보다 많이 주셔야 합니다.

후에 print.css 를 지정해 줄때도 이러한 방식으로 표현하셔도 되고 끄고 싶으시면 display:none;을 넣어주시면 전혀 문제가 없겠습니다.

발전 가능?

물론 이것은 간단한 기본 방법이고 여기서 더욱 개발을 해야겠죠. 혹시 TT 라면 지정값을 만드셔서 [SC] 코멘트 [/SC] 라고 하실수도 있구요. 물론 배포시 기본값을 display:none: 으로 해놓고 스킨제작자가 display: block; 으로 풀어주면 될듯 합니다. 워프라면 첫 페이지는 display:none;으로 되어 있다가 글을 제대로 읽기 클릭시에 display:block 으로 보여주는 방식도 있구요.

이슈가 없는건 아닙니다. Feed Reader에서 모든 CSS 스타일을 끄게 된다고 할 때에 이 부분이 Side Comment 부분 이라는 것을 표현하기가 힘들다는 것입니다. 저는 지금은 단순히 [ 내용 ] 대괄호로 나타내었습니다만, 여러가지 표현의 방법을 생각해 봐야겠네요.

잘만 사용된다면 유저가 글을 읽을시에 상당히 도움이 될꺼라 생각됩니다. 곧(과연 언제…….) 일모리네 레이아웃을 그렇게 바꿀듯 합니다만, 즐거운 레이아웃이 될듯 하네요. both author and the readers ^^

위의 예제를 응용해서 약간 손질을 본 레이아웃 입니다. 확인해보세요 ^^

HAPPY READING~~

일몰: “제가 혹시 도움이 좀 될까요?”

집사님: “아 그럼 플래쉬 같은걸 사용해서 여기에 물결좀 넣을수 있습니까?”

일몰: “아 네 가능하죠”

집사님: “그리고 이 메뉴 부분을 이미지로 만들려고 하는데, 이게(글자크기 조절을 막 하시며) 이렇게 글자가 커졌다 작아졌다 하니까 영…”

일몰: “. . . ”

몇주전에 조금이나마 도움이 될까 해서 찾아갔습니다. 물론.. 저 대화를 하고는 할말을 잃고 머뭇대다 나이드신분께 아는체 하는게 그리 좋을꺼 같지 않아서 그냥 이런 저런 부분에 대해 도와드리겠다고 하였습니다. ^^ 최대한 많은 이들에게 접근성을 필요로 하는 웹사이트중의 하나가 교회 홈페이지 일텐데 아쉬운 부분이 많군요. 어느 사이트이던 개발 전에 가장 중요한 체크업포인트는 사이트 존재의 목적 입니다. 그에 맞추어서 개발을 하겠죠. 개인 플래쉬 포트폴리오 사이트에 접근성을 높이기 위해 텍스트로 제작되기를 기대하는 사람은 없습니다. 그리고 교회 웹사이트가 플래쉬로 범벅이길 기대하는 사람도 없을겁니다. 누구에게나 편하게 다가갈수 있는 사이트들이 많아 지길 ^^

현재 우리가 살고 있는 웹2.0이라는 문화, 시대, 풍조에 관한 이야기는 태우님이나 다른 멋진 블로거 분들이 해박한 지식으로 자세히 설명을 하고 계시지만, 저는 이 웹2.0 일부인 웹사이트, 더 들어가서 웹 디자인에 국한하여 변화되는 부분을 나누려고 합니다. 웹의 어플리케이션, 사용자층, 하드웨어등은 급속히 변화되는것에 비해 웹사이트의 변화는, 특히나 Usability, 사용성에 관한한 아직 그 속도에 이르지 못하는게 아닐까 하는 느낌을 충분히 받았습니다. 오랜만의 글이라 제가 머리속으로 그리는것을 제대로 전달할수 있을지 걱정이 되는군요 ^^

유저의 변화에 따른 유저빌리티 (상편) - ‘인터넷 강국의 부모님들도 웹을 즐긴다’

하드웨어의 변화에 따른 유저빌리티 (중편) - 미정

어플리케이션의 변화에 따른 유저빌리티 (하편) - 미정

인터넷 강국의 부모님들도 웹을 즐긴다

웹2.0은 더 많은 더 깊은 층의 웹 유저들을 바라보고 있습니다. 어린아이부터, 게임, 게시판, 인터넷 동호회, 싸이월드, 블로그에 열심인 청소년들, 인터넷의 시작부터 함께한 중년층(추억의 너구리…), 컴맹이라 불리웠던 부모님과 연세가 지극히 드신 할아버지 할머님들까지 점점 다양하고 여러 분류의 유저들이 생겨나고 있는건 다들 아는 사실 입니다. 하지만 이러한 다양한 유저들이 생기는 반면 웹사이트는 얼마만큼 준비를 하며 변화 하고 있을까 라는 질문을 던진다면 그리 긍정적인 답이 나오는거 같진 않습니다. 극단적이지만, 과연 일모리네를 방문 하시는 분들중, 자신의 부모님께 간단한 세미나나 교육을 드림으로 웹서핑을 꽤나 괜찮게 하실것이다 라는데에 확신을 가지신분이 얼마나 많을지 질문을 던진다면 약간의 이해에 도움이 될런지요 ^^

고령층과의 교류

최근 386 이전 세대의 분들께 컴퓨터를 가르쳐 드릴 기회가 종종 생깁니다. 그리고 종종 듣는 말중의 하나는, “이런 깨알같은 글자를 어떻게 봐?” 입니다. 이상하지만 괜시리 죄송하다는 말이 나오게 되더군요. 해상도를 최소화해서 글자를 가장 크게 해 드립니다만, 그렇다고 보통 그 분들이 사용하시려는 모니터가 크지 않아서 800×600 해상도로 내려가야 글자가 그나마 읽을만 해지고 더러는 600×480 정도도 내려갑니다. 글씨가 읽을만 해지셨으니 이제 웹을 알려드려야 하는데 참 막막한 경우가 한둘이 아니더군요.

웹서핑 . . . 보통 한국 사이트의 규격은 1024를 맞추어 되어 있습니다. 고로 스크롤바는 상하조정뿐만이 아니라 좌우 조정까지 출현하게 되고, 생전 처음 보시는 스크롤바 라는것을 위 아래도 힘드신데 좌우까지 해야 한다고 말씀드리면 상당한 어려움이 다가옵니다. 마우스도 잘 못움직이시는데 스크롤바를 잡고 드래그를 하시자니 여간 쉽지 않습니다. 거기에다 ‘즐겨찾기’ 를 켜 놓아 드리면 웹서핑은 스타크래프트의 용어를 빌리자면 gg 라고 할수 있겠네요.

웹서핑 어려움의 문제는 여기서 끝나지 않습니다. 웹 용어의 문제, 메뉴 위치의 문제 등등이 그 다음 숙제로 다가옵니다. 일단 웹의 설명을 마치고 한 사이트를 같이 서핑 하며 여러 부분들을 가르쳐 드리는 중에 어려운 부분은 ‘과연 어떤것이 상위 메뉴 이며 하위 메뉴인 것인가’ 하는 문제입니다. 웹에 푹 빠져 사는 많은 젊은 세대와 386 세대 분들도 사이트를 접속하면 Home(홈으로) 등과 같이 나열되어 있는 링크들은 소위 말하는 상위 메뉴로 사이트의 큼직한 링크들을 담당하고 있다는걸 생각지 않아도 이해되고 골라 클릭을 하는 능력이 있지요. 하지만 메뉴 라는 것의 개념이 없으신 분들에게 알려드리는 것은 쉽지 않습니다. 상위 메뉴는 사이트에서 큼직 큼직 하게 다루니 찾기 쉽다고 해도 하위 메뉴나, 서브 메뉴들을 알려드리는것은 상당한 고통이 따르죠. 특히 영어로 되어 있다면. . .

어린이는?

물론 어린이들도 인터넷을 즐깁니다. 어릴때부터 컴퓨터를 즐기며 인터넷을 사용한다면 과연 자신의 아이를 위해서 뭘 개선해 줄수 있을까요? 글자 크기? 눈이 최대한 피로하지 않도록 크고 여백도 있는 곳이 좋겠죠. 올바른 용어? 당연합니다. 복잡한 메뉴구성 보다는 간단 명료하지만 잘 알아볼수 있는 네비게이션. 위의 컴퓨터와 친하지 않으신 고령층과 비슷한 목록들이 나오게 됩니다.

더 나아질수 있는 방법들?

이러한 부분에 있어서 접근성으로 더 촛점을 맞추어 여러 법안들이 나오긴 하였습니다만, 사용성으로 시각을 맞추어 어떻게 하면 웹사이트 방문시에 문제없이 기능들을 잘 활용할까 를 보고 싶습니다.

유저의 변화에 따른, 또한 특히나 이러한 부분에 있어서 민감한 웹사이트의 웹메스터들께서 하실수 있는 개선 방법등을 나누어 보겠습니다. 간단히 네비게이션, 폰트 크기, 레이아웃의 변화 등을 보고자 합니다. 이러한 부분의 개선이 있다면 충분한 웹2.0에 맞춰가는 사이트라고 할수 있겠죠. 어떻게 보면 기본기에 충실하면서 그 안에서 창의성으로 아름답게 표현되는 사이트가 되는것이라고 할수 있겠습니다.

*주의: 목적에 맞게 디자인되고 표출되어야 합니다. 어른분들이나 아이들이 전혀 방문할 가능성이 거의 없는 일모리네집에 메뉴가 영어로 되어있다고 크기가 작다고 머라 하신다면 ^^; 물론 개선 하긴 해야죠… 작은 설명이 뜨긴 해도 물론 더욱 큰 설명을 위해 조치를 취하려 합니다. ㅠㅠ

네비게이션

alistapart.com 의 Derek Powazek 은 웹사이트의 네비게이션이 잘 되어 있는지를 저울질 하는 3가지의 질문을 제시합니다.

1. 내가 지금 어디있는지 아는가?
2. 내가 다음 갈곳이 어디인지 아는가?
3. 내가 그 전에 갔던 곳들이 어디인가?

이 3가지의 질문에 무난히 답할수 있다면 네비게이션이 충분히 그 일을 감당하고 있다고 할수 있겠네요.

제가 보통 저희 어머님께서 웹서핑을 하실때, “어머니 인터넷 주소를 치고 들어가셔서 나오는게 큰 잡지라고 생각을 하시구요, 가장 맨 위에 나오는 메뉴들은 큼직 큼직한 토픽이고 그걸 클릭해서 들어가시면 왼쪽에 보이는 메뉴들이 바로 세부토픽이고, 이제 중간에 나오는 여러가지 글들이 바로 보시고자 하는 잡지 내용이에요” 라고 말씀을 드립니다. 아무리 사이트가 복잡해 보여도 (특히 한국 방송을 시청하시기 위해 MBC, SBS, KBS를 들락 날락 거리시는 어머님께) 그것만 기억 하세요 라고 말씀드리면 어느정도 이해하시고 서핑을 하십니다. 하지만 그 패턴을 벗어나서 메뉴들이 여기저기 퍼져 있거나 너무 복잡하게 움직이는 메뉴는 서핑을 참 힘들게 하는 요소가 됩니다. 자유스러움을 좋지만 개인 포트폴리오가 아닌 정보전달 사이트라면 조금은 자제 하는게 첫번째가 될수 있겠습니다.

특히 현재의 위치를 잘 알려주는 방식의 메뉴 구성, 예를들어 탭 방식의 구성은 인터넷 초보 유저뿐만이 아닌 여러 유저들에게도 도움이 되는 방식이라고 할수 있겠네요. NAVER의 블로그 페이지가 한 예가 되겠네요.

참고글: 탭 방식으로 html에 옷을 입혀주는 css

폰트사이즈의 변화를 잘 고려하자

폰트 크기의 중요성은 정말 그 필요를 느껴 보신 분들만이 아시는거 같습니다. 개발자나 디자이너의 입장에서 충분히 case study, 즉 임의의 상황들을 실험해봄으로써 가장 알맞는 폰트를 제공하며 옵션들을 제공하면 그만큼 편리하고 방문객이 편안해 할수 있는 사이트가 되겠죠. 예를들어 CSS와 JS 를 사용하여 방문객들에게 직접 폰트 크기를 조절할수 있게 한다던지, 방문객이 고령층이 꽤 된다면 폰트 크기 자체를 13PX 이상으로 조정하는것도 고려해볼만 합니다. 폰트 크기 변화를 브라우저에 맡길수도 있겠지만, 브라우저의 세부 메뉴까지 보실만한 능력이 안되시는 분들께는 유용 하겠죠. VISTA의 맑은고딕체가 나오긴 했지만 앞으로 백터 폰트들이 더 많이 개발되어 나오게 되면 12px 9pt 사이즈의 정해진 사이즈 보다 필요에 따라 디자인도 살리며 폰트 크기도 커지는 효과를 누릴수 있을 것입니다. 기대되네요 ^^

한가지 예를 들고 간다면, 정보 전달의 최선의 방법중의 하나인 블로그 라는 툴에서 소위 말하는 파워블로거들을 잘 보면, 디자인이나 참신한 아이디어 라기 보다는, 글씨 크기나 정보전달을 위한 깔끔하고 방문자를 배려하는 디자인을 갖고 있습니다. 그리고 그들은 꾸준히 고민합니다. “내 블로그의 글씨가 작아서 정보전달에 혹시나 걸림돌이 될까?” “글간격이 너무 작으니 넓혀볼까?” 이러한 고민들을 하는 이유는, 그만큼 그 중요성을 잘 인식하고 있기 때문입니다. 이쁜디자인 vs 유용한 디자인. 그 결과는 너무나도 뚜렷합니다.

유동적인 레이아웃

창크기의 변화에 따라서 사이트의 크기가 변화한다는것, 상당히 애매하고 어려운 부분입니다. 아마 이 부분은 하드웨어의 변화에 따른 유저빌리티 부분에서 더 자세히 다룰듯 한데요, 중요한것은 아직도 800px X 600px의 해상도를 쓰시는 분들이 많다는 것입니다. 통계적으로 보면 상당히 미묘할수 있지만, 어른들께는 꽤나 큰 부분이라는걸 염두 하시고, 정보 전달시에 1024에 맞추어 디자인을 하더래도 정보가 분산되어 나오기 보다는 일정한 부분에서 출력이 되어서 좌우스크롤바를 고정시키고 서핑이 가능할수 있도록 해 주시는것도 좋은 디자인이 될꺼라고 생각합니다.

어느정도의 유동성을 감안하여 디자인을 하겠다면 thinkvitamin.com 같은 사이트를 참고 하셔도 되고, js 를 사용하여 접속자의 해상도를 읽어들인후에 800 이하의 해상도에 맞는 디자인을 출력해도 좋은 방법이 될것입니다. 또한 Max-width, min-width 와 % 의 상대 스케일도 잘 이해 하시면 큰 도움이 됩니다

새창띄우기를 자제하자

간단히 ‘이 외’ 의 부분으로 한줄 넣으려 하다가 조금이라도 짚고 넘어가면 좋을듯 하여 넣었습니다. 이 부분에 대해선 예전에 나눈적이 있지만(열띈 토론 너무 아름다웠습니다) 그당시의 여러 이유와는 약간은 다르게 새창이 띄워짐으로써 갑작스런 변화에 당황 하시는 분들의 관점에서 말씀을 드리는 부분입니다 . 현재 보고 있는 창에서 새로운 창으로의 이동이 어른분들께는 꽤나 부담으로 다가옵니다. 정말 외부링크를 새창으로 띄워야만 하겠다면 어쩔수 없겠지만, 최대한 새창띄우기를 줄여서 한 페이지에서 링크도 클릭하고 ‘뒤로가기’ 기능도 잘 쓸수 있도록 배려해주는것이 생각외로 중요한 부분으로 보고 있습니다.

이 외에도 자세히 언급은 하지 않지만, 풀다운 방식보다는 리스트 형식으로 메뉴를 구성해준다던지, 폼 입력박스등의 폰트 크기를 약간 크게 하여 타입시에 잘 보이도록 한다던지, 아직도 토론되고 있는 뜨거운 감자인 Active X 사용을 줄이며 링크의 명확한 표시등도 어른과 아이들의 서핑을 위한 큰 도움이 된다고 볼수 있겠습니다.

마지막 마무리

이런 긴 글은 참 오랜만에 써보는거 같습니다. 하지만 그만큼 저에겐 중요한 부분으로 다가 왔었다고나 할까요. 웹2.0은 이미 우리의 삶에 발을 들여 놓았습니다. 인터넷 뱅킹부터 하여 TV 도 보고, 대학 원서도 넣고, 세금도 내고 말이죠. 하지만 그만큼 유저도 다양해 지고, 특히 어른들의 웹에 대한 관심도 상당히 높아 졌습니다. 단순히 이메일을 쓰는데에서 그치지 않고 웹으로 동영상도 보시며 신문도 읽게 되십니다. 물론 누군가는 ‘과연 소수의 집단을 위해 이정도의 배려를 해야하나?’ 라는 질문을 던질지 모르지만, 그것이 바로 웹2.0의 시대에 고려해 볼만한 부분이 될수 있다는 것을 인지하면 좋겠다 라는 것이죠. 언제 어디서 어른들께 즐겁고 재미나고 흥미로운 사이트가 폭팔하여 그들이 웹에 한층 가까워 질지 모릅니다. 우리의 웹 뿐만이 아닌 어른들, 아이들의 웹도 가꾸어 줄수 있다면 그 사이트는 참 멋진 사이트가 되지 않을까요. 더 나아가서 웹의 지식이라 불리우는 블로그 라는곳에 어른들의 귀중하고 수준높은 경험과 가치를 담을수 있다면 얼마나 우리의 웹이 더 발전되고 가치를 갖게 될까요.

* 최근 ‘어머니와 컴퓨터’ 에 관한 글들을 여기저기서 읽으면서 대부분의 분들이 부모님께서 컴퓨터를 배우시면서 정말 기초적인 부분에 대해 질문할때에 첨에는 괜찮았는데 같은 질문을 하시고 쉬운부분을 물으시고 하실때 ‘귀찮다’ 라는 반응을 보이시는거 같더군요. 혹시나 이런 아주머니, 아저씨들께서 모여서 쉽게쉽게 질문도 하시고, 토론도 하시고 기초적인 부분에 대한 동영상 강좌나 음성 강좌등이 있는 (물론 즐거운 채팅의 기능도 ^^) 커뮤니티 사이트도 참 괜찮겠다는 생각이 드네요. ^^ ‘쉽게 질문하고 나눌수 있게’ 하는 부분에 있어서 참 많은 연구과 개발이 필요하겠지만 말입니다.

웹 접근성 이란
웹 접근성은 장애가 있는 사람에게도 웹을 사용할수 있도록 해 주는 것이다. 더 자세하게 말하자면, 장애가 있는 사람들 에게도 웹과 함께 느끼고, 이해하고, 항해하며 교류할수 있게 하는 것이며 그들또한 웹에 기여할수 있게 되는 것이다. 또한 웹 접근성은 노년층과 같이 나이에 따라 변하게 되는 행동의 제약에도 해택을 주는 것이다.

웹 접근성은 시야, 청각, 언어, 신체 어떠한 부분의 장애도 모두 포함한다. “장애자들은 어떻게 웹을 쓰는가”(How People with Disabilities use the Web) 라는 문서에서 각각 다른 장애와 함께 웹으로의 접근 방식을 소개하며 그들의 웹 사용시의 시나리오 또한 포함하고 있다.

몇백만명이 장애때문에 웹사용에 제약을 받는다. 요즘엔 대다수의 웹사이트들과 웹 소프트웨어들이 접근성의 장벽을 지니고 있어 장애가 있는 이들의 웹서핑이 불가능 하거나 매우 어렵다. 접근성을 지닌 사이트들과 웹 소프트웨어들이 많아질수록, 장애를 지닌 이들의 웹에 대한 사용과 기여는 더욱 늘것이다.

웹 접근성은 장애가 없는 이들에게도 해택을 준다. 예를들어, 웹 접근성의 중요한 요점은 다양한 사람들과 다양한 조건들, 상황들을 더욱 많이 포괄할수 있는 유연성있는 웹사이트나 웹 소프트웨어들을 디자인 하는 것이다. 이 유연성은 장애는 없지만, 어떠한 특정 상황에 처해 있는 이들, 예를들어 인터넷 속도가 느리다던지, 팔이 부러졌다거나 나이가 들어 행동의 제약을 받는 경우에도 웹 사용이 가능케 하는 것이다.
-Web Accessibility Initiative (WAI)

하지만 왜

중앙행정기관 홈페이지를 포함하여 지방자치단체, 입법 사법 기관등 공공기관 77개의 대표적인 홈페이지에 대한 한국형 웹 콘텐츠 접근성 지침(KWCAG 1.0)을 기준으로 웹 접근성 준수 상태를 실시한 결과, 국내의 정부처 홈페이지들은 한군데도 웹 접근성을 모두 준수하는 홈페이지는 하나도 없는곳으로 나타남. 또한 웹 접근성의 기본적인 준수 사항인 대체 텍스트를 전부 제공하는 사이트는 하나도 없었음 - 2005년 웹 접근성 실태조사

이러한 조건에서 탈피하고자 실시하는 경진대회가, 그리고 그 경진대회를 통하여 교육을 하겠다고 말하는 곳에선 웹 접근성과 거리가 먼 것인가? 한국정보문화 진흥원 홈페이지의 메뉴는 크로스브라우징은 말할것도 없고, 전부 JS 로 제작되어 JS 가 off 일땐 서핑이 불가능 하며, 이 ‘훌륭한’ 대회에 참가에 관한 문의 이메일이 24시간이 지난 지금도 답변하나 없고, 정통부 홈페이지는 정말 정통으로 전형적인 무설명 플래쉬 범벅뿐이다.

도대체 누가 누구에게 상을주며 교육을 한단 말인가? IABF 정보통신 접근성 향상 표준화 포럼엔 오른쪽 마우스를 ‘정보보호 차원’ 에서 막아 논다며 클릭조차 제대로 될수 없게 해 놓았으며(오페라에선 그것또한 뒤바뀌어 인식도 제대로 되지 않는다) 접근성에 관한 공식 문서들 초자 이러한 공식 홈페이지에서 제대로 정리되지 않아 오히려 블로거의 글이 더 잘 정리되었다고 보이는 상황에서 (문서의 정리와 모음은 크게 틀리다.) 난 화가날 뿐이다.

이제 막 웹에 꿈을 갖고 있는 고등학생들이 ‘그럼 정통부나 한국정보문화진흥원 홈페이지는 왜그런가요?’ 라고 물으면 뭐라 답할것인가? 경진대회를 열면서 이 대회의 제대로된 Guideline 은 제시하고 있는가? 홍보글 마지막에 “※웹 접근성이란 장애인 및 고령층 등 모든 사람들이 특별한 전문지식이나 능력 없이도 웹 사이트에서 제공하는 모든 정보에 접근하고 이용 할 수 있도록 보장하는 것” 이라는 문구가 혹시 다는 아닐거라 굳게 믿는다.

정말 기쁜 마음으로 환영하는 행사 이지만, 마음 한구석에 씁쓸함, 불안함은 어쩔수가 없다. 꼭. 꼭 좋은 결과가 있으면 정말, 정말 좋겠다.

마지막으로 이 대회를 혹 참가한다면 이 지침은 꼭 읽고 참가했으면 하는 바램이다.