코딩 공부를 시작하면 어느 순간 Git과 GitHub라는 말을 정말 자주 만나게 됩니다. 강의에서도 나오고, 개발자 포트폴리오를 검색해도 나오고, 취업 준비 글을 봐도 GitHub 주소를 정리하라는 이야기가 빠지지 않습니다. 그런데 처음에는 이 둘이 정확히 무엇인지 잘 와닿지 않습니다.
저도 처음에는 Git과 GitHub를 거의 같은 의미로 생각했습니다. 둘 다 코드를 올리는 곳이라고만 이해했는데, 공부하다 보니 역할이 다르다는 걸 알게 됐습니다. 쉽게 말하면 Git은 내 코드의 변경 기록을 관리하는 도구이고, GitHub는 그 코드를 온라인에 저장하고 공유할 수 있는 서비스입니다.
처음부터 어렵게 생각할 필요는 없습니다. Git과 GitHub는 개발자가 코드를 더 안전하게 관리하고, 나중에 다시 돌아볼 수 있게 도와주는 도구입니다. 혼자 공부하는 입문자에게도 중요하고, 팀으로 일하는 개발자에게는 거의 필수에 가깝습니다.
Git은 코드의 변경 기록을 남기는 도구
Git을 가장 쉽게 이해하려면 문서 작업을 떠올리면 됩니다. 과제를 하거나 보고서를 쓸 때 파일 이름을 이렇게 저장해본 적이 있을 겁니다. 최종.docx, 최종수정.docx, 진짜최종.docx, 진짜최종2.docx처럼 말입니다. 처음에는 괜찮아 보이지만 시간이 지나면 어떤 파일이 진짜 최신인지 헷갈립니다.
코딩도 마찬가지입니다. 처음에는 파일 몇 개만 있으니 그냥 복사해서 보관해도 될 것 같습니다. 그런데 기능을 추가하고, 버그를 고치고, 디자인을 바꾸다 보면 코드가 계속 달라집니다. 이때 Git을 사용하면 변경된 내용을 기록으로 남길 수 있습니다.
Git은 “언제”, “어떤 파일이”, “어떻게 바뀌었는지” 저장해줍니다. 그래서 문제가 생겼을 때 이전 상태로 돌아갈 수도 있고, 어떤 부분을 수정했는지 확인할 수도 있습니다. 코딩을 하다 보면 분명 어제는 잘 되던 기능이 오늘 갑자기 안 되는 순간이 있습니다. 이럴 때 Git 기록이 있으면 훨씬 덜 당황하게 됩니다.
저도 처음에는 Git을 귀찮게 느꼈습니다. 코드 저장은 그냥 파일 복사로 하면 되는 줄 알았습니다. 그런데 프로젝트를 만들다가 기능 하나를 잘못 건드려서 전체 화면이 깨진 적이 있습니다. 이전 코드가 따로 정리되어 있지 않아서 결국 기억을 더듬으며 다시 고쳐야 했습니다. 그 뒤로 Git을 조금씩 쓰기 시작했는데, 코드 변경 기록이 남아 있다는 것만으로도 마음이 꽤 편했습니다.
GitHub는 코드를 온라인에 보관하고 공유하는 공간
Git이 내 컴퓨터에서 코드의 변경 기록을 관리하는 도구라면, GitHub는 그 코드를 온라인에 올려두는 공간입니다. 쉽게 말해 개발자를 위한 클라우드 저장소라고 생각해도 좋습니다.
내 컴퓨터에만 코드를 저장해두면 컴퓨터가 고장 나거나 파일을 실수로 지웠을 때 위험합니다. 하지만 GitHub에 올려두면 인터넷이 되는 곳에서 다시 내려받을 수 있습니다. 또 다른 사람에게 내 코드를 보여주기도 쉽습니다.
개발자 취업을 준비할 때 GitHub가 중요한 이유도 여기에 있습니다. 이력서에는 내가 어떤 코드를 작성했는지 전부 보여주기 어렵습니다. 하지만 GitHub 주소를 함께 제출하면 내가 만든 프로젝트, 코드 작성 습관, 공부 기록을 어느 정도 보여줄 수 있습니다.
물론 GitHub에 코드가 있다고 해서 무조건 좋은 포트폴리오가 되는 것은 아닙니다. 저장소 이름이 정리되어 있고, README에 프로젝트 설명이 있고, 실행 방법과 주요 기능이 적혀 있으면 훨씬 보기 좋습니다. 반대로 코드만 덩그러니 올라와 있으면 보는 사람이 프로젝트를 이해하기 어렵습니다.
Git과 GitHub는 같은 것이 아니다
입문자들이 가장 많이 헷갈리는 부분이 바로 Git과 GitHub의 차이입니다. 이름도 비슷하고 같이 쓰는 경우가 많다 보니 같은 도구처럼 느껴질 수 있습니다.
하지만 둘은 다릅니다. Git은 버전 관리 도구입니다. 내 코드가 어떻게 바뀌었는지 기록하고 관리합니다. GitHub는 Git으로 관리한 코드를 온라인에 저장하고 공유하는 서비스입니다.
비유하자면 Git은 사진을 찍고 앨범을 정리하는 방식이고, GitHub는 그 앨범을 온라인에 올려두는 공간입니다. 사진을 찍지 않으면 올릴 것도 없고, 온라인 공간이 없으면 다른 사람과 공유하기 어렵습니다. 그래서 둘은 다르지만 함께 쓰면 훨씬 편리합니다.
처음에는 Git만 배워도 되고, GitHub만 가입해도 됩니다. 하지만 실제 개발 공부에서는 둘을 같이 익히는 것이 좋습니다. 내 컴퓨터에서 Git으로 변경 내용을 저장하고, 그 기록을 GitHub에 올리는 흐름을 익히면 됩니다.
저장소는 프로젝트를 담는 폴더라고 보면 된다
GitHub를 처음 사용하면 repository라는 단어를 만나게 됩니다. 보통 저장소라고 부릅니다. 저장소는 하나의 프로젝트를 담는 공간이라고 생각하면 쉽습니다.
예를 들어 계산기 프로젝트 하나를 만들었다면 계산기 저장소를 만들 수 있습니다. Todo 리스트를 만들었다면 Todo 리스트 저장소를 따로 만들 수 있습니다. 저장소 안에는 코드 파일, 이미지 파일, 설명 문서 등이 들어갑니다.
초보자라면 처음부터 저장소를 많이 만들 필요는 없습니다. 작은 프로젝트를 하나 만들 때마다 하나의 저장소를 만들고, 그 안에 코드를 정리하는 연습을 하면 됩니다. 저장소 이름은 가능하면 프로젝트 내용을 알 수 있게 짓는 것이 좋습니다. test1, practice, newproject 같은 이름보다는 todo-list, weather-app, portfolio-site처럼 의미가 보이는 이름이 좋습니다.
나중에 포트폴리오를 정리할 때도 저장소 이름이 깔끔하면 훨씬 보기 좋습니다. 실제로 제 GitHub 초반 저장소를 보면 이름이 뒤죽박죽이었습니다. 나중에 다시 보니 어떤 프로젝트인지 저도 헷갈렸습니다. 그 뒤로는 저장소 이름과 README를 조금 더 신경 쓰게 됐습니다.
커밋은 저장 버튼이 아니라 기록 남기기다
Git을 배우면 commit이라는 단어를 자주 만나게 됩니다. 많은 초보자가 커밋을 단순한 저장 버튼처럼 생각합니다. 하지만 커밋은 그냥 저장이 아니라 “의미 있는 변경 기록을 남기는 것”에 가깝습니다.
예를 들어 로그인 버튼 디자인을 수정했다면 그 내용을 커밋으로 남길 수 있습니다. Todo 리스트에 삭제 기능을 추가했다면 그것도 하나의 커밋이 될 수 있습니다. 커밋을 하면 나중에 어떤 작업을 했는지 기록으로 확인할 수 있습니다.
커밋 메시지도 중요합니다. 처음에는 수정, 작업, 완료처럼 대충 적기 쉽습니다. 저도 초반에는 커밋 메시지를 거의 일기처럼 아무렇게나 적었습니다. 그런데 나중에 기록을 보니 어떤 내용을 바꿨는지 전혀 알 수 없었습니다.
좋은 커밋 메시지는 짧아도 내용이 분명해야 합니다. 예를 들어 “할 일 삭제 기능 추가”, “메인 페이지 반응형 스타일 수정”, “로그인 입력값 검증 추가”처럼 적으면 나중에 봐도 이해하기 쉽습니다. 커밋 메시지는 미래의 내가 코드를 다시 볼 때 큰 도움이 됩니다.
브랜치는 새로운 작업 공간이다
Git을 조금 더 배우면 branch라는 개념이 나옵니다. 처음에는 브랜치가 어렵게 느껴질 수 있지만, 쉽게 말하면 새로운 작업 공간입니다.
예를 들어 현재 잘 작동하는 프로젝트가 있다고 해보겠습니다. 여기에 새로운 기능을 추가하고 싶은데, 바로 기존 코드에 작업했다가 망가지면 곤란합니다. 이럴 때 브랜치를 만들어 따로 작업할 수 있습니다. 새 기능이 잘 작동하면 기존 코드에 합치고, 문제가 있으면 그 브랜치에서만 수정하면 됩니다.
혼자 공부할 때는 브랜치를 꼭 깊게 사용할 필요는 없습니다. 하지만 팀 프로젝트나 실무에서는 브랜치를 자주 사용합니다. 여러 사람이 동시에 다른 기능을 개발해야 하기 때문입니다.
입문자라면 처음에는 main 브랜치에 작업하다가, 어느 정도 익숙해지면 새 기능을 만들 때 브랜치를 하나 만들어보는 정도로 시작하면 좋습니다. 브랜치는 Git이 단순 저장 도구가 아니라 협업 도구로 강력해지는 이유 중 하나입니다.
README는 프로젝트의 첫인상이다
GitHub 저장소에 들어갔을 때 가장 먼저 보이는 문서가 README입니다. README는 이 프로젝트가 무엇인지 설명하는 안내문입니다. 프로젝트 소개, 주요 기능, 사용 기술, 실행 방법, 배운 점 등을 적을 수 있습니다.
초보자일수록 README를 꼭 작성하는 습관을 들이는 것이 좋습니다. 코드만 올려두면 다른 사람이 프로젝트를 이해하기 어렵습니다. 반대로 README가 잘 정리되어 있으면 프로젝트의 완성도가 훨씬 높아 보입니다.
README에는 너무 거창한 내용을 적지 않아도 됩니다. “이 프로젝트는 할 일을 추가하고 삭제할 수 있는 Todo 리스트입니다”, “HTML, CSS, JavaScript를 사용했습니다”, “로컬 저장 기능을 구현했습니다”처럼 간단히 적어도 충분합니다.
저는 처음에 README를 거의 비워둔 채로 프로젝트를 올렸습니다. 그런데 나중에 포트폴리오를 정리하면서 다시 보니 어떤 목적으로 만든 프로젝트인지 설명하기 어려웠습니다. 그때부터 프로젝트를 만들 때마다 짧게라도 README를 적는 습관을 들였습니다. 이 기록이 나중에 면접 준비나 블로그 글 작성에도 도움이 됐습니다.
처음 배울 때 꼭 알아야 할 기본 흐름
Git과 GitHub를 처음 배울 때는 모든 명령어를 외우려고 하지 않아도 됩니다. 처음에는 기본 흐름만 이해하면 충분합니다.
먼저 프로젝트 폴더를 만들고, Git으로 관리하도록 설정합니다. 그다음 코드를 작성하고, 변경된 파일을 확인합니다. 필요한 파일을 선택해서 커밋하고, 그 커밋을 GitHub 저장소에 올립니다. 이 흐름이 가장 기본입니다.
처음에는 명령어가 낯설어서 어렵게 느껴질 수 있습니다. 하지만 몇 번 반복하면 점점 익숙해집니다. 중요한 것은 명령어를 무작정 외우는 것이 아니라, 지금 내가 하는 작업이 어떤 의미인지 이해하는 것입니다.
예를 들어 커밋은 변경 기록을 남기는 것이고, push는 내 컴퓨터의 기록을 GitHub에 올리는 것이며, pull은 GitHub에 있는 변경 내용을 내 컴퓨터로 가져오는 것입니다. 이 세 가지 개념만 알아도 GitHub를 사용하는 기본 흐름은 어느 정도 이해할 수 있습니다.
GitHub를 공부 기록으로 활용하기
GitHub는 취업용 포트폴리오뿐만 아니라 공부 기록으로도 좋습니다. 매일 공부한 코드를 올리면 내가 어떤 내용을 배웠는지 기록으로 남습니다. 처음에는 코드가 어설퍼도 괜찮습니다. 중요한 것은 꾸준히 쌓아가는 과정입니다.
초보자라면 작은 예제도 저장소에 올려보는 것이 좋습니다. 조건문 연습, 반복문 연습, 간단한 계산기, 자기소개 페이지 같은 것들도 좋은 기록이 됩니다. 나중에 보면 실력이 얼마나 늘었는지 확인할 수 있습니다.
다만 아무 파일이나 막 올리기보다는 폴더 구조와 파일 이름을 조금씩 정리하는 습관을 들이면 좋습니다. 그리고 비밀번호, API 키, 개인 정보 같은 민감한 내용은 절대 GitHub에 올리지 않도록 주의해야 합니다. GitHub는 온라인 공간이기 때문에 공개 저장소에 올린 코드는 다른 사람이 볼 수 있습니다.
Git과 GitHub는 개발자의 기본 습관이다
Git과 GitHub는 처음에는 어렵게 느껴질 수 있습니다. 하지만 개발 공부를 오래 할수록 꼭 필요한 도구라는 것을 알게 됩니다. Git은 코드의 변경 기록을 관리해주고, GitHub는 그 코드를 온라인에 저장하고 공유할 수 있게 도와줍니다.
처음부터 브랜치 전략이나 협업 방식까지 깊게 알 필요는 없습니다. 입문 단계에서는 저장소 만들기, 커밋하기, GitHub에 올리기, README 작성하기 정도만 익혀도 충분합니다. 이 기본 흐름을 작은 프로젝트마다 반복하면 자연스럽게 익숙해집니다.
저도 처음에는 Git 명령어가 무섭고, GitHub에 코드를 올리는 과정이 복잡하게 느껴졌습니다. 하지만 프로젝트가 하나둘 쌓이고, 이전 기록을 다시 확인할 수 있게 되면서 왜 개발자들이 Git을 중요하게 생각하는지 알게 됐습니다.
코딩 공부는 코드를 작성하는 것만큼이나 기록하고 관리하는 습관이 중요합니다. 오늘 만든 작은 계산기 하나라도 GitHub에 올려보세요. README에 어떤 기능을 만들었는지 한 줄이라도 적어보세요. 그 작은 기록들이 쌓이면 나중에는 나만의 개발 성장 기록이 되고, 포트폴리오의 좋은 재료가 됩니다.