ActiveX / OCX를 지금 어떻게 다룰 것인가 - 남길지・감쌀지・교체할지 판단표

ActiveX / OCX라는 말이 나오는 안건은 대개 분위기가 약간 무겁습니다.

• VB6이나 오래된 C++ / MFC 앱이 아직 현역
• 산업 기기나 계측기의 SDK가 OCX만 내놓고 있다
• 사내 Web이 ActiveX 전제로, IE 모드에서 빠져나올 수 없다
• 32bit에서 64bit로 옮기고 싶은데 1개의 OCX가 고개를 젓고 있다

다만, 여기서 「오래됐으니 전부 버린다」도 「동작하고 있으니 영구 보존」도 둘 다 거칩니다. 중요한 것은 그 ActiveX / OCX가 단순한 UI 부품인지, 아니면 업무 사양이나 기기 사양을 안고 있는 경계면인지를 구별하는 것입니다.

이 글에서는 ActiveX / OCX를 발견했을 때, 남길지・감쌀지・교체할지 중 어느 것을 선택해야 할지를 판단하기 쉬운 순서로 정리합니다.

대상은 예를 들어 다음과 같은 경우입니다.

• VB6 / MFC / WinForms 계열의 기존 데스크톱 앱
• C# / .NET으로의 단계적 이행
• WebBrowser / IE 모드를 포함하는 레거시 화면
• 벤더제 ActiveX 컨트롤을 포함하는 Windows 앱

1. 먼저 결론(한마디로)

• ActiveX / OCX를 봤을 때 먼저 판단해야 할 것은 「오래됐는지 여부」가 아니라 그 부품이 무엇을 떠맡고 있는가입니다
• 단순한 UI 부품이라면 교체는 비교적 하기 쉽습니다
• 기기 제어, 장표, 독자 파일 형식, 오랜 운용 버릇을 안고 있다면, 갑자기 재구현하기보다 먼저 감싸는 편이 안전합니다
• 데스크톱에서 안정 가동하고 있으며 변경 범위가 작다면 남기는 판단도 충분히 가능합니다
• 브라우저 상의 ActiveX 의존은 연명은 가능해도 미래가 가늘기 때문에 교체 우선으로 보는 편이 좋습니다
• 32bit OCX를 64bit 프로세스에 그대로 로드할 수는 없습니다. 여기는 기합으로는 넘을 수 없습니다
• 등록, 의존 DLL, 관리자 권한, 라이선스, STA / MTA 등, 구현 이외의 마찰이 난관이 되기 쉽습니다
• 「일단 전면 리라이트」와 「무서우니까 영구 동결」은 둘 다 사고율이 높습니다

요컨대 판단의 순서는 대개 다음과 같습니다.

1. 그 OCX는 무엇을 가지고 있는가
2. 동일 프로세스에서 사용할 필요가 있는가
3. 32bit / 64bit, 등록, 브라우저 의존으로 막히지 않는가
4. 테스트 가능한 경계를 만들고 나서 교체해야 하는가

이 순서로 보면 상당히 정리하기 쉬워집니다.

2. 이 글에서 말하는 ActiveX / OCX

여기는 용어를 조금만 정리합니다.

엄밀히 말하면 ActiveX와 COM은 같은 것이 아닙니다. 다만, 실무에서 곤란한 지점은 상당히 비슷합니다.

• 32bit / 64bit가 맞물리는가
• 등록이나 의존 DLL을 어떻게 배포하는가
• 어느 호스트 / 컨테이너에서 동작하는가
• STA, 메시지 루프, 콜백에서 막히지 않는가
• 브라우저 의존이 남아 있지 않은가

이 글에서는 이러한 실무상의 판단 포인트를 한데 묶어 다룹니다.

3. 먼저 보는 판단표

3.1. 전체상

먼저 이 표를 보면 대체적인 방침이 정해집니다.

