일기장/2009-10-11

나 뿐만 아니라 트위터/미투데이를 쓰는 사람들 대부분이 블로그 포스팅이 아주 뜸해졌다. 그리 좋은 현상은 아닌 듯 하다. 차분하게 생각하면서 글을 쓸 때 얻을 수 있는 것을 마이크로블로그에서는 얻기 힘들다. 나는 블로깅을 하는 가장 큰 목적이 글을 쓰면서 생각을 정리하기 위함이다. 나 뿐 아니라 많은 사람이 그럴 것이다. 그런데 트위터에서 하면 그런 정리에 이르지 못한다. 트위터의 함정에 빠지지 말아야겠다.

두어 달 NHN에서 HTML/CSS 작업을 하다보니 사이트 전체를 개발할 때는 그렇게 재미 있던 작업이 그렇게 재미 없을 수가 없었다. NHN은 이미 널리 알려진 것처럼 프로세스를 상당히 잘게 나눈다. 웹 사이트를 띄울 때 자바 비즈니스로직 개발자, JSP 개발자, Ajax 개발자, HTML/CSS 개발자가 다 따로 있다. 팀마다 차이는 조금씩 있지만 대부분 이 정도로 나누게 된다. 기획자가 기획안을 내면 디자이너가 그대로 디자인하고 PSD 파일이 넘어온다. 그러면 퍼블리셔가 HTML/CSS 작업해서 웹 개발자에게 넘겨준다. 이렇게 단계가 명확하게 분리되어 있다보니 개발자들이 기획에 참여할 기회는 거의 봉쇄되어 있다. 내가 있던 팀도 그나마 교차기능팀을 구성한 팀이었지만 일하는 프로세스는 똑같았기 때문에 대부분의 개발자는 기획에 관심조차 없었고, 관심이 있는 개발자도 발언권을 행사하기는 힘든 듯 했다. 거기에 나는 팀원도 아니고 외주 직원이다보니 프로젝트에 대해 아무 말도 할 수 없고 그저 PSD 파일대로 찍어내는 것 뿐이었다. 이러니 웹 사이트를 만드는 재미는 전혀 느낄 수 없었다. 태근이가 이런 포지션을 아주 멋진 말로 표현해주었다. 프린터. 태근이도 한 달 반 정도 일하더니 자기가 프린터가 된 것 같았다고 했다. 프린터의 속도가 PPM(page per minute)로 측정된다면 퍼블리셔는 PPD(page per day)로 측정되는 차이가 있을 뿐. 실제로 대부분 그렇게들 일하고 있었다.

NHN이 팀을 그렇게 나누는 논리는 많은 개발자들이 생각하는 것과 비슷하다. 전문화다. 기능을 세분화해서 각 분야별로 팀을 만들고 그 일만 하게 하면 그 일에 대한 전문성이 높아질 것이기 때문에 생산성이 높아질 것이라는 논리다. 거기에 공유가 더해진다. 기능별로 중복되는 것들이 많으니까 기능별로 사람을 모아놓으면 그런 중복으로 인한 낭비가 없어질 것이라고 생각하는 것이다.

이런 생각에 대해서는 이미 내_블로그/2007-09-30를 통해서 비판한 바 있다. 거기에 조금 더 할 이야기가 생겼다. 우선, 기능을 지나치게 세분화하면 전문성을 높여도 별반 생산성의 차이가 없는 분야까지 전문화시키게 될 수 있다는 것이다. HTML/CSS가 그랬다. 분명히 전문성이 필요한 기술은 틀림 없고 간단한 일은 아니지만 몇 년씩 전문성을 높여갈 만한 일은 결코 아니다. 1~2주 교육하고 2~3개월 실무로 사이트 하나 다 해보면 모든 것을 다 배울 수 있다. 물론 전문성에 따라 속도 차이는 나겠지만, 그렇다고 CSS 몇 년씩 한 사람이 하루에 10 페이지씩 찍어내는 것도 아니었다. 오히려 개발자에게 필요한 기술들(예를 들면 리팩토링)이 부족해서 생산성이 더 쳐진다는 느낌도 받았다.

하지만 웹 퍼블리셔들은 대개 HTML/CSS가 중요하고 어려운 일이라고 광고해서 하나의 직종으로 인정 받고자 하는 전략을 쓰는 것 같다. 그렇게 중요하고 어려운 일로 인정 받게 되면 개발자와 같은 대우를 받을 수 있다고 생각해서일까? 좋은 전략으로 보이지는 않는다. 그 전략대로 이제 많은 회사들이 웹 퍼블리셔를 하나의 직종으로 인정하고 있고, 하나의 중요한 역할로 대우해준다. 그럼 원하는 바를 얻었을까? 그렇지 않다. 여전히 웹 퍼블리셔의 임금은 개발자의 70% 수준도 안된다. 네이버, 다음처럼 제대로 인정해주는 듯한 회사들도 연봉을 보면 그렇지 않다는 것을 알 수 있다. 중요하고, 전문화할 가치가 있는 일이긴 한데 개발자가 하는 일처럼 중요한 일은 아니라고 보는 것일까? 그보다는 오히려 개발자의 짐을 덜어주는 역할로 보는 것이 맞을 것이다. 개발자의 일을 30% 줄여줄 수 있다면 싸게 웹 퍼블리셔 한 명 더 고용하는 게 낫다고 보는 시각인 것이다. 이 점을 웹 퍼블리셔들도 알아야 한다. 스스로를 프린터로 만드는 일이다.

