자사 개발 Windows 앱이 바이러스로 오탐되었다면 ── Microsoft Defender 오탐 대응과 성능 영향에 대처하는 법

‘고객사 단말에서 저희 앱이 바이러스로 취급되어 삭제되었습니다’ ── 자사 개발·수탁 개발 Windows 앱을 배포하다 보면, 언젠가는 이런 연락을 받는 날이 옵니다. 어제까지 아무 문제 없이 동작하던 업무용 앱이, Defender의 정의 업데이트를 계기로 갑자기 격리됩니다. 개발 머신에서는 아무 일도 일어나지 않는데, 고객 환경에서만 탐지됩니다. 멀웨어 따위를 작성한 기억은 없는데도 말입니다.

이는 드문 사고가 아닙니다. 현대의 백신 소프트웨어는 ‘알려진 멀웨어와 일치하는가’뿐 아니라, 머신러닝·행동·클라우드상의 평판(레퓨테이션)으로 ‘수상함’을 추정하기 때문에, 실적이 없는 정규 바이너리가 의심받는 것은 구조상 피할 수 없는 일입니다. 그리고 오탐 대응에는 해도 되는 일(Microsoft에 대한 오탐 신고, 제한적인 제외)과 해서는 안 되는 일(백신 비활성화, 광범위한 제외)이 뚜렷하게 나뉩니다.

이 글에서는 오탐이 발생하는 구조, 배포 전에 할 수 있는 예방, 탐지되었을 때의 정규 대응 경로, 고객 환경에서의 응급 대응으로서의 제외 설정과 그 위험, 그리고 또 다른 단골 상담인 ‘Defender(MsMpEng.exe)가 무겁다’에 대처하는 법을, 개발자의 시점에서 정리합니다.

긴 글이므로 상황별 진입점을 먼저 안내합니다. 고객 대응 도중 지금 당장 조치를 취하고 싶은 정보시스템·지원 담당자는 4장(정규 대응 경로)과 5장(제외 설정법과 위험)부터, 앞으로 배포할 앱에서 오탐을 예방하고 싶은 개발자는 3장부터, ‘Defender가 무겁다’는 상담을 받고 있는 분은 6장부터 읽어 주세요. 증상별 조견표는 7장에 있습니다.

1. 먼저 결론

• 정규 앱이라도 오탐은 일어날 수 있습니다. Defender는 2015년 이후 정적 시그니처 중심 엔진에서 머신러닝·클라우드 보호를 활용하는 예측형 모델로 이행했으며, 알려지지 않은 파일은 기지의 악성과 일치하지 않아도 ‘수상함’으로 판정됩니다.¹²
• 항구 대응의 정규 경로는 Microsoft에 대한 파일 신고(오탐 신고)입니다. Microsoft Security Intelligence의 샘플 신고 포털에서 개발자로 제출하고 판정을 추적합니다. 판정에 이의가 있으면 개발자용 연락 양식으로 재조사를 요청할 수 있습니다.³⁴
• 격리된 파일은 복원할 수 있습니다. Windows 보안의 ‘보호 기록’에서, 또는 명령줄의 MpCmdRun.exe -Restore로 되돌립니다.⁵
• 제외 설정은 ‘신고 결과가 나올 때까지의 임시 대응’입니다. 제외는 보호의 구멍(protection gap)이며, Microsoft는 ‘절제해서・특정 문제에만・정기적으로 재검토하며’ 사용하도록 명시하고 있습니다. 설정한다면 전체 경로 지정으로 최소 범위로 하고, 기록을 남깁니다.⁶
• 예방의 기둥은 일관된 코드 서명입니다. Microsoft에는 오탐 방지를 위한 사전 등록 프로그램이 없으며, 신뢰된 루트 인증 기관의 인증서로 일관되게 서명을 계속하는 것이, 출처 특정과 기지 목록 편입을 앞당기는 공식적으로 안내된 방법입니다.⁴
• 릴리스 전 자체 스캔과 사전 신고로 ‘실적 제로’를 줄일 수 있습니다. MpCmdRun.exe의 커스텀 스캔으로 배포물을 검사할 수 있으며, 알려지지 않은 파일을 미리 샘플 신고해 두는 것은 평판(레퓨테이션) 확립을 시작하는 수단이라고 Microsoft 스스로 안내하고 있습니다.⁷⁸
• ‘Defender가 무겁다’는 먼저 측정입니다. Performance analyzer(New-MpPerformanceRecording / Get-MpPerformanceReport)로 어떤 파일·프로세스가 스캔 부하의 중심인지 특정한 뒤 대책을 생각합니다. 제외는 여기서도 최후의 수단입니다.⁹¹⁰

2. 정규 앱이 왜 바이러스로 오탐되는가

‘백신 소프트웨어 = 알려진 바이러스의 패턴(시그니처)과 대조하는 것’이라는 이해에 머물러 있으면, 오탐은 이해하기 어려운 현상으로 보입니다. 하지만 현대의 Defender는 다릅니다. Microsoft는 2015년에 정적 시그니처 기반 엔진에서, 머신러닝·응용 과학·AI와 같은 예측 기술을 사용하는 모델로 이행했다고 명언하고 있습니다.¹

