Windows I/O의 심층(제6회・최종회) ── 필터 드라이버와 미니필터: Procmon과 백신 검사가 I/O에 개입할 수 있는 이유

연재 「Windows I/O의 심층」의 최종회입니다.

제1회의 디바이스 스택 그림에 ‘파일 시스템 필터(백신·암호화·Procmon 등)’라는 상자를 그린 이래, 이 연재에는 사이에 끼어드는 존재들이 몇 번이고 얼굴을 내밀어 왔습니다. Procmon이 모든 I/O를 기록할 수 있는 이유(제1회). ‘그 환경에서만 파일 접근이 느리다’(제2회). 열리는 순간 OneDrive가 다운로드를 시작하는 리파스 포인트(제5회). 이번 회에서는 드디어 그 끼어드는 구조 그 자체──파일 시스템 필터 드라이버와 미니필터──를 정면으로 다루며, 연재의 복선을 모두 회수합니다.

1. 먼저 결론

• ‘I/O에 개입한다’는 OS가 공인한 확장 지점입니다. 파일 시스템 필터는 파일 시스템에 대한 요청을 보고, 다시 쓰고, 거부하고, 대신 처리할 수 있습니다(2장).¹
• 현재의 표준은 미니필터입니다. 디바이스 스택에 직접 개입하는 레거시 방식의 문제(순서 불확정·언로드 불가)를 해결하기 위해, Windows에 포함된 필터 매니저(FltMgr)에 콜백을 등록하는 방식으로 세대교체가 이루어졌습니다(2장).²³
• 동작은 pre/post 콜백입니다. 각 작업의 전후에, 등록 순서=알티튜드 순으로 호출됩니다. 통과·완료·거부·다시 쓰기──제1회에서 본 ‘드라이버의 선택지’가 그대로 쓰입니다(3장).²
• 알티튜드(고도)가 순서를 결정합니다. 용도별 그룹에 번호 대역이 할당되며(Activity Monitor 360000~389999, Anti-Virus 320000~329999 등), 볼륨에 연결되는 인스턴스마다 고유한 번호가 붙습니다(4장).⁴⁵
• 여러분의 PC에 사는 존재들은 fltmc로 볼 수 있습니다. Procmon(실행 중일 때만), 백신, OneDrive의 클라우드 필터──모두 여기에 나란히 나타납니다(5장).
• 백신의 제외 설정이란 ‘그 제품 자신의 스캔을 생략하는 것’이며, 다른 미니필터에는 영향을 주지 않습니다. 제외는 보호를 약화시키는 트레이드오프이며, 개발 볼륨에는 Dev Drive(비동기 스캔)라는 더 안전한 선택지가 있습니다(6장).⁶⁷
• ‘그 환경에서만 느리다’의 조사는 Procmon의 Duration 열과 fltmc의 구성 비교에서 시작합니다(7장).

2. 끼어드는 존재들의 역사 ── 레거시 필터에서 FltMgr로

파일 시스템 필터 드라이버는 파일 시스템(또는 그 아래의 볼륨)으로 향하는 요청을 가로챌 수 있는 드라이버입니다. 요청을 기록하고, 감시하고, 내용을 변경하며, 나아가 거부나 대체 처리까지 할 수 있습니다──백신, 암호화, 백업, 계층형 저장소 같은 소프트웨어의 토대입니다.¹

오래된 구현 방식(레거시 필터)은 제1회에서 본 디바이스 스택에 자신의 디바이스 오브젝트를 직접 쌓는 방식이었습니다. 구조로서는 단순하지만, 실무에서는 문제투성이였습니다──쌓이는 순서가 로드 순서에 의존해 보장하기 어렵고, 한번 쌓으면 안전하게 빠져나올 수 없으며(언로드할 수 없으며), 필터끼리의 상성 버그가 발생하기 쉬운 온상이었습니다.

그래서 Windows는 필터 매니저(FltMgr)를 도입했습니다. FltMgr 자신이 OS 제공 필터로서 스택에 서고, 개별 필터 기능은 미니필터로서 FltMgr에 콜백을 등록하는 방식입니다.²

