← 목록으로

📰 데일리 테크 다이제스트 - 2026-07-14

2026-07-14 Cloud, Kubernetes, AI, DevOps 소식 17건 — 자동 큐레이션 다이제스트.

데일리 다이제스트
Kubernetes
Cloud Native
AI
DevOps

🔥 오늘의 주요 소식

Prefect just bought Dagster, another big Airflow rival — and it’s not a data pipeline story

데이터 파이프라인 오케스트레이터 Prefect가 Apache Airflow의 대표적 경쟁자인 Dagster를 인수한다고 발표했다. 인수는 아직 공식적으로 종결되지 않았으며, Dagster와 관리형 서비스 Dagster+는 기존 이름·가격·로드맵을 유지하고 Dagster 팀 약 40명이 Prefect로 합류한다. Prefect 창업자 겸 CEO Jeremiah Lowin은 이번 인수를 AI 에이전트가 안정적으로 동작하는 데 필요한 요소들, 즉 목표 정의(Dagster)와 실행(Prefect), 그리고 에이전트가 외부 시스템에 접근하는 범위를 통제하는 Prefect의 FastMCP를 하나로 묶는 베팅이라고 설명했다. Prefect와 Dagster는 지난 7년간 Airflow의 대안으로 경쟁하며 각각 프로덕션 워크플로 안정성과 파이프라인 검증 가능성에 초점을 맞춰 성장해왔다. Dagster 창업자 Nick Schrock은 공식적으로는 전략 고문으로 남는다고 알려졌지만, 본인 블로그에서는 프로젝트와 회사를 떠난다고 밝혀 사실상 결별에 가깝다는 해석이 나온다. FastMCP는 Anthropic의 MCP 표준과 동시에 출시돼 이후 MCP 공식 파이썬 SDK로 채택된 바 있어, 이번 인수는 오케스트레이션 업계의 무게중심이 에이전틱 워크로드로 이동하고 있음을 보여준다.

💡 왜 중요한가: 오케스트레이션 도구를 도입 중인 팀은 Dagster의 독립 로드맵 지속 여부와 FastMCP 기반 에이전트 거버넌스로의 통합 방향을 주시해야 한다.

🔗 원문 보기 · The New Stack


Kubernetes & Cloud Native

Accessing private Git repositories from Amazon EKS capability for Argo CD

AWS Containers

AWS가 블로그를 통해 Amazon EKS의 관리형 Argo CD 기능("Argo CD capability")을 사설 Git 서버와 연결하는 방법을 소개했다. Argo CD capability는 고객 VPC에 직접 접근할 수 없어 기본적으로 공개 저장소만 가져올 수 있는데, 이를 해결하기 위해 AWS CodeConnections를 VPC 안에 호스트로 구성해 IAM 기반 인증으로 사설 Git 서버(GitHub Enterprise Server, 셀프호스팅 GitLab)에 접근하는 아키텍처를 제시한다. 절차는 크게 세 단계로, VPC 내 CodeConnections 호스트 생성, Argo CD가 사용할 커넥션 설정, 샘플 애플리케이션 배포로 이어진다. 내부적으로는 지정한 서브넷마다 크로스 어카운트 ENI가 생성돼 사설 Git 서버와 통신하고, 리포지토리에는 AWS Connector 앱이 설치되어 상호작용마다 임시 자격 증명을 발급받는 구조다. 이 방식을 쓰면 장기 자격 증명을 관리하지 않고도 IP 화이트리스팅, 리전 간 CodeConnections 연동, 사설 네트워크를 통한 완전 폐쇄망 Git 서버 접근이 가능해진다.

💡 GitOps 환경에서 사설 Git 서버를 쓰는 팀은 장기 토큰 관리 부담 없이 IAM 기반 임시 자격 증명으로 Argo CD를 연결할 수 있어, 보안 감사 대응과 자격 증명 순환 정책을 단순화할 수 있다.

Operating OpenTelemetry at scale with OpAMP

CNCF

