제 업무 특성상 하루에도 아주 많은 도움 요청을 받습니다. 가급적 답변에 하루를 넘기지 않으려고 노력하지만, 요즘은 일주일에 두차례씩 외부 개발 컨설팅을 나가고 있어서 보통은 하루나 이틀 정도가 흐른 다음에야 답변을 하고 있습니다. 양해를 부탁드립니다.

오늘 질문받은 건 중에, 현재 데이터베이스 연결에 BDE를 사용중인 프로젝트가 있는데 BDE를 마이그레이션하는 데 대한 조언을 요청한 건이 있어서, 이에 대한 내용을 써볼까 합니다.
왜 BDE를 제거해야 하는가

먼저, 왜 BDE를 들어내야 하는지에 대해 써보죠. 아시다시피 BDE는 2002년 델파이 7이 출시되면서 RDBMS에 대한 연결 지원이 중단되었습니다. 쉽게 말해서 오라클, MS SQL, 사이베이스, DB2 등의 데이터베이스로 연결할 수 없게 되었다는 것입니다. BDE의 SQLLinks가 바로 이런 RDBMS로의 연결을 담당하는 부분인데, 델파이 7 버전부터는 이 SQLLinks가 제거되었습니다.

이에 대해서는 2002년에 볼랜드포럼의 주요 뉴스로 올린 적이 있으니 자세한 내용은 링크를 참고하실 수 있습니다.
http://www.borlandforum.com/impboard/impboard.dll?action=read&db=news&no=93

물론 굳이 사용하려면 편법은 있습니다. 델파이 6까지의 BDE에는 여전히 SQLLinks가 포함되어 있으므로, 구버전 라이선스가 있다면 구버전을 먼저 설치하고 그 이후에 신버전을 설치하면 구버전의 SQLLinks를 그대로 사용하여 BDE로 RDBMS를 그대로 연결할 수 있습니다.

구버전 라이선스가 없을 경우에 BDE의 SQLLinks를 따로 복사하여 쓰는 것이 기술적으로는 가능하지만 라이선스 위반이 됩니다. 이런 경우에는 반드시 제게 연락하여 사전 양해를 받아야 하며 그렇지 않은 경우 불법이 됩니다.

그러면, 이런 방식으로 BDE를 계속 사용할 수 있는 것일까요? 그래도 여전히 문제들이 남습니다.

1. 데이터베이스 버전 문제
BDE는 1999년에 마지막으로 버전업이 되었고, 2001년 델파이 6 버전에서 마지막으로 지원되었던 만큼, 당연히 각 데이터베이스들의 지원 버전도 1999년 당시로 그대로 머물러 있습니다. 오라클의 경우를 보자면 오라클 8 버전까지만 지원하고, SQL 서버도 2000 버전까지만 지원합니다. 당연히 사이베이스나 DB2의 경우도 당시 버전까지만 지원하죠.

새로운 데이터베이스 버전에는 새로운 데이터 타입이 많이 추가됩니다. 오라클에서도 MS SQL에서도 각 버전마다 중요한 새로운 타입들이 많이 추가되어 있습니다. 만약 오라클 데이터베이스에 오라클 9 이후로 추가된 필드 타입이 있다면, BDE에는 그 타입에 대응하는 내부 처리가 되어 있지 않으므로 BDE에서 처리할 수 없게 됩니다. (아마 친숙한 Access Violation이 뜨게 될 겁니다)
그러면, 이런 새로운 타입을 가진 필드들을 아예 사용하지 않으면 되지 않겠느냐, 물론 그렇습니다만, 그렇게 새로운 필드 타입들을 피해간다면 새로운 버전의 데이터베이스를 사용하는 효과도 반감될 것입니다. 또 델파이나 C++빌더로 개발된 이외의 웹 같은 다른 시스템들도 있어서 그쪽에서도 데이터베이스를 다루어야 하는 경우, 그쪽 시스템 담당자들은 왜 구닥다리 버전의 델파이나 C++빌더 시스템 때문에 우리 시스템이 피해를 봐야 하느냐고 불평하거나 반발할 것입니다.

