COM STA/MTA의 기초 지식 - 스레드 모델과 hang을 피하는 사고방식

COM의 STA/MTA는 Windows 개발이나 .NET에서 COM을 다룰 때 피해 가기 어려운 기초 지식입니다. 특히 검색에서 많은 질문은 UI 스레드가 왜 STA인지, Apartment를 넘으면 무엇이 일어나는지, 왜 hang이 나는지입니다.

목차

• 1. 먼저 결론(한 마디로)
• 2. Apartment Model의 호출 패턴(그림)
  • 2.1. 패턴 1: 같은 STA 스레드 안에서의 호출
  • 2.2. 패턴 2: 같은 MTA 안에서의 호출
  • 2.3. 패턴 3: Apartment를 넘는 호출
  • 2.4. 마샬링 오버헤드의 대략
• 3. STA(Single-Threaded Apartment)
  • 3.1. UI 스레드에서 STA가 쓰이는 이유
• 4. MTA(Multi-Threaded Apartment)
• 5. STA/MTA는 어디에서 정해지는가
  • 5.1. .NET에서의 STA/MTA
• 6. STA를 잘못 다루면 생기는 hang의 구체 예
  • 6.1. 흔히 있는 상황
  • 6.2. 무엇이 일어나는가
  • 6.3. 의사 코드(전형적인 실패 패턴)
  • 6.4. 회피의 요점
  • 6.5. 「메시지 루프를 돌린다」는 결국 무엇인가?
  • 6.6. 올바른 방향의 예(대충 쓰면)
  • 6.7. 또 하나의 hang 예: 동기 호출 중의 콜백
• 7. 대략적인 구분
• 8. 정리
• 9. 참고 자료

COM을 쓸 때 「어느 스레드에서 동작하는가」는 피해 갈 수 없습니다. 그 중심에 있는 것이 Apartment Model(STA/MTA) 입니다. STA/MTA는 Windows의 일반적인 스레드 개념이 아니라, COM 객체의 호출 규칙을 정하기 위한 스레드 모델입니다.

이 글에서는 STA와 MTA와 COM의 관계를 그림으로 따라가면서, 「왜 hang이 나기도 하는가」까지 이어서 설명합니다.

flowchart TB
    accTitle: Apartment Model의 위치
    accDescr: STA/MTA는 Windows의 일반적인 스레드 개념이 아니라, COM 객체의 호출 규칙을 정하기 위한 스레드 모델인 Apartment Model의 두 형태임을 나타내는 그림.
    com["COM 객체의 호출 규칙"] --> am["Apartment Model"]
    am --> sta["STA"]
    am --> mta["MTA"]
    am -.-> note["Windows 일반 스레드 개념이 아님"]

그림 1: STA/MTA는 COM 객체의 호출 규칙을 정하는 Apartment Model의 두 형태.

이 글의 지식 맵

COM의 STA(Single-Threaded Apartment)와 MTA(Multi-Threaded Apartment)는 어느 스레드에서 컴포넌트를 호출해도 되는지를 정하는 Apartment 모델의 두 형태입니다. STA는 1 스레드에 1 Apartment이며, Apartment를 넘는 호출은 Proxy/Stub을 거쳐 마샬링됩니다. 다른 스레드에서 호출되는 STA는 메시지 루프를 돌리고 있지 않으면 호출의 전달을 받을 수 없어 행(hang)이 되고, 동기 호출 중에 콜백이 오는 패턴도 데드락이 되기 쉬운 구조입니다. MTA는 여러 스레드가 1 Apartment를 공유하는 대신 객체 쪽에 스레드 안전 설계를 요구합니다. .NET의 [STAThread] 속성은 이 Apartment 초기화를 설정하는 래퍼에 지나지 않습니다.

flowchart LR
    accTitle: COM STA/MTA의 지식 맵
    accDescr: STA와 MTA라는 COM의 Apartment 모델이 메시지 루프·마샬링·Proxy/Stub과 어떻게 관계되고, 메시지 루프의 부재가 STA의 행(hang)이나 데드락으로 이어지는 구조를 보여주는 그림
    sta["STA(Single-Threaded Apartment)"]
    mta["MTA(Multi-Threaded Apartment)"]
    com["COM(컴포넌트 오브젝트 모델)"]
    com_apartment_model["COM 아파트먼트 모델(STA/MTA)"]
    coinitializeex["CoInitializeEx"]
    message_loop["메시지 루프"]
    proxy_stub["Proxy/Stub"]
    thread_safe_com_object["스레드 안전 COM 개체 설계"]
    windows_forms["Windows Forms"]
    stathread_attribute[".NET의 [STAThread]/[MTAThread] 특성"]
    threadingmodel_registry["ThreadingModel 레지스트리 값"]
    com_automation["Automation"]
    idispatch["IDispatch"]
    midl["MIDL"]
    sta_hang["STA hang(호출 전달 중단)"]
    msgwaitformultipleobjects["MsgWaitForMultipleObjects"]
    sta_callback_deadlock["동기 호출 중 콜백으로 인한 데드락"]
    dotnet[".NET(Core 이후)"]
    com_marshaling["마샬링"]
    com -->|"이용한다"| com_apartment_model
    com_apartment_model -->|"전제로 한다"| coinitializeex
    sta -->|"전제로 한다"| message_loop
    sta -.->|"이용한다"| proxy_stub
    mta -->|"전제로 한다"| thread_safe_com_object
    windows_forms -.->|"이용한다"| sta
    windows_forms -->|"이용한다"| message_loop
    stathread_attribute -->|"이용한다"| coinitializeex
    threadingmodel_registry -.->|"전제로 한다"| sta
    com_automation -->|"이용한다"| idispatch
    proxy_stub -.->|"에서 구성할 수 있다"| midl
    sta -.->|"원인이 될 수 있다"| sta_hang
    message_loop -->|"방지한다"| sta_hang
    msgwaitformultipleobjects -.->|"방지한다"| sta_hang
    sta -.->|"원인이 될 수 있다"| sta_callback_deadlock
    dotnet -.->|"원인이 될 수 있다"| sta_hang
    mta -.->|"이용한다"| proxy_stub
    stathread_attribute -->|"전제로 한다"| com_apartment_model
    proxy_stub -->|"구현을 담당한다"| com_marshaling
    com_automation -->|"구현을 담당한다"| com_marshaling

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

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

