버전업을 하면서 겪는 문제들 중 가장 큰 것은 설계의 문제일 겁니다. 1.0에서 차기에 도입할 기능에 대한 확장성을 충분히 고려하지 않고 설계를 하게 되면 2.0에서 1.0에서 작성했던 코드를 상당수 뜯어고쳐야 하는 경우가 반드시 생깁니다.

사실 버전업 개발을 하면서는 아무리 설계를 잘 해놓더라도 개발자가 점쟁이가 아닌 한은 새롭게 추가될 기능에 대해 미리 고려해놓기는 어렵죠. 하지만 차후 버전에서 추가로 구현할 기능이 미리 예정되어 있는 경우도 많고, 또 예정까지는 아니더라도 쉽게 예상할 수 있는 버전업 기능들도 있습니다.

예를 들어 파일 탐색기를 만든다고 가정해보면요. 1.0 버전에서 요구된 사항은 하드디스크상의 디렉토리와 파일만 나타나면 된다고 요구받았다고 하죠. 그런데 만약 1.0만 개발하고 퇴사하거나 프리랜서의 경우 계약을 끝내고 다시는 안볼 것이 아니면, 당연히 버전업이 될 때는 자신이 그대로 개발을 하게 되겠죠?

그런데 탐색기 기능을 구현했다면, 2.0 버전에서 하드디스크 외에 네트워크상의 파일을 보여주는 기능을 요구받을 가능성이 높겠죠. 그런데도 일단은 간단하게 끝내겠다고 탐색기상의 아이템을 하드디스크 기준으로만 클래스를 설계했다고 하면, 네트웍 상의 파일에는 적용하기 어려울 수 있고, 그때문에 2.0 개발에서 기존의 코드를 상당수 날리고 새로 작성해야 하겠죠.

하지만 윗선에서 그걸 쉽게 이해하겠습니까. 개발에 상당한 경험이 있는 사람이 아니면, 당연히 1+1은 2라고 생각해버리죠. 파일 탐색기능이 이미 있는 경우에 네트웍 기능을 추가하는데는 아주 잠깐이라고 생각하고 일정을 지시하곤 하죠.

이런 설계의 미진함이 기존의 버그와 엮이면 문제가 복합적으로 더 커집니다. 따라서 만약 기존의 버그를 알면서도 1.0을 릴리즈해야 할 경우가 생기더라도, 최소한 차후 버전에서 문제가 더 커지지는 않을지에 대한 고려는 해보고 최소한의 대비책은 코딩해놔야 하지요.

그렇다고 해서 1.0 개발을 하면서 2.0 개발에 필요한 걸 다 준비 해놓는다면 당연히 노력도 훨씬 더 필요하겠죠. 나중에 2.0 개발할 때가 되어 알고보니 필요가 없었을 수도 있구요. 그러니 미리 예상할 수 있는 추가 기능에 대해서는 최소한의 대비 정도만 해두는 것이 좋겠습니다.

사실 이런 문제는 언어에 따라 다른 것도 아니라 모든 언어에서 똑같이 생기는 문제이고요. 좋은 방법론을 세워놓고 개발을 착수한다면 좀 줄일 수는 있지만, 이런 설계의 확장 부분에 대해서는 어떤 방법론도 명쾌한 답변이 되지는 않습니다. 누가 가르쳐줄 수 있는 것도 아니고, 경험으로만 알 수 있는 거죠.

제 생각입니다만, 예를 들어 Win32 API 같은 테크닉적인 면은 경험이 적더라도 열심히 머리 처박고 달달 외우면 어느정도 커버가 됩니다. 한 마디로 팁일 뿐, 그걸 기술이라고 하기에는 좀 부족하죠. 하지만 설계, 그것도 확장성을 고려하는 설계에서는 팁을 1000개를 알고 있든 1만개를 알고 있든 도움이 안되죠. 바로 이런 부분에서 경력자의 진정한 실력이 나타나는 것 아니겠습니까.


김호광 님이 쓰신 글 :
: 1.0은 쉽지만 2.0은 어렵다라는 말이 허언이 아니군요...
:
: 기능 업데이트와 지속적인 개발이 이렇게 어려울줄이야
:
: testcode~