AI SDK의 이슈와 PR을 자율적으로 처리하는 소프트웨어 팩토리를 구축했습니다. 병합 여부는 사람이 직접 결정하며, 운영 4주 만에 전체 병합 PR의 25~40%를 이 시스템이 작성하고 있습니다.
AI SDK는 전 세계에서 가장 인기 있는 오픈소스 AI 프로젝트 중 하나입니다. 주간 npm 다운로드 수가 2천만 건을 넘고, 저장소 스타는 26,000개 이상입니다. 이 코드베이스를 유지보수한다는 것은 동시에 네 가지 변화를 따라잡아야 한다는 뜻입니다.
모델 프로바이더: 새로운 프로바이더 추가, 신규 기능, 그리고 새로운 버그
UI 프레임워크: React, Next.js, Svelte, Vue 등 각종 바인딩
샌드박스: 에이전트가 코드를 실행하는 환경
하네스: Codex, Claude Code, Pi 등을 위한 어댑터
수년간 성장을 거듭하면서 저장소에는 매달 100개 이상의 이슈가 쏟아졌고, Anthropic의 Opus 4.6 모델이 출시되자 PR 수도 급격히 늘기 시작했습니다. 6월 말에 이르러 그 누적 효과로 미해결 이슈가 1,000개를 넘어섰고, 풀 리퀘스트도 거의 800개에 달했습니다.
이 백로그는 관리 소홀의 결과가 아닙니다. 아무리 뛰어난 메인테이너라도 더 열심히 일하는 것만으로는 이 격차를 좁힐 수 없습니다. 게다가 코드 생성 비용이 낮아진 만큼 앞으로 이 격차는 더욱 벌어질 것입니다.
우리가 직접 규모를 늘리는 대신, 소프트웨어 팩토리를 구축했습니다. 운영 4주 만에 이 팩토리가 병합 PR의 25~35%를 작성하고, 이슈의 70~80%를 처리하고 있습니다.
본격적인 구축에 앞서 세 가지 질문에 먼저 답해야 했습니다.
기존의 에이전트 방식으로는 왜 부족한가
AI SDK 같은 프로젝트에 적합한 자동화 수준은 어느 정도인가
자동화와 사람의 개입을 어떻게 위험도에 맞게 조율할 것인가
뛰어난 메인테이너들은 이미 에이전트를 적극적으로 활용하고 있습니다. Mitchell Hashimoto는 항상 에이전트가 돌아가는 것을 목표로 Ghostty를 운영하면서, 에이전트가 실패할 때마다 같은 실수가 반복되지 않도록 AGENTS.md에 기록합니다. Simon Willison은 코딩 에이전트 네 개를 병렬로 돌리고 있으며, Vercel Agent나 CodeRabbit 같은 리뷰 봇은 수백만 개의 저장소에 적용되어 있습니다. 반면 Daniel Stenberg처럼 curl에 AI 생성 코드 제출을 아예 차단하는 메인테이너도 있습니다.
이런 방법들이 도움이 되는 건 사실이지만, 핵심 제약은 여전히 해결되지 않습니다. 모든 변경 사항이 결국 한 사람의 주의를 거쳐야 한다는 점입니다. 에이전트 엔지니어링에서 신뢰의 핵심은 여전히 사람이 책임을 진다는 것이라고 생각하기 때문에, 우리는 리뷰어 효율성을 최우선 원칙으로 삼아 팩토리를 설계해야 한다는 결론을 내렸습니다.
소프트웨어 팩토리는 스펙트럼 위에 존재합니다. 한쪽 끝은 완전 자동화로, 사람이 코드를 한 줄도 읽지 않은 채 에이전트가 작성·배포·운영까지 모두 처리합니다. 중간에는 Codex나 Claude Code 같은 하네스가 있어, 사람이 하나 혹은 여러 에이전트를 직접 지휘합니다. 반대쪽 끝에는 위험 부담이 너무 커서 자동화를 거의 하지 않는 영역, 예컨대 심장박동기 펌웨어나 자율주행 차량 소프트웨어가 있습니다.
AI SDK는 신중한 쪽에 더 가깝게 운영되어야 합니다. 수백만 개의 애플리케이션이 그 위에서 돌아가는 핵심 AI 인프라인 만큼, 품질과 보안은 타협할 수 없습니다. 또한 무엇을 출시할지는 사람이 통제해야 합니다. 우리가 필요한 것은 사람을 배제하지 않으면서도, 사람 주변의 모든 과정을 최대한 자동화하는 팩토리였습니다.
특정 변경 사항에 대해 사람이 검토해야 하는 깊이는 위험도에 비례합니다.
세부적인 기능 명세가 담긴 중앙 집중식 로드맵은 위험도를 사전에 정의하고 소프트웨어 팩토리에 투입되는 작업의 방향을 직접 잡아줄 수 있습니다. 그러나 AI SDK 같은 오픈소스 프로젝트에는 커뮤니티가 올리는 이슈와 PR도 함께 들어오는데, 이것들이 프로젝트 목표와 일치한다거나 변경이 안전하다는 보장이 없습니다. 위험도가 높을수록 사람의 판단이 시스템에서 더 중요한 역할을 합니다.
이 판단을 최적화하기 위해 에이전트는 단순히 요청에 따라 코드를 생성하는 것을 넘어서야 했습니다. 프로젝트 전체 맥락 안에서 각 작업 단위를 온전히 평가할 수 있어야 했습니다.
팩토리의 목표는 각 변경 사항에 대해 적합성과 위험도를 종합한 평가를 작성하고, 근거가 되는 증거 체인을 문서화하여 리뷰어가 적절한 수준의 노력을 투입할 수 있도록 돕는 것이었습니다.
문서 수정은 빠르게 확인
명확하게 정의된 프로바이더 변경은 집중 검증
새로운 퍼블릭 API는 심층 리뷰
ai-sdk-factory은 AI SDK에 들어오는 이슈와 풀 리퀘스트를 자율적으로 처리하는 소프트웨어 팩토리입니다. 팩토리 내의 에이전트들은 버그 재현, 기능 구현, 이전 SDK 버전을 위한 백포트 생성 등 각자 맡은 역할을 수행하며, 검토 가능한 형태로 결과를 남깁니다. 모든 변경 사항의 병합을 포함해 전체 과정에서 사람이 주도권을 쥐고 있습니다.
팩토리를 한 번에 완성해 출시하지는 않았습니다. 이슈를 버그, 기능, 문서 업데이트로 분류하는 단계에서 시작해 점진적으로 구축했습니다. 이 첫 번째 단계는 백로그의 전체적인 모습을 파악하는 데 도움이 되었을 뿐 아니라, 이후에 구축한 다른 전문 에이전트들에게 유용한 맥락을 전달하는 역할도 했습니다.
새로운 기능을 구현할 때마다 다양한 방식을 프로토타이핑했고, 그 과정에서 프로덕션 팩토리 아키텍처를 형성한 일련의 원칙들을 도출했습니다.
분류 에이전트가 높은 정확도에 도달하자, 우리는 버그 재현·수정·리뷰 자동화에 집중했습니다. 각 단계에 필요한 기능을 하나의 에이전트에 모두 담는 방식도 검토했지만, 장기적으로 유지보수와 디버깅 부담이 커진다는 것을 금방 깨달았습니다.
대신 특정 작업 하나에만 집중하는 에이전트를 각각 구축했습니다. 이 방식 덕분에 새로운 기능 추가, 독립적인 테스트, 디버깅이 훨씬 수월해졌습니다. 각 에이전트는 고유한 프롬프트, 컨텍스트, 평가를 갖추고 특정 역할에만 집중합니다.
현재 팩토리에는 전체 흐름의 각 단계를 담당하는 전용 에이전트가 있습니다.
버그 재현
버그 수정
PR 리뷰
백포트
문서 업데이트
기능 분석
기능 구현
보안은 두 번째 에이전트를 구현할 때부터 적용했습니다. 팩토리가 외부에서 제어되는 콘텐츠를 기반으로 코드를 실행하기 시작하는 첫 단계가 바로 버그 재현이었기 때문입니다.
퍼블릭 저장소를 대상으로 운영되는 팩토리는 모든 입력이 공격자에 의해 조작될 수 있다고 가정해야 합니다. 이슈, 풀 리퀘스트, 댓글, 그리고 그 안에 포함된 링크는 모두 신뢰할 수 없는 데이터입니다. 성공한 오픈소스 프로젝트는 고가치 표적이기 때문에, 악의적인 코드 변경과 공급망 공격부터 리소스 고갈, API 키 탈취, 프롬프트 탈취까지 다양한 위협에 노출됩니다.
방어의 기반은 샌드박스입니다. ai-sdk-factory의 모든 에이전트는 코드, 런타임, 그리고 해당 작업에 꼭 필요한 시크릿만을 포함한 격리된 Vercel 샌드박스 안에서 실행됩니다. 이 가드레일 덕분에 신뢰할 수 없는 콘텐츠가 에이전트의 제안에 영향을 줄 수는 있어도, 그 피해는 샌드박스 안으로 제한됩니다.
또한 샌드박스 주변에 네트워크 접근을 제어하는 차폐 레이어를 구축해, 공격자가 격리된 환경에서 시크릿을 빼내는 데 쓰는 경로를 원천 차단했습니다.
최후의 방어선은 사람의 리뷰입니다. AI SDK 팀원의 승인 없이는 아무것도 병합되지 않습니다.
팩토리를 위해 처음 만든 에이전트들은 로컬 CLI를 통해 실행했습니다. 부정확한 부분을 발견하고, 불편함을 직접 느끼고, 다양한 아이디어를 빠르게 프로토타이핑하기에 최적의 환경이었습니다.
여러 단계가 CLI에서 안정적으로 돌아가는 것을 확인한 뒤, 시스템을 관리형 인프라로 이전했습니다. ai-sdk-factory는 다음을 사용합니다.
API, 워커, 웹훅 수신에는 Vercel Functions
작업 실행에는 Vercel Queues
로그 저장에는 Vercel Blob
에이전트 작업 공간에는 Vercel Sandbox
팩토리 데이터 관리에는 Neon Postgres
현재는 GitHub 웹훅이 이슈 큐에 데이터를 공급하면, 워커가 이를 자동으로 가져와 샌드박스에서 에이전트 실행을 시작합니다. 모든 실행 상황을 병렬로 추적하고 리뷰어 팀을 위해 큐를 시각화하는 모니터링 UI도 함께 구축했습니다.
7월 24일, 커뮤니티 멤버가 OpenAI 웹 검색에서 차단 도메인 지원을 요청했고, 이 요청은 이슈 #17898이 되었습니다. 아래 내용은 소프트웨어 팩토리가 이 이슈를 처리하고, 기능이 구현된 풀 리퀘스트를 열고, 최종적으로 병합된 기능을 SDK v5와 v6에 백포트하기까지의 전 과정을 설명합니다.
팩토리에서 가장 먼저 실행되는 에이전트는 이슈와 PR을 분류합니다. 이번 경우 ai-sdk-factory 봇이 이슈에 댓글을 남기고 라벨을 적용해, 높은 신뢰도로 해당 유형을 기능(Feature)으로 식별했습니다. 에이전트는 댓글에 분류 근거도 함께 기재했습니다.
분류가 끝나면 분석 에이전트가 실행됩니다. 팩토리의 에이전트들은 기능 요청이나 버그의 기술적 타당성을 미리 가정하지 않기 때문에, 분석 에이전트는 차단 도메인 지원이 실제로 없는지 확인하는 프로브를 직접 작성했습니다. issue-17898-type-probe.ts가 생성되어 실행되었고, 차단 도메인을 찾지 못해 오류와 함께 실패했습니다.
실패한 프로브는 main에 해당 기능이 없다는 것을 증명했고, 에이전트는 이를 분석 결과의 근거로 포함했습니다.
분석 에이전트는 조사 결과를 바탕으로 기능 명세를 작성했습니다. 기존 웹 검색 도구에 선택적 blockedDomains 필터를 추가하고, 이를 프로바이더의 blocked_domains 필드에 매핑하는 내용이었습니다.
에이전트는 이 명세가 SDK의 프로바이더-어댑터 아키텍처와 맞아떨어지고 하위 호환성이 보장된다는 것도 확인했으며, 문서 변경 범위까지 정리했습니다.
이어서 별도의 에이전트가 명세를 구현하고 풀 리퀘스트를 열었습니다. 구현 에이전트는 wikipedia.org를 차단한 상태에서 OpenAI 웹 검색을 실행하는 라이브 엔드투엔드 테스트를 수행해 해당 도메인에 접근할 수 없음을 확인했고, 이 테스트를 추가 증거로 풀 리퀘스트에 포함했습니다.
다음으로 리뷰 에이전트가 변경 사항을 평가했고, 문제가 없다고 판단해 승인했습니다. 에이전트는 해당 기능이 완전히 구현되었다고 평가하며 다음과 같이 점수를 매겼습니다.
부작용 위험: 낮음
성능 위험: 없음
하위 호환성 위험: 낮음
마지막으로 Lars가 에이전트들의 증거 체인을 읽고 코드 변경 사항을 검토한 뒤, PR #18033을 main에 병합했습니다.
Lars가 첫 번째 PR을 병합하자, ai-sdk-factory는 두 건의 백포트 PR을 추가로 열었습니다. v6용 #18035와 v5용 #18036입니다. v5 백포트는 충돌 없이 적용되지 않았지만, 팩토리 에이전트가 충돌 상태를 라벨링·커밋하고 수정 방법을 찾아 검증한 뒤 17분 만에 푸시했습니다. 검토를 마친 Lars는 두 백포트 PR을 모두 병합했습니다.
소프트웨어 팩토리를 프로덕션에서 운영한 지 이제 막 4주가 지났습니다. 지금까지의 결과입니다.
main 브랜치 병합 PR
매주 병합되는 PR의 25~35%를 ai-sdk-factory 에이전트가 작성하고 있습니다.
백포트
v6 릴리스 라인 주간 병합에서 팩토리 PR 비중이 50%를 넘었고, v5도 비슷한 수준입니다. 예전에는 머지 충돌 처리가 번거로워 건너뛰던 작업이었는데, 이제 v5와 v6 모두 훨씬 나은 지원을 받고 있습니다.
이슈
7월 한 달간 처리된 이슈의 75% 이상을 팩토리가 처리했습니다.
미해결 이슈는 6월 말 최고점인 1,022개에서 8월 초 844개로 줄었고, 미해결 버그는 약 25% 감소했습니다.
ai-sdk-factory는 공개적으로 운영되므로, 저장소에서 팩토리가 작성한 모든 풀 리퀘스트를 직접 확인할 수 있습니다.
팩토리를 운영하면서 가장 흥미로운 부분은 실패했을 때 일어나는 일입니다. 모든 실행은 성공(success), 결함(flawed), 차단(blocked), 수동(manual) 중 하나로 끝납니다. 성공만이 실제로 출시되고, 나머지는 시스템에 피드백 신호로 다시 유입됩니다.
결함 실행은 에이전트가 잘못된 결과를 냈다는 뜻으로, 더 나은 프롬프트, 더 풍부한 컨텍스트, 또는 같은 실수가 자동으로 걸러지도록 평가 케이스를 추가하는 것으로 해결합니다
차단 실행은 환경에 무언가가 빠져 있다는 뜻으로, 인증 정보, 서비스, 의존성 등을 프로비저닝하는 것으로 해결합니다
수동 실행은 우리가 의도적으로 그은 경계를 표시하며, 팩토리 개선이 그 경계를 제거할 만큼 충분한지 다시 묻게 만듭니다
이런 개선들이 자동화의 경계를 넓혀 가고, 매주 팩토리는 이전에는 맡길 수 없었던 작업까지 처리할 수 있게 됩니다.
팩토리를 운영하는 것은 팀이 테스트 스위트나 파이프라인에 이미 적용하는 방식과 같은 원칙입니다. 다만 그 대상이 결과를 검증하는 시스템이 아닌, 실제로 작업을 수행하는 시스템으로 바뀐 것입니다. 에이전트가 SDLC를 정의하는 시대에는 팩토리를 개선하는 것이 표준적인 엔지니어링 업무가 될 것입니다.
