01
큐레이터의 판단
내 AI 시스템에 바이브 코딩으로 기능을 더할 때, 요청을 바로 코드로 바꾸기 전에 무엇을 분류하고 구현 뒤 무엇을 확인할지 정하는 데 유용하다. Warp의 Zach Lloyd는 ‘Software Engineering Is Becoming Factory Engineering’에서 엔지니어의 역할이 소프트웨어를 만드는 공정의 설계·운영으로 이동한다고 예측한다. 이는 발표자의 전망이며 업계 전체에 확립된 사실은 아니다. 이 큐레이션은 접수·명세·구현·검증·관찰의 흐름을 개인 시스템의 작은 변경에 적용해 읽는다. 대규모 공장 인프라를 먼저 갖출 필요는 없으며, 발표자도 Q&A에서 인프라 구축에 과투자하기보다 제품에 집중하라고 권한다.
02
누구에게 유용한가
에이전트·API·MCP로 자신의 AI 시스템을 이미 구축하거나 운영하며, 바이브 코딩으로 CLI·UI·작업 흐름을 직접 확장하려는 사람. 브랜치, 변경 내역, 자동 검사, 데이터 접근 권한의 기본을 알고 작은 변경의 완료 조건과 복구 방법을 정할 준비가 있으면 좋다.
03
핵심 내용
09:32 · 요청을 분류하고 완료 조건을 적기 ↗
- Lloyd는 팀·사용자·작업 추적기·모니터링 등에서 들어오는 요청을 먼저 분류하자고 제안한다. 쉽고 모호하지 않은 일은 구현으로 보내고, 어려운 일은 명세를 작성하는 단계로 보낸다.
- Warp에서는 제품이 지켜야 할 조건을 담은 product spec과 구조·코드의 형태를 담은 tech spec을 구분한다고 설명한다. 그다음 구현 에이전트가 변경 내역을 만든다.
11:05 · 실제 사용과 위험에 따른 리뷰 ↗
- Lloyd는 에이전트가 먼저 코드를 리뷰하되 위험에 따라 사람이 검토하는 지점을 남겨야 한다고 말한다. UI는 실제 화면을 사용하고 스크린샷·영상으로 확인하는 검증을 CI/CD와 함께 제안한다.
- 코드를 배포한 뒤에도 충돌하는지, 실제로 쓰이는지 관찰하고 그 결과를 다음 요청으로 되돌려야 한다고 본다. 구현이 끝나는 시점과 운영에서 유용함을 확인하는 시점을 구분하는 설명이다.
12:37 · 실행 기록을 다음 스킬의 개선으로 ↗
- Lloyd는 공장을 확장할 때 작업을 배분하는 control plane, 샌드박스·모델·하네스가 실행되는 환경, 에이전트의 작업을 기억하고 개선을 돕는 data plane이 필요하다고 본다.
- 출하한 소프트웨어와 인간 시간·토큰 비용을 측정하자고 제안한다. 사람이 리뷰 에이전트의 코멘트를 수정한 기록을 관찰해 다음 실행의 스킬을 개선하는 skill loop를 예로 든다.
17:10 · 공장보다 내가 쓸 기능에 집중하기 ↗
- Q&A에서 Lloyd는 공장 인프라 전체를 직접 구축하는 일과 자기 제품에 맞게 스킬·공정을 조정하는 일을 구분한다. 대부분은 핵심 제품을 만드는 데 집중하는 편이 좋다고 답한다.
- 이후 별도의 질문들에 답하면서, 18:00 이후 졸업생의 준비에 관한 답변에서는 에이전트가 쓴 명세와 코드를 판단하려면 시스템·아키텍처를 이해하는 능력이 여전히 중요하다고 말한다. 19:12 이후 제품 감각에 관한 답변에서는 아무도 원하지 않는 결과물을 많이 만드는 공장은 의미가 없으며 인간의 제품 감각이 필요하다고 강조한다.
04
큐레이터의 해석•제안
- 공장 인프라보다 내 자료를 찾는 CLI 필터나 반복 업무의 확인 화면처럼 실제로 쓸 작은 기능 하나부터 완성하기를 권한다. 입력·기대 결과·건드리지 않을 데이터와 권한을 적고 별도 브랜치나 테스트 환경에서 구현을 맡긴다. control plane과 data plane을 시작의 필수 조건으로 삼지 말고, 반복 작업에서 드러난 필요에 맞춰 절차를 보완한다.
- 내 UI나 CLI에서는 기대한 결과뿐 아니라 접근 권한이 없는 자료를 거부하는지도 확인하기를 권한다. 공개 전 변경 내역과 복구 방법을 검토하고, 이미 바뀐 데이터까지 되돌릴 수 있는지 점검한다.
- 실패한 입력·실제 결과·수정한 판단·시간과 비용을 간단히 남기기를 권한다. 반복되는 실패를 재현 검사나 스킬 수정으로 연결하고 수정 결과도 검토한다.
05