techlist.io
KREN

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

cloudflare4분 읽기큐레이션 요약

어떤 웹사이트에든 WebMCP 인터페이스 추가하기

Cloudflare는 코드 변경 없이 사이트에 WebMCP를 활성화할 수 있는 개발자 프리뷰를 출시했다. 이를 통해 브라우저 에이전트는 사람이 페이지를 탐색하듯 추측하지 않고, 사이트가 제공하는 MCP 도구를 직접 발견하고 호출할 수 있다. Cloudflare는 HTML 응답에 브리지 스크립트를 엣지에서 주입하며, 도구 실행은 방문자의 브라우저와 기존 세션을 활용해 수행한다. ## 사람 중심 웹과 AI 에이전트의 간극 - 기존 웹은 사람이 페이지를 읽고 버튼을 클릭하며 양식을 작성한다는 전제로 설계됐다. - AI 에이전트의 방문이 늘고 있지만, 일반적으로는 크롤러가 콘텐츠를 복사해 서버로 가져가는 방식이 사용됐다. - 크롤링은 원 사이트에 트래픽과 출처를 충분히 돌려주지 못하는 문제가 있다. - WebMCP는 스크래핑 대신 사이트가 에이전트용 도구를 직접 노출하도록 해 이 문제를 해결하려 한다. - Chrome 146 실험 버전부터 `document.modelContext`를 통해 WebMCP 표면이 제공된다. ## Cloudflare WebMCP 개발자 프리뷰 - Cloudflare 대시보드에서 설정을 켜는 것만으로 WebMCP 도구를 활성화할 수 있다. - 사이트별로 도구를 직접 설계하고 연결하는 별도 구현 작업이 필요 없다. - 도구는 관련 기능을 묶은 “팩(pack)” 단위로 제공된다. - 새로운 팩이 추가되면 재배포 없이 설정에서 켤 수 있도록 확장성을 고려했다. - 이번 프리뷰에는 브라우저에서 동작하는 두 가지 팩이 포함된다. - Content Credentials 팩 - Site MCP Server 팩 ## 엣지 주입 방식과 브리지 동작 - Cloudflare는 원본 서버 앞단에서 두 가지 작업을 수행한다. - HTMLRewriter를 이용해 모든 HTML 응답에 다음과 같은 브리지 스크립트 참조를 삽입한다. ```html <script type="module" src="/.webmcp/bridge.js" data-packs="c2pa,mcp-server-client" data-mcp-url="/mcp"> </script> ``` - 삽입되는 스크립트와 태그는 동일 출처에서 제공되며, 원본 사이트 코드와 나머지 HTML은 변경하지 않는다. - `data-packs`는 활성화할 도구 팩 목록을 지정한다. - `data-mcp-url`은 사이트의 MCP 서버 주소이며, 기본값은 동일 출처의 `/mcp`다. - 브리지 스크립트는 브라우저에 `document.modelContext`가 없으면 아무 작업도 하지 않고 종료한다. - 브리지는 각 팩의 도구를 통합해 `document.modelContext.registerTool()`로 등록한다. - 정적 팩은 도구를 미리 정의하고, 동적 팩은 시작 시 MCP 서버에서 도구 목록을 조회한 뒤 등록한다. ## 브라우저에서 실행되는 MCP 도구 - 프리뷰의 모든 도구는 Cloudflare 서버로 별도 왕복하지 않고 방문자의 브라우저에서 실행된다. - Content Credentials 팩은 브라우저에서 이미지를 가져와 앞부분의 콘텐츠 출처 메타데이터를 분석한다. - Site MCP Server 팩은 방문자의 브라우저에서 사이트 MCP 엔드포인트로 직접 요청한다. - 요청에는 `credentials: "same-origin"`이 사용되므로 방문자의 기존 로그인 세션과 권한을 활용할 수 있다. - 사이트 MCP 서버가 `tools/list`로 제공한 이름, 설명, 입력 스키마를 그대로 브라우저 도구로 등록한다. - 에이전트는 기존 MCP 서버와 동일한 `Tool`, `CallToolResult` 형식을 사용하므로 별도 전용 인터페이스가 필요 없다. - 도구 호출은 JSON-RPC `tools/call` 요청으로 사이트의 `/mcp` 엔드포인트에 전달된다. ## 향후 확장 가능성 - 브리지 코드는 엣지의 Cloudflare Worker에서 제공된다. - 현재 도구는 브라우저에서만 실행되지만, 향후 Worker를 활용하는 팩도 추가될 수 있다. - 예를 들어 Workers AI를 이용한 사이트맵 요약이나 AI Search 인덱스 조회 같은 기능이 가능하다. - 따라서 WebMCP는 단순한 페이지 조작을 넘어 사이트 기능과 Cloudflare 서비스를 에이전트 도구로 연결하는 기반이 될 수 있다. ## 이미지 콘텐츠 자격 증명 확인 - Content Credentials 팩은 C2PA 메타데이터를 읽어 이미지의 출처와 편집 정보를 에이전트에게 제공한다. - `scan_images_c2pa`는 페이지의 모든 이미지를 검사해 다음과 같은 정보를 요약한다. - 전체 이미지 수와 검사 수 - C2PA 포함 여부 - 이미지 형식 - 매니페스트 개수 - 생성 도구 또는 작성자 - 서명 주체 - `inspect_image_c2pa`는 특정 이미지의 전체 매니페스트를 확인한다. - 편집 이력 - 명시된 작성자 - 서명 인증서 - 이 기능은 이미지 전체가 아니라 파일 앞부분의 소량 메타데이터만 읽는 TypeScript 기반 리더로 구현됐다. - 현재는 자격 증명을 읽고 보고하는 기능이며, 암호학적 서명 검증까지 수행하지 않는다. - 따라서 결과에는 `signatureVerified: false`가 표시되어 에이전트가 검증되지 않은 정보를 신뢰하지 않도록 한다. 사이트에 로그인 상태나 민감한 기능이 있다면 MCP 서버가 에이전트에게 어떤 도구와 권한을 노출하는지 신중하게 설계해야 한다. WebMCP는 크롤링을 대체하는 에이전트 친화적 인터페이스를 제공하지만, 현재는 개발자 프리뷰이므로 브라우저 지원과 표준 변화, 서명 검증 범위를 함께 고려해 시험적으로 도입하는 것이 적절하다.

원문 읽기(새 탭에서 열림)
모델 컨텍스트 프로토콜cloudflareworkers-aiwebmcp+2
discord4분 읽기큐레이션 요약

Discord 패치 노트: 2026년 8월 4일

Discord의 2026년 8월 패치는 설정 화면 개편, Electron 42 업그레이드, 데스크톱·모바일 전반의 성능 및 안정성 개선에 초점을 맞췄습니다. 설정 메뉴의 명칭과 관련 항목을 정리해 탐색성을 높였고, 오버레이·테마·프로필·게임 활동 등에서 발생하던 다양한 UI 버그를 수정했습니다. 모든 수정 사항은 병합됐지만 플랫폼별 적용은 순차적으로 진행될 수 있습니다. ## 설정 화면 개편 - `Activity`가 `Games & Apps`로 변경되었습니다. - `Content & Social`은 `Messaging Permissions`로 이름이 바뀌었습니다. - `Authorized Apps`, 연결 설정, 운영체제별 페이지와 키 바인드 등 관련 항목을 더 명확하게 묶었습니다. - `Data & Privacy`, `Activity Privacy` 등 여러 설정 페이지의 문구와 스타일을 개선했습니다. - 설정 항목의 이름과 배치를 정리해 사용자가 원하는 기능을 찾기 쉽게 했습니다. ## Electron 42 업그레이드 - 데스크톱 클라이언트를 Electron 42 기반으로 업데이트했습니다. - Electron 유지보수 측면의 개선과 함께 Discord의 CPU 사용량이 일부 감소했습니다. - 이번 버전은 대규모 기능 추가보다는 클라이언트의 기반 기술과 실행 효율 개선에 초점을 맞췄습니다. ## 데스크톱 안정성 및 계정 기능 수정 - CAPTCHA 완료 후 이메일 변경이 실패하던 문제를 해결했습니다. - 서버 초과 상태에서 유효한 초대 링크를 사용해도 “유효하지 않거나 만료된 초대”로 표시되던 오류를 수정했습니다. - 서버 선택 드롭다운에서 선택이 적용되지 않거나 목록이 현재 선택 항목으로 되돌아가는 문제를 고쳤습니다. - 긴 서버·역할 목록을 스크롤할 때 목록이 갑자기 맨 위로 이동하는 현상을 해결했습니다. - 전화번호 인증 오류가 표시될 때 입력 필드가 어긋나는 문제를 수정했습니다. - 프로필 편집 화면이 저장할 변경 사항이 없는데도 상점으로 이동한 뒤 계속 열려 있던 문제를 해결했습니다. - 비공개 서버 프로필을 사용하는 사용자에게도 기본 프로필 보기 메뉴가 표시되도록 수정했습니다. ## 오버레이와 게임 활동 개선 - 오버레이가 활성화된 상태에서 일부 게임을 탭 전환하면 화면 전체가 검게 변하던 문제를 해결했습니다. - 서버가 선택된 상태에서 오버레이 채팅 위젯을 드래그해 위치를 변경할 수 없던 문제를 수정했습니다. - 오버레이에서 서버 아이콘을 드래그할 때 이미지가 잘못 잡혀 채팅 위젯이 커서를 따라다니던 현상을 해결했습니다. - 오버레이에서 그룹 DM을 만들면 모달이 게임 오버레이가 아닌 기본 Discord 창에 열리던 문제를 수정했습니다. - 활동 감지를 끈 게임을 실행했을 때 백그라운드에서 실행 중인 다른 게임의 플레이 상태가 지워지던 오류를 해결했습니다. - 게임 데이터를 불러온 직후 사용자 프로필 팝업의 크기가 변하거나 흔들리던 문제를 수정했습니다. ## 테마와 프로필 UI 수정 - 테마 미리보기 종료 후 원래 테마로 돌아가지 않고 미리 본 테마가 기본값으로 저장되던 문제를 해결했습니다. - 사용자 지정 테마 편집기를 연 뒤 테마 전환이 작동하지 않던 문제를 수정했습니다. - 친구 탭의 `Active Now` 패널에 사용자 지정 테마의 그라데이션이 적용되지 않던 문제를 해결했습니다. - 프로필 카드에서 사용자 지정 상태 문구의 하단이 잘리던 현상을 수정했습니다. - 긴 서버 이름, 연결 이름, 사용자 지정 상태가 잘리지 않고 말줄임표로 표시되도록 개선했습니다. - 프로필 효과 미리보기 카드의 불필요한 여백을 제거했습니다. - 배지에 마우스를 올렸을 때 Early Supporter 배지의 눈이 투명해지던 시각적 오류를 수정했습니다. - 프로필 편집 드롭다운과 배지 모달의 클릭 영역, 닫기 버튼, 포인터 커서 표시 문제를 개선했습니다. ## 기타 데스크톱 버그 수정 - 긴 드롭다운과 작은 창 크기에서 모달이 잘못 배치되거나 콘텐츠가 잘리던 문제를 해결했습니다. - 서버 목록을 클릭한 뒤 키를 입력하면 주황색 포커스 링이 나타나던 현상을 수정했습니다. - 친구 추가 입력란에 `#`을 입력할 때 판별자 안내 문구가 텍스트와 겹치던 문제를 해결했습니다. - Linux에서 Stable과 Canary 클라이언트가 작업 표시줄과 창 관리자에서 하나로 묶이던 문제를 수정했습니다. - 활동 사이드바의 확장 영역과 아이콘 클릭·호버 동작을 개선했습니다. - 위시리스트 안내 팝업과 Xbox Game Pass 안내 팝업의 위치가 어긋나던 문제를 수정했습니다. ## 모바일 성능 및 표시 문제 개선 - Android에서 게임 프로필의 공지 목록을 스크롤할 때 프레임이 떨어지던 문제를 개선했습니다. - iPad에서 상태 표시줄 아래로 잘리던 프로필 헤더의 닫기 버튼과 액션 버튼을 수정했습니다. - Android의 You Bar에서 특정 스와이프 동작 후 빈 화면에 멈추던 문제를 해결했습니다. - PIP 모드에서 복귀한 뒤 서버 목록 하단의 일부 아이콘이 표시되지 않던 문제를 수정했습니다. - iOS에서 상태 문구가 있는 사용자의 이름 스타일 효과가 멤버 목록에서 제대로 표시되지 않던 현상을 해결했습니다. - Android에서 여러 줄 텍스트를 닉네임·서버 이름·역할 이름 같은 한 줄 입력란에 붙여넣을 때 입력창이 비정상적으로 커지던 문제를 수정했습니다. - iOS의 `Active Now` 카드에서 긴 게임 제목이 잘리던 문제를 해결했습니다. - Android와 iOS에서 사용자 프로필의 긴 연결 링크가 잘리지 않고 표시되도록 개선했습니다. - Android 라이트 테마의 Server Boosts 화면에서 카드와 배경의 흰색 음영이 서로 달랐던 문제를 수정했습니다. 이번 패치는 새로운 기능보다는 설정 구조 정리와 반복적으로 발생하던 UI·플랫폼별 오류 제거에 의미가 있습니다. Discord 데스크톱 사용자는 업데이트 후 테마, 오버레이, 게임 활동 관련 동작을 확인하고, 문제가 계속되면 플랫폼별 최신 버전 적용 여부를 점검하는 것이 좋습니다.

