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 경고를 반드시 없애주는 마법이 아닙니다.

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

대략적인 판단 기준은 이렇습니다.

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

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

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

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

자신들에게는 올바른 앱이라도, Windows 입장에서는 ‘처음 보는 파일’입니다. 서명되어 있어도 파일 해시나 발행자의 평판이 충분하지 않은 동안은 SmartScreen 경고가 뜰 수 있습니다.

즉, SmartScreen 경고는 이렇게 받아들이면 이해하기 쉽습니다.

악성코드로 단정된 것은 아니다.
다만, Windows가 아직 충분히 신뢰할 수 있다고 판단하지 않았다는 뜻이기는 하다.

이 차이를 이해하지 못하면, “서명했는데 왜 안 고쳐지지”, “EV 증명서를 샀는데 왜 안 바뀌지” 같은 오해로 이어집니다.

3. 코드 서명이 보증하는 것

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

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

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

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

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

서명이 없으면 이용자는 발행자를 알 수 없습니다. 기업 환경에서는 서명 없는 파일이 App Control이나 EDR, Defender, 프록시, 메일 게이트웨이에 의해 차단될 수도 있습니다. 자동 업데이트를 만드는 경우에도, 업데이트 파일이 진짜인지 검증하기 위해 서명이 중요해집니다.

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

4. EV 증명서를 쓰면 처음부터 경고가 사라진다는 것은 낡은 이해

이전에는 EV 코드 서명 증명서를 쓰면 SmartScreen에서 유리하게 취급받는다는 이해가 널리 퍼져 있었습니다.

하지만 현재는, 적어도 SmartScreen 회피만을 목적으로 EV 증명서를 사는 판단은 위험합니다. Microsoft의 현재 설명에 따르면, EV 증명서가 최초 다운로드 시 SmartScreen 경고를 자동으로 회피해 주는 동작은 없어졌습니다. 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이라 불렸습니다.

물리적인 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 <timestamp-server-url> /td SHA256 /a .\MyApp.exe
signtool verify /pa /v .\MyApp.exe

포인트는 최종 산출물에 서명한다는 것입니다.

서명 후에 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의 영향을 받기 쉬운 방식이기도 합니다.

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 배포를 우선하거나, 다운로드 페이지에 발행자 확인 안내를 둡니다.

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

실무상의 제1후보는 이렇게 정리할 수 있습니다.

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