소프트웨어 공장 시대의 엔지니어링 전환

URL: https://www.youtube.com/watch?v=XyVUHSzKM2E
날짜: 2026-09-30
채널: Tech Bridge
원문 제목: [한영자막] 소프트웨어 엔지니어링은 이제 소프트웨어 공장을 짓는 일이 될 것입니다 — Zach Lloyd (Warp)
발표자: Zach Lloyd, Warp 창업자

---

📌 핵심 질문 / 핵심 논점

==소프트웨어 엔지니어링은 코드를 직접 쓰는 일에서, 에이전트가 아이디어를 검증된 제품으로 바꾸는 소프트웨어 공장을 설계·운영·개선하는 일로 이동한다.==

• 입력된 아이디어와 이슈를 에이전트가 분류하고, 복잡한 작업은 제품 명세와 기술 명세로 구체화한다.
• 구현·코드 리뷰·검증·모니터링은 에이전트가 맡되, 의도·위험·제품 가치가 걸린 지점에는 사람이 개입한다.
• 공장 성능은 생성한 코드의 양이 아니라 출하한 소프트웨어, 사람의 시간, 토큰 비용을 함께 측정해 판단한다.
• 사람의 수정 사항을 다음 실행의 스킬에 반영하는 자기개선 루프가 공장을 단순 자동화 묶음과 구분한다.

Zach Lloyd는 Google Docs 제품군의 엔지니어링을 이끌었던 20년 경력의 엔지니어이며, 최근 6개월 동안 코드를 한 줄도 직접 쓰지 않았지만 계속 제품을 출하하고 있다고 말한다. Warp는 터미널에서 출발해 에이전트가 내장된 오픈 소스 개발 환경으로 확장됐고, 개발 자동화가 대화형 에이전트 다음 단계가 될 것이라는 판단 아래 공개 소프트웨어 공장을 구축했다. 중요한 제품을 만드는 능력은 여전히 사람의 제품 감각에 달려 있지만, 제품을 만드는 반복 과정은 점점 공장처럼 운영된다.

1. 코드를 쓰지 않고도 더 많이 출하하는 개발의 변화

소프트웨어 개발의 중심이 자동완성에서 대화형 에이전트, 다시 전체 수명주기 자동화로 이동한다.

1.1. Zach Lloyd와 Warp의 출발점

1. 발표자의 경력과 현재 역할

   1. Google의 전 수석 엔지니어(Principal Engineer)로 Google Docs 제품군의 엔지니어링을 이끌었다.
   2. 엔지니어로 일한 기간은 20년이 넘었고, 현재는 Warp를 창업해 개발 환경과 개발 자동화를 만들고 있다.
   3. 최근 6개월 동안 코드 한 줄을 직접 작성하지 않았지만 제품은 계속 출하했다.

2. Warp의 정체성 변화

   1. Warp는 원래 터미널로 시작했으며, 이후 에이전트를 내장한 에이전트형 개발 환경으로 발전했다.
   2. 몇 달 전 오픈 소스로 전환했고, 터미널의 대화형 사용을 넘어 개발 자체를 자동화하는 방향에 집중하고 있다.
   3. Warp는 6만 개가 넘는 GitHub 스타, 수백 명의 기여자, 80만 명이 넘는 활성 개발자를 확보했다.

1.2. 자동완성에서 클라우드 공장으로

1. 세 단계의 개발 방식

   1. 초기 단계는 Cursor와 Copilot 같은 채팅·AI 자동완성 도구였다.
   2. 현재의 주류는 개발자가 컴퓨터 앞에서 Claude Code나 Warp 같은 에이전트에게 작업을 지시하는 대화형 에이전트 단계다.
   3. 다음 단계는 사람이 매번 다음 작업을 넘기지 않아도 여러 개발 단계가 이어지는 자동화다.

2. 현장의 손들기 질문

   1. 참석자 거의 전원이 에이전트로 개발하고 있었다.
   2. 여러 에이전트를 동시에 사용하는 참석자도 거의 전원에 가까웠다.
   3. 발표 중 에이전트를 실행 중인 사람에게 손을 들어 달라고 하자, Lloyd는 자신도 그랬을 것이라며 농담했다.
   4. 클라우드에서 에이전트를 실행하는 사람은 절반보다 적지만 상당수였다.
   5. 분류·명세 작성·구현·리뷰까지 전체 소프트웨어 개발 수명주기를 내부 시스템으로 자동화한 조직은 일부에 그쳤다.

