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

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

이 10가지 스킬을 시도해 보고—여러분의 스킬도 뽐내 보세요 | Figma 블로그

Figma의 ‘스킬’은 에이전트가 따를 작업 절차와 디자이너의 판단 기준을 담은 Markdown 지침 파일이다. 글은 디자이너가 자신의 스타일과 노하우를 스킬로 만들고, Figma 안에서 에이전트와 함께 작성·수정·실행할 수 있다고 설명한다. 이를 통해 반복 작업을 자동화하고, 개인의 디자인 감각을 팀의 워크플로에 확장할 수 있다. ## 디자이너의 판단을 담는 스킬 - 스킬은 엔지니어링 코드가 아니라, 에이전트가 따라야 할 순서화된 지침이나 프롬프트다. - 디자이너가 평소 사용하는 미적 기준, 작업 방식, 판단 규칙을 문서화할 수 있다. - 예시: - `/image-audit`: 파일 내 이미지의 내보내기 가능 여부를 검사하고 캔버스에 보고서 작성 - `/shader-starter`: 셰이더를 생성할 때 필요한 프롬프트 작성을 지원 - `/make-a-type-scale`: 선택한 텍스트를 기반으로 타입 스케일과 관련 폰트 변수를 생성 - `/ease-like-miggi` 스킬은 특정 디자이너가 선호하는 이징 커브를 키프레임에 적용해, 팀원도 동일한 모션 스타일을 사용할 수 있게 했다. ## Figma 안에서 스킬을 직접 제작하는 과정 - 디자인 프레임을 참고 자료로 제공하거나, 원하는 작업 단계와 가이드라인을 설명해 에이전트에 스킬 생성을 요청할 수 있다. - 에이전트가 초안을 만들면 미리보기로 결과를 확인한 뒤 채팅에서 바로 사용할 수 있다. - 테스트 과정에서 다음과 같이 반복 개선할 수 있다. - 작업 단계 수정 - Markdown 형식 변경 - 개선 방향이나 추천 요청 - Markdown 편집기를 통한 직접 수정 - 일부 스킬은 Figma MCP 서버와 연동되는 서드파티 에이전트에서도 사용할 수 있다. - MCP 서버용 스킬은 Figma의 GitHub 저장소에서 확인할 수 있다. ## 이미지에 X선 효과 적용하기 - 스킬: `/xray-scan` - 제작자: Adele Ix - 이미지나 텍스트 설명을 현실적인 방사선 사진처럼 변환한다. - 한 번에 두 가지 스타일을 생성한다. - 검은 배경 위에 빛나는 흰색 윤곽 - 흰 배경 위의 부드러운 어두운 톤 - 여러 X선 이미지를 겹쳐 독특한 모노크롬 콜라주를 만들 수 있다. - 빛나는 가장자리를 활용하기 때문에 여러 결과물을 겹쳐도 시각적으로 자연스럽게 섞인다. ## 모션이 필요한 지점 찾기 - 스킬: `/find-animation-opportunities` - 제작자: Linear의 Emil Kowalski - 디자인을 분석해 애니메이션이 필요한 부분과 오히려 애니메이션을 제거해야 할 부분을 찾아낸다. - 다음과 같은 질문에 답하도록 설계됐다. - 어떤 요소를 움직이면 더 생동감이 생기는가? - 어디에 어떤 모션을 적용해야 하는가? - 애니메이션의 구체적인 값은 무엇인가? - 제안된 변경 사항은 Figma Motion에서 직접 구현하거나 에이전트에게 적용하도록 요청할 수 있다. - 한 프레임을 대상으로 사용하고, 페이지의 타깃 사용자 같은 추가 맥락을 제공할 때 효과가 좋다. - “아예 움직이지 않아야 하는 요소는 무엇인가?”라고 질문하면 과도한 애니메이션도 줄일 수 있다. ## 정적인 구성에 카메라 움직임 추가하기 - 스킬: `/camera-pan-and-zoom` - 제작자: Figma의 Mallory Dean - 선택한 콘텐츠 주변에 실제 카메라 리그처럼 작동하는 중첩 레이어 구조를 만든다. - 팬, 줌, 롤 같은 카메라 움직임을 적용해 정적인 화면을 영상처럼 연출한다. - 예를 들어 여러 카드가 있는 그리드를 순차적으로 둘러본 뒤 전체 화면으로 다시 줌아웃하는 장면을 만들 수 있다. - 특정한 모션 연출에 특화된 스킬이지만, 복잡한 카메라 이동을 직접 구성하는 작업을 단순화한다. ## 실용적인 활용 방향 스킬은 단순한 자동화 명령이 아니라 디자이너의 작업 철학과 반복 가능한 판단을 팀에 공유하는 방법이다. 먼저 자신이 자주 수행하는 작업이나 고유한 스타일을 하나의 명확한 절차로 정리한 뒤, Figma 에이전트로 초안을 만들고 실제 결과를 확인하며 반복 개선하는 방식이 효과적이다.

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

