Tinybird와 직접 ClickHouse를 쓰는 것의 차이는 무엇인가요?

Tinybird는 수집·변환·API 게이트웨이·권한·버전 관리까지 운영 부담을 줄여 주는 관리형 레이어입니다. 원시 ClickHouse 운영·스케일링·보안을 직접 맡기보다 프로덕트 속도에 집중할 때 유리합니다.

실시간 대시보드는 Tinybird 안에서만 만들 수 있나요?

대시보드는 Metabase, Grafana, 자체 프론트엔드 등 HTTP API를 소비하는 도구와 조합하는 경우가 많습니다. Tinybird는 저지연 쿼리 API를 제공하는 것이 핵심입니다.

로그를 바로 넣어도 되나요?

가능하지만 스키마·파티션·TTL·샘플링·PII 마스킹 등을 Pipe와 수집 단계에서 설계하지 않으면 비용과 쿼리 성능이 급격히 나빠질 수 있습니다.

Tinybird 완벽 가이드 — 실시간 분석·ClickHouse·파이프·API·로그 파이프라인

2026년 4월 17일 · 50분 읽기 · 수정 2026년 4월 17일 중급 tutorial

이 글의 핵심

Tinybird는 ClickHouse를 기반으로 스트리밍 수집·SQL 변환·저지연 API를 한 플랫폼에서 제공하는 실시간 데이터 분석 서비스입니다. Data Source, Pipe, 엔드포인트, 대시보드 연동, 로그 분석 설계까지 한 번에 정리합니다.

이 글의 핵심

Tinybird는 이벤트·로그·메트릭을 높은 처리량으로 수집하고, ClickHouse 호환 SQL로 변환한 뒤, 밀리초 단위 지연으로 노출할 HTTP API를 만들 수 있게 하는 실시간 데이터 분석 플랫폼입니다. “데이터 레이크에 넣고 나중에 배치로 돌린다”가 아니라, 운영 중인 제품이 바로 소비할 수 있는 지표·집계 결과를 만드는 데 초점이 맞춰져 있습니다.

실무 관점: API 트래픽 로그, 결제 이벤트, 게임 텔레메트리처럼 시간에 민감한 집계(분당 오류율, 실시간 DAU 추정, 지역별 지연)가 필요할 때, 웨어하우스만으로는 대시보드 새로고침 체감이 따라오기 어렵습니다. Tinybird는 그 간극을 수집—변환—엔드포인트로 압축합니다.

들어가며: “실시간인데 왜 느리게 느껴질까?”

실무 문제 시나리오

시나리오 1: 로그는 쌓이는데 대시보드는 어제 자료다

배치 파이프라인은 신뢰도는 높지만 지연(latency) 이 큽니다. 장애 대응·A/B 판단·캐파 계획에는 초~분 단위 통찰이 필요합니다.

시나리오 2: 직접 ClickHouse를 올렸더니 운영이 본업이 됐다

스키마 마이그레이션, 샤딩, 백업, 쿼리 폭주, 권한 분리까지 플랫폼 엔지니어링이 추가됩니다. 제품 팀은 쿼리와 API 계약에 더 쓰고 싶습니다.

시나리오 3: “API 하나 주세요”가 반복된다

데이터 팀이 매번 임시 뷰·크론·스크립트를 양산하면 재현성과 버전 관리가 무너집니다. 엔드포인트 단위로 버전·토큰·문서가 있어야 합니다.

1. Tinybird란? 핵심 개념

제품이 해결하는 문제

Tinybird는 다음을 하나의 워크스페이스에서 이어 붙입니다.

구분	역할
Data Source	수집된 데이터가 랜딩하는 테이블(스키마·엔진·TTL 등 메타 포함)
Pipe	ClickHouse SQL로 변환·조인·집계하는 노드들의 유향 그래프(DAG)
Endpoint	Pipe의 최종 노드를 REST API로 노출 (쿼리 파라미터·JWT 등과 결합)
토큰·워크스페이스	운영·앱·읽기 전용 등 접근 분리

