Software Engineering Is Becoming Factory Engineering — Zach Lloyd, Warp

AI Engineer · 2026-09-28 02:30 · 20:37

한 줄 핵심

소프트웨어 개발은 점점 코드를 직접 쓰는 일이 아니라 에이전트와 인간이 함께 돌아가는 ‘소프트웨어 공장’을 설계·운영하는 일로 바뀌며, 성공하려면 제품 자체만이 아니라 자동화·평가·학습 루프까지 함께 구축해야 한다.

시간별 요약

0:00
소개 Warp 창업자이자 전 Google 엔지니어로서 20년 넘게 개발해 온 경험을 바탕으로, 소프트웨어 개발이 어떻게 자기개선형 공장 모델로 바뀌는지 설명한다.
0:55
Warp 소개 Warp는 에이전트가 내장된 오픈소스 개발 환경이며, 터미널에서 시작해 이제는 개발 자동화로 초점이 이동했다. 60,000개 이상의 GitHub 스타와 800,000명 이상의 활성 개발자를 기반으로 공개적으로 확장 중이다.
1:55
소프트웨어 공학이 공장 공학으로 바뀐다 개발의 중심이 채팅형 AI와 자동완성에서 상호작용형 에이전트로 이동했고, 다음 단계는 더 넓은 자동화로 향한다. 소프트웨어 공학은 점점 공장을 설계하고 운영하는 일과 비슷해진다.
2:10
자동완성에서 상호작용형 에이전트로, 다시 자동화로 최근 개발 방식은 사용자가 명령을 내리면 Claude Code나 Warp 같은 에이전트가 작업을 수행하는 구조로 변했다. 앞으로는 단일 작업 보조를 넘어 개발 흐름 전체를 자동화하는 방향으로 빠르게 이동한다.
2:50
손들기 에이전트 활용, 다중 에이전트 운용, 클라우드에서의 에이전트 실행, 전체 개발 생명주기 자동화가 이미 일부 실무에 들어와 있음을 보여준다. 규모가 큰 프로젝트는 결국 이런 공장형 구조를 갖게 될 가능성이 높다.
3:40
소프트웨어 공장 루프 아이디어가 들어오면 에이전트가 분류하고, 필요하면 명세를 작성한 뒤, 구현·검토·검증·모니터링을 거쳐 다시 입력으로 되돌리는 순환 구조가 핵심이다. 소프트웨어 엔지니어는 제품을 직접 쓰는 사람이라기보다 이 공장을 만들고 관리하는 사람에 가까워진다.
4:50
Warp가 오픈소스로 전환한 이유 Warp는 공개적인 개발 공장을 만들기 위해 오픈소스로 전환했고, build.warp.dev에서 이슈와 에이전트 작업 상태를 공개적으로 보여준다. 개발 비용이 급격히 낮아지면서 공개적으로 일하는 방식이 더 중요해졌다.
5:25
build.warp.dev: 공개 공장 build.warp.dev는 Warp의 오픈소스 작업 흐름을 외부에 그대로 보여주는 실험적 공장이다. 이 시스템은 에이전트와 기여자들이 어떤 작업을 어떤 상태로 처리 중인지 추적하게 한다.
5:35
소프트웨어는 만들기도, 복제하기도 싸다 소프트웨어를 만드는 비용이 낮아진 만큼, 경쟁자가 복제하는 비용도 함께 낮아졌다. 그래서 단순히 좋은 제품만으로는 가치 포착이 어렵고, 차별화 수단이 더 필요하다.
6:15
좋은 제품만으로는 충분하지 않다 좋은 제품은 여전히 필수지만, 배포, 생태계, 브랜드, 데이터 해자, 자본 같은 추가 우위가 있어야 한다. 스타트업은 이런 우위를 갖기 어려우므로 빌드 인 더 오픈 같은 전략이 중요해진다.
7:05
공개적으로 만들기 오픈소스와 공개 개발은 생태계와 커뮤니티를 키우고 브랜드를 강화하는 효과가 있다. 다만 과거에는 노이즈 많은 이슈, 지저분한 PR, 과도한 코드 리뷰가 큰 부담이었다.
7:35
자동화로 오픈소스의 고통 줄이기 이제는 오픈소스 운영 자체를 자동화한 소프트웨어 공장으로 관리할 수 있어서 공개 개발의 부담을 줄일 수 있다. Warp가 공개 전환을 결정할 수 있었던 이유도 이런 자동화 체계를 먼저 만들었기 때문이다.
8:25
공장에 필요한 것 효과적인 공장에는 자동화, 컨텍스트와 스킬 제공, 적절한 시점의 인간 개입, 자기개선 루프가 필요하다. 이런 구조가 있으면 에이전트는 기여를 돕고 유지보수도 돕는 역할을 맡을 수 있다.
9:05
모든 프로젝트에는 공장이 생긴다 공장 바닥은 입력이 들어와 여러 단계를 거치며 막히는 지점을 통과하는 그래프처럼 설계된다. 규모가 있는 프로젝트라면 결국 이런 흐름 관리 구조를 갖게 된다.
9:25
공장 현장 둘러보기 입력은 이슈 트래커, Slack, IDE, 터미널, 모니터링 시스템 등 여러 채널에서 들어온다. 중요한 것은 어떤 작업을 쉽게 자동 구현할지, 어떤 작업은 명세가 필요한지 먼저 가르는 것이다.
10:25
분류 에이전트가 들어온 이슈를 보고 단순하고 명확한 작업은 바로 구현하고, 어려운 작업은 명세 작성 단계로 넘겨야 한다. 이 단계가 공장 전체의 흐름을 크게 좌우한다.
10:50
제품 명세와 기술 명세 product spec은 만들고자 하는 제품의 불변 조건을, tech spec은 아키텍처와 코드 형태를 정의한다. 이 둘을 분리하면 구현 전 단계에서 의도를 더 명확하게 고정할 수 있다.
11:20
구현과 검토 클라우드에서 실행되는 코딩 에이전트가 diff를 만들고, 이어서 코드 리뷰가 진행된다. 처음에는 에이전트가 먼저 검토하고, 점차 인간 개입 시점을 위험도에 따라 조절하는 방식이 효율적이다.
11:55
검증 UI가 있는 제품이라면 컴퓨터 사용, 영상, 스크린샷 같은 방식으로 에이전트 결과를 실제로 검증해야 한다. CI/CD도 여전히 중요하며, 검증은 단순 코드 생성보다 훨씬 넓은 범위를 다룬다.
12:15
모니터링 배포가 끝나도 에이전트는 종료되지 않고, 실제 사용 중 충돌 여부와 활용 여부를 관찰해야 한다. 모니터링 결과는 다시 공장 상단으로 돌아가 다음 작업의 입력이 된다.
12:30
직접 만들 것인가, 살 것인가 소규모로는 내부에서 쉽게 만들 수 있지만, 제대로 확장되는 시스템은 생각보다 많은 인프라를 필요로 한다. 핵심 제품에 집중해야 하는 조직은 공장 인프라를 직접 구축하기보다 사는 선택이 더 나을 수 있다.
13:05
공장 아키텍처 공장은 작업 유입부, 분배를 담당하는 제어면, 실제 작업을 수행하는 샌드박스와 하네스, 그리고 학습을 담당하는 데이터 계층으로 나뉜다. 특히 아래쪽의 데이터 계층은 에이전트가 기억하고 점점 나아지게 만드는 기반이다.
13:50
측정하고 개선하기 공장은 단순한 제품이 아니라 효율을 계속 높여야 하는 운영 체계다. 산출량, 인간 시간, token 비용을 측정해 점진적으로 개선하는 것이 핵심이다.
14:20
스킬 개선 루프 에이전트가 특정 스킬을 실행하면, 관찰 에이전트가 그 결과를 보고 오류를 찾아 다음 실행에 반영해야 한다. 예를 들어 code review agent가 틀린 코멘트를 남기면 이를 학습해 더 나아지게 만들 수 있다.
15:10
엔지니어의 역할은 어떻게 바뀌는가 이제 엔지니어는 제품을 만드는 동시에 제품을 만드는 시스템 자체를 만들어야 한다. 코드를 덜 쓰는 대신 더 많이 출시하게 되며, 그 과정에서 메타-엔지니어링 같은 새로운 난제가 생긴다.
16:35
시작용 저장소 누구나 자신의 공장형 에이전트를 시도해 볼 수 있도록 오픈소스 GitHub 저장소가 제공된다. 이를 통해 triage나 spec 작성 같은 작업을 이론이 아니라 실제 구현으로 옮길 수 있다.
17:20
질문과 답변: 만들기 대 사기 대부분의 회사는 공장 자체를 직접 만들기보다 핵심 제품에 집중하는 편이 낫지만, 공장을 자기 제품에 맞게 조정하고 튜닝하는 작업은 여전히 중요한 엔지니어링 과제다.
18:15
질문과 답변: 신입 졸업생을 위한 조언 새로운 환경에서 중요한 역량은 적응력, 비판적 사고, 빠른 학습 속도다. 시스템과 아키텍처를 이해하고, 에이전트가 작성한 spec과 코드를 해석할 수 있는 능력이 특히 중요하다.
19:30
질문과 답변: 취향과 제품 감각 자동화와 공장 비유가 중요하더라도, 결국 가치 있는 것을 만드는 감각이 핵심이다. 인간의 취향, 입력, 제품 감각은 자동화할 수 없는 지점에서 여전히 필수적이다.

실무 인사이트

에이전트 도입의 핵심은 단일 기능이 아니라 triage→spec→구현→검증→모니터링을 잇는 전체 루프를 설계하는 것이다.
오픈소스나 공개 개발은 홍보 전략이 아니라, 자동화된 운영 체계가 있을 때만 지속 가능한 생산 방식이 된다.
실무에서는 코드를 더 잘 쓰는 것보다, 에이전트가 더 잘 일하게 만드는 명세·검증·관찰 구조를 만드는 역량이 더 중요해진다.