5장. 변경 저장하기 — 커밋, 푸시, 풀의 반복

2026년 3월 16일 밤 11시, 김진관 선생님은 class-2b 폴더 안에서 반 웹사이트 첫 완성본을 손보고 있었습니다. 수업 공지 영역, 학습 자료 링크, 학급 앨범 자리까지 Claude의 도움으로 채워 넣었습니다. 시계를 보니 새벽 1시가 지났습니다. GitHub Desktop의 파란 Push origin 버튼이 화면 오른쪽 위에 떠 있었습니다. 한 번도 눌러보지 않은 버튼입니다. 마우스를 올리자 손끝이 미세하게 떨렸습니다. 클릭. 진행 바가 10초 동안 움직였습니다. 화면이 바뀌었습니다. 김진관 선생님은 크롬을 열고 GitHub에서 알려준 주소 github.com/jinkwan-kim/class-2b를 주소창에 쳤습니다. 방금 책상에서 만든 index.html과 style.css가 그대로 거기 있었습니다. 핸드폰을 꺼내 같은 주소를 쳤습니다. 똑같이 열렸습니다. "세상 어디서든 이 주소면 열린다." 잠들기 전 김진관 선생님 머릿속에 내일 1교시 최은영의 얼굴이 떠올랐습니다.

커밋, 푸시, 풀. 이 세 단계의 반복이 Git 사용의 전부입니다.

이 챕터를 마치면 다음 네 가지를 할 수 있습니다.

• 수정한 파일을 커밋 메시지와 함께 저장소에 기록할 수 있습니다
• Publish repository로 내 저장소를 GitHub에 처음 공개할 수 있습니다
• Push origin으로 새 커밋을 GitHub에 올릴 수 있습니다
• Fetch origin과 Pull origin으로 GitHub의 변경 사항을 내 컴퓨터로 내려받을 수 있습니다

(1) 커밋 — 일기장에 오늘 한 일 기록하기

매일 밤 일기장을 쓰는 사람은 하루 일과 중 "오늘 기억할 만한 순간"을 골라 한 줄로 적습니다. 커밋도 같은 행동입니다. 김진관 선생님이 class-2b 폴더의 파일 몇 개를 고친 뒤, 그 변경을 한 덩어리로 묶어서 "공지 영역 추가"라는 한 줄을 붙여 저장합니다. 이게 커밋입니다. 일기장과 다른 점은 나중에 그 페이지로 정확히 되돌아갈 수 있다는 것입니다.

실습 순서는 다음과 같습니다. (1) class-2b 폴더의 index.html 파일을 메모장으로 열어 제목 아래에 <h2>이번 주 수업 공지</h2> 한 줄을 추가하고 저장합니다. (2) GitHub Desktop 화면으로 돌아가면 Changes 탭에 index.html이 자동으로 나타납니다. 파일 이름 옆에 노란색 점이 보이고, 오른쪽 화면에는 초록색으로 추가된 줄이 표시됩니다. (3) 왼쪽 하단 Summary 칸에 공지 영역 추가라고 적습니다. Description 칸은 비워둬도 괜찮습니다. (4) 파란색 Commit to main 버튼을 누릅니다. (5) 화면 왼쪽의 Changes 탭이 비어지고, 상단의 History 탭으로 넘어가면 방금 찍은 커밋이 가장 위에 쌓입니다.

커밋 메시지는 너무 짧지도 너무 길지도 않게 씁니다. "수정함" 같은 표현은 나중에 자신도 못 알아봅니다. "공지 영역 추가", "학급 앨범 링크 수정"처럼 한 줄에 "무엇을 했는지"가 드러나면 충분합니다. 이게 전부입니다.

잘 안 되면?

• Commit to main 버튼이 회색으로 눌리지 않는 경우: Summary 칸이 비어 있습니다. 한 글자라도 적으면 즉시 파란색으로 바뀝니다.
• Changes 탭에 파일이 나타나지 않는 경우: 메모장에서 저장을 누르지 않았거나, class-2b 폴더가 아닌 다른 위치에 저장했을 가능성이 큽니다. 파일 경로를 다시 확인합니다.
• "Your name and email are not configured" 경고가 뜨는 경우: GitHub Desktop > Preferences > Git 탭에서 이름과 이메일을 GitHub 계정과 같게 입력한 뒤 Save를 누르면 해결됩니다.

