신현석 님은 UI 개발자나 웹표준, 접근성에 조금만 관심있으신 분들은 잘 아시는 블로거일 겁니다. 최근 웹2.0 트랜드를 통해 웹의 기본에 대해 다시 돌아보는 기회가 많아졌으며, 자연스럽게 웹표준 커뮤니티의 활동들도 활발해 지고 있습니다. openmaru에서는 이러한 변화의 힘이 좀더 희망적인 웹의 발전으로 이어지기를 바라는 마음으로, 우리가 앞으로의 웹서비스를 개발하는데 반드시 고민해 보아야 할 문제들을 얘기해보는 자리를 만들었습니다.(2006.10.31)현석 님과의 첫 미팅이어서 우선 가볍게 몇 명만 모여서 얘기했는데, 앞으로 더 많은 분들이 함께 하면 좋겠습니다.

대화의 맛을 살리려다보니 좀 긴 글이 되었습니다만, 일반적인 세미나 자리에서는 듣기 힘든 재미있는 얘기들도 많아서 편집없이 그대로 옮기기로 했습니다. :)

-----------------------------------------------------------------------------------

이광호(개발자, 웹데이타아키텍트, 이하 이)
오늘의 대화 주제를 이렇게 정리해봤습니다.
- 웹 접근성, 웹표준 과 웹 2.0 UI 와의 관계
- 웹2.0 시대의 UI 개발의 역할분담 및 UI 개발자의 비전
- 웹2.0 디자인 방향
로 말씀을 나누고자 합니다.

신현석(UI개발자, 이하 신) : 사실 웹2.0이라는 트렌드보다는 웹 자체의 보다 근본적인 이용에 관심이 많습니다. 그래서, 만드는 모든 사이트가 다 테스트베드이고(웃음) 글도 공유하고 교육도 합니다.

이 : 주제를 다 바꿔야겠네요.(웃음)
사실 openmaru에서 웹2.0이라는 트렌드에서 캐치하고 싶은 것이 바로 원래 웹의 기능에 충실하자는 것이므로 현석님 생각과 다르지 않습니다. ajax가 중요한 게 아니라, URL이 살아있는 것이 중요하다고 생각합니다.
예를 들면, netvibe 는 rss 링크를 클릭했을때 자체 Rich UI 로 처리하면서도, 브라우저의 URL 관련기능(새창열기,탭열기) 이나 del.icio.us bookmarklet등이 모두 작동합니다. Rich UI 로 사용성이 증가 되면서도 접근성이나 표준의 취지에 충실한 웹이라는 의미에서 웹2.0 을 규정하고, openmaru에서도 같은 방향의 UI 를 고민하고 있습니다.
그럼 첫번째 주제로, 최근의 웹2.0스러운 UI와 접근성, 표준의 관계에 대해 얘기해볼까요?

신 : 소위 웹2.0스러운 UI라는 것은, 디자인 트렌드라고나 할 수 있지요. 효과적인 ajax도 아니고 자바스크립트로 dhtml짜놓은 것이 대부분입니다. 실제로 웹2.0라고 하는 사이트들이 접근성과 표준을 준수하지 않고 있습니다.flickr도 표준준수전혀 안되어 있고, del.icio.us도 그다지 만족스럽지 않고.사람들이 두가지를 결부시키려는 이유가 아마 트렌드여서인것같은데 공통성은 없다고 봅니다. 특히 ajax 프레임 나오는 거 보면 대부분 접근성 꽝이예요.(웃음)
ajax도 내년이면 사그러들 것 같고 fade in/out, drag/drop 등이 사용성에 도움을 그리 많이 준다고 볼 수도 없습니다.대개는 wow effect 인 것이 대부분입니다.

이 : 지금까지는 ajax를 위주로 웹2.0 UI 의 부정적 측면을 말씀하셨습니다만, 저는 웹2.0 스러운 사이트가 있으면 소스 열어서 문서형식(DTD)을 확인하는데, 최근에는 예전보다는 xhtml 등 DTD 명시가 많이 늘어난 것 같습니다.
물론 이역시, 표준을 준수한다기보다는 일종의 계급장이나 최근 트렌드에 맞추는 것으로 받아들여지는 경향도 있는것 같습니다.

