[Gerrit 기초] Gerrit이란? GitHub의 Pull Request와 비교

개발팀의 협업에서 '코드 리뷰'는 이제 선택이 아닌 필수 과정입니다.
그런데 이 코드 리뷰를 진행하는 방식은 팀의 문화와 사용하는 도구에 따라 크게 달라지곤 합니다.

오늘은 그중에서도 가장 대표적인 두 도구, Gerrit(게릿)과 GitHub의 Pull Request(PR)가 어떻게 다른지,
그리고 각각 어떤 상황에 더 적합한지 쉽고 상세하게 비교해보려고 합니다.

🧐 "우리 팀은 왜 이렇게 복잡한 Gerrit을 쓸까?" 혹은 "Gerrit이 PR보다 좋은 점이 대체 뭐지?"
이런 궁금증을 가졌던 분이라면 오늘 포스팅이 명쾌한 해답이 될 것입니다.

1. 코드 리뷰의 두 얼굴: Gerrit과 GitHub PR
   두 도구를 한마디로 표현하면 이런 느낌입니다.

• Gerrit 🛡️: "이 코드는 제 허락 없이는 한 줄도 메인 브랜치에 들어갈 수 없습니다." 라고 말하는 깐깐하고 엄격한 품질 관리 사수
• GitHub Pull Request 💬: "제가 작업한 내용인데, 한번 보시고 의견 주세요! 괜찮으면 병합(Merge) 부탁드립니다." 라고 말하는 유연하고 사교적인 동료

이 비유에서 알 수 있듯, 두 도구는 코드 리뷰를 대하는 근본적인 철학부터 다릅니다.

Gerrit(게릿)이란?

Gerrit은 구글이 안드로이드 오픈소스 프로젝트(AOSP)의 어마어마한 소스 코드를 관리하기 위해 만든 코드 리뷰 중심의 협업 도구입니다.

Gerrit의 핵심 철학은 "리뷰를 통과하지 못한 코드는 애초에 브랜치에 들어올 자격이 없다"는 것입니다.
모든 코드는 Submit(제출)을 통해 병합되기 전에, 반드시 독립된 공간에서 리뷰어들의 승인(+2)과 자동화된 검증(+1)을 통과해야 하는 강력한 게이트키핑(Gate-Keeping) 시스템입니다.

GitHub Pull Request(PR)란?

반면, GitHub의 PR은 개발자가 독립된 브랜치에서 작업한 내용을 기존 브랜치(예: main 또는 develop)에 병합해달라고 요청(Request)하는 기능입니다.

PR의 핵심은 '소통'입니다.
리뷰어들은 PR에 올라온 코드를 보며 자유롭게 의견을 나누고, 추가적인 커밋을 쌓아가며 코드를 개선합니다.
리뷰 과정 자체가 기록으로 남는 훌륭한 소통 채널의 역할을 합니다.

---

2. 가장 결정적인 차이점: Gerrit vs GitHub PR 전격 비교

두 도구의 차이점을 표로 정리하면 다음과 같습니다.
가장 중요한 '리뷰의 기본 단위'와 '변경 사항 반영 방식'을 유심히 봐주세요.

---

항목	Gerrit	GitHub Pull Request
리뷰의 기본 단위	커밋 (Commit)	브랜치 (Branch)
변경 사항 반영	git commit --amend로 기존 커밋을 수정 (Patch Set 업데이트)	git commit으로 새로운 커밋을 추가
코드 히스토리	매우 깔끔한 선형 히스토리 (하나의 기능 = 하나의 커밋)	Merge 방식에 따라 다양함 (Merge 커밋, Squash, Rebase)
핵심 철학	품질 보증 (Gate-Keeping). 리뷰 통과 후 병합	소통 및 협업 (Discussion). 병합을 위한 논의 과정
워크플로우	엄격하고 정형화됨	유연하고 자유로움

가장 중요한 차이점: 리뷰 단위 (커밋 vs 브랜치)

이 부분이 두 시스템을 가르는 가장 근본적인 차이점입니다.

Gerrit은 '커밋' 하나하나를 독립된 심사 대상으로 봅니다.
개발자가 git push를 하면, Gerrit은 해당 커밋에 Change-ID라는 고유 식별자를 부여하여 리뷰를 생성합니다.
리뷰어가 수정을 요청하면, 개발자는 새 커밋을 쌓는 대신 기존 커밋을 수정(--amend)하여 다시 푸시합니다.
Gerrit은 동일한 Change-ID를 보고 "아, 아까 그 리뷰의 수정본이구나!"라고 인식하여 Patch Set 2, Patch Set 3 형태로 버전을 관리합니다.
하지만 GitHub PR은 '브랜치' 전체를 하나의 심사 대상으로 봅니다.
개발자는 feature/login과 같은 새 브랜치를 만들고 작업을 시작합니다.
리뷰어가 수정을 요청하면, 개발자는 수정 내용을 담은 새 커밋을 해당 브랜치에 추가하고 다시 푸시합니다.
PR은 브랜치의 모든 커밋을 포함하며, 리뷰 과정에서 계속 커밋이 쌓여나갑니다.

