Agent Development Lifecycle가 Cloudflare에 도입되었습니다

엔지니어링 관리자는 지난 수십 년 동안 여러 프로그래머가 하나의 코드베이스에서 함께 작업할 수 있는 방법을 고민해 왔습니다. 이러한 노력은 1975년 RAND의 "Systems Development Lifecycle"까지 거슬러 올라가며, 오늘날에는 일반적으로 "Software Development Lifecycle"(SDLC)로 불립니다. SDLC는 다음과 같은 단계를 정의합니다.

• 계획
• 설계
• 구현
• 테스트
• 배포
• 유지 관리
• 폐기

AI는 이전까지 가장 느리고 비용이 많이 들던 단계였던 구현을 가장 빠르고 비용 효율적인 단계로 바꾸었습니다. 그 결과, SDLC의 나머지 단계를 담당하는 사람들에게 부담이 집중되고 있습니다. 수천 건의 풀 리퀘스트와 이슈에 시달리는 오픈 소스 유지 관리자부터, 소프트웨어 배포 속도가 기하급수적으로 빨라지는 상황에서 운영 환경의 장애를 막기 위해 고군분투하는 프로덕션 엔지니어까지 모두가 영향을 받고 있습니다.

우리 모두는 품질이 낮은 결과물로부터 시스템과 고객, 그리고 우리 자신을 지키기 위해 노력하고 있습니다.

역설적이게도, 그 해답은 에이전트가 더 많은 일을 할 수 있도록 하는 것입니다. 생각해 보면 당연한 일입니다. 팀의 엔지니어에게 코드를 작성하게 한 뒤, 검증은 다른 사람이 하고, 병합도 다른 사람이 하고, 배포도 다른 사람이 하고, 운영 환경의 장애 대응도 다른 사람이 맡고, 들어오는 버그도 또 다른 사람이 분류하도록 하지는 않을 것입니다. 하지만 지금 대부분의 기업은 에이전트를 그렇게 활용하고 있습니다. 모델의 성능은 크게 향상되었고, 에이전트는 더 긴 시간에 걸쳐 훨씬 더 큰 작업을 수행할 수 있게 되었습니다. 그럼에도 아직 SDLC 전반에 걸쳐 균형 있게 활용되지는 못하고 있습니다.

Cloudflare는 에이전트를 고객으로 대합니다. 에이전트는 도메인을 구매하고, 임시 계정을 생성하며, Cloudflare API 전체를 사용할 수 있습니다. Cloudflare는 에이전트가 고객을 대신해 SDLC의 시작 단계뿐 아니라 전체 과정을 관리하려면 API와 다양한 도구가 필요하다는 점을 잘 알고 있습니다.

그래서 오늘 Cloudflare는 에이전트가 단순히 코드를 생성하는 것을 넘어 SDLC의 더 많은 단계를 수행할 수 있도록 지원하는 새로운 도구들을 소개합니다. 또한 Cloudflare가 이 문제를 직접 해결하는 과정에서 구축하고 얻은 경험도 함께 공유합니다.

• @cloudflare/ci — 수백만 개의 저장소에서 CI/CD를 실행할 수 있는 새로운 방식입니다. Cloudflare Workflows를 기반으로 자체적으로 문제를 복구하고, 더 복잡한 작업을 수행할 에이전트를 생성할 수 있습니다.
• 로컬 개발 환경의 OpenTelemetry 트레이스 — Wrangler와 Cloudflare Vite 플러그인에 내장되어, 에이전트가 운영 환경에서와 동일한 수준의 가시성을 로컬 개발 환경에서도 확보할 수 있도록 지원합니다.
• Cloudflare Agents 및 Agent Traces 소개 — OpenTelemetry 트레이스를 중심으로 에이전트를 관찰하고, 유지 관리하며, 개선할 수 있는 새로운 환경입니다.
• Cloudflare가 AI를 활용해 엔지니어링 표준을 적용하는 방법 — Cloudflare의 모든 제품과 시스템 저장소 및 사양에서 모범 사례를 적용해 온 실제 경험을 공유합니다.
• Astro의 GitHub 이슈를 0건으로 만든 소프트웨어 팩토리 구축 사례 — 대규모로 성장하는 오픈 소스 프로젝트에서 이슈를 자동으로 분류하고, 재현하고, 검증하고, 수정하는 시스템을 구축한 실제 경험을 소개합니다.

하지만 여기에는 더 큰 변화가 있습니다. 현재의 SDLC는 아무리 뛰어난 자동화를 적용하더라도, 에이전트가 작성할 수 있는 코드의 양과 소프트웨어 팀이 경쟁력을 유지하기 위해 요구되는 개발 속도를 감당하기에는 한계가 있습니다. Cloudflare는 이제 SDLC를 ADLC(Agent Development Lifecycle)로 대체해야 할 시점이라고 생각합니다.

