cloudflare2026년 8월 6일

순위에서 추천으로: AI 에이전트 시대에 성공할 수 있도록 사이트를 준비하세요 (새 탭에서 열림)

AI 에이전트가 검색엔진을 대신해 고객의 질문에 답하고 제품·서비스를 추천하는 시대가 오면서, 웹사이트의 발견 가능성은 검색 순위뿐 아니라 에이전트가 사이트를 읽고 신뢰하며 추천할 수 있는지에 달려 있다. Cloudflare는 이를 위해 에이전트가 사이트를 실제로 이용할 수 있는지 점검하는 **Agent Readiness Diagnostics**와, AI 답변에서 브랜드가 얼마나 추천·인용되는지 측정하는 **AEO** 도구를 제공한다. 앞으로는 사람이 읽기 좋은 사이트를 넘어, 에이전트가 쉽게 찾고 읽고 호출할 수 있는 사이트가 경쟁력을 갖게 된다. ## 에이전트 중심으로 바뀌는 웹사이트 발견 방식 - 고객은 검색 결과 페이지보다 AI 어시스턴트에게 직접 질문하고 추천을 받을 가능성이 커지고 있다. - HTML 페이지 요청 중 인간이 직접 발생시키는 요청은 절반 이하이며, 나머지에는 크롤러·자동화 도구·AI 에이전트 등이 포함된다. - 기존의 클릭 수와 페이지뷰만으로는 다음을 알기 어렵다. - AI 에이전트가 사이트에 접근하고 콘텐츠를 사용할 수 있는지 - AI 답변에서 경쟁사 대신 자사 브랜드가 추천되는지 - 에이전트에게 중요한 사이트의 조건은 다음과 같다. - 쉽게 발견될 것 - 기계가 읽기 쉬울 것 - 정보의 출처와 신뢰성이 명확할 것 - 필요한 경우 API나 도구를 통해 직접 작업할 수 있을 것 ## Agent Readiness Diagnostics: 에이전트가 사이트를 사용할 수 있는가 Diagnostics는 사람이 브라우저로 접속하는 방식이 아니라, 에이전트가 사이트를 해석하는 방식으로 기술 상태를 점검한다. - 주요 점검 대상 - `robots.txt` 접근 규칙 - XML 사이트맵 - HTTP 응답 헤더 - 에이전트용 Markdown 콘텐츠 - 인증 및 도구 사용을 위한 공개 메타데이터 - 결과는 “Not Ready”부터 완전한 에이전트 네이티브 상태까지 하나의 준비도 화면으로 통합된다. - 각 항목은 다음 정보를 제공한다. - 통과, 실패, 중립 상태 - 해당 검사가 중요한 이유 - 실제 요청과 응답을 확인할 수 있는 증거 - 개선 항목은 구현 난이도와 우선순위에 따라 나뉜다. ### 빠른 개선 항목 - 크롤러가 읽을 수 있는 `robots.txt` - XML 사이트맵 - AI 크롤러를 위한 접근 규칙 - 에이전트가 처리하기 쉬운 정제된 Markdown 콘텐츠 ### 기술적 기반 - 콘텐츠를 어떤 방식으로 사용해도 되는지 선언하는 Content Signals - API 카탈로그 - 링크 헤더 - 에이전트 로그인 지침 ### 고급 에이전트 통합 - OAuth 검색·발견 기능 - MCP(Model Context Protocol) - A2A(Agent2Agent) 에이전트 카드 - skills index - Web Bot Auth - WebMCP ### 에이전트 상거래 - x402: HTTP 402 Payment Required를 확장한 결제 표준 - ACP(Agent Commerce Protocol) - UCP(Universal Commerce Protocol) - AP2(Agent Payments Protocol) 상거래 관련 항목은 현재 정보 제공 목적이며 준비도 점수에는 포함되지 않는다. ## 진단 결과를 실제 개선으로 연결하는 방식 - Cloudflare 기능으로 해결할 수 있는 문제에는 바로 설정 화면으로 이동하는 “Set up in Cloudflare” 링크가 제공된다. - 예: 에이전트용 Markdown 활성화 - 관리형 `robots.txt` 설정 - 별도 개발이 필요한 경우 “Copy Agent Prompt” 버튼으로 코딩 에이전트에 전달할 구현 지침을 생성할 수 있다. - 변경 후 다시 스캔해 해결 여부를 확인하고, 통과한 항목을 즉시 확인할 수 있다. ## AEO: AI 어시스턴트가 브랜드를 추천하는가 AEO는 사이트를 읽을 수 있는지에서 더 나아가, 실제 고객 질문에 AI가 해당 브랜드를 추천하는지를 측정한다. - Cloudflare는 사이트에서 산업과 카테고리를 추론한다. - 예: 건강·피트니스 산업 - 예: 스포츠 의류 카테고리 - 이후 Claude와 GPT 같은 주요 AI 어시스턴트에 실제 고객이 할 법한 질문을 입력한다. - 질문 유형은 다음을 포함한다. - 제품·서비스 추천 - 경쟁 제품 비교 - 카테고리 전반에 대한 조언 - 특정 브랜드를 질문에 직접 넣지 않고, 자연스러운 시장 탐색 상황에서 어떤 사이트와 브랜드가 선택되는지 측정한다. ## AEO에서 사용하는 주요 지표 - **Citation Rate** - 해당 카테고리의 AI 답변 중 자사 사이트가 출처로 인용된 비율 - **Prominence** - 인용된 경우 답변의 얼마나 앞부분에 등장하는지 - 답변 내용 중 자사 사이트에 얼마나 많은 비중이 귀속되는지 - **Mention Rate** - 출처 링크 여부와 관계없이 답변에서 브랜드명이 언급되는 비율 - 언급률은 높지만 인용률이 낮다면 브랜드 인지도는 있으나 신뢰할 만한 출처로 인정받지는 못하고 있다는 뜻이다. - **Share of Voice** - 경쟁사 대비 자사가 차지하는 인용 비중 - 어떤 질문에서 경쟁사에 밀리는지 파악할 수 있다. - **Industry Fit** - AI가 해당 사이트를 실제 경쟁사들과 함께 인식하는 정도를 나타내는 점수 ## 카테고리별 벤치마크와 사전 계산 - Cloudflare는 산업·카테고리별로 브랜드를 지정하지 않은 질문을 AI에 먼저 질의한다. - 이 과정에서 다음 정보를 수집한다. - 어떤 사이트가 인용되는지 - 답변에서 어느 위치에 등장하는지 - 얼마나 큰 비중으로 다뤄지는지 - 카테고리별 기준 데이터를 한 번 구축한 뒤 여러 계정에서 재사용한다. - 이 방식의 장점 - 매번 AI 모델을 다시 호출하지 않아 결과가 즉시 표시된다. - 수천 개 사이트가 같은 질문을 반복하는 데 따른 컴퓨팅 비용을 줄인다. - 동일 시장에서 함께 등장하는 브랜드를 파악해 Industry Fit을 계산할 수 있다. ## AI 답변의 변동성을 반영한 평가 방식 - AI는 같은 질문에도 매번 완전히 동일한 답변을 생성하지 않는다. - 이를 보완하기 위해 Cloudflare AI Gateway를 사용해 여러 모델과 여러 번의 질의를 수행한다. - 평가 대상은 단순한 브랜드 언급이 아니다. - 사이트가 출처로 인용됐는지 - 인용이 답변의 앞부분에 나오는지 - 답변의 실질적인 내용이 사이트에 얼마나 귀속되는지 - Workers AI가 답변을 분석하고 점수를 계산한다. - 모델이 자기 답변을 다시 평가하는 방식이 아니라, 응답 텍스트와 출처를 대상으로 정확한 텍스트 분석을 함께 사용한다. - 따라서 직접 다중 모델 평가 시스템을 구축하지 않아도 실행 가능한 AEO 지표를 얻을 수 있다. ## AI Operator Activity로 실제 유입과 오류 확인 - AI Operator Activity는 실제 운영자별 크롤링 및 추천 트래픽을 보여준다. - 확인 가능한 정보 - OpenAI, Google 등 어떤 운영자가 사이트를 읽는지 - 어떤 운영자가 방문자를 사이트로 보내는지 - 크롤링·추천 과정에서 발생한 오류 - `403`: 접근 차단 - `404`: 잘못되거나 사라진 링크 - 이를 통해 AI가 사이트를 발견하지 못하는 문제와, 발견했지만 접근·탐색 과정에서 실패하는 문제를 구분할 수 있다. 사이트 운영자는 먼저 `robots.txt`, 사이트맵, Markdown 콘텐츠 같은 기본적인 기계 가독성을 확보한 뒤, API·OAuth·MCP 등 직접 실행 가능한 인터페이스를 추가하는 것이 좋다. 이후 AEO 지표를 통해 인용률과 경쟁사 대비 점유율을 지속적으로 추적해야 하며, 단순히 AI 봇 방문 수를 늘리는 것보다 실제 추천과 출처 인용으로 이어지는 구조를 만드는 데 집중해야 한다.

oauthcloudflaremodel-context-protocolai-gateway+4

