16장. 저장과 커밋: 작업을 안전하게 남기는 법

저장은 파일을 살리고, 커밋은 프로젝트를 지킨다

지난 장에서 우리는 Git과 GitHub가 왜 필요한지 살펴봤습니다. 핵심은 분명했습니다. 개발은 잘 만드는 일인 동시에, 망가져도 다시 돌아올 수 있게 만드는 일이라는 점입니다.

이제 그 안전장치를 실제로 손에 쥘 차례입니다. 바로 저장과 커밋입니다.

처음 개발을 시작하면 둘이 비슷하게 느껴집니다. 파일을 저장했으면 끝난 것 아닌가 싶기도 합니다. 하지만 이 둘은 하는 일이 다릅니다.

에디터에서 저장은 현재 파일의 내용을 디스크에 반영하는 일입니다. 쉽게 말해, 내가 방금 쓴 문장을 파일에 남기는 동작입니다. 반면 커밋은 프로젝트의 의미 있는 상태를 Git의 기록으로 남기는 일입니다. 단순히 파일이 존재하게 만드는 것이 아니라, "여기까지는 안전하다"는 체크포인트를 만드는 것이죠.

이 차이를 감각적으로 이해하는 것이 정말 중요합니다. 저장만 해 두면 파일은 남지만, 어떤 이유로 무엇이 바뀌었는지는 흐릿합니다. 커밋까지 해야 비로소 "왜 바뀌었는지", "어디까지가 한 덩어리 작업이었는지", "문제가 생기면 어디로 돌아가야 하는지"가 선명해집니다.

그래서 커밋은 단순한 기록이 아닙니다. 복구 장치이자 성장 로그입니다. 오늘의 나는 대충 수정했다고 생각해도, 일주일 뒤의 나는 그 커밋 덕분에 길을 찾습니다.

초보자가 가장 자주 하는 오해

초보자는 보통 두 가지 실수를 많이 합니다.

첫 번째는 너무 자주 저장하고, 너무 늦게 커밋하는 것입니다. Ctrl+S는 열심히 누르는데 Git 기록은 거의 남기지 않습니다. 그러다 기능이 꼬이면 "분명 조금만 바꿨는데 왜 이렇게 됐지?"라는 상황이 옵니다.

두 번째는 반대로 너무 많은 걸 한 번에 커밋하는 것입니다. 헤더도 고치고, 로그인도 붙이고, 버튼 색도 바꾸고, 에러 메시지도 손보고, 폴더 구조까지 정리한 뒤 한 번에 커밋해 버립니다. 이러면 나중에 문제가 생겼을 때 어느 변경이 원인인지 찾기가 매우 어려워집니다.

좋은 커밋 습관은 극단 사이에 있습니다. 너무 잘게 쪼개서 의미가 없어도 안 되고, 너무 크게 뭉쳐서 되돌리기 어려워도 안 됩니다.

핵심은 간단합니다.

한 커밋에는 한 가지 의미 있는 변화만 담는다.

이 원칙만 잡아도 Git이 훨씬 쓸모 있어집니다.

저장과 커밋의 차이를 비유로 이해하기

비유를 하나 들어 보겠습니다.

저장은 책상 위 메모지를 서랍에 넣는 일과 비슷합니다. 일단 잃어버리지는 않겠죠. 하지만 그 메모가 왜 중요한지, 언제 쓴 것인지, 다른 메모와 어떤 관계인지까지는 설명되지 않습니다.

커밋은 다릅니다. 메모를 날짜별로 정리해서 파일철에 꽂고, 앞장에 "로그인 화면 초안 완성", "게시글 작성 폼 검증 추가"처럼 제목을 붙이는 일에 가깝습니다. 나중에 다시 꺼내 봤을 때 맥락이 살아 있습니다.

개발에서는 이 맥락이 정말 중요합니다. 코드는 글보다 연결이 복잡하기 때문입니다. 한 줄을 바꿨는데 화면이 달라지고, 데이터가 안 보이고, 로그인까지 꼬일 수 있습니다. 그래서 단순 저장만으로는 부족합니다. 프로젝트의 상태를 설명 가능한 단위로 남겨야 합니다.

