객체지향의 탄생-프로젝트의 풍선효과

 

프로젝트의 풍선효과, 개발자가 고생하는 3가지 이유

공장의 작업장은 아이들이 수족관에서 고기들을 보는것처럼 보이는 그대로 수족관의 상황을 알 수 있는것과 같다. 작업장의 관리자가 윗층 자신의 사무실에서 작업장을 내려다보면 공장이 제대로 돌아가는 지 알 수 있다. 공장의 작업장은 관리자가 작업장이 돌아가는 내부 정보를 비교적 정확하게 파악한다. 노동자들도 자신들의 작업장 상태를 잘 알것이다.

 

관리자가 비용을 아끼며 강하게(빡씨게) 굴리기에는 공장의 상태가 오픈되어 있고 압박을 했을때 오히려 성과가 떨어지는 것을 고스란히 알것이다. 그래서 공장의 작업장은 투자 비용과 성과가 공평하게 계산되고 쓰인다.

 

 

우리의 프로젝트 룸은 식당의 주방과 같다. 관리자는 식당의 손님과 같다. 손님은 식당안이 어떻게 움직이는지 알지 못한다. 식당에서 신선한 재료로 음식을 만드는지 불량 재료로 음식을 만드는지 알지 못한다. 음식은 제대로 만들면서 빨리나오길 원한다.

 

식당안이 어떻게 돌아가는지 알수 없다는 것은 손님의 무의식으로 식당안이 잘돌아갈까라는 의심이 싹틀 가능성이 생긴다. 투명한 공장과 볼수 없는 식당은 의심의 가능성이 없는것과 있는것의 차이가 있다. 식당의 손님은 안을 볼수 없기 때문에 의심할수 있고, 식당안의 직원들이 언제나 조금만 더 노력하면 좀더 맛있고 좀더 빨리 음식이 나올수 있지 않을까 하며 투덜거리게 된다.

 

 

프로젝트도 마찬가지이다. 만약 개발자들이 정말로 최선을 다해 노력한다는 것을 관리자도 안다면 관리자는 의심을 풀고 필요한 자원을 제공할것이다. 그러나 관리자는 개발자들이 정말로 최선을 다하는지 알수 없기 때문에 아무리 좋은 관리자도 아스팔트의 틈에 생긴 잡초처럼 의심의 싹을 가지고 있다.

 

그 의심의 싹은 개발자를 조금 더 압박하면 성과를 더 낼것이라 생각을 하게 되고 대부분 행동으로 옮기게 된다. 그래서 안되면 되게 하라~ 개발자를 압박하는 경우가 생긴다.

 

관리자 입장에서 개발자들이 정말 열심히 일하는지 일을 잘하는지 직접적으로 확인할 수 있는 방법은 없다. 다만 결과물이 빨리 나왔는지 잘 나왔는지로 확인 할 뿐이다. 소프트웨어 내부 품질이 잘 만들었는지는 확인할 수 없다. 그래서 관리자는 결과물이 빨리 나왔는지 눈으로 볼때 잘 나왔는지로 개발자들이 일을 잘했는지 확인한다.

 

프로젝트 중간에 관리자가 개발자가 열심히 일을 하는지 일을 잘하는지 확인하는 방법은 개발자들의 근무 태도로 확인한다.

 

개발자들이 얼마나 야근하는지로 확인한다.

 

그래서 개발자들이 고생한다. 개발자들이 고생하는 근본적인 이유는 관리자가 개발자들이 얼마나 열심히 일을 하고 일을 잘하는지 측정할수 있는 방법이 없기 때문에 의심을 하기 때문이다.

 

 

보통 관리자는 개발자들을 압박하면 투자 대비 얻는 효과가 크다고 생각한다. 어느정도는 사실이나 한편으로는 사실이 아니다.

 

[풍선 효과1]

 

프로젝트 4개의 축중에 개발자를 압박하는 경우는 비용과 기간을 압박하는 것이다. 그러면 품질 비용과 기능 비용이 마치 풍선처럼 상대적으로 증가한다.

 

나는 내 나름대로 풍선 효과를 생각했다.

 

[풍선 효과2]

 

관리자들은 프로젝트 할 때 개발자를 압박한다. 압박하면 눈에 보이는 성과가 있기 때문이다. 그러나 장기적으로 유능하고 경험많은 개발자가 튕겨져 나갈 가능성이 존재한다.

 

실제로 많은 개발자들이 압박을 견뎌내다가 결국 튕겨져 나가고 있다.

 

 

개발자를 맷돌을 돌리듯이 압박하면 기능의 완성도와 소프트웨어 내부 품질이 손해를 본다. 특히 소프트웨어 내부 품질의 손해는 프로젝트가 끝나고 유지보수로 넘어갈때 지속적으로 이어져 수정/변경의 어려움 버그의 증가로 차라리 프로젝트때 돈좀 더 들여서 완벽하게 만들걸, 유지보수로 넘어가니 손해가 더 큰 경우가 생길 수 있다.

 

