http

4 개의 포스트

cloudflare3분 읽기큐레이션 요약

인터넷의 개기일식: 아이슬란드, 스페인, 포르투갈의 트래픽 영향

8월 12일 유럽을 가로지른 개기일식은 사람들의 온라인 활동을 일시적으로 크게 감소시켰다. Cloudflare Radar 분석에 따르면 인터넷 트래픽 하락 시점은 각 지역의 태양 최대 가림 시각과 거의 정확히 일치했으며, 개기일식 경로에 가까울수록 감소 폭도 컸다. 특히 아이슬란드·스페인·포르투갈에서는 트래픽이 최대 약 15~30% 또는 그 이상 줄었다가, 일식이 끝난 뒤 수분 내 정상 수준으로 회복됐다. ## 일식 최대 가림과 인터넷 트래픽 감소의 일치 - Cloudflare는 일식 당일 각 국가의 HTTP 요청량을 5분 단위로 집계했다. - 비교 기준은 같은 시간대의 직전 3개 수요일 트래픽 중앙값으로 설정해 특정 주의 이상치를 줄였다. - 일식이 가장 깊어진 순간을 검은색 다이아몬드로 표시한 결과, 해당 시점이 트래픽 최저점과 거의 겹쳤다. - 개기일식 경로와 깊은 부분일식이 관측된 아이슬란드, 아일랜드, 영국, 프랑스, 스페인, 포르투갈에서 감소 폭이 가장 컸다. - 태양이 거의 가려지지 않은 스웨덴, 덴마크, 폴란드, 스위스에서는 변화가 미미했다. - 일식 최대 가림 직후 사람들이 다시 기기를 사용하면서 트래픽은 대체로 몇 분 안에 회복됐다. ## 태양 가림 정도와 트래픽 하락 폭의 상관관계 - 국가별 최대 태양 가림 비율과 최대 일식 전후 15분간의 평균 트래픽 변화를 비교했다. - 태양이 많이 가려진 지역일수록 트래픽 하락 폭이 커지는 뚜렷한 하향 추세가 나타났다. - 개기일식 경로에 있는 지역은 대략 15~30%의 트래픽 감소를 보였고, 얕은 부분일식 지역은 감소가 작거나 거의 없었다. - 인구 밀도, 관측 시각, 구름 등 지역별 요인이 세부 수치에 영향을 주었지만, 전체적인 방향은 일관됐다. - 하락 시점이 최대 가림 시각과 정확히 맞물린 점까지 고려하면, 트래픽 감소의 주된 원인은 일식 자체로 해석된다. ## 국가별 영향: 아이슬란드·스페인·포르투갈의 큰 하락 - 국가별 트래픽 변화는 약 9.3% 증가부터 -46.7% 감소까지 다양하게 나타났다. - 아이슬란드, 스페인, 포르투갈에서 가장 극적인 트래픽 하락이 발생했다. - 폴란드와 덴마크는 일식 이후 트래픽이 빠르게 평소 수준으로 돌아왔다. - 노르웨이와 스웨덴은 오히려 기준치보다 약간 높은 트래픽을 기록했다. - 덴마크는 전체적으로 일식의 영향이 가장 적은 국가 중 하나였다. - 일식은 알래스카에서 UTC 15시 35분경 시작해 관측 경로를 따라 이동했으며, 국가별 트래픽 변화도 그 순서에 맞춰 나타났다. ## 태양 가림 비율을 계산한 방법 - 각 지역의 태양과 달의 정확한 위치를 바탕으로 두 천체의 겉보기 각 크기와 하늘에서의 거리를 계산했다. - 태양과 달의 원형 원반이 겹치는 면적을 이용해 5분마다 태양 원반이 가려진 비율을 산출했다. - 이를 통해 지역별 최대 가림 비율과 최대 일식 시각을 구했다. - 국가 단위 분석에서는 각 지역의 트래픽을 합산하고, 지역별 가림 정도를 평균해 국가의 대표 최대 일식 시각을 정했다. - 트래픽 수치는 평소 기준 대비 변화율로 표시했으며, 0%는 정상 수준, 음수는 평소보다 낮은 활동을 의미한다. ## 물리적 사건이 디지털 활동에 미치는 영향 - 인터넷 트래픽은 네트워크 장애뿐 아니라 사람들의 관심과 행동 변화를 직접 반영한다. - 이번 사례에서 트래픽 감소는 통신 인프라 문제가 아니라 사람들이 온라인 활동을 멈추고 하늘을 관측했기 때문에 발생했다. - Cloudflare Radar는 일식과 같은 대규모 사건이 전 세계 인터넷 이용 패턴을 어떻게 바꾸는지 추적할 수 있는 분석 도구로 제시된다. - 실제 세계의 공동 경험이 짧은 시간 동안 대륙 전체의 디지털 활동을 동시에 변화시킬 수 있음을 보여준다. 일식처럼 관측 시각이 명확하고 영향 범위가 넓은 사건을 분석할 때는, 실시간 트래픽과 평소 같은 요일의 기준치를 함께 비교하면 사람들의 행동 변화를 정량적으로 파악할 수 있다.

