Windows 방화벽과 업무 앱 ── 인바운드 규칙은 인스톨러에서 등록한다

‘개발 PC에서는 아무 문제 없이 동작하는데, 고객사에 설치했더니 클라이언트에서 서버로 연결이 안 된다’, ‘처음 실행할 때 무언가 경고가 떴고, 현장 담당자가 취소를 눌렀다고 한다’, ‘netstat으로 보면 포트는 대기 중인데 옆 PC에서는 접속이 안 된다’ ── 업무 앱 도입 현장에서 이런 종류의 ‘통신 안 됨’ 문의는 단골 중의 단골입니다. 그리고 원인의 상위권에 계속 자리 잡고 있는 것이 바로 Windows 방화벽(Windows Defender Firewall)입니다.

까다로운 점은 개발 PC에서는 문제가 눈에 띄지 않는다는 것입니다. 개발 PC에서는 Visual Studio 디버그 실행 시 직접 허용을 눌렀거나, 애초에 자신이 관리자였거나 하기 때문에 기본 인바운드 차단을 눈치채지 못한 채 출시해 버립니다. 반면 고객사에서는 조작하는 사람이 관리자 권한이 없는 일반 사용자이며, 네트워크는 GPO로 관리되고 있습니다. ‘작동해야 할 것이 작동하지 않는’ 것이 아니라, ‘개발 PC가 우연히 작동하고 있었을 뿐’이라는 것이 실제 상황입니다.

이 글에서는 자체 개발 앱에서 ‘고객사에서 통신이 안 됨’에 직면하는 업무 앱 개발자와, 그 문의를 받는 중소기업 정보시스템 담당자를 대상으로, Windows 방화벽의 기본 동작과 프로필 구조를 최소한으로 짚은 다음, 인바운드 규칙 설계, 인스톨러에서의 등록 실무, 원인 분리 절차, GPO/Intune 관리하에서의 주의점까지를 2026년 8월 시점의 1차 정보를 바탕으로 정리합니다.

1. 먼저 결론

• Windows 방화벽의 기본값은 ‘인바운드는 차단, 아웃바운드는 허용’입니다. 요청에 대한 응답이 아닌 인바운드 트래픽은 규칙에 일치하지 않는 한 폐기됩니다.¹
• 인바운드 규칙이 필요한 것은 포트를 대기하는 서버형 앱뿐입니다. 자신이 먼저 접속하기만 하는 클라이언트 앱은 기본값 그대로 통신할 수 있습니다. 먼저 이 부분에서 구분하십시오.¹
• 프로필은 3가지(도메인/개인/공용)입니다. 도메인은 도메인 컨트롤러 감지 시 자동 적용되고, 공용은 미식별 네트워크의 기본값입니다. 규칙은 프로필 단위로 활성/비활성이 결정됩니다.¹
• 그 ‘주요 경고’ 대화상자에 운영 환경을 맡겨서는 안 됩니다. 관리자가 취소를 누르면 차단 규칙이 만들어지고, 관리자 권한이 없는 사용자는 어떤 버튼을 눌러도 차단 규칙이 만들어집니다. 만들어진 규칙을 삭제할 때까지 대화상자는 다시 표시되지 않습니다.²
• 결론은 ‘업무 앱의 인바운드 규칙은 인스톨러에서 등록한다’입니다. Microsoft 스스로도 처음 실행하기 전에 규칙을 배치하고, 인바운드 알림은 비활성화할 것을 권장하고 있습니다.²
• 규칙은 최소 권한으로 설계합니다. 프로그램 + 프로토콜 + 포트를 축으로, 프로필을 도메인/개인으로 한정하고, 원격 IP를 필요한 서브넷으로 좁힙니다. 프로그램 경로에는 와일드카드를 사용할 수 없습니다.²³
• 원인 분리는 Test-NetConnection → Get-NetFirewallRule → pfirewall.log 순서로 진행합니다. 방화벽 로그는 기본적으로 기록되지 않으며, 폐기 패킷 기록을 활성화해야 비로소 남습니다.⁴⁵⁶
• 서비스 중지를 통한 전체 비활성화는 지원 대상이 아닙니다. GPO/Intune 관리하에서는 ‘로컬 규칙 병합’이 비활성화되어 있는 경우가 있으며, 그때는 로컬 규칙이 적용되지 않습니다. 규칙의 중앙 배포를 정보시스템 부서에 신청합니다.¹²

2. 기본 동작을 정확히 ── 인바운드는 기본 차단, 아웃바운드는 기본 허용

먼저 기초를 정확히 짚고 넘어가겠습니다. Windows 방화벽은 모든 에디션에서 기본적으로 활성화되어 있는 호스트 기반 방화벽이며, 기본 동작은 다음 두 줄로 요약됩니다.¹

