[한영자막] 소프트웨어 엔지니어링은 이제 소프트웨어 공장을 짓는 일이 될 것입니다 — Zach Lloyd (Warp)

Tech Bridge · 2026-10-02 22:00 · 20:09

AI 개발 방법론 업무 자동화 제품·창업

YouTube에서 보기

한 줄 핵심

소프트웨어 엔지니어링은 점점 코드를 직접 쓰는 일이 아니라, 아이디어를 받아 분류·명세·구현·검증·모니터링까지 자동화하는 소프트웨어 공장을 설계하고 운영하는 일로 바뀌고 있다.

시간별 요약

0:00
인트로 및 소개 Zach Lloyd는 자가 개선형 소프트웨어 공장과 오픈소스의 새로운 모델이 개발 방식을 어떻게 바꾸는지 이야기한다. Google Docs 엔지니어 경험과 Warp 창업 경험을 바탕으로, 최근 6개월간 직접 코드를 거의 쓰지 않았지만 제품 출시는 계속하고 있다고 소개한다.
0:42
Warp 소개 Warp는 에이전트가 내장된 오픈소스 터미널이자 에이전틱 개발 환경이다. 최근 오픈소스로 전환했으며, 이제는 터미널 자체보다 개발 자동화에 더 집중하고 있다.
1:42
소프트웨어 엔지니어링의 변화 개발은 채팅과 AI 자동완성, Cursor·Copilot 단계를 지나 대화형 에이전트 중심 단계로 이동했다. 다음 단계는 사람이 에이전트에게 작업을 지시하고, 많은 과정을 자동화하는 방향이다.
1:57
자동완성에서 대화형 에이전트, 그리고 자동화로 앞으로 6개월에서 1년 사이에 개발은 더 강한 자동화 중심으로 이동할 가능성이 크다. 현재 현장에서는 에이전트 사용, 다중 에이전트 운용, 클라우드에서의 에이전트 실행이 이미 흔한 흐름으로 보인다.
2:37
청중 설문 에이전트 사용, 다중 에이전트 운용, 클라우드 에이전트 실행, SDLC 전체 자동화가 이미 일부 팀에서 진행 중임을 확인한다. 대규모 프로젝트는 결국 이러한 전체 흐름을 갖게 될 것이라고 본다.
3:27
소프트웨어 공장 루프 아이디어 유입부터 triage, 명세 작성, 구현, 검증, 배포, 모니터링까지 이어지는 반복 루프가 소프트웨어 개발의 기본 구조가 된다. 소프트웨어 엔지니어는 코드를 쓰는 사람보다 이 공장을 만들고 운영하는 사람에 가까워진다.
4:37
Warp가 오픈소스로 전환한 이유 Warp가 오픈소스로 전환한 핵심 이유는 공개된 소프트웨어 공장을 만들기 위해서다. build.warp.dev는 이슈와 작업 상태, 참여자와 에이전트의 흐름을 공개적으로 보여주는 실험장 역할을 한다.
5:12
build.warp.dev: 퍼블릭 공장 build.warp.dev는 실제로 돌아가는 공장에 가까운 공개 작업판이다. 완벽하진 않지만, 에이전트와 기여자가 함께 흘러가는 개발 흐름을 규모 있게 보여준다.
5:22
소프트웨어 개발과 복제가 쉬워진 시대 소프트웨어를 만드는 비용이 급격히 낮아지면서 복제도 쉬워졌다. 그래서 소프트웨어 비즈니스는 단순히 만들기 쉬운 것만으로는 방어력이 약해진다.
6:02
훌륭한 제품만으로는 부족한 이유 좋은 제품은 여전히 필요하지만, 그것만으로는 충분하지 않다. 유통, 생태계, 브랜드, 데이터, 자본 같은 추가 우위가 없으면 스타트업이 버티기 어렵다.
6:52
공개적으로 만들기 공개적으로 개발하면 생태계, 브랜드, 커뮤니티를 동시에 키울 수 있다. 다만 오픈소스의 어려움은 자동화로 관리해야 하며, Warp도 여러 해의 폐쇄 개발 뒤에야 이 방식으로 전환할 수 있었다.
7:22
오픈소스의 고통을 자동화로 해결하기 노이즈가 많은 이슈, 지저분한 PR, 코드 리뷰 피로, 검증 부담은 오픈소스의 전형적인 문제다. Warp는 이런 운영 부담을 자동화하는 소프트웨어 공장을 먼저 만든 뒤 오픈소스로 나아갔다.
8:12
소프트웨어 공장에 필요한 핵심 요소 효과적인 소프트웨어 공장에는 자동화, 컨텍스트와 스킬 제공, 적절한 시점의 인간 개입, 그리고 자기개선 루프가 필요하다. 오픈소스뿐 아니라 모든 규모 있는 프로젝트가 이 구조에서 이익을 얻을 수 있다.
8:52
모든 프로젝트가 공장을 갖게 될 미래 앞으로는 회사와 오픈소스 프로젝트 모두가 CI/CD처럼 당연한 수준의 소프트웨어 공장을 갖게 된다. 공장은 제품별로 다르지만, 작업이 들어와 여러 단계를 거쳐 흘러간다는 점은 공통적이다.
9:12
공장 내부 워크플로 둘러보기 작업 입력은 팀, 사용자, Slack, Teams, IDE, 모니터링 시스템 등 다양한 채널에서 들어온다. triage는 매우 중요한 단계이며, 쉽고 명확한 작업은 바로 구현하고 어려운 작업만 다음 단계로 넘겨야 한다.
10:12
이슈 분류 triage 에이전트는 들어온 이슈를 보고 바로 처리할지, 더 정교한 명세가 필요한지 판단한다. spec-driven development는 효과적이며, Warp는 product spec과 tech spec을 나누어 사용한다.
10:37
제품 명세서와 기술 명세서 product spec은 제품이 지켜야 할 불변 조건을 설명하고, tech spec은 아키텍처와 코드의 형태를 정의한다. 이후 클라우드에서 동작하는 implementation agent가 실제 diff를 만든다.
11:07
구현 및 코드 리뷰 코드 리뷰는 가장 피곤한 단계 중 하나이며, 우선 에이전트가 1차 리뷰를 맡는 편이 효율적이다. 그다음에는 위험도에 따라 인간이 개입해 리뷰하는 구조가 적합하다.
11:42
동작 검증 UI가 있는 제품에서는 computer use로 실제 동작을 실행해보고 비디오와 스크린샷으로 검증할 수 있다. CI/CD는 여전히 중요하며, 검증 결과는 다시 공장 상단의 입력으로 피드백된다.
12:02
모니터링 배포가 끝나도 에이전트는 멈추지 말고, 실제로 크래시가 나는지와 사용되는지를 관찰해야 한다. 운영 중 수집된 정보는 다음 반복의 입력이 된다.
12:17
직접 구축할 것인가, 사서 쓸 것인가? 간단한 버전은 직접 만들 수 있지만, 규모 있게 돌아가는 시스템을 만드는 데는 많은 인프라가 필요하다. 대부분의 조직은 핵심 제품에 집중하고 공장 인프라는 자체 구축과 구매 사이에서 판단해야 한다.
12:52
공장의 아키텍처 및 데이터 플레인 공장은 입력을 받는 계층, 작업을 분산하는 control plane, 실제 작업이 수행되는 cloud sandbox와 harness, 그리고 학습과 기억을 담당하는 data plane으로 나뉜다. 특히 data plane은 에이전트가 과거를 기억하고 개선하는 기반이 된다.
13:37
측정과 지속적 개선 공장은 제품이 아니라 개선 가능한 시스템으로 봐야 하며, 생산성도 정량적으로 측정해야 한다. 얼마나 많은 소프트웨어를 어떤 human time과 token time으로 만들었는지 추적하고 개선해야 한다.
14:07
스킬 개선 루프 스킬 루프는 에이전트가 실행한 스킬을 관찰하는 다른 에이전트가 문제를 찾아 개선하는 구조다. 예를 들어 code review agent의 코멘트가 부정확하면, 관찰 에이전트가 이를 다음 버전에 반영하게 만들 수 있다.
14:57
엔지니어의 역할은 어떻게 변하는가? 엔지니어는 더 이상 제품만 만드는 사람이 아니라 제품을 만드는 시스템 자체를 만드는 사람으로 바뀐다. 코드는 덜 쓰지만 더 많이 출하하게 되며, 이는 공장 공학에 가까운 메타 엔지니어링이다.
16:22
스타터 오픈소스 저장소 소개 누구나 자기만의 공장 에이전트를 실험해볼 수 있도록 스타터 오픈소스 GitHub repo가 제공된다. triage나 spec writing 에이전트를 실제로 어떻게 만들지 감을 잡는 데 도움이 된다.
17:07
Q&A: 직접 구축 vs 사서 쓰기 대부분의 조직은 공장을 완전히 직접 만들기보다, 핵심 제품에 집중하면서 공장을 조정하고 튜닝하는 쪽이 맞다. 다만 도메인에 맞는 스킬과 동작 방식으로 맞추는 엔지니어링 문제는 여전히 중요하다.
18:02
Q&A: 취업을 준비하는 졸업생을 위한 조언 졸업생에게 중요한 역량은 적응력, 비판적 사고, 빠른 학습 능력이다. 시스템과 아키텍처를 이해하고, 에이전트가 작성한 spec과 코드를 해석할 수 있는 기본기가 큰 가치가 된다.
19:17
Q&A: 인간의 안목과 제품 감각의 중요성 공장 비유가 기계적으로 들릴 수 있지만, 결국 중요한 것은 유용한 제품을 만드는 일이다. 인간의 taste, 제품 감각, 고객 이해는 자동화할 수 없는 핵심 요소로 남는다.

실무 인사이트

에이전트 도입의 핵심은 개별 작업 자동화보다 triage, spec, review, verification, monitoring을 하나의 반복 루프로 묶는 운영 설계다.
오픈소스와 AI 개발에서는 코드 자체보다 배포·운영·검증·브랜딩 같은 주변 우위가 더 중요해지므로, 공개 개발 전략을 제품 전략과 함께 설계해야 한다.
개발자 역량은 코딩량보다 시스템 이해, 명세 해석, 품질 판단, 제품 감각으로 이동하므로 팀 채용과 교육 기준도 이에 맞춰 바뀌어야 한다.