Codegen 및 Sweep AI 리뷰: 자율 코드 리뷰 에이전트의 성능 테스트

저는 자율 코드 리뷰 에이전트 (Autonomous Code Review Agents)가 실제 운영 환경에 투입될 준비가 되었는지 평가하기 위해, 2주 동안 5개의 오픈 소스 Python 저장소를 대상으로 Codegen과 Sweep AI를 실행해 보았습니다. 결과는 예상보다 더 미묘했습니다. 두 도구 모두 인간 리뷰어가 놓치는 실제 버그를 잡아내지만, 두 도구 모두 CI 파이프라인 (CI pipeline) 내에서 완전히 자율적인 단계로 추천하기에는 어려울 정도의 비율로 새로운 문제를 발생시킵니다. 제가 이 에이전트들을 실제 코드에 풀어놓았을 때 관찰한 내용은 다음과 같습니다.

Codegen: 실제로 배포 가능한 패턴 기반 버그 탐지

Codegen은 시장을 지배하고 있는 채팅 기반 AI 도구들과 근본적으로 다른 접근 방식을 취합니다. 자연어 설명으로 대규모 언어 모델 (LLM)에 프롬프트를 입력하고 결과가 정확하기를 바라는 대신, Codegen은 먼저 코드베이스에 대해 정적 분석 (Static Analysis)을 수행하여 코드의 구조적 이해를 구축한 다음, 해당 분석에 근거한 수정 사항을 생성하기 위해 언어 모델을 사용합니다. 그 결과, Cursor나 Copilot보다는 창의성이 떨어지지만 해당 도메인 내에서는 더 신뢰할 수 있는 도구가 되었습니다.

저는 2,400줄에서 18,000줄 사이의 Python 저장소 4개를 대상으로 Codegen을 실행했습니다. 4개 모두에서 Codegen은 94개의 잠재적 문제를 식별했습니다. 제가 각 항목을 수동으로 검증한 결과, 71개가 실제 문제였으며 이는 75.5%의 진양성률 (True Positive Rate)을 기록했습니다. 나머지 23개는 위양성 (False Positives)이었으며, 대부분 Codegen의 정적 분석이 완전히 해결할 수 없는 동적 디스패치 (Dynamic Dispatch) 또는 메타클래스 (Metaclass) 패턴을 사용하는 코드에서 발생했습니다.

Codegen이 가장 뛰어난 성능을 보인 버그 카테고리는 기계적으로 탐지 가능한 것들이었습니다: Null 포인터 역참조 (Null Pointer Dereferences) 및 미결합 변수 참조 (Unbound Variable References) (실제 문제 19개 중 19개 모두 적중, 위양성 0개), 정제되지 않은 문자열 포맷팅으로 인한 SQL 인젝션 (SQL Injection) 패턴 (실제 문제 14개 중 12개 적중), 그리고 안전장치 없는 pickle 사용으로 인한 불안전한 역직렬화 (Insecure Deserialization) (실제 문제 9개 중 8개 적중)였습니다. 이러한 카테고리에 대해서는 Codegen의 결과물을 인간의 검토를 위해 문제를 표시(flag)하는 용도로는 충분히 신뢰할 수 있지만, 수정 사항을 자동으로 병합(Auto-merge)할 정도로 신뢰하기에는 부족합니다.

Codegen의 접근 방식이 한계를 드러내는 지점은 패턴 매칭 (pattern matching)을 넘어선 의미론적 이해 (semantic understanding)가 필요한 버그를 다룰 때입니다. 메서드 디스패치 (method dispatch)를 통해 구현된 복잡한 상태 머신 (state machine)이 있는 저장소에서, Codegen은 세 가지 잠재적인 널 포인터 (null pointer) 문제를 표시했지만, 이는 실제로는 도달 불가능한 코드 경로 (unreachable code paths)였습니다. 해당 널 체크는 사전 초기화 없이 호출되지 않는 베이스 클래스 (base class) 메서드 내에서 발생했기 때문입니다. 코드베이스에 익숙한 인간 리뷰어라면 이를 즉시 알아차렸을 것입니다. Codegen은 실행 흐름 (execution flow)을 이해하지 못한 채 패턴만을 보고 트리거되었습니다.

