개인 프로젝트를 왜 해야 하나

오늘 저녁, 학교에서 MyKMS 디버깅을 하다가 문득 '내가 이걸 왜 계속 하는거지'하는 회의가 들었다. 사실 방학을 맞아 많은 시간을 스스로의 계획 하에 보내는 상황에서, 그 중 많은 부분을 개인 프로젝트에 보내고 있는데 최근 부쩍 이러한 회의가 자주 들고 있다. 나의 직관이 어떤 일의 가치에 대해 의구심을 품는 상황에서 보내는 신호인 '회의'를 받는 찰나에 개인 프로젝트에 대한 생각을 정리해보기로 했다.

사실 내가 개인 프로젝트를 시작한 것은 하루이틀 된 것은 아니다. 2002년 10월 경 일정관리 - 개인적으로 별로 좋아하지 않는 수식어이지만 - 프로그램인 MyLEO에서 시작해서 개인지식관리 프로그램인 MyKMS까지, 그리고 최근에는 이 두가지를 뒷받침하기 위한 이론개발까지 벌써 4년 가까이 이 일에 매달린 것이다.

그리고 그 동안 투자한 시간과 노력은 정말 어마어마하다. 내 일정에 대한 활동별 통계를 보여주는 MyLEO의 데이터 기준으로 주당 평균 10시간은 투자했으니, 일년이면 500시간, 4년이면 2000시간 가까이 된다. 내가 책 한권을 읽는데 5시간이 걸린다고 가정하면, 책 400권을 읽을 수 있는 시간이다. 다른 언어 - 중국어/일본어 - 를 하나 마스터하고도 남았을 시간이다.

정신적인 부담도 상당하다. 대부분의 프로그램이 서버에서 동작하는 까닭에 서버에 장애라도 생기면 일정 및 지식관리를 사용할 수 없다는 부담도 있었고, 뭔가 필요한 기능인데 디버깅이 안 되면 짜증이 막 나기도 했다.

MyLEO의 통계 화면

그렇다면 내가 그동안 이렇게 몰두한 일은 과연 값어치가 있는 것인가? 결론적으로 말해서 가치가 있다고 생각한다. 그동안의 노력에 대한 아쉬움 때문이 아니라 미래를 볼 때 그렇다고 생각한다. 그 이유를 알아보기 위해 내가 개인 프로젝트에 대해 세워 둔 원칙을 살펴보자. 내가 개발을 할 때에는

