COM / ActiveX / OCX란 무엇인가 - 차이와 관계를 정리해 해설

COM / ActiveX / OCX라는 세 단어는 Windows의 레거시 프로젝트에서 대체로 세트로 나옵니다.

• 벤더로부터 .ocx가 전송되어 온다
• Access나 VB6 화면에 정체 모를 부품이 올라가 있다
• 「이것은 COM입니다」라는 말을 듣자마자 「ActiveX네요」라는 말을 듣는다
• 그다음 regsvr32, 32bit / 64bit, IE 모드 같은 단어가 한꺼번에 달려온다

이 흐름이 되면 대화는 대체로 엇갈립니다. 용어가 가까운 데다가, 역사적으로도 겹침이 크기 때문입니다. 반대로 말하면, 여기를 나누어 이해할 수 있으면 조사, 이전, 설명의 수월함이 꽤 달라집니다.

flowchart TB
    accTitle: 대화가 엇갈리는 구도
    accDescr: COM·ActiveX·OCX처럼 가까운 용어가 같은 현장에서 한꺼번에 나오면 대화가 엇갈리지만, 어느 것이 토대이고 어느 것이 부품이고 어느 것이 파일인지를 나누어 이해하면 조사도 이전도 설명도 쉬워진다.
    mix["세 단어가 한꺼번에 나온다"] --> lost["대화가 엇갈린다"]
    split["토대·부품·파일로 나눈다"] --> clear["조사와 이전과 설명이 편해진다"]

그림 1: 이 글의 목적은 하나. 「어느 것이 토대이고, 어느 것이 부품이고, 어느 것이 파일인가」를 나누는 것.

이 글에서는 COM이란 무엇인가, ActiveX란 무엇인가, OCX란 무엇인가를 차이와 관계가 보이는 순서로 정리합니다. 특히 어느 것이 토대이고, 어느 것이 부품이고, 어느 것이 파일인가를 분명히 합니다.

목차

1. 먼저 결론(한 마디로)
2. 이 글에서 말하는 COM / ActiveX / OCX
3. 먼저 한 장으로 정리
   • 3.1. 관계도
   • 3.2. 용어의 최단 정리
4. COM이란 무엇인가
   • 4.1. 한 마디로 말하면
   • 4.2. COM에서 중요한 것
   • 4.3. 용어 한 줄 메모
5. ActiveX란 무엇인가
   • 5.1. 한 마디로 말하면
   • 5.2. ActiveX는 브라우저 전용이 아니다
6. OCX란 무엇인가
   • 6.1. 한 마디로 말하면
   • 6.2. .dll과 어떻게 다른가
7. 차이를 표로 정리
8. 어디서 쓰였는가
9. 왜 혼동하기 쉬운가
10. 지금의 실무에서 어떻게 봐야 하는가
11. 흔한 오해
12. 조사할 때의 체크포인트
13. 정리
14. 참고 자료

이 글의 지식 맵

COM은 Windows에서 컴포넌트끼리 바이너리 계약으로 주고받기 위한 토대이며, ActiveX는 COM과 OLE/Automation을 기반으로 한, 호스트나 컨테이너에 매립해 쓰는 재사용 가능한 부품의 문맥입니다. OCX는 그 ActiveX 컨트롤의 구현으로 흔히 쓰이는 파일 확장자일 뿐, 개념 그 자체는 아닙니다. VB6나 MFC, WinForms에서의 COM 래퍼 이용 등, ActiveX는 브라우저 전용이 아니라 Windows 앱 쪽에서도 오래 쓰여 왔습니다. CLSID와 ProgID, Type Library, STA/MTA의 Apartment 모델이 COM의 식별과 호출을 뒷받침하며, regsvr32에 의한 관리자 권한 등록과 32bit/64bit의 비트 일치가 OCX의 배치를 좌우합니다. 브라우저 쪽 ActiveX는 하위 호환의 다리인 IE 모드를 전제로 계속 동작하고 있습니다.

flowchart LR
    accTitle: COM·ActiveX·OCX
    accDescr: COM을 토대로 OLE/Automation과 ActiveX가 쌓여 OCX라는 구현 파일에 이르는 관계, CLSID·ProgID·Type Library·Apartment 모델이라는 COM의 식별과 호출 구조, regsvr32에 의한 관리자 권한 등록과 비트 일치 제약, 브라우저 쪽 ActiveX가 IE 모드에 의존하는 구도를 보여주는 그림입니다.
    com["COM(컴포넌트 오브젝트 모델)"]
    activex["ActiveX"]
    ocx["OCX"]
    ole_automation["OLE/Automation"]
    clsid["CLSID(Class ID)"]
    progid["ProgID(Programmatic Identifier)"]
    vb6["Visual Basic 6.0(VB6)"]
    type_library["타입 라이브러리(TLB)"]
    dotnet[".NET(Core 이후)"]
    com_apartment_model["COM 아파트먼트 모델(STA/MTA)"]
    regsvr32["regsvr32"]
    admin_rights["관리자 권한"]
    bitness_match_requirement["비트수 일치 요건"]
    ie_mode["IE 모드"]
    mfc["MFC(Microsoft Foundation Classes)"]
    windows_forms["Windows Forms"]
    dumpbin["dumpbin"]
    activex -->|"이용한다"| com
    ocx -->|"구현을 담당한다"| activex
    ole_automation -->|"이용한다"| com
    activex -->|"이용한다"| ole_automation
    com -->|"이용한다"| clsid
    progid -->|"이용한다"| clsid
    vb6 -.->|"이용한다"| type_library
    dotnet -.->|"이용한다"| type_library
    com -->|"이용한다"| com_apartment_model
    regsvr32 -->|"자동화한다"| com
    regsvr32 -.->|"전제로 한다"| admin_rights
    ocx -->|"에서 구성할 수 있다"| regsvr32
    ocx -->|"전제로 한다"| bitness_match_requirement
    activex -.->|"전제로 한다"| ie_mode
    vb6 -->|"이용한다"| activex
    mfc -.->|"이용한다"| activex
    windows_forms -.->|"이용한다"| activex
    ocx -->|"에서 확인할 수 있다"| dumpbin

