GitHub 시리즈 3편 - Pull Request 제대로 쓰는 법

GitHub 시리즈 3편

Pull Request 제대로 쓰는 법 (C# 실무 기준)

GitHub를 어느 정도 써본 개발자라면 누구나 Pull Request(PR)를 만들어본 경험이 있을 것이다. 하지만 “PR을 만든다”와 “PR을 제대로 쓴다”는 완전히 다른 이야기다.

이 글에서는 단순히 버튼을 누르는 방법이 아니라, 실무에서 신뢰받는 Pull Request를 작성하는 방법을 C# 프로젝트 기준으로 아주 깊게 다룬다.

---

1️⃣ Pull Request란 무엇인가?

Pull Request는 단순한 코드 병합 요청이 아니다.

PR은 코드 변경의 이유, 맥락, 영향 범위를 모두 담은 기술 문서다.

• 왜 이 변경이 필요한가?
• 어떤 문제를 해결하는가?
• 기존 코드에 어떤 영향을 주는가?

이 질문에 답하지 못하는 PR은 리뷰어에게 부담이 되고, 결국 품질 저하로 이어진다.

---

2️⃣ 나쁜 Pull Request의 전형적인 특징

❌ 변경 내용이 너무 많다

- 로그인 기능 추가
- 기존 인증 로직 리팩토링
- 공통 유틸 수정
- UI 스타일 수정

이런 PR은 리뷰가 불가능하다. 리뷰어는 무엇에 집중해야 할지 알 수 없다.

❌ 설명이 없다

PR 설명: 수정했습니다.

이 한 줄은 사실상 “리뷰하지 마세요”라는 뜻이다.

---

3️⃣ 좋은 Pull Request의 핵심 원칙

• 하나의 PR = 하나의 목적
• 변경 이유가 명확해야 한다
• 리뷰어가 코드만 봐도 이해할 수 있어야 한다

PR은 작성자가 아니라 리뷰어를 위해 쓰는 문서다.

---

4️⃣ Pull Request 제목 작성법

❌ 나쁜 예

fix
update
bug fix

✅ 좋은 예

feat: 사용자 로그인 시 JWT 토큰 만료 처리 추가
fix: NullReferenceException 발생 조건 수정
refactor: 인증 서비스 책임 분리

제목만 봐도 무슨 변경인지 바로 이해되어야 한다.

---

5️⃣ Pull Request 본문 템플릿 (실무용)

## 변경 내용
- 로그인 시 토큰 만료 시간 검증 로직 추가

## 변경 이유
- 만료된 토큰으로 접근 가능한 문제 발견

## 테스트 방법
- 만료된 토큰으로 API 호출 시 401 반환 확인

## 영향 범위
- AuthService
- JwtTokenProvider

이 구조는 리뷰 속도를 최소 2배 이상 올려준다.

---

6️⃣ C# 코드 변경 예시 (PR 단위)

❌ 한 PR에 너무 많은 변경

public class AuthService
{
    public void Login() { }

    public void Logout() { }

    public void RefreshToken() { }

    // UI 관련 코드까지 포함
}

✅ 책임이 명확한 PR

public class JwtTokenValidator
{
    public bool IsExpired(string token)
    {
        // 토큰 만료 검사
        return true;
    }
}

PR 하나는 리뷰 가능한 크기여야 한다.

---

7️⃣ 리뷰어를 배려하는 커밋 전략

• 의미 있는 단위로 커밋
• 중간 깨진 상태 커밋 금지
• 커밋 메시지는 변경 이유 중심

feat: JWT 토큰 만료 검사 로직 추가
test: 토큰 만료 테스트 케이스 추가

---

8️⃣ PR과 테스트의 관계

테스트 없는 PR은 미완성 PR이다.

[TestMethod]
public void ExpiredToken_Should_ReturnFalse()
{
    var validator = new JwtTokenValidator();
    Assert.IsFalse(validator.IsExpired("expired-token"));
}

테스트가 있으면 리뷰어는 의도를 신뢰할 수 있다.

공식 문서: .NET 테스트 개요

.NET에서 테스트 - .NET

 

---

9️⃣ Pull Request 리뷰 대응 방법

❌ 방어적인 태도

“이건 원래 이렇게 쓰는 겁니다.”

✅ 좋은 태도

“이 부분은 이런 의도로 작성했는데, 더 나은 방법이 있을까요?”

PR 리뷰는 평가가 아니라 협업이다.

---

🔚 마무리

Pull Request를 잘 쓴다는 것은 GitHub를 잘 쓴다는 뜻이 아니다.

PR을 잘 쓴다는 것은 팀을 배려할 줄 안다는 뜻이다.

• 리뷰어의 시간을 존중하고
• 변경의 맥락을 설명하며
• 품질을 시스템으로 지키는 것

이 글의 내용을 실천하는 순간, 당신의 PR은 거절되는 PR이 아니라 신뢰받는 PR이 된다.