cloudflare2026년 8월 4일

Cloudflare가 AI를 활용해 엔지니어링 표준을 시행하는 방법 (새 탭에서 열림)

Cloudflare는 흩어져 있던 엔지니어링 지침을 통합·관리하는 표준 저장소인 **Cloudflare Codex**를 구축했다. Codex는 RFC 형식의 표준을 사람과 AI 에이전트가 작업 시점에 검색하고 적용할 수 있게 하며, 코드 리뷰·기술 설계 검토·사고 보고서 검토 등에 공통으로 활용된다. 도입 후 AI 코드 리뷰어는 약 23만 건의 위반을 발견했고, 그중 약 1만 6천 건의 병합을 차단했다. ## Codex가 필요했던 이유 - Cloudflare의 기존 지침은 공식 문서, 저장소 파일, 채팅 기록, 개인의 경험 등 여러 위치에 분산돼 있었다. - 개발자는 문제 해결보다 관련 지침을 찾는 데 많은 시간을 써야 했다. - 지침을 찾더라도 최신 정보인지, 권위 있는 기준인지, 현재 상황에 적용 가능한지 판단하기 어려웠다. - 조직이 커지면서 모든 표준을 읽고 모든 요구사항을 검토하는 것이 불가능해졌다. - 팀 이동이나 인력 변화로 조직의 지식이 유실되기 쉬웠고, 지침이 일관되게 노출·강제되지 않아 프로젝트 간 품질 편차가 발생했다. ## 도메인과 RFC 기반 거버넌스 - Codex는 아키텍처, 프런트엔드, 컨트롤 플레인, 보안, 신뢰성, TypeScript, Rust 등 여러 도메인으로 나뉜다. - 각 도메인에는 담당자가 있어 문서의 내용·일관성·품질을 관리한다. - 표준은 RFC 2119의 의미에 따라 `SHOULD`와 `MUST` 키워드를 사용한다. - `SHOULD`: 특별한 이유가 없다면 따라야 하는 권고 - `MUST`: 반드시 지켜야 하는 필수 요구사항 - RFC에는 도메인과 상태 같은 메타데이터를 담은 front matter가 포함된다. - 도메인 역량과 관심이 있는 직원은 정해진 형식의 merge request로 RFC를 제안할 수 있다. - 제안서는 점점 더 넓은 범위의 리뷰를 거치며, 도메인 담당자가 최종 승인하면 Codex에 편입되고 Astro 기반 내부 사이트에 게시된다. ## 승인과 강제를 분리한 표준 수명주기 - 승인된 RFC는 Codex 클라이언트와 에이전트가 즉시 읽고 코드·설정·문서의 위반을 탐지하는 데 사용할 수 있다. - 다만 승인 직후부터 병합을 차단하지는 않는다. - RFC가 `approved`에서 `enforced` 상태로 승격된 뒤에야 관련 요구사항이 차단 근거가 된다. - 이 단계 분리를 통해 팀이 새로운 요구사항을 받아들일 시간을 확보하고, 자동화나 예외 처리 등 강제에 필요한 준비도 마칠 수 있다. - 승인된 RFC의 위반은 일반적으로 비차단 권고로 처리되며, 강제 상태 RFC의 `MUST` 위반은 심각도에 따라 승인 보류 또는 병합 차단으로 이어진다. ## LLM을 위한 구조화와 점진적 공개 - 60개가 넘는 RFC 전체를 매번 LLM에 제공하면 컨텍스트 윈도우 부담이 커지고 결과 품질이 떨어질 수 있다. - 이를 해결하기 위해 별도의 에이전트가 RFC에서 `SHOULD`와 `MUST` 문장을 추출해 JSON 구조로 압축한다. - 각 표준 문장에는 다음 정보가 포함된다. - RFC 번호와 제목 - RFC 상태와 도메인 - 적용 수준(`SHOULD` 또는 `MUST`) - 문장이 속한 섹션 - 원문으로 연결되는 링크 - 안정적인 `slug` 식별자 - 에이전트는 우선 관련 표준 문장만 검색하고, 추가 설명이 필요할 때만 RFC 전체 내용을 불러온다. - 안정적인 slug는 RFC가 수정돼도 같은 요구사항을 추적할 수 있게 해 모니터링, 분석, 예외 처리에 활용된다. - 초기에는 간결한 Markdown을 사용했지만, 더 정확한 필터링을 위해 구조화된 JSON으로 전환했다. - 향후에는 설계·구현·런타임 등 소프트웨어 개발 생명주기 단계별 적용 범위도 메타데이터에 포함할 계획이다. ## AI 코드 리뷰 적용 - AI 코드 리뷰어는 merge request를 여러 기준으로 검사하며 Codex 준수 여부도 평가한다. - 리뷰마다 관련 RFC와 추출된 표준 문장을 검색하고, 필요한 경우에만 RFC 본문을 추가로 읽는다. - 대부분의 위반은 압축된 표준 문장만으로도 문제와 근거를 설명할 수 있다. - Codex 도입 이후 약 23만 건의 위반을 발견했다. - 이 중 약 1만 6천 건은 강제 상태 RFC의 `MUST` 요구사항 위반으로 승인 보류를 발생시켰다. ## AI 리뷰를 보완하는 빠른 린터 - AI 리뷰는 코디네이터와 여러 하위 에이전트를 실행하므로 보통 수 분이 걸린다. - 수정 후 다시 리뷰를 받아야 하는 추가 왕복과 대기 시간이 개발자 경험을 저하시킬 수 있다. - Cloudflare는 기계적으로 검증 가능한 언어별 요구사항을 별도 린터 설정 패키지로 제공하는 방식을 마련했다. - 이 린터는 Codex 표준과 정렬되며 문제를 밀리초 단위로 표시할 수 있다. - TypeScript가 첫 번째 대상 언어였고, 동시에 `oxlint`를 표준화하는 방향으로 진행됐다. ## 여러 엔지니어링 단계로의 확장 - Codex는 코드 리뷰에만 한정되지 않는다. - 기술 설계가 구현되기 전에 표준을 검토하는 spec reviewer가 이미 약 600개의 설계를 평가했다. - incident report reviewer 등 사고 분석과 운영 프로세스에도 같은 기준을 적용할 수 있다. - 하나의 관리된 표준 원천을 여러 에이전트가 공유함으로써 설계부터 구현, 운영까지 일관된 엔지니어링 기준을 적용할 수 있다. 새로운 표준은 먼저 `approved` 상태로 도입해 팀의 적응과 자동화 준비 시간을 확보한 뒤, 충분히 검증되면 `enforced`로 승격하는 방식이 실용적이다. 또한 LLM에는 전체 문서를 무작정 제공하기보다, 안정적인 식별자와 메타데이터를 갖춘 핵심 규칙을 먼저 검색하게 하고 필요할 때만 원문을 공개하는 구조가 효과적이다.

