techlist.io
KREN

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

toss5분 읽기큐레이션 요약

모노리포 희망편, 절망의 리포가 희망의 리포로 부활하기까지 걸린 1년

토스는 100명 이상의 프론트엔드 엔지니어가 여러 제품을 개발하면서도 React 19, Next.js 15 등 동일한 개발환경을 유지하기 위해 모노리포와 의존성 카탈로그를 활용하고 있습니다. 단순히 모노리포를 사용하는 것만으로는 서비스별 의존성 버전 파편화와 느린 설치 속도 문제를 해결할 수 없었기 때문에, 핵심 라이브러리 버전을 표준화하는 카탈로그 전략을 도입했습니다. 그 결과 의존성 규모와 설치 시간이 크게 줄었고, 플랫폼 변경과 최신 기술 도입도 더 안전하고 빠르게 진행할 수 있게 되었습니다. ## 모노리포가 제공한 개발 일관성 - 토스의 모바일 제품 코드는 하나의 모노리포로 통합되어 있습니다. - 모든 서비스가 React, Next.js, TypeScript, 번들러, Linter 등 유사한 버전을 사용하도록 관리되었습니다. - 이를 통해: - React Concurrent Mode, React Server Components 같은 최신 기능을 여러 서비스에서 활용할 수 있습니다. - 서비스 간 공통 코드와 플랫폼 라이브러리를 쉽게 공유할 수 있습니다. - 플랫폼 변경사항을 전체 서비스에 일관되게 전파할 수 있습니다. - 제품이 많아도 동일한 개발환경을 유지해 사용자 경험과 개발자 경험을 함께 개선하는 것이 목표였습니다. ## 모노리포만으로 해결되지 않은 문제 - 서비스마다 React와 각종 라이브러리의 버전이 달라 의존성 트리가 복잡했습니다. - 오래된 서비스는 낡은 개발환경을 계속 사용하게 되어 개발 서버 속도와 API 사용성에서 큰 차이가 났습니다. - 의존성 종류와 버전이 많아 설치에 캐시가 있어도 1분 이상 걸리는 경우가 있었습니다. - 플랫폼 팀은 다양한 React 및 라이브러리 조합을 모두 테스트해야 했기 때문에 공통 라이브러리 변경이 어려웠습니다. - 서비스 개발자도 업데이트 후 문제가 발생할 가능성을 우려해 플랫폼 라이브러리 업데이트를 기피했습니다. - 결과적으로 오래된 의존성이 고착되고, 서비스와 플랫폼 양쪽의 유지보수 비용이 커졌습니다. ## 폴리리포의 한계 - 모노리포를 여러 개의 독립적인 리포지토리로 나누면 각 저장소의 의존성과 설치 부담은 줄어듭니다. - 그러나 다음 문제는 오히려 남거나 심해질 수 있습니다. - 서비스별 개발환경 파편화 - 공통 코드 공유와 업데이트 비용 증가 - 서비스마다 다른 개발 경험 - 플랫폼 변경사항의 일관된 전파 어려움 - 토스는 지속적으로 플랫폼을 유지보수하고 최신화해야 하므로, 폴리리포보다는 기존 모노리포의 의존성 문제를 해결하는 방향을 선택했습니다. ## 핵심 해결책: 의존성 버전 표준화 - 가장 근본적인 문제를 “서비스마다 핵심 의존성 버전이 모두 다르다”는 점으로 정의했습니다. - React, 컴포넌트 라이브러리(TDS), 상태 관리 라이브러리(Jotai), TypeScript, ESLint 등 약 10~20개의 주요 라이브러리를 표준화 대상으로 삼았습니다. - 핵심 의존성 버전을 통일하면: - 설치해야 할 의존성의 종류와 개수가 줄어듭니다. - 모든 서비스에서 비슷한 개발 경험을 제공합니다. - 플랫폼 라이브러리의 테스트 환경이 단순해집니다. - Breaking change에 대응하는 코드 변환 스크립트나 호환성 레이어를 만들기 쉬워집니다. - 서비스 개발자가 검증된 최신 라이브러리로 업데이트할 유인이 커집니다. - 대부분의 개발자는 “React가 필요하다”고 결정할 뿐 특정 버전을 직접 선택할 필요는 없다는 점도 표준화의 근거가 되었습니다. ## 카탈로그를 통한 버전 관리 - 토스는 서비스에서 권장하는 표준 라이브러리 버전 집합을 **카탈로그(Catalog)**라고 정의했습니다. - pnpm이나 Yarn의 카탈로그 기능을 사용해 모노리포의 공통 버전을 선언합니다. ```yaml catalog: react: ^18.2.0 jotai: ^2.18.1 ``` - 각 서비스는 `catalog:` 프로토콜로 버전을 참조합니다. ```json { "dependencies": { "react": "catalog:", "jotai": "catalog:" } } ``` - 안정 버전과 실험 버전을 별도 카탈로그로 관리할 수도 있습니다. ```yaml catalogs: stable: react: ^18.2.0 jotai: ^2.18.1 beta: react: ^19.1.0 jotai: ^2.20.1 ``` - 이후 서비스는 `catalog:stable`처럼 특정 카탈로그를 선택할 수 있습니다. - React, Next.js, TypeScript, TDS, 토스 앱 SDK 등 핵심 개발 라이브러리부터 카탈로그에 편입했습니다. ## 카탈로그 도입과 운영 방식 - 카탈로그 패키지는 릴리즈 전에 주요 사용 사례를 테스트 페이지로 검증했습니다. - 신규 서비스는 최신 카탈로그를 자동으로 참조하도록 스캐폴딩했습니다. - 개발자가 `yarn add`로 직접 패키지를 추가해도 카탈로그 버전을 사용하도록 했습니다. - 실수로 카탈로그를 사용하지 않는 경우를 CI에서 자동 검출했습니다. - 기존 서비스는 코드 오너와 함께 의존성을 카탈로그 참조 방식으로 일괄 마이그레이션했습니다. - 카탈로그 버전을 변경할 때는 기존 카탈로그를 직접 수정하지 않고 새 버전을 발행했습니다. - 일부 서비스에서 먼저 검증 - 안정성 확인 - 전체 서비스가 새 카탈로그로 수동 마이그레이션 - 업그레이드 비용을 낮추기 위해 코드 수정 스크립트와 AI Skill도 제공했습니다. ## 카탈로그 적용 후의 성과 - 서비스별 의존성 버전이 통일되면서 전체 의존성 규모가 크게 감소했습니다. - Yarn PnP의 `.pnp.cjs` 파일 크기: - 96MB → 15MB - 약 84% 감소 - 개발 서버 실행 시간: - 26.7초 → 20.3초 - 약 23% 개선 - 전체 의존성 설치 시간: - 528.4초 → 249.9초 - 약 52% 감소 ## 검증된 의존성과 구조적 개선 - 카탈로그에 포함된 패키지는 최소 한 개 이상의 서비스에서 동작을 검증해야 하므로 사용 신뢰도가 높아졌습니다. - 패키지 간 의존성도 엄격하게 관리할 수 있게 되었습니다. - 예를 들어 A 패키지가 B의 v1에 의존하는데 서비스가 B의 v2를 사용하는 식의 불일치를 예방할 수 있습니다. - 어떤 서비스가 어떤 버전을 사용하는지 파악하기 쉬워져 패키지 개발자가 대규모 구조 개선을 추진하기 수월해졌습니다. - 그 결과 RSC, TypeScript 7, Rspack, E2E 테스트 같은 급진적인 기술 개선도 비교적 빠르고 안정적으로 도입할 수 있었습니다. - 플랫폼 패키지의 개선사항이 서비스에 전달되는 경로가 표준화되어, 서비스가 최신 플랫폼의 혜택을 더 빠르게 받을 수 있는 기반도 마련되었습니다. ## 실용적인 결론 모노리포의 효과를 극대화하려면 저장소를 하나로 합치는 것만으로는 부족합니다. 핵심 의존성의 버전을 카탈로그로 표준화하고, CI 검증·자동 마이그레이션·단계적 릴리즈를 함께 운영해야 서비스 간 일관성, 설치 성능, 플랫폼 업데이트 속도를 동시에 개선할 수 있습니다.

원문 읽기(새 탭에서 열림)
ReactTypeScriptmonorepodependency-management+3
cloudflare4분 읽기큐레이션 요약

에이전틱 인터넷의 좋은 행동과 나쁜 행동을 파헤치다