원문 읽기(새 탭에서 열림)
discordAndroidiOSdesktop-app+3
gitlab3분 읽기큐레이션 요약

GitLab Secrets Manager, ESO·Terraform·API 지원 추가

GitLab Secrets Manager가 External Secrets Operator(ESO), Terraform/OpenTofu, CLI, API를 지원하면서 CI/CD 외의 환경에서도 하나의 비밀 저장소를 사용할 수 있게 되었다. OpenBao 기반의 Vault 호환 인터페이스를 통해 Kubernetes, 인프라 코드, 외부 자동화가 동일한 방식으로 비밀을 조회하며, 인증에는 단기 JWT를 사용한다. 이를 통해 여러 저장소와 인증 모델, 감사 로그를 따로 관리해야 하는 부담을 줄일 수 있다. ### GitLab Secrets Manager의 통합 비밀 관리 - 기존에는 CI/CD, Kubernetes, Terraform마다 별도의 비밀 저장소를 사용하는 경우가 많았다. - GitLab Secrets Manager는 OpenBao를 기반으로 다음 환경에 동일한 저장소를 제공한다. - Kubernetes 워크로드 - Terraform 및 OpenTofu 실행 - OpenBao 또는 Vault CLI - GitLab CI/CD 작업 - 외부 자동화 시스템 및 스크립트 - Vault 호환 KV v2 API를 제공하므로 기존 Vault 생태계 도구와 연동할 수 있다. - 중앙 집중식 저장소를 사용하면 접근 정책과 감사 추적을 일관되게 관리할 수 있다. ### Kubernetes와 External Secrets Operator 연동 - ESO는 Vault provider를 통해 GitLab Secrets Manager에서 비밀을 가져온다. - Kubernetes 워크로드는 단기 JSON Web Token(JWT)을 사용해 OpenBao에 인증한다. - `SecretStore` 리소스에서 다음 항목을 설정한다. - `server`: GitLab Secrets Manager의 Vault 호환 서버 주소 - `path`: KV v2 마운트 경로 - `namespace`: 조직·그룹·프로젝트 계층을 나타내며 접근 가능한 비밀 범위를 제한 - `auth.jwt.path`: JWT 인증 경로 - `auth.jwt.role`: 사용할 인증 역할 - `secretRef`: Kubernetes Secret에 저장된 JWT 참조 - `ExternalSecret`은 원격 비밀과 Kubernetes Secret 사이의 매핑을 정의한다. - `remoteRef.key`: GitLab Secrets Manager의 비밀 경로 - `property`: 원격 비밀 내부에서 가져올 필드 - `secretKey`: Kubernetes Secret에 저장될 키 - `target.name`: 생성할 Kubernetes Secret 이름 - ESO는 대상 Secret을 생성하고 소유하며, 설정된 `refreshInterval`마다 값을 다시 조회한다. - 비밀이 교체되면 애플리케이션을 재배포하지 않아도 Kubernetes Secret에 변경 사항이 반영된다. ### Terraform과 OpenTofu에서 비밀 조회 - Terraform의 `.tfvars` 파일이나 상태 파일에 인증 정보가 기록되면 자격 증명이 유출될 위험이 있다. - GitLab Secrets Manager를 Terraform data source로 조회하면 비밀을 `.tfvars`나 CI/CD 변수에 직접 저장하지 않고 실행 시점에 가져올 수 있다. - 일반적인 흐름은 다음과 같다. - 외부 스크립트로 GitLab 프로젝트의 단기 JWT를 발급 - Terraform Vault provider에 서버 주소, namespace, 인증 경로, role, JWT 전달 - `vault_kv_secret_v2` data source로 원하는 비밀 조회 - 필요한 경우 `sensitive = true`로 출력값을 민감 정보로 표시 - Terraform 실행 시점에 인증이 이루어지므로 장기 자격 증명을 코드나 설정 파일에 남기는 일을 줄일 수 있다. ### OpenBao 및 Vault CLI 사용 - 기존에 Vault용 CLI나 스크립트를 사용 중인 팀은 별도의 클라이언트를 도입하지 않아도 된다. - `VAULT_ADDR`와 `VAULT_NAMESPACE`를 설정한 뒤, 발급받은 JWT를 JWT 인증 엔드포인트에 전달한다. - 인증 결과로 받은 OpenBao 토큰을 `VAULT_TOKEN`에 설정한다. - 이후 `vault kv get` 명령으로 KV v2 경로의 비밀을 조회할 수 있다. - Vault 호환 방식을 사용하므로 기존 운영 자동화와의 통합 비용이 낮다. ### Secrets Manager API를 통한 외부 자동화 - GitLab CI/CD, Kubernetes, Terraform에 포함되지 않는 외부 시스템은 Secrets Manager API를 사용할 수 있다. - 서비스 계정 또는 액세스 토큰으로 프로젝트별 액세스 토큰 발급 API를 호출한다. - API 응답에는 다음과 같은 연결 정보가 포함된다. - Vault 서버 주소 - namespace - KV 마운트 경로 - 비밀 경로 - JWT 인증 경로 - 인증 role - JWT - 외부 시스템은 이 정보를 이용해 단기 인증을 수행하고 필요한 비밀만 조회한다. - 하드코딩된 비밀번호나 별도의 변수 파일을 유지하지 않아도 되는 것이 장점이다. ### 실용적인 적용 권장 사항 - Kubernetes에서는 ESO의 `SecretStore`와 `ExternalSecret`을 사용해 자동 동기화와 비밀 교체를 구성한다. - Terraform에서는 비밀을 `.tfvars`에 넣기보다 실행 시점의 data source 조회 방식으로 전환한다. - 기존 Vault 자동화가 있다면 OpenBao/Vault CLI 호환 기능을 우선 활용한다. - 외부 서비스에는 장기 토큰 대신 프로젝트 범위와 역할이 제한된 단기 JWT를 사용하고, 접근 범위와 감사 로그를 함께 관리하는 것이 좋다.

원문 읽기(새 탭에서 열림)
쿠버네티스Terraformjwtsecrets-management+4
gitlab4분 읽기큐레이션 요약

GitLab 셀프 호스팅을 위한 기밀 AI

GitLab Self-Hosted 환경에서도 소스 코드를 외부에 노출하지 않고 AI 코딩 에이전트를 사용할 수 있다는 것이 글의 핵심 주장입니다. GitLab Duo의 AI Gateway를 Privatemode AI에 연결하면, 프롬프트와 코드가 하드웨어 기반 기밀 컴퓨팅 영역 안에서만 복호화·처리됩니다. 따라서 규제 산업은 자체 GPU·LLM 인프라를 운영하지 않고도 최신 AI 기능과 데이터 보안성을 함께 확보할 수 있습니다. ## 규제 조직이 AI 코딩 도입에 어려움을 겪는 이유 - GitLab Duo Agent Platform은 단순 자동완성을 넘어 다음과 같은 작업을 수행합니다. - 머지 리퀘스트 리뷰 - 여러 파일에 걸친 리팩터링 - 테스트 코드 생성 및 실행 - CI 작업으로 실행되는 에이전트형 워크플로 - 그러나 이러한 기능을 사용하려면 프롬프트, 소스 코드, 실행 컨텍스트가 모델 제공업체로 전송됩니다. - 금융, 의료·제약, 방위산업, 공공기관, 핵심 인프라 기업에서는 소스 코드가 지적 재산이자 규제 대상이므로 외부 AI 서비스 전송 자체가 문제가 될 수 있습니다. ## 데이터 주권과 규제 요구사항 - 소스 코드 처리 위치는 단순한 편의가 아니라 계약, 산업 규정, 데이터 보호법의 적용 대상입니다. - 관련 요구사항에는 다음이 포함됩니다. - NIS2와 DORA의 운영 복원력 및 제3자 위험 관리 - GDPR에 따른 코드와 로그 내 개인정보 처리 - 독일 금융권의 BaFin 감독 - 조달 기준으로 활용되는 BSI C5 - 의료 데이터 관련 규정 - 유럽 조직이 중시하는 데이터 주권 - GitLab Self-Hosted는 원래 코드를 신뢰할 수 있는 조직 내부 경계에 유지하기 위한 방식이므로, AI 기능 도입으로 이 경계를 무너뜨려서는 안 됩니다. ## 기존 AI 운영 방식의 한계 - **공개 AI SaaS** - 소스 코드가 외부 서비스로 이동하므로 규제 조직에서 사용하기 어렵습니다. - **VPC 또는 프라이빗 클라우드** - 네트워크 격리는 강화되지만 클라우드 운영자나 서비스 제공자가 평문 데이터를 처리할 가능성이 남습니다. - 계약상 비공개 약정은 보안에 대한 법적 약속일 뿐, 기술적으로 읽을 수 없게 만드는 보장은 아닙니다. - **자체 모델 및 GPU 운영** - 코드 프라이버시는 확보할 수 있지만 GPU 구매, 인프라 운영, 모델 업데이트, 전문 인력 확보 비용이 큽니다. - 최신 프론티어 모델과 성능 격차가 발생할 수 있습니다. - 결과적으로 많은 규제 조직은 AI를 제한적으로 도입하거나 아예 도입하지 못합니다. ## 하드웨어 기반 기밀 컴퓨팅 - 기밀 컴퓨팅은 데이터가 처리되는 동안에도 메모리 안의 데이터를 암호화합니다. - 하드웨어 기반 TEE(Trusted Execution Environment)가 CPU 또는 GPU 내부에 격리된 실행 영역을 제공합니다. - 사용되는 기술은 다음과 같습니다. - CPU 측: AMD SEV 또는 Intel TDX - GPU 측: NVIDIA Confidential Computing - 전송 및 저장 암호화: AES-256 - 운영체제, 하이퍼바이저, 서버 관리자, 클라우드 제공자도 TEE 내부 데이터를 직접 읽을 수 없습니다. ## 원격 검증과 암호화된 데이터 흐름 - 핵심 보안 장치는 **원격 검증(remote attestation)**입니다. - 클라이언트는 데이터를 보내기 전에 TEE에 다음을 증명하도록 요청합니다. - 어떤 하드웨어에서 실행 중인지 - 어떤 코드와 설정이 실행 중인지 - TEE는 서명된 암호학적 증거를 반환하고, 클라이언트는 이를 사전에 등록된 정상 값과 비교합니다. - 검증이 성공한 뒤에만 암호화 채널을 만들고 요청을 전송합니다. - 데이터는 다음과 같은 흐름으로 처리됩니다. - 클라이언트에서 프롬프트와 코드 암호화 - 암호문 상태로 네트워크 전송 - 원격 TEE 내부에서만 복호화 및 추론 - 서비스 운영자와 클라우드 제공자는 프롬프트·완성 결과·컨텍스트를 확인할 수 없음 - 이는 “보지 않겠다”는 계약이 아니라 하드웨어가 “볼 수 없게” 강제하는 보안 모델입니다. ## Privatemode AI의 역할 - Privatemode AI는 독일의 기밀 컴퓨팅 전문 기업 Edgeless Systems가 개발했습니다. - OpenAI 호환 API를 제공하므로 표준 `/v1` API를 사용하는 도구와 SDK를 그대로 연결할 수 있습니다. - 클라이언트 측 프록시가 다음 작업을 자동으로 처리합니다. - 원격 TEE 검증 - 요청 암호화 - Privatemode 서비스로의 전송 - 글에서 소개한 주요 코딩 모델은 다음과 같습니다. - Kimi K2.6 - 256K 컨텍스트 - 향후 Kimi K3, GLM 등 지원 예정 - Capgemini, 독일 연방고용청, 금융·보험·방위 조직 등에서 규제 환경의 기밀 코딩 용도로 사용되고 있다고 설명합니다. - 암호화는 포스트퀀텀 보안을 지원해, 현재 암호문을 수집한 뒤 미래의 기술로 복호화하려는 “지금 수집하고 나중에 복호화” 공격에도 대응합니다. ## GitLab Duo Self-Hosted 통합 방식 - GitLab Duo Self-Hosted는 GitLab이 관리하는 게이트웨이 대신 조직이 제어하는 AI Gateway를 사용할 수 있습니다. - 구성 흐름은 다음과 같습니다. - 개발자 및 GitLab Duo Agent Platform - 자체 호스팅 GitLab AI Gateway - Privatemode 프록시 - CPU·GPU 기반 원격 TEE - Privatemode 프록시는 OpenAI 호환 `/v1` 엔드포인트로 동작합니다. - 요청이 들어오면 프록시가: - 네트워크를 벗어나기 전에 요청을 암호화하고 - 원격 TEE를 검증한 뒤 - 검증된 환경으로 요청을 전달합니다. - 복호화와 모델 추론은 기밀 컴퓨팅 영역 내부에서만 수행됩니다. - 개발자는 Code Suggestions, Chat, Code Review, 에이전트형 작업 등 기존 GitLab Duo 기능을 동일한 방식으로 사용할 수 있습니다. ## 실용적인 결론 규제 대상 소스 코드를 다루면서 AI 코딩 기능을 도입해야 한다면, GitLab Duo Self-Hosted와 Privatemode AI의 조합은 자체 GPU 클러스터 없이도 검토할 만한 선택지입니다. 다만 실제 도입 전에는 TEE 지원 하드웨어, 원격 검증 절차, 키 관리, 로그 및 메타데이터 처리, 관련 규정에 대한 감사 증적을 별도로 검증해야 합니다.

