하지만, 그 당시가 이미 Microsoft(이하MS)가 .bet beta를 내놓은 상황이었고, 같이 일하는 사람들중 일부는 이미 .net을 공부하기 시작하신 분도 있었고, 그 당시 꽤 유명한 사이트였던 www.advisor.co.kr(현재는 devpia.com)같은 사이트에서 주최하는 세미나에서도 .net이 과연 얼마나 성공할까라던지, .net의 정신이라던지 하는 것들을 설명하고 있었다.
나중에 공부하면서 알게 된 바로는, .net을 이루는 기본바탕에는 당연히 COM이 놓여있고, 그 앞에는 OLE가 놓여있다. MS의 입장에서는 이미 COM 기술에 대한 확신이 있었다는 이야기이고, 이는 그당시에 이미 나와서 쓰이고 있던 기술들(OpenGL과 GDI등을 대체하기 위한 directX, RDO나 DAO,ODBC를 대체할 ADO)이나 어플리케이션(MS Office제품군, MTS등등) COM으로 이루어져 있다는 사실이 이를 뒷받침 해준다. MS에서 발표하고 이미 상용화된 COM기술을 한국에 입장에서는 구현할 기술은 거의 없고, 이미 COM으로 만들어진 기술들을 사용하는 방법만을 익히고 있는 정도였던 것이다.(알려지지 않은 COM개발도 많았겠지만, 그나마 유명한 거로는 약 1~2년뒤에 한국 정보기술 연구의 메카중 한군데인 ETRI에서 GIS기술을 적용한 Map Object를 개발하여 이를 몇군데 회사가 상용화하고 있다던가, Dream3D란 이름으로 중소 게임 개발사를 위한 3D Library를 COM 형태로 개발했다는 정도가 다 일것이다. 이것도 아는 사람이 거의 없다.)
일단 소프트웨어 강국인 한국의 프로그램 원천기술에 대한 한숨은 이쯤 해두구,주제는 전망이니까 전망을 다시 보자. 현재 MS의 정책의 주류를 이루고 있는 .net이전에 OLE와 COM이 있다고 했다. OLE는 미약하게 남아있지만, 실제로 거의 사용되지 않는다고 봐야하는 것이 옳다(Office97에 있던 OLE의 강한 예였던 연결하여 붙여넣기 같은 기능은 office상위버전에선 발견하기 힘들다.)
그러면 COM도 OLE의 예를 따르게 되는 걸까? ATL/COM에 대한 애착이 있는 필자여서인지 적어도 필자는COM은 상당히 오랜기간 MS기술의 주류를 이룰것으로 본다. OLE는 다른 프로세스사이의 데이터 전송과 데이터 전송에 따른 메세지 전송이 주류였지만, COM은 Component와 Object자체의 전송을 목적으로 둔다. 이는 단순 데이터나 메시지의 전송과는 큰 차이를 보이는 것이다. 대충 C에서 struct를 가지고 작업하던것을 class를 가지고 작업하는 차이라고 말하면 비슷할까? COM은 말 그대로 Component Object Model이며, 이 말에 들어있는 Component와 Object는 과거부터 현재까지 높은 생산성, 코드 재활용, 쉬운 디버깅등을 포괄하는 소프트웨어 개발의 이슈이다.
소프트 웨어 개발의 이슈가 structed프로그램에서 object 그리고, Component시대로 이전된 지금 상황에서 현재 나와있는 어떤 기술보다도 Component를 지향하는 COM기술은 당연히 가장 이슈화되는 기술이 될것이다. 이는 .net으로 대표되는 MS의 정책이 COM을 깔고 있다는 것도 COM기술의 중요성이 새로운 소프트웨어 개발 패러다임이 전개되기 전까지는 계속될것이라는 걸 말해준다.