flowchart TB
    subgraph OLD["레거시 방식"]
        L1["레거시 필터 A"]
        L2["레거시 필터 B"]
        LFS1["파일 시스템"]
        L1 --> L2
        L2 --> LFS1
        NOTE1["순서는 로드 순서에 좌우됨<br/>안전한 언로드 불가"]
    end
    subgraph NEW["미니필터 방식 ── 현재의 표준"]
        FM["필터 매니저 FltMgr<br/>OS 제공, 스택에 서는 것은 이것뿐"]
        M1["미니필터 A ── 알티튜드 높음"]
        M2["미니필터 B ── 알티튜드 낮음"]
        LFS2["파일 시스템"]
        FM -. "콜백 등록" .- M1
        FM -. "콜백 등록" .- M2
        FM --> LFS2
        NOTE2["순서는 알티튜드로 결정적<br/>임의의 시점에 로드 가능<br/>대응 필터는 언로드도 가능"]
    end

그림 1: 세대교체. 스택에 ‘쌓는’ 것이 아니라 FltMgr에 ‘등록하는’ 방식으로

미니필터 방식의 이점은 공식적으로 열거되어 있습니다──언제든지 로드할 수 있고, 순서를 제어할 수 있으며, 언로드 콜백을 구현한 필터라면 가동 중에 언로드할 수도 있습니다(구현하지 않았거나 거부하는 필터는 뗄 수 없습니다).³ 레거시 필터와의 공존을 위해 FltMgr는 여러 개의 ‘프레임’으로서 스택의 여러 위치에 설 수 있으며, 미니필터는 언로드 후 다시 로드해도 같은 위치(같은 알티튜드)로 돌아오는 것이 보장됩니다.² 현대의 백신·감시·동기화 소프트웨어는 거의 모두 이 미니필터입니다.

3. 미니필터의 동작 ── pre/post 콜백

미니필터는 ‘어떤 작업에 관심이 있는가’를 FltMgr에 선언합니다. 예를 들어 IRP_MJ_CREATE(열기)와 IRP_MJ_WRITE(쓰기)에만 관심이 있다는 식입니다. 그러면 그 작업이 흐를 때마다 작업 전(pre 콜백)과 작업 후(post 콜백)가 호출됩니다.

sequenceDiagram
    participant IOM as I/O 관리자
    participant FM as FltMgr
    participant A as 미니필터 A<br/>(알티튜드 높음)
    participant B as 미니필터 B<br/>(알티튜드 낮음)
    participant FS as NTFS

    IOM->>FM: 요청(IRP_MJ_CREATE 등, 제1회의 세계)
    FM->>A: pre 콜백
    FM->>B: pre 콜백
    FM->>FS: 파일 시스템으로
    FS-->>FM: 처리 결과
    FM-->>B: post 콜백
    FM-->>A: post 콜백
    FM-->>IOM: 완료(제1회의 완료 흐름으로)

그림 2: pre/post 콜백. 갈 때는 알티튜드가 높은 순서로, 돌아올 때는 그 역순으로 호출된다

각 콜백에서 무엇을 할 수 있을까요. 제1회 4.3절의 ‘드라이버의 3가지 선택지’와 같은 구도가, 더 안전한 API로 제공됩니다.

flowchart TB
    PRE["pre 콜백이 호출됨"]
    Q{"이 작업을 어떻게 할까"}
    PASS["그대로 통과시킨다<br/>post도 필요 없으면 그것도 선언"]
    DENY["거부한다<br/>접근 거부 등을 즉시 반환<br/>예 - 바이러스 검출, 쓰기 금지"]
    DONE["직접 완료 처리한다<br/>예 - 클라우드 필터가<br/>실체를 가져와 건네준다"]
    MOD["매개변수나 내용에 손을 대서 흘려보낸다<br/>예 - 암호화 필터"]
    PRE --> Q
    Q --> PASS
    Q --> DENY
    Q --> DONE
    Q --> MOD

그림 3: pre 콜백의 선택지. ‘본다·멈춘다·대신한다·다시 쓴다’를 모두 공식적으로 할 수 있다

