← Day 1 장표

Day 4 · 배포 실행 안내서

GitHub에서
Vercel까지

Day 1에 만든 비공개 GitHub 저장소를 사용합니다. 기능과 의도를 확인한 최종 커밋만 올리고, Vercel에서 공개 주소가 같은 결과를 보여 주는지 검사합니다.

GitHub Desktop · Vercel 환경 변수 · 공개 주소 · 대체 화면 공식 문서 확인 · 2026-07-22

시작 전에 네 곳을 엽니다

  1. Codex 앱 — 마지막 변경과 실행 결과를 확인합니다.
  2. GitHub Desktop — 커밋과 업로드 상태를 확인합니다.
  3. 브라우저 — GitHub와 Vercel 대시보드를 엽니다.
  4. 다른 브라우저 또는 휴대전화 — 로그인 정보에 기대지 않고 공개 주소를 검사합니다.
오늘은 기능을 늘리지 않습니다

시연을 막는 오류만 고칩니다.

새 아이디어는 별도 목록에 적고 배포 뒤로 미룹니다.

0 / 7

배포 순서

각 단계의 통과 문장을 확인한 뒤 다음으로 갑니다. 실패하면 같은 배포 버튼을 반복해서 누르지 말고, 어느 단계에서 멈췄는지 먼저 확인합니다.

배포할 상태를 먼저 확인합니다

로컬에서 작동하지 않는 결과는 배포해도 고쳐지지 않습니다.

이 프로젝트를 배포하기 전 상태만 점검해 줘. 파일은 아직 바꾸지 마. 1. 현재 Git 저장소와 브랜치 2. 아직 커밋하지 않은 변경 3. 마지막 커밋 4. 프로젝트의 공식 실행·검사·빌드 명령 5. 서비스 설계서의 핵심 흐름을 로컬에서 확인하는 순서 6. .env, API 키, 개인정보와 공개 권한이 없는 원본 파일이 Git에 포함됐는지 를 확인해 표로 보여 줘. 검사 명령을 실행하기 전에는 무엇을 확인하는지 설명하고 내 승인을 기다려.
  1. Codex가 현재 프로젝트 폴더를 가리키는지 확인합니다.
  2. 실행·검사·빌드 명령을 승인하고 결과를 읽습니다.
  3. 내 노트북에서 핵심 흐름을 처음부터 끝까지 한 번 직접 실행합니다.

최종 변경을 커밋하고 GitHub에 올립니다

무엇을 올리는지 확인한 뒤 마지막 커밋을 게시합니다.

배포할 마지막 변경을 검토해 줘. 서비스 설계서와 다른 부분, 실행을 막을 위험, 비밀정보와 공개 권한이 없는 파일이 있는지 확인해. 내가 변경 내용을 확인하고 승인하면 이번에 검토한 파일만 커밋해. 원격 저장소에는 아직 올리지 말고 마지막 커밋과 남은 변경을 보여 줘.
  1. GitHub Desktop의 Changes와 History에서 마지막 커밋을 확인합니다.
  2. Push origin을 한 번 선택합니다.
  3. View on GitHub에서 마지막 커밋 설명과 시간이 같은지 확인합니다.
저장소는 비공개여도 됩니다 Vercel 연결 때문에 코드를 공개 저장소로 바꿀 필요는 없습니다.

Vercel에 GitHub 저장소를 연결합니다

Day 1에 만든 저장소를 새 Vercel 프로젝트로 가져옵니다.

  1. Vercel 새 프로젝트 화면을 엽니다.
  2. GitHub 저장소 목록이 보이지 않으면 같은 GitHub 계정인지 확인하고, 요청된 저장소 접근 권한을 학생이 직접 승인합니다.
  3. my-small-service에 해당하는 저장소의 Import를 선택합니다.
  4. 다른 학생의 저장소나 예제 저장소를 선택하지 않았는지 이름과 소유자를 다시 확인합니다.
저장소가 보이지 않으면 저장소를 공개로 바꾸지 않습니다. Vercel의 GitHub 접근 범위와 현재 로그인 계정을 먼저 확인합니다.

빌드 설정과 환경 변수를 확인합니다

