▲

AI 코드 리뷰: 작성자가 리뷰어가 되어도 될까?

 (greptile.com)
3P by GN⁺ 2일전 | ★ favorite | 댓글 3개
  • AI가 작성한 코드를 AI가 리뷰하는 것이 타당한지에 대한 흥미로운 질문
  • Devin AI와 같은 봇이 가장 많은 PR을 작성하고 있으며, 리뷰 역시 AI가 수행되는 사례가 늘고 있음
  • LLM은 상태가 없고(stateless), 리뷰와 작성 시 내부 구조가 다르므로 역할 구분이 가능하다는 주장도 존재함
  • AI가 생성한 코드는 사람보다 다른 유형의 버그를 유발하고, AI는 그 버그를 찾는 데 더 효과적임
  • 결과적으로 AI 리뷰는 인간 리뷰보다 실제적인 오류 감지에 유리, 단 인간의 건축적 판단과 스타일 가이드는 여전히 중요함

AI가 자기 코드를 리뷰해도 될까?

  • 대부분의 회사는 작성자 ≠ 리뷰어 원칙을 지키고 있음
  • 그러나 AI는 LLM 기반으로 상태가 없고 요청마다 새롭게 판단함
  • 즉, 동일한 엔진을 사용해도 작성과 리뷰는 다른 “차” 로 볼 수 있음

Scaffolding: AI 리뷰의 구조

  • 리뷰를 위한 AI는 다음과 같은 특정 워크플로우를 수행함:
    • 코드 diff 분석
    • 버그 감지
    • 코멘트 작성 및 심각도 판단
    • 코드베이스 문서와 연관 파일 참조
  • 반면 코드 생성 AI는 완전히 다른 맥락에서 동작하므로 리뷰와 생성은 기능적으로 다름

인간도 사실은 "같은 엔진"

  • PR 작성자와 리뷰어가 달라도, 같은 인간 지능에서 나옴
  • 같은 회사, 같은 훈련을 받은 비슷한 지식과 경험을 공유하고 있음
  • 결국 AI와 인간 모두 “동일 엔진, 다른 케이스” 라는 점에서 유사함

AI 코드, 더 정밀한 리뷰가 필요함

  • AI 코드의 품질은 살짝 낮음

    • AI는 속도는 빠르지만, 프롬프트의 한계로 인해 요건 전달이 부정확함
    • 좋은 개발자조차 AI 코드에 대해 자신의 코드만큼 꼼꼼히 리뷰하지 않음
    • 결과적으로 전체 품질은 하향 평준화되며, 중간 수준에 수렴함

  • AI 버그는 사람이 찾기 어려움

    • AI가 만드는 버그는 인간이 보통 만들지 않는 유형
    • 예: 예상치 못한 라인 수정, 미세한 조건문 오류 등
    • Greptile 내부 테스트에 따르면:
      • AI(Sonnet) 는 “Hard” 버그 209개 중 32개 발견
      • 사람 개발자는 평균 5~7개만 찾음

결론

  • AI가 자기 코드를 리뷰하는 것이 기술적으로는 가능하고 의미 있음
  • AI는 버그 탐지에 인간보다 뛰어나며, 리뷰에 실제로 유용함
  • 그러나 인간의 의도 해석, 설계 판단, 코드 스타일 판단은 여전히 중요
  • 작성자 ≠ 리뷰어라는 전통적 기준을 AI에게는 새롭게 해석할 필요가 있음
▲
aer0700 1일전  [-]

LLM 모델을 바꿔 가면서 리뷰하는 건 어떨지 싶네요. A 모델로 작성한 코드를 B, C, D모델로 리뷰한다거나

답변달기
▲
bungker 1일전  [-]

앗 우리회사에서 이렇게 합니다 커서(클로드)로 작성한 코드를 pr하면 chatgpt로 리뷰하고 있습니다. 이제부터 서로 싸워라 하고요. o4-mini에서부터 사람들 감탄 나오더라구요. 커서에서 모델바꿔서 요청하는식으로 바로도 해볼수있습니다