그리고 제4회의 숙제가 여기서 회수됩니다──미니필터는 패스트 I/O(IRP를 만들지 않는 지름길)에도 참여할 수 있습니다. FltMgr가 패스트 I/O 경로에도 콜백 메커니즘을 통과시키기 때문이며, 레거시 시대처럼 ‘지름길로 지나가면 보이지 않는다’는 일이 없습니다. Procmon 로그에 FASTIO_로 시작하는 행까지 나란히 나타나는 것은 이 위치 덕분입니다.

4. 알티튜드 ── ‘고도’가 순서를 결정한다

여러 필터가 같은 작업에 관심을 가질 때, 누가 먼저 볼 것인가는 중대한 문제입니다. 암호화보다 먼저 백신이 보지 않으면 암호문을 스캔하게 되고, 감시 도구는 모든 필터보다 위에 있지 않으면 전체를 관찰할 수 없습니다.

이 순서를 결정하는 것이 알티튜드(altitude, 고도)입니다. 필터의 종류마다 로드 순서 그룹과 번호 대역이 정의되어 있습니다. 정확히 말하면 알티튜드가 붙는 단위는 드라이버 전체가 아니라 볼륨에 연결되는 미니필터의 ‘인스턴스’입니다. 번호는 고유하며, 숫자가 클수록 스택의 위쪽(애플리케이션 쪽)에 위치합니다.⁴ 하나의 드라이버가 여러 개의 인스턴스 정의를 가지고 서로 다른 고도에 나타나는 구성도 가능하며, fltmc instances의 목록이 인스턴스 단위인 것은 이 때문입니다.

flowchart TB
    APP["애플리케이션 쪽 ── 숫자가 큼"]
    G1["FSFilter Activity Monitor ── 360000~389999<br/>I/O 관찰·기록, Procmon이 여기"]
    G2["FSFilter Undelete ── 340000~349999<br/>삭제 파일 복원"]
    G3["FSFilter Anti-Virus ── 320000~329999<br/>바이러스 검출·제거"]
    G4["FSFilter Replication ── 300000~309999<br/>원격 복제"]
    G5["FSFilter Continuous Backup ── 280000~289999<br/>연속 백업"]
    G6["더 아래로 ── Content Screener /<br/>Quota Management / System Recovery /<br/>암호화·압축 등의 대역이 이어짐"]
    FS["파일 시스템 쪽 ── 숫자가 작음"]
    APP --> G1 --> G2 --> G3 --> G4 --> G5 --> G6 --> FS

그림 4: 알티튜드 대역(발췌). 용도별로 ‘서야 할 고도’가 정해져 있다

중요한 것은 이 번호가 Microsoft에 의해 할당·관리되고 있다는 점입니다.⁵ 벤더가 마음대로 자칭하는 것이 아니라 신청해서 받는 방식입니다──그래서 어떤 PC에서든 ‘감시는 백신보다 위, 백신은 암호화보다 위’라는 질서가 유지됩니다. 레거시 시대의 ‘로드 순서 뽑기’에 대한 답이 바로 이것이었습니다.

자사에서 미니필터를 만들 경우의 신청처. 개발자를 위해 다음 한 수만 적어 둡니다. 알티튜드는 Request a Filter Altitude Identifier의 절차에 따라 제목을 ‘Filter altitude request’로 하여 fsfcomm@microsoft.com으로 영문 메일을 보내 신청합니다. 회사명·연락처(개인이 아니라 장기간 사용할 수 있는 회사 에일리어스)·제품명·제품 URL·필터 설명·드라이버 파일명·필터 종류·시작 종류·희망하는 로드 순서 그룹과 희망 알티튜드를 모두 기입해야 합니다. 처리에 30영업일을 예상해야 하며, 긴급 처리 창구는 없고, 할당되는 번호가 희망과 다를 수 있다는 점도 명시되어 있습니다.⁸ 참고로 같은 로드 순서 그룹에 이미 정수 알티튜드를 가진 회사라면, 그 번호에 소수를 붙인 값(예: 325000.3)을 스스로 정해도 되며, 이 경우 사후에 메일로 연락하면 충분합니다.⁸

