Vercel eve Software Factory — AI 에이전트 4명이 코드를 만드는 "소프트웨어 공장"

핵심 요약

• Vercel Labs가 공개한 vercel-labs/eve-software-factory-template은 이슈를 받아 리뷰까지 마친 초안 PR을 만들어내는 "소프트웨어 공장(Software Factory)" 템플릿이며, 공장의 이름은 Foreman(현장 감독)입니다 (GitHub).
• 2026-08-12 생성, 2026-08-14 최종 push로 공개 사흘 만에 668★ / 포크 46 / 오픈 이슈 0을 기록했고, 언어는 TypeScript, 라이선스는 MIT입니다 (GitHub).
• 파이프라인은 Classifier → Analyst → Implementer → Reviewer 4개 스테이션으로 나뉘며, 각 스테이션은 독립 에이전트입니다.
• Reviewer는 Implementer의 추론 과정을 보지 않고 실제 diff만 판단합니다. 격리가 곧 리뷰 품질의 근거입니다.
• 작업 유입 경로는 GitHub 라벨 factory, @멘션, Linear 위임, 로컬 TUI, 빨간 CI 자동 진단, PR 오리엔팅 코멘트까지 6가지입니다.
• 최종 머지 판단은 언제나 사람이 합니다. "판단은 사람, 실행은 에이전트"라는 경계가 이 구조의 핵심 안전장치입니다.
• 같은 패러다임은 코드가 아닌 글이나 콘텐츠 생산에도 적용됩니다. Vercel이 코드 PR 공장이라면, 뉴스·블로그 자동화는 검증 규칙을 거쳐 글을 발행하는 콘텐츠 공장입니다.

소프트웨어 공장이란 무엇인가

코딩 에이전트를 실무에 붙여본 팀이라면 비슷한 벽을 만납니다. 에이전트 하나에게 "이 이슈 고쳐줘"라고 던지면 그럴듯한 diff가 나오지만, 그 diff가 요구사항을 충족했는지, 애초에 그 이슈가 지금 손댈 만한 것이었는지, 검증은 돌렸는지를 확인하는 비용이 코드를 직접 짜는 비용을 넘어서는 순간이 옵니다. 단일 에이전트의 문제는 능력이 아니라 책임 분리의 부재입니다. 계획을 세운 주체가 구현을 하고, 구현한 주체가 자기 결과를 리뷰하면 판단은 필연적으로 편향됩니다.

Software Factory는 이 문제에 조립 라인이라는 답을 내놓은 구조입니다. 즉 소프트웨어 공장이란, 개발 주기의 모든 단계에 각각 독립된 AI 에이전트를 배치하되 최종 판단인 머지만은 사람이 쥐고 있는 자동화 코드 생성 시스템입니다. 그리고 Foreman은 Vercel Labs가 eve 위에 구현한 소프트웨어 공장의 레퍼런스 템플릿으로, GitHub 또는 Linear의 이슈를 입력으로 받아 네 개 스테이션을 통과시킨 뒤 리뷰된 초안 PR을 산출물로 내놓는 프로그램입니다 (Foreman Docs). 공장이라는 은유가 중요한 이유는 여기에 있습니다. 공장의 목표는 무인화가 아니라 공정 분리와 검사 지점의 명시화입니다.

수치로 보면 반응은 분명합니다. 저장소는 2026-08-12에 생성되어 2026-08-14에 마지막으로 push되었는데, 공개 사흘 만에 668개의 별과 46개의 포크를 모으며 같은 주에 생성된 저장소 중 상위권에 올랐습니다 (GitHub). 오픈 이슈가 0건이라는 점은 아직 실전 투입 사례가 축적되기 전이라는 신호로도 읽어야 합니다.

Foreman의 4개 스테이션과 Factory Brain

스테이션별 역할

Classifier는 들어온 이슈의 유형·우선순위·복잡도를 분류하고, 무엇보다 "지금 실행 가능한 작업인가"를 먼저 판정합니다. 실행 가능하지 않다고 보면 구현으로 넘기지 않고 요청자에게 질문을 되돌립니다. 애매한 요구사항이 파이프라인 전체를 낭비하는 것을 입구에서 막는 장치입니다.

Analyst는 실시간으로 저장소를 체크아웃한 상태에서 계획을 세우고, 그 계획에 수용 기준(acceptance criteria)을 명시합니다. 기억이나 요약이 아니라 현재 코드베이스를 근거로 삼는다는 점, 그리고 "무엇을 충족해야 완료인가"를 구현 전에 못 박는다는 점이 핵심입니다.

