영상 링크: AI powered entomology: Lessons from millions of AI code reviews — Tomas Reimers, Graphite
채널명: AI Engineer
AI 기반 곤충학: 수백만 건의 AI 코드 리뷰에서 얻은 교훈 핵심 요약
- 영상 제목: AI 기반 곤충학: 수백만 건의 AI 코드 리뷰에서 얻은 교훈
- Tomas Reimers(그래파이트 공동 창업자)는 Diamond라는 AI 기반 코드 리뷰어 개발 경험을 공유함.
- 최근 AI가 작성하는 코드량이 급격히 늘어남에 따라 버그 역시 증가, AI가 버그를 만들지만 동시에 찾아낼 수도 있다는 문제의식을 갖고 출발함.
- 다양한 대형 언어 모델(LLM)에게 실제 PR(풀 리퀘스트)에서 버그를 찾도록 요청한 결과, 일부 실질적인 버그를 성공적으로 탐지했으나, 불필요하거나 실효성이 떨어지는 피드백도 많았음.
- LLM의 코드 리뷰 한계와 장점을 분석하기 위해, AI가 잘 찾는 버그와 그렇지 못한 버그로 분류하고, 개발자들이 AI가 남긴 피드백을 받아들일지의 여부 또한 중요한 축으로 설정함.
- 10,000건 이상의 코드 리뷰 코멘트를 자체 및 오픈소스 저장소에서 수집, 다양한 LLM에 분류시킴으로써 실무적으로 어떤 버그와 피드백 유형이 존재하는지 체계화함.
- AI가 인간에게 ‘환영받는’ 피드백을 남기고 있는지 판단하기 위해, 사용자의 업보트/다운보트 반응, AI 코멘트가 실제 코드 변경에 반영되는 비율 등 구체적 지표를 수집함.
- 평균적으로 전체 인간 코드 리뷰 코멘트 중 약 50%만이 실제 코드 변경을 일으켰으며, 오히려 올바른 프롬프트 설계와 평가 지표 구축으로 AI 역시 이 수준까지 끌어올릴 수 있었음.
- Diamond 제품은 이러한 인사이트를 반영해 LLM이 ‘유의미하고 환영받는’ 리뷰만을 남기도록 설계됨.
- AI 코드 리뷰 성과 측정 및 개선을 위한 ‘계속적인 지표 관리’가 중요함을 강조함.
세부 요약 - 주제별 정리
AI가 작성하는 코드 증가와 버그의 동반 상승이 필연임을 인식함
- 최근 1년간 GitHub 등 코드 저장소에서 AI를 이용한 코드 작성이 급증함.
- 동시에 버그도 함께 늘어나고 있어, 이는 단순한 우연이 아닌 ‘AI 개발환경의 본질적 특성’으로 해석.
- 이에 따라 기존보다 더욱 효과적으로 다양한 버그를 찾아낼 방안이 절실해졌음.
- Graphite 팀에서는 AI가 버그 생성에 기여하는 만큼, AI 자체를 버그 탐지에 사용할 수 있는지 고민하기 시작함.
AI(LLM)이 실제로 코드 버그를 탐지할 수 있음을 다양한 사례로 검증함
- 대형 언어 모델(Claude)을 활용해 “이 PR에서 버그를 찾아봐달라”는 식으로 프롬프트를 주었음.
- 내부 예시: 데이터베이스 ORM 클래스를 인스턴스화하지 않고 반환해 서버가 크래시되는 버그 발견.
- 외부 예시: 트위터에서 Diamond 봇이 ‘border radius 수식에서 음수로 나누는 연산 발생’ 등 실질적 프론트엔드 오류 탐지 사례 공개.
- 결론적으로, LLM이 실제로 코드 내 버그를 찾아낼 수 있음을 확인함.
LLM의 코드 리뷰 피드백에는 작성 능력 한계와 불필요한 조언이 섞여 있음
- 성공적인 버그 탐지 사례와 동시에 “CSS 문법은 이렇다”, “이전 코드로 되돌리라”, “함수 주석을 남겨라” 등 실효성 떨어지는 코멘트가 빈번히 생성됨.
- 이러한 “기계적이거나 엄격한 지시에 가까운” 코멘트는 실제 개발자에게 가치가 떨어짐.
- 즉, LLM은 본질적으로 인간 코드 리뷰어가 남긴 피드백 패턴을 모방하지만, 문맥에 맞지 않거나 불필요한 조언도 함께 제공함.
LLM이 잘 잡아내는 버그와 그렇지 못한 영역은 명확히 구분됨
- LLM이 잘 포착하는 유형: 실제 논리적 버그(오동작 가능성), 우연히 커밋된 코드, 보안/성능 문제 등.
- 인간 개발자만이 적절히 처리할 수 있는 영역: 조직 내부의 ‘트라이벌 지식’(ex. “이전에는 이렇게 했으나 정책상 이렇게 바뀌었다” 등), 히스토리 기반 나침반, 암묵적 패턴 등.
- LLM이 역사적 맥락이나 암묵적 규칙 등은 인지/판단하기 어려움.
LLM이 남기는 ‘지적이지만 환영받기 어려운’ 코멘트가 많음을 인지함
- “함수 주석 추가”, “테스트 코드 추가”, “구조 분리” 등 항상 맞긴 하지만 맥락에 따라 불필요할 수 있는 피드백 반복 발견.
- 개발자들은 이런 코멘트를 인간 리뷰어에게선 환영하지만, AI에게선 오히려 ‘잔소리’로 느끼는 경향이 강함.
- 인간 리뷰어는 상황 맥락에 따라 필요성과 우선순위를 판별해 피드백을 주지만, LLM은 그런 기준 부여가 어렵다는 점이 확인됨.
AI 코드 리뷰를 유용하고 환영받게 만드는 기준이 정립됨
- ‘LLM이 발견 가능’하며 ‘개발자가 받길 원하는’ 피드백 유형만을 남기는 것이 중요함.
- 이 기준 설정을 위해, 자체 코드베이스 및 오픈소스 PR에서 10,000여건의 리뷰 코멘트를 샘플링함.
- 여러 LLM(MODEL)에게 반복적으로 분류 태스크를 맡김 → 실제로 어떤 유형의 버그/피드백이 생성되고, 받아들여지는지 정량 및 정성적으로 분석.
코드 리뷰 코멘트 유형을 다차원적으로 분류하여 개선 방향을 도출함
- 버그, 우연한 코드 커밋, 성능/보안 이슈, 문서와 코드의 불일치, 스타일/코딩 컨벤션 등 다양하게 분류.
- AI가 잘 남기지만 개발자가 원하지 않는 영역(좌측 하단), AI도 못 남기고 인간만 전달하는 영역(우측 하단), 양쪽 모두 환영하는 영역(우측 상단) 등 사분면 모델로 체계화.
- 이러한 분류 기반으로 LLM이 남기는 코멘트를 제어하고, 실제 가치가 높은 피드백만 제공하도록 유도함.
LLM 코드 리뷰 성과 판단을 위해 정량적/정성적 피드백 시스템을 구축함
- 첫 번째 지표: 개발자가 AI 코멘트에 ‘업보트/다운보트’로 즉각 반응할 수 있도록 UI 설계.
- 다운보트 비율이 높아지면 LLM이 한계를 넘었거나 부적합한 피드백을 남기는 것으로 판단, 알고리즘/프롬프트를 개선.
- 실제 운영 데이터를 분석한 결과, 최근 다운보트율은 4% 미만으로 유지됨.
‘코드 리뷰 코멘트가 실제 코드 변경에 영향을 주는가?’라는 실질적 지표 도입
- 코드 리뷰 피드백의 진정한 목적은 코드 수준에서의 ‘실질적 수정’ 유발임.
- 실제 오픈소스/내부 코드베이스 평균 수치: 인간이 남긴 리뷰 코멘트의 약 50%만이 실제 코드 변경을 유도.
- Diamond의 LLM 리뷰 역시 프롬프트와 분류 기준 개선을 통해 동일한 52% 실효성에 도달.
- 100%가 되지 않는 이유: 단순 참고, 추후 개선 예고, 개인 취향 등 코드 변경과 무관한 코멘트도 상당수 존재.
Diamond 제품은 ‘실효적이고 환영받는’ AI 리뷰를 제공하는 데 집중함
- 위 실험과 분석을 바탕으로, Diamond는 LLM이 생성하는 리뷰 유형을 엄격히 선정하고, 불필요하거나 개발자에게 거부감 주는 피드백은 제외함.
- 제품 내 지표 관리 및 피드백 시각화(업/다운보트, 댓글 반영율 등)를 통해 AI 코드 리뷰 품질을 유지/개선함.
- 최신 LLM 모델 적용(Claude 4, Opus 등) 및 지속적인 데이터 수집으로 차세대 AI 코드 리뷰의 정밀도를 높여감.
- Diamond를 실제 적용하고 싶은 개발팀/조직을 위해 부스에서 시연 및 경험 기회 제공.