![[SingleStore 가이드①] 거래와 분석, 왜 한 DB에서 처리하게 됐을까](https://www.notion.so/image/notion%3A%2F%2Fcustom_emoji%2F47e97c56-fad2-49ef-a757-4c5b8458bc95%2F222ddf18-253e-80d8-81cf-007a46c77840?table=block&id=3d5ddf18-253e-8061-99dc-eaee56b5e3c7&cache=v2&width=1200)
![[SingleStore 가이드①] 거래와 분석, 왜 한 DB에서 처리하게 됐을까](https://www.notion.so/image/attachment%3A6d17025e-ac52-439c-a79d-3850c34be32c%3Asinglestore.png?table=block&id=3d5ddf18-253e-8061-99dc-eaee56b5e3c7&cache=v2&width=1200)
분석용 DB를 별도로 두지 않는 선택
실시간 이상거래 탐지나 생산 라인 감시처럼 데이터가 발생한 즉시 판단해야 하는 업무가 늘고 있습니다. 이런 업무에서는 거래를 기록하는 데이터베이스와 분석용 데이터베이스를 별도로 운영하기 어려워집니다. 그래서 한 번에 해결하는 제품을 찾게 되고 이때 자주 언급되는 데이터베이스가 SingleStore(싱글스토어)입니다.
이름은 알려졌지만 어떤 데이터베이스인지 구체적으로 알기는 쉽지 않습니다. 검색 결과에 MemSQL이라는 옛 이름의 자료가 함께 나오고, 과거 설명인 인메모리 데이터베이스라는 소개가 지금까지 남아 있기 때문입니다.
기능 목록만 봐서는 이 제품의 성격이 잘 드러나지 않습니다. 거래 처리와 분석은 원래 서로 다른 시스템이 맡던 일인데 왜 하나로 합쳐진 제품이 나왔을까요. 이 질문은 거래 처리와 분석이 왜 나뉘어 있었는지를 보면 알 수 있습니다.
이번 글에서는 거래 처리와 분석이 나뉜 이유부터 싱글스토어가 거래 처리와 분석을 어떻게 한 번에 처리했는지 차례로 살펴보겠습니다.
1. 거래 처리와 분석을 분리해 온 이유
거래 처리와 분석이 나누어졌던 이유는 요구 성능이 반대였기 때문입니다.
주문과 결제, 회원 가입처럼 짧고 빈번한 작업을 처리하는 영역이 OLTP입니다. 주문 한 건이 들어오면 회원 테이블에서 그 회원을 찾고 재고 테이블에서 그 상품을 찾아 각각 한 줄만 바꾸면 끝납니다. 건드리는 양은 적지만 이런 요청이 쉬지 않고 들어옵니다. 그래서 수백만 줄에서 목표한 한 줄을 얼마나 빨리 찾는지가 성능을 가릅니다.
반면 지난 분기 매출을 지역별로 집계하는 작업은 OLAP입니다. 주문 테이블을 처음부터 끝까지 읽어야 하는데 수백만 줄에서 실제로 쓰는 값은 금액과 지역 두 개 열뿐입니다. 한 줄을 빨리 찾는 능력은 여기서 도움이 되지 않습니다. 성능은 수백만 줄을 얼마나 빨리 읽는지에 달려 있습니다.
OLTP(Online Transaction Processing)는 온라인 거래 처리, OLAP(Online Analytical Processing)는 온라인 분석 처리를 뜻합니다. 데이터베이스가 담당하는 작업의 성격을 구분하는 기준으로 사용합니다.
두 성능을 한 가지 구조로 함께 만족시키기는 어렵습니다. 한 줄을 통째로 붙여 두면 그 줄을 찾아 바꾸기는 쉽지만 금액 열만 읽을 때도 필요 없는 나머지 열까지 같이 읽게 됩니다. 같은 열끼리 모아 두면 읽기는 빨라지는데 한 줄을 바꾸려면 여러 곳에 나뉜 값을 하나씩 건드려야 합니다. 어느 한쪽을 빠르게 만들면 다른 쪽 성능이 떨어집니다.
그래서 두 작업을 서로 다른 시스템에 나눠 맡기는 구성이 오랫동안 표준이었습니다. 서비스에서 발생한 데이터를 운영 데이터베이스에 저장하고 ETL을 거쳐 데이터 웨어하우스로 옮긴 다음 그 시스템에서 분석하는 방식입니다.
ETL(Extract, Transform, Load)은 원본에서 데이터를 뽑아 형식을 맞춘 뒤 목적지에 적재하는 과정을 뜻합니다. 운영 데이터베이스의 데이터를 분석용 시스템으로 옮길 때 주로 씁니다.
이 구성은 오래 유지됐지만 두 가지 문제가 따라옵니다.
첫째로 판단이 늦어집니다. 배치로 옮기는 구성에서는 데이터가 생긴 시점과 분석에 반영되는 시점이 벌어져, 당일 오후 화면에 전일 데이터가 표시됩니다. 월간 마케팅 리포트라면 문제가 되지 않지만 거래 승인 여부를 판단하는 업무라면 이 시간 차이가 그대로 손실이 됩니다.
둘째로 파이프라인을 유지하는 일이 계속 남습니다. 원본 스키마가 바뀔 때마다 ETL을 수정해야 하고 두 시스템의 수치가 어긋나면 어느 쪽이 정확한지 확인하는 작업까지 붙습니다. 데이터가 늘어날수록 이 확인 작업도 함께 늘어납니다.
2. 분리하지 않는 방식, HTAP
두 시스템을 합치면 이 문제는 사라집니다. 옮기는 단계가 없어지니 시간 차이도 생기지 않고, 유지할 파이프라인도 남지 않습니다. 이렇게 합치는 방식을 HTAP(Hybrid Transactional/Analytical Processing)라고 부릅니다.
그러나 이름을 정의하는 일과 실제로 합치는 일은 다릅니다. 두 작업이 요구하는 성능이 반대이기 때문에 기존 관계형 데이터베이스에 분석 쿼리를 그대로 실행해서는 합쳐지지 않습니다. 저장 방식과 데이터를 두는 위치를 처음부터 다시 설계해야 하는데 그 설계가 제품마다 달라서 HTAP를 지원한다는 제품들도 내부 구조가 서로 다릅니다. 같은 이름을 달았다고 성능까지 비슷하리라 보기 어려운 이유입니다.
싱글스토어는 그 설계를 처음부터 다시 한 제품입니다. 거래 처리와 분석을 한 엔진에서 함께 수행하도록 만든 분산 SQL 데이터베이스로 2011년 MemSQL이라는 이름으로 출발해 2020년 10월 지금의 이름을 달았습니다. 인메모리 처리만 앞세우던 초기와 달리 디스크 기반 저장과 분석까지 범위를 넓혔고 이름도 그 변화를 따라간 것입니다.
지금의 싱글스토어를 인메모리 데이터베이스로 소개하면 정확하지 않습니다. 기본 테이블 타입은 디스크 기반 컬럼스토어이며 인메모리 로우스토어는 필요할 때 별도로 지정해 사용하는 선택지입니다.
그렇다면 요구가 반대인 두 작업을 한 엔진에서 처리하는 구조는 어떻게 만들었을까요.
3. 왜 분산 SQL 구조가 됐을까
싱글스토어의 구조는 두 요구를 동시에 받기 위해 만들어진 결과입니다. 분석 부하까지 한 엔진에서 받아야 하니 노드를 나눴고, 성능 요구가 반대이니 저장 방식을 두 가지로 두었습니다. 반면 접속 방식은 기존 관계형 데이터베이스와 똑같이 남겨 두었습니다.
데이터를 저장하고 처리하는 방법은 새로 설계했지만, 개발자가 쿼리를 보내는 방법은 손대지 않았습니다. 새로 설계한 노드 구성부터 차례로 보겠습니다.
3-1. 노드 단위 데이터 분산
노드 구성을 나눈 이유는 분석 쿼리가 읽어야 하는 데이터 양에 있습니다. 거래 처리는 특정 행만 찾아 바꾸면 끝나지만 분석은 수백만 행을 한 번에 읽어야 해서 서버 한 대의 처리 용량을 빠르게 넘어섭니다. 이 부하를 나누려고 싱글스토어는 클러스터를 역할이 다른 두 종류의 노드로 구분합니다.
① 애그리게이터(Aggregator)
쿼리를 받아 리프로 분배하고 되돌아온 중간 결과를 병합해 클라이언트에 전달합니다. 이 가운데 마스터 애그리게이터(MA)는 메타데이터와 DDL을 담당하므로 클러스터당 하나만 둡니다. 차일드 애그리게이터(CA)는 쿼리 부하를 나눠 받는 역할이어서 필요한 만큼 0개 이상 둡니다.
② 리프(Leaf)
리프는 데이터를 실제로 저장하고 연산합니다. 테이블이 통째로 들어가지 않고 파티션이라는 조각으로 쪼개져 여러 리프에 나뉘며 노드 하나가 조각 여러 개를 맡습니다. 그래서 조회 하나가 여러 노드에서 동시에 실행되고 그 결과를 애그리게이터가 다시 합칩니다.
이렇게 나눠 두면 데이터와 처리량이 늘어도 노드를 추가해 용량과 성능을 함께 늘릴 수 있습니다.
3-2. 테이블별 저장 방식 선택
노드를 나누는 것만으로는 반대인 성능 요구가 해결되지 않습니다. 단건 조회와 대량 집계를 같은 데이터베이스에서 처리해야 하니 저장 방식도 하나로 고정할 수 없습니다. 그래서 싱글스토어는 한 행을 함께 저장하는 로우스토어와, 같은 열을 모아 저장하는 컬럼스토어를 모두 제공합니다.
개별 행을 자주 바꾸는 거래 처리에는 로우스토어가 맞고 여러 행을 한꺼번에 집계하는 분석에는 컬럼스토어가 맞습니다. 어느 쪽을 쓸지는 생성 시점에 정하므로 한 데이터베이스 안에서도 테이블마다 다르게 잡을 수 있습니다. 주문은 로우스토어로, 집계용 이력은 컬럼스토어로 두는 식입니다. 로우스토어와 컬럼스토어를 함께 제공하는 이 구조를 싱글스토어는 Universal Storage라고 부릅니다.
3-3. 기존 접속 방식 유지
노드 구성에 로우스토어와 컬럼스토어 구분까지 새로 익혀야 한다면 도입 문턱이 높아집니다. 그래서 데이터를 저장하고 처리하는 방법은 새로 만들면서도 쿼리를 보내는 방법은 예전 그대로 두었습니다. 싱글스토어는 MySQL이 쓰는 통신 규약(와이어 프로토콜)을 그대로 따르므로 애플리케이션이 보기에는 MySQL과 구분되지 않고 쓰던 드라이버와 도구로 그대로 접속할 수 있습니다.
접속 방식뿐 아니라 문법도 ANSI SQL을 따릅니다. 2024년에는 SingleStore Kai로 MongoDB API 호환까지 범위를 넓혔습니다.
다만 문법이 같다고 동작까지 같지는 않습니다. 데이터가 여러 노드에 나뉘어 있어서 ORDER BY를 붙이지 않은 조회는 실행할 때마다 순서가 달라질 수 있고, 지원하지 않는 기능도 있습니다. 순서가 달라지는 조회와 미지원 기능은 다른 데이터베이스에서 옮겨 온 직후에 따로 점검해야 합니다.
점검할 항목까지 확인했으니, 그러면 이렇게 만든 싱글스토어는 어떤 업무에 쓰이고 있을까요.
4. 금융과 제조가 먼저 도입한 이유
싱글스토어를 먼저 도입한 곳을 가른 것은 업종이 아니라 업무 성격이었습니다. 데이터가 생긴 뒤 판단까지 걸리는 시간이 그대로 손실이 되는 업무여서, 분석을 다른 시스템으로 넘길 여유가 없었습니다. 국내에 공개 사례가 있는 세 가지를 정리하면 다음과 같습니다.
업무 영역 | 요구되는 조건 | 국내 공개 사례 |
금융 이상거래탐지, 자금세탁방지 | 거래 승인 이전에 판단이 완료돼야 한다 | 케이뱅크 실시간 AI FDS |
제조 공정 데이터 | 생산 중 발생하는 대량 데이터를 즉시 집계한다 | 스마트팩토리 구축 사례 |
실시간 분석과 마케팅 | 직전에 발생한 행동까지 반영해 집계한다 | 리테일, 이커머스 |
세 업무 모두 분석 결과를 기다릴 시간이 없습니다. 금융 이상거래탐지는 거래를 승인하기 전에 탐지가 끝나야 하므로 데이터를 옮긴 뒤 분석하는 순서를 거칠 수 없고, 제조 라인도 이상을 감지한 직후에 세워야 의미가 있어서 같은 제약을 받습니다. 반대로 월 단위로 집계하는 업무라면 굳이 합칠 이유가 없습니다.
이런 제약 때문에 국내에서도 금융이 먼저 움직였습니다. FDS(Fraud Detection System)는 도난 카드나 명의 도용 같은 이상 거래를 승인 전에 걸러내는 시스템입니다. 케이뱅크는 2026년 7월 이 시스템을 싱글스토어로 구축한 사례를 공개했습니다. SingleStore 공식 블로그도 국내 파트너십을 발표하면서 카카오와 포스코를 포함한 국내 기업을 고객사로 명시했습니다.
금융에서 시작된 도입은 한 번 더 넓어졌습니다. 2024년 1월에는 인덱스 기반 근사 최근접 이웃 검색이 들어왔습니다. 문장이나 이미지를 숫자 배열로 바꾼 것을 벡터라고 하는데 그중 뜻이 가장 가까운 것을 찾아 주는 기능입니다. 이 기능이 들어오면서 벡터도 같은 엔진에 저장하고 검색할 수 있게 됐고 2026년 7월에는 그 위에서 AI 에이전트를 개발하도록 지원하는 Aura AI가 공개됐습니다.
그래서 회사가 스스로를 소개하는 문구도 함께 바뀌었습니다. HTAP 데이터베이스라는 설명은 기술 문서에 남아 있지만 지금 앞세우는 표현은 실시간 데이터 플랫폼입니다.
5. 클러스터에서 새로 확인해야 하는 3가지
지금까지는 합쳐서 좋아지는 부분을 봤습니다. 다만 싱글스토어처럼 거래와 분석을 한 데이터베이스에 모으면 확인해야 할 항목도 함께 달라집니다. 노드가 여러 대로 늘어나면 확인할 항목이 노드마다 생기기 때문입니다. 이렇게 노드마다 확인해야 하는 문제를 세 가지로 나눠 보겠습니다.
① 노드는 정상인데 서비스 응답만 지연되는 상황
리프 여러 대의 CPU와 메모리가 모두 정상 범위인데 서비스 응답만 지연되는 경우가 생깁니다. 데이터가 특정 리프에 집중되면 그 노드가 병목이 되는데 개별 지표는 평균값에 묻혀 정상으로 보이기 때문입니다. 이런 편중을 스큐(Skew)라고 부릅니다.
② 동일한 역할인데 노드별로 다른 설정
테이블이 쓸 수 있는 메모리 한도는 노드마다 따로 정해집니다. 같은 리프인데 이 값이 서로 다르면 낮게 잡힌 노드부터 먼저 한계에 닿고, 한계에 닿으면 디스크가 남아 있어도 쓰기를 받지 못하고 읽기만 되는 상태로 바뀝니다. 노드를 하나씩 조회하지 않으면 이 차이가 보이지 않습니다.
③ 노드 상태값에 나타나지 않는 지연
모든 노드가 Online인데 복제만 밀리는 경우가 있습니다. Online은 노드가 살아 있다는 뜻이지 복제가 어디까지 따라왔는지는 알려주지 않기 때문입니다. 데이터베이스 지표는 정상인데 외부에서 들어오는 적재가 몇 시간씩 밀리는 경우도 마찬가지여서, 서비스에서 데이터가 낡았다는 문의가 온 다음에야 알게 됩니다.
세 문제는 지표가 모자라서 생기지 않습니다. 모두 노드 하나만 봐서는 드러나지 않고 노드끼리 견줘야 보이기 때문입니다. 서버 한 대를 볼 때의 질문이 「이 데이터베이스가 정상인가」였다면 클러스터에서는 「어느 노드에 쏠려 있고 어디가 밀려 있는가」로 바뀝니다. 확인할 지표가 늘어난 것이 아니라 같은 지표를 읽는 범위가 달라진 것입니다.
6. 정리
거래와 분석을 한 데이터베이스에서 처리한다는 결정은 파이프라인 하나를 없애는 데서 끝나지 않습니다. 이 결정으로 저장 방식과 데이터를 두는 위치까지 함께 바뀌므로 운영에서 확인할 지표의 범위도 그만큼 달라집니다.
반면 SQL 문법과 인덱스 설계, 실행 계획을 읽는 방법은 기존과 같습니다. 새로 세워야 하는 것은 문법이 아니라 서버가 한 대일 때 당연하게 여기던 기준입니다.
그 기준을 어디서부터 다시 세워야 할까요. 다음 글에서는 전제가 어느 지점에서 깨지는지, 클러스터에서 무엇을 어떤 순서로 점검해야 하는지 정리하겠습니다.
출처
SingleStore Announces Exclusive Partnership with Agile Platform to Develop the Korea Market - SingleStore (2024.04.16) SingleStore Announces Real-Time Data Platform to Further Accelerate AI, Analytics and Application Development - SingleStore (2024.01.24) 싱글스토어, AI 에이전트 시대 겨냥 'Aura AI' 공개 - 전자신문 (2026.07.08) "Better Context, Better AI" 싱글스토어, AI 에이전트 시대 위한 데이터 플랫폼 공개 - 테크데일리 (2026.07.07) Cluster Components - SingleStore Docs Choosing a Table Storage Type - SingleStore Docs Cluster Architecture - SingleStore Docs Detecting and Resolving Data Skew - SingleStore Docs SingleStore Kai - SingleStore
함께 보면 좋은 아티클
