제대로 배포하고 운영하기

02이 차시를 마치면

• 1.프로젝트 성격(정적 페이지인지, 서버·DB가 필요한지)에 따라 적합한 배포 서비스를 고를 수 있다.
• 2.코드에 직접 적힌 API 키를 환경변수로 옮기고, 노출 위험을 확인한 뒤 안전하게 재배포할 수 있다.
• 3.배포 후 점검 체크리스트를 실행해 모바일 화면·로딩 속도·에러 페이지·로그인 동작을 확인할 수 있다.
• 4.배포한 서비스에 커스텀 도메인을 연결하거나, 서비스 제공 주소를 정리해 공유할 수 있다.
• 5.무료 플랜의 사용 한도를 확인하고, 한도에 가까워지면 알림을 받도록 설정할 수 있다.

03왜 필요한가

9차시까지 와서 데이터베이스와 로그인이 붙은 서비스를 완성했다고 해보자. 그런데 이 서비스는 지금 내 컴퓨터 안, 즉 localhost에서만 켜져 있다. 개발 서버를 끄면 사라지고, 다른 사람은 이 주소로 아무것도 볼 수 없다. 발표일이 다가오는데 아직 아무도 접속해볼 수 있는 상태가 아니다.

• ·로컬에서만 도는 서비스는 팀장이나 친구에게 '한번 써보세요'라고 보낼 방법이 없다.
• ·API 키를 코드에 그대로 넣은 채 GitHub에 올리고 배포하면, 저장소가 공개인 경우 키가 그대로 노출된다.
• ·배포는 했지만 주소가 임시 도메인(예: my-app-a1b2.vercel.app)뿐이라 '진짜 서비스'라는 느낌이 나지 않고, 발표 자료에 넣기도 어색하다.
• ·무료 한도를 모르고 쓰다가 발표 당일 서비스가 멈추거나, DB가 잠들어 있어 첫 화면이 한참 안 뜨는 사고가 난다.

04개념 설명

05실습 가이드

1. 1. 같은 프로젝트를 두 서비스에 배포해 차이 체감하기

   • -9차시까지 만든 프로젝트(또는 실습용 예제 프로젝트)를 GitHub Pages에 배포해본다.
   • -같은 프로젝트를 Vercel에도 GitHub 저장소 연동으로 배포해본다.
   • -두 결과를 나란히 열어 어떤 기능이 GitHub Pages에서는 동작하지 않는지(로그인, DB 조회 등) 확인한다.

   예상 결과 — 두 서비스 각각에 배포 URL이 생기고, 서버 기능이 필요한 화면은 GitHub Pages에서만 정상 동작하지 않는 차이를 직접 확인한다.

   안 될 때 — GitHub Pages 배포에서 화면 자체가 안 뜨면 저장소 설정(Settings → Pages)에서 배포 브랜치·폴더 지정이 빠졌을 가능성이 크다. Vercel은 저장소 연동 시 프레임워크를 자동 인식하지 못하면 빌드가 실패하니, 빌드 로그의 에러 메시지를 그대로 P10-6에 붙여 물어본다.

2. 2. 배포 전 노출 위험 확인하기

   • -GitHub 저장소 검색창 또는 코드 전체에서 'API_KEY', 'SECRET', 'password' 같은 단어로 검색해, 실제 키 값이 코드에 직접 적혀 있는지 확인한다.
   • -Claude Code에 P10-1 프롬프트를 실제 프로젝트 이름과 배포 서비스로 채워 요청한다.
   • -AI가 찾아준 노출 지점 목록을 눈으로 하나씩 확인한다.

   예상 결과 — 코드에 직접 적힌 키·비밀번호 목록과, 각각을 환경변수로 옮겼을 때 등록할 위치 안내를 받는다.

   안 될 때 — 이미 공개 저장소에 실제 키 값을 커밋한 적이 있다면, 지금 지워도 커밋 이력에는 남아 있다. 해당 키는 발급처(Supabase, 외부 API 등)에서 즉시 재발급(rotate)하고 이전 키를 폐기한다.

3. 3. API 키를 환경변수로 옮기고 재배포하기

   • -P10-1에서 안내받은 대로 .env 관련 파일을 .gitignore에 추가했는지 먼저 확인한다.
   • -코드에서 키 값을 직접 쓰던 부분을 환경변수를 읽는 코드로 바꾼다.
   • -Vercel 프로젝트 설정의 Environment Variables 화면에 같은 이름과 값을 등록하고 재배포한다.

   예상 결과 — 코드에는 키 값이 보이지 않고, 재배포한 서비스는 이전과 동일하게 동작한다.

   안 될 때 — 재배포 후 기능이 멈추면 환경변수 이름이 코드와 배포 설정에서 한 글자라도 다르거나, 재배포를 하지 않고 설정만 저장한 경우다. 이름을 다시 대조하고 재배포를 명시적으로 실행한다.

