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

포스트양자 시대의 EO는 중요한 이정표다. 이제 실행에 옮길 때다

미국의 행정명령 14409호는 연방기관이 2030년까지 고위험 시스템의 암호화를, 2031년까지 디지털 서명과 인증을 양자내성암호(PQC)로 전환하도록 요구한다. 이는 양자컴퓨터가 현재의 RSA와 타원곡선 암호를 무력화할 가능성에 대비한 중요한 이정표이며, 특히 이미 진행 중인 암호화 전환과 달리 인증 전환은 지금부터 서둘러야 한다. 글은 각 기관이 자산을 조사하고 단계적인 전환 계획을 세우되, 민간과 중요 인프라도 같은 준비를 시작해야 한다고 주장한다. ## 행정명령 14409호의 주요 요구사항 - 2026년 6월 22일 트럼프 대통령이 「첨단 암호 공격으로부터 국가 보호」 행정명령에 서명했다. - 대상은 주로 다음 두 종류의 연방 시스템이다. - **고가치 자산(HVA)**: 국가안보, 외교, 국민 신뢰에 중대한 영향을 주는 핵심 시스템 - **고영향 시스템**: FIPS 199 기준으로 기밀성·무결성·가용성의 영향도가 ‘높음’인 시스템 - 주요 일정은 다음과 같다. - **2026년 7월**: 각 기관이 PQC 전환 책임자를 지정 - **2026년 9월**: OMB가 자산 목록 검토, 전환 계획 수립 및 제출을 요구 - **2030년 12월**: HVA와 고영향 시스템의 키 설정을 PQC로 전환 - **2031년 12월**: 디지털 서명과 인증서를 PQC로 전환 - 국가안보시스템(NSS)은 행정명령의 일정에서 제외되며, NSA가 관리하는 별도 기밀 전환 일정이 적용된다. - 행정명령의 직접적인 법적 적용 대상은 연방기관이며, 주·지방정부, 중요 인프라, 학계, 시민사회에는 직접 의무를 부과하지 않는다. ## 양자컴퓨터가 만드는 시급성 - 양자컴퓨터가 충분히 발전하면 현재 인터넷에서 널리 쓰이는 **RSA와 타원곡선암호(ECC)**를 깨뜨릴 수 있다. - NIST는 2024년 기존 공개키 암호를 2030년까지 단계적으로 폐기하고 2035년까지 사용을 금지하는 방향을 제시했다. - 최근 연구 발전으로 ‘Q-Day’, 즉 암호학적으로 유의미한 양자컴퓨터가 등장하는 시점이 앞당겨질 가능성이 커졌다. - 미국 정부가 양자컴퓨팅 개발을 촉진하는 동시에 2031년까지 PQC 인증을 요구한 것은, 그 무렵 실용적인 양자컴퓨터가 등장할 가능성을 무시할 수 없다고 판단했음을 시사한다. ## 암호화와 인증은 서로 다른 전환이다 ### 포스트양자 암호화 - 양자컴퓨터에 안전한 키 설정과 암호화를 사용해 통신 내용을 보호한다. - 현재 가장 중요한 위협은 **‘지금 수집하고 나중에 복호화’** 공격이다. - 공격자가 오늘 암호화된 데이터를 저장해 두었다가, 미래에 양자컴퓨터로 복호화할 수 있다. - 다음과 같이 장기간 가치가 유지되는 데이터를 보유한 조직은 즉시 전환을 시작해야 한다. - 정부기관 - 은행 및 금융기관 - 의료기관 - 방위산업체 - 통신사업자 - 인터넷 전반에서 이미 전환이 진행 중이며, Cloudflare는 브라우저 트래픽의 3분의 2 이상에 PQC 암호화를 적용하고 있다고 설명한다. ### 포스트양자 인증 - 양자컴퓨터를 이용한 다음과 같은 위조 공격을 막는다. - 서버 인증서 위조 및 서버 사칭 - 악성 코드 서명 생성 - 시스템에 대한 무단 접근 - 암호화와 달리, 인증 공격은 실제로 강력한 양자컴퓨터가 등장해야 본격적으로 가능하다. - 그러나 인증 전환은 더 복잡하고 시간이 오래 걸리므로 Q-Day 이후가 아니라 지금부터 준비해야 한다. - ML-DSA 같은 PQC 디지털 서명은 기존 서명보다 크기가 커서 짧은 TLS 연결의 성능과 네트워크 비용에 영향을 줄 수 있다. - 인증 전환에는 다음 구성요소의 동시 업그레이드가 필요하다. - 클라이언트와 서버 - 인증기관(CA) - 인증서 투명성 로그 - 루트 저장소 - 웹 브라우저 - Cloudflare는 Google Chrome과 함께 Merkle Tree Certificates를 연구해 대형 PQC 서명이 TLS 성능에 미치는 영향을 줄이려 하고 있다. ## 표준화된 PQC와 QKD의 차이 - 행정명령이 NIST가 표준화한 PQC 알고리즘에 초점을 맞춘 점은 타당하다고 평가한다. - 양자키분배(QKD)는 다음 이유로 인터넷 전체에 적용하기 어렵다. - 특수 하드웨어가 필요하다. - 송신자와 수신자 사이에 전용 물리 링크가 필요하다. - 기존 인터넷 규모로 확장하기 어렵다. - 따라서 범용 인터넷과 연방 시스템의 현실적인 경로는 표준화된 PQC 알고리즘을 기존 암호 체계에 통합하는 것이다. ## Cloudflare가 제시하는 전환 현황 - Cloudflare는 2029년까지 암호화와 인증을 포함한 완전한 포스트양자 보안을 달성하는 것을 목표로 한다. - 대부분의 제품이 PQC 키 합의를 지원하며, Cloudflare One은 다음 연결 경로에 PQC 암호화를 제공한다. - TLS - MASQUE - IPsec - 암호화 전환은 이미 상당히 진행됐지만, 포스트양자 인증 배포는 아직 초기 단계다. - 글은 이번 행정명령이 이전 행정부와 민간 부문이 진행해 온 작업을 확대하는 기반이라고 평가한다. ## 실용적인 권고 - 조직은 먼저 공개키 암호가 사용되는 자산과 데이터를 목록화해야 한다. - 장기 보존 가치가 있는 데이터는 ‘수집 후 복호화’ 공격을 고려해 PQC 암호화를 우선 적용해야 한다. - 인증 전환은 인증서, 브라우저, 서버, CA 등 의존성을 함께 점검하고 장기 마이그레이션 계획을 세워야 한다. - 연방기관뿐 아니라 금융·의료·통신·방위 분야 조직도 2030~2031년 일정을 외부 기준으로 삼아 지금부터 테스트와 단계적 도입을 시작하는 것이 바람직하다.

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

post-quantum-cryptographyquantum-computingcryptographyelliptic-curve-cryptography+3

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

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 WorkersRusthttprace-condition+2

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

AI 에이전트를 위한 임시 Cloudflare 계정

