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

Cloudflare는 MCP 트래픽을 어떻게 탐지하고 보안을 강화하는가

AI 에이전트는 기존 사용자보다 훨씬 빠르고 반복적으로 도구를 호출할 수 있어, 한 번의 잘못된 판단이 대규모 권한 오용으로 확산될 수 있다. MCP는 에이전트가 SaaS, 내부 애플리케이션, API의 도구를 호출하게 해주지만, 승인되지 않은 서버로 직접 연결하는 ‘Shadow MCP’가 일반 HTTPS 트래픽처럼 보일 수 있다는 문제가 있다. 따라서 클라이언트·네트워크·MCP 서버의 각 지점에서 호출을 식별하고, 검사하며, 실행 전 차단하는 다층 통제가 필요하다. ## AI 에이전트가 기존 권한 모델을 바꾸는 이유 - 기존 권한 체계는 사용자가 판단하고, 사람의 속도로만 작업한다는 가정에 기반했다. - AI 에이전트는 판단이 비결정적이며, 같은 도구를 피로 없이 반복 호출할 수 있다. - 잘못된 판단 하나가 사람이 알아차리기 전에 수천 건의 잘못된 작업으로 확대될 수 있다. - 에이전트 연결은 한 줄의 설정만으로 가능해, 직원이 승인 여부를 확인하지 않고 MCP 서버를 사용할 위험이 있다. ## MCP 도구 호출의 구조와 보안 신호 MCP 호출은 시스템의 위치에 따라 세 가지 형태로 나타난다. - 클라이언트 내부에서는 특정 도구와 인자를 호출하기로 한 에이전트의 결정이다. - 네트워크에서는 JSON-RPC 메시지를 담은 HTTP 요청이다. - 서버에서는 실제 도구 핸들러를 실행하는 작업으로 변환된다. - 요청에는 다음과 같은 식별 정보가 포함된다. - `Host`, 경로: 대상 서버 식별 - `Authorization`: 호출자 인증 정보 - `MCP-Protocol-Version`: MCP 프로토콜 버전 - `Mcp-Method`: 수행할 작업 - `Mcp-Name`: 호출할 도구 이름 - `id`: 요청과 응답을 연결하는 식별자 - `params`: 도구 인자 - 특히 `params`에는 검색어, 소스 코드, 고객 데이터, 티켓 생성이나 인프라 변경 지시가 포함될 수 있어 가장 민감하다. - 응답에도 도구가 반환한 민감한 데이터가 포함될 수 있으므로 요청뿐 아니라 응답 검사와 로깅도 중요하다. - MCP는 특정 호스트명이나 `/mcp` 경로를 반드시 요구하지 않기 때문에, 승인되지 않은 직접 연결이 일반 HTTPS API 호출처럼 보일 수 있다. ## 클라이언트 내부 통제 - 모델이 도구를 선택한 뒤 실제 요청으로 직렬화하기 전에 서버, 도구 이름, 인자를 검사할 수 있다. - 승인 목록에 없는 서버를 차단할 수 있다. - 민감한 작업에 사용자 확인을 요구할 수 있다. - 요청이 기기를 떠나기 전에 인자에서 민감한 데이터를 제거할 수 있다. - 네트워크를 사용하지 않는 로컬 `stdio` MCP 서버도 통제할 수 있다. - 단점은 사용하는 모든 MCP 클라이언트마다 통제를 별도로 구현해야 한다는 점이다. - 조직이 클라이언트와 기기를 모두 관리할 때 효과적이지만, 단일 클라이언트의 telemetry만으로는 전체 MCP 사용 현황을 파악할 수 없다. ## 네트워크 경계에서의 탐지와 차단 - 보안 웹 게이트웨이는 요청이 클라이언트를 떠난 뒤 HTTP 트래픽을 관찰한다. - TLS 복호화를 적용하면 사용자와 기기, 대상 서버, MCP 관련 헤더를 함께 식별할 수 있다. - 특정 MCP 클라이언트에 의존하지 않고 관리되는 네트워크 경로의 원격 MCP 트래픽을 폭넓게 탐지할 수 있다. - 승인된 MCP Portal을 거치지 않는 직접 연결을 목적지에 도달하기 전에 차단할 수 있다. - DLP 기능을 사용하면 JSON-RPC 메서드와 인자를 검사해 민감한 데이터 전송을 차단하거나 기록할 수 있다. - 다만 로컬 `stdio` 호출이나 조직 네트워크 밖에서 발생한 트래픽은 볼 수 없다. ## MCP 서버에서의 실행 전 통제 - MCP 서버는 호출자를 인증하고, 메시지를 해석하며, 도구와 인자를 검증한 뒤 실행하는 가장 풍부한 실행 컨텍스트를 가진다. - 도구 핸들러가 실행되기 전에 다음 정책을 적용할 수 있다. - 호출자별 도구 권한 확인 - 호출 횟수 제한 - 인자 검사 - 실행 결과와 승인 여부 기록 - 읽기 작업은 허용하되, 쓰기 작업에는 에이전트 식별 정보와 감사 이벤트를 추가할 수 있다. - 중요 작업은 핸들러 실행 전에 차단해야 하며, 실행 후 로그만 남기는 방식으로는 피해를 예방할 수 없다. - Cloudflare의 WriteGuard는 도구별 위험 등급과 활성화 상태를 사용해 읽기·쓰기·중요 작업을 차등 처리한다. - 서버 측 통제는 사용자가 클라이언트를 바꾸거나 로컬 훅을 비활성화해도 우회하기 어렵다. - 단, 해당 통제를 구현한 MCP 서버만 보호할 수 있다는 한계가 있다. ## Cloudflare One과 MCP Portal의 역할 - Cloudflare One은 검사된 MCP 트래픽을 식별하고, 어떤 사용자와 서버가 생성했는지 보여주는 기능을 제공한다. - 관리 네트워크 경로에서 직접 연결을 통제해 승인된 MCP Portal 경로만 사용하도록 강제할 수 있다. - 이를 통해 관리자는 에이전트가 승인된 경로를 이용하는지, 아니면 MCP Portal을 우회해 서버에 직접 연결하는지 확인할 수 있다. - 네트워크 계층은 가장 넓은 범위의 원격 MCP 연결을 감시하고, 클라이언트와 서버 계층은 요청 내용과 실행 맥락을 더 깊이 통제한다. ## 실용적인 권장 방식 MCP 보안은 한 지점에 의존하기보다 다층으로 구성하는 것이 적절하다. 클라이언트에서는 민감한 요청을 사전 확인하고, 네트워크에서는 Shadow MCP와 Portal 우회 연결을 탐지·차단하며, 서버에서는 도구별 권한·위험 등급·속도 제한을 적용해야 한다. 특히 데이터 변경이나 외부 시스템 조작을 수행하는 도구는 반드시 서버에서 실행 전에 검증하고 감사 로그를 남겨야 한다.

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

모델 컨텍스트 프로토콜AI 에이전트access-controldata-loss-prevention+4

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

코더에서 오케스트레이터로: 에이전트가 개발자의 역할을 어떻게 바꾸는가

한 번의 프롬프트로 코드를 만드는 시연과, 코드를 반복적·안전하게 배포하는 시스템을 구축하는 일은 다르다. AI 에이전트 시대의 개발자는 단순히 코드를 작성하는 사람을 넘어, 코드 생성부터 검증·리뷰·배포까지의 흐름을 설계하고 통제하는 ‘오케스트레이터’가 되어야 한다. 에이전트의 유연성과 CI·브랜치 보호·리뷰 같은 결정론적 통제를 결합해야 팀이 신뢰할 수 있는 개발 시스템을 만들 수 있다. ## 일회성 프롬프트에서 반복 가능한 워크플로로 - 한 번의 프롬프트는 빠르게 결과를 만들 수 있지만, 매번 안정적으로 재현되는 산출물을 보장하지는 않는다. - 실제 개발에는 다음 요소가 연결된 워크플로가 필요하다. - 작업을 시작하는 이벤트와 트리거 - 에이전트가 수행할 작업의 범위 - 코드 검증과 보안 검사 - 리뷰 및 승인 절차 - 안전한 병합과 배포를 위한 통제 - 따라서 개발자는 코드뿐 아니라 코드가 제안되고, 검증되고, 리뷰되고, 배포되는 시스템 자체를 설계해야 한다. ## 이벤트 기반 에이전트 흐름 - 익숙한 저장소 이벤트를 에이전트 작업의 시작점으로 활용한다. - 이슈에 특정 라벨 추가 - 예약된 야간 워크플로 실행 - 기타 GitHub 저장소 이벤트 - 이벤트가 GitHub Actions 워크플로를 실행하고, 사전에 범위를 정한 작업을 Copilot 에이전트가 수행한다. - 에이전트가 만든 결과는 풀 리퀘스트에 기록된다. - 이후 자동화된 검증 절차가 결과를 평가한다. - 린트 - 테스트 - 보안 스캔 - 빌드 검증 ## 에이전트의 유연성과 결정론적 통제 - 에이전트는 모호하고 맥락이 많은 작업을 처리하는 데 적합하다. - 반면 다음과 같은 규칙 기반 장치는 예측 가능하고 반복 가능한 품질 신호를 제공한다. - CI 검사 - CODEOWNERS - 필수 리뷰 - 브랜치 보호 규칙 - 브랜치 보호는 검증되지 않은 변경이나 승인되지 않은 병합을 막는다. - 위험도가 높은 변경에는 사람의 판단이 반드시 개입되도록 리뷰 요건을 설정할 수 있다. - 팀이 에이전트를 신뢰하려면 에이전트의 자율성을 무제한으로 허용하기보다, 명확한 결정론적 경계 안에서 운영해야 한다. ## 개발자의 역할 변화 - 개발자는 여전히 코드를 작성하지만, 동시에 다음을 책임진다. - 어떤 이벤트가 에이전트를 실행할지 정의 - 에이전트의 권한과 작업 범위 제한 - 에이전트와 검증·리뷰 단계 사이의 인계 설계 - 사람의 판단이 필요한 지점 결정 - GitHub Copilot은 이러한 자동화와 에이전트 운영을 한곳에서 관리하는 제어 평면 역할을 한다. - Copilot cloud agent 워크플로, GitHub Actions의 Copilot CLI, MCP를 통한 외부 도구·컨텍스트 연동은 같은 성숙 경로에서 선택할 수 있는 구현 방식이다. ## 작은 범위에서 시작하기 - 처음부터 전체 개발 프로세스를 자동화하기보다 범위가 명확하고 위험이 낮은 작업 하나를 선택하는 것이 좋다. - 예시: - 이슈 분류 - 문서와 테스트의 동기화 - 단순 유지보수 변경 - 기존 소프트웨어 개발 인프라에 Copilot을 단계적으로 도입하고, 실제로 필요한 다음 자동화 단계를 확인하며 확장한다. 실용적으로는 에이전트에게 제한된 권한을 부여하고, 모든 변경을 풀 리퀘스트와 자동 검사를 거치게 하는 방식이 적합하다. 즉, AI가 코드를 대신 작성하는 것보다 중요한 것은 사람이 통제 가능한 검증·승인·배포 체계를 설계하는 일이다.

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