커밋은 언제 해야 할까

초보자는 이 질문을 가장 많이 합니다. "도대체 어느 타이밍에 커밋해야 하죠?"

정답은 놀랍도록 실용적입니다.

되돌아오고 싶은 순간마다 커밋하면 됩니다.

예를 들어 이런 순간들은 커밋 타이밍으로 좋습니다.

• 첫 화면이 깨지지 않고 일단 보일 때

• 로그인 폼 UI만 완성됐을 때

• 데이터 목록이 정상적으로 불러와질 때

• 글 작성 기능이 실제로 저장될 때

• 큰 리팩터링 전에 현재 상태를 안전하게 남기고 싶을 때

• AI에게 큰 수정을 맡기기 직전

이 기준이 좋은 이유는 단순합니다. 문제가 생겼을 때 "이 상태로는 다시 돌아가고 싶다"라고 느끼는 지점이기 때문입니다.

반대로 커밋을 미루면 어떤 일이 생길까요? 작은 성공들이 하나의 거대한 변경 덩어리로 섞입니다. 그러면 나중에 되돌릴 때 필요한 부분과 불필요한 부분이 한꺼번에 움직입니다. 결국 Git이 있는데도 복구가 어려워집니다.

좋은 작업 단위는 작지만, 너무 잘게는 아니다

작업을 작게 나누라는 말을 들으면 어떤 사람은 버튼 색 하나 바꿀 때마다 커밋하려고 합니다. 물론 그런 방식도 가능하지만, 초보자에게는 오히려 흐름을 끊을 수 있습니다.

좋은 작업 단위는 작지만 설명 가능한 크기입니다.

예를 들어 이런 식은 괜찮습니다.

• 메인 페이지 레이아웃 추가

• 게시글 목록 카드 컴포넌트 분리

• 로그인 폼 입력 검증 추가

• 검색창 상태 관리 연결

반면 이런 식은 너무 큽니다.

• 서비스 전체 수정

• 이것저것 고침

• AI가 해준 거 반영

이런 메시지가 나오는 이유는 보통 작업 단위가 너무 크기 때문입니다. 무엇을 했는지 한 문장으로 설명이 안 되는 상태인 것이죠. 커밋 메시지가 흐릿하다는 것은 대개 커밋 자체가 흐릿하다는 뜻입니다.

커밋은 '사진 찍기'에 가깝다

Git 커밋은 흔히 프로젝트의 스냅샷, 즉 사진이라고 비유합니다. 이 비유가 꽤 유용합니다.

사진을 찍을 때도 애매한 순간보다 장면이 정리된 순간이 좋습니다. 눈 감은 사람, 지나가는 사람, 흔들린 손이 한꺼번에 섞이면 나중에 보기 어렵습니다. 커밋도 마찬가지입니다. 장면이 어느 정도 정리되었을 때 찍어야 기록으로서 가치가 생깁니다.

예를 들어 로그인 기능을 만든다고 해 봅시다. 이 작업을 한 번에 끝내려 하면 커밋 하나가 너무 비대해집니다. 대신 이렇게 나눌 수 있습니다.

먼저 로그인 페이지의 기본 UI를 만들고 커밋합니다. 그다음 입력값 검증을 붙이고 커밋합니다. 마지막으로 실제 인증 로직을 연결하고 커밋합니다.

그러면 나중에 문제가 생겼을 때 "UI는 괜찮았는데 인증 연결부터 꼬였구나"처럼 원인을 좁히기 쉬워집니다.

즉, 커밋을 잘 남긴다는 것은 코드를 잘 쓰는 기술이기도 하지만, 작업을 사고하기 좋은 단위로 자르는 기술이기도 합니다.

실전에서 가장 많이 쓰는 기본 흐름

이 장에서는 복잡한 명령어보다 흐름을 익히는 것이 더 중요합니다. 초보자는 아래 순서만 몸에 익혀도 훨씬 안전하게 작업할 수 있습니다.

먼저 파일을 수정합니다. 그리고 에디터에서 저장합니다. 그다음 현재 무엇이 바뀌었는지 확인합니다. 변경이 내가 의도한 범위인지 살펴본 뒤, 커밋할 파일을 담고 메시지를 붙여 커밋합니다.

