🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Cloudflare는 분산된 내부 데이터를 하나의 SQL 기반 데이터 레이크하우스인 Town Lake로 통합하고, 그 위에 자연어로 검증 가능한 데이터 질의를 수행하는 AI 에이전트 Skipper를 구축했다.

📌 핵심 요약

• Cloudflare는 초당 10억 건이 넘는 이벤트와 330개 이상 도시, 120개 이상 국가에 걸친 네트워크에서 발생하는 방대한 데이터를 다루지만, 과거에는 데이터가 여러 운영 DB, ClickHouse, Kafka, Google Cloud 버킷, BigQuery, 파이프라인에 흩어져 있어 접근과 해석이 어려웠다.
• 데이터 분산, 샘플링된 분석 데이터, 외부 벤더 의존, 테이블과 조인 규칙을 아는 사람에게만 의존하는 암묵지 문제가 누적되면서, Cloudflare는 내부 데이터 인프라를 단순한 백오피스 기능이 아니라 핵심 인프라로 재정의해야 했다.
• 이를 해결하기 위해 Cloudflare는 R2, Workers, Cloudflare Access, Workflows 등 자사 플랫폼 위에 Town Lake라는 통합 데이터 분석 플랫폼을 만들었고, Apache Trino, R2 Data Catalog, DataHub, Lifeguard, Skimmer, Transformer, Ingestion 구성요소로 데이터 검색·쿼리·권한·PII 검토·변환·수집을 통합했다.
• Town Lake는 기본적으로 민감 데이터 노출면을 줄이기 위해 ‘기본 차단, 검토 후 허용’ 방식을 택했으며, Skimmer가 PII를 자동 탐지하고 Lifeguard가 접근 정책을 관리하며, 사용자는 필요한 경우 셀프서비스 방식으로 검토나 권한 요청을 진행할 수 있다.
• Skipper는 Town Lake 위에서 작동하는 대화형 AI 데이터 에이전트로, 사용자의 자연어 질문을 받아 DataHub에서 관련 테이블과 메타데이터를 찾고 SQL을 작성·실행하며, 결과가 이상할 경우 폐루프 방식으로 조사와 수정을 반복해 감사 가능한 답변과 차트, 대시보드를 제공한다.

🧩 주요 포인트

1. Cloudflare는 초당 10억 건이 넘는 이벤트와 330개 이상 도시, 120개 이상 국가에 걸친 네트워크에서 발생하는 방대한 데이터를 다루지만, 과거에는 데이터가 여러 운영 DB, ClickHouse, Kafka, Google Cloud 버킷, BigQuery, 파이프라인에 흩어져 있어 접근과 해석이 어려웠다.
2. 데이터 분산, 샘플링된 분석 데이터, 외부 벤더 의존, 테이블과 조인 규칙을 아는 사람에게만 의존하는 암묵지 문제가 누적되면서, Cloudflare는 내부 데이터 인프라를 단순한 백오피스 기능이 아니라 핵심 인프라로 재정의해야 했다.
3. 이를 해결하기 위해 Cloudflare는 R2, Workers, Cloudflare Access, Workflows 등 자사 플랫폼 위에 Town Lake라는 통합 데이터 분석 플랫폼을 만들었고, Apache Trino, R2 Data Catalog, DataHub, Lifeguard, Skimmer, Transformer, Ingestion 구성요소로 데이터 검색·쿼리·권한·PII 검토·변환·수집을 통합했다.
4. Town Lake는 기본적으로 민감 데이터 노출면을 줄이기 위해 ‘기본 차단, 검토 후 허용’ 방식을 택했으며, Skimmer가 PII를 자동 탐지하고 Lifeguard가 접근 정책을 관리하며, 사용자는 필요한 경우 셀프서비스 방식으로 검토나 권한 요청을 진행할 수 있다.
5. Skipper는 Town Lake 위에서 작동하는 대화형 AI 데이터 에이전트로, 사용자의 자연어 질문을 받아 DataHub에서 관련 테이블과 메타데이터를 찾고 SQL을 작성·실행하며, 결과가 이상할 경우 폐루프 방식으로 조사와 수정을 반복해 감사 가능한 답변과 차트, 대시보드를 제공한다.

