비용을 줄이는 과정에서 홈페이지 문의메일이 임시 통합 수신처로 바뀐 일이 있었다. 이후에는 각 사이트의 변경 전 설정을 기준으로 다시 복구했다.

2026년 9월 7일 후속 기록에는 대상 열 개 모두가 원래 설정과 일치했다고 남아 있다. 최신 기술을 적용하는 것보다 먼저 지켜야 할 것이 있다는 경험이었다. 어느 문의가 누구에게 가야 하는지는 서비스의 약속이었다.

문의하는 사람의 입장에서 다시 본다

나는 내 사업의 문의가 나에게 도착하길 기대한다. 그 당연한 기대가 서버를 정리하는 과정에서 바뀌어서는 안 된다. 기술적으로 편한 연결보다 문의를 보낸 사람과 받는 사람의 관계를 먼저 보존한다.

복구는 이메일 주소 한 줄로 끝나지 않았다

전용 Worker에서는 수신 허용목록과 수신처 설정을 함께 대조했다. 구형 Worker 일부는 소스에도 임시 주소가 들어 있었기 때문에 원본 코드와 설정으로 해당 Worker만 재배포했다. Pages의 서비스 바인딩과 인증 비밀 바인딩은 보존했다.

이 사건 이후 내가 중요하게 보는 것은 사이트별 경계다. 사이트 식별자, 문의 엔드포인트, 연결된 Worker, 허용 수신처, 발신 검증 방식이 한 묶음으로 설명돼야 한다. 일반 공개 연락 링크와 서버에서 보내는 메일도 구별한다.

내가 먼저 사용하는 비발송 점검표

  1. 프로젝트의 문의 주소가 같은 사이트의 서버 경로로 향하는지 확인한다.
  2. 서비스 바인딩이 존재하는 이메일 Worker를 가리키는지 확인한다.
  3. Worker의 수신 설정과 허용목록이 같은 정책을 따르는지 대조한다.
  4. GET, 허용되지 않은 요청, 형식이 잘못된 입력처럼 메일이 나가지 않는 조건부터 검사한다.
  5. 정상 문의 발송 테스트는 허용된 사이트와 수신처에서 한 번 실행하고 서버 수락과 수신함 도착을 따로 확인한다.

과거 설정을 현재 API 설명과 구별한다

이 복구 사례는 당시의 설정에 관한 기록이다. 현재 Cloudflare Email Service 문서는 Workers 바인딩과 발신·수신 제한을 설명한다. 새 프로젝트에는 작성일의 현재 문서를 적용하고, 예전 소스의 호출 형태를 무조건 복사하지 않는다.

코드와 구현 살펴보기

비발송 경로 존재 확인 예시

curl.exe -i -X GET ($siteUrl + '/api/register')
# POST 전용 경로라면 405와 명확한 응답을 확인한다.
# 이 결과만으로 실제 메일 도착을 증명하지 않는다.

내가 기록에 남긴 한계

그 복구 작업에서는 테스트 46개, 사전 배포 검사와 바인딩 검사, 비발송 운영 경로 검사가 통과했다. 실제 테스트 메일은 보내지 않았다. 따라서 설정 복구와 비발송 검증 완료까지가 확인된 결과다.

메일 연결을 설명하는 좋은 인수인계는 주소만 알려주지 않는다. 다른 사이트의 문의가 섞이지 않는 이유와 실패를 확인할 경로까지 남긴다.