flowchart TD
    start["ActiveX / OCX가 있다"] --> q1{"브라우저 의존?"}
    q1 -- "예" --> p1["교체를 우선<br/>IE 모드는 연명책"]
    q1 -- "아니오" --> q2{"주로 UI 부품?"}
    q2 -- "예" --> q3{"동등한 대체가 있는가?"}
    q3 -- "예" --> p2["교체를 검토"]
    q3 -- "아니오" --> p3["먼저 감싸서 경계 정리"]
    q2 -- "아니오" --> q4{"기기 제어・독자 사양・장표 로직을 안고 있는가?"}
    q4 -- "예" --> p4["먼저 감싼다<br/>테스트를 갖추고 나서 단계 교체"]
    q4 -- "아니오" --> q5{"등록・bitness・배포가 아픈가?"}
    q5 -- "예" --> p5["구성을 재검토<br/>out-of-proc / 별도 프로세스 연계 / Reg-Free COM을 검토"]
    q5 -- "아니오" --> p6["남기는 판단도 현실적"]

이하, 각 패턴을 순서대로 봐갑니다.

3.2. 남기는 판단

ActiveX / OCX라고 해서 곧바로 교체 대상이 되는 것은 아닙니다. 다음 조건이 갖춰진다면 남기는 것이 가장 저렴한 경우는 흔합니다.

• 이용 범위가 닫혀 있고, 사내 배포나 장치 동봉 등 운용 환경이 고정되어 있다
• 그 컨트롤이 지금도 안정 가동하고 있으며, 변경 요구가 크지 않다
• 벤더가 아직 현역이거나, 자사에서 최저한의 보수가 가능하다
• 브라우저 의존이 아니라 데스크톱의 기존 호스트 상에서 완결되어 있다
• 32bit / 64bit의 전제를 당분간 바꾸지 않아도 된다

여기서 중요한 것은 남기기 = 방치가 아니라는 점입니다. 남긴다면 적어도 다음은 해두는 편이 좋습니다.

• 대응 OS, bitness, 필요한 의존 DLL, 등록 순서를 문장으로 남긴다
• 설치, 등록, 해제를 수작업 메모가 아니라 스크립트나 인스톨러로 옮긴다
• 클린 환경에서의 스모크 테스트를 준비한다
• 컨트롤로의 호출을 앱 전체로 퍼뜨리지 말고, 가능한 한 1곳에 모은다

가장 안 좋은 것은 「동작하고 있으니 건드리지 않는다」를 10년 계속해서 아무도 전제를 설명할 수 없게 되는 것입니다. 남기는 선택을 할수록 전제의 가시화는 중요해집니다.

3.3. 감싸는 판단

실무에서는 이 선택이 가장 일거리가 됩니다.

여기서 말하는 「감싼다」는 ActiveX / OCX를 좁은 경계의 안쪽에 가두고, 주변에서는 새로운 API나 새로운 화면 부품으로서 보이게 하는 것입니다.

이것은 상당히 효과적입니다. 왜냐하면, 오래된 부품의 거동을 다 읽을 수 없는 단계에서 전면 재구현에 들어가면 사양 발굴과 불구 재현의 이중고가 되기 쉽기 때문입니다. 먼저 오래된 부품을 격리하고 경계만 정돈하는 편이 안전합니다.

감싸는 방법으로는 예를 들어 다음과 같은 것들이 있습니다.

특히 중요한 것은 감쌀 때 오래된 API를 그대로 200개 복사하지 않는 것입니다. 그걸 하면, 오래된 사정을 새 코드로 그대로 수입할 뿐입니다.

감쌀 때는 다음을 의식하면 상당히 나아집니다.

• 굵은 입자의 메서드로 한다
• 화면 코드에서 직접 OCX를 건드리게 하지 않는다
• 실패 시에 필요한 로그를 경계에서 취한다
• 타임아웃, 재시도, 예외 변환의 책무를 경계에서 정한다
• 장래의 교체 대상도 같은 인터페이스로 치환할 수 있도록 한다