1. 스스로에게 절실히 필요한 프로그램을 개발한다.
2. 더 좋은 프로그램이 있는 경우에는 개발하지 않는다. (Don't re-invent the wheel)
3. 평생 쓸 수 있는 품질을 유지한다.
   • 당장 시간이 더 들더라도 제대로 설계한다.
4. 비슷한 필요를 지닌 다른 사람이 쓸 수 있도록 범용으로 만든다.
   • 개발과 동시에 문서화한다.
   • 패키지 수준의 범용성(configurability)을 유지한다.

이와같은 원칙을 지키도록 노력한다.

물론 원칙이 100% 지켜졌다고 말할 수는 없겠지만, 스스로의 생활에 많은 도움을 받으며, 주변에서 필요로 하는 사람에게 도움을 주기도 하였다. 내가 주로 개발한 프로그램이 개인 생산성에 지대한 영향을 끼치는 일정 및 지식 관리 프로그램이고, 이변이 없는 한 내가 평생 프로그램을 사용할 것임을 감안할 때, 그동안 프로그램 개발에 많은 시간과 노력이 투입된 것은 사실이지만, 내가 평생동안 절약할 수 있는 시간과 노력이 개발에 투자한 그것보다 훨씬 클 것이라고 생각한다.

또한 내가 스스로 편리하게 쓰는 프로그램을 쓰고싶은 사람이 있어서 그 사람에게도 도움을 줄 수 있다면 엔지니어로서 이보다 보람된 일은 별로 없을 것이라는 생각이 든다. 다른 사람이 만든 것을 불편한대로 사용하는 것이 아니라, 스스로의 필요에 정확히 부합하는 도구를 만들어 사용하는 만족감에 비하면 차라리 부차적인 것이기는 하지만 말이다.

이러한 활용의 측면 이외에 개인 프로젝트를 통하여 개발 전반에 걸쳐서 엄청나게 많은 것을 배울 수 있었다. 회사, 그리고 학교에서는 계속 C/C++ 프로그래밍만 했던 내가 CSS / Javascript / AJAX / XML / XSLT 웹 전반에 걸쳐서 폭넓게 공부하고 실습할 수 있었던 데에는 개인 프로젝트의 공이 절대적이었다. 최신 기술이 나오면 바로 자료를 찾아 공부한 후에, 개인 프로젝트에 적용해 보고 희열을 느끼곤 했다.

이러한 지식보다 더 중요한 배움이 있다면, '오랬동안 쓸 수 있을 만한' 소프트웨어 개발에 대한 노하우일 것이다. 사실 프로그램 개발은 고등 교육을 받은 사람은 누구나 할 수 있는 일이며, 그래서 소프트웨어 개발자가 전문직으로 대우받지 못하는 측면이 있다. 하지만, 소프트웨어 개발의 목표를 '대충 돌아가는 일회용' 프로그램이 아닌 '평생 쓸만한 고품질' 프로그램으로 바꾸어 설정하면 이야기는 완전히 달라진다. 지속 가능한 소프트웨어 개발을 위해서는 설계 및 개발 방법론 전반에 대한 폭넓은 이해와 통찰력이 필요하기 때문이다.

The_Pragmatic_Programmer에서 David Thomas가 설파하듯이 음식만 부페하는 것이 아니다. 소프트웨어 역시 제대로 설계되고 관리되지 못하고 관리되지 못하면 부폐하는 것이다. 문제는 대부분의 IT 기업에서 이러한 고품질의 소프트웨어 개발보다는 기한 맞추기식 개발이 요구된다는 것이다. 이런 환경에서 일을 통하여 능력을 개발하는 것은 어려운 일일 수밖에 없다.

하지만 나는 '평생 직접 고쳐가며 쓸' 소프트웨어 개발을 목표로 삼았기 때문에 항상 설계 및 방법론에서 최상의 것을 고집했다. 물론 그 까닭에 수차례 기존 코드를 거의 다 버리고 다시 작성해야 했긴 하지만 말이다. MyLEO 개발이 1년 정도 되었을 때 하드코딩한 웹페이지 수십개를 클래스 라이브러리로 바꾸던 일, 그 클래스 라이브러리의 코드 중복을 줄이기 위해 상속 구조로 바꾸면서 수많은 코드를 고쳐야 했던 일이 떠오른다. 당시에는 상당히 고달펐지만, 그일을 겪으면서 뼈저리게 체득한 '좋은 디자인'에 대한 깨달음과 집착은 엔지니어로서 평생의 자산일 것이라고 생각한다.

그동안 개인 프로젝트를 하면서 몇가지 느낀 것이 있다. 앞서 언급한 나의 원칙과도 통하는 것이지만, 우선은 최고의 품질을 유지해야 한다는 것이다. 소프트웨어의 품질은 '설계-구현-테스트-유지보수'로 이어지는 생명주기 중 어느 부분에 가장 많은 노력이 들어가느냐의 문제로 볼 수 있을 것이다. 품질좋은 소프트웨어는 설계에, 그 반대의 경우에는 유지보수에 대부분의 노력이 들어갈 것이다. 스스로 만들고 고쳐가며 사용할 프로그램에서 유지보수에 많은 노력이 들어가야 한다면 수지(?)가 맞지 않는다. 개발은 잠깐이지만 유지보수는 평생이기 때문이다. 문서화의 경우에도 마찬가지다. 하루이틀 쓸 프로그램이 아니라면 자신이 나중에 수정할 때에도 문서를 만들지 않으면 다시 코드를 보아야 하는 수고스러움이 있다.

최근 나의 원래 전공인 전자공학 - 마이크로 컨트롤러를 사용한 로봇 제작 - 에 다시 관심이 생겨서 공부하기 시작했다. 이번에도 내 방식대로 뭔가 쓸만한 것을 만들면서 공부하려고 한다. 개인 비서 로봇같은 것을 만들어 볼 생각이다. 아침에 깨워주고, 기분에 따라 음악도 들려주고 재롱도 부리는 그런 것 말이다. 아직은 개념조차 상당히 애매한 단계이지만, 미래에는 누구나 그런 로봇을 하나씩은 갖고 있지 않을까?

진정한 엔지니어는 주변에서 끊임없이 불편함과 개선점을 찾아 이를 개선할 수 있는 좋은 도구를 만드는 사람이라고 생각한다. 그리고 다른 사람의 문제를 해결하기 전에 스스로의 문제를 해결해 보는 것이 자연스러운 순서일 것이다. 오늘 당신의 문제는 무엇인가요?