NARADESIGN

웹표준, 웹접근성, 유니버설디자인, HTML, CSS, UI, UX, UD


웹 퍼블리셔(웹 표준 및 웹 접근성 전문가)의 세 가지 기술.

본문 건너 뛰기

웹 퍼블리셔의 세 가지 기술.

웹 퍼블리셔는 ‘웹 표준 및 웹 접근성 전문가’ 라고 정의합니다. 또한 웹 퍼블리셔에게 필요한 기술을 저는 다음과 같이 정의하였습니다. 논문을 쓰는것이 아니므로 제 깜냥껏 구분했다고 생각하셔도 됩니다.

  1. 구조 기술(Structure Technique)

    Semantic Markup 과 Valid Markup 을 모두 구사하는 기술.

  2. 표현 기술(Rendering Technique)

    CSS 만을 이용하여 표현에 관계된 요소를 처리하고 이를 최적화 하는 기술.

  3. 호환 기술(Compatibility Technique)

    다양한 Vendor, Platform, Device 에 대하여 동일한 Content 또는 동일한 View 를 제공하는 기술.

구조기술(structure technique).

문법적으로 유효한 XHTML 을 구사하는 기술은 습득하기 쉽습니다. HTML 4 와의 차이점만 익히면 되고 W3C Markup Validation Service 를 이용하거나 Dreamweaver 와 같은 저작도구를 사용하는 경우 Dreamweaver 에 내장된 Markup Validation 검사도구를 이용하게 되면 자신이 잘못된 문법의 코드를 작성하였는지 쉽게 검증할 수 있기 때문에 이를 빠르게 교정할 수 있습니다. 하지만 Semantic Markup 기술은 기계가 이것을 검증해 주지 못하기 때문에 잘못된 마크업을 했더라도 교정받기가 쉽지 않습니다. 극단적인 예를 들어 h1 태그를 한번도 사용하지 않았더라도 기계가 실시하는 Validation 검사쯤은 쉽게 통과할 수 있습니다. 하지만 문서에 제목이 없다는 것은 분명 잘못된 마크업 입니다. 또는 ol, ul, dl 태그를 목록에 적절하게 사용하지 않는것도 역시 마찬가지로 잘못된 문법입니다. 기계는 Semantic Markup 까지 검증해 내는 능력이 없기 때문에 각종 Validation 도구들은 반쪽짜리 검사결과만 보여줄 뿐이라는 것을 명심하여야 합니다. Semantic Markup 기술을 익히려면 HTML 4 element 에 대한 표준 스펙을 다시 공부하여야 합니다. XHTML 1 element 는 HTML 4 element 와 같기 때문이며 XHTML 1 명세에는 element 에 대한 별도의 스펙을 따로 제공하지 않습니다. 웹 표준에 입문하고 Validation 검사를 통과하였지만 이것이 왠지 너무 쉽게 느껴졌다면 Semantic Markup 기술을 추가로 습득하시기 바랍니다. 대부분의 경우 이미 element 본래의 사용 목적을 알고 있으면서도 실무에 이것을 적용하지 못하는 경우가 많습니다. Semantic Markup 역시 그다지 어려운것은 아닙니다. 제목 요소에 대하여 h1~h6 태그를 순차적으로 사용하고 순차·비순차목록(네비게이션 포함)에 ol, ul 태그를 사용하며 정의목록은 dl 태그로 마크업 합니다. 더 나아가 그동안 잘 사용하지 않던 form 관련 label, fieldset, legend 등의 태그들도 적절하게 활용할 줄 알아야 합니다. 그 밖에 이곳에서 일일이 모든것을 열거할 수 없으므로 결국 다시한번 HTML 4 element 에 대한 표준 스펙을 공부하여야 한다는 말씀밖에 드리지 못합니다. 우선 내가 코딩할 페이지의 요소들 가운데 (X)HTML element 로 마크업 할 수 있는 것들이 무엇이 있는지 판단해 내고 가장 적절한 Markup element 를 찾아내어 그것으로 Markup 하는 습관을 들이는 것이 필요합니다. 가장 중요한 것은 의미가 있는 요소에 대하여만 적절한 element 를 이용하여 Markup 하라는 충고이며 표현과 관계된 것은 CSS 에서 처리하므로 표현 때문에 의미가 없는 요소에 대하여 Markup 을 입히는 방법은 피해야 합니다. 모르는 것을 새로 배우는 것보다 이미 알고 있는것을 바르게 교정하는 일 또한 쉽지많은 않을것이라는 충고를 곁들이고 싶습니다.

표현기술(rendering technique).

