Windows Defender 가 우리 앱을 삭제했다 — 오탐 전말

2026년 9월 10일, Windows Defender 가 울타리 NEO 를 악성코드로 분류해 사용자 PC 에서 삭제했습니다. 실행 파일뿐 아니라 시작 메뉴 바로가기와 레지스트리 항목까지 함께 지웠습니다. 이 글은 무슨 일이 있었고, 저희가 무엇을 측정했고, 무엇을 틀렸는지에 대한 기록입니다.

무슨 일이 있었나

최신 판(build 65)을 설치한 직후 Windows 보안이 다음 이름으로 탐지했습니다.

사용자 PC: Trojan:Win32/Sabsik.FL.A!ml
마이크로소프트 제출 후 클라우드 검사: Trojan:Win32/Wacatac.C!ml

두 이름 모두 끝에 !ml 이 붙어 있습니다. 머신러닝 모델의 판정이라는 뜻입니다. 사람이 만든 시그니처에 걸린 것이 아니라, 모델이 통계적으로 「악성 같다」고 점수를 매긴 것입니다. Sabsik 과 Wacatac 은 서명 없는 새 실행 파일에 붙는 대표적인 일반명이기도 합니다.

측정한 것

짐작으로 넘어가지 않으려고, 같은 PC·같은 정의판(1.459.133.0)·같은 시점에 세 판을 명령줄 검사(MpCmdRun -Scan -ScanType 3)로 돌렸습니다.

빌드	결과
build 63	found no threats
build 64	found no threats
build 65	found 1 threats

정의판이 바뀌어서 생긴 일이 아니었습니다. 세 판 모두 같은 정의판에서 검사했고, 앞의 두 판은 깨끗했습니다.

우리가 틀렸던 가설

처음 세운 가설은 「제품 안에 들어 있는 탐지용 문자열 때문」이었습니다. 울타리 NEO 는 보안 점검 도구라 악성코드를 식별하는 문자열을 갖고 있습니다 — 랜섬노트 문구, 해킹 도구 이름, 채굴기 이름 같은 것들입니다. 이런 것들이 한 실행 파일에 모여 있으면 백신이 오해할 수 있다고 본 것입니다.

그래서 세 판의 바이너리를 직접 열어 문자열을 대조했습니다. 결과는 가설과 반대였습니다.

문제의 문자열들은 build 63·64·65 에 개수까지 똑같이 들어 있었습니다. 그런데 63 과 64 는 깨끗했습니다.

문자열이 원인이면 앞의 두 판도 걸렸어야 합니다. 가설은 틀렸습니다. 그리고 그 사실을 확인한 것이 이 조사에서 가장 쓸모 있는 결과였습니다. 틀린 가설을 붙잡고 며칠을 쓸 뻔했기 때문입니다.

그래서 원인이 무엇인가 — 모릅니다

build 65 에서 늘어난 코드 중 정확히 무엇이 방아쇠였는지는 특정하지 못했습니다. 문자열 단위·토큰 단위로 두 번 비교했지만 의미 있는 차이를 분리해 내지 못했습니다.

그리고 이것은 더 파면 나올 성질의 문제가 아닐 수 있습니다. 머신러닝 판정은 근거를 공개하지 않습니다. 파일 전체의 바이트 분포·구조·크기 같은 특징으로 점수를 매기기 때문에, 하는 일이 똑같은 두 빌드가 결정 경계 양쪽에 떨어질 수 있습니다. 사람이 납득할 만한 「이유」가 아예 없을 수도 있습니다.

확실한 것은 네 가지

특정 원인 대신, 애초에 오탐 확률을 높이는 조건들은 분명합니다.

코드 서명 인증서가 없습니다. 가장 큰 요인입니다.
새 빌드는 사용 이력이 0입니다. 판을 낼 때마다 평판이 처음으로 리셋됩니다.
보안 도구라 행동이 악성코드와 겹칩니다. 자동 실행 목록을 읽고, 프로세스를 훑고, 방화벽 규칙을 쓰고, 파일을 격리합니다. 전부 제품의 기능이지만, 모델이 보기에는 악성코드가 하는 일과 같습니다.
설치 형태가 지속성 패턴과 같습니다. 사용자 폴더에 실행 파일을 두고 자동 시작을 등록합니다. Defender 가 지목한 것도 실행 파일 하나가 아니라 이 조합이었습니다.