탐지는 여러 계층에서 이루어집니다. 단말 위에서는 경량 머신러닝 모델·행동 분석·휴리스틱이 동작하고, 단말만으로는 흑백을 가릴 수 없는 파일은 메타데이터가 클라우드 보호 서비스로 전송되어 대부분의 경우 밀리초 단위로 판정이 돌아옵니다. 그래도 판정할 수 없는 경우에는 파일 샘플 전송을 요청하고, 클라우드 측에서 스캔·디토네이션(격리 환경에서의 실행)·빅데이터 분석을 수행합니다. ‘block at first sight(초회 탐지 시 차단)’가 활성화된 환경에서는, 클라우드의 판정이 나올 때까지 파일 열기가 일시적으로 보류되기도 합니다.²¹¹

이 구조가 의미하는 바는 명확합니다. 판정 재료는 ‘악성과의 일치’뿐 아니라 ‘무해하다는 실적’도 포함한다는 것입니다. Microsoft의 분류 기준에는 ‘Unknown(인식되지 않는 소프트웨어)’이라는 카테고리가 명시되어 있으며, 알려지지 않았거나 다운로드 실적이 적은 프로그램에 대한 경고는 ‘아직 탐지되지 않은 멀웨어에 대한 조기 경보 시스템’으로 자리매김되어 있습니다. 드문 프로그램이 모두 악성인 것은 아니지만, 알려지지 않은 카테고리의 위험은 일반 사용자에게 높다는 것이 공식적인 정리입니다.⁸

즉, 갓 릴리스된 자사 앱은 Windows의 보안 메커니즘에서 보면 ‘전 세계에서 아무도 실행한 적 없는, 실적 제로의 바이너리’입니다. 그 위에 다음과 같은 특징이 겹치면 의심은 강해집니다.

• 코드의 실체를 감추는 구조. Microsoft의 멀웨어 분류에는 코드와 목적을 감춰 탐지를 어렵게 만드는 ‘Obfuscator(난독화)’라는 유형이 있으며, 보안 제품의 탐지를 적극적으로 회피하려는 소프트웨어는 원치 않는 애플리케이션(PUA)의 한 분류이기도 합니다. 난독화 도구나 자기 해제 형식, 런타임을 하나의 exe에 동봉하는 유형의 패키징은 멀웨어가 흔히 사용하는 구조와 외형상 구분이 어려워, 정규 앱이라도 경계 대상이 되기 쉬운 영역입니다.⁸
• 서명이 없어 출처를 추적할 단서가 없다. 다음 장에서 설명하듯, 일관된 서명은 조사 측이 출처를 특정하는 주요 단서입니다.⁴
• 설치 프로그램이 다른 소프트웨어를 동봉하고 있다. 동일 개발사가 아닌 소프트웨어나 동작에 불필요한 소프트웨어의 설치를 제안하는 것은 ‘Bundling software’로서 PUA 분류의 대상입니다.⁸

덧붙여, 다운로드 직후에 뜨는 ‘Windows에 의해 PC가 보호되었습니다’라는 파란 경고는, Defender 백신의 탐지와는 다른 메커니즘(Microsoft Defender SmartScreen)입니다. Microsoft의 개발자용 FAQ에서도 SmartScreen은 Defender 백신과는 무관하다고 명시되어 있습니다.⁴ SmartScreen과 평판에 관한 이야기는 Windows에서 ‘Windows에 의해 PC가 보호되었습니다’가 나타나는 이유에서 자세히 정리했으니, 경고의 종류가 어느 쪽인지부터 구분해 주세요.

3. 배포 전에 할 수 있는 예방

3.1. 일관된 코드 서명 ── 사전 등록 프로그램은 존재하지 않는다

‘오탐되지 않도록 미리 Microsoft의 화이트리스트에 등록할 수 없을까’라는 발상은 자연스럽지만, 답은 ‘아니오’입니다. Microsoft는 개발자로부터의 기지 목록 등록·오탐 방지 프로그램 신청을 받고 있지 않습니다. 대신 공식 FAQ가 안내하는 것은, 신뢰된 루트 인증 기관이 발급한 인증서로, 프로그램의 파일군에 일관되게 서명을 계속하는 것입니다. 일관된 서명이 있으면 조사 팀이 프로그램의 출처를 빠르게 특정해 과거의 지식을 적용할 수 있고, 그 결과 프로그램이 기지 목록에 빠르게 추가되는 경우가 있으며, 빈도는 낮지만 인증서 자체가 신뢰된 발행자 목록에 오르는 경우도 있다고 합니다.⁴

뒤집어 말하면, 서명의 효과는 ‘파일 단위의 실적’을 ‘발행자 단위의 실적’으로 묶는 데에 있습니다. 빌드할 때마다 해시가 바뀌는 실행 파일은 파일 단위로 보면 매번 ‘처음 보는 파일’이지만, 같은 인증서로 서명되어 있다면 출처는 연속됩니다. 서명의 실무(인증서 종류, Azure Artifact Signing, 타임스탬프)는 위의 SmartScreen 글과 Windows 앱 개발에서 최저한의 보안을 지키기 위한 체크리스트를 참조해 주세요.

3.2. 릴리스 전에 직접 스캔하기

