협업의 문턱, 깃허브 코드 리뷰와 Pending의 늪
개인 프로젝트를 할 때는 자유롭기만 했던 깃허브가, 협업의 영역으로 들어오니 꽤 깐깐한 ‘수문장’처럼 느껴집니다. 우리 팀의 소중한 메인 브랜치를 지키기 위해 적용한 Ruleset과, 그 과정에서 겪은 코드 리뷰의 시행착오를 정리해 봅니다.
🛡️ 메인 브랜치를 보호하라: Ruleset 적용
팀 프로젝트에서는 main 브랜치에 코드를 합치기 전, 반드시 누군가의 검토를 거치도록 Ruleset을 설정했습니다. 시스템적으로 머지(Merge)를 막아두니 비로소 “협업”의 긴장감이 실감 났습니다. 하지만 이 규칙 때문에 오늘 예상치 못한 삽질을 하게 되었습니다.
💬 ‘댓글’과 ‘리뷰’는 한 끗 차이였다
분명 팀원의 PR에 정성스럽게 의견을 남겼는데, 깃허브는 여전히 “리뷰가 필요하다”며 머지 버튼을 활성화해주지 않았습니다. 알고 보니 제가 한 행동은 ‘리뷰’가 아니라 단순 ‘댓글’이었습니다.
❌ 단순 댓글 (Add single comment)
코드 옆의 [+] 버튼을 눌러 의견을 남길 때, 무심코 클릭한 Add single comment는 말 그대로 일회성 댓글입니다. 브랜치 보호 규칙을 만족시키는 ‘공식 리뷰’로 인정되지 않습니다.
✅ 코드 리뷰 (Start a review)
제대로 된 리뷰는 Start a review로 시작해야 합니다. 이 버튼을 누르면 내가 남기는 의견들이 하나로 묶여 ‘리뷰 진행 중’ 상태가 됩니다.
⏳ “Pending” 상태가 내 발목을 잡을 때
리뷰를 다 썼는데도 제 상태가 Pending으로 떠 있는 것을 발견했습니다.
- Pending의 의미: “아직 전송되지 않음”. 즉, 의견은 다 적었지만 최종 승인(Approve)이나 수정 요청을 담은 보따리를 상대방에게 던지기 전인 임시 저장 상태입니다.
최종적으로 Submit review 버튼을 찾아 누르고 나서야 비로소 보류 중이던 리뷰가 전송되었고, 막혀있던 Merge 버튼도 초록색으로 빛나기 시작했습니다.
🔄 대화의 마침표: Resolve conversation
리뷰가 끝난 뒤, 코드 옆에 생긴 Resolve conversation 버튼도 오늘 처음 제대로 써봤습니다.
- 리뷰어가 지적한 사항을 개발자가 수정한 뒤, 이 버튼을 눌러 “이 대화는 해결되었습니다”라고 표시하는 이정표입니다. 수많은 리뷰 속에서 어떤 논의가 끝났는지 한눈에 보여주는 아주 유용한 기능이었습니다.
🧠 오늘 느낀 점: 익숙함 속의 새로움
그동안 깃허브가 꽤 익숙하다고 생각했지만, 그것은 ‘개인용’ 깃허브에 국한된 것이었습니다.
- 깨달음: 협업 툴은 단순히 기능을 쓰는 게 아니라, 팀원 간의 신뢰를 시스템으로 약속하는 것이라는 점을 배웠습니다.
- 다짐: 앞으로는 리뷰를 남길 때
Submit review를 잊지 않았는지, 내 리뷰가Pending에 갇혀 팀원의 시간을 뺏고 있지는 않은지 꼭 확인해야겠습니다.
💡 오늘의 꿀팁
- 코드 옆 [+] 버튼은 리뷰의 시작점이다.
- Add single comment는 잡담, Start a review는 공식 문서다.
- 리뷰의 완성은 Submit review 버튼이다!