팀의 협업 방식
프로젝트에서 팀원들의 역할을 어떻게 나누어야 할까. 가장 효율적인 팀 구성과 작업 방식은 무엇일까. 이 질문 자체만 가지고는 우문을 벗어날 수 없다. 작업 환경에 따라 프로젝트 목표에 따라 팀원들의 능력, 경험, 성향에 따라 효율성은 천차만별로 달라지기 때문이다. 그래서 환경과 목표와 사람을 좀 한정시켜보겠다.
환경은 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는 비판 거리가 많았는데, 문제는 그런 비판 요소들이 대부분 제거된(앞단 광고 제외) 지금까지도 그 비판 기조를 유지하고 있다는 점이다. 파이어폭스에서 화면이 깨져보이면 엉망인 서비스라고 판단해버리거나 사파리에서 깨끗하게 보인다고 너무 심한 호감을 갖는다던지 하는 점도 서비스를 객관적으로 벤치마킹하는 데 방해가 된다. 사용자 입장에서 불만을 표시하고 호감을 표시하는 것은 문제될 것이 없지만, 서비스를 벤치마킹 하거나 내 서비스를 만드는 입장이라면 감정적, 취향적 관점을 배제하고 통계적, 비즈니스적 관점으로 관찰해야 한다.
전문화에 대한 지나친 추종이, 정해진 직능 내에서 아무런 발전도 하지 않는 것보다는 낫겠지만 통합적인 협업을 통해 다른 직능에 대한 이해를 지향하게 되면 내가 속한 직능에 대해 편향된 애착을 갖지 않고 전체 요스들을 수평선상에 놓고 합리적으로 평가할 수 있다고 기대한다. 사용자 만족과 비즈니스 성과라는 목표에 좀더 가까운 중요한 요소들을 우선순위 상위에 놓고 집중할 수 있다.
서버 개발과 클라이언트 개발의 통합
기획자 내에서도 전략기획, 상위기획, 하위기획, 사용자 요구 분석 등 직군이 다양하고 개발자도 클라이언트, 서버, 시스템, 데이터베이스, QA 등 다양한데 기획자 내에서의 업무 이동이나 개발자 내에서의 업무 이동 및 통합은 기획자-개발자 간 업무 이동 및 통합에 비해 수월한 편이다. 하지만 개발 파트 내에서도 특히 클라이언트 개발과 서버 개발 만큼은 이동과 통합이 어려운 편이다.
서버 프로그램과 데이터베이스까지는 프레임워크와 라이브러리 등이 적극적으로 지원하는 추세이고 시스템은 호스팅도 좋아지고 OS도 간편해지고 있어서, 이 세 가지는 통합이 용이하다. 그런 반면, 서버 측과 클라이언트 측은 아직까지 분리된 상태로 남아있다. 뷰 템플릿이 아무리 발전해도, 서버 프로그램 언어로 자바스크립트를 메타 프로그래밍 해주는 라이브러리가 제공되어도, html, css, javascript는 결국 새로 습득해야 되는 영역이다.
기술적으로 많이 다르다는 것도 한 몫 하지만 심리적인 장벽도 높은 것 같다. 서버 개발자는 가볍고 불안해보이는 자바스크립트를 적극적으로 배우고 싶지 않고, 자바스크립트 개발자는 자바스크립트 기교를 서버 프로그래밍에 활용할 수 없다는 점 때문에 지루해한다. 서버 측의 고민은 주로 시스템이나 데이터와 관련된 반면 클라이언트 측 고민은 인터페이스나 크로스브라우징, 룩엔필 등과 관련되어 있으니 관심사도 다르다. 이렇게 기술적 장벽과 심리적 장벽이 분명 존재하지만 그럼에도 나는 둘의 통합을 지향하는 편이다.
대부분의 서버 프로그램 개발 에디터는 자바스크립트와 html, css 개발도 지원한다. 코드 힌트가 제공되고 메서드, 변수, 주석 등의 폰트 처리를 해준다. Aptana만 해도 자바스크립트 개발 최고봉 에디터(논란의 여지 많음)이면서 레일스 개발 최고봉인(이것도 논란) RadRails가 통합되어 있다. 넷빈즈 루비 패키지를 비롯해 서버와 클라이언트를 통합하기위한 에디터 조건은 갖춰져 있다.
기술적으로는 다르지만 개발 작업 시에 둘은 심하게 밀접하다. 클라이언트 사이드를 개발할 때 특히 서버 사이드의 개발자와 빈번하게 소통해야 한다. 자바 스크립트를 객체지향으로 작성한다고 가정하면, 어떤 객체는 브라우져 내에서만 놀지만 어떤 객체는 주기적으로 서버와 소통을 하는 XHR 객체를 관리하기도 한다. 서버의 어떤 스크립트가 이 객체의 요청을 처리할지, 반환되는 데이터는 JSON으로 할지 텍스트로 할지 XML로 할지 HTML로 할지 그리고 이들의 넘겨받는 파라미터와 넘겨주는 파라미터 항목은 무엇으로 할지 등등 두 사이드가 분리되어 있을 경우 서로 협의해야 할 부분이 많고 빈번하다.
자바 스크립트와 서버 개발은 어차피 동시에 하지 않는다(물론 일정 부분은 동시에 진행할 수 있다). 기본적인 데이터 뷰잉을 서버 사이드에서 처리해준 후에 UI나 비동기 데이터 처리부분을 자바스크립트로 Unobtrusive하게 덮어 씌우는 것을 장려한다. 덮어 씌우는 과정에서 서버 사이드에서 제공할 부분, 즉 데이터를 넘겨 주거나 받는 것에 대해 협의한다.
Ajax 요소가 많을수록 협의는 더 빈번해지는데 이 때 협의되는 내용은 중요한 결정사항이라기 보다는 단지 요청의 응답과 전달 방식을 정하는 것이 전부이기 때문에 그렇게 생산적인 토론이 아니다. 내가 두 사이드를 다 개발하면서 느낀 점은 두 사이드가 두 개발자로 분리되어 있을 때 상당한 비효율이 발생하고 더 좋은 처리 방법을 놓칠 수 있다는 점이다.
서버에서 처리할 수 있더라도 어떤 부분은 클라이언트에서 처리하는 것이 트래픽 비용 절감이나 서버 자원 절감을 위해 유리한 경우가 있고, 사용자가 페이지 로딩 시의 지체를 느끼지 못하도록 일부를 먼저 표시하고 나머지를 비동기로 가져온다던가 할 경우가 있다. 이런 트릭을 구상해 내고 큰 어려움 없이 쉽게 적용할 수 있으려면, 무엇보다 이렇게 하겠다는 결정을 내리려면 두 사이드에 대한 프로그래밍 경험이 있어야 한다. 물론 경험 뿐만 아니라 실제로 둘 다 하고 있는 것이 더 좋다고 보고.
서버 사이드 개발자에게 클라이언트 사이드 지식을 교육시키고 클라이언트 사이드 개발자에게 서버 사이드 지식을 교육시키는 방법은 심플하다. 그 둘을 페어로 작업하도록 해서 클라이언트와 서버를 함께 개발하게 하는 것이다. 기술적인 차이는 있지만 어쨌든 둘다 프로그래밍이기 때문에 일단 진입 장벽만 낮추어주면 우려보단 쉽게 학습할 수 있다고 기대하고 있다. 아참, 클라이언트 사이드에서도 UI개발이라 불리는 html/css는 물론 통합에 포함되고 페어에도 포함된다.
디자인의 통합
그렇다면 디자인 작업은 언제 어떤 방식으로 이루어지느냐는 질문을 종종 받는다. 디자인은 크게 html/css에 해당되는 '코드' 부분과, 로고나 버튼, 메뉴, 배경 이미지 등의 '이미지' 부분이 있다. 코드 부분은 클라이언트 사이드를 개발할 때 동시에 진행되고, 이미지 부분은 코드가 완성된 후에 프로그래밍 흐름을 끊지 않는 선에서 투입된다. 기존의 디자인 프로세스와 가장 큰 차이점은 기획과 개발 사이에 디자인 '프로세스'가 떡하니 자리잡고 있지 않다는 점인데, 디자인은 프로세스가 아니라 '요소'로서 중간중간에 작업한다.
이런 게 가능한 이유는 기존처럼 테이블 테그로 와꾸를 잡지 않아서이다. 기존처럼 테이블 테그로 골격을 잡고 셀 안에 이미지 조각들을 채워넣는 방식으로 디자인을 하면 인터페이스 변경에 의해 픽셀 사이즈가 달라졌을 때 디자이너가 고쳐야 할 부분이 한두가지가 아니다. 그래서 디자이너는 기획서의 정확성 및 변경 불가를 요구하고 이 과정에서 기획자는 가뜩이나 서비스 아이디어로 복잡한 머리속에 픽셀 규격까지 밀어넣어야 한다. 디자인 작업에서 실제 브라우져 표시되기까지의 간극이 길기까지 하다. 디자인 작업 안에 html 코딩이 포함되고, 디자인으로 덮어씌워진 html 코딩을 받아야 개발자가 마무리(또는 이제 시작)를 지을 수 있다.
이제는 웹표준의 시대이니 만큼 서버 개발자가 뷰 템플릿 안에서 html 테그를 직접 다루고, 클라이언트 개발자(방금 언급한 서버 개발자이면 더 좋음)는 html 페이지의 레이아웃과 폰트, 백그라운드 컬러 등을 css로 잡는다. 레이아웃 위치나 가로세로 픽셀은 언제든지 코드 한 줄 수정해서 변경할 수 있고, 파이어버그를 통해 변경 전에 프리뷰를 할 수도 있다. 그리고 페이지의 모든 부분을 이미지로 채우지 않고, 필요한 부분을 정해 이미지를 백그라운드로 삽입하거나, 버튼, 아이콘, 로고 등 부각되어야 하는 요소만 간단하게 이미지 작업(직접 하든 친구에게 부탁을 하든)을 해서 채워 넣는다.
마무리
개개인의 효율성을 향상시켜 직능을 통합하는 것은 지금 시작하는 조직, 변화에 능동적인 작은 조직이 해봄직한 것이지, 규모가 커져서 조직 구조가 어느 정도 고착화되어 있는 조직에 적용하기에는 리스크가 너무 크다. 경영진의 입장에서는 이런 통합이 효율성을 담보할 수 있더라도 근로자 입장에서는 통합에 적응하는 학습 지향적인 소수만 남고 나머지에게는 구조조정 대란이 올지 모른다. 서론에서 언급한 세 가지 조건에 해당될 때만 시도해보기!
프로젝트에서 팀원들의 역할을 어떻게 나누어야 할까. 가장 효율적인 팀 구성과 작업 방식은 무엇일까. 이 질문 자체만 가지고는 우문을 벗어날 수 없다. 작업 환경에 따라 프로젝트 목표에 따라 팀원들의 능력, 경험, 성향에 따라 효율성은 천차만별로 달라지기 때문이다. 그래서 환경과 목표와 사람을 좀 한정시켜보겠다.
환경은 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는 비판 거리가 많았는데, 문제는 그런 비판 요소들이 대부분 제거된(앞단 광고 제외) 지금까지도 그 비판 기조를 유지하고 있다는 점이다. 파이어폭스에서 화면이 깨져보이면 엉망인 서비스라고 판단해버리거나 사파리에서 깨끗하게 보인다고 너무 심한 호감을 갖는다던지 하는 점도 서비스를 객관적으로 벤치마킹하는 데 방해가 된다. 사용자 입장에서 불만을 표시하고 호감을 표시하는 것은 문제될 것이 없지만, 서비스를 벤치마킹 하거나 내 서비스를 만드는 입장이라면 감정적, 취향적 관점을 배제하고 통계적, 비즈니스적 관점으로 관찰해야 한다.
전문화에 대한 지나친 추종이, 정해진 직능 내에서 아무런 발전도 하지 않는 것보다는 낫겠지만 통합적인 협업을 통해 다른 직능에 대한 이해를 지향하게 되면 내가 속한 직능에 대해 편향된 애착을 갖지 않고 전체 요스들을 수평선상에 놓고 합리적으로 평가할 수 있다고 기대한다. 사용자 만족과 비즈니스 성과라는 목표에 좀더 가까운 중요한 요소들을 우선순위 상위에 놓고 집중할 수 있다.
서버 개발과 클라이언트 개발의 통합
기획자 내에서도 전략기획, 상위기획, 하위기획, 사용자 요구 분석 등 직군이 다양하고 개발자도 클라이언트, 서버, 시스템, 데이터베이스, QA 등 다양한데 기획자 내에서의 업무 이동이나 개발자 내에서의 업무 이동 및 통합은 기획자-개발자 간 업무 이동 및 통합에 비해 수월한 편이다. 하지만 개발 파트 내에서도 특히 클라이언트 개발과 서버 개발 만큼은 이동과 통합이 어려운 편이다.
서버 프로그램과 데이터베이스까지는 프레임워크와 라이브러리 등이 적극적으로 지원하는 추세이고 시스템은 호스팅도 좋아지고 OS도 간편해지고 있어서, 이 세 가지는 통합이 용이하다. 그런 반면, 서버 측과 클라이언트 측은 아직까지 분리된 상태로 남아있다. 뷰 템플릿이 아무리 발전해도, 서버 프로그램 언어로 자바스크립트를 메타 프로그래밍 해주는 라이브러리가 제공되어도, html, css, javascript는 결국 새로 습득해야 되는 영역이다.
기술적으로 많이 다르다는 것도 한 몫 하지만 심리적인 장벽도 높은 것 같다. 서버 개발자는 가볍고 불안해보이는 자바스크립트를 적극적으로 배우고 싶지 않고, 자바스크립트 개발자는 자바스크립트 기교를 서버 프로그래밍에 활용할 수 없다는 점 때문에 지루해한다. 서버 측의 고민은 주로 시스템이나 데이터와 관련된 반면 클라이언트 측 고민은 인터페이스나 크로스브라우징, 룩엔필 등과 관련되어 있으니 관심사도 다르다. 이렇게 기술적 장벽과 심리적 장벽이 분명 존재하지만 그럼에도 나는 둘의 통합을 지향하는 편이다.
대부분의 서버 프로그램 개발 에디터는 자바스크립트와 html, css 개발도 지원한다. 코드 힌트가 제공되고 메서드, 변수, 주석 등의 폰트 처리를 해준다. Aptana만 해도 자바스크립트 개발 최고봉 에디터(논란의 여지 많음)이면서 레일스 개발 최고봉인(이것도 논란) RadRails가 통합되어 있다. 넷빈즈 루비 패키지를 비롯해 서버와 클라이언트를 통합하기위한 에디터 조건은 갖춰져 있다.
기술적으로는 다르지만 개발 작업 시에 둘은 심하게 밀접하다. 클라이언트 사이드를 개발할 때 특히 서버 사이드의 개발자와 빈번하게 소통해야 한다. 자바 스크립트를 객체지향으로 작성한다고 가정하면, 어떤 객체는 브라우져 내에서만 놀지만 어떤 객체는 주기적으로 서버와 소통을 하는 XHR 객체를 관리하기도 한다. 서버의 어떤 스크립트가 이 객체의 요청을 처리할지, 반환되는 데이터는 JSON으로 할지 텍스트로 할지 XML로 할지 HTML로 할지 그리고 이들의 넘겨받는 파라미터와 넘겨주는 파라미터 항목은 무엇으로 할지 등등 두 사이드가 분리되어 있을 경우 서로 협의해야 할 부분이 많고 빈번하다.
자바 스크립트와 서버 개발은 어차피 동시에 하지 않는다(물론 일정 부분은 동시에 진행할 수 있다). 기본적인 데이터 뷰잉을 서버 사이드에서 처리해준 후에 UI나 비동기 데이터 처리부분을 자바스크립트로 Unobtrusive하게 덮어 씌우는 것을 장려한다. 덮어 씌우는 과정에서 서버 사이드에서 제공할 부분, 즉 데이터를 넘겨 주거나 받는 것에 대해 협의한다.
Ajax 요소가 많을수록 협의는 더 빈번해지는데 이 때 협의되는 내용은 중요한 결정사항이라기 보다는 단지 요청의 응답과 전달 방식을 정하는 것이 전부이기 때문에 그렇게 생산적인 토론이 아니다. 내가 두 사이드를 다 개발하면서 느낀 점은 두 사이드가 두 개발자로 분리되어 있을 때 상당한 비효율이 발생하고 더 좋은 처리 방법을 놓칠 수 있다는 점이다.
서버에서 처리할 수 있더라도 어떤 부분은 클라이언트에서 처리하는 것이 트래픽 비용 절감이나 서버 자원 절감을 위해 유리한 경우가 있고, 사용자가 페이지 로딩 시의 지체를 느끼지 못하도록 일부를 먼저 표시하고 나머지를 비동기로 가져온다던가 할 경우가 있다. 이런 트릭을 구상해 내고 큰 어려움 없이 쉽게 적용할 수 있으려면, 무엇보다 이렇게 하겠다는 결정을 내리려면 두 사이드에 대한 프로그래밍 경험이 있어야 한다. 물론 경험 뿐만 아니라 실제로 둘 다 하고 있는 것이 더 좋다고 보고.
서버 사이드 개발자에게 클라이언트 사이드 지식을 교육시키고 클라이언트 사이드 개발자에게 서버 사이드 지식을 교육시키는 방법은 심플하다. 그 둘을 페어로 작업하도록 해서 클라이언트와 서버를 함께 개발하게 하는 것이다. 기술적인 차이는 있지만 어쨌든 둘다 프로그래밍이기 때문에 일단 진입 장벽만 낮추어주면 우려보단 쉽게 학습할 수 있다고 기대하고 있다. 아참, 클라이언트 사이드에서도 UI개발이라 불리는 html/css는 물론 통합에 포함되고 페어에도 포함된다.
디자인의 통합
그렇다면 디자인 작업은 언제 어떤 방식으로 이루어지느냐는 질문을 종종 받는다. 디자인은 크게 html/css에 해당되는 '코드' 부분과, 로고나 버튼, 메뉴, 배경 이미지 등의 '이미지' 부분이 있다. 코드 부분은 클라이언트 사이드를 개발할 때 동시에 진행되고, 이미지 부분은 코드가 완성된 후에 프로그래밍 흐름을 끊지 않는 선에서 투입된다. 기존의 디자인 프로세스와 가장 큰 차이점은 기획과 개발 사이에 디자인 '프로세스'가 떡하니 자리잡고 있지 않다는 점인데, 디자인은 프로세스가 아니라 '요소'로서 중간중간에 작업한다.
이런 게 가능한 이유는 기존처럼 테이블 테그로 와꾸를 잡지 않아서이다. 기존처럼 테이블 테그로 골격을 잡고 셀 안에 이미지 조각들을 채워넣는 방식으로 디자인을 하면 인터페이스 변경에 의해 픽셀 사이즈가 달라졌을 때 디자이너가 고쳐야 할 부분이 한두가지가 아니다. 그래서 디자이너는 기획서의 정확성 및 변경 불가를 요구하고 이 과정에서 기획자는 가뜩이나 서비스 아이디어로 복잡한 머리속에 픽셀 규격까지 밀어넣어야 한다. 디자인 작업에서 실제 브라우져 표시되기까지의 간극이 길기까지 하다. 디자인 작업 안에 html 코딩이 포함되고, 디자인으로 덮어씌워진 html 코딩을 받아야 개발자가 마무리(또는 이제 시작)를 지을 수 있다.
이제는 웹표준의 시대이니 만큼 서버 개발자가 뷰 템플릿 안에서 html 테그를 직접 다루고, 클라이언트 개발자(방금 언급한 서버 개발자이면 더 좋음)는 html 페이지의 레이아웃과 폰트, 백그라운드 컬러 등을 css로 잡는다. 레이아웃 위치나 가로세로 픽셀은 언제든지 코드 한 줄 수정해서 변경할 수 있고, 파이어버그를 통해 변경 전에 프리뷰를 할 수도 있다. 그리고 페이지의 모든 부분을 이미지로 채우지 않고, 필요한 부분을 정해 이미지를 백그라운드로 삽입하거나, 버튼, 아이콘, 로고 등 부각되어야 하는 요소만 간단하게 이미지 작업(직접 하든 친구에게 부탁을 하든)을 해서 채워 넣는다.
마무리
개개인의 효율성을 향상시켜 직능을 통합하는 것은 지금 시작하는 조직, 변화에 능동적인 작은 조직이 해봄직한 것이지, 규모가 커져서 조직 구조가 어느 정도 고착화되어 있는 조직에 적용하기에는 리스크가 너무 크다. 경영진의 입장에서는 이런 통합이 효율성을 담보할 수 있더라도 근로자 입장에서는 통합에 적응하는 학습 지향적인 소수만 남고 나머지에게는 구조조정 대란이 올지 모른다. 서론에서 언급한 세 가지 조건에 해당될 때만 시도해보기!
댓글을 달아 주세요
비밀댓글 입니다
2008/06/20 13:58