제3부 · Claude Code로 직접 만들기

28단계GitHub 계정과 첫 저장소

내 노트북에만 있는 것은 아직 도구가 아니다. GitHub에 올리고 눈으로 확인하는 데까지가 한 걸음이다.

걸리는 시간 · 읽기 약 10분 · 따라 하기 약 40분 · 난이도 ★★★ 심화 · 화면 확인 2026.09.27

이 단계를 마치면

  • GitHub 개인 계정과 비공개 저장소를 만들 수 있다.
  • 작업 폴더를 저장소에 처음 올리는 일을 Claude Code에게 맡기고, 인증을 직접 통과할 수 있다.
  • GitHub 화면에서 올라간 파일과 바뀐 줄을 눈으로 확인할 수 있다.

노트북에 커피를 쏟았다고 해 보자. 지난 한 주 동안 공들여 만든 방문 일지는 어디에 남아 있을까?

지금까지 만든 것은 내 노트북 한 곳에만 있다. 노트북이 고장 나면 함께 사라지고, 어제 상태로 돌아가고 싶어도 돌아갈 곳이 없다. 팀원에게 넘기려면 파일을 메일로 보내야 한다. GitHub가 이 문제를 풀어 준다. 코드와 그 코드가 바뀐 기록을 인터넷에 보관하는 곳이다. 보관소라고 생각하면 쉽다. 다만 파일만 쌓아 두는 창고와는 다르다. 누가 언제 무엇을 바꿨는지까지 차곡차곡 기록된다. 뒤의 제7부에서는 Claude가 GitHub를 읽어 오도록 연결하는 법도 다루지만, 이번에는 내 도구를 직접 그곳에 올린다.

GitHub에서 프로젝트 하나를 담는 공간을 저장소라고 부른다. 작업 폴더 하나가 저장소 하나와 짝을 이룬다. 이 단계에서는 계정을 만들고, 빈 저장소를 하나 만들고, 내 폴더를 처음 올리고, 눈으로 확인하는 데까지 간다. 용어 설명은 다음 단계로 미룬다. 먼저 한 번 올려 본 뒤에 이름을 붙여야 기억에 오래 남는다.

계정. 개인 이메일로 만든다. 사용자 이름은 영문으로 짧게 짓자. 이 이름은 저장소 주소에 그대로 들어가고, 나중에 배포 서비스에 로그인할 때도 쓴다. 가입 과정에서 이메일 인증을 요구하고, 2단계 인증을 켜라는 안내가 나올 수 있다. 켜 두는 편이 안전하다. 회사 이메일로 만든 계정이나 회사 조직에 속한 계정은 조직 규칙을 따라야 해서, 다른 서비스와 연결할 때 조직 관리자의 승인을 기다려야 할 때가 있다. 실제 수업에서도 여기서 막힌 사람이 많았다. 연습은 개인 계정으로 하고, 사내 도구로 정식으로 쓰게 되면 그때 회사 조직으로 옮긴다.

새 저장소. 로그인한 뒤 새 저장소를 만드는 버튼을 찾는다. 위치는 바뀔 수 있다. 채울 것은 세 가지다. 이름은 작업 폴더와 같은 영문 이름으로 한다. 공개 범위는 비공개(Private)를 고른다. README 파일을 함께 만들지 묻는 항목이 있으면 이번에는 체크하지 않는다. 빈 저장소여야 내 폴더를 처음 올릴 때 서로 다른 기록이 부딪히지 않는다. 만들고 나면 https://github.com/아이디/visit-log 같은 저장소 주소가 보인다. 이 주소를 복사해 두자.

처음 올리기. 명령을 직접 칠 필요는 없다. Claude Code에게 저장소 주소를 주고 올려 달라고 하면 된다. 그러면 Claude가 순서대로 일한다. 폴더에 기록 장치를 켜고(git 초기화), 지금 상태를 첫 기록으로 저장하고(커밋), 이 폴더와 GitHub 저장소를 연결한 뒤, 기록을 보낸다(푸시). 단계마다 허락을 구한다. 컴퓨터에 git이 깔려 있지 않다면 이 과정에서 설치하라는 안내가 뜬다. 맥에서는 개발 도구를 설치할지 묻는 창이 뜨기도 하고, 윈도우에서는 Git을 따로 설치해야 한다. 안내를 Claude에게 보여 주고 무엇을 해야 하는지 물으면 된다.

지시를 어떻게 하느냐에 따라 결과가 달라진다. "깃허브에 올려 줘"라고만 하면 어느 저장소인지, 무엇을 빼야 하는지, 인증에서 막히면 어떻게 할지가 빠져 있다. Claude가 저장소를 새로 만들려 하거나, 올리면 안 되는 파일까지 올릴 수 있다. 아래 프롬프트처럼 저장소 주소를 주고, 올라갈 파일 목록부터 보여 달라고 하고, 비밀 값이 담긴 파일은 빼 달라고 하고, 인증이 필요하면 멈추고 알려 달라고 하자. 사고가 날 만한 구멍이 미리 막힌다.

