Windows에서 'Windows에서 PC를 보호했습니다'가 나타나는 이유

SmartScreen, 코드 서명, EV/OV 인증서, MSIX/Store 배포를 실무 관점에서 정리

Windows 앱을 만들어 배포할 때 가장 먼저 부딪히기 쉬운 벽이 바로 이 경고입니다.

Windows에서 PC를 보호했습니다
Microsoft Defender SmartScreen에서 인식할 수 없는 앱의 시작을 차단했습니다.

이 경고가 나오면 사용자는 불안해합니다. 개발자 쪽도 “바이러스가 아닌데 왜 막히는가”, “코드 서명을 했는데 왜 아직 경고가 나오는가”를 고민합니다.

이 글에서는 Windows 앱을 배포할 때의 SmartScreen 경고를 코드 서명, EV/OV 인증서, MSIX, Microsoft Store, ClickOnce, 사내 배포의 관점에서 정리합니다.

1. 이 글을 한 줄로

Windows 앱 배포에서는 코드 서명이 필요합니다.
그러나 코드 서명은 SmartScreen 경고를 반드시 없애는 마법이 아닙니다.

중요한 것은 세 가지 관점을 나누어 생각하는 것입니다.

대략적인 판단 기준은 다음과 같습니다.

이 글의 지식 맵

Windows 앱 배포에서 나타나는 SmartScreen 경고는 코드 서명 여부뿐 아니라 게시자와 파일의 평판으로 결정되므로, 코드 서명 인증서는 경고를 줄여 주더라도 완전히 없애지는 못합니다. EV 인증서는 현재 SmartScreen을 즉시 우회할 목적으로는 권장되지 않으며, 프로덕션 배포에서는 Azure Artifact Signing이나 OV 인증서가 현실적인 선택지가 됩니다. Microsoft Store에 제출한 MSIX 패키지는 Microsoft가 무상으로 다시 서명하므로 가장 안정적이기 쉽고, ClickOnce는 Authenticode 인증서로 매니페스트에 서명하여 게시자를 보증합니다. SignTool은 코드 서명과 타임스탬프의 부여·검증을 담당하며, 타임스탬프는 인증서가 실효된 뒤에도 서명의 유효성을 유지합니다. 사내 배포에서는 Intune이나 그룹 정책으로 구성하는 App Control for Business가 서명되지 않은 바이너리의 실행 실패를 초래할 수 있으므로, 강제 적용보다 감사 모드에서의 검증을 먼저 해야 합니다.

flowchart LR
    accTitle: SmartScreen과 코드 서명의 지식 맵
    accDescr: SmartScreen 경고의 판정 근거와 코드 서명 인증서의 종류, MSIX나 ClickOnce 등의 배포 경로, 사내 배포에서 App Control for Business와의 관계를 보여주는 그림.
    smartscreen["Windows SmartScreen"]
    code_signing_cert["코드 서명 인증서"]
    ev_certificate["EV 코드 서명 인증서"]
    group_policy["그룹 정책"]
    intune["Microsoft Intune"]
    msix["MSIX"]
    microsoft_store["Microsoft Store"]
    azure_artifact_signing["Azure Artifact Signing"]
    ov_certificate["OV 코드 서명 인증서"]
    self_signed_cert["임시 자체 서명 인증서"]
    trusted_publisher_store["신뢰할 수 있는 게시자 저장소"]
    clickonce["ClickOnce"]
    signtool["SignTool"]
    code_signing_timestamp["코드 서명 타임스탬프"]
    certificate_expiry["인증서 만료"]
    app_control_for_business["App Control for Business(구 WDAC)"]
    managed_installer["매니지드 인스톨러"]
    audit_mode["감사 모드"]
    unsigned_binary["서명되지 않은 바이너리"]
    blocked_app_startup_failure["실행 제어로 인한 앱 시작 실패"]
    code_signing_cert -.->|"완화한다"| smartscreen
    ev_certificate -->|"사용은 비권장"| smartscreen
    smartscreen -->|"에서 구성할 수 있다"| group_policy
    smartscreen -->|"에서 구성할 수 있다"| intune
    msix -->|"전제로 한다"| code_signing_cert
    microsoft_store -.->|"이용한다"| msix
    microsoft_store -->|"완화한다"| smartscreen
    azure_artifact_signing -->|"권장되는 대응"| msix
    ov_certificate -->|"권장되는 대응"| msix
    self_signed_cert -->|"권장되는 대응"| msix
    self_signed_cert -.->|"전제로 한다"| trusted_publisher_store
    clickonce -.->|"전제로 한다"| code_signing_cert
    signtool -.->|"이용한다"| code_signing_timestamp
    code_signing_cert -->|"에서 확인할 수 있다"| signtool
    code_signing_timestamp -->|"완화한다"| certificate_expiry
    app_control_for_business -.->|"이용한다"| managed_installer
    audit_mode -->|"보다 먼저 해야 한다"| app_control_for_business
    app_control_for_business -->|"에서 구성할 수 있다"| intune
    unsigned_binary -.->|"원인이 될 수 있다"| blocked_app_startup_failure
    smartscreen -.->|"원인이 될 수 있다"| blocked_app_startup_failure

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

