cloudflare·2026년 8월 6일·4분 읽기큐레이션 요약

Kitesurf 소개: Cloudflare Workers의 V8 격리 환경에서 실행되는 에이전트 우선 브라우저

Cloudflare는 인간이 아닌 AI 에이전트에 최적화된 브라우저가 필요하다고 판단해, Workers 위에서 동작하는 헤드리스 브라우저 **Kitesurf**를 개발했다. Chromium이 제공하는 탭·확장 기능·정밀한 시각 렌더링보다 토큰 수, 확장성, 성능, 비용, 구조화된 콘텐츠 추출을 우선하며, 일반적인 에이전트 작업에서 CPU와 메모리 사용량을 크게 줄이는 것이 목표다. Kitesurf는 Browser Run에서 베타 서비스로 무료 제공된다. ## AI 에이전트에 기존 브라우저가 과한 이유 - Chromium 같은 브라우저 엔진은 인간 사용자를 중심으로 설계됐다. - AI 에이전트에는 다음 기능의 가치가 낮다. - 탭, 테마, 브라우저 확장 기능 - 여러 기기 간 동기화 - 픽셀 단위로 정확한 렌더링 - 부드러운 60fps 스크롤 - 반대로 에이전트에는 다음 요소가 중요하다. - 적은 토큰 수와 효율적인 컨텍스트 사용 - HTML 등 구조화된 콘텐츠 - 높은 처리량과 확장성 - 낮은 CPU·메모리 사용량과 비용 - AI 브라우저의 위협 모델도 인간용 브라우저와 다르다. - 임의의 웹사이트를 방문하는 에이전트는 모든 페이지를 신뢰할 수 없는 입력으로 다뤄야 한다. - 프롬프트 인젝션과 도구 사용 안전성이 핵심 보안 문제가 된다. ## Cloudflare 플랫폼이 가능하게 한 전환점 - Kitesurf는 Cloudflare Workers 위에서 전체적으로 실행된다. - 다음 기술 발전이 복잡한 브라우저 구현을 가능하게 했다. - Workers에서의 성숙한 WebAssembly 지원 - 동적 워커 - SQLite 기반 Durable Objects - 워커 간 RPC - 서비스 바인딩 - 향상된 Node.js 호환성 - 더 높은 실행 한도 - AI 에이전트용 브라우저 자동화 수요가 커지면서, 기존 Chromium 인스턴스를 에이전트마다 제공하는 방식의 비용 문제가 부각됐다. - Kitesurf는 이러한 환경에서 더 작고 저렴한 브라우저 실행 모델을 제공하려는 시도다. ## 초기 구현과 AI 활용 - 출발점은 Rust로 작성된 AI 자동화용 헤드리스 엔진 **obscura**였다. - Cloudflare 팀은 AI 에이전트의 도움을 받아 이를 Workers로 포팅했다. - 초기 결과는 불완전했지만, 명확한 실행 계획과 성공 조건을 제공하자 AI가 반복적으로 구현·검증하며 작동하는 프로토타입을 만들 수 있었다. - 이후 프로토타입을 기반으로 실제 대규모 서비스에 필요한 구조와 품질 기준을 마련했다. ## 테스트를 중심으로 한 개발 방식 - 복잡한 브라우저를 AI의 도움으로 빠르게 개발하려면, 구현 속도뿐 아니라 결과 품질을 통제해야 했다. - 이를 위해 가능한 많은 테스트를 성공 기준으로 제공했다. - **Web Platform Tests(WPT)**를 활용해 다음을 검증했다. - 웹 표준에 대한 기능 준수 여부 - 각 브라우저 기능의 구현 상태 - AI 에이전트가 작업을 완료했는지 판단할 수 있는 명확한 기준 - WPT만으로는 실제 웹사이트에서의 동작을 충분히 검증할 수 없기 때문에 추가 테스트도 도입했다. - Chromium과 Kitesurf 양쪽에서 실제 사이트를 대상으로 Puppeteer 통합 테스트 실행 - 여러 단계의 사용자 작업과 assertion 비교 - 각 단계의 렌더링 결과를 비교하는 시각적 회귀 테스트 - 예상하지 못한 렌더링 차이를 자동으로 표시 - AI 에이전트는 기능 구현을 담당하고, 사람은 아키텍처 설계와 구현 방식 검토에 집중하는 방식이다. ## Rust와 WebAssembly 선택 - Cloudflare는 C, C++, Rust 코드를 WebAssembly로 컴파일해 Workers에서 실행할 수 있다. - Emscripten을 사용하면 많은 의존성과 모의 계층이 추가되어 결과 바이너리가 커지고 실행이 느려질 수 있다. - Kitesurf는 가능한 한 네이티브 Rust로 구현하고 `wasm-bindgen`을 통해 WebAssembly로 직접 컴파일했다. - 이를 통해 불필요한 에뮬레이션 계층을 피하고, 성능과 안정성을 높였다. ## 예외 처리와 장애 격리 - 웹페이지는 잘못된 HTML, 예상 밖의 입력, 악의적인 콘텐츠를 포함할 수 있으므로 브라우저는 일부 기능이 실패해도 세션 전체를 중단해서는 안 된다. - Kitesurf의 원칙은 다음과 같다. - 오류가 발생하면 죽은 세션 대신 빈 프레임이나 누락된 요소로 처리 - 모든 경계에서 예외를 포착 - 안전하고 비어 있는 기본값 사용 - 문제를 진단할 수 있을 만큼 충분한 로그 기록 - 목표는 페이지 일부가 손상되더라도 브라우저 요청 자체는 계속 유지하는 것이다. ## 페이지와 컴포넌트의 격리 - AI 에이전트는 작업에 따라 임의의 출처에서 코드를 실행하거나 페이지를 방문할 수 있다. - 따라서 모든 페이지 로드를 신뢰할 수 없는 입력으로 취급하고, 모든 세션을 새로 시작한다. - 각 컴포넌트는 필요한 리소스에만 접근하도록 제한한다. - Workers의 격리 모델이 기본적인 보안 경계를 제공하지만, 그것만으로 충분하지 않다. - 애플리케이션 수준에서도 컴포넌트별 접근 권한을 정의해야 한다. - 한 페이지의 데이터나 리소스가 다른 페이지로 유출되지 않도록 별도로 보장해야 한다. ## 가능한 한 무상태로 설계 - 상태가 많을수록 장애 발생 후 복구 비용이 커진다. - 무상태 컴포넌트는 다음 장점을 가진다. - 실패하면 새 인스턴스를 만들고 요청을 다시 재생하면 됨 - 필요할 때 병렬로 대량 실행 가능 - 멈춘 인스턴스를 즉시 폐기 가능 - 트래픽이 급증하는 자동화 작업에 맞춰 수요 기반으로 확장 가능 - 사용한 만큼만 비용을 지불하고 작업 종료 후 리소스를 제거 가능 - 따라서 상태가 꼭 필요하지 않은 컴포넌트는 가능한 한 무상태로 구현한다. ## 실용적인 결론 AI 브라우저는 인간용 브라우저를 그대로 축소하는 것이 아니라, 구조화된 데이터 처리·낮은 비용·높은 확장성·강한 격리를 중심으로 다시 설계해야 한다. 브라우저 자동화 서비스를 구축할 때는 표준 테스트뿐 아니라 실제 사이트 통합 테스트와 시각적 회귀 테스트를 병행하고, Rust/WebAssembly·무상태 설계·방어적인 예외 처리를 활용하는 것이 효과적이다.

원문 읽기(새 탭에서 열림)

AI 에이전트Cloudflare WorkersRustwebassembly+4

cloudflare·2026년 8월 6일·4분 읽기큐레이션 요약

어떤 웹사이트에든 WebMCP 인터페이스 추가하기

Cloudflare는 코드 변경 없이 사이트에 WebMCP를 활성화할 수 있는 개발자 프리뷰를 출시했다. 이를 통해 브라우저 에이전트는 사람이 페이지를 탐색하듯 추측하지 않고, 사이트가 제공하는 MCP 도구를 직접 발견하고 호출할 수 있다. Cloudflare는 HTML 응답에 브리지 스크립트를 엣지에서 주입하며, 도구 실행은 방문자의 브라우저와 기존 세션을 활용해 수행한다. ## 사람 중심 웹과 AI 에이전트의 간극 - 기존 웹은 사람이 페이지를 읽고 버튼을 클릭하며 양식을 작성한다는 전제로 설계됐다. - AI 에이전트의 방문이 늘고 있지만, 일반적으로는 크롤러가 콘텐츠를 복사해 서버로 가져가는 방식이 사용됐다. - 크롤링은 원 사이트에 트래픽과 출처를 충분히 돌려주지 못하는 문제가 있다. - WebMCP는 스크래핑 대신 사이트가 에이전트용 도구를 직접 노출하도록 해 이 문제를 해결하려 한다. - Chrome 146 실험 버전부터 `document.modelContext`를 통해 WebMCP 표면이 제공된다. ## Cloudflare WebMCP 개발자 프리뷰 - Cloudflare 대시보드에서 설정을 켜는 것만으로 WebMCP 도구를 활성화할 수 있다. - 사이트별로 도구를 직접 설계하고 연결하는 별도 구현 작업이 필요 없다. - 도구는 관련 기능을 묶은 “팩(pack)” 단위로 제공된다. - 새로운 팩이 추가되면 재배포 없이 설정에서 켤 수 있도록 확장성을 고려했다. - 이번 프리뷰에는 브라우저에서 동작하는 두 가지 팩이 포함된다. - Content Credentials 팩 - Site MCP Server 팩 ## 엣지 주입 방식과 브리지 동작 - Cloudflare는 원본 서버 앞단에서 두 가지 작업을 수행한다. - HTMLRewriter를 이용해 모든 HTML 응답에 다음과 같은 브리지 스크립트 참조를 삽입한다. ```html <script type="module" src="/.webmcp/bridge.js" data-packs="c2pa,mcp-server-client" data-mcp-url="/mcp"> </script> ``` - 삽입되는 스크립트와 태그는 동일 출처에서 제공되며, 원본 사이트 코드와 나머지 HTML은 변경하지 않는다. - `data-packs`는 활성화할 도구 팩 목록을 지정한다. - `data-mcp-url`은 사이트의 MCP 서버 주소이며, 기본값은 동일 출처의 `/mcp`다. - 브리지 스크립트는 브라우저에 `document.modelContext`가 없으면 아무 작업도 하지 않고 종료한다. - 브리지는 각 팩의 도구를 통합해 `document.modelContext.registerTool()`로 등록한다. - 정적 팩은 도구를 미리 정의하고, 동적 팩은 시작 시 MCP 서버에서 도구 목록을 조회한 뒤 등록한다. ## 브라우저에서 실행되는 MCP 도구 - 프리뷰의 모든 도구는 Cloudflare 서버로 별도 왕복하지 않고 방문자의 브라우저에서 실행된다. - Content Credentials 팩은 브라우저에서 이미지를 가져와 앞부분의 콘텐츠 출처 메타데이터를 분석한다. - Site MCP Server 팩은 방문자의 브라우저에서 사이트 MCP 엔드포인트로 직접 요청한다. - 요청에는 `credentials: "same-origin"`이 사용되므로 방문자의 기존 로그인 세션과 권한을 활용할 수 있다. - 사이트 MCP 서버가 `tools/list`로 제공한 이름, 설명, 입력 스키마를 그대로 브라우저 도구로 등록한다. - 에이전트는 기존 MCP 서버와 동일한 `Tool`, `CallToolResult` 형식을 사용하므로 별도 전용 인터페이스가 필요 없다. - 도구 호출은 JSON-RPC `tools/call` 요청으로 사이트의 `/mcp` 엔드포인트에 전달된다. ## 향후 확장 가능성 - 브리지 코드는 엣지의 Cloudflare Worker에서 제공된다. - 현재 도구는 브라우저에서만 실행되지만, 향후 Worker를 활용하는 팩도 추가될 수 있다. - 예를 들어 Workers AI를 이용한 사이트맵 요약이나 AI Search 인덱스 조회 같은 기능이 가능하다. - 따라서 WebMCP는 단순한 페이지 조작을 넘어 사이트 기능과 Cloudflare 서비스를 에이전트 도구로 연결하는 기반이 될 수 있다. ## 이미지 콘텐츠 자격 증명 확인 - Content Credentials 팩은 C2PA 메타데이터를 읽어 이미지의 출처와 편집 정보를 에이전트에게 제공한다. - `scan_images_c2pa`는 페이지의 모든 이미지를 검사해 다음과 같은 정보를 요약한다. - 전체 이미지 수와 검사 수 - C2PA 포함 여부 - 이미지 형식 - 매니페스트 개수 - 생성 도구 또는 작성자 - 서명 주체 - `inspect_image_c2pa`는 특정 이미지의 전체 매니페스트를 확인한다. - 편집 이력 - 명시된 작성자 - 서명 인증서 - 이 기능은 이미지 전체가 아니라 파일 앞부분의 소량 메타데이터만 읽는 TypeScript 기반 리더로 구현됐다. - 현재는 자격 증명을 읽고 보고하는 기능이며, 암호학적 서명 검증까지 수행하지 않는다. - 따라서 결과에는 `signatureVerified: false`가 표시되어 에이전트가 검증되지 않은 정보를 신뢰하지 않도록 한다. 사이트에 로그인 상태나 민감한 기능이 있다면 MCP 서버가 에이전트에게 어떤 도구와 권한을 노출하는지 신중하게 설계해야 한다. WebMCP는 크롤링을 대체하는 에이전트 친화적 인터페이스를 제공하지만, 현재는 개발자 프리뷰이므로 브라우저 지원과 표준 변화, 서명 검증 범위를 함께 고려해 시험적으로 도입하는 것이 적절하다.