CNCF 블로그가 OpenObservability Talks 팟캐스트에서 나눈 OpAMP(Open Agent Management Protocol) 메인테이너이자 BindPlane 수석 엔지니어 Andy Keller와의 인터뷰를 정리했다. OpenTelemetry Collector 배포가 수십 개에서 수백만 개(임베디드·POS 기기 포함)까지 다양해지면서 중앙에서 일관되게 설정·업데이트·헬스체크하는 문제가 대두됐고, OpAMP는 Protocol Buffers로 정의된 서버-에이전트·에이전트-서버 두 개 메시지만으로 이를 표준화한다. 아키텍처는 읽기 전용으로 현재 설정과 헬스를 보고하는 OpAMP 익스텐션과, Collector 옆에서 별도 프로세스로 동작하며 읽기·쓰기를 모두 수행하는 슈퍼바이저로 구성되는데, 슈퍼바이저는 새 설정을 디스크에 쓰고 Collector를 재시작하되 시작 실패 시 마지막으로 정상 동작한 설정으로 자동 롤백하는 안전장치를 갖췄다. 설정 페이로드가 단순한 이름-값 쌍이라는 범용적 설계 덕분에 OpAMP는 Collector뿐 아니라 Kubernetes Operator(OpAMP Bridge 경유), OpenTelemetry Java SDK, Fluent Bit 플릿까지 관리할 수 있다. KubeCon Europe 2026을 전후해 출시되는 OpAMP Gateway Extension은 WebSocket 연결 한계를 해결하기 위한 것으로, 예를 들어 10만 개 Collector를 100개의 게이트웨이가 각각 1000개씩 모아 관리 플랫폼에는 100개 연결만 노출하는 팬인 구조를 제공한다. OpAMP는 현재 베타 단계이며, 설정 diff 전송과 SDK 핫리로딩, 구현 방식이 아닌 의도를 전달하는 "텔레메트리 정책" OTEP 등이 로드맵에 올라 있다.

💡 수백~수백만 대 규모의 Collector 플릿을 운영 중이거나 계획 중인 팀이라면, 자체 개발한 사설 에이전트 관리 프로토콜 대신 OpAMP 표준과 곧 나올 Gateway Extension을 검토해 WebSocket 연결 폭증 문제를 미리 설계에 반영하는 편이 낫다.


클라우드 업데이트

Key findings from the 2026 Public Sector M-Trends report and beyond

Google Cloud

Google Cloud(Mandiant)가 2026 공공 부문 위협 지형 보고서(M-Trends and Beyond)를 발표하고, 2025년 한 해 50만 시간 이상의 사고 대응 조사에서 도출한 핵심 트렌드를 정리했다. 가장 두드러진 지표는 초기 접근 브로커가 발판을 마련한 뒤 랜섬웨어 운영자에게 넘기기까지 중간값이 단 22초에 불과하다는 "22초 인계" 현상으로, 사람이 개입하는 전통적 트리아지 속도로는 대응이 불가능하다는 점을 보여준다. 보고서는 또한 국가 배후 스파이 활동이 5년 넘게 탐지되지 않고 지속되는 "지속성 역설", 게스트 수준 보안 도구를 우회하는 "스냅샷 마운팅" 등으로 가상화 관리 평면을 노리는 공격, 서비스 계정·OAuth 토큰 같은 비인간 신원(NHI) 탈취로 SaaS 연동 전체가 연쇄적으로 뚫리는 문제, 그리고 전체 글로벌 침해의 11%를 차지하는 보이스피싱(비싱) 급증을 지적한다. 이에 대응해 Google은 Chrome Enterprise Premium을 통한 VPN 대체형 컨텍스트 기반 접근 제어, Google Security Operations 기반의 실시간 텔레메트리 분석과 위협 헌팅·탐지 엔지니어링·서드파티 컨텍스트 에이전트 3종, Security Command Center와 Wiz 파트너십을 통한 가상화·클라우드 계층 가시성 강화를 제시한다. 파스코 보안관실과 코네티컷 주정부 사례에서는 Google Security Operations 도입으로 포렌식 조사 시간이 수개월에서 수 시간으로 단축됐다고 소개됐다.

💡 초기 침투에서 랜섬웨어 인계까지 수십 초 단위로 압축된 공격 사이클을 고려하면, 90일 텔레메트리 보존 정책과 사람 중심 트리아지에 의존하는 보안 운영 체계는 근본적으로 재설계가 필요하다.

Securing the AI supply chain on GKE: Introducing k8s-aibom for automated AI BOMs

Google Cloud