5. 입주민 소개 ── fltmc로 보는 여러분의 PC

이론은 여기까지 하고, 실물을 봅시다. 관리자 권한의 명령 프롬프트에서:

:: 등록된 미니필터 목록(알티튜드 포함)
fltmc

:: 어떤 볼륨에 어떤 필터가 붙어 있는가
fltmc instances

:: 볼륨 쪽에서 본다
fltmc volumes

인수 없이 실행한 fltmc는 fltmc filters와 같은 목록을 출력합니다. 출력은 4개 열로 구성되며, Microsoft 문서에도 같은 형식의 예시가 실려 있습니다.⁹

C:\Windows\system32>fltmc

Filter Name                     Num Instances    Altitude    Frame
------------------------------  -------------  ------------  -----
bindflt                                 1        409800         0
cldflt                                  1        409500         0
WdFilter                                4        328010         0
luafv                                   1        135000         0
FileInfo                                4         45000         0

위는 설명을 위한 발췌입니다. 나열되는 구성과 인스턴스 수는 환경마다 다르지만, 알티튜드 수치는 Microsoft가 할당한 고정값이므로 4장에서 다룬 공개 목록과 대조할 수 있습니다.

열의 의미는 다음과 같습니다.

이 5줄만으로도 bindflt와 cldflt가 최상위 FSFilter Top 대역(400000~409999), WdFilter가 Anti-Virus 대역(320000~329999), FileInfo가 최하층 FSFilter Bottom 대역(40000~49999)에 있음을 읽어낼 수 있습니다. 4장에서 본 ‘용도별로 서야 할 고도가 정해져 있다’는 구도가 그대로 숫자로 확인되는 것입니다. 그리고 Procmon을 실행한 뒤 다시 한번 fltmc를 실행하면, Activity Monitor 대역(360000~389999)에 PROCMON으로 시작하는 행이 하나 늘어납니다.

환경에 따라 구성은 다르지만, 전형적인 입주민은 이 연재의 단골들뿐입니다.

• WdFilter ── Microsoft Defender의 미니필터. Anti-Virus 대역에 있습니다. 많은 PC에서 모든 파일 I/O가 반드시 통과하는 관문입니다.
• cldflt ── 클라우드 파일 필터. OneDrive 파일 온디맨드의 실행 부대로, 제5회에서 본 리파스 포인트(플레이스홀더)가 열렸을 때 실체를 준비합니다.¹⁰
• PROCMON24(등) ── Process Monitor를 실행하는 동안에만 나타나는, Activity Monitor 대역의 일시적인 미니필터. Procmon이 모든 I/O를 볼 수 있는 비밀이 바로 이것입니다.¹¹ 실행 전후로 fltmc를 실행해 비교해 보십시오.
• 그 밖에도 백업 소프트웨어, 암호화(정보 유출 대책) 제품, EDR, 가상화 스토리지 등──업무용 PC일수록 입주민이 늘어납니다.

제1회부터 사용해 온 Procmon이라는 도구를, 최종회에서 도구 상자 밖에서 다시 바라보면, ‘관찰자 또한 관찰 대상과 같은 구조의 입주민이었다’는 깔끔한 순환이 됩니다.

6. 백신은 어디서 시간을 쓰는가

필터가 실무에 미치는 영향 중 가장 큰 것이 백신의 스캔 비용입니다. 어디서 시간이 발생하는지를 그림으로 나타냅니다(제품에 따라 세부 사항은 다릅니다. 아래는 전형적인 형태입니다).

sequenceDiagram
    participant App as 앱
    participant AV as AV 미니필터
    participant FS as NTFS

    App->>AV: 파일을 연다
    Note over AV: pre-create: 경로나 정책의 사전 판정
    AV->>FS: 통과시킨다(오픈 실행)
    FS-->>AV: 오픈 성립(post-create)
    Note over AV: 아직 스캔하지 않은 파일이면<br/>여기서 내용을 스캔하고<br/>문제가 있으면 오픈을 취소한다<br/>── 열기가 느려지는 주요 원인
    AV-->>App: 문제가 없으면 핸들이 반환된다
    App->>AV: 쓰기·닫기
    Note over AV: 변경된 파일은<br/>닫을 때 등에 재스캔 대상이 된다
    Note over App,FS: 대량의 소형 파일(빌드의 중간 산출물 등)에서는<br/>이 왕복이 파일 수만큼 쌓인다