2. SmartScreen은 ‘바이러스 판정’만 하는 것이 아니다

SmartScreen 경고가 나오면 사용자는 “위험한 앱인가”라고 느낍니다.

그러나 SmartScreen은 단순히 “바이러스인가 아닌가”만 보는 것이 아닙니다. Microsoft의 설명에서는 다운로드된 파일에 대해 주로 다음과 같은 평판 정보를 봅니다.

여기서 중요한 점은 새로 만든 파일에는 아직 평판이 없다는 것입니다.

당사자에게는 올바른 앱이더라도, Windows 쪽에서는 “처음 보는 파일”입니다. 서명이 있어도 파일 해시나 게시자의 평판이 충분하지 않은 동안에는 SmartScreen 경고가 나올 수 있습니다.

즉 SmartScreen 경고는 이렇게 보면 이해하기 쉽습니다.

맬웨어로 단정되었다는 뜻은 아니다.
다만 Windows가 아직 충분히 신뢰할 수 있다고 판단하지 않았다는 의미는 있다.

이 차이를 이해하지 않으면 “서명했는데도 고쳐지지 않는다”, “EV 인증서를 샀는데도 달라지지 않는다”는 오해로 이어집니다.

3. 코드 서명은 무엇을 보증하는가

코드 서명이 보증하는 것은 주로 두 가지입니다.

1. 그 파일이 표시된 게시자에 의해 서명되었다는 것
2. 서명 후에 파일이 변조되지 않았다는 것

반대로 말하면, 다음은 직접 보증하지 않습니다.

• 그 앱이 절대적으로 안전하다는 것
• 그 앱에 버그가 없다는 것
• SmartScreen 경고가 반드시 나오지 않는다는 것
• 기업 정책에서 반드시 허용된다는 것

그래도 코드 서명은 거의 필수에 가깝습니다.

서명이 없으면 사용자에게 게시자가 보이지 않습니다. 기업 환경에서는 서명 없는 파일이 App Control이나 EDR, Defender, 프록시, 메일 게이트웨이에서 차단되기도 합니다. 자동 업데이트를 만들 때도 업데이트 파일이 진짜인지 검증하려면 서명이 중요합니다.

즉 코드 서명은 “경고를 없애기 위해서”만이 아니라, 배포·업데이트·감사·기업 도입의 기반입니다.

4. EV 인증서면 처음부터 경고가 사라진다는 것은 오래된 이해

예전에는 EV 코드 서명 인증서를 쓰면 SmartScreen에서 유리하게 다뤄진다는 이해가 널리 있었습니다.

그러나 현재는 적어도 SmartScreen 우회만을 목적으로 EV 인증서를 사는 판단은 위험합니다. Microsoft의 개발자용 문서 SmartScreen reputation for Windows app developers에는 “EV 인증서가 SmartScreen을 더 이상 우회하지 않습니다”, “SmartScreen 경고를 우회하기 위해서만 EV에 프리미엄을 지불하는 것은 더 이상 정당화되지 않습니다”라고 명시되어 있습니다. 같은 페이지의 인증서 유형별 표에서도 OV와 EV는 같은 “유효한 인증서 (OV/EV)” 행으로 묶여 있고, 최초 다운로드 시의 동작은 “평판이 쌓일 때까지 경고”라고 적혀 있습니다. EV로 서명한 파일도 OV 인증서와 마찬가지로 평판이 쌓이는 것을 전제로 생각해야 합니다.

EV 인증서에 의미가 전혀 없는 것은 아닙니다.