모델 컨텍스트 프로토콜AI 에이전트CI/CDgithub-copilot+4

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

에이전트 위크 동안 출시한 모든 것

에이전트는 AI 기능을 넘어 사람과 소프트웨어가 인터넷과 상호작용하는 방식을 바꾸는 새로운 소프트웨어 계층이다. Cloudflare는 Agents Week를 통해 실행 환경, 개발 생명주기, 신원·보안, 에이전트 친화적 인터넷, 관측·검색·AI 인프라를 하나의 플랫폼으로 통합하는 방향을 제시했다. 궁극적으로는 인간과 에이전트가 충돌하지 않고 협력하는 “Agentic Internet”을 구축하는 것이 목표다. ### 에이전트를 위한 실행 환경과 인프라 - 에이전트에는 단순한 컨테이너가 아니라 작업에 맞는 컴퓨터 환경이 필요하다는 관점에서 `@cloudflare/computer` 런타임을 소개했다. - Python과 JavaScript Workers 간 RPC 통신을 지원해 혼합 언어 프로젝트를 쉽게 만들 수 있도록 했다. - Kimi, GLM 같은 대규모 모델을 더 작고 빠르며 안전하게 운영하는 방법을 제시했다. - Billable Usage API로 셀프서비스 제품의 사용량과 비용을 프로그램 방식으로 확인할 수 있다. - Workers와 Containers에서 인바운드 TCP 및 gRPC를 지원해 음성 AI 백엔드와 실시간 에이전트 구축이 가능해졌다. ### 프로토타입에서 운영까지: Agent Development Lifecycle - 기존 SDLC를 확장한 ADLC(Agent Development Lifecycle)를 제안했다. - Cloudflare Agents는 에이전트 실행 과정을 실시간으로 관찰하고, 추적·재생하며, 운영 중 사람의 승인을 받을 수 있게 한다. - 로컬 개발 환경에서도 분산 추적을 활용해 에이전트가 Workers 문제를 직접 찾고 디버깅할 수 있다. - Cloudflare Wallets는 에이전트가 안전하게 거래를 수행할 수 있는 프로그래밍 가능한 지갑을 제공한다. - 코드로 정의하는 CI/CD 파이프라인과 실패를 분석하고 수정안을 검토 단계로 보내는 에이전트를 소개했다. - AI를 활용해 코드 표준과 개발 프로세스를 자동으로 점검하고, Astro의 GitHub 이슈를 분석·분류·라우팅해 유지보수 부담을 줄인 사례도 공유했다. ### 에이전트의 신원과 보안 통제 - Zero Trust를 사용자와 기기뿐 아니라 에이전트에도 적용하는 Agent Access Model을 제시했다. - 에이전트가 사용자를 대신해 리소스와 서비스에 접근할 때, 주체와 권한을 명확히 식별하고 통제하는 것이 핵심이다. - Cloudflare OS는 내부 업무와 시스템에 AI를 통합하되 보안과 감독을 유지하도록 설계된 오픈 플랫폼이다. - 신원 기반 분석으로 AI 활동을 실제 사용자와 시스템에 연결해 이상 행동이나 비용 급증을 감지할 수 있다. - WriteGuard는 MCP 서버의 도구 호출을 세밀하게 제한해 에이전트의 위험한 변경이나 원치 않는 작업을 줄인다. ### 사람이 통제하는 Agentic Internet - Agentic Internet은 웹사이트와 콘텐츠가 에이전트에게 읽히고(readable), 발견되며(discoverable), 호출되고(callable), 결제될 수 있어야 한다는 모델이다. - WebMCP를 통해 웹사이트와 웹 애플리케이션에 에이전트용 인터페이스를 쉽게 추가할 수 있다. - 기존 SEO를 넘어 에이전트가 콘텐츠를 이해하고 답변에 활용하도록 만드는 AEO(Answer Engine Optimization)의 필요성을 강조했다. - Kitesurf는 픽셀 단위의 브라우저 렌더링보다 낮은 메모리·CPU 사용량을 우선한 에이전트 전용 브라우저다. - MCPv2는 MCP 기반 애플리케이션의 배포와 확장을 단순화하는 차세대 규격으로 소개됐다. - Cloudflare AI Search는 파일이나 웹사이트를 한 번의 명령으로 에이전트가 사용할 수 있는 검색 엔진으로 변환한다. ### 실제 인터넷에서의 신뢰와 AI 운영 - 봇을 무조건 악성으로 보거나 사람을 항상 신뢰하는 방식에서 벗어나, 행동을 지속적으로 평가하는 신뢰 모델을 제안했다. - Workers AI와 AI Gateway를 하나의 AI 제어 평면으로 통합해 단일 바인딩, 지갑, 대시보드에서 다양한 AI 모델을 호출하도록 했다. - 향후에는 모델 중심 라우팅을 통해 목적과 비용, 성능에 맞는 모델을 자동 선택할 수 있게 될 전망이다. - Cloudflare Ambassadors와 Community Engineers 프로그램, 2년간 추가 100만 달러 규모의 오픈소스 지원 계획을 발표했다. - Radar Researcher는 자연어 질문을 인터랙티브 차트로 변환해 인터넷 데이터를 탐색하도록 돕는다. Cloudflare가 제시한 Agent Cloud는 실행 계층, ADLC 기반 개발 도구, 신원과 보안 제어, 에이전트 친화적 웹 표준, 관측·검색·AI 운영 도구를 함께 제공하는 형태로 구체화되고 있다. 에이전트를 도입할 때는 모델 성능뿐 아니라 권한 관리, 실행 추적, 사람의 승인 절차, 비용 가시성, 웹 접근 규칙까지 함께 설계하는 것이 실용적인 출발점이다.

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

모델 컨텍스트 프로토콜AI 에이전트CI/CDCloudflare Workers+4

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

Cloudflare AI 검색: 에이전트에게 데이터 검색 엔진을 제공하세요

