CI에서 나만의 AI 코드 리뷰 에이전트 만들기
Source: Dev.to
번역을 진행하려면 실제 번역이 필요한 텍스트(본문)를 제공해 주시겠어요?
본문을 알려주시면 원본 형식과 마크다운을 그대로 유지하면서 한국어로 번역해 드리겠습니다.
The problem with manual PR reviews
If you do PR reviews all day, you already know the pain:
- Reviewers miss stuff when they’re tired.
- The same comments repeat forever (naming, tests, edge cases).
- A “quick PR” turns into a 45‑minute context rebuild.
AI‑powered 솔루션
모든 풀 리퀘스트가 즉시 구조화된 코드 리뷰(정확성, 보안, 성능, 테스트)를 CI가 자동으로 게시하고, 원하는 모델(OpenAI, Anthropic, OpenRouter, 혹은 로컬 Ollama 인스턴스)을 사용한다고 상상해 보세요 — 별도의 “AI 코드 리뷰” 구독료를 내지 않아도 됩니다.
핵심은 모델이 아니라 리뷰 루브릭(프롬프트/워크플로)이며, 이것이 유용한 구조를 강제합니다:
- 고위험 이슈와 사소한 지적을 구분합니다.
- 구체적인 수정 방안과 테스트 제안을 요구합니다.
- “내가 살펴본 내용”과 “내가 확신하지 못하는 부분”을 명시하도록 합니다.
CI 기반 리뷰가 의미 있는 이유
- 채팅 구독은 인터랙티브 사용에 좋지만, CI 코드 리뷰는 다른 가격 구조를 따릅니다: PR이 발생할 때만 실행됩니다.
- 사용량 기반 API를 이용하거나, 작은 차이에 대해 더 저렴하고 빠른 모델을 라우팅하거나, 한계 비용이 거의 제로인 로컬 모델(Ollama)을 실행할 수 있습니다.
- DIY 파이프라인을 통해 모델 선택, 최대 토큰 수, 실행 시점, 그리고 “검토할 가치가 있는” 기준을 직접 제어할 수 있습니다.
최종 결과
- 모든 PR에서 실행되는 GitHub Action.
- 구조화된 Markdown 리뷰를 출력하는 코드‑리뷰 워크플로우.
GitHub Action 정의
리포지토리에서 .github/workflows/ai-code-review.yml 파일을 생성하세요:
name: AI Code Review
on:
pull_request:
jobs:
review:
runs-on: ubuntu-latest
permissions:
contents: read
pull-requests: write
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- name: Install Jazz
run: npm install -g jazz-ai
- name: Run code review workflow
run: jazz --output raw workflow run code-review --auto-approve
env:
OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}참고
--output raw는 CI에서 편리합니다(캡처/리다이렉트가 쉽습니다).--auto-approve는 해당 단계를 완전 자동화합니다.- 권한은 의도적으로 최소화되었습니다.
OpenAI가 아닌 다른 제공자를 사용하려면 환경 변수를 해당 제공자(Anthropic, OpenRouter 등)용으로 교체하세요.
리뷰 루브릭 (프롬프트) 정의
파일 **workflows/code-review/WORKFLOW.md**를 생성하세요. 이것이 에이전트가 실행할 프롬프트입니다:
---
name: code-review
description: Review PR diff and produce a structured report
autoApprove: read-only
---
Review the current PR diff.
Output GitHub‑flavored Markdown with:
1. **Summary** (2–4 bullets)
2. **High‑risk issues** (correctness + security)
3. **Performance / complexity concerns**
4. **API / UX footguns**
5. **Test gaps + concrete test suggestions**
6. **Nitpicks** (style/readability)
**Rules**
- Be specific: reference files/functions.
- Prefer minimal diffs / smallest safe fix.
- If you’re unsure, say so and propose how to verify.
- No generic advice (“add tests”) — propose exact test cases.
- Rank issues (High/Medium/Low).
- List files reviewed, assumptions, and what was not checked.리뷰 캡처 및 게시
GitHub Action에 리뷰를 파일에 기록하고 PR에 댓글을 다는 단계를 추가합니다:
- name: Generate review markdown
run: jazz --output raw workflow run code-review --auto-approve > review.md
env:
OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
- name: Comment on PR
run: gh pr comment "$PR_NUMBER" --body-file review.md
env:
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
PR_NUMBER: ${{ github.event.pull_request.number }}인라인 주석은 나중에 추가할 수 있지만, 즉각적인 가치를 얻기 위해 반드시 필요하지는 않습니다.
Best‑practice checklist
- 읽기 전용 모드: 검토 작업에서는
autoApprove를 읽기 전용으로 유지하고, 에이전트가 저장소를 변경하지 못하도록 합니다. - 이슈 순위 매기기: 에이전트가 이슈를 (높음/중간/낮음)으로 순위를 매기도록 강제합니다. 모든 것이 “중요”라면 실제로 중요한 것이 없게 됩니다.
- 오탐 예산: 리뷰가 일주일 동안 잡음이 많으면 개발자들이 무시하게 됩니다. 이에 맞게 평가 기준을 조정합니다.
- 모델 라우팅: 작은 PR에는 저비용 모델을 사용하고, 대규모 리팩터링에는 더 강력한 모델을 사용합니다.
- 투명성: 에이전트가 검토한 파일 목록, 가정한 내용, 그리고 검토하지 않은 항목을 명시하도록 요구합니다.
실제 사례
Jazz 저장소는 자체 코드 리뷰와 릴리즈 노트에 Jazz를 사용합니다. 워크플로 파일은 여기에서 확인하세요: https://github.com/lvndry/jazz/tree/main/.github
읽어 주셔서 감사합니다!