• 기업 조달에서 더 엄격한 본인 확인이 평가된다
• 거래처 보안 심사에서 EV가 요구된다
• 이미 EV 인증서를 가지고 있어 계속 사용한다

이런 이유가 있다면 사용해도 됩니다.

다만 이 목적만으로 EV 인증서를 사는 것은 권장하지 않습니다.

SmartScreen 경고를 처음부터 없애고 싶어서 EV 인증서를 산다

이 목적이라면 먼저 배포 경로, 서명 방식, 초기 사용자에 대한 설명, 업데이트 빈도, Store 배포 가능 여부를 다시 검토해야 합니다.

5. 서명 방법의 선택지

Windows 앱 배포에서 자주 나오는 서명·배포 선택지를 정리합니다.

Microsoft Store / MSIX

일반 사용자에게 배포한다면 먼저 검토하고 싶은 것은 Microsoft Store입니다.

특히 MSIX와 Store 배포의 조합은 인증서 관리나 SmartScreen 경고 측면에서 유리합니다. Store에 제출된 MSIX 패키지는 Microsoft 측에서 재서명되므로, 개발자가 개별적으로 인증서를 구입·갱신하는 부담도 줄어듭니다.

다만 모든 Windows 앱이 MSIX에 맞는 것은 아닙니다.

• Windows 서비스를 깊게 사용한다
• 드라이버가 필요하다
• shell extension이 있다
• 오래된 COM 등록이나 ActiveX 자산이 있다
• 설치 시 복잡한 OS 변경이 필요하다

이런 경우에는 MSIX보다 MSI나 기존형 설치 프로그램이 자연스러울 수 있습니다.

Azure Artifact Signing

Azure Artifact Signing은 Microsoft가 제공하는 클라우드형 코드 서명 서비스입니다. 이전에는 Trusted Signing이라는 이름이었고, 현재 정식 명칭은 Azure Artifact Signing(Artifact Signing)입니다. Microsoft 제품 페이지도 “Artifact Signing (formerly Trusted Signing)”으로 표기합니다. 이전 이름 그대로 적힌 글이나 사내 자료도 많으므로, 검색할 때는 두 이름 모두로 찾아 보세요. 공식 문서는 Microsoft Learn: What is Artifact Signing?와 Azure: Artifact Signing (formerly Trusted Signing)입니다.

물리 USB 토큰을 쓰지 않고 CI/CD에 넣기 쉽다는 점이 매력입니다. Store 밖 배포의 서명 방식으로 유력하지만, 이용할 수 있는 지역이나 계정 조건이 있습니다.

2026년 시점의 Microsoft 자료에서는 조직은 미국, 캐나다, EU, 영국, 개인 개발자는 미국·캐나다가 대상입니다. 일본의 법인·개인이 쓰는 경우에는 이용 조건을 반드시 확인하세요. 쓸 수 없으면 기존의 OV 코드 서명 인증서가 현실적인 후보가 됩니다.

또한 Azure Artifact Signing으로 서명해도 SmartScreen 신뢰가 즉시 부여되는 것은 아닙니다. OV 인증서와 같이 평판은 배포 실적에 따라 쌓입니다.

OV 코드 서명 인증서

일본의 개발자나 법인이 Store 밖에서 Windows 앱을 배포하는 경우, OV 코드 서명 인증서는 지금도 현실적인 선택지입니다.

OV 인증서를 쓰면 사용자에게 게시자 이름이 표시됩니다. 서명 없음보다는 분명히 나은 상태가 됩니다. 다만 신규 앱이나 신규 파일에서는 SmartScreen 경고가 나올 수 있습니다.

OV 인증서를 쓸 때 염두에 둘 점은 이 정도입니다.

• 게시자 이름을 계속 사용한다
• 매번 같은 게시자로 서명한다
• 서명 후에 파일을 변경하지 않는다
• 타임스탬프를 붙인다
• EXE뿐 아니라 DLL, MSI, updater도 확인한다
• 인증서 갱신 시의 이전 계획을 준비한다

자체 서명 인증서

자체 서명 인증서는 개발이나 검증에는 편리합니다.

그러나 공개 배포에서는 기본적으로 쓸 수 없습니다. 사용자의 Windows에서 보면 그 인증서는 신뢰되지 않기 때문입니다.

자체 서명 인증서를 쓸 수 있는 것은 이런 환경입니다.

