15장. Git과 GitHub 처음 이해하기
![[3부] Git과 GitHub 처음 이해하기](https://images.tilnote.io/pages/d4259890-3b93-41eb-b145-f9242e8a71bf.webp)
![[3부] Git과 GitHub 처음 이해하기](https://images.tilnote.io/pages/20010e20-c383-496d-8394-8064f8fd5b86.webp)
![[3부] Git과 GitHub 처음 이해하기](https://images.tilnote.io/pages/eb0fba87-1dfe-461a-95a2-b358198ea32a.webp)
코드를 잘 쓰는 사람보다 먼저 필요한 감각
처음 개발을 시작하면 많은 사람이 이렇게 생각합니다. "일단 만들기만 하면 되는 거 아닌가?"
맞는 말입니다. 처음에는 돌아가는 화면 하나를 띄우는 것만으로도 충분히 신납니다. 그런데 서비스를 조금만 손대기 시작하면 곧 무서운 순간이 찾아옵니다. 잘 되던 기능이 갑자기 망가지고, 어제까지 보이던 화면이 오늘은 사라지고, AI에게 "이 부분 정리해줘"라고 맡겼더니 너무 많은 파일이 한꺼번에 바뀌어 버리는 순간이 옵니다.
이때 가장 먼저 필요한 것은 천재적인 코딩 실력이 아닙니다. 망가져도 다시 돌아갈 수 있다는 안전장치입니다.
Git과 GitHub는 바로 그 안전장치를 만들어 주는 도구입니다. 이 장에서는 복잡한 명령어보다 먼저, 왜 이 도구가 필요한지부터 이해해 보겠습니다. 초보자에게는 이 감각이 훨씬 중요합니다. 되돌릴 수 있다는 안심이 있어야 AI와도 과감하게 실험할 수 있기 때문입니다.
왜 버전 관리가 필요한가
문서 작업을 해 본 사람이라면 이런 경험이 있을 겁니다. 파일 이름이 점점 길어집니다.
기획서_최종.docx
기획서_최종진짜.docx
기획서_최종진짜수정본.docx
기획서_최종진짜수정본_진짜마지막.docx
처음에는 웃기지만, 나중에는 어떤 파일이 진짜 최신인지 본인도 헷갈립니다. 개발도 똑같습니다. 오히려 더 복잡합니다. 코드 파일은 서로 연결되어 있어서 한 파일만 따로 보관한다고 해결되지 않는 경우가 많기 때문입니다.
버전 관리란 쉽게 말해 작업의 변화를 시간순으로 안전하게 기록하고, 필요하면 이전 상태로 돌아갈 수 있게 하는 방법입니다.
이 개념이 중요한 이유는 아주 현실적입니다.
첫째, 실수해도 복구할 수 있습니다. 초보자는 실수하면서 배웁니다. 그런데 실수할 때마다 처음부터 다시 만들면 너무 지칩니다.
둘째, 무엇이 바뀌었는지 확인할 수 있습니다. "왜 갑자기 안 되지?"라는 질문 앞에서, 최근에 바뀐 내용을 볼 수 있으면 문제를 훨씬 빨리 찾을 수 있습니다.
셋째, 실험이 쉬워집니다. 새로운 아이디어를 시험해 보고 마음에 안 들면 되돌리면 됩니다. 이 감각은 AI와 협업할 때 특히 중요합니다.
넷째, 다른 사람과 함께 작업하기 쉬워집니다. 지금은 혼자 시작하더라도, 나중에는 디자이너나 개발자, 혹은 미래의 나 자신과 협업하게 됩니다. 버전 관리가 없으면 협업은 금방 혼란스러워집니다.
버전 관리는 단순히 "코드 백업"이 아닙니다. 작업의 흐름을 정리하고, 실수를 두려워하지 않게 만드는 작업 방식입니다.
Git은 무엇인가
Git은 버전 관리를 해 주는 도구입니다.
조금 더 쉬운 말로 하면, 내 컴퓨터 안에서 프로젝트의 변경 이력을 차곡차곡 기록하는 시스템입니다. 파일이 어떻게 바뀌었는지 기억하고, 필요하면 예전 상태를 다시 꺼내 볼 수 있게 해 줍니다.
여기서 중요한 점은 Git이 웹사이트 이름이 아니라는 것입니다. 많은 초보자가 Git과 GitHub를 같은 것으로 생각하는데, 사실 둘은 역할이 다릅니다. Git은 작업 기록을 관리하는 기술이고, GitHub는 그 기록을 올려 두고 함께 활용하는 서비스입니다.
Git을 처음 접할 때는 이렇게 이해하면 충분합니다.
Git은 프로젝트의 시간여행 장치입니다.
지금 상태를 저장해 두었다가, 문제가 생기면 예전 시점으로 돌아갈 수 있습니다. 물론 아무 때나 자동으로 다 저장되는 것은 아니고, 내가 의미 있는 작업 단위마다 기록을 남겨야 합니다. 그 기록 하나하나가 나중에 아주 큰 힘이 됩니다.
예를 들어 이런 상황을 생각해 봅시다.
처음에는 게시글 목록 화면이 잘 보였습니다. 그런데 로그인 기능을 붙이려다가 코드가 꼬였습니다. 화면이 깨지고 에러도 납니다. 이때 Git으로 작업 기록을 남겨 두었다면, "로그인 붙이기 전, 목록 화면이 잘 되던 상태"로 돌아가서 다시 시작할 수 있습니다.
초보자에게 이건 정말 큰 차이입니다. 되돌아갈 수 없는 상태에서 배우는 것은 너무 불안합니다. 반대로 되돌릴 수 있으면, 시도하는 마음이 생깁니다.
GitHub는 무엇인가
GitHub는 Git으로 관리하는 프로젝트를 인터넷에 올려 두는 서비스입니다.
아주 단순하게 말하면, Git이 개인 작업 노트라면 GitHub는 그 노트를 안전하게 보관하고 공유할 수 있는 온라인 공간입니다.
GitHub가 필요한 이유는 여러 가지가 있습니다.
프로젝트를 원격으로 백업할 수 있습니다.
다른 사람과 함께 작업할 수 있습니다.
여러 컴퓨터에서 같은 프로젝트를 이어서 작업할 수 있습니다.
변경 내역을 온라인에서 확인하기 쉽습니다.
배포 도구나 AI 도구와 연결하기 좋습니다.
예를 들어 집에서는 노트북으로 작업하고, 회사나 학교에서는 다른 컴퓨터를 쓴다고 해 보겠습니다. GitHub가 있으면 프로젝트를 온라인에 올려 두고 어디서든 이어서 작업할 수 있습니다.
또 한 가지 중요한 점이 있습니다. 오늘날 많은 개발 도구는 GitHub를 중심으로 연결됩니다. Vercel 같은 배포 도구도 GitHub 저장소와 연결해 자동 배포를 할 수 있고, 협업 도구도 GitHub를 기준으로 움직이는 경우가 많습니다. 즉, GitHub는 단순한 저장소를 넘어 개발 흐름의 중심 역할을 합니다.
Git과 GitHub의 차이, 딱 이 정도만 구분하자
처음에는 둘의 차이를 정확히 말하기 어렵습니다. 그래서 더 헷갈립니다. 하지만 아래 감각만 잡아도 충분합니다.
Git은 내 작업 이력을 관리하는 엔진입니다. GitHub는 그 이력을 올려 두고 공유하는 온라인 공간입니다.
비유해 보면 이렇습니다.
Git은 내가 쓰는 일기장 방식입니다. 언제 무엇을 썼는지, 무엇을 고쳤는지 기록합니다.
GitHub는 그 일기장을 보관하는 클라우드 서랍입니다. 잃어버리지 않게 올려 두고, 필요하면 다른 사람과 함께 볼 수 있습니다.
또 다른 비유도 가능합니다.
Git은 카메라이고, GitHub는 사진을 올려 두는 앨범 서비스입니다. 사진을 찍는 기능과, 저장하고 공유하는 공간은 다르죠. 개발에서도 비슷합니다.
이 차이를 이해하면 나중에 명령어를 배울 때 훨씬 덜 헷갈립니다. "왜 GitHub에 올리기 전에 내 컴퓨터에서 먼저 기록을 남기지?" 같은 질문도 자연스럽게 풀립니다. 기록을 만드는 주체는 Git이고, 그 기록을 올려 두는 곳이 GitHub이기 때문입니다.
저장소라는 말이 자꾸 나오는 이유
Git과 GitHub를 배우다 보면 저장소라는 말을 자주 듣게 됩니다. 영어로는 repository, 줄여서 repo라고 부릅니다.
저장소는 프로젝트 파일과 그 변경 기록을 함께 관리하는 공간입니다.
쉽게 말하면, 내 서비스 하나를 담아 두는 작업 상자라고 생각하면 됩니다. 화면 코드도 들어 있고, 서버 코드도 들어 있고, 설정 파일도 들어 있고, 그 파일들이 어떻게 바뀌었는지도 함께 들어 있습니다.
우리가 앞으로 만들 웹 서비스도 하나의 저장소로 관리하게 됩니다. 그러면 서비스 전체를 한 덩어리로 다룰 수 있습니다. "이 프로젝트의 현재 상태", "어제 상태", "배포 직전 상태" 같은 식으로 흐름을 관리할 수 있는 것이죠.
초보자는 종종 저장소를 단순한 폴더로만 생각합니다. 비슷하지만 완전히 같지는 않습니다. 폴더는 파일을 담는 공간이고, Git 저장소는 파일과 변경 이력까지 함께 관리하는 공간입니다. 겉으로 보기엔 비슷해 보여도, 안에서 하는 일은 훨씬 많습니다.
왜 초보자일수록 Git이 더 필요할까
많은 사람이 Git을 "팀 개발할 때나 쓰는 것"이라고 생각합니다. 하지만 사실은 반대에 가깝습니다. 초보자일수록 Git이 더 절실합니다.
경험이 많은 개발자는 문제가 생겨도 원인을 빨리 좁히고 복구하는 능력이 있습니다. 그러나 처음 배우는 사람은 어디서부터 잘못되었는지 찾는 것 자체가 어렵습니다. 그러니 안전하게 되돌릴 수 있는 장치가 훨씬 중요합니다.
특히 이 책처럼 AI와 함께 개발할 때는 더 그렇습니다. AI는 빠릅니다. 그리고 가끔 너무 빠릅니다. 내가 한 줄만 고쳐 달라고 했는데 관련 파일 여러 개를 한꺼번에 바꿔 버릴 수도 있습니다. 겉보기에는 그럴듯해 보여도 실제로는 다른 기능을 망가뜨릴 수 있습니다.
이럴 때 Git이 없다면 마음이 급해집니다. "방금 뭐가 바뀐 거지?", "원래 코드가 뭐였지?", "이제 어떡하지?"라는 상태가 됩니다.
반대로 Git이 있으면 훨씬 침착해집니다.
"좋아, 일단 바뀐 내용을 보자." "문제가 있으면 이전 상태로 돌아가자." "그다음 AI에게 더 작은 범위로 다시 요청하자."
이 차이가 정말 큽니다. Git은 단지 파일을 지키는 도구가 아니라, 초보자의 멘탈을 지켜 주는 도구이기도 합니다.
AI와 실험할수록 버전 관리가 중요해진다
AI 코딩 도구의 가장 큰 장점은 시도를 빠르게 만들어 준다는 점입니다. 예전에는 검색하고, 문서를 읽고, 코드를 붙여 넣고, 다시 고치느라 오래 걸리던 작업을 지금은 훨씬 짧은 시간에 해볼 수 있습니다.
문제는 시도가 빨라진 만큼, 망가지는 속도도 빨라졌다는 것입니다.
예를 들어 이런 일이 생길 수 있습니다.
디자인만 바꾸려 했는데 데이터 불러오는 부분까지 건드려졌다.
로그인 기능을 추가했더니 기존 작성 기능이 안 된다.
AI가 리팩터링을 해 주었는데 파일 구조가 너무 크게 변했다.
잘 되던 코드가 갑자기 다른 방식으로 바뀌어 이해가 어려워졌다.
이때 버전 관리가 되어 있으면 AI는 훨씬 강력한 도우미가 됩니다. 마음 놓고 시도해 볼 수 있기 때문입니다. "실패하면 되돌리면 된다"는 전제가 있으면 질문도 더 과감해지고, 비교 실험도 쉬워집니다.
예를 들어 같은 기능을 두 가지 방식으로 만들어 보고 싶을 수 있습니다. 하나는 단순한 방식, 다른 하나는 조금 더 세련된 방식입니다. 버전 관리가 없다면 이런 비교 자체가 부담스럽습니다. 원래 상태를 잃어버릴까 봐 두렵기 때문입니다. 하지만 Git이 있으면 한 단계씩 기록해 두면서 비교할 수 있습니다.
이 감각은 앞으로 책 전체에서 계속 중요합니다. AI를 잘 쓰는 사람은 무턱대고 크게 맡기는 사람이 아니라, 되돌릴 수 있는 구조 안에서 똑똑하게 실험하는 사람입니다.
Git이 해결해 주는 아주 현실적인 문제들
Git이 추상적인 개념처럼 느껴질 수 있으니, 초보자가 자주 겪는 장면으로 바꿔 보겠습니다.
첫 번째 장면입니다. 어제는 되던 코드가 오늘 안 됩니다.
보통 이런 일이 생기면 사람은 기억에 의존합니다. "아마 로그인 파일을 만진 뒤부터였나?" 그런데 개발에서는 기억이 자주 틀립니다. Git이 있으면 최근 무엇이 바뀌었는지 확인하면서 추적할 수 있습니다.
두 번째 장면입니다. AI가 고쳐 준 뒤 더 망가졌습니다.
이때 가장 무서운 것은 원래 상태를 잃어버리는 것입니다. Git으로 이전 상태가 남아 있으면, 과감하게 롤백하고 다시 시도할 수 있습니다. 롤백은 이전의 안정된 상태로 되돌리는 것을 뜻합니다.
세 번째 장면입니다. 노트북이 고장 나거나 파일을 잘못 지웠습니다.
GitHub에 올려 두었다면 프로젝트를 다시 내려받아 이어서 작업할 수 있습니다. 몇 주 작업이 한순간에 사라지는 비극을 줄여 줍니다.
네 번째 장면입니다. 기능 하나를 추가하다가 전체가 흔들립니다.
작업 단위를 나누어 기록해 두면, 어느 단계까지는 안전했는지 확인할 수 있습니다. 문제를 좁혀 가는 것이 훨씬 쉬워집니다.
즉, Git과 GitHub는 개발을 더 멋있게 만드는 도구라기보다, 덜 망하게 만드는 도구에 가깝습니다. 초보자에게는 그게 훨씬 중요합니다.
Git을 쓰면 생기는 좋은 습관
Git은 단순한 프로그램이 아니라 생각하는 방식을 바꿉니다. Git을 쓰기 시작하면 자연스럽게 작업을 작은 단위로 나누게 됩니다.
예를 들어 "오늘 프로젝트 다 만들기"처럼 뭉뚱그려 작업하는 대신, "헤더 만들기", "로그인 폼 만들기", "게시글 목록 연결하기"처럼 나눠 생각하게 됩니다. 이렇게 하면 AI에게도 훨씬 정확하게 요청할 수 있습니다.
또 Git을 쓰면 작업의 이유를 설명하는 습관이 생깁니다. 무엇을 왜 바꿨는지 정리해야 나중에 내가 봐도 이해가 되기 때문입니다. 이 습관은 코드 실력과 별개로 매우 중요합니다. 개발은 결국 변경의 역사이기 때문입니다.
게다가 Git을 쓰면 완벽주의를 조금 내려놓게 됩니다. 처음부터 완벽하게 만들 필요가 없습니다. 한 단계씩 바꾸고, 기록하고, 확인하면 됩니다. 잘못되면 돌아오면 됩니다. 이 태도는 초보자에게 큰 힘이 됩니다.
GitHub는 단순 저장소가 아니라 협업의 무대다
혼자 만드는 서비스라도 GitHub를 쓰는 순간, 프로젝트는 조금 더 서비스답게 관리되기 시작합니다.
왜냐하면 GitHub는 단순히 파일을 올려 두는 공간이 아니라, 작업을 보여 주고 나누고 검토하는 공간이기 때문입니다. 앞으로 배울 브랜치와 PR도 결국 GitHub에서 빛을 발합니다. 지금은 자세히 알 필요 없지만, 큰 그림 정도는 알아 두면 좋습니다.
혼자 작업할 때도 GitHub는 유용합니다. 미래의 내가 현재의 나와 협업하기 때문입니다. 일주일 뒤의 나는 지금 작성한 코드를 남의 코드처럼 낯설게 볼 가능성이 큽니다. GitHub에 기록이 잘 남아 있으면 "왜 이걸 바꿨는지", "어느 시점부터 기능이 들어갔는지"를 훨씬 쉽게 따라갈 수 있습니다.
그리고 누군가의 도움을 받을 때도 GitHub는 큰 역할을 합니다. 문제가 생겼을 때 저장소를 보여 주면, 다른 사람이 구조를 파악하고 조언하기 쉬워집니다. AI에게도 전체 맥락을 설명할 때 훨씬 유리합니다.
지금 당장 외워야 할 최소 개념
아직 명령어를 몰라도 괜찮습니다. 이 장에서 꼭 가져가야 할 것은 몇 가지 핵심 감각입니다.
Git은 내 컴퓨터에서 프로젝트 변경 이력을 관리하는 도구다.
GitHub는 그 프로젝트를 온라인에 올려 두고 공유하는 서비스다.
버전 관리는 실수를 막는 것이 아니라, 실수해도 회복할 수 있게 해 준다.
되돌릴 수 있다는 안심이 있어야 AI와 과감하게 실험할 수 있다.
초보자일수록 버전 관리가 더 필요하다.
이 다섯 가지만 이해해도 오늘 장의 목적은 거의 달성한 셈입니다.
개발은 잘 만드는 일인 동시에, 안전하게 만드는 일이다
처음 서비스를 만들 때 사람들은 화면과 기능에만 집중합니다. 물론 그것도 중요합니다. 하지만 실제 개발에서는 "안전하게 바꿀 수 있는가"도 그만큼 중요합니다.
Git과 GitHub는 바로 그 안전함을 담당합니다. 내가 어떤 코드를 쓰는 사람인지보다 먼저, 어떤 방식으로 작업을 남기고 되돌릴 수 있는 사람이 되는지가 중요합니다.
이 감각이 생기면 개발이 훨씬 덜 무섭습니다. 기능 추가도, 디자인 수정도, AI에게 큰 변경을 맡기는 일도 전보다 덜 부담스러워집니다. 내 뒤에는 기록이 있고, 필요하면 돌아갈 수 있기 때문입니다.
결국 Git과 GitHub를 배우는 이유는 단순합니다. 더 대담하게 만들기 위해서입니다. 무모하게 하자는 뜻이 아닙니다. 안전망이 있으니 더 멀리 시도해 볼 수 있다는 뜻입니다.
다음 장으로 가기 전에
이 장에서는 Git과 GitHub가 왜 필요한지, 둘이 무엇이 다른지 감각적으로 이해하는 데 집중했습니다. 아직 손에 익지 않아도 괜찮습니다. 중요한 것은 "버전 관리가 개발의 기본 체력"이라는 사실을 받아들이는 것입니다.
다음 장에서는 이 안전장치를 실제로 어떻게 남기는지 살펴봅니다. 작업을 기록으로 남기는 가장 기본 동작, 즉 저장과 커밋을 배워 보겠습니다.
서비스를 만드는 사람에게 커밋은 단순한 저장 버튼이 아닙니다. 작업의 의미를 남기는 첫 습관입니다.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.