Cloudflare AI Search는 Workers AI, AI Gateway, Vectorize, R2, Browser Run 등을 직접 조합하지 않아도 에이전트용 검색 엔진을 구축할 수 있도록 개발자 경험을 개선했다. 웹사이트와 파일을 쉽게 색인하고, 여러 데이터 소스를 하나의 검색 엔드포인트나 MCP 엔드포인트로 통합할 수 있으며, 임베딩과 재순위화 비용은 일부 기본 모델 사용 시 무료다. Cloudflare는 이를 자사 문서·블로그·개발자 생태계 검색과 Dev Stack MCP에 실제로 적용하고 있다. ### 에이전트용 데이터 색인 - 구조화·비구조화 데이터를 AI 에이전트가 검색할 수 있도록 색인한다. - 개별 파일뿐 아니라 소유권을 확인할 수 있는 웹사이트도 데이터 소스로 사용할 수 있다. - AI Search가 웹 크롤링, 데이터 수집, 임베딩, 검색 결과 반환 과정을 처리한다. - 현재는 Cloudflare 계정에 등록된 zone이어야 하며, 향후 소유권 확인 방식이 확대될 예정이다. ### 사이트맵 없이 웹사이트 검색 구축 - 기존에는 웹사이트 연동에 sitemap이 필요했다. - 이제 `Discover` 파싱 옵션을 사용하면 sitemap이 없는 사이트도 링크를 따라가며 페이지를 발견하고 색인할 수 있다. - 내부적으로 Browser Run의 `/crawl` 기능을 활용해 페이지를 탐색한다. - Wrangler 명령어 예시는 다음과 같다. ```bash npx wrangler ai-search instance create cloudflare-community \ --namespace dev-stack \ --source https://community.cloudflare.com \ --type web-crawler \ --parse-type discover ``` ### 여러 검색 인스턴스를 하나로 통합 - 하나의 namespace 안에 여러 웹사이트나 데이터 인스턴스를 구성할 수 있다. - `/search`와 `/mcp` 공개 엔드포인트를 활성화하면 여러 인스턴스를 한 번에 검색할 수 있다. - 별도 Worker를 작성하지 않고도 여러 소스를 대상으로 통합 검색을 제공할 수 있다. - 검색 결과에는 출처 인스턴스 정보와 인용 가능한 청크가 포함된다. ### Worker와 MCP를 통한 검색 연동 - 기존 애플리케이션이나 MCP 서버에 검색 기능을 포함하려면 namespace를 Worker에 바인딩한다. - Worker에서는 `AI_SEARCH.search()`를 호출하고, `instance_ids`로 검색 대상들을 지정한다. - `max_num_results`로 결과 수를 제한하고 `reranking.enabled`로 재순위화를 활성화할 수 있다. - Cloudflare Dev Stack MCP는 이 방식을 사용해 Docs, Blog, API Docs, Community, Astro, Vite, Vitest, Hono, Replicate, OpenNext 등 여러 표면을 한 번에 검색한다. ```json { "ai_search_namespaces": [ { "binding": "AI_SEARCH", "namespace": "cloudflare-stack" } ] } ``` - 간단히 공유 가능한 검색 URL만 필요하다면 Worker 대신 공개 엔드포인트를 활성화하면 된다. ### 공개 엔드포인트와 사용자 도메인 - namespace에 공개 URL을 활성화하면 다음 엔드포인트가 제공된다. - `/search`: 일반 검색 API - `/mcp`: MCP 클라이언트와 에이전트 연동용 엔드포인트 - 기본 공개 URL 대신 `search.example.com/mcp`처럼 사용자 정의 도메인을 연결할 수 있다. - Cloudflare Access를 도메인 앞에 배치하면 공개 엔드포인트를 인증 기반의 비공개 검색 서비스로 전환할 수 있다. ### 예측 가능한 가격 모델 - AI Search는 임베딩 및 재순위화 비용을 포함하는 방향으로 가격 모델을 설계했다. - Workers AI 카탈로그의 일부 기본 모델을 사용하면 임베딩과 재순위화가 무료다. - 토큰 수를 직접 계산해 비용을 예측해야 하는 부담을 줄이고, 데이터 규모가 커져도 비용을 예측하기 쉽게 만드는 것이 목표다. - 가격은 현재 프리뷰 단계다. ### EmDash와 Cloudflare 서비스에 적용 - Cloudflare의 오픈소스 CMS인 EmDash에는 AI Search 플러그인을 추가할 수 있다. - 이 플러그인은 EmDash로 구축한 사이트 콘텐츠에 의미 기반 검색을 제공한다. - Cloudflare는 AI Search를 Blog, Developer Docs, Cloudflare.com, EmDash 기반 사이트 등에 실제 검색 기능으로 사용하고 있다. ### Cloudflare Dev Stack MCP 사례 - Dev Stack MCP는 Cloudflare 개발자 생태계 전체에서 최신 문서를 검색해 코딩 에이전트에 제공한다. - 검색 결과에 출처와 인용 정보가 포함되어 최신 기능과 수정 사항을 반영할 수 있다. - 기존처럼 웹 검색 후 여러 페이지를 직접 가져오는 방식보다 빠르고, 토큰 사용량이 적으며, 오래되거나 부정확한 문서를 선택할 가능성이 낮다. - MCP 설정에 다음 URL을 추가하면 에이전트에서 사용할 수 있다. ```json { "mcpServers": { "dev-stack": { "url": "https://stack.mcp.cloudflare.com/mcp" } } } ``` Cloudflare AI Search는 여러 Cloudflare 서비스를 직접 연결해야 했던 검색 구축 과정을 단순화하고, 웹사이트·문서·MCP를 하나의 검색 계층으로 묶는 데 초점을 둔다. 기존 애플리케이션에 통합하려면 Worker 방식을, 빠르게 공유 가능한 검색 기능이 필요하면 공개 `/search` 또는 `/mcp` 엔드포인트를 선택하는 것이 적합하다.

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

모델 컨텍스트 프로토콜Cloudflare Workersembeddingscloudflare-access+4

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

순위에서 추천으로: AI 에이전트 시대에 성공할 수 있도록 사이트를 준비하세요

AI 에이전트가 검색엔진을 대신해 고객의 질문에 답하고 제품·서비스를 추천하는 시대가 오면서, 웹사이트의 발견 가능성은 검색 순위뿐 아니라 에이전트가 사이트를 읽고 신뢰하며 추천할 수 있는지에 달려 있다. Cloudflare는 이를 위해 에이전트가 사이트를 실제로 이용할 수 있는지 점검하는 **Agent Readiness Diagnostics**와, AI 답변에서 브랜드가 얼마나 추천·인용되는지 측정하는 **AEO** 도구를 제공한다. 앞으로는 사람이 읽기 좋은 사이트를 넘어, 에이전트가 쉽게 찾고 읽고 호출할 수 있는 사이트가 경쟁력을 갖게 된다. ## 에이전트 중심으로 바뀌는 웹사이트 발견 방식 - 고객은 검색 결과 페이지보다 AI 어시스턴트에게 직접 질문하고 추천을 받을 가능성이 커지고 있다. - HTML 페이지 요청 중 인간이 직접 발생시키는 요청은 절반 이하이며, 나머지에는 크롤러·자동화 도구·AI 에이전트 등이 포함된다. - 기존의 클릭 수와 페이지뷰만으로는 다음을 알기 어렵다. - AI 에이전트가 사이트에 접근하고 콘텐츠를 사용할 수 있는지 - AI 답변에서 경쟁사 대신 자사 브랜드가 추천되는지 - 에이전트에게 중요한 사이트의 조건은 다음과 같다. - 쉽게 발견될 것 - 기계가 읽기 쉬울 것 - 정보의 출처와 신뢰성이 명확할 것 - 필요한 경우 API나 도구를 통해 직접 작업할 수 있을 것 ## Agent Readiness Diagnostics: 에이전트가 사이트를 사용할 수 있는가 Diagnostics는 사람이 브라우저로 접속하는 방식이 아니라, 에이전트가 사이트를 해석하는 방식으로 기술 상태를 점검한다. - 주요 점검 대상 - `robots.txt` 접근 규칙 - XML 사이트맵 - HTTP 응답 헤더 - 에이전트용 Markdown 콘텐츠 - 인증 및 도구 사용을 위한 공개 메타데이터 - 결과는 “Not Ready”부터 완전한 에이전트 네이티브 상태까지 하나의 준비도 화면으로 통합된다. - 각 항목은 다음 정보를 제공한다. - 통과, 실패, 중립 상태 - 해당 검사가 중요한 이유 - 실제 요청과 응답을 확인할 수 있는 증거 - 개선 항목은 구현 난이도와 우선순위에 따라 나뉜다. ### 빠른 개선 항목 - 크롤러가 읽을 수 있는 `robots.txt` - XML 사이트맵 - AI 크롤러를 위한 접근 규칙 - 에이전트가 처리하기 쉬운 정제된 Markdown 콘텐츠 ### 기술적 기반 - 콘텐츠를 어떤 방식으로 사용해도 되는지 선언하는 Content Signals - API 카탈로그 - 링크 헤더 - 에이전트 로그인 지침 ### 고급 에이전트 통합 - OAuth 검색·발견 기능 - MCP(Model Context Protocol) - A2A(Agent2Agent) 에이전트 카드 - skills index - Web Bot Auth - WebMCP ### 에이전트 상거래 - x402: HTTP 402 Payment Required를 확장한 결제 표준 - ACP(Agent Commerce Protocol) - UCP(Universal Commerce Protocol) - AP2(Agent Payments Protocol) 상거래 관련 항목은 현재 정보 제공 목적이며 준비도 점수에는 포함되지 않는다. ## 진단 결과를 실제 개선으로 연결하는 방식 - Cloudflare 기능으로 해결할 수 있는 문제에는 바로 설정 화면으로 이동하는 “Set up in Cloudflare” 링크가 제공된다. - 예: 에이전트용 Markdown 활성화 - 관리형 `robots.txt` 설정 - 별도 개발이 필요한 경우 “Copy Agent Prompt” 버튼으로 코딩 에이전트에 전달할 구현 지침을 생성할 수 있다. - 변경 후 다시 스캔해 해결 여부를 확인하고, 통과한 항목을 즉시 확인할 수 있다. ## AEO: AI 어시스턴트가 브랜드를 추천하는가 AEO는 사이트를 읽을 수 있는지에서 더 나아가, 실제 고객 질문에 AI가 해당 브랜드를 추천하는지를 측정한다. - Cloudflare는 사이트에서 산업과 카테고리를 추론한다. - 예: 건강·피트니스 산업 - 예: 스포츠 의류 카테고리 - 이후 Claude와 GPT 같은 주요 AI 어시스턴트에 실제 고객이 할 법한 질문을 입력한다. - 질문 유형은 다음을 포함한다. - 제품·서비스 추천 - 경쟁 제품 비교 - 카테고리 전반에 대한 조언 - 특정 브랜드를 질문에 직접 넣지 않고, 자연스러운 시장 탐색 상황에서 어떤 사이트와 브랜드가 선택되는지 측정한다. ## AEO에서 사용하는 주요 지표 - **Citation Rate** - 해당 카테고리의 AI 답변 중 자사 사이트가 출처로 인용된 비율 - **Prominence** - 인용된 경우 답변의 얼마나 앞부분에 등장하는지 - 답변 내용 중 자사 사이트에 얼마나 많은 비중이 귀속되는지 - **Mention Rate** - 출처 링크 여부와 관계없이 답변에서 브랜드명이 언급되는 비율 - 언급률은 높지만 인용률이 낮다면 브랜드 인지도는 있으나 신뢰할 만한 출처로 인정받지는 못하고 있다는 뜻이다. - **Share of Voice** - 경쟁사 대비 자사가 차지하는 인용 비중 - 어떤 질문에서 경쟁사에 밀리는지 파악할 수 있다. - **Industry Fit** - AI가 해당 사이트를 실제 경쟁사들과 함께 인식하는 정도를 나타내는 점수 ## 카테고리별 벤치마크와 사전 계산 - Cloudflare는 산업·카테고리별로 브랜드를 지정하지 않은 질문을 AI에 먼저 질의한다. - 이 과정에서 다음 정보를 수집한다. - 어떤 사이트가 인용되는지 - 답변에서 어느 위치에 등장하는지 - 얼마나 큰 비중으로 다뤄지는지 - 카테고리별 기준 데이터를 한 번 구축한 뒤 여러 계정에서 재사용한다. - 이 방식의 장점 - 매번 AI 모델을 다시 호출하지 않아 결과가 즉시 표시된다. - 수천 개 사이트가 같은 질문을 반복하는 데 따른 컴퓨팅 비용을 줄인다. - 동일 시장에서 함께 등장하는 브랜드를 파악해 Industry Fit을 계산할 수 있다. ## AI 답변의 변동성을 반영한 평가 방식 - AI는 같은 질문에도 매번 완전히 동일한 답변을 생성하지 않는다. - 이를 보완하기 위해 Cloudflare AI Gateway를 사용해 여러 모델과 여러 번의 질의를 수행한다. - 평가 대상은 단순한 브랜드 언급이 아니다. - 사이트가 출처로 인용됐는지 - 인용이 답변의 앞부분에 나오는지 - 답변의 실질적인 내용이 사이트에 얼마나 귀속되는지 - Workers AI가 답변을 분석하고 점수를 계산한다. - 모델이 자기 답변을 다시 평가하는 방식이 아니라, 응답 텍스트와 출처를 대상으로 정확한 텍스트 분석을 함께 사용한다. - 따라서 직접 다중 모델 평가 시스템을 구축하지 않아도 실행 가능한 AEO 지표를 얻을 수 있다. ## AI Operator Activity로 실제 유입과 오류 확인 - AI Operator Activity는 실제 운영자별 크롤링 및 추천 트래픽을 보여준다. - 확인 가능한 정보 - OpenAI, Google 등 어떤 운영자가 사이트를 읽는지 - 어떤 운영자가 방문자를 사이트로 보내는지 - 크롤링·추천 과정에서 발생한 오류 - `403`: 접근 차단 - `404`: 잘못되거나 사라진 링크 - 이를 통해 AI가 사이트를 발견하지 못하는 문제와, 발견했지만 접근·탐색 과정에서 실패하는 문제를 구분할 수 있다. 사이트 운영자는 먼저 `robots.txt`, 사이트맵, Markdown 콘텐츠 같은 기본적인 기계 가독성을 확보한 뒤, API·OAuth·MCP 등 직접 실행 가능한 인터페이스를 추가하는 것이 좋다. 이후 AEO 지표를 통해 인용률과 경쟁사 대비 점유율을 지속적으로 추적해야 하며, 단순히 AI 봇 방문 수를 늘리는 것보다 실제 추천과 출처 인용으로 이어지는 구조를 만드는 데 집중해야 한다.

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

