블로그를 새 도메인에서 읽게 하려고 9월 27일 nanoplaydays.com을 연결했어요. 그런데 같은 날 확인한 2개 주소 중 기본 주소는 기대한 블로그 화면을 보여주지 않았고, 확인용 문구를 붙인 주소만 열려서 방문자가 쓰는 기본 주소로는 글을 확인할 수 없었어요.

무슨 상황이었냐면요

이 블로그의 페이지는 Firebase Hosting이라는 구글의 웹페이지 호스팅 서비스에서 내보내요. 도메인 연결에는 Cloudflare라는 도메인·DNS 관리 서비스도 쓰고 있었어요. Firebase 관리 화면에는 연결됨이 떴지만, 제가 브라우저에서 기본 주소를 열었을 때 기대한 블로그 화면은 나오지 않았어요. AI가 주소의 응답을 확인한 결과와 제가 본 화면도 달랐어요. 관리 화면의 상태, AI가 받은 응답, 사람 눈에 보인 화면이 서로 다른 세 가지 확인 지점이었던 거예요.

이 블로그는 AI와 함께 만듭니다. 글은 Codex가 쓰고 Claude가 검수하며, 사이트 검사가 걸러 낸 뒤 실행기가 공개해요. 이번 접속 문제는 그 글쓰기 흐름 앞단의 일이었어요. 독자가 들어올 주소가 제대로 열리는지 제가 확인하다가 발견했거든요. AI가 점검했다고 해도 제가 보는 화면과 같다고 넘길 수 없다는 것을 보여 준 작은 사건이에요. 대단한 해결 사례라기보다, 에이전트를 써서 사이트를 운영하다 만난 함정을 복기해 보려는 기록이에요.

먼저 인증서와 프록시를 의심했어요

도메인을 연결한 직후라 HTTPS 인증서 발급이 아직 끝나지 않은 것인지 먼저 생각했어요. HTTPS는 브라우저와 사이트 사이의 연결을 암호화하는 방식이고, 인증서는 그 연결에 쓰여요. Cloudflare 프록시 설정도 찾아봤어요. 프록시는 방문자와 사이트 사이에서 요청을 전달하는 기능이에요. 막 새 주소를 연결했다면 두 곳 모두 살펴볼 만한 후보였어요.

하지만 기록에는 인증서 발급 대기나 프록시가 원인이었다는 확인이 없어요. 두 설정을 바꾸자 화면이 달라졌다는 전후 기록도 없어요. 처음 떠올린 가설을 원인으로 옮겨 적으면, 나중에 같은 문제를 겪는 사람이 잘못된 설정부터 바꿀 수 있겠죠. 당시 확인된 것은 관리 화면의 연결됨 표시와 실제 접속 결과가 달랐다는 사실뿐이에요.

물음표를 붙이자 다른 결과가 나왔어요

9월 27일 제가 기본 주소 nanoplaydays.com/을 열었을 때는 기대한 화면이 보이지 않았어요. 그런데 nanoplaydays.com/?check=20260927은 열렸어요. 물음표 뒤의 check=20260927은 주소에 붙인 확인용 문구예요. 사이트의 새 페이지나 별도 도메인을 뜻하지 않아요. 제가 본 차이를 AI에게 전한 실제 말은 이랬어요.

“나도 nanoplaydays.com/?check=20260927 이건 열려.. nanoplaydays.com/ 이게 안열려서 그렇치 ㅋㅋㅋㅋㅋㅋ”

이 대화는 같은 날 기본 주소와 확인용 문구를 붙인 주소가 다르게 보였다는 직접 관찰을 남겨요. 흐름으로 적으면 도메인 연결 → 관리 화면의 ‘연결됨’ → 기본 주소에서 기대한 화면이 안 보임 → 확인용 문구를 붙인 주소는 열림이에요. 두 주소가 다르다는 사실은 분명하지만, 왜 달라졌는지는 이 흐름만으로 알 수 없어요.

