아직도 COM+를 쓰시나요?

  
Written by 안재우(Jaewoo Ahn), 닷넷엑스퍼트(.netXpert) 

오늘은 보시다시피 약간 위험한(?) 제목의 포스트를 쓰게 되었습니다. 우선 제목만 보고 너무 섣불리 단정지으시는 분들이 없으시길 빕니다. 그리고 제 의견이 절대 '정답'이나 '진리'는 아니며, 제 의견과 다른 의견을 가지신 분들 역시 얼마든지 계실 수 있습니다. 그럴 경우, 소모적인 논쟁보다는 건설적인 토론을 했으면 한다는 것을 노파심에 얘기해둡니다.

 

최근 사용 중인 개발 프레임워크의 업그레이드 진단을 요청받아, 분석을 해본 것이 여러 건 있었습니다. 이 프레임워크들은 저희 회사가 개발한 것이 아니었으며, 다른 회사들에서 개발한 것이었습니다. .NET으로 이런저런 프로젝트들을 해보셨을 분들은 한번쯤은 이 회사들의 프레임워크를 써보신 분들도 좀 있으시겠네요.

 

공교롭게도, 이 프레임워크들에게서 매우 공통적으로 보이는 특성들이 있었습니다. 그건 바로 'COM+'를 기반으로 만들어진 프레임워크들이라는 것이죠. (사실 다른 항목들도 있지만, 이건 다음에 써먹도록 하겠습니다.)

 

굳이 프레임워크를 사용하지 않더라도, COM+라는 것을 보신 분들이 있으실 겁니다. 지금 운영 중인 회사의 시스템에서 여전히 COM+를 사용하고 있을 수도 있을 거구요.

 

그럼 여기서 잠깐..!

COM+를 왜 사용하시나요?

특히 만약 .NET을 사용하신다면, 왜 아직도 COM+를 사용하고 계십니까?

 

이유를 명확하게 말하실 수 있는 분들이라면, 사실 이 질문은 애초부터 할 필요도 없습니다.

하지만 답변을 명확하게 못하거나 '원래부터 그랬으니깐'이라거나 '프레임워크에서 쓰도록 되어 있으니깐' 등의 답변이라면, 다시 한번 생각해봐야 합니다.

 

솔직히 고백하자면, 이러한 문제를 만든 것에 제가 어느 정도의 책임이 있는 것 같습니다. 왜냐하면 예전 2004년에 만들어서 공개했던 .NET 표준 개발 가이드에서 COM+를 사용하는 것을 기반으로 설명을 했으며, 함께 공개한 Microsoft.Framework(DxFramework Lite)가 COM+를 기반으로 하기 때문입니다.

사실 이 당시에도 Biz나 Dac 단에서 트랜잭션 모델의 간편화를 통한 생산성/유지보수성/확장성의 측면에서 COM+를 '선택'했을 뿐이지, 반드시 COM+를 써야 한다라고 했던 것은 아니었습니다. 그런데 이 얘기가 와전되었는지, COM+를 무조건 꼭 써야 하는 것처럼 알고 계신 분들이 상당수 있다는 것에 놀랐습니다. '.NET 표준 개발 가이드에 그렇게 되어 있던데요?'라는 얘기를 듣고 제가 큰 실수를 저질렀다는 것을 깨달았습니다.

 

최근에 리뷰한 개발 프레임워크를 만든 업체들의 문서 등을 보면, 밑도 끝도 없이 무조건 모든 클래스를 다 COM+ 컴포넌트(즉 ServicedComponent를 상속받는 컴포넌트)로 만들어야 한다고 해둔 경우도 있었습니다. 프레임워크 제공 업체가 그렇게 얘기하니, 프레임워크를 사용하는 고객사나 협력업체 개발자들은 아무 생각없이 그렇게 만들어왔습니다.

그러다 보니, '서버에서 돌아가는 거면 무조건 COM+에서 다 올려야 하는거다'로 이해하고 있는 사람들마저도 한 둘이 아니었습니다.

 

