[연재] × 도메인 사기 전에 통합을 먼저 끝낸 이유

연재 · 2026-09-04

옮긴 지 보름이 지났는데, 네이버가 아는 제 사이트는 두 장이었습니다

8월 9일에 네이버 서치어드바이저를 열어봤어요. 옛 주소에 이사 표시를 다 걸고, 새 도메인으로 사이트맵도 넣고, 소유 확인까지 다시 한 다음이었습니다. 그러니까 할 건 다 한 상태였죠.

색인된 페이지 두 장이라고 나오더라고요.

홈 하나, 그리고 카드 혜택 하나. 그게 전부였습니다. 그 아래 숫자들은 더 얄궂었어요. 수집 제한 0, 색인 제외 0, SEO 오류 0. 뭐가 막힌 게 아니었습니다. 그냥 안 긁어간 거예요. 문은 활짝 열려 있는데 손님이 안 온 겁니다.

노출은 160회 찍혔는데 클릭은 0이었고요. 그 160회도 전부 /cards/ 한 장에서 나온 거였습니다. 그리고 그 노출을 만든 검색어를 봤더니 전부 카드 이름이었어요. 사람들은 특정 카드 하나를 찾는데, 검색 결과에는 도구 첫 화면만 뜨니까 아무도 안 누른 거죠.

이 화면이 그때 사이트예요. 도구가 열네 개 걸려 있고, 글도 258편 있고, 겉으로는 멀쩡합니다. 그런데 검색엔진이 색인한 건 그중 일부뿐이었어요 — 7월 28일 기준 448장이던 것이 뒤에 90장까지 내려갑니다.

그래서 이사 횟수를 줄이는 게 전부였습니다

여기서 좀 실감이 났어요.

주소를 옮기는 일은 이사 표시를 거는 순간에 끝나지 않습니다. 표시를 걸어놓고, 검색엔진이 그걸 읽으러 올 때까지 기다리고, 읽고 나서 자기 색인을 고칠 때까지 또 기다립니다. 그게 며칠이 될지 몇 주가 될지는 제가 못 정해요. 제 쪽에서 할 수 있는 건 표시를 정확하게 걸어두는 것까지입니다.

그러면 결론은 하나예요. 옮기는 횟수 자체를 줄이는 겁니다.

한 번 옮기는 데 보름이 넘게 걸린다면, 두 번 옮기면 그 기다림도 두 번입니다. 게다가 두 번째 이사는 첫 번째 이사가 아직 반영되지도 않은 주소에서 출발해요. 검색엔진 입장에선 "A로 갔다더니 이제 B라고?" 가 되는 거죠.

저는 이걸 옮기기 전에 계산했습니다. 그래서 제일 사고 싶었던 걸 제일 늦게 샀어요.

도메인부터 사면 이사를 두 번 합니다

사실 순서가 반대일 뻔했어요. 도메인부터 사고 싶었거든요. 연 1만 원 조금 넘는 돈(약 $10.46)이고, 결제하는 데 5분이면 되고, 무엇보다 그게 제일 재미있는 단계입니다. 주소창에 제 이름이 박히는 순간이잖아요.

그런데 그때 도구들이 어떤 상태였냐면요. 여섯 개가 각자 자기 공짜 주소를 하나씩 갖고 살고 있었습니다. parental-pay.pages.dev, card-wallet.pages.dev, equity-holdings.pages.dev… 이런 식으로요.

여기서 도메인을 먼저 샀다고 쳐볼게요. 그럼 자연스럽게 이런 순서가 됩니다.

1. 새 도메인이 생겼으니까 도구들을 거기로 옮긴다 → 이사 1회 2. 옮겨놓고 보니 여섯 개를 어떻게 나눠 담을지 정해야 한다. 계산기를 /leave/ 에 둘지 /parental/ 에 둘지, 카드를 /cards/ 로 할지 /card/ 로 할지. 3. 정하고 나서 경로를 바꾼다 → 이사 2회

