방화벽(Firewall)이란? 기초 개념 정리

방화벽은 어떻게 발전해 왔나

위키백과(Firewall)의 역사 항목은 1980년대 라우터가 이미 네트워크를 구분하고 패킷을 거를 수 있었기 때문에 이를 방화벽의 전신으로 봅니다. 1987년 디지털 이큅먼트(DEC)의 엔지니어들이 패킷 필터 방식의 방화벽을 개발했고, AT&T 벨 연구소의 빌 체스윅과 스티브 벨로빈이 패킷 필터링 연구를 이어갔다고 합니다. 1989~1990년에는 벨 연구소의 데이브 프레소토 등이 연결 단위로 대화를 추적하는 회로 수준 게이트웨이를 개발했고, 1993년 10월 마커스 래넘 등이 공개한 방화벽 툴킷(FWTK)은 애플리케이션 계층 방화벽의 바탕이 되었습니다. 위키백과는 2012년 기준으로 차세대 방화벽이 웹 필터링, 침입 방지, TLS 검사까지 확장되었다고 정리합니다. 다만 해당 위키백과 문서에는 일부 내용이 검증되지 않았을 수 있다는 유지보수 안내가 붙어 있으므로, 이 연표는 대략적인 흐름을 보는 참고용으로만 읽어 주세요.

방식별 비교표

아래 표는 NIST SP 800-41 Rev.1의 2장 설명을 요약한 것입니다.

참고로 NIST는 순수한 스테이트리스 패킷 필터링만 하는 제품은 오늘날 많지 않지만, 패킷 필터링은 대부분 현대 방화벽의 핵심에 들어 있다고 적습니다. 즉 "하나만 고르는" 구조가 아니라 위 기능들이 겹쳐 쌓여 있습니다.

규칙은 어떤 원칙으로 짜나: 기본 차단

NIST는 방화벽이 정책에서 명시적으로 허용되지 않은 인바운드·아웃바운드 트래픽을 모두 막아야 한다고 권고하며, 이를 deny by default라고 부릅니다. 변화가 빠른 호스트·프로토콜·애플리케이션 환경에서는 "금지한 것만 막는" 방식보다 "필요한 것만 여는" 방식이 더 안전하다는 설명입니다. TCP·UDP 인바운드에도 같은 원칙을 쓰되, 아웃바운드는 상대적으로 완화된 정책을 쓰는 경우가 많다고 덧붙입니다. 규칙의 평가 순서나 문법은 제품마다 다르므로 해당 제품 문서를 확인해야 합니다.

가상 예시: 작은 사무실의 규칙표

아래는 개념을 설명하기 위해 만든 가상 예시이며 실제 제품의 문법이 아닙니다. 사내에 웹 서버 한 대(내부 주소 192.0.2.10, 문서용 예약 주소 대역)가 있다고 가정합니다.

NAT와 방화벽은 같은 것일까: NIST의 정리

많은 사람이 "공유기의 NAT 덕분에 외부 접속이 막힌다"고 알고 있습니다. NIST SP 800-41 Rev.1의 3.2절은 이를 대중적인 오해로 규정하며 "NAT는 방화벽의 보안 기능에 속하지 않는다"고 적습니다. NAT가 주는 보안상 이점, 즉 외부 호스트가 내부 호스트에 먼저 접속하지 못하게 하는 효과는 스테이트풀 방화벽으로도 얻을 수 있고, 오히려 NAT에서 잘 동작하지 않는 프로토콜에 대한 영향도 줄일 수 있다는 것입니다. 다만 NIST는 NAT를 켜는 쪽이 정책을 올바르게 구성하는 것보다 쉬워서 보안 기능으로 오인되기 쉽다는 점도 함께 인정합니다. 가정용 공유기에서 NAT와 상태 추적이 한 장비 안에서 함께 동작하는 경우가 많지만, 개념상 둘은 분리해서 이해하는 것이 정확합니다. 포트포워딩이나 DMZ를 열면 해당 호스트는 그만큼 노출되므로 필요한 포트만 최소한으로 여는 것이 좋습니다.

실제 기록으로 보는 사례

사례 1: FTP가 방화벽 설정을 어렵게 하는 이유

