슈퍼 개발자와 제약이론(TOC)

슈퍼 개발자

---

뛰어나다 못해 출중한 개발자가 한 명 있습니다. 게다가 이 개발자는 성실하고 일 욕심도 많습니다. 그래서 이 사람은 주변에 일을 도맡아 하고 실제로도 많은 일을 훌륭히 처리합니다. 회사에서는 없어서는 안 될 존재이며 회사 구성원들이 모두 이 사실에 동의합니다.

하지만 문제가 좀 있습니다. 일을 너무 잘하고 많이 하다보니 이 슈퍼 개발자의 가동률이 항상 100%를 넘어선다는 것입니다. 잠깐, 항상 100%를 넘게 일하고 있는데 뭐가 문제냐고요? 모든 개발자들이 스스로가 할 수 있는 일보다 더 많은 일을 처리하고 있다면 전체 조직의 생산성도 더 올라갈 거란 생각은 잘못된 생각입니다. 바로 부분최적화의 오류입니다.
 

(이미지출처)

많은 일을 하고 있는 슈퍼 개발자일지라도 한 번에 할 수 있는 일에는 분명한 한계가 있습니다. 게다가 슈퍼 개발자의 업무는 항상 가득 차있고, 처리할 일은 넘쳐 항상 바쁘기 때문에 슈퍼 개발자가 일을 끝내 줘야 다음 일을 진행 할 수 있는 개발자들은 자기 차례가 오지 않는 이상 작업할 거리가 없어 놀고 있는 상태가 됩니다. 슈퍼 개발자가 일을 끝내주기만을 넋 놓고 기다려야 하기 때문입니다. 결국, 전체적으로 보면 부분 최적화된 조직의 생산성은 그렇지 않은 경우보다 더 떨어지게 됩니다.
 

제약이론(Theory Of Constraints)

---

‘The Goal’ 이라는 소설이 있습니다. 엘리 골드렛(Eliyahu M. Goldratt)박사님이 쓴 책으로 1984년에 출간되었고 우리나라에서도 상당한 인기를 끌었던 책입니다. 저도 2005년 즈음에 자칫 잘못하면 밤샐 정도로…너무 재미있게 읽었던 기억이 있습니다. 그리고 이 책을 통해서 제약이론을 처음 알게 됐습니다. 상당히 설득력이 있는 이론이고 실제로 현장에 도입해서 탁월한 성과를 내기도 했다고 합니다. 

(이미지출처) 

제약이론은 간단히 말해 생산라인의 처리량을 높이기 위한 방법을 제시합니다. 제품을 생산하는 생산 라인에서 작업을 가장 느리게 하는 부분인 제약(Constraints)을 찾아 없애는 방식입니다. 전체 처리량은 가장 느린 부분에 의해 결정되기 때문입니다. 즉 병목을 찾아 개선하는 방법입니다. 가장 큰 병목을 제거하고 나면 그 다음에 나타나는 병목을 제거합니다. 이를 반복적이고 지속적으로 수행하며 병목을 제거해 나가면 전체 처리량이 점점 높아지게 됩니다.

조직

---

다시 슈퍼 개발자의 이야기로 돌아와 보겠습니다. 제약이론에 의하면 이 슈퍼 개발자는 전체 조직의 생산성 측면에서 제약(Constraint)임이 분명하며, 따라서 어떻게든 이 슈퍼 개발자같이 일하는 사람을 줄여야 합니다. 하지만 일반적으로 조직의 성과평가 시스템은 일을 많이 하고 오래하고 늦게까지 하는 사람에게 좋은 평가 결과를 부여합니다. 전체적인 조직의 관점에서는 오히려 생산성을 떨어뜨릴 수도 있는데도 말입니다. 

따라서 조직 혹은 팀 차원에서 이런 부분최적화의 오류를 분명히 인지해야 하며, 이런 문제가 발생할 경우 이를 해결하기 위한 노력을 해야 지속적으로 해야 합니다. 그렇지 않으면, 의도한 것과는 정반대의 효과를 경험하게 될지도 모릅니다.:-)