• 인바운드(inbound): 요청에 대한 응답(solicited)이거나 규칙에 일치하지 않는 한 모두 차단
• 아웃바운드(outbound): 규칙에 일치하지 않는 한 모두 허용

이 두 줄에서 업무 앱에 있어 가장 중요한 구분 기준이 나옵니다. 인바운드 규칙이 필요한 것은 ‘대기하는 쪽’뿐입니다.

• 사내 웹 서버·DB 서버·기간 시스템에 스스로 접속하기만 하는 클라이언트 앱 → 원칙적으로 규칙 불필요. 접속 응답 패킷은 ‘요청에 대한 응답’이므로 기본값으로 통과합니다.
• TCP나 gRPC, 독자 프로토콜 등으로 포트를 열고 접속을 대기하는 서버형 앱·Windows 서비스 → 인바운드 규칙 필수.
• 참고로, 이름 있는 파이프(named pipe)를 원격에서 사용하는 구성은 예외입니다. 원격 이름 있는 파이프는 앱 자체의 포트가 아니라 SMB(TCP 445)를 경유하기 때문에, 필요한 것은 앱의 규칙이 아니라 파일 공유(SMB) 쪽의 규칙입니다.
• 예외는 아웃바운드 기본값을 명시적으로 차단으로 변경한 고보안 환경입니다. 이런 구성은 일부 조직에만 존재하지만, 그 경우에는 클라이언트 앱에도 아웃바운드 규칙 신청이 필요합니다.²

flowchart TB
    APP["자사 앱의 통신을 파악한다"] --> Q{"포트를 열고<br/>접속을 대기하는가"}
    Q -- "대기하지 않음, 클라이언트로서 접속만 함" --> C1["인바운드 규칙은 원칙적으로 불필요<br/>접속 응답은 '응답'으로 통과"]
    Q -- "대기함, 서버형·콜백 수신" --> S1["인바운드 규칙 필수<br/>→ 인스톨러에서 등록, 5장 참고"]
    C1 -.-> EX["예외, 아웃바운드 기본 차단인<br/>고보안 환경에서는 아웃바운드 규칙 신청"]

‘클라이언트인 줄 알았던 앱이 사실은 대기도 하고 있는’ 경우(결과의 콜백 수신, 다른 프로세스로부터의 통지 창구 등)는 놓치기 쉽습니다. 자사 앱이 어떤 통신 방식으로 대기하고 있는지 애매하다면, 설계 단계의 정리로서 「Windows의 프로세스 간 통신을 어떻게 선택할까 ── 네임드 파이프 / TCP / gRPC / 공유 메모리 / COM 판단표」도 함께 확인해 보십시오.

2.1. 프로필과 ‘네트워크 위치’

규칙은 네트워크 프로필 단위로 적용됩니다. 프로필은 3가지입니다.¹

현재 어떤 프로필이 적용되어 있는지는 Get-NetConnectionProfile로 확인할 수 있고, 개인/공용 전환은 Set-NetConnectionProfile로 수행할 수 있습니다.¹ 현장에서 흔한 사고는 고객사의 workgroup 환경에서 네트워크가 ‘공용’으로 판정되어, 도메인/개인으로 한정해 만든 인바운드 규칙이 적용되지 않는 경우입니다. ‘규칙은 있는데 통하지 않는다’면 규칙의 내용보다 먼저 프로필 일치 여부를 의심하십시오.

2.2. 규칙의 우선순위

규칙이 여러 개 있을 때의 평가는 가중치가 부여된 순서 목록이 아니라, 다음과 같은 일관된 원칙으로 결정됩니다.²

1. 명시적인 허용 규칙은 기본 차단보다 우선한다
2. 명시적인 차단 규칙은 충돌하는 허용 규칙보다 우선한다
3. 위 2번에 반하지 않는 범위에서 더 구체적인 규칙이 우선한다

실무적으로 의미하는 바는 ‘어딘가에 차단 규칙이 하나라도 있으면, 나중에 허용 규칙을 아무리 추가해도 이길 수 없다‘는 것입니다. 다음 장에서 보듯, 바로 이 차단 규칙을 그 대화상자가 조용히 만들어냅니다.

3. ‘주요 경고’ 대화상자의 정체 ── 맡기면 안 되는 이유

앱이 처음으로 포트 대기(listen)를 시작했을 때, 그 앱에 대한 허용 규칙도 관리자가 정의한 규칙도 존재하지 않으면, Windows는 ‘이 앱의 일부 기능이 Windows Defender 방화벽에서 차단되었습니다’라는 익숙한 ‘Windows 보안 주요 경고’ 대화상자를 표시합니다. 동작 사양은 명확합니다.²

