AI는 사람이 검토하는 것보다 빠르게 코드를 작성합니다 — 진짜 병목은 리뷰가 되고 있습니다

본문

소프트웨어 개발에서 오랫동안 비용이 큰 작업은 코드를 작성하는 일이었습니다. 개발자는 기능을 구현하고, 예외 상황을 처리하고, 테스트를 작성하고, Pull Request를 준비하는 데 몇 시간에서 며칠을 사용했습니다. 하지만 Claude Code, GitHub Copilot, Cursor, Codex 같은 AI 코딩 에이전트가 등장하면서 이 구조가 바뀌고 있습니다. 이제는 하나의 작업 지시만으로 데이터베이스 변경, 미들웨어, API, UI, 테스트, 문서까지 짧은 시간 안에 생성할 수 있습니다.

문제는 코드 생성 속도가 빨라진 만큼 코드의 의미를 이해하고 검토하고 검증하는 속도는 빨라지지 않았다는 점입니다. 예를 들어 관리자 대시보드에 역할 기반 접근 제어(Role-Based Access Control)를 추가하는 작업에서, AI 에이전트가 27개 파일과 1,800줄의 코드를 몇 분 만에 변경할 수 있습니다. 그러나 해당 변경을 사람이 제대로 검토하는 데는 여전히 한 시간이 걸릴 수 있습니다. 생성(Generation)은 빨라졌지만 검증(Verification)은 느린 상태이며, AI가 하나의 병목을 제거하는 동시에 다른 병목을 만든다는 설명입니다.

코드 생성보다 어려워지는 코드 검증

이 문제는 단순한 가정에 그치지 않습니다. GitHub는 Copilot Code Review가 빌드, 테스트, 특정 검사를 실행하면서 더 깊이 분석할 수 있도록 기능을 확장하고 있습니다. GitHub는 코드 리뷰 과정에서 여러 전문 에이전트를 조합하는 방식도 실험했으며, 보고된 실험에서는 개발자가 심각도가 높은 리뷰 의견을 처리하는 비율이 47% 증가했다고 밝혔습니다. AI는 이제 코드를 작성하는 데서 그치지 않고, AI가 작성한 코드를 리뷰하고 수정 사항을 제안하며, 다시 직접 수정하는 역할까지 맡고 있습니다.

이 흐름은 다음과 같은 형태가 될 수 있습니다. 사람이 기능을 설명하면 AI가 구현하고, AI가 테스트를 작성한 뒤, 다른 AI가 구현을 리뷰하고, 문제를 수정하고, 다시 AI가 수정한 결과를 반영합니다. 마지막에 사람은 Approve 버튼을 누릅니다. 겉으로는 효율적인 과정처럼 보이지만, 이때 인간 개발자가 전체 과정에서 가장 적게 알고 있는 사람이 될 위험이 있습니다. 개발자가 직접 작성하지 않은 코드와 직접 설계하지 않은 테스트, 또 다른 AI 시스템이 만든 리뷰 결과를 승인할 수 있기 때문입니다. 모든 테스트가 통과하고 모든 상태가 녹색이어도 코드가 실제 요구사항에 맞는다는 보장은 없습니다.

테스트가 통과해도 비즈니스 규칙이 틀릴 수 있습니다

글은 워크스페이스를 영구 삭제할 수 있는 권한을 계정 소유자에게만 부여하는 사례를 제시합니다. AI가 DELETE /workspace/:id 엔드포인트를 만들고 테스트를 작성했으며, 테스트가 통과하고 AI 리뷰어도 문제를 발견하지 못했다고 가정합니다. 그러나 실제 규칙이 소유자(Owner)는 삭제할 수 있고, 관리자(Admin), 일반 멤버(Member), 정지된 계정(Suspended)은 삭제할 수 없어야 한다는 내용이었다면, 구현과 테스트가 서로 일치하더라도 전체 결과는 잘못될 수 있습니다.

핵심적인 구분은 AI가 코드가 자신의 해석과 일치하는지를 확인할 수는 있지만, 그 해석이 현실의 요구사항과 일치하는지까지 증명할 수는 없다는 점입니다. 요구사항을 잘못 이해한 상태에서는 구현, 테스트, 리뷰가 모두 같은 방향으로 맞아떨어지면서도 실제 비즈니스 규칙을 위반할 수 있습니다. 따라서 요구사항과 권한 경계, 보안 규칙을 정의하는 일은 여전히 사람의 판단이 필요한 영역입니다.

AI 기술 부채와 유지보수 문제

전통적인 기술 부채는 개발자가 지름길을 택한다는 사실을 알고도 임시적인 구현을 남길 때 발생하는 경우가 많았습니다. AI는 여기에 다른 형태의 위험을 추가합니다. 현재는 동작하지만 팀 구성원 누구도 제대로 이해하지 못하는 코드가 빠르게 쌓일 수 있다는 점입니다. 1년 동안 기능, 리팩터링, 마이그레이션, 테스트, 문서를 모두 적극적으로 AI로 생성한 코드베이스에서 장애가 발생하면, 서로 상호작용하는 여러 구성 요소를 깊이 이해하고 디버깅할 사람이 없을 수 있습니다.

글은 Sonar가 이러한 위험을 AI 기술 부채(AI Technical Debt)로 설명한다고 소개합니다. 이는 AI가 생성한 코드가 팀이 검증하고 이해하고 유지보수할 수 있는 속도보다 빠르게 유입되면서 발생하는 재작업과 위험을 뜻합니다. 코드 생성량이 늘었다고 해서 생산성이 자동으로 높아지는 것은 아닙니다. 더 많은 코드를 만들어내는 동시에 미래의 디버깅과 유지보수 작업을 더 빠르게 쌓고 있을 수도 있습니다.