3. 6개월에서 1년 사이의 전환 전망

   1. 자동화로 이동하는 속도는 정확히 예측하기 어렵지만, 향후 6개월에서 1년 동안 변화가 크게 진행될 것으로 예상한다.
   2. 규모 있는 모든 프로젝트가 전체 개발 수명주기를 연결한 시스템을 갖추게 될 것이라고 전망한다.

2. 소프트웨어 공장의 기본 루프

소프트웨어 공장은 기존 소프트웨어 개발 수명주기를 클라우드 에이전트와 사람의 판단 지점으로 재구성한 큰 루프다.

2.1. 아이디어부터 출하까지 이어지는 흐름

1. 입력과 분류

   1. 팀의 아이디어, 사용자의 이슈, 운영 모니터링의 관찰 결과가 공장 상단으로 들어온다.
   2. 분류 에이전트가 쉬우면서 모호하지 않은 작업은 바로 구현 단계로 보낸다.
   3. 복잡한 작업은 명세 작성 단계로 보내어 구현 전에 의도를 정리한다.

2. 명세와 사람의 개입

   1. 명세 에이전트가 복잡한 작업의 제품 명세와 기술 명세를 작성한다.
   2. 사람은 구현 전에 명세를 검토해 만들어야 할 결과와 보존해야 할 동작을 바로잡는다.
   3. 슬라이드의 파란 상자는 사람이 공장 루프에 개입하는 지점을 나타낸다.

3. 구현·리뷰·검증

   1. 클라우드에서 실행되는 구현 에이전트가 코드 변경분(diff)을 만든다.
   2. 코드 리뷰 에이전트가 먼저 변경분을 검토하고, 위험도에 따라 사람이 추가 리뷰를 수행한다.
   3. 검증 에이전트가 결과물이 실제로 작동하는지 확인한다.
   4. 사람은 제품 수준의 결과를 확인한 뒤 출하를 승인한다.

4. 출하 이후의 되먹임

   1. 배포가 끝나도 에이전트의 역할은 끝나지 않는다.
   2. 모니터링 에이전트가 충돌 여부와 실제 사용 여부를 관찰한다.
   3. 모니터링 결과는 새로운 작업 입력으로 되돌아가 다음 루프를 시작한다.

2.2. 공장이라는 비유의 의미

1. 루프는 복잡한 신조어가 아니다

   1. Lloyd는 루프라는 말이 복잡하게 들리지만 실제로는 단계의 연결이라고 말한다.
   2. 클라우드 소프트웨어 공장이라는 이름을 빼면 같은 구조는 전통적인 소프트웨어 개발 수명주기와 같다.
   3. 중요한 차이는 각 단계가 에이전트와 사람의 명확한 책임으로 분리되고, 단계 사이의 흐름이 지속적으로 운영된다는 점이다.

2. 엔지니어의 책임 이동

   1. 소프트웨어 엔지니어는 구현 작업만 수행하는 사람이 아니라 이 루프를 만들고 관리하는 사람이 된다.
   2. 제품을 만드는 동시에 제품을 만드는 시스템을 설계해야 하므로 업무는 프로세스 엔지니어링·제조 엔지니어링에 가까워진다.

3. 에이전트 시대의 오픈 소스와 사업 전략

Warp는 오픈 소스 전환을 공개 소프트웨어 공장을 구축하는 실험으로 활용했고, 자동화로 오픈 소스 유지 비용을 감당할 수 있게 했다.

3.1. Warp가 공개 공장을 만든 이유

1. build.warp.dev의 공개 작업 흐름

   1. Warp는 build.warp.dev라는 웹사이트에서 시스템을 통과하는 이슈와 현재 상태를 보여준다.
   2. 각 이슈를 어떤 에이전트와 기여자가 처리하는지 확인할 수 있다.
   3. 완벽하게 작동하지는 않지만 규모 있게 동작하는 프로토타입 공장으로 자리 잡았다.

2. 오픈 소스의 새로운 역할

   1. Warp는 5년 동안 비공개로 개발한 뒤 공개 개발로 전환했다.
   2. 공개 개발은 생태계와 커뮤니티를 키우고 브랜드를 강화한다.
   3. Lloyd는 Hacker News에서 “미움받는” 상태를 “용인되는” 상태로 바꾸는 정도만 되어도 평판 측면의 이득이라고 농담했다.
   4. 에이전트가 기여자의 기여와 관리자의 유지보수를 돕도록 만들어 공개 공장의 부담을 줄인다.