AI 에이전트Figma디자인 시스템markdown+2

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

GitHub Copilot 앱으로 첫 프롬프트 작성하기

GitHub Copilot 앱에서 첫 프롬프트를 작성할 때 완벽한 문장보다 작업 대상과 원하는 결과를 명확히 전달하는 것이 중요하다. 프로젝트를 연결한 뒤 자연어로 작은 작업부터 요청하고, 결과에 따라 프롬프트·모델·실행 방식을 점진적으로 조정하면 된다. 음성 입력, 모델 선택, 에이전트 및 원격 세션 같은 기능은 필요할 때 활용할 수 있다. ## 작업에 필요한 컨텍스트 연결 - Copilot이 코드를 수정하려면 먼저 작업 대상이 필요하다. - GitHub 저장소나 로컬 컴퓨터의 폴더를 에이전트 세션에 연결할 수 있다. - Copilot은 연결된 프로젝트의 코드와 파일을 살펴보고 요청과 관련된 부분을 찾아 작업한다. - 앱 홈 화면에서 기존 프로젝트를 선택하거나 새 프로젝트·로컬 폴더를 추가한다. ## 자연어로 원하는 작업 설명하기 - 별도의 문법이나 정해진 프롬프트 형식을 배울 필요가 없다. - 원하는 변경 사항을 평범한 문장으로 설명하면 된다. - 예시: `게임 목록에 가장 많이 투자된 순서 정렬 옵션을 추가해줘.` - 첫 요청이 충분하지 않으면 세부 조건을 추가하거나 수정 사항을 다시 요청할 수 있다. - 프롬프트는 한 번에 완성하는 것이 아니라 결과를 보며 반복적으로 다듬는 방식이다. ## 작업에 맞는 AI 모델 선택 - Copilot 앱에서는 작업을 처리할 AI 모델을 직접 선택할 수 있다. - 모델마다 복잡한 추론 능력이나 처리 속도 등 강점이 다르다. - 처음에는 기본 모델을 사용해도 충분하다. - 복잡한 작업이거나 결과가 기대에 미치지 못하면 다른 모델로 전환할 수 있다. - 모델 선택은 매번 사전에 세밀하게 설정해야 하는 항목이 아니라, 필요할 때 활용하는 도구다. ## 음성 입력으로 프롬프트 작성 - 프롬프트는 키보드로만 입력할 필요가 없다. - 내장 음성 입력을 사용하면 문제를 말로 설명하면서 긴 요청을 작성할 수 있다. - 음성은 프롬프트 입력창의 텍스트로 변환된다. - 전송 전에 내용을 검토하고 수정할 수 있어, 생각나는 대로 말한 뒤 정리하는 방식도 가능하다. ## 에이전트와 원격 세션 활용 - 세션 제목 메뉴에서 다른 에이전트를 선택하거나 원격 제어를 활성화할 수 있다. - 에이전트마다 작업 유형에 맞게 설정할 수 있으므로 목적에 맞는 에이전트를 고르면 된다. - 원격 세션을 사용하면 작업을 로컬 컴퓨터에서 시작한 뒤 웹이나 다른 기기에서 이어서 확인할 수 있다. - 노트북을 닫아도 세션의 진행 상황을 잃지 않고 나중에 다시 작업할 수 있다. - 이러한 설정은 첫 프롬프트 전에 반드시 구성할 필요는 없으며, 더 많은 제어가 필요할 때 선택하면 된다. ## 작은 작업부터 반복하기 - 이미 익숙한 프로젝트에서 작은 변경 사항부터 요청하는 것이 좋다. - 처음부터 모든 세부 사항을 예측하거나 완벽한 프롬프트를 작성할 필요는 없다. - 결과를 확인하면서 요청을 구체화하고, 필요하면 모델이나 세션 실행 방식을 바꾼다. - 핵심은 프로젝트를 선택하고 자연어로 작업을 요청해 실제 결과를 확인하는 것이다. 실용적으로는 “프로젝트 연결 → 작은 작업 요청 → 결과 검토 → 프롬프트 보완” 순서로 시작하는 것이 가장 쉽다. Copilot의 모델·음성 입력·원격 세션 기능은 기본 흐름에 익숙해진 뒤 작업 상황에 맞게 추가하면 된다.

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