openapillmtypescriptrust+4

toss2026년 7월 30일

토스의 디바이스 팜 만들기 (새 탭에서 열림)

네뷸라는 팀별로 흩어져 운영하던 실기기 테스트 환경을 중앙 플랫폼으로 통합해, 누구나 API 호출 한 번으로 실제 스마트폰을 제어할 수 있도록 만든 사내 디바이스 팜입니다. Appium 대신 자체 드라이버를 개발해 속도와 확장성을 높였고, 실시간 미러링·보안·24시간 운영 안정성까지 직접 구축했습니다. 그 결과 15대에서 시작한 팜은 100대를 넘어 수백 대 규모로 확장되며 전사 공용 테스트 인프라로 자리 잡았습니다. ## 팀별 디바이스 팜의 한계 - 각 팀이 맥북이나 맥미니에 5~10대의 기기를 직접 연결하고 관리했습니다. - Appium 설정, 기기 인식, OS 버전 대응, 연결 장애 복구를 팀마다 반복해야 했습니다. - 기기 관리와 테스트, 보안·컴플라이언스까지 개발자가 함께 맡아야 했습니다. - 팀별 자원이 격리되어 회사 전체의 기기를 효율적으로 공유하기 어려웠습니다. - 네뷸라는 이러한 운영 부담을 중앙화하고 전문 플랫폼으로 이전하기 위해 시작됐습니다. - 맥미니 5대와 기기 15대, 개발자 1명으로 시작해 1년간 100대 이상으로 성장했습니다. ## API 한 번으로 실기기 제어 - 사용자는 기기가 어느 호스트에 연결됐는지, ADB나 Xcode를 어떻게 설정했는지 알 필요가 없습니다. - `occupy` API로 조건에 맞는 기기를 점유한 뒤 액션 API를 호출하면 됩니다. - 예를 들어 다음과 같은 흐름으로 기기를 사용할 수 있습니다. - Android 기기 점유 - 좌표 `(540, 1200)` 클릭 - 테스트 종료 후 기기 반환 - 예약, 케이블 연결, 로컬 환경 설정을 숨기고 단순한 인터페이스를 제공하는 것이 네뷸라의 핵심 가치입니다. ## 네뷸라의 4계층 아키텍처 - **클라이언트** - 웹 프런트엔드, SDK·CLI, 직접 API 호출 등 다양한 접근 방식을 제공합니다. - **서버** - 기기 발견·점유·할당·테스트 실행을 관리하는 오케스트레이션 계층입니다. - 테스트 요청은 Kafka로 전달되고 여러 Runner가 분산 처리합니다. - `occupy · assign · release` 기반 분산 락으로 한 기기를 여러 테스트가 동시에 사용하는 문제를 방지합니다. - **에이전트** - iOS용 Mac mini와 Android용 Linux 호스트에서 실행됩니다. - ADB·Xcode로 연결된 기기를 자동 발견하고 서버 요청을 로컬 기기로 전달합니다. - **기기 계층** - 기기마다 controller server와 controller runner가 동작합니다. - 실제 화면 클릭, 텍스트 입력 등의 동작은 이 계층에서 수행됩니다. ## Appium 대신 개발한 Nebula Driver ### 빠른 명령 처리 - Appium과 Android 기기에서 명령 지연을 비교한 결과, 클릭·입력 작업에서 네뷸라가 10배 이상 빠른 경우가 있었습니다. - Appium은 동작 전 화면이 안정될 때까지 기다리는 `waitForIdle`을 사용해 견고성을 높입니다. - 네뷸라는 화면이 진행 중이어도 노드에 바로 명령을 전달하고 즉시 반환하는 속도 우선 방식을 택했습니다. - `waitForIdle`을 끄면 성능 격차가 2~3배 수준으로 줄어들지만, 실시간 조작이 중요한 네뷸라에는 속도 중심 설계가 적합했습니다. ### Stateless 구조 - Appium은 세션 기반이라 세션 생성에 약 15~40초가 걸릴 수 있습니다. - 기기 수가 늘수록 세션 생성 실패와 세션 관리 비용도 증가합니다. - 네뷸라는 기기 컨트롤러를 미리 실행해 두고, 상태 없는 HTTP 호출을 받는 구조를 사용합니다. - 세션 시작 비용과 세션 장애를 줄이고, 대규모 기기 운영에 유리한 구조를 만들었습니다. ### 사내 환경에 맞춘 확장 - 자체 인터페이스를 소유하므로 필요한 기능을 직접 추가할 수 있습니다. - 한글·이모지 입력을 지원하는 자체 IME를 구현했습니다. - 토스 앱 전용 신호 트리거를 추가할 수 있습니다. - 사내 앱센터와 연동해 pre-release 빌드를 기기에 바로 설치할 수 있습니다. - 보안 정책도 드라이버 규격 안에서 강제할 수 있습니다. - Android는 ADB·UiAutomation, iOS는 Swift·XCTest를 기반으로 구현하고, OpenAPI 스펙으로 Go·TypeScript 코드를 자동 생성했습니다. ## 실시간 화면 미러링 - 네뷸라는 정해진 테스트 스텝만 실행하는 도구가 아니라, 사용자가 화면을 보면서 동시에 조작할 수 있어야 했습니다. - 따라서 실시간 조작과 실시간 영상 스트리밍을 Android·iOS 모두에서 해결해야 했습니다. ### Android 미러링 - scrcpy는 Android 화면을 데스크톱 앱에 보여주는 데 적합하지만, 서버를 거쳐 여러 브라우저에 배포하는 구조에는 맞지 않았습니다. - 네뷸라는 scrcpy의 인코딩 방식을 참고하되 자체 미러링 경로를 구현했습니다. - `SurfaceControl`로 가상 디스플레이를 만들고 `MediaCodec`으로 H.264 영상을 인코딩합니다. - 인코딩된 영상은 브로드캐스터를 통해 여러 브라우저 시청자에게 전달됩니다. ### iOS 미러링 - iOS는 Android처럼 화면을 자유롭게 추출하기 어렵고 USB 사용 방식에도 제약이 있습니다. - 기존 QVH·Appium MJPEG 방식은 화면을 보면서 동시에 조작하는 요구를 충족하지 못했습니다. - QuickTime Player의 iOS 화면 캡처 방식과 유사한 경로를 USB 독점 없이 내재화했습니다. - 그 결과 조작과 미러링을 동시에 수행할 수 있게 됐습니다. - Android와 iOS 모두 실시간 H.264·브로드캐스팅 경로로 통일해 브라우저에서 여러 기기를 한 번에 볼 수 있습니다. ## 중앙화로 강화한 보안과 컴플라이언스 - 팀별 운영에서는 개발자가 테스트와 기기 관리, 보안 준수를 모두 책임져야 했습니다. - 네뷸라 팀은 사내 보안팀과 협력해 모바일 기기 팜 운영 기준을 정의했습니다. - 중앙 플랫폼에 보안 정책을 적용해 모든 기기에 동일한 기준을 일괄 반영할 수 있게 했습니다. - 사용자는 보안 요건이 적용된 환경에서 테스트에만 집중할 수 있습니다. ## 24시간 운영을 위한 안정성 ### 하드웨어 운영 - USB 연결 안정성, 케이블·허브 선택, 전원 공급, 서버실 설계를 직접 검증했습니다. - 물리적 장애를 완전히 제거할 수 없기 때문에 사람의 대응 체계와 이중화를 함께 준비하고 있습니다. ### 소프트웨어 운영 - 호스트별 컨트롤러와 미러링 프로세스를 오케스트레이션합니다. - 프로세스가 종료되더라도 자동으로 복구되도록 설계했습니다. - 서버·에이전트·컨트롤러·미러링 구성요소에 무중단 배포를 적용했습니다. - 기기 상태, 프로세스 상태, 서버 성능을 함께 관측하는 모니터링 체계를 구축하고 있습니다. - 여러 팀이 상시 사용하는 공용 인프라이므로 안정성을 핵심 기능으로 취급합니다. ## API 위에 만들어진 테스트 생태계 - 기기 15대에서 100대 이상, 수백 대 규모로 확장 중이며 24시간 운영됩니다. - 웹페이지에서는 미러링 화면을 보며 클릭으로 테스트 스텝을 만들 수 있습니다. - SDK로 E2E 테스트 코드를 작성하고, CLI로 터미널·CI/CD·AI 에이전트에서 기기를 제어할 수 있습니다. - 제품 로그가 기대대로 기록되는지 검수하는 시스템에도 활용됩니다. - AI 에이전트가 API를 호출해 테스트 스텝을 직접 판단하고 실행할 수도 있습니다. - 하나의 공개 API를 기반으로 여러 도구와 활용 사례가 자연스럽게 확장됐습니다. - 사용자 사례에 따르면 Appium 기반 테스트를 이전한 뒤 실행 속도가 크게 향상됐고, 수동 검수 시간이 30~40분에서 10분 이내로 줄었습니다. 네뷸라의 사례는 기기 수를 늘리는 것보다, 복잡한 하드웨어와 운영 문제를 단순한 API 뒤로 숨기는 것이 중요하다는 점을 보여줍니다. 비슷한 플랫폼을 구축한다면 초기부터 기기 점유 모델, 실시간 미러링, 보안 정책, 자동 복구와 무중단 배포를 함께 설계하고, 내부 사용자가 쉽게 확장할 수 있는 단일 API를 중심에 두는 것이 좋습니다.