CSS 기술 또한 이미 여러분은 어느정도의 경지에 올라있을 줄로 믿습니다. 하지만 그것이 완전한 것인지에 대하여는 다시한번 검증되어야 합니다. 만약 아직도 디자인 표현을 위하여 의미 없는 (X)HTML 마크업을 페이지에 넣었다면 그것은 아직 (X)HTML 과 CSS 라는 언어의 목적을 완벽하게 이해하지 못한 것입니다. (X)HTML 은 문서의 구조를 정의하기 위한 용도로만 Markup 되어야 하며, 표현을 위한 요소는 모두 CSS 로 처리되어야 합니다. ‘(X)HTML=구조언어’ 이고 ‘CSS=표현언어’ 라는 것을 머리속에 확실하게 집어넣은 상태라면 어떤 요소를 ‘마크업’ 하거나 ‘표현’ 하고자 할 때 ‘의미가 있고 없고’ 에 따라서 적절한 언어를 선택하게 될 것입니다. 그렇습니다. 모든 Markup 은 의미를 갖습니다. 의미가 없는 것은 ‘표현’ 이며 이러한 표현요소는 모두 CSS 로 처리되어야 합니다. 한 가지 구체적인 예를 들어보겠습니다. 웹표준 방식으로 제작된 웹사이트를 뜯어보면 의미를 포함하고 있는 콘텐트는 모두 적절한 element 로 마크업 되어 있고 의미가 없는 단순한 표현요소는 CSS 코드에 의하여 layout 이 결정되거나 background 로 처리되어 있습니다. 이것은 Markup 이 기계 또는 사람에게 어떤 의미를 전달하고 문서의 구조를 결정하는 언어라는 것을 완벽하게 이해한 상태에서 처리된 코드 입니다. CSS 를 잘 다루려면 일단 (X)HTML 을 이용한 Semantic Markup 과 Valid Markup 을 적절하게 다루는 기술이 선행되어야 함을 의미합니다. 진정한 CSS 전문가는 CSS 보다 (X)HTML 전문가라고 말할 수 있으며 검증된 (X)HTML 코드를 이용하여 이것을 자유자재로 표현할 줄 아는 사람입니다. 또한, CSS 전문가는 해당 문서가 어떤 환경에서도 동일한 Content 와 View 를 제공할 수 있도록 Vendor(브라우저)의 특징(버그)에 대하여도 경험적으로 체득한 사람이라고 말할 수 있습니다. CSS 의 스펙을 모두 터득하였다고 할지라도 (X)HTML 의 표준 스펙(Semantic Markup + Valid Markup)을 적절하게 구사하지 못한다면 이 역시 반쪽짜리 표준 입니다.

호환기술(compatibility technique).

앞서 설명드린 구조기술과 표현기술은 W3C의 표준스펙이 담긴 문서를 학습하고 실무에 이를 적용한 뒤 주변의 고수들로부터 feedback 을 받아보면 얼추 감을 잡을 수 있게 됩니다. 물론 그 과정조차 쉽지 않을 수 있습니다. 하지만 지금부터 설명하려고 하는 호환기술은 조금 더 어렵습니다. 구조기술과 표현기술을 학습한 그대로 실무에 적용하면 그 댓가는 정직하게 돌려받을 수 있습니다. 하지만 호환기술은 예측 불가능 합니다. 저는 위에서 호환기술을 정의 할 때 ‘다양한 Vendor, Platform, Device 에 대하여 동일한 Content 또는 View 를 제공하는 기술’ 이라고 설명하였는데 이 가운데 현실적으로 가장 자주 만나게 되는 문제는 바로 Vendor 간 호환성 문제(‘Cross Browsing’ 또는 ‘브라우저 호환성’ 이라고 부르는 것들..)입니다. CSS 렌더링 표준을 잘 지원하고 있는 Safari2 나 Opera9 에서 완벽하게 렌더링 되더라도 그 밖의 대중적인 브라우저(IE 6~7, FF 2)에서는 버그 때문에 이것을 동일하게 렌더링 시켜주지 않고 있으며 개발자들은 Vendor 간 호환성 유지 기법을 따로 익혀야 하는 것입니다. 실제로 어떤 웹 브라우저에 어떤 버그가 있다는 것을 뻔히 알고 있음에도 불구하고 그 해결 방법은 항상 동일하지 않고 상황에 따라 다릅니다. 때문에 이것은 예측 불가능한 문제인 동시에 경험적으로 대응할 수 밖에 없는 ‘기술’ 이라고 설명할 수 있을것 같습니다. 또한 Opera Mini 와 같은 Mobile 전용 웹 브라우저에서도 PC에서 제공받을 수 있는 Content 를 동일하게 제공할 수 있는 장치(Device)독립성 보장 역시 마찬가지 이유로 ‘기술’ 이라고 정의 합니다. Platform 독립성에 대한 문제는 보통 Vendor 호환성과 Device 독립성 문제를 해결하면 자동으로 해결된다고 생각합니다. FF의 호환성을 보장하면 Linux 에서도 볼 수 있게 되고 Mobile Device 에 대응하도록 코딩하면 이 역시 Mobile 장치의 Platform 에 독립적인 페이지가 되기 때문입니다. 이러한 호환기술은 각각의 주요 웹 브라우저(IE/FF/OP)에 대한 표준지원현황 표를 참조할 수도 있지만 누구도 이것을 감히 외우려고 하지는 않을 것입니다. 개인마다 경험치의 차이는 있겠지만 적절한 수준의 호환기술을 익히는 데에는 적지않은 시간이 필요할 것이며 이것을 익히기 위하여 별도의 시간투자는 필요치 않습니다. 다른사람보다 얼마나 더 많은 시행착오를 격었는지 그것이 중요합니다. 시행착오.

