인터넷 주소로 접속할 수 있게 사이트 올리기

배포할 프로젝트와 계정을 확인합니다

VS Code에서 이번 예제 폴더를 열고 터미널 경로를 확인합니다. 같은 이름으로 여러 번 압축을 풀었다면 마지막으로 수정한 폴더가 맞는지 봅니다. 화면에 보이는 파일과 명령을 실행하는 폴더가 다르면 배포 성공 후에도 예전 이름이 나올 수 있습니다. wrangler.jsonc 의 name은 Worker 이름입니다. 예제의 small-home-learning-site를 사용할 수 있지만 이미 같은 이름의 다른 프로젝트가 있다면 구분되는 이름을 정합니다.

이름을 바꿀 때는 이번 Worker가 새 프로젝트인지 기존 운영 사이트인지 먼저 확인합니다. 기존 Worker 이름으로 배포하면 해당 프로그램이 바뀔 수 있기 때문입니다. 처음 실습할 때는 사용 중인 업무 사이트와 분리한 이름을 선택합니다. Cloudflare 계정에 여러 프로젝트가 보인다면 이름과 용도를 간단히 기록해 두세요. 저장 공간도 이번 learning-site-db를 가리키는지 함께 확인합니다.

앞 회차에서 로그인했더라도 현재 CLI가 어느 계정을 사용하는지 확인할 수 있습니다. npx wrangler whoami 로 계정 상태를 보고, 필요한 경우 로그인 절차를 다시 진행합니다. 계정 목록을 화면 캡처로 외부에 올릴 필요는 없습니다. 배포 권한이 부족한 계정이라면 해당 계정의 허용 범위를 확인하고 진행합니다. 권한 오류를 사이트 본문 코드 수정으로 해결하려 하지 않습니다.

배포 결과에서 URL과 데이터 연결을 따로 확인합니다

npm run deploy가 성공했다면 출력된 주소를 저장하고 그 주소를 PUBLIC_ORIGIN에 넣어 다시 배포합니다. 첫 배포에서 홈은 열리지만 관리자 403이 나오는 것은 보호 설정이 아직 끝나지 않았을 때의 정상 동작입니다. 홈까지 500이 나오면 로그인 설정보다 D1 바인딩과 원격 schema 적용을 먼저 확인하세요. 오류를 고치려고 LOCAL_DEV를 원격에서 true로 바꾸지 않습니다.

공개 전 설정을 읽고 저장합니다

wrangler.jsonc에서 D1의 database_id가 실제 내 저장 공간 값인지 봅니다. LOCAL_DEV는 false, INDEXABLE도 false로 둡니다. 전자는 로컬 로그인 생략을 원격에서 사용하지 않기 위한 값이고, 후자는 아직 준비 중인 사이트를 검색 대상으로 삼지 않기 위한 값입니다. ADSENSE_ENABLED 역시 false를 유지합니다. 아직 광고 계정 연결이나 승인을 진행하지 않았으므로 가상의 광고 ID를 넣을 필요가 없습니다.

PUBLIC_ORIGIN에는 첫 배포 전이라면 예시 주소가 남아 있을 수 있습니다. 실제 workers.dev 주소가 나오면 그 주소로 바꾸고 한 번 더 배포합니다. ACCESS 관련 값이 아직 비어 있는 상태에서는 관리 요청이 거절됩니다. 이를 피하려고 허용 이메일 검사를 없애지 않습니다. 첫 배포의 목적은 방문자 화면과 연결 설정을 확인하는 것이며, 관리 기능은 도메인과 Access 설정을 맞춘 뒤 사용합니다.

.dev.vars 에는 내 기기의 비밀값이 들어갈 수 있으므로 public 폴더 안으로 옮기지 않습니다. 예제에서 공개 파일은 public 아래의 이미지와 관리자 브라우저 파일입니다. 원고 백업 JSON이나 계정 화면 캡처를 이 폴더에 넣으면 정적 파일로 접근될 수 있습니다. 배포 전에는 public 안에 공개해도 되는 파일만 있는지 확인합니다. 코드를 숨기기 위한 이름 변경보다 배포 대상 폴더를 구분하는 것이 먼저입니다.

원격 표를 준비한 뒤 배포합니다

7회차에서 아직 원격 초기 명령을 실행하지 않았다면 npm run db:remote 로 표를 준비합니다. 이미 실행했다면 같은 D1을 사용하고 있는지 확인합니다. 이 명령의 성공과 사이트 배포의 성공은 별개입니다. 데이터 표가 준비되지 않은 상태에서 코드만 올라가면 페이지를 요청할 때 저장 공간 오류가 날 수 있습니다. 각 단계가 끝난 뒤 마지막 출력에 실패가 없는지 읽습니다.