배포한 뒤 고객 환경에서 탐지되는 것보다, 릴리스 판정의 일부로서 자신의 빌드 산출물을 미리 스캔해 두는 편이 훨씬 저렴합니다. Defender에는 명령줄 도구 MpCmdRun.exe가 있으며, 스크립트나 예약 작업을 통한 자동화에 사용할 수 있습니다. 기본적으로 PATH에는 포함되어 있지 않으므로, %ProgramData%\Microsoft\Windows Defender\Platform\<버전>(없다면 %ProgramFiles%\Windows Defender)으로 이동한 뒤 실행합니다.⁷

rem 관리자 권한의 명령 프롬프트에서 실행
cd /d "C:\ProgramData\Microsoft\Windows Defender\Platform\<최신 버전 폴더>"

rem 릴리스 폴더를 커스텀 스캔(-ScanType 3)
rem -DisableRemediation: 탐지하더라도 격리 등의 조치를 하지 않고, 결과를 명령 출력에 표시
MpCmdRun.exe -Scan -ScanType 3 -File "C:\Release\MyApp" -DisableRemediation

반환값은 0과 2가 정의되어 있는데, 게이트로 사용할 때 놓치기 쉬운 점은 0이 ‘탐지 없음’뿐 아니라 ‘탐지했지만 복구에 성공함’도 포함한다는 것입니다. 순수한 -Scan 그대로라면, Defender가 릴리스 산출물을 탐지하여 격리까지 마쳤는데도 반환값은 0으로 ‘깨끗함’으로서 파이프라인을 통과하는, 최악의 조합이 발생할 수 있습니다. 커스텀 스캔에서는 -DisableRemediation을 붙여 탐지 시 조치를 하지 않는 구성으로 하고(탐지 결과는 명령 출력에 표시됩니다), ‘2가 반환되면 출하를 멈추고 조사한다’는 판정에 더해, 명령 출력의 탐지 여부와 산출물 파일이 누락되지 않았는지 확인하는 것까지 게이트에 포함해 주세요.⁷

3.3. 알려지지 않은 파일을 미리 신고해 두기

Microsoft는 알려지지 않았거나 의심스러운 소프트웨어의 샘플 신고에 대해 ‘시스템에 의한 스캔을 받게 하여 평판 확립을 시작하는 데 도움이 된다’고 명언하고 있습니다.⁸ 즉 샘플 신고 포털은 탐지된 후에 이용하는 마지막 수단인 동시에, 실적 제로인 새 바이너리에 최초의 실적을 만드는 예방 수단이기도 합니다. 큰 릴리스(메이저 버전, 패키징 방식 변경, 난독화 도구 도입 등 외형이 크게 바뀌는 시점)에서는 배포를 시작하기 전에 신고해 두는 것이 가치가 있습니다.

4. 오탐되었을 때의 정규 대응 경로

4.1. 먼저 사실 확인 ── 보호 기록과 이벤트 로그

‘사라졌다’, ‘실행되지 않게 되었다’는 보고가 정말로 Defender의 탐지에 의한 것인지 먼저 확인합니다. GUI에서는 Windows 보안의 ‘바이러스 및 위협 방지’ → ‘보호 기록’에 탐지와 격리 기록이 남으며, 격리된 항목의 필터 표시도 가능합니다.⁵

로그로 남기고 싶은 경우·원격으로 확인하고 싶은 경우에는 이벤트 로그입니다. Defender의 이벤트는 ‘애플리케이션 및 서비스 로그 → Microsoft → Windows → Windows Defender → Operational’에 기록되며, PowerShell의 Get-WinEvent로도 가져올 수 있습니다.¹² 탐지 자체는 이벤트 ID 1116(멀웨어 또는 원치 않는 소프트웨어 탐지), 그에 대한 격리 등의 조치는 ID 1117로 기록됩니다.¹³

# Defender의 탐지(1116)와 조치(1117) 이벤트를 최신순으로 확인
# 필터링은 이벤트 로그 쪽에서 수행(-FilterHashtable). 파이프 뒤의 Where-Object보다 빠름
Get-WinEvent -FilterHashtable @{
    LogName = 'Microsoft-Windows-Windows Defender/Operational'
    ID      = 1116, 1117
} -MaxEvents 10 |
    Select-Object TimeCreated, Id, Message

여기서 위협 이름(예: Trojan:Win32/Wacatac.B!ml과 같은 탐지명)과 탐지된 파일의 경로·버전을 기록해 두세요. Microsoft에 대한 신고에서도 고객에 대한 설명에서도, 이 두 가지가 출발점이 됩니다. 탐지명의 구조(유형/플랫폼/패밀리명)는 CARO(Computer Antivirus Research Organization) ── 백신 연구자들로 구성된 단체로, 그 명명 규칙이 업계에서 널리 사용되고 있습니다 ── 의 멀웨어 명명 규칙을 따르고 있으며, 끝의 !ml과 같은 접미사에서 탐지의 유래를 추측할 수 있는 경우도 있습니다.¹⁴

4.2. Microsoft에 오탐을 신고하기

항구 대응은 이것입니다. Microsoft Security Intelligence의 샘플 신고 포털(microsoft.com/wdsi/filesubmission)에서 잘못 탐지된 파일을 제출합니다. 신고에는 로그인이 필요하며, 로그인하면 신고의 판정 상태를 추적할 수 있습니다. 이메일을 통한 샘플 접수는 이루어지지 않습니다.³

