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월 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월 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월 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 기반 과금을 적용하는 방식이 적합하다. 다만 실제 도입 시에는 스테이블코인 지원 범위, 환불·분쟁 처리, 가격 변동성, 규제 및 회계 처리를 별도로 검토해야 한다.

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

cloudflareAI 에이전트모델 컨텍스트 프로토콜API+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 학습과 검색 접근의 구분, 콘텐츠 라이선싱 정책을 마련하는 것이 필요하다. 앞으로는 콘텐츠를 공개할지 차단할지의 이분법보다, 어떤 용도로 누구에게 어떤 조건으로 제공할지를 관리하는 능력이 핵심 경쟁력이 될 것이다.

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

cloudflareAI대규모 언어 모델생성형 AI+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처럼 다목적 봇이 어떤 규칙을 적용받는지 사전에 점검해야 합니다.

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

cloudflareAI 에이전트bot-managementweb-crawlers+3

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

Cloudflare DMARC 관리 기능이 이제 정식 출시되었습니다

Cloudflare DMARC Management가 무료 서비스에서 정식 출시(GA)로 전환되며, 도메인의 이메일 인증 상태를 한곳에서 확인하고 DMARC 적용 단계를 안전하게 높일 수 있도록 개편되었습니다. SPF·DKIM·DMARC·BIMI 상태와 발신 소스를 분석해 인증 실패나 위조 발신을 파악하고, `p=none`에서 `p=quarantine`, `p=reject`로 전환할 때 발생할 수 있는 문제를 줄이는 것이 핵심입니다. 이를 통해 전문 컨설턴트나 XML 보고서 수작업 분석 없이도 도메인 보호와 이메일 전달률 개선을 지원합니다. ## 이메일 인증의 역할 - **SPF**는 도메인을 대신해 이메일을 보낼 수 있는 IP 주소와 서비스를 지정합니다. - **DKIM**은 이메일에 암호화 서명을 추가해 전송 중 메시지가 변조되지 않았는지 검증합니다. - **DMARC**는 SPF와 DKIM을 연결하고, 인증 실패 메일을 허용·격리·거부할지 정책으로 지정합니다. - DMARC 보고서를 통해 어떤 발신자가 도메인을 사용하고 있는지도 확인할 수 있습니다. - **BIMI**는 지원되는 받은편지함에 브랜드 로고를 표시하며, 이를 사용하려면 강력한 DMARC 정책이 필요합니다. - 네 가지 설정이 올바르면 도메인 사칭 메일을 차단하고 정상 메일의 전달 가능성을 높일 수 있습니다. ## DMARC가 필수가 된 배경 - Google, Microsoft, Yahoo 등 주요 메일 제공업체가 최근 이메일 인증 요구사항을 강화했습니다. - DMARC·SPF·DKIM이 없거나 잘못 설정된 도메인은 정상적인 메일도 스팸 처리되거나 거부될 수 있습니다. - 이메일 인증 문제는 브랜드 사칭뿐 아니라 고객 커뮤니케이션 실패와 매출 손실로 이어질 수 있습니다. - 과거의 권장사항이었던 DMARC가 이제는 도메인에서 이메일을 보내기 위한 사실상 필수 조건이 되었습니다. ## DMARC 적용 단계의 불확실성 - `p=none`은 모니터링만 수행하고 인증 실패 메일을 차단하지 않습니다. - `p=quarantine`은 의심스러운 메일을 스팸함으로 보냅니다. - `p=reject`는 인증되지 않은 메일을 완전히 차단합니다. - 너무 빨리 정책을 강화하면 외부 이메일 서비스나 누락된 발신 시스템의 정상 메일이 중단될 수 있습니다. - 반대로 전환을 지나치게 늦추면 도메인 사칭과 이메일 전달률 저하 위험이 계속됩니다. - 기존에는 XML 집계 보고서를 분석하고 모든 정상 발신 소스를 직접 식별해야 했지만, Cloudflare는 이를 셀프서비스 방식으로 단순화하는 것을 목표로 합니다. ## 발신 소스 조사 기능 - DMARC 보고서에서 발신 서비스와 함께 **소스 IP 주소**를 확인할 수 있습니다. - 각 발신 소스가 DMARC, SPF, DKIM 정렬(alignment)을 통과했는지 또는 실패했는지 한눈에 볼 수 있습니다. - IP 주소를 Cloudflare의 **Investigate** 탭에서 직접 조회할 수 있습니다. - Investigate 탭에서는 다음 정보를 제공합니다. - IP 평판 - 지리적 위치 - ASN(자율 시스템 번호) - 악성 활동과의 알려진 연관성 - 이에 따라 보고서가 단순한 통계 자료가 아니라 정상 인프라와 무단 발신자를 구분하는 조사 도구로 활용됩니다. ## 이메일 인증 레코드 통합 점검 - DMARC, DKIM, SPF, BIMI 레코드 상태를 하나의 화면에서 확인할 수 있습니다. - 각 레코드는 자동 분석을 통해 **통과·경고·실패** 상태로 표시됩니다. - 레코드별 상세 결과와 수정 권장사항을 확인할 수 있습니다. - 점검 항목에는 다음이 포함됩니다. - **SPF**: 중복 레코드, DNS 조회 제한 초과, 허용 범위가 지나치게 넓은 `+all`, 누락된 메커니즘 - **DKIM**: 키 형식 오류 또는 잘못 구성된 키 - **BIMI**: 강력한 DMARC 정책을 갖췄지만 BIMI 레코드가 없는 경우 - 안내 문구는 RFC 전문 용어보다 이해하기 쉬운 평이한 표현으로 제공되어, 다음 조치를 쉽게 판단할 수 있도록 설계되었습니다. ## 실용적인 활용 방향 먼저 Cloudflare DMARC Management에서 SPF·DKIM·DMARC·BIMI 상태와 발신 IP를 점검하고, 실패한 소스가 실제 사용 중인 외부 서비스인지 확인하는 것이 좋습니다. 정상 발신 흐름을 모두 파악한 뒤 `p=none`에서 단계적으로 정책을 강화하면, 정상 메일 중단 위험을 줄이면서 최종적으로 `p=reject` 수준의 도메인 보호에 도달할 수 있습니다.

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

