AI 에이전트가 실제 Stripe (새 탭에서 열림)

최근 LLM은 코드 스니펫 작성을 넘어 파일 단위의 리팩토링까지 수행할 정도로 발전했으나, 실제 소프트웨어 프로젝트를 자율적으로 관리하는 능력은 여전히 검증이 필요한 영역입니다. Stripe는 에이전트가 100%의 정확도를 요구하는 결제 통합 작업을 완수할 수 있는지 확인하기 위해, 실제 운영 환경과 유사한 11개의 벤치마크 환경을 구축하여 성능을 측정했습니다. 연구 결과, 최신 모델들은 UI 탐색 및 복잡한 API 구성에서 기대 이상의 성과를 보였으나, 모호한 상황에서의 의사결정이나 완벽한 엔드 투 엔드 검증에서는 여전히 한계를 드러냈습니다. **Stripe 통합 벤치마크의 설계와 구조** * **다층적 환경 구축**: 실제 비즈니스 시나리오를 반영하여 백엔드 전용 작업, 풀스택 작업, 그리고 특정 기능(Checkout, Billing 등)을 깊게 파고드는 'Gym' 문제 세트로 구성된 11개의 환경을 설계했습니다. * **에이전트 실행 도구**: 모든 모델에 일관된 환경을 제공하기 위해 'goose' 기반의 하네스를 사용했으며, MCP(Model Context Protocol) 서버를 통해 터미널, 브라우저, Stripe 전용 검색 도구에 대한 접근 권한을 부여했습니다. * **결과 검증 시스템(Graders)**: 단순히 코드의 형태를 보는 것이 아니라, API 호출 및 자동화된 UI 테스트를 통해 소프트웨어의 동작을 결정론적으로 검증하며, 생성된 Stripe API 객체의 상태까지 직접 확인하여 정확도를 측정합니다. **에이전트의 뛰어난 실전 적응력과 성과** * **기대 이상의 풀스택 수행 능력**: 모델들은 단순히 코드를 작성하는 데 그치지 않고 브라우저를 직접 조작하며 실시간 이슈를 디버깅하는 능력을 보여주었으며, Claude 4.5와 GPT-5.2 같은 모델들은 특정 영역에서 70~90% 이상의 높은 평균 점수를 기록했습니다. * **복잡한 UI 역공학**: 'Checkout Gym' 과제에서 에이전트들은 기존 UI를 분석하여 제품 ID, 수량, 세금 설정 등 20개 이상의 매개변수를 역으로 추출해 API 호출로 변환하는 복잡한 추론 과정을 성공적으로 수행했습니다. * **자율적인 자기 검증**: 레거시 UI를 새로운 시스템으로 교체하는 작업에서, 에이전트는 명시적인 지시 없이도 브라우저에서 테스트 결제를 진행하고 Link(Stripe의 디지털 지갑)와 같은 실제 결제 수단을 활용해 동작 여부를 스스로 확인했습니다. **한계점과 향후 과제** * **모호성 처리의 부재**: SDK 업그레이드와 같이 모호한 상황이 주어졌을 때, 에이전트들은 존재하지 않는 데이터를 입력하거나 API 오류(400 Error)가 발생해도 이를 논리적으로 해결하지 못하고 정체되는 현상을 보였습니다. * **엔드 투 엔드 검증의 어려움**: 코드를 생성하는 능력과 사람이 수행하는 수준의 엄격한 검증 및 테스트 사이에는 여전히 간극이 존재하며, 특히 장기적인 프로젝트 관리 능력에서는 추가적인 개선이 필요합니다. **실용적인 제언** 에이전트를 실제 개발 워크플로우에 도입하려는 조직은 단순히 코드 생성 엔진으로서의 성능뿐만 아니라, 에이전트가 터미널과 브라우저를 사용하여 자신의 작업을 스스로 검증할 수 있는 환경을 제공하는 데 집중해야 합니다. 또한, API 문서의 명확성과 모호하지 않은 에러 메시지 제공은 에이전트의 자율적 문제 해결 능력을 극대화하는 핵심 요소가 될 것입니다.

애자일 SASE를 통한 현대 (새 탭에서 열림)

현대 기업 네트워크 환경이 재택근무의 일상화와 AI 에이전트의 등장으로 경계가 없는 시대로 진입함에 따라, 기존의 파편화된 보안 솔루션과 레거시 VPN은 더 이상 유효하지 않은 기술 부채가 되었습니다. 클라우드플레어는 이러한 복잡성을 해결하고 비즈니스 성장을 가속화하기 위해 가볍고 유연한 '애자일 SASE(Agile SASE)' 플랫폼인 Cloudflare One을 제시합니다. 이는 네트워킹과 보안을 단일 글로벌 연결 클라우드로 통합하여 성능 저하 없이 실시간 대응력을 극대화하는 현대적 보안 아키텍처를 지향합니다. ## 기존 SASE의 한계와 애자일 SASE의 정의 * 과거의 보안 방식은 하드웨어 박스와 VPN 농축기에 의존하여 수천 개의 방화벽 규칙과 수동 패치 등 관리하기 어려운 기술 부채를 야기해 왔습니다. * 1세대 SASE 제공업체들은 단순히 기존의 파편화된 구조를 클라우드로 옮겨놓은 것에 불과하여, 데이터 센터 간의 운영 사일로(Silo) 문제를 해결하지 못했습니다. * 애자일 SASE는 전 세계 300개 이상의 도시에 구축된 글로벌 네트워크를 기반으로, 모든 보안 검사를 모든 서버에서 동시에 실행하는 구조를 가집니다. * 데이터가 여러 도구를 순차적으로 거치는 '서비스 체이닝(Service-chaining)' 방식에서 벗어나 '싱글 패스(Single-pass)' 아키텍처를 채택함으로써 보안 프로세스가 비즈니스의 병목이 아닌 추진력이 되도록 설계되었습니다. ## 프로그래밍 가능한 보안 및 통합 가시성 * Cloudflare One은 단순한 보안 솔루션을 넘어 개발자 플랫폼인 Cloudflare Workers와 결합되어 기업이 보안 이벤트를 실시간으로 가로채고 코드로 제어할 수 있는 구성 가능성(Composability)을 제공합니다. * 단순한 '허용/차단' 규칙을 넘어 정교한 자동화 운영이 가능하며, 이는 블랙박스 형태의 기존 레거시 벤더들과 차별화되는 지점입니다. * AI 기술을 역으로 활용해 대량의 보안 데이터에서 유의미한 신호를 추출하고, 사람이 읽을 수 있는 실시간 조치로 전환하는 'AI를 대항하는 AI' 전략을 사용합니다. * 신원 확인 체계 역시 단순 패스워드를 넘어 인간과 장치에 대한 포괄적인 검증 시스템으로 진화시키고 있습니다. ## SASE 전환을 위한 단계별 실행 전략 * **원격 접속 현대화:** 유지보수 비용이 높은 VPN을 대체하여 더 빠르고 안전한 클라이언트리스(Clientless) 제로 트러스트 접속 환경을 구축합니다. * **이메일 및 DNS 보호:** AI 기반 플랫폼으로 비즈니스 이메일 침해(BEC)를 차단하고, 세계에서 가장 빠른 1.1.1.1 리졸버를 활용해 악성 사이트 접속을 원천 차단합니다. * **안전한 AI 도입:** 기업 내에서 몰래 사용되는 섀도우 AI(Shadow AI)를 파악하고, 생성형 AI 프롬프트로 유입되는 민감 데이터를 관리하는 거버넌스를 수립합니다. * **지점 네트워크 단순화:** 무거운 하드웨어 장비 없이도 모든 사무실을 원격지처럼 취급하여 지점 네트워크 구성을 간소화합니다. 향후 10년의 인터넷 환경은 AI와 양자 수준의 리스크가 공존할 것이며, 느린 마이그레이션 일정은 비즈니스의 장애물이 될 것입니다. 클라우드플레어는 최대 50인까지 무료로 제공되는 Cloudflare One을 통해 기업들이 리스크 없이 제로 트러스트 현대화를 시작하고, 비즈니스 규모에 맞춘 유연한 보안 체계를 구축할 것을 권장합니다.