여기서 관리자가 프로젝트때 개발자를 압박하는 두번째 이유를 알 수 있다. 관리자가 개발자를 압박하는 이유는 눈에 보이는 손해와 눈에 보이지 않는 손해에서 당장 자기가 책임을 져야 하는 눈에 보이는 손해를 막는데 집중하기 때문이다.

 

눈에 보이는 손해를 막는데 급급하면 눈에 보이지 않는 손해가 더 커진다. 그래도 관리자는 눈에 보이는 손해를 막는데 급급하다. 눈에 보이지 않는 손해는 당장 관리자가 책임져야할 범위가 아니기 때문에 관리자는 지금의 불을 끄는게 더 중요하기 때문이다.

 

그러나 풍선효과에서 알 수 있듯이 프로젝트 동안 비용/기간 절감을 시도하면 어떻하든 좌충우돌 끝에 프로젝트는 끝나더라도 그 여파는 유지보수내내 계속 된다. 어쩌면 한번 틀을 잘 못 잡았기 때문에 해당 프로젝트 결과물은 나중에 프로젝트를 다시 하기까지 회복 불능의 유지보수하기 골치아픈 경우가 될 것이다. 고사성어 조삼모사와 같다. 관리자가 프로젝트때 개발자를 압박하는 이유 세번째는 비용/기간 절감을 시도할때 생기는 문제를 자신이 의도하지 않아도 개발자에게 떠넘길 수 있기 대문이다.

 

풍선효과에서 보듯이 개발자를 압박하면 품질과 기능에서 손해를 본다. 하지만 관리자 입장에서는 이 책임을 개발자에게 떠넘길 수 있다. 개발을 어떻게 했길래 품질과 기능이 이 모양이야~ 하면서 개발자 탓을 할 수 있다.

 

비용/기간 절감할때 생기는 일정 측정의 실수, 기획의 잘못, 설계의 부실은 마치 블랙홀에서 모든 쓰레기를 빨아들이듯 모두 개발자가 떠 안는다.

 

개발자가 밤을 새고 주말을 반납하며 온몸으로 떠 안아 고군분투 하지만 결국 비용/기간 절감의 부실로 프로젝트에는 여러가지 문제가 생길것이다. 관리자는 이 문제의 원인을 개발자가 더 열심히 일을 안하고 개발자 실력이 문제임을 탓 할 수 있다.

 

 

프로젝트때 개발자가 고생하는 이유는 프로젝트의 비용/기간 측정을 합리적으로 하지 않고 지나치게 절감하기 때문이다.

 

관리자가 비용/기간을 절감하는 이유는

- 관리자가 개발자들이 최선을 다해 일하는지 제대로 측정할 수 있는 방법이 없어 의심을 하고 개발자를 압박할수록 투자대비 효과가 좋을것이라 생각하기 때문이다. 그나마 개발자들이 열심히 일하는지 측정하는 방법은 야근으로 측정하기 때문이다.

- 관리자가 당장 자기가 책임을 져야 하는 눈에 보이는 손해를 막는데만 급급하기 때문이다. 눈에 보이는 손해는 비용/기간이 늘어나는 것이다. 관리자는 비용/기간 절감을 통해 눈에 보이는 손해를 줄이려고 하는데, 눈에 보이는 손해를 줄일수록 눈에 보이지 않는 손해는 더 늘어나고 비용은 더 늘어나지만 관지라가 눈에 보이지 않는 손해까지 책임질 필요는 없다.

- 관리자가 비용/기간 절감을 시도할때 생기는 문제를 자신이 의도하지 않아도 개발자에게 떠넘길 수 있기 때문이다. 관리자는 과도한 비용/기간 절감에 생기는 설계 부실, 기획의 잘못, 일정 측정 실수의 원인을 개발자가 더 열심히 일을 안하고 개발자 실력이 문제임을 탓 할 수 있고, 더 야근하라고 강요할 수 있다.

 

그럼 위의 문제에 대한 해결책은 없을까. 나는 세대가 바뀌기 전까지는 불가능하다고 생각한다. 다만 개발자들이 최선을 다해 일하는지 측정 할 수 있는 방법이 있고, 관리자가 눈에 보이지 않는 품질에도 신경을 쓰도록 제도적인 뒷받침이 있고, 비용/절감에서 생기는 문제를 개발자가 떠 안지 않도록 역시 제도적인 뒷받침이 되야 할것이다.

 

덧 ) 이 객체지향의 탄생 원고는 제가 책으로 내려다가 일단 잘 안되었는데요. 이유는 비문이 많다. 단락내 주제가 중복된다. 어떤 상황 설명을 과장한다.등 입니다. 그래도 원고를 일단 블로그에 몽땅 풀어보고 언젠가 제대로 교정해서 다시 도전할 생각입니다. 이점을 감안해서 읽고 객체지향을 이해하는데 도움이 되셨으면 좋겠습니다. 의견도 주셨으면 좋겠습니다. 원고 조금만 교정하면 괜찮을것 같은 출판사 관계자분의 피드백도 환영합니다.