2번이 문제예요. 칸 이름은 도메인이 생겼다고 저절로 정해지지 않습니다. 그건 따로 앉아서 정해야 하는 일이고, 정하는 데는 시간이 걸려요. 그런데 도메인이 이미 손에 있으면 정하기 전에 옮기고 싶어집니다. 일단 붙여놓고 나중에 정리하지, 하고요.

그리고 옮길 때마다 따라와야 하는 뒤처리가 통째로 한 벌씩 더 생깁니다. 옛 주소마다 이사 표시 걸기, 사이트맵 다시 제출하기, 검색엔진 소유 확인 다시 하기. 소유 확인은 특히 얄궂은데, 이건 주소를 따라오지 않아요. 새 주소에서 처음부터 다시 해야 합니다.

그래서 칸 이름부터 못 박았어요

그래서 순서를 뒤집었습니다. 도메인은 나중에 사고, 여섯 개를 한 지붕 아래로 모으는 일부터 끝냈어요. 어디에 모았냐면, 클라우드플레어가 공짜로 주는 주소 victor-house.pages.dev 아래에요.

칸은 이렇게 나눴습니다.

/          본진 (글)
/leave/    육아휴직 급여 계산기
/cards/    카드 혜택
/equity/   지분·지배구조
/bible/    성경 아틀라스
/study/    기술사 스터디
/privacy/  개인정보처리방침

이 다섯 화면이 그 칸들이에요. 화면 자체는 하나도 안 바꿨습니다. 바꾼 건 이것들이 사는 주소뿐이고요.

여기서 중요한 건 이 결정이 도메인과 아무 상관이 없다는 거예요. /leave/ 냐 /parental/ 이냐는 도메인이 뭐든 똑같이 고민해야 하는 문제입니다. 그러니까 도메인 없이도 먼저 정할 수 있어요. 그리고 먼저 정해두면, 나중에 도메인이 왔을 때 바꿀 게 앞부분밖에 안 남습니다.

증거가 코드에 그대로 남아 있어요. 주소를 갈아끼우는 스크립트의 설명문에 예시가 이렇게 적혀 있습니다.

https://victor-house.com/leave        → https://victor-house.pages.dev/leave
https://victor-house.com/leave/       → https://victor-house.pages.dev/leave/
https://victor-house.com/leave/og.png → https://victor-house.pages.dev/leave/og.png

오른쪽을 보시면 .com 이 아니라 .pages.dev 예요. 이 파일을 쓸 때는 도메인이 아직 없었던 겁니다. 그런데도 /leave 라는 칸 이름은 이미 저기 박혀 있죠. 구조가 먼저고 주소가 나중이었다는 게 이 세 줄에 남아 있는 거예요.

도메인은 값 하나로 남겨뒀습니다

그러면 도메인이 왔을 때 뭘 해야 하냐. 설정 파일 한 줄을 고칩니다.

BASE_URL="https://victor-house.com"
PROJECT="victor-house"
ADSENSE_CLIENT="ca-pub-..."

이 파일 머리에는 이런 문장이 적혀 있어요. 지금 다시 읽으면 좀 웃긴데, 미래형으로 쓰여 있습니다.

도메인(victor-house.com)을 사면 아래 값만 바꾸고 publish-all.sh 를 다시 돌리면 된다. canonical, og:url, sitemap, robots 가 전부 따라온다.

"사면"이라고 되어 있죠. 아직 안 산 상태에서 쓴 문장이에요. 도메인을 살 물건이 아니라 나중에 채울 빈칸으로 취급한 겁니다.

그래서 실제로 도메인이 왔을 때 다시 짠 게 없었어요. 저 값 하나 바꾸고 배포를 다시 돌렸더니 검색엔진에 알려주는 파일들이 전부 새 주소를 달고 나갔습니다.

이사 표시는 딱 한 번, 최종 주소로 걸었습니다

그리고 그제서야 옛 주소 여섯 개에 이사 표시를 걸었어요. 매핑은 이렇게 여섯 줄입니다.

parental-pay    → /leave
card-wallet     → /cards
equity-holdings → /equity
bible-map       → /bible
sigong-study    → /study
victor-simpson  → (뿌리)