인터넷 트래픽은 인간과 봇으로 단순히 나눌 수 없으며, 한 세션 안에서 인간과 에이전트가 번갈아 행동하는 하이브리드 트래픽도 증가하고 있다. 따라서 사이트 운영자는 일회성 검사보다 세션 전체의 행동을 분석해 위험(Risk)과 신뢰(Trust)를 평가해야 한다. Cloudflare는 투명하게 자신을 밝히고 신뢰를 남용하지 않는 봇은 허용하되, 지속적인 행동 분석으로 악성 자동화 트래픽을 탐지하는 생태계를 구축하고 있다. ## 위험과 신뢰는 서로 다른 개념 - **위험(Risk)**은 특정 요청이나 행동이 해로울 가능성으로, 순간적이고 상황에 따라 달라진다. - **신뢰(Trust)**는 시간에 걸쳐 쌓이는 평판이며, 방문자의 행동 맥락을 바탕으로 형성된다. - 예를 들어 밤늦게 초인종을 여러 번 누르는 행동만 보면 위험해 보이지만, 방문자가 신뢰하는 친구라면 판단이 달라진다. - 인터넷에서도 “특정 시간대의 요청”이나 “일정 횟수 이상의 요청”만으로 차단하면 정상적인 사용자를 오탐할 수 있다. - Cloudflare는 악성 활동을 차단하는 것부터 안전한 참여를 장려하는 것까지, 신뢰를 중심으로 한 도구와 인센티브를 제공하려 한다. ## 투명성을 기반으로 한 정상 봇 - Cloudflare가 정의하는 검증된 봇과 에이전트는 다음 두 조건을 만족해야 한다. - 자신이 누구인지 정직하게 선언한다. - 획득한 신뢰를 악용하지 않는다. - 봇 운영자가 정체성과 데이터 사용 목적을 투명하게 공개하면, 사이트 운영자는 허용할 행동과 접근 범위를 더 쉽게 결정할 수 있다. - **BotBase**는 단순히 “좋은 봇 목록”을 제공하는 디렉터리가 아니라, 알려진 봇과 에이전트의 신원 및 행동 정보를 추적하는 시스템이다. - 검증된 봇이라도 Cloudflare 네트워크에서 신뢰를 남용하면 검증 상태를 잃을 수 있다. - 즉, 정상 여부는 고정된 신분이 아니라 실제 행동과 신뢰 유지 여부에 따라 계속 평가된다. ## 일회성 검사를 넘어서는 악성 봇 탐지 - **Precursor**는 CDN에서 JavaScript를 주입해 클라이언트 측 행동을 지속적으로 분석하는 시스템이다. - CAPTCHA나 한 번의 브라우저 검사는 특정 시점의 위험만 평가하므로, 이후 악성 행동을 시작하는 봇을 놓칠 수 있다. - Precursor는 페이지 이동을 포함한 전체 세션을 관찰해 인간답지 않은 행동 패턴을 탐지한다. - 주요 효과는 다음과 같다. - 세션 전체에 걸친 신뢰 기반 탐지 - 봇 개발자가 여러 페이지에 걸쳐 인간 행동을 모방해야 하도록 비용 증가 - 단 한 번의 검사만 통과한 자동화 트래픽에 지속적인 우회 기회를 주지 않음 - 이는 봇 개발자가 탐지 시스템을 우회하는 경제적 이점을 줄여, 공격자와 방어자 사이의 경쟁에서 방어 측에 유리하게 만든다. ## 세션 중간에 나타나는 의심스러운 행동 - 출시 후 24시간 동안 Precursor는 Cloudflare 네트워크의 73,438개 존에서 2억 600만 건의 평가 이벤트를 처리했다. - 분석 결과, 의심스러운 행동은 세션 시작 시점이 아니라 **세션 중간에 발생하는 경우가 많았다**. - 한 세션이 인간 행동에서 에이전트 행동으로, 다시 인간 행동으로 바뀌는 사례도 확인됐다. - 따라서 무조건 봇을 차단하기보다 다음 요소를 기준으로 분류해야 한다. - 트래픽의 사용 목적 - 요청의 의도 - 접근하는 데이터의 종류와 사용 방식 - 이 같은 하이브리드 트래픽을 정상적인 사용자 흐름과 구분하려면, 세분화된 봇·에이전트 분류 체계가 필요하며 BotBase 개편의 배경도 여기에 있다. ## Precursor Trace와 행동 신호 - **Precursor Trace**는 Precursor 탐지 방식 일부를 체험할 수 있는 인터랙티브 데모다. - 커서 움직임을 분석해 다음과 같은 특징을 보여준다. - 움직임의 가속과 감속 - 이동 중 수정이나 보정 - 커서 이동의 리듬과 질감 - 사람은 무의식적으로 이러한 불규칙성을 보이지만, 자동화 프로그램이 이를 여러 페이지와 긴 시간 동안 정확히 재현하기는 어렵다. ## 적응형 인텔리전스 - Cloudflare는 자동화 여부를 단순한 이진값으로만 판단하지 않고, 요청에 대한 평가 결과를 여러 단계로 구분하는 **Adaptive Intelligence**를 준비하고 있다. - 제공된 글의 본문은 이 기능의 구체적인 평가 단계와 출시 내용이 이어지기 전에 끝나 있어, 세부 사항은 확인할 수 없다. 사이트 운영자는 CAPTCHA 같은 단발성 방어책에만 의존하기보다 세션 전체의 행동, 봇의 신원 공개, 목적과 데이터 사용 방식을 함께 평가하는 것이 좋다. 정상적인 자동화는 투명성과 신뢰를 바탕으로 허용하고, 신뢰를 악용하거나 세션 중간에 비정상 행동을 보이는 트래픽은 지속적으로 재평가하는 접근이 적절하다.

원문 읽기(새 탭에서 열림)
AI 에이전트cloudflareJavaScriptcdn+3
cloudflare3분 읽기큐레이션 요약

Cloudflare 앰배서더와 커뮤니티 엔지니어, 그리고 오픈 소스에 대한 추가 100만 달러 지원 발표

Cloudflare는 개발자들이 서로 가르치고, 오픈소스에 기여하며, 커뮤니티를 성장시키는 활동을 체계적으로 지원하기 위해 커뮤니티 프로그램을 개편한다. 프로그램은 커뮤니티 행사를 이끄는 **Cloudflare Ambassadors**와 오픈소스 프로젝트에 기여하는 **Cloudflare Community Engineers**의 두 축으로 운영된다. 또한 빠르게 성장한 Discord 커뮤니티를 자동화 도구와 새로운 운영위원회로 개선할 계획이다. ## 커뮤니티 프로그램 개편 - Cloudflare는 개발자 교육, 행사 운영, 오픈소스 유지보수처럼 인터넷 생태계에 기여하는 사람들을 지원하고 인정하려 한다. - 새 프로그램의 두 가지 트랙은 다음과 같다. - **Cloudflare Ambassadors**: 각자의 지역·학교·온라인 커뮤니티에 Cloudflare를 알리고 활동을 확산 - **Cloudflare Community Engineers**: 인터넷과 Cloudflare 생태계를 개선하는 오픈소스 프로젝트에 기여 - 프로그램 관련 정보와 참여 신청은 `cloudflare.com/community`에서 제공된다. ## Cloudflare Ambassadors의 역할 - 앰배서더는 Cloudflare를 자신의 커뮤니티에 소개하고, 다른 개발자들이 실제로 제품을 활용하도록 돕는다. - 활동 사례는 다음과 같다. - 밋업, 해커톤, 워크숍, 강연 개최 - 대학 내 학생 그룹 운영 - 개발자가 함께 학습할 수 있는 공간 조성 - 튜토리얼 작성과 온라인 콘텐츠 공유 - Cloudflare의 활용 가능성을 설명하는 기술 지원 - 선정된 앰배서더는 최대 2년 동안 활동할 수 있어, 단기 이벤트가 아니라 지속적인 커뮤니티 성장을 추진할 수 있다. ## 앰배서더 지원 내용 - 커뮤니티 행사를 개최할 때 다음과 같은 지원을 신청할 수 있다. - Cloudflare 크레딧 - 마케팅 자료 - 기술 리소스 - 행사 운영에 필요한 추가 지원 - Discord 등 Cloudflare 온라인 커뮤니티에서 공식적인 역할과 식별 표시를 제공한다. - 당시 지원서 접수 기간은 9월 6일까지이며, 선정 결과는 10월 5일까지 통보될 예정이었다. - 미시간대학교 학생 Sruthi Pereddy의 사례처럼, 학생과 개발자들이 리소스 부족 때문에 아이디어를 실행하지 못하는 문제를 Cloudflare 인프라로 해결하려는 활동을 장려한다. ## Cloudflare Community Engineers와 오픈소스 지원 - Cloudflare Developer Platform은 `workerd`, `quiche` 등 오픈소스 프로젝트에 크게 의존하거나 직접 오픈소스로 제공된다. - 유지보수자와 기여자는 장기간 핵심 라이브러리, 문서, 도구, 커뮤니티를 관리하지만 그 기여가 충분히 보상받지 못하는 경우가 많다. - Cloudflare는 기존 TanStack 후원에 이어 Community Engineers 프로그램을 통해 오픈소스 기여자에게 직접적인 지원을 제공한다. - 향후 2년 동안 오픈소스 프로젝트 후원과 지원에 **추가 100만 달러**를 투입하고, 자격을 갖춘 Community Engineer에게 보조금을 지급한다. - 프로그램에는 최대 활동 기간이 없다. - 오픈소스 유지보수는 연 단위 일정에 맞지 않을 수 있다. - 어떤 프로젝트는 수년간 관리가 필요하고, 어떤 기여는 특정 시점에 집중적으로 발생하기 때문이다. - 초기 지원 대상은 Cloudflare 오픈소스 생태계와 가까운 프로젝트다. - Astro - Agents SDK - EmDash - Hono - Vinext - Community Engineer에게는 Cloudflare Discord와 기타 온라인 공간에서 특별한 표식이 부여된다. - 보조금 신청은 추후 시작될 예정이다. ## Cloudflare Discord 커뮤니티 개선 - 2020년 개설된 Cloudflare Discord에는 약 10만 명의 사용자가 참여했다. - Discord는 질문, 프로젝트 공유, 제품 피드백이 이루어지는 주요 공간으로 성장했다. - 커뮤니티가 커질수록 스팸, 악성 링크, 운영 부담도 증가하기 때문에 다음과 같은 개선을 추진한다. - Cloudflare 직원과 앰배서더가 참여하는 새로운 Discord 위원회 구성 - 스팸과 악성 링크를 차단하는 자동화 도구 도입 - 운영 자동화 도구를 향후 오픈소스로 공개 - 위원회의 핵심 역할은 단순한 관리자 업무나 채팅방 감시가 아니다. - 질문자를 적절한 도메인 전문가에게 연결 - Cloudflare 내부 팀과 커뮤니티 간 대화 주선 - 기술 세션과 협업 기회 마련 - 커뮤니티 콘텐츠와 성장 기회에 집중 - 제공된 글은 Discord를 “더 쉽게…” 개선하겠다는 대목에서 끝나므로, 이후 구체적인 계획은 확인할 수 없다. Cloudflare의 방향은 단순히 제품 사용자를 늘리는 데서 벗어나, 교육자·행사 주최자·오픈소스 유지보수자를 장기적으로 지원하는 생태계를 만드는 데 있다. Cloudflare를 활용하는 개발자라면 앰배서더 프로그램을, 관련 오픈소스 프로젝트를 유지하거나 기여한다면 Community Engineer 보조금 프로그램을 검토할 만하다.

원문 읽기(새 탭에서 열림)
discordcloudflare오픈 소스Cloudflare Workers+4
cloudflare3분 읽기큐레이션 요약

Workers AI와 AI Gateway를 하나의 AI 제어 플레인으로 통합하기

