IE 모드 의존 시스템 탈피 가이드

1. 이 글을 한마디로

“IE 모드를 정식 운영으로 안전하게 쓰면서, 의존을 조금씩 줄여 최종적으로 IE 모드를 0으로 만든다” ── 이것이 현실적인 전략입니다. 폐기하기 전에, 먼저 제대로 관리합시다.

이 글에서 쓰는 용어

이후 반복해서 나오는 용어를 먼저 정리합니다.

이 글의 지식 맵

이 글은 Edge의 IE 모드가 지원이 종료된 IE11을 대신해 Trident(MSHTML) 엔진으로 구형 문서 모드와 ActiveX를 렌더링하는 구조임을 전제로, Enterprise Mode Site List와 중립 사이트를 올바르게 구성해 사이트 목록을 일원화해 관리하면서 안전하게 연명하는 방법을 정리합니다. 탈피의 실무상 최우선 후보는 점진적 리팩터링이며, 의존이 너무 깊어 분해할 수 없을 때의 최후 수단인 전면 리라이트보다 먼저 검토해야 한다고 합니다. WebView2는 ActiveX를 존치하는 용도가 아니라 OS 쪽 책임을 분리하는 데 쓰고, VDI/RemoteApp 격리는 바로 고칠 수 없는 업무의 일시적인 수용처로 두며, Windows 컨테이너는 연명 대상으로 권장되지 않습니다. 의존 현황 파악에는 Enterprise Site Discovery를, 현대화한 경로 검증에는 Playwright를 사용합니다.

flowchart LR
    accTitle: IE 모드 의존 탈피의 지식 맵
    accDescr: IE 모드가 Trident(MSHTML) 엔진에서 문서 모드와 ActiveX를 다루는 구조와, 사이트 목록 및 중립 사이트를 통한 안전한 연명, 점진적 리팩터링을 중심으로 한 여러 탈피 패턴의 대응 관계를 보여주는 그림
    ie_mode["IE 모드"]
    ie_mode_dependency["IE 모드 의존"]
    trident_mshtml_engine["Trident(MSHTML) 엔진"]
    ie11_desktop_app["IE11 데스크톱 앱"]
    document_mode["문서 모드(Document Mode)"]
    activex["ActiveX"]
    enterprise_mode_site_list["Enterprise Mode Site List(사이트 목록)"]
    neutral_site["뉴트럴 사이트(Neutral Site)"]
    sso_auth_failure["SSO 인증 실패(리다이렉트 루프)"]
    cloud_site_list_management["Cloud Site List Management"]
    staged_refactoring["단계적 리팩터링"]
    full_rewrite["전면 리라이트"]
    vdi_remoteapp_isolation["VDI/RemoteApp 격리"]
    micro_frontend["마이크로 프론트엔드"]
    windows_containers["Windows 컨테이너"]
    webview2["Microsoft Edge WebView2"]
    enterprise_site_discovery["Enterprise Site Discovery"]
    app_assure["App Assure"]
    extended_stable_channel["Extended Stable(업데이트 채널)"]
    security_compliance_toolkit["Security Compliance Toolkit"]
    playwright["Playwright"]
    ie_mode -->|"이용한다"| trident_mshtml_engine
    ie_mode -->|"의 후속"| ie11_desktop_app
    trident_mshtml_engine -->|"구현을 담당한다"| document_mode
    trident_mshtml_engine -->|"구현을 담당한다"| activex
    ie_mode -->|"전제로 한다"| enterprise_mode_site_list
    enterprise_mode_site_list -.->|"전제로 한다"| neutral_site
    neutral_site -->|"방지한다"| sso_auth_failure
    cloud_site_list_management -->|"권장되는 대응"| enterprise_mode_site_list
    activex -->|"원인이 될 수 있다"| ie_mode_dependency
    document_mode -->|"원인이 될 수 있다"| ie_mode_dependency
    staged_refactoring -->|"권장되는 대응"| ie_mode_dependency
    full_rewrite -.->|"권장되는 대응"| ie_mode_dependency
    vdi_remoteapp_isolation -.->|"권장되는 대응"| ie_mode_dependency
    micro_frontend -.->|"권장되는 대응"| ie_mode_dependency
    windows_containers -->|"사용은 비권장"| ie_mode_dependency
    webview2 -->|"사용은 비권장"| activex
    webview2 -.->|"권장되는 대응"| ie_mode_dependency
    staged_refactoring -->|"보다 먼저 해야 한다"| full_rewrite
    ie_mode_dependency -->|"에서 확인할 수 있다"| enterprise_site_discovery
    app_assure -.->|"완화한다"| ie_mode_dependency
    extended_stable_channel -->|"권장되는 대응"| ie_mode
    enterprise_mode_site_list -->|"에서 확인할 수 있다"| security_compliance_toolkit
    staged_refactoring -->|"에서 확인할 수 있다"| playwright

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

