새 서비스 론칭 체크리스트에 DoS 방어 기본 설정 추가

새 서비스를 론칭할 때마다 빠지던 게 있었다. 아, 이건 아니고 저건 맞고, 하면서 런칭 체크리스트를 돌 때 정작 DoS 공격이나 스크래핑 같은 기본 방어책은 "나중에 필요하면" 같은 톤으로 미루곤 했다. 그러다 실제로 트래픽 스파이크를 맞거나 악의적 스크래핑이 감지되면 그제야 급하게 대응하는 패턴이 반복됐다. 이번엔 그걸 구조화해서 온보딩 문서에 박아 넣기로 했다.

왜 DoS/스크래핑 방어가 새 서비스 론칭의 필수 항목인가

대부분의 팀이 그렇듯이, 우리도 새 서비스 론칭 때는 기능 완성도, 성능 테스트, 모니터링 셋업 같은 것들에 집중한다. 그건 맞다. 근데 서비스가 공개되자마자 바뀌는 게 있다. 인터넷 구석구석에서 프로브(probe)가 들어오기 시작한다. SQL injection, 취약한 엔드포인트 스캔, 그리고 단순 용량 소모를 목표로 하는 DDoS.

여기에 정당한 목적의 스크래핑도 뒤섞인다. 검색 엔진 크롤러는 당연히 좋아야 하지만, 경쟁사가 데이터를 대량으로 긁어가거나, 좀비 IP가 우리 API를 반복 호출하면서 부하를 주는 경우도 있다. 초기 론칭 단계에서 이런 트래픽이 제대로 걸러지지 않으면 실제 사용자가 느끼는 응답 시간이 악화되고, 인프라 비용도 튄다.

그런데 이런 것들이 매번 "나중에" 되고, 결국 런칭 후 문제가 터진 다음에 비상 대응한다. 물론 그때 대응하면 괜찮긴 한데, 비용 대비 효율성으로 보면 최악이다. 런칭 전에 베이스라인 설정을 다 해두고 가면, 나중에 필요한 건 튜닝만 하면 된다.

우리의 접근: Cloudflare rate-limit 10개 zone + nginx worker 튜닝

이번 문서화 작업에 담은 내용은 다음과 같다.

Cloudflare rate-limit 규칙 (10개 zone 기반)

우리는 여러 지역/서비스에 걸쳐 도메인을 운영하고 있다. 각각을 zone 으로 분리해서 rate-limit 정책을 적용했다. 기본 사상은:
- 정상 사용자 트래픽은 충분히 허용
- 의심스러운 패턴(초당 요청 수, 특정 엔드포인트 반복)은 빠르게 차단
- 지역별·서비스별로 다른 임계값 설정 가능

nginx worker 튜닝

Cloudflare 레이어에서 막지 못한 트래픽이나, 자체 호스팅 인프라에 도착한 요청도 처리해야 한다. 여기선 nginx 워커 프로세스(worker_processes)와 커넥션 수(worker_connections)를 튜닝했다.

# 기본 설정
worker_processes auto;              # CPU 코어 수에 자동 맞춤
worker_connections 2048;            # 워커당 동시 연결 수
keepalive_timeout 30s;              # HTTP keep-alive 타임아웃

# Under load (DoS 대응 시)
client_body_timeout 10s;            # 클라이언트 업로드 타임아웃 단축
client_header_timeout 10s;          # 헤더 수신 타임아웃 단축
client_max_body_size 5m;            # 요청 바디 최대 크기 제한

이 조정들이 함께 작동하면, 공격 트래픽은 Cloudflare 단계에서 대부분 차단되고, 혹시 빠져나온 것들은 nginx 단계에서 빠르게 버려진다.

문서화: 왜 체크리스트가 아니라 온보딩 필수 항목인가

이 작업에서 핵심은 "변경 파일 2개"다.

1. NEW-SITE-ONBOARDING.md

새 서비스를 론칭할 때 팀이 따라야 할 체크리스트 문서다. 그동안 이 문서에는:
- 도메인 등록
- SSL 인증서
- 모니터링 알림
- 로깅 셋업

정도가 있었다. 여기에 이번에 추가한 섹션:
- DoS/스크래핑 방어 체크리스트
- [ ] Cloudflare zone 10개 설정 (템플릿 참고)
- [ ] rate-limit 규칙 검토 및 서비스에 맞게 커스터마이징
- [ ] nginx worker 기본 설정 적용
- [ ] 초기 24시간 트래픽 프로필 모니터링

2. hedvion-CLAUDE.md (전사 지침)

여기는 팀 전체가 참고하는 기술 가이드인데, 새로 "보안 기본설정" 섹션을 만들어서 DoS/스크래핑 방어 철학과 의사결정 기준을 넣었다. 예를 들어:
- "언제 rate-limit을 5req/sec로 vs. 20req/sec로 설정할 것인가"
- "임계값을 초과했을 때 응답 코드는 429 (Too Many Requests)를 써야 하는 이유"
- "모니터링 대시보드에서 봐야 할 지표"

팀 리딩 관점: 왜 이게 중요한 의사결정인가

새로운 서비스를 론칭할 때마다 "나중에 필요하면"이라는 리스크를 안는 것 자체가 문제다. 그건 결국 팀의 인지 부하를 증가시킨다. 누군가는 며칠 후 "어, 트래픽이 좀 이상한데?" 하고 인시던트를 열고, 팀 전체가 긴급 대응에 들어간다. 물론 나중에 "왜 미리 안 했냐"는 후문이 따온다.

반대로, 온보딩 체크리스트에 이 항목을 "필수"로 넣으면:
1. 일관성: 모든 새 서비스가 같은 레벨의 방어 기준으로 출발
2. 예측 가능성: 런칭 후 "갑자기" 이슈가 터지는 사례가 줄어듦
3. 스케일: 팀이 커질수록, 경험 있는 사람이 부재할수록, 문서화된 기준이 빛난다
4. 비용 효율: 사후 대응 비용 vs. 사전 설정 비용 비교하면, 문서 한 번 정리하는 게 훨씬 싸다

특히 우리 팀처럼 여러 서비스를 병렬로 운영하는 경우, 누군가는 처음 론칭하는 사람이다. 그 사람이 체크리스트를 보고 "아, 이건 반드시 해야 하는 것이구나"라고 알 수 있게 만드는 게 팀장의 역할이라고 본다.

다음 단계

이번 문서화로 기본 토대는 깔았는데, 앞으로의 과제는:
- 실제로 온보딩할 때 이 체크리스트가 따라가는지 모니터링
- Cloudflare 설정 템플릿을 코드나 IaC(Infrastructure as Code)로 자동화하면 더 좋을 것 같음
- rate-limit 임계값을 서비스 특성별로 더 세밀하게 분류

지금은 "DoS 방어를 론칭 전에 필수로 챙기자"는 메시지를 조직 전체에 박아 넣은 것. 다음엔 그 설정들이 정말 작동하는지, 필요에 따라 어떻게 조정하는지를 팀이 체득하게 되겠지.

🛒 이 글과 어울리는 추천 상품

• 모니터 쿠팡에서 보기 →
• 사무의자 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.