[AI] gemini code assist 로 무료 코드 리뷰 받기

📌  Gemini code assist

📌 새로운 PR이 올라가면 코드를 리뷰해주는 AI 어시스턴트

• 새로운 PR이 올라가면 5분 이내에 summary, review 제공

📌 동작 맞춤설정

.gemini/config.yaml

: 무시할 파일을 지정하는 등 사용 설정하거나 사용 중지할 수 있는 다양한 구성 가능한 기능이 포함된 파일

have_fun: false # 재미/창의적 응답 비활성화
code_review:
  disable: false # 코드 리뷰 활성화
  comment_severity_threshold: MEDIUM # 이 수준 이상만 댓글 남김
  max_review_comments: -1 # -1이면 리뷰 댓글 개수 제한 없음
  pull_request_opened:
    help: false # PR 생성 시 도움말 자동 게시 안 함
    summary: true # PR 생성 시 요약 게시
    code_review: true # PR 생성 시 코드 리뷰 실행
    include_drafts: true # 드래프트 PR에도 적용
ignore_patterns: [] # 무시할 경로/패턴 (빈 값이면 없음)

.gemini/styleguide.md

코드 검토를 실행할 때 따라야 하는 특정 규칙을 Gemini Code Assist에 안내하는 마크다운 파일

# Gemini Code Assist Style Guide

## Language

Please provide all code reviews, summaries, and help messages in Korean (한글).

# Introduction
This style guide outlines the coding conventions for TypeScript code developed at Company X.
It's based on common TypeScript + ESLint/Prettier practices, with a few adjustments for our
organization.

All code changes must also follow the conventions defined in [CODE_CONVENTION_AGENT.md](CODE_CONVENTION_AGENT.md); treat that document as mandatory alongside this guide.

# Key Principles
* **Readability:** Code should be easy to understand for all team members.
* **Maintainability:** Code should be easy to modify and extend.
* **Consistency:** Adhering to a consistent style across all projects improves
  collaboration and reduces errors.
* **Performance:** While readability is paramount, code should be efficient.

## Line Length
* **Maximum line length:** 100 characters (align with Prettier default when possible).
    * Modern screens allow for wider lines, improving code readability in many cases.
    * If a line naturally exceeds 100 (e.g., long URLs), prefer breaking lines with clear continuations.

## Indentation
* **Use 2 spaces per indentation level.**

## Imports
* **Group imports:**
    * Node/DOM built-ins
    * Third-party packages
    * Internal aliases
    * Relative paths (`../`, `./`)
* **Use path aliases** where configured (e.g., `@/`), otherwise prefer relative paths that minimize `../`.
* **Import order within groups:** Alphabetical; keep type-only imports separated using `import type` when applicable.
* **Avoid default exports** unless a module has a single clear export; prefer named exports for clarity.

## Naming Conventions

* **Variables and functions:** camelCase: `userName`, `totalCount`, `calculateTotal()`
* **Constants:** UPPER_SNAKE_CASE: `MAX_VALUE`, `DEFAULT_TIMEOUT_MS`
* **Classes, types, interfaces, enums:** PascalCase: `UserManager`, `PaymentProcessor`, `User`, `UserRole`
* **React components:** PascalCase for component names and file names when a file exports a single component.
* **Files and modules:** kebab-case for general utilities (e.g., `user-utils.ts`), PascalCase for single-component React files.

## Documentation Comments
* **Use JSDoc (`/** ... */`) for exported functions, classes, and complex public APIs.**
* **First line:** Concise summary of the object's purpose.
* **Detail:** Add `@param`, `@returns`, and relevant tags (`@throws`, `@deprecated`) when helpful.
    ```ts
    /**
     * Formats a price with currency symbol.
     * @param amount Amount in minor units (e.g., cents)
     * @param currency ISO currency code
     */
    export function formatPrice(amount: number, currency: string): string {
      // ...
    }
    ```

## Types
* **Prefer explicit return types** for exported functions and components; allow inference for local helpers when clear.
* **Use `type` aliases for data shapes and union types**; use `interface` for public contracts that may be extended.
* **Favor `readonly` and `as const`** to express immutability where useful.
* **Avoid `any` and `unknown`** unless absolutely necessary; prefer precise types or generics.

## Comments
* **Explain the why, not the obvious what.**
* **Use JSDoc or block comments for non-trivial logic; keep inline comments short.**
* **Comment sparingly; favor readable code and clear naming.**

## Logging
* **Use structured logging or a shared logger utility** when available; avoid scattered `console.log`.
* **Log at appropriate levels:** debug, info, warn, error.
* **Provide context:** Include identifiers (userId, requestId) to aid debugging.

## Error Handling
* **Throw specific errors** with meaningful messages; avoid catching all errors unless rethrowing with context.
* **Narrow `try/catch` blocks** around code that can fail; handle recovery paths explicitly.
* **Propagate errors** with context (`new Error("Invalid state: ...")`) and avoid silent failures.

# Tooling
* **Code formatter:** Prettier (project defaults). Do not hand-format around Prettier.
* **Linter:** ESLint (project config). Fix lint errors; do not suppress without a clear reason.
* **Type checker:** `tsc --noEmit` for CI/local checks; keep the codebase type-clean.

📌 리뷰 방식

gemini-code-assist의 가장 좋았던 점은 피드백의 우선순위 뱃지를 함께 달아 어떤 점을 더 빨리 수정해야하는 지를 명확하게 알 수 있었다!

시험 삼아 테스트 해본 PR에는 많은 파일이 수정되지 않았지만 생각보다 세세하게 달아줘서 너무 좋았뜸 ㅎㅅㅎ

내 프로젝트에 조금 더 확실한 코드 컨벤션 같은 게 잡힌다면, 이를 제미나이에 적용해보고 싶다. 그렇게 하면 내가 원하는 코드 리뷰의 방향이 나올 수도 ?!

📌 참고

Gemini Code Assist - GitHub Marketplace

Bring the power of Gemini to the pull request process

github.com