Cloudflare는 AI 에이전트가 사람의 개입 없이 코드를 배포할 수 있도록 ‘임시 계정’을 출시했다. 에이전트는 `wrangler deploy --temporary`를 실행해 별도 회원가입이나 OAuth, API 토큰 입력 없이 Worker를 배포하고, 60분 동안 결과를 테스트할 수 있다. 사용자가 그 안에 계정을 클레임하면 영구 계정이 되며, 클레임하지 않으면 자동 삭제된다. ## AI 에이전트 배포에서 인증이 걸림돌이 되는 이유 - 기존 클라우드 서비스 가입 과정은 브라우저 OAuth, 대시보드 조작, API 토큰 복사, MFA 입력 등 사람을 전제로 한다. - 백그라운드에서 실행되는 AI 에이전트는 브라우저를 열거나 사용자의 즉각적인 확인을 기다리기 어렵다. - 인증 단계에서 멈추면 에이전트가 다른 배포 서비스를 선택할 가능성도 있다. - 에이전트는 코드를 작성하고 배포한 뒤 직접 요청을 보내 검증하는 반복 작업이 중요하므로, 빠르고 저렴한 임시 배포 환경이 필요하다. ## `wrangler deploy --temporary`를 통한 배포 - 최신 Wrangler CLI에서 다음 명령으로 임시 계정에 Worker를 배포할 수 있다. ```bash wrangler deploy --temporary ``` - 사용자가 Cloudflare에 로그인하지 않은 상태에서 배포를 시도하면 Wrangler가 `--temporary` 옵션을 안내한다. - 에이전트가 해당 옵션으로 다시 배포하면 Cloudflare가 자동으로: - 임시 Cloudflare 계정을 생성하고 - Wrangler가 사용할 API 토큰을 발급하며 - 사용자가 계정을 인수할 수 있는 클레임 URL을 제공한다. - 에이전트는 별도의 사람 확인 없이 코드를 작성하고 즉시 배포할 수 있다. ## 작성·배포·검증의 반복 루프 - 에이전트는 TypeScript Worker를 생성한 뒤 배포 결과로 받은 미리보기 URL에 `curl` 등을 실행해 동작을 검증한다. - 예를 들어 “hello world” Worker를 배포한 뒤 응답이 코드와 일치하는지 확인할 수 있다. - 이후 소스 코드를 수정하고 같은 임시 계정을 재사용해 여러 번 재배포할 수 있다. - 임시 계정은 60분의 클레임 기간 동안 유지되므로, 에이전트가 여러 차례 수정·테스트하는 데 적합하다. ## 임시 계정의 클레임과 자동 삭제 - 사용자는 에이전트가 제공한 클레임 링크를 클릭해 Cloudflare에 가입하거나 로그인할 수 있다. - 계정을 클레임하면 임시 계정이 영구적으로 사용자의 계정이 된다. - Worker뿐 아니라 데이터베이스와 기타 바인딩 리소스도 함께 인수할 수 있다. - 60분 이내에 클레임하지 않으면 임시 계정과 배포된 리소스가 자동으로 삭제된다. ## 더 넓은 에이전트용 인프라 - Cloudflare는 Stripe와 협력해 에이전트가 사용자를 대신해 계정 생성, 구독 시작, 도메인 등록, API 토큰 발급까지 수행할 수 있는 프로토콜도 개발하고 있다. - WorkOS와는 기존 OAuth 표준을 활용해 에이전트가 계정을 생성할 수 있도록 하는 `auth.md` 프로젝트를 추진했다. - 임시 계정은 이러한 ‘에이전트 친화적 배포’ 전략의 한 단계로 소개된다. - 기능과 제한 사항은 변경될 수 있으므로 실제 사용 전 Cloudflare 개발자 문서를 확인해야 한다. 에이전트가 짧은 실험이나 프로토타입을 자동으로 배포·검증해야 한다면 `wrangler deploy --temporary`가 유용하다. 다만 60분 내에 클레임하지 않으면 리소스가 삭제되므로, 장기 운영 서비스는 반드시 계정을 클레임하고 정식 인증·관리 체계로 전환해야 한다.

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

AI 에이전트TypeScriptCloudflare Workersstripe+4

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

나만의 취약점 테스트 하네스 구축하기

프론티어 모델 하나에 의존하는 대신, 모델을 교체할 수 있는 취약점 분석 하니스(harness)를 구축해야 한다는 글입니다. 하니스는 정찰·탐색·검증·중복 제거·재검증·트리아지를 지속적으로 수행하며, 수천 개의 후보를 실행 가능한 취약점 목록으로 줄입니다. 핵심은 LLM을 상태를 보존하지 않는 계산 엔진으로 취급하고, 분석 상태와 결과를 데이터베이스 및 파이프라인에 외부화하는 것입니다. ## 단일 에이전트 방식의 한계 - 일반적인 코딩 에이전트는 한 번에 하나의 가설만 유지하므로 대규모 저장소의 여러 공격 경로를 동시에 분석하기 어렵습니다. - 컨텍스트 창이 가득 차면 컨텍스트 압축 과정에서 이전에 발견한 버그나 분석 근거를 잃을 수 있습니다. - 단일 저장소만 분석하면 다른 애플리케이션·라이브러리·서비스와의 연결에서 발생하는 취약점을 놓칩니다. - 한 번 실행한 결과는 전체 버그의 약 절반 정도만 찾으며, 비교적 단순한 취약점에 편향되는 경향이 있습니다. - 분석을 여러 번 실행한 뒤 결과를 사람이 직접 비교해야 한다면, 이미 전용 하니스가 필요한 단계에 도달한 것입니다. ## 모델에 독립적인 하니스가 필요한 이유 - 특정 모델에 시스템을 맞추면 해당 모델이 코드를 바라보는 방식에 분석 범위가 고정됩니다. - 서로 다른 모델을 같은 코드에 적용하면 각 모델이 서로 다른 취약점을 발견할 수 있습니다. - 예를 들어 한 모델은 초기 탐색을 담당하고, 다른 모델은 발견된 취약점의 재현 가능성과 타당성을 검증하도록 구성할 수 있습니다. - 모델이 교체되거나 더 뛰어난 모델이 등장해도 하니스의 상태 관리·오케스트레이션·트리아지 구조는 그대로 유지할 수 있습니다. - 따라서 장기적으로 중요한 자산은 특정 프롬프트나 모델보다 모델을 연결하고 결과를 관리하는 하니스입니다. ## 초기 보안 감사 스킬 처음에는 약 450줄 규모의 `security-audit` 스킬을 단일 저장소에서 실행하며 프롬프트를 조정했습니다. 이후 이 스킬의 단계가 전체 하니스의 기본 구조로 확장되었습니다. - **정찰(Recon)** - 세 개의 병렬 연구 에이전트가 저장소 구조와 아키텍처를 조사합니다. - 결과를 `architecture.md`에 기록합니다. - **공격 탐색(Hunt)** - 공격 클래스별로 Hunter 에이전트를 실행합니다. - 코드를 검토하는 데 그치지 않고 실제로 깨뜨리는 시도를 합니다. - **검증(Validate)** - 적대적 검증 에이전트가 각 발견을 반박하려고 시도합니다. - 재현되지 않거나 근거가 약한 후보를 제거합니다. - **보고서 작성(Report)** - 살아남은 취약점을 사람이 읽을 수 있는 보고서로 정리합니다. - **기계적 검증** - `findings.json`을 정해진 스키마에 맞춰 생성합니다. - 파일 형식뿐 아니라 취약점에 언급된 함수와 줄 번호가 실제 소스에 존재하는지도 검사합니다. - **독립 재검증** - 별도의 새로운 에이전트가 소스를 기준으로 모든 발견을 다시 확인합니다. - 최종 생존 항목만 수집 API로 제출합니다. ## 파이프라인으로의 확장 초기 스킬의 단계는 다음과 같이 하니스의 파이프라인으로 대응됩니다. - `architecture.md`를 생성하는 연구 에이전트 → **Recon** - 공격 유형별 Hunter → **Hunt** - 발견을 반박하는 Validator → **Validate** - 검증된 항목의 보고서화 → **Report** - `findings.json`의 스키마 및 소스 위치 검사 → **기계적 검증** - 새로운 에이전트의 최종 확인 → **독립 검증** 이 구조는 한 번의 긴 세션에 모든 작업을 몰아넣지 않고, 각 작업을 독립적으로 실행·저장·재시작할 수 있게 합니다. ## 상태를 외부화해야 하는 이유 - **컨텍스트 고갈** - 장시간 실행하면 모델이 기존 분석 내용을 잊습니다. - 분석 상태, 가설, 조사 결과, 발견 사항을 데이터베이스 등에 저장해 모델의 기억에 의존하지 않도록 해야 합니다. - LLM은 상태를 가진 작업자라기보다 필요할 때 호출되는 계산 엔진으로 취급합니다. - **지속성 부족** - 네트워크 오류, API 제한, 프로세스 충돌이 발생해도 처음부터 다시 시작해서는 안 됩니다. - 각 단계의 진행 상황과 결과를 저장하면 중단된 지점부터 재개할 수 있습니다. - **재범위 지정과 교차 참조** - 독립적인 조사 결과를 나중에 다시 불러오고, 다른 발견이나 저장소와 연결할 수 있어야 합니다. - 수백 개의 조사를 별도의 실행 단위로 유지해야 중복 제거와 후속 검증이 가능합니다. ## 대규모 트리아지와 교차 저장소 분석 - 엔터프라이즈 환경에서는 원시 취약점 후보가 수천 개 생성될 수 있습니다. - 하니스는 후보를 수집하는 것에서 끝나지 않고, 검증·중복 제거·우선순위 지정 과정을 거쳐 신뢰할 수 있는 수정 큐로 줄여야 합니다. - 단일 저장소 분석만으로는 해당 저장소를 사용하는 애플리케이션과의 인터페이스 문제를 볼 수 없습니다. - 여러 저장소 간 의존성과 데이터 흐름을 추적하면 구성 요소 사이에서만 드러나는 취약점을 찾을 수 있습니다. - 다만 교차 저장소 추적은 초기 구현부터 넣기보다, 실제로 중요한 저장소가 여러 개일 때 도입하는 것이 권장됩니다. ## 단계적으로 구축하는 방법 - 최소한의 하니스는 데이터베이스에 상태를 저장하는 **Recon, Hunt, Validate** 세 단계로 시작할 수 있습니다. - 자기 자신이 발견 사항을 제출하지 못하는 별도의 Validator를 두어 검증 편향을 줄입니다. - 먼저 개발 환경에서 단일 스킬로 프롬프트와 공격 시나리오를 충분히 다듬습니다. - 다음 기능은 현재의 병목이 명확해졌을 때만 추가합니다. - 중단 후 재개가 문제라면 영속성 추가 - 결과가 너무 많으면 중복 제거 에이전트 추가 - 여러 저장소가 실제 분석 대상이 되면 교차 저장소 추적 추가 - 초기부터 전부 자동화하기보다, 현재 작업을 가장 느리게 만드는 문제를 해결하는 방향으로 하니스를 확장해야 합니다. 실용적으로는 특정 모델이나 프롬프트에 시스템을 종속시키지 말고, 분석 상태·발견 사항·검증 결과를 저장하는 모델 독립적 파이프라인부터 구축하는 것이 좋습니다.

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