어쩌면 전문화의 미신이 퍼져 있는 업계의 특성일지도 모르겠다. HTML/CSS 하던 사람이 개발도 할 줄 안다고 해도 쉽사리 인정해주려 하지 않기 때문에 한 번 발을 들여놓으면 다른 분야로 넘어가기가 쉽지 않은 것이다. 개발자들도 상황은 좀더 낫지만 비슷한 상황을 겪는다. 웹 개발 하던 사람이 C++도 할 줄 안다고 해봤자 높은 임금을 주면서 C++ 시키려고 하지는 않는다. 그래서 많은 개발자들이 처음 배운 기술로 끝까지 가는 것 같다. 그런 상황에서라면 지금의 전략이 그나마 최선일지도 모르겠다.

기능 세분화의 또 다른 나쁜 점은 중복이 발생할 가능성이 높아진다는 것이다. HTML/CSS의 경우, 자바스크립트 개발자와 분리되어 있으면 class, id 명의 중복이 발생할 가능성이 아주 크다. 웹 퍼블리셔는 일단 완성된 HTML을 줘야 하는데 id는 보통 자바스크립트에서 필요로 하는 속성이기 때문에 id가 붙을 것 같은 엘리먼트에도 그냥 class로 붙이게 된다. 예를 들면 인라인 팝업(레이어라고도 부르는)의 경우 대개 띄웠다 숨겼다를 스크립트로 하기 위해 id를 부여한다. 그런데 웹 퍼블리셔도 스타일을 주기 위해서 팝업 별로 unique한 class 이름을 주게 되는 경우가 있다. 그러면 십중 팔구 그 팝업에 필요한 id명과 class명은 아주 비슷해진다. 이런 경우 그냥 id만 쓰면 되는데도 분리된 구조에서는 그럴 수 없어 중복이 발생하게 된다. 그 외에도 개발자 입장에서 class를 써야할 때도 있는데 여러 개로 중첩된 엘리먼트의 경우 어느 레벨의 엘리먼트에 class를 붙일 것인가도 고민거리가 되는데, 이 때도 자바스크립트 개발자 따로, 웹 퍼블리셔 따로 class를 붙여서 코드가 중복으로 넘쳐나게 된다. 이 뿐만이 아니다. 서버 사이드 개발자가 서버측 템플릿을 이용하면 쉽게 중복을 제거할 수 있는 경우인데 웹 퍼블리셔는 거기까지 볼 수 있는 상황이 아니기 때문에 CSS 수준에서 중복 제거를 하느라고 더 복잡해지는 경우도 있고, 문자열 일부만 바뀌는 화면인데도 웹 퍼블리셔는 전체 화면을 다 만들어서 줘야 한다.

자잘한 문제들도 많다. 이를테면, input type="image"가 뭐가 다른지 정확하게 아는 웹 퍼블리셔는 많지 않다. 실제로 submit을 눌러서 무슨 데이터가 가는지 보지 못하기 때문이다. 그래서 원하지 않는 파라미터가 전송이 되기도 한다. 동적인 레이아웃을 구성하는 경우도 자바스크립트 개발자가 CSS를 조금만 알면 쉬운 작업임에도 늘 협업을 해야 한다. Ajax로 데이터가 오가야 하는데 서버를 전혀 모르는 Ajax 개발자와 자바스크립트를 전혀 모르는 서버측 개발자가 협업을 해야 한다면 낭비가 얼마나 심할까.

개발자에게도 통섭이 필요하다. 웹 개발을 하는데 적어도 HTML/CSS, 자바스크립트, 서버 사이드 언어 하나 정도는 알아야 한다. 이거 다 배우는데 몇 년이 걸리는 것도 아니다. 통섭으로 얻는 이득은 전문화로 얻는 이득의 몇 배는 넘을 것이다.

단순히 생산성의 문제만 있는 것은 아니다. 개발이라는 게 또 즐거움이 중요한 일 아니겠는가. NHN에서 본 것 중에 하나는, 사람들이 일을 참 재미 없어하는 것 같다는 것이다. 외주 직원인 나에게 재미 없다는 불만을 대놓고 이야기한 사람도 여럿 있을 정도였으니 내가 잘못 본 것은 아닐 것이다. 웹 사이트 개발이 창조적이면서도 참 즐거운 일이다. 그런 일을 프린터처럼 만들어버리고 있으니 안타까울 뿐이다.