널리

제목은 웹표준기반의 웹개발 프로세스 인데
부제를 달자면 웹표준의 장점을 차용한 웹개발 프로세스 정도가 될것 같습니다.

웹표준이 쟁점화가 되거나 불거진 시점이 얼마안된 지금 아직은 웹표준을 실무에 적용한다는것이 다소 부담스럽다는 의견입니다.
정확히는 이윤을 내야 유지가 되는 회사나 업체 입장이라고 하는것이 맞겠지요

웹표준을 적용해야 하는 이유와 당위성들에 대해선 많이 설명되어져 있지만, 실무와 다소 거리가 있지 않냐는 생각과 더불어 제작자 입장에서의 장점들인 편이여서 업계전체 로의 공감은 좀 어렵기도 합니다.

무엇보다
웹표준을 적용한 사례는 많이 있지만 웹표준 적용을 통해 큰 이익을 본 사례는 아직 없기 때문에 불확실한 것에 모험을 하는 업체는 없는것이 당연할수도 있는것이 현제 웹표준에 대한 현실이 아닐까 합니다.

그럼 이런 불확실한(?) 웹표준을 자꾸 실무에 끌어들이려는 노력들은 왜 하는걸까요?

아마 올해IT업계의 유행어가 된 "웹표준" 자체가 가지는 무한한 가능성을 막연하게나마 인식하고 있는건 아닐까 하고 생각해봅니다. ^^;;
아직 구체화 되지 않아서 좀 불확실 할뿐 분명이 웹표준을 통한 큰 실질적 이익은 존재 합니다.
다양한 시각과 다양한 접근경로로 여러가지의 장점들이 구체화 되고 적용되어서 성과를 내리라 믿습니다.

저는 우선 웹표준에 의거한 웹페이지의 구조와 디자인의 분리라는 측면에서 웹개발 프로세스에 접근해 봤습니다.
기존의 웹개발 방식의 단점인 선형적인 업무흐름으로 인한 일정 누적의 문제나, 인력활용의 비효율성, 불필요한 이중작업 등등..
기존의 선형적인 업무흐름으로 인해 생기는 문제점들을 웹표준을 통해 문제를 해결하고 리소스의 낭비를 줄여 실질적인 이익을 보여주는 모델을 제시해 봅니다.
물론 보여드릴 모델은 어디까지나 이론적인 모델로써 완벽하진 않고 러프하게 제시 되었습니다.
그리고 기존 어디에선가 html템플릿 엔진들과 결합시켜 이미 진행하고 있는지도 모르겠네요.. ㅎㅎ

기존 웹개발 프로세스의 모습에서 비효율적인 것들과 그 원인을 찾아봐야 겠습니다

기존 웹 개발 프로세스의 모습

일반적으로 웹개발 프로세스에는 4가지의 단계로 나뉘는게 보통입니다.
흐름을 살펴보면 기획에서 스토리보드로 부터 시작해서 그 스토리보드가 웹디자인을 거치면서 디자인 결과물로 HTML개발쪽으로 전달이 됩니다. 그러면 그 웹디자인은 웹에 게시가 가능한 HTML 코드로 마크업 된후 개발자에게 넘겨지는 이러한 일련의 과정 즉 선형적인 업무흐름이 이어집니다.

이런 일반적인 개발프로세스는 한단계가 끝나야만 다른 단계가 시작되는 형태이기 때문에 전 단계에서 일정이 밀려버리면 그뒤에 따라오는 모든 일정에 영향을 주게 됩니다. 아마 프로젝트 진행하면서 처음에 기획했던 일정 대로 딱 맞는 경우는 거의 없지 않을까 하는데요.
결국 이런 기존 개발프로세스에서는 일정 문제가 항상 문제가 되고 좀 과장하자면 일정 문제는 프로젝트의 한 과정처럼 늘 있는 일일지도 모르겠습니다.