마지막 줄만 새 경로가 비어 있죠. victor-simpson 은 본진의 옛 주소라 칸이 아니라 뿌리로 보내야 하거든요. 이런 건 코드가 못 정합니다.

핵심은 오른쪽이 처음부터 최종 주소라는 거예요. 중간 주소를 한 번 거쳤다가 다시 옮기는 게 아니라, 옛 주소에서 최종 목적지로 한 번에 갑니다. 옮기는 스크립트가 그 최종 주소를 설정 파일에서 읽어오게 돼 있어서, 애초에 중간 주소를 쓸 방법이 없어요.

오늘 다시 확인해봤습니다. 한 달 넘게 지난 지금도 여섯 개 다 살아 있어요.

parental-pay.pages.dev     301 → https://victor-house.com/leave/
card-wallet.pages.dev      301 → https://victor-house.com/cards/
equity-holdings.pages.dev  301 → https://victor-house.com/equity/
bible-map.pages.dev        301 → https://victor-house.com/bible/
sigong-study.pages.dev     301 → https://victor-house.com/study/
victor-simpson.pages.dev   301 → https://victor-house.com/
www.victor-house.com       301 → https://victor-house.com/

그리고 뒤에 붙은 경로도 그대로 따라옵니다. 예를 들어 card-wallet.pages.dev/c/신한카드/ 로 들어오면 victor-house.com/cards/c/신한카드/ 로 넘어가요. 주소 하나하나를 목록으로 적어둔 게 아니라, 앞부분만 갈아끼우고 뒤는 그대로 이어붙이는 규칙 한 줄입니다. 페이지가 천 장이든 만 장이든 이 한 줄이 다 처리해요.

이사 안내문을 눈에 보이게도 한 장 남겼어요

여기서 하나 더 붙인 게 있는데요.

이사 표시라는 게 사실 브라우저나 크롤러한테만 보이는 신호예요. 사람 눈에는 아무것도 안 보이고 그냥 새 주소로 넘어갑니다. 그런데 그 신호를 안 따라가는 손님도 있어요. 어떤 수집기는 그냥 원래 주소의 내용물만 가져가려고 합니다.

그래서 옛 주소마다 눈에 보이는 안내문도 한 장씩 같이 올렸어요. "이 페이지는 여기로 옮겼습니다" 하는 짧은 페이지요. 거기엔 세 가지가 같이 들어갑니다.

이 장은 검색 결과에 넣지 말라는 표시
원본은 새 주소라는 표시
그리고 잠시 뒤 새 주소로 자동으로 넘어가는 줄

이사 표시를 못 읽는 손님에게도 최소한 새 주소가 어디인지는 글자로 남겨두는 거예요. 어차피 한 번만 걸 거라면, 그 한 번을 두껍게 거는 게 낫다고 봤습니다.

지운 것과 안 지운 것을 반대로 골랐습니다

이사가 끝나면 정리하고 싶어지잖아요. 짐 다 뺐으니까 옛날 집 계약을 해지하는 기분으로요.

그걸 하면 안 됩니다. 옛 주소 프로젝트를 지우면 그 주소는 이제 "없는 페이지"가 돼요. 그러면 그동안 그 주소에 쌓인 검색 평가가 새 주소로 넘어가는 게 아니라 그냥 사라집니다. 이사 표시는 "여기 살던 사람 저기로 갔어요"인데, 지우는 건 "그런 집 없어요"거든요.

그래서 옛 프로젝트 여섯 개는 그대로 남겨뒀습니다. 안에 내용물은 없고 이사 표시만 들어 있는 빈 껍데기로요.

대신 지운 게 따로 있어요. 도구마다 하나씩 갖고 있던 옛날 배포 스크립트들입니다.

그 스크립트들이 왜 위험하냐면, 실수로 한 번 돌리는 순간 그 프로젝트에 내용물이 다시 올라가면서 이사 표시를 덮어버리기 때문이에요. 그러면 옛 주소가 다시 살아나서 새 주소랑 같은 걸 보여주게 됩니다. 이건 앞 편에서 실제로 겪은 일이기도 해요 — 매일 아침 도는 자동화가 그 짓을 하고 있었거든요.