그림의 실선은 항상 성립하는 관계, 점선은 조건이 붙는 관계입니다(성립 조건은 상세 페이지의 관계별 설명에 적혀 있습니다). 관계 전체 목록(총 18건, 근거와 확신도 포함)과 주요 개념의 정의는 지식 맵 상세 페이지에 정리되어 있습니다(일본어). 데이터: JSON-LD / Turtle

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

먼저 거칠지만 도움이 되는 표현으로 말하면 이렇습니다.

• COM은 토대입니다. Windows에서 컴포넌트끼리 주고받기 위한 바이너리 계약입니다
• ActiveX는 COM 기반의 부품 문맥입니다. 특히 호스트에 삽입해 쓰는 컨트롤로 나오기 쉽습니다
• OCX는 ActiveX 컨트롤에서 자주 보는 구현 파일입니다. 파일 확장자로 마주칩니다
• 즉 COM = 구조, ActiveX = 부품의 문맥, OCX = 파일 정도로 잡으면 전망이 좋아집니다
• ActiveX = 옛날 브라우저의 위험한 것이라는 기억은 반은 맞고 반은 부족합니다. ActiveX는 브라우저 전용이 아닙니다
• OCX = ActiveX와 거의 동의어로 이야기되는 경우는 많지만, 엄밀히는 개념과 파일 확장자를 섞고 있습니다
• 지금 신규 개발에서 주역으로 세울 기술은 아니지만, 기존의 Windows 앱, Office, Access, 기기 SDK, 사내 Web에서는 아직 마주칩니다

우선 이 셋을 나누어 생각하는 데서 시작합니다.

1. 그것은 COM의 이야기인가
2. 그것은 ActiveX 컨트롤의 이야기인가
3. 그것은 단지 .ocx 파일을 보고 그렇게 부르고 있을 뿐인가

여기가 나뉘면 안개가 꽤 걷힙니다.

flowchart TB
    accTitle: 처음에 나누는 세 가지 질문
    accDescr: 눈앞의 이야기가 COM이라는 구조의 이야기인지, ActiveX 컨트롤이라는 부품의 이야기인지, 단지 ocx 파일을 보고 그렇게 부르고 있을 뿐인지를 나누는 데서 시작한다.
    q{"지금 무슨 이야기를 하고 있는가"}
    q --> a["COM = 구조의 이야기"]
    q --> b["ActiveX = 부품 문맥의 이야기"]
    q --> c["OCX = 파일의 이야기"]

그림 2: 막히면 이 세 갈래로 돌아간다. COM은 구조, ActiveX는 부품의 문맥, OCX는 파일.

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

이 셋은 실무에서 종종 거칠게 한자리에 있습니다. 그래서 이 글에서는 먼저 의미를 고정합니다.

• COM: Windows의 컴포넌트 모델 그 자체. 인터페이스, GUID, 등록, 호출의 토대
• ActiveX: COM을 기반으로 한, 삽입 가능한 컨트롤이나 그 이용 문맥. 실무에서는 특히 ActiveX 컨트롤을 가리키는 경우가 많다
• OCX: ActiveX 컨트롤 구현에서 자주 보는 파일 확장자. .ocx

조금만 보충하면, 역사적으로는 ActiveX라는 말이 조금 더 넓게 쓰인 시기가 있습니다. 다만 지금 실무에서 ActiveX라고 했을 때 곤란한 장소의 대부분은 대체로 컨트롤, 삽입, 호스트, 브라우저, 등록 근처입니다.

그래서 이 글에서도 기본은 ActiveX = ActiveX 컨트롤 쪽의 이야기로 진행합니다.

flowchart TB
    accTitle: ActiveX라는 말의 폭과 이 글의 초점
    accDescr: 역사적으로는 ActiveX라는 말이 조금 더 넓게 쓰인 시기가 있지만, 지금 실무에서 곤란한 것은 컨트롤·삽입·호스트·브라우저·등록 근처이므로, 이 글은 ActiveX 컨트롤 쪽 이야기에 초점을 둔다.
    word["ActiveX라는 말"] --> wide["역사적으로는 더 넓은 의미도"]
    word --> now["지금 곤란한 것은 컨트롤 주변"]
    now --> focus["이 글은 컨트롤 쪽으로 진행한다"]
    now -.-> items["삽입·호스트·브라우저·등록"]