• COM 객체는 「어느 Apartment에 속하는가」로 호출 규칙이 정해진다
• STA는 스레드 하나당 Apartment 하나, MTA는 여러 스레드가 Apartment 하나라고 보면 이해하기 쉽습니다
• Apartment를 넘는 호출은 COM이 Proxy/Stub을 거쳐 마샬링합니다

flowchart TB
    accTitle: STA와 MTA와 Apartment 경계를 넘는 관계
    accDescr: STA는 스레드 하나당 Apartment 하나, MTA는 여러 스레드가 Apartment 하나라는 형태를 취하고, Apartment를 넘는 호출은 COM이 Proxy/Stub을 거쳐 마샬링한다는 결론을 나타내는 그림.
    sta["STA(스레드 하나당 Apartment 하나)"] -->|"Apartment를 넘는 호출"| m["Proxy / Stub을 거쳐 마샬링"]
    mta["MTA(여러 스레드가 Apartment 하나)"] -->|"Apartment를 넘는 호출"| m

그림 2: 소속 Apartment가 호출 규칙을 정하고, Apartment를 넘을 때만 마샬링이 끼어든다.

2. Apartment Model의 호출 패턴(그림)

COM 객체 호출에는 크게 세 가지 패턴이 있습니다.

flowchart TB
    accTitle: 호출의 세 가지 패턴
    accDescr: COM 객체 호출에는 같은 STA 스레드 안에서의 호출, 같은 MTA 안에서의 호출, Apartment를 넘는 호출이라는 세 가지 패턴이 있음을 나타내는 그림.
    caller["COM 객체의 호출"] --> p1["패턴 1: 같은 STA 스레드 안"]
    caller --> p2["패턴 2: 같은 MTA 안"]
    caller --> p3["패턴 3: Apartment를 넘음"]

그림 3: 호출 패턴은 세 가지로 나뉘며, 어디에 해당하는가에 따라 오버헤드와 주의점이 달라진다.

2.1. 패턴 1: 같은 STA 스레드 안에서의 호출

같은 STA 스레드 안이라면 직접 호출할 수 있습니다. 오버헤드는 없습니다.

flowchart LR
    subgraph STA[STA 스레드]
        Caller[호출하는 쪽 코드]
        Obj[COM 객체]
        Caller -->|직접 호출| Obj
    end

그림 4: 같은 STA 스레드 안의 호출은 직접 호출이 되며, 오버헤드가 없다.

2.2. 패턴 2: 같은 MTA 안에서의 호출

MTA 안의 여러 스레드에서는 어느 스레드에서든 직접 호출할 수 있습니다. 다만 객체 쪽에는 스레드 안전 설계가 필수입니다.

flowchart LR
    subgraph MTA["MTA(Apartment 하나)"]
        Thread1[워커 스레드 1]
        Thread2[워커 스레드 2]
        Obj[COM 객체]
        Thread1 -->|직접 호출| Obj
        Thread2 -->|직접 호출| Obj
    end

그림 5: 같은 MTA 안이라면 어느 스레드에서도 직접 호출할 수 있지만, 객체 쪽에 스레드 안전 설계가 필요하다.

2.3. 패턴 3: Apartment를 넘는 호출

서로 다른 Apartment 사이에서는 COM이 Proxy/Stub을 써서 전달합니다. 표준 인터페이스라면 COM 런타임이 처리해 줍니다.

이 뒤의 표에는 COM 고유 용어가 설명 없이 나옵니다. 먼저 한 줄씩 적어 둡니다.

주의: Proxy/Stub이 무엇이든 자동으로 준비되는 것은 아니지만, 실무에서는 명시적으로 생성하지 않아도 되는 경우가 대부분입니다.

즉, MIDL로 Proxy/Stub 생성이 필요해지는 것은 IDispatch를 쓰지 않고 IUnknown에서 직접 파생한 인터페이스를 만드는 경우입니다. .NET이나 스크립트 언어에서 쓰는 일반적인 COM 컴포넌트에서는 이 작업이 필요해지는 일이 적습니다.

flowchart TB
    accTitle: Proxy/Stub을 직접 준비할지 여부의 갈림
    accDescr: IDispatch 기반이나 타입 라이브러리 마샬러 등 COM 표준 마샬링으로 되는 경우에는 Proxy/Stub 생성이 불필요하고, 그것으로 안 되는 IUnknown 직접 파생 커스텀 인터페이스일 때만 MIDL로 Proxy/Stub 생성과 등록이 필요해진다는 갈림을 나타내는 그림.
    q{"표준 마샬링으로 되는가"} -->|"예"| auto["Proxy/Stub 생성은 불필요"]
    q -->|"아니요"| midl["MIDL로 Proxy/Stub을 생성·등록"]
    auto -.-> how["IDispatch나 타입 라이브러리가 처리"]
    auto -.-> few["실무에서는 이쪽인 경우가 대부분"]