• 개발자의 로컬 PC
• 테스터의 검증 환경
• Intune이나 GPO로 신뢰된 인증서를 배포할 수 있는 사내 디바이스
• 폐쇄망에서 디바이스 구성을 완전히 관리할 수 있는 환경

자체 서명 인증서를 쓰는 경우에도 “언제 삭제할지”, “누가 신뢰된 저장소에 넣었는지”, “프로덕션 환경에 섞이지 않는지”를 관리해야 합니다.

6. 실무에서는 무엇에 서명해야 하는가

“EXE에 서명했으니 끝”이 아닙니다.

Windows 앱 배포에서는 서명 대상을 빠짐없이 확인합니다.

SignTool을 쓰는 경우, 현재 Windows SDK에서는 /fd와 /td 지정이 중요합니다. 전형적으로는 SHA256을 지정합니다.

signtool sign /fd SHA256 /tr http://timestamp.digicert.com /td SHA256 /a .\MyApp.exe
signtool verify /pa /v .\MyApp.exe

각 옵션의 의미는 다음과 같습니다.

타임스탬프 서버 URL은 인증서 발급자가 안내하는 것을 사용합니다. Microsoft의 SignTool 문서 예에서는 http://timestamp.digicert.com이, Artifact Signing의 서명 절차에서는 https://timestamp.acs.microsoft.com이 사용됩니다. 타임스탬프를 붙여 두면 서명 시점에 인증서가 유효했다는 것이 기록되므로, 인증서 유효 기간이 끝난 뒤에도 서명을 계속 사용할 수 있습니다.

인증서 지정 방법은 환경에 따라 나눕니다.

놓치기 쉬운 점은, /sm을 붙이지 않는 한 SignTool이 보는 것은 실행 사용자의 개인 저장소라는 것입니다. 인증서를 “로컬 컴퓨터” 인증서 저장소에 넣었는데 /sm을 쓰지 않은 경우, 빌드를 서비스 계정으로 돌리는데 인증서는 다른 사용자의 개인 저장소에 있는 경우처럼, “인증서를 찾을 수 없다”가 되는 예가 흔합니다. CI에서 서명할 때는 어느 계정의 어느 저장소에 인증서가 있는지를 먼저 확정하세요.

서명되었는지는 다음 세 가지로 확인합니다.

• signtool verify /pa /v .\MyApp.exe가 성공하는 것
• 그 명령의 종료 코드가 0인 것(PowerShell이라면 직후에 $LASTEXITCODE를 본다)
• 탐색기에서 파일 속성을 열고 “디지털 서명” 탭에 게시자와 타임스탬프가 표시되는 것

핵심은 최종 산출물에 서명하는 것입니다.

서명 후에 EXE를 다시 쓰고, ZIP 안의 파일을 갈아 끼우고, 설치 프로그램을 만든 뒤에 포함 파일을 바꾸는 일을 하면, 서명이 깨지거나 검증 결과가 기대와 달라질 수 있습니다.

빌드 파이프라인에서는 이 순서를 고정합니다.

빌드
  ↓
의존 파일 수집
  ↓
설치 프로그램 / 패키지 작성
  ↓
서명
  ↓
서명 검증
  ↓
해시 기록
  ↓
배포

7. 배포 방식별 생각

MSI / EXE 설치 프로그램

MSI나 EXE 설치 프로그램으로 배포하는 경우에는, 사용자가 맨 먼저 실행하는 파일에 반드시 서명합니다.

더해서, 설치 후에 함께 설치되는 EXE나 DLL도 서명 대상으로 다시 봅니다. 설치 프로그램만 서명되어 있어도, 설치 후의 updater나 helper가 서명되지 않으면 기업 환경에서 차단될 수 있습니다.

생각할 일은 대체로 정해져 있습니다.

• 설치 프로그램 본체에 서명한다
• 안에 들어가는 EXE/DLL에도 서명한다
• UAC 상승이 필요한 처리를 분리한다
• updater나 service helper를 따로 감사한다
• 다운로드 페이지 URL을 안정시킨다
• 초기 사용자에게 게시자 이름을 안내한다

MSIX

MSIX는 패키지로서의 일관성이 강한 방식입니다.

Store 배포가 가능하다면 SmartScreen 경고나 인증서 관리 측면에서는 상당히 다루기 쉬워집니다. 한편 사내 사이드로드나 Store 밖 배포에서는 MSIX 패키지 서명과 인증서 신뢰를 제대로 설계해야 합니다.