그림 3: 말의 역사적 폭은 인정하되, 실무에서 곤란한 「컨트롤 쪽」에 초점을 고정한다.

3. 먼저 한 장으로 정리

3.1. 관계도

우선 전체 그림을 한 장으로 보는 것이 빠릅니다. 그림이 표시되지 않는 환경이라면, 바로 아래 글머리 기호가 같은 내용이므로 그쪽을 읽어 주세요.

flowchart LR
    COM["COM<br/>바이너리 계약의 토대"] --> OLE["OLE / Automation<br/>삽입·자동화의 구조"]
    OLE --> AX["ActiveX<br/>COM 기반의 컨트롤 문맥"]
    AX --> CTRL["ActiveX 컨트롤"]
    CTRL --> OCX["OCX (.ocx)<br/>구현 파일에서 자주 보는 형태"]

    HOST["호스트 / 컨테이너<br/>IE / Access / VB6 / MFC / WinForms"] --> CTRL

그림 4: COM을 토대로 OLE / Automation, ActiveX, OCX가 쌓이고, 호스트가 컨트롤을 올리는 관계도.

여기서 중요한 것은 COM과 ActiveX는 같은 말이 아니다는 점입니다.

• COM은 토대입니다
• OLE / Automation은 삽입이나 자동화를 위한 구조입니다
• ActiveX는 그 위에서 쓰이는 컨트롤 문맥으로 나옵니다
• OCX는 그 컨트롤 구현에서 자주 보는 파일입니다

그래서 ActiveX는 COM인가요라고 물으면, 답은 토대는 COM이지만, ActiveX는 COM 그 자체가 아니다가 됩니다.

3.2. 용어의 최단 정리

최단으로 외운다면 이것으로 충분합니다.

• COM은 구조
• ActiveX는 부품의 문맥
• OCX는 파일

4. COM이란 무엇인가

4.1. 한 마디로 말하면

COM은 Component Object Model의 약자로, Windows에서 컴포넌트끼리 주고받기 위한 바이너리 계약입니다.

여기서 말하는 바이너리 계약이란 소스 코드의 사정이나 언어 사양이 아니라, 컴파일 이후의 형태에서도 약속이 유지되는 인터페이스를 뜻합니다. C++로 만든 부품을 다른 언어나 다른 애플리케이션에서 쓸 수 있는 것은 이 계약이 있기 때문입니다.

실무 감각에 맞추면, COM은 편리한 라이브러리의 배포 방식이라기보다 구현을 숨기고 계약만으로 잇는 구조입니다.

예를 들어 이 근처가 COM의 전형입니다(각 단어의 의미는 4.3에 한 줄씩 정리해 두었습니다).

• IUnknown에 의한 참조 카운트
• QueryInterface에 의한 인터페이스 탐색
• IID나 CLSID 같은 GUID 기반 식별
• DLL에 의한 인프로세스 이용
• EXE에 의한 아웃프로세스 이용

요컨대 COM은 Windows 부품화 문화의 토대입니다.

flowchart TB
    accTitle: 바이너리 계약이라는 생각
    accDescr: COM은 소스 코드나 언어 사양의 사정이 아니라, 컴파일 이후의 형태에서도 유지되는 약속인 바이너리 계약으로 부품을 잇기 때문에, C++로 만든 부품을 다른 언어나 다른 앱에서 이용할 수 있다.
    part["부품〔구현은 숨긴다〕"] --> contract["바이너리 계약〔공개하는 약속〕"]
    contract --> user["다른 언어·다른 앱"]
    contract -.-> note["컴파일 이후에도 약속이 유지된다"]

그림 5: COM의 핵은 「구현을 숨기고 계약만으로 잇는」 것. 그래서 언어를 건너뛰어 부품을 쓸 수 있다.

4.2. COM에서 중요한 것

기본만 잡자면, COM에서는 다음이 중요합니다.

• 인터페이스 중심
  • 구현보다 먼저, 무엇을 공개할지를 정합니다
• GUID에 의한 식별
  • 클래스나 인터페이스를 유일하게 식별합니다
• 호스트와 구현의 분리
  • 호출하는 쪽은 내부 구현을 알 필요가 없습니다
• 프로세스를 넘을 수 있다
  • 같은 프로세스뿐 아니라, 다른 프로세스의 부품으로도 쓸 수 있습니다

이 근처가 COM을 그저 오래된 기술로 끝내지 않는 이유입니다. 꽤 이른 시기부터 계약 기반으로 재사용하는 설계를 단단히 갖고 있었습니다.

flowchart TB
    accTitle: COM에서 중요한 네 기둥
    accDescr: 인터페이스 중심 설계, GUID에 의한 유일한 식별, 호스트와 구현의 분리, 프로세스를 넘을 수 있다는 넷이 COM을 계약 기반의 재사용 설계로 만든다.
    com["COM의 기본"] --> p1["인터페이스 중심"]
    com --> p2["GUID에 의한 식별"]
    com --> p3["호스트와 구현의 분리"]
    com --> p4["프로세스를 넘을 수 있다"]