결론

‘웹 표준-웹 접근성’ 의 관계는 ‘하위목표-상위목표’ 관계이며, 웹 표준 및 접근성 전문가는 ‘구조기술, 표현기술, 호환기술’ 에 대한 이론적인 지식과 실무적용 그리고 시행착오를 통하여 탄생하게 됩니다. 그리고 지금까지는 그 누구도 (X)HTML 코딩을 기술이라고 표현하는데 주저하였지만 (X)HTML 코딩은 Art 맞습니다. 스스로를 웹 퍼블리셔(Client Side 언어를 다루는 모든 직군으로서 UI개발자, 디자이너, 코더, 프로그래머…) 라고 생각하신다면 웹 1.0 시대에 학교와 학원에서 배운 것들을 과감하게 갈아 엎으시기 바랍니다. 지금 자신의 모습에 적당히 만족하신다면 꼭 그러지 않으셔도 됩니다. 절대로 강요하고 싶은 생각은 없거든요.

분류: CSS,웹 디자인,웹 접근성,웹 표준 | 2007년 1월 2일, 11:36 | 정찬명 | 댓글: 18개 |
트랙백URI - http://naradesign.net/wp/2007/01/02/99/trackback/

18개의 댓글이 있습니다.

  1. miriya 댓글:

    브라우저의 렌더링 특성을 모두 만족하여 각종 브라우저에서 오차 없이 전부 동일하게 보이는 웹페이지가 가능할까요?
    IE, FF, Opera, Safari 정도라면요. 요즘 너무 혼란스럽습니다.

  2. 정찬명 댓글:

    지금 생각해 보니 정작 중요한 것은 1px 의 오차도 허용하지 않는 동일한 View 가 아니라 바로 Content 라는 것을 강조하지 못했다는 생각이 듭니다. 자세히 살펴볼 기회는 없으셨겠지만 제 블로그도 주요 4대 브라우저에서 각각 조금씩 다릅니다. 하지만 다기종의 웹 브라우저 렌더링 화면을 스크린샷으로 제공해도 아마 보통 사람들은 그 차이점을 인지하기 쉽지 않을 것입니다. 왜냐하면 제 블로그의 디자인은(디자인이라고 부르기도 뭣하지만) 1px 의 오차쯤은 무시해도 좋을만큼 융통성 있게 디자인 되었기 때문입니다. 각종 브라우저에서 한 점의 오차도 없이 전부 동일하게 보이는 웹페이지는 거의 불가능에 가까울 수 있겠지만 그 오차의 허용범위 내에서 융통성 있게 디자인 하는 것은 가능하다는 말씀을 전해드리고 싶습니다. 저같은 경우 우선은 1px 정도는 무시해도 좋을만큼 융통성 있는 디자인을 구상하고 그럼에도 불구하고 그것을 꼭 맞춰야 하는 경우에는 어떻게 해서든 맞춰내고 있습니다.

  3. 윤좌진 댓글:

    개발자에서 웹퍼블리셔로 전환하면서 요즘 많은 혼란에 휩싸여있었는데 힘이 나는 글입니다^^

  4. 신현석 댓글:

    “오차”는 에러(error)를 말하는데 당연히 오차 없이 동일하게 보이는 웹페지를 만들 수 있습니다. 다만 OS나 폰트가 달라서 나타나는 차이는 OS고유의 특성이기 때문에 동일하게 할 수도 없고 동일하게 하는 것이 무의미 합니다. “동일하게 보이는 웹페이지”에서 “동일함”의 의미를 과거의 1px도 어긋나지 않는 동일함이 아닌 사용자의 다양성을 인정한 다음에 재해석 해봐야 합니다.

    브라우저마다 가지고 있는 버그 때문에 “과연 이게 제대로 하고 있는 것인가?” 라는 혼란을 느낄 수 있습니다. 그런 분들을 위해서 만박님께서 CSS 마스터 전략을 번역하셨으니 읽어보시면 도움이 많이 되실 것입니다.

  5. hooney 댓글:

    좋은 글 감사합니다.

    뭐든지 잘 하는, 제대로 하는 것은 어렵다고 생각합니다. 경험은 무척 소중하죠.

    다만, 최근 웹 표준 기술이 특정 상황(IE의 flicker 버그)에 대한 대처법으로 보여지는 게 아쉽습니다. 많은 웹 종사자들이 “A라는 상황은 a라는 방법으로 해결한다” 처럼 틀에 밖힌 공식으로 웹 표준을 받아들이는 것 같습니다.

    마치 수학에서 개념원리가 부족하다고 할까요. “A라는 상황이 발생한 이유를 명확히 이해하며, a, b, c, d라는 다양한 해결 방법들 중에서 여건 상 a라는 방법을 이용하는 게 가장 적절하다”라고 다가서는 게 필요하다고 생각해요.

    제가 넘 많은 걸 바라는 건 아닌지 모르겠네요. ㅎㅎ

  6. 정찬명 댓글:

    좌진님께, 웹 코더도 별로 없지만 아직까지 웹 퍼블리셔는 더욱 흔치 않은 직군이라고 생각됩니다. 웹 퍼블리셔가 앞으로 더욱 유망한 직군이 되려면 지금 선구자의 위치에 서있는 분들께서(좌진님 같은..) 현재의 분야를 확고한 전문영역으로 인정받을 수 있도록 가치를 만들어 주셔야 한다고 생각합니다. 그리고 현재의 위치에서 좌진님만의 실적을 계속 만들어 내는 것이 바로 그 가치라고 볼 수 있을것 같습니다. 힘내세요!

    현석님의 ‘동일함에 대한 재해석’ 에 동의 합니다. 비록 조금 다른 View 를 제공할 지언정 동일한 Content 를 제공하는 것을 더욱 중요하게 생각해야한다는 사실을 추가하고 싶습니다. 우선 ‘동일’ 하여야 하는 것은 Content 이며 View 는 그 다음이어야 할 것입니다. 그리고 아주 극단적인 경우가 아니고서는 View 를 ‘동일’ 하게 처리하지 못했다고 해서 ‘웹 표준 맞어?’ 또는 ‘접근성이 떨어지네?’ 라고 말 할 수 없습니다. 하지만 Content 가 ‘동일’ 하지 않다면 그것은 ‘접근성이 떨어지는군요’ 라고 말할 수 있습니다.

    훈님이 말씀하신 대로 웹 표준의 목적이 단지 ‘Cross Browsing’ 에 있는 것처럼 오해하는 분들이 계신것 같아 저도 걱정 됩니다. ‘Cross Browsing’ 은 웹 표준의 궁극적인 목적이 아니며 웹 표준이 주는 혜택 가운에 ‘일부’ 에 불과하다는 것을 지속적으로 알려야 겠다는 생각도 들구요. 그리고 저 또한 코끼리 다리를 코끼리의 전부라고 생각 했었기에 시행착오도 많았고 앞선 사람들의 도움을 많이 필요로 했었습니다. 많은 분들이 개념찾아 저처럼 안드로메다로 떠나기 전에 안드로메다를 지구 가까이로 당겨와야 겠다는 생각이 듭니다. 앞선 분들이 격었던 시행착오를 최대한 줄이고 최대한 빠른 시간에 원리를 깨우칠 수 있다면 좋겠습니다.

  7. miriya 댓글:

    네^^ 좋은 댓글들 감사합니다.
    브라우저마다 제각각 다르게 보이는 사이트를 보고 해당 회사에 일일히 리포팅을 해야 하나 고민했었지요.
    앞으로는 중대한 기능적인 결함이 아닌 이상 그냥 넘어가려고 합니다.^^
    주변에 웹표준을 지키면 모든 브라우저에서 다 동일하게 보이는줄 아는 분들이 아직 많아 안타깝습니다.

  8. deute 댓글:

    동일하게 보여지는건 중요합니다.
    브라우저에 따라 1px 이 어긋나는 어쩔 수 없는 경우에 그것이 잘 어우러 질수있게 디자인을 하는것도 하나의 목표가 되겠죠….
    제생각은 최대한 동일하게 보여진뒤 브라우저로 약간씩 어긋나는 부분은 최대한 티안나게 하는게 좋다고 생각해요 :)

    당연히 웹표준 = 크로스 브라우징 이라 생각하는 사람들한테 잘 알려주는 방법을 생각해 봐야겠죠:)

  9. 홍길동 댓글:

    정말 좋은 정보 감사합니다. 저는 웹표준이라고 해서 걍 표준이구나 라고 생각만 했는데, 글을 읽어보니 저의 생각에 많은 착오가 있었던 거 인정합니다. 웹표준과 웹접근성 구조와 표현 다시 한 번 생각해 보게 되는 말씀 많이 해 주신거 같습니다.
    저도 웹표준을 지키면 모든 주요 4개의 브라우저에서 동일하게 보이는 것이 당연한 줄알았는데 그것이 아니더라고요..
    아무튼 계속해서 웹 표준안에 대한 논의가 진행,새로운 표준이 마련되고 있으니 앞으로 지속적인 공부만이 필요할 거라고 생각합니다.

  10. 정찬명 댓글:

    홍길동님, 반갑습니다! 설마 실명은 아니시죠? ㅎㅎ. 보통 코딩할 때 DB에서 사람이름 출력되는 부분에 ‘홍길동’ 이렇게 많이들 쓰시잖아요.(진짜 실명이시라면 이건 제가 실례하는거죠 ㅡㅜ;) 여하튼 도움이 되셨다니 무척 기쁩니다. 공부 하실 때 도움이 될만한 웹사이트를 하나 소개시켜 드려도 될까요? 웹 표준이나 접근성에 대하여 더 깊은 지식을 얻을 수 있는 곳으로 신승식님의 블로그를 추천합니다. http://gregshin.pe.kr/ 신승식님의 웹사이트 중 Universal Design 이라는 분류에는 관심있어 하실만한 내용들로 가득 차 있습니다. 이미 알고 계시겠죠 ^^a 좋은 하루 되시구요!

  11. JoyFull!! 댓글:

    웹퍼블리셔의 세가지기술…

    웹 퍼블리셔의 세 가지 기술. 웹 퍼블리셔는 ‘웹 표준 및 웹 접근성 전문가’ 라고 정의합니다. 또한 웹 퍼블리셔에게 필요한 기술을 저는 다음과 같이 정의하였습니다. 논문을 쓰는것이 아…

  12. 눈먼자들의 도시를 통해 본 웹접근성…

    눈을 떠도 감은 것만 같이 아무 것도 보이지 않았던 시골의 밤. 처음엔 단지 시야가 확보되지 않아 답답한 마음이 들었습니다. 눈을 꿈뻑이다가 내가 눈을 뜨거나 감아도 보이는 것에는 그다…

  13. 또이또이 댓글:

    이제 코더가 된 사람입니다~
    제 목표는 퍼블리셔가 되는건데요!!
    퍼블리셔란게 어떤건지 잘몰랐던것 같습니다!!
    이제야 약간 이해할수 있게되었어요^^;ㅋㅋ
    좋은 정보감사하고 글 퍼가겠습니다!

  14. KaGuRa 댓글:

    웹 퍼블리셔라는 직군에 매력을 느끼게 하는 글이네요
    적어도 제게는요 ^^
    잘 읽고 갑니다.

  15. 정찬명 댓글:

    서버측 개발 하시는 분들도 CSS는 재미있으실꺼에요 ^^;

  16. […] This post was mentioned on Twitter by Yee Sangmee, Yee Sangmee. Yee Sangmee said: @Sw_J "다른사람보다 얼마나 더 많은 시행착오를 격었는지 그것이 중요합니다. 시행착오" : NARADESIGN:BLOG » Blog Archive » 웹 퍼블리셔(웹 표준 및 웹 접근성 전문가)의 세 가지 기술. http://tln.kr/23upf […]

  17. 익명 댓글:

    전 회사가 브라우저만다 1픽셀의 오차를 허용하질안내요.
    힘들어요 T.T

  18. 승승 댓글:

    좋은 정보 감사합니다. 눈팅만하다가 글한번 남깁니다^^ㅋ

댓글 쓰기

전송된 글이 나타나지 않는다면 필터링 된 것입니다. dece24앳gmail.com 으로 메일 주세요.
(X)HTML 코드 사용이 가능하지만 소스 코드 출력을 원하시면 <꺽쇠>는 [괄호]로 변환하여 작성해 주세요.

필수 아님

필수 아님