에이전트 환경에서 무너진 CI/CD: 지속적 컴퓨팅 스택 (The Continuous Compute Stack)

📖 차트와 임베디드 소스가 포함된 전체 버전은 AgentConn에서 읽어보세요 → 지난주 AI Engineer Europe에서 Hugo Santos (Namespace CEO)와 Madison Faulkner (NEA)는 플랫폼 엔지니어들이 모인 자리에서 모두가 속으로만 생각하던 것을 공개적으로 언급했습니다: 에이전트 기반 시스템에서 CI/CD는 끝났다는 것입니다. 전통적인 CI는 개발자가 일주일에 한두 개의 diff를 푸시하는 인간을 위해 구축되었습니다. 수천 개의 자율 에이전트가 지속적으로 PR(Pull Request)을 생성하며 규모를 확장하면, 추상화 계층이 무너집니다 — 러너 포화(runner saturation), 모든 브랜치에서의 차가운 Docker 빌드(cold Docker builds), 비용 폭발, 그리고 에이전트가 테스트 결과를 확인하기 전에 컨텍스트가 소멸되어 버리는 피드백 지연(feedback latency) 등이 발생합니다. 그들은 이를 대체할 새로운 용어를 만들어냈습니다: 지속적 통합(continuous integration)이 아닌, 지속적 컴퓨팅(continuous compute)과 지속적 컴퓨터(continuous computers)입니다. 이 프레임워크는 매우 날카로운데, 그 이유는 이 프레임워크가 가리키는 구조적 변화가 이미 일어나고 있기 때문입니다. 또한, Claude Code Max, Cursor, 또는 프라이빗 에이전트 플릿(private agent fleet)을 운영하는 모든 운영(ops) 팀이 향후 두 분기 동안 비용을 청구받게 될 운영 계층을 의미하기 때문입니다. 이 글은 세 가지를 다룹니다. 첫째, 전통적인 CI가 에이전트 규모의 부하 하에서 구조적으로 무너지는 네 가지 방식을 명명합니다. 둘째, 이번 주 ElevenLabs, Vercel, Anthropic, 그리고 GitHub 트렌딩 차트 전반에서 눈에 띄게 형성되고 있는 프로덕션 스택을 매핑합니다. 셋째, 엔지니어링 조직을 위해 에이전트 워크플로우를 활성화한 후 CI 비용이 세 배로 급증할 때를 대비하여 운영 팀을 위한 구매자 가이드 체크리스트를 제공합니다.

1. 전통적인 CI/CD가 실제로 무너지는 지점
   구조적 변화를 뒷받침하는 세 가지 수치가 있습니다:

• 인간의 PR 볼륨: 일반적인 팀의 경우 개발자당 하루 약 10개의 PR. 리뷰와 머지(merge)를 포함하면 중형 코드베이스 기준 저장소당 하루 약 50~100회의 CI 실행.
• 에이전트 PR 볼륨: 이번 주 Opus 4.7을 사용하여 8개의 항공편과 5개의 호텔을 한 번에 예약하는 Cowork 사례가 있었습니다 — 다단계 에이전트 워크플로우는 이제 기본적으로 다중 PR을 생성합니다. 플릿을 운영하는 운영자들은 에이전트 계층에서만 하루 100~1,000개 이상의 PR을 목격합니다.
• PR당 CI 비용: Docker 빌드, 의존성 설치, 전체 테스트 스위트(test suites). CI 실행 시간이 12분인 일반적인 SaaS 저장소의 경우, 호스팅된 러너(hosted runners) 기준 실행당 약 $0.20–$0.40가 소요됩니다.

저장소당 하루에 1,000배 이상 곱해집니다. 실행 속도가 두 자릿수(two orders of magnitude)만큼 급증하면 네 가지 문제가 발생합니다.

