67. 풀 리퀘스트 (Pull Request, PR) / 머지 리퀘스트 (MR)

⚠️ 이 문서는 개발자가 자신의 로컬 컴퓨터에서 짠 코드를 메인 소스코드 저장소(운영 뼈대)에 함부로 덮어쓰지 못하게 하고, **"제가 이렇게 코드를 짰으니 버그나 엉망인 구조가 없는지 검토하시고, 괜찮으면 원본에 합쳐(Pull/Merge) 주세요"라고 동료와 관리자에게 공식적으로 결재를 올리고 코드 리뷰(Code Review)를 받는 애자일 협업의 꽃인 'PR 프로세스'**를 다룹니다.

핵심 인사이트 (3줄 요약)

  1. 본질: 깃허브(GitHub)가 창안하여 소프트웨어 개발 문화를 영원히 바꿔놓은 '소통의 게시판'이다. 코드가 저장소에 병합(Merge)되기 전에 멈춰 세워, 변경된 코드의 줄(Diff)을 한눈에 보여주며 토론을 유도하는 소셜 네트워크 기능이다.
  2. 가치: "네 코드는 쓰레기야"라는 나중의 감정적 비난을 막고, 배포 전에 미리 버그를 잡고 더 우아한 로직(리팩토링)을 집단지성으로 도출하여 시스템 전체의 품질 부채를 획기적으로 낮춰주는 가장 싸고 확실한 품질 보증(QA) 장치다.
  3. 기술 체계: PR이 생성되는 순간 단순히 사람만 개입하는 것이 아니라, 젠킨스나 깃허브 액션 같은 CI(지속적 통합) 로봇이 자동으로 깨어나 테스트 코드를 돌려보고 "안전함/에러남" 마크를 달아주는 자동화 파이프라인의 핵심 방아쇠(Trigger) 역할을 한다.

Ⅰ. PR이 없는 시대의 묻지 마 덮어쓰기 (Push의 저주)

과거에는 네 코드가 내 코드를 죽이는 전쟁터였다.

  1. 강제 푸시 (Direct Push)의 끔찍함:
    • 개발자 5명이 한 사무실에서 master 브랜치 하나만 쓴다. 신입 사원이 버그 픽스를 끝내고 아무런 통보 없이 원격 master에 코드를 던져 넣는다(Push).
    • 10분 뒤, 운영 서버가 멈추고 선임 개발자가 짠 로직이 다 깨져버린다. 누가, 왜, 어떤 생각으로 그 코드를 엎어버렸는지 아무도 모른다.
  2. 포크(Fork)와 브랜치 분리의 한계:
    • 이를 막으려면 각자 자기 가지(Feature 브랜치)에서 개발해야 한다.
    • 그런데 완성된 코드를 다시 master에 합치려니, 팀장이 일일이 터미널에서 명령어로 코드를 긁어와 눈으로 수백 줄을 텍스트로 읽어가며 합칠지 말지 고민해야 하는 지옥 같은 수작업이 펼쳐졌다.
  3. 풀 리퀘스트(Pull Request)의 발명:
    • 깃허브(GitLab에서는 Merge Request라 부름)는 이 불편함을 없애기 위해 웹 화면에 버튼 하나를 만들었다. "내 코드를 당신의 브랜치로 '가져가 달라(Pull)'고 요청(Request)합니다."

📢 섹션 요약 비유: 과거에는 공동 집필하는 원고에 아무나 마음대로 들어가서 글을 덮어써 버리고 도망가는 난장판이었습니다. PR이 도입된 이후에는, 자기가 쓴 원고(코드)를 투명한 결재 서류철에 담아 편집장 책상 위에 올려두고 "이거 초안인데 한 번 읽어봐 주시고, 괜찮으면 원본 책자에 붙여(Merge) 주세요"라고 예의 바르게 허락을 구하는 시스템으로 바뀐 것입니다.

Ⅱ. 소셜 코딩: 코드 리뷰(Code Review)의 르네상스

