긍정적 사고, 음식의 절제, 규칙적인 운동

AI 코드 리뷰는 몇 번 돌려야 할까

https://edgelog.dev/ko/blog/how-many-ai-code-reviews/

AI 코드 리뷰는 몇 번 돌려야 할까? 약 400번의 LLM 호출로 직접 측정해봤습니다

AI로 코드를 작성하고 리뷰까지 맡기다 보면 생각보다 자주 이런 상황을 만납니다.

코드 작성 → 리뷰 → 수정 → 다시 리뷰 → 다시 수정 → 또 리뷰...

처음 리뷰에서 문제를 몇 개 찾아 고쳤는데, 다시 리뷰하면 새로운 문제가 나옵니다.
그걸 고치고 다시 돌리면 또 다른 지적이 나옵니다.

리뷰 → 수정 → 리뷰 → 수정이 끝나지 않습니다.

그러다 보면 애매해집니다.

대체 언제 끝내야 할까?

• 지적(이슈)가 0개가 될 때까지?
• 테스트가 모두 통과하면?
• 2~3번 정도 돌리면 충분한가?
• 계속 돌릴수록 실제로 코드가 좋아지는가?

특히 이 과정을 에이전트나 CI에 자동화하려고 하면 더 문제가 됩니다.

review → fix → review → fix

루프를 만드는 건 어렵지 않은데, 언제 멈춰야 하는지에 대한 근거가 없습니다.

저도 최대 3라운드까지 자동 반복하는 워크플로를 사용하고 있었는데, 어느 순간 궁금해졌습니다.

정말 리뷰와 수정을 반복할수록 코드가 좋아질까?

그래서 실제 C 펌웨어 코드와 별도의 벤치마크 과제를 대상으로 리뷰어와 수정자를 분리하고, 약 400회의 LLM 호출을 돌려 직접 측정해봤습니다.

결과는 생각했던 것과 조금 달랐습니다.

1. 리뷰만 반복하는 것은 효과가 있었습니다

같은 코드를 수정하지 않고 반복해서 리뷰하면 실제 결함 커버리지가 대략

34% → 61% → 76%

로 증가했습니다.

같은 코드, 같은 모델이어도 매번 보는 문제가 달랐습니다.
어떤 실제 결함은 10번 중 한 번만 발견되기도 했습니다.

즉, AI 리뷰 한 번만으로 충분하다고 보기는 어려웠습니다.

2. 하지만 리뷰와 수정을 반복하는 것은 다른 문제였습니다

리뷰 → 수정 → 리뷰 → 수정

루프를 반복했을 때 테스트/계약 준수율은 그대로인데, 코드는 조건에 따라

+24% ~ +152%

까지 커졌습니다.

즉,

리뷰를 반복하는 것과 리뷰-수정 루프를 반복하는 것은 같은 일이 아니었습니다.

발견의 이득은 리뷰에서 나오지만, 수정할 때마다 새로운 변경과 새로운 위험도 함께 생깁니다.

3. 여러 번 지적됐다고 더 정확한 것도 아니었습니다

처음에는 여러 리뷰에서 반복적으로 나온 finding일수록 진짜일 가능성이 높을 거라고 생각했습니다.

그런데 대상 파일 하나만 보여준 조건에서는 반대였습니다.

오탐이 실제 결함보다 더 자주 반복적으로 보고됐습니다.

여러 AI가 독립적으로 리뷰하더라도 모두 같은 context를 잃고 있다면,
같은 잘못된 가정에서 출발해서 같은 방향으로 틀릴 수 있었습니다.

4. Repository context가 오탐 제거에 상당히 중요했습니다

대상 파일 하나만 보여준 조건에서는 고유 지적의 29%가 오탐이었습니다.

반면 호출자, 헤더, 초기화 경로 등 repository를 읽을 수 있게 하자 동일한 오탐들이 사라졌습니다.

코드 리뷰에서는 모델 자체뿐 아니라,

모델에게 어디까지 볼 수 있게 할 것인가

도 상당히 중요한 변수였습니다.

5. AI가 조용해졌다고 리뷰가 끝난 것도 아니었습니다

몇 라운드 이후 "지적 없음"이 나오더라도 같은 코드를 다른 관점으로 구조화해서 리뷰하면 새로운 failure mode가 다시 나왔습니다.

그래서 단순히

finding == 0

을 종료 조건으로 쓰기도 어려웠습니다.

6. 테스트 통과만으로도 종료를 판단하기 어려웠습니다

여러 조건에서 테스트 결과는 계속 동일했습니다.

