# AI 시대의 코드 리뷰

> Clean Markdown view of GeekNews topic #25625. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=25625](https://news.hada.io/topic?id=25625)
- GeekNews Markdown: [https://news.hada.io/topic/25625.md](https://news.hada.io/topic/25625.md)
- Type: news
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-01-07T09:51:01+09:00
- Updated: 2026-01-07T09:51:01+09:00
- Original source: [addyo.substack.com](https://addyo.substack.com/p/code-review-in-the-age-of-ai)
- Points: 47
- Comments: 3

## Summary

AI는 코드 리뷰를 없애지 않고, 오히려 **입증 책임을 명확히 하는 방향**으로 개발 문화를 재편하고 있습니다. 이제 리뷰의 초점은 코드의 옳고 그름보다 **‘작동함을 증명하는 증거’** 에 맞춰지며, 테스트·로그·데모를 통해 변경의 신뢰성을 입증해야 합니다. 솔로 개발자는 자동화된 검증 루프를 만들고, 팀은 리뷰를 통한 **공통 맥락과 책임 공유**를 중요하게 챙겨야 합니다. AI는 단순 작업을 가속하지만 **최종 판단과 책임은 여전히 인간의 몫**이라는 걸 잊지 마세요.

## Topic Body

- AI가 코드 리뷰를 없앤 게 아니라, 오히려 **입증 책임을 명확히** 함   
- 수동 검증이나 자동화된 테스트와 같은 **증거를 첨부**하여 변경 사항을 배포하고, 그 후에 **리뷰를 통해 위험, 의도, 책임 소재를 파악**해야함   
- 개인 개발자는 AI의 속도를 따라잡기 위해 자동화에 의존하는 반면, **팀은 리뷰를 통해 공통된 맥락과 책임감**을 구축  
- PR에 작동 증거가 없으면 빠른 배포가 아니라 **작업을 다운스트림으로 옮기는 것**에 불과, **검증 시스템**을 갖춘 개발자만이 **AI 고속 개발**에 성공함  
- 코드 리뷰의 병목이 코드 작성에서 **작동함을 증명하는 과정**으로 이동했으며, AI가 기계적 작업을 가속하되 **책임은 인간**이 유지해야 함  
  
### AI 시대의 코드 리뷰 변화  
  
- 2026년 초 기준 **시니어 개발자 30% 이상**이 대부분 AI 생성 코드를 배포하고 있으며, AI는 기능 초안 작성에 뛰어나지만 로직·보안·엣지 케이스에서 **로직 오류 75% 증가** 등 취약점 노출  
- 솔로 개발자는 **추론 속도(inference speed)** 로 빠르게 배포하며 테스트 스위트를 안전망으로 활용하고, 팀은 컨텍스트와 규정 준수를 위해 **휴먼 리뷰**를 유지  
- 제대로만 한다면 둘 다 **AI를 가속기로 활용**하지만, **누가, 무엇을, 언제 검증하느냐에 따라 차이가 발생**함  
- **코드가 제대로 작동하는 것을 직접 확인**하지 않았다면 **제대로 작동하는 것**이 아님  
  - AI는 이 규칙을 강화할 뿐, 면제해 주는 것은 아님   
  
### 개발자들의 AI 활용 리뷰 방식  
  
- **Ad-hoc LLM 체크**: 커밋 전에 diff를 Claude·Gemini·GPT에 붙여 넣어 **버그나 스타일 문제를 빠르게 점검**  
- **IDE 통합**: Cursor, Claude Code, Gemini CLI 같은 도구로 **코딩 중 인라인 제안과 리팩토링**을 이용   
- **PR 봇과 스캐너**: GitHub Copilot이나 커스텀 에이전트로 **PR에서 잠재적 이슈를 자동 표시하고**, Snyk 같은 정적·동적 분석 도구로 보안 검사 병행  
- **자동화된 테스팅 루프**: AI로 테스트를 생성·실행하고 **커버리지 70% 이상을 병합 조건으로 설정**  
- **멀티 모델 리뷰**: 여러 LLM으로 코드를 검토해 **모델별 편향을 포착** (예: Claude로 생성, 보안 특화 모델로 감사)  
  
### 솔로 개발자 vs 팀: 비교  
  
* **솔로 개발자**  
  * 리뷰 초점: 자동화된 테스트 + 제한적인 스팟 체크  
  * 속도 트레이드오프: 추론 시간 속도, 반복 루프로 문제 수정  
  * 핵심 도구: 에이전틱 테스팅 (예: Claude Code 루프)  
  * 원칙: **직접 증명하기(Prove it yourself)**  
* **팀**  
  * 리뷰 초점: **컨텍스트와 보안을 사람의 판단으로 검토**  
  * 속도 트레이드오프: **리뷰 병목을 피하기 위해 PR을 작게 유지**  
  * 핵심 도구: 봇 + 정책 조합 (예: AI 생성 PR 라벨링)  
  * 원칙: **작동 증거를 팀과 공유하기(Share the Proof)**  
  
### 솔로 개발자: “추론 속도”로 배포  
- 솔로 개발자들은 AI 생성 코드의 **‘바이브를 신뢰’** 하며, 핵심 부분만 확인하고 테스트로 이슈를 잡는 방식으로 빠르게 기능을 배포  
- 코딩 에이전트를 **대규모 리팩토링을 혼자 처리할 수 있는 강력한 인턴**처럼 다루는 경향  
- Peter Steinberger 발언: “이제 코드를 많이 읽지 않는다. 스트림을 보고, 가끔 핵심 부분만 확인한다”  
- 개발의 병목이 타이핑이 아니라 **추론 시간**(AI 출력 대기)으로 이동  
- **주의점**: 강력한 테스팅이 없으면 체감 속도 향상이 사라짐  
  - 리뷰를 건너뛰는 것은 작업을 없애는 것이 아니라 **뒤로 미루는 것**  
  - AI 기반 고속 개발에 성공하는 핵심은 맹목적 신뢰가 아니라 **검증 시스템 구축**  
- 책임감 있는 솔로 개발자는 **광범위한 자동화 테스트를 안전망으로 활용**, 커버리지 70% 이상을 목표로 설정  
- **언어 독립적이고 데이터 기반인 테스트**가 결정적 역할  
  - 테스트가 충분하면 에이전트가 언어에 상관없이 구현을 생성·수정하며 검증 가능  
  - 프로젝트 시작 시 AI가 spec.md 초안을 작성하고, 승인 후 작성 → 테스트 → 수정 루프를 반복  
- 솔로 개발자도 최종 단계에서는 **수동 테스트와 비판적 판단**을 수행  
  - 애플리케이션을 직접 실행하고 UI를 클릭하며 기능을 사용  
  - 위험도가 높은 경우 더 많은 코드를 읽고 추가 검증 수행  
  - 빠르게 개발하더라도 지저분한 코드는 발견 즉시 정리  
- 핵심 원칙: 개발자의 임무는 **‘작동함을 직접 증명한 코드를 전달하는 것’**  
  
### 팀: AI가 리뷰 병목을 이동시킴  
  
- 팀 환경에서 AI는 코드 리뷰의 강력한 보조자지만, 품질·보안·유지보수성에 필요한 **인간의 판단을 대체할 수 없음**  
- 여러 엔지니어가 협업하는 환경에서는 실수의 비용과 코드의 수명이 훨씬 더 중요한 고려 요소  
- 많은 팀이 AI 리뷰 봇을 PR의 초기 단계에 사용하지만, **최종 승인은 사람에게 요구**  
- Graphite의 Greg Foster 발언: “AI 에이전트가 실제 인간 엔지니어의 PR 승인을 대신하는 일은 없을 것”  
- **가장 큰 실질적 문제**는 AI 리뷰어가 스타일 이슈를 놓치는 것이 아니라, AI가 코드 **볼륨을 증가시켜 인간에게 검토 부담을 전가**한다는 점  
  - AI 도입 확산과 함께 PR 크기 약 18% 증가  
  - PR당 인시던트 약 24% 증가  
  - 변경 실패율 약 30% 증가  
- 출력 속도가 검증 역량을 앞지르면, 리뷰 과정이 전체 개발 흐름의 **속도 제한 요소**로 작동  
- Foster 발언: “동료 인간이 읽거나 이해하지 못한 코드를 배포하는 것은 큰 위험”  
- 팀 환경에서는 AI가 대량의 출력을 만들어내기 때문에, **점진적 개발 방식 적용이 필요**하며 에이전트 출력을 검토 가능한 커밋 단위로 분할  
- 인간의 최종 승인은 사라지지 않으며, 대신 **AI가 놓치는 영역에 집중하는 방향으로 진화**함  
  (로드맵 정렬, AI가 파악하지 못하는 조직적·제도적 맥락)  
  
### 보안: AI의 예측 가능한 취약점  
  
- 보안은 **인간의 판단이 절대적으로 필요한 영역**  
- **AI가 생성한 코드의 약 45%에서 보안 결함이 발견됨**  
- **로직 오류** 발생률이 인간이 작성한 코드보다 1.75배 높음  
- **XSS 취약점** 발생 빈도가 2.74배 더 높게 나타남  
- 코드 자체의 문제 외에도, 에이전트 기반 도구와 AI 통합 IDE가 **새로운 공격 경로를 만들어냄**  
  - 프롬프트 인젝션, 데이터 유출, RCE 취약점  
- AI가 공격 표면을 확장시키는 만큼, **하이브리드 접근이 효과적**  
  - AI가 문제를 플래그하고, 인간이 최종 검증  
- **규칙**: 인증, 결제, 시크릿, 신뢰할 수 없는 입력을 다루는 코드는  
  AI를 **고속 인턴처럼 다루고**, 머지 전 **인간의 위협 모델 리뷰와 보안 도구 검사**를 필수로 수행  
  
### 리뷰를 통한 지식 전달  
  
- 코드 리뷰는 팀이 **시스템 컨텍스트를 공유하는 핵심 수단**  
- AI가 코드를 작성했지만 아무도 설명할 수 없다면 **온콜 비용이 증가**  
- 완전히 이해하지 못한 AI 생성 코드를 제출하면 팀의 회복력을 만드는 **지식 전달 메커니즘이 붕괴**  
- 작성자가 코드가 왜 작동하는지 설명하지 못하면, 온콜 엔지니어는 새벽 2시에 디버깅이 불가능  
- **OCaml 메인테이너가 13,000줄 분량의 AI 생성 PR을 거부한 사례**  
  - 코드 품질이 반드시 나빴던 것은 아니지만, 해당 규모의 변경을 검토할 **리뷰 대역폭이 부족**  
  - AI 생성 코드 리뷰가 인간이 작성한 코드보다 **더 큰 인지 부담**을 요구  
- 교훈: **AI는 대량의 코드를 만들어낼 수 있지만, 팀은 리뷰 병목을 피하기 위해 변경 규모를 관리해야 함**  
  
### AI 리뷰 도구 활용법  
  
- AI 리뷰 도구에 대한 사용자 경험은 **확연히 엇갈림**  
- **긍정적 측면**: 일부 사례에서는 널 포인터 예외, 테스트 커버리지 누락, 안티패턴 등 **버그의 95% 이상을 포착**  
- **부정적 측면**: 일부 개발자는 AI 리뷰 코멘트를 가치 없는 일반론적 관찰인 **‘텍스트 노이즈’** 로 인식  
- 교훈: AI 리뷰 도구는 **신중한 설정이 필요**  
  - 민감도 조정, 도움이 되지 않는 코멘트 유형 비활성화, 명확한 옵트인·옵트아웃 정책 수립  
- 적절히 설정하면 AI 리뷰어가 **쉬운 문제의 70~80%를 포착**하고, 인간은 아키텍처와 비즈니스 로직에 집중 가능  
- 많은 팀이 AI가 한 번에 거대한 변경을 만들 수 있어도 **작고 쌓을 수 있는 PR**을 권장  
- 변경은 자주 커밋하고, 각 변경을 **자체 완결된 단위로 명확한 메시지와 함께** 별도 커밋·PR로 관리  
- **팀은 인간 책임에 대한 명확한 경계를 유지**  
- AI의 기여 정도와 관계없이 **최종 책임은 인간에게 귀속**  
- IBM 교육 격언: “컴퓨터는 절대 책임질 수 없다. 책임은 루프 안에 있는 인간의 몫이다”  
  
### PR 계약: 저자가 리뷰어에게 갖는 의무  
  
- 솔로든 팀이든 공통으로 부상하는 모범 사례는 **AI 생성 코드를 검증이 필요한 유용한 초안**으로 취급하는 것  
- 가장 성공적인 팀들이 공통적으로 사용하는 간단한 프레임워크 존재  
- ## PR 계약 구성요소  
  1/. **What/Why**: 변경 의도와 이유를 1–2문장으로 정리  
  2/. **작동 증거**: 테스트 통과 결과와 수동 검증 단계(스크린샷·로그)  
  3/. **위험 + AI 역할**: 변경 위험 수준과 AI가 생성한 부분 명시(예: 결제 기능은 고위험)  
  4/. **리뷰 포커스**: 인간의 검토가 필요한 1–2개 영역 지정(예: 아키텍처)  
- 이는 관료주의가 아니라 리뷰어 시간을 존중하고 **저자 책임을 명확히 하기 위한 장치**  
- 이 내용을 작성할 수 없다면, 다른 사람에게 승인 요청을 할 만큼 **자신의 변경을 충분히 이해하지 못한 상태**  
  
### 핵심 원칙들  
  
- **약속이 아닌 증거 요구**: “작동하는 코드”를 기준선으로 삼고, AI 에이전트에게 코드 생성 후 실행이나 유닛 테스트 실행을 요구하며 로그·스크린샷·결과 같은 증거를 확인, **새 테스트나 작동 데모 없이 PR을 올리지 않음**  
- **AI를 최종 중재자가 아닌 1차 리뷰어로 사용**: AI 리뷰 출력은 자문으로 취급하고, 한 AI가 코드를 작성하고 다른 AI가 검토하며 인간이 수정 방향을 조율, AI 리뷰는 **맞춤법 검사 수준으로 활용하고 편집자는 아님**  
- **휴먼 리뷰는 AI가 놓치는 부분에 집중**: 보안 취약점 도입 여부, 기존 코드 중복(흔한 AI 결함), 접근 방식의 유지보수 가능성 등에서 **AI는 쉬운 문제를 걸러내고 인간이 어려운 판단을 담당**  
- **점진적 개발 시행**: 작업을 작은 단위로 분할해 AI가 생성하기 쉽고 인간이 리뷰하기 쉽게 유지, 명확한 메시지를 가진 작은 커밋을 체크포인트로 활용, **설명할 수 없는 코드는 절대 커밋하지 않음**  
- **높은 테스팅 표준 유지**: 코딩 에이전트를 효과적으로 활용하는 개발자들은 강력한 테스팅 관행을 유지하며, AI에게 테스트 초안을 요청해 사람이 놓치기 쉬운 **엣지 케이스 테스트를 생성**  
  
### 향후 전망: 병목이 이동함  
  
- AI는 코드 리뷰를 **줄 단위 게이트키핑에서 고수준 품질 관리**로 이동시키고 있지만, 인간의 판단은 여전히 **안전상 필수 요소**  
- 이는 워크플로우의 **진화**이며, 코드 리뷰의 제거가 아님  
- 코드 리뷰 범위가 코드 diff뿐 아니라 **AI와 저자 사이의 대화나 계획**까지 포함  
- 인간 리뷰어의 역할은 점점 **편집자나 아키텍트**에 가까워지며, 중요한 판단에 집중하고 일상적 검사는 자동화를 신뢰  
- 솔로 개발자에게는 앞으로의 길이 흥미롭지만, 새 도구가 늘어나도 현명한 개발자는 여전히 **‘신뢰하되 검증’** 을 유지  
- 대규모 팀에서는 **AI 거버넌스 강화**가 예상됨  
  - AI 기여에 대한 정책을 공식화하고, 직원이 직접 리뷰했다는 승인 요구  
  - **‘AI 코드 감사자’** 와 같은 역할 등장  
  - 엔터프라이즈 플랫폼은 멀티 리포지토리 컨텍스트와 커스텀 정책 집행을 더 잘 지원하는 방향으로 진화  
- **핵심 원칙은 변하지 않음**: 코드 리뷰는 소프트웨어가 요구사항을 충족하고, 안전하며, 견고하고, 유지보수 가능하도록 보장  
- AI는 이 기본을 바꾸지 않으며, **도달하는 방식만 변화**  
- 개발의 병목은 코드 작성에서 **작동을 증명하는 과정**으로 이동  
- AI 시대의 뛰어난 코드 리뷰어는 이 변화를 받아들이되, AI가 기계적 작업을 가속하도록 허용하면서도 **책임의 선은 유지**  
- AI는 프로세스를 **가속(accelerate)** 할 수 있지만, 책임을 **포기(abdicate)** 하게 해서는 안 됨  
- 엔지니어들은 점점 **‘바이브보다 증거(proof over vibes)’** 를 중시하게 됨  
- 코드 리뷰는 사라지지 않았으며, 더 **전략적인 역할**로 변화 중  
- 새벽 2시에 배포하는 솔로 개발자든, 중요한 시스템 변경을 승인하는 팀 리드든 공통된 사실은 **AI가 만든 결과에 대한 최종 책임은 인간에게 있음**  
- AI를 받아들이되, **작업을 다시 확인하는 습관**은 유지해야 함

## Comments



### Comment 48937

- Author: tested
- Created: 2026-01-09T11:33:40+09:00
- Points: 1

https://www.coderabbit.ai/  
코드래빗 써보신 분? 가격이 꽤나 비싼데 그만큼 값어치를 하는지 모르겠네요.

### Comment 48816

- Author: developerjhp
- Created: 2026-01-07T15:11:54+09:00
- Points: 1

아래 크롬 익스텐션 사용하시면 편하게 GPT에게 github PR Diff기반으로 리뷰 받을 수 있어요~!  
https://github.com/developerjhp/Diffinity

### Comment 48817

- Author: crawler
- Created: 2026-01-07T15:21:20+09:00
- Points: 1
- Parent comment: 48816
- Depth: 1

직접 만드신 거면 Show GN에 올려주시는 게 좋을 거 같아요.  
  
5달 전까지만 해도 Show GN에 잘 올려주셨는데 왜 댓글에 홍보를 ㅠㅠ...