2008년 4월 5일 토요일

웹 표준 개발 프로세스

웹표준화와 웹접근성 강화에 대한 이슈가 커지고 있다. 오는 4월 11일(차주 금요일) '장애인 차별금지 및 권리구제를 위한 법률'이 시행되고, MS의 Internet Explorer 8은 그동안 문제가 많았던 CSS 렌더링 엔진을 자사 제품중(IE 5.5, 6, 7) 가장 완성도 있는 표준 지원 엔진으로 바꿔놓았다. 애플은 자사의 'Safari' 웹브라우저를 윈도우용으로 출시하였고, 최근에는 웹표준기술 테스트인 Acid3를 통과했다는 소식을 전했다. 오페라 역시 'Safari'와 같은 날 Acid3를 통과했고, 모바일 시장(휴대폰, PDA 등에 탑재되는 미니 브라우저 시장)에서의 강세를 이어가고 있다.

바야흐로 2008년은 웹표준의 전환점이 될 것으로 보인다. 그동안 은비까비가 들려주는 옛날 옛적 이야기쯤으로 치부하던 웹 실무자들도 조금씩 관심을 보이기 시작했고, 해야겠다는 생각을 하기 시작했다. 며칠전 사내 웹표준 세미나 이후 계획되어 있던 프로젝트가 곧바로 웹표준 개발로 전환되는 쾌거(!)를 이룬 것이다. 적어도 두시간 가까이 목말라가며 떠들었던 내 작은 수고가 헛되지만은 않았던 것일까.

그런데 바로 고민거리가 생겼다. 해야한다고 이연사 목청 높여~ 외쳤으나 정작 'How?'에 대한 해답을 확실히 주지 못한것이다. 세미나 직후 웹표준 개발로 선회한 프로젝트를 담당하신 기획자분이 내게 왔고, 어떻게 해요... 라고 물으시는데 참 미안해지더라. 지금까지는 웹표준을 위해서 웹퍼블리셔들이나 개발자들이 표준기술을 익혀왔고, 디자이너나 플래셔들에게는 접근성에 대한 이해를 구해왔었다. 하지만 사실 기획자를 통한 개발 프로세스의 적절성 논의에서부터 필요하다면 새로운 개발 프로세스가 필요하지 않을까 하는 생각을 하게 되었다.


한국소프트웨어진흥원에서 발표한  '실전 웹 표준 가이드(2005)'에 보면 마지막 챕터에 표준 개발 프로세스를 자세히 설명하고 있는데 이를 먼저 소개해보고, 김철수님의 웹 표준 개발 후기를 통한 문제점과 개선점 등을 고민해 보겠다.

실전 웹 표준 가이드의 '실전 표준 개발 프로세스'

기존 웹 개발 프로세스는 일반적으로 Waterfall 방식이라고 불리우는 선형적이고 밀어내기식의 프로세르를 따르고 있다.

사용자 삽입 이미지

실전 웹 표준 가이드 p183

쉽게 말해 '기획 → 시안 → 스토리보드 → 디자인 → 코딩 → 프로그래밍/디버깅'으로 이어지는 방식인데 전문적인 지식이 없더라도, 또는 프로젝트가 진행중인 새로운 인력이 투입이 되더라도 별도의 교육이 필요하지 않는 비교적 쉽고 단순한 방법이다. 때문에 웹개발 초기부터 도입이 쉬웠고 아직까지도 크게 변하지 않고 적용되고 있다.