원문 읽기(새 탭에서 열림)
cloudflare4분 읽기큐레이션 요약

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

원문 읽기(새 탭에서 열림)
cloudflare3분 읽기큐레이션 요약

hyper HTTP 라이브러리에서 버그를 발견한 방법

Cloudflare의 Images binding을 로컬 Unix 소켓 기반 구조로 개편한 뒤, 대용량 이미지 응답이 간헐적으로 잘리는 버그가 발생했다. 응답은 HTTP 200과 정상적인 `Content-Length`를 반환했지만 실제 본문은 수백 KB만 전달되어 이미지가 부분적으로 렌더링되거나 디코딩에 실패했다. 원인은 특정 조건에서 발생하는 hyper 라이브러리의 레이스 컨디션이었으며, 최종적으로 네 줄의 코드 수정으로 해결됐다. ### Images binding과 hyper의 데이터 흐름 - Workers는 바인딩을 통해 Images 서비스에 이미지 데이터를 직접 전달하고, 변환 결과를 스트림으로 받을 수 있다. - 이미지 변환 과정은 다음과 같이 진행된다. - Workers 런타임이 소켓을 통해 Images 서비스에 요청을 보낸다. - Images 서비스가 이미지를 합성·리사이즈·트랜스코딩한다. - 변환된 전체 이미지를 메모리 블록으로 hyper에 전달한다. - hyper가 데이터를 내부 버퍼에 저장한 뒤 소켓의 송신 버퍼로 기록한다. - 소켓의 양 끝에는 커널이 관리하는 버퍼가 있다. - 수신자가 충분히 빠르면 hyper가 한 번에 모든 데이터를 보내고 소켓을 종료할 수 있다. - 수신자가 조금이라도 느리면 송신 버퍼가 가득 차고, hyper는 공간이 생길 때까지 추가 쓰기를 기다려야 한다. ### 네트워크 중계에서 로컬 Unix 소켓으로 전환 - 초기 Images binding은 Workers 런타임과 Images 사이에서 FL이라는 내부 중계 서비스를 거쳤다. - FL은 DNS 조회와 라우팅 등 전체 네트워크 처리 파이프라인을 수행했기 때문에 오버헤드가 있었다. - 2025년 12월, Cloudflare는 FL을 같은 머신에서 실행되는 내부 Worker binding으로 교체했다. - 새 구조는 네트워크 소켓 대신 Unix 소켓으로 서비스를 직접 연결했다. - 이 변경으로 다음 효과를 기대했다. - 네트워크 스택과 FL 처리 과정 제거 - Images 요청 경로 단축 - Images 팀이 독립적으로 binding을 배포하고 변경 가능 - 그러나 출시 며칠 뒤부터 대용량 이미지 응답 실패 제보가 접수됐다. ### HTTP 200이지만 잘린 응답 - 고객 사례는 두 단계의 이미지 처리 파이프라인을 중첩한 비표준 구성이었다. - 내부 파이프라인: R2의 JPEG와 PNG를 합성해 JPEG 생성 - 외부 파이프라인: 결과 이미지를 다시 압축·변환·리사이즈 - 실제 문제는 내부 transformation binding의 반환 경로에서 발생했다. - 외부 파이프라인은 내부 응답에서 다음과 같은 모순을 받았다. - 상태 코드는 `200 OK` - `Content-Length`는 수 MB로 설정 - 실제 수신 본문은 일부 데이터에 불과함 - 한 사례에서는 예상 크기 3.3MB 중 약 200KB만 전달됐다. - 상위 계층에서는 다음 오류가 발생했지만, 실제 원인이 어느 서비스에 있는지는 즉시 알기 어려웠다. ```text error reading a body from connection: end of file before message length reached ``` - 브라우저에서는 이미지 형식에 따라 일부만 표시되거나, 하단이 회색으로 남거나, 아예 깨진 이미지로 표시됐다. ### 재현과 원인 범위 좁히기 - 개발팀은 고객의 중첩 파이프라인을 재현하는 Worker를 만들었다. - 이후 외부 파이프라인과 여러 계층을 하나씩 제거해 binding 단독으로도 문제를 재현할 수 있음을 확인했다. - 배치 요청을 보내는 간단한 스크립트로 재현을 자동화했다. - 초기 실행에서는 25건 중 19건이 실패했다. - 매번 도착한 데이터가 약 200KB였는데, 이는 운영 환경의 소켓 버퍼 크기와 매우 유사했다. - 이를 통해 문제는 고객 설정이 아니라 소켓 버퍼가 가득 찬 뒤 hyper가 응답 전송과 연결 종료를 처리하는 방식과 관련 있음을 추정할 수 있었다. - 최종 원인은 특정 타이밍에서 발생하는 hyper 내부의 레이스 컨디션으로 밝혀졌고, 수정에는 네 줄의 코드만 필요했다. ### 실용적인 결론 소켓 기반 스트리밍에서는 `200 OK`나 올바른 `Content-Length`만으로 전송 성공을 판단할 수 없다. 특히 송신 버퍼가 가득 차는 상황, 느린 수신자, 데이터 기록과 연결 종료가 동시에 일어나는 경로를 반드시 테스트해야 하며, 대용량·중첩 파이프라인을 포함한 재현 테스트가 간헐적인 네트워크 버그를 찾는 데 결정적이다.

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

