💣 하루 만에 대역폭 130GB 폭탄? Vercel 계정 중단 위기 탈출기

Supabase DB로 엔진도 교체했고, 초성 검색에 ISR 캐싱까지 달아놓으니 사이트는 그야말로 날아다녔습니다. 🚀 "아, 나 좀 개발 잘하는지도?"라며 디자이너의 자아와 개발자의 자아가 동시에 샴페인을 터뜨리던 5월 중순의 어느 날, 이메일 알림 하나가 스마트폰을 격렬하게 울렸습니다. 📱

[Vercel Alert] Your account has been suspended due to bandwidth usage... 🛑

정신이 번쩍 들었습니다. 메일함을 열어보니 하루 만에 public/logos 디렉터리에 있던 자산들이 외부에서 무차별적으로 핫링크(Hotlinking) 및 스크랩(Scraping)을 당해 약 130GB의 대역폭을 소모했다는 겁니다! 🤯 그 결과 Vercel 팀 계정이 일시 중단되는 초유의 사태가 벌어졌습니다.

평화롭던 사이드 프로젝트에 찾아온 거대한 보안 위기. 저는 즉시 팔을 걷어붙이고 인프라 방어선을 구축하기 위해 코드를 뜯기 시작했습니다. 🛠️

1. 1단계 방어: 불필요한 자산 다이어트 🧹

위기를 마주하고 가장 먼저 한 일은 적진의 타겟이 된 소스(Source) 자체를 정비하는 것이었습니다.

public/logos/ 디렉터리를 열어보니, 예전에 프로토타입을 만들 때 임시로 넣어둔 placeholder 자산(mcst.svg)이나 스크래치 파일(mcst-partial.txt) 등 실제 프로덕션과 아무 관계 없는 유령 자산들이 다수 방치되어 있더군요. 👻 외부 스크랩봇들은 이런 틈새를 기막히게 찾아내 빨대를 꽂았던 것입니다.

참조되지 않는 63개, 약 26MB 분량의 자산을 일괄적으로 영구 삭제했습니다. 그리고 실제 프로덕션 데이터는 모두 Supabase에 안전하게 보관되어 있으므로, public/logos/ 안을 깔끔하게 비워두어 공격 표면(Attack Surface) 자체를 최소화했습니다.

2. 2단계 방어: 미들웨어(Middleware)로 불법 핫링크 차단 🛑

자산을 줄였으니 이제 들어오는 길목을 막아야 했습니다. 외부 사이트나 봇이 우리 로고 자산 주소를 그대로 가져다 쓰는 불법 핫링크를 막기 위해, Next.js의 미들웨어(Middleware) 레이어에 다층 방어선을 깔았습니다.

[ 외부 요청 ] ──> Referer 검증 (미들웨어) ──> 화이트리스트 도메인인가?
                                            ├──> YES: 정상 렌더링 ⭕
                                            └──> NO : 403 Forbidden 차단! ❌

요청이 들어올 때 헤더의 Referer(어디서 이 링크를 타고 왔는지) 도메인을 화이트리스트 방식으로 검증하는 로직을 심었습니다. 우리 도메인이 아닌 낯선 off-domain에서 우리 로고를 이미지 태그로 무단 링크 걸어 대역폭을 빨아먹으려고 하면, 미들웨어가 칼같이 통과시키지 않고 403 Forbidden 에러를 뱉으며 문전박대하도록 만들었죠! 🙅‍♂️

단, 유저들의 정상적인 공유나 Slack/Discord 같은 메신저에서의 링크 프리뷰, 그리고 *.vercel.app 같은 개발 프리뷰 환경은 정상 작동하도록 예외 처리를 촘촘하게 곁들였습니다.

3. 3단계 방어: Config 헤더 설정과 구글 봇 진입 통제 🔒

여기서 끝내면 완벽한 방어가 아니죠. 더 확실하게 자산을 묶어두기 위해 next.config.ts와 검색엔진 설정까지 손을 보았습니다.

• 브라우저 롱캐시 및 자산 보호 헤더 추가: /logos/* 하위 경로로 들어오는 자산에 대해 브라우저가 오랫동안 캐싱(long-cache)하도록 설정해 불필요한 재요청 대역폭을 줄였습니다. 여기에 Cross-Origin-Resource-Policy: same-site와 X-Content-Type-Options 헤더를 강제하여 오직 허용된 사이트(same-site)에서만 자산을 안전하게 소비할 수 있도록 인프라 수준에서 락을 걸었습니다.
• robots.txt 디스얼로우: 구글이나 네이버 봇이 무지성으로 로고 이미지 자산 자체를 인덱싱하느라 크롤링 대역폭을 낭비하지 않도록, robots.ts 설정에 /logos/ 경로를 과감히 디스얼로우(Disallow) 처리했습니다.

4. 값진 교훈: 미들웨어 '조용한 실패'의 공포 👻

이 대역폭 폭탄 사건을 해결하면서, 저는 아주 식은땀 나는 개발적 교훈을 하나 얻었습니다.

사실 이전에 어드민 보안을 강화하는 과정에서 미들웨어 파일을 만들어 두었었는데, 실수로 파일명을 proxy.ts라고 잘못 만드는 바람에 Next.js가 미들웨어를 아예 인식하지 못하고 있었습니다! 🤦‍♂️ (Next.js는 오직 root의 middleware.ts 컨벤션만 인식하기 때문이죠.)

빌드는 아무 에러 없이 완벽하게 통과(Green Light)하는데, 정작 실제 서버에서는 인증 가드와 보안 미들웨어가 통째로 비활성화되어 작동하지 않는 '조용한 실패(Silent Failure)' 상태였던 것입니다.

파일명 버그를 middleware.ts로 정확하게 수정하고 나서야 모든 방어선이 정상적으로 작동하기 시작했습니다. 보안과 인프라 설정에 있어서 "컨벤션 파일명 하나가 서비스 전체를 마비시킬 수도 있다"는 무시무시한 사실을 온몸으로 배운 값진 성장의 순간이었습니다. 📝

올리브의 한 줄 요약 💡

"디자인 엔지니어의 역할은 단지 브라우저에 픽셀을 예쁘게 뿌리는 데서 끝나지 않습니다. 내가 뿌린 픽셀(자산)이 외부의 위협으로부터 안전하게 보호받고 있는지, 인프라의 비용 폭탄을 막아낼 다층 방어선을 구축할 수 있는가까지 책임지는 것이 진정한 메이커의 자세입니다."

이어지는 [5편(최종화)]에서는... 이 모든 험난한 여정을 거쳐 완성된 '로고착착'의 최종 운영 편의 기능(텔레그램 알림, 마퀴 배너)과 함께, 풀스택 디자이너로서 한 단계 완전히 진화한 올리브의 사후 회고 및 총평으로 전체 시리즈를 멋지게 마무리하겠습니다! 🏁