왜 야근은 끝날 줄 모르는가.

그놈의 야근 지긋지긋 하다 ? 왜 야근은 끝날줄 모르는가. 왜 항상 철야와 야근을 밥먹듯이 하는데, 일정은 계속 딜레이 되고 딜레이 되는 만큼 다시 철야를 하게 되고, 그렇게 고생을 해도 만들다 만것 같은 제품이 만들어지는가.

왜 야근을 하는가. 왜 한번 시작된 야근은 끝날 줄 모르는가. 어떻게 해야 야근을 막을 수 있는가.

야근을 하게 되는 첫번째 이유는 물론 일정을 잘못잡기 때문이다. 가장 흔한 실수가 투자시간 대비 효과가 1:1의 관계를 가진다는 생각이다. 5시간을 투자하면 5만큼의 효과가 10시간을 투자하면 10만큼의 효과를 얻을 수 있을 거라는 믿음이다. 이 믿음이 잘못된 것이라는 것은 두말할 필요도 없다. 누구나 알고 있는 사실이다. 시간 대비 효과는 로그 그래프를 따라간다는 것을. 문제는 머리로는 이해하는데, 가슴으로 받아들이지 못한다는거.

왠지 1:1 의 관계를 가질거라는 것을 믿고 싶다. 아니면 정신무장을 시켜서라도, 즉 어느정도의 강제성을 가지도록 하면 1:1 비슷하게 만들 수 있을거라고 생각을 하고 싶어진다.

그래서 이것을 기준으로 일정을 잡는다. 예컨데 주 40시간 노동이니 하루 8시간인데, 좀 빡세게 10시간 일할 것으로 가정을 해서 제품출시일과 스팩을 잡은다음 역산을 해서 일정을 잡는 식이다. 당연히 빵꾸난다. 처음 얼마간은 잘될 수 있다. 산술적으로는 로그 그래프를 가지지만, 사람은 변동성 즉 버퍼를 가지고 있기 때문으로, 얼마간의 초과능력사용은 감당할 수가 있다. 이 변동성의 크기는 사람마다 다른데, 개발자는 흔히 이것을 정신력, 정신무장이라고 한다. 야근과 철야를 얼마나 자신의 일상으로 받아들이고 버틸수 있는지로 측정되는 힘이다. 21세기 사무실에서 정신력을 생산력에 결부시키는 전근대적 상황을 봐야 하다니.

마르지 않는 샘물은 없다. 개인차가 있을 뿐, 변동성은 조금씩 줄어들게 되고 결국에는 정상상태 즉 하루 6시간 정도를 일할 수 있는 상태로 되돌아오게 된다. 물론 이때에도 책상에 앉아 있는 시간은 10시간이 되겠지만 말이다. 그럭저럭 열린마음?을 가진 관리자는 일정을 잡을때에는 하루 6시간을 집중하는 것으로 잡는 경우가 많은데, 다들 아실 것이다. 6시간을 집중해서 일한다는게 얼마나 힘든지를. 지속적으로 6시간 집중하는 건 (지금 이글을 보고 있는 사람이 일을 시키는 입장이라면 기분나쁠 수도 있지만) 거의 불가능 하다는 것을. 즉 6시간을 기준으로 잡고 일정을 짜도, 프로젝트 중간에 일정이 연기되는 조짐을 보는 경우가 많다는 점이다. 그러나 이경우에는 개인의 업무 변동성이 충분히 남아있기 때문에, 중간중간 남아있는 변동성을 이용해서 그리 무리하지 않고 업무를 정상궤도에 올려 놓을 수 있는 여지가 생긴다.

여튼 변동성이 줄어들면, 즉 업무의 효율성이 떨어지게 되면서 일정이 어긋나는게 눈에 보인다. 산술적으로 계산해봐도 4시간씩 빵꾸가 나기 때문이다.

