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

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 차단 규칙과 보안 이벤트 로그를 함께 점검하는 방식으로 방어 계층을 구성하는 것이 권장됩니다.

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

cloudflarevulnerability-managementrest-apiweb-application-firewall+3

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

잘못된 DNSSEC 롤오버로 .AL이 다운됐다. 이제 1.1.1.1이 검증 우회 시점을 알려준다

2026년 7월 3일, 알바니아의 .AL 운영자가 DNSSEC 키 롤오버를 잘못 수행해 루트 영역의 DS 레코드와 실제 DNSKEY가 불일치했고, 검증하는 DNS 리졸버에서 .AL 전체가 장애를 겪었다. Cloudflare는 임시로 Negative Trust Anchor(NTA)를 적용해 접속을 복구했지만 DNSSEC 검증을 우회해야 했다. 이번에는 응답에 Extended DNS Error(EDE) 코드 33을 함께 반환해, 클라이언트가 해당 응답이 NTA 때문에 검증되지 않았음을 알 수 있도록 했다. ### .AL DNSSEC 장애의 발생 과정 - DNSSEC는 루트 영역의 DS 레코드에서 TLD의 DNSKEY로 이어지는 신뢰 체인을 구성한다. - 14:15 UTC경 .AL 운영자가 새 DNSKEY를 게시하고 기존 키를 제거했다. - 루트 영역의 DS 레코드는 여전히 기존 키 `id=26319`를 가리키고 있었다. - 리졸버는 일치하는 DNSKEY를 찾지 못해 검증에 실패했다. - 17:00 UTC경 새 DNSKEY까지 제거되면서 .AL 영역에 DNSKEY가 전혀 남지 않았다. - 19:15 UTC경 루트 영역에서 .AL의 DS 레코드를 제거하자 검증 대상이 사라져 DNS 조회가 복구됐다. - 게시 시점에도 .AL은 서명되지 않은 상태였으며, 모든 .AL 도메인은 DNSSEC 보호를 사용할 수 없었다. ### 장애가 .AL 전체로 확산된 이유 - .AL TLD 자체의 DNSSEC 신뢰 체인이 끊어지면 그 하위의 모든 도메인도 검증할 수 없다. - 도메인이 어디에 호스팅되어 있거나 어떤 권위 DNS 서버를 사용하든, 검증 리졸버는 DNSSEC 실패를 감지하면 응답 대신 `SERVFAIL`을 반환한다. - 캐시된 레코드가 만료될수록 재검증 요청이 늘어나 `SERVFAIL` 비율이 상승했다. - Cloudflare 1.1.1.1은 17:15 UTC에 NTA를 배포한 뒤 정상 응답을 제공하면서 장애가 급격히 완화됐다. ### Negative Trust Anchor를 통한 복구 - RFC 7646의 NTA는 특정 영역을 서명되지 않은 영역처럼 취급해 DNSSEC 검증을 일시적으로 우회한다. - Cloudflare는 .AL 운영자와 직접 연락하려 했지만, 연락처 역시 .AL 도메인에 있어 장애 중 접근할 수 없었다. - 약 3시간 후 .AL에 NTA를 적용해 1.1.1.1 사용자에게 정상적인 DNS 응답을 제공했다. - NTA의 대가로 해당 기간 동안 .AL 응답은 DNSSEC로 암호학적 진위를 보장받지 못했다. - 장애가 공개적으로 확인됐고 모든 검증 리졸버에 영향을 주고 있었기 때문에, 도메인 접근성을 유지하는 편이 낫다고 판단했다. - 루트 영역에서 DS 레코드가 제거된 다음 날 NTA를 삭제했다. ### NTA의 보안상 문제 - NTA가 적용된 응답은 일반적인 성공 응답과 겉보기에는 동일하다. - 사용자는 응답만 보고 DNSSEC 검증이 수행됐는지, 위조 가능성이 남아 있는지 알 수 없었다. - RFC 7646은 운영자가 NTA 적용 현황을 공개하도록 권고하지만, 상태 페이지나 공지는 사용자가 직접 확인해야 한다. - 애플리케이션, 모니터링 도구, 일반 DNS 클라이언트가 응답 자체만으로 검증 우회를 감지할 방법이 부족했다. ### EDE를 이용한 투명성 확보 - RFC 8914의 Extended DNS Error는 정상 응답이나 오류 응답에 추가 설명을 포함할 수 있다. - Quad9의 Babak Farrokhi가 NTA 적용 사실을 DNS 응답에 표시하는 새 EDE 코드를 제안했고, Cloudflare가 공동 저자로 참여했다. - 1.1.1.1은 .AL 장애 중 다음 정보를 함께 반환했다. - `EDE: 9 (DNSKEY Missing)`: DS와 일치하는 DNSKEY를 찾지 못했다는 원래 검증 오류 - `EDE: 33 (Negative Trust Anchor)`: 해당 조회에 NTA가 적용되어 DNSSEC 검증이 우회됐다는 사실 - 따라서 클라이언트는 `NOERROR`와 실제 IP 주소를 받더라도, 그 응답이 검증된 결과가 아님을 구분할 수 있다. ### 실용적인 결론 DNSSEC 장애 시 NTA는 대규모 접속 장애를 완화하는 유용한 비상 수단이지만, 보안 검증을 포기하는 조치이므로 제한적으로 사용해야 한다. DNS 리졸버와 모니터링 도구는 EDE, 특히 NTA를 나타내는 코드 33을 확인해 검증 우회 상태를 사용자와 시스템에 명확히 알려야 하며, TLD 운영자는 키 롤오버 전에 DS·DNSKEY 전환 절차를 철저히 검증해야 한다.

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

cloudflarednsdnssecnegative-trust-anchor+2

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

Precursor 소개: 지속적인 클라이언트 측 신호를 통한 에이전트형 행동 탐지

Cloudflare의 Precursor는 개별 요청이나 챌린지 결과가 아니라 웹사이트 전체 세션에서 나타나는 행동 패턴을 지속적으로 분석해 인간과 봇·에이전트 트래픽을 구분하는 클라이언트 측 검증 시스템이다. Turnstile이 로그인·가입·결제 같은 특정 시점의 검증을 담당한다면, Precursor는 사용자 여정 전반의 신호를 수집해 탐지 정확도를 높이고 불필요한 챌린지를 줄인다. 봇이 실제 브라우저와 JavaScript를 사용하더라도 장시간 일관된 인간 행동을 모방하기는 어렵다는 점이 핵심이다. ### 기존 봇 탐지의 가시성 한계 - Cloudflare는 하루 1조 건이 넘는 요청과 인터넷의 20% 이상에서 얻은 네트워크 신호를 활용한다. - Turnstile은 CAPTCHA 대체 수단에서 위험 기반 관리형 챌린지로 발전했으며, 하루 약 30억 회 실행된다. - 하지만 로그인, 가입, 결제처럼 중요한 순간에만 검증하면 애플리케이션 전체 여정에서 사용자가 어떻게 행동했는지는 충분히 파악하기 어렵다. - Precursor는 이 공백을 메우기 위해 세션 전체의 상호작용을 지속적으로 관찰한다. ### Precursor의 역할 - 동적으로 삽입되는 JavaScript가 방문자의 행동 신호를 수집한다. - 수집된 신호는 실시간으로 Cloudflare의 봇 방어 시스템에 반영된다. - Turnstile을 대체하는 기능이 아니라, Enterprise Bot Management에서 선택적으로 함께 사용하는 보완 기능이다. - 짧은 시간 동안 정상적으로 보이는 자동화도 세션 전체의 일관된 행동 패턴에서는 이상 징후를 드러낼 수 있다. - 공격자는 전체 세션을 인간처럼 시뮬레이션해야 하므로 자동화 개발·유지·대규모 운영 비용이 증가한다. - 정상 사용자는 공격적인 챌린지를 덜 받으면서도 보호 수준을 유지할 수 있다. ### 인간 행동과 봇 행동의 차이 - 인간의 마우스 움직임은 단순한 무작위 노이즈가 아니라 물리적·인지적 제약을 따른다. - 손목과 팔의 회전 범위 때문에 움직임이 일정한 곡선이나 호 형태를 보인다. - 화면의 요소를 인지한 뒤 클릭하기까지 인지 처리 시간이 발생한다. - 손 떨림으로 인해 미세한 생리학적 진동이 나타난다. - 봇은 다음과 같은 패턴을 보이기 쉽다. - 두 지점 사이를 직선으로 이동한다. - 수학적으로 이상적인 베지어 곡선을 따른다. - 지나치게 정확하게 클릭한다. - 동일한 속도와 리듬으로 반복한다. - 마우스를 항상 원점으로 되돌리는 등 기계적인 동작을 보인다. - 개별 동작 하나만 보면 정상처럼 보일 수 있지만, 세션 전체에서 이동 경로·속도·대기 시간·수정 동작의 반복을 관찰하면 인간과 자동화의 차이가 커진다. - 마우스 이동 외에도 키보드 활동, 포커스 변화, 페이지 가시성 등이 함께 분석된다. ### 데이터 수집 및 전송 - Precursor가 활성화되면 Cloudflare가 네트워크를 통과하는 HTML 응답에 경량 스크립트를 자동 삽입한다. - 별도의 네트워크 설정이나 외부 임베드가 필요 없다. - 스크립트는 응답마다 동적으로 조립되고 난독화되며, 기존 애플리케이션 로직에 영향을 주지 않도록 설계된다. - 다음과 같은 이벤트를 수집한다. - 포인터 이동 - 키보드 활동 - 입력 요소의 포커스 변화 - 페이지 가시성 변화 - 이벤트는 압축된 형식으로 직렬화되어 메모리에 임시 저장된다. - 일정 간격으로 버퍼의 데이터가 평가 계층으로 전송된다. ### 엣지 기반 행동 평가 - Cloudflare 엣지 서버는 수신한 Precursor 데이터를 역직렬화해 행동 입력으로 변환한다. - 여러 평가기(evaluator)가 각자 필요한 데이터 스트림을 분석하고 탐지 레지스트리에 신호를 추가한다. - 평가기는 단일 이벤트보다 서로 다른 신호 간의 상관관계를 확인한다. - 포인터 활동이 실제 페이지 가시 시간과 일치하는지 검사한다. - 키보드 입력이 텍스트 필드 포커스 상태에서 발생했는지 확인한다. - 개별 평가 결과는 통합된 탐지 신호로 변환되어 세션의 봇 점수와 판정에 반영된다. ### 세션 단위 분석 - Precursor 데이터는 요청 단위가 아니라 세션 범위에서 누적된다. - 페이지를 새로고침하거나 새로운 챌린지를 시작해도 기존 행동 서명을 쉽게 초기화할 수 없다. - 세션 메타데이터는 다음과 같은 후속 분석에도 사용된다. - 섀도 모드 휴리스틱 - 세션 분석 - 예측된 완료 상태와 실제 완료 상태의 비교 - 세션 비정상 종료(delinqency) 관련 휴리스틱 - 엣지에서 관찰된 정보는 탐지 개선과 세션 봇 점수 조정에 활용된다. - Cloudflare는 요청별 분석에서 방문자 전체 여정을 보는 방식으로 확장하기 위해 Security Analytics에 세션 기반 뷰를 도입한다. ### 개인정보 보호 설계 - 자동화와 악성 행위를 식별하는 데 필요한 최소한의 신호만 수집한다. - 키보드 활동은 실제 입력한 키가 아니라 입력 시점의 타이밍과 리듬으로 기록된다. - 개별 행동 자체보다 여러 행동의 집계된 패턴을 평가한다. - 수집된 행동 신호는 Cloudflare 내부 봇 탐지 시스템에서 사용된다. - 고객 대시보드에 노출되지 않으며, 사용자 계정·로그인 신원·영구 프로필과 연결되지 않는다. ### 실용적인 결론 Precursor는 CAPTCHA를 더 복잡하게 만드는 접근보다, 사용자 세션 전체에서 축적되는 행동 일관성을 탐지 신호로 활용하는 방식이다. 봇 방어가 필요한 서비스는 Turnstile로 중요한 순간을 보호하면서 Precursor로 전체 여정을 분석하면, 정상 사용자에 대한 마찰을 줄이고 장기적으로 정교한 자동화 공격의 비용과 불안정성을 높일 수 있다.

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