이 방법의 문제는 ① 업무의 병목현상 ② 의존적 스토리보드 ③ HTML문서구조화의 어려움 ④ 개별 역활 중심의 프로세스를 통한 업무 과중을 들 수 있습니다.

  1. 업무의 병목현상
    Waterfall 방식은 선행 프로세스가 지연될 경우 전체 프로세스의 지연으로 이어진다. 즉, 기획이 늦어지면 디자인과 코딩, 개발이 차례로 늦어지는 문제가 생긴다. 코딩까지 완료된 시점에서 기획이나 디자인이 변경되면 재코딩이 이루어지는 것도 병목현상에 한 몫 하게 된다. 아울러 프로세스상 뒤에 위치한 코딩이나 개발 인력의 프로젝트의 초기 참여율이 낮고, 둘 이상의 프로젝트에 참여하게 되면서 집중도를 낮춰 전체적인 생산성을 떨어뜨리는 경우가 생긴다.
  2. 의존적 스토리보드
    스토리보드는 웹개발의 시작이고, 밑그림입니다. 그만큼 중요하죠. 문제는 디자이너나 개발자들이 지나치게 스토리보드에 의존적이라는 것입니다.
  3. “스토리보드에는 그에 대한 지시사항이 없는 걸요” - 아주 기본적인 에러확인 로직을
    스토리보드에 없다는 이유만으로 개발하지 않은 프로그래머의 반문
    “저는 스토리보드에 그려진 대로 그린 것 뿐인데요...” – 디자인이 참신하지 못하다는
    지적을 받은 디자이너의 변명
    “어째서 스토리보드에 있는 그대로 하지 않았지?” – 발전적 창의성을 적용한
    프로그래머/디자이너를 인정하지 않는 기획자의 질책

    위의 예는 의존적 스토리보드의 문제점을 제대로 보여주고 있죠. 이로 인해서 기획자는 스토리보드를 수백장씩 상세하게 기술해야만 하는 업무적 과중을 느끼게 됩니다. 웹디자이너에게는 스토리보드를 그대로 Photoshop에 그려내는 '오퍼레이터'와 같은 수동적인 자세를 가지는 것도 문제가 됩니다. 또한, 전체 프로세스를 한 눈에 보여주지 못한 수백장의 스토리보드는 개발자에게 별로 도움이 되지 못합니다.

  4. HTML문서 구조화의 어려움
    HTML문서를 코딩하는 일은 관례적으로 웹디자이너의 역활로 지정되어 온 경우가 많습니다. 규모가 커지고, 웹디자이너의 부담을 줄이기 위해서 'HTML코더'라고 불리우는 직군이 생겼지만 상대적으로 낮은 대우와 평가를 받아왔습니다. 때문에 웹디자이너가 코딩을 하든, 웹개발자가 하든, 별도의 코더가 하든 HTML문서가 제대로 '구조화'되지 못하는 문제가 생기게 된 것입니다.

  5. 개별 역활 중심의 프로세스를 통한 업무 과중
    기획자나 디자이너, 개발중 어느 한 직군(역활)을 중심으로 프로세스를 개선하거나 정리할 수 있습니다.
    기획자 중심의 프로세스는
    사용자 삽입 이미지

    실전 웹 표준 가이드 p191

     
    이 될 것이고, 디자이너 중심의 프로세스는
    사용자 삽입 이미지

    실전 웹 표준 가이드 p189


    이 됩니다. 프로그래머 중심의 프로세스 역시
    사용자 삽입 이미지

    실전 웹 표준 가이드 p190


    의 절차를 갖게 됩니다. 어느경우라도 XHTML 구조화(마크업)와 CSS 디자인이라는 표준 기술 영역을 포함해야 하기 때문에 업무 과중이 문제가 됩니다. 특히 과거처럼 웹디자이너에게 마크업과 CSS디자인을 맡기게 되면, 시각적인 디자인과 논리적인 디자인의 차이로 인해 오히려 좋지 않은 영향을 끼칠 수 있을 것입니다.

웹 표준 가이드에서는 위와 같은 기존 프로세스의 문제점을 지적하고 '웹퍼블리셔 중심의 개선된 모델'을 제안하고 있습니다.

사용자 삽입 이미지

실전 웹 표준 가이드 p193


보기엔 상당히 복잡해 보이지만 단순히 HTML 코딩만을 위해서 'HTML 코더'를 두었던 것과 달리 웹 표준 기술에 대한 전문성을 가진 '웹퍼블리셔'라는 직군을 포함시키면서 기획자나 디자이너, 개발자가 가질 업무의 과중을 덜어냄과 동시에 전체 프로세스의 효율성을 높이고 있다고 볼 수 있습니다.

이제 여기서 실제로 위의 프로세스를 실무에 적용했던 김철수님의 후기를 살펴보겠습니다.

김철수님의 'Storyboard - 표준 스토리보드 구상기'

김철수님은 웹 2.0 에 따른 Ajax 사용등을 고려하면서 새로운 스토리보드의 필요성을 느끼셨다 합니다. 그리고 앞서 소개해 드린 '실천 웹 표준 가이드'의 '웹퍼블리셔 중심의 개발 프로세스'를 받아들여 프로젝트에 적용하는 노력을 해 주셨습니다. 특히 김철수님은 웹퍼블리셔에게 XHTML, CSS, JS와 같은 웹 표준 기술의 전문성과 더불어 프로젝트의 실무적인 조율 능력이 필요함을 지적하고 있습니다. 그리고 다음은 김철수님께서 실제로 적용한 방법이다.

방법은 이러했다. 우선 전체가 모여 프로세스 플로우를 짜기 시작했다. 이때 사실상 전반적인 기획과 분석과 설계가 같이 진행되어서 대략 2개월 정도가 걸렸다. 그 다음에는 컨텐츠 명세서를 간단히 작성하고 곧바로 퍼블리셔를 임명하여 HTML 코딩 작업에 들어갔다. 그 산출로 나온 CSS를 디자이너가 실시간으로 확인하면서 디자인 작업을 했고, 개발자는 DB 개발과 서버 프로그램 개발을 진행했다.

