이런 경험, 있으신가요?
기획서나 제안서를 여러 번 고치다 보면, 어느 순간 파일이 이렇게 쌓여 있죠.
- 제안서_최종
- 제안서_최종_v2
- 제안서_진짜진짜최종
분명 전부 내가 만든 파일인데, 막상 열어 보려고 하면 "어? 진짜 최신이 뭐였더라?" 하고 멈칫하게 돼요.
또, 여러 명이서 일할 때 내가 한참 공들여 작업한 문서를 수정했는데, 다른 사람이 동시에 수정하는 바람에 내 수정사항이 통째로 날라가기도 합니다. 🫠
이건 비개발 직군만 겪는 일이 아니에요. 개발도 결국엔 '코드'가 적힌 문서 파일을 함께 작성해 나가는 일입니다. 그래서 개발할 때에도 똑같은 문제를 겪어요. 예를 들어 개발자 A가 새 기능을 만들어서 코드 파일을 B에게 넘기면 B는 그 파일을 받아서 버그를 고칩니다. 이렇게 주고받다 보면 결국 누가 뭘 바꿨는지 알 수 없게 되고, 서로의 수정사항이 의도치 않게 사라지기도 해요.
이렇게 "파일이 뒤엉키는 문제"를 깔끔하게 풀려고 만든 도구가 바로 Git이에요.
여기서 용어를 살짝만 이야기하고 넘어가 볼게요!
이렇게 수정사항이 서로 부딪히는 걸 개발자들은 충돌(conflict), 여러 개발자가 따로 진행한 작업을 하나로 합치는 걸 병합(merge)이라고 불러요. 말로만 들으면 와닿지 않으니, 개발자들이 회의나 메신저에서 실제로 어떻게 쓰는지 예를 들어보겠습니다.
🗣️ "이거 머지해 주세요"
'머지'가 병합(merge)이에요. 따로따로 작업한 코드를 하나로 합쳐 달라는 뜻이죠. 사실 합치는 건 대부분 컴퓨터가 알아서 척척 해줘요.
🗣️ "앗, 컨플릭 났어요"
여기서 '컨플릭'은 충돌(conflict)을 의미해요. 개발자 A가 작성한 코드와 개발자 B가 작성한 코드를 병합(merge)하려고 하는데 동일한 줄을 서로 다르게 고쳐 수정사항이 충돌이 난거죠. 그래서 컴퓨터가 "둘 중에 뭘 살려야 할지 모르겠어요" 하며 merge를 하다말고 멈춰 선 상태를 말해요. 그러면 둘 중 누군가가 "어느 쪽이 맞는지" 직접 골라 줘야 이어서 merge가 진행돼요.
두 단어는 다음에 더 자세하게 풀어 볼 테니, 지금은 "아, 이런 말을 이런 뜻으로 쓰는구나" 정도면 충분해요. 그리고 이렇게 변경 이력을 차곡차곡 관리하는 일을 있어 보이는 말로 버전 관리(version control)라고 한답니다. 😎
파일 변경을 기록하는 도구, Git ✨
Git을 한마디로 하면, 파일이 어떻게 바뀌었는지를 기록해 두는 도구예요.
내 컴퓨터에 있는 파일을 고친 다음, "이번엔 이런 걸 바꿨어요"라고 Git에 기록해 둘 수 있어요. 그 기록에는 이런 정보가 담겨요.
- 뭐가 바뀌었는지 — 어떤 내용이 더해지고, 지워지고, 고쳐졌는지
- 누가 바꿨는지 — 이 변경을 한 사람이 누구인지
- 언제 바꿨는지 — 정확한 날짜와 시간
- 왜 바꿨는지 — 그 사람이 직접 남긴 설명 메시지
Git은 내가 파일을 고친다고 자동으로 저장해 주지 않아요. 내가 "여기까지 했으니 기록해 두자" 하고 직접 표시하는 순간, 그 시점이 기록 하나로 남죠. 이 "기록 하나 남기기"를 커밋(commit)이라고 불러요. 커밋은 게임의 세이브 포인트랑 비슷해요! 내가 '저장'을 누른 순간 저장이 되잖아요? 커밋도 똑같아요! 그리고 커밋을 할 때 이 작업을 왜 했는지도 간략한 메시지를 함께 남깁니다.
이렇게 남겨 두면 나중에 "누가, 언제, 무엇을, 왜 바꿨는지"를 그대로 다시 확인할 수 있어요. 예를 들면 "아, 철수가 2026년 6월 3일 12:30에 로그인 기능을 추가했네" 하고 콕 집어낼 수 있는 거죠.
게다가 실수로 코드를 지워 버렸더라도, 특정 세이브 포인트를 불러오듯 특정 커밋을 한 시점으로 쉽게 되돌릴 수 있어요. 단, 되돌아갈 수 있는 곳은 어디까지나 '내가 커밋해 둔 지점'까지예요. 그러니 평소에 틈틈이 커밋해 두는 게 중요하겠죠?
| 상황 | Git이 없으면 | Git이 있으면 |
|---|---|---|
| 파일 변경 추적 | 파일_v1, 파일_v2, 파일_최종… 일일이 손으로 관리 | 내가 기록(커밋)한 시점마다 변경이 차곡차곡 쌓임 |
| 누가 뭘 했나? | "어? 이 코드가 왜 여기 있지?" | "철수가 2024-06-03 12:30에 추가함" |
| 파일을 망쳤을 때 | 예전 파일을 직접 뒤져서 찾기 | 기록(커밋)을 보고 특정 상태로 되돌리기 |
| 팀원과 협업 | 손으로 일일이 합치다 충돌 지옥 | 체계적으로 합치고(merge), 부딪히는 부분(conflict)을 감지 |
| 어떤 코드가 버그의 원인? | "누가 이 코드를 쓴 거죠?" | "철수가 언제, 왜 이 코드를 넣었는지" 추적 |
그럼 GitHub은 뭐죠?
Git과 GitHub은 이름이 비슷하지만 같은 게 아니에요.
Git은 내 컴퓨터에서 변경을 기록하는 도구고, GitHub은 그 기록을 인터넷에 올려 팀과 함께 보는 사이트입니다.
(GitHub과 비슷한 서비스로 GitLab도 있어요. 둘은 역할이 거의 같으니, 이 글에서는 편하게 'GitHub'으로 부를게요.)
- 내 컴퓨터 = 내 손으로 직접 파일을 고치는 곳이에요. 내 컴퓨터에 있는 파일은 나만 볼 수 있어요 🎤
- GitHub = 구글드라이브처럼 인터넷에 올려 두고, 팀과 함께 보는 곳이에요.
개발자들은 위의 개념들을 조금 다른 용어로 아래와 같이 사용하기도 해요!
🗣️ "로컬에서 먼저 해 볼게요"
'로컬(local)'이 바로 내 컴퓨터라는 뜻이에요. 즉, 자신의 컴퓨터에서만 먼저 해본다는 뜻이죠.
🗣️ "리모트에 올렸어요"
'리모트(remote)', 우리말로는 원격 저장소라고도 불리는데, 이것이 바로 GitHub을 의미해요. 로컬(자신의 컴퓨터)에서 작업을 마친 뒤 다른 사람들도 볼 수 있게 깃헙에 올렸다는 뜻입니다.
정리해보자면 로컬(내 컴퓨터)에서 작업 후 Git으로 기록을 남기고 GitHub(인터넷)에 올려서 팀원들과 공유합니다.
1. 내 컴퓨터(로컬)에서 코드를 고쳐요.
2. Git에 "이렇게 바꿨어요" 하고 기록(commit)해요.
3. 변경된 코드와 기록(commit)을 GitHub에 올려요. 이 올리는 동작을 푸시(push)라고 해요.
4. 팀원들이 인터넷에서 그걸 봐요. "아, 영희가 이 부분을 이렇게 바꿨구나!"
5. 팀원들도 자기 컴퓨터로 받아 가서 이어서 작업해요. 코드를 받아가는 동작을 풀(pull)이라고 해요.
회사에서는 하나의 프로젝트만 진행하지 않고 여러 프로젝트가 동시에 진행되죠! 이 프로젝트를 모두 하나의 폴더에 넣어두면 어떤 프로젝트를 위한 코드인지 헷갈리기 쉬워요. 그래서 GitHub에 올릴 땐 프로젝트마다 폴더를 따로 나눠 두는데, 이 프로젝트 단위 폴더 하나를 레포(Repository, 저장소)라고 불러요.
이때 GitHub에 올라가는 건 '변경 기록'만이 아니에요. 프로젝트의 코드 전체가 '누가·언제·뭘·왜 바꿨는지' 이력과 함께 통째로 올라가요. 그래서 지금의 최신 코드도, 과거의 모든 버전도 인터넷에 안전하게 보관되죠. 내 컴퓨터가 고장 나더라도, 심지어 불이 나더라도 github에만 올려두면 안전하게 작업 내용을 보관할 수 있기 때문에 이런 짤이 돌아다니기도 했어요 😂
오늘 나온 용어, 한눈에 복습 📒
지금까지 여러 단어가 스쳐 지나갔죠. 동료와 대화할 때 바로 떠오르도록, 오늘 나온 말들을 한번 되짚어보아요!
- Git — 내 컴퓨터에서 "뭐가·누가·언제·왜 바뀌었는지"를 기록하는 도구.
- GitHub (= 원격 저장소) — 그 기록과 코드 전체를 인터넷에 올려 팀과 함께 보는 공간.
- 로컬 / 리모트 — '로컬'은 내 컴퓨터, '리모트(원격)'는 인터넷에 있는 GitHub
- 레포(Repository) — GitHub 안에서 프로젝트별로 나눠 둔 폴더.
- 커밋(Commit) — "이 순간을 기록!" 하고 코드 작성자가 직접 남기는 변경 기록.
- 푸시(Push) / 풀(Pull) — '푸시'는 커밋을 GitHub에 업로드하기. '풀'은 GitHub에 올라온 변경을 내 컴퓨터로 다운받기.
- 충돌(Conflict) / 병합(Merge) — '병합'은 서로 다른 사람이 작업한 걸 코드를 하나로 합치기. '충돌'은 같은 곳을 서로 다르게 고쳐 합치다 멈춘 상태.
🚀 다음에는...
지금까지 Git이 왜 필요한지, 뭘 하는 도구인지 큰 그림을 잡았어요.
다음 편에서는 브랜치(Branch)에 대해 알아볼 거예요. 혼자서든 여럿이서든, 여러 작업을 서로 방해하지 않고 동시에 진행하는 방법이랍니다. 오늘 살짝 알아본 충돌(conflict)도 조금 더 자세하게 이야기해 보겠습니다!
오늘 나온 개념 중에 "이건 좀 아리송한데?" 싶은 게 있다면, 편하게 댓글로 남겨 주세요. 어려운 용어 같이 쉽게 풀어 봐요. 🙌
'개발' 카테고리의 다른 글
| GPT가 엉뚱한 답변을 만드는 이유와 해결 방법 [#2 언제나 어디에나 뉴비는 있다] (0) | 2026.04.27 |
|---|---|
| GPT가 제 말을 어떻게 이해하나요? - [#1 언제나 어디에나 뉴비는 있다] (0) | 2026.04.24 |
