AI 가 대신 코드를 다 작성해 줬지만, 아무도 다시 제대로 살펴보려 하지 않는다.

저자: The Pragmatic Engineer

번역: TechFlow

TechFlow 가이드: AI 가 코드를 작성하는 속도는 점점 빨라지고 있지만, 코드를 검토하는 것은 여전히 사람입니다. 이 모순은 위기로 번지고 있습니다: 엔지니어들은 AI 가 생성한 PR 에 압도되어 대응하느라 지쳐 부주의하게 검토하거나, 아니면 AI 가 오류를 보고하지 않으면 그냥 승인해버립니다. 대형 기업들은 이에 대응하기 위해 자체 도구를 구축하고 있지만, 현재로서는 누구도 표준 답안을 가지고 있지 않습니다.

안녕하세요, 저는 Gergely 입니다. 이는 Pragmatic Engineer Newsletter 의 무료 보충 호입니다. 매호 저는 시니어 엔지니어 및 엔지니어링 리더의 관점에서 대형 기술 기업과 스타트업을 취재합니다. 오늘 우리는 과거 The Pulse 저널의 네 가지 주제 중 하나를 논의합니다. 정식 구독자들은 일주일 전에 이 기사를 받았습니다. 이 이메일이 전달된 것이라면, 여기서 구독할 수 있습니다.

저는 많은 엔지니어링 리더들이 가장 우려하는 사항이 지속적으로 증가하는 코드 검토 부하를 어떻게 처리할 것인지라고 듣습니다. 이 주제는 한동안 존재해 왔지만, 지금 이런 대화가 점점 더 많아지는 것 같습니다.

저에게 이는 올해 1 월에 시작되었습니다. 당시 Opus 4.5 와 GPT 5.4 가 대부분의 회사에서 더 많고 더 나은 코드를 작성하기 시작했습니다. 대략 그 시점부터 디렉터 레벨의 사람들이 소프트웨어 개발의 병목 현상이 코딩 단계에서 검토 단계로 이동하고 있다고 논의하기 시작했습니다.

AI 코드 검토 도구의 폭발적 증가

2 월 이후, 부하 증가에 대응하기 위해 AI 코드 검토 도구가 폭발적으로 성장했으며, CodeRabbit, Greptile, Qodo, SonarQube (지금에는 Gitar 도 있음) 와 같은 전용 AI 코드 검토 도구의 실험과 채택이 폭발적으로 증가했습니다. 또한 코딩 도구 자체에서 제공하는 도구들도 있습니다. 예를 들어 Claude Code review, Cursor review, GitHub Copilot review 가 있습니다. 그리고 이전에는 코드 검토에 관여하지 않았지만 코드베이스에 컨텍스트를 가지고 있던 도구들도 이 분야에 참여하고 있습니다. 예를 들어 Sentry 의 Seer AI reviews, Linear code reviews 가 있습니다.

대형 기업의 자체 내부 도구 구축: Uber 의 Code Inbox

대형 기업들은 코드 검토 경험을 개선하기 위해 내부 도구를 구축하고 있습니다. Uber 의 Code Inbox 가 그 사례입니다:

스마트 할당은 Code Inbox 내의 기능으로, 검토 프로세스를 진행하는 데 사용됩니다:

그림: Code Inbox 의 스마트 할당 (Smart assignment) 설정으로, 검토 프로세스 진행에 사용됩니다. 출처: The Pragmatic Engineer

또한 위험 프로필 기능이 있어 변경 사항의 영향을 평가하고 개발자에게 고위험 변경 사항에 특별히 주의하도록 장려합니다:

그림: Code Inbox 의 위험 프로필 (Risk Profiles) 기능으로, 코드 변경 위험을 추정하고 주목할 점을 알림합니다. 출처: The Pragmatic Engineer

우리는 Uber 가 AI 를 사용하여 소프트웨어 개발을 어떻게 하는지 보도한 바 있습니다. 그리고 Uber 뿐만 아니라: Cloudflare (AI Code Reviewer), Faire (Fairey), HubSpot (Sidekick) 및 많은 다른 회사들도 코드 검토 프로세스를 더 원활하게 만들기 위해 도구를 구축했습니다. 내부 구현이 통합 공급업체의 솔루션보다 효과적이라고 판단했기 때문입니다.

从「审查」转向「验证」

또 다른 방법은 코드를 검토하는 대신 어떻게 검증할지 생각하는 것입니다. 말하기는 쉽지만 실천하기는 어렵습니다. 이론적으로 철저한 테스트는 코드가 예상대로 작동하는지 검증할 수 있어야 합니다. 하지만 얼마나 많은 테스트가「철저한」것일까요? 우리가 말하는 테스트 유형은 무엇입니까? 통합 테스트와 엔드투엔드 테스트도 포함됩니까? 퍼즈 테스트는요? 형식적 방법은요? 새로운 테스트가 기능을 예상대로 커버하는지 어떻게 검증합니까? 우리는 이 모든 것을 관찰 가능성과 어떻게 연결합니까?

과도한 검토가 엔지니어들을 지치게 하고 있습니다

지나치게 철저한 코드 검토는 엔지니어들을 탈진하게 하고 검토 품질 저하로 이어집니다. 개발자들이 더 이상 다른 사람들이 코드 검토에 마음을 쏟지 못하는 것을 본다는 많은 소문을 들었습니다. AI 코드 검토에서 실질적인 의견이 없으면 그냥 승인해버립니다. 한편, 이전과 마찬가지로 코드 검토에 같은 에너지와 시간을 투자하는 개발자들은 자신에게 보내진 AI 쓰레기 PR 에 압도되었다고 느낍니다.

문제는 존재하지만, 해결책은 여전히 실험 단계입니다

문제는 존재하지만, 해결책은 여전히 실험처럼 느껴집니다.