CodeRabbit 도입 후 다음에 해야 할 일 — autoFixable 패턴으로 기계적 수정을 자동화하기

CodeRabbit을 도입하면 PR(Pull Request)에 자동으로 리뷰 코멘트가 달립니다. "사용하지 않는 import가 있습니다", "여기는 const 권장입니다", "nullable 타입에 명시가 필요합니다". 편리한 것은 틀림없지만, 3개월간 사용한 저희 팀의 감상은 의외였습니다.

"코멘트를 읽는 시간이 늘어났다"

리뷰어(Reviewer)는 내용을 확인하고, 리뷰이(Reviewee)는 수정하며, CodeRabbit에 "확인"이라고 답합니다. 이 왕복 과정이 이전보다 늘어났습니다. 이유는 단순합니다. 기계적으로 고칠 수 있는 지적까지 AI가 코멘트를 남기기 때문입니다.

여기서 효과적인 것이 harness-code-review Book ch12에서 작성한 "autoFixable 패턴"이라는 사고방식입니다. CodeRabbit의 지적 중 "기계가 고칠 수 있는 것"은 리뷰어를 거치지 않고 GitHub Actions에서 먼저 고칩니다. 남은 것들만 인간이 리뷰합니다. 도입 3주 만에 저희 팀의 PR 리뷰 시간은 40% 감소했습니다.

가장 먼저 해야 할 분류 작업입니다. CodeRabbit / Claude Code Review / Cursor BugBot이 내놓는 지적은 대략 다음 두 가지로 나뉩니다.

종류	도구	예시
autoFixable (기계적으로 고칠 수 있음)	Prettier / Biome / ESLint --fix / Ruff --fix	포맷팅 / import 순서 / 끝 세미콜론
non-autoFixable (인간의 판단이 필요함)	인간 리뷰어	설계 방침 / 명명(Naming) / N+1 문제 / 로직 버그

autoFixable은 "정답이 일의적으로 결정된다"는 것이 특징입니다. 포맷팅은 설정 파일대로 고치면 되고, import는 순서 규칙이 정해져 있다면 자동으로 정렬할 수 있습니다. 반면, 명명이나 설계는 문맥에 의존하므로 기계가 "올바른 답"을 하나로 좁힐 수 없습니다.

저희 팀의 체감으로는 CodeRabbit 지적의 6~7할이 autoFixable이었습니다. 이를 자동화하면 인간이 보는 것은 남은 3할뿐입니다. 리뷰의 밀도가 단번에 높아집니다.

최소 구성의 workflow(워크플로우)는 다음과 같습니다.

# .github/workflows/auto-fix.yml
name: Auto Fix
on: 
...

PR이 open 또는 synchronize될 때마다 Prettier와 ESLint를 실행하여, 차분이 있으면 자동으로 commit & push합니다. PR 소유자는 아무것도 하지 않아도 포맷팅의 불일치가 사라집니다.

포인트는 permissions: contents: write입니다. secrets.GITHUB_TOKEN으로 다시 commit하기 위해 필요한 권한이며, 이를 잊어버리면 workflow가 silently(조용히) commit에 실패합니다.

secrets.GITHUB_TOKEN으로 push한 commit은 GitHub Actions를 재트리거(re-trigger)하지 않는 사양입니다. auto-fix commit 후 추가적인 workflow(테스트 등)를 실행하고 싶다면, personal access token (PAT) 또는 GitHub App token으로 push해야 합니다. 이를 모르면 "auto-fix 후에 CI가 돌아가지 않는" 현상에 당황하게 됩니다.

ESLint와 Prettier를 별도로 실행하면 설정 충돌과 기동 오버헤드(Overhead)가 은근히 영향을 미칩니다. 저희 팀은 2025년부터 Biome으로 통합했습니다.