🧠 상세 정리

1. 초대형 네트워크가 만든 데이터 접근 문제

Cloudflare는 초당 10억 건이 넘는 이벤트를 처리하고, 330개 이상의 도시와 120개 이상의 국가에 걸친 네트워크를 운영한다. HTTP 요청, Worker 실행, R2 읽기 작업마다 데이터가 생성되지만, 그 데이터가 곧바로 활용 가능한 형태였던 것은 아니었다. 과거에는 데이터가 여러 생산 데이터베이스, ClickHouse 클러스터, Kafka 스트림, Google Cloud 버킷, BigQuery 데이터셋, 장기 파이프라인에 흩어져 있었다. 단순해 보이는 질문 하나에 답하려 해도 어떤 시스템을 봐야 하는지, 어떤 권한이 필요한지, 어떤 쿼리 언어를 써야 하는지, 데이터가 샘플링되었는지 또는 최신인지 알아야 했다. 이 때문에 데이터에서 신뢰할 수 있는 인사이트를 얻는 과정 자체가 조직적으로 큰 비용이 되었다.

2. 데이터 스프롤의 구체적 증상

Cloudflare가 겪은 문제는 단순히 데이터가 많다는 것이 아니라, 데이터가 너무 많은 장소와 형식에 흩어져 있었다는 점이었다. 고객 이슈를 조사하려는 제품 엔지니어는 계정 메타데이터를 위해 Postgres를, 분석 이벤트를 위해 ClickHouse를, 사용량 롤업을 위해 BigQuery를, 원시 로그를 위해 R2를, 실시간 신호를 위해 Kafka 토픽을 각각 확인해야 할 수 있었다. 각 시스템은 서로 다른 인증 방식, 질의 언어, 보존 정책을 갖고 있었다. 특히 대시보드에는 적절한 샘플링 데이터가 청구와 같은 정확성이 필요한 영역에는 맞지 않았다. 700M+ 이벤트를 처리하기 위해 다운샘플링하는 분석 파이프라인은 빠른 대시보드에는 적합하지만, 고객에게 청구할 사용량을 계산할 때는 잘못된 기반이 될 수 있었다.

3. 외부 의존성과 조직적 암묵지의 한계

이전 내부 리포팅 스택의 일부는 외부 벤더에 의해 구동되었고, 이는 비용뿐 아니라 중요한 내부 데이터에 대해 다른 클라우드에 의존해야 한다는 문제를 만들었다. 또한 데이터를 찾는 일 자체가 어려웠다. 필요한 자격 증명을 모두 갖고 있더라도, 예를 들어 ‘계정별 청구 가능한 Workers 요청’을 구하려면 특정 ClickHouse 클러스터의 특정 스키마와 특정 Postgres 차원 테이블, 그리고 잘 알려지지 않은 고객 ID 변환 규칙까지 알아야 했다. 이 지식은 시스템에 명확히 기록되어 있기보다는 사람들 사이의 암묵지로 남아 있었다. Cloudflare는 데이터 인프라가 사업을 보조하는 백오피스 기능으로 취급되어 온 문화적 문제도 함께 인식했다.

4. Town Lake와 Skipper의 목표

Cloudflare는 적절한 권한과 업무상 필요가 있는 누구나 회사 데이터에 대해 답을 얻을 수 있는 하나의 장소를 만들고자 했다. 그 장소는 분기별 매출 상위 고객, 특정 조건의 Bot Management ML 스코어링 이벤트, 일정 지출 이상 고객의 주요 청구 지원 티켓 같은 다양한 질문을 다룰 수 있어야 했다. 동시에 청구나 보안 조사처럼 정확성이 중요한 경우에는 신선하고 정확하며 샘플링되지 않은 데이터를 제공하고, 대시보드나 탐색처럼 속도가 중요한 경우에는 빠르고 다운샘플링된 데이터를 제공해야 했다. 보안과 거버넌스도 처음부터 내장되어야 했고, PII 자동 탐지, 기본 잠금, 감사 가능한 접근, 시간 제한 권한 부여가 요구되었다. 마지막으로 SQL을 모르는 직원도 데이터를 활용할 수 있어야 했고, 이 요구가 Skipper로 이어졌다.

