기획자를 위한 깃허브 실전⑤ — Pull Request
브랜치를 나누고 자동 배포까지 설정했다면, 이제는 ‘함께 일하는 방법’을 알아야 합니다. 깃허브에서는 그걸 Pull Request(풀 리퀘스트) 라고 부릅니다. 이건 단순히 코드 승인 절차가 아니라, 기획자도 팀과 아이디어를 공유하고 변경사항을 확인할 수 있는 협업 도구입니다.
Pull Request로 협업 완성하기 — 개발팀처럼 의견을 주고받는 방법
브랜치를 나누고 자동 배포까지 설정했다면, 이제는 ‘함께 일하는 방법’을 알아야 합니다. 깃허브에서는 그걸 Pull Request(풀 리퀘스트) 라고 부릅니다. 이건 단순히 코드 승인 절차가 아니라, 기획자도 팀과 아이디어를 공유하고 변경사항을 확인할 수 있는 협업 도구입니다.
Pull Request란 무엇인가
Pull Request(줄여서 PR)는 “내가 수정한 내용을 원본(main 브랜치)에 반영해도 될까요?”라고 요청하는 절차입니다. 즉, 누군가의 브랜치(feature, dev 등)에서 작업한 내용을 다른 사람이 검토하고, 승인하면 main으로 합치는 과정이죠.
기획자의 언어로 바꾸면 이렇게 이해할 수 있습니다.
“내가 수정한 문서를 검토해 주세요.” → 검토 후 승인되면, 메인 문서에 반영됩니다.
이건 단순한 기술 절차가 아니라, 팀 내의 “검토·의견 교환·승인”을 하나의 흐름으로 만드는 협업 방식입니다.
왜 기획자에게 중요한가
기획자 입장에서 PR의 가치는 단순합니다. “내 요청이 코드에 어떻게 반영되는지 확인할 수 있는 창구”이기 때문입니다.
예를 들어,
- 디자인팀이 버튼 위치를 변경했을 때
- 개발팀이 정책 문구를 수정했을 때
- 테스트 과정에서 오류를 발견했을 때
이런 모든 수정사항은 PR을 통해 확인할 수 있습니다. PR을 열면 누가 무엇을, 왜 수정했는지가 한눈에 보이고, 기획자는 그 내용을 직접 검토하고 코멘트를 남길 수 있습니다.
Pull Request의 기본 흐름
- 브랜치에서 작업
개발자나 디자이너가
feature/policy-update같은 브랜치를 만듭니다. - 커밋 & 푸시 수정 내용을 깃허브에 올립니다.
- Pull Request 생성 깃허브에서 “Compare & pull request” 버튼을 클릭합니다. → 어떤 파일이 수정됐는지 자동으로 비교됩니다.
- 검토 및 의견 남기기 기획자는 깃허브 웹화면에서 바로 코멘트를 남길 수 있습니다. “문구를 다시 한 번 확인해주세요” 같은 피드백도 가능합니다.
- 승인 후 머지(Merge) 수정 내용이 승인되면 main 브랜치에 합쳐집니다. 자동배포(CI/CD)가 설정되어 있다면, 즉시 반영됩니다.
기획자가 직접 할 수 있는 일
기획자는 코드를 수정하지 않아도 Pull Request 안에서 다음과 같은 역할을 할 수 있습니다.
- 변경 내용 요약 읽기 어떤 파일이 바뀌었는지, 왜 수정되었는지 확인
- 코멘트 작성 정책문구, UI 흐름, 텍스트 표현 등에 피드백 남기기
- 승인 또는 보류 요청 “이 변경은 다음 배포에 반영해주세요” 같은 의견 표시
- 변경 이력 확인 과거의 PR을 통해 누가 어떤 수정 요청을 했는지 추적 가능
이 모든 과정은 이메일 대신 깃허브 안에서 정리되므로, 협업 히스토리가 명확하게 남습니다.
예시: 기획자와 개발자의 실제 협업 상황
👩💼 기획자: “신규가입 화면에서 버튼 문구가 ‘확인’으로 바뀐 것 같아요.” 👨💻 개발자: “맞아요. 이번에
feature/signup-text브랜치에서 수정했어요.” 👩💼 기획자: “Pull Request 링크 공유해주실 수 있을까요?” 👨💻 개발자: “여기요. GitHub에서 변경 내용 보시고 의견 주세요.”
→ 기획자는 깃허브 웹 화면에서 수정된 문구를 바로 보고 코멘트를 남깁니다. 승인 후 merge가 되면, 자동배포로 실제 페이지에도 반영됩니다.
이게 바로 CI/CD와 Pull Request가 연결되는 순간입니다.
Pull Request를 쓰면 달라지는 협업 문화
- “메일 확인해주세요” 대신 “PR 링크 확인해주세요.”
- “누가 수정했는지 몰라요” 대신 “히스토리에 다 남아있어요.”
- “언제 반영돼요?” 대신 “merge 후 자동배포됩니다.”
기획자도 더 이상 개발 일정이나 소스 반영 시점을 ‘감’으로 판단하지 않아도 됩니다. PR과 CI/CD를 이해하면, 기획이 개발의 타이밍을 예측하고 조율할 수 있는 수준으로 올라오게 됩니다.
Pull Request는 “승인 절차”가 아니라 “대화 도구”입니다.
이 기능을 이해하는 순간, 기획자는 개발자와 같은 도구 위에서 일하게 됩니다. 브랜치를 나누고, 자동배포로 반영되고, PR로 의견을 주고받는 구조가 완성되면 기획과 개발은 더 이상 따로 움직이지 않습니다. 그게 바로 깃허브 협업의 완성입니다.