모델 컨텍스트 프로토콜cloudflareoauthai-gateway+4

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

MCP의 차세대 기술

지난 1년 반 동안 MCP는 에이전트와 외부 서비스를 연결하는 표준이 되었지만, 기존에는 세션과 연결 상태를 유지해야 해 원격 서버 운영이 복잡했다. 2026-07-28 사양부터 MCP는 완전한 무상태 프로토콜로 바뀌어, 서버가 세션을 저장하거나 sticky session·장기 스트림을 관리하지 않아도 된다. 그 결과 MCP 서버는 Cloudflare Workers 같은 요청 단위 인프라에서 더 저렴하고 간단하게 운영할 수 있다. ## MCP의 무상태 전환 - 기존 MCP는 `initialize`와 `initialized` 교환으로 세션을 만들고, 서버가 `Mcp-Session-Id`를 발급했다. - 이후 모든 요청은 해당 세션의 상태를 찾아야 했기 때문에 다음과 같은 운영 부담이 발생했다. - 오토스케일링 환경에서 세션 보존 - sticky session을 통한 요청 라우팅 - 배포 시 세션 drain 또는 migration - 인스턴스 장애 시 재연결 및 세션 복구 - 새 사양에서는 필수 handshake와 `Mcp-Session-Id`, 프로토콜 세션이 제거됐다. - 각 요청이 MCP 버전, 클라이언트 식별 정보, 클라이언트 capability를 직접 포함한다. - 서버 정보를 미리 확인해야 하는 경우에만 선택적으로 `server/discover`를 호출한다. - MCP 자체에 상태가 필요하지 않으므로 기존 `McpAgent` 없이도 서버를 구현할 수 있다. - 애플리케이션 자체에 상태가 필요할 때는 Durable Objects를 사용할 수 있지만, MCP 프로토콜만 제공하는 서버는 Cloudflare Workers처럼 요청 단위 인프라에서 실행할 수 있다. - Cloudflare SDK에서는 기존 `McpAgent` 대신 `createMcpHandler`로 새 무상태 사양을 지원한다. ## 장기 연결이 필요 없는 Elicitation - Elicitation은 서버가 작업을 완료하기 전에 사용자 입력이나 승인을 요청하는 기능이다. - 운영 배포 승인 - 디자인 색상 선택 - 환불 확인 - 기존에는 `elicitation/create`가 열린 스트림에 의존했다. - 이 방식은 스트림 유지, 타임아웃, 비용, 로드 밸런싱을 복잡하게 만들었다. - 새 사양은 Multi Round-Trip Requests(MRTR)를 사용한다. - 서버가 `input_required` 결과를 반환한다. - 클라이언트가 사용자 입력을 수집한다. - 클라이언트가 입력값과 함께 작업을 재시도한다. - 서버가 작업을 완료한다. - 요청 사이에 연결이나 transport session을 보존할 필요가 없다. - 기존 Elicitation 방식과 호환되지 않는 breaking change이지만, 구현과 운영은 훨씬 단순해진다. ## HTTP 인프라가 MCP 요청을 직접 이해 - 기존에는 MCP 요청의 메서드와 대상이 JSON-RPC 본문 안에만 있어, 게이트웨이가 내용을 파싱해야 했다. - 새 Streamable HTTP 요청에는 다음 헤더가 필수로 추가된다. - `Mcp-Protocol-Version` - `Mcp-Method` - `Mcp-Name` - 예를 들어 도구 호출은 `Mcp-Method: tools/call`, `Mcp-Name: search`로 표현할 수 있다. - 게이트웨이, rate limiter, WAF가 JSON 본문을 해석하지 않고도 요청 종류별 정책을 적용할 수 있다. - 도구별 metrics 수집, 메서드별 rate limit, 보안 규칙 적용도 기존 HTTP 인프라 방식으로 처리할 수 있다. ## 캐시와 도구 목록 개선 - `tools/list`, `prompts/list`, `resources/list`, `resources/read` 결과에 다음 힌트가 추가된다. - `ttlMs`: 결과를 얼마나 오래 캐시할 수 있는지 나타냄 - `cacheScope`: 캐시 적용 범위를 나타냄 - 도구 카탈로그는 결정론적으로 정렬된다. - 클라이언트가 연결이 끊겼다가 다시 연결되어도 카탈로그를 재사용하기 쉬워진다. - upstream prompt cache가 불필요하게 무효화되는 문제도 줄일 수 있다. ## 인증 체계의 변화 - 새 사양은 MCP 인증 방식의 우선순위를 정비한다. - 서버와 클라이언트 사이에 사전 관계가 있다면 사전 등록된 클라이언트를 우선 사용한다. - 동적 등록이 필요하면 Client ID Metadata Documents(CIMD)를 사용한다. - Dynamic Client Registration(DCR)은 최후의 수단으로 남지만, 신규 구현에서는 deprecated되었다. ## 실용적인 결론 새 MCP 서버는 세션 저장소나 장기 연결을 기본 전제로 설계할 필요가 없다. 단순한 도구·프롬프트·리소스 서버라면 `createMcpHandler`와 요청 단위 실행 환경을 사용하고, 애플리케이션 자체에 지속 상태나 실시간 협업이 필요할 때만 Durable Objects 같은 상태ful 인프라를 선택하는 것이 권장된다.

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

모델 컨텍스트 프로토콜Cloudflare Workersdurable-objectsjson-rpc+2

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 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분 읽기큐레이션 요약

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 에이전트gitlabTypeScript+4

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

Billable Usage API 소개: Cloudflare 비용을 프로그래밍 방식으로 확인하기