신 : 웹2.0 강의를 위해 조사해보니, 웹 2.0사이트로 인식되고 있는 사이트의 반 정도가 W3C 권고사항을 지키고 있다는 뉘앙스는 풍기고 있지만 웹표준의 준수가 웹 2.0의 필요조건은 아닌 것 같습니다.

이 : 웹2.0에 대한 팀 오라일리 페이퍼에서는 데이타가 가장 중요하다는 얘기를 하는데, 이것이 웹 컨텐츠 접근성과 일맥 상통하며일부에서는 표준준수도 웹2.0 의 주요 덕목으로 언급되고 있습니다. 물론 ajax도 적절히 쓰는 딜리셔스처럼 적절히 쓰면사용성이 좋아진다고 생각합니다.

신 : 사실 표준을 준수함으로 인해 당장에 가시적인 이득은 없습니다.인증마크라고 하지 않고 배지라고 하듯이 비지니스적인 도움은 거의 없는 것 같습니다.

이 : 비지니스적으로는 그렇습니다.

신 : 요즘은 좀 트랜디한 느낌은 줄 수 있지만, valid한 markup이 중요한 게 아니라 표준의 목적을 지키는 것이 중요하다고말해야할 것 같습니다. 제가 웹2.0이라는 트렌드의 부정적인 입장이라기보다는 우리가 당연히 지켜야할 것을 하는 것에 집중하는게좋겠다는 거죠. 그것을 트렌드에 넣고 말고를 떠나서 w3c가 말하는 것이 이미 앞으로 흘러갈 것을 얘기하는 것이므로 표준준수자체가 트렌드에 맞는 것이 될 겁니다.

이 : 네....사실 웹2.0의 부정적인 측면이 많지만 이용하는 것도 의미있죠. 자본이 몰리고 기술적으로 투자가 되는 기회니까, 그 에너지를 받아서 웹표준 운동(웃음)의 기회로 이용해야하지 않을까요?

신 : 우리나라에서는 용어 혼선이 많습니다. 확실한 선을 긋기 위해 굳이 관련 없는 것은 분리시켜야겠다는 생각이 깊이 자리잡고 있습니다. 다 좋은 거니까 좋게좋게 가면 좋지만...(웃음)

이 : 흠... 용어야 어찌되었건, 우리 조직에서 중요하게 생각하는 UI는 데이타를 최대한 유통시킬 수 있느냐입니다. 어떤 사람이어떤 상황에서 어떤 프로그램에서 쓰든지 접근이 가능하도록 하는 그런 맥락에서, xhtml 기반으로 가는 것이 유일한 대안이라고생각합니다.
두번째 주제로, 기존의 웹UI개발과 달라져야하는 것이 확실한데요, 기존에는 html 태깅이 주로 그림그리는목적이었다면, 데이타를 중시하는 앞으로의 방향에서는 html로 컨텐츠를 표현하는 원래 역할을 회복해야 한다고 봅니다.따라서UI개발자가 그림의 코더가 아니라 웹컨텐츠 개발자 혹은 웹컨텐츠 디자이너 역할을 해야하지 않을까 싶습니다.
또한 그림이라는 측면이 css로 분리되면서 실제 html 코드는 많이 단순해져 개발자가 생성할 수 있을 정도로 심플해졌습니다. UI개발자의 역할과 비전이 바뀌어야할 것 같습니다.
사실 제가 있었던 회사(포털)에서 UI개발자라는 직능명을 제가 만들었습니다. 원래는 그 직능이 없었죠. 더 rich한 것을 고려했으나 html 코딩 전문가가 되어 버렸습니다.(웃음) 쉽지 않네요.
최근에 네이버에서는 “연결하는 사람”이라고 하지만 자칫 “낀 사람”이 되어버립니다. 포지션이 중요한데, 지금까지는 디자이너나 서버사이드 개발자들의 목소리가 더 컸죠. 디자이너는 원하는 비쥬얼이 보이기만 하면 되고 개발자는 퍼포먼스만 나면 되기 때문에컨텐츠의 흐름은 별로 고려되지 않았습니다. 해서, UI개발자가 컨텐츠성을 책임지는 것이 바람직한 역할이 아닐까 하는데 어떻게생각하세요?