JavaScriptbot-managementbot-detectionbehavioral-analysis+3

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

퍼블릭 클라우드 리전을 위한 스마트 계층형 캐시 개선

Smart Tiered Cache는 원본(origin)으로 향하는 캐시 미스를 가장 가까운 단일 Cloudflare 상위 티어(upper tier)로 모아 캐시 적중률을 높이는 기능이다. 그러나 AWS·GCP·Azure·Oracle Cloud처럼 anycast 또는 regional unicast를 사용하는 퍼블릭 클라우드 원본은 IP만으로 실제 위치를 판단하기 어려워, 여러 상위 티어를 사용하는 보수적 방식으로 동작했다. 이번 개선에서는 사용자가 클라우드 리전을 지정하면 Cloudflare가 해당 리전에 맞는 주·보조 상위 티어를 선택해 불필요한 대륙 간 우회(hairpin)와 원본 요청을 줄인다. ## Smart Tiered Cache의 목적과 발전 - 모든 요금제에서 무료로 제공되는 Cloudflare의 대표적인 tiered cache 토폴로지다. - 원본 IP의 실시간 지연 시간을 측정해 가장 빠른 Cloudflare 데이터센터 하나를 상위 티어로 선택한다. - 캐시 미스를 한 곳에 집중해 다음 효과를 얻는다. - 캐시 적중률 향상 - 원본으로 연결되는 요청 및 연결 수 감소 - 원본 데이터를 가져오는 지연 시간 감소 - 기존 확장 사례: - **R2 지원(2024년 11월):** R2 버킷의 실제 위치에 가까운 상위 티어를 자동 선택 - **Load Balancing 지원(2025년 1월):** 풀 전체에 동일한 상위 티어를 사용해 공유 캐시와 적중률 개선 ## 퍼블릭 클라우드 anycast 원본의 문제 - 고정된 unicast IP는 특정 물리적 위치에 대응하므로 지연 시간 측정만으로 최적 상위 티어를 고르기 쉽다. - 반면 클라우드 로드 밸런서나 regional ingress의 IP는 여러 클라우드 엣지에서 동시에 응답할 수 있다. - 같은 IP라도 Cloudflare 데이터센터마다 서로 다른 클라우드 엣지로 연결되므로, IP가 실제 백엔드 위치를 나타내지 않는다. - 그 결과 한 곳을 최적 상위 티어로 잘못 선택할 수 있다. - 예를 들어 싱가포르 원본에 대해 시카고 데이터센터가 가장 낮은 측정 지연을 보이면: - 아시아 사용자의 요청이 가까운 Cloudflare PoP에 도착 - 시카고 상위 티어로 대륙을 건너 이동 - 시카고에서 다시 싱가포르 원본으로 이동 - 이런 hairpin 트래픽은 대륙 간 왕복을 추가해 수백 밀리초의 지연을 만들 수 있다. ## anycast 감지와 기존 대응 - Cloudflare는 여러 전 세계 체크포인트에서 원본까지의 probe 지연을 측정한다. - 두 체크포인트 간 물리적으로 빛이 이동할 수 있는 시간보다 전체 경로가 빠르게 나타나면, 하나의 위치가 아니라 여러 위치에서 응답한다고 판단한다. - 이는 해당 원본이 anycast일 가능성이 높다는 의미다. - anycast로 감지되면 Cloudflare는 단일 상위 티어에 고정하지 않고 여러 상위 티어를 사용하는 방식으로 전환한다. - 이 방식은 안정적이지만 트래픽이 여러 티어로 분산되어: - 캐시가 한 곳에 모이지 않음 - 원본으로 전달되는 요청 증가 - 단일 최적 상위 티어를 사용할 때보다 캐시 효율 저하 ## 리전 힌트를 이용한 개선 - 사용자가 원본이 위치한 클라우드 리전을 직접 지정한다. - 예시: - `aws:us-east-1` - `gcp:europe-west1` - Cloudflare는 리전 정보를 바탕으로 IP 자체의 모호한 지연 측정 대신 해당 리전에 적합한 상위 티어를 선택한다. - 각 리전에 대해: - **Primary upper tier:** 가장 강한 신호를 가진 최적 상위 티어 - **Fallback upper tier:** 주 상위 티어와 다른 PoP에 위치한 보조 상위 티어 - 주·보조 티어를 서로 다른 PoP로 구성해 한 PoP 장애가 두 경로를 동시에 제거하지 않도록 한다. - AWS, GCP, Azure, Oracle Cloud에서 출시되며 향후 지원 제공자가 추가될 예정이다. ## 설정 방법과 운영 방식 - Cloudflare 대시보드에서 다음 경로로 설정한다. - `Caching > Tiered Cache > Origin Configuration` - 원본 IP 옆의 **Set Region Hint** 선택 - 클라우드 리전 입력 - 대시보드에서는 Cloudflare가 anycast로 감지한 원본 IP에만 리전 힌트를 설정할 수 있다. - IP별 개별 설정뿐 아니라 여러 원본 IP에 대한 일괄 편집도 가능하다. - API와 Terraform도 지원하므로 Infrastructure as Code 환경에 통합할 수 있다. ## 리전 매핑과 상위 티어 선택 방식 - Cloudflare는 지원 클라우드 제공자의 최신 IP 범위 파일을 몇 시간마다 가져온다. - 이 파일을 통해 각 클라우드 리전과 현재 IP prefix를 매핑한다. - 클라우드 제공자가 서브넷을 추가·삭제·재할당해도 최신 정보를 반영한다. - Cloudflare의 상위 티어 데이터베이스는 15분마다 갱신되는 지속적인 지연 시간 측정 결과로 구성된다. - 리전에 속한 각 서브넷은 현재 상위 티어 할당 결과에 따라 가중 투표를 제공한다. - 가장 강한 신호를 얻은 상위 티어가 해당 리전의 primary가 된다. ## 실용적인 권장 사항 퍼블릭 클라우드의 anycast 원본에서 캐시 효율이 낮거나 대륙 간 hairpin 지연이 발생한다면, 원본 IP에 정확한 클라우드 리전 힌트를 설정하는 것이 좋다. 여러 원본을 운영한다면 API나 Terraform으로 리전 정보를 관리하고, primary와 fallback이 서로 다른 PoP로 구성되는지 확인하면 장애 대응과 성능을 함께 개선할 수 있다.

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

cloudflareTerraformtiered-cachinganycast+3

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

왜 우리는 더 나은 양자내성 서명 알고리즘을 기다릴 수 없는가

RSA와 ECC는 충분히 강력한 양자컴퓨터가 등장하면 깨질 수 있으므로, 양자내성을 갖춘 암호 알고리즘으로의 전환이 필요하다. ML-KEM은 이미 널리 사용되기 시작했지만, 인증을 보호하는 양자내성 서명은 아직 선택지가 제한적이며 당장은 ML-DSA를 사용해야 한다. 더 나은 알고리즘이 개발 중이지만 전환 시점에 맞춰 준비되기 어렵기 때문에, “원하는 알고리즘이 아니라 현재 가진 알고리즘으로 대응해야 한다”는 것이 글의 결론이다. ## 양자내성 암호 전환이 시급한 이유 - RSA와 ECC는 현재 인터넷 보안의 핵심이지만, 충분히 발전한 양자컴퓨터에서는 취약해진다. - 공격자가 지금 암호화된 데이터를 수집해 두었다가 미래에 복호화하는 **harvest-now-decrypt-later** 공격이 가능하다. - NIST는 8년에 걸친 국제 경쟁 끝에 2024년 다음 알고리즘을 표준화했다. - **ML-KEM**: 양자내성 키 캡슐화·암호화 알고리즘 - **ML-DSA**: 양자내성 디지털 서명 알고리즘 - Cloudflare는 이미 대부분의 트래픽에 ML-KEM을 적용하고 있으며, 2029년까지 전체 시스템을 양자내성 상태로 전환하는 것을 목표로 한다. - 암호화만으로는 충분하지 않다. 인증서와 인증 시스템의 서명까지 양자내성으로 바꿔야 무단 접근을 막을 수 있다. ## 당장은 ML-DSA를 사용해야 하는 이유 - ML-DSA는 현재 표준화된 양자내성 서명 중 가장 범용적인 선택지다. - 다만 기존 RSA·ECC에 비해 다음과 같은 단점이 있다. - 공개키와 서명 크기가 훨씬 크다. - 네트워크 전송량이 증가한다. - RSA와 ECC에서 활용하던 일부 최적화 기법을 적용하기 어렵다. - 더 나은 후보가 개발되고 있지만, 표준화와 구현·배포까지는 오랜 시간이 걸린다. - NIST는 새로운 서명 알고리즘 9개를 “signatures on-ramp” 3라운드로 진출시켰다. - 기존 경쟁에서 선정된 Falcon의 후속 표준인 **FN-DSA**도 표준 초안이 곧 나올 예정이다. - 그러나 이 알고리즘들은 현재 진행 중인 양자내성 전환에 맞춰 준비되기 어렵다. - 따라서 완벽한 알고리즘을 기다리기보다, 현재 사용 가능한 ML-DSA로 우선 전환해야 한다. ## 양자내성 서명 알고리즘의 평가 기준 - 글에서는 TLS에 적합한 128비트 보안 수준의 변형을 중심으로 후보들을 비교한다. - 주요 평가 지표는 다음과 같다. - 공개키 크기 - 서명 크기 - 서명 생성 시간 - 서명 검증 시간 - 후보 알고리즘은 보안 수준별로 여러 변형을 제공하며, 3라운드 과정에서 성능과 크기가 바뀔 수 있다. - 일부 알고리즘은 구현상의 위험도 존재한다. - **FN-DSA·SQIsign**: 빠르고 타이밍 부채널 공격에 안전한 구현이 어렵다. - **LMS**: 서명마다 상태를 보존해야 하며, 안전한 서명을 위해 상당한 캐시가 필요하다. - **SLH-DSA의 특정 변형**: 생성 가능한 서명 수가 제한적이다. ## ‘만능 알고리즘’이 없는 상황 - 양자 공격에 취약하다는 점을 제외하면 Ed25519는 여전히 거의 모든 지표에서 가장 뛰어난 서명 알고리즘이다. - 공개키와 서명이 작다. - 서명 생성이 빠르다. - 검증 속도도 대부분의 애플리케이션에 충분하다. - 반면 양자내성 알고리즘에는 Ed25519와 같은 만능 선택지가 없다. - 크게 두 종류로 나뉜다. - **전문가형(specialist)**: 특정 지표에서는 ECC에 근접하지만 다른 부분에 큰 단점이 있다. - **범용형(generalist)**: 모든 지표에서 균형 잡힌 대신, ECC만큼 뛰어난 항목은 적다. - ML-DSA는 대표적인 범용형 알고리즘으로, 크기·성능·구현 난이도에서 극단적인 약점은 없지만 전반적으로 부담이 크다. ## SQIsign: 작은 서명과 느린 서명 생성 - SQIsign은 전송 크기만 보면 ECC의 대체재에 가까운 특성을 보인다. - 서명 크기: 148바이트 - 공개키 크기: 65바이트 - RSA-2048보다도 작다. - 그러나 다음과 같은 약점이 있다. - 후보 중 가장 복잡한 알고리즘이다. - 서명 생성과 검증이 느리다. - 타이밍 부채널 공격에 안전한 서명 생성 구현이 어렵다. - 부채널 방어를 적용하면 성능 저하가 더 커진다. - 2024년과 비교하면 구현이 크게 개선되었다. - 당시에는 타이밍 부채널 안전 구현이 없었다. - 검증 속도도 현재보다 약 20배 느렸다. - 최근에는 알고리즘 단순화와 성능 개선이 진행됐다. - 그래도 안전한 서명 생성은 가까운 미래에 TLS 핸드셰이크처럼 온라인으로 반복되는 작업에 쓰기 어려울 가능성이 높다. - 대신 서명 생성보다 검증이 중요한 오프라인 용도에는 적합할 수 있다. - 인증기관(CA)의 서명 - DNSSEC - SQIsign은 아이소제니(isogeny) 수학에 기반한다. - 같은 계열의 SIKE는 NIST 경쟁 후반에 치명적으로 공격받았다. - 다만 SIKE는 이미 보안 우려가 있었고, 그 때문에 표준화에서 제외된 뒤 추가 검토 대상으로 남아 있었다. - SQIsign은 SIKE의 취약점과 관련된 torsion point를 사용하지 않으므로 동일한 문제가 직접 적용되지는 않는다. - 현재 SQIsign에 대해 알려진 최선의 공격은 잘 선택된 타원곡선처럼 일반적인 전수공격에 가깝다. - 그러나 아이소제니 수학은 매우 풍부하고 공격 표면도 넓어, 충분한 검토 없이 서둘러 표준화해서는 안 된다. ## 실용적인 결론 현재 시스템은 더 나은 서명 알고리즘이 나올 때까지 기다리기보다 ML-DSA를 중심으로 양자내성 전환을 시작해야 한다. 이후 FN-DSA, SQIsign 등 후속 알고리즘이 표준화되고 구현 안정성이 검증되면, TLS·CA·DNSSEC처럼 용도별 특성에 맞춰 ML-DSA와 함께 선택적으로 도입하는 전략이 현실적이다.

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

