클라우드 소프트웨어 팩토리 — 코딩 에이전트를 ROI가 보이는 개발 시스템으로 바꾸는 법

Warp 창업자이자 전 Google Docs 수석 엔지니어인 Zach Lloyd는 글 The guide to software factories에서 소프트웨어 개발의 다음 변화를 설명한다. 개발자가 터미널에서 코딩 에이전트를 직접 조종하는 방식에서, 이슈 분류부터 배포와 모니터링까지를 클라우드에서 자동으로 흘려보내는 클라우드 소프트웨어 팩토리로 이동한다는 주장이다.

대화형 코딩 에이전트만으로는 부족하다

Copilot, Cursor, Claude Code 같은 도구를 개발자에게 배포하는 일은 AI 도입의 좋은 출발점이다. 실제로 많은 조직이 먼저 모든 엔지니어에게 도구를 제공하고, 사용량과 도입률을 추적하며, 토큰을 많이 쓰는 팀을 격려했다. 새로운 기술을 현장에 빠르게 퍼뜨리는 단계에서는 합리적인 접근이다.

하지만 사용량이 늘었다고 사업 가치가 늘어난 것은 아니다. 개발자가 에이전트를 많이 사용해도 토큰 비용과 사람의 검토 시간을 합친 총비용이 실제 고객 가치로 이어졌는지는 불분명할 수 있다. 개발자마다 다른 모델을 선택하고, 프롬프트를 작성하고, MCP를 설치하고, 결과를 검증하면 비용·보안·품질의 편차도 커진다.

대화형 도구의 근본적인 문제는 사람이 매번 실행 방식을 결정한다는 것이다. 어떤 사람은 간단한 작업에도 가장 비싼 모델을 사용하고, 어떤 사람은 과도한 권한을 가진 MCP를 설치하며, 어떤 사람은 에이전트의 결과를 충분히 검증하지 않는다. 조직 차원에서 ROI, 보안, 규정 준수를 관리하기가 어려워지는 이유다.

Lloyd가 제안하는 해법은 개발자별 환경에 통제 장치를 계속 덧붙이는 일이 아니다. 개발 작업을 중앙화된 클라우드 팩토리로 옮겨 실행 환경, 권한, 워크플로, 관측성을 표준화하는 일이다. 이는 20년 전 서버와 개발 인프라가 클라우드로 이동하면서 얻었던 통제력·가시성·표준화의 효과를 에이전트 개발에도 적용하는 방식이다.

클라우드 소프트웨어 팩토리란 무엇인가

클라우드 소프트웨어 팩토리는 개발의 핵심 루프를 에이전트와 사람의 협업으로 자동화하는 시스템이다. 흐름은 다음과 같다.

이 구조에서 중요한 것은 모든 작업을 무조건 자동으로 처리하는 것이 아니다. 트리아지 에이전트가 작업을 세 갈래로 나눈다.

• 범위가 명확하고 자동화 가능한 작업은 구현 에이전트로 바로 보낸다.
• 명세가 필요한 작업은 사람과 명세 에이전트가 반복해서 범위를 정한 뒤 구현으로 넘긴다.
• 모호하거나 위험한 작업은 사람의 입력을 요청하거나 일단 보류한다.

따라서 팩토리는 단순한 에이전트 실행기가 아니라 작업을 자동화 가능한 경로로 라우팅하는 운영 시스템에 가깝다. Lloyd는 현재 Warp 팀의 경험을 바탕으로 전체 PR의 약 20~30%가 이슈에서 배포까지 자동화 가능하다고 설명한다. 나머지 작업도 리뷰, 검증, 모니터링처럼 일부 단계는 자동화할 수 있다. 이 수치는 보편적 벤치마크라기보다 원문 저자의 실무 경험으로 이해해야 한다.

팩토리를 구성하는 세 계층

1. 클라우드 호스트·런타임·샌드박스·코딩 에이전트

