트래픽 20GB/일 제한과 같이 사는 법

"20GB면 충분하지 않나?"—우리도 그렇게 생각했다

서버를 처음 세팅할 때 하루 20GB 트래픽 제한이 그렇게 위협적으로 느껴지지 않았다. 단순 소개 페이지라면 실제로 충분할 수도 있다. 그런데 우리가 운영하는 것은 그런 서비스가 아니다. 결제 요청을 실시간으로 받고, 정산 데이터를 API로 파트너사에 내려주고, 자동화 파이프라인이 내부 엔드포인트를 끊임없이 두드린다. 이 환경에서 20GB는 생각보다 훨씬 빠르게 닳는다.

위험한 순간은 예측이 어렵다. 평소에는 하루 5~8GB를 유지하다가도 월말 정산 배치가 돌거나 파트너사 쪽에서 웹훅 재전송이 쏟아지면 오전 중에 15GB를 넘긴 날이 있었다. 트래픽 제한을 초과하면 서버가 응답을 못 하고, 결제 콜백이 유실되며, 정산 파일 다운로드가 중단된다. 그냥 "사이트가 느려지는" 문제가 아니다. 돈이 걸린 문제다. 이 제약을 제대로 다루지 않으면 SLA 위반과 직결된다.

결제·정산 환경에서 트래픽이 빠르게 닳는 진짜 이유

일반 웹사이트와 달리 결제·정산 서비스는 트래픽을 소비하는 패턴이 독특하다. 첫째, **웹훅 폭풍(webhook storm)**이다. PG사나 파트너 시스템이 결제 결과를 통보하는 웹훅은 네트워크 장애 후 재연결 시 밀린 건들을 한꺼번에 쏘는 경우가 많다. 건당 페이로드가 1~3KB라도 수천 건이 몰리면 순식간에 수십 MB가 소비된다. 우리가 실측한 최악의 케이스는 약 45분 안에 6,200건의 웹훅이 몰려 단일 버스트로 18MB를 소진한 사례였다.

둘째, 정산 파일 반복 다운로드다. 경리팀이나 파트너사 담당자가 같은 정산 리포트를 하루에 여러 번 내려받는 패턴은 생각보다 흔하다. 엑셀 파일 한 장이 500KB라면 10명이 하루 10번씩 내려받으면 그것만 50MB다. 셋째, 자동화 파이프라인이 만들어내는 내부 폴링 트래픽이다. 상태 확인, 큐 조회, 헬스체크—이것들이 분당 수십 회씩 돌면 하루 합산이 의외로 크다. 우리 팀이 실측해보니 자동화 내부 트래픽만으로 하루 1.5~2GB를 쓰고 있었다. 외부에 노출되지 않는 내부 트래픽도 제한에 포함된다는 사실을 처음에는 간과했다.

CDN을 트래픽 방패로 쓰되, 결제 데이터 엔드포인트는 반드시 예외로

Cloudflare 프리 플랜만 붙여도 정적 콘텐츠 오리진 요청이 60~70% 줄어드는 건 우리도 직접 확인했다. HTML, CSS, JS, 이미지가 엣지에 캐싱되면 원본 서버까지 도달하는 요청 자체가 없어진다. 정적 에셋은 캐시 TTL을 7일 이상으로 공격적으로 잡고, 콘텐츠 변경 시 파일명에 버전 해시를 붙이면 캐시 무효화 문제도 없다. 설정 한 번으로 트래픽 절감 효과가 즉시 나타나는 가성비 최고의 작업이다.

