제가 일하는 회사는 GitHub에서 PR 기능을 거의 안 써요.
작업 관리는 노션이나 엑셀로 하고, 코드 리뷰도 크게 없어요.
왜 안 쓸까 생각해봤는데요.
늘 마감에 쫓기듯 개발을 해야 하니까, 이런 프로세스 자체가 사치로 느껴지는 건 아닐까 싶더라고요.
그리고 개발을 함께 하기보단, 각자 알아서 하는 분위기라 문서화나 리뷰에 큰 의미를 두지 않는 것 같기도 하고요.
그래도 저는 PR 템플릿을 꼭 만들고 싶었어요.
회사에선 회사 방식대로 일하더라도, 회사 밖에선 제가 원하는 방식으로 개발하고 싶어서요.
왜 굳이 PR 템플릿을 만들었냐고요?
취업 준비하면서 팀 프로젝트를 꽤 여러 번 했어요.
그때마다 팀원들의 생각, 경험, 스타일이 다 달라서 PR 하나 쓰는 데도 합을 맞추는 데 시간이 꽤 걸렸어요.
그때 느꼈어요.
"PR 템플릿이 있으면 이런 거 좀 덜 헤맬 수 있겠다."
그래서 여유가 좀 생긴 지금, 제가 직접 템플릿을 만들어보기로 했어요.
어떻게 만들었지?
우아한형제들, 카카오, SK DEVOCEAN 같이 큰 기업에서 운영하는 테크 블로그를 쭉 살펴봤어요.
큰 기업에서 똑똑한 사람들이 고민한 내용들은 분명 도움이 될거라고 생각했고, 실제로 도움이 됐어요.
-
우아한형제들은 PR에서는 "문제"란 키워드를 사용해서 "뭘 바꿨는지"보단 "왜 바꾸려 했는지"를 더 중시하는 느낌이더라고요. 그래서 문제 중심으로 쓰도록 했어요.
-
카카오는 실수 방지를 위한 체크리스트를 제공하고 있었는데, 저처럼 PR 기능에 익숙하지 않은 사람에게 꼭 필요하겠다 싶었어요.
-
SK DEVOCEAN은 PR 리뷰 문화를 따로 정리해두었더라고요. 그리고 PR 코멘트에 P1~P3를 붙여서 우선순위를 명확히 하는 방식도 인상 깊었고요.
그래서 완성된 템플릿은 이런 식이에요
# 📌 PR 템플릿
## 🔍 어떤 문제가 있었나요?
> 해결하려는 문제의 배경과 맥락을 간단히 설명해주세요.
> ex) 모바일 Safari에서 이미지가 잘리는 문제가 발생함
## ❓ 왜 이게 문제라고 판단했나요?
> 사용자 경험, 비즈니스 영향, 데이터 근거 등 판단한 이유를 설명해주세요.
> ex) 제품 정보 확인이 어려워 사용자 이탈이 유발됨
## 🛠 어떻게 해결했나요?
> 핵심 변경사항 위주로 작성해주세요.
> ex) 이미지 컨테이너에 object-fit: contain 스타일 추가
## 📝 기타 변경사항이 있다면 작성해주세요
> 리팩토링, 불필요한 코드 제거 등 핵심 외의 변경사항이 있다면 기재해주세요.
> 없으면 `없음`이라고 명시해주세요.
## 🧪 테스트 방법
### 🔬 유닛 테스트
> 유닛 테스트가 작성/수정되었다면 적어주세요.
> ex) useAuth 훅 테스트 케이스 추가
### 👀 수동 테스트
> 브라우저 또는 직접 동작 확인이 필요한 경우 작성해주세요.
> ex) 로그인 후 /dashboard로 리디렉트 되는지 확인
## 🤔 리뷰어에게 요청하고 싶은 부분
> 리뷰 중 확인받고 싶은 부분, 고민한 설계 등에 대해 작성해주세요.
> ex) 조건 분기 처리 방식에 더 나은 구조가 있을지 피드백 요청
## 📸 스크린샷 / GIF (UI 변경이 있다면 첨부)
> UI가 변경되었을 경우 비교 가능한 스크린샷 또는 동작 GIF를 첨부해주세요.
## 🔗 관련 이슈 / 문서
> 관련 이슈 번호 또는 문서 링크를 첨부해주세요.
> ex) closes #42, Notion 기획 문서 링크 등
## ✅ Assignee용 CheckList (PR 올리기 전 아래 내용을 확인해주세요)
- merge할 브랜치의 위치를 확인해 주세요. (`master/main❌`)
- WIP(작업 중) 상태는 아닌지 확인해주세요. (불필요한 Draft PR, `WIP:` 제목 등)
- Approve된 PR은 리뷰어가 merge 하고, 수정 요청이 온 경우 수정 후 다시 push 합니다.
### 📌 PR 리뷰 진행 시 참고 사항
- 리뷰어는 코드 수정 강제보다는 좋은 방향 제시를 지향해주세요.
- 좋은 코드를 발견했다면 칭찬과 격려를 함께해주세요.
- 리뷰는 특별한 사정이 없다면 지정 후 3일 이내에 진행해주세요.
- Comment 작성 시 Prefix(P1~P3)를 사용하면 대응이 쉬워집니다:
- **P1**: 꼭 반영이 필요한 변경 (Request Changes)
- **P2**: 반영을 권장하는 개선 (Comment)
- **P3**: 사소한 제안 또는 참고 의견 (Chore)일단 완성은 했지만 고민중인 부분이 많아요.
각 항목이 꼭 필요한 부분이 맞는지, 추가되야 할 항목이 있는지, 예시는 필요한 건지 등등...
하지만 일단 마무리가 있어야지 다른 사람들의 피드백을 받을 수 있으니까요.
다른 사람들과 프로젝트 할 일이 있을 때 사용해보면서 피드백 받아보려고요.
마무리하며
저는 개발을 배우면서 PR 같은 건 꽤 늦게 알게 됐어요.
취직 전 공부할 것도 많고, 취업 준비가 우선이라 이런 건 계속 미뤄졌어요.
궁금한 게 생겨도 취업에 직접적으로 도움이 되지 않으면 우선순위를 뒤로 미뤘어요.
그래도 팀 프로젝트를 하면서 문서화나 리뷰 같은 과정이 협업에 정말 중요하다는 걸 느꼈어요.
그래서 지금은 실무에서 쓰지 않더라도 저만의 기준을 하나 만들어두고 싶었어요.
혹시 저처럼 이런 걸 늦게 접했거나, 어디서부터 시작해야 할지 막막한 분이 있다면 제 템플릿이 작은 힌트가 되었으면 좋겠어요.
혹시 더 좋은 아이디어나 조언이 있다면 편하게 알려주세요.
여러분의 작은 조언이 저에게는 큰 도움이 될 거예요.
