Flying Mate

어떤 분야에 대한 정보가 전혀 없는 상태에서는 가리지 말고 무조건 많이 읽어서 익숙해져야 하고, 정보가 쌓여가는 중에는 축적된 정보간에 체계를 잡아주면서 정보의 질을 판단할 수 있는 분별력을 길러야 한다.

정보가 충분히 축적되어 그 분야에 대해 성숙한 관점을 갖게 될 즈음에는 실행의 비중을 높여야하기 때문에 정보 소비를 줄이게 된다. 이 단계에서는 수없이 많은 정보 채널을 알고 있고, 수없이 많은 관심사를 갖고 있기 때문에 정보 소비를 줄이지 않으면 수많은 관심사와 관련된 수많은 정보 채널들로부터 매일 날라오는 피드 폭탄에 질식할 수밖에 없다.

이런 정보의 양을 감당하겠다고 욕심을 부리면 실행할 시간을 빼앗기거나, 다른 분야 또는 다른 관점에 대한 정보/능력 습득의 기회를 놓칠 수도 있다. 완전히 다른 분야를 시작하기 위해서는 충분한 여유시간이 필요하다. 꾸준한 습득은 필요하지만 과한 습득은 다독 또는 다 안다 라는 자기만족 이상도 이하도 아니다.

정보는 끝없이 생산되고 또 시간이 갈수록 생산되는 양도 더 많아지는데 그것을 다 소화할 수는 없다. 끊임없이 읽는데도 읽어야 할 것은 늘어가고, 읽지 않을 딜리셔스 북마킹은 쌓여가고 있다면, 더 중요할 수 있는 다른 것들을 놓치고 있다는 이야기이다.

정보를 습득하는 데는 시간이 필요하기 때문에 정보들간의 우선순위를 파악해서 중요한 것들을 먼저 확인하고 우선순위 뒤에 있는 것들은 무시할 수 있어야 한다. 내가 사용하는 방식은 토픽을 아주 좁게 선택해 일정 기간동안 그것만 파고드는 것인데, 시간을 충분히 들이면 뜬구름 잡는 수준에서 벗어나 꽤 디테일한 파악과 실제 활용까지 해볼 수 있기 때문에 그 주제를 '졸업'했다고 말할 수 있게 된다.

하나를 졸업하면 그 형제뻘 부모뻘 자식뻘 되는 토픽들은 그 패턴과 유사하게 해석할 수 있어서 이해가 쉽다. 그리고 해당 토픽과 관련해 해석, 예측하는 것에 관심을 갖기 보단, 그것이 실제로 어떻게 동작하는지, 어떻게하면 만들 수 있는지, 누가 만들고 있는지에 집중한다.

예를 들면, 안드로이드나 아이폰 앱 스토어에 대해 관심이 있다면, Techcrunch나 CNet을 읽는 것이 아니라 개발문서를 보거나 SDK를 받아서 직접 개발해보는 것이다. Hello World만 찍지 말고 에어로미터와 OpenGL/AL API 사용해서 3~7일 프로젝트로 매달려보는 것이다. 뜬구름 잡는 해석, 과장된 예측, 비장하게 풀이된 경쟁구도 같은 것에 휘둘리지 않고, 아예 제대로 발을 푹 담그는 것이다.

그 토픽에 대한 장미빛 예측이 결과적으로 맞는다면, 발을 담그고 있는 나에게도 좋을 것이고, 사실상 별 것 아닌 것으로 판명난다 해도 난 나름대로 배운 것이 있으면서 다음 번 예측에 필요한 인사이트를 얻은 것이니 역시 나쁘지 않다. 이런 인사이트는 Techcrunch를 매일 읽는다고 해서 생기는 게 아닐 것이다.

지금 당장 발을 푹 담글 것이 아니라면, 아예 관심 끄고 더욱 시급한 것, 바로 지금이 타이밍인 것에 집중하는 것이 낫다. 나중에 진정으로 관심이 생겼을 때, 그것이 폭발하는 시점에 달려들어도 늦지 않다고 생각한다. 세상은 관심을 끄고 보면 빨리 변하지만 관심을 갖고 보면 느리게 변한다.

좀 다른 토픽을 예로 들면. 내가 잠깐 주식에 관심이 있었을 때, 일반적인 개미 투자자가 접할 수 있는 HTS 강좌, 좀 더 낫다 싶은 사람들이 하는 기본적 분석, 기술적 분석, 그리고 수많은 증시와 차트 분석 책들을 거쳤고, 나중에는 워런트나 옵션도 좀 공부했는데, 그리고 나서 얻은 결론은 이렇게 겉만 핥아서는 돈과 시간만 버린다는 것이었다.

주식을 하려면, 아니 금융을 하려면 금융공학을 하고 수치해석을 하고 퀀트들이 하는 모델링 프로그래밍을 해서 통계적 차익거래를 해야 한다. 사실 나도 이게 무슨 말인지 잘 모르겠고 또 지금은 이쪽과 관련해 내가 잘 모르는 것들을 구체적으로 배울만한 좋은 시기가 아니라고 생각한다. 하지만 언젠가 주식이 하고 싶어지면 차트분석책이나 증권뉴스가 아니라 금융공학 책을 들어야 겠다는 확신은 있다.

새로운 웹서비스의 참신한 인터페이스라면, 몇 번 클릭해보면서 테스트하거나 수많은 리뷰들 읽는 데 시간을 쓰기보단(물론 필요한 과정이다. 과하면 안좋다는 뜻), 기획서에 옮겨담아 보면서 그 기획자의 사고방식을 모방해보는 것이 낫고, 프로그램 라이브러리를 사용한다면 API문서를 외우기보단 소스코드를 이해하는 것이 낫다고 생각한다.

핵심을 곧바로 겨냥하면, 중요하지 않은 2차, 3차 정보들은 우선순위 뒤로 밀리면서 나의 시간을 빼앗기지 않을 수 있다. 지금처럼, 정보가 부족해서가 아니라, 정보를 찾지 못해서, 또는 정보가 너무 많아서, 또는 정보의 중요도를 판단하지 못해서 기회를 놓치고 있는 시대에는, 핵심을 보고 실행에 집중할 수 있는 노하우가 필요한 것 같다.

나 스스로에게, 그리고 이 글을 보는 다른 누군가에게 의미가 있는 글만 쓰고 싶다는 욕심이 있다. 그래서 블로그 에디터를 열어놓고 장문의 글을 써내려가다가 임시저장해놓고 영원히 묵혀두는 일이 많다. 내가 이 글을 뭐하러 쓰고 있지? 누군가가 썼을텐데? 이게 나에게 의미가 있나? 보는 사람에게 의미가 있나? 라는 회의감에 젖어.

