diff --git a/.coderabbit.yaml b/.coderabbit.yaml index fc3d7d8..a38d5a4 100644 --- a/.coderabbit.yaml +++ b/.coderabbit.yaml @@ -5,68 +5,58 @@ tone_instructions: "1. 리뷰 시에는 변경 사항의 문제점이나 한계 # ─────────── 리뷰(Reviews) 전반 ─────────── reviews: profile: chill - high_level_summary: true - high_level_summary_placeholder: "🤖 Code Rabbit PR 요약" - review_status: true - commit_status: true # 워크스루/자동화/부가 기능 - collapse_walkthrough: false changed_files_summary: false sequence_diagrams: false assess_linked_issues: true - related_issues: false - related_prs: false suggested_labels: false - auto_apply_labels: false suggested_reviewers: false - auto_assign_reviewers: false poem: false - # 경로별 리뷰 지침 및 제외 폴더 + # 리뷰 지침 path_instructions: - - path: android/** + - path: src/** instructions: | - - 1. 코틀린 공식 스타일 가이드 및 팀 컨벤션을 우선적으로 반영하여, 가독성, 안전성(Null/예외처리), 테스트/유지보수 용이성, 안드로이드 특화 사항(라이프사이클, 리소스, 권한 등)에 대해 리뷰해주세요. - - 2. 최신 코틀린/안드로이드 트렌드, 주석 및 문서화, 팀 스타일 통일성도 함께 확인해 주세요. - - 3. 각 리뷰 포인트별로 문제점과 대안, 장단점을 논리적으로 제시하고, 필요한 경우 예시 코드도 추가해 주세요. - - 4. 리뷰가 너무 많아서 피로감을 줄 수 있으니, 꼭 필요한 부분에 집중해주고, 나머지는 캡션으로 설명해주세요. - - 5. 리뷰 남겨주는 부분은 해당 라인 범위의 코멘트에 작성해주세요. - - path: backend/** - instructions: | - - 1. 팀 및 공식 컨벤션, 가독성, 예외처리, 테스트/확장/유지보수성, 모듈화, API/DB/보안 설계 기준을 기반으로 리뷰해주세요. - - 2. 최신 트렌드, 불필요한 로직, 클린코드, 리팩토링, 서비스/도메인 설계, 공통 예외 처리, 확장성도 함께 확인해주세요. - - 3. 각 피드백은 문제점·대안·장단점을 짧고 논리적으로, 예시 코드가 있다면 간결히 포함해 주세요. - - 4. 팀 내 스타일 통일성도 확인해주세요. - - 5. 미작성한 테스트 코드 케이스가 있다면, 어떤 테스트가 필요한지 제안해주세요. (예: 컨트롤러는 인수 테스트, 나머지는 단위 테스트) - - 6. 리뷰 남겨주는 부분은 해당 라인 범위의 코멘트에 작성해주세요. - - path: frontend/** - instructions: | - - 우리는 백엔드 개발자 팀으로, 관리자 페이지 프론트엔드를 Vibe 코딩 방식으로 빠르게 구현했습니다. - - React에 대한 전문적인 이해도가 부족한 상태이므로, 다음과 같은 기준으로 리뷰해 주세요: - - 1. 코드 스타일이나 컴포넌트 구조 등 전반적인 구조에 대한 일반적인 피드백은 생략해 주세요. - - 2. 보안상 취약점이 될 수 있는 부분 (예: XSS, CSRF, 사용자 입력 검증 부족 등) 은 반드시 알려주세요. - - 3. 화면 상 명백하게 어색하거나 비정상적으로 동작할 수 있는 UI/UX 요소만 지적해 주세요. - - 4. 빠른 배포를 목적으로 하기 때문에, 논리상 큰 이상이 없는 부분은 코멘트하지 않으셔도 됩니다. - - 5. 실제 사용자에게 혼동을 줄 수 있는 부분(버튼 비노출, 접근 불가능 등)이 있다면 꼭 알려주세요. - - 6. 해당 PR에는 테스트 코드가 포함되지 않았으며, 테스트 커버리지나 테스트 방식에 대한 피드백은 생략해 주세요. - - 위 기준을 바탕으로 꼭 필요한 피드백 위주로 리뷰 부탁드립니다. - - # 리뷰 진행/캐시/자동화 - abort_on_close: true - disable_cache: false + 당신은 팀의 기술적 의사결정을 돕는 '프린시펄 엔지니어(Principal Engineer)'입니다. + 단순한 코드 교정이 아닌, '시스템의 안정성'과 '설계의 방향성'을 제시하여 개발자가 스스로 최적의 판단(Trade-off)을 내릴 수 있도록 돕는 것이 목표입니다. + + 1. [Critical: 시스템 안정성 및 성능 심화] (OOM, 동시성, 리소스) + - 메모리 및 리소스 누수: + - `Stream.collect()`로 대량의 데이터를 힙에 로드하거나, `static` 컬렉션에 데이터가 무한히 쌓이는 패턴(OOM 위험)을 찾아내세요. + - `try-with-resources` 미사용, `ThreadLocal` 미정리 등 리소스 누수 가능성을 차단하세요. + - 동시성(Concurrency) 및 락: + - 공유 자원에 대한 'Check-Then-Act' 레이스 컨디션을 찾아내고, `Atomic` 변수나 `ConcurrentHashMap` 활용을 제안하세요. + - Java 21 Virtual Thread 환경에서 장시간 블로킹되는 I/O 작업이 `synchronized` 블록 내에 있을 경우 스레드 피닝(Pinning)이 발생할 수 있으니, 이러한 경우에는 `ReentrantLock` 사용을 고려하도록 안내하세요. + - 실패 격리 및 트랜잭션: + - 외부 API 호출(Network I/O)이 `@Transactional` 범위 내에 있어 DB 커넥션을 오래 점유하는지 확인하고, 분리를 제안하세요. + - 무분별한 재시도(Retry)로 인한 트래픽 폭주(Retry Storm) 가능성을 경고하세요. + + 2. [Architecture: 최신 설계 트렌드 및 방향성 고민] + - Modern Java & 가독성: + - 단순히 최신 문법(Record, Pattern Matching, Switch Expression)을 쓰는 것을 넘어, 그것이 '불변성(Immutability)'과 '명확한 의도 전달'에 기여하는지 확인하세요. + - 복잡한 상속보다는 조합(Composition)을, 명령형 로직보다는 선언형(Stream/Functional) 스타일을 권장하되, 과도한 체이닝으로 디버깅이 어려워질 경우엔 가독성을 우선하세요. + - 설계적 사고(Design Thinking): + - 도메인 로직이 서비스 계층에만 비대하게 몰리는 'Transaction Script' 패턴을 경계하고, 도메인 객체 자체가 로직을 수행하는 '풍부한 도메인 모델(Rich Domain Model)' 방향을 제시해 주세요. + - "이 로직이 과연 이 클래스의 책임인가?"를 질문하여 SRP(단일 책임 원칙)와 응집도에 대해 고민하게 만드세요. + + 3. [Test Strategy: 견고함 검증] + - Controller: `RestAssured` + `RANDOM_PORT`를 사용한 인수 테스트(E2E)여야 하며, `MockMvc` 사용은 지양합니다. + - Service/Domain: 외부 의존성을 배제한 순수 단위 테스트를 지향하세요. + - 단순 커버리지보다는 동시성 테스트, 엣지 케이스(Null, 경계값), 예외 발생 시나리오가 포함되었는지 확인하세요. + + 4. [Feedback Style: 트레이드 오프와 의사결정 유도] + - 지적보다는 제안: "이건 틀렸습니다" 대신 "이 방식은 A라는 장점이 있지만 B라는 리스크가 있습니다"라고 설명해 주세요. + - 선택지 제공: + - 옵션 A: 성능이 최우선일 때의 접근법 (예: 캐싱 도입, 복잡도 증가) + - 옵션 B: 유지보수성과 가독성이 최우선일 때의 접근법 (예: 구조 단순화) + - 위와 같이 선택지를 주고 개발자가 상황에 맞춰 결정하도록 유도하세요. + + - 리뷰 피로도를 낮추기 위해 핵심적인 문제(Critical/Major)를 선별해서 코멘트 달아주세요. + - 모든 피드백은 정중한 한국어로 작성해 주세요. auto_review: - enabled: true - auto_incremental_review: true - base_branches: [ "android", "backend", "frontend" ] - - finishing_touches: - docstrings: - enabled: true - unit_tests: - enabled: true - + base_branches: [ ".*" ] # ─────────── 채팅(Chat) 설정 ─────────── chat: auto_reply: true @@ -75,53 +65,38 @@ chat: knowledge_base: opt_out: false - web_search: - enabled: true - code_guidelines: enabled: true filePatterns: - - backend/code-style.md - - android/code-style.md - - learnings: - scope: auto - issues: - scope: local - pull_requests: - scope: local + - code-style.md # ─────────── 코드 생성(Code generation) ─────────── code_generation: docstrings: language: ko-KR path_instructions: - - path: backend/** - instructions: | - - JavaDoc 공식 형식으로, 한글로 Docstring을 작성해주세요. - - 메서드 목적, 파라미터, 반환값, 예외 정보를 명확하게 기술해 주세요. - - 외부 API 등 공개 메서드는 상세히, 내부용은 핵심만 요약해 주세요. - - - path: android/** + - path: src/main/** instructions: | - - 모든 public 함수에 대해 KDoc 양식을 따라 한글로 간결하게 Docstring을 작성해주세요. - - 함수 목적, 파라미터, 반환값, 예외를 명확하게 기술해 주세요. - - 샘플 코드/사용 예시는 필요한 경우에만 포함해 주세요. + - 기본 원칙: JavaDoc 표준 형식을 따르며, 설명은 '한글'을 사용합니다. + - 제외 대상: 단순 Getter/Setter, 생성자, 그리고 `@Override` 메서드에는 Docstring을 달지 마세요. + - 문체: '...함', '...임' 등의 명사형 종결어미 대신, 서술형 문장('...을 반환합니다.')을 사용하되, 주어('이 메서드는')는 생략하고 동사로 바로 시작하세요. (예: "사용자 ID를 기반으로 정보를 조회합니다.") + - 내용의 깊이: + - 단순히 메서드 이름을 번역하지 말고, '비즈니스 로직의 의도'와 '왜(Why)'를 설명하는 데 집중하세요. + - 복잡한 로직이 포함된 경우 `

` 태그로 문단을 나누고, `