AI 에이전트github-copilot프롬프트 엔지니어링ai-coding-assistant+2

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/CD모델 컨텍스트 프로토콜github-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/CD모델 컨텍스트 프로토콜Cloudflare Workers+4

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

AWS 주간 요약: AWS Heroes Summit, Amazon Bedrock의 웹 검색, Dogwood, Kiro Crew 등 (2026년 8월 10일) | Amazon Web Services

AWS는 AI 에이전트의 실시간 정보 활용, 실행 환경 제어, 벡터 검색, 거버넌스와 협업 개발을 강화하는 기능들을 대거 공개했다. Amazon Bedrock의 웹 검색·전용 런타임·DynamoDB 벡터 검색과 AWS Transform의 지속적 현대화가 주요 출시 내용이며, Dogwood와 Agent Plugins를 통해 에이전트의 안전성과 이식성도 확대한다. 또한 AWS Heroes Summit과 Kiro Crew를 통해 개발자 커뮤니티와 멀티에이전트 개발 경험을 강화하고 있다. ## AWS Heroes Summit - 전 세계 AWS Heroes가 초청된 연례 행사로, AI·서버리스·컨테이너 분야 전문가들이 참여했다. - AWS 내부 제품·서비스 팀과 직접 기술 토론, 심층 세션, 피드백 교환을 진행했다. - AWS CEO 맷 가먼의 대담과 James Hamilton의 AMA, 제품 팀별 브레이크아웃 세션 등이 열렸다. - 참가자 간 지식 공유와 협업 기회 확대가 행사의 핵심 성과였다. ## Amazon Bedrock의 웹 검색 - Amazon Bedrock에서 OpenAI 모델이 인터넷을 검색하고 최신 정보를 가져올 수 있게 됐다. - GPT-5.4, GPT-5.5, GPT-5.6 Sol·Terra·Luna 모델이 학습 데이터 이후의 실시간 웹 콘텐츠를 활용할 수 있다. - AI 에이전트가 최신 뉴스나 외부 정보를 바탕으로 답변하도록 구축할 수 있다. - 데이터가 보안이 적용된 AWS 환경에 머물며 외부 데이터 반출 없이 사용할 수 있어 데이터 레지던시 요구사항에 유리하다. ## Bedrock AgentCore 전용 런타임 인스턴스 - AI 에이전트를 전용 런타임 인스턴스에 배포하고 실행할 수 있다. - 에이전트 실행 환경을 더 세밀하게 제어할 수 있으며 성능과 비용을 예측하기 쉽다. - 실행 리소스와 운영 특성이 중요한 프로덕션 에이전트에 적합하다. ## DynamoDB 벡터 검색 - 기존 DynamoDB 데이터와 AI용 벡터 임베딩을 같은 데이터베이스에 저장할 수 있다. - 별도의 벡터 데이터베이스를 운영하지 않고도 의미 기반 검색을 제공한다. - 에이전트 메모리에 저장된 정보에서 관련 내용을 검색해 응답을 보강하는 에이전틱 그라운딩에 활용할 수 있다. - DynamoDB 기반 운영 모델을 유지하면서 예측 가능한 성능으로 벡터 검색을 추가할 수 있다. ## AWS Transform의 지속적 현대화 - 소스 코드 저장소를 대규모로 분석해 기술 부채를 식별하고 수정한다. - 메인프레임과 레거시 워크로드를 일회성 마이그레이션이 아니라 지속적·자동화된 방식으로 현대화한다. - AWS Transform용 Kiro Power와 에이전트 플러그인을 통해 개발 작업을 자동화할 수 있다. ## Lambda 네트워크 대역폭 확대 - Lambda 함수의 네트워크 대역폭이 최대 3,000Mbps로 증가했다. - VPC 외부에서 실행되며 메모리가 2GB 이상인 함수의 네트워크 대역폭이 메모리에 비례해 확장된다. - 2GB 메모리에서는 625Mbps, 10GB 메모리에서는 최대 3,000Mbps를 제공한다. - 대용량 데이터 처리나 Lambda와 다른 AWS 서비스 간 통신이 많은 작업의 성능을 높일 수 있다. ## Dogwood와 시간 기반 에이전트 거버넌스 - AWS는 AI 에이전트용 거버넌스 언어인 Dogwood를 오픈 소스로 공개했다. - Cedar 정책을 지원하고, 에이전트 행동의 시간적 조건을 표현할 수 있다. - AgentCore의 temporal policy는 현재 요청만이 아니라 세션 내 과거 행동 이력에 따라 정책 결정을 내린다. - 반복적인 행동, 특정 순서의 작업, 이전 행동에 따른 권한 제한 등 상태ful한 에이전트 통제가 가능하다. ## Agent Plugins 표준 - Agent Plugins는 AI 에이전트 확장을 위한 오픈 소스·벤더 중립 표준이다. - 하나의 형식으로 확장 기능을 패키징해 Kiro, VS Code, Cursor 등 표준을 구현한 여러 클라이언트에서 사용할 수 있다. - 특정 개발 도구에 종속되지 않는 에이전트 확장 생태계를 구축하는 것이 목적이다. ## Kiro Crew의 멀티에이전트 개발 - Kiro Crew는 작업 상태를 지속적으로 유지하는 협업형 개발 workspace다. - 단일 채팅 세션을 넘어 여러 저장소, 도구, 날짜에 걸친 엔지니어링 작업을 관리한다. - 여러 작업을 병렬로 실행하거나 하위 에이전트에게 작업을 위임할 수 있다. - 하위 에이전트가 작업 결과를 보고하므로 개발자가 자리를 비운 동안에도 작업이 진행된다. 이번 발표의 방향은 AI 에이전트를 단순한 대화형 도구에서 실시간 검색, 장기 실행, 상태 기반 권한 관리, 협업 자동화가 가능한 운영 시스템으로 발전시키는 데 있다. 실제 도입 시에는 Bedrock 웹 검색의 데이터 통제, AgentCore의 실행 비용, Dogwood 기반 정책 설계, DynamoDB 벡터 검색의 데이터 규모를 함께 검토하는 것이 좋다.

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

