git
Pull Request(PR)는 깃(Git) 기반 협업에서 내가 작업한 코드 변경 사항(기능 추가, 버그 수정 등)을 원본 저장소에 병합해 달라고 공식적으로 요청하는 과정을 의미합니다. PR로 잠재적인 버그나 성능 이슈를 조기 발견할 수 있습니다. 일관된 코드 스타일 확립이 가능하므로 코드 유지보수 비용 절감 효과를 만들어 낼 수 있습니다.
github에서 PR을 하는 가장 큰 이유는 코드 기여를 하기 위합니다. A 개발자의 A-1 프로젝트에 B 개발자가 관심이 있습니다. 그래서 B 개발자는 A 개발자의 프로젝트의 기여자(Contribute)로 기여를 하고 싶어 합니다. 하지만, A-1 프로젝트의 코드를 수정하려면, A-1 프로젝트에 B가 기여자로 등록이 되어 있어야 수정이 가능합니다. 기여자로 등록이 되어 있지 않는 경우 우리는 Fork를 활용하여 A-1 프로젝트를 자신의 원격 저장소로 레포를 가져오는 것이 가능합니다. 그리고 내 레포의 코드를 Clone하여 수정할 수 있습니다. 그리고 수정 이후에 A-1 프로젝트로 Pull Request를 보내면, A 개발자가 코드를 확인 한 후에 merge를 하게 됩니다. 정리하면 순서는 아래와 같습니다.
Github PR 생성 시에 템플릿 설정이 가능합니다. 템플릿은 크게 단일 템플릿과 멀티 템플릿으로 분류됩니다. 단일 템플릿을 만들떄는 아래와 같이 pull_request_template.md을 만들어 줍니다.
pull_request_template.md 라는 파일명으로 넣어줘야기 PR 시 템플릿이 자동 등록됩니다. 멀티 템플릿의 경우는 아래와 같은 방법으로 생성을 하면 됩니다.
폴더를 만들어 그 안에 템플릿 파일들얼 넣어주면 됩니다. 이때 파일 이름의 제약이 없지만, 폴더의 위치랑 이름은 동일하게 적어줘야합니다.
단일 템플릿을 설정한 경우에 Pull Request 시 바로 적용이 됩니다. 그러나 멀티 템플릿인 경우에 멀티 템플릿의 경우, PR 생성했을 때의 URL 뒤에 &template={템플릿 파일 이름} 을 붙여줘야 합니다.
만약에 PULL_REQUEST_TEMPLATE 폴더 안에서 template_sample.md 라고 만들었다면, URL 뒤에 &template=template_sample.md를 붙여서 보면 템플릿 설정이 됩니다.
테스트 없이 제출된 PR이나 과도하게 큰 PR은 코드 리뷰의 품질을 크게 떨어뜨리는 대표적인 요인입니다. 테스트가 없는 상태에서 PR이 올라오면, 리뷰어는 코드 스타일이나 설계보다도 “이 코드가 어떤 상황에서 에러를 낼 수 있는지”를 먼저 추측하고 검증하는 데 시간을 쓰게 됩니다. 이는 리뷰어의 인지 부담을 불필요하게 높이고, 결과적으로 더 중요한 개선 포인트를 놓치게 만듭니다. 또한 여러 변경 사항이 하나의 PR에 한꺼번에 담겨 있는 경우, 리뷰어는 전체 맥락을 이해하는 데 큰 피로를 느끼게 되며, 세부적인 문제를 꼼꼼히 짚어내기 어려워집니다.
PR의 제목과 설명이 불명확한 경우도 마찬가지입니다. 제목만 보고는 어떤 문제를 해결했는지, 왜 이 변경이 필요한지 알 수 없고, 설명이 부족하면 리뷰어는 코드를 직접 읽으며 의도를 유추해야 합니다. 이는 리뷰 시간을 늘릴 뿐 아니라, 작성자의 의도와 리뷰어의 해석이 어긋날 가능성도 높입니다. 명확한 제목과 배경 설명, 주요 변경 사항을 간단히 정리해 두는 것만으로도 리뷰는 훨씬 효율적이고 건설적으로 진행될 수 있습니다.
모호한 커밋 메시지 역시 장기적으로 팀의 생산성을 저해합니다. “수정”, “작업 완료”와 같은 의미 없는 메시지는 해당 커밋이 어떤 기능이나 이슈와 관련 있는지 파악하기 어렵게 만들고, 리뷰어에게 빠른 피로감을 줍니다. 더 나아가 시간이 지나 깃 히스토리를 통해 코드의 변화를 추적하려 할 때, 각 변경의 맥락을 이해하기 힘들어집니다. 명확한 커밋 메시지는 단순히 리뷰를 돕는 수준을 넘어, 팀 전체가 코드의 진화를 쉽게 이해할 수 있도록 돕는 중요한 기록이라는 점을 잊지 말아야 합니다.
좋은 PR을 만들기 위한 첫걸음은 테스트를 미리 수행하는 것입니다. 리뷰어의 역할은 코드를 대신 검증해 주는 사람이 아니라, 변경 사항의 품질과 방향성을 함께 점검하는 동료입니다. 테스트가 선행되지 않은 PR은 리뷰어로 하여금 에러 케이스를 직접 상상하고 확인하게 만들며, 이는 리뷰의 본질에서 벗어난 불필요한 소모를 발생시킵니다. 기본적인 테스트를 통과한 상태로 PR을 올리는 것만으로도 리뷰어는 훨씬 중요한 로직, 구조, 개선 포인트에 집중할 수 있습니다.
또한 PR의 크기를 적절히 유지하는 것도 매우 중요합니다. 하나의 PR에 너무 많은 작업이 포함되면 변경 의도를 파악하기 어렵고, 리뷰어의 피로도는 급격히 올라갑니다. 작업 내용을 커밋 단위로 잘게 나누거나, 필요하다면 PR 자체를 여러 개로 분리하는 것이 좋습니다. 깃허브의 Pull Request Size와 같은 도구를 활용해 PR 크기를 가시화하고, 가능하다면 size/M을 넘기지 않도록 관리하면 리뷰 효율과 품질을 동시에 높일 수 있습니다.
명확하고 상세한 PR 제목과 설명은 리뷰 경험을 크게 개선합니다. 단순히 무엇을 바꿨는지 나열하는 것을 넘어, 왜 이 변경이 필요했는지에 대한 배경과 의사결정 흐름, 그리고 주요 로직에 대한 간단한 설명을 포함하는 것이 좋습니다. 이렇게 작성된 PR은 리뷰어가 코드를 읽기 전부터 전체 맥락을 이해할 수 있게 해주며, 불필요한 질문과 오해를 줄여 보다 생산적인 논의를 가능하게 합니다.
마지막으로, 의미 있는 커밋 메시지와 잘게 나뉜 변경 단위는 좋은 리뷰어 경험의 핵심 요소입니다. 커밋 메시지만 보아도 어떤 작업을 했는지 즉시 알 수 있도록 작성하고, 여러 변경 사항이 불가피한 경우에도 커밋 단위로 논리적으로 분리해야 합니다. 이러한 PR을 마주한 리뷰어는 이전과 달리 거부감 없이 코드를 읽게 되고, 리뷰 자체에 더 집중할 수 있습니다. 결국 핵심은 하나입니다. 리뷰어가 작업 내역과 리뷰 포인트를 쉽고 빠르게 파악할 수 있도록 배려하는 것, 이것이 곧 좋은 PR이자 팀 전체의 생산성을 높이는 방법입니다.