깨진 창문을 내버려 두지 말라

 깨진 창문 이론(Broken Window Theory)이라는 말이 있습니다.
'티핑 포인트'라는 책과 '실용주의 프로그래머'라는 책에서 인용되고 있는데요..

요약하면,

오랜기간 수리하지 않고 방치된 창문 하나가 거주자들에게 버려진 느낌을 준다는 겁니다.
그래서 다른 창문이 하나 더 깨지고.. 낙서가 등장하고.. 심각한 구조적 손상이 시작되는 것이죠..
결국 건물 소유주가 고치려는 의지를 넘어설 정도로 건물이 손상되고, 버려진 느낌은 현실이 되어 버린다는 겁니다.

보다 자세한 내용은 다음 블로그들을 참고하시기 바랍니다.

http://www.nanael.net/48
http://blog.naver.com/chowyf?Redirect=Log&logNo=80034681435

'실용주의 프로그래머' 책에서는 실생활 뿐만 아니라 IT 프로젝트에서도 깨진 창문을 조심하라고 말하고 있습니다.
나쁜 설계, 잘못된 결정, 좋지 않은 코드를 눈에 뜨일 때마다 고치라는 것이죠~

흔히 프로젝트 초반에는 DB도 조금 변경하고, 로직도 변경하고.. 개발을 진행합니다.
하지만 어느정도 프로젝트가 진행이 되고 나면.. 고객의 요구사항이나 프로그램 구성상 변경이 발생할 때..
전체를 고치기 보다는 그 부분만 땜빵하듯이 고쳐나가는 경우가 있습니다.
DB를 수정하게 되면 너무 많은 부분을 손대야 하니 어쩔 수 없다고 말하면서~~
하지만, 점점 더 많은 변경을 적용하면서... 소스 코드는 더욱 지저분해지고.. DB도 누더기다 되어버리게 됩니다.

솔직히 지금까지는 이런 경우, 변명을 많이 했었습니다.
"고객이 생각지도 못한 요구사항을 추가한 것이다."
"초기에는 논의 되지 않았던 부분이다."
"데이터베이스를 변경할 수는 없으니 이런식의 꼼수 코딩은 정당하다."
하지만 최종적으로 유지보수도 어려운... 쉬레기 코드가 만들어지는 것이죠~

그렇다면, 실제 프로젝트에서 깨진 창문을 내버려 두지 않으려면 어떻게 해야 할까요?
일단, 프로젝트 팀원들의 마음가짐이 중요할 것 같습니다.
내가 먼저 창문을 깨어서는 안된다~ 는 각오가 필요할 것 같네요~

그리고 가장 중요한 것은 PM 혹은 PL의 역할이 아닐까 합니다.
외부의 변수에 의해 수정이 필요할 때, 전체적인 관점에서 고칠 것을 빠르게 결정하고 진행하는 것이 필요하지 않을까 합니다.
누군가 끊임없이 프로젝트를 관찰하고 있다면, 창문 하나가 깨지더라도 바로 복구할 수 있을 테니까요..
그러기 위해서는 소스코드에 대한 관리, 테스트에 대한 관리, 설계나 기획안에 대한 관리가 PM/PL에게 일정관리 이상으로 중요한 부분이 아닐까 합니다.
깨어진 소스.. 깨어진 설계를 찾아내야 하니까요~~