The AI factory playbook for engineering teams
📺 원본 영상: The AI factory playbook for engineering teams
🎙️ 채널: How I AI
📅 정리 일자: 2026-09-22
⚠️ Note: 본 리포트는 영상 음성의 STT를 바탕으로 작성된 리포트를 검수한 것이다. 이번 검수에는 원본 STT와 영상·스크린샷의 실제 내용이 제공되지 않아, 표현과 문서 내부의 일관성을 점검했으며 발화와 수치를 원본에 대조하지는 못했다. 화면에 표시된 차트, 코드, 슬라이드는 직접 확인하지 않았다. 모델명과 버전처럼 STT만으로 확정하기 어려운 정보는 구체적인 표기를 생략했다.
개요
코딩 에이전트가 구현 속도를 높여도, 엔지니어링 조직 전체의 제품 출시 속도가 같은 비율로 빨라지는 것은 아니다. How I AI에 출연한 Warp CEO Zach Lloyd는 이러한 간극을 줄이는 접근으로 소프트웨어 팩토리(Software Factory)를 소개하며, 개별 개발자의 코딩 자동화를 조직 차원의 실행·측정·개선 체계로 확장하는 과정을 설명한다. 이 대화의 핵심은 더 많은 코드를 생성하는 방법에서 출발해, 무엇을 자동화하고 어떤 결과를 검증하며 그 경험을 다음 작업에 어떻게 반영할 것인지로 이어진다.
코딩 에이전트에서 소프트웨어 팩토리로
Zach가 설명하는 소프트웨어 팩토리는 여러 에이전트를 동시에 실행하는 환경보다 구체적인 개념이다. 저장소(Repository), MCP 서버, 설정, 역할별 에이전트, 자동화 절차를 하나의 정의로 묶어 소프트웨어 개발을 수행하는 시스템을 뜻한다. 여기서 MCP(Model Context Protocol)는 에이전트가 외부 도구와 맥락을 활용하는 연결 수단으로 등장하며, 팩토리에는 코드 리뷰처럼 서로 다른 책임을 맡은 에이전트가 포함된다. 중요한 점은 이러한 구성이 코드로 정의되므로, 팩토리 자체가 변경하고 시험할 수 있는 대상이 된다는 것이다.
그는 팩토리를 사용하는 사람을 크게 두 관점으로 구분한다. 빌더(Builder)는 아이디어를 제안하고 실제 결과물을 만들려는 사람으로, 엔지니어뿐 아니라 디자이너나 제품 담당자도 여기에 해당한다. 관리자는 개별 작업의 성공을 넘어, 팀이 얼마나 빠르게 움직이고 비용을 얼마나 쓰며 개발 방식이 개선되고 있는지 알아야 하는 사람이다. 빌더에게 팩토리는 작업을 맡기는 인터페이스로 보이지만, 관리자에게는 조직 전체의 실행을 관찰하고 조정하는 운영 체계로 기능한다.
이 구분은 영상에서 다루는 자동화의 범위를 이해하는 출발점이다. 로컬 코딩 에이전트는 사용자가 요청한 변경을 구현하는 데 집중할 수 있지만, Warp가 보여주는 팩토리는 요청 접수부터 이슈 추적, 구현, PR 생성, QA까지 여러 단계를 연결한다. 여기에 작업 기록을 평가하고 시스템 구성을 개선하는 과정이 추가되면서, 자동화의 대상은 코드 작성뿐 아니라 코드가 만들어지는 절차까지 넓어진다. 따라서 영상의 팩토리는 특정 모델의 성능만으로 설명하기 어려우며, 모델이 움직이는 조직적 환경까지 포함하는 개념이다.
작업이 공개된 공간에서 시작될 때 달라지는 것
Warp 팀의 사례에서 작업의 출발점은 공개 Slack 채널이다. 팀원은 Wilson이라는 이름의 팩토리를 태그하고 원하는 변경을 설명하며, 필요하면 이미지나 구체적인 검증 요구를 함께 전달한다. 팩토리는 이를 바로 실행할 명령으로만 받아들이지 않고, 먼저 요청을 분류하고 처리 방향을 정하는 트리아지(Triage)를 수행한다. 이어 Linear에 이슈를 만들고 구현을 진행한 뒤 GitHub에 PR(Pull Request)을 생성하면서, 대화와 개발 기록이 연결되는 흐름을 만든다.
Zach가 강조하는 차이는 이 모든 과정이 팀이 볼 수 있는 공간에서 이루어진다는 점이다. 개인의 로컬 환경에서 에이전트와 주고받은 대화는 다른 사람이 접근하기 어렵지만, 공개 스레드에서는 동료가 요청의 맥락과 진행 과정을 확인하고 추가 의견을 보탤 수 있다. 실제로 Warp에서는 여러 사람이 같은 Slack 스레드에 참여하며 작업에 기여한다고 설명한다. 작업 결과뿐 아니라 결과에 이르는 과정까지 공유되기 때문에, 협업의 단위가 완성된 코드에서 진행 중인 문제 해결 과정으로 확장된다.
작업을 시작하는 주체도 사람으로 한정되지 않는다. Zach는 Sentry의 크래시 보고를 신호로 받아 수정 작업을 자동으로 시작하는 사례를 소개하며, Slack 외에 Linear나 GitHub에서도 작업을 시작할 수 있다고 말한다. 이 구조에서는 사람이 낸 아이디어와 외부 시스템이 발견한 문제가 공통된 처리 흐름으로 들어온다. 팩토리의 역할은 특정 채팅 도구에 응답하는 데 머물지 않고, 여러 경로에서 발생한 요구를 일관된 개발 절차에 연결하는 것으로 넓어진다.
구현 완료를 넘어 동작의 증거를 남기는 QA
시연에서 팩토리는 PR을 생성한 뒤 컴퓨터 사용 검증(Computer-use Verification)을 수행한다. Zach의 설명에 따르면 에이전트는 완성된 기능을 실제로 조작하고, 키 입력을 포함한 동작 과정을 영상으로 남겼다. 검토자는 코드 변경뿐 아니라 기능이 어떻게 작동했는지 보여주는 자료도 함께 받게 된다. 이는 요청한 기능의 구현 여부를 확인하기 위해 사람이 다시 환경을 준비하고 동일한 조작을 반복해야 하는 부담을 줄이려는 접근이다.
06:57 - 완성된 기능과 키 입력을 보여주는 QA 검증 영상을 설명하는 구간. 실제 영상 화면과 검증 범위 확인 지점.
이러한 검증 자료가 모든 품질 문제를 해결한다는 주장은 영상에 등장하지 않는다. 실제로 Warp는 뒤에서 설명하듯 모든 PR에 사람의 코드 리뷰를 유지하고 있으며, 컴퓨터 사용 검증은 그 검토를 지원하는 수단으로 제시된다. 화면에서 기능이 작동하는 모습과 코드의 변경 내용은 서로 다른 종류의 정보를 제공하기 때문에, 두 자료를 함께 보는 것이 이 흐름의 핵심이다. 다만 검수 대상 리포트에는 실제 테스트 코드나 검증 시나리오의 전체 범위가 없으므로, 어떤 예외 상황까지 확인했는지는 확정할 수 없다.
💡 [영상 참조] 약 06:31~07:28 구간에서 기능 구현 후 QA 영상과 관련 산출물을 설명한다. 실제 조작 화면과 검증 범위는 원본 영상을 확인해야 한다.
조직 차원의 자동화를 보려면 사람의 개입도 측정해야 한다
Zach는 개별 개발자가 각자의 로컬 환경에서 에이전트를 사용하는 구조에서는 조직 전체의 상태를 파악하기 어렵다고 말한다. 누가 어떤 설정으로 작업하고 있는지, 얼마나 많은 비용을 쓰는지, 자동화가 실제로 개선되고 있는지를 공통된 기준으로 보기 어렵기 때문이다. Warp의 팩토리는 실행을 클라우드에 중앙화하고, 자동화 수준과 작업 속도, 소요 시간 등을 한곳에서 관찰할 수 있도록 구성된다. 관리자의 관점에서 중요한 변화는 에이전트 사용량이 늘어나는 것 자체보다, 그 사용이 어떤 결과를 내는지 비교할 수 있게 된다는 점이다.
대화에서 특히 주목한 지표는 PR당 사람의 상호작용 횟수(Human Interactions per PR)다. 이 지표에는 Slack에서 다시 지시한 횟수, Linear에 남긴 의견, 코드 리뷰 과정에서 수정하도록 요구한 개입 등이 포함된다. Zach는 이를 에이전트가 일을 끝내도록 만들기 위해 사람이 얼마나 수고해야 했는지 보여주는 대리 지표(Proxy)로 설명한다. 초기 프롬프트 하나만 세는 방식과 달리, 여러 업무 도구에 흩어진 후속 개입을 함께 집계한다는 점이 특징이다.
14:28 - PR당 사람의 상호작용 지표에 Linear 댓글과 코드 리뷰 수정 요청 등이 포함된다고 설명하는 구간.
그 배경에는 사람이 계속 방향을 바로잡아야 하는 자동화는 처리량을 확장하는 데 한계가 있다는 판단이 있다. 에이전트의 실행 속도가 빨라도 사람이 반복해서 재지시하고 수정해야 한다면, 작업량 증가가 곧바로 사람의 업무 증가로 돌아올 수 있다. 다만 Zach 자신도 적절한 지표를 찾아가는 단계이며 현재 정의를 개선할 여지가 있다고 인정한다. 따라서 이 수치를 사람의 기여도나 작업 가치의 절대적 평가로 읽기보다, 자동화가 요구하는 개입 부담을 이해하기 위한 시도로 보는 것이 대화의 취지에 가깝다.
35분의 구현과 3시간 30분의 대기
진행자는 대시보드의 수치를 짚으며 작업 시작부터 PR 생성까지는 35분이지만, PR 생성부터 첫 사람 리뷰까지는 3시간 30분이 걸린다고 말한다. 코드 생성 과정이 빨라진 뒤에도 리뷰 대기 구간에는 더 긴 시간이 남아 있다는 것이다. Zach는 이를 부정하지 않으며, 당시 Warp에서는 모든 PR이 사람의 코드 리뷰를 받는다고 설명한다. 이 사례는 구현 시간의 단축과 전체 개발 사이클 타임(Cycle Time)의 단축을 구분해야 한다는 문제를 드러낸다.
| 항목 | 원문 리포트에 기재된 발언 내용 | 해석 시 구분할 점 |
|---|---|---|
| 작업 시작부터 PR 생성 | 35분 | 시연 당시 언급된 값이며, 평균·중앙값 여부는 설명되지 않았다. |
| PR 생성부터 첫 사람 리뷰 | 3시간 30분 | 첫 리뷰까지의 시간으로, 최종 병합까지의 시간은 아니다. |
| 사람 리뷰 적용 범위 | 당시 모든 PR | 향후 일부 작업에서 생략할 가능성은 별도로 논의했다. |
| 최근 한 달 PR 규모 | 진행자가 2,000건 이상으로 언급 | 질문 속 대략적 언급이며, 병합 건수나 품질 성과로 확정할 수 없다. |
두 시간 값을 단순 환산하면 PR 생성 후 첫 리뷰까지의 대기 시간은 작업 시작부터 PR 생성까지 걸린 시간의 여섯 배다(210분 ÷ 35분 = 6). 이는 원문 리포트에 기재된 수치에서 계산한 비교이며, 작업 유형이나 측정 분포를 통제한 분석은 아니다. 그럼에도 대화에서 이 수치가 중요한 이유는 에이전트의 구현 성능만 높여서는 해결되지 않는 대기 구간을 보여주기 때문이다. 리뷰를 시작할 사람의 가용 시간과 검토 방식이 전체 흐름에 큰 영향을 줄 수 있다는 점이 구체적으로 드러난다.
Warp가 이미 바꾼 부분은 요청자와 리뷰어의 분리 규칙이다. 이전에는 한 사람이 에이전트로 변경을 만들면 다른 사람이 그 코드를 검토했지만, 이제는 에이전트에 요청한 사람이 결과 코드도 리뷰할 수 있도록 허용한다. Zach는 이를 팀과 조직이 결정할 문제로 설명하며, 아직 완전히 신뢰하지 못하기 때문에 사람 리뷰 자체는 유지하고 있다고 말한다. 따라서 영상의 운영 상태를 사람 검토 없이 코드가 자동 병합되는 체계로 해석해서는 안 된다.
코드 리뷰는 위험에 따라 사람의 주의를 배분하는 일로 바뀐다
진행자는 리뷰 병목을 다루는 별도 사례로 자신이 만든 Merge Mommy라는 에이전트를 소개한다. 이 흐름에서는 각 PR의 위험도를 자동으로 평가하고, 낮거나 매우 낮은 위험으로 분류된 변경에는 에이전트가 승인 표시를 남긴다. 이후 사람이 병합 버튼을 누를 수 있게 하되, 중간 이상 위험이거나 특이한 위험 신호가 있는 변경은 사람의 검토를 요구한다. 이는 Warp가 당시 그대로 사용하고 있다고 밝힌 방식이 아니라, 진행자가 제시한 위험 기반 리뷰 사례다.
이 제안의 목적은 사람의 검토 역량을 더 중요한 변경에 집중시키는 데 있다. 모든 PR이 동일한 수준의 관심을 요구한다고 가정하면, 변경량이 늘수록 검토 대기열이 커질 수밖에 없다는 문제의식이다. Zach도 코드 리뷰가 위험 관리(Risk Management)의 성격을 갖게 된다는 관점에 동의한다. 다만 구체적인 위험도 계산 기준이나 오분류를 검증하는 방식은 설명되지 않았으므로, 이 대화에서 얻을 수 있는 것은 운영 방향이며 완성된 위험 평가 명세는 아니다.
비용 최적화의 출발점은 모델 구성을 시험하는 것
비용 대시보드를 설명하면서 Zach는 표시된 금액이 사람의 인건비를 제외한 에이전트 비용이라고 선을 긋는다. 그는 몇 주 전 비용이 높았지만 모델 구성을 바꾼 뒤 이를 낮출 수 있었다고 말한다. 진행자가 가장 큰 비용 조절 수단을 묻자, Zach는 모델 선택이 가장 크고 맥락 관리(Context Management)도 그다음으로 중요하다고 답한다. 다만 검수 대상 리포트에는 화면의 구체적인 금액이나 절감률이 기재되어 있지 않으므로 수치로 재구성할 수 없다.
17:35 - 모델 구성 변경 후 에이전트 비용이 낮아졌다고 비용 대시보드를 설명하는 구간.
이 설명은 저렴한 모델로 일괄 교체하면 된다는 결론으로 이어지지 않는다. Zach는 적절한 선택을 판단하려면 시험해야 한다고 강조하고, 뒤에서 실제 과거 작업을 다른 구성으로 다시 실행하는 방식을 보여준다. 같은 작업에서도 비용과 품질이 함께 달라질 수 있기 때문에, 모델의 가격만 비교해서는 운영상 유리한 구성을 결정하기 어렵다는 흐름이다. 또한 앞서 소개한 사람의 개입 횟수와 나란히 생각하면, 이 대화는 에이전트 비용과 사람이 들이는 수고를 구분해 관찰할 필요성을 보여준다.
평가 에이전트로 반복되는 실패를 발견한다
팩토리는 작업을 실행할 때마다 기록을 남기고, 이 기록을 활용해 실행 결과를 사후 평가한다. Zach는 사람이 과거 작업을 하나씩 읽어볼 수도 있지만, 다른 에이전트에게 평가를 맡기는 방식도 사용할 수 있다고 설명한다. 여기서 등장하는 방식이 LLM-as-a-Judge, 즉 언어 모델을 평가자로 사용하는 접근이다. 구현한 에이전트와 별개의 평가 에이전트가 특정 기준에 따라 실행을 살펴보면서, 여러 작업에서 반복되는 문제를 찾는다.
구체적인 예시는 불필요하게 중복된 테스트(Redundant Tests)다. Zach에 따르면 에이전트는 회귀를 방지하기 위한 테스트뿐 아니라 작업 도중 동작을 확인하려는 테스트도 작성하므로, 결과적으로 필요 이상의 테스트가 남을 수 있다. 팩토리에서는 이런 현상을 평가 항목으로 정의하고, 각 실행에서 불필요한 테스트가 있었는지를 다른 모델이 판정하도록 할 수 있다. 대화의 초점은 테스트 수 자체를 줄이는 데 있지 않고, 추가된 테스트가 실제로 필요한지를 지속해서 관찰하는 데 있다.
21:28 - 중복 테스트 평가에서 불필요한 테스트가 있다고 판정된 실행 기록들을 설명하는 구간.
평가에도 비용이 들기 때문에 평가 모델의 능력과 실행 빈도를 조정한다. Zach는 평가에 지나치게 비싼 모델을 사용하면 채점 비용이 커진다고 설명하며, 적절한 평가 모델과 샘플링 비율을 선택하는 방식을 언급한다. 따라서 전체 실행을 가로질러 평가 체계를 운영한다는 설명이 모든 평가 항목을 모든 실행에 빠짐없이 적용한다는 뜻은 아니다. 이 구조가 제공하는 것은 정답의 자동 확정이라기보다, 사람이 검토할 만한 문제와 추세를 체계적으로 드러내는 신호라고 이해할 수 있다.
자기 개선은 단일 실패보다 반복되는 증거에서 출발한다
Zach는 실행을 평가하는 루프와 팩토리를 개선하는 루프를 구분한다. 첫 번째 루프가 개별 작업의 문제를 식별한다면, 두 번째 루프는 실패한 작업들을 모아 관찰 에이전트(Observer Agent)가 공통된 원인을 살펴보는 과정이다. 그는 예를 들어 실패 실행 20~25개 정도의 표본이 필요하다고 말하며, 단일 사례에 반응하면 과도하게 교정할 수 있다고 지적한다. 이 숫자는 통계적으로 검증된 보편적 기준이 아니라, 충분한 사례를 모으라는 취지에서 제시된 예시다.
시연에서 관찰 에이전트는 팩토리를 구동하는 스킬의 문제를 찾고, 근거와 함께 에이전트 정의를 바꾸는 제안을 제시한다. 원문 리포트에는 특정 에이전트가 수행해야 할 절차 중 10번째 단계를 변경한다고 기재되어 있지만, 실제 변경 전후의 문구는 제공되지 않는다. 따라서 어떤 규칙이 잘못되었고 어떤 문장으로 교체되었는지까지 재구성할 수는 없다. 확인할 수 있는 핵심은 실행에서 얻은 증거가 이후 실행을 지시하는 구성의 수정으로 이어진다는 점이다.
23:23 - 관찰 에이전트의 개선 제안이 팩토리 에이전트 정의의 특정 단계를 변경한다고 설명하는 구간.
이때 자기 개선(Self-improvement)은 기저 모델의 가중치를 다시 학습시킨다는 의미로 설명되지 않는다. 영상에서 수정 대상으로 제시되는 것은 팩토리의 스킬, 에이전트 정의와 같은 코드로 관리되는 구성이다. 또한 제안된 변경이 어떤 승인 절차를 거쳐 실제 환경에 적용되는지도 구체적으로 다루지 않는다. 그러므로 이를 무제한으로 스스로 바뀌는 자율 시스템으로 확대하기보다, 실패 분석을 운영 규칙의 개선으로 연결하는 방식으로 이해하는 편이 정확하다.
코드로 정의된 팩토리는 비교 실험의 대상이 된다
팩토리를 코드로 정의하는 이유는 변경을 쉽게 만들기 위해서만은 아니다. Zach는 특정 시점의 팩토리 상태를 고정하고, 정의를 바꾼 뒤 같은 작업들을 다시 실행해 개선 여부를 살펴볼 수 있다고 설명한다. 실행 환경의 구성을 비교 가능한 대상으로 다루면서, 변경 효과를 경험적 인상보다 실험 결과로 판단하려는 것이다. 동시에 구성 자체가 코드이므로 코딩 에이전트가 개선안을 작성할 수 있다는 점도 장점으로 제시된다.
여기서 다음 단계로 등장하는 것이 과거 세션의 재실행, 즉 리플레이(Replay)다. 공개 벤치마크인 SWE-bench나 Terminal-Bench가 일반적인 작업 집합을 제공한다면, 팩토리에 쌓인 기록은 해당 조직이 실제로 수행했던 작업 집합을 제공한다. Zach는 이를 다른 모델 구성으로 다시 실행하면 비용과 품질이 어떻게 달라졌을지 비교할 수 있다고 말한다. 모델을 평가하는 질문이 공개 순위에서의 위치를 넘어, 우리 팀의 작업에서 어떤 결과를 내는지로 구체화되는 것이다.
그는 프런트엔드 작업을 모아 서로 다른 모델로 수행하게 하는 예시를 든다. 이때 비용과 품질의 관계를 보여주는 차트를 언급하며, 조직이 원하는 절충점을 선택할 수 있다고 설명한다. 다만 원문 리포트에서 일부 모델명과 버전은 불확실한 것으로 처리되어 있으므로, 특정 모델이 다른 모델보다 우수하다는 제품별 결론은 여기서 재현하지 않는다. 여기서 설명하는 방법론은 작업 유형별 비교 결과를 모델 라우팅(Model Routing) 전략에 반영한다는 것이다.
30:19 - 과거 작업의 재실행 결과를 바탕으로 비용과 품질의 절충점을 선택하고 모델 라우팅에 반영하는 구간.
이 실험의 품질 판정에는 앞서 소개한 평가 인프라를 다시 사용한다. 진행자가 프런트엔드 구현에는 여러 타당한 해법이 있을 수 있는데 무엇을 더 좋은 결과로 보느냐고 묻자, Zach는 기존 평가 항목에서 점수가 어떻게 달라졌는지를 본다고 답한다. 현재 구축한 방식은 주로 LLM-as-a-Judge이지만, 사람이나 알고리즘으로 평가할 수도 있다고 덧붙인다. 따라서 리플레이의 결론은 평가 기준에 대한 신뢰에 의존하며, 실제 출시된 코드와 같은 모양인지를 단순 비교하는 방식으로 설명되지는 않는다.
실행 기록이 있어야 개선의 원인도 찾을 수 있다
진행자는 이러한 접근의 기반을 세션 수준의 관측 가능성(Observability)에서 찾는다. 최종 PR만 보는 대신 세션, 도구 호출, MCP 호출, 테스트 실패, 컴퓨터 사용 수준의 기록을 확보해야 최적화 기회를 찾을 수 있다는 주장이다. 그는 일부 조직이 로컬 코딩 세션을 S3에 수집하고 자체 플랫폼에서 평가를 수행한다고 소개한다. 이는 Warp의 제품을 사용하지 않더라도 유사한 관측·평가 체계를 구성하는 접근이 존재한다는 맥락에서 나온 설명이다.
대화 전체를 연결하면 기록, 평가, 개선, 재실행이 하나의 순환 구조를 이룬다. 기록은 문제가 발생한 과정을 남기고, 평가는 여러 실행에서 반복되는 문제를 분류하며, 개선 과정은 그 증거를 팩토리 정의의 변경으로 전환한다. 이후 재실행은 바뀐 구성이 기존 작업에서 어떤 결과를 내는지 비교하게 해준다. 이 연결이 중요한 이유는 단순히 실패를 많이 모으는 데 그치지 않고, 운영 방식을 바꾼 효과까지 확인하려 하기 때문이다.
코딩 에이전트는 CEO의 비개발 업무에도 쓰인다
대화 후반부에서 Zach는 Figma Slides 수정, 영업 미팅 분석, 과거 영업 기회 탐색을 각각 에이전트에 맡긴다. Figma 작업에서는 MCP를 통해 기존 슬라이드의 맥락을 가져오고, 원본을 직접 수정하지 말고 복제본을 만들도록 지시한다. 이어 상자 사이의 포함 관계를 조정하고, 맥락 시스템을 구름처럼 표현하며, 실행을 시작하는 요소에는 로켓 이미지를 활용해 달라고 요청한다. 핵심은 장식적 요소를 추가하는 것과 함께 구성요소 사이의 의미적 관계를 시각적으로 전달하려 한다는 점이다.
이 시연은 음성 입력을 활용한 작업 지시의 사례이기도 하다. Zach는 말로 요구사항을 전달하면서 중간에 표현을 수정하며, 코딩 에이전트를 Figma 조작의 인터페이스로 사용한다. 다만 방송 중 확인한 결과에 대해서는 아직 좋지 않고 더 개선되어야 한다고 평가한다. 따라서 이 사례는 전문적인 디자인 결과가 즉시 완성되었다는 증거가 아니라, 익숙하지 않은 도구에서도 의도를 전달해 변경을 시도할 수 있다는 사용 사례다.
두 번째 작업에서는 Granola MCP로 최근 4주간의 영업 미팅을 살펴보고, Warp 소프트웨어 팩토리와 관련해 자주 나온 질문 10개를 추려 달라고 요청한다. 공개 방송이라는 맥락 때문에 특정 고객의 정보는 포함하지 말고 익명화하라는 조건도 명시한다. 이후 결과를 확인하며 Zach는 구매할 것인지 직접 구축할 것인지에 관한 문제, 보안, 작업 흐름, 측정, 비용 관리 등이 고객 질문에 등장한다고 설명한다. 그는 이 내용을 영업 자료와 웹사이트에 반영하거나 FAQ로 발전시켜, 실제 고객의 관심사와 제품 설명을 맞추려 한다.
39:49 - 영업 미팅 분석 결과에서 보안, 작업 흐름, 측정, 비용 관리 등 고객 질문의 주제를 확인하는 구간.
세 번째 작업은 과거 6개월간의 이메일과 캘린더에서 다시 연락할 만한 잠재 기업 고객을 찾는 것이다. Zach는 제품이 크게 달라졌으므로 과거에는 적합하지 않았던 잠재 고객에게 다시 접근할 여지가 있다고 설명한다. 에이전트에는 관련 정보를 Google Sheets로 정리하고 링크를 제공하되, 현재 대화에는 고객 이름이나 이메일을 출력하지 말라고 요청한다. 이 작업의 최종 결과는 검수 대상 리포트에서 확인되지 않으며, 실제 고객에게 연락을 보냈다는 설명도 없다.
이 세 작업은 동시에 시작되지만, 모두 영업 활동이라는 공통된 목적을 갖는다. 고객이 무엇을 묻는지 파악하고, 그 질문에 맞게 설명 자료를 고치며, 달라진 제품에 관심을 가질 대상을 찾는 흐름이다. Zach가 보여주는 변화는 기술자가 비기술 업무를 수행할 때 도구 조작의 부담을 줄일 수 있다는 데 있다. 그러나 포지셔닝이 적절한지와 어떤 고객에게 접근할지는 여전히 사람이 판단하는 과제로 남는다.
작업량이 늘어날수록 무엇을 만들지에 대한 판단이 중요해진다
진행자는 한 달에 2,000건이 넘는 PR이 발생하는 상황에서 팀이 어떻게 혼란을 피하고 중요한 일을 하고 있는지 확인하느냐고 묻는다. Zach의 답은 기존 소프트웨어 개발 원칙의 상당 부분이 여전히 유효하다는 것이다. Warp 팀은 자신들이 만든 제품을 지속적으로 사용하는 도그푸딩(Dogfooding)을 통해 품질을 확인하고, 사용자 인터뷰와 실제 사용 관찰도 이어간다고 설명한다. 구현 속도가 빨라졌다고 해서 제품이 풀어야 할 문제를 발견하는 과정까지 자동으로 해결되지는 않기 때문이다.
개발 전 디자인 잼(Design Jam)을 진행하는 이유도 같은 맥락이다. Zach는 이 시간이 UI의 세부 모양을 미리 확정하는 데만 쓰이는 것이 아니라, 올바른 사용자 스토리를 다루고 있는지 확인하는 데 중요하다고 말한다. 아무리 빠르게 소프트웨어를 만들어도 사용자 문제를 적절히 해결하지 못하면 의미가 없다는 판단이다. 팩토리는 실행 능력을 확대하지만, 그 능력을 어떤 문제에 사용할 것인지를 정하는 책임까지 없애지는 않는다.
공개된 작업 방식은 팀의 학습에도 영향을 준다. Zach에 따르면 팀에는 에이전트를 매우 능숙하게 쓰는 사람과 상대적으로 평균적인 수준으로 활용하는 사람이 함께 존재한다. 공개 Slack 스레드에서 숙련자의 작업 방식을 볼 수 있으면, 다른 팀원도 그 사람이 어떻게 지시하고 문제를 해결하는지 접할 기회를 얻는다. 공개 협업은 진행 상황을 공유하는 수단이면서, 개인의 활용 노하우를 팀 전체가 배울 수 있도록 만드는 통로이기도 하다.
마무리 / 핵심 정리
이 대화에서 소프트웨어 팩토리는 개발을 더 빠르게 수행하는 수단과, 개발 방식을 지속적으로 개선하는 수단을 함께 뜻한다. Slack에서 시작한 요청이 이슈, 구현, PR, QA로 연결되는 흐름은 개별 작업의 수행을 자동화한다. 그 위에서 실행 기록을 평가하고 팩토리 정의를 수정하며 과거 작업을 재실행하는 흐름은 자동화 자체를 개선한다. 두 흐름이 연결될 때 코딩 에이전트의 사용 경험이 조직 차원의 운영 지식으로 축적된다.
35분의 PR 생성 시간과 3시간 30분의 첫 리뷰 대기는 이 변화의 긴장을 보여준다. 구현 능력이 커질수록 사람의 검토와 의사결정이 전체 흐름에서 차지하는 비중이 더 선명해지지만, Warp는 당시에도 모든 PR에 사람의 리뷰를 유지했다. 대화가 제시하는 방향은 사람의 개입을 무조건 없애는 데 있지 않고, 어떤 개입이 반복적인 부담이며 어떤 개입이 품질과 제품 방향을 위해 필요한지 구분하는 데 있다. 위험에 따른 리뷰, 작업별 모델 선택, 실패에 근거한 구성 개선은 모두 그 구분을 정교하게 만드는 시도다.
Zach가 마지막에 강조하는 사용자 문제의 중요성은 앞선 자동화 논의의 기준점이 된다. 비용과 처리량, 개입 횟수를 측정하더라도 잘못된 문제를 빠르게 해결하고 있다면 제품의 가치는 보장되지 않는다. 따라서 영상에서 읽어낼 수 있는 엔지니어링 팀의 과제는 실행을 에이전트에 맡길수록 목적과 평가 기준을 더 분명하게 만드는 것이다. 팩토리의 성숙도는 생성한 코드의 양뿐 아니라, 결과를 검증하고 실패에서 배우며 그 속도를 실제 사용자 가치로 연결하는 능력에서 드러난다.
📚 출처 및 참고
본문은 STT 기반 원문 리포트를 검수했으며, 외부 자료로 제품 기능이나 성능 주장을 추가하지 않았다. 광고 구간은 본론에서 제외했고, Warp의 실제 운영 설명과 진행자가 소개한 별도 사례를 구분했다. 원문에는 불확실 수치를 나타내는 [?] 표기가 없었으며, 수치를 교정할 원본 근거가 없어 기존 값을 유지했다. 3시간 30분을 210분으로 환산한 뒤 35분과 비교하는 계산은 확인했다. 스크린샷 목록에는 로컬 경로만 있고 webUrl이 없어 이미지를 삽입하지 않았다.
| 구분 | 내용 |
|---|---|
| 원본 영상 | The AI factory playbook for engineering teams |
| 채널 | How I AI |
| 주요 출연자 | Zach Lloyd — Warp CEO |
| 원문에 기재된 STT 범위 | 00:00~46:41 |
| 리포트 작성 | 2026-09-22 |
| 작성 방식 | 제공된 STT 기반 리포트의 표현·내부 일관성 검수 |
| 자료의 한계 | 원본 STT·음성·화면 미대조, 일부 모델명·버전 불확실, 수치의 집계 방식 미제공, 스크린샷 webUrl 미제공 |
💬 본 리포트는 영상 내용을 바탕으로 재구성되었다. 정확한 표현과 화면 자료는 원본 영상을 참조해야 한다.
Related Reports
- Don’t Build Agents You Can’t Answer For — Addy Osmani
- Stop Burning Tokens - Why self-improvement needs domain expertise first - Annabell Schafer, Langfuse
- ReviewDebt - a practical framework for scoring every pull request — Sachin Gupta, Ebay
- Velocity Sickness - What Happens When Your Whole Team Gets 10x Faster — Matt Dailey, Ref.
- What Does Done Even Mean? Agents and Paperclip’s Liveness Model - Dotta, Paperclip