그림 5: 스캔 비용이 발생하는 지점. 파일 1개당은 미미해도 수만 개라면 지배적인 요인이 된다

이를 바탕으로 하면 2가지 실무 주제를 정확히 이해할 수 있습니다.

제외 설정의 기술적 의미. 제외 목록에 일치하는 경로의 I/O에서는 필터의 스캔 처리가 생략됩니다. 필터가 스택에서 사라지는 것이 아니라, ‘검사하지 않는다’는 판단이 일찍 내려지게 된다는 것이 실태입니다. 그리고 하나 더 중요한 제한이 있습니다──제외가 적용되는 것은 그 설정을 가진 제품 자신의 필터뿐입니다. Microsoft Defender의 제외 설정이 바꾸는 것은 WdFilter의 스캔이며, 함께 설치된 다른 미니필터(타사 백신·EDR·백업·암호화 등)의 동작에는 아무런 영향도 주지 않습니다. ‘제외를 설정했는데도 여전히 느리다’는 경우에는 다른 입주민이 시간을 쓰고 있을 가능성을 의심해 보십시오(7장의 fltmc 비교). 효과는 크지만, 제외는 그 위치의 보호를 확실히 약화시킵니다. Microsoft 문서에서도 제외는 방어를 줄이므로 위험 평가를 거쳐 최소한으로 하라고 반복해서 경고하고 있습니다.⁶ 오탐 대응과 성능 영향의 실무는 「자사 개발 Windows 앱이 바이러스로 오탐되었다면」에서 다루었습니다.

Dev Drive라는 새로운 답. 개발 워크로드(대량의 소형 파일)를 위해 설계된 전용 볼륨으로, Microsoft Defender가 성능 모드(비동기 스캔)로 동작합니다. 폴더 제외의 더 안전한 대안으로 자리매김하고 있으며, 기본적으로 추가 필터가 연결되지 않는 한편, 필터를 전부 제거하고 운용하는 것에 대한 강력한 경고도 명시되어 있습니다.⁷ ‘빌드를 빠르게 하고 싶지만 제외는 무섭다’에 대한, 현재 Microsoft의 권장 해법입니다.

7. ‘그 환경에서만 느리다’의 조사 절차

연재를 통해 쌓아 온 도구를, 마지막으로 하나의 절차로 정리합니다.

flowchart TB
    S["증상 ── 같은 앱인데 특정 환경에서만<br/>파일 접근이 느림"]
    P1["Procmon에서 Duration 열을 본다<br/>IRP_MJ_CREATE·WRITE 등<br/>어떤 작업에 시간이 소모되는가"]
    Q1{"특정 작업이 일관되게 느린가?"}
    F1["fltmc instances를 빠른 환경과 비교<br/>필터 구성의 차이를 본다"]
    Q2{"차이가 나는 필터가 원인인가?"}
    A1["제외 설정 ── 위험 평가 포함 ── 이나<br/>Dev Drive 검토·벤더 상담"]
    A2["필터 이외를 의심한다 ──<br/>캐시 제4회·단편화나 MFT 제5회·<br/>네트워크 대상 UNC·디바이스 자체"]
    S --> P1 --> Q1
    Q1 -->|"예"| F1 --> Q2
    Q2 -->|"예"| A1
    Q2 -->|"아니오"| A2
    Q1 -->|"아니오, 산발적"| A2

그림 6: 필터로 인한 느려짐의 판별. 핵심은 ‘작업 단위의 소요 시간’과 ‘환경 간 필터 구성 차이’

