새 도메인 rate-limit 자동 적용으로 보안 실수 없애기

신규 도메인을 온보딩할 때마다 수동으로 Cloudflare rate-limit 설정을 하던 과정을 자동화로 전환했다. 문서도 정책도 함께 정리해서 "신규 도메인은 무조건 rate-limit이 적용된다"는 명확한 기본값을 만들었다.

신규 도메인 온보딩이 보안 사각지대였던 이유

도메인을 새로 추가할 때는 할 일이 많다. DNS 설정, TLS 인증서, 캐싱 정책, 서버 설정... 그리고 보통은 체크리스트가 있다. "이걸 빼먹으면 안 된다"고 문서에 써있지만, 사람은 빠뜨린다. 특히 rate-limit처럼 "모든 도메인에 적용돼야 하는" 보안 정책은 더 그렇다.

내가 발견한 패턴:
- 온보딩 담당자가 바뀔 때마다 누군가는 rate-limit 설정을 깜빡함
- 특정 도메인은 "임시라서" 또는 "트래픽 양이 적어서" 빠짐
- 나중에 문제가 터졌을 때 역추적이 필요함
- 같은 실수가 반복됨

이건 단순히 "한 명이 실수한 것"이 아니라, 프로세스 설계의 문제였다. 자동화와 기본값 설계가 없으면, 팀이 커질수록 일관성이 깨진다.

cf_harden.py로 기본값 자동화하기

해결책은 두 부분이었다.

첫 번째: 자동화 통합
기존에 cf_harden.py라는 스크립트가 있었다. Cloudflare 설정을 코드로 관리하는 도구였는데, 이걸 신규 도메인 온보딩 자동화 파이프라인에 물렸다. 즉, 새 도메인이 추가되는 순간 자동으로 rate-limit이 먹혀 들어간다.

두 번째: 정책 문서화
단순히 코드만 넣은 게 아니라, 문서(NEW-SITE-ONBOARDING.md, hedvion-CLAUDE.md)에도 "신규 도메인은 무조건 rate-limit이 적용된다"고 명시했다. 이건 팀 전체가 따라야 할 정책 수준이고, 예외나 우회 방법이 없어야 한다.

왜 "무조건"인가

여기서 중요한 선택이 있었다. 개발자들이 "이 도메인은 trusted traffic만 와서 rate-limit 빼도 돼"라고 요청할 수 있다. 하지만 그렇게 하면:
- 요청마다 판단이 필요 (시간 낭비)
- 누군가는 실수로 예외를 줄 것 (보안 갭)
- 나중에 정책이 뭐였는지 모름 (기술 부채)

그래서 기본값을 높게 설정하기로 했다. Rate-limit이 필요 없으면 나중에 명시적으로 풀어야 하는 구조. 이렇게 하면 역할이 명확해진다.

이건 "Secure by Default" 원칙이다. 보안은 opt-out 이 아니라 opt-in 이어야 한다.

문서 정비로 팀 신뢰도 올리기

코드 변경이 절반이고, 나머지 절반은 문서였다.

• NEW-SITE-ONBOARDING.md: 신규 도메인 추가 절차를 다시 썼다. "자동으로 rate-limit이 적용되니까 따로 할 게 없다"고 명시
• hedvion-CLAUDE.md: 팀 지침에 "신규 도메인은 무조건 CF rate-limit 적용"을 추가. 이건 새 팀원이 입사했을 때 첫 단추

문서와 코드가 같은 이야기를 하면, 팀은 그걸 믿는다. 만약 코드만 바꾸고 문서를 안 했다면? 다음 온보딩 담당자는 "이게 정말 자동이야?"라고 다시 물어볼 것.

배운 점: 자동화는 "규칙을 없애는 것"

이 작업 후 깨달은 게 있다. 좋은 자동화는 "규칙을 없애는 것"이다. 체크리스트에서 항목을 뺀다는 뜻이 아니라, 그 항목을 누구도 깜빡할 수 없게 만든다는 뜻이다.

요청이 들어왔을 때:
- "rate-limit 설정 다시 확인해줄 수 있어?" → 이제는 필요 없음
- "새 도메인 온보딩했는데 뭘 빼먹었나?" → 확인할 게 줄어듦
- 새 팀원의 학습 곡선 → 자동으로 보장되는 것들이 있으면 더 빨리 생산성 가능

특히 인프라 자동화는 이런 점에서 좋다. 휴먼 에러가 없으면, 팀은 더 중요한 것에 집중할 수 있다.

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

• 모니터 쿠팡에서 보기 →
• 기계식키보드 쿠팡에서 보기 →
• 커피머신 쿠팡에서 보기 →

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