3.2. 소프트웨어 복제 비용 하락과 사업의 방어력

1. 값싼 개발의 양면성

   1. 에이전트로 소프트웨어를 만드는 비용이 낮아지면 경쟁 제품의 복제도 쉬워진다.
   2. 경쟁자가 제품을 복제할 수 있는 환경에서는 좋은 제품만으로 가치를 독점하기 어렵다.
   3. Lloyd는 “첫 번째 조언은 코드를 특허 내는 것”이라고 말한 뒤, 곧바로 농담이라며 “그러지 말라”고 정정했다.

2. 제품 밖의 경쟁 우위

   1. 훌륭한 제품은 여전히 필수지만, 훌륭한 제품을 만들고 출하하는 것만으로는 충분하지 않다.
   2. 유통망, 생태계, 브랜드, 데이터 해자(data moat), 자본이 추가적인 방어력이 될 수 있다.
   3. 스타트업은 이런 자산을 처음부터 갖기 어렵기 때문에 공개 개발로 생태계·커뮤니티·브랜드를 함께 키울 수 있다.

3. 오픈 소스의 전통적 비용

   1. 시끄럽고 중복된 이슈가 쏟아질 수 있다.
   2. 완성도가 낮은 풀 리퀘스트가 들어올 수 있다.
   3. 코드 리뷰 지옥에 빠지고 변경 검증에 많은 시간을 써야 한다.
   4. Warp는 이런 유지보수 비용을 자동화로 감당할 수 있게 된 시점에 오픈 소스 전환을 결정했다.

4. 공장 바닥의 작업 그래프와 개발 단계

공장 바닥은 제품에 맞는 개발 방법을 정의한 단계 그래프이며, 입력 채널과 작업의 분기 조건을 명시한다.

4.1. 입력 채널과 분류의 분기

1. 작업 입력의 출처

   1. 팀과 사용자가 제시한 아이디어가 입력이 된다.
   2. 작업 추적기(task tracker), Slack, Teams 같은 커뮤니케이션 채널이 입력 통로가 된다.
   3. 터미널이나 IDE에서 직접 작업을 보낼 수 있다.
   4. 모니터링 시스템이 충돌·사용량·운영 이상을 감지해 새로운 입력을 만든다.

2. 쉬운 작업과 어려운 작업의 처리 차이

   1. 쉽고 명확한 이슈는 분류 에이전트가 바로 구현으로 보낸다.
   2. 어려운 이슈는 제품 명세와 기술 명세를 먼저 만들게 한다.
   3. 모든 작업에 같은 양의 계획을 강제하지 않아야 작은 작업도 빠르게 흐른다.

4.2. 제품 명세와 기술 명세

1. 제품 명세(Product spec)

   1. 제품이 만들어야 하거나 계속 보존해야 하는 동작과 속성을 정의한다.
   2. 구현자가 어떤 사용자 결과를 달성해야 하는지 명확히 한다.

2. 기술 명세(Tech spec)

   1. 구현에 사용할 아키텍처와 코드의 형태를 정의한다.
   2. 어떤 구조로 변경분을 만들어야 하는지 구현 에이전트에 전달한다.

3. 명세 검토의 의미

   1. 사람이 명세를 검토하면 코드가 생성되기 전에 잘못된 의도와 범위를 바로잡을 수 있다.
   2. 구현 이후에 큰 변경을 되돌리는 것보다 구현 전에 제품 의도와 기술 방향을 교정하는 편이 비용이 낮다.

4.3. 구현·리뷰·검증을 연결하는 방법

1. 구현과 코드 리뷰

   1. 구현 에이전트는 클라우드 어딘가에서 실행되는 코딩 에이전트이며 결과로 diff를 만든다.
   2. 특정 에이전트 하나에 종속될 필요 없이 여러 코딩 에이전트를 사용할 수 있다.
   3. 코드 리뷰는 에이전트가 먼저 수행하고, 사람이 개입할 시점을 위험 관리 문제로 정한다.
   4. 약한 에이전트 출력인 “에이전트 슬롭(agentic slop)”을 사람이 전부 검토하면 사람의 리뷰가 병목이 되므로 위험도에 따른 선택이 필요하다.

2. 제품 검증

   1. UI를 만드는 경우 컴퓨터 사용(computer use) 에이전트가 실제 화면을 조작해 코드가 작동하는지 확인할 수 있다.
   2. 검증 과정은 동영상과 스크린샷을 만들어 결과를 남길 수 있다.
   3. 기존 CI/CD는 계속 사용해야 하며, 에이전트 검증이 CI/CD를 대체하지 않는다.
   4. 초기 루프에서는 사람이 제품을 확인한 뒤 출하한다.