백지 상태를 넘어: Cloudflare (새 탭에서 열림)

Cloudflare One은 강력한 SASE(Secure Access Service Edge) 플랫폼이지만, 모든 보안 기능을 최적으로 활용하기 위해서는 복잡한 설정 과정을 거쳐야 하는 '빈 캔버스'의 어려움이 존재합니다. 이를 해결하기 위해 Cloudflare는 전문가의 노하우를 코드화하여 자동 배포하는 '프로젝트 헬릭스(Project Helix)'를 도입했습니다. 이 프로젝트를 통해 고객은 수동 설정의 번거로움 없이 단 몇 분 만에 베스트 프랙티스가 적용된 제로 트러스트 환경을 구축할 수 있습니다. ### 초기 설정의 복잡성과 제로 트러스트 도입의 장벽 * Cloudflare One은 DNS 보호, 네트워크 보호, SWG 등 방대한 기능을 제공하지만, 초기 테넌트는 대개 운영 환경의 중단을 방지하기 위해 최소한의 설정만 되어 있는 '빈 상태'로 제공됩니다. * 고급 보안 기능인 TLS 검사, DLP(데이터 손실 방지), AV 스캔 등을 활성화하려면 수많은 스위치와 정책을 일일이 조정해야 하며, 이는 관리자에게 큰 부담이 됩니다. * 수동 설정 방식은 문서화가 어렵고 휴먼 에러의 가능성이 높으며, 특히 여러 시나리오를 동시에 적용해야 할 때 설정 간 충돌이나 누락이 발생하기 쉽습니다. ### 프로젝트 헬릭스: 전문가 노하우의 코드화와 자동화 * Cloudflare의 솔루션 엔지니어와 파트너들이 실제 구축 현장에서 겪은 베스트 프랙티스를 수집하여 이를 실행 가능한 코드(IaC) 형태로 변환했습니다. * 단순한 보안 정책 설정을 넘어, 신규 등록 도메인에 대한 원격 브라우저 격리(RBI), AI 애플리케이션 제어, 특정 SaaS 인스턴스만 허용하는 테넌트 제어(Tenant Control) 등 고도화된 설정을 포함합니다. * 사용자 경험 개선을 위해 Zoom과 같은 실시간 통신 앱의 트래픽 분리(Split Tunnel) 설정이나 공항·호텔의 캡티브 포털(Captive Portal) 접속을 위한 최적의 설정을 사전 구성으로 제공합니다. ### Terraform과 Cloudflare Workers를 활용한 기술적 구현 * **Terraform 기반 관리:** 확장 가능하고 유연한 Terraform 템플릿을 설계하여 복잡한 설정 파편과 정책을 일관되게 전달합니다. * **웹 기반 UI와 Workers:** Cloudflare Workers 및 Cloudflare Containers를 활용해 사용자가 기본 정보만 입력하면 테라폼 템플릿이 즉시 실행되는 웹 인터페이스를 구축했습니다. * **보안성 확보:** 실행 환경을 휘발성(Ephemeral)으로 구성하여 로그나 인증 토큰을 영구 저장하지 않으므로 보안 리스크를 최소화했습니다. * **효율성 극대화:** 수동으로 수 시간이 소요되던 구성 작업을 단 몇 분으로 단축하며, 클릭 한 번으로 권장 보안 정책 세트를 즉시 배포할 수 있습니다. Cloudflare One을 처음 도입하거나 환경을 재정비하려는 조직은 프로젝트 헬릭스를 통해 시행착오를 줄일 수 있습니다. 수동 설정 대신 자동화된 베스트 프랙티스 템플릿을 활용하여 보안 공백을 메우고 서비스 가동 시간을 빠르게 확보하는 것을 추천합니다.

진정으로 프로그래밍 가능한 S (새 탭에서 열림)

Cloudflare는 단순한 설정 변경을 넘어 실시간 로직 주입이 가능한 진정한 의미의 프로그래밍 가능한 SASE(Secure Access Service Edge) 플랫폼을 지향합니다. Cloudflare One과 개발자 플랫폼(Workers)이 동일한 네트워크 인프라 위에서 기본적으로 통합되어 있어, 사용자는 대기 시간 없이 보안 이벤트를 가로채고 외부 컨텍스트를 결합하여 맞춤형 보안 결정을 내릴 수 있습니다. 이는 정적인 보안 정책의 한계를 극복하고 각 기업의 고유한 요구사항에 맞춘 유연한 보안 아키텍처 구축을 가능하게 합니다. **진정한 프로그래밍 가능성의 의미** - 업계에서 흔히 말하는 API 제공이나 Terraform 지원 같은 '기초적인 프로그래밍 가능성'을 넘어, 실시간으로 보안 이벤트를 가로채고 외부 데이터를 보충하여 즉각적인 조치를 취하는 능력을 의미합니다. - 예를 들어, 특정 앱 접속 시 사용자의 규정 준수 교육 이수 여부를 외부 시스템(LMS)에서 즉시 확인하여, 미이수자에게는 접속 차단 대신 교육 포털로 리다이렉트하는 동적인 정책 결정이 가능합니다. **SASE와 개발자 플랫폼의 결합** - Cloudflare One(SASE)과 Workers(개발자 플랫폼)는 동일한 전 세계 330개 이상의 도시 인프라 및 동일한 서버 자원 위에서 실행됩니다. - 별도의 외부 클라우드에서 자동화를 실행할 필요가 없어 불필요한 네트워크 왕복 지연(Latency)이 발생하지 않으며, 보안 정책 내에서 밀리초 단위로 커스텀 로직을 수행할 수 있습니다. - 웹 보호, 사용자 보안, 프라이빗 네트워크 보안 모두가 동일한 개발 도구와 기본 요소를 공유하므로 아키텍처의 일관성을 보장합니다. **확장된 보안 액션과 워크플로우** - 기존 보안 게이트웨이의 제한적인 옵션(허용, 차단, 격리 등)에서 벗어나, 사용자 정의 로직을 실행할 수 있는 '커스텀 액션' 기능을 제공합니다. - 사용자 ID 클레임에 기반한 동적 헤더 삽입, 외부 리스크 엔진의 실시간 판독 결과 반영, 근무 시간 및 위치에 따른 정교한 접근 제어 등을 구현할 수 있습니다. - '관리형 액션(템플릿)'을 통해 ITSM 통합이나 규정 준수 자동화를 쉽게 설정하거나, '커스텀 액션'을 통해 Cloudflare Worker를 직접 호출하여 정교한 코드를 실행할 수 있습니다. **실제 활용 사례: 자동화된 세션 관리** - 특정 고객은 정해진 시간 동안 활동이 없는 기기의 세션을 강제로 종료해야 하는 보안 요건을 Cloudflare Workers를 통해 해결하고 있습니다. - 'Scheduled Worker'가 주기적으로 실행되어 기기 API(Devices API)를 쿼리하고, 비활성 임계값을 초과한 기기의 등록을 자동으로 취소하여 사용자가 ID 공급자를 통해 다시 인증하도록 강제합니다. - 이는 표준 기능으로 제공되지 않는 복잡한 보안 요구사항도 프로그래밍을 통해 즉시 해결할 수 있음을 보여줍니다. 보안 요구사항이 복잡해질수록 단순한 설정 중심의 솔루션은 한계에 부딪힙니다. Cloudflare One의 프로그래밍 가능성을 활용하여 기업 고유의 비즈니스 로직을 보안 스택에 직접 통합하면, 성능 저하 없이도 가장 강력하고 유연한 제로 트러스트 환경을 구축할 수 있습니다.