그림 6: Proxy/Stub을 명시적으로 생성하는 것은, 표준 마샬링으로 안 되는 IUnknown 직접 파생 커스텀 인터페이스일 때이다.

flowchart LR
    subgraph STA[STA 스레드]
        StaCaller[호출하는 쪽 코드]
    end

    subgraph RT["COM 런타임(자동)"]
        Proxy[Proxy]
        RPC[RPC/IPC]
        Stub[Stub]
        Proxy --> RPC --> Stub
    end

    subgraph MTA[MTA 스레드]
        MtaObj[COM 객체]
    end

    StaCaller -->|호출| Proxy
    Stub -->|전달| MtaObj

그림 7: Apartment를 넘는 호출은, COM 런타임이 자동으로 준비하는 Proxy·RPC·Stub을 거쳐 전달된다.

포인트: Apartment를 넘으면 마샬링 오버헤드가 발생합니다. 호출이 잦으면 성능에 영향을 주므로, 설계 단계에서 고려가 필요합니다.

2.4. 마샬링 오버헤드의 대략

아래는 일반적인 대략입니다(실측값이 아니며, 상황·매개변수의 복잡도에 따라 크게 달라집니다).

상대적인 비교:

• 같은 Apartment: 메모리 접근 한 번 정도
• 다른 Apartment: 시스템 콜 한 번 정도
• 다른 프로세스: 로컬 호스트로의 네트워크 통신 정도

루프에서 1만 번 호출하는 장면에서는 이 차이가 뚜렷이 나타납니다.

이 수치를 다루는 방식

위 표는 자릿수(order)의 감각을 잡기 위한 것이며, 출처가 있는 실측값이 아닙니다. 공개된 통일 벤치마크가 있는 것도 아니므로, 이 수치 자체를 설계 판단의 근거로 쓰지 마십시오.

한편 「같은 Apartment 안은 직접 호출이고, 경계를 넘으면 반드시 마샬링이 끼어든다」는 구조는 Microsoft 문서에 적힌 사양입니다. Single-Threaded Apartments 항에는, 같은 Apartment 안이라면 인터페이스 포인터를 마샬링 없이 넘길 수 있다는 것, Apartment를 넘는 경우에는 같은 프로세스 안이라도 프로세스 간과 같은 마샬링 구조를 쓴다는 것, 그리고 호출이 숨겨진 창(OleMainThreadWndClass)으로의 윈도우 메시지로 도착한다는 것이 명시되어 있습니다. 자릿수가 바뀌는 것은 이 구조 때문이며, 수치 자체는 환경과 인수의 복잡도에 따라 움직입니다.

자기 사례로 판단하려면, 같은 인터페이스를 같은 Apartment에서 호출한 경우와 다른 Apartment에서 호출한 경우로 측정해 비교하는 것이 확실합니다.

flowchart TB
    accTitle: 자릿수가 바뀌는 구조상의 이유
    accDescr: 같은 Apartment 안은 직접 호출인 데 비해, Apartment를 넘으면 같은 프로세스 안이라도 반드시 마샬링이 끼어들고, 목적지가 STA이면 호출이 숨겨진 창으로의 윈도우 메시지로 도착한다는, 자릿수가 바뀌는 구조상의 이유를 나타내는 그림.
    same["같은 Apartment 안의 호출"] --> direct["직접 호출"]
    cross["Apartment를 넘는 호출"] --> marshal["반드시 마샬링이 끼어든다"]
    marshal -.-> msg["STA 대상은 숨겨진 창으로 도착한다"]

그림 8: 자릿수가 바뀌는 것은, 경계를 넘으면 반드시 마샬링이 끼어든다는 사양상의 구조 때문이다.

// C#. 같은 호출을 N번 반복해 1회당 시간을 낸다
static void Measure(string label, Action call, int iterations = 100_000)
{
    call(); // 첫 호출의 지연(JIT, 프록시 생성, 연결 수립)을 계측에서 뺀다

    var sw = System.Diagnostics.Stopwatch.StartNew();
    for (int i = 0; i < iterations; i++)
    {
        call();
    }
    sw.Stop();

    double perCallNs = sw.Elapsed.TotalMilliseconds * 1_000_000.0 / iterations;
    Console.WriteLine($"{label}: {perCallNs:F1} ns/call");
}

인수가 적은 메서드와, 문자열이나 배열을 넘기는 메서드 양쪽에서 측정하면 「마샬링량에 따라 영향이 달라진다」는 것도 보입니다.

3. STA(Single-Threaded Apartment)

STA는 「1스레드 = 1Apartment」 모델입니다.

• 그 Apartment 안의 COM 객체는 기본적으로 그 스레드에서만 실행
• 다른 스레드에서 호출하면 COM이 메시지 큐/RPC로 호출을 전달
• UI 스레드(WinForms/WPF)에서 자주 쓰인다(UI도 「thread affinity + 메시지 루프」라 궁합이 좋다)

flowchart TB
    accTitle: STA의 실행 모델
    accDescr: STA에서는 Apartment 안의 COM 객체가 기본적으로 생성한 스레드에서만 실행되고, 다른 스레드에서의 호출은 COM이 메시지 큐나 RPC로 그 스레드에 전달함을 나타내는 그림.
    obj["STA의 COM 객체"] --> own["생성한 스레드에서만 실행"]
    other["다른 스레드에서의 호출"] --> fwd["메시지 큐 / RPC로 전달"]
    fwd --> own