{
"$schema": "https://biomejs.dev/schemas/1.9.0/schema.json",
"formatter": {
...

CI에서의 auto-fix는 biome check --apply . 한 줄로 끝납니다.

- name: Biome auto-fix
run: npx @biomejs/biome check --apply .

저희 팀의 측정 결과, Prettier + ESLint 조합으로 12초 걸리던 CI 시간이 Biome을 사용하니 2.8초가 되었습니다. auto-fix의 비용 부담이 작기 때문에 매 PR마다 실행해도 부담이 없습니다.

Node.js뿐만 아니라 다른 언어에도 동일한 패턴이 적용됩니다.

- name: Python auto-fix (Ruff)
run: ruff check --fix . && ruff format .
- name: Go auto-fix
...

Ruff는 2026년 5월 시점에서 Python lint/format 업계의 디폴트에 가까워졌습니다 (Pandas, FastAPI, Polars 등의 주요 프로젝트가 채택). Black + isort + Flake8 조합에서 이행하면, CI 시간이 체감상 5~10배 빨라집니다.

CodeRabbit 자체도 AI가 생성한 autoFix 제안을 PR 코멘트에 포함하는 기능이 있습니다 (2026년 5월 기준, Pro Plan · 공개 베타).

CodeRabbit의 리뷰 코멘트 안에 「Apply suggestion」 버튼이 나타나며, 클릭 한 번으로 제안이 commit됩니다. ESLint나 Ruff로 다 고칠 수 없는 로직 중심의 lint 지적 (예: 처리되지 않은 Promise, nullable 체크 누락)도 AI가 수정안을 제시해 줍니다.

저희 팀은 "기계적인 autoFix는 GitHub Actions로 전자동화, AI 생성 autoFix 후보는 CodeRabbit을 통해 사람이 승인하는 방식"이라는 이중 구조를 채택하고 있습니다.

PR open
↓
GitHub Actions auto-fix (Prettier/ESLint/Ruff) → 자동 commit
...

자동화 영역과 AI 지원 영역을 나누면 책임 소재가 명확해집니다. 포맷팅 오류는 bot의 책임, 로직 수정은 최종적으로 사람의 책임입니다. 이것이 팀에서 원활하게 운영되는 비결이었습니다.

auto-fix workflow를 도입하기 전과 후로, 저희 팀의 수치가 어떻게 변했는지 기록해 둡니다. 약 30명 규모의 프론트엔드/백엔드 혼성 팀에서의 3개월간의 변화입니다.

지표	도입 전	도입 후	변화
PR 평균 리뷰 시간	47분	28분	-40%
...

사람이 리뷰하는 "로직 중심의 코멘트"만 남게 되므로, 리뷰의 밀도가 높아지고 논의의 질도 향상되었습니다. "import 순서가 어떻다" 식의 불필요한 대화가 사라지는 것만으로도 인지 비용 (Cognitive Cost)이 상당히 낮아집니다.

특히 부수적인 효과로, "신입 사원의 심리적 안전감 (Psychological Safety)"이 높아졌다는 의견이 팀 내에서 많이 나왔습니다. 포맷팅 관련 지적은 신입에게 은근히 스트레스가 되는데, 이를 기계에 맡기게 되면서 설계 논의에 집중할 수 있게 되었다는 목소리였습니다. 리뷰어로부터 "세미콜론 넣어라"라는 말을 계속 듣는 것만큼 괴로운 일은 없습니다. 기계가 고친다면 아무도 상처받지 않으며, 이는 예상보다 훨씬 큰 효과였습니다.

"pre-commit hook으로 돌리면 CI에서 실행할 필요가 없지 않나요?"라는 질문을 자주 받습니다. 저의 대답은 "둘 다 하는 것이 안전하다"입니다.

pre-commit: 로컬에서 조기에 수정하여 CI를 깨끗하게 유지
CI (auto-fix workflow): pre-commit을 우회(bypass)했을 경우를 대비한 최후의 보루

pre-commit은 git commit --no-verify로 간단히 건너뛸 수 있습니다. 팀원 모두가 hook을 설치했을 것이라고 확신할 수도 없습니다. **"절대 놓치고 싶지 않은 지적은 CI에서 고친다"**는 전략이 벨트와 서스펜더(Belt and Suspenders) 같은 보험이 됩니다.

Lefthook이나 husky로 hook을 관리하는 팀은, lefthook install을 npm install의 postInstall 단계에 포함시켜 신규 멤버가 자동으로 hook을 활성화하는 구조를 만들어 두는 것이 좋습니다.

실제로 운영하며 발견한, 빠지기 쉬운 함정 3가지입니다.

actions/checkout@v4의 기본 설정에서는 PR이 detached HEAD 상태로 checkout됩니다. 이 상태에서 push를 시도하면 실패합니다. 대책은 workflow에서 ref: ${{ github.head_ref }}를 명시하는 것입니다. 샘플 workflow에 이 설정을 넣은 이유가 바로 이것입니다.

OSS 리포지토리에서 외부 fork로부터 오는 PR에 대해, secrets.GITHUB_TOKEN은 read-only가 되는 사양입니다. 따라서 auto-fix workflow는 fork PR에서 push에 실패합니다. 대책은 pull_request_target을...

「event를 사용한다」 또는 「fork PR은 auto-fix 대상에서 제외한다」라고 운영 방침을 정하는 것입니다. 전자는 보안 리스크가 높아지기 때문에, 저는 후자를 선택하고 있습니다.

auto-fix 커밋과 개발자의 로컬 커밋이 충돌하여, package-lock.json의 merge conflict (병합 충돌)가 빈번하게 발생하는 팀이 있었습니다. merge-strategies (병합 전략)를 .gitattributes에서 package-lock.json merge=theirs로 설정하거나, auto-fix는 lock file을 건드리지 않는 방침으로 정해두는 것이 편합니다.

CodeRabbit 도입의 다음 단계는 autoFixable 패턴의 자동화였습니다.

autoFixable과 non-autoFixable 분류: 정답이 일의적인 것은 bot (봇)에게, 문맥 의존적인 것은 인간에게 -
GitHub Actions를 통한 auto-fix workflow (자동 수정 워크플로우): Prettier / ESLint / Biome / Ruff를 --fix로 실행 -
2단계 운영 체계: 기계적 수정은 Automation (자동화), AI 생성 제안은 CodeRabbit, 최종 판단은 인간

이것을 도입한 것만으로 저희 팀의 PR 리뷰 시간은 40% 감소했습니다. 인간만이 할 수 있는 리뷰에 시간을 쓰기 위해, 첫 발판을 다지는 메커니즘입니다. CodeRabbit의 월 구독료가 높게 느껴지는 분들은, 우선 autoFixable의 자동화만이라도 도입해 본다면 효과를 볼 수 있을 것입니다.