Techlist.io - 한국 테크 블로그 큐레이터

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

Cloudflare Workers와 Containers, 이제 인바운드 TCP 연결 및 gRPC 지원

Cloudflare는 Workers에 인바운드 TCP 소켓을 직접 처리하는 `connect(socket)` 기능과 컨테이너 기반의 양방향 gRPC 지원을 추가했습니다. 이를 통해 클라이언트의 TCP 연결을 Worker, Durable Object, Container로 전달하고, 다양한 언어로 작성된 gRPC 서버를 Cloudflare 네트워크에서 실행할 수 있습니다. 특히 저지연·양방향 통신이 중요한 음성 AI와 실시간 애플리케이션을 클라이언트 가까이에서 처리하는 것이 목표입니다. ## Workers의 인바운드 TCP 지원 - 기존 Workers는 주로 HTTP 요청을 처리하거나 아웃바운드 TCP 연결을 생성하는 방식이었지만, 이제 `connect(socket)` 핸들러로 들어오는 TCP 연결을 받을 수 있습니다. - 소켓은 `readable`과 `writable` 스트림으로 제공되며, 다음과 같이 데이터를 읽고 쓸 수 있습니다. - `socket.writable.getWriter()`로 데이터 전송 - `socket.readable.pipeTo(...)`로 다른 소켓에 데이터 전달 - TCP 연결을 Worker에서 직접 종료하거나, 다른 Worker·Durable Object·Container로 라우팅할 수 있습니다. ## Durable Objects와 Container로 소켓 전달 - Worker는 Durable Object의 `connect()` 메서드를 호출해 인바운드 소켓을 특정 객체로 전달할 수 있습니다. - Durable Object는 양방향 스트림을 연결해 클라이언트와 서버 사이의 바이트를 그대로 중계할 수 있습니다. - Durable Object에서 Container의 TCP 포트에 연결한 뒤 다음과 같이 양방향 파이프를 구성합니다. - 클라이언트 → Container - Container → 클라이언트 - Container에서는 Python, Go 등 원하는 언어와 TCP 서버 구현을 사용할 수 있습니다. - 따라서 특정 RPC 프레임워크에 종속되지 않고, TCP를 사용하는 어떤 프로토콜이나 프로그램도 Cloudflare에서 처리할 수 있습니다. ## Spectrum을 이용한 TCP 진입점 - Cloudflare Spectrum은 HTTP가 아닌 TCP·UDP 트래픽을 Cloudflare 네트워크로 받아들이는 인그레스 프록시입니다. - 새로운 Spectrum 애플리케이션 유형에서는 유입된 TCP 연결을 지정한 Worker의 `connect(socket)` 핸들러로 전달할 수 있습니다. - 결과적으로 클라이언트부터 Cloudflare Worker, Durable Object, Container 내부 서버까지 전체 네트워크 경로를 제어할 수 있습니다. ## Cloudflare Containers의 양방향 gRPC - gRPC는 HTTP/2와 TCP를 기반으로 하는 RPC 프레임워크로, 모바일 앱·분산 시스템·음성 AI 서비스에서 널리 사용됩니다. - 실시간 음성 애플리케이션은 단일 연결에서 클라이언트와 서버가 모두 지속적으로 메시지를 보내야 하므로 양방향 스트리밍이 중요합니다. - Cloudflare의 새 기능을 사용하면 다음과 같은 gRPC 서버를 Container에 배포할 수 있습니다. - 모든 언어로 작성된 gRPC 서버 - 클라이언트와 서버 간 full-duplex 양방향 스트리밍 - 지속적인 단일 TCP 연결 - 예시 gRPC 서버는 연결 직후 `connected` 메시지를 보내고, 클라이언트 메시지마다 `echo` 응답을 보내며, 연결 종료 시 `goodbye` 메시지를 전송합니다. - Cloudflare는 330개 이상의 위치에서 요청을 처리하므로, 서버를 사용자와 가까운 위치에서 실행해 지연 시간을 줄일 수 있습니다. ## Workers 기반 gRPC API - Workers에서는 gRPC 서버를 직접 구현하거나 기존 gRPC 서버를 호출할 수 있습니다. - 개발자는 `gRPC-web` 방식으로 코드를 작성하고, Cloudflare가 요청과 응답을 실제 gRPC 형식으로 변환합니다. - 지원 범위에는 다음이 포함됩니다. - 단일 요청·응답 방식인 unary RPC - 서버가 여러 메시지를 보내는 server-streaming RPC - Container로 소켓을 직접 전달하는 양방향 스트리밍 gRPC - 이 기능을 활용하면 기존 gRPC 생태계를 유지하면서 Cloudflare의 글로벌 네트워크와 Workers의 라우팅 기능을 함께 사용할 수 있습니다. ## 음성 AI와 실시간 서비스에 대한 의미 - AI 음성 비서, 실시간 받아쓰기, 음성 기반 에이전트는 모델·클라이언트·지원 서비스 사이의 낮은 지연 시간이 필수적입니다. - WebSockets와 Durable Objects도 적합하지만, 이미 gRPC를 사용하는 기존 시스템은 새 인프라로 전면 재작성할 필요가 줄어듭니다. - Cloudflare는 TCP 연결을 직접 전달하므로 음성 데이터나 스트리밍 추론 요청처럼 연결을 오래 유지하는 서비스에 적합합니다. - 해당 기능은 현재 프라이빗 베타로 제공되며, 사용을 위해 별도 신청이 필요합니다. 실시간 음성 AI나 기존 gRPC 시스템을 Cloudflare에 배포하려는 경우, `connect(socket)`을 이용해 Worker–Durable Object–Container 간 양방향 스트림을 구성하는 방식이 유용합니다. 다만 현재는 프라이빗 베타이므로 실제 도입 전 지원 프로토콜, 연결 수명, 지연 시간, 비용 및 운영 제한을 확인하는 것이 좋습니다.

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

Cloudflare Workersgrpcdurable-objectstcp+3

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

더 작고, 더 빠르고, 더 안전하게: Kimi와 GLM을 대규모로 실행하기

Cloudflare는 대규모·장문 컨텍스트 MoE 모델인 Kimi와 GLM을 GPU 메모리에 효율적으로 탑재하기 위해 KV 캐시 양자화, 모델 가중치 압축, 공유 캐시 무결성 검사를 적용했다. FP8 KV 캐시와 INT4 가중치는 정확도를 거의 유지하면서 동시 처리량과 비용을 개선하며, 캐시 무결성 검사는 1% 미만의 오버헤드로 데이터 오염 위험을 줄인다. 특히 프리필과 디코드 단계를 분리해 각 단계에 가장 적합한 정밀도를 선택한 것이 핵심이다. ## 장문 컨텍스트의 메모리 병목 - 모델 추론에서 GPU 메모리는 크게 두 부분이 사용된다. - 모델 가중치 - 이전 토큰의 어텐션 Key·Value를 저장하는 KV 캐시 - 장문 컨텍스트 모델에서는 가중치보다 KV 캐시가 먼저 메모리를 가득 채우는 경우가 많다. - Cloudflare는 모든 실험과 운영 트래픽에 오픈소스 추론 프레임워크 SGLang을 사용한다. - 프리필(prefill)은 입력 전체를 처리하는 단계이고, 디코드(decode)는 토큰을 하나씩 생성하는 단계다. - 프리필: 주로 연산량에 제한됨 - 디코드: 메모리 용량과 메모리 대역폭에 제한됨 ## FP8 기반 KV 캐시 양자화 - 기본 BF16 형식의 KV 캐시를 FP8(e4m3)로 저장해 캐시 크기를 절반으로 줄였다. - Kimi K2.6에서는 GPU에 저장 가능한 컨텍스트가 약 68만 6천 토큰에서 137만 토큰으로 증가했다. - 단일 동시 요청에서는 FP8 변환 비용 때문에 BF16보다 토큰 처리 속도가 몇 퍼센트 느리다. - 그러나 더 많은 요청을 동시에 수용할 수 있다. - BF16: 동시 요청 32개에서 메모리 부족 - FP8: 동시 요청 64개까지 처리 - 최대 처리량: 약 41% 증가 - 토큰당 비용: 약 30% 감소 - 프리필은 메모리보다 연산이 병목이므로 BF16을 유지하고, 디코드에만 FP8을 적용한다. - 평가 결과 FP8과 BF16의 성능 차이는 사실상 구분하기 어려웠다. - GSM8K, ARC, MMLU 등 주요 벤치마크에서 점수 차이가 미미함 - 도구 호출 유효성도 BF16 92.2%, FP8 92.6%로 유사 ## INT4 기반 모델 가중치 압축 - GLM 5.2의 가중치를 FP8에서 INT4로 줄였다. - 모델 체크포인트 크기: - 705GB → 421GB - 약 40% 감소 - 8-way 텐서 병렬 구성에서 GPU당 가중치 메모리: - 약 88GB → 52GB - 확보된 공간으로 동일한 하드웨어에서 약 118만 토큰의 KV 캐시를 수용할 수 있다. - 디코드에서는 매 토큰 생성 시 가중치를 GPU 메모리에서 읽어야 하므로, 가중치가 작을수록 메모리 대역폭 부담이 줄어든다. - INT4 디코드 성능 개선: - 동시 요청 1개: 60 → 92 tok/s, 55% 향상 - 동시 요청 8개: 21% 향상 - 동시 요청 32개: 27% 향상 - 반면 프리필에서는 INT4 가중치를 연산 전에 확장해야 하므로 느려진다. - FP8: 약 10,160 tok/s - INT4: 약 8,660 tok/s - 따라서 디코드는 INT4, 프리필은 FP8로 실행하는 방식이 가장 효율적이다. - 벤치마크 전반에서 INT4와 FP8의 정확도 차이는 0.8점 이내로, 실질적인 품질 저하가 관찰되지 않았다. ## 공유 KV 캐시 무결성 검사 - 캐시 압축으로 더 많은 요청이 같은 GPU와 물리적 KV 캐시 페이지를 공유하게 되면서, 페이지 재사용 오류의 위험도 커진다. - Cloudflare는 각 물리적 캐시 페이지에 재할당 때마다 바뀌는 태그를 부여했다. - 요청마다 사용할 페이지와 태그 정보를 기록하고, 디코드 전에 실제 매핑과 일치하는지 검사한다. - 불일치가 발생하면 잘못된 캐시 데이터를 반환하지 않고 해당 요청을 중단한다. - 검사는 어텐션 커널에 직접 삽입하지 않고 별도의 배치 검사로 실행해 GPU 스레드 간 경쟁 상태를 피했다. - 측정 결과 오버헤드는 매우 작았다. - 처리량 감소: 약 0.38~0.79% - p95 지연시간 증가: 약 0.42~0.80% - 기능이 필요 없는 배포 환경에서는 기본 no-op 추적기를 사용해 측정 가능한 오버헤드가 없다. ## 향후 방향 - 더 많은 모델과 배포 환경에 FP8 KV 캐시를 확대할 예정이다. - NVIDIA Blackwell GPU에서 NVFP4 가중치를 검증하고 있다. - KV 캐시 무결성 검사를 거의 비용 없이 모든 환경에서 활성화하는 것을 목표로 한다. - 이러한 최적화는 정확도를 유지하면서 더 많은 고객에게 낮은 비용으로 모델을 제공하기 위한 기반이다. 실용적으로는 추론 단계를 하나의 설정으로 처리하기보다, 프리필과 디코드의 병목이 다르다는 점을 반영해 정밀도를 분리하는 것이 중요하다. 디코드에는 FP8 KV 캐시와 INT4 가중치를, 프리필에는 BF16 KV 캐시와 FP8 가중치를 선택하는 방식이 대표적인 최적화 전략이다.

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

