Cloudflare 가 우리 인프라를 4단계 단순화시켰다
DNS 프록시 하나를 붙였을 뿐인데 SSL 관리, DDoS 방어, 캐시, 글로벌 CDN이 한꺼번에 해결됐다. 그 과정에서 우리가 실제로 없앤 것들을 정리한다.
서비스를 운영하다 보면 인프라 레이어가 조용히 쌓인다. 처음엔 서버 한 대였다가 인증서 갱신 크론이 생기고, DDoS 차단 스크립트가 붙고, CDN 원점 설정 문서가 위키 어딘가에 묻힌다. 팀원이 세 명뿐인 우리에게 이 잡일들은 생산성을 갉아먹는 주범이었다.
이전에 우리가 관리하던 것
Cloudflare 를 전면 도입하기 전 우리 스택은 이랬다.
- Let’s Encrypt 인증서 + certbot 자동 갱신 크론
- nginx 앞단에 붙인 fail2ban 규칙 (IP 차단 목록 수시 업데이트)
- 정적 에셋 CDN 을 위한 별도 버킷 + 원점 URL 설정
- 서브도메인 추가 시마다 DNS 레코드 + nginx 블록 + 인증서 발급 3단계
유지 자체가 불가능하진 않지만, 새 서브도메인 하나 추가할 때마다 담당자 기억에 의존하는 절차가 세 개였다.
Cloudflare 를 붙이고 없앤 것들
1단계: 인증서 관리 폐기. Cloudflare Flexible SSL 로 전환하면서 certbot 을 서버에서 완전히 제거했다. 갱신 크론도, 인증서 경로를 참조하는 nginx 설정 줄도 사라졌다. 서버 쪽 nginx 는 80 포트만 열고 프록시가 HTTPS 를 처리한다.
2단계: IP 차단 정책 이관. fail2ban 은 여전히 SSH 보호 용도로 남겨뒀지만, HTTP 레이어 차단은 Cloudflare WAF 규칙으로 넘겼다. 봇 스코어 기반 필터링이 직접 작성한 정규식 규칙보다 실제로 더 정확하다.
3단계: 에셋 CDN 통합. 별도로 관리하던 정적 에셋 원점을 없앴다. Cloudflare 가 캐시 TTL 과 엣지 캐싱을 대신 처리하므로 버킷 운영 비용과 설정 복잡도가 동시에 줄었다.
4단계: 서브도메인 추가 절차 단순화.
*.hedvion.com 와일드카드 레코드를 Proxied 로 설정해두면 새 서브도메인은 nginx 서버 블록 하나만 추가하면 끝난다. DNS 레코드 추가, 인증서 발급 두 단계가 사라졌다.
주의할 점
Flexible SSL 은 Cloudflare 와 서버 사이 구간을 암호화하지 않는다. 내부 트래픽이 민감하거나 규정 준수가 필요한 환경이라면 Full(Strict) 모드와 Origin Certificate 를 써야 한다. 우리는 트래픽 성격을 검토한 뒤 Flexible 을 선택했지만, 이 판단은 서비스마다 다르다.
또 Cloudflare 의존도가 높아지는 것 자체를 리스크로 봐야 한다. 설정 실수 하나가 전체 도메인에 영향을 줄 수 있으므로, 변경 이력 관리와 롤백 절차를 미리 정해두는 편이 낫다.
결론
인프라 복잡도를 줄이는 가장 빠른 방법은 좋은 도구에 적절히 위임하는 것이다. 우리가 직접 운영하던 네 가지를 Cloudflare 에 넘긴 결과, 신규 서비스 셋업 시간이 크게 줄었고 인증서 만료 알림이 슬랙에 뜨는 일도 없어졌다. 남은 시간은 제품 코드에 쓴다.
— by mings