그림 6: COM을 받치는 네 기둥. 이른 시기부터 계약 기반의 재사용 설계를 갖고 있었다.

4.3. 용어 한 줄 메모

COM 이야기에서는 설명 없이 다음 단어가 날아옵니다. 여기서는 개념의 입구로, 우선 한 줄씩만 잡아 둡니다. 설계로서의 재미까지 들어가고 싶은 분은 COM이란 무엇인가 - Windows COM의 설계가 지금도 아름다운 이유를 참고하세요.

이 글은 개념 정리까지이므로, 각 항목의 세부까지는 들어가지 않습니다. 구현 이야기가 필요해지면 이 표의 단어를 그대로 검색어로 쓰면 감을 잡기 쉽습니다.

flowchart TB
    accTitle: IUnknown을 토대로 한 기본 동작
    accDescr: 모든 COM 인터페이스의 토대인 IUnknown은 QueryInterface로 다른 인터페이스를 묻고, AddRef와 Release로 참조 카운트를 증감시키며, 0이 된 시점에 부품이 해제된다는 기본 동작을 갖는다.
    iu["IUnknown〔모든 토대〕"] --> qi["QueryInterface로 묻는다"]
    qi --> got["갖고 있으면 포인터가 돌아온다"]
    iu --> rc["AddRef와 Release로 수를 관리"]
    rc --> zero["0이 되면 부품을 해제"]

그림 7: 용어표의 중심에 있는 IUnknown의 세 메서드는 「묻기」와 「세기」 두 일로 나뉜다.

5. ActiveX란 무엇인가

5.1. 한 마디로 말하면

ActiveX는 COM을 기반으로 한 재사용 가능한 소프트웨어 부품, 특히 호스트나 컨테이너에 삽입해 쓰는 컨트롤로 이해하는 것이 알기 쉽습니다.

실무에서 ActiveX라고 하면 꽤 높은 확률로 ActiveX 컨트롤 이야기입니다. 예를 들어 버튼, 그리드, 그래프, 캘린더, 뷰어, 기기 연계 부품 같은 것이 해당합니다.

ActiveX는 혼자서 거창하게 서 있는 거대한 기술이라기보다, 어떤 호스트 안에 삽입되어 일하는 부품으로 보면 빗나가기 어렵습니다.

flowchart TB
    accTitle: 호스트에 삽입되어 일하는 부품
    accDescr: 실무에서 ActiveX라고 하면 꽤 높은 확률로 ActiveX 컨트롤 이야기이며, 버튼·그리드·그래프·뷰어·기기 연계 부품처럼 호스트나 컨테이너에 삽입되어 일하는 부품을 가리킨다.
    host["호스트 / 컨테이너"] --> ctrl["ActiveX 컨트롤"]
    ctrl --> ex1["그리드나 캘린더"]
    ctrl --> ex2["뷰어나 기기 연계 부품"]
    ctrl -.-> note["혼자서 서는 거대한 기술이 아니다"]

그림 8: ActiveX는 「삽입되어 일하는 부품」으로 보면 빗나가기 어렵다.

5.2. ActiveX는 브라우저 전용이 아니다

ActiveX = Internet Explorer의 그거라는 인상은 꽤 강합니다. 이것은 틀린 말은 아니지만, 그것만이 아닙니다.

ActiveX 컨트롤이 쓰여 온 장소를 들어 봅니다.

• Access 폼
• VB6(Visual Basic 6.0) 애플리케이션
• MFC(Microsoft Foundation Class 라이브러리)의 컨테이너
• Office / VBA 주변
• WinForms에서의 COM 래퍼 이용
• Internet Explorer나 그 호환 운용 문맥

즉 ActiveX는 브라우저 전용 기술이 아니라, Windows 앱 쪽에서도 오래 쓰여 온 부품 기술입니다.

여기가 안 보이면, 사내 Web에서 발견한 ActiveX와 Access 화면에 묻혀 있는 ActiveX를 다른 것으로 보게 됩니다. 실제로는 둘 다 꽤 COM 쪽 친척입니다.

flowchart TB
    accTitle: ActiveX 컨트롤이 쓰여 온 장소
    accDescr: Access 폼이나 VB6 앱, MFC 컨테이너, Office나 VBA 주변, WinForms에서의 COM 래퍼 이용, Internet Explorer와, ActiveX는 브라우저 전용이 아니라 Windows 앱 쪽에서도 오래 쓰여 왔다.
    ax["ActiveX 컨트롤"] --> d["Access나 VB6나 MFC"]
    ax --> o["Office나 VBA 주변"]
    ax --> w["WinForms의 COM 래퍼"]
    ax --> ie["Internet Explorer 계열"]
    ie -.-> myth["유명한 것은 여기뿐"]

그림 9: IE에서 눈에 띈 것뿐이고, 쓰여 온 장소의 대부분은 Windows 앱 쪽에 있다.

