CodeRabbitCodeRabbitKorea User Group
← 모범 사례 목록으로
Kotlin설정베스트프랙티스

CodeRabbit, 어떻게 하면 더 잘 활용할 수 있을까 (Kotlin)

CodeRabbit Korea User Group·

CodeRabbit, 어떻게 하면 더 잘 활용할 수 있을까

요즘 오픈소스 레포지터리들을 보면 CodeRabbit을 사용하는 경우가 많은데요, 오늘은 AI 코드리뷰 툴인 코드리뷰를 더욱 잘 활용할 수 있는 팁을 CodeRabbit 팀에서 작성한 공식 Configuration 베스트 프랙티스를 보면서 알아보고자 합니다.

이와 관련해 더 자세한 내용들을 알아보고 싶다면 CodeRabbit 유저 그룹 오픈 채팅방을 활용해보세요!

CodeRabbit을 조금 더 똑똑하게 활용하려면?

CodeRabbit은 그 자체만으로도 개발 생산성을 올릴 수 있는 아주 좋은 툴이지만, 팀 내에서 합의된 컨텍스트나 프레임워크에서 종속된 컨텍스트를 제공하지 않는 한 퀄리티가 좋은 리뷰를 제공받는다는 느낌을 받을 수 없을 것입니다.

Claude Code를 사용하면 이런 것들을 Skills를 통해 어느정도 해소를 할 수 있는데요, CodeRabbit에서도 역시 이런 것들을 Configuration 이라는 기능으로 원하는 컨텍스트를 주입할 수도, 팀의 환경에 맞게 툴의 설정을 변경할 수 있습니다.

제 본업이 안드로이드 개발자이기 때문에, 이번 아티클에서는 안드로이드, 특히 Kotlin 쪽의 설정을 보면서 어떻게 Configuration을 만들어가면 좋을지에 대해 알아보도록 합시다.

Kotlin Configuration 분석하기

해당 내용은 coderabbit/awesome-coderabbit 의 예제를 참고해서 작성하였습니다.

그러면 저와 같이 설정 파일을 분석해도록 합시다.

coderabbit.yaml

기본적으로 CodeRabbit의 설정 기능은 프로젝트의 .coderabbit.yaml 파일을 통해 설정을 할 수 있습니다. 다만 관리하는 프로젝트가 많은 회사의 경우에는 레포지터리 별 공통 설정을 하고 싶은 니즈가 생길 수 있는데요, 이 경우에는 오거니제이션 내에 coderabbit 레포지터리를 생성한 후, 해당 레포지터리 내에 coderabbit.yaml 파일을 생성하면 해당 설정이 오거니제이션 내 전체 레포지터리에 영향을 줄 수 있습니다. (이 기능을 Central Configuration이라 합니다)

Repository YAML
↓ merges with
Central YAML 
↓ merges with

프로젝트에 CodeRabbit 리뷰 설정을 하려면? 프로젝트 루트 디렉터리에 .coderabbit.yaml 파일을 생성

오거니제이션 전역에 리뷰 설정을 기본적으로 하고 싶다면?

  • 오거니제이션 내에 coderabbit 레포지터리 생성
  • 해당 레포지터리 내에 .coderabbit.yaml 파일에 설정

기본적인 옵션들

이제부터 본격적으로 설정을 분석해보려고 합니다. 해당 파일은 여기서 확인할 수 있습니다.

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

• language는 리뷰에 사용되는 언어입니다. 저희는 ko-KR(혹은 ko) 정도로 설정해보면 되겠죠? • early_access는 CodeRabbit의 새로운 기능(experimental feature)를 사용할 수 있는 기능입니다.

reviews:
  profile: chill
  high_level_summary: true
  collapse_walkthrough: true
  poem: false

• profile은 리뷰의 어투를 결정합니다. • chill은 약한 피드백 • assertive는 조금 더 독한 피드백(사소한 린트 이슈까지)을 원할 때 사용하시면 됩니다.

저는 개인적으로 chill만으로도 충분했습니다.

• high_level_summary는 PR description에 PR에 대한 설명을 기재가 필요한지에 대한 설정값입니다.

이런식으로 PR의 어떤 부분이 바뀌었는지, 문서나 테스트의 어떤 부분이 추가/수정되었는지를 직접 확인할 수 있습니다.

• collapse_walkthrough는 PR에 walkthrough 섹션을 토글 섹션으로 감싸서 볼 것인지에 대한 설정값인데요 (기본값은 true)

이런식으로 이번 PR의 요약/변경된 폴더, 파일들에 대한 설명을 적어주다보니 그 양이 상당합니다. 웬만하면 기본값 그대로 보시는 것을 추천드립니다.

• poem은 CodeRabbit만의 재밌는 기능으로, Walkthrough의 끝에 PR 전체 요약을 시 한편으로 설명을 하는 기능입니다. (전 이게 나름 재밌어서 따로 끄지는 않았습니다.)

리뷰 퀄리티에 필요한 옵션들

    # Files to review (use ! prefix to exclude)
    path_filters:
      • "**/*.kt"
      • "**/*.kts"
      • "!/build/"
      • "!/.gradle/"
      • "!/out/"
      • "!/generated/"
      • "!/node_modules/"
      • "!**/*.md"
      • "!**/*.txt"

