Windows 앱 호환이 동작하는 방식 ── 호환성 모드, 심(Shim), Compatibility Administrator로 오래된 앱의 수명을 연장하는 방법

「소스 코드가 사라진 십 년 된 업무 앱이 새 Windows 11 PC에서 시작되지 않습니다. 속성 대화상자의 호환성 탭에서 ‘Windows XP’에 체크했더니 그냥 돌아갔습니다. — 그게 실제로 무엇을 하는 건가요? 계속 이것에 기대도 되나요?」 자주 받는 상담입니다.

체크박스 하나로 동작하면, 오히려 불안해지는 것이 자연스럽습니다. 마법처럼 보이는 호환성 모드의 진짜 정체는 앱과 Windows API 사이에 끼어들어 「거짓말」을 돌려주는 심(shim) 이라는 작은 코드 조각들의 모임입니다. Windows 자신도 여러 세대 전의 앱을 돌리기 위해 이 응급처치를 대규모로 쓰고, 그 메커니즘의 일부를 사용자와 관리자에게 열어 둡니다.

메커니즘을 모른 채 쓰면, 수명 연장은 「왜 도는지 모르니 건드리면 안 된다」는 불안정한 상태가 됩니다. 메커니즘을 이해하면 어디까지 안심하고 기댈 수 있는지, 무엇이 깨뜨리는지, 언제 다시 만들어야 하는지를 이유로 결정할 수 있습니다.

flowchart TB
    accTitle: 메커니즘을 이해하면 수명 연장의 질이 달라진다
    accDescr: 메커니즘을 모른 채 호환성 모드를 쓰면 건드리지 못하는 불안정한 수명 연장이 되고, 이해한 뒤에는 어디까지 기댈지, 무엇이 깨뜨리는지, 언제 다시 만들지를 이유로 결정할 수 있다
    unknown["메커니즘을 모른 채 사용"] --> fear["건드리지 못하는 불안정한 수명 연장"]
    known["메커니즘을 이해한 뒤 사용"] --> judge["이유가 있는 판단"]
    judge -.-> j1["어디까지 기댈 수 있는가"]
    judge -.-> j2["무엇이 깨뜨리는가"]
    judge -.-> j3["언제 다시 만들어야 하는가"]

그림 1: 같은 수명 연장이라도, 메커니즘을 몰라 생기는 불안과 이해에 근거한 판단은 질이 다릅니다.

중소기업의 IT 담당자와 오래된 업무 앱을 맡는 Windows 앱 개발자를 대상으로, 이 글은 Microsoft Learn 1차 자료를 바탕으로 호환성 모드의 진짜 정체인 심의 메커니즘, 대표 심이 할 수 있는 일, Compatibility Administrator로 조직에 적용하는 방법, 심이 구하지 못하는 한계, 수명 연장과 이전 사이의 판단까지 정리합니다.

1. 먼저 결론

• 호환성 모드의 진짜 정체는 심(호환 레이어)입니다. 호환성 탭의 설정은 HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers에 쓰이고, 시작 때 그 프로세스에 심의 묶음이 적용됩니다.¹²
• 심은 가져오기 주소 테이블(IAT)을 다시 쓰는 사용자 모드 API 훅입니다. 앱이 Windows API를 부르는 경로를 가로채 옛 Windows가 주었을 답을 돌려줍니다. OS 자체를 바꾸지 않습니다.³
• 심이 할 수 있는 일의 범위는 앱 쪽 코드 수정이 할 수 있는 일과 같습니다. 보안 메커니즘을 우회하지 못하고, 커널 모드(장치 드라이버) 문제도 고치지 못합니다.³
• Microsoft는 미리 만든 심을 대량으로 제공합니다 — 버전 거짓말, 파일 경로 재매핑, 레지스트리 위장, 관리자 검사 위장 등. Compatibility Administrator에서 개별 EXE에 적용할 수 있습니다.⁴
• Windows 자신도 기본적으로 심을 씁니다. OS 표준 호환성 데이터베이스(.sdb)가 모든 실행에서 대조되고, PCA(Program Compatibility Assistant)가 문제를 감지해 호환 설정을 자동으로 적용하기도 합니다.¹⁵
• 「옛 Windows인 것처럼 답하는 것」이 지금은 기본입니다. Windows 8.1부터 GetVersionEx는 앱이 매니페스트에 선언하지 않은 OS 버전을 돌려주지 않습니다. 호환성 모드는 그 메커니즘의 연장입니다.⁶⁷
• 심은 16비트 앱, 커널 드라이버 의존, 직접 하드웨어 접근에는 통하지 않습니다. 특히 16비트 앱은 64비트 Windows에서 아예 실행되지 않습니다.⁸
• 「관리자를 요구하지만 실제로는 필요 없는」 앱에는 RunAsInvoker가 정석입니다. __COMPAT_LAYER=RunAsInvoker는 권한 상승 요청을 억제하고 일반 권한으로 돌립니다.⁹
• 심 아래에서 돈다는 것은 당장은 수명 연장할 수 있다는 뜻이지, 본래의 길은 「심 없이 돌게 만드는 것」입니다. 수명 연장을 결정했다면, 어떤 심으로 도는지 기록하고 재작성 판단의 재료로 관리하십시오.

2. 애플리케이션 호환성의 큰 그림 ── Windows가 이미 가진 하위 호환 층

심을 말하기 전에, Windows가 오래된 앱을 위해 이미 가진 메커니즘을 나열합니다. 「호환성 모드에서 돌아가기 시작했다」고 해도, 실제로 앱을 구하는 것은 이 층 중 하나이거나 여럿의 조합입니다.

UAC 가상화는 매니페스트가 없는 32비트 대화형 프로세스에 적용되는 과도기 조치이며, Microsoft 자신도 「향후 Windows 버전에서 제거하려는 임시 기술」이라고 말합니다.¹⁰ Wow6432Node 리다이렉트와 VirtualStore가 실제로 일으키는 피해와 대처는 「레지스트리의 32bit/64bit 리다이렉트와 가상화의 함정 ── Wow6432Node와 ‘분명히 썼는데 값이 없다’ 문제」에서 자세히 다루므로, 이 글은 심을 중심에 두고 다른 층은 필요한 만큼만 언급합니다.