보통 프로젝트진행 한달정도가 되면 슬슬 중간점검을 하는 시기가 다가올 것이다. 역산한 일정과 업무진행정도를 맞춰보는 PM의 얼굴이 굳어지기 시작한다. 아무리 역산을 해봐도 절대 목표로한 일정에 제품이 나올 수 없다는 결론이 도출된다.

취할수 있는 방법은 두가지다.

1. 일정산정방법이 애시당초 잘못되었음을 인정하고 다시 짠다.
2. 10시간을 12시간으로 늘린다.

2는 물론 최악의 방법이다. 이미 계속된 야근과 철야로 변동성이 남아있지 않은 상태에서는 기존에 4시간씩 빵꾸나던게 6시간 빵꾸나는 걸로 바뀔뿐 달라지는 것은 없기 때문이다. 2주일뒤 혹은 한달뒤 일정역산 들어가면 오히려 상태가 악화되었다는 것을 깨닫게 된다. 문제는 많은 PM이 2번의 방법을 선택한다는 것. 결국 목표일에 제품출시가 불가능하다는 것을 깨닫고, 일정을 다시 잡는다. 그리고 이 사이클이 반복된다. 한번야근이 평생야근이 된다. 2번은 대게가 일정이 연기되거나 기능이 빠진채 출시될 수 밖에 없다는 것을 마음으로 받아들이고 그래도 열심히는 했습니다라는 식의 자기위안을 삼기위해서 선택된다.

최종적으로는 열심히 일할 수록 프로젝트가 지연되는 상황에 직면하게 된다고 보면 될거같다.

1번은 그나마 좀 나아질 수 있는 여지가 있다. 사람은 기계가 아니라는 현실을 가슴과 머리로 받아들이고 일정을 연기하던지, 스팩을 조정하던지 둘다 하던지 하면 되니까. 근데, 지금가지의 경험상 한번 일정역산 들어가게 되면 끝까지 일정역산이다.

우리는 머리로 이해하고 있다. 투자시간 대비 효과가 절대 1:1 이 될 수 없다는 사실을. 그 일정을 맞추려면 기능을 빼야 한다는 것을. 기능조절이 하지 않을거면 일정을 늘려야 한다는 것을, 그래도 제시된 일정은 너무 빡빡하다는 것을. 그런데 결국 그러한 무리한 일정을 받아들이게 된다. 왜 일까 ?

에라 모르겠다. 될대로 되라지 라는 식으로 체념하기 때문일 수도 있다. 나중에 핑계를 댈 수 있기 때문이다. 애초부터 일정이 빡빡했어요 T.T 라고 말이다. 나중에 이말을 하기 위해서 개발자는 안전장치를 해둔다. 해보긴 해보겠지만 이 일정 정말 무리입니다... 이런말을 하면 관리자도 고개를 끄덕이면서 나도 알긴 아는데, 해볼때까지는 해봐야 하지 않겠어 ? 라고 동의해준다. 안될줄 알면서 한다는 것인가 !!!???. "해볼때까지 해봐야 하지 않겠어 ? 최선을 다해야 되지 않겠어 ? == 야근과 철야를 받아 들여야 하지 않겠어 ?"

또다른 것으로는 집단사고와 집단극화 현상을 들 수 있다.

집단사고란 의견합치의 추구가 너무 강해서, 행위에 대한 효과적인 판단을 하지 못하게 하는 사고의 양식을 말한다.

집단사고는 합리적인 판단을 마비시킨다. 집단사고는 특히 수직적인 위계질서를 가지는 조직에서 잘나타 난다. 집단사고로 실패한 대표적인 예는 존슨 행정부의 베트남 정책일, 닉슨 행정부의 워터게이트 사건, 케네디 행정부의 피그만 침공등이 지적된다. 비관론자로 낙인 찍히거나, 집단으로 부터 왕따당할 거라는 두려움. 짱에게 미운털 박힐지도 모른다는 생각들이 모이고 모이고 모여서 비합리적인 낙관론이 판치게 되고 결국 잘못된 판단을 내리게 된다. 일을 제대로 할려고 회의를 하는 건데, 오히려 일을 망치게 된다.