에이전트가 코드를 작성하고 Cloudflare 리소스를 배포·관리하면서, 자동화된 비용 가시성의 필요성이 커지고 있다. Cloudflare는 이를 위해 계정별 제품·서비스 기간별 사용량과 비용을 제공하는 Billable Usage API를 출시했다. 이 API는 FOCUS 표준과 유사한 필드 구조를 사용해 FinOps 도구나 다른 자동화 시스템에서 Cloudflare 비용을 쉽게 통합하도록 설계됐다. ## 자동화를 위한 Cloudflare Billable Usage API - 셀프서비스 계정에서 단일 API 엔드포인트로 사용량과 비용을 조회할 수 있다. - 지원 제품에는 다음이 포함된다. - Workers - R2 - D1 - Workers AI - Vectorize - Images - Stream - 기본 요청 예시: ```bash curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/billable-usage" \ -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" ``` - `from`, `to` 파라미터로 조회 기간을 지정할 수 있다. - 현재 데이터는 일 단위로 갱신되며, 향후 더 실시간에 가까운 데이터 제공을 목표로 한다. - 응답은 HTTP 200과 JSON 형식이며, Cloudflare 표준 API 구조인 `result`, `success`, `errors`, `messages`를 사용한다. ## 응답 데이터의 구성 각 응답 행은 계정 내 특정 제품의 하나의 과금 기간을 나타낸다. - `ServiceName`, `ServiceFamilyName` - 제품명과 제품군을 표시한다. - 예: `Workers Standard`와 `Workers` - `ChargePeriodStart`, `ChargePeriodEnd` - 해당 행이 포함하는 사용량·과금 기간이다. - `PricingQuantity`, `ConsumedUnit` - 과금 기준으로 측정된 사용량과 단위다. - 예: GB-months, GB-seconds, 요청 수 등 - `ContractedCost`, `BillingCurrency` - 해당 기간의 비용과 통화다. - `CumulatedPricingQuantity`, `CumulatedContractedCost` - 청구 기간 동안 누적된 사용량과 비용이다. - `ZoneId`, `ZoneName` - 특정 Cloudflare Zone에 귀속되는 사용량인 경우 제공된다. - 응답에는 `BillingPeriodStart`도 포함될 수 있어 전체 청구 기간을 확인할 수 있다. ## FOCUS 표준과의 호환성 Cloudflare는 여러 클라우드·SaaS 제공업체와 비용 관리 도구가 사용하는 FOCUS(Open Cost and Usage Specification)와 유사한 필드명을 채택했다. - `BillingCurrency`, `BillingPeriodStart` - `ChargePeriodStart`, `ChargePeriodEnd` - `ServiceName` - `ConsumedQuantity`, `ConsumedUnit` - `PricingQuantity` - `ContractedCost` 다만 현재 API가 FOCUS 전체 사양을 완전히 준수하는 것은 아니다. - `ServiceFamilyName`은 FOCUS의 `ServiceCategory`와 비슷하지만 Cloudflare 고유의 제품군 분류다. - `ZoneId`, `ZoneName`은 FOCUS의 `ResourceId`, `ResourceName`과 유사한 역할을 한다. - `CumulatedContractedCost`는 편의상 제공되는 누적 필드이며, FOCUS에서는 일반적으로 쿼리로 계산한다. - FOCUS에서 요구하는 일부 컬럼은 아직 제공되지 않으며, 완전한 준수는 향후 로드맵에 포함돼 있다. ## Vantage를 통한 멀티 클라우드 비용 관리 Cloudflare는 인프라 비용 관리 플랫폼 Vantage와 네이티브 통합을 제공한다. - Billing Read 권한이 있는 읽기 전용 API 토큰으로 Cloudflare를 연결한다. - Vantage는 Billable Usage 데이터를 매일 가져와 다음 기준으로 비용을 분류한다. - 제품 - Zone - 계정 - AWS, Azure 등 다른 클라우드 비용과 Cloudflare 비용을 하나의 보고서에서 비교할 수 있다. - 지원되는 활용 사례: - 팀·제품별 비용 할당 - Workers나 R2 비용 증가에 대한 이상 탐지 - Slack·이메일 기반 비용 알림 - FinOps 에이전트와 MCP를 통한 자연어 비용 조회 - 수동 내보내기나 청구서 업로드 없이 기존 Cost Reports, Budgets, Cost Alerts에 Cloudflare 비용을 포함할 수 있다. ## 에이전트 시대의 비용 가시성 - 에이전트는 코드 작성뿐 아니라 Workers 배포, R2 버킷 생성, D1 데이터베이스 관리까지 수행한다. - 프로그램에 Cloudflare 계정 접근 권한을 부여할수록, 프로그램이 발생시키는 비용을 API로 추적할 필요도 커진다. - 대시보드는 사람이 확인하기에는 적합하지만, 자동화·에이전트·FinOps 시스템이 처리하기에는 구조화된 API가 더 적합하다. - 이번 API는 Cloudflare 사용량을 다른 클라우드 비용 데이터와 함께 분석하기 위한 기반이다. 실무에서는 읽기 전용 Billing 권한의 API 토큰을 사용해 일일 비용 데이터를 수집하고, 제품·Zone·팀 단위로 예산과 알림을 설정하는 것이 권장된다. FOCUS 기반 도구를 사용한다면 현재 필드로 통합을 시작하되, 아직 완전한 FOCUS 준수 단계는 아니라는 점을 고려해야 한다.

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

모델 컨텍스트 프로토콜cloudflareCloudflare Workersfinops+3

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

Claude와 GitLab으로 모든 커밋을 프로덕션까지 안전하게 배포하세요

Claude은 코딩 세션 중 취약점을 발견하고 수정하는 데 유용하지만, 커밋 이후의 병합·의존성·인프라 변경·감사까지 대체할 수는 없다. 글은 Claude Security와 GitLab을 연계해 작성 단계부터 프로덕션 배포까지 보안 검사를 지속하고, 정책을 강제하며, 감사 증거를 자동으로 남기는 방식을 제안한다. Claude가 작성 시점을 담당하고 GitLab이 이후 전체 소프트웨어 공급망을 관리하는 구조다. ## 세션 내 보안 점검에서 강제 가능한 정책으로 - Claude 보안 가이던스 플러그인은 개발자의 코딩 세션 안에서 취약점을 빠르게 찾아 수정하도록 돕는다. - 코드가 세션 밖으로 나간 뒤에는 보안팀이 어떤 검사가 수행됐는지 확인하고 후속 작업을 통제해야 한다. - GitLab 보안 구성 프로필을 사용하면 저장소 외부에서 필요한 스캔을 정의하고 여러 프로젝트와 파이프라인에 일괄 적용할 수 있다. - 병합 요청 승인 정책으로 변경을 작성한 에이전트나 해당 에이전트를 사용한 개발자가 자신의 코드를 직접 승인·병합하지 못하게 할 수 있다. - 해결되지 않은 치명적 취약점이 있는 병합 요청은 지정된 승인자가 승인할 때까지 차단된다. - 취약점 보고서와 보안 대시보드에서 각 취약점이 발견·무시·해결된 상태와 사유를 추적할 수 있다. ## 자동화된 감사 증거와 변경 이력 - SOC 2, PCI DSS, FedRAMP 같은 규정은 에이전트가 작성한 변경도 테스트·검토·승인됐다는 증거를 요구한다. - GitLab은 모든 병합 요청에서 스캔이 실행되도록 보장하고, 결과를 병합 요청과 취약점 보고서에 표시한다. - 파이프라인 로그, 승인 기록, 감사 이벤트를 통해 어떤 변경을 누가 또는 어떤 에이전트가 처리했는지 재현할 수 있다. - 규정 프레임워크별 요구사항에 보안 통제를 매핑할 수 있으며, 각 통제의 통과·대기·실패 상태를 보고서에서 확인할 수 있다. ## 모델로 전송되는 민감 데이터 통제 - 컨텍스트 제외 기능으로 인증 정보, 민감한 파일, 독점 로직, 규제 데이터를 모델에 보내지 않도록 설정할 수 있다. - 자체 관리 환경과 자체 호스팅 모델을 사용하면 코드와 추론 데이터를 조직 경계 안에 둘 수 있다. - 흐름별 허용 모델을 지정하고, 코드가 모델 학습에 사용되지 않도록 제한할 수 있다. - GitLab Duo의 프롬프트 가드레일은 모델에 전달되기 전 코드 제안에서 비밀정보를 탐지한다. - 프롬프트가 접근할 수 있는 콘텐츠를 제한해 프롬프트 인젝션 위험도 줄인다. ## 세션 단위 검사를 넘어선 전체 생명주기 보안 - 세션 기반 검사는 해당 시점의 코드만 다루므로, 이후 공개되는 의존성 취약점이나 이미 커밋된 비밀정보까지 발견하지 못할 수 있다. - GitLab은 다음 영역을 독립적으로 검사한다. - 의존성 취약점 - 컨테이너 이미지 - 인프라스트럭처 코드 - 비밀정보 유출 - 실행 중 애플리케이션에 대한 DAST - 결정론적 스캐너는 동일 코드에 대해 일관된 결과와 CWE 매핑을 제공해 감사에 적합하다. - 반면 비즈니스 로직 오류, 잘못된 권한 검사, 경쟁 조건처럼 일반 스캐너가 놓치기 쉬운 문제는 Security Review Flow가 코드의 의도를 분석해 보완한다. - 글은 Claude의 보안 검사를 인간 코드 리뷰와 다양한 보안 스캐너를 대체하는 수단이 아니라 보조 수단으로 규정한다. ## 사람과 에이전트에 동일한 보안 가드레일 적용 - Claude 플러그인은 Claude가 세션에서 작성·커밋한 코드에 집중한다. - 개발자가 셸에서 직접 작성하거나 세션 내 `!` 셸 이스케이프를 통해 실행한 변경은 플러그인 검토 범위를 벗어날 수 있다. - Claude Security는 개발자나 관리자가 필요할 때 전체 코드베이스 또는 사람이 작성한 코드도 검사할 수 있다. - GitLab의 스캔 실행 정책과 병합 승인 정책은 파이프라인에서 모든 변경에 적용된다. - 따라서 코드 작성자가 사람인지 에이전트인지, 개발자가 별도로 검사를 실행했는지에 관계없이 동일한 통제를 적용할 수 있다. ## 프로덕션에 도달하는 변경 통제 - Claude Security와 GitLab MCP 서버를 연결하면 기존 Claude 기반 개발 흐름을 유지하면서 GitLab의 정책·스캔·감사 기능을 활용할 수 있다. - 모든 기본 브랜치와 대상 프로젝트에 보안 스캔을 강제해 정책 우회를 어렵게 만든다. - 치명적 취약점, 미승인 변경, 누락된 검사 결과가 있는 코드는 배포 전에 차단할 수 있다. - 결과적으로 세션 안의 빠른 AI 보안 지원과 프로덕션 배포 전의 조직 차원 거버넌스를 하나의 흐름으로 결합한다. 실무에서는 Claude를 개발 중 취약점 탐지와 수정에 활용하되, GitLab에서 SAST·의존성·컨테이너·IaC·비밀정보·DAST 스캔과 승인 정책을 중앙 관리하는 구성이 권장된다. 특히 모델에 전송되는 파일을 사전에 제외하고, 에이전트와 사람 모두에게 동일한 승인·감사 규칙을 적용해야 한다.

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

모델 컨텍스트 프로토콜gitlabinfrastructure-as-codesast+4

line·2026년 7월 31일·5분 읽기큐레이션 요약

Grafana에서 자연어로 장애 원인을 분석하기: LLM 에이전트 기반 SRELens 개발기