그래서 프로젝트는 남기고 스크립트를 지웠습니다. 정리 본능이 가리키는 방향과 정확히 반대예요. 지금 필요한 배포 명령은 딱 하나뿐입니다.

옮기고 나서 알게 된 것 ① 사이트맵이 전부 똑같아 보였어요

여기서부터가 이 편의 진짜 × 입니다. 순서를 잘 잡아서 이사를 한 번으로 줄였는데도, 그 한 번의 뒤처리에서 계속 뭐가 나왔어요.

합친 다음에 사이트맵을 하나로 모으는 코드를 만들었습니다. 도구마다 자기 사이트맵을 갖고 있었는데, 한 도메인에서는 뿌리에 있는 것만 읽히거든요. /leave/sitemap.xml 은 아무도 안 봅니다. 그래서 도구별 파일은 걷어내고 주소만 모아서 뿌리에 한 벌을 만들었어요.

그런데 처음 만든 버전이 이상했어요. 주소만 뽑아 모으고, 모든 항목에 "이 페이지는 주 단위로 바뀝니다"를 똑같이 붙이고 있었습니다.

형식은 맞아요. 사이트맵 규격에 그런 항목이 있고, 검사도 통과합니다. 그런데 찾아보니 구글은 그 값을 읽지 않아요. 대신 읽는 건 "마지막으로 바뀐 날짜" 쪽입니다.

무슨 뜻이냐면, 300장 넘는 목록을 내밀면서 어느 것도 언제 바뀌었는지 안 알려주고 있었던 거예요. 크롤러 입장에선 전부 똑같아 보입니다. 뭘 먼저 읽을지 고를 수가 없어요.

새 도메인은 안 그래도 크롤러가 조금씩만 읽고 갑니다. 그 적은 몫을 어디에 쓸지 정할 힌트를 제가 지워버린 셈이었어요.

고치고 나서는 이렇게 나갑니다.

<url><loc>https://victor-house.com/bible/</loc><lastmod>2026-08-19</lastmod></url>
<url><loc>https://victor-house.com/cards/</loc><lastmod>2026-08-05</lastmod></url>
<url><loc>https://victor-house.com/equity/</loc><lastmod>2026-08-03</lastmod></url>

그리고 여기 규칙 하나를 더 박아뒀어요. 도구가 날짜를 안 적어 보냈으면 그냥 비웁니다. 지어내지 않아요. 위 화면에서 아래쪽 항목들에 날짜가 없는 게 그거예요. 모르는 걸 그럴듯하게 채우는 게 이 연재에서 계속 나오는 사고 유형이라, 이번엔 코드 쪽에 아예 못을 박았습니다.

오늘 세어보니 사이트맵에 주소가 312개 있고, 그중 285개에 날짜가 붙어 있네요.

옮기고 나서 알게 된 것 ② 배포는 되는데 사이트맵엔 없던 칸

두 번째로 나온 건 더 조용한 거였어요.

도구를 하나씩 칸에 넣다 보니 자기 사이트맵을 안 만드는 도구가 생겼습니다. 화면이 한 장뿐인 도구는 굳이 사이트맵을 만들 이유가 없거든요. 그런데 합치는 코드는 "도구들이 만든 사이트맵을 모으는" 방식이라, 안 만든 도구는 모을 게 없으니까 그냥 빠집니다.

배포는 성공이라고 찍힙니다. 주소를 열면 화면도 잘 뜨고요. 검색엔진한테만 그 칸이 없는 겁니다.

실제로 두 칸이 그렇게 빠져 있었어요. 사이트맵 줄 수랑 실제 칸 수를 맞춰보다 알았습니다. 그래서 그런 칸은 이름을 적어서 따로 넣게 했는데, 여기에 조건을 하나 달았어요. 파일이 실제로 있을 때만 넣습니다.

