며칠간 포토샵 HTML/CSS를 가지고 웹 디자인을 하고 있다. 경기불황의 한파 때문에 닥치는 대로 일해야 하는 상황이라서 웨사이트 디자인과 5년만에 PHP도 하고 있다. PHP는 그 동안 발전해온 RoR을 흉내낸 듯한 프레임워크들이 많이 있어서, 공부하고 사용해보는 재미가 쏠쏠하다. Eclipse에서 동작하는 IDE도 거의 환상적이다. 하지만 이놈의 HTML/CSS를 가지고 디자인 하는 작업은 5년전이나, 10년 전과 다를바 없이 노가다 이다.

 

15년 전에 처음 netscape 0.x대에서 HTML을 만들땐 태그도 몇개 없었으니까 금새 배우고 쉽게 만들 수 있었던 것 갈다. 그런 것이 IE가 나오고 버전이 올라가고 하면서 10년전쯤에는 IE와 넷스케이프에서 다 보이는 사이트를 만들어주세요라는 고객의 요구가 가장 괴로운 주문이었던 것 같다. 심지어 HTML을 따로 분리해서 만드는 경우도 있었으니까.

그리고 한참이 지나서 IE가 브라우저 시장을 평정을 했을 때는 잠시 편했다. 드림위버 같은 스파게티 태그를 쏟아내는 툴 덕분에 디자이너로부터 HTML코드를 받아서 정리해서 쓰려면 좀 고역이긴 했지만, 그래도 브라우저 하나에서만 잘 동작하면 됐으니까.

그러던게 다시 파이어폭스가 등장하고, 그동안 해왔던 HTML과 CSS작업엔 표준이 아닌 것도 많으니 웹표준을 지키자는 운동도 일어나고 하는듯 하더니 다시 브라우저들이 쏟아져 나오기 시작했다.

IE5, 5.5, 6, 7까지 오는 사이 Firefox 1,2,3가 등장했고 최근에는 IE8까지 나타났다. 맥 사용자도 늘어나면서 Safari도 끼어들기 시작했다.

문제는 브라우저의 버전에 따른 부분적인 표준호환성, 렌더링 버그, 비표준 모드 등등을 이유로 같은 디자인을 해도 브라우저마다 다르게 보이는 일이 일어나는 것이다. 그래서 인터넷을 다니다 보면 각종 IE hack이나 디자인 땜방기술들이 눈에 띄게 보이기 시작했다. 하나의 HTML/CSS로 브라우저에 상관없이 동일하게 보이게 하려고 별 희한한 코드를 삽입하고 표준과 비표준을 적절히 버무려 넣어서 브라우저에 상관없이 최대한 비슷하게 보이려고 애를 쓰는 듯 하다.

문제는 나같은 얼치기 HTML/CSS 디자이너가 그런 것을 다 알고 만족시키기에는 너무 해야 할게 많고 복잡하다는 사실.

어휴.

 

어제 이런 저런 태클 때문에 시간을 많이 뺐겨서 밤 늦게까지 화면 작업을 하고 브라우저에서 확인을 하는데 최근에 받은 IE8에서 돌려보니 같은 IE에서 조차 IE8모드와 IE7모드에서 다르게 보인다는 것을 알고 바로 충격. 파이어폭스3와 구글 크롬에서도 미묘하게 달라지는데, 것참.. 초고급 디자이너, HTML/CSS전문가들이 포진해있는 유명 사이트들은 그래도 거의 비슷하게 보이는데.. 어떻게 한 것인지. 툴을 써서 Layout과 CSS를 살펴보려고 하지만, 수도 없이 중첩(이게 무슨 비법일까?)되어 있는 DIV들과 난생 처음보는 CSS설정(이런 것도 있었나 싶은게 종종 보인다)이 담긴 파일들을 어떻게 해석해야 할지 막막하다. 전에 잠시 구독했던 N사디자인블로그(N사 웹디자이너 블로그인데 자사 블로그 시스템을 안쓰고 워드프레스로 되어있어서 신기하게 생각했던)에 보면 새로운 브라우저가 나올 때마다 매번 그 브라우저(더 표준을 잘 지킨다고 하는데도)와 호환성을 얻기 위해 이런 저런 수정과 삽질을 해야 한다고 분석한 글들이 올라오는 것을 본 기억도 난다.

 

