CLI만으로 GitHub에 올리기
앱은 내 컴퓨터에서만 돌고 있습니다. 남들이 쓰게 하려면 먼저 소스를 GitHub에 올려야 합니다. 4장에서는 이 과정을 브라우저와 터미널을 오가며 손으로 했지만, 이번에는 “최대한 CLI를 이용하도록 해” 한 문장 으로 대신합니다.
이 레슨의 진짜 주제는 GitHub이 아닙니다. 중간에 AI가 한 번 막히는데, 그때 더 쉬운 우회로 를 제안합니다. 사람이 “아니, 제대로 된 방법으로 하자”고 방향을 잡아 주는 장면이 이 수업에서 가장 중요한 대목입니다.
한 문장이면 된다
저장소 만들기, 첫 커밋, 원격 연결, 푸시까지 — 4장에서 여러 화면을 오가며 하던 일이 명령 몇 줄로 이어집니다.
올리기 전에 걸러 낸다
무엇을 올리지 않을지 부터 정합니다. 환경 변수, 로컬 설정, 빌드 결과물은 저장소에 올라가면 안 됩니다.
쉬운 길로 새지 않게
막혔을 때 AI가 고르는 우회로가 늘 옳지는 않습니다. 방향을 되잡아 주는 것이 사람의 몫입니다.
① 시키기 — 문장 하나
1. 무엇을 원하는지, 어떻게 하길 원하는지 같이 말합니다
“이 소스를 Vercel에 배포하기 위해 GitHub에 업로드하고 싶어. 최대한 CLI를 이용하도록 해.” — 뒷문장이 중요합니다. 그냥 “올려 줘”라고 하면 브라우저를 열어 클릭하라고 안내할 수도 있습니다. 어떤 방식으로 하길 원하는지까지 적어야 원하는 흐름이 나옵니다.
2. 도구가 준비돼 있는지부터 확인합니다
바로 명령을 쏘지 않고 git 과 gh 가 깔려 있는지, GitHub에 로그인돼 있는지부터 봅니다. 4장 「GitHub CLI 설치·설정」을 해 뒀다면 여기서 그냥 통과합니다.
3. 계정까지 확인되면 시작합니다
어떤 계정으로 로그인돼 있는지 이름까지 확인해 줍니다. 여러 GitHub 계정을 쓴다면 이 줄을 꼭 보세요. 엉뚱한 계정에 저장소가 생기는 사고가 여기서 걸러집니다.
② 올리기 전에 — 무엇을 올리지 않을지부터
4. 환경 변수 파일을 먼저 제외합니다
.gitignore 에 환경 변수 파일을 추가한 뒤에야 저장소를 초기화합니다. 순서가 중요합니다. 한 번 올라간 비밀값은 나중에 지워도 기록에 남습니다.
가장 흔한 사고가 이겁니다 — API 키가 든 .env 파일을 그대로 올려 버리는 것. 공개 저장소라면 몇 분 만에 자동 수집기에 걸립니다. 올리기 전에 .gitignore부터 가 몸에 배어야 합니다.
5. 로컬 설정 파일도 걸러 냅니다
내 컴퓨터에서만 쓰는 설정 파일도 저장소에 올릴 이유가 없습니다. 시키지 않았는데 스스로 골라내고, 왜 빼는지 이유까지 말합니다.
6. 이미 올라간 것도 되돌립니다
파일을 지우는 게 아니라 “추적 목록”에서만 뺍니다. 내 컴퓨터에는 그대로 남고 저장소에만 안 올라갑니다. 이 구분이 Git에서 자주 헷갈리는 지점입니다.
7. 최종 목록을 확인합니다
제외 목록이 완성됐습니다. 무엇이 올라가고 무엇이 안 올라가는지 이 파일 하나로 결정됩니다.
③ 커밋 — 누가, 무엇을 바꿨는지 남기기
8. 비공개 저장소를 기본으로 잡습니다
“가족용 개인 앱이니 비공개(private) 저장소를 기본으로 하겠다”고 먼저 밝힙니다. 나중에 공개로 바꾸기는 쉽지만, 잘못 공개한 것을 되돌리기는 어렵습니다. 의심스러우면 비공개 가 안전한 기본값입니다.
9. 커밋에는 “누가”가 필요합니다
Git은 커밋마다 “누가 했는지”를 기록합니다. 그래서 이름과 이메일이 설정돼 있지 않으면 커밋이 안 됩니다. 이 저장소에서만 쓰도록 로컬 설정 으로 잡아 줍니다. 5장에서 우리가 오류를 만난 뒤에야 손으로 입력했던 그 값입니다.
git config user.name "내이름"
git config user.email "내메일@example.com"이 이메일은 나중에 한 번 더 문제를 일으킵니다. 4교시에서 다시 만납니다.
④ 저장소 만들고 밀어 넣기 — 그리고 첫 실패
10. 저장소 생성 · 원격 연결 · 푸시를 한 번에
GitHub 웹사이트에 들어가 「New repository」를 누르고, 이름을 정하고, 원격 주소를 복사해 와서 연결하고… 이 전부가 명령 한 줄 로 끝납니다. 저장소 생성, 비공개 설정, 원격 등록, 첫 푸시까지 한꺼번에 처리하는 명령입니다.
11. 그런데 푸시가 실패합니다
저장소는 만들어졌는데 푸시가 막혔습니다. SSH로 GitHub에 접속하려는데 “이 서버가 진짜 GitHub이 맞는지” 를 확인할 수 없었기 때문입니다. 그러자 “HTTPS 방식으로 바꿔서 푸시하겠다” 는 우회로를 제안합니다.
여기가 이 레슨의 핵심입니다.
제안 자체는 틀리지 않았습니다. HTTPS로 바꾸면 실제로 푸시는 됩니다. 하지만 그건 막힌 문제를 푼 게 아니라 피해 간 것 입니다. AI는 “일단 되게 하는” 쪽으로 기우는 경향이 있고, 그 결과 원래 하려던 방식이 슬그머니 바뀌어 있곤 합니다. 무엇이 왜 실패했는지 읽고, 우회로를 받아들일지 결정하는 것은 사람의 몫 입니다.
⑤ 사람이 방향을 되잡는다
12. “우회하지 말고 제대로 하자”
“SSH 호스트 키 검증을 통해 배포하도록 하자.” 한 줄이면 방향이 바뀝니다. 길게 설명할 필요 없습니다. 무엇이 마음에 들지 않는지, 대신 무엇을 원하는지만 말하면 됩니다.
13. 이번에는 “안전하게” 하겠다고 합니다
여기서 그냥 “신뢰함”으로 처리해 버릴 수도 있었습니다. 그런데 임의로 신뢰하지 않고, GitHub이 공식 문서에 공개한 지문과 대조한 뒤 등록하겠다 고 합니다. 방식을 지정해 주자 방식에 맞는 절차까지 따라온 것입니다.
호스트 키 지문이 무엇인가
SSH로 서버에 처음 접속하면 “이 서버를 믿겠느냐”고 묻습니다. 여기서 아무거나 “예”를 누르면, 중간에서 GitHub인 척하는 가짜 서버에 내 열쇠를 내밀 수도 있습니다. 그래서 서버가 내미는 지문을 GitHub이 공식 문서에 적어 둔 지문과 눈으로 대조 하는 것이 정석입니다. 5장에서 “핑거프린트를 물어보면 예스를 입력하세요”라고 넘어갔던 그 단계입니다.
14. 공식 지문과 대조합니다
GitHub이 공개한 지문 값을 화면에 적어 두고, 서버에서 실제로 받아 온 값과 비교합니다. 사람이 문서를 찾아 눈으로 맞춰 보던 일을 그대로 재현합니다.
15. 일치하면 등록합니다
두 값이 정확히 일치했습니다. 이제 “이 서버는 진짜 GitHub” 이라고 내 컴퓨터에 기록해 둡니다. 이 작업은 홈 폴더의 열쇠 보관함을 건드리므로 여기서도 승인을 따로 받습니다.
16. 인증에 성공하고 푸시합니다
“Hi vibecodingkr!” — GitHub이 나를 알아봤다는 뜻입니다. 우회하지 않고 원래 하려던 방식 그대로 문제를 해결한 뒤 푸시합니다.
17. 푸시가 끝나면 스스로 확인합니다
“올렸다”로 끝내지 않고 저장소 상태를 다시 조회해 이름·공개 범위·기본 브랜치를 확인합니다.
⑥ 결과 확인
18. GitHub에 실제로 올라와 있습니다
브라우저로 확인합니다. 저장소 이름 옆에 Private 이 붙어 있고, 파일들이 첫 커밋 메시지와 함께 올라와 있습니다. .env 파일이 목록에 없는지 도 이때 꼭 확인하세요.
19. 마지막 요약을 읽습니다
주소, 공개 범위, 기본 브랜치, 연결 방식이 표로 정리됩니다. 그리고 다음 단계인 Vercel 배포 방법까지 미리 알려 줍니다. 이 요약은 그대로 다음 레슨의 출발점이 됩니다.
이번 레슨에서 남길 것
- “어떻게”까지 말하라 — “올려 줘”와 “CLI로 올려 줘”는 다른 결과를 냅니다. 방식에 선호가 있으면 처음부터 적으세요.
- 올리기 전에 .gitignore부터 — 환경 변수·로컬 설정·빌드 결과물은 저장소에 올라가면 안 됩니다. 한 번 올라간 비밀값은 지워도 기록에 남습니다.
- 의심스러우면 비공개 — 공개로 바꾸기는 쉽고, 잘못 공개한 것을 되돌리기는 어렵습니다.
- AI는 “되게 하는” 쪽으로 기운다 — 막히면 더 쉬운 우회로를 제안합니다. 그 제안이 원래 목표를 바꾸고 있지는 않은지 읽어야 합니다.
- 한 줄이면 방향이 바뀐다 — 길게 설명할 필요 없습니다. “우회하지 말고 이 방식으로 하자” 정도면 충분합니다.
- “예”를 누르기 전에 무엇을 믿는 건지 보라 — 호스트 키 지문 대조는 중간에서 가로채는 서버를 걸러 내는 절차입니다.
- 올린 뒤에는 브라우저로 눈으로 확인 — Private 표시와 파일 목록, 그리고 .env가 없는지.
이제 소스가 GitHub에 있습니다. 다음 레슨에서는 이것을 Vercel로 배포 하고, main 브랜치에 푸시할 때마다 자동으로 배포되도록 연결합니다. 6장에서 개념으로만 봤던 Skills 가 실제로 도는 장면도 여기서 나옵니다.
강의로 이어서 보고 싶다면
이 부록에서 만든 앱은 5장에서 만든 바로 그 단톡방 입니다. 여기서는 Claude Code로, 5장에서는 AI 편집기(Cursor)로 만들었을 뿐입니다. 같은 앱을 만드는 전 과정을 영상 강의로 처음부터 보고 싶다면 아래 인프런 강의에서 이어서 볼 수 있습니다.