원문 읽기(새 탭에서 열림)

모델 컨텍스트 프로토콜cloudflareworkers-aiwebmcp+2

cloudflare·2026년 8월 5일·4분 읽기큐레이션 요약

Cloudflare, 2026년 SASE 및 SSE 보고서에서 비저너리로 선정된 유일한 벤더

Cloudflare는 2026년 Gartner SASE 및 SSE 매직 쿼드런트에서 모두 비저너리로 선정된 유일한 기업이라고 발표하며, 이를 통합형 아키텍처와 고객 신뢰의 결과로 설명한다. 글은 AI 에이전트, 양자 컴퓨팅, 섀도 앱 확산에 대응하려면 기존 제품을 조합한 SASE가 아니라 민첩하고 프로그래밍 가능한 통합 보안·접속 플랫폼이 필요하다고 주장한다. Cloudflare One은 단일 글로벌 네트워크와 통합 정책 체계를 기반으로 AI 보안, 제로 트러스트, DLP, 포스트퀀텀 암호화를 하나의 플랫폼에서 제공하는 방향을 제시한다. ## SASE와 SSE 시장의 변화 - SSE는 팬데믹 시기 원격 근무 보안을 위한 “SASE의 보안 영역”으로 먼저 확산됐다. - 최근에는 사무실 복귀, AI 에이전트, 섀도 앱, 포스트퀀텀 위협으로 인해 네트워크 연결과 보안을 함께 관리하는 SASE의 중요성이 커지고 있다. - 기업은 과거 아키텍처에 묶인 제품보다 변화 속도에 맞춰 정책과 보호 기능을 확장할 수 있는 플랫폼을 필요로 한다. ## 기존 SASE의 구조적 한계 - **분산된 아키텍처** - 인수합병으로 여러 제품을 결합한 플랫폼은 배포와 정책 관리가 복잡하다. - 사용 사례마다 서로 다른 제품과 엔진을 운영해야 해 보안 공백과 구현 지연이 발생한다. - Cloudflare는 하나의 글로벌 네트워크로 사용자, AI 에이전트, 인프라를 연결하고 보호하는 “connectivity cloud” 접근을 내세운다. - **관리되지 않는 AI 에이전트** - 기존 보안 제품은 사람의 생성형 AI 프롬프트에 집중했지만, AI 에이전트와 MCP 서버의 확산은 충분히 통제하지 못했다. - Cloudflare는 사람과 AI 에이전트를 함께 가시화하고 MCP 서버 사용을 정책으로 관리한다고 설명한다. - AI Gateway와 연동해 사용자·팀·애플리케이션별 추론 비용을 제한할 수 있어 예기치 않은 AI 사용료를 줄일 수 있다. - **이론에 머문 포스트퀀텀 보안** - 포스트퀀텀 암호화를 향후 과제로만 다루는 대신, 주요 온·오프램프에 실제 적용해 “지금 수집하고 나중에 복호화”하는 공격에 대응한다고 주장한다. - 규제 산업은 장기간 보관되는 암호화 데이터를 현재 시점부터 보호해야 한다. - **복잡한 추가 과금** - 기존 업체는 고급 기능을 별도 애드온으로 판매하거나 원격 근무와 사무실 사용에 중복 과금하는 경우가 있다. - Cloudflare는 숨은 비용 없이 예측 가능한 통합 번들을 제공하는 것을 차별점으로 제시한다. ## SASE를 변화시키는 네 가지 기술 압력 - **AI로 만든 내부 앱과 섀도 IT** - 직원이 IT 승인 없이 내부 도구를 빠르게 만드는 “vibe-coded” 앱이 늘어나고 있다. - SASE는 이런 앱에 제로 트러스트 접근 제어, WAF, API 보호, DLP를 자동 적용해야 한다. - AI 프롬프트와 민감 데이터도 보호하면서 개발 속도는 유지해야 한다. - **AI 에이전트 권한 통제** - 사람의 광범위한 권한을 AI 에이전트가 그대로 상속해서는 안 된다. - 에이전트 작업별로 최소 권한의 자격 증명을 발급하고, 의도와 도구 호출량을 분석해 이상 행동을 감지해야 한다. - **포스트퀀텀 민첩성** - 양자 컴퓨팅 발전에 대비해 NIST 표준이 확정되기 전부터 암호화 체계를 교체할 수 있어야 한다. - Cloudflare는 2028년까지 포스트퀀텀 인증을 포함한 완전한 양자 보안 SASE를 제공하겠다는 목표를 제시한다. - **실질적인 아키텍처 통합** - 단순히 여러 제품을 “플랫폼”으로 묶는 것만으로는 통합이 이뤄지지 않는다. - 진정한 통합에는 단일 코드베이스와 통합된 제어·데이터·인프라 플레인이 필요하다. - AI 시대에는 구성 가능성과 프로그래밍 가능성이 실제 아키텍처에 내장되어야 한다. ## Cloudflare의 통합 아키텍처 - Cloudflare는 서로 다른 보안 제품을 조합하는 대신 처음부터 단일 플랫폼으로 구축했다고 설명한다. - 모든 서비스가 글로벌 네트워크의 각 서버에서 실행되므로 특정 보안 장비 간 트래픽을 우회시키는 ‘tromboning’이 줄어든다. - 제품별 용량 계획, 분리된 정책, 복잡한 통합 작업이 필요 없어 새로운 사용 사례를 수개월이 아니라 수일 또는 수주 내 배포할 수 있다는 주장이다. - 제로 트러스트, Gateway, DLP, 신규 사무실 연결 등을 동일한 운영 체계에서 확장할 수 있다. ## AI 도입을 빠르게 보호하는 방식 - AI 보안을 별도 모듈로 추가하지 않고 기존 SASE 정책 언어에 통합한다. - 관리자는 사람의 AI 프롬프트와 에이전트의 MCP 서버 연결을 동일한 정책 체계로 관리할 수 있다. - 새로운 AI 비서나 AI 기반 업무 도구가 도입돼도 보안을 사후에 덧붙이는 대신 기존 제로 트러스트 정책을 즉시 적용할 수 있다. - 단일 아키텍처를 활용해 새로운 AI 보안 기능을 별도 제품 통합 주기 없이 빠르게 배포할 수 있다는 점을 강조한다. ## 사용하기 쉬운 SASE - 기존 SASE는 여러 검사 지점을 거치는 복잡한 트래픽 경로와 제품별 관리 방식 때문에 배포 기간이 길어지는 문제가 있었다. - Cloudflare는 서비스가 동일한 네트워크에서 일관되게 동작하도록 설계해 전문 장비 간 연결과 별도 용량 계획을 줄인다. - 새로운 애플리케이션에 제로 트러스트를 적용하거나 Gateway 트래픽에 DLP를 추가하는 작업을 설정 중심으로 처리할 수 있다고 설명한다. ## 프로그래밍 가능한 SASE - 글은 단순한 GUI 자동화나 제한적인 API를 “프로그래밍 가능성”이라고 부르는 기존 방식을 비판한다. - Cloudflare는 엣지 개발자 플랫폼과 SASE를 결합해 사용자 코드를 SASE 패브릭 안에서 직접 실행할 수 있는 구조를 지향한다. - 이를 통해 실시간 신호를 활용한 접근 결정 등 기업별 맞춤 로직을 기본 제품의 제약을 우회하지 않고 구현할 수 있다고 주장한다. 실무적으로는 SASE 제품을 평가할 때 기능 목록뿐 아니라 단일 정책 체계, AI 에이전트 권한 관리, 포스트퀀텀 전환 능력, 통합 비용 구조, 커스텀 로직 실행 가능성을 함께 확인하는 것이 중요하다.

원문 읽기(새 탭에서 열림)

제로 트러스트ai-securitysasecloudflare-one+3

cloudflare·2026년 8월 5일·5분 읽기큐레이션 요약

에이전트 액세스 모델

기업 보안은 네트워크 위치 대신 사용자 신원과 기기 상태를 기준으로 판단하는 Zero Trust로 발전했지만, 에이전트에는 기존 인간 중심 통제가 충분하지 않다. 에이전트는 짧은 작업 단위로 실행되면서도 사람보다 훨씬 빠르게 권한을 행사하고, 여러 시스템과 다른 에이전트를 연쇄 호출할 수 있기 때문이다. 글은 작업 실행 그래프 전체를 신뢰하지 않고 매 행동을 검증하는 **Agent Access Model(AAM)**을 제안하며, 핵심은 판단을 더 정교하게 만드는 것보다 에이전트의 능력 범위를 처음부터 작게 제한하는 데 있다. ## 인간 중심 보안 모델의 한계 - BeyondCorp는 요청이 내부 네트워크에서 왔는지보다 사용자 신원과 기기 상태를 기준으로 접근을 허용해야 한다고 주장했다. - 이 모델은 사람이 주체라는 전제에서 잘 작동했다. - 사람은 비교적 일정한 기기를 사용한다. - 작업 속도가 느리고 접근 요청 빈도가 제한적이다. - 로그인, 기기 상태, 세션 위험도 등을 바탕으로 개별 접근을 판단할 수 있다. - 에이전트는 하나의 서비스가 여러 작업을 처리하며, 데이터베이스·소스 저장소·로그·티켓 시스템·문서 등에 짧은 시간 안에 접근할 수 있다. - 따라서 인간에게 분기별로 검토하던 최소 권한 정책을 에이전트에게는 실시간으로 적용하고 감사 로그로 남겨야 한다. ## 에이전트의 네 가지 특성 - **자격 증명보다 작업 수명이 짧다** - 서비스 계정용 키는 장기간 유지되고 권한 범위가 넓은 경우가 많다. - 에이전트 작업은 몇 분 만에 끝날 수 있지만 토큰이 메모리, 로그, 환경 변수에 남아 재사용될 수 있다. - 자격 증명 수명은 작업 수명과 일치해야 하며, 작업 종료 시 함께 만료되어야 한다. - **사람보다 훨씬 빠르게 행동한다** - 인간 활동을 기준으로 설계한 이상 탐지, 속도 제한, 데이터 유출 방지 기능은 대응 전에 이미 대량의 데이터가 전송될 수 있다. - 데이터베이스 연결과 외부 네트워크가 동시에 있으면 읽은 정보를 즉시 외부 엔드포인트로 전송할 수 있다. - 그러므로 통제는 사후 탐지가 아니라 도구 호출과 네트워크 요청이 발생하는 지점에서 동기적으로 실행되어야 한다. - **프롬프트는 보안 경계가 아니다** - “운영 환경에 접근하지 말라” 같은 지시는 행동 의도를 표현할 뿐 접근을 강제하지 않는다. - 입력 데이터에 삽입된 지시로 에이전트가 조작될 수 있고, 에이전트가 스스로 안전하지 않은 행동을 선택할 수도 있다. - 실제 강제는 도구 호출을 중재하는 하네스와 패킷을 통제하는 네트워크 계층에서 수행해야 한다. - **여러 홉을 거치며 권한을 조합한다** - 한 에이전트가 도구를 호출하고, 그 도구가 다시 다른 에이전트나 API를 호출할 수 있다. - 이 과정에서 원래 요청한 사람, 작업 목적, 허용된 권한의 관계가 사라질 수 있다. - 기존 권한 모델은 단일 위임에는 대응해도 다단계·다중 사용자 위임에는 취약하다. ## 작업 실행 그래프를 기준으로 한 AAM - AAM의 출발점은 “실행 중인 작업 자체를 신뢰하지 말라”는 원칙이다. - 에이전트의 각 행동은 다음 세 가지를 기준으로 매번 인가된다. - 에이전트의 신원 - 해당 에이전트가 수행하도록 승인된 작업 - 작업 실행 그래프가 지금까지 접근한 정책상 중요한 리소스 - 한 행동이 승인되었다고 해서 다음 행동까지 자동으로 승인되지 않는다. - 그래프에 누적된 상태는 이후 사용할 수 있는 권한을 줄일 수만 있으며, 작업 중 권한을 임의로 확대하지 않는다. - Beyond Zero처럼 개별 행동 단위로 판단하는 방식과 결합할 수 있으며, AAM은 판단 엔진이 검토해야 할 권한 범위를 제한한다. ## AAM의 다섯 가지 원칙 - **짧고 작업에 결합된 자격 증명** - 작업 전용 자격 증명을 발급하고 작업 종료 시 만료시킨다. - 탈취된 토큰만으로 재사용할 수 없도록 하네스가 보유한 증명 키에 토큰을 결합한다. - **하네스와 네트워크에서의 강제** - 프롬프트는 의도를 설명하는 수단일 뿐이다. - 도구 호출은 하네스에서, 네트워크 요청은 네트워크 계층에서 정책으로 차단·허용한다. - **예외적인 인간 승인** - 모든 단계마다 사람의 승인을 요구하면 승인 피로와 형식적인 클릭이 발생한다. - 정말 중요한 의사결정에만 인간 승인을 사용해야 한다. - **증거 기반 권한 검토** - 실제 작업 활동을 분석해 작업 템플릿의 권한이 과도한지 부족한지 판단한다. - 검토 후 승인된 변경은 이후 작업에만 적용하며, 현재 실행 중인 작업의 권한을 소급해 확대하지 않는다. - **되돌릴 수 없는 신뢰 감소** - 보호 대상 이벤트가 발생하면 Trust Ratchet이 작업 실행 그래프 전체의 권한을 정책에 따라 제거한다. - 제거된 권한은 현재 작업에서 복구되지 않고, 새롭게 승인된 작업에서만 다시 부여된다. ## 참조 아키텍처와 에이전트 신원 브로커 - AAM 참조 아키텍처는 작업을 직접 통제하는 네 가지 활성 제어와, 증적을 처리하는 두 개의 지원 시스템으로 구성된다. - 지원 시스템에는 다음이 포함된다. - **Agent Activity Log**: 작업 중 발생한 활동을 기록한다. - **Grant Review Loop**: 기록된 증거를 바탕으로 향후 권한 정책을 검토한다. - **Agent Identity Broker**는 작업이 배포될 때 작업 범위가 제한된 검증 가능한 자격 증명을 발급한다. - 자격 증명은 작업 종료 시점보다 늦게 만료되지 않아야 한다. - 자격 증명에는 최소한 다음 관계가 표현된다. - 어떤 에이전트인지 - 누구를 대신하는지 - 어떤 작업을 수행하는지 - 또한 발신자 제약(sender constraint)을 적용해, 자격 증명만 탈취한 공격자가 하네스의 증명 키 없이 재사용하지 못하도록 한다. ## 실용적인 적용 방향 - 에이전트마다 장기 서비스 계정과 광범위한 정적 키를 제공하지 말고, 작업별 단기 자격 증명을 발급하는 것이 우선이다. - 프롬프트의 금지 문구에 의존하지 말고 하네스와 네트워크 계층에서 도구·데이터·외부 전송을 직접 제한해야 한다. - 모든 행동에 인간 승인을 넣기보다 고위험 작업에만 승인 절차를 적용해야 한다. - 활동 로그를 통해 권한 범위를 지속적으로 줄이되, 실행 중인 작업의 권한을 사후에 넓히지 않는 원칙을 유지해야 한다.

