13개의 댓글이 있습니다.

1. yser 님의 말:

   2006년 9월 19일, (4:13)

   3번 항목에 대해서..
   개발 기간을 단축하는 면은 있지만 그 css라는 게 규모가 커질수록 다루기 어렵기 때문에, 시간이 지나서 숙달된다고 하더라도 이전의 막가파 코딩보다 항상 더 효율이 좋다고 할 수는 없습니다. 매크로미디어 사이트의 css를 보면 얼마나 고달픈지 알 수 있죠. 대신 규모가 작은 사이트는 css를 활용해 문서와 디자인을 분리한 게 많은 이득을 본다고 생각합니다.

   그리고 유지보수 측면에서 웹표준을 모르는 사람은 아예 그게 불편한 것인지도 인지 못할 겁니다. 왜냐하면 그게 당연한 것이라고 생각해왔고 그렇게 배웠기 때문입니다. 오히려 그런 사람들에게 ‘웹표준이란 지키면 이런 저런 장점이 있어요’라고 알려주면 뚱한 표정을 보이며 “그게 뭔데 그래?”라는 반응을 보이기 쉽죠. 다만 웹표준이 뭔지 알고 그걸로 이점이 있다는 걸 아는 사람이 지키지 못할 환경에서 일하면 답답함을 느끼게 될 겁니다.

   4번 항목에 대해서..
   실제로 만들게 되면 장애인용 페이지와 모바일용 페이지는 따로 기획해서 만들어야 할 수도 있습니다. 가령 컨텐츠가 PC 브라우저에서 볼 때는 그리 많지 않지만 화면이 제한되는 모바일에서는 그게 지나친 컨텐츠 크기가 될 수도 있습니다. css만 바꿔서 좁은 화면을 제대로 받쳐주지 못한다면 새로 만들어야겠죠. 물론 이 경우 이미 ‘문서화’ 되어 있는 html을 쉽게 재활용할 수는 있을 겁니다.

   >대기업들은 말로만 Global Standard 하지 말고 일단 웹사이트 부터 좀 뜯어 고치는게…

   새로 사이트를 만들 예산을 책정하고 그게 가져다 줄 이득이 충분하다고 판단되지 않는다면 굳이 바꾸려 하지 않을 것 같습니다. 현실적인 시점에서 보자면 지금은 그게 한계라는 것이죠. 어디 맡기고 싶어도 제대로 해주는 곳이 드무니까요. 이 점은 정상 교육을 제대로 받는 인력이 조금씩 늘어가면서 차차 해결되리라 봅니다. 그러나 문제는 지금의 몇 년차 물을 먹어서 ‘잘못된 교육을 받고 그게 왜 잘못된 것인지도 모르는’ 개발자입니다. 밑의 신입이 잘 알고 있어도 관행이 잘못 되면 똑바로 고쳐지지 않는 법이죠. 이게 참 타파하기 힘든 문제랄까요.

   p.s
   >웹사이트가 저 따위로 코딩되어 있는 것을 보고

   여기서 ‘저 따위’ 링크가 트랙백 링크로 잘못 되어있습니다. 저도 가끔 하는 실수인데 트랙백 링크로 접속했을 경우, 트랙백을 쏠 때 필요한 4개의 요소 값이 없다면 본문 글 링크로 돌려줬으면.. 싶은 때가 있더군요. ^^;

   그리고 내용과 관련 없는 사소한 겁니다만 ‘그것은 더 낳은 생산성을’에서 ‘나은’이 올바른 맞춤법입니다. 세심하게 정성 들여 쓴 글에서 옥의 티라고 생각되어 몇 자 적고 갑니다.
