cloudflare

78 개의 포스트

cloudflare

인증서 투명성 모니터링이 이제 정식 출시되었습니다 (새 탭에서 열림)

Cloudflare는 Certificate Transparency(CT) 모니터링에서 자사가 발급한 정상적인 인증서 갱신까지 알림으로 보내던 문제를 해결했다. 이제 Cloudflare가 관리·발급한 인증서는 자동으로 필터링하고, 외부에서 발급된 예상치 못한 인증서만 알림을 보낸다. 이를 위해 인증서 발급 초기부터 최종 인증서까지 유지되는 공개키 기반 식별자 `spki_sha256`를 사용한다. ## CT 모니터링의 알림 과다 문제 - CT 모니터링은 고객 도메인에 새로운 TLS 인증서가 공개 CT 로그에 등장하면 이메일을 보낸다. - 이 기능은 잘못 발급된 인증서를 조기에 발견하는 데 유용하지만, Cloudflare가 고객을 대신해 발급하는 인증서도 모두 알림 대상이었다. - Universal SSL, Advanced Certificate Manager, Total TLS, Backup Certificate 등의 정상적인 발급·갱신이 반복적으로 CT 로그에 기록된다. - 기존 인증서는 최대 60일마다 갱신될 수 있으며, 2029년에는 최대 유효기간이 47일로 줄어들 예정이라 정상 갱신 알림은 더욱 늘어날 수 있다. - 결과적으로 중요한 외부 인증서 발급 알림이 정상적인 갱신 알림에 묻히거나, 사용자가 기능을 꺼버리는 문제가 발생했다. ## 인증서 관리 시스템과 CT 알림 시스템의 단절 - 인증서 발급 시스템은 내부 발급 정보를 관리하고, CT 알림 시스템은 공개 CT 로그를 읽어 알림을 생성한다. - 두 시스템은 같은 인증서를 다루지만 처리 시점과 보유 정보가 다르다. - CT 알림 시스템이 로그를 확인하는 순간에는 해당 인증서가 Cloudflare 발급인지 알려주는 발급 시스템의 정보가 없었다. - 따라서 “이 인증서가 Cloudflare가 발급한 것인가?”를 판단할 연결 고리가 필요했다. ## 사전 인증서와 최종 인증서의 처리 순서 - 하나의 인증서 발급은 일반적으로 다음 두 단계로 CT 로그에 기록된다. - CA가 사전 인증서(pre-certificate)를 생성하고 로그에 기록한다. - SCT(Signed Certificate Timestamp)를 최종 인증서에 포함한 뒤 최종 인증서를 다시 로그에 기록한다. - 하나의 발급 요청에 대해 두 개의 로그 항목이 생기므로, Cloudflare는 `stripped_fingerprint`를 사용해 중복 알림을 방지했다. - `stripped_fingerprint`는 DER로 인코딩된 TBSCertificate의 해시이며, 사전 인증서와 최종 인증서 쌍을 식별하는 데 적합하다. - 그러나 발급 시스템은 사전 인증서를 받지 않기 때문에 이 값을 발급 초기에 계산할 수 없다. - 사전 인증서가 먼저 로그에 기록되는 짧은 시간 동안에는 발급 시스템 데이터베이스에 해당 fingerprint가 없어, Cloudflare가 발급한 인증서임에도 알림이 발생할 수 있었다. ## 공개키 기반 식별자 선택 새 식별자는 다음 조건을 만족해야 했다. - CT 로그에 기록되기 전에 생성될 것 - 사전 인증서와 최종 인증서 전반에서 동일할 것 - CT 알림 시스템이 로그 정보만으로 다시 계산할 수 있을 것 - 인증서 발급 요청마다 고유할 것 이 조건을 만족하는 값으로 인증서의 공개키가 선택됐다. - 공개키는 `SubjectPublicKeyInfo(SPKI)` 구조 안에 포함된다. - 키 생성 시점부터 CSR, 사전 인증서, 최종 인증서까지 동일하게 유지된다. - Cloudflare는 발급마다 새로운 키 쌍을 생성하므로 공개키는 사실상 발급 요청마다 고유하다. - 개인키는 Cloudflare만 보유하므로, 동일한 공개키를 가진 유효한 인증서는 Cloudflare 발급 과정에서 나온 것으로 판단할 수 있다. - Cloudflare는 DER 인코딩된 SPKI를 SHA-256으로 해시한 `spki_sha256` 값을 사용한다. ## `spki_sha256`를 이용한 알림 필터링 - 인증서 발급 시스템은 CSR에서 `spki_sha256`를 계산해 키 생성 시점에 데이터베이스에 저장한다. - CT 알림 시스템은 CT 로그에서 인증서를 발견하면 공개키로 동일한 `spki_sha256`를 다시 계산한다. - 이후 발급 시스템 데이터베이스에서 해당 값을 조회한다. - 값이 있으면 Cloudflare가 발급한 인증서로 간주하고 알림을 억제한다. - 값이 없으면 외부 발급 인증서로 간주하고 기존처럼 알림을 보낸다. - 사전 인증서와 최종 인증서의 공개키가 동일하므로 어느 항목이 먼저 처리되더라도 일관되게 판단할 수 있다. ## 필터링 적용 결과 - Cloudflare가 관리하는 Universal SSL, Advanced Certificate Manager, Total TLS, Backup Certificate는 정상적으로 알림에서 제외된다. - 사전 인증서만 로그에 남고 최종 발급이 중단된 경우에도 Cloudflare 발급 기록과 일치하므로 불필요한 알림이 발생하지 않는다. - 사용자가 직접 업로드한 커스텀 인증서는 Cloudflare가 키를 생성하지 않았으므로 발급 시스템에 일치하는 키 기록이 없다. - 따라서 외부에서 관리되는 커스텀 인증서나 예상치 못한 인증서 발급은 계속 알림 대상이다. Cloudflare의 개선은 정상적인 내부 인증서 갱신을 제거하면서도 외부 발급 인증서는 놓치지 않도록 해 CT 모니터링의 신호 대 잡음비를 높인 사례다. 사용자는 알림을 끄기보다, 이제 실제로 확인할 가치가 있는 인증서 발급 이벤트를 중심으로 대응할 수 있다.