Google Cloud가 GKE에서 실행 중인 AI 워크로드를 자동으로 탐지해 표준 규격의 AI 자재명세서(ML-BOM)를 생성하는 오픈소스 도구 k8s-aibom을 공개했다. 이 도구는 사이드카, eBPF 커널 모듈, 특권 DaemonSet, 파드 스펙 수정 없이 비특권 Kubernetes 컨트롤러 하나로 클러스터 API와 컨테이너 환경을 지속 감시하며 vLLM, Triton 같은 서빙 런타임과 LangChain·AutoGen 같은 에이전트 프레임워크, 벡터DB 등을 패턴 매칭으로 식별한다. 탐지 결과는 OWASP CycloneDX 1.6 규격의 ML-BOM 문서로 컴파일되어 클러스터 내 커스텀 리소스 상태와 Google Cloud Storage, 웹훅 등 외부 싱크로 전달되며, 동일한 클러스터 입력에서는 항상 동일한 산출물이 나오는 결정론적 특성 덕분에 GitOps 워크플로에서 정확한 diff 비교와 드리프트 알림이 가능하다. 탐지 신뢰도는 명시적으로 설정된 "Declared", 패턴 매칭으로 추론된 "Inferred", 모델 정보가 특정되지 않는 "Unresolved" 3단계로 구분해 감사자가 사람의 의도와 기계 추론을 구분할 수 있게 한다. Cloud Storage 싱크는 객체 생성 시 DoesNotExist 조건을 강제해 한 번 기록된 BOM을 사후 변조할 수 없는 불변 감사 로그로 만든다. Google은 이 도구가 EU AI Act 12·50조, NIST AI RMF, ISO/IEC 42001 같은 규제 프레임워크 대응에 필요한 실증 데이터를 자동으로 축적해 준다고 설명한다.

💡 개발자가 비공식적으로 배포한 섀도 AI 워크로드까지 포함해 실행 중인 자산을 자동·불변 감사 로그로 남길 수 있다는 점에서, EU AI Act 등 규제 대응 압박을 받는 조직이라면 빌드 타임 스캐너와 병행해 도입을 검토할 가치가 있다.

Building the AI-defined vehicle with Android, Google Cloud, and Nexus SDV

Google Cloud

Google Cloud와 파트너사 Valtech Mobility가 Android Automotive OS(AAOS)의 소프트웨어 정의 차량(SDV) 아키텍처와 Google Cloud Bigtable을 결합한 Nexus SDV 플랫폼을 소개했다. AAOS SDV는 차량 기능을 하드웨어에서 분리한 서비스 지향 아키텍처(SOA)로 구현해 냉난방·조명·진단 등 비안전 기능을 동적으로 발견·관리할 수 있게 하며, 클라우드 상의 Android Cuttlefish 에뮬레이터로 디지털 트윈을 만들어 실제 하드웨어 없이 검증할 수 있다. Nexus SDV는 이 미들웨어 계층에서 수집한 고빈도 원격측정 데이터를 서브밀리초 지연으로 처리하도록 설계된 Bigtable에 스트리밍하며, 희소 행 스키마 덕분에 엔진 지표부터 LiDAR 포인트 클라우드까지 다양한 센서 데이터를 단일 테이블 구조로 다운타임 없이 수용할 수 있다. Continuous Materialized Views로 배터리 온도 평균 같은 지표를 저장 계층에서 미리 계산하고, Agent Development Kit·Apache Spark 연동을 통해 실시간 텔레메트리 이상 탐지 시 자동으로 OTA 업데이트나 부품 사전 주문 같은 워크플로를 트리거할 수 있다. 예방 정비 사용 사례에서는 Gemini 기반 에이전트가 주행거리·정비 이력·향후 일정 등 맥락을 종합해 정비소 예약이나 부품 주문을 제안하는 식으로, 반응형 정비를 예측형 정비로 전환한다. 보안은 상호 TLS와 Google Cloud CAS를 통한 차량 신원 인증, Private GKE 클러스터 기반 네트워크 격리, SAIF(Secure AI Framework)로 계층화됐으며, AAOS SDV는 Android Automotive 26Q2 릴리스부터 제공된다.

💡 자동차 OEM 입장에서는 텔레메트리 파이프라인을 처음부터 구축하는 대신 Bigtable·ADK 기반 표준 데이터 계층 위에서 브랜드 차별화 기능에 집중할 수 있다는 점이 이 플랫폼의 핵심 가치다.

Introducing Precursor: detecting agentic behavior with continuous client-side signals

Cloudflare