• 관리자 권한이 있는 사용자에게 표시된 경우: ‘액세스 허용’을 누르면 허용 규칙이 만들어집니다. 하지만 ‘취소’를 누르면 차단 규칙이 만들어집니다. 보통은 TCP용과 UDP용 두 개입니다.
• 관리자 권한이 없는 사용자에게 표시된 경우: 어떤 선택지를 골라도 차단 규칙이 만들어집니다.
• 어느 경우든 만들어진 규칙을 삭제하지 않는 한 대화상자는 두 번 다시 표시되지 않으며, 통신은 계속 차단됩니다.

flowchart TB
    L["앱이 포트 대기를 시작"] --> Q1{"해당 앱에 일치하는<br/>규칙이 있는가"}
    Q1 -- "있음" --> R1["규칙을 따름<br/>대화상자는 나타나지 않음"]
    Q1 -- "없음" --> Q2{"인바운드 알림은<br/>활성화되어 있는가"}
    Q2 -- "비활성화" --> R2["말없이 차단<br/>규칙은 만들어지지 않음"]
    Q2 -- "활성화" --> DLG["'주요 경고' 대화상자"]
    DLG -- "관리자가 '액세스 허용'" --> OK["허용 규칙이 만들어짐"]
    DLG -- "관리자가 '취소'" --> NG1["차단 규칙이 만들어짐"]
    DLG -- "관리자 권한이 없는 사용자<br/>어떤 조작을 해도" --> NG2["차단 규칙이 만들어짐"]
    NG1 --> NEVER["규칙을 삭제할 때까지<br/>대화상자는 두 번 다시 나타나지 않음"]
    NG2 --> NEVER

즉 이 대화상자는 ‘사용자에게 허가를 구하는 장치’처럼 보이지만, 업무 앱 현장에서는 ‘일반 사용자가 건드리는 순간 차단 규칙을 새겨 넣는 장치’로 작동합니다. 도입 담당자가 관리자 계정으로 처음 실행하여 대화상자에서 허용한 경우, 만들어진 허용 규칙은 PC 전체에 적용되므로 다음 날부터는 일반 사용자도 일단 통신할 수 있습니다. 그래도 사고는 남습니다 ── 도입 시 동작 확인에서는 거치지 않았던 대기 경로를 일반 사용자가 처음 거쳤을 때, 적용되는 네트워크 프로필이 도입 시와 다를 때, 그리고 업데이트로 exe 경로가 바뀌었을 때(4장·5장)입니다.

Microsoft 스스로도 관리자가 아닌 사람이 사용하는 디바이스에 대해서는 다음과 같은 모범 사례를 명시하고 있습니다.²

1. 앱을 처음 실행하기 전에 필요한 규칙을 미리 배치해 둔다(인스톨러 또는 관리 측에서의 배포)
2. 인바운드 알림을 비활성화한다(알림을 끄면 실행 시 자동 규칙 생성 자체가 이루어지지 않는다)

알림 비활성화는 Set-NetFirewallProfile -NotifyOnListen False, 또는 그룹 정책으로 설정할 수 있습니다.⁷ ‘대화상자가 뜨면 현장 담당자에게 허용을 눌러 달라고 한다’는 운영 절차가 아니라 사고 예약입니다. 인바운드 규칙은 설치 시점에 등록한다 ── 이것이 이 글의 결론이며, Microsoft의 권장 사항과도 일치합니다.

4. 인바운드 규칙 설계 ── 프로그램 지정·포트 지정·서비스 지정

등록할 규칙의 내용을 설계합니다. 지정 방법은 크게 3가지 계통이 있으며, 단독으로 쓸지 조합할지를 판단합니다.

그런 다음 범위 한정을 추가로 적용합니다. Microsoft의 설계 권장 사항도 ‘인바운드 규칙은 가능한 한 구체적으로’입니다.²

• 프로필 한정: 사내에서만 사용하는 업무 앱의 인바운드 규칙은 도메인/개인으로 한정하고, 공용에서는 활성화하지 않습니다. 노트북이 사외 Wi-Fi에 연결되는 순간 대기 포트가 전 세계에 열리는 사고를 방지합니다.
• 원격 IP 한정: 접속 출발지가 정해져 있다면 -RemoteAddress를 해당 서브넷으로 좁힙니다. 가정·소규모 네트워크에는 LocalSubnet 키워드로 한정하는 것이 권장됩니다.²³
• 방향과 개수: 대기가 TCP뿐이라면 TCP 규칙 하나로 충분합니다. 대화상자가 자동으로 만드는 것처럼 TCP/UDP 양쪽 규칙을 관성적으로 만들지 말 것.

