개인 블로그를 운영하다가 갑자기 사이트가 다운되는 경험을 했다. 에러 코드는 402 Payment Required. Vercel의 Free 플랜 트래픽 한도를 초과했다는 메시지였다. 분명 방문자가 그렇게 많지 않은 작은 블로그인데, 도대체 무슨 일이 있었던 걸까...

사건의 발단

10월 말, 내 블로그는 "This deployment is temporarily paused"라는 메시지를 띄우며 접속 불가 상태가 되었다. Vercel Dashboard를 확인해보니 충격적인 수치가 보였다.

Vercel Free 플랜 한도:
- Bandwidth: 100 GB
- Function Invocations: 100만 건

10월 실제 사용량:
- Bandwidth: 20.14 GB (20%)
- Function Invocations: 140만 건 (140%!)

Function Invocations가 한도를 40%나 초과했다. 일반적인 블로그 트래픽으로는 도저히 나올 수 없는 수치였다.

범인은 Amazonbot

트래픽 분석을 위해 vercel 대시보드의 log탭을 확인했다. 그리고 범인을 찾았다.

User Agent 분석 (지난 1시간):
- Amazonbot: 905회
- 일반 브라우저: 21회
- DotBot: 4회
- vercel-favicon: 4회

단 한 시간 동안 Amazonbot이 905회나 요청을 보냈다. 하루로 계산하면 약 21,720회, 한 달이면 651,600회다. 전체 Function Invocations의 절반 이상이 단일 봇에서 발생한 것이다.

Amazonbot이 뭐길래?

Amazonbot은 Amazon이 운영하는 웹 크롤러다. 주로 다음 용도로 사용된다.

Alexa 검색 엔진: Amazon 음성 비서 Alexa의 답변 데이터 수집

상품 정보 수집: 경쟁사 가격 모니터링, 제품 정보 업데이트

AI 학습 데이터: AWS AI 서비스를 위한 웹 콘텐츠 수집

왜 이렇게 공격적일까?

Amazonbot은 2022년에 출시된 신생 크롤러다. Google(1998년 시작)이나 Bing과 달리 늦게 시작했기 때문에, 빠르게 데이터를 축적하기 위해 공격적으로 크롤링하는 것으로 알려져 있다.

실제로 Stack Overflow, Reddit 등 여러 커뮤니티에서 "Amazonbot이 서버를 공격하고 있다", "AWS 비용이 10배 증가했다"는 불만이 끊이지 않는다.

임시 해결: Netlify로 이전

Vercel은 Free 플랜 초과 시 초과분만 결제하는 옵션이 없다. Pro 플랜($20/월)으로 업그레이드하거나, 다음 달 리셋을 기다려야 한다.

하지만 청구 주기가 캘린더 월 기준이 아니라 계정 생성일 기준 30일이라는 것을 알게 되었다. 월 기준으면 얼마 안 가 11월이 되기 때문에 그냥 뻐겨볼까 싶었는데 계정 생성일 기준 30일이면 11월 중순까지 기다리거나 Pro플랜으로 업그레이드 해야됐다.

Netlify 선택 이유

결국 Netlify로 플랫폼을 옮기기로 결정했다. 이유는 다음과 같다.

더 관대한 Free 플랜: Bandwidth 100GB (Vercel의 10배)

초과 시 유연한 대응: Vercel처럼 즉시 차단하지 않음

Next.js 지원:@netlify/plugin-nextjs로 완벽 지원

이전 과정

# 1. Netlify CLI 설치
npm i -g netlify-cli

# 2. 로그인 및 배포
netlify login
netlify init
netlify deploy --prod

# 3. Next.js 플러그인 설치
npm install -D @netlify/plugin-nextjs

# 4. netlify.toml 설정
# [build]
# command = "npm run build"
# publish = ".next"
#
# [[plugins]]
# package = "@netlify/plugin-nextjs"

# 5. DNS 변경 (hosting.kr)
# A 레코드: @ → 75.2.60.5 (Netlify IP)
# CNAME: www → bumang-blog.netlify.app

약 30분 만에 이전을 완료했고, 내가 도메인을 구매한 hosting.kr에서도 DNS 설정을 netlify 것으로 변경해줬다.

근본 해결: Rate Limiting 구현

플랫폼을 옮겼지만, 근본적인 문제는 해결되지 않았다. Netlify에서도 같은 일이 반복될 수 있었다. 봇 트래픽을 제어할 방법이 필요했다.

Rate Limiting이란?

Rate Limiting은 일정 시간 동안 허용되는 요청 수를 제한하는 기술이다.

일상 생활로 비유하자면:

놀이기구: "10분에 60명만 탑승 가능"

ATM: "하루 3회까지만 출금 가능"

무료 앱: "매일 10장까지 사진 편집 가능"

웹에서도 마찬가지다. "1분에 60회까지만 요청 가능"이라는 제한을 두면, 정상 사용자는 영향이 없지만 공격적인 봇은 차단된다.