답변달기
▲
GN⁺ 2일전  [-]
Hacker News 의견

  • 나는 이 부분을 강조하고 싶음: 엔지니어들은 AI가 생성한 코드를 자신이 작성한 코드만큼 꼼꼼하게 검토하지 않음. 그 이유는 타이핑 속도보다 LLM이 코드를 생성하는 속도가 훨씬 빠르기 때문임. 그래서 스스로 코드를 작성할 때는 자연스럽게 검토하지만, AI가 생성하면 그 과정이 생략됨. 흥미롭게도, 평범한 엔지니어에게는 AI가 오히려 코드 품질을 높여 주기도 함. AI를 많이 쓸수록 좋은 엔지니어와 안 좋은 엔지니어가 점점 비슷한 수준의 코드를 만들게 될 것임. 코드 리뷰, 설계, 작성 각 단계마다 사고방식이 달라서 항상 재미있음

    • 사람마다 상호작용 방식이 다르기 때문에 각자 더 잘 맞는 방법이 있음. 나는 코드를 쓰는 것보다 리뷰하는 게 더 쉬움. 직접 작성할 때는 코드베이스 외에도 맥락을 많이 생각해야 하지만, 리뷰할 때는 그 맥락을 코드베이스에만 집중할 수 있어서 더 빠르게 패턴매칭할 수 있음. 불행히도 LLM의 수준이 주니어 엔지니어 급이라 PR 리뷰에 더 많은 노력과 에너지가 듦

    • 좋은 엔지니어가 반드시 좋은 코더는 아닌 경우가 많음

  • AI로 코드 리뷰와 코드를 작성할 때 사용하는 봇과 프롬프트가 다르면 훨씬 더 많은 오류를 발견할 수 있음. 같은 도구로 여러 번 반복해도 새로운 문제를 찾아내기도 함. 인간이나 AI 모두 한 번에 완벽하게 코드를 만들지 못함. AI 툴이 점점 발전해서 자기 코드를 직접 테스트하고 사전 리뷰하는 단계까지 왔지만, 사람과 AI 모두가 PR 코드를 리뷰하는 것은 절대 해가 되지 않는다고 믿음. 내가 직접 만든 Kamara라는 도구로도 스스로 작성한 코드에서 문제를 발견하는 경우가 많았음. greptile 예시처럼 코드 위치가 완전히 잘못된 제안을 하는 문제도 있었으나 점점 제어하고 있음. 아직 100% 완벽한 툴은 없고, AI가 모든 것을 takeover하기 전까지는 조금 더 시간이 필요하다고 느낌

  • OpenHands(이전 이름은 OpenDevin)을 시작했을 때, AI가 만든 PR이 AI 계정 이름으로 올라왔음. 이로 인해 두 가지 심각한 문제가 있었음: 1) AI를 호출한 사람이 코드 리뷰 없이 바로 머지할 수 있어 검수하지 않는 코드가 배포될 수 있었음, 2) PR의 명확한 책임자가 없어 머지되지 않거나 문제가 생겨도 누구에게 책임을 물어야할지 불분명했음. 그래서 모든 PR을 사람이 오너로 갖게 전략을 바꿨고, 커밋만 AI 이름으로 남도록 했음. PR 자체는 전적으로 인간의 책임임

    • 만약 문제가 생긴 코드를 머지했다면, 결국 승인자와 머지한 사람이 책임을 져야 한다는 점은 분명함

  • LLM이 버그를 잘 찾아낸다는 부분이 흥미로웠음. 높은 실제 버그 탐지율을 위해 얼마나 많은 오탐이 발생했는지 궁금함. 내 경험상 LLM은 버그가 없는데도 "있다"고 답할 때가 많음

    • 정말 공감함. 나는 ChatGPT에게 뭔가 물어봤을 때 제안이 맘에 들지 않으면 "그 부분 잘 모르겠는데?"라고 하면 바로 답변을 바꿈. 사실 처음에 맞을 수도 있는데, 사용자가 확신이 없으면 쉽게 흔들림. 그래서 툴을 제대로 검증하기가 쉽지 않음

    • 이번 사례에서는 각 파일에 단 한 개의 버그만 있고 봇이 정확하게 하나만 찾으라고 했음. 모두 오탐 사례였으며, 아무런 문제도 없는 곳에서 버그를 만들어냈음

    • 시장에 나온 다양한 AI 코드 리뷰 툴의 차이는 바로 신호/잡음 비율 튜닝에 있음. 어떤 툴은 훨씬 더 정확하고 오탐이 적음

  • 프로그래머로서 가장 중요한 책임은 자신이 자신 있는, 정상 동작하는 코드를 만드는 것임. LLM을 사용한 것 자체는 상관없음. 중요한 건 PR을 올렸을 때 "나는 이 변경이 문제를 해결한다고 확신하고, 내 평판을 걸 수 있다"는 자세임. 그러므로 사람이든 AI든 PR에는 항상 두 번째 검토자가 필요함

    • 내 생각에 평판이 핵심임. 코딩에만 해당하는 것이 아니라 자연어 글도 마찬가지임. 앞으로는 저자가 아니라 공개한 사람, 즉 게시자가 내용에 대한 책임을 져야 하는 시대임. 5%만 챗봇, 95%만 챗봇이 얼마나 개입해도 문제가 생기면 그 글을 게시한 나를 비난해야 함. "챗봇이 한 거라서"라는 변명은 통하지 않음

    • 예시로 Devin 같은 완전 자동화 엔지니어를 이야기한 것일 뿐, 일반적인 엔지니어와는 조금 다른 상황임

    • 요즘 많은 엔지니어들이 AI가 만든 조악한 코드를 무책임하게 던지고, 다른 동료들이 문제를 잡아주길 기대함. 예전에는 코드 생성 자체가 힘들어서 이런 일이 적었음

    • 당신의 책임이 신뢰할 수 있는 코드를 만드는 것이라는 말에 깊이 공감함. 하지만 AI 이전에도 좋은 코드가 잘 지켜지지 않았음. 우리는 코딩을 수단이나 돈벌이로만 여기게 되었음. 본래는 '문제를 풀고 세상을 변화시키는 즐거움'이 있었음. 하지만 지금은 '빠르게 돈을 벌거나 경계를 쌓는 데' 집중하게 되었음. 중요한 건 아름다운 코드인지가 아니라 문제를 세련되게 해결했는지임. AI로 인해 이런 문화가 나빠질 수도 있지만, 결국 어떻게 쓰느냐에 모든 것이 달려 있음

    • 궁금한 게 있음. 만약 PR이 문제는 모두 해결하고 사소한 버그만 들어있다면, 그 PR이 시간 낭비라고 볼 수 있는지 예시가 궁금함

  • 코드 리뷰가 엔지니어링에서 가장 느린 단계임. 나도 AI 없이 코드를 빠르게 쓸 수 있지만 코드 리뷰는 빨라지지 않음. 그래서 리뷰 전에 AI로 미리 리뷰시켜서 동료들의 시간을 절약하고, 사전에 버그도 잡아서 배포까지 걸리는 시간을 며칠씩 줄이고 있음. AI가 명백한 버그와 숨겨진 실수까지 잡아줘서 실제 딥한 버그까지 찾아낸 적 있음. git cli와 xclip 등으로 diff를 복사해서 o3 같은 로직 모델에 붙여 넣어 리뷰 받는 워크플로우를 씀

    • 이런 방식이라면 반드시 OpenAI와 엔터프라이즈 계약을 맺었길 바람

  • AI의 장점 중 하나는 사람보다 훨씬 빠르게 많은 단위 테스트를 쓸 수 있다는 점임. 그리고 자기가 발견한 문제도 스스로 고칠 수 있음. 이상적인 워크플로우는 코드 리뷰뿐만 아니라 AI가 스스로 테스트까지 자동 수행하고, 모든 것이 특정 스펙을 충족하는지 확인하는 것임. 너무 많은 테스트가 나중에 리팩토링을 어렵게 만들거나(예: 구현 세부 사항에 의존하는 테스트), 귀찮을 땐 AI가 쓴 테스트만 따로 버릴 수도 있음

    • 나는 필요할 때마다 단위 테스트를 재생성할 수 있어서 너무 좋음. 리뷰를 올릴 때 diff의 크기에서 큰 만족감을 느끼고, 지루한 테스트 작성 시간을 아껴서 더 많은 일을 할 수 있음

    • 현재도 프로그래밍에는 귀찮은 작업이 남아있지만, AI 이상적으로는 이런 비효율을 줄이고 인간은 창의적인 영역에 집중할 수 있게 해야 함. 그러나 실제로는 AI가 점점 더 고수준의 창의적 작업까지 넘보고 있음

    • 사실 AI가 아니라도 프로퍼티 기반 테스팅 프레임워크를 이용해서 수많은 입력값으로 자동 테스트를 생성할 수 있음

  • 코드 리뷰할 때 규칙이 있음: 내가 나중에 직접 관리할 자신이 없으면 승인하지 않음. 만약 LLM을 코드 작성과 리뷰 양쪽에 쓴다면, 동일한 책임 원칙을 툴에도 적용한다고 볼 수 있음. 하지만 실제로 그런 상황에 오래 남아 있기엔 자신이 없음

  • 하나의 LLM으로 요구사항에서 Gherkin 스크립트를 만들고, 또 다른 LLM으로 그 스크립트에서 코드를 생성한 뒤, Cucumber로 결과를 체크하는 파이프라인을 써 본 사람이 있는지 궁금함. 어쨌든 Gherkin 스크립트와 코드 둘 다 리뷰가 필요하겠지만, 이런 방식으로 만들 수 없는 코드 유형이 무엇인지 알아보고 싶음. AI를 하나의 개발자처럼 보고 있는데, 인간 개발자와 마찬가지로 잘 못하는 영역도 분명 있을 것 같음

  • 결국 PR을 올린 저자가 자기 코드의 영향과 결과에 대한 책임을 져야 함. AI 코딩이 보편화되고 주니어 엔지니어들도 많아지면서 이 책임은 더 중요해졌음. AI가 리뷰의 1차 패스를 맡는 것은 합리적이지만, 인간 리뷰어가 외부적 관점으로 코드베이스 이해도 키우고 더 높은 수준의 문제를 발견해 줄 필요가 있음. 결론적으로 AI가 1차 리뷰, 또 다른 엔지니어가 컨텍스트나 협업 차원에서 코드 리뷰, 그리고 궁극적으로 저자가 모든 결과에 책임지는 구조가 이상적임

답변달기