gpu-inferencemixture-of-expertskv-cachecontinuous-batching+4

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

Billable Usage API 소개: Cloudflare 비용을 프로그래밍 방식으로 확인하기

에이전트가 코드를 작성하고 Cloudflare 리소스를 배포·관리하면서, 자동화된 비용 가시성의 필요성이 커지고 있다. Cloudflare는 이를 위해 계정별 제품·서비스 기간별 사용량과 비용을 제공하는 Billable Usage API를 출시했다. 이 API는 FOCUS 표준과 유사한 필드 구조를 사용해 FinOps 도구나 다른 자동화 시스템에서 Cloudflare 비용을 쉽게 통합하도록 설계됐다. ## 자동화를 위한 Cloudflare Billable Usage API - 셀프서비스 계정에서 단일 API 엔드포인트로 사용량과 비용을 조회할 수 있다. - 지원 제품에는 다음이 포함된다. - Workers - R2 - D1 - Workers AI - Vectorize - Images - Stream - 기본 요청 예시: ```bash curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/billable-usage" \ -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" ``` - `from`, `to` 파라미터로 조회 기간을 지정할 수 있다. - 현재 데이터는 일 단위로 갱신되며, 향후 더 실시간에 가까운 데이터 제공을 목표로 한다. - 응답은 HTTP 200과 JSON 형식이며, Cloudflare 표준 API 구조인 `result`, `success`, `errors`, `messages`를 사용한다. ## 응답 데이터의 구성 각 응답 행은 계정 내 특정 제품의 하나의 과금 기간을 나타낸다. - `ServiceName`, `ServiceFamilyName` - 제품명과 제품군을 표시한다. - 예: `Workers Standard`와 `Workers` - `ChargePeriodStart`, `ChargePeriodEnd` - 해당 행이 포함하는 사용량·과금 기간이다. - `PricingQuantity`, `ConsumedUnit` - 과금 기준으로 측정된 사용량과 단위다. - 예: GB-months, GB-seconds, 요청 수 등 - `ContractedCost`, `BillingCurrency` - 해당 기간의 비용과 통화다. - `CumulatedPricingQuantity`, `CumulatedContractedCost` - 청구 기간 동안 누적된 사용량과 비용이다. - `ZoneId`, `ZoneName` - 특정 Cloudflare Zone에 귀속되는 사용량인 경우 제공된다. - 응답에는 `BillingPeriodStart`도 포함될 수 있어 전체 청구 기간을 확인할 수 있다. ## FOCUS 표준과의 호환성 Cloudflare는 여러 클라우드·SaaS 제공업체와 비용 관리 도구가 사용하는 FOCUS(Open Cost and Usage Specification)와 유사한 필드명을 채택했다. - `BillingCurrency`, `BillingPeriodStart` - `ChargePeriodStart`, `ChargePeriodEnd` - `ServiceName` - `ConsumedQuantity`, `ConsumedUnit` - `PricingQuantity` - `ContractedCost` 다만 현재 API가 FOCUS 전체 사양을 완전히 준수하는 것은 아니다. - `ServiceFamilyName`은 FOCUS의 `ServiceCategory`와 비슷하지만 Cloudflare 고유의 제품군 분류다. - `ZoneId`, `ZoneName`은 FOCUS의 `ResourceId`, `ResourceName`과 유사한 역할을 한다. - `CumulatedContractedCost`는 편의상 제공되는 누적 필드이며, FOCUS에서는 일반적으로 쿼리로 계산한다. - FOCUS에서 요구하는 일부 컬럼은 아직 제공되지 않으며, 완전한 준수는 향후 로드맵에 포함돼 있다. ## Vantage를 통한 멀티 클라우드 비용 관리 Cloudflare는 인프라 비용 관리 플랫폼 Vantage와 네이티브 통합을 제공한다. - Billing Read 권한이 있는 읽기 전용 API 토큰으로 Cloudflare를 연결한다. - Vantage는 Billable Usage 데이터를 매일 가져와 다음 기준으로 비용을 분류한다. - 제품 - Zone - 계정 - AWS, Azure 등 다른 클라우드 비용과 Cloudflare 비용을 하나의 보고서에서 비교할 수 있다. - 지원되는 활용 사례: - 팀·제품별 비용 할당 - Workers나 R2 비용 증가에 대한 이상 탐지 - Slack·이메일 기반 비용 알림 - FinOps 에이전트와 MCP를 통한 자연어 비용 조회 - 수동 내보내기나 청구서 업로드 없이 기존 Cost Reports, Budgets, Cost Alerts에 Cloudflare 비용을 포함할 수 있다. ## 에이전트 시대의 비용 가시성 - 에이전트는 코드 작성뿐 아니라 Workers 배포, R2 버킷 생성, D1 데이터베이스 관리까지 수행한다. - 프로그램에 Cloudflare 계정 접근 권한을 부여할수록, 프로그램이 발생시키는 비용을 API로 추적할 필요도 커진다. - 대시보드는 사람이 확인하기에는 적합하지만, 자동화·에이전트·FinOps 시스템이 처리하기에는 구조화된 API가 더 적합하다. - 이번 API는 Cloudflare 사용량을 다른 클라우드 비용 데이터와 함께 분석하기 위한 기반이다. 실무에서는 읽기 전용 Billing 권한의 API 토큰을 사용해 일일 비용 데이터를 수집하고, 제품·Zone·팀 단위로 예산과 알림을 설정하는 것이 권장된다. FOCUS 기반 도구를 사용한다면 현재 필드로 통합을 시작하되, 아직 완전한 FOCUS 준수 단계는 아니라는 점을 고려해야 한다.

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

모델 컨텍스트 프로토콜cloudflareCloudflare Workersfinops+3

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

DS와 MLE가 함께 일하는 법

토스뱅크는 DS와 MLE 사이의 역할 경계를 사람이나 파일이 아닌 명시적인 인터페이스로 정의하면서 ML 모델 배포 협업을 개선했습니다. 노트북 전달 방식에서 `.py` 파일 공유를 거쳐, 전처리·추론·후처리를 구현한 모델 패키지를 `pip install`로 배포하는 구조로 발전했습니다. 여기에 모노레포, 공통 추상화, CI, AI 코딩 스타일 규칙을 결합해 배포 속도와 일관성을 높였습니다. ## 노트북 전달 방식의 한계 - Phase 0에서는 DS가 주피터 노트북에서 학습과 추론 코드를 모두 작성하고, MLE가 이를 바탕으로 서빙 코드를 처음부터 다시 작성했습니다. - 라이브러리, 설정 파일, 소스 코드가 흩어져 있어 실행 환경을 재현하기 어려웠습니다. - 노트북에서 동작하던 전처리나 설정을 MLE가 다르게 해석하는 문제가 발생했습니다. - 모델 수가 늘어날수록 파일 요청과 커뮤니케이션 비용이 크게 증가했습니다. - 역할의 경계가 코드가 아니라 사람 사이에 있었기 때문에 책임과 작업 범위가 불명확했습니다. ## `.py` 파일로 추론 로직 분리 - Phase 1에서는 DS가 노트북에서 핵심 추론 로직을 별도의 `.py` 파일로 분리했습니다. - 노트북은 학습과 실험에 집중하고, 실제 모델 로직은 코드 파일로 관리했습니다. - MLE 리뷰와 CI 검증을 거치도록 하면서 DS의 의도를 더 정확히 보존할 수 있었습니다. - 그러나 모델마다 함수 이름이 `predict()`, `run()`, `inference()` 등으로 달라 인터페이스가 통일되지 않았습니다. - 서빙 환경으로 코드를 옮길 때 환경 차이로 수정이 필요했고, 로깅·메트릭·에러 처리를 공통으로 적용하기도 어려웠습니다. - 노트북에서 전역 설정을 변경한 코드가 여러 모델이 실행되는 서빙 프로세스에 영향을 주는 문제도 있었습니다. ## 인터페이스를 통한 역할 분리 - Phase 2에서는 `commons-ml-model` 패키지에 모델의 표준 구조를 정의했습니다. - 추상화 클래스가 다음 세 가지 인터페이스를 제공합니다. - `pre_process`: 입력 데이터 전처리 - `inference`: 모델 추론 - `post_process`: 결과 후처리 - DS는 위 메서드의 구현체를 작성하고 모델을 하나의 패키지로 배포합니다. - MLE는 해당 패키지를 설치해 서비스에 연결하므로 코드를 직접 복사하거나 재작성하지 않습니다. - 추상화 클래스가 추론 전후에 공통으로 다음 기능을 처리합니다. - 요청 추적을 위한 `trace_id` - 추론 시작·완료 로그 - 실행 시간 측정 - 메트릭 기록 - 결과적으로 DS는 모델 동작에 집중하고, MLE는 서비스 인프라와 운영 기능을 담당하게 됐습니다. - 공통 관측 기능을 추상화 클래스 한 곳에서 수정하면 모든 모델에 일괄 적용할 수 있습니다. ## 모노레포와 `uv` 워크스페이스 - 여러 모델 패키지와 공통 추상화 패키지를 하나의 저장소에서 관리했습니다. - `uv` 워크스페이스를 사용해 DS와 MLE가 같은 코드베이스에서 작업하고 리뷰할 수 있도록 했습니다. - 공통 인터페이스 변경과 모델 패키지 수정이 하나의 PR에서 함께 이뤄졌습니다. - CI, 버전 관리, 배포 정책을 저장소 단위로 통일할 수 있었습니다. - 공통 패키지 변경이 모든 모델에 영향을 줄 수 있다는 위험도 존재합니다. - 모델과 패키지가 늘면서 빌드가 느려졌고, Poetry에서 `uv`로 전환해 빌드 속도를 약 3~5배 개선했습니다. ## AI 시대의 코드 스타일 통일 - AI가 코드를 작성하면서 같은 기능도 예외 처리, 네이밍, enum 사용 방식 등이 사람마다 달라지는 문제가 생겼습니다. - 인터페이스가 같더라도 코드의 세부적인 작성 방식이 달라 리뷰 비용이 증가했습니다. - 팀 규칙 모음인 `pfmls-stylepack`을 도입해 AI가 코드 작성 단계부터 팀 컨벤션을 따르도록 했습니다. - Hook을 활용해 네이밍, 예외 처리, 고정값과 enum 사용 기준 등을 자동 적용했습니다. - 규칙이 적용된 코드에는 그 이유를 표시해 리뷰어가 변경 의도를 쉽게 파악하도록 했습니다. - 협업 표준을 두 층위로 나눴습니다. - 구조 표준화: 인터페이스로 담당 범위와 코드 형태 통일 - 스타일 표준화: 컨벤션으로 구현 방식과 코드 결 통일 ## 도입 과정에서 얻은 교훈 - 인터페이스는 너무 엄격하면 DS의 모델별 커스터마이징을 막고, 너무 느슨하면 다시 구현 방식이 제각각이 될 수 있습니다. - 초기에는 가이드 문서를 제공하고 DS와 MLE가 첫 모델을 페어로 함께 만드는 방식이 효과적입니다. - 공통 라이브러리는 한 번의 수정으로 전체 모델에 개선을 적용할 수 있지만, 반대로 전체 모델에 장애를 전파할 수도 있습니다. - 기존 모델 패키지를 참고 코드로 제공하면 새로운 구성원의 러닝 커브를 줄일 수 있습니다. - AI 활용이 늘어날수록 기능의 책임뿐 아니라 코드 작성 방식까지 명시적으로 관리해야 합니다. 실무적으로는 모델 배포 과정에서 “누가 무엇을 한다”를 문서로만 정의하기보다, 추상화 클래스와 패키지 구조로 강제하는 것이 효과적입니다. 먼저 전처리·추론·후처리 같은 최소 인터페이스를 정하고, 공통 로깅·메트릭·CI를 그 바깥에 배치하는 방식부터 시작하는 것을 추천합니다.

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

