cdn

7 개의 포스트

cloudflare

에이전틱 인터넷의 좋은 행동과 나쁜 행동을 파헤치다 (새 탭에서 열림)

인터넷 트래픽은 인간과 봇으로 단순히 나눌 수 없으며, 한 세션 안에서 인간과 에이전트가 번갈아 행동하는 하이브리드 트래픽도 증가하고 있다. 따라서 사이트 운영자는 일회성 검사보다 세션 전체의 행동을 분석해 위험(Risk)과 신뢰(Trust)를 평가해야 한다. Cloudflare는 투명하게 자신을 밝히고 신뢰를 남용하지 않는 봇은 허용하되, 지속적인 행동 분석으로 악성 자동화 트래픽을 탐지하는 생태계를 구축하고 있다. ## 위험과 신뢰는 서로 다른 개념 - **위험(Risk)**은 특정 요청이나 행동이 해로울 가능성으로, 순간적이고 상황에 따라 달라진다. - **신뢰(Trust)**는 시간에 걸쳐 쌓이는 평판이며, 방문자의 행동 맥락을 바탕으로 형성된다. - 예를 들어 밤늦게 초인종을 여러 번 누르는 행동만 보면 위험해 보이지만, 방문자가 신뢰하는 친구라면 판단이 달라진다. - 인터넷에서도 “특정 시간대의 요청”이나 “일정 횟수 이상의 요청”만으로 차단하면 정상적인 사용자를 오탐할 수 있다. - Cloudflare는 악성 활동을 차단하는 것부터 안전한 참여를 장려하는 것까지, 신뢰를 중심으로 한 도구와 인센티브를 제공하려 한다. ## 투명성을 기반으로 한 정상 봇 - Cloudflare가 정의하는 검증된 봇과 에이전트는 다음 두 조건을 만족해야 한다. - 자신이 누구인지 정직하게 선언한다. - 획득한 신뢰를 악용하지 않는다. - 봇 운영자가 정체성과 데이터 사용 목적을 투명하게 공개하면, 사이트 운영자는 허용할 행동과 접근 범위를 더 쉽게 결정할 수 있다. - **BotBase**는 단순히 “좋은 봇 목록”을 제공하는 디렉터리가 아니라, 알려진 봇과 에이전트의 신원 및 행동 정보를 추적하는 시스템이다. - 검증된 봇이라도 Cloudflare 네트워크에서 신뢰를 남용하면 검증 상태를 잃을 수 있다. - 즉, 정상 여부는 고정된 신분이 아니라 실제 행동과 신뢰 유지 여부에 따라 계속 평가된다. ## 일회성 검사를 넘어서는 악성 봇 탐지 - **Precursor**는 CDN에서 JavaScript를 주입해 클라이언트 측 행동을 지속적으로 분석하는 시스템이다. - CAPTCHA나 한 번의 브라우저 검사는 특정 시점의 위험만 평가하므로, 이후 악성 행동을 시작하는 봇을 놓칠 수 있다. - Precursor는 페이지 이동을 포함한 전체 세션을 관찰해 인간답지 않은 행동 패턴을 탐지한다. - 주요 효과는 다음과 같다. - 세션 전체에 걸친 신뢰 기반 탐지 - 봇 개발자가 여러 페이지에 걸쳐 인간 행동을 모방해야 하도록 비용 증가 - 단 한 번의 검사만 통과한 자동화 트래픽에 지속적인 우회 기회를 주지 않음 - 이는 봇 개발자가 탐지 시스템을 우회하는 경제적 이점을 줄여, 공격자와 방어자 사이의 경쟁에서 방어 측에 유리하게 만든다. ## 세션 중간에 나타나는 의심스러운 행동 - 출시 후 24시간 동안 Precursor는 Cloudflare 네트워크의 73,438개 존에서 2억 600만 건의 평가 이벤트를 처리했다. - 분석 결과, 의심스러운 행동은 세션 시작 시점이 아니라 **세션 중간에 발생하는 경우가 많았다**. - 한 세션이 인간 행동에서 에이전트 행동으로, 다시 인간 행동으로 바뀌는 사례도 확인됐다. - 따라서 무조건 봇을 차단하기보다 다음 요소를 기준으로 분류해야 한다. - 트래픽의 사용 목적 - 요청의 의도 - 접근하는 데이터의 종류와 사용 방식 - 이 같은 하이브리드 트래픽을 정상적인 사용자 흐름과 구분하려면, 세분화된 봇·에이전트 분류 체계가 필요하며 BotBase 개편의 배경도 여기에 있다. ## Precursor Trace와 행동 신호 - **Precursor Trace**는 Precursor 탐지 방식 일부를 체험할 수 있는 인터랙티브 데모다. - 커서 움직임을 분석해 다음과 같은 특징을 보여준다. - 움직임의 가속과 감속 - 이동 중 수정이나 보정 - 커서 이동의 리듬과 질감 - 사람은 무의식적으로 이러한 불규칙성을 보이지만, 자동화 프로그램이 이를 여러 페이지와 긴 시간 동안 정확히 재현하기는 어렵다. ## 적응형 인텔리전스 - Cloudflare는 자동화 여부를 단순한 이진값으로만 판단하지 않고, 요청에 대한 평가 결과를 여러 단계로 구분하는 **Adaptive Intelligence**를 준비하고 있다. - 제공된 글의 본문은 이 기능의 구체적인 평가 단계와 출시 내용이 이어지기 전에 끝나 있어, 세부 사항은 확인할 수 없다. 사이트 운영자는 CAPTCHA 같은 단발성 방어책에만 의존하기보다 세션 전체의 행동, 봇의 신원 공개, 목적과 데이터 사용 방식을 함께 평가하는 것이 좋다. 정상적인 자동화는 투명성과 신뢰를 바탕으로 허용하고, 신뢰를 악용하거나 세션 중간에 비정상 행동을 보이는 트래픽은 지속적으로 재평가하는 접근이 적절하다.