6. OCX란 무엇인가

6.1. 한 마디로 말하면

OCX는 ActiveX 컨트롤 구현에서 자주 쓰이는 파일 확장자입니다. Windows 현장에서 .ocx를 발견하면, 우선 삽입 컨트롤 계열의 COM 부품을 의심해도 됩니다.

나오는 장면은 대체로 이 근처입니다.

• 벤더 SDK의 배포물
• VB6 / Access / MFC의 오래된 프로젝트
• 설치 프로그램에 포함된 등록 대상 파일
• regsvr32가 필요한 부품

잡아 두고 싶은 것은 OCX는 파일의 형태이지, 개념 그 자체가 아니다는 점입니다. 그래서 OCX란 무엇인가를 거칠게 말하면, ActiveX 컨트롤의 실체로 자주 마주치는 파일입니다.

6.2. .dll과 어떻게 다른가

여기도 헷갈리기 쉬운 지점입니다.

• .ocx는 ActiveX 컨트롤임을 꽤 강하게 암시합니다
• .dll은 평범한 라이브러리일 수도, COM 서버일 수도, ActiveX 주변의 의존 DLL일 수도 있습니다

.ocx를 보면 거의 ActiveX 쪽 이야기라고 감을 잡을 수 있지만, .dll만 봐서는 아직 무엇인지 알 수 없습니다.

실무에서 흔한 것은

• vendorcontrol.ocx
• vendorhelper.dll
• vendorcore.dll

처럼 나란히 있고, 주역은 OCX, 옆을 DLL이 받치는 패턴입니다.

그래서 OCX = DLL의 일종인가라고 물으면, 감각적으로는 가깝지만, 조사하는 자리에서는 역할을 나누어 보는 것이 안전합니다.

flowchart TB
    accTitle: 확장자에서 읽을 수 있는 정보의 차이
    accDescr: ocx는 ActiveX 컨트롤임을 강하게 암시하지만, dll은 평범한 라이브러리인지 COM 서버인지 의존 DLL인지 아직 모른다. 실무에서는 주역 OCX를 옆의 DLL이 받치는 패턴이 흔하다.
    q{"확장자는 무엇인가"}
    q -->|".ocx"| ax["거의 ActiveX 쪽으로 감을 잡는다"]
    q -->|".dll"| unk["아직 무엇인지 모른다"]
    unk --> roles["라이브러리인지 COM 서버인지 의존인지"]
    ax -.-> pair["주역 OCX를 옆의 DLL이 받치는 형태"]

그림 10: .ocx는 감을 잡을 수 있지만, .dll은 역할을 조사하기 전까지 무엇인지 모른다.

7. 차이를 표로 정리

이 표로 외운다면 우선 이렇습니다.

• COM은 기초 공사
• ActiveX는 그 위에 올라가는 부품 문화
• OCX는 현장에서 집어 올리는 파일

8. 어디서 쓰였는가

ActiveX / OCX는 브라우저 기억이 너무 강해 옛날 Web 기술로 보이기 쉽습니다. 다만 실제로는 더 넓게 쓰였습니다.

구체적으로는 이런 장소입니다.

• 데스크톱 앱
  • VB6
  • MFC / C++
  • Access 폼
  • Office / VBA 주변
• 브라우저 / 사내 Web
  • Internet Explorer에 삽입하는 뷰어
  • 서명 부품
  • 파일 전송 부품
  • 주변 기기 연계 부품
• 기존 .NET 앱
  • WinForms에서 래핑해 쓰는 기존 ActiveX 컨트롤
  • 기존 COM 자산을 UI 부품으로 연명하고 있는 경우

여기에서도 결국 ActiveX는 인터넷 전용이 아니다는 이야기로 돌아옵니다. IE에서 화려하게 눈에 띄어 Web 기술처럼 보일 뿐이고, 실태로는 Windows의 삽입 부품 기술로 보는 편이 실무에서는 맞습니다.

flowchart TB
    accTitle: 보이는 모습과 실태의 어긋남
    accDescr: IE에서 화려하게 눈에 띈 탓에 ActiveX는 옛날 Web 기술로 보이기 쉽지만, 실제로는 데스크톱 앱, 사내 Web, 기존 .NET 앱에서 넓게 쓰였으며, 실태는 Windows의 삽입 부품 기술이다.
    look["IE에서 눈에 띈 기억"] --> web["옛날 Web 기술로 보인다"]
    real["실제 사용 장소"] --> r1["데스크톱 앱"]
    real --> r2["브라우저와 사내 Web"]
    real --> r3["기존 .NET 앱"]
    r1 -.-> truth["실태는 Windows의 삽입 부품 기술"]

그림 11: 「옛날 Web 기술」이라는 보이는 모습과 「Windows의 삽입 부품 기술」이라는 실태의 어긋남.

9. 왜 혼동하기 쉬운가

9.1. 말의 계층이 다른데 같은 대화에 나온다

• COM은 토대의 이야기입니다
• ActiveX는 부품의 문맥의 이야기입니다
• OCX는 파일의 이야기입니다