하지 않기로 한 것

탐지를 피할 때까지 바이너리를 이리저리 고쳐 보는 방법이 있습니다. 하지 않기로 했습니다.

그건 악성코드 제작자가 쓰는 작업 방식이고, 보안 제품을 만드는 회사가 자기 릴리스 절차에 심을 수 있는 것이 아닙니다. 성공한다 해도 다음 기능을 넣을 때 또 걸릴 것이고, 그때마다 같은 짓을 반복하게 됩니다. 결국 제품을 백신 분류기가 설계하게 됩니다.

대신 하고 있는 것

마이크로소프트에 오탐 정정 요청을 접수했습니다. 위 측정 결과를 근거로 제출했고 검토를 기다리는 중입니다.
코드 서명 인증서를 발급받고 있습니다. 위 1·2번을 동시에 없애는 유일한 수단입니다. 다만 서명한다고 오탐이 즉시 사라지지는 않습니다 — 평판은 다운로드 이력이 쌓이면서 붙습니다.
설치 위치를 바꾸는 것을 검토 중입니다(4번 대응).
정정될 때까지 홈페이지에 오탐 안내와 검사에서 깨끗한 이전 판을 함께 올려 두었습니다.

받으신 파일을 직접 확인하는 법

「이 회사가 오탐이라고 하니 믿으라」고 말할 생각은 없습니다. 저희 제품 자체가 근거를 보고 직접 판단하라는 원칙으로 만든 것이라, 여기서도 같은 것을 드립니다.

다운로드 페이지에 모든 배포 파일의 SHA-256 을 적어 두었습니다. 받으신 파일이 저희가 올린 그 파일인지 명령 한 줄로 확인할 수 있습니다.

certutil -hashfile "받은파일경로" SHA256

값이 다르면 그건 저희 파일이 아닙니다. 그 경우에는 실행하지 마시고 알려 주세요.

결말 — 마이크로소프트가 오탐을 인정했습니다 (2026-09-11)

접수 하루 만에 답이 왔습니다. 분석가 회신을 그대로 옮깁니다.

현재 제출하신 파일은 악성코드 또는 원치 않는 애플리케이션에 대한 당사의 기준을 충족하지 않습니다. 탐지 기록이 제거되었습니다.

build 65 는 더 이상 악성으로 분류되지 않습니다. 이미 차단을 겪으신 분은 PC 에 남아 있는 캐시된 판정을 지워야 합니다. 관리자 권한 명령 프롬프트에서:

cd "C:\Program Files\Windows Defender"
MpCmdRun.exe -removedefinitions -dynamicsignatures
MpCmdRun.exe -SignatureUpdate

설치하려고 Defender 예외를 걸어 두셨다면 그 예외도 지우시는 편이 좋습니다. 예외는 그 폴더 전체를 검사에서 빼는 것이라, 더 필요하지 않은데 남겨 두면 그 자리만 보호가 비게 됩니다.

그래서 끝난 것인가 — 아닙니다

이번 회신은 이 빌드 하나에 대한 개별 구제입니다. 원인이었던 「미서명 + 무이력 + 보안도구 행동」은 그대로 남아 있어서, 다음 빌드가 같은 판정을 받을 수 있습니다. 매번 신고해서 풀 수는 없습니다.

그래서 같은 날 코드 서명 인증서 발급 절차를 마쳤습니다. 신원 확인 심사가 통과하면 앞으로 모든 릴리스가 회사 이름으로 서명되어 나갑니다. 그때 이 글에 다시 덧붙이겠습니다.

이 글을 남기는 이유

보안 제품이 백신에 악성으로 잡혔다는 사실은 숨기고 싶은 종류의 일입니다. 그런데 숨기면 사용자는 검색해서 아무 설명도 못 찾고, 「이 프로그램은 바이러스였다」로 결론을 내립니다. 그게 사실보다 나쁩니다.

그리고 저희가 세운 가설이 측정 앞에서 틀렸다는 것도 그대로 적었습니다. 판정 근거를 보여 주겠다고 만든 제품이 자기 문제에서만 근거를 감추면, 그 제품이 하는 말을 믿을 이유가 없어집니다.

