[연재] 왜 하이픈 .com 이었나 — 후보를 고르는 기준
이름을 바꾸고 닷새 동안, 네이버는 제 사이트가 있는 줄도 몰랐습니다
7월 23일 오전에 도메인을 붙였어요. 화면은 멀쩡했고, 검색엔진한테 알려주는 파일들도 전부 새 주소로 다시 만들어졌습니다. 저는 그걸로 이사가 끝났다고 생각했어요.
닷새 뒤인 7월 28일에야 알았습니다. 네이버 쪽에는 victor-house.com 이라는 사이트가 등록조차 안 돼 있었어요.

이유가 좀 허무한데요. 페이지마다 "이 사이트 주인이 나 맞다"고 증명하는 짧은 코드가 한 줄 박혀 있습니다. 그런데 그 코드가 옛 주소(victor-simpson.pages.dev) 때 받은 것 그대로였어요. 네이버는 이 코드를 사이트별로 따로 내주기 때문에, 옛 코드로는 새 주소를 인증하지 못합니다. 구글은 그래도 알아서 긁어가는데 네이버는 등록을 안 하면 사실상 안 옵니다.
주소 한 줄만 바꾸면 canonical도 sitemap도 전부 따라온다고 지난 편에서 자랑했는데, 따라오지 않는 줄이 있었던 거예요. 오류도 안 났고 화면도 멀쩡해서 눈에 띌 구석이 없었습니다. 그래서 같은 실수를 또 하지 않으려고, 주소를 정하는 그 줄 바로 옆에 경고를 적어뒀어요.

이번 편은 이름 이야기입니다. 그런데 저는 이 사고부터 꺼내고 싶었어요. 이름을 고른다는 건 예쁜 걸 고르는 게 아니라, 바꿨을 때 뭐가 따라오고 뭐가 안 따라오는지를 감당하는 일이더라고요.
결론부터 — victor-house.com, 하이픈 들어간 .com 입니다

보시면 아시겠지만 특별할 게 없는 이름이에요. 짧지도 않고, 하이픈도 하나 끼어 있고, 무슨 서비스인지도 안 드러납니다. 그런데 이건 여러 후보를 놓고 취향으로 고른 게 아니라 조건을 하나씩 지우고 남은 것이었어요.
이 편은 그래서 고른 이름보다 접은 후보 이야기가 더 깁니다. 무엇을 왜 포기했는지가 다음 사람한테는 더 쓸모 있을 것 같아서요.
이름은 산 날 정한 게 아니라, 전날 밤에 이미 정해져 있었습니다
먼저 시간 순서를 보실게요. 홈페이지를 짓기 시작한 게 7월 22일 저녁입니다. 그날 밤 기록이 이렇게 남아 있어요.

19시 53분에 초안을 올리고, 20시 31분에 익명 댓글을 붙이고, 21시 54분에 네이버 글 287편을 통째로 끌어오고, 22시 1분에 첫 화면 큰 글씨가 Victor House 로 바뀝니다. 도메인을 결제한 건 다음 날 오전 10시 28분이고요.
그러니까 저는 도메인을 고른 게 아니에요. 이미 정해져 있던 이름에 맞는 주소를 산 겁니다. 순서가 이렇게 되니까 고민의 성격 자체가 달라집니다. "무슨 이름이 멋있을까"가 아니라 "이 이름을 주소로 만들 때 뭐가 걸리나"가 되거든요.
접은 후보 ① 제 이름 석 자
첫 커밋을 열어보면 사이트 이름 자리에 제 실명이 그대로 박혀 있습니다. (여기서는 가려서 찍었어요.)