cloudflare2026년 8월 5일

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 서버에 쓰기 권한을 추가할 때는 단순한 사용자 인증만으로는 부족하다. 도구별 위험도 정책, 에이전트 세션 식별, 민감정보 제거 감사 로그, 사전 차단 기능을 중앙 계층에서 제공해야 하며, 특히 대량 변경이 가능한 작업은 높은 위험도로 분류해 별도 통제하는 것이 안전하다.

oauthai-agentgitlabmodel-context-protocol+4

gitlab2026년 7월 8일

GitLab 패치 릴리스: 19.1.2, 19.0.4, 18.11.7 | GitLab 문서 (새 탭에서 열림)

2026년 7월 8일 GitLab은 CE/EE용 패치 버전 19.1.2, 19.0.4, 18.11.7을 출시했다. 이번 릴리스는 XSS·HTML 인젝션·권한 우회·자격 증명 노출 등 여러 보안 취약점과 버그를 수정했으며, 자체 호스팅 사용자는 즉시 업그레이드하는 것이 권장된다. GitLab.com은 이미 패치가 적용됐고, GitLab Dedicated 고객은 별도 조치가 필요 없다. ## 패치 릴리스와 업그레이드 권고 - 패치 릴리스는 정기 릴리스와 고위험 취약점에 대응하는 비정기 긴급 패치로 나뉜다. - 정기 패치는 매월 둘째·넷째 수요일에 배포된다. - 영향을 받는 모든 자체 관리형 설치 환경은 Omnibus, 소스 코드, Helm Chart 등 배포 방식과 관계없이 최신 패치 버전으로 업그레이드해야 한다. - 보안 취약점 상세 이슈는 수정 버전 출시 후 90일이 지나면 공개된다. ## 취약점: XSS와 HTML 인젝션 - **CVE-2026-6896** - GitLab EE의 취약점 증거 테이블 렌더러에서 사용자 입력 sanitization이 충분하지 않았던 문제다. - Developer 권한의 인증 사용자가 다른 사용자의 브라우저 세션에서 임의 스크립트를 실행할 수 있었다. - CVSS 8.7로 이번 릴리스에서 가장 심각한 취약점 중 하나다. - EE 13.11 이후 버전 중 18.11.7, 19.0.4, 19.1.2 이전 버전에 영향을 준다. - **CVE-2026-13320** - CE/EE의 Wiki 마크업 렌더링 과정에서 HTML 인젝션이 가능했던 문제다. - 인증 사용자가 다른 사용자의 브라우저 세션에서 스크립트를 실행할 수 있었다. - CVSS 7.3이며, 높은 권한과 특정 조건이 필요하다. - CE/EE 15.7 이후 버전 중 각 패치 버전 이전 릴리스가 영향을 받는다. ## 자격 증명 및 저장소 보안 문제 - **CVE-2026-11827** - EE 저장소 미러링 기능의 권한 검사가 부족했다. - Maintainer 권한 사용자가 다른 사용자의 저장된 자격 증명을 획득할 수 있었다. - CVSS 4.9이며, EE 9.5 이후 버전에 영향을 준다. - **CVE-2025-12506** - Git 태그·브랜치 이름 해석이 모호하게 처리되는 문제다. - 공격자가 웹 인터페이스에 표시되는 저장소 내용과 다운로드 가능한 실제 내용이 다르게 보이는 저장소를 만들 수 있었다. - CE/EE 16.5 이후 버전에 영향을 주며 CVSS는 3.5다. ## 권한 검증 및 정보 노출 문제 - **CVE-2026-8472** - EE Work Items 기능에서 비공개 프로젝트의 메타데이터 접근 권한 검사가 누락됐다. - 최소 권한을 가진 인증 사용자가 비공개 프로젝트의 Work Item 정보를 읽을 수 있었다. - CVSS 4.3이다. - **CVE-2026-7492** - 커밋 토론 표시와 프로젝트 간 참조 페이지에서 권한 검사가 제대로 이뤄지지 않았다. - 비인증 사용자가 비공개 프로젝트의 존재 여부를 추론할 수 있었다. - CE/EE에 영향을 주며 CVSS는 4.3이다. - **CVE-2026-13151** - EE 그룹 수준 설정에 대한 권한 검사가 부정확했다. - 인증 사용자가 자신의 권한 범위를 넘어 그룹 설정을 수정할 수 있었다. - CVSS 2.7이며 GitLab 내부에서 발견됐다. - **CVE-2026-6352** - EE의 컴플라이언스 위반 관리 GraphQL 작업에서 권한 검사가 부족했다. - Auditor 수준 사용자가 컴플라이언스 위반 기록을 수정할 수 있었다. - CVSS 2.7이다. ## 버그 수정 및 기술 변경 ### 19.1.2 - OAuth 애플리케이션 등록 및 생성 시 `organization_id`를 설정하도록 수정했다. - 제약 조건 검증 전에 `oauth_applications`의 `NULL organization_id` 값을 보완하는 백필을 추가했다. - Go 버전을 1.25.11로 업데이트했다. - 멀티 아키텍처 태그를 레거시 레지스트리 경로에서 처리할 때 발생하던 HTTP 500 오류를 수정했다. - 외부 에이전트 흐름에서 커밋 작성자와 커미터의 신원을 사용하도록 개선했다. - ClickHouse 23.x에서 `ci_finished_builds` 엔진 교체가 동작하도록 수정했다. - Duo Workflow 이벤트 조회를 최신 체크포인트로 제한하고 커서 페이지네이션을 적용했다. - Developer가 작성한 Merge Request의 승인 규칙 재정의 회귀 문제를 수정했다. - 커밋 설명을 지나치게 미리 가져오면서 발생하던 커밋 페이지 메모리 누수를 해결했다. - 더 이상 필요하지 않은 `ActiveUserCountThresholdWorker` cron 스케줄을 제거했다. - 레지스트리 인증, OAuth 처리, 빌더 이미지 리비전 등 관련 구성도 백포트 및 조정했다. ### 19.0.4 및 18.11.7 - 19.0.4에도 OAuth 애플리케이션 등록 시 `organization_id`를 설정하는 수정이 백포트됐다. - CI_JOB_TOKEN을 이용한 레지스트리 인증 방식과 같은 일부 수정 사항이 19.0 안정화 브랜치에 반영됐다. - 18.11.7은 위 보안 취약점들이 수정된 18.11 계열의 권장 패치 버전이다. ## 실용적인 권장 사항 자체 호스팅 GitLab 운영자는 현재 지원 중인 계열에 맞춰 **19.1.2, 19.0.4, 18.11.7 중 하나로 즉시 업그레이드**하는 것이 좋다. 특히 EE에서 저장소 미러링, Work Items, 컴플라이언스 관리, 취약점 증거 렌더링을 사용하는 환경은 패치 적용 전까지 권한과 외부 입력 처리 기능을 우선 점검해야 한다.

oauthgitlabgraphqlcross-site-scripting+4

cloudflare2026년 6월 24일

모두를 위한 OAuth로 Cloudflare 앱 생태계의 잠금 해제 (새 탭에서 열림)