그런데 코드 크기와 복잡도는 크게 달라졌습니다.

즉,

테스트를 계속 통과한다 = 코드가 계속 좋아지고 있다

라고 보기는 어려웠습니다.

그래서 현재 제가 쓰고 있는 가장 단순한 원칙은:

리뷰는 여러 번, 수정은 한 번.

여러 독립 리뷰에서 finding을 먼저 모으고, 사람이 한 번 선별한 다음 수정자에게 한꺼번에 넘깁니다.

그리고 수정 폭이 충분히 크다면 다음 리뷰는 단순한 '재리뷰'가 아니라,

새로 생긴 코드에 대한 첫 리뷰

라고 보는 편이 더 맞다고 생각합니다.

다만 아직 일반화하기에는 작은 실험입니다.

다른 조건이나 모델에서도 다시 확인된 결과는 일부뿐이고, Python 벤치마크 과제도 두 개뿐입니다. 언어나 코드베이스가 달라졌을 때 결과가 달라진 경우도 있었습니다.

그래서 이 결과를 모델 성능 비교보다는,

“AI 코딩 에이전트의 review/fix loop를 어떻게 설계하고, 어디서 멈출 것인가?”

에 대한 실험으로 보는 것이 맞습니다.

실험 과정에서 초기 결론이 여러 번 뒤집혔고, 그 과정과 원 데이터, 벤치마크 코드, 현재의 실무 처방, 한계까지 모두 공개했습니다.

관련 자료

• 연구 전문 — EdgeLog
  https://edgelog.dev/ko/blog/how-many-ai-code-reviews/

• GitHub 연구 원문
  https://github.com/Ecro/harness-bench/…

• 측정 결과를 기반으로 정리한 실전 처방
  https://github.com/Ecro/harness-bench/…

• 자신의 AI 코딩 파이프라인에 적용하기 위한 가이드
  https://github.com/Ecro/harness-bench/…

• 이 실험으로 주장할 수 없는 것 / 연구의 한계
  https://github.com/Ecro/harness-bench/blob/main/docs/LIMITS.ko.md

http://www.zdnet.co.kr/column/column_view.asp?artice_id=20131223174623&type=xml

SW개발, 제대로 된 코드리뷰가 힘든 이유

두달넘게 소프트웨어 개발문화에 관련된 칼럼을 쓰고 있다. 문화란 한쪽이 일방적으로 잘못되었다기 보다는 서로 다른 부분이 많은 것이다. 그러한 우리 문화 중 소프트웨어 개발에 불리한 부분을 짚어보고 같이 고민해보자는 의미로 칼럼을 쓰고 있다.

문화란 공동체의 비슷한 생각과 행동이다. 공동체에 속한 사람은 당연히 하는 행동도 다른 문화를 가진 사람들은 지식적으로는 알고 있어도 쉽게 따라하기 정말 어렵다. 개인의 습관은 개인의 의지로 고칠 수 있지만 집단의 문화는 바꾸기가 훨씬 어렵다.

그래서 개발문화는 우리가 흔히 알고 있는 것도 제대로 정착시키기가 힘들다. 그중에서 대표적이고 중요한 것이 '리뷰 문화'다.

소프트웨어 개발에 있어 가장 중요한 문화 중 하나인 “리뷰문화”가 제대로 정착된 회사를 우리나라에서 찾기란 그렇게 쉬운 일이 아니다. 다들 그 중요성은 알고 있지만 대부분은 시도해보고 포기하기를 반복하곤 한다.

왜 그렇게 리뷰가 어려울까?

가장 흔히 하는 얘기는 리뷰할 시간이 없다는 것이다. 물론 이것은 단기적으로는 오해지만 이해가 안가는 것은 아니다. 매일 일정에 쫓겨서 간신히 구현만 하기에도 허덕인다. 통계 상으로는 적절한 리뷰를 하는 것이 총 개발시간 및 비용을 절약해 준다고는 하지만 이것은 손에 잡히지 않는 이상의 세계와도 같다.

많은 회사들이 리뷰를 특히, 코드리뷰를 강제화하곤 하는데 그 결과 효율적인 리뷰가 되기보다는 의무적인 리뷰로 변질되면서 리뷰에 대한 나쁜 기억만 쌓이게 된다. 그러다보면 리뷰문화가 제대로 정착하지 못하고 포기하거나 강제화 덕에 비효율적이지만 명맥만 유지하게 된다.

리뷰문화는 어렵다고 포기해도 될만큼 사소하지 않다.