cloudflarednsthreat-intelligencedmarc+4

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

Cloudflare로 퍼블릭 트래픽을 프라이빗 애플리케이션으로 라우팅하기

Cloudflare는 이제 퍼블릭 IP를 노출하지 않고도 인터넷 트래픽을 사설 애플리케이션으로 전달하는 **Application Services for Private Origins**를 제공한다. 이를 통해 사설 네트워크의 내부 API, AI 에이전트 백엔드, MCP 서버, 운영 도구에도 WAF, 봇 관리, 레이트 리미팅, 캐싱, Workers 같은 Cloudflare 기능을 적용할 수 있다. 핵심은 기존 Cloudflare Tunnel, WAN, Mesh 등의 사설 연결 경로를 애플리케이션 프록시 계층과 통합해, 마지막 구간만 사설 네트워크로 전송하는 것이다. ### 퍼블릭 애플리케이션과 프라이빗 애플리케이션의 경계 - 기존에는 퍼블릭 애플리케이션이 CDN·WAF 뒤에, 프라이빗 애플리케이션이 VPN·방화벽·별도 네트워크 스택 뒤에 위치했다. - 내부 API, AI 백엔드, MCP 서버처럼 인터넷에 직접 공개할 필요는 없지만 보안·성능 제어가 필요한 서비스가 늘고 있다. - 기존 방식은 퍼블릭 IP, 방화벽 예외, 커넥터 소프트웨어, 복잡한 네트워크 구성을 요구했다. - 그 결과 프라이빗 애플리케이션은 WAF, 봇 관리, 속도 제한, 캐시, 트래픽 가속, URL 변환, Workers 등의 기능을 활용하기 어려웠다. ### Application Services for Private Origins - 적격 Enterprise 고객을 대상으로 클로즈드 베타로 제공된다. - 사설 오리진을 인터넷에 노출하지 않고도 Cloudflare를 통해 퍼블릭 트래픽을 전달한다. - 다음 기능을 프라이빗 오리진 앞에서 사용할 수 있다. - WAF - 봇 관리 - 레이트 리미팅 - 캐싱 - URL·요청 변환 - Workers - 오리진에 퍼블릭 IP, 인바운드 방화벽 규칙, `cloudflared` 실행을 반드시 요구하지 않는다. ### 하나로 통합되는 사설 네트워크 연결 - 기존 Cloudflare Tunnel, Cloudflare One Client, Cloudflare WAN, Cloudflare Mesh 등의 연결 모델을 활용한다. - Cloudflare의 사설 네트워크 라우팅 계층이 다음 경로를 통합적으로 관리한다. - Cloudflare Tunnel - IPsec·GRE 터널 - CNI 연결 - Cloudflare Mesh - 기타 사설 연결 방식 - 고객은 제품별로 별도 네트워크 스택을 운영하는 대신 API나 대시보드에서 라우팅을 정의할 수 있다. - Workers VPC 바인딩과 Spectrum의 프라이빗 오리진 라우팅도 같은 사설 연결 계층을 사용하게 된다. ### 네 가지 트래픽 조합 Cloudflare는 사용자 위치와 애플리케이션 위치에 따라 트래픽을 네 가지 조합으로 구분한다. - 인터넷 사용자 → 인터넷 애플리케이션: 기존 Cloudflare 프록시 모델 - 프라이빗 네트워크 사용자 → 인터넷 서비스: Cloudflare One 모델 - 인터넷 사용자 → 프라이빗 애플리케이션: 이번에 제공하는 기능 - 프라이빗 네트워크 사용자 → 프라이빗 애플리케이션: 향후 구축 대상 ### DNS 레코드로 활성화하는 프라이빗 라우팅 - 프록시된 A 또는 AAAA 레코드에서 `Use private network routing` 옵션을 활성화한다. - Cloudflare의 WAF, 캐싱, 봇 관리, 레이트 리미팅, Transform Rules는 기존처럼 Cloudflare 네트워크에서 실행된다. - 차이는 오리진으로 향하는 최종 연결만 퍼블릭 인터넷이 아닌 사설 네트워크를 이용한다는 점이다. - 다음 주소 범위는 사설 주소이므로 옵션이 자동 활성화된다. - RFC 1918: `10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16` - RFC 6598 CGNAT: `100.64.0.0/10` - RFC 4193 IPv6 ULA: `FC00::/7` - 퍼블릭 IP라도 사설 터널을 통해서만 접근할 수 있다면 옵션을 수동으로 활성화할 수 있다. ### API 설정 방식 프라이빗 라우팅은 일반 DNS 레코드에 `use_private_routing` 속성을 추가하는 방식이다. ```json { "type": "A", "name": "app.example.com", "content": "10.0.0.50", "ttl": 300, "proxied": true, "use_private_routing": true } ``` - Cloudflare 프록시는 Origin API에서 오리진 주소와 라우팅 메타데이터를 조회한다. - `use_private_routing: true`가 있으면 프라이빗 IP로 인터넷 연결을 시도하지 않는다. - 대신 IPsec, GRE, Tunnel, CNI, Mesh 등 고객의 기존 연결을 통해 사설 네트워크 라우팅 계층으로 요청을 전달한다. ### HTTP 이외의 서비스 지원 - 이 모델은 웹 애플리케이션뿐 아니라 다양한 프로토콜과 서비스에도 적용된다. - Spectrum을 이용하면 TCP·UDP 기반 서비스도 프라이빗 오리진 뒤에 둘 수 있다. - 데이터베이스 - UDP 로그 수집 엔드포인트 - 기타 비HTTP 서비스 - Workers가 프라이빗 API나 데이터베이스를 직접 호출하는 구성에도 사용할 수 있다. - 공통적으로 Cloudflare가 사용자 트래픽과 사설 네트워크 사이에 위치해 보안, 성능, 라우팅을 통합 제공한다. ### 실용적인 결론 퍼블릭 트래픽을 받아야 하지만 오리진을 인터넷에 공개하고 싶지 않은 조직이라면, 기존 Cloudflare WAN·Tunnel·Mesh 연결을 유지한 채 DNS 레코드의 `use_private_routing`을 활성화하는 방식이 가장 단순하다. 이를 통해 별도의 퍼블릭 로드 밸런서, 역방향 프록시, 다중 TLS 종료 계층을 줄이고 사설 애플리케이션에도 Cloudflare의 보안·성능 기능을 일관되게 적용할 수 있다.

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

