델파이는 수많은 장점을 갖고 있는 프로그래밍 언어입니다. 이미 본 강좌에서 뿐만 아니라 단행본과 인터넷을 통해 많이 알려진 사실이죠. 하지만 많은 델파이 사용자들이 그런 문서를 통해 델파이의 장점만 알고 있고 중요한 단점은 발견하지 못하는 경우가 많습니다. 필자가 생각하는 델파이의 가장 큰 단점을 두 가지만 말하자면 다음과 같습니다.

완벽한 RAD를 지향하다보니 프로그래밍이 사용자 인터페이스(GUI) 중심으로 진행되기 쉬우며, 결과적으로 프로젝트가 비 OOP적으로 만들어질 확률이 높다. 결과적으로 엔진이 없는 프로그래밍을 하게 될 수 있다.
MS에서는 문서를 대부분 VC++, VB로만 설명을 하므로 MS의 신기술을 델파이에 적용할 수 있는 사람이 그리 많지 않다.

이중 두번째는 자신이 해결하지 못하더라도 다른 누군가가 대신 해줄 수 있는 일이므로 실무에서는 그리 큰 문제가 되지는 않는 것 같습니다. 하지만 첫번째 문제는 델파이의 가장 큰 단점이라고 할 수 있으며 지금도 수많은 업체나 프로그래머들이 이 문제를 해결하지 못해 버그가 많거나 안정성이 떨어지는 프로그래밍을 하는 경우가 많습니다. 이것은 어떻게 보면 델파이의 단점이 아니라 RAD툴의 단점이라고 보는 게 더 정확할 것입니다.

폼 디자이너에 속지 말자!
델파이에서 새 프로젝트를 시작하면 델파이는 항상 빈 폼부터 하나 보여주고 시작합니다. 그래서인지 대부분의 델파이 사용자는 빈 폼에다가 기본적인 GUI부터 디자인하고 시작하는 것이 일반적입니다. 하지만 필자가 생각하기에 그것은 좋은 방법이 아닌 것 같습니다.

껍데기부터 만들면 안되는 이유
필자는 이 부분을 설명할 때 항상 자동차를 만드는 일에 비유합니다. 자동차의 예를 들어 간단히 설명해보겠습니다. 초보자가 주로 이용하는 방법은 마치 자동차를 만들 때 껍데기를 먼저 만들고 그 안에 부품을 집어넣는 것과 같습니다. 그러다보니 불량이 발생해도 갈아끼우기가 쉽지 않고 속이 너무 복잡하게 엉켜있어 오류가 있는 부분을 찾아내기도 쉽지가 않습니다.
이번에는 올바른 방법으로 자동차를 만드는 방법을 봅시다. 우선 규격과 용도를 정하겠죠. 최대 속도가 얼마, 마력은 얼마, 승차인원은 몇명 등. 그리고 자동차의 용도는 일반 가족용 승용차로 해놓고 그 다음 자동차의 골격부터 만듭니다. 골격은 바퀴를 달기 위한 부분과 엔진 등 주요 부품을 달기 위한 부분, 그리고 승차를 하기 위한 부분 등을 따로 탑재할 수 있도록 만듭니다. 그리고 골격 위에 바퀴를 먼저 달고 부품을 하나씩 답니다. 그리고 껍데기를 부분별로 하나씩 붙여갑니다.
물론 필자는 자동차 전문가가 아니므로 이것은 실제 자동차를 만드는 과정이 아니고 어디까지나 비유일 뿐입니다. 아직도 수많은 델파이 사용자들은 껍데기를 먼저 만들고 이벤트 핸들러를 이용해 부분 부분별로 부품을 안쪽에 붙여가는 방법으로 진행하고 있습니다. 델파이를 올바르게 사용하려면 우선 이것부터 고쳐야 합니다. 이 문제가 해결되지 않으면 다음과 같은 일이 발생하게 됩니다.

개발 기간이 오래 걸린다
껍데기 중심의 프로그램을 만들다보면 처음에는 진행속도가 빠른 듯 하지만 시간이 지날수록 내부가 복잡해지고 자신도 알지 못하는 부분이 많이 생겨서 개발 기간도 결국 길어집니다.

버그가 산발적으로 많이 발생한다
버그는 프로그램의 가장 큰 적이라 할 수 있는데, 이 경우 어느 한 부분에 버그가 발생하면 원인을 찾는 데 많은 시간이 소요됩니다. 찾아서 수정해도 또 다른 곳에 버그가 발생하는 등, 버그가 꼬리에 꼬리를 물고 발생하지요. 이로 인한 스트레스가 실로 엄청나서, 심하면 개발자가 개발을 포기하고 행방불명(?)되는 사례가 허다합니다.

프로젝트의 문서화가 불가능해진다
사실 프로젝트를 문서로 남기는 일은 개발자에게는 그리 중요하지 않습니다. 하지만 프로젝트의 문서화가 잘되지 않으면 제품은 회사의 소유가 되겠지만 프로젝트의 진행과정이나 노하우 등은 개발자에게만 남게 됩니다. 이렇게 되면 개발자가 회사를 떠나면 기술도 떠나게 될 확률이 높습니다. 때문에 회사의 입장에서는 프로젝트를 문서로 남기는 일이 매우 중요합니다. 하지만 프로젝트가 껍데기 위주로 진행이 됐다면 그것에 대한 프로젝트 진행 과정과 방법 등을 문서로 남기는 것이 힘들어지고 무의미해집니다.

팀 단위 작업이 힘들어진다
팀 작업을 하는 데는 여러 가지 방법이 있겠지요. 규모가 작은 경우 한 사람이 파일을 하나씩(DLL로 나눠서)하면 되겠지만 규모가 조금 커지면 하나의 파일을 여러 사람이 만들게 됩니다. 이때 주로 하는 방법이 폼 단위로 나눠서 하는 방법인데 이것 역시 좋은 방법이 아닙니다. 팀 단위 작업을 원활하게 수행하려면 프로젝트 전체를 OOP적으로 잘 구성해야 합니다.
이 외에도 많은 문제가 있겠지만 프로젝트가 OOP적이지 못하고 인터페이스 위주로 만들어진다면 이와 같은 문제점들이 발생할 수 있습니다. 그러므로 폼 디자이너 중심으로 작업하는 것은 델파이를 배우는 단계에서만 사용하고, 실무에서는 반드시 설계부터 하고 모듈화한 다음 마지막으로 폼 디자이너를 이용해 디자인해야 합니다.

도움이 되었으면 하네요 그럼 이만~