공유 ClickHouse 클러스터에서 모든 사용자에게 SQL 접근을 허용하는 방법

멀티테넌트 환경에서 SQL을 직접 열어준다고?

Trigger.dev가 자사 플랫폼 사용자들에게 공유 ClickHouse 클러스터에 대한 직접 SQL 접근 권한을 제공하는 방법에 대해 공개했습니다. 일반적으로 SaaS 제품에서 사용자에게 공유 데이터베이스의 SQL 접근을 직접 열어주는 것은 상당히 위험한 결정입니다. 한 사용자의 잘못된 쿼리가 전체 클러스터의 성능을 떨어뜨릴 수 있고, 다른 테넌트의 데이터가 노출될 수도 있기 때문입니다. 그럼에도 불구하고 Trigger.dev는 이 접근법을 선택했고, 이를 안전하게 구현하기 위해 TRQL이라는 자체 쿼리 레이어를 개발했습니다.

ClickHouse를 선택한 이유

ClickHouse는 OLAP(Online Analytical Processing)에 특화된 컬럼 지향 데이터베이스입니다. 전통적인 행 기반 데이터베이스(MySQL, PostgreSQL 등)가 개별 레코드의 읽기/쓰기에 최적화되어 있다면, ClickHouse는 대량의 데이터를 집계하고 분석하는 쿼리에서 압도적인 성능을 보여줍니다. 예를 들어 "지난 7일간 API 엔드포인트별 평균 응답 시간"같은 분석 쿼리를 수십억 행의 데이터에 대해 수 초 내에 처리할 수 있습니다. Trigger.dev는 백그라운드 작업(background job) 실행 플랫폼으로, 각 작업의 실행 로그, 성능 메트릭, 상태 변화 등 대량의 시계열 데이터가 발생합니다. 이런 데이터 특성상 ClickHouse는 자연스러운 선택이었을 것입니다.

TRQL: SQL을 안전하게 열어주는 쿼리 레이어

TRQL(Trigger Query Language)의 핵심 설계 원칙은 사용자가 익숙한 SQL 문법을 그대로 사용하면서도, 시스템 안정성과 데이터 격리를 보장하는 것입니다. 이를 위해 몇 가지 핵심 메커니즘이 작동합니다.

첫째, 자동 테넌트 격리입니다. 사용자가 작성하는 모든 쿼리에는 자동으로 해당 사용자의 조직 ID 필터가 주입됩니다. 사용자가 SELECT FROM runs WHERE status = 'failed'라고 쿼리하면, 실제로는 SELECT FROM runs WHERE org_id = '해당유저조직' AND status = 'failed'로 변환되어 실행됩니다. 사용자가 의도적으로든 실수로든 다른 테넌트의 데이터에 접근하는 것이 구조적으로 불가능합니다.

둘째, 리소스 제한(Resource Governance)입니다. 멀티테넌트 환경에서 가장 무서운 것은 한 사용자의 무거운 쿼리가 전체 클러스터를 느리게 만드는 "noisy neighbor" 문제입니다. TRQL은 쿼리별 최대 실행 시간, 스캔할 수 있는 최대 행 수, 메모리 사용량 등에 제한을 둡니다. ClickHouse 자체가 제공하는 max_execution_time, max_rows_to_read 같은 서버 사이드 설정과 함께, 쿼리 파싱 단계에서 위험한 패턴(예: 조건 없는 전체 테이블 스캔, CROSS JOIN 등)을 사전에 차단합니다.

셋째, SQL 파싱과 검증입니다. 사용자의 SQL을 단순히 문자열로 전달하는 것이 아니라, AST(Abstract Syntax Tree)로 파싱하여 허용된 테이블, 함수, 구문만 사용하는지 검증합니다. DROP, ALTER, INSERT 같은 DDL/DML 명령은 원천적으로 차단되고, 읽기 전용 SELECT 쿼리만 허용됩니다.

이 접근법이 업계에서 갖는 의미

사용자에게 직접 SQL 접근을 허용하는 것은 최근 데이터 플랫폼 업계에서 주목받는 트렌드입니다. Supabase가 PostgreSQL에 대한 직접 접근을 제공하고, Planetscale이 MySQL 호환 인터페이스를 열어주는 것과 맥을 같이합니다. 하지만 이들은 주로 사용자별로 격리된 데이터베이스를 제공하는 반면, Trigger.dev는 공유 클러스터 위에서 이를 구현했다는 점에서 기술적 난이도가 다릅니다.

비슷한 접근으로는 Rockset(Oracle에 인수됨), Apache Druid 기반의 Imply, 그리고 최근 주목받는 StarRocks 등이 멀티테넌트 실시간 분석을 제공합니다. 하지만 이들은 대부분 관리형 서비스로 쿼리 인터페이스를 자체적으로 제한하는 반면, 사용자에게 raw SQL을 그대로 열어주는 것은 상대적으로 드문 접근입니다.

한국 개발자에게 주는 시사점

내부 데이터 플랫폼을 구축하는 팀이라면 TRQL의 접근법에서 배울 점이 많습니다. 특히 사내 BI 도구나 데이터 분석 플랫폼에서 비개발 직군에게 SQL 접근을 허용해야 하는 상황은 한국 기업에서도 흔합니다. 이때 "어떻게 안전하게 SQL을 열어줄 것인가"는 항상 고민거리입니다. Redash, Metabase 같은 도구를 사용하더라도 결국 바닥에서는 비슷한 문제를 해결해야 합니다.

ClickHouse 자체도 한국에서 관심이 높아지는 추세입니다. 카카오, 네이버, 쿠팡 등 대규모 로그 분석이 필요한 기업에서 Elasticsearch의 대안으로 ClickHouse를 검토하거나 도입하는 사례가 늘고 있습니다. TRQL처럼 쿼리 레이어를 추가하여 안전한 셀프서비스 분석 환경을 구축하는 것은 실무에서 충분히 참고할 수 있는 패턴입니다.

마무리

공유 인프라 위에서 사용자에게 SQL을 직접 열어주되, 파싱·격리·리소스 제한이라는 세 겹의 안전장치로 멀티테넌트 안정성을 확보한 사례입니다. 여러분의 팀에서는 내부 사용자나 외부 고객에게 데이터 접근을 어떤 방식으로 제공하고 계신가요? SQL 직접 접근과 대시보드 기반 접근 중 어떤 것이 더 효과적이었는지 경험을 나눠주세요.