주의점을 적어 둡니다.

• 개발·검증은 자체 서명이어도 된다
• 프로덕션 배포에서는 공개적으로 신뢰되는 서명 방식을 사용한다
• appxmanifest의 Publisher와 인증서의 Subject를 일치시킨다
• Store 밖 배포에서는 SmartScreen 경고가 나올 가능성을 가정한다
• MSIX에 맞지 않는 OS 통합이 없는지 사전에 확인한다

ClickOnce

ClickOnce는 WinForms/WPF 같은 .NET 업무 앱을 표준 사용자에게 배포할 때 편리합니다.

다만 ClickOnce라고 해서 SmartScreen 문제가 사라지는 것은 아닙니다. 사용자가 다운로드하여 시작하는 경로, 매니페스트 서명, 배포 출처, 업데이트 시 파일 변경이 관계합니다.

ClickOnce에서 확인할 것은 이 정도입니다.

• 애플리케이션 매니페스트와 배포 매니페스트의 서명
• 배포 출처 URL 또는 공유 폴더의 관리
• 업데이트 시 인증서 변경의 취급
• 사내 프록시나 Defender에서 차단되지 않는지
• 최초 설치 시 사용자 안내

ClickOnce의 강점은 “쉽게 배포할 수 있다”는 것이지만, 게시자 신뢰나 배포 경로까지 포함해 설계하지 않으면 현장에서 막힙니다.

xcopy / ZIP 배포

폴더를 두기만 하거나 ZIP만 푸는 배포는 단순합니다.

폐쇄망이나 사내 도구에서는 유효한 경우도 있습니다. 그러나 일반 사용자 대상 Web 배포에서는 SmartScreen이나 Defender, Mark of the Web의 영향을 가장 받기 쉬운 방식이기도 합니다.

여기서 나온 Mark of the Web (MOTW)는 브라우저나 메일 클라이언트가 다운로드한 파일에 붙이는 Zone.Identifier라는 alternate data stream입니다. “이 파일은 인터넷에서 왔다”는 표시로, SmartScreen 확인, Office 매크로 차단, PowerShell 실행 정책(RemoteSigned) 판단 등에 사용됩니다. 표시는 탐색기에서 파일 속성을 열고 “보안” 란의 “차단 해제”를 선택하거나, PowerShell의 Unblock-File로 뗄 수 있습니다. ZIP을 풀 때 안의 파일로 표시가 이어지는지는 압축을 푼 도구에 따라 달라집니다. 자세한 내용은 PowerShell의 실행 정책과 스크립트 서명의 “Zone.Identifier (Mark of the Web)와 Unblock-File” 장에서 다룹니다.

xcopy 배포를 쓴다면 여기는 지켜 두고 싶은 부분입니다.

• EXE/DLL에 서명한다
• ZIP에만 의존하지 않고 안의 파일을 검증한다
• 배포 출처를 고정한다
• 버전, 해시, 업데이트 이력을 명시한다
• 자동 업데이트를 나중에 붙인다면 서명 검증을 넣는다

“설치 프로그램을 만들지 않으니 쉽다”가 아니라, “설치 프로그램이 갖는 책임을 직접 진다”고 생각해야 합니다.

자체 updater

자체 updater는 편리하지만 보안 경계 그 자체입니다.

updater는 새 파일을 가져와 기존 파일을 바꿉니다. 경우에 따라서는 관리자 권한으로 동작합니다. 여기가 무너지면 앱 본체보다 위험합니다.

최소한 이것만은 확인합니다.

• 업데이트 metadata에 서명한다
• metadata에 version, hash, size, channel, expiry를 넣는다
• 다운로드 후에 hash와 서명을 검증한다
• 검증 실패 시에는 fail-closed로 멈춘다
• rollback 절차를 준비한다
• updater 자신의 업데이트 방법을 정한다
• 프로덕션 서명 키를 개발 환경에서 분리한다

이 주제는 기존 글 “자동 업데이트의 보안 설계”와 함께 생각하면 이해하기 쉽습니다.

8. 사내 배포에서는 SmartScreen만 봐서는 부족하다

사내 앱의 경우 흔한 오해가 있습니다.

사내에서만 쓰니까 서명은 필요 없다

이것은 위험합니다.

