AI Sparkup

최신 AI 쉽게 깊게 따라잡기⚡

코드 리뷰가 죽어가고 있다, AI 시대 개발 워크플로우의 구조적 전환

AI가 코드를 쓰기 시작한 뒤, 개발팀에 이상한 일이 벌어졌습니다. 코드는 더 빨리, 더 많이 나오는데 — 리뷰는 오히려 더 느려진 겁니다.

사진 출처: Latent.Space / Aviator

AI 코딩 도구를 적극 도입한 팀들은 완료하는 작업이 21% 늘고 머지하는 PR이 98% 증가했지만, PR 리뷰 시간은 91% 늘었습니다. 1만 명 이상의 개발자 데이터에서 나온 수치입니다. 코드를 더 빠르게 만들었더니, 리뷰가 새로운 병목이 된 겁니다.

Aviator의 CEO Ankit Jain은 Latent.Space에 기고한 글에서 이 구조적 모순을 짚으며 결론을 내립니다. 코드 리뷰라는 관행 자체가 한계에 부딪혔다고.

출처: How to Kill the Code Review – Latent.Space

코드 리뷰가 원래부터 완벽하지 않았다

코드 리뷰가 표준 관행이 된 건 2012~2014년 무렵의 일입니다. 그전에도 소프트웨어는 만들어졌고 출시됐습니다. 리뷰가 있어도 버그는 나왔고, 그래서 우리는 feature flag, 점진적 롤아웃, 즉각 롤백 같은 안전망을 쌓아왔습니다. 리뷰 하나로 품질을 보장한다는 생각은 애초에 환상이었다는 거죠.

그런데 AI가 등장하면서 이 환상이 더 빨리 깨지고 있습니다. 개발자들은 AI가 생성한 코드를 리뷰하는 게 동료 코드보다 더 힘들다고 말합니다. 500줄짜리 diff를 훑어보는 건 이미 사람이 감당하기 어려운 일인데, 그 양이 기하급수적으로 늘어나고 있습니다.

인간의 개입 시점을 앞으로 당기기

Jain이 제안하는 핵심은 간단합니다. 인간이 판단을 내리는 위치를 바꾸자는 것입니다. 코드가 완성된 뒤 리뷰하는 게 아니라, 코드가 만들어지기 전에 스펙을 검토하는 방식으로.

이 구조에서 스펙이 진짜 소스가 됩니다. 코드는 스펙의 산출물일 뿐이고, 인간이 해야 할 질문은 “이 코드가 올바르게 작성됐는가”가 아니라 “우리가 올바른 문제를 올바른 방식으로 정의했는가”로 바뀝니다.

여기서 BDD(행동 주도 개발)가 다시 주목을 받습니다. BDD는 원래 좋은 아이디어였지만 코드도 직접 써야 하는 상황에서는 스펙 작성이 부가 작업처럼 느껴졌습니다. AI 에이전트 환경에서는 방정식이 뒤집힙니다. 스펙이 가장 중요한 작업물이 되고, 코드는 에이전트가 알아서 만들어냅니다. 인간이 작성한 인수 조건을 머신이 검증하는 구조입니다.

코드를 안 읽어도 되게 만드는 검증 계층

리뷰를 없애려면 그 자리를 채울 무언가가 필요합니다. Jain은 여러 계층의 자동화 검증을 제안합니다.

에이전트는 자기 검증을 믿을 수 없습니다. “이 코드가 작동하나요?”라고 물으면 잘못된 코드를 앞에 두고도 자신 있게 작동한다고 답할 수 있거든요. 대신 “이걸 검증하는 스크립트를 작성하세요”라고 요청하면 판단이 아닌 artifact가 나옵니다. 코딩 가이드라인, 조직 불변 규칙, 도메인 계약, 인수 조건을 각각의 계층으로 쌓고, 각 계층은 pass/fail만 뱉는 결정론적 도구로 구성합니다.

에이전트를 여러 개 경쟁시키는 방식도 유효합니다. 하나의 에이전트가 완벽하길 기대하는 대신, 세 에이전트가 같은 문제를 다르게 풀게 한 뒤 검증 단계를 가장 많이 통과한 결과물을 선택합니다. 에이전트 비용이 내려간 지금, 이런 옵션은 현실적인 전략이 됐습니다.

권한 범위를 좁히는 것도 중요합니다. 특정 파일의 버그를 고치는 에이전트에게 전체 코드베이스 접근권을 줄 필요가 없습니다. 인증 로직이나 데이터베이스 스키마 변경처럼 민감한 영역은 자동으로 인간 검토를 트리거하도록 설계할 수 있습니다.

리뷰가 사라진 자리에 남는 것

이 모든 주장이 불편하게 느껴진다면, 그건 자연스러운 반응입니다. AI가 한 번 이상한 코드를 냈을 때 직접 잡아낸 경험이 있다면 “그러니까 항상 확인해야 해”라는 직관이 작동합니다. Jain도 그 심리를 이해합니다. 다만 그 직관이 유효했던 건 검증이 인간 규모 안에 있을 때의 이야기라고 말합니다.

코드 리뷰가 품질 게이트로서 사망 선고를 받았다는 주장은 아직 논쟁 중입니다. Latent.Space 편집진조차 이 글에 동의하지 않는다고 명시하며 실었습니다. 하지만 PR 수가 이미 두 배가 됐고, 앞으로도 계속 늘어날 환경에서 이 질문은 결국 모든 팀이 직면하게 될 겁니다. 스펙 중심 개발, BDD, 자동화 검증 계층의 구체적인 설계 방식은 원문에서 더 자세히 다루고 있습니다.

참고자료:


AI Sparkup 구독하기

최신 게시물 요약과 더 심층적인 정보를 이메일로 받아 보세요! (무료)

Comments

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다