글이 항상 무거워지고 단락이 늘어나고 포스팅 주기가 길어지는 이유이기도 하다. 의미 있는 글이라.. 과도한 욕심이다. 나도 분명 드라마를 보고 영화를 보고 음악을 듣고 웹툰을 보고 디바이스와 신규 웹 서비스에 관심이 많으니, 많은 취향이 있고 누군가에게 떠들고 싶은 화두도 많다. 그런 주제로 글을 쓰지 못하는 것은 순전히 이런 강박관념 때문이다.

누군가에게 들었던 조언은, 블로그를 컨텐츠로 채우지 말라는 것이었다. 사람들이 블로그 주인장이 아니라 블로그 컨텐츠를 보러 방문하고, 그 컨텐츠를 보고 만남을 요청해서 관계가 시작되면 그 관계조차 서로에게 하나의 컨텐츠 채널이 될 뿐이라는 의미였다.

꼭 그렇다고 생각하지는 않지만, 저널이나 미디어가 되고자 하는 욕구가 생기기 시작하면 얻는 것 만큼 손해보는 게 있다는 사실에는 공감한다. 그래서 프로덕트를 만들 때는 최우선적으로 대중성을 생각하지만, 글을 쓸 때는 대중성을 배제한다. 어려운 주제를 다룬다고 할 순 없지만, 쉬운 문장으로 표현하기 위해 노력하지 않는다.

내가 블로그를 하는 이유는, 아마도 나를 좋아해줄 사람들을 찾기 위해서인 것 같다. 나를 좋아하는 사람은 내가 좋아할 확률이 크다. 지금 내 블로그를 보고 계시고, 덧글을 달아주시는 분들은 거의 100% 내가 좋아하는 타입의 사람이다. 나는 좋아하는 타입과 그렇지 않은 타입이 선명하다. 전자의 타입은 전체 인구 중에 아주 작은 비율일 것이다.

그래서 취향과 관련된 화두로 글을 쓰지 못하는 것일지도. 드라마, 영화, 음악, 애니를 좋아하는 사람은 너무 많아서 내가 좋아할 만한 소수의 사람들을 발견하기 어려워지니까. 그리고 난 나와 같은 취향의 사람들을 발견하기 보단 비슷한 방향의 비전 또는 비슷한 크기의 비전을 가진 사람들을 발견하고 싶다. 성향과 능력은 다양한 사람들을. 언젠간 틀림없이 함께하게 될 거라는 기대가 있다.

나는 26살의 대학생이다. 컴퓨터과학을 전공하고 경영학을 부전공하고 있다. 하고 있다. 휴학 제한 기간을 최대한 활용하고 있는 장기 휴학생이다. 전공, 부전공 수업과 인문학 수업을 청강하고 타 학교의 유명하다는 과목도 종종 청강한다. 학교 도서관의 휴학생 대출을 애용한다. 초면인 사람에게 내가 대학생이라는 사실과 내 나이를 굳이 밝히지 않는다.

나는 26살의 수강생이다. 외국어학당에서 비즈니스 영어를 익히고 매주 개발 스터디, 매월 개발 세미나에 가면 열심히 필기와 토론을 한다. 한 달에 5권의 기획/개발 실무서를 보고 5년 간 하루에 수십 페이지의 포스트와 도큐먼트를 읽었다. 학습 측면에서 타인에게 지는 것을 참지 못한다.

나는 26살의 직장인이다. 휴대폰 판매사원으로 일하기도 했고 주먹밥이나 악세서리도 팔아봤고 돈까스집 알바로, 과외 선생님으로, 어떤 회사에서는 웹 서비스 기획자로, 프로젝트 메니저로, 어떤 회사에서는 창업 멤버로 일했으며, 지금은 서버/클라이언트 개발자로 일한다. 웹표준 디자이너로 일해보고 싶고 '부장님'과 마케터 타이틀을 가져보고 싶기도 하다. 언젠가는 영화 감독과 작곡가, 에니메이터, 시나리오 작가, 회로 설계, 금융 공학, 게임 개발 전문가를 틀림없이 해볼 것이다.

나는 26살의 창업자다. 서버 사이드를 개발하고, 자바스크립트도 개발한다. UI개발을 하고 로고와 버튼 디자인도 한다. 기획서를 그리고 사업계획서와 프리젠테이션을 만든다. 창업회계를 하고 경영과 마케팅을 익혔다. 업계의 굵직한 소식은 공개적/비공개적으로 듣고, 스타트업이나 관심있는 분야의 비즈니스와 관련된 거라면 국내외를 떠나서 자잘한 것까지 알고 있다.

나는 26살의 몽상가다. 시가총액 100조원의 회사를 설립하는 것이 목표이고, 100조 목표가 달성되면 1000조, 1경이라는 새로운 목표들까지 미리 세워두고 있다. 성공할 때까지 무한대로 시도하면 실패 가능성은 제로로 수렴한다고 믿으며, 무한대로 시도할 수 있으려면 비용을 제로에 가깝게 끌어내릴 수 있는 제로 코스트 비즈니스를 해야 한다고 고집을 피우고 있다. 돈을 벌면 비영리 대안교육 재단을 만들고 국내외 소외된 계층의 아이들에게 교육과 양육을 제공할 것이다.

나는 26살의 외동아들이다. 집에 밥이 없으면 쌀을 씻어서 밥을 해놓고, 설거지감이 많으면 고무장갑을 낀다. 어머니가 장 볼 것이 많으시다 하시면 장바구니를 들고 뒤따르고, 계란이나 우유가 떨어지면 알아서 채워둔다. 아버지나 내가 집을 나설 땐 어머니의 포옹을 받는다. 배가 고프면 난폭해지고 갈치나 조기는 알아서 다듬어서 구워먹으며 국이 없으면 국타령을 한다. 집밥이 익숙해 밖에서도 한식이나 급식이 제일 좋다.


요즘 가장 큰 고민은, 변해야 하는가, '아니면 조금만 더 있다가' 변해야 하는가이다. 지난 4년 간, 지식적인 측면을 최대한 끌어올리기 위해 비장하기도 하고 공격적이기도 한 아이덴티티를 유지해왔다. 최근 2년 간 많이 변했다고 스스로 평가해봤지만 따지고보면 기획 베이스에서 개발 베이스로 바뀐 것이었지 성향은 전혀 변하지 않았다. 중간중간 좀 여유로워지기도 하고 사교적인 행세를 해보기도 했는데 결국 다시 치열하고 계산적인 상태로 돌아왔다.

