2장 — 내 코드의 타임머신: 커밋과 히스토리

3월 10일 화요일 저녁 9시, 김진관 선생님은 퇴근 후 집에서 세 시간 동안 class-2b 웹사이트에 수능 영단어 퀴즈 기능을 붙였습니다. 학생들이 단어를 클릭하면 뜻이 뒤집히는 카드 방식입니다. 자정이 다 되어 잠자리에 들었고, 다음 날 아침 노트북을 다시 열었더니 어젯밤 마지막 요청에서 Claude가 파일 일곱 개를 한꺼번에 바꿔놓은 것이 그제야 확인됐습니다. 화면에는 오류가 빨갛게 쏟아집니다. 어느 파일이 원래 멀쩡했고 어느 파일이 새로 망가진 건지 구분이 되지 않습니다. 김진관 선생님은 처음으로 이런 생각을 했습니다. "1장을 읽고 그때 커밋이라도 한 번 찍어뒀다면."

커밋을 제대로 찍어두면 AI가 동시에 망가뜨린 파일 일곱 개를 한꺼번에 원래대로 돌려놓을 수 있습니다.

이 챕터를 마치면 세 가지를 직접 합니다. 스테이징으로 커밋에 담을 파일만 골라냅니다. 한 달 뒤의 내가 읽어도 알아볼 커밋 메시지를 한 줄 씁니다. 히스토리 목록에서 원하는 시점을 찾아 엽니다.

(1) 스테이징 — 단체 사진 찍기 전 찍힐 사람만 모으기

스테이징(staging)은 학급 단체 사진을 찍기 전에 찍힐 사람만 카메라 앞에 모으는 과정과 같습니다. 2학년 B반 단체 사진을 찍는 날 운동장에는 B반 학생뿐 아니라 지나가는 A반 학생, 체육 수업 마친 3학년 선배도 섞여 있습니다. 전부 프레임 안에 들어가면 "B반 단체 사진"이라고 부를 수 없습니다. 커밋도 같습니다. 프로젝트 폴더에는 방금 수정한 소스 파일, 아직 수정하지 않은 파일, 임시로 만든 메모 파일까지 뒤섞여 있습니다. 스테이징은 "이번 커밋에는 이 파일과 저 파일만 담자"라고 미리 고르는 단계입니다. GitHub Desktop에서는 변경된 파일 왼쪽의 체크박스가 스테이징입니다. 체크한 파일만 다음 커밋에 들어갑니다.

잘 안 되면? 파일을 분명히 수정했는데 GitHub Desktop 변경 목록이 비어 있을 때가 있습니다. 두 가지를 확인합니다. (1) 파일을 저장(Ctrl+S)했는지 확인합니다. 편집기에서 수정만 하고 저장하지 않으면 Git은 변화를 보지 못합니다. (2) 저장소 폴더 안에서 작업 중인지 확인합니다. 저장소 바깥에 있는 파일은 Git의 시야 밖입니다. 두 가지를 모두 확인했는데도 비어 있다면 Repository > Refresh를 한 번 눌러봅니다.

(2) 커밋 메시지 — 냉장고에 붙여 두는 포스트잇

커밋 메시지는 냉장고 문에 붙이는 포스트잇과 같습니다. "점심 먹고 남은 카레, 수요일까지"라고 적어 두면 다음에 냉장고를 열 내가 바로 상황을 파악합니다. "음식"이라고만 적혀 있으면 열어서 맛을 보고 냄새를 맡아야 합니다. 커밋 메시지도 같습니다. 한 달 뒤 히스토리를 훑을 때 각 줄이 바로 말을 걸어야 합니다.

좋은 메시지에는 세 가지 원칙이 있습니다. (1) 무엇을 고쳤는지 동사로 시작합니다. "영단어 퀴즈 카드 뒤집기 기능 추가", "학급 소개 페이지 배경색 변경". (2) 한 줄에 한 가지 변화만 담습니다. 버그 수정과 새 기능이 한 커밋에 섞이면 되돌릴 때 둘이 같이 딸려 갑니다. (3) 15자에서 50자 사이면 충분합니다. 너무 짧으면 정보가 없고, 너무 길면 목록에서 눈에 안 들어옵니다. 김진관 선생님이 3월 10일 밤 잠자리에 들기 전 "영단어 퀴즈 기능 첫 완성"이라고 한 줄 커밋해 뒀다면, 다음 날 아침 AI가 망가뜨린 일곱 파일을 그 한 줄로 한꺼번에 되돌릴 수 있었습니다.

(3) 히스토리 읽기 — 유튜브 시청 기록처럼 최신이 맨 위

히스토리는 유튜브의 시청 기록 페이지와 같은 구조입니다. 최신이 맨 위에, 오래된 것이 아래에 쌓입니다. GitHub Desktop의 History 탭을 열면 커밋이 한 줄씩 나열됩니다. 한 줄을 클릭하면 오른쪽에 그때 어떤 파일이 어떻게 바뀌었는지 색으로 표시됩니다. 초록색은 추가된 줄, 빨간색은 지워진 줄입니다. 유튜브에서 어제 본 영상을 다시 찾듯이, 히스토리에서 "그때 잘 되던 시점"을 찾아 열어봅니다.

AI로 코딩할 때는 커밋을 자주 찍어야 합니다. 기능 하나를 완성할 때마다, AI에게 큰 수정을 맡기기 직전마다 커밋 버튼을 한 번 누릅니다. 쌓아둔 줄 하나하나가 김진관 선생님 같은 아침에 타임머신의 좌표가 됩니다.

잘 안 되면? 히스토리에 방금 찍은 커밋이 안 보일 때가 있습니다. GitHub Desktop 왼쪽 위에 현재 보고 있는 브랜치 이름이 main인지 확인합니다. 다른 브랜치로 이동한 상태라면 커밋 목록도 그 브랜치 기준으로 바뀝니다. main으로 돌아오면 원래 히스토리가 다시 나타납니다. 브랜치는 이 책 5장에서 자세히 다룹니다.

이 챕터의 핵심 3줄

(1) 스테이징은 커밋에 담을 파일만 체크해서 골라내는 단계입니다. (2) 커밋 메시지는 한 달 뒤의 내가 읽어도 알아볼 동사 중심 한 줄입니다. (3) 히스토리는 유튜브 시청 기록처럼 시간순으로 커밋을 보여주며, 각 줄에서 변경 내용을 색으로 확인합니다.

완료 체크리스트

수정한 파일 중 원하는 것만 체크해 스테이징한다
동사로 시작하는 커밋 메시지를 한 줄 쓴다
히스토리에서 특정 커밋의 변경 내용을 색으로 확인한다
AI에게 큰 수정을 맡기기 전에 커밋부터 찍는 습관을 안다

다음 챕터 예고

3장에서는 지금까지 내 컴퓨터에만 있던 커밋 기록을 인터넷 너머로 올려 둡니다. 학교 컴퓨터에서도, 집 노트북에서도, 연수장 태블릿에서도 같은 코드를 여는 방법입니다.