PR은 단순한 결재가 아니다. 주니어와 시니어가 소통하는 거대한 광장이다.

  1. 차분(Diff)의 시각화:
    • PR 창이 열리면 화면 왼쪽에는 원래 코드(빨간색 삭제 줄), 오른쪽에는 내가 짠 새 코드(초록색 추가 줄)가 나란히 보여서 무엇이 바뀌었는지 1초 만에 알 수 있다.
  2. 줄 단위 댓글 (Line-by-line Commenting):
    • 팀장이나 동료가 이 초록색 코드를 읽다가, 이상한 부분을 발견하면 바로 그 소스코드 45번째 줄에 클릭해서 댓글을 단다.
    • "이거 For문 돌리면 데이터 많아질 때 $O(N^2)$이라서 뻗을 것 같은데요? Map 써서 해시로 찾는 게 낫지 않을까요?"
    • 작성자는 그 댓글을 보고 코드를 수정해서 다시 커밋(Push)을 올리면, PR 화면에 수정된 내역이 실시간으로 업데이트된다.
  3. 심리적 안전감과 멘토링:
    • PR 리뷰는 단순히 남의 흠을 잡는 감사가 아니다. 시니어가 주니어의 코드를 자연스럽게 가르치는(Mentoring) 가장 훌륭한 OJT 수단이며, 내 코드를 동료가 한 번 더 꼼꼼히 봐줄 것이라는 믿음이 개발자의 심리적 부담감을 엄청나게 덜어준다.

📢 섹션 요약 비유: 작가가 쓴 소설 초안(PR)을 구글 독스에 띄워놓고, 동료 작가 세 명이 들어와서 "이 부분은 개연성이 좀 떨어지는데 대사를 이렇게 고쳐보면 어때요?"라고 형광펜을 칠하며(댓글) 조언해 줍니다. 치열한 토론 끝에 내용이 훌륭하게 다듬어지면 다 같이 "승인(Approve)" 도장을 쾅 찍어 출판사(운영 서버)로 넘기는 아름다운 집단지성의 장입니다.

Ⅲ. CI 봇의 참전: PR은 배포 파이프라인의 스위치다

인간의 눈만으로는 수만 줄의 버그를 잡을 수 없으므로 로봇 경비견을 고용한다.

  1. 자동화 검문소 (Quality Gate):
    • PR이 생성되는 순간, 깃허브 창 하단에서 회전하는 로딩 아이콘(CI 서버 작동)이 돌기 시작한다.
    • Jenkins나 GitHub Actions 로봇이 몰래 백그라운드에서 이 PR 코드를 임시로 병합해 보고, 1,000개의 단위 테스트(Unit Test) 스크립트를 싹 다 돌려본다.
    • 로봇이 "테스트 3개 실패함. 코드 병합 절대 불가(❌)"라고 빨간 엑스 자를 띄우면, 아무리 팀장이 승인(Approve) 버튼을 누르고 싶어도 물리적으로 Merge 버튼이 비활성화되어 눌리지 않게 막아버린다 (통제 강제화).
  2. 리뷰 피로도 감소:
    • 로봇이 단순한 띄어쓰기 오류나 문법 에러(Linting), 뻔한 테스트 통과 여부를 미리 다 기계적으로 걸러주기 때문에, 인간 동료는 코드가 비즈니스 요구사항에 맞는지 '아키텍처와 로직의 아름다움'을 토론하는 데에만 100% 집중할 수 있다.

📢 섹션 요약 비유: 편집장(동료 개발자) 책상에 원고를 올리면, 먼저 꼼꼼한 AI 맞춤법 검사기(CI 봇)가 튀어나와 1분 만에 오타와 표절률을 쫙 검사해 줍니다. 로봇이 "치명적 오타 발견" 스티커를 붙이면 편집장은 원고를 읽어볼 필요도 없이 돌려보냅니다. 로봇이 "통과" 스티커를 붙여줬을 때만, 인간 편집장들이 모여 이 글의 문학적 가치(코드 구조)를 깊게 논의하는 고효율 검수 시스템입니다.