소프트웨어 팩토리 도입 가이드: 크롤 워크 런

Crawl

소프트웨어 팩토리 접근법(클라우드에서 실행되는 폐쇄형 에이전트 루프)이 점점 더 인기를 얻고 있지만, 이를 도입하는 것은 부담스러울 수 있습니다. 이 글에서는 로컬 인터랙티브 에이전트에서 자동화된 클라우드 개발로 전환하기 위한 '크롤(crawl), 워크(walk), 런(run)' 단계를 살펴볼 것입니다.

Crawl (기어가기)

내가 대화한 많은 엔지니어링 리더와 플랫폼 엔지니어들은 이미 클라우드 에이전트를 사용하여 간단한 자동화를 구축함으로써 소프트웨어 팩토리 구축의 '기어가기' 단계를 시작했습니다.

이러한 자동화를 트리거 → 에이전트 활동으로 생각하세요.

예를 들어:

이슈 재현 및 분류: 새로 등록된 모든 이슈를 확인하고 재현하며 라벨을 붙이는 에이전트 사용
코드 리뷰: PR이 열리면 자동으로 리뷰하고 댓글 남기기
모니터링: Sentry 알림에 응답하여 문제를 디버깅하고 수정하는 에이전트 사용
CI 자가 복구: 롤백할 PR 식별, 병합 충돌 해결 등을 통해 깨진 CI 수정
문서 자동 업데이트: 사용자 대상 문서 업데이트 및 변경 로그 생성
검증: 브라우저 사용 및 컴퓨터 사용 에이전트를 통한 시각적 QA 및 변경 사항 검증
단순 버그 수정: 에이전트가 사용자가 보고한 단순한 문제를 식별하고 수정

이 모든 접근법의 공통점은 소프트웨어 라이프사이클의 개별 부분을 자동화한다는 점입니다. 간단한 자동화로 시작하는 것은 위험과 비용이 낮은 접근 방식이며, 더 복잡한 다단계 작업에서 에이전트를 효과적으로 사용하는 방법에 대한 직관을 기르는 데 도움이 됩니다.

알림 모니터링용 샘플 자동화

이러한 자동화는 자체 인프라(예: Claude Code SDK를 Docker 컨테이너에 넣고 트리거 서버 연결)를 사용하여 구축하거나, 트리거 시 에이전트를 실행하도록 설계된 범용 클라우드 에이전트 자동화 플랫폼을 사용할 수도 있습니다. 또한 사이클의 특정 단계에만 전용인 전체 플랫폼(예: 전용 에이전트 코드 리뷰어 또는 AI SRE)을 사용할 수도 있습니다.

개별 지점 자동화의 패치워크로 시작하는 것도 괜찮지만, 대부분의 팀은 결국 이 접근법의 한계에 부딪힙니다.

구체적으로 다음과 같습니다:

설정 방식에 따라 이러한 자동화가 컨텍스트를 공유하지 않을 수 있습니다. 즉, 한 측면(예: 코드 리뷰)을 개선해도 분류나 QA 등 다른 단계에는 반영되지 않습니다.
이러한 일회성 자동화가 전반적인 생산성을 실제로 개선하는지 확인할 글로벌 뷰가 없으며, PR당 비용, 사이클 타임, 자동화 비율 등 중요한 상위 수준 지표를 테스트하고 개선할 체계적인 방법도 없습니다. 이를 추적하려면 개발 단계를 아우르는 시스템이 필요합니다.
각 지점 솔루션은 자체적인 설정 및 유지보수 부담을 만듭니다. 관리해야 할 보안 표면이 넓어지며, 관측성을 위한 통합 인터페이스가 없습니다. 팀은 결국 중앙 집중식 구성, 감사 및 거버넌스를 원하게 됩니다.

Walk (걷기)

이러한 모든 문제는 보다 포괄적인 접근 방식의 필요성을 시사합니다. '기어가기' 단계를 거친 조직들은 "에이전트 기반 개발을 진정한 규모로 확장하기 위해 우리가 원하는 시스템은 무엇인가?"라고 자문합니다.