안정적인 자동화를 만들려면 에이전트를 개발자의 노트북에서 분리해야 한다. 노트북은 꺼져 있을 수 있고, 사람마다 설치된 도구와 환경이 다르며, 권한을 일관되게 관리하기 어렵다.

실행 환경은 기존 클라우드 개발 환경을 사용하거나, 환경을 Docker 이미지로 만들거나, Kubernetes 같은 오케스트레이션 플랫폼 위에 구성할 수 있다. AWS나 Google Cloud 같은 퍼블릭 클라우드뿐 아니라 Modal, Daytona 같은 에이전트 전용 호스팅 플랫폼, 또는 기업 자체 인프라도 선택지가 된다.

런타임 안에는 Claude Code, Codex, Cursor, OpenCode, Warp 같은 코딩 에이전트 하네스가 들어간다. 에이전트는 코드 저장소뿐 아니라 GitHub·GitLab, 이슈 추적 시스템, Slack·Teams, MCP와 CLI에도 접근해야 한다. 이때 다음 두 질문을 분리해서 관리해야 한다.

• 인증: 에이전트가 누구의 신원으로 행동하는가?
• 인가: 그 신원이 어떤 리소스에 어떤 권한으로 접근할 수 있는가?

팩토리의 첫 계층은 단순히 컨테이너를 띄우는 문제가 아니다. 실행 환경, 도구, 비밀, 네트워크, 저장소 권한을 함께 표준화하는 보안 경계다.

2. 오케스트레이션·통합·사람 개입

클라우드에 에이전트를 올려두는 것만으로는 일이 시작되지 않는다. 사람의 요청, 새 티켓, 일정, 모니터링 알림 같은 트리거를 받아 적절한 에이전트와 워크플로를 실행하는 오케스트레이션 계층이 필요하다.

이 계층은 특정 순서의 SDLC 루프를 실행하면서도 확장 가능해야 한다. 트리아지·명세·구현·리뷰·검증·배포·모니터링 외에 카나리 배포, 죽은 코드 정리, 회귀 분석 같은 작업을 추가할 수 있어야 한다. 동시에 모든 에이전트의 현재 상태와 과거 실행 기록을 한눈에 보여주는 팩토리 관제실 역할도 해야 한다.

통합은 새로운 목적지를 만드는 것이 아니라 팀이 이미 일하는 곳에서 팩토리를 사용할 수 있게 하는 방향이어야 한다. Slack이나 Teams에서 작업을 만들고, Jira나 Linear에서 상태를 확인하고, GitHub의 코드 리뷰에서 에이전트 동작을 조정할 수 있어야 한다. 리뷰 에이전트가 저장소의 규칙과 다른 조언을 한다면, 개발자가 리뷰 화면에서 바로 그 행동을 수정하도록 지시할 수 있어야 한다.

사람의 개입은 실패를 보완하는 예외 처리가 아니라 팩토리의 기본 기능이다. 원문이 강조하는 핵심 프리미티브는 세 가지다.

• Steering: 실행 중인 에이전트 세션에 들어가 방향을 조정한다.
• Handoff: 에이전트 세션과 컨텍스트를 클라우드와 로컬 사이에서 옮긴다.
• Notifications: 도움이 필요한 순간 사람에게 알린다.

복잡한 작업을 클라우드에서 로컬 작업대로 넘기거나, 자동 검증 대신 사람이 직접 결과를 확인해야 하는 경우가 있다. 이 경로가 없으면 개발자는 팩토리를 우회하게 되고, 자동화 시스템은 오히려 마찰을 만든다.

3. 측정·평가·메모리

팩토리 접근법의 경영적 의미는 개발 자동화를 측정하고 개선할 수 있다는 데 있다. Lloyd가 제시하는 간단한 지표는 다음과 같다.

팩토리 효율 = 출시된 제품 / 토큰 비용