그런데 여기서 결제·정산 서비스만의 트레이드오프가 있다. 실시간 데이터는 CDN 캐시에 절대 태우면 안 된다. 결제 상태 조회(/api/payment/{id}/status), 정산 잔액 확인, 환불 처리 결과—이 엔드포인트를 캐시했다가는 이미 환불 완료된 건이 "처리 중"으로 표시되거나, 잔액이 오래된 값으로 보일 수 있다. 우리는 Cloudflare Page Rule로 /api/* 경로에 Cache Level을 명시적으로 Bypass로 설정한다. CDN을 적극적으로 활용할수록 캐시 대상과 비대상의 경계를 더 엄격하게 관리해야 한다는 것이 핵심 교훈이다. CDN을 붙이면 끝이 아니라, 붙인 이후 경계 설정이 본격적인 작업의 시작이다.

이미지·응답 압축: 숫자로 보는 실제 절감

정산 대시보드나 관리자 페이지에도 이미지는 들어간다. 로고, 아이콘, 차트 썸네일. 이미지 하나가 2MB이고 관리자 50명이 하루 5번씩 페이지를 열면 그것만 500MB다. WebP 변환과 업로드 전 리사이즈를 적용하면 동일한 이미지가 보통 400~~600KB 수준으로 내려온다—원본 대비 70~~80% 절감이다. 우리는 업로드 파이프라인에 Sharp 기반 리사이즈를 끼워 넣어 "최대 너비 1,200px, WebP 변환, 품질 80%" 규칙을 강제한다. 담당자가 원본 파일을 그대로 올려도 자동으로 처리된다.

응답 압축은 더 간단하고 효과가 즉각적이다. Nginx에 gzip on과 gzip_types에 application/json을 포함하는 세 줄이면 텍스트 기반 응답이 평균 65~~75% 줄어든다. JSON API 응답이 10KB였다면 압축 후 2.5~~3.5KB다. 정산 내역처럼 JSON 응답이 수백 KB에 달하는 엔드포인트에서는 효과가 더 크다. CPU 오버헤드는 현대 서버에서 측정 가능한 수준이 아니다. 안 켜둘 이유가 없다. 확인 방법은 간단하다: curl -I -H "Accept-Encoding: gzip" https://yourdomain.com/api/test로 응답 헤더에 Content-Encoding: gzip이 찍히는지 보면 된다.

트래픽 모니터링을 결제 이상 감지와 연결하라

제한이 있다는 사실보다 더 위험한 것은 현재 사용량을 모르는 상태다. 우리는 Nginx 액세스 로그를 하루 단위로 파싱해서 ① 총 바이트 전송량, ② 엔드포인트별 상위 10개, ③ IP별 상위 10개를 집계하는 스크립트를 매일 아침 자동 실행한다. 결과가 Slack 채널에 세 줄 요약으로 오는 형태다. 별도 대시보드 없이 awk와 sort 조합으로 충분하다. 중요한 건 이 모니터링을 단순한 "총량 체크"로만 쓰지 않는다는 점이다.

어느 날 오전 10시에 특정 외부 IP에서 /api/settlement/export 요청이 300회 발생한 적이 있었다. 트래픽 집계로 먼저 포착했고, 역추적해보니 파트너사 쪽 연동 스크립트 버그로 무한 루프가 돌고 있었다. 결제 데이터 유출은 아니었지만, 모니터링이 없었다면 해당 IP를 차단하기 전에 하루치 트래픽을 다 써버렸을 것이다. 트래픽 모니터링은 절약 도구인 동시에 보안 감지 도구다. 특정 엔드포인트에 비정상적인 요청이 집중되면, 그것은 오용이거나 버그이거나 공격 시도다. 세 경우 모두 빠른 포착이 핵심이다.

지금 당장 실행할 수 있는 체크리스트

추상적인 조언 대신, HEDVION 팀이 실제로 적용한 순서대로 나열한다.

이번 주 안에:

Cloudflare(또는 동급 CDN) 연결, 정적 에셋 캐시 TTL 최소 3일 이상 설정
Nginx gzip 또는 brotli 압축 활성화 확인 (curl -I 헤더 체크)
/api/* 경로에 CDN 캐시 Bypass 룰 명시적으로 설정 — 이것을 빠뜨리면 CDN이 오히려 독이 된다

이번 달 안에:

업로드 파이프라인에 이미지 리사이즈·WebP 변환 자동화 (Sharp, ImageMagick 등)
일일 트래픽 집계 스크립트 작성 후 Slack 알림 연결, 엔드포인트별 상위 10개 포함
자동화 워크플로우의 폴링 주기 점검—10초 간격이 30초로 바뀌어도 기능에 문제없다면 바꿔라

운영하면서 반드시 기억할 것:

트래픽 급감도 이상 신호다. 정상 트래픽이 갑자기 줄었다면 서비스 오류일 수 있다
여유가 생겼다고 느끼는 순간이 대부분 새 기능 추가나 파트너 연동 직전이다. 여유분을 항상 버퍼로 남겨라
웹훅 재시도 로직이 있다면 지수 백오프(exponential backoff) 와 최대 재시도 횟수를 반드시 설정하라. 무한 재시도는 웹훅 폭풍의 주범이다

20GB 제한이 처음에는 불편하게 느껴졌지만, 이 제약을 제대로 다루는 과정에서 시스템이 더 견고해졌다. 비용을 쓰지 않고 버티는 것이 목표가 아니다. 같은 자원으로 더 많은 결제와 정산을 안정적으로 처리하는 것—그것이 작은 팀이 제약 안에서 만들어야 할 진짜 결과다.

— by slecs