2. 정찬명 님의 말:

   2006년 9월 19일, (11:32)

   yser 님께서 언급하신 국내의 현실은 공감도 가고 이해도 갑니다. 하지만 작은 규모의 웹사이트에서 CSS를 사용하는 것이 더 효율적이라는 이야기와 별도의 웹사이트(장애인, 모바일) 문제에 관하여는 제 견해와 완전히 다르시군요. 그 부분은 절대 그렇지 않다고 생각 됩니다.

   # CSS는 웹사이트의 규모와는 관계없이 디자인 패턴과 관계가 있으며 기본적인 작업량을 필요로 합니다.

   CSS 의 업무량이 늘어나는 것은 CSS를 재사용하지 않고 하나의 웹사이트에 계속해서 새로운 표현을 추가로 생성해 내기 때문 입니다. 즉, 스타일가이드에 정의된 디자인 패턴을 재 사용하지 않고 페이지마다 새로운 형태의 디자인 표현을 하려고 한다면 그것은 CSS 보다 이미지로 처리하는 것이 낫겠지요. 100개 페이지를 가진 웹사이트에 CSS코딩만 이틀 걸린다고 가정합니다. 그렇다면 동일한 디자인 패턴을 가진 1,000개 페이지를 가진 웹사이트에는 얼마나 많은 CSS 코딩 시간이 필요할까요? 알고 계시겠지만 정답은 0시간 입니다. 따라서 웹사이트의 규모가 커지면 커질수록 웹 표준으로 전환했을 때 단축되는 작업효율이 높다는 것입니다. 어도비사의 CSS 코드는 여러명의 개발자가 공동작업으로 수행하고 있는 것으로 알고 있는데 과연 효과적으로 CSS를 사용하고 관리하고 있는지는 의문입니다. 설사 CSS 코드가 좀 과도하더라도 어도비사 같은 웹사이트를 CSS 없이 개발한다면 생각만으로도 끔찍한 상황이 벌어지겠지요. 오히려 작은 규모의 웹사이트는 CSS가 없더라도 수시로 쉽게 뜯어고치는 작업이 가능하기 때문에 당연히 규모가 큰 웹사이트 개발에서 진면목을 발휘한다고 봅니다. 결론은 웹사이트 규모와 CSS 작업기간은 직접적인 상관관계가 없으므로 규모가 커질수록 업무절감 효과가 높다고 말하는 것 입니다.

   #장애인용 페이지와 모바일용 페이지를 별도로 만들지 않기 위해서 웹 표준 코딩을 하는것 입니다.

   웹 표준은 기본적으로 접근성을 준수하도록 지침되어 있습니다. 즉, 다양한 환경을 지원하기 위하여 웹 표준코딩을 하는 것인데 장애인용 페이지와 모바일용 페이지를 별도로 만든다는 것은 티타늄 자전거를 한번 타고 버리는 꼴 입니다. 대대손손 물려주고 씨름선수가 타도 끄떡없도록 티타늄으로 만든 자전거를 왜 한번 쓰고 버리나요? 더구나 장애인용 별도 페이지는 장애인에 대한 역차별이며 장애인에게 전혀 도움이 되지 않습니다. 장애인용 별도의 웹사이트를 일반인과 동일한 콘텐츠로 구성하고 일반인 웹사이트 콘텐츠와 동일한 주기로 똑같이 업데이트 해주는 곳 혹시 보셨나요? 저는 보지 못했습니다. 더구나 음성장치 TTS 따위는 스크린 리더를 사용하는 장애인들에게 오히려 혐오스러운 존재 입니다. 또, 모바일용 웹문서에서 콘텐츠의 양이 많기 때문에 적절히 추려서 보여주는것이 낫다고 판단이 된다면 모바일 접속 화면을 위한 CSS파일 하나만 수정해서 우선순위가 낮은 콘텐츠는 숨기고 제목에 해당하는 링크만 보여주는 식으로도 얼마든지 처리할 수 있습니다. CSS만 바꿔서 좁은 화면을 처리하지 못한다고 하셨는데 CSS를 바꿔서 처리하지 못하는 콘텐츠라면 표나 그림따위가 있겠지요. 그럼 화면이 좁다는 이유만으로 표와 그림을 모두 제거해서 보여주게 되나요? 그건 아니라고 봅니다. 설령 화면이 좁아서 가로 스크롤이 생긴다 하더라도 동일한 콘텐츠를 보여주는 것이 더 중요하다고 생각 됩니다. 서로 다른 버전의 웹사이트를 구축하는것은 돈이 많으니까 괜찮다고 합시다. 더 심각한 문제는 그것들이 실시간으로 동기화 되지 않거나 유지관리 되지 않으며 버전에 따라서 콘텐츠의 내용이 다르다는게 문제 입니다.

   #기업이 항상 눈앞의 이익만 가지고 투자를 하지는 않는다고 생각 합니다.

   당장 눈앞에 보이는 이윤만 추구한다면 수시로 웹사이트를 개편할 이유도 없습니다. 웹 표준방식이든 아니든 웹사이트 개편이 향후 1년 이내의 매출에 얼마나 영향을 줄것인지를 정량적으로 측정할 수 있나요? 또는 직접적인 상관관계가 있을까요? 그건 아닐껍니다. 웹사이트 개편은 기업이미지 재고 측면에서 진행되는 경우가 많겠고 보통의 기업 관리자들은 웹의 전문가가 아니기 때문에 이런 분야까지 세심하게 인지하지 못하는 것이겠지요. 웹 표준을 알지만 당장 이윤이 남지 않기 때문에 안하는 것이 아니라 기업 관리자가 웹 표준을 모르기 때문이라고 보는 것이 맞는것 같습니다. 그리고 웹 표준으로 전환하고자 한다면 얼마든지 전환할 수 있습니다. 단지 yser 님 말씀대로 현재는 인력이 많지 않아서 웹 에이전시 에서도 초기 투자비용 및 인력에 대한 희소성의 댓가를 치를수는 있겠지만 그것은 의뢰하는 기업의 의지 문제이지 당장의 지출 때문은 아닐 껍니다.

   옥의 티 감사합니다. 부끄럽네요. ㅡㅜ;;