AI 에이전트vulnerability-scanningsecurity-auditllm-orchestration+3

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

프로젝트 갈릴레오 12주년 기념

Cloudflare의 Project Galileo는 표현의 자유와 민주주의를 지키는 시민사회 조직이 권력이나 공격 때문에 온라인에서 퇴출되지 않도록 무료 보안 서비스를 제공하는 프로그램이다. 출범 12년째인 2026년에는 120개국 3,400개 이상의 웹사이트를 지원하며, 시민사회 대상 사이버공격이 일반 인터넷 사용자보다 더 빈번하고 강도 높다는 연례 보고서를 처음 발표했다. Cloudflare는 저렴하고 단순한 보안 접근성, 공격과 인터넷 차단에 대한 투명성, AI 및 포스트퀀텀 보안의 기본 적용을 앞으로의 과제로 제시했다. ## Project Galileo의 역할과 성장 - Cloudflare가 12년 전 시작한 공익 프로그램으로, 언론인·인권 옹호자·비영리단체 등에 무료 사이버보안 서비스를 제공한다. - 현재 120개국 3,400개 이상의 웹사이트가 참여하고 있다. - Cloudflare 네트워크는 125개국 335개 이상의 도시에 분포하며, 전체 웹의 20% 이상을 처리한다. - 이 광범위한 네트워크 덕분에 시민사회 조직에 대한 공격과 일반 고객 대상 공격을 비교할 수 있었다. - 프로그램 참여 신청은 59개 시민사회 파트너가 심사·승인하며, 파트너들은 하루에도 여러 건의 신청을 검토한다. ## 시민사회 대상 사이버공격의 주요 추세 - **DDoS 공격** - 시민사회 조직에 가장 흔한 위협이었다. - 단시간 공격보다 지속 시간이 긴 것이 특징이며, 일부 공격은 며칠 또는 몇 주간 이어졌다. - **웹사이트 취약점 공격** - 시민사회 단체를 대상으로 한 취약점 악용 시도가 일반 Cloudflare 고객보다 7배 이상 많았다. - 특히 미디어 조직이 불균형적으로 큰 피해를 입었다. - **망명 중인 언론인에 대한 악성 트래픽** - 망명 상태에서 활동하는 언론인은 전체 언론 조직보다 거의 4배 높은 악성 트래픽에 노출됐다. - **피싱 이메일** - Cloudflare가 시민사회 조직을 대상으로 처리한 이메일 중 거의 10%에 잠재적인 피싱 콘텐츠가 포함됐다. - 공격은 탐사보도 발표나 공개 캠페인처럼 조직의 활동이 중요한 시점에 집중되는 경향을 보였다. ## 연례 위협 보고서와 사례 연구 - Cloudflare는 시민사회 대상 사이버공격을 다루는 종합 보고서를 처음 공개했다. - 앞으로 매년 보고서를 발간해 공격 유형과 강도의 변화를 장기적으로 비교할 계획이다. - 보고서는 시민사회 단체뿐 아니라 정책 입안자와 일반 대중이 사이버공격을 이해하고 대응하는 자료로 활용되도록 작성됐다. - 정량 데이터에 더해 16개 Project Galileo 참여 조직의 보안 요구를 다룬 사례 연구도 공개했다. - 사례 연구 대상에는 다음과 같은 조직이 포함된다. - 디지털 권리·표현의 자유 단체인 SHARE Foundation - 실종·유실 반려동물 플랫폼 Hledaczvirat - 핵무기와 비확산 문제를 연구하는 Iran Watch - 핵 위험·기후변화·기술을 다루는 Bulletin of Atomic Scientists - 전쟁범죄 증거를 보존하는 Ukraine War Archive - 빈곤·보건·기후 데이터를 제공하는 Our World in Data - 탐사보도 네트워크 OCCRP - 중국의 검열과 인권을 다루는 China Digital Times - 해양 생태계를 보호하는 Sea Shepherd Brazil 등 ## 보안 접근성을 높이기 위한 과제 - 모든 사람이 이용할 수 있는 단순하고 저렴한 사이버보안 도구가 필요하다고 강조했다. - 사이버공격과 인터넷 차단에 대한 투명성을 확대해야 한다고 제안했다. - AI 기반 위협과 포스트퀀텀 환경에 대비한 보호 기능을 보안 도구에 기본값으로 포함해야 한다고 밝혔다. - 시민사회 조직은 공익 활동의 특성상 공격 시점과 목적이 명확한 경우가 많으므로, 일반적인 보안 도구뿐 아니라 지속적인 모니터링과 대응 체계가 필요하다. ## 지역 파트너십 확대 - Project Galileo는 파트너 조직을 통해 각 지역의 시민사회 단체를 발굴하고 신청을 심사한다. - 기존 협력은 이메일 보안과 공공학교 인터넷 측정 같은 새로운 사업으로 확장됐다. - Protect.ngo와는 시민사회 조직을 위한 이메일 보안 사업을 진행했다. - UNICEF의 Giga 프로젝트와는 공립학교의 인터넷 연결 상태 측정을 지원했다. - 북미와 유럽 이외 지역의 조직을 더 많이 지원하기 위해 Costa Rica·Taiwan RightsCon 등 지역 행사에도 참여했다. - 아시아·태평양 지역에서는 EngageMedia와 OpenCulture Foundation을 새 파트너로 맞이했다. - 올해는 AI 크롤러로부터 지역 언론 콘텐츠를 보호하는 신규 서비스와 연계해 언론인 지원 조직에 초점을 맞췄다. - 새 파트너로 International Center for Journalists와 Media Cluster Norway 등이 소개됐다. 제공된 글은 세 번째 파트너 설명이 끝나기 전에 중단되어 있다. Project Galileo의 사례는 시민사회 조직의 보안이 단순한 기술 문제가 아니라 표현의 자유와 공공 참여를 유지하기 위한 기반임을 보여준다. 특히 언론·인권 단체는 공격이 집중되는 시점과 장기화되는 DDoS에 대비해 웹 방화벽, DDoS 방어, 이메일 피싱 대응, 취약점 관리 체계를 기본적으로 갖추는 것이 바람직하다.

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