그 아래 한 줄 소개는 "공개돼 있지만 읽기 어려운 것들을 한 화면에서 판단할 수 있게 정리합니다" 였고요. 문장은 정확해요. 실제로 그런 사이트를 만들고 있었으니까요. 그런데 이건 설명문이지 이름이 아닙니다.
실명을 접은 이유는 두 가지예요.
하나, 개인 이름은 검색되지 않습니다. 회사나 서비스라면 이름 자체를 검색해서 들어오는 사람이 있지만, 저는 그럴 게 없어요. 지금 첫 화면만 봐도 최근 글 조회수가 1, 3, 4 이런 식입니다. 이름을 기억해서 찾아오는 손님이 아니라 검색으로 우연히 들어오는 손님을 받아야 하는 사이트라는 뜻이에요.
둘, 실명은 나중에 뭘 더 얹기가 애매합니다. 지금 이 사이트에는 육아휴직 계산기도 있고 성경 지도도 있고 기술사 문제 히트맵도 있어요. 이런 게 한 사람 이름 아래 있으면 "이 사람 포트폴리오"가 되는데, 저는 포트폴리오가 아니라 도구 창고를 만들고 있었거든요.
접은 후보 ② 제 필명 — victor-simpson
여기가 재밌는 대목이에요. 위 화면에 무료 주소가 victor-simpson.pages.dev 로 적혀 있죠. 이 simpson 이 어디서 왔냐면, 제 네이버 블로그 필명입니다.

블로그를 열어보면 위쪽 큰 글씨가 Victor House, 프로필 이름이 Victor Simpson 이에요. 2024년 2월부터 쓴 글이 290개 쌓여 있고요. 즉 저한테는 이미 두 개의 이름이 있었던 겁니다. 하나는 집 이름, 하나는 사는 사람 이름.
처음 사이트를 올릴 때는 아무 생각 없이 사람 이름 쪽을 주소로 썼어요. 그런데 도메인을 사려고 보니 이게 걸리더라고요.
- 사람 이름은 지붕이 아닙니다.
victor-simpson.com/leave/라고 하면 "빅터 심슨이라는 사람의 육아휴직 계산기"가 되는데, 저는 계산기를 제 이름으로 팔 생각이 없었어요. - 그리고 블로그 독자들이 2년 동안 봐온 이름은 집 이름 쪽입니다. 새로 만드는 사이트가 그 이름을 안 쓰면, 있는 인지도마저 두 갈래로 쪼개지는 거예요.
그래서 사람 이름은 접고 집 이름으로 갔습니다. 22시 1분 커밋이 그 결정이에요.
접은 후보 ③ 도구 이름으로 짓기
세 번째 후보가 제일 위험했어요. 사이트를 만들기 전에 도구를 먼저 여러 개 만들었거든요. 그것들이 각자 주소를 이미 갖고 있었습니다.

parental-pay(육아휴직), card-wallet(카드), equity-holdings(지분), bible-map(성경), sigong-study(기술사). 이름만 봐도 뭘 하는지 알겠죠? 검색 관점에서는 이게 좋은 이름이에요. 주소에 키워드가 들어 있으니까요.
그런데 이 중 하나를 대표 주소로 골랐다고 생각해보세요. 육아휴직 계산기 주소 아래에 성경 지도가 들어가고 카드 비교가 들어갑니다. 도구를 하나 더 만들 때마다 이름이 점점 거짓말이 되는 거예요.
배포 목록에도 그 이름들이 아직 화석처럼 남아 있습니다.

그리고 접었다고 주소를 버릴 수는 없어요. 지금도 옛 주소 여섯 개는 살아서 새 경로로 넘겨줍니다. 방금 하나씩 눌러봤어요.

여섯 개 전부 301, 즉 "영구히 이사했다"로 응답합니다. 이 이야기는 두 편 뒤에 따로 하겠지만, 여기서 한 가지는 미리 말씀드릴게요. 이름을 바꾸는 값에는 옛 이름을 계속 살려두는 비용도 포함됩니다. 접은 후보가 공짜로 사라지지 않아요.
하이픈은 취향이 아니라, 이미 살고 있던 주소였습니다
이제 하이픈 이야기입니다. victorhouse.com 처럼 붙여 쓰는 게 더 깔끔해 보이는데 왜 굳이 하이픈을 넣었냐고요.

