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

https://www.ddaily.co.kr/page/view/2026081208245230655

최근 AI 솔루션을 공급하는 한 기업 대표를 만나 AI 생산성 향상의 불편한 이면을 들었다. 이 기업은 자체 솔루션을 공급하면서 고객사 요구에 맞춘 시스템 구축 사업도 병행하고 있다.

"AI 코딩으로 개발 생산성이 높아졌지만 발주사로부터 그만큼 사업비를 낮추라는 요구를 받고 있다"는 얘기였다.

일반적으로 국내 시스템 구축 현장에서는 투입할 개발자 수와 기간이 견적을 산정하고 협의하는 기준으로 쓰이곤 한다.

이때 흔히 사용하는 단위가 ‘맨먼스(M/M·Man-Months)’다. 개발자 한 명을 한 달간 전일제로 투입하면 1인월, 개발자 10명을 6개월간 전일제로 투입하면 60인월로 계산한다.

실제로 AI가 코드 작성과 오류 점검을 도우면서 예전보다 개발 시간이 줄었다. 같은 업무를 더 적은 인원과 짧은 기간에 끝낼 수 있게 된 것이다.

발주사 입장에서는 자연스럽게 “그렇다면 투입 인력과 사업비도 줄어야 하지 않느냐”는 계산이 나온다.

그런데 문제는 AI로 줄어든 공수는 사업비를 낮추는 근거가 되지만 수행사가 AI를 도입하고 운영하느라 쓴 비용은 계산에 잘 반영되지 않는다는 점이다.

발주사는 AI로 줄어든 인력과 시간부터 따지지만 정작 AI 사용료와 검증 비용, 개발 환경을 갖추는 데 들어간 투자는 별도로 인정하지 않는다. 결국 "AI 때문에 인건비가 줄었으니 사업비를 깍자"는 단순 무지한 논리가 작동하는 것이다.

그러나 AI가 공짜로 일하는 것은 아니다.

먼저, 생성형 AI 모델을 호출하면 사용량에 따라 토큰 비용이 발생한다. AI가 작성한 코드가 고객사 시스템에서 제대로 작동하는지, 보안과 품질에 문제가 없는지도 사람이 다시 검증해야 한다. AI를 실제 개발 현장에 적용할 환경을 갖추고 시행착오를 거치는 데도 시간과 비용이 든다.

계약을 따내기 전부터 비용이 발생하기도 한다.

발주사가 기술력을 확인하기 위해 무상 개념증명(PoC)을 요구하는 일은 새삼스럽지 않다. 다만 예전에는 인력 투입이 주된 부담이었다면 이제는 여기에 AI 사용 비용까지 더해진다. 수주 여부가 정해지지 않은 상태에서 인력과 AI 비용을 먼저 부담해야 하는 셈이다.

AI 덕분에 줄어든 시간은 바로 보이지만 그 시간을 줄이기 위해 들인 비용은 가격표에 잘 잡히지 않는다. 생산성을 높였다는 이유로 사업비가 낮아진다면 수행사가 AI를 적극적으로 도입할 유인은 약해진다.

AI를 활용한 개발까지 사람의 투입 시간만으로 계산하는 방식에는 한계가 있다. 줄어든 공수뿐 아니라 AI를 적용하고 검증하는 데 든 비용과 개발 기간을 단축해 만들어낸 가치까지 함께 보는 계산법이 필요한 시점이다.

아마존이 인공지능(AI) 모델 학습용 데이터를 확보하기 위해 희귀·절판 도서를 대량으로 사들인 뒤 제본을 잘라내어 스캔하고 원본을 폐기하고 있는 것으로 드러나 논란이 일고 있습니다

배경과 목적: AI 생성물이 섞이지 않은 2022년 이전의 순수 '인간 저작물'과 양질의 텍스트 데이터가 귀해졌기 때문입니다. 인터넷에 AI 생성 콘텐츠가 범람하면서 모델 성능 저하(모델 붕괴)를 막기 위한 조치입니다.

방식: 404미디어 등의 조사에 따르면, 중고 및 희귀 서적을 대량 매입한 후 책등을 절단해 페이지 단위로 스캔하고 실물 책은 폐기하는 방식으로 진행됩니다. 추적 장치를 통해 최종 목적지가 미국 네바다주 라스베이거스에 있는 아마존 시설(VGT3)인 것으로 확인되었습니다.

