2007년 08월 04일
제약이론에 대한 짧은 생각
얼마전부터 XP에 대한 책을 읽고 있다. 워낙 무지몽매한 인생을 사는 탓에 이런 것이 있다는 것도 몇 달 전에서야 알았다. 바로 내가 지금 읽고 있는 책의 역자인 김창준 님의 블로그를 알게 되고서야.
XP는 분명 소프트웨어 개발에 관한 얘기이고, 개발팀을 구성하는 각 역할 분담자들의 업무 방법에 대한 얘기다. 어찌보면 웹 서비스 기획을 하고 있는 나와는 그닥 관계 없는 것일 수도 있다. 사실 책을 샀을 때에는 그 생각이 좀더 짙었고. 하지만 책을 읽어가면서 이 책에 담긴 내용들이 내가 몸담고 있는 분야에도 적용할 수 있는 부분이 있다는 것을 느끼고 있다.
책 중간에 '제약 이론'에 대한 언급이 있다. 예전에 언급한 적이 있지만, 제약 이론은 물리학자 엘리 골드렛이 제창한 이론이다. 특정 부분에 업무량이 과하게 집중되어 전체 업무 효율을 떨어뜨리는 것을 말한다. 바로 그 지점이 병목이며, 이것을 전체 업무 흐름을 조명하는 관점에서 해결해야 한다는 이론이다. 이것은 생산 제조 공장에서부터 실생활까지 폭넓게 적용이 가능하다. 내가 읽는 책에서 제약 조건의 예로 사용한 것은 '빨래'다.
세탁 45분 -> 건조 90분 -> 정리 15분
위 순서가 빨래가 진행되는 순서라 하자. 이 흐름에서 가장 심각한 병목 지점은 바로 건조 단계이다. 전체 빨래 속도를 빠르게 하기 위해 세탁기 두 대를 사용해 빨래를 한다해도 건조 단계에서 90분이 걸리는 한 빨래의 전체 속도는 전혀 앞당겨지지 않는다. 만약 빨래의 속도를 앞당기려면 병목 지점인 건조를 앞당겨야 한다. 가령 세탁기 한 대분의 빨래는 건조기에서 건조시키고, 나머지 한 대분의 빨래는 빨랫줄에 널어 건조를 시키는 방법이 있다.
우리가 업무를 진행하면서도 흔히 병목 단계를 눈으로 확인할 수 있다. 가령 내가 예전에 투입되었던 프로젝트에서는 2명의 고객 담당자 중 한 명이 결정권자였다. 문제는 이 사람이 내부 고객으로부터 자료를 수급하고, 의사를 타진하고, 의견을 조율하고, 우리에게 그것을 전달하고, 산출물을 확정 짓고 하는 기타등등의 모든 일들을 결정하고 있었다는데에 있다. 그래서 어떤 일이 일어났을까.
이 분이 회의라도 참석해 자리를 비우는 날에는 화면설계를 마친 기획자는 이 분이 올 때까지 빈둥빈둥 논다. 그 시간 동안 기획자의 문서를 기다리고 있는 디자이너도 놀고 있으며, 그 디자이너가 만든 html 문서를 기다리는 개발자도 놀고, 그것을 실제로 적용할 또 다른 고객 담당자 역시 논다. (논다고 표현했지만, 정말로 이 사람들이 무작정 노는 것은 물론 아니다. 다만 '이 업무'와 관련된 일을 진행하지 못하고 있다는 의미이다)
이 상황에서 병목은? 아이러니하게도 바로 그 결정권을 가진 고객 담당자이다. 그 사람은 자료 수급을 위한 독촉 전화, 확인 전화도 해야 하고 의견도 모아야 하고, 회의도 참석해야 하는, 아주 바쁜 하루를 보내면서도 전체 프로젝트의 속도를 떨어뜨리는 원인이 되고 있다. 문제는 이 병목 지점의 과부하를 줄이기 위해 단순히 그와 같이 일하는 고객 담당자에게 권한을 나눠주는 것으로 일이 해결되지는 않는다는 데에 있다. 업무량의 일부분을 다른 담당자에게 나눠주면 분명 이 지점은 더 이상 병목 지점이 아니다. 하지만 기획 문서의 처리가 빨라져서 디자이너에게 쏟아지는 문서량이 많아지면, 그 뒤의 프로세스에서 분명 병목이 생긴다. 또 기획자가 허비하는 시간이 없어지는만큼 또 다른 업무를 그만큼 빨리 처리하게 된다면 역시 디자이너에게 쏟아지는 업무량도 늘어난다. 혹은 디자이너가 아니라 프로그래머의 업무량이 늘어나서 과부하가 걸릴 수도 있다.
요는 어느 한 지점이 병목 지점이라해서 단순히 그 부분의 업무량을 드러내어 버리는 것으로 모든 업무 흐름이 좋아지지는 않는다는데에 있다. "The Goal"에서도 이 부분에 대한 설명을 하고 있음은 물론이다.
어떤 제약 조건의 해결을 위해선 반드시 전체 업무 흐름의 관점에서 접근해야 한다. 한 지점을 변화시키면 또 다른 지점이 병목으로 나타나지는 않는가. 전체의 효율을 향상시키기 위해서는 어떤 것이 최선인가. 이런 고민을 수반해야 한다는 것이 제약 이론을 실제 업무에 적용하는 데서 나타나는 제약 조건이다.
일을 하다보면 최선의 결과를 위해 이 작업을 하는 것인지, 이 작업을 위해 최선의 일을 하고 있는 것인지 헷갈릴 때가 있다. 집을 짓기 위해 기둥을 고르는 기준을 세웠는데 나중엔 기둥을 고르는 기준을 위해 기둥을 고르고 있다는 것을 깨닫는 순간이다. 비록 아직 책도 다 읽지 못했고, 전체적인 이해도 하지 못했지만 이것 하나만은 분명하다. XP건 제약 이론이건 궁극적으로 말하고자 하는 바는 같다. 우리가 이루고자 하는 진정한 목표가 무엇인지를 놓치지 말라는 것. 다른 모든 것은 그 목표를 이루기 위한 접근 방법일 뿐이다. 프로젝트의 성공을 위해 만든 기준점이 프로젝트의 목표가 되는 일은 없어야한다.
XP는 분명 소프트웨어 개발에 관한 얘기이고, 개발팀을 구성하는 각 역할 분담자들의 업무 방법에 대한 얘기다. 어찌보면 웹 서비스 기획을 하고 있는 나와는 그닥 관계 없는 것일 수도 있다. 사실 책을 샀을 때에는 그 생각이 좀더 짙었고. 하지만 책을 읽어가면서 이 책에 담긴 내용들이 내가 몸담고 있는 분야에도 적용할 수 있는 부분이 있다는 것을 느끼고 있다.
책 중간에 '제약 이론'에 대한 언급이 있다. 예전에 언급한 적이 있지만, 제약 이론은 물리학자 엘리 골드렛이 제창한 이론이다. 특정 부분에 업무량이 과하게 집중되어 전체 업무 효율을 떨어뜨리는 것을 말한다. 바로 그 지점이 병목이며, 이것을 전체 업무 흐름을 조명하는 관점에서 해결해야 한다는 이론이다. 이것은 생산 제조 공장에서부터 실생활까지 폭넓게 적용이 가능하다. 내가 읽는 책에서 제약 조건의 예로 사용한 것은 '빨래'다.
세탁 45분 -> 건조 90분 -> 정리 15분
위 순서가 빨래가 진행되는 순서라 하자. 이 흐름에서 가장 심각한 병목 지점은 바로 건조 단계이다. 전체 빨래 속도를 빠르게 하기 위해 세탁기 두 대를 사용해 빨래를 한다해도 건조 단계에서 90분이 걸리는 한 빨래의 전체 속도는 전혀 앞당겨지지 않는다. 만약 빨래의 속도를 앞당기려면 병목 지점인 건조를 앞당겨야 한다. 가령 세탁기 한 대분의 빨래는 건조기에서 건조시키고, 나머지 한 대분의 빨래는 빨랫줄에 널어 건조를 시키는 방법이 있다.
우리가 업무를 진행하면서도 흔히 병목 단계를 눈으로 확인할 수 있다. 가령 내가 예전에 투입되었던 프로젝트에서는 2명의 고객 담당자 중 한 명이 결정권자였다. 문제는 이 사람이 내부 고객으로부터 자료를 수급하고, 의사를 타진하고, 의견을 조율하고, 우리에게 그것을 전달하고, 산출물을 확정 짓고 하는 기타등등의 모든 일들을 결정하고 있었다는데에 있다. 그래서 어떤 일이 일어났을까.
이 분이 회의라도 참석해 자리를 비우는 날에는 화면설계를 마친 기획자는 이 분이 올 때까지 빈둥빈둥 논다. 그 시간 동안 기획자의 문서를 기다리고 있는 디자이너도 놀고 있으며, 그 디자이너가 만든 html 문서를 기다리는 개발자도 놀고, 그것을 실제로 적용할 또 다른 고객 담당자 역시 논다. (논다고 표현했지만, 정말로 이 사람들이 무작정 노는 것은 물론 아니다. 다만 '이 업무'와 관련된 일을 진행하지 못하고 있다는 의미이다)
이 상황에서 병목은? 아이러니하게도 바로 그 결정권을 가진 고객 담당자이다. 그 사람은 자료 수급을 위한 독촉 전화, 확인 전화도 해야 하고 의견도 모아야 하고, 회의도 참석해야 하는, 아주 바쁜 하루를 보내면서도 전체 프로젝트의 속도를 떨어뜨리는 원인이 되고 있다. 문제는 이 병목 지점의 과부하를 줄이기 위해 단순히 그와 같이 일하는 고객 담당자에게 권한을 나눠주는 것으로 일이 해결되지는 않는다는 데에 있다. 업무량의 일부분을 다른 담당자에게 나눠주면 분명 이 지점은 더 이상 병목 지점이 아니다. 하지만 기획 문서의 처리가 빨라져서 디자이너에게 쏟아지는 문서량이 많아지면, 그 뒤의 프로세스에서 분명 병목이 생긴다. 또 기획자가 허비하는 시간이 없어지는만큼 또 다른 업무를 그만큼 빨리 처리하게 된다면 역시 디자이너에게 쏟아지는 업무량도 늘어난다. 혹은 디자이너가 아니라 프로그래머의 업무량이 늘어나서 과부하가 걸릴 수도 있다.
요는 어느 한 지점이 병목 지점이라해서 단순히 그 부분의 업무량을 드러내어 버리는 것으로 모든 업무 흐름이 좋아지지는 않는다는데에 있다. "The Goal"에서도 이 부분에 대한 설명을 하고 있음은 물론이다.
어떤 제약 조건의 해결을 위해선 반드시 전체 업무 흐름의 관점에서 접근해야 한다. 한 지점을 변화시키면 또 다른 지점이 병목으로 나타나지는 않는가. 전체의 효율을 향상시키기 위해서는 어떤 것이 최선인가. 이런 고민을 수반해야 한다는 것이 제약 이론을 실제 업무에 적용하는 데서 나타나는 제약 조건이다.
일을 하다보면 최선의 결과를 위해 이 작업을 하는 것인지, 이 작업을 위해 최선의 일을 하고 있는 것인지 헷갈릴 때가 있다. 집을 짓기 위해 기둥을 고르는 기준을 세웠는데 나중엔 기둥을 고르는 기준을 위해 기둥을 고르고 있다는 것을 깨닫는 순간이다. 비록 아직 책도 다 읽지 못했고, 전체적인 이해도 하지 못했지만 이것 하나만은 분명하다. XP건 제약 이론이건 궁극적으로 말하고자 하는 바는 같다. 우리가 이루고자 하는 진정한 목표가 무엇인지를 놓치지 말라는 것. 다른 모든 것은 그 목표를 이루기 위한 접근 방법일 뿐이다. 프로젝트의 성공을 위해 만든 기준점이 프로젝트의 목표가 되는 일은 없어야한다.
이 글과 관련있는 글을 자동검색한 결과입니다 [?]
- NHN 개인커뮤니티팀과 애자일 by 애자일컨설팅
- 차라리 내가 기획할래 by 김웅남
- 더골(THE GOAL) by 정상혁
- 기획자와 기획서 by 김웅남
- 나는 웹기획자다 by june
# by | 2007/08/04 22:43 | 인터넷 이야기 | 트랙백






☞ 내 이글루에 이 글과 관련된 글 쓰기 (트랙백 보내기) [도움말]