사람을 사귀는 기준도 그에게 배울 것이 있는가, 어떤 모임이나 행사에 시간을 할애하는 기준도 그곳에서 배울 것이 있는가 였다. 솔직히 이런 성향 덕분에 굉장한 이득을 보았다. 하지만 이면에는 (손해를 보았다기 보다는) 얻을 수 있는 다른 이득을 놓쳤다는 느낌. 이득이란 단어도 계산적이다. 행복. 행복을 조금씩 놓쳤다. 그 행복 속의 기회도.

나는 다른 사람의 개인적인 이야기에 잘 감동하고 뭉클해하며 눈물도 잘 맺힌다. 외로움을 잘 타서 사람 만나기도 좋아하고 한 번 누구를 만나면 그와 나누었던 대화들을 곱씹어보느라 잠에 들지 못하고 심지어 그와 이야기를 나누는 꿈까지 꾼다. 그가 내 말을 들어주는 것도, 내가 그의 말을 들어주는 것 모두 좋아한다.

그런 관계, 그런 대화를 의식적으로 제거해왔던 것이 지난 4년 이었다. 여행, 휴가 같은 건 사전에서 지워버렸다. 요즘 문득 비즈니스 이외의 주제로 대화하는 것이 너무나 어색한 스스로를 발견하게 되었다. 주변에는 목표가 커다란 친구들만 남아있고 그들과 만나면 역시나 커다란 목표와 오늘의 성장에 대해 이야기했다.

목표하는 바가 있고, 그것이 다른 사람들의 목표보다 훨씬 큰 것이기에 삶의 여유를 어느 정도 포기해야 한다고 각오해왔다. 포기했던 여유를 되찾을 때인가 아니면 치열함을 아직 유지해야 하는가. 나의 몽상가적인 목표를 유지하면서 지금 벌써 삶의 여유를 탐낼 자격이 있는가 혹은 오히려 그런 여유가 목표 도달에 더 중요한 것은 아닐까, 이런 고민을 하고 있는 요즘이다.

more...

투잡 생활을 두 달째 하고 있다. 하루 4시간은 레일스 개발자로, 하루 6시간은 레일스 창업자로. 이건 정말 흥미로운 체험이다. 4시간과 6시간의 경험을 간단하게 적어볼까. 일단 오늘은 4시간.

10시에 출근해 기획팀 개개인과 개발팀 개개인이 돌아가면서 자신들이 어제 한 일과 오늘 할 일을 브리핑한다. 자신이 할 일은 자신이 정하고 우선순위도 자신이 정한다. 개개인의 역할이 커지고 책임도 커진다.

다 함께 수정할 문서는 위키를 활용하고 기획문서 교환과 피드백은 지메일을 포럼 쓰레드처럼 활용한다. 개발팀은 신중한 작업에는 언제든 페어 프로그래밍을 하고 작업량이 많을 땐 인덱스카드에 테스크를 시간 단위로 분할해서 분담해 작업하고 SVN으로 통합한다.

레일스의 MVC는 커뮤니케이션에 유리하다. 커뮤니케이션에 유리하다는 말은 사고하는 것에도 유리하고 결국 개발하는 데도 유리해지니 다 같은 말이긴 한데, 대화를 하다보면 MVC이기 때문에 소통에 이익을 얻는다는 느낌을 받는다.

'그 코드는 컨트롤러에서 자주 쓰이니 모델로 빼는 것이 좋겠다', '그건 뷰에서 일단 테스트한 다음에 컨트롤러로 옮기자' 등 모델에서 할 작업인지 컨트롤러에서 할 작업인지 뷰에서 할 작업인지를 언급하는 것만으로도 내가 말하는 의도가 전달이 된다.

커밋을 할 때면 내가 수정한 파일이 무엇이고 어떤 내용의 작업이었는지 다른 개발자에게 간단하게 브리핑하고, 업데이트할 때 머지된 부분이 있으면 설명을 요청한다. Trac 등을 사용하면 더 정확한 파악이 가능하겠지만 커밋과 업데이트가 워낙 빈번해서 상대방의 코드를 봐야 할 정도로 큰 수정은 없어서 안 쓰고 있다.

페어는 상황에 따라 이 PC에서 할 때도 있고 저 PC에서 할 때도 있는데 두 PC의 개발 도구가 완전히 달라서(압타나 vs. VI) 극과극의 체험을 빈번하게 할 수 있다. 냉탕과 온탕을 왔다갔다 하는 기분? 페어의 가장 큰 장점은 타인의 습관을 관찰하고 학습할 수 있다는 것이다.

상대방의 코딩을 눈으로 따라가면서 의도를 파악하고 잘 파악되지 않는 부분은 질문을 하거나 다른 방식을 제안하기도 한다. 내가 코드를 작성할 때는 '이렇게 하려고 한다'는 의도를 설명하면서 상대방의 제안을 귀담아 듣고 해결책을 잘 모를 때는 힌트를 요청하기도 한다.

문제를 해결할 수 있는 방법이야 수없이 많지만 가장 좋은 방법을 찾기 보다는 합리적이고 괜찮은 꽤 많은 방법 중에 먼저 떠오른 방법을 택한다. 약간의 타협인데 최고의 코드 보다는 합리적인 수준의 코드와 빠른 속도를 따르자는 암묵적인 합의.

미래의 재사용성을 고려해 메서드를 많이 만들어내기 보다는 가급적 쉽고 단순하게 구현한 뒤 그 코드를 2번 이상 똑같이 반복해야 할 상황이 왔을 때야 메서드로 뽑는다. 모듈화는 코드 재사용을 쉽게 하고, 잘 설계되었다는 인상과 프로그래머로서의 뿌듯함을 주지만, 타인이 코드를 이해하는 데 시간을 많이 걸리게 한다.

언젠가 또 사용하게 될 것 같다고 생각해서 미리부터 설계에 머리를 싸매기 보다는 가장 중요한 기능을 가장 빨리 구현할 수 있는 방법으로 코드를 작성하고, 같은 코드를 여러 번 반복하고 앉아있다는 자각이 일고 나서야 점차 코드를 리팩토링해 나가는 게 좋다고 생각한다.

4시간은 번개같이 지나가지만, 4시간이 지나놓고 보면 만들어 놓은 결과물이 결코 작지 않다. 6명 정도의 작은 팀이고 고개만 돌리면 기획팀과 개발팀이 소통을 할 수 있다. 꼭 필요한 커뮤니케이션을 30분 이내로 하고 간식을 자주 먹는다(중요). 기획팀이든 개발팀이든 하루 동안 많은 일을 한다.