새로운 .NET 쪽에서 COM의 입구만 남기고 싶은 경우도 있습니다. 이 경우는 「내용물은 업데이트하면서 COM 계약만 유지한다」라는 구성이 현실적입니다. 다만, .NET Framework 시대의 감각으로 「일단 RegAsm」으로 해결된다고는 할 수 없습니다. 지금의 .NET의 COM host, TLB, bitness, Registry-Free COM의 취급은 먼저 설계해 두는 편이 나중에 편합니다.

3.4. 교체하는 판단

교체에 적합한 것은 주로 표면의 낡음이 문제가 되는 케이스입니다.

예를 들어 다음과 같을 때는 교체 우선으로 보는 편이 좋습니다.

• 그 ActiveX가 UI 부품으로만 사용되고 있다
• 벤더가 .NET / WPF / WebView2용의 후계를 내놓고 있다
• 브라우저 의존이나 IE 전제가 발목을 잡고 있다
• 등록, 서명, 관리자 권한, 보안 설정에서 매번 걸린다
• 대체 구현을 검증할 수 있는 테스트나 업무 시나리오가 있다

반대로, 겉모습이 낡았다는 이유만으로 기기 제어나 장표 로직까지 안고 있는 부품을 한 번에 버리려고 하면, 대개 진흙탕이 됩니다.

교체한다면 먼저 UI부터입니다.

• 그리드
• 캘린더
• 트리
• 브라우저 표시부
• 단순한 입력 보조

이 부근은 비교적 교체하기 쉽습니다. 한편으로 다음과 같은 것은 UI처럼 보여도 내용물이 진합니다.

• 벤더제 기기 제어 ActiveX
• 인쇄나 장표 생성과 일체화된 컨트롤
• 독자 파일 형식의 읽기 쓰기를 내포하는 컨트롤
• COM 콜백이나 스레드 전제를 안고 있는 컨트롤

이 차이를 잘못 보면 공수 견적이 한 번에 무너집니다.

3.5. 브라우저 의존은 별도 프레임으로 생각한다

여기는 상당히 별도 프레임입니다.

브라우저 상의 ActiveX는 데스크톱의 OCX와 달리, 앞으로도 그대로 늘려갈 이유가 상당히 약합니다.

이유는 단순해서, 현대의 브라우저 기반이 거기를 주전장으로 삼고 있지 않기 때문입니다. Microsoft Edge 자체는 ActiveX를 지원하지 않습니다. 한편으로 IE 모드는 설정된 사이트에 대해 IE 계열의 엔진을 사용해 ActiveX를 포함한 일부 IE 기능을 동작시키기 위한 호환 레이어로서 사용할 수 있습니다.

즉,

• 지금 동작시키기 위한 연명은 가능
• 하지만, 장기 설계로서는 미래가 굵지 않다

는 것입니다.

같은 일은 Windows 앱에 임베드한 WebBrowser 컨트롤에도 일어납니다. WebBrowser는 IE 계열의 세계관을 끌고 오므로, 단순히 HTML을 표시하고 싶을 뿐이라면 지금부터의 신규 작업은 WebView2를 제1후보로 삼는 편이 자연스럽습니다.

다만, 여기서 주의하고 싶은 것은 WebView2는 WebBrowser의 완전한 교체 부품이 아니라는 점입니다.

• IE DOM 전제의 스크립트
• ActiveX 의존
• window.external 주변의 전제
• 보안 존이나 인트라넷 전제의 거동

이 부근은 그대로는 옮겨지지 않습니다. 교체한다면 렌더링 엔진뿐만 아니라 브라우저와 네이티브의 접속면도 재설계할 필요가 있습니다.

4. 판단을 흐트러뜨리기 쉬운 논점

4.1. UI 부품인가, 사양을 안은 부품인가

이것이 가장 중요합니다.

오래된 그리드나 캘린더라면, 겉모습과 이벤트의 호환을 보면 상당히 이야기가 진행됩니다. 한편, 기기 제어나 장표나 독자 형식을 안은 ActiveX는 겉모습 뒤에 사양의 덩어리가 있습니다.

