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

에이전트에게 필요한 건 컨테이너가 아니라 컴퓨터입니다 — @cloudflare/computer 소개

가장 뛰어난 에이전트는 자체 컴퓨터처럼 사용할 수 있는 파일시스템, 셸, 도구, 실행 환경을 제공받는다는 것이 글의 핵심 주장입니다. Cloudflare는 이를 위해 `@cloudflare/computer`라는 에이전트 런타임을 공개 프리뷰로 제공하며, 격리 실행 환경(isolate)과 컨테이너를 하나의 공유 파일시스템 아래 결합합니다. 이를 통해 컨테이너만 사용하는 방식보다 비용과 확장성 문제를 줄이고, 수억~수십억 개의 동시 에이전트까지 확장하는 것을 목표로 합니다. ## 에이전트마다 컴퓨터를 제공하는 방식 - 코딩 에이전트는 파일시스템, 셸, 패키지, 실행 도구를 직접 사용하면서 환경을 조사하고 코드를 수정·실행·검증한다. - 이런 “컴퓨터”가 모델이 현실의 작업을 수행하는 익숙한 인터페이스가 된다. - `@cloudflare/computer`는 코드가 isolate, 컨테이너, 웹 브라우저 중 어디에서 실행되는지에 대한 세부 사항을 플랫폼이 처리하는 런타임이다. - 각 에이전트에 작업 공간과 실행 환경을 제공하면서 효율성과 확장성을 최적화한다. ## 컨테이너 중심 구조의 확장성 문제 - 초기에는 에이전트 전체를 컨테이너 안에서 실행하는 방식이 일반적이었다. - 최근에는 에이전트의 판단 루프와 실제 코드 실행 환경을 분리하고, 샌드박스를 도구로 호출하는 구조가 확산되고 있다. - 그러나 사용자마다 에이전트 전용 컨테이너를 제공하면 수억, 수십억 개의 동시 에이전트를 감당할 컴퓨팅 자원이 부족하다. - 이 때문에 에이전트 시스템에는 GPU뿐 아니라 막대한 양의 CPU 컴퓨팅 자원도 필요하다. ## Isolate와 컨테이너의 결합 - Cloudflare는 수년 전부터 빠르게 생성·삭제할 수 있고 수평 확장에 적합한 isolate를 핵심 컴퓨팅 단위로 개발해 왔다. - isolate는 다음과 같은 특성을 가진다. - 매우 빠른 시작과 종료 - 유휴 상태에서의 휴면 - 에이전트 상태 저장 - 신뢰할 수 없는 코드를 실행하기 위한 추가 isolate 생성 - 대규모 수평 확장 - Cloudflare의 기존 구조에서는 Durable Object 안에서 에이전트 루프를 isolate로 실행하고, 무거운 작업이 필요할 때만 연결된 컨테이너를 도구로 호출한다. - 즉, 가벼운 작업은 isolate에서 처리하고 Linux, npm, 네이티브 바이너리 등이 필요한 작업만 컨테이너에서 실행해 성능과 비용을 조절한다. - `@cloudflare/computer`는 개발자가 이 여러 컴퓨팅 요소를 직접 조합하지 않아도 되도록 더 단순한 추상화를 제공하려는 실험이다. ## 공유 파일시스템 기반 작업 공간 - 에이전트에게 작업에 필요한 파일과 실행 환경이 미리 준비된 내구성 있는 파일시스템을 제공한다. - 에이전트는 작업 성격에 따라 실행 환경을 선택할 수 있다. - 파일 조작, 데이터 처리, Git 저장소 관리는 isolate에서 실행 - Linux 명령, npm, 네이티브 바이너리가 필요한 작업은 컨테이너에서 실행 - isolate와 컨테이너는 동일한 파일을 사용하며, 변경 사항은 원본 파일시스템과 동기화된다. - 파일시스템은 Git 저장소, 스토리지 버킷, 임의의 파일을 대상으로 사용할 수 있다. - 파일 읽기·쓰기·수정은 Code Mode나 Bash 명령으로 수행할 수 있다. - 모든 작업은 다음 방식으로 관리된다. - 권한 제어 - 감사(audit) - 관찰 및 추적(observability) - 따라서 에이전트가 수행할 수 있는 변경 범위를 세밀하게 제한하고, 어떤 작업을 했는지 기록으로 남길 수 있다. ## 사용 방법과 에이전트 통합 - 패키지는 npm으로 설치한다. ```bash npm install @cloudflare/computer ``` - Durable Object에 `Workspace`를 생성해 가상 파일시스템과 실행 런타임을 연결한다. - `Workspace`는 Durable Object의 저장소를 이용해 에이전트별 상태와 파일을 지속적으로 보관한다. - 예시에서는 `@cloudflare/think` 기반 에이전트가 버그 트리아지를 수행하도록 구성한다. - 시스템 프롬프트를 통해 에이전트가 다음 작업을 수행하게 할 수 있다. - `/workspace/repo`의 프로젝트 조사 - 버그 재현 - 안전한 경우 집중적인 수정 - 검증 명령 실행 - 변경 내용과 실행한 명령, 검증 결과 보고 - `@cloudflare/computer`는 기본 실행 백엔드 외에도 개발자가 직접 백엔드를 작성할 수 있다. - 제공된 `CloudflareContainerBackend`를 사용하면 Workspace를 Cloudflare Container와 연결할 수 있다. - `withWorkspaceContainer` 같은 헬퍼를 통해 에이전트 Durable Object와 컨테이너를 결합한다. ## 실용적인 의미 - 가벼운 작업은 isolate로 처리하고 무거운 작업만 컨테이너로 넘기는 구조가 대규모 에이전트 서비스에 적합하다. - 에이전트별 전용 컨테이너를 항상 실행하는 방식보다 자원 사용량과 비용을 줄일 가능성이 크다. - 파일 변경 권한과 실행 기록을 통제할 수 있어 코드 수정 에이전트, 버그 트리아지, 자동화된 개발 작업에 유용하다. - 현재는 초기 공개 프리뷰이므로, 실제 도입 시 지원되는 백엔드와 API 안정성, 작업 격리 수준, 비용 구조를 확인하는 것이 좋다.

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

TypeScriptCloudflare Workersdurable-objectsisolates+3

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

Workers RPC, 이제 Python과 JavaScript 간에도 작동