flowchart TB
    accTitle: UAC 가상화가 놓인 위치
    accDescr: UAC 가상화는 매니페스트가 없는 32비트 대화형 프로세스를 위한 과도기 조치로, 쓰기를 사용자별 VirtualStore로 리다이렉트하지만, Microsoft 자신은 향후 Windows에서 제거하려는 임시 기술이라고 말한다
    proc["매니페스트 없는 32비트 대화형 프로세스"] --> uacv["UAC 가상화가 적용됨"]
    uacv --> vs["사용자별 VirtualStore로 리다이렉트"]
    uacv -.-> tmp["향후 제거를 전제로 한 임시 기술"]

그림 2: UAC 가상화는 매니페스트 없는 32비트 프로세스를 위한 과도기 조치이며, 영구히 기댈 수 없습니다.

DPI 가상화에 대한 곁가지입니다. DPI 인식을 선언하지 않은 앱은 96 DPI(100%)로 그리는 것으로 취급되고, Windows가 표시를 위해 비트맵을 늘립니다. 고 DPI 모니터에서 옛 앱이 「흐릿해」 보이는 이유이며, 호환성 탭의 「높은 DPI 배율 동작 재정의」가 이 가상화 동작을 바꾸는 스위치입니다.¹¹

flowchart TB
    accTitle: DPI 가상화가 동작하는 방식
    accDescr: DPI 인식을 선언하지 않은 앱은 96 DPI로 그리는 것으로 취급되고, Windows가 비트맵을 늘려 흐릿하게 보이며, 호환성 탭의 고 DPI 설정 재정의가 이 가상화 동작을 전환한다
    app["DPI 인식을 선언하지 않은 앱"] --> treat["96 DPI로 그리는 것으로 취급"]
    treat --> stretch["표시를 위해 비트맵이 늘어남"]
    stretch --> blur["고 DPI 모니터에서 흐릿해 보임"]
    tab["높은 DPI 배율 동작 재정의"] -.->|가상화 동작을 전환| treat

그림 3: DPI를 인식하지 않는 앱은 96 DPI로 취급되어 늘어나고, 호환성 탭의 재정의가 이 가상화의 스위치입니다.

3. 심의 진짜 정체 ── IAT를 다시 써서 API 사이에 끼어들기

3.1. 앱과 OS 사이에 서는 「통역」

Windows 실행 파일(PE 형식)은 가져오기 주소 테이블(IAT) 을 통해 외부 DLL의 API를 호출합니다. 앱이 GetVersionEx를 부를 때, 하는 일은 IAT에 적힌 주소로 점프하는 것뿐입니다. 심 메커니즘은 그것을 이용합니다. 로드 시점에 대상 API의 IAT 항목을 심 코드의 주소로 다시 쓰고, 앱과 Windows 사이에 자신을 끼워 넣습니다. GetProcAddress로 동적으로 얻은 API는 GetProcAddress 자체를 훅해 처리합니다.³

가로챈 뒤, 심은 「현재 OS 버전이 무엇인가」에 옛 버전 번호를 돌려주거나, 쓸 수 없는 위치의 파일 접근을 다른 곳으로 재매핑한 뒤, 필요하면 진짜 API를 호출합니다. 앱 쪽에서는 「옛 Windows에서 도는 것」처럼 보이고, OS 쪽에서는 「잘 행동하는 앱이 도는 것」처럼 보입니다 — 심이 둘 사이의 통역입니다.

flowchart TB
    accTitle: 심이 API 호출을 가로채는 경로
    accDescr: 앱의 API 호출은 IAT를 지나며, 로드 시 IAT 항목을 심으로 다시 쓰면 심이 가로채 옛 Windows가 주었을 응답을 위장한 뒤 필요하면 진짜 API를 호출한다
    app["앱"] -->|API 호출| iat["IAT 항목"]
    iat -->|로드 시 심으로 다시 씀| shim["심（통역）"]
    shim -->|필요하면| api["진짜 Windows API"]
    shim -.-> lie["옛 Windows가 주었을 응답을 위장"]
    gpa["GetProcAddress로 호출"] -.->|훅으로 처리| shim

그림 4: 심은 앱과 Windows API 사이를 가로챕니다. 다시 쓰는 것은 앱 쪽 IAT이며, OS 자체는 바뀌지 않습니다.

이 설계에서 중요한 성질 세 가지가 나옵니다.³

1. 심은 앱 쪽 코드로 실행됩니다. OS의 일부가 아니므로, 앱과 같은 보안 제약을 받습니다. 심은 OS 보안 메커니즘을 우회하지 못하며, 심을 쓰기 위해 보안 설정을 느슨하게 할 필요도 없습니다.
2. 심이 고칠 수 있는 것은 앱 쪽 코드 수정도 고칠 수 있습니다. 심은 「소스가 없다 / 고칠 수 없다」는 경우의 대체물이지, 코드 수정보다 더 강력하지 않습니다.
3. 사용자 모드만. 커널 모드에서 도는 장치 드라이버의 호환 문제는 심으로 고칠 수 없습니다.

3.2. 심 데이터베이스(.sdb)와 대조

「어느 EXE에 어느 심을 적용할지」의 대응표가 심 데이터베이스이며, .sdb 확장자의 바이너리 파일입니다. 대상 앱 실행 파일은 파일 이름, 크기, 체크섬, 버전 같은 속성(대조 속성)으로 데이터베이스에 등록되고, 프로세스 시작 때 대조됩니다. 처방에는 API 훅을 주입하는 Appfix(심)와 「이 앱에 호환 문제가 있다」는 메시지를 표시하는 Apphelp가 있습니다. 여러 심과 플래그의 묶음이 호환 레이어(호환성 모드) 입니다.¹