관측성 데이터가 메트릭·로그·트레이스·프로파일별로 분산되면, 장애 원인을 파악하기 위해 사람이 여러 도구를 오가며 맥락을 연결해야 합니다. LY Corporation의 Home SRE 팀은 이를 해결하기 위해 Grafana 플러그인인 SRELens를 개발했습니다. SRELens는 자연어 질문을 바탕으로 LLM 에이전트가 관측성 데이터를 조회하고, 도구 호출과 비용·권한·안전 정책을 백엔드에서 통제하며 원인 후보를 근거와 함께 제시합니다. ## 관측성 데이터가 분산되며 발생한 문제 - 메트릭은 Grafana·IMON, 로그는 LaaS·IU, 트레이스는 IMON 트레이스·Tempo, 프로파일은 별도 도구에서 확인해야 했습니다. - 장애 분석 과정에서 시간 범위, 서비스명, 라벨, 트레이스 ID 등의 맥락을 여러 시스템에 반복해서 옮겨야 했습니다. - 자체 호스팅형 LGTM-P 스택을 구축해 데이터를 통합했습니다. - Mimir: 메트릭 - Loki: 로그 - Tempo: 트레이스 - Pyroscope: 프로파일 - OpenTelemetry Collector: 데이터 수집 및 전달 - 데이터가 한곳에 모여도 사용자가 적절한 데이터소스와 라벨, 쿼리 방법을 알아야 한다는 문제는 남았습니다. - 예를 들어 서비스명이 데이터소스마다 `service_name`, `resource.service.name` 등 다른 필드로 표현될 수 있습니다. ## 오픈소스 PoC에서 확인한 한계 - **사용자 컨텍스트와 권한 전파** - Grafana 인증 사용자 정보를 대화 기록, 사용량 한도, 조회 권한에 안정적으로 연결하기 어려웠습니다. - **시스템 프롬프트 제어** - 도구 호출 순서, 재시도, 위험 작업 제한 같은 운영 정책을 사용자 질의와 분리해 보호하기 어려웠습니다. - **짧은 도구 호출 라운드** - 메트릭·트레이스·로그를 순차적으로 확인해야 하는 장애 분석을 충분히 수행하지 못했습니다. - **데이터소스별 라벨 차이** - 올바른 데이터소스를 선택해도 라벨이나 필드가 다르면 검색 결과가 0건이 될 수 있었습니다. - **운영 및 라이선스 제약** - 사내 환경에 맞게 수정하고 배포하는 데 한계가 있었습니다. - 이를 통해 단순한 자연어 질의 기능보다, LLM 에이전트의 행동을 운영 환경에 맞게 통제하는 것이 더 중요하다는 결론을 얻었습니다. ## SRELens 아키텍처 - SRELens는 Grafana 애플리케이션 플러그인으로 동작합니다. - 프런트엔드는 Grafana 내부에 채팅 UI를 제공합니다. - 백엔드는 다음을 담당합니다. - LLM 호출 - 시스템 프롬프트 합성 - 도구 오케스트레이션 - 사용량 및 비용 제한 - 결과 크기와 재시도 제어 - 관측성 데이터 조회는 MCP 게이트웨이를 통해 수행합니다. - 업스트림 MCP 도구 외에도 Grafana 패널 검색과 이미지 렌더링을 위한 로컬 도구를 제공합니다. - `find_grafana_panel` - `render_grafana_panel` - 업스트림 도구와 로컬 도구는 `CompositeClient`를 통해 LLM에 일관된 인터페이스로 노출됩니다. ## 세 계층으로 분리한 프롬프트 설계 ### 베이스 시스템 프롬프트 - 조직 전체에 적용되는 전역 행동 정책입니다. - 다음과 같은 규칙을 포함합니다. - 도구 호출 순서 - 결과가 없을 때의 폴백 전략 - 결과가 잘렸을 때 집계 쿼리를 재실행하는 방법 - 대시보드 생성·수정·삭제 등 위험 작업의 안전 규칙 - 응답 형식과 분석 근거 제시 방식 - 관리자만 수정할 수 있으며, 별도 설정이 없으면 코드에 포함된 기본 프롬프트를 사용합니다. ### 데이터소스 프래그먼트 - 환경별 관측성 시스템 정보를 YAML 형태로 제공합니다. - 주요 내용은 다음과 같습니다. - 우선 사용할 Mimir·Loki·Tempo 데이터소스 UID - 서비스명을 찾기 위한 라벨 후보 - Loki 로그의 JSON 파싱 및 구조화 메타데이터 처리 방법 - SRE의 운영 지식을 미리 제공해 불필요한 탐색을 줄이고 분석 성공률과 속도를 높입니다. ### 사용자 프롬프트 - 담당 서비스, 선호 응답 형식, 자주 사용하는 대시보드 등 개인·팀의 맥락을 저장합니다. - Redis에 저장되며 시스템 프롬프트의 추가 컨텍스트로 주입됩니다. - 베이스 프롬프트를 덮어쓰지 않으므로 개인화가 조직 공통 안전 정책보다 우선할 수 없습니다. ## 백엔드 중심의 툴 오케스트레이션 - 프런트엔드가 시스템 프롬프트를 조립하지 않고, 백엔드 오케스트레이터가 모든 프롬프트 합성을 담당합니다. - 에이전트는 다음 루프를 반복합니다. 1. 사용자 질문을 LLM에 전달 2. LLM이 요청한 MCP 또는 로컬 도구 실행 3. 도구 결과를 다시 LLM에 전달 4. 최종 분석이 나올 때까지 반복 - 운영 안정성을 위해 코드 수준의 가드레일을 적용했습니다. - 최대 10라운드로 도구 호출 제한 - 동일 도구·동일 인자의 중복 호출 차단 - 도구별 재시도 최대 2회 - 개별 도구 결과 크기 제한 - 전체 요청이 커질 경우 오래된 도구 결과를 플레이스홀더로 치환 - `tool_call_id`를 유지해 호출과 결과의 연결 보장 - 결과가 없으면 라벨, 시간 범위, 데이터소스를 바꿔 재시도하도록 유도 ## 비용·요청량 및 장애 대응 정책 - 사용자별 일일 토큰 한도를 적용합니다. - 분당 요청 수를 제한하고, 한도 초과 시 HTTP 429를 반환합니다. - 응답 후 OpenAI가 반환한 실제 프롬프트·출력 토큰 사용량을 사용자별 일일 버킷에 기록합니다. - 사용량은 Asia/Seoul 기준 자정에 초기화됩니다. - Redis는 대화 기록, 사용자 프롬프트, 쿼터 저장에 사용됩니다. - Redis 장애가 발생해도 단일 채팅 요청은 계속 처리할 수 있도록 설계했습니다. - 대화 기록 및 개인화 기능은 제한될 수 있습니다. - SRELens 전체가 동시에 중단되지는 않습니다. ## 실제 장애 분석 방식의 변화 - 사용자는 “특정 시간대에 왜 에러가 늘었는가”처럼 자연어로 질문할 수 있습니다. - SRELens는 하나의 분석 흐름에서 메트릭, 로그, 트레이스를 연결해 확인합니다. - 예시 시나리오에서는 베타 환경의 오류 급증을 분석하면서 특정 API 요청인 `CopyMedia` 호출 증가와 관련된 원인까지 범위를 좁혔습니다. - 기존처럼 대시보드, 로그 검색 시스템, 트레이스 도구를 오가며 사람이 상관관계를 직접 맞출 필요가 줄어듭니다. - 분석 결과는 단순한 결론이 아니라 조회된 관측성 데이터와 근거를 함께 제시하는 것을 목표로 합니다. 운영 환경에서 LLM 기반 장애 분석을 도입할 때는 자연어 인터페이스보다 통제 구조를 먼저 설계하는 것이 중요합니다. 조직 정책과 환경별 데이터소스 지식을 프롬프트 계층으로 분리하고, 도구 호출·권한·비용·재시도를 백엔드 코드로 제한해야 안정적이고 재현 가능한 분석 도구를 만들 수 있습니다.

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

모델 컨텍스트 프로토콜옵저버빌리티redisgrafana+3

gitlab·2026년 7월 31일·4분 읽기큐레이션 요약

에이전트형 AI, MCP 및 AI 코딩 어시스턴스를 어떻게 거버넌스할 것인가