3. yser 님의 말:

   2006년 9월 19일, (12:45)

   조목조목 자세하게 짚어주신 점 감사합니다. 저도 써주신 부분을 공감하며 그렇게 생각하고 있습니다. 글을 쓰면서 반대 의견을 전개해보고 싶었달까요. 사실은 저렇게 적으면서도 이렇게 긍정적인 의견과 비교를 하고 싶다고 생각했습니다. 웹표준이 널리 알려지면서 오히려 이걸 알고 있는 사람들이 모르는 사람들에 대해 거리감을 조성하는 위기감을 느낀 적이 있습니다. 무조건 좋게만 보려고 하거나 파가 갈리는 모습, 분위기에 휩쓸리는 모습이 불안하게 보였던 것이죠.

   css는 분명 잘 관리하고 조직된다면 대형 사이트에서 상당히 도움이 되는 게 사실입니다. 비슷한 페이지를 공통 css 파일을 안쓰고 inline으로만 처리한 것과, css로 잘 정리해서 쓴 것은 큰 차이가 나겠죠. 유지 보수의 문제는 처음 기획할 때 잘 해두고 유동적인 부분은 그에 맞춰 만들면 될 것입니다. 그 점에 있어서 하신 말씀은 충분히 이해가 되고 또 그렇게 하는 게 당연한 것이라고 생각합니다. (지금은 비록 ‘당연한 일’이 아니지만요)

   써주신 답변을 보니 좀 더 긍정적으로 생각해도 되겠다는 생각이 듭니다. 솔직히 말해서 웹표준, 접근성을 지키고자해도 이런 문제로 인한 건 어떻게 할건데? 라고 하는 반박성 의견에는 뭐라고 답해야 할지 모르겠더군요. 웹표준을 지키는 것이 좋다는 것을 알고 있으면서도 정작 그걸 어떻게 설파해야 할지, 당장 현업에서 일하는 분들을 어찌 설득시킬지는 알 수 없었습니다. 항상 거기서 생각이 맴돌더군요.

   정말 아직 걸음마 수준이긴 하지만 그래도 이렇게 변화를 일으키고자 하는 분들이 있으니까 조금씩 나아질 것이라고 믿습니다. 드림위버 8 툴은 저도 기대를 했었는데, 웹표준에 관심을 가진 분이 집필에 참여한 책으로 나오게 되서 다행입니다. 기존의 툴을 바꾸는 시간과 배우는 기간 등 또 넘어야 할 산이 있지만 그런 노력이 모여서 점차 좋아지는 현실이 되기를 바랍니다. ^^