Cloudflare Workers의 RPC가 이제 JavaScript/TypeScript와 Python 사이에서도 동작해, 서로 다른 언어로 작성된 Worker가 별도 API 스키마나 의존성 없이 메서드·객체·함수를 주고받을 수 있게 되었습니다. 개발자는 다른 언어의 Worker를 로컬 라이브러리처럼 호출할 수 있으며, 예외·비동기 반환값·콜백도 자연스럽게 전달됩니다. 이를 위해 Pyodide FFI와 사용자 정의 타입 변환 계층을 결합해 두 언어의 타입 체계를 연결했습니다. ## 언어 간 RPC 호출 - TypeScript Worker에서 정의한 `add(a, b)` 메서드를 Python Worker에서 `await rpc.add(42, 144)`처럼 호출할 수 있습니다. - 반대로 Python Worker의 메서드를 JavaScript/TypeScript에서 호출하는 것도 가능합니다. - 별도 패키지나 직렬화 스키마 없이 Service binding만 설정하면 됩니다. ```json { "services": [ { "binding": "RPC", "service": "ts-rpc-server", "entrypoint": "RpcService" } ] } ``` - RPC 대상은 Worker의 엔트리포인트 클래스에 정의된 메서드로 노출됩니다. ## 일반 함수처럼 동작하는 RPC - JavaScript/TypeScript에서는 Promise, Python에서는 Future처럼 비동기 결과를 받습니다. - 원격 메서드에서 발생한 예외는 호출한 쪽의 RPC 호출 지점에서 다시 발생합니다. - Structured Cloneable 타입을 인자와 반환값으로 전달할 수 있습니다. - JavaScript의 `Date`는 Python의 `datetime`으로 변환됩니다. - 숫자, 불리언, 객체, 배열 등 기본 타입도 대응되는 언어의 타입으로 변환됩니다. - 함수를 다른 Worker에 전달하거나 반환할 수 있습니다. - 상대 Worker가 해당 함수를 호출하면 원래 Worker로 역방향 RPC가 발생합니다. - 대부분의 Worker 간 RPC는 네트워크를 거치지 않고 동일한 스레드에서 실행되므로, 같은 Worker 내부 함수 호출에 가까운 성능을 제공합니다. - 구현은 `workerd`와 `workers-runtime-sdk`의 오픈 소스 코드로 제공됩니다. ## JavaScript와 Python의 호출 방식 차이 두 언어는 복잡한 인자를 표현하는 방식이 다릅니다. - JavaScript/TypeScript는 보통 객체를 전달합니다. ```ts myFunction({ key: "myKey", value: true, optional: 1 }); ``` - Python은 위치 인자와 키워드 인자를 사용합니다. ```python my_complex_function("myKey", True, optional=1) ``` - 목표는 호출자가 상대 언어의 내부 표현을 의식하지 않도록 만드는 것입니다. - Python에서 JavaScript 메서드의 옵션 객체를 다음 두 방식으로 모두 전달할 수 있습니다. ```python JSRPC.get("myKey", {"type": "text"}) JSRPC.get("myKey", type="text") ``` - Pyodide FFI가 두 호출을 JavaScript가 기대하는 옵션 객체 형태로 변환합니다. ## Pyodide FFI 기반 타입 변환 Pyodide는 WebAssembly로 컴파일된 CPython이며, Python과 JavaScript 사이의 기본 타입 변환 기능을 제공합니다. | Python 타입 | JavaScript 타입 | |---|---| | `int`, `float` | `Number` | | `bool` | `Boolean` | | `dict` | `Object` | | `list` | `Array` | - 직접 변환하기 어려운 사용자 정의 클래스나 함수는 Proxy 객체로 표현됩니다. - Proxy는 다른 언어의 속성 접근과 메서드 호출을 원격으로 전달합니다. - 이 방식으로 Python 함수를 JavaScript에 콜백으로 넘기는 등의 패턴을 구현할 수 있습니다. ## Cloudflare Workers 객체 처리의 과제 - `Request`, `Response`, `Blob`, `File` 같은 Cloudflare Workers의 Web API 객체는 일반 Python 타입과 달리 Pyodide가 자동 변환하지 못합니다. - 기본 동작에서는 이런 객체를 JavaScript Proxy로 전달합니다. - 기능적으로는 사용할 수 있지만, Python 개발자가 JavaScript 구현 세부사항과 Proxy를 계속 의식해야 하는 문제가 있습니다. - 따라서 언어 간 RPC를 완전히 자연스럽게 만들려면 표준 타입뿐 아니라 Workers 전용 객체에 대한 별도 변환 전략도 필요합니다. ## 실용적인 결론 언어별 강점을 활용해 하나의 Workers 애플리케이션을 구성하려는 경우, 이번 기능은 유용한 선택지입니다. Service binding만으로 TypeScript와 Python Worker를 연결할 수 있으므로, 공통 API 서버나 수동 직렬화 계층을 별도로 만들기보다 RPC를 통해 기능을 라이브러리처럼 분리하는 방식을 고려할 수 있습니다.

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

TypeScriptPythonJavaScriptCloudflare Workers+4

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

Cloudflare Workers와 Containers, 이제 인바운드 TCP 연결 및 gRPC 지원

Cloudflare는 Workers에 인바운드 TCP 소켓을 직접 처리하는 `connect(socket)` 기능과 컨테이너 기반의 양방향 gRPC 지원을 추가했습니다. 이를 통해 클라이언트의 TCP 연결을 Worker, Durable Object, Container로 전달하고, 다양한 언어로 작성된 gRPC 서버를 Cloudflare 네트워크에서 실행할 수 있습니다. 특히 저지연·양방향 통신이 중요한 음성 AI와 실시간 애플리케이션을 클라이언트 가까이에서 처리하는 것이 목표입니다. ## Workers의 인바운드 TCP 지원 - 기존 Workers는 주로 HTTP 요청을 처리하거나 아웃바운드 TCP 연결을 생성하는 방식이었지만, 이제 `connect(socket)` 핸들러로 들어오는 TCP 연결을 받을 수 있습니다. - 소켓은 `readable`과 `writable` 스트림으로 제공되며, 다음과 같이 데이터를 읽고 쓸 수 있습니다. - `socket.writable.getWriter()`로 데이터 전송 - `socket.readable.pipeTo(...)`로 다른 소켓에 데이터 전달 - TCP 연결을 Worker에서 직접 종료하거나, 다른 Worker·Durable Object·Container로 라우팅할 수 있습니다. ## Durable Objects와 Container로 소켓 전달 - Worker는 Durable Object의 `connect()` 메서드를 호출해 인바운드 소켓을 특정 객체로 전달할 수 있습니다. - Durable Object는 양방향 스트림을 연결해 클라이언트와 서버 사이의 바이트를 그대로 중계할 수 있습니다. - Durable Object에서 Container의 TCP 포트에 연결한 뒤 다음과 같이 양방향 파이프를 구성합니다. - 클라이언트 → Container - Container → 클라이언트 - Container에서는 Python, Go 등 원하는 언어와 TCP 서버 구현을 사용할 수 있습니다. - 따라서 특정 RPC 프레임워크에 종속되지 않고, TCP를 사용하는 어떤 프로토콜이나 프로그램도 Cloudflare에서 처리할 수 있습니다. ## Spectrum을 이용한 TCP 진입점 - Cloudflare Spectrum은 HTTP가 아닌 TCP·UDP 트래픽을 Cloudflare 네트워크로 받아들이는 인그레스 프록시입니다. - 새로운 Spectrum 애플리케이션 유형에서는 유입된 TCP 연결을 지정한 Worker의 `connect(socket)` 핸들러로 전달할 수 있습니다. - 결과적으로 클라이언트부터 Cloudflare Worker, Durable Object, Container 내부 서버까지 전체 네트워크 경로를 제어할 수 있습니다. ## Cloudflare Containers의 양방향 gRPC - gRPC는 HTTP/2와 TCP를 기반으로 하는 RPC 프레임워크로, 모바일 앱·분산 시스템·음성 AI 서비스에서 널리 사용됩니다. - 실시간 음성 애플리케이션은 단일 연결에서 클라이언트와 서버가 모두 지속적으로 메시지를 보내야 하므로 양방향 스트리밍이 중요합니다. - Cloudflare의 새 기능을 사용하면 다음과 같은 gRPC 서버를 Container에 배포할 수 있습니다. - 모든 언어로 작성된 gRPC 서버 - 클라이언트와 서버 간 full-duplex 양방향 스트리밍 - 지속적인 단일 TCP 연결 - 예시 gRPC 서버는 연결 직후 `connected` 메시지를 보내고, 클라이언트 메시지마다 `echo` 응답을 보내며, 연결 종료 시 `goodbye` 메시지를 전송합니다. - Cloudflare는 330개 이상의 위치에서 요청을 처리하므로, 서버를 사용자와 가까운 위치에서 실행해 지연 시간을 줄일 수 있습니다. ## Workers 기반 gRPC API - Workers에서는 gRPC 서버를 직접 구현하거나 기존 gRPC 서버를 호출할 수 있습니다. - 개발자는 `gRPC-web` 방식으로 코드를 작성하고, Cloudflare가 요청과 응답을 실제 gRPC 형식으로 변환합니다. - 지원 범위에는 다음이 포함됩니다. - 단일 요청·응답 방식인 unary RPC - 서버가 여러 메시지를 보내는 server-streaming RPC - Container로 소켓을 직접 전달하는 양방향 스트리밍 gRPC - 이 기능을 활용하면 기존 gRPC 생태계를 유지하면서 Cloudflare의 글로벌 네트워크와 Workers의 라우팅 기능을 함께 사용할 수 있습니다. ## 음성 AI와 실시간 서비스에 대한 의미 - AI 음성 비서, 실시간 받아쓰기, 음성 기반 에이전트는 모델·클라이언트·지원 서비스 사이의 낮은 지연 시간이 필수적입니다. - WebSockets와 Durable Objects도 적합하지만, 이미 gRPC를 사용하는 기존 시스템은 새 인프라로 전면 재작성할 필요가 줄어듭니다. - Cloudflare는 TCP 연결을 직접 전달하므로 음성 데이터나 스트리밍 추론 요청처럼 연결을 오래 유지하는 서비스에 적합합니다. - 해당 기능은 현재 프라이빗 베타로 제공되며, 사용을 위해 별도 신청이 필요합니다. 실시간 음성 AI나 기존 gRPC 시스템을 Cloudflare에 배포하려는 경우, `connect(socket)`을 이용해 Worker–Durable Object–Container 간 양방향 스트림을 구성하는 방식이 유용합니다. 다만 현재는 프라이빗 베타이므로 실제 도입 전 지원 프로토콜, 연결 수명, 지연 시간, 비용 및 운영 제한을 확인하는 것이 좋습니다.

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