2. 배경: IE 모드는 “언제까지” 쓸 수 있는가

여기서 짚어 둘 점은, 2029년까지 쓸 수 있다고 해서 안심하고 방치해도 되는 것은 아니라는 점입니다. 이 기간은 어디까지나 “계획적으로 탈피하기 위한 유예”이며, 2029년이 임박해서 허둥대지 않으려면 지금부터 준비를 시작하는 수밖에 없습니다.

3. 왜 IE 모드 의존에서 벗어나지 못하는가

IE 모드는 Chromium 기반 Edge 안에서 오래된 사이트만 Trident(MSHTML) 엔진으로 그리는 방식입니다. 이 Trident 엔진이 맡고 있는 것은 다음과 같습니다.

• 오래된 문서 모드(Document Mode)
• ActiveX 컨트롤 / BHO(Browser Helper Object)
• 오래된 보안 영역 설정
• Enterprise Mode 호환 설정

이들에 의존하는 한, 브라우저만 최신으로 바꾼다고 해서 문제는 해결되지 않습니다. 의존의 실체를 파악하는 것이 첫걸음입니다.

현장에서 자주 발생하는 문제

1. 문서 모드 설정 오류 → 화면이 깨지거나 스크립트 오류
2. Neutral Site 설정 누락 → SSO(싱글 사인온)에서 재인증 루프나 리다이렉트 루프가 발생
3. Enterprise Mode Site List 형식 불일치 → IE 모드 연동에서는 schema v.1이 지원되지 않아 schema v.2로 이전이 필요
4. Edge는 사이트 목록을 하나만 처리한다 → Edge 쪽 정책이 IE 쪽 정책보다 우선된다

의존 분류: 먼저 “무엇에 의존하고 있는가”를 파악한다

4. 1단계: 수명 연장책 ── 먼저 안전하게 운영한다

1. 사이트 목록을 제대로 관리한다(가장 중요)

사용자에게 맡기는 “재로드”는 위험합니다. 정책으로 정식 관리합시다.

해야 할 일: Cloud Site List Management로 전환해, 누가·어느 사이트를·언제까지 IE 모드로 쓰는지를 중앙에서 관리한다.

사이트 목록 XML의 최소 예

사이트 목록은 Enterprise Mode Site List의 schema v.2, 즉 루트 요소가 <site-list>인 XML로 작성합니다. 최소 구성은 이것뿐입니다.

<site-list version="1">
  <!-- IE 모드로 열 사이트 -->
  <site url="legacy.contoso.local">
    <compat-mode>IE8Enterprise</compat-mode>
    <open-in>IE11</open-in>
  </site>

  <!-- 인증 서버: 이동 전 엔진 그대로 연다(Neutral Site) -->
  <site url="login.contoso.local">
    <open-in>None</open-in>
  </site>
</site-list>

작성 시 주의점은 다음과 같습니다.