진짜 문제는 이런 일정에 지연에 상관없이 프로젝트 오픈일은 변동이 거의 없습니다.. 결국은 앞단에서 지연된 일정부담을 뒷단계에서 커버해야 하는 형태가 되는데 뒤에 시작되는 단계일수록 일정에 대한 압박은 높아지게 됩니다.

이 외에도 인력효율에 관한 문제점도 있습니다.
각 단계가 종료되었을때 그 해당 단계의 작업자는 무얼 해야 하는지 좀 애매한 경우입니다.
예를 들면,
디자인이 종료되고 html개발까지 완료되어서 개발작업이 들어갈 시점에, 맡았은 업무를 끝낸 해당 웹디자이너와 HTML개발자는 무얼해야 할까요?
물론 해야 할 일이 아주 없는건 아닙니다. 각종 수정과 이런저런 일이 있겠지만 이미 완성한후의 작업들은 완성전 작업보단 아무래도 없게 마련인데, 프로젝트 기간에 각 담당자 들에게 해당 프로젝트에 대한 100%라는 이력배정을 한상태에서 그 소소한 일들로 100%에 대한 인력활용을 하기엔 좀 석연찮아 보입니다.

그러면 좀 다르게 생각해서, "두탕"뛰는걸 생각해볼수 있겠는데요.. 현재 프로젝트 A를 진행하고 있다면 각 맡은 업무가 종료되는 시점에 프로젝트 B를 하면 됩니다.
하지만 이역시 썩 좋아보이진 않습니다. 일정에 문제가 생겨버리면 프로젝트 A뿐만이 아니고 B까지 영향을 미치게 됩니다.
또 동시에 두가지 프로젝트를 한다는 것이 작업자 입장에서 그리 효율적인 방법 이라고 보이진 않습니다.

이 외에도 하나의 수정이슈를 2번 작업해야 하는 이중작업의 문제가 있습니다.

개발까지 끝낸후 진행되기 때문에 HTML태그에 개발코드가 붙혀진 상태로 수정이 됩니다..
수정 과정은 보통
html을 변경해야 하는경우에는 html개발자가 html수정본을 주면 개발자가 수정된 부분을 찾아서 개발이 입혀진 코드에 다시 수정내용을 적용해야 하는 번거로움이 있습니다.
하지만 단순 html변경이라 하더라도 일단은 개발자의 손을 거쳐 반영이 되는 이중작업 문제가 생깁니다..

이렇게 열거된 기존 개발프로세스의 비효율적인 사항들은 업무간 연계성이 높기 때문에 생겨나는 일들입니다.

디자인과 개발은 실질적으로 서로 연관이 없지만 그사이에 위치한 HTML이란놈이 둘을 교집합 형태로 연결시켜버린 상태 입니다.
결국 디자인, html, 개발 이렇게 3개의 업무단위들이 서로 연결되어져 선형화된 작업흐름을 만들어 내고 있습니다.

스토리보드를 통해 디자인이 완성되어야 그 디자인 완성본으로 html개발자가 개발을 하게 되고 그 html까지 완성이 되어야 개발자가 비로서 개발을 시작하게 되는 이런 기차놀이..식의 작업흐름인것이지요..

그러면 이런 선형적인 업무흐름으로 인한 단점들은 선형적인 흐름을 제거나 최소화 함으로써 극복해볼수 있지 않을까 합니다.
그 극복의 Key는 바로 웹표준 방식이 해줄겁니다.

웹표준

웹표준에 대한 간단한 정의를 해보면 아래정도로 표현할수 있을것 같습니다.
- W3C에서 제정한 표준 코드를“의미에 맞게” 사용하여 마크업한 개발이다. -
부족할순 하지만 ^^;; 그래두 잘못된 말은 아닐듯합니다

메타데이터의 성격을 잘 나태내는것 중 하나가 바로 HTML인데
각 태그들은 태그 자체로 어떤 정보를의미하고. 제작자가 따로 설명을 하지 않아도 태그의 이름만으로 어떤 정보인지 파악하게 해줍니다.
앞서 말한 "의미에 맞게는" 바로 메타데이터를 의미하게 되겠구요. 그 메타데이터는 트리 형식으로 구조화 할수 있습니다.