원문 읽기(새 탭에서 열림)

제로 트러스트access-controlaudit-loggingleast-privilege+2

cloudflare·2026년 8월 5일·4분 읽기큐레이션 요약

Cloudflare OS로 Cloudflare의 업무 방식을 재구상하는 방법

Cloudflare는 AI 에이전트가 업무 방식을 크게 바꿀 만큼 발전했지만, 생산 시스템과 내부·고객 데이터에 대한 통제가 함께 필요하다고 판단했다. 이를 위해 사내 AI 플랫폼인 **Cloudflare OS**를 구축하고, 인간의 책임·최소 권한·조직 맥락 활용을 핵심 원칙으로 삼았다. 엔지니어에게는 코드 품질과 보안을 위한 가드레일을 제공하고, 비엔지니어에게는 개발 도구가 아닌 업무 중심의 직관적인 인터페이스를 제공하려 했다. ## AI 확산과 거버넌스의 필요성 - 영업팀 직원이 AI로 여러 시스템의 API 키와 배포 파이프라인 관리자 권한을 요구하는 “SuperApp”을 만든 것이 문제의 출발점이었다. - 초기에는 정보 검색용 챗봇과 코드 작성 보조 정도로 AI를 제한했지만, 더 강력한 모델과 에이전트 도구가 등장하면서 상황이 급변했다. - 기술·비기술 직군 모두가 AI를 활용해 업무를 자동화하려 했고, 회사는 생산성을 지원하면서도 다음 자산을 보호해야 했다. - 내부 시스템 - 조직 데이터 - 고객 데이터 - 배포 및 운영 환경 - Cloudflare는 Workers, Access 등 기존 개발자·Zero Trust 제품을 조합하고 맞춤형 서비스를 추가해 Cloudflare OS를 구축했다. ## AI 도입을 위한 다섯 가지 원칙 ### 고객 문제 해결이 출발점 - AI를 사용하는 것 자체를 목표로 삼지 않는다. - 먼저 “해야 할 일(jobs to be done)”과 업무의 병목, 고객 대응의 개선 지점을 정의한다. - 그 다음 문제에 적합한 AI 도구를 선택한다. ### 모든 직원에게 도구를 제공 - 초기 AI 에이전트는 터미널, 코드 에디터, Git 저장소 등 개발자 중심의 인터페이스에 집중됐다. - 하지만 모든 직원이 개발 도구를 사용할 필요는 없다. - 직원은 자신의 도메인 전문성을 제공하고, 회사는 누구나 사용할 수 있는 직관적인 플랫폼을 제공해야 한다. ### AI 결과물은 인간이 책임진다 - AI를 팀원으로 간주하지 않고 도구와 도구 제작자로 본다. - AI 결과물의 품질 기준, 테스트 방법, 업무 흐름을 정의하고 검증하는 책임은 사람에게 있다. - 에이전트를 만든 사람이 회사를 떠나면 관리자가 해당 에이전트의 책임을 이어받는다. ### 모델보다 조직 맥락이 중요하다 - Cloudflare용 에이전트는 일반적인 지식뿐 아니라 Cloudflare의 정책, 업무 방식, 시스템 구조를 이해해야 한다. - 따라서 모델 성능 향상과 함께 신뢰할 수 있고 정제된 조직 지식 계층을 구축해야 한다. ### AI 사용 시 권한을 확대하지 않는다 - AI를 통해 시스템 원장에 접근할 때 사용자가 기존보다 더 많은 권한을 가져서는 안 된다. - 에이전트는 업무에 필요한 최소 권한만 가져야 한다. - 에이전트를 다른 사람과 공유할 때도 제작자의 권한이 아니라 사용하는 사람의 권한을 적용해야 한다. - 기존의 역할·기기·지역별 접근 제어와 서드파티 애플리케이션의 보안 설정도 AI 에이전트에 동일하게 적용해야 한다. ## 엔지니어를 위한 가드레일: Engineering Codex - AI가 코드를 매우 빠르게 작성하면서 기존 코드 리뷰 프로세스가 따라가지 못했고, 잘못된 코드도 더 빠르게 생성되는 문제가 생겼다. - Cloudflare는 엔지니어링 원칙과 모범 사례를 담은 권위 있는 가이드인 **Cloudflare Engineering Codex**를 만들었다. - Codex는 단순히 금지 목록을 제시하는 정책이 아니라, 각 영역에서 “어떻게 해야 좋은가”를 제시하는 의견이 반영된 기준이다. - 코드베이스의 각 영역에는 품질 기준에 책임을 지는 도메인 오너가 있다. - Codex는 소프트웨어 개발 생명주기 전반에 적용된다. - 작업 계획 검토 - 기술 설계 검토 - Merge Request 검토 - 장애 보고서 검토 - 최근 4개월 동안 관련 에이전트는 약 25만 건의 잠재적 문제를 발견했고, 1만 6천 건의 병합을 차단했다. - 구현이 시작되기 전 약 600건의 설계에서 아키텍처 문제를 찾아냈다. - 다음 단계는 에이전트가 생성한 결과물을 평가하는 평가 루프를 엔지니어들이 직접 정의할 수 있도록 지원하는 것이다. ## 비엔지니어를 위한 접근 방식의 전환 - 초기에는 엔지니어용 도구에 더 친절한 사용자 인터페이스만 입힌 방식으로 비엔지니어를 지원하려 했다. - 그러나 코드 저장소를 복제하고 `AGENTS.md` 같은 컨텍스트 파일을 추가하는 개발자 중심 방식은 비정형 지식 업무와 잘 맞지 않았다. - 비엔지니어의 업무는 다음과 같은 특징이 있다. - 일회성 결과물을 자주 만든다. - 여러 시스템 원장의 데이터를 함께 사용한다. - 명확한 코드 저장소나 반복 가능한 개발 프로젝트가 없는 경우가 많다. - 개발용 에이전트 환경을 그대로 제공하면 실제 문제보다 더 많은 “바이브 코딩” 앱이 만들어지는 문제가 발생했다. - Cloudflare는 이 접근이 잘못되었음을 인정하고, 사용자가 직접 도구를 조립하게 하기보다 원하지 않는 업무를 “매직 AI 이메일 봇”에 보내도록 하는 업무 중심 인터페이스로 방향을 전환했다. Cloudflare의 경험은 AI 도입에서 모델 선택보다 **권한 설계, 조직 지식의 구조화, 인간의 책임, 사용자별 인터페이스**가 더 중요할 수 있음을 보여준다. 특히 에이전트는 기존 사용자의 권한을 넘지 않도록 설계하고, 직군별 업무 방식에 맞는 도구를 제공하는 것이 안전하고 지속 가능한 도입의 핵심이다.

원문 읽기(새 탭에서 열림)

AI 에이전트Cloudflare Workers코드 리뷰제로 트러스트+2

cloudflare·2026년 8월 5일·4분 읽기큐레이션 요약

Cloudflare OS: 에이전트, 앱 및 업무를 위한 개방형 플랫폼

