웹 개발 데일리 브리핑 — 2026-10-16

기준 시점: 2026-10-16 06:00 KST
조사 범위: 2026-10-15 06:00 ~ 2026-10-16 06:00 KST
추천 글 범위: 기준 시점 당시 최근 7일

---

1️⃣ 프론트엔드

Astro 7.4 공개 — 빌드 시간 분석, 이미지 처리 분리, 병렬 정적 렌더링 지원

• 발표일: 2026-10-15 — 정확한 게시 시각 미확인
• 버전: Astro 7.4
• 안정화 단계: 정식 릴리스. 병렬 Prerendering과 커스텀 Redirect Page는 Experimental
• 원문: https://astro.build/blog/astro-740/

Astro가 빌드 성능 분석과 이미지 처리 구조를 개선한 7.4 버전을 공개했다.

Astro는 콘텐츠 중심 웹사이트에서 불필요한 클라이언트 JavaScript를 최소화하는 데 초점을 맞춘 웹 프레임워크다.

React나 Vue 컴포넌트를 일부 화면에 사용할 수 있지만, 기본적으로 가능한 많은 콘텐츠를 빌드 또는 서버 렌더링 단계에서 HTML로 생성한다.

이러한 구조에서는 일반적인 React SPA와 다른 성능 문제가 발생할 수 있다.

브라우저에 전달되는 JavaScript의 양이 적더라도 정적 페이지를 생성하는 시간이 길어질 수 있기 때문이다.

특히 수천 개의 문서와 이미지, Markdown 파일을 처리하는 웹사이트에서는 빌드 시간이 개발 및 배포 속도를 제한할 수 있다.

이번 릴리스는 이러한 문제를 분석하기 위한 기능을 추가했다.

astro build --timings: 빌드 과정의 병목 구간 분석

가장 큰 변경은 astro build --timings 옵션이다.

기존에는 빌드가 느려졌을 때 어떤 단계에서 시간이 소비되는지 확인하기 어려웠다.

예를 들어 빌드가 30초 걸린다고 해도 원인이 다음 중 무엇인지 구분해야 한다.

• Vite 플러그인의 코드 변환
• JavaScript 번들 생성
• Markdown 파싱
• 구문 강조 처리
• 이미지 최적화
• 정적 페이지 렌더링
• 외부 API 요청

--timings 옵션을 사용하면 Astro가 이러한 작업에 소비한 시간을 구분해 출력한다.

전체 빌드 시간뿐 아니라 가장 느린 페이지와 각 페이지의 렌더링 시간도 확인할 수 있다.

Astro는 공식 발표에서 블로그 스타터 프로젝트를 이용한 예제를 공개했다.

이 프로젝트에는 총 9개 페이지가 존재하며, 일부 블로그 페이지에서 댓글과 작성자 프로필을 외부 API로 가져오도록 구성했다.

최초 측정 결과는 다음과 같았다.

전체 빌드 시간 가운데 대부분이 페이지 생성에 소비됐다.

특히 댓글을 가져온 뒤 각 댓글 작성자의 프로필을 다시 조회하는 구조가 문제였다.

첫 번째 네트워크 요청이 완료돼야 두 번째 요청을 시작할 수 있어 불필요한 Request Waterfall이 발생한 것이다.

Astro는 댓글과 프로필 요청을 병렬로 처리하도록 변경했다.

그 결과 페이지 생성 시간이 2.10초에서 1.13초로 감소했다.

이는 약 46%의 감소다.

다만 해당 수치는 Astro가 구성한 예제 프로젝트의 자체 측정 결과다.

Astro 7.4로 업데이트하는 것만으로 모든 프로젝트의 빌드 시간이 같은 비율로 감소하는 것은 아니다.

실제 개선은 개발자가 측정 결과를 분석하고 병목 구간을 수정했기 때문에 발생했다.

이번 기능은 빌드 속도를 자동으로 높이는 기능보다 성능 저하의 원인을 파악하기 위한 관측 도구에 가깝다.

빌드와 런타임의 이미지 처리 서비스 분리

Astro는 이미지 최적화 과정도 변경했다.

기존에는 빌드 시점과 런타임에 동일한 이미지 처리 서비스를 사용하거나 Adapter가 상황에 맞게 선택하도록 해야 했다.

하지만 두 환경은 요구사항이 다르다.

정적 페이지를 생성하는 빌드 환경에서는 Node.js에서 Sharp와 같은 이미지 처리 라이브러리를 사용할 수 있다.

반면 Cloudflare Workers 같은 Edge Runtime에서는 동일한 라이브러리를 실행하기 어려울 수 있다.

또한 사용자가 요청할 때마다 이미지를 직접 변환하기보다 이미지 CDN에 처리를 맡기는 편이 적합할 수도 있다.

Astro 7.4에서는 image.service에 다음 두 설정을 구분해 지정할 수 있다.

• build: 정적 페이지 생성 및 개발 과정에서 사용할 이미지 처리 서비스
• runtime: 운영 환경의 동적 페이지와 이미지 엔드포인트에서 사용할 서비스

예를 들어 정적 페이지에서는 Sharp로 이미지를 최적화하고, 동적으로 생성되는 페이지에서는 이미지 CDN을 사용할 수 있다.

기존처럼 하나의 이미지 서비스만 지정하는 방식도 계속 지원된다.

이번 변경은 이미지 서비스 설정의 표현 방식만 바꾼 것이 아니다.

Astro 내부에서 이미지가 사용되는 위치를 추적하는 구조도 변경됐다.

정적 페이지 생성 과정에서 어떤 이미지가 필요한지 메타데이터를 통해 전달하도록 개선했다.

이를 통해 @astrojs/cloudflare도 다른 Adapter와 동일한 Astro 이미지 처리 파이프라인을 사용할 수 있게 됐다.

다만 커스텀 Prerenderer를 직접 구현한 프로젝트에서는 주의가 필요하다.

새로운 이미지 생성 메타데이터를 전달하지 않는 커스텀 Prerenderer는 기존 방식으로 계속 실행될 수 있지만, 해당 페이지의 이미지가 정상적으로 생성되지 않을 수 있다.

Astro는 관련 통합 패키지인 @astrojs/cloudflare와 @astrojs/markdoc도 함께 업데이트할 것을 안내한다.

커스텀 서버 진입점에 notFound() 추가

Astro는 astro/fetch와 astro/hono를 이용해 서버 진입점을 직접 구성할 수 있는 기능을 제공한다.

예를 들어 Hono를 이용해 미들웨어를 구성하고 Astro 페이지를 연결하는 방식이다.

하지만 기존에는 직접 구성한 Handler에서 요청에 해당하는 페이지가 없으면 비어 있는 HTTP 404 응답이 반환될 수 있었다.

프로젝트에 404.astro 페이지가 존재하더라도 해당 페이지가 렌더링되지 않는 문제가 있었다.

이번 버전에서는 notFound() Handler가 추가됐다.

개발자는 직접 구성한 서버 파이프라인에서 이 Handler를 이용해 커스텀 404 페이지를 반환할 수 있다.

다만 Astro의 통합 astro() Handler를 사용하고 있다면 해당 동작이 이미 포함돼 있다.

따라서 모든 Astro 프로젝트에 notFound()를 추가해야 하는 것은 아니다.

Font Provider의 지원 범위 검증

Font 설정에 대한 검증 기능도 추가됐다.

기존에는 Font Provider가 실제로 지원하지 않는 Weight나 Style을 요청해도 해당 설정이 올바른지 즉시 확인하기 어려웠다.

예를 들어 Regular와 Bold만 제공하는 Font에 500 Weight를 요청하면 예상과 다른 글꼴이 표시될 수 있다.

Astro 7.4에서는 Font Provider가 다음 정보를 반환할 수 있다.

• 지원하는 Font Weight
• 지원하는 Font Style
• 지원하는 문자 Subset
• 지원하는 Font Format

이를 위한 API는 getFontProperties()다.

Astro는 설정이 실제 Font Provider의 지원 범위를 벗어나면 경고를 표시한다.

내장 Font Provider는 이미 해당 기능을 지원한다.

커스텀 Font Provider에서는 현재 선택 사항이지만 Astro 8부터 필수 API가 될 예정이다.

따라서 자체 Font Provider를 구현한 프로젝트에서는 향후 호환성을 고려해야 한다.

Experimental: Worker Thread를 이용한 병렬 Prerendering

이번 릴리스에는 experimental.parallelPrerender 옵션도 추가됐다.

기존 Astro는 정적 페이지를 동시에 생성할 수 있었지만 실제 페이지 렌더링은 하나의 스레드에서 이루어졌다.

따라서 CPU 연산이 많은 페이지를 대량으로 생성하는 프로젝트에서는 CPU 코어를 충분히 활용하지 못할 수 있었다.

새로운 기능은 Node.js의 Worker Thread를 이용해 정적 페이지 렌더링을 여러 스레드에 분산한다.

기본적으로 사용할 수 있는 CPU 코어에서 하나를 제외한 수만큼 Worker를 실행한다.

예를 들어 CPU 코어가 8개라면 기본 설정에서 최대 7개의 Worker를 사용할 수 있다.

개발자는 Worker 수를 직접 지정할 수도 있다.

하지만 병렬 실행이 항상 더 빠른 것은 아니다.

각 Worker는 추가 메모리를 사용한다.

따라서 메모리가 제한된 CI 환경에서는 Worker 수를 늘렸을 때 오히려 빌드가 실패하거나 성능이 나빠질 수 있다.

또한 병렬 처리에 적합하지 않은 작업이 대부분이라면 추가적인 실행 비용만 발생할 수 있다.

현재 이 기능은 Experimental 단계다.

그리고 @astrojs/cloudflare처럼 자체 Prerendering 방식을 제공하는 Adapter에서는 옵션이 적용되지 않는다.

Astro는 이러한 경우 빌드 과정에서 경고를 표시한다.

Experimental: 정적 Redirect 페이지 커스터마이징

정적 웹사이트에서는 서버가 HTTP Redirect 응답을 직접 보내지 못할 수 있다.

Astro는 이러한 환경에서 HTML의 Meta Refresh를 이용해 Redirect 페이지를 생성한다.

기존에는 해당 페이지의 문구나 디자인을 변경하기 어려웠다.

이번 버전에서는 experimental.redirectPage 옵션을 추가했다.

개발자는 src/pages/3xx.astro 파일을 생성해 정적 Redirect 페이지를 직접 정의할 수 있다.

해당 페이지에는 출발 주소, 목적지 주소, 상태 코드, 지연 시간 등의 정보가 전달된다.

다만 정적 Redirect를 실제로 실행하려면 Meta Refresh 태그가 필요하다.

Astro는 해당 태그가 누락된 경우 경고를 표시한다.

동적으로 처리되는 페이지의 Redirect 동작은 기존과 동일하다.

최소 Node.js 버전 변경

Astro와 공식 통합 패키지의 최소 Node.js 버전은 22.22.0으로 변경됐다.

이보다 오래된 Node.js 22 버전을 사용한다면 Astro를 업데이트하기 전에 Node.js부터 업데이트해야 한다.