1. Docker 빌드 캐시 무효화 패턴 (Docker build cache invalidation patterns). 빌드 캐시는 인간의 속도에 맞춘 커밋 주기 (commit cadence)를 가정합니다. 즉, 대부분의 푸시(push)가 공유된 베이스 레이어(base layer)에 도달한다는 가정입니다. 병렬 샌드박스 (parallel sandboxes)에서 병렬 브랜치로 작업하는 에이전트들은 인간 팀처럼 브랜치 조상 (branch ancestry)을 공유하지 않기 때문에 캐시를 빠르게 소진합니다. 모든 에이전트 브랜치에서 콜드 빌드 (Cold builds)가 발생하면, 5분짜리 CI 실행이 15분으로 늘어나고 러너 (runner) 비용은 두 배로 증가합니다.

2. 러너 풀 크기 조정 (Runner pool sizing). 풀 용량 (Pool capacity)은 인간의 PR 속도에 맞춰 계획됩니다. 일단 자율 에이전트 (autonomous agents)를 가동하면, 그 속도는 커밋 사이에 커피를 마시는 개발자가 아니라 에이전트의 초당 토큰 (token-per-second) 예산에 의해 결정됩니다. 당신은 풀을 포화 상태로 만들 것입니다. 대기열 (queueing)이 발생할 것입니다. 대기열은 CI가 에이전트에게 테스트 통과 여부를 알려주기도 전에 에이전트의 컨텍스트 (context)를 더 빠르게 소모할 것입니다.

3. 테스트 피드백 지연 (Test-feedback latency). 인간이 CI를 기다릴 때 12분은 짜증 나는 시간입니다. 에이전트가 CI를 기다릴 때 12분은 컨텍스트 부식 (context decay)입니다. PR을 제출한 에이전트는 결과를 확인하는 에이전트와 더 이상 동일하지 않습니다. 즉, 에이전트의 작업 메모리 (working memory)가 재활용된 것입니다. 결과는 대기열 속의 오래된 메시지가 되고, 에이전트는 그 결과에 따라 행동하기 위해 PR 디프 (PR diff)로부터 컨텍스트를 다시 도출해야 합니다.

4. 브랜치 위생 (Branch hygiene). 에이전트 브랜치는 생성하기는 쉽지만 삭제하기는 비용이 많이 듭니다. 운영자들은 각기 빌드 아티팩트 (build artifact), 캐시, 그리고 GitHub이 저장 비용을 부과하는 메타데이터를 가진 수천 개의 오래된 에이전트 브랜치가 저장소에 쌓이는 것을 발견하고 있습니다.

가비지 컬렉션 (Garbage collection) 문제는 매력적이지 않습니다. 하지만 이는 2026년 운영자들이 보고하고 있는 예상치 못한 플랫폼 지출의 가장 큰 단일 원인입니다.

이것이 파괴(demolition)입니다. 이제 구축(construction)입니다.

2. 눈에 보이게 형성되고 있는 지속적 컴퓨팅 스택 (The Continuous Compute stack)
   CI를 대체하는 것의 형태는 네 개의 뚜렷한 레이어 (layers)로 분해되고 있으며, 각 레이어는 이번 주에 출시 순간을 맞이했습니다. 이러한 우연이 일치하는 현상은 왜 이 수렴 (convergence)이 실재하는지를 보여주는 이유 중 하나입니다.

단일 플랫폼을 과장하는 사람은 아무도 없습니다. 인접한 니치 (niche) 시장의 여러 플레이어들이 독립적으로 이 아키텍처를 확인해주고 있습니다.