Cloudflare OS는 회사의 지식·절차·용어·시스템을 에이전트가 활용하도록 만들어, 엔지니어뿐 아니라 모든 직원이 업무를 자동화하고 앱과 문서를 만들 수 있게 하는 플랫폼이다. 초기 버전의 한계였던 정적 앱, 반복적인 에이전트 실행, 데이터 권한 관리 문제를 해결하기 위해 보안과 거버넌스를 플랫폼의 핵심으로 재설계했다. 새 버전은 오픈 소스로 제공되며, 조직이 내부 시스템과 업무 방식을 연결해 직접 구축하고 확장할 수 있다. ## 조직의 맥락을 에이전트에게 전달하기 - 조직은 미션과 함께 고유한 용어, 절차, 시스템, 표준, 업무 방식을 구성원에게 전달한다. - 업무 결과는 코드뿐 아니라 문서, 발표 자료, 인간관계, 물리적 성과 등 다양한 형태로 나타난다. - 코드는 실행 여부라는 명확한 피드백이 있지만, 비정형 업무에는 조직의 맥락과 시스템 접근 권한이 필요하다. - Cloudflare OS는 회사가 축적한 지식과 반복 업무의 모범 사례를 에이전트가 따를 수 있는 컨텍스트와 스킬로 저장한다. - 한 사람이 더 나은 업무 방식을 만들면 조직 전체가 이를 재사용할 수 있다. ## 초기 버전에서 얻은 한계와 교훈 - 초기 Cloudflare OS는 개인별 비공개 워크스페이스 중심이었다. - 앱은 내부 시스템과 실시간으로 연결된 소프트웨어가 아니라 정적인 결과물에 가까웠다. - 결정적인 반복 작업도 스킬을 다시 실행해야 했고, 그만큼 추가 모델 토큰을 소비했다. - MCP 서버가 제공하는 도구 목록만으로는 에이전트가 실제로 어떤 데이터와 리소스를 관찰했는지 알 수 없었다. - 워크스페이스와 앱을 공유하면서, 사용자가 권한 없는 정보를 간접적으로 볼 가능성이 커졌다. - 이에 따라 보안을 앱 제작자나 개별 사용자에게 맡기지 않고 플랫폼 수준에서 처리하도록 새 기반을 설계했다. ## Cloudflare OS의 세 가지 구성 요소 - **조직 컨텍스트 기반 에이전트 워크스페이스** - 회사가 선별한 지식과 스킬을 바탕으로 대화하고 작업한다. - 에이전트가 코드를 작성·실행할 수 있는 격리된 런타임을 제공한다. - **보안·거버넌스 프레임워크** - 내부 데이터와 서비스에 대한 접근을 정책에 따라 통제한다. - 에이전트와 앱이 접근할 수 있는 리소스와 데이터의 이동 경로를 관리한다. - **수정 가능한 개인·협업 앱 플랫폼** - 대화에서 시작한 작업을 문서, 앱, 지속 실행 워크플로로 발전시킬 수 있다. - 사용자가 만든 앱을 공유하고 계속 수정할 수 있다. ## 브라우저 기반 에이전트 워크스페이스 - 개발자나 터미널 사용법을 몰라도 브라우저에서 사용할 수 있도록 설계됐다. - 워크스페이스는 다음 요소를 결합한다. - 에이전트 세션 - 지속 상태 - 파일과 산출물 - 외부 리소스 접근 - 코드를 작성하고 실행하는 격리 런타임 - 팀이나 회사가 수집한 컨텍스트와 스킬이 기본으로 포함되어 동일한 업무 절차를 매번 다시 설명할 필요가 없다. ### 조사와 질의 - 회사 컨텍스트와 허용된 리소스를 기반으로 주제를 조사할 수 있다. - 전체 데이터를 모델 컨텍스트에 넣는 대신, 에이전트가 코드를 작성해 검색·필터링·조인·분석을 수행한다. ### 문서·슬라이드·스프레드시트 생성 - 조사 결과를 문서, 프레젠테이션, 스프레드시트로 변환할 수 있다. - 결과물은 단순한 정적 파일이 아니라 원본 데이터와 연결된 상태로 유지될 수 있다. - 데이터가 변경되면 결과물을 갱신할 수 있으며, Google Drive 같은 기존 서비스나 익숙한 형식으로 내보낼 수도 있다. ### 협업 앱 구축 - 문서나 스프레드시트로 부족한 경우, 에이전트가 자체 인터페이스·로직·상태를 가진 앱을 만든다. - 앱은 회사 리소스와 연결될 수 있고 여러 사람이 함께 사용할 수 있다. ### 결정적 워크플로 실행 - 반복적인 업무의 예측 가능한 단계는 코드로 처리하고, 판단이 필요한 부분에만 모델을 사용한다. - 워크플로는 수동 실행, 예약 실행, 연결된 시스템의 이벤트 발생 시 실행이 가능하다. - 기존 MCP 서버는 MCP Server Portals를 통해 계속 사용할 수 있다. ## API 키 대신 세분화된 권한 모델 - 회사 시스템에 연결하기 위해 API 키를 에이전트나 사용자에게 직접 제공하는 방식은 위험하다. - API 키는 대개 권한 범위가 넓고 수명이 길며, 공유와 감사가 어렵다. - MCP 서버는 자격 증명을 내부에 보관하고 제한된 도구만 노출하므로 개선된 접근 방식이다. - 그러나 MCP만으로는 에이전트가 어떤 원본 리소스를 관찰했는지, 이후 데이터가 어디로 이동할 수 있는지까지 통제하기 어렵다. - 따라서 권한 부여는 단순히 “어떤 도구를 호출할 수 있는가”를 넘어 데이터의 후속 사용과 노출 가능성까지 고려해야 한다. ## 무권한 시작과 Gatekeeper 기반 접근 - Cloudflare Access가 Cloudflare OS에 들어올 수 있는 사용자를 통제한다. - OS 내부에서는 모든 에이전트와 앱이 처음에 아무 권한도 갖지 않는다. - 에이전트가 특정 리소스에 대한 접근을 요청하면 관리자가 승인하거나 거부한다. - 승인된 리소스는 생성 코드에 타입이 지정된 바인딩으로 전달된다. ```ts const issues = await env.PROJECT.listIssues({ teamId: "ENG", state: "open", }); ``` - `env.PROJECT`는 특정 리소스와 정책에 대한 권한을 나타내는 capability다. - 실제 인증 정보는 에이전트와 생성된 코드에서 완전히 격리된다. - 이러한 Gatekeeper를 통해 에이전트와 앱이 시스템 오브 레코드에 접근할 때 조직의 정책에 따른 통제가 가능해진다. ## 실용적인 결론 Cloudflare OS의 핵심은 단순히 AI 챗봇을 제공하는 것이 아니라, 조직의 지식과 시스템 접근 권한을 안전하게 결합해 업무 자체를 자동화하는 데 있다. 조직에 도입하려면 먼저 반복 업무를 컨텍스트·스킬·결정적 워크플로로 정리하고, API 키 직접 공유 대신 리소스별 최소 권한과 감사 가능한 접근 정책을 설계하는 것이 중요하다.

원문 읽기(새 탭에서 열림)

AI 에이전트모델 컨텍스트 프로토콜cloudflare자동화+3

cloudflare·2026년 8월 5일·4분 읽기큐레이션 요약

신원 인식형 분석으로 통제 불능 AI 행동 포착하기

AI 사용량의 이상 징후를 파악하려면 요청마다 검증된 사용자·에이전트 신원과 각 계정의 정상적인 사용 기준선이 필요하다. Cloudflare는 AI Gateway와 Cloudflare Access를 결합해 요청별 신원을 확인하고, User Insights로 계정별 사용 패턴에서 벗어난 행동을 탐지한다고 밝혔다. 이를 통해 비용 관리뿐 아니라 과도한 사용이나 악성·오작동 에이전트 탐지까지 가능하게 한다. ## AI Gateway를 통한 중앙 관리 - AI Gateway는 OpenAI, Anthropic, Google, Workers AI 등 여러 모델로 향하는 요청을 하나의 제어 지점으로 통합한다. - 애플리케이션뿐 아니라 Claude Code, Codex, GitHub Copilot 같은 개발자용 에이전트도 동일한 관찰·보안·거버넌스 정책을 적용할 수 있다. - 모든 AI 트래픽을 한곳에서 분석하므로 비용, 모델 사용량, 접근 제어를 통합 관리할 수 있다. ## Cloudflare Access 기반의 신원 확인 - AI Gateway 앞에 사용자 정의 도메인을 두고 Cloudflare Access로 보호할 수 있다. - Okta, Entra 등 SAML을 지원하는 ID 공급자를 이용해 인증하며, 별도의 Cloudflare API 키를 배포할 필요가 없다. - 인증된 요청에는 사용자의 Access ID가 `cf.user_id` 메타데이터로 포함된다. - 관리자는 실제 요청자를 기준으로 로그, 분석 데이터, 비용을 필터링할 수 있다. - 공유 API 키 때문에 누가 얼마나 사용했는지 알기 어려웠던 문제를 해결한다. ## 사용자별 비용 한도와 정책 - `cf.user_id`를 기반으로 사용자마다 독립적인 예산 한도를 설정할 수 있다. - 한도에 도달하면 요청을 차단하거나 더 저렴한 모델로 자동 전환할 수 있다. - 향후 ID 공급자의 그룹 정보와 연동해 팀별로 모델 접근 권한과 지출 한도를 설정할 예정이다. - 머신러닝 팀에는 최고급 모델 허용 - 지원팀에는 지출 상한 적용 - 특정 프로젝트 구성원에게 공동 예산 할당 ## User Insights의 역할 - User Insights는 AI Gateway를 통과하는 기존 트래픽을 별도 설정 없이 분석한다. - 사람과 에이전트 각각의 평소 행동 패턴을 학습하고, 그 패턴에서 벗어난 계정을 보여준다. - 비용뿐 아니라 캐시 적중률이 낮거나 컨텍스트 윈도우가 과도하게 큰 등 비용 낭비 요인도 추적한다. - 단순히 “많이 사용했는가”가 아니라 “그 계정의 평소 사용 방식과 다른가”를 판단하는 데 초점을 둔다. ## 사람과 에이전트별 행동 기준선 - 계정은 사용자든 에이전트든 시간에 따라 고유한 행동 패턴을 만든다. - 일정한 간격으로 티켓을 요약하는 에이전트와, 프롬프트·세션 길이가 불규칙한 사람은 정상 패턴이 다르다. - 따라서 모든 계정에 동일한 절대 비용 기준을 적용하면 오탐이 많아진다. - 평소 비용이 큰 사용자의 500달러 지출은 정상일 수 있다. - 평소 5달러를 쓰는 에이전트의 50달러 세션은 10배 증가한 이상 징후일 수 있다. ## 세션 비용 기반 이상 탐지 - User Insights는 개별 요청이 아니라 세션 단위로 비용을 평가한다. - 최근 30일 동안 해당 계정의 세션 비용 p95를 개인 기준선으로 사용한다. - 세션 비용이 개인 p95의 2배를 초과하면 이상 행동 후보로 분류한다. - 단, 상대적 급증만으로는 부족하므로 조직 전체 세션 비용의 p99도 함께 사용한다. - 최종적으로 다음 조건을 모두 만족하는 세션만 경고 대상이 된다. - 해당 계정의 최근 기준선보다 2배 이상 비쌈 - 조직 전체 세션 중 가장 비싼 1% 수준에 해당함 - 절대 비용 하한선도 적용해, 소액 사용자의 몇 센트짜리 급증이 불필요한 경고를 발생시키지 않도록 한다. ## 동적으로 갱신되는 기준선 - 기준선은 고정값이 아니라 계정의 최근 사용 습관에 따라 계속 변한다. - 계정의 rolling p95와 2배 임계값이 이동하므로 현재 행동에 맞는 경고가 가능하다. - 정상적인 고사용자 활동은 제외하고, 평소 패턴을 깨면서도 실제 조사 가치가 있는 고비용 세션만 추린다. - 결과적으로 관리자는 정상 트래픽을 모두 살펴보는 대신, 의심스러운 계정 중심의 “rogue behavior feed”를 확인할 수 있다. ## 보안과 비용 관리의 결합 - 이상 사용은 새로운 도구나 명백히 차단된 행동으로 나타나지 않을 수 있다. - 이미 권한을 가진 계정이나 서비스 계정이 허용된 작업을 평소보다 훨씬 많이 수행하는 방식으로 나타날 수 있다. - 따라서 사용자 신원 확인과 행동 기준선 분석을 함께 적용해야 비용 폭증과 보안 위험을 동시에 발견할 수 있다. 실무적으로는 모든 AI 요청을 AI Gateway로 통합하고, Cloudflare Access로 개인·에이전트 신원을 연결한 뒤, 사용자별 예산과 User Insights의 상대적 기준선을 함께 활용하는 방식이 권장된다.

원문 읽기(새 탭에서 열림)

ai-securityanomaly-detectionai-gatewaycloudflare-access+4

cloudflare·2026년 8월 5일·4분 읽기큐레이션 요약

WriteGuard: MCP 서버를 위한 세밀한 제어

