방화벽

서버를 인터넷에 연결하는 순간, 그 서버는 필요한 요청뿐 아니라 원치 않는 요청도 함께 받게 됩니다. 웹 서버는 외부에 열어야 할 수 있지만 데이터베이스나 관리 포트까지 그대로 노출되면 공격자는 포트 스캔만으로 접근 지점을 찾을 수 있습니다. 더 어려운 점은 '완전히 막을 것인가'가 아니라, 어떤 출발지에서 어떤 포트와 프로토콜을 어떤 방향으로 허용할 것인가를 세밀하게 정해야 한다는 데 있습니다. 이 기준이 없으면 네트워크는 과하게 열려 위험해지거나, 반대로 너무 닫혀 정상 서비스까지 막힙니다. 방화벽은 이 경계 결정을 규칙으로 명시하는 가장 기본적인 보안 장치입니다.

인터넷이 작고 비교적 신뢰 가능한 집단의 연결망이던 시절에는 오늘날만큼 강한 경계 통제가 필요하지 않았습니다. 그러나 상업화와 대중화가 진행되면서 외부의 모든 트래픽을 기본적으로 신뢰할 수 없게 됐고, 네트워크 경계에서 무엇을 통과시킬지 먼저 결정해야 하는 시대가 왔습니다. 초기에는 물리 장비 형태의 방화벽이 중심이었지만, 클라우드 환경에서는 보안 그룹과 네트워크 ACL처럼 소프트웨어로 정의된 규칙이 같은 역할을 합니다. 방화벽의 핵심은 장비 형태가 아니라, 네트워크 경계를 명시적으로 선언한다는 발상입니다. 오늘날 인프라 설정을 코드로 관리하는 흐름에서 방화벽 규칙도 그 연장선에 있습니다.

방화벽은 들어오거나 나가는 트래픽을 보고 출발지 IP, 목적지 IP, 포트, 프로토콜, 연결 상태 같은 속성을 규칙과 대조합니다. 규칙에 맞으면 허용하고, 맞지 않으면 차단하거나 기본 정책에 따라 버립니다. Stateful 방화벽은 이미 허용된 연결의 응답 패킷인지까지 추적할 수 있어, 포트 숫자만 보는 단순 필터보다 실용적인 제어가 가능합니다. 그래서 보안 운영의 기본 원칙은 보통 '전부 허용 후 일부 차단'이 아니라 '기본 차단 후 필요한 통신만 명시적으로 허용'에 가깝습니다. 이 구조를 이해하면 방화벽이 단순한 체크박스가 아니라, 서비스 의존성과 네트워크 경로를 규칙으로 번역하는 도구라는 점이 보입니다.

방화벽과 WAF는 모두 요청을 걸러낸다는 공통점이 있지만, 관찰하는 층이 다릅니다. 방화벽은 네트워크와 전송 계층에서 IP와 포트, 프로토콜, 연결 방향을 기준으로 통과 여부를 결정합니다. 반면 WAF는 HTTP 요청이라는 전제를 두고 URL, 헤더, 쿠키, 쿼리 문자열, 본문 패턴을 분석해 애플리케이션 공격을 탐지합니다. 데이터베이스 포트 노출이나 서브넷 경계 제어는 방화벽 문제이고, 웹 폼을 통한 공격 문자열 차단은 WAF 문제에 더 가깝습니다. 둘 다 필요할 수 있지만 같은 문제를 두 번 푸는 도구로 보면 설계가 흐려집니다.

방화벽은 웹 서버 공개 포트 최소화, 데이터베이스 외부 접근 차단, 퍼블릭과 프라이빗 서브넷 사이 통신 제한, 운영자 관리 포트 접근 통제 같은 기본 보안 작업에 즉시 적용됩니다. 누가 어떤 자원에 어느 경로로 접근해야 하는지가 비교적 명확한 환경에서는 강력하고 직관적인 보호막이 됩니다. 다만 규칙이 많아질수록 예외가 누적되고, 임시로 연 포트가 오래 남는 등 운영 부채가 빠르게 쌓일 수 있습니다. 최소 권한 원칙과 함께 규칙을 코드로 관리하고, 주기적으로 실제 의존성과 맞는지 검토하는 습관이 중요합니다. 좋은 방화벽 정책은 많이 막는 정책이 아니라, 서비스가 필요한 통신만 명료하게 남기는 정책입니다.