'AI가 코드 리뷰를 대신해준다'는 말, 이제 낯설지 않습니다. 문제는 어떤 도구를, 어떻게 써야 하느냐입니다. 마케팅 카피 말고 실제 숫자와 현장 경험이 필요한 시점이죠. 최근 dev.to에 올라온 두 편의 실험 아티클과 '코드를 읽지 않는' AI-First 개발 워크플로우 사례를 엮어보면, 꽤 선명한 그림이 나옵니다.
도구별 탐지율: 숫자가 말해주는 것
한 개발자가 .NET 10 코드베이스에 SQL 인젝션, 하드코딩된 자격증명, async void, N+1 쿼리 등 38개 버그를 심고 Copilot·Claude·BugBot 세 도구를 동시에 돌렸습니다(dev.to, 38 Issues: Showdown between BugBot, Copilot and Claude). 1차 리뷰 결과는 이렇습니다.
- Copilot 34/38 (89.5%)
- Claude 32/38 (84.2%)
- BugBot 29/38 (76.3%)
보안 취약점은 세 도구 모두 강세였습니다. 차이는 '미묘한 영역'에서 났습니다. 코드 스멜, 잘못된 HTTP 상태 코드, CancellationToken 누락처럼 컴파일은 되지만 운영 환경에서 문제가 되는 항목들이죠. 숫자만 보면 Copilot이 우위지만, 중요한 건 탐지율 자체보다 각 도구가 '어떤 문제'에 강한가를 아는 것입니다.
모델마다 다른 '눈'
또 다른 실험에서는 Claude Code, Codex CLI, GPT-4, 그리고 인간 한 명이 동일한 bash 훅 코드(약 400줄)를 독립적으로 리뷰했습니다(dev.to, I Asked 4 AIs to Judge Each Other's Code). 결론부터 말하면, 네 평가자 모두 다른 버그를 잡았고, 다른 버그를 놓쳤습니다. 실제로 프로덕션을 터뜨린 이슈는 아무도 못 잡았고요.
- Claude Code: 레이스 컨디션, 미인용 변수 등 런타임 동작 기반 버그에 강했습니다. 단, 아키텍처 자체를 의심하지 않았습니다. '주어진 구조 안에서 최적화'하는 성향이죠.
- Codex CLI: 하드코딩된 경로 23개, 테스트 전략 부재, 일관성 없는 종료 코드를 짧고 날카롭게 집어냈습니다. 컨텍스트가 없어서 프로젝트 운영 현실을 몰랐던 게 약점.
- GPT-4: 보안 패턴과 POSIX 호환성 이슈를 포함해 가장 광범위하게 다뤘지만, 과도한 분량과 '일반론 위주' 피드백이 실무 적용성을 떨어뜨렸습니다.
- 인간: 코드를 읽지 못하지만, '게임이 이상하게 느껴진다'는 감각으로 사용자 경험 이슈를 잡아냈습니다.
이거 Claude한테 물어보니까 레이스 컨디션을 잡아줬는데, Codex는 하드코딩 경로를 잡아줬다는 식으로—각 모델이 다른 사각지대를 가집니다. 단일 도구에 의존하면 반드시 구멍이 생깁니다.
'코드를 읽지 않는' 개발—무모한가, 합리적인가
더 도발적인 흐름도 있습니다. Geeknews에서 화제가 된 '코드를 읽지 않는 것에 대한 옹호'입니다. OpenAI Harness Engineering 사례에서 엔지니어 3명이 Codex 에이전트로 100만 줄 코드를 생성해 수백 명이 쓰는 제품을 만들었고, 라인 단위 코드 리뷰에는 투자하지 않았습니다. 대신 집중한 것은 '하네스(harness)'—스펙, 테스트 인프라, 린터, 관측 체계입니다.
이게 무모하게 들릴 수 있지만, 핵심 논지는 명확합니다. 라인별 독해가 정확성을 보장하는 가장 효과적인 방법이 아닐 수 있다는 것. 대신 스펙 기반 워크플로우, 계층적 검증 시스템, 크로스 모델 세컨드 오피니언 리뷰로 보완합니다. 실제로 변경된 diff를 Codex CLI에 넘겨 다른 모델의 시각으로 교차 검증하는 방식은 앞서 실험에서 확인한 '모델마다 다른 눈'을 실무에 적용한 구조입니다.
물론 균형점은 있습니다. 보안에 민감한 서비스, 안전이 직결된 시스템, 중대한 아키텍처 결정에서는 인간 리뷰가 여전히 필요합니다. 항공의 'Children of the Magenta' 비유처럼—오토파일럿을 쓰되, 언제든 개입할 수 있는 능력을 유지해야 합니다.
AI 코드 어시스턴트 실무 운용 원칙
dev.to의 실무 가이드(An Engineer's Practical Manual for Using AI Code Assistants)는 이 흐름을 현장 언어로 정리해줍니다. 핵심만 추리면:
- AI는 '똑똑한 주니어'다 — 아키텍처 결정과 트레이드오프는 여전히 사람 몫. AI는 보일러플레이트, 반복 변환, 테스트 스캐폴딩에 탁월.
- 컨텍스트를 인코딩하라 — 기술 스택, 컨벤션, 비기능 요구사항을 매번 설명하지 말고 커스텀 인스트럭션으로 고정.
- "모르면 물어봐"를 허락하라 — 프롬프트 끝에 "갭이 있으면 질문해줘"를 붙이면 엉터리 코드 생성 전에 확인을 먼저 받을 수 있습니다.
- AI는 반드시 범위를 벗어난다 — 새 의존성 도입, 불필요한 전체 리팩토링을 사전 제약으로 막지 않으면 PR 하나가 아키텍처를 흔듭니다.
이거 자동화하면 우리가 더 중요한 일에 집중할 수 있어요—는 맞는 말이지만, 자동화 범위를 잘못 설정하면 오히려 기술 부채가 쌓입니다.
팀 리드 관점의 시사점
정리하면, AI 코드 리뷰 전략은 세 층위로 나눠 설계해야 합니다.
도구 선택: 단일 도구로 끝내지 마세요. 탐지율 차이가 있고, 모델마다 강점이 다릅니다. Copilot은 PR 통합 흐름에서 커버리지가 높고, Claude는 런타임 맥락 기반 버그에 강하며, BugBot은 Cursor 워크플로우와 연동이 자연스럽습니다. 크로스 모델 세컨드 오피니언을 CI 파이프라인에 넣는 것을 진지하게 고려해보세요.
리뷰 설계: AI 리뷰가 1차 필터라면, 인간 리뷰는 아키텍처 결정과 보안 민감 영역에 집중해야 합니다. 모든 줄을 사람이 읽는 것은 이제 비효율입니다. 팀원들에게 AI-First 마인드를 심어줘야 하는 이유가 바로 여기에 있습니다—AI 리뷰 결과를 해석하고 판단하는 능력이 새로운 핵심 역량입니다.
하네스 구축: 코드 품질은 리뷰 단계에서만 만들어지지 않습니다. 스펙, 테스트 커버리지, 정적 분석, 관측 체계가 갖춰진 하네스가 있어야 AI 생성 코드도 안전하게 흐릅니다.
코드는 점점 구현의 세부사항으로 이동하고 있습니다. 스펙, 아키텍처, 검증 레이어가 핵심 산출물로 부상하는 흐름—이건 선택의 문제가 아니라 방향의 문제입니다. AI가 생성해준 걸 기반으로 우리가 다듬는 협업 모델이 이미 실전에서 작동하고 있고, 그 모델을 팀 차원에서 얼마나 빨리 내재화하느냐가 다음 경쟁력을 결정할 겁니다.