그림 9: STA 객체는 주인 스레드에서만 움직이고, 바깥에서의 호출은 전달되어 도착한다.

3.1. UI 스레드에서 STA가 쓰이는 이유

UI 스레드와 STA는 설계가 일치하기 때문입니다.

• UI 컨트롤은 스레드 안전하지 않다 버튼이나 텍스트 박스 등은 생성한 스레드에서만 안전하게 조작할 수 있다
• STA도 마찬가지로 「thread affinity」 COM 객체는 생성한 스레드에서만 직접 실행된다
• UI 스레드는 반드시 메시지 루프를 돌린다 윈도우 이벤트를 처리하기 위해 필수. STA의 전제(메시지 펌프)와 일치한다

그래서 WinForms/WPF의 UI 스레드는 기본값이 STA입니다.

flowchart TB
    accTitle: UI 스레드와 STA 설계의 일치
    accDescr: UI 컨트롤은 생성한 스레드에서만 안전하게 조작할 수 있고, STA도 thread affinity이며, UI 스레드가 반드시 돌리는 메시지 루프는 STA의 전제인 메시지 펌프와 일치하므로 UI 스레드는 기본값이 STA가 됨을 나타내는 그림.
    ui["UI 컨트롤의 thread affinity"] --> match["설계가 일치"]
    sta["STA의 thread affinity"] --> match
    loop["UI 스레드의 메시지 루프"] --> pre["STA의 전제(메시지 펌프)"]
    pre --> match
    match --> def["UI 스레드는 기본값이 STA"]

그림 10: thread affinity와 메시지 루프라는 두 점에서 설계가 일치하므로, UI 스레드는 STA가 되어 있다.

포인트: STA는 thread affinity가 높은 대신, 호출하는 쪽이 많으면 혼잡해지기 쉽다.

4. MTA(Multi-Threaded Apartment)

MTA는 「여러 스레드가 1Apartment」 모델입니다.

• COM 객체는 여러 스레드에서 동시에 호출된다
• 객체 쪽에 스레드 안전 설계가 필수
• 서버 사이드 처리나 백그라운드 처리에 맞다

포인트: MTA는 병렬성이 높지만, 객체 구현의 책임이 무겁다.

flowchart TB
    accTitle: MTA의 실행 모델
    accDescr: MTA는 여러 스레드가 Apartment 하나를 공유하고, COM 객체는 여러 스레드에서 동시에 호출되므로 객체 쪽에 스레드 안전 설계가 필수가 됨을 나타내는 그림.
    mta["MTA(여러 스레드가 1Apartment)"] --> par["여러 스레드에서 동시에 호출된다"]
    par --> safe["객체 쪽의 스레드 안전 설계가 필수"]
    mta -.-> use["서버 사이드나 백그라운드 처리에 맞다"]

그림 11: MTA는 병렬로 호출할 수 있는 대신, 안전성의 책임이 객체 구현 쪽으로 옮겨 간다.

5. STA/MTA는 어디에서 정해지는가

COM의 Apartment는 스레드마다 초기화해서 정해집니다.

• CoInitialize / CoInitializeEx를 호출한 순간에 그 스레드의 Apartment가 정해진다
• STA: COINIT_APARTMENTTHREADED
• MTA: COINIT_MULTITHREADED

flowchart TB
    accTitle: Apartment가 정해지는 순간
    accDescr: 스레드가 CoInitialize 또는 CoInitializeEx를 호출한 순간에 그 스레드의 Apartment가 정해지며, COINIT_APARTMENTTHREADED이면 STA, COINIT_MULTITHREADED이면 MTA가 됨을 나타내는 그림.
    th["스레드"] --> init["CoInitialize / CoInitializeEx를 호출"]
    init -->|"COINIT_APARTMENTTHREADED"| sta["STA로 정해진다"]
    init -->|"COINIT_MULTITHREADED"| mta["MTA로 정해진다"]

그림 12: Apartment는 스레드마다 초기화를 호출한 순간의 지정으로 정해진다.

5.1. .NET에서의 STA/MTA

.NET에도 [STAThread] / [MTAThread] 속성과 ApartmentState가 있지만, 이들은 COM의 Apartment Model을 설정하기 위한 래퍼입니다.

• [STAThread] → Main 메서드(엔트리 포인트)에 붙인다. COM을 쓸 때 STA로 초기화된다
• [MTAThread] → 마찬가지로 Main 메서드용. MTA로 초기화된다
• Thread.SetApartmentState(ApartmentState.STA) → 추가로 만드는 스레드용. 스레드 시작 전에 설정이 필요하다

주의점:

• [STAThread]가 있어도 실제로 COM을 호출하기 전에는 초기화되지 않는다(COM을 쓰지 않으면 효과 없음)
• 추가 스레드에는 [STAThread]가 적용되지 않는다. Thread.SetApartmentState를 쓴다

즉, .NET의 STA/MTA는 COM의 STA/MTA 그 자체이며, COM Interop을 위해 마련된 구조입니다.

중요: 나중에 Apartment를 바꿀 수는 없습니다. 최초 초기화가 전부입니다.

flowchart TB
    accTitle: .NET에서 Apartment를 설정하는 위치
    accDescr: Main 메서드에는 STAThread나 MTAThread 속성을 붙이고, 추가로 만드는 스레드에는 시작 전에 Thread.SetApartmentState로 설정하며, 어느 쪽이든 최초 초기화로 Apartment가 확정되어 나중에 바꿀 수 없음을 나타내는 그림.
    main["Main 메서드"] --> attr["〔STAThread〕/〔MTAThread〕 속성"]
    newth["추가로 만드는 스레드"] --> setap["시작 전에 Thread.SetApartmentState"]
    attr --> fixed["최초 초기화로 Apartment가 확정"]
    setap --> fixed
    fixed -.-> nochange["나중에 바꿀 수 없다"]