Cloudflare가 세션 전체에 걸친 행동 패턴을 지속적으로 수집·분석해 봇을 탐지하는 새로운 클라이언트 사이드 검증 시스템 Precursor를 출시했다. 기존 Turnstile이 로그인·가입·결제 같은 특정 시점에서 하루 약 30억 회 실행되는 위험 기반 챌린지였다면, Precursor는 동적으로 주입되는 자바스크립트로 마우스 움직임, 키보드 리듬, 포커스 변화, 화면 가시성 등을 세션 단위로 계속 수집해 Turnstile이 커버하지 못하던 애플리케이션 전 구간의 가시성 공백을 메운다. 핵심 논리는 봇이 개별 캡차나 짧은 구간에서는 사람처럼 보이도록 흉내 낼 수 있어도, 손목 회전에 따른 곡선 궤적, 체크박스를 보고 클릭하기까지의 인지 지연, 손 떨림 같은 물리적 제약이 반영된 사람의 세션 전체 행동 패턴은 재현하기 훨씬 어렵다는 데 있다. 데이터는 엣지 서버의 평가 계층에서 여러 이벤트를 교차 검증해 봇 점수에 반영되며, 세션이 새로고침되거나 챌린지가 재시작돼도 초기화되지 않는 세션 스코프 방식이라 페이지를 새로고침해 행동 시그니처를 리셋하는 우회를 막는다. 프라이버시 설계상 키 입력은 실제 입력값이 아닌 타이밍·리듬만 캡처하고, 집계된 패턴으로만 평가되며 고객 대시보드에 노출되거나 사용자 계정에 연결되지 않는다. Precursor는 Enterprise Bot Management의 옵션 기능으로 정식 출시(GA) 전까지 무료로 제공되며, 세션 기반 뷰를 제공하는 새로운 Security Analytics 대시보드와 함께 출시됐다.

💡 로그인·결제 시점의 단발성 챌린지만으로는 세션 전반에 걸친 정교한 봇/에이전트 자동화를 걸러내지 못하므로, 세션 단위 행동 시그널을 기존 봇 스코어·챌린지 로직에 결합하는 방향으로 전환할 필요가 있다.

Unlocking the future of video data: March Networks cloud storage on AWS

AWS Architecture

AWS 아키텍처 블로그가 25년 경력의 영상 감시 업체 March Networks가 대규모 엔터프라이즈 비디오 데이터를 AWS 위에서 저장·분석하는 아키텍처를 구축한 사례를 소개했다. 소매·은행·QSR·교통 등 수천 개 분산 거점에서 발생하는 페타바이트급 영상은 기존 온프레미스 NVR 모델로는 하드웨어 확장과 유지보수 부담이 크고 거점 간 보존 정책도 일관되지 않았는데, March Networks는 Amazon S3와 S3 Glacier를 계층형으로 사용해 자주 접근하는 최근 영상은 S3 Standard/Standard-IA에, 장기 보존용은 초저가 Glacier 계층에 저장하고 SQS·SES·CloudWatch·STS로 수집·알림·모니터링·인증을 지원한다. 사례로 제시된 한 소매업체는 카메라 580대 이상, 약 5,600TB 규모 아카이브 영상을 5년간 보관하는 데 제3자 클라우드 기준 연간 약 34만7000달러가 드는 반면, 동일 물량을 온프레미스로 유지하면 연간 약 170만 달러가 든다고 추산해 하이브리드 클라우드 전환의 비용 절감 효과를 뒷받침했다. 메타데이터와 상태 관리에는 PostgreSQL과 Amazon ElastiCache for Redis를 사용하며, Amazon S3 Vectors와 Amazon Bedrock을 결합한 AI Smart Search로 자연어 질의를 통해 방대한 영상 아카이브에서 특정 장면을 빠르게 찾아내는 기능도 지원한다. AWS는 이 사례를 통해 클라우드 계층화 저장이 비용 절감뿐 아니라 다지점 통합 조사·거버넌스와 AI 기반 영상 분석의 기반이 된다고 강조한다.

💡 다지점 영상 감시 인프라를 운영하는 조직이라면 계층형 오브젝트 스토리지로의 전환이 온프레미스 대비 수배의 비용 절감을 낼 수 있을 뿐 아니라, 벡터 검색 기반 자연어 영상 질의 같은 AI 기능을 자연스럽게 얹을 수 있는 발판이 된다.

Why good AI agents fail in production: The missing infrastructure layer

Red Hat