post-quantum-cryptographyquantum-computingelliptic-curve-cryptographyml-kem+4

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

Meerkat 소개 - 글로벌 합의에 대한 실험

Cloudflare는 330곳이 넘는 글로벌 데이터센터에서 동일한 컨트롤 플레인 상태를 강한 일관성으로 읽고 수정할 수 있는 합의 서비스를 개발하고 있다. 기존 Raft는 리더 장애와 타임아웃 때문에 광역 네트워크에서 쓰기 가용성이 중단될 수 있어, Cloudflare는 모든 복제본이 쓰기에 참여하고 타임아웃으로 진행이 멈추지 않는 QuePaxa 기반의 Meerkat을 만들었다. Meerkat은 아직 실험 단계이며, 우선 데이터베이스 리더십이나 리소스 배치처럼 작은 규모의 내부 컨트롤 플레인 상태를 관리하는 데 사용될 예정이다. ## 글로벌 컨트롤 플레인 데이터의 필요성 - Cloudflare의 여러 서비스는 전 세계 데이터센터에 분산된 머신에서 동일한 제어 상태를 읽고 수정해야 한다. - 대표적인 컨트롤 플레인 데이터는 다음과 같다. - AI 모델 인스턴스 등 리소스의 배치 정보 - 데이터베이스에서 쓰기를 수행할 수 있는 머신을 나타내는 리더십 정보 - 네트워크 단절, 데이터센터 장애, 서버 중단, 큐 포화, 케이블 절단 등 인터넷 환경의 불확실성에도 시스템이 동작해야 한다. - 따라서 다음 두 조건을 동시에 만족하는 데이터 시스템이 필요하다. - 여러 클라이언트가 서로 모순되지 않는 상태를 읽는 강한 일관성 - 일부 머신이나 네트워크 링크가 실패해도 읽기와 쓰기가 가능한 장애 내성 ## 선형화 가능성으로 대표되는 강한 일관성 - 일관성 모델은 동시 읽기와 쓰기에서 시스템이 허용하는 동작 범위를 정의한다. - 약한 일관성에서는 여러 노드에 도착한 쓰기 순서가 재배열될 수 있다. - 더 강한 모델에서는 쓰기 순서는 유지되더라도 읽기가 서로 다른 시점의 값을 볼 수 있다. - 가장 강한 모델인 **선형화 가능성(linearizability)** 은 실제 시간 순서에 맞춰 연산이 실행된 것처럼 보이게 한다. - 어떤 쓰기가 완료된 뒤의 읽기는 반드시 그 쓰기 결과를 볼 수 있다. - 프로그래머는 분산 저장소를 단일 스레드 머신의 메모리처럼 추론할 수 있다. - Meerkat 위에 구축되는 키-값 저장소는 선형화 가능성뿐 아니라 직렬성(serializability)도 제공할 예정이며, 직렬성에 대한 자세한 내용은 후속 글에서 다룬다. ## 요구되는 장애 내성 - 시스템은 전체 머신 수가 `2f + 1`일 때 최대 `f`개의 장애를 감당하는 것을 목표로 한다. - 다음 조건이 유지되면 어느 데이터센터의 클라이언트에서도 읽기와 쓰기가 가능해야 한다. - 전체 머신의 과반수가 살아 있고 서로 통신할 수 있다. - 클라이언트가 과반수의 활성 머신과 연결된 머신 하나에 접속할 수 있다. - 이 조건은 단일 머신 장애나 하나의 네트워크 링크 성능 저하만으로 전체 시스템의 가용성이 떨어지지 않아야 함을 의미한다. - 시스템은 다음과 같은 장애에서도 올바른 상태를 유지해야 한다. - 머신 충돌 및 재시작 - 네트워크 장애와 지연 - 데이터센터 장애 - 네트워크 품질 저하 - 한편 공격자가 악의적으로 잘못된 메시지를 보내는 **비잔틴 장애**는 Raft와 마찬가지로 처리 대상에서 제외한다. - 안전성의 핵심은 최신 상태를 가진 두 머신이 서로 다른 세계를 인식하지 않도록 하는 것이다. 예를 들어 한 머신이 `key1=1`, 다른 머신이 `key1=2`라고 판단하는 상황을 허용하지 않는다. ## Raft가 광역 네트워크에서 겪는 한계 - Raft는 한 번에 하나의 리더만 쓰기를 수행할 수 있도록 한다. - 리더가 충돌하거나 네트워크 지연으로 사실상 접근 불가능해지면 다음 과정이 필요하다. - 다른 복제본이 리더의 실패를 타임아웃으로 감지 - 새로운 리더 선출 - 새 리더가 활동을 시작할 때까지 쓰기 중단 - 인터넷 전반에 걸친 Cloudflare 네트워크에서는 지연 시간이 일정하지 않기 때문에 타임아웃 값을 적절히 설정하기 어렵다. - 타임아웃이 너무 짧으면 정상적인 지연을 장애로 오인하고, 너무 길면 실제 장애 이후 복구가 늦어진다. - Cloudflare는 리더를 사용할 수 없어 합의 기반 시스템이 중단된 여러 장애를 경험했으며, 이것이 새로운 합의 서비스 개발의 배경이 되었다. ## QuePaxa 기반 Meerkat - Meerkat은 EPFL 연구진이 2023년에 발표한 합의 알고리즘 **QuePaxa**를 기반으로 한다. - Raft와 달리 QuePaxa에서는 모든 복제본이 항상 쓰기를 수행할 수 있다. - 특정 리더가 장애를 일으켰을 때 새 리더 선출을 기다리느라 전체 진행이 멈추지 않는다. - 타임아웃 때문에 합의 진행이 중단되지 않는 특성은 지연이 불규칙한 광역 네트워크에 적합하다. - Meerkat은 합의 로그를 제공하고, 그 위에 다음과 같은 애플리케이션을 구축한다. - 트랜잭션 키-값 저장소 - 분산 임대(lease) 및 잠금 시스템 - 데이터베이스 리더십 관리 - Cloudflare는 이를 글로벌 규모에서 산업적으로 배포하는 최초의 QuePaxa 사례가 될 것으로 보고 있다. ## 현재 개발 단계와 적용 범위 - Meerkat은 아직 개발 중인 실험적인 서비스다. - 초기에는 대규모 사용자 데이터가 아니라 작은 컨트롤 플레인 상태를 관리하는 데 집중한다. - 즉시 외부 공개 서비스로 제공하지 않고 Cloudflare 내부 전용으로 운영할 계획이다. - 이번 글은 Meerkat의 배경과 요구사항을 소개하고, 이후 합의 로그와 그 위에 구축되는 저장소 및 리스 시스템에 관한 후속 글의 기반을 마련한다. Meerkat의 핵심 설계 방향은 리더 장애와 고정된 타임아웃에 의존하지 않는 합의를 통해, 글로벌 네트워크에서도 선형화 가능한 데이터와 높은 쓰기 가용성을 함께 확보하는 것이다. 다만 실제 운영에서는 과반수 연결 조건과 비잔틴 장애를 처리하지 않는다는 한계를 함께 고려해야 한다.

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

분산 시스템fault-tolerancekey-value-storequepaxa+4

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

Cloudflare, 영국 정부의 사이버 복원력 서약에 자랑스럽게 동참