이번 릴리스는 단순한 기능 추가보다 빌드 성능의 가시성, 실행 환경별 이미지 처리, 서버 Handler 구성, 정적 페이지 생성 구조를 함께 개선한 업데이트다.

---

Void 공개 — Vite 기반 프론트엔드에서 데이터베이스·API·배포까지 연결하는 오픈소스 풀스택 개발 도구

• 발표일: 2026-10-15 — 정확한 게시 시각 미확인
• 발표 주체: VoidZero, Cloudflare
• 공개 범위: Void Platform, Void SDK, Void CLI
• 원문: https://blog.cloudflare.com/deploy-with-void/
• 공식 사이트: https://void.cloud/

VoidZero와 Cloudflare가 Vite 프로젝트를 풀스택 애플리케이션으로 확장하고 배포까지 연결하는 오픈소스 도구인 Void를 공개했다.

VoidZero는 Vite, Rolldown, Vitest, Oxc 등 JavaScript 개발 도구 생태계와 밀접하게 연결된 기업이다.

VoidZero는 이러한 도구를 Vite+라는 개발 도구 체계로 통합해 왔다.

하지만 프론트엔드 개발 도구가 빠르고 편리해졌더라도 실제 서비스를 만들려면 여전히 여러 요소가 필요하다.

대표적으로 다음과 같은 기능이 있다.

• 서버 API
• 데이터베이스
• 사용자 인증
• 데이터베이스 마이그레이션
• 실행 환경 설정
• 클라우드 리소스 구성
• 배포와 로그 관리

Vite는 빠른 개발 서버와 빌드 도구를 제공하지만 이러한 풀스택 기능을 모두 직접 제공하는 프레임워크는 아니다.

Void는 이 문제를 해결하기 위해 Vite 기반 애플리케이션에 서버 기능과 인프라 구성을 추가하는 방식을 선택했다.

이번에 공개된 Void는 크게 세 부분으로 구성된다.

세 구성요소는 오픈소스로 공개됐다.

Void SDK: Vite 프로젝트에 서버 기능 추가

Void SDK는 Vite Plugin 형태로 프로젝트에 연결할 수 있다.

공식 예제에서는 Vite 설정에 voidPlugin()과 React용 voidReact()를 등록한다.

Void는 React와 Vue를 위한 Adapter를 제공한다.

또한 다음 기능을 지원한다.

• 파일 기반 API Routing
• 정적 페이지 생성
• 캐싱
• Islands 구조
• 데이터베이스에서 UI까지 연결되는 타입 추론
• Cloudflare Workers 기반 서버 실행

여기서 중요한 설계 선택은 기존 Vite 프로젝트를 반드시 완전히 새로운 프레임워크 구조로 변경하지 않아도 된다는 것이다.

Void의 기능은 선택적으로 조합할 수 있도록 설계됐다.

예를 들어 React Router를 사용해 페이지 라우팅을 처리하면서 Void의 데이터베이스 및 서버 API 기능을 사용할 수 있다.

또는 Astro나 SvelteKit이 렌더링을 담당하도록 두고 Void가 인프라 리소스를 관리하도록 구성할 수 있다.

공식 발표에서는 다음 프레임워크와의 통합을 언급했다.

• Vinext
• React Router
• SvelteKit
• Nuxt
• TanStack Start
• Astro

다만 이러한 통합을 지원한다는 사실이 모든 프레임워크의 기능과 실행 환경을 완전히 동일하게 지원한다는 의미는 아니다.

각 프레임워크가 제공하는 렌더링 방식과 실행 환경의 제약은 별도로 존재할 수 있다.

데이터베이스에서 UI까지 타입 연결

Void는 서버에서 조회한 데이터의 타입을 클라이언트까지 전달하는 방식을 제공한다.

예를 들어 서버 Handler에서 데이터베이스의 게시글 목록을 조회한다고 가정해 보자.

기존에는 서버 응답의 타입을 프론트엔드에서 별도로 정의하거나 API 스키마를 통해 동기화해야 하는 경우가 있었다.

이 과정에서 서버와 클라이언트의 타입 정의가 달라지면 런타임 오류가 발생할 수 있다.

Void는 Handler의 반환 타입을 추론하는 방식으로 이러한 중복 정의를 줄이려 한다.

공식 예제에서는 서버 Handler를 defineHandler()로 정의하고 InferProps를 이용해 반환 데이터의 타입을 가져온다.

따라서 데이터베이스 조회 결과와 UI에서 사용하는 타입을 하나의 흐름으로 연결할 수 있다.

다만 TypeScript 타입이 연결된다는 사실이 외부 입력의 런타임 검증까지 자동으로 보장한다는 뜻은 아니다.

사용자가 전달하는 요청 본문이나 외부 API 응답은 실제 런타임에서도 검증해야 한다.

Cloudflare 리소스 자동 구성

Void의 특징 가운데 하나는 코드에서 사용하는 리소스를 바탕으로 배포에 필요한 Cloudflare 구성을 자동화한다는 점이다.

예를 들어 애플리케이션이 void/db를 사용한다면 개발 환경에서는 로컬 데이터베이스를 사용할 수 있다.

이후 void deploy를 실행하면 운영 환경에 필요한 Cloudflare D1 리소스를 자동으로 구성할 수 있다.

AI 기능에서는 void/ai를 통해 Cloudflare AI Gateway와 연결하는 방식도 제공한다.

Void는 데이터베이스뿐 아니라 Queue, AI 관련 Binding 등의 구성도 자동화하도록 설계됐다.

따라서 개발자는 서비스 로직을 작성하면서 인프라 리소스의 생성 과정 일부를 도구에 맡길 수 있다.

그러나 이러한 자동화가 인프라 설계 자체를 불필요하게 만드는 것은 아니다.

데이터베이스의 접근 권한, 저장 용량, 사용량 제한, 서비스 간 데이터 이동과 비용 구조는 여전히 고려해야 한다.

특히 자동 생성된 리소스가 어떤 권한과 설정으로 운영되는지 확인하는 과정이 중요하다.

Void Platform: 조직 내부의 공유 배포 환경

Void Platform은 여러 사용자가 동일한 Cloudflare 계정 안에서 애플리케이션을 배포하도록 지원한다.

예를 들어 회사 내부에서 여러 팀이 작은 관리 도구와 프로토타입을 만들고 있다고 가정해 보자.

각 팀에 Cloudflare 계정 전체의 접근 권한을 부여하면 보안과 운영 관리가 복잡해질 수 있다.

반대로 중앙 개발팀이 모든 애플리케이션의 배포를 직접 처리하면 개발 속도가 느려질 수 있다.

Void Platform은 이 사이에서 공유 배포 환경과 관리자 정책을 제공한다.

관리자는 사용자의 접근 권한과 리소스 제한을 설정할 수 있다.

또한 배포 기록과 사용량을 확인하고, 필요한 경우 배포를 되돌릴 수 있다.

Void Platform을 자체적으로 운영하려면 다음 구성요소가 필요하다.

• Workers for Platforms와 R2가 활성화된 Cloudflare 계정
• PostgreSQL 데이터베이스
• 로그인 제공업체 계정
• 애플리케이션에 사용할 도메인

따라서 Void Platform이 완전히 별도의 인프라 없이 실행되는 것은 아니다.

플랫폼의 실행 기반은 Cloudflare Workers for Platforms다.

Void CLI: 빌드부터 배포까지

Void CLI는 프로젝트의 빌드, 데이터베이스 마이그레이션, 리소스 생성과 배포를 관리한다.

대표적인 명령은 void deploy다.

이 명령을 실행하면 Vite를 이용해 애플리케이션을 빌드하고 필요한 리소스를 구성한 뒤 Cloudflare 또는 Void Platform에 배포한다.

CLI에서는 배포 상태와 로그, 사용량을 확인할 수도 있다.

공식 발표에서는 AI 코딩 에이전트가 이러한 CLI를 사용해 애플리케이션의 배포와 오류 분석을 수행하는 방식도 소개했다.

다만 AI 에이전트가 배포 명령을 실행할 수 있다는 사실과 해당 배포가 안전하다는 사실은 다르다.

운영 환경의 접근 권한과 배포 승인 절차는 별도로 정의해야 한다.

VoidZero는 Void SDK와 CLI, Platform을 자사 운영 환경에서 수개월 동안 사용해 왔다고 설명한다.

그러나 이번 발표에는 다른 프레임워크와 비교한 독립적인 성능 측정이나 대규모 외부 운영 사례가 제공되지 않았다.

따라서 Void를 기존 풀스택 프레임워크보다 항상 빠르거나 안정적인 도구라고 단정할 수는 없다.

이번 발표는 Vite 생태계가 빌드 도구를 넘어 서버 기능, 타입 시스템, 클라우드 리소스 관리와 배포까지 연결되는 방향으로 확장되는 사례다.

---

2️⃣ 웹 플랫폼·브라우저

Cloudflare Stream, WebRTC 기반 초저지연 라이브 스트리밍 정식 출시 — 브라우저에서 직접 방송 송출·재생 지원

• 발표일: 2026-10-15 — 정확한 게시 시각 미확인
• 안정화 단계: Generally Available
• 적용 대상: Cloudflare Stream
• 원문: https://developers.cloudflare.com/changelog/post/2026-10-15-stream-live-webrtc-ga/

Cloudflare가 Stream의 WebRTC 기반 라이브 스트리밍 기능을 정식 출시했다.

WebRTC(Web Real-Time Communication)는 브라우저와 애플리케이션에서 실시간 오디오·비디오 및 데이터 통신을 구현하기 위한 기술이다.

화상회의나 실시간 음성 통화에 널리 사용되지만, 대규모 시청자에게 방송을 전달하는 서비스에서는 별도의 스트리밍 인프라가 필요한 경우가 많다.

일반적인 실시간 방송에서는 영상을 송출하는 사람과 영상을 시청하는 사람이 서로 다른 요구사항을 가진다.

송출자는 카메라와 마이크에서 생성한 데이터를 빠르게 서버에 전달해야 한다.

반면 스트리밍 플랫폼은 하나의 방송을 수백 명에서 수천 명의 시청자에게 안정적으로 전달해야 한다.

Cloudflare Stream은 이러한 기능을 관리형 서비스로 제공한다.

이번 업데이트에서는 WebRTC 기반 라이브 방송 기능이 Beta를 종료하고 정식 출시됐다.

WHIP과 WHEP 기반의 송출·재생

이번 기능에는 두 가지 표준 프로토콜이 사용된다.

WHIP(WebRTC-HTTP Ingestion Protocol)은 방송 송출에 사용된다.

브라우저나 방송 소프트웨어가 WebRTC 연결을 이용해 미디어를 서버로 전달하도록 한다.

WHEP(WebRTC-HTTP Egress Protocol)은 방송 재생에 사용된다.

시청자의 애플리케이션이 WebRTC를 이용해 방송을 수신하는 방식이다.

두 프로토콜을 이용하면 개발자는 브라우저의 WebRTC API와 Cloudflare Stream을 연결해 방송 기능을 구현할 수 있다.