AI Gateway와 Workers AI는 각각 모델 호출 프록시와 Cloudflare 관리형 추론 서비스로 출발했지만, 이제 하나의 통합 AI 제어 평면으로 수렴하고 있다. 사용자는 단일 바인딩과 REST API를 통해 Workers AI를 포함한 여러 모델 제공자를 호출하면서 관측성, 로깅, 보안, 비용 관리, 결제를 한곳에서 처리할 수 있다. 향후에는 제공자가 아니라 원하는 모델을 기준으로 자동 라우팅·장애 조치·부하 분산까지 수행하는 모델 우선 라우팅을 제공할 계획이다. ## 통합된 바인딩과 REST API - Workers AI와 AI Gateway는 별도의 호출 경로가 아니라 동일한 `env.AI.run()` 바인딩으로 통합된다. - `gateway: { id: "default" }`를 지정하면 기본 AI Gateway를 통해 Workers AI 모델을 호출할 수 있다. - REST API도 통합되어 다음과 같은 `/ai/` 엔드포인트를 사용한다. - `https://api.cloudflare.com/client/v4/accounts/{account_id}/ai/run/{model}` - `cf-aig-gateway-id: default` 헤더로 기본 게이트웨이를 지정 - 사용자는 처음부터 Workers AI와 AI Gateway 중 어느 제품을 선택할 필요 없이 관측성과 제어 기능이 포함된 경로를 사용할 수 있다. - 여러 애플리케이션을 분리하거나 애플리케이션별 정책을 적용해야 하는 경우에는 별도의 이름 있는 게이트웨이를 지정할 수 있다. ## 자동 관측성과 제어 - AI Gateway를 사전에 생성하지 않아도 `default` 게이트웨이를 처음 인증 요청에 사용하면 자동으로 생성된다. - 별도 대시보드 설정 없이 다음 정보가 기록된다. - 요청 및 응답 전문 - 모델별 토큰 사용량 - 요청 비용 및 비용 귀속 - 지연 시간 분석 - 오류율 - 기존 Workers AI 직접 호출에 게이트웨이 옵션만 추가하면 전체 관측성을 활성화할 수 있다. - 이후 캐싱 규칙을 사용자 지정하거나 애플리케이션별로 트래픽을 분리하려면 이름 있는 게이트웨이로 변경하면 된다. - 프롬프트와 응답까지 확인할 수 있어 모델 동작 디버깅과 AI 출력 감사에 유용하다. ## AI Gateway 크레딧과 Workers AI 통합 결제 - 기존에는 AI Gateway 크레딧을 OpenAI, Anthropic 등 외부 제공자에만 사용할 수 있었다. - 이제 동일한 크레딧 지갑으로 다음 서비스의 사용량을 결제할 수 있다. - OpenAI - Anthropic - Workers AI - 기타 지원 모델 제공자 - Workers AI에도 선불 결제가 적용된다. - AI Gateway 통합 결제를 사용하는 Workers AI 이용자에게는 더 높은 요청 한도가 제공될 수 있다. - 실제 한도와 상향 요청 방법은 최신 개발자 문서를 확인해야 한다. ## 모델 우선 라우팅 - 현재는 사용자가 특정 제공자를 직접 선택해야 하므로, 해당 제공자의 장애나 속도 제한이 애플리케이션 장애로 이어질 수 있다. - 향후에는 “어느 제공자를 호출할지”가 아니라 “어떤 모델이 필요한지”를 지정하는 방식으로 전환한다. - 추론 능력이 높은 모델 - 빠른 요약 모델 - 저렴한 임베딩 모델 - AI Gateway가 모델을 호스팅하는 제공자를 선택하고 다음 작업을 자동으로 처리한다. - 제공자 선택 - 장애 조치 - 부하 분산 - 용량 부족 시 다른 제공자로의 투명한 전환 - 예를 들어 `kimi-k2.7-code`를 요청하면 Workers AI, Moonshot API 또는 동일 가중치를 제공하는 다른 검증된 제공자 중 적절한 경로가 선택될 수 있다. - 원하면 특정 제공자에 고정할 수도 있다. - 검증된 제공자를 사용하고 Zero Data Retention(ZDR) 같은 데이터 처리 요구사항도 반영할 예정이다. ## 실용적인 적용 방향 새 프로젝트라면 `default` 게이트웨이를 사용해 별도 설정 없이 로그, 토큰 사용량, 비용, 오류율을 확보하는 것이 권장된다. 애플리케이션이 커지면 이름 있는 게이트웨이로 분리하고 캐싱·보안·라우팅 정책을 세분화하면 된다. 장기적으로는 특정 제공자에 강하게 결합하기보다 모델 중심으로 호출 구조를 설계하는 편이 장애 대응과 비용 최적화에 유리하다.

원문 읽기(새 탭에서 열림)
옵저버빌리티rest-apiai-gatewayload-balancing+3
cloudflare4분 읽기큐레이션 요약

레이더 리서처 소개: 자연어로 인터넷 데이터를 탐색하는 AI 도구

Cloudflare Radar Researcher는 자연어 질문만으로 인터넷 트래픽 데이터를 조회하고, 실제 API 기반 차트와 설명을 제공하는 AI 도구다. 사용자는 복잡한 필터 설정이나 API 문서 학습 없이 국가별 인터넷 품질, 장애·셧다운 상황 등을 분석할 수 있다. Cloudflare는 이를 통해 초보자부터 네트워크 전문가까지 Radar의 공개 데이터를 더 빠르고 쉽게 활용하도록 하는 것을 목표로 한다. ## Radar Researcher를 만든 배경 - Cloudflare Radar는 2020년부터 전 세계 인터넷 트래픽에 대한 공개 데이터와 시각화를 제공해 왔다. - 주요 데이터에는 다음이 포함된다. - 1.1.1.1 공개 DNS 리졸버의 DNS 질의 - Cloudflare 글로벌 네트워크의 HTTP 트래픽 - Cloudflare Speed Test 기반 네트워크 품질 데이터 - 기존에는 사용자가 적절한 Radar 페이지를 찾고, 필터를 설정하고, API 문서를 읽어야 했다. - AI 도구의 발전으로 데이터셋의 구조와 전문 용어를 몰라도 자연어로 원하는 정보를 얻을 수 있게 되었다. - 기자나 연구자처럼 신속하게 데이터를 확인해야 하는 사용자는 복잡한 탐색 과정을 거치지 않고 바로 분석을 시작할 수 있다. ## 자연어 기반 데이터 질의 - Radar Researcher는 사용자의 질문을 해석해 Radar API에 필요한 데이터 요청을 자동으로 구성한다. - 답변은 단순한 텍스트가 아니라 Radar에서 제공하는 것과 같은 인터랙티브 차트와 간단한 설명으로 제공된다. - 답변의 깊이를 선택할 수 있다. - 짧고 직접적인 답변 - 여러 주제를 다루는 상세 보고서 - 답변 뒤에는 추가로 조사할 만한 후속 질문을 제안한다. - 대화 기록은 검색·고정할 수 있고, 링크로 공유할 수 있다. - 공유 링크는 30일 후 자동 만료된다. - 사용자는 텍스트 입력뿐 아니라 음성 입력이나 Radar 검색창에서도 Researcher를 실행할 수 있다. - 모델이 질문을 어떻게 해석했고, 어떤 데이터셋과 API를 사용했으며, 결과를 어떻게 분석했는지 확인할 수 있다. ## 기존 차트에서 바로 분석 시작 - Radar의 차트에 있는 **Explain with AI** 기능을 사용하면 현재 보고 있는 시각화를 대화의 출발점으로 삼을 수 있다. - 모델에는 다음 세 가지 정보가 함께 전달된다. - 차트 스크린샷: 사용자가 실제로 보는 시각적 맥락 파악 - Radar API의 원시 데이터: 숫자를 픽셀에서 추정하지 않고 정확하게 인용 - 현재 화면의 위치, 날짜 범위, 필터 등 조회 조건 - 따라서 일반적인 차트 설명이 아니라 사용자가 선택한 국가·기간·필터에 정확히 맞춘 분석을 제공한다. ## 사례: 포르투갈의 인터넷 품질 분석 - 사용자는 “포르투갈의 가정용 인터넷 품질은 어떤가?”처럼 자연어로 질문할 수 있다. - Researcher가 인터넷 품질 API를 조회하고 결과를 분석한 뒤, 수치 나열 대신 인터랙티브 차트로 답변한다. - 이후 포르투갈과 인접 국가를 비교하거나, 포르투갈에서 가장 흔한 인터넷 장애를 확인하는 식으로 후속 분석을 이어갈 수 있다. - API 호출 방식이나 파라미터를 직접 알지 않아도 국가별·주제별 비교가 가능하다. ## 사례: 이란 인터넷 셧다운 조사 - 2026년 이란에서 발생한 정부 주도 인터넷 차단 사례를 조사할 때 여러 트래픽 차트와 장애 기록을 직접 찾아 비교할 필요가 없다. - Researcher는 이란의 Cloudflare Radar 장애 이벤트와 관련 HTTP 트래픽 데이터를 함께 조회한다. - 분석 결과를 다음과 같은 타임라인으로 설명한다. - 1월 7일 HTTP 트래픽 지수가 약 0.58에서 시작 - 1월 9일까지 사실상 0으로 하락 - 1월 17일경 부분 회복 시작 - 1월 27일경 셧다운 이전 수준에 근접 - 2월 28일 시작된 두 번째 셧다운도 장애 표에 표시 - 장애 기간은 트래픽 차트 위에 직접 표시되며, 관련 장애 이벤트는 표 형태로 함께 제공된다. - 이후 주변 국가와의 트래픽 비교 같은 추가 조사도 제안한다. ## Cloudflare 개발자 플랫폼으로 구축 - Radar Researcher는 Cloudflare의 자체 개발자 플랫폼 위에서 구현되었다. - 핵심 구성은 다음과 같다. - Cloudflare Worker - Cloudflare Agents SDK - 대화별 상태를 유지하는 Durable Objects - 각 대화의 기록·제목·스트리밍 응답을 저장하는 SQLite 데이터베이스 - Workers AI 기반의 오픈 모델 - 사용자가 페이지를 떠나도 서버에서 응답 생성이 계속되고, 다시 접속하면 결과를 이어받을 수 있다. - 특정 모델이나 제공업체에 의존하지 않도록 세 가지 모델 계열을 순서대로 사용하는 fallback 체인을 구성했다. - 한 모델이 일시적으로 용량 부족 상태가 되면 다른 모델로 자동 전환해 서비스 중단 가능성을 줄인다. - 모든 AI 호출은 AI Gateway를 거친다. ## 실용적인 결론 Radar Researcher는 전문적인 데이터 탐색 과정을 자연어 인터페이스로 감싸, 기자·연구자·네트워크 운영자뿐 아니라 일반 사용자도 Cloudflare Radar의 공개 데이터를 쉽게 활용하게 해준다. 다만 AI의 해석을 그대로 받아들이기보다는 제공되는 API 데이터, 조회 조건, 분석 과정을 함께 확인하는 방식으로 사용하는 것이 적절하다.

원문 읽기(새 탭에서 열림)
대규모 언어 모델Cloudflare Workersdurable-objectssqlite+3
line4분 읽기큐레이션 요약

개인 AI 활용의 다음 단계는 무엇인가 - LY Corporation에서 AIDD 워크숍을 통해 살펴본 AIDD 조직 도입의 조건