4. 4. 배포 후 점검 체크리스트 실행하기

   • -P10-4 프롬프트로 점검 항목별 확인 방법을 안내받는다.
   • -휴대폰(또는 브라우저 개발자 도구의 모바일 화면 보기)으로 레이아웃이 깨지지 않는지 확인한다.
   • -처음 접속했을 때 로딩 속도, 존재하지 않는 주소로 접속했을 때 에러 페이지, 회원가입·로그인이 배포 주소에서도 실제로 되는지 차례로 확인한다.

   예상 결과 — 네 개 점검 항목(모바일 화면, 로딩 속도, 에러 페이지, 로그인 동작)을 모두 통과한다.

   안 될 때 — 로그인만 안 된다면 3단계에서 옮긴 환경변수 중 인증 관련 값(Supabase URL·키 등)이 빠졌을 가능성이 높다. 배포 서비스의 환경변수 목록을 다시 확인한다.

5. 5. 커스텀 도메인 연결 또는 제공 주소 정리하기

   • -커스텀 도메인을 구입한 경우, P10-3 프롬프트로 도메인 등록처와 Vercel 양쪽에 등록할 값을 안내받아 연결한다.
   • -도메인을 구입하지 않은 경우, 발급된 제공 주소(예: my-app.vercel.app)를 그대로 발표 자료·이력서 등에 쓸 수 있게 정리한다.
   • -연결 직후가 아니라 시간이 좀 지난 뒤 새 주소로 다시 접속해 정상적으로 연결됐는지 확인한다.

   예상 결과 — 커스텀 도메인 또는 정리된 제공 주소로 서비스에 정상 접속된다.

   안 될 때 — 도메인 연결 직후 접속이 안 되면 DNS 반영이 아직 끝나지 않은 것이다. 최대 하루 정도 걸릴 수 있으므로 발표 며칠 전에 미리 연결해두고, 급하면 제공 주소를 임시로 함께 준비한다.

6. 6. 무료 한도 확인 및 사용량 알림 설정하기

   • -P10-5 프롬프트로 Vercel과 Supabase 각각의 무료 한도 항목과 대시보드 내 확인 위치를 안내받는다.
   • -각 서비스 대시보드에서 현재 사용량이 한도의 몇 퍼센트인지 확인한다.
   • -한도 근접 알림 기능이 있다면 켜둔다.

   예상 결과 — 두 서비스의 현재 사용량 위치를 알고, 가능한 경우 알림이 설정되어 있다.

   안 될 때 — 무료 플랜에는 사용량 알림 기능이 없는 항목도 있다. 그런 경우 발표 전날 대시보드를 직접 확인하는 일정을 캘린더에 등록해둔다.

7. 7. 되돌리기(롤백) 연습하기

   • -Vercel의 Deployments 목록에서 이전 배포 버전을 하나 찾는다.
   • -일부러 화면 문구를 하나 바꿔 재배포한 뒤, 방금 찾은 이전 버전으로 되돌리는(Promote to Production 또는 Redeploy) 절차를 실제로 실행해본다.
   • -되돌린 결과가 실제로 이전 화면으로 바뀌었는지 확인한다.

   예상 결과 — 배포 목록에서 원하는 이전 버전으로 실제로 되돌아간다.

   안 될 때 — 되돌리기 버튼이 안 보이면 배포 서비스의 배포 이력 화면 이름이 다를 수 있다(예: Rollback, Promote, Redeploy 등 서비스마다 명칭이 다름). P10-6 형식으로 화면 캡처 내용을 설명하며 AI에게 위치를 물어본다.

8. 8. 캡스톤 발표 준비하기

   • -완성된 서비스의 주소, 사용한 기술(배포 서비스·DB), 만든 이유(어떤 업무·문제를 해결했는지)를 한 페이지로 정리한다.
   • -발표 직전 Supabase 프로젝트에 접속해 DB가 잠들어 있지 않은지 미리 깨워둔다.
   • -발표 자료에 실제 서비스 화면을 시연할지, 스크린샷으로 대체할지 정하고 시연할 경우 네트워크 연결을 미리 확인한다.

   예상 결과 — 발표 자료 한 페이지와 정상 접속되는 서비스 URL이 준비된다.

   안 될 때 — 현장 네트워크가 불안정할 것이 걱정되면 시연 화면을 미리 녹화하거나 스크린샷으로 백업 자료를 준비해둔다.

06실전 프롬프트

지금 만든 프로젝트를 [Vercel]에 배포하려고 해.

배포 전에 확인해야 할 것들을 점검해줘.
1. 코드에 API 키나 비밀번호가 직접 적혀 있는 곳이 있는지 찾아줘
2. 있으면 환경변수로 빼고, 어떤 값을 어디에 등록해야 하는지 알려줘
3. .gitignore에 빠진 게 없는지 확인해줘
4. 배포 후 확인해야 할 항목을 체크리스트로 만들어줘

나는 배포가 처음이니까 각 단계에서 무슨 화면이 나와야 하는지도 알려줘.

지금 만든 [프로젝트 이름]을 GitHub Pages랑 Vercel 둘 다에 배포해보고 싶어.

두 방법을 순서대로 알려줘.
1. GitHub Pages로 배포하는 절차
2. Vercel로 배포하는 절차
3. 이 프로젝트 기준으로 두 방법이 실제로 어떻게 다른지 (되는 기능 / 안 되는 기능 포함해서)