머신러닝CI/CDPythonAPI 설계+4

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

Claude와 GitLab으로 모든 커밋을 프로덕션까지 안전하게 배포하세요

Claude은 코딩 세션 중 취약점을 발견하고 수정하는 데 유용하지만, 커밋 이후의 병합·의존성·인프라 변경·감사까지 대체할 수는 없다. 글은 Claude Security와 GitLab을 연계해 작성 단계부터 프로덕션 배포까지 보안 검사를 지속하고, 정책을 강제하며, 감사 증거를 자동으로 남기는 방식을 제안한다. Claude가 작성 시점을 담당하고 GitLab이 이후 전체 소프트웨어 공급망을 관리하는 구조다. ## 세션 내 보안 점검에서 강제 가능한 정책으로 - Claude 보안 가이던스 플러그인은 개발자의 코딩 세션 안에서 취약점을 빠르게 찾아 수정하도록 돕는다. - 코드가 세션 밖으로 나간 뒤에는 보안팀이 어떤 검사가 수행됐는지 확인하고 후속 작업을 통제해야 한다. - GitLab 보안 구성 프로필을 사용하면 저장소 외부에서 필요한 스캔을 정의하고 여러 프로젝트와 파이프라인에 일괄 적용할 수 있다. - 병합 요청 승인 정책으로 변경을 작성한 에이전트나 해당 에이전트를 사용한 개발자가 자신의 코드를 직접 승인·병합하지 못하게 할 수 있다. - 해결되지 않은 치명적 취약점이 있는 병합 요청은 지정된 승인자가 승인할 때까지 차단된다. - 취약점 보고서와 보안 대시보드에서 각 취약점이 발견·무시·해결된 상태와 사유를 추적할 수 있다. ## 자동화된 감사 증거와 변경 이력 - SOC 2, PCI DSS, FedRAMP 같은 규정은 에이전트가 작성한 변경도 테스트·검토·승인됐다는 증거를 요구한다. - GitLab은 모든 병합 요청에서 스캔이 실행되도록 보장하고, 결과를 병합 요청과 취약점 보고서에 표시한다. - 파이프라인 로그, 승인 기록, 감사 이벤트를 통해 어떤 변경을 누가 또는 어떤 에이전트가 처리했는지 재현할 수 있다. - 규정 프레임워크별 요구사항에 보안 통제를 매핑할 수 있으며, 각 통제의 통과·대기·실패 상태를 보고서에서 확인할 수 있다. ## 모델로 전송되는 민감 데이터 통제 - 컨텍스트 제외 기능으로 인증 정보, 민감한 파일, 독점 로직, 규제 데이터를 모델에 보내지 않도록 설정할 수 있다. - 자체 관리 환경과 자체 호스팅 모델을 사용하면 코드와 추론 데이터를 조직 경계 안에 둘 수 있다. - 흐름별 허용 모델을 지정하고, 코드가 모델 학습에 사용되지 않도록 제한할 수 있다. - GitLab Duo의 프롬프트 가드레일은 모델에 전달되기 전 코드 제안에서 비밀정보를 탐지한다. - 프롬프트가 접근할 수 있는 콘텐츠를 제한해 프롬프트 인젝션 위험도 줄인다. ## 세션 단위 검사를 넘어선 전체 생명주기 보안 - 세션 기반 검사는 해당 시점의 코드만 다루므로, 이후 공개되는 의존성 취약점이나 이미 커밋된 비밀정보까지 발견하지 못할 수 있다. - GitLab은 다음 영역을 독립적으로 검사한다. - 의존성 취약점 - 컨테이너 이미지 - 인프라스트럭처 코드 - 비밀정보 유출 - 실행 중 애플리케이션에 대한 DAST - 결정론적 스캐너는 동일 코드에 대해 일관된 결과와 CWE 매핑을 제공해 감사에 적합하다. - 반면 비즈니스 로직 오류, 잘못된 권한 검사, 경쟁 조건처럼 일반 스캐너가 놓치기 쉬운 문제는 Security Review Flow가 코드의 의도를 분석해 보완한다. - 글은 Claude의 보안 검사를 인간 코드 리뷰와 다양한 보안 스캐너를 대체하는 수단이 아니라 보조 수단으로 규정한다. ## 사람과 에이전트에 동일한 보안 가드레일 적용 - Claude 플러그인은 Claude가 세션에서 작성·커밋한 코드에 집중한다. - 개발자가 셸에서 직접 작성하거나 세션 내 `!` 셸 이스케이프를 통해 실행한 변경은 플러그인 검토 범위를 벗어날 수 있다. - Claude Security는 개발자나 관리자가 필요할 때 전체 코드베이스 또는 사람이 작성한 코드도 검사할 수 있다. - GitLab의 스캔 실행 정책과 병합 승인 정책은 파이프라인에서 모든 변경에 적용된다. - 따라서 코드 작성자가 사람인지 에이전트인지, 개발자가 별도로 검사를 실행했는지에 관계없이 동일한 통제를 적용할 수 있다. ## 프로덕션에 도달하는 변경 통제 - Claude Security와 GitLab MCP 서버를 연결하면 기존 Claude 기반 개발 흐름을 유지하면서 GitLab의 정책·스캔·감사 기능을 활용할 수 있다. - 모든 기본 브랜치와 대상 프로젝트에 보안 스캔을 강제해 정책 우회를 어렵게 만든다. - 치명적 취약점, 미승인 변경, 누락된 검사 결과가 있는 코드는 배포 전에 차단할 수 있다. - 결과적으로 세션 안의 빠른 AI 보안 지원과 프로덕션 배포 전의 조직 차원 거버넌스를 하나의 흐름으로 결합한다. 실무에서는 Claude를 개발 중 취약점 탐지와 수정에 활용하되, GitLab에서 SAST·의존성·컨테이너·IaC·비밀정보·DAST 스캔과 승인 정책을 중앙 관리하는 구성이 권장된다. 특히 모델에 전송되는 파일을 사전에 제외하고, 에이전트와 사람 모두에게 동일한 승인·감사 규칙을 적용해야 한다.

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

gitlab모델 컨텍스트 프로토콜infrastructure-as-codesast+4

figma·2026년 8월 3일·3분 읽기큐레이션 요약

코드, 장인정신, 그리고 중첩 폴더의 제작 | Figma 블로그