예를 들어 브라우저에서 카메라와 마이크 권한을 얻고, WebRTC 연결을 생성한 뒤 WHIP 엔드포인트로 데이터를 전달할 수 있다.

시청자는 WHEP 엔드포인트를 통해 방송을 수신한다.

Cloudflare는 별도의 방송 소프트웨어 없이 브라우저의 기본 JavaScript API만 사용하는 송출 예제도 제공한다.

이는 브라우저에서 직접 방송을 시작하는 웹 애플리케이션을 구현할 수 있다는 의미다.

Trickle ICE와 연결 협상 개선

Cloudflare는 Beta 기간 동안 WebRTC 구현을 다시 구성했다.

새로운 구현은 Cloudflare Realtime의 기반 구성요소를 사용한다.

또한 최신 WHIP 및 WHEP 프로토콜의 연결 협상 기능을 지원하도록 변경했다.

대표적인 기능은 다음과 같다.

• Trickle ICE
• Server Offer
• Client Offer
• Counter Offer

ICE(Interactive Connectivity Establishment)는 서로 다른 네트워크 환경에 있는 두 통신 주체가 연결 가능한 경로를 찾도록 하는 기술이다.

WebRTC 연결에서는 NAT와 방화벽 때문에 단순히 상대방의 IP 주소만으로 통신할 수 없는 경우가 있다.

Trickle ICE는 연결 후보가 모두 수집될 때까지 기다리지 않고, 발견되는 후보를 순차적으로 교환할 수 있도록 한다.

이러한 방식은 연결 설정 과정의 지연을 줄이는 데 도움이 될 수 있다.

Offer와 Answer는 WebRTC 연결에서 사용할 미디어 형식과 연결 조건 등을 협상하는 과정이다.

이번 업데이트는 서로 다른 WebRTC 라이브러리나 클라이언트가 사용하는 협상 방식에 대한 호환성을 확대했다.

다수 시청자에게 방송 전달

Cloudflare는 새로운 WebRTC 기반 Stream이 수천 명의 동시 시청자를 지원하도록 설계됐다고 설명한다.

또한 초저지연 방송 전달을 강조한다.

다만 공식 발표에서 설명하는 밀리초 단위의 전달 능력이 모든 시청자 환경에서 특정 지연 시간을 보장한다는 의미는 아니다.

실제 지연 시간은 송출자의 네트워크, 시청자의 연결 상태, 미디어 인코딩, 브라우저와 재생 라이브러리 등에 영향을 받는다.

Cloudflare가 발표한 성능은 제공업체의 설명이며, 독립적인 비교 Benchmark가 함께 공개된 것은 아니다.

사용량 기반 과금 시작

WebRTC 기능은 2026년 10월 15일부터 사용량 기반 과금이 적용된다.

과금은 기존 Stream의 비디오 전달 시간에 대한 요금 체계를 따른다.

따라서 WebRTC가 브라우저의 기본 API라는 사실과 Cloudflare Stream 서비스 이용이 무료라는 사실을 혼동해서는 안 된다.

WebRTC 자체는 웹 기술이지만, Cloudflare의 방송 송출·전달 인프라는 관리형 서비스다.

이번 발표는 새로운 브라우저 표준을 도입한 것이 아니다.

이미 존재하는 WebRTC 및 WHIP·WHEP 기술을 Cloudflare Stream의 정식 방송 서비스에 통합한 업데이트다.

---

3️⃣ 백엔드·인프라

Vercel Daemons 공개 Beta — HTTP 서버 없이 장시간 실행되는 백그라운드 Worker 지원

• 발표일: 2026-10-15 — 정확한 게시 시각 미확인
• 안정화 단계: Public Beta
• 적용 대상: Vercel Daemons, Fluid Compute
• 원문: https://vercel.com/changelog/vercel-daemons-is-now-in-public-beta

Vercel이 HTTP 요청을 기다리는 서버 없이 지속적으로 실행되는 백그라운드 프로세스를 운영할 수 있는 Daemons 기능을 공개했다.

일반적인 서버리스 함수는 HTTP 요청이나 이벤트가 발생했을 때 실행된다.

요청 처리를 완료하면 실행이 종료되거나 일정 시간 이후 실행 환경이 회수될 수 있다.

이러한 구조는 웹 API나 짧은 비동기 작업에 적합하다.

하지만 모든 백엔드 작업이 요청 단위로 실행되는 것은 아니다.

예를 들어 다음과 같은 프로그램을 생각할 수 있다.

• 메시지 큐에서 작업을 계속 가져오는 Consumer
• Redis 기반 작업 큐를 처리하는 Worker
• 백그라운드 데이터 처리 서비스
• 장시간 실행되는 워크플로 엔진
• 외부 CI 시스템에서 작업을 가져오는 Runner

이러한 프로그램은 사용자가 HTTP 요청을 보낼 때만 실행되는 구조와 다르다.

프로세스가 지속적으로 실행되면서 새로운 작업이 들어오는지 확인해야 한다.

이번 Vercel Daemons는 이런 형태의 프로그램을 실행하기 위한 기능이다.

HTTP Listener 없이 실행

Daemons는 HTTP 서버를 실행할 필요가 없다.

일반적인 Vercel Function은 요청과 응답을 중심으로 실행된다.

반면 Daemon은 외부 작업 시스템에서 직접 작업을 가져오는 Pull 기반 구조를 사용할 수 있다.

공식 발표에서 제시한 지원 사례는 다음과 같다.

• Vercel Queues의 Poll Mode Consumer
• Celery
• BullMQ
• RabbitMQ
• Kafka
• Temporal
• Cadence
• GitHub Actions·GitLab·CircleCI의 자체 호스팅 Runner

예를 들어 BullMQ Worker는 Redis Queue에 새로운 작업이 들어오는지 확인하고 처리한다.

이 작업을 실행하기 위해 외부에서 HTTP 요청을 전달할 필요는 없다.

Daemon은 계속 실행되면서 큐의 작업을 가져오고 처리할 수 있다.

Container 기반 배포

Daemons는 Vercel의 Fluid Compute에서 Container 형태로 실행된다.

개발자는 Dockerfile 또는 Containerfile을 이용해 실행 환경을 정의한다.

이후 프로젝트 설정 파일에 Daemon을 등록한다.

설정에서는 다음 정보를 지정할 수 있다.

• Container를 빌드할 디렉터리
• Dockerfile 경로
• 실행 명령
• 리전별 Replica 수

예를 들어 Celery Worker를 미국 동부 리전인 iad1에서 하나 실행하도록 구성할 수 있다.

Vercel은 지정된 리전에서 설정된 인스턴스 수를 유지한다.

프로세스가 종료되거나 충돌하면 새로운 인스턴스를 시작한다.

이는 개발자가 서버 운영체제에 직접 로그인해 Process Manager를 관리하는 방식과 다르다.

애플리케이션의 배포 설정에 백그라운드 프로세스의 실행 정책을 함께 선언하는 구조다.

일반적인 서버리스 함수와의 차이

Daemon을 사용한다고 해서 작업이 항상 중단 없이 실행된다는 의미는 아니다.

실행 프로세스는 충돌하거나 재시작될 수 있다.

따라서 Queue Consumer에서는 작업의 중복 실행과 재처리를 고려해야 한다.

예를 들어 작업을 가져온 뒤 데이터베이스를 변경했지만 완료 확인을 기록하기 전에 프로세스가 종료되면 동일한 작업이 다시 전달될 수 있다.

이 경우 멱등성(Idempotency)을 고려하지 않은 구현에서는 중복 데이터가 생성될 가능성이 있다.

운영과 모니터링

Daemon은 애플리케이션과 동일한 Vercel 프로젝트에 배포된다.

프로젝트의 Production 환경 변수를 사용할 수 있고, 실행 로그도 프로젝트의 Logs에서 확인할 수 있다.

CPU 및 메모리 측정은 Observability Plus를 통해 제공된다.

이번 기능은 Public Beta다.

따라서 일반적인 Vercel Function과 동일한 안정화 수준이라고 가정해서는 안 된다.

공식 발표는 여러 Worker 프레임워크를 실행할 수 있는 구조를 소개하지만 각 프레임워크의 모든 운영 특성을 Vercel이 자동으로 관리한다는 의미는 아니다.

Queue의 재시도 정책, 메시지 처리 보장, 작업 중단과 복구는 사용하는 시스템에 따라 별도로 설계해야 한다.

이번 발표는 Vercel의 실행 모델을 HTTP 요청 중심의 서버리스 함수에서 지속적으로 실행되는 백그라운드 프로세스까지 확장한 변화다.

---

Vercel Drives 정식 출시 — Sandbox 종료 이후에도 파일을 유지하고 독립적인 작업 공간으로 분기

• 발표일: 2026-10-15 — 정확한 게시 시각 미확인
• 안정화 단계: Generally Available
• 적용 대상: Vercel Sandbox
• 지원 요금제: Hobby, Pro, Enterprise
• 원문: https://vercel.com/changelog/vercel-drives-is-now-generally-available

Vercel이 Sandbox에서 사용하는 영속적인 파일 저장소인 Drives를 정식 출시했다.

Sandbox는 애플리케이션 코드나 AI 에이전트가 생성한 코드를 격리된 실행 환경에서 실행하는 데 사용할 수 있다.

예를 들어 AI 코딩 에이전트가 프로젝트 파일을 생성한 뒤 테스트를 실행하거나 빌드 결과물을 만들어야 하는 상황을 생각할 수 있다.

이러한 실행 환경은 필요할 때 생성하고 작업이 종료되면 제거하는 방식으로 운영할 수 있다.

하지만 실행 환경을 제거하면 내부 파일도 함께 사라질 수 있다.

문제는 어떤 파일은 실행 환경이 종료된 이후에도 유지돼야 한다는 것이다.

예를 들어 다음과 같은 데이터가 있다.

• AI 에이전트가 수정한 프로젝트 파일
• 모델이나 데이터셋
• 다운로드한 의존성
• 테스트 결과
• 빌드 아티팩트
• 다음 작업에 필요한 파일 기반 상태

Vercel Drives는 이러한 파일을 Sandbox의 수명주기와 분리해 보관하도록 한다.

Sandbox와 Drive의 수명주기 분리

Drive는 Sandbox에 디렉터리 형태로 연결된다.

애플리케이션은 연결된 디렉터리를 일반적인 파일시스템처럼 사용할 수 있다.

대표적인 마운트 경로는 /data다.

Sandbox가 종료되더라도 Drive에 저장된 파일은 유지된다.

이후 새로운 Sandbox를 생성하고 동일한 Drive를 연결하면 기존 파일에 다시 접근할 수 있다.

즉 실행 환경의 수명주기와 파일 저장소의 수명주기를 분리한 것이다.

이러한 구조는 여러 단계에 걸쳐 작업을 수행하는 AI 에이전트에서 활용할 수 있다.

예를 들어 첫 번째 실행에서 프로젝트 코드를 생성하고, 두 번째 실행에서 테스트를 수행하고, 세 번째 실행에서 결과물을 패키징할 수 있다.