원문 읽기(새 탭에서 열림)
gitlab-duoai-coding-agentsconfidential-computingtrusted-execution-environment+3
discord4분 읽기큐레이션 요약

Discord Social SDK 버전 1.10에서 모바일 플랫폼 지원 정식 출시

Discord Social SDK 1.10은 iOS와 Android 모바일 지원을 정식 출시해, 게임 개발자가 모바일에서도 Discord의 소셜 기능을 활용할 수 있게 했다. 주요 개선 사항은 Android Rich Presence, 딥링크 기반 계정 연결, 모바일 Discord Social Commerce이며, 이를 통해 플레이어 유지율·참여도·신규 유입을 높이는 것이 목표다. Tencent, Scopely, Ninja Kiwi 등의 사례는 친구 관리, 파티 구성, 커뮤니티 참여를 게임 경험과 자연스럽게 연결할 수 있음을 보여준다. ## 모바일 플랫폼 지원 정식 출시 - Discord Social SDK는 C++, Unreal Engine, Unity 프로젝트에서 사용할 수 있다. - 지원 플랫폼과 최소 버전은 다음과 같다. - Android 7.0 이상 - iOS 15.1 이상 - 모바일 환경에 맞춰 작은 화면과 이동 중 플레이를 고려한 기능 개선이 이루어졌다. - 계정 연결과 소셜 기능을 통해 게임의 도달 범위, 플레이 시간, 참여도를 높이는 것을 목표로 한다. ## Android Rich Presence 개선 - Android 게임에서 실시간 게임 상태를 공유하는 방법이 여러 가지로 확대됐다. - 계정 연결뿐 아니라 RPC(Remote Procedure Call)를 통해서도 Rich Presence를 제공할 수 있다. - 플레이어의 현재 게임 상태를 Discord 친구들에게 노출해 게임 발견과 소셜 공유를 촉진한다. - 향후 Rich Presence 초대 기능과 결합해 친구의 게임 참여를 유도할 수 있다. ## 딥링크 기반 모바일 계정 연결 - 모바일 계정 연결 과정에 딥링크가 추가됐다. - 브라우저 리디렉션이나 수동 로그인 절차를 줄여 앱 안에서 더 빠르게 Discord 계정을 연결할 수 있다. - Tencent의 Delta Force 사례에서는 단일 탭 방식의 계정 연결로 모바일 온보딩과 캠페인 활성화 과정의 마찰을 낮췄다. - 계정 연결은 게임 내 친구 목록, 초대, 커뮤니티 기능을 사용하기 위한 기반으로 활용된다. ## 모바일 Discord Social Commerce - Discord Social Commerce가 모바일로 확장돼, Discord를 통해 게임 아이템을 판매할 수 있게 된다. - 기존 플레이어뿐 아니라 친구와 잠재적인 신규 유저에게도 상품을 노출할 수 있다. - Marvel Rivals 파일럿 결과: - 구매의 41%가 선물 구매였다. - 선물 구매자의 25%는 휴면 유저 또는 신규 유저였다. - Discord의 소셜 관계가 수익화뿐 아니라 플레이어 재활성화와 신규 유입에도 기여할 수 있음을 보여준다. ## Tencent의 Arena Breakout 사례 - 크로스플랫폼에서 분산된 친구 목록과 파티 구성의 불편함을 해결하기 위해 SDK를 도입했다. - 주요 기능: - **Unified Friends List**: 여러 플랫폼의 친구 목록을 하나로 통합 - **Game Invites**: 분대 구성과 게임 초대 절차를 간소화 - 개선된 모바일 Account Linking - 도입 효과: - 분대 구성 시간 단축 - 세션 간 크로스플랫폼 메시지 증가 - 공식 Discord 서버 활동 증가 - 향후 기간 한정 게임 이벤트와 Discord 소셜 기능을 결합할 계획이다. ## Scopely의 Marvel Strike Force 사례 - Discord를 게임 내 커뮤니케이션과 동맹 관리 플랫폼으로 활용했다. - 플레이어 간 소셜 상호작용뿐 아니라 고객 지원과 커뮤니티 운영을 위한 전용 채널도 제공했다. - 도입 이후 나타난 결과: - 신규 플레이어의 계정 연결 증가 - 동맹별 Discord 채널 생성 가속 - 전반적으로 긍정적인 커뮤니티 반응 - 게임 커뮤니티 관리와 플레이어 지원을 Discord 안에서 함께 운영할 수 있다는 점을 보여준다. ## Tencent의 Delta Force 사례 - 공식 Discord 커뮤니티를 단순한 공지 채널이 아니라 플레이어가 함께 만들어가는 커뮤니티 공간으로 발전시켰다. - Account Linking과 Unified Friends List를 먼저 도입해 게임과 커뮤니티 사이의 경계를 줄였다. - 브라우저 이동과 수동 로그인 대신 모바일 단일 탭 계정 연결을 적용했다. - 주요 효과: - 온보딩 과정 개선 - 캠페인 참여 활성화 - 분대 구성 편의성 향상 - 커뮤니티 제작 콘텐츠와 게임 활동의 연결 - 향후 Discord 내 게임 검색 노출과 Rich Presence 초대 기능도 확대할 예정이다. ## Ninja Kiwi의 Bloons TD 6 사례 - Bloons TD 6는 Account Linking과 Unified Friends List를 도입해 Discord 기반 소셜 경험을 구축하기 시작했다. - 제공된 글의 내용은 이 사례의 초기 도입 기능을 소개하는 부분에서 끝나며, 구체적인 성과 수치는 제시되지 않았다. 모바일 게임에 Discord Social SDK를 도입하려면 먼저 계정 연결과 통합 친구 목록으로 진입 장벽을 낮추고, 이후 Rich Presence·게임 초대·커뮤니티 채널을 결합하는 방식이 효과적이다. 특히 모바일에서는 브라우저 전환과 수동 로그인 단계를 최소화하는 것이 온보딩과 유지율 개선에 중요하다.

원문 읽기(새 탭에서 열림)
AndroidiOSc++account-linking+4
cloudflare4분 읽기큐레이션 요약

Cloudflare, 2026년 SASE 및 SSE 보고서에서 비저너리로 선정된 유일한 벤더

Cloudflare는 2026년 Gartner SASE 및 SSE 매직 쿼드런트에서 모두 비저너리로 선정된 유일한 기업이라고 발표하며, 이를 통합형 아키텍처와 고객 신뢰의 결과로 설명한다. 글은 AI 에이전트, 양자 컴퓨팅, 섀도 앱 확산에 대응하려면 기존 제품을 조합한 SASE가 아니라 민첩하고 프로그래밍 가능한 통합 보안·접속 플랫폼이 필요하다고 주장한다. Cloudflare One은 단일 글로벌 네트워크와 통합 정책 체계를 기반으로 AI 보안, 제로 트러스트, DLP, 포스트퀀텀 암호화를 하나의 플랫폼에서 제공하는 방향을 제시한다. ## SASE와 SSE 시장의 변화 - SSE는 팬데믹 시기 원격 근무 보안을 위한 “SASE의 보안 영역”으로 먼저 확산됐다. - 최근에는 사무실 복귀, AI 에이전트, 섀도 앱, 포스트퀀텀 위협으로 인해 네트워크 연결과 보안을 함께 관리하는 SASE의 중요성이 커지고 있다. - 기업은 과거 아키텍처에 묶인 제품보다 변화 속도에 맞춰 정책과 보호 기능을 확장할 수 있는 플랫폼을 필요로 한다. ## 기존 SASE의 구조적 한계 - **분산된 아키텍처** - 인수합병으로 여러 제품을 결합한 플랫폼은 배포와 정책 관리가 복잡하다. - 사용 사례마다 서로 다른 제품과 엔진을 운영해야 해 보안 공백과 구현 지연이 발생한다. - Cloudflare는 하나의 글로벌 네트워크로 사용자, AI 에이전트, 인프라를 연결하고 보호하는 “connectivity cloud” 접근을 내세운다. - **관리되지 않는 AI 에이전트** - 기존 보안 제품은 사람의 생성형 AI 프롬프트에 집중했지만, AI 에이전트와 MCP 서버의 확산은 충분히 통제하지 못했다. - Cloudflare는 사람과 AI 에이전트를 함께 가시화하고 MCP 서버 사용을 정책으로 관리한다고 설명한다. - AI Gateway와 연동해 사용자·팀·애플리케이션별 추론 비용을 제한할 수 있어 예기치 않은 AI 사용료를 줄일 수 있다. - **이론에 머문 포스트퀀텀 보안** - 포스트퀀텀 암호화를 향후 과제로만 다루는 대신, 주요 온·오프램프에 실제 적용해 “지금 수집하고 나중에 복호화”하는 공격에 대응한다고 주장한다. - 규제 산업은 장기간 보관되는 암호화 데이터를 현재 시점부터 보호해야 한다. - **복잡한 추가 과금** - 기존 업체는 고급 기능을 별도 애드온으로 판매하거나 원격 근무와 사무실 사용에 중복 과금하는 경우가 있다. - Cloudflare는 숨은 비용 없이 예측 가능한 통합 번들을 제공하는 것을 차별점으로 제시한다. ## SASE를 변화시키는 네 가지 기술 압력 - **AI로 만든 내부 앱과 섀도 IT** - 직원이 IT 승인 없이 내부 도구를 빠르게 만드는 “vibe-coded” 앱이 늘어나고 있다. - SASE는 이런 앱에 제로 트러스트 접근 제어, WAF, API 보호, DLP를 자동 적용해야 한다. - AI 프롬프트와 민감 데이터도 보호하면서 개발 속도는 유지해야 한다. - **AI 에이전트 권한 통제** - 사람의 광범위한 권한을 AI 에이전트가 그대로 상속해서는 안 된다. - 에이전트 작업별로 최소 권한의 자격 증명을 발급하고, 의도와 도구 호출량을 분석해 이상 행동을 감지해야 한다. - **포스트퀀텀 민첩성** - 양자 컴퓨팅 발전에 대비해 NIST 표준이 확정되기 전부터 암호화 체계를 교체할 수 있어야 한다. - Cloudflare는 2028년까지 포스트퀀텀 인증을 포함한 완전한 양자 보안 SASE를 제공하겠다는 목표를 제시한다. - **실질적인 아키텍처 통합** - 단순히 여러 제품을 “플랫폼”으로 묶는 것만으로는 통합이 이뤄지지 않는다. - 진정한 통합에는 단일 코드베이스와 통합된 제어·데이터·인프라 플레인이 필요하다. - AI 시대에는 구성 가능성과 프로그래밍 가능성이 실제 아키텍처에 내장되어야 한다. ## Cloudflare의 통합 아키텍처 - Cloudflare는 서로 다른 보안 제품을 조합하는 대신 처음부터 단일 플랫폼으로 구축했다고 설명한다. - 모든 서비스가 글로벌 네트워크의 각 서버에서 실행되므로 특정 보안 장비 간 트래픽을 우회시키는 ‘tromboning’이 줄어든다. - 제품별 용량 계획, 분리된 정책, 복잡한 통합 작업이 필요 없어 새로운 사용 사례를 수개월이 아니라 수일 또는 수주 내 배포할 수 있다는 주장이다. - 제로 트러스트, Gateway, DLP, 신규 사무실 연결 등을 동일한 운영 체계에서 확장할 수 있다. ## AI 도입을 빠르게 보호하는 방식 - AI 보안을 별도 모듈로 추가하지 않고 기존 SASE 정책 언어에 통합한다. - 관리자는 사람의 AI 프롬프트와 에이전트의 MCP 서버 연결을 동일한 정책 체계로 관리할 수 있다. - 새로운 AI 비서나 AI 기반 업무 도구가 도입돼도 보안을 사후에 덧붙이는 대신 기존 제로 트러스트 정책을 즉시 적용할 수 있다. - 단일 아키텍처를 활용해 새로운 AI 보안 기능을 별도 제품 통합 주기 없이 빠르게 배포할 수 있다는 점을 강조한다. ## 사용하기 쉬운 SASE - 기존 SASE는 여러 검사 지점을 거치는 복잡한 트래픽 경로와 제품별 관리 방식 때문에 배포 기간이 길어지는 문제가 있었다. - Cloudflare는 서비스가 동일한 네트워크에서 일관되게 동작하도록 설계해 전문 장비 간 연결과 별도 용량 계획을 줄인다. - 새로운 애플리케이션에 제로 트러스트를 적용하거나 Gateway 트래픽에 DLP를 추가하는 작업을 설정 중심으로 처리할 수 있다고 설명한다. ## 프로그래밍 가능한 SASE - 글은 단순한 GUI 자동화나 제한적인 API를 “프로그래밍 가능성”이라고 부르는 기존 방식을 비판한다. - Cloudflare는 엣지 개발자 플랫폼과 SASE를 결합해 사용자 코드를 SASE 패브릭 안에서 직접 실행할 수 있는 구조를 지향한다. - 이를 통해 실시간 신호를 활용한 접근 결정 등 기업별 맞춤 로직을 기본 제품의 제약을 우회하지 않고 구현할 수 있다고 주장한다. 실무적으로는 SASE 제품을 평가할 때 기능 목록뿐 아니라 단일 정책 체계, AI 에이전트 권한 관리, 포스트퀀텀 전환 능력, 통합 비용 구조, 커스텀 로직 실행 가능성을 함께 확인하는 것이 중요하다.