예를 들어, 같은 「화면상의 컨트롤」처럼 보여도 실제로는 다음과 같은 차이가 있습니다.

• 단순한 일람 표시 부품
• 독자 프로토콜로 장치에 명령을 날리고 있는 부품
• 내부에서 타임아웃, 재접속, 재송신, 예외 흡수까지 하고 있는 부품
• 인쇄나 익스포트 형식의 호환을 짊어지고 있는 부품

후자를 갑자기 재구현하는 것은 대개 사양 발굴 프로젝트가 됩니다. 여기는 먼저 감싸는 편이 안전합니다.

4.2. 32bit / 64bit와 프로세스 경계

여기는 자주 간과되지만 상당히 본질입니다.

in-proc의 OCX는 로드하는 프로세스와 bitness를 맞춰야 합니다. 즉, 32bit OCX를 64bit 앱에 그대로 로드할 수 없습니다.

이때의 현실적인 선택지는 대략 다음 중 하나입니다.

• 당분간 호스트 앱 쪽도 32bit 그대로 유지한다
• 32bit의 별도 프로세스에 가두고, 64bit 쪽과는 IPC나 out-of-proc COM으로 연결한다
• 그 OCX 의존을 뗄 수 있는 곳부터 먼저 교체한다

여기서 「Any CPU니까 어떻게든 될 것」은 대개 통하지 않습니다. 새로운 .NET 쪽에서 COM 호환 창구를 만드는 경우도, managed 코드의 겉모습과 실제 COM host의 bitness는 별개 문제입니다. 여기를 거칠게 시작하면, 빌드는 통과했는데 배포처에서 동작하지 않는다는 싫은 녀석이 나옵니다.

4.3. 등록, 배포, 권한, 라이선스

기술적으로는 부를 수 있는데 배포에서 죽는다. 이것은 ActiveX / OCX에서 꽤 자주 있습니다.

난관이 되기 쉬운 것은 예를 들어 다음입니다.

• regsvr32의 전제가 사람 의존이 되어 있다
• 의존 DLL의 배치가 암묵적으로 되어 있다
• 관리자 권한이 필요한데 운용 순서로 떨어져 있지 않다
• 벤더제 컨트롤의 design-time / runtime 라이선스가 나뉘어 있다
• 개발기에서는 동작하지만 클린 환경에서는 동작하지 않는다

이 부근은 코드를 1줄도 건드리지 않아도 프로젝트를 멈춥니다.

등록 불필요의 구성이나 side-by-side 배치로 편해지는 경우도 있지만, 마법의 가루는 아닙니다. 컨테이너 쪽이나 배포 방식과의 상성 확인이 필요합니다.

요컨대, ActiveX / OCX의 이행은 구현뿐만 아니라 배포 설계이기도 합니다. 여기를 뒤로 미루면 마지막에 화려하게 넘어집니다.

4.4. STA / 메시지 루프 / 콜백

ActiveX / OCX는 단순한 DLL 호출이 아닙니다. COM의 스레드 모델이나 메시지 루프의 전제를 가지고 있는 경우가 있습니다.

특히 주의하고 싶은 것은 다음과 같은 케이스입니다.

• UI 스레드 전제로만 안정된다
• STA 전제인데 MTA 쪽에서 거칠게 부르고 있다
• 동기 호출 중에 콜백이 돌아온다
• 이벤트를 받는 스레드 전제가 애매하다

이 부근은 처음에는 「가끔 굳는다」「가끔 이벤트가 오지 않는다」라는 괴담의 얼굴을 하고 나타납니다. 하지만 내용물은 대개 전제 위반입니다.

그래서 감쌀 때도 교체할 때도, 어느 스레드에서 생성하고, 어느 스레드에서 부르고, 어디서 이벤트를 받을지는 먼저 고정하는 편이 좋습니다.