각 단계가 서로 다른 Sandbox에서 실행되더라도 같은 Drive를 사용하면 필요한 파일을 전달할 수 있다.

Drive Fork 지원

이번 기능에는 Drive Fork도 포함됐다.

Fork는 기존 Drive의 데이터를 기반으로 새로운 Drive를 생성하는 기능이다.

새로운 Drive는 원본 데이터와 초기 상태를 공유하지만 이후 변경 사항은 독립적으로 관리된다.

예를 들어 AI 에이전트 세 개가 동일한 프로젝트를 서로 다른 방식으로 수정한다고 가정해 보자.

각 에이전트가 같은 작업 디렉터리를 직접 수정하면 파일 변경이 충돌할 수 있다.

반면 하나의 Drive를 세 개로 Fork하면 각 에이전트가 자신의 파일을 독립적으로 수정할 수 있다.

이후 필요한 결과만 선택해 병합하는 구조를 만들 수 있다.

Fork된 Drive는 원본의 다음 속성을 상속한다.

• 기존 파일 데이터
• 리전
• 최대 저장 용량

Fork 이후 생성하거나 수정하는 파일은 다른 Fork나 원본 Drive에 영향을 주지 않는다.

이는 여러 에이전트가 병렬로 작업하는 환경에서 사용할 수 있다.

다만 Drive Fork가 Git처럼 변경 사항을 자동으로 병합하거나 충돌을 해결한다는 의미는 아니다.

각 작업 결과를 어떻게 비교하고 통합할지는 별도 로직이 필요하다.

SDK 지원

Vercel은 @vercel/sandbox SDK에서 Drive를 관리할 수 있도록 한다.

Drive.get()으로 기존 Drive를 조회하고, Fork를 생성한 뒤 Sandbox에 연결하는 구조다.

개발자는 파일을 저장하기 위해 매번 별도의 Object Storage API를 호출하지 않아도 된다.

그러나 영속적인 파일시스템이 제공된다고 해서 데이터베이스나 Object Storage의 모든 기능을 대체할 수 있는 것은 아니다.

검색과 트랜잭션, 동시 수정 제어, 접근 권한 정책 등은 저장소의 종류에 따라 차이가 있다.

이번 업데이트는 일회성 실행 환경인 Sandbox에 지속적인 파일 상태를 제공하고, 병렬 작업을 위한 독립적인 파일 공간을 만들 수 있도록 확장한 기능이다.

---

Vercel Bring Your Own Cloud 정식 출시 — Vercel Functions를 고객의 AWS 계정에서 실행

• 발표일: 2026-10-15 — 정확한 게시 시각 미확인
• 안정화 단계: Generally Available
• 적용 대상: Vercel Enterprise
• 지원 실행 환경: Node.js 및 Python Functions
• 원문: https://vercel.com/changelog/bring-your-own-cloud-on-aws-is-now-generally-available

Vercel이 Bring Your Own Cloud(BYOC)의 AWS 지원을 정식 출시했다.

일반적으로 Vercel에 애플리케이션을 배포하면 Vercel이 제공하는 인프라에서 서버리스 함수가 실행된다.

이 방식에서는 개발자가 서버를 직접 운영할 필요가 없다.

하지만 기업 환경에서는 애플리케이션의 실행 위치를 직접 관리해야 하는 경우가 있다.

예를 들어 내부 데이터베이스가 외부 인터넷에서 접근할 수 없는 VPC 안에 존재할 수 있다.

또는 조직의 보안 정책상 애플리케이션 코드가 기업이 관리하는 AWS 계정 안에서 실행돼야 할 수 있다.

BYOC는 이러한 요구사항을 지원하기 위한 기능이다.

함수 실행은 AWS, 배포와 라우팅은 Vercel

이번 기능에서는 Vercel Functions를 고객이 소유한 AWS 계정에서 실행할 수 있다.

반면 Vercel은 기존처럼 다음 작업을 담당한다.

• 애플리케이션 배포
• 실행 환경 구성
• 요청 라우팅
• 정적 파일 제공
• 배포 환경 관리

즉 Vercel의 모든 인프라를 고객의 AWS 계정으로 이전하는 구조는 아니다.

실제로 실행되는 Node.js와 Python Function을 고객의 AWS 환경에 배치하는 방식이다.

이러한 구분이 중요하다.

예를 들어 프론트엔드의 정적 JavaScript 파일과 이미지가 Vercel을 통해 제공되더라도 서버 함수는 기업의 AWS 계정 안에서 실행될 수 있다.

IAM과 VPC 접근 제어

BYOC에서는 기업이 자신의 AWS 계정에 적용된 IAM 정책을 사용할 수 있다.

IAM(Identity and Access Management)은 AWS 리소스에 접근할 수 있는 사용자와 역할, 권한을 관리하는 시스템이다.

또한 Function이 기업의 VPC 안에 있는 서비스와 통신하도록 구성할 수 있다.

VPC는 클라우드 환경에서 네트워크를 논리적으로 분리하는 기능이다.

이를 통해 외부 인터넷에 공개하지 않은 데이터베이스나 내부 API에 접근할 수 있다.

하지만 BYOC를 사용한다고 해서 애플리케이션이 자동으로 모든 보안 및 규제 요구사항을 충족하는 것은 아니다.

실제 데이터 이동 경로, 접근 권한, 로그 저장 위치와 리소스 정책은 별도로 검토해야 한다.

Enterprise 전용 기능

이번 기능은 Enterprise 고객을 대상으로 제공된다.

따라서 일반적인 Hobby나 Pro 프로젝트에서 동일한 방식으로 사용할 수 있다고 가정해서는 안 된다.

또한 발표된 지원 범위는 Node.js와 Python Function이다.

다른 언어의 실행 환경이나 모든 Vercel 기능이 고객의 AWS 계정 안에서 실행된다고 해석해서는 안 된다.

이번 발표는 Vercel의 배포 경험을 유지하면서 서버 실행 위치와 클라우드 계정의 소유권을 기업이 통제하도록 하는 인프라 운영 모델의 확장이다.

---

Vercel Connect, MCP Events·기업 관리형 인증·고정 IP 연결 지원 확대

• 발표일: 2026-10-15 — 정확한 게시 시각 미확인
• 적용 대상: Vercel Connect
• 안정화 단계: MCP Events 및 Enterprise-Managed Authorization은 Public Beta
• MCP Events 원문: https://vercel.com/changelog/mcp-events-support-in-vercel-connect-is-now-in-public-beta
• 기업 관리형 인증 원문: https://vercel.com/changelog/vercel-connect-adds-enterprise-managed-authorization
• Secure Compute 원문: https://vercel.com/changelog/vercel-connect-secure-compute

Vercel이 외부 서비스와 AI 에이전트를 연결하는 Connect에 세 가지 기능을 추가했다.

이번 변경은 외부 시스템의 이벤트를 전달받는 기능, 조직의 사용자 권한으로 다른 서비스에 접근하는 기능, 고정 IP가 필요한 인증 서버와 통신하는 기능으로 나뉜다.

세 기능은 서로 다른 문제를 해결하지만 모두 Connect의 외부 서비스 통합 기능과 관련되므로 함께 정리한다.

MCP Events: 외부 시스템의 이벤트로 에이전트 실행

첫 번째 변경은 MCP Events의 Public Beta 지원이다.

MCP(Model Context Protocol)는 AI 애플리케이션이 외부 데이터와 도구에 접근하기 위한 표준화된 인터페이스다.

일반적인 MCP 도구 호출에서는 AI 에이전트가 필요한 시점에 외부 시스템에 요청을 보낸다.

예를 들어 에이전트가 사용자의 최신 메시지를 확인하기 위해 메시지 조회 도구를 호출할 수 있다.

하지만 실제 서비스에서는 에이전트가 직접 조회하지 않아도 외부 시스템에서 이벤트가 발생할 수 있다.

대표적으로 다음과 같은 상황이다.

• 새로운 메시지 수신
• GitHub Issue 생성
• 문서에 댓글 추가
• 외부 작업 완료

기존에는 애플리케이션이 이런 이벤트를 수신하기 위해 각 서비스의 Webhook을 별도로 구현해야 할 수 있었다.

이번 Connect 기능은 호환되는 MCP 서버의 이벤트를 구독하도록 지원한다.

애플리케이션은 Connect SDK의 experimental_subscribe()를 이용해 이벤트 구독을 생성할 수 있다.

Connect는 필요한 경우 구독을 자동으로 갱신한다.

또한 MCP 서버가 전달한 Webhook을 검증한 뒤 인증된 방식으로 애플리케이션에 전달한다.

이벤트를 수신하는 애플리케이션에서는 서명을 검증하는 기능도 사용할 수 있다.

이를 통해 외부 시스템에서 이벤트가 발생했을 때 AI 에이전트의 작업을 시작하는 구조를 만들 수 있다.

다만 모든 MCP 서버가 이벤트 구독을 지원하는 것은 아니다.

해당 서버가 MCP Events를 지원해야 하며, 현재 Connect의 기능도 Public Beta 단계다.

이벤트 처리와 멱등성

이벤트 기반 시스템에서는 같은 이벤트가 두 번 전달될 가능성을 고려해야 한다.

예를 들어 새로운 Issue가 생성됐다는 이벤트가 네트워크 오류로 인해 재전송될 수 있다.

애플리케이션이 이벤트를 받을 때마다 무조건 동일한 작업을 수행하면 중복 댓글이나 중복 데이터가 생성될 수 있다.

Connect의 구독 API는 Idempotency Key를 지원한다.

동일한 구독 요청을 재시도할 때 같은 Key를 사용하면 중복 구독 생성을 방지하는 데 도움이 된다.

다만 구독 요청의 멱등성과 실제 이벤트 처리의 멱등성은 서로 다른 문제다.

이벤트를 전달받은 애플리케이션은 작업을 처리한 이벤트의 ID를 저장하는 등의 방식으로 중복 실행을 방지해야 할 수 있다.

Enterprise-Managed Authorization

두 번째 변경은 Enterprise-Managed Authorization(EMA) 지원이다.

기업 환경에서는 사용자가 여러 업무용 애플리케이션을 사용한다.

예를 들어 한 사용자가 AI 에이전트에게 자신의 Slack 메시지를 검색하고 다른 업무 시스템의 정보를 조회하도록 요청할 수 있다.

이 과정에서 애플리케이션마다 별도의 OAuth 동의 과정을 요구하면 사용자 경험과 관리 정책이 복잡해질 수 있다.

EMA는 기업의 Identity Provider가 이러한 권한을 관리하도록 한다.

예를 들어 Okta와 같은 호환되는 인증 제공업체를 사용할 수 있다.

사용자는 자신의 기업 계정으로 애플리케이션에 로그인한다.

이후 Connect가 관리자의 승인 정책과 사용자의 기존 서비스 권한을 기준으로 필요한 Access Token을 발급받아 사용하도록 한다.

이때 애플리케이션은 필요한 Scope를 요청한다.

Connect는 Token Exchange와 캐싱, 갱신 과정을 처리한다.

