01 / 15
SESSION 14 · Part 4 개발 환경

Git이란?

코드의 시간 여행자 — 버전 관리의 세계

02 / 15
🎯

이 세션에서
배우는 것

❓
왜 Git인가
버전 관리가 왜 필요한지 스스로 설명할 수 있다
📸
기본 흐름
init → add → commit → log의 사이클을 이해한다
🌿
브랜치
브랜치가 무엇이며 왜 쓰는지 말할 수 있다
03 / 15
💭

왜 버전 관리가
필요할까?

✕ Git 없는 세계
report_최종.docx
report_최종_진짜.docx
report_최종_진짜_v2.docx
어제 코드로 되돌릴 수 없음
✓ Git 있는 세계
모든 변경이 스냅샷으로 저장
언제든 과거 시점으로 복원
누가, 언제, 왜 바꿨는지 추적
여러 명이 동시에 협업 가능
04 / 15

Git은 분산 버전 관리 시스템

2005년, 리눅스 창시자 리누스 토르발스가 만들었다.
오늘날 전 세계 대부분의 개발팀이 쓰는 사실상의 표준.

📸
스냅샷 저장
변경 사항을 커밋이라는 단위로 보관
🔄
분산 구조
모든 사람의 PC에 전체 이력이 복사됨
🌿
브랜치 지원
독립된 작업 공간에서 실험 후 합치기
05 / 15
🗂️

Git의 3가지 영역 —
더 깊게 이해하기

커밋이 되기까지 코드는 세 단계의 공간을 거친다.

1
작업 공간 (Working Directory)
실제 파일을 수정하는 공간. 아직 Git이 추적하지 않는 "날 것" 상태의 변경이다.
2
스테이징 영역 (Staging Area)
git add로 커밋할 파일을 선택해 올려두는 대기 공간. "이번 커밋에 담을 내용"을 고른다.
3
저장소 (Repository)
git commit으로 스냅샷이 영구 저장되는 공간. 이력이 쌓이고 언제든 되돌아올 수 있다.
+
왜 스테이징이 필요한가?
10개 파일을 바꿨어도 3개만 이번 커밋에 포함할 수 있다. 논리적 단위로 이력을 깔끔하게 유지한다.
06 / 15
🔄

Git의 기본 흐름

이 네 단계만 알면 매일 쓸 수 있다.

📁 git init
저장소 생성
→
✏️ 파일 수정
Working
→
➕ git add
Staging
→
💾 git commit
저장

예: git commit -m "로그인 버그 수정" — 메시지와 함께 시간 여행 지점을 기록한다.

07 / 15
🌿

브랜치와 병합 —
실제로는 어떻게?

새 기능을 안전하게 개발하고 메인에 합치는 전형적인 흐름.

🌿 브랜치 생성
feature/login
→
💾 여러 커밋
독립 작업
→
🔀 main에 merge
병합
→
✅ 완료
브랜치 삭제

핵심: main은 항상 안정적으로 유지하고, 실험은 브랜치에서 — 실패해도 브랜치만 버리면 된다

08 / 15

브랜치 — 병렬 우주

메인 코드를 건드리지 않고 독립된 작업 공간에서 실험한다.

1
main 브랜치에서 출발
현재 안정적으로 동작하는 코드 — 아무도 깨뜨리면 안 되는 줄기.
2
새 브랜치 생성 — feature/login
새 기능을 개발할 독립 공간. main은 그대로 유지된다.
3
자유롭게 커밋
브랜치에서 여러 번 커밋해도 main에는 영향이 없다.
4
병합 (merge)
완성되면 main으로 합친다. 실패하면 그냥 브랜치를 버리면 된다.
09 / 15
📱

실생활에서
이렇게 쓰여요

우리가 매일 사용하는 앱과 서비스 속에 이 개념이 녹아 있다.

🐙
GitHub 오픈소스 기여
전 세계 개발자들이 Git으로 협업해 Linux, React, VS Code 같은 도구를 함께 만든다
👥
팀 프로젝트 코드 관리
5명이 동시에 같은 프로젝트를 개발해도 코드가 충돌 없이 관리된다
⏮️
"어제 버전으로 되돌리기"
배포 후 버그 발견 시 이전 커밋으로 즉시 롤백해 서비스를 복구한다

💡 이 개념이 없다면 팀으로 개발하는 것이 불가능에 가까워진다

10 / 15
💡

자주 하는
오해 바로잡기

이렇게 생각하기 쉽지만, 실제로는 조금 다릅니다.

❌ 흔한 오해
  • Git과 GitHub는 같은 것이다
  • 커밋은 자동 저장이다
  • 브랜치는 파일의 복사본이다
✓ 실제로는
  • Git은 도구(소프트웨어), GitHub는 Git을 호스팅하는 서비스다
  • 커밋은 의도적인 스냅샷이다. 직접 실행해야 저장된다
  • 브랜치는 포인터(참조)다. 파일을 복사하지 않아 가볍다
11 / 15
🎮

Git은 게임의 세이브 포인트

복잡한 개념도 익숙한 비유로 풀어보자.

🕹️ 게임 비유
세이브 포인트
=
커밋(commit) — 원하는 시점에 저장
불러오기
=
checkout/reset — 과거 커밋으로 돌아가기
다른 엔딩 시도
=
브랜치(branch) — 메인 스토리를 망치지 않고 실험
플레이 기록
=
git log — 언제 무엇을 했는지 히스토리
12 / 15
🤖

이걸 알면
AI와 이렇게 대화해요

이 개념을 이해하면 Claude나 ChatGPT를 훨씬 잘 활용할 수 있다.

👤
Git에서 실수로 파일을 삭제했어요.
🤖
어떤 상황인지 조금 더 알려주시면 정확히 도움드릴 수 있어요.
👤
3일 전 커밋에 있던 login.js 파일을 실수로 삭제하고 커밋했어요. git 명령어로 그 파일만 이전 커밋에서 복구하는 방법 알려줘.
🤖
git log --oneline으로 3일 전 커밋 해시를 찾은 뒤, git checkout [해시] -- login.js 를 실행하면 그 파일만 복원됩니다. 이후 git add, git commit으로 저장하세요.
13 / 15
✅

이렇게
이해하셨나요?

✅
맞게 이해하셨어요
커밋은 코드 변경의 스냅샷이며, 의도적으로 실행해야 저장된다
❌
이렇게는 아니에요
Git 없이는 팀 개발이 불가능하다 — 불편할 뿐이지 이메일로 파일을 주고받는 방식도 가능은 하다
✅
맞게 이해하셨어요
브랜치는 독립된 작업 공간이며, main을 안전하게 유지하면서 실험할 수 있다
❌
이렇게는 아니에요
Git과 GitHub는 같은 것이다 — Git은 도구, GitHub는 Git을 호스팅하는 서비스다

💪 Git을 이해하면 혼자든 팀이든 코드를 훨씬 안전하게 관리할 수 있습니다!

14 / 15
📌

핵심 정리

📦
repository
프로젝트의
모든 이력 저장소
💾
commit
변경 사항을
스냅샷으로 저장
➕
add
커밋할 파일을
스테이징
📜
log
커밋 이력을
확인
🌿
branch
독립된
작업 공간
🔀
merge
브랜치를
합치기
15 / 15
🚀

다음 세션
Session 15 · GitHub와 협업

내 PC의 Git 저장소를 인터넷에 올려 세계와 협업하는 플랫폼.
push · pull · Pull Request — 오픈소스의 중심지로 떠난다.

💡 기억할 것: Git은 코드의 타임머신이다.

슬라이드 목록