4.5. 테스트가 있는가, 관측할 수 있는가

교체가 어려운 것은 코드가 오래됐기 때문만이 아닙니다. 무엇을 근거로 「같이 동작했다」라고 할 수 있는가가 없기 때문입니다.

예를 들어, 다음이 있는 것만으로도 꽤 다릅니다.

• 조작 시나리오별 스모크 테스트
• 입출력 샘플
• 화면 캡처나 장표 샘플
• 에러 패턴과 기대 거동
• 타임아웃 시나 장치 미접속 시의 로그

특히 기기나 장표가 얽히면 사양서보다 현물의 거동 쪽이 진실이라는 묘한 일이 일어납니다. 여기서 관측 수단이 없으면 교체는 발굴 조사로 바뀝니다.

5. 전형 패턴별 추천

5.1. 지금도 안정되게 동작하는 사내 데스크톱 앱

추천은 남기는 쪽입니다.

다음과 같은 조건이라면 무리하게 떼어내지 않는 편이 좋은 경우가 많습니다.

• 사내 한정으로 사용하고 있다
• 대상 단말이나 OS가 어느 정도 고정되어 있다
• 그 OCX는 몇 개의 화면에서만 사용하고 있다
• 개수 요구는 작고 수명도 읽힌다

다만, 그대로 맨몸으로 두는 것이 아니라 호출 위치만은 모아 두는 편이 나중에 효과적입니다.

즉, 방침으로는 이렇습니다.

• 지금은 남긴다
• 하지만, 경계만 정리한다
• 교체가 필요해졌을 때 거기서 착수할 수 있는 형태로 한다

이 3단계 구성이 자연스럽습니다.

5.2. 32bit OCX를 64bit 쪽으로 가져가고 싶다

추천은 감싸기 / 구성 변경입니다.

여기는 정면에서 가면 막힙니다. 32bit OCX를 64bit 프로세스에 in-proc로 넣을 수는 없기 때문입니다.

현실적으로는 32bit의 헬퍼 프로세스나 LocalServer 쪽에 가두고, 64bit 앱과는 굵은 API로 통신하는 구성이 다루기 쉽습니다.

sequenceDiagram
    participant App as 64bit .NET 앱
    participant Bridge as 32bit 헬퍼 / LocalServer
    participant Ocx as 32bit OCX

    App->>Bridge: 굵은 API로 의뢰
    Bridge->>Ocx: in-proc 호출
    Ocx-->>Bridge: 결과 / 이벤트
    Bridge-->>App: 변환된 결과

여기서의 포인트는 세세한 메서드를 전부 그대로 중계하지 않는 것입니다. 프로세스 간 경계는 세세한 호출을 대량으로 흘리면 금방 힘들어집니다.

• 1 조작 = 1 요청 정도의 입자로 모은다
• 반환값이나 에러를 의미 있는 단위로 정형한다
• 로그를 경계에서 취한다

이 형태로 해 두면 나중에 내용물을 정말로 교체할 때도 편합니다.

5.3. IE / WebBrowser 전제의 화면

추천은 교체 우선입니다.

여기는 「지금 동작한다」와 「앞으로도 편하게 유지할 수 있다」가 일치하기 어려운 영역입니다. IE 모드는 호환을 위해 꽤 도움이 되지만, 그래도 전제는 IE 계열 그대로입니다.

그래서 사고 방식으로는 다음이 알기 쉽습니다.

• 사내 업무를 멈추지 않기 위해 IE 모드로 연명한다
• 다만, 연명과 항구 설계를 혼동하지 않는다
• 교체 대상은 WebView2, 순 Web, 네이티브 UI + Web의 하이브리드 등에서 고른다

특히 WebBrowser 컨트롤을 단순히 HTML 뷰어로서 사용하고 있을 뿐이라면, 교체 우선도는 높습니다.