신 : 현재는 컨텐츠의 구조화 책임자가 없습니다. 사실은 html하는 사람이 컨텐츠 구조화를할 것이 아니라 팀 전체가 같이 해야 하는 것 아닐까요? 즉, 정보 설계자(Information Architect)가 있어서그 사람이 전체 컨텐츠 구조를 만들고 그것을 모든 개발자가 공유해야 하는 것이 아닐까요? html 코딩을 디자인이 나온 다음에할 것이 아니라 아예 기획자가 html을 만든다는 거죠. 컨텐츠 구조화 작업을 프로세스 깊숙히 넣어야 합니다.
그리고 서버쪽 어플리케이션 개발자도 따로 있고, markup을 총괄하는 역할, 스크립팅하는 역할도 분리 되어야 합니다. CSS를 다루는 사람은 스타일가이드를 웹언어로 구현하는 역할을 하게 됩니다. 현재는 모든 룰이 뭉뚱거려져서 웹개발자라고 하고 있습니다만...
또, 그러면서도 모든 정보(컨텐츠)의 흐름을 다 알고 조정해주는 수퍼맨이 하나 있어야 합니다. (이 : 수퍼맨? 수퍼바이저?)

이윤정(UI개발자, 이하 윤) : 하지만 현실적으로 불가능해서 우리(UI개발자)가 스스로 원하는 스토리보드를 만들고 있습니다.

신 : 스토리보드도 어찌보면 필요악입니다. 중간중간에 끊어진 링크가 너무 많거든요. 스토리보드에 의존해서 구현하는 방식에 대해 심각히 고민하고 바꿀 필요가 있습니다. 단계적인 개발 프로세스도 중요하지만 컨텐츠를 만들어 배포하는 것은 복합적이고 다양한 관점에서 바라봐야할 일입니다. 해서, 전체적으로 고민하는 사람이 있냐없냐, 구현할 능력있는 사람이 있냐없냐가 중요합니다. 자기포지션에서 최대한 해야죠.

이 : 포털에서도 기획자들이 IA역할을 하고는 있는데 아직은 피상적인 것 같습니다. 그 사이트를 넘어선 유통까지 생각하려면 HTML까지도 좀 알아야하는데...
CSS로스타일이 거의 표현되면 데이터 표현 위주의 html 프로토타이핑을 할 수 있습니다. 지금까지는 기획도 그 역할 안하고 디자인,개발 다 안해서 비어있었고, 그 역할을 할만한 UI개발자는 조직 내에서 영향력이 크지 않았고... 그것이 그대로 우리나라 웹에반영되어 있습니다. 해서, 제 명함에는 웹데이타아키텍트 라고 썼습니다.(웃음)

장기형(UI디자이너, 이하장) : 저는 좀더 현실적인 얘기를 듣고 싶은데, 현석 님이 일하시는 회사(웹에이전시사)에서 작년에 재정경제부 프로젝트로 표준화관련 상을 받았는데 현실적으로 조직이 운영되고 있는지 궁금합니다. 비용이 많이 들었을텐데 어떻게 설득이 되었는지요?
그리고, 현실적으로 업무 역할 구분이 어떻게 되어 있나요? NHN UI조직개편에 대해 아쉽다는 커맨트하신 것을 봤습니다만...

신 : 현실적으로는 난감합니다.(웃음) 비용이 많이 들어가는 것이 사실입니다. 이성노님이 블로그에서 말씀하신 것과 같이 지금까지비용이 덜 든 것은 퀄리티를 적당히 줄였기 때문입니다. (HTML validation 이나 웹 접근성을 엄격히 지키려고 하면최소 1.5배의 시간 필요합니다.) 저의 경우엔, 이렇게까지 하는데 2년 과정이 필요했습니다. 그 결과가 재정경제부 상이고 그전에는 저도 그다지 퀄리티가 높이 않았습니다. 지금은 표
준이라는 것이 눈으로 드러나는 것이 있고 기준이 있으나 전에는 관련 정보가 거의 없었습니다.
직능, 직군, 일정에 대해 얘기하기는 좀 힘듭니다. 2년간 서서히 변화된 것이 지금까지 온 겁니다. 과거에는 일정을 못 지키면안되니까 제가 할 수 있는 데까지 했던것 같습니다. 제 경우는 초기여서 그랬는데, 일반 회사에서 2년간 개발자를 교육시키기는힘들 것 같습니다. 퀄리티 문제가 아니라 교육투자비용 문제가 생깁니다. 가장 현실적인 방안은, 어느정도 준비된 인력을 찾고 그사람이 올라갈 수 있도록 도와주는 것이라 생각합니다.