자동 감지 결과를 읽고 필요한 비밀 값은 Vercel에 직접 입력합니다.

  1. Framework Preset과 Root Directory가 실제 프로젝트 위치와 맞는지 확인합니다.
  2. 프로젝트에 환경 변수가 없다면 새 값을 만들지 않고 넘어갑니다.
  3. 환경 변수가 있다면 변수 이름만 Codex와 확인하고, 값은 Vercel의 Environment Variables에 학생이 직접 입력합니다.
  4. 브라우저에 전달되는 변수는 비밀 값으로 사용할 수 없으므로 모르는 항목은 배포 전에 멘토에게 보여 줍니다.
값을 공유하지 않습니다 API 키와 토큰 값은 Codex 대화, GitHub, 화면 캡처와 도움 요청 글에 붙여 넣지 않습니다.

배포를 한 번 실행하고 결과를 읽습니다

실패하면 같은 버튼을 반복하지 않고 첫 오류부터 확인합니다.

  1. Deploy를 한 번 선택하고 완료될 때까지 기다립니다.
  2. 성공하면 생성된 주소를 엽니다.
  3. 실패하면 Build Logs에서 가장 먼저 나온 실제 오류와 실패한 명령을 찾습니다.
Vercel 배포가 실패했어. 아래에는 비밀정보를 가린 첫 오류와 실패한 명령만 붙일게. 바로 파일을 바꾸지 말고 원인 후보와 확인 순서를 쉬운 말로 설명해 줘. 로컬에서 같은 실패를 재현할 방법을 먼저 제안하고 내 승인을 기다려. 실패한 명령: 첫 오류:

다른 환경에서 공개 주소를 검사합니다

내 로그인과 개발 환경이 없어도 같은 핵심 흐름이 보여야 합니다.

  1. 시크릿 창, 다른 브라우저 또는 휴대전화에서 공개 주소를 엽니다.
  2. 서비스 설계서의 시작 → 핵심 행동 → 결과를 설명 없이 실행합니다.
  3. 새로고침 뒤에도 서비스 설계서에서 남아야 하는 결과가 유지되는지 확인합니다.
  4. 휴대전화 화면에서 글자, 버튼과 이미지가 잘리거나 겹치지 않는지 확인합니다.
  5. 화면이나 주소에 API 키, 내부 오류, 개인 경로가 보이지 않는지 확인합니다.
여기서 실패하면 새 기능을 추가하지 않습니다. 공개 시연을 막는 문제 하나만 재현하고 수정한 뒤 다시 커밋·업로드·검사합니다.

시연과 대체 화면을 준비합니다

인터넷이나 외부 서비스가 멈춰도 핵심 결과를 설명할 수 있게 합니다.

  1. 공개 주소와 마지막 커밋 설명을 진행 기록에 남깁니다.
  2. 핵심 흐름의 시작·행동·결과 화면을 각각 캡처합니다.
  3. 외부 API나 네트워크가 꼭 필요하면 정상 작동하는 짧은 화면 녹화를 준비합니다.
  4. 동료 앞에서 시간을 재며 시연하고, 무엇을 왜 만들었는지 내 말로 설명합니다.

최종 통과 기준

아래 결과가 모두 있어야 배포가 끝난 것입니다.

기능과 배포

  • 로컬과 공개 주소에서 같은 핵심 흐름이 작동합니다.
  • GitHub와 Vercel이 같은 최종 커밋을 가리킵니다.
  • 다른 브라우저와 휴대전화에서 공개 주소를 확인했습니다.

안전과 시연

  • 비밀정보와 공개 권한이 없는 원본이 저장소와 화면에 없습니다.
  • 새 기능을 추가하지 않고 시연을 막는 문제만 고쳤습니다.
  • 공개 주소와 대체 화면을 준비했습니다.

막혔을 때

배포 실패와 서비스 동작 실패를 구분해서 전달합니다.

배포 자체가 실패

  • 실패한 명령
  • Build Logs의 첫 오류
  • 로컬에서 같은 명령의 결과

주소는 열리지만 기능이 실패

  • 어느 화면에서 시작했는지
  • 무엇을 눌렀는지
  • 예상 결과와 실제 결과
  • 새로고침 뒤에도 같은지

공식 안내

수업 직전 화면과 절차가 바뀌지 않았는지 다시 확인합니다.