LY Corporation은 개인의 AI 활용을 조직 차원의 재현 가능한 개발 방식으로 확장하기 위해 팀 단위 AIDD 워크숍을 진행했습니다. 워크숍의 핵심 결론은 AI 도구 자체보다 요구 사항, 사양, 용어, 제약 조건 등 컨텍스트를 정비하고 사람과 AI의 역할·책임을 설계하는 일이 더 중요하다는 것입니다. 또한 조직적 도입을 위해서는 다양한 직군과 의사결정자가 실제 업무 주제를 함께 다뤄야 합니다. ## AIDD의 정의와 지향점 - AIDD는 요구 사항 정리부터 설계, 구현, 리뷰까지 개발 전 과정에서 AI를 협력자로 활용하는 방식입니다. - AI에 업무를 일괄 위임하는 것이 아니라, AI가 초안을 만들고 사람이 의도·제약 조건을 제공하며 핵심 판단과 책임을 맡습니다. - 각 단계의 결과를 다음 단계로 연결하는 통합된 개발 프로세스를 설계하는 것이 중요합니다. - 따라서 AIDD는 단순한 보조 도구 활용이 아니라, AI와 사람의 역할 분담을 포함한 개발 방식의 재설계입니다. ## 개인 활용에서 조직 도입으로 넘어가는 장벽 - AI 코딩 에이전트는 코드 자동 완성, 테스트, 리서치, 문서 작성 등에 널리 활용되고 있습니다. - 그러나 다음과 같은 문제로 개인의 노하우에 머무르기 쉽습니다. - 개인이 사용해도 팀의 개발 프로세스와 연결되지 않음 - AI 산출물의 리뷰 기준과 책임 범위가 불명확함 - 기존 제품과 코드베이스에 적용하는 방법이 모호함 - 편리함은 확인했지만 조직 차원의 투자와 표준화로 이어지지 않음 - 워크숍은 이러한 정체를 해결하고, 조직이 AI를 활용하기 위한 ‘AI Ready’ 조건을 확인하는 데 목적이 있었습니다. ## 팀 단위 워크숍을 선택한 이유 - AI 활용의 성과는 프롬프트 작성 능력보다 정보 전달, 리뷰 지점, 최종 산출물 기준, 피드백 흐름에 좌우됩니다. - 기획, 디자인, 엔지니어링, 리더십 등 여러 역할의 관점과 암묵지가 함께 드러나야 프로세스를 설계할 수 있습니다. - 팀 단위로 실제 업무를 다루면 다음 논점이 구체화됩니다. - 어떤 업무에 AI를 적용할 것인가 - 누가 AI 산출물을 검토할 것인가 - 어떤 결과물을 공식 산출물로 인정할 것인가 - 책임과 의사결정의 경계를 어디에 둘 것인가 - 의사결정자가 참여하면 적용 범위, 투자 우선순위, 표준화 수준을 워크숍 이후 실행으로 연결하기 쉬워집니다. ## 이틀간의 프로그램 구성 - 첫째 날에는 문제 정의와 업무 컨텍스트 정리에 집중했습니다. - 둘째 날에는 팀이 자율적으로 AI 활용을 검증하고 실제 업무에 적용 가능한 형태로 구체화했습니다. - 21개 팀, 112명이 실제 프로젝트 주제를 가져와 실습했습니다. - Orchestration 길드, Developer Relations, Technical Directors가 콘텐츠 구성과 멘토링, 학습 공유를 지원했습니다. - 단순한 도구 시연이 아니라 이해, 실습, 검증, 공유를 반복하는 실천 중심 구조였습니다. ## 구현보다 중요한 사전 정리 - AI 코딩 에이전트의 코드 생성 속도보다 그 이전 단계의 정리 작업이 더 큰 가치로 인식되었습니다. - 특히 다음 작업이 중요했습니다. - 모호한 요구 사항을 논점별로 분해하기 - 요구 사항을 명확한 언어로 정의하기 - 팀 내부의 인식을 일치시키기 - 선행 의사결정과 우선순위를 정하기 - 다음 작업 단위로 구체화하기 - AI가 개발을 전진시키려면 사람이 목적과 제약 조건을 먼저 명확히 해야 합니다. ## 병목은 AI 도구가 아니라 컨텍스트 - AI 출력의 품질은 제공되는 컨텍스트의 품질에 크게 의존합니다. - 필요한 컨텍스트에는 다음이 포함됩니다. - 사양과 용어 - 제약 조건 - 설계 의도와 판단 이유 - 기존 코드와 기능 간의 관계 - 운영 규칙 - 컨텍스트가 부족하면 AI가 그럴듯한 답을 내더라도 실무 적용이 어렵고, 사람의 리뷰 부담이 커집니다. - 따라서 컨텍스트 정리는 부수적인 준비가 아니라 조직적 AI 활용을 위한 핵심 기반입니다. ## 팀 협업과 의사결정자의 역할 - 개인 실험에서는 잘 드러나지 않던 합의 형성, 책임 범위, 리뷰 기준이 팀 단위 활동에서 명확해졌습니다. - 서로 다른 직군이 같은 업무를 검토하면서 역할별 인식 차이와 숨은 전제가 드러났습니다. - 리더나 의사결정자가 참여한 팀은 워크숍 후에도 다음 실행으로 이어질 가능성이 높았습니다. - 조직 확산을 위해서는 다음을 결정할 사람이 초기 단계부터 참여해야 합니다. - 우선 적용 영역 - 투자할 시간과 자원 - 표준화할 대상 - 운영 프로세스에 내재화할 범위 ## 조직에 AIDD를 정착시키는 방법 - 처음에는 적용하기 쉬운 주제부터 시작해야 합니다. - 요구 사항이나 쟁점이 불명확한 업무 - 관계자 간 인식 정렬이 중요한 업무 - 기존 정보를 어느 정도 확보할 수 있는 업무 - 짧은 주기로 결과를 검증할 수 있는 업무 - 기능 하나, 요구 사항 정리 하나, 리뷰 기준 정리 하나처럼 작은 진입점을 마련해야 합니다. - 사양·용어·제약 조건·설계 의도를 정리하는 작업을 개인의 자발성에 맡기지 말고 공식 업무로 인정해야 합니다. - 컨텍스트 자산화는 AI를 위한 작업인 동시에 팀의 개발 역량과 지식을 강화하는 활동입니다. 실무적으로는 전사 도입을 서두르기보다, 의사결정자와 여러 직군이 참여하는 작은 팀에서 실제 업무 한 사이클을 검증하는 것이 좋습니다. 그 과정에서 컨텍스트, 리뷰 책임, 표준화 범위를 정리한 뒤 성공 사례를 조직 전체로 확장해야 합니다.

원문 읽기(새 탭에서 열림)
software-development코드 리뷰software-designcontext-engineering+4
aws4분 읽기큐레이션 요약

런타임 인스턴스: Amazon Bedrock AgentCore에서 프로덕션 AI 에이전트를 위한 지속적 컴퓨팅 | Amazon Web Services

Amazon Bedrock AgentCore의 **runtime instances**는 장시간 실행, GPU 사용, 다중 에이전트 협업이 필요한 프로덕션 AI 에이전트를 위한 AWS 관리형 EC2 기반 실행 환경이다. 최대 14일 동안 세션 상태를 유지하고, 여러 에이전트가 같은 호스트와 파일 시스템을 공유할 수 있다. 기존에 직접 구성해야 했던 EC2, 네트워크, 세션 관리, 확장, 모니터링을 AgentCore API·IAM·관측성 체계와 함께 관리해 복잡한 에이전트 워크로드를 단순화한다. ## runtime instances가 해결하는 문제 - 프로토타입 에이전트를 프로덕션으로 전환하면 다음 요구사항이 발생한다. - 수 시간에서 수일 동안 지속되는 워크플로 - 여러 단계에 걸친 상태 유지 - 에이전트 간 협업과 컨텍스트 공유 - GPU 또는 운영체제 수준 접근 - 대용량·지속형 컴퓨팅 환경 - 기존에는 EC2 인스턴스, 네트워크, 세션 관리, 확장, 모니터링을 직접 구축해야 했다. - runtime instances는 이러한 인프라를 AWS가 관리하면서 기존 AgentCore API, 인증 제어, 관측성 기능과 통합한다. ## runtime microVM과 runtime instances의 차이 - **runtime microVM** - 빠른 확장에 적합한 경량 실행 환경 - 개별 호출을 최대 8시간까지 실행 - 관리형 세션 저장소를 통해 상태 기반 워크플로 지원 - **runtime instances** - AWS 관리형 EC2 기반의 지속형 실행 환경 - 공유 세션을 최대 14일까지 유지 - GPU, 직접적인 OS 접근, 장시간 실행 지원 - 여러 에이전트를 하나의 런타임에서 실행 가능 - 유휴 기간에는 세션을 중지하고 나중에 재개해 비용 절감 - 두 환경은 독립적으로 사용하거나 함께 구성할 수 있다. - 예를 들어 microVM의 오케스트레이터가 작업을 분배하고, instances의 워커 에이전트가 코드 컴파일·보안 검사·GUI 자동화 같은 무거운 작업을 수행한다. ## 에이전트 배포와 협업 방식 - CrewAI, LangGraph, LlamaIndex, Strands 등 원하는 프레임워크와 모델을 사용할 수 있다. - 애플리케이션은 `@app.entrypoint` 데코레이터를 사용하며, ZIP 파일 또는 컨테이너 이미지로 패키징한다. - 같은 세션에 속한 에이전트들은 서로를 도구처럼 호출하며 자율적으로 작업을 반복할 수 있다. - 세션이 며칠간 중단되어도 상태를 유지한 채 재개할 수 있다. - 세션을 초월해 보존해야 하는 지식은 다음 서비스와 결합할 수 있다. - Amazon EBS: 지속적인 파일 시스템과 작업 데이터 저장 - AgentCore Memory: 세션·환경을 넘어 유지되는 장기 기억 ## 코드 작성 에이전트와 리뷰 에이전트 예시 - 예제에서는 두 개의 Python 에이전트를 만든다. - **Writer**: 자연어 요구사항을 Python 코드로 변환 - **Reviewer**: 생성된 코드의 버그, 보안 문제, 스타일을 검토 - Writer는 세션 ID를 기반으로 공유 디렉터리를 만든 뒤 `code.py`를 저장한다. - Reviewer는 같은 세션 ID로 해당 파일을 읽어 코드 리뷰를 수행한다. - 두 에이전트가 같은 파일 시스템을 공유하므로 다음이 필요 없다. - 코드 파일을 별도로 업로드하거나 다운로드하는 과정 - 에이전트 간 API를 통한 데이터 전송 - 실제 운영 환경에서는 예외 처리, 파일 접근 권한, 동시성 제어, 세션 ID 검증 등을 추가해야 한다. ## 용량 공급자 설정 - 먼저 에이전트가 실행될 EC2 인프라를 정의하는 **capacity provider**를 생성한다. - 주요 설정 항목은 다음과 같다. - 운영체제: Linux 64-bit ARM - 인스턴스 유형: 예시에서는 `c7g.2xlarge` - 컴퓨팅 자원: 8 vCPU, 16 GiB 메모리 - VPC, 서브넷, 보안 그룹 - gp3 EBS 볼륨 - EC2 관리를 위한 서비스 역할과 인프라 역할 - 생성 후 상태가 `Active`가 되면 런타임에서 사용할 수 있다. - 생성 이후에는 설명 외 설정 변경이 제한되므로 인스턴스 유형, 네트워크, 보안 설정을 처음부터 검토해야 한다. ## 런타임 생성과 에이전트 배포 - Runtime에서 Compute type으로 **Instances**를 선택한다. - 앞서 만든 capacity provider를 연결한다. - 에이전트 소스는 S3에서 가져오며, ZIP 파일을 업로드할 수 있다. - 배포 시 다음 정보를 지정한다. - Python 3.13 등 언어 런타임 - `agent.py`와 같은 엔트리포인트 파일 - 에이전트의 `@app.entrypoint` 함수 - AWS Management Console뿐 아니라 AgentCore CLI, AWS CLI, IaC 도구로도 배포할 수 있다. ## 실용적인 선택 기준 - 빠른 확장과 짧은 호출 중심의 오케스트레이션에는 runtime microVM이 적합하다. - 장시간 실행, GPU, 공유 파일 시스템, 다중 에이전트 협업, OS 접근이 필요하면 runtime instances를 고려하는 것이 좋다. - 일반적으로는 microVM을 오케스트레이터로, runtime instances를 전문 워커 실행 환경으로 조합하는 구조가 효과적이다. - 비용을 줄이려면 작업이 없는 시간에 세션을 중지하고, EBS와 AgentCore Memory를 목적에 맞게 분리해 사용하는 것이 권장된다.