이 : 에이전시에는 표준에 대해 고민하는 사람 없었고 더구나 남의 것 만들어주는 것이니...

신 : 사실 열악한 에이전시 상황에서는 표준을 준수한다고 해서 특별한 이점도 없습니다. 기계가 접근해서 얻을 수 있는 효과가 정말 있다면 구현해볼만한 가치가 있겠죠. API를 만들었는데 안돌아가면 정말 엄격하게 지키겠죠.(웃음)

김범준(openmaru 실장, 이하 김) : 오늘 윤석찬님 블로그에 구글의 transcoding을 적용했을 때 표준의 power가 나타난다는 글이 있었습니다. 다음과 조선일보를 비교했던데 네이버와 했으면 더 좋았을 듯.(웃음) CSS는 적용되었으나 시맨틱한 태깅을 인식했느냐에서 차이가 드러난것 같습니다.

이 : 제가 있었던 회사는 제가 그만둔 후부터 잘 움직이더군요.(웃음)

신 : XHTML이면 http 요청 날려서 뽑을 수 있는 데이타가 엄청 많아지죠.

이 : 제가 원하는게 바로 그거예요. 오픈 API는 이미 기획된 범위가 있어서 소위 창발성을 못 따라갑니다. 사이트 전체가 XML 기반의 오픈 컨텐츠화 되어 있으면 그 컨텐츠 종류만큼 API가 많은 것이니 전혀 예상못한 활용이 가능해지겠죠.
얼마전 programmableweb 이라는 오픈 API 포탈 의 API/Mashup 매트릭스를 분석하는데 정작 거기는 API가 없어서 일일이 손으로 엑셀로 옮겼습니다, 이런 꾸웩 !(웃음)

신 : 마이크로포맷이 그러한 상황에서 많은 도움을 줄수 있겠다고 생각 했지만 오늘 팀버너스리의 HTML다시 만든다는 블로그 글 때문에 어떻게 될지 묘연해 진 것 같습니다. 마이크로포맷은 아직 실현가능성 검증된 것이 없어서 의문이긴 했지만...

이 : 시맨틱 웹의 매우 실용적인 접근 방법이 아닌가요?

신 : 아는 사람만 알죠.(웃음)

이 : 사실 팀버너스리가 실수를 많이 했어요. 시맨틱 웹에 무거운 사람들 데려다가 놓는 바람에 ..
모든 직능에서 관심을 가져야한다고 하셨는데, 디자이너들도 이런 생각에 대해 공유할 필요가 있습니다. 타협이 필요합니다. 픽셀 하나에 목숨 거는 디자인 관습이 바뀌어야 하는데 어떻게 바뀌어야할 지는 디자인 쪽에서도 고민했으면 합니다. 최근 웹2.0 의 디자인에 대한 어떤 페이퍼에서는 데이타를 디자인해야한다고도 하는데, 디자이너가 다 해야 하네요.(웃음)

신 : 사실 CSS 로도 픽셀도 다 맞출 수 있고, 굳이 그것을 잘못되었다고 생각하지는 않습니다. flexible 디자인을 CSS로 할 수 있으니 굳이 제한할 필요는 없지만 브로셔 찍듯이 웹을 바라보는 건 좀...
근데 그것도 구현할 수는 있어요.(웃음) 그 때 그 때 상황에 맞게 적용하는게 필요해요. 접근성을 지키면서도 양쪽 다 맞춰줄 수 있으니 표준이라는 이름으로 그런 니즈(pixel perfect)를 억제할 필요는 없지 않을까요?
사실 경험 많은 디자이너의 디자인 코딩은 어렵지 않습니다. 경험없이 그냥 만든 디자인에 대해서는 가서 얘기해야하는데 그것도 하나의 상황으로 받아들여야...