Cloudflare는 영국 정부의 자발적 사이버 복원력 서약(Cyber Resilience Pledge) 창립 서명기관으로 참여하며, 보안의 대중화·경영진 책임·투명성이라는 원칙을 지지한다고 밝혔다. 이 서약은 기업이 이사회 차원에서 사이버 보안을 관리하고, 공급망 전체의 보안 수준을 높이며, 기본적인 기술 통제를 갖추도록 요구한다. Cloudflare는 보안이 특정 상품이나 대기업만의 영역이 아니라 모든 조직에 기본값으로 제공되어야 하며, 집단 방어를 통해 인터넷 전체의 복원력을 높여야 한다고 주장한다. ## 영국 사이버 복원력 서약의 배경 - 영국 정부가 조직의 기본적인 사이버 보안 거버넌스와 이사회 책임을 강화하기 위해 자발적 프레임워크를 출범시켰다. - 주요 원칙은 다음과 같다. - 보안 기술과 보호 기능의 대중화 - 경영진 및 이사회의 책임 강화 - 사고와 대응 과정에 대한 투명성 확대 - 공급망 전반의 보안 기준 향상 - Cloudflare는 이 서약을 새로운 의무라기보다, 지난 10여 년간 추진해 온 보안 철학을 영국 정부가 공식적으로 확인한 것으로 평가한다. - Cloudflare는 영국 과학·혁신·기술부(DSIT), 국가사이버보안센터(NCSC) 등과 협력해 영국의 디지털 경제 보안을 강화해 왔다. ## 증가하는 사이버 위협과 AI의 영향 - Cloudflare는 2026년 1분기에 전 세계 네트워크에서 하루 평균 2,340억 건의 사이버 위협을 차단했다. - 최근에는 최대 31.4Tbps 규모의 초대형 DDoS 공격을 완화했다. - 2025년 말 기준 영국은 전 세계에서 DDoS 공격 표적이 많은 국가 6위로 올라섰다. - 금융 서비스, 항공, 지방정부 인프라 등에서 애플리케이션 계층 공격이 증가하고 있다. - 영국 사이버 보안 침해 조사에 따르면 지난 1년간 사이버 사고를 경험한 비율은 기업 43%, 자선단체 28%였다. - 프런티어 AI 모델은 공격자의 진입 장벽을 낮추고 다음과 같은 공격을 자동화·고도화하고 있다. - 취약점 자동 탐색 - 대규모 공격 시도 - 더욱 설득력 있는 피싱 캠페인 - 이에 따라 방어 체계도 머신러닝 기반 공격 평가, Zero Trust 접근 제어 등으로 위협 변화에 맞춰 빠르게 발전해야 한다. ## 사이버 복원력은 비즈니스의 기본 요건 - 고객은 공격이나 장애 상황에서도 서비스가 지속적으로 제공되고, 빠르게 응답하며, 신뢰할 수 있기를 기대한다. - 사이버 복원력은 단순히 사고 발생 후 복구하는 능력이 아니다. - 복원력 있는 시스템은 다음을 수행해야 한다. - 위협 신호를 사전에 탐지 - 공격과 장애를 서비스 전체로 확산시키지 않고 흡수 - 운영 과정에서 얻은 교훈을 바탕으로 지속적으로 개선 - 따라서 보안 통제는 복원력을 실현하는 핵심 기반이며, 보안과 복원력은 분리할 수 없는 개념이다. ## 보안을 상품 등급이 아닌 기본값으로 제공 - Cloudflare는 기본적인 보안 기능을 모든 조직이 사용할 수 있어야 한다고 주장한다. - 모든 사용자에게 트래픽 암호화에 필요한 SSL 인증서를 제공했고, 무료 요금제에도 다음 기능을 포함한다. - 공격 규모와 관계없는 무제한 DDoS 보호 - 글로벌 CDN - DNSSEC - 네트워크 전반에 양자내성 암호화를 도입하는 등 인터넷 암호화 기술도 발전시키고 있다. - Project Galileo와 Athenian Project를 통해 취약한 목소리와 공공기관을 보호한다. - 중소기업, 지방정부, 공공서비스, 스타트업도 보안 수준을 높일 수 있어야 서약의 목표인 “사이버 복원력의 최저선”을 높일 수 있다는 취지다. ## 네트워크 전체를 위협 탐지 센서로 활용 - Cloudflare는 전 세계 13,000개 이상의 네트워크와 직접 피어링하며 공격 패턴을 대규모로 관찰한다. - 한 지역에서 발견한 위협 정보와 공격 패턴을 수초 내 네트워크 전체의 방어 규칙에 반영할 수 있다. - 예를 들어 싱가포르 고객을 공격한 위협을 분석해 얻은 규칙이 곧바로 영국 셰필드의 고객 보호에도 활용될 수 있다. - 대규모 가시성은 공격 탐지, 위험 점수 산정, 대응 속도를 개선하고 고객 전체의 복원력을 높인다. ## 스스로 먼저 검증하는 ‘고객 제로’ 원칙 - Cloudflare는 고객에게 제공하는 보안 제품과 인프라를 자체 시스템 보호에도 사용한다. - 내부 애플리케이션 접근에는 다음 통제를 적용한다. - Cloudflare Access와 Gateway - 하드웨어 키 기반 다중 인증 - 기기 보안 상태 점검 - 암호학적으로 검증된 신원 토큰 - 모든 보안 계층을 내부 환경에서 먼저 시험하고, 운영 경험을 제품과 네트워크 개선에 반영한다. - 보안을 특정 팀이나 제품의 책임이 아니라 조직 전반의 운영 방식으로 통합한다. ## 투명한 공개와 사고 이후의 개선 - 사고나 제로데이 취약점이 발생하면 기술적 사후 분석(postmortem)을 공개한다. - 침해 지표(IoC)와 아키텍처 회고를 공유해 다른 조직과 보안 커뮤니티가 동일한 위협에 대비할 수 있도록 한다. - 투명한 공개만으로 끝내지 않고, 사고를 시스템 개선의 계기로 활용한다. - 대규모 장애 이후 진행한 “Code Orange” 작업에서는 다음을 추진했다. - 장애가 전체 시스템으로 번지지 않도록 “작게 실패하는(fail small)” 구조 설계 - 안전한 구성 변경을 강제하는 도구 개발 - 보안 모범 사례의 자동화 - 목표는 같은 유형의 장애가 반복되지 않도록 구조적 원인을 제거하는 것이다. ## 서약이 강조하는 조직 차원의 책임 - 서약은 이사회 책임과 거버넌스, 공급망 보안, 영국 Cyber Essentials 인증과 관련된 기술 요건을 기업이 수용하도록 요구한다. - 대부분의 침해 사고는 패치되지 않은 시스템, 취약한 접근 제어, 부실한 공급업체 관리처럼 이미 알려진 문제에서 발생한다. - 따라서 고도화된 기술만큼 다음과 같은 기본 통제의 광범위한 적용이 중요하다. - 정기적인 패치와 취약점 관리 - 강력한 인증 및 접근 권한 통제 - 공급업체 보안 검토 - 지속적인 모니터링 - 이사회 차원의 위험 관리와 책임 부여 영국의 서약은 사이버 보안을 IT 부서의 단독 과제가 아니라 경영진과 공급망 전체가 함께 책임져야 할 사업 과제로 끌어올린다는 점에서 의미가 있다. 조직은 우선 패치, 인증, 접근 제어, 공급업체 관리 같은 기본 통제를 강화하고, 사고를 숨기기보다 투명하게 공유하며, 보안을 모든 서비스의 기본값으로 설계하는 것이 바람직하다.

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

cloudflare제로 트러스트post-quantum-cryptographycybersecurity+3

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

이제 Worker 앞에 자체 캐시를 둘 수 있습니다

Cloudflare의 **Workers Cache**는 Worker 앞에 계층형 캐시를 배치해, 캐시 적중 시 Worker를 실행하지 않고 응답을 반환하는 기능이다. Wrangler 설정 한 줄과 기존 HTTP `Cache-Control` 헤더만으로 사용할 수 있으며, 캐시 적중 시 CPU 비용과 렌더링 지연을 줄인다. 서버 렌더링 애플리케이션은 정적 사전 생성과 매 요청 렌더링 사이에서, 필요할 때만 렌더링하고 결과를 캐시하는 세 번째 선택지를 얻게 된다. ## 서버 렌더링 앱에 필요한 캐시 - 기존 Workers 구조에서는 Worker가 캐시와 원본 앞에 위치했다. - 요청 변환, URL 재작성, A/B 테스트, 트래픽 필터링 등에 적합했다. - 하지만 Worker 자체가 애플리케이션 서버이자 원본이 되면, 캐시할 대상이 없어 모든 요청이 코드를 실행한다. - Astro, TanStack Start, Next.js, Remix, SvelteKit 같은 프레임워크는 Cloudflare용 어댑터를 통해 앱을 Worker로 배포할 수 있다. - 동일한 응답을 반복 생성하더라도 매번 렌더링해야 하므로: - 페이지 로드마다 렌더링 지연이 발생한다. - Worker CPU 실행 비용이 계속 발생한다. - Workers Cache는 캐시를 Worker 앞에 배치한다. - 캐시 적중: Worker를 실행하지 않고 응답 반환, CPU 비용 0. - 캐시 실패: Worker가 실행되어 응답을 생성하고 캐시에 저장. - 이후 전 세계 어디서든 캐시된 응답을 받을 수 있다. ## 정적 생성과 매 요청 렌더링 사이의 선택지 - 빌드 시점 사전 생성(SSG)은 빠르지만 콘텐츠 변경마다 전체 빌드와 재배포가 필요하다. - 대규모 문서나 전자상거래 사이트에서는 빌드 시간이 길어질 수 있다. - 매 요청 서버 렌더링은 최신 데이터를 반영하지만, 모든 방문자가 렌더링 비용과 지연을 부담한다. - Workers Cache는 요청 시 생성한 결과를 TTL 동안 저장한다. - 새 페이지의 첫 요청만 렌더링한다. - 이후 요청은 정적 페이지처럼 캐시에서 제공한다. - TTL 만료 후 필요할 때 다시 렌더링한다. - 프레임워크별 ISR 구현 없이 표준 HTTP 캐싱 방식으로 동작한다. ## Wrangler 설정과 HTTP 헤더 기반 제어 - Wrangler 설정에서 캐시를 활성화한다. ```json { "name": "my-worker", "main": "src/index.ts", "compatibility_date": "2026-05-01", "cache": { "enabled": true } } ``` - 응답의 `Cache-Control` 헤더로 캐시 정책을 지정한다. ```ts return new Response(body, { headers: { "Cache-Control": "public, max-age=300, stale-while-revalidate=3600", "Cache-Tag": "products,product:123" } }); ``` - 별도의 Zone 설정, 규칙 엔진, 캐시 프로비저닝 없이 Worker 코드와 HTTP 헤더만으로 구성한다. - 커스텀 도메인, `workers.dev`, 서비스 바인딩, 프리뷰, Workers for Platforms 테넌트 등 Worker가 실행되는 여러 진입점에서 동일한 방식으로 사용할 수 있다. ## `stale-while-revalidate`로 만료 시에도 지연 방지 - `max-age=300`은 응답을 5분 동안 신선한 상태로 유지한다. - `stale-while-revalidate=3600`은 만료 후 최대 1시간 동안 오래된 응답을 즉시 제공하면서 백그라운드에서 새 응답을 생성하도록 한다. - 이 설정이 없으면 TTL 만료 직후 첫 요청이 Worker 렌더링을 기다려야 한다. - 설정이 있으면: - 사용자는 오래된 페이지를 즉시 받는다. - 응답에는 `Cf-Cache-Status: UPDATING`이 표시될 수 있다. - Worker는 백그라운드에서 캐시를 갱신한다. - 갱신을 유발한 요청자도 캐시 수준의 응답 속도를 얻는다. ## 캐시 무효화와 고급 기능 - 콘텐츠가 변경되면 Worker에서 직접 캐시를 제거할 수 있다. ```ts await ctx.cache.purge({ tags: ["product:123"] }); ``` - `Cache-Tag`를 사용하면 특정 상품이나 콘텐츠 그룹 단위로 캐시를 무효화할 수 있다. - 글에서 언급한 추가 기능은 다음과 같다. - 네트워크 전반의 계층형 캐싱 - `Vary`를 이용한 콘텐츠 협상 - `ctx.props` 기반의 멀티테넌트 안전 캐시 키 - 태그 또는 경로 접두사 기반 프로그래밍 방식 purge - 공개 엔드포인트뿐 아니라 모든 Worker 진입점 앞에 캐시 배치 - 진입점별 캐시 활성화 여부 제어 ## 적용 범위와 의의 - Workers Cache는 모든 요금제의 Worker에서 사용할 수 있으며 Wrangler로 활성화한다. - 캐시는 애플리케이션 구조에 맞춰 여러 진입점 사이에 배치할 수 있다. - 결과적으로 서버 렌더링 앱은 정적 사이트에 가까운 응답 속도와 동적 서버 렌더링의 최신성, 두 가지를 함께 얻을 수 있다. - 실무에서는 페이지 특성에 따라 `max-age`와 `stale-while-revalidate` 값을 정하고, 데이터 변경 시 `Cache-Tag` 기반 purge를 함께 사용하는 방식이 적합하다.

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