놓치기 쉬운 점: 이 대조는 호환성 모드가 설정된 앱뿐 아니라 모든 프로세스 시작에서 돌아갑니다. Windows는 수천 개의 알려진 앱에 대한 수정이 담긴 OS 표준 데이터베이스를 제공하고(파일은 %WINDIR%\AppPatch 아래), 지금 그 PC에서도 어떤 옛 앱은 아무도 모르게 심이 붙은 채 시작하고 있을 가능성이 큽니다. Microsoft가 제공하는 호환성 수정은 Windows의 일부로 제공되며 Windows Update로 갱신됩니다.³

flowchart TB
    accTitle: 프로세스 시작 때 심 데이터베이스 대조
    accDescr: 모든 프로세스 시작이 심 데이터베이스와 대조되며, 대조 속성이 등록과 맞으면 Appfix가 심을 주입하거나 Apphelp가 메시지를 표시하고, 아니면 그대로 시작한다
    start["프로세스 시작"] --> db[".sdb와 대조"]
    db -.-> attr["파일 이름, 크기 등"]
    db --> hit{"등록이 있는가?"}
    hit -->|예| appfix["Appfix: 심 주입"]
    hit -->|예| apphelp["Apphelp: 메시지"]
    hit -->|아니오| plain["그대로 시작"]
    layer["호환 레이어"] -.->|여러 심과 플래그의 묶음| appfix

그림 5: 대조는 호환성 모드가 설정된 앱뿐 아니라 모든 프로세스 시작에서 돌아갑니다.

3.3. PCA ── 심을 자동으로 적용하는 메커니즘

관리자가 의도하지 않았는데도 심이 적용되는 또 다른 경로가 PCA(Program Compatibility Assistant)입니다. PCA는 앱 실행을 감시하고, 알려진 호환 문제의 징후를 감지하면 사용자에게 수정을 적용하자고 제안하거나, 어떤 경우에는 호환 설정을 자동으로 적용합니다. 예를 들어 해제된 DLL 안의 코드를 호출해 크래시하는 앱에는 PINDLL이, 보호된 Windows 파일에 쓰기가 실패하는 앱에는 WRPMITIGATION이 할당됩니다.⁵

flowchart TB
    accTitle: PCA가 호환 설정을 자동으로 적용하는 방식
    accDescr: PCA는 앱 실행을 감시하고, 알려진 호환 문제의 징후를 감지하면 사용자에게 수정을 제안하거나, 어떤 경우에는 호환 설정을 자동으로 적용한다
    run["앱 실행"] --> pca["PCA가 감시"]
    pca --> sign{"알려진 문제의 징후?"}
    sign -->|예| resp{"어느 경우인가?"}
    resp -->|제안으로 처리| suggest["수정 적용을 제안"]
    resp -->|어떤 경우| auto["호환 설정을 자동 적용"]
    sign -->|아니오| none["그대로 실행"]
    auto -.-> ex["예: PINDLL 또는 WRPMITIGATION"]

그림 6: PCA는 앱 실행을 감시하고, 알려진 문제의 징후를 감지하면 수정을 제안하거나 자동으로 적용합니다.

「아무것도 설정하지 않았는데 어느 순간 호환성 모드 체크박스가 켜져 있었다」의 정체는, 많은 경우 이것입니다. 고장도 오클릭도 아니며, Windows가 설계대로 동작한 것입니다.

4. 대표 심이 할 수 있는 일

Microsoft가 공개한 미리 만든 심 가운데, 업무 앱을 수명 연장할 때 실제로 자주 나오는 것을 고릅니다.⁴

목록을 보면, 대부분의 심은 「옛 앱이 기대하는 답을 돌려주는 거짓말」 입니다. 디스크는 최대 2GB, OS는 XP, 당신은 관리자 — 그 프로세스 안에서만, 앱이 태어난 시대의 세계관을 재현합니다.

버전 위장은 「공식 기본 동작」이 되었다

버전 위장은 특별한 해킹이 아닙니다. Windows 8.1부터 GetVersionEx가 돌려주는 값은 앱의 매니페스트에 달려 있습니다. 매니페스트의 <compatibility> 절에 <supportedOS> 선언이 없는 앱은, 실제 OS가 무엇이든 항상 Windows 8 상당(6.2)을 받습니다. 선언이 있으면 선언된 것 중 가장 높은 OS까지의 값이 반환됩니다(예를 들어 Windows 8.1 GUID까지 선언했다면 Windows 11에서도 6.3을 받습니다).⁶⁷

따라서 「앱이 보는 Windows 버전」은 이렇게 쌓인 단계에서 결정됩니다.

1. 매니페스트에 선언된 OS까지의 값이 반환된다(선언이 없으면 6.2)
2. 호환성 모드(VersionLie 계열 심)가 적용되면, 선택한 OS의 버전이 반환된다⁶

flowchart TB
    accTitle: 앱이 보는 OS 버전이 결정되는 방식
    accDescr: GetVersionEx가 돌려주는 값은 매니페스트의 supportedOS 선언 여부로 결정되며, 선언이 없으면 Windows 8 상당 6.2, 있으면 가장 높은 선언 OS까지의 값이 반환되고, VersionLie 계열 심이 적용되면 선택한 OS 버전으로 덮어쓴다
    q["GetVersionEx 조회"] --> m{"supportedOS 선언이 있는가?"}
    m -->|아니오| v62["Windows 8 상당（6.2）이 반환됨"]
    m -->|예| decl["가장 높은 선언 OS까지의 값"]
    v62 --> lie{"VersionLie 계열 심이 적용되었는가?"}
    decl --> lie
    lie -->|예| fake["호환성 모드에서 고른 OS 값"]
    lie -->|아니오| asis["값이 그대로 반환됨"]

그림 7: 앱이 보는 Windows 버전은 매니페스트와 심이 쌓인 단계에서 결정됩니다.

사내 앱이 「OS 버전으로 분기하는데, Windows 11인데도 이상하게 8로 판정된다」면, 먼저 매니페스트의 supportedOS 선언을 의심하십시오. 반대로 말하면, 버전 검사로 시작을 거부하는 옛 앱은 VersionLie 심으로 높은 확률로 통과시킬 수 있습니다. 많은 경우 버전 숫자만 보고 있고, 실제 동작은 더 새 OS에서도 문제없습니다.