에이전틱 AI는 코드 제안만 하는 보조 도구와 달리, 도구 호출·설정 변경·머지 리퀘스트 생성·배포까지 수행할 수 있어 기존의 인간 중심 검토 방식만으로는 충분히 통제하기 어렵다. 따라서 조직은 모델 성능보다 에이전트의 신원, 권한 범위, 데이터 접근, 실행 기록을 관리하는 거버넌스 체계를 먼저 마련해야 한다. 핵심은 모든 작업을 막는 것이 아니라, 자율 실행과 인간 승인이 필요한 경계를 명확히 정하고 사후 감사가 가능하도록 만드는 것이다. ## 에이전틱 AI에 별도 거버넌스가 필요한 이유 - 기존 AI 코드 자동완성은 개발자가 제안을 보고 승인하거나 거부하므로, 모든 코드에 인간 검토가 개입한다. - 에이전틱 AI는 테스트 실행, CI/CD 설정 변경, 파일 작성·삭제, 코드 푸시 등 여러 단계를 연속적으로 수행할 수 있다. - MCP(Model Context Protocol)를 사용하면 에이전트가 외부 도구와 데이터에 연결되므로 접근 권한과 실행 범위가 더욱 중요해진다. - 거버넌스의 핵심 질문은 다음과 같다. - 에이전트가 무엇에 접근할 수 있는가? - 어떤 작업을 수행하도록 승인되었는가? - 실제로 어떤 작업을 했으며, 이를 사후에 증명할 수 있는가? - 조사 결과에서도 AI 코드의 장기 유지보수와 기술 부채 증가가 주요 우려로 나타났다. - 개발자·기술 리더의 73%가 AI 생성 코드의 장기 유지보수를 우려했다. - 86%는 명확한 거버넌스가 없으면 기술 부채가 기존 개발 방식보다 빠르게 누적될 수 있다고 답했다. - DevSecOps 전문가의 92%는 AI 생성 코드와 관련된 거버넌스 문제를 경험했다. ## MCP와 에이전트 권한 통제 에이전트가 외부 도구를 호출할 수 있게 되면 권한 관리가 가장 중요한 통제 지점이 된다. - 에이전트와 작업 흐름의 중앙 카탈로그를 운영한다. - 팀마다 임의로 통합 기능을 만들게 하지 않고, 관리자가 승인된 에이전트와 플로우만 조직에 배포한다. - 기존 역할·그룹 구조와 연계해 프로젝트별 사용 범위를 관리한다. - 복합 신원(composite identity)을 사용한다. - 에이전트의 활동을 에이전트 자체의 작업으로만 기록하지 않고, 작업을 요청한 인간 사용자와 연결한다. - 리소스 접근 시 에이전트와 요청 사용자 모두 인증·인가되어야 한다. - 도구별 승인 정책을 설정한다. - 안전한 도구는 자율 실행을 허용한다. - 파일 작성, 리소스 삭제처럼 민감한 작업은 인간 승인 후 실행되도록 한다. - 위험한 도구는 아예 차단할 수 있어야 한다. - 프롬프트 가드레일을 마련한다. - 웹페이지, 이슈 댓글, 외부 파일 등 신뢰할 수 없는 입력이 에이전트의 행동을 조작하는 프롬프트 인젝션을 탐지한다. - 단순히 실행 결과를 기록하는 것을 넘어, 공격 시도를 실행 전에 차단해야 한다. 이러한 통제는 인간 사용자에게 적용하는 역할 기반·감사 가능·일관된 권한 모델과 동일한 수준으로 에이전트에도 적용되어야 한다. ## 데이터 privacy와 자체 호스팅 소스 코드를 외부 AI 서비스에 제공할 때는 데이터 처리와 소유권을 명확히 확인해야 한다. - 공급자가 고객 코드를 모델 학습에 사용하는지 확인한다. - 입력 데이터와 AI가 생성한 출력의 소유권을 확인한다. - 하위 처리자(subprocessor)의 위치와 목록 변경 통지 정책을 검토한다. - 규제 산업에서는 데이터가 조직 외부 인프라로 나가지 않아야 할 수 있으므로 자체 호스팅이 중요한 통제 수단이 된다. - 자체 호스팅을 사용하면 다음을 함께 달성할 수 있다. - 조직이 통제하는 인프라에서 에이전트 실행 - 팀별 사용량과 활동 추적 - 규제기관의 데이터 보관·처리 요구 충족 - BYOM(Bring Your Own Model)을 활용하면 내부 검증을 마친 모델을 연결하고, 특정 에이전트 플로우에만 지정할 수 있다. - 민감한 작업은 신뢰할 수 있는 자체 모델에 고정한다. - 상대적으로 덜 민감한 작업은 관리형 모델을 사용할 수 있다. ## 인간 검토가 필요한 지점 정의 거버넌스는 에이전트의 자율 실행을 전면 금지하는 것이 아니라, 자율성이 끝나고 인간 검토가 시작되는 지점을 결정하는 것이다. - 대화형 작업 - 개발자가 실시간으로 제안을 확인하고 승인·거부한다. - 일반적인 AI 코드 자동완성에 가까운 방식이다. - 자동화·헤드리스 작업 - CI/CD 파이프라인에서 개발자의 실시간 관찰 없이 에이전트가 실행된다. - 실행 전에 도구 승인 절차를 거치거나, 실행 직후 감사 로그를 통해 사람이 검토해야 한다. ### 검토 지점별 통제 방식 - 코드 리뷰 - 에이전트가 생성한 머지 리퀘스트라도 일반 코드와 동일하게 승인 정책을 적용한다. - 지정된 담당자의 승인이 없으면 병합되지 않도록 한다. - 테스트와 검증 - 필수 테스트, 보안 스캔, 품질 검사를 통과해야 다음 단계로 진행하도록 파이프라인에서 강제한다. - 배포 - 운영 배포처럼 영향이 큰 작업은 명시적인 인간 승인을 요구한다. - 도구 실행 - 도구별로 자율 실행, 승인 대기, 실행 차단 중 하나를 지정한다. - 조직 정책 - 팀별 관행에 맡기지 말고 조직 전체의 AI 사용·승인·감사 정책으로 표준화해야 한다. - 이렇게 해야 사용 방식이 일관되고, 감사 담당자가 AI 활용 과정을 검증할 수 있다. ## 실용적인 적용 방향 조직은 에이전트 도입 전에 승인된 에이전트 목록과 모델 목록을 만들고, 사용자·에이전트의 복합 신원, 프로젝트별 권한, 도구별 승인 정책, 데이터 처리 위치를 정의해야 한다. 이후 머지 승인, 보안 스캔, 배포 승인 같은 기존 개발 통제 지점을 에이전트 작업에도 동일하게 적용하고, 모든 실행을 추적 가능한 감사 로그로 남기는 것이 바람직하다.

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

모델 컨텍스트 프로토콜AI 에이전트CI/CDDevSecOps+4

line·2026년 7월 30일·5분 읽기큐레이션 요약

AI 에이전트를 위한 Android CLI: 대규모 모바일 개발 환경에 적용하기

LINE Android처럼 수백 개의 Gradle 모듈과 대규모 코드를 가진 저장소에서는 단순한 `grep`·`glob` 검색만으로 AI 에이전트가 의미론적 질문에 답하기 어렵고, 불필요한 결과와 재시도로 토큰 비용이 급증합니다. LINE 개발팀은 Android CLI를 문서 검색과 Android Studio 연동의 기반으로 활용하되, 고정된 바이너리·래퍼·스킬·프롬프트를 조합해 보안, 환경 일관성, 오류 처리, 토큰 효율성을 보완하고 있습니다. 핵심은 CLI를 에이전트에 그대로 노출하지 않고, 저장소 규모와 조직 환경에 맞게 통제된 인터페이스로 제공하는 것입니다. ## 대규모 Android 저장소에서 AI 에이전트가 겪는 문제 - 수백 개의 Gradle 모듈과 방대한 코드 때문에 검색 한 번에도 지나치게 많은 결과가 반환됩니다. - 검색 결과가 에이전트 컨텍스트에 포함되면서 토큰과 비용이 빠르게 증가합니다. - 텍스트 검색만으로는 다음과 같은 의미론적 질문에 정확히 답하기 어렵습니다. - 특정 심볼의 선언 위치 - 심볼의 실제 참조 위치 - IDE가 판단하는 사용되지 않는 코드나 경고 - 의존성 내부 심볼의 위치 - 관련 없는 결과를 바탕으로 에이전트가 반복 검색과 재시도를 수행하면서 비효율이 커집니다. - 따라서 Android CLI를 그대로 적용하기보다는 래퍼, 스킬, 프롬프트를 통한 보완이 필요합니다. ## 문서 검색을 Android CLI로 전환 - Android CLI는 빌드·배포, SDK 관리, 환경 진단, 공식 문서 검색, Android Studio 연동 등을 제공합니다. - 첫 적용 대상은 Android, Jetpack Compose, AndroidX, Firebase 등의 공식 문서 검색이었습니다. - 모델의 사전 학습 지식은 최신 API 변경을 반영하지 못할 수 있어 잘못된 시그니처를 생성하는 환각이 발생할 수 있습니다. - 최신 Android Knowledge Base를 직접 참조하면 문서의 권위와 최신성을 확보할 수 있습니다. - 기존에는 Google Cloud Knowledge MCP 서버를 사용했지만 다음 운영 부담이 있었습니다. - 개발자별 Google Cloud API 인증 설정 - 인증 프록시 운영 - API 할당량 제한 대응 로직 유지 - Android CLI의 `docs` 명령은 다음 두 단계로 사용됩니다. - `docs search`: 키워드로 공식 문서 검색 - `docs fetch`: 검색 결과의 KB URL로 문서 본문 조회 - 이 기능은 `get-android-dev-knowledge` 스킬로 에이전트에 제공됩니다. - 기존 MCP 방식과 비교해 인증, 프록시, 할당량 처리 인프라를 제거하고 더 적은 토큰으로 최신 문서를 참조할 수 있습니다. ## CLI 바이너리를 저장소에 번들링한 이유 LINE 팀은 전역 설치된 `android` 명령 대신 `.agents/tools/android-cli/android`처럼 저장소 내부의 고정 경로에 바이너리를 포함했습니다. ### 환경 파편화 방지 - 개발자마다 CLI 버전, 설치 위치, 운영체제가 달라지는 문제를 줄입니다. - 저장소를 클론하면 동일한 버전을 사용할 수 있습니다. - 개발자 장비뿐 아니라 CI와 AI 에이전트 실행 호스트에서도 동일한 환경을 보장합니다. ### 보안 정책과 래퍼 적용 - Android CLI는 호출 과정에서 일부 데이터를 수집할 수 있습니다. - 이를 막으려면 호출마다 `--no-metrics` 인자를 지정해야 합니다. - 에이전트가 해당 인자를 누락할 수 있으므로 모든 호출을 통과시키는 래퍼에서 강제하는 방식이 안전합니다. - 래퍼가 실제 바이너리를 안정적으로 찾으려면 바이너리 위치가 고정되어 있어야 하므로 저장소 번들링이 유리합니다. - 대규모 저장소에 이미 `git-lfs`가 적용되어 있어 바이너리 포함 비용도 감당할 수 있었습니다. ## `--no-metrics` 관련 버그와 오류 출력 개선 - Android CLI 1.0 도입 과정에서 정보 수집 기능이 `--no-metrics` 처리 전에 초기화되는 버그가 발견되었습니다. - 이 때문에 메트릭 수집을 비활성화해도 `~/.android/cli`에 쓰기를 시도할 수 있습니다. - 샌드박스나 파일 시스템 권한으로 쓰기가 차단되면 여러 페이지의 Java 스택 트레이스가 출력됩니다. - 장황한 스택 트레이스는 에이전트 컨텍스트를 불필요하게 차지하고 문제 해결도 어렵게 만듭니다. - 래퍼는 CLI 실행 전에 다음을 수행합니다. - `~/.android/cli` 디렉터리 생성 시도 - 임시 파일을 만들어 쓰기 권한 확인 - 쓰기가 막히면 한 줄짜리 파싱 가능한 오류 출력 - 에이전트는 이제 긴 예외 대신 “쓰기 권한을 부여한 뒤 재시도하라”는 원인과 조치를 직접 전달받습니다. - 반복적으로 발생하는 오류를 에이전트가 처리하기 쉬운 구조화된 메시지로 변환하는 방식은 이후 Android Studio 연동에도 적용됩니다. ## Android Studio 연동의 의미론적 기능 Android CLI 1.0에서는 실행 중인 Android Studio와 연결해 IDE 수준의 분석을 명령줄에서 수행할 수 있게 되었습니다. - `studio check` - Android Studio 실행 여부를 확인합니다. - 대상 프로젝트가 열려 있는지 확인합니다. - 프로젝트 인덱싱이 완료되었는지 확인합니다. - 다른 Studio 기능을 사용하기 위한 전제 조건입니다. - `studio analyze-file` - 빌드하지 않고 단일 파일에 IDE 인스펙션을 적용합니다. - 에러와 경고를 반환합니다. - `is never used`처럼 단순한 `grep`으로 파악하기 어려운 의미론적 문제도 찾을 수 있습니다. - `studio find-declaration` - 심볼의 선언 위치를 찾습니다. - 프로젝트 코드뿐 아니라 `.aar`, `.jar` 의존성 내부도 검색합니다. - `studio find-usages` - 특정 심볼이 사용된 위치를 찾습니다. - `studio render-compose-preview` - `@Preview`가 적용된 Jetpack Compose 화면을 PNG 이미지로 렌더링합니다. ## CLI를 래퍼와 스킬로 감싼 설계 - Android Studio 기능도 CLI를 에이전트에 직접 노출하지 않고 얇은 래퍼와 스킬을 통해 제공합니다. - 가장 먼저 `studio-check` 스킬을 만들었습니다. - 에이전트가 CLI의 복잡한 입출력과 환경 전제 조건을 직접 처리하지 않도록 하는 것이 목적입니다. - 래퍼는 권한 확인, 실행 환경 검증, 오류 메시지 정규화 같은 공통 처리를 담당합니다. - 스킬은 에이전트가 언제 어떤 기능을 사용해야 하는지 안내하는 고수준 인터페이스 역할을 합니다. 실무적으로는 대규모 저장소에서 Android CLI를 전역 도구로 배포하기보다, 버전을 고정한 바이너리를 저장소에 포함하고 모든 호출을 래퍼로 통제하는 방식을 추천할 수 있습니다. 특히 검색 결과를 무작정 늘리는 대신 문서 검색, 심볼 탐색, IDE 분석처럼 목적에 맞는 의미론적 명령을 스킬로 제공하면 토큰 낭비와 에이전트의 반복 작업을 크게 줄일 수 있습니다.

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