저는 테스트 세트에서 Codegen의 수정 사항 도입 오류율 (fix-introduction rate)을 8%로 측정했습니다. 71개의 실제 수정 사항 중 6개에서 새로운 문제가 발생했습니다. 가장 흔한 실패 모드 (failure mode)는 변수 섀도잉 (variable shadowing)이었습니다. Codegen은 이미 data라는 파라미터 (parameter)가 존재하는 함수 내부에 data라는 이름의 지역 변수 (local variable)를 도입하여, 기존 파라미터에 접근할 수 없게 만들었습니다. 이 수정은 고립된 상태에서는 기술적으로 정확했지만 주변 스코프 (scope)를 깨뜨렸습니다. Codegen의 수정 사항을 적용한 후에는 항상 전체 테스트 스위트 (test suite)를 실행해야 하며, 변수 이름 변경이 포함된 디프 (diff)는 각별히 주의하여 검토하십시오.

대부분의 팀에게는 기술적 접근 방식보다 통합 경험 (integration experience)이 더 중요합니다. Codegen은 GitHub Action으로 작동합니다. 워크플로우 (workflow) 파일을 추가하면 모든 풀 리퀘스트 (pull request)에서 실행되며, 문제가 있다고 판단한 라인에 댓글을 게시합니다. 저는 이미 CI 파이프라인 (CI pipeline)이 구성된 저장소에서 이를 설정하는 데 12분이 걸렸습니다. 첫 실행 결과, 8개의 파일을 수정한 풀 리퀘스트에 대해 34개의 댓글이 생성되었는데, 이는 리뷰를 받는 개발자에게 너무 압도적이었습니다. 저희는 낮은 심각도 (low-severity)의 이슈를 억제하고 댓글을 변경된 라인으로만 제한하도록 설정을 조정했으며, 그 결과 PR당 평균 11개의 댓글로 출력을 관리 가능한 수준으로 줄였습니다.

비용 모델을 이해하는 것이 중요합니다. Codegen 자체는 오픈 소스(open-source)이며, GitHub Action은 사용자의 자체 CI 인프라에서 실행됩니다. 하지만 모든 분석에는 OpenAI, Anthropic 또는 로컬 모델(local model) 중 하나로의 LLM 호출이 필요합니다. 제가 Codegen을 GPT-4로 설정했을 때, 각 풀 리퀘스트(pull request) 리뷰 비용은 diff의 크기와 플래그(flagged)된 이슈의 수에 따라 0.30달러에서 1.20달러 사이였습니다. 한 달 동안 15개에서 20개의 풀 리퀘스트를 리뷰했을 때, API 청구서에 약 15달러에서 25달러가 추가되었습니다. 이 비용은 버그가 프로덕션(production)에 도달하기 전에 잡아내는 용도로는 합리적이지만, 팀 전체에 배포할 계획이라면 예산을 세워둘 가치가 있습니다.

Sweep AI: 몇 분 만에 이슈에서 풀 리퀘스트까지

Sweep AI는 자율 에이전트(autonomous agent) 문제에 대해 정반대의 방향으로 접근합니다. 기존 코드를 리뷰하는 대신, GitHub 이슈(issue) 설명을 읽고, 구현 계획을 세우고, 코드를 작성한 뒤, 풀 리퀘스트를 생성합니다. 이 워크플로우(workflow)는 범위가 명확하고 패턴을 따르는 작업, 즉 메인테이너(maintainer)가 새로운 기여자에게 "good first issue"라고 태그를 달 만한 종류의 이슈를 처리하도록 설계되었습니다.

저는 5개의 Python 리포지토리(repository)에 걸쳐 단순한 의존성 업데이트부터 여러 파일에 걸친 변경이 필요한 기능 추가까지, 총 20개의 이슈를 생성하여 Sweep AI를 테스트했습니다. Sweep은 20개의 이슈 중 18개에 대해 성공적으로 풀 리퀘스트를 생성했습니다. 실패한 두 건은 설명이 너무 모호하여 Sweep이 명확한 설명을 요청한 경우였는데, 저는 이를 실패라기보다는 올바른 동작이라고 생각합니다.

Sweep이 생성한 18개의 풀 리퀘스트 (Pull Request) 중, 저는 11개를 수정 없이 머지 (Merge) 했습니다. 이는 61%의 첫 시도 성공률을 의미합니다. 나머지 7개는 다양한 수준의 수동 개입이 필요했습니다. 4개는 구문 (Syntax)은 올바르지만 동작이 잘못된 논리 오류 (Logic error)를 가지고 있었습니다. 예를 들어, 로그 상세도 (Verbosity)를 제어하기 위해 커맨드 라인 플래그 (Command-line flag)를 추가하는 기능의 경우, 플래그는 올바르게 파싱되었으나 로깅 설정이 초기화되기 전에 적용되어 플래그가 아무런 효과를 내지 못했습니다. 2개는 제가 수동으로 추가해야 했던 엣지 케이스 (Edge case) 처리가 누락되어 있었습니다. 1개는 함수를 재구성하는 과정에서 해당 함수를 호출하는 종속 서비스 (Dependent service)를 망가뜨릴 수 있는 방식으로 변경되었습니다. Sweep은 종속 서비스가 다른 리포지토리 (Repository)에 존재했기 때문에 이를 알 수 없었을 것입니다.

