본 콘텐츠는 사용자의 편의를 고려해 자동 기계 번역 서비스를 사용하였습니다. 영어 원문과 다른 오류, 누락 또는 해석상의 미묘한 차이가 포함될 수 있습니다. 필요하시다면 영어 원문을 참조하시기를 바랍니다.
Cloudflare에서는 매초 10억 개 이상의 이벤트를 처리합니다. Cloudflare의 네트워크는 120여 개 국가의 330여 개 도시에 분포되어 있습니다. 모든 HTTP 요청, 모든 Worker 호출, 모든 R2 읽기 작업에는 데이터가 포함됩니다.
수년 동안 이 데이터에는 액세스하기가 쉽지 않았습니다. Cloudflare는 수십 개의 프로덕션 데이터베이스, ClickHouse 클러스터, Kafka 스트림, Google Cloud 버킷, BigQuery 데이터 세트, 롱테일 파이프라인에서 상주했습니다. "오늘 가입한 도메인이 트래픽 기준 상위 100대 도메인에 몇 개나 포함되어 있습니까?"와 같은 간단한 질문에 답하려면 Cloudflare의 분석가는 어떤 시스템에 문의해야 할지, 어떤 자격 증명을 사용해야 할지, 어떤 쿼리 언어를 작성할지, 바로 샘플링된 데이터, 최신 데이터, 7일이 지난 데이터 등이었습니다. 그 결과 데이터에서 정보에 입각한 인사이트를 도출하기가 어려웠습니다.
이 문제를 해결하기 위해 우리는 Cloudflare의 통합 데이터 분석 플랫폼인 Town Lake와 이 플랫폼에서 실행되는 AI 데이터 에이전트인 Skipper라는 두 가지 사내 도구를 구축했습니다. Town Lake는 Cloudflare가 알고 있는 모든 것에 대한 단일 SQL 인터페이스이고, Skiper는 Cloudflare의 누구나 평범한 영어로 질문하고 몇 초 안에 정확하고 감사 가능한 답변을 다시 받을 수 있는 단일 SQL 인터페이스입니다.
우리가 두 가지 모두를 구축한 과정은 다음과 같습니다.
고도로 성장한 회사에서 근무해 본 적이 있다면 무분별한 데이터 확장이 어떤 모습인지 잘 알 것입니다. Cloudflare 솔루션에는 몇 가지 구체적인 증상이 있었습니다.
서로 다른 시스템이 너무 많습니다. 고객 문제를 조사하려는 제품 엔지니어는 계정 메타데이터는 Postgres, 분석 이벤트는 ClickHouse, 사용량 롤업은 BigQuery, R2는 원시 로그, Kafka 주제는 실시간 신호를 쿼리해야 할 수 있습니다. 시스템마다 자체 자격 증명, 자체 언어, 자체 보존 정책이 있었습니다.
샘플링된 데이터. 대시보드에는 적합하지만, 요금 청구와 같은 도메인에는 적용되지 않습니다. 당사의 분석 파이프라인 은 초당 7억 개 이상의 이벤트를 처리하기 위해 다운샘플링합니다. 분석 대시보드를 로드할 경우에는 올바른 동작이지만, 청구서 발행에 필요한 사용량을 계산하려고 할 때는 정확히 잘못된 동작입니다.
내부 데이터에 대한 외부 종속성. 이전의 내부 보고 스택의 일부는 외부 벤더에서 제공했습니다. 비용 외에도 중요한 데이터 중 일부를 다른 클라우드에 외부적으로 의존해야 했습니다.
누구도 데이터를 찾을 수 없었습니다. 올바른 자격 증명을 모두 가지고 있더라도 "계정별 청구 대상 Workers 요청"에 대한 올바른 테이블이 특정 ClickHouse 클러스터에 있거나 특정 스키마에 있어야 하며, 특정 Postgres 차원 테이블에 조인된다는 것, 그리고 조인이 필요하다는 것 고객 ID 변환을 모호하게 만듭니다. 부족에 대한 지식이 너무 많았습니다.
우리에게는 문화적으로도 어려운 과제가 있었습니다. 데이터 인프라가 역사적으로 중요 인프라 그 자체가 아니라 비즈니스를 지원하는 백오피스 기능으로 취급되어 왔습니다.
우리는 적절한 권한과 알아야 할 사항이 있는 모든 직원이 Cloudflare에 대한 질문(“지난 분기 매출 기준 상위 100대 고객 보여주세요”, “모든 봇 관리 ML 점수 이벤트 나열”)에 답할 수 있는 공간을 만들고자 했습니다 지난 48시간 동안 특정 ASN에서 발생한 청구 지원 점수 > 0.9점입니다", "$100를 지출한 고객에게서 발생한 상위 100개 청구 지원 티켓 찾기" 등입니다.
Cloudflare는 데이터 센터가 필요한 쿼리(예: 청구, 보안 조사)에 대해서는 새롭고, 정확하며, 샘플링되지 않은 데이터를 제공하고, 필요하지 않은 쿼리(예: 대시보드, 탐색)에 대해서는 빠르고 다운 샘플링된 데이터를 제공할 수 있기를 원했습니다.
우리는 개인 식별 정보(PII)를 자동으로 감지하고 중요한 테이블은 기본적으로 잠금으로써 보안과 거버넌스를 통합하기를 원했습니다. 모든 액세스는 감사가 가능해야 하며 사용자가 데이터가 필요한 작업을 수행하고 있을 때만 데이터에 액세스할 수 있도록 시간 제한 권한을 부여해야 합니다.
우리는 스토리지용 R2, 컴퓨팅용 Workers, 인증용Cloudflare Access, 오케스트레이션용 Workflows등 Cloudflare의 자체 플랫폼에 플랫폼이 구축되기를 원했습니다. 데이터 인프라에 대규모 투자를 하려면 우리가 고객에게 판매하는 제품과 동일한 제품을 기반으로 구축될 것이었습니다.
그리고 궁극적으로는 SQL을 알 필요가 없는 인터페이스를 원했습니다. 그 목표는 분석가뿐만 아니라 적절한 권한과 알 필요가 있는 회사 직원 모두가 분석가뿐만 아니라 네트워크를 통해 흐르는 데이터 스트림을 볼 수 있도록 하는 것이었습니다.
마지막 요건이 Skiper가 되었습니다.
본질적으로 Cloudflare 데이터 플랫폼의 아키텍처는 개체 스토리지에서 읽는 쿼리 엔진과 스토리지가 데이터베이스처럼 작동하도록 하는 메타데이터 계층과 같은 데이터 레이크하우스를 갖추고 있습니다. 우리는 텍사스주 오스틴에서 이름을 따서 타운 호수라고 부릅니다.
가장 중요한 구성 요소는 다음과 같습니다.
쿼리 엔진. 하나의 SQL 쿼리로 중간 결과를 다른 시스템으로 구체화할 필요 없이 R2에서 Postgres 테이블, ClickHouse 테이블, Iceberg 테이블을 조인할 수 있습니다. "이번 주 Workers 요청별 상위 100대 유료 고객은?"을 묻는 쿼리는 ClickHouse로 필터를 푸시하고, Postgres의 계정 차원에 대해 가입하며, R2에서 청구 롤업에 대한 순위를 매기는 계획으로 컴파일되며, 이 모든 작업이 한 번에 완료됩니다.
Cloudflare의 관리형 Apache Iceberg 서비스인R2 Data Catalog는 콜드 데이터와 웜 데이터가 있는 곳입니다. Iceberg는 스키마 진화, 시간 여행, 파티션 진화, 노후화된 데이터를 압축하는 기능 등을 제공합니다. 지난주의 분당 사용량은 시간당이 되고 지난 분기의 시간당은 매일이 되는 식입니다. 데이터를 쿼리할 수 있는 상태를 유지하면서 최신성이 감소하면 스토리지 비용이 절감됩니다. R2의 Parquet 파일은 동일한 데이터를 OLAP 데이터베이스에 보관하는 것에 비해 훨씬 저렴합니다.
DataHub는 당사의 메타데이터 카탈로그입니다. 모든 테이블, 열, 소유자, 연계 에지, 용어집이 여기에 있습니다. 사용자가 "what's in townlake.dim.accounts"라고 물으면, DataHub는 테이블 설명, 열 설명, 소유 팀, 데이터를 공급하는 업스트림 테이블, 데이터를 사용하는 다운스트림 테이블 등의 답을 제공합니다.
Lifeguard는 액세스 제어 서비스입니다. 이 서비스는 D1에 액세스 규칙을 저장하고, 내부 액세스 관리 시스템에서 사용자 및 그룹 멤버십을 동적으로 가져오고, Trino가 HTTP를 통해 읽을 수 있도록 결합된 JSON 정책을 렌더링합니다. 또한 Lifeguard는 선장 및 Gateway에 기본 액세스 정보를 제공하므로 사용자가 쿼리하는 시점이 아니라 현관문에서 차단됩니다.
Skimmer는 개인 식별 정보 감지 스캐너입니다. 연속적으로 실행되고 모든 테이블의 모든 열에서 행을 샘플링하고 Workers AI를 사용하여 각 열에 PII가 포함되어 있는지 여부를 분류합니다. 이는 두 단계로 이루어집니다. 첫째, 빠른 열별 분류기입니다. 플래그가 지정된 경우, 에이전틱 두 번째 패스 결과는 DataHub와 Lifeguard의 허용 목록으로 전달되어 휴먼인더루프(human-in-the-loop) 검토가 가능하도록 합니다.
Transformer는 Cloudflare의 ELT(추출, 로드, 변환) 엔진으로, Workflows를 기반으로 구축되었습니다. 사용자는 YAML 주요 내용(대상 테이블, 구체화 모드, 종속성, 일정)으로 SQL 변환의 방향성 비순환 그래프(DAG)를 정의합니다. Transformer는 그래프를 컴파일하고 Trino에서 실행하며, Durable Objects가 관리하는 상태, R2에 정의, D1에 실행 이력을 저장합니다.
수집 은 운영 시스템에서 레이크로 연결되는 다리입니다. 오케스트레이터는 수명이 긴 Kubernetes 배포로 실행되고, 파이프라인 구성을 읽고, Postgres 또는 ClickHouse에서 추출하고, Parquet으로 변환하며, Iceberg 테이블로 R2에 로드할 수명이 짧은 Worker 작업을 생성합니다. 각 파이프라인은 전체 바꾸기 또는 증분 추가로 실행됩니다.
통합 데이터 플랫폼을 구축할 때 실제로 우려되는 점은 중요한 데이터 표면이 막 구축되어 있다는 사실입니다. 이에 대한 전통적인 답변은 기본적으로 공개되어 있고 예외로 인해 제한되는 것입니다. 모든 것에 대한 액세스를 허용한 다음 누군가가 알아차리면 중요한 테이블을 감사하고 차단할 수 있습니다.
Town Lake는 정반대의 접근 방식을 취합니다. 테이블이 검토될 때까지 쿼리를 위해 테이블에 액세스할 수 없습니다. 새 데이터베이스가 Trino에 연결되거나 새 테이블이 생성되면 Skimer는 해당 데이터베이스를 스캔하고 열을 분류한 다음 중앙 허용 목록에 보류 중으로 등록합니다. 검토자가 테이블과 그 안의 특정 열을 승인할 때까지 사용자는 이를 쿼리할 수 없습니다. 이는 고통스러울 것 같지만, 두 가지 경우를 제외하면 말입니다.
첫째, 자동화가 잘 되어 있습니다. Skimer의 분류 기준은 상당히 훌륭합니다. 명백한 개인 식별 정보(이메일, IP, 이름, 전화번호)와 명확하지 않은 중요한 데이터의 롱테일(특정 접두사와 일치하는 API 토큰, 사용자까지 다시 추적할 수 있는 불투명한 ID)을 포착합니다. 검토자는 감지된 내용을 확인하여 승인, 재정의, 거부할 수 있습니다. 대부분의 검토에는 몇 초밖에 걸리지 않습니다.
둘째, 워크플로우는 셀프 서비스입니다. 액세스 권한이 없는 테이블을 쿼리할 경우 오류 메시지는 "권한 거부됨"이 아닙니다. "이 테이블에 대한 검토가 필요합니다. 여기를 클릭하여 검토를 요청하세요."입니다. AI 에이전트인 Skipper가 요청에 적합한 RBAC 그룹을 제안하고 바로 연결해 드립니다.
Cloudflare는 스키마 검색과 데이터 액세스를 분리합니다. 사용자는 존재하는 테이블을 볼 수 있지만, 검토되지 않은 열은 DESCRIBE 및 SHOW COLUMNS, 그리고 SELECT *에서 숨겨집니다. 이 미묘한 차이는 중요합니다. 이는 검토되지 않은 새로운 열이 승인된 테이블의 나머지 부분을 기반으로 구축된 기존 대시보드를 손상시키지 않는다는 것을 의미합니다.
PII는 세션별로 옵트인입니다. 기본적으로 Trino는 민감한 글이 화면에 들어오기 전에 수정합니다. 원시 PII가 합법적으로 필요한 경우(예: 사기 조사), 세션을 켜고 권한을 검사하고, 수정이 해제됩니다. 모든 쿼리가 로그에 기록됩니다.
요즘은 쿼리 엔진만으로는 충분하지 않습니다. 수만 개의 테이블 중 쿼리할 수 있는 테이블을 아는 것, 정식 스키마를 알아야 하는 것처럼 SQL은 여전히 장벽입니다.
Skidper는 회사의 실제 데이터, 코드 및 기관 지식에 기반을 둔 자연스러운 언어 질문에서 검증된 답변으로 전환하는 대화형 AI 에이전트에 대한 Cloudflare의 입장입니다. 저희는 Town Lake와 Workers, Workers AI, Durable Objects, D1, R2, Workflows, KV 같은 개발자 플랫폼을 기반으로 구축했습니다.
인터페이스는 채팅 상자입니다. 다음과 같이 질문해 보세요.
지난 30일 동안의 R2 스토리지 비용 기준 상위 10개 고객과 이전 30일 간의 변화를 보여주세요.
스키퍼가 올바른 테이블을 찾고(DataHub 검색), 스키마와 계보를 가져오고, SQL을 작성하고, Trino에 제출하고, 결과를 폴링하고, 테이블이나 차트를 보여줍니다. 후속 조치:
이제 지역별로 분류하고, 내부 Cloudflare 계정은 무시합니다.
컨텍스트를 전달하고, 쿼리를 개선하고, 다시 실행합니다. 예를 들어 조인에서 0개의 행이 생성되거나 필터가 예상했던 내용을 제외하는 등 문제가 발생하면, 건너뛰는 기계는 폐쇄 루프 추론을 조사, 조정, 다시 시도합니다. 가장 어려웠던 점은 적절한 맥락을 파악하는 것이었습니다.
또한, Skipper는 차트를 내부적으로 공유하고 다른 내부 애플리케이션에 임베딩할 수 있는 대시보드로 패키징할 수도 있습니다. 또한, Transformer를 통해 변환 그래프를 작성하고 Lifeguard를 통해 액세스 및 권한을 확인할 수 있는 도구도 있습니다.
사용자가 어디에서든 사용자를 만납니다. 이러한 모든 도구는 Workers AI로 구동되는 내장형 에이전트 도구로 지원되는 Worker를 통해 제공됩니다. 반면에, 많은 내부 사용자는 로컬 에이전트 흐름을 통해 작업하고, Skidper의 도구는 MCP 서버를 통해 추가로 사용할 수 있습니다.
SQL 프롬프트와 테이블 이름 목록이 주어지면 LLM은 조인을 생각하고, 열을 오용하며, 완전히 잘못된 숫자를 자신 있게 생성할 수 있습니다. Cloudflare는 초기 실험을 통해 이를 뼈저리게 깨달았습니다. 이 문제를 해결하려면 검색 시 다양한 계층의 근거에 기반한 컨텍스트에서 모델을 도출할 수 있어야 합니다.
계층 1: 스키마 및 사용 현황 메타데이터. DataHub는 모든 테이블의 모든 열, 모든 유형, 모든 기본 키, 모든 외부 키를 알고 있습니다. 또한 기록된 쿼리 패턴을 기반으로 어떤 테이블이 일반적으로 조인되는지 알 수 있습니다. Skipper의 search_datasets 및 get_entity_details 도구는 이를 직접 나타냅니다.
계층 2: 인간 주석. dim.accounts를 소유한 팀이 "계정 수준 엔터티입니다. account_id당 하나의 행입니다. 모든 계정은 정확히 하나의 고객에게 속합니다(customer_id FK를 통해)" 와 같은 설명을 작성하면, 해당 설명은 DataHub에 상주하며 Skipper의 컨텍스트에 있게 됩니다. 큐레이션된 과 같은 태그는 Skipper가 스크래치 공간보다 선호해야 하는 유효성 검사된 테이블을 표시합니다.
계층 3: 코드 기반 지식. 가장 가치 있는 컨텍스트는 어떤 카탈로그에도 없습니다. 표를 생성하는 것은 SQL입니다. Transformer 파이프라인은 성공적으로 실행될 때마다 노드별 .meta.json 문서를 DataHub로 내보냅니다. 따라서 Skipper가 fct.billings_allocated를 볼 때 스키마만 보는 것이 아닙니다. 이것은 dim.accounts, dim.customers, seed.product_classification에서 빌드된 사전 조인된 팩트 테이블이며, alloc_amount 열은 billed_amount / 12 for annual; billed_amount for monthly로 계산됩니다. 이것이 정답과 자신 있게 오답을 구분하는 미묘한 차이입니다.
계층 4: 선별된 데이터 모델. Cloudflare는 청구, 고객, 계정, 영역에 대해 생각하는 방법을 사람이 쓴 짧은 문서인 작은 "데이터 모델" 페이지 세트를 유지합니다. "' 엄선된' 태그가 지정된 테이블을 선호합니다.scrap_r2 및 '내부' 태그가 지정된 테이블을 사용하지 않습니다. 자연어가 아닌 데이터 모델 용어(예: '청구 제품 수익')로 검색합니다." 이는 질문이 일치할 때 에이전트가 가져올 수 있는 MCP 리소스로 표면화됩니다.
계층 5: 런타임 자체 검사. 다른 모든 방법이 실패할 때 Skipper는 Trino에 실시간 쿼리를 실행할 수 있습니다. DESCRIBE table, SELECT DISTINCT col LIMIT 20, SELECT COUNT(*). 런타임 컨텍스트에 비용이 많으므로 거의 사용하지 않지만, 시스템의 나머지 부분을 견고하게 만드는 것은 안전망입니다.
구현은 Cloudflare와 유사한 고유한 솔루션이므로 한 가지 구체적인 구현 세부 정보를 주목할 필요가 있습니다.
도구를 사용하여 AI 에이전트를 구축할 때 표준 패턴은 프롬프트에서 도구를 정의하고, 모델이 도구를 한 번에 하나씩 호출하여, 응답을 구문 분석하고, 실행하고, 결과를 반환하도록 하는 것입니다. 이는 괜찮은 일이지만, 수식이 많다는 것입니다. 5가지 도구를 사용하는 워크플로는 5가지 모델을 왕복해야 하며, 각 단계마다 맥락을 다시 확립해야 하기 때문입니다.
MCP 서버의 경우 코드 모드를 사용합니다. 30개의 개별 도구를 정의하는 대신검색 및 실행이라는 두 가지를 노출합니다. 이 모델은 프로그래밍 방식으로 전체 도구 세트를 호출하는 JavaScript 스니펫을 작성합니다.
const datasets = await skipper.search_datasets({ query: "billing product revenue" })
const queryId = await skipper.start_query({ sql: "SELECT ..." })
const results = await skipper.fetch_results({ queryId, mode: "inject" })
return skipper.create_chart({ chartType: "bar", data: results.rows, ... })
해당 JavaScript는 WorkerLoader를 통해 샌드박스 처리된 동적 Worker 격리에서 실행됩니다. 모델은 복잡한 다단계 워크플로를 이미 아주 잘 알고 있는 언어로 한 번의 왕복으로 표현할 수 있습니다. 더 빠르고 저렴하며 생성하는 워크플로우를 코드로 감사할 수 있습니다.
Skipper가 하는 모든 일은 호출한 사용자로서 실행됩니다. 여러분에게 테이블에 대한 액세스 권한이 없으면 Skipper가 해당 테이블을 쿼리할 수 없습니다. PII를 요청하면 권한을 확인합니다. 저장한 쿼리가 팀원과 공유되는 경우, 그룹 구성원이 변경되므로 저장 시간이 아니라 보기 시 액세스 권한이 확인됩니다.
공유 대시보드는 나름의 특징이 있습니다. 단일 플레이스홀더 div와 script 태그를 통해 모든 내부 Cloudflare 도구에 임베딩할 수 있습니다.
<div data-skipper-dashboard="dash-123"></div>
<script src="https://skipper.cloudflare.com/embed.js" async></script>
iframe은 콘텐츠에 맞게 크기가 자동으로 조정됩니다. 콘텐츠 보안 정책(CSP) 프레임-상위는 기업 도메인 외부의 모든 곳에서의 임베딩을 차단합니다. Cloudflare Access에서는 여전히 iframe 콘텐츠를 차단하므로 인증되지 않은 사용자는 데이터를 확인하지 않고 iframe에서 Access 로그인 페이지를 방문합니다. 소유자가 아닌 최종 사용자는 기본 테이블과 비교하여 확인됩니다. 해당 사용자에게 액세스 권한이 없는 경우 해당 사용자에게 적절한 그룹을 지정하여 요청하도록 지정할 수 있습니다.
과금. 이것이 원래의 사용 사례였습니다. 종량제 사용자에게 정확히 얼마를 지불해야 하는지 보여주는 고객 대면 대시보드인 Cloudflare의 청구 가능한 사용량 대시보드는 Trino를 통해 쿼리된 R2의 Iceberg 테이블 세트가 그 소스를 기반으로 합니다. 대시보드의 API는 청구 시스템에서 사용하는 것과 동일한 압축 (date, account_id, metric_name, usage) 행을 가져오므로 대시보드의 숫자는 청구서의 숫자와 일치합니다.
청구 관련 쿼리는 Town Lake가 서비스하는 모든 쿼리의 53%를 차지합니다. 이는 최근 측정 기간 동안 324명의 개별 Cloudflare 직원이 수행한 91,760개의 쿼리입니다. 고객별 수익 롤업을 계산하는 데 사용되던 200~300줄짜리 기존 SQL 쿼리가 이제 다섯 줄로 단축되었습니다.
비즈니스 인텔리전스. 선장에서 이제 '수익별 상위 100대 고객' 질문은 3초 정도 걸립니다. "오늘 가입한 도메인 중 상위 100위 안에 드는 도메인 수"도 마찬가지입니다. 우리가 Jira 티켓을 제출할 때 사용한 대부분의 데이터 관련 질문도 마찬가지입니다.
보안 분석. Cloudflare 봇 관리 팀은 Town Lake를 사용하여 자율 시스템 번호 및 지역으로 필터링된 지난 48시간 동안 점수가 0.9보다 큰 ML 점수 이벤트를 쿼리합니다. 위협 연구자들은 이를 기반으로 자체 쿼리 툴킷을 구축했습니다. Trust & Security에서는 신호를 가져와 경찰 남용을 지원합니다.
고객 지원. "$100 이상을 지출한 고객에게서 발생한 청구 지원 티켓 상위 100개 찾기"는 며칠이 소요되는 프로젝트였습니다. 이제 선장 쿼리입니다.
우리를 놀라게 한 사실이 몇 가지 있습니다.
프롬프트는 적을수록 좋습니다. Skipper의 초기 버전에는 "우선, search_datasets를 사용하고, 그 다음에는 get_entity_details를 사용하고, 필요하면 list_schema_fields를 사용하세요..." 와 같이 정교하고 규범적인 시스템 프롬프트가 있었습니다. 품질이 떨어졌습니다. 이 모델은 분석 워크플로우에 대한 추론에 능숙합니다. 세세하게 관리할 필요가 없습니다. 규범적 프롬프트를 높은 수준의 지침으로 대체하고 모델이 스스로 경로를 선택하도록 했습니다. 결과도 개선되었습니다.
중복되는 도구는 독이 됩니다. 초기에는 모든 도구의 모든 변형을 노출했습니다. 세 가지 다른 "결과 가져오기" 도구, 두 가지 "검색" 도구, 여러 가지 "목록" 도구였습니다. 모델이 혼란스러워하며 모델을 잘못 호출했습니다. 연결했습니다. 이제 fetch_results 에는 세 가지 개별 도구 대신 모드 매개변수 (주입 / 표시 / 모두) 가 있습니다. 모든 도구는 단 하나의 이유 때문에 존재합니다.
의미를 포착하는 것은 메타데이터가 아니라 코드에 있습니다. 가장 큰 정확도 향상은 스키마뿐만 아니라 테이블을 생성하는 실제 SQL을 수집하기 시작했을 때 이루어졌습니다. customer_type 열은 계약, 페이고, 무료 값을 가지며 두 컨텍스트 모두에서 동일하게 보이지만, SQL은 Salesforce 데이터가 누락된 경우 customer_type이 기본적으로 페이고로 설정되어 있음을 알려줍니다. 이러한 맥락은 열 설명에 존재하지 않습니다.
메모리는 예상보다 더 중요합니다. "이와 같이 X는 필터링해야 합니다" 또는 "Y 태그가 지정된 테이블은 무시합니다"와 같은 긴 형태의 수정 작업이 있습니다. 메모리 계층이 없으면 에이전트는 모든 대화를 재발견하고 다시 학습합니다. 1개를 사용하면 팀에서 실제로 반복되는 질문을 단조롭게 개선할 수 있습니다.
지루한 인프라는 어려운 부분입니다. Trino + Iceberg는 새로운 기술이 아닙니다. 어려운 작업은 행별 액세스 제어, 기본적으로 닫힌 테이블 허용 목록, 쿼리 감사, 시간 제한 자격 증명, 개인 식별 정보 감지, 멱등 수집, 스키마 진화와 같은 지루한 작업에서 이루어집니다. 이러한 요소들은 데이터 플랫폼을 실제로 사용하기에 안전하게 만드는 요소입니다.
Cloudflare는 에이전트 표면을 확장하고 있습니다. Skipper는 이미 MCP 서버를 지원하는 모든 IDE에 MCP 서버로 통합되어 있습니다. 다음 단계는 자체 내부 채팅 및 티켓 시스템과 더 긴밀하게 통합하여 인시던트를 디버깅하거나, 프로젝트의 범위를 지정하거나, 가설 상태를 점검하는 모든 사람이 "데이터에 요청"하는 것이 자연스러운 첫 번째 조치가 되도록 하는 것입니다.
Cloudflare는 트랜스포머 파이프라인에 막대한 투자를 하고 있습니다. 목표는 Cloudflare의 모든 팀이 SQL 파일 몇 개와 .meta.json 설명으로 큐레이션된 데이터 세트를 구축하고, 이를 Workflow로 배포하고, 자동으로 예약 및 모니터링하며, DataHub와 Skipper에 추가 작업 없이 표시되도록 하는 것입니다. 아이디어는 셀프 서비스 데이터 엔지니어링으로, 셀프 서비스 소프트웨어 엔지니어링과 동일한 형태입니다.
R2 SQL, Cloudflare의 서버리스 분산 분석 쿼리 엔진은 점점 더 강력해지고 있습니다. 기능 세트가 확장되면서 Town Lake 워크플로우의 많은 부분을 Cloudflare로 옮길 계획입니다.
차세대 혁신 제품은 데이터를 보고 다른 사람은 볼 수 없는 것을 보는 사람이 이를 통해 탄생할 수 있다는 우리의 믿음에 아직도 걸림돌이 되고 있습니다. 우리가 이를 확인하는 방법은 Town Lake입니다.