cloudflare

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

cloudflare

캐시 응답 규칙 소개 (새 탭에서 열림)

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

discord

Discord 음성을 엣지로 이전한 방법 (새 탭에서 열림)

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

cloudflare

AI 시대를 위해 캐시를 재고하는 이유 (새 탭에서 열림)

AI 트래픽의 급격한 증가는 인간 사용자의 행동 패턴을 기반으로 설계된 기존 CDN 캐시 아키텍처에 큰 도전 과제를 던지고 있습니다. AI 크롤러와 에이전트는 일반적인 인간 사용자와 달리 웹사이트 전체를 순차적으로 스캔하거나 방대한 양의 '롱테일(비인기)' 콘텐츠를 집중적으로 요청하며, 이는 기존 캐시 적중률을 떨어뜨리고 원본 서버의 부하를 가중시키는 결과를 초래합니다. Cloudflare는 이러한 AI 시대의 독특한 데이터 접근 패턴에 대응하기 위해 CDN 캐시 설계의 근본적인 재검토가 필요하다고 주장합니다. ### AI 트래픽과 인간 트래픽의 차이점 * **높은 고유 URL 요청 비율:** AI 에이전트는 정보를 정제하고 정확도를 높이기 위해 반복적인 루핑(looping)을 수행하며, 이 과정에서 요청의 70~100%가 중복되지 않는 고유 URL로 구성됩니다. * **콘텐츠 접근의 광범위성:** 인기 페이지에 집중하는 인간과 달리, AI는 훈련 데이터 수집이나 검색 증강 생성(RAG)을 위해 기술 문서, 이미지, 블로그 등 웹사이트의 거의 모든 콘텐츠를 훑어갑니다. * **크롤링 비효율성:** AI 크롤러는 브라우저 측 캐싱이나 세션 관리를 제대로 활용하지 않으며, 독립적인 인스턴스를 여러 개 실행하여 동일한 콘텐츠를 중복 요청하거나 잘못된 URL 처리로 인해 많은 404 오류를 발생시키기도 합니다. ### 기존 캐시 알고리즘(LRU)의 한계와 영향 * **캐시 오염(Cache Churn):** 대규모 AI 스캔이 발생하면 인간 사용자가 자주 찾는 인기 콘텐츠가 캐시에서 밀려나고, 그 자리를 AI가 일회성으로 긁어가는 비인기 콘텐츠가 차지하게 됩니다. * **캐시 적중률(Hit Rate) 하락:** 가장 오래전에 사용된 데이터를 먼저 삭제하는 LRU(Least Recently Used) 알고리즘은 AI의 공격적인 스캔 패턴 아래에서 효율이 급격히 떨어지며, 이는 곧 캐시 미스 증가로 이어집니다. * **원본 서버 및 비용 부담:** 캐시 미스가 발생하면 모든 요청이 원본(Origin) 서버로 직접 전달되어 서버 부하가 커지고, 데이터 전송에 따른 이그레스(Egress) 비용이 상승하며 응답 속도는 느려집니다. ### AI 시대의 웹 운영을 위한 새로운 방향 * **운영자의 이분법적 선택:** 웹 운영자는 이제 자원 보호를 위해 AI 크롤러를 차단할 것인지, 아니면 AI 모델의 최신 정보를 유지하기 위해 이들을 수용할 것인지 선택해야 하는 상황에 놓여 있습니다. * **차세대 캐시 전략의 필요성:** 기존의 단순한 프리페칭(Prefetching)이나 캐시 만료 정책은 더 이상 유효하지 않으며, AI 에이전트의 반복적인 루핑과 롱테일 접근 패턴을 반영한 지능적인 캐시 설계가 필수적입니다. * **연구 및 협업:** Cloudflare는 ETH Zurich 연구진과 협력하여 AI 트래픽 패턴을 모델링하고, 이를 기반으로 CDN이 AI 시대에 어떻게 적응해야 할지에 대한 기술적 방향성을 제시하고 있습니다. 웹 운영자는 자신의 콘텐츠가 AI 검색 결과나 학습 데이터에 포함되기를 원한다면, AI 트래픽의 특성을 이해하고 이를 효율적으로 처리할 수 있는 도구를 도입해야 합니다. 단순히 트래픽을 차단하는 것을 넘어, 'Pay per crawl'과 같은 수익화 모델이나 AI 전용 캐시 계층을 고려하는 등 변화하는 환경에 맞춘 유연한 대응 전략이 권장됩니다.