파장과 논란: 앤스로픽 등 다른 빅테크 기업들도 유사한 방식을 써온 것으로 알려졌습니다. 합법적으로 구매한 책의 스캔 및 폐기 자체는 '공정 이용'으로 인정받는 추세이나, 자본력을 앞세워 희귀 도서 원본을 없앰으로써 후발 기업의 데이터 접근을 차단하고 인류의 지식 유산을 독점·훼손한다는 비판이 제기되고 있습니다. 미국 소비자연맹 등 시민단체들은 이를 불공정 경쟁 및 반독점 이슈로 규정하고 연방거래위원회(FTC)에 조사를 촉구했습니다.

https://www.choicestock.co.kr/stock/news_view/176396?bu=

「AI 시대의 필수 지식 MCP 이 영상 하나로 끝내세요!」 — 조코딩 JoCoding

https://youtu.be/46HxP7kO9oY?si=9S_C51BLPhje4J6M 이 영상의 자막과 내용, 요약 정리

MCP는 AI 모델과 외부 도구를 잇는 USB-C 같은 표준 규격이다. 이 영상은 "왜 필요한지 → 어떻게 쓰는지 → 직접 만드는 법 → 회사에 도입하는 법"까지 한 번에 훑는다.

1부. MCP가 왜 필요한가

• 정의: Model Context Protocol. Anthropic이 2024년 11월에 내놓은 표준으로, AI 모델이 외부 도구·데이터에 접근하는 방식을 통일한 규격.
• 문제: LLM은 다음 단어를 예측할 뿐이라 실시간 정보를 모른다. 도구 없이 "오늘 날씨 어때?"를 물으면 그럴듯한 거짓말(할루시네이션)을 만들어낸다.
• 해결: 날씨 API 같은 도구를 붙여주면 AI가 알아서 그 도구를 호출해 실제 데이터로 답한다.
• 표준화의 의미: Gmail, 캘린더, Slack마다 제각각 연동을 만들면 개발 부담이 폭증한다. MCP는 이 연결 방식을 하나로 통일해 그 부담을 없앤다. → USB-C 비유.

2부. 실제 사용 — 이미 만들어진 MCP 쓰기

• Blender 사례: 3D 툴을 전혀 못 다루는 사람도 Claude Desktop에 Blender MCP를 붙이면 AI가 프로그램을 직접 조작해 3D 오브젝트를 만들어준다.
• Smithery: MCP 모음 플랫폼. 영상 시점 기준 6,341개 이상의 MCP가 등록돼 있어 검색해서 바로 연결하면 된다(코딩 불필요).
• Context7 MCP: Next.js 등 개발 공식 문서를 AI가 참조하게 해주는 도구. 코딩할 때 최신 문서 기준으로 답하게 만든다.
• Claude Desktop 연결법: 데스크톱 앱 설치 → 설정 → 개발자(Developer) → MCP 서버 → JSON으로 설정 추가.

3부. 직접 만들기

• FastMCP(파이썬 라이브러리) 사용. 함수 위에 @mcp.tool 데코레이터만 붙이면 끝날 만큼 간단하다.
• 예제: 두 수를 더하는 함수 하나로 MCP를 만들어 시연.
• 로컬 vs 원격
  • 로컬: 내 PC에서 STDIO(표준 입출력) 방식으로 구동
  • 원격: 클라우드에 배포해 HTTP 방식으로 연결 → 내 컴퓨터를 켜두지 않아도 됨
• VSCode 연동: Ctrl+Shift+P로 MCP 연결, 원격 서버는 HTTP 방식 사용.
• 배포: 파이썬 파일을 Git·클라우드 서비스에 올리면 URL이 생기고, 그 URL로 어디서든 접근 가능.

4부. 회사에 도입하기

• 현실적 문제: VSCode나 Cursor로 MCP를 붙이는 방식은 비개발자 동료에게 배포하기가 사실상 불가능하다.
• Porter AI(소개된 솔루션): 웹 기반으로 기술 지식 없이 MCP를 붙여 쓰게 해주는 플랫폼.
  • 모델 선택 자유: GPT-5, OpenRouter 경유 커스텀 모델 등 외부 모델 추가 가능
  • 사내 데이터 연결: 내부 DB(회원 정보)나 Notion 연동 → 예) "출장 시 식대 얼마인가요?" 질문에 Notion MCP가 사내 규정을 찾아 답변
  • 팀 초대: '팀 초대' 버튼 한 번이면 비개발자도 MCP 설정 없이 사용
  • 사용량 모니터링: 팀원별 AI 사용 통계·모델 선택·소비 패턴을 대시보드로 확인
  • Slack 연동: 채널에서 봇을 태그해 "지난달 신규 가입자 몇 명?"이라고 물으면 DB MCP를 호출해 실제 수치를 가져옴

