오늘, 회사에서 어이없는 경험을 했습니다. 제가 담당하고 있는 모 사이트의 유지보수를 위해 데이터베이스 테이블들을 체킹하는 도중, 모 사이트의 회사에서 게시판에 글이 2개씩 나온다는 이야기를 했고, 확인해본 결과 데이터베이스에 이상하게 데이터들이 두개씩 쌓여 있던 것입니다. 어찌할 방법이 없어 일일이 300개의 데이터를 삭제하곤 했는데, 알고보니 데이터베이스를 설계할 때 거의 대 다수가 기본키(primary key)를 무시하고 설계를 했더군요..
어떤 얘기인지 모르는 분도 분명 계실 것입니다. 하지만 유지보수를 하는 입장에서는 참으로 난감한 경우가 아닐 수 없지요. 페이지들도 어떤 것은 post방식으로 한 페이지에 데이터를 몰아 놓고 mode로 구분해놓고.. 아니 이럴 꺼면 다른 페이지도 다 구분해 두지 어떤건 다 따로 html로 빼둔 것은 무엇이란 말입니까. 그래도 최근(2007년)에 제작된 홈페이지 같은데.
좌우간 이러한 일은 뒷일을 생각하지 않은 설계에서 일어난 결과라 할 수 있습니다. 설계가 왜 중요할까요? 3가지 이유에서 중요합니다.
1. 설계는 고객의 요구를 수용하는 과정이다.
실무에서 프로그래밍이란 일반적인 공부를 통해 얻는 프로그램과는 다릅니다. 물론, 팀 작업을 하면 조금 유사하겠지만 분명 실무에서는 고객(buyer)이 존재하고 제작자(maker)가 존재합니다. 우선 고객의 범위를 정확히 정한 후, 고객이 원하는 프로그램을 만들기 위해 고객의 시각에서부터 시작해야 하는게 정석일 것입니다. 그리고는 데이터베이스 설계던, 프로그램 설계던 이제 우리의 입장에서 설계에 들어갑니다.
2. 설계는 레고 블럭과도 같은 제작을 위해서다.(no삽질)
레고블럭과도 같은 제작이라면 꼭 객체지향 프로그래밍을 말하는 것 같지만, 제가 강조하고 싶은 것은 우선 설계를 통해 우선순위와 모듈 트리가 나온다면 순서대로 딱 딱 진행해서 그야말로 멋진 프로그래밍을 할 수 있습니다. 설계가 이래서 중요합니다. 특히, 프로그래밍을 하다 보면 엄청난 삽질들을 하게 되는데, 이런 삽질을 미연에 방지하기 위해서라도 프로그램 구조 설계나 모듈 트리 등은 필수라 할 수 있겠습니다.
3. 쉬운 인수인계(유지보수)
마지막 항목이 제가 오늘 당한 것입니다. 왜 꼭 프로그래머들은 문서화 작업이 그렇게 싫어서 뭐 그냥 죄다 연습장에 대에충 설계해 두고 나중에 인수인계를 할 때에는 그냥 ‘주석 참조’ 정도로만 넘어갈까요? 이러한 부분은 설계의 문서화에 해당되는 것이 아니라 설계 시 모든 가능성을 고려해서 설계를 할 수 있다면, 그리고 문서화까지 완벽하게 된다면 분명 쉬운 인수인계가 될 것인데 말입니다.
저도 설계라는 부분이 너무나도 약해서 설계를 항상 공부하고 있습니다. 요즘 제가 공부하는 설계 방법은 ‘데이터베이스’ 설계를 해보면서 이것을 기반으로 소프트웨어(혹은 웹 소프트웨어) 아키텍트에 적용해 보는 것입니다. 데이터베이스 만큼이나 또 설계가 중요한 게 없다고 생각하고 있기 때문에.. ^^ 아무튼, 설계라는 게 무슨 uml쓰고 use-case그리고 비지오 쓰고 rational rose 쓰고.. 이런게 중요하다기 보다는 나도, 프로그래머인 남도, 고객인 남도, 모두가 쉽게 이해할 수 있는 설계가 중요하겠습니다. 툴 따위는 자신에게 맞고, 보다 직관적인 결과물을 도출할 수 있으면 되는 것입니다. 또한, 이러한 과정에서 문서화를 통해 모든 사항을 로깅(logging)해두는 것이 추후를 위한 가장 좋은 방법일 것이구요.
아무튼, 소프트웨어 개발자 여러분. 유지보수 하는 사람들도 나름대로 프로그래머 등의 사람들입니다. 제발, 설계할 때 뒤를 바라보고 문서화 정도는 습관화 되서 서로 얼굴 붉히는 일 없도록 하는 것이 좋지 않을까요? ^^a