5. 확장 가능한 공장을 만드는 인프라와 측정

간단한 자동화는 쉽게 만들 수 있지만, 규모 있는 공장은 작업 유입·분배·실행·기억을 담당하는 인프라 층이 필요하다.

5.1. 직접 구축할 것인가, 구매할 것인가

1. Uber 사례와 선택의 문제

   1. Uber는 내부적으로 이런 구조를 구축한 사례로 언급된다.
   2. 조직에 따라 간단한 버전은 쉽게 만들 수 있지만 실제 규모 확장은 훨씬 많은 요소를 요구한다.
   3. 대부분의 조직은 공장 인프라 자체를 만드는 일이 핵심 제품에서 주의를 빼앗는지 먼저 판단해야 한다.

2. 구축과 구매 이후에도 남는 일

   1. 공장 인프라를 직접 만들든 구매하든 제품에 맞게 조정해야 한다.
   2. 어떤 스킬이 도메인에 맞는지, 공장이 올바른 방식으로 제품을 만드는지 계속 점검해야 한다.
   3. 인프라를 구매하는 것이 제품에 맞춘 설계·튜닝 책임까지 없애지는 않는다.

5.2. 공장 하부의 네 가지 인프라 층

1. 작업 유입층(Work intake)

   1. 이슈·아이디어·모니터링 이벤트가 공장으로 들어오는 여러 경로를 제공한다.

2. 제어 평면(Control plane)

   1. 공장 바닥에서 작업을 어디로 보낼지 결정한다.
   2. 분류 결과에 따라 명세·구현·리뷰·검증 단계로 분배한다.

3. 실행층(Execution)

   1. 클라우드 샌드박스에서 실제 작업을 실행한다.
   2. 어떤 에이전트 하네스(harness)와 어떤 모델을 사용할지 결정한다.

4. 데이터 평면(Data plane)

   1. 에이전트가 과거 작업을 기억하도록 한다.
   2. 작업 결과와 실패 사례를 축적해 시간이 지나며 학습하고 개선할 수 있게 한다.

5.3. 출하량이 아니라 가치 흐름을 측정하기

1. 측정할 세 가지

   1. 실제로 출하한 소프트웨어의 양과 품질을 측정한다.
   2. 사람이 투입한 시간(human time)을 측정한다.
   3. 모델이 소비한 토큰 시간(token time)과 비용을 측정한다.

2. 개선의 기준

   1. 생성된 코드의 양만으로 공장 성능을 판단하면 안 된다.
   2. 핵심 비교는 얼마만큼의 소프트웨어를 실제로 출하했는지와 그 결과에 사람 시간·토큰 시간이 얼마나 들었는지다.
   3. 반복 실행마다 이 수치를 비교해 공장 효율을 개선한다.

6. 사람의 수정으로 공장을 자기개선시키는 스킬 루프

자기개선 루프는 한 번의 사람 개입을 현재 작업의 수정으로 끝내지 않고 다음 실행의 에이전트 스킬 개선으로 연결한다.

6.1. 관찰자 에이전트의 역할

1. 스킬 실행과 관찰의 분리

   1. 공장 에이전트는 부여된 스킬을 사용해 작업한다.
   2. 관찰자 에이전트(observer agent)는 스킬이 실제로 적용되는 방식을 살펴본다.
   3. 관찰자는 실패와 문제 패턴을 찾아 스킬을 개선한다.

2. 코드 리뷰 사례

   1. 코드 리뷰 에이전트가 리뷰 코멘트를 남긴다.
   2. 선임 엔지니어가 잘못된 코멘트를 수정하거나 더 나은 코멘트로 교정한다.
   3. 관찰자 에이전트가 선임 엔지니어의 교정을 분석한다.
   4. 수정된 지침을 리뷰 스킬에 반영하면 다음 실행부터 같은 실수를 반복하지 않을 가능성이 커진다.

6.2. 제안 단계로서의 자기개선

1. 개별 PR을 넘어서는 피드백

   1. 스킬 루프가 없으면 선임 엔지니어의 교정은 현재 풀 리퀘스트에만 영향을 준다.
   2. 스킬 루프가 있으면 현재 교정이 다음 리뷰의 입력이 된다.
   3. 사람의 판단이 공장 지식으로 축적되면서 반복되는 실패를 줄이는 구조가 생긴다.