넷플릭스의 마운트 메 (새 탭에서 열림)

넷플릭스는 컨테이너 런타임을 현대화하는 과정에서 수백 개의 컨테이너가 동시에 부팅될 때 시스템이 멈추거나 헬스 체크가 실패하는 심각한 병목 현상에 직면했습니다. 조사 결과, 이는 컨테이너 보안을 위해 도입된 사용자 네임스페이스(User Namespace)의 `idmap` 마운트 작업이 리눅스 커널의 VFS(가상 파일 시스템) 전역 잠금 장치에서 경합을 일으키기 때문으로 밝혀졌습니다. 특히 이러한 현상은 구형 다중 소켓(NUMA) 하드웨어 아키텍처에서 더욱 두드러지게 나타났으며, 최신 단일 소켓 인스턴스로 전환함으로써 스케일링 성능을 크게 개선할 수 있었습니다. **컨테이너 보안 강화와 마운트 폭증의 관계** - 넷플릭스는 보안 강화를 위해 각 컨테이너에 고유한 사용자 범위를 할당하는 새로운 런타임(Kubelet + Containerd)으로 전환했습니다. - 파일 소유권을 실제로 변경하는 비용을 줄이기 위해 커널의 `idmap` 마운트 기능을 사용하는데, 이는 각 레이어마다 `open_tree`, `mount_setattr`, `move_mount` 등의 호출을 발생시킵니다. - 50개의 레이어를 가진 컨테이너 100개를 동시에 실행할 경우, 이론적으로 약 20,000번 이상의 마운트 관련 작업이 수행되며 이는 커널의 마운트 테이블 전역 락(Global Lock)에 엄청난 부하를 줍니다. **커널 및 하드웨어 수준의 병목 현상 진단** - 시스템 분석 결과, CPU는 커널의 `path_init()` 함수 내 시퀀스 락(Sequence Lock)을 기다리는 스핀 루프(Spin Loop)에서 대부분의 시간을 소비하며 'Pause' 명령어를 반복 실행했습니다. - TMA(Topdown Microarchitecture Analysis) 분석에 따르면 파이프라인 슬롯의 95.5%가 경합된 액세스로 인해 중단되었으며, 57%는 가짜 공유(False Sharing)로 인해 발생했습니다. - 여러 코어가 동일한 캐시 라인에 접근하려고 시도하면서 캐시 라인 바운싱(Cache Line Bouncing) 현상이 발생하여 시스템 성능이 급격히 저하되었습니다. **인스턴스 아키텍처에 따른 성능 차이** - 테스트 결과, 5세대 인텔 듀얼 소켓 인스턴스인 `r5.metal`은 100개 이상의 컨테이너가 동시에 실행될 때 성능이 급격히 저하되며 실패하는 모습을 보였습니다. - 반면, 단일 소켓 및 단일 NUMA 도메인을 사용하는 7세대 인스턴스(`m7i.metal-24xl`, `m7a.24xlarge`)는 높은 동시성 환경에서도 훨씬 낮은 지연 시간과 높은 성공률을 유지했습니다. - 이는 NUMA 아키텍처의 프로세서 간 상호 연결(Interconnect) 대기 시간이 전역 락 경합 상황에서 병목 현상을 수배로 증폭시키기 때문입니다. 대규모 컨테이너 환경을 운영한다면 컨테이너 이미지의 레이어 수를 최소화하여 마운트 발생 횟수를 줄여야 합니다. 또한, 컨테이너 생성 및 삭제가 빈번한 워크로드의 경우 다중 소켓 기반의 구형 인스턴스보다는 메모리 접근 대기 시간이 짧고 락 경합에 유리한 최신 단일 소켓 혹은 단일 NUMA 노드 아키텍처를 선택하는 것이 성능 안정성에 유리합니다.

마이크로소프트 규모의 멀 (새 탭에서 열림)

