소프트웨어(패키지, SI, 솔루션, 서비스 등등)를 개발하는 것도 큰 일이지만 더 큰 일은 그것을 변경된 상황에 맞게 수정하는 일입니다. 개발은 한 달 동안 해놓고 수정은 일 년 동안 하는 일은 아주 흔하지요.

그렇다면 여기서 우리에게 주어진 질문이 있습니다.

어느 곳을 수정 해야 할까요?

저는 어느 부분을 수정하여 요구 조건을 만족시키냐에 있어 일종의 우선 순위를 가지고 있습니다. 우선 순위가 높은 것을 수정 할 수 없거나 수정하여도 해결이 안 된다면 그것보다 낮은 순위의 부분을 고려합니다.

우선 순위부터 적어보지요.

  1. 비지니스 로직
  2. 알고리즘
  3. 자료 구조
  4. 라이브러리 또는 프레임워크의 알고리즘
  5. 라이브러리 또는 프레임워크의 자료 구조
  6. 데이터베이스

요구 조건을 만족시키는 제일 좋은 방법은 애초의 요구 조건을 변경하는 일입니다. 생각보다 이렇게 해결 가능한 일이 많습니다. 실제로 실효성을 고려하지 않고 즉흥적인 요구 조건이 상당히 많습니다. 이런 경우는 보다 여러가지 측면으로 더 효과적인 비지니스 로직을 제안함으로서 문제 해결이 가능합니다. 간단한 코드의 변경이라고 쉽게 생각했다 소프트웨어에 치명적인 버그를 일으킨 경험이 있으실 겁니다. 실제로 if 문 한 줄에 서비스가 통째로 죽어버리는 일은 드물지 않습니다.

그 다음은 알고리즘을 바꾸는 것입니다. 상위 부분부터 하위 부분으로 내려갑니다. 하위 부분을 낮은 순위로 두는 것은 재활용성 때문에 하위 부분의 변경이 미치는 영향이 더 크기 때문입니다.

그 다음은 자료 구조입니다. 파일 또는 각종 입출력 형식일 수도 있고 내부의 구조체 형식일 수도 있습니다. 자료 구조의 변경은 많은 코드의 변경과 버그를 일으킬 가능성이 높기 때문에 고달플 때가 많습니다.

위의 순서와 마찬가지로 이번에는 라이브러리입니다. 라이브러리는 해당 프로젝트 이외에서도 사용하고 있을 가능성이 매우 높기 때문에 수정시 매우 조심해야합니다. 사소한 요구 사항 하나 고치려다 초가삼간 잡을 수 있습니다. 라이브러리의 코드 체크인은 정말 정말 주의 깊게 하시길 바랍니다.

끝으로 데이터베이스입니다. 데이터베이스는 초기에 정교하고 주의깊게 만들어져야하며 그렇기에 변경에도 신중을 기해야 합니다. 간단한 데이터베이스 변경으로 말미암아 시스템 폭주로 인해 모든 서비스가 중단되는 일은 드물지 않습니다. 변경 후 원상 복귀 또한 어렵습니다. 5천만 로우(row)짜리 테이블에 변경을 주는 일은 사람을 초조하게 만듭니다.

끝으로 데이터베이스 변경에 대해서는 절대적으로 극단적인 보수주의자가 되어야 한 다는 것을 잊지 마십시오.