flowchart TB
    accTitle: 버전으로 인한 두 증상과 대처
    accDescr: 사내 앱이 Windows 11인데도 8로 판정되면 매니페스트의 supportedOS 선언을 의심하고, 버전 검사로 시작을 거부하는 옛 앱은 VersionLie 심으로 높은 확률로 통과시킬 수 있다
    sym1["Windows 11인데도 8로 판정됨"] --> fix1["supportedOS 선언을 의심"]
    sym2["버전 검사로 시작 거부"] --> fix2["VersionLie로 통과를 시도"]
    fix2 -.-> why["실제 동작은 더 새 OS에서도 종종 괜찮음"]

그림 8: 판정이 낡았으면 매니페스트를, 시작이 거부되면 VersionLie를 의심하십시오.

5. 호환성 모드 체크박스가 하는 일

속성 → 호환성 탭의 설정은 레지스트리의 AppCompatFlags\Layers 키에 저장됩니다. DXGI 앱 호환 설정 등도 같은 키를 호환 레이어를 지정하는 장소로 씁니다.² 실제로 봅시다.

reg query "HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers"

호환성 탭에서 「Windows XP (Service Pack 3)」, 「이 프로그램을 관리자로 실행」, 「높은 DPI 배율 동작 재정의」를 설정한 EXE에는 다음과 같은 값이 보입니다.

HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers
    C:\LegacyApp\Gyomu.exe    REG_SZ    ~ WINXPSP3 RUNASADMIN HIGHDPIAWARE

체크박스 항목과 값의 대표 대응(Windows 11에서 확인. 항목 이름과 값은 OS 버전에 따라 바뀔 수 있음).

기억할 세 가지.

• 「이 프로그램을 관리자로 실행」도 같은 곳에 쓰입니다. 호환성 모드와 상승 플래그는 같은 Layers 키에 함께 살고, 「호환성 모드를 설정했더니 상승이 따라왔다 / 사라졌다」는 혼란이 거기서 생깁니다. 값을 직접 보면 둘이 갈라집니다.
• HKCU에 쓰인 것은 「그 사용자의 설정」입니다. 탭의 「모든 사용자에 대한 설정 변경」에서 설정하면 HKLM 쪽 같은 이름 키에 쓰여 모든 사용자에게 적용됩니다. 이미징으로 배포할 때는 어느 쪽에 쓰는지 의식하십시오.
• 체크박스는 미리 만든 레이어의 입구일 뿐입니다. 탭에서는 대표 레이어만 고를 수 있고, 개별 심을 골라 조합할 수는 없습니다. 그것이 다음 장의 Compatibility Administrator가 하는 일입니다.

flowchart TB
    accTitle: 호환성 탭 설정이 효력을 갖기까지의 경로
    accDescr: 호환성 탭 설정은 AppCompatFlags Layers 키에 EXE 경로와 값으로 저장되고, 다음에 그 EXE가 시작될 때 로더가 값을 읽어 대응하는 호환 레이어를 프로세스에 적용한다
    tab["호환성 탭에서 설정"] --> reg["Layers 키에 EXE 경로와 값을 저장"]
    reg --> boot["다음 EXE 시작"]
    boot --> loader["로더가 값을 읽음"]
    loader --> apply["호환 레이어를 프로세스에 적용"]
    reg -.-> hkcu["HKCU는 그 사용자만"]
    reg -.-> hklm["HKLM은 모든 사용자에게 적용"]

그림 9: 체크박스는 실제로는 Layers 키에 쓰는 일이며, 적용은 다음 시작에서 일어납니다.

6. Compatibility Administrator의 실무 ── 사용자 지정 .sdb를 만들어 배포하기

6.1. 구하는 방법과 주의점

Compatibility Administrator는 Windows ADK(Windows Assessment and Deployment Kit)에 포함된 도구입니다.¹² 설치 후 32비트와 64비트 판이 모두 있고, 32비트 앱에는 32비트 판을, 64비트 앱에는 64비트 판을 써야 합니다.¹³

또 하나의 중요한 주의점. Compatibility Administrator를 상승된 상태(관리자)로 시작해 테스트하면, UAC 가상화와 리다이렉트가 실제 사용자와 다르게 동작해 「고쳐졌다」고 오판할 수 있습니다. 수정의 효과는 반드시 실제 사용자와 같은 계정·권한으로 확인하십시오.⁴

flowchart TB
    accTitle: Compatibility Administrator를 쓸 때의 두 주의점
    accDescr: 32비트 앱에는 32비트 판을, 64비트 앱에는 64비트 판을 쓰고, 수정의 효과는 상승된 상태가 아니라 실제 사용자와 같은 계정·권한으로 확인한다
    app32["32비트 앱"] --> tool32["32비트 판을 사용"]
    app64["64비트 앱"] --> tool64["64비트 판을 사용"]
    elev["상승된 상태로 테스트"] -.-> wrong["수정을 오판할 수 있음"]
    user["실제 사용자와 같은 권한으로 테스트"] --> ok["효과를 확인"]

그림 10: 32비트/64비트 판을 고르는 것과, 실제 사용자와 같은 권한으로 확인하는 것이 입구의 주의점입니다.

6.2. 사용자 지정 호환성 데이터베이스를 만드는 절차

개요는 다음과 같습니다.¹⁴

1. Compatibility Administrator 왼쪽 창의 「Custom Databases」에서 새 데이터베이스를 만들고 「Create New」→「Application Fix」를 고릅니다
2. 앱 이름과 공급자 이름을 입력하고, 대상 EXE 파일을 지정합니다
3. 적용할 호환성 모드(레이어)를 고릅니다 — 먼저 「Windows XP 호환」 같은 묶음을 시도하는 것이 지름길입니다
4. 필요하면 개별 호환성 수정(심)을 추가합니다 — VersionLie만, CorrectFilePaths만 같은 최소 집합으로 좁힐 수 있습니다
5. 대조 조건(파일 크기, 체크섬, 버전 등)을 확인하고 저장합니다