‘필요한 상대로부터, 필요한 포트로, 필요한 프로그램만’ ── 인바운드 규칙 설계는 이 최소 권한 한 문장으로 요약됩니다.

5. 인스톨러에서의 등록 실무 ── netsh와 New-NetFirewallRule

5.1. 전제: 관리자 권한이 필요

방화벽 규칙의 추가·삭제는 컴퓨터 전체의 설정 변경이므로, 관리자 권한(승격된 프로세스)으로 실행해야 합니다.⁸ 인스톨러는 보통 관리자 권한으로 동작하므로, 규칙 등록은 설치 처리 안에 두는 것이 합리적입니다. 앱 본체를 관리자로 실행할 이유는 되지 않습니다. 이 구분 기준에 대한 사고방식은 「Windows의 관리자 특권이 필요해지는 것은 언제인가 - UAC, 보호 영역, 설계상의 구분 방법」에서 자세히 다룹니다.

5.2. netsh advfirewall를 통한 등록

고전적이지만, 어떤 인스톨러에서든 호출하기 쉬운 것이 netsh advfirewall firewall add rule입니다.⁸

rem add rule는 동일한 이름의 규칙이 있어도 추가되어 버리므로, 재설치·복구·
rem 업데이트로 재실행할 때를 대비해 동일한 이름의 규칙을 지운 뒤 다시 등록한다
netsh advfirewall firewall delete rule name="MyCompany OrderServer"

rem 프로그램 지정 + 포트 지정 + 프로필 한정 인바운드 허용 규칙
netsh advfirewall firewall add rule name="MyCompany OrderServer" dir=in action=allow program="C:\Program Files\MyCompany\OrderServer\OrderServer.exe" protocol=TCP localport=50051 profile=domain enable=yes

rem 제거 시: 이름으로 삭제
netsh advfirewall firewall delete rule name="MyCompany OrderServer"

add rule는 기존의 동일한 이름 규칙을 대체하지 않고 동일한 이름 그대로 추가하므로, 먼저 delete rule을 실행하지 않으면 재실행할 때마다 규칙이 늘어나며, 경로나 범위를 바꾼 업데이트 이후에도 이전 허용 규칙이 그대로 남습니다(첫 실행 시에는 맨 앞의 delete rule이 ‘일치하는 규칙이 없다’는 결과를 반환하지만, 배치 실행은 계속되므로 이 순서로 문제없습니다. 인스톨러의 성공/실패 판정을 종료 코드로 하는 경우에는 마지막 add rule의 결과를 확인하도록 하십시오). remoteip=157.60.0.1,172.16.0.0/16,LocalSubnet처럼 접속 출발지도 좁힐 수 있습니다.⁸ 삭제는 이름이 일치하는 규칙을 한꺼번에 지우므로, 규칙 이름은 자사 접두사를 붙여 고유하게 만드는 것이 안전합니다.

5.3. PowerShell(New-NetFirewallRule)을 통한 등록

더 세밀하게 제어하려면 NetSecurity 모듈을 사용합니다. -DisplayName은 필수이며, -Profile은 쉼표로 구분해(공백 없이) 여러 개를 지정할 수 있습니다.³