한편으로, 브라우저 내의 ActiveX가 로컬 파일, 장치, 서명, 독자 애드온과 같은 역할까지 가지고 있다면, 그건 렌더링 엔진의 교환이 아니라 네이티브 연계의 재설계입니다. 여기는 이야기가 조금 무거워집니다.

5.4. 기기 제어나 독자 사양을 안은 ActiveX

추천은 먼저 감싼다입니다.

이 타입은 겉모습보다 내용물이 진합니다. SDK의 자료가 얇아도, 현장에서 오랜 세월 동작해 온 결과로서 다음과 같은 거동이 암묵적으로 쌓여 있는 경우가 있습니다.

• 접속 실패 시의 대기 방식
• 타임아웃 후의 재시도
• 이벤트 순서
• 실기의 버릇을 흡수하는 회피 처리
• 예외나 에러 코드의 해석

이 종류의 부품을 「어차피 오래됐으니까」로 다시 만들면, 상당한 확률로 현장 시험이 탑니다.

그래서 먼저 다음을 하는 것이 안전합니다.

1. 기존 부품을 경계의 안쪽에 가둔다
2. 로그를 추가해 무엇이 일어나고 있는지 보이도록 한다
3. 테스트 시나리오와 실기 패턴을 모은다
4. 그 후, 교체 가능한 범위를 잘라낸다

화려함은 없지만, 실무에서는 이것이 가장 효과적입니다.

6. 자주 있는 안티패턴

이 중에서 특히 실무에서 자주 보는 것은 다음 3개입니다.

1. 전면 리라이트를 서두른다
2. bitness의 벽을 가볍게 본다
3. API를 앱 전체에 퍼뜨린다

이 3개를 피하는 것만으로도 상당히 사고율은 내려갑니다.

7. 이행을 시작할 때의 체크리스트

ActiveX / OCX의 안건은 갑자기 구현에 들어가기보다 먼저 재고 조사를 하는 편이 잘 됩니다. 순서로서는 대개 다음입니다.

1. 사용하고 있는 OCX / DLL을 씻어낸다
   • 파일명, 버전, ProgID, CLSID, 벤더, 라이선스의 유무
2. 어디서 사용하고 있는지를 씻어낸다
   • 화면, 기능, 장표, 장치, 배치, Office 연계 등
3. bitness와 호스트 조건을 확인한다
   • 32bit / 64bit, in-proc / out-of-proc, STA 전제, 브라우저 의존
4. 배포 조건을 확인한다
   • 등록 방법, 의존 DLL, 관리자 권한, 사일런트 인스톨, 클린 환경 재현
5. 스모크 테스트를 만든다
   • 정상계뿐만 아니라 실패 시, 미접속 시, 타임아웃 시도 포함
6. 경계를 만든다
   • adapter, service, facade, 별도 프로세스 다리 등
7. 1 화면, 1 기능, 1 장치 등, 작은 단위로 시험한다
8. 잘된 경계부터 순서대로 남긴다 / 감싼다 / 교체한다를 넓힌다

이 순서를 건너뛰면, 나중에 「무엇이 어려웠는지」조차 설명하기 어려워집니다.

8. 대강의 사용 구분

망설여지면 먼저 UI 부품인지, 사양을 안은 경계면인지를 구별하면 상당히 빗나가기 어려워집니다.

9. 이런 상담은 상성이 좋다

이 주제는 갑자기 개발에 들어가기 전의 방침 정리만으로도 가치가 나오기 쉽습니다.

예를 들어 다음과 같은 상담은 상당히 상성이 좋습니다.

• 어느 OCX를 정말로 교체해야 할지 재고 조사하고 싶다
• 32bit / 64bit의 막힘 포인트만 먼저 정리하고 싶다
• .NET으로 옮기고 싶지만 COM의 입구만은 남기고 싶다
• 벤더 종료된 ActiveX의 연명책과 철수전을 비교하고 싶다
• IE / WebBrowser 의존을 어디서부터 뗄 수 있을지 보고 싶다
• 우선 1 화면, 1 기능만 안전하게 분리하고 싶다