그림 13: 엔트리 포인트는 속성, 추가 스레드는 SetApartmentState로, 어느 쪽이든 첫 한 번에 확정된다.

6. STA를 잘못 다루면 생기는 hang의 구체 예

다음 같은 구성은 실제로 hang이 나기 쉽습니다.

6.1. 흔히 있는 상황

• 백그라운드에서 STA 스레드를 만들어 COM 객체를 생성
• 그 스레드는 메시지 루프를 돌리지 않는다
• 다른 스레드(STA/MTA를 가리지 않음)에서 그 COM 객체를 호출

flowchart TB
    accTitle: hang이 나기 쉬운 구성
    accDescr: 백그라운드에서 만든 STA 스레드가 COM 객체를 생성했는데 메시지 루프를 돌리지 않고, 그쪽으로 다른 스레드에서 그 COM 객체를 호출하는, hang이 나기 쉬운 구성을 나타내는 그림.
    bg["백그라운드의 STA 스레드"] --> gen["COM 객체를 생성"]
    bg --> noloop["메시지 루프를 돌리지 않는다"]
    other["다른 스레드(STA / MTA를 가리지 않음)"] -->|"호출한다"| gen

그림 14: 「루프를 돌리지 않는 STA가 가진 객체를, 다른 스레드에서 호출한다」는 조합이 위험하다.

6.2. 무엇이 일어나는가

hang의 이유는 STA의 두 전제로 모입니다. 이 절이 이유 설명이고, 이후 절에서는 반복하지 않습니다.

• COM 객체는 생성한 STA 스레드에서 처리된다 호출하는 쪽이 STA이든 MTA이든, 다른 스레드에서의 호출은 반드시 그 STA 스레드로 전달됩니다. 전달은 COM이 그 Apartment에 만드는 숨겨진 창(윈도우 클래스 OleMainThreadWndClass)으로의 윈도우 메시지로 도착합니다
• 그 전달을 받으려면 STA 스레드가 메시지 펌프를 돌리고 있어야 한다 Microsoft 문서에도 「각 STA는 다른 프로세스나 같은 프로세스 안의 다른 Apartment에서의 호출을 처리하기 위해 메시지 루프를 가져야 한다」고 명시되어 있습니다

따라서 메시지를 돌리지 않는 STA 스레드는 호출을 받지 못하고, 호출하는 쪽은 답을 계속 기다리며, 결과적으로 hang이 됩니다.

flowchart TB
    accTitle: hang에 이르는 흐름
    accDescr: 다른 스레드에서의 호출은 생성한 STA 스레드로 숨겨진 창으로의 윈도우 메시지로 전달되지만, STA 스레드가 메시지 펌프를 돌리지 않으면 받지 못해 호출하는 쪽이 답을 계속 기다리며 hang이 되는 흐름을 나타내는 그림.
    caller["다른 스레드에서의 호출"] --> fwd["생성한 STA 스레드로 전달"]
    fwd -.-> hidden["숨겨진 창으로의 메시지로 도착"]
    fwd --> nopump["메시지 펌프가 돌지 않는다"]
    nopump --> norecv["STA 쪽이 호출을 받지 못한다"]
    norecv --> wait["호출하는 쪽은 답을 계속 기다린다"]
    wait --> hang["hang"]

그림 15: 전달은 메시지로 도착하므로, 펌프가 멈춘 STA에서는 받을 쪽이 없어진다.

참고로 이것은 .NET에서도 같습니다. Single-Threaded Apartments 문서에는, STA 스레드를 Task.Wait(), Task.Result, Thread.Sleep(), ManualResetEvent.WaitOne() 등으로 막으면 COM 콜백이나 Apartment를 넘는 호출이 끝나지 못해 데드락이 된다는 경고가 있습니다. 다음 6.3의 실패 예가 WaitOne()에서 멈추는 것은 바로 이 형태입니다.

한편 UI 스레드는 윈도우 이벤트를 처리하기 위해 처음부터 메시지 루프를 돌리므로, STA 요건을 추가 구현 없이 충족합니다. UI 스레드가 STA COM 객체를 움직이는 장소로서 자연스러운 선택이 되는 것은 이 때문입니다.

6.3. 의사 코드(전형적인 실패 패턴)

using System;
using System.Runtime.InteropServices;
using System.Threading;

internal static class StaHangDemo
{
    private const uint COINIT_APARTMENTTHREADED = 0x2;

    [DllImport("ole32.dll")]
    private static extern int CoInitializeEx(IntPtr pvReserved, uint dwCoInit);

    [DllImport("ole32.dll")]
    private static extern void CoUninitialize();