그리고 다음과 같은 문제점들을 나열했습니다.

첫째, 전체가 모여 프로세스 플로우를 맞추는 것이 매우 힘든 일이었다.

둘째, 컨텐츠 명세서를 작성하는 것이 쉽지 않았다.

셋째, 퍼블리셔의 작업을 충분히 해낼 사람이 없었다.

넷째, CSS를 잘 다루는 디자이너가 없었다.

아무래도 새로운 프로세스를 직군별로 설득하고 이해시키는 일이 쉽지 않았을 것이며, 새롭게 등장한 컨텐츠 명세서를 어떻게 해야하는지 기준도 없는 상태에서 진행하기란 쉽지 않았을 것이다. 그리고 웹 표준 기술을 제대로 숙지하고 적용할 수 있는 전문적인 웹퍼블리셔의 부재는 어제 오늘의 문제가 아니고, CSS 디자인과 같은 웹 표준 기술이 요구되는 작업을 디자이너가 하기에는 무리가 있었을 것이다. 이러한 문제가 있었지만 김철수님은 나름의 노하우를 익히셨고 다음과 같이 공개해 주셨다.

하나, 사이트맵 대신 모듈맵을 만든다.

둘, 모듈 단위로 HTML을 작성한다.

셋, 최종사용자의 UX를 먼저 확정한 뒤 서버 프로그램을 시작한다.

넷, 텍스트 기반으로 먼저 만들고 나중에 세세한 디자인 요소를 삽입한다.

다섯, 위키 방식으로 모두가 개발 소스에 접근하여 수정할 수 있도록 한다.

자세한 설명은 김철수님 블로그에서 직접 확인해 볼 수 있는데, 간단히 코멘트를 하자면 전체 프로세스를 모듈화 하는 것이 중요해 보인다. 과거처럼 거대한 프로젝트를 수백장의 스토리보드에 다 담아 내는 것이 아니라, 기능별로 모듈화된 페이지를 고려하고, 그에 맞는 명세서나 차트를 만들어 개발자와 디자이너에게 전달한다. 그리고 텍스트 기반(XHTML 마크업)의 프로토탑입 설계를 함께 진행하여 디자인 이후에 있을 오류를 최소회 시켜야 한다. 또한, 개발 팀원간의 소통을 위한 도구로 '위키(wiki, 누구나 접근하여 쓰고, 지우고, 수정할 수 있는 시스템)'를 제안하고 있다. 제 의견으로는 'Trac' 의 사용을 추천해 드립니다.'Trac'는 '위키'시스템과 '포럼' 형태를 모두 가지고 있고, 버전관리와 연동이 되기 때문에 프로젝트 게시판으로 사용하기 좋은것 같습니다.


개량형 '웹퍼블리셔 중심의 웹 표준 개발 프로세스'


위 표는 '실전 웹 표준 가이드'와 김철수님의 후기를 읽은 뒤에 살짝 고민을 덧붙여 변형을 가해 본 것이다. 가이드에서도 밝혔고, 나 역시 미리 밝혀두는 것이지만 이러한 웹 표준 프로세스라는 것이 아직은 정형화 되어 있지 못하고, 객관적인 장단점이 불분명한 상태이다. 따라서 프로젝트의 성공 여부를 보장해주지 못한다. 다만, 웹 표준을 준수하는 웹 개발을 할라치면 이러한 고민과 적용이 필요하지 않을까 해서 시작된 것이고, 이렇게 나의 의견까지 덧붙이게 된 것이다.

