1,200줄 PR, 4분 만에 Approve — 이게 리뷰인가요?
AI 코딩 어시스턴트가 몇 초 만에 모듈을 생성하는 시대입니다. 그런데 그 코드를 읽는 건 여전히 사람 속도예요. dev.to에 올라온 한 분석 글("LGTM: Are We Reviewing Code or Just Rubber Stamping It?")이 이 비대칭을 정면으로 짚었습니다. 1,200줄짜리 PR이 올라오면 CI 그린 확인하고, 4분 스크롤한 뒤 "LGTM" 찍고 넘어간다. 리뷰가 아니라 로깅이라는 거죠. CodeRabbit이 470개 오픈소스 PR을 분석한 데이터가 뼈아픕니다. AI 생성 코드는 전체 이슈가 1.7배, 로직·정확성 문제 75% 이상, 에러 핸들링 갭 2배, XSS 같은 보안 취약점은 2.74배나 높았습니다. 그런데 이 코드를 우리가 제대로 안 보고 머지하고 있다는 겁니다.
저는 이걸 '기술 부채 특이점(Tech Debt Singularity)'이라고 부르는 원문 표현에 깊이 공감합니다. 들어오는 코드 속도가 검증 속도를 영구적으로 초과하는 구조적 단절. 일시적 백로그가 아니라, 비대칭이 고착된 상태예요. 한 모듈은 팩토리 패턴, 다른 모듈은 DI, 또 다른 건 하드코딩 — 각각은 로컬에서 맞지만 합치면 미로가 됩니다. 6개월 뒤 신규 기능 하나 넣으려고 코드베이스 열면 "이건 누가 왜 이렇게?"가 셀 수 없이 쏟아지는 거죠.
'소프트웨어 엔지니어'라는 직함이 사라진다?
이 문제의 스케일을 더 키우는 전망이 있습니다. Claude Code 창시자 보리스 체르니는 Y Combinator 팟캐스트에서 "2026년부터 소프트웨어 엔지니어라는 직함이 사라지기 시작할 것"이라고 말했어요. 뉴스스페이스 보도에 따르면, 앤트로픽 내부 조사(132명 대상)에서 직원들은 Claude를 업무의 59%에 활용하며 생산성 50% 향상을 보고했고, 체르니 자신은 지난 2개월간 코드 100%를 Claude Code로 생성하며 하루 20개 이상 PR을 배포했습니다. PM도, 데이터 과학자도, 심지어 재무팀까지 코딩에 참여하는 '하이퍼 제너럴리스트' 팀이 이미 현실이라는 겁니다.
하루 20개 PR. 팀원 한 명이 이 속도로 코드를 쏟아내는데, 리뷰어는 여전히 사람입니다. 리뷰 부담 비율(Review Burden Ratio)이 무너지는 건 당연한 귀결이에요. 여기서 핵심 질문이 나옵니다. AI가 코드를 쓰는 시대에, 리뷰어의 역할은 무엇이어야 하는가?
리뷰어는 '코드 검수자'에서 '아키텍처 오케스트레이터'로
원문이 제안하는 리뷰 품질 프레임워크는 실전에서 즉시 적용할 만합니다. 세 가지 메트릭 — 리뷰 부담 비율(변경량·복잡도 vs. 리뷰 시간), 리뷰 커버리지(실제 확인한 코드 비율, 80% 미만이면 스키밍), 실질적 피드백까지의 시간(변수명 수정이 아닌 로직 피드백)을 추적하라는 거죠. 한 팀은 속도 40% 향상에 리뷰 깊이 60% 하락을 발견했습니다. 버그를 더 빨리 출하하고 있었던 겁니다.
그런데 저는 메트릭만으로는 부족하다고 봅니다. AI-First 팀에서 리뷰어의 진짜 역할은 코드 한 줄 한 줄 검수가 아니에요. "이 코드가 우리 아키텍처 맥락에 맞는가"를 판단하는 오케스트레이터 역할입니다. dev.to의 또 다른 글("Developing for AI: The New Paradigm of Application Architecture")이 이 방향을 잘 보여줍니다. AI가 작업할 수 있도록 컴포넌트를 '원자 단위(Atomic Unit)'로 격리하고, .agent/skills 폴더에 "이 프로젝트에서는 이렇게 한다"는 규칙을 문서화하면, AI가 생성한 코드가 아키텍처에서 이탈할 확률 자체가 줄어듭니다. 리뷰어가 1,200줄을 한 줄씩 읽을 필요 없이, 아키텍처 정합성과 엣지 케이스에 집중할 수 있는 구조를 만드는 거예요.
실전 도구도 나오고 있습니다. gwt라는 Git Worktree CLI 도구는 AI 코딩 워크플로우에 맞춰 설계됐어요. gwt feature/new-thing 한 줄이면 워크트리 생성, 설정 복사, Claude Code 자동 실행까지 끝납니다. PR 400줄 제한을 걸고(SmartBear/Cisco 연구에 따르면 400줄 넘으면 리뷰 효과 급락), AI에게 1,200줄 리팩토링을 세 개 원자적 PR로 분리하라고 시키고, 각각 격리된 워크트리에서 작업하는 흐름이 가능해지는 겁니다.
기술 근육이 녹는 문제, 외면할 수 없습니다
한 가지 경고를 덧붙여야 합니다. OpenAI 공동창업자 안드레이 카르파티는 2개월 만에 수동 코딩에서 AI 80% 의존으로 전환한 뒤 "수동 코딩 능력 퇴화(atrophy)"를 고백했습니다. 앤트로픽 내부 인터뷰에서도 27% 업무가 Claude 없이는 불가능하다고 답했고, 깊은 기술 습득 감소와 감독 역량 약화 우려가 나왔어요. 리뷰어가 "AI가 짠 거니까 괜찮겠지"라고 넘기는 순간, 검증 능력 자체가 사라지는 악순환에 빠집니다.
지금 팀에서 바꿔야 할 세 가지
정리하면, AI-First 팀에서 코드 리뷰와 개발자 역할을 재설계하려면 이 세 가지가 핵심입니다.
- 리뷰 메트릭을 속도가 아닌 깊이 중심으로 전환하세요. 리뷰 부담 비율, 커버리지, 실질적 피드백 시간을 추적하고, 수치가 무너지면 관리자에게 데이터로 보여주세요. "안전하게 리뷰할 수 없는 볼륨"이라는 신호입니다.
- 리뷰어를 '코드 검수자'가 아닌 '아키텍처 수호자'로 재정의하세요. AI 생성 코드의 문맥 적합성, 실패 모드, 기존 패턴과의 정합성을 판단하는 역할. 스킬 문서와 아키텍처 가이드를 AI가 참조할 수 있도록 정비하면, 리뷰 부담이 구조적으로 줄어듭니다.
- "지금 제대로 리뷰할 시간이 없다"를 말할 수 있는 문화를 만드세요. 러시된 승인보다 정직한 거절이 낫습니다. 리뷰어가 지속적으로 시간이 부족하다면, 그건 팀이 AI가 만들어내는 코드 볼륨에 비해 검증 리소스가 부족하다는 데이터입니다.
체르니의 전망대로 '소프트웨어 엔지니어' 직함이 사라질지는 아직 모릅니다. 하지만 확실한 건, 코드를 쓰는 사람의 가치는 떨어지고, 코드를 판단하는 사람의 가치는 올라간다는 겁니다. AI가 동료로 들어온 팀에서, 리뷰어의 역할을 다시 설계하는 건 선택이 아니라 생존의 문제입니다.