비개발자를 위한 IT 상식 #5 Git과 버전 관리 — 여러 명이 한 코드를 고치는 법

2026년 4월 21일 화요일

5 분 소요

지난 글에서 새 배포가 문제를 일으키면 직전의 정상 버전으로 되돌리는 롤백을 이야기했습니다. 그러면서 질문 하나를 남겼습니다. 되돌릴 이전 버전은 대체 어디에 보관돼 있을까요. 그리고 여러 명의 개발자가 같은 코드를 동시에 고치는데, 어떻게 서로의 작업을 덮어쓰지 않을까요.

이 두 질문의 답이 바로 Git과 버전 관리입니다. 개발자들이 하루에도 수십 번 “커밋했어요”, “푸시했어요”, “머지 충돌났어요”, “PR 리뷰해 주세요"라고 말하는 그 이야기입니다. 시리즈의 마지막인 이번 글에서는 Git이 무엇이고 왜 모든 개발팀이 이것을 쓰는지 살펴보겠습니다.

이번 시리즈는 비개발자를 위한 IT 상식 5편으로 구성됩니다.

#1 웹사이트는 무엇으로 이루어지는가 — 프론트엔드,백엔드,데이터베이스
#2 API란 무엇인가 — 서비스끼리 대화하는 약속
#3 서버, 클라우드, 그리고 배포
#4 버그, 핫픽스, 롤백 — 개발자가 장애에 대응하는 법
#5 Git과 버전 관리 — 여러 명이 한 코드를 고치는 법 ← 이번 글

버전 관리는 변경 이력을 체계적으로 남기는 것입니다 #

문서를 만들다가 “기획서_최종.docx”, “기획서_최종_진짜최종.docx”, “기획서_최종_v3.docx"처럼 파일을 늘려 본 경험이 있을 것입니다. 어느 것이 진짜 최신인지 헷갈리고, 어제 지운 문장을 다시 살리고 싶어도 방법이 마땅치 않습니다.

코드는 이보다 훨씬 복잡합니다. 파일이 수백 개에 이르고, 여러 명이 동시에 고칩니다. 그래서 누가 언제 무엇을 왜 바꿨는지를 자동으로 기록하고, 원하는 시점으로 언제든 되돌릴 수 있게 하는 방법이 필요합니다. 이것이 버전 관리입니다.

Git은 코드의 변경 이력을 관리하는 도구입니다 #

Git은 오늘날 가장 널리 쓰이는 버전 관리 도구입니다. 코드가 바뀔 때마다 그 변경을 기록으로 남기고, 누가 어떤 부분을 어떻게 고쳤는지 추적합니다. 그리고 필요하면 과거의 어떤 시점으로든 되돌릴 수 있습니다.

지난 글에서 본 롤백이 가능한 것도 바로 이 때문입니다. Git이 변경 이력을 차곡차곡 쌓아 두기 때문에, 문제가 생긴 새 버전을 거두고 직전의 멀쩡했던 버전으로 빠르게 돌아갈 수 있습니다. 버전이 기록돼 있지 않다면 되돌릴 곳도 없습니다.

커밋은 변경을 한 묶음으로 저장하는 단위입니다 #

Git에서 변경을 저장하는 기본 단위를 커밋이라고 부릅니다. 의미 있는 변경 하나를 묶어서, “로그인 버그 수정"처럼 짧은 설명과 함께 저장하는 것입니다. 사진을 찍어 그 순간을 남기듯, 커밋은 코드의 특정 순간을 기록으로 남깁니다.

이 커밋이 시간순으로 쌓인 것이 곧 변경 이력입니다. “푸시했어요"라는 말은 자기 컴퓨터에 쌓은 커밋을 모두가 공유하는 곳에 올렸다는 뜻입니다. 롤백은 이렇게 쌓인 커밋 중 문제가 생기기 전의 한 시점으로 되돌아가는 일입니다.

브랜치와 병합으로 여러 명이 동시에 일합니다 #

여러 명이 같은 코드를 동시에 고치면 서로의 작업이 부딪힐 수 있습니다. Git은 브랜치라는 방법으로 이 문제를 풉니다.

브랜치는 메인 브랜치에서 갈라져 나온 작업용 갈래입니다. 각 개발자는 자기 브랜치에서 다른 사람을 신경 쓰지 않고 마음껏 작업합니다. 그리고 작업이 끝나면 그 변경을 메인 브랜치에 합치는데, 이것을 병합 또는 머지라고 부릅니다. “머지 충돌났어요"라는 말은 두 사람이 같은 부분을 서로 다르게 고쳐서, 둘 중 무엇을 택할지 사람이 직접 정리해야 하는 상황을 뜻합니다.

GitHub는 함께 작업하는 온라인 공간입니다 #

여기서 Git과 GitHub를 구분할 필요가 있습니다. Git은 변경을 관리하는 도구이고, GitHub는 그 Git 저장소를 온라인에 두고 여러 명이 함께 작업하도록 돕는 서비스입니다. 도구와 그 도구를 쓰는 공간의 관계라고 생각하면 됩니다.

GitHub에서 자주 등장하는 말이 PR, 즉 풀 리퀘스트입니다. “내가 만든 변경을 메인 브랜치에 합쳐 달라"고 올리는 요청입니다. 동료들은 이 요청에 담긴 변경을 살펴보고 의견을 남기는데, 이 과정을 코드 리뷰라고 합니다. 리뷰를 통과하면 비로소 변경이 병합됩니다. 곧바로 합치지 않고 한 번 더 확인하는 이 절차가 실수를 크게 줄여 줍니다.

왜 비개발자가 알면 일이 편해지는가 #

Git의 큰 그림을 알면 개발팀의 일하는 방식이 보입니다.

개발 대화를 따라갈 수 있습니다. “커밋했어요”, “PR 올렸어요”, “머지하고 배포할게요” 같은 말이 작업이 어디까지 왔는지를 알려 주는 신호로 들립니다.
“아직 운영엔 없어요"를 이해할 수 있습니다. “그 기능은 다른 브랜치에서 작업 중이라 아직 합쳐지지 않았어요"라는 말은, 만들고 있지만 메인 브랜치에 병합되지도 배포되지도 않았다는 뜻입니다.
버전 관리는 개발만의 것이 아닙니다. 누가 언제 무엇을 바꿨는지 남기고 되돌리는 발상은 디자인 파일이나 문서 작업에도 그대로 쓸모가 있습니다.

시리즈를 마치며 #

다섯 편에 걸쳐 비개발자가 알면 좋은 IT 상식을 살펴봤습니다.

#1에서 웹사이트가 프론트엔드, 백엔드, 데이터베이스로 이루어진다는 것을 봤습니다.
#2에서 그 층들이 API라는 약속으로 대화한다는 것을 봤습니다.
#3에서 백엔드가 서버와 클라우드 위에서 돌아가고, 배포로 사용자에게 공개된다는 것을 봤습니다.
#4에서 문제가 생기면 핫픽스와 롤백으로 대응한다는 것을 봤습니다.
#5에서 그 모든 변경이 Git으로 기록되고 관리된다는 것을 봤습니다.

이 단어들을 직접 다룰 일은 없더라도, 뜻을 알고 있는 것만으로 개발자와의 대화가 한결 또렷해집니다. 회의에서 오가는 말이 들리고, 일정이 왜 그렇게 잡히는지 납득되고, 장애가 터졌을 때 상황을 차분히 읽을 수 있습니다. 이 시리즈가 개발자와 함께 일하는 모든 분께 조금이나마 도움이 되었으면 합니다.