AIpost-quantum-cryptographycybersecurityddos+3

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

Flue를 시작으로 Cloudflare에 더 많은 에이전트 하네스 도입하기

2026년에는 AI 에이전트가 프로토타입을 넘어 실제 운영 인프라로 사용되면서, 중단 복구·보안 실행·도구 연동 같은 분산 시스템 문제가 중요해지고 있다. 글은 이를 해결하기 위해 **프레임워크(Flue)–하네스(Pi, Project Think)–런타임(Cloudflare Agents SDK)**의 3계층 구조가 필요하다고 주장한다. Flue는 선언적으로 에이전트를 정의하고, Cloudflare Agents SDK는 내구성 있는 실행·상태·스토리지·샌드박스를 제공해 프로덕션 환경의 안정성을 높인다. ## 프로덕션 에이전트를 위한 3계층 구조 - **프레임워크: Flue** - 프로젝트 구조, 규칙, 외부 서비스 통합, CLI, 개발자 경험을 제공한다. - 에이전트를 실제 업무 환경에 배치하고 관리하는 상위 계층이다. - **하네스: Pi, Project Think** - 모델의 에이전트 루프를 담당한다. - 도구 호출, 결과 확인, 컨텍스트 관리, 작업 완료까지의 반복 과정을 처리한다. - **런타임/플랫폼: Cloudflare Agents SDK** - 에이전트가 의존하는 컴퓨트, 상태 관리, 스토리지 primitives를 제공한다. - 특정 하네스에 종속되지 않고 다양한 하네스와 프레임워크가 사용할 수 있는 기반 계층이다. ## Flue의 선언적 에이전트 모델 - Flue 1.0 Beta는 Pi 하네스를 기반으로 하며, OpenClaw와 같은 하네스를 사용한다. - 에이전트가 무엇을 할지 절차적으로 스크립팅하는 대신, 에이전트가 알아야 할 내용을 선언한다. - 사용할 모델 - 필요한 스킬 - 실행 샌드박스 - 시스템 지침 - 별도의 오케스트레이션 루프를 직접 작성하지 않아도 에이전트가 주어진 작업을 자율적으로 수행한다. - 예를 들어 버그 리포트를 받아 샌드박스에서 재현하고 원인을 진단하는 에이전트를 25줄 이하로 작성할 수 있다. ## 개발자 도구와 외부 서비스 통합 - **Channels** - Slack, GitHub, Linear, Discord 등에 에이전트를 연결한다. - 이벤트 검증과 디스패치에 필요한 반복적인 보일러플레이트를 대신 처리한다. - **헤드리스 실행과 UI 연동** - 백그라운드 작업에서는 완전히 헤드리스로 실행할 수 있다. - `@flue/react`를 사용하면 에이전트 상태, 도구 실행, 실시간 메시지를 프론트엔드로 스트리밍할 수 있다. - 별도의 실시간 통신 인프라를 직접 구축할 필요를 줄인다. - **CLI 기반 생태계 확장** - `flue add channel slack` 같은 명령으로 통합 기능을 추가한다. - 생성된 Markdown blueprint를 코딩 에이전트가 읽고 수정해 기존 코드베이스에 통합할 수 있다. ## Durable Streams를 통한 장애 복구 - 에이전트 실행은 모델 응답 스트리밍, 도구 호출, 도구 결과 대기, 사용자 승인, 하위 에이전트 위임 등 여러 단계로 구성된다. - 호스트 장애, LLM API 타임아웃, 프로세스 재시작이 발생하면 메모리에 있던 실행 상태가 사라질 수 있다. - Flue는 **Durable Streams**를 사용해 실행 이력을 append-only 로그로 기록한다. - 프롬프트 - 도구 응답 - 모델 선택 - 기타 실행 이벤트 - 각 이벤트를 변경할 수 없는 원장처럼 저장하므로 프로세스가 종료되어도 다른 프로세스가 마지막 로그부터 실행을 이어갈 수 있다. - 결과적으로 에이전트가 작업 중이던 정확한 단계에서 복구되고, 사용자가 영원히 끝나지 않는 로딩 상태를 보는 문제를 줄인다. ## 다양한 환경에 배포하는 방식 - Node.js에서는 에이전트를 장시간 실행되는 프로세스로 배포할 수 있다. - VM, 컨테이너, GitHub Actions, 기존 서버 등에 배포할 수 있어 멀티클라우드 구성이 가능하다. - Cloudflare 환경에서는 각 Flue 에이전트가 하나의 **Durable Object**로 실행된다. - 에이전트별 독립적인 컴퓨트와 스토리지를 제공한다. - 필요한 에이전트 수만큼 자동 확장할 수 있다. - 서버 프로비저닝, sticky session, noisy neighbor 문제를 신경 쓰지 않아도 된다. ## Cloudflare Agents SDK의 실행 primitives - Cloudflare에 배포된 Flue는 Agents SDK의 다음 기능을 사용해 내구성 있는 실행을 구현한다. - `runFiber()`: 에이전트 실행을 중단·복구 가능한 작업 단위로 관리 - `stash()`: 실행 중인 상태를 보존 - `onFiberRecovered()`: 복구된 실행을 다시 처리 - `@cloudflare/codemode`와 `@cloudflare/shell`을 활용해 샌드박스 안에서 코드를 실행한다. - 이 코드는 Durable Workspace와 결합되어 에이전트가 지속적으로 사용할 수 있는 작업 공간을 제공한다. ## 하네스가 플랫폼에 요구하는 것 - 에이전트 턴은 단순한 단일 HTTP 요청이 아니라 수초에서 수분간 이어지는 상태ful한 실행이다. - 실행 중 다음과 같은 단계가 발생할 수 있다. - 모델 토큰 스트리밍 - 도구 호출 - 도구 결과 대기 - 사람의 승인 요청 - 하위 에이전트 위임 - 프로세스가 중단되면 스트리밍 연결, 대기 중인 도구 호출, 현재 실행 위치 등 메모리 상태가 사라진다. - 대화 기록만 디스크에 저장되어 있어도 사용자는 완료되지 않는 스피너를 보게 되므로 충분하지 않다. - 따라서 현대적인 하네스에는 실행 중간 상태를 체크포인트로 저장하고 장애 후 이어서 실행할 수 있는 **durable execution**이 필수다. - 글은 Cloudflare Agents SDK의 Fiber가 이러한 체크포인트와 복구를 위한 네이티브 메커니즘을 제공한다고 설명하기 시작하며, 이후 세부 동작은 제공된 본문에서 이어지지 않는다. 에이전트를 실제 서비스로 운영하려면 모델 호출 로직만 구현해서는 부족하다. Flue 같은 프레임워크로 개발 경험과 통합을 단순화하고, Pi 같은 하네스로 에이전트 루프를 처리하며, Durable Objects와 Durable Streams 같은 플랫폼 primitives로 상태 보존·장애 복구·안전한 코드 실행을 확보하는 구성이 실용적이다.

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