SDLC는 소프트웨어 팀을 위한 것이라면, ADLC는 소프트웨어 팩토리를 위한 것입니다.

지금 모두가 이야기하는 것은 소프트웨어 팩토리입니다. 즉, 입력을 받아 소프트웨어를 자율적으로 구축하고, 개선하고, 배포하고, 관리하는 에이전트 기반 시스템입니다. 운영 환경에서 발생한 오류, 고객이 보고한 버그, 새로운 기능에 대한 아이디어 등 어떤 입력이든 받아 이를 전적으로 에이전트에 맡기는 것입니다.

하지만 에이전트를 사용하더라도 대부분의 소프트웨어 프로젝트는 여전히 사람이 개입하는 단계에 제약을 받습니다. 사람이 에이전트에 프롬프트를 입력하고, 계속 작업하도록 지시하며, 코드 리뷰 피드백을 반영하라고 알려주고, 여러 에이전트를 지속적으로 관리하며 작업을 지시합니다. 대부분의 소프트웨어 팀에서는 여전히 사람이 SDLC의 각 단계를 관리하고 있으며, 달라진 점은 각 단계의 작업을 에이전트에게 위임한다는 것뿐입니다.

소프트웨어 팩토리가 지향하는 비전은 다음과 같습니다. 소프트웨어 개발 전 과정을 하나의 팩토리로 다시 설계한다면 어떨까? 사람의 시간을 진정으로 사람의 창의성, 안목, 판단력이 필요한 일에 더 많이 사용할 수는 없을까? 그렇게 된다면 우리는 설계에 더 많은 시간을 쓰고, 고객과 더 많이 대화하며, 더 큰 꿈을 꾸는 데 집중할 수 있을 것입니다.

소프트웨어 팩토리도 SDLC의 동일한 단계를 관리해야 하지만, 이를 뒷받침하는 플랫폼에는 훨씬 더 많은 것이 요구됩니다. 에이전트에게 모든 것을 맡기는 순간, 기존에는 사람이 수행하던 모든 수작업은 다음과 같은 특성을 갖추도록 바뀌어야 하기 때문입니다.

• 프로그래밍 방식 — 사람에게도 ”ClickOps”는 좋은 방식이 아니었지만, 에이전트에게는 애초에 사용할 수 없는 방식입니다. 모든 작업은 에이전트가 호출하고, 디버깅하고, 신뢰할 수 있는 API를 통해 수행되어야 합니다.
• 수평적으로 확장 가능 — 사람이 화면을 보며 개발하거나 스테이징 서버를 직접 운영하던 시절에는 프리뷰 배포가 있으면 좋은 기능 정도였습니다. 하지만 에이전트가 작업하려면 모든 에이전트가 운영 환경과 동일한 자체 프리뷰 환경을 가져야 합니다.
• 재현 가능 — 예를 들어 iPhone 15에서 4G 환경을 시뮬레이션하거나 특정 국가의 IP에서만 재현되는 버그가 있다면 어떻게 할까요? 기존의 단위 테스트나 통합 테스트만으로는 이런 문제를 해결할 수 없습니다.
• 실시간, 푸시 기반 — 사람이 적절한 대시보드를 확인해야만 문제를 알 수 있는 방식은 원래도 효율적이지 않았지만, 에이전트 환경에서는 전혀 작동하지 않습니다. 작업이 필요할 때 에이전트를 즉시 실행시키는 이벤트 기반 구조가 필요합니다.
• 원자성 — 모든 변경 사항은 다른 기능에 영향을 주지 않으면서 독립적으로 테스트, 배포, 관찰, 롤백할 수 있어야 합니다.
• 권한 제어 가능 — 실제로는 바람직하지 않다는 것을 알면서도, 지금은 몇몇 신뢰할 수 있는 엔지니어에게 운영 환경에 SSH로 접속할 수 있는 권한을 부여합니다. 하지만 에이전트에게 그런 권한을 그대로 줄 수는 없습니다. 그렇다고 필요한 경우 권한을 상승시킬 수 있는 방법이 없다면, 에이전트는 자신의 역할을 수행할 수 없습니다.
• 자기 개선 — 사람은 경험을 통해 성장합니다. 첫 릴리스나 첫 장애 대응에서는 느리고 다른 사람을 따라 배우지만, 시간이 지나면서 더 빠르고 능숙해집니다. 에이전트 역시 경험을 통해 학습하고 개선할 수 있는 방법이 필요합니다.