이 식은 단순하지만 방향을 바꾼다. 토큰을 얼마나 많이 썼는지가 아니라, 일정한 비용으로 고객에게 전달된 결과를 얼마나 만들었는지를 본다. 이를 위해서는 작업이 클라우드에서 중앙화되고, 각 단계의 입력·출력·비용·지연·재작업이 기록되어야 한다.

그 위에서 다음과 같은 실험을 진행할 수 있다.

• 작업 유형별로 어떤 모델과 하네스 조합이 가장 적합한지 비교한다.
• MCP와 스킬의 구성과 설명이 결과에 미치는 영향을 평가한다.
• 트리아지 비용을 줄이거나 컴퓨터 사용 검증의 정확도를 높이는 자기개선 에이전트를 운영한다.
• 과거 상호작용에서 명시적 규칙과 암묵적 패턴을 추출해 다음 작업의 컨텍스트에 반영한다.

메모리는 기업이 직접 소유하고 저장해야 한다. 에이전트가 배운 규칙과 작업 이력이 벤더 내부에만 남으면, 자동화 효율이 높아질수록 특정 플랫폼에 묶이는 역설이 발생한다.

여러 하네스와 모델을 지원해야 한다

최고의 에이전트는 고정된 선택지가 아니다. 모델과 하네스의 비용·품질·속도는 빠르게 바뀌므로 팩토리는 여러 실행기를 교체하거나 혼합할 수 있어야 한다.

모델 라우팅의 기준도 단순한 최고 성능이 아니다. 주어진 작업의 품질 기준을 통과하는 모델 중 가장 저렴하고 빠른 모델을 선택하는 것이 목표다. 한 작업 안에서도 초안 작성에는 가벼운 모델을 쓰고, 중요한 검토에는 더 강한 모델을 쓰는 식의 조합이 가능하다.

단일 모델이나 단일 하네스에 고정하면 세 가지 위험이 커진다.

1. 비용 종속: 모델 공급자가 가격과 사용 조건을 바꿀 때 대응하기 어렵다.
2. 가용성 종속: 모델 제공자의 장애가 개발 전체를 멈출 수 있다.
3. 정책·지정학적 종속: 지역 규제나 수출 통제로 특정 모델을 사용할 수 없게 될 수 있다.

따라서 팩토리 벤더를 선택할 때는 여러 하네스와 모델을 지원하는지, 회사가 데이터를 소유하는지, 자체 호스팅을 포함해 다양한 컴퓨트를 선택할 수 있는지, Bedrock·Vertex·Azure 같은 자체 추론 엔드포인트를 연결할 수 있는지를 확인해야 한다. 벤더가 토큰을 재판매하는 구조라면 비용 최적화와 매출 확대 사이에 이해 충돌이 생길 수 있다는 점도 살펴봐야 한다.

팩토리는 코드로 관리해야 한다

소프트웨어 팩토리는 일회성 설정이 아니라 CI/CD와 비슷한 인프라다. 따라서 팩토리의 구성, 워크플로, 권한, 모델 라우팅, 평가 기준을 파일로 정의하고 버전 관리하는 편이 좋다.

이렇게 하면 세 가지 이점이 생긴다.

• 변경 이력을 검토하고 되돌릴 수 있다.
• 에이전트가 팩토리 설정 자체를 수정할 수 있다.
• 개발 환경과 운영 환경의 차이를 줄일 수 있다.

다만 에이전트에게 팩토리 설정을 수정할 권한까지 주는 순간, 시스템은 자기 자신을 바꾸는 단계에 들어간다. 자동 평가와 사람의 승인, 권한 분리, 회귀 검증이 없으면 팩토리의 효율을 높이는 변경이 실제로는 보안과 품질을 훼손할 수 있다.

직접 만들 것인가, 사서 쓸 것인가

Lloyd는 대부분의 회사가 팩토리 인프라 전체를 직접 만들 필요는 없다고 주장한다. 실행 환경, 오케스트레이션, 통합, 권한, 세션 이동, 관측성, 평가를 모두 개발하고 유지하는 일은 생각보다 크기 때문이다. 고객 문제를 해결해야 하는 팀의 핵심 역량을 내부 플랫폼 유지보수에 쓰게 될 수 있다.