Cloudflare Workersgrpcdurable-objectstcp+3

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

더 작고, 더 빠르고, 더 안전하게: Kimi와 GLM을 대규모로 실행하기

Cloudflare는 대규모·장문 컨텍스트 MoE 모델인 Kimi와 GLM을 GPU 메모리에 효율적으로 탑재하기 위해 KV 캐시 양자화, 모델 가중치 압축, 공유 캐시 무결성 검사를 적용했다. FP8 KV 캐시와 INT4 가중치는 정확도를 거의 유지하면서 동시 처리량과 비용을 개선하며, 캐시 무결성 검사는 1% 미만의 오버헤드로 데이터 오염 위험을 줄인다. 특히 프리필과 디코드 단계를 분리해 각 단계에 가장 적합한 정밀도를 선택한 것이 핵심이다. ## 장문 컨텍스트의 메모리 병목 - 모델 추론에서 GPU 메모리는 크게 두 부분이 사용된다. - 모델 가중치 - 이전 토큰의 어텐션 Key·Value를 저장하는 KV 캐시 - 장문 컨텍스트 모델에서는 가중치보다 KV 캐시가 먼저 메모리를 가득 채우는 경우가 많다. - Cloudflare는 모든 실험과 운영 트래픽에 오픈소스 추론 프레임워크 SGLang을 사용한다. - 프리필(prefill)은 입력 전체를 처리하는 단계이고, 디코드(decode)는 토큰을 하나씩 생성하는 단계다. - 프리필: 주로 연산량에 제한됨 - 디코드: 메모리 용량과 메모리 대역폭에 제한됨 ## FP8 기반 KV 캐시 양자화 - 기본 BF16 형식의 KV 캐시를 FP8(e4m3)로 저장해 캐시 크기를 절반으로 줄였다. - Kimi K2.6에서는 GPU에 저장 가능한 컨텍스트가 약 68만 6천 토큰에서 137만 토큰으로 증가했다. - 단일 동시 요청에서는 FP8 변환 비용 때문에 BF16보다 토큰 처리 속도가 몇 퍼센트 느리다. - 그러나 더 많은 요청을 동시에 수용할 수 있다. - BF16: 동시 요청 32개에서 메모리 부족 - FP8: 동시 요청 64개까지 처리 - 최대 처리량: 약 41% 증가 - 토큰당 비용: 약 30% 감소 - 프리필은 메모리보다 연산이 병목이므로 BF16을 유지하고, 디코드에만 FP8을 적용한다. - 평가 결과 FP8과 BF16의 성능 차이는 사실상 구분하기 어려웠다. - GSM8K, ARC, MMLU 등 주요 벤치마크에서 점수 차이가 미미함 - 도구 호출 유효성도 BF16 92.2%, FP8 92.6%로 유사 ## INT4 기반 모델 가중치 압축 - GLM 5.2의 가중치를 FP8에서 INT4로 줄였다. - 모델 체크포인트 크기: - 705GB → 421GB - 약 40% 감소 - 8-way 텐서 병렬 구성에서 GPU당 가중치 메모리: - 약 88GB → 52GB - 확보된 공간으로 동일한 하드웨어에서 약 118만 토큰의 KV 캐시를 수용할 수 있다. - 디코드에서는 매 토큰 생성 시 가중치를 GPU 메모리에서 읽어야 하므로, 가중치가 작을수록 메모리 대역폭 부담이 줄어든다. - INT4 디코드 성능 개선: - 동시 요청 1개: 60 → 92 tok/s, 55% 향상 - 동시 요청 8개: 21% 향상 - 동시 요청 32개: 27% 향상 - 반면 프리필에서는 INT4 가중치를 연산 전에 확장해야 하므로 느려진다. - FP8: 약 10,160 tok/s - INT4: 약 8,660 tok/s - 따라서 디코드는 INT4, 프리필은 FP8로 실행하는 방식이 가장 효율적이다. - 벤치마크 전반에서 INT4와 FP8의 정확도 차이는 0.8점 이내로, 실질적인 품질 저하가 관찰되지 않았다. ## 공유 KV 캐시 무결성 검사 - 캐시 압축으로 더 많은 요청이 같은 GPU와 물리적 KV 캐시 페이지를 공유하게 되면서, 페이지 재사용 오류의 위험도 커진다. - Cloudflare는 각 물리적 캐시 페이지에 재할당 때마다 바뀌는 태그를 부여했다. - 요청마다 사용할 페이지와 태그 정보를 기록하고, 디코드 전에 실제 매핑과 일치하는지 검사한다. - 불일치가 발생하면 잘못된 캐시 데이터를 반환하지 않고 해당 요청을 중단한다. - 검사는 어텐션 커널에 직접 삽입하지 않고 별도의 배치 검사로 실행해 GPU 스레드 간 경쟁 상태를 피했다. - 측정 결과 오버헤드는 매우 작았다. - 처리량 감소: 약 0.38~0.79% - p95 지연시간 증가: 약 0.42~0.80% - 기능이 필요 없는 배포 환경에서는 기본 no-op 추적기를 사용해 측정 가능한 오버헤드가 없다. ## 향후 방향 - 더 많은 모델과 배포 환경에 FP8 KV 캐시를 확대할 예정이다. - NVIDIA Blackwell GPU에서 NVFP4 가중치를 검증하고 있다. - KV 캐시 무결성 검사를 거의 비용 없이 모든 환경에서 활성화하는 것을 목표로 한다. - 이러한 최적화는 정확도를 유지하면서 더 많은 고객에게 낮은 비용으로 모델을 제공하기 위한 기반이다. 실용적으로는 추론 단계를 하나의 설정으로 처리하기보다, 프리필과 디코드의 병목이 다르다는 점을 반영해 정밀도를 분리하는 것이 중요하다. 디코드에는 FP8 KV 캐시와 INT4 가중치를, 프리필에는 BF16 KV 캐시와 FP8 가중치를 선택하는 방식이 대표적인 최적화 전략이다.

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

gpu-inferencemixture-of-expertskv-cachecontinuous-batching+4

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

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

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

모델 컨텍스트 프로토콜cloudflareCloudflare Workersfinops+3

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

에이전트 주간에 오신 것을 환영합니다