원문 읽기(새 탭에서 열림)
Pythonmulti-agent-systemsamazon-bedrock-agentcoreaws-ec2+2
github3분 읽기큐레이션 요약

GitHub Copilot 앱의 슬래시 명령어 가이드

GitHub Copilot 앱의 슬래시 명령어는 채팅 입력창에서 `/`로 시작해 세션 관리, 프로젝트 탐색, 작업 모드 전환을 빠르게 수행하도록 돕는다. CLI가 터미널과 디렉터리·작업 경로 관리에 초점을 둔다면, 앱의 명령어는 시각적 인터페이스와 멀티 세션 워크플로에 맞춰 계획 수립, 비판적 검토, 자동 구현 등을 지원한다. 특히 `/plan`으로 작업을 설계하고 `/spar`로 위험을 검토한 뒤 `/autopilot`으로 구현하는 흐름이 핵심이다. ## 슬래시 명령어의 개념과 앱·CLI의 차이 - 채팅 입력창에 `/`를 입력하면 현재 상황에서 사용할 수 있는 명령어 자동완성 메뉴가 표시된다. - CLI 명령어는 터미널 중심으로 설계되어 디렉터리 추가(`/add-dir`), 작업 디렉터리 변경(`/cwd`) 등을 담당한다. - Copilot 앱은 프로젝트 컨텍스트와 파일 접근을 시각적으로 관리하므로 `/add-dir`, `/cwd` 같은 명령어가 필요하지 않다. - 앱에서는 세션 이동, 프로젝트 관리, 에이전트 작업 방식 제어 등 워크플로 중심의 명령어를 제공한다. - `/clear`, `/model`처럼 CLI와 앱에서 공통으로 사용할 수 있는 명령어도 있다. ## `/plan`으로 코딩 전에 작업 설계 `/plan`은 구현에 앞서 작업을 분석하고 단계별 계획을 세우는 명령어다. 실행하면 세션이 **Plan 모드**로 전환되며, 채팅 입력창의 **Mode** 메뉴에서도 같은 모드를 선택할 수 있다. - 새 기능 개발: - 변경이 필요한 파일, 컴포넌트, 의존성을 파악한다. - 예: `/plan`으로 2단계 인증 도입에 필요한 작업과 구현 순서를 정리한다. - 대규모 리팩터링: - 복잡한 코드 변경의 범위와 위험 요소를 확인한다. - 한 번에 전환하지 않고 점진적으로 마이그레이션할 방법을 수립한다. - 버그 조사: - 원인이 불명확한 장애의 가능한 원인을 탐색한다. - 진단 절차와 수정 작업을 단계별로 계획한다. ## `/spar`로 가정과 설계 검증 `/spar`는 Copilot이 반대 의견을 제시하도록 해 설계의 허점, 위험, 트레이드오프를 검토하는 명령어다. - 아키텍처 선택 검증: - Redis 캐시의 무효화 전략, 확장성, 일관성 문제 등을 점검한다. - 구현 방식 비교: - REST와 GraphQL, 동기 처리와 비동기 처리처럼 여러 접근법의 장단점을 비교한다. - 애플리케이션 요구사항에 맞는 선택을 추천하도록 요청할 수 있다. - 마이그레이션 계획 검토: - 데이터베이스나 인프라 이전 과정의 엣지 케이스와 배포 위험을 찾는다. - 무중단 또는 최소 다운타임 조건에서 발생할 문제를 미리 점검한다. - 성능 최적화 비판: - 지연 로딩 등 최적화가 사용자 경험을 해치거나 불필요한 복잡성을 만들 가능성을 확인한다. - 숨은 병목과 부작용, 더 단순한 대안을 함께 검토한다. ## `/autopilot`으로 구현 자동화 `/autopilot`은 계획한 목표를 바탕으로 여러 구현 단계를 Copilot이 직접 수행하도록 하는 명령어다. 실행하면 세션이 **Autopilot 모드**로 전환되며, Mode 메뉴에서도 선택할 수 있다. - 새 기능 구현: - 필요한 파일을 식별하고 코드를 수정한다. - 관련 테스트를 추가하거나 업데이트하도록 요청할 수 있다. - 예: 사용자 보고서를 CSV로 내보내는 기능을 설계부터 구현까지 진행한다. - 대규모 유지보수: - 의존성 업데이트, 리팩터링, 문서 개선처럼 여러 단계가 필요한 작업에 적합하다. - React 버전 업그레이드 시 호환성 문제를 수정하고 테스트 통과 여부까지 확인하도록 할 수 있다. - 사용자는 세부 단계마다 지시하기보다 최종 목표와 제약 조건을 전달하는 방식으로 작업할 수 있다. ## `/rubber-duck`로 문제를 대화형 검토 `/rubber-duck`는 문제를 설명하고 다른 관점에서 검토받는 디버깅 지원 명령어다. - Copilot이 별도의 모델을 사용해 독립적으로 검토하는 방식으로 소개된다. - 혼자 문제를 설명하며 사고를 정리하는 ‘러버 덕 디버깅’ 과정을 Copilot과 수행할 수 있다. - 제공된 글 내용은 이 명령어 설명 중간에서 끝나므로, 구체적인 사용 예와 전체 동작 방식은 확인할 수 없다. 실무에서는 먼저 `/plan`으로 범위와 순서를 정리하고, `/spar`로 설계의 위험을 검증한 다음, 충분히 구체화된 작업을 `/autopilot`에 넘기는 방식이 효과적이다. 자동 구현을 사용하더라도 테스트와 변경 내용을 직접 검토해 결과를 확인하는 것이 좋다.

원문 읽기(새 탭에서 열림)
github-copilotslash-commandscopilot-cliai-coding-assistant+2
github1분 읽기큐레이션 요약

멀웨어 보안 권고를 npm을 넘어 확장한 방법

Ankit은 GitHub에서 Dependabot 팀을 이끄는 시니어 엔지니어링 매니저입니다. Dependabot은 34개 이상의 패키지 생태계에 걸쳐 3천만 개가 넘는 저장소를 감시하며, 소프트웨어 공급망 공격에 대응하는 역할을 합니다. 이러한 광범위한 책임 때문에 Ankit은 공급망 보안 위협에 대해 높은 경계심을 유지하고 있습니다. ### Ankit의 역할 - GitHub의 Supply Chain Security 조직에서 Dependabot 팀을 이끕니다. - 엔지니어링 관리자로서 소프트웨어 의존성 및 공급망 보안과 관련된 업무를 담당합니다. ### Dependabot의 감시 범위 - 3천만 개 이상의 저장소를 모니터링합니다. - 34개 이상의 패키지 생태계를 지원합니다. - 다양한 패키지 관리자와 의존성을 다뤄야 하므로 매우 광범위한 보안 대응이 필요합니다. ### 소프트웨어 공급망 보안 - 패키지와 의존성은 애플리케이션 보안에 직접적인 영향을 줍니다. - 의존성의 취약점이나 악성 패키지는 다수의 저장소에 빠르게 확산될 수 있습니다. - Dependabot의 대규모 감시 범위는 공급망 공격을 조기에 탐지하고 대응하는 데 중요한 역할을 합니다. 이 글의 제공된 내용은 Ankit과 Dependabot의 역할 및 규모를 소개하는 부분에 해당하며, 구체적인 기술적 주장이나 구현 세부사항은 포함되어 있지 않습니다.

원문 읽기(새 탭에서 열림)
githubsupply-chain-securitydependabotpackage-ecosystems
kakao4분 읽기큐레이션 요약

개인화된 Airflow 테스트 환경 구축 및 운영 경험