대규모 프로덕션 환경에서 멀티모달 에이전트의 사후 학습(Post-training)은 표준적인 강화학습 알고리즘이 예상하지 못한 지점에서 실패하는 경우가 많으며, 특히 전체 보상 지표가 상승함에도 불구하고 실제 성능은 퇴보하는 '침묵하는 실패'가 빈번하게 발생합니다. Microsoft Copilot 팀은 이러한 문제를 해결하기 위해 정책 경사 추정치(Policy gradient estimator)의 정보력을 유지하는 데 초점을 맞춘 공학적 및 알고리즘적 개입 방법을 개발했습니다. 이를 통해 수백만 명의 사용자를 대상으로 하는 복잡한 도구 조작 및 멀티모달 추론 태스크에서 성능 안정성과 모델의 견고성을 확보할 수 있었습니다. ### 단계적 목적 함수 커리큘럼을 통한 조기 전문화 방지 * **문제점**: 단순한 스칼라 보상을 최적화할 경우, 모델은 달성하기 쉬운 지표에만 매몰되어 장기 실행 능력이나 견고성이 필요한 복잡한 행동을 포기하는 조기 전문화(Premature specialization) 현상이 나타납니다. * **검증 및 선호 신호 분리**: 보상 신호를 '검증 가능 신호(도구 구문, 형식 준수 등)'와 '선호도 신호(품질 등)'로 분리하고, 학습 초기 30% 구간에서는 검증 가능 신호에만 집중하여 기본기를 다지게 합니다. * **엔트로피 하한선(Entropy Floor)**: 단순한 엔트로피 보너스 대신, 정책의 엔트로피가 특정 임계값 아래로 떨어질 때만 활성화되는 KL 페널티 형태의 '하한선'을 도입하여 학습 후반부까지 정책의 다양성을 강제로 유지합니다. ### 추정치 건강도에 따른 적응형 커리큘럼 * **ESS(유효 샘플 크기) 모니터링**: 전체 배치 중 실제로 유의미한 그래디언트 업데이트에 기여하는 궤적의 비율인 ESS를 실시간으로 추적합니다. ESS가 20% 미만으로 떨어지면 향후 학습 정체가 일어날 것임을 미리 예측할 수 있습니다. * **근접 실패(Near-miss) 주입**: ESS 수치가 위험 수준에 도달하면 저장소 버퍼에서 '근접 실패' 궤적을 학습 배치에 주입합니다. 이는 모델이 정답과 오답 사이의 미세한 차이를 학습하게 하여 배치 내 결과의 대비(Contrast)를 복구합니다. * **동적 KL 페널티 조절**: 추정치의 건강도가 낮아질 때 일시적으로 KL 페널티를 높여 정책의 급격한 변화를 방지하고, 에스티메이터가 회복될 시간을 확보합니다. ### 구조적 변산성을 고려한 분산 교정 정규화 * **문제점**: 표준적인 태스크별 정규화는 태스크 내의 변산성 구조를 무시합니다. 특히 100토큰 내외의 짧은 궤적과 2000토큰 이상의 긴 궤적 사이에는 거대한 분산 차이가 존재하며, 긴 궤적이 전체 그래디언트 신호를 왜곡하는 현상이 발생합니다. * **길이 기반 보정**: 궤적의 길이에 따라 변산성이 선형적으로 증가하는 특성을 반영하여 정규화 로직을 개선함으로써, 특정 유형의 작업이 전체 학습 방향을 독점하지 않도록 조정합니다. 실제 운영 환경에서의 AI 에이전트 학습은 대시보드상의 요약 지표와 실제 사용자 경험 사이의 괴리를 줄이는 것이 핵심입니다. 특히 ESS와 같은 추정치 건전성 지표를 상시 모니터링하고, 학습 초기 단계에서 모델이 기본 형식을 먼저 마스터할 수 있도록 보상 신호의 투입 시점을 제어하는 전략이 대규모 멀티모달 시스템의 안정적인 배포에 결정적인 역할을 합니다.

격차 해소: Pinterest L1 (새 탭에서 열림)

Pinterest는 L1 전환(CVR) 모델의 오프라인 평가 지표가 대폭 개선되었음에도 불구하고, 실제 온라인 A/B 테스트에서는 CPA 성과가 정체되거나 악화되는 ‘온라인-오프라인(O/O) 불일치’ 현상을 겪었습니다. 심층적인 진단 결과, 이 문제의 핵심은 학습 시 사용된 고차원 피처들이 실시간 서빙 시스템의 임베딩 생성 과정에서 누락되거나 쿼리-핀 타워 간의 모델 버전이 어긋난 데 있었습니다. 이를 해결하기 위해 L1/L2 시스템 간 피처 온보딩을 자동화하고 정합성을 맞춤으로써 오프라인의 모델 개선을 실제 비즈니스 지표의 승리로 연결할 수 있었습니다. ### 오프라인 지표와 온라인 성과의 괴리 * **지표 상의 모순:** 새로운 L1 CVR 모델은 오프라인 평가에서 기존 모델 대비 LogMAE를 20~45% 감소시켰으며, 모든 pCVR 버킷에서 우수한 보정(Calibration) 성능을 보였습니다. * **온라인 실험 결과:** 하지만 실제 운영 환경(Budget-Split 실험)에서는 주요 oCPM 세그먼트의 CPA가 오히려 나빠지거나 중립적인 결과를 보였고, 오프라인 예측과는 다른 트래픽 믹스 변화가 관찰되었습니다. * **가설 수립:** 문제 해결을 위해 '모델 및 평가(데이터 오류)', '서빙 및 피처(시스템 정합성)', '퍼널 및 유틸리티(설계 미스)'의 세 가지 계층으로 가설을 나누어 분석을 시작했습니다. ### 원인 분석에서 제외된 요인들 * **오프라인 평가 오류:** 다양한 로그 소스(경매 낙찰 건, 전체 요청 건 등)를 재검증하고 아웃라이어를 제거한 후에도 오프라인 성능 우위는 견고하게 유지되었으므로 평가 방식 자체의 문제는 아니었습니다. * **노출 편향(Exposure Bias):** 실험군 트래픽 비중을 20%에서 70%까지 높였음에도 온라인 보정 문제가 지속되는 것을 확인하여, 대조군 모델의 지배력으로 인한 편향 문제도 주된 원인이 아님을 밝혀냈습니다. * **서빙 지연 및 타임아웃:** 처리 시간(p50/p90/p99) 및 성공률을 비교한 결과 실험군과 대조군 사이에 유의미한 차이가 없어 시스템 성능 이슈도 배제되었습니다. ### 피처 수준의 온라인-오프라인 불일치 * **누락된 피처 파이프라인:** L1 단계는 지연 시간 단축을 위해 별도의 ANN(근사 최근접 이웃) 인덱스를 사용하는데, 학습 로그에는 존재하던 고영향력 피처들이 정작 온라인 임베딩 생성기에는 온보딩되지 않은 상태였습니다. * **구체적 사례:** 타겟팅 사양(관심사, 검색어 모드), 외부 사이트 전환 방문 횟수(1/7/30/90일), MediaSage 이미지 임베딩 등이 온라인 서빙 시 누락되어 모델이 빈약한 정보만으로 예측을 수행하고 있었습니다. * **해결 방안:** UFR(Unified Feature Representation) 구성을 업데이트하여 누락된 피처를 L1 임베딩 경로에 추가했으며, 향후 L2용으로 온보딩된 피처가 L1 임베딩에도 자동 적용되도록 도구의 기본 동작을 수정했습니다. ### 임베딩 버전 및 아키텍처 불일치 * **Two-tower 버전 스큐:** 오프라인에서는 단일 체크포인트로 평가하지만, 온라인 시스템에서는 쿼리 타워(User)와 핀 타워(Ad)가 사용하는 모델 버전이 일시적으로 일치하지 않는 현상이 발생할 수 있음을 확인했습니다. * **모델 정합성:** 두 타워가 서로 다른 시점의 모델 가중치를 사용할 경우 생성된 임베딩 벡터 간의 거리 계산이 무의미해지며, 이는 곧 L1 단계의 회수(Recall) 성능 저하로 이어집니다. * **시스템적 교훈:** 단순한 모델 알고리즘의 개선보다 학습 환경과 서빙 아키텍처 간의 '기술적 정합성'을 유지하는 파이프라인 관리가 실제 성능에 더 결정적인 영향을 미친다는 것을 입증했습니다. L1 랭킹 모델의 성능 향상이 온라인 지표 개선으로 이어지지 않는다면, 모델 자체의 로직보다는 학습 데이터 피처가 실시간 서빙 아키텍처(ANN, 임베딩 빌더 등)까지 온전히 전달되고 있는지 파이프라인의 종단간 정합성을 가장 먼저 점검해야 합니다.

아이디어에서 풀 리퀘스트까지 (새 탭에서 열림)

Senior Service Delivery Engineer, GitHub

2조 토큰을 카테고리 분류에 쓰면서 알게된 것들 (새 탭에서 열림)