인증. 가장 많이 막히는 곳이다. 처음 푸시하면 GitHub가 이 저장소의 주인이 맞는지 확인한다. 여기서 GitHub 로그인 비밀번호를 넣으면 거절당한다. GitHub는 명령으로 올릴 때 비밀번호를 받지 않기 때문이다. 대신 두 가지 방법 중 하나를 쓴다.

방법 어떻게 하나 맞는 경우
브라우저 로그인 브라우저 창이 열려 GitHub에 로그인하고 허용을 누른다. GitHub의 명령줄 도구로 로그인하는 방식도 있다 개인 노트북, 처음 해 보는 사람
개인용 토큰 GitHub 설정의 개발자 항목에서 토큰을 만들고, 비밀번호를 묻는 곳에 넣는다 브라우저 창이 열리지 않을 때

어느 쪽이 편한지는 컴퓨터마다 다르니, 지금 상황에 맞는 방법을 Claude에게 물어보자. 토큰은 비밀번호나 다름없다. 대화창에 붙여 넣어 Claude에게 건네지 말고, 입력을 요구하는 곳에 내가 직접 넣는다. CLAUDE.md나 코드에도 절대 적지 않는다. 만들 때 유효 기간과 권한 범위를 고르게 되어 있다면 꼭 필요한 만큼만 고른다.

눈으로 확인. 올렸다는 보고를 받았다고 끝난 게 아니다. 브라우저로 저장소 주소를 열고 새로고침한다. 내 파일 이름이 목록으로 보여야 한다. index.html과 CLAUDE.md가 있는지, 올라가면 안 되는 파일이 섞이지 않았는지 살핀다. 그다음 문구 하나를 고쳐 다시 올려 달라고 하고, GitHub 화면에서 그 파일을 열어 해당 문구가 바뀌었는지 확인한다. 여기까지 되면 내 노트북과 보관소가 이어졌다.

칼럼에서 읽기 「[AX CEO가이드] 회계장부 보듯이, 코드장부도 봐야 한다」

“깃허브(그리고 같은 역할을 하는 깃랩·기업 내부 저장소)는 회사의 코드장부가 실제로 보관되는 '장부 캐비닛'이자 '금고'다. 누가 언제 어떤 코드를 넣고 뺐는지, 어떤 외부 부품을 끌어다 썼는지, 무엇을 고치고 무엇을 미뤄뒀는지가 그 안에 시간 순서대로 고스란히 기록된다. 회계로 치면 전표와 원장이 쌓여 있는 바로 그 방이다.”

오늘 만든 저장소가 방문 일지의 장부다. 작은 도구라도 기록이 남아 있으면 만든 사람이 부서를 옮겨도 무엇이 언제 왜 바뀌었는지 뒷사람이 따라갈 수 있다. 다음 단계에서 커밋 메시지를 우리말로 또박또박 쓰게 하는 까닭도 여기에 있다.

CEO경제신문, 2026.07.24

현장 장면

윤 과장은 처음에 회사 이메일로 GitHub에 가입했다. 회사가 이미 GitHub 조직을 쓰고 있어서, 가입하자마자 조직에 합류하라는 안내가 왔다. 그런데 조직 안에 저장소를 만들려 하자 권한이 없다며 관리자 승인을 요청하라는 안내가 떴다. 언제 올지 모르는 승인을 기다리는 대신, 윤 과장은 개인 이메일로 계정을 하나 더 만들어 비공개 저장소 visit-log를 만들었다. 이때 README 추가 항목에 무심코 체크를 했다. 작은 체크 하나였다.

Claude Code에게 "깃허브에 올려 줘"라고 하자 Claude가 저장소 주소를 물었다. 주소를 알려 주자 기록 장치를 켜고 첫 커밋을 만든 뒤 푸시하다가 멈췄다. 화면에는 "rejected, fetch first"라는 문구와 함께, GitHub 쪽에 이 폴더에 없는 기록이 있다는 설명이 붙어 있었다. 아까 체크한 README 때문이었다. 윤 과장이 합치는 계획부터 보여 달라고 하자, Claude는 GitHub의 README를 받아와 합친 뒤 다시 올리겠다고 했다. 강제로 덮어쓰는 방법도 있다고 했지만 윤 과장은 합치는 쪽을 골랐다.

다음 관문은 인증이었다. 사용자 이름과 비밀번호를 묻자 윤 과장은 GitHub 비밀번호를 넣었고, 비밀번호 인증은 지원하지 않는다는 문구가 돌아왔다. 그 문구를 보여 주자 Claude는 브라우저 로그인 방법을 안내했다. 창이 열리고 허용을 누르자 푸시가 끝났다.

안도는 오래가지 않았다. GitHub 화면을 새로고침해 보니 테스트용으로 만들어 둔 "고객사_원본.xlsx"가 함께 올라가 있었다. 올라갈 파일 목록을 미리 보지 않은 탓이다. 저장소가 비공개였던 게 천만다행이었다. 윤 과장은 그 파일을 저장소에서 빼고 제외 목록에 넣게 한 뒤, 원본 파일은 작업 폴더 밖으로 옮겼다. 그날 이후 윤 과장은 무엇을 올리든 파일 목록부터 받는다.

