- 공유 링크 만들기
- X
- 이메일
- 기타 앱
요즘 제가 AI 바이브 코딩을 꽤 자주 하고 있거든요. 처음에는 Copilot이나 ChatGPT로 코드 짜는 재미에 빠졌다가, 어느 순간 이런 생각이 들더라고요. “아니, 코드는 AI랑 같이 짜는데 리뷰는 왜 아직도 내가 다 붙잡고 있지?” 사실 20년 넘게 개발하면서 코드 리뷰를 안 해본 것도 아니고, 중요하다는 것도 너무 잘 아는데요. 바쁠 때는 사람이 참 간사합니다. 꼼꼼하게 봐야지 하면서도, 야근 냄새가 슬슬 올라오면 눈이 대충 훑고 지나가요. 그래서 CodeRabbit을 한번 붙여봤습니다. 처음엔 가볍게 시작했는데, 쓰다 보니 이게 단순한 PR 자동 리뷰 툴이 아니라 “AI한테 일을 어떻게 맡길 것인가”의 문제더라고요.
오늘은 제가 CodeRabbit을 쓰면서 겪었던 삽질이랑, 토큰 아끼는 방법, 프롬프트를 덜 시끄럽게 만드는 법, 그리고 팀 프로젝트에 세팅해두면 은근히 오래 가는 설정들을 편하게 풀어보려고 해요. 뭐랄까, 여행 가기 전에 숙소 위치랑 동선 잡아두면 현장에서 덜 헤매는 것처럼, AI 코드 리뷰도 초반 세팅을 잘해두면 마음이 좀 편해집니다.
CodeRabbit을 붙인 이유는 단순했어요. 내가 놓치는 걸 줄이고 싶었거든요
사실 코드 리뷰라는 게 늘 멋있게만 흘러가진 않잖아요. PR 열리고, 변경 파일 20개쯤 있고, 중간에 회의 들어갔다 오면 흐름 끊기고요. “아까 어디까지 봤더라?” 하다가 중요한 로직 하나를 놓치는 일이 생깁니다. 저도 그랬어요. 특히 API 쪽에서 예외 처리 하나 빠뜨린 걸 못 보고 머지했다가, 운영에서 특정 케이스만 500 에러가 나는 바람에 식은땀 좀 흘린 적이 있었습니다.
그때 로그가 대충 이런 식이었어요.
TypeError: Cannot read properties of undefined (reading 'id')
at createOrder (/src/orders/service.js:84:27)
at processTicksAndRejections (node:internal/process/task_queues:95:5)
코드로 보면 별거 아니었어요. 외부 API 응답에서 user 객체가 항상 온다고 생각하고 그냥 user.id를 찍은 거죠. 리뷰할 때 봤으면 바로 잡았을 텐데, 그날은 PR이 여러 개 밀려 있었고 저는 이미 머리가 좀 흐릿했습니다. 그 뒤로 “리뷰의 첫 번째 필터 정도는 AI한테 맡겨도 되지 않을까?”라는 생각을 하게 됐어요.
그래서 GitHub 저장소에 CodeRabbit을 연결했습니다. 처음 붙였을 때 느낌은 꽤 신기했어요. PR 올리면 알아서 diff를 읽고 코멘트를 달아주니까요. 그런데 문제도 바로 보였습니다. 코멘트가 너무 많았어요. 진짜 많았습니다.
예를 들면 단순히 변수명을 data에서 responseData로 바꿨을 뿐인데, “좀 더 명확한 이름을 사용하는 것이 좋습니다” 같은 이야기를 길게 해주더라고요. 틀린 말은 아닌데, 그걸 굳이 지금 PR에서 들어야 하나 싶은 거죠. 사람 리뷰어도 그런 식으로 계속 말하면 팀 분위기 묘해지잖아요. AI도 똑같습니다. 똑똑한데, 눈치가 없으면 피곤해요.
토큰은 생각보다 빨리 녹아요. 그래서 리뷰 범위를 줄이는 게 먼저였습니다
CodeRabbit 같은 AI 리뷰 도구를 쓸 때 제일 먼저 봐야 하는 건 “무엇을 리뷰하게 할 것인가”예요. 사람한테도 리뷰 부탁할 때 “전체 다 봐줘”라고 하면 힘들잖아요. AI도 마찬가지입니다. 전체 저장소를 다 훑게 만들면 토큰도 많이 쓰고, 코멘트도 산으로 갑니다.
제가 처음에는 별생각 없이 전체 파일을 보게 뒀어요. 그랬더니 README.md, package-lock.json, yarn.lock, 자동 생성 파일까지 다 건드리더라고요. 특히 lock 파일은 diff가 어마어마하게 큰데, 리뷰해서 얻을 게 거의 없습니다. 그냥 토큰 먹는 하마예요.
그래서 .coderabbit.yaml에서 리뷰 대상과 제외 대상을 나눠봤습니다. 저는 보통 실제 서비스 로직이 있는 src/ 중심으로 보고, 문서나 lock 파일은 제외하는 쪽을 선호해요.
reviews: path_filters:
- "src/**"
- "!**/*.md"
- "!package-lock.json"
- "!yarn.lock"
- "!dist/**"
- "!coverage/**"
여기서 테스트 코드를 어떻게 할지는 조금 고민했어요. 처음엔 tests/**도 제외했는데, 막상 써보니까 테스트 코드 리뷰가 필요한 순간이 있더라고요. 예를 들어 결제나 권한 쪽 테스트는 오히려 AI가 놓친 케이스를 잘 짚어줄 때가 있어요. 그래서 저는 테스트 전체를 무조건 제외하기보다는, 프로젝트 성격에 따라 다르게 둡니다.
| 항목 | 처음 설정했을 때 | 지금 주로 쓰는 방식 |
|---|---|---|
| 리뷰 대상 | 저장소 전체 | src/** 중심, 자동 생성 파일 제외 |
| 문서 파일 | README, md 파일까지 리뷰 | 기본 제외, 문서 PR일 때만 별도 확인 |
| lock 파일 | 변경량 그대로 분석 | package-lock.json, yarn.lock 제외 |
| 테스트 코드 | 전체 리뷰 또는 전체 제외 | 도메인 중요도에 따라 선택 |
이렇게 바꾸고 나니까 체감상 리뷰 코멘트가 확 줄었습니다. 토큰 사용량도 같이 내려갔고요. 정확히 말하면 PR마다 다르긴 한데, 큰 PR 기준으로는 대략 30~40% 정도 덜 쓰는 느낌이었습니다. 숫자 하나하나를 칼같이 재진 않았지만, 월말에 사용량 그래프 보면 확실히 차이가 나요.
제가 특히 중요하게 보는 기준은 이겁니다. AI에게 “많이 봐줘”라고 부탁하지 말고, “여기만 제대로 봐줘”라고 말해야 한다는 거예요. 이건 ChatGPT에 질문할 때도 똑같고, CodeRabbit에 리뷰를 맡길 때도 똑같습니다. 범위가 넓으면 답이 흐려지고, 범위가 좁으면 꽤 날카로워져요.
프롬프트는 친절하게, 대신 단호하게 써야 하더라고요
CodeRabbit 기본 리뷰도 나쁘진 않습니다. 그런데 제 취향에는 조금 말이 많았어요. 저는 코드 리뷰에서 스타일 취향 싸움을 별로 좋아하지 않거든요. 물론 팀 컨벤션은 중요하죠. 그런데 포맷팅은 ESLint, Prettier, ktlint 같은 도구가 잡으면 됩니다. AI 리뷰어까지 와서 “이 변수명은 조금 더 명확하면 좋겠습니다”를 매번 말하면, 개발자들이 금방 피곤해져요.
그래서 저는 프롬프트를 꽤 단호하게 바꿨습니다. 핵심은 이거였어요.
- 로직 오류를 우선해서 봐달라고 하기
- 성능 문제와 보안 취약점을 놓치지 말라고 하기
- 스타일, 취향, 단순 네이밍은 말하지 말라고 하기
- 심각한 문제가 없으면 길게 쓰지 말고 짧게 끝내라고 하기
제가 써본 프롬프트는 이런 식입니다.
prompts:
review: |
당신은 실무 경험이 많은 senior developer입니다.
이 PR에서는 로직 오류, 성능 문제, 보안 취약점만 집중해서 리뷰하세요.
코드 스타일, 변수명 취향, 주석 부족은 언급하지 마세요.
중요한 문제가 없다면 "LGTM"으로 짧게 답하세요.
코멘트는 짧고 구체적으로 작성하세요.
이걸 넣고 나서 꽤 달라졌습니다. 예전에는 사소한 제안이 여럿 달렸다면, 이제는 진짜 봐야 할 지점 위주로 코멘트가 붙었어요. 저는 이 변화가 마음에 들었습니다. 코드 리뷰는 많다고 좋은 게 아니거든요. 좋은 리뷰는 적당히 조용하다가, 중요한 순간에 정확히 찌르는 쪽에 가깝습니다.
한번은 users/controller.js에서 사용자 검색 조건을 조립하는 코드가 있었어요. 기존에는 대충 이런 식이었습니다.
const query = `SELECT * FROM users WHERE email = '${email}'`;
const user = await db.query(query);
사람이 보면 바로 찝찝하죠. 그런데 프롬프트가 애매할 때는 CodeRabbit이 이걸 강하게 잡지 못하고 지나간 적이 있었습니다. 그래서 프롬프트에 이 문장을 추가했어요.
SQL query가 보이면 parameterized query 사용 여부를 반드시 확인하세요. 사용자 입력값이 문자열로 직접 연결되면 보안 문제로 지적하세요.
그다음 비슷한 PR에서 바로 잡아내더라고요. “사용자 입력값이 SQL 문자열에 직접 들어가고 있어 SQL Injection 위험이 있습니다”라고요. 그때 좀 웃겼습니다. 사람한테 일을 알려주는 느낌이랑 비슷했어요. 한 번 제대로 말해두면 그다음부터는 훨씬 덜 답답해집니다.
AI 리뷰를 잘 쓰려면, 프로젝트마다 성격을 나눠줘야 합니다
이 부분은 제가 꽤 강하게 믿는 쪽인데요. 모든 프로젝트에 같은 프롬프트를 쓰면 효율이 떨어집니다. 백오피스 관리자 화면이랑 결제 API가 같은 강도의 리뷰를 받을 필요는 없거든요. 물론 둘 다 중요하지만, 위험의 종류가 다릅니다.
예를 들어 프론트엔드 쪽에서는 불필요한 렌더링, 상태 관리 꼬임, 접근성 같은 걸 더 봐야 할 때가 있고요. 백엔드 API에서는 트랜잭션, 권한 체크, 입력값 검증, N+1 쿼리 같은 게 더 중요합니다. 배치 프로그램은 또 달라요. 장애가 나도 바로 티가 안 나는 대신, 데이터가 조용히 틀어질 수 있거든요. 저는 그게 더 무섭습니다.
| 영역 | AI 리뷰에 강조한 내용 | 제가 실제로 도움 받은 부분 |
|---|---|---|
| 프론트엔드 | 불필요한 렌더링, 상태 변경 위치, null 처리 | useEffect 의존성 누락을 발견 |
| 백엔드 API | 권한 체크, 입력값 검증, transaction 처리 | 관리자 권한 검증 누락을 리뷰에서 확인 |
| DB 쿼리 | SQL Injection, N+1, index 사용 가능성 | 문자열 조합 쿼리를 parameterized query로 수정 |
| 배치 작업 | 재시도, 중복 실행, 부분 실패 처리 | 재실행 시 데이터 중복 생성 가능성을 발견 |
이렇게 나눠두면 리뷰가 훨씬 현실적입니다. 사실 실무에서 제일 피곤한 리뷰는 “맞는 말인데 지금은 별로 안 중요한 말”이거든요. AI도 그걸 줄여야 합니다. 잘 쓰는 AI 도구는 말을 많이 하는 도구가 아니라, 지금 내 상황에서 필요한 말을 해주는 도구라고 봐요.
초안 PR에는 굳이 리뷰를 돌리지 않았습니다
처음 CodeRabbit을 붙였을 때 제일 귀찮았던 게 알림이었어요. PR을 Draft로 열어두고 작업 중인데, AI가 벌써 와서 이것저것 말을 하기 시작합니다. 아직 내가 정리도 안 한 코드인데 말이죠. 이건 마치 이사 중인 집에 손님이 와서 “여기 인테리어는 조금 아쉽네요” 하는 느낌입니다. 아니, 아직 짐도 안 풀었는데요.
그래서 Draft PR에서는 리뷰가 돌지 않게 했습니다. 팀원들도 이걸 좋아하더라고요. 작업 중인 코드는 편하게 올려두고, 리뷰 받을 준비가 됐을 때만 AI가 붙도록 하는 게 훨씬 자연스러웠습니다.
reviews:
auto_review:
drafts: false
이 설정 하나만으로도 불필요한 코멘트와 알림이 꽤 줄었어요. 그리고 심리적으로도 좋습니다. 개발자는 아직 덜 익은 코드를 올려둘 자유가 필요하거든요. AI가 너무 빨리 참견하면, 이상하게 작업 리듬이 깨집니다.
팀에 공유하기 좋았던 체크리스트
저는 이런 설정을 혼자만 쓰는 것보다 팀에 공유하는 게 더 낫다고 봅니다. 특히 주니어 개발자들이 있는 팀에서는 효과가 꽤 있어요. AI 리뷰가 너무 많이 달리면 주니어들은 그걸 다 고쳐야 하는 줄 알고 지칩니다. 반대로 너무 느슨하면 중요한 걸 놓치고요. 그래서 팀 위키에 아래 정도는 정리해뒀습니다.
- 자동 생성 파일은 리뷰에서 제외하기:
dist/**,coverage/**,package-lock.json,yarn.lock은 기본 제외로 뒀습니다. - 스타일 리뷰는 최소화하기: 포맷팅과 네이밍 취향은 사람이 싸우기 시작하면 끝이 없어서, 가능한 lint 도구에 맡겼습니다.
- 보안과 장애 가능성은 강하게 보기: 인증, 권한, SQL, 외부 API 연동, 결제 쪽은 AI 리뷰 강도를 높였습니다.
- Draft PR은 리뷰하지 않기: 개발 중인 코드는 개발자에게 여백을 주는 게 좋았습니다.
- 큰 PR은 작게 쪼개기: AI 리뷰 품질도 올라가고, 사람 리뷰어도 덜 지칩니다. 이건 진짜 오래된 진리예요.
특히 큰 PR 쪼개기는 AI 시대에도 여전히 중요합니다. 아니, 오히려 더 중요해진 것 같아요. 변경량이 너무 많으면 AI도 맥락을 잡다가 헷갈립니다. 사람도 그렇고요. 저는 가능하면 PR 하나에 목적 하나만 담으려고 합니다. 기능 추가면 기능 추가, 리팩토링이면 리팩토링. 섞이면 리뷰가 탁해져요.
토큰을 아낀다는 건, 결국 집중력을 아낀다는 말이기도 해요
처음에는 저도 토큰을 그냥 비용 문제로만 봤습니다. “아, 이거 많이 쓰면 돈 나가겠네” 정도였죠. 그런데 계속 써보니까 토큰 절약은 단순히 비용만의 문제가 아니더라고요. AI가 읽는 범위를 줄이면 답변이 짧아지고, 답변이 짧아지면 사람이 읽는 시간도 줄어듭니다. 그러면 리뷰 피로도가 내려가요.
이게 꽤 큽니다. 개발팀에서 피로도는 생산성이랑 바로 연결되거든요. 리뷰 코멘트가 30개 달린 PR과, 진짜 중요한 코멘트 3개만 달린 PR은 받아들이는 느낌이 완전히 다릅니다. 후자는 “오, 이건 봐야겠다”가 되는데, 전자는 “아…”부터 나와요. 솔직히 그렇잖아요.
제가 느낀 좋은 AI 리뷰의 기준은 이 정도입니다.
- 사소한 취향보다 실제 장애 가능성을 먼저 본다.
- 코멘트가 짧아도 이유가 분명하다.
- 수정 방향을 너무 장황하게 늘어놓지 않는다.
- 문제가 없을 때는 조용히 지나갈 줄 안다.
- 팀의 코드 스타일을 억지로 바꾸려 하지 않는다.
저는 특히 “문제가 없을 때 조용한 AI”가 좋습니다. 사람도 그렇잖아요. 같이 여행 가도 모든 순간에 훈수 두는 친구보다, 진짜 필요할 때 “여긴 돌아가는 게 낫겠다” 하고 말해주는 친구가 편합니다. 코드 리뷰 AI도 비슷합니다.
제가 지금 쓰는 CodeRabbit 운영 방식
지금은 CodeRabbit을 완전한 리뷰어로 보진 않습니다. 대신 사전 점검자 정도로 봐요. PR이 올라오면 CodeRabbit이 먼저 위험한 부분을 훑고, 그다음 사람이 도메인 맥락을 봅니다. 이 조합이 제일 괜찮았습니다.
예를 들어 AI는 이런 걸 잘 봅니다.
- null 또는 undefined 가능성
- 예외 처리 누락
- SQL Injection 같은 전형적인 보안 문제
- 비동기 처리 순서 문제
- 중복 코드나 불필요한 반복
반대로 사람은 이런 걸 봐야 합니다.
- 이 기능이 비즈니스 정책에 맞는지
- 이 예외 케이스가 실제 운영에서 중요한지
- 지금 구조 변경이 팀의 장기 방향과 맞는지
- 이 PR이 배포 일정에 어떤 영향을 주는지
- 기획 의도와 사용자 경험이 어긋나지 않는지
AI가 아무리 좋아져도 도메인 맥락은 아직 사람이 더 잘 봅니다. 특히 오래된 서비스일수록 코드에 역사와 사연이 묻어 있어요. “왜 이렇게 이상하게 짰지?” 싶은 코드가 알고 보면 5년 전 특정 고객사 요구사항 때문에 남아 있는 경우도 많습니다. AI는 그런 걸 모릅니다. 그래서 저는 AI 리뷰를 믿되, 최종 판단은 사람이 해야 한다고 봐요. 이건 꽤 단호한 제 생각입니다.
이런 분들에게는 CodeRabbit 세팅을 꼭 권하고 싶어요
CodeRabbit을 그냥 설치만 해두면 처음엔 신기하지만, 금방 피곤해질 수 있습니다. 코멘트가 많고, 토큰도 많이 쓰고, 팀원들이 “이거 꼭 다 봐야 해요?”라고 묻기 시작하거든요. 그런데 리뷰 범위를 좁히고, 프롬프트를 프로젝트에 맞게 다듬고, Draft PR을 제외하는 정도만 해도 꽤 쓸 만한 동료가 됩니다.
혼자 여러 프로젝트를 보는 시니어 개발자, PR이 자주 쌓이는 개발 팀 리더, 주니어 개발자 코드 리뷰를 꾸준히 해야 하는 분들에게 특히 잘 맞을 것 같아요. 저처럼 “리뷰는 해야 하는데 시간이 늘 부족한 사람”에게도요. 다만 처음부터 완벽한 답을 기대하면 실망할 수 있습니다. AI 리뷰는 세팅하고, 지켜보고, 조금씩 길들이는 쪽에 가깝습니다.
저는 요즘 AI 도구를 볼 때마다 그런 생각을 합니다. 좋은 도구는 개발자를 대체하는 게 아니라, 개발자가 덜 지치게 도와줘야 한다고요. CodeRabbit도 제게는 그런 쪽입니다. 모든 리뷰를 대신해주는 마법사는 아니지만, 제가 놓칠 뻔한 부분을 한 번 더 비춰주는 작은 손전등 같은 느낌이에요. 밤길에 손전등 하나 있으면 마음이 좀 놓이잖아요. 딱 그 정도의 든든함입니다.
AI 바이브 코딩을 하고 있다면, 코드 작성만 AI와 함께하지 말고 리뷰 루틴도 한번 손봐보세요. 토큰을 아끼는 설정, 조용하고 날카로운 프롬프트, 필요 없는 파일 제외. 이 세 가지만 해도 생각보다 개발 흐름이 많이 부드러워집니다.
댓글
댓글 쓰기