소프트웨어를 수정해야 한다면 어느 곳을 수정 해야하나?

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

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

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

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

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

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

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

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

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

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

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

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

소프트웨어를 수정해야 한다면 어느 곳을 수정 해야하나?”의 2개의 생각

  1. 음.. 전 디비는 잘 모르지만, 현업으로 디비를 다루시는 분에게 궁금한 게 있어요. 일반적인 디비에 대한 경구는 말씀하신대로 ‘주의깊게 설계하고 가능하면 건드리지 말아라’인데요, 저의 경우 마틴 파울러 패거리들의 디비 리팩토링에 대한 주장을 듣고는 좀 멍해졌단 말입니다. 들어본 적이 있으신지, 만약 그렇다면 여기에 대해서는 어떻게 생각하세요?

  2. hey// 리팩토링의 중요한 전제 조건은 풍부한 경험과 현명한 판단입니다. 즉, 작은 실수는 있을지언정 전체를 망치는 커다란 실수를 하지 않을 정도의 경험과 판단이 필요하다는 것이지요.

    리팩토링을 실제로 현업에서 자유자재로 사용하기 위해서는 적어도 아키텍터나 시니어 엔지니어급 정도의 경력과 실력이 필요하다고 봅니다.

댓글 남기기

이메일은 공개되지 않습니다. 필수 입력창은 * 로 표시되어 있습니다