풀 리퀘스트란 무엇인가요?

풀 리퀘스트(PR)는 코드베이스에 변경 사항을 제안하는 방법입니다. 소프트웨어 개발자는 메인 코드 리포지토리(리포라고도 함)를 별도의 브랜치로 포크하고, 작업하면서 해당 브랜치에 코드를 커밋한 뒤, 브랜치의 변경 사항을 메인 코드베이스로 가져오거나 병합하기 전에 제안된 변경 사항을 코드 리뷰 대상으로 표시하기 위해 풀 리퀘스트를 생성합니다.

PR은 Bitbucket 및 GitHub와 같은 Git 리포지토리에서 일반적으로 사용되는 메커니즘입니다. GitLab에서는 동일한 프로세스를 위해 풀 리퀘스트 대신 “머지 리퀘스트”라는 용어를 사용합니다.

개발자는 명령줄 인터페이스(CLI) 또는 웹 인터페이스를 사용하여 풀 리퀘스트를 생성할 수 있습니다. 새로운 풀 리퀘스트는 일반적으로 버그 수정, 의존성 업데이트, 새로운 기능 추가 또는 리팩터링된 코드를 위해 생성됩니다. 풀 리퀘스트는 코드 리뷰를 간소화하고 코드베이스를 표준에 맞게 유지하며 소프트웨어 개발 팀 구성원 간의 협업을 촉진합니다.

PR은 개발자가 소스 코드를 작성하고 로컬에서 테스트할 수 있도록 합니다. 코드 변경 사항이 메인 브랜치로부터 분리되어 있기 때문에, 개발자는 전체 코드베이스를 망가뜨릴 걱정을 하지 않아도 됩니다.

풀 리퀘스트 방식에는 주로 오픈 소스 프로젝트에 적용되지만, 독점 또는 폐쇄형 소스 프로젝트에도 적용할 수 있는 세 가지 핵심 역할이 포함됩니다.

• 유지 관리자: 프로젝트 유지 관리자는 프로젝트를 관리(그리고 종종 소유)하며 PR을 승인하고 병합하거나 거부할 권한을 가집니다.

• 리뷰어: 이 팀 구성원들은(메인터이너이거나 프로젝트 경험이 많은 다른 적극적인 기여자일 수 있음) 제안된 변경 사항을 코드 품질 관점에서 검토하고 필요에 따라 개선 사항을 제안합니다.

• 기여자: 이 개발자들은 변경 사항을 수행하고 풀 리퀘스트를 생성하는 역할을 맡습니다.

풀 리퀘스트 생성은 일반적으로 7단계 절차로 이루어집니다.

1. 기여자는 메인 리포지토리를 포크하여 새로운 브랜치를 생성하고(git checkout 명령 또는 웹 인터페이스 사용), 이 브랜치를 로컬 머신에 클론합니다.
   
   
2. 기여자는 변경 사항을 작업하고 브랜치에 로컬로 코드를 커밋합니다.
   
   
3. 기여자가 코드를 완료하고 테스트한 후, 코드를 푸시하기 전에 충돌을 방지하기 위해 메인 리포지토리의 최신 변경 사항을 먼저 가져옵니다.
   
   
4. 기여자는 제안한 변경 사항을 메인 브랜치에 통합하기 위해 새로운 풀 리퀘스트를 생성합니다.
   
   
5. 리뷰어는 풀 리퀘스트가 제출되면 알림을 받습니다. 리뷰어는 PR을 확인하여 기여자의 브랜치와 메인 브랜치 간의 차이(디프라고도 함)를 비교하고 코드를 검토하며, 최적화 또는 개선이 필요한 부분에 대해 의견을 남깁니다.
   
   
6. 기여자는 리뷰어의 제안과 변경 요청에 따라 추가 커밋을 수행합니다.
   
   
7. 모든 변경 사항이 반영되면 리뷰어는 관리자에게 알리고, 관리자는 PR을 승인합니다. 그 후 풀 리퀘스트는 메인 리포지토리에 병합됩니다.