AI 에이전트가 외부 시스템에 쓰기 권한을 가지면, 잘못된 프롬프트 하나만으로 사람의 작업 속도를 훨씬 뛰어넘는 대규모 변경을 일으킬 수 있다. Cloudflare는 에이전트별 설정이나 사용자의 감시에 의존하지 않고, MCP 도구 호출을 중앙에서 정책 적용·식별·감사하기 위해 WriteGuard를 구축했다. WriteGuard는 인간 사용자의 권한은 유지하면서 에이전트 세션을 별도로 추적하고, 위험도에 따라 작업을 허용·기록·차단한다. ## MCP의 구조와 에이전트 동작 방식 - MCP(Model Context Protocol)는 AI 애플리케이션이 외부 도구와 데이터에 연결되도록 하는 표준이다. - MCP 서버는 다음 요소를 가진 도구를 제공한다. - 도구 이름 - 설명 - 입력 스키마 - 실제 작업을 수행하는 핸들러 - 에이전트가 도구를 선택하면 MCP 클라이언트가 서버에 호출을 보내고, 서버가 Jira·GitLab·데이터베이스 등 downstream 시스템과 상호작용한다. - 따라서 도구에 쓰기 권한이 부여되면 에이전트가 외부 시스템의 상태를 직접 변경할 수 있다. ## 무제한 쓰기 권한의 위험 - 잘못 작성된 정리 작업 프롬프트가 수천 개의 티켓을 자동으로 닫을 수 있다. - 사람이 직접 수행한 작업과 에이전트가 수행한 작업이 동일한 사용자 계정으로 기록되면 원인 분석과 복구가 어려워진다. - 여러 에이전트 세션이 동시에 실행되면 네트워크 로그만으로 특정 세션을 식별하기 어렵다. - 위험한 사례는 다음과 같다. - 계약 소프트웨어의 계약 내용 변경 - 고객지원 큐에 대량 답변 전송 - 데이터베이스 테이블 전체 삭제 - Cloudflare는 모든 사용자가 에이전트를 완벽하게 설정하거나 모든 도구 호출을 감시할 수 없다고 판단했다. ## Cloudflare의 MCP 확장 - Cloudflare의 내부 에이전트는 OpenCode, Cloudflare OS, 장기 실행 에이전트 서비스 등을 통해 MCP를 사용한다. - 내부 MCP 포털이 여러 서버를 통합하며, 연결된 서버 수는 13개에서 27개로 증가했다. - 초기에는 Jira, GitLab, 위키, 운영 시스템 등을 조회하는 읽기 전용 서버로 시작했다. - 이후 엔지니어링·제품·디자인·영업·고객 성공팀에서 실제 변경 작업을 수행하는 도구를 요구했다. - 클라이언트의 skill이나 elicitation prompt만으로는 통제가 어렵기 때문에 중앙 정책 계층인 WriteGuard를 도입했다. ## WriteGuard의 역할 - WriteGuard는 MCP 서버와 도구 호출 사이에 위치하는 공통 계층이다. - 도구 설정과 요청 컨텍스트를 바탕으로 호출을 다음과 같이 처리한다. - 호출을 그대로 통과 - 에이전트 식별 정보를 추가한 뒤 통과 - 감사 이벤트를 생성 - 핸들러 실행 전에 호출 차단 - WriteGuard는 다음 기능을 하나의 장소에서 제공한다. - 도구별 정책 관리 - 사용자 및 에이전트 신원 연결 - downstream 시스템에 에이전트 정보 표시 - 중앙 감사 로그 수집 ## 도구 위험도 기반 정책 각 도구에는 위험도, 활성화 여부, 라벨링 설정을 지정한다. - **Read Only** - 이슈 검색 - Merge Request 조회 - 파이프라인 상태 확인 - **Minimal Impact** - 리액션 추가 - 알림을 읽음으로 표시 - 이슈 구독 - **Contained Write** - 댓글 작성 - Merge Request 생성 - 이슈 필드 수정 - **Critical** - Merge Request 병합 - 운영 환경 배포 실행 - 레코드 일괄 삭제 위험도는 감사 로그 기록 여부와 호출 허용 여부를 결정하며, 위험도별로 로그를 검색할 수 있다. 또한 서버 코드를 수정하지 않고도 특정 입력 필드에 일반 텍스트나 HTML 형식의 에이전트 라벨을 삽입할 수 있다. ## 사람의 권한을 유지하고 에이전트만 식별 - 내부 MCP 서버는 Cloudflare Access와 OAuth로 사용자를 인증한다. - 에이전트는 별도 계정이 아니라 사용자의 권한을 그대로 사용한다. - 따라서 Joe가 특정 이슈를 닫을 수 없다면 Joe의 에이전트도 닫을 수 없다. - 별도 에이전트 계정을 만들지 않은 이유는 다음과 같다. - 관리해야 할 권한 체계가 추가됨 - 에이전트와 책임자인 사람의 연결이 약해짐 - 대신 WriteGuard는 사용자 신원에 MCP 클라이언트와 세션 정보를 추가한다. - downstream 애플리케이션에는 사람의 권한으로 수행된 작업이라는 정보와 함께, 어떤 에이전트 세션이 작업했는지 표시할 수 있다. ## 중앙 감사 로그와 대규모 활동 분석 - WriteGuard는 각 도구 호출을 성공, 실패, 차단으로 분류한다. - 이후 감사 이벤트를 비동기적으로 내부 audit Worker에 전송한다. - 감사 이벤트에는 다음 정보가 포함된다. - MCP 서버 - 도구 이름 - 위험도 - 호출 결과 - 사용자 - 클라이언트 - 실행 시간 - 비밀번호나 민감한 값으로 분류된 입력 키의 값은 제거한다. - 비동기 로깅을 사용하므로 에이전트가 응답을 기다리는 시간에는 추가 지연이 없다. - MCP 포털 로그가 개별 호출을 보여준다면, WriteGuard 로그는 도구의 의미적 분류·에이전트 컨텍스트·백엔드 처리 결과를 함께 제공한다. - 이를 통해 특정 시스템 하나가 아니라 전체 MCP 환경에서 에이전트의 대량 활동을 검색하고 조사할 수 있다. ## GitLab 적용 방식 - 글에서는 GitLab MCP 서버의 세 도구를 예로 든다. - `get_merge_request`: Merge Request 읽기 - `create_mr_note`: 댓글 또는 노트 작성 - `merge_mr`: Merge Request 병합 - 이 도구들은 각각 읽기, 제한적 쓰기, 중요 쓰기 등 서로 다른 위험도 정책을 적용할 수 있다. - 이를 통해 동일한 GitLab 서버 안에서도 조회는 허용하되 댓글 작성이나 병합은 별도로 기록하거나 차단하는 식의 세밀한 통제가 가능하다. ## 실용적인 결론 MCP 서버에 쓰기 권한을 추가할 때는 단순한 사용자 인증만으로는 부족하다. 도구별 위험도 정책, 에이전트 세션 식별, 민감정보 제거 감사 로그, 사전 차단 기능을 중앙 계층에서 제공해야 하며, 특히 대량 변경이 가능한 작업은 높은 위험도로 분류해 별도 통제하는 것이 안전하다.

원문 읽기(새 탭에서 열림)

AI 에이전트gitlab모델 컨텍스트 프로토콜TypeScript+4

cloudflare·2026년 8월 4일·4분 읽기큐레이션 요약

에이전트 개발 수명주기가 Cloudflare에 도래했습니다

AI는 소프트웨어 구현을 가장 빠르고 저렴한 단계로 만들었지만, 그 결과 테스트·배포·운영·유지보수 단계가 감당하기 어려운 속도로 몰려들고 있다. 글은 인간 중심의 SDLC만으로는 에이전트가 생산하는 코드와 변경량을 처리할 수 없다고 주장하며, 전체 개발 과정을 에이전트 중심의 ADLC(Agent Development Lifecycle)로 재설계해야 한다고 제안한다. 이를 위해서는 에이전트가 코드 작성뿐 아니라 검증, 배포, 관측, 장애 대응, 개선까지 수행할 수 있는 소프트웨어 팩토리와 전용 플랫폼이 필요하다. ## AI가 바꾼 소프트웨어 개발 생태계 - 전통적인 SDLC는 다음 단계로 구성된다. - 계획(Plan) - 설계(Design) - 구현(Implement) - 테스트(Test) - 배포(Deploy) - 유지보수(Maintain) - 폐기(Retire) - AI는 기존에 가장 느리고 비용이 많이 들던 구현 단계를 급격히 빠르고 저렴하게 만들었다. - 그러나 구현 이후의 단계는 같은 속도로 자동화되지 않아 다음과 같은 병목이 발생한다. - 오픈소스 프로젝트에 쏟아지는 풀 리퀘스트와 이슈 - 급증한 배포량을 처리해야 하는 운영 엔지니어 - 검토·병합·배포·장애 대응을 담당하는 사람들의 과부하 - 현재 많은 조직은 에이전트에게 코드 작성만 맡기고, 검증과 운영은 사람이 담당하는 불균형한 구조를 사용하고 있다. ## SDLC에서 ADLC로의 전환 - 글은 인간 중심의 SDLC를 에이전트 중심의 ADLC로 대체해야 한다고 주장한다. - ADLC의 목표는 에이전트가 단일 작업이 아니라 다음 전체 흐름을 자율적으로 처리하는 것이다. - 버그 리포트나 고객 요청 수집 - 문제 재현과 원인 분석 - 코드 수정 - 테스트와 검증 - 리뷰 및 병합 - 배포와 모니터링 - 운영 중 발생한 문제의 자동 triage와 수정 - 현재는 사람이 각 SDLC 단계에서 에이전트를 지시하고 결과를 확인하는 방식이 대부분이다. - 소프트웨어 팩토리는 이러한 사람의 개입을 줄이고, 인간이 창의성·판단·고객 이해가 필요한 업무에 집중하도록 만드는 시스템이다. ## 소프트웨어 팩토리에 필요한 플랫폼 특성 에이전트가 전체 개발 프로세스를 운전하려면 기존의 인간용 개발 환경을 그대로 사용할 수 없으며, 각 작업이 다음 특성을 가져야 한다. - **프로그램화 가능성** - ClickOps처럼 사람이 화면을 클릭해야 하는 작업은 에이전트에 적합하지 않다. - 모든 작업이 호출·디버깅·자동화 가능한 API를 제공해야 한다. - **수평 확장성** - 여러 에이전트가 동시에 작업할 수 있어야 한다. - 각 에이전트가 운영 환경과 일치하는 독립적인 프리뷰 환경을 가져야 한다. - **재현 가능성** - 특정 기기, 네트워크 상태, 국가별 IP 등 복잡한 조건에서 발생하는 버그도 재현할 수 있어야 한다. - 단순한 단위 테스트와 통합 테스트만으로는 부족하다. - **실시간·푸시 기반 동작** - 사람이 대시보드를 확인하기를 기다리는 방식은 에이전트에 맞지 않는다. - 장애나 상태 변화가 발생하면 이벤트가 에이전트를 자동으로 호출해야 한다. - **원자성** - 각각의 변경은 독립적으로 테스트·배포·관측·롤백 가능해야 한다. - 한 변경이 관련 없는 동작에 영향을 주지 않아야 한다. - **권한 관리** - 에이전트에 운영 환경의 무제한 권한을 제공할 수는 없다. - 작업에 필요한 권한을 명확히 제한하면서도, 안전한 절차를 통해 추가 권한을 요청하거나 상승시킬 수 있어야 한다. - **자기 개선** - 에이전트도 과거 작업과 운영 경험으로부터 학습해야 한다. - 반복되는 작업에서 점점 더 빠르고 정확하게 동작할 수 있는 피드백 체계가 필요하다. ## Cloudflare가 제시한 구현 사례 Cloudflare는 에이전트를 단순한 코드 생성기가 아니라 API를 통해 전체 시스템을 조작하는 고객으로 취급한다. 이를 바탕으로 다음과 같은 도구와 사례를 소개한다. - `@cloudflare/ci` - 수백만 개 저장소에서 CI/CD를 실행하기 위한 시스템 - Cloudflare Workflows를 기반으로 동작 - 실패를 스스로 복구하고, 복잡한 작업을 수행할 에이전트를 생성할 수 있음 - 로컬 개발 환경의 OpenTelemetry 트레이스 - 운영 환경에서 사용하는 수준의 관측성을 로컬 개발에도 제공 - Wrangler와 Cloudflare Vite 플러그인에 통합 - Cloudflare Agents와 Agent Traces - 에이전트의 실행을 관찰하고 유지보수하며 개선하기 위한 공간 - 에이전트 활동을 OpenTelemetry 트레이스로 추적 - AI 기반 엔지니어링 표준 적용 - 여러 제품과 시스템 저장소에 공통 개발 원칙과 표준을 자동으로 적용 - Astro 소프트웨어 팩토리 - GitHub 이슈를 자동으로 분류하고, 재현하고, 검증하고, 수정 - 규모가 커지는 오픈소스 프로젝트의 이슈 수를 0에 가깝게 줄이는 것을 목표로 함 ## 자율 시스템에 필요한 신뢰성 - 소프트웨어 팩토리는 자율주행차와 비슷한 문제를 가진다. - 단순히 80% 정도 성공하는 수준은 충분하지 않다. - 실제 운영 소프트웨어를 맡기려면 99%를 넘어 여러 개의 9가 붙는 수준의 안정성과 안전성이 필요하다. - 자율주행차가 카메라, 라이다, 고성능 연산 장치, 원격 제어 체계를 갖추는 것처럼, 자율적으로 개발하는 에이전트에도 인간 개발자를 위해 설계된 기존 도구 이상의 장치가 필요하다. - 에이전트가 PR을 자동 승인하고 운영 서비스에 병합하지 못하는 이유는 테스트 실패뿐 아니라 다음과 같은 복합적인 위험 때문이다. - 고객 요구를 잘못 해석할 가능성 - 여러 팀과 전문 영역에 걸친 변경 - 주관적인 품질 판단 - 대시보드나 사용자 경험처럼 자동 테스트가 어려운 변화 - 운영 중 발생할 수 있는 예측하기 어려운 부작용 ## 실용적인 결론 에이전트 도입의 핵심은 코드 생성량을 늘리는 데 있지 않고, 생성된 변경을 안전하게 검증하고 배포하고 운영하는 전체 체계를 함께 자동화하는 데 있다. 따라서 조직은 에이전트에 단순한 코딩 권한만 주기보다, 재현 가능한 환경·세밀한 권한·실시간 관측·원자적 배포·자동 롤백과 같은 ADLC 기반 인프라부터 구축해야 한다.