이 : 역할분담도 이슈입니다. 최근에는 포털들도 UI개발의 중요성을 인식하고 해서 업계에 인력이 많이 부족하고, CSS로 스타일을 분리해 버리면 html 코딩도 많이 단순해 지고 서버 개발자도 ROR같은 프레임웍등의 도움으로 일이 많이 줄어서 서버 개발자가 html 까지 하는것도 고려중입니다.
물론 주 업무가 아니었기 때문에 아직 익숙치는 않겠으나 HTML/javascript 까지는 개발자가 하고 CSS는 디자이너가 하면 어떨까요? 적어도 양쪽 커리어패스의 특정 시기에는 꼭 해야하지 않을까 합니다. 즉, 기존의 전문성, 역할, 비전을 재정립 해야할 상황이죠.

신 : 현실적으로 불가능하다고 봅니다. XHTML을 데이터 형으로 인식하는 개발자를 못 봤거든요.(웃음) 패턴 출력만 고려하지 데이터형이라고 생각지 않더군요. 그리고 디자이너가 익히기에 CSS 룰이 너무 복잡합니다.
제가 생각하는 역할 분화는 기존 웹개발에서 진짜 웹개발을 분리하는 거예요. 어플리케이션에서 클라이언트 사이드를 분리하는 것입니다. 스크립팅,html,css 세가지를 서로 분리하는 것은 무리가 있고요,
다만 기존 UI 개발자들은 스크립팅 능력이 문제가 됩니다. 결국 스크립팅 능력이 있는 개발자가 세가지 다 하는 것이 가장 효율적이라고 봅니다. 대개 자바스크립트 어설프게 아는 서버 개발자는 HTML도 모르더군요.

이: 그럼 기존의 UI개발자가 클라이언트 사이드를 확실히 커버해주되 데이타 markup 과 디자인 표현을 확실히 분리한다는 것이군요, 결국 어설프게 다 하는 것보다 서버 개발자는 서버개발만, 디자이너는 디자인만 하는 것이 좋다는 의견이네요.

신 : 어플리케이션 개발자들에게 자바스크립트를 못하도록 뺏는 것이 중요해요. 안 좋은 효과가 많아요.(웃음)

이 : 할려면 CSS까지 커버하든지...

신 : CSS는 전문가를 따로 두는 것도 가능합니다. CSS를 따로 떼내려면 우선은 완전하게 구조화된 마크업이 있고 그 마크업을 기반으로 디자인을 입히게 됩니다. 스크립트가 많이 들어가는 동적인 컨텐츠가 아니면 미리 CSS룰에 대한 가이드라인을 가지고 CSS전문가와 협업할 수 있겠으나 바람직한 것 같진 않네요.

이 : 휴 암튼, UI는 참 어려운 것 같아요. 저도 PC통신 시절 전용 브라우저도 만들었지만 그 당시 윈도우 클라이언트 이후 UI가 그렇게 좋아진 것 같지 않습니다, Rich 하지도 않고, 생산성이 좋지도 못하구요.

신 : 웹인터페이스가 발전해갈 길을 잘못 찾고 있습니다. CS와 같은 인터페이스를 웹에서 구현하려고 하는 시도만 많다는 느낌입니다. 사용자 경험, 사용성, 크로스 플랫폼 다 보장하려면 가장 근본적인 룰대로 만드는게 필요합니다.

장 : IE 열어서 싸이월드 하는 이용자에게 필요한 경험을 제공하려면 표준성을 해칠 수 있을 것 같은데 어느 쪽 손을 들어주시겠어요? 즉, 웹표준과 웹접근성이 유저빌리티와 배치되는 부분 있을 때...

신 : 표준을 지키는 것이 UI를 해치지는 않습니다. 표준이나 접근성은 되느냐마느냐의 문제죠.

장 : 하지만, 유저빌리티를 고려하지 않은 레이아웃의 사이트를 디자인해도 똑같이 표준적인 웹으로 표현될 수 있지 않을까요?

신 : 말 안되는 디자인이란, 모양 그대로는 다 되지만 확장성이 없거나(박스 크기가 늘어난다거나) 이용자 동선이 말이 안되는 것 등입니다. 즉, 분리해서 생각할 수 있다는 거죠.

이 : 제 생각은 좀 다른데요, 사용성, 접근성, 웹표준등이 전혀 무관하지는 않다고 봅니다. 컨텐츠 접근성이 확보되서 스크린리더로읽히는 등 제한된 상황에서도 사용되게 하는것이 사용성도 높이는 것이지요. 또한, 웹표준을 지키면 접근성을 확보하는 것이 그나마용이(접근성이 더 큰 문제이므로)하게 된다고 생각합니다.