Red Hat 블로그가 LangChain으로 구축된 AI 에이전트가 프로덕션에서 겪은 하룻밤 새 3건의 장애 사례를 통해 "에이전트 프레임워크와 프로덕션 인프라는 다른 문제"라는 주장을 전개했다. 첫 번째는 티켓 생성 API 응답이 타임아웃되자 LangChain의 정상적인 재시도 로직이 반복 실행되며 중복 티켓 43건과 고객 이메일 43통이 발생한 사례로, 원인은 재시도 로직 자체가 아니라 요청 성공 여부를 추적하는 멱등성(idempotency) 계층이 인프라에 없었던 데 있었다고 짚는다. 두 번째는 배포 단계에서 개발 편의를 위해 여러 청구 계정에 접근 가능하도록 발급된 서비스 계정 자격 증명이 프로덕션까지 그대로 유지되면서, 모델이 계정 식별자를 잘못 선택해 4,000달러가 엉뚱한 고객 계정에 청구된 사례로, 자격 증명 범위를 제한하는 "신원 경계(identity boundary)"의 부재가 근본 원인으로 지목됐다. 세 번째는 90일 반품 정책을 30일로 잘못 안내한 에이전트 응답을 그대로 고객에게 전달해 47일째 반품을 승인한 사례로, 모델 출력이 실제 정책과 대조 검증되는 "추론 경계(inference boundary)" 가드레일이 없었던 탓이라고 설명한다. 저자는 세 사례 모두 LangChain 자체는 설계대로 정확히 동작했으며, 문제는 프레임워크가 아니라 신원·안전 집행·거버넌스·관측성 같은 플랫폼 계층의 부재였다고 강조한다. Red Hat은 이런 인프라 공백을 Red Hat AI(OpenShift AI)가 "BYOA(Bring Your Own Agent)" 원칙 아래 LangChain·CrewAI·LangGraph 등 어떤 에이전트 코드도 변경 없이 그 아래에 신원·안전·거버넌스·관측성 계층을 주입해 메운다고 소개하며, 이는 자사 제품을 소개하는 후속 기사로 이어지는 시리즈의 첫 편이다.

💡 스테이징에서 통과한 에이전트라도 멱등성 처리, 자격 증명 범위 제한, 모델 출력 검증 같은 플랫폼 계층이 없으면 프로덕션에서 반복 청구·오청구·허위 정책 안내 같은 사고로 이어질 수 있어, 프레임워크 선택과 별개로 이 세 가지를 배포 체크리스트에 명시적으로 넣어야 한다.

Results for Red Hat’s Kubernetes fleet management survey

Red Hat

Red Hat이 자체 "State of Kubernetes Fleet Management" 설문 결과를 발표했다. 응답 조직의 85%가 지난 1년간 클러스터 플릿을 확장했고 70%는 이미 여러 클라우드 공급자에 걸쳐 워크로드를 운영 중이지만, 실시간으로 전체 클러스터 가시성을 확보했다고 답한 IT 리더는 17%에 불과했다. 가시성 부족은 설정 드리프트로 이어져 조직의 76%가 이를 겪고 있고, 인프라 장애의 5건 중 4건이 설정·변경 관리 실패에서 비롯됐다. 운영 압박이 커지면서 75%의 운영자가 서비스를 유지하기 위해 자체 보안 정책을 정기적으로 우회한다고 답했고, 엔지니어는 업무 시간의 65%를 예정에 없던 긴급 대응에 쓰며 57%가 번아웃을 겪고 있다고 응답했으며, IT 리더의 62%는 쿠버네티스 복잡성이 핵심 비즈니스 이니셔티브를 지연시키고 있다고 답했다. 반면 정책 기반으로 플릿을 운영하는 조직은 89%가 예측 가능한 관리에 자신감을 보였고 서비스 장애도 3배 적었던 것과 달리, 반응형(reactive) 운영 조직 중에는 단 12%만이 자신감을 보여 뚜렷한 격차가 확인됐다. Red Hat은 이 격차 해소책으로 중앙화된 가시성, 자동화된 생명주기 관리, 일관된 정책 집행을 갖춘 자사의 Red Hat Advanced Cluster Management(RHACM)를 제시하며, OpenShift·EKS·AKS·GKE 등 CNCF 준수 배포판 전반을 단일 콘솔에서 관리할 수 있다고 소개한다.

💡 자체 설문이라는 한계는 있지만, 실시간 가시성 확보 여부가 정책 기반 운영으로의 전환과 서비스 장애 3배 차이로 이어진다는 상관관계는 플릿 규모가 커지는 팀이라면 참고할 만한 신호다.

Red Hat Advanced Cluster Management 2.17: Less operational toil and more Kubernetes fleet control

Red Hat

