블루문님의 누가 웹 기획자를 미치게 하는가?를 읽어 보면 비슷한 생각을 웹 디자이너와 웹 개발자도 같이 할 거라고 생각한다. 즉, 누가 웹OOO를 미치게 하는가 하는 시리즈를 만들 수 있을 거다.

내가 한참 웹 사이트를 만들 때는 기획, 디자인, 개발 간 공동 작업이 보편화 되어 있었다. 처음 부터 서로 같이 이야기를 나누고 이것 저것 만들어 보고 기능도 넣어 봤다가 뺐다가 재미있게도 작업 했었다. 스토리 보드라는 것도 없이 끄적 거리면 개발자가 HTML로 대충 만들어 기능이 돌아가게 만들어주었다. 그걸 보고 웹 디자이너들이 입혀 주었다. 물론 10년 전 그런 작업이 원시적으로 보일 수 있겠지만, 요즘 들어서는 규격화된 서비스 프로세스 같은 것들이 거추장스러워 보인다.

기획 끝나고 스토리 보드라는 산출물 나오면, 웹디자이너가 작업하고, UI개발자가 HTML코딩하고 개발자에게 넘기는 이런 '컨베이어 벨트' 프로세스가 과연 올바른 것일까? 사실 이렇게 된 데에는 다양한 웹 사이트 프로젝트를 수행해서 돈을 버는 웹에이전시와 온갖 것을 다 가지려고 했던 포털의 섹션 구조가 한몫을 했다. 한 마디로 웹 사이트를 '찍어 내는' 일에 충실 했던 것이다. 웹 사이트 기획이나 개발이 '찍어 내는' 수준이라면 몰라도 좀 더 획기적인 사이트를 만들고 싶다면 공동의 프로젝트로 거듭나야 되는 것이다.

작년 이맘 때쯤 웹사이트 제작 3인4각, 올곧게 가기에서 말한 대로 프로젝트가 완결되기 까지 공동의 프로젝트로 만들 수 있는 방법론이 필요하다. 지금은 기획자는 A 스토리 보드 넘기고 다른 기획들어가고... 디자이너나 개발자가 A 스토리 보드를 웹 사이트로 만들 때 같이 야근하면서 B 스토리 보드 작업하고 있다. (아니면 그냥 같이 밤새 줘야 하거나.)

내 생각엔 스토리 보드를 구조화된 HTML로 만들고 그걸 개발자가 개발하고, 디자이너가 디자인을 입히는 병행 작업이 가능하다고 본다. (한번에 전체 사이트를 다 기획, 개발, 디자인 하다 보니 결국 노가다 처럼 느끼는 것일 뿐이다.) 세부 기능 하나 하나를 같이 만들 수 있는 것이다. 그러다 보면 세밀한 사용성 문제도 미리 체험해 볼 수 있고 전반적으로 QA시간이 늘어 날 수 있다. 공동작업으로 인한 팀웍은 동기 유발에도 도움이 된다. 기획, 디자인, 개발이 서로 전달 혹은 계약 관계에 있기 때문에 커뮤니케이션이 더욱 어려워 지는 것이다.

최근에 웹2.0 스타트업 기업들이 보다 획기적이고 창의적인 사이트로 우리에게 선보이는 방법도 공동 팀웍에서 오는 기획력의 승리라고 본다.