discord

디스코드 패치 노트: (새 탭에서 열림)

Discord의 2025년 12월 8일 패치는 대용량 업로드 안정성, 앱 성능, 동영상 로딩 속도, 설정 화면 사용성을 크게 개선한 업데이트다. 미디어 업로드 재시도 로직을 Rust로 재작성하고 중단된 업로드 재개를 지원했으며, CDN 설정 변경으로 동영상 임베드 시작 지연도 크게 줄였다. 이와 함께 Desktop·iOS·Android 전반에서 수많은 UI 오류와 검색, 권한, 이벤트, 채팅 관련 버그를 수정했다. ## 업로드 성능과 안정성 개선 - 미디어 업로드 클라이언트를 리팩터링했다. - 업로드 중단 시 처음부터 다시 시작하지 않고 이어서 진행할 수 있는 **파일 업로드 재개 기능**을 추가했다. - Rust로 작성한 새로운 재시도 로직을 적용해 전체 업로드 지연 시간이 약 15% 감소했다. - iOS: 약 21% 개선 - Android: 약 10% 개선 - 대용량 파일이나 불안정한 네트워크 환경에서 업로드 성공률과 체감 속도가 향상될 것으로 보인다. ## 동영상 임베드 로딩 개선 - CDN 설정을 변경해 동영상 임베드의 시작 속도를 크게 개선했다. - P90 지연 시간이 600ms에서 275ms로 줄어 약 54% 개선됐다. - P95 지연 시간은 1,250ms에서 658ms로 줄어 약 47% 개선됐다. - 일부 동영상이 재생까지 최대 40초 걸리던 비정상적인 사례도 해결했다. ## 설정 화면과 플랫폼 업데이트 - Desktop 사용자 설정 화면을 새롭게 디자인했다. - 디자인 체계를 정리해 원하는 설정을 더 쉽게 찾을 수 있도록 했으며, 내부 지표상 개선 효과가 확인됐다. - 모바일 앱의 React Native 버전을 0.78에서 0.81.4로 업데이트했다. - Desktop 앱의 Electron 버전을 37로 업그레이드했다. ## 검색·권한·이벤트 관련 수정 - Server Hub에서 검색 성능을 개선했으며, 50개 이상의 서버가 연결된 허브에서 효과가 특히 크다. - 서버 닉네임 변경 권한이 없을 때 오류 메시지가 중복 표시되던 문제를 수정했다. - Student Hubs 검색에서 잘못된 접근 권한 오류가 나타나던 문제를 해결했다. - 설정에서 특정 문자열을 검색했을 때 카테고리가 비어 보이던 문제를 수정했다. - Upcoming Events 배너를 닫을 수 있게 했다. - 이벤트 초대에서 참여 버튼이 작동하지 않거나, 사용자 지정 장소를 포함한 이벤트 공유 모달이 제대로 동작하지 않던 문제를 해결했다. - 이벤트 팝업의 여러 액션 버튼 정렬과 초대 문구를 개선했다. ## Desktop 및 모바일 UI 버그 수정 - Linux에서 제목 표시줄이 두 개 나타나던 문제를 해결했다. - macOS 창 제어 버튼의 정렬을 수정했다. - 서버 목록의 스크롤바, 폴더의 잘못된 스크롤바 및 빈 공간 표시 문제를 플랫폼별로 해결했다. - 서버 목록에 unread 표시 요소와 관련된 흰색 픽셀이 나타나던 문제를 수정했다. - 친구 요청의 Accept/Deny 버튼 간격을 조정했다. - 서버 초대 모달, 검색창, 프로필 미리보기, Nitro 설정 화면의 디자인 불일치를 개선했다. - 이모지 슬롯이 음수로 표시되거나, Emoji Studio의 이미지 초기화 버튼이 이미지를 중앙에 배치하지 못하던 문제를 해결했다. - Avatar Decoration과 Nameplate 미리보기 및 기본값 사용 버튼의 오류를 수정했다. - Android·iOS에서 서버별 Nameplate의 “None” 옵션을 선택할 수 없던 문제를 해결했다. - 설정과 프로필 관련 일부 문자열의 현지화 문제를 수정했다. ## 채팅과 메시지 기능 개선 - Desktop에서 여러 줄 메시지를 입력할 때 Message Forward 화면의 입력 영역이 시각적으로 이동하던 문제를 수정했다. - 스포일러를 공개하기 전 타임스탬프가 제대로 표시되지 않던 문제를 해결했다. - iOS에서 메시지 스와이프 시 행 높이가 잘못 계산되거나 답글 이동이 실패하던 문제를 수정했다. - 스레드 미리보기가 있을 때 스크롤바를 조작할 수 없던 문제를 해결했다. - Android 코드 블록이 고정폭 글꼴로 표시되지 않던 문제를 수정했다. - Android의 채널 음소거 화면 헤더 정렬과 스티커 전송 후 Picker가 닫히지 않는 문제를 개선했다. - Emoji Picker에서 서버 간 이동이 되지 않던 문제를 해결했다. - iOS에서 포럼 게시글에 답글을 스와이프하거나, 메시지와 스레드를 연결하는 시각적 요소가 표시되지 않던 문제를 수정했다. - Inbox에서 스레드 생성 메시지로 이동할 수 없던 문제를 해결했다. - 포럼 게시물 검색창의 불필요한 여백을 줄였다. 이번 패치는 새로운 대형 기능을 추가하기보다, 업로드와 동영상처럼 체감 효과가 큰 성능 영역을 개선하고 Desktop·모바일 전반의 세부 버그를 광범위하게 정리한 업데이트다. 특히 대용량 파일을 자주 올리거나 모바일에서 Discord를 사용하는 이용자는 업로드 재개와 응답 속도 개선을 가장 크게 체감할 가능성이 높다.