cloudflareCloudflare Workers제로 트러스트web-application-firewall+3

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

최첨단 사이버 모델에 대비하기: ‘고객 제로’로서의 Cloudflare 아키텍처

프런티어 사이버 모델은 취약점 탐색, 공격 경로 구성, PoC 생성 속도를 크게 높여 공격자의 시간과 규모 우위를 강화한다. 따라서 보안의 핵심은 패치를 얼마나 빨리 배포하느냐뿐 아니라, 취약점이 악용된 뒤 공격자가 이동할 수 있는 범위를 제한하는 아키텍처를 구축하는 데 있다. Cloudflare는 자사 인프라를 ‘고객 제로(customer zero)’로 삼아 가시성, 탐지, 방어 체계를 실제 환경에서 운영한다고 설명한다. ## 프런티어 사이버 모델이 바꾸는 공격의 속도 - 침입의 단계 자체는 여전히 정찰, 초기 접근, 측면 이동, 지속성 확보, 데이터 유출로 구성된다. - 달라지는 점은 각 단계로 진입하기 위한 탐색과 실행 속도, 그리고 시도 규모다. - 모델은 대규모 공개 코드와 오픈소스 라이브러리를 빠르게 분석하고, 취약점의 악용 가능성을 추론하며, 작동하는 공격 증명을 생성할 수 있다. - 과거에는 취약점 발견, 공격 경로 구성, PoC 작성이 공격의 병목이었지만, 프런티어 모델은 이를 짧은 시간 안에 수행한다. - 방어자는 모든 취약점을 찾아 안전하게 수정하고 회귀 테스트까지 해야 하지만, 공격자는 단 하나의 진입점만 찾으면 되므로 비대칭성이 커진다. - AI가 작성한 패치도 원래 버그는 해결하면서 주변 코드의 의존성을 깨뜨릴 수 있어, 자동 수정만으로는 충분하지 않다. ## 오픈소스 취약점과 방어자보다 빠른 발견 - 널리 사용되는 라이브러리와 프레임워크는 공격자가 한 번 분석해 여러 조직에 적용할 수 있는 공통 공격 표면이다. - 라이브러리에 버그가 있다고 해서 항상 악용 가능한 것은 아니다. - 애플리케이션에서 해당 코드가 실제로 사용되는지 - 공격자 입력이 취약한 경로까지 도달하는지 - 주변 보호 장치가 존재하는지에 따라 exploitability가 달라진다. - 가장 큰 위험은 공격자가 취약점을 발견한 시점과 방어자가 그 존재를 파악하는 시점 사이의 격차다. - 조직이 자체 코드에 프런티어 모델을 적용해 점검하지 않는다면, 다른 누군가가 먼저 같은 작업을 하고 있다고 가정해야 한다. ## 공격 대량화와 탐지 우회 - 모델은 하나의 공격을 수천 가지 변형으로 만들고, 대규모 정찰을 자동으로 수행할 수 있다. - 단순한 공격 변형은 동일한 기반 시그니처를 공유하므로 시그니처 기반 탐지 규칙에 함께 걸릴 수 있다. - 더 중요한 위협은 모델의 적응 능력이다. - 예를 들어 SQL 인젝션 공격이 WAF에 차단되면, 모델은 차단되는 입력과 통과하는 입력을 반복적으로 확인하고 페이로드를 수정할 수 있다. - 따라서 알려진 공격 패턴 차단만으로는 부족하며, 공격자의 반복적인 탐색·수정 행위와 비정상적인 요청 흐름도 관찰해야 한다. ## 취약점보다 중요한 침해 이후의 아키텍처 - 모든 공격을 사전에 차단할 수 있는 아키텍처는 없다. - 핵심 질문은 하나의 계정, 경로, 자격 증명이 탈취됐을 때 공격자가 추가 방어에 막히기 전까지 어디까지 접근할 수 있느냐이다. - 탈취된 하나의 신원으로 시스템 전체에 접근할 수 있다면, 근본적인 문제는 개별 취약점이 아니라 취약점 주변의 설계다. - 피해 범위를 줄이려면 권한 분리, 접근 범위 제한, 네트워크·애플리케이션 계층 간 추가 검증 같은 방어 심층화가 필요하다. - 즉, 패치 속도보다 침해가 발생해도 공격자가 확산하지 못하도록 만드는 구조가 장기적인 방어력을 결정한다. ## Cloudflare가 강조하는 가시성 - Cloudflare는 전 세계 웹 트래픽의 약 5분의 1을 관찰하며, 실시간 트래픽에서 다음 변화를 파악한다고 설명한다. - 공격 페이로드의 변형 - 새롭게 증가하는 공격 패턴 - 공격 도구의 이동 방향 - Cloudforce One은 이러한 네트워크 관찰 정보를 위협 인텔리전스, 연구, 작전 역량으로 전환한다. - 이 팀은 추적 중인 공격자, 신흥 캠페인, 침해 지표(IOC)를 식별해 다른 방어 계층이 활용할 수 있도록 한다. - 보안의 어려움은 악성 행위를 판별하는 것뿐 아니라, 새로운 위협 정보가 보고서에서 피드와 실제 차단 정책으로 전달되기까지 발생하는 완화 지연을 줄이는 데 있다. ## 실용적인 결론 프런티어 모델 시대에는 취약점 관리만으로 충분하지 않다. 자체 코드와 의존성을 AI로 지속 점검하고, WAF 같은 시그니처 기반 방어에 더해 공격자의 적응 행동을 탐지하며, 하나의 자격 증명이 침해돼도 전체 환경으로 확산되지 않도록 접근 권한과 이동 경로를 제한해야 한다.

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