원문 읽기(새 탭에서 열림)
제로 트러스트ai-securitysasecloudflare-one+3
meta5분 읽기큐레이션 요약

사용자 시퀀스에서 스케일링 법칙까지: Meta 광고 순위를 위한 다단계 아키텍처

Meta는 사용자 행동의 순서와 시간 정보를 활용하는 시퀀스 학습을 광고 추천 시스템에 확장하기 위해 두 가지 구조적 혁신을 제시한다. 첫째, 오프라인 사용자 모델과 온라인 랭킹 모델을 분리해 긴 사용자 이력을 효율적으로 처리하고, 둘째, dense tokenization과 target-aware attention으로 광고와 사용자 행동 간 상호작용을 모델이 직접 학습하도록 했다. 이 플랫폼은 Instagram 전환율 6%, Facebook 전환율 3%, Facebook 광고 클릭률 3.5%의 누적 향상에 기여했으며, Meta의 GEM(Generative Ads Recommendation Model)의 핵심 요소로 활용되고 있다. ## 기존 시퀀스 모델의 한계 - 광고 추천 시스템은 밀리초 단위로 수천 개의 광고를 검색·순위화해야 하며, 초당 수백만 개의 후보를 처리해야 한다. - 기존 방식은 보통 다음과 같은 하이브리드 구조를 사용했다. - 한 모델은 사용자 행동 시퀀스를 처리한다. - 다른 모델은 희소 피처 간 상호작용을 처리한다. - 이 구조는 운영 효율성은 높지만 다음과 같은 문제가 있다. - 두 모델 사이의 지식 전달이 손실될 수 있다. - 희소 피처를 조합하기 위한 수작업 피처 엔지니어링이 계속 필요하다. - 시퀀스 모델과 랭킹 모델의 규모를 동시에 키울 때 서로 간섭해 확장성이 제한된다. - 시퀀스 길이와 Transformer 규모를 키울수록 모델 복잡도와 실시간 추론 비용 사이의 균형을 맞추기 어려워진다. ## 오프라인 사용자 모델과 온라인 랭킹 모델의 분리 - 다단계 시퀀스 모델은 무거운 사용자 모델링과 실시간 광고 순위화를 두 단계로 분리한다. - 오프라인 사용자 모델 - 사용자의 긴 행동 이력을 비동기적으로 처리한다. - 수천 개 수준의 시퀀스 길이와 여러 Transformer 레이어를 사용할 수 있다. - 사용자 행동에서 장기적인 관심사와 패턴을 추출해 사용자 임베딩을 생성한다. - 계산 결과는 사용자 단위로 미리 계산하고 캐시한다. - 광고 후보나 특정 문맥 정보와 분리해, 특정 광고에 종속되지 않는 사용자 표현을 만든다. - 온라인 랭킹 모델 - 캐시된 사용자 임베딩에 최신 사용자 신호와 광고 후보 정보를 결합한다. - 실시간 요청에서 최종 광고 순위를 계산한다. - 엄격한 지연 시간 예산을 만족하도록 가볍고 빠르게 설계된다. - 이 분리를 통해 오프라인 모델의 용량과 복잡도는 크게 늘리면서도 온라인 서빙 비용과 지연 시간의 급증을 피할 수 있다. ## Dense Tokenization으로 희소 피처 통합 - 기존 추천 시스템은 희소 ID 피처 간 상호작용을 표현하기 위해 사람이 직접 조합 피처를 설계하는 경우가 많았다. - Dense tokenization은 희소 피처와 순차적 행동 데이터를 하나의 조밀한 토큰 어휘로 통합한다. - 통합된 토큰 표현을 사용하면 attention 메커니즘이 데이터에서 직접 피처 간 관계를 발견할 수 있다. - 결과적으로 다음과 같은 장점이 있다. - 수작업으로 정의한 교차 피처에 대한 의존도가 낮아진다. - 사용자 행동, 광고 속성, 문맥 정보 사이의 복잡한 관계를 통합적으로 학습할 수 있다. - 시퀀스 모델이 전통적인 희소 피처 모델의 역할까지 흡수할 수 있다. ## Target-Aware Multi-Head Attention - 사용자 행동 시퀀스와 광고 후보 정보를 함께 토큰화한 뒤, 광고별로 사용자 과거 행동의 중요도를 다르게 계산한다. - 각 attention 레이어는 현재 평가 중인 광고를 기준으로 사용자의 과거 행동을 참조한다. - 여러 개의 정렬된 attention 블록을 쌓아 다음을 수행한다. - 광고와 과거 행동 사이의 1차 상호작용을 학습한다. - 이후 레이어에서 더 높은 차원의 상호작용을 포착한다. - 긴 사용자 시퀀스를 광고별로 중요한 정보만 포함한 압축 표현으로 점진적으로 변환한다. - 이 방식은 모든 광고에 동일한 사용자 표현을 사용하는 대신, 각 광고 후보에 맞는 사용자 관심사 표현을 생성한다. ## 예측 가능한 LLM 스타일 확장 법칙 - 실제 광고 트래픽에서 모델 성능은 계산량(FLOPs)이 증가할수록 로그-선형적으로 향상되는 경향을 보였다. - 이는 대규모 언어 모델에서 관찰된 scaling law와 유사하다. - 성능은 다음 요소를 확장할 때 측정됐다. - Transformer 깊이 - 모델 폭 - 사용자 시퀀스 길이 - 콘텐츠·의미 정보의 풍부함 - 기존 Transformer 기반 시퀀스 모델보다 계산량 증가에 따른 확장 효율도 개선됐다. - 광고 추천은 텍스트처럼 조밀한 데이터만 처리하지 않고 희소 ID 피처와 시간 순서 정보를 함께 다루지만, 그럼에도 예측 가능한 확장 법칙이 나타났다는 점이 아키텍처의 적합성을 뒷받침한다. ## 성능 확장을 위한 네 가지 조절 요소 ### 균형 잡힌 모델 구조 - 깊이, 폭, 시퀀스 길이를 균형 있게 확장해야 한다. - 한 축만 키우면 다른 축이 병목이 되어 성능 향상이 둔화될 수 있다. - 이는 모델 확장에서 각 구성 요소 간의 시너지가 필요하다는 “scaling synergy principle”로 설명된다. ### 다단계 모델의 독립적 조정 - 오프라인 사용자 모델과 온라인 랭킹 모델을 서로 독립적으로 확장할 수 있다. - 온라인 모델 확장은 단위 계산량당 더 큰 성능 향상을 가져올 수 있지만, 요청 처리 시간과 서빙 지연 시간에 제한된다. - 오프라인 모델은 비동기 추론이 가능하므로 지연 시간 제약 없이 모델 규모를 점진적으로 키울 수 있다. ### 시퀀스 구성의 다양성 - 더 긴 사용자 행동 시퀀스를 사용할수록 성능이 향상된다. - 단순히 유사한 유형의 행동을 많이 넣는 것보다 다양한 행동 유형을 균형 있게 포함하는 것이 더 효과적이다. - 즉, 시퀀스의 길이뿐 아니라 행동 데이터의 다양성이 사용자 의도와 관심사를 표현하는 데 중요하다. ### 모델·데이터 확장의 결합 - 광고 추천에서는 모델 크기만 키우는 것으로 충분하지 않다. - 희소 피처, 의미 정보, 사용자 행동의 시간적 범위와 다양성을 함께 확장해야 한다. - 다단계 구조는 각 확장 요소가 온라인 비용과 오프라인 비용에 미치는 영향을 분리해 조정할 수 있게 한다. ## 실용적인 결론 대규모 추천 시스템에서는 모든 계산을 실시간으로 수행하기보다, 긴 사용자 이력은 오프라인에서 깊게 모델링하고 실시간 단계에서는 캐시된 표현과 최신 광고 신호를 결합하는 구조가 효과적이다. 또한 수작업 피처 조합을 계속 늘리기보다 dense tokenization과 target-aware attention을 통해 모델이 광고별 사용자 행동 상호작용을 직접 학습하도록 설계하는 것이 확장성과 성능 향상에 유리하다.

원문 읽기(새 탭에서 열림)
transformerrecommendation-systemsscaling-lawsattention-mechanisms+3
aws4분 읽기큐레이션 요약

Amazon DynamoDB, 이제 모든 규모에서 실시간 벡터 검색 지원 | Amazon Web Services