당근 Taxonomy 팀은 방대한 중고거래 게시글과 서비스 데이터를 효율적으로 분류하기 위해 LLM 기반의 자동화 파이프라인인 'Taxonomy Management System'을 구축했습니다. 이 시스템은 Dataflow를 통한 고병렬 추론과 LLM as a Judge 방식의 평가 체계를 결합하여, 사람이 직접 수행하던 카테고리 관리와 라벨링 비용을 획기적으로 줄이면서도 1만 개 이상의 정교한 카테고리 체계를 안정적으로 운영하고 있습니다. 2조 토큰에 달하는 대규모 데이터를 처리하며 얻은 노하우를 통해, 단순 분류를 넘어 서비스 전반의 공통 데이터 언어를 구축하는 성과를 거두었습니다. **택소노미의 중요성과 자동화의 필요성** * 택소노미는 검색, 추천, 광고 등 서비스 전반에서 데이터를 통일된 방식으로 다루기 위한 계층적 카테고리 체계이자 공통 언어입니다. * 기존의 수동 분류 방식은 도메인 전문가의 리소스가 과도하게 소요되고, 사용자가 입력한 데이터만으로는 정밀한 분류(3-depth 이상)가 어렵다는 한계가 있었습니다. * LLM을 활용해 사용자가 입력하지 않은 세부 카테고리와 속성(브랜드, 색상, 재질 등)을 자동으로 추출하여 데이터의 표현력을 높였습니다. **Dataflow와 BigQuery 중심의 파이프라인 설계** * 초 단위의 응답 시간이 걸리는 LLM 추론을 대규모 배치 및 스트림으로 처리하기 위해 Apache Beam 기반의 Google Cloud Dataflow를 채택하여 병렬 처리 성능을 확보했습니다. * 추론 결과의 원천 데이터(Source of Truth)를 BigQuery에 적재하여 분석과 학습에 즉시 활용하고, 실시간 서비스가 필요한 경우 Kafka를 통해 피처 플랫폼으로 전달합니다. * 택소노미 정의, 파이프라인 설정, 모델 옵션(Gemini, GPT, Claude 등)을 YAML 파일로 관리하여 코드 수정 없이 유연하게 시스템을 운영할 수 있도록 설계했습니다. **LLM을 이용한 택소노미 생성 및 확장 전략** * 기존 1,400개 수준의 카테고리를 LLM 기반의 리서치와 실데이터 분석을 통해 6-depth, 10,000개 이상의 정교한 체계로 확장했습니다. * 신규 카테고리 후보가 발생하면 기존 데이터 할당 테스트와 회귀 평가(Regression)를 거쳐 품질이 검증된 경우에만 정식 택소노미로 편입시킵니다. * 다국어 지원 시 일관성을 유지하기 위해 DFS(깊이 우선 탐색) 방식으로 상위 카테고리의 번역 문맥을 하위 단계 LLM에게 전달하는 방식을 사용했습니다. **추론 전략 최적화와 품질 관리(LLM as a Judge)** * 단일 단계(Single Shot), 계층적(Hierarchical), 토너먼트(Two-stage) 방식 등 택소노미 규모에 맞는 다양한 추론 전략을 모듈화하여 교체 가능하게 구현했습니다. * 분류 결과의 정확도를 측정하기 위해 여러 모델이 투표하여 정답(Ground Truth)을 정하는 'LLM as a Judge' 방식을 도입했습니다. * 카테고리 정확도(Accuracy)뿐만 아니라 다중 라벨인 속성 데이터에 대해서는 정밀도(Precision)와 재현율(Recall) 지표를 상시 모니터링하여 프롬프트와 모델 변경의 효과를 즉각 검증합니다. **실용적인 결론 및 추천** 대규모 서비스에서 카테고리 분류를 자동화하려는 팀은 처음부터 완벽한 모델을 찾기보다, **다양한 LLM 전략을 실험할 수 있는 모듈형 파이프라인**과 **자동화된 평가 체계(LLM as a Judge)**를 먼저 구축하는 것이 중요합니다. 특히 데이터 소스가 다양해질 것에 대비해 이벤트 스트림과 배치 처리를 동시에 지원하는 인프라를 선택하고, 분류 결과가 실제 서비스 피처로 흐를 수 있는 파이프라인 구조를 설계할 것을 권장합니다.

‘로컬’ 슈퍼 앱에서 장기 유저 모델링은 어떻게 달라질까? (새 탭에서 열림)

당근(Karrot)은 유저의 장기적인 행동 패턴과 여러 버티컬을 넘나드는 관심을 포착하기 위해 Transformer 기반의 장기 유저 모델링 시스템을 구축했습니다. 대규모 행동 로그를 대조 학습(Contrastive Learning)으로 학습하여 공통 유저 임베딩을 생성하고, 이를 홈피드와 광고 등 다양한 추천 지면에 적용함으로써 서비스 전반의 온라인 지표를 개선했습니다. 특히 지역 기반 서비스의 특성을 반영한 배치 샘플링 전략과 대규모 콘텐츠 임베딩 학습 기법을 통해 기술적 한계를 극복하며 개인화 추천의 품질을 한 단계 높였습니다. ### 장기 유저 모델링의 필요성과 구조적 접근 * 단기 히스토리만으로는 파악하기 어려운 계절적 취향, 이사 등 특정 시기에 발생하는 반복적 관심사, 그리고 중고거래와 알바 등 여러 서비스를 넘나드는 유저의 통합적 의도를 파악하기 위해 장기 모델링을 도입했습니다. * 실시간 랭킹 모델의 지연 시간(Latency) 문제를 해결하기 위해, 별도의 유저 인코더가 오프라인에서 임베딩을 생성하고 다운스트림 모델들이 이를 '공통 피처'로 사용하는 디커플링 구조를 채택했습니다. * 수백억 건의 다중 버티컬 로그를 활용해 유저의 다음 액션을 예측(Next Action Prediction)하는 방식으로 학습하며, 이는 기존 모델 대비 약 150배 많은 데이터를 활용한 결과입니다. ### 콘텐츠 임베딩 전환과 인프라 최적화 * 아이템 ID 기반 임베딩의 한계인 신규 아이템 대응 불가(Cold Start) 문제와 GPU 메모리 점유 문제를 해결하기 위해, LLM 기반의 콘텐츠 임베딩으로 전환했습니다. * 임베딩 테이블이 차지하던 메모리를 Transformer 모델 스케일업에 집중하여 파라미터 수를 ID 기반 모델 대비 1,000배 확장하는 데 성공했습니다. * 수백 GB 규모의 대규모 임베딩 데이터를 처리하기 위해 `memmap`을 사용하여 필요한 시점에만 데이터를 디스크에서 읽고, `bbhash(Minimal Perfect Hash)`를 통해 ID 매핑에 필요한 메모리를 97% 절감하는 기술적 최적화를 수행했습니다. ### 지역성을 고려한 지역 제한 배치 샘플링 (RCBS) * 당근은 거래의 86%가 반경 5km 이내에서 발생하는 지역 기반 서비스로, 유저가 물리적으로 볼 수 없는 지역의 아이템은 학습 시 의미 없는 부정 샘플(Impossible Negatives)이 되어 학습 신호를 희석시켰습니다. * 이를 해결하기 위해 같은 지역 유저끼리 미니배치를 구성하는 '지역 제한 배치 샘플링(RCBS)'을 도입하여, 유효한 부정 샘플(Feasible Negatives)의 비중을 2%에서 70%로 대폭 끌어올렸습니다. * 단순히 부적절한 샘플을 제거하는 마스킹 방식 대신 배치 구성을 변경함으로써, 효과적인 배치 사이즈를 유지하면서도 유저의 세밀한 취향을 구분해야 하는 '어려운 부정 샘플(Hard Negative)' 학습 효과를 얻었습니다. ### 실전 적용 및 운영 전략 * 생성된 유저 임베딩은 홈피드와 광고 랭킹 모델의 추가 피처로 입력되어 장기 취향을 보강하거나, 추천 후보(Retrieval) 모델의 독립적인 소스로 활용되어 결과의 다양성을 높였습니다. * 유저의 최신 취향을 반영하기 위해 GCP Dataflow와 Beam 파이프라인을 활용해 24시간 주기로 임베딩을 갱신하며, 최근 활동이 있는 유저만 선별적으로 추론하여 비용과 시간을 최적화했습니다. * 온라인 A/B 테스트 결과, 임베딩의 갱신 주기가 짧을수록 성능이 향상됨을 확인했으며 향후 실시간 추론에 가까운 시스템 구축을 과제로 삼고 있습니다.