Cloudflare Workerswranglerhttp-cachingstale-while-revalidate+2

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

AI 검색을 더 스마트하게 만들기

AI 검색의 확산으로 사용자는 원문 링크를 방문하지 않고 요약된 답변만 소비하게 되었으며, 기존의 “콘텐츠 제공과 방문자·수익의 교환” 구조가 흔들리고 있다. Cloudflare는 단순한 AI 크롤러 차단을 넘어, 더 효율적인 검색 크롤링과 콘텐츠 사용량에 따른 창작자 보상 체계를 구축해야 한다고 주장한다. 이를 위해 콘텐츠 최신성 신호를 활용한 검색 개선과 ‘크롤링당 지불’에서 ‘사용당 지불’로의 전환을 추진한다. ### AI 검색이 만든 기존 수익 모델의 위기 - 전통적으로 검색엔진은 웹사이트를 크롤링하고 방문자를 보내는 방식으로 콘텐츠 제공자와 상호 이익을 만들었다. - AI 검색·답변 엔진은 웹페이지를 읽고 직접 요약하므로 사용자가 원문 사이트를 방문할 필요가 줄어든다. - 2025년 Pew Research Center 조사에 따르면: - Google에 AI 요약이 표시되면 일반 검색 결과 링크 클릭률은 8%에 그쳤다. - AI 요약 안의 링크 클릭률은 1%에 불과했다. - 콘텐츠 제공자는 AI 검색을 차단하면 발견 가능성이 낮아지고, 허용하면 콘텐츠는 활용되지만 방문자와 수익은 줄어드는 선택을 강요받고 있다. ### 차단을 넘어선 새로운 인터넷 거래 구조 - Cloudflare는 투명성, 통제권, 책임 있는 봇 운영을 기본 원칙으로 제시한다. - 새로운 봇 관리 옵션을 통해 사이트 운영자는 어떤 봇이 접근하고 무엇을 할 수 있는지 제어할 수 있다. - 그러나 차단만으로는 콘텐츠 제작자를 지속적으로 지원할 수 없으므로 다음 두 가지가 필요하다고 본다. - AI 검색이 더 신선하고 품질 높은 콘텐츠를 찾도록 개선 - 콘텐츠가 실제 답변 생성에 사용된 가치에 따라 창작자에게 보상 ### 콘텐츠 최신성 신호로 AI 검색 개선 - Cloudflare는 전 세계 네트워크에서 얻는 신호를 활용하는 연구 프로그램을 시작한다. - 활용하려는 정보에는 다음이 포함된다. - 페이지가 실제로 변경되었는지 여부 - 콘텐츠의 최신성 - 사용자와 봇이 어떤 콘텐츠에 많이 접근하는지 - 사이트 운영자가 공유에 동의한 콘텐츠 신호 - 답변 엔진은 이 정보를 이용해 더 관련성 높고 최신인 콘텐츠를 우선 노출할 수 있다. - 사이트 운영자는 자신의 콘텐츠가 어떤 질문과 AI 결과에 연결되는지 파악할 수 있다. ### 불필요한 크롤링 감소 - Cloudflare 데이터에 따르면 정상적인 봇 크롤링 트래픽의 20% 이상이 변경되지 않은 페이지를 다시 가져오는 데 사용된다. - “이 페이지는 변경되지 않았다”는 신호를 제공하면 크롤러가 불필요한 재방문을 생략할 수 있다. - 이에 따라: - AI 기업의 컴퓨팅 비용이 감소한다. - 사이트 운영자의 서버 부하와 요청 처리 비용이 줄어든다. - 크롤링 규모가 커질수록 누적되는 낭비를 줄일 수 있다. - 이 프로그램은 특정 검색엔진에 종속되지 않으며, 공정하게 참여하는 모든 답변 엔진을 대상으로 한다. - 검색 목적에만 한정되고 콘텐츠 자체를 공유하거나 기초 모델 학습에 사용하는 방식은 아니다. - Cloudflare는 연구 결과와 사이트 운영자에게 발생한 효과를 공개하고, 이후 네트워크 전반에 기능을 확대할 계획이다. ### ‘크롤링당 지불’에서 ‘사용당 지불’로 - Cloudflare의 기존 Pay Per Crawl은 AI 기업이 콘텐츠를 크롤링할 때 게시자에게 비용을 지불하도록 하는 모델이었다. - 하지만 크롤링 횟수만으로는 콘텐츠의 실제 가치를 정확히 측정하기 어렵다. - 한 번 크롤링된 페이지가 수천 개 답변에 인용될 수 있다. - 여러 번 크롤링되어도 실제 검색 결과에는 한 번도 사용되지 않을 수 있다. - 이에 따라 Cloudflare는 콘텐츠가 실제 답변이나 검색 결과에 사용된 횟수에 기반해 보상하는 Pay Per Use 모델을 실험한다. - Ceramic.ai와 You.com 등 AI 기업과 협력하고 있으며, 각 기업의 결제 모델을 Cloudflare 네트워크의 콘텐츠 제공자에게 확장할 수 있도록 지원한다. - Ceramic.ai의 ‘쿼리당 지불’ 모델에서는 게시자가 동의할 경우 자신의 콘텐츠가 검색 결과에 표시될 때마다 보상받는다. - 이 방식은 단순한 봇 접근량이 아니라 콘텐츠가 이용자에게 제공한 실제 가치에 보상이 연결된다는 점에 의미가 있다. ### 실용적인 시사점 콘텐츠 운영자는 AI 봇을 일괄 차단하기보다 봇별 접근 권한과 보상 조건을 구분하는 전략을 검토할 필요가 있다. Cloudflare가 추진하는 최신성 신호와 사용량 기반 보상 모델이 확산되면, 콘텐츠의 발견 가능성을 유지하면서도 AI 검색으로 발생하는 가치 일부를 수익으로 회수할 수 있을 것으로 보인다.

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

cloudflarebot-managementai-searchweb-crawling+2

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

수익화 게이트웨이 출시: x402를 통해 Cloudflare 뒤의 모든 리소스에 요금 부과

Cloudflare는 웹 페이지·데이터셋·API·MCP 도구 등 Cloudflare 뒤의 모든 리소스에 사용량 기반 요금을 부과할 수 있는 Monetization Gateway를 발표했다. 이 게이트웨이는 결제 규칙, 결제 검증, 접근 제어를 엣지에서 처리하며, 출시 시 x402와 스테이블코인을 사용한다. 이를 통해 에이전트가 계정이나 구독 없이 요청 단위로 소액 결제하고, 서비스 제공자는 별도의 결제·정산 시스템 없이 리소스를 수익화할 수 있다. ## 에이전트 중심으로 바뀌는 웹의 수익 모델 - 기존 웹은 콘텐츠를 인간의 관심과 교환하고, 광고·구독·전자상거래로 수익을 창출했다. - AI 에이전트는 광고를 보거나 장기 구독을 유지하기보다, 필요한 페이지·데이터·도구를 한 번 사용하고 이동한다. - AI 크롤러는 방문자를 보내는 횟수보다 훨씬 많은 요청을 발생시킬 수 있어, 기존 광고 모델과 맞지 않는다. - 에이전트 경제에서는 다음과 같은 사용량 기반 과금이 적합하다. - 검색 1회당 수 센트 - 업로드 기본 요금 0.001달러와 MB당 0.01달러 - 성공적으로 해결된 지원 요청 1건당 0.99달러 - 소프트웨어의 자연스러운 과금 단위는 사용자 좌석이나 월 구독이 아니라 요청, 토큰, 작업 결과가 된다. ## 기존 사용량 과금의 한계 - 클라우드와 API는 호출량·사용 시간 기준으로 판매되어 왔지만, 일반적으로 사전에 등록한 고객과 API 키가 필요했다. - 콘텐츠 서비스는 주로 광고에 의존했기 때문에, 신원 확인이 되지 않은 구매자의 초소액 결제를 처리하기 어려웠다. - 결제 수수료와 정산 지연 때문에 결제 금액이 너무 작으면 결제 자체가 더 비싸지는 문제가 있었다. - 사업자는 사용량을 정확하고 감사 가능하게 기록하기 위해 자체 회계·청구 시스템을 구축해야 했다. - 이러한 복잡성 때문에 많은 기업이 구현하기 쉬운 좌석 기반 가격제를 선택했다. ## 스테이블코인과 에이전트 결제 - 에이전트는 한 사람이 처리할 수 없는 수준으로 지속적으로 작업하며, 수천 건의 소액 결제를 자동으로 수행할 수 있다. - 사람이 각 결제를 승인해야 하는 기존 방식은 에이전트 사용 패턴과 맞지 않는다. - Open USD, USDC 같은 스테이블코인은 매우 작은 금액을 낮은 수수료로 전송하고, 1초 이내에 정산할 수 있다. - 따라서 에이전트 환경에서는 소액·고빈도 결제와 사용량 기반 가격제가 적합하다. ## x402의 HTTP 기반 결제 흐름 - x402는 HTTP 상태 코드 `402 Payment Required`를 활용하는 개방형 결제 프로토콜이다. - 기본 흐름은 다음과 같다. - 클라이언트가 결제 보호 리소스를 요청한다. - 서버가 `402` 응답과 함께 가격, 허용 자산, 결제 주소를 전달한다. - 클라이언트가 결제한 뒤 결제 증명을 포함해 요청을 재전송한다. - 퍼실리테이터가 결제를 검증하면 서버가 리소스를 반환한다. - 결제는 별도의 결제 페이지나 API 호출 없이 일반적인 HTTP 요청·응답 안에서 처리된다. - 구매자의 결제 금액은 판매자의 지갑으로 직접 정산되는 P2P 구조다. - 판매자 계정이 없어도 결제 자체가 접근 자격 증명이 되므로, 구매자 온보딩이 필요 없다. - 프로토콜 오버헤드가 작아 1센트 미만의 결제도 가능하며, 스테이블코인과 결합하면 낮은 수수료와 빠른 정산을 기대할 수 있다. ## Monetization Gateway의 역할 - Cloudflare는 결제 정책과 접근 제어를 하나의 컨트롤 플레인에서 관리하도록 지원한다. - 서비스 제공자는 어떤 요청에 결제를 요구할지 Cloudflare 규칙 표현식으로 정의할 수 있다. - 토큰, API, MCP 호출, 데이터 등 기존 Cloudflare 경로를 통과하는 트래픽에 대해 선택적으로 과금할 수 있다. - 결제 검증과 집행은 원본 서버가 아니라 Cloudflare 엣지에서 처리된다. - Cloudflare의 330개 이상 도시에 분산된 네트워크에서 x402 핸드셰이크가 수행되므로 구매자와 가까운 위치에서 처리할 수 있고, 원본 서버의 부하와 지연도 줄일 수 있다. - 계획된 기능에는 다음이 포함된다. - 특정 REST 경로와 HTTP 메서드별 과금 - 예를 들어 `/api/premium/*`의 GET·POST 요청마다 0.01달러 부과 - 작업의 특성에 따른 변동 가격 설정 ## 서비스 제공자에게 주는 이점 - 제공자가 직접 구매자를 등록하거나 API 키·청구 시스템을 운영할 필요가 없다. - 사용량 측정, 결제 교환, 정산이 원본 서버에서 분리된다. - 제공자는 가격, 결제 조건, 접근 규칙, 수익에 집중할 수 있다. - Cloudflare는 기존에 자체 청구 및 고객 분석을 위해 구축한 사용량 회계 역량을 웹 리소스에 적용하려 한다. 실용적으로는 API·데이터·MCP 도구처럼 요청 단위 가치가 분명한 리소스부터 x402 기반 과금을 적용하는 방식이 적합하다. 다만 실제 도입 시에는 스테이블코인 지원 범위, 환불·분쟁 처리, 가격 변동성, 규제 및 회계 처리를 별도로 검토해야 한다.

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

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

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

