코드 검토가 없는 팀

위험 요소

CI는 테스트가 다루는 부분만 잡아냅니다. 검토가 없으면 다음 두 가지 문제를 놓치게 됩니다:

• 모델 편향. 코드를 작성한 모델은 작업을 확인하라고 요청해도 자신의 추론을 그대로 받아들이고 자신의 실수를 놓치기 쉽습니다.
• 반복 수정으로 인한 오류. 에이전트가 같은 코드를 거듭 수정하면, 매번의 변경이 이전에 제대로 되어 있던 부분을 모르는 사이에 깨뜨릴 수 있습니다.

HeyDeer가 더하는 것

• 독립적인 의견. HeyDeer는 코드를 작성한 에이전트와 별개로 각 풀 리퀘스트를 검토하며, 모든 발견 사항을 게시하기 전에 코드와 대조해 확인합니다.
• 전담 검토 프로세스. 푸시할 때마다 검토가 이루어지고, 후속 검토가 이전 우려 사항을 다시 확인하며, HeyDeer Review 검사가 각 커밋에 결과를 기록합니다.

권장 구성

1. 모든 변경에 풀 리퀘스트를 여세요. 에이전트가 main에 커밋하는 대신 브랜치에 푸시하고 풀 리퀘스트를 열도록 하세요.
2. 푸시할 때마다 검토하세요. 워크스페이스 설정 → 검토 규칙에서 “검토 일정”을 “푸시할 때마다”로 설정하세요. 자동 검토를 참고하세요.
3. 문제가 있으면 검사가 실패하도록 하세요. “결과 게시” 아래에서 “문제가 발견되면 검사를 실패로 표시”를 켜세요. HeyDeer Review 검사를 참고하세요.
4. 자동 승인을 켜세요. “결과 게시” 아래에서 “자동 승인”을 켜세요. 완전한 검토 결과 남은 문제가 없으면 HeyDeer가 풀 리퀘스트를 승인합니다. “중대한 아키텍처 및 핵심 동작 변경”은 여전히 사람의 승인을 기다립니다. 이러한 변경도 승인하려면 “사람의 승인이 필요한 변경”을 “변경 유형에 대한 추가 제한 없음”으로 설정하세요. 자동 승인을 참고하세요.
5. GitHub에서 main을 보호하세요. main 브랜치 규칙에서 Require a pull request before merging 옵션을 켜고 필수 승인 수를 1로 설정한 뒤, Dismiss stale pull request approvals when new commits are pushed 옵션도 켜세요. 그런 다음 Require status checks to pass before merging 옵션을 켜고 CI 검사와 함께 HeyDeer Review를 추가하세요.
6. 자동으로 병합하세요. 저장소의 GitHub 설정에서 Allow auto-merge 옵션을 켜세요. 그런 다음 각 풀 리퀘스트에서 자동 병합을 활성화하거나, 에이전트가 풀 리퀘스트를 연 뒤 gh pr merge --auto --squash를 실행하도록 하세요.

팀의 기준을 검사로 작성하기

에이전트는 검토에서 강제하는 규칙을 더 확실하게 따릅니다. 규칙마다 .agents/checks/에 Markdown 파일을 추가하면, HeyDeer가 일치하는 파일을 변경하는 모든 풀 리퀘스트에 그 규칙을 적용합니다. 저장소 검사를 참고하세요.

.agents/checks/tenant-scope.md

---
files:
  - "src/db/**/*.ts"
  - "!**/*.test.ts"
---
Every query that reads or writes customer data must be
scoped to one tenant, taken from the request context and
never from request parameters.