이유가 있어요. 아직 만들지도 않은 칸을 사이트맵에 적어두면, 검색엔진이 찾아와서 없는 페이지를 만납니다. 그건 빠뜨린 것보다 나빠요. 빠뜨린 건 "아직 모르는 것"인데, 없는 걸 적은 건 "틀린 걸 알려준 것" 이니까요.

옮기고 나서 알게 된 것 ③ 주소 하나에 이사가 한 번 더 숨어 있었어요

세 번째는 이 편의 축이랑 제일 정확하게 맞물리는 건데요.

칸 하나에 설명 페이지를 about.html 이라는 이름으로 뒀어요. 그래서 사이트맵에도 /iem/about.html 이라고 적었습니다. 당연한 거죠, 파일 이름이 그거니까요.

그런데 호스팅이 .html 로 들어온 주소를 .html 없는 주소로 넘겨버립니다. /iem/about.html 로 오면 /iem/about 으로 보내요.

그러니까 사이트맵에 .html 을 적어두면, 크롤러는 이렇게 움직입니다. 사이트맵 읽고 → .html 주소로 감 → "저쪽으로 가세요" 를 받음 → 다시 감. 주소 하나마다 이사가 한 번씩 더 끼는 거예요.

이사를 두 번 안 하려고 순서까지 뒤집어놨는데, 사이트맵 안에서 주소마다 이사가 한 번씩 더 생기고 있었던 겁니다. 그래서 사이트맵에 적는 주소는 실제로 열리는 꼴로 적기로 했어요.

이런 건 배포 기록에도 안 찍히고 화면에도 안 보입니다. 주소를 하나 골라서 응답을 직접 열어봐야 나와요.

그래서 일곱 번째부터는 이사가 아예 없습니다

순서를 이렇게 잡은 게 제일 크게 돌아온 자리가 여기예요.

지금 홈에서 도구 쪽으로 걸린 칸이 열네 개입니다. 그런데 옛 주소를 새 경로로 갈아끼우는 줄은 여전히 여섯 줄뿐이에요. 이사 표시를 걸어둔 옛 프로젝트도 여섯 개 그대로고요.

키보드 스위치 찾기, 핸드폰 보험 계산기, 시장 지표, 이어폰 그래프 읽기, 집값 지도… 이것들은 전부 처음부터 최종 주소에서 태어났어요. 그러니까 옮길 일이 없습니다. 이사 표시도 필요 없고, 소유 확인도 이미 돼 있고, 사이트맵은 원래 있던 목록에 줄이 몇 개 늘어날 뿐이에요.

아홉 칸이 그렇게 들어왔습니다. 만약 순서를 반대로 해서 경로 구조가 나중에 정해졌다면, 이 중 앞쪽 몇 개는 자기도 한 번씩 이사를 했을 거예요.

처음 한 번의 순서가, 그 뒤로 만드는 모든 것의 이사 횟수를 정합니다. 이건 만들 때는 잘 안 보이는 종류의 이득이더라고요.

아직 안 끝난 것

정직하게 적을게요. 이만큼 신경 써서 이사를 한 번으로 줄였는데도, 결과가 빨리 오지는 않았습니다.

맨 앞에 적은 그 화면이 그거예요. 8월 9일 기준으로 네이버가 아는 페이지는 두 장이었습니다. 구글 쪽도 좋지 않았고요 — 7월 말에 사이트맵을 한 번 읽어가고는 한동안 다시 안 왔어요.

그러니까 이 편에서 제가 한 건 "제대로 옮겼다"까지입니다. "옮겨서 잘 됐다"가 아니에요. 이사 표시는 지금도 여섯 개 다 살아 있고, 사이트맵도 뿌리에 한 벌 잘 있고, 주소는 전부 최종 꼴로 적혀 있습니다. 그런데 그게 유입으로 바뀌는 건 다른 문제였어요.

하나 더 있어요. 공짜 주소는 도메인을 붙여도 안 없어집니다. victor-house.pages.dev 는 지금도 열려요. 같은 사이트가 두 주소에 있는 셈이죠. 이건 원본이 어디인지 알려주는 표시로 처리해뒀는데 — 그 표시가 자동으로 붙는 것도, 주소를 설정 파일 한 곳에만 뒀기 때문입니다. 그 한 곳이 .com 을 가리키니까 공짜 주소로 들어가도 자기 입으로 "원본은 저쪽"이라고 말해요.