따라 하기

  1. 개인 이메일로 GitHub 계정을 만들거나 로그인한다. 성공 기준: 내 사용자 이름이 적힌 프로필 화면이 열린다.
  2. 새 저장소를 비공개로, README 없이, 작업 폴더와 같은 영문 이름으로 만든다. 성공 기준: 빈 저장소 화면에 저장소 주소가 보인다.
  3. 아래 프롬프트에 저장소 주소를 넣어 Claude Code에게 맡기고, 올라갈 파일 목록을 먼저 확인한다. 성공 기준: 목록에 비밀 값, 원본 자료, 개인정보가 담긴 파일이 없다.
  4. 인증을 물으면 브라우저 로그인이나 토큰으로 직접 통과한다. 성공 기준: 푸시가 끝났다는 보고가 오고, 토큰을 대화창에 붙이지 않았다.
  5. 브라우저에서 저장소 주소를 새로고침한다. 성공 기준: 내 파일 목록이 보이고 올라가면 안 되는 파일이 없다.
  6. 문구 하나를 고쳐 다시 올리게 하고 GitHub에서 그 파일을 연다. 성공 기준: 고친 문구가 GitHub 화면에도 반영돼 있다.

복사해 쓰는 프롬프트

이 폴더를 내 GitHub 비공개 저장소 [저장소 주소]에 처음 올리고 싶어.
1. 먼저 올라갈 파일 목록을 보여 주고, 인증키·비밀번호·개인정보·원본 자료가 들어 있을 만한 파일은 따로 표시해 줘.
2. 그런 파일은 올라가지 않게 제외 목록에 넣어 줘.
3. 첫 기록 메시지는 우리말로 "첫 업로드: [도구 이름] 첫 화면"처럼 적어 줘.
4. 인증이 필요하면 멈추고, 내가 직접 할 수 있는 방법을 순서대로 알려 줘. 토큰은 나에게 달라고 하지 마.
5. GitHub 쪽 기록과 부딪히면 강제로 덮어쓰지 말고 합치는 계획을 먼저 보여 줘.
다 올린 뒤에는 GitHub 화면에서 무엇을 확인하면 되는지 알려 줘.

막히면 이렇게

증상 원인 처방
Authentication failed, 비밀번호 인증은 지원하지 않는다는 문구 GitHub 비밀번호를 넣었거나 토큰이 틀렸다 브라우저 로그인이나 개인용 토큰으로 다시 한다
Repository not found, Permission denied 주소가 틀렸거나 다른 계정으로 인증됐다. 회사 조직이면 승인 대기일 수 있다 저장소 주소와 로그인한 계정을 확인하고, 조직이면 관리자에게 묻는다
rejected, fetch first 저장소를 만들 때 README를 함께 만들었다 강제로 덮어쓰지 말고 받아와 합치게 한다
올리면 안 되는 파일이 GitHub에 보인다 올리기 전에 목록을 확인하지 않았다 저장소에서 빼고 제외 목록에 넣는다. 비밀 값이었다면 그 값을 폐기하고 새로 발급한다

실습 파일

공개 저장소에 올려 둔 가공 자료와 양식이다. 회사 자료 대신 먼저 이것으로 해 본다.

스스로 점검

  • ☐ 저장소가 비공개이고, 개인 계정에 있는가
  • ☐ 토큰이나 비밀번호를 대화창, CLAUDE.md, 코드 어디에도 적지 않았는가
  • ☐ GitHub 화면에서 방금 고친 문구를 직접 확인했는가
점검 해설 보기
  1. GitHub 저장소 화면에 비공개(Private) 표시가 있고, 주소의 아이디가 개인 이메일로 만든 계정이면 통과다. 회사 조직 안에 만들었다가 승인 대기에 걸렸다면 개인 계정으로 새 저장소를 만든다. 「계정」과 「새 저장소」 부분을 다시 읽는다.
  2. 토큰을 대화창에 붙인 적이 없고, CLAUDE.md와 코드에서 비밀 값이 하나도 보이지 않으면 통과다. 이미 붙였거나 올렸다면 그 값을 폐기하고 새로 발급한다. 「인증」 부분과 「막히면 이렇게」 마지막 행을 확인한다.
  3. 문구 하나를 고쳐 올린 뒤 브라우저에서 GitHub의 해당 파일을 열어 바뀐 문구를 눈으로 봤으면 통과다. 보고만 받고 확인하지 않았다면 「눈으로 확인」대로 저장소 주소를 새로고침하고, 올라가면 안 되는 파일이 섞이지 않았는지도 함께 본다.

기억할 것

  • 연습은 개인 계정, 저장소는 비공개로 시작하고, 올리기 전에 파일 목록부터 본다.
  • 비밀번호 대신 브라우저 로그인이나 토큰을 쓰고, 토큰은 내가 직접 넣는다.

더 알아보기 · GitHub 시작하기

v2026.09.27.5 · 2026년 9월 27일 기준 · CEO비즈니스스쿨 김문수 교수 · 기능과 화면은 자주 바뀝니다. 책과 화면이 다르면 부록의 공식 문서가 기준입니다.