수천 개의 Airflow DAG를 운영하는 카카오 데이터서비스 조직은 테스트 과정의 반복 작업과 환경 간 차이, 리소스 충돌 문제를 해결하기 위해 PR 단위의 개인 Airflow 환경인 AirZone을 구축했습니다. AirZone은 GitHub PR 코멘트에서 생성·삭제를 요청하면 Kubernetes Job과 전용 Helm 차트로 격리된 Airflow를 배포합니다. 사용자는 인프라를 직접 구성하지 않고 실제 운영 환경과 유사한 하둡·인증 환경에서 DAG를 테스트할 수 있습니다. ## 기존 테스트 방식의 한계 - **로컬 Airflow** - Airflow뿐 아니라 하둡 인증, 연결 설정, Docker 환경까지 직접 구성해야 합니다. - 초기 구축 비용이 크고, 로컬 환경과 운영 환경의 차이로 인해 실제 배포 후 실패할 수 있습니다. - **개발용 Airflow** - 코드를 커밋하고 푸시한 뒤 GitHub webhook, submodule 업데이트, DAG 파일 처리 과정을 기다려야 합니다. - DAG를 수정할 때마다 동기화 지연이 반복되어 개발 속도를 떨어뜨렸습니다. - **테스트용 Airflow** - SSH 컨테이너에 로컬 파일을 복사해야 하므로 코드 수정 때마다 추가 작업이 필요합니다. - 실제 데이터와 하둡에 접근하려면 prod VPN을 연결해야 하는 불편도 있었습니다. - **Production Airflow에서의 테스트** - 테스트 DAG가 스케줄러와 워커 자원을 점유해 다른 프로젝트의 실행을 지연시킬 수 있습니다. - 과도한 리소스 사용으로 노드 장애가 발생하면 같은 노드의 다른 태스크까지 중단될 위험이 있습니다. ## AirZone의 핵심 요구사항 - Kubernetes나 Helm을 몰라도 브라우저에서 Airflow 환경을 생성하고 삭제할 수 있어야 합니다. - 사용자는 DAG 검증에만 집중하고, 인프라 구성은 AirZone이 담당해야 합니다. - Jupyter Notebook을 제공해 별도 로컬 환경 없이 코드를 수정할 수 있어야 합니다. - 운영 환경과 유사한 DAG 실행 환경과 하둡 인증 방식을 제공해야 합니다. - PR마다 독립된 Airflow를 생성해 사용자와 테스트 작업을 서로 격리해야 합니다. ## PR 단위의 격리된 환경 - 레포지터리명과 PR 번호를 조합해 Kubernetes 네임스페이스를 생성합니다. - Airflow 웹 서버, 스케줄러, PostgreSQL, Jupyter, DAG PVC, 로그가 PR별로 분리됩니다. - 한 PR의 테스트가 다른 프로젝트의 스케줄러·워커 자원을 침범하지 않습니다. - 리뷰어는 PR에 남은 링크로 특정 코드 상태의 실행 결과를 직접 확인할 수 있습니다. - PR이 종료되면 네임스페이스를 기준으로 관련 리소스를 쉽게 정리할 수 있습니다. ## 요청 처리와 배포 작업의 분리 - `airzone-api`는 PR 존재 여부, PR이 열려 있는지, 네임스페이스 중복 여부 등 요청의 유효성만 검증합니다. - 실제 Helm 설치와 헬스체크는 별도의 Kubernetes Job이 수행합니다. - API가 수 분이 걸리는 배포 작업을 직접 기다리지 않으므로 빠르게 응답할 수 있습니다. - Job별로 상태와 로그가 독립적으로 남아 실패 단계와 원인을 추적하기 쉽습니다. - 실패한 Job을 삭제한 뒤 새 Job을 생성하는 방식으로 배포를 재시도할 수 있습니다. - 생성 요청은 `create-airzone-{namespace}`, 삭제 요청은 `delete-airzone-{namespace}` 형식의 Job 이름을 사용합니다. ## GitHub PR 코멘트를 사용자 인터페이스로 활용 - PR 생성 이벤트를 webhook으로 받아 저장소, 브랜치, PR 번호, 요청자 정보를 확인합니다. - 사용자가 선택할 수 있도록 하둡 환경별 AirZone 생성 링크를 PR 코멘트에 남깁니다. - 생성 완료 결과와 접속 정보도 PR에 표시해 별도 플랫폼 없이 테스트를 시작할 수 있습니다. - 다만 Jupyter 토큰과 Kubernetes 네임스페이스 토큰처럼 민감한 정보는 공개 범위가 넓은 PR 대신 카카오워크로 전달합니다. - 요청 접수와 배포 완료 시점에 카카오워크 알림을 보내 진행 상태를 알립니다. ## 전용 Helm 차트로 구성한 Airflow 기존 운영용 Airflow 차트가 아닌 AirZone 전용 Helm 차트를 만들어 테스트 환경에 필요한 구성만 묶었습니다. - **Airflow 구성** - 웹 서버와 스케줄러를 배포합니다. - `KubernetesExecutor`, DAG 스캔 주기, 로그 설정, 하둡 관련 변수를 테스트 환경에 맞게 설정합니다. - **데이터베이스와 저장소** - 개인 환경용 PostgreSQL을 함께 배포합니다. - scheduler와 Jupyter가 같은 DAG 작업 디렉터리를 사용하도록 DAG PVC를 공유합니다. - **DAG 동기화** - PR의 head repository와 branch 정보를 받아 해당 코드만 동기화합니다. - Git 초기화 컨테이너 등을 통해 배포 환경에 테스트 대상 DAG를 준비합니다. - **인증과 보안** - 사용자·공용 principal, 키탭, Jupyter 토큰을 환경에 주입합니다. - 하둡 접근에 필요한 Kerberos 인증을 운영 환경과 유사하게 구성합니다. - dkos에서 제공하는 TLS 인증서도 테스트 환경에 반영합니다. - **운영 연동** - 여유 있는 노드 그룹과 같은 리전의 `storageClass`를 선택합니다. - Airflow 로그를 Elasticsearch와 Kibana에서 확인할 수 있도록 연결 정보를 주입합니다. - Jupyter를 함께 제공해 브라우저에서 DAG와 관련 코드를 수정할 수 있게 합니다. ## 자동 정리와 운영 구조 - 생성·삭제 요청은 Kubernetes Job으로 처리합니다. - PR 종료 후 남아 있는 AirZone은 매일 실행되는 CronJob이 자동으로 회수합니다. - 사용자에게는 “PR 코멘트의 링크를 누르는 기능”으로 단순하게 보이지만, 운영자는 요청·설치·헬스체크·알림·정리 단계를 각각 추적할 수 있습니다. - 운영 환경에서 불필요한 PGBouncer나 외부 DB 연결 등은 제외해 개인 테스트 환경의 복잡도와 비용을 줄였습니다. AirZone과 같은 구조를 도입할 때는 테스트 환경을 운영 환경과 최대한 유사하게 유지하되, PR 또는 브랜치 단위로 리소스를 격리하는 것이 중요합니다. 또한 긴 배포 작업은 API 요청과 분리하고, Kubernetes Job의 상태·로그·재시도 기능을 활용하면 장애 대응과 운영 추적이 훨씬 쉬워집니다.

원문 읽기(새 탭에서 열림)
쿠버네티스PostgreSQLapache-sparkhelm+3
cloudflare5분 읽기큐레이션 요약

개방형 에이전틱 인터넷 구축하기: 읽을 수 있고, 발견 가능하며, 호출 가능하고, 결제 가능한

에이전트가 사람을 대신해 웹을 읽고, 행동하고, 비용을 지불하는 시대가 오면서 기존의 인간 중심 웹은 한계에 부딪히고 있다. Cloudflare는 이를 “에이전틱 인터넷”이라 부르며, 웹이 에이전트에게 읽기 쉽고(readable), 발견 가능하며(discoverable), 호출 가능하고(callable), 결제 가능해야 한다고 주장한다. 이를 위해 특정 기업에 종속되지 않는 개방형 표준과 도구를 구축해야 하며, 궁극적으로 에이전트와 웹사이트가 충돌하는 대신 협력하는 구조를 만들어야 한다. ## 에이전트가 바꾸는 웹의 전제 - 기존의 `User-Agent`는 브라우저가 사용자를 대신해 웹을 방문한다는 의미였지만, 이제는 실제로 사람이나 기업을 대신해 작업하는 프로그램이 웹의 방문자가 되고 있다. - 코딩 에이전트는 문서를 읽고, 코드를 작성하며, 필요한 페이지를 가져오지만 CSS를 렌더링하거나 광고를 보지는 않는다. - 에이전트의 각 요청에는 비용을 지불하는 사람과 구체적인 목적이 있다. - 에이전트를 단순 스크래퍼로 차단하면 실제 고객의 요청까지 막게 되고, 기존의 페이지뷰·광고 중심 분석과 비즈니스 모델도 제대로 작동하지 않는다. - 현재 웹에는 변경되지 않은 페이지를 정상적인 봇이 반복해서 가져오는 요청이 수십억 건 발생하며, 이는 막대한 컴퓨팅 자원의 낭비를 보여준다. ## 개방형 에이전틱 인터넷 - 에이전틱 인터넷의 미래는 특정 플랫폼이 검색, 신원 확인, 결제를 독점하는 방식과 개방형 표준을 사용하는 방식으로 나뉠 수 있다. - Cloudflare는 누구나 구현할 수 있는 공개 표준을 기반으로 한 개방형 인터넷을 지향한다. - 핵심 기술로 다음을 제시한다. - **x402**: 에이전트가 웹 리소스나 서비스에 직접 비용을 지불하는 결제 표준 - **MCP**: 에이전트가 도구와 기능을 발견하고 호출하기 위한 프로토콜 - **Web Bot Auth**: 봇이 자신을 암호학적으로 증명하는 인증 방식 - **PACT**: 신뢰할 수 있는 사이트가 에이전트를 익명으로 보증하는 토큰 - 도메인 소유자는 원하는 인증 제공자, 결제 사업자, 에이전트 파트너를 선택할 수 있으며 Cloudflare도 여러 선택지 중 하나로 남아야 한다. ## 신원 확인과 신뢰 - **Web Bot Auth**를 사용하면 사이트는 User-Agent 문자열에 의존하거나 위조 여부를 추측하지 않고, 방문한 봇의 신원을 암호학적으로 확인할 수 있다. - 사이트는 자신이 이미 로그인, 앱 사용 기록, 구매 이력 등을 통해 알고 있는 사용자를 기반으로 에이전트에게 **PACT(Private Access Control Tokens)**를 발급할 수 있다. - 에이전트는 다른 사이트에서 이 토큰을 제시해 자신이 신뢰할 만한 사용자와 연결되어 있음을 증명할 수 있다. - 이를 통해 정상적인 에이전트는 불필요한 차단과 CAPTCHA를 줄이고, 사이트는 악성 자동화 트래픽을 더 정확히 구분할 수 있다. ## Readable: 에이전트가 읽기 쉬운 웹 - 에이전트는 인간처럼 화면을 보고 CSS를 해석하지 않으므로, 인간용 HTML 전체를 전달하는 방식은 토큰과 대역폭을 낭비한다. - 보이지 않는 장식 요소와 레이아웃 정보는 에이전트의 컨텍스트를 오염시키고, 결국 처리 비용을 증가시킨다. - **Markdown for Agents**는 서버 측에서 에이전트가 필요한 콘텐츠를 더 간결한 Markdown 형태로 제공하는 접근이다. - Cloudflare의 **Kitesurf**는 에이전트를 일급 사용자로 고려한 브라우저로, Workers에서 요청마다 실행하고 폐기할 수 있도록 가볍게 설계되었다. - 에이전트는 인간용 브라우저의 광고, 시각 효과, 기타 불필요한 기능 없이 콘텐츠와 기능에 직접 접근할 수 있다. ## Discoverable: 에이전트가 자원을 찾는 방법 - 에이전트가 콘텐츠를 읽거나 도구를 호출하거나 결제하려면 먼저 해당 자원이 존재한다는 사실을 알아야 한다. - 인간용 검색창과 키워드 중심 검색만으로는 에이전트의 목적과 작업 흐름을 충분히 지원하기 어렵다. - **AI Search**는 공개 웹사이트가 에이전트 검색 결과에 포함되도록 지원한다. - 반대로 콘텐츠 제작자와 API 운영자는 자신의 서비스가 에이전트에게 얼마나 노출되는지도 측정해야 한다. - **AEO(Agent Engine Optimization)**는 주요 모델과 에이전트에서 브랜드나 콘텐츠가 얼마나 잘 발견되는지를 측정한다. - 고객이 사용하는 에이전트에서 발견되지 않는 서비스는 사실상 해당 고객에게 오프라인 상태가 된다. ## Callable: 웹 기능을 직접 호출하기 - 인간용 웹에서는 예약, 구독 갱신, 보고서 조회 같은 기능이 버튼과 폼으로 구현되어 있다. - 에이전트가 이를 사용하려면 HTML을 분석하고, 어떤 버튼이 작업을 수행하는지 추측하고, DOM 변화에 대응해야 한다. - **WebMCP**는 웹사이트가 브라우저 안에서 에이전트에게 기능을 명시적으로 도구로 노출하도록 한다. - 예를 들어 `add-todo` 도구는 다음 정보를 직접 선언할 수 있다. - 도구 이름과 설명 - 입력값의 JSON 스키마 - 실제 작업을 수행하는 함수 - 실행 결과 - 이 방식에서는 HTML 파싱이나 버튼 위치 추측이 필요 없다. - 도구가 페이지 내부에서 실행되므로 기존 사용자의 로그인 세션과 상태를 그대로 활용할 수 있다. - **Code Mode**는 에이전트가 자연어로 도구를 호출하는 대신 코드로 직접 호출하도록 해 정확성과 속도를 높인다. - 사이트 운영자는 에이전트가 어떤 기능과 콘텐츠를 실제로 사용하는지 명확한 호출 신호를 얻을 수 있다. ## Payable: 에이전트가 직접 지불하는 웹 - 광고 기반 모델은 에이전트가 광고를 보거나 페이지를 렌더링하지 않기 때문에 약화될 수밖에 없다. - 사용자 단위 좌석 과금도 한 명의 사람이 프로그램을 통해 작업하는 상황에는 적합하지 않다. - 에이전트가 요청마다 소액을 지불하면 기존의 페이지뷰나 광고 노출 없이도 콘텐츠 제공자가 수익을 얻을 수 있다. - 예를 들어: - 레시피 사이트는 fetch 한 건당 아주 작은 금액을 받아 수익성을 확보할 수 있다. - 지역 신문은 별도 장기 라이선스 계약이나 로그인 없이 기사 열람 시점에 과금할 수 있다. - 에이전트는 사용자가 미리 설정한 지갑과 예산을 가지고 서비스에 접근하며, 결제는 에이전트가 직접 처리한다. - 따라서 에이전틱 인터넷에서는 콘텐츠 접근 자체가 작고 자동화된 경제적 거래가 될 수 있다. ## 실용적인 시사점 웹사이트 운영자는 에이전트를 무조건 차단하거나 스크래퍼로 취급하기보다, 봇 신원 확인·에이전트용 콘텐츠 제공·명시적 도구 API·소액 결제를 함께 설계해야 한다. 특히 기존 HTML UI를 에이전트가 추측하게 두기보다는 WebMCP 같은 명시적 계약을 제공하고, 에이전트 검색 노출과 실제 호출량을 별도로 측정하는 것이 중요하다.

