사이드바 영역으로 건너뛰기

분업

난 요리를 하게 될 때 음식을 잘하는 사람이 주위에 있는 것이 싫다. 아무래도 먹는 문제에 대해서는 대강대강이 잘 통하지 않아서 그런 것인지 모르겠지만. 요리를 잘하는 사람들은 주위를 맴돌면서 잘못하는 것이 없나 감시하고, 만약 뭔가가 잘못되었다고 생각되면 지체없이 끼어들어 잔소리를 하며, 최악의 경우 내 자리를 밀어내고 자신이 요리를 마무리하기를 원한다. (요리에 관심있는 남성의 경우 엄마에 의해 부엌에서 밀려난 경험이 적어도 한두번쯤 있을 것이다.)

전에도 얘기한 적이 있지만, 굳이 천재적인 재능을 필요로 하지 않는 일들은 익숙해질 수 있도록 노력한다면 어느 정도 할 수 있다고 생각한다. 하지만 이와 동시에 중요한 것은 주위에서 이를 도와주어야 하고 특히 잘하는 사람의 도움이 필요하다는 것이다. 잘하는 사람은 이론적으로 잘 할수 있는 방법을 이해하기 쉽게 설명해 줄 수 있고, 많은 경험으로 배울 수 있는 노하우를 알려줄 수 있으며, 자주 범하게 되는 실수에 대해 미리 주의를 줄 수가 있다.



그러나 공동작업을 해 보면 쉽게 알 수 있듯이, 이렇게 일을 진행하면 확실히 효율이 떨어진다. 익숙하지 않은 사람은 당연히 같은 일을 하기 위해 더 많은 시간이 필요하고, 잘하는 사람은 설명하기 위해 많은 시간을 빼앗기게 된다. 그래서 아마도 대부분의 조직들은 잘하는 사람이 잘하는 분야를 책임지는 분업이라는 방식으로 공동작업을 진행하게 되는 것 같다.

하지만 이렇게 각 분야의 전문가로 구성된 사람들로 작업이 돌아가게 될 때 치명적인 문제가 있다. 한 분야에서 잘하는 사람이 빠지게 되면 그 공백을 메꾸기 위해 또다른 잘 하는 사람을 찾아야 한단 것이다. 만약 잘하는 사람을 운좋게 빠른 시간 내에 구했다 하더라도 전임자만큼 익숙해지기 위해 어느 정도의 적응기가 필요하다.그래서 그 분야에 대해 새로운 사람이 투입되더라도 쉽게 익숙해질 수 있도록 문서화나 내부교육 같은 시스템화된 업무인수체계를 갖추려는 경우가 많다.

그런데 한 때 장안의 화제를 불러왔던 XP(eXtreme Programming)라는 개발방법론은 완전히 다른 관점을 제시한다. XP는 여러 요소들로 구성되는데, 이 중 "커뮤니케이션"과 "공동 소유"의 개념이 매우 특이하다고 생각한다. XP 방법론에서는 커뮤니케이션을 매우 중요한 가치로 생각한다. 개발자-관리자-클라이언트 사이의 커뮤니케이션은 물론이고 개발자-개발자 사이의 커뮤니케이션 역시 매우 중요하다. 동시에 XP는 코드의 공동 소유를 지향하는데, 각자 맡은 부분만을 열심히 개발하고 잘 안다고 되는 것이 아니라, 다른 사람의 코드라도 자신이 수정할 수 있고 개선할 수 있어야 한다는 것이다. TDD(Test Driven Development), 페어 프로그래밍, 코드 컨벤션 등이 같이 도출되는데, 결국 XP에서는 이 방법이 더 큰 효율을 낳을 것이라고 말하는 것이다.

나는 개인적으로 분업 시스템을 대단히 싫어한다. 물론 직접 일을 담당하는 실무자의 입장에서는 분업이 매우 편리한 방법일 수있다. 하지만 분업의 결과가 장기적인 관점에서 결코 효율적이지만은 않다고 생각한다. 또한 효율성을 떠나 생각해 봐도 분업은 일의재미를 떨어뜨리고 총체적인 작업 전반에 대해 이해할 수 있는 기회를 박탈한다.

불행하게도 다양한 일을 할 수 있는 능력을 갖추면 갖출수록 더 많은 노동을 강요당하고 더 많은 책임을 져야만 하는 사태가 발생하기도 하는 것은 사실이다. 그렇지만 반대로 다양한 일을 할 수 있게 된다면 누군가의 과다한 업무를 도와줄 수도 있고 지겨운 반복 노동을 어느 정도 완화할 수도 있으며 더 많은 상상력과 다 많은 가능성을 제시할 수 있다.

그리고 이를 위해서 잘하는 사람은 다른 사람도 잘할 수 있도록 하기 위해 노력해야 한다고 생각한다.

진보블로그 공감 버튼트위터로 리트윗하기페이스북에 공유하기딜리셔스에 북마크