대조 조건이 「이 EXE에만 적용한다」의 열쇠입니다. 기본 조건으로 보통 충분하지만, 앱 버전을 식별할 수 있는 조건을 남기는 것을 권합니다. 공급자가 나중에 고친 판을 내놓았을 때, 옛 거짓말이 새 버전에도 계속 적용되는 사고를 막습니다.¹⁴¹⁵

flowchart TB
    accTitle: 사용자 지정 호환성 데이터베이스를 만드는 절차
    accDescr: 새 데이터베이스에서 Application Fix를 만들고, 앱 이름과 대상 EXE를 지정한 뒤, 먼저 호환성 모드 묶음을 시도하고 필요하면 개별 심으로 좁힌 다음, 대조 조건을 확인하고 저장한다
    new["새 데이터베이스를 만듦"] --> fix["Application Fix를 고름"]
    fix --> info["앱 이름과 대상 EXE를 지정"]
    info --> layer["호환성 모드 묶음을 시도"]
    layer --> single["필요하면 개별 심으로 좁힘"]
    single --> match["대조 조건을 확인하고 저장"]
    match -.-> ver["버전을 식별하는 조건을 남김"]

그림 11: Application Fix에서는 먼저 호환성 모드 묶음을 시도하고, 최소 집합으로 좁힌 뒤, 대조 조건으로 대상을 한정합니다.

만든 .sdb는 먼저 검증 머신에서 시험합니다. 의도대로 동작하면 조직에 전개합니다.

6.3. sdbinst로 배포하기

사용자 지정 .sdb를 각 PC에 적용하는 명령은 sdbinst.exe입니다(관리자 권한 필요).¹⁵

:: Install (-q is silent with no confirmation)
sdbinst -q "C:\Deploy\MyCorpFixes.sdb"

:: Uninstall (by file)
sdbinst -q -u "C:\Deploy\MyCorpFixes.sdb"

:: Uninstall (by database GUID)
sdbinst -q -u -g {database GUID}

조직 배포 전략으로 Microsoft는 앱 설치 프로그램마다 별도의 .sdb를 실어 보내는 대신, 회사 전체(또는 부서별) 사용자 지정 데이터베이스 하나로 모아 중앙에서 관리하는 것을 권합니다. 수정이 늘어날수록, 한 줄짜리 데이터베이스를 많이 배포하는 것보다 하나를 갱신·재배포하는 편이 쉽습니다. 사용자 지정 데이터베이스는 고유 GUID를 가지며, 같은 GUID로 새 버전을 설치하면 옛 버전이 자동으로 교체되므로 갱신 작업도 단순합니다. 배포 자체는 MSI로 패키징하거나 시작 스크립트처럼 관리자 권한으로 돌릴 수 있는 기존 경로에 태우십시오.¹⁵

flowchart TB
    accTitle: 사용자 지정 .sdb를 만들어 배포하기까지의 경로
    accDescr: Compatibility Administrator에서 사용자 지정 호환성 데이터베이스를 만들고, 검증 머신에서 시험한 뒤, sdbinst로 각 PC에 적용하고, 갱신 때는 같은 GUID로 새 버전을 설치해 옛 버전이 자동으로 교체되게 한다
    make["Compatibility Administrator에서 작성"] --> test["검증 머신에서 시험"]
    test --> deploy["sdbinst로 각 PC에 적용"]
    deploy --> update["같은 GUID로 새 버전을 설치"]
    update -.-> replace["옛 버전이 자동으로 교체됨"]
    deploy -.-> inv["프로그램 및 기능에 등록됨"]

그림 12: 사용자 지정 .sdb는 작성, 검증, sdbinst 배포를 거쳐 전개되고, 갱신은 GUID로 관리합니다.

설치된 사용자 지정 데이터베이스는 「프로그램 및 기능(설치된 앱)」의 항목으로 등록되므로, 재고와 제거도 거기서 확인할 수 있습니다. 어느 PC에 어느 .sdb가 있는지는 자산 관리 대장에 올릴 정보입니다.

7. 통하지 않는 경우와 한계

심은 만능이 아닙니다. 설계상 다음 경우에는 통하지 않습니다.

• 커널 모드 문제. 심은 사용자 모드 프로세스 안에서 도므로, 장치 드라이버 비호환은 고칠 수 없습니다. 옛 계측기, USB 동글, 프린터의 드라이버가 Windows 11을 지원하지 않으면, 앱 쪽에 무엇을 적용해도 해결되지 않습니다. 백신 소프트웨어의 일부처럼 커널에서 도는 코드도 같습니다.³
• 16비트 앱. 64비트 Windows는 16비트 앱 실행을 지원하지 않습니다. 핸들은 64비트 Windows에서 유효 비트가 32개라 16비트 앱에 잘라 넘길 수 없어, 시작이 ERROR_BAD_EXE_FORMAT로 실패합니다.⁸ 앱 자체는 32비트여도, 그 시대 패키지 중 설치 프로그램 스텁이 16비트인 것이 있어, 「앱은 돌 텐데 설치를 못 한다」로 나타납니다.
• 직접 하드웨어 접근. I/O 포트나 물리 메모리를 직접 만질 수 있다고 전제하는 산업용 앱은, 현대 Windows의 사용자 모드에서는 애초에 허용되지 않으며, 심이 위장할 수 있는 범위를 넘습니다.
• 보안 메커니즘 우회. 심은 앱과 같은 보안 제약 아래에서 도므로, 「권한이 없어 할 수 없는 일」을 가능하게 만들지 못합니다. ForceAdminAccess와 WRPMitigation은 검사나 쓰기의 성공을 위장해 앱이 진행하게 할 뿐이며, 보호된 자원을 실제로 다시 쓰는 것이 아닙니다.³⁴
• 자체 무결성을 검사하는 앱. 옛 복사 방지나 변조 탐지가 있는 앱은 API 훅 자체를 이상으로 보고 동작을 멈출 수 있습니다.