리뷰에는 여러가지 목적이 있다. 오류검출외에 공유, 교육의 목적도 있다. 품질 향상을 위해 리뷰를 하지만 리뷰를 통해서 지식 및 정보가 공유되고 노하우가 전달되며 개발자들이 서로 성장하게 된다. 지식공동체가 리뷰를 통해서 성장하게 되는 것이다. 사실 리뷰를 통하지 않고서는 개발자들의 핵심 역량이 성장하기는 어렵다.

리뷰가 활발하지 않다면 혼자서 책보고 인터넷보고 피아노를 배우는 것과 비슷하다. 더 많은 시행착오를 겪어야하며 느리게 성장하거나 좌절하게 된다. 자칫 우물안 개구리가 되거나 자아도취에 빠지기 쉽다. 이런 환경에서는 아마추어가 될 수는 있지만 프로가 되기는 어렵다.

그럼 리뷰를 제대로 하려면 어떻게 해야 할까? 리뷰 문화가 잘 정착된 곳에서는 어떻게 리뷰를 하고 있을까?

What, When, Who, How 4가 측면으로 살펴보자.

What, 무엇을 리뷰하는가?

'리뷰'하면 흔히 코드리뷰를 생각한다. 하지만 소스코드만 리뷰를 하는 것은 그렇게 효율적이지 못하다. 설계가 다 된 빌딩을 만들면서 벽돌 쌓는 것만 검토하는 것이다. 설계가 잘못되었다면 이미 되돌릴 수가 없다. 그리고 스펙과 설계가 공유가 안된 상태라면 소스코드를 봐도 리뷰할 것이 별로 없다. 기껏해야 코딩 규칙이나 문법 등 밖에 못본다.

코드리뷰보다 더 중요한 것은 스펙과 설계 리뷰다. 스펙과 설계리뷰가 더 어려운 이유는 스펙과 설계를 제대로 작성하지 않기 때문이다. 아무리 스펙과 설계가 없어도 소스코드는 있기 때문에 코드리뷰는 항상 할 수 있다. 스펙과 설계를 제대로 작성하고 충분히 리뷰를 해야 한다. 코드리뷰 때보다 스펙과 설계 리뷰 시에 더 다양하고 중요한 것을 배우고 공유할 수 있다.

When, 언제 리뷰하는가?

코드리뷰를 포함해 리뷰의 실패로 이어지는 대표적인 방법은 나중에 몰아서 리뷰를 하는 것이다.

피어데스크체크부터 인스펙션까지 코드리뷰의 종류도 여러가지가 있지만 별다른 전략없이 1주나 2주에 한번씩 개발자들이 모여서 지금까지 작성한 코드를 놓고 끝장 리뷰를 하곤 한다. 사전에 검토하지 않고 참석해서 내용을 파악하지도 못하고 장시간 모여 리뷰를 하게 되면 집중력이 떨어지고 형식적인 일이 되기 쉽다. 이렇게 잔뜩 개발을 해 놓고 검토를 한들 고치기도 어렵다.

성공적인 리뷰를 하려면 그때 그때 바로 해야 한다. 코드리뷰에서 가장 쉽게 성공할 수 있는 방법중 하나는 소스코드를 등록하기 전에 동료와 모니터를 보면서 5분~10분 정도 검토를 하는 것이다. 고칠 것이 있으면 바로 고칠 수 있다. 이것을피어데스크체크(Peer desk check)라고 하는데 가장 쉽게 적용할 수 있는 방법 중 하나다.

이외에도 소스코드를 등록하고 나서 고친 내용을 이메일을 통해서 리뷰를 할 수도 있고 소스코드 리뷰시스템을 이용하면 좀더 수월하게 할 수 있다. 원격지에 있는 개발자와도 리뷰가 가능하다. 중요한 것인 코딩을 하고 즉시 리뷰를 하는 것이다. 물론 몇 시간의 시간 간격이 있지만 다시 고치기에 부담이 없는 시간이다.

스펙을 작성하거나 설계를 할 때도 마찬가지다. 다 작성하고나서 한꺼번에 리뷰를 하는 것이 아니라 중간 중간 필요할 때마다 리뷰를 계속 하면서 작성해야 한다. 너무 자주는 아니지만 적절할 때 리뷰를 하는 것이 요령이다.

Who, 누가 리뷰하는가?

흔히 리뷰를 프로세스로 생각하고 승인을 받도록 한다. 그래서 팀장이나 고참 개발자들이 리뷰를 의무적으로 하도록 한다. 물론 내용적인 검토를 하기 위해서는 그렇게 해도 되지만 팀장이나 고참이 항상 리뷰를 할 수 없을 수도 있고 시간이 안될 수도 있다.