어떤 분들은 COM+에 올린다고 문제가 되냐라고 반문하실지도 모르겠습니다. 저 역시 http://support.microsoft.com/kb/890425/en-us와 같이 COM+의 과다사용으로 인한 문제 등을 보기 전까지는 그렇게 생각했습니다. COM+ 카탈로그에 몇 만개가 넘는 개체가 등록되어 '구성요소 서비스' 스냅인을 한번 띄우면 CPU가 한참동안 100%를 치는 웃지 못할 상황을 보기 전까지는 이런 문제를 생각할 수 없었습니다. -.-;;

 

자, 이쯤에서 미리 분명히 해두겠습니다.

.NET 표준 개발 가이드는 무려 5년전인 2004년, .NET 1.1 시절에 작성된 것입니다. 그 당시 기준으로는 맞았을지 모르지만, 곧 2010년과 .NET 4.0을 목전에 두고 있는 상황에서는 적합하지 않은 내용들이 상당수 있습니다. COM+ 관련 내용을 제외하고도 많은 내용들이 현재의 시점에 맞게 재검토되어야 합니다.

 

다시 원점으로 돌아가서, 원칙적으로 COM+를 사용해야 하는 경우는 보통 다음 중 하나가 필요한 경우입니다.

- 분산 트랜잭션 또는 선언적-자동 트랜잭션 모델이 필요한 경우

- Object Construction String/Activate-Deactivate 등과 같은 개념이 필요한 경우

- 개체 풀링(Object Pooling)이 필요한 경우

- Queued Component, Loosely-Coupled Event 등이 필요한 경우

- 원격 호출(RPC)이 필요하며, 보안(인증/암호화) 등이 필요한 경우

 

과거에는 저러한 내용에 대한 해결책이 COM+ 밖에 없었습니다. 하지만 지금은 2009년입니다. 굳이 COM+가 아니더라도 저러한 작업들을 처리할 수 있는 방법들은 많습니다.

예를 들어, .NET 2.0부터 도입된 System.Transaction을 활용하여 굳이 ServicedComponent로부터 상속받지 않더라도 선언적 트랜잭션 모델을 사용할 수 있으며, 분산 트랜잭션으로 Promotion시킬 수도 있습니다. 또한 WCF의 트랜잭션을 사용할 수도 있구요.

Object Construction String은 Configuation으로, Activate-Deactive와 같은 동작은 AOP로 얼마든지 해결될 수 있습니다. 개체풀링 역시 DB의 경우 ADO.NET은 이미 연결 풀링을 제공하니 2004년에도 굳이 쓸 필요가 없었습니다. DB 연결이 아닌 경우에는 연결 풀링이 의미가 있을수도 있지만, 이것 역시 WCF에서 간단하게 제어하는 것이 가능합니다. Queued Componet, 원격 호출 등등도 이미 WCF에서 다 제공하고 있지요.

 

그러한 연유인지 COM+는 Windows XP/Windows 2003의 COM 1.5에서 더 이상 아무런 업그레이드가 되지 않고 있습니다. 현재의 COM+는 OS 서비스 중 일부로서의 의미만을 가지며, 기존 플랫폼과의 호환성을 위해 제공될 뿐입니다. 그에 따라 우리가 COM+ 컴포넌트를 작성해야 할 필요성은 더 이상은 없다고 봅니다.

 

제가 하는 얘기는 당장 COM+를 쓴다고 해서 문제가 있다는 것을 말하는 것이 아닙니다. COM+는 매우 성숙된 기술이며, 적어도 몇 년 전에는 COM+ 외의 대안이 없을 정도로 훌륭한 솔루션이었습니다. 다만, 이제는 굳이 COM+를 사용하지 않더라도(좀 더 정확하게 말하면 COM+ 컴포넌트를 작성하지 않더라도) 동일한 작업들을 수행할 수 있다는 것을 의미합니다.

 

행여나 아직도 자사의 프레임워크나 아키텍처 그림 등에서 COM+를 언급하는 경우가 있다면, 그 이유를 한번 물어보시기 바랍니다. 어쩌면 그 사람들의 세월도 .NET 1.1 시절에 멈춰버렸을지도 모릅니다.

 

p.s. 어찌보면 COM+의 의미가 퇴색하면서, 뭔가 관리 콘솔 같아 보이는 것이 필요하다는 의견이 AppFabric이 나오게 된 계기일지도 모릅니다. 물론 AppFabric은 단순한 관리 콘솔 그 이상입니다만.. ^^