처음 사용할 때 헤매기 쉬우므로, 공식 문서에 적힌 범위 안에서 절차의 뼈대를 정리해 둡니다.³⁴¹⁵

1. 로그인한다. 샘플 신고 포털은 로그인 없이는 제출할 수 없습니다. 2024년 5월 20일 이후, 이 포털의 로그인은 Microsoft Entra ID로 이전되었습니다. 조직의 테넌트가 관리자 동의를 요구하는 설정으로 되어 있는 경우, 대상 앱에 대한 접근 권한을 IT 관리자에게 요청해야 합니다.
2. 오탐된 파일을 업로드한다. 함께 사용 중이던 제품(Microsoft Defender 백신 등)과, 어떤 상황에서 그 파일과 마주쳤는지를 자세히 적습니다. 여기에 적은 정보가 그대로 분석 재료가 되므로, 4.1에서 확정한 탐지명·파일 경로·버전을 첨부합니다.
3. 제출자 구분을 software developer(소프트웨어 개발자)로 한다. 이 구분으로 제출해 두면, 판정에 이의가 있는 경우를 위한 개발자용 연락 양식이 신고 결과에 첨부됩니다.
4. Software Assurance ID(SAID)를 가지고 있다면 입력한다. 포털은 SAID를 받아들이며, 유효한 SAID를 가진 고객은 더 높은 우선순위로 제출할 수 있습니다. 고객사가 이를 보유하고 있는 경우, 고객 측에서 제출하도록 하는 편이 더 빠를 수도 있습니다.
5. 제출 후에는 신고 이력 페이지(microsoft.com/wdsi/submissionhistory)에서 상태를 추적한다. 상태는 Submitted(접수됨) / In progress(분석가가 확인을 시작함) / Closed(최종 판정이 나옴)의 3가지입니다. 판정이 갱신되지 않았는지 확인하고 싶을 때는, 신고 상세 페이지에서 재스캔(rescan)을 선택합니다.
6. 최종 판정을 기다리고, 이의가 있으면 재조사를 요청한다. 판정이 확정될 때까지 기다리고, 결과에 납득할 수 없는 경우 신고 결과에 첨부되는 개발자용 연락 양식을 통해 Microsoft에 연락합니다.

화면의 항목명이나 배치는 갱신될 수 있으므로, 헷갈리면 공식 문서의 안내를 확인해 주세요. 또한 제출된 파일은 먼저 자동 시스템으로 즉시 스캔되며, 이미 처리된 파일이라면 조기에 판정이 나옵니다. 미처리 신고는 영향 범위가 큰 파일이나, Software Assurance ID를 가진 엔터프라이즈 고객으로부터의 신고가 우선되는 형태로 분석됩니다.¹⁵

오탐으로서 Microsoft가 정의를 업데이트하면, 그 파일은 이후로 탐지되지 않게 됩니다. 반대로 말하면, 신고하지 않는 한 제외 설정으로 버텨도 다른 고객 환경에서는 계속 탐지됩니다. 참고로 파일로 남지 않는 행동 기반 탐지의 경우에도, MpCmdRun.exe -GetFiles로 생성할 수 있는 진단 파일(MpSupportFiles.cab)을 제출하여 분석을 요청하는 경로가 마련되어 있습니다.¹⁵⁷

고객이 Microsoft Defender for Endpoint(EDR)를 도입한 조직이라면, 고객 측 보안 관리자가 Microsoft Defender 포털의 신고(Submissions) 페이지에서 제출하고, 아울러 ‘허용’ 인디케이터로 조직 내 오탐을 억제하는 관리자 경로도 있습니다.¹⁵ 이 경우에는 자사만으로 완결시키지 말고 고객의 IT 부서와 연계해 주세요.

4.3. 격리된 파일 복원하기

오탐이라고 확신할 수 있는 파일은 격리에서 복원할 수 있습니다. GUI에서는 보호 기록에서 대상을 선택하여 ‘복원’합니다. 명령줄에서는 MpCmdRun.exe를 사용합니다.⁵

rem 격리되어 있는 항목 목록
MpCmdRun.exe -Restore -ListAll

rem 격리 당시의 파일 경로를 지정하여 원래 위치로 복원
MpCmdRun.exe -Restore -FilePath "C:\Program Files\Contoso\ContosoApp\ContosoApp.exe"

-Path 옵션으로 복원 위치를 다른 폴더로 지정할 수도 있습니다(이 경우 항목은 격리에도 남습니다).⁷ 다만 정의가 업데이트되기 전에 복원하면 당연히 다시 탐지될 수 있으므로, 실무에서는 ‘오탐 신고 → 필요하면 임시 제외 → 복원’의 순서로 진행하는 것이 안전합니다.

4.4. 타사 백신 소프트웨어에서 탐지된 경우

Defender가 아니라 EDR이나 타사 백신 제품에서의 탐지는 Microsoft에 신고해도 해결되지 않습니다. 탐지한 제품의 벤더마다 오탐 신고(false positive submission) 창구에 개별적으로 신청해야 합니다. 많은 벤더가 전용 양식을 마련해 두고 있으므로, ‘벤더명 + false positive submission’으로 창구를 찾아, Defender의 경우와 마찬가지로 탐지명·파일·서명 정보를 첨부하여 신청해 주세요. 여러 제품에서 동시에 탐지된 경우에는 빌드 쪽의 요인(난독화·패커·동봉물)을 의심할 근거가 되기도 합니다.

