1편에서 저의 오만 했던 생각으로 저질렀던 실패를 고백했습니다. 문제는 example.com/entry/123 (옛 주소)로 오는 트래픽을 sub.example.com/entry/123 (새 주소)로 경로를 유지하며 넘겨야 한다는 것이었습니다.
이 '경로 유지'가 실패하면, 구글 검색에 노출되던 기존 글들의 SEO 점수가 모두 사라져 트래픽이 0이 될 수도 있기 때문입니다.
예전 개발자 시절이라면 간단했습니다. 서버 설정 파일(.htaccess)을 열어 RewriteRule이라는 명령어 한 줄만 추가하면 끝이었죠.
내가 통제할 수 없는 영역
하지만 지금은 상황은 다릅니다.
example.com→ 구글 '블로그스팟' 서버sub.example.com→ 카카오 '티스토리' 서버
혹시 당신은 두 플랫폼(티스토리, 블로그스팟)의 서버에 직접 접근할 수 있으신가요? (아마 대부분 '아니오'라고 답하실 겁니다.)
티스토리나 블로그스팟은 우리가 계정을 빌려 쓰는 '서비스형 플랫폼(SaaS)'이기 때문입니다. 내 컴퓨터에 직접 설치하는 워드프레스와는 근본적으로 다릅니다.
이 말은 곧, 블로그 이사의 핵심인 '서버 레벨 301 리디렉션' 을 설정할 권한이 우리에게 없다는 뜻입니다.
보통 서버를 직접 운영한다면, .htaccess (Apache 서버) 파일이나 Nginx.conf (Nginx 서버) 같은 '서버 설정 파일'에 접근할 수 있습니다.
이 파일들은 방문자가 사이트에 접속하는 순간, "어디로 보낼지"를 결정하는 서버의 '교통경찰'과도 같습니다. 만약 이 파일에 접근할 수 있다면, 아래와 같은 코드 단 한 줄만 추가하면 끝납니다.
(예시) Redirect 301 / https://새도메인.com/
이 코드 하나면 수천 개의 글이든 뭐든, 기존도메인.com으로 오는 모든 요청을 서버가 알아서 새도메인.com으로 즉시, 그리고 영구적으로(301) 넘겨줍니다. 이것이 가장 확실하고 SEO에도 완벽한 '정공법'이죠.
하지만 우리에겐 이 파일들을 수정할 권한이 전혀 없습니다. 이것이 바로 우리가 마주한 첫 번째이자 가장 큰 '난관'입니다.그럼 도메인을 구입한 '가비아' 같은 곳에서 해결해야 할까요? 도메인 구입처의 'DNS 설정'을 아무리 뒤져봐도 답이 없었습니다.
- 가비아 등 도메인 업체의 '포워딩':
example.com도메인 전체를sub.example.com메인으로 넘기는 기능뿐입니다.
- 우리가 필요한 것:
.../entry/123(개별 글 주소) →.../entry/123(새 블로그의 개별 글 주소) 처럼 '하위 경로(Path)'를 보존하는 기능.
제 개발 지식은 서버에 직접 접근할 수 있을 때만 유효했습니다. 지금처럼 모든 것이 클라우드와 플랫폼 서비스로 분리된 환경에서는 다른 접근법이 필요했습니다.
해결의 실마리: DNS 너머의 무언가
DNS는 단순히 '주소'만 알려줄 뿐, '경로'까지 제어하지 못합니다. 서버 파일을 직접 만질 수도 없습니다.
이 문제를 해결하려면 DNS 단(level)보다 한 단계 위에서, 즉 사용자와 서버 사이(엣지단)에서 트래픽을 가로채 제어하는 '무언가'가 필요했습니다.
3편에서는 마침내 찾아낸 해결책, '클라우드플레어(Cloudflare)'를 이용해 이 난관을 해결하는 실전 방법을 소개합니다.