에이전트 시대의 클라우드는 인간 중심으로 설계된 기존 클라우드를 단순히 확장하는 것이 아니라, 에이전트의 요구를 출발점으로 새롭게 설계해야 한다. 동시에 현재의 인간 중심 웹과 미래의 에이전트 중심 환경을 연결하는 번역 계층도 필요하다. Agents Week는 이러한 Agent Cloud의 구조와 실행 환경, 개발 생명주기, 보안, 웹의 변화를 다룬다. ### 인간 중심 클라우드의 한계 - 기존 클라우드와 웹은 사람이 직접 보고, 읽고, 클릭하고, 판단하는 상황을 전제로 설계됐다. - 페이지는 사용자의 관심을 끌도록 구성되고, 대시보드는 사람이 탐색하고 조작하기 쉽게 만들어졌다. - 에이전트는 사람처럼 피로하거나 산만해지지 않으며, 속도·구조화된 정보·시스템 접근성 등 다른 요구사항을 가진다. - 따라서 인간용 도구를 에이전트에게 그대로 제공하는 방식에는 한계가 있다. ### Agent Cloud의 두 가지 역할 - 장기적으로는 에이전트를 위한 기본 구성 요소를 처음부터 설계하는 ‘에이전트 네이티브’ 클라우드가 되어야 한다. - 단기적으로는 현재 존재하는 인간 중심 웹과 앞으로 등장할 에이전트 중심 웹 사이를 연결해야 한다. - 즉, Agent Cloud는 새로운 실행·저장 환경인 동시에 기존 시스템과 에이전트 간의 변환 계층 역할을 수행해야 한다. ### Agents Week에서 다루는 주제 - 에이전트에 필요한 스토리지·컴퓨팅·실행 프리미티브 - 인간의 개입을 최소화한 에이전트 중심 소프트웨어 개발 생명주기(ADLC) - 조직 내부의 시스템 오브 레코드에 에이전트와 직원이 안전하게 접근하는 방법 - 권한 관리와 안전한 제어를 통한 에이전트의 실제 업무 수행 - 정보 탐색, 서비스 접근, 결제 등을 포함한 에이전트 중심 웹의 변화 - 현재의 인간과 에이전트가 함께 일하는 현실적인 환경에서의 적용 방식 ### 에이전트에게 직접 요구사항 묻기 - Agent Cloud가 무엇이어야 하는지 사람의 관점에서 추측하기보다, 에이전트에게 직접 질문해야 한다는 것이 글의 핵심 제안이다. - 질문에는 다음과 같은 영역을 포함할 수 있다. - 스토리지와 컴퓨팅 - 실행 및 데이터 저장 프리미티브 - 인간의 개입이 줄어든 개발 생명주기 - 조직 내 핵심 시스템에 대한 안전한 접근 - 웹에서의 정보 발견, 서비스 이용, 결제 - 독자들이 자신의 에이전트에게 질문하고, 그 답변과 통찰을 공유하도록 권한다. 에이전트용 인프라를 설계할 때는 기존 인간 중심 인터페이스를 자동화하는 데 그치지 말고, 에이전트가 빠르고 구조화된 방식으로 실행·접근·판단할 수 있는 기본 요소부터 정의해야 한다. 동시에 권한, 보안, 기존 시스템과의 호환성을 갖춘 연결 계층을 마련하는 것이 현실적인 출발점이다.

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

AI 에이전트클라우드 컴퓨팅sdlcagent-cloud+2

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

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 릴레이를 통해 서버 운영과 확장 부담을 줄일 수 있다. 운영 시에는 방송자와 시청자 토큰을 반드시 분리하고, 만료 기간과 폐기 정책을 설정해 권한 탈취 위험을 최소화하는 것이 좋다.

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

cloudflarejwtcdnwebrtc+3

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

대규모 도그푸딩: cdnjs를 Cloudflare의 개발자 플랫폼으로 마이그레이션하기

cdnjs는 2026년 6월 23일부터 Cloudflare Developer Platform만으로 운영되며, 이를 통해 하루 90억 건의 요청을 처리하는 대규모 오픈소스 CDN의 배포 파이프라인까지 단일 플랫폼으로 통합했다. 기존 시스템은 안정적이고 높은 캐시 적중률을 유지했지만, GCP·VM·GitHub·Cloudflare로 분산된 구조 때문에 관측성과 유지보수가 어려웠다. 이번 마이그레이션은 성능 개선보다 배포·처리 과정의 단순화, 추적 가능성, 보안성 향상에 초점을 둔 것이다. ### cdnjs가 여전히 대규모 트래픽을 처리하는 이유 - cdnjs는 JavaScript와 CSS 오픈소스 라이브러리를 무료로 제공하는 커뮤니티 기반 CDN이다. - 사용자는 API 키나 회원가입 없이 `<script>` 태그만으로 jQuery, Bootstrap, Lodash 등을 불러올 수 있다. - 전체 웹사이트의 약 12%, JavaScript CDN 시장의 48.3%가 cdnjs를 사용한다. - 하루 약 90억 건, 초당 평균 10만 8천 건의 요청을 처리하며 330개 이상의 Cloudflare 데이터센터에서 서비스한다. - 캐시 적중률은 98.6%에 달한다. - URL 규칙이 일관되고 버전이 불변이어서 ChatGPT, Claude, Cursor 같은 LLM이 예제 코드에 안정적으로 활용하기 쉽다. - 각 파일에 SRI 해시가 제공되고 미러가 감사 가능해 공급망 공격 대응에도 유리하다. - 무료·무제한 서비스라는 점 역시 cdnjs가 계속 사용되는 중요한 이유다. ### 기존 아키텍처의 배경 - 2020년 파일 제공 영역은 Cloudflare Workers와 KV로 이전됐다. - KV 장애 시에는 베어메탈 오리진을 사용하는 구조로 복원력을 높였다. - Brotli와 gzip으로 모든 자산을 사전 압축해 응답 크기도 줄였다. - 그러나 새 버전 감지, 패키지 다운로드, 압축, 처리 결과 저장을 담당하는 퍼블리싱 파이프라인은 GCP에 남아 있었다. - 당시 Workers에는 장시간 실행 작업, 대용량 아카이브 처리, 다단계 오케스트레이션을 지원할 기능이 충분하지 않았다. - 이에 따라 GCP Functions, VM 기반 `git-sync`, GCS, Pub/Sub, GitHub 저장소가 서로 연결된 형태로 운영됐다. ### 관측성과 데이터 일관성의 문제 - 하나의 패키지 업데이트가 Cloud Functions, GCS 이벤트, Pub/Sub, `git-sync` VM, Workers KV를 거쳤지만 공통 correlation ID가 없었다. - GCP Logging과 Cloudflare Logpush의 로그를 연결할 기준이 없어 장애 원인을 수작업으로 추적해야 했다. - 처리 결과가 KV에는 기록됐지만 GitHub 저장소 반영에 실패하는 부분 성공(partial success)이 발생할 수 있었다. - 두 저장소가 불일치해도 전체 파이프라인 상태를 아는 시스템이나 자동 알림이 없었다. - 파일은 엣지의 KV와 GitHub 저장소에 동시에 존재했지만 어느 쪽도 명확한 단일 원본이 아니었다. ### 이벤트 기반 파이프라인의 한계 - 여러 Cloud Functions가 공유 스토리지에 파일을 기록하고, 스토리지의 새 파일 이벤트가 다음 함수를 호출하는 방식이었다. - 스토리지가 메시지 큐 역할까지 맡으면서 구조가 복잡해졌다. - 명시적인 dead-letter queue가 없어 실패한 작업을 확인하기 어려웠다. - 대기 중인 작업의 backlog를 파악하기 어렵고, 특정 단계부터 깔끔하게 재실행하기도 힘들었다. - npm 업데이트 확인만 해도 알파벳별로 나눈 26개의 Cloud Functions가 필요했다. - 각 함수마다 별도의 배포와 로그가 있어 전체 시스템의 정상 여부를 확인하려면 26개를 모두 점검해야 했다. ### GitHub 저장소의 규모 문제 - `git-sync` VM은 처리된 모든 파일을 GitHub 저장소에 미러링했다. - 저장소의 packed storage가 1.1TB를 넘으면서 GitHub의 tarball·zip 아카이브 생성이 불가능해졌다. - 클론 속도가 느려지고 포크도 사실상 어려워졌다. - 비정상적이거나 처리하기 곤란한 릴리스를 차단하기 위한 `.gitignore` 항목이 274개까지 늘어났다. - GitHub 저장소는 원본 저장소이면서 동시에 배포 미러 역할까지 맡아 장기적인 확장에 부적합해졌다. ### 보안과 운영 부담 - GCP Functions, `git-sync` VM, 컨테이너 이미지, GCS 버킷, 서비스 계정 키 등 관리해야 할 보안 대상이 많았다. - 각 구성 요소마다 패치, 접근 권한 관리, 감사가 필요했다. - 기존 파이프라인을 폐기하면서 최근 발견된 cdnjs 관련 취약점도 함께 줄일 수 있었다. - 시스템 구성 요소가 줄어들어 장애 대응과 보안 관리가 단순해졌다. ### Cloudflare Developer Platform으로의 재구축 - 새 아키텍처는 Workers, Workflows, D1, Queues, Workers Cache, R2, KV, Containers를 사용해 Cloudflare 안에서 전체 파이프라인을 운영한다. - R2가 파일 콘텐츠의 단일 원본(single source of truth)이 됐다. - 실질적인 크기 제한이 없어 기존 KV에 저장하기 어려웠던 소스 맵, 대형 번들, 폰트 패키지도 함께 저장할 수 있다. - R2의 S3 호환 API를 통해 cdnjs 전체 카탈로그를 일반적인 S3 클라이언트로 접근하고 미러링할 수 있다. - 저장소와 처리 시스템을 하나의 플랫폼으로 통합함으로써 배포 상태 추적, 재처리, 장애 분석을 개선할 기반을 마련했다. ### 실용적인 시사점 대규모 서비스에서는 높은 성능이나 캐시 적중률만으로 충분하지 않다. 여러 클라우드와 저장소에 걸친 파이프라인은 부분 성공, 데이터 불일치, 로그 단절 문제를 만들 수 있으므로, 명확한 단일 원본과 공통 추적 ID, 재처리 가능한 작업 큐를 설계하는 것이 중요하다. 또한 플랫폼이 장시간 작업과 대용량 데이터를 지원할 만큼 성숙해졌다면, 분산된 운영 스택을 통합하는 것이 기능 추가와 보안 관리에 큰 이점이 된다.

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