2. 아직 해결해야 할 검증 문제

   1. 제안된 구조가 실제로 얼마나 개선되는지는 별도의 측정이 필요하다.
   2. 스킬 수정의 품질을 어떻게 평가할지, 잘못된 학습을 어떻게 되돌릴지는 추가 설계 과제다.
   3. 따라서 자기개선이라는 말만으로 자동 개선이 보장되는 것은 아니며, 관찰·측정·롤백 체계가 필요하다.

7. 엔지니어의 역할과 제품 감각

코드를 덜 쓰고 더 많이 출하하는 변화는 엔지니어의 즐거움과 역량의 기준을 바꾸지만, 사람의 제품 판단을 제거하지 않는다.

7.1. 코드를 덜 쓰고 제품을 더 많이 출하하는 트레이드오프

1. 즐거움의 기준에 따른 차이

   1. 코드 작성 자체에서 가장 큰 즐거움을 얻는 사람에게는 변화가 아쉬울 수 있다.
   2. 제품을 만들고 출하하는 데서 즐거움을 얻는 사람에게는 더 좋은 시기가 된다.
   3. 모든 엔지니어가 코드를 덜 쓰게 되지만 더 많은 제품을 출하하게 된다는 교환 관계가 생긴다.

2. 메타 엔지니어링

   1. 에이전트 시스템이 엔지니어링을 가장 잘 수행하도록 에이전트·스킬·검토 지점을 설계하는 일이 새로운 엔지니어링 과제가 된다.
   2. 제품 코드가 아니라 제품을 만드는 공장을 개선하는 일은 프로세스·제조 엔지니어링과 닮았다.
   3. Lloyd는 이 문제를 매우 흥미로운 공학적 도전으로 본다.

7.2. 실무로 옮기는 출발점

1. 공개 에이전트 저장소

   1. Lloyd는 누구나 공장 에이전트를 직접 만들어 볼 수 있는 오픈 소스 GitHub 저장소를 QR 코드로 소개했다.
   2. 저장소에는 분류 에이전트와 명세 작성 에이전트의 예가 포함되어 있다.
   3. Warp 에이전트 플랫폼을 사용하지만, 반드시 Warp를 사용할 필요는 없다고 강조했다.
   4. 공장 루프 이론을 실제 개별 작업자 에이전트 구축으로 옮기는 출발점이 된다.

2. 제품에 맞춘 튜닝

   1. 모든 조직은 어느 형태로든 공장을 배포하게 되지만, 공장의 스킬이 도메인에 맞는지 조정하는 작업은 남는다.
   2. 공장이 자사 제품을 올바른 방식으로 만드는지 확인하는 일이 핵심이다.
   3. 대부분의 조직은 공장 인프라를 처음부터 만드는 대신 핵심 제품에 집중하고, 제품에 맞춘 튜닝에 엔지니어링 역량을 써야 한다.

7.3. 대학 졸업생에게 필요한 역량

1. 변화에 대응하는 능력

   1. 가장 중요한 역량은 적응력이다.
   2. 비판적 사고와 빠르게 학습하는 속도가 중요하다.
   3. 도구와 모델이 계속 변해도 문제를 다시 정의하고 해결하는 능력이 필요하다.

2. 시스템 이해와 제품 중심 사고

   1. 컴퓨터과학 학생이라면 기본 시스템과 아키텍처를 이해하는 능력을 계속 쌓아야 한다.
   2. 생성된 코드를 읽고 추론하며, 에이전트가 작성한 명세의 품질을 판단할 수 있어야 한다.
   3. Warp는 AI 때문에 채용을 줄인 것이 아니라 지금까지 어느 때보다 많은 사람을 채용하고 있다고 말한다.
   4. Warp가 찾는 사람은 적응력이 높고 제품에 집중하며, 기반 기술이 바뀌어도 문제를 해결하는 사고자다.

7.4. 제품 발견·아이디어·디자인·비전·취향

1. 공장 비유의 한계

   1. 공장이라는 말은 개발을 기계화하고 비인간화하는 느낌을 줄 수 있다.
   2. 아무도 관심을 갖지 않는 결과물을 대량 생산하는 공장은 효율적이어도 의미가 없다.
   3. 중요한 질문은 공장이 얼마나 많은 코드를 만들었는지가 아니라 실제로 유용한 것을 만들었는지다.