cloudflare

Cloudflare DDoS 위협 보고서 2026년 상반기: DNS 플러드와 지정학적 긴장으로 새로운 물결이 일며 1Tbps 공격 급증 (새 탭에서 열림)

Cloudflare의 2026년 상반기 DDoS 보고서는 공격 규모가 급격히 커지는 동시에, 공격 방식이 봇넷 기반 대량 트래픽에서 DNS·CLDAP 같은 반사·증폭 공격으로 이동하고 있다고 분석한다. 상반기에만 네트워크 계층 공격 2,320만 건과 HTTP DDoS 요청 29조 6,400억 건이 차단됐으며, 1Tbps 초과 공격은 935건에 달했다. 공격 대부분은 짧고 자동화되어 발생하므로 수동 대응이 아닌 상시 자동화 방어가 필수라는 것이 보고서의 결론이다. ## 2026년 상반기 DDoS 규모 - Cloudflare는 2026년 1~6월 동안 다음 공격을 완화했다. - 네트워크 계층 DDoS: 2,320만 건 - HTTP DDoS 요청: 29조 6,400억 건 - 시간당 약 5,343건, 하루 약 12만 8,000건의 네트워크 계층 공격이 발생했다. - 2026년 4월에는 공격량이 정점에 도달했다. - HTTP 요청 6조 4,600억 건 - 네트워크 트래픽 165PB - 이후 공격량이 감소한 것은 21개국이 참여한 Operation PowerOFF의 영향일 가능성이 있다. - DDoS 대행 서비스 이용자 7만 5,000명 이상 대상 - 도메인 53개 폐쇄 - 수색영장 25건 발부 - 4명 체포 ## 초대형 공격의 급증 - 1Tbps, 10억 패킷/초(Bpps), 100만 요청/초(Mrps)를 초과하는 공격을 초대형 DDoS로 분류한다. - 상반기 1Tbps 초과 네트워크 공격은 총 935건이었다. - 특히 2분기에는 805건이 발생해 전 분기보다 6배 이상 증가했다. - 1Tbps를 넘는 공격은 대규모 인터넷 인프라까지 압박할 수 있는 수준이다. ## 대부분은 작고 짧지만 충분히 치명적 - 네트워크 계층 공격의 96.62%는 500Mbps 미만이었다. - 90.60%는 10분 이내에 종료됐다. - 그러나 “작은 공격”도 일반적인 서비스에는 치명적일 수 있다. - 100Mbps: 서버나 웹사이트를 마비시킬 수 있는 수준 - 100Gbps: 보호되지 않은 대부분의 데이터센터를 오프라인으로 만들 수 있는 수준 - 1Tbps 이상: 주요 인터넷 인프라까지 위협하는 초대형 공격 - 공격자는 대역폭과 패킷 속도를 조합해 네트워크 장비 또는 회선 용량의 약점을 노린다. - 공격 시간이 수십 초에 불과한 경우도 있어, 보안 담당자가 경보를 확인한 뒤 수동으로 대응하는 방식은 현실적으로 늦다. - 짧은 공격도 라우팅 불안정, TCP 재전송, 애플리케이션 타임아웃, 하위 서비스 장애 같은 장기적인 후속 피해를 유발할 수 있다. ## 공격 산업: 미디어와 정부 부문 ### 미디어·출판 산업의 지속적인 표적화 - Media, Production & Publishing 부문은 1·2분기 모두 가장 많이 공격받은 산업이었다. - 전체 완화 HTTP DDoS 요청의 14.2%를 차지해 2위 산업보다 약 4배 많았다. - 이란과 우크라이나 전쟁 관련 보도, 월드컵 등 국제적 관심이 집중된 사건이 공격 증가에 영향을 준 것으로 분석된다. ### Operation Epic Fury 이후 정부 공격 증가 - 2026년 2월 28일 이스라엘과 미국이 이란 지도부 및 인프라를 대상으로 Operation Epic Fury를 시작했다. - 이후 72시간 동안 16개국 110개 조직을 대상으로 한 핵티비스트 DDoS 공격 주장이 149건 보고됐다. - 표적 조직의 약 47.8%가 정부 부문이었다. - 정부 부문은 공격 비중 순위가 1분기 29위에서 2분기 9위로 급상승했다. ## 공격받은 국가 및 지역 - 2분기 기준 가장 많이 공격받은 국가는 중국으로, 전 세계 HTTP DDoS 요청의 22.4%를 차지했다. - 미국은 18.8%로 2위를 유지했다. - 튀르키예는 공격 비중이 두 배 이상 증가하며 3위로 올라섰다. - 이 증가는 2026년 앙카라 NATO 정상회의를 앞두고 보안 당국이 대규모 단속을 진행한 시기와 겹쳤다. ## 공격 발생지 국가 - 브라질이 미국을 제치고 상반기 DDoS 트래픽의 최대 발생지로 나타났다. - 브라질: 14.9% - 미국: 13.4% - 브라질은 2분기에만 전체 완화 DDoS 요청의 21.4%를 차지했다. - 인도네시아는 두 분기 모두 3위를 기록하며 주요 DDoS 발생지로 남았다. ## 공격 벡터의 변화 ### DNS Flood와 DNS Amplification의 확대 - DNS 기반 공격은 상반기 네트워크 계층 공격의 34.3%를 차지했다. - DNS Flood는 봇넷이 피해자의 권한 있는 DNS 서버에 대량 질의를 보내 처리 용량을 고갈시킨다. - DNS가 마비되면 해당 도메인에 의존하는 웹사이트와 서비스가 함께 영향을 받는다. - DNS Amplification은 위조된 출발지 IP를 사용해 개방형 DNS 리졸버에 작은 질의를 보내고, 더 큰 응답이 피해자에게 전달되도록 만드는 반사·증폭 공격이다. - DNS Flood 비중은 1분기 25.7%에서 2분기 40.0%로 상승했다. ### CLDAP 증폭 공격의 폭증 - CLDAP Flood는 노출된 Active Directory LDAP-over-UDP 엔드포인트를 악용하는 반사·증폭 공격이다. - 2분기에 전 분기 대비 580% 증가했다. - 그 결과 CLDAP Flood는 2분기 네트워크 계층 공격 벡터 중 3위가 됐다. - 이는 공격 중심이 단순한 봇넷 트래픽 폭주에서, 개방형 서비스와 프로토콜의 증폭 특성을 악용하는 방식으로 이동하고 있음을 보여준다. ## 실용적인 대응 방향 - 공격이 짧고 빠르게 끝나므로 수동·온디맨드 대응만으로는 부족하다. - DNS 인프라, 네트워크 회선, 애플리케이션 계층을 모두 포함하는 상시 자동화 방어가 필요하다. - CLDAP·DNS 등 반사·증폭에 악용될 수 있는 인터넷 노출 서비스를 점검하고, 불필요한 UDP 서비스와 개방형 리졸버를 차단해야 한다. - 공격 직후에도 재전송, 타임아웃, 라우팅 불안정 등 후속 장애를 확인해야 한다.