실제 운영 환경에서 소프트웨어 팩토리를 안전하게 활용하려면 새로운 접근 방식이 필요합니다. 소프트웨어 팩토리는 자율주행차와 같은 다른 자율 시스템과 동일한 과제에 직면해 있습니다. 성공률 80% 수준에서 멈추는 것이 아니라, 99%를 훨씬 넘어서는 신뢰성을 달성해야 하는 과제입니다.

에이전트에게 SDLC를 맡기려면, 사람을 위해 설계된 자동차를 그대로 줄 수는 없습니다

자율주행차에는 일반 자동차에는 없는 다양한 센서와 기술이 탑재되어 있습니다. LiDAR 센서, 카메라, 추론을 수행하기 위한 강력한 컴퓨팅 성능, 그리고 필요할 경우 원격으로 개입할 수 있는 중앙 제어 시스템과의 연결 기능이 그것입니다.

자율주행차가 사람만큼 운전을 80% 정도만 잘하면 된다면, 아마 이 모든 기술은 필요하지 않을 것입니다. 자율주행 기술은 이미 10년 전부터 사람 수준의 약 80%에 도달했습니다. 하지만 그것이 목표는 아닙니다. 목표는 사람보다 훨씬 뛰어나고 더 안전하게 운전하는 것입니다. 시속 60마일로 101번 고속도로를 달리며 안심하고 잠들 수 있으려면, 우리는 기계가 사람보다 더 안전할 것이라고 기대합니다. 그래서 자율주행차에는 자율주행만을 위해 설계된 기술이 탑재됩니다. 이러한 기술이 신뢰를 구축하고, 미리 모두 설계할 수 없는 다양한 예외 상황까지 처리할 수 있도록 해 주기 때문입니다.

소프트웨어를 자율적으로 개발하는 경우도 마찬가지입니다. 한번 생각해 보세요. 왜 아직도 에이전트가 생성한 PR을 자동으로 승인하고 운영 환경에 직접 병합하도록 맡기지 못할까요? 여러분이 구축하는 서비스의 중요도가 높을수록, 그 이유는 훨씬 더 많을 것입니다.

이 과정에서 치명적인 문제가 발생할 수 있는 수많은 가능성과 고객에게 올바른 결과를 제공하기 위해 반드시 필요한 요소들을 하나씩 살펴보면, 그 복잡성은 매우 큽니다. 이러한 과정은 GitHub Actions의 YAML 파일에 정의된 선형적인 단계로는 표현할 수 없으며, 기존의 자동화 테스트만 실행하는 수준을 훨씬 넘어섭니다. 대시보드의 작은 변경 하나만으로도 여러 역할과 전문 분야, 조직이 함께 관여할 수 있으며, 주관적인 판단이 필요한 변경일수록 테스트하거나 에이전트에 위임하기가 가장 어렵습니다. 이러한 작업 대부분은 지금도 CI/CD 파이프라인에 포함되어 있지 않을 가능성이 큽니다. 하지만 소프트웨어 팩토리를 운영하는 에이전트에게 전권을 맡기면서도 이러한 작업이 계속 이루어지게 하려면, 앞으로는 반드시 파이프라인의 일부가 되어야 합니다.

에이전트가 전체 과정을 주도하도록 하려면, 이렇게 동적으로 이어지는 일련의 단계를 더 효과적으로 오케스트레이션할 수 있는 방법이 필요합니다. Cloudflare는 그 해답이 Workflow라고 생각합니다. 컨테이너, 에이전트, 브라우저를 생성할 수 있는 기능을 갖춘 Workflow 말입니다. 기능 플래그를 설정하고 테스트 사용자에게만 활성화하거나, 로그와 트레이스를 조사하고, 변경 사항이 점진적으로 배포되는 동안 운영 환경의 메트릭을 관찰하는 등, 안전하게 소프트웨어를 배포하는 데 필요한 모든 작업을 수행할 수 있는 Workflow가 필요합니다.

CI/CD 파이프라인도 결국 하나의 Workflow입니다. 하지만 Workflow는 CI/CD 파이프라인보다 훨씬 더 많은 일을 수행할 수 있습니다.

Cloudflare Workflows를 사용하면 여러 단계를 하나로 연결하고, 실패한 작업을 자동으로 재시도하며, 상태를 몇 분, 몇 시간, 심지어 몇 주 동안 유지할 수 있습니다. Cloudflare Workflows는 복잡하고 동적인 비즈니스 프로세스를 논리적이고 이해하기 쉬운 프로그램으로 구현하도록 설계되었습니다. 이 블로그에서는 Workflows와 Artifacts를 함께 사용하면 CI/CD 파이프라인을 정의하고 실행하는 방식이 근본적으로 어떻게 더 단순해지는지 설명합니다. 예를 들면 다음과 같습니다.