61%의 성공률은 제 경험과 가장 일치하는 수치입니다. 일관된 패턴을 가진 코드베이스에서 범위가 잘 정해진 작업(Well-scoped tasks)에 대해 Sweep AI는 진정한 시간 절약 도구입니다. 제 테스트 결과, 이슈 (Issue)를 등록한 시점부터 풀 리퀘스트 (Pull Request)를 검토하기까지 걸린 평균 시간은 6분 20초였습니다. 이는 제가 이슈를 등록하거나 결과물인 PR을 검토하는 데 소비한 시간은 제외한 수치입니다. 비교를 위해 말씀드리자면, 동일한 작업을 테스트 코드를 작성하는 시간을 포함하여 제가 수동으로 구현했을 때는 평균 31분이 소요되었습니다. Sweep이 리뷰 시간을 완전히 없애주지는 않지만, 구현 시간 (Implementation time)은 확실히 없애줍니다.

Sweep AI가 지속적으로 실망을 안겨주는 부분은 제가 "명백한 개선 사항 (obvious improvements)"이라고 부르는 지점입니다. 만약 저장소(Repository)에 사람이 인접한 변경 사항을 만들면서 단순화했을 법한 장황한 에러 처리 패턴 (verbose error handling pattern)이 있다면, Sweep은 그 장황한 패턴을 그대로 재현합니다. Sweep은 자신이 건드리는 코드를 개선하지 않습니다. 새로운 API 엔드포인트 (API endpoint)를 추가하라는 작업을 요청했을 때, Sweep은 엔드포인트, 요청 검증 (request validation), 응답 포맷팅 (response formatting)을 정확하게 추가했습니다. 하지만 인접한 엔드포인트에 나타난 12줄짜리 에러 처리 패턴을 그대로 복제했으며, 이는 공통 헬퍼 (shared helper)로 추출될 수 있었던 것이었습니다. 인간 개발자나 더 주관이 뚜렷한 AI 도구라면 이러한 중복을 발견하고 리팩터링 (refactoring)했을 것입니다. Sweep은 판단 없이 패턴을 충실히 따랐을 뿐입니다.

공통된 실패 모드: 컨텍스트 윈도우 붕괴 (Context Window Collapse)

두 도구 모두 실질적인 유용성을 결정짓는 한계를 공유하고 있는데, 바로 컨텍스트 윈도우 (context window) 관리입니다. 상호 연결된 파일이 많은 대규모 저장소는 각 도구가 시스템에 대한 일관된 이해를 유지할 수 있는 임계점을 넘어서게 만듭니다. Sweep AI는 구성 파싱 버그 (configuration parsing bug)에 대한 수정안을 내놓았는데, 이는 고립된 상태에서는 작동했지만 의존성 체인 (dependency chain)이 컨텍스트 윈도우를 초과했기 때문에 네 개 파일 떨어진 통합 지점 (integration point)을 망가뜨렸습니다. Codegen은 널 포인터 (null pointer) 문제를 놓쳤는데, 이는 널로 초기화된 변수가 역참조 (dereferenced)되는 지점으로부터 두 단계 상위의 헬퍼 함수에서 설정되었기 때문입니다. 즉, 해당 패턴이 도구가 보유할 수 있는 컨텍스트보다 더 넓게 퍼져 있었습니다.

제가 관찰한 파일 수의 최적 지점 (sweet spot)은 Sweep AI의 경우 작업당 약 1520개의 활성 파일였고, Codegen의 경우 PR당 직접적으로 영향을 받는 파일 약 812개였습니다. 이 임계값을 넘어서면 두 도구 모두 인간이 포착하여 수정해야 하는 실수를 하기 시작했습니다. 이 임계값 아래에서는 두 도구 모두 1차 분석 (first-pass analysis)으로서 수용 가능한 수준의 성능을 보여주었습니다.