Figma의 중첩 폴더는 단순한 파일 정리 기능이 아니라 콘텐츠 구조와 권한 모델을 재설계한 대규모 제품 작업이었다. 개발 과정에서 팀은 전통적인 순차형 프로세스 대신 코드로 아이디어를 빠르게 검증하고, 직무 경계를 유연하게 넘나들며, 인수인계를 대화 중심 협업으로 바꾸었다. 그 결과 변화하는 AI·코드 중심 환경에서도 복잡한 기능을 빠르게 구체화하고 출시할 수 있었다. ## 중첩 폴더가 단순한 기능이 아니었던 이유 - 중첩 폴더는 규모가 커지는 팀이 파일과 프로젝트를 계층적으로 정리하도록 돕는 기능이다. - 구현 범위는 파일 브라우저에 그치지 않았다. - 콘텐츠 구조 - 관리자 제어 - 공유 방식 - 권한 처리 - 핵심 인프라 - 따라서 기존 모델에 폴더 한 단계만 추가하는 방식이 아니라, Figma의 콘텐츠 및 권한 모델을 근본적으로 재검토해야 했다. ## 변화한 제품 개발 환경 - 프로젝트 초기에는 일반적인 순차형 개발 방식을 따랐다. - 제품팀이 요구사항을 정의 - 디자인팀이 사용자 경험을 설계 - 설계가 충분히 정리된 뒤 엔지니어링 시작 - 그러나 개발 중 팀의 자원과 우선순위가 달라졌다. - AI 네이티브 기능 개발로 인력이 분산됨 - Figma Make, MCP 서버, 에이전트 스킬, 코드베이스 프로토타이핑 등이 아이디어를 빠르게 구현하는 수단으로 부상함 - 아이디어는 더 이상 완성된 문서에서만 출발하지 않고, 프로토타입·코드·Slack의 간단한 스케치에서도 시작될 수 있게 되었다. ## 코드로 먼저 검증하기 - 코드 작성 비용이 낮아지면서 논쟁이나 추상적인 기획을 오래 이어가기보다 실제 구현물을 빠르게 만들 수 있게 되었다. - 팀은 아이디어를 검증하기 위해 초기부터 pull request(PR)를 생성했다. - PR은 단순한 최종 코드 리뷰 수단이 아니라 다음을 확인하는 실험 도구로 활용되었다. - 기술적으로 가능한지 - 사용자 경험이 자연스러운지 - 권한과 데이터 구조에 문제가 없는지 - 여러 대안 중 어떤 방향이 적절한지 - 실제 동작하는 결과물을 바탕으로 논의하면서 의사결정 속도와 피드백의 구체성이 높아졌다. ## 직무 경계를 유연하게 바꾸기 - 역할을 엄격히 분리하기보다 문제 해결에 필요한 사람이 해당 영역의 결정을 맡았다. - 엔지니어가 디자인 관련 결정을 내리고, 디자이너가 직접 코드를 작성하는 등 업무 범위가 서로 겹쳤다. - 제품 관리자는 일상적인 실행 관리에서 일부 벗어나 더 큰 전략적 질문에 집중했다. - 이 방식은 각 직무의 전문성을 없애는 것이 아니라, 프로젝트 상황에 따라 책임을 유연하게 배분하는 접근이다. ## 인수인계 대신 지속적인 대화 - 디자인 완료 후 개발로 넘기는 식의 일방적인 handoff를 줄였다. - 역할의 경계가 흐려지면서 팀원들은 서로에게 배우는 동시에 자신의 전문 지식을 공유하는 관계가 되었다. - 평소 각 직무가 독점하던 작업 방식과 판단 기준을 공개함으로써 협업에 필요한 신뢰를 쌓았다. - 결과적으로 디자인, 제품, 엔지니어링이 단계별로 분리된 프로세스가 아니라 지속적인 대화와 공동 결정에 가까워졌다. ## 실용적인 시사점 복잡한 기능을 개발할 때는 완벽한 사전 설계만 기다리기보다 작은 PR과 프로토타입으로 가설을 검증하는 것이 효과적이다. 또한 직무별 책임을 고정하기보다 문제의 성격에 따라 역할을 유연하게 조정하고, 인수인계 문서만으로 소통하기보다 실행 과정에서 지속적으로 대화하는 협업 구조를 만드는 것이 중요하다.

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

FigmaAI 에이전트mcp-servercode-prototyping+2

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

에이전트 주간에 오신 것을 환영합니다

에이전트 시대의 클라우드는 인간 중심으로 설계된 기존 클라우드를 단순히 확장하는 것이 아니라, 에이전트의 요구를 출발점으로 새롭게 설계해야 한다. 동시에 현재의 인간 중심 웹과 미래의 에이전트 중심 환경을 연결하는 번역 계층도 필요하다. Agents Week는 이러한 Agent Cloud의 구조와 실행 환경, 개발 생명주기, 보안, 웹의 변화를 다룬다. ### 인간 중심 클라우드의 한계 - 기존 클라우드와 웹은 사람이 직접 보고, 읽고, 클릭하고, 판단하는 상황을 전제로 설계됐다. - 페이지는 사용자의 관심을 끌도록 구성되고, 대시보드는 사람이 탐색하고 조작하기 쉽게 만들어졌다. - 에이전트는 사람처럼 피로하거나 산만해지지 않으며, 속도·구조화된 정보·시스템 접근성 등 다른 요구사항을 가진다. - 따라서 인간용 도구를 에이전트에게 그대로 제공하는 방식에는 한계가 있다. ### Agent Cloud의 두 가지 역할 - 장기적으로는 에이전트를 위한 기본 구성 요소를 처음부터 설계하는 ‘에이전트 네이티브’ 클라우드가 되어야 한다. - 단기적으로는 현재 존재하는 인간 중심 웹과 앞으로 등장할 에이전트 중심 웹 사이를 연결해야 한다. - 즉, Agent Cloud는 새로운 실행·저장 환경인 동시에 기존 시스템과 에이전트 간의 변환 계층 역할을 수행해야 한다. ### Agents Week에서 다루는 주제 - 에이전트에 필요한 스토리지·컴퓨팅·실행 프리미티브 - 인간의 개입을 최소화한 에이전트 중심 소프트웨어 개발 생명주기(ADLC) - 조직 내부의 시스템 오브 레코드에 에이전트와 직원이 안전하게 접근하는 방법 - 권한 관리와 안전한 제어를 통한 에이전트의 실제 업무 수행 - 정보 탐색, 서비스 접근, 결제 등을 포함한 에이전트 중심 웹의 변화 - 현재의 인간과 에이전트가 함께 일하는 현실적인 환경에서의 적용 방식 ### 에이전트에게 직접 요구사항 묻기 - Agent Cloud가 무엇이어야 하는지 사람의 관점에서 추측하기보다, 에이전트에게 직접 질문해야 한다는 것이 글의 핵심 제안이다. - 질문에는 다음과 같은 영역을 포함할 수 있다. - 스토리지와 컴퓨팅 - 실행 및 데이터 저장 프리미티브 - 인간의 개입이 줄어든 개발 생명주기 - 조직 내 핵심 시스템에 대한 안전한 접근 - 웹에서의 정보 발견, 서비스 이용, 결제 - 독자들이 자신의 에이전트에게 질문하고, 그 답변과 통찰을 공유하도록 권한다. 에이전트용 인프라를 설계할 때는 기존 인간 중심 인터페이스를 자동화하는 데 그치지 말고, 에이전트가 빠르고 구조화된 방식으로 실행·접근·판단할 수 있는 기본 요소부터 정의해야 한다. 동시에 권한, 보안, 기존 시스템과의 호환성을 갖춘 연결 계층을 마련하는 것이 현실적인 출발점이다.

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

AI 에이전트클라우드 컴퓨팅sdlcagent-cloud+2

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

분석을 위한 디바이스 기능 모델링

넷플릭스는 다양한 기기의 하드웨어·플랫폼 차이로 인해 기능 지원 여부가 달라지므로, 기기별 역량을 정교하게 모델링해야 한다고 설명합니다. 이를 위해 최신 기기 상태를 저장하는 누적 테이블과 최근 28일간의 활성 기기 분포를 집계하는 히스토그램 테이블을 구축했습니다. 이 데이터는 4K, 공간 음향, 클라우드 게임, 최신 UI 등의 기능 도달 범위를 분석하고 기기별 기능 활성화 여부를 안전하게 결정하는 데 활용됩니다. ## 기기 역량 모델링의 필요성 - 넷플릭스는 4K 스트리밍, 몰입형 오디오, 라이브 스트리밍, 클라우드 게임 등 다양한 기능을 제공합니다. - 기기마다 다음과 같은 하드웨어 및 플랫폼 제약이 존재합니다. - RAM 용량 - CPU 코어 수 - 화면 해상도와 외부 디스플레이 지원 - 비디오·오디오 프로필 - 운영체제 및 플랫폼 기능 지원 여부 - 따라서 모든 기기에 동일한 기능을 활성화하면 성능 저하나 사용자 경험 악화가 발생할 수 있습니다. - 기기 역량 데이터를 바탕으로 기능 지원 가능 여부를 세밀하게 판단하면 기능 확산의 병목을 찾고 출시 속도를 높일 수 있습니다. ## 최신 상태를 저장하는 누적 테이블 - 누적 테이블은 각 기기 모델의 최신 역량 상태를 저장하도록 설계되었습니다. - 기기별로 다음과 같은 정보를 기록할 수 있습니다. - 화면 너비와 높이 - 지원되는 비디오 프로필 - 서라운드 사운드 지원 여부 - RAM 크기 - 기타 하드웨어 및 플랫폼 기능 - 예시 데이터는 한 기기가 1280×720 해상도와 `playready`, `hevc` 비디오 프로필을 지원함을 나타냅니다. ```json { "Screen Height": ["720"], "Screen Width": ["1280"], "Video Profiles": ["playready", "hevc"] } ``` - 최신 상태 중심으로 데이터를 관리하기 때문에 분석 및 리포팅 시스템에서 현재 기기 환경을 효율적으로 조회할 수 있습니다. ## 최근 활성 기기 분포를 보여주는 히스토그램 테이블 - 집계 분석에는 최근 28일 동안 활성 상태였던 기기 수를 기록하는 히스토그램 테이블을 사용합니다. - 데이터는 다음 기준으로 세분화됩니다. - 기기 모델 - 소프트웨어 버전 - 특정 기능 또는 역량 지원 여부 - 전체 활성 기기 중 특정 역량을 지원하는 기기의 비율을 계산할 수 있습니다. - 예를 들어 스트리밍 스틱에 연결된 외부 디스플레이 역량을 분석할 때 다음과 같이 확인할 수 있습니다. - 전체 기기의 100%가 HD용 `playready` 프로필 지원 - 전체 기기의 20%만 UHD용 `hevc` 프로필 지원 - 단순히 “기기 모델이 기능을 지원한다”는 정보가 아니라, 실제 사용 중인 기기 집단에서 해당 기능이 어느 정도 보급되어 있는지 파악할 수 있다는 점이 중요합니다. ## 기능 플래그와 분석 제품의 결합 - 기기 역량 데이터는 내부 시스템의 기능 플래그와 통합됩니다. - 이를 통해 특정 기기 모델이나 소프트웨어 버전에만 기능을 활성화하는 세밀한 제어가 가능합니다. - 분석 제품은 다음 기능의 도달 범위를 파악하는 데 활용됩니다. - 4K Ultra HD - Netflix Spatial Audio - 클라우드 게임 - 최신 사용자 인터페이스 - 실제 기기 지원률과 성능 데이터를 기반으로 기능을 활성화하므로 안정성과 성능을 함께 고려할 수 있습니다. ## 기대 효과 - 기능이 지원되지 않는 기기에 잘못 배포되는 문제를 줄일 수 있습니다. - 특정 기기나 소프트웨어 버전에서 발생하는 기능 확산의 병목을 식별할 수 있습니다. - 기능 출시 전 지원 가능한 사용자 규모를 예측할 수 있습니다. - 전 세계의 다양한 기기 생태계에 맞춰 기능을 점진적이고 안전하게 확장할 수 있습니다. 실무적으로는 기기별 최신 상태와 실제 활성 기기 분포를 분리해 관리하고, 이를 기능 플래그와 연결하는 방식이 효과적입니다. 특히 기능 지원 여부뿐 아니라 실제 사용자 기기 중 지원 기기의 비율까지 함께 분석해야 기능 출시 범위와 우선순위를 정확하게 결정할 수 있습니다.

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

