핵심 결론

깃은 “파일의 변경 이력을 관리하는 도구”이고, 깃허브는 “깃으로 관리하는 프로젝트를 온라인에 올려 공유하고 협업하는 서비스”입니다.

비유하면 이렇게 보면 쉽습니다.

• 깃: 내 컴퓨터 안에서 작업 기록을 남기는 타임머신
• 깃허브: 그 작업 기록을 인터넷에 올려 팀원과 함께 보는 작업 공간

예를 들어 웹사이트를 만들다가 index.html 파일을 수정했다고 해보겠습니다. 그냥 저장만 하면 “현재 파일”만 남습니다. 그런데 깃을 쓰면 “언제, 누가, 왜, 어떤 줄을 바꿨는지”가 기록됩니다. 깃허브를 쓰면 그 기록을 온라인에 올려 다른 사람이 확인하고, 리뷰하고, 함께 수정할 수 있습니다.

깃은 정확히 무엇인가

깃은 버전 관리 시스템입니다. 버전 관리란 파일을 수정할 때마다 중요한 변경점을 기록해서 나중에 되돌아가거나 비교할 수 있게 하는 방식입니다.

일반적인 파일 관리 방식은 이런 식입니다.

• 최종.docx
• 최종_진짜.docx
• 최종_진짜_수정.docx
• 최종_진짜_수정_마지막.docx

이 방식은 금방 혼란스러워집니다. 어떤 파일이 진짜 최신인지, 어떤 내용을 언제 바꿨는지 알기 어렵습니다.

깃을 쓰면 파일 이름을 계속 복사하지 않아도 됩니다. 대신 변경 단위마다 기록을 남깁니다. 이 기록을 커밋이라고 부릅니다.

예를 들어 이런 식입니다.

• 1번째 커밋: 메인 페이지 생성
• 2번째 커밋: 로그인 버튼 추가
• 3번째 커밋: 모바일 화면 오류 수정
• 4번째 커밋: 가격표 문구 변경

각 커밋에는 변경된 파일, 변경된 줄, 작성자, 시간, 설명이 남습니다. 그래서 문제가 생기면 “어느 변경에서 문제가 생겼는지” 추적할 수 있고, 필요하면 이전 상태로 되돌릴 수 있습니다.

깃허브는 정확히 무엇인가

깃허브는 깃 저장소를 온라인에 보관하고 협업할 수 있게 해주는 플랫폼입니다.

깃 자체는 내 컴퓨터에서도 사용할 수 있습니다. 하지만 내 컴퓨터에만 있으면 다른 사람과 함께 보기 어렵고, 컴퓨터가 고장 나면 기록도 위험해집니다. 깃허브는 이 저장소를 인터넷에 올려서 다음 일을 가능하게 합니다.

• 내 코드를 온라인에 백업하기
• 팀원과 같은 프로젝트를 함께 수정하기
• 다른 사람이 변경한 내용을 검토하기
• 이슈로 할 일을 관리하기
• 오픈소스 프로젝트에 기여하기
• 배포 서비스와 연결해서 자동 배포하기

즉, 깃이 “기록 도구”라면 깃허브는 “기록을 공유하고 운영하는 협업 공간”입니다.

여기서 중요한 점은 깃과 깃허브가 같은 것이 아니라는 점입니다. 깃은 도구이고, 깃허브는 그 도구를 활용하는 서비스입니다. 깃허브 말고도 GitLab, Bitbucket 같은 서비스가 있습니다. 하지만 현재는 깃허브가 가장 널리 쓰입니다.

상황별 판단 기준

혼자 코딩을 배우는 단계라면

깃은 반드시 배우는 것이 좋습니다. 처음에는 깃허브까지 완벽히 알 필요는 없지만, 최소한 다음 개념은 익혀야 합니다.

• 저장소
• 커밋
• 변경 내역 확인
• 이전 상태로 되돌리기
• 깃허브에 올리기

혼자 공부할 때도 깃을 쓰면 실수했을 때 되돌리기 쉽습니다. 예를 들어 잘 돌아가던 코드가 갑자기 망가졌다면, 이전 커밋과 비교해서 무엇이 달라졌는지 확인할 수 있습니다.

팀 프로젝트를 한다면

깃허브까지 거의 필수입니다. 팀원이 각자 파일을 보내고 합치는 방식은 금방 한계가 옵니다. 깃허브를 쓰면 누가 어떤 기능을 만들었는지, 어떤 변경을 합쳐도 되는지 확인할 수 있습니다.

특히 팀에서는 Pull Request, 코드 리뷰, 브랜치 개념이 중요해집니다.

취업이나 포트폴리오를 준비한다면

깃허브는 단순 저장소가 아니라 포트폴리오 역할도 합니다. 회사나 협업자가 깃허브를 보면 다음을 알 수 있습니다.

• 실제로 코드를 작성했는지
• 꾸준히 작업했는지
• 커밋 메시지를 의미 있게 쓰는지
• 프로젝트 구조를 이해하고 있는지
• README로 설명을 잘 남기는지

