전에도 몇번 언급한 적이 있는데, 저는 최근 몇년 동안 3티어 업무 프로젝트를 주로 하고 있고요.
하이 레벨에서는 제가 개발한 프레임워크를 씁니다만, 그 아랫단에 kbmMW가 기반이 되어 있습니다.

일단 기존의 DataSnap(이전에는 MIDAS라고 불렸었죠)은 본격적인 3티어 프로젝트에는 아주 부적합합니다.
기능적으로나 성능적으로나 거의 꽝 수준이었구요. 그래서 DataSnap/MIDAS 기반으로 진행했던 프로젝트들 중 상당수가 수행 결과면에서는 대체로 좋지 않은 평을 받았다는 얘기들을 많이 들었습니다.

그에 비해, kbmMW는 기능과 성능 면에서는 아주 만족스러웠기 때문에 계속 쓰고 있는데요. 써보지는 않았지만 kbmMW의 경쟁 제품인 RemObjects의 경우도 아마 대동소이할 거라고 생각합니다. kbmMW만의 장점이라면, 아키텍처가 다른 벤더들의 컴포넌트들과 잘 연동되도록 되어 있고 확장도 비교적 쉽다는 점을 들 수 있습니다.

반면, kbmMW의 경우 프레임워크가 지나치게 복잡하고 개발자의 접근이 쉽지 않다는, 꽤 큰 단점들도 있습니다. 개발 결과물도 그렇게 썩 3티어틱(?)하게 나오는 편이 아닙니다. (또.. 필드에서 개발하다보면 kbmMW의 컴포넌트들의 이름이 허벌 길다는 것도 부수적으로 불만.. --;;)

그런데, 며칠전에 발표된 델파이/C++빌더 2009에서는 그동안 혹평과 외면을 받아온 DataSnap이 대폭 강화되어서 꽤 관심을 가지고 보고 있습니다. 일단 델파이 프로덕트 매니저인 닉 호지스가 직접 시연하는 DataSnap 시연 동영상을 보면 대략의 감을 알 수 있구요.

DataSnap in Delphi and C++Builder 2009 – Multi-tier and thin client database solutions and data remoting
http://dn.codegear.com/article/38587

보시면 아시겠지만, 기존의 DataSnap과는 엄청 달라졌습니다. 일단 세가지 서버 컴포넌트들이 추가되고, 이것들을 중심으로 서버쪽 개발 방식이 확 바뀌었습니다. 클라이언트쪽에서도 아주 기발한(?) 방식으로 개발이 진행되는군요.

kbmMW에 비하면, 새로운 DataSnap의 접근 방식은 3티어의 원론에 더 가깝기도 하고 많이 복잡하지 않아서 일단 호감이 팍팍! 갑니다. 또, 개발자의 입장에서는 프로그래밍 인터페이스의 여러가지 면에서 아주 신선한 방식이기도 합니다.

클라이언트쪽에서 dbExpress의 데이터베이스 커넥션 컴포넌트인 TSQLConnection의 프로퍼티중 Driver에서 바로 "DataSnap"을 지정하고 바로 그 속성을 확장해서 호스트 주소와 포트 등을 지정하는 방식이죠. dbExpress와 DataSnap 사이의 경계가 사라지는, 그래서 그만큼 더 코딩의 확장성이 좋아지는 방식인 것 같습니다.

새로운 DataSnap에서 가장 맘에 드는 것은, kbmMW의 방식보다 접근과 학습이 쉽다는 것일 듯 하네요. 매번 개발자들을 가르치느라 꽤 땀좀 뺐거든요. 물론 쉽다는 것이, 전체 규모가 kbmMW보다 작아서 컴포넌트의 갯수가 적은 탓이 가장 크겠습니다만...

반면에, 아직 기능적으로 부족한 것도 많고, 많이 테스트해보지는 못했지만 아무래도 kbmMW에 비해서 성능면에서도 많이 떨어질 듯 합니다. 그래도 기존의 DataSnap보다는 많이 빨라질 것 같습니다만.

그래도 중소규모 업무 프로젝트에서는 가볍게 도입이 가능할 듯 하고요. 또, 델파이와 C++빌더가 한두 버전이 더 올라가면서 더욱 강화되면 kbmMW를 버리고 옮겨탈 수 있을 거 같습니다. 그때쯤에는 제 프레임워크의 아랫단을 kbmMW에서 새로운 DataSnap으로 갈아치워야죠.