cloudflare

가장 중요한 임무를 지원하는 Cloudflare for Government, FedRAMP Class D(High) 인증 획득 (새 탭에서 열림)

Cloudflare는 공공기관용 서비스인 Cloudflare for Government에서 FedRAMP Class D(High) 인증을 획득했다고 발표했습니다. 이는 미국 정부의 가장 민감한 비기밀 데이터를 처리할 수 있는 높은 수준의 보안·감사·지속적 모니터링 요건을 충족했다는 의미입니다. 또한 이 인증에 사용한 시스템을 기반으로 미 국방부 DoD Impact Level 4(IL4) 승인도 추진하며, 별도 정부용 클라우드가 아닌 글로벌 단일 플랫폼에서 빠른 혁신과 강력한 보안을 제공하겠다는 전략을 강조했습니다. ### FedRAMP High 인증의 의미 - FedRAMP는 미국 연방정부 클라우드 서비스의 보안 평가, 승인, 지속적 모니터링을 표준화한 프로그램입니다. - ‘인증’은 단순한 자체 보안 선언이 아니라 다음 절차를 거친 공식 승인입니다. - 연방기관의 역량 검증 - 후원 기관의 전체 승인 절차 진행 - FedRAMP Program Management Office의 승인 확인 - Cloudflare는 2022년 FedRAMP Moderate 승인을 받았으며, 이번에는 더 높은 수준인 Class D(High)를 획득했습니다. - Moderate는 시스템 침해가 심각한 피해를 일으킬 수 있는 환경에 적용되지만, High는 다음과 같은 국가 핵심 데이터에 적용됩니다. - 법 집행 및 긴급 서비스 데이터 - 금융 시스템 정보 - 국가 안보 관련 데이터 - High 수준에서 보안 통제가 침해되면 인명 피해, 경제적 손실, 국가 안보 위협으로 이어질 수 있어 요구사항과 책임 수준이 크게 높아집니다. ### 분리된 정부용 클라우드의 한계 - 기존 기술 기업들은 공공 부문과 국방 부문을 위해 상용 플랫폼과 분리된 독립 환경을 구축하는 경우가 많았습니다. - 이런 방식은 보안과 규정 준수에는 유리할 수 있지만 다음 문제가 발생했습니다. - 상용 서비스와 정부용 서비스 사이에 기능 격차 발생 - 정부 환경이 최신 기술 적용에서 수년씩 뒤처짐 - 기관이 최신 기능과 엄격한 규정 준수 중 하나를 선택해야 함 - Cloudflare는 정부용 제품을 축소된 별도 플랫폼으로 만들지 않고, 상용 서비스와 동일한 글로벌 네트워크를 기반으로 구축했습니다. ### 하나의 글로벌 네트워크와 소프트웨어 정의 지역성 - Cloudflare는 전 세계 데이터센터에서 동일한 소프트웨어 스택과 서비스를 운영합니다. - FedRAMP High 서비스도 별도 장비나 고립된 네트워크가 아니라 동일한 인프라 위에서 동작합니다. - 핵심 기술은 Data Localization Suite입니다. - 데이터가 어디에서 처리되고 저장되는지 소프트웨어로 세밀하게 제어 - FedRAMP High 환경에서는 트래픽 검사와 처리를 미국 내 데이터센터로만 제한 - 글로벌 네트워크의 확장성과 미국 내 데이터 residency 및 처리 요건을 동시에 충족 - 따라서 연방기관은 기능이 제한된 정부용 버전이 아니라 다음과 같은 최신 기능을 사용할 수 있습니다. - Zero Trust 보안 도구 - 애플리케이션 성능 최적화 - 최신 개발자 플랫폼 기능 - 글로벌 네트워크 기반의 안정성과 확장성 ### DoD IL4 추진과 국방 분야의 혁신 속도 - Cloudflare는 FedRAMP High를 위해 설계한 시스템을 DoD Impact Level 4 승인 기반으로 활용할 계획입니다. - DoD IL4는 통제된 비기밀 정보(Controlled Unclassified Information)를 처리하기 위한 미 국방부의 사이버보안 기준입니다. - 동일한 시스템을 활용하면 국방용 환경을 별도로 구축할 필요가 줄어들고, FedRAMP High와 IL4 요구사항에 대응하는 보안 체계를 재사용할 수 있습니다. - 이를 통해 국방기관이 격리된 정부 클라우드의 느린 배포 주기에 묶이지 않고, 새로운 사이버 위협에 더 빠르게 대응할 수 있다는 것이 Cloudflare의 주장입니다. ### 공공 부문 현대화 전략 - Cloudflare는 이번 인증을 규정 준수 달성 이상의 의미로 설명합니다. - 공공기관이 다음과 같은 현대적 보안·서비스 운영 방식을 도입하도록 지원하는 것이 목표입니다. - Zero Trust 아키텍처 전환 - 정교한 DDoS 공격 방어 - 더 빠르고 복원력 높은 디지털 서비스 제공 - 국가 핵심 애플리케이션의 보안 강화 - 미국 국무부와 상무부 등 기존 연방기관과의 협력도 이번 인증을 계기로 확대할 계획입니다. 실무적으로는 FedRAMP High가 필요한 기관이라면 Cloudflare의 미국 내 데이터 처리 통제, 동일 플랫폼 기반의 최신 기능 제공 여부, 그리고 향후 DoD IL4 승인 진행 상황을 함께 확인하는 것이 적절합니다.