경영진(혹은 팀장님)은 이미 뜻을 굳히셨습니다. 여기에서 왈가불가 하는 것은 쓸데없는 낭비를 가져올 뿐입니다. 지금은 프로젝트의 원할한 수행을 위해서 모두가 힘을 모아야 할때입니다. 모든 의심과 회의는 버리십시요. 프로젝트에 전혀 도움이 되지 않습니다. 많이 들어본 얘기다. 이건 2-3명이 모인 작은 조직에서 부터 국가단위의 거대조직까지 일상적으로 목격할 수 있는 양식이다. 프로젝트의 원할한 수행 을 국가와 경제발전으로 대치시켜보기 바란다. 특히 2MB 정부에서 시도때도 없이 목도된다.

이러한 집단사고의 폐해를 막기 위해서, PL은 다음과 같은 점을 염두에 두고 커뮤니케이션에 임해야 한다고 권고하고 있다.

1. 어느 의견이건 선호를 보이지 않고 중립을 지킨다.
2. PM은 말을 많이 하지 않는다.
3. 제안에 대해서 자유롭게 비판하도록 한다.
4. 반대를 전담하는 악역을 배치한다.
   • 배치하기는 힘들더라도 악역의 의견에 대해서 중립을 지킬 수 있어야 한다.
5. 하위집단에서 충분한 토의가 이루어지도록 해서 다양한 견해가 토론에 제시될 수 있도록 한다.
6. 한번에 결정하지 않고, 예비결정을 한다. 이 예비결정은 하위 집단에서 토론되어서 의혹이 없도록 한다.

집단극화란 토론에 참여한 구성원들이 혼자 생각할 때보다 좀더 모험적인 의사결정을 지지하게 된다는 이론이다. 뭐 많이 경험해 봤을 거다. 분명 회의 참가하기 전에는 시간이 너무 촉박해, 사람이 부족해, 스팩을 재조정해야되, 이 기술은 이래서 안되고, 저 기술은 저래서 안되고 하는 식으로 보수적이였는데, 회의가 끝났을 때는 오오.. 으샤으샤 우린 모두다 할 수 있어. 문제 없어. 아하하하..!!! 하게 되는거 말이다.

집단극화의 메커니즘은 대략 다음과 같다.

여러 사람이 모여서 토론을 하면, 어떤 문제의 해결에 대한 새로운 정보들을 얻게 되는데, 이때 얻는 정보들은 대체로 지지받는 의견인 경우가 많다. 이렇게 지지받는 의견들로 몇번 사이클이 돌다보면, 모든 문제가 당장 해결된거 같은 착각에 빠진다. "이렇게 쉽게 해결될 것을 괜히 고민했네"라고 생각하는 거다. 그래서 점점더 모험적이고 극단적인 선택을 하게 된다. 이 현상은 비슷한 의견을 가진 사람들이 모여있을 때 특히 위력을 발휘한다. 100분토론을 보면 평소보다 더욱 극단적인 주장을 펴는 경우를 많이 보아왔을 건데, 비슷한 맥락이다.

일정을 잡을때 문제가 되는 또하나의 것은 병렬처리 효과에 대한 몰이해이다.

5일이라는 시간동안 A 일을 하고, 다음 3일에 B 일을 하겠습니다. 총 8일의 시간을 잡았습니다. 라고 일정을 잡아가면 열에 일곱은 분명히 병렬로 처리할 수 있는 일 아냐 ? 너무 널널하게 시간을 잡은거 같어 ?. 병렬로 하면 6일이면 가능하겠네라는 얘기를 들을 것이다.