리뷰는 목적에 따라 다양한 사람들이 할 수 있다. 코드리뷰는 주로 고참개발자들이 진행하지만 개발자들끼리 서로 리뷰를 할 수도 있다. 내용에 따라서 어려운 것은 특별히 고참개발자를 지정해서 리뷰를 요청할 수도 있고 일반적인 것들은 동료와 같이 리뷰를 해도 공유의 목적을 달성하는 것이고 동료들끼리도 서로 배울 수 있는 것도 많다.

스펙과 설계를 작성할 때는 각 분야의 전문가와 리뷰를 한다. 마케팅팀, 영업팀, QA팀 등과 해당 팀과 관련된 내용을 리뷰한다. 특히 설계를 할 때는 아키텍트들의 도움을 받고 특정 기술에 대해서는 해당 기술의 전문가의 리뷰를 받으면서 도움을 얻는다.

따라서 리뷰자를 프로세스에 강제로 지정하면 비효율적인 리뷰가 될 수도 있다. 리뷰 내용과 목적에 따라서 적절한 사람이 리뷰를 할 수 있도록 해야 한다.

How, 어떻게 리뷰하는가?

리뷰는 감사(Audit)가 아니다. 리뷰를 하라고 하면 귀찮아하고 부담스러워하지만 리뷰는 누군가가 나를 도와준다고 생각하면 좋다. 또, 누군가가 나에게 리뷰를 부탁하면 나의 전문성을 가지고 누군가를 도와줘야 하는 일이므로 꼼꼼히 검토를 하고 최선을 다해야 한다.

고참이 될 수록 리뷰어(Reviewer)인 경우가 많다. 따라서 고참들은 리뷰를 할 수 있는 시간을 충분히 확보를 해야 한다. 이것을 일은 적게한다고 생각하면 안된다. 코딩 한줄 더 하는 것보다 리뷰를 해주는 것이 전체적으로 이익이기 때문에 그렇게 하는 것이다.

리뷰를 하려면 우선 문서가 있어야 한다. 소스코드, 설계문서, 스펙문서가 있어야 한다. 바로 만나서 가볍게 하는 리뷰도 있지만 대부분은 미리 배포가 되고 검토를 한 후에 리뷰를 진행하는 것이 더 효율적이다. 또 항상 만나야 리뷰를 할 수 있는 것도 아니다. 온라인으로도 충분히 리뷰를 진행할 수 있다.

가끔은 모여서 하는 리뷰가 훨씬 효율적일 때도 있다. 아키텍처 리뷰와 같은 회의가 그중 하나다. 하지만 많은 리뷰는 온라인으로도 충분히 진행할 수 있다.

가끔은 체크리스트를 만들어서 리뷰를 하곤 하지만 체크리스트는 그렇게 효율적이지 못하다. 피아노를 잘 치는 방법 체크리스트 1천개가 있어도 별로 도움이 안된다. 전문가는 10초만 봐도 피아노 치는 방법을 어떻게 바꿔야 하는지 안다.

대부분은 경험을 기반으로 리뷰를 하는 것이다. 자신의 경험과 전문적인 지식을 토대로 리뷰를 하고 도움을 주는 것이다. 체크리스트는 간접적인 도움이 될지는 몰라도 체크리스트를 잘 만든다고 해서 누가나 리뷰를 할 수 있도록 하게 할 수는 없다.

만약에 리뷰를 잘하고 있는 회사에 개발자가 처음으로 입사를 했다면 자연스럽게 습관으로 익혔을 것이다. 그런데 그렇지 않은 회사에서 3,4년 일하다보면 리뷰를 안하는 것이 완전히 몸에 베이게 된다. 그리고 습관을 바꾸기가 정말 어렵다.

세살버릇 여든간다고 하듯 개인적으로도 바꾸기 어렵지만 회사차원에서는 더욱 어렵다. 자율에 맡겨 놓으면 대부분 실패한다. 그렇다고 포기할 수는 없고 프로세스로 강제화하는 것이 시작하는 방법 중 하나다. 이미 리뷰 문화 정착에 실패한 경험이 있는 회사들은 실패의 원인을 잘 찾아야 한다. "이 산이 아닌가보다”가 반복되면 직원들의 거부감만 가득차게 된다.

리뷰를 강제화하되 벌칙보다는 포상으로 정착을 유도하는 것이 좋다. 제약사항을 너무 많이 만들어 놓는 것도 좋지 않다. 직원들의 적응 상태를 봐가면서 아주 천천히 한발씩 나가야 한다.