더 구체적으로는 다음과 같은 질문을 합니다:

개발은 어디서 이루어져야 하는가? 로컬인가 클라우드인가? 어떤 인터페이스를 통해?
성공적인 자동화된 개발 프로세스는 어떤 모습이어야 하는가? 핵심 지표는 무엇인가?
우리의 AI 주권 입장은 어떠한가? 코딩 에이전트 데이터를 소유하는 것이 얼마나 중요한가? 모델 제공업체에 얼마나 의존해야 하는가?
시간이 지남에 따라 개발 프로세스를 어떻게 개선할 계획인가? 출시 속도를 높이는 동시에 비용을 통제하려면 어떻게 해야 하는가? 개선되고 있음을 어떻게 알 수 있는가?
모델과 에이전트가 발전함에 따라 미래를 어떻게 대비할 것인가? 모델 접근성에 영향을 미칠 수 있는 규제 리스크를 고려하고 있는가?
엔지니어는 개발 프로세스에 정확히 어떻게 참여해야 하는가? 디자이너, PM 및 기타 빌더들도 마찬가지인가?
개발 보안을 어떻게 확보할 것인가? 소프트웨어 생산 프로세스가 침해될 경우 우리의 계획은 무엇인가?

이러한 질문에 깊이 고민한 대부분의 엔지니어링 리더와 플랫폼 팀은 클라우드 소프트웨어 팩토리 접근법과 유사한 결론에 도달합니다. 그들은 다음을 원합니다:

기본적으로 클라우드에서의 개발. 에이전트를 로컬에서 풀어놓는 것보다 샌드박스를 제공하는 것이 더 안전하기 때문
코딩 에이전트 및 이들이 접근하는 도구와 시스템에 대한 중앙 집중식 거버넌스
감사 및 생산성 이해를 위한 에이전트 활동의 완전한 추적 기록
리스크 최소화 및 성능 최적화를 위한 모델과 하네스의 선택지 제공
팀이 이미 사용 중인 모든 도구(Slack/Teams, Jira, Github 등)와의 개발 통합
라이브 에이전트 조종이나 작업을 내부 개발 루프로 가져오는 것을 통해 인간이 개입할 수 있는 비상 탈출구
개발의 모든 단계에서 에이전트 간에 작동하는 공유 컨텍스트 계층
팀이 시간이 지남에 따라 시스템이 개선되고 있다는 확신을 가질 수 있도록 테스트, 평가 및 벤치마크를 허용하는 접근 방식

회사가 팩토리 접근법을 결정하면, 기존 지점 자동화에서 어떻게 거기로 갈 것인지가 문제가 됩니다. 이는 일반적으로 (1) 해당 자동화 주변에 더 많은 인프라를 구축하거나 (2) 팩토리 인프라를 제공하는 Warp Factories와 같은 플랫폼으로 전환하는 것으로 귀결됩니다.

이를 전통적인 직접 구축 대 구매(build vs. buy) 의사결정으로 보지 않기를 권합니다. 어떤 경로를 택하든 내부 팀이 일부 구축 작업을 수행해야 한다고 예상해야 합니다. 팩토리 접근법이 작동하려면 그 팩토리가 팀의 컨텍스트와 워크플로우에 깊게 통합되어야 하기 때문입니다. 이는 완전히 처음부터 자동화 인프라를 구축할 것인가, 아니면 선두 주자를 제공하는 파트너와 협력할 것인가의 문제입니다.

예를 들어, 어떤 경로를 택하든 조직 특화 스킬을 구축하고 코드베이스에 맞게 튜닝해야 한다고 예상해야 합니다. 조직 특화 MCP와 내부 컨텍스트 소스를 노출하고 구성해야 한다고 예상해야 합니다. 하지만 에이전트 실행 및 관리, 조종, 작업 인수인계, 효율성 측정, 컴퓨터 사용 등을 위한 클라우드 인프라를 구축하고 싶지는 않을 수 있습니다. 경험칙은 모든 조직에 필요한 부분이 아니라, 당신의 조직에만 특화된 부분을 구축하는 데 집중하는 것입니다.