즉, “저장소 + 변환 파이프라인 + API 게이트웨이”를 관리형으로 제공합니다.

왜 ClickHouse인가

ClickHouse는 컬럼 지향·압축·벡터화 실행에 강해 시계열·이벤트 로그·집계 워크로드에 적합합니다. Tinybird는 이를 기반으로 대량 append와 집계 쿼리를 동시에 만족시키려는 설계입니다. 사용자는 표준 SQL에 가까운 문법으로 Pipe를 작성하고, 엔진 세부(머지 트리, 파티션 키 등)는 Data Source 정의에서 다룹니다.

용어 정리

Ingestion(수집): 애플리케이션·스트림·오브젝트 스토리지 등에서 이벤트 행을 Data Source로 넣는 과정입니다.
Materialized / 중간 노드: Pipe 안에서 단계별 결과를 재사용해 같은 연산을 반복하지 않도록 구성합니다(설계에 따라 Materialized View와 유사한 이점).
엔드포인트 SLA: “API가 얼마나 자주, 얼마나 빨리 응답해야 하는가”는 파티션·인덱스·사전 집계·캐시와 함께 정의됩니다.

2. ClickHouse 기반 아키텍처 이해

계층 구조(개념도)

애플리케이션과 분석 소비자 사이에 Tinybird가 끼면 대략 다음과 같습니다.

[프로듀서: 서비스·에이전트·스트림]
        │  (HTTPS / Kafka / S3 …)
        ▼
[Tinybird Ingestion] ──► [Data Source: 원시 이벤트]
        │
        ▼
[Pipe: SQL 변환 · 집계 · 조인]
        │
        ▼
[Endpoint: REST/토큰] ──► [대시보드·알림·사내 포털]

설계 시 유의할 트레이드오프

정규화 vs 폭넓은 이벤트: 로그 한 줄에 컨텍스트를 넣을수록 조인은 줄지만 스키마 변경 비용이 커집니다.
실시간성 vs 비용: 모든 이벤트를 원시 저장하면 저장 비용이 커지고, 샘플링·집계 테이블을 두면 세부 드릴다운이 제한됩니다.
동일 API, 다른 소비자: 모바일 앱은 가벼운 JSON, BI는 대용량 CSV를 원할 수 있어 엔드포인트를 쪼개 파라미터와 응답 스키마를 분리하는 편이 안전합니다.

3. Data Sources와 Ingestion

Data Source의 역할

Data Source는 “어떤 컬럼으로, 어떤 타입으로, 얼마나 오래 보관할지”를 선언하는 첫 관문입니다. 여기서 파티션 키(보통 시간), 정렬 키, TTL을 잘못 잡으면 이후 Pipe가 아무리 깔끔해도 풀 스캔이 됩니다.

Ingestion 경로(개념)

실무에서는 다음과 같은 경로가 자주 등장합니다.

HTTPS 이벤트 API: 서비스 코드에서 배치·스트림으로 POST
스트리밍 커넥터(환경에 따라 Kafka 등): 초당 많은 이벤트를 버퍼링해 적재
오브젝트 스토리지: 과거 로그 백필(backfill) 에 적합

스키마 설계 예시 (HTTP 액세스 로그)

아래는 웹/API 액세스 로그를 위한 최소 스키마 예시입니다. 실제 프로덕션에서는 request_id, user_id_hash, trace_id 등을 추가합니다.

-- 개념 예시: Data Source DDL 스타일 (워크스페이스 문법에 맞게 조정)
CREATE TABLE access_logs (
  ts DateTime64(3),
  method LowCardinality(String),
  path String,
  status UInt16,
  latency_ms UInt32,
  region LowCardinality(String)
) ENGINE = MergeTree()
PARTITION BY toYYYYMM(ts)
ORDER BY (region, ts);

