1. 도입
금융권 고객사의 대고객 서비스의 WEB-WAS 구간, 즉 east-west 통신 구간에 AWS TGW Native Network Firewall을 구축한 과정을 기록했습니다. Inspection VPC 같은 별도 인프라 없이 TGW에 방화벽을 바로 붙여 운영 중인 서비스의 트래픽 경로를 전환한 구축기입니다.
2. ISMS 심사가 던진 숙제, 금융권 보안 고도화
금융권에서는 정기적으로 ISMS 심사를 받아 인프라의 보안 적합성을 확인받아야 합니다. 이번 고객사도 클라우드 인프라를 대상으로 한 심사를 준비하고 있었습니다. 그 과정에서 IDC와 클라우드 간 구성 차이가 문제로 제기되었습니다.
고객사의 기존 IDC 환경은 WEB과 WAS 사이에 트래픽을 통제하는 방화벽이 있었습니다. 반면 클라우드에서는 WEB과 WAS를 각각 다른 계정으로 분리해 망분리를 구현하고, 이를 TGW로 연결해 통신하는 구조였습니다. 계정은 분리돼 있었지만 그 사이의 트래픽을 검사하고 통제하는 방화벽은 없었습니다. IDC와 클라우드의 보안 구성이 서로 다르다는 점이 문제였습니다. 그래서 클라우드 쪽에도 IDC와 동등한 수준의 방화벽을 추가해 구성을 맞춰야 했습니다.
여기에 Splunk 연동이라는 한 가지 요건이 더 있었습니다. S3에 저장되는 NFW 로그는 gzip으로 압축된 파일 형태이다 보니 내용을 실시간으로 확인하기 어렵습니다. 최종적으로 WEB, WAS 사이에 방화벽을 구성하고 그 로그를 Splunk로 연동해 실시간 보안 모니터링 체계를 갖추는 것까지가 목표였습니다.
3. Transit Gateway Native Network Firewall이란
AWS에서 Network Firewall을 구성하는 아키텍처는 크게 두 가지입니다. VPC마다 방화벽을 따로 두는 분리형과, 여러 VPC의 트래픽을 한 지점에서 모아 검사하는 중앙집중형입니다. 이번 프로젝트는 트래픽을 한 지점에서 일괄 통제해야 하는 요건이 있었고 마침 고객사 환경도 여러 계정과 VPC가 TGW로 얽혀 있는 구조였기 때문에 중앙집중형 NFW 아키텍처를 선택했습니다.
중앙집중형으로 구성하려면 일반적으로 별도의 Inspection VPC가 필요합니다. 방화벽 트래픽이 지나갈 VPC를 새로 만들고, 서브넷, 라우팅 테이블까지 모두 구성한 뒤에야 방화벽을 생성할 수 있습니다. 방화벽 하나를 위해 이를 위한 인프라까지 만들어야하는 셈입니다.
이번 프로젝트에서의 NFW는 이 Inspection VPC 구성 과정을 생략합니다. AWS가 2025년 6월 발표한 Transit Gateway-Network Firewall 네이티브 통합 기능 덕분입니다. TGW의 Attachment 목록에 “Network Function”이라는 방화벽 전용 Attachment로 등록되는 방식입니다. 방화벽이 사용자 VPC가 아닌 AWS의 매니지드 영역에 생성되기 때문에 우리가 할 일은 NFW이 생성될 TGW와 가용 영역을 지정하는 것뿐입니다. VPC 전용 서브넷을 새로 파거나 라우팅 테이블을 따로 관리하거나, 가용성 확보를 위해 AZ별 라우팅을 수동으로 신경 쓸 필요가 없어집니다.
특히 AWS는 이 기능이 East-West 트래픽을 검사하는 용도에 잘 맞는다고 소개합니다. VPC 간 트래픽 검사는 기존과 동일한 TGW 통과 비용만으로 운영이 가능하다는 점도 장점입니다. 마침 이번 프로젝트에서 다루는 구간이 East-West 트래픽이었기 때문에 이 아키텍처가 방향성 면에서도 적합했습니다.
두 아키텍처를 그림으로 비교해보면 차이가 바로 보입니다.
AS-IS: Inspection VPC 방식
방화벽을 위한 전용 VPC를 만들고 그 안에 방화벽 엔드포인트를 배치합니다. 트래픽은 TGW를 거쳐 이 VPC로 들어와 방화벽 검사를 받은 뒤 다시 TGW를 통해 목적지로 향합니다. VPC와 서브넷, 라우팅 테이블까지 우리가 직접 설계하고 관리해야 합니다.
TO-BE: TGW Native NFW 방식
Inspection VPC를 없애고 TGW Native NFW을 붙여보았습니다. 방화벽 엔드포인트가 별도 VPC 없이 TGW에 바로 붙습니다. TGW 라우팅 테이블에 경로만 등록하면 트래픽이 TGW 안에서 방화벽을 거쳐 곧장 목적지로 향합니다. 관리할 VPC 하나가 사라집니다.
4. 구축 여정 ① 설계
네트워크 구성 파악 — NFW로 트래픽을 전환해야 할 대상이 어떤 VPC, 어떤 계정에 속해 있는지를 추렸습니다. 동시에 VPC 라우팅 테이블과 TGW 라우팅 테이블을 하나씩 열어보면서 WEB-WAS 구간이 실제로 어떤 경로로 연결돼 있는지 확인했습니다. 총 DEV/TEST에 6개, PROD에 5개 계정이 연결되어 있었습니다. VPC, 서브넷, VPC 라우팅 테이블, TGW 라우팅 테이블까지 이 대상들의 리소스 내역을 전부 엑셀에 정리하는 것부터 시작했습니다.
TGW를 통해 통신하는 리소스를 확인하기 위한 수많은 라우팅 정리의 흔적
AS-IS를 TO-BE로 — 현재 상태를 정리한 다음에는 TGW 라우팅 테이블 기준으로 트래픽이 방화벽을 거치도록 전환하면 각 경로가 어떻게 바뀌는지를 TO-BE 엑셀표로 정리했습니다. 실제 전환 작업에 들어가기 전에 바뀌어야 하는 라우팅 경로를 문서화해두어 이를 참고해서 작업하기 위함이었습니다.
단계적 방화벽 정책 적용 — 마지막으로 방화벽 정책을 어떻게 구성할지가 남았습니다. 개발·테스트 계정에는 우선 TCP/UDP/ICMP 프로토콜에 대한 통신을 전부 허용하는 정책으로 시작했습니다. 해당 정책으로 NFW를 붙여 트래픽이 문제없이 운영되는지부터 확인하려는 목적이었습니다.
방화벽을 붙인 뒤에는 중간 점검 기간을 가졌습니다. NFW가 제대로 동작하는지 모니터링하는 동시에 라우팅이 바뀐 VPC들의 리소스에 대한 보안 그룹을 하나씩 확인했습니다. 원래대로라면 어떤 트래픽을 허용해야 하는지는 고객사 쪽에서 제공해주어야 했지만 보안 그룹 정책이 명시된 문서가 따로 없었습니다. 실제로 그 서비스가 어떤 트래픽을 허용하고 있었는지를 보안 그룹 규칙에서 역으로 확인해 방화벽 정책을 구성했습니다.
5. 구축 여정 ② 전환
정책을 파악하고 난 뒤에는 라우팅 전환 작업을 진행했습니다. NFW를 먼저 생성해두고 정책까지 적용한 다음, 그 뒤에 TGW 라우팅 테이블의 경로를 방화벽 쪽으로 돌리는 순서입니다.
문제는 콘솔에서 손으로 누르기엔 너무 위험한 작업이라는 점이었습니다. 대상 서비스는 운영 중인 대고객 서비스였고, 경로를 잘못 바꾸면 바로 장애로 이어질 수 있는 상황이었습니다. 그래서 휴먼 에러를 줄이고자 라우팅 전환과 원복을 Lambda 함수로 자동화했습니다. 이벤트 JSON 하나만 실행시키면 지정한 TGW 라우팅 테이블의 경로를 NFW 쪽으로 변환하고(REPLACE), 문제가 생기면 같은 방식으로 원래 경로로 되돌릴 수 있게(ROLLBACK) 만들었습니다. 서비스 단위로 좁혀서 바꿀 수도, 전체 대역을 한 번에 바꿀 수도 있게 구성해서 상황에 따라 유연하게 대응할 수 있게 했습니다.
{
"service": "service_name",
"env": "DEV",
"job": "REPLACE",
"tgw_rt_id": "tgw_rt_id",
"nfw_rt_att_id": "nfw_tgw_att_id",
}
이벤트 JSON 예시
이 Lambda가 안전한 전환·원복을 가능하게 했던 핵심은 TGW 라우팅 테이블의 경로 우선순위를 활용한 데 있습니다. 같은 대역에 대해 propagated 경로와 static 경로가 동시에 존재하면, TGW는 static 경로를 우선 적용합니다. 그래서 기존에 있던 propagated 경로는 건드리지 않고 그 위에 NFW로 향하는 static 경로만 새로 추가하는 방식으로 전환을 구현했습니다. 실질적으로 트래픽이 NFW를 거치도록 덮어씌우는 효과를 내면서도, 기존 구성 자체는 그대로 남겨둘 수 있었습니다.
롤백도 같은 원리로 단순해집니다. 문제가 생기면 새로 얹었던 static 경로만 지우면 됩니다. propagated 경로는 애초에 변경한 부분이 없어 그대로 설정이 남아있습니다. static 경로가 사라지는 순간 TGW는 다시 원래의 propagated 경로를 따르게 됩니다. 기존 구성을 바꾸지 않고 얹었다 뺄 수 있는 구조였기 때문에 전환과 롤백 모두 부담이 훨씬 덜한 작업이 되었습니다.
7. 프로젝트에서의 어려움
촉박한 일정 — 일정 자체가 가장 큰 압박이었습니다. 두 달이라는 기간 안에서도 연말에는 고객사 쪽 변경 프리징 기간이 있어 실제로 움직일 수 있는 시간은 6주 남짓이었습니다. 게다가 장비와 계정 발급에만 2주 가까이 소요되어 체감상 준비 기간은 훨씬 짧았습니다. 자연스럽게 매주 수요일 주간 보고에서는 일정 리스크를 계속 짚고 넘어가야 했습니다.
물리적인 공간의 분리 — 실제로 정책을 변경하는 작업 공간과, 리소스를 분석하는 공간이 서로 다른 건물이었습니다. 정책을 수정하거나 이슈가 터졌을 때는 매번 옆 건물로 넘어가서 상황을 파악해야 했는데, 그 이동에만 신호 대기까지 포함해서 10분에서 15분 정도가 걸렸습니다. 게다가 작업은 저희에게 지급된 PC가 아니라 실무자분의 PC를 빌려서 진행하는 구조였습니다. 그러다 보니 그분이 바쁘신 시점과 겹치면 조치가 필요한 순간에도 작업 자체를 바로 시작하지 못하는 경우가 있었습니다.
AWS 자체 버그 발생 — 가장 당혹스러웠던 건 개발·테스트 환경에서는 멀쩡히 잘 돌던 구성이 운영 환경에서 문제를 일으킨 순간이었습니다. 운영 환경에 NFW 도입 이후 로그인 페이지에 접속할 때마다 30초 가까이 지연되는 현상이 발생했습니다. 개발·테스트 환경과 다른 점은 트래픽 양이 5배 정도 많다는 것이었는데, AWS에 문의해보니 스케일링상의 문제는 없다는 답변을 받았습니다. NFW 로그에도 문제 될 만한 요소가 보이지 않았습니다. 다만 문제가 되는 서비스의 ALB에서는 503 에러가 발생한 것을 확인했습니다.
AWS Support Case를 열었고, 몇 차례 커뮤니케이션 끝에 NFW 설정 문제가 아닌 AWS 서비스 자체의 이슈라는 걸 확인받았습니다. 원인은 NFW 내부에서 트래픽을 처리하는 Firewall Host들이 트래픽 양에 따라 자동으로 늘었다 줄었다 하는(Auto Scaling) 구조에 있었습니다. 트래픽이 줄어들어 Firewall Host 하나가 축소(Scale-in)되는 시점에, 이미 제거된 Host 정보를 GWLB(Gateway Load Balancer)가 계속 붙들고 있다가 그쪽으로 트래픽을 흘려보내는 latent bug였습니다. 이미 사라진 곳으로 트래픽이 가니 당연히 응답이 없고, 결국 ALB 503 에러와 지연으로 나타난 것이었습니다.
AWS도 이 버그를 인지한 뒤 리전 내 가용 영역별로 순차 검증하며 패치를 배포했고, 저희 환경에도 적용된 뒤에야 문제가 해결됐습니다. 다만 이 과정 자체에 시간이 걸리면서 프로젝트 기간이 한 달 더 늘어나는 결과로 이어졌습니다.
이 과정에서 아쉬운 점도 하나 있었습니다. TGW Native NFW은 매니지드 환경에 구축되는 자원이기 때문에 AWS TAM이 모니터링 할 수 없습니다. 무조건 AWS Support Case를 통한 서포트 엔지니어에게 NFW 세부 상태를 확인 받아야 합니다. 운영 중인 서비스와 NFW의 중요도를 고려하여 레거시 NFW을 쓸 것인지, 관리의 편의성을 위하여 TGW Native NFW을 쓸 것인지를 꼼꼼히 비교 후에 사용하는 것을 권장드립니다.
8. 마무리
우여곡절 끝에 방화벽은 개발 환경부터 운영 환경까지 순차적으로 적용되었습니다. WEB-WAS 사이 구간의 모든 트래픽이 NFW를 거치도록 라우팅이 완전히 전환됐습니다. 예정보다 한 달 늦어지긴 했지만 새 구조 위에서 정상적으로 동작했습니다.
검증은 단순히 “잘 붙었다”에서 끝나지 않았습니다. 방화벽 정책이 실제 서비스 트래픽을 막지 않으면서도 의도한 대역만 통과시키는지, CloudWatch 지표와와 S3에 쌓이는 로그를 통해 확인했습니다. 여기에 Splunk 연동까지 맞물리면서 이제는 이 구간에서 이상 트래픽이 발생해도 월 단위가 아니라 실시간으로 알아챌 수 있는 체계가 갖춰졌습니다.
돌아보면 이번 프로젝트는 방화벽 하나를 붙이는 일이었다기보다는 예상 밖의 변수들과 계속 부딪히며 하나씩 풀어나간 여정에 가까웠습니다. NFW 설정 및 로그부터 배워가야 했고, 옆 건물을 오가며 발을 동동 구르기도 했고, 결국엔 저희 잘못이 아닌 AWS 자체 버그 때문에 한 달을 더 기다려야 했습니다. 시작할 때 그렸던 두 달 기간의 계획과는 많이 달랐습니다.
그래도 그 과정에서 많은 것을 배웠습니다. 운영 중인 서비스를 전환 시의 상황을 고려하여 자동화와 롤백 장치를 준비해 둘 것, 작업을 위해 작업계획서를 작성하고 이 내용 기반의 작업을 진행하는 방법, NFW 각 설정과 로그의 각 필드 의미, 이슈가 생길 시 AWS분들과 소통하는 법까지. 예상하지 못한 문제들을 하나씩 마주하고 풀어내는 과정에서, 그만큼 단단해지고 성장한 것 같습니다.