모델 컨텍스트 프로토콜Androidgradleai-coding-agents+3

gitlab·2026년 7월 22일·4분 읽기큐레이션 요약

Cursor와 GitLab으로 Java 현대화하기

Java 8에서 21로의 현대화는 단순한 버전 업그레이드가 아니라 빌드·런타임·의존성·API·동시성·테스트·컨테이너·운영 동작을 함께 다루는 복합 작업이다. 따라서 Cursor로 모든 변경을 한 번에 수행하기보다, 작은 문제를 단계적으로 해결하고 GitLab의 이슈 계층, CI/CD, 보안 검사, 코드 리뷰, 영향 분석으로 안전성을 검증해야 한다. 글은 실패한 테스트 수정에서 시작해 품질 게이트를 마련하고, 특정 HTTP 연결 경계를 Java 21 방식으로 현대화하는 흐름을 제시한다. ## Cursor와 GitLab의 역할 분담 - Cursor는 코드베이스 안에서 다음과 같은 집중 작업에 적합하다. - 실패한 테스트의 원인 추적 - 구현 코드와 테스트 분석 - 제한된 범위의 수정안 작성 - 로컬 테스트 실행 - 브랜치와 머지 리퀘스트 생성 - GitLab은 AI가 만든 변경을 소프트웨어 개발 생명주기 안에서 검증하는 역할을 한다. - Epic과 하위 이슈로 현대화 계획을 지속적이고 검토 가능하게 관리 - GitLab MCP 서버로 이슈, 논의, 파이프라인, 의존성 등 프로젝트 문맥을 Cursor에 제공 - CI/CD, 보안 스캔, 코드 리뷰, 코드 소유자 승인, 영향 분석 수행 - Duo Agent Platform의 Code Review Flow와 Developer Flow로 프로젝트별 품질 기준 적용 - AI 에이전트의 속도 자체가 안전성을 보장하지 않으므로, 모든 에이전트 생성 머지 리퀘스트도 일반 변경과 동일한 검증 절차를 거쳐야 한다. ## 예제 시스템과 현대화 범위 - 대상은 Tanuki IoT Platform의 Java HTTP metrics collector다. - 이 컴포넌트는 다음 작업을 수행한다. - 상태 점검 및 유지보수 HTTP 엔드포인트에 `GET` 요청 - 응답 상태와 응답 시간 등의 메트릭 기록 - Rust 기반 metrics-store 백엔드에 `POST /api/metrics` 요청 - 백엔드의 HTTP 응답을 확인 - Java 애플리케이션과 Rust 백엔드 사이의 실제 HTTP 계약이 존재하므로, Java 런타임 현대화가 운영 경계에 미치는 영향을 테스트할 수 있다. - 환경에는 Java 8과 Java 21, Maven, Docker, Docker Compose, GitLab MCP 서버가 필요하다. - 저장소의 `AGENTS.md`에는 프로젝트 구조와 Maven 테스트 명령이 있어 Cursor가 로컬 개발 규칙을 따르는 데 활용된다. ## 실패한 엔드투엔드 테스트 수정 - 문제는 엔드포인트의 기대 HTTP 상태 코드 처리에서 발생한다. - 사용자는 특정 상태 코드를 기대하도록 설정할 수 있다. - 구현은 모든 `2xx` 응답만 성공으로 간주한다. - 따라서 `503`을 정상적인 기대값으로 설정해도 테스트가 실패한다. - 엔드투엔드 테스트는 이미 문제를 드러내고 있었지만 CI/CD 작업이 `allow_failure` 상태여서 실패가 지속적인 경고음으로만 남아 있었다. - Cursor에는 관찰 가능한 문제를 직접 설명하고 다음 순서로 작업하도록 요청한다. - 먼저 분석 작성 - 구현과 실패 테스트 추적 - 수정 적용 - 테스트 재실행 - Cursor는 엔드포인트 설정에서 `HttpCollector`와 실패한 엔드투엔드 테스트까지 경로를 추적해 불일치의 원인을 찾는다. - 집중 테스트와 전체 Maven 테스트가 통과한 뒤 브랜치와 머지 리퀘스트를 만든다. - 테스트가 결정적이고 안정적으로 통과하면, 기존에 실패를 허용하던 엔드투엔드 작업을 필수 검증 단계로 전환할 수 있다. ## 머지 리퀘스트 기반 검증 - 머지 리퀘스트 생성 후 자동으로 다음 검증이 실행된다. - 빌드 - 단위 및 통합 테스트 - 엔드투엔드 테스트 - 보안 스캔 - GitLab Duo Code Review는 프로젝트의 Java 전용 리뷰 지침에 따라 변경을 검토한다. - 리뷰에서 구체적인 문제가 발견되면 Developer Flow를 통해 수정한 뒤 병합한다. - 머지 리퀘스트는 단순한 결과물 제출 수단이 아니라 다음을 수행하는 협업·의사결정 공간이다. - 변경 의도 설명 - 테스트 및 파이프라인 결과 확인 - 리뷰 의견 처리 - 에이전트가 만든 코드의 품질 증거 축적 - 이 단계에서 실제 버그를 런타임 마이그레이션과 섞지 않고 먼저 수정함으로써, 이후 현대화 작업의 행동 기준선과 회귀 방지 테스트를 확보한다. ## Java 8에서 Java 21로 넘어가기 위한 품질 게이트 - Java 21 현대화는 앞선 테스트 버그 수정과 달리 훨씬 넓은 범위를 가진다. - 기존 Java modernization epic에는 다음과 같은 계획 문맥이 포함되어 있다. - 하위 작업 항목 - 팀 논의 - 조사 결과와 관련 머지 리퀘스트 - 과거 파이프라인 기록 - 의존성 정보 - 보안 취약점 및 관련 발견 사항 - 이러한 정보를 Cursor에 제공하면 단순히 소스 코드를 바꾸는 것이 아니라 프로젝트의 개발 이력과 운영 제약을 반영한 변경 계획을 세울 수 있다. - 글의 접근 방식은 전체 마이그레이션을 한 번에 수행하지 않고, 먼저 품질 게이트를 마련한 뒤 영향 범위가 명확한 경계부터 현대화하는 것이다. ## 실용적인 적용 순서 - 먼저 하나의 실패한 테스트나 제한된 버그를 선택한다. - Cursor로 원인 분석, 수정, 테스트 실행을 수행한다. - 변경을 작은 머지 리퀘스트로 제출하고 CI/CD와 자동 리뷰를 통과시킨다. - 그다음 Epic과 이슈, MCP를 통해 Java 21 마이그레이션의 전체 문맥을 연결한다. - 모든 테스트, 보안 검사, 코드 소유자 승인, 영향 분석 결과를 품질 게이트로 사용한다. - 마지막으로 HTTP 연결 처리처럼 하나의 경계를 골라 현대화하고, Java 애플리케이션과 Rust 백엔드 사이의 실제 계약이 유지되는지 검증하는 것이 안전하다.

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

모델 컨텍스트 프로토콜CI/CDgitlabDocker & 컨테이너+4