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

에이전트 위크 동안 출시한 모든 것

에이전트는 AI 기능을 넘어 사람과 소프트웨어가 인터넷과 상호작용하는 방식을 바꾸는 새로운 소프트웨어 계층이다. Cloudflare는 Agents Week를 통해 실행 환경, 개발 생명주기, 신원·보안, 에이전트 친화적 인터넷, 관측·검색·AI 인프라를 하나의 플랫폼으로 통합하는 방향을 제시했다. 궁극적으로는 인간과 에이전트가 충돌하지 않고 협력하는 “Agentic Internet”을 구축하는 것이 목표다. ### 에이전트를 위한 실행 환경과 인프라 - 에이전트에는 단순한 컨테이너가 아니라 작업에 맞는 컴퓨터 환경이 필요하다는 관점에서 `@cloudflare/computer` 런타임을 소개했다. - Python과 JavaScript Workers 간 RPC 통신을 지원해 혼합 언어 프로젝트를 쉽게 만들 수 있도록 했다. - Kimi, GLM 같은 대규모 모델을 더 작고 빠르며 안전하게 운영하는 방법을 제시했다. - Billable Usage API로 셀프서비스 제품의 사용량과 비용을 프로그램 방식으로 확인할 수 있다. - Workers와 Containers에서 인바운드 TCP 및 gRPC를 지원해 음성 AI 백엔드와 실시간 에이전트 구축이 가능해졌다. ### 프로토타입에서 운영까지: Agent Development Lifecycle - 기존 SDLC를 확장한 ADLC(Agent Development Lifecycle)를 제안했다. - Cloudflare Agents는 에이전트 실행 과정을 실시간으로 관찰하고, 추적·재생하며, 운영 중 사람의 승인을 받을 수 있게 한다. - 로컬 개발 환경에서도 분산 추적을 활용해 에이전트가 Workers 문제를 직접 찾고 디버깅할 수 있다. - Cloudflare Wallets는 에이전트가 안전하게 거래를 수행할 수 있는 프로그래밍 가능한 지갑을 제공한다. - 코드로 정의하는 CI/CD 파이프라인과 실패를 분석하고 수정안을 검토 단계로 보내는 에이전트를 소개했다. - AI를 활용해 코드 표준과 개발 프로세스를 자동으로 점검하고, Astro의 GitHub 이슈를 분석·분류·라우팅해 유지보수 부담을 줄인 사례도 공유했다. ### 에이전트의 신원과 보안 통제 - Zero Trust를 사용자와 기기뿐 아니라 에이전트에도 적용하는 Agent Access Model을 제시했다. - 에이전트가 사용자를 대신해 리소스와 서비스에 접근할 때, 주체와 권한을 명확히 식별하고 통제하는 것이 핵심이다. - Cloudflare OS는 내부 업무와 시스템에 AI를 통합하되 보안과 감독을 유지하도록 설계된 오픈 플랫폼이다. - 신원 기반 분석으로 AI 활동을 실제 사용자와 시스템에 연결해 이상 행동이나 비용 급증을 감지할 수 있다. - WriteGuard는 MCP 서버의 도구 호출을 세밀하게 제한해 에이전트의 위험한 변경이나 원치 않는 작업을 줄인다. ### 사람이 통제하는 Agentic Internet - Agentic Internet은 웹사이트와 콘텐츠가 에이전트에게 읽히고(readable), 발견되며(discoverable), 호출되고(callable), 결제될 수 있어야 한다는 모델이다. - WebMCP를 통해 웹사이트와 웹 애플리케이션에 에이전트용 인터페이스를 쉽게 추가할 수 있다. - 기존 SEO를 넘어 에이전트가 콘텐츠를 이해하고 답변에 활용하도록 만드는 AEO(Answer Engine Optimization)의 필요성을 강조했다. - Kitesurf는 픽셀 단위의 브라우저 렌더링보다 낮은 메모리·CPU 사용량을 우선한 에이전트 전용 브라우저다. - MCPv2는 MCP 기반 애플리케이션의 배포와 확장을 단순화하는 차세대 규격으로 소개됐다. - Cloudflare AI Search는 파일이나 웹사이트를 한 번의 명령으로 에이전트가 사용할 수 있는 검색 엔진으로 변환한다. ### 실제 인터넷에서의 신뢰와 AI 운영 - 봇을 무조건 악성으로 보거나 사람을 항상 신뢰하는 방식에서 벗어나, 행동을 지속적으로 평가하는 신뢰 모델을 제안했다. - Workers AI와 AI Gateway를 하나의 AI 제어 평면으로 통합해 단일 바인딩, 지갑, 대시보드에서 다양한 AI 모델을 호출하도록 했다. - 향후에는 모델 중심 라우팅을 통해 목적과 비용, 성능에 맞는 모델을 자동 선택할 수 있게 될 전망이다. - Cloudflare Ambassadors와 Community Engineers 프로그램, 2년간 추가 100만 달러 규모의 오픈소스 지원 계획을 발표했다. - Radar Researcher는 자연어 질문을 인터랙티브 차트로 변환해 인터넷 데이터를 탐색하도록 돕는다. Cloudflare가 제시한 Agent Cloud는 실행 계층, ADLC 기반 개발 도구, 신원과 보안 제어, 에이전트 친화적 웹 표준, 관측·검색·AI 운영 도구를 함께 제공하는 형태로 구체화되고 있다. 에이전트를 도입할 때는 모델 성능뿐 아니라 권한 관리, 실행 추적, 사람의 승인 절차, 비용 가시성, 웹 접근 규칙까지 함께 설계하는 것이 실용적인 출발점이다.

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