durable-objectscloudflare-agents-sdkdurable-executionflue+3

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

Cloudflare One 스택 소개: 에이전트 기반 배포

Cloudflare는 Zero Trust 도입·마이그레이션·운영을 에이전트가 수행하도록 돕는 “Cloudflare One stack”을 공개했습니다. 이 스택은 Cloudflare One 제품 지식, 의사결정 트리, 마이그레이션 로직, API 도구를 제공해 기존 네트워크를 분석하고 안전한 배포 계획과 설정을 생성합니다. 특히 Zscaler·Palo Alto Networks 등 기존 SASE 솔루션에서 Cloudflare로 이전하는 작업을 자동화하고, 운영 중인 환경의 문제 해결까지 지원하는 것이 핵심입니다. ## 네트워크 보안에서의 에이전트 활용 격차 - 조직은 이미 에이전트를 코드 작성, 보안 알림 분류, 업무 자동화에 활용하고 있습니다. - 그러나 에이전트가 조직별 네트워크 토폴로지, 인증 정책, 트래픽 흐름, 기존 공급업체 설정을 자동으로 이해하기는 어렵습니다. - Cloudflare One stack은 이러한 부족한 맥락을 보완하기 위해 Cloudflare 제품에 대한 권위 있고 구체적인 지침을 제공합니다. - 이를 통해 에이전트가 일반적인 API 호출이 아니라 권장된 보안·배포 절차에 따라 작업하도록 합니다. ## Cloudflare One stack의 구성 - 어떤 에이전트와도 사용할 수 있는 스킬 모음으로 제공됩니다. - 두 개의 경량 스킬 파일로 구성됩니다. - `cloudflare-one`: Cloudflare One 구축, 관리, 운영, 문제 해결 - `cloudflare-one-migration`: 다른 SASE 제품에서 Cloudflare로의 마이그레이션 - Cloudflare One 고객 지원 과정에서 축적된 수만 시간의 실무 지식을 기반으로 제작되었습니다. - Cloudflare Code Mode MCP 서버와 함께 사용하면 Cloudflare API에 타입이 지정된 인터페이스로 접근할 수 있습니다. - 에이전트는 실시간 계정 정보를 조회하고, 현재 설정을 검사하며, 검증된 방식으로 변경을 수행할 수 있습니다. ## 지원하는 Cloudflare One 영역 - **Cloudflare Access** - 기존 VPN과 원격 접속 환경을 대체합니다. - 애플리케이션별 인증·인가 정책을 구성합니다. - **Cloudflare Gateway** - 사용자, 네트워크, 디바이스, 데이터를 보호합니다. - **Cloudflare Tunnel·Mesh·WAN** - 애플리케이션과 네트워크 간 연결 방식을 구성합니다. - **마이그레이션** - Zscaler, Palo Alto Networks 등 기존 SASE 공급업체의 개념과 설정을 Cloudflare 방식으로 변환합니다. - **네트워크 다이어그램** - 현재 또는 제안된 네트워크 구조를 시각화합니다. - **운영 및 문제 해결** - Digital Experience Monitoring(DEX)으로 사용자 경험과 지연 문제를 분석합니다. - 트래픽을 바탕으로 보안 규칙을 추천합니다. ## VPN 교체와 신규 배포 절차 에이전트는 기존 VPN 환경을 분석한 뒤 다음과 같은 순서로 Cloudflare 구성을 제안할 수 있습니다. - 기존 VPN 애플리케이션을 목록화하고 각 애플리케이션에 필요한 연결 모델을 식별합니다. - 애플리케이션을 적절한 Cloudflare 구성요소에 매핑합니다. - Self-hosted Access 애플리케이션 - Tunnel 연결 서비스 - Mesh 연결 네트워크 세그먼트 - 서비스 중단을 최소화하도록 단계별 전환 순서를 생성합니다. - 실제 변경 전에 팀이 검토할 수 있는 구성 요약을 제공합니다. ## 공급업체 간 마이그레이션 자동화 - Zscaler Private Access 애플리케이션 정의를 Cloudflare Access 애플리케이션 정의로 변환합니다. - 사용자 그룹과 보안 정책을 Cloudflare Access 정책으로 매핑합니다. - Cloudflare API를 사용해 변환된 리소스를 계정에 생성할 수 있습니다. - 마이그레이션된 항목과 수동 검토가 필요한 예외를 별도로 정리합니다. - 이 로직은 Cloudflare의 Descaler·Deskope 프로그램에 사용된 방식으로, 기업 고객의 이전 작업을 수개월에서 수시간으로 단축한 사례를 바탕으로 합니다. ## 운영 중인 환경의 보안·성능 개선 - 실시간 계정의 트래픽을 분석해 적절한 보안 규칙을 추천합니다. - 기존 Zscaler Private Access 애플리케이션을 Cloudflare의 self-hosted Access 애플리케이션으로 자동 이전할 수 있습니다. - Secure Web Gateway HTTP 로그에서 이상 현상을 조사하고 사용자 문제를 해결할 규칙을 만들 수 있습니다. - DEX 도구를 이용해 사용자 연결 안정성과 지연 시간을 분석하고 개선 조치를 제안합니다. ## 실용적인 결론 Cloudflare One stack은 Zero Trust 전문가의 경험을 에이전트가 활용할 수 있는 구조화된 지식과 도구로 패키징한 제품입니다. 다만 네트워크 정책 변경은 영향 범위가 크므로 에이전트가 생성한 계획과 구성 요약을 먼저 검토하고, 단계적 전환과 수동 승인을 병행하는 방식이 적절합니다.

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

모델 컨텍스트 프로토콜제로 트러스트sasecloudflare-access+4

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월 15일·3분 읽기큐레이션 요약

Ensemble AI 출신 인재들과 함께 Cloudflare AI 팀을 확장하기