'개량형'이라고는 했지만 '실전 웹 표준 가이드'에서 소개하는 내용과 크게 다르지는 않다. 용어가 일부 변경('코딩' 보다는 '마크업'이라는 용어로, 일부는 김철수님의이 제안하신 것)되었고, 프로세스가 약간은 더 복잡해졌다고 볼 수 있다. (없던 화살표가 생겼다!) 풀어서 서술하자면 다음과 같다.

  • 기획자 : 기획자는 '실전 웹 표준 가이드'에서 제안하는 것과 같이 기획문서를 '프로세스 플로우'와 '컨텐츠 상세화'로 구분하여 작성한다. 차이가 있다면 '프로세스 플로우'와 함께 게시판이나 회원가입/로그인과 같이 모듈화가 가능한 것들에 대한 모듈 명세서 또는 모듈 맵이 함께 작성된다. 그리고 이것은 개발자에게 전달되어 프로젝트 전반에 대한 설계와 프레임 개별 모듈에 대한 설계를 할 수 있도록 한다.
  • 디자이너 : 디자이너는 기획/분석 단계에서 만들어진 아이디어를 통해 시안과 스타일 가이드(문서 또는 준하는 이미지 파일)를 만듭니다. 그리고 기획자의 컨텐츠 상세화 문서(기존의 스토리보드로 생각하면 쉬울것 같다)를 받아 화면 디자인을 시작한다. 여기서 완성된 스토리보드를 가지고 시안을 만들지 않는다는 것은 중요합니다. '실전 웹표준 가이드'나 김철수님이 지적했듯이 상세한 스토리보드는 디자이너의 창의력을 둘러싸는 장벽이 될 위험요소가 있습니다. 때문에 기획/분석 단계에서 나온 아이디어나 컨셉 등 필요한 만큼의 적은 정보만으로 시안을 잡아 디자이너로 하여금 충분히 창의력을 발휘할 수 있도록 해야 합니다.
  • 개발자 : 개발자는 기획/분석 단계에서 나온 아이디어와 컨셉을 통해 기술적 이슈(HTML문서의 DTD, 인코딩, 폼 영역의 ID값 등)에 대한 개발 가이드를 작성하여 퍼블리셔에게 전달합니다. 그리고 기획자로부터 '프로세스 플로우'와 '모듈 맵'을 전달받아 시스템 설계와 모듈 단위의 개발 준비를 시작합니다. 이후 퍼블리셔로부터 마크업이 완료된 XHTML문서를 받아 프로그래밍과 디버깅 작업을 진행합니다.
  • 퍼블리셔 : 퍼블리셔는 기획자로부터 '컨텐츠 상세화 문서' 또는 '페이지 명세서'를 받아 XHTML 마크업을 시작합니다. 이때 개발자로부터 받은 '개발 가이드'를 바탕으로 XHTML 문서의 Doctype 설정, 인코딩 설정, 공통  ID값 등을 결정하거나 적절치 않을시 재논의하여 적용하도록 합니다.(한 번 결정된 Doctype이나 인코딩은 개발 과정에 쉽게 바꾸기가 어려우므로 반드시 확실히 결정을 하고 넘어가도록 합니다.) XHTML 마크업이 완료되면 개발자에게 전달하여 프로그래밍이 진행될 수 있도록 합니다. 이후 디자이너로부터 받은 '스타일 가이드'와 '화면 디자인(PSD 파일)'을 통해 XHTML 문서에 CSS 디자인을 시작합니다. 다음으로 개발자와 소통하며 완료된 페이지를 '퍼블리싱'하면서 CSS 오류 등을 잡아내는 '디버깅' 작업을 진행합니다. 마지막으로 기획자와 함께 '표준화 준수 확인'작업을 하게 되는데 '실전 웹 표준 가이드'에서는 이를 퍼블리셔의 역활로 두었으나 제 경험상 '내가 작업한 것을 내가 테스트 하는 것은 실효성이 적다'였습니다. 다시말해 내 실수를 내가 찾아내는게 쉽지 않았다라는 겁니다. 프로세스대로 디자이너와 개발자가 표준에 맞춘 일정을 따라주었다면 최종적으로 퍼블리셔의 웹 표준 기술(XHTML, CSS, DOM, JS 등)에 의한 크로스 브라우징과 접근성 문제 등이 주요 이슈로 나타날 수 있는데 이를 퍼블리셔 스스로 검증하기란 쉽지 않습니다. 따라서 애초에 기획자에게 책임을 지우는 것이 좋다는 생각을 해봤습니다. 그리고 단계적으로는 최종 단계이긴 하나 기획자는 프로젝트가 진행되는 가운데 지속적으로 디자이너와 개발자, 퍼블리셔가 표준을 준수하고 있는지를 검증해야 합니다.

특별히 부연 설명을 드리고 싶은 것은 위 표에서도 나타나 있듯이 양쪽화살표로 되어 있는 굵은 선 프로세스들입니다. 퍼블리셔를 중심으로 기획자와 퍼블리셔, 디자이너와 퍼블리셔, 개발와 퍼블리셔가 지속적으로 커뮤니케이션을 이루도록 되어 있습니다. 또 한가지 기획자와 퍼블리셔가 같은 색 영역으로 묶여 있음을 보실 수 있습니다.

김철수님도 쓰셨듯이 웹 표준 개발 프로세스에서 기획자와 퍼블리셔의 협력은 굉장히 중요해 보입니다. 1차적으로 과거의 스토리보드가 세부화된 개별 문서와 XHTML 문서로 만들어집니다. 이렇게 만들어진 XHTML문서는 디자인이 입혀지기 전에 1차적으로 프로세스 테스팅을 가질 수 있다는 장점이 있습니다. 일종의 프로토타입을 만드는 것입니다. 버튼이 빠져 있거나 페이지가 잘못 연결되어 있거나 추가되는 페이지등을 사전에 고려하여 디자인 이후에 생길 수 있는 추가 작업을 줄일 수 있습니다.