이런 의미에 맞게된 태깅은 웹페이지 구조와 디자인을 분리해낼수가 있는데 이 점이 바로 개발 프로세스에 접목시키게 될 부분입니다.

또 이렇게 "의미에 맞게" 코딩된 이러한 웹표준화 방식은 제작 측면에서 생각해보면 큰 변화가 있는데요
그건 Table기반의 코딩 방식에서 CSS기반의 코딩 방식으로 전환됨을 의미하기도 합니다.

사실 디자인과 구조의 분리는 새로운 어떤 방법을 취하는것이 아니고 원래 의미 그대로 쓰이는걸 의미합니다.
디자인과 구조의 분리를 해야 하는것이 아니라 사실상 원래 그랬어야 하는것인데.
table기반의 코딩 방식이 그것을 이상하게 꼬인채로 진행을 시켜버렸던 것이죠.

css기반의 코딩방식은 디자인과 구조가 분리되는 원래 의도대로 사용을 할수 있게 해줍니다. 원래 되있어야 하는 디자인과 구조의 분리인거죠.

정리를 좀 해보면
웹표준 기반의 div방식으로 코딩을 하게 되면 디자인정보는 모두 css로 옮겨갈수 있고 body구간의 html태그들은 본래목적의 역활들을 할수 있게 되는겁니다. 구조와 디자인이 분리되는 순간입니다.

이렇게 웹표준기반 방식은 우리가 눈으로 보는 화면인 웹페이지의 view와 body에 선언되는 태그들 간의 디펜던시를 없애줄수 있습니다.
그 연계성을 없애주는 역활은 바로 CSS가 됩니다.
모든 디자인 요소가 css로 옮겨지면서 css로 제어가 가능하게 때문에 body에 선언된 html태그와 데이터값들은 손대지 않고 view의 모습을 제어할수 있게 면서 화면과 구조사이에 연계성은 없어지고 그 둘간의 조율은 디자인 정보인 css가 도맡을수 있게 됩니다.

화면과 구조 사이의 연계성이 없어진다는건 많은 자유로움을 의미하는데요. 우선 원래 선형적인 기존 웹개발 프로세스상 디자인 아웃풋이 있어야먄 그를 바탕으로 html코딩이 시작될수 있었는데 구조와 디자인의 분리를 바탕으로 디자인 아웃풋 없이 스토리보드만으로 HTML개발자들은 선작업이 가능해집니다.

일명 코드 정보설계라는 과정을 진행할수가 있습니다.
코드 정보 설계란 말은 메타데이터인 html태그들을 스토리보드의 내용을 파악해서 미리 그에 맞는 구조화된 데이터를 설계함을 의미합니다.
"코드 정보 설계도" 란 각 프로세스 초기작업들인 기획의 스토리보드, 디자인의 시안, 웹개발의 DB디자인 과 같은 맥락으로 표현한 것 입니다.

이런 코드 정보설계란 단계를 진행하면 스토리보드가 나오자 마자 디자인 시안 작업과 병행으로 코드정보 설계를 진행할수 있게 되고
개발자들은 화면에서 구조 부분에 해당하는 곳에서 개발코드를 입히게 되니깐 코드 정보 설계가 끝나는대로 그 설계도를 바탕으로 웹개발 작업 역시 병렬 형태로 진행이 가능하게 됩니다.
화면과 같이 CSS를 통해서 화면과 구조가 분리되듯이 디자인과 개발간의 연계성은 없어지는 형태가 가능해집니다.

개발 모델중 Model과 View사이의 커플링을 막아주는 Control과 같은 역활을 CSS가 해주면서.. 마치 MVC패턴과 같은 형태를 보이고 있습니다.
이해를 돕기위해 억지스런면도 있지만, 이해에 도움이 될것 같아서 비교해봤습니다 ㅎㅎ

웹개발 프로세스에 사용할 웹표준이점중 하나는 찾은것 같습니다.

웹표준 기반 웹개발 프로세스