Cloudflare Workers서버리스content-delivery-networkcloudflare-r2+3

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

오리진에 대한 양자 이후 인증이 이제 지원됩니다

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 인증서를 추가하는 데 그치지 말고, 원본 서버의 신뢰 저장소에서 기존 양자 취약 인증 방식을 제거해야 다운그레이드 공격까지 방어할 수 있다.

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

cloudflarepost-quantum-cryptographyml-dsaopenssl+4

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

자연재해와 정부 개입: 2026년 2분기 주요 인터넷 장애 사건 분석

인터넷 장애는 자연재해·정전 같은 물리적 사건부터 정부의 의도적 차단, 클라우드 인프라 손상, DNSSEC 설정 오류까지 다양한 원인으로 발생하며, 서로 다른 원인도 사용자에게는 비슷한 “연결 불가”로 나타난다. Cloudflare Radar의 Q2 2026 분석은 이란의 88일 인터넷 차단 종료, 괌 태풍, 수단·이라크의 시험 기간 차단, 독일 `.de` 도메인 장애 등을 통해 인터넷의 취약성과 동시에 높은 복원력을 보여준다. 다만 이 글은 모든 이상 현상이 아니라 확인된 주요 장애 사례를 다룬다. ### 자연재해와 정전이 네트워크에 미친 영향 - **괌의 슈퍼태풍 신라쿠** - 4월 중순 태풍이 괌 북쪽을 지나가며 열대폭풍급 강풍과 광범위한 정전을 일으켰다. - 전력과 수도 시스템이 영향을 받으면서 4월 13~14일 인터넷 트래픽이 예상치보다 최대 80% 감소했다. - 섬이 태풍의 직접적인 타격을 피했음에도 디지털 연결성이 크게 흔들렸다. - **베네수엘라 지진** - 6월 24일 북부 베네수엘라에서 규모 7.5 지진과 추가 지진이 연이어 발생했다. - 지진 발생 시점에 HTTP 전송 바이트가 급격히 감소했으며, Fibex Telecom, CANTV, VNET 등 주요 ISP에서 동일한 현상이 관측됐다. - 특히 약 160만 명의 사용자를 보유한 것으로 추정되는 Fibex Telecom에서 감소가 뚜렷했다. - **탄자니아 정전** - 6월 27일 발생한 정전으로 인터넷 트래픽이 최소 5시간 동안 급락했다. - 원인은 정부의 의도적 차단이 아니라 전력 인프라 장애였지만, 사용자에게 나타난 결과는 통신과 뉴스 접근이 불가능해지는 등 과거의 국가적 차단과 유사했다. - 서로 다른 사건도 데이터상으로는 “트래픽의 급격한 소실”이라는 비슷한 패턴을 남긴다. - 이러한 사례는 전력 공급, 라우팅 경로, 물리적 회선의 중복성을 확보해야 인터넷이 외부 충격을 견딜 수 있음을 보여준다. ### 정부 정책과 지정학적 갈등에 따른 접속 제한 - **이란의 인터넷 복구** - 2월 28일부터 이어진 약 88일간의 전국적 인터넷 차단이 5월 26일부터 점진적으로 해제되기 시작했다. - 5월 27일 트래픽은 차단 전의 약 40%까지 회복됐고, 이후 최대 90%까지 상승한 뒤 약 59% 수준으로 안정됐다. - 완전한 정상화라기보다 최근 차단 이전 수준에 가까운 부분적 복구로 평가된다. - 2026년 월드컵 분석에서도 이란의 트래픽은 경기 일정이 아니라 차단과 복구의 극적인 대비에 의해 좌우됐다. - **중동 분쟁과 AWS 인프라 손상** - UAE의 AWS `me-central-1` 리전 트래픽은 계속 낮은 수준을 유지했다. - 드론 공격으로 UAE와 바레인의 데이터센터 시설이 물리적 피해를 입었고, AWS는 UAE 리전이 고객 애플리케이션을 안정적으로 지원하지 못한다고 밝혔다. - 이는 네트워크 자체의 장애가 아니라 데이터센터 손상이 해당 리전에 호스팅된 웹사이트와 애플리케이션에 영향을 준 사례다. - **시험 기간의 국가 인터넷 차단** - 이라크에서는 6월 2일, 11일, 28일 세 차례 차단이 발생했으며 각각 약 90분간 지속됐다. - 수단에서는 4월 13~23일 사이 열 차례 차단이 시행됐고, 매번 약 3.5시간 동안 이어졌다. - 두 국가 모두 국가시험 부정행위를 막기 위해 시험 시간에 맞춰 접속을 차단했다. - 정부는 국가 인터넷을 완전히 끄거나, 속도를 낮추거나, 일부 사용자에게만 재개하는 등 정책적으로 연결성을 통제할 수 있다. ### DNSSEC 오류로 발생한 독일 `.de` 도메인 장애 - 5월 5일 독일 국가 코드 도메인 `.de`를 관리하는 DENIC의 DNSSEC 키 교체 과정에서 잘못된 서명이 생성됐다. - DNSSEC 검증 리졸버는 서명이 현재 공개된 키와 일치하지 않으면 DNS 응답을 위조나 변조로 간주한다. - 그 결과 전 세계 검증 리졸버가 `.de` 도메인 요청을 거부하고 `SERVFAIL` 오류를 반환했다. - 장애는 5월 6일 23:15 UTC에 정상화됐다. - 장애 중 `.de` 질의량이 오히려 증가했는데, 실패한 응답은 캐시에 저장되지 않아 사용자의 재시도와 반복 조회가 늘어났기 때문이다. - 사용자는 암호화 서명 문제를 직접 인식하기보다 독일 도메인의 웹사이트와 서비스가 갑자기 열리지 않는 현상으로 경험했다. ### 해저 케이블과 지역 인프라의 취약성 - 세인트루시아에서는 해저 케이블 절단이 지역 인터넷 연결을 약화시켰다. - 이 사건은 특정 국가나 지역의 국제 연결이 제한된 수의 물리적 케이블에 의존할 경우, 단일 절단만으로도 사용자 접속이 크게 영향을 받을 수 있음을 보여준다. - DNSSEC 장애와 케이블 절단은 원인은 다르지만, 인터넷 서비스가 정상적으로 보이기 위해서는 암호화 검증 체계와 물리적 전송 경로가 모두 안정적으로 운영되어야 한다는 점을 공통적으로 드러낸다. 인터넷 회복력을 높이려면 전력·라우팅·해저 케이블·데이터센터의 중복성을 확보하고, DNSSEC 키 교체 같은 정기 유지보수에는 철저한 검증 절차를 적용해야 한다. 또한 정부와 사업자가 연결성을 정책적으로 차단할 수 있는 만큼, 장애 원인이 기술적 고장인지 의도적 차단인지 구분해 모니터링하는 것도 중요하다.

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

AWScloudflare-radardnssecinternet-infrastructure+3

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

프라이버시 프록시 CLI를 오픈 소스로 공개합니다