Cloudflare는 API 토큰 중심의 제한적인 연동 방식을 넘어, 모든 고객이 직접 OAuth 클라이언트를 관리할 수 있는 self-managed OAuth를 도입했다. 이를 통해 SaaS, 내부 개발자 플랫폼, 에이전트 도구가 사용자로부터 필요한 권한만 위임받고, 사용자는 동의·철회·권한 범위를 더 명확하게 관리할 수 있게 됐다. 이 확장을 위해 동의 화면과 철회 기능을 개선하고, OAuth 엔진인 Hydra를 무중단에 가깝게 1.X와 2.X로 단계적으로 업그레이드했다. ## 모든 고객을 위한 self-managed OAuth - 기존 Cloudflare OAuth는 Wrangler나 PlanetScale 같은 일부 파트너 통합에만 제공됐다. - 자체 통합을 개발하는 일반 개발자는 API 토큰을 사용해야 했지만, API 토큰은 다음과 같은 한계가 있었다. - 관리가 어렵다. - 사용자가 애플리케이션에 권한을 위임하는 흐름에 적합하지 않다. - 권한 범위와 철회 상태를 사용자 관점에서 명확히 관리하기 어렵다. - self-managed OAuth를 사용하면 개발자가 직접 OAuth 클라이언트를 만들고 관리할 수 있다. - 애플리케이션은 사용자가 승인한 범위 내에서만 Cloudflare API에 접근하며, 사용자는 권한을 쉽게 철회할 수 있다. - 주요 활용 사례는 SaaS 통합, 내부 개발자 플랫폼, 에이전트 기반 도구다. ## 대규모 OAuth 생태계를 위한 보안 개선 - 기존 OAuth 시스템은 소수의 파트너를 수동 관리하는 데는 충분했지만, 모든 고객에게 개방하기에는 권한 모델과 보안 장치가 부족했다. - 동의 화면을 개선해 다음 정보를 명확히 표시했다. - 어떤 애플리케이션이 접근을 요청하는지 - 애플리케이션에 부여될 권한이 무엇인지 - Cloudflare 대시보드에 애플리케이션 권한 철회 기능을 추가했다. - 앱 소유자 정보를 더 잘 표시해 OAuth 피싱 공격을 예방했다. - 동시에 OAuth 엔진의 성능과 데이터 안정성을 개선하면서, 사용자 중단을 최소화하는 업그레이드 계획이 필요했다. ## Hydra 1.X 업그레이드와 데이터베이스 마이그레이션 - Cloudflare는 기존 OAuth 엔진으로 오픈소스 Hydra를 사용하고 있었다. - 개발자 플랫폼과 에이전트 워크플로가 성장하면서 성능과 기능 확장을 위해 Hydra 업그레이드가 필요해졌다. - 한 번에 대규모 업그레이드를 진행하지 않고 다음 두 단계로 나눴다. 1. 최신 1.X 버전으로 업그레이드 2. 동작과 성능을 검증한 뒤 2.X로 업그레이드 - 1.X 업그레이드에도 다음과 같은 위험이 있었다. - 인덱스 생성이 주요 테이블에 배타적 잠금을 걸어 OAuth 작업을 차단할 수 있었다. - 주요 테이블에 컬럼을 추가하거나 다른 테이블로 컬럼을 이동해야 했다. - 기존 Hydra SDK의 `SELECT *` 사용 때문에 스키마 변경 후 역직렬화 문제가 발생할 수 있었다. - 이를 해결하기 위해: - 인덱스 생성 SQL을 `CREATE INDEX CONCURRENTLY` 기반으로 다시 작성했다. - 필요한 컬럼만 명시적으로 조회하는 Hydra 커스텀 버전을 제작했다. - 실제 1.X 마이그레이션은 예상보다 빠르게 완료됐고 사용자 영향도 없었다. - 다만 구버전 Hydra가 신버전에서 생성된 토큰을 조회하지 못했기 때문에 점진적 전환이 아닌 하드 컷오버가 필요했다. ## 2.X 업그레이드를 위한 블루-그린 전략 - Hydra 2.X는 스키마 변경 규모가 커서 기존 데이터베이스에서 바로 업그레이드하는 인플레이스 방식은 적합하지 않았다. - Cloudflare는 새 환경을 준비한 뒤 전환하는 블루-그린 방식을 선택했다. - 단순히 데이터베이스 연결만 바꾸는 방식으로는 부족했다. 마이그레이션에 수 시간이 걸리는 동안에도 OAuth가 계속 작동해야 했기 때문이다. - 검토한 첫 번째 방식은 업그레이드 중 데이터베이스 쓰기를 중단하는 것이었다. - 신규 OAuth 승인을 막아 데이터 유실을 방지할 수 있다. - 하지만 기존 앱도 새 인증을 사용할 수 없게 된다. - 사용자가 애플리케이션 권한을 철회할 수도 없어 보안상 문제가 된다. - 따라서 쓰기를 계속 허용하되, 전환 과정에서 일부 쓰기가 유실될 수 있는 방식을 채택했다. ## 토큰 만료 조정과 철회 이벤트 보존 - 전환 중 발생하는 신규 토큰 쓰기를 줄이기 위해 토큰 만료 시간을 몇 시간으로 늘렸다. - 업그레이드 직전에 발급된 토큰이 갱신 없이 계속 사용되도록 해, 전환 기간의 토큰 갱신 요청을 줄였다. - 반면 권한 철회 이벤트는 절대 유실되면 안 됐다. - 철회 이벤트가 사라지면 사용자가 접근을 차단한 애플리케이션의 권한이 다시 살아날 수 있다. - Cloudflare는 Cloudflare Queues를 이용해 철회 이벤트를 별도 큐에 기록했다. - 녹색 환경으로 전환한 뒤 큐를 비우면서 철회 이벤트를 재생해, 업그레이드 중 발생한 모든 철회를 반영했다. ## 리프레시 토큰 문제와 완화 - Hydra 1.X 업그레이드 후 리프레시 토큰 오류가 증가했다. - 새 버전에서는 리프레시 토큰이 재사용되면 전체 액세스 토큰·리프레시 토큰 체인을 무효화하는 동작이 더 엄격해졌다. - 요청량이 많은 Wrangler와 MCP 클라이언트에서는 재시도 한 번만 발생해도 전체 세션이 무효화될 수 있었다. - Cloudflare는 OAuth 트래픽을 라우팅하는 Worker에 리프레시 토큰 요청 병합(coalescing)을 추가했다. - 동일 요청의 짧은 재시도를 잠시 캐시했다. - 재시도를 감지하면 Hydra에 다시 전달하지 않고 기존 요청 결과를 반환했다. - Hydra 2.X에서는 리프레시 토큰을 일정 시간 동안 재사용해도 전체 체인을 무효화하지 않는 `refresh token grace period` 설정을 제공해 이 문제를 근본적으로 완화할 수 있었다. ## 실용적인 결론 대규모 OAuth 시스템을 개방하려면 클라이언트 등록 기능만 추가해서는 부족하다. 명확한 동의 화면, 즉각적인 권한 철회, 앱 소유자 표시 같은 보안 기능과 함께, 스키마 마이그레이션 중에도 철회 이벤트를 보존하는 큐, 토큰 만료 조정, 토큰 갱신 재시도 제어 같은 운영 설계가 함께 필요하다.

oauthcloudflare-workerswranglerdatabase-migrations+3

cloudflare2026년 6월 19일

AI 에이전트를 위한 임시 Cloudflare 계정 (새 탭에서 열림)

Cloudflare는 AI 에이전트가 사람의 개입 없이 코드를 배포할 수 있도록 ‘임시 계정’을 출시했다. 에이전트는 `wrangler deploy --temporary`를 실행해 별도 회원가입이나 OAuth, API 토큰 입력 없이 Worker를 배포하고, 60분 동안 결과를 테스트할 수 있다. 사용자가 그 안에 계정을 클레임하면 영구 계정이 되며, 클레임하지 않으면 자동 삭제된다. ## AI 에이전트 배포에서 인증이 걸림돌이 되는 이유 - 기존 클라우드 서비스 가입 과정은 브라우저 OAuth, 대시보드 조작, API 토큰 복사, MFA 입력 등 사람을 전제로 한다. - 백그라운드에서 실행되는 AI 에이전트는 브라우저를 열거나 사용자의 즉각적인 확인을 기다리기 어렵다. - 인증 단계에서 멈추면 에이전트가 다른 배포 서비스를 선택할 가능성도 있다. - 에이전트는 코드를 작성하고 배포한 뒤 직접 요청을 보내 검증하는 반복 작업이 중요하므로, 빠르고 저렴한 임시 배포 환경이 필요하다. ## `wrangler deploy --temporary`를 통한 배포 - 최신 Wrangler CLI에서 다음 명령으로 임시 계정에 Worker를 배포할 수 있다. ```bash wrangler deploy --temporary ``` - 사용자가 Cloudflare에 로그인하지 않은 상태에서 배포를 시도하면 Wrangler가 `--temporary` 옵션을 안내한다. - 에이전트가 해당 옵션으로 다시 배포하면 Cloudflare가 자동으로: - 임시 Cloudflare 계정을 생성하고 - Wrangler가 사용할 API 토큰을 발급하며 - 사용자가 계정을 인수할 수 있는 클레임 URL을 제공한다. - 에이전트는 별도의 사람 확인 없이 코드를 작성하고 즉시 배포할 수 있다. ## 작성·배포·검증의 반복 루프 - 에이전트는 TypeScript Worker를 생성한 뒤 배포 결과로 받은 미리보기 URL에 `curl` 등을 실행해 동작을 검증한다. - 예를 들어 “hello world” Worker를 배포한 뒤 응답이 코드와 일치하는지 확인할 수 있다. - 이후 소스 코드를 수정하고 같은 임시 계정을 재사용해 여러 번 재배포할 수 있다. - 임시 계정은 60분의 클레임 기간 동안 유지되므로, 에이전트가 여러 차례 수정·테스트하는 데 적합하다. ## 임시 계정의 클레임과 자동 삭제 - 사용자는 에이전트가 제공한 클레임 링크를 클릭해 Cloudflare에 가입하거나 로그인할 수 있다. - 계정을 클레임하면 임시 계정이 영구적으로 사용자의 계정이 된다. - Worker뿐 아니라 데이터베이스와 기타 바인딩 리소스도 함께 인수할 수 있다. - 60분 이내에 클레임하지 않으면 임시 계정과 배포된 리소스가 자동으로 삭제된다. ## 더 넓은 에이전트용 인프라 - Cloudflare는 Stripe와 협력해 에이전트가 사용자를 대신해 계정 생성, 구독 시작, 도메인 등록, API 토큰 발급까지 수행할 수 있는 프로토콜도 개발하고 있다. - WorkOS와는 기존 OAuth 표준을 활용해 에이전트가 계정을 생성할 수 있도록 하는 `auth.md` 프로젝트를 추진했다. - 임시 계정은 이러한 ‘에이전트 친화적 배포’ 전략의 한 단계로 소개된다. - 기능과 제한 사항은 변경될 수 있으므로 실제 사용 전 Cloudflare 개발자 문서를 확인해야 한다. 에이전트가 짧은 실험이나 프로토타입을 자동으로 배포·검증해야 한다면 `wrangler deploy --temporary`가 유용하다. 다만 60분 내에 클레임하지 않으면 리소스가 삭제되므로, 장기 운영 서비스는 반드시 계정을 클레임하고 정식 인증·관리 체계로 전환해야 한다.

oauthai-agenttypescriptcloudflare-workers+4