단순히 프로젝트 파일을 압축해서 보내는 것보다 깃허브 링크 하나가 훨씬 신뢰도가 높습니다.

웹사이트나 앱을 운영한다면

깃허브는 배포 흐름의 중심이 될 수 있습니다. 예를 들어 깃허브에 코드를 올리면 Vercel, Netlify, GitHub Actions 같은 서비스가 자동으로 테스트하거나 배포할 수 있습니다.

실무에서는 보통 이런 흐름을 씁니다.

1. 내 컴퓨터에서 코드 수정
2. 깃으로 커밋
3. 깃허브에 푸시
4. 배포 서비스가 변경 감지
5. 자동으로 웹사이트 배포

이렇게 하면 “내 컴퓨터에서는 되는데 서버에서는 안 되는” 문제도 줄이고, 누가 언제 무엇을 배포했는지도 추적할 수 있습니다.

바로 실행할 순서

처음 배우는 사람이라면 너무 많은 명령어를 한 번에 외우려고 하지 말고, 아래 순서대로 익히는 것을 추천합니다.

깃 설치 확인

터미널에서 다음 명령을 실행합니다.

git --version

버전이 나오면 깃이 설치된 것입니다. 예를 들어 git version 2.43.0처럼 나옵니다.

사용자 이름과 이메일 설정

처음 한 번은 내 커밋에 표시될 이름과 이메일을 설정합니다.

git config --global user.name "내이름"

git config --global user.email "내이메일@example.com"

이 정보는 “이 커밋을 누가 만들었는지”를 기록하는 데 쓰입니다.

프로젝트 폴더를 깃 저장소로 만들기

프로젝트 폴더로 이동한 뒤 실행합니다.

git init

이 명령을 실행하면 해당 폴더가 깃으로 관리되기 시작합니다.

변경 상태 확인하기

git status

현재 어떤 파일이 새로 생겼고, 어떤 파일이 수정됐는지 보여줍니다. 깃을 쓸 때 가장 자주 확인해야 하는 명령어입니다.

커밋할 파일 선택하기

git add 파일명

예를 들어 README.md를 기록 대상으로 추가하려면 이렇게 합니다.

git add README.md

모든 변경 파일을 추가하려면 다음처럼 쓸 수 있습니다.

git add .

다만 실무에서는 무조건 git add .를 쓰기보다, 어떤 파일이 들어가는지 git status로 먼저 확인하는 습관이 중요합니다.

커밋 만들기

git commit -m "README 추가"

커밋 메시지는 “무엇을 했는지” 알아볼 수 있게 써야 합니다. 수정, 작업, asdf 같은 메시지는 나중에 추적하기 어렵습니다.

좋은 예시는 다음과 같습니다.

• 로그인 폼 UI 추가
• 모바일 메뉴 열림 오류 수정
• 상품 목록 API 연동
• README에 실행 방법 추가

깃허브 저장소 만들기

깃허브 사이트에서 새 저장소를 만듭니다. 저장소 이름은 보통 프로젝트 이름과 맞춥니다.

예를 들어 my-first-website 같은 이름을 사용할 수 있습니다.

내 로컬 저장소와 깃허브 저장소 연결하기

깃허브에서 안내해주는 주소를 복사한 뒤 다음처럼 연결합니다.

git remote add origin 깃허브저장소주소

그리고 업로드합니다.

git push -u origin main

이제 내 컴퓨터의 커밋 기록이 깃허브에 올라갑니다.

구체적인 예시

예시 1. 혼자 웹사이트를 만드는 경우

당신이 개인 소개 웹사이트를 만든다고 해보겠습니다.

첫날에는 기본 페이지를 만듭니다.

• index.html 생성
• style.css 생성
• 커밋 메시지: 기본 소개 페이지 생성

둘째 날에는 프로필 사진과 자기소개 문구를 추가합니다.

• 이미지 추가
• 소개 문장 수정
• 커밋 메시지: 프로필 섹션 추가

셋째 날에는 모바일에서 화면이 깨지는 문제를 고칩니다.

• CSS 미디어 쿼리 수정
• 커밋 메시지: 모바일 레이아웃 깨짐 수정

이렇게 남겨두면 나중에 “모바일 문제가 언제 고쳐졌는지”, “어떤 파일을 바꿨는지” 바로 확인할 수 있습니다.

예시 2. 팀 프로젝트에서 기능을 나눠 만드는 경우

세 명이 쇼핑몰 프로젝트를 만든다고 해보겠습니다.

• A: 로그인 기능
• B: 상품 목록
• C: 장바구니

각자가 같은 파일을 직접 덮어쓰면 충돌이 납니다. 깃과 깃허브를 쓰면 각자 브랜치를 만들어 작업하고, 완성된 변경을 Pull Request로 올려 검토한 뒤 합칠 수 있습니다.