신 : 사실 표준, 접근성, 상호운용성, 사용성 등의 관계가 애매모호한데, 서로 배타적이지는 않습니다. 닭-달걀 문제일 수 있는데 W3C에서 권고안이 나오려면 WAI의 검증을 거쳐야하듯이 표준자체가 보편적 접근성을 고려해서 만들어졌으니 완벽치 않더라도 어느정도 이해하고 만들어야 다같이 좋아질 수 있습니다.
표준에서는 굳이 사용성을 얘기하고 있지는 않습니다만 접근성 높이려면 사용성도 고려해야하는 등... 딱 구분하기 힘들고 분리해서 생각하는 것이 현실적으로 힘듭니다.

이 : 하지만 HTML4.0보다 XHTML1.1 통과하면 굳이 모든 브라우저 테스트 안해도 된다든지 하는 보장이 있어야 validation 통과의 의미가 있을텐데요...

신 : html4.0 과 xhtml 1.0 간 차이는 거의 없습니다. XHTML은 XML 파서로 파싱이 가능하다는 것 뿐. validation은 어떻게 보면 상징적인 의미가 있을 뿐 통과해도 접근성이 떨어지는 사이트는 많습니다.

이 : 접근성 체크 툴도 많지만 실용적인지 모르겠습니다. 스크린리더는 아직 테스트 못해봤는데 시도해보셨어요?

신 : 체크 툴이라는 게 노가다를 줄이거나 접근성에 대한 지식이 부족한 사람들이 최소한의 오류를 찾는 정도이지, 제대로 평가하려면결국 사람이 직접 해봐야 합니다. 툴에 의존하는 것은 지금 상황에서는 별로 바람직하지 않다고 봅니다.
접근성 리포트를 내는 건 어렵지만(장애인도 웹사용능력이 각자 다르니) 상식적인 수준의 테스트는 간단히 할 수 있습니다. 파이어 폭스와 웹디벨로퍼 확장기능만 갖고도 고퀄리티로 접근성 테스트를 할 수 있습니다.

이 : 회사는 경제논리를 따라 움직이게 됩니다. 이용자 99%가 IE를 쓰니까 IE만 지원하고. “시각장애인이 얼마나 된다고”라는 얘기를 들을 때 어떻게 대답해야할까요?

신 : 소수자를 배려해야 성숙된 사회가 된다는 식의 일반적인 얘기 밖에 할 수 없는 게 사실입니다. 고퀄리티를 만들기 위한 수단이라고 얘기되어야지 매출증대를 위한 추가투자비용이라는 식은 안됩니다.

이 : 사실 소수자를 위한 배려의 결과로 대다수에게도 좋은 퀄리티가 나온다고 봅니다. 키보드나 마우스가 없거나 눈이 아파서 글자를 크게 보고 싶을 때가 있자나요.

신 : 이용자 유치에 도움이 된다는 얘기도 있습니다. IE이용자가 95%인 사이트를 모든 브라우저로 접근가능토록 만들었더니 IE 비율이 85%로 떨어지고 기타브라우저가 15%로 증가했다는... 예를 들면, 국민은행 사이트는 IE 이용자가 100%일텐데 파폭에서 이용 가능하면 80%정도로 떨어질 수도 있겠죠. 현재 상황은 경제논리로 고객의 권리를 뺏고 있는 거죠.

이 : 고품질이 회사의 이익으로 되돌아온다 식으로 회사의 경제논리에 맞게 연결시켜주는 것이 필요하지 않을까요?

윤희경(웹서비스마케터, 이하 희) : 안 그러면 표준화란 공공기관에서만 통하지 않을까요?

신 : 1차적으로는 그렇습니다. 파폭이 되면 매킨토시 이용자를 확보할 수 있고 맥 사용자는 오피니언 리더일 가능성이 높으므로 홍보효과가 높아진다.. 식이라든가.
실제적인 이익은 사실 좀 궁색합니다. 그래서 경제논리로 연결시켜 투자비용으로 인식케하는 것보다는 당연히 가야하는 방향으로자연스럽게 인식되게 해야하지 않을까 합니다. 그래서 종교처럼 “전도사”라는 표현을 쓰는 거겠죠. 웹표준 마케터가 아니라.