cloudflare2026년 6월 5일

AI 비용이 감당할 수 없을 정도로 늘었습니다. 이제 Cloudflare가 해결할 수 있습니다. (새 탭에서 열림)

AI 사용이 확산되면서 기업은 막대한 토큰 비용을 부담하지만, 공유 API 키만으로는 누가 어떤 모델을 얼마나 사용했는지 파악하기 어렵다. Cloudflare는 AI Gateway에 달러 기준 지출 한도, 요청별 비용 추적, 모델 자동 전환 기능을 추가해 AI 비용을 통제할 수 있도록 했다. 또한 Cloudflare Access와 기존 IdP를 연동하면 사용자·팀·에이전트별 예산과 모델 사용 정책을 적용할 수 있다. ### 공유 API 키가 만드는 비용 관리의 한계 - 여러 엔지니어가 하나의 API 키를 사용하면 사용자별·팀별 비용을 추적할 수 없다. - 월말 청구서만 보고는 비용 증가 원인이 다음 중 무엇인지 알기 어렵다. - 머신러닝 팀의 신규 파이프라인 - 인턴의 고가 모델 사용 - CI 작업의 무한 반복 - 예산과 라우팅 기준이 없으면 사용자는 대부분 가장 강력하고 비싼 모델을 선택하게 된다. - 단순한 코드 리뷰 요약이나 로그 파싱에는 최첨단 모델이 필요하지 않으므로, 작업에 맞는 모델 선택과 비용 가시성이 중요하다. ### AI Gateway의 기본 역할 - 애플리케이션과 OpenAI, Anthropic, Google 등 AI 제공업체 사이에 위치하는 중간 계층이다. - 여러 제공업체와 모델을 하나의 인터페이스와 청구 체계로 관리할 수 있다. - 모든 요청의 로그, 토큰 수, 비용을 통합해 확인할 수 있다. - 응답 캐싱으로 반복 요청 비용을 줄일 수 있다. - Rate limiting으로 요청량을 제한할 수 있다. - PII와 비밀정보가 모델에 전달되기 전에 차단하는 콘텐츠 가드레일을 제공한다. - 기존에는 전체 계정 사용량은 볼 수 있었지만, 사용자별 비용 귀속이나 예산 설정은 어려웠다. ### 달러 기준 지출 한도 - 토큰 수가 아니라 실제 비용인 달러를 기준으로 예산을 설정한다. - 요청마다 모델 가격을 바탕으로 비용을 계산하고, 누적 지출을 실시간으로 한도와 비교한다. - 다음 기준을 조합해 한도를 지정할 수 있다. - 모델 - 제공업체 - 사용자, 팀, 애플리케이션 등 관리자가 정의한 속성 - 예산 기간은 고정형 또는 이동형으로 설정할 수 있다. - 매월 1일, 매주 월요일, 매일 자정에 초기화 - 최근 24시간·7일·30일처럼 이동하는 기간 - 일간·주간·월간 예산을 지원한다. - 한도에 도달하면 기본적으로 추가 요청을 차단한다. - Dynamic Routes를 사용하면 고가 모델 대신 저렴한 대체 모델로 요청을 전환할 수 있다. - 지출 한도 기능은 모든 요금제의 AI Gateway 사용자를 대상으로 오픈 베타로 제공된다. ### Cloudflare의 실제 사용 방식 - Cloudflare는 직원들의 AI 요청을 AI Gateway로 통합하고, 월간 수백만 건의 요청과 수십억 토큰을 처리한다. - 직원이 Cloudflare Access로 인증하면 JWT에서 신원을 추출한다. - 추출한 사용자 정보를 AI Gateway 요청의 메타데이터로 추가한다. - 이를 통해 다음을 확인할 수 있다. - 사용자별 토큰 소비량 - 팀별 사용량 - 조직 전체의 비용 귀속 - 단순히 공유 API 키를 사용하는 방식보다 비용의 책임 소재와 사용 패턴을 명확히 파악할 수 있다. ### Access 기반 사용자·팀별 정책 - 현재 폐쇄 베타로 제공되는 기능이다. - AI Gateway의 사용자 정의 메타데이터 방식과 달리, Cloudflare Access를 사용하면 인증된 신원을 자동으로 검증할 수 있다. - 사용자별 월간 예산을 설정할 수 있다. - 일반 엔지니어: 월 500달러 - 고급 엔지니어: 월 2,000달러 - 예산을 초과하면 요청을 차단하거나 저렴한 모델로 자동 전환할 수 있다. - IdP 그룹에 따라 팀별 모델 접근 정책을 설정할 수 있다. - ML 팀: Claude Opus, GPT-4o - 디자인 팀: 이미지·비디오 생성 모델 - 인턴: Workers AI 기반 오픈소스 모델 - CI/CD 파이프라인과 자율 에이전트에는 Access 서비스 토큰으로 고유한 신원을 부여할 수 있다. - 코드 리뷰 봇과 문서 생성기를 별도로 추적하고, 특정 에이전트의 폭주만 독립적으로 제한할 수 있다. - 로그에는 이메일, IdP 그룹, 서비스 토큰 이름이 포함되며, 이를 분석 플랫폼으로 내보내 사용자·팀·에이전트별 비용 보고서를 만들 수 있다. ### 인증 및 구성 방식 - AI Gateway 엔드포인트에 Cloudflare Access 애플리케이션을 구성한다. - 기존 IdP 그룹을 바탕으로 Access 정책을 설정한다. - 개발자나 에이전트는 OAuth 기반의 일반적인 CLI 디바이스 코드 흐름으로 인증한다. - AI Gateway가 토큰을 검증하고 인증된 신원을 자동으로 추출한다. - 별도의 Worker 작성, JWT 직접 파싱, 신뢰할 수 없는 메타데이터 헤더에 의존할 필요가 없다. ### 실용적인 적용 방향 기업은 먼저 AI Gateway를 모든 모델 요청의 단일 경로로 구성하고, 사용자·팀·애플리케이션별 로그와 비용을 수집하는 것이 좋다. 이후 업무 유형에 맞는 모델 라우팅과 달러 기준 예산을 설정하고, 마지막으로 Cloudflare Access와 IdP를 연동해 인증된 사용자 및 에이전트별 정책을 적용하면 비용 통제와 업무 연속성을 함께 확보할 수 있다.

oauthci-cdcloudflare-accessidentity-provider+4

aws2026년 6월 3일

Amazon Cognito 다중 리전 복제로 애플리케이션 복원력 향상 | Amazon Web Services (새 탭에서 열림)