터미널에서는 보통 이런 흐름을 많이 씁니다.

git status
git add .
git commit -m "메시지"

여기서 가장 먼저 익숙해져야 할 명령은 git status입니다. 이것은 "지금 뭐가 바뀌었는지" 알려주는 현재 상황판입니다. 초보자에게는 거의 거울 같은 명령입니다. 무언가 이상하다고 느껴질 때, 먼저 상태를 보는 습관이 있으면 훨씬 침착해집니다.

git add는 커밋할 대상을 고르는 동작입니다. 마치 장바구니에 담는 것과 비슷합니다. 그리고 git commit은 그 장바구니의 내용을 하나의 기록으로 확정하는 단계입니다.

초보자들은 git add .를 자주 사용합니다. 현재 변경된 파일을 한꺼번에 담는 방식이죠. 처음에는 편리합니다. 다만 나중에는 정말 커밋할 파일만 선택하는 습관도 중요합니다. 의도하지 않은 파일, 테스트용 코드, 임시 메모가 같이 들어갈 수 있기 때문입니다.

지금 단계에서는 이렇게 기억하면 충분합니다.

상태를 확인하고, 의미 있는 변경만 담고, 한 문장으로 설명하며 커밋한다.

커밋 메시지는 미래의 나에게 보내는 메모다

커밋 메시지는 대충 써도 될 것 같지만, 사실은 Git을 쓸모 있게 만드는 핵심입니다.

메시지가 엉성하면 기록은 남아도 의미가 약해집니다. 반대로 메시지가 또렷하면 나중에 히스토리를 읽는 것만으로도 프로젝트의 성장 과정이 보입니다.

좋은 커밋 메시지는 길게 에세이를 쓸 필요가 없습니다. 오히려 짧고 분명한 한 문장이 가장 좋습니다. 무엇을 했는지가 바로 떠올라야 합니다.

예를 들어 이런 메시지는 좋지 않습니다.

• 수정

• 작업함

• 오류 해결

• 이것저것 반영

• 최종

문제는 사실이 아니라는 데 있습니다. 수정은 했겠죠. 작업도 했겠죠. 하지만 무엇을 했는지 전혀 보이지 않습니다.

반대로 이런 메시지는 훨씬 좋습니다.

• 메인 페이지 히어로 섹션 추가

• 로그인 폼 입력 검증 로직 적용

• 게시글 목록 API 연결

• 글 작성 실패 시 에러 메시지 표시

• 모바일 화면에서 카드 간격 조정

이 메시지들은 하나같이 변화의 초점을 보여 줍니다. 그래서 나중에 기록을 읽을 때도 프로젝트의 흐름이 살아 있습니다.

좋은 커밋 메시지를 쓰는 쉬운 공식

초보자에게는 복잡한 규칙보다 간단한 공식이 더 유용합니다.

무엇을 바꿨는지 + 어디에 적용했는지

이 틀만 써도 대부분 괜찮은 메시지가 나옵니다.

예를 들면 이렇습니다.

• 검색 기능 상태 관리 추가

• 회원가입 페이지 문구 수정

• 게시글 상세 조회 로직 연결

• 공통 버튼 컴포넌트 스타일 정리

조금 더 익숙해지면 왜 바꿨는지를 드러내는 메시지도 좋습니다.

• 빈 목록 화면 안내 문구 추가

• 중복 요청 방지를 위해 제출 버튼 비활성화

• 인증 실패 원인 확인을 위해 로그 출력 추가

이런 메시지는 단순 결과를 넘어 의도까지 보여 줍니다. 특히 디버깅할 때 아주 큰 힘이 됩니다.

커밋 메시지에 감정을 넣지 말고 의미를 넣자

개발을 하다 보면 에러 때문에 마음이 급해집니다. 그래서 커밋 메시지가 이렇게 되는 경우가 있습니다.

• 드디어 됨

• 왜 안 됐는지 모르겠지만 해결

• 진짜 마지막 수정

• 제발 되라