Layer 1: 라우팅 계층 (The routing layer) — 명시적 워크플로 그래프 (explicit workflow graphs)가 메가 프롬프트 (mega-prompt)를 대체합니다. ElevenLabs는 비주얼 그래프 에디터를 핵심 인터페이스로 내세운 Agent Workflows를 출시했습니다. 그 설명은 건조합니다. "에지 (edges)는 동적이고 문맥 인식적인 대화 경로를 가능하게 하는 정교한 라우팅 로직을 지원합니다"라고 말이죠. 하지만 그 밑바닥에 깔린 구조적 변화가 진짜 뉴스입니다. 단일 프롬프트 에이전트가 조건부 분기 (conditional branching), 서브 에이전트 디스패치 (sub-agent dispatch), 그리고 노드별 도구/지식 베이스 오버라이드 (per-node tool/knowledge-base overrides)를 갖춘 명시적 라우팅 그래프에 자리를 내주고 있다는 점입니다. 이는 2년 전 LangGraph와 CrewAI가 보여준 것과 같은 이야기지만, 이제는 실제로 프로덕션 비용 (production tax)을 지불하고 있는 단계입니다. 2026년 5월 릴리스 노트에는 분기 표현식을 위한 conditional_operator AST 노드와 워크플로 로직 내 null 비교 분기를 위한 ASTNullNode 타입이 언급되어 있습니다. 이것은 마케팅이 아닙니다. 프로덕션 에이전트를 위한 그래프 실행 엔진 (graph-execution engine)을 구축하고 있는 팀의 모습입니다. 프로덕션 트래픽을 위한 메가 프롬프트 시대는 끝났습니다. ElevenLabs Agent Workflows 문서 →

Layer 2: 기질 (The substrate) — 스토리지 (storage)가 아닌 파일 시스템 (filesystems)

Vercel의 Nico Albanese는 이번 주 "에이전트에게 컴퓨터를 부여하라 (Give Your Agent a Computer)"라는 강연으로 화제가 되었습니다. 핵심 논지는 에이전트에게 (단순한 스토리지가 아닌) 파일 시스템을 부여하는 것이 에이전트의 행동 방식을 바꾸었다는 것입니다. 지속적인 FS 형태의 기질을 가진 에이전트들은 매 호출마다 문맥을 다시 도출하는 것을 멈추고, 다단계 작업을 완수하기 시작했습니다. 즉, 인간이 메모장 (scratchpads)을 사용하는 방식처럼 파일을 사용하게 된 것입니다. 이는 CI 문제에 있어 구조적으로 중요한데, 데이터 지역성 (data-locality) 문제와 실행 (execution) 문제를 분리하기 때문입니다. 지속적 컴퓨팅 (Continuous compute)은 "더 많은 러너 (runners)"를 의미하는 것이 아닙니다. 그것은 에이전트의 컴퓨팅 환경이 PR (Pull Request) 사이에도 지속된다는 것을 의미합니다. 에이전트는 콜드 스타트 (cold restart)를 하지 않습니다. 에이전트의 파일 시스템 상태가 그대로 이어집니다. 이는 CI가 설계된 방식의 역전입니다. 기존의 CI는 인간의 PR이 지속적인 디스크 상태를 필요로 하지 않기 때문에 명시적으로 휘발성 (ephemeral)이었습니다. 하지만 에이전트의 PR은 그렇지 않습니다.

Layer 3: 컨트롤 플레인 (Control Plane) — 에이전트 뷰 (Agent View)
Anthropic은 5월 11일에 Agent View를 출시했습니다. 이는 Claude Code의 리서치 프리뷰 (research preview)로, 하나의 화면에서 여러 에이전트 세션을 나열하고, 시작하며, 감독할 수 있습니다. Boris Cherny의 발표는 486,000회의 조회수를 기록했으며, Cowork의 1-shot 예약 흐름에 관한 동반 발표는 424,000회의 조회수를 추가로 기록했습니다. 신호는 명확합니다. 다음 단계의 지배적인 UI 패턴은 '저자로서의 인간 (human-as-author)'이 아니라 '에이전트 함대의 오케스트레이터로서의 인간 (human-as-orchestrator-of-agent-fleets)'입니다. 지속적 컴퓨팅 (continuous compute)에 대한 시사점은 단순한 관찰 가능성 (observability)이나 대시보드 (dashboards)를 넘어, 새로운 세션을 파견하고, 무엇이 차단되었는지 확인하며, 작업을 재라우팅 (reroute)할 수 있는 제어 표면 (control surface)이 필요하다는 것입니다. Agent View의 각 행은 세션, 입력 필요 여부, 마지막 응답, 그리고 최신성을 보여줍니다. 이것이 지속적 컴퓨팅의 사용자 대면 형태입니다. CI 대시보드의 자식의 자식 격입니다. Claude.com에서 Agent View 발표 읽기 →