Amazon DynamoDB에 벡터 검색 기능이 정식 출시되어, 운영 데이터와 벡터 임베딩을 한 테이블에 저장하고 별도 벡터 데이터베이스 없이 유사도 검색을 수행할 수 있게 되었습니다. 서버 관리나 데이터 동기화 파이프라인 없이도 단일 자릿수 밀리초 지연 시간과 99% 이상의 재현율을 목표로 하며, 수조 개 벡터까지 확장할 수 있습니다. 기존에 DynamoDB를 사용하는 애플리케이션이라면 의미 기반 검색, RAG, 추천 시스템 등을 더 단순한 구조로 구현할 수 있습니다. ## DynamoDB 네이티브 벡터 검색의 특징 - 벡터 임베딩을 DynamoDB의 운영 데이터와 함께 저장합니다. - 별도 벡터 데이터베이스로 데이터를 복제하거나 동기화할 필요가 없습니다. - 서버 프로비저닝, 패치, 소프트웨어 설치, 유지보수가 필요 없는 서버리스 방식입니다. - 벡터 인덱스는 저장 용량 제한 없이 수평 확장됩니다. - 기존 DynamoDB와 동일한 서버리스 인프라 및 요청 단위 과금 모델을 사용합니다. - 에이전트 메모리, 검색 증강 생성(RAG), 추천 엔진, 개인화, 이상 탐지 등에 활용할 수 있습니다. ## 벡터 저장 및 검색 방식 - 사용자가 선택한 임베딩 모델로 텍스트를 벡터로 변환합니다. - Amazon Bedrock Titan Text Embeddings - Cohere Embed - OpenAI 임베딩 모델 등 - 임베딩은 DynamoDB의 기존 `List` 데이터 타입에 여러 `Number` 값으로 저장합니다. - 별도 벡터 전용 데이터 타입이나 테이블 스키마 변경이 필요하지 않습니다. - `PutItem` 또는 기존 항목을 수정하는 `UpdateItem`으로 벡터를 저장합니다. - 벡터 인덱스를 생성한 뒤 `SearchVectors` API로 검색합니다. - 검색 요청에는 다음 정보를 포함할 수 있습니다. - 검색용 쿼리 벡터 - 반환할 결과 수(최대 100개) - 파티션 키 값 - 선택적 필터 조건 - 결과는 유사도에 따라 정렬되어 반환되며, 벡터와 함께 상품명·가격 등 운영 데이터도 조회할 수 있습니다. ## 지원되는 인덱스 및 거리 함수 - 최대 4096차원 벡터를 지원합니다. - 다음 거리 함수를 제공합니다. - **Cosine**: 벡터의 크기보다 방향을 비교하며, 텍스트 의미 유사도에 적합합니다. - **Euclidean**: 벡터 간 실제 거리를 비교하며, 크기 자체가 중요한 데이터에 사용할 수 있습니다. - **Dot product**: 방향과 크기를 모두 반영하며, 관심도와 빈도를 함께 고려하는 추천 시스템 등에 적합합니다. - 일반적으로 임베딩 모델을 학습하거나 사용하는 방식에 맞는 거리 함수를 선택하는 것이 좋습니다. - Cosine과 Euclidean은 점수가 낮을수록 유사하고, Dot product는 점수가 높을수록 유사합니다. ## 파티션 키와 인라인 필터 - 벡터 인덱스에 파티션 키를 지정하면 벡터를 분산 저장하고 검색 범위를 제한할 수 있습니다. - 예를 들어 `marketplace`를 파티션 키로 설정하면 미국 시장 상품만 검색할 수 있습니다. - 대규모 데이터셋이나 높은 검색 처리량이 필요한 경우 파티션 키 사용이 권장됩니다. - 검색 시 일반 속성을 이용한 인라인 필터를 적용할 수 있습니다. - 예: `category = footwear` - 필터는 정확히 일치하는 값만 지원합니다. - `BETWEEN`, `BEGINS_WITH` 같은 범위 조건은 지원하지 않습니다. - 검색 결과에 반환할 속성은 전체 속성을 포함하거나 필요한 속성만 프로젝션할 수 있습니다. ## 상품 카탈로그 적용 예시 - 기존 `ProductCatalog` 테이블에 다음과 같은 운영 데이터가 있다고 가정합니다. - `productId` - `category` - `description` - `marketplace` - `name` - `price` - 상품 설명을 임베딩으로 변환한 뒤 `descriptionEmbedding` 속성으로 저장합니다. - `descriptionEmbedding`을 대상으로 `ProductDescriptionIndex` 벡터 인덱스를 생성합니다. - 인덱스 설정 예시는 다음과 같습니다. - 벡터 속성: `descriptionEmbedding` - 거리 함수: `Cosine` - 파티션 키: `marketplace` - 필터 속성: `category` - “lightweight running shoes for summer” 같은 자연어 검색어를 동일한 임베딩 모델로 변환합니다. - `US` 시장과 `footwear` 카테고리로 범위를 제한하고 Top K를 5로 설정하면, 의미적으로 가장 가까운 상품 5개를 유사도 순으로 반환합니다. ## 기존 구조와 비교한 장점 - 기존에는 DynamoDB 데이터를 전용 벡터 저장소로 복제해야 했습니다. - 이 방식은 다음과 같은 부담을 만들었습니다. - 데이터 동기화 파이프라인 운영 - 데이터 이동 비용 - 별도 데이터베이스 라이선스 및 운영 비용 - 두 시스템 간 일관성 관리 - 대규모 환경에서 예측 가능한 지연 시간 유지 - DynamoDB 네이티브 벡터 검색은 운영 데이터와 벡터를 한곳에서 관리해 이러한 복잡성을 줄입니다. 기존 운영 데이터가 DynamoDB에 있다면, 별도 벡터 데이터베이스를 추가하기 전에 네이티브 벡터 검색을 우선 검토할 만합니다. 특히 자연어 상품 검색이나 RAG처럼 벡터 검색 결과와 가격·재고·카테고리 같은 운영 속성을 함께 사용해야 하는 경우 구조 단순화와 운영 비용 절감에 유리합니다.

원문 읽기(새 탭에서 열림)
RAG서버리스vector-dbamazon-dynamodb+2
cloudflare5분 읽기큐레이션 요약

에이전트 액세스 모델

기업 보안은 네트워크 위치 대신 사용자 신원과 기기 상태를 기준으로 판단하는 Zero Trust로 발전했지만, 에이전트에는 기존 인간 중심 통제가 충분하지 않다. 에이전트는 짧은 작업 단위로 실행되면서도 사람보다 훨씬 빠르게 권한을 행사하고, 여러 시스템과 다른 에이전트를 연쇄 호출할 수 있기 때문이다. 글은 작업 실행 그래프 전체를 신뢰하지 않고 매 행동을 검증하는 **Agent Access Model(AAM)**을 제안하며, 핵심은 판단을 더 정교하게 만드는 것보다 에이전트의 능력 범위를 처음부터 작게 제한하는 데 있다. ## 인간 중심 보안 모델의 한계 - BeyondCorp는 요청이 내부 네트워크에서 왔는지보다 사용자 신원과 기기 상태를 기준으로 접근을 허용해야 한다고 주장했다. - 이 모델은 사람이 주체라는 전제에서 잘 작동했다. - 사람은 비교적 일정한 기기를 사용한다. - 작업 속도가 느리고 접근 요청 빈도가 제한적이다. - 로그인, 기기 상태, 세션 위험도 등을 바탕으로 개별 접근을 판단할 수 있다. - 에이전트는 하나의 서비스가 여러 작업을 처리하며, 데이터베이스·소스 저장소·로그·티켓 시스템·문서 등에 짧은 시간 안에 접근할 수 있다. - 따라서 인간에게 분기별로 검토하던 최소 권한 정책을 에이전트에게는 실시간으로 적용하고 감사 로그로 남겨야 한다. ## 에이전트의 네 가지 특성 - **자격 증명보다 작업 수명이 짧다** - 서비스 계정용 키는 장기간 유지되고 권한 범위가 넓은 경우가 많다. - 에이전트 작업은 몇 분 만에 끝날 수 있지만 토큰이 메모리, 로그, 환경 변수에 남아 재사용될 수 있다. - 자격 증명 수명은 작업 수명과 일치해야 하며, 작업 종료 시 함께 만료되어야 한다. - **사람보다 훨씬 빠르게 행동한다** - 인간 활동을 기준으로 설계한 이상 탐지, 속도 제한, 데이터 유출 방지 기능은 대응 전에 이미 대량의 데이터가 전송될 수 있다. - 데이터베이스 연결과 외부 네트워크가 동시에 있으면 읽은 정보를 즉시 외부 엔드포인트로 전송할 수 있다. - 그러므로 통제는 사후 탐지가 아니라 도구 호출과 네트워크 요청이 발생하는 지점에서 동기적으로 실행되어야 한다. - **프롬프트는 보안 경계가 아니다** - “운영 환경에 접근하지 말라” 같은 지시는 행동 의도를 표현할 뿐 접근을 강제하지 않는다. - 입력 데이터에 삽입된 지시로 에이전트가 조작될 수 있고, 에이전트가 스스로 안전하지 않은 행동을 선택할 수도 있다. - 실제 강제는 도구 호출을 중재하는 하네스와 패킷을 통제하는 네트워크 계층에서 수행해야 한다. - **여러 홉을 거치며 권한을 조합한다** - 한 에이전트가 도구를 호출하고, 그 도구가 다시 다른 에이전트나 API를 호출할 수 있다. - 이 과정에서 원래 요청한 사람, 작업 목적, 허용된 권한의 관계가 사라질 수 있다. - 기존 권한 모델은 단일 위임에는 대응해도 다단계·다중 사용자 위임에는 취약하다. ## 작업 실행 그래프를 기준으로 한 AAM - AAM의 출발점은 “실행 중인 작업 자체를 신뢰하지 말라”는 원칙이다. - 에이전트의 각 행동은 다음 세 가지를 기준으로 매번 인가된다. - 에이전트의 신원 - 해당 에이전트가 수행하도록 승인된 작업 - 작업 실행 그래프가 지금까지 접근한 정책상 중요한 리소스 - 한 행동이 승인되었다고 해서 다음 행동까지 자동으로 승인되지 않는다. - 그래프에 누적된 상태는 이후 사용할 수 있는 권한을 줄일 수만 있으며, 작업 중 권한을 임의로 확대하지 않는다. - Beyond Zero처럼 개별 행동 단위로 판단하는 방식과 결합할 수 있으며, AAM은 판단 엔진이 검토해야 할 권한 범위를 제한한다. ## AAM의 다섯 가지 원칙 - **짧고 작업에 결합된 자격 증명** - 작업 전용 자격 증명을 발급하고 작업 종료 시 만료시킨다. - 탈취된 토큰만으로 재사용할 수 없도록 하네스가 보유한 증명 키에 토큰을 결합한다. - **하네스와 네트워크에서의 강제** - 프롬프트는 의도를 설명하는 수단일 뿐이다. - 도구 호출은 하네스에서, 네트워크 요청은 네트워크 계층에서 정책으로 차단·허용한다. - **예외적인 인간 승인** - 모든 단계마다 사람의 승인을 요구하면 승인 피로와 형식적인 클릭이 발생한다. - 정말 중요한 의사결정에만 인간 승인을 사용해야 한다. - **증거 기반 권한 검토** - 실제 작업 활동을 분석해 작업 템플릿의 권한이 과도한지 부족한지 판단한다. - 검토 후 승인된 변경은 이후 작업에만 적용하며, 현재 실행 중인 작업의 권한을 소급해 확대하지 않는다. - **되돌릴 수 없는 신뢰 감소** - 보호 대상 이벤트가 발생하면 Trust Ratchet이 작업 실행 그래프 전체의 권한을 정책에 따라 제거한다. - 제거된 권한은 현재 작업에서 복구되지 않고, 새롭게 승인된 작업에서만 다시 부여된다. ## 참조 아키텍처와 에이전트 신원 브로커 - AAM 참조 아키텍처는 작업을 직접 통제하는 네 가지 활성 제어와, 증적을 처리하는 두 개의 지원 시스템으로 구성된다. - 지원 시스템에는 다음이 포함된다. - **Agent Activity Log**: 작업 중 발생한 활동을 기록한다. - **Grant Review Loop**: 기록된 증거를 바탕으로 향후 권한 정책을 검토한다. - **Agent Identity Broker**는 작업이 배포될 때 작업 범위가 제한된 검증 가능한 자격 증명을 발급한다. - 자격 증명은 작업 종료 시점보다 늦게 만료되지 않아야 한다. - 자격 증명에는 최소한 다음 관계가 표현된다. - 어떤 에이전트인지 - 누구를 대신하는지 - 어떤 작업을 수행하는지 - 또한 발신자 제약(sender constraint)을 적용해, 자격 증명만 탈취한 공격자가 하네스의 증명 키 없이 재사용하지 못하도록 한다. ## 실용적인 적용 방향 - 에이전트마다 장기 서비스 계정과 광범위한 정적 키를 제공하지 말고, 작업별 단기 자격 증명을 발급하는 것이 우선이다. - 프롬프트의 금지 문구에 의존하지 말고 하네스와 네트워크 계층에서 도구·데이터·외부 전송을 직접 제한해야 한다. - 모든 행동에 인간 승인을 넣기보다 고위험 작업에만 승인 절차를 적용해야 한다. - 활동 로그를 통해 권한 범위를 지속적으로 줄이되, 실행 중인 작업의 권한을 사후에 넓히지 않는 원칙을 유지해야 한다.

원문 읽기(새 탭에서 열림)
제로 트러스트access-controlaudit-loggingleast-privilege+2
cloudflare4분 읽기큐레이션 요약