중요한 점은 기업 관리자가 허용한 권한과 사용자가 실제로 보유한 권한의 범위를 벗어나는 접근이 자동으로 허용되는 것은 아니라는 사실이다.

관리자는 Identity Provider에서 서비스 접근 권한을 부여하거나 철회할 수 있다.

현재 EMA는 Public Beta 단계다.

또한 호환되는 인증 제공업체와 대상 서비스에서만 사용할 수 있다.

Secure Compute: 고정 IP가 필요한 인증 서버 연결

세 번째 변경은 Secure Compute 연결 지원이다.

일부 기업용 SaaS는 특정 IP 주소에서 들어오는 요청만 허용한다.

이러한 방식을 IP Allowlist라고 한다.

Salesforce나 Snowflake와 같은 서비스에서는 조직의 보안 정책에 따라 고정 IP를 등록해야 할 수 있다.

하지만 일반적인 서버리스 플랫폼에서는 요청을 보내는 IP 주소가 고정되지 않을 수 있다.

이번 변경은 Connect가 외부 인증 제공업체에 요청을 보낼 때 Secure Compute 네트워크의 고정 IP를 사용하도록 하는 기능을 제공한다.

개발자는 Connect 설정에서 사용할 Secure Compute 네트워크를 선택할 수 있다.

이후 외부 제공업체의 IP Allowlist에 해당 네트워크의 주소를 등록한다.

그러면 Connect가 Access Token을 발급받거나 갱신하는 요청을 지정된 네트워크를 통해 전달할 수 있다.

다만 적용 범위에 주의해야 한다.

이번 설정은 Connect의 인증 토큰 발급 및 갱신 요청에 적용된다.

애플리케이션이 외부 API를 직접 호출하는 모든 요청의 네트워크 경로까지 자동으로 변경하지는 않는다.

또한 Secure Compute가 제공된다고 해서 별도의 권한 검증이나 인증 절차가 불필요해지는 것은 아니다.

이번 세 가지 업데이트는 AI 애플리케이션이 외부 서비스의 이벤트를 수신하고, 사용자별 접근 권한을 유지하며, 기업 네트워크 정책 안에서 인증을 처리하는 기능을 확대한 변화다.

---

4️⃣ 개발 도구 및 보안

GitHub AI Scan·Agentic Autofix 정식 출시 — PR의 취약점 탐지와 기본 브랜치의 보안 문제 수정 지원

• 발표일: 2026-10-15 — 정확한 게시 시각 미확인
• 안정화 단계: Generally Available
• 적용 대상: GitHub Code Scanning, GitHub Code Security, GitHub Advanced Security
• AI Scan 원문: https://github.blog/changelog/2026-10-15-ai-scan-for-pull-requests-generally-available/
• Agentic Autofix 원문: https://github.blog/changelog/2026-10-15-agentic-autofix-for-code-scanning-alerts-general-availability/

GitHub가 AI Scan for Pull Requests와 Agentic Autofix for Code Scanning Alerts를 정식 출시했다.

두 기능은 AI를 이용해 코드의 보안 문제를 다룬다는 공통점이 있다.

하지만 적용되는 시점과 역할은 다르다.

AI Scan은 PR에서 변경된 코드를 분석해 잠재적인 취약점을 발견하는 기능이다.

Agentic Autofix는 이미 발견된 보안 경고에 대해 코드를 수정하고 검증하는 작업을 수행한다.

즉 하나는 문제 탐지, 다른 하나는 문제 수정에 초점을 맞춘다.

AI Scan: CodeQL이 충분히 지원하지 않는 언어와 파일 형식 분석

GitHub Code Scanning은 CodeQL을 이용해 코드의 데이터 흐름과 보안 문제를 분석할 수 있다.

CodeQL은 정적 분석 도구다.

코드를 실제로 실행하지 않고 소스코드의 구조와 데이터 흐름을 분석해 알려진 취약점 패턴을 찾는다.

하지만 모든 언어와 프레임워크, 설정 파일을 동일한 수준으로 분석할 수 있는 것은 아니다.

이번에 정식 출시된 AI Scan은 이러한 범위를 보완한다.

GitHub는 다음 항목을 예로 들었다.

• PHP
• Shell 및 Bash
• Terraform 설정 파일(HCL)
• Dockerfile
• Java의 JSP
• C#의 Blazor

AI Scan은 PR에서 변경된 코드를 분석하고 발견한 문제를 PR 화면에 표시한다.

결과는 Conversation 탭과 Files Changed 탭에서 확인할 수 있다.

CodeQL 결과와 혼동하지 않도록 AI Scan 결과에는 별도의 AI 표시가 추가된다.

각 결과에는 문제가 되는 코드와 보안 위험에 대한 설명이 포함될 수 있다.

또한 일부 문제에는 자동 수정 제안도 제공된다.

PR 자동 실행 조건

AI Scan은 다음 조건이 충족되면 PR에서 자동 실행될 수 있다.

• Repository의 Code Scanning이 활성화돼 있어야 한다.
• 해당 Repository에 적용되는 AI Scan 설정이 활성화돼 있어야 한다.

그러나 모든 PR에서 실행되는 것은 아니다.

Fork에서 생성된 PR과 Dependabot이 생성한 PR은 AI Scan의 지원 대상에서 제외된다.

또한 AI Scan 결과는 권고 성격이다.

AI Scan이 취약점을 발견하더라도 Code Scanning Check를 실패 상태로 만들지 않는다.

Repository Ruleset을 이용해 AI Scan 결과만으로 PR 병합을 차단할 수도 없다.

따라서 AI Scan을 활성화했다고 해서 모든 보안 취약점이 자동으로 병합 전에 차단되는 것은 아니다.

사용 가능 범위와 과금

AI Scan은 개인 또는 조직이 소유한 공개 저장소에서 사용할 수 있다.

비공개 및 내부 조직 저장소에서는 GitHub Code Security 또는 GitHub Advanced Security가 필요하다.

별도의 GitHub Copilot 라이선스는 요구하지 않는다.

다만 AI Scan은 Code Security AI Credits 사용량에 영향을 준다.

따라서 기능 사용과 별도로 관련 과금 조건을 확인해야 한다.

Agentic Autofix: 취약점 수정부터 검증까지

Agentic Autofix는 이미 생성된 Code Scanning Alert를 수정하는 기능이다.

개발자는 보안 경고를 Copilot에 할당할 수 있다.

이후 Copilot은 다음 과정을 수행한다.

1. 취약점과 관련된 소스코드를 탐색한다.
2. 문제의 원인을 분석한다.
3. 수정 코드를 생성한다.
4. CodeQL을 다시 실행한다.
5. 경고가 해결됐는지 확인한다.
6. 필요한 경우 수정 작업을 반복한다.
7. 검토를 위한 Draft PR을 생성한다.

중요한 차이는 단순히 수정 코드를 제안하는 데서 종료하지 않는다는 점이다.

수정한 코드가 CodeQL에서 기존 경고를 해결했는지 확인하는 과정까지 포함한다.

생성된 PR에는 수정 내용과 검증 과정이 설명된다.

개발자는 이후 PR에 댓글을 남기거나 Agents 화면을 통해 추가 수정을 요청할 수 있다.

다만 CodeQL 경고가 사라졌다는 사실이 코드의 모든 보안 문제가 해결됐다는 의미는 아니다.

수정 과정에서 다른 동작이 변경되거나 새로운 문제가 발생할 수도 있기 때문이다.

따라서 최종 병합 전에는 개발자의 검토가 필요하다.

최대 25개의 경고를 하나의 PR로 수정

Agentic Autofix는 여러 보안 경고를 하나의 작업으로 처리할 수도 있다.

최대 25개의 Alert를 선택해 하나의 PR에서 수정하도록 요청할 수 있다.

예를 들어 동일한 취약한 함수가 여러 위치에서 사용되고 있다면 관련 경고를 하나의 수정 작업으로 묶는 것이 유리할 수 있다.

하지만 여러 경고를 한꺼번에 수정하면 변경 범위가 커질 수 있다.

따라서 관련성이 낮은 취약점을 무조건 하나의 PR로 묶는 것이 항상 적합한 것은 아니다.

REST API를 통해 Agentic Autofix 작업을 시작하는 방법도 제공된다.

Code Scanning Alert의 담당자를 copilot-swe-agent[bot]으로 지정하는 방식이다.

기본 브랜치에 있는 경고만 수정 가능

Agentic Autofix에는 중요한 제한이 있다.

Repository의 기본 브랜치에 존재하는 Code Scanning Alert만 할당할 수 있다.

PR에서만 발견됐거나 다른 브랜치에만 존재하는 경고는 Agentic Autofix에 직접 할당할 수 없다.

따라서 PR 단계의 AI Scan과 기본 브랜치의 Agentic Autofix가 하나의 완전한 자동 수정 파이프라인으로 연결된다고 해석해서는 안 된다.

두 기능은 적용 범위가 다르다.

Enterprise 정책과 과금

Agentic Autofix는 GitHub Enterprise Cloud의 Code Security 및 Advanced Security 고객에게 제공된다.

사용하려면 Enterprise 관리자가 Advanced Security 정책에서 Agentic Autofix를 허용해야 한다.

이후 조직 또는 저장소 관리자가 기능을 활성화할 수 있다.

또한 Copilot 과금 방식이 설정돼 있어야 한다.

실행 과정에서는 Copilot 관련 사용량과 GitHub Actions 실행 시간이 발생할 수 있다.

이번 업데이트는 보안 경고를 발견하는 기능과 실제 수정하는 기능을 각각 정식 출시한 변화다.

AI가 보안 분석과 수정의 일부를 수행하지만, 최종 코드의 안전성과 서비스 동작을 검증할 책임까지 자동으로 대체하는 것은 아니다.

---

Cloudflare Gateway와 Workers 통합 공개 Beta — 기업의 HTTP 보안 정책에 커스텀 JavaScript 실행 연결

• 발표일: 2026-10-15 — 정확한 게시 시각 미확인
• 안정화 단계: Public Beta
• 적용 대상: Cloudflare Gateway, Workers
• 지원 범위: 모든 Cloudflare Zero Trust 요금제
• 원문: https://developers.cloudflare.com/changelog/post/2026-10-15-gateway-workers-public-beta/

Cloudflare가 Gateway의 HTTP 정책에서 직접 Workers 코드를 실행할 수 있는 기능을 공개했다.

Cloudflare Gateway는 기업이나 조직의 네트워크 트래픽에 보안 정책을 적용하는 서비스다.

예를 들어 조직은 특정 웹사이트의 접근을 차단하거나, 파일 다운로드를 검사하거나, 사용자별 접근 권한을 적용할 수 있다.

하지만 모든 조직의 요구사항을 정해진 정책 규칙만으로 표현하기는 어렵다.

특정 애플리케이션으로 전송되는 요청의 내용을 변경해야 하거나, 특정 조건에서 별도의 알림을 생성해야 할 수 있다.

기존에는 이러한 처리를 위해 별도의 Proxy 서버나 자체 네트워크 서비스를 운영해야 할 수 있었다.

이번 기능은 Gateway의 HTTP 정책과 Workers 실행 환경을 직접 연결한다.

