에이전트가 방금 깨뜨린 40년 된 데이터베이스 규칙: LTAP가 OLTP 및 OLAP 워크로드를 통합하는 방법

조나단 카츠는 대부분의 데이터 업계가 당연하게 받아들여 온 경계선의 양쪽 모두에서 커리어를 쌓아왔습니다. 오랫동안 Postgres 기여자로 활동했으며 현재 Databricks의 수석 스태프 제품 매니저로 재직 중인 그는, 운영 시스템과 분석 시스템이 파이프라인, 복제본, 그리고 타협으로만 연결된 채 서로 다른 두 개의 세계로 작동하는 것을 지켜보았습니다.

이번 대화에서 조나단은 왜 애초에 그러한 분리가 존재했는지, 왜 AI 에이전트가 마침내 그 장벽을 허물고 있는지, 그리고 LTAP가 단일 엔진이 아닌 통합 스토리지 레이어에서 두 세계가 만나는 지점을 재고함으로써 어떻게 그 격차를 좁히는지 설명합니다.

AI 에이전트가 깨뜨린 가정

업계는 수십 년 동안 운영 데이터베이스 시스템과 분석 데이터베이스 시스템 간의 엄격한 분리를 유지해 왔습니다. 자율형 AI 에이전트의 부상이 왜 이를 깨뜨리고 있나요?

조나단 카츠: 데이터에는 두 가지 세계가 있습니다. 운영 데이터는 신용카드 결제를 처리하거나 사기를 탐지할 때 다루는 데이터입니다. 데이터를 한 줄씩 살펴보는 매우 짧고 빠른 쿼리가 특징입니다. 분석 데이터는 몇 주, 몇 달, 또는 몇 년 동안 축적해 온 데이터로, 쿼리를 실행할 때 전체 데이터 세트를 훑어보게 됩니다. 둘 다 가능한 한 빨리 답을 반환하려고 하지만, 그 방식은 완전히 다릅니다.

이러한 차이는 임의적인 것이 아닙니다. 물리적인 특성 때문입니다. 데이터를 행(row) 단위로 저장하면 단일 행에 대한 빠른 답변을 가장 신속하게 반환할 수 있습니다. 열(column) 단위로 저장하면 전체 데이터를 가장 빠르게 스캔하고 집계할 수 있습니다. 또한 설계상 분석 쿼리는 매우 큰 데이터 세트에서 답을 얻기 위해 대규모 병렬 시스템의 리소스를 모두 소모할 수 있는 반면, 운영 쿼리는 리소스를 최소한으로 소모하면서도 빠르게 답을 반환하도록 설계되었습니다. 이로 인해 데이터 시스템을 설계하고 관리하는 방식에 있어 완전히 다른 두 가지 접근법이 생겨나며, 서로 다른 종류의 최적화가 필요하게 됩니다.

Postgres는 전 세계에서 가장 널리 배포된 데이터베이스 중 하나로, 운영 워크로드에 최적화되어 있기 때문에 행 기반으로 구축되었습니다. 분석 엔진은 그 반대의 이유로 열 기반으로 구축됩니다. 이러한 근본적인 물리적 차이 때문에 두 시스템은 항상 분리되어 있어야 했으며, 운영 데이터를 분석하고 싶을 때마다 데이터를 다른 곳으로 전송해야 했습니다.

AI 에이전트의 부상은 우리가 데이터베이스에 요구하는 사항을 바꾸어 놓았습니다. 이것이 바로 에이전트가 실제로 작동하는 방식에 발맞추어 구축된 데이터베이스인 Lakebase의 아키텍처가 존재하는 이유이기도 합니다. 예를 들어, 에이전트는 사기나 이상 징후를 탐지하는 작업을 수행하며, 이러한 이벤트는 수백 밀리초 내에 발생합니다. 하지만 해당 시스템은 동시에 방대한 양의 쓰기 및 짧은 읽기 작업도 처리하고 있습니다. 단일 에이전트는 실행해야 할 쿼리가 무엇인지 알 만큼 똑똑할 수 있습니다. 하지만 안전장치가 없다면 수많은 에이전트 무리가 운영 시스템을 쉽게 마비시킬 수 있습니다.