요점은 2가지입니다. 첫째, Procmon은 작업별 소요 시간(Duration)을 가지고 있습니다. ‘느리다’를 ‘어떤 작업이 느린가’로 분해할 수 있다면, 범인 찾기는 절반이 끝난 것입니다. 둘째, 환경 차이는 필터 구성의 차이인 경우가 많습니다. 개발 머신과 프로덕션 머신, 자사 PC와 고객사 PC──fltmc의 출력을 나란히 놓기만 해도 의심해야 할 후보가 보이기 시작합니다.

Procmon을 처음 다뤄 보는 경우의 첫 3가지 조작. Duration 열은 기본적으로 표시되지 않으므로, 여기서 막히지 않도록 조작 방법만 적어 둡니다.

1. 관리자 권한으로 Procmon.exe를 실행한다.
2. Options 메뉴 > Select Columns…를 열고, 열 목록에서 Duration에 체크한다.
3. Filter 메뉴 > Filter…(Ctrl+L)에서 Process Name / is / 대상 exe 이름 / Include를 입력하고, Add 버튼을 누른 다음 OK한다(Add를 누르지 않으면 조건이 입력되지 않습니다).

그런 다음 Duration 열을 클릭해 정렬하면, 시간을 많이 쓰는 작업이 위쪽에 모입니다. 프로세스 단위·파일 단위 집계라면 Tools 메뉴 > File Summary도 사용할 수 있습니다. ProcMon의 조작 전반은 「Process Monitor(ProcMon) 실전 가이드」에 정리해 두었습니다.

8. 연재의 마무리 ── 6회분의 지도

이것으로 제1회에서 그렸던 지도의 모든 상자를 열었습니다. 전체를 한 장으로 정리합니다.

flowchart TB
    APP["애플리케이션<br/>ReadFile / WriteFile / async-await"]
    API["제2회 ── 동기·비동기 I/O<br/>핸들의 모드와 OVERLAPPED"]
    IOCP["제3회 ── IOCP와 .NET 스레드 풀<br/>완료 수신과 연속 실행"]
    IOM["제1회 ── I/O 관리자와 IRP<br/>이름 해석·3가지 오브젝트·디바이스 스택"]
    FLT["제6회 ── 필터와 미니필터<br/>FltMgr·알티튜드·pre/post"]
    CACHE["제4회 ── 캐시 관리자<br/>256KB 뷰·lazy writer·패스트 I/O<br/>NTFS와 협조하여 동작"]
    NTFS["제5회 ── NTFS<br/>MFT·스트림·링크·2가지 저널"]
    HW["스토리지 스택과 디바이스"]
    APP --> API
    API --> IOM
    IOCP -. "완료는 여기로 돌아옴" .-> APP
    IOM --> FLT
    FLT --> NTFS
    NTFS -. "캐시 유효 I/O는 협조<br/>파일 시스템이 캐시 기능을 호출함" .- CACHE
    NTFS --> HW
    HW -. "인터럽트→완료, 제1회" .-> IOCP

그림 7: 연재 전체의 지도. 캐시 관리자는 ‘통과하는 계층’이 아니라 파일 시스템과 협조하는 동반자이며, 캐시 미스 시 NTFS에서 스토리지로 요청이 나간다

• 제1회: 전체상 ── 모든 읽기·쓰기는 IRP가 된다
• 제2회: 동기/비동기 ── OVERLAPPED의 진짜 의미
• 제3회: IOCP ── async/await의 지하실
• 제4회: 캐시 ── 당신의 WriteFile은 언제 디스크에 도달하는가
• 제5회: NTFS ── MFT로 이해하는 파일 시스템
• 제6회: 필터와 미니필터(본 글) ── Procmon과 백신 검사가 I/O에 개입할 수 있는 이유

9. 정리 ── 연재를 마치며

최종회의 정리입니다.