AI 에이전트AWSamazon-bedrockaws-lambda+4

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

에이전틱 인터넷의 좋은 행동과 나쁜 행동을 파헤치다

인터넷 트래픽은 인간과 봇으로 단순히 나눌 수 없으며, 한 세션 안에서 인간과 에이전트가 번갈아 행동하는 하이브리드 트래픽도 증가하고 있다. 따라서 사이트 운영자는 일회성 검사보다 세션 전체의 행동을 분석해 위험(Risk)과 신뢰(Trust)를 평가해야 한다. Cloudflare는 투명하게 자신을 밝히고 신뢰를 남용하지 않는 봇은 허용하되, 지속적인 행동 분석으로 악성 자동화 트래픽을 탐지하는 생태계를 구축하고 있다. ## 위험과 신뢰는 서로 다른 개념 - **위험(Risk)**은 특정 요청이나 행동이 해로울 가능성으로, 순간적이고 상황에 따라 달라진다. - **신뢰(Trust)**는 시간에 걸쳐 쌓이는 평판이며, 방문자의 행동 맥락을 바탕으로 형성된다. - 예를 들어 밤늦게 초인종을 여러 번 누르는 행동만 보면 위험해 보이지만, 방문자가 신뢰하는 친구라면 판단이 달라진다. - 인터넷에서도 “특정 시간대의 요청”이나 “일정 횟수 이상의 요청”만으로 차단하면 정상적인 사용자를 오탐할 수 있다. - Cloudflare는 악성 활동을 차단하는 것부터 안전한 참여를 장려하는 것까지, 신뢰를 중심으로 한 도구와 인센티브를 제공하려 한다. ## 투명성을 기반으로 한 정상 봇 - Cloudflare가 정의하는 검증된 봇과 에이전트는 다음 두 조건을 만족해야 한다. - 자신이 누구인지 정직하게 선언한다. - 획득한 신뢰를 악용하지 않는다. - 봇 운영자가 정체성과 데이터 사용 목적을 투명하게 공개하면, 사이트 운영자는 허용할 행동과 접근 범위를 더 쉽게 결정할 수 있다. - **BotBase**는 단순히 “좋은 봇 목록”을 제공하는 디렉터리가 아니라, 알려진 봇과 에이전트의 신원 및 행동 정보를 추적하는 시스템이다. - 검증된 봇이라도 Cloudflare 네트워크에서 신뢰를 남용하면 검증 상태를 잃을 수 있다. - 즉, 정상 여부는 고정된 신분이 아니라 실제 행동과 신뢰 유지 여부에 따라 계속 평가된다. ## 일회성 검사를 넘어서는 악성 봇 탐지 - **Precursor**는 CDN에서 JavaScript를 주입해 클라이언트 측 행동을 지속적으로 분석하는 시스템이다. - CAPTCHA나 한 번의 브라우저 검사는 특정 시점의 위험만 평가하므로, 이후 악성 행동을 시작하는 봇을 놓칠 수 있다. - Precursor는 페이지 이동을 포함한 전체 세션을 관찰해 인간답지 않은 행동 패턴을 탐지한다. - 주요 효과는 다음과 같다. - 세션 전체에 걸친 신뢰 기반 탐지 - 봇 개발자가 여러 페이지에 걸쳐 인간 행동을 모방해야 하도록 비용 증가 - 단 한 번의 검사만 통과한 자동화 트래픽에 지속적인 우회 기회를 주지 않음 - 이는 봇 개발자가 탐지 시스템을 우회하는 경제적 이점을 줄여, 공격자와 방어자 사이의 경쟁에서 방어 측에 유리하게 만든다. ## 세션 중간에 나타나는 의심스러운 행동 - 출시 후 24시간 동안 Precursor는 Cloudflare 네트워크의 73,438개 존에서 2억 600만 건의 평가 이벤트를 처리했다. - 분석 결과, 의심스러운 행동은 세션 시작 시점이 아니라 **세션 중간에 발생하는 경우가 많았다**. - 한 세션이 인간 행동에서 에이전트 행동으로, 다시 인간 행동으로 바뀌는 사례도 확인됐다. - 따라서 무조건 봇을 차단하기보다 다음 요소를 기준으로 분류해야 한다. - 트래픽의 사용 목적 - 요청의 의도 - 접근하는 데이터의 종류와 사용 방식 - 이 같은 하이브리드 트래픽을 정상적인 사용자 흐름과 구분하려면, 세분화된 봇·에이전트 분류 체계가 필요하며 BotBase 개편의 배경도 여기에 있다. ## Precursor Trace와 행동 신호 - **Precursor Trace**는 Precursor 탐지 방식 일부를 체험할 수 있는 인터랙티브 데모다. - 커서 움직임을 분석해 다음과 같은 특징을 보여준다. - 움직임의 가속과 감속 - 이동 중 수정이나 보정 - 커서 이동의 리듬과 질감 - 사람은 무의식적으로 이러한 불규칙성을 보이지만, 자동화 프로그램이 이를 여러 페이지와 긴 시간 동안 정확히 재현하기는 어렵다. ## 적응형 인텔리전스 - Cloudflare는 자동화 여부를 단순한 이진값으로만 판단하지 않고, 요청에 대한 평가 결과를 여러 단계로 구분하는 **Adaptive Intelligence**를 준비하고 있다. - 제공된 글의 본문은 이 기능의 구체적인 평가 단계와 출시 내용이 이어지기 전에 끝나 있어, 세부 사항은 확인할 수 없다. 사이트 운영자는 CAPTCHA 같은 단발성 방어책에만 의존하기보다 세션 전체의 행동, 봇의 신원 공개, 목적과 데이터 사용 방식을 함께 평가하는 것이 좋다. 정상적인 자동화는 투명성과 신뢰를 바탕으로 허용하고, 신뢰를 악용하거나 세션 중간에 비정상 행동을 보이는 트래픽은 지속적으로 재평가하는 접근이 적절하다.

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

