No, That's Not a Software Factory — Ryan Cooke, WorkOS

한 줄 핵심

WorkOS는 단순히 코드만 생성하는 샌드박스형 software factory가 아니라, 웹훅·MCP 게이트웨이·내부 메모리 레이어를 결합해 제품 작업 전체를 자동화하고 성과까지 개선하는 시스템으로 재설계해야 한다고 주장한다.

시간별 요약

1. 0:00
   표준 소프트웨어 팩토리 일반적인 software factory는 샌드박스 안에 AI agent를 넣고 prompt로 PR을 생성해 머지하는 구조다. 이 접근은 널리 퍼졌지만, 코드 생성 자체만으로는 충분하지 않다는 문제의식이 출발점이 된다.
2. 1:17
   산출 지표는 무엇이 잘 작동하는지 가린다 PR 수나 생성된 코드량 같은 산출 지표는 실제로 가치가 나는지 보여주지 못한다. 자동화에 투입한 공수가 조직 성과로 이어지는지 보려면, 결과 중심의 지표가 필요하다.
3. 2:37
   산출이 아니라 성과를 측정하기 핵심 기준은 기능을 얼마나 더 빠르게 배포하느냐, 그리고 복잡한 기능을 얼마나 빨리 완성하느냐이다. 각 엔지니어에게 작은 팀을 붙여주는 효과를 내려면 더 많이 만드는 것보다 더 빨리 고객 가치로 연결되는지가 중요하다.
4. 3:12
   기본 샌드박스로는 부족했다 Cloudflare 기반 샌드박스와 open code model router만으로는 로컬에서 Claude Code를 쓰는 것과 큰 차이가 없었다. 코드 생성만 자동화해서는 부족했고, 엔지니어의 실제 업무 프로세스까지 팩토리에 넣어야 한다는 결론에 이른다.
5. 4:07
   TARS와 Horizon TARS는 Slack, Linear, GitHub 같은 도구 안에서 coding agent와 상호작용하는 계층이다. Horizon은 인프라 오케스트레이션 레이어로, 그 앞단의 MCP gateway를 통해 여러 내부 시스템을 연결한다.
6. 5:22
   웹훅으로 코드 작업을 제품 작업으로 바꾸기 Linear의 티켓 의존성과 완료 웹훅을 이용하면, 다음에 처리할 일을 agent가 자동으로 이어받을 수 있다. 작업 진행 중에 계획을 재검토하게 해 누락된 티켓을 찾으면, 초기 계획을 계속 갱신하면서 제품 엔지니어링 흐름을 유지할 수 있다.
7. 6:32
   Hilltop 문서를 팩토리에 넣기 WorkOS의 hilltop document는 목적, 고객 니즈, 경쟁 분석, 초기 디자인, 마일스톤을 한곳에 모은 PRD 역할을 한다. 이 문서를 agent가 읽고 작업 단위로 쪼갤 수 있게 만들면, 기존 제품 기획 절차를 자동화 파이프라인에 직접 encode할 수 있다.
8. 8:07
   PM agent PM agent는 짧은 brief를 바탕으로 hilltop 초안을 만들고, 사람의 리뷰를 반영하며, 구현을 티켓으로 분해한다. 인간이 각 단계에 개입할 수 있어도, 빈 문서에서 시작하는 초기 부담을 크게 낮춰준다.
9. 8:52
   Slack에서 프로젝트 시작하기 Slack의 간단한 명령만으로 새 프로젝트를 시작하면 TARS가 Linear 문서, 결정 로그, 열린 질문까지 첫 초안을 생성한다. 이후 제품 엔지니어가 맥락을 보강하고 다시 agent에 넘기면, 구현 단계로 자연스럽게 이어진다.
10. 10:17
    빈 페이지 문제 해결하기 agent가 초기 정보를 채워주면 문서와 기획을 시작하는 데 드는 심리적 장벽이 크게 낮아진다. 과하게 잡힌 범위는 사람이 줄이면 되므로, 시작 자체를 사람이 다 만드는 것보다 효율적이다.
11. 11:02
    Devin과 Claude Code도 함께 쓰기 이 구조는 TARS만 쓰는 것이 아니라 Devin이나 로컬의 Claude Code와도 연결된다. 같은 문서와 티켓을 컨텍스트로 제공하면, 각 도구가 공통의 작업 맥락 위에서 구현을 수행할 수 있다.
12. 11:57
    MCP 게이트웨이: 컨텍스트 엔진 MCP gateway는 내부 시스템을 연결할 뿐 아니라, 각 도구를 어떻게 써야 하는지와 정보가 어떻게 구조화되어 있는지도 설명해 주는 컨텍스트 엔진이다. Snowflake의 테이블 설명과 같은 메타정보를 함께 제공해 agent가 올바른 데이터를 찾고 쿼리하도록 돕는다.
13. 13:37
    모든 팩토리에 MCP 게이트웨이가 필요한 이유 내부 MCP gateway는 agent 연결용 부품이 아니라, 여러 내부 도구를 이해 가능한 형태로 묶는 공용 접점이다. Slack에서 직접 질의하는 데이터·고객 분석까지 확장되며, 다양한 AI 워크플로의 기반이 된다.
14. 14:07
    버그, 지원 분류, 그리고 자체 샌드박스 Slack으로 들어오는 버그 요청과 고객 지원 문의도 TARS가 먼저 분류하고 초기 수정 PR을 만들 수 있다. 다음 단계로는 자체 sandbox 인프라를 직접 구축해 session 정보를 더 깊게 통제하고 워크로드 이동도 자유롭게 하려 한다.
15. 15:27
    다음 단계: 회사 전체 메모리 계층 회사 전체 메모리 레이어는 모든 사람이 무엇을 하고 있는지, 어떤 팀에 속하는지, 어떤 제품을 맡는지를 지속적으로 담는 evergreen context를 목표로 한다. 이 맥락은 software factory 안팎의 다른 AI 도구에도 재사용될 수 있다.
16. 15:57
    성공을 측정하는 방법 성공은 단순한 출력량이 아니라 고객 가치, defect rate, time to recovery, 그리고 엔지니어가 실제로 TARS를 쓰는지로 본다. 로컬 harness보다 cloud sandbox를 선택하는 흐름도 가치의 신호로 해석한다.
17. 17:02
    인프라를 소유해야 스스로 개선할 수 있다 인프라를 직접 소유해야 agent 세션과 사용 패턴을 관찰해 무엇이 잘못되었는지, 어떤 skill이 필요한지, 어떤 지식이 obsolete인지 파악할 수 있다. 이런 관측성이 있어야 시스템이 계속 학습하고 개선된다.
18. 18:02
    마무리 핵심 메시지는 샌드박스와 PR 생성만으로는 부족하고, 팀의 엔지니어링 프로세스 전체를 automation에 encode해야 한다는 점이다. 실제로는 authorization 같은 미해결 문제도 남아 있어, 같은 고민을 하는 사람들과의 교류를 요청한다.

실무 인사이트

• software factory를 평가할 때 PR 수보다 기능 리드타임, defect rate, time to recovery 같은 결과 지표를 먼저 정의해야 한다.
• agent 자동화의 효과는 코드 생성보다 티켓·문서·웹훅을 연결해 작업 흐름 전체를 이어줄 때 커진다.
• 내부 MCP gateway와 메모리 레이어를 만들면 특정 agent용 도구를 넘어, 조직 전체의 AI 작업 공통 인프라로 확장할 수 있다.