프로젝트를 빨리 진행하기 위해서 사용되는 병렬처리는 프로젝트 장기화의 고질적인 원인이 된다. 병렬처리는 생각처럼 효율적이지 않다. 아마 CPU의 병렬처리의 효율성 때문에 사람도 효율적으로 병렬처리를 할 수 있을 것이다라고 생각이 많아진게 아닐까 생각해본다.

사람은 컴퓨터가 아니다. 또한 CPU의 경우에는 빠른처리를 위해서 모든 잡스러운 것이 제거되는 깨끗한 환경에서 돌아가지만, 개발자의 환경은 전혀 그러하지가 못하다. 문서작성, 메일 체크, 회의, 알게모르게 생기는 여러가지 걸림돌들이 생기기 때문이다. 이미 병렬처리 상태라는 거다. 거기에 병렬처리를 하게 되면, 여러개의 업무로 부터 동시에 문서작성, 메일체크, 일정체크, 회의, 디버깅, 기타잡다한 요구사항 들이 생기게 된다. 머리가 혼란해지고, 실수를 하게 되고, 어디에선가 무언가를 빠트리게 된다. 결국에는 오히려 하나씩 끝내는 것보다 더 많은 시간이 소모되게 된다.

동시에 진행할때 좋은 점이라면, 뭔가 많은 일을 하고 있는 것같다는 안도감이 생긴다는 점 정도일 것이다.

우리는 변동성을 무시하고 일정을 잡는 경우가 많다. 그렇지만 어떤 일을 하더라도 거의 반드시 예상치 못한일이 생긴다. 아무리 경험이 많은 PM 이라고 하더라도 이러한 변동성을 다 예측 해서 일정을 잡을 수는 없을 것이다. 문제는 이러한 변동성에 유연하게 대처하는 자세다. 변동사항이 생기면 야근으로 해결한다. ? 백프롭니다. 계속되는 야근 입니다.

변동성을 예측에 실패하는 이유는 복잡도에 대한 잘못된 이해 때문이다. 복잡도는 급수적으로 늘어난다. 예컨데, 입력된 정보가 5개에서 10개로 늘어나면 복잡도는 2배가 아닌, 10 배이상으로 팩토리얼하게 늘어나게 된다. 이것은 네트워크이팩트(:12)로도 설명이 되기도 한다.

그런데, 인간은 기하급수적인 증가라는 개념을 잘 이해할 수 없는 방향으로 진화를 해왔다. 자연에서는 기하급수적 증가를 목도할 일이 없기 때문이다. - 혹은 생존에 영향을 미치는 경우가 없어서 이를 고려할 필요가 없기 때문이다 -. 미생물학과 통계학이 나타나면서 그나마 기하급수적이라는 것을 머리로 이해할 수 있게 되었다. 그렇지만 여전히 인간은 세균이 그처럼 빨리 번식할수 있다는 사실에 당황해 한다.

10개의 기능에 하나의 기능이 추가되면, 1만큼 복잡도가 증가하는게 아니란 얘기다. 하지만 많은 PM이 1만큼 증가하는 것으로 판단 추가된 단일 기능을 구현하기 위한 시간만큼만 일정을 늘린다. 아니.. 일정을 늘리는게 아니고 초과근무를 시키는 경우가 다반사다. 대게의 개발자는 일을 하다가 느끼게 된다. 이거 엿된 거구나. 야근과 철야를 하는 개발자와 핑계거리를 만드는 개발자가 나타난다. PM은 전자의 개발자는 책임감이 뛰어난개발자로 평가를 하고, 후자의 개발자는 책임감이나 애사심이 부족한 혹은 개발자 마인드가 없는 평가를 받는다. 야근이 일상화된 조직에서 개인의 능력이 얼마나 야근에 충실하는지로 평가되는 이유다.

중간에 기능추가하지 말라는 얘기다. 역시 문제는 머리로는 알고 있는데, 가슴으로는 받아들이기가 매우 힘들다는 점.