200MB 모듈을 팀 단위로 해결하기: 당근 숏폼팀의 On-demand Dynamic Feature Module 도입 (새 탭에서 열림)

당근 숏폼팀은 글로벌 사용자에게 불필요한 용량 부담을 주지 않기 위해 비디오 편집 기능의 핵심인 네이티브 라이브러리를 On-demand Dynamic Feature Module(DFM)로 분리했습니다. 기술적 순수성보다 운영의 안정성을 택하여 코드 영역은 베이스 모듈에 유지하고 무거운 SO 파일만 선택적으로 다운로드하는 구조를 도입했으며, 이를 통해 기능의 독립성을 확보하면서도 전체 앱 용량을 효율적으로 관리하는 성과를 거두었습니다. ### 편집 기능의 비대화와 DFM 도입 배경 * 당근 스토리의 비디오 편집 기능 추가로 인해 관련 모듈 용량이 200MB까지 증가했으며, 리소스를 CDN으로 전환한 후에도 40MB라는 적지 않은 용량이 남았습니다. * 편집 기능은 전체 사용자 중 일부만 사용하며 특히 기능이 제공되지 않는 글로벌 사용자에게는 불필요한 용량이었기에, 필요한 시점에만 설치하는 On-demand DFM 방식을 선택했습니다. * 단순히 용량을 줄이는 것을 넘어, 팀 단위의 실험적 기능이 전체 앱 사용자 경험(UX)에 영향을 주지 않는 구조를 만드는 것이 핵심 목표였습니다. ### 개발 과정에서의 기술적 제약과 해결 방안 * **Hilt/DI 제약:** DFM은 컴파일 타임에 베이스 모듈과 의존성 그래프를 합칠 수 없어 일반적인 Hilt 사용이 불가능합니다. 이를 해결하기 위해 `EntryPoint` 패턴으로 베이스의 의존성을 노출하고 DFM에서 Dagger 컴포넌트를 수동으로 구성했습니다. * **SplitCompat 설정:** 별도로 설치된 DFM의 클래스와 리소스에 접근하기 위해 `SplitCompat`을 적용하여 기본 ClassLoader가 나중에 설치된 모듈을 인식할 수 있도록 조치했습니다. * **R8 난독화 관리:** DFM에만 적용된 keep 규칙으로 인해 베이스의 타입이 난독화되어 런타임 오류가 발생하는 문제를 겪었으며, 모든 중요 규칙을 베이스 모듈에서 집중 관리하는 원칙을 세웠습니다. ### 네이티브 라이브러리(SO) 관리의 복잡성 * **로딩 경로 문제:** On-demand DFM의 SO 파일은 일반 경로와 다르기 때문에 `System.loadLibrary()` 대신 `SplitInstallHelper.loadLibrary()`를 사용해야 하며, 수정 불가능한 서드파티 SDK는 베이스로 옮기는 등 전략적 배치가 필요했습니다. * **STL 충돌과 메모리 이슈:** 여러 모듈이 `libc++_shared.so`를 공유할 때 발생하는 심볼 충돌과 메모리 오염을 방지하기 위해, 베이스 모듈에서 특정 SO를 제외하거나 `pickFirsts` 설정을 통해 버전 정합성을 맞추었습니다. * **ABI 필터 일치:** 베이스와 DFM 모듈 간의 지원 ABI 세트가 다르면 빌드 자체가 실패하므로 모든 모듈의 `ndk.abiFilters`를 동일하게 정렬했습니다. ### 실용적인 결론: SO 파일 중심의 DFM 구조 * 모든 코드를 분리하는 대신, 용량의 90% 이상을 차지하는 SO 파일만 DFM으로 옮기고 비즈니스 로직은 베이스 모듈에 남기는 실용적인 노선을 택했습니다. * 기능 코드가 베이스에 있으므로 DFM 로딩에 실패하더라도 앱이 강제 종료되지 않고 사용자에게 적절한 안내를 보여줄 수 있어 운영 안정성이 크게 향상되었습니다. * 로컬 개발 시 DFM 설치 여부를 신경 쓰지 않아도 되어 디버깅 효율이 높아졌으며, 결과적으로 대규모 앱에서 팀 단위 실험을 안전하게 진행할 수 있는 기반을 마련했습니다. **추천:** 대규모 앱에서 특정 국가나 특정 사용자에게만 제공되는 무거운 기능을 개발 중이라면, 전체 아키텍처를 분리하느라 고생하기보다 용량의 핵심이 되는 에셋이나 네이티브 라이브러리만 On-demand로 분리하는 방식을 우선적으로 고려해 보시기 바랍니다.

위험한 조합: 작은 신 (새 탭에서 열림)