flowchart TB
    accTitle: 심이 통하지 않는 경우
    accDescr: 심은 사용자 모드 프로세스 안에서 도므로, 커널 모드 드라이버 문제, 16비트 앱, 직접 하드웨어 접근, 보안 메커니즘 우회에는 통하지 않는다
    shim["심（사용자 모드에서 실행）"] -->|통하지 않음| drv["커널 드라이버"]
    shim -->|통하지 않음| b16["16비트 앱"]
    shim -->|통하지 않음| hw["직접 하드웨어 접근"]
    shim -->|통하지 않음| sec["보안 메커니즘 우회"]
    b16 -.-> fmt["64비트에서는 시작 자체가 실패"]
    sec -.-> fake["앱이 진행하도록 성공만 위장"]

그림 13: 심은 사용자 모드뿐이며, 커널, 16비트 앱, 직접 하드웨어 접근, 보안 우회에는 닿지 않습니다.

그리고 모든 심에 공통인 본질적 한계는 응급처치라는 점입니다. 심은 특정 API의 특정 쓰임새에 맞춘 거짓말이고, OS 쪽 구현이 바뀌면 전제가 무너집니다. Microsoft가 제공하는 심은 Windows Update를 통해 Windows의 일부로 유지되지만,³ 사용자 지정 데이터베이스로 적용한 거짓말을 돌보는 일은 조직의 몫입니다. 기능 업데이트마다 「심으로 수명 연장 중인 앱 목록」을 검증하는 운용을 수명 연장의 비용으로 잡으십시오.

flowchart TB
    accTitle: 응급처치로서의 심, 그리고 유지 책임은 누구에게 있는가
    accDescr: 심은 특정 API 쓰임새에 맞춘 거짓말이고 OS 쪽 구현이 바뀌면 전제가 무너지며, Microsoft 제공 심은 Windows Update로 유지되지만, 사용자 지정 데이터베이스로 적용한 거짓말은 조직이 돌보고, 기능 업데이트마다의 검증이 수명 연장 비용이다
    shim["심 = 응급처치 거짓말"] --> break["OS 변경이 깨뜨림"]
    ms["Microsoft 심"] --> wu["Windows Update를 통해"]
    own["사용자 지정 데이터베이스의 거짓말"] --> self["조직이 돌봄"]
    self --> cost["업데이트마다 검증이 수명 연장 비용"]

그림 14: 심 거짓말을 유지하는 책임은 Microsoft 제공 집합과 조직의 사용자 지정 집합으로 나뉩니다.

8. RunAsInvoker의 실무 가치 ── 권한 상승 요청만 잠재우기

심 가운데 일상 IT 업무에서 가장 자주 나오는 것이 RunAsInvoker입니다.

일부 옛 업무 앱은 매니페스트에 requireAdministrator를 선언하거나, EXE 이름이나 내용으로 설치 프로그램으로 오탐되어, 시작할 때마다 UAC 상승을 요청합니다. 그중 상당수는 XP 시대의 관성으로 관리자를 요구할 뿐, 실제로 관리자 권한을 쓰지 않습니다. RunAsInvoker 심을 적용하면 설치 프로그램 탐지와 매니페스트를 모두 덮어쓰고, 앱은 부모 프로세스에서 상속한 토큰(= 일반 사용자 권한)으로 시작됩니다.⁹

flowchart TB
    accTitle: RunAsInvoker가 권한 상승 요청을 억제하는 방식
    accDescr: 매니페스트의 requireAdministrator 선언이나 설치 프로그램 오탐이 시작 때 UAC 상승 요청을 일으키지만, RunAsInvoker를 적용하면 둘을 덮어쓰고 앱은 부모에서 상속한 토큰으로 시작한다
    manifest["requireAdministrator 선언"] --> shim{"RunAsInvoker가 적용되었는가?"}
    detect["설치 프로그램으로 오탐됨"] --> shim
    shim -->|아니오| uac["시작할 때마다 UAC 상승 요청"]
    shim -->|예| token["부모의 토큰으로 시작"]
    token -.-> limit["정말로 관리자가 필요한 작업은 앱 안에서 실패"]

그림 15: RunAsInvoker는 권한 상승 요청의 원인만 덮어씁니다. 권한이 늘어나지는 않습니다.

Compatibility Administrator에서 .sdb를 만들지 않아도, __COMPAT_LAYER 환경 변수로 같은 레이어를 일시적으로 적용할 수 있습니다.

:: Apply RunAsInvoker to child processes started from this command prompt
set __COMPAT_LAYER=RunAsInvoker
start "" "C:\LegacyApp\Gyomu.exe"

# In PowerShell
$env:__COMPAT_LAYER = 'RunAsInvoker'
Start-Process 'C:\LegacyApp\Gyomu.exe'

이 두 줄을 배치 파일로 만들어 바로 가기로 배포하면, 일반 사용자에게 로컬 관리자 권한을 넘기지 않을 수 있고, UAC 암호 때문에 IT가 매번 불리지 않습니다. 최소 권한에 맞추어 방어를 단단히 하는 호환 기법입니다.

flowchart TB
    accTitle: RunAsInvoker 배치를 배포하는 효과
    accDescr: RunAsInvoker를 설정하는 두 줄 배치를 바로 가기로 배포하면, 일반 사용자에게 로컬 관리자 권한을 넘기지 않을 수 있고, UAC 암호로 IT가 불리지 않으며, 운용이 최소 권한을 따른다
    bat["두 줄 배치를 배포"] --> noadmin["관리자 권한을 넘기지 않을 수 있음"]
    bat --> nocall["UAC로 IT가 불리지 않음"]
    noadmin --> lp["최소 권한을 따르는 운용"]
    nocall --> lp

그림 16: 배치만 배포해도 관리자 권한 배포와 UAC 호출을 모두 줄일 수 있습니다.

주의점도 분명히.

• 권한이 늘어나지 않습니다. 정말로 관리자 권한이 필요한 작업(HKLM 쓰기, Program Files 아래 갱신 등)은 앱 안에서 오류가 나거나, 조건이 맞으면 UAC 가상화가 VirtualStore로 리다이렉트합니다.¹⁰ 설정 저장이 갑자기 「안 된다」면 가상화를 의심하십시오.
• 환경 변수 방식은 자식 프로세스에만 적용됩니다. 영구 적용에는 Layers 키에 직접 설정(탭에는 RUNASINVOKER 항목이 없음)하거나 .sdb로 배포하는 것이 확실합니다.
• 쓰기 대상을 고치는 것이 본래의 길입니다. 앱을 바꿀 수 있다면, 설정 파일을 %APPDATA% 아래로 옮기고 매니페스트에 asInvoker를 선언하는 것이 올바른 형태입니다.⁹