distributed-tracingAI 에이전트CI/CD모델 컨텍스트 프로토콜+4

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

대규모 서비스 토폴로지 구축: 아키텍처, 도전 과제, 그리고 얻은 교훈

넷플릭스는 장애 대응과 변경 영향 분석을 위해 실시간 서비스 의존성 지도를 구축했으며, 이를 위해 배치가 아닌 스트리밍 중심 아키텍처를 선택했다. 시스템은 eBPF 네트워크 흐름, IPC 메트릭, 분산 추적 데이터를 물리적으로 분리된 계층에 저장하고, 필요할 때 통합해 제공한다. 대규모 트래픽에서도 안정적으로 동작하기 위해 백프레셔와 분산 집계 파이프라인을 적용했으며, 약간의 지연을 허용하는 대신 데이터 손실과 시스템 장애를 방지했다. ## 실시간 서비스 토폴로지가 필요한 이유 - 기존의 시간별·일별 배치 방식은 데이터가 생성될 때 이미 오래된 상태가 된다. - 장애 대응 시 한 시간 전의 의존성 지도는 현재의 장애 원인과 영향 범위를 정확히 보여주기 어렵다. - 실시간 변경 검증과 장애 분석을 위해 지속적인 데이터 수집과 갱신이 필요하다. - 넷플릭스의 시스템은 일반적으로 수십 분 이내에 토폴로지 정보를 갱신하는 것을 목표로 한다. ## 스트리밍 중심 아키텍처 - 여러 리전의 Kafka 스트림에서 네트워크 흐름 데이터를 지속적으로 수집한다. - IPC 메트릭은 Server-Sent Events(SSE) 형태로 전달하고, 반응형 파이프라인에서 처리한다. - 배치 처리처럼 완전한 스냅샷을 기다리지 않고, 데이터가 도착하는 즉시 토폴로지를 갱신한다. - 대규모 트래픽을 처리하면서도 처리 지연이 누적되지 않도록 스트리밍 처리와 부하 제어를 함께 설계했다. ## 백프레셔를 통한 안정적인 부하 제어 - 단순한 무제한 큐는 트래픽이 급증할 때 메모리를 고갈시키고 인스턴스 장애를 일으킬 수 있다. - 버퍼가 가득 찼을 때 데이터를 버리는 방식은 연결 정보가 사라져 토폴로지가 불완전해진다. - 배치 방식은 데이터를 보존할 수 있지만, 장애가 끝난 뒤에야 결과를 확인하게 될 수 있다. - 백프레셔는 하위 단계의 처리 속도에 맞춰 상위 단계가 자동으로 속도를 줄이는 방식이다. - 그래프 데이터베이스가 느려지면 Stage 2가 Stage 1에 감속을 요청한다. - 감속 신호는 Kafka 소비자까지 전파된다. - Kafka에 데이터가 남아 있으므로 처리 능력이 회복된 뒤 이어서 처리할 수 있다. - GC 일시정지, 외부 저장소 지연, 트래픽 급증 상황에서도 시스템이 중단되거나 데이터를 대량으로 버리지 않고 점진적으로 느려진다. - 실시간성이 몇 초 또는 몇 분 늦어지는 대신, 시간 단위로 오래된 데이터나 누락된 토폴로지를 피할 수 있다. - 반응형 스트림은 전통적인 동기식 처리보다 이해하고 운영하기 어렵지만, 넷플릭스 규모에서는 안정성을 위한 필수 요소로 평가된다. ## 데이터 소스별 물리적 토폴로지 계층 넷플릭스는 서로 다른 특성을 가진 데이터를 하나의 저장소에 억지로 통합하지 않고, 세 개의 계층으로 분리했다. - **네트워크 계층** - eBPF 기반 네트워크 흐름 로그를 그래프 데이터베이스에 저장한다. - 서비스 간 연결을 폭넓게 포착하지만 애플리케이션 수준의 상세한 맥락은 부족하다. - **IPC 계층** - 애플리케이션 메트릭을 별도의 그래프 데이터베이스에 저장한다. - 엔드포인트 정보가 풍부하지만 계측된 서비스만 포함한다. - **트레이싱 계층** - 분산 추적 데이터를 Parquet 기반 컬럼형 저장소에 저장한다. - 실제 요청 경로를 보여주지만 샘플링으로 인해 전체 트래픽을 대표하지 않을 수 있다. - 각 계층을 물리적으로 분리하면 처리량, 쿼리 패턴, 데이터 발전 주기에 맞춰 독립적으로 최적화할 수 있다. - 쿼리 시에는 필요한 저장소에 병렬 질의한 뒤 결과를 병합해 통합된 서비스 뷰를 제공한다. ## 네트워크 중간 장비를 해결하는 분산 집계 파이프라인 네트워크 흐름 로그는 실제 서비스 의존성이 아니라 개별 네트워크 홉만 보여주는 문제가 있다. - 실제 경로가 `App A → 로드 밸런서 → App B`라면 흐름 로그에는 두 개의 별도 연결로 기록된다. - 이 데이터를 그대로 시각화하면 서비스 대신 로드 밸런서, NAT 게이트웨이, API 게이트웨이, 프록시 같은 인프라 컴포넌트가 중심에 나타난다. - 따라서 여러 홉을 분석해 논리적인 `App A → App B` 의존성으로 재구성해야 한다. - 이를 위해 네트워크 계층 수집은 세 단계의 분산 집계 파이프라인으로 구성된다. ### Stage 1: 초기 집계 - 네 개 리전의 Kafka에서 흐름 로그를 소비한다. - 잘못된 흐름 로그를 필터링한다. - 5분 단위 시간 창으로 데이터를 묶는다. - 각 시간 창마다 초기 집계 객체를 생성한다. - 일관성 해싱을 사용해 집계 대상을 분산한다. - 생성된 집계 결과를 SSE를 통해 Stage 2로 스트리밍한다. - 이 단계에서는 중간 장비가 포함된 네트워크 홉을 식별하지만, 최종적인 서비스 간 연결은 아직 확정하지 않는다. ## 대규모 분산 시스템에서 얻은 설계 교훈 - 실시간 처리는 단순히 빠르게 처리하는 문제가 아니라, 느려지는 상황에서도 시스템을 무너지지 않게 만드는 문제다. - 데이터 손실보다 일시적인 지연을 선택하는 것이 서비스 토폴로지와 장애 분석에는 더 적합할 수 있다. - 서로 다른 데이터의 특성이 뚜렷하다면 저장소와 처리 계층을 분리하고, 조회 시 통합하는 편이 확장성과 독립적인 최적화에 유리하다. - 로컬 환경에서 정상 동작하는 구현도 운영 환경에서는 Kafka 지연, 메모리 부족, 트래픽 편중, GC 비용 등으로 쉽게 한계에 도달할 수 있다. - 따라서 대규모 시스템은 초기 설계뿐 아니라 부하 상황에서의 관찰, 병목 측정, 단계별 최적화 방법론이 중요하다. 실용적으로는 스트리밍 파이프라인을 구축할 때 무제한 버퍼나 무조건적인 데이터 삭제보다 백프레셔를 우선 고려하는 것이 좋다. 또한 서로 다른 품질과 용도를 가진 데이터 소스를 하나의 모델로 통합하기보다, 각 소스에 맞는 저장 계층을 유지하고 조회 단계에서 결합하는 방식이 운영 유연성을 높인다.

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