희 : 계속 자발적으로 전도될 수 있을까요?

신 : 일부만 가능할 듯 싶습니다. 극소수는 너무 냉정하고요(웃음). 미국에서는 섹션508 을 만들어서 법제화했으나 실제 준수율이 40% 정도 밖에 안되죠. XHTML2가 나와도 상당수는 html3 같은 걸로 이미 돌아가고 있을 거예요. 대변혁 같은 것은 힘들죠.
효과를 입증할 수 있는 말그대로의 플랫폼을 만드는 작업이 성공적일 때 표준의 가치가 따라서 높아질 수 있겠죠.
구글처럼 표준 안지키면서도 접근성, 상호운용성을 지키는 아주 특이한 케이스도 있습니다.

이 : 파폭 이용율을 높이는 방법 밖에 없지 않을까요... 파폭 전도사이신 윤석찬 님이 좀더 많은 역할을 해주시면...(웃음)

신 : 웹 위젯같은 대안적인 UI 들이 많이 사용되면 접근성이 좋은 수단이 될 듯도 합니다.
그런 상황에서라야 사이트 잘 만들어놓으면 운영하기도 쉬우니까요. 표준을 경험해보고 이득이 될 수 있다고 조금이라도 느낀 사람은 표준을 버리지 못하게 되더군요.

이 : 하지만 효과가 쉽게 보이지는 않습니다. 웹2.0 서비스의 성공요소 중 큰 부분인 network effect를 만들어내려면연결이 가장 큰 전제조건입니다. 물론 개방도 되어야 하고요. 이렇게 연결의 중요성이 인식되면 접근성도 자연스럽게 중요해지지않을까요?

신 : 결국 사용자를 가장 중심에 놓고 생각해야할 것 같습니다. flickr의 초기 생각도그냥 사진을 공유하는 플랫폼이었죠. 거기서 네트웍, 컨텐츠가 형성이 된 것이죠. 사용자를 중심에 두면 접근성, 상호운영성,웹표준 등이 모두 자연스럽게 따라 갈 수 밖에 없죠.

(여기서 잠깐, 신현석 님이 맡고 계신 팀의 사내 역할에 대한 얘기가 오갔는데 생략합니다)

이 : 포털이 에이전시보다 더 영향력이 있을 것 같은데 포털에서 일할 생각은 안해보셨어요?

신 : 표준을 알리려면 표준 준수 사이트의 갯수가 많아야 한다고 생각했습니다. 그리고 사람들이 “야후니까, 다음이니까 저렇게만들지.”라고만 생각할 것 같았고. 요새는 생각이 좀 바뀌었어요. 에이전시에 얘기하는 것은 소귀에 경 읽기구나, 이렇게 해서전체 시장을 다 바꾸는 것은 불가능하겠구나... 해서, 요즘은 의식을 가진 사람들을 잘 지원하는 방법을 생각하고 있습니다. 우선사람들이 보고 공부할 책이 없어요. 작년에 쓴 책은 욕을 무지하게 먹고 있어요. 어렵기도 하고 오타도 많았고...(웃음)

이 : 저는 UCC가 생산되는 지점을 잡아야한다고 생각합니다. 에디터 같은 놈들이 쏟아내니까. 현석님은 실제 만드는 사람들의 인식변화 쪽을 생각하시는 것 같네요.

신 : “우리는 xml로 만든다”라는 가이드가 만들어지면 어떨까요?

이 : 비슷한 것으로 openmaru에는 누디즘nudism이라는 키워드가 있습니다.(웃음)

신 : 초보개발자를 잘 교육하는 것이 좋을 것 같습니다. 스킬은 쉽게 배울 수 있다. 1주일짜리 커리큘럼 정도로. 다만, 목표와 이념까지 깨닫는데는 좀더 걸립니다. 6개월 정도? 그리고 일반인들이 워드나 파워포인트를 만들 때부터 타이틀을 직접 그리지 말고제목1, 제목2를 활용하도록. 에디터가 중요하네요.(웃음)

-----------------------------------------------------------------------------------
이후에 좀더 개인적인 얘기들이 이어졌는데 여기서 줄입니다. openmaru 사무실까지 찾아와주신 신현석 님께 다시 한 번 감사의 인사를 드립니다. :)

- 정리 by Joyce