Cloudflare OS로 Cloudflare의 업무 방식을 재구상하는 방법

Cloudflare는 AI 에이전트가 업무 방식을 크게 바꿀 만큼 발전했지만, 생산 시스템과 내부·고객 데이터에 대한 통제가 함께 필요하다고 판단했다. 이를 위해 사내 AI 플랫폼인 **Cloudflare OS**를 구축하고, 인간의 책임·최소 권한·조직 맥락 활용을 핵심 원칙으로 삼았다. 엔지니어에게는 코드 품질과 보안을 위한 가드레일을 제공하고, 비엔지니어에게는 개발 도구가 아닌 업무 중심의 직관적인 인터페이스를 제공하려 했다. ## AI 확산과 거버넌스의 필요성 - 영업팀 직원이 AI로 여러 시스템의 API 키와 배포 파이프라인 관리자 권한을 요구하는 “SuperApp”을 만든 것이 문제의 출발점이었다. - 초기에는 정보 검색용 챗봇과 코드 작성 보조 정도로 AI를 제한했지만, 더 강력한 모델과 에이전트 도구가 등장하면서 상황이 급변했다. - 기술·비기술 직군 모두가 AI를 활용해 업무를 자동화하려 했고, 회사는 생산성을 지원하면서도 다음 자산을 보호해야 했다. - 내부 시스템 - 조직 데이터 - 고객 데이터 - 배포 및 운영 환경 - Cloudflare는 Workers, Access 등 기존 개발자·Zero Trust 제품을 조합하고 맞춤형 서비스를 추가해 Cloudflare OS를 구축했다. ## AI 도입을 위한 다섯 가지 원칙 ### 고객 문제 해결이 출발점 - AI를 사용하는 것 자체를 목표로 삼지 않는다. - 먼저 “해야 할 일(jobs to be done)”과 업무의 병목, 고객 대응의 개선 지점을 정의한다. - 그 다음 문제에 적합한 AI 도구를 선택한다. ### 모든 직원에게 도구를 제공 - 초기 AI 에이전트는 터미널, 코드 에디터, Git 저장소 등 개발자 중심의 인터페이스에 집중됐다. - 하지만 모든 직원이 개발 도구를 사용할 필요는 없다. - 직원은 자신의 도메인 전문성을 제공하고, 회사는 누구나 사용할 수 있는 직관적인 플랫폼을 제공해야 한다. ### AI 결과물은 인간이 책임진다 - AI를 팀원으로 간주하지 않고 도구와 도구 제작자로 본다. - AI 결과물의 품질 기준, 테스트 방법, 업무 흐름을 정의하고 검증하는 책임은 사람에게 있다. - 에이전트를 만든 사람이 회사를 떠나면 관리자가 해당 에이전트의 책임을 이어받는다. ### 모델보다 조직 맥락이 중요하다 - Cloudflare용 에이전트는 일반적인 지식뿐 아니라 Cloudflare의 정책, 업무 방식, 시스템 구조를 이해해야 한다. - 따라서 모델 성능 향상과 함께 신뢰할 수 있고 정제된 조직 지식 계층을 구축해야 한다. ### AI 사용 시 권한을 확대하지 않는다 - AI를 통해 시스템 원장에 접근할 때 사용자가 기존보다 더 많은 권한을 가져서는 안 된다. - 에이전트는 업무에 필요한 최소 권한만 가져야 한다. - 에이전트를 다른 사람과 공유할 때도 제작자의 권한이 아니라 사용하는 사람의 권한을 적용해야 한다. - 기존의 역할·기기·지역별 접근 제어와 서드파티 애플리케이션의 보안 설정도 AI 에이전트에 동일하게 적용해야 한다. ## 엔지니어를 위한 가드레일: Engineering Codex - AI가 코드를 매우 빠르게 작성하면서 기존 코드 리뷰 프로세스가 따라가지 못했고, 잘못된 코드도 더 빠르게 생성되는 문제가 생겼다. - Cloudflare는 엔지니어링 원칙과 모범 사례를 담은 권위 있는 가이드인 **Cloudflare Engineering Codex**를 만들었다. - Codex는 단순히 금지 목록을 제시하는 정책이 아니라, 각 영역에서 “어떻게 해야 좋은가”를 제시하는 의견이 반영된 기준이다. - 코드베이스의 각 영역에는 품질 기준에 책임을 지는 도메인 오너가 있다. - Codex는 소프트웨어 개발 생명주기 전반에 적용된다. - 작업 계획 검토 - 기술 설계 검토 - Merge Request 검토 - 장애 보고서 검토 - 최근 4개월 동안 관련 에이전트는 약 25만 건의 잠재적 문제를 발견했고, 1만 6천 건의 병합을 차단했다. - 구현이 시작되기 전 약 600건의 설계에서 아키텍처 문제를 찾아냈다. - 다음 단계는 에이전트가 생성한 결과물을 평가하는 평가 루프를 엔지니어들이 직접 정의할 수 있도록 지원하는 것이다. ## 비엔지니어를 위한 접근 방식의 전환 - 초기에는 엔지니어용 도구에 더 친절한 사용자 인터페이스만 입힌 방식으로 비엔지니어를 지원하려 했다. - 그러나 코드 저장소를 복제하고 `AGENTS.md` 같은 컨텍스트 파일을 추가하는 개발자 중심 방식은 비정형 지식 업무와 잘 맞지 않았다. - 비엔지니어의 업무는 다음과 같은 특징이 있다. - 일회성 결과물을 자주 만든다. - 여러 시스템 원장의 데이터를 함께 사용한다. - 명확한 코드 저장소나 반복 가능한 개발 프로젝트가 없는 경우가 많다. - 개발용 에이전트 환경을 그대로 제공하면 실제 문제보다 더 많은 “바이브 코딩” 앱이 만들어지는 문제가 발생했다. - Cloudflare는 이 접근이 잘못되었음을 인정하고, 사용자가 직접 도구를 조립하게 하기보다 원하지 않는 업무를 “매직 AI 이메일 봇”에 보내도록 하는 업무 중심 인터페이스로 방향을 전환했다. Cloudflare의 경험은 AI 도입에서 모델 선택보다 **권한 설계, 조직 지식의 구조화, 인간의 책임, 사용자별 인터페이스**가 더 중요할 수 있음을 보여준다. 특히 에이전트는 기존 사용자의 권한을 넘지 않도록 설계하고, 직군별 업무 방식에 맞는 도구를 제공하는 것이 안전하고 지속 가능한 도입의 핵심이다.

원문 읽기(새 탭에서 열림)
AI 에이전트Cloudflare Workers코드 리뷰제로 트러스트+2
cloudflare4분 읽기큐레이션 요약

Cloudflare OS: 에이전트, 앱 및 업무를 위한 개방형 플랫폼

Cloudflare OS는 회사의 지식·절차·용어·시스템을 에이전트가 활용하도록 만들어, 엔지니어뿐 아니라 모든 직원이 업무를 자동화하고 앱과 문서를 만들 수 있게 하는 플랫폼이다. 초기 버전의 한계였던 정적 앱, 반복적인 에이전트 실행, 데이터 권한 관리 문제를 해결하기 위해 보안과 거버넌스를 플랫폼의 핵심으로 재설계했다. 새 버전은 오픈 소스로 제공되며, 조직이 내부 시스템과 업무 방식을 연결해 직접 구축하고 확장할 수 있다. ## 조직의 맥락을 에이전트에게 전달하기 - 조직은 미션과 함께 고유한 용어, 절차, 시스템, 표준, 업무 방식을 구성원에게 전달한다. - 업무 결과는 코드뿐 아니라 문서, 발표 자료, 인간관계, 물리적 성과 등 다양한 형태로 나타난다. - 코드는 실행 여부라는 명확한 피드백이 있지만, 비정형 업무에는 조직의 맥락과 시스템 접근 권한이 필요하다. - Cloudflare OS는 회사가 축적한 지식과 반복 업무의 모범 사례를 에이전트가 따를 수 있는 컨텍스트와 스킬로 저장한다. - 한 사람이 더 나은 업무 방식을 만들면 조직 전체가 이를 재사용할 수 있다. ## 초기 버전에서 얻은 한계와 교훈 - 초기 Cloudflare OS는 개인별 비공개 워크스페이스 중심이었다. - 앱은 내부 시스템과 실시간으로 연결된 소프트웨어가 아니라 정적인 결과물에 가까웠다. - 결정적인 반복 작업도 스킬을 다시 실행해야 했고, 그만큼 추가 모델 토큰을 소비했다. - MCP 서버가 제공하는 도구 목록만으로는 에이전트가 실제로 어떤 데이터와 리소스를 관찰했는지 알 수 없었다. - 워크스페이스와 앱을 공유하면서, 사용자가 권한 없는 정보를 간접적으로 볼 가능성이 커졌다. - 이에 따라 보안을 앱 제작자나 개별 사용자에게 맡기지 않고 플랫폼 수준에서 처리하도록 새 기반을 설계했다. ## Cloudflare OS의 세 가지 구성 요소 - **조직 컨텍스트 기반 에이전트 워크스페이스** - 회사가 선별한 지식과 스킬을 바탕으로 대화하고 작업한다. - 에이전트가 코드를 작성·실행할 수 있는 격리된 런타임을 제공한다. - **보안·거버넌스 프레임워크** - 내부 데이터와 서비스에 대한 접근을 정책에 따라 통제한다. - 에이전트와 앱이 접근할 수 있는 리소스와 데이터의 이동 경로를 관리한다. - **수정 가능한 개인·협업 앱 플랫폼** - 대화에서 시작한 작업을 문서, 앱, 지속 실행 워크플로로 발전시킬 수 있다. - 사용자가 만든 앱을 공유하고 계속 수정할 수 있다. ## 브라우저 기반 에이전트 워크스페이스 - 개발자나 터미널 사용법을 몰라도 브라우저에서 사용할 수 있도록 설계됐다. - 워크스페이스는 다음 요소를 결합한다. - 에이전트 세션 - 지속 상태 - 파일과 산출물 - 외부 리소스 접근 - 코드를 작성하고 실행하는 격리 런타임 - 팀이나 회사가 수집한 컨텍스트와 스킬이 기본으로 포함되어 동일한 업무 절차를 매번 다시 설명할 필요가 없다. ### 조사와 질의 - 회사 컨텍스트와 허용된 리소스를 기반으로 주제를 조사할 수 있다. - 전체 데이터를 모델 컨텍스트에 넣는 대신, 에이전트가 코드를 작성해 검색·필터링·조인·분석을 수행한다. ### 문서·슬라이드·스프레드시트 생성 - 조사 결과를 문서, 프레젠테이션, 스프레드시트로 변환할 수 있다. - 결과물은 단순한 정적 파일이 아니라 원본 데이터와 연결된 상태로 유지될 수 있다. - 데이터가 변경되면 결과물을 갱신할 수 있으며, Google Drive 같은 기존 서비스나 익숙한 형식으로 내보낼 수도 있다. ### 협업 앱 구축 - 문서나 스프레드시트로 부족한 경우, 에이전트가 자체 인터페이스·로직·상태를 가진 앱을 만든다. - 앱은 회사 리소스와 연결될 수 있고 여러 사람이 함께 사용할 수 있다. ### 결정적 워크플로 실행 - 반복적인 업무의 예측 가능한 단계는 코드로 처리하고, 판단이 필요한 부분에만 모델을 사용한다. - 워크플로는 수동 실행, 예약 실행, 연결된 시스템의 이벤트 발생 시 실행이 가능하다. - 기존 MCP 서버는 MCP Server Portals를 통해 계속 사용할 수 있다. ## API 키 대신 세분화된 권한 모델 - 회사 시스템에 연결하기 위해 API 키를 에이전트나 사용자에게 직접 제공하는 방식은 위험하다. - API 키는 대개 권한 범위가 넓고 수명이 길며, 공유와 감사가 어렵다. - MCP 서버는 자격 증명을 내부에 보관하고 제한된 도구만 노출하므로 개선된 접근 방식이다. - 그러나 MCP만으로는 에이전트가 어떤 원본 리소스를 관찰했는지, 이후 데이터가 어디로 이동할 수 있는지까지 통제하기 어렵다. - 따라서 권한 부여는 단순히 “어떤 도구를 호출할 수 있는가”를 넘어 데이터의 후속 사용과 노출 가능성까지 고려해야 한다. ## 무권한 시작과 Gatekeeper 기반 접근 - Cloudflare Access가 Cloudflare OS에 들어올 수 있는 사용자를 통제한다. - OS 내부에서는 모든 에이전트와 앱이 처음에 아무 권한도 갖지 않는다. - 에이전트가 특정 리소스에 대한 접근을 요청하면 관리자가 승인하거나 거부한다. - 승인된 리소스는 생성 코드에 타입이 지정된 바인딩으로 전달된다. ```ts const issues = await env.PROJECT.listIssues({ teamId: "ENG", state: "open", }); ``` - `env.PROJECT`는 특정 리소스와 정책에 대한 권한을 나타내는 capability다. - 실제 인증 정보는 에이전트와 생성된 코드에서 완전히 격리된다. - 이러한 Gatekeeper를 통해 에이전트와 앱이 시스템 오브 레코드에 접근할 때 조직의 정책에 따른 통제가 가능해진다. ## 실용적인 결론 Cloudflare OS의 핵심은 단순히 AI 챗봇을 제공하는 것이 아니라, 조직의 지식과 시스템 접근 권한을 안전하게 결합해 업무 자체를 자동화하는 데 있다. 조직에 도입하려면 먼저 반복 업무를 컨텍스트·스킬·결정적 워크플로로 정리하고, API 키 직접 공유 대신 리소스별 최소 권한과 감사 가능한 접근 정책을 설계하는 것이 중요하다.