콘텐츠 독립기념일, 1년 후—에이전틱 인터넷의 비즈니스 모델 구축

AI 확산으로 인터넷의 기존 경제 모델인 “콘텐츠 제공 → 검색 노출 → 추천 트래픽”의 구조가 빠르게 붕괴하고 있다. 사람들은 검색 결과를 직접 방문하기보다 AI가 통합한 답변을 소비하고 있으며, 크롤러의 절반 이상이 AI 학습용으로 사용된다. 이에 Cloudflare는 콘텐츠 접근 통제·투명성·희소성을 통해 콘텐츠 라이선싱 시장을 만들고, 퍼블리셔가 AI 기업과 더 공정하게 거래할 수 있도록 하겠다고 주장한다. ## AI adoption과 오픈 웹의 급격한 변화 - 생성형 AI는 스마트폰보다 2배 이상 빠른 속도로 확산되고 있다. - 약 3.5년 만에 전 세계 25억 명, 즉 인류의 30% 이상이 정기적으로 생성형 AI를 사용하게 됐다. - 인터넷 사용 방식도 바뀌었다. - 온라인에서 정보를 검색하는 1시간 중 실제 오픈 웹에서 보내는 시간은 약 15분에 불과하다. - 여러 웹사이트를 방문해 정보를 비교하는 대신, 사용자는 AI에 질문하고 통합된 답변을 바로 받는다. - 이 변화는 검색 기반 유입에 의존하던 콘텐츠 사업자에게 직접적인 위협이 된다. ## 에이전틱 인터넷과 비인간 트래픽 - 2026년에는 인터넷 트래픽의 50% 이상이 처음으로 비인간 트래픽이 됐다. - AI 에이전트와 크롤러가 정보 검색, 상품 비교, 조사, 업무 수행을 직접 처리하면서 인간 방문자와 자동화된 접근의 경계가 흐려지고 있다. - 콘텐츠 소유자는 자신의 콘텐츠가 누구에게, 어떤 목적으로 사용되는지 파악하기 어려워지고 있다. ## 크롤러의 목적 변화 - 2026년 6월 기준 크롤러 요청의 52%가 AI 학습 목적이었다. - 2025년 봄의 22%에서 크게 증가한 수치다. - 검색·에이전트·학습을 혼합한 크롤러가 전체 활동의 36% 이상을 차지한다. - 순수 검색용 크롤링은 전체에서 작아지고 있지만, 퍼블리셔의 검색 노출에는 여전히 중요하다. - 혼합형 크롤러는 콘텐츠 소유자에게 딜레마를 만든다. - AI 시대에도 발견되려면 크롤링을 허용해야 한다. - 그러나 그 과정에서 핵심 콘텐츠가 보상 없이 AI 학습에 사용될 수 있다. - 따라서 검색을 위한 접근과 AI 학습을 위한 접근을 기술적으로 구분하는 것이 중요해졌다. ## 검색 유입 중심 모델의 붕괴 - 과거에는 콘텐츠를 검색엔진에 제공하면 검색 결과를 통해 방문자가 유입됐고, 그 트래픽이 광고·구독·판매 등의 경제적 가치를 만들었다. - 현재는 콘텐츠가 계속 크롤링되고 사용되지만, 원 출처로 돌아오는 트래픽은 줄어들고 있다. - AI가 원문을 방문하지 않고도 질문에 답하고 제품을 비교하며 업무를 수행하기 때문이다. - 이에 따라 콘텐츠 제작자는 “사람들이 원문을 방문하지 않아도 어떻게 지속 가능한 수익을 만들 것인가”라는 문제에 직면했다. - 일부 퍼블리셔는 검색 유입이 거의 사라지는 상황을 “Google Zero”라고 부르며 대비하고 있다. ## 산업 전반으로 확산되는 영향 - 초기에는 뉴스·미디어 기업이 가장 큰 영향을 받았지만, 현재는 다음 산업으로 확산되고 있다. - 소매 - 소프트웨어 - IT - 금융 - 일부 고크롤링 분야에서는 1년 이내 인간 트래픽이 최대 40% 감소했다. - 인터넷에 독점적이거나 전문적인 정보를 게시하는 모든 조직이 에이전틱 인터넷에 대응해야 한다. - 이 문제는 퍼블리셔만의 문제가 아니라, 인터넷을 기반으로 운영되는 전체 경제와 정보 생태계의 지속 가능성에 영향을 준다. ## 콘텐츠 시장을 만들기 위한 세 가지 요소 Cloudflare는 Content Independence Day 이후 다음 세 가지 방향을 추진했다고 설명한다. - **투명성과 통제** - 사이트 운영자가 자신의 콘텐츠가 어떻게 접근되고 수익화되는지 결정하도록 지원한다. - **희소성 창출** - 무제한 접근을 기본값으로 두지 않고, 콘텐츠 접근을 제한해 소유자의 협상력을 높인다. - **콘텐츠 마켓플레이스** - 콘텐츠 제작자와 AI 기업이 콘텐츠를 발견하고, 라이선스를 협의하며, 콘텐츠 가치를 정할 수 있는 시장을 구축한다. ## 통제와 투명성이 협상력을 만든 방식 - 기존에는 퍼블리셔가 AI 기업의 콘텐츠 접근·사용 방식을 충분히 알기 어려웠다. - Cloudflare의 귀속 분석, 비즈니스 인텔리전스, 집행 도구는 네트워크 수준에서 AI 콘텐츠 소비를 파악하고 통제하도록 했다. - 이는 자발적 규범인 `robots.txt`보다 강력한 집행 수단으로 제시된다. - 운영자는 다음과 같은 데이터를 확보할 수 있다. - LLM이 콘텐츠에 접근하려 한 빈도 - 어떤 경쟁 AI 모델이 크롤링했는지 - 가장 많이 요청된 URL - 크롤링 횟수와 실제 추천 트래픽의 비율 - 이런 데이터는 콘텐츠 접근을 제한해 희소성을 만들고, 라이선스 협상에서 정보 비대칭을 줄인다. - 결과적으로 퍼블리셔는 AI 기업이 콘텐츠를 얼마나 필요로 하는지 근거를 바탕으로 판단하고, 더 유리한 조건을 협상할 수 있게 된다. ## 실용적인 결론 콘텐츠 사업자는 검색 유입만을 성과 지표로 삼기보다 AI 크롤러의 접근 목적과 규모를 측정해야 한다. `robots.txt` 같은 선언적 방식에 더해 접근 제어, 사용량 분석, AI 학습과 검색 접근의 구분, 콘텐츠 라이선싱 정책을 마련하는 것이 필요하다. 앞으로는 콘텐츠를 공개할지 차단할지의 이분법보다, 어떤 용도로 누구에게 어떤 조건으로 제공할지를 관리하는 능력이 핵심 경쟁력이 될 것이다.

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

AI대규모 언어 모델생성형 AIcloudflare+3

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

내 사이트, 내 규칙: 모든 고객을 위한 새로운 AI 트래픽 옵션