정상 사용자 vs 봇의 차이

정상 사용자 (1분 동안):
├─ 페이지 로드: 1~3회
├─ 이미지 로드: 5~15회
├─ API 호출: 2~10회
└─ 총합: 8~28회 ✅ (60회 이하)

공격적인 봇 (1분 동안):
├─ 초당 10~100회 요청
└─ 총합: 600~6000회 ❌

Next.js Middleware 구현

기존에 JWT 토큰 검증을 위한 middleware가 있었기 때문에, 여기에 봇 차단과 Rate Limiting 로직을 추가했다.

// middleware.ts
import { NextRequest, NextResponse } from "next/server";

// Rate Limiting을 위한 메모리 저장소
const requestCounts = new Map<string, { count: number; resetTime: number }>();

// 차단할 봇 목록
const blockedBots = [
'amazonbot',
'ahrefsbot',
'semrushbot',
'dotbot',
'mj12bot',
'blexbot',
'python-requests',
'curl/',
'wget',
'scrapy',
];

// 허용할 검증된 봇
const verifiedBots = [
'googlebot',
'bingbot',
'duckduckbot',
'facebookexternalhit',
];

function applyRateLimit(key: string, limit: number, windowMs: number): NextResponse | null {
const now = Date.now();

if (!requestCounts.has(key)) {
requestCounts.set(key, { count: 1, resetTime: now + windowMs });
return null;
}

const record = requestCounts.get(key)!;

if (now > record.resetTime) {
record.count = 1;
record.resetTime = now + windowMs;
return null;
}

record.count++;

if (record.count > limit) {
console.log(`[RATE_LIMIT] Exceeded: ${key}`);
return new NextResponse('Too Many Requests', {
status: 429,
headers: {
'Retry-After': String(Math.ceil((record.resetTime - now) / 1000))
}
});
}

// 메모리 정리
if (requestCounts.size > 1000) {
const cutoff = now - windowMs;
for (const [k, v] of requestCounts.entries()) {
if (v.resetTime < cutoff) {
requestCounts.delete(k);
}
}
}

return null;
}

export default async function middleware(request: NextRequest) {
const ip = request.ip || request.headers.get('x-forwarded-for') || 'unknown';
const userAgent = request.headers.get('user-agent') || '';
const userAgentLower = userAgent.toLowerCase();

// 1. 악성 봇 차단
const isBlockedBot = blockedBots.some(bot => userAgentLower.includes(bot));

if (isBlockedBot) {
console.log(`[BLOCKED] Bot: ${userAgent} from ${ip}`);
return new NextResponse('Forbidden', { status: 403 });
}

// 2. User Agent 검증
if (!userAgent || userAgent.length < 10) {
console.log(`[BLOCKED] Suspicious: Empty/short UA from ${ip}`);
return new NextResponse('Forbidden', { status: 403 });
}

// 3. Rate Limiting 적용
const isVerifiedBot = verifiedBots.some(bot => userAgentLower.includes(bot));

let rateLimitResponse: NextResponse | null;

if (isVerifiedBot) {
// 검증된 봇: 1분에 100회
rateLimitResponse = applyRateLimit(ip, 100, 60000);
} else {
// 일반 사용자: 1분에 60회
rateLimitResponse = applyRateLimit(ip, 60, 60000);
}

if (rateLimitResponse) {
return rateLimitResponse;
}

// 4. 기존 JWT 토큰 검증 로직 (생략)
// ...

return NextResponse.next();
}

robots.txt 설정

크롤러에게 명시적으로 크롤링 속도를 제한하도록 요청했다. 물론 Amazonbot은 이를 무시하는 경우가 많지만, 그래도 설정해두는 것이 좋다.

# public/robots.txt

# 일반 봇 설정
User-agent: *
Crawl-delay: 10
Disallow: /api/
Disallow: /_next/

# Google, Bing은 허용
User-agent: Googlebot
Crawl-delay: 5
Allow: /

User-agent: Bingbot
Crawl-delay: 5
Allow: /

# 공격적인 봇 차단
User-agent: AhrefsBot
Disallow: /

User-agent: SemrushBot
Disallow: /

User-agent: DotBot
Disallow: /

User-agent: Amazonbot
Disallow: /

User-agent: MJ12bot
Disallow: /

User-agent: BLEXBot
Disallow: /

# Sitemap
Sitemap: https://bumang.xyz/sitemap.xml

Rate Limiting의 원리

다층 방어 전략

Rate Limiting은 User Agent 체크와 함께 사용할 때 가장 효과적이다.

1차 방어: User Agent 체크

봇: "나는 Amazonbot이야!"
→ 즉시 403 차단

2차 방어: Rate Limiting

영리한 봇: "나는 Chrome이야!" (User Agent 속임)
→ 1차 통과
→ 하지만 1분에 100회 요청
→ 61번째부터 429 차단!