(2) 푸시 — 일기장 사진 찍어 구글 드라이브에 올리기

종이 일기장은 책상 서랍에만 있으면 불이 나거나 잃어버릴 때 모든 기록이 사라집니다. 그래서 스마트폰으로 사진을 찍어 구글 드라이브에 올려두면 언제 어디서든 다시 열 수 있습니다. 푸시도 같은 행동입니다. 내 컴퓨터의 커밋을 GitHub 서버로 올려서 세상 어디서든 접근할 수 있는 사본을 만듭니다.

Publish repository와 Push origin은 다른 버튼입니다. Publish repository는 저장소를 GitHub에 처음 등록할 때 딱 한 번 쓰는 버튼이고, Push origin은 그 이후 새 커밋이 생길 때마다 반복해서 누르는 버튼입니다. 첫 번째 업로드가 끝나면 버튼 이름이 자동으로 Push origin으로 바뀌므로 혼동할 일은 없습니다.

실습 순서는 다음과 같습니다. (1) 첫 번째 푸시는 Publish repository 버튼입니다. GitHub Desktop 상단 오른쪽에 있는 이 버튼을 누르면 "Publish Repository" 창이 뜹니다. Name은 class-2b로 이미 채워져 있습니다. Description은 우리 반 2학년 B반 학급 웹사이트로 적습니다. Keep this code private 체크박스는 일단 체크된 상태로 두고 파란색 Publish Repository 버튼을 누릅니다. (2) 10초 안에 업로드가 끝납니다. 상단 오른쪽 버튼이 Push origin으로 바뀝니다. (3) 이제 앞으로는 새 커밋을 찍을 때마다 Push origin 버튼 옆에 숫자 배지가 뜹니다. 1↑이라고 쓰여 있으면 "올려보낼 커밋이 1개 있다"는 뜻입니다. 이 버튼을 누르면 GitHub 서버로 올라갑니다. (4) 브라우저에서 github.com/내아이디/class-2b 주소를 열면 방금 올린 파일들이 그대로 보입니다.

김진관 선생님이 새벽 1시에 처음 Push origin 버튼을 누른 순간, 내 컴퓨터에만 있던 웹사이트가 세상의 주소 하나를 얻었습니다. 이게 진짜 변화입니다.

잘 안 되면?

• Publish repository 후 "authentication failed" 경고가 뜨는 경우: GitHub 계정 로그인 세션이 풀린 상태입니다. File > Options > Accounts에서 Sign out 후 다시 Sign in 합니다.
• Push origin 버튼이 안 보이는 경우: 아직 커밋하지 않았거나 이미 모두 올라간 상태입니다. Changes 탭에서 커밋을 먼저 만듭니다.
• GitHub 웹사이트에서 파일이 0개로 보이는 경우: 저장소는 만들어졌지만 아직 push가 성공하지 못한 상태입니다. GitHub Desktop으로 돌아가 Push origin을 다시 누릅니다.

(3) 풀 — 카카오톡에서 사진 받기

카카오톡 대화방에서 누가 사진을 올리면, 내 핸드폰은 자동으로 그 사진을 받아와 화면에 보여줍니다. 받지 못한 사진이 있으면 대화방을 다시 열 때 위에서 아래로 당겨 새로고침합니다. 풀도 같은 행동입니다. GitHub 서버에 새로운 변경이 올라와 있으면 그것을 내 컴퓨터로 내려받습니다. 김진관 선생님은 학교 컴퓨터에서 공지를 고치고 Push origin한 뒤, 집에 돌아와 노트북에서 Pull origin으로 최신 상태를 맞춥니다.