cloudflarevulnerability-managementai-securityweb-application-firewall+2

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

Discord 음성을 엣지로 이전한 방법

Discord는 음성·영상 트래픽을 기존 약 30개 클라우드 리전에서 Cloudflare의 300개 이상 엣지 PoP로 이전해 사용자와 가까운 서버를 제공하려 했다. 그 결과 전체 트래픽의 80% 이상이 Cloudflare에서 처리되고, 프랑크푸르트에서는 평균 핑이 34%, 패킷 손실이 42% 감소했다. 그러나 단순히 가까운 PoP를 추가하는 것만으로는 충분하지 않았으며, 통화 호스트 배치와 ISP 간 네트워크 경로·피어링 상태가 품질을 좌우했다. ## 클라우드 리전에서 엣지 네트워크로 - 기존 인프라는 주요 클라우드 사업자의 데이터센터가 있는 약 30개 도시 중심으로 구성됐다. - Reykjavik, Auckland, Lagos 등 일부 지역은 가까운 음성 서버가 없어 수백 km 떨어진 리전으로 트래픽이 우회했다. - Cloudflare는 300개 이상의 도시에서 소규모 PoP를 운영하므로 사용자와 더 가까운 위치에 Discord의 음성·영상 서버를 배치할 수 있었다. - CDN은 주로 정적 콘텐츠 캐싱에 사용되지만, Discord는 Cloudflare 네트워크에서 실시간 UDP 패킷을 처리하는 방식을 적용했다. - 이전보다 지리적 커버리지는 크게 넓어졌지만, 각 PoP에 Discord 소프트웨어를 배포하고 운영해야 하는 부담은 남았다. ## 아이슬란드: 가까운 서버가 항상 최선은 아니다 - 2025년 2월, Reykjavik PoP에 음성 서버를 배치해 첫 실험을 진행했다. - 아이슬란드 사용자끼리 통화할 때는: - 핑 9% 감소 - 패킷 손실 11% 감소 - 그러나 아이슬란드와 독일처럼 여러 지역의 사용자가 섞인 통화에서는: - 비아이슬란드 사용자 핑이 2.7배 증가 - 패킷 손실 9% 증가 - Discord는 하나의 SFU가 통화 전체를 호스팅하고, 모든 참가자가 통화가 끝날 때까지 해당 SFU에 연결되는 구조다. - 따라서 독일 사용자 3명과 아이슬란드 사용자 1명의 통화가 Reykjavik에 배정되면, 독일 사용자들의 패킷이 아이슬란드까지 갔다가 돌아와야 했다. - 이 경험을 통해 새로운 PoP를 추가하는 것보다, 통화가 실제로 지역적으로 유지되도록 호스트 배치 로직을 개선하는 것이 중요하다는 점을 확인했다. ## 로테르담: ISP 피어링이 병목이 되다 - 2025년 4월, 기존 로테르담 트래픽을 Cloudflare의 암스테르담 PoP로 이전했다. - 대부분의 ISP에서는 문제가 없었지만, 프랑스 ISP Orange 사용자에게 심각한 품질 저하가 발생했다. - 피크 시간대 Orange 사용자의 통화 지연은 1초를 넘었고, 음성 프리즈 비율은 30% 악화됐다. - 원인은 Cloudflare 자체가 아니라 Orange와 암스테르담 사이의 네트워크 경로였다. - Orange와 Cloudflare의 연결은 Telia의 중계망을 거쳤으며, 피크 시간대 Telia와 Orange 간 인계 구간이 이미 포화 상태였다. - Cloudflare로 트래픽을 더 많이 옮길수록 해당 구간의 혼잡이 심해지는 구조였다. ## 롤백과 피어링 중심의 배포 전략 - Discord는 약 10일 후 암스테르담 이전을 되돌리고, 기존 공급자의 용량으로 Orange 트래픽을 처리했다. - 이후 Cloudflare는 Orange와 직접 피어링을 협상했다. - Orange 트래픽에 더 짧은 경로를 제공하기 위해 파리와 런던 PoP에 SFU를 배치했다. - 이 사건 이후 지역 이전 여부를 단순한 서버 용량이 아니라 ISP별 피어링 여유 공간을 기준으로 판단했다. - 주요 ISP와 Cloudflare 사이의 경로가 포화되어 있으면 해당 지역의 마이그레이션을 보류하는 방식으로 배포 절차를 변경했다. ## 마이그레이션에서 얻은 교훈 - 가까운 PoP는 일반적으로 지연 시간을 줄이지만, 통화 참가자가 여러 지역에 분산되어 있으면 전체 품질을 악화시킬 수 있다. - 최적의 서버 위치는 사용자와의 물리적 거리만으로 결정되지 않는다. - SFU 호스트 배치, 참가자 분포, ISP 간 라우팅, 트랜짓 사업자의 용량을 함께 고려해야 한다. - 초기에는 대규모 지역을 빠르게 이전하려 했지만, 아이슬란드와 로테르담 사례 이후 지역별·단계별 rollout으로 전환했다. - 결과적으로 배포 속도는 느려졌지만, 피어링 분석과 점진적인 트래픽 전환을 통해 장애 위험을 줄일 수 있었다. 실무적으로는 엣지 서버를 늘리는 것보다 먼저 통화·세션의 호스트 배치 정책과 ISP별 네트워크 경로를 분석해야 한다. 특히 글로벌 실시간 서비스는 서버 위치, 사용자 분포, 피어링 용량을 함께 검증한 뒤 소규모 트래픽으로 단계적으로 이전하는 전략이 안전하다.

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

