Cloudflare 가 우리 인프라를 4단계 단순화시켰다

결제 인프라에서 인증서 만료가 의미하는 것

결제·정산 서비스에서 인증서 만료는 단순한 운영 실수가 아니다. HTTPS 오류가 뜨는 순간 PG사 연동 웹훅이 끊기고, 정산 배치가 실패하며, 일부 브라우저는 결제 페이지 자체를 차단한다. 우리 팀이 경험한 가장 아찔한 순간은 certbot 자동 갱신 크론이 서버 재시작 후 조용히 죽어 있었고, 만료 3일 전에야 슬랙 알림으로 뒤늦게 파악했을 때다. 갱신 자체는 15분이었지만 "왜 크론이 죽었는지" 추적하는 데 2시간이 들었다.

이 2시간이 핵심이다. 팀원 세 명이 2시간을 쓴다는 건 그날 기획하려던 정산 자동화 스펙이 다음 주로 밀린다는 뜻이다. 결제·정산 시스템은 PG사 점검, 카드사 정책 변경 같은 외부 일정에 이미 충분히 끌려다닌다. 인프라 잡일로 추가 시간을 잃는 건 팀 규모를 고려하면 감당하기 어려운 비용이다. 그래서 우리에게 인프라 단순화는 취향의 문제가 아니라 생산성의 문제였다.

우리가 관리하던 것들과 실제 비용

Cloudflare 전면 도입 전, 우리 스택은 네 가지 독립 레이어를 유지하고 있었다. Let's Encrypt + certbot 자동 갱신, nginx 앞단 fail2ban HTTP 차단, 정적 에셋용 별도 버킷 및 원점 설정, 그리고 서브도메인 추가 시 DNS·인증서·nginx 3단계 절차. 각각은 그리 복잡하지 않지만, 공통점이 하나 있었다. 문서화 상태와 담당자 기억에 의존하는 수동 스텝이 반드시 중간에 끼어 있다는 것이다.

숫자로 보면 더 명확하다. 서브도메인 하나를 추가할 때 DNS 레코드 생성 약 5분, Let's Encrypt 발급 및 nginx 설정 수정 약 20분, 배포 후 검증 약 10분으로 최소 35분이 필요했다. 연간 10~15개 서브도메인을 추가하면 단순 계산으로 약 9시간이다. 여기에 "담당자가 다른 작업을 하다 중단되는 컨텍스트 스위칭 비용"과 "야간·주말 인증서 만료 대응 시간"을 더하면 실질 비용은 두 배 이상이었다. 우리가 놓친 건 시간 총량이 아니라 매번 흐름이 끊겼다는 것이다.

4단계 단순화: 무엇을 없앴나

1단계 — 인증서 관리 완전 제거. Cloudflare Flexible SSL로 전환하면서 certbot을 서버에서 제거했다. 갱신 크론, 인증서 경로를 하드코딩한 nginx 설정 블록, 만료 알림 스크립트가 모두 사라졌다. 서버 쪽 nginx는 80포트만 열고 Cloudflare 엣지가 HTTPS 종단점 역할을 한다. "인증서 만료 알림이 슬랙에 뜨지 않는다"는 것 자체가 팀의 인지 부하를 줄인다는 걸 실감했다.

2단계 — HTTP 레이어 차단 이관. fail2ban은 SSH 보호 용도로만 남기고 HTTP 레이어 차단은 Cloudflare WAF로 넘겼다. 결제 API 엔드포인트에 붙는 봇 트래픽은 생각보다 많다. 우리 경험상 특정 결제 완료 콜백 URL이 공개되면 48시간 내에 자동화된 스캐닝 요청이 들어오기 시작한다. 직접 작성한 IP 차단 정규식은 IP 로테이션에 금방 뚫리지만, Cloudflare 봇 스코어 기반 필터링은 행동 패턴 분석이 들어가 실제로 더 정확했다. 오탐, 즉 정상적인 PG사 웹훅을 차단하는 경우가 줄어든 것은 예상 외의 수확이었다.

3단계 — 에셋 CDN 통합. 별도로 운영하던 정적 에셋 원점을 없앴다. Cloudflare의 캐시 TTL 설정과 엣지 캐싱이 그 역할을 대체한다. 월 스토리지·트래픽 비용 절감보다 "버킷 접근 키 관리"와 "원점 URL이 바뀔 때마다 코드를 수정해야 하는 의존성"이 사라진 것이 더 실질적인 이득이었다.

4단계 — 서브도메인 추가 절차 단축. *.hedvion.com 와일드카드 레코드를 Proxied로 설정해두면 새 서브도메인 추가는 nginx 서버 블록 하나만 작성하는 작업으로 끝난다. DNS 추가와 인증서 발급 두 단계가 사라지면서 35분 작업이 10분 이내로 줄었다. 숫자보다 중요한 건 "담당자를 찾아야 하는 절차"가 없어졌다는 것이다.

Flexible SSL의 트레이드오프: 결제 현장에서의 판단 기준

