개발&Development/개발방법론

공감 조직

겐도 2008. 6. 9. 06:23

전통적인 상하적인 조직에서는 비젼의 공유가 중요하였다. 총대를 맨 한사람 아래에 그사람의 의지를 공유한 사람들이 동일의 비전하에 일을 수행한다. 각 구성원의 공유가 잘 될 수록 일은 잘 진행될 가능성이 높다. 장점으론 공유의 코스트만 들인다면 이후 일사천리로 일이 진행될 수 있다. 단점은 집단이 동일한 시각을 가짐으로써 집단의 오류를 일으킬 가능성이 높다거나 정점의 사람의 판단에 의존성이 높다. 고전 게임중 하나인 "레밍즈" 처럼 잘 가이드된 쥐들은 무사히 목적지에 도착할 수 있지만 집단의 오류에 빠져 버리면 불구덩이속으로 집단은 달려가게 된다. 소위 "효율적인 도박"을 하는데 적절한 방법이라 볼 수 있다.

최근의 팀 구조나 Open Source Project에서 보여주는 방식은 구성원의 공감을 통한 진행이다. 오늘 Textcube 1.7이 발표되었는데 이 프로젝트의 구성원인 TNF의 경우 이 방식의 장단점을 본인이 잘 볼 수 있는 케이스중 하나이다. 가령 포럼에서 누군가 의견을 제시하더라도 그것이 실제 TC에 적용되기 위해선 많은 사람들의 공감을 요구한다. 조직의 수장이라 할 수 있는 정규님도 기능을 다 구현하고도 공감을 얻지 못하면 roll-back을 당한다. 새로운 커밋터(Commiter - 코드를 직접 수정할 수 있는 권한을 가진 사람)을 선출함에도 그 방식에 대해 리딩을 하는 사람은 있어도 최종 방법이 나오기 까진 많은 논의와 공감과 동의을 필요로 한다. 의사 진행은 느릴 수 밖에 없지만, 대신 구성원들의 노력을 최대한 끌어 낼 가능성이 높다던가 한 문제를 두고 다양한 시각을 통한 문제 해결을 도모할 수 있다는 방법이 있다. 물론 집단의 오류에 여전히 빠질 수 있다. 집단의 특성 혹은 대다수를 차지하는 구성원의 특성에 의해 집단의 시각이 고정될 수 있기 때문이다.

후자의 방식은 관리자의 입장에선 매우 곤란해질 가능성이 높은 조직이다. 구성원들의 공감에 얼만큼의 시간이 소모될 지 예측하기 힘들기 때문이다. 또한 열정을 가진채 탄생하였다면 몰라도 그저 소집된 인원이라던가, 혹은 장시간이 가져다 주는 피로감에 열정이 식어버리면 원래 조직의 가져야할 장점들은 다 사라져 버리고 어중간한 전자의 조직 형태를 뛰게 될 수 있기 때문이다. 양쪽의 단점만을 취한채 "죽음의 행진"을 시작할지도 모른다.

공감 기반의 조직에 좀 더 끌리는 것은 개인적인 경험에 따른 것일지도 모른다. 첫 프로젝트부터 3~4인의 팀프로젝트부터 하였고, 대학의 많은 강의들에서도 3명 정도의 팀프로젝트를 많이 하였다. 회사에서는 "1 리더 + 3인방" 체계로 개발을 하였다. 자신의 생각을 끊임없이 구성원들에게 검증받으려는 노력이었겠지만 자연스레 의견이 첨가되고 문제점들이 수정되어 나간다. 더불어 최근 몇년간 이런 형태에 대해 좀더 생각해 보게 된 것은, 현대의 프로젝트는 혼자의 힘으론 할 수 없을 뿐더러 현대의 프로덕트는 한사람의 머리로 완벽한 모습을 그려 내기 보다는 다양한 머리가 동원되어야 확률이 올라갈 것이라는 생각이 들어서이다. 적어도 확실한 것은 나의 지식이나 경험조차 편항되어 있고 모든 케이스를 알고 있고 모든 시야를 볼 수 있는 사람이 존재할 확률은 극히 낮을 것이라는 가정때문이다. 아무리 뛰어난 사업가라도 개발적인 부분에서 나보다 뛰어날 확률은 높지 않을 것이다. 분업이라는 현대사회의 개발시스템 특성상 한 사람이 모든 부분을 잘하긴 힘들기 때문이다. 그리고 분야별 전문가가 존재하는 이유도 그럴 것이다.

공감시스템에 참여하는 단위는 3~4개가 적당하지 않은가 한다. 한번에 고민하는 인원이 저정도가 적당할 것으로 보인다. 전체적인 구조는 상황에 따라 병렬 팀 구조나 수직적 트리구조를 가질 수 있다. 중간 리더급 인력이 3~4개의 단위(팀)에 참여해서 공감된 내용을 위로 들고 가서 논의하거나 위에서의 내용을 아래에서 공감작업을 할 수도 있다. 조직의 25% 정도가 공감작업에만 소모될 가능성도 있지만 파티셔닝을 통하여 해당 조직의 사이즈를 적절히 조정한다면 공감작업의 코스트가 10% 미만까지도 떨어지지 않을 까 하는 생각이 든다.

최근 낙하산 브레인에 쓴맛을 본 모 조직이나, 잘나가는 외국계 그 기업을 볼때(더불어 보아온 케이스 등등등) MS의 "빌 아저씨"의 시대는 가고 공감조직이 분명 성공 확률을 높이는데 좋지 않은가 한다. 물론 "스티브 아저씨"의 기업이 절대적이지는 않음을 보여주고 있긴 하지만 말이다.

일단 내가 슈퍼맨-모든 분야에 전문가가 아니라는 사실, 그리고 많은 공감 모델을 통한 장점을 맛본 나로서는 손이 갈 수 밖에 없지 싶다.

'개발&Development > 개발방법론' 카테고리의 다른 글

저도 코던데요  (2) 2008.11.12
개발자 교육  (0) 2008.06.13
웹기획  (5) 2008.01.31
Tistory Project review 조금  (1) 2007.10.22
아름다운 구현이 최고인가?  (3) 2007.05.31