openapiandroidioskafka+4

line2026년 6월 25일

AI 시대의 개발 능력은 검증력으로 결정된다, Flava API Gateway 개발 중 배운 빠른 검증과 로컬 환경 구성 전략 (새 탭에서 열림)

코딩 에이전트는 빠르게 코드를 생성하지만, 설계 불명확성·출력 비결정성·검증 지연 때문에 신뢰할 수 없는 결과를 만들 수 있다. LY Corporation의 Flava API Gateway 팀은 이를 해결하기 위해 **스펙 주도 개발, 검증 자동화, 빠르고 독립적인 로컬 환경**을 구축했다. 결론적으로 AI의 생산성을 활용하려면 개발자의 전문성과 테스트·린터·사전 설계를 오히려 더 강화해야 한다. ## 코딩 에이전트가 만드는 개발 병목 - 에이전트의 코드 생성 속도에 비해 CI 대기, 환경 프로비저닝, 원격 테스트 같은 단계는 느리다. - 에이전트는 다음과 같은 오류를 반복적으로 만들 수 있다. - 컴파일되지 않는 코드 - 존재하지 않는 API 참조 - 명시되지 않은 설계 결정을 임의로 선택 - 동일한 프롬프트라도 실행마다 결과가 달라질 수 있어 출력의 일관성과 역량을 일반화하기 어렵다. - AI가 개발자의 리뷰 속도보다 빠르게 코드를 생성하면, 검토되지 않은 코드가 누적될 위험이 있다. - 따라서 AI 활용의 핵심은 단순한 생성 속도가 아니라, 잘못된 결과를 빠르게 발견하고 수정하는 개발 시스템이다. ## Flava API Gateway와 세 가지 대응책 - Flava API Gateway는 LY Corporation의 사내 프라이빗 클라우드 Flava에서 API를 생성·배포·모니터링하는 제품이다. - Kong이 데이터 플레인을 담당하고, 컨트롤 플레인은 각 팀이 독립적으로 API를 관리할 수 있는 다중 테넌트 REST API를 제공한다. - 팀은 다음 세 가지 원칙을 채택했다. - 코드 작성 전 설계와 요구사항을 확정하는 **스펙 주도 개발** - 테스트와 린터로 에이전트가 스스로 오류를 찾도록 하는 **검증 자동화** - CI를 기다리지 않고 전체 검증 루프를 돌리는 **빠른 로컬 환경** ## 스펙 주도 개발로 구현 방향 고정 - 에이전트가 설계가 정해지기 전에 구현을 시작하면, 에이전트가 임의로 설계 결정을 내리면서 비결정성이 커진다. - Flava 팀은 먼저 OpenAPI 스펙으로 컨트롤 플레인의 전체 설계를 정의했다. - OpenAPI 스펙은 다음 역할을 한다. - 에이전트가 따라야 할 명시적 기준 - 구현 결과가 설계에서 벗어났는지 판단하는 검증 기준 - API 동작 계약의 문서화 - 이후 기능을 작은 단위로 나누고 OpenSpec을 사용해 각 기능을 구현했다. ## Nickel을 활용한 OpenAPI 관리 - 원본 OpenAPI YAML은 반복적이고 장황해 수작업 유지보수가 어렵다. - 스펙과 실제 구현이 어긋나면 에이전트를 통제하는 기준으로서의 가치가 떨어진다. - 팀은 Nickel을 사용해 API 리소스를 선언적으로 정의하고, 이를 전체 CRUD 엔드포인트 스펙으로 변환했다. - 예를 들어 리소스 정의만으로 다음 요소를 일관되게 생성할 수 있다. - 목록·생성·조회·삭제 엔드포인트 - 페이지네이션과 정렬 - 정확히 일치하는 필터와 부분 문자열 필터 - ETag 기반 낙관적 잠금 - 공통 오류 응답 - 이 방식은 반복적인 YAML 작성량을 줄이고, API 설계 규칙을 생성기에 집중시킨다. ## OpenSpec 기반의 협업 워크플로 OpenSpec은 에이전트가 구현 전에 행동 계약에 합의하도록 다음 네 가지 산출물을 요구한다. - **제안(Proposal)**: 무엇을, 왜 변경하는지 설명 - **설계(Design)**: 기술적 결정과 트레이드오프 정리 - **델타 스펙(Delta Specs)**: 변경되는 요구사항을 Given-When-Then 시나리오로 정의 - **작업 목록(Task List)**: 구현 단계를 체크리스트로 분해 워크플로는 다음 순서로 진행된다. - 개발자와 에이전트가 기능, 세부사항, 에지 케이스를 함께 검토한다. - 에이전트가 네 가지 산출물을 작성한다. - 에이전트가 작업 목록을 단계적으로 실행하며 구현한다. - 완료 후 변경 사항을 아카이브하고 델타 스펙을 메인 스펙에 병합한다. - 축적된 델타 스펙은 시간이 지나면서 시스템 전체의 “살아 있는 스펙”이 된다. ## 검증 자동화로 에이전트의 오류 수정 유도 - 프롬프트에 주의사항을 계속 추가하는 방식은 효과가 제한적이며, 제약이 많아질수록 출력 품질이 낮아질 가능성도 있다. - 대신 테스트와 린터가 오류를 구체적으로 드러내도록 구성했다. - 에이전트는 다음과 같은 반복 루프를 수행한다. - 코드를 작성한다. - 테스트·린터·포매터를 실행한다. - 실패 원인을 확인한다. - 코드를 수정한다. - 다시 검증하고 다음 오류로 넘어간다. - 모든 요구사항을 처음부터 프롬프트에 주입하는 대신, 필요한 제약을 실패 시점에 점진적으로 제공하는 방식이다. - 프로젝트별 스킬에 테스트, 린터, 포매터를 묶고 `AGENTS.md`를 통해 언제 해당 스킬을 사용할지 안내했다. - 검사 지침을 매 턴마다 전달하지 않고 필요할 때만 로드해 에이전트의 불필요한 컨텍스트 부담도 줄였다. ## 세 계층 테스트와 완전한 로컬 검증 전체 테스트 모음은 2,754개이며 다음 세 계층으로 구성된다. - **단위 테스트** - 비즈니스 로직을 분리해 검증 - **통합 테스트** - 실제 PostgreSQL 사용 - 제약 조건, 트리거, 소프트 삭제 연쇄, 트랜잭션 검증 - 전체 인프로세스 HTTP 스택 검증 - 모든 응답의 OpenAPI 준수 여부 확인 - **E2E 테스트** - 실제 Athenz 인증 - Kong 데이터 플레인 - API 키 적용 - 멀티 테넌트 격리 - 전체 시스템 동작 검증 ## CI 의존성을 줄인 빠른 개발 환경 - 개발자가 직접 작성할 때는 CI 왕복을 줄이기 위해 어느 정도 완성된 코드를 먼저 제출할 수 있지만, 에이전트는 짧은 간격으로 수많은 시도를 반복한다. - 모든 시도를 원격 CI로 보내면 다음 문제가 생긴다. - 긴 대기 시간 - 반복 과정에서 에이전트가 컨텍스트를 잃을 가능성 - 원격 환경의 로그와 상태를 조사하기 어려움 - 완전한 로컬 환경을 구축하면 에이전트가 즉각적인 피드백을 받고 현재 작업 흐름을 유지할 수 있다. - 로컬 의존성의 로그와 상태를 직접 확인할 수 있어 실패 원인 분석도 쉬워진다. - 전체 테스트는 개발자 기기에서 약 15초 안에 실행되도록 최적화했다. - 이를 위해 테스트를 병렬화하고 테스트 간 격리를 강화했다. 공유 테이블을 매번 삭제하는 방식보다 각 테스트 패키지가 독립적으로 생성한 데이터를 사용해 실행 간 충돌을 줄이는 방향을 택했다. ## 실용적인 적용 권장사항 AI 코딩 에이전트를 도입할 때는 프롬프트를 복잡하게 만드는 것보다 먼저 API·행동 스펙을 문서화하고, 테스트·린터·포매터를 자동 실행하며, 핵심 검증을 로컬에서 빠르게 끝낼 수 있게 만드는 것이 효과적이다. 에이전트의 성능을 높이는 가장 현실적인 방법은 더 많은 일을 맡기는 것이 아니라, 실패를 즉시 알려 주고 스스로 수정할 수 있는 짧은 피드백 루프를 구축하는 것이다.