Layer 4: 기능 번들 (Capability Bundles) — 휴대 가능한 단위로서의 기술 (skills)
이번 주 GitHub 트렌딩 차트는 '제품으로서의 기술 번들 (skill-bundles-as-product)'이 장악하고 있습니다. mattpocock/skills는 하루 만에 +3,372개의 스타를 기록하며 1위를 차지했습니다 (

rohitg00/agentmemory는 이번 주 GitHub 트렌딩 차트 5위를 기록하며 +1,335개의 스타를 얻었습니다 — "실제 벤치마크를 기반으로 한 AI 코딩 에이전트용 #1 영구 메모리 (Persistent memory)." farion1231/cc-switch (#6, +1,186)는 메모리를 보존하면서 에이전트 CLI 간을 전환하기 위한 메타 도구 (meta-tool)입니다. 운영 (ops) 팀에게 메모리 계층은 예산 문제입니다. 메모리는 에이전트가 실행 전반에 걸쳐 학습을 분할 상환 (amortize)할지, 아니면 매 PR마다 재유도 (re-derivation) 비용을 지불할지를 결정합니다. 분할 상환에 관한 수치는 극명합니다. 운영자들이 인용하는 내부 벤치마크에 따르면, 메모리가 올바르게 연결되었을 때 컨텍스트 검색 (context-retrieval) 절감액은 전체 에이전트 토큰 지출의 30~60%에 달합니다. GitHub의 rohitg00/agentmemory → 3. Cowork 변곡점: 다단계 (multi-step)가 이제 실제로 작동합니다. 스택이 왜 이렇게 빠르게 분해되는지에 대한 단 하나의 신호를 원한다면, 그것은 Anthropic의 Cowork입니다. 하나의 에이전트. 단 한 번의 시도. 8개의 항공편 예약, 5개의 호텔 예약. 다단계 계획 (multi-step planning), 예약 API 전반의 도구 사용 (tool use), 중간 실패로부터의 복구 — 이 모든 것이 단일 세션 내에서 이루어집니다. 발표 트윗이 424k 회의 조회수를 기록한 이유는 운영자들이 자신들이 무엇을 보고 있는지 이해했기 때문입니다: 다단계 에이전트 신뢰성 (multi-step agent reliability)의 실질적인 하한선이 방금 이동했습니다. 하한선이 이동하면, 그 아래의 운영 스택 (operational stack)도 따라잡아야 합니다. 다단계 신뢰성은 애초에 모든 CI 가정을 무효하게 만든 핵심 요소입니다. 단일 인간의 PR은 단계 사이에 상태 (state)를 보존하며 순차적으로 13가지 항목을 예약하지 않습니다. 하지만 에이전트의 PR은 가능합니다. 그리고 이것이 기대되는 워크로드 (workload)가 되는 순간, CI 기질 (CI substrate)은 이를 위해 재설계되어야 합니다. 4. 운영 팀을 위한 구매 체크리스트 만약 엔지니어링 조직이 Claude Code Max를 활성화하여 CI 비용이 세 배로 뛸 상황에 처해 있다면, 실제로 무엇을 구매하거나 구축해야 할지는 다음과 같습니다: 1. 라우팅/워크플로 에디터 (routing/workflow editor). 대화형 AI (conversational AI) 환경에 있다면 ElevenLabs Agent Workflows를 선택하십시오. TypeScript 우선이라면 LangGraph 또는 Vercel AI SDK Workflows를 선택하십시오. 핵심은 프로덕션 파이프라인으로서 단 하나의 메가 프롬프트 (mega-prompt)를 작성하는 것이 아닙니다.

1. 프로덕션에 배치하는 모든 커스텀 요소는 팀원이 4,000토큰 분량의 프롬프트를 읽지 않고도 검토할 수 있는 시각화 가능한 그래프 (visualizable graph) 형태여야 합니다. 2. 에이전트를 위한 지속적인 파일 시스템 레이어 (persistent filesystem layer). S3도 아니고 데이터베이스도 아닙니다. 에이전트 실행 사이에도 유지되는 실제 파일 시스템 시맨틱 (filesystem semantics)이 필요합니다. Vercel의 패턴이 한 가지 접근 방식이며, CI 빌드 이후에도 지속되는 Docker 볼륨 (Docker volumes)을 실행하는 것이 또 다른 방식입니다. 핵심 요구사항은 에이전트가 매 PR (Pull Request)마다 콜드 스타트 (cold start) 상태로 시작하지 않아야 한다는 것입니다. 3. 에이전트 군단 (fleet-of-agents)을 위한 컨트롤 플레인 (control plane). 이제 Claude Code Agent View가 표준 참조 모델입니다. 사람이 군단 전체의 상태를 한눈에 파악하고 명령을 내리거나 리다이렉트 (dispatch/redirect)할 수 있는 무언가를 구축하거나 구매하십시오. 이것이 없다면, 당신은 시스템이 아닌 개별 에이전트에 대한 관측성 (observability)만을 갖게 됩니다. 4. 스킬 번들 컨벤션 (skill-bundle convention). Anthropic의 claude/skills 디렉토리 형식을 채택하거나, 현재 유행하는 대안들 (mattpocock/skills, obra/superpowers) 중 하나를 채택하십시오. 핵심은 자신만의 것을 발명하는 것이 아닙니다. 스킬은 지식이 에이전트 간에 이식 가능하게 (portable) 만드는 방법입니다. 5. 지속적인 메모리 레이어 (persistent memory layer). agentmemory 또는 그에 상응하는 기술이 필요합니다. 분할 상환된 메모리 (amortized memory)가 없다면, 당신의 에이전트는 매 PR마다 코드베이스로부터 컨텍스트 (context)를 재도출하는 데 40% 이상의 시간을 소비하게 됩니다. 이것이 스택 내에서 가장 큰 비용 절감 레버 (cost-saving lever)입니다. 6. 브랜치 위생 자동화 (Branch hygiene automation). 삭제 작업을 구축하십시오. 이를 스케줄링하십시오. 에이전트가 작성한 브랜치에는 커밋 메타데이터에 태그를 달아, 사람에게 영향을 주지 않으면서 작성자 클래스별로 정리(prune)할 수 있도록 하십시오. Hugo Santos와 Madison Faulkner의 프레임워크인 '지속적 통합 (continuous integration)이 아닌 지속적 컴퓨팅 (continuous compute)'은 그 형태를 정확히 포착하고 있습니다. 기질 (substrate)은 지속되는 컴퓨터입니다. 결과물은 '통합된 빌드 아티팩트 (integrated build artifact)'가 아니라 '행동할 수 있는 일관된 상태를 가진 에이전트'입니다. 이는 CI/CD 세대가 인간의 속도에 맞춘 팀을 위해 해결했던 문제와 동일하며, 에이전트의 속도에 맞는 현실에 맞춰 재설계된 것입니다. 운영자들에게는 플랫폼의 2차 계층이 자신들이 직접 구축했어야 할 라우팅 및 메모리 레이어에 대해 프리미엄 요금을 부과하기 시작하기 전까지, 이 스택을 구축할 수 있는 한 분기의 시간이 남아 있습니다. 어휘는 새롭지만, 아키텍처는 구체적입니다.

청구서가 날아오고 있습니다. 에이전트 런타임 (agent runtime) 측에서 무엇이 실행되고 있는지에 대한 자세한 내용은, 에이전트 하네스 파편화 (agent harness fragmentation) 및 기술 시장 경쟁 (skill marketplace race)에 관한 저희의 보도를 참조하십시오. 원래 AgentConn에 게시되었습니다.