2편에서 우리는 서버 파일을 수정할 수 없는 한계에 부딪혔습니다. 이 문제를 해결할 열쇠는 바로 '클라우드플레어(Cloudflare)'였습니다.
클라우드플레어는 단순한 DNS 서비스가 아니라, 쉽게 말해 '중간 관리자'처럼, 내 도메인으로 들어오는 모든 트래픽을 먼저 받는 '프록시(Proxy)' 역할을 합니다. 덕분에 트래픽이 실제 서버(블로그스팟, 티스토리)에 도달하기 전에 우리가 원하는 규칙을 적용할 수 있습니다.
네임서버 변경 및 DNS 레코드 설정
전직 개발자로서 이 부분은 익숙했습니다.
1. 네임서버 변경
먼저 도메인 구입처(가비아 등)에서 네임서버 주소를 클라우드플레어가 알려준 주소로 변경합니다. (이제 모든 DNS 관리는 클라우드플레어에서!)
(🚨 주의: 이 작업은 도메인 연결이 일시적으로(몇 분~몇 시간) 불안정해질 수 있습니다. 블로그 방문자가 적은 새벽 시간에 하시는 것을 강력히 추천합니다.)
2. DNS 레코드 설정 (Cloudflare)
클라우드플레어 대시보드의 'DNS' 메뉴에서 다음과 같이 레코드를 설정합니다.
CNAME, 이름:@(혹은example.com), 대상:ghs.google.com
(새 블로그가 블로그스팟인 경우 예시입니다. 사용하는 플랫폼에 따라 이 값은 다를 수 있습니다.)CNAME, 이름:sub(서브도메인), 대상:host.tistory.io
(이전한 티스토리 예시)
핵심! 301 리디렉션 규칙(Rules) 설정하기 (무료 플랜)
이것이 바로 우리가 클라우드플레어를 쓰는 이유입니다.
처음엔 '정규식(regex)'을 사용하려 했습니다. 하지만 '정규식 일치(matches regex)' 기능은 클라우드플레어 유료 플랜에서만 지원됩니다.
하지만 좌절할 필요 없습니다. 무료 플랜에서도 동일한 기능을 완벽하게 구현하는, 훨씬 더 쉬운 방법이 있습니다.
- 왼쪽 메뉴 규칙(Rules) > Redirect Rules로 이동합니다.
- Create rule (규칙 만들기) 버튼을 클릭합니다.
- 규칙 이름: "티스토리 옛 주소 이전" (자유롭게 입력)
When incoming requests match... (요청이 다음과 일치할 때)
- 필드 (Field):
URI 경로(URI Path) - 연산자 (Operator):
다음으로 시작(starts with) - 값 (Value):
/entry/- (설명: 이게 끝입니다! 비싼 유료 플랜의 '정규식' 기능 대신, "주소 경로가
/entry/로 시작하면"이라는 이 쉬운 규칙을 선택하면 됩니다. 티스토리 구 주소가/category/123이었다면/category/를 쓰면 되겠죠.)
- (설명: 이게 끝입니다! 비싼 유료 플랜의 '정규식' 기능 대신, "주소 경로가
Then... (다음을 수행)
- 유형 (Type):
동적(Dynamic) - 식 (Expression):
concat("https://sub.example.com", http.request.uri.path)- (설명: 이게 마법의 코드입니다.
"https://sub.example.com"(새 주소) 뒤에, 사용자가 요청한 기존 경로(http.request.uri.path, 즉/entry/123)를 그대로 붙여서 보내라는 강력한 명령어입니다.)
- (설명: 이게 마법의 코드입니다.
- 상태 코드 (Status code):
301(영구 이동)
4. Deploy (배포) 클릭!
SEO 승계의 완성
이 설정으로 "누군가 example.com/entry/...로 접속하면, 그 경로 그대로 sub.example.com/entry/...로 301 영구 이동시켜라"는 규칙이 완성되었습니다. 드디어 구글 봇에게 SEO를 승계하라고 당당히 말할 수 있게 된 것이죠.
하지만 문득 불안감이 스쳤습니다. "도메인은 국내 업체(가비아)인데, 관리는 외국 업체(클라우드플레어)? 이거 괜찮은 건가? 그냥 다시 돌아갈까?"
4편에서 이 불안감과 리스크를 전직 개발자의 관점으로 총정리합니다.