하루동안 내가 작업할 수 있는 시간이 8시간이라면 일단 마음이 느긋해진다. 음악을 듣고 웹툰을 본다. 누군가 강제하지 않는다면 30분 단위로 테스크를 분할하게 되지는 않을 것이다. 아마도 오전에 할 것, 오후에 할 것, 퇴근 전까지 할 것 정도로 나누겠지.

오전 2시간 오후 2시간 사이에 식사 시간이 한 시간 있기 때문에 체감되는 시간은 더 빠듯하다. 화장실 가거나 물 마시는 시간 이외엔 따로 쉬는 시간도 안 챙긴다. 바빠서가 아니라 쉬고 싶다는 생각을 할 틈이 없을 정도로 높은 집중력을 유지할 수 있는 짧은 시간이다.

오늘은 처음으로 초과근무를 해서 총 8시간을 앉아있었는데 5시간 째 이후로는 확실히 집중력이나 작업속도가 절반 이하로 떨어졌다. 일한다는 느낌 보다는 버틴다는 느낌이 들었다. 알찼던 하루가 도로 풀려버리는 듯한. 보통의 개발자들이 이런 느낌으로 일하겠지 싶었다. 다음 글엔 '6시간' 이야기.

국내에서는 디자인 퀄리티 요구 수준이 향상되면서 디자인 및 UI 개발 프로세스가 캘리포니아와 반대로 가고 있는데, 캘리포니아 스타트업들은 가급적 포토샵 터치를 줄이는 방향으로 디자인을 바꾸고 있는 반면, 국내는 국내 포털을 따라해서 포토샵을 많이 사용하는 방향으로 디자인이 이루어지고 있다.

국내외 디자인 방식의 차이를 두고 '국내 사용자들의 눈이 높다'라고 보는 시각도 있지만, 나는 사용자들이 단지 포털식 디자인에 익숙해져 있을 뿐이고 캘리포니아식 디자인도 초반에 겪는 약간의 이질감을 넘어서면 더 '깔끔한, 세련된' 것으로 인식하게 될거라고 생각한다. 이런 방식으로 디자인하는 습관을 버리지 못했거나, 그렇게 디자인하는 사람들을 해고할 수 없는 것 뿐일 수도 있다.

국내의 디자인 방식은 UI 개발(코더) 과정을 필수적인 것으로 만들어버리고, 클라이언트 또는 서버 개발직군의 선택권을 제한한다. 가령 UI개발자의 손을 거쳐 나온 html과 css파일은 나름의 id와 class값을 가지고 있는데 자바스크립트 개발자는 동작 의도와 맞지 않는 이름의 id를 억지로 사용하거나 일일이 id값을 수정(그 id값이 위치한 css도 수정)해야 한다.

또 서버 개발자는 빌더 형태의 뷰 템플릿(레일스의 경우 HAML)을 사용할 수 없게 되고 프레임워크에서 제공하는 헬퍼 메서드(link_to 등), 코드 조각(Partial) 사용에 제한을 받거나 성가신 수정 작업을 해야 한다. 또 별도의 UI개발자가 작성한 CSS는 스타일 모듈화 보다는 엘리먼트간 스타일 간섭 최소화를 우선하고 있어서 CSS 코드 분량도 많고 재사용도 어렵고 개발한 본인이 아니면 수정도 어렵다.

나는 서버 개발자를 위한 UI개발 도우미(HAML이나 BluePrint) 사용을 반대하는 쪽이지만 어쨌든 국내 디자인 트렌드가 가져온 UI개발 프로세스가 서버 개발자들의 여러 선택권을 제한하는 것은 좋지 않은 것 같다. 물론 해외에도 UI개발 직군 및 UI 개발 프로세스가 있지만 국내의 UI개발과 해외의 UI개발은 목적과 전문성에서 차이가 있다.

내가 느끼는 캘리포니아의 UI개발 직군은 (myspace UI와 디자인을 컨설팅한 adaptive path처럼) 정말 UI 개발만을 '전문적'으로 하거나 컨설팅을 해주는 수준으로 고급화되었고, 국내는 개발자 대신 성가신 작업을 대신 해주는 코더 개념에서 크게 향상되지 못했다고 보는 것이다. 국내 디자인 형태가 그것을 조장했다고 보고. CSS를 얼마나 효율적으로 모듈화해서 사용하느냐가 아니라, 잘게 쪼개진 테두리 이미지들을 어떻게 하면 오차 없이 끼워 넣을 수 있는지를 고민해야 하는 것이다.

포토샵 작업이 중심이 아니라, CSS 스타일과 레이아웃이 디자인의 중심으로 올라오면, 디자인 프로세스 및 UI개발 프로세스의 순서가 클라이언트/서버 개발의 이전이 아닌 이후로 바뀔 수 있다. 실제로 UI/클라이언트/서버 개발을 혼자서 진행하게 될 경우 UI 개발은 앞쪽이 아니라 뒤쪽에 오게 된다. 뷰 코드를 다 작성하고 난 후에 id/class를 추가하면서 css를 작성하는 것이다.

클라이언트/서버 개발자는 디자인과 UI개발 결과물이 나올 때까지 기다리는 것이 아니라, 주요 골격을 미리 완성해놓고 UI개발자와 디자이너의 '도움'을 받는 형태가 된다.

팀의 협업 방식

프로젝트에서 팀원들의 역할을 어떻게 나누어야 할까. 가장 효율적인 팀 구성과 작업 방식은 무엇일까. 이 질문 자체만 가지고는 우문을 벗어날 수 없다. 작업 환경에 따라 프로젝트 목표에 따라 팀원들의 능력, 경험, 성향에 따라 효율성은 천차만별로 달라지기 때문이다. 그래서 환경과 목표와 사람을 좀 한정시켜보겠다.

환경은 Environment 내지는 Restriction으로서 경영진의 지원이나 사내 분위기, 자원, 복지 등이며, 목표는 Goal 내지는 Mission으로서 프로젝트의 카테고리와 타겟 마켓, 엔터프라이즈인지 컨슈머인지, 매출 목표나 UV/PV 목표 또는 퀄리티 목표 등이 있을 수 있고, 마지막으로 사람은 Team 또는 Human Resource으로서 팀원 간의 신뢰, Self-Motivating, Passion, 학습 능력, 숙련도, 협업 경험 등이 될 것이다.