LTAP이란 실제로 무엇인가

LTAP이란 무엇이며, 실제로 내부적으로는 어떻게 작동하나요?

조나단 카츠: LTAP(Lake Transactional/Analytical Processing)을 사용하면 데이터를 다른 곳으로 이동하지 않고, 트랜잭션을 처리하는 시스템에 부하를 주지 않으면서 실시간 운영 데이터에 대해 직접 분석 쿼리를 실행할 수 있습니다. 이는 트랜잭션 데이터와 분석 데이터를 파이프라인으로 연결된 별도의 시스템으로 강제 전송하는 대신, 단일 논리적 스토리지 레이어에 통합함으로써 가능해집니다.

내부적으로 LTAP은 Lakebase 자체의 아키텍처 덕분에 가능합니다. 즉, 레이크의 스토리지와 완전히 분리된 상태 비저장형(stateless) 및 임시(ephemeral) 컴퓨팅 덕분입니다. Neon에서 상속된 이러한 분리는, 특정 시점에 실행 중인 컴퓨팅 작업과 무관하게 영구 스토리지 레이어가 고처리량 쓰기를 처리하고 이를 주기적으로 오브젝트 스토리지로 플러시하여 영구 보존할 수 있음을 의미합니다. 해당 데이터가 이미 클라우드 스토리지에 최적화되어 있다면, Lakehouse가 이미 사용하는 것과 동일한 열 기반 포맷으로 표현하여 Apache Spark 및 SQL 같은 엔진이 이를 직접 읽고 추가 복제본 없이도 고성능 분석 읽기를 수행할 수 있도록 만드는 것은 어떨까요?

가장 어려웠던 부분은 변환 과정에서 아무것도 유실되지 않도록 보장하는 것이었습니다. Postgres는 고유한 데이터 타입과 인코딩을 가지고 있으며, Iceberg 및 Delta와 같은 오픈 포맷도 고유한 방식을 가지고 있습니다. 우리는 단 한 비트도 변경하지 않고 원래 Postgres 데이터의 정확한 물리적 표현을 보존하는 방식으로 데이터를 작성하여 Parquet 파일로 저장해야 했습니다. 이 부분이 바로 동일한 데이터의 운영 및 분석 표현을 하나로 병합할 수 있게 해준 핵심입니다. 실제로 스토리지 레이어는 두 개의 티어로 실행됩니다. 빠른 운영 액세스를 위해 데이터를 행 포맷으로 유지하는 핫(hotter) 티어와 분석 읽기를 위해 열 포맷으로 보관하는 쿨(cooler) 티어로 나뉘어, 양쪽 모두 필요한 데이터를 효율적으로 얻을 수 있습니다.

HTAP이 정체된 상황에서 LTAP이 성공하는 이유

HTAP은 수년 전에 실시간 분석을 해결하려고 시도했으나 정체되었습니다. 전통적인 HTAP이 실패한 지점에서, 레이크하우스 스토리지 레이어에서 이 작업을 수행하는 것이 성공하는 이유는 무엇인가요?

조나단 카츠: HTAP 시스템을 작동하게 만들 수는 있지만 비용이 많이 듭니다. 번거롭고 운영하기 어려우며 일반적으로 개방적이지 않습니다. LTAP 모델이 다른 점은 서버리스 운영 컴퓨팅과 서버리스 분석 컴퓨팅을 두 개의 별개 요소로 제공한다는 것입니다. 두 가지 작업을 동시에 처리하려는 단일 시스템에 비용을 지불하는 대신, 각 워크로드에 사용하는 컴퓨팅 리소스의 양을 독립적으로 정확하게 조정할 수 있습니다. 스토리지는 모든 데이터 시스템에서 저렴한 부분입니다. 컴퓨팅이 비싼 부분이죠.

