여전히, 많은 닷넷 프로젝트에서 "COM" 개체를 심심치 않게 사용합니다. 물론, Interop으로 사용하는 COM 개체 역시 참조시에 함께 제공되는 "RCW(Runtime Callable Wrapper)"에 의해서 자원 해제가 자동으로 불려지게 됩니다. 즉, VC++에서는 CoCreateInstance 한 이후에 반드시 IUnknown::Release 메서드를 호출해서 명시적으로 자원을 해제해야 했지만, .NET에서는 해당 COM 개체에 대해 Interop DLL을 통해서 제공되는 RCW 개체가 GC(Garbage Collector)가 구동되면서 COM 개체 자원이 같이 해제(Release)되어 집니다.

그럼... 한번 테스트 해볼까요?

우선, ATL 프로젝트를 하나 만들고 "Simple Object" 유형의 개체를 추가한 다음, 자동 생성된 코드의 "FinalRelease" 메서드에 자원이 해제되었음을 알리는 출력문을 넣어둡니다.

// COM 개체가 해제되었을 때 불려지는 메서드
void FinalRelease()
{
    ::OutputDebugString("CTestObject - Released\r\n");
}

이제, 빌드하고 테스트용 WinForm 프로젝트를 만들어서 위의 COM 개체를 참조한 다음 아래와 같이 그에 대한 RCW 개체를 사용합니다.

// COM 개체를 사용
private void Form1_Load(object sender, EventArgs e)
{
    TestATLLib.TestObjectClass testObject = new TestATLLib.TestObjectClass();
}

// button1 버튼이 눌리면 GC를 호출.
// Form1_Load 안에서 생성되었던 testObject에 대한 RCW 개체가 해제되면서 COM 개체 역시 해제됨.
private void button1_Click(object sender, EventArgs e)
{
    GC.Collect();
}

마지막으로, C/C++의 "OutputDebugString" 함수 호출로 인한 디버그 메시지를 VS.NET Output 창에서도 볼 수 있도록 프로젝트 속성 창에서 "Enable unmanaged code debugging" 옵션을 켭니다. (이거 안 켜두면, 아무리 Debug 빌드일지라도 메시지가 보이지 않습니다.)

이제 실행시키고, "button1"을 누르면 "Output(출력)" 창에 "CTestObject - Released" 메시지가 출력되는 것을 볼 수 있습니다. 결국, COM 개체 해제를 명시적으로 해주지 않아도 자원이 샐 염려는 없으니 별다르게 문제가 없어보입니다. ^^

물론, 그런 가정은 때에 따라서 맞을 수도 있고, 아닐 수도 있습니다. 왜냐하면, 가령 예를 들어 그 COM 개체가 DB에 대한 연결 개체였다면 다음 GC 호출 때 까지는 DB 연결 개체가 해제되지 않고 계속 쌓여갈 테고 급기야 DB 연결이 불가능한 상황에 까지 이를 수 있습니다. 상황을 더욱 안 좋게 만드는 원인이 하나 더 있다면, 대개의 경우 개발시에는 테스트를 위해 한두번 DB 조회/수정/삭제/생성 관련 메서드를 호출해 보기 때문에 아무런 이상이 없다고 넘어가다가, 마지막 실서버에 올려서 서비스를 하게 되면 여지없이 문제가 발생합니다. 물론, 그 때는 이미 소스 코드 양이 많아진 상태이기 때문에 디버깅 및 문제 수정을 위한 적지 않은 비용이 들어가게 됩니다.

그럼, 이럴 때는 어찌해야 하느냐?

그런 경우에는 Marshal.ReleaseComObject를 사용하시면 됩니다. 아마 닷넷 출시 이후 초기 프로젝트에서 COM+ 개체를 이용하여 DB 트랜잭션을 구현해 보신 분들은 익히 알고 계실텐데요. 그래서, 가능한 COM 개체는 다음과 같이 명시적으로 해제하는 코드를 사용해 주시는 것이 좋습니다.

private void Form1_Load(object sender, EventArgs e)
{
    TestATLLib.TestObjectClass testObject = new TestATLLib.TestObjectClass();
    Marshal.ReleaseComObject(testObject);
}

여기까지는 이미 많은 분들이 아실 테고.

그런데, 최근 들어서 C++/CLI에서의 Interop이 많아지면서 다음과 같은 식으로 COM 개체를 사용하는 경우도 있습니다.

=== C# ===
CPPCLI.Helper.UseThisObject(pObject);

=== C++/CLI ===
public static void UseThisObject(Object ^pObject)
{
    IntPtr iPtr = System::Runtime::InteropServices::Marshal::GetIUnknownForObject(pObject);
    CComQIPtr<ITestObject> pTestObject((ITestObject *)iPtr.ToPointer());
}

위험하죠! 그나마 이전에 설명한 RCW는 GC에 의해서 자원해제라도 되지만, 위의 코드로 넘어온 COM 개체는 영원히 해제가 되지 않습니다. 오늘의 퀴즈입니다. 어디가 문제일까요? ^^ (혹시, 여러분들의 코드에서 Marshal.GetIUnknownForObject 메서드를 사용한 곳이 있다면 지금 당장 코드를 추가하시기 바랍니다.)

정답은, 첨부 파일의 예제 프로젝트 안에 있습니다.

---

[이 토픽에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[최초 등록일: 12/6/2008]
[최종 수정일: 7/10/2021]


이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

by SeongTae Jeong, mailto:techsharer at outlook.com