data-modelingvideo-streamingcloud-gamingfeature-flags+2

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

일찍 멈추지 마라: 메모리 속도로 소스 코드의 대소문자를 정규화하기

GitHub는 코드 검색 엔진 Blackbird에서 대규모로 수행되는 유니코드 케이스 폴딩을 메모리 대역폭에 가까운 속도로 최적화했다. 핵심은 비ASCII 문자를 만나면 즉시 중단하는 기존 최적화를 제거하고, 전체 버퍼를 분기 없이 처리해 컴파일러의 SIMD 벡터화를 유도한 것이다. Apple M4에서 단순 구현의 약 3.1GiB/s 처리량을 45GiB/s 이상으로 끌어올렸으며, 분기 없는 코드는 벡터화를 가능하게 할 때만 이점이 있다는 점도 확인했다. ## 케이스 폴딩과 소문자 변환의 차이 - 케이스 폴딩은 표시를 위한 변환이 아니라 문자열 비교를 위한 정규화다. - 대소문자만 다른 문자열을 동일하게 취급하기 위해 사용된다. - 검색 엔진 - 정규식의 `(?i)` 옵션 - 대소문자를 구분하지 않는 사용자명과 호스트명 - 일반적인 소문자 변환과 달리 케이스 폴딩은: - 로케일에 독립적이다. - 문맥에 의존하지 않는다. - 비교 관계가 일관되고 대칭적이다. - 그리스어 final sigma, 터키어의 `I`, 독일어 `ß`처럼 소문자 변환과 케이스 폴딩 결과가 달라지는 문자가 있어 `to_lowercase`를 대체 수단으로 사용하면 잘못된 검색 결과가 발생할 수 있다. - 공개된 Rust `casefold` 크레이트는 Unicode `CaseFolding.txt`의 단일 문자 변환인 C·S 상태만 구현한다. - `ß → ss`와 같은 다중 문자 변환은 지원하지 않는다. - 터키어 전용 폴딩도 지원하지 않는다. - ripgrep과 정규식 엔진도 유사한 제한을 둔다. ## GitHub에서 케이스 폴딩이 중요한 이유 - Blackbird는 1억 8천만 개 이상의 저장소와 480TB가 넘는 소스 코드를 색인한다. - 색인 전에 모든 바이트를 폴딩하고, 검색 결과 후보를 확인할 때도 케이스 폴딩이 반복적으로 수행된다. - 소스 코드는 대부분 ASCII이므로 ASCII 경로를 메모리 속도로 처리하는 것이 가장 큰 성능 개선 요소다. - 비ASCII 입력은 드물기 때문에, 최적화의 목표는: - 흔한 ASCII 경로를 최대한 빠르게 만들고 - 드문 유니코드 경로가 ASCII 성능을 방해하지 않게 하는 것이다. ## 조기 종료를 제거한 ASCII 처리 기존 방식은 비ASCII 바이트를 만나면 즉시 반복문을 종료하고 유니코드 처리로 넘겼다. ```text if byte >= 0x80 { break } ``` 하지만 이 데이터 의존적 `break`는 컴파일러의 루프 벡터화를 막는다. 개선된 구현은 다음과 같이 동작한다. - 모든 바이트를 끝까지 순회한다. - `high_bit_acc |= byte`로 모든 바이트의 최상위 비트를 누적한다. - 반복문이 끝난 뒤 누적값을 한 번만 검사해 비ASCII 문자가 있었는지 확인한다. - 따라서 반복문 내부에는 데이터에 따른 분기나 조기 종료가 없다. 이 방식은 비ASCII 여부를 동일하게 알아내면서도 SIMD 명령을 사용할 수 있게 한다. ## 분기 없는 ASCII 대소문자 변환 ASCII 대문자 변환도 조건문 대신 산술 연산으로 처리한다. - `b.wrapping_sub(b'A') < 26` - 바이트가 `A`부터 `Z` 사이일 때만 참이 된다. - 별도의 분기 없이 대문자 여부를 0 또는 1 마스크로 만든다. - `u8::from(is_upper) << 5` - 대문자이면 ASCII의 비트 5를 설정해 소문자로 바꾼다. - 그 외 문자는 아무 변화가 없다. - 모든 바이트를 항상 저장하므로 조건부 저장 명령도 제거된다. 결과적으로 루프는 다음 특성을 갖는다. - 데이터 의존적 분기 없음 - 조기 종료 없음 - 연속적인 메모리 접근 - LLVM이 NEON 기반 16바이트 단위 SIMD 코드 생성 가능 ## 벤치마크와 성능 개선 Apple M4에서 5.7KB ASCII 버퍼를 처리한 누적 측정 결과는 다음과 같다. - 조기 종료와 분기 조건을 사용하는 순진한 구현: **3.1GiB/s** - 본문만 분기 없이 바꾸고 조기 종료를 유지한 구현: **2.6GiB/s** - 조기 종료를 제거한 구현: **7.6GiB/s** - 대문자 판별과 저장까지 분기 없이 처리한 최종 구현: **45GiB/s 이상** 성능 향상의 핵심은 단순히 분기를 없앤 것이 아니다. - 조기 종료 제거가 루프 벡터화를 가능하게 했다. - 대문자 변환의 분기 제거가 완전한 벡터화를 가능하게 했다. - 최종 성능은 사실상 메모리 대역폭 한계에 도달했다. ## 스칼라 코드에서는 분기 없는 방식이 느릴 수 있다 - 조기 종료를 유지한 채 본문만 분기 없이 바꾼 구현은 오히려 3.1GiB/s에서 2.6GiB/s로 느려졌다. - 기존 분기 방식은 실제로 값이 바뀌는 대문자일 때만 저장한다. - 소문자, 숫자, 공백이 대부분인 일반 텍스트에서는 조건부 저장 분기가 매우 잘 예측된다. - 반면 분기 없는 구현은 모든 바이트를 무조건 저장해 불필요한 쓰기 트래픽이 발생한다. - 따라서 분기 없는 코드는 그 자체로 항상 빠른 것이 아니다. - 이 사례에서는 분기 없는 코드가 SIMD 벡터화를 가능하게 하는 수단이었기 때문에 최종적으로 큰 이득을 냈다. 실용적으로는 데이터 규모가 크고 반복 횟수가 많은 바이트 처리에서 조기 종료가 정말 최적인지 확인해야 한다. 특히 루프의 조기 종료가 SIMD 벡터화를 막는다면, 전체 버퍼를 일정한 흐름으로 처리하고 마지막에 상태를 확인하는 방식이 훨씬 빠를 수 있다.

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

Rust성능 최적화unicodellvm+3

cloudflare·2026년 7월 31일·3분 읽기큐레이션 요약

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

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

cloudflarejwtcdnwebrtc+3

line·2026년 7월 31일·5분 읽기큐레이션 요약

Grafana에서 자연어로 장애 원인을 분석하기: LLM 에이전트 기반 SRELens 개발기