AI 트래픽은 더 이상 “차단할 것인가, 허용할 것인가”의 단순한 문제가 아니며, 웹사이트 운영자는 봇의 목적에 따라 접근을 세분화해 관리해야 한다는 글입니다. Cloudflare는 AI 트래픽을 **검색(Search), 에이전트(Agent), 학습(Training)**으로 분류하고, 각 유형을 개별적으로 허용하거나 차단할 수 있는 기능을 모든 고객에게 제공합니다. 특히 광고가 표시되는 페이지에서는 2026년 9월 15일부터 학습·에이전트 봇은 기본 차단하고, 검색 봇은 기본 허용할 예정입니다. ## AI 봇을 일괄 차단하기 어려운 이유 - 기존에는 AI 기업이 콘텐츠를 학습에 사용하면서도 웹사이트에 방문자나 보상을 돌려주지 않는 문제가 컸습니다. - 이에 Cloudflare는 2025년부터 다음과 같은 대응책을 제공했습니다. - 한 번의 설정으로 AI 봇을 차단하는 **“Block AI Bots”** - 크롤링 건별로 콘텐츠 사용료를 받는 **Pay-Per-Crawl** 마켓플레이스 - 그러나 모든 자동화 트래픽을 차단하면 소규모 사이트는 검색 결과에서 발견될 기회까지 잃을 수 있습니다. - 검색 노출을 얻기 위해 AI 학습까지 허용해야 하는 상황은 대형 검색 사업자에게 유리한 구조를 만들고, 신규 사업자가 봇의 정체를 숨기도록 유도할 수 있습니다. ## AI 대신 봇의 행동을 기준으로 분류 - AI 기술의 범위는 빠르게 변하므로, 봇을 단순히 “AI 봇”인지 아닌지로 구분하는 방식은 오래 유지되기 어렵습니다. - 대신 다음 질문을 기준으로 봇을 평가합니다. - 사이트에서 무엇을 하는가? - 콘텐츠를 어디에 저장하는가? - 나중에 콘텐츠를 어떻게 재공유하는가? - 하나의 봇이 여러 목적을 수행한다면 대표 목적 하나만 기록하지 않고, **모든 목적을 함께 추적**하는 방향을 채택합니다. ## 검색·에이전트·학습의 3가지 분류 ### 검색(Search) - 사이트 콘텐츠를 수집하거나 색인해 나중에 질문에 답하는 데 사용하는 자동화입니다. - 검색 엔진이나 AI 답변 엔진이 사이트 데이터를 미리 데이터베이스화하는 행위가 해당됩니다. - 사이트 운영자는 검색 유입이나 그에 상응하는 보상을 기대할 수 있습니다. - Google 검색처럼 결과 페이지에서 직접 답변을 제공하는 서비스도 이 범주와 관련됩니다. ### 에이전트(Agent) - 사용자를 대신해 실시간으로 작업을 수행하는 자동화입니다. - 예시: - ChatGPT-User 같은 채팅 기반 가져오기 봇 - Gemini 또는 Claude가 브라우저를 조작하는 브라우저 에이전트 - 일반적으로 사람이 요청한 작업을 완료하기 위해 웹 애플리케이션을 방문합니다. - 콘텐츠를 장기적으로 학습하기보다는 특정 시점에 필요한 정보를 조회하거나 거래를 수행하는 것이 핵심입니다. ### 학습(Training) - 콘텐츠를 모델 학습이나 파인튜닝에 사용하기 위해 수집하는 크롤러입니다. - 사이트 데이터가 AI 모델의 내부 구조에 영구적으로 흡수되어 모델의 능력을 개선하는 것이 특징입니다. - 검색처럼 방문자를 되돌려 보내는 목적이 명확하지 않기 때문에, 사이트 운영자가 별도로 차단하거나 보상을 요구할 수 있어야 합니다. ## 목적별로 분리된 크롤러의 필요성 - 하나의 기업이 검색 색인 구축, 사용자 대신 작업 수행, 모델 학습을 모두 한다면 각 목적에 맞는 크롤러를 분리하는 것이 권장됩니다. - 크롤러를 분리하면 사이트 운영자가 다음을 더 명확히 파악할 수 있습니다. - 어떤 이유로 방문했는지 - 어떤 콘텐츠 접근 권한이 필요한지 - 검색은 허용하면서 학습은 차단할 수 있는지 - 일부 크롤러는 여러 목적을 동시에 수행할 수 있으며, Googlebot·Applebot·BingBot처럼 검색과 학습 목적이 결합된 봇이 그 예입니다. ## Cloudflare의 새로운 AI 트래픽 관리 옵션 - Cloudflare는 기존의 일괄적인 **“Block AI Bots”** 설정을 세분화합니다. - 모든 요금제, 무료 요금제를 포함한 고객이 다음 유형을 각각 관리할 수 있습니다. - Search 크롤러 - Agent 크롤러 - Training 크롤러 - 이를 통해 사이트 운영자는 다음과 같은 정책을 설정할 수 있습니다. - 검색 봇은 허용하고 학습 봇은 차단 - 에이전트 접근은 허용하되 특정 콘텐츠에서는 제한 - 모든 유형을 허용하거나 차단 - Cloudflare는 광고 검증, 피드 수집, 에이전트 기반 거래 등 다른 자동화 유형도 분류하고 있지만, 이번 변경의 중심은 세 가지 AI 사용 사례입니다. ## 2026년 9월 15일부터 적용되는 기본값 - 새로 Cloudflare에 등록되는 도메인의 광고 표시 페이지에는 다음 기본 정책이 적용됩니다. - **Training:** 기본 차단 - **Agent:** 기본 차단 - **Search:** 기본 허용 - 광고는 사람이 페이지를 방문해 콘텐츠를 보고 관심을 갖는 것을 전제로 하는 수익 신호입니다. - 따라서 광고 페이지에서는 사람의 관심을 방해하거나 콘텐츠를 재사용할 수 있는 학습·에이전트 봇을 차단하고, 방문자를 유도할 가능성이 높은 검색 봇은 허용한다는 논리입니다. - 여러 목적을 가진 크롤러는 모든 목적에 대한 규칙을 적용받으며, 가장 제한적인 규칙이 우선합니다. - 따라서 Training을 차단한 고객은 검색과 학습을 함께 수행하는 Googlebot, Applebot, BingBot도 차단될 수 있습니다. - 운영자는 9월 15일 이전에 Cloudflare 보안 설정에서 새 기본값을 적용하지 않도록 선택할 수 있습니다. 사이트 운영자는 모든 AI 자동화를 일괄 차단하기보다 검색·에이전트·학습 목적을 구분해 정책을 설정하는 것이 좋습니다. 특히 검색 유입이 중요한 사이트는 Search를 허용하되 Training과 Agent를 별도로 차단하고, Googlebot처럼 다목적 봇이 어떤 규칙을 적용받는지 사전에 점검해야 합니다.

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

AI 에이전트cloudflarebot-managementweb-crawlers+3

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

Attribution Business Insights로 크롤링의 실체 밝히기

웹사이트의 기존 검색엔진 생태계는 크롤링의 대가로 방문자를 보내는 구조였지만, AI 크롤러의 확산으로 이 균형이 무너지고 있다. AI 봇은 콘텐츠를 대량 수집하면서도 원 사이트로 유입되는 방문자는 거의 제공하지 않아, 게시자는 트래픽·수익·인프라 비용 측면에서 손해를 입을 수 있다. Cloudflare는 이를 판단할 수 있도록 봇별 활동과 크롤링 대비 추천 비율을 보여주는 **Attribution Business Insights** 대시보드를 공개했다. ## 검색엔진 시대에서 ‘제로 클릭’ 시대로 - 전통적인 검색엔진은 콘텐츠를 크롤링한 뒤 사용자에게 원문 페이지를 추천했다. - 게시자는 검색 유입을 통해 광고, 제휴, 구독 수익과 독자 관계를 확보할 수 있었다. - 검색엔진의 크롤링 횟수와 추천 방문자 수 사이에는 비교적 균형 잡힌 관계가 있었다. - 그러나 AI 챗봇은 원문을 수집해 답변을 직접 생성하면서 사용자를 원 사이트로 보내지 않는 ‘제로 클릭’ 환경을 만들고 있다. - 이에 따라 인터넷의 최적화 전략도 SEO에서 AEO(Answer Engine Optimization), GEO(Generative Engine Optimization) 중심으로 변화하고 있다. ## AI 크롤러의 불균형한 트래픽 - Cloudflare가 관찰한 주요 AI 크롤러의 크롤링 대비 추천 방문 비율은 약 **118:1에서 거의 50,000:1**까지 나타났다. - 일부 AI 크롤러는 방문자 한 명을 보내기 위해 콘텐츠를 수십만 번에 가깝게 요청할 수 있다. - 게시자는 두 가지 손실을 동시에 부담한다. - 광고 노출, 직접 방문, 독자 관계 등 수익으로 이어지는 트래픽 감소 - 상업적 가치가 불분명한 봇 요청을 처리하는 서버·대역폭 비용 증가 - 따라서 모든 크롤러를 허용해 노출을 기대하는 기존 전략은 더 이상 합리적이지 않을 수 있다. ## Attribution Business Insights 대시보드 - Cloudflare Bot Management 고객에게 제공되는 대시보드다. - 복잡한 로그 분석이나 수동 필터링 없이 사이트의 봇 트래픽을 사업 관점에서 파악하도록 설계됐다. - 주요 제공 정보는 다음과 같다. - 콘텐츠 페이지에 접근한 인간 사용자와 봇의 전체 트래픽 비교 - 사이트 전체 및 봇 운영자별 크롤링 대비 추천 방문 비율 - 24시간, 7일, 30일 단위의 비율 변화 - 트래픽 규모가 큰 봇 목록 - 봇의 국가, 사용 대역폭, 현재 허용·차단 상태 - 이를 통해 어떤 봇이 콘텐츠를 많이 사용하고 실제 방문자를 유도하는지 확인할 수 있다. ## 행동 기반 AI 크롤러 분류 Cloudflare는 AI 봇을 단순히 ‘AI 크롤러’로 묶지 않고 목적에 따라 분류한다. - **Training** - 차세대 대규모 언어 모델을 학습하기 위해 콘텐츠를 수집하는 크롤러 - **Search** - RAG(검색 증강 생성)에 사용할 데이터베이스를 갱신하는 크롤러 - **Agent** - 최종 사용자의 요청에 답하기 위해 에이전트형 상호작용에서 콘텐츠를 조회하는 크롤러 - 이러한 분류를 통해 게시자는 단순한 요청량뿐 아니라 콘텐츠가 어떤 용도로 사용되는지도 판단할 수 있다. ## 데이터에서 콘텐츠 비즈니스 전략으로 - 사이트 운영자는 보안 전문가가 아니더라도 대시보드의 요약 지표만으로 현재 콘텐츠 보안 정책의 효과를 점검할 수 있다. - 더 자세한 분석이 필요한 경우 봇 운영자별로 다음 정보를 비교할 수 있다. - 봇 유형 - 크롤링 대비 추천 비율 - 전체 요청량 - 현재 허용 또는 차단 정책 - 이 데이터는 AI 기업과의 협상이나 콘텐츠 라이선스 재검토에도 활용할 수 있다. - 예를 들어 특정 회사의 크롤링량이 다른 회사보다 20배 많거나, 이미 콘텐츠 사용료를 지급하는 회사가 있다면 이를 근거로 접근 정책과 계약 조건을 조정할 수 있다. - 핵심은 AI 트래픽을 일괄적으로 허용하거나 차단하는 것이 아니라, 실제 사업 가치와 비용을 기준으로 운영하는 것이다. ## 실용적인 적용 방향 게시자는 봇별 크롤링량, 추천 방문자, 대역폭 비용을 함께 비교해 허용·제한·차단 정책을 세워야 한다. 특히 Training, Search, Agent 목적을 구분하고, 유입 가치가 낮은 대량 크롤러에는 속도 제한이나 차단을 적용하며, 수익 또는 라이선스와 연결되는 봇에는 차별화된 접근 정책을 검토하는 것이 바람직하다.

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

대규모 언어 모델RAGai-crawlersweb-crawling+4

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

Cloudflare Workflows를 위한 사가 롤백 구축 방법