NIST SP 800-41 Rev.1은 포트 규칙을 설명하면서 FTP가 최소 두 개의 포트를 쓰고 그중 하나는 예측하기 어렵다고 적습니다. 위키백과(FTP)에 따르면 능동 모드에서는 서버가 클라이언트로 되접속하는데 방화벽과 NAT가 이를 막는 경우가 많았고, 이를 개선한 패시브(수동) 모드가 RFC 1579(1994)에서 방화벽 친화적 방식으로 소개되었습니다. 교훈은 "허용할 포트 번호 하나만 열면 끝나는 프로토콜이 아니다"입니다. 프로토콜의 동작 방식을 모르고 규칙을 만들면 연결이 되다 말다 하는 현상으로 이어질 수 있습니다. FTP 자체의 차이는 FTP와 SFTP 차이 가이드에서 다룹니다.

사례 2: 암호화 트래픽 앞에서의 한계

NIST 2.3절은 방화벽이 이해하지 못하는 트래픽은 제대로 처리할 수 없다고 말합니다. IPsec, TLS, SSH 등으로 내용이 암호화되어 있거나 S/MIME·OpenPGP로 보호된 데이터는 읽을 수 없고, 알려지지 않은 터널링 방식(예: IPv4 안에 IPv6를 담는 여러 방식)도 해석하기 어렵습니다. 이런 경우 방화벽 규칙이 "이해하지 못한 트래픽"을 어떻게 다룰지를 결정하므로, 조직은 허가되지 않은 암호화 트래픽을 허용할지 막을지 정책으로 정해 두어야 한다고 NIST는 설명합니다. 특정 사건의 이름보다는 표준 문서가 명시한 구조적 한계라는 점이 중요합니다.

내 환경에서 점검해 보기

• 내 PC의 운영체제 방화벽이 켜져 있는지 확인하고, 사용하지 않는 프로그램의 허용 규칙을 정리합니다. 방법은 윈도우 방화벽 가이드를 참고하세요.
• 공유기에서 포트포워딩, DMZ, 원격 관리 기능이 불필요하게 열려 있지 않은지 확인합니다.
• 새 규칙을 만들기 전에 "어떤 서비스가 어떤 포트·프로토콜을 쓰는지"를 공식 문서로 먼저 확인합니다.
• 가능하면 인바운드는 기본 차단으로 두고, 열어 둔 규칙마다 사유를 기록해 둡니다.

흔한 오해와 정정

• 오해: NAT가 켜져 있으면 방화벽이 필요 없다. 실제: NIST는 NAT를 방화벽 보안 기능으로 보지 않으며, 같은 효과를 스테이트풀 방화벽으로 더 깔끔하게 얻을 수 있다고 설명합니다.
• 오해: 방화벽은 바이러스를 잡아 준다. 실제: 방화벽은 통신 경로를 통제하는 장치이고, 기기 안에서 실행되는 악성코드 탐지는 별도의 보안 소프트웨어 영역입니다.
• 오해: 방화벽은 켜 두기만 하면 안전하다. 실제: 규칙이 너무 많이 열려 있거나 오래된 예외가 남아 있으면 효과가 줄어듭니다. 규칙은 주기적으로 점검해야 합니다.
• 오해: 아웃바운드는 막을 필요가 없다. 실제: NIST는 아웃바운드에 상대적으로 완화된 정책을 쓰는 경우가 많다고 하면서도, 필요한 만큼만 허용하는 방향을 권합니다. 감염된 기기의 외부 통신을 줄이는 데 도움이 됩니다.

한계와 더 알아볼 점

방화벽은 자신이 볼 수 있는 트래픽에만 효과적입니다. 암호화된 트래픽을 중간에서 복호화해 검사할지는 조직마다 정책 판단이 다릅니다. 또한 사용자가 직접 입력한 자격 증명(피싱)이나 허용된 경로를 통한 공격은 경계 장치만으로 막기 어렵기 때문에, 경계 안팎을 구분하지 않고 접근을 검증하는 접근이 논의됩니다. 이에 대해서는 제로 트러스트 가이드와 IDS/IPS 가이드를 함께 보면 좋습니다. 이 글은 일반 정보이며, 운영 중인 시스템의 정책 변경은 해당 장비 문서와 보안 담당자의 확인이 필요합니다.

윈도우 방화벽 설정 방법이 궁금하다면

내 PC의 호스트 기반 방화벽에서 특정 프로그램을 허용하는 방법이 궁금하다면윈도우 방화벽에서 프로그램 허용하는 방법을 참고해보세요.

홈 네트워크 보안을 더 강화하고 싶다면

방화벽 외에 공유기 보안 설정까지 함께 점검하고 싶다면홈 네트워크 보안 설정하는 방법도 확인해보세요. NAT 자체의 동작은 NAT 기초 가이드에서 볼 수 있습니다.

자주 묻는 질문