Forward Action으로 Workers 실행

Gateway HTTP 정책에는 새로운 Forward Action을 사용할 수 있다.

요청이 지정된 정책과 일치하면 Gateway는 해당 요청을 연결된 Worker로 전달한다.

Worker에서는 JavaScript 또는 TypeScript 코드를 이용해 요청을 처리할 수 있다.

예를 들어 다음과 같은 작업을 수행할 수 있다.

• HTTP Request 변경
• HTTP Response 변경
• 사용자에게 안내 페이지 반환
• 특정 요청에 대한 Slack 알림 생성
• R2에 필요한 데이터 저장
• 조직별 커스텀 접근 정책 구현

Worker는 단순히 HTTP 요청 본문만 전달받는 것이 아니다.

Gateway가 확인한 요청 문맥도 함께 전달받을 수 있다.

여기에는 사용 가능한 경우 다음 정보가 포함된다.

• 연결 메타데이터
• 사용자 신원
• 디바이스 보안 상태

예를 들어 회사에서 관리하는 기기인지 여부에 따라 서로 다른 응답을 반환하는 로직을 구현할 수 있다.

Gateway의 보안 검사와 Worker의 실행 순서

이번 기능에서 중요한 점은 Worker가 Gateway의 보안 검사를 완전히 대체하지 않는다는 사실이다.

Gateway는 먼저 기존 HTTP Request 정책을 평가한다.

허용된 요청 가운데 Forward 정책에 일치하는 요청을 Worker로 전달한다.

또한 Gateway는 Worker로 전달하기 전에 원본 Request Body를 검사한다.

차단 대상 콘텐츠가 발견되면 Worker의 실행이 중단될 수 있다.

Worker가 응답을 생성하거나 변경한 뒤에도 Gateway는 최종 응답을 검사한다.

즉 요청과 응답에 대한 보안 검사가 Worker 실행 전후에 적용될 수 있다.

Cloudflare는 TLS 복호화, Proxy 연결, 외부 서버로의 요청 전달 등을 Gateway가 처리하도록 한다.

개발자는 별도의 전체 HTTP Proxy 서버를 직접 구현하지 않고 필요한 로직만 Worker에 작성할 수 있다.

기존 Workers 사용 방식과의 차이

일반적인 Cloudflare Worker는 특정 도메인으로 들어오는 요청을 처리하거나 외부 API를 호출하는 서버리스 프로그램이다.

반면 이번 통합에서는 기업의 보안 Gateway를 통과하는 트래픽에 Worker를 연결한다.

따라서 특정 웹서비스의 애플리케이션 코드뿐 아니라 조직의 네트워크 정책 자체를 프로그래밍할 수 있다.

그러나 Worker를 연결한다고 해서 모든 HTTP 및 HTTPS 요청을 제한 없이 분석하거나 변경할 수 있는 것은 아니다.

Gateway에 설정된 정책과 TLS 검사 구성, 지원하는 트래픽 범위에 따라 실제로 사용할 수 있는 정보가 달라질 수 있다.

또한 사용자의 요청 및 응답 데이터를 처리하는 커스텀 코드는 개인정보와 접근 권한 정책을 고려해야 한다.

예를 들어 요청 본문을 R2에 저장하는 기능을 추가했다면 해당 데이터의 보존 기간과 접근 권한도 정의해야 한다.

이번 기능은 Public Beta 단계다.

Cloudflare Gateway의 정책 처리 과정에 개발자가 작성한 코드를 삽입할 수 있도록 한 확장으로, 별도의 Proxy 인프라를 운영하지 않고 조직별 HTTP 처리 정책을 구현할 수 있는 범위를 넓혔다.

---

📚 추천 글

Opening the app from a link, and what happens when it is not installed

• 저자: Yury Hryshchanka
• 게시일: 2026-10-14
• 원문: https://dev.to/yhryshchanka/opening-the-app-from-a-link-and-what-happens-when-it-is-not-installed-1505

웹페이지에서 특정 링크를 클릭했을 때 앱이 설치돼 있으면 앱의 해당 화면을 열고, 설치돼 있지 않으면 브라우저에서 적절한 대체 페이지를 보여주는 문제를 실제 운영 사례를 바탕으로 설명한 글이다.

저자는 Nicegram의 웹서비스에서 사용한 구현을 소개한다.

Nicegram은 Telegram을 기반으로 하는 클라이언트 애플리케이션이다.

사용자가 웹에서 특정 채널을 발견하면 앱에서 같은 채널을 열 수 있어야 한다.

하지만 앱이 설치되지 않은 사용자에게 단순히 앱스토어를 보여주는 것은 반드시 좋은 사용자 경험이 아니다.

사용자가 원래 하려던 일은 앱을 설치하는 것이 아니라 해당 채널의 콘텐츠를 보는 것이기 때문이다.

저자는 이 문제를 해결하는 과정에서 앱 설치 여부를 추측하는 JavaScript 코드를 제거하고 운영체제의 링크 처리 기능을 사용하도록 변경했다.

타이머로 앱 설치 여부를 추측하던 기존 구현

기존 구현에서는 커스텀 URL Scheme을 사용했다.

커스텀 URL Scheme은 myapp://처럼 애플리케이션이 자신의 주소로 등록하는 방식이다.

브라우저에서 이 주소를 열면 운영체제가 해당 Scheme을 처리할 수 있는 앱을 찾는다.

문제는 앱이 설치돼 있지 않을 때 발생한다.

기존 구현은 JavaScript로 앱 실행을 시도한 뒤 짧은 타이머를 실행했다.

예를 들어 25ms 뒤에 타이머를 실행하고 실제 경과 시간이 100ms보다 작다면 앱이 열리지 않았다고 추측하는 방식이었다.

논리는 다음과 같다.

앱이 정상적으로 열리면 브라우저가 백그라운드로 이동하면서 타이머 실행이 지연될 것이다.

반면 앱이 설치돼 있지 않다면 브라우저가 계속 실행되므로 타이머가 예정된 시점에 실행될 것이다.

하지만 이 가정에는 문제가 있다.

브라우저의 타이머가 지연됐다는 사실과 앱이 성공적으로 실행됐다는 사실은 동일하지 않다.

기기 성능이 느리거나 운영체제가 다른 작업을 처리하는 경우에도 타이머는 지연될 수 있다.

반대로 앱이 실행되는 동안 브라우저의 타이머가 계속 진행될 수도 있다.

그 결과 앱과 앱스토어가 동시에 열리거나, 정상적으로 앱이 설치돼 있는데도 잘못된 대체 페이지로 이동하는 문제가 발생했다.

더 근본적인 문제는 해당 방식이 브라우저의 공식적인 동작 보장에 기반하지 않았다는 것이다.

특정 운영체제와 브라우저에서 우연히 동작하던 구현이었다.

Universal Links와 Android App Links 사용

저자는 커스텀 URL Scheme과 타이머를 이용하는 대신 iOS Universal Links와 Android App Links를 사용했다.

두 기술은 일반적인 HTTPS 주소를 애플리케이션과 연결할 수 있도록 한다.

앱이 특정 도메인의 주소를 처리할 수 있다고 선언하면 운영체제는 해당 앱과 웹사이트의 관계를 확인한다.

이후 사용자가 해당 링크를 클릭했을 때 앱으로 전달할지 브라우저에서 열지 결정한다.

중요한 차이는 앱 설치 여부를 웹페이지가 직접 추측하지 않는다는 것이다.

운영체제는 사용자가 어떤 앱을 설치했는지 알고 있다.

따라서 해당 판단을 운영체제에 맡기는 방식이다.

이 구조는 개인정보 보호 측면에서도 의미가 있다.

웹사이트가 사용자의 설치된 앱 목록을 자유롭게 확인할 수 있다면 사용자를 식별하는 Fingerprinting에 악용될 수 있기 때문이다.

저자는 웹페이지가 앱 설치 여부를 알아내려고 하는 것보다 운영체제가 처리하지 못한 요청에 어떻게 응답할지 설계하는 것이 중요하다고 설명한다.

특정 경로만 앱과 연결

저자는 웹사이트 전체를 앱과 연결하지 않았다.

대신 /deeplink라는 특정 경로만 앱이 처리하도록 구성했다.

실제로 열려는 콘텐츠의 주소는 Query Parameter에 전달한다.

예를 들어 다음과 같은 구조다.

https://www.example.com/deeplink?url=...

이렇게 하면 웹사이트의 모든 페이지가 앱 실행 대상이 되는 문제를 방지할 수 있다.

예를 들어 서비스 소개 페이지나 고객센터 페이지까지 앱으로 연결된다면 사용자가 의도하지 않은 앱 전환이 발생할 수 있다.

따라서 앱과 연결할 경로를 명확하게 제한하는 방식을 선택했다.

같은 도메인에서 클릭했을 때 발생하는 문제

이 글에서 흥미로운 부분은 iOS Universal Links의 도메인 처리 방식이다.

사용자가 이미 특정 웹사이트를 Safari에서 보고 있는 상황에서는 같은 도메인의 Universal Link를 클릭해도 브라우저가 일반적인 내부 탐색으로 처리할 수 있다.

즉 Universal Link 설정 자체가 올바르더라도 앱이 열리지 않을 수 있다.

저자는 이를 해결하기 위해 링크에 사용하는 호스트를 분리했다.

예를 들어 현재 페이지가 example.com에 있다면 앱 실행 링크는 www.example.com을 사용한다.

두 주소는 사용자에게 같은 서비스처럼 보일 수 있지만 기술적으로는 서로 다른 호스트다.

이러한 차이를 이용해 운영체제가 앱으로 연결할 수 있는 경로를 구성한다.

다만 모든 브라우저에서 앱 전환 동작이 동일하다고 가정할 수는 없다.

또한 주소창에 직접 URL을 입력하거나 JavaScript만으로 탐색을 시작하는 경우에는 사용자가 링크를 직접 클릭했을 때와 다른 동작이 발생할 수 있다.

따라서 웹사이트에서 앱 전환을 지원하려면 실제 사용자 상호작용과 브라우저의 탐색 정책을 함께 고려해야 한다.

Next.js Middleware에서 Fallback 처리

운영체제가 앱으로 링크를 전달하지 않았다면 요청은 웹 서버에 도착할 수 있다.

저자는 이 상황을 이용한다.

앱으로 정상적으로 전달됐다면 웹 서버가 요청을 받지 않는다.

반면 앱으로 전달되지 않았다면 브라우저가 /deeplink 경로를 요청한다.

서버는 Query Parameter에 포함된 실제 콘텐츠 주소를 확인한다.

주소가 허용된 대상이라면 해당 콘텐츠의 웹페이지로 Redirect한다.

유효하지 않은 주소라면 서비스의 다운로드 페이지를 보여준다.

원문에서는 Next.js 15의 Middleware를 사용한다.

구현은 요청의 경로와 url 파라미터를 확인하고, 허용된 주소에 따라 Redirect 또는 Rewrite를 수행한다.

여기서 Redirect와 Rewrite의 차이도 중요하다.

