CodeRabbit 세팅

codeRabbit

Organization Settings yaml 파일

# yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json
language: ko-KR
tone_instructions: >
  당신은 코치입니다. 목표는 크루들이 코드 품질을 개선하며 성장하도록 돕는 것입니다. 1. 피드백은 명확하고 구체적이어야 하며, 문제의 원인과 개선 방법을 반드시 제시하세요.
  2. 리뷰는 교육적이어야 하며, 관련 개념이나 공식 문서를 함께 추천하세요. 3. 비판보다는 개선 중심의 제안을 우선하세요. 4. 칭찬은 짧고 위트 있게 작성하세요.
reviews:
  request_changes_workflow: true
  sequence_diagrams: false
  related_issues: false
  related_prs: false
  suggested_reviewers: false
  path_instructions:
    - path: frontend/**
      instructions: |
        1. 기준: HTML/CSS/Vanilla JS best practices를 기반으로 리뷰해주세요.
        2. 우선순위: (1) 런타임 에러/예외 처리(null/undefined, fetch 실패, JSON 파싱 등)
           (2) DOM 조작 안정성/이벤트 누수
           (3) 보안(XSS, innerHTML 사용, 사용자 입력 처리)
           (4) 성능(불필요한 reflow/반복 렌더)
           (5) 접근성(aria, label, 키보드 내비게이션).
        3. 리뷰는 가장 중요한 5개 포인트만 상세히 작성하고, 나머지는 캡션으로 요약해주세요.
        4. 가능한 경우 짧은 예시 코드(10~20줄 이내)로 개선안을 제시해주세요.
        5. 코멘트는 해당 라인 범위에 작성해주세요.
    - path: backend/**
      instructions: |
        1. 기준: Java/Spring Boot 백엔드 best practices를 기반으로 리뷰해주세요.
        2. 우선순위: (1) API 계약/DTO/입력 검증(Bean Validation)
           (2) 예외 처리 및 에러 응답 일관성
           (3) 트랜잭션/동시성
           (4) DB/쿼리 성능(N+1, 인덱스, 페이징)
           (5) 보안(인증/인가, CORS/CSRF).
        3. 리뷰는 가장 중요한 6개 포인트만 상세히 작성하고, 나머지는 캡션으로 요약해주세요.
        4. PR 범위 내에서 적용 가능한 개선만 제안해주세요.
        5. 테스트가 없다면 필요한 테스트를 3~5개 제안해주세요
           (Controller/API, Service, Repository 중 어디인지 명시).
        6. 코멘트는 해당 라인 범위에 작성해주세요.
knowledge_base:
  code_guidelines:
    enabled: false
  learnings:
    scope: local
  issues:
    scope: local
  pull_requests:
    scope: local

1) 파일 헤더: 스키마 + 언어 서버 지원

# yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

기능: YAML 편집기(예: VSCode)가 이 파일을 “CodeRabbit 설정 스키마”로 인식하게 해줘서
자동완성, 타입 체크, 경고 표시가 가능해짐.

효과: 오타/잘못된 키를 빨리 잡아줌 → 설정 실수 줄어듦.

2) 전역 스타일: 리뷰 언어/톤 지정

language: ko-KR
tone_instructions: >
  당신은 코치입니다...

language: ko-KR

기능: 리뷰 코멘트/응답을 한국어(ko-KR)로 출력하도록 유도.

tone_instructions

기능: 봇의 “리뷰 성격(페르소나)”을 정의.

효과: “지적만 하는 봇”이 아니라, 팀 성장에 도움되는 코치형 리뷰로 일관성 유지.

3) 리뷰 동작 옵션: 리뷰 결과/부가 기능 토글

reviews:
  request_changes_workflow: true
  sequence_diagrams: false
  related_issues: false
  related_prs: false
  suggested_reviewers: false

request_changes_workflow: true

기능: 리뷰가 “바꿔야 머지 가능”한 스타일로 동작(보통 GitHub의 Request changes 흐름에 맞춤).

효과: 봇이 중요 이슈를 발견하면 “권장”이 아니라 변경 요구로 강하게 걸어줄 수 있음 → 품질 게이트 역할.

sequence_diagrams: false

기능: PR에서 흐름/아키텍처를 시각화하는 시퀀스 다이어그램 생성 비활성화.

효과: 리뷰 노이즈 줄이고, 필요한 경우에만 사람이 문서화하도록.

related_issues / related_prs: false

기능: PR과 연관된 이슈/다른 PR을 자동으로 찾아 연결해주는 기능 비활성화.

효과: 링크/추론이 불필요할 때 리뷰를 깔끔하게 유지.

suggested_reviewers: false

기능: “이 PR은 누가 리뷰하면 좋다” 추천 비활성화.

효과: 팀에서 이미 리뷰어 지정 규칙이 있거나, 추천이 부정확해서 방해될 때 끔.

4) 경로별 규칙: frontend / backend를 “다른 기준”으로 리뷰

reviews:
  path_instructions:
    - path: frontend/**
      instructions: |
        ...
    - path: backend/**
      instructions: |
        ...

기능: 변경 파일 경로에 따라 리뷰 체크리스트/우선순위/출력 형식을 다르게 적용.

효과: 프론트/백엔드 리뷰 기준이 섞여서 이상한 피드백 나오는 걸 방지.

5) knowledge_base: CodeRabbit의 ‘기억/학습’ 범위 설정

knowledge_base:
  code_guidelines:
    enabled: false
  learnings:
    scope: local
  issues:
    scope: local
  pull_requests:
    scope: local

code_guidelines.enabled: false

기능: 별도의 “팀 코드 가이드라인 문서”를 지식 베이스로 사용하지 않음.

효과: 봇이 외부 가이드라인을 근거로 강하게 단정하지 않고, 여기 적힌 규칙 중심으로 움직임.

learnings / issues / pull_requests: scope: local

기능: 학습/참고 범위를 local로 제한.

해석: 조직 전체/레포 전체에 걸친 광범위한 추론보다, 현재 프로젝트/현재 PR 문맥에 가까운 범위에서만 판단하도록 제한하는 느낌.

효과: 맥락 과잉 추론, 엉뚱한 PR 끌고 오는 노이즈를 줄임.

도입 이유

새로 프로젝트를 시작하기 앞서서 혼자서는 제대로 하고 있는 지 피드백 받기 어렵기 때문에 코치와 같은 개념으로 PR리뷰를 자동화시켜 코드 품질 유지, 개선하려고 도입했습니다.