• url에는 프로토콜을 쓰지 않습니다. contoso.local이라고 쓰면 http와 https 모두에 적용됩니다.
• <open-in>IE11</open-in>을 지정한 사이트가 IE 모드로 열립니다.
• <compat-mode>는 IE 모드 쪽에서 쓸 문서 모드 지정입니다(IE8Enterprise, IE7Enterprise, Default 등).
• <open-in>None</open-in>이 Neutral Site 지정입니다. 인증 서버는 여기에 넣습니다.
• version은 사이트 목록의 버전 번호입니다. 목록을 갱신하면 값을 올립니다.

배포에 쓰는 그룹 정책

사이트 목록을 배포하려면 그룹 정책을 두 개 설정합니다. 둘 다 “사용자 구성” “컴퓨터 구성” 어느 쪽에서든 설정할 수 있습니다.

사이트 목록 위치에는 HTTPS URL(권장), 네트워크 공유 경로, 로컬 파일 경로를 지정할 수 있습니다. IE 쪽에도 같은 역할의 “Use the Enterprise Mode IE website list”(관리 템플릿 > Windows 구성 요소 > Internet Explorer)가 있지만, Edge 쪽 정책을 설정하면 그쪽이 우선됩니다. 전사에는 IE 쪽 정책으로 운영 목록을 배포하고, 파일럿 부서에만 Edge 쪽 정책으로 검증용 목록을 배포하는 식으로 나눌 수 있습니다.

2. 인증 관련 설정을 다잡는다

SSO가 관련되면 IE 모드⇔Edge 모드 간 이동에서 인증이 깨지는 경우가 자주 있습니다.

Neutral Site는 IE 모드와 Edge 모드 어느 쪽에서든 “이동 전 엔진 그대로 연다”고 지정하는 설정입니다. 인증·SSO 중계 사이트를 여기에 등록해 두지 않으면, IE 모드로 연 페이지에서 인증 서버로 가는 순간에 Edge 쪽으로 리다이렉트되어 인증이 실패합니다. Microsoft 문서에서도, IE 모드를 올바르게 동작시키려면 인증·SSO 서버를 명시적으로 Neutral Site로 구성해야 한다고 설명합니다.

• Neutral Site를 올바르게 설정한다 → SSO 서버를 <open-in>None</open-in>으로 명시적으로 지정
• 필요에 따라 Cookie 공유를 설정한다(기본값에서는 Edge와 Internet Explorer 프로세스가 세션 Cookie를 공유하지 않습니다)
• 인증 서버가 어디인지 모르는 동안에는 edge://net-export로 네트워크 로그를 남겨 이동 대상을 파악한다
• 인증 서버를 특정할 수 없는 동안에는, 일시적으로 “IE 모드에서 페이지 내 탐색을 유지한다”는 정책을 사용한다(단, 확정되면 비활성화한다)

3. 진단 도구를 활용한다

감이 아니라 관측 데이터로 판단합니다.

4. 아무리 해도 고칠 수 없는 부분은 “격리”한다

5. 2단계: 탈피책 ── 의존을 어떻게 줄일 것인가

패턴 비교표

★가 실무상 첫 번째 후보입니다.

“예상 공수”를 읽는 방법

표의 인월은 사내 시스템 1개를 가정한 범위이며, 그대로 견적에 쓸 수 있는 숫자가 아닙니다. 같은 패턴이라도 화면 수, IE 모드 대상 URL 수, ActiveX / BHO 종류, SSO 경로 수, 외부 연동 수, 필요한 인수 테스트 양에 따라 몇 배로 달라집니다. 이 표는 “패턴 사이의 상대적인 무게”를 비교하기 위한 것으로 생각하면 됩니다.

실제로 견적할 때는 먼저 다음을 세고, 자사 실적(화면 1개당 수정 공수, 경로 1개당 인증 검증 공수)을 곱해 쌓아 올립니다.