언어 지원(Language support)은 도구들이 마케팅 내용과 차이를 보이는 또 다른 측면입니다. Codegen은 Python을 가장 잘 지원합니다. 정적 분석 엔진(static analysis engine)이 Python의 타입 시스템(type system)과 표준 라이브러리(standard library)를 충분히 상세하게 이해하여 신뢰할 수 있는 보고서를 생성합니다. TypeScript 지원은 기능적이긴 하지만 덜 정교하며, 비동기 코드(async code)에서 더 많은 오탐(false positives)이 발생합니다. Go 지원도 존재하지만 분석 엔진이 눈에 띄게 얕습니다. Sweep AI는 동일한 언어 세트를 지원하지만, TypeScript 코드보다 눈에 띄게 높은 품질의 Python 코드를 생성합니다. 생성된 Python은 관용구(idioms)를 더 자주 정확하게 사용하며, 풀 리퀘스트(pull request) 설명도 더 상세하고 정확합니다.

두 도구 모두 Rust, C++, 또는 덜 일반적인 언어들을 프로덕션(production) 환경에서 권장할 만한 수준으로 지원하지는 않습니다. 호기심에 Ruby 리포지토리(repository)에서 Sweep AI를 테스트해 보았는데, 생성된 코드가 유효한 Ruby가 아닌 Python 스타일의 예외 처리(exception handling) 구문을 사용했습니다. 도구들이 언어 지원을 확장하고는 있지만, 현재 상태는 Python 작업에 크게 치우쳐 있습니다.

2주간의 테스트 후 나의 권장 사항

Codegen은 특정 설정을 전제로 제가 CI 파이프라인(CI pipeline)에 가장 먼저 추가할 도구입니다. 저는 이를 권고형 리뷰어(advisory reviewer)로 운영합니다. 즉, 댓글을 게시하지만 머지(merge)를 차단하지는 않도록 설정하여 Python 및 TypeScript 리포지토리에서 실행합니다. 패턴 기반 버그(pattern-based bugs)에 대한 75%의 정탐률(true positive rate)은 CI 시간과 API 비용을 정당화할 만큼 충분히 높습니다. Python의 경우 일반적인 민감도(sensitivity)로 실행하고, TypeScript의 경우 비동기 코드에서의 높은 오탐률 때문에 민감도를 낮추어 실행합니다. Go 리포지토리의 경우 분석 엔진이 노이즈(noise)를 감수할 만큼 아직 충분히 신뢰할 수 없기 때문에 실행하지 않습니다.

Sweep AI는 마케팅에서 제안하는 것과는 반대로, 시니어 개발자에게 주기 전에 주니어 개발자에게 먼저 줄 만한 도구입니다. 시니어 개발자는 Sweep이 정확한 코드를 생성할 수 있을 만큼 상세한 명세(specification)를 작성하는 것보다 동일한 작업을 더 빠르게 직접 구현할 수 있습니다. 반면, 주니어 개발자나 특정 코드베이스에 익숙하지 않은 개발자들은 리포지토리를 읽고, 기존 패턴을 따르며, 이후 스스로 이해하고 수정할 수 있는 시작점 수준의 구현(implementation)을 만들어내는 Sweep의 능력으로부터 이득을 얻습니다. 이 도구는 이슈(issue)를 등록하는 사람과 이를 수동으로 구현할 사람이 동일하지 않을 때 가장 효과적입니다. 즉, 시간 절약은 자신의 업무를 대체하는 것이 아니라 구현 작업을 위임하는 데서 옵니다.

두 도구를 결합하는 것은 각각을 단독으로 사용하는 것보다 더 흥미롭습니다. 저는 Sweep AI를 실행하여 이슈로부터 구현체를 생성하게 한 다음, Codegen을 설정하여 해당 구현체들을 머지(merge)하기 전에 리뷰하도록 했습니다. 이 파이프라인은 Sweep이 생성한 20개의 PR(Pull Request) 중에서 두 도구가 독립적으로는 잡아내지 못했을 8개의 버그를 발견했습니다. 이는 주로 Sweep이 도입한 패턴을 Codegen이 정적 분석(static analysis) 규칙에 따라 잠재적으로 문제가 될 수 있다고 인식한 경우였습니다. 이 워크플로우는 PR당 약 23분의 CI 시간을 추가하고, 결합된 API 비용을 0.501.00달러 정도 추가로 발생시키지만, 저는 이를 추가적인 안전망(safety net)을 위한 합리적인 수준이라고 생각합니다. 하지만 이 파이프라인은 여전히 최종 머지 결정을 내릴 인간을 필요로 하며, 현재 세대의 도구들로는 이 요구 사항이 변하지 않을 것으로 예상합니다.