프로젝트 협업 과정에서 발생하는 코드 결함을 줄이고 원활한 진행을 돕기 위한 표준 운영 절차입니다.
PR 화면 우측 상단의 Review changes 버튼을 누를 때 사용하는 세 가지 기준입니다.
| 결정 항목 | 머지 차단 여부 | 적용 기준 | 예시 내용 |
|---|---|---|---|
| Comment | 차단 안 됨 | 단순 질문, 구현 의도 확인, 가벼운 제안 | *"이 부분에서 기본 사전 대신 defaultdict를 사용한 이유가 있나요?" |
| "테스트 케이스를 꼼꼼하게 작성해 주셔서 좋습니다."* | |||
| Approve | 승인 완료 | 요구사항 충족, 자동 검증 통과, 코드 안전성 확인 | *"예외 처리와 주석이 기준에 맞게 작성되었습니다. 머지 승인합니다." |
| "주석에 사소한 오타가 있지만 동작에 문제가 없으므로 승인합니다."* | |||
| Request changes | 머지 불가 | 취약점 발견, 데이터 스키마 임의 변경, 테스트 누락 | *"정규식 처리 과정에서 과도한 백트래킹 위험이 있습니다. 선형 탐색 방식으로 수정해 주세요." |
| "공통 인터페이스 필드가 변경되어 전체 테스트가 실패합니다. 원래대로 되돌려 주세요."* |
PR을 닫고 새로 만들지 않습니다. 에이전트 대화창의 컨텍스트 오염을 막기 위해 새 세션을 열고 수정합니다.
새 대화창 열기: 기존 개발 대화창을 닫고, 에이전트의 새 대화창을 엽니다.
리뷰 반영 명령 전달: 에이전트에 지적받은 리뷰 내용과 기존 브랜치 수정을 요청합니다.
"PR #[번호]에 코드 리뷰 피드백이 달렸어. 기존 브랜치(
feat/...)에서 지적받은 [피드백 내용]을 반영하고, check.ps1 검증 후 커밋/푸시해줘."
재검토 요청: 푸시가 끝나면 PR 화면에서 검토자 이름 옆의 새로고침 버튼(Re-request review)을 누릅니다.
승인 후 머지: 검토자가 수정 내용을 확인하고 Approve로 변경하면 머지가 가능해집니다.
회의가 길어지는 현상을 막기 위해 코드 검토와 상태 공유 시간을 분리하여 운영합니다.
Comment, Approve, Request changes 중 하나를 남깁니다.