5. 고객 환경에서의 응급 대응 ── 제외 설정과 그 위험

5.1. 제외의 위치 ── 항구 대응이 아니다

오탐 신고의 판정이 나올 때까지 고객의 업무가 멈춘다는 상황에서는, Defender의 제외(exclusion)가 응급 처치가 됩니다. 다만 위치를 착각해서는 안 됩니다. Microsoft 스스로 거듭 경고하고 있듯이, 제외는 기술적으로 보호의 구멍(protection gap)이며, (1) 절제해서 사용한다, (2) 성능 문제나 앱 호환성 등 특정 문제에만 사용한다, (3) 왜 그 제외가 필요했는지 경위를 남기고 정기적으로 재검토한다가 공식 원칙입니다.⁶ 참고로 여기서 설명하는 제외는 Defender 백신의 스캔(예약/온디맨드/실시간 보호)에 대한 제외입니다. Microsoft Defender for Endpoint를 도입한 환경에서는 제외한 파일이라도 EDR의 경고나 그 밖의 탐지는 계속 발생할 수 있습니다.¹⁶ ‘제외를 넣었는데 경고가 뜬다’는 이 사양에 의한 것이며 고장이 아닙니다.

그리고 제외를 넣는다 해도, 실시간 보호 자체나 Defender 전체를 비활성화하는 제안은 논외입니다. 그 단말의 방어는 앱 이외의 위협에 대해서도 통째로 낮아집니다. 오탐 대응이라는 명목으로 보안 기능의 비활성화를 고객에게 요청한 이력은, 훗날의 보안 감사에서 반드시 문제가 됩니다.

5.2. 올바르게 설정하는 법 ── 전체 경로로 최소 범위

제외는 Windows 보안의 GUI(바이러스 및 위협 방지 설정 → 제외)에서도 추가할 수 있지만, 절차서로 만든다면 PowerShell이 확실합니다. 제외 목록 관리에는 Add-MpPreference(추가), Remove-MpPreference(삭제), Set-MpPreference(목록 전체를 교체)를 사용합니다. Set-MpPreference는 기존 제외 목록을 덮어쓰기 때문에, 고객 환경에서 기존 제외를 지워버리지 않도록 추가할 때는 반드시 Add-MpPreference를 사용해 주세요.¹⁶

# 관리자 권한의 PowerShell에서 실행

# 파일 단위의 제외(최소 범위. 폴더가 아닌 실행 파일을 전체 경로로)
Add-MpPreference -ExclusionPath "C:\Program Files\Contoso\ContosoApp\ContosoApp.exe"

# 현재 제외 설정 확인
Get-MpPreference | Select-Object ExclusionPath, ExclusionProcess, ExclusionExtension

# 오탐이 해소되면 철거한다
Remove-MpPreference -ExclusionPath "C:\Program Files\Contoso\ContosoApp\ContosoApp.exe"

-ExclusionPath는 파일 단위로도 폴더 단위로도 지정할 수 있지만, 폴더를 지정하면 하위 폴더까지 통째로 대상이 되므로 먼저 파일 단위를 검토합니다.¹⁶ 또 하나의 -ExclusionProcess는 이름 때문에 오해하기 쉬운 옵션으로, 지정한 프로세스 자신을 제외하는 것이 아니라, 그 프로세스가 여는 파일을 스캔 대상에서 제외하는 것입니다. 프로세스의 실행 파일 자체를 제외하고 싶다면 -ExclusionPath를 사용한다는 것이 공식적인 정리입니다.¹⁷ 앱이 대량의 데이터 파일을 여는 탓에 탐지나 성능 문제가 발생하는 경우에는 -ExclusionProcess, 실행 파일 자체가 오탐되는 경우에는 -ExclusionPath로 나누어 사용합니다.

의도한 대로 제외되었는지는 MpCmdRun.exe -CheckExclusion -Path <경로>로 검증할 수 있습니다.⁷ 또한 관리되는 환경에서는 엔드포인트마다 수동으로 넣는 것이 아니라, Intune이나 그룹 정책(컴퓨터 구성 → 관리 템플릿 → Windows 구성 요소 → Microsoft Defender 백신 → 제외)으로 중앙 관리하는 것이 전제입니다. Microsoft는 제외의 정의·편집에 Intune 사용을 권장하고 있습니다.¹⁶¹⁵

5.3. 해서는 안 되는 제외

제외 폴더는 ‘Defender가 보지 않는 곳’으로서 공격자에게도 이용됩니다. Microsoft는 ‘설령 악의가 없다고 신뢰하더라도 제외해서는 안 되는’ 항목을 구체적으로 열거하고 있습니다.¹⁸

• C:\, C:\Temp, C:\Users\, %Windir%\Temp와 같은 범용 폴더의 제외. 자사 앱을 위해 임시 폴더를 통째로 제외하는 것은 모든 멀웨어에 안전지대를 제공하는 행위입니다.
• .exe, .dll, .tmp, .zip와 같은 확장자 단위의 제외.
• cmd.exe, powershell.exe, msbuild.exe, java.exe와 같은 범용 프로세스의 제외.
• 경로 없이 파일 이름만으로 하는 제외(예: ContosoApp.exe). 동일한 이름의 멀웨어가 어디에 놓이더라도 제외되어 버리므로, 반드시 전체 경로로 지정합니다.