Cloudflare는 Ensemble AI의 핵심 인력을 영입해 AI 인프라와 추론 효율성 분야를 강화한다. 목표는 대규모·멀티모달 모델을 더 작고 빠르며 저렴하게 실행해, 개발자가 전 세계에서 AI 애플리케이션을 안정적으로 배포하도록 돕는 것이다. 이를 위해 모델 구조 개선, 메모리·연산량 감소, GPU 활용률 향상에 집중한다. ### Ensemble AI의 모델 효율화 기술 - Ensemble AI는 2023년 설립 이후 대규모 모델의 메모리, 연산량, 배포 비용을 줄이는 기술을 개발해왔다. - 단순한 양자화나 하드웨어 최적화가 아니라, 신경망의 구조 자체를 더 작고 효율적으로 만드는 접근을 취한다. - **NdLinear**는 트랜스포머의 표준 선형 계층을 대체하는 기술이다. - 다차원 활성값을 평탄화하지 않고 직접 처리한다. - 어텐션 헤드, 채널, 공간 차원 등 데이터의 의미 있는 구조를 보존한다. - 이를 통해 파라미터 수와 계산량을 줄인다. - **NdLinear-LoRA**는 대규모 모델을 파인튜닝할 때 학습해야 하는 파라미터 수를 줄이는 방식이다. - 양자화, 벡터 양자화와 결합하면 모델의 메모리 사용량과 실행 비용을 더욱 낮출 수 있다. ### Cloudflare Workers AI의 추론 효율 개선 - Workers AI는 Cloudflare의 글로벌 네트워크에서 서버리스 GPU 기반 추론을 제공한다. - AI 애플리케이션이 확산될수록 모델 추론 비용은 확장성을 결정하는 핵심 요소가 된다. - 모델 크기, 메모리 사용량, 처리량, GPU 활용률을 개선하면 개발자의 비용 부담을 줄이고 더 많은 AI 서비스를 운영할 수 있다. - 대상 워크로드는 텍스트 생성뿐 아니라 다음 영역으로 확대되고 있다. - AI 에이전트 - 멀티모달 모델 - 개인화 - 파인튜닝 - 검색 결합 생성(RAG) - 강화학습 - Cloudflare는 기존의 추론 엔진 **Infire**, 텐서 압축 기술 **Unweight**, 대규모 언어 모델 실행 플랫폼을 기반으로 효율화 작업을 강화한다. ### 글로벌 AI 인프라와 모델 압축의 결합 - 개발자는 이제 모델에 접근하는 것만으로는 충분하지 않으며, 모델을 저렴하고 안정적으로 사용자 가까이에서 실행할 인프라가 필요하다. - Cloudflare의 글로벌 네트워크와 서버리스 플랫폼은 AI 실행 환경을 애플리케이션이 이미 배포된 위치에 가깝게 제공할 수 있는 기반이 된다. - Ensemble AI의 모델 압축·효율적 아키텍처 기술을 결합하면 다음 효과를 기대할 수 있다. - 낮은 추론 비용 - 빠른 응답 속도 - 향상된 GPU 활용률 - 대규모 배포의 운영 복잡성 감소 - 다양한 모델 크기와 파인튜닝 방식에 대한 실험 용이성 ### 향후 목표 - Cloudflare는 강력한 AI 모델을 전 세계 규모로 실행하면서도 추론 경제성을 개선하는 것을 목표로 한다. - 새 팀은 대규모 언어 모델과 고급 AI 아키텍처의 서빙 비용을 낮추고, 효율적인 모델 실행과 확장 가능한 배포 방식을 발전시킬 예정이다. - 궁극적으로 개발자가 비용과 운영 부담에 막히지 않고 AI 애플리케이션을 구축·배포할 수 있는 플랫폼을 제공하려는 전략이다. 실용적으로는 AI 서비스를 설계할 때 모델 성능만 비교하기보다 파라미터 수, 메모리 사용량, GPU 활용률, 추론 지연시간, 글로벌 배포 비용을 함께 평가해야 한다. Cloudflare의 방향은 이러한 운영 비용을 모델 구조와 인프라 양쪽에서 동시에 줄이려는 접근으로 볼 수 있다.

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

대규모 언어 모델머신러닝quantizationcloudflare-workers-ai+4

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

보안 인사이트 확장: 글로벌 스캔 처리 역량을 10배 향상한 방법

Security Insights는 기존 주 1~2회에 그치던 보안 검사를 모든 계정에 더 자주 적용하기 위해 처리량을 초당 10건에서 100건으로 약 10배 높여야 했다. Cloudflare는 Kafka 소비 병렬화, 느린 작업 분리, Postgres 대량 삽입 최적화, 지역 간 네트워크 지연 분석을 통해 스캔 처리량을 10배 이상 향상시켰다. 그 결과 수백만 고객에게 보안 인사이트를 제공하고 전체 고객의 검사 주기를 두 배로 늘릴 수 있었다. ## 기존 보안 검사 구조와 확장 과제 - 스케줄러가 검사 시점이 된 계정과 Zone을 감지한다. - 검사 작업을 Apache Kafka 메시지로 발행하고, 여러 Go 기반 checker 마이크로서비스가 메시지를 나누어 처리한다. - 각 checker는 특정 자산이나 설정을 검사한 뒤 내부 API로 결과를 전송한다. - API는 결과를 Postgres 데이터베이스에 저장한다. - 기존 시스템은 다음 문제를 겪고 있었다. - 검사가 주 1~2회만 수행되어 위험이 최대 2주간 탐지되지 않을 수 있었다. - 많은 무료 요금제 계정에서 자동 검사가 선택 사항이라 검사 자체가 이뤄지지 않았다. - Kafka backlog 증가, API 타임아웃, 프로세스 충돌이 발생했다. - 모든 계정에 자동 검사를 적용하고 검사 빈도를 높이려면 평균 처리량을 초당 10건에서 100건으로 늘려야 했다. ## Kafka 파티션의 병목 - Kafka는 일반적인 큐와 달리 파티션 내 메시지를 순서대로 소비하고 처리한다. - 하나의 consumer group에서는 파티션당 활성 consumer를 하나만 둘 수 있다. - 따라서: - 처리 시간이 긴 메시지 하나가 뒤따르는 메시지의 처리를 막을 수 있다. - checker별 병렬 소비자 수는 Kafka 파티션 수에 제한된다. - 파티션을 추가하면 확장할 수 있지만, 여러 서비스가 공유하는 Kafka 브로커의 자원 사용량이 증가하므로 최후의 수단으로 남겨두었다. ## 배치 기반 병렬 처리 - 메시지를 하나씩 처리하던 checker를 배치 단위로 소비하도록 변경했다. - 배치 안의 각 메시지는 별도의 Go goroutine에서 동시에 처리했다. - 이 방식의 trade-off는 다음과 같다. - 배치 처리 중 프로세스가 중단되면 이미 처리한 작업을 다시 수행해야 할 수 있다. - 동시에 처리하는 작업이 늘어 메모리 사용량이 증가한다. - 검사 시스템에서는 재처리 비용과 메모리 증가가 감당 가능한 수준이었기 때문에 병렬 처리를 선택했다. ## 느린 작업으로 인한 Head-of-Line Blocking 제거 - 일부 계정이나 Zone은 자산 수가 많아 검사에 수초가 아니라 수분 또는 수시간이 걸릴 수 있었다. - 이런 느린 메시지가 일반 메시지 앞에 있으면 Kafka 소비가 멈춰 빠른 작업까지 지연됐다. - 해결책으로 checker와 consumer group을 두 개의 처리 경로로 분리했다. - **Fast lane**: 빠르게 처리할 수 있는 일반 메시지 담당 - **Slow lane**: 처리 시간이 긴 메시지 전담 - 메시지의 예상 처리 시간을 빠르게 판단하고, fast lane이 느린 메시지를 만나면 건너뛰도록 했다. - 그 결과 느린 작업은 전용 자원을 사용하고, 빠른 작업은 지연 없이 계속 처리할 수 있었다. ## Postgres 대량 저장 최적화 - 기존 API는 인사이트 하나마다 별도의 `INSERT ... ON CONFLICT DO UPDATE` 쿼리를 실행했다. - 한 요청에 최대 50만 개의 인사이트가 포함될 수 있어, 최악의 경우 50만 번의 데이터베이스 왕복과 쿼리 실행이 발생했다. - 처음에는 임시 테이블에 `COPY`하는 Postgres 표준 대량 삽입 방식을 시도했지만, Postgres 시스템 테이블의 bloat가 증가하는 문제가 나타났다. - 최종적으로 입력 규모에 따른 하이브리드 방식을 채택했다. - 작은 데이터셋: `UNNEST`를 사용해 빠르게 삽입 - 큰 데이터셋: `COPY`를 사용해 대량 삽입 - 이 방식은 대규모 데이터에는 수초 수준의 처리 시간을, 소규모 데이터에는 밀리초 수준의 빠른 처리를 제공했다. ## 지역 간 지연으로 발생한 API 타임아웃 - 확장 과정에서 다음 현상이 관찰됐다. - 클라이언트 타임아웃 증가 - checker 처리 시간의 20~90%가 단일 API 호출에 소요 - 대량 검사 시 초기 처리량은 높지만 시간이 지나며 감소 - 원인은 API와 데이터베이스 간 네트워크 지연이었다. - 주 데이터베이스는 미국 오리건주 포틀랜드에 위치했다. - API는 포틀랜드와 네덜란드 암스테르담에서 active-active로 운영됐다. - 포틀랜드 API 호출은 평균 10ms였지만, 암스테르담 인스턴스에서는 거의 3초가 걸렸다. - 암스테르담 API가 데이터베이스 연결을 오래 점유하면서 checker의 클라이언트 연결 풀이 고갈됐다. - 연결을 기다리는 요청이 타임아웃되고, 암스테르담 API에 연결된 Kafka 파티션만 지속적으로 지연됐다. - 결국 API의 단순한 지역 분산이 전체 Kafka 소비 처리량의 불균형과 lag를 유발할 수 있음을 확인했다. ## 실용적인 결론 대규모 이벤트 처리 시스템에서는 소비자 수를 늘리는 것만으로 충분하지 않다. Kafka의 파티션 제약을 고려한 병렬 처리, 느린 작업의 별도 격리, 대량 데이터베이스 작업의 배치화, 데이터베이스와 API 간 지역 지연 관리까지 함께 최적화해야 안정적인 처리량 확장이 가능하다. 특히 분산 배포 환경에서는 평균 latency뿐 아니라 연결 풀 점유 시간과 파티션별 처리 편차까지 함께 측정해야 한다.

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

