WAF와 API 게이트웨이는 같은 방어선이 아니다

WAF와 API 게이트웨이는 모두 요청 앞단에 놓이기 때문에 같은 제품처럼 보이기 쉽다. 실제 장애와 침해는 두 장비의 기능 차이보다 “어느 통제를 누가 책임지는지”가 비어 있을 때 발생한다. WAF 팀은 게이트웨이가 막는다고 생각하고, 플랫폼 팀은 애플리케이션이 검증한다고 생각하며, 개발팀은 경계 장비가 처리한다고 가정하면 인증된 공격 요청이 그대로 핵심 로직까지 도달한다.

설계의 출발점은 제품 비교표가 아니라 요청 경로다. 클라이언트 → CDN·로드밸런서 → WAF → API 게이트웨이 → 서비스 → 데이터 저장소를 그리고, 각 단계에서 검증할 항목과 실패 시 동작을 적어야 한다. 관리형 서비스의 실제 배치 순서는 공급자마다 다를 수 있으므로 논리적 책임과 물리적 위치를 구분한다.

두 방어선의 역할을 먼저 분리한다

통제 영역	WAF가 잘하는 일	API 게이트웨이가 잘하는 일	애플리케이션이 끝까지 책임질 일
공격 패턴	SQL 삽입·경로 탐색·비정상 인코딩 등 알려진 패턴 탐지	제한된 요청 변환과 정책 실행	데이터 계층의 매개변수화와 안전한 API 사용
인증	명백한 봇·악성 원본 차단 보조	토큰 형식·서명·발급자·대상 검증, 인증 정보 전달	사용자·서비스의 실제 업무 권한 판단
사용량	IP·지역·네트워크 기반 거친 제한	키·계정·테넌트·엔드포인트별 할당량	업무 객체·잔액·재고·수취인별 남용 방어
입력	크기·메서드·헤더·일반 공격 문자열 제한	콘텐츠 유형·스키마·필수 필드 검증	필드 간 관계와 업무 의미 검증
라우팅	공격 트래픽을 경계에서 차단	버전·경로·백엔드 라우팅, 카나리 분배	호환성·트랜잭션·오류 처리
관측성	차단 규칙, 원본, 요청 특성	인증 주체, 정책 결과, 백엔드 지연	객체 ID, 업무 결과, 데이터 변경 감사

가장 중요한 구분은 인증과 권한이다. 게이트웨이가 유효한 액세스 토큰을 확인해도 사용자가 요청한 주문, 문서, 계좌가 그 사용자의 것인지는 모를 수 있다. 객체 수준 권한과 테넌트 경계는 애플리케이션이 매 요청마다 검증해야 한다. WAF 규칙으로 /users/123의 123이 현재 사용자에게 허용되는지 판단하려 해서는 안 된다.

요청 경로별 최소 정책

인터넷 경계

• 허용할 HTTP 메서드와 콘텐츠 유형을 명시한다.
• 경로·쿼리·헤더 크기에 상한을 두고 압축 해제 후 크기도 고려한다.
• 신뢰할 프록시가 설정하는 전달 헤더와 클라이언트가 임의로 넣을 수 있는 헤더를 분리한다.
• 관리·디버그·내부 경로는 공개 경로와 별도 정책으로 묶는다.
• 차단 규칙에는 소유자, 적용 범위, 변경 티켓, 만료 또는 재검토일을 붙인다.

API 게이트웨이

• 토큰의 서명뿐 아니라 발급자, 대상, 만료, 허용 알고리즘을 검증한다.
• 인증 실패와 권한 부족을 구분하되 외부 오류 응답에 민감한 내부 정보를 노출하지 않는다.
• 계정·키·테넌트·엔드포인트·비용 단위를 조합해 제한한다.
• 스키마 검증 실패는 백엔드로 전달하지 않고, 정책 버전과 이유 코드를 로그에 남긴다.
• 백엔드로 전달하는 신원 헤더는 외부 입력을 제거한 뒤 게이트웨이가 새로 생성한다.

애플리케이션

• 객체 단위 권한과 필드 단위 권한을 각각 검증한다.
• 단순 JSON 스키마로 표현할 수 없는 업무 규칙을 확인한다.
• 멱등성 키, 중복 요청, 재시도, 순서 뒤바뀜을 처리한다.
• 데이터 변경에는 주체, 대상 객체, 이전·이후 상태, 결과를 감사 로그로 남긴다.
• 공급자 장애나 게이트웨이 우회 경로에서도 동일한 핵심 권한 검사가 실행되게 한다.

흔한 실패 모드와 탐지 신호

실패 모드	탐지 신호	확인할 내용
WAF 우회 원본 노출	원본 주소로 직접 들어오는 요청, WAF 요청 수와 원본 요청 수 불일치	원본 방화벽이 WAF·게이트웨이 경로만 허용하는가
전달 헤더 신뢰 오류	외부 요청이 내부 사용자·관리자 헤더를 포함	프록시 체인별 헤더 제거·재작성 규칙이 있는가
규칙 중복과 충돌	WAF는 허용했지만 게이트웨이가 대량 거부하거나 반대 현상 발생	같은 통제의 소유자와 우선순위를 정했는가
스키마 검증의 선택적 적용	신규 경로나 특정 콘텐츠 유형에서 검증 건수가 0	모든 버전·메서드에 정책이 연결됐는가
인증은 했지만 권한 검증 누락	정상 토큰으로 다른 객체 ID 조회가 성공	객체·테넌트 테스트가 자동화됐는가
긴급 예외 영구화	특정 IP·파트너·경로의 허용 규칙이 계속 증가	예외에 만료일과 사용량 모니터링이 있는가
차단 모드 즉시 전환	배포 직후 4xx·고객 문의가 급증	관찰 모드, 표본 검토, 단계적 확대를 했는가

