코딩 에이전트를 늘리기 전에 ‘리뷰 공장’부터 설계해야 하는 이유

코딩 에이전트가 여러 개 동시에 코드를 만들면 개발 속도도 그만큼 빨라질 것처럼 보인다. 그러나 사람이 모든 변경을 같은 깊이로 읽고 판단해야 한다면 병목은 사라지지 않는다. 코드 생성량만 늘고, 검토 대기열은 오히려 길어질 수 있다.

Vercel은 2026년 8월 AI SDK 저장소를 운영하기 위해 만든 ai-sdk-factory 사례를 공개했다. 이 시스템은 이슈 분류, 분석, 구현, 리뷰, 백포트를 서로 다른 에이전트에게 맡기지만, 모든 병합은 사람이 승인한다. 공개 4주 시점에 Vercel은 팩토리가 주간 병합 PR의 25~35%를 작성하고 이슈의 70~80%를 닫았다고 보고했다.

숫자보다 더 유용한 부분은 구조다. 이 사례는 “사람을 빼는 자동화”가 아니라 사람이 판단해야 할 단위와 증거를 미리 정리하는 자동화에 가깝다. 작은 팀이 그대로 복제할 필요는 없지만, 코딩 에이전트를 운영할 때 어디를 분리하고 무엇을 검증하며 어떤 권한을 남겨야 하는지 구체적인 설계 원칙을 얻을 수 있다.

에이전트 수가 아니라 사람의 주의력이 병목이다

코딩 에이전트가 만든 변경도 결국 누군가가 읽어야 한다. 하나의 범용 에이전트가 이슈를 이해하고 코드를 고치고 스스로 검토한 뒤 PR을 열더라도, 리뷰어 입장에서는 다음 질문이 남는다.

• 요청이 프로젝트 방향과 맞는가?
• 실제 결함이나 기능 공백이 재현됐는가?
• 변경 범위가 요구사항보다 넓어지지 않았는가?
• 테스트는 통과했지만 호환성이나 보안 위험이 남지 않았는가?
• 어떤 근거를 믿고 리뷰 깊이를 줄여도 되는가?

Vercel이 선택한 답은 더 많은 코드를 생성하는 단일 에이전트가 아니었다. 작업을 분류, 분석, 구현, 리뷰, 백포트처럼 검토 가능한 단위로 나누고, 각 단계가 다음 단계와 사람에게 증거를 넘기는 파이프라인이었다.

이 차이는 중요하다. 병목이 구현 속도라면 더 강한 모델이나 병렬 실행이 도움이 된다. 병목이 검토라면 필요한 것은 작은 diff, 재현 가능한 증거, 위험도에 맞는 리뷰 경로다. 자동화 목표도 “사람이 읽지 않게 하기”보다 “사람이 어디를 깊게 읽어야 하는지 빠르게 알게 하기”로 바뀐다.

범용 에이전트 하나보다 단계별 책임을 나눈다

AI SDK 팩토리는 한 에이전트에 모든 기술을 넣는 방식을 검토했지만, 유지보수와 문제 해결 부담 때문에 작업별 에이전트를 선택했다고 설명한다. 각 에이전트는 고유한 프롬프트, 문맥, 평가를 갖고 한 가지 책임을 맡는다.

공개된 흐름은 다음과 같다.

1. 분류: 이슈나 PR을 버그, 기능, 문서 작업 등으로 분류하고 근거를 남긴다.
2. 분석: 요청을 그대로 믿지 않고 재현용 probe를 만들어 실제 공백이나 결함을 확인한다.
3. 구현: 분석 단계의 명세를 코드와 테스트로 옮긴다.
4. 자동 리뷰: 구현 충족도와 부작용, 성능, 하위 호환성 위험을 평가한다.
5. 사람 리뷰와 병합: 증거 사슬과 diff를 사람이 확인하고 최종 권한을 행사한다.
6. 백포트: 병합 뒤 지원 버전으로 변경을 옮기고 충돌을 별도 작업으로 처리한다.