이 지점이 글에서 가장 중요한 대목이다. Flexible SSL은 Cloudflare와 서버 사이 구간을 암호화하지 않는다. Cloudflare 엣지에서 내 서버로 가는 트래픽은 평문 HTTP다. 일반 마케팅 사이트라면 수용 가능한 트레이드오프지만, 결제·정산 현장은 다르다. 이를 단순히 "보안이 좀 약해지는 것"으로 퉁치면 안 된다.

우리 판단 기준은 세 가지였다. 첫째, 해당 서버가 프라이빗 네트워크 안에 있고 퍼블릭 인터넷에서 직접 접근 불가한가. 둘째, 그 서브도메인이 카드번호·계좌번호 같은 민감 데이터를 직접 처리하는가. 셋째, PCI DSS나 계약상 전구간 암호화 요건이 명시돼 있는가. 이 중 하나라도 해당하면 Full(Strict) 모드와 Cloudflare Origin Certificate를 쓴다. 우리는 결제 처리 직접 경로인 PG사 연동 API 서버는 Full Strict로, 내부 대시보드와 웹훅 수신 서버는 Flexible로 구분해 운영한다. 서비스 전체에 단일 정책을 적용하는 것보다 서브도메인 성격별로 분리하는 것이 현실적이다.

우리 팀이라면 어떻게 적용할까: 실제 시나리오

정산 자동화 신규 서비스를 출시한다고 가정하자. 필요한 서브도메인은 settlement-api.hedvion.com(API 서버), settlement-dashboard.hedvion.com(내부 대시보드), webhook-receiver.hedvion.com(PG사 웹훅 수신) 세 개다.

이전 방식이라면 DNS 레코드 3개 추가, 각 서버에서 certbot 발급 3회, nginx 설정 작성 및 배포, 전체 검증으로 최소 2시간짜리 작업이고 야간 배포 시 담당자 한 명이 그 시간 동안 묶인다. Cloudflare 방식이라면 와일드카드 레코드는 이미 있으니 nginx 서버 블록 3개 추가 후 배포, 작업 시간 30분이다. 단, settlement-api는 민감 데이터 처리 경로이므로 Full Strict로 설정하고 Origin Certificate를 발급해 nginx에 적용한다. 이 부분만 추가 15분이 든다.

Cloudflare 의존도 심화에 대한 리스크 관리도 빠뜨리면 안 된다. 우리는 Terraform Cloudflare Provider로 WAF 규칙·DNS 레코드·캐시 설정 전체를 코드로 관리하고, 모든 WAF 규칙 변경은 PR 리뷰를 거친다. "설정 실수 하나가 전체 도메인에 영향을 준다"는 리스크를 낮추는 가장 실용적인 방법이 버전 관리다.

지금 당장 써먹을 수 있는 실행 시사점

1. 서브도메인 분류표부터 만들어라. 현재 운영 중인 모든 서브도메인을 "민감 데이터 직접 처리 여부"로 분류한다. Flexible을 쓸 수 있는 곳과 Full Strict가 필요한 곳을 명확히 구분하면 도입 범위가 보인다. 이 표가 없으면 도입 직후 판단을 반복하게 된다.

2. 와일드카드 레코드 + Proxied 설정을 기본값으로. 와일드카드 A/CNAME 레코드 하나가 이후 서브도메인 추가 절차를 절반 이하로 줄인다. 기존 개별 레코드와 충돌하지 않으므로 지금 당장 추가해도 운영 중인 서비스에 영향이 없다.

3. WAF 봇 스코어 임계값은 천천히 낮춰라. 처음부터 공격적으로 설정하면 PG사 웹훅이나 파트너 API 호출을 차단할 수 있다. 1~2주 관찰 모드(Challenge 없이 로그만 쌓기)로 트래픽 패턴을 파악한 뒤 임계값을 조정하는 것이 안전하다. 결제 시스템에서 오탐 한 건은 생각보다 큰 사고다.

4. Cloudflare 설정을 반드시 코드로 관리하라. Terraform Cloudflare Provider 또는 Pulumi로 WAF 규칙·DNS 레코드·캐시 설정을 버전 관리한다. 팀원 누가 변경해도 이력이 남고, 롤백은 git revert 한 줄이다. 대시보드에서 직접 수정하는 습관을 처음부터 차단해야 한다.

5. 오리진 인증서 만료일은 캘린더에 박아둬라. Cloudflare가 엣지 인증서를 알아서 관리한다는 건 맞지만, Full Strict 구간에서 쓰는 Cloudflare Origin Certificate는 최대 15년 만료다. 갱신 부담은 없지만, 도입 시점을 기록하지 않으면 몇 년 후 만료 원인을 추적하는 데 시간을 낭비한다.

인프라 단순화는 엔지니어링 미덕이 아니라 작은 팀의 생존 전략이다. 인증서 만료 추적에 쓰던 시간, 야간 대응에 쓰던 시간, 서브도메인 절차를 기억하는 데 쓰던 인지 부하 — 이것들을 걷어낸 자리에 제품 코드가 들어간다.

— by mings