Red Hat이 멀티클러스터 관리 도구 Red Hat Advanced Cluster Management(RHACM) 2.17을 발표했다. 오픈소스 Perses 기반의 커스터마이즈 가능한 대시보드가 정식 출시(GA)되어 허브·매니지드 클러스터 지표를 중앙 콘솔에서 바로 볼 수 있고, 클러스터·애플리케이션·검색 결과 목록에 Line of Business나 배포 환경 같은 커스텀 라벨 컬럼을 추가할 수 있다. Placement 리소스 UI가 개선돼 ApplicationSet과 Policy 생성 워크플로에 시각적 가이드 마법사가 내장됐고, 저장 전에 "선택된 클러스터/선택되지 않은 클러스터"를 실시간으로 시뮬레이션해 보여준다. 기술 프리뷰로 도입된 Argo CD Agent 통합은 기존의 풀 방식이 아닌, 원격 사이트의 경량 컴포넌트가 허브 클러스터로 역방향 연결하는 "차세대 풀 모델" GitOps를 지원해 중앙 제어 플레인이 개별 클러스터에 인바운드로 접근할 필요가 없어지고, 오프라인 상태에서도 동작하다가 연결이 복구되면 자동으로 상태를 동기화한다. 이는 폐쇄망 환경, 공장 현장, 원격 엣지 컴퓨팅 사이트에 특히 적합하다고 소개된다. 가상머신 워크로드를 위한 RBAC도 세분화되어, 예를 들어 VM을 시작할 권한만 부여하고 중지·삭제·마이그레이션 권한은 제외하는 등의 세밀한 ClusterRole을 정의해 MulticlusterRoleAssignments로 특정 클러스터·사용자 그룹에 정책으로 배포할 수 있다.

💡 엣지·폐쇄망 환경에서 GitOps를 운영 중이거나 계획 중인 팀이라면, 허브가 원격 클러스터에 인바운드로 접근할 필요 없는 Argo CD Agent의 풀 모델이 네트워크 단절 상황에서의 안정성을 크게 높여줄 수 있다.


DevOps & 인프라

Microsoft CEO Satya Nadella says you’re paying for AI twice — the second price is worse

The New Stack

마이크로소프트 CEO 사티아 나델라가 X에 올린 글에서 기업 AI 도입 비용을 노벨경제학상 수상자 케네스 애로우의 "정보의 역설"을 뒤집은 "역정보 역설"이라는 개념으로 설명했다. 그는 기업이 AI 모델의 성능을 높이기 위해 돈을 지불하는 동시에, 모델이 더 잘 작동하도록 자사의 고유 프로세스와 조직 지식을 노출해야 하는 이중 비용을 치른다고 주장했다. 그는 모든 상호작용과 수정 사항이 "배기가스"처럼 누적돼 경쟁사가 살 수 없는 조직 노하우가 AI 시스템 안에 흡수된다고 표현했다. 이런 위험에 대응하기 위해 나델라는 조직 메모리를 테넌트 내부에 두고, 자체 평가·학습 시스템을 구축하며, 오케스트레이션 레이어를 특정 파운데이션 모델과 분리하라고 권고했다. 다만 그의 제안이 결국 Azure 클라우드 인프라 사용을 전제로 한다는 점, 그리고 마이크로소프트 자사 Copilot이 기업 데이터에 광범위하게 접근하는 제품이라는 점에서 이해상충 지적도 나온다. 실제로 보안 업체 Concentric AI 조사에 따르면 Copilot은 2025년 상반기 기업당 평균 약 300만 건의 기밀 기록에 접근했고, EPC Group 감사에서는 마이크로소프트 365 테넌트의 약 80%가 과도한 공유 위험을 안고 있는 것으로 나타났다.

💡 파운데이션 모델을 프롬프트·메모리 계층에서 분리해 벤더 종속을 줄이려는 모델-애그노스틱 오케스트레이션(LangChain, Haystack 등) 채택이 기업 AI 아키텍처의 핵심 고려사항이 되고 있다.

Anthropic extends Fable 5 again — and won’t talk about what developers found inside Cursor

The New Stack

Anthropic이 모든 유료 구독자 대상 Claude Fable 5 확장 접근을 7월 19일까지 다시 연장했다. 5주 사이 세 번째 연장으로, 이전 마감 시한 종료 몇 시간 전인 일요일 저녁에 발표됐다. Pro·Max·Team 및 일부 Enterprise 요금제 사용자는 이 기간 동안 주간 사용량의 최대 50%까지 추가 비용 없이 Fable 5를 계속 쓸 수 있고, Claude Code의 주간 속도 제한 50% 증가 조치도 같은 날짜까지 유지된다. 프로모션 종료 후에는 입력 토큰 100만 개당 10달러, 출력 토큰 100만 개당 50달러가 청구되는데, 이는 Anthropic의 가장 비싼 요금제다. 일부 사용자들은 사용량이 초기화되지 않은 채 반복 연장되는 데 불만을 표하며 경쟁 모델로 이동하겠다는 반응도 나왔다. 이와 별개로 지난 7월 8일 개발자 도구 Cursor의 모델 목록에 "Claude Honeycomb EAP"라는 미공개 모델이 잠시 노출됐다가 사라졌는데, 유출된 스크린샷에는 민감한 프롬프트를 Opus 4.8로 라우팅하는 동작이 담겨 있어 커뮤니티에서는 이를 Opus 5의 초기 미리보기로 추정하고 있다. Anthropic은 이에 대해 공식 확인도 부인도 하지 않았다.