애초에 계층이 다른데, 실무에서는 같은 현장에서 동시에 나오므로 대화가 뒤섞이기 쉬운 것입니다.

9.2. ActiveX라는 말이 조금 넓다

COM은 비교적 의미가 고정되어 있습니다. 한편 ActiveX는 역사적으로도 실무적으로도 조금 넓게 쓰입니다.

사람에 따라

• 컨트롤 그 자체
• .ocx 파일
• IE에서 동작하는 오래된 부품
• COM 기반의 삽입 부품 전반

중 무엇을 가리키는지가 어긋납니다. 이 시점에서 이미 대화는 맞지 않습니다.

9.3. .ocx를 본 순간에 전부 ActiveX라고 부르고 싶어진다

이 마음은 이해합니다. 평소에는 그것으로 대체로 통합니다.

다만 이전이나 조사 장면에서는

• 그것은 UI 부품인가
• 어느 호스트에서 동작하는가
• 등록이 필요한가
• 32bit / 64bit는 어떻게 되어 있는가
• 브라우저 의존이 있는가

를 나누어 보지 않으면, 나중에 제대로 넘어집니다.

flowchart TB
    accTitle: 혼동이 일어나는 세 가지 이유
    accDescr: 계층이 다른 이야기가 같은 대화에 나온다는 것, ActiveX라는 말이 조금 넓다는 것, ocx를 본 순간에 전부 ActiveX라고 부르고 싶어진다는 셋이 혼동의 원인이다.
    r1["계층이 다른 이야기가 같은 대화에 나온다"] --> mixup["대화가 뒤섞인다"]
    r2["ActiveX라는 말이 넓다"] --> mixup
    r3["ocx를 보고 전부 그렇게 부른다"] --> mixup
    mixup -.-> risk["이전이나 조사 자리에서는 넘어진다"]

그림 12: 혼동의 정체는 토대·부품·파일이라는 계층 차이가 같은 현장에 동시에 나타나는 것.

10. 지금의 실무에서 어떻게 봐야 하는가

먼저, COM / ActiveX / OCX를 발견했다고 해서 바로 전면 부정할 필요는 없습니다. 다만 전부를 같은 온도로 다루는 것도 위험합니다.

브라우저 쪽 ActiveX 의존

이것은 우선적으로 더 엄하게 보는 편이 안전합니다.

• 현대 브라우저 개발의 주류가 아닙니다
• 호환 운용 문맥에서는 IE 모드가 화제가 되지만, 이것은 하위 호환을 위한 다리로 보는 편이 낫습니다
• 신규의 전제 기술로 삼기는 추천하기 어렵습니다

판단에는 시간축도 필요합니다. IE11 데스크톱 앱은 이미 퇴역했고, 지금 남은 발판은 Microsoft Edge의 IE 모드입니다. 그 IE 모드에 대해 Microsoft는 적어도 2029년까지는 지원하고, 폐지하는 경우에는 1년 전에 알린다는 방침을 내고 있습니다. 즉 2029년은 「거기까지 방치해도 되는 기한」이 아니라, 거기까지 떼어 내기를 마치는 기한으로 역산하는 대상입니다. 떼어 내는 절차 자체는 IE 모드 의존 시스템의 탈피 가이드에 나누어 적어 두었습니다.

Web 쪽 ActiveX는 「어떻게 연명할지」보다 「어디서부터 떼어낼지」로 생각하는 편이 현실적입니다.

flowchart TB
    accTitle: 브라우저 쪽 ActiveX의 시간축
    accDescr: IE11 데스크톱 앱은 퇴역했고, 남은 발판은 Edge의 IE 모드이며, Microsoft는 적어도 2029년까지 지원하고 폐지 시에는 1년 전에 알린다는 방침을 내고 있다. 2029년은 방치해도 되는 기한이 아니라, 떼어 내기를 마치는 기한으로 역산한다.
    ie11["IE11 데스크톱은 퇴역 완료"] --> iem["남은 발판은 Edge의 IE 모드"]
    iem --> y2029["적어도 2029년까지 지원"]
    y2029 --> plan["떼어 내기를 마치는 기한으로 역산"]
    y2029 -.-> notice["폐지 시에는 1년 전 고지의 방침"]

그림 13: 2029년은 여유가 아니라 마감. 브라우저 쪽은 「어디서부터 떼어낼지」로 생각한다.

데스크톱 쪽 ActiveX / OCX 의존

이쪽은 조금 더 현실적으로 판단할 수 있습니다.

• 기존 호스트 안에서 안정적으로 가동하고 있다
• 배포처가 한정되어 있다
• 벤더 유지보수인지 자체 유지보수인지 전망이 있다
• 등록, 의존 DLL, bitness의 전제를 파악하고 있다

이 조건이 갖춰지면 남긴다는 판단은 흔히 있습니다.

한편

• 32bit OCX를 64bit 쪽으로 그대로 읽고 싶다
• 주변만 .NET화하고 싶다
• 배포와 등록에서 매번 넘어진다
• 브라우저 의존이 남아 있다

라면, 남긴다 / 감싼다 / 교체한다를 나누어 생각하는 것이 안전합니다.