Implementer는 자체 샌드박스 안에서 계획을 실행하고, 저장소가 원래 가지고 있던 검사 도구로 결과를 검증한 뒤 브랜치를 push합니다. 검증 기준을 에이전트가 새로 만들지 않고 레포의 기존 규칙을 그대로 쓴다는 설계가 눈에 띕니다.

Reviewer는 실제 diff만 보고 독립적으로 판단하며, 근거와 함께 평결을 냅니다. Implementer가 어떤 추론으로 그 코드에 도달했는지는 보지 않습니다. 이 격리가 없다면 리뷰는 구현자의 논리를 재확인하는 절차로 퇴화합니다.

Factory Brain과 6가지 유입 경로

Foreman은 Factory Brain, 즉 공장의 기억을 유지합니다. 저장소에 대해 누적된 메모를 매 실행 시작 시점에 참조하므로, 같은 실수나 같은 질문을 반복할 가능성이 줄어듭니다. 작업은 여섯 경로로 들어옵니다. ① GitHub 이슈에 factory 라벨 부착 ② @멘션 ③ Linear에서의 위임 ④ 로컬 TUI ⑤ 빨간 CI 감지 후 실패를 진단해 자체 브랜치에 수정 ⑥ PR에 남기는 오리엔팅 코멘트입니다. 특히 ⑤는 사람이 요청하지 않아도 공장이 스스로 일을 집어 든다는 뜻이라, 뒤에서 다룰 리뷰 부담과 직결됩니다.

안전장치는 두 겹입니다. 로컬 실행은 untrusted로 취급되어 GitHub에 실제 변경을 가하려면 승인을 기다리고, Reviewer는 Implementer로부터 격리됩니다. 배포는 Vercel 원클릭으로, GitHub/Linear 커넥터와 Blob 스토어를 연결한 뒤 환경변수를 채우는 방식입니다 (Vercel Connect). 필수 값은 작업 대상을 지정하는 FACTORY_REPO와 GITHUB_CONNECTOR / LINEAR_CONNECTOR이고, 샌드박스 체크아웃에서 한 번 실행할 FACTORY_SETUP_COMMAND, 이슈 라벨을 지정하는 FACTORY_LABEL(기본 factory), PR 브랜치 접두사인 FACTORY_BRANCH_PREFIX(기본 factory/)는 선택입니다. 하부 런타임의 개념은 eve 문서에서 확인할 수 있습니다 (eve Documentation).

코드 공장과 콘텐츠 자동화의 같은 뿌리

이 구조는 코드 PR 생산에만 국한되지 않습니다. 소프트웨어 공장의 핵심 원칙 — 공정을 쪼개고, 각 단계에 독립 에이전트를 두고, 검사 지점을 명시하고, 최종 책임을 사람에게 남기는 것 — 은 코드가 아닌 다른 산출물에도 그대로 적용됩니다. 가장 가까운 예가 콘텐츠/글 자동화 파이프라인입니다. Vercel의 Foreman이 코드 PR 공장이라면, 블로그 운영에는 같은 구조를 닮은 글 공장이 있습니다. 주제와 리서치 데이터가 들어오고, 초안이 생산되고, 규칙 검증을 거쳐 발행됩니다.

대응 관계를 놓고 보면 겹치는 지점이 선명합니다. Foreman의 Classifier가 "이 이슈가 실행 가능한가"를 묻는 자리에, 글 공장은 "이 주제가 쓸 만한 소재인가"를 묻습니다. Analyst의 수용 기준은 분량·출처 표기·문체 같은 발행 규칙에 해당합니다. Implementer가 레포 자체 검사로 자기 결과를 검증하듯, 초안은 정해진 규칙 세트(분량, 출처 인용, 문체 일관성)를 통과해야 합니다. 그리고 Reviewer가 구현자의 추론이 아니라 diff만 보듯, 발행 검증은 글이 어떤 의도로 쓰였는지가 아니라 완성된 텍스트 자체를 기준으로 판정합니다.

차이도 분명히 해둘 필요가 있습니다. Foreman은 사람의 머지를 최종 게이트로 두지만, 글 공장은 발행 자체를 자동화가 수행할 수 있습니다. 사람의 판단은 그보다 앞선 지점, 즉 어떤 규칙을 세울 것인가와 무엇을 발행 대상으로 삼을 것인가에 배치됩니다. 게이트의 위치가 다를 뿐, 사람은 판단하고 에이전트는 실행한다는 경계선은 동일합니다. 코드와 글이라는 산출물의 차이가 있을 뿐, 공정을 쪼개고 검사 지점을 명시하고 최종 책임을 사람에게 남기는 설계 원리는 하나입니다.