소프트웨어 개발 팀은 필요에 따라 다양한 PR 워크플로 옵션 중에서 선택할 수 있습니다. 일반적인 풀 리퀘스트 워크플로는 다음과 같습니다.

• 기능 브랜치 워크플로

• 포크 워크플로

• git-flow

• 스택형 워크플로

각 새로운 기능은 기능의 목적을 명확히 나타내는 설명적인 이름의 전용 브랜치를 가집니다. 기능이 완료되면 개발자는 해당 기능 브랜치를 메인 브랜치로 푸시하고 풀 리퀘스트를 생성할 수 있습니다.

이 워크플로는 기여자가 기능별로 독립적으로 작업하는 동안 메인 브랜치의 안정성을 유지합니다. 그러나 여러 기능 브랜치를 관리하는 것은 복잡해질 수 있습니다.

이전에 설명한 풀 리퀘스트 생성의 7단계 절차는 포킹 워크플로에 해당합니다. 오픈 소스 프로젝트에서는 이 워크플로를 자주 사용하며, 이는 지속적 통합/지속적 배포(CI/CD) 방식과도 잘 맞습니다. GitHub flow는 포킹 워크플로와 유사한 절차를 따릅니다.

소프트웨어 엔지니어 Vincent Driessen은 2010년에 git-flow를 고안했습니다. 이는 일반적으로 엄격한 릴리스 일정이 있는 소프트웨어나 여러 버전을 지원하는 소프트웨어를 구축할 때 사용됩니다.

이 워크플로는 다음과 같은 브랜치로 구성된 브랜칭 모델을 따릅니다.

• main 최신 안정 릴리스를 유지하는 브랜치입니다.

• develop 다음 릴리스에 포함될 버그 수정, 기능 및 기타 코드 변경 사항을 통합하는 브랜치입니다.

• feature develop 브랜치를 소스 및 대상 브랜치로 사용하며, 기능이 준비되면 develop에 병합됩니다.

• release develop에서 분기되고 다음 릴리스의 버전 번호로 태그된 후, 배포 준비가 완료되면 develop과 main에 모두 병합됩니다.

• hotfix main에서 직접 분기되어 높은 우선순위 또는 심각한 프로덕션 문제를 수정하고, 수정이 완료되면 즉시 develop과 main에 모두 병합됩니다.

개발자는 검토가 필요한 hotfix , feature , release 브랜치에 대해 풀 리퀘스트를 생성합니다.

스택형 워크플로는 큰 작업을 작은 점진적 코드 변경의 연속으로 분해합니다. 다음 코드 변경은 이전 변경에 의존하므로, 풀 리퀘스트는 서로 위에 쌓이는 방식으로 구성됩니다.

다음과 같은 기능에 변경이 필요한 기능을 고려해 보세요. 데이터베이스 또는 데이터 모델, API, 그리고 프론트엔드입니다. 기존의 기능 브랜치 또는 포킹 워크플로에서는, 기여자가 API 업데이트를 시작하기 전에 데이터베이스 또는 데이터 모델 변경에 대한 PR이 검토, 승인되고 메인 브랜치에 병합될 때까지 기다려야 합니다. 스택형 워크플로에서는 이러한 대기 시간이 제거되어, 기여자는 데이터베이스 또는 데이터 모델 변경에서 분기하여 API 작업을 시작하고, 이에 대한 PR을 제출한 뒤 API 변경에서 다시 분기하여 프론트엔드 작업을 진행할 수 있습니다.

풀 리퀘스트는 다음과 같은 이점을 제공합니다.

• 협업 촉진

• 코드 품질 향상

• 투명성 향상

• 코딩 역량 강화

풀 리퀘스트는 협력을 촉진하여 역할에 관계없이 팀 구성원이 함께 작업하도록 장려합니다. PR은 피드백과 그 대응 방식을 촉진하고, 논의를 활성화하며, 개선 아이디어를 이끌어냅니다.