원문 읽기(새 탭에서 열림)
Cloudflare Workerswebmcpx402agentic-internet+2
cloudflare4분 읽기큐레이션 요약

Cloudflare AI 검색: 에이전트에게 데이터 검색 엔진을 제공하세요

Cloudflare AI Search는 Workers AI, AI Gateway, Vectorize, R2, Browser Run 등을 직접 조합하지 않아도 에이전트용 검색 엔진을 구축할 수 있도록 개발자 경험을 개선했다. 웹사이트와 파일을 쉽게 색인하고, 여러 데이터 소스를 하나의 검색 엔드포인트나 MCP 엔드포인트로 통합할 수 있으며, 임베딩과 재순위화 비용은 일부 기본 모델 사용 시 무료다. Cloudflare는 이를 자사 문서·블로그·개발자 생태계 검색과 Dev Stack MCP에 실제로 적용하고 있다. ### 에이전트용 데이터 색인 - 구조화·비구조화 데이터를 AI 에이전트가 검색할 수 있도록 색인한다. - 개별 파일뿐 아니라 소유권을 확인할 수 있는 웹사이트도 데이터 소스로 사용할 수 있다. - AI Search가 웹 크롤링, 데이터 수집, 임베딩, 검색 결과 반환 과정을 처리한다. - 현재는 Cloudflare 계정에 등록된 zone이어야 하며, 향후 소유권 확인 방식이 확대될 예정이다. ### 사이트맵 없이 웹사이트 검색 구축 - 기존에는 웹사이트 연동에 sitemap이 필요했다. - 이제 `Discover` 파싱 옵션을 사용하면 sitemap이 없는 사이트도 링크를 따라가며 페이지를 발견하고 색인할 수 있다. - 내부적으로 Browser Run의 `/crawl` 기능을 활용해 페이지를 탐색한다. - Wrangler 명령어 예시는 다음과 같다. ```bash npx wrangler ai-search instance create cloudflare-community \ --namespace dev-stack \ --source https://community.cloudflare.com \ --type web-crawler \ --parse-type discover ``` ### 여러 검색 인스턴스를 하나로 통합 - 하나의 namespace 안에 여러 웹사이트나 데이터 인스턴스를 구성할 수 있다. - `/search`와 `/mcp` 공개 엔드포인트를 활성화하면 여러 인스턴스를 한 번에 검색할 수 있다. - 별도 Worker를 작성하지 않고도 여러 소스를 대상으로 통합 검색을 제공할 수 있다. - 검색 결과에는 출처 인스턴스 정보와 인용 가능한 청크가 포함된다. ### Worker와 MCP를 통한 검색 연동 - 기존 애플리케이션이나 MCP 서버에 검색 기능을 포함하려면 namespace를 Worker에 바인딩한다. - Worker에서는 `AI_SEARCH.search()`를 호출하고, `instance_ids`로 검색 대상들을 지정한다. - `max_num_results`로 결과 수를 제한하고 `reranking.enabled`로 재순위화를 활성화할 수 있다. - Cloudflare Dev Stack MCP는 이 방식을 사용해 Docs, Blog, API Docs, Community, Astro, Vite, Vitest, Hono, Replicate, OpenNext 등 여러 표면을 한 번에 검색한다. ```json { "ai_search_namespaces": [ { "binding": "AI_SEARCH", "namespace": "cloudflare-stack" } ] } ``` - 간단히 공유 가능한 검색 URL만 필요하다면 Worker 대신 공개 엔드포인트를 활성화하면 된다. ### 공개 엔드포인트와 사용자 도메인 - namespace에 공개 URL을 활성화하면 다음 엔드포인트가 제공된다. - `/search`: 일반 검색 API - `/mcp`: MCP 클라이언트와 에이전트 연동용 엔드포인트 - 기본 공개 URL 대신 `search.example.com/mcp`처럼 사용자 정의 도메인을 연결할 수 있다. - Cloudflare Access를 도메인 앞에 배치하면 공개 엔드포인트를 인증 기반의 비공개 검색 서비스로 전환할 수 있다. ### 예측 가능한 가격 모델 - AI Search는 임베딩 및 재순위화 비용을 포함하는 방향으로 가격 모델을 설계했다. - Workers AI 카탈로그의 일부 기본 모델을 사용하면 임베딩과 재순위화가 무료다. - 토큰 수를 직접 계산해 비용을 예측해야 하는 부담을 줄이고, 데이터 규모가 커져도 비용을 예측하기 쉽게 만드는 것이 목표다. - 가격은 현재 프리뷰 단계다. ### EmDash와 Cloudflare 서비스에 적용 - Cloudflare의 오픈소스 CMS인 EmDash에는 AI Search 플러그인을 추가할 수 있다. - 이 플러그인은 EmDash로 구축한 사이트 콘텐츠에 의미 기반 검색을 제공한다. - Cloudflare는 AI Search를 Blog, Developer Docs, Cloudflare.com, EmDash 기반 사이트 등에 실제 검색 기능으로 사용하고 있다. ### Cloudflare Dev Stack MCP 사례 - Dev Stack MCP는 Cloudflare 개발자 생태계 전체에서 최신 문서를 검색해 코딩 에이전트에 제공한다. - 검색 결과에 출처와 인용 정보가 포함되어 최신 기능과 수정 사항을 반영할 수 있다. - 기존처럼 웹 검색 후 여러 페이지를 직접 가져오는 방식보다 빠르고, 토큰 사용량이 적으며, 오래되거나 부정확한 문서를 선택할 가능성이 낮다. - MCP 설정에 다음 URL을 추가하면 에이전트에서 사용할 수 있다. ```json { "mcpServers": { "dev-stack": { "url": "https://stack.mcp.cloudflare.com/mcp" } } } ``` Cloudflare AI Search는 여러 Cloudflare 서비스를 직접 연결해야 했던 검색 구축 과정을 단순화하고, 웹사이트·문서·MCP를 하나의 검색 계층으로 묶는 데 초점을 둔다. 기존 애플리케이션에 통합하려면 Worker 방식을, 빠르게 공유 가능한 검색 기능이 필요하면 공개 `/search` 또는 `/mcp` 엔드포인트를 선택하는 것이 적합하다.

원문 읽기(새 탭에서 열림)
모델 컨텍스트 프로토콜Cloudflare Workersembeddingscloudflare-access+4
cloudflare5분 읽기큐레이션 요약

순위에서 추천으로: 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 봇 방문 수를 늘리는 것보다 실제 추천과 출처 인용으로 이어지는 구조를 만드는 데 집중해야 한다.

원문 읽기(새 탭에서 열림)
모델 컨텍스트 프로토콜cloudflareoauthai-gateway+4
cloudflare3분 읽기큐레이션 요약

MCP의 차세대 기술

