![[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%3Aceabb5d0-58b0-4632-bfe8-ee31b57f626d%3Asinglestore_guide1_cover_D.png?table=block&id=3d5ddf18-253e-8061-99dc-eaee56b5e3c7&cache=v2&width=1200)
SingleStore가 분석용 DB를 따로 두지 않는 이유
2026년 7월 서울에서 열린 SingleStore AI NOW 2026에서 국내 기업들의 도입 사례가 공개됐습니다. 케이뱅크는 거래 데이터를 수 밀리초 단위로 분석하는 AI 이상거래탐지(FDS) 시스템을 소개했고, 카카오는 키워드 검색과 벡터 검색을 하나의 SQL로 결합한 하이브리드 검색 사례를 공유했습니다. 두 업무 모두 요청이 들어오면 결과가 곧바로 나와야 하고, 두 회사는 이를 SingleStore 기반으로 처리했습니다.
이렇듯 도입 사례는 늘고 있지만, 정작 SingleStore(싱글스토어)가 어떤 데이터베이스인지 정확히 알기는 쉽지 않습니다. 검색 결과에는 옛 이름인 MemSQL 시절 자료가 섞여 있고, 2020년 국내 기사의 "인메모리와 디스크를 함께 쓰는 데이터베이스"라는 설명도 그대로 남아 있습니다. 이 설명이 틀린 것은 아니지만, 지금은 기본 테이블 타입이 그때와 다릅니다.
결론부터 말하면, SingleStore는 거래 처리(OLTP)와 분석(OLAP)을 하나의 엔진에서 처리하도록 설계된 분산 SQL 데이터베이스입니다. 작업을 여러 노드에 나눠 처리하고, 분석용이던 컬럼스토어가 거래 처리까지 맡도록 확장했습니다.
1. 거래 처리와 분석을 나눠 온 이유
거래 처리(OLTP)와 분석(OLAP)은 데이터에 접근하는 방식과 자원을 쓰는 방식이 크게 달라, 한 시스템에서 두 작업의 성능을 함께 만족시키기 어려웠습니다.
OLTP는 주문과 결제, 회원 가입처럼 짧은 작업을 빈번하게 처리하는 영역입니다. 주문 한 건을 처리할 때는 회원과 재고를 확인하고, 주문 내역을 추가하고, 재고 수량을 갱신합니다. 중간에 실패하면 일부 변경만 남지 않도록 모든 변경을 함께 취소해야 합니다. 이런 요청이 끊임없이 들어오므로 대상 행을 빠르게 찾는 능력뿐 아니라 짧은 응답 시간과 동시 처리 성능이 중요합니다.
반면 지난 분기 매출을 지역별로 집계하는 작업은 OLAP입니다. 원본 데이터로 계산한다면 해당 기간의 수많은 주문에서 날짜, 지역, 금액처럼 필요한 열만 읽어 합산합니다. 성능은 한 행을 찾는 속도보다 넓은 범위의 데이터를 얼마나 빠르게 읽고 집계하는지에 달려 있습니다.
OLTP(Online Transaction Processing)는 온라인 거래 처리, OLAP(Online Analytical Processing)는 온라인 분석 처리를 뜻합니다. 데이터베이스가 담당하는 작업의 성격을 구분하는 기준으로 사용합니다.
SingleStore 공식 문서에 따르면 두 작업에 유리한 저장 방식도 서로 다릅니다. 행 저장(로우스토어)은 한 행의 값을 가까이 두어 특정 행의 조회와 갱신에 유리하지만, 많은 행에서 몇 개 열만 집계할 때는 필요 없는 값까지 읽게 됩니다. 열 저장(컬럼스토어)은 같은 열의 값을 모아 두어 필요한 열만 연속으로 읽고 압축하기 좋습니다. 그래서 대량 집계에 유리하지만, 잦은 소규모 갱신에는 추가 처리가 필요합니다(바꿀 행에 삭제 표시를 하고 새 행을 따로 쓰는 식입니다).
그래서 운영 DB에 거래 데이터를 기록하고, 이를 분석용 데이터 웨어하우스로 옮겨 집계하는 구성이 널리 쓰였습니다. 데이터는 ETL이나 CDC 파이프라인을 거쳐 이동합니다.
ETL(Extract, Transform, Load)은 데이터를 추출·변환·적재하는 과정입니다. CDC(Change Data Capture)는 원본 DB의 변경 사항을 포착해 다른 시스템에 거의 실시간으로 전달하는 방식입니다.
이 구성은 지금도 유용하지만, 데이터를 옮기는 과정에서 두 가지 비용이 생깁니다.
첫째, 분석에 반영되는 데이터가 늦어집니다. 하루 한 번 적재하는 배치 구성이라면 당일 오후 화면에도 전일 데이터가 표시될 수 있습니다. 월간 보고서라면 감수할 만한 지연이지만, 거래를 승인하기 전에 이상 징후를 탐지해야 하는 업무에는 더 빠른 반영 경로가 필요합니다. CDC로 변경분을 실시간에 가깝게 보내면 지연은 초 단위로 줄어들지만, 그만큼 파이프라인이 복잡해지고 유지하는 부담이 커집니다.
둘째, 파이프라인을 계속 운영해야 합니다. 원본 스키마가 바뀔 때마다 적재 설정과 변환 규칙을 점검하고, 운영 DB와 데이터 웨어하우스의 수치가 다르면 반영 지연 때문인지 변환 규칙 때문인지 추적하는 일이 따라옵니다. 어느 방식이든 같은 데이터를 두 곳에 따로 보관하게 됩니다.
업계에서도 같은 진단이 나옵니다. 같은 행사에서 한정희 싱글스토어코리아 대표는 여러 데이터베이스를 조합한 구조에서는 ETL과 CDC 같은 데이터 이동이 반복되면서 병목이 생긴다고 지적했습니다.
2. 나누지 않는 방식, HTAP
운영 DB와 분석 DB를 따로 두면 두 시스템 사이에 데이터를 옮기는 단계가 필요합니다. 같은 데이터베이스에 기록된 데이터를 곧바로 분석하면 이 단계를 줄이고, 가장 최근 데이터로 판단할 수 있습니다. SingleStore 공식 블로그에 따르면 IT 시장조사기관 가트너(Gartner)는 이처럼 거래 처리와 분석을 한 시스템에서 함께 처리하는 방식을 HTAP(Hybrid Transaction/Analytical Processing)라고 불렀습니다.
다만 두 작업을 한 DB에서 실행할 수 있다는 것과 두 작업을 모두 효율적으로 처리한다는 것은 다릅니다. 짧고 빈번한 거래 요청과 많은 데이터를 읽는 분석 쿼리는 같은 자원을 놓고 경쟁합니다. 그래서 저장 구조와 인덱스, 쿼리 실행 방식을 함께 설계해야 하고, HTAP 제품마다 이 문제를 푸는 방법도 다릅니다. 로그, 외부 API, 다른 시스템의 데이터는 여전히 적재해야 합니다. HTAP로 줄일 수 있는 것은 같은 DB에 이미 있는 데이터를 분석용으로 다시 옮기는 일입니다.
두 작업이 같은 자원을 놓고 경쟁하는 문제를 SingleStore가 어떻게 풀어 왔는지는 제품 이력에서 보입니다. 2011년 MemSQL이라는 이름의 인메모리 로우스토어 데이터베이스로 시작했고, 이후 디스크 기반 컬럼스토어와 분석 기능을 더했습니다. 2020년 10월 사명을 바꾸면서 공식 블로그는 'SingleStore'가 원래 사내 프로젝트의 이름이었다고 밝혔습니다. 두 테이블 타입을 골라 쓰던 방식에서 벗어나, 하나의 테이블 타입으로 거래와 분석을 모두 처리하려는 프로젝트였습니다.
이 프로젝트의 결과물이 지금의 'Universal Storage'입니다. 로우스토어는 그대로 두고, 컬럼스토어가 두 작업을 모두 맡도록 발전시켰습니다.
지금의 SingleStore를 인메모리 데이터베이스로 소개하면 정확하지 않습니다. 기본 테이블 타입은 디스크 기반 컬럼스토어인 Universal Storage이고, 인메모리 로우스토어는 필요한 테이블에만 따로 지정해 씁니다.
3. SingleStore가 거래와 분석을 함께 처리하는 구조
그렇다면 SingleStore는 두 작업을 한 엔진에서 어떻게 효율적으로 처리할까요. 데이터를 여러 노드에 나눠 저장하고 쿼리를 병렬로 실행하며, 분석용이던 컬럼스토어가 단건 조회와 갱신까지 처리하도록 저장 방식을 확장했습니다. 접속 방식은 새로 만들지 않고 MySQL 와이어 프로토콜을 지원해 기존 도구를 그대로 쓸 수 있게 했습니다.
3-1. 노드 나누기: 저장과 연산을 여러 노드에 분산
거래 요청이 늘거나 분석해야 할 데이터가 많아지면 저장 공간과 연산 자원이 함께 필요해집니다. SingleStore는 클러스터를 애그리게이터와 리프라는 두 역할로 구성해 이 작업을 나눕니다.
① 애그리게이터(Aggregator)
애그리게이터는 클라이언트의 쿼리를 받아 리프에 전달하고, 돌아온 결과를 모아 응답합니다. 상태 관리와 장애 조치, DDL 작업을 조정하는 마스터 애그리게이터는 클러스터에 하나뿐이고, 쿼리와 연결 부하가 늘면 차일드 애그리게이터를 추가합니다. 공식 문서는 마스터를 이중화한 구성에서 애플리케이션을 차일드 애그리게이터 앞단의 로드밸런서에 연결하도록 권장하며, 이때 DDL 같은 관리 작업은 차일드가 마스터로 넘겨 처리합니다.
② 리프(Leaf)
리프는 데이터를 저장하고 쿼리의 연산을 수행합니다. 테이블은 파티션이라는 조각으로 나뉘어 여러 리프에 분산되고, 리프 하나가 조각 여러 개를 맡습니다. 데이터를 어느 파티션에 둘지는 샤드 키라는 기준 열로 정합니다. 넓은 범위를 읽는 분석 쿼리는 여러 파티션에서 병렬로 실행되지만, 샤드 키 값으로 대상을 특정하는 조회는 한 파티션에서 끝낼 수도 있습니다.
이렇게 나눠 두면 데이터와 처리량이 늘어도 리프를 추가해 용량과 성능을 함께 늘릴 수 있는데, 이 효과는 샤드 키가 데이터를 고르게 나눌 때만 납니다.
3-2. 저장 구조 합치기: 컬럼스토어를 거래 처리까지 확장
노드를 늘리는 것만으로 단건 조회·갱신과 대량 집계를 모두 효율적으로 처리할 수는 없습니다. 초기 SingleStore에서는 테이블의 용도에 따라 인메모리 로우스토어와 디스크 기반 컬럼스토어를 선택했습니다. 주문은 로우스토어에, 집계용 이력은 컬럼스토어에 두는 식이었습니다.
현재 기본 테이블 타입인 Universal Storage는 컬럼스토어를 발전시킨 방식입니다. 공식 문서에 따르면 열 단위 저장의 집계 이점을 유지하면서 해시 인덱스, 서브세그먼트 접근, 행 단위 잠금, 업서트 등을 더해 특정 행을 찾고 변경하는 작업도 지원합니다.
작은 단위의 쓰기는 곧바로 압축된 열 덩어리에 쓰지 않고 메모리의 로우스토어 구간에 먼저 받았다가, 어느 정도 쌓이면 백그라운드에서 압축해 디스크 세그먼트로 내려보냅니다. 열 저장이 약한 잦은 소규모 갱신을 이 완충 구간이 흡수하기 때문에, 컬럼스토어 테이블 하나로 거래 처리와 분석 쿼리를 함께 처리할 수 있습니다.
인메모리와 디스크를 함께 쓴다는 2020년 기사의 설명은 이 구조에도 그대로 들어맞습니다. SingleStore는 모든 종류의 작업에 이 테이블 타입을 권장하고, 7.3 버전 이후 만든 클러스터에서는 기본값이기도 합니다.
인메모리 로우스토어도 남아 있습니다. 갱신과 삭제가 매우 잦거나 밀리초 응답이 최우선인 업무에서는 로우스토어가 더 적합할 수 있지만, 테이블 데이터를 메모리에 두는 비용을 고려해야 합니다. 따라서 테이블을 만들 때는 Universal Storage를 기본으로 두고, 워크로드에 따라 로우스토어를 고릅니다.
3-3. 접속 방식 유지: 기존 도구와의 연결
저장 방식은 바꿨지만, 접속 방식은 기존 그대로 두었습니다. SingleStore는 MySQL 와이어 프로토콜을 지원하므로 MySQL 드라이버와 여러 도구로 접속할 수 있습니다. 다만 접속 호환성이 MySQL의 모든 문법과 동작을 보장하지는 않습니다. 예를 들어 외래 키 제약과 트리거는 지원하지 않으므로, 기존 애플리케이션을 옮길 때 스키마와 쿼리를 확인해야 합니다.
MongoDB 클라이언트를 위한 SingleStore Kai는 2024년 1월 정식 출시됐습니다. SingleStore의 관리형 클라우드 서비스인 Helios에서 별도 엔드포인트로 제공됩니다. 다만 공식 문서에 따르면 Kai는 현재 기존 고객을 위한 유지보수 모드로, 신규 워크로드에는 권장되지 않습니다.
4. 국내에서는 SingleStore를 어떤 업무에 쓰고 있을까
SingleStore AI NOW 2026의 국내 발표 사례를 보면 SingleStore가 맡는 역할이 업무마다 다릅니다.
업무 | SingleStore로 처리하는 것 | 발표 기업 |
실시간 AI 이상거래탐지(FDS) | 거래 기록과 수 밀리초 단위 탐지, 벡터 검색을 활용한 사기 계정 탐지 | 케이뱅크 |
하이브리드 검색 | 키워드 검색과 벡터 검색을 순위 결합(RRF)으로 묶은 하나의 SQL 쿼리 | 카카오 |
광고 분석 플랫폼 | 실시간 영상 이해 기반 광고 분석, AI 분석 응답 시간을 수 분에서 1~2초로 단축 | 파일러 |
온프레미스 AI 플랫폼 | SingleStore를 포함한 플랫폼 구성 제안 (Sovereign AI) | 효성인포메이션시스템 |
이 가운데 거래 처리와 분석을 한 엔진에서 함께 하는 HTAP 구성에 가장 가까운 사례는 케이뱅크입니다. 이상거래탐지는 거래를 승인하기 전에 탐지가 끝나야 하므로, 들어온 거래 데이터를 분석용 시스템으로 다시 옮길 시간이 없습니다. 케이뱅크는 SingleStore 기반으로 거래 데이터를 수 밀리초 단위로 분석하는 AI 이상거래탐지를 구축했다고 밝혔습니다.
카카오는 키워드 검색과 벡터 검색을 한 쿼리로 묶은 사례이고, 파일러는 AI 분석 응답 시간을 줄인 사례입니다. 파일러는 SingleStore 도입 후 분석 응답 시간이 수 분에서 1~2초로 줄고 운영 비용이 약 70% 감소했다고 밝혔습니다. 파일러가 발표에서 밝힌 수치여서, 다른 환경에서도 같은 결과가 나온다고 볼 수는 없습니다.
효성인포메이션시스템의 발표는 성격이 다릅니다. 이 회사는 SingleStore를 포함한 온프레미스 AI 플랫폼 구성을 소개한 공급사입니다. 공개된 발표만으로 각 조직이 기존 거래 DB와 분석 DB를 통합했거나 데이터 이동 단계를 없앴다고 판단할 수는 없습니다. 실제 도입을 검토할 때는 SingleStore에 어떤 데이터를 저장하고, 외부 시스템에서 어떤 경로로 데이터를 가져오는지 확인해야 합니다.
SingleStore 공식 블로그는 2024년 4월 에이플랫폼과 한국 시장 독점 파트너십을 발표하면서 카카오, 포스코, LG이노텍, 케이뱅크, 키움증권, SK텔레콤을 국내 고객사로 명시했습니다.
케이뱅크와 카카오 사례에 나온 벡터 검색을 비롯해 SingleStore의 AI 관련 기능도 넓어졌습니다. 처음에는 벡터를 하나씩 비교하는 정확 검색만 가능했지만, 2024년 1월 인덱스 기반 검색이 더해지면서 대량의 데이터에서도 빠르게 찾을 수 있게 됐습니다. 2025년 10월에는 SQL에서 LLM을 호출하는 AI·ML Functions와 자연어로 질의하는 Aura Analyst가 더해졌습니다. 2026년 7월 서울 행사에서는 AI 에이전트 개발을 지원하는 Aura AI가 공개됐습니다.
케이뱅크, 카카오, 파일러는 모두 실시간 응답이 필요한 업무에 SingleStore를 썼습니다. 반대로 월 단위로 집계하는 업무는 배치 지연을 감수할 수 있으므로, 굳이 한 엔진으로 합칠 이유가 크지 않습니다.
5. 분산 클러스터에서는 무엇을 새로 확인해야 할까
SingleStore는 실시간 부하를 한 엔진에서 받기 위해 데이터를 여러 노드에 나눠 저장합니다. 그래서 노드 하나만 봐서는 드러나지 않는 문제가 생깁니다.
① 노드는 정상인데 서비스 응답만 지연되는 상황
리프 여러 대의 CPU와 메모리가 클러스터 평균으로는 정상 범위인데, 서비스 응답만 지연되는 경우가 있습니다. 데이터가 특정 파티션에 집중되면 그 파티션을 가진 리프가 병목이 되지만, 평균값에서는 이 차이가 드러나지 않기 때문입니다. 이런 편중을 스큐(skew)라고 부릅니다. 공식 문서는 경험칙으로 파티션 간 편차가 10% 미만이면 대체로 성능에 큰 영향이 없다고 안내합니다. 편차는 파티션별 행 수와 메모리 사용량의 상대 표준편차로 계산하며, 샤드 키를 잘못 고르면 이 값이 커집니다.
② 한 노드만 먼저 메모리 한도에 닿는 상황
온프레미스 클러스터에서는 테이블이 쓸 수 있는 메모리 한도(maximum_table_memory)가 노드마다 설정됩니다. 위 그림처럼 데이터가 한 리프에 집중되거나 특정 리프의 설정값이 낮게 잡혀 있으면, 그 리프가 다른 노드보다 먼저 한도에 닿습니다. 한도에 닿으면 조회와 삭제는 처리되지만, 입력(INSERT)·갱신(UPDATE)과 테이블·인덱스 변경은 오류로 거부됩니다. 디스크가 남아 있어도 쓰기가 막힌 것처럼 보이고, 리프마다 설정값과 사용량을 비교해 보지 않으면 원인을 찾기 어렵습니다.
③ 노드 상태값에 나타나지 않는 지연
재해 복구(DR)를 위해 다른 클러스터로 데이터를 복제하는 경우, 모든 노드가 online으로 보이는데 복제만 밀리는 상황이 생길 수 있습니다. online은 노드가 살아 있다는 뜻일 뿐, 데이터가 어디까지 복제됐는지는 알려 주지 않습니다. 그래서 공식 문서는 복제 진행 상황을 별도의 상태 뷰에서 지연량과 예상 따라잡기 시간으로 확인하라고 안내합니다. Kafka나 외부 저장소에서 파이프라인으로 적재하는 경우도 마찬가지여서, 적재 진행 상태를 따로 보지 않으면 서비스에서 데이터가 오래됐다는 문의가 온 다음에야 알게 되기도 합니다.
3가지 문제 모두 노드별 수치를 나란히 비교해야 드러납니다. 한 노드의 편중이나 설정 차이가 다른 증상으로 나타나기도 합니다. 어떤 지표를 볼지는 서비스가 어떤 경로로 데이터를 쓰고 읽는지에 따라 달라집니다.
6. 한 DB에서 처리한다는 결정이 바꾸는 것
거래와 분석을 한 데이터베이스에서 처리하면 ETL 파이프라인이 줄어드는 대신, 노드 구성과 테이블 타입이 바뀌고 같은 지표도 노드별로 비교해 읽어야 합니다. 이 방식은 실시간 응답이 필요한 업무에 맞습니다.
여러 작업을 한 클러스터에서 처리하는 만큼 운영할 때는 파티션별 데이터 분포, 리프별 자원 사용량, 데이터 반영 지연을 함께 살펴봐야 합니다. MySQL 드라이버로 접속할 수 있어도 SQL 기능이 모두 같지는 않습니다. 실행 계획에도 쿼리가 한 파티션에서 끝나는지, 여러 파티션을 읽거나 노드 사이에서 데이터를 옮기는지가 함께 나타납니다.
SingleStore가 분석용 DB를 따로 두지 않는 것은 데이터를 옮기는 동안의 지연을 감당할 수 없는 업무가 생겼고, 컬럼스토어가 거래 처리까지 맡을 수 있게 됐기 때문입니다.
출처
싱글스토어, AI 에이전트 시대 겨냥 'Aura AI' 공개 - 전자신문 (2026.07.08) "Better Context, Better AI" 싱글스토어, AI 에이전트 시대 위한 데이터 플랫폼 공개 - 테크데일리 (2026.07.07) MemSQL, 싱글스토어로 사명 변경 - ZDNet Korea (2020.11.11) MemSQL is Now SingleStore - SingleStore (2020.10.21) 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) SingleStore Drops Three Major Upgrades to Power the Next Decade of AI Applications - SingleStore (2025.10.01) SingleStore 공식 문서 - SingleStore Docs: Choosing a Table Storage Type, Writing Columnstore Data, Cluster Components, Master Aggregator Redundancy, Universal Storage, Creating a Columnstore Table, Unsupported MySQL Features, SingleStore Kai, Detecting and Resolving Data Skew, maximum_table_memory, Monitoring Replication, PIPELINES, Query Plan Operations
함께 보면 좋은 아티클