2. 윈도우 버전 문제
BDE는 그 마지막 버전 조차도 윈도우 XP 이상의 버전에 대해서는 아무런 동작 보장을 하지 않습니다. 볼랜드/엠바카데로에서 BDE의 마지막 버전을 내놓은 것이 2001년이므로 당연히 윈도우 비스타와 윈도우 7, 윈도우 2003 서버 등에 대해서는 테스트 자체가 안되었습니다. 따라서 윈도우 비스타와 윈도우 7에 대해서는 아직 알려지지 않은 문제가 발생할 수도 있습니다.

예를 들면 BDE에서는 비스타 이상의 보안 구조를 전혀 고려하지 않고 개발되어 있는데, 그런 이유로 BDE를 사용하기 위해 프로그램을 구버전 델파이로 개발한 개발자가 사용자에게 UAC를 끄라고 조언하는 경우가 종종 있습니다. 이건 아주 위험한 시도인데요, 심각한 문제로 비화될 수 있습니다. 개발자가 사용자에게 UAC를 끄라고 조언한 경우, 그로 인해 비전문가인 사용자가 바이러스나 해킹에 노출되어 피해를 입었다면, 개발자를 대상으로 법적으로 고소하는 것이 충분히 가능합니다. 이게 한두 명의 개인 사용자가 아니라 수십, 수백, 수천명의 기업 사용자가 사용하는 업무 시스템이라면 어마어마한 손해배상을 해야 할 수도 있겠지요.

3. 64비트 문제
특히 BDE는 64비트에서는 전혀 사용이 불가능합니다. BDE는 최초 버전이 16비트로 개발되었고, 32비트로 포팅된 후에도 마지막 버전까지도 16비트 코드가 상당히 남아있습니다. 16비트 코드는 64비트 OS에서 전혀 운영이 안됩니다. 따라서 윈도우 7 64비트 버전에서는 운영이 전혀 불가능합니다. 이런 경우라면 BDE를 무조건 다른 기술로 마이그레이션해야 합니다.

개발자 여러분이 BDE를 사용하여 개발해서 내놓은 소프트웨어를 사용자가 64비트 윈도우에서 사용하려 한다면 당연히 제대로 동작하지 않습니다. 패키지/솔루션 소프트웨어이든 혹은 SI 성격의 업무개발 시스템이든 그 사용자는 강하게 반발할 것입니다. 현재 버전의 델파이는 32비트 개발툴이기는 하지만 개발된 소프트웨어는 64비트 윈도우에서 아무 문제 없이 실행되는데, BDE를 사용하게 되면 문제가 생기게 되는 거죠.

그럼 대안은?

볼랜드에서도 그랬고, 지금 엠바카데로에서도 BDE의 공식적인 대안으로 dbExpress를 강력하게 추천하고 있습니다. 그리고, 그 외에 또다른 범용 데이터베이스 연결 방법으로 ADO가 있죠.

아무래도 ADO를 조금이라도 써본 분이 적지 않을 것이기 때문에, BDE를 들어내려면 ADO가 먼저 대안으로 떠오르는 것이 당연할 것입니다. 그런데 ADO나 dbExpress나 BDE로부터 마이그레이션하는 데 드는 노력은 별 차이가 없습니다. 그리고 지원하는 데이터베이스 면에서는 둘다 약간 차이는 있지만 메이저 데이터베이스는 두루 다 지원한다는 면에서는 별 차이가 없습니다.

그럼, 아무래도 더 친숙한 ADO를 선택해도 되지 않을까요? 하지만 여기에는 몇가지 고려해야 할 점들이 있습니다.