디자이너가 CSS를 다루지 않는 것도 김철수님의 경우와 다릅니다. HTML이나 CSS도 모르면서 웹을 어떻게 하냐는 소리를 하곤 했지만 사실 웹디자이너에게 전문적인 수준의 XHTML과 CSS를 강요할수만은 없다고 생각합니다. (현실적으로 불가능에 가깝습니다.) 때문에 CSS 디자인 역시 퍼블리셔의 영역 안에서 해결해야 한다고 생각합니다. 실제로도 대부분의 퍼블리셔들이 시멘틱한 마크업과 CSS 작성은 자신들의 영역이라고 생각하면서 공부하고 있습니다.

아울러 개발자들이 텍스트로만 이루어진 XHTML 문서를 통한 개발에 적응할 수 있어야 한다고 봅니다. 개발 영역에서는 MVC모델이라는 것이 확실히 자리잡고 있지만 아직도 많은 경우에 XHTML문서 내에 직접 프로그래밍을 입히는 경우가 많습니다. 이 경우 XHTML문서와 서버측 스크립트 언어, CSS 등이 뒤섞여 유지보수가 매우 어려워질 수 있고, 위의 개발 프로세스도 적용하기 힘들 수 있습니다.

저는 가능하면 현재의 프로세스(Waterfall) 에서 크게 변형을 가하고 싶지는 않았습니다. 갑작스러운 변화는 오히려 효율성 측면에서 마이너스 효과를 가져올 수 있기 때문입니다. 따라서 위 표를 보면 초록색 프로세스를 중심으로 기획자는 기획문서를 만들어서 개발자와 디자이너에게 주고, 디자이너는 퍼블리셔에게 PSD를 주고, 퍼블리셔는 마크업이 완료된 XHTML문서를 건네게끔 되어 있습니다. 이는 기존의 프로세스와 크게 다르지 않습니다. 그러면서도 상호간의 커뮤니티를 강조하고 있고, 전문적인 웹퍼블리셔의 인력 확보에 포커스를 두고자 합니다.(이 부분은 구인이든 교육이든 사내에서 해결을 해야할 것으로 보임) 따라서 디자이너가 어렵게 CSS를 다루지 않아도 되고, 개발자 역시 초기 단계에서 문제가 될 만한 것들을 퍼블리셔와 미리 확실하게 집고 넘어가는 과정을 필수적으로 포함시킴으로써 개발 후에 생길 문제를 최소화 하는데 신경을 썼습니다.

지금까지 웹 표준화 프로젝트를 위한 '웹 표준 개발 프로세스'를 고민해 보았습니다. '실전 웹 표준 가이드'의 제안과 김철수님의 '표준 스토리보드 구상기'는 이미 충분히 좋은 자료가 되고 있습니다. 여기에 저의 부족한 경험과 고민을 덧붙여 약간 변형된 모습까지를 보여드렸습니다. 이미 더 좋은 방법으로 프로젝트를 진행하고 계실 분들도 계실 것이고, 더 나은 생각을 가지신 분들도 계실텐데 저에게 지적과 함께 좋은 의견을 주셨으면 감사하겠습니다.