진행 상황이 바뀌면 이 글을 갱신합니다. 문의: [email protected]

덧붙임 (2026-09-12) — 서명했습니다

위에서 약속한 코드 서명이 끝났습니다. 2026-09-12 배포판부터 설치 파일과 무설치 실행 파일 모두 PROJECTTEAMFORYOU 이름으로 서명되어 나갑니다. 인증서는 Azure Artifact Signing 이 발급했고, 발급 전에 D&B 를 통한 사업자 실체 확인을 거쳤습니다. 받으신 파일에서 오른쪽 클릭 → 속성 → 「디지털 서명」 탭을 열면 그 이름이 직접 보입니다.

이것으로 앞에서 적은 원인 셋 가운데 「미서명」 하나가 없어졌습니다. 남은 둘 가운데 「무이력」은 서명이 붙은 채 다운로드가 쌓이면 시간이 해결합니다. 「보안도구다운 행동」은 이 제품의 본질이라 없앨 생각이 없습니다.

서명했다고 SmartScreen 경고가 즉시 사라지지는 않는다는 점도 같이 적어 둡니다. 새 인증서는 평판 이력이 0에서 시작합니다. 지금 설치하실 때 경고가 뜨면 게시자 이름이 PROJECTTEAMFORYOU 로 보이는지 확인하신 뒤 「추가 정보 → 실행」을 누르시면 됩니다. 그 이름이 안 보이면 우리 파일이 아닙니다.

한 가지 더. 서명을 붙이면 실행 파일의 해시가 전부 바뀝니다. 그래서 서명 첫 배포와 같은 날 자기보호 기대 해시도 함께 갈아 끼웠습니다. 2026년 9월 10일부터 12일 사이에 받으신 서명 전 build 65 를 쓰고 계시다면 자기보호가 대조에 실패했다고 표시할 수 있습니다 — 그때는 지금 판을 다시 받아 덮어 설치해 주세요.

덧붙임 2 (2026-09-12) — 서명한 파일을 스캐너에 다시 걸어 봤습니다

서명을 붙여 놓고 「이제 됐다」고 적으면 그것도 결국 우리 주장일 뿐입니다. 그래서 서명본(build 66)을 그대로 VirusTotal 에 올려 71개 엔진에 다시 걸었습니다. 결과는 2/71 이었고, 태그에 signed 가 붙어 서명이 인식된 것도 확인했습니다.

중요한 것은 누가 빠졌는가입니다. 이 글의 주인공이던 Microsoft 가 정상 판정입니다. 우리 도메인을 High Risk 로 분류했던 Webroot, W32/PossibleThreat 를 냈던 Fortinet 도 정상입니다. ESET·Sophos·Symantec·Trend Micro·Malwarebytes·CrowdStrike·Google 도 전부 정상이었습니다.

남은 두 건은 성격이 같았습니다. Kaspersky 는 HEUR:Exploit.Win64.VulDriver.h(취약 드라이버), Huorong 은 Backdoor/IRCBot.bs(IRC 봇). 설치 파일을 풀어 직접 확인해 보니 안에 든 실행 파일은 우리 앱 하나뿐이고 드라이버는 들어 있지 않습니다. 걸린 것은 우리가 들고 다니는 탐지 사전 — 알려진 취약 드라이버 이름 29종과 IRC 봇 지표 — 이었습니다. 보안 스캐너가 자기 탐지 데이터를 갖고 있다는 이유로 악성으로 분류된 셈입니다.

두 곳에 오탐 신고를 보냈고, Kaspersky 는 같은 날 오탐임을 확인하고 수정하겠다고 회신했습니다 (악성코드 분석가 회신, 티켓 KL-3054659). Huorong 회신은 기다리고 있습니다.

다만 이것으로 끝이라고 적지는 않겠습니다. 뿌리는 탐지 사전이 실행 파일에 평문으로 들어 있다는 점이고, 그건 남이 아니라 우리가 고칠 수 있는 일입니다. 다음 판에서 사전을 빌드 시각에 인코딩해 넣을 예정입니다. 목적은 탐지 회피가 아닙니다 — 우리 탐지 데이터가 남의 탐지 데이터로 오인되지 않게 하는 것입니다.