AI 코드, 어디까지 믿고 병합할까: Addy Osmani가 말하는 위험도 기반 코드 리뷰 | DAKER 커뮤니티

AI가 코드를 만드는 속도는 빠르게 올라갔지만, 그 코드를 이해하고 책임지는 일까지 같은 속도로 빨라진 것은 아닙니다. 그래서 지금 팀에 더 중요한 질문은 AI가 코드를 썼는지가 아니라, 그 변경이 실패했을 때 얼마나 큰 비용이 생기는지일 수 있습니다.

Addy Osmani의 「Agentic Code Review」는 바로 이 지점을 짚습니다. 병목이 작성에서 검증으로 이동한 상황에서, 모든 변경을 같은 방식으로 읽기보다 위험도에 따라 리뷰 깊이를 달리해야 한다는 이야기입니다. Claude Code나 Codex를 쓰는 팀이라면 특히 실감할 만한 관점입니다.

핵심은 AI가 쓴 코드인지가 아니라, 그 변경이 실패했을 때 비용이 얼마나 큰지에 따라 리뷰 깊이를 달리하는 데 있습니다.

코드 작성이 빨라질수록 리뷰는 더 중요해집니다

AI 도구는 기능 구현, 테스트 수정, 리팩터링 PR을 빠르게 만들어냅니다. 하지만 사람이 변경의 의도와 영향 범위를 이해하고, 실제로 그 결과에 책임지는 속도는 그만큼 빨라지지 않습니다. 이 간극 때문에 리뷰의 역할도 달라집니다.

리뷰는 단순히 문법이나 스타일을 확인하는 절차가 아닙니다. 무엇을 바꾸려 했는지, 어디까지 영향을 미치는지, 테스트가 정말 의도를 검증하는지, 운영상 어떤 책임이 따르는지를 확인하는 과정에 가깝습니다.

리뷰의 목적은 문법 확인이 아니라 변경 의도, 영향 범위, 테스트의 의미, 운영 책임을 확인하는 데 있습니다.

모든 diff를 같은 밀도로 읽지 않아도 됩니다

Osmani의 관점에서 중요한 기준은 작성자가 아니라 위험도입니다. 작은 문구 수정이나 설정 변경, 곧 폐기할 프로토타입처럼 실패 비용이 낮은 변경은 자동 검사와 짧은 확인으로 충분할 수 있습니다. 반대로 인증, 결제, 개인정보, 프롬프트 입력 경계처럼 문제가 생겼을 때 비용이 큰 경로는 에이전트 리뷰와 테스트가 통과했더라도 사람이 의도와 위험을 다시 확인하는 것이 좋습니다.

즉, 리뷰 노력은 균등하게 배분하는 것이 아니라 위험이 큰 곳에 더 집중하는 방식이 됩니다. 낮은 위험 변경에는 가벼운 게이트를 두고, 높은 위험 변경에는 타입 검사, 테스트, 서로 다른 AI 리뷰, 보안 검토, 담당자의 인간 리뷰를 거치는 식입니다.

리뷰 노력은 작성자 기준이 아니라 위험도 기준으로 나누는 것이 핵심입니다.

AI 리뷰는 판결이 아니라 신호로 다뤄야 합니다

Claude Code나 Codex 같은 도구의 출력은 유용합니다. 다만 그것을 병합 승인 자체로 받아들이기보다, 사람이 어디를 더 자세히 읽어야 하는지 알려주는 신호로 보는 편이 맞습니다.

짧게 비유하면 AI 리뷰어는 계기판의 센서에 가깝습니다. 센서가 초록색을 보여줘도 실제 도로 상황과 목적지에 대한 책임은 운전자가 집니다. 코드 리뷰도 마찬가지입니다. AI가 이상 없다고 말해도, 변경의 맥락과 실패 비용까지 대신 책임져주지는 않습니다.

AI 리뷰 결과는 병합 승인보다 사람이 시간을 어디에 써야 할지 정하는 triage 신호로 쓰는 편이 적절합니다.

실무에서는 이렇게 적용할 수 있습니다

완료 조건을 먼저 적습니다

Claude Code나 Codex에 작업을 요청할 때는 구현 지시만 주기보다 완료 조건을 먼저 적는 방식이 도움이 됩니다. 예를 들어 인증 경로를 바꾸는 작업이라면 테스트 결과, 영향 파일, 롤백 위험까지 함께 보고하게 할 수 있습니다.

PR을 위험도로 분류합니다

PR을 낮음, 중간, 높음 위험도로 나누면 리뷰 밀도를 정하기 쉬워집니다. 사용자 데이터, 권한, 결제, LLM 프롬프트 입력과 관련된 변경은 기본적으로 높음에 두는 것이 좋습니다.

결정 로그를 남기게 합니다

에이전트에게 diff 요약만 요구하지 말고, 무엇을 하려 했는지와 무엇을 배제했는지도 남기게 하면 검토가 쉬워집니다. 사람이 결과만 보는 것이 아니라 판단의 흔적까지 확인할 수 있기 때문입니다.

테스트 파일을 먼저 읽습니다

테스트가 바뀐 PR에서는 테스트 파일을 코드보다 먼저 읽는 방식이 유효합니다. 에이전트가 실제로 동작을 고친 것인지, 아니면 깨진 동작에 맞춰 assertion만 바꾼 것인지 구분하는 데 도움이 됩니다.

결국 병합의 기준은 신뢰가 아니라 책임입니다

이 글의 요지는 AI를 덜 믿으라는 단순한 경고가 아닙니다. 오히려 AI가 코드를 더 많이 쓰는 환경일수록, 사람의 리뷰는 더 선택적이고 더 책임 중심적이어야 한다는 제안에 가깝습니다.

대표 썸네일의 장면처럼 중요한 순간은 병합 버튼 앞에서 멈춰 서는 판단입니다. 설명 차트가 보여주는 것도 결국 같습니다. AI 리뷰를 승인 도장으로 쓰기보다, 사람이 읽을 위치를 정하는 증거 신호로 쓰는 것이 핵심입니다.

참고 자료

https://addyosmani.com/blog/agentic-code-review/
https://addyosmani.com/blog/loop-engineering/
https://addyosmani.com/blog/agent-harness-engineering/

여러분의 팀에서는 AI가 만든 PR을 어떤 기준으로 더 깊게 리뷰하고 있나요?