예외는 Stripe나 Uber처럼 개발 조직이 매우 크고, 기존의 복잡한 개발 인프라와 팩토리를 긴밀하게 결합해야 하는 경우다. 이 정도 규모에서는 자체 구축이 차별화된 운영 역량이 될 수 있다.

글의 후반부는 Warp가 기업의 팩토리 구축을 돕는다는 제안으로 이어진다. 따라서 클라우드 팩토리의 필요성에 대한 설명과 Warp의 제품·사업 관점은 구분해서 읽어야 한다. 어떤 벤더를 선택하든 데이터 소유권, 여러 모델·하네스 지원, 컴퓨트 유연성, 자체 추론 엔드포인트 연결 여부를 계약 전에 확인하는 것이 핵심이다.

실무에 적용할 때의 순서

이 글의 주장을 조직에 적용한다면 처음부터 모든 개발 업무를 자동화하려고 하기보다, 측정 가능하고 되돌릴 수 있는 흐름부터 시작하는 편이 현실적이다.

1. 한 가지 이슈 유형을 고른다. 반복적이고 입력과 성공 조건이 비교적 명확한 버그 수정이나 의존성 업데이트처럼 시작 범위가 좁은 작업이 적합하다.
2. SDLC 단계를 기록한다. 트리아지부터 배포까지 각 단계의 처리 시간, 토큰 비용, 사람의 개입, 재작업, 실패 원인을 수집한다.
3. 사람의 승인 지점을 정한다. 코드 리뷰와 운영 배포처럼 위험이 큰 단계에서는 자동 실행보다 명시적 승인을 우선한다.
4. 클라우드 실행 환경을 표준화한다. 저장소, 테스트, 도구, 네트워크, 권한을 하나의 재현 가능한 런타임으로 묶는다.
5. 자동화율보다 결과를 평가한다. 자동 처리한 이슈의 수보다 배포 후 결함, 롤백, 고객 가치, 총비용을 함께 본다.
6. 실패를 팩토리 개선으로 연결한다. 에이전트가 실패한 이유를 새 규칙, 평가 케이스, 스킬, 라우팅 정책으로 바꾸고 회귀 여부를 확인한다.

이렇게 하면 팩토리는 개발자를 대체하는 거대한 자동화 프로젝트가 아니라, 특정 작업 흐름에서 사람의 반복 판단을 줄이고 결과를 측정하는 운영 시스템으로 시작할 수 있다.

결론 및 시사점

클라우드 소프트웨어 팩토리는 코딩 에이전트를 더 많이 배포하자는 제안이 아니다. 대화형 도구를 조직의 개발 시스템 안으로 가져와, 이슈·코드·검증·배포·운영 데이터를 하나의 루프로 연결하자는 제안이다.

핵심은 세 가지다. 첫째, 에이전트의 실행 위치를 클라우드로 옮겨 환경과 권한을 표준화해야 한다. 둘째, 오케스트레이션과 사람의 개입 경로를 함께 설계해야 한다. 셋째, 모델·하네스·스킬·메모리를 실험하고 실제 출시 결과와 비용으로 개선 효과를 측정해야 한다.

동시에 이 접근법은 중앙화와 벤더 종속을 혼동하지 않아야 한다. 데이터는 조직이 소유하고, 여러 모델과 하네스를 교체할 수 있으며, 사람은 언제든 실행을 조정하거나 되돌릴 수 있어야 한다. 팩토리의 목표는 자율성을 최대화하는 것이 아니라, 통제 가능한 범위에서 소프트웨어 생산성을 지속적으로 높이는 것이다.

한 줄 결론: 코딩 에이전트의 다음 단계는 개발자 옆의 대화형 도구가 아니라, 사람의 판단과 에이전트의 실행을 SDLC 전체에 연결하는 클라우드 소프트웨어 팩토리다.