Redirect는 브라우저에 다른 URL로 이동하도록 지시한다.

반면 Rewrite는 브라우저의 주소를 유지하면서 다른 페이지의 콘텐츠를 반환한다.

저자는 실제 콘텐츠 주소로 이동할 때는 Redirect를 사용하고, 다운로드 페이지를 보여줄 때는 Rewrite를 사용한다.

Open Redirect 방지

원문 구현에서는 URL Allowlist를 사용한다.

url Query Parameter는 사용자가 직접 변경할 수 있기 때문이다.

서버가 전달받은 URL로 무조건 Redirect한다면 공격자는 신뢰할 수 있는 서비스 도메인을 이용해 악성 사이트로 사용자를 이동시킬 수 있다.

이러한 취약점을 Open Redirect라고 한다.

저자는 URL 객체로 대상 주소를 분석하고 origin이 허용된 목록에 포함돼 있는지 확인한다.

단순히 문자열에 특정 도메인이 포함돼 있는지 검사하는 방식은 사용하지 않는다.

예를 들어 다음 주소는 신뢰할 수 있는 도메인이 아니다.

https://example.com.evil.test

하지만 단순 문자열 포함 검사에서는 잘못 허용될 수 있다.

따라서 실제 Origin을 비교하는 방식이 필요하다.

Fallback을 앱스토어가 아닌 콘텐츠로 연결하는 이유

저자가 변경한 가장 중요한 제품 설계는 앱이 설치돼 있지 않을 때의 동작이다.

기존에는 앱이 설치되지 않았다고 판단하면 앱스토어로 이동했다.

하지만 사용자가 특정 대화나 채널을 열려고 했다는 점을 고려하면 앱스토어는 원래 목적과 다르다.

사용자는 먼저 앱을 설치해야 하고, 설치한 뒤에는 원래 클릭했던 콘텐츠를 다시 찾아야 한다.

이 과정에서 사용자가 이탈할 수 있다.

저자는 이를 해결하기 위해 앱이 설치돼 있지 않으면 동일한 콘텐츠를 볼 수 있는 웹페이지로 이동하도록 했다.

이 방식에서는 앱 실행에 실패하더라도 사용자가 원래 보려고 했던 콘텐츠에 접근할 수 있다.

물론 이 구현에도 한계가 있다.

웹 서버에 요청이 도착했다는 사실이 앱이 설치돼 있지 않다는 확실한 증거는 아니다.

브라우저 정책이나 링크를 클릭한 위치에 따라 앱이 설치돼 있어도 웹 요청이 발생할 수 있기 때문이다.

그러나 Fallback이 같은 콘텐츠의 웹페이지라면 이러한 추측이 잘못됐더라도 사용자가 겪는 불편이 작다.

이 글은 단순한 Deep Link 구현 방법을 넘어 브라우저와 운영체제의 책임을 구분하고, 기술적 불확실성이 존재하는 상황에서도 사용자에게 자연스러운 결과를 제공하는 설계를 보여준다.

---

Shipping Media Over QUIC at Meta Scale for Instagram Live Ingest

• 저자: Konstantin Tsoy, Aman Sharma, Hari Anil Kumar, Alan Frindell, Sandarsh Srivastava / Meta Engineering
• 게시일: 2026-10-12
• 원문: https://engineering.fb.com/2026/10/12/video-engineering/shipping-media-over-quic-at-meta-scale-for-instagram-live-ingest/

Meta가 Instagram Live의 영상 송출 과정에 Media over QUIC(MoQ)을 도입한 과정을 설명한 기술 글이다.

MoQ는 QUIC을 기반으로 실시간 미디어를 전달하기 위한 프로토콜이다.

이번 글은 새로운 웹 표준의 정식 출시를 발표하는 내용이 아니다.

아직 발전 중인 IETF 프로토콜을 대규모 서비스에 적용하면서 발생한 호환성과 배포 문제를 다룬 운영 사례다.

특히 기존 프로토콜을 새로운 프로토콜로 교체할 때 서비스 전체를 한 번에 재작성하지 않고 점진적으로 이전하는 방법을 설명한다.

기존 스트리밍 프로토콜이 여러 개로 나뉜 이유

인터넷에서는 목적에 따라 서로 다른 미디어 전송 프로토콜이 발전했다.

예를 들어 다음과 같은 기술이 있다.

각 프로토콜은 해결하려는 문제가 다르다.

라이브 방송 송출에서는 서버에 영상을 안정적으로 전달하는 것이 중요하다.

대규모 재생에서는 많은 시청자에게 데이터를 효율적으로 배포해야 한다.

실시간 통화에서는 네트워크 지연과 패킷 손실을 빠르게 처리해야 한다.

문제는 하나의 애플리케이션이 이러한 기능을 모두 제공할 때 발생한다.

사용자가 라이브 방송을 시작하고 이후 실시간 통화를 하거나 녹화된 영상을 재생하면 서비스 내부에서는 여러 프로토콜과 서버 인프라가 사용될 수 있다.

이는 개발 및 운영 측면에서 복잡성을 증가시킨다.

Meta는 이 문제를 해결하기 위해 미디어 송출과 전달, 재생을 하나의 프로토콜 체계로 연결하는 방향을 검토하고 있다.

QUIC 기반 전송

QUIC은 UDP를 기반으로 하는 전송 프로토콜이다.

HTTP/3에서도 사용된다.

QUIC은 여러 독립적인 Stream을 하나의 연결 안에서 사용할 수 있도록 한다.

이러한 구조는 하나의 데이터 흐름에서 패킷 손실이 발생했을 때 다른 흐름까지 불필요하게 지연되는 문제를 줄이는 데 도움이 될 수 있다.

또한 연결 설정과 연결 경로 변경을 지원하는 기능을 제공한다.

MoQ는 이러한 QUIC 위에서 미디어를 전송한다.

MoQ의 핵심 개념은 Track이다.

Track은 송출자가 전달하고 시청자가 구독하는 미디어 데이터의 단위다.

예를 들어 하나의 방송에서도 오디오와 비디오를 서로 다른 Track으로 구성할 수 있다.

중간 Relay는 미디어 데이터의 내부 내용을 직접 해석하지 않고도 전송 메타데이터를 이용해 필요한 Track을 전달할 수 있다.

또한 Relay는 캐싱과 Fan-out을 수행할 수 있다.

Fan-out은 하나의 데이터 흐름을 여러 시청자에게 복제해 전달하는 구조다.

이러한 기능은 대규모 라이브 방송에서 중요하다.

동일한 콘텐츠를 서로 다른 지연 시간으로 전달

MoQ는 동일한 Track을 구독하는 사용자에게 서로 다른 전달 정책을 적용할 수 있도록 설계됐다.

예를 들어 실시간으로 방송에 참여하는 사용자는 약 100ms 수준의 지연을 목표로 할 수 있다.

반면 일반적인 시청자는 수 초의 버퍼링을 허용하면서 재생 안정성을 높이는 방식을 선택할 수 있다.

이는 모든 시청자에게 동일한 지연 시간과 신뢰성 정책을 적용할 필요가 없다는 의미다.

네트워크 상태에 따라 오래된 미디어 데이터를 건너뛰거나 특정 Track의 우선순위를 변경하는 방식도 활용할 수 있다.

다만 이러한 기능이 프로토콜에 설계돼 있다는 사실과 Meta의 현재 Instagram Live 배포에서 모두 구현됐다는 사실은 구분해야 한다.

이번 실제 배포는 라이브 방송의 Ingest 경로를 먼저 교체한 단계다.

시청자에게 전달되는 전체 재생 경로까지 모두 MoQ로 전환한 것은 아니다.

기존 RUSH를 대체하는 과정

Meta는 기존 Instagram Live의 영상 송출 과정에서 RUSH를 사용했다.

RUSH는 Meta가 자체적으로 개발한 QUIC 기반 스트리밍 프로토콜이다.

수년 동안 대규모 서비스를 운영하면서 안정성을 확보했지만, 하나의 기업이 주로 관리하는 자체 프로토콜이라는 제한이 있었다.

Meta는 이를 여러 기업과 연구기관이 함께 발전시키는 MoQ로 이전하기로 결정했다.

하지만 Instagram Live처럼 사용자가 많은 서비스를 한 번에 새로운 프로토콜로 변경하는 것은 위험하다.

프로토콜의 작은 호환성 문제가 많은 방송에 영향을 줄 수 있기 때문이다.

따라서 Meta는 기존 시스템을 최대한 유지하면서 클라이언트의 송출 프로토콜부터 변경했다.

Edge에서 프로토콜 변환

가장 중요한 설계 선택은 Edge에서 MoQ를 기존 RUSH 형식으로 변환하는 계층을 둔 것이다.

새로운 클라이언트는 MoQ를 이용해 영상을 송출한다.

Edge 서버는 MoQ 데이터를 받아 기존 RUSH 형식으로 변환한다.

이후 내부 백엔드 시스템은 기존과 동일한 형식의 데이터를 처리한다.

따라서 전체 미디어 처리 파이프라인을 즉시 변경할 필요가 없다.

이 방식은 새로운 프로토콜을 일부 사용자에게 적용하면서 기존 처리 시스템을 유지할 수 있다는 장점이 있다.

하지만 변환 계층이 추가되기 때문에 운영해야 할 구성요소도 증가한다.

Meta는 이러한 변환 계층을 장기적으로 유지할 최종 구조가 아니라 전환 과정에서 사용하는 임시 호환 계층으로 설명한다.

향후 전체 시스템이 MoQ를 직접 처리할 수 있게 되면 해당 계층을 제거하는 것이 목표다.

서버 측 라우팅을 이용한 점진적 배포

Meta는 방송을 시작할 때 생성되는 Stream URL을 이용해 어떤 프로토콜을 사용할지 결정했다.

실험 대상 사용자의 요청은 MoQ를 지원하는 Endpoint로 전달한다.

기존 사용자는 RUSH 경로를 계속 사용한다.

이렇게 하면 모바일 애플리케이션의 배포 버전에만 의존하지 않고 서버 측에서 실험 대상을 조정할 수 있다.

문제가 발생하면 실험 대상 비율을 빠르게 줄이거나 기존 경로로 되돌릴 수 있다.

이는 대규모 네트워크 프로토콜을 변경할 때 중요한 설계다.

새로운 프로토콜의 문제가 확인됐을 때 모든 사용자가 앱을 다시 설치하도록 요구하는 방식으로는 신속하게 대응하기 어렵기 때문이다.

UDP가 차단된 네트워크의 처리

QUIC은 UDP를 사용한다.

하지만 일부 기업 네트워크나 이동통신망에서는 UDP/443 연결이 차단되거나 제한될 수 있다.

이러한 상황에서는 QUIC 기반 전송만 사용하도록 강제하면 일부 사용자가 방송을 시작하지 못할 수 있다.

Meta는 연결을 시작할 때 TCP와 QUIC 연결을 시도하고, 먼저 성공한 경로를 선택하는 방식을 사용했다.

현재는 기존 RUSH의 TCP Fallback을 활용한다.