그나마 이번 작업은 고객과 잘 협상 끝에 많이 사용하는 IE(6,7이면 되겠지? 설마 5.5까지?)에서만 잘 보이면 된다고 타협을 보았으니 좀 다행이긴 한데…

 

삽질을 한참 하다보니 이런 생각이 들기도 했다. 자기 기준에만 맞추면 되는 플렉스나 AIR, X-Internet, 실버라이트 등으로 디자인 하는 사람들은 얼마나 좋을까 부러워졌다. 그러면서 강력하게 적용도 되지 않는 HTML, CSS의 표준 따위가 도대체 무슨 도움이 되는가 하는 투정도 부리고 싶어졌다. 차라리 HTML표준이 없이, IE디자인 방법, 파이어폭스 디자인 방법이 다 제각각이고 표준 호환성 싸움 없이 각자 자기 기준대로 쭉 밀고 갔다면, 그냥 콕 찝어서 한가지 제품에 대해서만 디자인을 하면 되지 않았을까 싶기도 하다.

물론 표준이 중요하고 없는 것보다 훨씬 나은게 사실이겠지만.. 저 비표준과 멋대로 만든 확장모드로 자기 제품만 띄울려는 기업의 악덕(또는 무식) 공세 덕분에 오늘도 밤잠 못자는 나같은 허접 디자이너들은 오늘도 억울하게 고생을 한다. 얼마전 등장했던 "IE7(표준모드를 잘 지원하는 브라우저)으로 업그레이드 해서 개발자좀 살려주세요"라는 운동이 떠오른다. 블로그에 배너라도 달까보다.

 

표준이 존재하긴 하지만 자신들 만이 제공할 수 있는 표준의 확장기능에 더 신경을 쓰고, 고객에게 사용을 은근히 강조해서 결국 호환성을 떨어뜨리는 EJB/WAS시절의 모습을 생각해봐도 그렇고, 꺼꾸로 오픈소스 등으로 자신들의 독점기술을 먼저 공개해 인기를 끌게 한뒤 그것을 꺼꾸로 표준으로 인정받으려고 애쓰는, 그러나 표준화작업으로 축소된 기능만을 표준에 올려 결국엔 다시 표준호환이라는  의미가 떨어지게 만드는(JPA에 대한 스프링의 삽질이 그탓이라는데…) 그런 일들도 자바진영에서는 적지 않게 보이고…

아무튼 표준이라는 것이 기대와는 달리 개발자/디자이너를 더 피곤하게 만드는 세상에서 살고 있는 것 같다.

 

비주얼 툴로 디자인하면 완벽한 표준호환에 각종 브라우저 호환성까지 보장되는 HTML/CSS코드가 나오는 그런 툴을 만들면 대박이지 않을까?

 

나는 다시 삽질하러 간다. 오늘은 디자인 끝내고 내일부터는 재밌는 PHP Codeigniter 프레임워크로 개발을 해봐야겠다.

Related posts:

  1. 유쾌한 이슈처리 재촉 메일

Facebook comments:

