Cloudflare가 자체 기술 스택 위에 구축한 통합 데이터 플랫폼 'Town Lake'와 AI 에이전트 'Skipper'를 공개했다. 초당 10억 개 이상의 이벤트를 처리하는 글로벌 네트워크에서 산재된 데이터를 SQL 인터페이스로 통일하고, 일반인도 자연어 질문으로 답을 얻을 수 있게 한 것이 특징이다.

Cloudflare는 공식 블로그를 통해 "수년간 데이터가 수십 개의 운영 데이터베이스, ClickHouse 클러스터, Kafka 스트림, Google Cloud 버킷, BigQuery 데이터세트 등 여러 시스템에 흩어져 있었다"며 "단순한 질문에 답하기 위해 어떤 시스템을 사용할지, 어떤 쿼리 언어를 쓸지 알아야 했던 문제를 해결했다"고 밝혔다.

데이터 스프롤의 늪에서 벗어나다

대규모 성장 과정에서 Cloudflare가 직면한 문제는 일반적이면서도 심각했다.

첫째, 시스템의 다양성. 한 명의 엔지니어가 고객 이슈를 조사하려면 계정 메타데이터는 Postgres에서, 분석 이벤트는 ClickHouse에서, 사용량 집계는 BigQuery에서, 원본 로그는 R2에서 조회해야 했다. 각 시스템은 서로 다른 접근 자격증, 쿼리 언어, 데이터 보존 정책을 가지고 있었다.

둘째, 샘플 데이터의 한계. 초당 7억 개 이상 이벤트를 처리하기 위해 분석 파이프라인은 데이터를 다운샘플링한다. 대시보드 로딩에는 최적이지만, 청구 시스템처럼 정확한 데이터가 필요한 도메인에는 부적절했다.

셋째, 부족한 데이터 거버넌스. 직원이 필요한 테이블이 어느 클러스터의 어느 스키마에 있으며, 어떤 고객 ID 변환이 필요한지 알기 위해서는 '부족한 지식'에 의존해야 했다. 조직 전체의 데이터 인프라가 '백오피스 기능'으로 취급되었던 것이다.

통합 데이터 플랫폼 아키텍처

Cloudflare는 이 문제를 'Town Lake'라는 데이터 레이크하우스 아키텍처로 풀었다. 핵심 구성 요소는 다음과 같다.

쿼리 엔진 — Apache Trino: Postgres 테이블, ClickHouse 테이블, R2의 Iceberg 테이블을 중간 결과를 구체화하지 않고도 한 번의 SQL 쿼리로 조인할 수 있다. "이번 주 Workers 요청이 가장 많은 상위 100개 고객" 같은 질문은 Trino가 자동으로 필터를 ClickHouse로, 계정 정보를 Postgres로, 청구 정보를 R2로 푸시하여 한 번에 응답한다.

R2 데이터 카탈로그: Cloudflare의 관리형 Apache Iceberg 서비스. 스키마 진화, 시간 여행(과거 데이터 조회), 파티션 진화를 지원한다. 지난주 분 단위 데이터는 시간 단위로, 지난분기 시간 단위 데이터는 일 단위로 자동 압축되면서도 쿼리 가능하다. 저장 비용은 데이터 오래됨에 따라 감소한다.

DataHub: 메타데이터 카탈로그. 모든 테이블, 컬럼, 소유팀, 데이터 계보(lineage), 용어 정의가 저장된다. 사용자가 "townlake.dim.accounts에 뭐가 있나?"라고 물으면 테이블 설명, 컬럼 설명, 소유팀, 상위/하위 테이블 정보가 즉시 반환된다.

Lifeguard: 접근 제어 서비스. 내부 정책을 D1 데이터베이스에 저장하고, 사용자·그룹 권한을 실시간으로 동기화하여 JSON 정책으로 변환. Trino가 이를 읽으면서 쿼리 시점이 아닌 진입 시점에 접근을 차단한다.

Skimmer: PII(개인식별정보) 검출 스캐너. 모든 테이블의 모든 컬럼을 지속적으로 샘플링하고 Workers AI로 분류한다. 첫 번째 패스에서는 빠른 컬럼별 분류를, 필요하면 두 번째 패스에서 전체 테이블 맥락을 고려하여 재검증한다.

Transformer: ELT(추출-적재-변환) 엔진. 사용자가 YAML로 SQL 변환 작업의 방향성 비순환 그래프(DAG)를 정의하면, Workflows가 의존성을 따라 자동 실행한다.

AI 에이전트로 'SQL 장벽' 무너뜨리다

이 플랫폼 위에 Cloudflare는 'Skipper'라는 AI 데이터 에이전트를 구축했다. 누구든 자연어로 "상위 100개 고객 매출 현황", "지난 48시간 Bot Management ML 점수 0.9 이상인 이벤트 모두 찾기" 같은 질문을 하면 Skipper가 SQL로 변환해 정확한 답을 몇 초 안에 반환한다.

이것이 중요한 이유는 데이터 인프라가 더 이상 '분석팀의 도구'가 아닌 **'전사 인프라'**가 되었다는 점이다. 영업 담당자, 고객 지원팀, 보안 담당자 모두가 적절한 권한 하에서 필요한 데이터에 접근할 수 있다.

Cloudflare의 전략적 선택: '자사 제품 기반 구축'

특히 주목할 부분은 Cloudflare가 AWS, Google Cloud, Databricks 같은 외부 솔루션 대신 자신의 제품(R2, Workers, Access, Workflows, D1)으로 이 모든 것을 구축했다는 점이다.

이는 단순한 내부 활용을 넘어 **'제품 검증'**의 성격을 띤다. 자신들이 고객에게 판매하는 인프라로 대규모 데이터 워클로드를 직접 처리해본 것이다. 문제가 발견되면 제품팀이 즉시 해결할 수 있고, 고객에게 "우리도 이 환경에서 대규모 시스템을 구축했다"는 신뢰를 줄 수 있다.

또한 외부 클라우드 제공자에 대한 의존도 감소도 전략이다. 청구·보안 조사 같은 중요 데이터를 자사 플랫폼에서 완전히 관리함으로써 외부 의존성을 최소화했다.

남은 과제: 데이터 거버넌스의 지속성

Town Lake와 Skipper는 훌륭한 기술적 해결책이지만, 근본적으로는 조직 문화의 변화를 요구한다. 데이터 인프라가 '백오피스'가 아니라 '핵심 상품'이라는 인식의 전환이 필요하다. PII 검출, 접근 제어, 감사 로그 같은 거버넌스 체계가 얼마나 견고한지, 그리고 조직 전체가 그것을 신뢰하는지가 성공의 열쇠다.

Cloudflare의 사례는 초대형 인프라 회사들이 데이터 분산 문제를 어떻게 푸는지를 보여준다. 기술만큼이나 조직의 의지와 장기적 투자가 중요하다는 점도 함께.