Amazon Cognito의 다중 리전 복제는 사용자 인증과 M2M 인증을 보조 리전에서도 지속할 수 있도록 해 애플리케이션의 복원력을 높인다. 기본 리전의 사용자 프로필, 자격 증명, 머신 시크릿, 풀 설정을 보조 리전에 자동 복제하며, 장애 전환 시 기존 사용자의 재로그인이나 강제 비밀번호 재설정을 줄일 수 있다. 다만 사용자 등록·프로필 수정은 장애 전환 중 제한되며, KMS 키와 애플리케이션·주변 AWS 리소스에 대한 별도 구성이 필요하다. ## 기존 멀티 리전 인증의 문제 - 리전 간 Cognito 설정과 사용자 데이터를 일관되게 유지하려면 팀이 직접 복제 시스템을 구축·운영해야 했다. - 사용자 데이터를 수동으로 내보내고 가져오는 과정에서 다음 문제가 발생했다. - 민감한 인증 데이터 노출 위험 - 리전 간 데이터 불일치 - 장애 전환 시 강제 비밀번호 재설정 및 재인증 - M2M 인증에서는 보조 리전에 새 앱 클라이언트를 만들고, 애플리케이션과 OAuth 리소스가 새 리전의 토큰 발급자를 신뢰하도록 재구성해야 했다. ## Cognito 다중 리전 복제 방식 - 기본 리전에서 선택한 보조 AWS 리전으로 데이터를 단방향 복제한다. - 다음 항목이 복제된다. - 사용자 프로필 - 사용자 자격 증명 - 머신 인증용 시크릿 - 사용자 풀 구성 - 보조 리전은 읽기 전용으로 동작하며 인증 지속성을 제공한다. - 양쪽 리전이 서로 발급한 액세스 토큰을 인식하므로, 기존 로그인 세션을 유지할 수 있다. - 다음 인증 방식을 지원한다. - Amazon, Google, Apple, Facebook 등 소셜 로그인 - SAML 및 OIDC 연동 - API 및 M2M 인증 흐름 - 장애 전환 중에는 인증은 가능하지만 신규 사용자 등록이나 사용자 프로필 변경은 사용할 수 없다. ## 고객 관리형 KMS 키 - 복제를 구성하려면 AWS KMS에 저장된 멀티 리전 고객 관리형 키가 필요하다. - 동일한 암호화 키를 리전 간 복제해 사용자 데이터 저장 시 일관된 암호화 정책을 적용한다. - Cognito가 키를 사용할 수 있도록 KMS 키 정책에 권한을 추가해야 한다. - 고객 관리형 키를 사용하면 AWS 기본 키에만 의존하지 않고 조직의 암호화 및 키 관리 전략을 적용할 수 있다. ## 복제 설정 절차 예시로 `us-west-2`의 사용자 풀을 `us-east-1`로 복제한다. 1. **고객 관리형 KMS 키 설정** - 두 리전에 키를 생성·복제한다. - KMS 키 정책에 Amazon Cognito의 키 사용 권한을 추가한다. 2. **멀티 리전 OIDC 엔드포인트 설정** - 콘솔에서 새로운 OIDC issuer 유형을 활성화한다. - 변경된 엔드포인트를 서버 애플리케이션과 모바일 앱에 반영한다. - 서버는 재배포가 필요하고, 모바일 앱은 App Store와 Google Play에 업데이트를 제출해야 할 수 있다. - 엔드포인트를 변경하지 않으면 기존 인증 요청이 올바르게 라우팅되지 않아 사용자 장애가 발생할 수 있다. 3. **복제 대상 리전 선택** - 고객 관리형 키가 복제된 리전만 대상 리전으로 선택할 수 있다. - 데이터 규모에 따라 복제 준비 시간이 달라진다. - 복제 사용자 풀이 준비되면 관리자가 수동으로 활성화해야 한다. ## 장애 전환과 트래픽 라우팅 - 기본 리전과 보조 리전의 엔드포인트는 항상 활성 상태로 유지된다. - 애플리케이션 요구사항에 맞춰 다음 항목을 기준으로 헬스 체크를 설계할 수 있다. - 인증 오류율 - 지연 시간 증가 - 특정 AWS 서비스 장애 알림 - 장애 조건이 충족되면 DNS를 변경해 보조 리전으로 트래픽을 전환한다. - 실제 장애 전에 비업무 시간에 일부 트래픽만 보조 리전으로 보내 인증 흐름을 검증하는 것이 권장된다. - 관리형 로그인과 사용자 지정 도메인 기반 연동에서는 Route 53 헬스 체크 ID를 이용한 내장 트래픽 라우팅도 사용할 수 있다. ## 추가로 준비해야 할 리소스 다중 리전 복제 자체만으로 모든 인증 관련 리소스가 자동 복제되는 것은 아니다. - 사용자 지정 인증 흐름에 사용하는 Lambda 함수를 대상 리전에 배포해야 한다. - SMS 및 이메일 알림 설정도 대상 리전에서 별도로 구성해야 한다. - 로그 스트리밍 설정과 AWS WAF 규칙을 수동으로 복제해야 한다. - 장애 전환 절차, DNS 변경, 보안 정책을 사전에 문서화하고 테스트해야 한다. ## 가격과 제공 리전 - Essentials 및 Plus 요금제의 추가 기능으로 제공된다. - 사용자 인증 비용: - Essentials: 복제 리전별 월간 활성 사용자당 `$0.0045` - Plus: 복제 리전별 월간 활성 사용자당 `$0.006` - M2M 인증은 성공적으로 발급된 토큰의 표준 볼륨 요금에 30%가 추가된다. - 미국, 캐나다, 유럽, 아시아 태평양, 남미 등 여러 리전에서 제공되며, 지원 리전은 기본 리전과 복제 대상 리전 모두로 사용할 수 있다. ## 실용적인 권장 사항 다중 리전 복제는 인증 중단을 최소화해야 하는 고객-facing 서비스와 M2M 백엔드에 적합하다. 도입 전 KMS 키, OIDC 엔드포인트, Lambda·WAF·로그 설정을 함께 준비하고, 인증 지속성과 장애 전환 후의 읽기 전용 제약을 포함한 실제 장애 대응 테스트를 수행하는 것이 좋다.

oauthaws-lambdasamlopenid-connect+4

gitlab2026년 5월 13일

GitLab 패치 릴리스: 18.11.3, 18.10.6, 18.9.7 | GitLab 문서 (새 탭에서 열림)

GitLab은 2026년 5월 13일 보안 및 버그 수정이 포함된 18.11.3, 18.10.6, 18.9.7 패치 버전을 출시했으며, 모든 자체 관리형 설치 환경에 즉시 업그레이드를 권고했습니다. 이번 릴리스에는 인증된 사용자가 악성 JavaScript를 실행할 수 있는 XSS, 인증 없이 서비스를 마비시킬 수 있는 DoS, 권한 검증 오류 등이 수정되었습니다. GitLab.com은 이미 패치가 적용되었고, GitLab Dedicated 고객은 별도 조치가 필요하지 않습니다. ## 릴리스 대상과 업그레이드 권고 - 대상 버전: - GitLab 18.11.3 - GitLab 18.10.6 - GitLab 18.9.7 - CE와 EE 모두에 해당하는 수정이 포함되었습니다. - Omnibus, 소스 설치, Helm 차트 등 특정 배포 방식이 명시되지 않은 취약점은 모든 배포 유형에 영향을 줍니다. - 지원되는 버전을 운영 중인 자체 관리형 GitLab은 가능한 한 빨리 최신 패치 버전으로 업그레이드해야 합니다. - GitLab 패치 릴리스는 매월 둘째·넷째 수요일의 정기 릴리스와, 심각도가 높은 취약점에 대응하는 비정기 긴급 패치로 나뉩니다. - 보안 취약점의 상세 이슈는 패치된 릴리스 후 30일이 지나면 공개됩니다. ## XSS 취약점 수정 - **CVE-2026-7481 — Analytics 대시보드 차트 렌더링** - GitLab EE에 영향. - Developer 권한의 인증된 사용자가 입력값 검증 부실을 악용해 다른 사용자의 브라우저에서 임의 JavaScript를 실행할 수 있었습니다. - CVSS 8.7. - 16.4 이상에서 18.9.7, 18.10.6, 18.11.3 이전 버전에 영향. - **CVE-2026-5297 — 전역 검색** - GitLab CE/EE에 영향. - 인증된 사용자가 조작된 입력을 통해 다른 사용자의 브라우저에서 JavaScript를 실행할 수 있었습니다. - CVSS 8.7. - 15.11 이상에서 수정 버전 이전까지 영향. - **CVE-2026-6073 — Duo Agent 출력 렌더링** - GitLab EE에 영향. - Duo Agent 출력 처리 과정의 입력값 정제 부족으로 XSS가 발생할 수 있었습니다. - CVSS 8.7. - 18.7 이상 버전 중 수정 버전 이전에 영향. - **CVE-2026-7377 — 사용자 지정 Analytics 대시보드** - GitLab EE에 영향. - 인증된 사용자가 대시보드 입력을 조작해 다른 사용자의 브라우저 컨텍스트에서 임의 JavaScript를 실행할 수 있었습니다. - CVSS 8.7. - 18.7 이상 버전 중 수정 버전 이전에 영향. ## 인증 없이 악용 가능한 DoS 취약점 - **CVE-2026-1659 — CI/CD 작업 업데이트 API** - 특수하게 조작된 요청과 불충분한 입력 검증을 이용해 인증 없이 서비스 거부를 일으킬 수 있었습니다. - GitLab CE/EE에 영향. - CVSS 7.5. - **CVE-2025-14870 — Duo Workflows API** - 조작된 JSON 페이로드를 전송해 인증 없이 서비스 거부를 유발할 수 있었습니다. - GitLab CE/EE에 영향. - CVSS 7.5. - **CVE-2025-14869 — 내부 API 엔드포인트** - 특정 API 엔드포인트에 악성 페이로드를 보내 서비스 거부를 일으킬 수 있었습니다. - GitLab CE/EE에 영향. - CVSS 7.5. - **CVE-2026-1184 — Insights 구성** - GitLab EE에서 조작된 파일 업로드와 부적절한 검증을 통해 서비스 거부가 발생할 수 있었습니다. - CVSS 6.5. - 일부 설명에서는 인증 요구 수준이 명시되어 있으므로 외부 파일 업로드 경로를 특히 점검해야 합니다. ## 권한 및 접근 제어 취약점 - **CVE-2026-1322 — GraphQL 토큰 범위 적용** - `read_api` 범위만 가진 OAuth 애플리케이션이 비공개 프로젝트에 이슈를 생성하거나 댓글을 추가할 수 있었습니다. - 인증 및 권한 검증 오류가 원인이었습니다. - GitLab CE/EE에 영향. - CVSS 6.8. - **CVE-2026-4524 — Issues API** - 공개 프로젝트의 기밀 이슈 내용이 적절한 권한 확인 없이 노출될 수 있었습니다. - GitLab CE/EE에 영향. - CVSS 6.5. ## 공개되지 않은 추가 수정 사항 - 글 마지막에는 **CVE-2026-8280 — direct transfer CSV 파서의 DoS 취약점**이 언급되지만, 제공된 본문이 해당 항목 중간에서 끝나 구체적인 영향 버전과 CVSS 점수는 확인할 수 없습니다. 자체 관리형 GitLab 운영자는 먼저 현재 버전을 확인하고 18.9.7, 18.10.6, 18.11.3 중 지원되는 최신 버전으로 업그레이드하는 것이 가장 안전합니다. 특히 외부에 노출된 API, 검색·분석 대시보드, OAuth 토큰, 파일 업로드 기능을 사용하는 환경은 패치 전까지 접근 통제를 강화해야 합니다.

oauthgitlabjavascriptgraphql+3

cloudflare2026년 4월 30일

이제 에이전트가 Cloudflare 계정을 만들고 도메인을 구매하고 배포할 수 있습니다 (새 탭에서 열림)