사내 환경에서는 SmartScreen뿐 아니라 여러 메커니즘이 관계합니다.

특히 App Control for Business를 쓰는 환경에서는 “서명되어 있는가”뿐 아니라 “그 게시자가 허용되어 있는가”, “managed installer 경유인가”, “해시나 경로가 허용되어 있는가”가 문제가 됩니다.

Microsoft의 배포 가이드에서도 App Control 정책 변경은 먼저 감사 모드로 배포하고, 차단 이벤트가 예상과 같은지 확인한 뒤에 강제 모드로 넓히는 생각이 제시되어 있습니다.

사내 배포에서는 이 순서로 설계하는 것이 현실적입니다.

1. 대상 디바이스를 나눈다
   - 개발자
   - 테스터
   - 일부 부서
   - 전사

2. 배포 경로를 정한다
   - Intune
   - GPO + 파일 공유
   - 사내 포털
   - VDI / RemoteApp
   - 폐쇄망의 수동 배포

3. 신뢰 규칙을 정한다
   - 게시자 규칙
   - 인증서 배포
   - managed installer
   - 해시 허용
   - 경로 허용

4. 감사 모드로 확인한다
   - 무엇이 차단되는가
   - 어느 DLL이나 helper가 빠졌는가
   - 업데이트 시 다른 파일로 다루어지지 않는가

5. 단계적으로 배포한다
   - 작게 배포한다
   - 로그를 본다
   - 허용 규칙을 조정한다
   - 넓힌다

사내 배포의 요점은 SmartScreen 우회가 아니라, Windows에게 설명 가능한 배포 경로로 만드는 것입니다.

9. 흔한 오해와 올바른 생각

10. 초기 릴리스 때 사용자에게 어떻게 설명하는가

새 앱에서는 처음 몇 주나 초기 사용자에서 SmartScreen 경고가 나올 수 있습니다.

이때 사용자에게 단지 “경고가 나와도 실행하세요”라고 안내하는 것은 좋지 않습니다. 안전한 설명에는 확인해야 할 정보를 넣습니다.

안내에 넣어야 할 항목을 듭니다.

• 정식 다운로드 URL
• 표시되는 게시자 이름
• 파일 이름
• 버전 번호
• 릴리스 날짜
• 필요하면 SHA-256 해시
• 서명되어 있음을 확인하는 방법
• 알 수 없는 경로에서 입수한 파일은 실행하지 말 것

예를 들어 사내라면 이런 안내가 안전합니다.

이 앱은 사내 포털의 다음 페이지에서만 배포합니다.
표시되는 게시자 이름이 "○○주식회사"인지 확인하세요.
메일 첨부나 채팅으로 전달된 EXE는 실행하지 마세요.
SmartScreen 경고가 나오면 정보시스템 부서에 화면을 공유하세요.

일반 사용자라면 Microsoft Store 배포를 우선하거나, 다운로드 페이지에 게시자 확인 설명을 둡니다.

경고 화면에서 사용자가 하는 조작

안내 자료에는 사용자가 실제로 어디를 누르게 되는지에까지 적어 둡니다. SmartScreen 경고 대화 상자에서는 초기 상태에서 누를 수 있는 버튼은 “실행 안 함”뿐입니다. 실행하려면 다음 순서로 조작합니다.

"Windows에서 PC를 보호했습니다" 대화 상자
  → "추가 정보"를 선택
  → 앱 이름(파일 이름)과 게시자가 표시됨
  → "실행" 버튼을 누름

Microsoft의 개발자용 문서에서도, 서명이 없는 파일에 대해 “앱을 실행하려면 ‘실행’을 선택해야 한다”고 설명합니다. 안내문에서는 이 두 단계 조작에 더해, 도중에 표시되는 게시자 이름이 자사 이름인지 확인하게 하는 것이 핵심입니다. 게시자 이름이 “알 수 없는 게시자”로 나오면, 서명이 없거나 서명이 깨진 상태입니다.

참고로 기업 정책 설정에 따라서는 이 “실행” 자체가 비활성화되어 앞으로 진행하지 못할 수 있습니다. 사내 안내에서는 그 경우의 연락처도 덧붙입니다.

경고가 사라질 때까지의 대략적인 기준