PostgreSQLApache Kafka분산 시스템API+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

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

Cloudflare의 위협 지표를 실시간 WAF 규칙으로 전환하기

Cloudflare는 Threat Events의 실시간 위협 인텔리전스를 WAF 규칙에서 직접 사용할 수 있도록 통합했다. 이제 보안팀은 위협 행위자, 공격 대상 산업·국가, 공격 유형과 같은 정보를 바탕으로 악성 IP를 사전에 차단할 수 있으며, 탐지와 차단을 분리해 가시성도 유지할 수 있다. 해당 기능은 WAF 사용자 정의 규칙과 Rate Limiting, API, Terraform, Security Analytics에 통합된다. ## 위협 인텔리전스를 WAF 차단으로 연결 - 기존에는 특정 IP가 Tycoon 2FA, RaccoonO365 같은 위협 행위자와 연관되었거나 특정 산업을 공격했다는 사실을 알아도, WAF에서 직접 차단하려면 수동으로 규칙을 작성해야 했다. - 새 기능은 요청 처리 초기 단계에서 위협 메타데이터를 필드로 채운다. - WAF는 다음 기준으로 트래픽을 평가할 수 있다. - 알려진 위협 행위자 이름 - 해당 IP가 과거 공격한 산업 - 공격 대상 국가 - 공격 발생 국가 - DDoS, WAF, 사이버 범죄 등 데이터셋 또는 공격 유형 - 초기 버전은 IP 기반 매칭에 초점을 두며, 향후 JA3 지문과 도메인 기반 매칭으로 확장될 예정이다. ## 항상 실행되는 탐지 구조 - 이 기능은 사전 규칙 없이도 공격 패턴을 탐지하는 Attack Signature Detection의 “always-on” 프레임워크를 사용한다. - 위협 인텔리전스 탐지는 백그라운드에서 지속 실행되며, 차단 여부를 결정하기 전부터 HTTP 요청에 위협 메타데이터를 추가한다. - 탐지와 완화(mitigation)를 분리해 기존의 “로그로 볼 것인가, 차단할 것인가”라는 선택 문제를 줄인다. - 차단하면 다른 탐지 시그니처가 해당 요청을 어떻게 판단했는지 확인하기 어렵다. - 항상 탐지하면 먼저 트래픽 패턴과 위협 행위자를 분석한 뒤 차단 규칙을 적용할 수 있다. - Cloudforce One 구독자는 Analytics에서 자사 사이트를 공격하는 위협 행위자와 해당 IP가 주로 공격한 산업을 확인할 수 있다. - 탐지 과정은 매우 낮은 지연 시간으로 실행되도록 설계되어 트래픽 처리 성능을 유지한다. ## WAF에 추가된 위협 인텔리전스 필드 - `cf.intel.ip.attacker_names` - 알려진 위협 그룹 이름 - 예: `CRAVENFLEA` - `cf.intel.ip.target_industries` - 해당 IP가 공격한 산업 - 예: `Cryptocurrency`, `Automotive` - `cf.intel.ip.attacker_countries` - 위협 이벤트의 발신 국가 - `cf.intel.ip.target_countries` - 공격 대상 국가 - `cf.intel.ip.datasets` - 데이터를 제공한 위협 피드 또는 공격 유형 - 예: `ddos`, `waf` ## 배열 필드와 WAF 표현식 - 하나의 IP가 여러 위협 행위자나 산업과 연관될 수 있으므로 관련 필드는 배열로 제공된다. - 배열 내부의 값은 `[*]` 와일드카드 및 `any()` 함수로 검사한다. - 프랑스에서 공격받은 이력이 있고 DDoS 데이터셋에 포함된 IP 차단: ```text any(cf.intel.ip.target_countries[*] == "FR") and any(cf.intel.ip.datasets[*] == "ddos") ``` - 금융 산업을 공격한 BLACKBASTA 관련 IP 차단: ```text any(cf.intel.ip.target_industries[*] == "Banking & Financial Services") and any(cf.intel.ip.attacker_names[*] == "BLACKBASTA") ``` - 특정 발신 국가의 고위험 IP를 광범위하게 차단: ```text any(cf.intel.ip.attacker_countries[*] == "IR") ``` ## API와 Terraform을 통한 자동화 - 새 `cf.intel` 필드는 WAF 사용자 정의 규칙과 Rate Limiting 규칙에서 사용할 수 있다. - 기존 WAF 표현식 문법으로 복합 조건을 작성할 수 있다. - Cloudflare API와 Terraform에서도 지원되므로 다음을 자동화할 수 있다. - 여러 도메인에 동일한 위협 차단 정책 배포 - 계정 전체에 정책 적용 - Infrastructure as Code 기반의 규칙 관리 - 위협 인텔리전스 조건 변경 및 배포 자동화 ## Security Analytics의 가시성 - 위협 인텔리전스 필드로 인해 발생한 모든 매칭은 Security Analytics에 기록된다. - 분석 화면에서 다음 정보를 확인할 수 있다. - 어떤 WAF 규칙이 실행되었는지 - 어떤 위협 지표가 일치했는지 - 해당 요청의 상세 트래픽 맥락 - 이 기록은 규칙 감사, 오탐 분석, 사고 후 검토를 빠르게 하는 데 활용된다. - 분석 결과에서 바로 사용자 정의 보안 규칙을 생성할 수도 있다. ## Threat Events 대시보드에서 원클릭 규칙 생성 - Threat Intelligence Dashboard에서 원하는 조건으로 Saved View를 만들 수 있다. - 예를 들어 “최근 7일 동안 금융 산업을 공격한 IP” 같은 필터를 저장할 수 있다. - IP 목록을 직접 복사하지 않고, Saved View의 조건을 한 번의 클릭으로 WAF 규칙으로 변환할 수 있다. - 조사 단계에서 확인한 위협 동향을 곧바로 운영 차단 정책으로 연결하는 workflow다. ## 글로벌 네트워크에 배포되는 인텔리전스 - Cloudflare는 수백만 개의 위협 지표를 고성능 형식으로 압축한다. - 압축된 데이터셋은 전 세계 Cloudflare 데이터센터로 배포된다. - 요청이 네트워크에 도착하면 Cloudflare WAF가 이 데이터를 이용해 지연 시간을 최소화하면서 위협 여부를 조회한다. - 글의 마지막 부분은 이러한 글로벌 배포와 고속 조회 구조가 대규모 위협 지표를 처리하는 방식으로 이어진다. 실무적으로는 먼저 Threat Events와 Security Analytics에서 위협 패턴을 관찰한 뒤, 신뢰도가 높은 조건을 Saved View나 Terraform 기반 WAF 규칙으로 전환하는 접근이 권장된다. 특히 산업·국가·공격 유형을 조합해 차단 범위를 좁히면 과도한 차단 위험을 줄일 수 있다.

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

