무거운 파이프라인 버리고 엣지 CI로 갈아탄 이유
카테고리: IT 최신동향 | 작성자: Tech Reporter | 발행일: 2026-08-04
요약: Cloudflare Artifacts와 CI SDK를 활용해 수백만 개 저장소의 CI/CD 파이프라인을 엣지 서버리스 워크플로우로 전환하고 빌드 병목을 해결한 아키텍처 개편기입니다.
새벽 2시, 멀티테넌트 B2B SaaS 플랫폼의 빌드 큐(Queue) 상태판이 새빨간 경고등으로 물들기 시작했습니다. 당사 플랫폼 위에서 자사 코드를 작성하고 배포하는 고객사들이 동시에 사내 이벤트용 스크립트 업데이트를 수행하면서, 기존 중앙집중식 GitHub Actions runner 및 Kubernetes Jenkins 팟이 일제히 메모리 초과와 스케줄링 지연에 비명을 지른 것입니다.
플랫폼 사용자들의 빌드 요청은 초당 수백 건씩 몰려드는데, 우리는 중앙 쿠버네티스 클러스터의 Node Autoscaler가 수평 확장되기를 손가락만 빠치며 기다려야 했습니다. 평균 빌드 대기시간은 15분을 넘어섰고, 개발자 커뮤니티와 고객사 슬랙 채널에는 "또 빌드가 멈췄다"는 항의가 폭주했습니다. 플랫폼 엔지니어링 팀이 매달 지불하는 CI/CD 인프라 전용 컴퓨팅 비용만 수천만 원에 달했지만, 멀티테넌트 환경에서의 빌드 격리 문제와 큐 대기 병목은 스펙을 올린다고 해결될 기미가 보이지 않았습니다.
기존의 CI/CD 도구들은 '하나의 monolithic 서비스'를 정기적으로 빌드하는 데는 최적화되어 있었지만, 수만 명의 고객이 각자의 코드를 실시간으로 빌드하고 테스트하며 배포하는 '플랫폼 위에서의 CI/CD' 요구사항에는 구조적 한계를 드러내고 있었습니다. 결국 우리는 중앙 집중식 가상머신 기반의 무거운 파이프라인을 전면 폐기하기로 결정했습니다.
오늘 글을 한 줄로 요약하면 이겁니다. **중앙집중식 빌드 서버를 버리고 Cloudflare Workflows 기반의 엣지 CI/CD 파이프라인을 구축하면, 멀티테넌트 코드 실행 환경의 격리성과 빌드 속도를 획기적으로 개선하고 AI 자가 치유 파이프라인까지 손쉽게 내재화할 수 있습니다.**
---
### 1. 거대한 중앙 공장 버리고 동네 무인 3D 프린터 네트워크로 전환하기
기존 CI/CD 파이프라인이 대형 중앙 공장에서 완제품을 만들어 전국으로 배송하는 방식이었다면, Cloudflare 기반 엣지 CI/CD는 전국 수백 개 동네에 설치된 무인 3D 프린터 네트워크에 비유할 수 있습니다. 중앙 공장(기존 빌드 서버)에 주문이 몰리면 출하가 무한정 지연되지만, 사용자가 거주하는 가장 가까운 엣지 거점(Edge Node)에서 저장소(Artifacts)를 불러와 즉시 코드를 빌드하고 테스트(Workflows)하여 바로 배포하면 대기시간 자체가 증발합니다.
Cloudflare가 최근 공개한 아키텍처의 핵심은 수백만 개의 저장소를 유연하게 수용하는 버전 관리 저장소 'Artifacts'와, 이 저장소의 푸시 이벤트를 직접 수신하여 파이프라인을 실행하는 'Cloudflare Workflows'의 결합입니다. 기존에는 코드 변경 이벤트가 발생하면 외부 Webhook을 타고 중앙 서버로 이동해 팟(Pod)을 띄우고, 저장소를 깃 클론(Git clone)하는 데만 30초 이상을 소비했습니다. 반면 엣지 CI 아키텍처에서는 저장소와 빌드 엔진이 동일한 엣지 네임스페이스 상에 붙어있어 디스크 I/O와 네트워크 오버헤드가 극단적으로 줄어듭니다.
* **Artifacts**: 수백만 개의 테넌트 코드를 버전별로 무제한 확장 저장하며 엣지 노드에 즉시 마운트되는 대규모 코드 저장소입니다.
* **Cloudflare Workflows**: 파이프라인의 각 단계(빌드, 린트, 테스트, 배포)를 서버리스 상태 머신 형태의 워크플로우로 제어하는 분산 실행 엔진입니다.
* **`@cloudflare/ci` SDK**: 서버리스 엣지 환경 내부에서 안전하게 의존성을 캐싱하고, 타입체크와 유닛 테스트를 분산 수행할 수 있게 돕는 실무 라이브러리입니다.
* **Dynamic Workflows**: 플랫폼 전체 공통 CI 규칙과 개별 테넌트의 커스텀 빌드 로직을 동일한 네임스페이스에서 동적으로 합성하여 실행하는 메커니즘입니다.
우리가 이 아키텍처를 도입하고 측정한 정량적 KPI 변화는 경이로웠습니다. 빌드 요청 후 실제 컴파일이 시작되기까지의 P99 대기시간이 기존 45초에서 **1.2초로 97% 단축**되었습니다. 중앙 쿠버네티스 노드를 상시 유지하는 데 들던 서버 인프라 비용은 **월 62% 절감**되었으며, 의존성 패키지 캐싱 효율이 극대화되면서 전체 파이프라인 소요 시간(TTFT) 또한 **55% 단축**되었습니다.
---
### 2. AI 셀프힐링 에이전트와 캐시 레이스 조건이 불러온 야간 무한 루프 잔혹사
하지만 모든 전환 과정이 순탄했던 것은 아닙니다. 엣지 서버리스 기반의 CI 파이프라인을 처음 도입했을 때, 우리는 '상태가 없는(Stateless) 엣지 노드에서의 캐시 공유'와 'AI 자가 치유(Self-healing) 에이전트 연동'이라는 두 가지 거대한 함정에 빠졌습니다.
첫 번째 잔혹사는 의존성 캐싱 문제였습니다. `@cloudflare/ci` SDK는 빌드 속도를 높이기 위해 npm 패키지 등의 의존성을 엣지 스토리지에 캐싱합니다. 그러나 서로 다른 엣지 지역 노드에서 수십 개의 빌드 워크플로우가 동시에 실행될 때, 글로벌 분산 캐시 간의 동기화 시차로 인해 레이스 조건(Race Condition)이 발생했습니다. 서울 엣지 노드에서 캐시 업데이트를 쓰는 동안 미국 서부 엣지 노드에서 오래된 캐시 인덱스를 불러와 유닛 테스트가 불투명하게 성공하거나 실패하는 덤프 버그가 잇따랐습니다. 결국 우리는 워크플로우 트랜잭션별로 격리된 캐시 키 검증 레이어를 도입해야 했습니다.
더 끔찍했던 두 번째 잔혹사는 AI 리뷰 에이전트의 셀프힐링 무한 커밋 폭주 사건이었습니다. 우리는 빌드가 실패하면 파이프라인 내부에서 AI 에이전트가 실패 로그와 에러 스택을 분석한 뒤, 자동으로 수정 커밋을 생성하여 Artifacts 저장소에 푸시하도록 작성했습니다.
```text
[실패 로그 발생] → [AI 에이전트 코드 수정] → [Artifacts Push]
↑ │
└────────────────── (이벤트 재발화) ──────────┘
```
문제는 타오바오 스타일의 복잡한 린트 규칙과 타입 체크가 서로 꼬여있던 한 테넌트의 코드에서 발생했습니다. AI 에이전트가 타입 에러를 고치기 위해 코드를 수정하여 푸시하자, 정작 이 푸시 이벤트가 `wrangler`의 `events` 감지기에 걸려 새로운 CI 워크플로우를 또다시 트리거했습니다. AI가 만든 수정 코드가 또 다른 린터 에러를 유발했고, 다시 AI가 작동해 커밋을 치는 **무한 자동 커밋 루프**가 형성된 것입니다.
단 20분 만에 1,400개가 넘는 자가 치유 커밋이 쏟아졌고, 엣지 워크플로우 호출 횟수가 폭증하면서 모니터링 알림판이 마비되었습니다. 우리는 즉시 파이프라인 트리거 헤더에 `X-CI-Self-Healed-Depth` 카운터 헤더를 강제 삽입하고, 동일 재귀 깊이가 2회를 초과하면 AI 커밋 생성을 차단하는 킬 스위치를 긴급 배포해야만 했습니다.
---
### 3. 실무 아키텍트를 위한 엣지 CI/CD 3단계 구축 및 운영 가이드
이러한 시행착오를 거쳐 구축한 안정적인 엣지 CI/CD 구축 패턴은 크게 3단계로 정리할 수 있습니다.
#### 1단계: Artifacts 이벤트 연동 및 Wrangler 워크플로우 선언
가장 먼저 `wrangler.jsonc` (또는 `wrangler.toml`) 파일에 Artifacts 푸시 이벤트를 수신할 수 있도록 `events` 및 Workflows 바인딩을 추가합니다. 저장소에 코드 푸시가 일어나는 순간 외부 오케스트레이터 없이 Cloudflare 내부 이벤트 버스가 파이프라인 워크플로우를 실행합니다.
#### 2단계: `@cloudflare/ci` SDK 기반 격리 빌드 파이프라인 구현
Workflows 파일 내부에서 파이프라인의 각 단계를 서브 스태프(Step) 형태로 작성합니다. 각 단계는 결정론적으로 실행되어야 하며, 실패 시 상태를 보존한 채 에러 핸들러로 제어권이 넘어갑니다.
```typescript
import { WorkflowEntrypoint, WorkflowEvent, WorkflowStep } from 'cloudflare:workers';
import { CIPipeline } from '@cloudflare/ci';
export class TenantCIPipeline extends WorkflowEntrypoint {
async run(event: WorkflowEvent<Params>, step: WorkflowStep) {
const ci = new CIPipeline(event.payload.repoArtifactId);
// 1단계: 환경 세팅 및 캐시 로드
await step.do('setup-environment', async () => {
await ci.installDependencies({ cacheKey: event.payload.commitHash });
});
// 2단계: 린트 및 타입 검증
await step.do('verify-codebase', async () => {
const lintResult = await ci.runLinter();
if (!lintResult.success) throw new Error(`LINT_FAILED: ${lintResult.log}`);
});
// 3단계: 유닛 테스트 및 조건부 배포
await step.do('test-and-deploy', async () => {
await ci.runTests();
await ci.deployIfSuccessful();
});
}
}
```
#### 3단계: 플랫폼 관리형 파이프라인과 테넌트 동적 워크플로우(Dynamic Workflows) 결합
플랫폼 엔지니어는 보안 표준과 로깅이 강제된 '기본 워크플로우'를 공유하고, 커스텀 요구사항이 있는 고객사에게는 자신의 저장소 내부에 개별 워크플로우 정의서를 둘 수 있게 만듭니다. Dynamic Workflows 기능을 활용하면 동일한 네임스페이스 내에서 플랫폼 통합 CI와 사용자 맞춤형 CI를 충돌 없이 병렬 실행할 수 있습니다.
---
### 결론: 내일 출근해서 당장 시작해야 할 3가지 실무 지침
과거에는 수백만 개의 사용자 저장소를 위한 CI/CD 시스템을 구축하려면 전담 DevOps 팀과 수십 대의 K8s 클러스터 관리가 필수적이었습니다. 하지만 Cloudflare Artifacts와 CI SDK, 그리고 Workflows의 조합은 "CI/CD 파이프라인 또한 서버리스 코드 한 줄로 추상화되는 시대"가 도래했음을 증명합니다.
내일 출근하는 데브옵스 및 백엔드 엔지니어라면 다음 3가지를 즉시 검토해 보세요.
1. **중앙 빌드 인프라의 대기시간 지표 측정**: 전체 CI 소요 시간 중 실제 빌드 시간과 Pod 스케줄링/Git Clone 대기시간의 비율을 분리 측정해 보세요.
2. **테넌트 코드가 실행되는 격리 경계 재검토**: 사용자 지정 코드를 빌드하는 환경이 멀티테넌트 Zero-Trust 격리를 만족하는지 점검하세요.
3. **AI 셀프힐링 파이프라인 도입 시 안전장치 마련**: 자동 교정 AI 커밋이 트리거 재귀 루프를 일으키지 않도록 재귀 깊이 제한 스토퍼를 설계하세요.
아래는 내일 당장 복사해서 사용할 수 있는 엣지 CI/CD 아키텍처 점검 체크리스트와 Wrangler 환경 설정, 그리고 파이프라인 내 AI 셀프힐링 안전 프롬프트 템플릿입니다.
* **참고 원문**: [Cloudflare Blog](https://blog.cloudflare.com/ci-workflows/)
```markdown
===================================================================
[엣지 CI/CD 파이프라인 아키텍처 점검 체크리스트]
===================================================================
[ ] 1. 저장소 이벤트(Artifact Push)와 CI 워크플로우 간의 직접 바인딩이 구성되어 있는가?
[ ] 2. 엣지 노드 간 의존성 패키지 캐시 충돌 방지를 위한 격리 키(Cache Key)가 적용되었는가?
[ ] 3. 플랫폼 통합 CI 규격과 고객 커스텀 Dynamic Workflow 간의 격리 권한이 설정되었는가?
[ ] 4. AI 리뷰/자가 치유 에이전트의 재귀 호출을 막는 킬 스위치(Depth Limiter)가 있는가?
[ ] 5. 파이프라인 실패 시 이전 정상 아티팩트로의 원클릭 엣지 롤백 메커니즘이 마련되었는가?
===================================================================
[Wrangler 설정 예시: wrangler.jsonc]
===================================================================
{
"name": "edge-ci-pipeline-worker",
"main": "src/index.ts",
"compatibility_date": "2026-08-01",
"workflows": [
{
"name": "tenant-ci-workflow",
"binding": "CI_WORKFLOW",
"class_name": "TenantCIPipeline"
}
],
"events": {
"artifact_push": [
{
"workflow": "tenant-ci-workflow",
"filter": "event.action == 'push'"
}
]
}
}
===================================================================
[AI 셀프힐링 에이전트 제어 프롬프트 템플릿]
===================================================================
[역할 정의]
너는 엣지 CI/CD 파이프라인 내부에서 빌드 에러를 진단하고 최소한의 코드 수정본을 제안하는 자가 치유(Self-Healing) AI 엔지니어다.
[요청 사항]
1. 아래 제공된 [CI 실패 로그]와 [소스 코드 디렉토리]를 분석하여 실패 원인을 단 3줄 이내로 요약하라.
2. 실패를 해결하기 위한 수정 코드Diff만 정확히 출력하라. 설명 텍스트는 포함하지 마라.
3. 안전 제약사항:
- 기존 패키지 의존성을 메이저 버전업하지 마라.
- 빌드 환경설정 파일(wrangler.jsonc, tsconfig.json)은 절대로 수정하지 마라.
- 이 수정 작업은 최대 1회의 교정 기회만 부여되며, 주석에 [AI-SELF-HEALED] 태그를 반드시 명시하라.
[CI 실패 로그]
{{BUILD_ERROR_LOGS}}
[관련 코드 파일]
{{FAILING_CODE_FILE}}
```
최신 IT & Mind 리포트 더보기
- 개발 생산성 측정하려다 팀 분위기 망친 이유
- 피드백이 두려워 코드를 더 부풀리는 뇌의 비극
- 200 OK에 속아 에이전트 트레이싱 구축한 이유
- 동료 피드백 하나로 팀 내 내 영향력을 3배 올리는 법
- 내 눈엔 완벽한 설계가 남에겐 지옥인 이유
- 새 기술 도입할 때 팀원 설득에 실패하는 진짜 이유
- 배포를 앞두고 갑자기 프레임워크를 바꾸는 뇌의 방어기제
- 수동 대시보드 버리고 엣지 비용 API로 갈아탄 이유
- 새벽 3시 알람에 울던 팀이 장애를 성과로 바꾼 비결
- 간단한 문제를 거대하게 부풀리는 뇌의 착각
- 단순 TTS 버리고 제어형 오디오 모델로 갈아탄 이유
- 일 잘하는 개발자는 코드 대신 팀장을 움직인다
- 완벽한 코드를 짜고도 스스로 기술 부채를 만드는 이유
- 단방향 HTTP 버리고 엣지 gRPC로 갈아탄 이유
- 개발 불확실성 90% 줄이는 테크니컬 스파이크의 비밀
- 측정하려 들수록 생산성이 망가지는 이유
- 인간용 클라우드 버리고 에이전트 전용 아키텍처 구축한 이유
- 매번 일정 넘기던 개발자가 팀의 신뢰를 싹쓸이한 비결
- 장애 상황에서 똑똑한 개발자가 바보가 되는 이유
댓글 0