User Agent는 쉽게 속일 수 있지만, Rate Limiting은 IP 기반이기 때문에 우회하기 어렵다.

IP로 추적하는 이유

모든 HTTP 요청에는 출발지 IP 주소가 포함된다. 이는 네트워크 통신의 기본이다.

// Next.js에서 IP 추출
const ip = request.ip ||
request.headers.get('x-forwarded-for')?.split(',')[0] ||
'unknown';

IP를 통해 알 수 있는 정보:

위치 정보: 국가, 도시, 시간대

ISP: 인터넷 서비스 공급자 (SK, KT, Amazon AWS 등)

IP 유형: 주거용, 데이터센터, 모바일

VPN/프록시 여부

과거 방문 기록

특히 데이터센터 IP인지 확인하면 봇을 더 정확하게 감지할 수 있다. 일반 사용자가 AWS나 Google Cloud의 서버에서 접속할 이유는 없기 때문이다.

Serverless 환경의 한계

Vercel이나 Netlify 같은 Serverless 환경에서는 Map 객체가 완벽하게 유지되지 않는다.

Instance Lifecycle:

Cold Start (새 인스턴스):
└─ Map 초기화

Warm Start (5-15분):
└─ Map 재사용 ✅
└─ Rate Limiting 정상 작동

Idle Timeout:
└─ 인스턴스 종료
└─ Map 소멸

새 요청:
└─ 다시 Cold Start
└─ Map 초기화 (이전 기록 없음)

완벽한 Rate Limiting을 원한다면 Redis 같은 외부 저장소를 사용해야 한다. 하지만 현재 Map 방식으로도 70-80% 정도의 효과는 충분히 볼 수 있다.

배운 점

1. Vercel Free 플랜의 함정

Vercel Free 플랜은 초과 시 초과분만 결제할 수 없다. Pro 플랜($20/월) 업그레이드만 가능하다. 그리고 청구 주기가 캘린더 월이 아니라 계정 생성일 기준이라는 점도 주의해야 한다.

2. Amazonbot은 과감하게 차단

Amazonbot을 차단해도 SEO나 트래픽에 거의 손해가 없다. Alexa 사용률이 낮고, Amazon 검색에 블로그가 노출될 일도 거의 없기 때문이다.

오히려 서버 비용만 증가시키는 "기생충" 같은 존재다. Stack Overflow, Reddit 등 많은 사이트가 Amazonbot을 차단하고 있다.

3. Rate Limiting은 필수

개인 블로그라도 Rate Limiting은 필수다. 정상 사용자는 전혀 영향받지 않으면서, 공격적인 봇을 효과적으로 차단할 수 있다.

특히 Serverless 환경에서는 요청 수가 곧 비용이기 때문에 더욱 중요하다.

4. IP 기반 추적의 중요성

User Agent는 쉽게 속일 수 있지만, IP는 그렇지 않다. IP를 통해 다음을 확인할 수 있다:

데이터센터 IP인가? (봇 가능성)

VPN/프록시 사용 중인가?

과거 차단 기록이 있는가?

1분에 몇 번 요청하는가?

5. 다층 방어의 힘

여러 방어 수단을 조합하면 더 효과적이다:

User Agent 체크: 순진한 봇 70% 차단

Rate Limiting: User Agent 속인 봇 차단

robots.txt: 착한 봇들에게 명시적 요청

Cloudflare Bot Fight Mode: 더 상위 레벨 차단

결과

Rate Limiting과 봇 차단 로직을 적용한 후, 예상되는 효과는 다음과 같다:

Before:
- Function Invocations: 140만/월
- Amazonbot 무제한 크롤링
- 비용: 초과로 인한 서비스 중단

After:
- Function Invocations: 10-30만/월 (70-90% 감소)
- Amazonbot 완전 차단
- 비용: Free 플랜 내 정상 운영

물론 완벽한 해결책은 아니다. 봇이 여러 IP를 사용하거나, 매우 천천히 크롤링한다면 우회할 수 있다. 하지만 대부분의 공격적인 크롤러는 이러한 간단한 방어만으로도 충분히 막을 수 있다.

마치며

작은 개인 블로그도 봇의 타겟이 될 수 있다는 것을 배웠다. 특히 Serverless 환경에서는 요청 수가 직접적인 비용으로 연결되기 때문에, 봇 대응이 더욱 중요하다.

Amazonbot은 상업적 목적으로 데이터를 수집하면서, 그 비용을 사이트 운영자에게 떠넘긴다. 이는 명백히 불공정한 일이다. 더 많은 사이트가 공격적인 크롤러를 차단하고, 크롤러 운영사들도 더 책임감 있게 행동해야 한다고 생각한다.

이 글이 비슷한 문제를 겪는 다른 개발자들에게 도움이 되길 바란다. 코드는 GitHub에서 확인할 수 있다.