원문 읽기(새 탭에서 열림)

AI 에이전트CI/CDcloudflareGitHub Actions+3

cloudflare·2026년 8월 4일·4분 읽기큐레이션 요약

수백만 개 리포지토리의 CI/CD를 실행하세요 — 여러분의 플랫폼에서, Cloudflare에서

Cloudflare는 코드 저장소인 Artifacts를 기반으로 빌드·테스트·배포까지 전 과정을 Cloudflare에서 실행하는 CI/CD 환경을 구축하고 있다. 새 CI SDK는 Cloudflare Workflows와 Sandbox SDK를 결합해 CI 파이프라인을 TypeScript로 정의하고, 코드가 Artifacts에 push될 때 자동으로 실행할 수 있게 한다. 각 단계의 재시도·타임아웃·캐싱·병렬 실행을 지원하며, 성공한 경우에만 자동 배포하거나 AI 에이전트를 통한 자동 수정도 가능하다. ## Cloudflare에서 완성되는 코드 개발 생태계 - Cloudflare는 다음 과정을 하나의 플랫폼으로 통합하려 한다. - 코드 저장: Artifacts - 빌드 및 테스트: CI SDK와 Workflows - 배포: `wrangler deploy` - Artifacts는 수백만 개의 저장소를 저장하고 버전을 관리할 수 있는 코드 저장소다. - `wrangler` 설정의 새로운 `events` 필드를 이용하면 Artifacts의 `push` 이벤트를 Workflow 실행으로 직접 연결할 수 있다. - 별도의 이벤트 구독, 큐, 큐 컨슈머를 구성하지 않아도 코드 push를 CI 작업의 시작점으로 사용할 수 있다. ## CI/CD 파이프라인은 하나의 Workflow - CI/CD는 정해진 순서로 여러 단계를 실행하고, 하나라도 실패하면 이후 단계를 중단하는 프로세스다. - Cloudflare는 이를 본질적으로 Workflow와 동일한 구조로 본다. - 기존 YAML 기반 도구 대신 TypeScript의 `step.do()`와 CI SDK를 사용해 파이프라인을 정의할 수 있다. - TypeScript를 사용하면 YAML보다 다음과 같은 장점이 있다. - 조건문과 동적 설정을 쉽게 적용 - 플랫폼별·저장소별 파이프라인 커스터마이징 - 일반 코드와 동일한 방식의 재사용 및 유지보수 ## 격리된 환경에서 실행되는 CI 단계 - CI SDK는 각 명령을 독립적인 Sandbox 환경에서 실행한다. - 대표적인 단계는 다음과 같다. - 의존성 설치 - 코드 빌드 - 린트 실행 - 타입 검사 - 단위 테스트 - 조건부 배포 - 각 Sandbox 명령은 Workflow의 단계로 실행되므로 Cloudflare Workflows가 제공하는 재시도와 타임아웃 기능을 활용할 수 있다. - 기존에는 Sandbox API를 직접 호출하고 단계 간 상태를 별도로 관리해야 했지만, CI SDK가 이 과정을 추상화한다. ## 의존성 캐싱과 병렬 실행 - `bun install --frozen-lockfile` 같은 설치 단계를 먼저 정의하고, `package.json`과 `bun.lock`을 캐시 입력으로 지정할 수 있다. - 의존성 캐시는 계정의 R2 버킷에 Sandbox 스냅샷 형태로 저장된다. - 이후 린트·테스트·타입 검사·빌드 단계는 의존성 설치를 반복하지 않는다. - 독립적인 단계는 `Promise.all()`로 병렬 실행할 수 있어 전체 CI 시간을 줄인다. - 배포 단계는 모든 검사가 성공한 뒤 실행되도록 마지막에 배치한다. ```ts const deps = 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, }, }); ``` ## 플랫폼 관리 CI와 사용자 정의 CI - 플랫폼 사업자는 고객 애플리케이션을 대신해 CI/CD 파이프라인을 관리할 수 있다. - 하나의 Workflow를 여러 고객 애플리케이션에 공유하면 고객마다 CI 환경을 직접 운영할 필요가 없다. - 반대로 특정 고객이 자체적인 빌드·테스트 규칙을 원한다면 Dynamic Workflows를 이용해 전용 CI를 정의할 수 있다. - 플랫폼이 관리하는 CI와 고객이 직접 작성한 CI는 동일한 namespace 안에서 동시에 실행할 수 있다. - 따라서 모든 고객에게 동일한 파이프라인을 강제하지 않고, 공통 규칙과 개별 요구사항을 함께 지원한다. ## AI 기반 셀프 힐링 CI - CI Workflow에 AI 리뷰 에이전트를 통합할 수 있다. - 빌드 단계가 실패하면 에이전트가 오류를 분석하고 수정 코드를 생성할 수 있다. - 수정 사항을 커밋으로 push해 사람이 검토하고 승인하는 흐름도 구성할 수 있다. - Cloudflare는 이러한 예제를 Project Think의 self-healing CI Workflow로 제공한다. ## 직접 CI Workflow 작성하기 - `@cloudflare/ci`의 `CIWorkflow`를 import해 자체 파이프라인을 작성한다. - 설치 단계에서 Vite, React, esbuild, ESLint, Vitest 등 필요한 패키지와 도구를 설치한다. - lockfile을 지정해 의존성 변경 여부를 검증한다. - 설치 결과를 캐시한 뒤 빌드와 각종 검사를 별도의 격리된 단계에서 실행한다. - 기본적으로 Workflow 단계는 독립적으로 실행되므로 병렬 처리가 가능하다. - 배포 전에 모든 검사가 끝나야 한다면 `Promise.all()`로 여러 검사를 묶어 완료를 기다린다. ## 실용적인 결론 Cloudflare 기반 플랫폼을 운영하거나 고객별 코드를 관리한다면, CI SDK와 Workflows를 이용해 공통 파이프라인을 먼저 만들고 저장소별 예외만 동적으로 추가하는 방식이 적합하다. 설치 단계의 캐싱과 독립 검사의 병렬 실행을 적용하면 CI 지연 시간을 줄일 수 있으며, 배포는 모든 검증 단계가 성공한 뒤에만 실행하도록 구성하는 것이 안전하다.

원문 읽기(새 탭에서 열림)

CI/CDcloudflareTypeScriptwrangler+3

cloudflare·2026년 8월 4일·4분 읽기큐레이션 요약

이제 에이전트가 로컬 트레이싱으로 Workers를 디버깅할 수 있습니다

`wrangler dev`와 `vite dev`가 로컬 Worker 실행 중 OpenTelemetry 트레이스를 자동 수집해, 코딩 에이전트가 배포 전 오류 원인을 직접 분석하고 수정 결과를 검증할 수 있게 되었습니다. 별도의 SDK 설치, 트레이싱 설정, 에이전트 구성 없이도 에이전트 세션이 감지되면 Local Explorer API가 자동으로 안내됩니다. 에이전트는 트레이스와 로그뿐 아니라 로컬 바인딩 및 데이터 상태까지 조회해 디버깅할 수 있습니다. ## 로컬 Worker 실행 시 자동 트레이싱 - `wrangler dev` 또는 `vite dev`로 실행한 Worker 호출이 자동으로 OpenTelemetry 트레이스로 기록됩니다. - 별도의 SDK나 애플리케이션 코드 수정, 관측성 활성화 설정이 필요하지 않습니다. - Wrangler와 Cloudflare Vite 플러그인은 Miniflare를 통해 Worker를 로컬에서 실행하므로, 실제 Worker 런타임에 내장된 계측 기능을 로컬에서도 사용할 수 있습니다. - 에이전트 세션이 감지되면 개발 서버가 Local Explorer API 주소와 트레이스 조회 엔드포인트를 출력합니다. ## 에이전트가 자동으로 발견하는 Local Explorer API - Local Explorer는 로컬 리소스 데이터와 관측성 데이터를 확인할 수 있는 브라우저 UI이자 REST API입니다. - API 루트에서 OpenAPI 스키마를 제공하므로, 에이전트가 사전에 하드코딩된 지침 없이 실행 중 사용 가능한 엔드포인트를 탐색할 수 있습니다. - 트레이스와 연결된 콘솔 로그는 다음과 같은 읽기 전용 엔드포인트로 조회할 수 있습니다. ```text POST /cdn-cgi/explorer/api/local/observability/query ``` - 에이전트는 트레이스 조회 후 KV, D1, R2, Durable Objects, Workflows 등 로컬 바인딩과 저장 상태도 함께 검사할 수 있습니다. - Local Explorer는 Cloudflare 대시보드가 아니라 Worker와 같은 localhost에서 실행됩니다. - Wrangler에서 `e` 키 입력 - 또는 `/cdn-cgi/explorer` 접속 ## 트레이스로 오류 원인 식별 및 검증 예를 들어 `POST /api/orders`가 다음 작업을 수행한다고 가정합니다. - KV에서 활성 장바구니 조회 - D1에 결제 정보 저장 - Queue에 주문 처리 메시지 전송 스키마 변경 이후 요청이 500 오류를 반환하면 다음과 같이 분석할 수 있습니다. - 트레이스가 없을 때 - 500 응답만으로는 KV, D1, Queue 중 어디서 실패했는지 알기 어렵습니다. - 에이전트가 각 작업 전후에 임시 로그를 추가하고 요청을 반복 실행해야 합니다. - 로그 확인과 코드 수정이 반복되어 시간과 토큰이 소모됩니다. - 트레이스가 있을 때 - KV 조회는 성공했고, D1 삽입 단계에서 `no such column: delivery_window` 오류가 발생했다는 사실을 확인합니다. - D1 작업이 실패했기 때문에 Queue 호출까지 도달하지 않았다는 흐름도 파악할 수 있습니다. - 에이전트가 로컬 D1 스키마를 검사해 저장소에 존재하지만 아직 적용되지 않은 마이그레이션을 발견합니다. - 마이그레이션을 적용한 뒤 요청을 다시 보내고, 새 트레이스에서 성공 여부를 검증합니다. 이 과정은 임시 로그를 추가하거나 배포하지 않고도 오류 위치 확인, 환경 수정, 재검증을 한 번의 로컬 디버깅 루프에서 수행하게 해줍니다. ## 자동으로 기록되는 트레이스 범위 Worker 런타임인 `workerd`에 계측 기능이 내장되어 있어 다음 작업이 자동 기록됩니다. - **Fetch 호출** - 외부 HTTP 요청의 실행 시간 - 상태 코드 - 요청 관련 메타데이터 - **바인딩 호출** - KV, R2, D1, Durable Objects, Queues 등 Cloudflare 바인딩과의 상호작용 - **핸들러 호출** - `fetch`, `scheduled`, Queue 핸들러 등 호출 전체 생명주기 - 애플리케이션이 직접 생성한 커스텀 span도 자동 트레이스에 포함됩니다. - Miniflare는 런타임 이벤트와 콘솔 출력을 수집해 OpenTelemetry 트레이스 및 연결된 로그로 구성합니다. - 수집된 데이터는 내부 SQLite 기반 Durable Object에 저장되고, Local Explorer API를 통해 제공됩니다. ## 사람이 확인하는 Local Explorer - 에이전트는 REST API로 데이터를 조회하지만, 개발자는 브라우저 UI에서 동일한 정보를 시각적으로 확인할 수 있습니다. - 특정 요청을 선택하면 다음 정보를 볼 수 있습니다. - 전체 span 구조 - 각 작업의 실행 시간 - 속성 및 메타데이터 - 오류 정보 - 관련 콘솔 로그 - 로컬 바인딩 상태를 탐색하면서 요청 처리 흐름과 데이터 상태를 함께 점검할 수 있습니다. ## 사용 방법 - Wrangler 기반 프로젝트: ```bash npm install --save-dev wrangler@latest ``` - Cloudflare Vite 플러그인 기반 프로젝트: ```bash npm install --save-dev @cloudflare/vite-plugin@latest ``` 업데이트 후 평소처럼 `wrangler dev` 또는 `vite dev`를 실행하고, 에이전트에게 로컬에서 오류를 재현하고 수정한 뒤 검증하도록 요청하면 됩니다. 로컬 트레이스를 활용하면 배포 전에 실패한 바인딩 호출과 환경 문제를 빠르게 찾아 수정할 수 있으므로, Cloudflare Worker 프로젝트의 에이전트 기반 디버깅에서는 최신 Wrangler 또는 Vite 플러그인 사용을 권장합니다.

원문 읽기(새 탭에서 열림)

