초창기에 델파이를 배울 때, 윈도우 개발 환경에 대해서 제대로 감을 잡지 못했던 나는 숱한 시행착오를 겪었다. 그중에서 가장 숱한 시행착오를 거친 것이 윈도우의 이벤트 프로그래밍 방식에 대한 이해이다. 이벤트 프로그래밍 방식이란, 폼에 버튼, 라디오박스, 콤보박스 등을 두고 OnClick 이벤트, 폼의 OnCreate, OnDestroy 이벤트를 작성해서 완성하는 방식을 말한다. 델파이를 비롯하여 대다수 윈도우 개발툴들이 이 방식을 채택하고 있다.

그런데, 이 이벤트 프로그래밍 방식이 처음에는 무지 편한 것 처럼 보이지만, 조만간 유지보수가 무지 어려워지고 기능 변경이 매우 까다로운 프로그램 구조를 만든다는 것을 깨닫게 되었다. 도스 시대에서 코볼, 클리퍼 등을 사용해본 독자라면, 도스 시절 개발이 지금의 윈도우 개발 보다 월등히 편하다는 것에 동의할 것이다.

윈도우보다는 도스가 월등히 단순한 오에스인 이유도 있겠지만, 도스 프로그램들은 기본적으로 탑다운(Top Down) 방식이기 때문에 소스 이해도 쉽고, 프로그램의 실행 흐름이 오로지 개발자가 정의한대로만 흐르기 때문에, 수정하기도 쉽다. 물론 개판이 아닌 잘 구조화된 프로그램의 경우이다.

그러나, 윈도우의 메시지 드리번 환경은 개발자가 원하는대로만 실행되는 것이 아니기 때문에 여러모로 고려해야할 것들이 많다. 대표적인 예로 특정 시점에서 어떤 기능의 실행을 막도록 하는 것이다. 예를 들어 수정한 내용이 하나도 없다면 저장 버튼은 비활성화되어야 한다. 만일 도스 프로그램이라면 이런 사항을 전혀 고려할 필요가 없을 것이다.

나는 주변의 델파이를 사용하는 사람들에게 이벤트 메서드를 가급적 최소화하는 방법을 연구해 보라고 가르킨다. 이렇게 가르키면 대부분은 "무슨 헛소리냐 웃기는 소리 하지 마라! 이벤트 방식은 윈도우의 대표적 코딩 방식인데 그걸 가급적 쓰지 말라는게 무슨 소리냐?"라고 반문한다.

Database, Session, Timer같은 Non Visual Component는 폼에 두지 말고 모조리 코드로 생성하고 이 코드는 별도 유닛으로 분리하는 것이 더 좋다고 가르킨다. 이렇게 가르켰을 때도 숱한 반론에 부닥혔다.

가급적 모든 객체는 자동 파괴 방식으로 코딩하라고 가르켰을 때도 명시적인 Free 호출이 더 좋다는 어거지 반대(?)에 부닥혔다. 자동 파괴가 비효율적이고 안 좋은 방식이라면 닷넷과 자바는 무지 공을 들여서 왜 가비지 컬렉터란 기능을 추가했겠는가? 델파이 VCL 역시 상당부분이 자동 파괴를 고려하여 만들어져 있다.

이벤트 메서드를 적게 만드는 방식의 코딩, Non Visual 콤포넌트를 폼에 두지 않는 방식의 코딩, 자동 파괴 방식의 코딩을 오랫동안 연구해오면서, 해외의 수많은 델파이 개발자들도 나와 같은 고민을 가진 개발자들이 많으며, 그 문제점을 해결하려 여러 방법으로 시도했던 흔적들을 찾아 볼수 있었다.

개발자들이 절대로 피해야할 안 좋은 태도 중 하나가 더 좋은 방식 채택을 거부하는 것이다. 기존 방식으로도 코딩하는데 아무런 문제가 없는데 왜 새 방식을 배워야 하냐는 태도이다. 이는 우리 분야 같이 혁신이 빈번한 곳에서는 매우 살아남기 힘들게 하는 태도이다.

