Cloudflare가 2026년 4월 15일 Project Think를 공개했습니다.

이 발표는 단순히 “Cloudflare도 AI 에이전트 기능을 냈다”로 보면 작게 보입니다.
핵심은 더 큽니다.

Cloudflare는 에이전트를 로컬 앱이나 챗봇이 아니라 서버리스 인프라 위에서 오래 살아 있는 실행 단위로 보고 있습니다.

지금까지 많은 AI 에이전트는 이런 모습이었습니다.

  • 노트북에서 실행된다
  • 터미널 세션이 끝나면 멈춘다
  • 대화 기록이 길어지면 흐려진다
  • 작업 중 실패하면 사람이 다시 이어야 한다
  • 파일 실행과 브라우저 실행을 직접 격리해야 한다

Project Think는 이 문제를 Cloudflare Workers, Durable Objects, SQLite, sandboxed execution 같은 인프라 개념으로 풀려는 시도입니다.

바로 보기

무엇이 공개됐나

Cloudflare 발표 기준 Project Think는 Agents SDK를 위한 새 primitives 묶음입니다.

주요 항목은 다음과 같습니다.

  • durable execution with fibers
  • sub-agents
  • persistent sessions
  • sandboxed code execution
  • execution ladder
  • self-authored extensions

이름은 복잡하지만 방향은 간단합니다.

에이전트가 한 번 답하고 끝나는 게 아니라, 작업을 저장하고, 중간에 멈춰도 이어가고, 필요한 하위 에이전트에게 일을 나누고, 코드를 격리된 환경에서 실행하게 만드는 것입니다.

로컬 코딩 에이전트와 무엇이 다른가

Claude Code, Codex CLI, Gemini CLI 같은 도구는 개발자에게 이미 익숙해지고 있습니다.
이 도구들은 코드베이스를 읽고, 파일을 고치고, 명령을 실행하고, 테스트를 돌립니다.

하지만 기본 출발점은 여전히 개인 작업 환경입니다.

  • 내 터미널
  • 내 저장소
  • 내 승인
  • 내 세션
  • 내 컴퓨터 상태

Cloudflare가 말하는 다음 단계는 조금 다릅니다.

에이전트가 인터넷 위에 주소를 갖고, 필요할 때 깨어나고, 각자 상태를 갖고, 여러 사용자나 이벤트를 처리하는 구조입니다.

예를 들어 이런 작업을 생각할 수 있습니다.

  • 고객 문의가 들어오면 관련 문서를 찾고 초안을 작성하는 에이전트
  • 매일 새 취약점 공지를 보고 영향받는 저장소를 표시하는 에이전트
  • 특정 GitHub issue가 달리면 재현 환경을 만들고 로그를 요약하는 에이전트
  • 블로그 초안을 만들고 검토 체크리스트를 남기는 에이전트
  • 가격 페이지 변경을 감지하고 내부 문서를 업데이트하는 에이전트

이런 작업은 노트북에서 한 번 실행하는 CLI보다, 서버에서 오래 유지되는 에이전트 쪽이 자연스럽습니다.

durable execution: 중간에 죽어도 이어가는 구조

에이전트가 실무 도구가 되려면 실패를 전제로 설계해야 합니다.

네트워크가 끊길 수 있고, 외부 API가 느릴 수 있고, 모델 호출이 길어질 수 있고, 사람이 중간에 다시 확인해야 할 수도 있습니다.

Project Think의 durable execution은 이런 긴 작업을 염두에 둔 기능입니다.
Cloudflare 발표는 checkpointing, crash recovery, automatic keepalive를 언급합니다.

즉 에이전트가 단일 요청 안에서 모든 것을 끝내는 구조가 아니라, 작업 상태를 남기고 이어가는 쪽입니다.

이건 “AI가 똑똑하다”보다 “운영 가능한가”에 가까운 문제입니다.

sub-agent: 한 에이전트가 모든 일을 하지 않는다

Project Think는 sub-agent도 강조합니다.

한 에이전트가 검색, 코드 실행, 리뷰, 문서화, 보안 점검을 모두 직접 하면 컨텍스트가 복잡해집니다.
하위 에이전트를 분리하면 역할과 상태를 나눌 수 있습니다.

예를 들어 소프트웨어 작업에서는 이렇게 나눌 수 있습니다.

  • research agent: 관련 문서와 issue를 찾는다
  • implementation agent: 파일을 수정한다
  • review agent: diff를 검토한다
  • test agent: 실패 로그를 정리한다
  • release agent: changelog를 만든다