    public static void Run(string progId)
    {
        var ready = new AutoResetEvent(false);
        var done = new AutoResetEvent(false);

        object comObj = null;

        var staThread = new Thread(() =>
        {
            // STA로 초기화
            CoInitializeEx(IntPtr.Zero, COINIT_APARTMENTTHREADED);

            // ThreadingModel=Apartment 로 등록된 COM 클래스를 가정
            Type type = Type.GetTypeFromProgID(progId, throwOnError: true);
            comObj = Activator.CreateInstance(type);
            ready.Set();

            // 메시지 루프 없이 대기 -> 여기가 치명적
            done.WaitOne();

            CoUninitialize();
        });

        staThread.SetApartmentState(ApartmentState.STA);
        staThread.Start();

        ready.WaitOne();

        try
        {
            // 다른 스레드(STA/MTA를 가리지 않음)에서 호출하면, 호출이 STA로 전달된다
            // 그러나 STA 쪽은 메시지를 처리하지 않으므로, 여기서 hang이 나기 쉽다
            dynamic obj = comObj;
            obj.AnyMethod();
        }
        finally
        {
            // 호출이 돌아온 경우 ── agile한 클래스였거나,
            // 호출이 전달되지 않았거나, AnyMethod가 바로 돌아온 경우 ── 라도
            // 반드시 STA 스레드를 해제한다. 여기를 빼면 done을 기다리는
            // 포그라운드 스레드가 남아, 「재현되지 않은」 때도
            // 프로세스가 끝나지 않는다. 재현 여부를 증상으로 구별할 수 없게 된다
            done.Set();
            staThread.Join();
        }
    }
}

이 코드는 ThreadingModel=Apartment(= STA)로 등록된 COM 클래스의 ProgID를 넘기는 전제입니다. AnyMethod는 그 클래스가 실제로 가진 메서드 이름으로 바꾸십시오. 어떤 COM 클래스에서든 재현되는 것은 아닙니다. 재현에 필요한 조건은 다음 세 가지입니다.

obj.AnyMethod()를 try / finally로 감싸고 done.Set()과 staThread.Join()을 반드시 통과시키는 것은, 이 「재현되지 않는 경우」를 구별하기 위해서입니다. STA 스레드는 기본이 포그라운드 스레드이므로, done이 설정되지 않는 한 프로세스는 끝나지 않습니다. finally를 빼면 재현된 때(호출이 돌아오지 않음)와 재현되지 않은 때(호출은 돌아왔지만 done을 아무도 세우지 않음)에서, 밖에서 보이는 증상이 둘 다 「프로세스가 끝나지 않는다」가 됩니다. 재현 조건을 확인하는 도구가 조건이 맞았는지 틀렸는지를 가려 버리는 셈입니다. 위 형태라면 재현되지 않은 경우에는 그대로 정상 종료합니다.

멈춘 것의 확인은, 디버거로 프로세스를 일시 정지하고 호출하는 쪽 스레드의 스택이 COM 대기에서 멈춰 있는 것과 STA 스레드가 WaitOne에서 멈춰 있는 것을 보는 편이 빠릅니다.

sequenceDiagram
    participant Main as 메인 스레드
    participant STA as STA 스레드
    participant COM as COM 런타임

    Main->>STA: 스레드 시작
    STA->>STA: CoInitializeEx(STA)
    STA->>STA: COM 객체 생성
    STA->>Main: ready.Set()
    STA->>STA: done.WaitOne()으로 대기
    Note over STA: 메시지 루프 없음<br/>여기서 막혀 있다

    Main->>COM: CallComObject()
    COM->>STA: 호출을 전달하려 한다
    Note over COM: 메시지로 전달하지만...
    Note over STA: WaitOne 중이므로<br/>메시지를 처리하지 못한다
    Note over Main: 호출하는 쪽도 계속 기다린다
    Note over Main,STA: 양쪽이 대기 상태 → hang

그림 16: WaitOne으로 멈춘 STA 스레드와, 전달의 답을 기다리는 메인 스레드가 서로 진행하지 못하게 된다.

그림 가운데 「메시지로 전달하지만…」의 두 줄이, 6.2에서 쓴 두 전제가 무너지는 지점입니다.

6.4. 회피의 요점

• 다른 스레드에서의 호출을 받는 경우, STA 스레드는 메시지 루프를 돌려야 한다
• 가능하면 UI 스레드에서 생성·사용한다(UI 스레드는 처음부터 메시지 루프가 있다)
• STA가 필요 없으면 처음부터 MTA로 둔다

보충: 같은 스레드 안에서만 끝나면, 항상 Application.Run()이 필요한 것은 아닙니다. 다만 UI 계열·COM 계열은 다른 스레드에서의 호출이 얽히는 경우가 많아서, 실무상으로는 거의 필수입니다.

flowchart TB
    accTitle: hang 회피의 세 방향
    accDescr: 다른 스레드에서의 호출을 받으면 STA 스레드에서 메시지 루프를 돌리고, 가능하면 처음부터 메시지 루프를 가진 UI 스레드에서 생성·사용하고, STA가 필요 없으면 처음부터 MTA로 둔다는 세 가지 회피 방향을 나타내는 그림.
    q["STA의 hang을 어떻게 피할 것인가"] --> a1["STA 스레드에서 메시지 루프를 돌린다"]
    q --> a2["UI 스레드에서 생성·사용한다"]
    q --> a3["STA가 필요 없으면 처음부터 MTA"]
    a2 -.-> why["UI 스레드는 처음부터 루프가 있다"]

그림 17: 회피책은 루프를 돌린다·루프가 있는 곳으로 모은다·STA를 그만둔다, 세 방향으로 정리할 수 있다.

6.5. 「메시지 루프를 돌린다」는 결국 무엇인가?

Win32 UI 스레드가 하는, 그 익숙한 이것입니다.

while (GetMessage(out var msg, IntPtr.Zero, 0, 0))
{
    TranslateMessage(ref msg);
    DispatchMessage(ref msg);
}

STA에서는 다른 스레드에서의 호출이 「전달」되어 옵니다. 그 전달을 받아 실행으로 넘기는 것이 이 루프(메시지 펌프)라는 이야기입니다.