1. 멀티티어로의 전환 문제
최근 버전인 델파이 2009와 델파이 2010에서, 델파이와 C++빌더의 멀티티어 기술인 DataSnap이 전면 재개발되면서, 이전의 COM 의존의 무겁고 기능성이 부족하던 방식에서 가볍고 강력한 멀티티어로 탈바꿈되었습니다. 당장 저 자신부터, 이전에는 MIDAS/DataSnap이 너무 무겁고 기능도 떨어져서 대안으로 서드파티 멀티티어 기술을 사용했었지만, 이제는 새로운 DataSnap 2010을 사용하고 있는데, 아주 만족스럽습니다.

그런데 이 새로운 DataSnap 2010이 강력하기만 할 뿐 아니라, dbExpress를 너무나 멋지게 활용해서, 기존에 dbExpress를 사용하던 프로젝트라면 DataSnap 2010 기반의 멀티티어 방식으로의 전환이 아주 쉬워졌습니다. 어디까지가 dbExpress이고 어디부터가 DataSnap 2010인지 잘 구별조차 안될 정도로 빈틈없이 잘 통합되었답니다.

2. ADO 자체에 대한 의존성의 문제
ADO를 사용하게 되면 당연히 MS 기술에 대한 의존성이 생깁니다. ADO 자체적으로는 SQL 서버나 액세스 외에 다른 데이터베이스도 지원을 하기는 합니다만, 아무래도 ADO로 오라클이나 DB2 등 다른 DB로 연결하면 특정 경향을 타거나 오작동할 우려가 있습니다. ADO 자체가 MS의 DB만을 고려하여 최적화된 엔진이기 때문입니다.

예를 들면, 지난 6월에 MS는 오라클에 대한 ADO.NET 드라이버 지원을 아예 끊겠다고 일방적으로 발표한 바 있습니다.
http://blogs.msdn.com/adonet/archive/2009/06/15/system-data-oracleclient-update.aspx

3. 윈도우에 대한 의존성의 문제
당연하지만 ADO는 플랫폼 의존성이 있습니다. (물론 BDE도 그랬습니다) 윈도우 이외의 OS는 전혀 꿈도 꿀 수 없게 됩니다. 반면 dbExpress는 플랫폼 독립적으로 만들어졌습니다. 지금은 단종되었지만 리눅스용 델파이인 카일릭스가 dbExpress로 델파이와 거의 완벽하게 호환되었었습니다. 물론 카일릭스는 지금 단종되었지만…

아시다시피 내년이면 델파이가 크로스플랫폼으로 갑니다. 리눅스 버전이 다시 나오고, MacOSX, 아이폰까지 지원합니다. 그 이후로 줄줄이 다른 OS 버전들이 계속 개발될 것입니다.
http://blog.devgear.co.kr/imp/entry/MacOSX와-Linux를-위한-Delphi와-CBuilder

당연하게도, dbExpress로 마이그레이션 하면 지금까지 개발한 소스들을 이런 플랫폼으로 쉽게 옮길 수 있지만, ADO로 작업하면 다시 또 dbExpress로 마이그레이션해야 합니다. 또, 당장 델파이의 형제 툴로서 닷넷용 개발툴인 델파이 프리즘에서도 dbExpress를 이용하고 있습니다.

개발자 여러분이 일하고 있는 업계에 따라 당장 리눅스와 MacOSX, 아이폰에 대해 큰 수요가 없을 거라고 생각하실 수도 있지만, 최근 3~4년 사이에 리눅스도 약진했고 Mac의 점유율은 더욱 크게 급등했습니다. 아직 우리나라에서는 크게 느끼기 힘든 수준이지만, 글로벌 시장에서는 MS의 윈도우 점유율이 상당히 크게 떨어지고 있습니다. 이미 일본 등 해외쪽으로 소프트웨어를 수출하는 업체들에서는 윈도우 버전밖에 없다는 이유로 거절당하는 사례도 종종 나오고 있습니다.

이런 여러가지 면들을 고려하면…
굳이 dbExpresss 대신 ADO를 사용해서 크로스플랫폼으로 쉽게 갈 수 있는 기회를 스스로 차단할 필요가 있을까요…?