5. Town Lake의 레이크하우스 아키텍처

Town Lake의 핵심 구조는 객체 스토리지에서 데이터를 읽는 쿼리 엔진과, 그 스토리지를 데이터베이스처럼 다루게 하는 메타데이터 계층으로 구성된 데이터 레이크하우스다. 쿼리 엔진으로는 Apache Trino를 선택해 Postgres 테이블, ClickHouse 테이블, R2 위 Iceberg 테이블을 하나의 SQL 쿼리에서 조인할 수 있게 했다. 예를 들어 Workers 요청 기준 상위 유료 고객을 찾는 쿼리는 ClickHouse에 필터를 푸시하고, Postgres의 계정 차원과 조인하며, R2의 청구 롤업과 함께 순위를 계산할 수 있다. R2 Data Catalog는 관리형 Apache Iceberg 서비스로서 스키마 진화, 타임트래블, 파티션 진화, 데이터 압축을 지원한다. 오래된 데이터는 분 단위에서 시간 단위, 일 단위로 점진적으로 압축되면서 비용을 낮추되 계속 질의 가능하게 유지된다.

6. 메타데이터, 권한, PII, 변환, 수집 계층

Town Lake는 단순한 쿼리 엔진이 아니라 여러 내부 구성요소가 결합된 플랫폼이다. DataHub는 모든 테이블, 컬럼, 소유자, 계보, 용어를 담는 메타데이터 카탈로그로, 사용자가 특정 테이블에 무엇이 있는지 물으면 설명, 컬럼 정보, 소유 팀, 상·하류 테이블 정보를 제공한다. Lifeguard는 D1에 접근 규칙을 저장하고 내부 접근 관리 시스템에서 사용자와 그룹 정보를 가져와 Trino가 읽을 JSON 정책을 만든다. Skimmer는 모든 테이블과 컬럼에서 샘플을 지속적으로 검사해 Workers AI로 PII 여부를 분류하고, 필요하면 테이블 전체 맥락과 Trino 질의를 활용하는 2차 검증을 수행한다. Transformer는 Workflows 기반 ELT 엔진이며, Ingestion은 운영 시스템에서 데이터를 추출해 Parquet로 변환하고 R2의 Iceberg 테이블로 적재하는 다리 역할을 한다.

7. 기본 차단 방식의 보안 모델

통합 데이터 플랫폼은 강력한 만큼 민감 데이터 노출면도 커질 수 있다. Cloudflare는 ‘일단 열고 나중에 제한’하는 전통적 접근 대신, 검토 전에는 쿼리할 수 없도록 막는 방식을 택했다. 새 데이터베이스가 Trino에 연결되거나 새 테이블이 만들어지면 Skimmer가 이를 스캔하고 컬럼을 분류한 뒤 중앙 허용 목록에 보류 상태로 등록한다. 리뷰어가 테이블과 특정 컬럼을 승인하기 전까지 사용자는 해당 데이터를 질의할 수 없다. 이 과정이 지나치게 느리지 않도록 자동 분류가 명백한 PII와 비명시적 민감 데이터를 잡아내고, 리뷰어는 승인·재정의·거부를 빠르게 결정한다. 또한 권한이 없을 때 단순한 거부 메시지 대신 검토 요청 링크를 제공하며, Skipper는 적절한 RBAC 그룹도 제안할 수 있다.

8. Skipper: 자연어에서 검증 가능한 데이터 답변까지