이들 세 가지 조건(환경, 목표, 사람)을 특정 케이스로 한정시켜서 그 케이스 내에서 가장 효율적인 협업 형태는 무엇일지를 고민해보고자 한다. 아래 서술되는 내용은 그에 대한 가정(Assumption)들이다.


세 가지 가정

우선 환경(Environment)은 대표이사와 경영진이 변화와 학습, 소통, 수평적인 프로세스를 전폭적으로 지원하고 메니저는 통제(Control)나 관리(Management)가 아닌 퍼실리테이터(Facilitator: 촉매자)의 역할을 하도록 되어 있다고 가정한다. 퍼실리테이터 역할은 좀 복잡한데 William G. Dyer의 Team Building에서 서술하는 형태라면 적당하다고 본다. 팀원 개개인의 경험 수준보다 약간 더 높은 수준까지 책임을 위임하여 매 프로젝트마다 팀원이 더 큰 스케일의 책임감을 학습 및 경험할 수 있도록 장려한다.

그 다음으로 목표(Mission)는 신규 컨슈머 웹 서비스를 만드는 것으로 한다. 대중 사용자를 타겟으로 하며 1million UV/Month 서비스를 만드는 것이 목표라고 가정한다. 데스크탑 애플리케이션이나 위젯이 아니라 특정 카테고리 내에서의 플랫폼을 지향하는 웹 애플리케이션이며, 엔터프라이즈가 아니라 소비재 서비스라고 가정한다. 따라서 개발 생산성과 기획의 섬세함을 무기로 사용자 이용 패턴에 빠르게 반응해 사용자 볼륨을 신속하게 키우는 것이 핵심이다.

마지막으로 사람(Team) 부문에서, 팀원 개개인은 매우 이성적이고 학습 지향적이며 기존에 서로간에 협력했던 경험이 있고. 자발적이고 끊임없는 소통을 통해 서로를 신뢰하고 있다고 가정한다. 자신이 담당해왔던 직군(3년 이상)에 대해서는 높은 숙련도를 가지고 있으며 그렇지 않은 부분에 대해서도 기본적인 이해와 더불어 적극적인 학습 의지를 가지고 있다. 더불어 내가 전문 직군으로 가지고 있는 부분을 팀원에게 적극적으로 교육시킬 의지가 있다(Environment가 이를 지원한다)


가정의 한계

이 세 가지의 가정은 통계적으로 따지면 전혀 일반적이지 않다. 모두 충족시키는 경우는 굉장히 희소하다고 보는 것이 맞을 것이다. 목표 부분만 봐도, 우리가 한 번이라도 들어본 벤처나 중소기업은 소비재 상품을 만드는 경우가 많지만(그래야 귀에 익으니깐), 실제로 전체 벤처 및 중소기업 비중에서 소비재 기업의 수는 하청 전문이나 B2B(에이전시, SI, 자체 서비스가 있지만 매출의 대부분이 외주개발에서 발생하는 업체 등) 전문 업체에 비해 훨씬 적다.

사람과 환경 부분에서도 저런 케이스는 꿈의 회사라 불릴 법 하다. 다니면 다닐수록 경험과 학습이 축적되어 내 몸값이 저절로 오르는 회사. 효율성과 동기부여, 즐거운 분위기를 장려하는 신뢰 중심의 회사. 그런 회사 어디 없냐고 모두가 찾고 있는 유토피아 같은 회사다. 그럼에도 이런 가정을 하는 이유는, 이런 세 개의 가정을 충족시키는 조직 형태를 지향하기 때문이기도 하고 창업자와 경영진이 창립 초기부터 이런 방향에 대한 공감대와 의지와 운영능력를 갖고 있다면 충분히 가능한 목표라고 보기 때문이기도 하다.


기존의 협업

이런 가정들 하에 어떤 협업 형태가 가장 효율적일지를 한 번 생각해보자. 우선 하나의 프로젝트에서 각각의 팀원에게 일을 할당하는 방법은 Function별 분류와 Product별 분류가 있다. 서비스 개발 조직 내에서 Function별 분류를 해보면 기획, 개발, 테스트, 디자인, 운영 레이어로 분할할 수 있다. (서비스 개발 조직 밖으로는 마케팅, 재무, HR, 전략기획 등이 있겠다) Product별 분류를 하면 팀원의 역할 분배를 서비스 기능(Feature)별로, 함수별로, 페이지별로, 메뉴별로 쪼개는 것을 예로 들 수 있다.

스타트업에서는 창업자 둘~다섯이 필요한 걸 닥치는 대로 하기도 하고, 좀더 체계적이라면 이슈 트레커에서 우선순위가 높은 티켓을 개발자들이 번갈아 맡아서 해결해나가기도 할 것이다. 포털이 진행하는 큰 프로젝트도 하위 레벨로 가면 이와 유사하겠지만, 전체적으로는 직능별 분류 하위에 서비스별 분류로 나뉘어있거나, 서비스별 분류 하위에 직능별 분류로 나뉘어져 있어 체계가 더 잡혀 있다. Function별 분류와 Product별 분류를 조합하는 것이다. 외부 컨설팅을 받아 잦은 조직 개편을 하고 적당한 타협점을 찾아간다.

조직행동론에서는 이런 조직 구조를 '매트릭스 구조'라는 용어로 포괄해버리지만 소비재 서비스를 만드는 IT기업에서는 매트릭스 형태가 당연한 것이어서 매트릭스냐 아니냐가 별 의미가 없고 개발 최전선에서 어떤 방식으로 소통하고 협업하는 지가 더 중요한 요소라고 생각된다. 조직 구조와 더불어 TFT도 중요한 요소 중 하나이다. 고정된 구조와 상관없이 필요에 따라 TFT가 구성되고 직능별 그룹에서 인력이 차출되어 한시적으로 운영되곤 한다. 경영진 직속 조직도 대게 TFT 형태이다.

IT뿐만 아니라 모든 분야에 걸쳐서 시급하고 중요한 일에는 TFT가 결성되지만 새로운 것을 계속 만들어내야 하는 컨슈머 웹 프로덕트의 경우는 운영그룹과 유지보수그룹을 제외한 나머지는 거의 항시 TFT 체제라고 볼 수도 있으며 초기 서비스 개발기간에는 별도의 운영/유지보수 그룹이 필요없기 때문에 전사적 TFT 체제 상태가 된다. 일단 서비스가 자리잡힌 후에는 기존 서비스에 새로운 기능이 추가되는 것을 유지보수로 볼 것이냐 개편으로 볼 것이냐에 따라 고정적인 형태(조직 구조)에 무게중심을 두느냐 가변적인 형태(TFT)에 무게중심을 두느냐가 달라질 것이다.