이제 AI 에이전트는 사람이 직접 대시보드에 접속하거나 신용카드 정보를 입력할 필요 없이, 스스로 클라우드플레어 계정을 생성하고 도메인을 구매하여 서비스를 배포할 수 있게 되었습니다. 클라우드플레어는 스트라이프(Stripe)와의 협업을 통해 '스트라이프 프로젝트(Stripe Projects)' 내에서 작동하는 새로운 프로토콜을 도입했으며, 이를 통해 에이전트가 소프트웨어 개발을 넘어 프로덕션 환경 구축까지 원스톱으로 처리할 수 있는 환경을 마련했습니다. 사용자는 최초의 권한 승인과 이용 약관 동의 외에는 복잡한 설정 과정에 개입할 필요가 없어 서비스 배포의 마찰력이 획기적으로 줄어들었습니다. **에이전트의 완전 자동화된 배포 흐름** * 사용자가 스트라이프 CLI를 통해 프로젝트를 초기화하면, AI 에이전트는 사용자의 스트라이프 계정 정보를 바탕으로 클라우드플레어 계정을 자동 생성하거나 기존 계정을 연결합니다. * 에이전트는 API 토큰을 발급받고, 도메인을 등록하며, 코드를 즉시 프로덕션 환경에 배포하는 모든 과정을 스스로 수행합니다. * 이 모든 과정은 사람이 대시보드에 들어가 API 토큰을 복사하거나 결제 수단을 수동으로 등록하는 단계 없이 하나의 흐름으로 진행됩니다. **상호운용성을 위한 세 가지 핵심 구성 요소** * **발견(Discovery):** 에이전트는 REST API 형태의 카탈로그를 조회하여 클라우드플레어의 도메인 등록과 같은 사용 가능한 서비스를 스스로 파악하고 선택할 수 있습니다. * **인증(Authorization):** 스트라이프가 신원 제공자(Identity Provider) 역할을 수행하여 사용자를 증명하면, 클라우드플레어는 즉시 계정을 프로비저닝하고 보안이 유지되는 자격 증명을 에이전트에게 반환합니다. * **결제(Payment):** 에이전트에게 실제 카드 번호를 공유하지 않고 스트라이프의 결제 토큰을 사용하며, 기본적으로 월 100달러의 지출 한도를 설정하여 예기치 못한 비용 발생을 방지합니다. **플랫폼 확정성 및 스타트업 지원** * 이 프로토콜은 스트라이프뿐만 아니라 로그인된 사용자를 보유한 어떤 플랫폼이든 '오케스트레이터' 역할을 맡아 클라우드플레어와 통합할 수 있도록 설계되었습니다. * 클라우드플레어는 이번 협업을 기념하여 스트라이프 아틀라스(Stripe Atlas)를 통해 법인을 설립하는 신규 스타트업에게 10만 달러 상당의 클라우드플레어 크레딧을 제공합니다. * 이를 통해 개발자들은 인프라 설정이라는 번거로운 작업에서 벗어나 AI 에이전트와 함께 아이디어를 프로덕션 수준의 서비스로 더욱 빠르게 전환할 수 있습니다. 에이전트 중심의 개발 환경을 구축하려는 개발자나 플랫폼 운영자라면 클라우드플레어의 'Code Mode MCP 서버'와 'Agent Skills'를 활용해 보시기 바랍니다. 인프라 구축의 모든 단계가 API화되어 있으므로, 사용자의 개입을 최소화하면서도 안전하고 확장 가능한 배포 자동화 시스템을 구현할 수 있습니다.

oauthdatabase-designcloudflarestripe+4

line2026년 4월 30일

AI 시대에 인증 과제를 해결할 차세대 표준 후보, ID-JAG (새 탭에서 열림)

AI 에이전트가 다양한 기업용 서비스와 연동되는 과정에서 발생하는 인증 및 인가 복잡성을 해결하기 위해 **Identity Assertion JWT Authorization Grant(ID-JAG)**라는 새로운 표준안이 주목받고 있습니다. ID-JAG는 기존 SSO의 신뢰 모델을 API 접근 영역으로 확장하여, 기업 IdP가 중앙에서 권한 정책을 일원화해 관리하고 검증 가능한 JWT를 통해 안전하게 토큰을 교환하도록 돕습니다. 이를 통해 사용자 경험을 개선하고 보안 가시성을 확보함으로써, 복잡한 연동 구조가 AI 도입의 병목이 되지 않도록 하는 것이 핵심입니다. **ID-JAG의 개념과 기술적 배경** * SSO를 통해 확립된 IdP(Identity Provider)에 대한 신뢰를 앱 간 API 호출이나 에이전트 서비스 연동에 적용하는 방식입니다. * OAuth 2.0 Token Exchange(RFC 8693)와 JWT Profile for OAuth 2.0 Authorization Grants(RFC 7523)라는 기존의 두 표준 기술을 결합하여 작동합니다. * IdP가 서명한 검증 가능한 JWT를 일종의 '소개장'으로 발행하고, API 리소스 측 인가 서버가 이 소개장을 신뢰하여 최종 액세스 토큰을 발행하는 구조입니다. **핵심 구성 요소와 작동 흐름** * **주요 주체:** 요청 에이전트(AI 등), 기업 IdP(중앙 정책 보유), 인가 서버(대상 앱의 서버), 리소스 서버(실제 API)의 네 가지 역할로 구분됩니다. * **작동 프로세스:** 사용자가 에이전트에 로그인하여 ID 토큰 획득 → IdP에 토큰 교환을 요청하여 ID-JAG 발급 → 인가 서버에 ID-JAG를 제시하고 최종 액세스 토큰 획득 → 리소스 서버 API 호출 순으로 진행됩니다. * **권한 판단의 주체 변화:** 개별 서비스 간의 파편화된 관계 대신, 조직 전체를 관리하는 기업 IdP와 인가 서버 간의 신뢰 관계로 허가 판단 시점이 이동합니다. **조직의 운영 및 보안 측면의 이점** * **사용자 경험(UX) 개선:** 새로운 도구를 연동할 때마다 나타나는 권한 동의 화면(Consent Screen) 절차를 IdP 관리자 정책에 통합하여 사용자의 번거로움을 줄입니다. * **보안 가시성 확보:** 모든 서비스 연결 관계가 IdP로 집중되므로, 누가 어떤 에이전트를 통해 어떤 데이터에 접근했는지 중앙 로그를 통해 명확하게 감사(Audit)할 수 있습니다. * **중앙 집중형 리스크 통제:** 승인되지 않은 '섀도우 AI'의 접근을 차단하고, 보안 사고 발생 시 개별 엔드포인트를 수정할 필요 없이 IdP 단에서 즉각적으로 권한을 제어할 수 있습니다. * **토큰 스프롤(Sprawl) 방지:** 장기 유효한 API 키나 리프레시 토큰 대신 동적으로 발행되는 ID-JAG를 사용하여 시스템 곳곳에 흩어진 인증 정보 노출 리스크를 낮춥니다. **도입 시 고려 사항 및 실용적 제언** * **표준화 상태 유의:** 현재 IETF 드래프트 단계이며 RFC로 최종 확정된 사양이 아니므로, 향후 변경 가능성을 염두에 둔 유연한 아키텍처 설계가 필요합니다. * **사전 신뢰 관계 구축:** 요청 에이전트가 IdP와 인가 서버 모두에 OAuth 클라이언트로 등록되어야 하며, 각 주체 간의 명시적인 신뢰 설정이 선행되어야 합니다. * **결론:** AI 에이전트 도입으로 인해 파편화된 권한 관리에 어려움을 겪는 기업이라면, ID-JAG를 통해 인가 정책을 중앙화하고 보안 표준을 프로토콜 기반의 동적 신뢰 구조로 전환하는 전략적 검토가 권장됩니다.

oauthdatabase-designjwtidentity-provider+4

stripe2026년 4월 29일

에이전트에게 결제 능력을 부여하기 (새 탭에서 열림)