openapipostgresqlcoding-agentsautomated-testing+4

cloudflare2026년 3월 9일

능동적 방어: API를 (새 탭에서 열림)

Cloudflare는 기존 WAF의 수동적 방어를 넘어, API의 복잡한 로직 결함을 사전에 탐지하는 '상태 기반(Stateful) 웹 및 API 취약점 스캐너'를 출시했습니다. 이 서비스는 OWASP API Top 10 중 가장 치명적인 BOLA(객체 수준 권한 위반)를 우선적으로 겨냥하며, 유효한 요청으로 위장한 논리적 공격을 찾아내는 데 집중합니다. Cloudflare의 엣지 네트워크 지능과 기존 API Shield 기능을 결합하여, 트래픽이 부족한 개발 환경에서도 자동화된 보안 테스트가 가능해진 것이 핵심입니다. ### API 보안에서 논리적 결함과 BOLA의 위험성 * 기존 웹 취약점(SQL Injection, XSS 등)은 구문 오류의 형태를 띠어 탐지가 용이하지만, API 취약점은 정상적인 HTTP 요청 형식을 유지하면서 비즈니스 로직을 악용하는 경우가 많습니다. * BOLA(Broken Object Level Authorization)는 공격자가 유효한 본인의 인증 토큰을 사용하되, 요청 파라미터의 ID값만 타인의 것으로 교체하여 권한이 없는 데이터에 접근하는 방식입니다. * 이러한 공격은 인증과 스키마가 모두 적절해 보이기 때문에, 단순히 패턴을 매칭하는 전통적인 WAF나 봇 관리 도구로는 방어하기 매우 어렵습니다. ### 기존 DAST 및 수동적 보안의 한계 * 수동적 보안(Passive Scanning)은 실제 사용자 트래픽에 의존하므로, 트래픽이 없는 개발 단계나 새로운 환경에서는 취약점을 미리 발견할 수 없습니다. * 전통적인 DAST(동적 애플리케이션 보안 테스트) 도구는 구성이 복잡하고, 수동으로 OpenAPI 파일을 업데이트해야 하며, 현대적인 복잡한 로그인 흐름을 처리하는 데 한계가 있습니다. * 대부분의 기존 스캐너는 각 요청을 독립적으로 처리하는 '무상태(Stateless)' 방식이라, 여러 요청을 연결하여 로직을 검증해야 하는 BOLA 탐지에 부적합합니다. ### Cloudflare의 상태 기반(Stateful) 스캐닝 기술 * **상태 기반 테스트**: '소유자(Owner)' 계정으로 자원을 생성한 뒤 '공격자(Attacker)' 계정으로 해당 자원에 접근을 시도하는 등, 요청 간의 상관관계를 추적하는 체인형 테스트를 수행합니다. * **자동화된 스캔 플랜**: 제공된 OpenAPI 스키마를 분석하여 API 호출 그래프를 스스로 구축하고, 이를 기반으로 공격 시나리오를 자동 설계합니다. * **API Shield와의 통합**: 기존의 API Discovery 및 Schema Learning 데이터를 활용하므로, 사용자는 복잡한 설정 없이도 자신의 API 구조에 최적화된 스캔을 즉시 시작할 수 있습니다. * **능동적 검증**: 수동적인 트래픽 관찰에서 얻은 통찰을 바탕으로 실제 공격 요청을 생성하여 전송함으로써, 보안 위협이 실재하는지 능동적으로 입증합니다. BOLA와 같은 로직 결함은 코드 수준의 수정이 필수적이므로, API Shield 고객은 이번 베타 버전을 활용해 운영 환경뿐만 아니라 개발 단계에서부터 취약점을 선제적으로 식별하고 수정하는 '시프트 레프트(Shift-left)' 보안 전략을 구축할 것을 권장합니다.