• 화면 수와 장표 수
• IE 모드 대상 URL 수(Enterprise Site Discovery 파악 결과)
• ActiveX / BHO 종류와, 각각의 대체 수단 유무
• 인증·SSO 경로 수
• 신구가 병행 가동하는 기간
• 회귀 테스트 케이스 수와, 그중 수동 확인이 필요한 비율

각 패턴의 활용 방식

단계적 리팩터링이 가장 현실적입니다.

• 처음부터 전부 다시 만들 필요는 없다
• 화면이나 기능을 하나씩 현대화해 나가면 된다
• 신구가 섞여 있는 기간의 “경로 설계”(어느 화면이 어느 엔진으로 동작하는가)가 중요하다

WebView2 래퍼는 “경계를 다시 나누기” 위해 사용합니다.

• ActiveX나 COM 의존을 그대로 유지하기 위한 것이 아니다
• “파일 조작” “기기 연동” “Windows 인증” 등 OS 쪽 책임을 네이티브 쪽으로 옮기고, Web UI 쪽을 현대화한다
• 다만 WebView2 Runtime 배포 책임이 생긴다는 점에 주의

마이크로 프론트엔드는 “팀 경계”와 “배포 경계”가 일치하는 경우에만 유효합니다. 유행한다는 이유만으로 채택해서는 안 됩니다.

전면 재작성은 최후의 수단입니다. ActiveX나 BHO에 대한 의존이 너무 깊어서 도저히 분해할 수 없는 경우로 한정됩니다.

6. 3단계: 구체적인 진행 방법(로드맵)

평가 → 우선순위 결정 → PoC → 테스트 → 배포 → 운영

1. 평가 ── 의존 파악

• Enterprise Site Discovery로 대상 URL을 목록화
• edge://net-export로 네트워크 이동을 시각화
• 의존을 “문서 모드” “ActiveX/BHO” “인증” “클라이언트 인증서” “파일/인쇄” “기기/COM”으로 분류

2. 우선순위 결정 ── 어디부터 손을 댈 것인가

다음 관점으로 정렬합니다.

• 중요도(멈추면 곤란한 순서)
• 이용자 수
• 보안 노출도
• 다른 시스템으로의 파급도
• 분리 용이성(경계가 명확한지 여부)

특히 “경계를 자르면 진행되는 기능”과 “경계 자체를 옮겨야 하는 기능”을 나눠 두면 이후 계획을 세우기 쉬워집니다.

3. PoC(개념 증명) ── 작게 시도한다

첫 대상은 “업무 가치가 높고, 의존이 중간 정도”인 워크플로 1개부터입니다.

성공 조건은 다음 4가지입니다.

1. IE 모드가 필요 없어질 것
2. SSO가 유지될 것
3. 응답 성능이 비교 가능한 수준일 것
4. 롤백(원래대로 되돌릴 수 있음)이 가능할 것

4. 테스트 ── 신구 공존에 대응한다

• 현대화 경로 → Playwright로 Edge를 자동 테스트
• IE 모드 경로 → 진단 페이지 + 수동 확인
• 신구 공존기에는 “어느 경로가 어느 엔진으로 동작하는가”를 명시한다(명시하지 않으면 결함 재현이 어려워짐)

5. 배포 ── 점차 넓힌다

• canary 배포(일부 사용자부터 선행 배포)
• Extended Stable(8주 사이클)로 검증 창을 확보
• 사이트 목록 갱신 주기나 브라우저 재시작 요건을 운영 흐름에 넣는다
• 클라우드 사이트 목록을 쓸 경우 Edge 로그인이 전제가 된다는 점을 잊지 않는다

6. 운영 ── 계속 줄인다

• Cloud Site List Management의 피드백 기능으로, 사용자가 추가한 사이트나 잘못된 설정을 회수
• 매월 IE 모드 대상 목록을 축소하는 운영 사이클을 돌린다
• “수명 연장책”은 반드시 “줄이는 운영”과 세트로 운영한다