cloudflare

에이전틱 인터넷의 좋은 행동과 나쁜 행동을 파헤치다 (새 탭에서 열림)

인터넷 트래픽은 인간과 봇으로 단순히 나눌 수 없으며, 한 세션 안에서 인간과 에이전트가 번갈아 행동하는 하이브리드 트래픽도 증가하고 있다. 따라서 사이트 운영자는 일회성 검사보다 세션 전체의 행동을 분석해 위험(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 같은 단발성 방어책에만 의존하기보다 세션 전체의 행동, 봇의 신원 공개, 목적과 데이터 사용 방식을 함께 평가하는 것이 좋다. 정상적인 자동화는 투명성과 신뢰를 바탕으로 허용하고, 신뢰를 악용하거나 세션 중간에 비정상 행동을 보이는 트래픽은 지속적으로 재평가하는 접근이 적절하다.

cloudflare

Cloudflare 앰배서더와 커뮤니티 엔지니어, 그리고 오픈 소스에 대한 추가 100만 달러 지원 발표 (새 탭에서 열림)

Cloudflare는 개발자들이 서로 가르치고, 오픈소스에 기여하며, 커뮤니티를 성장시키는 활동을 체계적으로 지원하기 위해 커뮤니티 프로그램을 개편한다. 프로그램은 커뮤니티 행사를 이끄는 **Cloudflare Ambassadors**와 오픈소스 프로젝트에 기여하는 **Cloudflare Community Engineers**의 두 축으로 운영된다. 또한 빠르게 성장한 Discord 커뮤니티를 자동화 도구와 새로운 운영위원회로 개선할 계획이다. ## 커뮤니티 프로그램 개편 - Cloudflare는 개발자 교육, 행사 운영, 오픈소스 유지보수처럼 인터넷 생태계에 기여하는 사람들을 지원하고 인정하려 한다. - 새 프로그램의 두 가지 트랙은 다음과 같다. - **Cloudflare Ambassadors**: 각자의 지역·학교·온라인 커뮤니티에 Cloudflare를 알리고 활동을 확산 - **Cloudflare Community Engineers**: 인터넷과 Cloudflare 생태계를 개선하는 오픈소스 프로젝트에 기여 - 프로그램 관련 정보와 참여 신청은 `cloudflare.com/community`에서 제공된다. ## Cloudflare Ambassadors의 역할 - 앰배서더는 Cloudflare를 자신의 커뮤니티에 소개하고, 다른 개발자들이 실제로 제품을 활용하도록 돕는다. - 활동 사례는 다음과 같다. - 밋업, 해커톤, 워크숍, 강연 개최 - 대학 내 학생 그룹 운영 - 개발자가 함께 학습할 수 있는 공간 조성 - 튜토리얼 작성과 온라인 콘텐츠 공유 - Cloudflare의 활용 가능성을 설명하는 기술 지원 - 선정된 앰배서더는 최대 2년 동안 활동할 수 있어, 단기 이벤트가 아니라 지속적인 커뮤니티 성장을 추진할 수 있다. ## 앰배서더 지원 내용 - 커뮤니티 행사를 개최할 때 다음과 같은 지원을 신청할 수 있다. - Cloudflare 크레딧 - 마케팅 자료 - 기술 리소스 - 행사 운영에 필요한 추가 지원 - Discord 등 Cloudflare 온라인 커뮤니티에서 공식적인 역할과 식별 표시를 제공한다. - 당시 지원서 접수 기간은 9월 6일까지이며, 선정 결과는 10월 5일까지 통보될 예정이었다. - 미시간대학교 학생 Sruthi Pereddy의 사례처럼, 학생과 개발자들이 리소스 부족 때문에 아이디어를 실행하지 못하는 문제를 Cloudflare 인프라로 해결하려는 활동을 장려한다. ## Cloudflare Community Engineers와 오픈소스 지원 - Cloudflare Developer Platform은 `workerd`, `quiche` 등 오픈소스 프로젝트에 크게 의존하거나 직접 오픈소스로 제공된다. - 유지보수자와 기여자는 장기간 핵심 라이브러리, 문서, 도구, 커뮤니티를 관리하지만 그 기여가 충분히 보상받지 못하는 경우가 많다. - Cloudflare는 기존 TanStack 후원에 이어 Community Engineers 프로그램을 통해 오픈소스 기여자에게 직접적인 지원을 제공한다. - 향후 2년 동안 오픈소스 프로젝트 후원과 지원에 **추가 100만 달러**를 투입하고, 자격을 갖춘 Community Engineer에게 보조금을 지급한다. - 프로그램에는 최대 활동 기간이 없다. - 오픈소스 유지보수는 연 단위 일정에 맞지 않을 수 있다. - 어떤 프로젝트는 수년간 관리가 필요하고, 어떤 기여는 특정 시점에 집중적으로 발생하기 때문이다. - 초기 지원 대상은 Cloudflare 오픈소스 생태계와 가까운 프로젝트다. - Astro - Agents SDK - EmDash - Hono - Vinext - Community Engineer에게는 Cloudflare Discord와 기타 온라인 공간에서 특별한 표식이 부여된다. - 보조금 신청은 추후 시작될 예정이다. ## Cloudflare Discord 커뮤니티 개선 - 2020년 개설된 Cloudflare Discord에는 약 10만 명의 사용자가 참여했다. - Discord는 질문, 프로젝트 공유, 제품 피드백이 이루어지는 주요 공간으로 성장했다. - 커뮤니티가 커질수록 스팸, 악성 링크, 운영 부담도 증가하기 때문에 다음과 같은 개선을 추진한다. - Cloudflare 직원과 앰배서더가 참여하는 새로운 Discord 위원회 구성 - 스팸과 악성 링크를 차단하는 자동화 도구 도입 - 운영 자동화 도구를 향후 오픈소스로 공개 - 위원회의 핵심 역할은 단순한 관리자 업무나 채팅방 감시가 아니다. - 질문자를 적절한 도메인 전문가에게 연결 - Cloudflare 내부 팀과 커뮤니티 간 대화 주선 - 기술 세션과 협업 기회 마련 - 커뮤니티 콘텐츠와 성장 기회에 집중 - 제공된 글은 Discord를 “더 쉽게…” 개선하겠다는 대목에서 끝나므로, 이후 구체적인 계획은 확인할 수 없다. Cloudflare의 방향은 단순히 제품 사용자를 늘리는 데서 벗어나, 교육자·행사 주최자·오픈소스 유지보수자를 장기적으로 지원하는 생태계를 만드는 데 있다. Cloudflare를 활용하는 개발자라면 앰배서더 프로그램을, 관련 오픈소스 프로젝트를 유지하거나 기여한다면 Community Engineer 보조금 프로그램을 검토할 만하다.

cloudflare

순위에서 추천으로: 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 봇 방문 수를 늘리는 것보다 실제 추천과 출처 인용으로 이어지는 구조를 만드는 데 집중해야 한다.

cloudflare

어떤 웹사이트에든 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는 크롤링을 대체하는 에이전트 친화적 인터페이스를 제공하지만, 현재는 개발자 프리뷰이므로 브라우저 지원과 표준 변화, 서명 검증 범위를 함께 고려해 시험적으로 도입하는 것이 적절하다.

cloudflare

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 키 직접 공유 대신 리소스별 최소 권한과 감사 가능한 접근 정책을 설계하는 것이 중요하다.

cloudflare

에이전트 개발 수명주기가 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 기반 인프라부터 구축해야 한다.

cloudflare

수백만 개 리포지토리의 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 지연 시간을 줄일 수 있으며, 배포는 모든 검증 단계가 성공한 뒤에만 실행하도록 구성하는 것이 안전하다.

cloudflare

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 준수 단계는 아니라는 점을 고려해야 한다.

cloudflare

MoQ를 위한 API: 자체 격리 릴레이 프로비저닝 (새 탭에서 열림)

Cloudflare는 MoQ(Media over QUIC)를 애플리케이션용으로 운영할 수 있도록 격리된 릴레이와 인증·권한 관리 기능을 추가했다. 프로비저닝 API나 대시보드에서 릴레이를 생성하면 별도 서버나 로드 밸런서 없이 Cloudflare 전역 네트워크에 수초 내 배포된다. 퍼블리셔와 구독자에게 서로 다른 토큰을 발급해 실시간 미디어 스트림의 접근 권한도 분리할 수 있다. ## MoQ의 구조와 장점 - MoQ는 IETF에서 개발 중인 공개 표준 기반의 publish/subscribe 프로토콜이다. - 퍼블리셔는 이름이 지정된 데이터 스트림을 전송하고, 구독자는 스트림 이름으로 원하는 데이터를 요청한다. - 릴레이는 데이터 내용을 해석하지 않고 스트림을 구독자들에게 복제·전달한다. - 하나의 프로토콜로 라이브 비디오, 화상 통화, 저지연 메시징 등 다양한 실시간 데이터를 처리할 수 있다. - QUIC을 기반으로 하므로 HTTP/3와 같은 낮은 지연 특성을 활용한다. - 애플리케이션이 직접 미디어 서버를 구축하거나 대규모 fan-out 서버를 운영할 필요가 줄어든다. ## 공개 프리뷰의 한계 - Cloudflare는 지난해 330개 이상의 도시에 있는 서버를 MoQ 릴레이로 개방했다. - 인증 없이 누구나 사용할 수 있어 프로토콜 테스트와 클라이언트 개발에 적합했다. - 그러나 인증이 없으면 누가 퍼블리시하거나 구독할 수 있는지 통제할 수 없다. - 예를 들어 경매 서비스에서는 시청자가 방송자의 트랙을 탈취하지 못하도록 퍼블리셔와 구독자의 권한을 분리해야 한다. - 따라서 기밀성, 인증, 역할 기반 접근 제어가 필요한 운영 환경에는 기존 공개 릴레이를 사용할 수 없었다. ## Cloudflare 릴레이의 격리 방식 - 릴레이를 생성해도 VM, 컨테이너, 전용 프로세스가 새로 실행되는 것은 아니다. - 기존 Cloudflare 글로벌 네트워크 위에 애플리케이션별 격리된 범위를 생성한다. - 각 범위는 다음을 분리한다. - 애플리케이션의 네임스페이스 - 미디어 트랙과 객체 - 접속 가능한 클라이언트 - 퍼블리시·구독 권한 - 클라이언트는 Anycast 엔드포인트에 접속하고, Cloudflare가 전 세계 네트워크로 라우팅한다. - 지역 선택, 용량 산정, 서버 배포, 로드 밸런서 설정 없이 즉시 사용할 수 있다. - 웹 호스팅에서 새 서버를 띄우는 것보다 가상 호스트를 추가하는 방식에 가깝다. ## 프로비저닝 API와 토큰 권한 - 프로비저닝 API는 미디어 데이터를 처리하지 않는 제어 평면이다. - 관리 대상은 두 가지다. - **Relay**: 애플리케이션별로 격리된 MoQ 실행 범위 - **Token**: 특정 릴레이에 대한 작업 권한을 부여하는 인증 정보 - 토큰은 다음 권한을 조합할 수 있다. - `publish` - `subscribe` - `publish`와 `subscribe` 모두 - 토큰마다 만료 시간을 설정할 수 있고, 개별적으로 폐기할 수 있다. - 기본적으로 토큰 권한은 릴레이 전체에 적용된다. - 현재는 세부 트랙별 권한보다 릴레이 단위 권한을 제공하며, 향후 더 정교한 권한 체계를 개발할 예정이다. - Cloudflare는 MoQ Transport draft-14와 draft-16 및 인증 기능을 지원한다. ## 릴레이 생성과 기본 토큰 - HTTP API에서는 릴레이 이름만 지정해 생성할 수 있다. - 생성 결과로 릴레이 ID와 기본 토큰 2개가 반환된다. - 퍼블리시와 구독이 모두 가능한 토큰 - 구독만 가능한 토큰 - 추가 토큰을 생성해 시청자, 방송자, 운영 도구 등 역할별로 권한을 세분화할 수 있다. - 예를 들어 시청자용 토큰은 `subscribe`만 허용하고, 2027년 1월 1일 만료되도록 설정할 수 있다. - 동일한 작업은 Cloudflare 대시보드의 **Media > Realtime > MoQ Relay** 메뉴에서도 수행할 수 있다. - 릴레이는 베타 기간 동안 무료로 제공된다. ## 퍼블리셔와 구독자의 연결 - 방송자에게는 `publish` 권한이 포함된 토큰을 제공한다. - 시청자에게는 `subscribe` 전용 토큰을 제공한다. - 클라이언트는 MoQ 세션을 열 때 토큰을 전달한다. - 릴레이는 토큰의 권한을 확인해 퍼블리시와 구독 작업을 허용하거나 거부한다. - 토큰은 MoQ 접속 URL 경로를 통해 전달되며, `moq-rs` 같은 오픈소스 도구와 FFmpeg를 이용해 fragmented MP4 스트림을 퍼블리시할 수 있다. ## 실용적인 결론 실시간 영상이나 저지연 데이터 서비스를 구축한다면 Cloudflare MoQ 릴레이를 통해 서버 운영과 확장 부담을 줄일 수 있다. 운영 시에는 방송자와 시청자 토큰을 반드시 분리하고, 만료 기간과 폐기 정책을 설정해 권한 탈취 위험을 최소화하는 것이 좋다.

cloudflare

오리진에 대한 양자 이후 인증이 이제 지원됩니다 (새 탭에서 열림)

Cloudflare는 Cloudflare와 고객의 원본 서버 사이 연결에 ML-DSA 기반의 포스트퀀텀(PQ) 인증을 지원하기 시작했다. 이제 Custom Origin Trust Store와 Authenticated Origin Pulls를 조합하면 원본 서버 연결을 암호화할 뿐 아니라 양쪽을 포스트퀀텀 방식으로 인증하는 mTLS 구성이 가능하다. 이는 Cloudflare가 2029년까지 완전한 포스트퀀텀 보안을 달성하기 위해 세운 로드맵의 첫 번째 주요 milestone이다. ## 포스트퀀텀 인증이 필요한 이유 - 기존에는 양자컴퓨터가 현재의 암호화를 미래에 해독하는 ‘수집 후 해독(harvest-now/decrypt-later)’ 공격에 대비해 포스트퀀텀 암호화를 우선 배포했다. - 최근 양자컴퓨팅과 암호해석 기술의 발전으로, 공격자가 고전적 인증서를 위조해 서버나 클라이언트를 사칭하는 위험에도 대비해야 하게 됐다. - Cloudflare는 다음 연결에 대해 이미 포스트퀀텀 암호화를 지원하고 있다. - 방문자와 Cloudflare 간 연결: 2022년 지원 - Cloudflare와 원본 서버 간 연결: 2023년 지원 - 이번 변경은 여기에 포스트퀀텀 인증을 추가한 것이다. ## Cloudflare-원본 서버 연결의 특성 - 웹사이트 요청에는 일반적으로 두 개의 TLS 연결이 사용된다. - 방문자 → Cloudflare - Cloudflare → 고객 원본 서버 - Cloudflare-원본 서버 연결에서는 Cloudflare가 TLS 클라이언트 역할을 하므로 인증 방식을 직접 통제할 수 있다. - Cloudflare는 여러 요청을 적은 수의 연결로 묶는 connection pooling을 사용해 PQ 서명에 따른 연결 설정 비용을 분산할 수 있다. - 고객과 이미 Cloudflare 계정 기반의 신뢰 관계가 있으므로, 공개 웹 PKI의 제약 없이 용도에 맞는 사설 PKI를 사용할 수 있다. - 중간 인증서 체인과 Certificate Transparency가 필요하지 않을 수 있다. - 공개 웹의 인증서 생태계보다 빠르게 ML-DSA 인증을 배포할 수 있다. - 방문자-Cloudflare 연결에서는 향후 Merkle Tree Certificates(MTC)를 활용할 계획이며, 초기 배포 목표는 2027년이다. ## 지원되는 ML-DSA 구성 - Cloudflare는 FIPS 204의 세 가지 ML-DSA 파라미터 세트를 지원한다. - ML-DSA-44 - ML-DSA-65 - ML-DSA-87 - 대부분의 애플리케이션에는 성능이 가장 우수하고 NIST 보안 강도 카테고리 2를 제공하는 ML-DSA-44가 권장된다. ## Custom Origin Trust Store를 이용한 원본 인증 - Full (strict) SSL 모드에서 Cloudflare는 원본 서버의 인증서를 신뢰 저장소와 대조한다. - 기본적으로 일반적으로 신뢰되는 CA와 Cloudflare Origin CA가 사용된다. - Custom Origin Trust Store(COTS)를 사용하면 고객이 관리하는 CA 목록으로 기본 신뢰 저장소를 대체할 수 있다. - 이제 ML-DSA CA를 업로드할 수 있으며, Cloudflare는 해당 CA로부터 발급된 원본 서버 인증서만 신뢰하도록 구성할 수 있다. - COTS 사용에는 Advanced Certificate Manager가 필요하다. ## Authenticated Origin Pulls를 이용한 상호 인증 - Authenticated Origin Pulls(AOP)는 원본 서버가 Cloudflare에서 온 요청만 처리하도록 제한하는 기능이다. - Cloudflare가 클라이언트 인증서를 제시하므로 원본 서버는 요청 주체가 Cloudflare인지 검증할 수 있다. - 이를 통해 Cloudflare와 원본 서버 간 상호 TLS(mTLS)를 구성할 수 있다. - AOP는 모든 Cloudflare 요금제에서 무료로 제공된다. - 영역(zone)별 및 호스트명별 설정에서 다음을 업로드할 수 있다. - ML-DSA 인증서 - ML-DSA 개인 키 - 개인 키는 현재 FIPS 204 seed 형식으로만 업로드할 수 있다. - 전역(global) 설정의 ML-DSA 지원은 아직 제공되지 않으며 추후 작업으로 예정되어 있다. ## 다운그레이드 공격 방지 - 양쪽이 PQ 인증을 지원하는 것만으로는 완전한 포스트퀀텀 보안이 보장되지 않는다. - 원본 서버가 기존의 양자 취약 인증 방식도 계속 신뢰하면, 공격자가 고전적 인증서를 위조해 연결을 다운그레이드할 수 있다. - 따라서 인증서를 검증하는 원본 서버는 양자 취약한 인증 메커니즘에 대한 신뢰를 제거해야 한다. - 복잡한 PKI에서는 인증 체계 전환 단계와 신뢰 설정을 별도로 설계해야 한다. ## 구성에 필요한 도구와 절차 - 인증서 생성에는 OpenSSL 3.5.0 이상이 필요하다. - Cloudflare가 현재 허용하는 개인 키 형식은 FIPS 204의 seed-only 인코딩이다. - 일반적인 구성 절차는 다음과 같다. - ML-DSA-44 등의 알고리즘으로 원본 서버용 CA와 인증서 체인을 생성한다. - 생성한 CA를 COTS에 업로드한다. - ML-DSA 클라이언트 인증서와 개인 키를 AOP의 영역별 또는 호스트명별 설정에 업로드한다. - Cloudflare API 또는 대시보드를 통해 원본 서버의 mTLS 및 인증서 검증을 활성화한다. - 원본 서버에서 양자 취약 인증서와 인증 기관을 신뢰하지 않도록 설정한다. ## 실용적인 권장 사항 대부분의 사용자는 ML-DSA-44를 사용해 COTS와 AOP를 함께 구성하는 것이 적절하다. 단순히 ML-DSA 인증서를 추가하는 데 그치지 말고, 원본 서버의 신뢰 저장소에서 기존 양자 취약 인증 방식을 제거해야 다운그레이드 공격까지 방어할 수 있다.

cloudflare

캐시 응답 규칙 소개 (새 탭에서 열림)

Cloudflare의 Cache Response Rules는 원본 서버 응답이 도착한 뒤, 캐시에 저장되기 전에 응답 헤더와 캐시 지시사항을 수정하는 기능이다. `Set-Cookie`, 잘못된 `Cache-Control`, 과도한 `ETag` 등으로 캐시되지 않던 콘텐츠를 원본 코드 변경 없이 캐시 가능하게 만들 수 있다. 다만 캐시 키처럼 요청 단계에서 이미 결정된 사항은 변경할 수 없으므로 기존 Cache Rules를 대체하지 않고 보완한다. ## 캐싱 판단이 이루어지는 시점 - CDN은 가능한 한 캐시에서 응답하고, 캐시에서 처리할 수 없을 때만 원본 서버에 요청한다. - 캐시 적중률이 낮으면 원본 서버의 대역폭과 인프라 비용이 증가하고 응답 속도도 느려진다. - 원본 서버의 응답 헤더는 다음과 같은 캐싱 정책을 결정한다. - 얼마나 오래 캐시할지 - 언제 재검증할지 - 애초에 캐시할 수 있는지 - 많은 캐싱 문제는 요청 시점이 아니라 원본 응답이 도착한 뒤에 드러난다. - 정적 파일에 실수로 `Set-Cookie`가 포함됨 - 캐시해도 안전한 리소스에 `Cache-Control: no-cache`가 설정됨 - 브라우저용 지시사항이 Cloudflare 캐싱에도 적용됨 - 지나치게 공격적인 `ETag`로 조건부 요청마다 재검증이 발생함 ## 기존 방식의 한계 - 요청 단계에서는 원본 서버가 반환할 응답 헤더를 알 수 없다. - 따라서 요청 시점에 동작하는 Cache Rules만으로는 `Set-Cookie`, `ETag`, `Last-Modified`, 원본의 `Cache-Control` 문제를 해결할 수 없다. - 기존 선택지는 다음과 같았다. - 원본 서버 코드나 설정 변경 - Worker로 응답을 다시 가져와 헤더 수정 - 낮은 캐시 적중률을 감수 - 특히 원본 서버 담당 팀과 CDN 담당 팀이 다르면 단순한 헤더 하나를 바꾸는 데도 긴 조율이 필요했다. ## Cache Response Rules의 동작 방식 - 실행 시점은 다음과 같다. 1. Cloudflare가 캐시 미스 후 원본 서버에 요청 2. 원본 응답 수신 3. Cache Response Rules 적용 4. 수정된 응답을 Cloudflare 캐시에 저장 - 다음과 같은 응답 변경이 가능하다. - `Set-Cookie` 제거 - `ETag` 및 `Last-Modified` 제거 - `Cache-Control` 지시사항 수정 - 캐시 태그 설정 및 관리 - 모든 변경은 Cloudflare에서 처리되므로 원본 애플리케이션이나 서버 설정을 수정할 필요가 없다. ## Cache Rules와 Cache Response Rules의 역할 차이 - **Cache Rules**는 요청 단계에서 동작한다. - 응답을 캐시할지 여부 - 어떤 캐시 키로 저장할지 - Edge TTL, 브라우저 TTL, stale 응답 제공 여부 - **Cache Response Rules**는 응답 단계에서 동작한다. - 원본 응답이 캐시에 적합한지 조정 - 캐시를 막는 헤더 제거 - 원본의 `Cache-Control` 수정 - 캐시 태그 설정 - 두 규칙이 충돌하면 Cache Response Rules가 우선한다. - 하지만 응답 단계에서는 캐시 키를 변경할 수 없다. 캐시 키는 원본 요청 전에 이미 결정되기 때문이다. ## 응답 단계에서 가능한 것과 불가능한 것 - 가능한 작업: - `Set-Cookie`를 제거해 캐시 가능하게 만들기 - 캐시 가능한 응답에 `no-store`를 설정해 저장하지 않기 - 원본의 캐시 TTL이나 캐시 지시사항 변경 - 캐시 무효화를 위한 태그 지정 - 불가능한 작업: - 이미 정해진 캐시 키 변경 - 요청 단계에서 캐시 대상에서 제외된 요청을 뒤늦게 캐시 대상으로 전환 - 따라서 Cache Response Rules는 Cache Rules의 대체재가 아니라, 원본 응답 헤더를 보정하는 보완 기능이다. ## 실용적인 결론 정적 리소스가 불필요한 `Set-Cookie`나 잘못된 `Cache-Control` 때문에 캐시되지 않는다면, 원본 서버를 수정하기 전에 Cache Response Rules를 활용하는 것이 효율적이다. 다만 캐시 여부의 기본 정책과 캐시 키는 Cache Rules에서 먼저 설계하고, 응답 단계에서는 헤더와 TTL 등 원본 응답의 캐시 관련 정보를 보정하는 방식으로 함께 사용하는 것이 적절하다.

cloudflare

Cloudflare WAF, 두 가지 고위험 취약점으로부터 WordPress 애플리케이션 보호 (새 탭에서 열림)

Cloudflare는 WordPress의 REST API 관련 SQL 인젝션과 인증 없는 원격 코드 실행(RCE) 취약점을 차단하는 WAF 규칙을 모든 고객에게 배포했습니다. 다만 WAF는 임시 방어 수단일 뿐이며, WordPress를 보안 수정 버전으로 업데이트하는 것이 근본적인 해결책입니다. 영향을 받는 사이트는 자동 업데이트 여부와 Cloudflare 규칙의 차단 상태를 반드시 확인해야 합니다. ### 취약점의 범위와 심각도 - **CVE-2026-60137 — SQL 인젝션** - WordPress 6.8 이상에 존재합니다. - 공격자가 조작된 입력값으로 데이터베이스 쿼리를 변경할 수 있습니다. - 심각도는 **High**입니다. - **CVE-2026-63030 — 인증 없는 원격 코드 실행** - WordPress 6.9 이상에서 발생합니다. - 영구 객체 캐시를 사용하지 않는 경우 REST API의 배치 엔드포인트를 통해 인증 없이 코드 실행이 가능합니다. - 로그인이나 사용자 상호작용이 필요하지 않으며, 심각도는 **Critical**입니다. - SQL 인젝션 취약점과 연관된 공격 경로를 사용합니다. - WordPress 6.8 미만 버전은 영향을 받지 않습니다. ### WordPress 보안 업데이트 - 수정 버전: - **7.0.2**: 두 취약점 모두 해결 - **6.9.5**: 두 취약점 모두 해결 - **6.8.6**: SQL 인젝션만 해결 - **7.1 Beta 2**: 두 취약점 모두 해결 - WordPress 보안팀은 이를 최고 심각도·최우선순위 문제로 분류하고 영향을 받는 사이트에 자동 업데이트를 강제하고 있습니다. - 자동 업데이트가 실행되었더라도 실제 설치 버전이 수정 버전인지 확인해야 합니다. ### Cloudflare WAF 차단 규칙 - Cloudflare는 2026년 7월 17일 17:03 UTC에 두 규칙을 배포했습니다. - 두 규칙 모두 기본 동작은 **Block**입니다. - SQL 인젝션 규칙: - CVE: `CVE-2026-60137` - Managed Ruleset ID: `1c060d3a371549219ee290d7ed933fcc` - Free Ruleset ID: `db003b39b7774859a8d588ce33697a1a` - 원격 코드 실행 규칙: - CVE: `CVE-2026-63030` - Managed Ruleset ID: `7dfb2bd4708d4b88b9911dc0550664b6` - Free Ruleset ID: `ebd3f2df15c74ddcbf6220c9b5ec246a` - Pro, Business, Enterprise 고객은 Cloudflare Managed Rules가 활성화되어 있는지 확인해야 합니다. - Free 요금제는 Free Ruleset을 통해 자동으로 보호됩니다. - 규칙 전체를 `Log`로 변경하는 규칙셋 수준 오버라이드가 있다면 제거하거나, 해당 규칙을 권장 동작인 `Block`으로 설정해야 합니다. ### 두 단계의 방어와 모니터링 - SQL 인젝션 규칙은 악성 파라미터가 WordPress에 도달하기 전에 탐지합니다. - RCE 규칙은 원격 코드 실행 경로에 접근하려는 요청을 차단합니다. - Cloudflare **Security Events**에서 두 규칙과 일치하는 요청을 확인해야 합니다. - 즉시 업데이트할 수 없는 경우에도 규칙이 활성화되어 있고 `Block` 상태인지 확인한 뒤, 관련 REST API 엔드포인트에 대한 의심스러운 요청을 조사해야 합니다. - WAF는 취약한 WordPress 코드를 수정하지 않으므로 패치를 대체할 수 없습니다. ### 향후 대응 - Cloudflare는 탐지된 트래픽을 지속적으로 분석하고 새로운 공격 변형에 맞춰 규칙을 업데이트할 예정입니다. - WordPress 운영자는 수정 버전으로 업데이트하고, WAF 차단 규칙과 보안 이벤트 로그를 함께 점검하는 방식으로 방어 계층을 구성하는 것이 권장됩니다.