정리하면, 제외는 ‘전체 경로로・최소 범위로・기록을 남기고・기한을 정해서’입니다. 제외를 넣은 사실과 이유는 고객 측 IT 관리자와 공유하고, 오탐 신고의 판정이 나와 탐지되지 않는 것을 확인하면 철거합니다.

6. 성능 영향에 대처하는 법 ── ‘MsMpEng.exe가 무겁다’

오탐과 나란한 또 하나의 단골 상담이 성능입니다. 작업 관리자에서 MsMpEng.exe(Antimalware Service Executable)가 CPU를 잡아먹는다, 앱의 파일 출력이나 빌드가 느리다는 증상입니다. MsMpEng.exe는 Defender 백신의 서비스 본체로, 실시간 보호의 기본 동작은 ‘파일을 여는 시점에 동기적으로 스캔한다(open now, scan now)’입니다.¹⁹ 대량의 작은 파일을 열고 닫는 워크로드 ── 빌드, 잦은 로그 기록, 임시 파일의 과다 사용 ── 일수록 스캔 횟수가 늘어나, 영향을 받기 쉬운 구조라는 것입니다.

6.1. 먼저 측정 ── Performance analyzer

‘무거우니까 제외’로 곧장 가기 전에, 무엇이 스캔 부하의 중심인지를 측정합니다. Defender에는 전용 Performance analyzer가 있으며, PowerShell의 New-MpPerformanceRecording으로 스캔의 성능 기록(ETL)을 채취하고, Get-MpPerformanceReport로 집계할 수 있습니다.⁹

# 관리자 권한의 PowerShell에서 실행

# 기록을 시작하고, 무거운 작업(빌드, 배치 처리 등)을 재현한 뒤 Enter로 중지
New-MpPerformanceRecording -RecordTo .\Defender-scans.etl

# 스캔 시간 상위 파일과, 해당 파일에 대한 스캔 내역을 표시
Get-MpPerformanceReport -Path .\Defender-scans.etl -TopFiles 3 -TopScansPerFile 10

-TopFiles / -TopScansPerFile 외에도 프로세스별·확장자별 집계도 얻을 수 있으므로, ‘자사 앱의 어떤 파일 접근이 스캔을 유발하는지’를 구체적으로 특정할 수 있습니다.

출력 내용은 환경마다 크게 달라지므로, 여기서는 무엇이 나열되는지와 어디를 볼지를 정리합니다. 공식 문서에 따르면 리포트에는 다음 정보가 나옵니다.⁹

어떤 리포트든 소요 시간의 내림차순으로 정렬됩니다. 읽는 순서는, 먼저 -TopFiles나 -TopProcesses로 상위를 훑어보고, 짚이는 게 있으면 -TopScansPerFile로 해당 파일의 개별 스캔을 여는 것입니다. 건수가 많아 보기 어려울 때는 -MinDuration 100ms처럼 하한을 설정해 노이즈를 줄일 수 있습니다.¹⁰ 기록을 다른 도구로 처리하고 싶은 경우에는 다음과 같이 CSV로 내보낼 수 있습니다.⁹

# 스캔 단위의 원본 데이터를 상위 1000건까지 CSV로 출력
(Get-MpPerformanceReport -Path .\Defender-scans.etl -TopScans 1000).TopScans |
    Export-Csv -Path .\Defender-scans.csv -Encoding UTF8 -NoTypeInformation

여기까지 확인한 뒤의 판단은, ‘상위에 오는 것이 자사 앱의 산출물인가’입니다. 자사 앱의 임시 파일이나 로그가 상위를 차지한다면, 다음의 6.2대로 먼저 앱 쪽에서 줄일 수 없는지를 생각합니다. 개발 머신의 빌드 출력이나 패키지 캐시가 상위라면 6.3의 Dev Drive가 효과적입니다. 제외를 검토하는 것은 그 어느 쪽으로도 해소되지 않은 경우뿐입니다. 주의할 점은, 이 도구는 문제 파일에 대한 통찰을 얻기 위한 것이며 제외를 제안하기 위한 것이 아니다라고 공식 문서 스스로 못을 박고 있습니다.¹⁰

6.2. 제외하기 전에 앱 쪽에서 할 수 있는 일

측정 결과 ‘자사 앱이 써내는 대량의 임시 파일이 스캔의 중심’이라는 것을 알았다면, 제외를 하기 전에 앱의 쓰기 패턴을 재검토할 여지가 있습니다. 실시간 보호가 파일 열기를 계기로 동작하는 이상¹⁹, 다음과 같은 설계 변경은 스캔 횟수 자체를 줄입니다.

• 수천 개의 작은 중간 파일을 열고 닫는 처리를, 소수의 파일에 대한 추가 기록이나 메모리 내 처리로 통합한다
• ‘임시 파일을 쓰고 이름을 바꾸거나 삭제’하는 패턴의 반복을 줄인다
• 로그를 한 줄마다 열고 닫는 구현을 그만두고, 스트림을 연 채로 기록한다

어떤 프로세스가 어떤 파일을 어느 정도의 빈도로 건드리는지에 대한 실측에는 Process Monitor를 그대로 사용할 수 있습니다. 절차는 Process Monitor(ProcMon) 실전 가이드 ── 「설정이 반영되지 않는다」「ACCESS DENIED」를 10분 만에 특정하기를 참조해 주세요.