설정 파일 가운데 줄을 보시면 이렇게 적혀 있어요. "Cloudflare Pages 프로젝트 이름(주소의 앞부분과 같아야 한다)". 사이트를 올려두는 곳에서 프로젝트 이름을 victor-house 로 지으면 공짜 주소가 victor-house.pages.dev 로 나옵니다. 이건 제가 고른 게 아니라 규칙이에요.
즉 도메인을 사기 전부터 제 사이트는 하이픈이 들어간 주소에 살고 있었습니다. 여기에 붙여 쓴 도메인을 얹으면 이렇게 됩니다.
| 어디 | 주소 |
|---|---|
| 실제로 사는 곳 | victor-house.pages.dev |
| 문패로 걸 이름 | victorhouse.com |
글자가 다르죠. 이게 왜 문제냐면, 이 사이트에는 두 주소를 이어 붙이는 자리가 열 군데 넘게 있거든요. 옛 주소를 새 주소로 갈아끼우는 줄, 301을 거는 줄, 검색엔진에 "원본은 여기"라고 알려주는 줄, 인증 코드… 그때마다 사람이 머릿속에서 "하이픈 있는 쪽 → 하이픈 없는 쪽"을 한 번씩 변환해야 합니다.
그리고 그 변환을 한 번 놓쳐서 이 글 맨 위의 사고가 났어요. 하이픈이 사고를 막아줬다는 얘기는 아니에요. 다만 굳이 글자가 다른 이름을 하나 더 만들 이유가 저한테는 없었습니다.
덤으로 하이픈에는 이런 것도 있어요. victorhouse 는 눈으로 한 번 끊어 읽어야 하는데 victor-house 는 두 단어인 게 그냥 보입니다. 사람한테도 검색엔진한테도요.
여기서 솔직히 비워두는 부분이 있습니다. 붙여 쓴 .com 이 그때 비어 있었는지 아닌지, 제가 확인해본 기록이 안 남아 있어요. "짧고 발음되는 무하이픈 .com 은 거의 다 팔렸다"는 말은 흔히들 하지만, 제가 직접 조회해서 확인한 화면이 없으니 그렇다고 단정하지 않겠습니다. 확실한 건 하나예요 — 제가 고른 이름은 이미 살고 있던 주소를 그대로 문패로 옮긴 것이었습니다.
.io 나 .dev 는 왜 안 봤나
이건 기준만 말씀드릴게요. 값 비교표는 없습니다(지난 편에도 적었지만 저는 견적을 받아보고 산 게 아니에요).
첫째, 오타입니다. 사람들은 주소 끝을 .com 으로 칩니다. 습관이에요. .io 로 사면 그렇게 잘못 친 사람이 어디로 가느냐면, 그 .com 을 갖고 있는 남의 사이트로 갑니다. 그 사람들을 다시 데려오려면 .com 도 같이 사야 하는데 그러면 두 벌 값이 나가요.
둘째, 갱신 값입니다. 도메인은 매년 내는 거라 진짜 값은 두 번째 해부터예요. .com 은 도매값이 정해져 있어서 바닥이 비슷한데, 다른 확장자는 그 바닥이 어디인지를 제가 모릅니다. 모르는 값을 매년 내는 건 개인 사이트한테 부담이에요.
셋째, 저는 브랜드가 없습니다. .io 나 .dev 는 "우리 이름을 알고 찾아오는 사람"이 있을 때 멋이 됩니다. 저는 그런 게 없어요. 검색으로 처음 들어온 사람이 주소를 보고 "이게 뭐지" 하지 않는 것, 그게 제 조건이었습니다.
정리하면 확장자는 개성이 아니라 오타 안 나는 쪽으로 골랐어요.
이름을 바꿔도 따라오지 않는 것들
맨 위 사고로 돌아갈게요. 왜 어떤 건 따라오고 어떤 건 안 따라왔을까요. 코드를 나란히 놓고 보면 한눈에 보입니다.

위쪽 줄들은 {BASE_URL} 이라는 값을 빌려 쓰고 있죠. 그러니까 그 값 하나만 바꾸면 전부 새 주소가 됩니다. 그런데 노란색으로 칠한 두 줄은 글자가 그대로 박혀 있어요. 구글·네이버가 사이트별로 내주는 인증 코드라서 빌려 쓸 값이 없거든요.
이름을 바꿀 때 손으로 챙겨야 하는 건 제 경험상 이 세 가지였습니다.
1. 검색엔진 인증 코드 — 새 주소로 다시 받아서 갈아끼워야 합니다. 안 하면 등록 자체가 안 됩니다. 2. 검색엔진에 주소 변경 신고 — 옛 주소에 쌓인 평가를 새 쪽으로 넘겨달라고 알려야 해요. 3. 옛 주소 301 — 이건 지우면 안 됩니다. 두 편 뒤에 자세히 씁니다.
셋 다 화면에는 안 보여요. 안 해도 사이트는 멀쩡히 열립니다. 그래서 위험합니다.
잘 고른 이름인지는 한 달 뒤에 알게 됩니다
이름을 고를 때 제가 세운 마지막 조건이 "여섯 개를 한 지붕에 넣을 수 있느냐"였어요. 그 조건이 맞았는지는 시간이 지나야 알 수 있죠. 지금 배포 스크립트 첫머리를 열어보면 이렇습니다.