2. 자동화할 수 없는 인간의 역할

   1. 사람의 취향, 입력, 제품 감각은 자동화할 수 없는 지점에서 필수다.
   2. 사람이 고객이 원하는 것과 사람에게 가치 있는 것을 판단해야 한다.
   3. 공장은 변경을 만드는 방법을 조직하지만, 무엇을 만들 가치가 있는지 정하는 역할은 사람에게 남는다.

주요 발언 모음

“소프트웨어 엔지니어링이라는 분야는 공장 엔지니어링에 가까운 무언가가 될 것이다.”

“나는 여전히 자주 출하하고 있지만, 지난 6개월 동안 코드 한 줄을 쓰지 않았다.”

“모든 규모 있는 프로젝트는 핵심에 소프트웨어 공장을 갖게 될 것이다. CI/CD가 ‘당연히 갖추는 것’이 된 것과 같은 흐름이다.”

“쉽고 모호하지 않은 작업이라면 그냥 구현하라. 어려운 작업이라면 명세를 먼저 작성하라.”

“제품 명세는 만들려는 제품의 불변 조건을 설명하고, 기술 명세는 아키텍처와 코드의 형태를 설명한다.”

“모두가 코드를 덜 쓰게 되지만, 더 많이 출하하게 될 것이다.”

“제품을 만드는 것만이 아니라 제품을 만드는 것을 만들어야 한다.”

“아무도 관심을 갖지 않는 것을 찍어내는 공장이 있다면, 그게 무슨 의미가 있겠는가?”

핵심 데이터 & 수치

• 20년 이상: Zach Lloyd가 엔지니어로 일해 온 기간이다.
• 6개월: Lloyd가 코드 한 줄을 직접 쓰지 않고도 계속 제품을 출하했다고 말한 기간이다.
• 5년: Warp가 비공개로 개발한 뒤 오픈 소스로 전환하기까지의 기간이다.
• 6만 개 이상: Warp의 GitHub 스타 수다.
• 수백 명: Warp 오픈 소스 프로젝트에 참여한 기여자 수다.
• 80만 명 이상: Warp를 사용하는 활성 개발자 수다.
• 절반 미만: 현장 손들기에서 클라우드 에이전트를 실행하는 참석자의 대략적인 비율이다.
• 6개월~1년: 대화형 에이전트에서 전체 개발 자동화로 이동이 크게 진행될 것으로 Lloyd가 예상한 기간이다.
• 4개 인프라 층: 작업 유입, 제어 평면, 실행, 데이터 평면으로 공장 하부를 나눈다.
• 3가지 측정 축: 출하한 소프트웨어, 사람의 시간, 토큰 시간으로 공장 효율을 평가한다.
• 7개 주요 단계: 입력·분류, 명세·사람 검토, 구현, 코드 리뷰, 검증·제품 검토, 출하·모니터링이 하나의 루프를 이룬다. 쉬운 작업은 명세를 건너뛸 수 있다.

결론 및 시사점

1. 소프트웨어 개발팀은 코딩 에이전트를 한 명씩 사용하는 수준에서 벗어나 입력부터 모니터링까지 연결된 공장 루프를 설계해야 한다.
2. 모든 작업을 자동화하지 말고, 쉽고 명확한 작업부터 구현으로 보내며 복잡한 작업에만 제품 명세와 기술 명세를 요구해야 한다.
3. 사람은 제품 의도, 코드 위험도, 실제 제품의 유용성을 판단하는 지점에 집중해야 한다.
4. 코드 리뷰 에이전트의 실수를 사람이 고치는 데서 끝내지 말고, 관찰자 에이전트와 스킬 루프로 다음 실행에 반영해야 한다.
5. 공장 도입의 성과는 생성 코드량이 아니라 출하 결과와 사람 시간·토큰 비용의 관계로 측정해야 한다.
6. 확장 가능한 인프라를 직접 만들면 핵심 제품에서 주의가 분산될 수 있으므로, 구매와 구축을 비교한 뒤 제품에 맞춘 튜닝에 집중해야 한다.
7. 오픈 소스는 복제하기 쉬운 시대에 생태계·커뮤니티·브랜드를 만드는 방어 수단이 되며, 공장 자동화는 유지보수 비용을 낮춘다.
8. 앞으로의 엔지니어에게 필요한 역량은 특정 모델 사용법보다 적응력, 비판적 사고, 빠른 학습, 시스템 이해, 제품 중심 문제 해결이다.
9. 공장이 코드를 잘 생산해도 유용하지 않은 결과물을 만들면 실패하므로, 사람의 취향·비전·제품 감각은 공장 바깥이 아니라 핵심 제어 지점으로 남는다.