Skipper는 SQL과 수많은 테이블 지식을 모르는 사용자도 데이터를 활용하게 하기 위한 대화형 AI 에이전트다. 사용자가 ‘지난 30일 R2 스토리지 비용 상위 10개 고객과 이전 30일 대비 변화’를 묻는다면, Skipper는 DataHub 검색으로 관련 테이블을 찾고 스키마와 계보를 가져온 뒤 SQL을 작성하고 Trino에 제출해 결과를 표나 차트로 보여준다. 이어서 ‘지역별로 나누고 내부 Cloudflare 계정은 제외해 달라’고 하면, 이전 문맥을 유지한 채 쿼리를 수정하고 다시 실행한다. 조인 결과가 0행이거나 필터가 예상과 다르게 작동하는 등 이상 징후가 있으면 Skipper는 조사하고 조정한 뒤 다시 시도한다. 또한 Skipper는 차트를 내부 공유용 대시보드로 묶거나 Transformer와 Lifeguard 관련 도구를 통해 변환 그래프와 권한 확인도 지원한다.

9. LLM을 데이터 에이전트로 쓰기 위한 접지 전략

Cloudflare는 초기 실험에서 LLM이 테이블 이름 목록과 SQL 프롬프트만 받으면 조인을 환각하거나 컬럼을 잘못 사용하고, 완전히 틀린 숫자를 자신 있게 낼 수 있음을 경험했다. 이를 줄이기 위해 Skipper는 검색 시점에 끌어올 수 있는 여러 층의 접지된 맥락을 사용한다. 첫 번째 층은 DataHub가 가진 스키마와 사용 메타데이터로, 모든 컬럼, 타입, 기본키, 외래키, 그리고 과거 쿼리 패턴상 자주 함께 조인된 테이블 정보를 포함한다. Skipper의 search_datasets와 get_entity_details 도구는 이 정보를 직접 노출한다. 원문은 이어서 사람의 주석을 두 번째 층으로 소개하기 시작하지만, 제공된 본문은 해당 설명 도중 끊겨 있어 그 이상의 세부 내용은 확인할 수 없다.

🧾 핵심 주장 / 시사점

• Cloudflare의 접근은 데이터 플랫폼의 핵심 문제가 저장소나 쿼리 성능만이 아니라, ‘누가 어떤 데이터를 어떤 근거로 신뢰하고 사용할 수 있는가’라는 거버넌스 문제임을 보여준다.
• Skipper 사례에서 중요한 점은 자연어 인터페이스 자체보다, AI가 DataHub, Lifeguard, Trino 같은 실제 시스템 맥락에 접지되어 검증 가능한 행동을 반복하도록 설계했다는 점이다.
• Town Lake의 ‘기본 차단, 검토 후 허용’ 모델은 통합 데이터 플랫폼이 커질수록 보안과 사용성을 동시에 고려해야 하며, 자동화와 셀프서비스 흐름 없이는 엄격한 거버넌스가 조직 생산성을 떨어뜨릴 수 있음을 시사한다.

✅ 액션 아이템

• 원문에서 강조한 핵심 변화와 이해관계자를 기준으로 How we built Cloudflare의 영향을 정리한다.
• 다음 의사결정이나 제품/정책 판단에 연결될 수 있는 근거를 원문 문장과 함께 기록한다.
• 기사에서 제시한 수치·사례·제약 조건을 분리해 과장 없이 검토한다.
• 후속 모니터링이 필요한 발표·제품·정책 변화가 있는지 출처 링크를 기준으로 추적한다.

❓ 열린 질문

• Cloudflare can fix it now.]]" "162. 이 변화가 실제 사용자나 조직의 선택 기준을 어떻게 바꿀까?
• The internet is being rebuilt for machines TechCrunch" "178. 이 근거가 다른 산업이나 지역에서도 동일하게 적용될 수 있을까?
• VoidZero is joining Cloudflare" "170. 기사에서 아직 검증되지 않은 전제나 리스크는 무엇일까?
• Agents that remember introducing Agent Memory" "[[223. 후속 발표나 데이터가 나오면 어떤 지표를 먼저 비교해야 할까?