여섯 개로 시작한 칸이 열세 개가 됐어요. 키보드 스위치, 이어폰, 시장 지표, 핸드폰 보험, 마블 인물 매트릭스, 집 찾기, 목소리 유형… 전부 나중에 만든 것들입니다. 실제로 열리는지도 한 줄씩 확인해봤어요.

열다섯 칸 전부 200, 정상입니다.

기술사 시험 히트맵도 이 지붕 아래 한 칸이에요. 우측 위 집 모양 버튼을 누르면 본진으로 돌아갑니다.
여기서 중요한 건 이걸 넣으면서 주소를 한 번도 안 바꿨다는 거예요. 이름이 victor-house, 그러니까 "빅터네 집"이라서 뭘 넣어도 어색하지가 않거든요. 만약 이름에 도구 하나를 박아뒀다면 새 도구를 만들 때마다 "이건 이 사이트 이름에 안 맞는데" 하고 걸렸을 겁니다.
좋은 이름은 뜻이 많은 이름이 아니라 뜻이 적은 이름이더라고요. 빈 그릇이어야 뭘 담습니다.
AI는 여기서 뭘 하고 뭘 못했나
구조는 AI가 만들었어요. 주소를 한 곳에만 적어두는 것, 배포 직전에 옛 주소를 갈아끼우는 것, 옛 프로젝트에 301만 남기는 것 — 전부 AI가 짠 겁니다. 저 혼자였으면 도구 여섯 개를 하나씩 열어 주소를 고치고 있었을 거예요.
대신 이름 자체는 AI가 못 골랐습니다. 첫 커밋을 보면 사이트 이름 자리에 제 실명이 들어가 있고, 한 줄 소개 자리에는 40자짜리 설명문이 들어가 있어요. 둘 다 틀린 답은 아닙니다. 이 사이트가 무엇을 하는 곳인지 정확히 적었어요. 다만 "이 이름을 2년 전부터 290편 동안 누가 뭐라고 부르고 있었는지"는 코드 어디에도 안 적혀 있습니다. 그건 블로그를 운영해온 사람 머릿속에만 있어요.
그리고 맨 위의 인증 태그요. 주소를 바꾼 뒤 canonical도 sitemap도 og도 전부 새 주소로 따라오는 걸 확인했고, 그건 실제로 맞았습니다. 실패한 게 없었어요. 안 따라온 두 줄은 화면에 안 보이고 오류도 안 내니까 확인할 대상에 아예 안 들어간 거예요.
이 연재를 쓰면서 매번 같은 결론에 도달하는데요. AI는 "시킨 것이 됐는가"는 아주 잘 봅니다. 못 보는 건 "시키지 않았는데 같이 깨진 것" 쪽이에요. 그리고 이름처럼 코드 밖의 사정이 결정하는 문제는, 그 사정을 겪은 사람이 답을 갖고 있습니다.
다음 편
다음 편은 흩어져 있던 사이트 여섯 개를 어떻게 한 도메인 아래로 모았는지입니다. 이번 편이 문패 이야기였다면 다음 편은 이삿짐 이야기예요.
#도메인이름짓기 #도메인선택 #하이픈도메인 #닷컴도메인 #victorhouse #개인홈페이지 #홈페이지만들기 #네이밍 #브랜드네이밍 #클라우드플레어 #CloudflarePages #커스텀도메인 #네이버서치어드바이저 #사이트인증 #구글서치콘솔 #301리디렉트 #canonical #sitemap #검색엔진최적화 #SEO기초 #정적사이트 #무료호스팅 #사이드프로젝트 #AI코딩 #클로드 #바이브코딩 #개발자아닌사람 #1인개발 #네이버블로그 #휴먼인더루프