개념 정리
버전 관리·협업·배포까지, 비개발자가 가장 자주 마주치는 깃허브 용어를 일상 비유로 풀어낸다. 한 번 개념을 잡아두면 더 이상 “커밋할까요?”라는 물음이 무섭지 않다.
직접 코드를 짜지 않고도 인공지능에게 시켜 프로그램을 만드는 방식이 보편화되면서, 비개발자가 갑자기 마주치는 관문이 하나 있다. 바로 깃허브(GitHub)다. 내 컴퓨터 안에서만 돌아가던 결과물을 인터넷에 올려 누구나 접속할 수 있게 만들려고 하면, 어김없이 “깃허브에 올리세요”라는 안내가 나온다. 그런데 막상 들어가 보면 리포지토리, 커밋, 푸시, 풀, 브랜치, 포크 같은 낯선 단어가 줄줄이 등장한다.
이 단어들은 사실 어렵지 않다. 대부분 우리가 이미 쓰고 있는 클라우드 문서 도구의 기능과 일대일로 대응되기 때문이다. 이 글은 코드를 한 줄도 몰라도 깃허브의 핵심 개념을 끝까지 이해할 수 있도록, 각 용어를 일상적인 비유와 그림으로 차근차근 풀어낸다.
깃허브는 “개발자들이 쓰는 구글 드라이브”다. 다만 파일을 보관만 하는 게 아니라, 누가·언제·무엇을 바꿨는지를 통째로 기록하고 여럿이 안전하게 함께 작업하도록 돕는 데 특화되어 있다.
가장 먼저 짚어야 할 혼동이 하나 있다. ‘깃’과 ‘깃허브’는 같은 말이 아니다. 둘을 구분하면 나머지 개념이 훨씬 또렷해진다.
깃(Git)은 2005년에 만들어진 버전 관리 프로그램이다. 파일이 시간에 따라 어떻게 바뀌었는지를 추적하고, 원하면 과거 어느 시점으로든 되돌릴 수 있게 해 준다. 깃은 인터넷 없이 내 컴퓨터 안에서도 완전히 작동한다. 사진 편집 프로그램이 ‘설치해서 쓰는 도구’이듯, 깃도 컴퓨터에 설치해서 쓰는 도구다.
깃허브(GitHub)는 그 깃을 인터넷에서 함께 쓰도록 만든 웹 서비스다. 깃이 만들어 낸 기록을 클라우드에 올려 보관하고, 여러 사람이 같은 프로젝트를 들여다보며 협업하게 해 준다. 깃 자체에는 사용자 권한 관리나 승인 같은 기능이 없는데, 깃허브가 그 위에 협업에 필요한 살을 붙인 셈이다. 비슷한 역할을 하는 다른 웹 서비스도 여럿 있지만, 가장 널리 쓰이는 것이 깃허브다.
깃은 문서를 편집하는 워드 프로그램, 깃허브는 그 문서를 보관하고 공유하는 구글 드라이브에 가깝다. 워드 없이 드라이브에 파일만 둘 수도 있고, 드라이브 없이 워드로 혼자 작업할 수도 있다. 하지만 둘을 함께 쓰면 ‘편집’과 ‘공유’가 자연스럽게 이어진다.
정리하면, 깃은 ‘무엇이 바뀌었는지 기록하는 엔진’이고 깃허브는 ‘그 기록을 모아 함께 보는 광장’이다. 흔히 둘을 섞어 부르지만, 우리가 웹 화면에서 보고 클릭하는 거의 모든 것은 깃허브의 기능이라고 보면 된다.
깃허브에서 처음 만드는 것이 리포지토리(repository)다. 그냥 폴더라고 하면 될 것을 왜 굳이 이렇게 부를까.
리포지토리의 사전적 뜻은 ‘저장소·보관소’다. 겉보기에는 파일을 담는 폴더와 똑같다. 결정적인 차이는 과거를 기억하는가에 있다. 보통의 폴더는 지금 이 순간의 최신 상태만 보여 준다. 어제 파일이 어떤 모습이었는지, 누가 무엇을 지웠는지는 남지 않는다. 반면 리포지토리는 파일이 거쳐 온 모든 변경 이력을 함께 보관한다. 언제 어떤 줄이 추가됐고 어떤 줄이 사라졌는지까지 전부 들여다볼 수 있다.
프로그램의 소스 코드는 결국 글자로 된 문서의 묶음이다. 이 문서 묶음을 통째로, 그리고 그 변천사까지 함께 담아 두는 단위가 리포지토리다. 보통은 프로그램 하나에 리포지토리 하나를 둔다. A라는 프로그램을 만들면 A 리포지토리에, B라는 프로그램을 만들면 B 리포지토리에 보관하는 식이다.
리포지토리는 글을 쓸 때마다 자동으로 모든 판본을 따로 보관해 주는 ‘무한 되돌리기가 되는 폴더’다. 일반 폴더가 ‘최종.docx’ 하나만 남긴다면, 리포지토리는 ‘최종’, ‘진짜최종’, ‘이게진짜최종’을 시간 순서대로 전부 간직하고, 언제든 원하는 판본으로 깔끔하게 되돌아갈 수 있게 해 준다.
처음 깃허브를 다룰 때 가장 겁나는 단어가 이 셋이다. 하지만 세 동작은 “저장하고, 올리고, 내려받는다”라는 한 줄짜리 흐름일 뿐이다.
먼저 큰 그림을 기억하자. 작업은 내 컴퓨터(로컬)에서 하고, 그 결과를 깃허브(원격)에 올려 보관한다. 아래 그림이 그 왕복 구조다.
커밋(commit)은 ‘저장’에 가장 가깝다. 다만 단순히 파일을 덮어쓰는 저장이 아니라, “지금 이 상태를 하나의 판본으로 기록해 두겠다”는 선언이다. 워드에서 Ctrl+S를 누르면 현재 내용이 저장되지만 이전 모습은 사라진다. 반면 커밋은 누를 때마다 그 순간의 스냅샷을 하나씩 차곡차곡 쌓는다. 그래서 나중에 “세 단계 전 모습으로 돌려 줘”가 가능하다. 커밋을 할 때 “무엇을 왜 바꿨는지”를 한 줄 메모(커밋 메시지)로 남기는 것도 이 때문이다.
커밋은 어디까지나 내 컴퓨터 안의 일이다. 이 기록을 깃허브(원격 저장소)로 올려 보관하고 남들과 공유하는 동작이 푸시(push)다. 회사에서 작업한 커밋들을 푸시해 두면, 집에 와서 같은 리포지토리를 열어 이어서 작업할 수 있다.
푸시의 반대 방향이 풀(pull)이다. 원격에 올라와 있는 최신 변경을 내 컴퓨터로 끌어내려, 내 작업 환경을 최신 상태로 맞추는 동작이다. 여럿이 함께 작업할 때는 “남이 올린 변경을 풀로 받고, 내가 한 작업을 푸시로 올린다”가 하루의 기본 리듬이 된다.
커밋은 내 안에서의 저장, 푸시는 위로 올리기, 풀은 아래로 내려받기다. 이 세 동작이 돌아가며 ‘여러 컴퓨터·여러 사람의 작업’을 하나로 모은다.
브랜치(branch)는 말 그대로 ‘가지’다. 본체를 건드리지 않고 곁가지에서 따로 작업하기 위한 장치다.
프로그램은 사용자가 쓰는 동안에도 늘 멀쩡하게 돌아가야 한다. 그런데 새 기능을 넣다가 중간에 망가지면 곤란하다. 그래서 본체(보통 main이라 부른다)는 그대로 살려 두고, 옆으로 가지를 하나 쳐서 그 위에서 마음껏 실험한다. 작업이 끝나고 문제가 없다는 것이 확인되면, 그 가지를 본체에 다시 합친다. 이 합치는 동작을 병합(merge)이라고 한다.
여럿이 함께 작업할 때는 브랜치를 보통 ‘기능 단위’로 나눈다. 한 사람은 1번부터 5번 기능을, 다른 사람은 6번부터 10번 기능을 각자 다른 가지에서 만들면, 서로의 작업이 뒤엉키지 않는다. 가지 이름만 봐도 “아, 이 가지는 결제 기능을 만드는 작업이구나” 하고 알 수 있어 관리가 쉬워진다.
완성된 보고서 원본은 그대로 두고, ‘사본’을 떠서 거기서 문장을 고쳐 보는 것과 같다. 사본에서 고친 결과가 마음에 들면 원본에 반영하고, 영 아니면 사본만 버리면 된다. 원본은 그동안 한 번도 위험해지지 않는다.
규모가 작고 혼자 하는 단순한 작업이라면 가지를 나누지 않아도 된다. 브랜치는 프로젝트가 커지고 사람이 늘수록 진가를 발휘하는, ‘선택적 안전장치’에 가깝다.
가지에서 만든 작업을 본체에 합치기 직전, 한 번 확인을 거치게 하는 장치가 풀 리퀘스트(Pull Request, 줄여서 PR)다.
이름이 다소 헷갈리지만 핵심은 단순하다. 풀 리퀘스트는 “내가 이 가지에서 이런 변경을 했는데, 검토하고 본체에 합쳐 주세요”라는 공식 요청이다. 요청을 받은 사람은 무엇이 어떻게 바뀌었는지 한눈에 비교해 보고, 의견을 달거나 수정을 부탁하거나, 괜찮으면 승인해서 병합한다.
이것이 보통의 클라우드 문서와 깃허브가 갈리는 지점이다. 클라우드 문서는 편집 권한을 가진 사람이 곧바로 원본을 바꿀 수 있다. 깃허브는 그 사이에 ‘검토와 승인’이라는 관문을 둘 수 있다. 같은 리포지토리에서 둘이 작업하다 한 사람이 무심코 중요한 부분을 덮어써 버리는 사고를, 풀 리퀘스트가 미리 막아 준다.
가지를 친다(브랜치) → 그 위에서 작업하고 저장한다(커밋) → 원격에 올린다(푸시) → “합쳐 주세요”라고 요청한다(풀 리퀘스트) → 검토 후 본체에 합친다(병합). 이 다섯 단계가 협업의 표준 리듬이다.
개념이 가장 자주 헷갈리는 한 쌍이다. 포크(fork)와 클론(clone)은 모두 ‘남의 리포지토리를 복사’하지만, 복사본이 놓이는 위치가 완전히 다르다.
클론(clone)은 원격 리포지토리를 내 컴퓨터로 통째로 내려받는 동작이다. 단순 다운로드와 결정적으로 다른 점은 ‘연결’이다. 그냥 다운로드한 파일은 원본과의 끈이 끊겨 있어, 이후 원본이 바뀌어도 알 길이 없다. 반면 클론한 복사본은 원본과 연결고리를 유지한다. 그래서 앞서 본 푸시·풀로 원본과 변경을 주고받을 수 있다. 개발 작업은 내 컴퓨터 환경에서 코드를 열고 돌려 봐야 하므로, 작업을 시작하려면 먼저 클론으로 내 손 안에 가져오는 것이 보통이다.
포크(fork)는 원본을 깃허브 안에서 내 계정으로 복사해, 독립된 별도의 리포지토리를 만드는 동작이다. 복사본은 내 소유가 되고, 원본 주인의 허락 없이도 마음대로 고칠 수 있다. 다만 원본의 이후 변경이 자동으로 따라오지는 않는다. 출발점이 같았을 뿐, 이제부터는 갈라져 나간 별개의 프로젝트로 자라난다.
그렇다면 포크는 왜 필요할까. 공개된 좋은 프로젝트를 토대로 “나는 여기에 우리 상황에 맞는 기능을 더 얹고 싶다”거나 “원본과는 다른 방향으로 발전시키고 싶다”고 할 때, 원본을 건드리지 않으면서 내 버전을 출범시키는 방법이 포크다. 어떤 프로젝트가 많이 포크되었다는 것은 그만큼 많은 사람이 그것을 출발점으로 삼았다는 뜻이라, 만든 사람에게는 일종의 인정 지표가 되기도 한다.
클론은 “내 컴퓨터로 가져와 같이 작업”, 포크는 “깃허브 안에 내 것으로 떠서 따로 발전”. 위치(내 PC ↔ 깃허브 내 계정)와 연결 여부(유지 ↔ 단절)가 둘을 가른다.
깃허브는 코드만 담는 곳이 아니다. ‘무엇을 고쳐야 하는지’와 ‘무엇을 만들 차례인지’를 함께 관리한다.
이슈(issue)는 말 그대로 ‘안건’이다. 프로그램을 쓰다 “여기서 오류가 났어요, 고쳐 주세요”라거나 “이런 기능이 있으면 좋겠어요” 같은 요청을 하나씩 등록해 두는 곳이다. 협업 도구에서 ‘할 일 카드’를 만들어 붙이는 것과 똑같다. 누구나 이슈를 올리고, 담당자가 그것을 보고 처리한다. 인기 있는 공개 프로젝트에는 이런 이슈가 수천 건씩 쌓이기도 한다.
프로젝트(project)는 그 이슈들과 작업을 ‘진행 중·완료’ 같은 칸으로 나눠 한눈에 관리하는 보드다. 별도의 일정 관리 도구를 쓰지 않아도, 깃허브 안에서 작업의 전체 그림을 정리할 수 있게 해 준다.
흥미로운 점은, 이 도구가 꼭 ‘코드’에만 쓰이지는 않는다는 것이다. 어떤 공공기관은 자기 지역의 법령 문서를 깃허브에 올려 두고, 시민들이 “이 조항을 이렇게 고쳐 달라”고 이슈로 제안하도록 운영하기도 한다. 민원 창구처럼 쓰는 셈인데, 모든 변경 이력과 토론이 공개적으로 남는다는 점이 일반 게시판과 다르다. 글자로 된 문서이고 ‘버전 관리’가 필요한 것이라면, 코드가 아니어도 깃허브의 무대에 오를 수 있다.
포크 이야기에서 빠질 수 없는 것이 오픈소스(open source)와 라이선스(license) 개념이다.
오픈소스란 소스 코드를 공개해 누구나 보고, 쓰고, 고칠 수 있게 한 소프트웨어를 말한다. 무언가를 공개한다는 것은 단순히 보여 주는 데 그치지 않는다. 거기엔 ‘이걸 어떤 조건으로 써도 되는가’라는 약속이 따라붙는데, 그 약속을 명문화한 것이 라이선스다. 라이선스에는 여러 종류가 있어서, 어떤 것은 “출처만 밝히면 상업적으로 써도 좋다”고 하고, 어떤 것은 “고친 결과물도 똑같이 공개해야 한다”는 조건을 단다.
공들여 만든 발표 자료 디자인 템플릿을 공개해 두는 것과 비슷하다. 돈을 받고 팔 생각이었다면 애초에 공개하지 않았을 것이다. 공개했다는 것 자체가 “가져다 당신 스타일대로 고쳐 써도 좋다”는 뜻이다. 그 ‘써도 되는 조건’을 적어 둔 안내문이 라이선스다.
그래서 누군가 내 공개 프로젝트를 포크해 가는 것은 보통 기분 좋은 일이다. 공개한 시점에서 이미 “자유롭게 가져다 쓰라”고 허락한 것이고, 많이 포크될수록 그만큼 쓸모를 인정받았다는 신호이기 때문이다. 잘 알려진 인터넷 백과사전이 ‘누군가 올린 지식을 다른 사람이 가져다 더 키우는’ 방식으로 자라는 것과 닮았다.
비개발자가 깃허브를 권유받는 가장 큰 이유가 바로 이 ‘배포(deploy)’ 때문이다.
인공지능에게 시켜 무언가를 만들면 처음엔 내 컴퓨터 안에서만 돌아간다. 이걸 다른 사람도 인터넷으로 접속해 쓰게 하려면, 24시간 켜져 있는 컴퓨터(서버)에 올려야 한다. 이 ‘올려서 작동시키는’ 과정이 배포다. 예전에는 서버를 직접 구하고 설정하는 일이 만만치 않았다. 그런데 지금은 깃허브와 호스팅 서비스를 연결해 두면, 이 과정의 대부분이 자동으로 처리된다.
구체적으로는 이렇다. 깃허브 리포지토리에 배포용 호스팅 서비스를 한 번 연결해 둔다. 그러면 이후로는 리포지토리에 변경을 푸시할 때마다, 호스팅 서비스가 그 변경을 감지해 자동으로 프로그램을 다시 만들고(빌드) 인터넷에 올린다. 사람이 매번 서버에 접속해 파일을 옮기는 수고가 사라지는 것이다. 이렇게 코드 변경부터 사이트 반영까지를 자동으로 잇는 방식을 흔히 지속적 배포(Continuous Deployment, CD)라고 부른다.
이 편리함이야말로 비개발자에게 깃허브가 거듭 추천되는 핵심 이유다. 깃허브가 협업 기록의 중심이면서, 동시에 ‘배포의 출발점’ 역할까지 해 주기 때문이다.
“이거 돈 드나요?”라는 물음에 대한 답은 분명하다. 개인이 쓰는 범위라면 무료로 충분하다.
깃허브는 무료 요금제와 유료 요금제를 함께 운영한다. 그런데 무료 요금제만으로도 개인·소규모 작업에는 부족함이 거의 없다. 무료 요금제에서도 공개·비공개 리포지토리를 사실상 무제한으로 만들 수 있고, 협업자도 제한 없이 둘 수 있다. 유료 요금제는 주로 팀이나 기업이 필요로 하는 보안·관리 기능, 자동화 작업량 확대 등에서 차이가 난다. 2026년 기준으로 팀용 요금제는 사용자당 월 4달러 안팎, 대규모 조직용은 사용자당 월 21달러 수준에서 시작한다.
처음 시작하는 사람이라면 고민할 것 없이 무료로 가입해서 쓰면 된다. 회사·팀 단위로 보안 관리가 필요해지는 시점이 오면, 그때 유료 전환을 검토해도 늦지 않다.
지금까지 나온 개념은 거의 모두 ‘협업’을 위한 것이었다. 그렇다면 혼자 작업하는 사람에게도 깃허브가 필요할까.
엄밀히 말하면, 정말 나 혼자만 보고 끝낼 작업에는 깃허브가 꼭 필요하진 않다. 그럼에도 혼자 하는 사람에게까지 깃허브가 권장되는 데는 두 가지 현실적인 이유가 있다.
첫째, 배포 때문이다. 앞서 보았듯 내 결과물을 인터넷에 띄우려면 깃허브를 거치는 길이 가장 매끄럽다. 푸시 한 번으로 사이트가 갱신되는 편리함은 혼자 하는 사람에게도 그대로 적용된다.
둘째, 가장 널리 쓰이기 때문이다. 많은 사람이 쓰는 도구일수록 안내 문서와 사례가 풍부하고, 인공지능 도구도 그만큼 더 잘 다룬다. 여러 비슷한 서비스를 일일이 비교하며 공부하기보다, 표준처럼 자리 잡은 깃허브를 쓰는 편이 결국 시간을 아낀다.
깃허브의 용어들이 처음에 낯선 것은, 그것이 ‘새로운 개념’이어서가 아니라 ‘익숙한 개념에 낯선 이름이 붙어서’다. 리포지토리는 이력이 남는 폴더, 커밋은 한 시점의 저장, 푸시와 풀은 올리고 내려받기, 브랜치는 가지치기, 포크와 클론은 위치가 다른 복사다. 한 번 이 대응 관계를 손에 쥐고 나면, “커밋할까요?”라는 물음에 더는 긴장하지 않게 된다. 나머지는 직접 한두 번 눌러 보며 익히면 되는, 그저 도구일 뿐이다.