승인 / 승인 받기: 개념, Git에서의 승인과 코드 리뷰

pull request 승인이란

승인은 pull request에 대한 긍정적인 리뷰로, 리뷰어가 코드를 확인하고, 중대한 문제가 없으며, 변경 사항이 merge될 준비가 되었다고 간주하는 것입니다. GitHub 인터페이스에서는 PR 페이지의 녹색 “Approve” 버튼입니다. 승인 후에는 작성자(또는 쓰기 권한이 있는 모든 멤버)가 merge를 수행할 수 있습니다.

승인 과정은 Branch Protection Rules의 일부입니다. 리포지토리 소유자가 필수 요건을 설정합니다: 최소 승인 수(예: 1이나 2), 누가 승인할 수 있는지(코드 소유자, 팀 멤버), 그리고 변경 후 PR을 재승인해야 하는지(Dismiss stale reviews). 규칙 설정이 없으면 승인은 선택사항이지만, 전문 팀에서는 필수입니다.

GitLab은 Approval Rules이라는 유사한 메커니즘을 사용합니다. GitLab에서는 다른 그룹으로부터 필요한 승인 수를 설정할 수 있습니다(예: 백엔드 개발자에서 2개, DevOps에서 1개). 모든 필수 승인을 받은 후, CI/CD 파이프라인이 녹색이면 PR이 merge를 위해 자동으로 언록됩니다.

리뷰 유형: Approve, Request Changes, Comment

GitHub과 GitLab에는 리뷰어가 pull request에 남길 수 있는 세 가지 리뷰 유형이 있습니다. 각 유형은 다른 상태와 merge 과정에 다른 결과를 가집니다. Approve는 녹색, Request Changes는 빨간색, Comment는 중립적인 회색입니다. 선택은 코드 품질과 변경 사항의 수렵 준비 상태에 따락니다.

Approve — 리뷰어가 확인: 코드가 올바르게 작성되었고, 기준을 충족하며, 명밝한 오류가 없고, merge할 수 있습니다. Approve는 코드가 완벽하다는 의미가 아닙니다 — 단지 생산에 착할 정도로 좋다는 것입니다. 작은 의견(스타일, 명명)이 있다면 PR을 차단하지 않고 코멘트로 남길 수 있습니다.

Request Changes — 리뷰어가 merge 전에 수정해야 할 문제를 발견: 논리적 오류, 취약점, 아키텍처 위반, 테스트 부족. Request Changes 후 PR이 차단되고, 언록을 위해 동일한 리뷰어의 재승인이 필요합니다(새 커미트에서 Dismiss stale reviews 옵션이 활성화된 경우).

• Approve — 코드가 merge될 준비가 되었으며, CI 통과 후 merge할 수 있습니다.
• Request Changes — 필수 수정 사항이 있으며, 재리뷰까지 PR이 차단됩니다.
• Comment — PR을 차단하지 않는 일반적인 의견 또는 제안.

리포지토리에서 승인 규칙 설정

