초보 개발자를 위한 GitHub Pull Request 만들고 코드 리뷰 받는 법(실습 중심)

처음 PR(Pull Request)을 올릴 때 제일 긴장되는 순간은 “내 코드가 누군가에게 보인다”는 사실이죠. 그런데 한 번만 흐름을 제대로 잡아두면, PR은 혼나는 자리가 아니라 더 빠르게 성장하는 루틴이 됩니다. 오늘은 “작게 바꾸고, 명확하게 설명하고, 리뷰를 잘 받는” 방식으로 PR을 직접 만들어보겠습니다.

1) PR이 뭐고, 왜 필요한가

PR은 내가 만든 변경사항을 메인 브랜치에 합치기 전에 팀원(또는 오픈소스 메인테이너)에게 보여주고 토론하는 과정입니다.

• 변경사항 공유: 어떤 의도로 무엇을 바꿨는지 기록
• 검증: 버그/실수/엣지 케이스를 다른 시선으로 확인
• 지식 전파: 리뷰 코멘트 자체가 문서가 됨

2) 실습 시나리오: 문서 한 줄 수정으로 PR 올리기

처음은 코드보다 README 같은 문서 수정이 부담이 적습니다. 예를 들어 README.md에 사용법 한 줄을 추가해 PR을 올려볼게요.

2-1. 저장소 포크/클론 & 브랜치 만들기

터미널에서 아래처럼 진행합니다.

git clone 저장소주소
cd 저장소폴더
git checkout -b docs/add-usage

브랜치 이름은 무엇을 하는지 한눈에 보이게 짓는 게 좋습니다. (docs/, fix/, feat/ 같은 접두어는 팀 규칙에 맞추세요.)

2-2. 변경하고 커밋하기

README.md에 한 줄 추가 후 상태 확인:

git status
git add README.md
git commit -m "docs: add usage line to README"

커밋 메시지는 짧지만 구체적으로. “update” 같은 단어만 쓰면 나중에 내가 봐도 기억이 안 납니다.

2-3. 푸시하고 PR 만들기

git push -u origin docs/add-usage

이제 GitHub에서 “Compare & pull request” 버튼을 눌러 PR을 생성합니다.

3) 리뷰가 잘 달리는 PR 작성법(핵심)

PR 본문은 길게 쓰는 글이 아니라, 리뷰어의 시간을 아껴주는 안내서입니다. 아래 템플릿처럼 작성해보세요.

3-1. PR 템플릿 예시

Title: docs: README 사용법 한 줄 추가

Body

• 변경 요약: README에 실행 예시 문장 1줄 추가
• 변경 이유: 처음 보는 사용자가 실행 방법을 바로 이해하기 어렵다는 피드백이 있어 보완
• 테스트 방법: README 렌더링 확인, 문장/서식 깨짐 없음
• 스크린샷/결과: (문서면 생략 가능)
• 관련 이슈: (있다면) #번호 여기서 포인트는 “왜”와 “어떻게 확인했는지”입니다. 이 두 줄만 잘 써도 리뷰 속도가 확 올라갑니다.

3-2. PR 크기는 작게, 논점은 하나로

초보 때 가장 흔한 실수:

• 문서 수정 PR에 불필요한 포맷팅 대청소
• 기능 추가하면서 리팩터링까지 한 번에 PR이 커지면 리뷰가 늦어지고, 피드백도 뭉뚱그려집니다. 가능하면 한 PR = 한 목적으로 쪼개세요.

4) 코드 리뷰 요청하는 요령(말 걸기 어렵다면 이렇게)

리뷰는 “봐주세요”가 아니라 어디를 봐달라고 요청하는 게 좋습니다.

• “로직은 단순한데, 에러 처리 방식이 적절한지 봐주실 수 있을까요?”
• “함수 이름이 애매한데 더 좋은 네이밍이 있을까요?”
• “이 부분 성능 이슈가 있을지 감이 안 옵니다. 체크 부탁드려요.” 또, 급하면 PR 본문에 리뷰 우선순위를 적어두세요. 예: “핵심 변경은 parser.py의 parse() 함수, 나머지는 테스트 코드입니다.”

5) 리뷰 코멘트 대응: 초보가 자주 막히는 3가지

5-1. 지적받으면 방어적으로 느껴질 때

리뷰는 사람 평가가 아니라 코드 품질을 올리는 대화입니다. 모호하면 이렇게 물어보세요: “이 방식이 더 좋은 이유가 있을까요? 제가 놓친 케이스가 궁금합니다.”

5-2. 수정 커밋은 어떻게 올리나

코멘트 반영 후 동일 브랜치에 커밋하고 푸시하면 PR에 자동 반영됩니다.

git add .
git commit -m "fix: address review comments"
git push

5-3. 대화는 남기고, 해결은 명확하게

코멘트를 반영했다면 GitHub에서 해당 스레드에 “반영했습니다. ~ 방식으로 수정했고 테스트도 통과했습니다.”처럼 짧게 결과를 공유하고 Resolve 처리합니다.

6) 머지 전 마지막 체크리스트

PR 제목이 변경내용을 대표한다

“왜 바꿨는지”가 본문에 있다

테스트/확인 방법을 적었다

불필요한 파일 변경이 없다

리뷰 코멘트에 답이 달려 있다

PR은 한 번에 완벽하려고 올리는 게 아니라, 리뷰를 통해 좋아지도록 올리는 것입니다. 오늘은 문서 한 줄로 시작했지만, 같은 흐름으로 기능 추가 PR도 충분히 할 수 있어요. 다음 단계로는 “테스트 코드 포함 PR”을 한 번 만들어보면 성장 속도가 확 달라집니다.