진짜 고민

TFT가 좋으냐 매트릭스가 좋으냐 고정적인 것이 좋으냐 가변적인 것이 좋으냐는 내가 당장 답을 내야 할 부분은 아니다. 인력이 20명~50명이 넘어가면 점차 고민을 시작해야 할 문제일 것이다. 당장 필요한 결정은 2~5명의 팀이 어떻게 일을 할 것인가이고, 이런 2~5명의 팀이 여러 개가 되었을 때는 또 어떻게 일을 할 것인가이다. TDD나 버전관리, 이슈트레커, 그룹위키 등 효율성 향상 측면에서 의심의 여지가 없는 것들은 당연히 기본사항이다. 고민이 필요한 부분은 예를 들면 이런 것이다.

두 명이 작업하는 데 한 명이 클라이언트 개발자고 다른 한 명이 서버 개발자인 것이 나을까 아니면 각각이 서버와 클라이언트를 다뤄서 기능별로 분담하는 것이 나을까. html/css나 데이터베이스, 시스템은 또 어떻게 분담해야 할가. Product별 분류와 Function별 분류는 '조직'이라는 거시적인 차원 보다는 '역할'이라는 미시적이고 개인적인 차원에서 더 중요한 문제라고 생각한다. 특히 서비스 제작자가 2명인지 20명인지 여부가 서비스 성공 여부와 큰 관련이 없는 컨슈머 웹 서비스의 경우에는 더욱 중요한 문제다.

또 소통 방식과 소통 빈도를 어떻게 해야 할까. 소통 방식을 예로 들면 이슈트레커를 포함한 문서 지향적인 방식이 좋은가 아니면 메신저와 구두를 포함한 속도 지향적인 방식이 좋은가. 그 둘의 비율과 적용 형태는 어떻게 해야 할까. 소통 빈도를 예로 들면 개발자의 집중 시간을 보장하기 위해 정기적으로 정해진 시간(가령 1시간 마다 호출이 있을 때)에만 소통하는것이 나은가 아니면 신속한 소통과 반영을 위해 수시로 빈번하게 이야기를 나누는 것이 나은가.

언어와 프레임워크에 대한 이해도나 코딩 스타일의 차이를 어떤 방식으로 줄이는 것이 좋을까. 코드 리뷰나 페어 프로그래밍 만으로 충분할까. 페어 프로그래밍을 한다면 전체 업무 내에서 페어 프로그래밍의 비중은 어느 정도로 할까. 다양한 문제 해결 방식의 습득(중급자들 간의 페어), 개발 진입장벽 낮춤(중급자와 입문자 사이의 페어), 상대방의 코딩 스타일에 익숙해지고 일치시키는 것 등 페어의 목적 중 어느 것을 중시할 것인가.

기획을 전담하는 인력을 고용할 것인가. 아니면 개발 인력이 기획적 사고 방식을 가질 수 있도록 교육 환경과 시간적 여유, 페어 스토리보딩 기회를 제공할 것인가. UX/디자인 단계를 분리할 것인가 개발이나 기획 안에 포함시킬 것인가. 서비스 개발 프로세스상에서의 디자인 레이어는 기획과 개발을 단절시키는 경향이 있어서 절차적인 방식의 진행에는 디자인 분리가 잘 어울리지만 기획과 개발이 밀접하게 붙어있는 경우는 디자인 단계를 아예 개발 이후로 빼거나 기획자 또는 개발자의 역할 중 일부로 포함시키는 것이 낫다고 본다.


분할 보단 통합

나는 역할 분할 보다는 역할 통합을 지향한다. 팀이 소수여서 어쩔 수 없이 다양한 역할을 감당하는 것이 아니라, 조직 규모가 커지더라도 통합적인 역할을 유지하면서 5명 내외의 팀 구조가 마치 프렉탈처럼 분포해있는 형태를 구상하고 있다. 여기서 말하는 '통합적인 역할'은 팀 개개인이 각자의 분야(예를 들면 기획, 서버 개발, 데이터베이스)를 유지한 체 협력하는 것이 아니라 팀 개개인이 프로덕트 제작에 필요한 모든 분야(기획, 클라이언트 개발, 서버 개발, 디자인, 시스템, 블라블라)를 숙지할 수 있도록 페어로 작업하도록 유도하고 궁극적으로는 개개인이 담당하는 분야와 책임을 확대시키는 것이다.

그래서 페어(페어 프로그래밍이든 페어 디자이닝이든 페어 스토리보딩이든 페어 벤치마킹이든)테스킹이 매우 중요하고 그것의 비중과 목적을 명확히 해야 한다. 코딩 스타일을 일치시키는 것보다는 특정 분야에 대한 선임자가 그 분야에 대한 후임자에게 사고력과 숙련된 습관을 전이시키는 것을 페어의 중요한 목적으로 삼는다. 개발 백그라운드의 팀원과 기획 백그라운드의 팀원이 프로덕트 하나에 대해 기획부터 개발, 배치까지 페어로 함께 작업하도록 하는 것이다. 더불어 디테일한 지식과 정보를 개인적으로 보완하도록 업무시간 내 학습시간을 보장하고 근무시간도 줄여가는 것이 목표다.

최근 포털 조직은 상위 기획 이후에 디테일한 기획이 들어가는 단계에서 개발자가 붙어서 개발 이슈를 함께 검토하는 형태로 효율성을 높이고 있는데 그것과 유사한 점이 있다. 차이점은 내가 언급한 페어 테스킹의 주 목적은 프로젝트의 단기적인 효율성 보다는 팀원 개개인의 효율성을 끌어올려 장기적인 측면에서 조직이 역동성을 갖도록 만든다는 점이다. 개개인의 역할 통합이 이루어지면 결국 개별적인 프로젝트 효율성은 자동으로 달성될 것으로 기대한다.


우려

통합을 지향했을 때의 몇 가지 우려는, 페어를 통한 학습이 개개인의 역할 효율성을 거쳐 프로젝트 효율성, 비즈니스 효율성으로 연결되는 데 얼마나 걸릴 것인가, 프로젝트 완성과 학습을 동시에 지향했을 때 당장의 개발 효율성이 떨어지는 것을 감수할 것인가, 기존의 직능 분리와는 비교할 수 없는 개개인의 학습 요구량을 팀원들이 감당할 수 있는가, 이런 학습을 팀원들이 하려고 하겠는가 등등이다.

