71.1 버전관리가 대체 뭐예요?
코드를 짜다 보면 이런 순간이 와요. 어제까지 잘 되던 기능이 오늘 갑자기 안 돼요. 그런데 내가 뭘 건드렸는지 기억도 안 나고요. 딱 이럴 때 필요한 게 바로 버전관리(version control, 버전 관리)예요.
버전관리는 쉽게 말해 코드의 변경 이력을 시간 순서대로 저장해두는 시스템이에요. 언제, 누가, 무엇을, 왜 바꿨는지가 전부 기록으로 남죠. 그래서 문제가 터지면 잘 되던 시점으로 되돌아갈 수 있어요.
그중에서도 실무에서 압도적으로 많이 쓰는 도구가 Git(깃)이에요. 리눅스를 만든 사람이 만들었고, 지금은 거의 모든 개발 회사가 이걸 써요. 그러니 코드는 짜는데 Git은 잘 모른다면, 지금이 딱 익힐 때예요.
71.2 파일 이름에 날짜 붙이던 그 시절, 기억나요?
버전관리를 안 써본 사람도 사실 나름의 버전관리를 해요. 보통 이런 식이죠.
프로젝트_최종.zip
프로젝트_최종_진짜최종.zip
프로젝트_최종_이게진짜최종.zip
웃기지만 다들 한 번쯤 해봤죠. 문제는 이 방식이 금방 무너진다는 거예요. 파일이 수십 개가 되면 어떤 게 최신인지 헷갈리고, 두 사람이 같은 파일을 각자 고치면 나중에 합치기가 지옥이에요.
게다가 "3일 전 그 코드로 돌아가고 싶다"거나 "이 한 줄을 누가 바꿨는지 알고 싶다" 같은 건 이 방식으론 아예 불가능해요. Git은 이 모든 걸 명령어 몇 개로 해결해줘요.
71.3 Git은 이 문제를 어떻게 풀까요?
Git의 핵심 개념은 커밋(commit, 저장 단위)이에요. 커밋은 "이 순간의 코드 상태"를 통째로 찍은 스냅샷(snapshot, 사진 같은 저장점)이라고 생각하면 딱 맞아요.
작업을 하다가 의미 있는 단위가 하나 끝나면 커밋을 하나 찍어요. 그러면 그 시점이 영구히 저장되죠. 나중에 언제든 그 커밋으로 돌아갈 수 있어요.
이 커밋들이 시간 순서로 쭉 쌓이면 그게 바로 프로젝트의 역사가 돼요. 각 커밋에는 누가, 언제, 무엇을, 왜 바꿨는지가 메시지와 함께 남고요.
71.4 그래서 뭐부터 시작하면 되나요?
먼저 Git으로 관리할 폴더를 정해요. 그 폴더에서 git init 명령을 딱 한 번만 실행하면 준비 끝이에요.
상황: my-app 폴더를 Git으로 관리하고 싶어요.
$ git init -b main
Initialized empty Git repository in .../my-app/.git/
이러면 폴더 안에 숨겨진 .git 폴더가 생겨요. 여기에 모든 버전 기록이 저장돼요. 이 .git이 들어 있는 곳을 저장소(repository, 줄여서 repo)라고 불러요. -b main은 기본 줄기 이름을 main으로 정해주는 옵션인데, 지금은 그냥 이렇게 쓴다고만 알아두면 돼요.
처음 Git을 쓴다면 내 이름과 이메일도 한 번 등록해요. 커밋에 "누가 했는지"를 남기려면 필요하거든요. 이건 컴퓨터당 한 번만 해두면 계속 쓰여요.
$ git config user.name "kim"
$ git config user.email "[email protected]"
71.5 첫 커밋까지 한번 가볼까요?
이제 파일을 만들고 첫 커밋을 찍어볼게요. 흐름은 항상 작업 → git add → git commit, 이 세 박자예요.
먼저 app.py 파일을 하나 만들었다고 해볼게요. 지금 상태가 궁금하면 git status를 쳐봐요.
$ git status
On branch main
No commits yet
Untracked files:
(use "git add <file>..." to include in what will be committed)
app.py
nothing added to commit but untracked files present
Untracked files는 "Git이 아직 추적하지 않는 파일"이라는 뜻이에요. 새로 만든 파일은 처음엔 다 여기 들어가요. 이걸 Git에게 "이제부터 관리해줘"라고 알려주는 게 git add예요.
$ git add app.py
그다음 git commit으로 스냅샷을 찍어요. -m 뒤에는 무슨 작업을 했는지 메시지를 적어요.
$ git commit -m "feat: add hello function"
[main (root-commit) 06da621] feat: add hello function
1 file changed, 2 insertions(+)
create mode 100644 app.py
드디어 첫 커밋이 찍혔어요. 지나온 기록은 git log로 확인해요.
$ git log
commit 06da6219048d3b5304bf2105e6dc3c3ad631c0fd
Author: kim <[email protected]>
Date: Sat Jul 11 05:54:05 2026 +0900
feat: add hello function
맨 위 영어와 숫자가 뒤섞인 긴 문자열이 이 커밋의 고유 번호(해시, hash)예요. 세상에 하나뿐인 이름표라고 보면 돼요. 보통 앞 7자리(06da621)만 따서 부르는 경우가 많아요.
한 번 더 해볼까요? app.py에 함수를 하나 더 추가하고 다시 add, commit을 하면 커밋이 하나 더 쌓여요.
$ git add app.py
$ git commit -m "feat: add bye function"
[main 67c59b4] feat: add bye function
1 file changed, 3 insertions(+)
이제 git log --oneline으로 보면 기록이 한 줄에 하나씩 짧게 정리돼서 나와요. 커밋이 쌓일수록 이 목록이 곧 프로젝트의 역사가 되는 거예요.
$ git log --oneline
67c59b4 feat: add bye function
06da621 feat: add hello function
커밋을 마친 뒤 git status를 다시 쳐보면 이렇게 나와요.
$ git status
On branch main
nothing to commit, working tree clean
working tree clean(작업 폴더가 깨끗함)은 "고칠 것도, 커밋할 것도 없이 다 저장됐다"는 뜻이에요. 이 문구가 뜨면 마음 놓고 다음 작업으로 넘어가도 돼요. 실무에선 이 상태로 두고 하루를 마치는 게 좋은 습관이에요.
71.6 오늘 배운 걸 정리해볼게요
오늘은 버전관리가 왜 필요한지, 그리고 Git으로 첫 커밋을 찍는 데까지 해봤어요. 핵심만 다시 짚어볼게요.
버전관리는 코드의 변경 이력을 저장하는 시스템이고, 그 실무 표준 도구가 Git이에요. git init으로 저장소를 만들고, git add로 파일을 올린 뒤, git commit으로 스냅샷을 찍어요. 지금 상태가 궁금하면 언제나 git status, 지나온 기록이 궁금하면 git log고요.
이 네다섯 개 명령만 손에 익어도 벌써 절반은 온 거예요. 완벽하게 외우려 하지 말고, 빈 폴더 하나 만들어서 직접 init하고, 파일을 add하고, commit까지 눌러보세요. 눈으로 읽는 것보다 한 번 직접 쳐보는 게 훨씬 오래 남아요. 손이 기억하는 게 제일 빠르거든요.