그리고 지금 사이트맵이 312장인데, 한때 이게 4,760장까지 갔던 적이 있습니다. 그 이야기는 다음 편에서 할게요. 그게 이 시기 제일 큰 사고였거든요.

사람은 어디에 남았나

이번 편은 좀 다른 자리였어요.

앞 편들에서는 AI가 만든 걸 사람이 검사해서 잡아내는 그림이 많았는데, 이번에 사람이 한 건 일의 순서를 정한 것이었습니다. 그리고 이건 검사로는 못 잡는 종류예요.

AI한테 "도메인 사서 연결해줘" 라고 하면 정확하게 그걸 해줍니다. "도구 여섯 개를 새 도메인으로 옮겨줘" 라고 해도 정확하게 해줘요. 둘 다 시킨 대로 잘 됩니다. 근데 그 두 개를 어느 쪽 먼저 할지는 안 물어보면 아무도 안 정해요. 그리고 순서가 틀렸다는 건 몇 주 뒤에, 그것도 아무 오류 없이 조용히 드러납니다.

정리하면 사람이 남은 자리는 네 군데였어요.

하나, 순서. 재미있는 걸 나중에 하기로 정한 것. 도메인은 결제 5분이면 되는데 그걸 뒤로 미룬 게 이 편의 전부입니다.

둘, 칸 이름. /leave/ 냐 /parental/ 이냐는 코드가 못 정해요. 이걸 몇 년 쓸 건지, 나중에 도구를 갈아엎을 건지를 아는 쪽이 정해야 합니다.

셋, 지울 것 고르기. 옛 프로젝트를 남기고 옛 스크립트를 지운 것. 정리 본능이 가리키는 방향과 반대라 자동으로는 절대 안 나오는 선택이에요.

넷, 형식은 맞는데 아무도 안 읽는 값을 알아본 것. 사이트맵에 붙던 그 "주 단위로 바뀝니다" 요. 검사도 통과하고 규격에도 있고 배포도 성공합니다. 틀린 건 읽는 쪽이 그 항목을 안 본다는 사실 하나였어요. 이건 코드를 아무리 들여다봐도 안 나오고, 받는 쪽 문서를 열어봐야 나옵니다.

이 연재를 쓰면서 계속 같은 자리로 돌아오는데요. AI는 "시킨 게 됐는지" 는 정말 잘 봅니다. 못 보는 건 "안 시켰는데 같이 어긋난 것" 하고 "애초에 이 순서가 맞는지" 쪽이에요.

그래서 저는 큰 걸 건드리기 전에 한 번 멈춰서 물어봅니다. 이거 나중에 또 해야 하나? 또 해야 할 것 같으면, 지금 하는 대신 순서를 바꿉니다.

다음 편

여기까지가 도메인 이야기예요. 이름 고르고, 사고, 합치고, 옮기고, 순서 맞추고.

다음 편부터는 그래서 사람이 오느냐 하는 이야기입니다. 그리고 시작이 좋지 않아요.

하루 90번씩 검색 결과에 뜨던 게 0이 됐거든요. 열흘이 지나도 안 돌아왔고요. 한나절 걸려 원인을 찾았는데, 범인은 저였습니다. 하루 만에 사이트맵을 314장에서 4,754장으로 늘렸어요. 좋은 일인 줄 알고 한 거였습니다.

#도메인구매순서 #사이트이사 #301리디렉트 #검색평가이전 #도메인통합 #서브디렉터리구조 #canonical #사이트맵 #lastmod #robotstxt #서치콘솔 #네이버서치어드바이저 #색인등록 #검색엔진최적화 #SEO기초 #CloudflarePages #클라우드플레어 #정적사이트 #무료호스팅 #배포자동화 #설정파일 #원소스관리 #개인홈페이지 #홈페이지만들기 #victorhouse #육아휴직계산기 #카드혜택 #기술사스터디 #AI코딩 #휴먼인더루프