솔직해서 웃기긴 하지만, 나중에는 거의 도움이 되지 않습니다. 미래의 나는 그날의 감정 상태를 복원할 수 없기 때문입니다.

커밋 메시지는 감정 일기가 아니라 작업 설명서에 가깝습니다. 답답한 마음은 이해하지만, Git 히스토리에는 감정보다 의미를 남기는 편이 훨씬 유용합니다.

물론 개인 프로젝트라면 가끔 이런 메시지를 써도 세상이 무너지지는 않습니다. 다만 이 책의 목표는 "돌아가는 서비스"를 넘어 "계속 고칠 수 있는 서비스"를 만드는 것이므로, 처음부터 좋은 습관을 들이는 편이 훨씬 낫습니다.

AI와 함께 작업할 때는 커밋이 더 중요하다

이 책의 중요한 차별점은 AI와 함께 개발한다는 데 있습니다. 여기서 커밋의 가치가 더 커집니다.

AI는 빠르고, 때로는 과감합니다. 내가 버튼 하나만 다듬고 싶었는데 관련 컴포넌트 구조를 바꾸고, 스타일 파일을 나누고, 심지어 상태 관리 방식까지 건드릴 수 있습니다. 겉보기에는 더 좋아 보이지만, 실제로는 다른 부분이 미세하게 깨질 수도 있습니다.

이럴 때 가장 좋은 습관은 단순합니다.

AI에게 큰 변경을 맡기기 전에 먼저 커밋한다.

이 한 줄 습관이 엄청난 차이를 만듭니다. 문제가 생기면 "AI가 바꾸기 전 안정 상태"로 즉시 돌아갈 수 있기 때문입니다.

그리고 AI의 결과를 받은 뒤에도 바로 커밋하지 말고, 먼저 실행해 보고, 화면을 확인하고, 핵심 기능을 테스트한 뒤 커밋해야 합니다. 커밋은 자동 저장이 아니라 검토를 통과한 상태에 주는 도장에 가깝습니다.

AI와 협업할 때 추천하는 흐름은 이렇습니다.

• 현재 안정 상태를 먼저 커밋한다.

• AI에게 한 번에 하나의 작업만 맡긴다.

• 결과를 받아 직접 확인한다.

• 이상이 없으면 그 변화만 따로 커밋한다.

이렇게 하면 AI가 만든 변화도 내 프로젝트 안에서 통제 가능한 기록으로 남습니다.

커밋을 너무 늦게 하면 생기는 일

커밋을 미루는 사람은 대개 이런 생각을 합니다. "조금만 더 하고 한 번에 정리해서 커밋해야지."

문제는 개발에서 그 "조금만 더"가 거의 끝나지 않는다는 것입니다. 로그인도 붙이고 싶고, 문구도 고치고 싶고, 에러도 잡고 싶고, 레이아웃도 손보고 싶습니다. 그러다 보면 작업 범위가 계속 불어납니다.

이 상태의 커밋은 겉보기에는 풍성하지만 실제로는 위험합니다. 이유는 분명합니다.

첫째, 되돌릴 범위가 너무 커집니다.

둘째, 문제가 생겼을 때 원인을 좁히기 어렵습니다.

셋째, AI나 다른 사람에게 설명하기 어려워집니다.

넷째, 나중에 히스토리를 봐도 성장 과정이 보이지 않습니다.

한마디로, 커밋을 늦게 하는 습관은 작업을 뭉개 버립니다. 반대로 적당한 시점에 커밋하면 프로젝트가 계단처럼 보입니다. 한 칸 한 칸 올라간 흔적이 남기 때문입니다.

커밋은 복구 장치이자 성장 로그다

이 장의 핵심 문장을 다시 꺼내 보겠습니다.

커밋은 기록이 아니라 복구 장치이자 성장 로그다.

복구 장치라는 말은 이해하기 쉽습니다. 문제가 생기면 돌아갈 수 있으니까요.

그런데 성장 로그라는 말도 꼭 기억할 가치가 있습니다. 커밋 히스토리를 보면 내가 어떤 순서로 생각했고, 어떤 기능을 먼저 붙였고, 어디에서 막혔는지가 드러납니다. 그 기록은 단지 과거를 보관하는 것이 아니라, 앞으로 더 잘 만들기 위한 자료가 됩니다.