Branch Protection Rules는 merge 품질을 제어하는 GitHub의 메커니즘입니다. 보호되는 브랜치(main, develop, release/*)별로 Settings → Branches에서 설정합니다. 주요 매개변수: 필수 승인 수, 코드 소유자(CODEOWNERS), 필수 CI/CD 검사, 그리고 PR 없이 push 금지.

Dismiss stale pull request approvals 매개변수는 PR에 새 커미트가 추가될 때 자동으로 승인을 제거합니다. 이는 리뷰어가 merge될 코드의 해당 버전을 승인하도록 보장합니다. 이 설정이 없으면 작성자가 승인 후 새 코드를 추가하고, 이것이 재검사 없이 main에 도착할 수 있습니다.

CODEOWNERS — 리포지토리 루트에 있는 파일로, 다양한 디렉토리에 대한 책임자를 지정합니다. PR이 코드 소유자의 파일에 영향을 미치면, 그의 승인이 필수가 됩니다. CODEOWNERS를 통해 책임 영역을 분배할 수 있습니다: iOS 개발자는 Swift 파일을, DevOps는 Docker 구성을, 테스터는 테스트 시나리오를 담당합니다.

# 리포지토리 루트의 예제 CODEOWNERS 파일

# iOS 개발자가 Swift 코드를 소유
*.swift @team/ios-developers

# DevOps가 CI/CD 구성을 소유
.github/workflows/* @devops-team

# QA 엔지니어가 테스트를 리뷰
**/tests/* @qa-engineers

# 기타 모든 항목의 기본 소유자
* @tech-leads

승인 전 코드 리뷰: 확인 사항

승인 전의 코드 리뷰는 diff를 대략 보는 것이 아닌 시스템적인 코드 검사입니다. 품질 좋은 코드 리뷰에는 아키텍처, 논리, 스타일, 테스트, 그리고 보안 검사가 포함됩니다. 이러한 검사 없이 승인은 품질 관리 도구가 아닌 형식에 그치게 됩니다.

먼저 확인하는 것: 변경 사항의 논리 — 코드가 작업을 해결하는지, 부작용이 있는지, 경계 케이스 처리가 올바른지. 테스트 — 새 테스트가 모든 시나리오를 다루는지, 기존 테스트가 변경 후에도 통과하는지. 보안 — SQL 인젝션, XSS, 민감 데이터 유출이 없는지.

리뷰 대상이 되지 않아야 할 것: 포맷 스타일(이를 위해 linter와 formatter가 있습니다), 사전에 결정된 아키텍처 결정(코드를 작성하기 전에 논의됩니다). 리뷰가 400 줄을 넘깰나 1시간이 넘으면, 작업이 너무 커서 분해가 필요하다는 신호입니다. 최고의 리뷰 실천 — PR 작성 후 24시간 내에 200~400 줄 단위.

• 논리 — 해결책의 올바름, 오류 처리, 경계 케이스.
• 테스트 — 새 시나리오 다루기, 기존 테스트 통과, flaky 테스트 없음.
• 보안 — 인젝션 없음, 출력 탈출, 데이터 액세스 제어.
• 성능 — 알고리즘 효율성, 과다한 쿼리, 메모리 누수.
• 문서 — 문서가 업데이트되었는지, 복잡한 부분의 주석이 명확한지.

팀에서의 승인 워크플로

5~10명의 개발자로 구성된 팀에서 일반적인 승인 워크플로는 다음과 같습니다: 개발자가 PR을 생성하고, 리뷰어를 지정하고(보통 팀에서 1~2명 또는 코드 소유자), CI/CD가 자동 검사를 실행합니다. 모든 필수 승인과 녹색 CI를 받은 후, 작성자가 merge를 수행합니다. PR 생성부터 merge까지의 시간은 복잡성에 따라 평균 2시간에서 2일 정도 걸립니다.

GitHub Actions는 승인 후 merge를 자동화할 수 있습니다. 브랜치 규칙이 설정된 경우 GitHub는 모든 조건이 충족될 때까지 merge를 차단합니다. 일부 팀은 bors-ng나 Mergify를 사용합니다 — 이 봇은 모든 승인을 받고 CI가 통과한 후 자동으로 PR을 merge합니다. 이를 통해 프로세스가 가속되고 merge에서 인간적 요인이 제거됩니다.

현대적 접근 방식은 trunk-based development로, 수명이 짧은 브랜치를 사용합니다. 이 워크플로에서는 몇 시간 내에 승인을 받아야 하며, 그렇지 않으면 작업이 단 것으로 간주되어 main과의 재동기화가 필요합니다. 리뷰 문화가 높은 팀은 승인 시간을 노동 4시간 이내로 목표합니다.

승인 실수와 피하는 방법

가장 흔한 실수는 실제 코드 검사 없이 형식적인 승인입니다. PR이 큰 경우나 마감이 임박한 경우, 리뷰어가 변경 사항을 검토하지 않고 Approve를 누른 수 있습니다. 이는 전체 코드 리뷰 과정을 무의미하게 만듭니다. 해결 방법: PR 크기에 제한을 둔니다(400 줄 이하), 그리고 코드 분석 도구(SonarQube, CodeClimate)를 사용하여 자동 검사를 수행합니다.

둘째 실수는 과도하게 엄격한 승인입니다. 완벽한 코드를 기대하면 개발이 차단됩니다. 리뷰어가 품질에 영향이 없는 스타일적 의견을 수정하라고 요구하는 경우가 있습니다. 해결 방법: 필수 의견(blocking)과 선택적 제안(코멘트)을 명확히 구분합니다. GitHub에서는 의견이 차단적인지 여부를 명시적으로 지정할 수 있습니다.

셋째 실수는 CI/CD 검사 없이 승인하는 것입니다. 코드가 올바르다면서도 컴파일이 되지 않거나 테스트에서 실패할 수 있습니다. 설정된 Branch Protection은 빨간 CI에서 merge를 자동으로 차단하지만, 일부 팀은 속도를 위해 이 보호를 비활성화합니다. 해결 방법: 승인 전에 항상 CI 상태를 확인하고 빨간 파이프라인의 PR을 승인하지 마세요.

• 형식적 승인 — 실제 코드 검사 부재. 해결 방법: PR당 400 줄 제한.
• 과도한 엄격성 — 스타일적 의견으로 차단. 해결 방법: blocking과 optional으로 구분.
• CI 무시 — 빨간 파이프라인에서 승인. 해결 방법: 항상 테스트 상태 확인.
• 작성자 지정 — PR 작성자의 승인. 해결 방법: 작성자에 대한 Branch Protection 설정.