흐름은 대략 이렇습니다.

1. login-feature 브랜치 생성
2. 로그인 기능 작업
3. 커밋
4. 깃허브에 푸시
5. Pull Request 생성
6. 팀원이 코드 리뷰
7. 문제가 없으면 main 브랜치에 병합

이 방식은 처음에는 번거로워 보이지만, 프로젝트가 조금만 커져도 훨씬 안전합니다.

예시 3. 실수로 코드를 망가뜨린 경우

어제까지 잘 되던 웹사이트가 오늘 갑자기 오류가 난다고 해보겠습니다. 깃을 쓰고 있었다면 다음을 할 수 있습니다.

• 어제 커밋과 오늘 커밋 비교
• 어떤 파일이 바뀌었는지 확인
• 특정 커밋으로 되돌리기
• 문제가 된 변경만 취소하기

깃이 없으면 기억에 의존해야 합니다. “내가 아까 뭘 바꿨더라?”가 됩니다. 깃이 있으면 기록을 보고 판단할 수 있습니다.

자주 나오는 용어 정리

이 용어들을 한 번에 완벽히 외울 필요는 없습니다. 실제로 프로젝트를 하나 만들면서 반복하면 자연스럽게 익숙해집니다.

실수와 주의할 점

깃허브에 비밀번호나 API 키를 올리지 않기

가장 위험한 실수입니다. .env 파일, API 키, 데이터베이스 비밀번호, 토큰을 깃허브에 올리면 외부에 노출될 수 있습니다.

예를 들어 다음 같은 값은 절대 공개 저장소에 올리면 안 됩니다.

• DATABASE_URL
• OPENAI_API_KEY
• GITHUB_TOKEN
• 서버 비밀번호
• 클라우드 접근 키

이런 파일은 .gitignore에 추가해서 깃이 추적하지 않게 해야 합니다.

커밋 메시지를 의미 없이 쓰지 않기

수정, 업데이트, 작업함 같은 메시지는 나중에 거의 도움이 되지 않습니다. 커밋 메시지는 짧아도 좋지만, 변경 목적이 보여야 합니다.

나쁜 예:

• 수정
• test
• 작업

좋은 예:

• 회원가입 이메일 검증 추가
• 헤더 모바일 메뉴 위치 수정
• 결제 실패 시 안내 문구 추가

main 브랜치에 바로 큰 작업을 하지 않기

혼자 연습할 때는 괜찮지만, 팀이나 운영 프로젝트에서는 main 브랜치를 안정적인 상태로 유지하는 것이 좋습니다. 새 기능이나 위험한 수정은 별도 브랜치에서 작업한 뒤 검토하고 합치는 방식이 안전합니다.

깃허브를 백업 서비스로만 생각하지 않기

깃허브는 단순 파일 저장소가 아닙니다. 변경 이력, 리뷰, 이슈, 배포 흐름까지 관리하는 협업 플랫폼입니다. 그냥 파일을 올려두는 용도로만 쓰면 장점을 절반도 활용하지 못합니다.

충돌을 무서워하지 않기

충돌은 실패가 아닙니다. 같은 줄을 여러 사람이 다르게 수정했기 때문에 깃이 “어느 쪽이 맞는지 사람이 결정해달라”고 알려주는 상황입니다. 충돌이 났을 때는 당황하지 말고, 어떤 변경을 남길지 확인한 뒤 정리하면 됩니다.

추천 시작 범위

처음부터 모든 깃 명령어를 외우려고 하면 어렵습니다. 처음 1주일은 아래 8개만 익혀도 충분합니다.

1. git init
2. git status
3. git add
4. git commit
5. git log
6. git remote
7. git push
8. git pull

그리고 깃허브에서는 다음 4가지만 먼저 익히면 됩니다.

1. 저장소 만들기
2. README 작성하기
3. 내 프로젝트 올리기
4. 다른 사람이 볼 수 있는 링크 공유하기

그다음 단계로 브랜치, Pull Request, 코드 리뷰, GitHub Actions를 배우면 됩니다.

다음 단계

가장 좋은 학습 방법은 작은 프로젝트 하나를 직접 깃허브에 올려보는 것입니다. 추천 실습은 다음과 같습니다.

1. my-profile이라는 폴더 만들기
2. README.md 파일 만들기
3. 자기소개 5줄 작성하기
4. git init 실행하기
5. git add README.md 실행하기
6. git commit -m "자기소개 README 추가" 실행하기
7. 깃허브에서 새 저장소 만들기
8. git remote add origin ...으로 연결하기
9. git push -u origin main으로 올리기
10. 깃허브 링크를 열어 내용 확인하기

이 한 번의 실습만 해도 깃과 깃허브의 기본 흐름은 잡힙니다. 핵심은 “깃은 내 변경 기록을 관리하는 도구, 깃허브는 그 기록을 온라인에서 공유하고 협업하는 공간”이라는 구분을 계속 유지하는 것입니다.