4. 정찬명 님의 말:

   2006년 9월 19일, (14:57)

   견해가 다른 사람들이 서로를 비판적인 시각으로 바라보는 것은 당연한것 같습니다. 그것이 인신공격적인 행태가 되면 안되겠지만 비판적인 견지가 서로의 논리를 더욱 견고히 한다는 측면에서 긍정적으로 생각 합니다. 한편 개인적으로는 그렇게 비판적인 견지를 취하는 것에 대하여 조심스럽게 행동하려고 노력하는 편입니다. 비판보다는 이해하고 수용하면서 나의 편이 되도록 만드는 것이 더 낫겠다는 생각 입니다.

   솔직히 저는 처음 블로그라는 것이 나타났을 때 대수롭지 않게 생각하면서 곧 사라질 쓰레기같은 서비스라고 생각 했습니다. 또한 웹 표준을 처음 접할 때의 느낌은 5년간 쌓아온 경력을 하루아침에 기본도 모르는 IT 개발자로 만들어 버린 사건 이었습니다.

   결국 제가 받아야 하는 비판을 논리적으로 벗어나려고 몸부림 칠때마다 더욱 상대방에게 끌려가게 되더군요. 호랑이를 잡으려고 호랑이 굴에 뛰어들어 갔다가 호랑이랑 같이 살고 있는 처지 랄까요? 지금은 블로그 없이는 못살고 웹 표준 마인드가 저의 경쟁력이 되었습니다.
5. 삐돌이 님의 말:

   2006년 9월 20일, (1:43)

   정찬명님의 글 잘 읽었습니다. 웹 표준 및 접근성에 대한 이득(이점)에 대해 설명할 수 있는 좋은 글을 써 주셔서 대단히 감사드립니다.

   저도 이 부문에 대해 사람들을 정말로 움직일 수 있게 하는 것이 무엇일까 큰 고민을 하고 있었지만, 정리를 잘 하지 못했던 것 같습니다..

   선생님의 글을 읽고 많은 부문을 느꼈습니다. 앞으로 저도 더 고민해 보고 더욱 쉬운 이야기들을 만들어 보도록 하겠습니다.

   앞으로도 좋은 글 부탁드립니다…
6. 정찬명 님의 말:

   2006년 9월 20일, (3:53)

   격려 감사합니다. 지난번 KADO 방문 때는(접근성 경진대회) 예약된 기차시간에 쫓겨서 인사도 못드리고 그냥 나왔는데 뒤늦게나마 용서를 구합니다. 처음있는 행사를 진행하느라 직원분들께서 고생이 많으셨던 것으로 알고 있습니다. 내년에는 좀 더 많은 기대와 관심속에서 열리게 되리라 확신 합니다. 저 역시 KADO의 좋은 행사를 부탁드립니다.
7. CunningWeb 님의 말:

   2006년 9월 22일, (4:48)

   웹표준의 경제학…

   웹표준의 경제학, 웹표준을 선택하는 것이 어째서 더 이득인가. 모델링을 통해 정량분석을 통해 웹표준의 이익을 계산함.

   ……
8. 유인동 님의 말:

   2006년 11월 9일, (1:43)

   좋은 글이 될지는 모르겠지만;;
   실제 적인 비용 절감 사례를 조금 적어보았어요^^;;
9. 정찬명 님의 말:

   2006년 11월 9일, (9:20)

   인동님, 트랙백을 걸어주시면 더 좋을것 같습니다. 바로 위 CunningWeb 처럼^^a