---

3. 한눈에 보는 작업 흐름 비교

"로그인 버튼의 색상을 파란색에서 빨간색으로 변경"하는 간단한 작업을 두 시스템에서 진행해 보겠습니다.

🛡️ Gerrit 워크플로우

1. 작업 및 커밋git commit --amend
2. 코드 수정 후 커밋 (Change-ID가 자동으로 생성됨)
3. 리뷰 요청 (Push)git push origin HEAD:refs/for/main

➔ Gerrit UI에 Change 12345 (Patch Set 1) 이 생성됩니다.

4. 'main' 브랜치에 병합하기 위한 리뷰를 요청
5. 피드백 및 수정
  -   리뷰어: "너무 강렬하네요. 좀 더 부드러운 빨간색으로 바꿔주세요." (Code-Review -1)
  -   나: (코드를 다시 수정)
6. 수정본 제출 (Amend & Push)git commit --amend
7. 새로운 커밋이 아닌, '기존 커밋'을 수정

 다시 똑같은 명령어로 푸시
git push origin HEAD:refs/for/main
> ➔ Gerrit UI의 Change 12345에 Patch Set 2 가 추가됩니다.

-   승인 및 병합
    -   리뷰어: "좋습니다!" (Code-Review +2)
    -   CI 봇: "빌드 및 테스트 통과!" (Verified +1)
    -   \[Submit\] 버튼을 클릭하면 하나의 깔끔한 커밋이 main 브랜치에 병합됩니다.

💬 GitHub PR 워크플로우

1. 브랜치 생성 및 작업  git checkout -b feature/red-buttongit commit -m "feat: 로그인 버튼 색상을 레드로 변경"
2. 코드 수정 후 커밋
3. 리뷰 요청 (Push & Create PR)  git push origin feature/red-button
    ➔ GitHub UI에서 feature/red-button 브랜치를 main 브랜치로 보내는 Pull Request를 생성합니다.

4. 피드백 및 수정
    -   리뷰어: (PR에 코멘트) "너무 강렬하네요. 좀 더 부드러운 빨간색으로 바꿔주세요."
    -   나: (코드를 다시 수정)
5. 수정본 제출 (New Commit & Push)git commit -m "fix: 피드백 반영하여 버튼 색상 톤 다운"
6. 수정 사항을 '새로운 커밋'으로 추가
7. 브랜치에 변경 사항을 푸시 git push origin feature/red-button
    > ➔ PR에 새로운 커밋이 추가되어 타임라인이 업데이트됩니다.
8.승인 및 병합
    -   리뷰어: "좋습니다!" (Approve)
    -   \[Merge Pull Request\] 버튼을 클릭하면 feature/red-button 브랜치의 내용이 main 브랜치에 병합됩니다. 
        (이때 Merge, Squash, Rebase 중 선택 가능)

---

4. 그래서, 우리 팀엔 뭐가 맞을까?
   두 도구 모두 훌륭하며, 정답은 없습니다. 팀의 성격과 프로젝트의 특성에 따라 선택이 달라질 뿐입니다.

🛡️ 이런 팀이라면 Gerrit을 추천합니다:

- 대규모 프로젝트: 수백, 수천 명의 개발자가 협업하는 안드로이드, 임베디드 OS 등
- 품질이 최우선: 항공, 자동차, 의료기기 등 안정성이 매우 중요한 시스템
- 깨끗한 히스토리: 모든 기능과 수정사항이 하나의 커밋으로 정리된, 추적하기 쉬운 히스토리를 선호하는 팀

💬 이런 팀이라면 GitHub PR을 추천합니다:

- 오픈소스 프로젝트: 누구나 쉽게 참여하고 논의할 수 있는 환경이 중요한 경우
- 빠른 개발 속도: 스타트업처럼 신속한 프로토타이핑과 유연한 협업이 중요한 팀
- 풍부한 생태계: 다양한 CI/CD 툴, 봇(Bot) 등 GitHub Actions와의 강력한 연동을 원하는 팀

마무리하며
Gerrit과 GitHub PR은 단순히 UI만 다른 것이 아니라, 코드 리뷰와 협업을 대하는 근본적인 철학의 차이를 보여줍니다.
Gerrit이 '품질 보증'이라는 목표를 위해 엄격한 절차를 따르게 한다면, GitHub PR은 '유연한 소통'을 통해 결과물을 만들어나가는 데 중점을 둡니다.