Oblivious HTTP(OHTTP)는 여러 주체와 바이너리 인코딩을 거치기 때문에 장애 원인을 추적하기 어렵다. Cloudflare는 실제 운영 경험을 바탕으로 전체 OHTTP 요청 과정을 한 번에 실행하고 각 단계를 확인할 수 있는 오픈소스 CLI 도구 `pvcli(privacy-client)`를 만들었다. 이 도구는 복잡한 수작업과 일회성 스크립트를 줄여 개발·테스트·장애 대응을 단순화한다. ### OHTTP가 제공하는 프라이버시 구조 - OHTTP는 요청을 보낸 사람과 요청 내용을 한 주체가 동시에 알 수 없도록 설계된다. - 서로 충돌하지 않는 두 운영 주체가 필요하다. - **Relay**: 클라이언트의 신원을 gateway에 전달하지 않음 - **Gateway**: 요청을 복호화해 실제 대상 서버로 전달 - 일반적인 요청 흐름은 다음과 같다. - 클라이언트가 gateway의 공개 키를 가져온다. - 클라이언트가 HTTP 요청을 암호화해 relay로 보낸다. - relay가 클라이언트 식별 정보를 제거하고 gateway로 전달한다. - gateway가 요청을 복호화해 target 서버에 전송한다. - target의 응답을 gateway가 다시 암호화한다. - relay가 암호화된 응답을 클라이언트에 전달한다. - 클라이언트가 응답을 복호화한다. - 각 단계가 별도의 장애 지점이므로, 문제가 relay·gateway·target 중 어디에서 발생했는지 확인하기 어렵다. ### 기존 디버깅 방식의 문제 - 고객 환경에서 실제 end-to-end 테스트를 수행하려면 배포별 맞춤 클라이언트를 일회성으로 작성해야 했다. - 장애 발생 시 자체 시스템의 문제인지 고객 시스템의 문제인지 판별하는 데 시간이 많이 걸렸다. - OHTTP는 바이너리 HTTP를 사용하므로 원시 바이트를 직접 분석해야 했다. - 공개 키, 바이너리 HTTP 요청, 암호화된 OHTTP 메시지를 RFC에 따라 수작업으로 해석해야 했다. - 사람이 긴 hexadecimal 문자열을 직접 검증하는 과정은 번거롭고 실수하기 쉽다. ### 공개 키와 바이너리 HTTP의 수동 분석 - gateway에서 받은 공개 키 설정은 긴 hexadecimal 데이터로 반환된다. - RFC 9458에 따라 다음 필드를 직접 해석해야 한다. - `0029`: 공개 키 항목의 길이 - `55`: 공개 키 ID - `0020`: DHKEM(X25519, HKDF-SHA256) 비대칭 암호 방식 - 뒤따르는 32바이트: 실제 공개 키 - `0004`: 대칭 암호 방식 ID 영역의 길이 - `0001`, `0001`: HKDF-SHA256 및 AES-128-GCM 식별자 - 원래의 HTTP 요청도 RFC 9292의 바이너리 HTTP 형식으로 변환해야 한다. - 예를 들어 `POST`, `https`, 호스트명, 경로, 헤더와 본문이 각각 바이너리 필드로 인코딩된다. - 이후 공개 키를 이용해 바이너리 HTTP 요청을 OHTTP 형식으로 암호화하고, 키 ID와 암호 방식 ID를 포함한 헤더를 붙여 relay에 보낼 wrapper HTTP 요청을 만들어야 한다. ### `pvcli`의 역할 - Cloudflare는 이러한 프라이버시 프로토콜 관련 기능을 하나의 CLI에 통합했다. - 익숙한 HTTP 클라이언트 인터페이스를 제공하면서 OHTTP의 각 처리 단계를 순서대로 표시한다. - relay, gateway, origin으로 이어지는 전체 요청을 단일 명령으로 실행할 수 있다. - 예시 명령은 다음 작업을 수행한다. - `--first-hop`: relay 지정 - `--proxy`: gateway 지정 - `-X POST`: HTTP 메서드 지정 - `--header`: 요청 헤더 지정 - `--data`: JSON 요청 본문 지정 - 대상 URL: gateway가 요청을 전달할 origin - 따라서 사용자는 공개 키 조회, 바이너리 HTTP 변환, OHTTP 암호화, relay 전달, 응답 복호화 과정을 각각 수동으로 구현할 필요가 없다. ### 공개와 활용 - 도구 이름은 `privacy-client`, 실행 파일은 `pvcli`다. - Apache-2.0 라이선스로 공개되며 외부 기여를 허용한다. - 새로운 프라이버시 프로토콜이나 다양한 네트워크 아키텍처를 지원할 수 있도록 확장성을 고려했다. - 운영 환경과 유사한 end-to-end 테스트 및 장애 재현에 활용할 수 있다. 복잡한 OHTTP 시스템을 운영하거나 연동한다면, 원시 바이트와 RFC를 직접 해석하는 방식보다 `pvcli`로 전체 경로를 재현하는 것이 효율적이다. 특히 relay·gateway·origin 중 장애 위치를 빠르게 좁혀야 하는 개발 및 incident response 상황에서 유용하다.

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

cryptographyclioblivious-httpbinary-http+3

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

BGP ORIGIN 속성 조작과 인터넷에 미치는 영향

BGP의 ORIGIN 속성은 경로가 어떻게 BGP에 주입됐는지를 나타내며, 원래 발신 AS가 설정한 뒤 다른 라우터가 변경하지 않는 것이 원칙입니다. 그러나 실제 인터넷에서는 관측된 경로의 약 70%가 최초 설정값과 다른 ORIGIN을 보였고, 이는 경로 선택과 트래픽 흐름에 큰 영향을 줍니다. 특히 일부 트랜짓 사업자는 더 많은 트래픽과 수익을 확보하기 위해 ORIGIN을 선호도가 높은 IGP로 바꾸고 있습니다. ## BGP ORIGIN 속성의 역할 - ORIGIN은 경로를 BGP에 주입한 방식을 나타내며, 경로를 발표한 AS 자체를 뜻하는 `origin AS`와는 다릅니다. - 가능한 값은 다음 세 가지입니다. - `IGP (0)`: 발신 AS 내부에서 생성된 경로 - `EGP (1)`: 현재는 폐기된 Exterior Gateway Protocol을 통해 학습한 경로 - `INCOMPLETE (2)`: 출처가 불명확하거나 외부 방식으로 학습한 경로 - RIPE RIS와 RouteViews의 공개 수집기에서 관측된 경로 분포는 다음과 같습니다. - IGP: 89.8% - EGP: 3.5% - INCOMPLETE: 6.7% - Local Preference와 AS_PATH 길이가 동일한 경로를 비교할 때, 라우터는 더 낮은 ORIGIN 값을 가진 경로를 선택합니다. 따라서 선호도는 일반적으로 `IGP > EGP > INCOMPLETE` 순서입니다. - RFC 4271은 ORIGIN을 최초 발신자가 생성하며, 다른 라우터는 변경하지 않아야 한다고 규정합니다. ## ORIGIN 변조가 트래픽에 미치는 영향 - 두 트랜짓 사업자가 동일한 목적지에 대해 비슷한 길이의 AS_PATH를 제공하면, ORIGIN 값이 경로 선택을 좌우할 수 있습니다. - 예를 들어 AS64501이 `INCOMPLETE`로 경로를 발표했을 때: - AS64502와 AS64503은 원래 해당 값을 유지한 채 경로를 전달해야 합니다. - 하지만 AS64503이 ORIGIN을 `IGP`로 바꾸면, 최종 고객 AS64504는 동일한 AS_PATH 길이에서 AS64503 경로를 선택하게 됩니다. - 결과적으로 AS64503은 더 많은 트래픽을 유치하고 트랜짓 수익을 늘릴 수 있습니다. - 이는 RFC 준수 여부보다 경쟁 사업자와의 트래픽 확보 경쟁이 우선되는 “수익 중심의 라우팅 경쟁”으로 이어집니다. ## 인터넷 운영 관행과 ORIGIN 폐기 논의 - 트랜짓 사업자가 ORIGIN을 IGP로 덮어써 경로 선호도를 높이는 관행은 오랫동안 운영자 커뮤니티에서 사실상 묵인되어 왔습니다. - RIPE 91 회의에서 James Bensley가 주요 네트워크의 광범위한 변조를 공개적으로 지적했고, 이후 LACNIC 45 회의에서는 라틴아메리카 지역의 영향을 조사했습니다. - 이 관행이 공개되면 중단될 가능성도 있지만, 경쟁 사업자들이 계속 변조할 경우 다른 사업자도 “경쟁 조건을 맞추기 위해” 같은 방식을 택할 유인이 있습니다. - ORIGIN 처리 방식이 인터넷 전체에서 일관되지 않게 되면서, ORIGIN 속성의 폐기를 권고하는 Internet-Draft도 작성되었으나 현재는 만료된 상태입니다. ## 변조 현황을 측정한 실험 방법 - 연구진은 IPv4 3개와 IPv6 3개의 테스트 프리픽스를 발표했습니다. - 각 프리픽스에는 각각 `IGP`, `EGP`, `INCOMPLETE` 중 서로 다른 ORIGIN 값을 설정했습니다. - BGP Anycast를 이용해 여러 피어링 지점에서 발표한 뒤, 전 세계로 전파되었는지 확인했습니다. - 이후 프리픽스를 철회해 BGP의 path hunting 과정에서 추가 경로가 드러나도록 했습니다. - 분석에는 다음 데이터가 사용되었습니다. - RIPE RIS 및 RouteViews의 MRT 덤프 - BGPKIT으로 처리한 BGP Update 메시지 - 연구진 경계 라우터에서 수집한 BMP 데이터 - RIB 스냅샷보다 Update 메시지를 사용한 이유는 발표와 철회 과정에서 나타나는 더 많은 경로를 확보하기 위해서입니다. - 다만 공개 BGP 모니터는 인터넷 전체 AS와 연결 구조를 볼 수 없습니다. - 하이퍼스케일러와 CDN이 기존 트랜짓 대신 직접·지역 피어링을 늘리고 있기 때문입니다. - 따라서 관측 결과는 전체 인터넷 토폴로지를 완전히 대표하지 못하며, AS의 의도나 특성에 대한 추론에는 불확실성이 남습니다. ## 두 홉 AS_PATH에서 확인된 변조 - 연구진은 먼저 `ASX AS13335`처럼 AS가 두 개뿐인 AS_PATH를 분석했습니다. - 연구진의 AS가 특정 ORIGIN으로 경로를 발표했으므로, 직접 피어 ASX에서 다른 ORIGIN이 관측되면 ASX가 값을 변경했다고 판단할 수 있습니다. - IPv4 직접 피어 352개를 조사한 결과 다음과 같은 행위가 발견되었습니다. - 3개 AS는 원래 값과 관계없이 ORIGIN을 EGP로 변경했습니다. - 4개 AS는 원래 값과 관계없이 INCOMPLETE로 변경했습니다. - 이는 고객 경로보다 덜 선호되도록 만들어 해당 경로의 선택 가능성을 낮추려는 의도일 수 있습니다. - 한 네트워크 운영자는 피어 또는 프로바이더로부터 받은 경로의 ORIGIN을 EGP로 바꾸어 고객 경로보다 낮은 우선순위를 부여한다고 확인했습니다. - 일부 AS는 비-IGP 경로에 대해 원래 ORIGIN과 IGP를 모두 전파했습니다. - 커뮤니티와 AGGREGATOR 같은 다른 속성을 함께 분석한 결과, 여러 피어링 지점에서 경로를 받고 특정 지점으로 트래픽을 유도하기 위해 IGP로 변경한 것으로 추정됩니다. - 글의 서두에서 제시한 전체 관측 결과에 따르면, 다양한 관측 지점에서 약 70%의 경로가 최초 발신 AS가 설정한 값과 다른 ORIGIN을 보였습니다. ## 실용적인 시사점 - ORIGIN은 단순한 메타데이터가 아니라 BGP 경로 선택과 트래픽 분배를 바꿀 수 있는 실질적인 정책 수단입니다. - 네트워크 운영자는 ORIGIN 변조 여부를 확인하기 위해 BGP Update와 여러 관측 지점의 경로를 비교하고, 커뮤니티·AGGREGATOR·AS_PATH를 함께 분석해야 합니다. - 경로 선택 정책을 ORIGIN에만 의존하면 사업자의 의도적인 조작에 취약하므로, Local Preference와 명시적인 커뮤니티 정책을 우선적으로 활용하는 것이 바람직합니다.

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

