비개발자를 위한 GitHub 첫걸음 - 04. 비개발자가 꼭 알아야 할 핵심 개념 7가지
핵심 요약
GitHub 용어는 기술 용어처럼 보여도, 실제로는 협업 과정에서 각 단계가 맡는 역할 이름에 가깝다.
issue는 요청,branch는 안전한 작업대,pull request는 검토 요청처럼 역할로 기억하면 훨씬 쉽다.
GitHub가 어렵게 느껴지는 가장 큰 이유 중 하나는 용어입니다.
하지만 단어를 기술적으로 외우려 하면 더 헷갈립니다.
입문자에게는 기능보다 역할로 기억하는 편이 훨씬 쉽습니다.
먼저 한눈에 보면 이렇습니다.
| 용어 | 쉽게 말하면 | 비유 |
|---|---|---|
| Repository | 프로젝트 작업 공간 | 협업 방, 자료실 |
| Commit | 변경 기록 한 번 | 체크포인트, 스냅샷 |
| Branch | 따로 작업하는 갈래 | 원본 옆 초안 테이블 |
| Issue | 해야 할 일이나 요청 | 티켓, 요청 카드 |
| Pull Request | 반영해도 되는지 묻는 단계 | 수정안 제출서 |
| Merge | 공식본에 합치기 | 초안을 최종본에 반영 |
| Review | 읽고 의견을 주는 과정 | 결재 전 검토, 피드백 |
이제 하나씩 보겠습니다.
1. Repository
쉬운 정의
관련 파일과 기록이 모여 있는 프로젝트 단위 작업 공간입니다.
이렇게 기억하면 쉽다
그냥 폴더라고 생각하면 절반만 맞습니다.
파일뿐 아니라 변경 이력, 이슈, 리뷰 기록까지 함께 남는 협업 방에 더 가깝습니다.
비개발자 예시
- 고객센터 운영 문서 모음
- 브랜드 가이드 저장소
- 서비스 정책 문서 프로젝트
2. Commit
쉬운 정의
변경 내용을 한 번 기록으로 남기는 것입니다.
이렇게 기억하면 쉽다
일반적인 저장보다 조금 더 강한 개념입니다.
“이 상태를 나중에 다시 볼 수 있게 남긴다”는 체크포인트에 가깝습니다.
비개발자 예시
FAQ 문장에서 배송 안내 표현을 바꾸고,
배송 안내 문구를 더 쉽게 수정 같은 메시지와 함께 저장하는 장면입니다.
3. Branch
쉬운 정의
원본을 바로 바꾸지 않고, 따로 갈라진 작업 공간에서 수정하는 방식입니다.
이렇게 기억하면 쉽다
공식 문서를 바로 고치기 전에 복사본 초안에서 먼저 작업한다고 생각하면 됩니다.
다만 완전히 별개 문서라기보다, 원본에서 잠시 갈라져 나온 작업선에 가깝습니다.
비개발자 예시
운영 매뉴얼 원본은 그대로 두고,
4월 개정안이라는 작업 갈래에서 먼저 수정해보는 상황입니다.
4. Issue
쉬운 정의
해야 할 일, 문제, 요청사항, 아이디어를 적어두는 티켓입니다.
이렇게 기억하면 쉽다
버그 신고서만이 아닙니다.
실무에서는 오히려 업무 요청 카드처럼 쓰는 경우가 많습니다.
비개발자 예시
- 회원가입 안내 문구를 더 쉽게 고치기
- 운영 매뉴얼에 최신 정책 반영하기
- 랜딩페이지 혜택 문장 수정안 논의하기
5. Pull Request
쉬운 정의
내가 작업한 내용을 원본에 반영해도 되는지 검토를 요청하는 단계입니다.
이렇게 기억하면 쉽다
“수정 완료”보다 “수정안을 제출했으니 검토해주세요”에 더 가깝습니다.
비개발자 예시
정책 문구 개정안을 올리고, 담당자에게 확인 후 반영해달라고 요청하는 장면입니다.
6. Merge
쉬운 정의
검토가 끝난 수정안을 원본에 합치는 것입니다.
이렇게 기억하면 쉽다
초안에서 작업한 내용을 공식본에 반영하는 순간입니다.
즉 Pull Request가 제출이라면 Merge는 최종 반영입니다.
비개발자 예시
리뷰를 마친 FAQ 수정안이 메인 문서에 들어가는 상황입니다.
7. Review
쉬운 정의
다른 사람이 변경 내용을 읽고 의견을 주거나 승인하는 과정입니다.
이렇게 기억하면 쉽다
틀린 것을 잡아내는 심사만이 아닙니다.
더 나은 표현과 더 안전한 반영을 위한 대화 과정에 가깝습니다.
비개발자 예시
PM이 문구 수정안을 보고
“이 표현은 조금 더 부드럽게 바꿔주세요”라고 코멘트하는 장면입니다.
이 일곱 개만 연결해서 기억해도 충분하다
한 줄로 이어서 외우면 더 쉽습니다.
Issue로 요청을 남긴다.Branch에서 따로 작업한다.Commit으로 기록을 남긴다.Pull Request로 검토를 요청한다.Review로 의견을 주고받는다.- 괜찮으면
Merge로 공식 반영한다.
즉 어려운 용어처럼 보여도 결국은 요청하고, 따로 작업하고, 기록 남기고, 검토받고, 합치는 과정입니다.
이 감각만 잡히면 GitHub 화면을 볼 때도 “이 버튼이 무슨 기술 기능이지?”보다 “지금 협업 흐름에서 어느 단계지?”라고 읽을 수 있게 됩니다.