관측성 데이터가 메트릭·로그·트레이스·프로파일별로 분산되면, 장애 원인을 파악하기 위해 사람이 여러 도구를 오가며 맥락을 연결해야 합니다. LY Corporation의 Home SRE 팀은 이를 해결하기 위해 Grafana 플러그인인 SRELens를 개발했습니다. SRELens는 자연어 질문을 바탕으로 LLM 에이전트가 관측성 데이터를 조회하고, 도구 호출과 비용·권한·안전 정책을 백엔드에서 통제하며 원인 후보를 근거와 함께 제시합니다. ## 관측성 데이터가 분산되며 발생한 문제 - 메트릭은 Grafana·IMON, 로그는 LaaS·IU, 트레이스는 IMON 트레이스·Tempo, 프로파일은 별도 도구에서 확인해야 했습니다. - 장애 분석 과정에서 시간 범위, 서비스명, 라벨, 트레이스 ID 등의 맥락을 여러 시스템에 반복해서 옮겨야 했습니다. - 자체 호스팅형 LGTM-P 스택을 구축해 데이터를 통합했습니다. - Mimir: 메트릭 - Loki: 로그 - Tempo: 트레이스 - Pyroscope: 프로파일 - OpenTelemetry Collector: 데이터 수집 및 전달 - 데이터가 한곳에 모여도 사용자가 적절한 데이터소스와 라벨, 쿼리 방법을 알아야 한다는 문제는 남았습니다. - 예를 들어 서비스명이 데이터소스마다 `service_name`, `resource.service.name` 등 다른 필드로 표현될 수 있습니다. ## 오픈소스 PoC에서 확인한 한계 - **사용자 컨텍스트와 권한 전파** - Grafana 인증 사용자 정보를 대화 기록, 사용량 한도, 조회 권한에 안정적으로 연결하기 어려웠습니다. - **시스템 프롬프트 제어** - 도구 호출 순서, 재시도, 위험 작업 제한 같은 운영 정책을 사용자 질의와 분리해 보호하기 어려웠습니다. - **짧은 도구 호출 라운드** - 메트릭·트레이스·로그를 순차적으로 확인해야 하는 장애 분석을 충분히 수행하지 못했습니다. - **데이터소스별 라벨 차이** - 올바른 데이터소스를 선택해도 라벨이나 필드가 다르면 검색 결과가 0건이 될 수 있었습니다. - **운영 및 라이선스 제약** - 사내 환경에 맞게 수정하고 배포하는 데 한계가 있었습니다. - 이를 통해 단순한 자연어 질의 기능보다, LLM 에이전트의 행동을 운영 환경에 맞게 통제하는 것이 더 중요하다는 결론을 얻었습니다. ## SRELens 아키텍처 - SRELens는 Grafana 애플리케이션 플러그인으로 동작합니다. - 프런트엔드는 Grafana 내부에 채팅 UI를 제공합니다. - 백엔드는 다음을 담당합니다. - LLM 호출 - 시스템 프롬프트 합성 - 도구 오케스트레이션 - 사용량 및 비용 제한 - 결과 크기와 재시도 제어 - 관측성 데이터 조회는 MCP 게이트웨이를 통해 수행합니다. - 업스트림 MCP 도구 외에도 Grafana 패널 검색과 이미지 렌더링을 위한 로컬 도구를 제공합니다. - `find_grafana_panel` - `render_grafana_panel` - 업스트림 도구와 로컬 도구는 `CompositeClient`를 통해 LLM에 일관된 인터페이스로 노출됩니다. ## 세 계층으로 분리한 프롬프트 설계 ### 베이스 시스템 프롬프트 - 조직 전체에 적용되는 전역 행동 정책입니다. - 다음과 같은 규칙을 포함합니다. - 도구 호출 순서 - 결과가 없을 때의 폴백 전략 - 결과가 잘렸을 때 집계 쿼리를 재실행하는 방법 - 대시보드 생성·수정·삭제 등 위험 작업의 안전 규칙 - 응답 형식과 분석 근거 제시 방식 - 관리자만 수정할 수 있으며, 별도 설정이 없으면 코드에 포함된 기본 프롬프트를 사용합니다. ### 데이터소스 프래그먼트 - 환경별 관측성 시스템 정보를 YAML 형태로 제공합니다. - 주요 내용은 다음과 같습니다. - 우선 사용할 Mimir·Loki·Tempo 데이터소스 UID - 서비스명을 찾기 위한 라벨 후보 - Loki 로그의 JSON 파싱 및 구조화 메타데이터 처리 방법 - SRE의 운영 지식을 미리 제공해 불필요한 탐색을 줄이고 분석 성공률과 속도를 높입니다. ### 사용자 프롬프트 - 담당 서비스, 선호 응답 형식, 자주 사용하는 대시보드 등 개인·팀의 맥락을 저장합니다. - Redis에 저장되며 시스템 프롬프트의 추가 컨텍스트로 주입됩니다. - 베이스 프롬프트를 덮어쓰지 않으므로 개인화가 조직 공통 안전 정책보다 우선할 수 없습니다. ## 백엔드 중심의 툴 오케스트레이션 - 프런트엔드가 시스템 프롬프트를 조립하지 않고, 백엔드 오케스트레이터가 모든 프롬프트 합성을 담당합니다. - 에이전트는 다음 루프를 반복합니다. 1. 사용자 질문을 LLM에 전달 2. LLM이 요청한 MCP 또는 로컬 도구 실행 3. 도구 결과를 다시 LLM에 전달 4. 최종 분석이 나올 때까지 반복 - 운영 안정성을 위해 코드 수준의 가드레일을 적용했습니다. - 최대 10라운드로 도구 호출 제한 - 동일 도구·동일 인자의 중복 호출 차단 - 도구별 재시도 최대 2회 - 개별 도구 결과 크기 제한 - 전체 요청이 커질 경우 오래된 도구 결과를 플레이스홀더로 치환 - `tool_call_id`를 유지해 호출과 결과의 연결 보장 - 결과가 없으면 라벨, 시간 범위, 데이터소스를 바꿔 재시도하도록 유도 ## 비용·요청량 및 장애 대응 정책 - 사용자별 일일 토큰 한도를 적용합니다. - 분당 요청 수를 제한하고, 한도 초과 시 HTTP 429를 반환합니다. - 응답 후 OpenAI가 반환한 실제 프롬프트·출력 토큰 사용량을 사용자별 일일 버킷에 기록합니다. - 사용량은 Asia/Seoul 기준 자정에 초기화됩니다. - Redis는 대화 기록, 사용자 프롬프트, 쿼터 저장에 사용됩니다. - Redis 장애가 발생해도 단일 채팅 요청은 계속 처리할 수 있도록 설계했습니다. - 대화 기록 및 개인화 기능은 제한될 수 있습니다. - SRELens 전체가 동시에 중단되지는 않습니다. ## 실제 장애 분석 방식의 변화 - 사용자는 “특정 시간대에 왜 에러가 늘었는가”처럼 자연어로 질문할 수 있습니다. - SRELens는 하나의 분석 흐름에서 메트릭, 로그, 트레이스를 연결해 확인합니다. - 예시 시나리오에서는 베타 환경의 오류 급증을 분석하면서 특정 API 요청인 `CopyMedia` 호출 증가와 관련된 원인까지 범위를 좁혔습니다. - 기존처럼 대시보드, 로그 검색 시스템, 트레이스 도구를 오가며 사람이 상관관계를 직접 맞출 필요가 줄어듭니다. - 분석 결과는 단순한 결론이 아니라 조회된 관측성 데이터와 근거를 함께 제시하는 것을 목표로 합니다. 운영 환경에서 LLM 기반 장애 분석을 도입할 때는 자연어 인터페이스보다 통제 구조를 먼저 설계하는 것이 중요합니다. 조직 정책과 환경별 데이터소스 지식을 프롬프트 계층으로 분리하고, 도구 호출·권한·비용·재시도를 백엔드 코드로 제한해야 안정적이고 재현 가능한 분석 도구를 만들 수 있습니다.

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

옵저버빌리티모델 컨텍스트 프로토콜redisgrafana+3

figma·2026년 7월 31일·3분 읽기큐레이션 요약

AI 숙련도는 최종 목표가 아니다 | Figma 블로그

AI 도구를 잘 다루는 능력은 중요하지만, 그것만으로는 AI 시대의 성공을 보장할 수 없다. 더 중요한 역량은 개인의 생산성 향상을 팀 전체의 속도로 확장하고, 다양한 의견을 모아 결정을 내리며, 실험과 실패를 안전하게 공유하는 협업 능력이다. 결국 AI의 가치는 한 사람이 10배 빠르게 일하는 데보다 팀 전체가 함께 더 빠르고 현명하게 움직이는 데 있다. ## AI 활용 능력 이상의 역량 - 제품 개발자 90% 이상이 AI 활용 능력을 미래의 성공에 필수적이라고 답했다. - AI 도구 숙련도는 채용, 업무 속도, 자신감 향상에 직접적인 도움을 준다. - 그러나 AI가 업무 방식을 바꿀수록 다음과 같은 역량의 중요성이 더 커진다. - 팀이 함께 사용할 수 있는 시스템 구축 - 적절한 사람들과 아이디어를 주고받는 능력 - 공동의 목표를 향해 협력하는 능력 ## 내부 제품 빌더가 되기 - AI 도구를 개인용으로만 사용하지 말고, 팀 전체가 활용할 수 있는 내부 도구로 전환해야 한다. - 예시는 다음과 같다. - 프로토타이핑 에이전트 - 브랜드 플러그인 - 공유 프롬프트 라이브러리 - 누구나 사용할 수 있는 프로토타이핑 도구 - Figma 연구팀은 AI를 활용해 설문 데이터를 탐색할 수 있는 인터랙티브 웹사이트를 만들었다. - 데이터와 맥락이 개인의 컴퓨터나 머릿속에만 머무르지 않게 했다. - AI를 개인 생산성 도구가 아니라 팀의 협업 역량을 확장하는 수단으로 활용했다. - Figma Brand Studio는 Figma Make로 이미지 효과 생성기를 제작했다. - 팀원이 사진이나 디자인에 브랜드에 맞는 질감을 클릭 한 번으로 적용할 수 있었다. - 핵심은 팀의 업무에서 반복되거나 막히는 지점을 발견하고, AI로 마찰을 줄이는 것이다. - 한 사람이 10배 빠르게 일하는 것보다 팀 전체가 함께 10배 빠르게 움직이는 편이 더 큰 효과를 낸다. ## 수많은 선택지에서 결정으로 이끌기 - AI는 짧은 시간에 수십 개의 방향과 결과물을 만들어내므로, 생성 자체보다 선택과 의사결정이 어려워진다. - 효과적인 의사결정을 위해서는 프로젝트 책임자뿐 아니라 다음 사람들을 참여시켜야 한다. - 반대 의견이나 새로운 관점을 가진 사람 - 과거의 맥락과 조직의 경험을 아는 사람 - 잠재적 위험을 발견할 수 있는 전문가 - 한 팀이 AI로 내부 앱을 빠르게 만들었지만, 직원들이 접근해서는 안 되는 회사 프로젝트 정보가 노출되는 문제가 발생했다. - 데이터 거버넌스 전문가를 초기 단계부터 참여시켰다면 예방할 수 있었던 사례다. - 회의 전에 이해하기 쉬운 선택지를 제공해야 한다. - 프로토타입의 각 흐름을 설명하는 Loom 영상 - 방향별 동작을 보여주는 주석이 달린 FigJam 파일 - 회의에서는 단순한 설명보다 트레이드오프를 비교하고 결정을 내리는 데 집중해야 한다. - 발언하지 않은 사람의 의견을 요청한다. - 모호한 추천은 구체적으로 되묻는다. - 논의를 진전시키는 질문을 한다. - 회의가 끝나기 전에 결정사항과 다음 단계를 확인한다. ## 나쁜 아이디어도 공유하기 - AI 활용 속도는 개인과 조직 사이에서 서로 다르게 나타난다. - 20%는 개인 기여자가 조직의 지원 없이 앞서가고 있다고 답했다. - 27%는 리더십이 AI 도입을 밀어붙이지만 팀이 따라가기 어려워한다고 답했다. - 팀원마다 AI를 접한 시점과 숙련도가 달라, 방치하면 역량 격차가 계속 커질 수 있다. - 앞선 사람만 계속 실험하면 다른 구성원은 AI 활용법을 배우기보다 뒤처지는 상황에 놓인다. - 따라서 아직 다듬어지지 않은 아이디어나 실패한 시도도 공유할 수 있는 환경이 필요하다. - 실험 결과를 공개적으로 나누면 개인의 경험이 팀의 학습 자산이 되고, AI 도입 속도 차이를 줄일 수 있다. AI 도구를 배우는 데 그치지 말고, 팀이 함께 사용할 수 있는 도구와 프로세스를 만들고, 다양한 이해관계자를 참여시켜 의사결정을 구조화하는 것이 좋다. 또한 완성된 결과만 공유하기보다 실패와 미숙한 아이디어까지 안전하게 나누는 문화를 구축해야 AI의 효과를 조직 전체로 확장할 수 있다.

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