두 주소를 따로 적는 것이 중요했어요. nanoplaydays.com/과 nanoplaydays.com/?check=20260927은 같은 도메인으로 가지만 요청하는 주소 문자열이 달라요. 접속 결과를 “사이트가 안 열린다”라고만 적었다면, 기본 주소에서 일어난 일인지 확인용 문구를 붙인 주소에서 일어난 일인지 나중에는 구분하기 힘들었을 거예요. 실제 대화 한 줄에 두 주소가 모두 남아 있어서, 적어도 그날 비교한 대상은 되짚을 수 있어요.

당시 AI가 받은 응답과 제가 브라우저에서 본 화면이 달랐다는 점도 따로 남겨야 했어요. AI의 점검은 요청에 대한 응답을 확인하는 과정이고, 제 확인은 브라우저에 실제로 표시된 화면을 보는 과정이었어요. 관측 방법이 다르면 결과가 어긋날 수 있어요. 어느 한쪽이 틀렸다고 정하기 전에 무엇을 어떻게 봤는지부터 나란히 놓는 게 순서였어요.

이번 사건에서 진범에 해당하는 설정 한 줄이나 코드 한 줄은 찾지 못했어요. 그 한 줄을 지목하는 변경 기록도 없어요. 확인용 문구가 결과를 바꾸는 계기가 되었을 수는 있지만, 문구 자체가 고장 원인이나 해결책이었다고 증명되지는 않았어요. 그래서 여기에는 원인 코드 대신 당시 비교한 주소 두 줄을 그대로 남겨요.

nanoplaydays.com/
nanoplaydays.com/?check=20260927

둘째 줄의 물음표 뒤 문구는 점검할 때 두 요청을 구별해 줬어요. 첫째 줄에서 기대한 화면이 보이지 않았다는 사실과 둘째 줄이 열렸다는 사실을 각각 적을 수 있었죠. 어느 설정이 이 차이를 만들었는지는 여전히 알 수 없어요.

커밋 두 개와 다음 날의 200

9월 28일 08:15에 남긴 커밋 0df7d5c의 메시지는 도메인 물음표 접속 사건을 에피소드로 발행이에요. 두 주소의 차이를 원고로 남긴 변경이라는 뜻이에요. 08:17의 e4c6ccb는 물음표 접속 에피소드 발행 근거와 시각 기록이에요. 글을 공개했다고 확인한 근거를 기록에 보탠 변경이에요. 두 커밋 모두 접속 장애를 고친 코드 변경은 아니에요.

성과 기록에는 이 글이 9월 28일 08:16 공개 확인으로 적혀 있어요. 08:15는 원고 커밋 시각, 08:16은 공개 확인 시각, 08:17은 근거 기록 시각이에요. 숫자 세 개가 가리키는 일이 각각 다르죠. 이 시간을 접속 문제가 사라진 시각으로 읽을 수는 없어요.

원고를 발행한 이력은 사건을 설명하는 글의 이력이고, 접속 문제의 원인을 찾은 이력은 아니에요. 같은 시간대의 커밋이라는 이유만으로 “이 변경이 사이트를 고쳤다”고 연결하면 사건의 순서가 뒤집혀요. 실제로 남은 커밋 메시지에는 주소 연결 설정을 고쳤다는 내용이 없어요. 공개 확인 시각도 독자가 글을 볼 수 있게 됐음을 기록한 시간이지, 전날의 두 주소가 언제부터 똑같이 보였는지 측정한 시간은 아니에요.

9월 28일에는 기본 주소도 HTTPS 200으로 열리는 것을 확인했어요. 200은 서버가 해당 요청에 정상 응답했다는 코드예요. 전날의 두 주소가 왜 다르게 보였는지를 밝혀 주는 코드는 아니에요. 브라우저에 남아 있던 응답이나 연결 상태가 영향을 줬을 가능성을 생각할 수는 있어요. 다만 당시의 화면·응답을 더 자세히 기록하지 않아 어느 설명이 맞는지 판별하지 못해요.

‘연결됨’과 ‘보인다’는 서로 다른 확인이에요

관리 화면의 연결됨은 서비스가 도메인을 연결된 상태로 표시한다는 뜻이에요. 방문자가 정확히 어떤 주소를 열어 어떤 화면을 받는지는 별도로 봐야 해요. 서버의 200 응답도 그 요청이 정상 처리됐다는 뜻이지, 방문자가 기대한 내용이 보였다는 증거까지 되지는 않아요. 이번에는 관리 상태, 요청의 응답, 사람의 화면을 한데 묶어 판단하면서 차이를 놓치기 쉬웠어요.

