만약 게시판을 만들다고 치자. 게시판에는 다음과 같은 요구사항이 있다.

• 보기, 쓰기, 삭제 기능을 지원한다.
• 약관동의를 하지 않았을 경우에는 약관동의를 받아야 한다.
• 인증을 받은 사용자만 쓰기, 삭제를 할 수 있다.

그래서 위 요구사항을 만족시키는 로직을 다음과 같이 프로그래밍 했다.

if(약관동의안했다면) {
  약관동의 페이지로 이동;
}
if(인증실패했다면) {
  인증 페이지로 이동;
}

처리 로직

위 자체로 보면 문제가 없어 보인다. 그러나 게시판 보기, 쓰기, 삭제 기능에 해당 로직이 아래 그림과 같이 들어갔다.

여기서 첫번째 문제점이 발생한다. ①보기, 쓰기, 삭제에 똑같은 로직이 중복하여 들어 갔다. 그래도 게시판도 한개 밖에 안되서 그대로 넘어갔다.

위 요구사항을 거의 만족시키는 프로그램이 완성되어가는 즈음에 고객의 요구사항이 추가 되었다. 그것은 아래와 같다.

• 게시판에 권한 기능 추가 : "관리자", "일반사용자"로 구분하여 관리자에게는 xxx 권한을 주어야 한다.

그래서 로직을 다음과 같이 수정했다.

if(약관동의안했다면) {
  약관동의 페이지로 이동;
}
if(인증실패했다면) {
  인증 페이지로 이동;
}
//권한처리 로직 추가
if(관리자라면){
  xx권한로직 + 처리로직;
}else{
  처리 로직;
}

위의 권한처리 로직을 보기, 쓰기, 삭제 로직에 모두 넣어 주어야 한다. 여기서 두번째 문제점이 발생된다. 기존의 보기, 수정, 쓰기 로직에 각각 권한처리 로직을 추가시켜야 하기 때문에 ②그동안 테스트도 통과되고 잘 작동되던 로직을 수정해야 한다.

며칠 야근을 하면서 새로운 권한 기능 추가도 끝나고 테스트에서 나오는 버그만 잡아 주면 프로그램 개발은 끝이나게 되었다.

그런데 갑자기 욕심많고 변덕스러운 고객이 새로운 요구사항을 또 들고 오는 것이 아닌가..ㅠㅠ 새로운 요구사항은 아래와 같다.

• xxx를 위한 새로운 게시판이 있어야 한다.

고객은 하나의 게시판을 완성 했으니까 새로운 게시판을 추가하는 것은 어렵지 않다고 생각한 모양이다. 오픈일도 얼마 남지 않아서 프로그래머는 게시판1의 소스를 copy하여 다음과 같이 새로운 게시판을 하나 더 구현했다.


아주 빠른 시간 안에 게시판은 한개 더 추가 되었고 일정에 맞추어 오픈을 할 수 있게 되었다. 그러나 여기에 또 커다란 잠재적 문제점이 발생하였다. ③게시판1과 똑같은 기능을 하는 소스(게시판2)가 한 copy 더 생긴 것이다.

우리는 위와 같이 프로젝트를 진행한 개발자에게 돌을 던지기는 쉽지 않다. 여러 이유가 있겠지만 우선 나의 경험을 바탕으로 보자면 첫째, 처음 요구사항이 계속 변경되었다. 둘째, 기능변경, 추가 되었음에도 불구하고 오픈 일정은 연기 되지 않았다. 셋째, 빠른 시간 안에 확장 가능한 잘 설계된 구조로 바꿀만한 실력이 되질 않는다.

위의 예는 좀 극단 적인 것이다. 하지만 이런 극단적인 모습이 현실에서는 심심치 않게 보이는 것도 사실이다.

이젠 신규 프로젝트 팀이 철수 하고 유지보수하는 프로그래머로 대체 되었다. 변덕쟁이 고객은 계속 새로운 요구사항을 제시한다.

• 권한을 관리자, 일반사용자1, 일반사용자2, 일반사용자3로 세분화 해서 관리한다.
• 새로운 목적을 위한 게시판 2개를 더 추가한다.

이제 부터 유지보수하는 프로그래머들의 고통이 시작된다.
게시판의 기능이 추가 될 수록 if로직은 점점 복잡해 진다.
게시판이 추가 되는 만큼 보기, 쓰기, 삭제 로직을 모두 관리해 주어야 한다.

각 게시판에 보기,쓰기,삭제 3개의 기능이 있고 이런 게시판이 5개 있다고 가정해 보자. 여기에 새로운 권한기능이 더 추가 된다고 보면 우리는 모두 15(5 x 3 = 15) 곳의 소스를 수정하고 테스트를 수행하여야 한다. 인간이 하는 일이라 15개중 2~3 곳에서 실수로 프로그램이 잘못될 가능성은 다분하다.