bgpipv6autonomous-systemsipv4+4

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

캐시 응답 규칙 소개

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 등 원본 응답의 캐시 관련 정보를 보정하는 방식으로 함께 사용하는 것이 적절하다.

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

cloudflarecachingcdncache-response-rules+2

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

2026년 월드컵이 인터넷 트래픽에 미친 영향

2026년 월드컵은 전 세계 사람들의 온라인 활동을 경기 시간과 관심도에 따라 크게 변화시켰다. Cloudflare는 전 세계 네트워크의 트래픽을 분석해, 심야 경기는 인터넷 사용량을 평소보다 두 배 이상 높인 반면 저녁 경기는 사람들이 기기를 내려놓으면서 트래픽을 감소시킬 수 있음을 보여줬다. 특히 아르헨티나 관련 경기가 세계 인터넷 활동에 가장 큰 영향을 미쳤고, 대회 기간 스포츠 베팅 사이트 트래픽도 뚜렷하게 증가했다. ## 월드컵 효과를 측정한 방법 - 국가별 인터넷 사용량은 규모 차이가 크기 때문에 단순한 요청량 대신, 각 국가의 최근 4주간 분당 트래픽 중앙값을 ‘평소’의 기준으로 삼았다. - 현재 트래픽과 기준 트래픽의 비율을 로그₂ 값으로 변환했다. - `0`: 평소와 동일 - `+1`: 평소의 2배 - `-1`: 평소의 절반 - 이 방식은 국가별 인터넷 규모가 달라도 증가와 감소를 대칭적으로 비교할 수 있게 한다. ## 경기 시작 시간이 온라인 활동에 미친 영향 - 자정부터 오전 8시 사이에 시작한 경기는 평소 인터넷 사용자가 적은 시간대에 열리므로 트래픽 증가폭이 가장 컸다. - 팬들이 늦게까지 깨어 있거나 일찍 일어나 경기를 시청하면서 일부 국가에서는 트래픽이 평소의 두 배를 넘었다. - 오전 9시부터 오후 중반까지의 경기는 사람들이 원래 온라인 상태인 시간대에 열려, 트래픽 변화가 크지 않았다. - 초저녁 경기는 평일에 작은 트래픽 증가를 유발했다. 평소 사용량이 줄어들기 시작하는 시간에 사람들이 계속 온라인에 머물렀기 때문이다. - 저녁 경기는 오히려 트래픽을 낮출 수도 있었다. 보스니아 헤르체고비나에서는 저녁 경기가 진행될 때 트래픽이 평소의 약 70%까지 떨어졌다. ## 같은 경기도 국가별로 정반대의 효과 - 브라질과 일본의 경기는 두 나라에서 12시간의 시차를 두고 시청됐다. - 일본에서는 경기가 한밤중에 열려 트래픽이 평소보다 약 두 배 높은 수준인 `+1` 부근까지 상승했다. - 브라질에서는 일상적인 활동 시간에 경기가 열려 트래픽이 평소보다 낮은 `-0.4` 정도를 기록했다. - 즉 경기가 인터넷 활동을 추가로 발생시키기도 하지만, 사람들이 평소 하던 웹 활동을 멈추고 경기에 집중하게 만들기도 했다. ## 세계 인터넷을 가장 크게 움직인 경기 - 각 경기 시작 후 2시간 동안 국가별 트래픽이 평소에서 얼마나 벗어났는지 계산했다. - 증가와 감소를 모두 ‘영향’으로 간주하기 위해 국가별 편차의 절댓값을 사용했다. - 동시 진행된 경기는 어느 경기가 트래픽 변화의 원인인지 구분하기 어려워 분석에서 제외했다. - 가장 큰 영향을 준 경기는 결승전이나 준결승전이 아닌 아르헨티나-스위스 8강전이었다. - 전 세계 트래픽 영향 계수: 약 `1.26` - 프랑스-스페인 준결승은 약 `1.21`로 뒤를 이었다. - 상위권에는 8강, 16강뿐 아니라 32강 경기까지 다양하게 포함됐다. ## 가장 큰 관심을 끈 팀 - 팀별로 해당 팀의 모든 경기가 각국 트래픽에 미친 영향을 집계했다. - 아르헨티나가 영향 계수 `1.17x`로 1위를 차지했다. - 아르헨티나 경기 때 일반적인 국가의 트래픽이 평소보다 약 17% 크게 움직였다는 의미다. - 디펜딩 챔피언이라는 지위와 리오넬 메시의 국가대표 마지막 무대 가능성이 관심을 높인 요인으로 해석됐다. - 프랑스, 브라질, 포르투갈, 모로코, 스페인, 노르웨이도 높은 순위를 기록했다. - 아이티와 이라크는 전체 트래픽 규모가 작아 주요 팀과의 경기에서 상대적으로 큰 변동률을 보인 특이 사례로 언급됐다. ## 스포츠 베팅 사이트 트래픽 증가 - 월드컵 개막 전 한 달과 비교했을 때 도박·스포츠 베팅 관련 웹사이트 요청량이 전반적으로 증가했다. - 대회 전에는 주중·주말에 따른 뚜렷한 주기성이 있었지만, 개막 이후에는 거의 매일 경기가 열리면서 트래픽 패턴이 일정하게 평탄화됐다. - 이는 월드컵이 경기 시청뿐 아니라 베팅과 같은 온라인 활동도 지속적으로 자극했음을 보여준다. ## 실용적인 시사점 - 글로벌 서비스는 이벤트 시간대를 현지 시간으로 변환해 트래픽 급증과 감소를 모두 대비해야 한다. - 심야 경기가 열리는 지역에서는 CDN, 서버 용량, 인증·결제 시스템의 과부하를 사전에 점검할 필요가 있다. - 반대로 사람들이 경기에 집중해 일반 웹사이트 이용을 줄이는 시간대에는 광고 노출이나 콘텐츠 게시 일정을 조정할 수 있다. - 국가별 시간대와 문화적 관심도를 함께 분석하면 단일한 글로벌 기준보다 훨씬 정확한 트래픽 예측이 가능하다.

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

