Vercel 배포와 GitHub 자동배포 연결
소스는 GitHub에 올라가 있습니다. 이제 인터넷에 띄울 차례입니다. 이번 레슨에서는 두 가지를 합니다 — ① 지금 상태를 바로 배포 하고, ② 앞으로 코드를 올릴 때마다 자동으로 배포되도록 연결 합니다.
이 레슨은 순탄하지 않습니다.
연결이 두 번 막히고, 그때마다 Claude Code가 “이건 제가 대신 할 수 없습니다” 라며 사람에게 일을 넘깁니다. 무엇을 맡길 수 있고 무엇은 내가 해야 하는지 — 그 경계를 보는 것이 이 수업의 핵심입니다.
Skills가 실제로 돈다
6장에서 개념으로 배운 Skills 가 여기서 실물로 등장합니다. “Vercel 전용 배포 스킬이 있으니 그걸 쓰겠다”며 정해진 점검 순서를 따라 배포합니다.
사람에게 넘기는 법
로그인, 권한 승인처럼 계정 주인만 할 수 있는 일이 있습니다. 그럴 때 무엇을 어디서 몇 번 클릭해야 하는지 목록으로 넘겨 줍니다.
한 번 연결하면 끝
자동 배포를 걸어 두면 그 뒤로는 코드를 올리는 것 = 배포 가 됩니다. 배포 명령을 따로 칠 일이 없어집니다.
① 배포 준비 — CLI를 깔고 로그인까지
1. 앞 레슨이 다음 할 일을 미리 알려 줍니다
GitHub 업로드를 마치면서 이미 “다음 단계는 Vercel 배포”라며 방법을 적어 뒀습니다. 심지어 로그인은 브라우저가 열려야 하니 직접 실행하는 편이 낫다 는 것까지 미리 짚어 줍니다. 이렇게 남겨 준 안내를 그대로 다음 지시로 쓰면 됩니다.
2. “이어서 진행해 줘”
긴 설명이 필요 없습니다. 앞 작업의 맥락이 그대로 남아 있어서 “Vercel 배포까지 이어서 진행해 줘” 한 줄이면 됩니다. 이번에도 도구가 깔려 있는지, 로그인돼 있는지부터 확인합니다.
3. 없으면 깝니다
Vercel CLI가 없다는 걸 확인하고 설치합니다. 무엇이 없는지 사람이 찾아 알려 줄 필요가 없습니다.
4. 로그인은 사람 몫입니다
여기서 브라우저가 열립니다. 내 계정에 로그인하는 일은 대신 해 줄 수 없습니다. 계정을 고르고 승인하는 것은 사람이 해야 합니다.
5. 기기 인증을 승인합니다
터미널에서 뜬 코드가 브라우저 화면의 코드와 같은지 확인하고 승인합니다. 이 절차 덕분에 남의 터미널이 내 계정에 몰래 붙을 수 없습니다.
6. 어떤 계정으로 붙었는지 확인합니다
로그인이 끝나면 어느 계정으로 들어갔는지 확인합니다. 회사 계정과 개인 계정을 함께 쓴다면 여기를 꼭 보세요.
② Skills가 실제로 도는 순간
7. “전용 배포 스킬이 있으니 그걸 쓰겠습니다”
배포 명령을 즉흥적으로 치지 않습니다. Vercel 배포용으로 미리 정리해 둔 “스킬”을 불러 그 절차대로 진행하겠다고 합니다. 화면에 “스킬을 성공적으로 불러왔다”는 한 줄이 찍힙니다.
6장 「Skills: 반복을 기술로 만들기」가 이겁니다
스킬은 “이런 일을 할 때는 이런 순서로, 이런 것들을 먼저 확인하고 해라”를 적어 둔 사용 설명서입니다. 매번 처음부터 생각하는 대신 검증된 절차를 그대로 재생 합니다. 사람으로 치면 “체크리스트를 꺼내 드는” 순간입니다.
8. 스킬이 시키는 점검부터 통과합니다
바로 배포하지 않고 점검 목록부터 지나갑니다 — CLI가 준비됐는지, 커밋하지 않은 변경이 남아 있지 않은지, 프로젝트 구조는 단일 패키지인지, 사용자가 정말 “프로덕션” 배포를 요청한 게 맞는지. 전부 통과한 뒤에야 배포 명령을 실행합니다.
9. 배포가 끝나고, 다음 요구가 나옵니다
한 번 배포됐습니다. 하지만 이 방식은 내 컴퓨터의 파일을 그때그때 올려 보내는 방식이라 코드를 고칠 때마다 명령을 다시 쳐야 합니다. 그래서 “GitHub과 연동해서 배포하고 싶다”고 요구를 바꿉니다.
③ 자동 배포 연결 — 그리고 첫 번째 벽
10. 방식이 어떻게 달라지는지 설명해 줍니다
“이렇게 하면 main에 올릴 때마다 Vercel이 알아서 빌드하고 배포 합니다. 방금 취소한 직접 업로드 방식과 달리, 저장소를 Vercel 프로젝트에 연결하는 흐름입니다.” — 무엇이 어떻게 달라지는지 먼저 알려 주고 시작합니다.
11. 프로젝트는 만들어졌는데 저장소 연결이 실패합니다
“저장소에 접근할 수 있는지 확인하라”는 오류입니다. 원인은 분명합니다 — 우리가 저장소를 비공개로 만들었기 때문 입니다. Vercel이 그 저장소를 들여다볼 권한을 아직 받지 못했습니다.
12. “이건 제가 대신 할 수 없습니다”
여기서 멈추고 사람에게 넘깁니다. 주목할 점은 “안 됩니다”로 끝내지 않는다 는 것입니다. 왜 자기가 할 수 없는지(로그인과 동의가 필요해서), 대신 무엇을 어디서 어떻게 해야 하는지를 번호까지 붙여 알려 줍니다.
- 브라우저에서 지정한 주소를 연다
- 내 GitHub 계정을 고른다
- “Only select repositories” 를 골라 이 저장소 하나만 허용한다
- 설치·저장을 누른다
그리고 “끝나면 알려 주세요. 그러면 제가 바로 이어서 하겠습니다”라고 덧붙입니다. 일이 끊기지 않게 이어 붙일 지점까지 정해 주는 것 — 좋은 위임의 모양입니다.
13. 브라우저에서 권한을 승인합니다
Vercel이 요구하는 권한이 무엇인지 화면에 나옵니다. 무심코 누르지 말고 한 번은 읽어 보세요. 무엇을 읽고 무엇을 쓰겠다는 것인지 적혀 있습니다.
14. 승인 직후 바로 다시 시도합니다
“권한 부여가 끝났으니 연결하겠습니다.” 사람이 한 일을 알려 주면 그 자리에서 이어서 진행합니다.
15. 저장소 범위를 이 프로젝트 하나로 제한합니다
권한을 줄 때 “모든 저장소”가 아니라 “선택한 저장소만” 을 고르고 talkie 하나만 지정합니다. 외부 서비스에 권한을 줄 때는 항상 필요한 만큼만 — 나중에 다른 저장소가 생겨도 자동으로 노출되지 않습니다.
④ 그래도 안 될 때 — 두 번째 벽
16. 아직 반영이 안 됐습니다
권한을 줬는데도 여전히 실패합니다. “설정이 반영되는 데 몇 초 걸릴 수 있으니 잠시 후 다시 시도하겠다”며 기다렸다 재시도합니다. 성급하게 다른 방법으로 갈아타지 않습니다.
17. 실패의 “진짜 내용”을 파고듭니다
그래도 안 되자 오류 메시지만 보고 추측하지 않고, 서버가 실제로 무엇을 돌려주는지 직접 조회 합니다. 도구가 감춰 둔 응답을 꺼내 보는 것 — 사람 개발자가 막혔을 때 하는 행동과 같습니다.
18. 원인을 정리하고, 다시 사람에게 넘깁니다
계정 연결 방식 때문에 CLI로는 이 연결을 끝낼 수 없다고 정리하고, “가장 확실한 방법은 대시보드에서 직접 연결하는 것” 이라며 다시 주소와 클릭 순서를 넘깁니다. 같은 방법을 무한정 반복하지 않고 방법 자체를 바꾸는 판단 입니다.
사람이 봐야 할 대목
여기서 “알아서 될 때까지 계속 해 봐”라고 두면 같은 실패를 반복하며 시간과 비용만 씁니다. 두세 번 같은 벽에 부딪히면 방법을 바꾸거나 사람이 개입할 시점 입니다. 이 판단을 AI가 먼저 해 주면 좋지만, 안 해 줄 때는 사람이 끊어야 합니다.
19. 대시보드에서 직접 연결합니다
Vercel 프로젝트 설정의 Git 항목에서 GitHub을 고르고, 저장소 목록에서 talkie를 선택해 연결합니다. 클릭 몇 번이면 끝나는 일입니다.
20. 연결이 확인됩니다
“이미 프로젝트에 연결된 상태”라는 응답이 돌아옵니다. 사람이 브라우저에서 한 일을 CLI 쪽에서 확인해 주는 것입니다.
21. 설정 화면에서도 보입니다
Vercel 프로젝트 설정에 저장소 이름과 Connected 표시가 붙었습니다. 여기까지가 “연결”입니다.
⑤ 자동 배포가 진짜 도는지 확인
22. 연결만으로는 배포되지 않습니다
연결은 됐지만 배포 이력은 비어 있습니다. Git 연동 배포는 “다음 push부터” 동작하기 때문입니다. 그래서 “지금 커밋을 하나 올려서 자동 배포를 실제로 걸어 보겠다”고 합니다. 이때 Vercel이 추가해 둔 항목까지 .gitignore에 정리해 함께 커밋합니다.
23. 올립니다
푸시가 끝났습니다. 여기서부터는 Vercel이 알아서 할 차례입니다.
24. 자동 배포가 걸린 것을 확인합니다
“GitHub push가 프로덕션 배포를 자동으로 걸었습니다 — 연동 정상 동작 확인.” 이제부터는 코드를 올리는 것만으로 배포가 됩니다. 배포 명령을 따로 칠 일이 없어졌습니다.
이번 레슨에서 남길 것
- 두 가지 배포 방식이 있다 — 내 컴퓨터에서 직접 올리는 방식과, 저장소에 올리면 자동으로 배포되는 방식. 두 번째가 목표입니다.
- Skills = 검증된 절차의 재생 — 매번 즉흥적으로 명령을 짜는 대신, 정해진 점검 순서를 밟습니다. 6장에서 배운 개념이 여기서 실제로 돕니다.
- 배포 전 점검이 사고를 막는다 — 커밋하지 않은 변경이 남아 있는지 확인하는 절차 하나가 “내 컴퓨터에서만 되던 코드”가 배포되는 사고를 막습니다.
- 계정·권한은 사람의 영역 — 로그인과 권한 승인은 대신 해 줄 수 없습니다. 좋은 위임은 “못 합니다”가 아니라 “이걸 여기서 이렇게 해 주세요”입니다.
- 권한은 필요한 만큼만 — 외부 서비스에 저장소를 열어 줄 때는 “모든 저장소”가 아니라 “선택한 저장소만”.
- 같은 벽에 두세 번 부딪히면 방법을 바꿔라 — 반복 재시도는 시간과 비용만 씁니다. 방법을 바꾸거나 사람이 끊고 들어갈 시점입니다.
- 연결했다고 배포된 게 아니다 — 자동 배포는 다음 push부터입니다. 한 번 올려서 실제로 도는지 확인해야 “됐다”입니다.
자동 배포는 걸렸습니다. 그런데 대시보드를 열어 보면 배포가 “차단됨(Blocked)” 으로 멈춰 있습니다. 다음 레슨에서는 이 화면을 그대로 캡처해 Claude Code에 던져서 원인을 찾아냅니다.
강의로 이어서 보고 싶다면
이 부록에서 만든 앱은 5장에서 만든 바로 그 단톡방 입니다. 여기서는 Claude Code로, 5장에서는 AI 편집기(Cursor)로 만들었을 뿐입니다. 같은 앱을 만드는 전 과정을 영상 강의로 처음부터 보고 싶다면 아래 인프런 강의에서 이어서 볼 수 있습니다.