증거 중심 소프트웨어 팩토리의 최소 구조. 에이전트는 단계별 산출물을 만들고, 병합 권한은 사람에게 남긴다. 실행 단계는 샌드박스·최소 비밀·네트워크 통제로 제한한다. 출처: vercel.com/blog/building-a-software-factory-for-ai-sdk.

단계를 나눈다고 자동으로 품질이 좋아지는 것은 아니다. 그러나 실패 위치는 선명해진다. 잘못 분류했는지, 재현이 틀렸는지, 명세와 구현이 어긋났는지, 리뷰 기준이 빠졌는지를 각각 조사할 수 있다. 한 프롬프트 안에서 모든 일이 일어날 때보다 평가 케이스를 붙이고 회귀를 막기도 쉽다.

작은 팀이라면 처음부터 여섯 단계를 자동화할 필요가 없다. 가장 반복적이면서 판정 기준이 분명한 한 단계부터 시작하는 편이 낫다. 예를 들어 이슈 분류나 실패 테스트 재현은 결과를 사람이 확인하기 쉽다. 반면 공개 API 설계처럼 제품 판단과 장기 호환성이 얽힌 작업은 자동 구현보다 분석 초안과 위험 목록 생성까지만 맡기는 편이 안전하다.

요청을 곧바로 구현하지 말고 먼저 ‘증명 가능한 공백’으로 바꾼다

Vercel이 공개한 blocked-domain 지원 사례에서 핵심은 에이전트가 기능 요청을 곧바로 코드로 옮기지 않았다는 점이다. 분석 에이전트는 먼저 main 브랜치에서 해당 지원이 없다는 것을 확인하는 probe를 만들고, 실패 결과를 근거로 명세를 작성했다. 이후 구현 에이전트가 변경과 테스트를 만들고, 실제 웹 검색에서 차단 대상 도메인에 접근하지 않는다는 종단 간 검증 결과를 PR에 남겼다.

공개 GitHub 기록으로도 이 흐름의 결과를 확인할 수 있다. 이슈 #17898은 2026년 7월 24일 열렸고, ai-sdk-factory[bot]이 만든 PR #18033은 7월 28일 병합됐다. 이어 v6와 v5 백포트 PR도 같은 날 병합됐다. 다만 이것은 한 사례의 실행 기록이지, 팩토리 전체 성공률을 독립적으로 재계산한 결과는 아니다.

실무에서는 이 구조를 다음 계약으로 바꿀 수 있다.

• 버그 수정 전에는 수정되지 않은 기준 브랜치에서 실패하는 최소 재현이 있어야 한다.
• 기능 추가 전에는 현재 동작과 원하는 동작의 차이를 검증하는 probe가 있어야 한다.
• 구현 단계는 분석 단계가 만든 기대 조건을 임의로 완화하지 않는다.
• 리뷰 단계는 코드 작성자의 설명이 아니라 재현 로그, 테스트, 변경 범위를 함께 본다.
• 증거가 부족하면 “실패”와 “수동 확인 필요”를 구분한다.

이렇게 하면 에이전트가 그럴듯한 패치를 빨리 만드는 능력보다, 요청을 검증 가능한 작업으로 바꾸는 능력이 파이프라인의 중심이 된다.

리뷰 깊이는 변경 위험에 따라 달라져야 한다

모든 PR을 같은 방식으로 검토하면 자동화가 늘어도 사람의 부담은 줄지 않는다. Vercel은 문서 수정은 빠른 확인, 잘 정의된 provider 변경은 집중 검증, 새 공개 API는 깊은 리뷰가 필요하다는 식으로 위험에 따라 사람의 노력을 배분한다.

작은 저장소에서도 간단한 위험 등급을 만들 수 있다.

낮은 위험

문서 오탈자, 생성 파일 갱신, 범위가 제한된 테스트 보강처럼 영향이 국소적이고 되돌리기 쉬운 변경이다. 자동 검사와 짧은 사람 확인으로 충분할 수 있다.