옵저버빌리티Cloudflare Workersdurable-objectssqlite+4

cloudflare·2026년 8월 4일·4분 읽기큐레이션 요약

소개: Cloudflare Agents

Cloudflare는 에이전트를 배포·관찰·개선할 수 있는 통합 관리 환경인 Cloudflare Agents를 공개했으며, 첫 기능으로 에이전트 트레이싱을 제공한다. 이 기능은 모델 호출, 도구 실행, 토큰 사용량, 승인 대기, 서브에이전트 작업과 Workers 인프라 동작을 하나의 추적으로 연결해 에이전트의 실제 동작과 비용을 파악하게 한다. 이를 통해 단순한 요청 성공 여부를 넘어 잘못된 도구 선택, 재시도 루프, 오래된 컨텍스트 전달 같은 문제를 분석하고 지속적으로 개선할 수 있다. ## 에이전트 관찰 가능성이 필요한 이유 - 에이전트는 HTTP 200을 반환하더라도 잘못된 도구를 선택하거나, 서브에이전트에 오래된 컨텍스트를 전달하거나, 토큰을 재시도 루프에서 낭비할 수 있다. - 기존 애플리케이션 텔레메트리는 API 요청이나 데이터베이스 쿼리는 보여주지만, 그 동작을 유발한 에이전트의 판단 과정은 보여주지 못한다. - 에이전트 수준의 텔레메트리는 다음 질문에 답해야 한다. - 지연 시간은 모델, 도구, 인프라 중 어디에서 발생했는가? - 승인 대기로 턴이 중단되었는가? - 어떤 모델을 호출했고 토큰을 얼마나 사용했는가? - 올바른 도구를 선택했는가? - 외부 API가 성공했는가, 타임아웃되었는가? - 어떤 서브에이전트가 작업했고 최종 응답에 어떤 영향을 주었는가? ## 에이전트 트레이싱의 범위 - 기존 Workers 트레이싱은 `fetch`, KV, D1 등 인프라 계층의 동작을 기록했다. - 새 에이전트 트레이싱은 여기에 다음과 같은 에이전트 전용 span을 추가한다. - 에이전트 호출 - 모델 호출 - 도구 실행 - 승인 이벤트 - 지원되는 서브에이전트 호출 - 모델명과 토큰 사용량 같은 정보도 메타데이터로 연결된다. - Think, Flue, AI SDK로 만든 에이전트는 Cloudflare 대시보드에서 추적을 확인하거나 OpenTelemetry 호환 대상에 내보낼 수 있다. ## 세션 리플레이로 판단 과정 확인 - Agents 대시보드의 Messages 탭에서는 특정 턴의 전체 대화를 재구성한다. - 시스템 지침 - 사용자 메시지 - 모델의 사고 과정 - 도구 호출 인자와 결과 - 최종 응답 - 이는 에이전트를 다시 실행하는 것이 아니라 기록된 데이터를 재생하는 기능이다. - 잘못된 도구 인자, 도구 선택 당시의 컨텍스트, 서브에이전트 핸드오프, 이전 턴이 이후 결과에 미친 영향을 분석할 수 있다. - Think, Flue, AI SDK에서는 `storeMessages`와 `storeTools` 설정으로 메시지 및 도구 payload 저장 여부를 제어한다. - 개인정보, 비밀값, 민감한 데이터가 포함될 수 있다면 payload 기록을 끄는 것이 권장된다. ## 실행 워터폴과 서브에이전트 추적 - Traces 탭은 각 턴의 실행 과정을 시간순 워터폴로 보여준다. - 부모 에이전트에서 서브에이전트, 모델, 도구, 데이터 저장소까지 하나의 흐름으로 연결된다. - 예시에서는 다음 작업을 한 화면에서 확인할 수 있다. - `TravelPlanner` 부모 에이전트 호출 - `itinerary_builder` 서브에이전트 호출 - `@cf/zai-org/glm-4.7-flash` 모델 호출과 토큰 사용량 - `record_itinerary_builder_execution` 도구 실행 - D1 쿼리 실행 - `record_respond_ready` 도구 실행 - KV 쓰기 - 부모 에이전트와 서브에이전트에는 에이전트 클래스, 대화, Durable Object 식별자가 연결되어 추적 간 상관관계를 파악할 수 있다. - KV, D1, Durable Object, 서비스 바인딩, `fetch` 등 Workers 리소스는 이를 호출한 에이전트 작업 아래에 중첩되어 표시된다. ## 트레이싱 활성화 방법 - 먼저 `wrangler.jsonc`에서 Workers 관찰 기능을 활성화한다. ```json { "observability": { "traces": { "enabled": true } } } ``` - 사용하는 에이전트 스택에 따라 추가 설정이 필요하다. - Think·Flue: 자체 트레이싱 통합 기능으로 에이전트, 대화, 턴, 모델, 도구 텔레메트리 전송 - AI SDK: Cloudflare의 `wrapAISDK()` 어댑터로 SDK 감싸기 - 사용자 정의 하네스: 커스텀 span API와 OpenTelemetry Generative AI 의미 규약 사용 ## OpenTelemetry 기반 확장과 외부 전송 - Cloudflare는 향후 Workers 내부에서 OpenTelemetry API를 직접 지원할 예정이다. - 표준 OpenTelemetry Generative AI span을 생성하는 프레임워크는 Cloudflare 전용 어댑터 없이 Agents 화면에서 시각화될 수 있다. - 표준 에이전트 및 대화 식별자가 포함되면 Cloudflare의 내장 통합처럼 에이전트와 세션 단위로 그룹화할 수 있다. - 추적 데이터는 Cloudflare에 종속되지 않으며, Wrangler 설정에서 OTLP 호환 제공자를 지정해 외부 관찰성 플랫폼으로 내보낼 수 있다. 에이전트 운영을 시작한다면 먼저 트레이싱을 활성화하고 메시지·도구 payload 저장 시 개인정보 노출 여부를 검토하는 것이 좋다. 이후 세션 리플레이로 판단 오류를 찾고, 워터폴 추적으로 모델·도구·인프라별 지연 시간과 비용을 분석하면 안정성과 효율을 체계적으로 개선할 수 있다.

원문 읽기(새 탭에서 열림)

Cloudflare Workersdurable-objectsopentelemetrywrangler+4

cloudflare·2026년 8월 4일·4분 읽기큐레이션 요약

Astro의 GitHub 이슈를 0개로 만들기 위해 소프트웨어 팩토리를 구축한 방법

AI 에이전트를 소프트웨어 생산 파이프라인처럼 조합하면 오픈소스 이슈 triage를 상당 부분 자동화할 수 있다는 글이다. Astro는 GitHub Actions 안에서 격리된 에이전트들이 이슈 재현·원인 분석·수정·검증을 수행하도록 구성해 열린 이슈를 200개 이상에서 약 30개까지 줄였다. 이 경험은 특정 플랫폼에 종속되지 않는 에이전트 워크플로 프레임워크인 Flue와 재사용 가능한 GitHub Action으로 발전했다. ## 오픈소스 유지보수와 이슈 폭증 - AI 때문에 이슈, pull request, 보안 보고서를 생성하는 비용은 크게 낮아졌다. - 반면 유지보수자가 각 보고서를 읽고 재현하고 검토하는 비용은 증가했다. - 기존의 수동 triage 방식만으로는 늘어나는 입력량을 감당하기 어려워졌다. - Astro 팀은 이슈를 자동으로 닫거나 “issue bankruptcy”를 선언하지 않고, 실제 문제를 해결하는 방향을 택했다. ## 에이전트 스킬로 시작한 자동화 - 첫 자동화 대상은 개발 과정 중 시간이 많이 들고 보상이 적은 이슈 triage였다. - 유지보수자는 로컬 코딩 하네스에서 에이전트 스킬을 개발·테스트한 뒤, 동일한 워크플로를 GitHub Actions에서 실행했다. - 수동 이슈 처리 절차를 다음 단계로 분리했다. - **재현:** 제보자가 제공한 재현용 저장소를 복제하고 문제 발생 여부 확인 - **진단:** 코드에 로깅과 계측을 추가해 근본 원인 파악 - **검증:** 테스트, 주석, 문서를 검토해 실제 버그인지 의도된 동작인지 판단 - **수정:** 재현 사례를 실패하는 단위 테스트로 변환하고 적절한 수정안을 구현 - 각 단계는 서로 격리된 서브에이전트가 담당한다. - 에이전트 간 정보는 `report.md`에 기록해 순차적으로 전달한다. - 단계별 격리는 LLM이 실제 버그가 아닌데도 해결책을 억지로 만들려는 편향을 줄인다. ## GitHub 이슈 라벨 기반 상태 머신 - 자동화 파이프라인은 사실상 이슈 라벨로 구동되는 상태 머신이다. - 새 이슈에는 `triage needed` 라벨이 붙고, 사용자가 수정 사항을 확인하면 `fix verified`로 이동한다. - 별도의 복잡한 내부 상태 저장소 없이, 이슈의 라벨과 기존 댓글을 읽어 현재 상태와 다음 작업을 판단한다. - 수정이 완료되면 다음 작업을 자동 수행한다. - `pkg.pr.new`를 이용해 프리뷰 릴리스 생성 - 분석 결과와 전체 로그를 이슈에 게시 - 제보자가 자신의 프로젝트에서 프리뷰 패치를 설치하도록 안내 - 제보자가 수정 사항을 확인하면 관련 pull request 생성 ## Flue로의 일반화 - 초기에는 GitHub 이슈에 맞춘 시스템처럼 보였지만, 핵심 구조는 플랫폼과 무관한 워크플로였다. - 이벤트를 받고, 격리된 서브에이전트를 순차 실행하며, 추론과 실제 실행 권한을 분리하는 방식은 Slack, cron, webhook 등에도 적용할 수 있다. - 이 구조를 특정 플랫폼이나 모델에 종속되지 않는 런타임으로 확장한 결과가 오픈 프레임워크 **Flue**다. - Flue는 지속적으로 실행 가능한 에이전트와 워크플로를 구축하기 위한 프레임워크를 지향한다. ## 자동화가 커뮤니티에 미친 영향 - 팀은 자동화된 봇 응답이 유지보수자와 사용자 사이를 더 멀어지게 만들 수 있다고 우려했다. - 실제로는 반복적인 이슈 처리에 쓰는 시간이 줄면서 더 가치 있는 커뮤니티 활동에 참여할 수 있었다. - Discord에서 사용자와 직접 소통 - RFC 논의와 신규 기능 요청 검토 - 기여자와 협업해 아이디어를 프레임워크에 통합 - 자동화가 사람과의 소통을 없앤 것이 아니라, 소통의 초점을 더 유용한 논의로 옮겼다는 설명이다. ## 에이전트 실패를 코드베이스 개선 신호로 활용 - 에이전트가 문제를 해결하지 못하면 단순히 모델의 실패로 보지 않고 코드베이스의 결함을 점검한다. - 주요 원인은 다음 세 가지다. - **불투명한 추상화:** 컴포넌트 간 경계가 불명확함 - **부족한 문서화:** 구현 이유와 핵심 로직을 설명하는 주석이 없음 - **불충분한 테스트:** 특히 특정 조건과 회귀 사례를 검증하는 단위 테스트 부족 - HMR 버그 사례에서 에이전트는 특정 `if` 조건을 반복 수정했지만, 다른 곳에 회귀를 일으켰다. - 해당 조건의 의미를 설명하는 주석과 테스트를 추가하자 에이전트는 올바른 설계 의도를 이해하고 잘못된 수정을 반복하지 않게 됐다. - 따라서 에이전트 자동화는 코드 구조, 문서, 테스트 품질을 개선하는 피드백 루프로도 작동한다. ## 독립적인 GitHub Action으로 분리 - 초기 triage 로직은 Astro 모노레포 내부에 직접 들어 있어 변경과 Flue 업그레이드가 어려웠다. - 팀은 이를 `triagebot-action`이라는 독립 저장소로 분리했다. - 분리 후 다음이 가능해졌다. - 자동화 로직의 독립적인 테스트 - 기존 코드베이스에 영향을 주지 않는 안정성 검증 - 여러 프로젝트에서 재사용 - 다른 팀이 그대로 사용하거나 포크해 자체 자동화 공장을 구축 - Astro에서 시작한 이 Action은 다른 팀으로도 확산되고 있다. 실용적으로는 처음부터 모든 개발 과정을 자동화하기보다, 재현·진단·검증처럼 절차가 명확한 좁은 영역부터 시작하는 것이 적절하다. 또한 에이전트의 실패를 숨기기보다 테스트, 문서, 추상화 경계를 개선하는 신호로 활용해야 자동화 품질과 사람 개발자의 생산성을 함께 높일 수 있다.

