깃허브(Git Hub) Pull Request란..
Git · GitHub · 바이브코딩 개념 정리
풀 리퀘스트(Pull Request, PR)는 “내가 코드를 수정했으니, 이걸 메인 코드에 합쳐도 되는지 검토해 주세요”라고 요청하는 기능입니다. 이 글에서는 PR이 무엇인지, PR을 쓰는 방식과 쓰지 않는 방식이 어떻게 다른지, 그리고 1인 개발자에게 어떤 조합이 좋은지 차례로 정리합니다.
1. 풀 리퀘스트란 무엇인가
PR은 “내가 고친 코드를 메인에 반영해 줄 수 있겠느냐”는 검토 요청입니다. 이름이 낯설어서 어렵게 느껴지지만, 실제로 하는 일은 병합(Merge) 요청입니다.
기본 흐름
- 메인 코드(
main브랜치)는 그대로 두고, 별도의 브랜치를 만들어 그 안에서 수정합니다. - 수정이 끝나면 GitHub에서 “이 브랜치를 main에 합쳐 주세요”라고 PR을 올립니다.
- 다른 사람(또는 본인)이 변경된 부분을 한눈에 비교해 보고, 댓글로 의견을 남기거나 수정을 요청합니다.
- 문제가 없으면 Merge(병합)해서 메인 코드에 반영합니다.
세무 업무에 비유하면
신고서를 바로 제출하지 않고, 검토용 초안을 따로 만들어 수정 전후를 대조한 뒤, 이상이 없을 때 확정본에 반영하는 절차와 비슷합니다.
용어의 유래
“풀 리퀘스트”라는 이름은 “내 브랜치의 변경 내용을 당신 쪽으로 끌어가(pull) 달라고 요청(request)한다”는 뜻에서 나왔습니다. 실제로 하는 일은 병합 요청이라, GitLab처럼 “Merge Request”라고 부르는 서비스도 있습니다.
2. PR이 주는 이점
- 변경 내용 비교: 어떤 파일의 어느 줄이 추가·삭제·수정됐는지 색깔로 표시됩니다.
- 검토와 토론: 특정 줄에 댓글을 달아 질문하거나 수정을 요청할 수 있습니다.
- 안전장치: 검토 전에는 메인 코드가 바뀌지 않아, 오류가 있는 코드가 바로 반영되는 것을 막습니다.
- 이력 보존: 언제, 누가, 왜 바꿨는지 기록이 남습니다.
- 자동 검사 연동: 테스트나 빌드를 자동으로 돌려 통과 여부를 PR 화면에 보여 줄 수 있습니다.
3. 혼자 개발할 때도 PR이 필요할까
결론부터 말하면 1인 개발이라면 필수는 아닙니다. main에 바로 커밋해서 올려도 전혀 문제없습니다. 다만 다음과 같은 경우에는 혼자서도 PR을 쓰는 것이 도움이 됩니다.
- 운영 중인 서비스를 건드리는 큰 수정: 브랜치에서 작업하고 PR 화면으로 변경 내역을 확인한 뒤 병합하면, 문제가 생겼을 때 그 PR 단위로 되돌리기 쉽습니다.
- 변경 내역을 정리해 두고 싶을 때: 무엇을 왜 바꿨는지 기록이 남습니다.
- AI가 뭘 바꿨는지 확인하고 싶을 때: Claude Code 같은 AI 도구가 만든 수정 사항을, 터미널에서
git diff를 보는 것보다 편하게 색깔 비교 화면으로 훑어볼 수 있습니다.
평소 작은 수정은 main에 바로 올리고, 부담되는 큰 수정만 브랜치로 분리하는 정도면 충분합니다.
4. 가장 흔한 오해: “PR을 서버에서 하는 건가?”
PR은 서버에서 하는 것이 아니라 GitHub 웹사이트에서 만드는 것입니다.
운영 서버에서 git pull로 코드를 받아오는 동작과는 별개의 개념입니다.
헷갈리는 이유는 “pull”이라는 같은 단어 때문입니다.
- PR의 pull: “내 브랜치를 main으로 끌어가 달라”는 병합 요청
- 서버의
git pull: “GitHub에서 최신 코드를 내려받기”라는 다운로드 동작
이름은 같지만 완전히 다른 동작이며, PR로 병합이 끝나야 비로소 main이 바뀌므로 서버 배포는 항상 병합 이후입니다.
5. 두 가지 방식의 비교: 누가 판단하고, 어디서 확인하는가
“서버에서 코드를 끌어다가 머지 여부를 판정하는 것”과 “PR”은 서로 다른 흐름입니다. 두 방식의 차이는 “어디서 판단하고, 무엇을 근거로 하느냐”입니다.
공통 출발점 (두 방식 모두 동일)
- 로컬에서 브랜치 생성
- 수정 후 커밋
- GitHub로 푸시
git checkout -b 브랜치이름
# ... 수정 후 커밋 ...
git push -u origin 브랜치이름여기까지 하면 GitHub에는 main과 브랜치이름 두 개가 존재하고, 운영 코드(main)는 아직 아무 변화가 없습니다. 이제부터 두 방식이 갈립니다.
방식 APR을 쓰는 경우
핵심: 병합 판단을 GitHub 웹 화면에서 한다.
- GitHub 웹에서 PR 생성 (“Compare & pull request” 버튼)
- GitHub 웹 화면에서 변경 내역(색깔 비교)을 눈으로 확인
- 이상 없으면 GitHub에서 Merge 버튼 클릭 → GitHub의
main이 바뀜 - 서버에서
git pull→ 서버가 최신main을 받아 반영
- 판단하는 곳: GitHub 웹
- 판단 근거: 변경된 코드를 눈으로 본 것 (실제로 돌려 본 것은 아님)
- 서버가 하는 일: 병합이 끝난 뒤 결과물을 받기만 함
방식 BPR 없이 서버에서 확인하는 경우
핵심: 병합 판단을 서버에서 실제로 돌려 보고 한다.
- 서버에서 원격 정보만 가져오기 (코드는 아직 안 바뀜)
- 서버에서 브랜치로 전환 (서버 코드가 브랜치 코드로 바뀜)
- 서버에서 실제로 실행해 보며 테스트
- 이상 없으면 main으로 돌아와 병합한 뒤 GitHub에도 반영
- 이상 있으면 병합하지 않고 main으로 복귀
# 4. 원격 정보만 가져오기
git fetch origin
# (선택) 무엇이 다른지 확인
git diff main origin/브랜치이름
# 5. 브랜치로 전환 후 6. 실제로 돌려 보며 테스트
git checkout 브랜치이름
# 7. 문제없으면 main으로 돌아와 병합, GitHub에도 반영
git checkout main
git merge 브랜치이름
git push origin main
# 8. 문제 있으면 병합하지 않고 복귀
git checkout main- 판단하는 곳: 서버
- 판단 근거: 실제로 돌려 본 결과
- GitHub 웹은 전혀 사용하지 않음 (PR 기능을 쓰지 않는 방식)
방식 B에서 주의할 점
- 브랜치로 전환하는 순간 서버에서 돌아가는 코드가 그 브랜치 코드로 바뀝니다. 운영 중인 서비스라면 그 시간 동안 실제 서비스에 영향을 줄 수 있습니다.
- 그래서 서비스가 돌아가는 서버에서 시험하기보다는, 별도의 테스트 환경이나 로컬에서 확인하는 편이 안전합니다.
- 서버에서 직접 병합하면 GitHub의
main과 서버의main이 어긋납니다. 병합 후git push origin main으로 GitHub에도 반영해야 합니다.
한눈에 비교
| 방식 A (PR) | 방식 B (서버 확인) | |
|---|---|---|
| 병합하는 곳 | GitHub 웹 | 서버 (터미널) |
| 병합 전 확인 방법 | 변경 내역을 눈으로 확인 | 실제로 실행해 보며 확인 |
| 서버가 하는 일 | 병합 후 git pull만 |
브랜치를 받아 직접 테스트 후 병합 |
| 운영 서비스 영향 | 병합 전까지 없음 | 브랜치 전환 중 있음 |
| 변경 비교 | 웹 화면에서 색깔로 표시 | git diff 명령어 |
| 기록·댓글 | 남음 | 남지 않음 |
6. 1인 개발자에게 추천하는 조합
두 방식은 합쳐서 쓸 수도 있습니다. 눈으로 보는 검토(PR)와 실제로 돌려 보는 검증(서버 테스트)은 서로 보완 관계이기 때문입니다.
- 로컬에서 브랜치 작업 후 푸시
- 서버에서 브랜치를 받아 실제로 테스트 (방식 B의 4~6단계)
- 문제없으면 서버에서 병합하거나, GitHub에서 PR로 병합한 뒤 서버에서
git pull
안전하게 하려면
운영 중인 서버에서 브랜치를 전환하면 서비스에 영향을 줄 수 있으니, 서버에 테스트용 폴더를 따로 만들어 그곳에서 브랜치를 받아 확인하는 방법이 안전합니다.
7. Claude Code에 시키면 어디까지 해 줄까
Claude Code에 “브랜치 만들어서 푸시하고 PR까지 올려줘”라고 시키면 브랜치 생성, 커밋, 푸시, PR 생성까지 대신 처리해 줍니다. 그러면 직접 할 일은 GitHub에서 내용을 확인하고 Merge 버튼을 누르는 것뿐입니다.
정리
- PR은 “내 브랜치를 main에 합쳐도 되는지 검토해 달라”는 병합 요청이며, GitHub 웹에서 만듭니다.
- 서버의
git pull은 PR과 별개로, 최신 코드를 내려받는 동작입니다. - PR은 눈으로 검토하고 기록을 남기는 방식, 서버 확인은 실제로 돌려 보고 판단하는 방식입니다.
- 1인 개발이라면 PR은 필수가 아니며, 큰 수정이나 AI가 대량으로 고친 코드를 확인할 때 골라 쓰면 충분합니다.