중간 위험

기존 provider 매핑, 버그 수정, 내부 리팩터링처럼 동작에는 영향을 주지만 계약이 비교적 명확한 변경이다. 최소 재현, 회귀 테스트, 영향 파일 목록, 호환성 검토가 필요하다.

높은 위험

공개 API, 인증·권한, 결제, 데이터 마이그레이션, 의존성 공급망처럼 실패 반경이 큰 변경이다. 에이전트의 자동 승인 여부와 관계없이 책임 있는 사람이 설계와 diff를 깊게 검토하고, 필요하면 단계적 배포와 롤백 계획까지 확인해야 한다.

핵심은 에이전트가 “낮은 위험”이라고 말했기 때문에 리뷰를 줄이는 것이 아니다. 파일 경계, API 변경, 권한 사용, 데이터 손실 가능성처럼 기계적으로 확인 가능한 신호와 프로젝트 정책으로 등급을 검증해야 한다.

공개 저장소 입력은 전부 공격자 통제 데이터로 본다

AI SDK 팩토리는 공개 이슈, PR, 댓글, 그 안의 링크를 신뢰하지 않는 입력으로 간주한다. 버그 재현 단계부터 외부 입력이 코드를 실행하게 만들 수 있기 때문이다. 프롬프트 인젝션만이 문제가 아니다. 악성 코드 실행, 의존성 공급망 공격, 자원 고갈, API 키 탈취, 프롬프트 유출이 모두 같은 경계에 걸린다.

Vercel이 설명한 방어는 세 층이다.

1. 각 작업을 격리된 샌드박스에서 실행한다.
2. 작업에 필요한 비밀값만 제공하고 네트워크 접근 경로를 통제한다.
3. 어떤 변경도 사람 승인 없이 병합하지 않는다.

여기서 샌드박스는 시작점이지 완성된 방어가 아니다. 격리된 환경 안에 광범위한 자격 증명이 있고 외부 네트워크가 열려 있다면, 악성 입력은 여전히 비밀을 외부로 보낼 수 있다. 반대로 네트워크만 막고 호스트 파일시스템이나 배포 권한을 넓게 주면 피해 범위가 커진다.

따라서 코딩 에이전트 작업에는 최소한 다음 경계를 별도로 점검해야 한다.

• 실행 경계: 호스트와 분리된 일회성 작업 환경인가?
• 비밀 경계: 이 단계에 꼭 필요한 자격 증명만 짧게 제공되는가?
• 네트워크 경계: 허용된 목적지와 프로토콜만 접근 가능한가?
• 변경 경계: 수정 가능한 저장소, 브랜치, 파일 범위가 제한되는가?
• 승인 경계: 병합, 배포, 릴리스는 별도 권한을 가진 사람이 승인하는가?

자동화 단계마다 필요한 권한이 다르다. 분류 에이전트는 코드 실행이나 쓰기 권한이 없어도 된다. 분석 에이전트는 읽기와 샌드박스 실행이 필요할 수 있다. 구현 에이전트는 작업 브랜치에 쓸 수 있지만 병합 권한은 필요 없다. 이 차이를 실제 권한으로 분리해야 “프롬프트에서 하지 말라고 썼다”를 보안 경계로 착각하지 않게 된다.

네 가지 종료 상태를 피드백으로 쓴다

Vercel은 실행 결과를 성공, 결함 있음, 차단됨, 수동 처리의 네 상태로 나눈다.

• 성공: 정해진 증거와 검사를 충족해 다음 단계로 보낼 수 있다.
• 결함 있음: 잘못된 결과를 냈다. 프롬프트, 문맥, 평가 케이스를 보완할 신호다.
• 차단됨: 자격 증명, 서비스, 의존성 등 환경이 부족했다. 프로비저닝 문제다.
• 수동 처리: 의도적으로 자동화 경계 밖에 둔 작업이다.

