RERIC.COM

기존의 C/S 통합 제품에서 필요한 기능만 단독버전으로 분리해 WEB으로 연동하는 프로젝트를 진행 중이다.
기존 제품의 데이터베이스와 UI를 분석해 보니 그대로 가져다 쓴다면 나 스스로 부끄러울 정도로 문제점이 눈에 보였다. 새로 추가 보완되는 기능들도 있어서 운영상의 프로세스는 그대로 유지하되 설계부터 다시 하기로 마음먹었다.
일정을 계획하고 회의를 하지만 “기존 제품이 이미 운영되고 있는데 단순히 웹으로 연동하는게 이렇게나 오래걸리냐” 는 말에 깨진 창문 이론을 말씀드렸다.
자리에 있던 개발자와 부장님은 어떤 생각을 하셨을까? 궁금하다;

오랜 기간 수리하지 않고 방치된 창문 하나가 거주자들에게 버려진 느낌을 스며들게 한다. 소유주가 그 건물에 별 관심이 없다는 느낌말이다. 그래서 다른 창문이 하나 더 깨진다. 사람들은 이제 어지르기 시작한다. 낙서가 등장한다. 심각한 구조적 손상이 시작된다. 소유주가 그걸 고치려는 의지를 넘어설 정도로 단기간에 건물은 손상되고, 결국 버려진 느낌은 현실이 된다.

‘깨진 창문’같은 나쁜 설계, 잘못된 결정, 혹은 형편없는 코드를 그냥 내버려두지 마라. 발견하자마자 바로 고쳐라. 적절히 고칠 시간이 충분치 않다면 판자로 덮는 것만이라도 하라. 불쾌한 코드를 주석처리 하거나, ‘아직 구현되지 않았음’이라는 메시지를 표시하거나, 가짜(dummy) 데이터로 대치해 놓거나 하라. 더 이상의 손상을 예방하기 위해 어떤 조치든 취하고 현 상황을 잘 관리하고 있다는 것을 보여 줘라.

깨끗하고 잘 기능하는 시스템들이 일단 창문이 깨지기 시작하면 급속도로 악화되는 것을 많이 보아 왔다. 소프트웨어의 부패에는 다른 요인들도 있는데, 그 중 방치는 다른 어떤 요인보다도 부패를 더 가속시킨다.
실용주의 프로그래머 중