Cloudflare 문서 기준 Think는 top-level agent로도, sub-agent로도 쓸 수 있고, parent agent가 agent tool을 통해 child Think instance를 실행하는 구조를 제공합니다.

여기서 중요한 점은 저장소와 실행 문맥을 분리할 수 있다는 것입니다.
잘못 만든 에이전트가 모든 권한과 모든 상태를 한 번에 갖는 구조보다 낫습니다.

persistent sessions: 대화 기록이 평면 목록이면 부족하다

많은 챗봇은 대화 기록을 긴 배열처럼 다룹니다.

하지만 오래 일하는 에이전트는 그렇게 단순하지 않습니다.

  • 작업을 중간에 갈라서 비교해야 합니다.
  • 이전 접근을 버리고 다른 방향으로 fork해야 합니다.
  • 긴 기록을 압축해야 합니다.
  • 특정 결정의 근거를 다시 찾아야 합니다.

Cloudflare 발표는 persistent session을 tree-structured messages, forking, compaction, full-text search 같은 기능으로 설명합니다.

이건 코딩 에이전트에서 이미 체감되는 문제입니다.
긴 작업에서는 “아까 왜 이 파일을 바꿨지”를 다시 찾을 수 있어야 합니다.

sandboxed code execution: 에이전트 실행의 핵심 안전장치

에이전트가 코드를 직접 실행할 수 있으면 생산성이 올라갑니다.
동시에 위험도 커집니다.

Cloudflare Think 문서는 LLM이 JavaScript를 sandboxed Worker 안에서 작성하고 실행할 수 있는 code execution tool을 설명합니다.

이 방향은 중요합니다.

AI 에이전트를 실제 서비스에 넣으려면 “모델이 악의적이지 않다”에 기대면 안 됩니다.
구조적으로 격리해야 합니다.

  • 파일 접근 범위
  • 네트워크 접근 범위
  • 실행 시간
  • 외부 패키지 사용
  • 민감한 환경 변수 접근
  • 사용자별 데이터 분리

이런 것이 인프라 레벨에서 정리되어야 서비스가 됩니다.

작은 팀이 바로 써야 하나

Project Think는 흥미롭지만, 모든 작은 팀이 바로 붙잡아야 할 도구는 아닙니다.

현재 Cloudflare 발표 기준 preview입니다. API가 바뀔 수 있다고 명시되어 있습니다.

따라서 추천 순서는 이렇습니다.

  1. 단순 질의응답이면 기존 챗봇이나 API 호출로 충분합니다.
  2. 내부 도구 자동화라면 먼저 로컬 에이전트와 스크립트로 검증합니다.
  3. 작업이 길고 상태가 필요해지면 서버형 에이전트를 검토합니다.
  4. 여러 사용자에게 각자 에이전트 상태가 필요하면 Durable Objects 같은 actor 모델이 의미가 있습니다.
  5. 외부 코드를 실행해야 한다면 sandbox 설계를 먼저 봐야 합니다.

즉 Project Think는 입문용 챗봇 도구라기보다, 에이전트를 제품 기능으로 넣으려는 개발자에게 더 맞습니다.

왜 Cloudflare다운 접근인가

Cloudflare는 Workers와 Durable Objects를 이미 갖고 있습니다.

이 조합은 에이전트와 잘 맞습니다.

  • 요청이 없을 때는 비용을 줄인다
  • 필요할 때 빠르게 깨어난다
  • 각 에이전트가 자기 상태를 가진다
  • 전 세계 edge에서 실행한다
  • 웹 이벤트와 쉽게 붙는다

에이전트를 “항상 켜 둔 서버 프로세스”로 보면 운영 부담이 커집니다.
반대로 “이벤트가 오면 깨어나는 주소 있는 객체”로 보면 서버리스와 잘 맞습니다.

Project Think는 이 해석을 노골적으로 밀고 있습니다.

한 줄 결론

Cloudflare Project Think의 핵심은 에이전트 기능 목록이 아닙니다.

AI 에이전트를 로컬 도구가 아니라 상태를 가진 서버리스 실행 단위로 보겠다는 선언에 가깝습니다.
앞으로 에이전트 제품을 만들려는 팀은 모델 성능뿐 아니라 durable execution, session, sandbox, sub-agent 구조까지 같이 봐야 합니다.

같이 보면 좋은 글

출처