WAF 이벤트만 보고 공격이 막혔다고 결론 내리면 안 된다. 같은 request_id 또는 추적 식별자를 WAF, 게이트웨이, 서비스 로그에 전달해 “경계에서 탐지된 요청이 실제로 어디까지 갔는지”를 연결해야 한다. 자세한 필드 설계는 보안 로그 파이프라인의 최소 요건과 함께 정리한다.

예시: 인증된 사용자의 대량 객체 조회

공격자가 정상 계정을 탈취한 뒤 /api/v1/invoices/{id}의 숫자를 순차 변경한다고 가정하자. 요청 형식은 정상이고 토큰도 유효하므로 일반적인 WAF 서명과 게이트웨이 인증은 모두 통과할 수 있다.

1. 게이트웨이는 계정·세션·엔드포인트별 조회 속도를 제한한다.
2. 애플리케이션은 각 청구서가 현재 테넌트에 속하는지 확인한다.
3. 연속된 객체 ID, 낮은 성공률, 짧은 간격 같은 행위 신호를 탐지한다.
4. 위험이 높아지면 토큰 폐기, 추가 인증, 세션 차단으로 연결한다.
5. 조사 시 요청 ID, 주체, 객체 ID, 응답 결과를 묶어 조회한다.

이 시나리오는 API 레이트 리밋은 남용 방어 장치다에서 다루는 다차원 제한이 필요한 이유를 보여 준다. IP 하나만 제한하면 분산 요청에 약하고, 계정 하나만 제한하면 여러 탈취 계정을 이용한 공격을 놓칠 수 있다.

안전한 도입 순서

1. 경로 목록을 만든다. 공개, 파트너, 관리자, 내부 API를 구분하고 소유자를 붙인다.
2. 현재 통제를 매핑한다. 인증, 권한, 스키마, 제한, 로깅이 어느 계층에서 실행되는지 기록한다.
3. 관찰 모드로 기준선을 잡는다. 차단 예상 건수와 정상 트래픽 영향을 엔드포인트별로 본다.
4. 저위험 규칙부터 차단한다. 허용되지 않은 메서드, 과도한 크기, 명확한 비정상 프로토콜부터 적용한다.
5. 업무 테스트를 붙인다. 다른 테넌트 객체 접근, 재시도, 중복 결제, 순서 조작을 자동화한다.
6. 예외를 줄인다. 모든 허용 목록에 이유·소유자·만료일·사용량을 기록한다.
7. 우회 경로를 시험한다. 원본 주소, 대체 도메인, 이전 버전, 배치 엔드포인트가 같은 정책을 받는지 확인한다.

운영 대시보드에 넣을 지표

• WAF 탐지·차단 건수와 규칙별 오탐 번복률
• 게이트웨이 인증 실패, 스키마 거부, 제한 초과 건수
• 원본 서비스 요청 수와 경계 계층 요청 수의 차이
• 엔드포인트별 4xx·5xx·지연의 배포 전후 변화
• 예외 규칙 수, 만료 초과 수, 최근 사용 시각
• 인증된 주체의 객체 열거·대량 다운로드·비정상 메서드 사용
• 정책 버전별 고객 문의와 정상 요청 차단률
• 로그 상관관계 실패율과 누락된 추적 식별자 비율

단순 차단률을 성과로 삼으면 규칙을 세게 만들수록 좋은 것처럼 보인다. 실제 목표는 위험한 요청이 업무 로직에 도달하는 비율을 줄이면서 정상 고객의 성공률과 지연을 유지하는 것이다.

변경·장애 체크리스트

배포 전

• 정책을 적용할 경로와 제외할 경로가 명시돼 있는가.
• 게이트웨이와 서비스가 동일한 인증 주체를 해석하는가.
• 차단 대신 기록만 하는 모드와 즉시 롤백 방법이 있는가.
• 관리 경로와 이전 API 버전까지 테스트했는가.
• 오류 응답에 토큰, 내부 호스트, 규칙 이름이 노출되지 않는가.

장애 시

• WAF 또는 게이트웨이를 우회하지 않고 제한적으로 기능을 복구할 방법이 있는가.
• 공급자 장애 때 적용할 최소 허용 정책이 문서화돼 있는가.
• 정책 변경자와 변경 시각을 감사할 수 있는가.
• 과도한 차단과 실제 공격을 구분할 기준선이 있는가.
• 긴급 예외가 자동 만료되고 사후 검토 티켓을 만드는가.

B2B 고객에게 이 구조를 설명할 때는 제품명보다 책임 경계를 보여 주는 편이 낫다. 인증, 테넌트 격리, 로그, 제한, 버전 정책을 묶은 증거는 API 제품 보안 로드맵에서 이어서 정리할 수 있다.

참고 기준

• OWASP API Security Top 10 2023
• OWASP Top 10:2025
• RFC 9110: HTTP Semantics
• NIST Secure Software Development Framework SP 800-218

최종 판단

WAF와 API 게이트웨이를 구분하는 목적은 도구를 더 사기 위해서가 아니다. 요청 경로의 각 계층이 어떤 판단을 내리고, 실패했을 때 어느 계층이 마지막 방어선이 되는지 분명히 하기 위해서다.

WAF는 악성 입력의 양을 줄이고, 게이트웨이는 공통 정책을 일관되게 실행하며, 애플리케이션은 업무 권한과 데이터 경계를 끝까지 책임져야 한다. 세 계층의 로그와 변경 절차까지 연결될 때 비로소 방어선이 된다.