Stripe은 AI 에이전트가 인터넷 경제의 능동적인 주체로 참여할 수 있도록 '에이전트용 Link 지갑(Link’s wallet for agents)'과 '에이전트용 Stripe Issuing'을 출시했습니다. 이 서비스는 에이전트에게 일회용 가상 카드나 공유 결제 토큰(SPT)을 발급하여 기존 결제 시스템에서 안전하게 구매를 수행할 수 있게 하며, 사용자는 앱을 통해 결제 요청을 검토하고 승인할 수 있는 통제권을 갖습니다. 결과적으로 복잡한 결제 인프라를 직접 구축할 필요 없이 AI 에이전트가 실질적인 상거래를 수행할 수 있는 기반을 마련해 줍니다. ### 에이전트용 Link 지갑의 작동 방식 * **보안 결제 수단 제공**: 에이전트는 사용자의 실제 카드 정보를 직접 보지 못하며, 대신 일회용 가상 카드나 SPT(Shared Payment Token)를 할당받아 결제를 진행합니다. * **OAuth 기반 권한 부여**: 사용자는 표준 OAuth 흐름을 통해 자신의 Link 지갑에 대한 접근 권한을 에이전트에게 부여할 수 있습니다. * **실시간 승인 프로세스**: 에이전트가 결제 요청을 생성하면 사용자는 Link의 웹 또는 모바일 앱(iOS/Android)에서 알림을 받고, 금액, 통화, 가맹점 등의 정보를 확인한 후 최종 승인합니다. * **다양한 결제 수단 추상화**: 현재 카드와 SPT를 지원하며, 향후 스테이블코인 및 기계 전용 결제 프로토콜 등으로 지원 범위를 확대할 예정입니다. ### 에이전트용 Stripe Issuing을 통한 맞춤형 인프라 * **API 기반 커스터마이징**: 독자적인 에이전트 지갑이나 카드 서비스를 구축하려는 기업은 Stripe Issuing API를 통해 온보딩, 자금 흐름, 지출 한도 등을 직접 설계할 수 있습니다. * **정교한 지출 제어**: 카드 수준의 권한 설정, 트랜잭션 승인 시점의 사기 방지 제어, 실시간 카드 활동 모니터링 기능을 제공합니다. * **자금 관리 최적화**: 가상 카드 발급부터 자금 보관, 지출 모니터링까지 에이전트 금융 워크플로우에 필요한 모든 하부 구조를 지원합니다. ### 주요 활용 사례 및 비즈니스 확장성 * **비즈니스 자동화**: 개발자는 에이전트를 활용해 기업의 반복적인 지출이나 프로그램 방식의 구매 워크플로우를 자동화할 수 있습니다. * **핀테크 및 SaaS**: 핀테크 제공업체는 실시간 지출 관리 시스템에 에이전트 발행 카드를 내장할 수 있으며, 수직형 SaaS 플랫폼은 중소상공인(SMB) 고객에게 자사 브랜드의 에이전트 결제 기능을 제공할 수 있습니다. * **마켓플레이스 효율화**: 판매자가 물류, 공급업체 결제, 주문 이행 등을 에이전트를 통해 자동 처리하도록 지원하여 운영 효율을 높일 수 있습니다. 개인 비서나 쇼핑 에이전트와 같은 소비자 지향 AI 서비스를 개발하는 기업이라면, 직접 복잡한 지갑 인프라를 구축하기보다 2억 명 이상의 사용자를 보유한 Link 지갑 기능을 도입하는 것이 효율적입니다. 보다 세밀한 금융 로직과 브랜드 경험이 필요한 경우에는 Stripe Issuing API를 활용하여 독자적인 에이전트 결제 생태계를 구축하는 것을 권장합니다.

oauthdatabase-designstablecoinslink-wallet+3

line2026년 4월 21일

ODW #3: MCP 서버를 안전하게 활용해 개발 효율 높이기 (새 탭에서 열림)

LY Corporation은 Model Context Protocol(MCP)을 활용해 AI 어시스턴트와 사내외 도구를 표준화된 방식으로 연결함으로써 개발 프로세스의 효율성을 극대화하고 있습니다. 보안 리스크를 체계적으로 관리하는 동시에 워크숍을 통한 조직적 학습을 병행하여, 엔지니어들이 안전하게 AI 에이전트를 확장하고 업무 자동화를 실현할 수 있는 환경을 구축하고 있습니다. **MCP의 개념과 표준화의 이점** * MCP는 AI 어시스턴트와 외부 시스템 사이에서 '번역자' 역할을 수행하는 공통 통신 규격으로, 각 서비스마다 별도의 인터페이스를 구현해야 했던 번거로움을 해결합니다. * 도구 개발자가 MCP라는 단일 인터페이스만 구현하면, 이를 지원하는 다양한 AI 어시스턴트(Claude, Cline 등)에서 동일한 방식으로 기능을 호출할 수 있어 호환성과 확장성이 비약적으로 향상됩니다. **보안 리스크 관리와 사내 거버넌스 구축** * 외부 MCP 서버의 약 53%가 정적 API 키나 PAT에 의존하고 있다는 보안 취약점을 인지하고, OAuth 등 최신 인증 방식을 권장하며 철저한 보안 검증을 수행합니다. * 사내에서는 허용 목록(Allow-list) 제도를 운영하여 검증된 MCP 서버만 사용하도록 제한하며, 내부 업무 시스템 연동을 위해 사내 보안 요구사항을 충족하는 전용 MCP 서버를 직접 구축해 제공합니다. * 'Help LY MCP'와 같은 전용 지원 도구를 마련해 전 세계 그룹사 직원들이 복잡한 절차 없이 자사 조직에 AI를 적용할 수 있는지 검토할 수 있는 체계를 갖추었습니다. **AI 에이전트 기반의 실무 자동화 사례** * **Claude Code와 Jira 연동:** 워크숍 실습을 통해 Claude Code가 작업 내용을 요약하고 사내 그룹웨어 MCP를 통해 Jira 티켓을 자동으로 발행하는 과정을 구현하여 반복적인 관리 업무를 자동화했습니다. * **멀티 에이전트 코드 리뷰:** Claude 3.5 Sonnet이 코드의 문맥과 로직을 1차로 리뷰하면, Codex MCP를 통해 연결된 다른 모델(GPT-5 등)이 리뷰의 타당성을 검증하는 2단계 리뷰 프로세스를 구축하여 객관성을 높였습니다. **조직적 학습과 공유의 가치** * 기술 변화 속도가 매우 빠른 AI 분야에서는 개인의 학습에만 의존하지 않고, '워크숍'이라는 형식을 통해 조직 전체의 배경지식과 위험 인식을 동기화하는 것이 중요합니다. * '무엇이 가능한가', '어떤 함정이 있는가', '어떻게 활용해야 가치가 생기는가'라는 세 가지 관점을 팀 전체가 공유함으로써 실질적인 업무 개선으로 이어지는 추진력을 얻을 수 있습니다. AI 기술은 정답이 정해지지 않은 채 매우 빠르게 발전하고 있으므로, 완벽한 모범 사례를 기다리기보다 호기심을 바탕으로 작은 시도를 꾸준히 쌓아가는 자세가 중요합니다. MCP 서버와 같은 최신 프로토콜을 적극적으로 탐구하고 팀 내에 공유하는 문화를 조성하는 것이 다가오는 AI 시대의 핵심 경쟁력이 될 것입니다.

oauthdatabase-designgithubclaude-code+4

cloudflare2026년 4월 20일

에이전트형 클라우드 구축: Agents Week 2026에서 출시한 모든 것 (새 탭에서 열림)

Cloudflare는 인공지능 에이전트가 주요 워크로드로 자리 잡는 미래를 위해 기존의 클라우드 구조를 재정의한 'Cloud 2.0(에이전트 클라우드)' 비전을 제시했습니다. 수천만 개의 에이전트 세션이 동시에 실행될 수 있도록 연산 인프라부터 보안, 도구 모음까지 스택 전반에 걸친 대대적인 신규 기능들을 공개했습니다. 이를 통해 개발자들은 단순한 프로토타입을 넘어 확장성과 보안을 갖춘 에이전트 기반 애플리케이션을 생산 환경에서 구현할 수 있게 되었습니다. **에이전트 전용 연산 환경 및 워크플로우** * **Git 호환 저장소 'Artifacts':** 에이전트가 생성한 코드와 데이터를 관리하기 위해 수천만 개의 레포지토리를 생성할 수 있고, 표준 Git 클라이언트와 연동되는 버전 관리 저장소를 제공합니다. * **격리된 실행 환경 'Sandboxes' (GA):** 에이전트에게 셸, 파일 시스템, 백그라운드 프로세스를 갖춘 독립된 컴퓨터 환경을 제공하며, 작업 중단 지점부터 즉시 재개할 수 있는 영속성을 보장합니다. * **상태 저장 및 확장성:** 'Durable Object Facets'를 통해 에이전트가 생성한 앱마다 독립된 SQLite 데이터베이스를 할당하며, 개선된 워크플로우 엔진으로 최대 50,000개의 동시 실행을 지원합니다. **에이전트를 위한 보안 및 ID 관리** * **Cloudflare Mesh:** 에이전트가 프라이빗 네트워크 내의 데이터베이스나 API에 안전하게 접근할 수 있도록 제로 트러스트 기반의 비공개 네트워크 연결을 지원합니다. * **Managed OAuth:** 에이전트가 보안상 취약한 서비스 계정 대신, 사용자를 대행해 내부 애플리케이션에 안전하게 인증하고 탐색할 수 있는 체계를 구축했습니다. * **비인간 식별자(Non-human Identity) 보호:** 에이전트용 API 토큰의 권한 범위를 세밀하게 제어하고 자동 취소 기능을 도입하여 자격 증명 유출에 따른 리스크를 최소화했습니다. **에이전트의 사고와 소통을 돕는 툴박스** * **다중 채널 소통 지원:** 실시간 음성 상호작용(STT/TTS) 기능을 약 30줄의 코드로 구현할 수 있게 되었으며, 이메일을 직접 송수신하고 처리할 수 있는 'Cloudflare Email Service' 베타를 출시했습니다. * **추론 성능 및 효율 최적화:** LLM의 품질 저하 없이 모델 크기를 22% 압축하는 'Unweight' 기술을 도입하여 더 빠르고 경제적인 추론 인프라를 구축했습니다. * **통합 추론 및 기억:** 14개 이상의 모델 공급자를 연결하는 통합 추론 레이어와 함께, 에이전트가 과거의 맥락을 기억하고 지속적으로 학습할 수 있는 'Agent Memory' 서비스를 제공합니다. 이번 발표는 에이전트가 단순히 텍스트를 생성하는 도구를 넘어, 독립적인 실행 환경과 보안 권한을 가지고 업무를 수행하는 '실행 주체'로 거듭나도록 돕는 데 초점이 맞춰져 있습니다. 대규모 에이전트 시스템을 구축하려는 팀이라면 Cloudflare가 제공하는 Sandboxes와 Mesh 기반의 보안 아키텍처를 활용하여 인프라 구축 비용과 보안 리스크를 획기적으로 낮출 수 있을 것입니다.

