AI는 데이터 플랫폼 위에 얹히는 또 하나의 워크로드가 아니라, 모든 기존 사용 사례 전반에서 워크로드 기대치를 근본적으로 바꾸고 있다.
AI는 데이터 플랫폼 위에 얹히는 또 하나의 워크로드가 아닙니다. AI는 모든 기존 사용 사례 전반에서 워크로드 기대치를 근본적으로 바꿉니다.
지금 일어나고 있는 세 가지 큰 변화는 다음과 같습니다. 1) 애플리케이션이 에이전트화(agentic)되고, 2) 분석 인터페이스가 대화형이 되며, 3) 관측 가능성(Observability)이 정적 대시보드에서 AI 주도 조사로 이동하고 있습니다. 각 경우에서 기반 데이터 요구사항은 높은 동시성, 실시간 쿼리 성능, 그리고 규모 있는 완전 충실도(full-fidelity) 데이터로 수렴합니다.
이는 기존 데이터 플랫폼이 설계될 때 염두에 두었던 요구사항이 아닙니다. 앞으로 몇 년 동안의 데이터 플랫폼 선택은 무엇이 가능한지를 좌우할 것입니다. 팀이 얼마나 빠르게 움직일 수 있는지, 어떤 제품을 만들 수 있는지, 비즈니스가 어떤 인사이트에 접근할 수 있는지가 달라집니다. 지금 던질 가치가 있는 질문은 단지 현재 플랫폼이 오늘의 워크로드를 처리하느냐가 아니라, AI 기반 애플리케이션이 실제로 요구하는 것에 맞는 올바른 토대인지입니다.
이전 글에서 저는 클라우드 데이터 웨어하우스의 언번들링(unbundling) — 인터랙티브하고 고객 대면(customer-facing) 애플리케이션으로의 전환이 배치 지향 웨어하우스와 실시간 워크로드 간의 아키텍처 불일치를 어떻게 드러냈는지 — 에 대해 썼습니다. 여기서 제가 설명하려는 것은 그 교란의 다음 물결이며, 세 가지 시장(실시간 분석, 데이터 웨어하우징, 관측 가능성) 전반에서 일어나고 있습니다.
이해관계자: 차세대 사용자 대면 및 AI 기반 애플리케이션을 만드는 개발자
Postgres는 행 지향 트랜잭션 데이터(row-oriented transactional data)를 다루는 능력이 뛰어나 현대적인 사용자 대면 애플리케이션을 구축하는 기본 데이터베이스가 되었습니다. 이는 애플리케이션이 진정으로 데이터 집약적(data-intensive)으로 변하기 전까지는 잘 작동했습니다. 실시간 대시보드, 사용 분석, 고객 대면 지표, 초당 수백만 행의 이벤트 스트림이 이를 견인했습니다. 이러한 점점 더 분석적인 워크로드에서 Postgres만으로는 확장이 멈췄습니다. 쿼리는 너무 느렸고, 인덱스는 너무 비쌌으며, 동시성은 너무 낮았습니다.
업계가 도달한 해법은 Postgres + ClickHouse였습니다. Postgres는 트랜잭션과 애플리케이션 상태를, ClickHouse는 분석을 담당합니다. 이 조합은 серьез한 분석 요구사항을 가진 모든 고객 대면 애플리케이션을 위한 사실상의 현대 데이터 스택이 되었습니다. ClickHouse는 분석 워크로드에 대한 명백한 선택지로 진화했습니다. 빠른 적재(ingestion), 수십억 행에서의 서브초(sub-second) 쿼리, 그리고 고객 대면 애플리케이션이 요구하는 동시성 수준에서의 효율성 말입니다. 데이터는 CDC 파이프라인을 통해 Postgres에서 ClickHouse로 이동했고, ClickHouse는 임베디드 제품 분석부터 고객 대면 대시보드까지 모든 것을 구동했습니다.
이제 AI는 이를 구동하는 현대 AI 애플리케이션과 에이전트를 구축하기 위한, 최고 수준(best-in-class)의 트랜잭션 및 분석 기반에 대한 필요를 가속하고 있습니다. AI 생성 인사이트, 이상 탐지, 추천, 제품 데이터에 대한 자연어 인터페이스를 포함한 LLM 기반 기능은 트랜잭션 쓰기와 분석 읽기 간의 더 촘촘한 피드백 루프를 요구합니다. 이것이 우리가 네이티브 Postgres + ClickHouse 데이터 스택을 구축하는 데 더 집중하는 이유입니다. 하나의 통합된 경험에서 Postgres는 트랜잭션 워크로드를, ClickHouse는 분석을 담당하며, 네이티브 확장(native extension)을 통해 엔진 수준에서 긴밀하게 통합됩니다 — 자동 데이터 복제 및 관리, 그리고 통합된 개발자 경험을 위해서입니다.
고객 대면 경험을 구축하는 플랫폼 의사결정자에게 방향은 명확합니다. 데이터스토어 계층에서 트랜잭션과 분석 역량이 모두 필요합니다. 그리고 “best of breed” 이점을 잃지 않으면서 트랜잭션과 분석 역량을 긴밀하게 통합하는 것은 개발자 워크플로를 가속하고 새로운 AI 기반 기능을 더 빠르게 출시할 수 있게 하는 추가적인 장점입니다.
이해관계자: 데이터 웨어하우징과 비즈니스 분석을 현대화하는 데이터 엔지니어링 팀
언번들링 글에서 저는 Snowflake 같은 클라우드 데이터 웨어하우스가 배치 적재, 무거운 ETL, 주기적 리포팅을 위해 아키텍처가 설계되었고, 그로 인해 인터랙티브한 고객 대면 애플리케이션에는 잘 맞지 않는다고 설명했습니다.
이제 전통적 데이터 웨어하우스의 역할은 “AI Analyst”의 등장과 함께 그들의 “주력(bread-and-butter)” 사용 사례에서도 재검토되고 있습니다. 즉, 자연어 프롬프트로 시작하는 비즈니스 분석이 애드혹 리포트와 대시보드를 포함한 다운스트림 자산을 파생시키는 것입니다.
텍스트-투-SQL 도구와 자연어 분석 인터페이스로 구동되는 에이전트 대면 분석은 실험에서 프로덕션으로 이동하고 있습니다. UX 측면의 함의는 분명합니다. 사용자는 평범한 영어로 질문하고 몇 초 안에 답을 기대합니다. 인프라 측면의 함의는 덜 분명하지만 더 중대합니다. 자연어 쿼리 하나는 SQL 쿼리 하나만 생성하는 것이 아닙니다. 사용 가능한 데이터셋을 탐색하고, 여러 병렬 가능성을 추론하는 과정에서 짧은 시간에 수십 개를 촉발할 수 있습니다. 단일 사용자 질문처럼 보이는 것이 동시성 높은 데이터베이스 쿼리의 버스트(burst)가 됩니다. 결과적으로 내부 분석가 생성 워크로드는 외부 고객 대면 워크로드처럼 보이기 시작합니다 — 높은 동시성, 낮은 지연, 인터랙티브 응답. 같은 패턴은 에이전트가 문제를 해결하면서 의사결정의 근거가 될 올바른 데이터 포인트를 찾기 위해 데이터 플랫폼을 자율적으로 쿼리하는 경우에도 확장됩니다.
이는 레거시 데이터 웨어하우스 아키텍처가 전제로 삼는 가정을 뒤집습니다. Snowflake와 Databricks 같은 플랫폼은 애드혹, 배치 지향 분석을 위해 설계되었습니다. 그들의 컴퓨트 모델은 쿼리가 드물고 비인터랙티브하다는 가정에 기반합니다. 이들은 각 쿼리의 높은 동시성과 낮은 지연이 아니라, 많은 쿼리에 걸친 높은 총 처리량(throughput)을 최적화합니다. AI 분석가 경험은 쿼리를 빠르고 매우 빈번하게 만들며, 이 워크로드를 레거시 DWH 아키텍처에서 돌리면 AI 어시스턴트가 느리게 느껴질 정도의 용납하기 어려운 지연이 발생하거나, 제공 가치보다 비용이 더 빠르게 증가하게 됩니다.
ClickHouse는 이러한 요구사항에서 탁월하도록 처음부터 만들어졌습니다. 페타바이트 규모 데이터, 높은 쿼리 동시성, 서브초 응답 시간. 가끔 배치 리포트를 돌리는 분석가가 아니라, 수십억 행에 대해 인터랙티브 쿼리를 실행하는 수천 명의 동시 사용자를 서빙하도록 설계되었습니다. 알고 보니 이것이 바로 에이전트 시대가 요구하는 속성들입니다.
장기적인 플랫폼에 베팅하는 팀에게 계산은 단순합니다. AI 기반 비즈니스 분석은 미래의 가능성이 아니라 이미 여기 있습니다. 이전 시대의 배치 리포팅에 적합했던 플랫폼은 기술 요구사항을 충족하지 못합니다. 레거시 데이터 웨어하우징 시스템에서 마이그레이션하는 전환 비용(switching costs)은 현실적이지만 유한합니다. 반면, 다음 5년을 잘못된 플랫폼 위에서 보내며 경쟁사가 인터랙티브 AI 분석을 실행하는 동안 동시성 세금(concurrency tax)을 내는 비용은 더 큽니다.
이해관계자: 관측 가능성 전략을 소유하는 플랫폼 및 인프라 팀
전통적인 관측 가능성 스택은 세 가지 분리된 기둥(메트릭, 로그, 트레이스)을 중심으로 구축되며, 각각이 자체의 특화된 시스템에 저장됩니다. 이 아키텍처는 스토리지와 컴퓨트가 비쌌던 시절에는 합리적이었습니다. 비용을 통제하기 위해 메트릭은 사전 집계하고, 로그는 샘플링하며, 트레이스 보존 기간을 짧게 유지했습니다. 그 트레이드오프는 감당 가능했습니다.
AI SRE 워크플로는 두 가지 새로운 압력으로 이 모델을 교란합니다. 1) 동시성이 높은 자연어 쿼리의 대량 발생, 2) 자동화된 인시던트 트리아지, 근본 원인 분석(root cause analysis), 이상 상관관계(anomaly correlation)를 구동하기 위해 필요한 세밀하고(high-granularity) 고카디널리티(high-cardinality)이며 장기 보존(long-retention)되는 데이터에 대한 지속적인 요구. 샘플링된 로그와 다운샘플된 메트릭은, 3일 전의 배포 이벤트와 오류 패턴을 상관시키려는 AI 에이전트에게는 유용하지 않습니다. AI 도구를 더 유능하게 만들수록 더 많은 데이터를 보관해야 하며, 기존 플랫폼의 비용 구조는 점점 더 불리하게 작동합니다.
이것이 Charity Majors가 Observability 2.0로 설명해온 핵심 변화입니다. 세 기둥 모델을 컬럼형 스토리지 엔진에 저장된 넓은 구조화 이벤트(wide structured events)를 기반으로 하는 단일 진실의 원천(single source of truth)으로 대체하는 것입니다. 어떤 질문을 할지 미리 정하고 그에 맞춰 사전 집계하는 대신, 완전 충실도의 이벤트를 저장하고 쿼리 시점에 메트릭, 트레이스, SLO를 도출합니다. 모든 현대 관측 가능성 회사는 이제 이 모델 위에 구축되어 있으며, 많은 곳이 ClickHouse를 주요 스토리지 엔진으로 사용합니다.
Datadog 같은 전통적 관측 가능성 플레이어는 여기서 진정한 “혁신가의 딜레마(innovator's dilemma)”에 직면해 있습니다. 데이터 볼륨 기반으로 가격을 매기고 플랫폼에 강한 레이트 리밋(rate-limit)을 걸기 때문에, 고객은 비용 통제를 위해 더 적은 데이터를 적재하도록 — 로그 샘플링, 메트릭 다운샘플링, 트레이스 보존 제한 — 학습되어 왔습니다. AI SRE 워크플로를 가능하게 하려면 GB당 가격을 낮춰야 하는데, 이는 비즈니스가 기반하고 있는 매출 모델을 잠식(cannibalizing)하는 일입니다. 넓은 이벤트와 컬럼형 스토리지로 재구축한다는 것은 수십 년 동안 확장해 온 특화 데이터 구조와 가격 메커니즘을 버리는 것을 뜻합니다.
반면 ClickHouse는 명확한 이유로 이 분야에 특히 적합합니다. 로그 및 이벤트 데이터에 대한 높은 압축률, 고카디널리티의 넓은 이벤트에 대한 서브초 쿼리, 프로덕션 인프라가 생성하는 적재 볼륨에서의 효율성, 그리고 GB당 데이터 적재 수수료가 아니라 컴퓨트와 스토리지에 기반한 비용 모델입니다.
이것이 또한 우리가 턴키(turnkey) 관측 가능성 스택인 ClickStack에 투자하는 이유입니다. OpenTelemetry와 ClickHouse 기반의 관측 가능성으로, 명확한 의견이 반영된 UI와 AI SRE 역량을 제공하며, 오픈 소스와 관리형 서비스로 모두 제공됩니다.
데이터 웨어하우징과 관측 가능성은 지난 10년 동안 분리된 도메인으로 취급되어 왔습니다. 구매자도, 벤더도, 스택도 분리되어 있었습니다. 그리고 역사적으로 그 분리는 어느 정도 기술적으로도 타당했습니다. 스토리지 백엔드, 사용자 인터페이스, 소비 패턴이 달랐기 때문입니다. 처음에는 온라인 존재감으로 움직이는 비즈니스가 많지 않았으므로 데이터셋조차 달랐습니다.
오늘날 이 분리는 기술적 필수라기보다 시대에 뒤떨어진 관례에 가깝습니다. 스토리지 측면에서 비즈니스 분석이든 관측 가능성이든, 사실상 모든 현대 데이터 플랫폼은 이제 오브젝트 스토어에 씁니다. 그리고 컴퓨트 엔진은 높은 동시성에서의 인터랙티브한 저지연 쿼리와 더불어 AI Analyst 또는 AI SRE 역량을 지원해야 합니다.
마지막으로, 과거에는 대부분의 팀이 관측 가능성 데이터를 순수 운영 데이터로 취급했습니다. 하지만 오늘날 현실에서는 API 호출이 구매이고, 오류는 실패한 트랜잭션입니다. 같은 진실의 원천을 보는 대신, 동일한 이벤트가 종종 두 플랫폼에, 두 팀에 의해, 그 사이에 취약한 동기화 계층을 둔 채 두 번 저장됩니다.
이를 모두 비즈니스 데이터로 재구성해, 개방형 포맷으로 한 번만 저장하고 AI Analyst와 AI SRE 도구 양쪽에서 쿼리 가능하게 만드는 팀은 그 중복을 제거하고, 어느 한 사일로만으로는 얻을 수 없었던 컨텍스트를 열어젖힙니다.
2026년의 완전한 데이터 플랫폼은 단순한 데이터베이스 그 이상입니다. AI 에이전트가 접근할 수 있게 만드는 도구, 그리고 그 에이전트가 어떻게 행동하는지 이해하기 위한 계측(instrumentation)까지 포함한 데이터베이스입니다.
두 가지가 동시에 일어나고 있습니다. 첫째, AI 에이전트가 데이터에 대한 주 인터페이스가 되고 있습니다. 사용자는 점점 SQL을 직접 작성하지 않고 자연어로 질문하며, 에이전트가 그 질문을 쿼리로 분해하고 실행한 뒤 결과를 종합합니다. 이는 데이터 플랫폼이 에이전트에게 네이티브하게 역량을 노출해야 함을 의미합니다. 즉, 바로 쓸 수 있는 UI, MCP 호환 API, 그리고 각 사용 사례마다 맞춤 통합 작업을 하지 않아도 데이터에 접근할 수 있는 에이전트 프레임워크가 필요합니다. 이것이 우리가 선도적인 오픈 소스 AI 채팅 플랫폼인 LibreChat을 인수하고, 우리가 Agentic Data Stack이라 부르는 것의 핵심 구성 요소로 만든 이유입니다. LibreChat과 ClickHouse의 결합은 팀이 에이전트 레이어를 처음부터 만들지 않고도, 데이터 위에 분석 에이전트를 턴키 방식으로 배포할 수 있게 해줍니다.
둘째, AI 에이전트가 확산될수록 그들이 어떻게 행동하는지 이해하고 거버넌스하는 일이 1급(first-order) 엔지니어링 문제가 됩니다. LLM 관측 가능성(에이전트 실행 트레이싱, 모델 성능 모니터링, 비용 추적, 다단계 에이전트 워크플로 전반의 실패 디버깅)은 선택 가능한 인프라가 아닙니다. 이는 프로덕션에서 AI를 자신 있게 운영하는 것과, POC/실험 단계에 갇히는 것의 차이입니다. 에이전트 시스템의 관측 가능성 문제는 전통적인 소프트웨어보다 더 어렵습니다. 실행 그래프는 동적이고, 입력과 출력은 고차원이며, 실패는 이진적이기보다 미묘한 경우가 많습니다. ClickHouse Cloud 위에서 실행되어 대규모 실시간 LLM 관측 가능성을 제공하는 Langfuse가 이 문제를 해결하고 있습니다.
플랫폼 의사결정자에게 결론은 명확합니다. 데이터베이스는 필요하지만 충분하지 않습니다. 전체 그림에는 에이전트 준비형 인터페이스와 LLM 관측 가능성 도구가 포함되며, 데이터 플랫폼 경험에 네이티브하게 통합되어야 합니다.
ClickHouse는 우리가 보는 바 인터랙티브 AI 기반 애플리케이션을 위한 통합 데이터 플랫폼으로 진화하고 있습니다. 트랜잭션과 분석 워크로드, 현대적 실시간 데이터 웨어하우징과 대화형 BI, 그리고 AI-SRE 주도의 관측 가능성 워크플로를, AI 네이티브 애플리케이션이 요구하는 성능과 비용 프로필로 처리하는 하나의 플랫폼입니다.
시장은 빠르게 움직이고 있으며, 다음 시대를 승리로 이끌 플랫폼은 이미 보입니다. 장기 인프라 결정을 내리는 모든 팀에게 질문은, 전환 비용이 감당 가능한 지금 올바른 베팅을 하고 있는지, 아니면 나중에 더 어렵고 더 비싼 결정을 하게 될지입니다.