cloudflareedge-computingwebrtccdn+3

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

VoidZero가 Cloudflare에 합류합니다

VoidZero가 Cloudflare에 합류하지만 Vite, Vitest, Rolldown, Oxc, Vite+는 계속 MIT 라이선스의 오픈소스이자 벤더 중립적·커뮤니티 주도 프로젝트로 유지됩니다. Cloudflare는 프로젝트의 방향을 통제하기보다 개발 인력과 자원을 추가하고, Vite 생태계 기금에 100만 달러를 투자해 기반 도구와 기여자들을 지원할 계획입니다. 이번 합류는 Vite를 Cloudflare 전용 도구가 아니라 JavaScript 생태계 전체를 위한 공통 기반으로 더욱 확장하려는 움직임입니다. ## VoidZero의 Cloudflare 합류 - Vite, Vitest, Rolldown, Oxc, Vite+를 만든 VoidZero의 전 구성원이 Cloudflare에 합류합니다. - 해당 프로젝트들은 계속해서: - MIT 라이선스를 유지합니다. - 특정 클라우드나 호스팅 업체에 종속되지 않습니다. - 어디서나 실행할 수 있습니다. - 로드맵과 개발 과정을 공개적으로 운영합니다. - Evan You를 비롯한 기존 VoidZero 팀이 프로젝트 리드를 계속 맡습니다. - Cloudflare는 프로젝트를 자사 제품으로 전환하는 대신 엔지니어링 인력과 개발 자원을 투입합니다. ## Vite 생태계에 대한 투자 - Vite는 Vue, SvelteKit, Nuxt, Astro, Solid, Qwik, Angular, React Router, TanStack Start 등 다양한 프레임워크의 기반으로 자리 잡았습니다. - Next.js 역시 `vinext`를 통해 Vite 기반 구현을 제공하기 시작했습니다. - 따라서 Vite는 단일 프레임워크가 아니라 JavaScript 생태계 전반의 공유 기반으로 평가됩니다. - Cloudflare는 Vite의 핵심 채택 요인인 개방성, 이식성, 벤더 중립성에 대한 신뢰를 유지하는 것을 최우선 목표로 제시했습니다. - Vite 코어 팀이 관리하는 생태계 기금에 100만 달러를 출연해 유지보수자와 기여자를 지원합니다. - 앞서 Cloudflare에 합류한 Astro 역시 오픈소스와 멀티 플랫폼 배포를 유지하고 있다는 점을 선례로 들었습니다. ## Vite Environment API와 Cloudflare 연동 - Vite와 Cloudflare는 2024년부터 Vite Environment API를 함께 개발해 왔습니다. - Environment API를 사용하면 개발 중 서버 코드를 Node.js가 아닌 다른 런타임에서 실행할 수 있습니다. - Cloudflare Vite 플러그인을 사용하면 `vite dev` 실행 시 서버 코드가 프로덕션 Workers와 동일한 오픈소스 런타임인 `workerd` 안에서 동작합니다. - 로컬 개발 환경에서 다음 Cloudflare 기능을 프로덕션과 유사한 런타임 모델로 사용할 수 있습니다. - Durable Objects - D1, KV, R2 - Workflows - Workers AI - Agents - Service Bindings - Workers RPC - 특정 업체 전용 개발 서버를 강제하지 않고, Vite에 범용 확장 지점을 제공한 뒤 각 런타임이 구현하도록 설계한 점이 핵심입니다. - 이 구조를 통해 비-Node.js 런타임에서도 로컬 개발 경험이 프로덕션보다 크게 뒤처지는 문제를 줄일 수 있습니다. ## 급증하는 Vite와 Cloudflare 플러그인 사용량 - 글 작성 시점 기준 Vite는 주간 약 1억 2,900만 회 다운로드를 기록했습니다. - `@cloudflare/vite-plugin`도 주간 약 1,400만 회 다운로드에 도달했습니다. - 이는 Cloudflare 플러그인이 Vite 전체 다운로드의 10% 이상에 해당하는 규모입니다. - AI로 생성되는 소프트웨어가 급증하면서 애플리케이션을 빠르게 만들고 실행할 수 있는 기본 스택에 대한 수요도 커졌습니다. - AI가 작성한 애플리케이션이 Vite를 선택하고, 그중 일부가 Cloudflare에서 실행되면서 플러그인 사용량이 증가한 것으로 설명합니다. ## AI 에이전트 중심의 개발 루프 - 개발 서버, 번들러, 린터, 포매터, CLI는 더 이상 사람만 사용하는 도구가 아닙니다. - AI 에이전트도 다음 작업을 반복적으로 수행합니다. - 프로젝트 스캐폴딩 - 개발 서버 실행 - 오류 분석 - 테스트 작성 및 실행 - 린트와 포맷 적용 - 프리뷰 배포 - 결과 확인 후 재수정 - 에이전트 개발에서는 다음 특성이 특히 중요합니다. - 반복 횟수가 많으므로 빠른 빌드 - 지속적인 검증을 위한 빠른 테스트 - 코드 품질을 보장하는 빠른 린팅·포매팅 - 에이전트가 해석하고 조치하기 쉬운 구조화된 오류 - 불필요한 우회를 줄이는 일관된 CLI - Vitest, Rolldown, Oxc, Oxlint, Oxfmt는 각각 빠른 도구로 설계되었으며, 반복 실행이 많은 에이전트 작업에 적합합니다. - Vite+는 이 도구들을 하나의 CLI와 설정 모델로 통합해 사람과 에이전트 모두가 더 예측 가능하게 사용할 수 있도록 합니다. ## Cloudflare 내부에서의 실제 적용 - Cloudflare 대시보드는 Vite를 기반으로 구축되고 있습니다. - Cloudflare 코드베이스에서는 Oxlint가 엔지니어링 시간을 절약하는 데 사용되고 있습니다. - Astro 팀의 에이전트 하네스 프레임워크인 Flue도 Vite를 기반으로 전환 중입니다. - Flue는 Node.js, Cloudflare Workers, GitHub Actions, GitLab CI/CD 등 여러 환경에서 에이전트를 실행할 수 있습니다. - Cloudflare 대상 환경에서는 공식 Cloudflare Vite 플러그인과 `workerd` 통합을 사용합니다. - 결과적으로 Vite는 외부 생태계뿐 아니라 Cloudflare 내부 애플리케이션 개발의 기본 기반으로도 자리 잡고 있습니다. ## 실용적인 결론 이번 변화는 Vite 사용자가 Cloudflare를 선택해야 한다는 의미가 아니라, Vite를 계속 어느 환경에서나 사용할 수 있도록 지원이 강화된다는 의미에 가깝습니다. 기존 Vite 프로젝트는 플랫폼 종속성 없이 유지할 수 있고, Cloudflare Workers 기능이 필요하다면 공식 Vite 플러그인과 `workerd` 기반 로컬 개발 환경을 선택적으로 활용할 수 있습니다.

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

