GitHub PR 올리기 전 / 욕 안 먹는 5분 점검 리스트

GitHub PR(Pull Request) 올리기 전 점검은 신입 개발자라면 반드시 습관을 들여야 하는 과정입니다. PR은 단순히 코드를 서버에 밀어 넣는 것이 아니라, 리뷰어에게 내 코드를 설득하고 검토를 요청하는 '협업의 시작점'이기 때문입니다. 이 글에서는 불필요한 코드 리뷰 핑퐁을 줄이고, 깔끔하게 머지(Merge)를 받아낼 수 있는 핵심 점검 순서를 정리했습니다.

자주 보이는 증상

• 리뷰어에게 "이 파일은 왜 수정된 건가요?", "콘솔 로그 지워주세요" 등 기능 외적인 지적을 반복해서 받음
• 기능 구현 완료 후 PR을 올렸는데 깃허브 화면에 'Resolve conflicts'라는 붉은 충돌 경고가 뜸
• PR 본문이 비어 있거나 '기능 수정'이라고만 덩그러니 적혀 있어, 리뷰어가 어디부터 봐야 할지 헤맴

왜 이런 문제가 생길까

1) 작업에 몰두해 '리뷰어 관점'을 잊어버림

코드를 짜다 보면 버그를 고치는 데 집중한 나머지, 테스트를 위해 남겨둔 임시 주석이나 console.log를 지우는 것을 깜빡하게 됩니다. 또한 리뷰어는 내 머릿속의 문맥을 모른다는 사실을 간과하고 설명 없이 코드만 툭 던지는 실수를 많이 합니다.

2) 원격 저장소의 최신 상태(Base Branch) 동기화 누락

내가 3일 동안 내 브랜치에서 작업하는 사이, 다른 팀원들이 develop이나 main 브랜치에 수많은 코드를 이미 올렸을 확률이 큽니다. 이를 내 브랜치에 미리 가져와서 합쳐보지 않고 PR부터 날리면, 과거의 코드와 현재의 코드가 부딪히며 심각한 충돌(Conflict)이 발생합니다.

GitHub PR 올리기 전 확인할 것들 (해결 방법)

1단계. 가장 먼저 확인할 부분: 작업 브랜치 위치와 변경 파일 목록

• 무엇을 확인하는지: 터미널에서 git branch로 현재 내가 올바른 기능 브랜치에 있는지 살피고, git status와 git diff를 통해 내가 의도한 파일만 변경되었는지 점검합니다.
• 왜 먼저 확인해야 하는지: IDE 자동 생성 파일(.idea, .vscode), .env 같은 보안 파일이나 실수로 건드린 엉뚱한 파일이 PR에 포함되는 것을 막는 첫 번째 방어선이기 때문입니다.
• 확인 후 어떻게 판단하는지: 목록에 내가 수정한 코드 파일만 깔끔하게 남아 있다면 성공입니다. 만약 올리지 말아야 할 파일이 섞여 있다면 git restore --staged <파일> 등으로 스테이징에서 제외해야 합니다.

2단계. 다음 점검: 최신 기준 브랜치 동기화 및 충돌 점검

• 무엇을 확인하는지: 기준이 되는 공용 브랜치(예: develop)의 최신 코드를 당겨와서(pull), 현재 내 작업 브랜치에 병합(merge 또는 rebase)해 봅니다.
• 왜 먼저 확인해야 하는지: 깃허브 웹 화면에서 충돌이 나면 리뷰어도 코드를 머지할 수 없습니다. PR을 올리기 전에 로컬 환경에서 미리 최신 코드를 맞춰보고 충돌이 나면 내 선에서 미리 해결(Resolve)해 두어야 합니다.
• 확인 후 어떻게 판단하는지: 로컬에서 병합 후 에러가 없거나 충돌을 잘 해결했다면, 내 기능이 최신 프로젝트 환경에서도 정상 작동할 준비가 된 것입니다.

3단계. 추가 조치: 찌꺼기 코드 제거 및 로컬 테스트(빌드) 확인

• 무엇을 확인하는지: 코드 안에 디버깅용 로그(console.log, print)나 테스트하느라 주석 처리해 둔 옛날 코드가 있는지 한 번 더 훑어보고, 로컬에서 프로젝트 빌드 및 단위 테스트(npm test, ./gradlew test 등)를 실행합니다.
• 왜 먼저 확인해야 하는지: 기능 자체가 훌륭해도 찌꺼기 코드가 섞여 있거나 빌드부터 빨간불이 들어오면 꼼꼼하지 못한 인상을 주어 리뷰의 신뢰도가 떨어집니다.
• 확인 후 어떻게 판단하는지: 모든 테스트가 통과(Pass)하고 화면이 의도대로 동작한다면 PR을 깃허브에 생성할 준비가 기술적으로 완벽히 끝난 것입니다.

4단계. 그래도 안 되면 볼 부분: 반려당하지 않는 PR 본문 작성

• 무엇을 확인하는지: 잦은 수정 요청이나 반려가 생긴다면 PR 본문의 품질을 돌아봐야 합니다. '무엇을', '왜' 변경했고, '어디를 중점적으로' 리뷰해야 하는지 친절하게 적었는지 점검합니다.
• 왜 먼저 확인해야 하는지: 리뷰어의 시간은 금입니다. 수백 줄의 코드를 설명 없이 던져주면 맥락을 파악하느라 지치지만, 잘 정리된 PR 설명글은 코드 리딩 시간을 획기적으로 줄여주기 때문입니다.
• 확인 후 어떻게 판단하는지: "기존 로그인 실패 시 안내가 없어 에러 메시지 UI를 추가했습니다. LoginAuth.js 부분을 중점적으로 봐주세요"처럼 내 코드를 처음 보는 사람도 단숨에 파악할 수 있게 적혔다면 훌륭한 PR입니다.

실전에서 자주 놓치는 부분

신입 개발자가 가장 많이 놓치는 팁은 '셀프 리뷰(Self-Review)'입니다. Create Pull Request 버튼을 덜컥 누르기 전에, 깃허브의 'Files changed' 탭을 눌러서 내가 작성한 코드를 내가 먼저 리뷰어의 시선으로 위에서부터 훑어보세요. IDE에서는 보이지 않던 오타, 쓸데없는 띄어쓰기, 빼먹은 파일들이 웹 화면에서는 귀신같이 잘 보입니다. 또한 하나의 PR에 너무 많은 기능과 리팩토링을 욱여넣지 마세요. PR 사이즈가 작고 목적이 한 가지로 명확할수록 리뷰가 빨리 끝나고 머지(Merge) 속도도 배로 빨라집니다.

마무리

GitHub PR 올리기 전 점검은 좋은 코딩 실력만큼이나 협업에서 인정받는 핵심 소프트 스킬입니다. 급할 때는 올리기 전 이 4가지만 빠르게 머릿속으로 체크하세요.

1. 불필요한 설정 파일이나 남의 코드가 섞여 들어가지 않았는가?
2. 기준 브랜치(develop)의 최신 코드를 바탕으로 충돌 없이 병합되는가?
3. 디버그 로그(console.log)와 찌꺼기 코드는 모두 지웠는가?
4. 리뷰어가 바로 이해할 수 있도록 PR 본문(설명)을 구체적으로 썼는가? 버튼 누르기 전 5분의 점검이 리뷰어와의 핑퐁을 하루 이상 단축해 줍니다.