기존에는 완료한 티켓 수, 병합된 Pull Request 수, 출시한 기능 수, 변경된 코드 줄 수, 배포 빈도 같은 지표로 생산성을 측정했습니다. 하지만 AI를 사용하면 이런 숫자는 크게 증가할 수 있습니다. 예를 들어 AI 도입 전 주당 10개의 PR과 2개의 버그가 있었고 개발자들이 변경 사항을 이해하고 있었다면, 도입 후 주당 35개의 PR과 11개의 버그가 발생하며 팀이 변경 사항의 절반을 이해하지 못하는 상황도 가능합니다. 이 경우 생산성이 실제로 향상됐다고 보기 어렵습니다. 글은 생산성을 ‘얼마나 많은 검증 가능하고 유지보수 가능한 가치를 출시했는가’로 측정해야 한다고 제안합니다.

리뷰는 코드 줄이기 전에 문제와 위험을 확인해야 합니다

AI가 생성한 대규모 변경을 검토할 때는 모든 줄을 처음부터 동일한 깊이로 읽기보다 먼저 다섯 가지 질문을 확인하는 접근이 제시됩니다. 첫째, 해결하려는 문제가 무엇인지 확인해야 합니다. 에이전트가 요구사항을 오해했다면 그 이후의 구현이 기술적으로 올바르더라도 쓸모없을 수 있습니다. 둘째, 이것이 문제를 해결하는 올바른 방식인지 봐야 합니다. AI는 동작하는 코드를 만들 수 있지만 불필요한 의존성, 추상화, 데이터베이스 테이블, 백그라운드 작업, 서비스와 복잡성을 추가할 수도 있습니다. 동작하는 코드가 항상 좋은 아키텍처인 것은 아닙니다.

셋째, 변경으로 무엇이 깨질 수 있는지 확인해야 합니다. 인증(Authentication), 권한 부여(Authorization), 결제, 마이그레이션, 운영 데이터, 캐시, 동시성, 인프라 관련 코드는 특히 주의해야 합니다. 20줄의 인증 변경이 500줄의 UI 변경보다 더 많은 검토를 요구할 수 있습니다. 넷째, 실패하면 어떤 일이 일어나는지 살펴야 합니다. API 타임아웃, 데이터베이스 장애, 동시 요청, 사용자의 새로고침, 결제 성공 후 Webhook 실패, AI API의 잘못된 응답, 비인가 사용자의 직접적인 엔드포인트 호출 같은 상황을 확인해야 합니다. AI는 정상 경로(Happy Path)에 강할 수 있지만, 운영 시스템은 비정상 경로에서도 동작해야 합니다.

다섯째, 6개월 뒤 다른 개발자가 이 코드를 이해할 수 있는지 물어야 합니다. AI가 만든 영리한 추상화가 현재 20줄을 줄여주더라도 나중에 디버깅 시간을 크게 늘릴 수 있습니다. 따라서 단순한 코드와 명확한 구조는 여전히 중요한 가치로 남습니다.

인간의 역할은 구현에서 정의와 판단으로 이동합니다

글은 AI가 개발자를 덜 중요하게 만든다고 주장하지 않습니다. 대신 책임의 위치가 바뀐다고 설명합니다. 기존 흐름이 이해, 설계, 작성, 테스트, 리뷰였다면, 새로운 흐름은 정의(Define), 제약 설정(Constrain), 위임(Delegate), 검증(Verify), 결정 리뷰(Review Decisions), 승인(Approve)의 순서에 가까워질 수 있습니다. AI는 더 많은 구현을 담당하지만, 인간은 요구사항, 아키텍처, 보안 경계, 비즈니스 규칙, 실패 모드, 트레이드오프, 최종 책임을 맡게 됩니다.

AI로 AI가 생성한 코드를 리뷰하는 방식 자체가 항상 위험한 것은 아닙니다. 한 에이전트가 구현을 생성하고 다른 에이전트가 보안 취약점, 누락된 테스트, 경쟁 조건(Race Condition), 성능 문제, 엣지 케이스를 찾도록 할 수 있습니다. 여기에 정적 분석(Static Analysis), 타입 검사, 단위 테스트, 통합 테스트, 의존성 검사를 자동으로 실행하고, 마지막으로 사람이 전체 결과를 평가하는 흐름을 구성할 수 있습니다. 중요한 점은 AI 리뷰가 좋아져도 인간 리뷰가 사라져서는 안 된다는 것입니다. 인간의 리뷰는 모든 줄을 무작정 읽는 방식에서 벗어나 전체 방향과 결정, 위험에 더 집중하는 방식으로 바뀌어야 합니다.

결국 핵심 질문은 AI가 코드를 얼마나 많이 생성할 수 있는지가 아니라, 생성된 코드를 얼마나 빠르게 신뢰할 수 있는 코드로 바꿀 수 있는지입니다. 이를 위해서는 더 나은 테스트, 명확한 사양(Specification), 관측 가능성(Observability), 보안, 리뷰 도구, 아키텍처와 함께 승인하는 시스템을 이해하는 개발자가 필요합니다. AI가 커피를 마시기도 전에 수천 줄을 작성할 수 있는 시대에는 코드를 작성하는 일이 가장 어려운 작업이 아닐 수 있습니다. 실제 운영 환경에 도달할 자격이 있는 코드가 무엇인지 판단하는 일이 더 어려운 작업이 됩니다.

원문: dev.to / 번역·요약: Trawling