• I/O에 대한 개입은 OS가 공인한 확장 지점이며, 현재의 표준은 FltMgr에 대한 콜백 등록(미니필터)입니다. 순서는 알티튜드로 결정적으로 정해지며, Microsoft가 번호를 할당·관리하고 있습니다.²⁴⁵
• 동작은 pre/post 콜백입니다. 통과·거부·대신·다시 쓰기가 가능하고, 패스트 I/O에도 참여할 수 있습니다. Procmon도 Defender도 OneDrive도 모두 이 같은 구조의 입주민입니다.¹¹¹¹⁰
• 제외 설정 = 스캔의 생략이며, 보호와의 트레이드오프입니다. 개발 볼륨에는 Dev Drive(비동기 스캔)라는 더 안전한 선택지가 있습니다.⁶⁷
• ‘그 환경에서만 느리다’는 Procmon의 Duration과 fltmc의 구성 차이로 판별합니다──연재의 도구가 그대로 조사 절차가 됩니다.

그리고 연재 전체의 결론을 한 줄로 말하면 이렇게 됩니다──Windows의 I/O는 이름공간에서 목적지를 정하고, 요청을 패킷(IRP)으로 만들어 계층 사이를 흘려보내며, 각 계층이 ‘본다·맡는다·대신한다’를 선택할 수 있도록 만들어진, 일관된 설계다. File.ReadAllText 한 줄 아래에서 이 6회분의 구조가 매번 동작하고 있습니다. API의 동작을 암기하는 대신, 이 지도로부터 ‘그렇게 될 것이다’라고 유도할 수 있는 것──그것이 이 연재를 통해 여러분이 얻어 가시길 바란 힘입니다. 긴 여정을 함께해 주셔서 감사합니다.

관련 글

• Windows I/O의 심층(제1회) ── 모든 읽기·쓰기는 IRP가 된다: I/O 시스템의 전체상
• Windows I/O의 심층(제4회) ── 캐시 관리자: 당신의 WriteFile은 언제 디스크에 도달하는가
• Windows I/O의 심층(제5회) ── NTFS의 내부 구조: MFT로 이해하는 파일 시스템
• Process Monitor(ProcMon) 실전 가이드 ── 「설정이 반영되지 않는다」「ACCESS DENIED」를 10분 만에 특정하기
• 자사 개발 Windows 앱이 바이러스로 오탐되었다면 ── Microsoft Defender 오탐 대응과 성능 영향에 대처하는 법
• Process Explorer / Handle / VMMap 실전 ── 행(hang)・누수・「파일 사용 중」을 지금 이 순간의 상태에서 추적한다
• Windows 앱 개발에서 최저한의 보안을 지키기 위한 체크리스트

관련 상담 영역

합동회사 코무라소프트에서는 ‘특정 환경에서만 느리다’, ‘보안 소프트웨어와 자사 앱이 간섭한다’ 같은, 필터 드라이버가 관련된 Windows 업무 앱의 성능 문제・결함 조사를 다루고 있습니다.

• Windows 앱 개발
• 결함 조사・원인 분석
• 기술 상담・설계 리뷰
• 문의하기

참고 링크

관련 기사

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

관련 토픽

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

이 주제와 연결되는 서비스

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

자주 묻는 질문

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

파일 시스템 필터 드라이버와 미니필터는 무엇이 다른가요?

둘 다 '파일 시스템에 대한 I/O 요청에 개입하는 드라이버'이지만, 개입하는 방식의 세대가 다릅니다. 오래된 레거시 필터는 파일 시스템의 디바이스 스택에 자신의 디바이스 오브젝트를 직접 쌓아 올리는 방식으로, 로드된 순서로 위치가 정해지기 때문에 순서를 보장하기 어렵고, 한번 로드하면 안전하게 언로드할 수 없는 등의 문제가 있었습니다. 현재의 표준인 미니필터는 Windows에 포함된 필터 매니저(FltMgr)에 '이 작업의 전후에 호출해 달라'고 콜백을 등록하는 방식입니다. 위치는 알티튜드라는 번호로 결정적으로 정해지며, 임의의 시점에 로드할 수 있고, 언로드 콜백을 구현한 필터라면 가동 중에 떼어낼 수도 있습니다. 백신·암호화·감시 도구·클라우드 동기화 등 현대의 필터는 거의 모두 미니필터로 구현되어 있습니다.

왜 백신 소프트웨어는 모든 파일 접근을 검사할 수 있나요?