• path_filters는 CodeRabbit이 리뷰를 해야하거나 하지 말아야할 파일 패턴을 위와 같이 표기할 수 있는 기능입니다. 파일명 앞에 "!"를 추가하는 경우 해당 경로의 파일들을 리뷰에서 제외하라는 것입니다. 빌드 파일이나 의존성 관련 파일들은 리뷰에서 제외해도 되겠죠?

auto_review:
  enabled: true
  auto_incremental_review: true
  drafts: false
  # Ignore dependabot PRs
  ignore_usernames:
    • dependabot
    • "dependabot[bot]"

• auto_review 는 CodeRabbit이 달아주는 리뷰의 속성 값입니다. • 만약 직접 @coderabbit 을 태그해서 리뷰를 하게 만들고 싶다면 enabled 를 false로 두시면 됩니다. • 푸시 이후 자동으로 리뷰를 달아주는 기능도 auto_incremental_review로 조절할 수 있습니다. • Draft PR의 경우 리뷰를 받고 싶지 않으시다면 drafts: false로 두시면 됩니다. (기본값이 false여서 만약 Draft여도 받고 싶다면 해당 속성을 true로 바꿔주세요) • 봇이 만든 PR의 경우 굳이 리뷰를 안달아도 되는 경우가 많은데요, 이 때 유저명을 기준으로 리뷰를 안달 수 있는 속성(ignore_usernames)이 있습니다. • 다른 속성을 추가로 더 보고 싶으시다면 레퍼런스 페이지를 참고해주세요

path_instructions:
  • path: "**/*.kt"

• 특정 경로/패턴의 파일에 대해서 컨텍스트를 알려주고 싶다면 path_instructions를 활용해보세요.

# "\*\*/\*.kt"
• path: "**/*.kt"
  instructions: 
  Kotlin best practices to check:
 
  Language correctness:
  • Null safety: Ensure proper use of nullable types, avoid unnecessary null assertions (!!)
  • Immutability: Prefer val over var, use immutable collections where possible
  • Data class usage: Use data classes for DTOs and value objects
  • Sealed class usage: Use sealed classes for representing restricted hierarchies
 
  Code quality:
  • Complexity: Flag functions with high cyclomatic complexity (>10)
  • Dead code: Identify unused functions, variables, and imports
  • Naming conventions: Follow Kotlin naming conventions (camelCase for functions/properties, PascalCase for classes)
 
  Coroutines and concurrency:
  • Structured concurrency: Ensure proper coroutine scope usage
  • Dispatcher misuse: Check for correct dispatcher usage (IO for blocking, Default for CPU-intensive)
 
  Performance:
  • Avoid unnecessary allocations in hot paths
  • Collection usage: Use appropriate collection types and operations (prefer sequences for large collections with multiple operations)
 
  API and design:
  • Visibility modifiers: Use appropriate visibility (prefer private/internal over public)
  • Unnecessary public API: Flag overly exposed APIs
 
  Error handling:
  • Proper exception handling, avoid swallowing exceptions
  • Result usage: Consider using Result type for operations that can fail
 
  Security:
  • No hardcoded secrets or credentials
  • Use SecureRandom instead of Random for security-sensitive operations
  • Avoid unsafe deserialization

이와 같이 공식 예제에서는 Kotlin으로 작성된 코드에 Best Practice를 나열해서 CodeRabbit AI 툴이 이를 참조할 수 있게 만들었는데요, 만약 팀에서 합의된 코딩 컨벤션이나 안드로이드/코틀린 컴포넌트가 아닌 사내에서 만든 컴포넌트를 사용해야한다면 이런 설정 파일에 기입해서 리뷰단계에서 안티 패턴들을 더욱 쉽게 걸러낼 수 있을 것입니다.

만약 Kotlin에 관련된 Best Practice들을 어떻게 정립해야할지 잘 모르겠다 싶으시면 아래와 같은 자료들을 활용해보는 것을 추천드립니다

tools:
  detekt:
    enabled: true
    # Uncomment if you have a custom detekt.yml in your repo
    # config_file: "detekt.yml"
  # Security scanning
  gitleaks:
    enabled: true

• CodeRabbit에는 프로젝트 내에 설정되어 있는 Lint 파일을 기반으로 린트 리뷰도 수행할 수 있습니다. Kotlin의 경우 detekt만 존재하니, 만약 detekt를 사용하시는 분들께서 CI에 따로 lint task를 돌리지 않으신다면 이런 설정을 활용해서 린트를 잡아볼 수도 있을 것 같아요. • 최근에 오픈소스 보안이슈가 많이 터지고 있는데요, Gitleaks나 TruffleHog와 같은 Secret 스캐닝 툴을 활용해서 푸시된 코드에 키가 있는지 확인을 해볼 수 있습니다. 이외에도 ast-grep, OpenGrep과 같이 코드 단위에서의 보안요소도 챙겨볼 수 있고, OSV-Scanner와 연동해서 의존성 패키지에 보안 위협이 있는지도 확인해볼 수 있습니다.

마치며

이외에도 CodeRabbit의 커스텀 설정을 위한 다양한 요소들이 있습니다. 이는 공식 문서와 예제에서 더 확인해볼 수 있습니다.

이 부분에 대해서 더 궁금한 것들이 있거나, AI를 활용한 개발 방법론에 관심을 가지고 계신다면 CodeRabbit 유저 그룹 오픈채팅방에서 더 많은 이야기들을 나눌 수 있습니다.