향후에는 QMUX와 같은 표준화된 TCP Fallback을 검토하고 있다.

여기서 중요한 점은 MoQ의 최종 목표와 현재 운영 환경에서 실제로 사용하는 Fallback 구조가 다르다는 사실이다.

결과와 한계

Meta는 iOS와 Android의 Instagram Live Ingest에 MoQ를 배포했다.

공식 발표에 따르면 새로운 경로는 기존 RUSH와 비교해 주요 스트리밍 품질 및 신뢰성 지표에서 동등한 수준을 달성했다.

하지만 이번 단계의 목표는 극적인 성능 향상이 아니었다.

기존 사용자 경험을 악화시키지 않으면서 새로운 프로토콜로 전환할 수 있다는 사실을 검증하는 것이었다.

따라서 모든 방송의 지연 시간이 특정 비율로 감소했다는 결과는 제시하지 않았다.

향후에는 재생 경로까지 MoQ를 확대하고, 손실된 오래된 프레임을 건너뛰거나 대역폭에 따라 품질을 조절하는 기능을 발전시킬 계획이라고 설명한다.

이번 글은 새로운 프로토콜을 대규모 서비스에 도입할 때 호환 계층, 관측 도구, 서버 측 라우팅, 빠른 롤백이 왜 중요한지를 실제 운영 사례로 보여준다.

---

Rewinding the exponential: How we keep hardware usage down

• 저자: Cathy Chi, Sergey Nuzhdin, Christian Endres / Cloudflare
• 게시일: 2026-10-13
• 원문: https://blog.cloudflare.com/rewinding-the-exponential/

Cloudflare가 전 세계 네트워크에서 수집하는 대규모 이벤트 데이터를 처리하면서 하드웨어 증가 속도를 줄이기 위해 수행한 최적화 작업을 설명한 글이다.

웹서비스에서는 요청 로그, 오류 정보, 보안 이벤트, 사용자 행동 데이터 등이 지속적으로 생성된다.

이러한 데이터는 장애 분석과 보안 탐지, 성능 측정에 필요하다.

하지만 서비스가 성장하면 데이터의 양도 증가한다.

문제는 단순히 저장 용량이 커지는 것만이 아니다.

데이터를 수집하고 전송하고 가공하는 모든 단계에서 네트워크 대역폭, CPU, 메모리 비용이 발생한다.

Cloudflare는 2026년 5월 기준으로 초당 약 20억 건의 이벤트를 전달하고 있었다고 설명한다.

이러한 규모에서는 데이터 처리량이 일정 비율만 증가해도 필요한 인프라 자원이 크게 늘어날 수 있다.

Cloudflare는 지난 5년 동안 여러 구조적 개선을 통해 하드웨어 확장 시점을 늦췄다고 설명한다.

전체 로그를 하나의 구조로 전달하던 문제

Cloudflare의 초기 데이터 파이프라인에서는 여러 제품이 생성하는 데이터를 하나의 거대한 스키마로 관리했다.

예를 들어 HTTP 로그, 보안 로그, CDN 관련 데이터가 하나의 데이터 구조에 포함될 수 있었다.

문제는 모든 Consumer가 해당 필드를 전부 필요로 하지 않는다는 점이다.

HTTP 요청 수를 계산하는 서비스에는 일부 네트워크 정보만 필요할 수 있다.

반면 보안 분석 시스템은 요청의 위험도나 탐지 규칙과 관련된 정보를 필요로 할 수 있다.

그런데 모든 Consumer에게 전체 데이터 구조를 전달하면 필요하지 않은 필드까지 네트워크로 전송해야 한다.

Cloudflare는 이를 해결하기 위해 제품별로 필요한 필드를 구분한 작은 스키마로 변경했다.

흥미로운 점은 일부 필드가 여러 메시지에 중복으로 포함될 수 있다는 것이다.

그러나 전체 데이터를 하나의 메시지로 전달하는 것보다 필요한 정보만 분리해 전달하는 편이 결과적으로 효율적이었다.

Cloudflare는 이러한 구조 변경으로 네트워크 대역폭 사용량을 약 35~40% 줄였다고 설명한다.

이 수치는 Cloudflare의 자체 운영 측정 결과다.

LZ4에서 Zstandard로 압축 방식 변경

다음 개선은 데이터 압축이었다.

Cloudflare는 기존에 LZ4를 사용했다.

LZ4는 빠른 압축과 해제 속도를 제공하는 알고리즘이다.

하지만 압축률이 더 높은 알고리즘을 사용하면 네트워크로 전송하는 데이터의 크기를 줄일 수 있다.

Cloudflare는 Zstandard(zstd)로 전환하는 방식을 검토했다.

문제는 압축률과 CPU 사용량 사이의 관계였다.

압축률이 높아져도 CPU 사용량이 크게 증가한다면 전체 시스템 비용이 줄어들지 않을 수 있기 때문이다.

Cloudflare는 먼저 일부 서버에 새로운 압축 알고리즘을 적용하고 CPU 사용량을 관찰했다.

이후 점진적으로 적용 범위를 확대했다.

결과적으로 CPU 사용량의 눈에 띄는 증가 없이 압축된 데이터의 전송량을 약 40% 줄였다고 설명한다.

이는 동일한 네트워크 대역폭으로 더 많은 이벤트를 처리할 수 있음을 의미한다.

하지만 모든 데이터에서 zstd가 LZ4보다 동일한 비율로 유리하다는 의미는 아니다.

압축률과 CPU 비용은 데이터의 형태와 압축 설정에 따라 달라질 수 있다.

데이터가 모이기 전에 먼저 집계

2026년에 이루어진 중요한 변경 가운데 하나는 데이터가 중앙 서버에 도착하기 전에 일부 집계를 수행하는 구조다.

예를 들어 1분 동안 특정 도메인에 발생한 HTTP 요청 수를 계산한다고 가정해 보자.

기존 방식에서는 개별 HTTP 요청 이벤트를 중앙 시스템으로 전달한 뒤 합계를 계산할 수 있다.

하지만 최종적으로 필요한 결과가 요청 수의 합계라면 모든 원본 이벤트를 중앙으로 보낼 필요는 없을 수 있다.

각 Edge 서버에서 먼저 요청 수를 계산한 뒤 부분 합계를 전달할 수 있기 때문이다.

Cloudflare는 이러한 원리를 이용해 집계를 여러 단계에 분산했다.

데이터를 생성하는 서버에서 먼저 부분 집계를 수행한다.

이후 중앙 Receiver에서 여러 부분 집계를 다시 합친다.

데이터를 버퍼에서 가져오는 Consumer도 다시 집계한다.

마지막으로 ClickHouse에서 최종 결과를 관리한다.

즉 데이터가 중앙으로 모이는 과정마다 동일한 집계값을 합칠 기회를 제공한다.

약 80% 감소한 HTTP 집계 데이터 전송량

Cloudflare는 HTTP 집계 데이터셋에 새로운 구조를 적용했다.

기존에는 압축된 데이터가 초당 9GB 이상 전송됐다.

집계를 여러 단계로 분산한 이후에는 초당 2GB 미만으로 감소했다.

Cloudflare는 이를 약 80%의 네트워크 전송량 감소라고 설명한다.

이 수치는 특정 HTTP 집계 데이터셋에서 관찰한 결과다.

Cloudflare의 모든 데이터셋에 동일한 비율의 감소가 발생한 것은 아니다.

집계가 효과적인 데이터와 그렇지 않은 데이터의 차이도 있다.

예를 들어 특정 도메인의 요청 수처럼 합계를 계산하는 데이터는 집계에 적합하다.

반면 개별 요청의 상세한 내용이 필요한 장애 조사 로그에서는 원본 데이터를 보존해야 할 수 있다.

따라서 집계를 적용할 때는 어떤 정보를 유지해야 하고 어떤 정보를 합쳐도 되는지를 먼저 정의해야 한다.

Sampling과 Aggregation의 차이

Cloudflare는 Sampling도 사용한다.

Sampling은 전체 데이터 가운데 일부만 선택해 저장하거나 분석하는 방식이다.

예를 들어 전체 요청 가운데 1%를 선택해 분석할 수 있다.

이 방식은 데이터 양을 크게 줄일 수 있지만 실제 전체 요청 수를 정확하게 알기 어려울 수 있다.

반면 Aggregation은 특정 기준으로 데이터를 합쳐 결과를 저장한다.

예를 들어 모든 요청을 처리하면서 HTTP Method별 요청 수를 계산할 수 있다.

이 경우 원본 요청의 모든 정보를 보존하지는 않지만, 선택한 집계 지표는 정확하게 계산할 수 있다.

두 방식의 차이를 정리하면 다음과 같다.

Aggregation은 어떤 질문에 답할지 미리 정의해야 한다는 제한이 있다.

나중에 새로운 분석 항목이 필요해지더라도 이미 버린 원본 이벤트를 복원할 수는 없기 때문이다.

따라서 모든 데이터를 무조건 집계하는 방식이 좋은 것은 아니다.

인프라 자원 감소 효과

Cloudflare는 2026년에 여러 최적화를 함께 적용했다.

주요 개선의 효과는 다음과 같다.

이 수치는 Cloudflare가 운영 환경에서 집계한 자체 측정 결과다.

각 개선 효과를 단순히 모든 환경에 적용할 수 있는 수치로 해석해서는 안 된다.

Cloudflare는 일부 데이터 파이프라인에서 CPU 약 750개와 메모리 약 3.5TiB에 해당하는 자원을 다시 확보했다고 설명한다.

또한 지난 5년 동안 수행한 개선을 합산하면 약 2년 6개월분의 하드웨어 확장을 지연시킨 효과가 있다고 추정했다.

다만 이는 실제로 하드웨어 확장이 정확히 2년 6개월 동안 필요하지 않았다는 의미보다, 기존 데이터 증가 추세를 기준으로 환산한 결과다.

실제 향후 데이터 증가 속도와 서비스 구조가 달라지면 추정값도 달라질 수 있다.

최적화 이후에도 트래픽은 계속 증가한다

Cloudflare가 강조하는 부분은 최적화 효과가 영구적으로 유지되지 않는다는 점이다.

트래픽은 계속 증가한다.

예를 들어 특정 데이터 파이프라인의 처리량을 절반으로 줄였더라도 몇 달 뒤 새로운 데이터가 증가하면 다시 높은 처리량에 도달할 수 있다.

따라서 일회성 압축 최적화만으로는 장기적인 확장 문제를 해결하기 어렵다.

Cloudflare는 데이터 구조와 처리 위치를 변경하는 방식으로 지속적인 자원 절감을 추구하고 있다.

이 글은 시스템의 처리량이 증가할 때 서버를 더 추가하는 방법뿐 아니라 애초에 이동하고 처리해야 할 데이터의 양을 줄이는 아키텍처가 중요하다는 점을 실제 운영 수치로 보여준다.

특히 로그 파이프라인, 데이터 분석 시스템, 대규모 백엔드 서비스를 설계할 때 Sampling과 Aggregation의 차이, 압축 알고리즘의 트레이드오프, 분산 집계의 효과를 이해하는 데 참고할 만하다.