💡 프로모션 종료 시점(7월 19일) 이후 요금 정책 변화와 프롬프트 캐싱·배치 API를 통한 비용 절감 옵션을 미리 점검해 장기 실행 에이전틱 워크로드의 비용 급증에 대비할 필요가 있다.

Modernizing the Meta Ads Service With an Open-Source Kernel Scheduler

Meta Engineering

Meta 엔지니어링 블로그가 광고 서빙 플릿의 리눅스 커널 업그레이드 과정에서 발생한 지연 시간 회귀 문제를 sched_ext로 해결한 사례를 공개했다. 커널 v6.6에서 도입된 EEVDF 스케줄러로 업그레이드하는 과정에서 광고 랭킹 처리량이 줄어드는 회귀가 발생해 일부 호스트가 구버전 v6.4에 머물러야 했는데, 이를 해결하기 위해 BPF 기반의 확장형 스케줄러 프레임워크 sched_ext(커널 v6.12에 정식 편입, Google ghOSt 팀과 공동 개발)를 도입해 광고 워크로드 전용 스케줄링 정책을 작성했다. 이 정책은 CPU를 지연에 민감한 요청 경로용과 그렇지 않은 작업용 두 풀로 동적으로 나누고, 관련 작업을 같은 CPU에 유지시켜 L3 캐시 지역성을 높이는 방식으로 동작한다. 최초 도입만으로 광고 조회 단계의 p99 테일 레이턴시가 28% 줄고, 플릿 전체에서 3.28메가와트의 전력을 절감했으며, 광고 랭킹 수가 1.1% 증가했다. 이후 사용자 공간 정책만 갱신하는 후속 개선으로 p99 레이턴시가 추가로 60% 줄고 타임아웃 오류가 18% 감소했는데, 이는 커널 재빌드 없이 스케줄러 프로세스만 재시작하면 되는 sched_ext의 배포 방식 덕분에 가능했다. Meta는 이를 커널 업그레이드 임시방편이 아니라 지속적인 최적화 플랫폼으로 자리매김시켰다고 밝혔다.

💡 커널 업그레이드가 특정 워크로드에서 지연 시간 회귀를 일으킬 위험이 있는 조직이라면, sched_ext를 활용해 커널 재빌드 없이 사용자 공간 정책만으로 반복 실험·롤백이 가능한 워크로드별 스케줄링 최적화를 검토할 만하다.

Building an end-to-end reliability testing strategy with Grafana Cloud

Grafana

Grafana Cloud 블로그가 Synthetic Monitoring, Frontend Observability, k6 세 가지 솔루션을 계층적으로 결합해 신뢰성 테스트 전략을 구성하는 방법을 소개했다. 사고 예방 이론인 "스위스 치즈 모델"을 차용해, 어느 한 도구도 모든 장애를 잡아낼 수 없지만 여러 계층을 겹치면 결함이 사용자에게 도달할 확률이 크게 낮아진다는 논리를 편다. 데모 앱 QuickPizza를 예로 들어, 첫 번째 계층인 Synthetic Monitoring은 전 세계 프로브로 HTTP·브라우저·DNS·TCP·핑 체크를 스케줄 실행해 배포 직후의 회귀를 실사용자보다 먼저 감지하며, 실제로 특정 기능의 평균 지연이 4.87초로 늘어난 것을 가동률·도달률 지표만으로는 알 수 없던 문제로 잡아냈다. 두 번째 계층인 Frontend Observability는 오픈소스 Faro SDK로 수집한 실사용자 데이터를 통해 Core Web Vitals와 세션을 추적하는데, 예시에서는 First Contentful Paint 3.58초 지연과 스크립트로 미리 정의하지 않아 신테틱 체크가 놓친 자바스크립트 오류 6건을 발견했다. 세 번째 계층인 k6는 자바스크립트로 부하 테스트 스크립트를 작성해 CI에 통합, 수정한 문제가 실제 트래픽 상황에서도 유지되는지 배포 전에 검증하는 역할을 한다. 세 도구 모두 무료 티어에서 사용 가능하며, 이렇게 계층화된 접근은 결함이 사용자에게 도달하려면 여러 독립된 계층을 동시에 통과해야 하는 구조를 만든다.