to “차라리 표준이 없었더라면”

  1. 고생이 많으시네요. IE에서만 돌아가면 된다고 타협을 보셨군요~. 뭐 다른 브라우져에서 디자인은 깨져도 기능만 제대로 돌아간다면 문제 없겠죠.

  2. 표준이 생겨서 빚어진 문제라기 보다는 브라우저 벤더들이 독자적으로 발전시켜온 기술들을 표준이라는 얼개로 묶는 과정이고 아직은 그 과정이 진행중이고 그에 따른 진통을 체험하셨다고 생각하셨으면 좋겠네요.

    대부분의 진통은 브라우저가 CSS를 해석하는 방식의 차이에서 발생합니다. HTML은 사이트가 화면에서 어떻게 보이느냐랑은 관계가 없거든요. :)

  3. 뭘 새삼스럽게 CAPS 진행할때도 그랬구먼..
    형이야 HTML/CSS부분만 그러겠지만..

    얼치기 Java개발자인 나는 Java부분에서도 “차라리 표준이 없었더라면..” 하는 생각을 할때가 많아. ㅋㅋ

    PHP는 그런면에서 고맙지..

    여튼 화이튕이야~

  4. ㅎㅎㅎ 초고수도 역시 HTML/CSS에서 괴로움을 토로하시는군요! 요즘에는 웹퍼블리셔라는 (예전에 HTML 코더 비스므리한..) 신종 직업도 뜨고 있다는 이야길 들었습니다.

    CodeIgniter 참 좋죠. CakePHP나 젠드보다는 어딘지 모르게 빈약해 보이긴 하지만, 매우 유연하고 가볍습니다. 저도 한 반년 전부터 CI를 써오고 있어서 기쁜 마음에 답글 달아봅니다. ^^

  5. 김군우씨와 일하면 해결됩니다. ^^

  6. 헉! 오늘은 좀 위험한 말씀을 하셨네요…ㅡ_ㅡ;;;

    표준이 있는게 문제가 아니라 브라우저들이 잘 지키지 못해서 그런게 아닐까요?
    이건 Java쪽 J2EE표준이 삽질한 것하고는 경우가 다른거 같은데요.
    Java는 그 몹쓸 J2EE 표준을 안 지켜도 결국 Java라는 틀안에서 만드는거라서
    크게 문제될 일이 없… 는 정도가 아니라 개발자나 고객 모두 이익을 보지만,

    브라우저 쪽은 전혀 다른 얘기가 되겠죠…ㅡ_ㅡ;
    브라우저마다 개판으로 보이는게 표준이 있어서 그런게 아니라
    표준을 안 지켜서 그런거 아닌가요?

    표준이 없다고 가정을 해보면,

    브라우저 별로 천차만별 다 다르게 보임 => 해결하려면, 브라우저 별로 View를 개별적으로 생성

    그럼 표준이 있으면 개별적으로 만들수 없는건가요?
    아니죠. 개별적으로 만들수 있죠. 근데 더 좋은건 브라우저들이
    표준을 지켜서 한쪽에서 돌아가면 다른곳에서도 잘 돌아가는
    웹페이지 생성이 가능한게 좋겠죠.

    결국 표준과는 상관없는 얘깁니다. IE에서만 보이게 만들건
    FF에서만 보이게 만들건 그건 표준이 있건 없건 가능한 얘기구요.

    표준이 있고, 브라우저들이 이걸 지키면, 개발자는 표준만 따르면
    Cross Browsing이니 하는건 신경 안 써도 되겠죠.
    고객들도 원하는 브라우저를 쓰면서 제대로된 화면을 보니 좋겠구요.

    결국 시초는 과거에 그넘에 M$가 독점하려고 지들 멋대로 나가면서…
    M$가 얼마나 삽질하고 있는지는 이걸…ㅡ_ㅡ;
    en.wikipedia.org/wiki/Acid3
    IE쪽 결과물의 참담함을 한번 보세요.

    아, 그리고 Toby님 혹시 이거 보셨나요?
    http://www.mozilla.or.kr/docs/web-developer/web-standard-guide-2005-appendix.pdf

    브라우저 마다 미묘한 차이야 어쩔수 없겠지만,
    사실 고객도 그런 미묘한건 크게 신경 안 쓸거 같구요.
    (로그인 버튼이 password field랑 1밀리 떨어졌건 2밀리 떨어졌건 고객이 불만 접수할 일은 없지 않을까요?ㅡ_ㅡ?)
    암튼 저 문서 꽤 도움 되더군요.

    말씀하신 WYSIWYG툴이 없는건 아닙니다만,
    만들고 나서 브라우저 호환성까지 좋은거는 대부분 Ajax용이라서…
    사실 개인적으로는 Accessibility 문제만 해결이 잘 된다면,
    JavaScript Framework를 사용하는게 여러 모로 훨씬 이익인거 같습니다.
    사이트도 이뻐지고, 특정부분은 속도도 빨라지고
    무엇보다 Cross Browser문제는 Framework에서 신경 쓰기 때문에
    개발자의 부담이 아주아주 줄어들죠.

    전 Java와 Ajax로 웹어플 개발을 했는데요.
    저는 Server-side Java이고, 같이 일하는 친구가 Ajax쪽을 맡았거든요.
    JS UI library 안 쓰고 개인적으로 UI Library를 만들어 썼어요.

    문제는, 뭐 하나 바뀔때마다 Browser별로 안 돌아가거나, 심지어 같은 브라우저도
    버전업 되면서 안 돌아가고…ㅡ_ㅡ; UI library 안 쓴걸 정말 후회 했었죠.
    사실 이친구는 쓰려고 했는데, 프로젝트 중간에 조인한 거라서
    이미 전임자가 UI library 안 쓰고 개발한 상태라서, 다 갈아엎을수도 없고…

    그래도 결국 FF2+, IE7, Opera 9.5+, Safari3+, Google Chrome에서
    돌아갈수 있게 만들었는데, 만드는 동안 짜증나는건 좀 많았죠… :)

    특히 문제가, 다른 브라우저들 다 정상인데, IE만 꼭 말썽을…ㅡ_ㅡ;

    아…
    그리고 혹시 Rich Ajax Platform (RAP) 아시나요?
    간단하게 설명하면,
    SWT를 써서 Java로 만들어진 UI를 JS library인 qooxdoo를 이용해서
    브라우저쪽에서 렌더링해서 HMTL페이지로 만들어 주는건데,
    SWT UI와 거의 1:1 대응을 해서
    데스크톱 어플을 그대로 웹어플로 만드는 효과를 기대할수 있죠.

    뭐 JS UI library쪽으로 눈을 돌리면 쓸만한게 꽤 많죠.
    RAP에서 기본 JS 엔진으로 쓰는 qooxdoo말고도 ExtJS나 Ext GWT
    그리고 Spring은 Dojo를 쓰던가요?

    RAP와 Ext GWT는 이걸 보시면 좋을거 같구요.
    http://www.eclipsecon.org/2008/sub/attachments/RAP_vs_GWT__Which_AJAX_Technology_is_for_You.pdf

    아 근데… 이미 다 알고 계신 것들을 가지고, 저혼자 삽질하고 있는거 같기도 하고…ㅡ_ㅡ;;;
    암튼, 계속 좋은글 써 주셨으면 하는 뜻으로 몇삽 떴습니다…ㅡ_ㅡ;;;

  7. 혹시 JavaScript Library 쓰실맘이 있으시다면,
    http://en.wikipedia.org/wiki/Comparison_of_JavaScript_frameworks
    이게 좀 도움이 되지 않을까 합니다만…
    JS Framework별로 기능, 특성 비교에,
    데모링크까지 있고, 브라우저 서포트까지 한눈에…

  8. Kevin/ 이미 jquery를 쓰면서 만족하고 있습니다. 정보 감사합니다.

  9. 그러시군요. 저도 jQuery 쓰고 있는데… :)
    근데, 이거 참 편하고 좋긴한데,
    UI쪽은 좀 부족한거 같아서요…
    이번에 저도 다른 녀석 한번 써볼까 하고 생각 중입니다.

  10. Toby님,
    개인적으로 아는 분도 아닌데 이런 질문드리기 좀 그렇습니다만,
    제가 요즘 ORM 선택을 놓고 고민중인데요.

    Hibernate나 JPA 중에 하나를 고르려고 하고 있습니다만,
    아, 물론 Spring하고 같이 쓰려구요.

    죄송한 말씀이지만, 혹시 언제 시간이 되시면
    간단하게라도 둘중에 어떤쪽을 어떤이유로 추천하신다거나

    혹은 간략하게 장단점 및 차이점 비교 같은거라도
    해주실수 없을까요?

    바쁘실테니 자세히는 바라지 않고, 간단하게 이러이러 해서
    이쪽이 Spring하고 쓰기 좋다거나
    이러이러해서 향후 전망이 불투명하니 이쪽을 쓰라거나…

    Gavin King이 JPA 개발에 참여하면서 둘이 비슷해진건
    알겠는데 자세한건 아무래도 자주 사용해 보신 전문가분께서
    잘 아실테니까요.

    Web Application 용이고, 서버는 Tomcat 6를 쓸 예정입니다.
    바쁘셔서 곤란하시면 이 질문은 그냥 모른척 하셔도 돕니다…^^;
    바쁜상황에서는 정말 1분 1초가 중요하다는걸 잘 알고 있어서
    충분히 이해할수 있고, 답변하실 의무가 있는것도 아니구요.
    그럼, 좋은밤 되세요.

  11. Kevin/ JPA는 Hibernate, JDO, TopLink등의 공통적인 면을 모아서 만든 것처럼 보이지만 사실은 하이버네이트의 용어와 스타일에 가깝게 만들어진(초안을 Gavin이 짰기 때문에 어쩔 수 없이…) 표준 ORM스펙입니다. Hibernate는 완벽하게 JPA의 스펙을 준수할 수 있는 툴입니다. 따라서 하이버네이트와 JPA중 선택하라고 하는 것은 조금 애매합니다. 마치 톰캣(의 확장기능까지 포함해서)쓸까요 JSP쓸까요 이런 질문과 비슷하기 때문입니다.
    아무튼 기준은 이렇습니다. JPA엔진(Hibernate, OpenJPA, EclipseLink 등등)을 바꿔가면서 써야하는 포터빌러티가 중요하다면 JPA를 쓰세요. 또는 표준기술을 썼다는 명분이 실제 기술자체보다 더 중요하다면 JPA를 쓰세요. 그외의 경우라면 하이버네이트를 쓰세요. 물론 JPA를 써도 하나의 구현체의 표준밖의 확장된 기능을 사용할 수 밖에 없기 때문에 결국엔 호환성이 완벽히 보장되기는 쉽지 않습니다. 개인적으로는 JPA에 대한 특별한 요구조건이 없다면, 하이버네이트를 사용하시면(JPA모드가 아니라 하이버네이트 모드로) 좋을듯 합니다.

  12. 와! 정말 빠른 답변 고맙습니다.
    그리고 중요한점을 쉽게 알려주셔서, 다시 한번 감사드립니다.

    특별히 표준을 써야 한다는 명분은 없구요.
    사실 저도 J2EE 표준의 희생자라고 생각합니다…^^;
    아무튼 OpenSource 이기만 하면 아무 상관없구요.

    단지 마음에 걸리는게 Gavin King이 쓴 책에서
    Tomcat에는 transaction manager가 딸려오지 않기 때문에
    JTA호환 transaction manager를 설치해야 할수도 있지만,
    JBoss같은 JEE Server를 쓸경우 이런 걱정없이 설정도 쉽고
    서비스도 더 좋다고 하던데요.
    Tomcat에 Hibernate를 쓸 경우,
    이건 걱정할 필요가 없을 정도 일까요?

  13. Kevin/ JTA를 쓰신다니 다중 DB(또는 리소스)의 통합트랜잭션을 사용하셔야 하나보죠?
    Tomcat에서도 동작하는 오픈소스 JTA엔진은 많이 있습니다. 그중에서 http://www.atomikos.com/Documentation/Tomcat6Integration33를 추천합니다.
    근데 JTA를 꼭 써야 하는 이유가 있긴 한건가요?

  14. 아… 고맙습니다.
    아뇨, 지금 당장 JTA를 쓸일이 있어서 그런것은 아니구요.
    앞으로 어떻게 될지 몰라서…

    근데 지금 댓글 쓰면서 생각해 보니까,
    그럴 상황이 올 가능성이 있는지는 모르겠지만
    만에하나 나중에 Tomcat으로는 도저히 안되고 다른 서버를 써야할
    상황이 온다해도 서버 바꾸면 되는거네요…ㅡ_ㅡ;;;
    Hibernate를 쓰면 다른 서버에서 안 돌아가는것도 아니고…

    JTA 문제는 제가 참 바보 같은 고민을 해서
    Toby의 시간을 뺏었네요. 죄송합니다…^^;;;

    어쨌든 추천 정말 고맙습니다. 나중에라도 요긴하게 쓸때가 있을것 같네요.

  15. 토비 화이팅… 늘 고맙게 생각해… 진심으로…

  16. Why Not Try These Out

  17. Useful info. Hope to see more good posts in the future.

  18. cheap mbt shoes online 차라리 표준이 없었더라면 » Toby’s Epril

Leave a Reply

(required)

(required)

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

© 2017 Toby's Epril Suffusion theme by Sayontan Sinha