“얼마나 배포하면 경고가 사라지는가”는 자주 나오지만, Microsoft는 구체적인 임계값을 공개하지 않습니다. 개발자용 문서의 설명은 “정확한 임계값은 없지만, 폭넓은 사용자로부터 몇 주, 수백 건의 클린 설치가 필요한 경우가 있다”는 것입니다. 함께 다음도 명시되어 있습니다.

• 일반 사용자 대상 디바이스에서는 평판 검토를 위해 파일을 수동으로 제출하는 절차는 없으며, 평판은 다운로드 실적으로 쌓인다
• 기업의 IT 관리자는 Microsoft Security Intelligence 포털에서 파일을 제출할 수 있다. 사내 배포나 관리 하의 디바이스에서는 이것으로 신뢰 획득을 앞당길 수 있는 경우가 있다
• 같은 인증서로 계속 서명하면 인증서 쪽 평판이 자라므로, 새 버전에서는 경고가 나오기 어려워지는 경우가 있다. 서명되지 않은 파일은 업데이트마다 처음부터 다시 쌓게 된다

즉 초기 릴리스는 “당분간 경고는 나온다”는 전제로 안내를 준비하고, 인증서와 게시자 이름을 바꾸지 않고 배포를 이어가는 것이 현실적입니다.

11. 판단 흐름

배포 방식을 정할 때는 이 순서로 생각하면 헤매기 어렵습니다.

flowchart TD
    A[Windows 앱을 배포한다] --> B{일반 사용자 대상인가}
    B -->|예| C{Microsoft Store에 낼 수 있는가}
    C -->|예| D[Store / MSIX를 우선]
    C -->|아니요| E[OV 인증서 또는 Artifact Signing으로 서명]
    B -->|아니요, 사내 대상| F{디바이스 관리가 있는가}
    F -->|Intune/GPO 있음| G[서명 + 인증서 배포 + App Control 감사]
    F -->|관리 없음| H[배포 출처 고정 + 서명 + 사용자 안내]
    E --> I[초기 SmartScreen 경고를 가정]
    G --> J[감사 모드부터 단계 배포]
    H --> J

실무상 우선 후보는 이렇게 정리할 수 있습니다.

12. 최소한의 체크리스트

Windows 앱을 공개·배포하기 전의 확인 항목입니다.

서명

• EXE에 서명하고 있다
• DLL에 서명하고 있다
• MSI 또는 설치 프로그램 EXE에 서명하고 있다
• updater에 서명하고 있다
• 타임스탬프를 붙이고 있다
• 서명 후에 파일을 다시 쓰지 않았다
• signtool verify로 검증하고 있다

배포

• 정식 배포 URL을 정했다
• 다운로드 페이지에 게시자 이름을 표시하고 있다
• 버전 번호와 릴리스 날짜를 표시하고 있다
• 초기 SmartScreen 경고가 나올 가능성을 가정하고 있다
• Microsoft Store에 낼 수 있는지 검토했다
• Store 밖 배포인 경우 OV 인증서나 Artifact Signing을 검토했다

업데이트

• 업데이트 파일에도 서명하고 있다
• 자체 updater에서는 metadata에 서명하고 있다
• hash, size, version을 검증하고 있다
• 실패 시 fail-closed로 멈춘다
• rollback 절차가 있다

사내 배포

• Intune / GPO / App Control 유무를 확인했다
• 인증서 배포 방법을 정했다
• 감사 모드에서 차단 이벤트를 보았다
• 대상 부서를 나누어 단계 배포한다
• 업데이트 시 다시 차단되지 않는지 확인했다

13. 정리

Windows 앱은 만들어 끝이 아니라, 배포한 파일이 Windows, 사용자, 기업 정책에서 보아 “신뢰할 수 있는 형태”가 되어 있어야 합니다.

기억해 둘 점은 이 정도입니다.

• SmartScreen은 파일이나 게시자의 평판을 본다
• 코드 서명은 필요하지만 경고 없음을 보증하지 않는다
• EV 인증서는 SmartScreen 즉시 우회 목적으로는 고르지 않는다
• 일반 배포에서는 Microsoft Store / MSIX를 우선 검토한다
• Store 밖 배포에서는 OV 인증서나 Artifact Signing을 쓰고 초기 경고를 가정한다
• 사내 배포에서는 SmartScreen뿐 아니라 Intune, GPO, App Control까지 본다
• updater는 배포 기능이 아니라 제품의 보안 경계로 설계한다

한 줄로 정리하면 이렇습니다.