지난 1년 반 동안 MCP는 에이전트와 외부 서비스를 연결하는 표준이 되었지만, 기존에는 세션과 연결 상태를 유지해야 해 원격 서버 운영이 복잡했다. 2026-07-28 사양부터 MCP는 완전한 무상태 프로토콜로 바뀌어, 서버가 세션을 저장하거나 sticky session·장기 스트림을 관리하지 않아도 된다. 그 결과 MCP 서버는 Cloudflare Workers 같은 요청 단위 인프라에서 더 저렴하고 간단하게 운영할 수 있다. ## MCP의 무상태 전환 - 기존 MCP는 `initialize`와 `initialized` 교환으로 세션을 만들고, 서버가 `Mcp-Session-Id`를 발급했다. - 이후 모든 요청은 해당 세션의 상태를 찾아야 했기 때문에 다음과 같은 운영 부담이 발생했다. - 오토스케일링 환경에서 세션 보존 - sticky session을 통한 요청 라우팅 - 배포 시 세션 drain 또는 migration - 인스턴스 장애 시 재연결 및 세션 복구 - 새 사양에서는 필수 handshake와 `Mcp-Session-Id`, 프로토콜 세션이 제거됐다. - 각 요청이 MCP 버전, 클라이언트 식별 정보, 클라이언트 capability를 직접 포함한다. - 서버 정보를 미리 확인해야 하는 경우에만 선택적으로 `server/discover`를 호출한다. - MCP 자체에 상태가 필요하지 않으므로 기존 `McpAgent` 없이도 서버를 구현할 수 있다. - 애플리케이션 자체에 상태가 필요할 때는 Durable Objects를 사용할 수 있지만, MCP 프로토콜만 제공하는 서버는 Cloudflare Workers처럼 요청 단위 인프라에서 실행할 수 있다. - Cloudflare SDK에서는 기존 `McpAgent` 대신 `createMcpHandler`로 새 무상태 사양을 지원한다. ## 장기 연결이 필요 없는 Elicitation - Elicitation은 서버가 작업을 완료하기 전에 사용자 입력이나 승인을 요청하는 기능이다. - 운영 배포 승인 - 디자인 색상 선택 - 환불 확인 - 기존에는 `elicitation/create`가 열린 스트림에 의존했다. - 이 방식은 스트림 유지, 타임아웃, 비용, 로드 밸런싱을 복잡하게 만들었다. - 새 사양은 Multi Round-Trip Requests(MRTR)를 사용한다. - 서버가 `input_required` 결과를 반환한다. - 클라이언트가 사용자 입력을 수집한다. - 클라이언트가 입력값과 함께 작업을 재시도한다. - 서버가 작업을 완료한다. - 요청 사이에 연결이나 transport session을 보존할 필요가 없다. - 기존 Elicitation 방식과 호환되지 않는 breaking change이지만, 구현과 운영은 훨씬 단순해진다. ## HTTP 인프라가 MCP 요청을 직접 이해 - 기존에는 MCP 요청의 메서드와 대상이 JSON-RPC 본문 안에만 있어, 게이트웨이가 내용을 파싱해야 했다. - 새 Streamable HTTP 요청에는 다음 헤더가 필수로 추가된다. - `Mcp-Protocol-Version` - `Mcp-Method` - `Mcp-Name` - 예를 들어 도구 호출은 `Mcp-Method: tools/call`, `Mcp-Name: search`로 표현할 수 있다. - 게이트웨이, rate limiter, WAF가 JSON 본문을 해석하지 않고도 요청 종류별 정책을 적용할 수 있다. - 도구별 metrics 수집, 메서드별 rate limit, 보안 규칙 적용도 기존 HTTP 인프라 방식으로 처리할 수 있다. ## 캐시와 도구 목록 개선 - `tools/list`, `prompts/list`, `resources/list`, `resources/read` 결과에 다음 힌트가 추가된다. - `ttlMs`: 결과를 얼마나 오래 캐시할 수 있는지 나타냄 - `cacheScope`: 캐시 적용 범위를 나타냄 - 도구 카탈로그는 결정론적으로 정렬된다. - 클라이언트가 연결이 끊겼다가 다시 연결되어도 카탈로그를 재사용하기 쉬워진다. - upstream prompt cache가 불필요하게 무효화되는 문제도 줄일 수 있다. ## 인증 체계의 변화 - 새 사양은 MCP 인증 방식의 우선순위를 정비한다. - 서버와 클라이언트 사이에 사전 관계가 있다면 사전 등록된 클라이언트를 우선 사용한다. - 동적 등록이 필요하면 Client ID Metadata Documents(CIMD)를 사용한다. - Dynamic Client Registration(DCR)은 최후의 수단으로 남지만, 신규 구현에서는 deprecated되었다. ## 실용적인 결론 새 MCP 서버는 세션 저장소나 장기 연결을 기본 전제로 설계할 필요가 없다. 단순한 도구·프롬프트·리소스 서버라면 `createMcpHandler`와 요청 단위 실행 환경을 사용하고, 애플리케이션 자체에 지속 상태나 실시간 협업이 필요할 때만 Durable Objects 같은 상태ful 인프라를 선택하는 것이 권장된다.

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

Kitesurf 소개: Cloudflare Workers의 V8 격리 환경에서 실행되는 에이전트 우선 브라우저

Cloudflare는 인간이 아닌 AI 에이전트에 최적화된 브라우저가 필요하다고 판단해, Workers 위에서 동작하는 헤드리스 브라우저 **Kitesurf**를 개발했다. Chromium이 제공하는 탭·확장 기능·정밀한 시각 렌더링보다 토큰 수, 확장성, 성능, 비용, 구조화된 콘텐츠 추출을 우선하며, 일반적인 에이전트 작업에서 CPU와 메모리 사용량을 크게 줄이는 것이 목표다. Kitesurf는 Browser Run에서 베타 서비스로 무료 제공된다. ## AI 에이전트에 기존 브라우저가 과한 이유 - Chromium 같은 브라우저 엔진은 인간 사용자를 중심으로 설계됐다. - AI 에이전트에는 다음 기능의 가치가 낮다. - 탭, 테마, 브라우저 확장 기능 - 여러 기기 간 동기화 - 픽셀 단위로 정확한 렌더링 - 부드러운 60fps 스크롤 - 반대로 에이전트에는 다음 요소가 중요하다. - 적은 토큰 수와 효율적인 컨텍스트 사용 - HTML 등 구조화된 콘텐츠 - 높은 처리량과 확장성 - 낮은 CPU·메모리 사용량과 비용 - AI 브라우저의 위협 모델도 인간용 브라우저와 다르다. - 임의의 웹사이트를 방문하는 에이전트는 모든 페이지를 신뢰할 수 없는 입력으로 다뤄야 한다. - 프롬프트 인젝션과 도구 사용 안전성이 핵심 보안 문제가 된다. ## Cloudflare 플랫폼이 가능하게 한 전환점 - Kitesurf는 Cloudflare Workers 위에서 전체적으로 실행된다. - 다음 기술 발전이 복잡한 브라우저 구현을 가능하게 했다. - Workers에서의 성숙한 WebAssembly 지원 - 동적 워커 - SQLite 기반 Durable Objects - 워커 간 RPC - 서비스 바인딩 - 향상된 Node.js 호환성 - 더 높은 실행 한도 - AI 에이전트용 브라우저 자동화 수요가 커지면서, 기존 Chromium 인스턴스를 에이전트마다 제공하는 방식의 비용 문제가 부각됐다. - Kitesurf는 이러한 환경에서 더 작고 저렴한 브라우저 실행 모델을 제공하려는 시도다. ## 초기 구현과 AI 활용 - 출발점은 Rust로 작성된 AI 자동화용 헤드리스 엔진 **obscura**였다. - Cloudflare 팀은 AI 에이전트의 도움을 받아 이를 Workers로 포팅했다. - 초기 결과는 불완전했지만, 명확한 실행 계획과 성공 조건을 제공하자 AI가 반복적으로 구현·검증하며 작동하는 프로토타입을 만들 수 있었다. - 이후 프로토타입을 기반으로 실제 대규모 서비스에 필요한 구조와 품질 기준을 마련했다. ## 테스트를 중심으로 한 개발 방식 - 복잡한 브라우저를 AI의 도움으로 빠르게 개발하려면, 구현 속도뿐 아니라 결과 품질을 통제해야 했다. - 이를 위해 가능한 많은 테스트를 성공 기준으로 제공했다. - **Web Platform Tests(WPT)**를 활용해 다음을 검증했다. - 웹 표준에 대한 기능 준수 여부 - 각 브라우저 기능의 구현 상태 - AI 에이전트가 작업을 완료했는지 판단할 수 있는 명확한 기준 - WPT만으로는 실제 웹사이트에서의 동작을 충분히 검증할 수 없기 때문에 추가 테스트도 도입했다. - Chromium과 Kitesurf 양쪽에서 실제 사이트를 대상으로 Puppeteer 통합 테스트 실행 - 여러 단계의 사용자 작업과 assertion 비교 - 각 단계의 렌더링 결과를 비교하는 시각적 회귀 테스트 - 예상하지 못한 렌더링 차이를 자동으로 표시 - AI 에이전트는 기능 구현을 담당하고, 사람은 아키텍처 설계와 구현 방식 검토에 집중하는 방식이다. ## Rust와 WebAssembly 선택 - Cloudflare는 C, C++, Rust 코드를 WebAssembly로 컴파일해 Workers에서 실행할 수 있다. - Emscripten을 사용하면 많은 의존성과 모의 계층이 추가되어 결과 바이너리가 커지고 실행이 느려질 수 있다. - Kitesurf는 가능한 한 네이티브 Rust로 구현하고 `wasm-bindgen`을 통해 WebAssembly로 직접 컴파일했다. - 이를 통해 불필요한 에뮬레이션 계층을 피하고, 성능과 안정성을 높였다. ## 예외 처리와 장애 격리 - 웹페이지는 잘못된 HTML, 예상 밖의 입력, 악의적인 콘텐츠를 포함할 수 있으므로 브라우저는 일부 기능이 실패해도 세션 전체를 중단해서는 안 된다. - Kitesurf의 원칙은 다음과 같다. - 오류가 발생하면 죽은 세션 대신 빈 프레임이나 누락된 요소로 처리 - 모든 경계에서 예외를 포착 - 안전하고 비어 있는 기본값 사용 - 문제를 진단할 수 있을 만큼 충분한 로그 기록 - 목표는 페이지 일부가 손상되더라도 브라우저 요청 자체는 계속 유지하는 것이다. ## 페이지와 컴포넌트의 격리 - AI 에이전트는 작업에 따라 임의의 출처에서 코드를 실행하거나 페이지를 방문할 수 있다. - 따라서 모든 페이지 로드를 신뢰할 수 없는 입력으로 취급하고, 모든 세션을 새로 시작한다. - 각 컴포넌트는 필요한 리소스에만 접근하도록 제한한다. - Workers의 격리 모델이 기본적인 보안 경계를 제공하지만, 그것만으로 충분하지 않다. - 애플리케이션 수준에서도 컴포넌트별 접근 권한을 정의해야 한다. - 한 페이지의 데이터나 리소스가 다른 페이지로 유출되지 않도록 별도로 보장해야 한다. ## 가능한 한 무상태로 설계 - 상태가 많을수록 장애 발생 후 복구 비용이 커진다. - 무상태 컴포넌트는 다음 장점을 가진다. - 실패하면 새 인스턴스를 만들고 요청을 다시 재생하면 됨 - 필요할 때 병렬로 대량 실행 가능 - 멈춘 인스턴스를 즉시 폐기 가능 - 트래픽이 급증하는 자동화 작업에 맞춰 수요 기반으로 확장 가능 - 사용한 만큼만 비용을 지불하고 작업 종료 후 리소스를 제거 가능 - 따라서 상태가 꼭 필요하지 않은 컴포넌트는 가능한 한 무상태로 구현한다. ## 실용적인 결론 AI 브라우저는 인간용 브라우저를 그대로 축소하는 것이 아니라, 구조화된 데이터 처리·낮은 비용·높은 확장성·강한 격리를 중심으로 다시 설계해야 한다. 브라우저 자동화 서비스를 구축할 때는 표준 테스트뿐 아니라 실제 사이트 통합 테스트와 시각적 회귀 테스트를 병행하고, Rust/WebAssembly·무상태 설계·방어적인 예외 처리를 활용하는 것이 효과적이다.

원문 읽기(새 탭에서 열림)
AI 에이전트Cloudflare WorkersRustwebassembly+4