이 분류가 좋은 이유는 모든 실패를 “모델이 약하다”로 뭉개지 않기 때문이다. 환경 문제를 프롬프트 수정으로 해결하려 하거나, 정책상 사람이 판단해야 할 작업을 재시도로 밀어붙이는 낭비를 줄인다.

운영 지표도 생성한 코드 줄 수보다 다음에 가까워야 한다.

• 사람이 수정 없이 받아들인 분석과 변경의 비율
• 잘못된 성공 판정을 회고에서 발견한 비율
• 단계별 수동 전환 이유
• 같은 실패가 평가 케이스 추가 뒤 재발했는지
• 위험 등급별 리뷰 시간과 되돌림 비율

작은 팀이 시작할 수 있는 최소 팩토리

대규모 웹훅, 큐, 대시보드를 먼저 만들 필요는 없다. 다음 네 단계면 충분한 첫 버전이 된다.

1. 작업 입구를 하나로 고정한다

이슈 템플릿에 기대 동작, 현재 동작, 재현 조건, 위험 영역을 받는다. 외부 텍스트와 링크는 신뢰하지 않는 입력으로 표시한다.

2. 분석 산출물의 형식을 정한다

에이전트가 최소 재현, 예상 영향 파일, 제안 명세, 검증 명령, 미확인 가정을 한 문서에 남기게 한다. 구현 전에 사람이 이 단위를 빠르게 승인하거나 반려할 수 있어야 한다.

3. 격리된 구현 단계만 자동화한다

승인된 분석을 입력으로 일회성 환경에서 브랜치를 만들고 코드를 수정한다. 비밀값과 네트워크는 기본 차단 후 필요한 것만 허용한다. 에이전트에는 병합 권한을 주지 않는다.

4. 증거 묶음과 함께 사람에게 넘긴다

PR에는 diff뿐 아니라 기준 브랜치에서 실패한 probe, 변경 뒤 통과한 검사, 미실행 검사, 위험 등급, 롤백 방법을 붙인다. 사람은 이 증거가 실제 변경 범위를 덮는지 확인하고 병합한다.

처음에는 분류와 분석까지만 자동화해도 된다. 리뷰 대기 시간이 줄고 오판 패턴을 모을 수 있을 때 구현과 백포트로 경계를 넓히는 편이 안전하다.

결론

AI SDK 사례가 보여주는 소프트웨어 팩토리의 핵심은 에이전트가 사람 없이 소프트웨어를 배송한다는 데 있지 않다. 반복 작업을 단계별 책임으로 나누고, 각 단계가 검증 가능한 증거를 만들며, 위험에 따라 사람의 주의력을 집중시키는 데 있다.

Vercel이 공개한 25~35%의 주간 병합 PR 작성과 70~80%의 이슈 종료는 운영 4주 시점의 자사 보고다. 하나의 대형 오픈소스 프로젝트 결과를 다른 팀의 생산성 약속으로 받아들여서는 안 된다. 대신 공개된 이슈와 PR 흐름에서 확인되는 설계 원칙—요청보다 재현을 먼저 만들기, 범용 에이전트보다 책임을 분리하기, 권한을 단계별로 줄이기, 마지막 병합은 사람에게 남기기—를 각 저장소의 위험에 맞게 시험할 수 있다.

코딩 에이전트를 더 많이 실행하기 전에 먼저 물어야 할 질문은 “몇 개를 병렬로 돌릴까?”가 아니다. 사람이 어떤 증거를 보고, 어느 지점에서, 어떤 권한으로 결정을 내릴 것인가? 그 답이 정해져야 에이전트의 속도가 검토 부채가 아니라 실제 처리량으로 바뀐다.

원문 및 출처

• Vercel Engineering, Building a software factory for AI SDK (2026-08-12)
• Vercel AI SDK 공식 저장소
• 공개 실행 사례, 기능 요청 이슈 #17898
• ai-sdk-factory[bot]이 작성하고 병합된 PR #18033