지금 실무에서 묻는 것은 ActiveX라서 나쁘다가 아니라, 어디에 경계를 만들지입니다. 오래된 기술이라기보다 기존 시스템의 접합면으로 보면 다루기 쉬워집니다.

flowchart TB
    accTitle: 데스크톱 쪽 판단이 갈리는 방식
    accDescr: 안정 가동·한정 배포·유지보수 전망·전제 파악이 갖춰지면 남긴다는 판단은 흔히 있고, bitness 충돌이나 주변의 .NET화나 배포 사고나 브라우저 의존이 있으면 남긴다·감싼다·교체한다를 나누어 생각한다.
    q{"조건은 갖춰져 있는가"}
    q -->|"안정 가동과 전제 파악이 갖춰진다"| keep["남긴다는 판단도 흔히 있다"]
    q -->|"막히는 지점이 있다"| split["남긴다·감싼다·교체한다를 나눈다"]
    split -.-> view["접합면으로서 어디에 경계를 만들지"]

그림 14: 데스크톱 쪽은 온도를 나누어 판단한다. 묻는 것은 선악이 아니라 경계의 위치.

11. 흔한 오해

오해 1: COM = ActiveX

아닙니다. COM은 토대이고, ActiveX는 그 위에서 쓰이는 컨트롤 문맥입니다.

오해 2: ActiveX = Internet Explorer

아닙니다. IE에서 유명해진 것은 사실이지만, ActiveX는 브라우저 전용이 아닙니다.

오해 3: ActiveX = OCX

실무에서는 꽤 가까운 의미로 쓰이지만, 엄밀히는 다릅니다. ActiveX는 문맥이나 부품의 이야기이고, OCX는 파일 확장자로 마주치는 실체입니다.

오해 4: OCX는 그냥 DLL이잖아

거칠게 말하면 가깝지만, 조사에서는 거칠게 하지 않는 편이 낫습니다. .dll만으로는 역할이 읽히지 않지만, .ocx는 꽤 컨트롤 쪽 냄새가 납니다.

오해 5: COM은 이미 죽은 기술

적어도 Windows 세계에서는 그런 말은 거칠습니다. 무대 앞에서 조금 내려간 것처럼 보일 뿐이고, 설계나 상호 운용 문맥에서는 지금도 나옵니다.

flowchart TB
    accTitle: 흔한 오해를 바로잡는 법
    accDescr: COM은 ActiveX 그 자체가 아니라 토대이고, ActiveX는 IE 전용이 아니며, ActiveX와 OCX는 개념과 파일의 차이가 있고, COM은 죽은 기술이 아니라는 오해의 바로잡기를 정리한다.
    m1["COM = ActiveX ?"] --> a1["COM은 토대이고 다른 것"]
    m2["ActiveX = IE 전용 ?"] --> a2["데스크톱에서도 현역"]
    m3["ActiveX = OCX ?"] --> a3["개념과 파일의 차이"]
    m4["COM은 죽었나 ?"] --> a4["상호 운용에서 지금도 나온다"]

그림 15: 다섯 오해는 모두 계층의 차이를 섞은 데서 생겨난다.

12. 조사할 때의 체크포인트

COM / ActiveX / OCX를 발견하면, 이 근처를 차례로 확인하면 길을 잃기 어렵습니다.

1. 그것은 무슨 부품인가
   • UI 컨트롤인가
   • 뷰어인가
   • 기기 연계인가
   • Office / Access 연계인가
2. 어디서 동작하는가
   • Access / VBA인가
   • VB6 / MFC인가
   • WinForms인가
   • IE / IE 모드인가
3. 파일과 식별자는 무엇인가
   • .ocx / .dll / .exe
   • ProgID
   • CLSID
   • Type Library
4. 등록과 배포는 어떻게 되어 있는가
   • regsvr32가 필요한가
   • 의존 DLL이 있는가
   • 관리자 권한이 필요한가
5. bitness는 맞는가
   • 32bit인가
   • 64bit인가
   • 같은 프로세스에서 동작해야 하는가
6. 장래에 어떻게 다룰 것인가
   • 그대로 남길 것인가
   • 경계를 만들어 감쌀 것인가
   • 교체할 것인가

12.1. 무엇으로 조사하는가

위의 6가지는 「무엇을 볼 것인가」이므로, 「어디를 열 것인가」도 나란히 둡니다. 여기를 모르면 체크리스트가 있어도 첫 한 걸음에서 멈춥니다.

이 근처를 보지 않고 ActiveX가 있으니 전부 신규 구현합니다로 달리면, 옛날 함정을 깨끗이 밟습니다. 우선 위의 6가지와 도구의 대응을 채운 다음, 10장의 「남긴다 / 감싼다 / 교체한다」를 정하는 편이 안전합니다.

flowchart TB
    accTitle: 조사의 순서
    accDescr: 무슨 부품인지, 어디서 동작하는지, 파일과 식별자는 무엇인지, 등록과 배포는 어떻게 되어 있는지, bitness는 맞는지를 차례로 확인한 다음, 남긴다·감싼다·교체한다를 정한다.
    s1["무슨 부품인지를 본다"] --> s2["어디서 동작하는지를 본다"]
    s2 --> s3["파일과 식별자를 훑는다"]
    s3 --> s4["등록과 배포를 확인한다"]
    s4 --> s5["bitness를 확인한다"]
    s5 --> s6["남긴다·감싼다·교체한다를 정한다"]

