아니오, 그것은 소프트웨어 팩토리가 아닙니다 — 라이언 쿡(Ryan Cooke), WorkOS
원제 · No, That's Not a Software Factory — Ryan Cooke, WorkOS
핵심 요약
소프트웨어 팩토리의 성패는 코드 생성량 증가가 아니라 PRD 작성, 티켓 분할, 데이터 조회 등 전체 제품 엔지니어링 프로세스를 TARS와 MCP 게이트웨이 기반으로 자동화하여 기능 전달 속도를 높이는 것에 달려 있다.
하이라이트
단순 코드 생성 및 PR 제출 수 중심의 산출량 지표는 소프트웨어 팩토리의 실제 실질적 가치를 가린다.
WorkOS는 개발 도구와 연동되는 인터페이스 TARS와 인프라 오케스트레이션 계층 Horizon을 결합해 엔지니어링 프로세스를 자동화한다.
Linear, Slack, GitHub 웹훅을 구독해 PRD 작성부터 티켓 분할, 작업 승인까지 제품 개발 생명주기를 자동 실행한다.
내부 MCP 게이트웨이인 Context Engine을 통해 Snowflake 데이터 레이크와 제품 활용 데이터를 에이전트 및 내부 구성원에 제공한다.
자체 샌드박스 인프라 구축을 통해 세션 정보를 제어하고 세션 분석 기반으로 AI 스킬을 지속 개선한다.
타임라인
산출량 중심 소프트웨어 팩토리 평가의 한계
업계 전반에서 클라우드 샌드박스와 AI 에이전트를 결합해 PR을 자동 생성하는 구조가 확산되었다. 하지만 PR의 비율이나 개수 같은 단순 산출량 지표는 실제 조직 가치를 왜곡할 위험이 있다. 엔지니어링 팀의 가치 창출 여부는 더 빠르게 기능을 구축하고 배포하는 성과 지표로 평가해야 한다.
- AI 코드 작성 도구 보급 이후 PR 수와 코드 생성량만 강조하는 측정 방식이 늘어났다.
- 코드 산출물 자체는 실질적인 제품 개발 성과로 직결되지 않는다.
- 소프트웨어 팩토리의 목적은 단순 코드 작성이 아닌 복잡한 기능의 배포 및 전달 속도 가속화다.
TARS와 Horizon을 활용한 프로세스 내재화
단순히 오픈소스 모델 라우터와 샌드박스를 연동하는 방식은 엔지니어 개인의 로컬 개발 대비 생산성 우위를 가져다주지 못했다. 이에 따라 WorkOS는 코딩 외 엔지니어링 절차 전반을 내재화하는 방향으로 구조를 전환했다. Slack, Linear, GitHub의 웹훅을 수신해 의존성이 걸린 티켓이 완료되면 다음 티켓을 자동으로 이어받아 실행하고 계획의 공백을 스스로 재평가하도록 설계했다.
- 단순 코드 에이전트 실행은 로컬 환경 대비 뚜렷한 생산성 향상을 제공하지 못한다.
- TARS는 Slack, Linear, GitHub과 통합되어 작업 진행 상황을 추적한다.
- Horizon은 MCP 게이트웨이 전면에 위치하는 인프라 오케스트레이션 계층으로 작동한다.
제품 요구사항 문서화 및 콜드 스타트 자동화
엔지니어가 직접 요구사항을 정의하는 업무 문화 속에서 문서 작성 초기 단계의 부담이 존재했다. PM 에이전트는 Slack 입력 내용에 기반해 PRD 초안과 미해결 질문 리스트를 즉시 생성하여 백지 상태의 공백을 제거한다. 리드 엔지니어의 피드백과 승인을 거치면 Linear 프로젝트와 구현 티켓 생성이 자동으로 이어져 Devin 등 타 코딩 에이전트나 로컬 환경으로 맥락이 전달된다.
- 별도 PM이 없는 구조에서 엔지니어들은 'Hilltop' 문서를 작성해 요구사항과 마일스톤을 정의한다.
- PM 에이전트는 한 줄의 Slack 명령어로 Hilltop 초안, Linear 프로젝트, Decision Log를 자동 생성한다.
- 문서 승인 웹훅을 수신하면 에이전트가 후속 구현 작업을 티켓 단위로 자동으로 쪼개어 할당한다.
Context Engine과 MCP 게이트웨이 활용
에이전트가 도구를 적절히 탐색하고 사용할 수 있도록 내부 MCP 게이트웨이를 구축했다. Snowflake의 고객 상담 내역 및 제품 활용도 테이블의 구조를 설명하는 MCP 서버를 제공함으로써 에이전트가 올바른 SQL 쿼리를 생성하도록 유도했다. 이 시스템은 AI 에이전트뿐만 아니라 일반 구성원들이 Slack에서 직접 데이터를 조회하는 수단으로 활용 범위를 넓혔다.
- Context Engine은 Snowflake 데이터 레이크 및 내부 시스템과 에이전트를 연결한다.
- 시맨틱 테이블 설명과 시스템 프롬프트를 통해 에이전트의 데이터 쿼리 정확도를 높인다.
- 에이전트 전용으로 구축한 MCP 게이트웨이는 내부 팀원들의 Slack 데이터 분석 도구로 확장되었다.
자체 샌드박스 인프라와 자율 개선 메커니즘
소프트웨어 팩토리가 스스로 개선되는 자율 주행 상태에 도달하려면 인프라 제어권이 필수적이다. 외부 서비스 대신 자체 샌드박스를 구축하면 워크로드 이동과 메모리 계층 연동이 수월해진다. 세션 기록을 실시간 모니터링하여 에이전트의 실수를 감지하고, 유효성이 지난 오래된 스킬을 교체함으로써 시스템 전체의 코딩 정확도를 지속적으로 끌어올린다.
- Slack 지원 요청 및 버그 티켓을 웹훅으로 받아서 1차 분류 및 PR을 생성한다.
- 외부 SaaS 샌드박스에서 벗어나 자체 샌드박스 인프라를 구축해 세션 제어권을 확보한다.
- 실행 세션 데이터를 분석해 에이전트의 오류를 파악하고 필요한 AI 스킬을 준온라인 상태에서 업데이트한다.
설명
The standard software factory puts an agent in a sandbox, prompts it and merges the PR. When WorkOS built one, the results were hard to tell apart from engineers running Claude Code on their laptops. Ryan Cooke, an engineer at WorkOS, argues that counting PRs or lines of AI code is the wrong measure. What matters is outcomes: are you actually shipping more to customers? WorkOS's answer is to build its engineering process into the factory itself. TARS, its agent, lives in Slack, Linear and GitHub and uses webhooks to track projects and pick up the next ticket on its own. A PM agent drafts the "Hilltop" product doc and breaks approved work into tickets, which solves the blank-page problem. Horizon, the orchestration layer, sits in front of an internal MCP gateway that connects every tool, including Snowflake. Cooke calls that gateway the single best investment for any team starting a factory. He also covers bug and support triage, why WorkOS is building its own sandboxes and a company-wide memory layer, and how it measures success with defect rates, recovery time and adoption. Related links: WorkOS: https://workos.com Timestamps: 0:00 Intro: the standard software factory 1:17 Output metrics hide what's working 2:37 Measuring outcomes instead 3:12 Why a basic sandbox wasn't enough 4:07 TARS and Horizon 5:22 Webhooks: from code work to product work 6:32 Building the Hilltop doc into the factory 8:07 The PM agent 8:52 Demo: kicking off a project from Slack 10:17 Solving the blank-page problem 11:02 Works with Devin and Claude Code too 11:57 The MCP gateway: a context engine 13:37 Why every factory needs an MCP gateway 14:07 Bugs, support triage and our own sandboxes 15:27 Next: a company-wide memory layer 15:57 How we measure success 17:02 Owning the infrastructure to self-improve 18:02 Wrap-up