어떤 접근 방식을 취하든, 걷기 단계의 가장 큰 이정표는 간단한 제품 표면에 첫 번째 팩토리를 엔드투엔드로 배포하는 것이라고 제안합니다. 이는 마케팅 사이트나 내부 앱일 수 있습니다.

하나의 간단한 프로젝트로 시작하면 위험 부담이 적고 복잡성이 최소화된 상태에서 전체 루프를 돌릴 수 있다는 장점이 있습니다. 저장소, 코드 라인, 서비스 종속성, 인간 이해관계자 등을 추가하면 복잡성이 증가하여 자동화 준비가 되지 않았다는 느낌을 받을 수 있습니다. 먼저 간단한 루프를 완벽하게 만드는 것이 낫습니다.

목표는 분류 → 사양 작성 → 구현 → 리뷰 → 검증 → 모니터링으로 이어지는 다중 에이전트 시스템입니다. 더 자세히 설명하면:

인간 또는 모니터링 에이전트를 통해 새 이슈가 시스템으로 유입됨
분류 에이전트가 실행되어 이슈를 이해하고 재현하려고 시도함. 작업이 자동화 가능하다고 판단되면 → 구현 에이전트로 전달. 범위로 인해 사양이 필요하면 → 사양 에이전트가 인간과 반복하여 사양을 작성. 모호하면 → 인간의 입력을 받아 다시 실행하거나, 당분간 이슈를 보류하기로 결정
[필요한 경우] 사양 에이전트 실행, 인간이 사양 검토 후 구현 에이전트로 전달
구현 에이전트가 코드 작성
코드 리뷰 에이전트가 코드 리뷰
검증 에이전트가 컴퓨터 사용 또는 기타 검증 수행
인간이 코드와 검증 출력 검토. 필요한 경우 2, 3, 4 또는 5 단계로 돌아가기
CI / CD
출시
모니터링 에이전트 실행, 필요시 이슈 생성하여 루프 완료

Warp 내부에서는 우리의 걷기 팩토리가 마케팅 사이트인 warp.dev 변경 사항의 약 75%를 자동화합니다. Warp Terminal(GitHub 스타 6만 5천 개, 활성 개발자 거의 100만 명, 네이티브 Rust 코드 100만 줄)과는 달리, 우리의 마케팅 사이트는 꽤 간단한 앱입니다. 여기서 '자동화'란 우리가 원하는 변경 사항을 Slack이나 태스크 트래커에 설명하는 것을 제외하고는 최소한의 인간 터치포인트만으로 팩토리를 통해 인간 입력에서 최종 출시 기능까지 전 과정을 거치는 것을 의미합니다.

Run (달리기)

간단한 프로젝트에서 기본 루프가 갖춰진 후에만 더 복잡한 프로젝트로 확장해야 합니다. 팩토리를 확장하려면 더 견고한 인프라가 필요합니다.

구체적으로, 확장함에 따라 다음과 같은 병목 현상이 발생합니다:

대규모 프로젝트에서 원격 개발 환경을 작동시키는 것은 어렵습니다. 더 많은 저장소, 코드 라인, 서비스 종속성은 모두 자동화를 더 어렵게 만듭니다.
스킬과 코드 등이 많아지면 팩토리에 가하는 변경 사항이 개발에 긍정적인 영향을 미치는지, 아니면 단순히 혼란만 야기하는지 파악하기가 더 어려워집니다.
에이전트가 더 복잡한 코드베이스에서 작업하므로 더 강력한 모델이 필요하고 에이전트 실행 시간이 길어져 자연스럽게 높은 비용 리스크에 직면합니다. 모델 라우팅과 하네스 선택이 더 중요해집니다.
미션 크리티컬한 사용자 대상 앱에 팩토리 접근법을 적용할수록 보안과 감사가 더 중요해집니다.
앱 이해관계자가 많아지면 인간 조정 및 서명이 더 많이 필요합니다. 멀티플레이어 입력과 감사 추적을 허용하는 팩토리 솔루션이 필요할 것입니다.
피할 수 없이 PR이 쌓이기 시작하므로, 무엇이 코드 리뷰를 받는지, 에이전트 검증과 QA를 어떻게 사용하는지에 대한 정의된 전략이 필요할 것입니다.
프로덕션으로 출시되는 변경 사항이 고품질이고, 크래시하지 않는지 등을 확인하여 루프를 닫기 위한 더 견고한 도구가 필요할 것입니다.