flowchart TB
    accTitle: 메시지 펌프의 역할
    accDescr: 다른 스레드에서 전달된 호출을 GetMessage로 받고, DispatchMessage로 실hang에 넘기는 반복이 메시지 펌프임을 나타내는 그림.
    fwd["전달되어 온 호출"] --> gm["GetMessage로 받는다"]
    gm --> dm["DispatchMessage로 실hang에 넘긴다"]
    dm --> gm

그림 18: 「메시지 루프를 돌린다」는 것은, 전달을 받아 실hang에 넘기는 이 반복을 말한다.

6.6. 올바른 방향의 예(대충 쓰면)

「백그라운드 STA에서 COM을 쓰고 싶다」면, 이런 형태가 됩니다.

var ready = new AutoResetEvent(false);
object comObj = null;

var staThread = new Thread(() =>
{
    CoInitializeEx(IntPtr.Zero, COINIT_APARTMENTTHREADED);

    comObj = new SomeStaComObject();
    ready.Set();

    // STA 스레드가 살아있는 동안은 메시지를 돌린다
    Application.Run();

    CoUninitialize();
});

staThread.SetApartmentState(ApartmentState.STA);
staThread.Start();

ready.WaitOne();
CallComObject(comObj);

(※ CoInitializeEx / CoUninitialize를 빼먹으면 흔히 사고가 납니다. CoInitializeEx의 P/Invoke 선언은 6.3과 같은 것이 필요합니다)

Application.Run()의 인수 없는 형태는 폼 없이 메시지 루프만 돌리기 위한 것입니다. 용도로는 바로 이런 장면이 해당하지만, 다음 두 가지는 짚어 두십시오.

• System.Windows.Forms 참조가 필요합니다. 콘솔 앱이라면 프로젝트 파일에 <UseWindowsForms>true</UseWindowsForms>를 넣습니다
• 이 루프는 스스로 끝나지 않습니다. 멈추려면 그 스레드에서 Application.ExitThread()(또는 앱 전체를 끝내는 Application.Exit())를 호출합니다. 위 예에서 CoUninitialize()까지 도달시키려면, STA 스레드에 「종료」를 알려 ExitThread를 호출하게 하는 장치가 따로 필요합니다

WinForms에 의존하고 싶지 않으면 6.5의 GetMessage / DispatchMessage 루프를 직접 쓰거나, 메시지와 동기 객체를 둘 다 기다릴 수 있는 MsgWaitForMultipleObjects를 씁니다. 후자는 「이벤트로 종료 알림을 받으면서 COM 호출도 놓치지 않는」 형태로 만들고 싶을 때의 정석입니다.

flowchart TB
    accTitle: 백그라운드 STA에서 루프를 돌리는 세 수단
    accDescr: 백그라운드 STA에서 메시지 루프를 돌리려면 WinForms 참조가 필요한 Application.Run을 쓰거나, GetMessage와 DispatchMessage 루프를 직접 쓰거나, 메시지와 동기 객체를 둘 다 기다릴 수 있는 MsgWaitForMultipleObjects를 쓴다는 세 수단이 있음을 나타내는 그림.
    want["백그라운드 STA에서 루프를 돌린다"] --> ar["Application.Run"]
    want --> gml["GetMessage 루프를 직접 쓴다"]
    want --> mw["MsgWaitForMultipleObjects"]
    ar -.-> dep["WinForms 참조와 종료 수단이 필요"]
    mw -.-> both["메시지와 동기 객체를 둘 다 기다릴 수 있다"]

그림 19: 루프를 돌리는 방법은 세 가지이며, 종료 방식과 의존의 무게로 고르게 된다.

6.7. 또 하나의 hang 예: 동기 호출 중의 콜백

STA는 「호출이 전달된다」뿐 아니라, 상황에 따라서는 반대 방향(서버→클라이언트)으로 콜백이 옵니다. 그중에서도 동기 호출 중에 콜백이 발생하는 패턴은 데드락의 정석입니다.

sequenceDiagram
    participant UI as UI 스레드(STA)
    participant Server as COM 서버

    UI->>Server: DoWork()(동기 호출)
    Note over UI: DoWork의 반환을 기다리는 중<br/>(메시지를 처리하지 않음)
    Server->>UI: ProgressCallback()(콜백)
    Note over UI: 대기 중이므로<br/>콜백을 받을 수 없다
    Note over Server: 콜백 완료를 기다리는 중
    Note over UI,Server: 서로가 상대를 기다린다 → 데드락

그림 20: 동기 호출의 반환을 기다리는 UI 스레드와, 콜백 완료를 기다리는 서버가 서로를 기다린다.

왜 데드락이 되기 쉬운가:

1. UI 스레드가 DoWork()를 동기 호출(블로킹)
2. UI 스레드는 반환을 기다리는 중(메시지를 처리하지 않음)
3. 서버가 ProgressCallback()을 UI 스레드에 보낸다
4. UI 스레드는 대기 중이므로 콜백을 받을 수 없다
5. 서버는 콜백 완료를 기다리고 있다
6. 서로가 상대를 기다린다 → 영원히 진행되지 않는다

처리 시간의 길이는 관계없습니다. 동기 호출 중에 콜백이 온다는 패턴 자체가 문제가 되기 쉽습니다.

보충: COM에는 상황에 따라 메시지를 돌리거나 재진입하는 구조도 있어, 컴포넌트나 호출 형태에 따라 동작이 달라집니다. 반드시 데드락이 되는 것은 아니지만, 이 패턴은 피하는 편이 무난합니다.

7. 대략적인 구분

헤맬 때의 우선순위는 「상대의 요구 > UI 유무 > 병렬성」 순으로 보면 정해지기 쉽습니다. Apartment는 최초 초기화로 확정되고 나중에 바꿀 수 없으므로, 여기만은 구현을 시작하기 전에 정해 둡니다.