원문 읽기(새 탭에서 열림)
AI 에이전트모델 컨텍스트 프로토콜cloudflare자동화+3
cloudflare4분 읽기큐레이션 요약

신원 인식형 분석으로 통제 불능 AI 행동 포착하기

AI 사용량의 이상 징후를 파악하려면 요청마다 검증된 사용자·에이전트 신원과 각 계정의 정상적인 사용 기준선이 필요하다. Cloudflare는 AI Gateway와 Cloudflare Access를 결합해 요청별 신원을 확인하고, User Insights로 계정별 사용 패턴에서 벗어난 행동을 탐지한다고 밝혔다. 이를 통해 비용 관리뿐 아니라 과도한 사용이나 악성·오작동 에이전트 탐지까지 가능하게 한다. ## AI Gateway를 통한 중앙 관리 - AI Gateway는 OpenAI, Anthropic, Google, Workers AI 등 여러 모델로 향하는 요청을 하나의 제어 지점으로 통합한다. - 애플리케이션뿐 아니라 Claude Code, Codex, GitHub Copilot 같은 개발자용 에이전트도 동일한 관찰·보안·거버넌스 정책을 적용할 수 있다. - 모든 AI 트래픽을 한곳에서 분석하므로 비용, 모델 사용량, 접근 제어를 통합 관리할 수 있다. ## Cloudflare Access 기반의 신원 확인 - AI Gateway 앞에 사용자 정의 도메인을 두고 Cloudflare Access로 보호할 수 있다. - Okta, Entra 등 SAML을 지원하는 ID 공급자를 이용해 인증하며, 별도의 Cloudflare API 키를 배포할 필요가 없다. - 인증된 요청에는 사용자의 Access ID가 `cf.user_id` 메타데이터로 포함된다. - 관리자는 실제 요청자를 기준으로 로그, 분석 데이터, 비용을 필터링할 수 있다. - 공유 API 키 때문에 누가 얼마나 사용했는지 알기 어려웠던 문제를 해결한다. ## 사용자별 비용 한도와 정책 - `cf.user_id`를 기반으로 사용자마다 독립적인 예산 한도를 설정할 수 있다. - 한도에 도달하면 요청을 차단하거나 더 저렴한 모델로 자동 전환할 수 있다. - 향후 ID 공급자의 그룹 정보와 연동해 팀별로 모델 접근 권한과 지출 한도를 설정할 예정이다. - 머신러닝 팀에는 최고급 모델 허용 - 지원팀에는 지출 상한 적용 - 특정 프로젝트 구성원에게 공동 예산 할당 ## User Insights의 역할 - User Insights는 AI Gateway를 통과하는 기존 트래픽을 별도 설정 없이 분석한다. - 사람과 에이전트 각각의 평소 행동 패턴을 학습하고, 그 패턴에서 벗어난 계정을 보여준다. - 비용뿐 아니라 캐시 적중률이 낮거나 컨텍스트 윈도우가 과도하게 큰 등 비용 낭비 요인도 추적한다. - 단순히 “많이 사용했는가”가 아니라 “그 계정의 평소 사용 방식과 다른가”를 판단하는 데 초점을 둔다. ## 사람과 에이전트별 행동 기준선 - 계정은 사용자든 에이전트든 시간에 따라 고유한 행동 패턴을 만든다. - 일정한 간격으로 티켓을 요약하는 에이전트와, 프롬프트·세션 길이가 불규칙한 사람은 정상 패턴이 다르다. - 따라서 모든 계정에 동일한 절대 비용 기준을 적용하면 오탐이 많아진다. - 평소 비용이 큰 사용자의 500달러 지출은 정상일 수 있다. - 평소 5달러를 쓰는 에이전트의 50달러 세션은 10배 증가한 이상 징후일 수 있다. ## 세션 비용 기반 이상 탐지 - User Insights는 개별 요청이 아니라 세션 단위로 비용을 평가한다. - 최근 30일 동안 해당 계정의 세션 비용 p95를 개인 기준선으로 사용한다. - 세션 비용이 개인 p95의 2배를 초과하면 이상 행동 후보로 분류한다. - 단, 상대적 급증만으로는 부족하므로 조직 전체 세션 비용의 p99도 함께 사용한다. - 최종적으로 다음 조건을 모두 만족하는 세션만 경고 대상이 된다. - 해당 계정의 최근 기준선보다 2배 이상 비쌈 - 조직 전체 세션 중 가장 비싼 1% 수준에 해당함 - 절대 비용 하한선도 적용해, 소액 사용자의 몇 센트짜리 급증이 불필요한 경고를 발생시키지 않도록 한다. ## 동적으로 갱신되는 기준선 - 기준선은 고정값이 아니라 계정의 최근 사용 습관에 따라 계속 변한다. - 계정의 rolling p95와 2배 임계값이 이동하므로 현재 행동에 맞는 경고가 가능하다. - 정상적인 고사용자 활동은 제외하고, 평소 패턴을 깨면서도 실제 조사 가치가 있는 고비용 세션만 추린다. - 결과적으로 관리자는 정상 트래픽을 모두 살펴보는 대신, 의심스러운 계정 중심의 “rogue behavior feed”를 확인할 수 있다. ## 보안과 비용 관리의 결합 - 이상 사용은 새로운 도구나 명백히 차단된 행동으로 나타나지 않을 수 있다. - 이미 권한을 가진 계정이나 서비스 계정이 허용된 작업을 평소보다 훨씬 많이 수행하는 방식으로 나타날 수 있다. - 따라서 사용자 신원 확인과 행동 기준선 분석을 함께 적용해야 비용 폭증과 보안 위험을 동시에 발견할 수 있다. 실무적으로는 모든 AI 요청을 AI Gateway로 통합하고, Cloudflare Access로 개인·에이전트 신원을 연결한 뒤, 사용자별 예산과 User Insights의 상대적 기준선을 함께 활용하는 방식이 권장된다.

원문 읽기(새 탭에서 열림)
ai-securityanomaly-detectionai-gatewaycloudflare-access+4
cloudflare4분 읽기큐레이션 요약

WriteGuard: MCP 서버를 위한 세밀한 제어

AI 에이전트가 외부 시스템에 쓰기 권한을 가지면, 잘못된 프롬프트 하나만으로 사람의 작업 속도를 훨씬 뛰어넘는 대규모 변경을 일으킬 수 있다. Cloudflare는 에이전트별 설정이나 사용자의 감시에 의존하지 않고, MCP 도구 호출을 중앙에서 정책 적용·식별·감사하기 위해 WriteGuard를 구축했다. WriteGuard는 인간 사용자의 권한은 유지하면서 에이전트 세션을 별도로 추적하고, 위험도에 따라 작업을 허용·기록·차단한다. ## MCP의 구조와 에이전트 동작 방식 - MCP(Model Context Protocol)는 AI 애플리케이션이 외부 도구와 데이터에 연결되도록 하는 표준이다. - MCP 서버는 다음 요소를 가진 도구를 제공한다. - 도구 이름 - 설명 - 입력 스키마 - 실제 작업을 수행하는 핸들러 - 에이전트가 도구를 선택하면 MCP 클라이언트가 서버에 호출을 보내고, 서버가 Jira·GitLab·데이터베이스 등 downstream 시스템과 상호작용한다. - 따라서 도구에 쓰기 권한이 부여되면 에이전트가 외부 시스템의 상태를 직접 변경할 수 있다. ## 무제한 쓰기 권한의 위험 - 잘못 작성된 정리 작업 프롬프트가 수천 개의 티켓을 자동으로 닫을 수 있다. - 사람이 직접 수행한 작업과 에이전트가 수행한 작업이 동일한 사용자 계정으로 기록되면 원인 분석과 복구가 어려워진다. - 여러 에이전트 세션이 동시에 실행되면 네트워크 로그만으로 특정 세션을 식별하기 어렵다. - 위험한 사례는 다음과 같다. - 계약 소프트웨어의 계약 내용 변경 - 고객지원 큐에 대량 답변 전송 - 데이터베이스 테이블 전체 삭제 - Cloudflare는 모든 사용자가 에이전트를 완벽하게 설정하거나 모든 도구 호출을 감시할 수 없다고 판단했다. ## Cloudflare의 MCP 확장 - Cloudflare의 내부 에이전트는 OpenCode, Cloudflare OS, 장기 실행 에이전트 서비스 등을 통해 MCP를 사용한다. - 내부 MCP 포털이 여러 서버를 통합하며, 연결된 서버 수는 13개에서 27개로 증가했다. - 초기에는 Jira, GitLab, 위키, 운영 시스템 등을 조회하는 읽기 전용 서버로 시작했다. - 이후 엔지니어링·제품·디자인·영업·고객 성공팀에서 실제 변경 작업을 수행하는 도구를 요구했다. - 클라이언트의 skill이나 elicitation prompt만으로는 통제가 어렵기 때문에 중앙 정책 계층인 WriteGuard를 도입했다. ## WriteGuard의 역할 - WriteGuard는 MCP 서버와 도구 호출 사이에 위치하는 공통 계층이다. - 도구 설정과 요청 컨텍스트를 바탕으로 호출을 다음과 같이 처리한다. - 호출을 그대로 통과 - 에이전트 식별 정보를 추가한 뒤 통과 - 감사 이벤트를 생성 - 핸들러 실행 전에 호출 차단 - WriteGuard는 다음 기능을 하나의 장소에서 제공한다. - 도구별 정책 관리 - 사용자 및 에이전트 신원 연결 - downstream 시스템에 에이전트 정보 표시 - 중앙 감사 로그 수집 ## 도구 위험도 기반 정책 각 도구에는 위험도, 활성화 여부, 라벨링 설정을 지정한다. - **Read Only** - 이슈 검색 - Merge Request 조회 - 파이프라인 상태 확인 - **Minimal Impact** - 리액션 추가 - 알림을 읽음으로 표시 - 이슈 구독 - **Contained Write** - 댓글 작성 - Merge Request 생성 - 이슈 필드 수정 - **Critical** - Merge Request 병합 - 운영 환경 배포 실행 - 레코드 일괄 삭제 위험도는 감사 로그 기록 여부와 호출 허용 여부를 결정하며, 위험도별로 로그를 검색할 수 있다. 또한 서버 코드를 수정하지 않고도 특정 입력 필드에 일반 텍스트나 HTML 형식의 에이전트 라벨을 삽입할 수 있다. ## 사람의 권한을 유지하고 에이전트만 식별 - 내부 MCP 서버는 Cloudflare Access와 OAuth로 사용자를 인증한다. - 에이전트는 별도 계정이 아니라 사용자의 권한을 그대로 사용한다. - 따라서 Joe가 특정 이슈를 닫을 수 없다면 Joe의 에이전트도 닫을 수 없다. - 별도 에이전트 계정을 만들지 않은 이유는 다음과 같다. - 관리해야 할 권한 체계가 추가됨 - 에이전트와 책임자인 사람의 연결이 약해짐 - 대신 WriteGuard는 사용자 신원에 MCP 클라이언트와 세션 정보를 추가한다. - downstream 애플리케이션에는 사람의 권한으로 수행된 작업이라는 정보와 함께, 어떤 에이전트 세션이 작업했는지 표시할 수 있다. ## 중앙 감사 로그와 대규모 활동 분석 - WriteGuard는 각 도구 호출을 성공, 실패, 차단으로 분류한다. - 이후 감사 이벤트를 비동기적으로 내부 audit Worker에 전송한다. - 감사 이벤트에는 다음 정보가 포함된다. - MCP 서버 - 도구 이름 - 위험도 - 호출 결과 - 사용자 - 클라이언트 - 실행 시간 - 비밀번호나 민감한 값으로 분류된 입력 키의 값은 제거한다. - 비동기 로깅을 사용하므로 에이전트가 응답을 기다리는 시간에는 추가 지연이 없다. - MCP 포털 로그가 개별 호출을 보여준다면, WriteGuard 로그는 도구의 의미적 분류·에이전트 컨텍스트·백엔드 처리 결과를 함께 제공한다. - 이를 통해 특정 시스템 하나가 아니라 전체 MCP 환경에서 에이전트의 대량 활동을 검색하고 조사할 수 있다. ## GitLab 적용 방식 - 글에서는 GitLab MCP 서버의 세 도구를 예로 든다. - `get_merge_request`: Merge Request 읽기 - `create_mr_note`: 댓글 또는 노트 작성 - `merge_mr`: Merge Request 병합 - 이 도구들은 각각 읽기, 제한적 쓰기, 중요 쓰기 등 서로 다른 위험도 정책을 적용할 수 있다. - 이를 통해 동일한 GitLab 서버 안에서도 조회는 허용하되 댓글 작성이나 병합은 별도로 기록하거나 차단하는 식의 세밀한 통제가 가능하다. ## 실용적인 결론 MCP 서버에 쓰기 권한을 추가할 때는 단순한 사용자 인증만으로는 부족하다. 도구별 위험도 정책, 에이전트 세션 식별, 민감정보 제거 감사 로그, 사전 차단 기능을 중앙 계층에서 제공해야 하며, 특히 대량 변경이 가능한 작업은 높은 위험도로 분류해 별도 통제하는 것이 안전하다.