확장된 팩토리를 작동시키는 것은 내 의견으로는 향후 몇 년간 가장 흥미로운 소프트웨어 엔지니어링 과제 중 하나가 될 것입니다. 소프트웨어 엔지니어링은 팩토리 엔지니어링으로 변모하고 있습니다. 팩토리를 견고하고, 신뢰할 수 있으며, 자가 개선(self-improving)되도록 만들 수 있는 조직은 더 나은 비용으로 더 많이 출시할 수 있으며 경쟁 우위를 가질 것입니다.

팩토리가 정말로 순조롭게 돌아가려면 상당한 투자가 필요합니다. Warp에서는 이를 팩토리 스택을 완전히 구축하는 것으로 생각합니다:

각 계층에 대한 자세한 내용은 이 게시물에서 다룹니다:

https://x.com/zachlloydtweets/status/2097739116720910619

명확하지 않을 수 있으므로 강조할 몇 가지 주요 사항은 다음과 같습니다:

코드로서의 팩토리(Factories-as-code): 팩토리를 코드로 정의하는 것은 당신이 할 수 있는 주요 선택 중 하나입니다. 이를 통해 다양한 팩토리 구성을 테스트하여 가장 효율적이고 품질이 높은 구성을 확인할 수 있습니다.
멀티 모델 & 멀티 하네스: 팩토리가 최신 모델(프런티어 모델과 오픈 웨이트 모델 모두)을 사용하고 Claude Code 및 Codex와 같은 다양한 코딩 에이전트 하네스를 사용할 수 있는지 확인해야 합니다.
데이터 소유권: 팩토리에서 나오는 모든 데이터를 저장하고 소유해야 합니다. 이는 운영을 개선하기 위한 원자재입니다.

완전히 순조롭게 돌아가는 팩토리의 핵심 특징은 그것이 폐쇄 루프, 측정 가능하고 개선 가능한 시스템이라는 점입니다. 이것이 목표여야 합니다. 이러한 시스템에서는 모두가 동일한 컨텍스트에서, 공개적으로, 완전히 감사되고 관찰되는 방식으로 작업합니다. 에이전트 자체는 시스템을 구동하는 스킬과 구성을 관찰하고 개선을 제안합니다. 플랫폼 엔지니어는 시스템을 확장하여 모든 내부 시스템과 통합할 수 있습니다. 엔지니어링 리더는 생산성 지표를 확인하고 이를 개선하기 위해 어떤 변경 사항이 이루어지고 있는지 이해할 수 있습니다. 전체 과정은 감(vibes)이 아닌 경험적으로 운영됩니다.

Warp에서는 이 비전에 점점 더 가까워지고 있습니다. 매일 우리는 공개적으로 작업하며 팩토리를 튜닝하고, 비용을 낮추며, 처리량과 품질을 개선하고 있습니다.

우리의 사명은 세계 최고의 엔지니어링 팀이 개방형 인프라 위에서 어떤 기초 모델과 하네스를 사용하든 자신의 워크플로우를 구축, 측정 및 최적화할 수 있는 도구를 제공하는 것입니다. 이러한 역량은 팀이 더 빠르고 효율적으로 더 나은 소프트웨어를 출시하는 데 도움이 될 것입니다.

Warp Factories는 현재 얼리 액세스 단계에 있습니다. 자격을 갖춘 회사는 $10k의 팩토리 사용을 제공합니다.