보안 사고는 종종 단일한 대규모 공격이 아니라, 미세한 설정 오류와 비정상 신호들이 결합된 '독성 조합(Toxic Combinations)'을 통해 발생합니다. 개별적으로는 무해해 보이는 디버그 플래그 노출이나 관리자 페이지 접근 시도가 봇 트래픽 및 비정상적인 맥락과 결합될 때 시스템 침해나 데이터 유출의 결정적인 징후가 됩니다. 클라우드플레어는 이러한 개별 신호들을 통합 분석하여 단순한 요청 차단을 넘어 공격자의 의도와 잠재적 위협을 식별하는 새로운 보안 프레임워크를 제시합니다. ### 독성 조합의 정의와 식별 맥락 기본적인 보안 장비(WAF, API 보호 등)가 개별 요청의 위험도를 평가한다면, 독성 조합 탐지는 여러 신호 사이의 관계와 맥락을 분석합니다. * **봇 신호 분석:** 공격의 자동화 여부를 판단하기 위해 봇 점수(Bot Score)를 활용하며, 낮은 점수의 트래픽이 민감한 경로를 탐색하는지 확인합니다. * **민감 경로 결합:** `/admin`, `/debug`, `/metrics`, `/wp-admin` 등 관리자 권한이나 내부 정보가 노출될 수 있는 경로에 대한 요청을 집중 감시합니다. * **통계적 이상 징후:** 평소와 다른 지리적 접속(Geo jump), 동일한 행위를 반복하는 분산 IP(Rate-limit evasion), 예상치 못한 HTTP 상태 코드 발생 등을 분석합니다. * **설정 오류 식별:** 인증 헤더가 누락되었거나 세션 쿠키가 없는 상태에서 민감한 데이터에 접근하는 시도를 탐지합니다. ### 공격 단계별 분석 및 데이터 현황 클라우드플레어는 24시간 동안의 데이터를 분석하여 실제 공격이 이루어지는 과정을 세 단계로 구분했습니다. * **광범위한 탐색(Probing):** 분석 대상 호스트의 약 11%에서 관리자 페이지 접근 시도가 관찰되었으며, 이는 주로 워드프레스(WordPress) 환경에 집중되었습니다. * **독성 조합 필터링:** 탐색 시도 중 봇 신호와 특정 경로 접근이 결합된 사례를 추출한 결과, 워드프레스 제외 시 약 0.25%의 호스트가 실제 위험에 노출된 것으로 나타났습니다. * **도달 가능성 검증(Reachable):** 단순한 `200 OK` 응답이 실제 성공인지 확인하기 위해 리다이렉션이나 오설정으로 인한 허위 양성(False Positive)을 제거하여 실제 취약한 호스트를 선별합니다. ### 주요 위협 시나리오와 취약점 작은 신호들이 모여 형성되는 대표적인 보안 위협은 다음과 같습니다. * **관리자 엔드포인트 노출:** `/wp-admin`이나 서버 대시보드 스캔을 통해 무차별 대입 공격을 수행하거나, 특정 소프트웨어 버전의 CVE 취약점을 노린 타겟팅 공격으로 이어집니다. * **디버그 플래그 오용:** URL에 `?debug=true`와 같은 파라미터를 추가하여 기술 스택 정보, 환경 변수, 데이터베이스 쿼리 세부 내용을 탈취하려는 시도입니다. * **권한 및 접근 제어 위협:** 인증 헤더가 없는 상태에서 높은 ID 변동성(High ID churn)을 보이는 요청은 IDOR(부적절한 직접 객체 참조)를 통한 데이터 유출 가능성을 시사합니다. ### 보안 강화를 위한 실무 권장사항 * **통합 모니터링:** Cloudflare WAF와 봇 관리 기능을 결합하여 자동화된 스캐닝을 차단하고, Log Explorer를 통해 민감한 경로에 대한 비정상적인 성공 응답을 주기적으로 쿼리해야 합니다. * **디버그 모드 관리:** 운영 환경에서 불필요한 디버그 플래그가 활성화되어 있지 않은지 점검하고, 노출된 관리자 페이지에는 Zero Trust 인증이나 IP 화이트리스팅을 적용하십시오. * **맥락 기반 대응:** 단일 요청 차단에 그치지 않고, 특정 IP나 봇이 수행하는 일련의 행위 패턴을 분석하여 공격의 '의도'를 파악하는 방어 전략을 수립해야 합니다.

인터넷에서 가장 많이 본 (새 탭에서 열림)

클라우드플레어는 매일 76억 회 이상 노출되는 인터넷의 대표적 UI인 '턴스타일(Turnstile)'과 '챌린지 페이지'를 사용자 중심으로 전면 개편했습니다. 인공지능 발전에 따른 보안 위협 증가로 보안 확인 횟수가 급증함에 따라, 사용자 좌절감을 줄이고 전 세계 수십억 명에게 일관된 경험을 제공하기 위해 정보 아키텍처를 표준화하고 기술적 복잡성을 직관적인 디자인으로 통합했습니다. ## 기존 UI의 문제점과 리디자인의 필요성 - **보안 인증의 급격한 증가**: 봇 공격이 정교해지면서 보안 확인 횟수가 연평균 58.1%씩 증가하여 2025년 기준 일일 53.5억 건에 달하게 되었고, 이는 사용자 피로도 증가로 이어졌습니다. - **불일치하는 사용자 경험**: 기존 UI는 에러 메시지가 지나치게 기술적이거나 모호했으며, 위젯과 풀페이지(Challenge Page) 간의 레이아웃과 시각 언어가 통일되지 않아 사용자가 상황을 파악하기 어려웠습니다. - **불분명한 피드백 루프**: 사용자가 불만을 표출하거나 오류를 보고하는 피드백 옵션이 모호하게 설계되어, 실제 문제 해결에 필요한 유의미한 데이터를 수집하는 데 한계가 있었습니다. ## 디자인 감사 및 사용자 여정 분석 - **포괄적 상태 점검**: 모든 에러 시나리오와 상호작용 상태를 전수 조사하여 기술적 복잡함과 사용자 편의성 사이의 간극을 확인했습니다. - **엣지 케이스의 일반화**: 수십억 명이 사용하는 도구인 만큼, 극소수의 예외 상황도 실제로는 수만 명에게 영향을 미치는 주요 케이스로 간주하고 모든 문화권과 기술 숙련도를 포용하도록 설계했습니다. - **감정 기반 여정 지도**: 사용자가 보안 확인을 만나는 순간부터 에러 발생, 최종 통과에 이르기까지의 감정 변화를 추적하여 가장 좌절감이 큰 지점을 개선 포인트로 잡았습니다. ## 통합 정보 아키텍처 구축 - **"생각하게 하지 마(Don't Make Me Think)" 원칙**: 사용자가 인터페이스를 해석하거나 고민할 필요가 없도록 시각적 계층 구조를 완전히 단순화했습니다. - **구조적 통일성**: 소형 위젯인 턴스타일과 전체 화면인 챌린지 페이지에 동일한 구조적 패턴을 적용하여, 버튼 위치나 설명 텍스트, 도움말 링크의 배치를 표준화했습니다. - **창의성보다 일관성**: 개별적인 디자인 창의성보다는 엄격한 프레임워크를 우선시하여, 사용자가 어떤 기기나 환경에서도 익숙하게 보안 인증을 마칠 수 있도록 제약 조건을 설계에 반영했습니다. 보안 인증과 같은 필수적인 마찰 구간에서는 기술적 완벽함만큼이나 사용자의 인지 부하를 줄이는 디자인 표준화가 중요합니다. 대규모 서비스를 운영한다면 모든 사용자가 직관적으로 이해할 수 있도록 정보 아키텍처를 통일하고, 에러 메시지에서 기술적 전문용어를 배제하여 명확한 가이드를 제공하는 것이 사용자 이탈을 막는 핵심 전략이 될 것입니다.

립트에는 더 나 (새 탭에서 열림)