OS가 공식적으로 그것을 위한 확장 지점을 마련해 두었기 때문입니다. 미니필터는 파일을 열기·읽기·쓰기 같은 작업의 전(pre 콜백)과 후(post 콜백)에 호출되는 코드를 필터 매니저에 등록할 수 있습니다. 백신 필터는 안티바이러스용 알티튜드 대역(320000~329999)에 위치하며, 예를 들어 파일 오픈이 성립된 직후(post-create)에 내용을 스캔하고, 문제가 있으면 그 오픈을 취소해 접근을 실패시킬 수 있습니다. 연재 제1회에서 본 것처럼 모든 파일 I/O는 디바이스 스택을 흐르므로, 그 통로의 정해진 위치에 서면 모든 접근을 검사할 수 있다는 논리입니다. 해킹이 아니라 OS의 설계에 내장된 구조입니다.

백신 소프트웨어의 제외 설정(폴더 제외)은 기술적으로 무엇을 하는 건가요?

제외 목록에 일치하는 경로에 대한 I/O에 관해, 그 제품의 필터가 수행하는 스캔 처리를 생략시키는 것입니다. 필터 자체가 스택에서 사라지는 것이 아니라, '이 경로는 검사하지 않는다'는 판단이 조기에 내려지게 된다는 것이 실태에 가까운 이해입니다. 중요한 제한으로, 제외가 적용되는 것은 그 설정을 가진 제품 자신뿐입니다. 예를 들어 Microsoft Defender의 제외 설정이 바꾸는 것은 Defender의 필터(WdFilter)의 스캔이며, 함께 설치된 타사 백신·EDR·백업 등 다른 미니필터의 동작에는 영향을 주지 않습니다. 제품마다 개별적인 제외 설정이 필요하며, '제외했는데도 여전히 느리다'는 경우에는 다른 필터가 원인일 수 있습니다. 또한 Microsoft 문서가 반복해서 경고하듯이, 제외는 그 위치의 보호를 약화시키므로 위험 평가와 함께 최소한으로 해야 합니다. 개발 용도에서는 폴더 제외의 안전한 대안으로 설계된 Dev Drive(성능 모드 = 비동기 스캔)를 검토하는 것도 가치가 있습니다.

Process Monitor는 어떻게 모든 I/O를 기록하나요?

Procmon 자신이 실행 시 Activity Monitor(활동 감시)용 알티튜드 대역의 미니필터로서 스스로를 필터 매니저에 등록하기 때문입니다. Procmon을 실행한 상태에서 관리자 권한의 명령 프롬프트에서 fltmc를 실행하면, PROCMON으로 시작하는 이름의 필터가 목록에 나타나는 것을 확인할 수 있습니다. 미니필터로서 모든 볼륨의 I/O 작업의 pre/post에 참여할 수 있기 때문에, 어떤 프로세스가 어떤 파일에 어떤 작업을 했는지 빠짐없이 기록할 수 있습니다. 연재에서 봐 온 IRP나 패스트 I/O라는 용어가 Procmon의 표시에 그대로 나타나는 것은, 바로 I/O의 통로 자체에 서서 관찰하고 있기 때문입니다.

개발 머신의 빌드가 느릴 때, 필터 드라이버를 의심해야 하나요?

의심할 가치는 충분히 있습니다. 빌드는 대량의 소형 파일 생성·읽기·쓰기·삭제의 덩어리이며, 그 하나하나가 필터군(특히 백신의 스캔)의 검사 대상이 되기 때문에 필터 비용이 가장 표면화되기 쉬운 워크로드입니다. 조사는 Procmon에서 Duration 열을 보고 시간이 어느 작업에 소모되는지 확인하고, fltmc instances로 환경별 필터 구성의 차이를 비교하는 것이 기본 절차입니다. 대책으로는 위험을 평가한 위에서의 제외 설정 외에, 개발 볼륨 전용으로 설계된 Dev Drive의 이용을 들 수 있습니다. Dev Drive에서는 백신이 성능 모드(비동기 스캔)로 동작하며, 제외 설정보다 안전한 대안이 된다고 Microsoft가 자리매김하고 있습니다.

저자 프로필

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

Go Komura

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

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