원문 읽기(새 탭에서 열림)
AI 에이전트gitlab모델 컨텍스트 프로토콜TypeScript+4
figma3분 읽기큐레이션 요약

더 나은 코드, 더 적은 토큰: MCP에서 Code Connect의 이점 | Figma 블로그

코딩 에이전트가 디자인을 코드로 변환할 때 Code Connect를 사용하면 실제 프로덕션 컴포넌트와 디자인 시스템을 더 정확히 활용할 수 있다. Figma MCP와 Code Connect를 함께 사용한 실험에서 작업 시간은 19.6%, 토큰 사용량은 29.5% 감소했고, 코드 품질은 1~4점 척도에서 1점 향상됐다. 즉, 시각적으로 비슷한 코드를 새로 만드는 대신 기존 컴포넌트를 직접 연결하면 더 빠르고 일관된 결과를 얻을 수 있다. ## 코딩 에이전트가 디자인 시스템을 잘못 구현하는 이유 - Figma MCP의 `get_design_context`는 캔버스의 디자인을 React 코드 형태로 설명한다. - Code Connect가 없으면 에이전트는 다음과 같은 문제를 겪을 수 있다. - 기존 컴포넌트 대신 새로운 컴포넌트를 직접 생성한다. - 디자인 시스템에서 잘못된 컴포넌트를 선택한다. - 올바른 컴포넌트를 찾더라도 검색과 수정에 불필요한 토큰과 시간을 사용한다. - 결과물은 시각적으로는 맞아 보여도 프로젝트의 실제 코드 구조나 디자인 시스템 규칙과 어긋날 수 있다. ## Code Connect가 MCP 응답을 보강하는 방식 - Code Connect는 Figma 컴포넌트와 코드베이스의 실제 컴포넌트를 연결한다. - 설정이 완료되면 MCP 응답에 일반적인 React 표현 대신 프로덕션 코드에 가까운 코드 스니펫이 포함된다. - 에이전트는 다음 정보를 직접 전달받는다. - 사용해야 할 컴포넌트의 import 경로 - 컴포넌트에 전달할 정확한 속성값 - 디자인 요소와 코드 컴포넌트 간의 대응 관계 - 예를 들어 Code Connect가 없으면 탭 UI를 여러 `<button>` 요소와 CSS 클래스로 재구성할 수 있다. - Code Connect를 사용하면 다음처럼 기존 디자인 시스템 컴포넌트를 바로 사용한다. ```tsx <SegmentedControl value="design" options={["Design", "Code"]} /> ``` ## Coinbase 사례 - Coinbase Design Systems 팀은 일관된 UI를 위해 핵심 컴포넌트, 디자인 토큰, 인프라를 관리한다. - 에이전트 기반 개발을 도입하면서 Code Connect를 적용해 에이전트가 CDS 컴포넌트를 재사용하도록 했다. - Code Connect가 없을 때는 에이전트가 스테퍼를 프로그레스 바 조합으로 임의 구현하는 등 컴포넌트를 잘못 추측할 수 있었다. - Code Connect를 사용하면 정확한 코드 표현과 실제 CDS 컴포넌트의 import 문을 확인할 수 있어 코드 품질이 향상되고 토큰도 절약됐다. ## Code Connect의 효과를 측정한 실험 - 동일한 디자인, 프롬프트, 모델을 사용해 Code Connect 적용 여부만 달리한 디자인-투-코드 작업을 비교했다. - 총 27개 테스트 케이스에서 다음 항목을 측정했다. - 코드 품질 - 토큰 사용량 - 작업 소요 시간 - React 기반 디자인 시스템 두 가지를 대상으로 했다. - Figma의 예제 디자인 시스템인 Simple Design System(SDS) - 더 규모가 크고 복잡한 내부 시스템인 Figma Pattern Library(FPL) - Code Connect 적용 결과: - 작업 시간 중앙값 19.6% 감소 - 토큰 사용량 중앙값 29.5% 감소 - 코드 품질 1~4점 Likert 척도에서 1점 향상 ## 실용적인 적용 방향 - 디자인 시스템의 핵심 컴포넌트에 Code Connect 템플릿을 우선 설정하는 것이 효과적이다. - 에이전트가 직접 HTML과 스타일을 조합하게 하기보다 실제 컴포넌트와 import 정보를 제공해야 한다. - 디자인 시스템을 사용하는 팀이라면 Code Connect를 단순한 인간 개발자용 문서화 도구가 아니라 에이전트의 코드 생성 품질과 비용을 개선하는 컨텍스트 계층으로 활용할 수 있다.

원문 읽기(새 탭에서 열림)
디자인 시스템ReactTypeScriptcode-connect+2
github4분 읽기큐레이션 요약

GitHub 법무팀이 Copilot CLI를 활용해 업무 흐름을 간소화한 방법

GitHub 법무팀은 엔지니어가 아니어도 Copilot CLI를 활용해 반복적인 법무 업무를 자동화하고, 자신의 판단 기준을 반영한 도구를 직접 만들 수 있음을 보여준다. 계약서 작성·검토와 DMCA 통지 분석 같은 업무를 평문 지침, 정책 자료, 템플릿으로 구조화해 일관성과 처리 속도를 높였다. 다만 AI는 법률적 판단을 대체하는 것이 아니라, 사람이 최종 검토하는 의사결정 지원 시스템으로 활용됐다. ## 반복 업무를 AI 도구로 전환한 배경 - 법무팀의 업무에는 유사 계약 검토, 반복적인 법률 질의 응답, 기존 가이드 재활용 등 반복 작업이 많았다. - 구성원들은 전통적인 프로그래밍 경험이 부족했지만, 자신의 업무 방식과 판단 기준은 명확히 알고 있었다. - Copilot CLI에 자연어로 원하는 기능을 설명하고 저장소와 연결하면서, 프롬프트를 일회성으로 사용하는 대신 재사용 가능한 내부 도구로 발전시켰다. - 지침과 자료를 저장소에서 관리해 버전 관리, 일관성 확보, 협업이 가능해졌다. ## `terms-ai`: 계약 작성 스타일 가이드 구축 - Ngandu Kasuku는 데이터·인프라·제품 통합 관련 파트너십 계약이 급증하자 계약 작성 도구 `terms-ai`를 만들었다. - 저장소에 다음 자료를 정리했다. - AI 작업 지침 - 계약 작성 리소스 - 업무 흐름 - 기존에 승인된 계약서 - 평문 중심의 계약 작성 원칙을 내부 스타일 가이드로 만들었다. - 불필요하게 고어체인 법률 용어를 줄임 - 더 명확하고 읽기 쉬운 문장 사용 - 계약 전반에 동일한 문체와 기준 적용 - 기존 파트너와의 과거 계약 및 승인된 문서를 참고해 새 계약서나 부속합의서 초안을 작성할 수 있게 했다. - 민감한 계약서와 내부 정보는 공개 저장소에 포함하지 않고, 접근 제어가 적용된 내부 환경에 보관했다. - 결과적으로 계약 검토와 작성 시간이 약 절반으로 줄었고, 조항의 일관성과 개인의 작성 스타일 반영 수준이 향상됐다. - 핵심은 AI가 단순히 초안을 생성한 것이 아니라, 변호사의 경험과 판단 방식을 도구에 내장했다는 점이다. ## DMCA 통지 분석을 위한 평문 기반 워크플로 - Jesse Geraci는 DMCA 통지를 처리하기 위해 소스 코드를 빠르고 정확하게 분석해야 하는 문제에서 출발했다. - 처음에는 팀원들이 각자 작성하던 일회성 프롬프트를 다음과 같은 반복 가능한 지침으로 정리했다. - DMCA 통지 분류 - 코드 비교 - 라이선스 확인 - 우회 행위 검토 - 분석 결과 보고서 작성 - 전통적인 소스 코드 대신 다음과 같은 평문 파일을 중심으로 워크플로를 구성했다. - 업무 절차 지침 - 정책 및 법률 참고 자료 - 보고서 템플릿 - 변호사가 가진 언어 구성 능력과 법률적 방법론을 구조화된 업무 로직으로 활용했다. - 고객용과 변호사용 분석 모드를 분리했다. - 고객용: 빠른 결과와 에스컬레이션 권고 제공 - 변호사용: 심층 검토와 양측 주장 분석 제공 - 외부 데이터 소스를 연동하면서 팀이 재사용할 수 있는 표준 워크플로로 확장됐다. ## 데스크톱 앱과 재사용 가능한 법무 에이전트 - 초기 평문 워크플로는 이후 사전 정의된 법무 작업을 실행하는 데스크톱 앱으로 발전했다. - 앱 자체를 구축하려면 상당한 코드가 필요했지만, 실제 업무 동작을 바꾸는 지침은 여전히 Markdown과 자연어로 편집할 수 있다. - DMCA 코드 분석을 넘어 다음 업무로 범위가 확대됐다. - 계약서 검토 - NDA 분류 - 위험 평가 - 컴플라이언스 점검 - 답변 초안 작성 - 내부적으로는 다음과 같은 재사용 가능한 스킬과 에이전트로 업무를 나눌 수 있다. - 접수 및 초기 분류 - 플레이북 기준 대조 - 위험 점수 산정 - 증거 검증 - 에스컬레이션 경로 결정 - 보고서 조립 - 기술적 구현이 복잡해져도 법무팀은 읽기 쉬운 Markdown을 통해 AI의 동작과 기준을 직접 통제할 수 있다. ## 인간의 법률 판단을 중심에 둔 AI 활용 - 법무 Copilot은 변호사를 대체하는 시스템이 아니라 구조화된 의사결정 지원 도구다. - AI 활용의 목적은 다음과 같다. - 법률 분석의 일관성 향상 - 판단 과정의 투명성 확보 - 반복 업무의 확장성 강화 - 사람이 중요한 쟁점과 최종 판단에 집중하도록 지원 - 조직은 완벽한 상용 솔루션이나 전문 개발자를 기다리지 않고, 먼저 자신의 방법론·기준·결과 형식을 명확히 정의할 수 있다. 작게는 반복되는 계약 검토나 자료 분류처럼 시간을 가장 많이 빼앗는 업무 하나를 골라, 자연어 지침과 내부 자료를 재사용 가능한 워크플로로 정리하는 것이 현실적인 시작점이다. 단, 민감한 자료에는 접근 제어를 적용하고, AI 결과는 반드시 담당자의 검토와 승인을 거치도록 설계해야 한다.

원문 읽기(새 탭에서 열림)
AI오픈 소스자동화desktop-app+3