distributed-tracingApache Kafkaebpfgraph-database+4

discord·2026년 3월 4일원문

디스코드의 엘릭 (새 탭에서 열림)

Discord는 Elixir의 강력한 동시성 메커니즘을 활용하여 각 서버(길드)를 독립적으로 운영함으로써 수억 명의 사용자에게 실시간에 가까운 채팅 경험을 제공합니다. 그러나 급격한 트래픽 증가로 시스템 자정 능력이 한계에 도달할 때, 기존의 메트릭이나 자체 개발한 메모리 기반 분석 도구만으로는 복잡한 성능 병목 현상과 사용자 경험의 실질적인 저하 원인을 파악하는 데 한계가 있었습니다. 이를 해결하기 위해 Discord는 Elixir 환경에 맞춤화된 분산 추적(Distributed Tracing) 시스템을 직접 구축하여 서비스 중단 없이 시스템 전반의 가시성을 확보하는 데 성공했습니다. **기존 관측 도구의 한계와 실무적 어려움** * **지표와 로그의 한계:** 대시보드는 엔진 온도계처럼 시스템의 상태를 보여주지만, 온도가 높을 때 사용자가 느끼는 실제 주행 경험(지연 시간의 체감 등)이나 구체적인 결과까지는 설명해주지 못합니다. * **길드 타이밍(Guild Timings) 도구:** 길드별 작업 소요 시간을 분 단위로 메모리에 기록하는 커스텀 도구를 사용해왔으나, 데이터 양이 너무 방대하여 대형 길드를 제외하고는 데이터를 빠르게 순환(Rotation)시켜야 하므로 과거 이력 분석이 어렵습니다. * **다운스트림 효과 파악 불가:** 기존 도구들은 개별 작업의 소요 시간은 보여주지만, 해당 작업이 연쇄적으로 일으키는 다운스트림 서비스의 영향과 전체적인 실행 흐름을 시각화하지 못하는 단점이 있었습니다. **Elixir 환경에서의 분산 추적 도입 과정** * **분산 추적(APM)의 필요성:** 작업의 구성 요소별 소요 시간을 한눈에 파악할 수 있는 분산 추적 기술을 통해 시스템 내부의 복잡한 상호작용을 투명하게 확인하고자 했습니다. * **기술적 난관:** 일반적인 추적 도구는 HTTP 헤더와 같은 메타데이터 레이어를 통해 추적 정보를 전달하지만, Elixir의 기본 통신 도구들에는 이러한 메타데이터 레이어가 내장되어 있지 않았습니다. * **커스텀 메타데이터 레이어 구축:** 서비스 간 통신 방식에 추적 정보를 함께 전달할 수 있는 자체 메타데이터 전달 메커니즘을 설계하여 문제를 해결했습니다. * **무중단 통합:** 서비스 간의 통신 방식을 근본적으로 변경하는 작업임에도 불구하고, 철저한 설계를 통해 시스템 가동 중단(Downtime) 없이 새로운 추적 시스템을 성공적으로 통합했습니다. 복잡한 분산 시스템에서 단순한 성능 지표만으로는 문제의 근본 원인을 파악하기 어렵습니다. 특히 Elixir와 같이 특수한 통신 구조를 가진 환경에서는 표준적인 APM 도구를 그대로 적용하기보다, 시스템의 특성에 맞춰 메타데이터 전달 계층을 직접 구현함으로써 인프라 전반의 흐름을 명확히 파악할 수 있는 분석 환경을 구축하는 것이 중요합니다.