현재의 WHATWG 스트림 표준(Web Streams)은 설계된 지 10년이 지나 현대적인 JavaScript 개발 방식과 동떨어져 있으며, 심각한 사용성 및 성능 문제를 안고 있습니다. 비동기 반복문(`for await...of`)이 도입되기 전에 수립된 이 API는 불필요하게 복잡한 리더/라이터 모델과 잠금(locking) 메커니즘에 의존하고 있어, 현대적 언어 기능을 활용한 대안적인 접근 방식을 통해 최대 120배까지 성능을 개선할 수 있다는 것이 핵심 주장입니다. **역사적 배경과 설계의 시대적 한계** - Web Streams 표준은 2014~2016년 사이에 개발되었으며, 이는 JavaScript의 비동기 반복문(`for await...of`)이 등장(2018년)하기 훨씬 전의 일입니다. - 당시에는 비동기 시퀀스를 처리하는 관용적인 방법이 없었기 때문에, 표준은 리더와 라이터를 획득하고 관리하는 독자적인 모델을 구축해야만 했습니다. - 결과적으로 Node.js와 같은 서버 사이드 런타임들은 호환성을 위해 나중에 이 복잡한 표준을 도입하게 되었고, 이는 현대적인 JavaScript 개발 흐름과 충돌하는 원인이 되었습니다. **과도한 상용구 코드와 사용성 저하** - 스트림을 끝까지 읽는 단순한 작업조차 리더 획득, `read()`의 반복 호출, `{ value, done }` 프로토콜 처리, 그리고 `finally` 블록을 통한 명시적인 잠금 해제 등 복잡한 과정을 거쳐야 합니다. - 나중에 비동기 반복문이 지원되기는 했으나, 이는 기존의 복잡한 구조 위에 덧씌워진 형태에 불과하여 BYOB(Bring Your Own Buffer) 같은 세부적인 기능을 제대로 활용할 수 없는 한계가 있습니다. - 개발자들은 여전히 내부의 리더, 잠금, 컨트롤러 구조를 이해해야 하며, 문제 발생 시 추상화 뒤에 숨은 복잡성 때문에 디버깅에 어려움을 겪습니다. **수동 잠금(Locking) 모델의 치명적 결함** - Web Streams는 다중 소비자의 간섭을 막기 위해 독점적 잠금 모델을 사용하지만, 이를 관리하는 방식이 매우 위험합니다. - `getReader()`를 통해 잠긴 스트림은 반드시 `releaseLock()`을 호출해야 하며, 이를 잊을 경우 스트림이 영구적으로 잠겨 파이프나 취소 등 다른 모든 작업을 수행할 수 없게 됩니다. - 잠금 상태(`locked`)에 대한 정보는 제공되지만, 누가 왜 잠갔는지 혹은 잠금이 유효한지에 대한 구체적인 맥락을 알 수 없어 운영 환경에서의 실수를 유발하기 쉽습니다. **현대적 대안을 통한 비약적인 성능 향상** - 저자가 제시하는 대안적인 접근 방식은 JavaScript 언어 자체의 원시 기능을 활용하며, 기존 Web Streams 대비 모든 런타임(Node.js, Deno, Bun, 브라우저 등)에서 2배에서 최대 120배 빠른 성능을 보입니다. - 이러한 성능 차이는 단순한 최적화의 결과가 아니라, 10년 전의 낡은 설계 결정을 현대적인 JavaScript 패턴에 맞게 근본적으로 다시 설계함으로써 얻어진 결과입니다. 개발자들은 이제 기존 Web Streams의 복잡한 수동 관리 방식에서 벗어나, 현대적인 비동기 반복 기반의 더 직관적이고 효율적인 스트림 API로의 전환을 논의해야 할 시점에 와 있습니다.

양자 내성 암호 사용 (새 탭에서 열림)

Cloudflare는 인터넷 보안의 투명성을 높이기 위해 Radar 플랫폼에 양자 내성 암호(PQ), 메시징 시스템의 키 투명성(Key Transparency), 그리고 라우팅 보안(ASPA)과 관련된 새로운 데이터셋과 도구를 대거 도입했습니다. 이번 업데이트는 클라이언트 측에 국한되었던 보안 모니터링을 오리진 서버와 메시징 인프라까지 확장하여, 다가오는 양자 컴퓨팅 시대와 고도화되는 네트워크 공격에 대비한 가시성을 제공하는 것을 핵심으로 합니다. **오리진 서버의 양자 내성 암호(PQ) 지원 모니터링** * **지원 범위 확장:** 기존 클라이언트 측 PQ 지원 모니터링을 넘어, Cloudflare 에지 서버와 고객의 오리진 서버 간 연결에 대한 PQ 호환성 데이터를 Radar에 추가했습니다. * **하이브리드 알고리즘 추적:** 고전적 방식인 X25519와 격자 기반 PQ 방식인 ML-KEM을 결합한 'X25519MLKEM768' 알고리즘의 채택 현황을 중점적으로 추적합니다. * **성장 지표:** 오리진 서버의 PQ 지원율은 2025년 초 1% 미만에서 2026년 2월 기준 10%로 약 10배 급증했으며, 이는 OpenSSL, Go 등 주요 암호화 라이브러리의 기본 설정 변경이 주도하고 있습니다. * **실시간 테스트 도구:** Cloudflare Containers를 활용하여 특정 호스트네임의 PQ 지원 여부를 즉시 확인할 수 있는 도구를 출시했으며, 이는 실제 TLS 핸드셰이크를 수행하여 협상된 알고리즘을 보여줍니다. **종단간 암호화(E2EE) 메시징을 위한 키 투명성** * **신뢰 문제 해결:** WhatsApp이나 Signal 같은 서비스에서 사용자가 서비스 제공자의 공공 키 배포를 무조건 신뢰해야 했던 취약점을 보완하기 위해 '키 투명성(Key Transparency)' 섹션을 신설했습니다. * **공개 감사 대시보드:** Cloudflare가 독립적인 감사자(Auditor)로서 WhatsApp 등의 메시징 서비스가 제공하는 공공 키 로그의 무결성을 실시간으로 검증하고 그 결과를 공개합니다. * **조작 방지:** 공격자가 공공 키를 가로채거나 교체하는 중간자 공격(MITM)을 방지할 수 있도록, 누구나 API를 통해 감사 증명을 독립적으로 검증할 수 있는 인터페이스를 제공합니다. **라우팅 보안 및 ASPA 배포 현황** * **BGP 경로 누출 방지:** 인터넷 라우팅의 고질적인 문제인 BGP 경로 누출을 탐지하고 방지하기 위한 새로운 표준인 ASPA(Autonomous System Provider Authorization) 관련 정보를 제공합니다. * **다각적 분석:** 글로벌 수준은 물론 국가 및 개별 네트워크(AS) 단위에서 ASPA가 얼마나 도입되었는지에 대한 상세한 인사이트를 확인할 수 있습니다. **결론 및 권장 사항** 인프라 운영자는 Cloudflare Radar의 새로운 PQ 테스트 도구를 활용해 자사 오리진 서버의 양자 내성 암호 준비 상태를 점검해야 합니다. 특히 최신 보안 표준을 유지하기 위해 OpenSSL 3.5.0+, Go 1.24+ 등 하이브리드 PQ를 기본으로 지원하는 최신 암호화 라이브러리로의 업데이트를 적극 권장합니다.