Pull Request와 Merge Request 관점의 차이

이름 차이와 그 안에 내포된 협업의 서로 다른 관점

GitHub, GitLab등의 플랫폼상에서 협업하는 개발자라면 누구나 한 번쯤 이 질문 앞에 멈춰 선다.
GitHub에서는 ‘Pull Request’, GitLab에서는 ‘Merge Request’.
철자만 다를 뿐 같은 개념 아닐까? 그게 그거지 뭐. 이런 생각이 드는 것은 당연하다.
하지만 이름의 차이는 단순한 용어 선택의 문제가 아니다.
그 안에는 두 플랫폼이 코드 협업을 바라보는 서로 다른 관점이 담겨 있다.
오래 간만에 후배사원에게 ‘라때는’을 시전하다 글로 남기고 싶어 포스팅을 해 본다.

우리가 눈여겨 보아야 할 점

두 개념의 출발점은 같다.
개발자가 특정 브랜치에서 작업을 마친 뒤, 그 변경 사항을 주요 브랜치에 합치기 전에 동료의 검토를 요청하는 절차를 이야기한다.
차이는 그 절차를 바라보는 시선의 각도다.

이름에 담긴 철학 — 행위냐, 목적이냐

GitHub의 Pull Request는 ‘당겨온다(pull)’는 행위에 초점을 맞춘다.
변경 사항을 가진 개발자가 메인테이너에게 “내 코드를 가져가 주십시오”라고 요청하는 구조다. 오픈소스 생태계에서 낯선 기여자가 프로젝트 소유자에게 기여를 제안하는 맥락에서 자연스럽게 생겨난 이름이다.
즉, 관계의 비대칭성이 이름에 녹아 있다.

반면 GitLab의 Merge Request는 ‘합친다(merge)’는 결과에 집중한다.
요청의 주체가 누구든, 목적은 코드를 통합하는 것이라는 사실을 부각한다.
이 명칭은 기여자와 메인테이너라는 수직적인(?) 관계보다 작업의 목적 자체를 더 중요하게 여기는 시각이 반영된 표현이라 할 수 있을 것 같다.

작업 흐름의 유연성 — Draft 모드와 협업 방식

이름의 철학적 차이를 넘어, 기능적 측면에서도 두 플랫폼은 갈린다.
GitLab의 Merge Request는 Draft(초안) 모드가 공식 기능으로 일찍 도입되었다.
작업이 완료되지 않은 상태에서도 리뷰 과정에 동료를 참여시킬 수 있다. 지금 내가 오르고 있는 산이 그 산이 맞는지 점검을 받을 수 있다.
GitHub 역시 ‘Draft Pull Request’ 기능을 제공하지만, GitLab이 이 흐름을 더 먼저, 더 정교하게 구현했다는 평가가 많다.

CI/CD 통합과 코드 리뷰의 깊이

GitLab은 Merge Request와 CI/CD 파이프라인의 통합이 훨씬 긴밀하다.
플랫폼 자체에 CI/CD 도구인 GitLab CI가 내장되어 있기 때문에, Merge Request를 생성하거나 새로운 커밋을 푸시하는 순간, .gitlab-ci.yml에 정의된 파이프라인이 자동으로 트리거되어 빌드·테스트·정적 분석 등의 스테이지가 순차적으로 실행된다.
아울러 각 스테이지의 성공·실패 여부와 로그가 Merge Request 페이지 안에 인라인으로 표시된다.
GitHub 역시 GitHub Actions를 통해 유사한 경험을 제공하지만, 이것은 나중에 추가된 기능이다.
GitLab은 처음부터 이 통합을 염두에 두고 설계되었다는 점에서 차이가 있다.
코드 리뷰의 세밀함에서도 미묘한 차이가 존재한다. GitHub는 리뷰 승인 여부를 Approve / Request changes / Comment 세 단계로 나누어 명시적으로 표현한다.
GitLab 역시 유사한 승인 체계를 갖추고 있으나, Approvals 규칙을 프로젝트 단위에서 더 세밀하게 강제할 수 있다.
예를 들어 특정 컴포넌트를 관리하는 별도의 팀이 있다면 그 팀을 주요 의사결정권자에 포함시킬 수 있다.
특정 인원 수 이상의 승인 없이는 아예 병합 자체가 불가능하도록 설정되어 있는 GitLab 이 병합과정에서 더 직관적으로 보인다.

마치며

최근 각 소프트웨어 개발 조직마다 별도의 Development platform engineering을 구축하는 것이 유행이다.
이러한 움직임은 최근 가속화 되고 있는 Coding agent의 도입과 맞물려 있다.
생산성과 품질을 최대한 끌어내기 위한 노력의 일환이다.
결국 Pull Request와 Merge Request의 차이는 단순한 명칭의 문제가 아니다.
두 플랫폼이 협업의 어떤 측면을 우선시하는가에 대한 설계 철학의 차이이며, 그것이 기능의 깊이와 통합 방식에서 구체적으로 드러난다.
GitHub가 오픈소스 커뮤니티 중심의 유연한 협업을 지향한다면, GitLab은 엔터프라이즈 환경에서의 통합적 DevOps를 염두에 둔다.
어느 쪽이 옳다는 판단보다는, 팀의 규모와 목적에 따라 적합한 플랫폼을 선택하는 것이 실용적인 태도다.
도구는 사용하는 사람의 필요에 봉사할 때 가장 빛난다.