Terraforminfrastructure-as-codethreat-intelligencesecurity-analytics+3

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

AI 비용이 감당할 수 없을 정도로 늘었습니다. 이제 Cloudflare가 해결할 수 있습니다.

AI 사용이 확산되면서 기업은 막대한 토큰 비용을 부담하지만, 공유 API 키만으로는 누가 어떤 모델을 얼마나 사용했는지 파악하기 어렵다. Cloudflare는 AI Gateway에 달러 기준 지출 한도, 요청별 비용 추적, 모델 자동 전환 기능을 추가해 AI 비용을 통제할 수 있도록 했다. 또한 Cloudflare Access와 기존 IdP를 연동하면 사용자·팀·에이전트별 예산과 모델 사용 정책을 적용할 수 있다. ### 공유 API 키가 만드는 비용 관리의 한계 - 여러 엔지니어가 하나의 API 키를 사용하면 사용자별·팀별 비용을 추적할 수 없다. - 월말 청구서만 보고는 비용 증가 원인이 다음 중 무엇인지 알기 어렵다. - 머신러닝 팀의 신규 파이프라인 - 인턴의 고가 모델 사용 - CI 작업의 무한 반복 - 예산과 라우팅 기준이 없으면 사용자는 대부분 가장 강력하고 비싼 모델을 선택하게 된다. - 단순한 코드 리뷰 요약이나 로그 파싱에는 최첨단 모델이 필요하지 않으므로, 작업에 맞는 모델 선택과 비용 가시성이 중요하다. ### AI Gateway의 기본 역할 - 애플리케이션과 OpenAI, Anthropic, Google 등 AI 제공업체 사이에 위치하는 중간 계층이다. - 여러 제공업체와 모델을 하나의 인터페이스와 청구 체계로 관리할 수 있다. - 모든 요청의 로그, 토큰 수, 비용을 통합해 확인할 수 있다. - 응답 캐싱으로 반복 요청 비용을 줄일 수 있다. - Rate limiting으로 요청량을 제한할 수 있다. - PII와 비밀정보가 모델에 전달되기 전에 차단하는 콘텐츠 가드레일을 제공한다. - 기존에는 전체 계정 사용량은 볼 수 있었지만, 사용자별 비용 귀속이나 예산 설정은 어려웠다. ### 달러 기준 지출 한도 - 토큰 수가 아니라 실제 비용인 달러를 기준으로 예산을 설정한다. - 요청마다 모델 가격을 바탕으로 비용을 계산하고, 누적 지출을 실시간으로 한도와 비교한다. - 다음 기준을 조합해 한도를 지정할 수 있다. - 모델 - 제공업체 - 사용자, 팀, 애플리케이션 등 관리자가 정의한 속성 - 예산 기간은 고정형 또는 이동형으로 설정할 수 있다. - 매월 1일, 매주 월요일, 매일 자정에 초기화 - 최근 24시간·7일·30일처럼 이동하는 기간 - 일간·주간·월간 예산을 지원한다. - 한도에 도달하면 기본적으로 추가 요청을 차단한다. - Dynamic Routes를 사용하면 고가 모델 대신 저렴한 대체 모델로 요청을 전환할 수 있다. - 지출 한도 기능은 모든 요금제의 AI Gateway 사용자를 대상으로 오픈 베타로 제공된다. ### Cloudflare의 실제 사용 방식 - Cloudflare는 직원들의 AI 요청을 AI Gateway로 통합하고, 월간 수백만 건의 요청과 수십억 토큰을 처리한다. - 직원이 Cloudflare Access로 인증하면 JWT에서 신원을 추출한다. - 추출한 사용자 정보를 AI Gateway 요청의 메타데이터로 추가한다. - 이를 통해 다음을 확인할 수 있다. - 사용자별 토큰 소비량 - 팀별 사용량 - 조직 전체의 비용 귀속 - 단순히 공유 API 키를 사용하는 방식보다 비용의 책임 소재와 사용 패턴을 명확히 파악할 수 있다. ### Access 기반 사용자·팀별 정책 - 현재 폐쇄 베타로 제공되는 기능이다. - AI Gateway의 사용자 정의 메타데이터 방식과 달리, Cloudflare Access를 사용하면 인증된 신원을 자동으로 검증할 수 있다. - 사용자별 월간 예산을 설정할 수 있다. - 일반 엔지니어: 월 500달러 - 고급 엔지니어: 월 2,000달러 - 예산을 초과하면 요청을 차단하거나 저렴한 모델로 자동 전환할 수 있다. - IdP 그룹에 따라 팀별 모델 접근 정책을 설정할 수 있다. - ML 팀: Claude Opus, GPT-4o - 디자인 팀: 이미지·비디오 생성 모델 - 인턴: Workers AI 기반 오픈소스 모델 - CI/CD 파이프라인과 자율 에이전트에는 Access 서비스 토큰으로 고유한 신원을 부여할 수 있다. - 코드 리뷰 봇과 문서 생성기를 별도로 추적하고, 특정 에이전트의 폭주만 독립적으로 제한할 수 있다. - 로그에는 이메일, IdP 그룹, 서비스 토큰 이름이 포함되며, 이를 분석 플랫폼으로 내보내 사용자·팀·에이전트별 비용 보고서를 만들 수 있다. ### 인증 및 구성 방식 - AI Gateway 엔드포인트에 Cloudflare Access 애플리케이션을 구성한다. - 기존 IdP 그룹을 바탕으로 Access 정책을 설정한다. - 개발자나 에이전트는 OAuth 기반의 일반적인 CLI 디바이스 코드 흐름으로 인증한다. - AI Gateway가 토큰을 검증하고 인증된 신원을 자동으로 추출한다. - 별도의 Worker 작성, JWT 직접 파싱, 신뢰할 수 없는 메타데이터 헤더에 의존할 필요가 없다. ### 실용적인 적용 방향 기업은 먼저 AI Gateway를 모든 모델 요청의 단일 경로로 구성하고, 사용자·팀·애플리케이션별 로그와 비용을 수집하는 것이 좋다. 이후 업무 유형에 맞는 모델 라우팅과 달러 기준 예산을 설정하고, 마지막으로 Cloudflare Access와 IdP를 연동해 인증된 사용자 및 에이전트별 정책을 적용하면 비용 통제와 업무 연속성을 함께 확보할 수 있다.

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

CI/CDoauthcloudflare-accessidentity-provider+4

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