oauthcloudflareserverlessgit+4

cloudflare2026년 4월 17일

Agent Readiness 점수를 소개합니다. 내 사이트가 에이전트 대응 준비가 되었는지 확인해 보세요. (새 탭에서 열림)

웹 환경이 브라우저와 검색 엔진을 넘어 AI 에이전트 중심으로 진화함에 따라, 사이트가 AI 모델에 얼마나 최적화되어 있는지를 평가하는 새로운 기준이 필요해졌습니다. Cloudflare는 웹사이트의 AI 에이전트 대응 수준을 측정하고 개선 가이드를 제공하는 도구인 'isitagentready.com'과 관련 데이터셋을 공개했습니다. 이를 통해 사이트 소유자는 에이전트 전용 콘텐츠 제공 및 권한 제어 표준을 도입함으로써 AI 도구가 더 빠르고 저렴하게 정보를 처리할 수 있도록 최적화할 수 있습니다. **웹 사이트의 AI 에이전트 표준 도입 현황** * 전 세계 상위 20만 개 도메인을 분석한 결과, 대다수의 사이트가 여전히 전통적인 검색 엔진 크롤러 방식에 머물러 있어 에이전트 준비도가 낮은 것으로 나타났습니다. * `robots.txt`는 78%의 사이트가 보유하고 있으나, AI 에이전트 전용 규칙이나 AI 사용 선호도(Content Signals)를 명시한 곳은 4%에 불과합니다. * 에이전트가 HTML 대신 효율적인 마크다운 형식을 요청하는 '마크다운 콘텐츠 협상(Markdown content negotiation)' 도입률은 3.9% 수준입니다. * MCP(Model Context Protocol) 서버 카드나 API 카탈로그(RFC 9727)와 같은 최신 에이전트 상호작용 표준은 현재 도입 초기 단계로, 이를 선제적으로 도입하면 AI 에이전트 생태계에서 두각을 나타낼 수 있습니다. **에이전트 준비도 점수 측정 항목** * **발견 가능성(Discoverability):** `robots.txt`와 `sitemap.xml`은 물론, 에이전트가 HTML을 파싱하지 않고도 리소스를 즉시 찾을 수 있도록 HTTP 응답 헤더의 `Link` 헤더(RFC 8288) 활용 여부를 평가합니다. * **콘텐츠 접근성(Content Accessibility):** LLM이 읽기 쉬운 구조로 사이트 맵을 제공하는 `llms.txt`와 텍스트 기반의 마크다운 제공 여부를 확인합니다. 마크다운은 HTML 대비 토큰 사용량을 최대 80%까지 줄여 비용 절감과 응답 속도 향상에 기여합니다. * **봇 제어 및 권한(Bot Access Control):** AI 봇 전용 접근 규칙과 웹 봇 인증 방식이 올바르게 설정되어 있는지 체크합니다. * **에이전트 역량(Capabilities):** API 카탈로그, OAuth 서버 검색(RFC 8414), MCP 서버 카드 등 에이전트가 사이트의 기능을 직접 수행하는 데 필요한 기술 표준 준수 여부를 측정합니다. **실무적인 최적화 지원 및 도구 활용** * `isitagentready.com`은 구글 라이트하우스(Lighthouse)처럼 동작하며, 진단 결과에서 통과하지 못한 항목에 대해 코딩 에이전트에게 바로 입력할 수 있는 구현용 프롬프트를 제공합니다. * 이 도구 자체도 MCP 서버를 노출하고 있어, 사용자는 웹 인터페이스 없이도 에이전트를 통해 프로그래밍 방식으로 사이트 스캔을 수행할 수 있습니다. * Cloudflare는 자사 개발자 문서를 에이전트 친화적으로 개편하여 AI 도구가 문서를 참조할 때 발생하는 비용을 대폭 절감하고 답변의 정확도를 높이는 사례를 직접 증명하고 있습니다. 웹 사이트 운영자는 `isitagentready.com`을 통해 현재 사이트의 상태를 점검하고, 특히 토큰 비용 효율성이 높은 **마크다운 콘텐츠 협상**과 **API 카탈로그** 표준을 우선적으로 도입하는 것을 권장합니다. 이는 AI 에이전트가 사이트 정보를 더 정확하게 이해하고 사용자에게 전달하도록 만드는 가장 효과적인 방법입니다.

oauthdatabase-designai-agentcloudflare+4

gitlab2026년 4월 15일

GitLab 19.0의 중대 변경 사항 가이드 (새 탭에서 열림)

GitLab 19.0은 이전 메이저 업데이트 대비 파괴적 변경 사항(Breaking Changes)의 수를 대폭 줄여 안정성을 높이는 한편, 최신 보안 표준과 현대적인 인프라 기술로의 전환을 가속화합니다. 이번 릴리스는 NGINX Ingress의 대체, PostgreSQL 최소 요구 버전 상향, 보안상 취약한 인증 방식 제거 등 시스템 운영의 핵심적인 변화를 포함하고 있어 사용자들의 철저한 사전 준비가 필요합니다. 각 배포 유형에 따라 2026년 5월부터 순차적으로 적용될 예정이므로, 운영 환경의 호환성을 미리 점검하고 마이그레이션을 계획해야 합니다. ### 배포 유형별 업데이트 일정 * **GitLab.com (SaaS):** 2026년 5월 4일~6일 사이에 주요 변경 사항이 적용되며, 5월 11일~13일이 예비 기간으로 설정되었습니다. * **Self-Managed:** 2026년 5월 21일부터 공식적으로 19.0 버전을 사용할 수 있습니다. * **GitLab Dedicated:** 배포판 관리 정책에 따라 2026년 6월 22일 주간의 유지보수 창 내에 업데이트가 진행됩니다. ### 인프라 및 네트워킹 구성의 변화 * **Gateway API 및 Envoy 전환:** NGINX Ingress가 2026년 3월 종료됨에 따라, GitLab Helm 차트의 기본 네트워킹 구성이 Envoy Gateway 기반의 Gateway API로 변경됩니다. 기존 NGINX 사용자는 20.0 버전 전까지 수동으로 활성화하여 유지할 수 있으나 조속한 마이그레이션이 권장됩니다. * **내장형 컴포넌트 제거:** 테스트 및 PoC 용도로 제공되던 Helm 차트 내 번들 PostgreSQL, Redis, MinIO가 라이선스 및 유지보수 이슈로 인해 완전히 제거됩니다. 해당 서비스를 사용하는 환경은 반드시 외부 서비스로 전환해야 합니다. * **OS 지원 종료:** Ubuntu 20.04의 표준 지원 종료에 맞춰 해당 OS용 리눅스 패키지 제공이 중단됩니다. 19.0 업그레이드 전 Ubuntu 22.04 이상의 지원 버전으로 OS를 교체해야 합니다. ### 데이터베이스 및 미들웨어 요구사항 강화 * **PostgreSQL 17 필수화:** PostgreSQL 16 지원이 중단되고 17 버전이 최소 요구 사항이 됩니다. 리눅스 패키지 사용자는 18.11 버전에서 자동 업그레이드가 시도될 수 있으며, 클러스터 사용자는 수동 업그레이드가 필수입니다. * **Redis 및 Valkey 지원:** Redis 6 지원이 종료됩니다. 외부 Redis 운영 환경은 Redis 7.2 또는 새롭게 지원되는 Valkey 7.2로 마이그레이션해야 합니다. (AWS, GCP 등 클라우드 매니지드 서비스 포함) ### 보안 및 빌드 환경 업데이트 * **ROPC OAuth 흐름 제거:** 보안상 결함이 있는 리소스 소유자 비밀번호 자격 증명(ROPC) 방식이 OAuth 2.1 표준에 따라 완전히 제거됩니다. 이를 사용하는 앱이나 통합 서비스는 Authorization Code flow 등 보안이 강화된 방식으로 수정해야 합니다. * **Auto DevOps 빌더 업데이트:** 클라우드 네이티브 빌드팩(CNB) 이미지가 heroku/builder:22에서 24 버전으로 업데이트됩니다. 이를 통해 최신 런타임 환경을 지원하며 관련 파이프라인의 빌드 방식이 변경될 수 있습니다. 성공적인 GitLab 19.0 전환을 위해 Self-Managed 운영자는 18.x 버전대에서 제공되는 PostgreSQL 17 마이그레이션 도구를 미리 활용하고, Helm 차트 사용자는 Gateway API로의 네트워크 인프라 전환 계획을 우선적으로 수립할 것을 권장합니다.

oauthdatabase-designgitlabpostgresql+4