나는 [정적 페이지만 있는지 / 로그인·DB 같은 서버 기능도 있는지] 잘 모르니까,
내 프로젝트 구조를 보고 어느 쪽이 맞는지도 판단해줘.

[Vercel]에 배포한 프로젝트에 내가 구입한 도메인 [example.com]을 연결하고 싶어.

1. 도메인 구입처(예: 가비아, 후이즈 등)에서 어떤 값을 설정해야 하는지
2. Vercel 쪽에서는 뭘 등록해야 하는지
3. 연결이 잘 됐는지 확인하는 방법
4. 반영되기까지 보통 시간이 얼마나 걸리는지

순서대로, 화면에 뭐가 보여야 하는지도 포함해서 알려줘.
도메인을 아직 안 샀다면, 사지 않고 무료 주소([프로젝트명].vercel.app)로 정리하는 방법도 같이 알려줘.

방금 [Vercel]에 배포한 [프로젝트 이름]을 점검하려고 해.

아래 항목을 하나씩 확인하는 방법을 알려주고,
내가 결과를 알려주면 문제인지 아닌지 판단해줘.

1. 휴대폰 화면에서 레이아웃이 깨지지 않는지
2. 처음 접속했을 때 로딩이 너무 느리지 않은지
3. 존재하지 않는 주소로 들어갔을 때 에러 페이지가 이상하게 뜨지 않는지
4. 회원가입/로그인이 배포된 주소에서도 실제로 되는지

각 항목을 어떤 화면·도구로 확인하면 되는지도 알려줘.

내가 지금 쓰고 있는 [Vercel]이랑 [Supabase] 무료 플랜의 한도를 확인하고 싶어.

1. 지금 내 프로젝트가 어떤 항목(대역폭, 함수 실행 시간, DB 용량 등)에서
   한도에 걸릴 가능성이 있는지
2. 각 서비스 대시보드에서 현재 사용량을 어디서 확인하는지
3. 한도에 가까워지면 알림을 받을 수 있는 설정이 있는지, 있다면 어떻게 켜는지

화면 기준으로 순서대로 알려줘.

방금 배포했더니 사이트가 이렇게 됐어.

[증상: 화면이 하얗게 뜬다 / 에러 메시지가 보인다 / 로그인만 안 된다 등]

배포 직전에 바꾼 것: [바꾼 내용]
배포 플랫폼: [Vercel 등]
배포 로그에 뜬 메시지: [로그 내용 그대로 붙여넣기]

원인을 먼저 설명해주고,
지금 상태에서 가장 빠르게 이전 버전으로 되돌리는 방법을 알려줘.
그다음에 진짜 원인을 고치는 방법도 따로 알려줘.

07이것만은 주의

08자가 점검

09과제

9차시까지 만든 서비스를 이번 차시 실습대로 정식 배포하고, 완성된 서비스로 캡스톤 발표를 준비한다. 발표에는 서비스 주소, 어떤 업무·문제를 해결했는지, 사용한 배포 스택(예: Vercel + Supabase), 실습 중 겪은 에러와 해결 과정을 포함한다.

제출 형식 — ① 커스텀 도메인 또는 정리된 제공 주소 ② 배포 후 점검 체크리스트 결과(스크린샷 포함) ③ 발표 자료 1페이지(주소·해결한 문제·사용 스택·에러 해결 과정) ④ 사용한 프롬프트 중 가장 도움이 된 것 1개를 하나의 문서로 정리해 제출한다.

10더 알아보기

• Vercel 배포 문서 — 환경변수 등록, 도메인 연결, 배포 롤백(Rollback/Promote) 절차 확인용
• Supabase 프로젝트 설정 문서 — 무료 플랜 일시 정지 조건과 사용량 한도 확인용
• 도메인 등록업체(가비아 등) DNS 설정 안내 — 구입한 도메인의 DNS 값을 배포 서비스에 연결할 때 참고

환경변수(Environment Variable)

— 코드에 값을 직접 적는 대신, 실행 환경(배포 서비스 설정)에 등록해두고 이름으로 불러 쓰는 값. API 키·비밀번호 등 공개되면 안 되는 값을 코드 밖에 두는 방법.

DNS

— 도메인 이름을 실제 서버 주소로 연결해주는 인터넷 주소록 체계. 커스텀 도메인 연결 시 이 값을 등록한다.

콜드 스타트(Cold Start)

— 일정 시간 사용되지 않아 잠들어 있던 서버나 데이터베이스가, 첫 요청을 받고 다시 깨어나는 데 걸리는 지연 시간.

롤백(Rollback)

— 새로 배포한 버전에 문제가 생겼을 때, 이전에 정상 동작하던 배포 버전으로 되돌리는 절차.

다음 차시 예고 — 기본과정은 여기서 끝나지만, 지금 만든 서비스를 더 안정적으로 운영하고 싶다면 중급과정 01차시부터 이어집니다. 중급과정은 '왜 잘 되다가 무너지는가'를 시작으로, 배포 자동화·롤백·모니터링까지 다루는 10차시(운영과 팀 도입)로 이어집니다.