Windows 앱 배포는 “어떻게 둘 것인가”가 아니라 “Windows에게 어떻게 신뢰받을 것인가”의 설계이다.

함께 읽기

• Windows 앱 배포 방식 선정 가이드
• ClickOnce 입문: 배포·업데이트·선정 기준
• 자동 업데이트의 보안 설계
• Windows 앱 개발에서 최소한의 보안을 지키기 위한 체크리스트
• Windows 관리자 권한이 필요한 경우와 필요하지 않은 경우의 경계
• Windows 단일 바이너리화의 한계와 실천

참고 링크

• Microsoft Learn: SmartScreen reputation for Windows app developers
• Microsoft Learn: Code signing options for Windows app developers
• Microsoft Learn: What is Artifact Signing? - Azure Artifact Signing(구 Trusted Signing)의 개요와 현재 정식 명칭.
• Microsoft Learn: Sign your MSIX package - end-to-end guide
• Microsoft Learn: SignTool.exe
• Microsoft Learn: Deploying App Control for Business policies
• Microsoft Learn: Manage approved apps for Windows devices with App Control for Business policy and Managed Installers in Microsoft Intune

관련 기사

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

관련 토픽

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

이 주제와 연결되는 서비스

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

자주 묻는 질문

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

'Windows에서 PC를 보호했습니다'라는 경고가 나오는 이유는 무엇인가요?

Microsoft Defender SmartScreen이 해당 파일을 아직 충분히 신뢰할 수 있다고 판단하지 않았기 때문입니다. SmartScreen은 단순한 바이러스 판정이 아니라 게시자의 평판, 파일 해시의 평판, 서명 유무, 배포 경로 등을 봅니다. 새로 만든 파일은 Windows 입장에서 '처음 보는 파일'이므로, 서명이 있어도 평판이 쌓일 때까지는 경고가 나올 수 있습니다. 맬웨어로 단정되었다는 뜻은 아니지만, Windows가 아직 충분히 신뢰할 수 있다고 판단하지 않았다는 의미이기는 합니다.

코드 서명을 하면 SmartScreen 경고가 사라지나요?

반드시 사라지지는 않습니다. 코드 서명이 보증하는 것은 표시된 게시자가 서명했다는 것과, 서명 후에 파일이 변조되지 않았다는 것 두 가지이며, 경고가 전혀 나오지 않는다는 것을 보증하지는 않습니다. 서명이 있어도 파일이나 게시자의 평판이 충분하지 않은 동안에는 경고가 나올 수 있습니다. 그래도 코드 서명은 배포, 업데이트, 감사, 기업 도입의 기반으로서 거의 필수에 가깝습니다. 서명이 없으면 기업 환경에서 App Control이나 EDR, Defender 등에 의해 차단되기도 합니다.

EV 인증서를 사면 처음부터 SmartScreen 경고가 나오지 않나요?

그것은 오래된 이해입니다. Microsoft의 현재 설명에서는, EV 인증서가 최초 다운로드 시 SmartScreen 경고를 자동으로 우회하는 동작은 없어졌으며, EV로 서명한 파일도 OV 인증서와 마찬가지로 평판이 쌓이는 것을 전제로 생각해야 합니다. 기업 조달 요건이나 거래처 보안 심사에서 EV가 요구되는 경우에는 사용할 의미가 있지만, SmartScreen 우회만을 목적으로 EV 인증서를 사는 판단은 권장하지 않습니다. 그 목적이라면 먼저 배포 경로, 서명 방식, Store 배포 가능 여부를 다시 검토해야 합니다.

SmartScreen 경고를 줄이려면 어떻게 배포하면 되나요?

일반 사용자에게 널리 배포한다면 먼저 Microsoft Store / MSIX를 검토합니다. Store에 제출된 MSIX 패키지는 Microsoft 측에서 재서명되므로, SmartScreen 측면에서 가장 안정되기 쉬운 경로입니다. Store에 낼 수 없는 경우에는 OV 인증서 또는 Azure Artifact Signing으로 서명하고, 초기에는 경고가 나올 수 있다고 가정한 뒤, 정식 다운로드 URL, 게시자 이름, 버전, 해시 등을 사용자에게 안내합니다. 사내 배포에서는 서명에 더해 Intune / GPO / App Control까지 포함한 배포 경로 설계가 필요합니다.

저자 프로필

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

Go Komura

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

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