공유 사전: 에이전틱 웹에 발맞춘 압축 기술 (새 탭에서 열림)

웹 페이지의 무게가 매년 증가하고 에이전트 기반의 트래픽이 급증하는 현대 웹 환경에서, 공유 사전(Shared Dictionaries) 기술은 대역폭 낭비를 획기적으로 줄일 수 있는 핵심 솔루션입니다. 이 기술은 클라이언트가 이미 캐시한 데이터를 사전으로 활용해 변경된 차이점(Delta)만 전송함으로써, 잦은 배포와 무거운 에셋 환경에서도 로딩 속도를 극대화하고 서버 부하를 최소화합니다. 클라우드플레어는 이러한 압축 표준인 RFC 9842 지원을 통해 효율적인 에이전틱 웹(Agentic Web) 시대를 대비하고자 합니다. ### 빈번한 배포와 캐싱 효율의 저하 * **에이전트 트래픽의 급증:** AI 크롤러와 에이전트 기반 도구들이 전체 요청의 상당 부분을 차지하며, 이들은 정보를 추출하기 위해 전체 페이지를 반복적으로 호출합니다. * **AI 기반 개발 가속화:** AI 보조 개발로 인해 팀들의 배포 주기가 짧아졌으나, 이는 곧 캐시 무효화의 빈도를 높여 단 몇 줄의 코드 수정만으로도 사용자가 전체 JS/CSS 번들을 다시 다운로드하게 만듭니다. * **중복 데이터 전송:** 기존 압축 방식은 파일 내부의 중복은 줄여주지만, 클라이언트가 이미 95% 동일한 파일을 가지고 있다는 사실을 인지하지 못해 수백 메가바이트의 불필요한 데이터를 전송하게 됩니다. ### 공유 사전과 델타 압축의 메커니즘 * **참조 기반 압축:** 서버와 클라이언트가 공통의 '사전(Dictionary)'을 공유하여, 서버는 "이미 알고 있는 내용은 제외하고 새로운 부분만 보낸다"는 방식으로 데이터를 압축합니다. * **델타 압축(Delta Compression):** 브라우저에 이미 캐시된 이전 버전의 리소스를 사전으로 변환합니다. 예를 들어 500KB 크기의 번들에서 한 줄의 코드만 수정되었다면, 실제 네트워크를 통해 전송되는 크기는 몇 KB 수준으로 줄어듭니다. * **HTTP 헤더 활용:** 서버가 `Use-As-Dictionary` 헤더를 통해 특정 파일을 사전으로 지정하면, 브라우저는 다음 요청 시 `Available-Dictionary` 헤더를 통해 자신이 가진 사전을 서버에 알리고 차이점만 수신합니다. * **지속적인 절감:** 버전 1과 버전 2 사이의 차이점만 전송하고, 다시 버전 2를 사전 삼아 버전 3의 차이점만 전송하는 방식으로 배포 횟수가 늘어나도 데이터 절감 효과가 누적됩니다. ### 과거의 한계 극복과 보안 강화 * **SDCH의 실패와 교훈:** 2008년 구글이 시도했던 SDCH는 성능은 좋았으나 CRIME, BREACH 같은 압축 사이드 채널 공격에 취약했고 동일 출처 정책(Same-Origin Policy) 위반 이슈로 퇴출되었습니다. * **RFC 9842 표준:** 최신 표준인 'Compression Dictionary Transport'는 사전을 동일 출처 응답에만 사용할 수 있도록 강제하여 보안 취약점을 해결했습니다. * **브라우저 지원 현황:** 크롬과 엣지는 이미 지원을 시작했으며 파이어폭스도 도입을 준비 중입니다. 이는 단순한 압축 기술을 넘어 복잡한 캐싱 로직과 실시간 델타 압축을 결합한 고난도 기술 구현의 결과물입니다. 잦은 업데이트가 발생하는 모바일 앱의 웹뷰나 대규모 자바스크립트 프레임워크를 사용하는 프로젝트라면, 공유 사전 기술 도입을 통해 사용자 경험을 혁신할 수 있습니다. 특히 네트워크 환경이 불안정한 사용자나 데이터 비용이 민감한 환경에서 그 가치는 더욱 빛을 발할 것입니다.