이것이 바로 엔진이 아닌 스토리지 레이어를 통합해야 한다는 주장의 핵심입니다. 각 작업에 특화되고 효율적인 엔진을 그대로 유지하면서, 모든 것을 한 번에 잘해내려는 값비싼 시스템 하나를 운영하는 대신 실제로 필요한 부분에만 컴퓨팅 비용을 지불할 수 있기 때문입니다.

에이전트가 오래된 데이터를 기반으로 작동할 때 발생하는 문제

오래된 데이터를 읽고 조치를 취하기 때문에 오늘날 중단되거나 성능이 저하되는 구체적인 에이전트 기반 워크로드를 예로 들어 설명해 주세요. 실제로 어떤 문제가 발생하나요?

조나단 카츠: 사기 탐지가 가장 명확한 예입니다. 신용카드 결제는 수백 밀리초 이하의 속도로 승인됩니다. 만약 사기를 잡아내는 역할을 하는 에이전트가 몇 분 또는 몇 시간 전의 오래된 배치 복사본 데이터를 기반으로 작동한다면, 결제가 이미 완료되기 전에 문제를 잡아내기에는 너무 느립니다. 따라서 해당 에이전트가 운영 시스템에서 직접 작동하도록 해야 합니다.

하지만 운영 시스템은 지속적인 쓰기 및 짧은 읽기 스트림을 처리하고 있으며, 무거운 분석 쿼리까지 감당하도록 구축되지 않았습니다. 에이전트가 이상 징후를 확인하기 위해 고객의 전체 구매 내역을 스캔하는 쿼리를 실행한다면, 이는 정반대의 워크로드에 최적화된 시스템에 실행하기에는 비용이 많이 드는 쿼리입니다. 이로 인해 동시에 승인 대기 중인 다른 모든 결제의 성능이 저하될 수 있습니다. 또한 현대적인 아키텍처는 올바른 결정을 내리기 위해 대개 운영 및 분석 양쪽의 데이터가 모두 필요하므로, 에이전트는 두 곳 모두에서 데이터를 가져와야 합니다. 한 대의 에이전트는 이를 무리 없이 처리할 수 있을지 모릅니다. 하지만 에이전트들이 허용된 부하를 제어하는 장치가 없다면, 유사한 쿼리를 동시에 실행하는 수많은 에이전트 무리가 운영 시스템을 빠르게 마비시킬 수 있습니다.

거버넌스, 개방성 및 엔터프라이즈 활용 사례

현재 Databricks는 LTAP을 구체적으로 어떻게 구현하고 있으며, HTAP의 한계를 이미 이해하고 있는 사람에게 이를 어떻게 설명하시겠습니까?

조나단 카츠: 스토리지 메커니즘 외에 또 다른 중요한 요소는 카탈로그입니다. Lakehouse의 진정한 혁신 중 하나는 조직에 모든 데이터에 대한 중앙 집중식 통합 뷰를 제공한다는 점이었습니다. 즉, 누가 무엇에 액세스할 수 있는지, 모든 데이터에 걸쳐 일관된 정책을 적용하여 권한이 있는 그룹이 아니면 주민등록번호와 같은 정보를 읽을 수 없도록 하는 것입니다. 이는 운영 시스템에는 적용되지 않았는데, 운영 시스템은 처음부터 데이터 사일로로 구축되었기 때문입니다. 이전의 운영 데이터와 분석 데이터의 관계는 파이프라인을 구축하고 데이터를 전송한 다음에는 알아서 잘 되기를 바라는 식이었습니다. 다운스트림에서 데이터에 어떤 일이 일어나는지 아무도 책임지지 않았죠. LTAP은 이를 완전히 뒤바꿉니다. 하나의 카탈로그 아래, 하나의 통합 스토리지 모델에 모든 데이터가 존재하게 됩니다. 누군가 분석을 해야 한다는 이유로 운영 데이터가 거버넌스 경계를 벗어날까 봐 걱정할 필요가 없습니다.