AI가 확인한 결과가 있어도 사람이 겪은 접속 문제는 그대로 기록할 가치가 있어요. 반대로 한 사람의 브라우저에서 보인 차이만으로 서버 전체의 원인을 확정할 수도 없어요. 같은 주소인지, 언제 열었는지, 어떤 환경에서 봤는지까지 묶어야 두 관찰을 비교할 수 있어요. 다음에 같은 문제가 생기면 그 묶음이 원인을 좁히는 출발점이 돼요.

예를 들어 기본 주소의 화면을 봤다면 그때의 주소를 그대로 적고, 확인용 문구를 붙여 다시 봤다면 두 번째 주소도 그대로 남겨요. 어느 브라우저와 기기를 썼는지도 함께 적어요. 화면이 달랐다면 보인 문구나 화면 자체를 기록하고, 응답 코드를 봤다면 그 값과 확인 시각을 적어요. 이렇게 해야 “다음 날에는 됐다”는 기억보다 더 구체적으로 전후를 비교할 수 있어요. 이번에는 두 주소의 차이는 남았지만 그만큼 자세한 환경 기록은 남지 않아 원인을 더 좁히기 어려웠어요.

그래서 하지 말아야 할 것

첫째, 관리 화면의 연결됨만 보고 방문자 화면까지 정상이라고 결론 내리지 않으려고 해요. 실제로 열어 본 주소와 화면을 따로 적으면 두 확인 결과의 차이가 보여요.

관리 화면은 연결 절차를 살필 때 여전히 유용해요. 다만 제가 풀려던 질문은 “도메인이 연결됐나”에서 “독자가 기본 주소로 들어오면 글을 볼 수 있나”로 옮겨 갔어요. 질문이 바뀌면 확인할 대상도 관리 화면에서 실제 주소와 화면으로 옮겨야 해요. 그 구분이 없으면 연결됨 표시를 보고 접속 문제를 이미 해결한 것으로 착각할 수 있어요.

둘째, 확인용 문구를 붙인 주소가 열렸다고 그 문구를 해결책으로 삼지 않으려고 해요. 기본 주소와 문구를 붙인 주소를 각각 열고, 어느 쪽에서 무엇이 보였는지 남겨야 해요.

이번 대화에서 물음표 뒤 문구는 두 결과를 비교하게 해 준 표시였어요. 기본 주소가 다시 열렸을 때도 그 문구를 계속 붙여야만 되는지 시험한 기록은 없어요. 문구가 왜 차이를 만들었는지도 확인되지 않았어요. 그래서 독자에게 같은 문구를 붙이면 고쳐진다고 안내할 근거가 없어요. 재현할 때는 문구 자체보다 두 요청의 차이와 각 결과를 빠짐없이 남기는 데 쓰는 게 맞아요.

셋째, 인증서나 프록시처럼 그럴듯한 후보를 확인된 원인으로 기록하지 않으려고 해요. 설정을 바꾸기 전에 정확한 주소·시각·브라우저와 기기·화면 또는 응답을 함께 적어 두면, 바뀐 뒤 결과와 나란히 볼 수 있어요. 같은 상황을 다시 만난다면 아래 명령으로 두 주소의 응답 코드와 확인 시각을 각각 남겨 볼 거예요.

Get-Date -Format o
curl.exe -I "https://nanoplaydays.com/"
curl.exe -I "https://nanoplaydays.com/?check=20260927"

이 명령은 서버 응답을 비교하는 다음 점검 방법이에요. 9월 27일에 이 명령을 실행했다는 기록은 없어요. 브라우저에 실제로 보인 화면도 명령 결과와 함께 따로 남겨야, 제가 겪은 차이를 다시 비교할 수 있어요.

마치며

도메인 연결 상태와 방문자가 본 화면은 각자 확인하고 기록해야 해요. 여러분도 관리 화면은 정상인데 실제 주소에서는 다른 화면을 본 적 있으세요? 그때 어떤 주소와 시각을 남기셨나요?