slack

E2E 파이프라인 (새 탭에서 열림)

Slack은 E2E 테스트 파이프라인에서 프론트엔드 변경이 없어도 매번 프론트엔드를 빌드하는 비효율을 발견했다. Git 변경 감지와 기존 빌드 산출물 재사용을 도입해 프론트엔드 빌드 횟수를 60% 줄이고, 전체 파이프라인 시간을 약 10분에서 2분으로 단축했다. 그 결과 개발자 대기 시간과 AWS S3 저장 비용을 줄였을 뿐 아니라 E2E 테스트의 플래키함도 개선됐다. ## 프론트엔드 빌드가 병목이 된 이유 - Slack의 대규모 모노레포에서는 병합 전 전체 스택을 검증하기 위해 E2E 테스트를 실행했다. - 기존 파이프라인은 다음 순서로 동작했다. - 코드 변경 후 브랜치 푸시 - 프론트엔드 빌드: 약 5분 - QA 환경 배포 - 200개 이상의 E2E 테스트: 약 5분 - 프론트엔드와 무관한 백엔드·데이터베이스·서비스 변경에도 프론트엔드를 새로 빌드했다. - 매주 수천 번의 빌드가 발생했고, 빌드 하나당 AWS S3에 약 1GB의 데이터가 저장됐다. - 이 중 절반가량은 실제 프론트엔드 변경이 없어 중복 산출물에 해당했다. ## Git diff를 이용한 조건부 빌드 - 현재 브랜치와 `main`의 최신 공통 커밋을 기준으로 `git diff`의 3-dot 표기법을 사용했다. - 변경 내역에 프론트엔드 관련 파일이 포함된 경우에만 새 프론트엔드 빌드 작업을 실행했다. - 프론트엔드 변경이 없으면 빌드를 완전히 건너뛰고 기존 산출물을 사용했다. - 추적 파일이 10만 개가 넘는 모노레포에서도 Git의 변경 감지는 약 몇 초 안에 완료됐다. ## 기존 빌드 산출물과 내부 CDN 재사용 - 새 빌드가 필요하지 않은 경우 AWS S3에 저장된 기존 프론트엔드 빌드를 탐색했다. - 현재 Production에서 사용 중인 비교적 최신 빌드를 선택해 테스트에 활용했다. - 내부 CDN이 해당 프론트엔드 정적 파일을 제공하도록 구성했다. - 이를 통해 PR마다 새 빌드를 생성하지 않으면서도 최신 상태에 가까운 프론트엔드 자산으로 E2E 테스트를 수행했다. ## 대규모 환경에서의 자산 관리 - 수백 개의 PR이 매일 병합되므로 재사용할 빌드가 충분히 최신인지 판단해야 했다. - S3의 파일명 규칙과 저장 구조를 활용해 빌드 산출물의 최신성, 일관성, 검색 성능을 관리했다. - 변경 여부 판단과 적절한 빌드 산출물 탐색을 평균 3초 이내에 처리했다. - 결과적으로 전체 테스트 흐름에서 프론트엔드 빌드 단계를 효율적으로 제거할 수 있었다. ## 성능과 비용 개선 - 불필요한 프론트엔드 빌드 빈도를 60% 줄였다. - AWS S3 중복 저장 데이터를 매월 수 테라바이트 규모로 절감했다. - 클라우드 컴퓨팅 비용과 개발자의 파이프라인 대기 시간을 줄였다. - 기존 Webpack 개선으로 평균 빌드 시간이 10분에서 5분으로 줄어든 데 이어, 이번 최적화로 약 2분까지 단축했다. - 전체 E2E 파이프라인 시간은 평균 10분에서 2분으로 감소했다. ## 예상하지 못한 효과 - 프론트엔드 빌드 과정과 자산 전달 방식이 단순해지고 일관되면서 E2E 테스트의 플래키함이 감소했다. - 월별 측정 결과 테스트 실패의 불안정성이 가장 낮은 수준까지 개선됐다. - 오래된 여러 시스템의 레거시 코드를 조사하는 과정에서 기존 동작을 재발견하고 향후 개선 과제도 발굴했다. ## 실용적인 결론 CI/CD 파이프라인에서는 모든 단계를 무조건 실행하기보다 실제 변경 범위와 필요한 검증 수준을 기준으로 조건부 실행을 설계하는 것이 효과적이다. 특히 Git 변경 감지, 빌드 산출물 캐싱, CDN 재사용을 결합하면 빌드 시간과 클라우드 비용을 동시에 줄일 수 있다.