cloudflare오픈 소스JavaScriptCloudflare Workers+4

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

미래를 위한 구축

Cloudflare는 에이전틱 AI 시대에 맞춰 내부 업무·조직·역할을 전면 재설계하기 위해 전 세계 직원 1,100명 이상을 감원한다고 발표했습니다. 이는 개인의 성과나 단순한 비용 절감이 아니라, AI 활용이 급증한 환경에서 회사 운영 방식을 근본적으로 바꾸려는 결정이라는 설명입니다. 회사는 조직 개편을 한 번에 단행해 불확실성을 줄이고, 남은 조직의 속도와 혁신성을 높이겠다고 밝혔습니다. ### 에이전틱 AI 시대에 맞춘 조직 재설계 - Cloudflare는 최근 3개월 동안 사내 AI 사용량이 600% 이상 증가했다고 설명했습니다. - 엔지니어링뿐 아니라 인사, 재무, 마케팅 등 전 부서에서 매일 수천 건의 AI 에이전트 세션을 업무에 활용하고 있습니다. - AI 도구를 고객에게 판매하는 데 그치지 않고, Cloudflare 스스로가 가장 까다로운 AI 고객이 되어야 한다는 입장입니다. - 이에 따라 내부 프로세스, 팀 구조, 직무와 역할을 에이전틱 AI 환경에 맞게 재구성합니다. ### 감원의 성격과 경영진의 책임 - 이번 조치는 1,100명 이상의 글로벌 인력을 줄이는 대규모 구조조정입니다. - 회사는 이를 개인의 역량이나 업무 성과에 대한 평가가 아니며, 단순한 비용 절감도 아니라고 강조했습니다. - 창업자인 Matthew Prince와 Michelle Zatlyn이 직접 모든 직원에게 이메일을 보내며 결정을 전달했습니다. - 관리자나 팀 단위로 소식을 단계적으로 전달하지 않고, 전 직원에게 동시에 안내해 정보의 지연과 혼선을 줄이려 했습니다. - 경영진은 이번 결정을 창업자와 리더가 직접 책임져야 하는 사안으로 규정했습니다. ### 퇴직자를 위한 보상과 지원 - 퇴직자에게 2026년 말까지의 기본급에 해당하는 보상금을 제공합니다. - 미국 직원에게는 의료보험 지원을 2026년 말까지 계속 제공합니다. - 주식 보상은 퇴사 후인 8월 15일까지 베스팅되도록 했습니다. - 근속 1년 미만으로 ‘1년 클리프(cliff)’에 도달하지 못한 직원도 해당 조건을 면제하고, 8월까지 비례 배분된 주식을 받게 됩니다. - 회사는 어려운 결정을 피하는 것이 공감이 아니라, 결정을 내린 뒤 사람을 어떻게 대하는지가 공감이라고 설명했습니다. ### 반복적인 감원 대신 한 번의 결단 - 회사는 여러 분기에 걸쳐 소규모 감원을 반복하거나 구조조정을 장기화하면 직원들의 정서적 불확실성이 커진다고 판단했습니다. - 장기간의 불안정성은 조직의 실행력과 제품 개발을 지연시킬 수 있다고 보았습니다. - 따라서 이번 조치를 한 번에 진행해 퇴직자에게는 즉각적인 명확성을 제공하고, 남은 직원에게는 조직의 안정성을 보장하려 합니다. - 향후 가까운 시일 내에 같은 방식의 추가 감원을 반복하지 않겠다고 밝혔습니다. ### 디지털 기업에서 AI 중심 기업으로의 전환 - Cloudflare는 처음부터 클라우드 기반으로 설계된 디지털 네이티브 기업이었습니다. - 기존 시스템과 관행에 묶인 전통 기업보다 빠르게 성장할 수 있었지만, 이제 시장의 선두 기업이 된 만큼 과거의 업무 방식에 안주할 수 없다고 진단했습니다. - 새 조직은 더 빠르고 혁신적으로 고객 가치를 창출하는 것을 목표로 합니다. - 회사의 사명인 “모두를 위한 더 나은 인터넷 구축”을 지속하기 위해 조직 자체도 미래에 맞게 변화해야 한다고 주장합니다. ### 후속 소통 - Cloudflare는 실적 발표 콘퍼런스콜에서 이번 결정에 대해 추가 설명할 예정이라고 밝혔습니다. - 전사 미팅에서도 직원들에게 직접 발표 내용을 설명하고 질의에 대응할 계획입니다. - 퇴직자들에게는 그동안의 기여에 감사를 표하며, Cloudflare에서 쌓은 경험과 기술이 향후 새로운 기업과 프로젝트를 만드는 데 도움이 될 것이라고 전했습니다. 조직이 AI 중심으로 전환할 때는 기술 도입뿐 아니라 역할, 의사결정 구조, 인력 운영까지 함께 재설계해야 합니다. 다만 대규모 감원은 명확한 전략과 충분한 보상, 투명한 소통이 뒷받침될 때에만 조직의 신뢰와 실행력을 유지할 수 있습니다.

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