기존 프로세스의 가장 큰 문제점이 각 단계별 디펜던시가 높아서 업무가 선형화 되는 문제였는데, 이 선형화 문제는 웹표준을 통해서 디자인과 개발의 디펜던시를 없애면서 병렬형태로 진행이 가능해집니다.

기존 개발 프로세스인 이런 선형적인 기존 흐름에서 웹표준의 구조와 디자인의 분리를 통해서 각 디자인과 개발사이의 연계성을 제거 하게 됩니다.

html자체가 구조와 디자인으로 분리되면서 디자인과 개발의 디펜던시를 없애주는 효과를 보여주게 됩니다.

앞에서 기존개발 프로세스의 문제점을 예기하면서 비효율성의 원인을 선형적인 작업flow라고 했었는데, 각 업무간 연계성이 없어지면 개발 프로세스가 더 이상 선형화될 이유는 없습니다.

스토리부터 각 단위 업무들은 동시에 시작이 가능하게 됩니다.
물론 개발자는 html "코드정보 설계도"를 받아야 시작이 되겠지만 디자인요소가 없는 상태의 코드정보 설계도는 DB디자인이 끝날때쯤엔 충분히 전달이 됩니다.

이렇게 디자인, HTML, 개발 업무가 동시에 진행되게 되면 업무는 일정감소라는 성과를 예상할수 있습니다.
프로젝트 진행하면서 프로젝트가 성공적인지 판단하는 기준중 하나가 일정준수도 포함될텐데요..
이러한 웹표준기반의 프로세스가 일정 준수를 넘어서 일정을 줄일수 있다는것에 저는 굉장한 가능성을 보고 있습니다.
웹표준을 계몽적인 문구들로 호소할 필요도 없습니다.

일정절약 이라는 사례를 구체화 시켜주고 실존모델이 있다면 우리 사장님들. 회사에 운영을 책임지시는 분들에게도 웹표준은 골칫거리가 아닌 귀염둥이로 다가갈수 있을거란 생각을 해봅니다.

또, 교집합 요소였던 html을 전문UI개발자가 도맡게 해서 업무별 디펜던시를 해소시키면
디자이너는 디자인에 집중할수 있게 해주고, 개발자는 개발에만 전념할수 있게 해주게 됩니다. 결국 그 집중도를 통해 전체적인 프로젝트 퀄리티는 보다 높아질수 있을거란 예상을 해볼수 있습니다.

하지만 이런 웹표준을 이용한 병렬업무 진행을 하기 위해선 전제조건이 필요합니다.

1. 준비된 UI개발자와
2. 웹표준의 바람이 단순한 계몽적인 움직임이 아닌 효과적인 자원절감 의 열쇠가 된다는 업계의 인식이 필요합니다.

쉽진 않지만 구체화되거나 실제 사례의 웹표준 기반의 웹개발 모델을 만드는것은 멀지 않았고 곧 다가올 2007년안에 될것 같은 느낌입니다.
저만의 생각은 아니길 바랍니다 ^^

마지막으로 웹표준 광고 문구를 준비해봤습니다.

이상 NHN 박태준 이였습니다.

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

지난 12월 21일 웹월드컨퍼런스 발표를 하고 왔습니다.
예상치 못하게 PT세팅이 잘 안되어 준비해간 내용을 잘 전달하지 못해서 너무나 마음이 아픈 발표였습니다 ㅜ_ㅡ (물론 부족한 제탓입니다만..)
무엇보다 준비해간 내용중 60%정도 밖에 내용을 전달 못한것이 가장 아쉬웠습니다.
게다가 발표를 끝내고 오는 중에 접촉사고를 당해 차고 입고 되야 하는 아픔까지 겪은 참 파란만장한 하루가 아니였나 싶습니다 ^^;
하지만 같이 간 팀원분들의 진심어린 마음이 감사하게 전해진 날이기도 했답니다.

부족하지만 발표한 내용을 다시 정리해 올려봤습니다.
2006년 한해 마무리 잘하시길 바랍니다 :)