dnsdata-analysiscloudflare-radarhttp-traffic+2

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

Cloudflare 내부 DNS 정식 출시

Cloudflare Internal DNS는 퍼블릭 DNS와 프라이빗 DNS를 하나의 글로벌 플랫폼과 제어 평면에서 통합하는 서비스다. 이를 통해 스플릿-호라이즌 DNS의 동기화 문제를 줄이고, Zero Trust 정책·감사·가시성을 DNS에도 적용할 수 있다. Cloudflare Gateway를 사용하는 Enterprise 고객은 추가 비용 없이 사용할 수 있으며, 기존 DNS 어플라이언스와 클라우드별 DNS를 대체하는 것을 목표로 한다. ## 기존 내부 DNS 운영의 한계 - 퍼블릭 DNS, 사설 DNS, 클라우드별 DNS가 서로 다른 플랫폼에서 운영되는 경우가 많다. - 시스템마다 보안 정책과 관리 방식이 달라 전체 DNS 구성을 한눈에 파악하기 어렵다. - 스플릿-호라이즌 DNS에서는 같은 호스트명에 대해 내부 사용자와 외부 사용자에게 서로 다른 응답을 제공해야 한다. - 여러 DNS 환경의 레코드를 별도로 관리하면 설정이 서로 어긋나는 드리프트가 발생하고, 장애로 이어질 수 있다. - 레거시 DNS 장비는 하드웨어 교체 주기, 용량 확장, 유지보수 부담을 발생시킨다. ## Cloudflare Internal DNS의 핵심 가치 - 퍼블릭·프라이빗 DNS를 하나의 API, 감사 로그, 정책 관리 체계로 통합한다. - 공유된 존에 여러 DNS 뷰를 적용해 스플릿-호라이즌 DNS를 중복 구성 없이 구현한다. - Cloudflare Gateway의 사용자·기기 기반 정책으로 어떤 DNS 뷰를 사용할지 제어한다. - DNS 질의 필터링, 라우팅, 로깅을 기존 Zero Trust 정책과 동일한 체계로 관리한다. - 1.1.1.1을 운영하는 글로벌 인프라를 활용하므로 별도 장비 설치나 용량 사전 확보가 필요 없다. ## 두 가지 핵심 구성 요소 - **Gateway Resolver** - DNS 재귀 조회와 정책 평가를 담당한다. - 질의를 차단하거나 특정 업스트림으로 전달할 수 있다. - 유연한 조건식, 로깅, 감사 기능을 제공한다. - 정책에 따라 내부 DNS 뷰 또는 퍼블릭 DNS 경로를 선택한다. - **Internal Authoritative DNS** - 프라이빗 리소스의 권한 있는 DNS 레코드를 제공한다. - 애플리케이션, 서비스 엔드포인트, 데이터베이스 등의 내부 존을 관리한다. - Cloudflare의 기존 권한 있는 DNS 플랫폼 위에서 동작한다. ## 주요 객체: 존, 뷰, 리졸버 정책 - **Internal Zone** - 내부 리소스의 권한 있는 레코드를 저장한다. - 예: `corp.internal`, `db.corp.internal`. - **DNS View** - 특정 사용자·기기 그룹이 볼 수 있는 존과 레코드의 해석 맥락을 정의한다. - 내부 사용자에게는 사설 주소를, 외부 사용자에게는 퍼블릭 주소를 제공하는 데 사용된다. - **Resolver Policy** - Gateway에서 질의를 평가하고 특정 DNS View로 전달한다. - 조건에 따라 질의를 허용, 차단하거나 퍼블릭 DNS로 보낼 수 있다. - **Zone Reference** - 하나의 공유 존을 여러 뷰에서 재사용한다. - 동일한 레코드를 뷰마다 복사하지 않으므로 중복과 설정 불일치를 방지한다. ## DNS 질의 처리 과정 - 클라이언트의 질의는 먼저 Gateway Resolver에 도착한다. - 리졸버 정책이 내부 뷰를 지정하면 해당 질의는 Internal Authoritative DNS로 전달된다. - 정책이 질의를 차단하면 응답 없이 삭제된다. - 일치하는 정책이 없으면 1.1.1.1을 통해 퍼블릭 DNS 계층에서 조회한다. - 내부 뷰에서 이름을 찾지 못할 경우 퍼블릭 DNS로 폴백하도록 구성할 수 있어, 클라이언트는 내부·외부 이름을 구분할 필요가 없다. ## DNS 변경 사항의 전파 - 대시보드, Terraform, 직접 API 호출 등 모든 변경은 동일한 DNS Records API를 거친다. - 하나의 쓰기 경로를 사용하므로 변경 이력과 감사를 일관되게 관리할 수 있다. - 변경 내용은 Cloudflare 핵심 데이터센터에 저장되고 검증된 뒤 글로벌 네트워크로 복제된다. - 관련 캐시가 무효화되므로 TTL 만료를 기다리지 않고 수 초 내에 변경 사항이 반영된다. - Terraform 변경도 대시보드나 API 변경과 동일한 전파 경로를 따른다. ## 설정 방법 - Cloudflare 대시보드의 **Networking → Internal DNS**에서 시작한다. - 일반적인 구성 순서는 다음과 같다. 1. 내부 존 생성 2. 내부 DNS 레코드 생성 3. DNS View 생성 후 존 연결 4. Gateway Resolver Policy를 만들어 특정 트래픽을 해당 뷰로 라우팅 - 예시로 `corp.internal` 존을 만들고 `db.corp.internal`을 `10.0.1.50`으로 지정할 수 있다. - Cloudflare API와 Terraform을 모두 사용할 수 있다. - 현재 Cloudflare Gateway를 사용하는 Enterprise 고객이 이용 대상이다. ## Connectivity Cloud와의 통합 - 다음과 같은 DNS 연결 방식과 함께 사용할 수 있다. - Cloudflare One Client(WARP) - DNS over HTTPS(DoH) - DNS over TLS(DoT) - 표준 DNS 53번 포트 - PAC 파일 배포 - Cloudflare WAN - Cloudflare WAN을 사용하면 개별 단말에 One Client를 설치하지 않아도 연결된 네트워크의 장치가 내부 호스트명을 조회할 수 있다. - 원격 사용자, 지사, 데이터센터, 클라우드 환경을 하나의 제어 평면으로 연결해 일관된 DNS 경험을 제공한다. - Internal DNS는 독립적인 DNS 제품이라기보다 Zero Trust와 네트워크 연결을 포함한 Cloudflare Connectivity Cloud의 기능 확장이다. 내부·외부 DNS를 여러 시스템에서 따로 운영하고 있다면, 공유 존과 DNS View를 중심으로 구성을 통합하는 것이 유용하다. 특히 Cloudflare Gateway와 WAN을 이미 사용 중인 조직은 별도 DNS 장비를 줄이고, 정책·감사·전파 경로를 단일화하는 방안을 검토할 만하다.

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

제로 트러스트dnsTerraformcloudflare-gateway+4