flowchart TB
    accTitle: RunAsInvoker의 일시 적용과 영구 적용
    accDescr: COMPAT_LAYER 환경 변수로 적용하면 거기서 시작한 자식 프로세스에만 적용되고, 영구 적용에는 Layers 키에 직접 설정하거나 .sdb로 배포한다
    env["환경 변수로 설정"] --> child["자식 프로세스에만 적용"]
    child -.-> tmp["일시 적용"]
    layers["Layers 키에 직접 설정"] --> always["영구 적용"]
    sdb["sdb로 배포"] --> always

그림 17: 환경 변수 방식은 자식 프로세스로 한정된 일시 적용이며, 영구화는 Layers 키나 .sdb로 합니다.

9. 수명 연장과 이전 사이의 판단 ── 심 아래에서 돈 뒤에 생각할 것

심 아래에서 도는 순간은 안도이지만, 거기서 생각을 멈추지 않는 것이 중요합니다. 심 아래에서 돈다는 것은 Windows가 준비한 받침대에 우연히 맞았다는 뜻일 뿐입니다. 판단의 축을 표로.

수명 연장을 결정했다면, 다음 세 가지를 세트로 운용에 넣으십시오.

1. 기록. 어느 EXE, 어느 심/레이어, 왜. Layers 키 값과 .sdb GUID를 대장에 남기십시오. 「왜 도는지 아무도 모른다」는 다음 사람에게 남기는 가장 큰 빚입니다. 「소스 코드도 사양서도 없는 시스템을 인계받았다면 ── 멈추지 않고 운용·보수하기 위한 실무 절차」에서 다룬 것과 같은 보존 사고입니다.
2. 검증. 심으로 수명 연장 중인 앱의 시작과 주요 조작을 Windows 기능 업데이트의 검증 항목에 넣으십시오. OS 교체 계획과도 묶으십시오(Windows 10 지원 종료 이후의 현실적 해법 ── ESU·LTSC·교체 판단표).
3. 기한을 정함. 수명 연장의 끝 — 「다음 기간계 개편까지」, 「2028년 3월까지」 — 를 정하고, 이전 검토를 병행하십시오.

flowchart TB
    accTitle: 수명 연장을 결정한 뒤의 3점 운용 세트
    accDescr: 어떤 심으로 도는지 대장에 기록하고, 기능 업데이트마다 심으로 수명 연장 중인 앱의 동작을 검증하며, 수명 연장의 끝을 기한으로 정하고 이전 검토를 병행한다
    decide["수명 연장을 결정"] --> rec["기록: 어떤 심으로 도는지 대장에"]
    rec --> verify["검증: 기능 업데이트마다 동작 확인"]
    verify --> deadline["기한: 수명 연장의 끝을 정함"]
    deadline --> mig["이전 검토를 병행"]

그림 18: 수명 연장은 기록, 검증, 기한의 3점 세트로 운용하며, 이전 검토를 병행하는 것도 포함합니다.

이전 쪽에서는, 표준 선택지가 앱의 기술에 따라 바뀝니다. VB6라면 「VB6 애플리케이션은 언제까지 동작할까 ── 런타임 지원 현황과 현실적인 .NET 이전 진행 방법」에서 정리한 전면 재작성, 자동 변환, 단계적 이전의 삼지선다. ActiveX/OCX 의존이라면 「ActiveX / OCX를 지금 어떻게 다룰 것인가 - 남길지・감쌀지・교체할지 판단표」의 유지 / 래핑 / 교체 판단표. 심을 건강하게 자리매김하는 방법은, 그 이전 프로젝트의 검토와 준비 기간이 안전하게 돌아가도록 시간을 사는 것입니다.

flowchart TB
    accTitle: 이전 쪽의 선택지, 그리고 심이 놓이는 자리
    accDescr: 표준 이전 선택지는 앱의 기술에 따라 바뀌며, VB6는 재작성·자동 변환·단계적 이전의 삼지선다, ActiveX 의존은 유지 / 래핑 / 교체 판단표가 적용되고, 심은 이전 프로젝트의 검토와 준비를 위한 시간을 사는 것으로 자리매김한다
    tech{"앱의 기술은 무엇인가?"} -->|VB6| vb["재작성, 자동 변환, 또는 단계적 이전"]
    tech -->|ActiveX 의존| ax["유지, 래핑, 또는 교체"]
    shim["심을 통한 수명 연장"] -.->|검토와 준비를 위한 시간을 삼| tech

그림 19: 표준 이전 선택지는 앱의 기술로 정해지고, 심은 그 검토를 위한 시간을 사는 것으로 자리매김합니다.

10. 정리

• 호환성 모드의 진짜 정체는 심입니다. 호환성 탭의 설정은 AppCompatFlags\Layers 키에 쓰이고, 시작 때 IAT 재기록을 통한 API 훅으로 프로세스에 주입됩니다.
• 심은 「옛 앱이 기대하는 답을 돌려주는 거짓말」의 모임입니다. 버전 위장, 경로 재매핑, 레지스트리 위장, 관리자 검사 위장 같은 미리 만든 심이 제공됩니다.
• Windows 자신도 기본적으로 많은 심을 쓰고, PCA가 자동으로 적용하기도 합니다. 호환성 모드에 기대는 것 자체가 OS의 공식 메커니즘을 타는 합리적인 선택입니다.
• 원칙적 한계는 사용자 모드뿐이며 보안 우회가 없다는 것이고, 커널 드라이버, 16비트 앱, 직접 하드웨어 접근은 구할 수 없습니다.
• 조직 전개는 Compatibility Administrator(Windows ADK)에서 사용자 지정 .sdb를 만들고 sdbinst로 배포하는 것입니다. 32비트/64비트 판 선택, 실제 사용자 계정으로의 시험, GUID로 갱신을 관리하는 것이 실무 포인트입니다.
• 「관리자를 요구하지만 실제로는 필요 없는」 앱은 __COMPAT_LAYER=RunAsInvoker로 일반 권한까지 내릴 수 있습니다. 권한을 나눠 주기보다 상승 요청을 잠재우는 방어 기법입니다.
• 심 아래에서 도는 것은 수명 연장이지 해결이 아닙니다. 무엇으로 도는지 기록하고, 기능 업데이트마다 검증하며, 이전이 병행되도록 기한을 정하는 — 그 3점 세트가 「호환성 모드에 기대기로 한다」는 판단에 포함됩니다.