AI대규모 언어 모델프로토타이핑figma-make+2

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

에이전트형 AI, MCP 및 AI 코딩 어시스턴스를 어떻게 거버넌스할 것인가

에이전틱 AI는 코드 제안만 하는 보조 도구와 달리, 도구 호출·설정 변경·머지 리퀘스트 생성·배포까지 수행할 수 있어 기존의 인간 중심 검토 방식만으로는 충분히 통제하기 어렵다. 따라서 조직은 모델 성능보다 에이전트의 신원, 권한 범위, 데이터 접근, 실행 기록을 관리하는 거버넌스 체계를 먼저 마련해야 한다. 핵심은 모든 작업을 막는 것이 아니라, 자율 실행과 인간 승인이 필요한 경계를 명확히 정하고 사후 감사가 가능하도록 만드는 것이다. ## 에이전틱 AI에 별도 거버넌스가 필요한 이유 - 기존 AI 코드 자동완성은 개발자가 제안을 보고 승인하거나 거부하므로, 모든 코드에 인간 검토가 개입한다. - 에이전틱 AI는 테스트 실행, CI/CD 설정 변경, 파일 작성·삭제, 코드 푸시 등 여러 단계를 연속적으로 수행할 수 있다. - MCP(Model Context Protocol)를 사용하면 에이전트가 외부 도구와 데이터에 연결되므로 접근 권한과 실행 범위가 더욱 중요해진다. - 거버넌스의 핵심 질문은 다음과 같다. - 에이전트가 무엇에 접근할 수 있는가? - 어떤 작업을 수행하도록 승인되었는가? - 실제로 어떤 작업을 했으며, 이를 사후에 증명할 수 있는가? - 조사 결과에서도 AI 코드의 장기 유지보수와 기술 부채 증가가 주요 우려로 나타났다. - 개발자·기술 리더의 73%가 AI 생성 코드의 장기 유지보수를 우려했다. - 86%는 명확한 거버넌스가 없으면 기술 부채가 기존 개발 방식보다 빠르게 누적될 수 있다고 답했다. - DevSecOps 전문가의 92%는 AI 생성 코드와 관련된 거버넌스 문제를 경험했다. ## MCP와 에이전트 권한 통제 에이전트가 외부 도구를 호출할 수 있게 되면 권한 관리가 가장 중요한 통제 지점이 된다. - 에이전트와 작업 흐름의 중앙 카탈로그를 운영한다. - 팀마다 임의로 통합 기능을 만들게 하지 않고, 관리자가 승인된 에이전트와 플로우만 조직에 배포한다. - 기존 역할·그룹 구조와 연계해 프로젝트별 사용 범위를 관리한다. - 복합 신원(composite identity)을 사용한다. - 에이전트의 활동을 에이전트 자체의 작업으로만 기록하지 않고, 작업을 요청한 인간 사용자와 연결한다. - 리소스 접근 시 에이전트와 요청 사용자 모두 인증·인가되어야 한다. - 도구별 승인 정책을 설정한다. - 안전한 도구는 자율 실행을 허용한다. - 파일 작성, 리소스 삭제처럼 민감한 작업은 인간 승인 후 실행되도록 한다. - 위험한 도구는 아예 차단할 수 있어야 한다. - 프롬프트 가드레일을 마련한다. - 웹페이지, 이슈 댓글, 외부 파일 등 신뢰할 수 없는 입력이 에이전트의 행동을 조작하는 프롬프트 인젝션을 탐지한다. - 단순히 실행 결과를 기록하는 것을 넘어, 공격 시도를 실행 전에 차단해야 한다. 이러한 통제는 인간 사용자에게 적용하는 역할 기반·감사 가능·일관된 권한 모델과 동일한 수준으로 에이전트에도 적용되어야 한다. ## 데이터 privacy와 자체 호스팅 소스 코드를 외부 AI 서비스에 제공할 때는 데이터 처리와 소유권을 명확히 확인해야 한다. - 공급자가 고객 코드를 모델 학습에 사용하는지 확인한다. - 입력 데이터와 AI가 생성한 출력의 소유권을 확인한다. - 하위 처리자(subprocessor)의 위치와 목록 변경 통지 정책을 검토한다. - 규제 산업에서는 데이터가 조직 외부 인프라로 나가지 않아야 할 수 있으므로 자체 호스팅이 중요한 통제 수단이 된다. - 자체 호스팅을 사용하면 다음을 함께 달성할 수 있다. - 조직이 통제하는 인프라에서 에이전트 실행 - 팀별 사용량과 활동 추적 - 규제기관의 데이터 보관·처리 요구 충족 - BYOM(Bring Your Own Model)을 활용하면 내부 검증을 마친 모델을 연결하고, 특정 에이전트 플로우에만 지정할 수 있다. - 민감한 작업은 신뢰할 수 있는 자체 모델에 고정한다. - 상대적으로 덜 민감한 작업은 관리형 모델을 사용할 수 있다. ## 인간 검토가 필요한 지점 정의 거버넌스는 에이전트의 자율 실행을 전면 금지하는 것이 아니라, 자율성이 끝나고 인간 검토가 시작되는 지점을 결정하는 것이다. - 대화형 작업 - 개발자가 실시간으로 제안을 확인하고 승인·거부한다. - 일반적인 AI 코드 자동완성에 가까운 방식이다. - 자동화·헤드리스 작업 - CI/CD 파이프라인에서 개발자의 실시간 관찰 없이 에이전트가 실행된다. - 실행 전에 도구 승인 절차를 거치거나, 실행 직후 감사 로그를 통해 사람이 검토해야 한다. ### 검토 지점별 통제 방식 - 코드 리뷰 - 에이전트가 생성한 머지 리퀘스트라도 일반 코드와 동일하게 승인 정책을 적용한다. - 지정된 담당자의 승인이 없으면 병합되지 않도록 한다. - 테스트와 검증 - 필수 테스트, 보안 스캔, 품질 검사를 통과해야 다음 단계로 진행하도록 파이프라인에서 강제한다. - 배포 - 운영 배포처럼 영향이 큰 작업은 명시적인 인간 승인을 요구한다. - 도구 실행 - 도구별로 자율 실행, 승인 대기, 실행 차단 중 하나를 지정한다. - 조직 정책 - 팀별 관행에 맡기지 말고 조직 전체의 AI 사용·승인·감사 정책으로 표준화해야 한다. - 이렇게 해야 사용 방식이 일관되고, 감사 담당자가 AI 활용 과정을 검증할 수 있다. ## 실용적인 적용 방향 조직은 에이전트 도입 전에 승인된 에이전트 목록과 모델 목록을 만들고, 사용자·에이전트의 복합 신원, 프로젝트별 권한, 도구별 승인 정책, 데이터 처리 위치를 정의해야 한다. 이후 머지 승인, 보안 스캔, 배포 승인 같은 기존 개발 통제 지점을 에이전트 작업에도 동일하게 적용하고, 모든 실행을 추적 가능한 감사 로그로 남기는 것이 바람직하다.

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

AI 에이전트CI/CD모델 컨텍스트 프로토콜DevSecOps+4

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

GenRec: 넷플릭스에서 LLM 네이티브 추천을 향하여