ActiveX / OCX의 안건은 구현보다 먼저 경계를 어떻게 자를지가 승부가 되는 경우가 많습니다. 전면 개수의 전단계로서, 현상 정리, 구성 비교, 이행 순서의 설계부터 들어가는 것만으로도 꽤 의미가 있습니다.

10. 정리

ActiveX / OCX를 어떻게 다룰지는 레거시라서 싫어한다, 로 결정하는 이야기가 아닙니다.

먼저 봐야 할 것은 다음 4가지입니다.

1. 그 부품은 단순한 UI인가, 아니면 사양을 안은 경계면인가
2. 동일 프로세스에서 사용할 필요가 있는가
3. 32bit / 64bit, 등록, 브라우저 의존, 라이선스로 막히지 않는가
4. 교체 전에 거동을 관측할 수 있는가

이 4가지가 보이면 대체로 다음과 같이 정리할 수 있습니다.

• 안정 가동하고 있고 수명도 읽힌다면 남긴다
• 주변만 근대화하고 싶다면 감싼다
• UI 부품이나 브라우저 의존이라면 교체한다
• 사양의 덩어리를 안은 부품은 먼저 감싸고 나서 단계 교체한다

레거시 기술은 웃음 대상이 아니라 역사와 계약이 쌓인 현물입니다. 다만, 현물을 상대하기 위한 경계 설계는 필요합니다.

「남긴다・감싼다・교체한다」를 섞어서 생각할 수 있게 되면, ActiveX / OCX의 안건은 갑자기 다룰 수 있는 문제로 변해 갑니다.

11. 참고 자료

• Microsoft Learn: AxHost Class (System.Windows.Forms)
  • https://learn.microsoft.com/en-us/dotnet/api/system.windows.forms.axhost
• Microsoft Learn: Aximp.exe (Windows Forms ActiveX Control Importer)
  • https://learn.microsoft.com/en-us/dotnet/framework/tools/aximp-exe-windows-forms-activex-control-importer
• Microsoft Learn: How to: Add ActiveX Controls to Windows Forms
  • https://learn.microsoft.com/en-us/dotnet/desktop/winforms/controls/how-to-add-activex-controls-to-windows-forms
• Microsoft Learn: Expose .NET Core components to COM
  • https://learn.microsoft.com/en-us/dotnet/core/native-interop/expose-components-to-com
• Microsoft Learn: Registration-Free COM Interop
  • https://learn.microsoft.com/en-us/dotnet/framework/interop/registration-free-com-interop
• Microsoft Learn: Microsoft Edge에 관한 자주 묻는 질문
  • https://learn.microsoft.com/en-us/deployedge/microsoft-edge-frequently-asked-questions
• Microsoft Learn: What is Internet Explorer (IE) mode?
  • https://learn.microsoft.com/en-us/deployedge/edge-ie-mode
• Microsoft Learn: WebBrowser Class (System.Windows.Forms)
  • https://learn.microsoft.com/en-us/dotnet/api/system.windows.forms.webbrowser
• Microsoft Learn: Introduction to Microsoft Edge WebView2
  • https://learn.microsoft.com/en-us/microsoft-edge/webview2/
• 합동회사 고무라소프트 Blog: COM의 STA/MTA에서 행을 피하기 위한 기초 지식
  • https://comcomponent.com/blog/2026/01/31/000-sta-mta-com-relationship/
• 합동회사 고무라소프트 Blog: C++의 네이티브 DLL을 C#에서 사용할 때 C++/CLI로 래퍼를 만드는 편이 좋은 이유
  • https://comcomponent.com/blog/2026/03/07/000-cpp-cli-wrapper-for-native-dlls/
• 합동회사 고무라소프트 Blog: COM이 도움이 되는 케이스 스터디 - 32bit 앱에서 64bit DLL을 호출하고 싶을 때
  • https://comcomponent.com/blog/2026/01/25/002-com-case-study-32bit-to-64bit/

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.