timeware.kr 도메인 인프라 구축기: Gabia + Cloudflare + Vercel

배경

서비스를 안정적으로 운영하면서도, 이후 확장 시 인프라를 다시 갈아엎지 않기 위해 도메인/보안/배포 역할을 분리한 구조를 선택했습니다. 목표는 단순 접속 성공이 아니라, 검색엔진/AI 크롤러가 한 주소 체계를 일관되게 인식하도록 만드는 것이었습니다.

인프라 결정

핵심은 "소유권(등록)"과 "운영 성능(배포/보안)"을 분리해 각 계층을 최적화하는 것입니다.

장애 1: Query Refused

증상

네임서버를 Cloudflare로 바꿨는데, 일부 구간에서 DNS 질의가 거부되거나 응답이 불안정했습니다.

원인

권한 NS 변경은 전파됐지만 Cloudflare Zone 활성화 트리거가 즉시 동작하지 않았습니다.

조치

Cloudflare 대시보드에서 Re-check now를 수동 실행해 authoritative 상태를 강제 갱신했습니다. 이후 DNS 조회가 정상화됐고, Vercel 검증도 진행 가능해졌습니다.

장애 2: 307 Redirect와 canonical 혼선

증상

루트 도메인과 www 간 리다이렉트가 임시(307)로 동작하거나, canonical/og:url/sitemap 기준 도메인이 혼재됐습니다.

원인

Vercel의 Primary Domain 정책과 DNS 레코드/CNAME 구조가 완전히 정렬되지 않은 상태였습니다.

조치

1. Vercel에서 Primary 도메인 전략을 확정
2. Cloudflare DNS 레코드를 Vercel 권장 구조로 정리
3. 앱 메타데이터, robots, sitemap, webhook endpoint 도메인을 단일 기준으로 통일

이 과정을 거치며 검색엔진 관점의 URL 신호를 한쪽으로 모으는 canonicalization을 완료했습니다.

실제 실행 워크플로

1. timeware.kr 신규 등록
2. 네임서버를 Cloudflare(coby, michelle)로 변경
3. Cloudflare DNS에서 Vercel 연결 레코드 설정
4. 검증 단계에서 Proxy를 일시적으로 DNS only로 전환해 소유권 확인 안정화
5. 루트/www 리다이렉트 방향 고정
6. canonical, og:url, robots.txt, sitemap.xml 도메인 정합성 점검
7. Contentful publish 이후 /api/revalidate/contentful 재검증 동작 확인

운영 체크리스트

1. https 강제 + 1-hop 리다이렉트 유지
2. canonical과 sitemap의 도메인 기준 일치
3. robots.txt의 Host/Sitemap 값 일치
4. Search Console/Naver 검증 메타 노출 확인
5. webhook 재검증 실패(401/503) 시 원인 로그 추적 가능 상태 유지

CTO 관점에서의 의미

이번 작업의 결과는 "도메인 연결 완료"가 아니라, 운영 신호(SEO/GEO/AEO)가 흔들리지 않는 주소 체계를 확보한 것입니다. 초기 단계에서 canonical과 재검증 경로를 고정하면, 이후 콘텐츠 자동 배포와 보안 정책 강화 시 기술 부채가 크게 줄어듭니다.

다음 단계

1. Cloudflare 보안 정책(HSTS/TLS 1.3/Bot 정책) 운영 기준 확정
2. revalidate 실패 시 알림 채널(Slack/메일) 연동
3. 주기 점검(리다이렉트, robots, sitemap, canonical) 자동화 스크립트 추가