10. 차윤정 님의 말:

    2007년 12월 10일, (17:06)

    웹표준을 지키려고 공부를 시작하는데.. 정말 개발자와의 의견충돌이 만만치 않습니다.
    나름대로 드림위버를 이용한 웹표준 가이드를 보면서 열심히 코딩 햇는데..
    개발자 분이 저한테 그러시더군요..
    dtd에 utp-8은 왜쓰냐구..
    그래서 저는 당연히 웹표준을 지키려고 그랬습니다… 그랬는데…
    비웃음을 날리셨어요.. 차장님을 비판하려고 그러는건 아니지만, 기분이 좀 상했습니다.
    (웹에서 일하신지 어언 10년이 넘으신 차장님이십니다. 저보다 많은걸 알고계시는 분이라고 생각하니 감히 반론하기가 뭣했어요…)

    문제는 제가 맞아요.. 일단 저는 찬명님의 지침대로 utp-8을 쓰면, 언어가 통합되니까 거의 무조건 적으로 받아들였던 거죠.. 그래서 utp-8이 지금 굴러가고 있는 웹페이지에 적용되었을때의 문제점은 생각하지 못했으니까요..

    그래서 묻고 싶습니다. 개발자분 말로는 utp-8로 dtd를 정의했을때,
    익스프롤러의 인터넷 옵션에서 utp-8로 내보내기.. 그걸 해야만 깨지지 않는 한글을 볼 수 있다는데
    그게 정말인지, 그렇다면 우리는 내가 만드는 사이트가 어디서 보여질 것인지를 고려하고 한국에서 사용될때는 euc-kr을 사용해야 하는건지..

    아직 제가 웹표준을 공부한지 얼마 되지 않다 보니까,
    현업에서 어디서 부터 어떻게 적용해야 올바른 웹표준이 되는건지 정말 모르겠습니다.
    혼자서 하는 공부의 한계인가 봅니다.

    배움의 길로 들어서려고 하는 어린양을 보살펴주소서+_+;;;;;;ㅋㄷㅋㄷ
11. 정찬명 님의 말:

    2007년 12월 13일, (1:04)

    테스트 해보시면 아시겠지만 HTML 문자셋을 UTF-8 으로 정의하는 것과 IE의 ‘UTF-8 URL 보내기’ 옵션은 전혀 무관한 것으로 알고 있습니다. 개발자분께 문제상황을 테스트 해보시고 정확한 테스트 결과에 근거해서 판단할 것을 요청하시는게 좋을것 같습니다. 우선 UTF-8 문자셋을 사용했을 때 문자가 깨지는 상황을 재현해달라고 요청해 보세요. 테스트 결과를 제게도 공유해주실수 있을까요? ^^
12. 마약 님의 말:

    2009년 10월 12일, (0:09)

    와…정말 입이 쩍 벌어집니다. _ _;

    제가 2008년 후반 IT업계에 발을 들일때쯤 웹표준이 이슈화 된 줄 알았었는데, 이미 2년전부터 이렇게 훌륭한 자료가 있었다니…
    이런걸 아직도 안보고 뭐했나 모르겠습니다. ㅠㅠ…

    지금봐도 정말 대단하다는 말밖에 안나오네요…
    찬명님의 블로그 글 내용들 하나하나 다 읽어보려고 계획을 잡았습니다.^^;
    너무 유익한 글들이 많아서요…

    이미 예전부터 찬명님께서 가지셨던 견해들을, 현실이 잘 증명해주고 있네요. ㅎㅎ
    웹표준을 지킴으로써 거의 완벽에 가까운 접근성이 보장되는건 동감하지만, 요즘은 웹표준을 지킴으로써 접근성이 보장되지 못하는 부분이 다소 눈에 띄어 안타까움이 있습니다.
    뭐 그냥 개인적인 생각이예요 ㅋ
    제 역량미달 문제가 가장 크겠지만요^^;

    많은거 배워가도록 해주셔서 정말 감사드리고, 앞으로도 유익한 정보 부탁드릴께요 ㅎㅎ
13. 정찬명 님의 말:

    2009년 10월 14일, (2:28)

    마약님, 저도 처음부터 개념 가지고 쓴 글들이 아니라 중간 중간 오류나 잘못된 개념이 많습니다. 모두 비판없이 수용치 마시고 다소 비판적인 관점도 유지해 주세요. ^^; 그리고 다른 견해를 코멘트 해주시면 다른 분들께도 도움이 될껍니다. 감사합니다.

댓글 남기기

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