실습 순서는 다음과 같습니다. (1) 일단 GitHub 웹사이트에서 직접 파일을 하나 수정해봅니다. 브라우저에서 class-2b 저장소를 열고 README.md 파일을 클릭한 뒤, 오른쪽 위 연필 아이콘을 눌러 # 2학년 B반 학급 웹사이트 한 줄을 맨 위에 추가합니다. Commit changes 초록색 버튼을 누릅니다. (2) 이제 GitHub 서버에는 새 커밋이 있고, 내 컴퓨터에는 없습니다. (3) GitHub Desktop으로 돌아와 상단 오른쪽 버튼을 봅니다. 버튼 이름이 Fetch origin으로 보입니다. 이 버튼을 누르면 GitHub 서버를 확인해서 "새 변경이 있는지"만 조회합니다. (4) 조회가 끝나면 버튼 이름이 자동으로 Pull origin으로 바뀌고 1↓ 배지가 뜹니다. "내려받을 커밋이 1개 있다"는 뜻입니다. (5) Pull origin을 누르면 내 컴퓨터 파일이 GitHub의 최신 상태로 업데이트됩니다. 메모장으로 README.md를 열면 방금 웹에서 추가한 줄이 보입니다.

Fetch(확인)와 Pull(받기)이 두 단계로 나뉘어 있는 이유는, 무턱대고 내려받기 전에 "뭐가 바뀌었는지 먼저 확인할 기회"를 주기 위해서입니다. 초보 단계에서는 두 단계를 한 번의 Pull origin 클릭으로 묶어 쓰면 충분합니다. 이게 전부입니다.

잘 안 되면?

• "Pull failed: merge conflict" 경고가 뜨는 경우: 같은 파일의 같은 줄을 컴퓨터와 GitHub 양쪽에서 서로 다르게 고친 상황입니다. 지금 단계에서는 최신 저장소를 새로 clone 받아 다시 시작하는 것이 가장 빠릅니다(8장에서 충돌 해결을 자세히 다룹니다).
• Fetch origin을 눌러도 새 커밋이 없다고 나오는 경우: GitHub 웹 수정 후 Commit changes 버튼을 누르지 않았을 가능성이 큽니다. 브라우저에서 저장소 첫 화면으로 돌아가 마지막 커밋 시간을 확인합니다.
• Pull 도중 GitHub Desktop이 멈춘 것처럼 보이는 경우: 큰 파일이 포함됐을 때 시간이 걸립니다. 1분 정도 기다린 뒤에도 반응이 없으면 앱을 종료하고 다시 켭니다.

Quick Win 확인 — 학생이 먼저 발견한 순간

다음 날 3월 17일 1교시가 끝난 쉬는 시간, 최은영이 반 단톡방에 링크 하나를 공유했습니다. github.com/jinkwan-kim/class-2b. 그리고 메시지 한 줄을 덧붙였습니다. "얘들아 우리 선생님이 직접 만든 웹사이트래. 신기함." 김진관 선생님의 핸드폰이 카카오톡 알림으로 연이어 울렸습니다. 34명의 아이들이 같은 주소를 눌렀습니다. 이 순간이 김진관 선생님의 진짜 Quick Win이었습니다.

핵심 3줄 요약

• 커밋은 Changes 탭에서 Summary를 적고 Commit to main을 누르는 행위이고, 변경 한 덩어리에 한 줄 이름을 붙여 저장합니다.
• 처음에는 Publish repository로 저장소를 공개하고, 그 다음부터는 Push origin을 누르면 내 커밋이 GitHub로 올라갑니다.
• 다른 기기에서 받은 변경은 Fetch origin으로 확인한 뒤 Pull origin으로 내 컴퓨터에 반영합니다.

완료 체크리스트

• class-2b 폴더의 파일을 고치고 커밋 메시지를 적어 Commit to main을 누를 수 있다
• Publish repository로 class-2b를 GitHub에 처음 공개할 수 있다
• 브라우저에서 github.com/내아이디/class-2b 주소를 열어 올라간 파일을 확인할 수 있다
• GitHub 웹에서 파일을 수정한 뒤 Fetch origin > Pull origin으로 내 컴퓨터를 최신 상태로 맞출 수 있다

다음 챕터 예고

다음 6장에서는 AI가 코드를 한꺼번에 망가뜨렸을 때 History 탭의 오른쪽 클릭 한 번으로 10초 만에 원상 복구하는 방법을 다룹니다. 프롤로그의 빈 화면 사건이 어떻게 해결될 수 있었는지 그 장면을 재현합니다.