상기 인물은 내용과 상관없음.
왜 이렇게 웹에이전시는 야근이 심할까?
첫째, 사업의 태생적인 구조 문제다. 사업을 주도하는 입장이 아닌 남의 사업을 해주는 사업이다 보니 돈 문제에서 고객과 매우 불리한 싸움을 해야한다. 그리고 다른 분야보다 한결 수월하게 시작할 수 있고 진입 장벽도 낮다보니 너도 나도 웹에이전시 사업에 달려들어 경쟁이 치열해져서 수익 경쟁은 더욱 악화되었다.
둘째, 종사자들의 잘못된 인식이 문제다. 상대적으로 진입장벽이 낮은 사업이다 보니 수준 이하의 사업자들과 혈기왕성한 직원들이 주로 이 사업에 뛰어들었고 이들의 대책없는 열정 때문에 야근을 하지 않고선 살아남을 수 없는 시장 환경이 조성되었다. 야근을 마치 근면의 상징처럼 생각하는 직원들과 이런 사람을 다독거려 야근을 부추기는 사업자들이 문제의 원인이다.
세째, 일하는 방법을 모른다. 대부분의 웹에이전시는 기획 -> 설계 -> 시안 -> 코딩 -> 개발.. 순서로 작업이 이루어지는데 이는 매우 비효율적인 구조다. 그 이유는 기획자, 디자이너, 개발자 모두 구조와 표현을 나누는 방법을 이해하지 못하고 있어서 웹사이트를 아주 어렵고 힘들게 만들기 때문이다.
아래는 대부분 웹에이전들이 그러하듯 작업 프로세서 단위를 1주일로 가정하여 도표로 만든 것이다.
이런 형태가 될 수 밖에 없는 이유는 기획자는 P.T로 설계서를 만들어 넘기고 설계서를 받은 디자이너는 PSD파일로 시안을 만들어 코더에게 넘기고 코더는 이 시안을 보면서 HTML로 만들어 넘기고 개발자는 이 HTML페이지를 보면서 개발을 하기 때문이다. 이렇게 이론상으로는 4주가 걸리는 프로젝트인데 만약 기획자와 디자이너와 코더가 구조와 표현을 나누는 방법을 알고 있고 개발자가 모듈화를 이해하고 있다면 이 프로젝트는 2주면 끝날 수 있다. 어떻게 가능하냐고? 아래의 도표를 보라.
4주가 걸릴 일을 2주만에 끝낼 수 있다. 어떻게 이런 일이 가능할까? 먼저, 웹기획자는 자신이 기획하는 모든 문서를 html페이지로 만들어서 넘겨줘야한다. 구조체를 만드는 작업은 어차피 해야할 일인데 복잡하게 P.T 작업을 거치지 않고 바로 만들어서 넘기면 되는 것이다. 애초부터 이 일은 중복이었다.(웹기획자가 어떤 공부를 해야할지 몰랐을뿐) 무엇보다 이 구조체 작업이 끝나면 이걸 토대로 코딩과 개발이 동시에 이루어질 수 있다. 단, 디자이너가 HTML과 CSS를 이해하고 있다는 전제 하에서 가능한 일이다.
디자이너가 PSD로 시안을 만들어 고객에게 보여주는 것이 업계에 고착화되어 있기는 하지만 한 사람이 PSD로 디자인하고 다른 한 사람이 그걸 다시 CSS로 재작업 한다면 이 얼마나 비효율적인 작업인가? 이건 마치 반죽을 가지고 빵을 굽기 전에 구워진 빵의 모습을 미리 스케치하는 것처럼 어리석은 일이다. 반죽은 망설임없이 구우면 빵이 되듯이 웹디자이너는 기획자에게 받은 구조체를 가지고 CSS로 시안을 만들어 고객에게 보여주면 된다. 만약 고객이 승낙하면 그 시안은 그대로 결과물로 쓸 수 있는 것이다.
또한, 기획자가 만들어준 구조체를 가지고 웹디자이너가 코딩을 하고 있을 때 개발자도 동시에 개발을 진행할 수 있다. 물론, 기획자와 개발자가 구조의 모듈화와 프레임워크라는 것을 이해하고 있을 때 가능한 일이다.(웹기획자의 역량이 참으로 중요하다.)
|
1주 |
2주 |
3주 |
4주 |
|
설계 |
|
|
|
|
|
시안 |
|
|
|
|
|
코딩 |
|
|
|
|
|
개발 |
이런 형태가 될 수 밖에 없는 이유는 기획자는 P.T로 설계서를 만들어 넘기고 설계서를 받은 디자이너는 PSD파일로 시안을 만들어 코더에게 넘기고 코더는 이 시안을 보면서 HTML로 만들어 넘기고 개발자는 이 HTML페이지를 보면서 개발을 하기 때문이다. 이렇게 이론상으로는 4주가 걸리는 프로젝트인데 만약 기획자와 디자이너와 코더가 구조와 표현을 나누는 방법을 알고 있고 개발자가 모듈화를 이해하고 있다면 이 프로젝트는 2주면 끝날 수 있다. 어떻게 가능하냐고? 아래의 도표를 보라.
|
1주 |
2주 |
|
설계 |
|
|
|
|
|
|
코딩 |
|
|
개발 |
4주가 걸릴 일을 2주만에 끝낼 수 있다. 어떻게 이런 일이 가능할까? 먼저, 웹기획자는 자신이 기획하는 모든 문서를 html페이지로 만들어서 넘겨줘야한다. 구조체를 만드는 작업은 어차피 해야할 일인데 복잡하게 P.T 작업을 거치지 않고 바로 만들어서 넘기면 되는 것이다. 애초부터 이 일은 중복이었다.(웹기획자가 어떤 공부를 해야할지 몰랐을뿐) 무엇보다 이 구조체 작업이 끝나면 이걸 토대로 코딩과 개발이 동시에 이루어질 수 있다. 단, 디자이너가 HTML과 CSS를 이해하고 있다는 전제 하에서 가능한 일이다.
디자이너가 PSD로 시안을 만들어 고객에게 보여주는 것이 업계에 고착화되어 있기는 하지만 한 사람이 PSD로 디자인하고 다른 한 사람이 그걸 다시 CSS로 재작업 한다면 이 얼마나 비효율적인 작업인가? 이건 마치 반죽을 가지고 빵을 굽기 전에 구워진 빵의 모습을 미리 스케치하는 것처럼 어리석은 일이다. 반죽은 망설임없이 구우면 빵이 되듯이 웹디자이너는 기획자에게 받은 구조체를 가지고 CSS로 시안을 만들어 고객에게 보여주면 된다. 만약 고객이 승낙하면 그 시안은 그대로 결과물로 쓸 수 있는 것이다.
또한, 기획자가 만들어준 구조체를 가지고 웹디자이너가 코딩을 하고 있을 때 개발자도 동시에 개발을 진행할 수 있다. 물론, 기획자와 개발자가 구조의 모듈화와 프레임워크라는 것을 이해하고 있을 때 가능한 일이다.(웹기획자의 역량이 참으로 중요하다.)
네째, 고객들의 수정사항에 속수무책이다. 대부분의 웹에이전시는 웹사이트 제작 기간이 1달이라면 수정 기간 때문에 1~2달 더 잡아 먹는다. 이 수정사항 때문에 회사가 흔들리기도 하는데 가끔 이 수정사항 때문에 소송이 걸려서 회사가 망하기도 한다. 경영자가 기획자에게 고객과의 싸움을 요구(?)하는 것도 이때문이다.
웹에이전시 종사자들은 프로젝트 말미에 던져주는 이 '수정사항'이라는 단어에 아마 노이로제에 걸려 있을 것이다. 개발 수정이면 그나마 다행이지만 기획 수정의 경우엔 디자인 코딩, 개발까지 모두 수정을 하게 되는 것이니 얼마나 힘든 일인지 모른다.
예를 들어 고객이 설계 변경을 요청했다고 가정해보자. 설계 수정사항 하나 때문에 기획자, 디자이너, 코더, 개발자 모두가 매달려서 오랜 시간을 소모하게 된다. 아래의 도표가 그 경우를 나타낸다.
|
1주 |
2주 |
3주 |
4주 |
5주 |
6주 |
7주 |
8주 |
|
설계 |
|
|
|
설계 |
|
|
|
|
|
시안 |
|
|
|
시안 |
|
|
|
|
|
코딩 |
|
|
|
코딩 |
|
|
|
|
|
개발 |
|
|
|
개발 |
앞서 내가 소개한 작업 프로세서를 적용하면 수정 작업은 훨씬 쉬워질 것이다. 웹사이트가 구조와 표현이 정확하게 나누어져있고 프레임워크 설계가 잘되어 있다면 우리는 이런 말도 안되는 수정 과정을 거치지 않아도 된다. 설계 문제는 설계만 변경하면 되는 것이고 이와 비슷하게 디자인 문제는 디자인만 변경하면 되고 개발 문제는 개발만 수정하면 되는 것이니 수정 과정이 굉장히 빠르고 효율적으로 개선될 것이다. 아마 한주를 놀아도 기존 방식보다 절반은 빨리 프로젝트가 끝날 것이다.
|
1주 |
2주 |
3주 |
4주 |
|
설계 |
|
배낭 여행 |
설계 |
|
|
|
| |
|
|
코딩 |
| |
|
|
개발 |
|
앞서 설명한 웹 프로젝트 제작 과정에서 각 포지션에 필요한 능력을 정리하자면 대략 이러하다.
- 웹기획자: HTML 제작 능력, 웹표준/프레임워크에 대한 이해.
- 웹디자이너: CSS 제작 능력, 웹표준/접근성에 대한 이해.
- 웹개발자: 프레임워크/모듈화/UML에 대한 이해.
나는 가끔 이러한 웹사이트 개발 방법론이 업계 보편화 되는 모습을 꿈꾸곤 하지만 설령 미래에 그렇게 된다 하더라도 웹에이전시 종사자들이 삶의 질에 대한 인식을 개선하지 못한다면 지금과 똑 같이 박봉에 비참한 삶을 살 것이라고 생각한다.
보통 사람들은 야근하는 자신을 부지런하다고 생각하지만 내 생각에 야근은 또 하나의 게으름이라고 생각한다. 건강도 잃고 자기개발도 못하는 등 야근이 안좋은 이유는 여러가지가 있겠지만 근본적으로 이 일은 사람답게 살기를 스스로 포기하는 비인간적인 책임회피이기 때문이다. 정말 부지런한 것은 시간을 효율적으로 쓰는 것이다. 부지런한 사람은 할 것 다하고 만날 사람 다 만나고 잘 것 다 잔다. 우리는 일하는 사람이지 일하는 기계가 아니라는 점을 기억하자.
'UI 디자인' 카테고리의 다른 글
| 초고속 UI디자인 (0) | 2009/01/13 |
|---|---|
| 초고속 편집 디자인 (0) | 2008/11/18 |
| 야근없는 웹에이전시 만드는 방법에 대해.. (3) | 2008/06/26 |
| 고액연봉 웹디자이너로 성공하기 -4.심미성- (5) | 2008/06/12 |
| 고액연봉 웹디자이너로 성공하기 -3.사용성- (1) | 2008/06/11 |
| 고액연봉 웹디자이너로 성공하기 -2.접근성- (0) | 2008/06/10 |
댓글을 달아 주세요
g-sunny 2008/09/04 14:36 댓글주소 수정/삭제 댓글쓰기
예를든 웹에이젼시는 디자인팝과는 무관합니다....ㅎㅎㅎㅎ
김반장 2009/09/21 18:08 댓글주소 수정/삭제 댓글쓰기
지나가다 봤는데 그닥 와닫지 않는 글인듯~~
특히 개선모델로 1주 설계 2주 코딩,개발
기획자가 설계할때 html로 뽑는게 가능한일인지..
야근 없는 세상에서 살기~~ 야근하면 수당이라도 나온다면.
글에 문제가 많음을 인정합니다. ^^ 제가 1~2년 전에 쓴 이 당차고 교만한 글을 몇번이나 지울까 고민했지만 이 또한 저의 기록이고 발상의 발전 과정이기 때문에 계속 남겨든 글이지요. 지적하신대로 아직까지는 이런 업무 방식은 단지 꿈이고 허상입니다. 허나 돌이켜 생각해보면 불가능한 것은 아니기에 생각해볼만한 가치는 있다고 봅니다. 여기서 말한 설계는 화면 설계가 아닌 고객 요구사항에 의거한 컨텐츠 정의서 정도가 되겠군요. 일반적인 프로젝트는 화면 설계서를 작성하여 레이아웃을 정해놓고 세부적인 컨텐츠를 추가시켜 나가지만 이 프로젝트 방식은 세부적인 컨텐츠를 완벽하게 구축해놓은 다음에 화면 설계가 아닌 디자인을 바로 시작한다는 차이가 있습니다. 즉, 고객 입장에선 시안이 아닌 실제 완성된 디자인을 계속 평가해볼 수 있어서 을쪽에서 의도한 바를 명확하게 갑에게 보여줄 수가 있지요. 이로 인해 화면설계서 검토과정, 시안 검토 과정을 모두 생략할 수 있습니다. 어차피 최종 완성본 검토 과정이 시작되면 이전의 검토 과정들은 의미가 없어지기 때문입니다. 컨텐츠도 명확하지 않은데 메뉴 위치부터 잡는 의미없는 일은 마지막에 하도록 하고 일단 어떤 컨텐츠가 들어갈지만 명확하게 명시하고 개발과 디자인을 동시에 진행하여 시간을 아끼자는 것이 이 프로젝트 방식의 핵심이지요. 물론, 제조업처럼 수치가 명확하지 않은 웹에이전시의 상황상 쉬운 업무 방식은 아닙니다. ^^