요금이 100달러를 넘으면 Partial로 나눠서 청구된다는 사실도 덕분에 알았다ㅎ
9월 Vercel 요금이 총 213달러나 나왔다. syde.kr 사이트 하나에서 나온 금액이다.
결론부터 말하자면... 바이브코딩으로 기능을 빠르게 붙여 나가면서, 그 코드가 실제로 어떻게 동작하는지는 꼼꼼히 들여다보지 않았고, 내 잘못된 코드로 인해 213달러라는 비싼 대가를 치뤄야 했다.
그런데 이 결론에 도달하기까지, 나는 꽤 오랫동안 전혀 다른 상대를 쫓고 있었다.
시작은 Vercel의 사용량 경고 메일이었다. 서버가 요청을 처리한 횟수(Function Invocations)가 548.81K에서 14.65M으로, 26배가 뛰어 있었다. 서버가 내보낸 데이터 양(Fast Origin Transfer)도 3.33GB에서 54.21GB가 됐다.
Vercel에서 날아온 메일 ㅠㅠ
갑자기 요청량이 미친듯이 증가했다...?
그런데 실제 방문자 수는 11.58K에서 11.28K로 오히려 줄어 있었다. 사람은 그대로인데 서버만 수십 배로 일하고 있었다.
원인을 추적하다가 이런 단서를 찾았다.
브라우저가 "나는 어떤 브라우저다"라고 밝히는 문자열(a.k.a. User-Agent) 중 Chrome/153.0.0.0이 110만 건의 요청을 차지하고 있었다.
요청이 어느 회선에서 왔는지(ASN) 조회하니 KT, SKT, 계명대, LG Powercomm 같은 일반적인 국내 회선이 나왔다.
버전 뒷자리가 0.0.0인 건 진짜 크롬이 아니라 크롬인 척하는 프로그램의 흔적이다. 국내 가정용 회선에서 오는 건 남의 집 인터넷을 빌려 쓰는 프록시(레지던셜 프록시)를 거쳤기 때문이다. 누군가 정체를 숨긴 채 우리 사이트를 통째로 긁어가고 있다는 뜻이었다.
솔직히 당황스러웠다. 내 사이드프로젝트가 스크래핑을 당하는 건 처음이었다.
그리고 의아했다. 대형 서비스도 아니고, 작은 커뮤니티 사이트다. 도대체 누가, 왜 여기까지 와서 이걸 긁어가는 걸까. 해킹 조직일까, 아니면 데이터를 모아서 쓰려는 악성 사용자일까.
상대가 누군지, 뭘 원하는지도 모르는 채로 요금만 불어나고 있었다. 당혹스러운 마음을 누르고, 일단 막는 것부터 하기로 했다.
요청이 가장 많은 IP 17개를 통째로 차단하고 한 IP에서 60초에 300번 넘게 요청하면 15분 동안 막는 규칙(rate limit)도 걸었다. 이제 정말 끝이라고 생각했다.
그런데 규칙을 적용하자마자, 내 PC가 차단당했다.
내가 왜 차단당했지? 평범하게 사이트를 쓰고 있었을 뿐인데? 말이 안 됐다. 그제야 외부의 누군가가 아니라 내 사이트 자체를 의심하기 시작했다.
브라우저 개발자 도구의 Network 탭을 열고 브라우저가 서버로 보내는 요청을 하나하나 유심히 봤다. 그런데 특정 순간, 요청이 미친듯이 빠르게 무한루프를 타며 반복되다가 rate limit에 걸렸다.
범인은 해킹 조직도 악성 사용자도 아니었던 것이다. 범인은 바로 내 코드였다.
우리 사이트는 Next.js라는 프레임워크로 만들었다. Next.js의 링크(<Link>)는 화면에 보이는 순간, 사용자가 누르기도 전에 그 페이지를 미리 받아둔다. 누를 것 같은 메뉴를 주방이 미리 조리해두는 셈이다. prefetch라는 기본 기능이다.
이 기본 기능이 우리 코드와 만나서 세 가지의 문제를 만들고 있었다.
첫째, 증폭. 피드와 블로그 목록의 카드 수십 개가 화면에 보일 때마다 각 상세 페이지를 미리 받았다. 그 페이지들은 로그인한 사람에 따라 내용이 달라지는 구조라 캐시되지 않았다. 스크롤만 해도 서버가 수십 번씩 일했다.
둘째, 무한루프. Next.js는 미리 받은 데이터가 예상과 다르면 받아둔 것을 전부 버리고 화면의 모든 링크를 다시 받는다. 그런데 프로필 주소 /@username의 @ 기호가 주소로 변환되는 과정에서 %40과 %2540으로 오락가락했다. 매번 "예상과 다르다"고 판정했고, 이런 링크가 화면에 두 개 이상 있으면 서로를 무효화하며 멈추지 않았다.
셋째, 또 다른 무한루프. 로고를 누르면 가는 /는 내부적으로 피드 페이지(/feed)를 보여주도록 설정돼 있었다(rewrite). 그런데 Vercel 서버에서는 이 미리 받기 요청이 엉뚱하게도 index라는 이름의 회원 프로필 페이지로 연결되고 있었다. 예상과 응답이 매번 어긋났다. 내 컴퓨터에서는 재현조차 되지 않던 문제였다.
이제와서 돌아보니 단서들은 처음부터 다른 이야기를 하고 있었다.
Chrome/153.0.0.0은 위장이 아니었다. 최신 크롬은 개인정보 보호를 위해 원래 버전 뒷자리를 0.0.0으로 보낸다.
KT, SKT 순으로 이어지는 회선 분포는 프록시가 아니라 한국 사용자 분포 그대로였다.
관문을 쉽게 통과한 건 보통내기라서가 아니라 진짜 브라우저라서였다.
페이지별 요청 수도 /feed, /showcase, /blog, /meetup이 모두 23.5만 건으로 똑같았고, 로고 링크가 헤더와 푸터에 두 개 있는 /만 정확히 2배인 47만 건이었다. 사람이 둘러본 흔적이 아니라, 화면에 있는 링크 개수가 그대로 찍힌 숫자였다.
내가 당혹스러워하며 막으려 했던 "나쁜 사람들"은 우리 사이트를 쓰던 회원들이었다. 내가 차단한 17개 IP도 대부분 그들이었을 것이다.
카드 링크, 프로필 링크, 로고 링크의 미리 받기를 차례로 끄고 나서야 페이지 하나를 열 때 나가는 요청이 9~12건으로 돌아왔다. 차단했던 IP들도 풀어줘야 했다.
돌이켜보면 이번 일에서 틀린 판단은 대부분 "확인하지 않고 믿은 것"에서 나왔다.
코드가 돌아가니까 괜찮다고 믿었다. 그 코드가 방문자 한 명당 서버에 요청을 몇 번 보내는지는 본 적이 없었다.
보안 패치라며 Next.js를 16.3.5 버전으로 올렸다. 이번 폭증은 그 직후에 시작됐다. 업그레이드가 원인인지까지는 확인하지 못했지만, 올린 뒤 트래픽을 들여다보지 않은 건 사실이다.
AI의 진단도 그대로 믿었다. 스크래퍼라는 결론, 내 컴퓨터에서 고쳤으니 해결됐다는 결론 모두 나중에 틀린 것으로 드러났다.
그럼 바이브코딩을 그만둬야 할까?
그렇지는 않다. 이번 원인을 찾고 고친 것도 결국 AI와 함께였다.
다만 방향을 바꾼 건 AI의 추론이 아니라, 내 PC가 차단당하고 Network 탭에서 요청이 반복되는 걸 직접 본 순간이었다.
속도를 내는 건 AI에게 맡기더라도, 그 코드가 실제로 무엇을 하는지 확인하는 일까지 넘겨서는 안 된다는 걸 213달러를 내고 배웠다.