6.3. 개발 머신이라면 Dev Drive의 퍼포먼스 모드

개발 머신의 빌드가 느리다는 맥락에서는 Windows 11의 Dev Drive + 퍼포먼스 모드가 첫 번째 후보입니다. Dev Drive(ReFS 기반 개발용 볼륨) 위에서는, Defender의 실시간 보호가 비동기적인 ‘퍼포먼스 모드’로 동작합니다. 파일을 열 때 동기적으로 스캔하는 대신, 열기가 완료된 뒤 지연하여 스캔하는 ‘open now, scan later’ 방식으로, 폴더 제외처럼 스캔을 완전히 멈추는 방법보다 훨씬 높은 보호를 유지한 채 성능을 개선할 수 있다고 공식 문서가 자리매김하고 있습니다.¹⁹ 소스 트리, 패키지 캐시, 빌드 출력을 Dev Drive로 옮기는 것이 정석입니다.²⁰

만드는 방법도 알아 두면 움직이기 쉬워집니다. 전제 조건과 절차는 공식 문서에 다음과 같이 나와 있습니다.²⁰

• 전제 조건: Windows 11(빌드 10.0.22621.2338 이상), 여유 용량 50GB 이상(Dev Drive의 최소 크기가 50GB), 메모리는 8GB 이상·16GB 권장, 로컬 관리자 권한. 기업 환경에서는 보안 관리자에 의한 그룹 정책 설정이 필요한 경우가 있습니다.
• GUI로 만들기: 설정 > 시스템 > 저장소 > 저장소 고급 설정 > 디스크 및 볼륨에서 ‘Dev Drive 만들기’를 선택합니다. 새 VHD 만들기/기존 볼륨 축소/할당되지 않은 공간 사용의 3가지 중에서 선택할 수 있습니다.
• 명령줄로 만들기: 관리자 권한으로 Format D: /DevDrv /Q(명령 프롬프트/PowerShell) 또는 Format-Volume -DriveLetter D -DevDrive(PowerShell). 여러 대에 배포할 때는 이쪽이 편리합니다.
• 주의: 기존 볼륨을 Dev Drive로 변환할 수는 없습니다. Dev Drive 지정은 포맷 시에만 가능하며, 기존 볼륨을 다시 포맷하면 내용물은 사라집니다. 또한 C: 드라이브는 Dev Drive로 만들 수 없습니다. 개발 도구나 SDK 자체는 C:에 두고, Dev Drive에는 소스 코드·패키지 캐시·빌드 출력을 두는 것이 공식적인 전제입니다.
• 신뢰 설정하기: 퍼포먼스 모드가 작동하는 것은 ‘신뢰됨(trusted)’ 상태의 Dev Drive뿐입니다. 보통은 생성 시에 자동으로 신뢰됨 상태가 되지만, 확인이나 재설정은 fsutil devdrv query D:와 fsutil devdrv trust D:로 할 수 있습니다(다른 PC로 VHD를 옮긴 경우 등에는 신뢰 지정을 다시 해야 합니다).

다만 퍼포먼스 모드는 Dev Drive 위에서만 동작하며, 실시간 보호가 활성화되어 있는 것이 전제입니다. 또한 ‘MsMpEng.exe의 CPU/메모리 사용률이 높다’는 증상에 대한 대처는 퍼포먼스 모드의 수비 범위가 아니며, 그 경우에는 앞서 설명한 Performance analyzer로 핫한 프로세스·경로를 좁혀 나가는 것이 공식적인 안내입니다.¹⁹

이 밖에 온디맨드 스캔(정기 전체 스캔 등)이 업무 시간대에 무겁다는 경우에는, MpCmdRun.exe -Scan에 -CpuThrottling 스위치가 있다는 것도 알아 두면 도움이 됩니다. 붙이면 스캔의 CPU 사용률에 상한(기본값 50%)이 적용됩니다.⁷ 다만 스위치에 숫자를 넘겨 임의의 비율을 지정하는 형식은 아닙니다. 상한값 자체는 정책 쪽 설정(ScanAvgCPULoadFactor)으로 구성하는 것으로, 이 값은 하드 리밋이 아니라 ‘평균적으로 이 비율을 넘지 않도록 한다’는 스캔 엔진에 대한 기준입니다.²¹

7. 판단표 ── 증상별 취해야 할 행동

어느 사례든 공통되는 것은, ‘먼저 사실(탐지명·대상·탐지한 제품)을 확정한다’, ‘신고라는 항구 대응을 반드시 진행한다’, ‘제외·복원은 임시 대응으로서 최소 범위에서’라는 3가지 점입니다.

8. 정리