다음에 옛 앱이 호환성 모드 체크박스 하나로 돌아가면, 다시 물으십시오. 「이 앱은 어떤 거짓말 덕분에 도는가? 그 거짓말은 언제까지 통할 것인가?」 답할 수 있다면, 수명 연장은 떳떳한 전략입니다.

관련 기사

• 레지스트리의 32bit/64bit 리다이렉트와 가상화의 함정 ── Wow6432Node와 ‘분명히 썼는데 값이 없다’ 문제
• VB6 애플리케이션은 언제까지 동작할까 ── 런타임 지원 현황과 현실적인 .NET 이전 진행 방법
• ActiveX / OCX를 지금 어떻게 다룰 것인가 - 남길지・감쌀지・교체할지 판단표
• Windows 10 지원 종료 이후의 현실적 해법 ── ESU·LTSC·교체 판단표
• 소스 코드도 사양서도 없는 시스템을 인계받았다면 ── 멈추지 않고 운용·보수하기 위한 실무 절차
• Windows 셸 통합의 현재 ── 바로 가기 메뉴, 파일 연결, Windows 11에서 바뀐 점

관련 상담 영역

합동회사 코무라소프트는 소스 코드가 없는 오래된 업무 앱의 동작을 조사하고 수명 연장을 설계하는 일(심과 호환성 모드 선정, 사용자 지정 .sdb 작성과 전개), Windows 11 이전을 위한 기존 앱의 호환성 검증, 수명 연장과 병행하는 재작성·이전 계획을 다룹니다. 「호환성 모드에서 돌아가기 시작했는데, 이대로 두어도 되나요?」 단계부터의 상담도 괜찮습니다.

• 기존 자산 활용 & 이관 지원
• Windows 앱 개발
• 기술 상담 & 설계 리뷰
• 문의하기

참고 링크

관련 기사

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

관련 토픽

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

이 주제와 연결되는 서비스

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

자주 묻는 질문

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

호환성 모드에 체크했더니 앱이 돌아갔습니다. 그대로 써도 되나요?

당장의 업무 연속이라는 뜻에서는 그대로 써도 됩니다. 호환성 모드의 실체는 심이라 불리는 사용자 모드 API 훅이며, OS가 공식적으로 제공하는 설정입니다. 다만 심은 앱을 고치지 않고 돌리기 위한 응급처치일 뿐이고, 다른 OS 업데이트가 전제를 바꾸면 다시 깨질 수 있습니다. 호환성 모드로 동작한다는 사실을 대장에 기록하고, 그 기록을 앱을 다시 만들 것인지 계획적으로 수명 연장할 것인지의 판단 재료로 다루십시오.

호환성 모드 체크박스는 실제로 무엇을 하나요?

속성 대화상자의 호환성 탭에서 설정을 저장하면, Windows는 대상 EXE 경로와 "WINXPSP3"나 "HIGHDPIAWARE" 같은 값을 HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers 키 아래에 씁니다. 다음에 그 EXE가 시작될 때 Windows 로더가 값을 읽고, 대응하는 호환 레이어(심의 묶음)를 프로세스에 적용합니다. 예를 들어 Windows XP 호환성 모드는 버전 조회 API에 옛 값을 돌려주어 OS 버전을 위장합니다. OS 자체를 바꾸는 것이 아니라, 그 프로세스에만 옛 Windows인 척 보여주는 것입니다.

16비트 시대 앱을 64비트 Windows의 호환성 모드로 돌릴 수 있나요?

없습니다. 64비트 Windows는 WOW64로 32비트 앱을 실행하지만, 16비트 앱 실행은 지원하지 않으며 시작을 시도하면 ERROR_BAD_EXE_FORMAT로 실패합니다. 심이 우회할 수 없는 아키텍처 제한입니다. 설치 프로그램 스텁만 16비트인 옛 패키지도 같은 이유로 실패합니다. 정말로 필요하다면 호환성 모드 밖, 예를 들어 32비트 Windows를 포함한 가상 머신을 봐야 합니다.

「관리자로 실행하지 않으면 시작되지 않는」 앱을 일반 사용자 계정으로 돌릴 수 있나요?

RunAsInvoker를 시도할 가치가 있습니다. 명령 프롬프트에서 set __COMPAT_LAYER=RunAsInvoker를 실행한 뒤 앱을 시작하면, requireAdministrator 매니페스트나 설치 프로그램 탐지로 인한 권한 상승 요청이 억제되고, 호출자와 같은(일반 사용자) 권한으로 앱이 시작됩니다. 관리자 권한을 요구만 하고 실제로 쓰지 않는 앱이라면, 이것만으로 일상 운용에서 상승을 빼낼 수 있습니다. 권한이 늘어나지는 않으므로, 정말로 관리자 권한이 필요한 작업은 앱 안에서 실패합니다. 동작을 확인한 뒤에 채택하십시오.

Compatibility Administrator는 어디서 받나요?

Windows ADK(Windows Assessment and Deployment Kit)에 포함되어 있습니다. Microsoft 사이트에서 ADK를 내려받고, 설치 때 Application Compatibility Tools 기능을 선택합니다. 32비트와 64비트 판이 모두 설치되며, 32비트 앱에는 32비트 판을, 64비트 앱에는 64비트 판을 써야 합니다. 만든 사용자 지정 호환성 데이터베이스(.sdb)는 각 PC에서 sdbinst 명령을 실행해 적용합니다.

저자 프로필

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

Go Komura

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

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