# 등록(인스톨러에서 승격된 상태로 실행). -Name은 고유 식별자이므로,
# 재설치·복구·업데이트로 재실행할 경우 동일한 이름의 규칙 생성이
# 오류가 된다. 기존의 동일한 이름 규칙을 지운 뒤 다시 만드는 방식으로 멱등성을 확보한다
Remove-NetFirewallRule -Name "MyCompany-OrderServer-In" -ErrorAction SilentlyContinue
New-NetFirewallRule -Name "MyCompany-OrderServer-In" `
    -DisplayName "MyCompany OrderServer (TCP 50051 수신)" `
    -Direction Inbound -Action Allow `
    -Program "C:\Program Files\MyCompany\OrderServer\OrderServer.exe" `
    -Protocol TCP -LocalPort 50051 `
    -Profile Domain,Private -RemoteAddress LocalSubnet

# 제거 시: 존재하지 않아도 오류로 처리하지 않음
Remove-NetFirewallRule -Name "MyCompany-OrderServer-In" -ErrorAction SilentlyContinue

여기서 -Name을 명시적으로 지정한 데에는 이유가 있습니다. -Name은 규칙의 고유 식별자로, 생략하면 무작위 값이 할당됩니다. 표시 이름(-DisplayName)은 로캘에 따라 달라질 수 있으므로, 스크립트에서 규칙을 식별하는 키로는 -Name을 사용하는 것이 Microsoft의 안내입니다.³ 제거 프로그램이 확실히 자신의 규칙만 지우기 위해서도 -Name 고정은 필수라고 생각하십시오.

5.4. 업데이트로 exe 경로가 바뀌는 경우

프로그램 지정 규칙은 전체 경로로 대상을 고정합니다. 즉, 업데이트로 설치 위치나 exe 이름이 바뀌면, 규칙은 남아 있는데 대상을 놓쳐서 대기가 다시 차단됩니다. 이때 새 경로의 exe는 ‘규칙이 없는 앱’으로 취급되므로, 알림이 활성화된 환경에서는 3장의 대화상자가 다시 나타나고 일반 사용자가 조작하면 차단 규칙이 새겨집니다. 3장의 권장대로 알림을 비활성화한 환경에서는 대화상자조차 뜨지 않고 조용히 실패합니다. 버전 번호가 들어간 폴더에 배치하는 방식이나, 자체 업데이트로 배치 위치가 바뀌는 방식에서 특히 발생하기 쉬운 사고입니다.

flowchart TB
    V1["v1.0 설치<br/>규칙은 v1.0 폴더의 exe를 가리킴"] --> UP["업데이트로 v1.1 폴더에 배치<br/>실행되는 exe의 경로가 바뀜"]
    UP --> MISS["기존 경로의 규칙이 대상을 놓침<br/>규칙은 남아 있지만 적용되지 않음"]
    MISS --> Q{"인바운드 알림은<br/>활성화되어 있는가"}
    Q -- "활성화" --> DLG["대화상자가 다시 표시됨<br/>일반 사용자가 조작하면 차단 규칙"]
    Q -- "비활성화" --> SILENT["대화상자도 없이<br/>말없이 차단"]
    MISS -.->|"대책"| FIX["경로를 업데이트와 무관하게 고정<br/>또는 업데이트 처리에서 기존 규칙을 삭제 후 재등록"]

대책은 단순하며, 다음 중 하나입니다.

• 설치 위치를 고정하여 exe의 전체 경로가 업데이트를 거쳐도 바뀌지 않는 배치로 만든다
• 경로가 바뀌는 업데이트에서는 업데이터가 기존 규칙을 삭제하고 새 경로로 재등록한다(5.2/5.3의 명령을 업데이트 처리에서도 실행한다)

MSI라면 규칙 등록은 파일 배치 이후에 실행되는 커스텀 액션(제거 시에는 삭제 쪽 커스텀 액션)으로 포함하는 것이 정석입니다. WiX 등의 툴셋에는 방화벽 규칙을 선언적으로 기술하는 확장 기능도 있습니다. 어떤 배포 방식을 선택하느냐에 따라 구현 위치가 달라지므로, 「Windows 앱의 배포 방식을 어떻게 고를까 - MSI / MSIX / ClickOnce / xcopy / 자체 updater의 판단표」도 참조하십시오. 참고로, 고객사 배포 시 또 하나의 단골 트러블인 백신 오탐은 「자체 개발한 Windows 앱이 바이러스로 오인될 때 ── Microsoft Defender 오탐 대응과 성능 영향과의 공존 방법」에서 다루고 있습니다.

6. 문제 해결 ── ‘통신 안 됨’ 원인 분리 절차

문의를 받았을 때의 절차를 순서대로 고정해 둡니다. 전체 흐름은 다음과 같습니다.

flowchart TB
    S["'클라이언트에서 통신이 안 됨'"] --> N["서버 측 - netstat -ano"]
    N -- "대기하고 있지 않음" --> APP["방화벽 이전 단계의 문제<br/>앱·서비스 쪽을 조사"]
    N -- "LISTENING 상태" --> T["클라이언트 측 - Test-NetConnection"]
    T -- "TcpTestSucceeded=True" --> OTHER["도달성은 정상<br/>앱 계층 - 인증·프로토콜 - 을 조사"]
    T -- "False" --> P["서버 측 - Get-NetConnectionProfile<br/>적용 중인 프로필을 확인"]
    P -- "규칙의 대상과 불일치" --> FIXP["규칙의 프로필 지정을 재검토"]
    P -- "일치함" --> R["Get-NetFirewallRule -PolicyStore ActiveStore<br/>허용 규칙 존재 여부·차단 규칙 혼입을 확인"]
    R --> LOGCHK["pfirewall.log에서 DROP 폐기 여부를 실측"]

절차 4에 대한 보충 설명입니다. 포트나 프로그램 조건은 규칙 본체가 아니라 필터 개체 쪽에 있으므로, 포트로부터 규칙을 역으로 조회하려면 필터를 경유해 쿼리해야 합니다.⁵⁷

# 포트 50051에 관련된 규칙을 역으로 조회
Get-NetFirewallPortFilter | Where-Object { $_.LocalPort -eq 50051 } | Get-NetFirewallRule

# 규칙의 출처(로컬인지 GPO인지)를 추적
Get-NetFirewallRule -PolicyStore ActiveStore -TracePolicyStore |
    Select-Object Name, DisplayName, PolicyStoreSourceType, PolicyStoreSource

절차 5의 방화벽 로그(pfirewall.log)는 기본적으로 아무것도 기록되지 않습니다. 기본 경로는 %windir%\system32\logfiles\firewall\pfirewall.log, 기본 최대 크기는 4,096KB이며, ‘폐기된 패킷을 로그에 기록’이나 ‘성공한 연결을 로그에 기록’ 중 하나를 활성화해야 비로소 기록됩니다.⁶ 단일 머신이라면 다음으로 활성화할 수 있습니다.⁶

netsh advfirewall set allprofiles logging droppedconnections enable
netsh advfirewall set allprofiles logging allowedconnections enable

로그는 텍스트 파일이며, 폐기(DROP)인지 허용(ALLOW)인지, 프로토콜, 발신지/목적지의 IP와 포트가 한 줄씩 기록되므로, ‘클라이언트로부터의 SYN이 도착했는데 폐기되고 있는지, 애초에 도착하지 않은 것인지’를 여기서 확정할 수 있습니다. 참고로, 정책으로 로그를 구성한 환경에서는 로그 폴더에 대한 쓰기 권한(서비스 mpssvc의 FullControl)이 부족해 파일이 만들어지지 않는 경우가 있으며, 그럴 때는 폴더 생성과 ACL 부여가 필요합니다.⁶

더 깊이 파고들고 싶다면, 감사 정책 ‘필터링 플랫폼 패킷 삭제’를 활성화하면 폐기가 일어날 때마다 보안 이벤트 5152가 기록됩니다. 다만 이벤트 양이 매우 많기 때문에, Microsoft는 연결 단위로 기록되는 이벤트 5157(필터링 플랫폼 연결)의 사용을 권장하고 있습니다. 상시 사용이 아니라 원인 분리 중에만 활성화하는 도구입니다.⁹

마지막으로 해서는 안 되는 원인 분리 방법을 명확히 해 두겠습니다. 방화벽 서비스(MpsSvc)를 중지시켜 전체를 비활성화하는 것은 지원 대상이 아니며, 시작 메뉴 미작동이나 스토어 앱 업데이트 실패 등 OS 측 문제를 일으킵니다. 부득이하게 비활성화하여 확인하고 싶을 때는, 서비스는 그대로 두고 Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled False로 프로필을 비활성화하고, 확인 후 즉시 원상 복구합니다.¹⁷ 그리고 원인이 방화벽으로 확정되면, 대응은 비활성화를 고착화하는 것이 아니라 올바른 규칙을 하나 추가하는 것입니다.

7. 조직 관리하에서의 주의 사항 ── 로컬 규칙이 적용되지 않는 환경과 신청 방법

인스톨러에서 규칙을 등록해도 그것이 적용되지 않는 환경이 있습니다. GPO나 Intune(CSP)으로 방화벽을 중앙 관리하는 조직에서는 프로필별로 ‘로컬 규칙 병합‘(AllowLocalPolicyMerge)을 비활성화할 수 있습니다. 이 설정이 비활성화되어 있으면 로컬 관리자(인스톨러 포함)가 만든 규칙은 적용되지 않으며, 인바운드 연결이 필요한 앱의 규칙은 GPO/CSP를 통한 중앙 배포가 필수가 됩니다.²

flowchart TB
    GPOR["GPO/Intune로 배포된 규칙"] --> EFF["실제로 적용되는 규칙의 집합<br/>ActiveStore"]
    LOCAL["로컬에서 만든 규칙<br/>인스톨러의 등록을 포함"] --> Q{"로컬 규칙 병합<br/>AllowLocalPolicyMerge"}
    Q -- "활성화, 기본값" --> EFF
    Q -- "비활성화" --> DROP["규칙은 존재하지만 적용되지 않음<br/>→ GPO/CSP를 통한 중앙 배포로 전환"]

개발 측·도입 측으로서의 현실적인 대비책은 다음과 같습니다.

• 인스톨러의 규칙 등록은 ‘실패하지 않는’ 설계로 만든다(등록 자체는 성공하기 때문에 오류로는 감지할 수 없습니다. 도입 후 소통 확인을 절차에 포함시킵니다)
• 6장의 절차 4(-TracePolicyStore)로, 적용되고 있는 규칙의 출처가 로컬인지 GPO인지 확인한다⁵
• 로컬 규칙이 적용되지 않는 환경임을 알게 되면, 정보시스템 부서에 규칙 배포 신청으로 전환한다

신청 시에는 다음 정보를 한 세트로 전달합니다. 방화벽 규칙은 방향·프로그램·포트·범위가 갖추어져야 비로소 만들 수 있으므로, 이것이 그대로 ‘업무 앱의 네트워크 사양서’가 됩니다.

정보시스템 부서 입장에서도 이 표가 있는 신청과 없는 신청은 작업량이 완전히 다릅니다. 반대로 포트 번호만 대고 ‘열어 주세요’라고 하는 신청은, 4장에서 본 대로 과잉 허용이 되기 쉽습니다. 참고로 도메인 환경의 파일 공유·인증 관련 통신 요건은 방화벽과는 별도의 강화 조치(서명 필수화 등)로도 바뀌고 있습니다. 함께 「SMB 서명과 LDAP 채널 바인딩 ── NTLM 대책의 ‘나머지 절반’을 실무에서 마무리하기」도 참조하십시오.

8. 정리

• Windows 방화벽의 기본값은 인바운드 차단·아웃바운드 허용입니다. 인바운드 규칙이 필요한 것은 대기하는 서버형 앱뿐이며, 클라이언트로서 접속하기만 한다면 원칙적으로 불필요합니다.
• 규칙은 프로필(도메인/개인/공용) 단위로 적용됩니다. ‘규칙은 있는데 통하지 않는다’의 첫 번째 용의자는 프로필 불일치입니다.
• ‘주요 경고’ 대화상자는 취소나 권한 없는 사용자의 조작으로 차단 규칙을 만들며, 이후에는 다시 표시되지 않습니다. 운영 환경을 이 대화상자에 맡겨서는 안 됩니다.
• 업무 앱의 인바운드 규칙은 인스톨러에서 등록한다 ── 이것이 유일한 원칙입니다. 등록은 관리자 권한으로 하며, 삭제까지 포함해 -Name을 고정해 구현합니다.
• 규칙은 프로그램 + 프로토콜 + 포트를 축으로, 프로필과 원격 IP로 좁힙니다. 업데이트로 exe 경로가 바뀌는 경우에는 규칙 재등록을 잊지 마십시오.
• 원인 분리는 netstat → Test-NetConnection → 프로필 확인 → Get-NetFirewallRule(ActiveStore) → pfirewall.log 순서로 기계적으로 진행합니다. 서비스 중지를 통한 비활성화는 지원 대상이 아닙니다.
• GPO/Intune 관리하에서는 로컬 규칙 병합이 비활성화되어 있는 경우가 있습니다. 그때는 규칙 이름·방향·프로그램·포트·원격 IP·프로필을 갖추어 정보시스템 부서에 배포를 신청합니다.

관련 글

• Windows의 프로세스 간 통신을 어떻게 선택할까 ── 네임드 파이프 / TCP / gRPC / 공유 메모리 / COM 판단표
• Windows 앱의 배포 방식을 어떻게 고를까 - MSI / MSIX / ClickOnce / xcopy / 자체 updater의 판단표
• Windows의 관리자 특권이 필요해지는 것은 언제인가 - UAC, 보호 영역, 설계상의 구분 방법
• 자사 개발 Windows 앱이 바이러스로 오탐되었다면 ── Microsoft Defender 오탐 대응과 성능 영향에 대처하는 법
• SMB 서명과 LDAP 채널 바인딩 ── NTLM 대책의 ‘나머지 절반’을 실무에서 마무리하기
• Windows 서비스 만드는 방법과 운영 ── 태스크 스케줄러와의 구분 사용부터 BackgroundService의 서비스화까지

관련 상담 영역

합동회사 코무라소프트에서는 서버형 업무 앱의 인스톨러 설계(방화벽 규칙의 등록·삭제 포함), 고객사 환경에서의 ‘통신 안 됨’ 원인 조사, GPO 관리하 배포를 염두에 둔 네트워크 요구사항 정리를 다루고 있습니다. ‘개발 PC에서는 되는데 고객사에서는 안 됨’의 원인 분리 단계부터도 괜찮습니다.

• Windows 앱 개발
• 결함 조사·원인 분석
• 기술 상담·설계 리뷰
• 문의하기

참고 링크

관련 기사

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

관련 토픽

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

이 주제와 연결되는 서비스

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

자주 묻는 질문

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

클라이언트로서 서버에 접속하기만 하는 앱에도 방화벽 규칙이 필요한가요?

원칙적으로 필요 없습니다. Windows 방화벽의 기본값은 '인바운드는 차단, 아웃바운드는 허용'이므로, 자신이 먼저 접속하러 가기만 하는 클라이언트 앱은 기본값 그대로 통신할 수 있습니다. 인바운드 규칙이 필요한 것은 포트를 열고 접속을 대기하는 쪽, 즉 서버형 앱뿐입니다. 다만 예외가 두 가지 있습니다. 고보안 환경에서는 아웃바운드도 기본 차단으로 변경되어 있는 경우가 있으며, 이때는 아웃바운드 규칙 신청이 필요합니다. 또한 클라이언트 앱이라도 결과 통지를 받는 창구로서 스스로 포트를 대기하는 설계라면, 그 부분에는 인바운드 규칙이 필요합니다.

'Windows 보안 주요 경고' 대화상자에서 '액세스 허용'을 누르면 되는 것 아닌가요?

그 순간은 넘어가더라도 운영 환경을 맡길 수는 없습니다. 이 대화상자는 관리자 권한이 있는 사용자가 취소를 누르면 차단 규칙이 만들어집니다. 게다가 관리자 권한이 없는 사용자의 경우에는 어떤 버튼을 눌러도 차단 규칙이 만들어집니다. 한 번 만들어진 규칙을 삭제하지 않는 한 대화상자는 두 번 다시 표시되지 않고, 통신은 계속 실패합니다. 현장 PC를 조작하는 사람이 일반 사용자인 업무 앱에서는 '누군가 한 번 취소하면 이후 계속 통신이 안 되는' 상태가 쉽게 발생합니다. Microsoft도 앱을 처음 실행하기 전에 규칙을 배치해 둘 것을 권장하고 있습니다.

인바운드 규칙은 포트 지정과 프로그램 지정 중 어느 쪽으로 만들어야 하나요?

단독이 아니라 조합하는 것이 기본입니다. 프로그램 지정은 exe의 전체 경로로 대상을 좁힐 수 있는 반면, 업데이트로 경로가 바뀌면 규칙이 대상을 놓치게 됩니다(와일드카드는 사용할 수 없습니다). 포트 지정은 정보시스템 부서에 신청하기가 명확해지는 반면, 같은 포트에서 대기하는 다른 프로세스까지 통과시켜 버립니다. 운영 중인 업무 앱에서는 '프로그램 + 프로토콜 + 포트'를 축으로, 프로필을 도메인/개인(사설)으로 한정하고, 원격 IP를 클라이언트가 있는 서브넷으로 좁히는 것이 최소 권한의 기본형입니다. 포트가 동적인 경우에만 프로그램 지정 단독을 사용합니다.

인스톨러가 등록한 규칙이 고객사 PC에서는 적용되지 않는 것 같습니다. 왜 그런가요?

고객사의 방화벽이 GPO나 Intune으로 중앙 관리되고 있고, '로컬 규칙 병합'(AllowLocalPolicyMerge)이 비활성화되어 있을 가능성이 높습니다. 이 설정이 비활성화되어 있으면 로컬에서 만든 규칙은 프로필상으로는 존재하더라도 적용되지 않으며, 규칙은 GPO/CSP 쪽에서 중앙 배포하는 수밖에 없습니다. Get-NetFirewallRule -PolicyStore ActiveStore로 실제로 적용되는 규칙 전체를 확인하고, 정보시스템 부서에 규칙 배포를 신청하십시오. 신청 시 규칙 이름, 방향, 프로그램 경로, 프로토콜과 포트, 원격 IP 범위, 프로필을 갖추어 전달하면 한 번에 처리됩니다.

통신 원인 분리를 위해 방화벽을 일시적으로 비활성화해도 되나요?

서비스(MpsSvc)를 중지시켜 비활성화하는 것은 절대로 피해야 합니다. Microsoft의 지원 대상 외 조작이며, 시작 메뉴가 작동하지 않게 되거나 스토어 앱 업데이트가 실패하는 등 OS 측 문제를 일으킵니다. 원인 분리를 위해 부득이하게 비활성화하고 싶다면, 서비스는 그대로 두고 Set-NetFirewallProfile -Enabled False로 프로필을 비활성화하는 것이 올바른 방법입니다. 다만 이 역시 '원인이 방화벽인지 아닌지'를 몇 분 안에 확인하는 용도로만 한정하고, 확인이 끝나면 즉시 원상 복구해야 합니다. 비활성화한 채로 운영하는 것은 규칙 하나만 추가하면 되는 문제를 PC 전체의 무방비 상태와 맞바꾸는 행위입니다.

저자 프로필

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

Go Komura

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

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