PR은 코드 리뷰 프로세스를 시작하여 버그, 코딩 스타일 및 표준에서의 이탈, 성능 문제 및 보안 취약점을 식별하는 데 도움을 줍니다. 이러한 추가 검토는 코드 품질을 유지하거나 더욱 향상시킵니다.

풀 리퀘스트를 통해 팀은 어떤 변경이 이루어졌는지, 누가 변경했는지, 어디에 적용되었는지, 그리고 그 이유를 확인할 수 있습니다. 이러한 가시성은 코드베이스와 프로젝트 상태에 대한 더 나은 통찰을 제공합니다.

리뷰어와 기여자 모두 서로에게서 배우며 새로운 기법을 익히고 문제에 대한 새로운 접근 방식을 발견할 수 있습니다. 초보자와 신규 팀원은 이전 PR을 학습하여 코드베이스를 더 잘 이해하고 팀의 코딩 표준과 모범 사례를 빠르게 익힐 수 있습니다.

풀 리퀘스트 생성은 간단해 보이지만, 다음과 같은 팁과 요령을 활용하면 프로세스를 더욱 원활하게 만들 수 있습니다.

• 초안 활용

• 세부 사항 중요

• 집중 유지

• 최신 상태 유지

• 템플릿 활용

초안 풀 리퀘스트 또는 머지 리퀘스트는 개발자가 진행 중인 작업을 공유할 수 있는 수단입니다. 이를 통해 팀원들은 더 이른 시점에 협업을 시작하고 더 빠르게 피드백을 받을 수 있어, 문제에 막힌 경우 동료로부터 해결 아이디어를 얻을 수 있습니다.

개발자는 새로운 커밋에 대해 명확하고 간결하며 구체적인 메시지를 제공해야 합니다. 명확성, 간결성, 구체성은 PR 제목과 설명에도 적용되어, 리뷰어가 코드 변경의 의도를 더 빠르고 쉽게 파악할 수 있도록 합니다.

여러 이슈를 하나의 PR로 묶으면 리뷰 시간이 길어지고 수정 횟수가 늘어날 수 있습니다. 각 풀 리퀘스트는 하나의 버그 수정 또는 기능만 다뤄야 합니다. 집중된 풀 리퀘스트는 보다 효율적인 코드 리뷰로 이어질 수 있습니다.

코드를 푸시하고 PR을 열기 전에 개발자는 자신의 브랜치가 최신 상태인지 확인해야 합니다. 최신 변경 사항과 새로운 커밋을 반영하면 풀 리퀘스트가 병합될 때 충돌을 방지할 수 있습니다. 대상 브랜치에서 변경 사항을 가져와 병합하기 위해 git pull 명령을 사용하거나, 깔끔한 git 커밋 이력을 위해 git rebase 명령을 사용할 수 있습니다.

PR 설명 템플릿은 일관성을 유지하고 코드 리뷰를 간소화하는 데 필요한 중요한 컨텍스트를 제공합니다. 팀은 버그 수정, 기능 추가 또는 리팩터링된 코드와 같은 다양한 풀 리퀘스트 유형에 맞는 템플릿을 만들 수 있습니다.

템플릿은 일반적으로 마크다운 마크업 언어로 작성되며 프로젝트 리포지토리의 루트 폴더 또는 메인 브랜치에 배치됩니다. 일반적으로 다음과 같은 항목이 포함됩니다.

• 문제 또는 기능 설명(Jira 또는 기타 이슈 추적 소프트웨어의 해당 티켓 링크 포함)

• 코드 변경 사항을 상세히 설명한 해결 방법

• 단위 테스트 또는 통합 테스트 사례, 테스트 커버리지 및 필요 시 수동 검증 절차와 같은 테스트

• 구성 변경

• 코드 문서화 및 오류나 경고 없이 빌드되는 코드와 같은 관련 작업 체크리스트

PR 자동화는 생성부터 리뷰 및 병합까지 풀 리퀘스트의 전체 수명 주기를 가속화할 수 있습니다. PR 자동화는 병목을 완화하는 데 도움을 주는 시스템 계층을 포함합니다.