핵심 흐름은 "할루시네이션 → 도구 연결로 해결 → 그 연결을 표준화한 게 MCP → 쓰기·만들기·팀 배포" 입니다.

클로드 코드 에이전트 팀 사용법, 역할별 AI 팀으로 개발 자동화하기

https://www.elancer.co.kr/blog/detail/1081

클로드 코드 에이전트 팀의 구성요소

클로드 코드 에이전트 팀은 여러 Claude Code 세션을 팀처럼 구성해 복잡한 작업을 역할별로 나누어 처리하는 구조로 팀 리드와 팀원 에이전트가 함께 움직이며 공유 작업 목록, 메시징, 실행 도구를 통해 협업합니다.

1. 팀 리드 에이전트

팀 리드 에이전트는 사용자의 명령을 이해하고 전체 작업 방향을 조율하는 중심 역할을 합니다. “신규 앱을 기획해줘”, “기능 구현과 테스트까지 진행해줘”처럼 요청하면 작업을 어떤 순서로 나눌지 판단하고, 각 팀원 에이전트에게 역할을 배정합니다. 쉽게 말해 Claude Code Agent Teams 안에서 프로젝트 매니저처럼 전체 흐름을 관리하는 역할입니다.

2. 팀원 에이전트

팀원 에이전트는 팀 리드가 배정한 역할에 따라 각자 독립된 컨텍스트에서 작업을 수행합니다. 예를 들어 시장 분석가, 기능 기획자, 프론트엔드 개발자, 백엔드 개발자, QA 담당자처럼 역할을 나눌 수 있습니다. 

각 팀원은 자신의 작업 공간에서 파일을 분석하고 결과물을 만든 뒤, 팀 리드나 다른 팀원에게 작업 내용을 전달합니다.

3. 프로젝트 코드베이스와 실행 도구

Agent Teams의 각 에이전트는 프로젝트 폴더를 기준으로 파일 구조와 코드 흐름을 확인합니다. 또한 파일 읽기, 코드 수정, 터미널 명령 실행 같은 도구를 활용해 실제 작업을 진행할 수 있습니다. 

예를 들어 프론트엔드 에이전트는 화면 관련 파일을 수정하고, QA 에이전트는 테스트 명령을 실행해 결과를 확인하는 방식으로 역할을 나눌 수 있습니다.

4. 하네스 엔지니어링 

하네스 엔지니어링은 에이전트가 어떤 기준으로 판단하고 움직일지 미리 설계하는 과정을 말합니다. 에이전트가 임의로 판단해 엉뚱한 방향으로 작업하는 것을 줄이고, 여러 에이전트가 일관된 기준으로 결과물을 만들 수 있도록 돕는 핵심 장치 역할을 합니다.

예를 들어 CLAUDE.md에는 프로젝트 목표, 에이전트의 역할, 사용할 도구, 출력 형식, 작업 순서, 검증 기준 등을 구체적으로 정의해둘 수 있습니다. 필요하다면 agent.md 같은 별도 마크다운 파일을 만들어 팀 리드와 팀원 에이전트의 역할, 파일 소유권, 릴레이 순서까지 더 자세히 정리할 수 있습니다.

5. 확장 기능

작업이 복잡해질 때는 Subagent, Skills, MCP 같은 확장 기능을 함께 활용할 수 있습니다. Subagent는 단일 Claude Code 세션 안에서 특정 작업을 맡아 격리된 컨텍스트로 처리하고 요약을 반환하는 보조 기능입니다. 

Skills는 특정 작업을 반복적으로 수행하기 위한 재사용 가능한 지식과 워크플로우를 추가하는 기능이고, MCP는 Claude Code를 외부 도구나 데이터 소스와 연결하는 확장 방식입니다. 이 기능들을 함께 활용하면 에이전트 팀의 자동화 범위를 더 넓힐 수 있습니다.

[AI] 클로드코드에서 에이전트 병렬로 실행하기

https://code.claude.com/docs/ko/agents