GitHub 개요와 필요성
읽는 시간: 약 7분 · 버전: v0.4 (2026-09-21) · GitHub 가이드 1편
그림으로 먼저 보고 싶다면 0편(3분)부터 보세요. 이 문서는 "왜 쓰는가"와 "우리 업무와 무엇이 닮았는가"만 다룹니다.
한 줄 요약
GitHub(깃허브)는 "변경 이력이 남는 회사 공용 폴더"입니다.
보고서를 쓰면서 버전을 남기고, 공용 폴더에 올리고, 결재를 받는 과정을 프로그램이 관리해 주는 서비스라고 생각하면 됩니다.
1. 필요성
문서 한두 개라면 보고서_최종_진짜최종.hwp 식으로도 버틸 수 있습니다. 하지만 우리가 만들 업무 도구(프로그램)는 파일 수십~수백 개가 서로 맞물려 돌아가고, 그 파일을 고치는 것은 주로 AI입니다. AI는 한 번에 파일 열 개를 바꾸기도 합니다.
| GitHub를 쓰면 | 쉽게 말하면 |
|---|---|
| 이력이 남습니다 | 커밋할 때마다 누가, 언제, 무엇을, 왜 바꿨는지 기록됩니다. 파일 이름에 _최종 을 붙일 필요가 없습니다 |
| 되돌릴 수 있습니다 | 잘못된 변경은 취소할 수 있습니다. AI가 일을 망쳐 놓아도 수습할 방법이 있습니다 |
| 확인한 것만 반영됩니다 | 작업 중인 버전과 실제로 쓰는 버전을 나눕니다. 팀장이 검토한 것만 실제 버전에 들어갑니다 |
| PC 밖에도 남습니다 | 푸시해 둔 작업은 PC가 고장 나도 GitHub에 남습니다 |
2. 보고서 작성·결재 과정과의 비교
보고서를 쓸 때 우리는 이렇게 합니다. 초안을 고치다가 중간중간 보고서_v2_표추가.hwp 처럼 버전을 따로 남기고, 공용 폴더에 올려 두고, 다 되면 결재를 올립니다. 결재가 끝난 최종본은 함부로 고치지 않습니다.
| GitHub 용어 | 보고서 업무로 치면 | 뜻 |
|---|---|---|
| 저장소(repository, repo) | 보고서 하나의 작업 폴더 | 프로젝트 하나를 통째로 담는 폴더 |
| 커밋(commit) | 버전을 남기고 무엇을 고쳤는지 메모하기 | "여기까지 저장"이라고 도장을 찍는 것. 한 줄 메모를 함께 남깁니다 |
| 푸시(push) | 공용 폴더에 올려 두기 | 내 PC에 찍어 둔 커밋을 GitHub에 올리는 것 |
| 풀(pull) | 공용 폴더에서 최신 파일 받기 | GitHub에 새로 올라온 내용을 내 PC로 내려받는 것 |
work 브랜치 | 작성 중인 초안 | 자유롭게 고치는 작업본 |
main 브랜치 | 결재가 끝난 최종본 | 팀장이 병합한 내용만 들어오는 완성본 |
| PR(Pull Request) | 결재 올리기 | "작업본을 완성본에 반영해 주세요"라는 요청 |
브랜치(branch)는 같은 저장소 안에 있는 "또 하나의 본"입니다.
work와main은 붙이기 나름인 이름표입니다.main은 GitHub의 기본 이름이고,work는 우리 TF가 정했습니다. 브랜치를 이 두 개만 쓰는 것, 병합을 팀장만 하는 것은 GitHub의 제약이 아니라 우리 TF의 규칙입니다.
한 가지 다른 점이 있습니다. 보고서는 버전을 남길 때마다 파일이 v2, v3 로 늘어나지만, GitHub에서는 파일은 하나인 채로, 커밋할 때마다 무엇이 어떻게 바뀌었는지가 글자 단위로 기록됩니다. 우리는 "왜 바꿨는지" 한 줄만 적으면 됩니다.
3. 전체 흐름
- 작업은 내 PC에서 합니다. GitHub 웹사이트에서 직접 코드를 고치지 않습니다.
- 평소에는 커밋 → 푸시만 합니다.
- "이제 실제로 써도 되겠다" 싶을 때만 PR을 올립니다.
- 그 뒤는 세 단계로 나뉩니다. ① 팀장이 검토·승인 → ② 팀장이 병합(
main에 반영) → ③ 사내 서버에 배포. 승인했다고 바로 서버에 올라가는 것이 아니라, 배포는 병합 뒤의 별도 단계입니다.
4. AI TF에서의 필요성
- AI와 일하기 때문입니다. AI는 빠르지만 가끔 잘 되던 것을 망가뜨립니다. 커밋을 자주 해 두면 잘못된 변경을 찾아 취소하기 쉽습니다.
- 원격으로 일하기 때문입니다. 푸시해 둔 내용을 보고 팀장이 진행 상황을 파악하고, 막힌 곳을 도와줍니다.
- 직원들이 쓸 도구를 만들기 때문입니다. 검토되지 않은 버전이 실제 서버에 올라가면 안 됩니다. PR과 팀장 병합이 그 안전장치입니다.
5. 자주 묻는 질문
Q. 잘못 눌러서 망가뜨리면 어떻게 되나요?
실수해도 괜찮습니다. 연습은 실제 프로젝트와 분리된 연습장(tf-sandbox)에서 하고, 실제 프로젝트의 완성본(main)은 팀장의 병합을 거쳐야만 바뀌도록 운영합니다. 실수했다면 더 진행하기 전에 알려 주세요. 복구 방법을 함께 확인합니다.
Q. 코드를 읽을 줄 모르는데 괜찮나요?
코드를 전부 이해할 필요는 없습니다. 다만 결과를 확인할 책임은 있습니다. 예상하지 못한 파일이 바뀌지 않았는지, 실행해 보니 요청한 대로 동작하는지, 민감한 자료가 섞이지 않았는지를 확인합니다. 코드 자체는 팀장이 봅니다.
Q. 제 작업이 회사 밖에 공개되나요?
저장소는 비공개로 운영합니다. 비공개란 "초대받아 권한이 있는 계정만 볼 수 있다"는 뜻입니다. 회사 네트워크 안에서만 열린다는 뜻은 아니므로, 계정 보안과 "회사 PC에서만 작업한다"는 TF 규칙을 지켜야 합니다. TF 구성원끼리는 서로의 프로젝트를 볼 수 있습니다.
Q. 아무 파일이나 올려도 되나요?
안 됩니다. 비밀유지계약(NDA) 자료, 개인정보, 입찰·견적 정보, 비밀번호는 올리지 않습니다. 한번 올라간 자료는 파일을 지워도 이력에 남습니다. 자세한 내용은 5편. GitHub 이용 규칙에 있습니다.
가이드 전체 구성
| 편 | 문서 | 내용 |
|---|---|---|
| 0 | 한눈에 보는 Git과 GitHub | 그림 열 장으로 보는 전체 흐름 |
| 1 | GitHub 개요와 필요성 (이 문서) | 왜 쓰는지, 보고서 업무와의 비교 |
| 2 | 계정과 프로그램 준비 | 계정, 설치, 연습장 내려받기 |
| 3 | 기본 실습 | 커밋, 푸시, 되돌리기, PR |
| 4 | Git 기본 개념 | 실습한 내용의 원리 |
| 5 | GitHub 이용 규칙 | 작업 흐름과 지켜야 할 규칙 |
| 6 | 한 장 요약 | 인쇄용 A4 한 장 |
| 7 | 브랜치 분기와 충돌 대처 | 브랜치의 원리, 충돌 안내가 떴을 때 |
이어서 읽기
- 다음 편: 2편. 계정과 프로그램 준비 — 계정, 설치, 연습장 내려받기
- 전체 목록: 가이드 전체 구성