Netflix의 GenRec은 사용자 이력과 콘텐츠 메타데이터를 자연어로 표현하고, Netflix에 맞게 후처리 학습한 LLM을 추천 랭커로 활용하는 시스템이다. 기존의 대규모 수작업 피처와 특화 아키텍처 의존도를 줄이면서도, 카탈로그 인식 점수 헤드와 보상 신호를 통해 개인화·장기 사용자 가치·비즈니스 제약을 반영한다. 대규모 A/B 테스트에서 기존 랭커보다 단기 및 장기 지표를 유의미하게 개선했으며, 더 적은 라벨 데이터와 입력 신호만으로도 경쟁력 있는 성능을 보였다. ## 기존 추천 시스템의 복잡성과 LLM의 가능성 - Netflix의 기존 모델은 사용자·아이템·상호작용에 대한 수천 개의 수작업 피처를 사용한다. - 시퀀스 모델링, 피처 상호작용, 멀티태스크 학습 등 다양한 특화 구조가 콘텐츠 유형과 제품 화면별로 구축되어 있다. - 새로운 콘텐츠 유형이나 추천 화면을 추가하려면 피처 설계, 모델 구조, 인프라, 실험을 함께 변경해야 한다. - LLM은 사용자 이력과 아이템 정보를 텍스트로 통합하고, 자연어 기반의 의미 관계와 추천 조건을 표현할 수 있다. - 하지만 일반 LLM은 인기 콘텐츠 편향, 카탈로그에 없는 아이템 생성, 비즈니스 제약 무시, 부족한 개인화 등의 문제가 있다. ## GenRec의 추천 문제 정의 - 사용자 \(u\), 컨텍스트 \(\tau\), 시간 \(t\), 상호작용 이력 \(H\)를 입력으로 받아 Netflix 전체 카탈로그 \(C\)의 순위 \(\pi\)를 생성한다. - 컨텍스트에는 기기, 화면, 지역, 시간 등이 포함된다. - 후보군이 주어지면 Top-K 순위를 만들고, 후보군이 없으면 전체 카탈로그를 대상으로 순위를 계산한다. - 단순 클릭이나 재생 수가 아니라 만족도와 유지율을 대변하는 장기적 회원 효용을 최적화한다. ## 2단계 학습 구조 ### Netflix 맞춤형 기반 LLM - 오픈소스 LLM을 Netflix의 독점 데이터로 적응시킨다. - Netflix 콘텐츠 이해, 회원 행동과 선호 패턴, 일반적인 언어 이해 능력을 학습한다. - 여러 애플리케이션이 공유하는 Netflix 인식 기반 모델로 사용된다. - 콘텐츠 변화에 맞춰 자주 갱신하기보다는 비교적 드물게 업데이트된다. ### GenRec 후처리 학습 - 기반 LLM을 추천 순위화와 제어에 특화된 모델로 전환한다. - 랭킹 데이터와 복수의 보상 신호를 사용한다. - 새로운 콘텐츠와 변화하는 취향을 반영하기 위해 더 자주 갱신한다. - Netflix의 LLM 서빙 비용과 지연시간을 고려해 최적화한다. ## 상호작용 로그를 대화 데이터로 변환 - Netflix의 조회, 재생 시간, 좋아요·싫어요, 찜하기, 중단 등 방대한 이벤트를 추천 대화 형식으로 변환한다. - 사용자 메시지에는 다음 정보가 포함된다. - 현재 화면과 기기 같은 컨텍스트 - 사용자 프로필과 과거 이력 - 아이템 메타데이터 - “다음에 시청하거나 좋아요를 누를 콘텐츠를 추천하라”와 같은 과제 - 어시스턴트 메시지에는 실제 회원 행동이 기록된다. - 어떤 콘텐츠를 재생했는지 - 얼마나 오래 시청했는지 - 어떤 피드백을 남겼는지 - 학습 시에는 언어 모델링과 추천 랭킹을 함께 지원하지만, 추론 시에는 답변 텍스트를 생성하지 않는다. - 실제 서비스에서는 verbalized context를 입력하고, 별도의 카탈로그 인식 점수 헤드로 콘텐츠를 정렬한다. ## 피처 엔지니어링에서 컨텍스트 엔지니어링으로 - 기존 추천 시스템이 밀집 벡터와 수작업 피처를 중심으로 한다면, GenRec은 이력과 상황을 자연어로 변환해 LLM의 의미 공간에 입력한다. - 모델이 아이템 간 관계, 반복 시청, 변화하는 관심사 같은 고차원 패턴을 직접 학습하도록 한다. - 모든 상호작용을 그대로 입력하면 토큰 한도와 비용 문제가 발생하므로, 컨텍스트를 선별하고 압축한다. - 긴 재생이나 긍정 피드백처럼 신호가 강한 이벤트는 자세히 유지 - 짧은 재생이나 빠른 탐색처럼 신호가 약한 이벤트는 제거 - 폭주 시청처럼 반복적인 행동은 요약 - 신작이나 콜드스타트 아이템은 필요한 경우 더 자세히 설명 - 제한된 토큰 예산 안에서 최근성과 신호 강도가 높은 이력을 우선한다. - 프롬프트의 공통 접두사를 늘려 prefix caching을 활용하고, 서빙 비용을 낮춘다. - 결과적으로 모델 개발의 초점이 개별 피처 제작에서 정보 밀도 높은 입력 문맥 설계로 이동한다. ## 랭킹·언어·보상 신호를 결합한 학습 ### 카탈로그 인식 랭킹 목표 - 충분히 긴 재생이나 강한 명시적 피드백처럼 가치가 높은 참여를 긍정 샘플로 사용한다. - 임계값과 노이즈 제거 로직으로 부정확한 행동 신호를 정제한다. - 전체 카탈로그 또는 후보군에 대한 cross-entropy 손실을 사용해 긍정 아이템의 점수를 높인다. - 자유로운 텍스트 생성이 아니라 실제 Netflix 카탈로그 안에서 점수를 계산하므로, 존재하지 않는 콘텐츠를 추천하는 문제를 줄인다. ### 언어 모델링 목표 - 입력과 출력의 텍스트에 대해 언어 모델링 목표를 유지한다. - 자연어로 표현된 사용자 이력과 콘텐츠 메타데이터를 이해하는 능력을 보존한다. - 향후 추천 이유나 설명 생성과 같은 텍스트 기반 기능으로 확장할 가능성도 유지한다. ### 보상 기반 정렬 - 단기 클릭이나 재생만 최적화하지 않고 장기적인 회원 만족도를 반영한다. - 영화, 시리즈, 게임, 라이브, 팟캐스트 등 콘텐츠 유형 간 균형 같은 비즈니스 요구사항을 고려한다. - 여러 보상 신호를 보상 가중 손실에 반영해 랭킹 결과가 Netflix의 장기 목표와 맞도록 조정한다. ## 서빙 효율성과 성능 - GenRec은 Netflix의 LLM 서빙 스택에서 prefill-only 방식으로 실행된다. - 추론 시 토큰을 생성하지 않고 입력을 처리해 아이템별 점수를 계산하므로 생성형 LLM보다 비용 효율적이다. - 기존의 성숙한 프로덕션 랭커와 비교한 대규모 A/B 테스트에서 단기 및 장기 온라인 지표를 모두 통계적으로 개선했다. - Phase 2 학습에 필요한 라벨 데이터와 입력 신호도 기존 시스템의 일부만 사용했다. 실무적으로는 LLM을 추천 시스템에 도입할 때 모든 로그를 무작정 텍스트화하기보다, 카탈로그 제약을 보장하는 점수 헤드, 장기 보상 설계, 토큰 예산 관리, 캐싱 전략을 함께 설계하는 것이 중요하다. GenRec의 사례는 추천 모델의 성능뿐 아니라 피처 유지보수 비용과 새로운 추천 시나리오의 확장성까지 고려할 때 LLM 기반 구조가 유효할 수 있음을 보여준다.

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

대규모 언어 모델자연어 처리recommendation-systemsreinforcement-learning+2

github·2026년 7월 30일·3분 읽기큐레이션 요약

GitHub Copilot 앱에서 세션과 풀 리퀘스트 쌓기

10년 넘은 React 15·Less·구버전 react-bootstrap 기반 프로젝트를 GitHub Copilot 앱으로 현대화한 경험을 소개합니다. 한 번에 전체를 바꾸려 하지 않고, 기존 작업을 세션과 브랜치별로 나누어 순차적으로 진행하는 “스택 세션” 방식이 핵심입니다. AI가 계획 수립, 코드 변경, PR 생성, 브랜치 전환까지 지원하면서 오래된 프로젝트의 대규모 유지보수를 현실적으로 수행할 수 있었다는 결론입니다. ## 오래된 프런트엔드 현대화의 어려움 - 개인용 대시보드 애플리케이션을 2014년경부터 운영해 왔습니다. - React 15, Less, 구버전 `react-bootstrap` 등 의존성이 수년간 업데이트되지 않았습니다. - 애플리케이션 규모가 아주 크지는 않지만, 구조가 충분히 복잡해 수작업으로 정리하려면 수주가 걸릴 상황이었습니다. - 과거에도 현대화를 시도했지만 호환성 문제 때문에 중단한 경험이 있었습니다. ## 첫 시도: 전체 현대화를 한 번에 진행하기 - Copilot의 Plan 모드에서 다음 작업을 요청했습니다. - Tailwind와 vanilla CSS 중 적절한 방식 검토 - Less 제거 - 접근성 및 반응형 개선 - 의존성 현대화 - React 기능의 점진적 정리와 통합 - 링크의 hover/focus 스타일 개선 - 입력 필드의 테두리 반경 축소와 라벨 정리 - 컨테이너 최대 너비와 적절한 줄바꿈 적용 - Claude Opus 4.8과 GPT-5.5의 검토를 거쳐 계획을 다듬은 뒤 실제 변경을 시작했습니다. - 그러나 처음부터 `main` 브랜치를 기준으로 작업한 것이 문제였습니다. AI가 충분히 좋은 계획을 세웠더라도, 현재 운영 중인 코드의 실제 기준 브랜치를 잘못 선택하면 결과가 실행되지 않을 수 있었습니다. ## 기존 `dev` 브랜치와의 충돌 발견 - 과거에 중단한 줄 알았던 현대화 작업이 실제로는 `dev` 브랜치에 일부 남아 있었습니다. - 현재 배포 환경은 `main`이 아니라 부분적으로 업데이트된 `dev` 브랜치를 사용하고 있었습니다. - 따라서 새 작업을 `main`에서 시작하면 기존 기능과 설정이 누락될 수 있었습니다. - 변경 규모가 커서 `dev`의 내용을 `main`으로 병합하기보다, 기존 PR을 닫고 `dev`에서 새 작업을 시작하는 편이 안전했습니다. - Copilot은 사용자의 지시에 따라: - 기존 세션의 PR을 닫고 - `dev`에서 새 브랜치를 만들고 - 기존 스타일·접근성 개선안을 새 기준에 맞게 다시 적용했습니다. ## 테스트 중 발견한 오래된 의존성 문제 - 스타일 변경 후 테스트하는 과정에서 `findDOMNode`, `componentWillReceiveProps` 관련 경고가 나타났습니다. - 문제의 상당 부분은 애플리케이션 코드가 아니라 오래된 `react-bootstrap`에 있었습니다. - Copilot의 Plan 모드에 다음 두 가지 선택지를 검토하게 했습니다. - `react-bootstrap`을 업그레이드해 기존 컴포넌트를 마이그레이션하기 - 라이브러리를 완전히 제거하고 현대적인 대체 구현으로 교체하기 - 분석 결과, 기존 라이브러리를 유지하기보다 전체 교체하는 방향이 권장되었습니다. ## 스택 세션과 분리된 pull request - `react-bootstrap` 교체는 기존 스타일·접근성 작업과 관련이 있지만, 범위가 크게 늘어나는 별도 작업이었습니다. - AI를 활용하면 구현 비용이 낮아 보여 여러 문제를 한 번에 해결하고 싶어지지만, 결과적으로 1만 줄 규모의 거대한 PR이 될 수 있습니다. - 이를 방지하기 위해 작업을 다음처럼 나눴습니다. - 먼저 현재 스타일·접근성 작업을 하나의 PR로 제출 - 해당 작업을 기반으로 새 세션과 브랜치를 생성 - 새 세션에서 `react-bootstrap` 교체를 별도 PR로 진행 - 첫 번째 PR을 `dev`에 병합한 뒤 두 번째 PR을 병합 - 이렇게 각 세션이 이전 세션의 결과 위에 쌓이도록 구성하면 작업 간 의존성은 유지하면서도 변경 범위와 검토 단위를 작게 만들 수 있습니다. ## 실용적인 결론 - AI에게 전체 프로젝트를 한 번에 현대화하게 하기보다, 기준 브랜치와 작업 범위를 먼저 확인하는 것이 중요합니다. - 스타일 개선, 의존성 교체, 기능 리팩터링을 각각 독립적인 세션과 PR로 나누면 테스트와 롤백이 쉬워집니다. - 특히 오래된 저장소에서는 현재 배포 브랜치가 무엇인지 확인한 뒤, 그 브랜치에서 새 세션을 시작하는 방식을 추천합니다.

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

React접근성TypeScriptgithub-copilot+4