그림 16: 갑자기 신규 구현으로 달리지 말고, 이 순서로 채운 다음 방침을 정하는 것이 안전.

13. 정리

COM / ActiveX / OCX의 차이를, 가장 거칠게, 그러면서 실무에 도움이 되는 형태로 말하면 이렇습니다.

• COM은 토대
• ActiveX는 COM 기반의 삽입 부품 문맥
• OCX는 ActiveX 컨트롤에서 자주 보는 파일

이 셋을 나누어 생각할 수 있게 되면,

• 이것은 단순한 .ocx인가
• COM 전체의 문제인가
• 브라우저 의존 ActiveX인가
• 데스크톱에서 남길 수 있는 부품인가

가 꽤 보이기 쉬워집니다.

레거시 기술은 이름이 오래되어서 어려운 것이 아니라, 토대, 부품, 파일이 같은 대화에 나오기 때문에 복잡한 것입니다. 다만 구조가 보이면, 의외로 다룰 수 있는 문제가 됩니다.

14. 참고 자료

• COM이란 무엇인가 - Windows COM의 설계가 지금도 아름다운 이유
• ActiveX / OCX를 지금 어떻게 다룰 것인가 - 남긴다·감싼다·교체한다 판단표
• 구성 요소 개체 모델(COM) - Microsoft Learn
• ActiveX 컨트롤 - Win32 apps - Microsoft Learn
• ActiveX Controls - MFC - Microsoft Learn
• ActiveX Control - Access VBA - Microsoft Learn
• Internet Explorer(IE) 모드란 - Microsoft Learn
• IE와 Edge의 수명 주기 FAQ - Microsoft Learn(IE 모드를 적어도 2029년까지 지원하는 방침)
• regsvr32 - Windows 명령 - Microsoft Learn
• CLSID 키 - Win32 apps - Microsoft Learn
• 레지스트리 리디렉터 - Win32 apps - Microsoft Learn
• Internet Explorer 모드(IE 모드)에서 DevTools 사용 - Microsoft Learn

관련 기사

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

관련 토픽

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

이 주제와 연결되는 서비스

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

자주 묻는 질문

이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.

OCX 파일이란 무엇인가요?

OCX는 ActiveX 컨트롤 구현에서 자주 쓰이는 파일 확장자입니다. Windows 현장에서 .ocx를 발견하면, 우선 호스트에 삽입하는 컨트롤 계열의 COM 부품이라고 의심해도 됩니다. 벤더 SDK 배포물, VB6 / Access / MFC의 오래된 프로젝트, 설치 프로그램에 포함된 등록 대상 파일, regsvr32가 필요한 부품으로 나오는 경우가 많습니다. OCX는 파일의 형태이지 개념 그 자체가 아니라는 점을 잡아 두면 헷갈리기 어렵습니다.

COM과 ActiveX는 무엇이 다른가요?

COM은 Windows에서 컴포넌트끼리 주고받기 위한 바이너리 계약, 즉 토대입니다. ActiveX는 COM을 기반으로 한 재사용 가능한 소프트웨어 부품으로, 특히 호스트나 컨테이너에 삽입해 쓰는 컨트롤의 문맥을 가리키는 경우가 많습니다. 「COM = 구조, ActiveX = 부품의 문맥, OCX = 파일」로 보면 전망이 좋아집니다. ActiveX의 토대는 COM이지만, ActiveX가 COM 그 자체는 아닙니다.

ActiveX는 Internet Explorer 전용 기술인가요?

아닙니다. IE에서 유명해진 것은 사실이지만, ActiveX 컨트롤은 Access 폼, VB6 애플리케이션, MFC 컨테이너, Office / VBA 주변, WinForms에서 COM 래퍼로 쓰는 경우처럼 Windows 앱 쪽에서도 오래 쓰여 온 부품 기술입니다. 브라우저 전용이 아니라 Windows의 삽입 부품 기술로 보는 편이 실무에서는 맞습니다. 브라우저 쪽 ActiveX 의존은 현대에는 「어떻게 연명할지」보다 「어디서부터 떼어낼지」로 생각하는 편이 현실적입니다.

OCX와 DLL은 어떻게 다른가요?

.ocx는 ActiveX 컨트롤임을 꽤 강하게 암시하는 확장자이지만, .dll은 평범한 라이브러리일 수도, COM 서버일 수도, ActiveX 주변의 의존 DLL일 수도 있습니다. 실무에서는 vendorcontrol.ocx를 주역으로 두고 vendorhelper.dll 같은 DLL이 옆을 받치는 패턴이 흔합니다. OCX가 DLL의 일종이냐고 물으면 감각적으로는 가깝지만, 조사나 이전 장면에서는 역할을 나누어 보는 것이 안전합니다.

저자 프로필

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

Go Komura

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

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