처음에는 커밋 메시지를 쓰는 것이 약간 귀찮게 느껴질 수 있습니다. 하지만 몇 주만 지나도 생각이 바뀝니다. 과거의 내가 남긴 한 줄 메모 덕분에 현재의 내가 길을 잃지 않게 되기 때문입니다.

이때 Git은 단순한 도구를 넘어, 나와 미래의 내가 협업하는 방식이 됩니다.

초보자를 위한 안전한 커밋 루틴

아직 손에 익지 않은 독자를 위해 아주 단순한 루틴을 제안하겠습니다.

작업을 시작하기 전에 오늘 무엇을 바꿀지 한 문장으로 정합니다. 예를 들어 "게시글 목록 화면 만들기"처럼요. 그리고 그 범위 안에서만 작업합니다. 중간에 다른 아이디어가 떠오르면 바로 손대지 말고 메모만 남깁니다.

작업이 끝나면 실행해서 직접 확인합니다. 화면이 보이는지, 버튼이 눌리는지, 기본 기능이 망가지지 않았는지 확인합니다. 그다음 git status로 변경 파일을 봅니다. 내가 의도한 변경이 맞다면 커밋합니다.

마지막으로 커밋 메시지는 "무엇을 바꿨는지"가 바로 보이게 씁니다.

이 루틴이 익숙해지면 개발이 훨씬 차분해집니다. 막연히 "오늘 엄청 많이 했다"가 아니라, "오늘은 여기까지 확실히 만들었다"는 감각이 생깁니다.

오늘부터 바로 써먹는 커밋 메시지 예시

실전에서 자주 쓸 수 있는 예시를 몇 개 남겨 보겠습니다.

• 프로젝트 초기 설정 파일 정리

• 메인 페이지 기본 레이아웃 추가

• 공통 헤더 컴포넌트 생성

• 게시글 목록 더미 데이터 연결

• 상세 페이지 라우팅 적용

• 로그인 페이지 UI 구현

• 회원가입 폼 검증 추가

• 게시글 작성 API 연결

• 글 수정 기능에서 권한 체크 추가

• 검색 결과 없을 때 빈 상태 화면 표시

• 모바일 화면에서 내비게이션 레이아웃 조정

이 예시를 그대로 외울 필요는 없습니다. 중요한 것은 패턴입니다. 어디를, 무엇 때문에, 어떻게 바꿨는지가 떠오르면 됩니다.

잘한 커밋은 자신감을 만든다

커밋 습관이 생기면 이상한 변화가 하나 일어납니다. 개발이 덜 무서워집니다.

예전에는 무언가를 고칠 때마다 "괜히 건드렸다가 더 망가지면 어떡하지?"라는 생각이 먼저 들었다면, 이제는 "일단 지금 상태 커밋해 두고 시도해 보자"라는 쪽으로 마음이 움직입니다. 이것이 바로 초보자가 다음 단계로 넘어갈 때 필요한 감각입니다.

안전하게 기록하는 사람은 더 과감하게 시도할 수 있습니다. 그리고 그 과감함은 무모함이 아니라, 되돌아갈 길을 확보한 상태에서의 실험입니다. AI와 협업할 때도 마찬가지입니다. 커밋이 있으면 실험할 용기가 생기고, 실험이 많아질수록 배우는 속도도 빨라집니다.

다음 장으로 가기 전에

이번 장에서는 저장과 커밋의 차이, 작업 단위를 나누는 감각, 의미 있는 커밋 메시지를 남기는 방법을 배웠습니다. 이제 우리는 단순히 파일을 고치는 사람이 아니라, 변경을 안전하게 남기는 사람이 되기 시작했습니다.

다음 장에서는 한 걸음 더 나아가, 이미 있는 작업을 망치지 않으면서 새로운 수정을 시도하는 방법을 배웁니다. 바로 브랜치와 PR입니다.

커밋이 계단 한 칸을 남기는 일이라면, 브랜치는 다른 길을 안전하게 열어 두는 방법입니다. 이제부터 개발은 더 재미있어질 것입니다.