소프트웨어 개발 세계에서 GitHub(깃허브)라는 이름을 한 번도 들어보지 못한 사람은 거의 없을 것이다. 2026년 4월 기준 전 세계 1억 8천만 명 이상의 개발자가 사용하고, 6억 3천만 개 이상의 저장소가 등록되어 있는 세계 최대 규모의 코드 호스팅 플랫폼이다. 하지만 개발 경험이 없는 사람이 깃허브 페이지를 처음 열면 Fork, Pull Request, Star, Issue 같은 낯선 영어 용어가 빽빽하게 나열되어 있어 당황하기 쉽다.
이 문서는 깃허브가 정확히 어떤 서비스인지, 화면 곳곳에 보이는 메뉴와 숫자가 무엇을 뜻하는지, 그리고 개발자 커뮤니티에서 일상적으로 쓰이는 은어와 줄임말까지 한 곳에 모아 정리한다. 코드 한 줄 작성할 줄 몰라도 깃허브 저장소 화면을 열고 맥락을 읽을 수 있도록 구성했다.
1. Git과 GitHub, 무엇이 다른가
깃허브를 이해하려면 먼저 Git(깃)과 GitHub(깃허브)의 관계를 구분해야 한다. 이 둘은 이름이 비슷하지만 전혀 다른 계층에 속한다.
1.1 Git — 내 컴퓨터 안의 버전 관리 도구
- Git은 분산 버전 관리 시스템(DVCS)이다. 쉽게 말해, 파일의 변경 이력을 자동으로 기록해 주는 프로그램이다. 워드 문서를 '보고서_최종', '보고서_최종_진짜최종'처럼 여러 파일로 저장한 경험이 있다면, Git이 바로 그 문제를 해결해 준다.
- 2005년 리눅스 운영체제를 만든 리누스 토르발스(Linus Torvalds)가 리눅스 커널 개발을 위해 직접 설계했다. 인터넷 연결 없이도 내 컴퓨터(로컬)에서 독립적으로 동작한다.
- 파일을 수정할 때마다 스냅샷(snapshot)을 찍듯 저장하기 때문에 언제든 과거 상태로 돌아갈 수 있고, 여러 사람이 동시에 작업해도 각자의 변경 내역이 충돌 없이 합쳐질 수 있다.
1.2 GitHub — Git 저장소를 인터넷에 올려 놓는 플랫폼
- GitHub는 Git으로 관리되는 코드를 온라인 서버에 올려 두고, 누구나 열람하거나 협업할 수 있게 해 주는 웹 기반 호스팅 서비스다. 비유하자면 Git이 '일기장'이라면 GitHub는 '일기장을 보관하고 다른 사람과 공유할 수 있는 클라우드 서재'에 해당한다.
- 2008년 설립되었고 2018년 마이크로소프트가 75억 달러(약 10조 원)에 인수했다. 코드 저장 기능 외에도 이슈 트래킹, 프로젝트 관리, CI/CD 자동화, 보안 스캔 등 개발 생태계 전반을 지원하는 올인원 플랫폼으로 성장했다.
- Git 없이 GitHub를 쓸 수는 없지만, GitHub 없이 Git을 쓸 수는 있다. 다만 대부분의 오픈소스 프로젝트와 기업이 GitHub를 사용하기 때문에 사실상 '개발자들의 SNS'로 불린다.
핵심 포인트: Git은 내 컴퓨터에서 코드 이력을 추적하는 도구이고, GitHub는 그 이력을 온라인에 올려 전 세계와 공유하는 플랫폼이다. 둘은 별개이지만 거의 항상 함께 사용된다.
2. GitHub가 이렇게 유명한 이유
단순한 코드 저장소가 아니라 개발 문화 자체를 바꾼 플랫폼이기 때문에 깃허브는 압도적인 인지도를 갖게 되었다.
2.1 오픈소스 생태계의 중심
- 리눅스 커널, React, TensorFlow, VS Code 등 세계적으로 유명한 오픈소스 프로젝트 대부분이 GitHub에 공개되어 있다. 누구든 코드를 읽고, 복사하고, 수정 제안을 보낼 수 있다.
- 2025년 한 해에만 3,600만 명의 신규 개발자가 가입했는데, 이는 매초 1명꼴로 계정이 만들어진 셈이다.
2.2 협업과 포트폴리오
- 여러 명이 동시에 하나의 프로젝트를 수정하더라도 브랜치(branch)와 풀 리퀘스트(Pull Request) 시스템 덕분에 코드가 엉키지 않고 체계적으로 합쳐진다.
- 개발자의 활동 기록(커밋 횟수, 기여한 프로젝트)이 프로필에 자동으로 남기 때문에 이력서이자 포트폴리오 역할도 한다. 채용 시 지원자의 깃허브 프로필을 확인하는 기업이 늘고 있다.
2.3 개발 워크플로 통합
- GitHub Actions를 통해 코드가 올라올 때마다 자동으로 테스트를 돌리고 서버에 배포하는 CI/CD 파이프라인을 구성할 수 있다.
- GitHub Copilot 같은 AI 코딩 보조 도구, 프로젝트 관리 보드, 보안 취약점 스캔 등 개발에 필요한 도구가 하나의 플랫폼 안에 통합되어 있다.
3. 깃허브 저장소 화면 메뉴 완전 해부
깃허브에서 특정 프로젝트 페이지에 들어가면 상단에 여러 개의 탭이 나란히 놓여 있다. 각 탭이 무엇을 의미하는지 하나씩 짚어 본다.
3.1 Code 탭 — 프로젝트의 본체
- 저장소에 들어가면 가장 먼저 보이는 화면이다. 폴더와 파일 목록이 나열되고, 각 파일 옆에 마지막으로 수정한 사람의 이름, 커밋 메시지(변경 설명), 수정 일시가 표시된다.
- 파일 목록 아래에는 README.md 파일의 내용이 자동으로 렌더링된다. README는 '읽어 주세요'라는 뜻 그대로, 프로젝트가 무엇인지, 어떻게 설치하고 사용하는지를 설명하는 안내문이다.
- 화면 오른쪽에는 About 영역이 있어 프로젝트 한 줄 소개, 태그(Topics), 라이선스 종류 등을 한눈에 확인할 수 있다.
3.2 Pull Requests 탭 — 코드 변경 제안 목록
- Pull Request(PR)는 '내가 수정한 코드를 원본 프로젝트에 반영해 달라'는 요청이다. 한국에서는 줄여서 '풀리퀘' 또는 'PR'이라고 부른다.
- 탭 옆에 표시되는 숫자(예: 32)는 현재 열려 있는 PR의 개수다. 숫자가 많을수록 활발하게 기여가 이루어지고 있다는 뜻이다.
- PR 안에서는 변경된 코드의 줄 단위 비교(diff), 리뷰어의 코멘트, 자동 테스트 결과 등을 한 화면에서 확인할 수 있다.
3.3 Issues 탭 — 할 일과 버그 신고 게시판
- Issue(이슈)는 버그 보고, 기능 요청, 질문 등을 올리는 게시판이다. 프로젝트의 투두 리스트 역할을 한다.
- 각 이슈에는 Label(라벨)을 붙여 분류할 수 있다. 예를 들어
bug(버그),enhancement(기능 개선),documentation(문서 수정),good first issue(초보자 환영) 같은 태그가 자주 쓰인다. - Milestone(마일스톤)은 관련 이슈를 묶어서 특정 목표(예: 'v2.0 출시')까지의 진행률을 추적하는 장치다.
3.4 Actions 탭 — 자동화 작업 현황
- GitHub Actions는 코드가 Push되거나 PR이 열릴 때 자동으로 실행되는 워크플로(작업 흐름)를 설정하는 기능이다.
- 테스트 자동 실행, 빌드, 배포, 코드 품질 검사 등을 사람이 직접 하지 않아도 기계가 대신 수행한다. 이를 CI/CD(지속적 통합/지속적 배포)라고 한다.
3.5 Projects, Security, Insights 탭
- Projects는 칸반 보드 형태의 프로젝트 관리 도구다. Issue와 PR을 카드처럼 배치해 'Todo → In Progress → Done' 흐름으로 진행 상황을 시각화한다.
- Security는 코드에 포함된 보안 취약점, 의존성 패키지의 알려진 결함 등을 자동으로 탐지하고 알림을 보내 준다.
- Insights는 저장소의 통계 대시보드다. 커밋 빈도, 기여자 순위, 트래픽(방문자 수), 코드 변경 빈도 그래프 등을 제공한다.
| 탭 이름 | 한 줄 설명 | 누가 주로 사용하는가 |
|---|---|---|
| Code | 소스코드 파일 목록과 README | 모든 방문자 |
| Pull Requests | 코드 변경 제안 및 리뷰 | 기여자, 메인테이너 |
| Issues | 버그 신고, 기능 요청 | 사용자, 기여자 |
| Actions | CI/CD 자동화 워크플로 | 개발팀 |
| Projects | 칸반 보드 기반 일정 관리 | 프로젝트 관리자 |
| Security | 보안 취약점 탐지 및 알림 | 보안 담당자, 메인테이너 |
| Insights | 저장소 활동 통계 | 프로젝트 관리자, 기여자 |
4. 반드시 알아야 할 깃허브 핵심 용어
깃허브 화면 곳곳에서 반복적으로 등장하는 용어를 모아 정리한다. 이 용어만 익혀도 저장소 페이지를 훑을 때 80% 이상의 맥락이 잡힌다.
4.1 저장소와 파일 관련 용어
- Repository(레포지토리, 줄여서 Repo) — 프로젝트의 모든 파일과 변경 이력이 담긴 폴더다. '저장소'라고 번역하며, 깃허브에서 가장 기본이 되는 단위다.
- README — 저장소 최상위에 놓이는 안내 문서로, 프로젝트의 목적, 설치 방법, 사용법 등을 적는다. 마크다운(.md) 형식으로 작성하면 깃허브가 자동으로 보기 좋게 렌더링해 준다.
- LICENSE(라이선스) — 이 코드를 누가 어떻게 사용할 수 있는지 법적 권한을 명시한 문서다. MIT, Apache 2.0, GPL 등 종류에 따라 허용 범위가 다르다. 라이선스가 없는 코드는 함부로 사용하면 저작권 문제가 생길 수 있다.
- Branch(브랜치) — 저장소 안에서 독립적으로 작업할 수 있는 평행 버전이다. 나뭇가지(branch)가 줄기에서 갈라져 나오듯, 원본(main) 코드를 건드리지 않고 새 기능을 실험할 수 있다. 작업이 끝나면 다시 원본에 합친다(merge).
- Main(메인) — 과거에는 'master'라고 불렀으나 현재 기본 브랜치 이름은 main이다. 배포 가능한 안정 버전의 코드가 머무르는 중심 줄기에 해당한다.
4.2 코드 작업과 협업 관련 용어
- Commit(커밋) — 파일의 변경 사항을 저장(확정)하는 행위다. 각 커밋에는 고유 ID(SHA 해시)가 붙고, '무엇을 왜 바꿨는지' 적는 커밋 메시지가 동반된다. 게임의 '세이브 포인트'와 같다.
- Push(푸시) — 내 컴퓨터(로컬)에 저장한 커밋을 원격 서버(GitHub)로 올리는 행위다.
- Pull(풀) — 원격 서버의 최신 변경 사항을 내 컴퓨터로 가져오면서 합치는 행위다.
- Fetch(페치) — Pull과 비슷하지만, 가져오기만 하고 내 작업 브랜치에 합치지는 않는다. 먼저 변경 내용을 확인한 뒤 합칠지 판단할 때 사용한다.
- Clone(클론) — 원격 저장소 전체를 내 컴퓨터에 복사하는 행위다. 복사본은 원본과 연결되어 있어 나중에 Push/Pull로 동기화할 수 있다.
- Fork(포크) — 다른 사람의 저장소를 내 깃허브 계정으로 통째로 복제하는 행위다. Clone이 '내 PC에 복사'라면 Fork는 '내 온라인 계정에 복사'다. 원본에 직접 쓸 권한이 없을 때 Fork한 뒤 수정하고, PR을 보내 원본에 반영을 요청한다.
- Pull Request(풀 리퀘스트, PR) — Fork하거나 브랜치에서 작업한 내용을 원본 저장소에 합쳐 달라고 보내는 공식 요청서다. PR 안에서 코드 리뷰, 토론, 자동 테스트 결과 확인이 모두 이루어진다.
- Merge(머지) — 두 개의 브랜치(또는 Fork)를 하나로 합치는 행위다. PR이 승인되면 메인테이너가 Merge 버튼을 눌러 변경 사항을 원본에 반영한다.
- Merge Conflict(머지 충돌) — 두 사람이 같은 파일의 같은 줄을 각각 다르게 수정했을 때 Git이 자동으로 합칠 수 없어 발생하는 충돌이다. 사람이 직접 어느 쪽 코드를 택할지 결정해야 한다.
- Diff(디프) — 두 버전 사이의 차이점을 줄 단위로 보여 주는 화면이다. 추가된 줄은 초록색, 삭제된 줄은 빨간색으로 표시된다.
| 용어 | 비유 | 핵심 기능 |
|---|---|---|
| Repository | 프로젝트 폴더 | 모든 파일과 이력 보관 |
| Branch | 나뭇가지 | 원본과 분리된 작업 공간 |
| Commit | 세이브 포인트 | 변경 사항 확정 기록 |
| Clone | 파일 복사(PC로) | 원격 저장소를 로컬에 복제 |
| Fork | 계정 복사(온라인) | 남의 저장소를 내 계정에 복제 |
| Pull Request | 변경 제안서 | 코드 합병 요청 및 리뷰 |
| Merge | 합치기 | 두 브랜치를 하나로 통합 |
5. 저장소 화면의 숫자가 의미하는 것들
깃허브 저장소 페이지 우측이나 상단에는 Star, Watch, Fork 옆에 숫자가 표시된다. 이 숫자들은 프로젝트의 인기도와 활성도를 보여 주는 일종의 사회적 지표다.
5.1 Star, Watch, Fork 숫자 읽기
- Star(스타) — '좋아요' 또는 '북마크' 개념이다. 마음에 드는 프로젝트에 별을 눌러 두면 나중에 다시 찾기 쉽고, 해당 프로젝트의 인지도 지표가 된다. 예를 들어 앞서 본 저장소가 50.2k Stars라면 약 5만 명이 별을 눌렀다는 뜻이며, 이는 상당히 높은 수치다.
- Watch(워치) — 해당 저장소의 활동 알림을 구독하는 기능이다. 새 이슈, PR, 릴리스 등이 올라올 때마다 알림을 받는다. 284 watching이라면 284명이 이 저장소를 주시하고 있다.
- Fork(포크) 숫자 — 이 저장소를 자기 계정으로 복제한 사람 수다. 4.1k forks라면 약 4,100명이 이 코드를 가져가 직접 수정하거나 참고하고 있다는 뜻이다.
5.2 Contributors 영역
- Contributors(컨트리뷰터)는 실제로 코드를 기여한 사람 목록이다. 커밋을 보내거나 PR이 머지된 사람이 자동으로 표시된다.
- Maintainer(메인테이너)는 저장소를 관리하는 핵심 책임자로, 이슈 분류, PR 리뷰 및 머지, 릴리스 배포 등을 담당한다. Contributors 목록에 항상 포함되지만 역할상 더 높은 권한을 가진다.
6. 개발 현장에서 자주 쓰이는 추가 용어
깃허브와 직접 관련은 없지만 깃허브 페이지나 개발 커뮤니티에서 자연스럽게 등장하는 용어도 있다.
6.1 코드 관리 관련
- Rebase(리베이스) — 브랜치의 시작점(base)을 다른 커밋으로 옮기는 작업이다. Merge와 달리 히스토리가 일직선으로 깔끔해지지만, 이력을 다시 쓰기 때문에 주의가 필요하다.
- Cherry-pick(체리픽) — 특정 커밋 하나만 골라서 다른 브랜치에 적용하는 행위다. 체리를 골라 따듯이, 원하는 변경 사항만 선별적으로 가져온다.
- Squash(스쿼시) — 여러 개의 커밋을 하나로 합치는 것이다. PR을 머지할 때 중간 커밋을 깔끔하게 정리할 목적으로 사용한다.
- Revert(리버트) — 이미 반영된 커밋의 변경 사항을 되돌리는 새 커밋을 만드는 것이다. 실수로 잘못된 코드를 머지했을 때 원상 복구하는 안전장치다.
- Tag(태그)와 Release(릴리스) — 특정 커밋에 'v1.0', 'v2.3.1' 같은 이름표를 붙이는 것이 Tag이고, 그 Tag를 기준으로 설치 파일이나 변경 내역을 공식 배포하는 것이 Release다.
6.2 소프트웨어 개발 일반 용어
- 포팅(Porting) — 소프트웨어를 원래 설계된 환경(예: Windows)과 다른 환경(예: macOS, Linux)에서 동작하도록 변환하는 작업이다. '이식'이라고도 번역하며, 게임이 PC에서 콘솔로 옮겨질 때 '포팅됐다'라고 표현한다.
- Refactoring(리팩토링) — 코드의 동작은 바꾸지 않으면서 내부 구조를 개선하는 작업이다. 집의 외관은 그대로인데 내부 배관과 배선을 깔끔하게 교체하는 리모델링에 비유할 수 있다.
- Deprecated(디프리케이티드) — 더 이상 사용을 권장하지 않는 기능이나 API라는 뜻이다. 당장 삭제되지는 않지만 '곧 없어질 예정이니 대안을 찾으라'는 경고다.
- Legacy(레거시) — 오래된 기술이나 시스템을 가리키는 표현이다. 유지보수가 어렵거나 현재 표준에 맞지 않지만 아직 운영 중인 코드에 흔히 붙는다.
- Boilerplate(보일러플레이트) — 프로젝트를 시작할 때 반복적으로 사용하는 기본 템플릿 코드다. 매번 처음부터 세팅하는 수고를 줄이기 위해 미리 만들어 둔 틀이다.
- Hotfix(핫픽스) — 긴급하게 수정해야 하는 버그를 즉시 고쳐 배포하는 패치다. 정규 업데이트 주기를 기다리지 않고 바로 나간다.
- Semantic Versioning(시맨틱 버전) — 버전 번호를 MAJOR.MINOR.PATCH 형식(예: 2.3.1)으로 매기는 규칙이다. MAJOR는 호환성이 깨지는 변경, MINOR는 기능 추가, PATCH는 버그 수정을 뜻한다.
7. 개발자 커뮤니티 은어와 줄임말
깃허브 Issue나 PR 코멘트, 슬랙 채널 등에서 개발자들이 즐겨 쓰는 줄임말과 은어가 있다. 처음 보면 암호처럼 느껴지지만 뜻을 알면 대화 흐름이 단번에 이해된다.
7.1 코드 리뷰에서 자주 쓰이는 약어
- LGTM — 'Looks Good To Me'의 줄임말로, '내가 보기에 괜찮다, 승인한다'는 뜻이다. PR 리뷰에서 문제가 없을 때 한 줄로 남기는 승인 사인이다.
- WIP — 'Work In Progress'의 줄임말로, '아직 작업 중'이라는 뜻이다. PR 제목 앞에
[WIP]를 붙여 '아직 리뷰하지 마세요, 진행 중입니다'라는 신호를 보낸다. - nit — 'nitpick'의 줄임말로, '중요하지는 않지만 더 나은 방법이 있다'는 사소한 지적을 남길 때 쓴다. 예: 'nit: 변수명을 좀 더 명확하게 바꾸면 좋겠다.'
- PTAL — 'Please Take A Look'의 줄임말로, '한번 봐 주세요'라는 리뷰 요청이다.
- RFC — 'Request For Comments'의 줄임말로, '의견을 구합니다'라는 뜻이다. 새로운 설계나 방향을 제안하면서 팀원의 피드백을 받고 싶을 때 사용한다.
- ACK / NACK — 'Acknowledged(인정함)' / 'Negative Acknowledgment(반대함)'의 줄임말이다. ACK는 동의, NACK는 반대 의사를 간결하게 표현한다.
- TL;DR — 'Too Long; Didn't Read'의 줄임말로, '너무 길어서 못 읽겠다'는 뜻이지만, 실제로는 긴 글 앞에 요약본을 제공할 때 'TL;DR: 핵심은 이것이다'처럼 쓴다.
- SSIA — 'Subject Says It All'의 줄임말로, '제목이 전부 말해준다, 추가 설명 없음'이라는 뜻이다.
- IMO / IMHO — 'In My Opinion' / 'In My Humble Opinion'의 줄임말로, '내 생각에는'이라는 뜻이다. 자기 의견임을 명시할 때 사용한다.
- FYI — 'For Your Information'의 줄임말로, '참고하세요'라는 뜻이다. 직접 액션이 필요한 건 아니지만 알아 두면 좋을 정보를 전달할 때 쓴다.
| 약어 | 풀어 쓰면 | 언제 쓰는가 |
|---|---|---|
| LGTM | Looks Good To Me | 코드 리뷰 승인 |
| WIP | Work In Progress | 아직 작업 중인 PR |
| nit | Nitpick | 사소한 개선 제안 |
| PTAL | Please Take A Look | 리뷰 요청 |
| RFC | Request For Comments | 설계/방향 의견 요청 |
| TL;DR | Too Long; Didn't Read | 긴 글의 요약 |
| IMO | In My Opinion | 개인 의견 표시 |
| FYI | For Your Information | 참고 정보 전달 |
7.2 개발 문화에서 통하는 재미있는 은어
- Dog-fooding(도그푸딩) — 자사가 만든 제품을 직원들이 직접 써 보는 것을 뜻한다. '자기가 만든 개밥을 자기가 먹는다'는 표현에서 유래했다.
- Bikeshedding(바이크셰딩) — 핵심 문제는 놔두고 사소한 문제에 지나치게 오래 논쟁하는 현상이다. 원자력 발전소 설계 회의에서 정작 원자로 설계는 넘어가고 자전거 보관소 색상만 논쟁했다는 일화에서 나왔다.
- Yak Shaving(야크 쉐이빙) — 본래 하려던 일을 하기 위해 끝없이 사전 작업이 필요해지는 상황이다. 'A를 하려면 B가 필요하고, B를 하려면 C가 필요하고...' 식으로 꼬리에 꼬리를 무는 작업 체인이다.
- Rubber Duck Debugging(러버덕 디버깅) — 문제를 고무 오리 인형에게 말로 설명하다 보면 스스로 해결책을 발견하게 된다는 디버깅 기법이다. 실제로 책상에 고무 오리를 두는 개발자가 꽤 있다.
- Spaghetti Code(스파게티 코드) — 얽히고설켜서 읽거나 수정하기 극도로 어려운 코드를 빗댄 표현이다. 스파게티 면발처럼 어디서 시작해 어디서 끝나는지 알 수 없다.
- Ship it(쉽 잇) — '배포하자, 내보내자'라는 의미다. 코드가 준비되었을 때 팀원이 '바로 Ship 하자'라고 말하면 '서버에 올리자'라는 뜻이다.
8. 마무리
위에서 살펴본 깃허브 용어와 개발자 커뮤니티 은어의 핵심 내용을 정리하면 다음과 같습니다.
핵심 요약:
- Git은 코드 변경 이력을 추적하는 도구이고, GitHub는 그 이력을 온라인에 호스팅하여 전 세계와 협업할 수 있게 하는 플랫폼이다
- 저장소(Repository) 화면의 Code, Pull Requests, Issues, Actions, Projects, Security, Insights 탭은 각각 코드 열람, 변경 제안, 할 일 관리, 자동화, 프로젝트 관리, 보안, 통계 기능을 담당한다
- Fork는 남의 저장소를 내 계정으로 복제하는 것, Clone은 내 PC로 복제하는 것, Pull Request는 수정한 코드를 원본에 합쳐 달라는 요청이다
- Star, Watch, Fork 숫자는 프로젝트의 인기도와 활성도를 보여 주는 지표로, 숫자가 클수록 많은 개발자가 관심을 갖고 있다는 의미다
- LGTM, WIP, nit, TL;DR 등 줄임말은 코드 리뷰와 협업 과정에서 소통을 빠르게 하기 위한 관용 표현이다
- 포팅, 리팩토링, Deprecated, Legacy 같은 소프트웨어 일반 용어까지 함께 알아두면 깃허브 저장소의 설명과 이슈 토론을 훨씬 수월하게 읽을 수 있다
깃허브를 처음 접한다면 먼저 관심 있는 프로젝트의 README를 읽고, Star를 눌러 북마크한 뒤, Issue 탭에서 good first issue 라벨이 붙은 항목을 찾아보는 것이 가장 자연스러운 첫 걸음이다.