Cloudflare Workflows에 Saga 패턴 기반의 롤백 기능이 추가되어, 각 `step.do()`에 보상 작업을 함께 선언할 수 있게 되었습니다. 여러 외부 시스템을 거치는 워크플로에서 중간 단계가 실패해도 이전 작업을 역순으로 되돌릴 수 있으며, 롤백 자체도 내구성 있는 단계로 실행됩니다. 이를 통해 개발자가 별도의 `try-catch`, 실행 이력 추적, 수동 롤백 순서 관리를 구현할 필요가 줄어듭니다. ## 분산 작업에서 롤백이 필요한 이유 - Workflow는 여러 단계에 걸쳐 외부 시스템을 호출하고, 각 단계의 상태를 저장하며 실패 시 재시도합니다. - 그러나 이미 완료된 외부 작업은 단순히 “취소”할 수 없습니다. - 예: Bank A에서 출금이 성공한 뒤 Bank B 입금이 실패하면, Bank A의 출금을 삭제하는 대신 다시 입금해야 합니다. - 원래 작업과 이를 의미적으로 되돌리는 보상 작업의 조합을 Saga 패턴이라고 합니다. - 기존에는 개발자가 성공한 단계를 추적하고, 실패 시 어떤 작업을 어떤 순서로 취소할지 직접 관리해야 했습니다. ## `step.do()`에 보상 로직 선언 - 이제 `step.do()`의 마지막 인자로 `rollback` 함수를 전달할 수 있습니다. ```ts await step.do( "debit-bank-a", () => bankA.debit(from, amount), { rollback: async ({ output }) => bankA.credit(from, amount, output.id), } ); ``` - 각 정방향 작업과 롤백 작업이 같은 위치에 정의됩니다. - 새로운 단계를 추가할 때 해당 단계의 보상 로직도 함께 추가할 수 있습니다. - 별도의 대형 `catch` 블록이나 성공 단계 추적 변수, 수동 실행 순서 관리가 필요하지 않습니다. - 롤백 함수는 정방향 작업의 결과인 `output`을 받아 보상 작업에 활용할 수 있습니다. ## 롤백 실행 순서와 실패한 단계 처리 - 어떤 단계에서 오류가 발생하면, 롤백 핸들러는 단계가 시작된 순서의 역순으로 실행됩니다. - 출금 → 입금 → 알림 순서라면, 롤백은 입금 취소 → 출금 환불 순서입니다. - 오류가 발생한 단계 자체도 롤백 대상이 될 수 있습니다. - 외부 시스템에는 작업이 반영됐지만, 결과를 Workflow에 반환하기 전에 단계가 실패할 수 있기 때문입니다. - 예를 들어 결제 제공자가 금액을 승인한 뒤 `chargeId`를 반환하기 전에 오류가 발생할 수 있습니다. - 따라서 롤백 함수는 `output === undefined`인 경우도 안전하게 처리해야 합니다. - 사용자가 오류를 잡고 Workflow를 정상적으로 계속 진행하면 롤백은 시작되지 않습니다. - 다만 오류를 잡은 뒤 Workflow가 나중에 다른 이유로 실패하면, 그때까지 등록된 롤백 핸들러가 역순으로 실행될 수 있습니다. ## 롤백도 내구성 있는 작업으로 실행 - 롤백은 단순한 메모리상의 정리 코드가 아니라 Workflow의 내구성 모델에 따라 실행됩니다. - 재시작이나 일시적인 장애가 발생해도 롤백 작업을 추적하고 재시도할 수 있습니다. - 롤백 과정에서 하나의 보상 작업이 실패하더라도 이후 롤백을 계속 진행할 수 있도록 설계해야 합니다. - 롤백 실패는 운영자가 대응할 수 있도록 알림이나 별도 모니터링을 연결하는 것이 필요합니다. ## 멱등성 보장의 중요성 - 일반 Workflow 단계와 마찬가지로 롤백 함수도 멱등적이어야 합니다. - 같은 롤백이 여러 번 실행되어도 결과가 중복 적용되면 안 됩니다. - 권장 방식: - 결제 환불에는 결제 제공자의 멱등성 키 사용 - 재고 해제는 여러 번 호출해도 한 번만 해제되도록 구현 - 출금·입금과 롤백 각각에 고유한 멱등성 키 부여 - 예시에서는 다음과 같이 작업별 키를 사용합니다. ```ts `${transferId}:debit-account-a` `${transferId}:rollback-debit-account-a` ``` - 이를 통해 Workflow 재시도나 롤백 재실행으로 인해 동일한 이체가 중복 처리되는 것을 방지합니다. ## 실용적인 적용 권장사항 - 외부 시스템을 변경하는 모든 단계에 가능한 한 명시적인 롤백 함수를 함께 정의하세요. - 롤백 함수는 `output`이 없거나 일부 작업만 반영된 상황도 처리해야 합니다. - 정방향 작업과 롤백 모두에 안정적인 멱등성 키를 사용하세요. - 롤백 실패는 조용히 무시하지 말고 알림, 재처리 큐, 운영 대시보드 등으로 추적하세요. - Saga 롤백은 트랜잭션을 원자적으로 만드는 기능이 아니라, 실패 후 상태를 보정하는 보상 처리机制이므로 외부 API의 보상 연산을 신중히 설계해야 합니다.

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

cloudflare-workflowsrollbackidempotencysaga-pattern+2

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

모두를 위한 OAuth로 Cloudflare 앱 생태계의 잠금 해제

Cloudflare는 API 토큰 중심의 제한적인 연동 방식을 넘어, 모든 고객이 직접 OAuth 클라이언트를 관리할 수 있는 self-managed OAuth를 도입했다. 이를 통해 SaaS, 내부 개발자 플랫폼, 에이전트 도구가 사용자로부터 필요한 권한만 위임받고, 사용자는 동의·철회·권한 범위를 더 명확하게 관리할 수 있게 됐다. 이 확장을 위해 동의 화면과 철회 기능을 개선하고, OAuth 엔진인 Hydra를 무중단에 가깝게 1.X와 2.X로 단계적으로 업그레이드했다. ## 모든 고객을 위한 self-managed OAuth - 기존 Cloudflare OAuth는 Wrangler나 PlanetScale 같은 일부 파트너 통합에만 제공됐다. - 자체 통합을 개발하는 일반 개발자는 API 토큰을 사용해야 했지만, API 토큰은 다음과 같은 한계가 있었다. - 관리가 어렵다. - 사용자가 애플리케이션에 권한을 위임하는 흐름에 적합하지 않다. - 권한 범위와 철회 상태를 사용자 관점에서 명확히 관리하기 어렵다. - self-managed OAuth를 사용하면 개발자가 직접 OAuth 클라이언트를 만들고 관리할 수 있다. - 애플리케이션은 사용자가 승인한 범위 내에서만 Cloudflare API에 접근하며, 사용자는 권한을 쉽게 철회할 수 있다. - 주요 활용 사례는 SaaS 통합, 내부 개발자 플랫폼, 에이전트 기반 도구다. ## 대규모 OAuth 생태계를 위한 보안 개선 - 기존 OAuth 시스템은 소수의 파트너를 수동 관리하는 데는 충분했지만, 모든 고객에게 개방하기에는 권한 모델과 보안 장치가 부족했다. - 동의 화면을 개선해 다음 정보를 명확히 표시했다. - 어떤 애플리케이션이 접근을 요청하는지 - 애플리케이션에 부여될 권한이 무엇인지 - Cloudflare 대시보드에 애플리케이션 권한 철회 기능을 추가했다. - 앱 소유자 정보를 더 잘 표시해 OAuth 피싱 공격을 예방했다. - 동시에 OAuth 엔진의 성능과 데이터 안정성을 개선하면서, 사용자 중단을 최소화하는 업그레이드 계획이 필요했다. ## Hydra 1.X 업그레이드와 데이터베이스 마이그레이션 - Cloudflare는 기존 OAuth 엔진으로 오픈소스 Hydra를 사용하고 있었다. - 개발자 플랫폼과 에이전트 워크플로가 성장하면서 성능과 기능 확장을 위해 Hydra 업그레이드가 필요해졌다. - 한 번에 대규모 업그레이드를 진행하지 않고 다음 두 단계로 나눴다. 1. 최신 1.X 버전으로 업그레이드 2. 동작과 성능을 검증한 뒤 2.X로 업그레이드 - 1.X 업그레이드에도 다음과 같은 위험이 있었다. - 인덱스 생성이 주요 테이블에 배타적 잠금을 걸어 OAuth 작업을 차단할 수 있었다. - 주요 테이블에 컬럼을 추가하거나 다른 테이블로 컬럼을 이동해야 했다. - 기존 Hydra SDK의 `SELECT *` 사용 때문에 스키마 변경 후 역직렬화 문제가 발생할 수 있었다. - 이를 해결하기 위해: - 인덱스 생성 SQL을 `CREATE INDEX CONCURRENTLY` 기반으로 다시 작성했다. - 필요한 컬럼만 명시적으로 조회하는 Hydra 커스텀 버전을 제작했다. - 실제 1.X 마이그레이션은 예상보다 빠르게 완료됐고 사용자 영향도 없었다. - 다만 구버전 Hydra가 신버전에서 생성된 토큰을 조회하지 못했기 때문에 점진적 전환이 아닌 하드 컷오버가 필요했다. ## 2.X 업그레이드를 위한 블루-그린 전략 - Hydra 2.X는 스키마 변경 규모가 커서 기존 데이터베이스에서 바로 업그레이드하는 인플레이스 방식은 적합하지 않았다. - Cloudflare는 새 환경을 준비한 뒤 전환하는 블루-그린 방식을 선택했다. - 단순히 데이터베이스 연결만 바꾸는 방식으로는 부족했다. 마이그레이션에 수 시간이 걸리는 동안에도 OAuth가 계속 작동해야 했기 때문이다. - 검토한 첫 번째 방식은 업그레이드 중 데이터베이스 쓰기를 중단하는 것이었다. - 신규 OAuth 승인을 막아 데이터 유실을 방지할 수 있다. - 하지만 기존 앱도 새 인증을 사용할 수 없게 된다. - 사용자가 애플리케이션 권한을 철회할 수도 없어 보안상 문제가 된다. - 따라서 쓰기를 계속 허용하되, 전환 과정에서 일부 쓰기가 유실될 수 있는 방식을 채택했다. ## 토큰 만료 조정과 철회 이벤트 보존 - 전환 중 발생하는 신규 토큰 쓰기를 줄이기 위해 토큰 만료 시간을 몇 시간으로 늘렸다. - 업그레이드 직전에 발급된 토큰이 갱신 없이 계속 사용되도록 해, 전환 기간의 토큰 갱신 요청을 줄였다. - 반면 권한 철회 이벤트는 절대 유실되면 안 됐다. - 철회 이벤트가 사라지면 사용자가 접근을 차단한 애플리케이션의 권한이 다시 살아날 수 있다. - Cloudflare는 Cloudflare Queues를 이용해 철회 이벤트를 별도 큐에 기록했다. - 녹색 환경으로 전환한 뒤 큐를 비우면서 철회 이벤트를 재생해, 업그레이드 중 발생한 모든 철회를 반영했다. ## 리프레시 토큰 문제와 완화 - Hydra 1.X 업그레이드 후 리프레시 토큰 오류가 증가했다. - 새 버전에서는 리프레시 토큰이 재사용되면 전체 액세스 토큰·리프레시 토큰 체인을 무효화하는 동작이 더 엄격해졌다. - 요청량이 많은 Wrangler와 MCP 클라이언트에서는 재시도 한 번만 발생해도 전체 세션이 무효화될 수 있었다. - Cloudflare는 OAuth 트래픽을 라우팅하는 Worker에 리프레시 토큰 요청 병합(coalescing)을 추가했다. - 동일 요청의 짧은 재시도를 잠시 캐시했다. - 재시도를 감지하면 Hydra에 다시 전달하지 않고 기존 요청 결과를 반환했다. - Hydra 2.X에서는 리프레시 토큰을 일정 시간 동안 재사용해도 전체 체인을 무효화하지 않는 `refresh token grace period` 설정을 제공해 이 문제를 근본적으로 완화할 수 있었다. ## 실용적인 결론 대규모 OAuth 시스템을 개방하려면 클라이언트 등록 기능만 추가해서는 부족하다. 명확한 동의 화면, 즉각적인 권한 철회, 앱 소유자 표시 같은 보안 기능과 함께, 스키마 마이그레이션 중에도 철회 이벤트를 보존하는 큐, 토큰 만료 조정, 토큰 갱신 재시도 제어 같은 운영 설계가 함께 필요하다.

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

Cloudflare Workersoauthwranglerdatabase-migrations+3