그렇다면 좋은 코딩 방법을 대체 왜 배워야 하는 것일까? 그 결론적 이유인즉, 버전 2를 더욱 잘 만들기 위해서다.

내 경험에 의하면 버전 1의 프로그램은 성공하기 힘들다. 대부분 프로그램은 버전 3 정도에서 진가 즉 실제 매출 증대를  발휘하게 된다. 델파이의 경우만 봐도 그렇고, 윈도우란 오에스를 봐도 그렇다. 윈도우 xp는 대체 버전 얼마인 윈도우일까? 윈도우 1.0부터치면 엄청난 버전업을 거친 프로그램이다.

좋은 코딩 습관을 익혀두지 않으면 버전 2를 만들기가 무지 힘들어진다. 프로그램을 새로 만드는 것 보다, 기존 프로그램의 기능을 추가 수정하는 업그레이드 작업이 얼마나 더 힘든지는 겪어 본 사람은 알 것이다. 기존의 모든 기능들이 제대로 동작하면서 새 기능들이 기존 기능들과 충돌하지 않게 하는 것은 사실 매우 어려운 작업이다.

상당수의 개발자들이 버전 1.0은 잘 만들지만, 이후 버전 업 과정에서는 대부분 엉망이다. 버전 1.0을 낸 다음에 반드시 거치는 작업이 버그 패치 작업이다. 이 버그 패치작업도 제대로 못하는 팀들이 국내에 매우 허다하다. 올바른 2.0 버전을 내는 팀은 더욱 적을 수 밖에 없다.

솔직히 말해서 나 스스로도 버전2를 아주 편하게 만드는 경지까지 올라서지 못했기 때문에, 나이만 헛먹은 개발자임을 스스로 자인하고 있다.

유지 보수가 편한 정갈한 소스를 만드는 것은 사실 무지 어렵지만 개발자로서 살아 남을려면 반드시 해야만 하는 작업이다. 완벽하지는 않더라도 후일 유지 보수를 고려하여 어느 정도 깔끔하게 정리된 소스를 만들려고 항상 노력해야 한다.

이 때문에 나는 윈도우 프로그램이라해도 소스 구조는 탑다운 방식처럼 보이도록 하기 위해서 무지 애쓴다. 그래야만 후일 다시 이 소스를 봤을 때 어떤 기능 추가를 위해 어디를 고쳐야 할지 금방 알 수 있기 때문이다.

결론인즉, 윈도우 프로그램이라도 이벤트 방식에 너무 의존하지 말고 탑다운 방식으로 보이도록, 즉 프로그램 실행 흐름이 확연히 보이는 구조로 만들도록 연구해 보라는 것이다. 불가능해 보이는가? 전혀 아니다. 이미 해외의 델 개발자들 중에는 이미 이런 방식으로 코딩하는 사람들이 많은 것으로 알고 있다. 그러나 국내 게시판에서 이런 구조의 소스를 보기 힘든 것이 무지 안타까울 뿐이다.

이 글을 쓰는 나도 사실 그다지 소스가 정갈하지는 못하지만 소스 구조를 더 이해하기 쉽도록 개선하려고 항상 무지 애를 쓴다. 소스의 가독성이 변수나 함수 같은 명칭으로 쉬운 영단어를 선택하여 작성하고, 줄 띄우기, 인덴트 등만을 잘해서 이뤄질 것 같은가? 이것을 잘하는 것은 원고지에 글 쓸때나 하는 단순 원칙이고 더욱 중요한 것은 소스의 일관된 체계성과 간결한 구조 유지다. 

분명한 것은 모든 기술 분야가 그렇지만 우리 분야는 특히나 머리 쓰기를 게을리하면 도태된다는 것이다.