소프트웨어 공장의 한계

이 구조를 낙관만 하기는 어렵습니다. 짚어야 할 부담이 최소 세 가지입니다.

첫째, 에이전트 신뢰 문제입니다. Reviewer가 근거와 함께 평결을 낸다고 해서 그 평결이 옳다는 보장은 없습니다. 격리는 편향을 줄이는 장치이지 정확도를 보증하는 장치가 아닙니다. Reviewer가 통과시킨 PR을 사람이 "이미 리뷰됐으니까"라며 가볍게 훑는 습관이 생기면, 격리 설계가 만든 안전 마진은 그대로 소진됩니다.

둘째, 리뷰 부담의 전가입니다. 공장은 PR 생산 속도를 올리지만 사람의 리뷰 대역폭은 그대로입니다. 특히 빨간 CI를 감지해 스스로 수정 브랜치를 만드는 경로가 켜져 있으면, 아무도 요청하지 않은 PR이 계속 쌓일 수 있습니다. 병목은 작성에서 검토로 이동할 뿐 사라지지 않으며, 검토되지 않은 PR 더미는 기술 부채와 다르지 않습니다.

셋째, 오버엔지니어링 위험입니다. 네 개 스테이션, 여섯 개 유입 경로, Factory Brain, 커넥터와 Blob 스토어까지 갖춘 인프라는 오탈자 수정이나 문구 변경 같은 작업에는 명백히 과합니다. 이슈 흐름이 주당 몇 건 수준인 팀이라면 공장을 세우고 유지하는 비용이 얻는 이득을 넘어설 가능성이 큽니다. 여기에 저장소가 공개된 지 사흘밖에 되지 않았고 오픈 이슈가 0건이라는 사실은, 장기 운영에서 드러날 문제들이 아직 보고되기 전이라는 뜻이기도 합니다 (GitHub).

완전 자동화가 망하는 이유

파이프라인이 사람의 판단까지 대신하기 시작하면 무슨 일이 벌어지는지는, 콘텐츠 영역에서 이미 실측으로 확인된 바 있습니다. 한 개발자는 100일 동안 chatGPT API(gpt-4-1106-preview)와 식약처 건강기능식품 원료 크롤링 데이터 400여 개를 엮어 티스토리에 하루 1~5개씩 글을 자동 업로드하는 파이프라인을 돌렸습니다. 프로필 소개까지 생성해 붙인, 사람 손이 거의 닿지 않는 구성이었습니다. 결과는 애드센스 1차 신청에서 2주 심사 끝에 "주의 필요" 판정, 두 달 뒤 재신청에서도 재차 거절이었습니다. 방향을 틀어 쿠팡 파트너스로 전환한 뒤에도 총 90여 개 글에서 하루 약 0.8건의 클릭이 발생했을 뿐, 실제 구매는 0건이었습니다(Medium). 검색에는 걸리는데 지갑은 열리지 않는다는 것, 그리고 심사 시스템은 생성물을 판별해낸다는 것이 이 실험의 결론이었습니다.

두 번째 사례는 도구를 사는 쪽에서 본 기록입니다. 50만~150만 원대의 자동 포스팅 프로그램 광고를 접한 경험을 정리한 글은, 2022년 애드센스 붐 시절 3주 만에 승인이 나던 환경과 지금의 심사 기준이 완전히 달라졌다는 점을 지적합니다. 구글은 E-E-A-T 원칙으로 "사람이 직접 경험한 흔적"을 요구하고, 네이버는 특정 주제에 대한 장기적 신뢰(C-Rank)와 독자가 오래 머무는 깊이(D.I.A.+)를 봅니다. 유튜브의 시청 지속 시간, 틱톡의 재시청률도 같은 방향입니다. 여기서 정리된 위험은 네 가지입니다(브런치).

• 금전적 위험: 고가 자동화 도구 비용을 수익으로 회수하지 못함
• 검색엔진 페널티: 저품질 대량 콘텐츠가 스팸으로 분류됨
• 수익 모델 붕괴: 애드센스 거절로 수익 경로 자체가 막힘
• 법적 리스크: 순수 생성물은 저작권 보호를 받기 어려움