• 스택형 PR

• CI/CD 파이프라인

• SDLC 관리 시스템

• AI 기반 코딩 어시스턴트

대부분의 Git 리포지토리는 스택형 워크플로를 지원하도록 설계되지 않았지만, 일부 툴은 스택형 풀 리퀘스트 동기화 및 병합 충돌 처리의 복잡성을 추상화합니다. 이러한 툴에는 스택형 PR을 위한 CLI와 Microsoft의 VS Code 확장, 관리용 웹 인터페이스를 제공하는 Graphite 플랫폼, Meta의 Sapling 소스 코드 관리 시스템, 그리고 스택형 변경 사항을 GitHub에 별도의 풀 리퀘스트로 제출할 수 있는 오픈 소스 ghstack CLI가 포함됩니다.

자동화된 DevOps 워크플로로서 CI/CD 파이프라인은 코드 품질을 보장하는 데 도움을 줍니다. GitHub Actions, GitLab 및 기타 CI 툴과 같은 플랫폼은 단위 테스트와 통합 테스트를 실행하고 PR에서 코드 변경 사항을 확인하고 테스트할 수 있는 샌드박스 역할의 프리뷰 환경을 배포할 수 있습니다.

CI/CD 파이프라인은 또한 보안 코딩 관행을 강화합니다. 정적 코드 분석기와 기타 정적 애플리케이션 보안 테스트(SAST) 툴은 대부분의 CI/CD 환경과 원활하게 통합되어 잠재적인 코드 취약점을 식별합니다. DevOps 팀은 비밀 정보 탐지를 위한 프리커밋 훅을 구현하여 개발자가 코드를 커밋하거나 풀 리퀘스트를 시작하기 전에 비밀 정보 스캔을 필수 단계로 만들고, 하드코딩된 비밀 정보가 포함된 변경 사항을 차단할 수 있습니다.

Jira 및 IBM® Engineering Lifecycle Management(ELM)과 같은 플랫폼은 소프트웨어 개발 생명주기(SDLC) 전반에 걸쳐 풀 리퀘스트의 추적 및 관리를 지원합니다.

ELM 제품군의 일부인 IBM Engineering Workflow Management(EWM)과 IBM® Engineering Integration Hub는 PR 자동화를 개발 워크플로에 직접 통합합니다. EWM은 Hub의 커넥터를 통해 Git 리포지토리와 연결되어 작업 항목에서 PR 생성을 트리거할 수 있습니다. EWM에서 요구 사항 또는 변경 요청이 승인되면, 규칙에 따라 연결된 Git 리포지토리에 자동으로 풀 리퀘스트가 생성되고 설명이 미리 채워질 수 있습니다.

ELM의 AI 기반 자동화는 PR이 열리면 정적 분석과 테스트 스위트를 실행하고, 결과를 작업 항목에 게시하며, 기준이 충족될 때까지 병합을 차단할 수 있습니다. 한편 Hub는 여러 툴 간에 PR 상태를 동기화하여 리포지토리와 EWM 대시보드에 반영함으로써 실시간 가시성을 제공합니다.

GitHub Copilot 및 IBM® Bob과 같은 AI 기반 코딩 어시스턴트는 풀 리퀘스트 워크플로를 강화할 수 있습니다. 예를 들어 Bob은 형식이 잘 갖춰진 의미 있는 커밋 메시지를 생성할 수 있습니다. 브랜치 이름과 커밋 이력을 분석하여 프로젝트의 스타일 규칙에 맞춥니다.

Bob은 개발자의 IDE에서 직접 풀 리퀘스트를 생성할 수도 있습니다. 브랜치 이름, 코드 변경 사항 및 커밋 이력을 분석하여 목적과 범위를 파악합니다. 그 후 변경 사항을 요약하는 PR 제목과 상세 설명을 생성하며, 프로젝트의 기존 PR 템플릿을 자동으로 감지하여 사용합니다.