이것이 개방형 기반 위에 구축되어야 하는 이유도 있습니다. Postgres는 DB-Engines 순위에서 선호도 기준 3위에 가까워지고 있습니다. 이것이 반드시 실제 도입률을 측정하는 지표는 아니지만, 트렌드가 어디로 향하고 있는지를 보여주는 강력한 신호이며 유연성과 선택의 가치를 증명합니다. 오픈 소스는 수십 년 동안 전 세계에서 가장 중요한 시스템들을 구동해 왔습니다. LTAP은 동일한 원칙을 확장합니다. Postgres 내에서도 데이터는 Postgres 시스템 간에 이동이 가능하지만, 여전히 Postgres에 종속되어 있습니다. LTAP의 통합 스토리지 레이어를 사용하면 적절한 엔진을 적용하기 위해 데이터를 이동할 필요가 없습니다. 엔진을 데이터가 있는 곳으로 가져오는 것입니다.

핵심 변화: 통합 스토리지

LTAP이 나타내는 핵심적인 변화를 한 문장으로 설명한다면 어떻게 표현하시겠습니까?

Jonathan Katz: 아주 단순화해서 말하자면 통합 스토리지입니다. 분석 분야에 있는 사람에게 이 말을 하면 거의 즉시 이해할 것입니다. 운영 분야에 있는 사람에게 말하면 무슨 뜻인지 물어볼 수도 있습니다. 하지만 아무것도 이동하지 않고, 비트 하나 바꾸지 않고 동일한 데이터의 운영 및 분석 표현을 하나로 합칠 수 있게 되면, 이전에는 피할 수 없다고 느껴졌던 많은 문제들이 해결됩니다. 단지 데이터를 브론즈(bronze)나 실버(silver) 레이어로 가져오기 위해 더 이상 파이프라인을 실행할 필요가 없습니다. 데이터가 기록되는 즉시 분석을 시작할 수 있습니다. 관점을 바꾸어 말하자면, 이는 새로운 것을 발명하는 것이라기보다는 결코 분리되어서는 안 되었을 두 세계를 다시 하나로 합치는 것에 가깝습니다. 데이터는 그냥 데이터일 뿐입니다. 데이터를 그렇게 대할수록 사람들과 이제는 에이전트들이 파이프라인을 통해 먼저 협상할 필요 없이 데이터로 작업하기가 더 쉬워집니다.

두 세계를 다시 하나로 합치기

40년 동안 운영 데이터와 분석 데이터 사이의 경계가 유지되었던 것은 스토리지의 물리적 한계 때문이었습니다. 에이전트는 그 경계가 만들어내는 지연을 감당할 수 없는 최초의 워크로드입니다. LTAP은 트랜잭션과 분석 쿼리 간의 차이를 없애려고 하지 않습니다. 동일한 데이터에 대해 두 가지를 모두 실행할 때 수반되던 비용을 제거할 뿐입니다. 에이전트 기반 워크로드에 실제로 이 패턴이 필요한지 평가하는 데이터 아키텍트에게 Jonathan이 설명하는 테스트는 유용합니다. 만약 에이전트의 다음 결정이 여전히 정리 중인 데이터(해당 데이터를 가깝고 안전하게 보호하도록 구축된 시스템에 있는 데이터)에 의존한다면, 기존의 파이프라인 및 복사 모델은 충분히 빠르지 않을 것입니다. 이것이 바로 LTAP이 해결하기 위해 고안된 구체적인 문제입니다.

LTAP에 대해 자세히 알아보려면 모놀리스에서 레이크베이스, LTAP까지: 스토리지부터 데이터베이스 다시 생각하기를 읽어보세요.

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)