AI 에이전트cloudflareJavaScriptcdn+3

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

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

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

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

코드, 장인정신, 그리고 중첩 폴더의 제작 | Figma 블로그

Figma의 중첩 폴더는 단순한 파일 정리 기능이 아니라 콘텐츠 구조와 권한 모델을 재설계한 대규모 제품 작업이었다. 개발 과정에서 팀은 전통적인 순차형 프로세스 대신 코드로 아이디어를 빠르게 검증하고, 직무 경계를 유연하게 넘나들며, 인수인계를 대화 중심 협업으로 바꾸었다. 그 결과 변화하는 AI·코드 중심 환경에서도 복잡한 기능을 빠르게 구체화하고 출시할 수 있었다. ## 중첩 폴더가 단순한 기능이 아니었던 이유 - 중첩 폴더는 규모가 커지는 팀이 파일과 프로젝트를 계층적으로 정리하도록 돕는 기능이다. - 구현 범위는 파일 브라우저에 그치지 않았다. - 콘텐츠 구조 - 관리자 제어 - 공유 방식 - 권한 처리 - 핵심 인프라 - 따라서 기존 모델에 폴더 한 단계만 추가하는 방식이 아니라, Figma의 콘텐츠 및 권한 모델을 근본적으로 재검토해야 했다. ## 변화한 제품 개발 환경 - 프로젝트 초기에는 일반적인 순차형 개발 방식을 따랐다. - 제품팀이 요구사항을 정의 - 디자인팀이 사용자 경험을 설계 - 설계가 충분히 정리된 뒤 엔지니어링 시작 - 그러나 개발 중 팀의 자원과 우선순위가 달라졌다. - AI 네이티브 기능 개발로 인력이 분산됨 - Figma Make, MCP 서버, 에이전트 스킬, 코드베이스 프로토타이핑 등이 아이디어를 빠르게 구현하는 수단으로 부상함 - 아이디어는 더 이상 완성된 문서에서만 출발하지 않고, 프로토타입·코드·Slack의 간단한 스케치에서도 시작될 수 있게 되었다. ## 코드로 먼저 검증하기 - 코드 작성 비용이 낮아지면서 논쟁이나 추상적인 기획을 오래 이어가기보다 실제 구현물을 빠르게 만들 수 있게 되었다. - 팀은 아이디어를 검증하기 위해 초기부터 pull request(PR)를 생성했다. - PR은 단순한 최종 코드 리뷰 수단이 아니라 다음을 확인하는 실험 도구로 활용되었다. - 기술적으로 가능한지 - 사용자 경험이 자연스러운지 - 권한과 데이터 구조에 문제가 없는지 - 여러 대안 중 어떤 방향이 적절한지 - 실제 동작하는 결과물을 바탕으로 논의하면서 의사결정 속도와 피드백의 구체성이 높아졌다. ## 직무 경계를 유연하게 바꾸기 - 역할을 엄격히 분리하기보다 문제 해결에 필요한 사람이 해당 영역의 결정을 맡았다. - 엔지니어가 디자인 관련 결정을 내리고, 디자이너가 직접 코드를 작성하는 등 업무 범위가 서로 겹쳤다. - 제품 관리자는 일상적인 실행 관리에서 일부 벗어나 더 큰 전략적 질문에 집중했다. - 이 방식은 각 직무의 전문성을 없애는 것이 아니라, 프로젝트 상황에 따라 책임을 유연하게 배분하는 접근이다. ## 인수인계 대신 지속적인 대화 - 디자인 완료 후 개발로 넘기는 식의 일방적인 handoff를 줄였다. - 역할의 경계가 흐려지면서 팀원들은 서로에게 배우는 동시에 자신의 전문 지식을 공유하는 관계가 되었다. - 평소 각 직무가 독점하던 작업 방식과 판단 기준을 공개함으로써 협업에 필요한 신뢰를 쌓았다. - 결과적으로 디자인, 제품, 엔지니어링이 단계별로 분리된 프로세스가 아니라 지속적인 대화와 공동 결정에 가까워졌다. ## 실용적인 시사점 복잡한 기능을 개발할 때는 완벽한 사전 설계만 기다리기보다 작은 PR과 프로토타입으로 가설을 검증하는 것이 효과적이다. 또한 직무별 책임을 고정하기보다 문제의 성격에 따라 역할을 유연하게 조정하고, 인수인계 문서만으로 소통하기보다 실행 과정에서 지속적으로 대화하는 협업 구조를 만드는 것이 중요하다.

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

AI 에이전트Figmamcp-servercode-prototyping+2