전체 흐름(플로차트)

flowchart TD
    A[대상 자산 파악] --> B[의존 분류]
    B --> C{의존 종류는?}
    C -->|문서 모드·SSO 중심| D[IE 모드 정식 운영]
    C -->|OS 연동·COM 중심| E[래퍼화]
    C -->|화면 단위로 자를 수 있음| F[단계적 리팩터링]
    C -->|여러 팀 병렬 개발| G[마이크로 프론트엔드]
    C -->|의존이 너무 깊음| H[전면 재작성]

    D --> I[Neutral Site와 Cookie 조정]
    E --> J[WebView2/네이티브 경계]
    F --> K[신구 공존과 단계적 교체]
    G --> K
    H --> L[새 아키텍처로 재설계]

    I --> M[PoC]
    J --> M
    K --> M
    L --> M

    M --> N[자동 테스트와 운영 테스트]
    N --> O[단계 배포]
    O --> P[이용 현황과 피드백 수집]
    P --> Q[IE 모드 대상 축소]
    Q --> R[폐지 판정]

7. 4단계: 거버넌스 ── 관리적인 틀

IE 모드를 “예외 운영”으로 명문화한다

• 새로 추가하는 IE 모드 대상 URL에는 반드시 다음 항목을 설정합니다.
  • 업무 담당자(누가 책임자인가)
  • 기술 담당자(누가 기술적으로 관리하는가)
  • 만료일(언제까지 탈피할 것인가)
  • 대체 계획(어떻게 탈피할 것인가)
• 기존 XML 사이트 목록이 schema v.1인 경우, IE 모드 연동에서 쓸 수 있는 schema v.2로 이전한다
• 변경 이력은 Cloud Site List Management 또는 구성 관리 도구로 추적한다

보안 측면에서의 주의

• 오래된 Edge를 고정해서 운영하는 것은 위험 → 최신 Stable/Beta 계열을 사용한다
• 검증 기간이 필요하면 Extended Stable(8주 사이클)을 사용한다
• GPO 품질 확인에는 Security Compliance Toolkit이나 Policy Analyzer를 사용한다
• “IE 모드 자체의 취약점”보다 “주변 브라우저 운영이 허술한 것”이 사고로 이어지기 쉽다

시간축을 역산한다

• IE 모드 지원 종료: 2029년
• Win10 22H2의 Edge/WebView2 업데이트 종료: 2028년 10월

이들은 “철수 기한의 외곽”입니다. 지원이 끝나기 전에 의존을 0으로 만드는 역산표를 먼저 만들어야 합니다.

8. 규모별 권장 전략

이 표의 인월도 2단계 “예상 공수”와 같은 전제의 범위입니다. 전형적인 조건 칸(화면 수, SSO 복잡도, 부서 수)이 자사와 크게 다르면 그대로 적용하지 말고, 화면 수와 경로 수부터 다시 쌓아 올립니다.

9. 흔한 실수와 대책

10. 정리

표준 전략 = 정식 IE 모드 운영(사고 방지)
           + 의존 가시화(파악)
           + 단계적 축소(하나씩 탈피)

• 소규모라면 단계적 리팩터링
• 대규모라면 사이트 목록 통제 + 포트폴리오 관리
• 예산이 빠듯하다면 가상화로 봉쇄하면서 신규 의존을 멈춘다
• 전면 재작성은 최후의 카드
• 컨테이너는 보통 후보 밖, VDI는 대피소, IE 모드는 활주로(이륙하기 위한 것)

참고 링크