openapicloudflareapi-securityvulnerability-scanning+3

cloudflare2026년 2월 20일

코드 모드: 1 (새 탭에서 열림)

Cloudflare에서 발표한 '코드 모드(Code Mode)'는 AI 에이전트가 방대한 API를 사용할 때 발생하는 컨텍스트 윈도우 낭비 문제를 해결하기 위한 혁신적인 접근 방식입니다. 개별 API 엔드포인트를 수천 개의 도구로 정의하는 대신, 에이전트가 직접 코드를 작성하고 실행하게 함으로써 단 1,000개의 토큰만으로 전체 Cloudflare API를 제어할 수 있게 합니다. 이 기술은 모델의 기억 공간을 보존하면서도 복잡한 연쇄 작업을 효율적으로 수행할 수 있는 높은 유연성을 제공합니다. ### 기존 MCP 방식의 한계와 코드 모드의 등장 * **컨텍스트 윈도우 포화 문제**: 모델 지시 프로토콜(MCP)에서 에이전트에게 너무 많은 도구를 제공하면 컨텍스트 윈도우가 가득 차서 실제 작업 수행에 필요한 공간이 부족해집니다. * **방대한 API의 비효율성**: Cloudflare API처럼 엔드포인트가 2,500개가 넘는 경우, 이를 모두 도구로 등록하려면 약 117만 개의 토큰이 필요하며 이는 최신 모델의 한계를 초과하는 수치입니다. * **코드 모드의 해결책**: 도구의 명세(Description)를 줄이는 대신, 에이전트가 SDK를 대상으로 코드를 작성하고 이를 안전한 샌드박스에서 실행하는 방식을 채택하여 토큰 사용량을 99.9% 절감했습니다. ### 핵심 인터페이스: search()와 execute() * **search() 도구**: 전체 OpenAPI 명세를 모델에 주입하는 대신, 모델이 자바스크립트 코드를 작성하여 명세 내에서 필요한 엔드포인트를 스스로 검색하게 합니다. 이를 통해 모델은 수천 개의 엔드포인트 중 당장 필요한 것만 식별할 수 있습니다. * **execute() 도구**: 에이전트가 실제 API 요청을 수행하는 자바스크립트 코드를 작성하여 실행합니다. 단순 호출뿐만 아니라 페이지네이션 처리, 응답 확인, 여러 작업을 하나로 묶는 체이닝(Chaining)이 가능합니다. * **고정된 토큰 비용**: API의 규모가 아무리 커져도 모델이 학습해야 할 도구는 이 두 가지뿐이므로, 약 1,000토큰의 고정된 비용만 발생합니다. ### 보안 및 실행 환경 (Dynamic Worker) * **V8 샌드박스 격리**: 에이전트가 작성한 코드는 파일 시스템 접근이나 환경 변수 유출이 불가능한 경량 V8 샌드박스인 'Dynamic Worker' 내부에서 실행됩니다. * **제한된 네트워크 접근**: 외부 호출(Fetch)은 기본적으로 비활성화되어 있으며, 필요에 따라 명시적으로 제어된 핸들러를 통해서만 외부와 통신할 수 있어 프롬프트 주입 공격으로부터 안전합니다. * **안전한 실행 흐름**: 모델이 직접 API 키를 다루지 않고 서버 측에서 정의된 안전한 환경에서 로직만 실행하므로 보안성이 높습니다. ### 실무 적용 사례: DDoS 방어 설정 * **엔드포인트 탐색**: 에이전트가 "DDoS 공격으로부터 내 사이트를 보호해줘"라는 요청을 받으면, `search()`를 통해 WAF 및 규칙 설정 관련 API 엔드포인트를 필터링합니다. * **복합 작업 수행**: 필터링된 엔드포인트 정보를 바탕으로 `execute()`를 호출하여 방화벽 규칙을 생성하고, 패키지를 업데이트하며, 설정을 확인하는 일련의 과정을 단 한 번의 도구 호출로 처리할 수 있습니다. 방대한 API를 다루는 서비스를 운영 중이라면 Cloudflare가 오픈소스로 공개한 **Code Mode SDK**를 활용해 보시기 바랍니다. 이를 통해 에이전트의 응답 속도를 높이고 운영 비용(토큰 사용량)을 획기적으로 줄이면서도 에이전트에게 서비스 전체에 대한 강력한 제어권을 부여할 수 있습니다.

openapiai-agentmodel-context-protocoljavascript+3