세계적인 경기 침체로 인해(?) 경제가 어렵다며 야근을 권장(...)하는 회사들이 점점 늘고 있다. 이미 IT업계는 야근은 필수요 주말근무는 진급의 등용문이요 철야는 옵션이라는 근무형태가 일반적으로 자리잡혀 있다. 꼭 IT업계 뿐만 아니라 어떤 회사든 소위 말하는 '대기업'이 아닌 이상 이런 근무 형태를 하고 있다. 이들 기업들의 논리는 보통 '우리는 대기업이 아니라서 황새가 뱁새 쫒아가다가 가랑이 찢어지면 어떻게 하라고 그러느냐?' 이다.

 '퇴근이란 오랜 옛 추억으로 기억 저편에 남아있는 것일 뿐이다' 라고 느끼는 근로자들은 일만 하려고 하는 '일 중독자'가 된다. '일 중독자'는 일을 잘해서 그렇게 불리는 것이 아니고 어딜 가든 업무와 관련된 행동을 해야 한다는 강박관념에 사로잡힌 사람이 되기 때문에 그렇게 불리는 것이다. 이들을 이렇게 만드는 방법으로 '너는 노력이 부족하다' 라거나 '먹고살기 힘들지 않느냐' 하는 것들이 있다. 이렇게 근로자들을 일 중독자로 만들면 회사를 경영하는 입장으로는 겉으로 보기에는 안심이 될 수 있을것이다.

 IT회사의 속내를 들여다 보자. 야근이 필수인 회사는 그저 근무시간이 법정 근로시간보다 좀 더 길 뿐이다. 그래서 열 몇 시간을 책상앞에 앉아서 무언가 바쁜척(?)을 하면 된다. 프로젝트 기한은 대충 맞는것처럼 보이면 된다. '프로젝트 관리'라는 무언가 거창한 타이틀이 존재는 하지만 어딘가 어설퍼 보이는 면이 없지 않다. 그나마 '마감시간'이라도 정해져 있어서 놀지는 않은 것 처럼 보인다.

 '프로젝트 관리' 업무는 '짬'좀 되는 사람들이 하게 된다. 자신의 경험에 비추어 대충 일정을 만들고 일을 하다보면 매일같이 야근을 하고도 항상 일정의 2~3배의 시간이 걸린다. 프로젝트가 지연되는건 항상 일어나는 일이기에 비난의 화살은 '칼퇴근자'로 돌아가도록 되어있다. 하지만 그 누구도 프로젝트가 '어디쯤' 와있는지 '얼마나 더' 해야 하는지는 알지 못한다. 그저 운이 좋기를 바랄 뿐이다.

 인간의 능력은 하루 4시간만 집중할 수 있도록 되어 있다. 카페인 음료의 도움을 받아 좀비모드로 되려고 하면 할수록 집중할 수 있는 능력은 줄어들 뿐이다. 하지만 회사는 근로자가 열 몇 시간을 책상앞에 앉아서 무언가 바쁜척(?)을 하기를 바라고 있기 때문에 근로자들은 안타깝게도 후자를 선택하게 된다. 차라리 인간이 아니라 기계였다면 좋았을 것이라는 생각이 들 정도이다. 어떻든 간에 인간은 4시간 이상 집중하지 못하므로 이에 맞는 일 처리 방법을 생각하는 것이 좋을 것이다. 

 아쉽게도 IT산업는 다른 산업들보다 상대적으로 짧은 역사를 가지고 있기 때문에 업무 프로세스에 대한 고찰이 많이 부족한 듯이 보인다. 야근을 하는 것이 비효율적이라는 것도 알고 있고, 몸을 혹사시켜서 돈을 좀 더 번다 한들 나중에 병원비로 더 많이 낼 것이라는 것도 알고 있다. 그런데 소프트웨어도 하드웨어처럼 '설계'가 필요하고, '설계'를 통해 '삽질하는' 시간을 줄일 수 있다는 것을 알고 있는 사람은 많지 않다.

 20년도 더 된 프로그래밍 서적에는 'Top-Down Design'과 'Bottom-Up Implementation'기법이 소개되어 있다. Top-Down Design이란, 인간이 필요로 하는 기능에서 부터 기계가 수행해야 할 일들을 나열하는 방법이고, Bottom-Up Implementation은 설계단계에서 기계가 수행해야 할 일 부터 먼저 구현해서 가장 마지막에 인간이 필요로 하는 기능을 구현하는 방법이다. 지금 하는 업무 방식과는 크게 달라보이지 않다.

 하지만 이것이 야근 문제를 해결 할 수 있는 핵심이다. 설계할 때 부터 필요한 기능이 나열되므로 필요없는 기능을 만드는데 들이는 시간을 줄여준다. 설계할 때 부터 불확실한 부분이 해결되므로 설계 이후에 프로젝트가 지연될 확률을 감소시켜준다. 설계할 때 각 모듈들의 인터페이스가 정의되므로 테스트 시나리오도 설계 단계에서 작성이 가능하다. 설계가 끝나면 마치 기계처럼 구현과 테스트만 하면 된다. 'Test Driven Development'는 말도 안 되는 것 처럼 보이지만 위의 설계와 구현과정이 확실히 분리가 되면 가장 아랫 단계에서 부터 테스트가 가능하고 테스트가 끝난 부분에 대해서는 다시 볼 필요가 없으므로 디버깅에 드는 시간이 줄어든다.  

 다음에는 (언제가 될 진 모르겠지만) 위의 세가지 방법을 이용해서 소프트웨어를 작성하는 방법을 소개하도록 하겠다. 혹시라도 프로젝트 매니저를 하고 있다면 직원들 좀 그만 갈구고 회식 따위로 어떻게 해결하면 될 거라는 생각 버리고 밑져야 본전이라는 생각으로 위에 제시된 방법들에 대해 공부해 보길 바란다.