원문 읽기(새 탭에서 열림)

AI 에이전트오픈 소스GitHub Actionsastro+4

cloudflare·2026년 8월 4일·3분 읽기큐레이션 요약

Cloudflare Wallets 출시: 에이전트 기반 인터넷을 위한 프로그래밍 가능한 지갑

AI 에이전트는 현재 인간용 로그인, 결제수단 등록, API 키 발급 절차 때문에 새로운 API를 탐색하고 비교하기 어렵다. Cloudflare Wallets는 계정 지갑과 에이전트용 가상 지갑을 제공해, 에이전트가 x402 기반 스테이블코인 소액결제로 API·콘텐츠·MCP 도구를 직접 구매하도록 한다. 예산 한도와 허용 목록 같은 통제 장치를 통해 자율적인 탐색과 안전한 지출을 동시에实现하는 것이 핵심이다. ## 에이전트 온보딩의 문제 - 에이전트는 서비스 가입에 사용할 안정적인 식별자가 없다. - 인간 중심의 로그인·결제·API 키 발급 과정을 스스로 처리하기 어렵다. - 결제수단 등록이나 가입 승인을 인간에게 요청해야 하므로, 여러 API를 빠르게 시험하고 비교하기 어렵다. - 이러한 마찰은 에이전트가 서비스를 구매·활용하는 에이전틱 커머스의 성장을 제한한다. ## Cloudflare Wallets와 x402 결제 - 사용자는 Cloudflare 계정에 연결된 고유한 Wallet 핸들을 만들 수 있다. - 지갑에는 스테이블코인을 보관하고 웹 전반의 서비스 구매 및 자금 수령에 사용할 수 있다. - Cloudflare의 Monetization Gateway는 웹사이트와 애플리케이션이 x402 프로토콜 기반 소액결제를 받을 수 있도록 한다. - x402는 HTTP 요청에 결제를 연결해 API 호출, AI 추론, 데이터, 콘텐츠 사용량 등에 따라 자동 결제할 수 있게 한다. - x402 호환 서비스를 구매하거나 판매하려면 지갑이 필요하다. ## 계정 지갑과 가상 지갑 - **Account Wallet** - 사람이 소유하고 관리하는 기본 지갑이다. - 자금을 충전하고, 에이전트에게 지출 권한을 위임한다. - 필요할 때 자금을 회수하거나 지출 정책을 변경할 수 있다. - **Virtual Wallet** - 에이전트 전용 지갑으로 API 키를 통해 작동한다. - 에이전트는 허용된 범위 안에서 API, MCP 도구, 콘텐츠 등을 구매할 수 있다. - 지출 한도는 Account Wallet 소유자가 설정한 상한을 넘을 수 없다. - 인간의 매번 승인을 요구하지 않으면서도 과도한 지출을 방지한다. ## 제한된 예산이 제공하는 자율성 - 에이전트는 적은 비용으로 수십~수백 개의 서비스를 직접 시험하고 용도에 맞는 API를 선택할 수 있다. - 예를 들어 API 호출 비용이 몇 센트라면, 10달러의 예산만으로도 다양한 후보를 충분히 평가할 수 있다. - Virtual Wallet에 다음과 같은 정책을 설정할 수 있다. - 총 허용량 - 서비스 허용 목록 - 거래당 최대 금액 - 주간 또는 사용자별 예산 - 예산 초과 시 승인된 관리자가 수동으로 한도를 늘리거나 일회성 자금을 추가할 수 있다. - 비정상적으로 빠른 지출이 발생하면 관리자가 검토할 수 있으며, 의도된 지출이면 승인하고 그렇지 않으면 정책의 제한으로 손실을 줄인다. - 초기에는 지원 지역에서 법정화폐 기반 입출금을 제공하고, 일부 사용자는 스테이블코인으로 직접 자금을 충전할 수 있다. ## 에이전트 정체성과 귀속 - 결제 권한을 위임해도 상점은 해당 에이전트가 어떤 개인이나 조직을 대신하는지 알기 어려울 수 있다. - 이 때문에 무료 체험, 가입 크레딧, 조직별 혜택을 에이전트에게 적용하기 어렵다. - Cloudflare는 지갑을 Cloudflare 계정과 연결하고 `cloudflare.pay` 식별자를 제공하려 한다. - 예를 들어 `research.example.cloudflare.pay`처럼 특정 조직에 속한 연구 에이전트임을 나타낼 수 있다. - 식별자 공개는 선택 사항이며, 상점은 알려진 에이전트와의 거래를 우선할지 결정할 수 있다. ## 사람이 읽을 수 있는 에이전트 식별자 - 식별되지 않은 에이전트가 본질적으로 신뢰할 수 없는 것은 아니지만, 추가적인 검증이 필요할 수 있다. - Cloudflare의 Web Bot Auth는 키 쌍을 이용해 에이전트 정체성을 등록하는 기반을 제공한다. - Cloudflare Wallet 식별자는 사람이 읽기 어려운 키 쌍에 기억하기 쉬운 이름을 연결하는 역할을 한다. - 이는 DNS가 사람이 읽는 도메인 이름과 기계적인 IP 주소를 연결하는 방식과 유사하다. - 빠르게 변하는 에이전트 신원 표준에 대응하기 위해, Cloudflare는 복잡한 스키마나 검증 체계를 새로 정의하기보다 단순하고 기억하기 쉬운 식별자 제공에 초점을 둔다. 에이전트가 다양한 서비스를 자율적으로 탐색하게 하려면 결제와 신원 확인이 기계 친화적으로 바뀌어야 한다. 따라서 서비스 제공자는 x402와 Monetization Gateway를 활용하고, 사용자는 Virtual Wallet에 명확한 예산·허용 목록·거래 한도를 설정하는 방식이 현실적인 도입 전략이다.

원문 읽기(새 탭에서 열림)

AI 에이전트agentic-commercestablecoinsx402+4

cloudflare·2026년 8월 4일·4분 읽기큐레이션 요약

Cloudflare가 AI를 활용해 엔지니어링 표준을 시행하는 방법

Cloudflare는 흩어져 있던 엔지니어링 지침을 통합·관리하는 표준 저장소인 **Cloudflare Codex**를 구축했다. Codex는 RFC 형식의 표준을 사람과 AI 에이전트가 작업 시점에 검색하고 적용할 수 있게 하며, 코드 리뷰·기술 설계 검토·사고 보고서 검토 등에 공통으로 활용된다. 도입 후 AI 코드 리뷰어는 약 23만 건의 위반을 발견했고, 그중 약 1만 6천 건의 병합을 차단했다. ## Codex가 필요했던 이유 - Cloudflare의 기존 지침은 공식 문서, 저장소 파일, 채팅 기록, 개인의 경험 등 여러 위치에 분산돼 있었다. - 개발자는 문제 해결보다 관련 지침을 찾는 데 많은 시간을 써야 했다. - 지침을 찾더라도 최신 정보인지, 권위 있는 기준인지, 현재 상황에 적용 가능한지 판단하기 어려웠다. - 조직이 커지면서 모든 표준을 읽고 모든 요구사항을 검토하는 것이 불가능해졌다. - 팀 이동이나 인력 변화로 조직의 지식이 유실되기 쉬웠고, 지침이 일관되게 노출·강제되지 않아 프로젝트 간 품질 편차가 발생했다. ## 도메인과 RFC 기반 거버넌스 - Codex는 아키텍처, 프런트엔드, 컨트롤 플레인, 보안, 신뢰성, TypeScript, Rust 등 여러 도메인으로 나뉜다. - 각 도메인에는 담당자가 있어 문서의 내용·일관성·품질을 관리한다. - 표준은 RFC 2119의 의미에 따라 `SHOULD`와 `MUST` 키워드를 사용한다. - `SHOULD`: 특별한 이유가 없다면 따라야 하는 권고 - `MUST`: 반드시 지켜야 하는 필수 요구사항 - RFC에는 도메인과 상태 같은 메타데이터를 담은 front matter가 포함된다. - 도메인 역량과 관심이 있는 직원은 정해진 형식의 merge request로 RFC를 제안할 수 있다. - 제안서는 점점 더 넓은 범위의 리뷰를 거치며, 도메인 담당자가 최종 승인하면 Codex에 편입되고 Astro 기반 내부 사이트에 게시된다. ## 승인과 강제를 분리한 표준 수명주기 - 승인된 RFC는 Codex 클라이언트와 에이전트가 즉시 읽고 코드·설정·문서의 위반을 탐지하는 데 사용할 수 있다. - 다만 승인 직후부터 병합을 차단하지는 않는다. - RFC가 `approved`에서 `enforced` 상태로 승격된 뒤에야 관련 요구사항이 차단 근거가 된다. - 이 단계 분리를 통해 팀이 새로운 요구사항을 받아들일 시간을 확보하고, 자동화나 예외 처리 등 강제에 필요한 준비도 마칠 수 있다. - 승인된 RFC의 위반은 일반적으로 비차단 권고로 처리되며, 강제 상태 RFC의 `MUST` 위반은 심각도에 따라 승인 보류 또는 병합 차단으로 이어진다. ## LLM을 위한 구조화와 점진적 공개 - 60개가 넘는 RFC 전체를 매번 LLM에 제공하면 컨텍스트 윈도우 부담이 커지고 결과 품질이 떨어질 수 있다. - 이를 해결하기 위해 별도의 에이전트가 RFC에서 `SHOULD`와 `MUST` 문장을 추출해 JSON 구조로 압축한다. - 각 표준 문장에는 다음 정보가 포함된다. - RFC 번호와 제목 - RFC 상태와 도메인 - 적용 수준(`SHOULD` 또는 `MUST`) - 문장이 속한 섹션 - 원문으로 연결되는 링크 - 안정적인 `slug` 식별자 - 에이전트는 우선 관련 표준 문장만 검색하고, 추가 설명이 필요할 때만 RFC 전체 내용을 불러온다. - 안정적인 slug는 RFC가 수정돼도 같은 요구사항을 추적할 수 있게 해 모니터링, 분석, 예외 처리에 활용된다. - 초기에는 간결한 Markdown을 사용했지만, 더 정확한 필터링을 위해 구조화된 JSON으로 전환했다. - 향후에는 설계·구현·런타임 등 소프트웨어 개발 생명주기 단계별 적용 범위도 메타데이터에 포함할 계획이다. ## AI 코드 리뷰 적용 - AI 코드 리뷰어는 merge request를 여러 기준으로 검사하며 Codex 준수 여부도 평가한다. - 리뷰마다 관련 RFC와 추출된 표준 문장을 검색하고, 필요한 경우에만 RFC 본문을 추가로 읽는다. - 대부분의 위반은 압축된 표준 문장만으로도 문제와 근거를 설명할 수 있다. - Codex 도입 이후 약 23만 건의 위반을 발견했다. - 이 중 약 1만 6천 건은 강제 상태 RFC의 `MUST` 요구사항 위반으로 승인 보류를 발생시켰다. ## AI 리뷰를 보완하는 빠른 린터 - AI 리뷰는 코디네이터와 여러 하위 에이전트를 실행하므로 보통 수 분이 걸린다. - 수정 후 다시 리뷰를 받아야 하는 추가 왕복과 대기 시간이 개발자 경험을 저하시킬 수 있다. - Cloudflare는 기계적으로 검증 가능한 언어별 요구사항을 별도 린터 설정 패키지로 제공하는 방식을 마련했다. - 이 린터는 Codex 표준과 정렬되며 문제를 밀리초 단위로 표시할 수 있다. - TypeScript가 첫 번째 대상 언어였고, 동시에 `oxlint`를 표준화하는 방향으로 진행됐다. ## 여러 엔지니어링 단계로의 확장 - Codex는 코드 리뷰에만 한정되지 않는다. - 기술 설계가 구현되기 전에 표준을 검토하는 spec reviewer가 이미 약 600개의 설계를 평가했다. - incident report reviewer 등 사고 분석과 운영 프로세스에도 같은 기준을 적용할 수 있다. - 하나의 관리된 표준 원천을 여러 에이전트가 공유함으로써 설계부터 구현, 운영까지 일관된 엔지니어링 기준을 적용할 수 있다. 새로운 표준은 먼저 `approved` 상태로 도입해 팀의 적응과 자동화 준비 시간을 확보한 뒤, 충분히 검증되면 `enforced`로 승격하는 방식이 실용적이다. 또한 LLM에는 전체 문서를 무작정 제공하기보다, 안정적인 식별자와 메타데이터를 갖춘 핵심 규칙을 먼저 검색하게 하고 필요할 때만 원문을 공개하는 구조가 효과적이다.

원문 읽기(새 탭에서 열림)

대규모 언어 모델TypeScriptRustastro+4