💡 배포 전 체크, 실사용자 텔레메트리, 부하 테스트를 각각 별도 도구가 아니라 하나의 계층화된 파이프라인으로 설계하면, 신테틱 체크만으로는 놓치는 실사용자 오류나 부하 조건 회귀를 조기에 잡아낼 수 있다.

Lattice Watch: Smarter Guardrails for Design System Observability

Honeycomb

Honeycomb이 자사 디자인 시스템 Lattice의 준수 여부를 자동으로 감시하는 AI 코드 리뷰 파이프라인 "Lattice Watch"를 어떻게 구축했는지 소개했다. 기존에도 토큰 기반 린터로 하드코딩된 값 같은 명백한 위반은 CI에서 걸러낼 수 있었지만, 에이전트가 대신 코드를 작성하는 사례가 늘면서 창의적으로 규칙을 우회하는 미묘한 위반은 린터만으로 잡기 어려워졌다. 이를 보완하기 위해 프런트엔드 저장소의 모든 커밋에서 트리거되는 워크플로를 만들어 diff를 관련 파일로 필터링한 뒤 Claude에게 구조화된 프롬프트로 리뷰시키고, 위반 사항과 수정 제안을 PR 코멘트로 남기도록 했다(리뷰는 머지를 막지 않는 non-blocking 방식). 각 리뷰 결과(PR 번호, 작성자, 위반 유형, 수정 파일)는 Honeycomb 데이터셋으로 텔레메트리화되고, Honeycomb Canvas의 자연어 질의 기능을 통해 "위반율이 늘고 있는가", "누구를 도와야 하는가" 같은 질문에 답하며 패턴을 발견한다. 실제로 이 과정에서 개발자들이 자체적으로 플렉스박스 컴포넌트를 만드는 흔한 위반 패턴을 찾아 프롬프트에 반영했고, 레거시 API를 가진 컴포넌트가 에이전트를 혼란시키는 지점도 식별해 개선했으며, 린터 설정이 실수로 "warn"으로 되어 있던 문제도 리뷰 도중 발견해 고쳤다. Honeycomb은 이 3단계 구조(린터→AI 리뷰→텔레메트리)가 보안, 접근성, 성능 등 다른 영역의 가드레일에도 그대로 적용 가능하다고 설명한다.

💡 에이전트가 코드를 대신 작성하는 비중이 늘면서 규칙 기반 린터만으로는 창의적 우회를 막기 어려워지고 있어, AI 리뷰와 관측 데이터를 결합한 3단 가드레일 패턴은 디자인 시스템 외에도 보안·접근성 정책 준수 자동화에 참고할 만하다.

Preparing for the post-quantum era: Discover and prioritize now

HashiCorp

HashiCorp 블로그는 양자 이후 시대에 대비한 암호 체계 전환 전략을 다룬 글을 게재했다. 본문 페이지가 접근 제한(봇 차단)으로 확인되지 않아 아래는 제목과 RSS 발췌 기준의 요약이다. 글의 핵심 메시지는 조직이 양자 컴퓨팅 시대에 대응하는 전략을 세울 때 발견(discovery), 우선순위화(prioritization), 암호 민첩성(crypto agility)을 포함한 전체적인 접근을 취해야 한다는 것이다. 즉, 현재 시스템에 어떤 암호화 방식이 어디에 쓰이고 있는지부터 파악하고, 양자 컴퓨터에 취약한 요소를 가려내 교체 우선순위를 매긴 뒤, 향후 알고리즘이 바뀌어도 유연하게 전환할 수 있는 아키텍처를 갖추라는 권고로 요약된다. 구체적인 제품 기능이나 수치는 원문에서 확인하지 못했으므로 이 요약에는 포함하지 않았다. 포스트-퀀텀 암호(PQC) 전환은 TLS, VPN, 비밀 관리 등 HashiCorp의 제품군(Vault 등)과 직결되는 주제로 다뤄졌을 가능성이 높다. 정확한 권고안과 로드맵은 원문(hashicorp.com/blog)에서 직접 확인하는 것이 안전하다.

💡 양자 내성 암호로의 전환은 아직 먼 이야기처럼 보여도, 지금 어떤 시스템이 어떤 암호화 방식에 의존하는지 인벤토리를 만들어두는 "발견" 단계는 비용이 낮고 나중에 전환 시점을 크게 단축시킨다.


이 다이제스트는 RSS 피드에서 수집한 뒤 AI(Claude)가 요약·정리했습니다. 자세한 내용은 원문 링크를 확인하세요.