솔직히 이런 우려에 대한 명쾌한 대안이 있는 것은 아니다. 이런 것들이 실제로 우려할만한 것들인지 그렇지 않은지도 가봐야 알 수 있다. 그래서 이 글 서론에 환경과 목표와 사람에 대한 가정이 필요했다. 팀원 개개인이 학습지향적이고 회사가 그것을 지원하며, 프로젝트 성격이 학습지향적인 구조가 가장 효과를 발휘하는 컨슈머 프로덕트라고 가정했다. 그 가정들을 적용하면 이런 우려들은 희석된다.


분할의 이유

나는 조직이 커진다고 해서 역할이 세분화되어야 한다고 생각하지 않는다. 직능 세분화는 전문화를 노리고 수행하는 것인데 전통적인 산업의 '생산' 시스템에서는 세분화가 전문화를 이끌어낼 수 있었고 컨베이어 벨트 위에서 꽤 효율적으로 돌아갔다. 반면 소프트웨어 개발은 '생산'이 아니라 '창조 및 개발'이며, 레시피대로 요리를 만드는 것이 아니라 레시피 자체를 매번 새롭게 만드는 지식근로산업이다. 분리된 직무 하나하나를 효율적으로 진행한다고 해서 전체 프로젝트가 효율적으로 진행되는 것이 아닌 산업이다.

공장에서는 병목 지점의 효율성을 끌어올리기 위해 시간 당 작업량을 증가시키거나 인력을 투입하면 되지만 기획과 개발에서는 기획서를 많이 그리고 코드를 많이 작성한다고, 추가 인력이 많이 투입된다고 좋은 서비스가 나오지 않는다. SI, 에이전시, 엔터프라이즈는 생산의 측면을 어느 정도 갖고 있지만 컨슈머 웹 프로덕트는 이들과 비교하면 완전히 창조에 치우쳐 있다. 창조적 프로덕트를 다루는 분야에서는 분할을 통한 세분화, 전문화가 업무 효율성은 물론 동기부여와 목표 도달률을 오히려 끌어내린다고 본다.

웹 프로덕트 제작 과정을 생산 시스템으로 본다면 크게는 기획(UI, UX, 전략, 요구 분석, 운영 포함)과 개발(클라이언트, 서버, UI개발, 테스팅, 시스템)로 분리했을 때 기획 생산성과 개발 생산성, 기획 전문화와 개발 전문화가 달성될 수 있을지 모른다. 빠르게 스토리보드를 만들어내고 빠르게 소스코드를 늘려가는 것은 가능할지 모른다. 하지만 이 과정을 창조 시스템으로 보고 분할된 산출물의 개별적인 퀄리티가 아니라 전체적인 비즈니스 성과(사용자 만족도나 수익모델 발굴, 새로운 킬러 카테고리 발굴 등)로 측정하게 된다면 이야기가 달라진다.

전통적인 시스템에서 기획자는 평소에 서비스들을 벤치마킹하고 내 서비스에 대한 아이디어를 짜고 회의를 하고 스토리보드를 작성하며 어느 정도 정리가 되면 개발팀과 협의를 해서 개발 이슈를 찾아내 기획에 반영한다. 합의가 이루어지면 디자인 팀(또는 UX센터)을 거쳐 최종 인터페이스가 디자인과 함께 도출되고 개발팀에 넘겨져 페이지로 완성된다. 버그를 잡고 서버에 배치된다. 정도의 차이는 있겠지만 일반적으로 이런 과정을 거친다. (너무 당연한 프로세스라 이렇게 정리하기도 민망하다)

기획자는 개발자가 어떤 라이브러리를 사용하는지 데이터베이스가 오라클인지 MySQL인지 알 필요가 없고 개발자는 기획자가 어느 서비스를 벤치마킹 하고 있는지 장기적으로 어떤 플랜을 갖고 있는지 굳이 묻지 않는다. 직능이 분리되어 있으면 내 영역만 알면 되기 때문에 다른 직능의 영역에 간섭하지 않고, 내 직능에 영향을 미치는 부분(개발 이슈에 의해 기획이 변경되거나 개발 로드가 심각하게 많이 걸리더라도 전략상 중요도가 높으면 구현한다던가)에 대해서만 검토를 요청한다.


분할의 비용 - 커뮤니케이션

통합적인 구조를 경험해보지 못했다면 세분화 구조에서 발생하는 비용을 눈치채지 못한다. 세분화의 비용은 커뮤니케이션 비용과 책임 분산에 따른 비용, 비즈니스 기회 상실의 비용, 학습 효율성 상실의 비용, 분야 추종의 비용 등이 있다. 커뮤이케이션 비용은 세분화에 의해 문서작업이 늘어나는 것만을 의미하지 않는다. 기획과 개발 사이의 선이 명확할수록 기획서는 사전에 완벽에 가깝게 정의되어야 하며 더 상세해져야 하고, 프로젝트 메니저와 나머지 실무자 사이의 선이 명확할수록 스케쥴링은 빈틈이 없어야 하고 맨먼스에 대한 기준이 정확해야 하며, 아키텍트와 개발자의 선이 명확할수록 개발 명세가 명확해져야 하는 문제가 있지만 그보다 더 큰 문제는 종합적인 판단이 느려지고 판단의 정확도가 떨어진다는 점이다.

모든 개발 작업에는 비용과 효과 요소가 있는데 비용이 커도(시간이 오래 걸리고 어렵고 불확실성이 크고 개발자가 많이 필요) 효과도 그만큼 크다면(그 서비스로 인한 기대 수익이 100억이라던가) 그것은 개발되어야 하는 합리적인 근거가 있는 것이고, 그렇지 않다면 개발 할지 여부를 다시 판단해야 하는 것이다. 그런데 이때 개발 파트에서 그 기능의 중요도를 판단하는 근거는 기획자의 의지(고집 또는 취향)에 의존해야 하고 기획 파트에서 그 개발의 비용을 산출하는 근거는 개발자의 예측(고집 또는 취향)에 의존해야 한다. 서비스 기능의 중요도와 개발 난이도를 양팔 저울에 놓고 비교해야 하는데 실제로는 합리적인 비교가 아니라 두 파트 가운데 영향력이 큰 쪽을 따르게 될 가능성이 있는 것이다. 기획 파트에서 해야 한다고 하면 무조건 하게 되는 조직이 있고 개발 파트에서 못한다고 하면 절대 못하게 되는 조직이 있다.