댓글 22개:

  1. trackback from: 웹 표준 개발 프로세스
    웹 표준 개발 프로세스 :: 2008/04/05 19:46 웹표준화와 웹접근성 강화에 대한 이슈가 커지고 있다. 오는 4월 11일(차주 금요일) '장애인 차별금지 및 권리구제를 위한 법률'이 시행되고, MS의 Internet Explorer 8은 그동안 문제가 많았던 CSS 렌더링 엔진을 자사 제품중(IE 5.5, 6, 7) 가장 완성도 있는 표준 지원 엔진으로 바꿔놓았다. 애플은 자사의 'Safari' 웹브라우저를 윈도우용으로 출시하였고, 최근에는..

    답글삭제
  2. 그간의 문제점을 짚은 것이나 고민한 내용들을 너무 잘 정리해주셨네요.

    봄눈님은 정말 정리하시는데 소질이 있으신거 같아요.



    김철수님 글을 보면서 정말 '의미있는 무모한시도'라는 생각을 했는데,

    봄눈님이 개선하신 프로세스는 훨씬 현실적인 것 같네요.



    아직도 퍼블리셔를 별도의 포지션으로 두지 않거나 전문화 시키지 않은 곳이 많지만

    퍼블리셔를 두는 쪽이 더 효율적이어서 그렇게 될 수 밖에 없겠지요.



    그와 함께 이런식으로 퍼블리셔의 역할이 좀 더 명확하게 정립되어 나가는 것이 꼭 필요하지 않나 생각했습니다만, 고양이 목에 방울을 달아주신 것 같아서. 감사합니다. ^^



    저도 기존의 선형적 방식에서 급격한 변화는 오히려 좋지 않다 싶고, CSS가 디자이너보다는 퍼블리셔의 영역이 되어야 한다는데 동감합니다.

    개선된 방식의 프로세스에서는 퍼블리셔의 역할이 상당히 중요해보이는데요. 디자인이 없는 상태에서 마크업을 먼저 한 뒤에, CSS로 디자인을 입히는 프로세스가 익숙해지고 나름의 노하우가 쌓이기 까지는 몇번의 프로젝트를 통한 시행착오가 필요하지 않을까 싶습니다. (이미 이렇게 하고 있나요? 저는 잘 몰라서 ^^)



    프로세스와 관련된 내용은 아니지만 웹표준을 잘 이해하지 못한 개발자가 프로젝트에 섞여 있는 것이 웹표준화 작업에 있어서 가장 큰 걸림돌이 아닐까 생각합니다. (경험이 없고 시야가 좁다보니 겪었던 일들위주로 생각하게 돼서요 ^^; 개발자들도 웹표준을 트레이닝 시켜야 하지 않나 싶네요)

    답글삭제
  3. @KANGOON - 2008/04/05 20:49
    댓글 감사합니다^^ 좋은 의견 있으시면 남겨주세요~

    답글삭제
  4. @Headvoy - 2008/04/05 22:35
    Headvoy님 긴 댓글 감사드립니다^^

    기획자, 디자이너, 개발자 그리고 아직도 많은 수의 퍼블리셔들에게 알리고, 교육해야겠죠^^

    저 역시 아직도 모르는게 많으니까 항상 공부를 하는 것이구요.



    아무래도 시행착오는 있을 거라고 생각합니다. 작은 프로젝트나 사내 프로젝트부터 경험을 쌓는게 좋다고 생각됩니다. 그리고 디자이너나 개발자나 과거로부터 익혀온 습관을 버리게 하기도 어렵지만 자존심이랄까요? 디자이너로서의 개발자로서의 프라이버시를 존중하면서 이끌어 오는 일이 쉽지 않을거라 생각합니다. 특히 지금까지는 개발자들에 의해서 사이트가 완료되는 형태를 가져왔는데 '실전 웹 표준 가이드'나 김철수님 그리고 제 글에서 웹 표준 프로세스는 실무적으로 웹퍼블리셔에 의해서 소통되고, 마무리가 되는 형태입니다.



    다시 말해서 통 큰 퍼블리셔가 많아야 하는데 그렇지 않다는 것, 이해의 폭을 넓히고 변화를 받아들이는 서버사이드개발자분들이 많아져야 하는데 이게 쉽지 않겠죠^^

    답글삭제
  5. trackback from: 웹 표준 개발 프로세스 By 웹 뒤에 숨은 'Web' -Pageoff
    웹표준화와 웹접근성 강화에 대한 이슈가 커지고 있다. 오는 4월 11일(차주 금요일) '장애인 차별금지 및 권리구제를 위한 법률'이 시행되고, MS의 Internet Explorer 8은 그동안 문제가 많았던 CSS 렌더링 엔진을 자사 제품중(IE 5.5, 6, 7) 가장 완성도 있는 표준 지원 엔진으로 바꿔놓았다. 애플은 자사의 'Safari' 웹브라우저를 윈도우용으로 출시하였고, 최근에는 웹표준기술 테스트인 Acid3를 통과했다는 소식을 전했다...

    답글삭제
  6. trackback from: 웹 표준 개발 프로세스
    출처 : 봄눈 님의 블로그에서한때 웹 프로그래머 및 웹마스터로서 회사에 몸 담은 적이 있는 나로서는이 그림이 얼마나 아름다운지를 느끼게 해 준다.더 나은 디자인과 더 많은 기능, 그리고 더 많은 요구를 하는 세명의 각기 다른 사람들이 모여서 만들어지던 홈페이지에서결국 위와 비슷한 그림의 공정을 거치는 것이 몸에 익게 될때까지엄청 충돌이 많았었다.UML이 중

    답글삭제
  7. 글 잘봣습니다^^



    기본에 나왔던 퍼블리셔(당시엔 코더)중점의 프로세스 라고 해서 획기적이라고 느꼈었지만 실제로 에이전시에 적용되기는 힘들었지요. 너무나도 통감하는 내용입니다.



    아마 이런 프로세스의 문제점에서 가장 큰 이슈는 퍼블리셔의 업무 분량을 고려해야만 한다라는 점입니다.

    그리고 적어도 2년차 이상의 XML , XHTML , HTML , CSS , DTD , JS정도의 스펙과 개발환경(서버사이드)의 기본은 갖춘 상태에서 ACtion script 와 이미지레디(포토샾을 쓰는 경우도 많구요)를 사용해야 하는 환경에 놓이게 되는게 문제점 이라는 문제점 입니다.



    추합하는 과정을 퍼블리셔가 하는것이 당연하다고 생각합니다만.. 위에 나온 정도의 스펙까지 올라가기에는

    시간과 기간 , 그리고 그에 따른 완벽함을 추구하는데에는 이루기 힘든 일정스케줄 등.. 그런것들 부터 변경해야 할듯 합니다.. 그냥.. 잡설(?) 이였습니다..^^;;;;;

    답글삭제
  8. @디스타일 - 2008/04/06 22:03
    웹퍼블리셔에게 요구되는 전문적 지식의 수준이 상당히 올라간 것은 맞는것 같습니다. 그리고 앞으로 지속적인 교육과 연구를 통해 웹퍼블리싱을 하시는 분들이 스스로 고민하고 발전시켜야 하지 않나 하는 생각도 해 봅니다.



    디스타일님 매번 댓글 감사드립니다^^

    답글삭제
  9. 감사합니다. 좋은 내용이네요.. 많은 도움이 되었습니다.

    답글삭제
  10. 예전 에이젼시에서 근무할 때 '개선된 개발공정' 이라는 프로세스와 비슷한 구조로 진행을 해본 적이 있었습니다.

    당시엔 웹표준이라는 인식이 크지 않았던 데다 html/css (구조/디자인)의 분리에 대해서 큰 이해가 없었던 터라 상당히 힘들었던 기억이 납니다. 결국엔 기존의 방식대로 돌아갔지만 시도를 해봤다는 데에 의미를 두고 있습니다.(혼자.. 저 혼자..)



    함께 일하는 모든 파트의 분들이 정확한 이해가 필요한 것 같았습니다. 게다가 클라이언트의 도움도 필요하구요. 개인적인 생각엔 기존의 방식에 드는 전체 프로젝트 소요기간이 '100' 이라면 '디자이너 위주', '개발자 위주'와 같은 구조와 디자인을 분리한 개선된 프로세스로 진행을 한다면 많게는 소요기간을 '50'정도로 줄일 수 있을 것 같았습니다.



    음.. 결론은

    모두가 함께해야 하는 것이죠..;

    답글삭제
  11. rootbox 님 말씀에 동감합니다.

    저역시 나름 위 프로세스 처럼 프로젝트를 진행 해 봤었는데요...

    저에게 과부하가 걸리더군요...



    이유는

    기획자는 명확한 컨텐츠 이해없이 명세서를 만들어서 어느게 타이틀이고 내용인지 불명확하게 만드시고,

    프로세스에서 자신이 해야 할 일들을 나몰라라 하게 되더군요...(대부분 제가 왔다갔다 하며 체크 -_-)

    그리고 디자이너 역시 단순하게 받아들이더군요...이미와 텍스트 구분만 하면 되고, 템플릿 처럼 만들면 되겠구나...라고요...



    사실 디자이너에겐 컨텐츠 중복 요소들 정리를 부탁한거였는데...정말 가이드 psd 외엔 페이지에 타이틀이미지만 딸랑;;;; 그럼....디자인 퀄리티라도 나왔어야 하는데...이도 저도 아닌;;;

    지금 방식은 자신의 창의력을 너무 제한한다라나 뭐라나 +_+;;;



    결국 프로젝은 완성했으나 그 피로도는 거의 WOW 일주일동안 쉬지않고 랩업한 기분이랄까요;;;

    그러나 프로젝 완성도는 많이 떨어졌습니다....(저역시 그렇게 진행한 프로젝이 첨이라서;;;)



    두번째 프로젝도 위와 같이 진행하려고 했으나...

    기획자의 능력이 첫번째보다도 현저히 떨어지시는 스펙이시라 감히 엄두도 못내고...

    디자이너한테 그냥 첫번째처럼 가이드 psd를 부탁하고 스토리보드 보면서 알아서 코딩했습니다...

    이번 디자이너는 그나마 말귀를 알아들어서인지 가이드 psd를 table(표,리스트요소), contests 요소, 기본 텍스트 요소 등등을 나누어서 주셔서 좀 편하게 CSS를 잡을 수 있었던듯...



    결론은...우리들만의 웹표준은 안된다...

    모든 프로젝 참가인원에 살포시 스며들어야 완성도 높은 웹표준 적용 사이트가 나올 수 있다...죵;;;

    답글삭제
  12. 안녕하세요.

    하코사 타고 왔습니다. 글 잘 봤습니다.

    일단 비공개로 트랙백 담았는데 담아가도 될지 모르겠네요^^;

    마지막 말씀에 공감합니다.

    답글삭제
  13. @kino - 2008/04/07 09:30
    댓글 감사합니다^^

    답글삭제
  14. @rootbox - 2008/04/07 09:52
    루트박스님 잘 지내시죠? ^^



    그 개선된 개발공정이 어떤 것이었는지 알고 싶은데요~

    답글삭제
  15. @진달래 - 2008/04/07 11:52
    네 어느 한 직군이나 인원에게 업무가 집중되는 것은 여러모로 좋지 않은것 같습니다.



    위의 프로세스가 제대로 가동되려면 대부분의 에이젼시에 웹퍼블리셔가 있어야 할 것이고, 웹표준기술을 평균이상으로 구현할 수 있어야 할 것입니다. 그리고 웹기획자 역시 웹표준에 대한 이해도가 어느정도 되야 무리가 없을 것으로 보입니다.



    저는 지금 다른 직군에 너무 큰 기대를 하고 있지는 않습니다. 단계적인 개선을 희망하는데 일단은 웹기획자의 스토리보드는 그대로 유지할려고 합니다. 디자이너와 개발자 역시 지금의 방식을 고수합니다.



    변화는 웹퍼블리셔부터 가져갈 계획입니다. 마크업과 CSS를 분리하는 프로세스를 정착하고, 기획자로 하여금 웹표준검증 영역을 함께 할 것을 유도할 계획입니다. 그렇게 직접 접하면서 경험을 가져가는게 좋다고 생각합니다.



    그리고 웹디자이너에게는 웹접근성과 관련하여 이슈가 되는 문제들을 몇가지 정리하여 그때 그때 제안하면서 나아갈 생각입니다. 텍스트가 커져도 깨지지 않는 레이아웃이라든가 셀렉트박스 옆에 버튼을 다는 것 등 말입니다. 처음부터 접근성을 고려해서 디자인을 해달라고 요구하는것은 디자이너 하여금 부담감만을 갖게 되고 나중에는 별의미없는 것으로 잊어버리고 맙니다.



    개발자와는 표준 스크립트 사용을 공유하면서 맞춰가고, ID값 설정이나 인코딩 문제등 기술적인 부분에서의 공유를 통해서 이해를 시켜가는 방법을 적용중입니다.



    이러다보면 하나씩 바뀌고 차츰 나아질 것이라고 생각합니다. 에휴~

    답글삭제
  16. @즐거운재앙 - 2008/04/07 15:53
    댓글 감사합니다. 그리고 비공개 아니어도 좋습니다. 많은 분들이 함께 공유하시고 좋은 의견들이 많이 나왔으면 하거든요^^

    답글삭제
  17. 잘 정리하시는 성격으로 봐서는 잘 하실듯 싶어요~ ^^



    전 성격이 욱해서 ㅠㅠ

    답글삭제
  18. @진달래 - 2008/04/08 15:44
    ^^ 칭찬 말씀 감사합니다.

    기회가 되면 한번 뵙고 많은 얘길 하고 싶은걸요~

    답글삭제
  19. 사실 제 나름대로의 의견도 적으려고 했는데, 제가 이제 막 이런부분에 대해 자세히 공부를 시작하려 하는 입장이라 참고하려고 복사한것인데, 트래백이 날라가는것까지 생각하지 못했었네요 ' ';;

    얼마전까지 기본적인 기능을 가진 보드와 쇼핑몰을 PHP를 이용하여 만들었는데, 제가 생각해도 소스가 참 엉망이다며 자책을 했었죠. 그래서 현재 웹표준에 맞춰 보드를 하나 만들어 보려고 하고 있습니다.

    봄눈s님의 글을 보고, 언젠간 저런 고민을 하며, 프로젝트를 진행할 날을 기대하게 되었네요.

    앞으로도 자주 오겠습니다. 전체글을 트래백 거는것은 앞으로 자제할께요.

    아.. 현재 이글은 허락없이 퍼갔지만, 제가 참고하고 싶은 내용, 글과 함께 출처를 표시해서 퍼가도 되는지요?

    답글삭제
  20. @KANGOON - 2008/04/11 20:32
    ^^ 물론입니다.

    답글삭제
  21. trackback from: 리눅스 웹사이트 설정방법
    운분투 리눅스 서버 웹사이트 설정1. 사용자추가 및 폴더생성 1) adduser 사용자2. DB생성 1) mysql -u root -p 2)create database 디비명; 3) grant all privileges on 디비명.* to '계정'@'%' identified by '패스워드' with grant option; flush privileges; 3. 아파치설정 apache2/sites-available/default 파일 설정 후 재가동

    답글삭제