설명: PARTITION BY는 월 단위 파티션으로 오래된 데이터 드롭·아카이브를 쉽게 합니다. ORDER BY는 자주 필터하는 컬럼(지역, 시간)을 앞에 두어 범위 스캔을 돕습니다. LowCardinality는 카디널리티가 낮은 문자열에 압축·속도 이점을 줍니다.

수집 단계에서의 운영 팁

이벤트 크기 제한: 거대 JSON 한 덩어리보다 필드 분해가 쿼리·압축에 유리한 경우가 많습니다.
중복 제거: 네트워크 재시도로 중복 행이 들어오면, Pipe에서 윈도우 함수나 버전 컬럼으로 멱등성을 설계합니다.
PII 분리: 이메일·전화번호는 해시·토큰화 후 적재하고, 원문은 별도 보안 저장소에 둡니다.

4. Pipes와 SQL 변환

Pipe란?

Pipe는 여러 SQL 노드로 이루어진 변환 파이프라인입니다. 앞 노드의 결과는 다음 노드에서 CTE처럼 참조합니다. 목적은 다음과 같습니다.

필터·정제: 봇 트래픽 제거, 상태 코드 범위 제한
집계: 분·시간 버킷, 지역별 카운트, 백분위(latency p95)
조인: 차원 테이블(제품 ID → 카테고리)과의 딕셔너리 조인

예시: 분당 오류율

원시 access_logs에서 5xx 비율을 구하는 개념적 Pipe입니다.

-- 노드 1: 오류만 추출
SELECT
  toStartOfFiveMinute(ts) AS bucket,
  region,
  countIf(status >= 500) AS err_cnt,
  count() AS total
FROM access_logs
WHERE ts >= now() - INTERVAL 1 DAY
GROUP BY bucket, region;

-- 노드 2: 비율 계산 (다음 노드에서 이전 결과를 참조)
SELECT
  bucket,
  region,
  err_cnt / total AS error_rate
FROM ...
WHERE total > 0;

설명: 짧은 시간 창에서는 total이 0인 버킷이 나올 수 있어 0으로 나누기를 피합니다. 윈도우 기준(5분 vs 1분)은 대시보드의 “파동” 민감도를 바꾸므로 제품·운영과 합의가 필요합니다.

SQL 작성 시 실무 체크리스트

시간 함수 통일: now(), today() 혼용 시 테스트 재현성이 떨어집니다. 가능하면 파라미터화된 시간을 엔드포인트에서 받습니다.
PREWHERE 활용: ClickHouse에서 필터가 강하면 PREWHERE가 읽기량을 줄이는 경우가 많습니다(지원 여부·버전 확인).
집계 테이블 분리: 자주 쓰는 일별 요약은 별도 Data Source로 사전 집계해 읽기 API를 가볍게 합니다.

5. API Endpoints 생성

왜 엔드포인트인가

BI 툴이든 프론트엔드든 결국 “잘 정의된 JSON을 안정적으로 가져오면” 됩니다. Tinybird는 Pipe의 결과를 HTTP 엔드포인트로 노출해 버전 가능한 계약을 만듭니다.

설계 포인트

쿼리 파라미터: from, to, region, limit 등 필터를 명시적으로 받아 캐시 키를 단순화합니다.
토큰 스코프: 읽기 전용 토큰을 대시보드에만 주고, 적재 토큰은 백엔드에만 둡니다.
응답 스키마 고정: 필드 이름을 바꿀 때 버전(/v2) 을 두어 깨지는 클라이언트를 방지합니다.

호출 예시 (개념)

curl -s \
  -H "Authorization: Bearer ${TB_READ_TOKEN}" \
  "https://api.tinybird.co/v0/pipes/error_rate_5m.json?region=ap-northeast-2&from=2026-04-17T00:00:00Z"

설명: 운영에서는 환경별 토큰과 레이트 리밋, WAF 규칙을 함께 검토합니다. 공개 대시보드라면 익명 토큰 + IP 제한 등을 고려합니다.

6. 실시간 대시보드