두 사례를 겹쳐 보면 공통점이 선명합니다. 애드센스 승인 거절을 양쪽 모두 겪었고, 검색 노출은 되지만 수익 전환은 일어나지 않았으며, 결과적으로 채널의 브랜딩과 신뢰가 손상됐습니다. 주목할 점은 실패의 원인이 "자동화를 썼다"가 아니라 "판단까지 자동화에 넘겼다"는 데 있다는 것입니다. 무엇을 쓸지, 어떤 근거로 쓸지, 이 글을 내보내도 되는지를 결정하는 지점이 비어 있었던 겁니다. 파이프라인은 소재의 품질을 평가하지 않고, 심사 기준의 변화를 감지하지 않습니다.

그래서 대안은 자동화를 줄이는 쪽이 아니라, 자동화 안에 사람의 판단 게이트를 남겨두는 쪽입니다. Vercel의 소프트웨어 공장이 코드 생성과 테스트와 CI는 기계에 맡기면서도 머지 버튼만은 끝내 사람에게 남겨둔 구조가 정확히 이 형태입니다. 블로그에 옮기면 수집·초안·포맷팅·배포 스케줄링은 파이프라인이 처리하되, 소재 선정과 발행 여부 판단, 그리고 직접 경험을 덧붙이는 작업은 사람이 통제하는 구성이 됩니다. "자동화는 보조일 뿐이고 브랜드의 무게 중심은 사람이며, 조수 역할에 머물러야 한다"는 브런치 기록의 정리는 소프트웨어 공장이 머지를 사람에게 남긴 이유와 같은 문장입니다. 게이트 하나를 남기는 비용은 하루 몇 분이지만, 그것을 없앤 대가는 두 사례가 보여주듯 승인 거절과 구매 0건입니다.

실행 체크리스트: 단계별 도입 가이드

당장 전면 도입을 검토하기보다, 아래 순서로 좁게 시작하기를 권합니다.

• 1단계 — 대상 좁히기. 팀 전체 저장소가 아니라 실패해도 타격이 적은 저장소 하나를 FACTORY_REPO로 지정합니다. 문서 사이트나 내부 도구가 적합합니다.
• 2단계 — 라벨 게이트 유지. FACTORY_LABEL(기본 factory) 기반 유입만 켜고, 빨간 CI 자동 수정과 @멘션 경로는 최소 2주간 끕니다. 사람이 명시적으로 붙인 라벨만 공장을 깨우게 합니다.
• 3단계 — 검증 명령 정비. FACTORY_SETUP_COMMAND와 레포의 lint·test·타입체크를 먼저 신뢰할 수 있는 상태로 만듭니다. Implementer의 검증 품질은 저장소 자체 검사 품질을 넘지 못합니다.
• 4단계 — 브랜치 분리 확인. FACTORY_BRANCH_PREFIX(기본 factory/)를 그대로 두어, 공장 산출물과 사람의 작업 브랜치가 목록에서 즉시 구분되게 합니다.
• 5단계 — 로컬 실행은 untrusted 유지. 승인 대기 설정을 임의로 해제하지 않습니다. 편의를 위해 이 설정을 끄는 순간 공장은 감사 가능한 시스템이 아니게 됩니다.
• 6단계 — 머지 기준 문서화. "Reviewer가 통과시킨 PR도 사람이 diff를 직접 읽고 머지한다"를 팀 규칙으로 명문화합니다. 판단을 사람이 한다는 원칙은 설정값이 아니라 합의로 지켜집니다.
• 7단계 — 지표로 판정. 4주 뒤 생성된 PR 수가 아니라 머지된 PR 비율과 리뷰에 든 사람 시간을 봅니다. 머지율이 낮다면 Analyst의 수용 기준이 부실하다는 신호이고, 리뷰 시간이 늘었다면 유입 경로를 더 좁혀야 한다는 신호입니다.

세 줄로 줄이면 이렇습니다. 소프트웨어 공장의 가치는 사람을 빼는 데 있지 않고, 사람이 판단해야 할 지점을 한 곳으로 모으는 데 있습니다. Foreman이 머지 버튼을, 콘텐츠 자동화가 규칙 설계와 소재 선정을 그 지점으로 삼는 것처럼, 각 팀은 자기 공정에서 사람이 지켜야 할 게이트가 어디인지 먼저 정해야 합니다. 그 게이트를 정하지 않은 채 파이프라인부터 세우면, 남는 것은 검토되지 않은 산출물뿐입니다.