cloudflareAIAI 에이전트클라우드 컴퓨팅+1

cloudflare·2026년 5월 1일원문

코드 오렌지: ‘작게 실패하기’가 완료되었습니다. 그 결과 더욱 강력해진 Cloudflare 네트워크 (새 탭에서 열림)

Cloudflare는 2025년 말 발생했던 두 차례의 대규모 장애를 계기로 추진한 인프라 회복 탄력성 강화 프로젝트인 'Code Orange: Fail Small'을 성공적으로 마무리했습니다. 이번 프로젝트를 통해 설정 변경의 안정성을 확보하고, 장애 발생 시 영향을 최소화하며, 비상 상황에서의 대응 체계를 전면 개편했습니다. 결과적으로 Cloudflare 네트워크는 잠재적인 문제를 조기에 감지하고 격리함으로써 전 세계 사용자에게 더욱 신뢰할 수 있는 서비스를 제공할 수 있게 되었습니다. ### 안전한 설정 변경을 위한 Snapstone 도입 설정 변경이 네트워크 전체에 즉각적으로 반영되어 발생하던 대규모 장애를 방지하기 위해 새로운 배포 매커니즘을 구축했습니다. * **Snapstone 시스템 개발**: 설정을 패키지화하여 단계적으로 배포하고, 실시간 상태 모니터링을 통해 문제가 감지되면 자동으로 롤백하는 통합 관리 도구를 도입했습니다. * **점진적 배포의 표준화**: 과거에는 팀별로 달랐던 배포 방식을 Snapstone으로 통일하여, 데이터 파일이나 글로벌 제어 플래그 등 모든 유형의 설정 변경에 '상태 기반 점진적 배포(Health-mediated deployment)'를 적용합니다. * **리스크 관리 자동화**: 위험한 설정 패턴이 발견되면 이를 Snapstone 관리 대상으로 즉시 편입시켜, 별도의 추가 작업 없이도 안전한 배포 사이클을 보장받을 수 있습니다. ### 장애 영향력 최소화 및 서비스 세분화 장애가 발생하더라도 서비스 전체가 중단되지 않도록 시스템의 구조적 유연성을 높였습니다. * **Fail Open 및 Fail Stale 구현**: 최신 설정을 읽지 못할 경우 마지막으로 정상 작동했던 설정을 사용(Fail Stale)하거나, 일부 기능을 제한하더라도 트래픽 흐름은 유지(Fail Open)하도록 프로그래밍 모델을 개선했습니다. * **고객 코호트별 세분화**: 서비스 실행 환경을 여러 독립적인 세그먼트로 나누어, 무료 사용자 그룹에 먼저 업데이트를 적용하고 점진적으로 확대하는 방식을 도입했습니다. * **폭발 반경(Blast Radius) 제한**: 특정 서비스(예: Workers 런타임)에서 문제가 발생하더라도 전체 네트워크가 아닌 소수의 특정 세그먼트에만 영향이 국한되도록 설계하여 대규모 장애로 확산되는 것을 차단합니다. ### 비상 접근 권한(Break Glass) 및 사고 관리 체계 개편 인프라 장애로 인해 관리 도구 자체가 마비되는 '자기 의존성' 문제를 해결하기 위해 비상 대응 절차를 강화했습니다. * **백업 인증 경로 확보**: 핵심 Zero Trust 보안 툴이 작동하지 않는 극한 상황에서도 시스템에 접근할 수 있도록 18개 주요 서비스에 대한 별도의 비상 인증 경로와 스크립트를 마련했습니다. * **실전 중심의 대응 훈련**: 200명 이상의 엔지니어가 참여하는 대규모 드릴(Drill)을 통해 비상 상황에서의 대응 속도와 숙련도를 높였습니다. * **고객 소통 강화**: 내부 모니터링 데이터가 외부 공지 시스템으로 신속하고 명확하게 전달될 수 있도록 소통 프로세스를 개선하여 장애 시 고객의 불확실성을 해소합니다. Cloudflare의 이번 개선 작업은 단순한 기술적 수정을 넘어, '작게 실패(Fail Small)'함으로써 더 큰 가용성을 보장하는 구조적 변화를 의미합니다. 사용자는 이제 더욱 견고해진 인프라 위에서 예상치 못한 설정 오류나 시스템 장애로부터 보호받으며 서비스를 이용할 수 있습니다.