• IE와 Edge의 라이프사이클 FAQ ─ IE 모드의 2029년 방침
• IE 모드 개요 ─ 지원 범위의 기본 자료
• IE 모드 정책 구성 ─ 통합 설정의 3단계
• Enterprise site configuration strategy ─ Neutral Site, Cookie 공유, schema v.2
• Enterprise Mode schema v.2 guidance ─ 사이트 목록 XML의 요소와 작성 예
• Microsoft Edge 업데이트 채널 개요 ─ Stable과 Extended Stable의 사이클
• IE mode troubleshooting and FAQ ─ 진단 페이지, net-export 사용법
• Cloud Site List Management ─ 관리 센터에서의 중앙 관리
• Enterprise Site Discovery ─ 파악의 출발점
• WebView2 문서 ─ 래퍼화 검토에
• Azure Virtual Desktop / RemoteApp ─ 격리책으로
• Windows Containers 이전 가이드 ─ GUI 수명 연장처로는 부적합
• App Assure ─ IE 모드 설정 지원의 범위
• Playwright ─ Edge 자동 테스트
• single-spa ─ 마이크로 프론트엔드의 기초
• webpack Module Federation ─ 독립 빌드 통합

관련 기사

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

관련 토픽

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

이 주제와 연결되는 서비스

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

자주 묻는 질문

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

Edge의 IE 모드는 언제까지 사용할 수 있나요?

Edge의 IE 모드는 최소 2029년까지 지원되며, 폐지 1년 전에 통지하는 방침입니다. 또한 Windows 10 22H2에서의 Edge / WebView2 Runtime 업데이트는 최소 2028년 10월까지입니다. 다만 이 기간은 어디까지나 계획적으로 탈피하기 위한 유예이며, 2029년은 준비를 시작하는 시점이 아니라 탈피를 완료해야 하는 기한으로 역산해야 합니다. IE11 데스크톱 앱 자체는 이미 퇴역했습니다.

IE 모드 의존에서 벗어나지 못하는 이유는 무엇인가요?

IE 모드는 Chromium 기반 Edge 안에서 오래된 사이트만 Trident(MSHTML) 엔진으로 그리는 방식이며, 이 Trident가 오래된 문서 모드, ActiveX 컨트롤과 BHO, 오래된 보안 영역 설정, Enterprise Mode 호환 설정을 맡고 있기 때문입니다. 이들에 의존하는 한, 브라우저만 최신으로 바꾼다고 해서 해결되지 않습니다. 먼저 의존을 문서 모드·ActiveX/BHO·인증 SSO·클라이언트 측 연동·오래된 운영 전제로 분류해 실체를 파악하는 것이 첫걸음입니다.

IE 모드 탈피에는 어떤 방법이 있나요?

주요 선택지는 IE 모드 지속 운영, WebView2 래퍼, 단계적 리팩터링, 마이크로 프론트엔드, 전면 재작성, VDI / RemoteApp 격리의 6가지입니다. 실무상 첫 번째 후보는 단계적 리팩터링으로, 화면이나 기능을 하나씩 현대화해 나갈 수 있습니다. WebView2 래퍼는 ActiveX를 그대로 유지하기 위한 것이 아니라, 파일 조작이나 기기 연동 등 OS 쪽 책임을 네이티브로 옮겨 경계를 다시 나누기 위해 사용합니다. 전면 재작성은 의존이 너무 깊어 분해할 수 없는 경우의 최후 수단입니다.

IE 모드를 당분간 계속 사용할 경우 무엇을 해야 하나요?

먼저 사이트 목록을 사용자에게 맡기는 재로드가 아니라 정책으로 정식 관리하는 것입니다. Cloud Site List Management로 전환하면 여러 목록 배포, 변경 이력, 그룹별 할당이 가능해집니다. SSO가 관련된 경우에는 Neutral Site를 올바르게 설정하고, 필요하면 Cookie 공유를 설정합니다. 아울러 새로 추가하는 IE 모드 대상 URL에는 업무 담당자·기술 담당자·만료일·대체 계획을 반드시 설정하고, 매월 대상 목록을 축소하는 운영 사이클과 함께 운영해야 합니다.

저자 프로필

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

Go Komura

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

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