• 현대의 Defender는 시그니처 대조가 아니라 머신러닝·클라우드 보호·실적(레퓨테이션)으로 판정합니다. 실적 제로인 새 바이너리가 의심받는 것은 구조상 필연이며, 난독화나 자기 해제와 같은 ‘실체를 감추는’ 구조는 더욱 의심받기 쉽습니다.
• 예방의 기둥은 신뢰된 인증 기관의 인증서에 의한 일관된 코드 서명입니다. 사전 등록을 통한 오탐 방지 프로그램은 존재하지 않습니다. 릴리스 전 MpCmdRun.exe를 이용한 자체 스캔과, 외형이 크게 바뀌는 릴리스에서의 사전 샘플 신고도 효과적입니다.
• 탐지되면 보호 기록과 이벤트 로그(ID 1116/1117)로 탐지명과 대상을 확정하고, Microsoft Security Intelligence의 샘플 신고 포털에 개발자로서 제출합니다. 격리된 파일은 보호 기록 또는 MpCmdRun.exe -Restore로 복원할 수 있습니다.
• 제외 설정은 신고의 판정이 나올 때까지의 임시 대응입니다. 전체 경로로 최소 범위, 기록을 남기고 해소되면 철거. 임시 폴더나 확장자, 범용 프로세스의 제외는 멀웨어의 은신처를 만들기 때문에 엄금입니다.
• 성능 문제는 먼저 Performance analyzer로 측정하고, 앱 쪽의 쓰기 패턴 개선과 Dev Drive의 퍼포먼스 모드를 검토한 뒤, 그래도 필요한 경우에만 제한적인 제외를 생각합니다. 실시간 보호의 비활성화를 고객에게 요청하는 것은 논외입니다.

관련 글

• Windows에서 ‘Windows에 의해 PC가 보호되었습니다’가 나타나는 이유
• 자동 업데이트 기능의 보안 기본 - 나쁜 패턴과 베스트 프랙티스
• Windows 앱 개발에서 최저한의 보안을 지키기 위한 체크리스트
• Windows 앱의 배포 방식을 어떻게 고를까 - MSI / MSIX / ClickOnce / xcopy / 자체 updater의 판단표
• Process Monitor(ProcMon) 실전 가이드 ── 「설정이 반영되지 않는다」「ACCESS DENIED」를 10분 만에 특정하기

관련 상담 영역

합동회사 코무라소프트에서는 배포한 앱의 오탐·SmartScreen 경고에 대한 대응 방침 정리, 코드 서명을 포함한 배포·업데이트 체계 설계, 백신 소프트웨어로 인한 성능 문제의 측정과 원인 구분과 같은 상담을 다루고 있습니다.

• Windows 앱 개발
• 기술 상담・설계 리뷰
• 문의하기

참고 링크

관련 기사

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

관련 토픽

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

이 주제와 연결되는 서비스

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

자주 묻는 질문

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

자체 제작한 앱이 Microsoft Defender에서 바이러스로 판정되었습니다. 어떻게 해야 하나요?

먼저 당황해서 제외 설정을 넣거나 Defender를 비활성화하지 마세요. 항구 대응의 정규 경로는 Microsoft Security Intelligence의 파일 신고 포털(샘플 신고)에서 개발자(software developer)로서 파일을 제출하는 것입니다. 로그인하면 신고의 판정 상태를 추적할 수 있고, 오탐으로 판정되면 정의 업데이트를 통해 이후로는 탐지되지 않게 됩니다. 격리된 파일은 Windows 보안의 '보호 기록' 또는 MpCmdRun.exe의 -Restore로 복원할 수 있습니다.

오탐을 Microsoft에 신고하려면 어떻게 해야 하나요?

Microsoft Security Intelligence의 샘플 신고 포털(microsoft.com/wdsi/filesubmission)에서 파일을 제출합니다. 신고에는 로그인이 필요하며, 제출 후에는 판정 상태를 포털에서 추적할 수 있습니다. 제출된 파일은 먼저 자동 시스템으로 즉시 스캔되고, 필요에 따라 분석가가 분석합니다. 개발자로서 제출했는데 판정에 이의가 있는 경우, 신고 결과에 첨부되는 개발자용 연락 양식을 통해 재조사를 요청할 수 있습니다.

고객 환경에 제외 설정을 넣어 달라고 하는 것은 적절한가요?

오탐 신고 결과가 반영될 때까지의 임시 대응이라면 선택지가 될 수 있지만, 항구 대응으로 삼아서는 안 됩니다. 제외는 Defender의 보호에 구멍을 내는 설정으로, Microsoft 스스로 '절제해서 사용할 것', '특정 문제에만 사용할 것', '정기적으로 재검토할 것'을 명시하고 있습니다. 설정할 경우에는 실행 파일의 전체 경로 등 최소 범위로 한정하고, 누가·왜·언제까지라는 기록을 남기며, 오탐이 해소되면 철거합니다. 폴더 전체나 C:\Temp, 확장자 .exe와 같은 넓은 범위의 제외는 멀웨어의 은신처를 만드는 것과 다름없습니다.

코드 서명을 하면 오탐이 없어지나요?

보장되지는 않지만 크게 효과가 있습니다. Microsoft는 기지(既知) 목록에 대한 사전 등록 같은 오탐 방지 프로그램을 제공하지 않으며, 대신 '신뢰된 루트 인증 기관의 인증서로 일관되게 서명을 계속하는 것'을 권장하고 있습니다. 일관된 서명이 있으면 조사 팀이 프로그램의 출처를 빠르게 특정할 수 있어, 기지 목록에 추가되는 시점이 앞당겨질 수 있습니다. 반대로 서명이 없고 빌드할 때마다 출처를 알 단서가 없는 바이너리는, 실적이 없는 미지의 파일로서 매번 처음부터 의심받습니다.

저자 프로필

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

Go Komura

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

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