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

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

이는 드문 사고가 아닙니다. 현대 바이러스 백신은 「알려진 맬웨어와 일치하는가」뿐 아니라, 머신러닝·행위·클라우드상의 평판(reputation)으로 「수상함」을 추정하기 때문에, 실행 이력이 없는 정상적인 바이너리가 의심받는 일은 구조상 피할 수 없습니다. 그리고 오탐 대응에는 해도 되는 일(Microsoft에 오탐 신고, 한정적인 제외)과 해서는 안 되는 일(바이러스 백신 끄기, 광범위 제외)이 분명히 갈립니다.

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

긴 글이므로 상황별 입구를 먼저 제시합니다. 고객 대응 중에 지금 바로 손을 써야 하는 IT·지원 담당자는 4장(정규 대응 경로)과 5장(제외를 넣는 방법과 위험)부터, 앞으로 배포할 앱에서 오탐을 막고 싶은 개발자는 3장부터, 「Defender가 무겁다」는 상담을 받고 있는 분은 6장부터 읽어 주십시오. 증상별 요약표는 7장에 있습니다.

1. 먼저 결론

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

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

2. 정상적인 앱이 바이러스로 취급되는 이유

「바이러스 백신 = 알려진 바이러스 패턴(시그니처)과 대조하는 것」이라는 이해에 머무르면, 오탐은 납득하기 어렵습니다. 그러나 현대 Defender는 다릅니다. Microsoft는 2015년에 정적 시그니처 기반 엔진에서 머신러닝·응용과학·AI 같은 예측 기술을 쓰는 모델로 전환했다고 분명히 밝히고 있습니다.¹

탐지는 여러 계층에서 이루어집니다. 디바이스 위에서는 가벼운 머신러닝 모델·행위 분석·휴리스틱이 동작하고, 디바이스만으로 판정을 내리지 못하는 파일은 메타데이터가 클라우드 보호 서비스로 보내지며, 대부분의 경우 밀리초 단위로 판정이 돌아옵니다. 그래도 판정하지 못하면 파일 샘플 전송을 요청하고, 클라우드에서 스캔·detonation(격리 환경에서의 실행)·빅데이터 분석에 올립니다. 「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 화이트리스트에 등록할 수 없을까」라는 발상은 자연스럽지만, 답은 No입니다. 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(최종 판정이 나옴)의 세 가지입니다. 판정이 갱신되었는지 확인하려면 제출 상세 페이지에서 재스캔(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) 실전 가이드」를 참조해 주십시오.

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 만들기/기존 볼륨 축소/할당되지 않은 영역 사용의 세 가지에서 고를 수 있습니다.
• 명령줄로 만들기: 관리자 권한으로 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. 판단표 ── 증상별·취해야 할 행동

어떤 경우든 공통인 것은 「먼저 사실(탐지명·대상·탐지한 제품)을 확정한다」「신고라는 근본 대응을 반드시 돌린다」「제외·복원은 임시 대응으로서 최소 범위로」라는 세 가지입니다.

8. 정리

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

관련 글

• Windows에서 「Windows에서 PC를 보호했습니다」가 나오는 이유
• 자동 업데이트의 보안 설계 - HTTPS만으로는 부족한 이유
• Windows 앱 개발의 보안 최소 체크리스트
• Windows 앱 배포 방식 고르기 - MSI/MSIX/ClickOnce/xcopy/독자 업데이트
• 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 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.