매주 누군가가 트래픽과 백링크, 몇 년간 쌓인 구글의 신뢰를 가진 실제 사이트를 AI 빌더로 옮기고 싶어 찾아온다. 신선한 아이디어도, 프로토타입도 아니다. 잃을 것이 있는 기존 비즈니스다. 이는 빈 프롬프트에서 시작하는 것과는 다른 작업이며, 내가 봐온 고통의 대부분은 그것을 똑같은 작업처럼 다뤘기 때문에 생긴다.
이 작업이 잘못되는 방식은 세 가지로, 너무 자주 일어나서 제목만 보고도 지원 티켓 내용을 예측할 수 있을 정도다. 올바른 방법은 특별히 영리하지 않다. 그저 이 세 가지를 그만두고 나서야 도달하게 되는 것일 뿐이다.
실수 하나: 기존 콘텐츠를 통째로 넣고 구조는 알아서 정리되길 바라기
이런 본능은 이해가 간다. 사이트가 있고, 거기에 글이 있으니, 그 글을 채팅에 붙여 넣고 빌더에게 "이걸 더 낫게 만들어줘"라고 요청한다. 결과물은 대개 새로워 보이지만 예전처럼 읽히는 사이트다 — 똑같이 길게 이어지는 서비스 설명 문단, 열다섯 개 분량의 일을 하고 있는 똑같은 세 개의 제목, 이제는 좀 더 나은 템플릿으로 포장되었을 뿐이다. 빌더는 요청받은 대로 했다. 재구성이 아니라 재단장을 요청했으니까.
잔해는 약 6주 뒤에 드러난다. 새 사이트의 순위가 예전 사이트와 정확히 같은 자리, 혹은 그보다 약간 낮은 자리에 머물 때다. 실제 정보 구조가 전혀 바뀌지 않았으니 나아진 것도 없다 — 세 페이지로 나뉘어야 할 서비스가 여전히 하나의 평면적인 페이지에, 경쟁사 사이트가 1년째 순위를 얻고 있는 FAQ 콘텐츠는 여전히 빠져 있다. 방 개수가 잘못된 집에 새로 페인트를 칠해도 방 개수는 여전히 잘못되어 있다.
열한 가지 서로 다른 서비스를 다루는 4,000단어짜리 "서비스" 페이지를 가진 고객이 있었다. 그는 "항상 효과가 있었다"는 이유로 그대로 마이그레이션하길 원했다. 사실 효과가 없었다 — 동시에 모든 것에 관한 페이지였기 때문에 어떤 구체적인 것에도 순위가 잡히지 않았다. 그대로 옮겼다면 순위가 안 잡히는 페이지를 더 예쁘게 만든 버전에 그쳤을 것이다.
여기서 실제로 효과가 있는 방법은 마이그레이션을 빌드 이전의 감사로 취급하는 것이다. 기존 콘텐츠를 입력하되, 먼저 콘텐츠 목록부터 요청한다. 어떤 페이지가 존재하는지, 각 페이지가 실제로 무엇에 대해 순위를 노리는지, 어디서 두 주제가 한 URL에 뭉쳐 있고 어디서 한 주제가 다섯 페이지에 걸쳐 얇게 퍼져 있는지. 그 목록이 계획이 된다. 기존 사이트는 템플릿이 아니라 자료일 뿐이다.
실수 둘: URL이야말로 구글이 실제로 신뢰하는 대상이라는 사실을 잊기
이것이 가장 비싼 실수다. 새 콘텐츠가 진짜로 더 나아졌다 해도, 기존 경로를 새 경로에 매핑하지 않고 URL 구조를 바꾸는 사이트 마이그레이션은 몇 년간 쌓인 신호를 통째로 버리는 셈이다. 백링크는 404 페이지를 가리키게 된다. 구글은 이미 다른 주소에서 신뢰했던 페이지를 다시 크롤링하고 다시 신뢰를 쌓아야 한다. 기존 북마크와 이메일 서명에서 오는 직접 트래픽은 막다른 길에 도달한다.
나는 사람들이 이 문제를 출시 후, 분석 대시보드가 상승 곡선 대신 절벽을 보여줄 때야 비로소 알아채는 것을 봐왔다. 그 시점에서의 해결책은 사후에 리다이렉트를 추가하는 것이며, 손실의 일부는 회복해도 전부는 아니다 — "URL이 옮겨졌다"와 "누군가 알아채고 고쳤다" 사이의 간극은 다시 돌려받지 못하는 몇 주치의 손실된 자산으로 측정된다.
| 기존 방식 | 무엇이 무너지는가 | 대신 해야 할 일 |
|---|---|---|
| 빌더가 새 디자인에 맞는 대로 URL 구조를 생성하게 둔다 | 모든 인바운드 백링크와 북마크가 이제 404 페이지를 가리킨다 | 빌드를 시작하기 전에 기존 사이트맵을 먼저 내보내고, 모든 기존 URL을 새 대응 URL에 매핑한다 |
| 홈페이지만 리다이렉트하고 내부 페이지는 404로 남긴다 | 심층 페이지들은 각자 개별적인 링크 자산을 가지고 있으므로, 하나씩 잃는 것이 누적된다 | 더 넓은 페이지로 통합되는 URL이라도, 의미 있는 기존 URL은 모두 301 리다이렉트한다 |
| 리다이렉트를 "나중에, 사이트가 라이브된 다음에" 추가한다 | 크롤러와 클릭하는 사용자들이 트래픽이 가장 불안정한 바로 그 시기에 막다른 길에 부딪힌다 | 리다이렉트는 새 사이트가 공개되는 것과 동시에, 나중이 아니라 바로 그 순간 활성화된다 |
이 중 어느 것도 특별한 게 아니다. 누구도 빌더를 만지기 전에 만드는, 열 두 개의 열로 된 스프레드시트일 뿐이다. 지루하고 빌드 자체가 재밌는 부분이라서 사람들이 건너뛰는 단계일 뿐이다.
실수 셋: 되돌아갈 방법 없는 빅뱅식 전환
세 번째 실패 유형은 콘텐츠나 URL과는 전혀 관계가 없다 — 전환 자체가 실제로 어떻게 이루어지는가에 관한 것이다. 누군가 새 사이트를 만들고, 미리보기에서 보이는 모습이 마음에 들어 그날 오후 도메인을 그쪽으로 돌려버린다. 스테이징 기간도 없고, 실제 트래픽 하에서의 나란한 비교도 없고, 미리보기가 잡아내지 못한 문제가 생겼을 때 어떻게 할지에 대한 계획도 없다 — 조용히 실패하는 문의 양식, 테스트에서는 잘 되지만 실제 결제 양이 몰리면 막히는 결제 흐름, 데스크톱에서는 잘 렌더링되지만 고객 절반이 쓰는 바로 그 휴대폰에서는 깨지는 페이지 같은 것들 말이다.
여기서의 잔해는 즉각적이기 때문에 가장 시끄러운 종류다. 지원 메일함이 가득 찬다. 누군가는 10분마다 분석 지표를 새로고침하며 그래프가 잘못된 방향으로 가는 것을 지켜보고, 롤백을 하려면 DNS를 다시 돌려야 하는데 그 자체가 전파되는 데 시간이 걸리므로, 되돌리기로 결정한 후에도 나쁜 경험은 계속된다.
해결책은 화려하지 않다. 전환 하루나 이틀 전에 DNS TTL을 낮춰서 필요할 경우 롤백이 빠르게 전파되도록 하고, 새 사이트를 먼저 미리보기나 스테이징 서브도메인에서 실제 고객처럼 사용해보고, 새 사이트가 올라간 순간 바로 없애버리지 말고 전환 후 최소 몇 주간 기존 사이트의 호스팅을 그대로 살려둔다. 마지막 부분은 몇 달러 정도의 호스팅 비용으로 진짜 보험을 드는 것이다. 사람들이 이를 건너뛰는 이유는 기존 요금제를 취소하는 게 마무리처럼 느껴지고, 마무리는 진전처럼 느껴지기 때문이다.
올바른 방법은 실제로 어떤 모습인가
종합해보면, 이 방법은 잘못된 방식보다 일이 더 많은 것이 아니다 — 순서만 다를 뿐 작업량은 같다. 재구축 전에 감사한다. 출시 전에 URL을 매핑한다. 전환 전에 스테이징을 거치고, 전환 후 몇 주간 되돌아갈 방법을 남겨둔다. 그렇게 나온 사이트는 그저 더 새로워 보이는 데 그치지 않는다. 기존 사이트가 이미 얻어낸 모든 것을 그대로 유지한다. 그것이 처음부터 다시 시작하는 대신 마이그레이션을 하는 이유 전부였다.