flowchart LR
    accTitle: 헤맬 때 보는 순서
    accDescr: STA와 MTA 구분에 헤맬 때는 쓰는 COM 컴포넌트 쪽의 요구, UI 유무, 병렬성 순으로 확인하면 정해지기 쉬움을 나타내는 그림.
    p1["상대의 요구"] -->|"다음에"| p2["UI 유무"]
    p2 -->|"다음에"| p3["병렬성"]

그림 21: 구분에 헤매면 상대의 요구·UI 유무·병렬성 순으로 확인한다.

8. 정리

STA/MTA는 COM을 위한 스레드 모델이며, STA는 1스레드 = 1Apartment, MTA는 여러 스레드가 1Apartment라는 형태를 취합니다. Apartment를 넘는 호출은 COM이 Proxy/Stub을 거쳐 전달해 줍니다(표준 인터페이스 이외는 MIDL 등으로 생성·등록이 필요)만, 거기에는 마샬링 오버헤드가 따르므로 고빈도 호출이 예상되는 장면에서는 Apartment 설계를 신중히 정하고 싶습니다.

hang의 관점에서는 「다른 스레드에서의 호출을 받는 STA 스레드는 메시지 펌프를 돌리는 것이 전제」라는 한 점으로 모입니다. 메시지를 돌리지 않는 STA 스레드에 호출하면 hang이 나기 쉽고, 동기 호출 중에 콜백이 오는 패턴도 데드락이 되기 쉽습니다. UI 스레드는 「thread affinity」과 「메시지 루프」를 처음부터 가지고 있어 이 전제를 추가 구현 없이 충족하므로, STA COM과 궁합이 좋은 것입니다.

9. 참고 자료

• Apartment Model https://learn.microsoft.com/en-us/windows/win32/com/com-apartments
• CoInitializeEx https://learn.microsoft.com/en-us/windows/win32/api/objbase/nf-objbase-coinitializeex
• Single-Threaded Apartments(메시지 루프가 필수인 이유, 숨겨진 창, .NET에서의 데드락 경고) https://learn.microsoft.com/en-us/windows/win32/com/single-threaded-apartments
• Multithreaded Apartments https://learn.microsoft.com/en-us/windows/win32/com/multithreaded-apartments
• InprocServer32(ThreadingModel 값) https://learn.microsoft.com/en-us/windows/win32/com/inprocserver32
• Application.Run 메서드(폼 없이 메시지 루프를 돌리는 형태와, 그 멈추는 방법) https://learn.microsoft.com/en-us/dotnet/api/system.windows.forms.application.run
• MsgWaitForMultipleObjects(메시지와 동기 객체를 동시에 기다림) https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-msgwaitformultipleobjects

이 글의 Word 파일 다운로드

관련 기사

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

관련 토픽

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

이 주제와 연결되는 서비스

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

자주 묻는 질문

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

STA와 MTA 중 어느 쪽을 골라야 하나요?

UI가 얽히는 처리라면 STA, 대량 병렬 처리라면 MTA가 기본적인 구분입니다. STA는 스레드 하나당 Apartment 하나라 thread affinity가 높은 반면, 호출자가 많으면 혼잡해지기 쉽습니다. MTA는 여러 스레드가 Apartment 하나를 공유하므로 병렬성은 높지만, COM 객체 쪽에 스레드 안전 설계가 필수입니다. 어느 쪽도 아니면, 쓰는 기존 라이브러리나 COM 서버의 요구에 맞추는 편이 현실적입니다.

UI 스레드는 왜 STA인가요?

UI 스레드와 STA의 설계가 일치하기 때문입니다. 버튼이나 텍스트 박스 같은 UI 컨트롤은 스레드 안전하지 않아, 생성한 스레드에서만 안전하게 조작할 수 있습니다. STA도 마찬가지로 thread affinity 모델입니다. 게다가 UI 스레드는 윈도우 이벤트 처리를 위해 반드시 메시지 루프를 돌리므로, STA의 전제인 메시지 펌프를 추가 구현 없이 충족합니다. 이 때문에 WinForms/WPF의 UI 스레드는 기본값이 STA입니다.

STA의 COM 객체를 호출하면 hang이 나는 이유는 무엇인가요?

STA COM 객체에 대한 호출은 생성한 STA 스레드에서 처리됩니다. 다른 스레드에서의 호출은 COM이 메시지/RPC로 전달하지만, STA 스레드가 메시지 루프를 돌리지 않으면 전달을 받지 못해 호출자가 계속 기다리며 hang이 됩니다. 피하려면 다른 스레드에서 호출되는 STA 스레드에서 메시지 루프를 돌리거나, UI 스레드에서 생성·사용하거나, STA가 필요 없으면 처음부터 MTA로 두면 됩니다.

.NET의 [STAThread] 속성은 무엇을 위한 것인가요?

COM의 Apartment Model을 설정하기 위한 래퍼입니다. Main 메서드에 붙이면 COM을 쓸 때 그 스레드가 STA로 초기화됩니다. 다만 실제로 COM을 호출하기 전에는 초기화되지 않으며, COM을 쓰지 않는 앱에서는 효과가 없습니다. 추가로 만드는 스레드에는 적용되지 않으므로, 스레드 시작 전에 Thread.SetApartmentState로 설정합니다. Apartment는 최초 초기화로 정해지며 나중에 바꿀 수 없다는 점도 주의가 필요합니다.

저자 프로필

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

Go Komura

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

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