import { CIWorkflow } from `@cloudflare/ci`

const deps: CiRunnerResult = await ci.runner({
      name: 'install',
      command: 'bun install --frozen-lockfile',
      cache: { inputs: ['package.json', 'bun.lock'] },
    });

    await Promise.all([
      deps.runner({ name: 'lint', command: 'bun run lint' }),
      deps.runner({ name: 'test', command: 'bun run test' }),
      deps.runner({ name: 'typecheck', command: 'bun run typecheck' }),
      deps.runner({ name: 'build', command: 'bun run build' }),
    ]);

    await deps.runner({
      name: 'deploy',
      command: 'bun wrangler deploy',
      cloudflareCredentials: {
        accountId: this.env.CLOUDFLARE_DEPLOY_ACCOUNT_ID,
      },
    });

하지만 Workflows는 단순히 선형적인 단계들을 순차적으로 실행하는 데 그치지 않습니다. 동적으로 정의할 수 있으며, 에이전트나 다른 Workflow를 생성할 수도 있습니다. 아래 예시는 지난 하루 동안 생성된 새로운 데이터를 검토하는 Workflow입니다. 이 Workflow는 언제, 어떤 방식으로 에이전트에 프롬프트를 전달할지 완전히 제어할 수 있으며, 각 단계 사이에서 필요한 컨텍스트도 전달할 수 있습니다. 

import { WorkflowEntrypoint, type WorkflowEvent, type WorkflowStep } from 'cloudflare:workers';
import { init } from '@flue/runtime';
import { Reviewer } from './agents/reviewer.ts';
import { collectFindings } from './shared/nightly.ts';

type Params = { date: string };

export class NightlyReview extends WorkflowEntrypoint {
  async run(event: WorkflowEvent<Params>, step: WorkflowStep) {
    const findings = await step.do('collect findings', () => collectFindings(event.payload.date));

    const agent = init(Reviewer, { id: `nightly-${event.payload.date}` });

    const receipt = await step.do('dispatch review', () =>
      agent.dispatch(`Review these findings:\n${findings}`),
    );

    const review = await step.do('read review', async () => {
      const reply = await agent.read(receipt);
      return { text: reply.text, data: reply.data };
    });

    // ...
  }
}

이러한 패턴을 이해하고 Cloudflare처럼 "Workflow 중심"의 사고방식을 갖게 되면, 자연스럽게 이런 질문을 하게 됩니다. 'Workflow에 또 어떤 일을 맡길 수 있을까?' '사람이 병목이 되는 어떤 작업을 Workflow와 Flue 에이전트의 조합에 위임할 수 있을까?'

Cloudflare 스택으로 구현하는 전체 ADLC

Workflows가 복잡한 작업을 오케스트레이션하고, Artifacts가 코드의 스토리지 계층 역할을 하므로, SDLC의 각 단계를 살펴보면 에이전트가 소프트웨어를 구축하고, 배포하고, 유지 관리하는 전 과정을 주도하는 데 필요한 모든 요소를 Cloudflare에서 사용할 수 있습니다.

소프트웨어 팩토리를 구축하기 위한 기반 요소

지금은 가장 앞서가는 개발자들이 미래의 소프트웨어 팩토리를 구축하고 있습니다. 하지만 시간이 지나면 에이전트와 AI가 그랬던 것처럼, 소프트웨어 팩토리도 소프트웨어를 개발하는 일반적인 방식이 될 것입니다. 다만 현재로서는 대부분의 사람과 조직이 아직 그 단계에 이르지는 못했습니다.

우리는 이를 바꾸고자 합니다.

이를 위해 우리는 다음과 같은 질문을 던졌습니다. 이러한 패러다임의 전환을 인터넷의 모든 사용자가 누릴 수 있도록 어떻게 더 단순하고 쉽게 만들 수 있을까? 그리고 가장 작은 스타트업부터 세계 최대 규모의 플랫폼까지 모두가 활용할 수 있는 기반 요소는 무엇일까?

이제 그 기반 요소들이 갖춰졌다고 생각합니다. 물론 이들을 더욱 긴밀하게 연결하고, Cloudflare 자체의 소프트웨어 팩토리를 계속 구축하면서 경험을 쌓아야 할 부분은 남아 있습니다. 하지만 지금 이 순간에도 여러분은 Cloudflare에서 기계를 만드는 기계를 구축할 준비를 시작할 수 있습니다. @cloudflare/ci로 시작해 에이전트를 구축하고, SDLC의 얼마나 많은 부분을 자율화할 수 있는지 직접 확인해 보세요.