Tinybird의 위치

Tinybird 자체가 화려한 차트 UI에 초점을 맞춘 제품이라기보다, 저지연 데이터를 공급하는 백엔드에 가깝습니다. 따라서 실시간 대시보드는 보통 다음과 조합합니다.

Metabase / Grafana / 자체 React 대시보드: 엔드포인트를 JSON 데이터 소스로 연결
사내 포털: iframe 또는 API 프록시로 임베드

“실시간”의 의미 정하기

새로고침 주기 10초: 거의 폴링입니다. API 캐시 TTL과 맞춥니다.
WebSocket 푸시: Tinybird가 아니라 알림 레이어(예: 임계값 초과 시 슬랙)와 함께 설계합니다.

UX 팁

스켈레톤·스테일 데이터: 쿼리가 200ms 걸려도 이전 값을 유지하면 체감 실시간성이 좋아집니다.
지역·디바이스 필터: 필터 조합이 늘수록 캐시 적중률이 떨어져 사전 집계 Pipe가 필요해집니다.

7. 실전 로그 분석 시스템

목표 KPI를 먼저 고정

로그 파이프라인은 “무엇을 보여줄지” 없이 만들면 컬럼 폭발만 남습니다. 예시 KPI는 다음과 같습니다.

가용성: 5xx 비율, 지역별 에러
성능: p95/p99 지연, 타임아웃 카운트
비즈니스: 결제 실패율, 퍼널 이탈

파이프라인 단계

수집: API 게이트웨이·서비스 메시·에이전트에서 구조화 로그(JSON) 로 통일
정제 Pipe: 봇·헬스체크 제거, 샘플링 정책 적용
집계 Pipe: 분 단위 지표, 일별 롤업 Data Source로 이중 저장
엔드포인트: 운영 대시보드용 경량 JSON, 분석 팀용 상세 드릴다운 분리

알림과 연동

임계값은 엔드포인트 + 스케줄러(크론·워크플로 엔진)로 주기적으로 호출해 슬랙·PagerDuty로 보냅니다. 이때 같은 Pipe를 쓰면 대시보드 숫자와 알림 숫자가 일치합니다.

장애 시나리오

수집 지연: 큐 적체 시 이벤트 타임스탬프와 처리 시각을 분리해 재처리 가능하게 둡니다.
쿼리 폭주: 인기 대시보드는 사전 집계로 옮기고, 동시성 제한을 둡니다.

8. 모범 사례와 한계

모범 사례

스키마 버전 필드: 이벤트에 schema_version을 넣어 호환성 전환을 안전하게 합니다.
비용 가드: TTL·파티션 드롭·샘플링을 코드 리뷰 항목에 넣습니다.
문서화: 각 엔드포인트에 예시 응답·파라미터 표를 README에 남깁니다.

알아둘 한계

복잡한 트랜잭션 워크로드는 적합하지 않습니다. 이벤트·집계 중심입니다.
완전한 멀티 테넌트 격리는 토큰·네임스페이스·별 워크스페이스 설계가 필요합니다.
법규·데이터 레지던시는 리전·계정 정책을 사전에 확인해야 합니다.

9. 정리

Tinybird는 ClickHouse의 힘을 수집·변환·API로 포장해, 제품 팀이 운영 부담 대신 쿼리와 계약에 집중하게 합니다. Data Source에서 스키마와 수명을, Pipe에서 비즈니스 의미 있는 집계를, Endpoint에서 소비자별 계약을 완성하면, 실시간 로그 분석은 단순한 “로그 검색”이 아니라 운영·성장을 움직이는 계기판이 됩니다.

배포 전에는 git add → git commit → git push 후 npm run deploy를 실행하는 것이 이 저장소 규칙입니다.

참고

Tinybird 공식 문서 — 최신 커넥터·CLI·가격 정책은 공식 문서를 기준으로 합니다.
ClickHouse 문서 — SQL 함수·엔진·튜닝의 근거가 됩니다.