반대의 경우도 문제다. 기획 파트에서는 가볍게 제안한 기능인데 구현이 까다로웠음에도 개발 파트가 기획 파트의 의견을 존중해서 그것을 구현해 내게 되면, 이제 이 기능에는 감정적인 요소가 포함되어 일종의 매몰 비용임에도 쉽게 제거할 수 없게 된다. 파생되는 부수적인 문제점은 이런 경험이 쌓여 기획 파트에서 개발 파트에 기능 제안을 할 때 심리적인 부담감을 느끼게 되거나 개발 파트에서 기획 파트의 이야기를 들을 때 방어적 또는 냉소적으로 변할 수 있다는 점 등이 있다. 물론 이런 문제는 잦은 커뮤니케이션과 서로의 능력과 의도에 대한 신뢰를 통해 극복할 수 있다.


분할의 비용 - 학습과 비즈니스 기회 상실

책임 분산의 비용은 쉽게 알 수 있듯이, 기여도가 분산되어 성과 측정이 어렵다거나 동기 부여 측면에서 불리하다는 점, 개발 파트에서 매출 등에 대해 무관심할 수 있다는 점 등이 있다. 학습 효율성 상실이나 비즈니스 기회 상실 비용은 일반적으로 비용으로 생각하지 않을텐데도 개인적으로는 가장 지불하고 싶지 않은 비용이다. 이 둘은 연결지어 볼 수 있다. 기획자가 기획자들 물에서만 놀면 제한된 관점만 갖게 된다. 개발자 역시 개발자들 물에서만 놀면 제한된 관점을 갖게 된다. 자신의 페러다임 안에 갖히는 것이다. 이 두 직군이 PC를 사용하는 방식, 웹서핑하는 방식, 그리고 읽는 글의 종류는 극단적으로 다르다. 서로간의 경험이 완전히 배타적이어서 서로가 상대방의 영역에서 얻을 수 있는 인사이트를 완전히 놓치고 있다.

기획자가 취미로 구글 앱 엔진을 써보고 오픈 API 메뉴얼을 읽고 오픈소스 커뮤니티를 돌아다녔을 때, 개발자가 취미로 UX서적을 읽고 IT칼럼을 읽고 새로운 웹서비스의 UI를 캡쳐하고 다녔을 때, 이 둘의 사고의 폭은 기존의 '기획 전문가', '개발 전문가'와 어떻게 달라질까. 더 나아가 학습하는 기획자 출신이 잘 교육받아 개발까지 하고 학습하는 개발자 출신이 잘 교육받아 기획까지 했을 때 무슨 일이 일어날까.

기획적인 인사이트를 갖게 된 개발자는 앞으로 어떤 오픈소스 프로젝트나 라이브러리를 보더라도 비즈니스와 연결지어서 사고할 수 있는 능력을 갖게 되었다. 개발 인사이트를 갖게 된 기획자는 새로운 서비스를 보게 되면 어떤 자바스크립트 라이브러리를 썼는지 어떤 메시업이 사용됐는지 파악할 수 있게 되었다. 서비스를 벤치마킹할 때 개발 이슈를 동시에 검토해버리는 것이다. 개발 커뮤니티에서의 이슈와 기획 커뮤니티에서의 이슈 사이의 시간차를 좁히는 회사가 역사상 비즈니스 승자가 된 사례가 많다. 또 무엇을 경험하든 종합적으로 보고 종합적으로 배울 수 있다. 페러다임 안에 갖힌 특정 직군과 비교해 놀라운 학습 효율성을 얻게 된다. 더불어 생산 효율성과 전체적인 비즈니스 안목도. 이제 이들은 기획자, 개발자로 불리기 애매한, 단지 '서비스 제작자'일 뿐이다.


분할의 비용 - 분야 추종

사용자 경험이든 리팩토링이든 데이터베이스 튜닝이든 모든 기획/개발 업무의 가장 중요한 목표는 사용자 만족이고 비즈니스로서의 성공이다. 세분화의 장점은 전문적인 지식의 습득이라고 했는데 전문화가 지나치게 진행되면 이것이 오히려 시야를 좁혀 자신의 업무를 비즈니스에 연결짓지 못하게 될 수 있다. 가령 인터페이스 설계의 극단으로 가면 사용자의 화면에 대한 인지적 반응속도를 계산한다거나, Eye Tracking를 기준으로 화면을 설계한다거나, input/output 데이터의 비율로 UI적합도를 측정한다거나, 버튼들의 위치좌표와 입력창을의 관계를 로그함수에 넣는다거나..

이런 것들이 '사용자 만족'이나 '비즈니스 성과'에 얼마나 밀접할지 장담할 수 없다 . 그리고 심지어 이런 고려들은 커뮤니케이션을 더 많이 만들어내고, 업계의 버즈워드에 휘둘리고, 다른 세분화된 직능의 의사결정에도 영향을 미쳐서 전체 프로젝트 생산성과 효율성을 오히려 끌어내릴 것 같다. 오늘 어떤 업무를 하더라도 이것을 왜 하는 것인지, 이 일이 어떤 효과가 있을지, 최종 목적으로 향하는 끈을 놓치 않고 있어야 하는데 업무가 점차 세분화의 극단으로 갈수록 그것이 어렵게 된다. 학창시절에 왜 공부해야 하는지 모를 경우 공부가 잘 안 되고 하기 싫었던 것과 비슷하다.

또 다른 예로 개발자의 관점에서(기획자의 관점에서도 어느 정도) 기존의 판도라TV는 비판 거리가 많았는데, 문제는 그런 비판 요소들이 대부분 제거된(앞단 광고 제외) 지금까지도 그 비판 기조를 유지하고 있다는 점이다. 파이어폭스에서 화면이 깨져보이면 엉망인 서비스라고 판단해버리거나 사파리에서 깨끗하게 보인다고 너무 심한 호감을 갖는다던지 하는 점도 서비스를 객관적으로 벤치마킹하는 데 방해가 된다. 사용자 입장에서 불만을 표시하고 호감을 표시하는 것은 문제될 것이 없지만, 서비스를 벤치마킹 하거나 내 서비스를 만드는 입장이라면 감정적, 취향적 관점을 배제하고 통계적, 비즈니스적 관점으로 관찰해야 한다.

전문화에 대한 지나친 추종이, 정해진 직능 내에서 아무런 발전도 하지 않는 것보다는 낫겠지만 통합적인 협업을 통해 다른 직능에 대한 이해를 지향하게 되면 내가 속한 직능에 대해 편향된 애착을 갖지 않고 전체 요스들을 수평선상에 놓고 합리적으로 평가할 수 있다고 기대한다. 사용자 만족과 비즈니스 성과라는 목표에 좀더 가까운 