본문으로 건너뛰기

© 2026 Molayo

Qiita헤드라인2026. 05. 20. 18:12

커밋 전에 AI가 코드를 검토해 준다 — IntelliJ IDEA의 Self-Review with AI를 사용해 보았다

요약

IntelliJ IDEA 2026.1 Ultimate 버전에서 제공하는 'Perform Self-Review with AI' 기능을 직접 사용해 본 후기입니다. 이 기능은 커밋 전 변경 사항(diff)을 AI가 자동으로 검토하여 코드 품질을 높여주며, 특히 Markdown 파일을 통해 팀의 고유한 리뷰 가이드라인을 적용할 수 있는 점이 강력한 장점입니다.

핵심 포인트

  • 커밋 전 또는 이미 푸시된 커밋에 대해 AI가 자동으로 코드 리뷰를 수행할 수 있음
  • Markdown 파일을 활용하여 팀의 코딩 컨벤션 및 리뷰 가이드라인을 AI에 학습시킬 수 있음
  • 가이드라인 적용 시, 일반적인 베스트 프랙티스뿐만 아니라 특정 규칙 위반 사항을 명시적으로 지적함
  • JetBrains AI 구독 또는 Anthropic, OpenAI API 키를 통한 BYOK 방식을 지원함

「이 커밋, 괜찮을까?」라며 git push 버튼을 누르기 직전에 불안해질 때가 있습니다.

리뷰어로부터 「또 이 패턴인가」라는 지적을 받는 경우. 매번 리뷰어의 시간을 뺏는 것도 미안합니다. 그렇다고 스스로 코드를 다시 읽어보는 「셀프 리뷰 (Self-Review)」를 커밋 전에 매번 하기에는 상당한 집중력과 시간이 필요합니다.

그래서 이번에는 IntelliJ IDEA의 Perform Self-Review with AI 기능을 사용해 보았습니다. AI가 커밋 전의 차이점(diff)을 자동으로 리뷰해 주는 기능입니다.

이 기사는 실제로 사용해 보니 어땠는지, 어떤 문제를 검출해 주었는지에 대해 작성한 것입니다.

제품: IntelliJ IDEA 2026.1 (Ultimate) -
기능: Perform Self-Review with AI (AI를 통한 셀프 리뷰) -
전제: JetBrains AI 구독 또는 BYOK (Anthropic / OpenAI API 키)가 활성화되어 있을 것

Alt+0을 눌러 Commit 툴 윈도우 (Commit tool window)를 연다. 여기는 평소에 사용하는 커밋 화면과 동일하다.

스테이징(Staging)하고 싶은 파일에 체크를 한 상태에서, 「Self-Review with AI」 버튼을 클릭한다.

Problems 툴 윈도우 (Problems tool window)가 자동으로 열리며, AI Self-Review 탭에 검출된 문제 목록이 표시된다.

검출된 문제를 확인 및 수정한 후, 평소와 같이 커밋한다.

미커밋 변경 사항뿐만 아니라, 이미 push한 커밋에 대해서도 나중에 셀프 리뷰를 할 수 있다.

Alt+9로 버전 관리 툴 윈도우 (Version Control tool window)를 열고, Git 로그에서 대상 커밋을 선택 → 「Self-Review with AI」를 클릭.

개인적으로 가장 흥미롭다고 생각한 점은, 리뷰 가이드라인 (Review Guidelines)을 Markdown 파일로 지정할 수 있는 기능이다.

Settings | Tools | AI Assistant | Project Settings의 「Path to rules for AI Self-Review」에 파일 경로를 지정하면, AI가 해당 규칙에 따라 리뷰를 수행한다.

# Code Review Guidelines
## Naming
- 메서드명은 동사로 시작할 것 (get / create / update / delete)
- Boolean 변수는 is / has / should로 시작할 것
...

팀의 규약을 Markdown으로 작성해 두면, AI가 그것을 바탕으로 리뷰한다.

의도적으로 심어둔 위반 사항을 모두 검출했다.

지적내용
varval
id / name / active 3개 프로퍼티를 하나로 묶음
activeisActiveBoolean 명명 규칙
usergetUser메서드명을 동사로 시작
빈 catch 블록log.severe()로 기록해야 함
if (user != null)?:Elvis 연산자를 사용
  • 지적은 모두 영어로 출력되었다.
  • 가이드라인이 없어도 Kotlin의 일반적인 베스트 프랙티스 (Best Practice)로서 전 건 검출되었다.

검출 건수와 내용은 동일한 5건이었다. 가이드라인이 없을 때와의 차이점은 지적 문구의 말투였다.

지적 사항가이드라인 없음가이드라인 있음
빈 catch 블록Consider logging the exceptionUse log.severe() ... as per the guidelines
varvalIt is recommended to use valshould be marked as val ... per the guidelines
Boolean 명명renamed to isActivenamed isActive to follow the naming convention
메서드 명명align with naming conventionsadhere to the 動詞で始める rule (일본어 그대로 인용)
null 체크use the Elvis operatorfollowing the guideline
  • 건수 및 검출 위치에는 차이가 없었다
  • 가이드라인이 있는 경우, 「per the guidelines」, 「following the guideline」과 같이 근거가 가이드라인임을 명시하였다
  • 가이드라인의 일본어( 動詞で始める [동사로 시작하기] )가 지적 문구에 그대로 인용되었다

AI를 통한 셀프 리뷰(Self-Review)는 「PR(Pull Request)을 보내기 전에 한 번 AI에게 보여준다」는 습관을 IDE를 벗어나지 않고 실천할 수 있는 편리한 기능이라고 느꼈다.

  • 리뷰에서 같은 종류의 지적을 받고 있다
  • 커밋 전에 「누락된 것이 없는지 불안하다」
  • 팀의 코딩 규약(Coding Convention)을 자동으로 확인하고 싶다

반대로, 거대한 커밋을 한꺼번에 보내는 운영 스타일이라면 리뷰 대상이 너무 넓어서 실용적이지 않을 수도 있다. 작고 세밀하게 커밋하는 개발 스타일과 궁합이 좋아 보인다.

팀의 규약을 Guidelines 파일에 작성하기 시작하면, 서서히 효과를 발휘하는 기능이라고 생각한다.

저희 회사는 JetBrains 제품에 관한 질문이나 상담 등을 받고 있습니다. 저희의 X(구 Twitter) 또는 이메일로 연락해 주시기 바랍니다.

AI 자동 생성 콘텐츠

본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0