cloudflare제로 트러스트incident-managementconfiguration-management+4

meta·2026년 5월 1일원문

메타가 종단간 암호화된 백업을 강화하는 방법 (새 탭에서 열림)

Meta는 하드웨어 보안 모듈(HSM) 기반의 백업 키 저장소를 통해 왓츠앱(WhatsApp)과 메신저(Messenger)의 종단간 암호화(E2EE) 백업 보안을 강화하고 있습니다. 이 시스템은 사용자의 복구 코드를 위변조 방지 하드웨어에 저장하여 Meta나 클라우드 제공업체를 포함한 제3자의 접근을 원천 차단하며, 최근 무선(OTA) 키 배포 방식과 배포 투명성 강화를 통해 인프라의 신뢰성을 한층 더 높였습니다. ### HSM 기반 백업 키 저장소의 구조 * 지리적으로 분산된 여러 데이터 센터에 HSM 함대(Fleet)를 구축하고, 다수결 합의(Majority-consensus) 복제 방식을 통해 하드웨어 수준의 복원력과 보안성을 확보합니다. * 사용자의 메시지 복구 코드는 HSM 내부에서만 관리되므로 외부에서는 절대 탈취할 수 없는 구조를 가집니다. * 최근 패스키(Passkeys) 지원을 통해 편의성을 높인 데 이어, 기존 비밀번호 기반 암호화 백업 인프라를 보호하기 위한 보안 업데이트를 지속적으로 적용하고 있습니다. ### 무선(OTA) 함대 키 배포 메커니즘 * 메신저 앱의 경우 앱 업데이트 없이도 새로운 HSM 함대를 유연하게 도입할 수 있도록, HSM 응답 과정에서 함대 공개 키를 무선(Over-the-Air)으로 전달하는 방식을 구축했습니다. * 키 배포의 신뢰성을 보장하기 위해 공개 키는 '검증 번들(Validation bundle)' 형태로 제공되며, 이는 Cloudflare의 서명과 Meta의 교차 서명을 통해 독립적인 암호화 증명을 제공합니다. * Cloudflare는 모든 검증 번들에 대한 감사 로그를 유지하여 배포 과정의 무결성을 외부에서 확인할 수 있도록 지원합니다. ### 배포 투명성 및 검증 가능성 * Meta는 시스템이 설계대로 작동하며 사용자 백업에 접근할 수 없음을 증명하기 위해, 새로운 HSM 함대를 배포할 때마다 보안 증거를 블로그 등을 통해 외부에 공개하기로 했습니다. * 함대 배포는 보통 수년 주기로 드물게 발생하지만, 매 배포 시마다 사용자가 기술 백서의 감사(Audit) 절차를 따라 보안성을 직접 검증할 수 있는 환경을 제공합니다. * 이러한 투명성 강화 조치는 Meta가 보안 백업 분야에서 기술적 리더십을 공고히 하고 사용자 신뢰를 얻기 위한 핵심 전략입니다. 종단간 암호화 백업 시스템의 구체적인 작동 원리와 감사 절차가 궁금한 개발자나 보안 전문가는 Meta가 공개한 "Security of End-To-End Encrypted Backups" 기술 백서를 통해 전체 사양을 상세히 확인할 수 있습니다.

cloudflareend-to-end-encryptionhsmkey-distribution+3