작업 기간: 2026.10.22–10.22
2026년 10월 22일, 이 포트폴리오의 주소를 sunttt.com에서 57loop.com으로 옮겼어요. sunttt.com은 같은 날 선데이나잇 교육 사이트의 주소가 될 예정이었어요. 코드와 배포는 AI가 맡았고, 저는 운영 배포를 승인하고 보안 설정을 맡았어요.
배포를 승인하고 1분도 지나지 않아 문제가 생겼어요. 45초 동안 옛 주소로 들어온 방문자가, 아직 옛 제품 화면이 걸려 있던 57loop.com으로 넘어갔어요. 이 글은 주소를 옮기는 배포에서 무엇을 먼저 켜야 하는지에 대한 기록이에요. 왜 순서가 어긋났는지, 다시 할 때는 무엇을 보고 다음 단계로 넘어갔는지에 답해 보려고 해요.
승인할 때는 DNS가 알아서 바뀐다고 들었어요
바꿀 것은 두 가지였어요. 사이트의 기준 주소를 57loop.com으로 바꾸고, sunttt.com으로 오는 방문자를 같은 경로의 57loop.com으로 넘기는 규칙을 한 파일에 모았어요. 그리고 57loop.com을 이 사이트가 도는 Cloudflare Worker에 연결해야 했어요.
57loop.com은 그때까지 Vercel에 올린 옛 제품 화면을 가리키고 있었어요. AI는 승인 요청에 "배포하면 wrangler(Cloudflare 배포 도구)가 기존 DNS 레코드를 Worker 연결로 바꿔 준다"고 적었어요. 저는 그 설명과 되돌리는 방법을 읽고 "승인, 진행"이라고 답했어요.
저도 AI도 배포 한 번이면 주소 연결과 새 코드가 함께 바뀐다고 생각했어요. 처음 가설은 "배포 한 번에 연결과 코드 교체가 같이 끝난다"였어요. 둘 중 하나만 성공하는 경우는 승인 요청에 없었어요.
Cloudflare는 기존 레코드 두 줄부터 지우라며 연결을 거절했어요
04:48(UTC)에 배포를 시작했어요. 빌드와 테스트 115개, 공개 검사는 모두 통과했어요. 그런데 57loop.com을 연결하는 단계에서 Cloudflare가 거절했어요. 이 주소에 직접 만든 DNS 레코드가 이미 있으니 먼저 지우라는 내용이었고, 오류 번호는 100117이었어요.
지울 레코드는 57loop.com과 www를 옛 화면으로 보내던 A 레코드 두 줄이었어요. 나중에 확인해 보니 wrangler는 화면 없는 실행에서 기존 DNS를 덮어쓰는 설정을 켜요. 하지만 Cloudflare는 사람이 직접 만든 레코드가 있는 주소는 받아 주지 않았어요.
검사를 모두 통과했는데 왜 몰랐을까 다시 봤어요. 빌드와 테스트는 이 저장소 안의 코드만 봐요. 57loop.com에 어떤 DNS 레코드가 남아 있는지는 Cloudflare 계정의 상태라서, 배포하는 순간에야 드러났어요.
거절당하는 사이 넘기는 코드는 이미 켜져 있었어요
더 큰 문제는 순서였어요. wrangler는 주소 연결이 실패해도 새 코드를 먼저 켰어요. 새 코드에는 sunttt.com 방문자를 57loop.com으로 넘기는 규칙이 들어 있었어요.
그래서 04:48:05부터 04:48:50까지 45초 동안, sunttt.com으로 온 방문자가 57loop.com으로 넘어갔어요. 그 57loop.com은 아직 옛 제품 화면이었어요. 포트폴리오를 보러 왔는데 전혀 다른 화면을 본 셈이에요.
AI는 이 상황을 보자마자 직전 버전으로 되돌렸어요. 새 버전은 올려만 두고 켜지 않았고, sunttt.com이 다시 정상으로 열리는 것을 확인했어요. 그리고 보고 첫머리에 "승인받을 때 드린 설명이 틀렸습니다"라고 적었어요.
DNS 두 줄은 사람에게 넘기는 대신 AI가 지웠어요
AI의 첫 제안은 제가 DNS 두 줄을 지워 달라는 것이었어요. AI가 쓰는 Cloudflare 로그인 권한에는 DNS 수정이 없었기 때문이에요. 지울 위치와 값을 한 줄씩 적어 보냈어요.
저는 "권한 줄테니까 니가해 지난번엔 니가 했어"라고 답했어요. 제가 화면을 찾아 지우는 동안에도 사이트는 반쯤 바뀐 상태로 남아 있어요. AI는 제 Chrome에서 Cloudflare 화면을 열어 두 줄을 지웠어요.
버린 선택지는 "사람에게 넘기고 기다리기"였어요. 기다리는 시간이 그대로 어중간한 상태로 남는다는 점이 이유였어요. 권한을 넘기는 결정은 제가 했고, 지운 것은 AI였어요.
주소부터 붙이고 열리는 걸 본 다음에 코드를 켰어요
두 번째에는 순서를 뒤집었어요. 켜져 있던 옛 코드는 그대로 두고, 주소만 붙이는 명령(wrangler triggers deploy)으로 연결부터 했어요. 이 단계에서는 sunttt.com이 아무 데도 넘어가지 않아요.
다음으로 57loop.com이 인증서까지 정상으로 열리는지 확인했어요. 그다음에야 올려 두었던 새 버전을 켰어요. 04:53에 주소를 연결하고 04:53:18에 새 코드를 켰고, 그 뒤로는 끊김이 없었어요.
확인도 주소 단위로 했어요. 새 주소의 페이지 11개가 정상으로 열렸고, 옛 주소 7가지가 경로와 쿼리를 그대로 가진 채 57loop.com으로 넘어갔어요. 이 순서는 배포 기록에 교훈으로 남겼어요.
마지막으로 Vercel에 있던 옛 제품 프로젝트는 지우지 않고 57loop.com 주소만 떼어 냈어요. 프로젝트는 Vercel이 준 원래 주소로 계속 열려요. 되돌려야 하면 주소를 다시 붙이고 DNS 두 줄을 되살리면 돼요.
같은 날 오후, 같은 순서를 한 번 더 썼어요
오후에는 2단계로 sunttt.com을 선데이나잇 교육 사이트에 넘겼어요. 두 사이트가 한 주소를 주고받는 일이라, 오전과 같은 질문을 먼저 했어요. 무엇이 먼저 켜지면 주소가 잠깐 비는지였어요.
포트폴리오를 먼저 배포하면 sunttt.com이 포트폴리오에서 떨어지는 순간이 생겨요. 그때는 어느 사이트에도 붙어 있지 않아요. 그래서 교육 사이트를 먼저 배포해 주소를 옮겨 받게 하고, 포트폴리오는 그다음에 sunttt.com을 내려놓게 했어요.
07:34에 교육 사이트, 07:35에 포트폴리오를 배포했고 끊김은 없었어요. 옛 포트폴리오 주소로 오면 교육 사이트가 같은 경로의 57loop.com으로 넘겨요. 오전에 45초를 쓰고 얻은 순서를 오후에 그대로 썼어요.
제가 맡은 칸과 AI가 맡은 칸
제가 한 일은 운영 배포 승인, DNS 권한을 넘기는 결정, 관리 화면 로그인 관문에 새 주소를 더하는 일이었어요. 보안 설정은 사람이 하는 게 맞다는 AI의 제안을 따랐어요. 마지막으로 관리 화면에 직접 로그인해 저장이 되는지도 확인했어요.
AI가 자기 권한으로는 할 수 없다고 넘긴 일은 두 가지였어요. DNS 삭제는 제가 권한을 넘겨 AI가 했고, 로그인 관문은 보안 설정이라 제가 직접 했어요. 같은 "권한 없음"이어도 누가 할지는 다르게 정했어요.
AI는 코드와 테스트를 바꾸고, 배포하고, 문제를 보자마자 되돌렸어요. 순서를 다시 짜고 주소별 확인과 배포 기록도 맡았어요. 승인 요청의 설명이 틀렸다는 것을 먼저 밝힌 것도 AI였어요.
처음 질문으로 돌아가면
"주소를 옮길 때 무엇을 먼저 켜야 하나?"에 대한 지금 답은 "주소가 열리는 걸 본 다음에 넘기는 코드"예요. 배포 한 번에 여러 일이 함께 바뀌면, 그중 하나가 실패해도 나머지는 먼저 켜질 수 있어요.
주소를 옮기는 배포에서는 새 주소가 인증서까지 열리는 것을 본 다음에 넘기는 코드를 켜요.