레거시 코드, 족쇄인가 기회인가

허광남(kenu@okjsp.pe.kr) GS이숍 EC정보팀, OKJSP운영자



소프트웨어 프로그램, 그 참을 수 없는 가벼움

소프트웨어 프로그램은 끊임없이 변화하는 특성을 가졌다. 건축물이야 한 번 완공되면 그 수명을 다할 때까지 보존되는 것이 대부분이지만 건축에서 많은 아이디어를 가져다 쓰는 소프트웨어는 소스코드만 있다면 변경하고 다시 빌드할 수 있는 노력과 비용이 건축과는 비교도 할 수 없이 작기 때문에 기능 추가 또는 변경에 대한 유혹이 굉장히 강하고, 또 많이 수정되고 있다.



문제 발생의 시점은 변경에서 시작된다. 수정에 따른 함수들의 변화를 감지하기 어렵기 때문에 나비효과라고 할 수 있는 결과들, 다른 말로 하면 사이드 이펙트(부작용)가 프로그램의 여기저기서 발견된다. 이것을 많이 경험하면 경험할수록 프로그램 수정에 대한 요구에 대해 소극적이고 방어적으로 요구사항에 응하게 된다. 변경 후 잘못된 결과에 대해 법적 책임은 지지 않아도-합법적으로 일했기 때문에- 자신이 작업했다는 도의적인 책임과 자신의 실력에 대한 자책감이 수반되기 때문이다.



소프트웨어 프로젝트에서 웃지 못할 얘기가 있었다. 납기일 빡빡하게 진행하던 SI 프로젝트에서 있었던 일이라고 들었다. 기간에 비해 많은 요구사항을 처리하느라 소프트웨어의 품질은 안봐도 비디오였다. 시간 때문에 일단 하드코딩으로 화면만 나오게 만든 곳도 있고, 이리저리 바뀌는 갑 회사의 요구사항 때문에 설계는 틀어지고 꼬인 부분도 다수였으며, 오픈 일정이 픽스(고정)되었기 때문에 대략 30%의 요구사항이 오픈 후에 개발하는 등 참으로 다사다난한 프로젝트였다. 일단 프로젝트 오픈일이 가까워지자 프로젝트 팀에서 유지보수로 누가 남을 것인지 이슈가 되었다고 한다. 지원자를 받는다고 했지만 누가 자청해서 남아 X을 치우겠는가. 결국 PM과 임원들 사이에서 누군가 내정을 했다. 그런데 자기가 유지보수로 남게 되었다는 소식을 알게 된 개발자는 ... 다음 날부터 연락이 되지 않았다. 잠적한 것이다.



레거시 코드가 발목을 잡는다. 왜?

개발을 바닥부터 시작하면 편하다. SI가 SM보다 환영을 받는 이유 중의 하나이다. 말 그대로 프로그램 단에서 걸리적거리는 것이 거의 없기 때문에 프로그램 설계의 자유도가 굉장히 높다. 하지만 SM의 경우 이것 저것 살펴봐야 할 것이 많다. 친절하게 써 놓은 주석도 순진하게 믿어서는 안된다. 절대 현재 운영 상에서 나오는 데이터가 어떠한지 찍어서 남겨야 되고, 그것을 바꾼 후에 변경된 값이 무엇인지 로그로 남겨놓아야 뒷탈이 없다.

프로그램 변경에 대한 요구는 외부로부터 ...

to be continued in http://www.imaso.co.kr

+ Recent posts