distributed-tracing데이터베이스 설계애플리케이션 성능 모니터링elixir+3

toss·2025년 11월 13일원문

100년 가는 프론트엔드 코드, SDK (새 탭에서 열림)

토스페이먼츠는 결제 연동의 복잡성을 해결하기 위해 SDK를 제공하고 있으며, 최근 V1의 한계를 극복하고 안정성과 확장성을 극대화한 V2 SDK를 구축했습니다. 가맹점의 다양한 런타임 환경과 예측 불가능한 요구사항에 대응하기 위해 단순한 기능 구현을 넘어 체계적인 아키텍처와 모니터링 시스템을 도입했습니다. 결과적으로 개발자에게는 쉬운 연동 경험을, 비즈니스에는 견고한 신뢰성을 제공하는 결제 생태계를 완성했습니다. **SDK 개발의 특수성과 V1의 한계** * **환경의 의존성:** SDK는 가맹점의 코드 내에서 실행되므로, 가맹점의 호출 빈도나 네트워크 상태에 직접적인 영향을 받습니다. 일례로 사용량 분석을 위해 추가한 로그 코드가 특정 가맹점의 잦은 호출과 맞물려 네트워크 병목 현상을 일으키고 서비스 전체를 다운시키는 사례가 발생했습니다. * **런타임 예측 불가능성:** 가맹점에서 잘못된 데이터 타입(예: String 대신 Number)을 전달할 경우 `startsWith` 같은 표준 메서드에서 에러가 발생하는 등, 일반적인 프론트엔드 개발보다 훨씬 방어적인 코딩이 요구됩니다. * **커뮤니케이션의 접점:** SDK는 단순히 API를 호출하는 도구가 아니라 가맹점 개발자와 만나는 기술적 창구이며, 가맹점의 수많은 커스텀 요구사항을 수용해야 하는 복잡성을 안고 있습니다. **안정성 확보를 위한 테스트와 모니터링** * **촘촘한 테스트 체계:** 로직 검증을 위한 300개 이상의 단위 테스트와 다양한 유즈케이스를 반영한 500개 이상의 E2E 통합 테스트를 통해 코드 수준의 안정성을 확보했습니다. * **Global Trace ID:** 프론트엔드부터 백엔드까지 결제 전 과정을 하나의 식별자로 추적하는 체계를 도입하여, 장애 발생 시 시스템 레이어 전체를 쉽게 파악할 수 있도록 했습니다. * **모니터링 CLI:** 배포 전후의 결제 성공률을 가맹점 및 런타임 환경(OS, 브라우저, 웹뷰 등)별로 비교 분석하는 자체 도구를 개발했습니다. 이를 통해 특정 환경에서 발생하는 결제 중단 현상을 실시간으로 탐지하고 즉각 대응합니다. **확장성을 위한 레이어드 아키텍처** * **조립 가능한 구조:** 특정 가맹점만을 위한 예외 처리가 `if`문으로 산재되어 코드 복잡도가 올라가는 문제를 해결하기 위해, 기능을 레고 블록처럼 독립적으로 구성했습니다. * **3계층 분리:** "변경의 원인"을 기준으로 코드의 경계를 명확히 나누어 관리합니다. * **Public Interface Layer:** 가맹점과 약속한 인터페이스를 검증하고 도메인 언어로 번역하는 역할 * **Domain Layer:** 핵심 비즈니스 로직과 결제 정책을 담당하는 중심부 * **External Service Layer:** 서버 API나 Web API 등 외부 의존성과의 통신을 담당하는 계층 * **관심사 격리:** 이러한 계층화를 통해 가맹점별 커스텀 요구사항이 추가되더라도 기존의 핵심 로직에 영향을 주지 않고 특정 블록만 교체하거나 확장할 수 있는 유연성을 확보했습니다. 성공적인 SDK 개발을 위해서는 단순히 편리한 기능을 제공하는 것을 넘어, 타사의 코드 환경에서도 견고하게 동작할 수 있는 방어적인 설계와 문제 발생 시 즉시 원인을 파악할 수 있는 관측성(Observability) 확보가 필수적입니다. 가맹점별 특이 케이스를 코드 전반에 흩뿌리기보다는, 명확한 레이어 구분을 통해 비즈니스 로직과 커스텀 로직을 분리하는 설계 원칙을 권장합니다.

distributed-tracing옵저버빌리티TypeScriptsoftware-architecture+3