마이클 스톤브레이커와 현대 데이터베이스: 그가 바꾼 것들

왜 스톤브레이커의 작업이 여전히 당신의 데이터 스택에 나타나는가

마이클 스톤브레이커는 데이터베이스 연구에만 영향을 준 연구자가 아니라, 많은 팀이 매일 의존하는 제품과 설계 패턴을 직접적으로 형성한 컴퓨터 과학자입니다. 관계형 데이터베이스, 분석용 웨어하우스, 스트리밍 시스템을 사용해 본 적이 있다면, 그가 증명하거나 구축하거나 보급한 아이디어의 혜택을 본 것입니다.

이 글에서 얻을 것

이 글은 전기나 이론적 데이터베이스 강의가 아닙니다. 대신 스톤브레이커의 주요 시스템(예: Ingres, Postgres, Vertica)이 현대 데이터 스택의 선택에 어떻게 연결되는지 보여줍니다:

• 왜 SQL이 데이터 작업의 공통 언어가 되었는가
• 왜 분석 엔진이 OLTP 데이터베이스와 다르게 보이고 동작하는가
• 왜 "모든 것을 처리하는 하나의 데이터베이스"가 실제로는 자주 실패하는가
• 아키텍처 선택이 비용, 성능, 신뢰성에 어떻게 영향을 주는가

"현대 데이터베이스"의 의미(평이한 설명)

현대 데이터베이스는 다음을 신뢰성 있게 수행할 수 있는 시스템입니다:

• 데이터를 안전하게 저장(데이터를 잃지 않음)
• 빠르게 질의(팀이 질문에 답할 수 있음)
• 확장(볼륨이나 사용자가 늘어나도 견딤)
• 동시성에서 올바름 유지(결과가 현실과 일치함)

거래 처리, BI 대시보드, 실시간 파이프라인을 비교하면 각 데이터베이스가 이 목표들을 다르게 최적화한다는 것을 알게 됩니다.

이 글의 약속

우리는 실용적 영향을 중심으로 다룹니다: 오늘날의 "웨어하우스 + 레이크 + 스트림 + 마이크로서비스" 세계에서 나타나는 아이디어들과 그것들이 무엇을 사고·구매·운영하게 만드는지. 명확한 설명, 트레이드오프, 실무적 함의를 기대하세요—증명이나 구현 세부로 깊게 들어가진 않습니다.

그의 주요 데이터베이스 이정표의 짧고 유용한 타임라인

스톤브레이커의 경력은 특정 작업을 위해 설계된 시스템들의 연속으로 보는 것이 가장 이해하기 쉽습니다—그리고 가장 좋은 아이디어들이 주류 데이터베이스 제품으로 전파되는 과정을 지켜보면 됩니다.

1970년대: Ingres — 관계형 DB를 실용적으로 만들다

Ingres는 관계형 데이터베이스가 단지 이론이 아니라 빠르고 실용적일 수 있음을 증명한 학술 프로젝트로 시작했습니다. SQL 스타일 쿼리와 비용 기반 최적화 개념을 대중화하는 데 기여했고, 이후 상업 엔진에서 표준이 된 사고방식을 확산시켰습니다.

1980~1990년대: Postgres — 확장성과 "데이터베이스가 진화하도록 허용"

Postgres(연구 시스템으로, 이후 PostgreSQL로 이어짐)는 데이터베이스가 고정 기능이 되어선 안 된다는 다른 배팅을 실험했습니다. 새로운 데이터 타입, 새로운 인덱스 방법, 더 풍부한 동작을 전체 엔진을 다시 쓰지 않고도 추가할 수 있어야 한다는 아이디어입니다.

이 시기에 많은 현대 기능들이 기원을 두고 있습니다—확장형 타입, 사용자 정의 함수, 그리고 워크로드가 바뀔 때 적응할 수 있는 데이터베이스라는 개념 등이 그 예입니다.

2000년대: 칼럼형 저장과 분석 우선 설계

분석 수요가 커지면서 행 지향 시스템은 대규모 스캔과 집계에서 어려움을 겪었습니다. 스톤브레이커는 칼럼형 저장과 필요한 칼럼만 읽고 잘 압축하는 실행 기법을 밀어붙였습니다—지금은 분석 데이터베이스와 클라우드 웨어하우스에서 표준이 된 아이디어들입니다.

2000년대 중반: Vertica — 제품으로서의 MPP 분석

Vertica는 칼럼 저장 연구 아이디어를 상업적으로 실현 가능한 대규모 병렬 처리(MPP) SQL 엔진으로 가져갔습니다. 프로토타입이 개념을 검증하면, 제품은 신뢰성, 툴링, 실제 고객 제약을 고려해 이를 단단하게 만듭니다—이 패턴은 산업 전반에 반복됩니다.

2010년대 이후: 스트리밍과 "워크로드에 맞는 올바른 도구"

그의 이후 작업은 스트림 처리와 워크로드 전용 엔진으로 확장되어, 범용 데이터베이스 하나가 모든 곳에서 이기는 경우가 드물다는 주장을 강화했습니다.

연구 프로토타입 vs 제품(왜 구분이 중요한가)

프로토타입은 가설을 빠르게 검증하기 위해 만들어지고, 제품은 운영성(업그레이드, 모니터링, 보안, 예측 가능한 성능, 지원)을 우선시해야 합니다. 스톤브레이커의 영향은 많은 프로토타입 아이디어가 상업용 데이터베이스의 기본 기능으로 졸업했기 때문에 두드러집니다.

Ingres: 관계형 데이터베이스를 실용적으로 만들다

Ingres(INteractive Graphics REtrieval System의 약칭)은 관계형 모델이 우아한 이론을 넘어서 현실적인 업무에서 쓸 수 있음을 입증한 초기 사례였습니다. 당시 많은 시스템은 맞춤형 접근 방법과 애플리케이션별 데이터 경로 위주로 만들어졌습니다.

Ingres는 다음과 같은 실용적 문제를 풀려 했습니다:

질문이 바뀔 때마다 소프트웨어를 다시 쓰지 않고 사람들이 유연하게 데이터에 질문하도록 어떻게 허용할 것인가?

Ingres가 고치려 한 것

관계형 데이터베이스는 무엇을 원하는지(예: "연체된 인보이스가 있는 캘리포니아 고객") 기술하면, 그걸 어떻게 가져올지 단계별로 적지 않아도 된다는 약속을 했습니다. 하지만 그 약속을 현실로 만들려면 시스템이 다음을 할 수 있어야 했습니다:

• 테이블에 데이터를 신뢰성 있게 저장
• SQL에 가까운 고수준 질의 언어를 받아들임
• 그 질의를 자동으로 효율적인 실행 계획으로 변환

Ingres는 당시 하드웨어에서도 실행 가능하고 반응성이 느껴지는 "실용적" 관계형 컴퓨팅으로 가는 중요한 발걸음이었습니다.

SQL 채택과 쿼리 최적화 기초의 탄생

Ingres는 데이터베이스가 쿼리 계획 수립이라는 어려운 일을 해야 한다는 생각을 대중화했습니다. 개발자가 모든 데이터 접근 경로를 수동으로 튜닝하는 대신, 시스템이 어느 테이블을 먼저 읽을지, 어떤 인덱스를 사용할지, 어떻게 조인할지를 선택할 수 있게 했습니다.

이로 인해 SQL 스타일 사고가 확산되었습니다: 선언형 쿼리를 작성할 수 있으면 더 빠르게 반복하고, 더 많은 사람이(분석가, 제품팀, 재무 등) 맞춤 리포트를 기다리지 않고 직접 질문할 수 있게 됩니다.

비용 기반 최적화가 중요한 이유

핵심 실무적 통찰은 비용 기반 최적화입니다: 데이터에 대한 통계에 근거해 예상되는 "비용"(보통 I/O, CPU, 메모리의 혼합)이 가장 낮은 쿼리 계획을 선택하는 것.

그 결과로 흔히 얻는 이점은:

• 애플리케이션을 바꾸지 않고도 더 빠른 쿼리
• 같은 성능 목표를 달성하는 데 필요한 하드웨어 감소
• 데이터가 커져도 더 예측 가능한 성능

Ingres가 현대 최적화의 모든 조각을 발명한 것은 아니지만, SQL + 옵티마이저라는 패턴을 확립해 관계형 시스템을 "좋은 아이디어"에서 일상적 도구로 확장시키는 데 기여했습니다.

Postgres: 확장 가능한 데이터베이스라는 큰 아이디어

초기 관계형 데이터베이스는 고정된 데이터 타입(숫자, 텍스트, 날짜)과 고정된 연산(필터, 조인, 집계)을 가정하는 경향이 있었습니다. 하지만 팀들이 지리공간, 로그, 시계열, 도메인별 식별자 같은 새로운 정보를 저장하기 시작하면서 이 가정은 한계를 드러냈습니다.

고정된 설계에서는 새로운 요구가 생길 때마다 열악한 선택을 강요당합니다: 데이터를 텍스트 블롭으로 억지로 집어넣거나, 별도 시스템을 덧붙이거나, 벤더가 지원 기능을 추가할 때까지 기다리는 식입니다.

확장성, 전문 용어 없이 설명하면

Postgres는 데이터베이스가 확장 가능이어야 한다는 아이디어를 밀었습니다—즉, 안전하고 통제된 방식으로 새로운 기능을 추가할 수 있어야 하며, SQL에서 기대하는 안전성과 정합성을 깨뜨리지 않아야 합니다.

쉽게 말하면, 확장성은 전동 공구에 인증된 부속품을 붙이는 것과 비슷합니다. 모터를 뜯어 고치지 않고도 도구에 "새 기술"을 가르칠 수 있고, 트랜잭션, 권한, 쿼리 최적화는 하나의 일관된 체계로 유지됩니다.

현대 확장 생태계에 미친 영향

이 사고방식은 오늘날 PostgreSQL 생태계(및 많은 Postgres 영감을 받은 시스템)에서 뚜렷하게 보입니다. 핵심 기능을 기다리는 대신, 검증된 확장을 채택해 SQL과 운영 도구와 매끄럽게 통합할 수 있습니다.

높은 수준의 예시는:

• 사용자 정의 데이터 타입: 지리공간 포인트, 범위, JSON 유사 구조 등 더 풍부한 값을 일등 시민으로 저장
• 사용자 정의 함수: 쿼리와 리포트 안에서 직접 쓸 수 있는 도메인 로직 추가
• 인덱싱 옵션: 접근 패턴에 따라 다른 인덱스 타입 선택으로 같은 SQL 쿼리의 실행 속도 개선

핵심은 Postgres가 "데이터베이스가 무엇을 할 수 있는지 바꾸는 것"을 설계 목표로 삼았다는 점입니다—그리고 이 아이디어는 현대 데이터 플랫폼이 어떻게 진화하는지에 여전히 영향을 미칩니다.

트랜잭션과 동시성: 대규모에서 올바른 결과 얻기

데이터베이스는 단순히 정보를 저장하는 것 이상입니다—많은 일이 동시에 일어나도 정보가 옳게 유지되도록 하는 것이 핵심입니다. 이것이 바로 트랜잭션과 동시성 제어의 역할이며, SQL 시스템이 실제 비즈니스 작업에서 신뢰받는 주요 이유입니다.

트랜잭션이 실제로 보장하는 것

트랜잭션은 하나의 단위로 성공하거나 실패해야 하는 변경들의 묶음입니다.

돈을 이체하거나 주문을 넣거나 재고를 업데이트할 때 "반쯤 끝난" 상태는 허용할 수 없습니다. 트랜잭션은 고객에게 비용을 청구했지만 재고를 확보하지 못하는 상황이나 재고가 줄었지만 주문 기록이 없는 상황을 방지합니다.

실무적으로 트랜잭션은:

• 사람이 설명할 수 있는 일관성: 데이터베이스가 변경을 "어느 정도만" 적용하지 않음
• 복구성: 중간에 시스템이 다운돼도 안전한 상태로 롤백 가능

동시성: 데이터베이스가 처리해야 하는 현실적 골칫거리

동시성은 많은 사람(및 애플리케이션)이 동시에 데이터를 읽고 바꾸는 상황을 뜻합니다: 고객의 결제, 고객센터의 계정 편집, 백그라운드 작업의 상태 업데이트, 분석가의 리포트 실행 등.

주의하지 않으면 동시성은 다음 같은 문제를 만듭니다:

• 업데이트 손실: 두 사용자가 같은 레코드를 편집할 때 한 쪽이 다른 쪽을 덮어씀
• 더러운 읽기: 나중에 롤백될 데이터가 보이는 경우
• 일관성 없는 리포트: 쿼리가 "전" 상태와 "후" 상태를 섞어 보는 경우

쉬운 말로 풀어쓴 MVCC

한 영향력 있는 접근법은 **MVCC(다중 버전 동시성 제어)**입니다. 개념적으로 MVCC는 행의 여러 버전을 잠시 동안 보관해, 읽는 쪽은 안정된 스냅샷을 유지하면서 쓰기가 진행되도록 합니다.

큰 이점은 읽기가 쓰기를 자주 막지 않는다는 점이며, 쓰기 또한 장시간 실행되는 조회에 의해 자주 지연되지 않습니다. 올바름은 유지하면서 대기 시간이 줄어듭니다.

이것이 현대 SQL 워크로드에서 중요한 이유

오늘날 데이터베이스는 종종 혼합 워크로드를 처리합니다: 높은 볼륨의 쓰기와 대시보드 / 고객 뷰 / 운영 분석을 위한 빈번한 읽기. 현대 SQL 시스템은 MVCC, 더 똑똑한 락킹, 격리 수준 같은 기법에 의존해 속도와 정확성을 균형 있게 유지합니다—따라서 활동을 확장해도 데이터에 대한 신뢰를 잃지 않습니다.

칼럼 저장소: 분석 성능의 전환점

행 지향 데이터베이스는 거래 처리용으로 설계되었습니다: 보통 하나의 고객이나 하나의 주문, 하나의 계정을 건드리는 작은 읽기/쓰기가 많습니다. 이런 설계는 전체 레코드를 빠르게 가져오거나 업데이트할 때 탁월합니다.

행 vs 칼럼(일상적 비유)

스프레드시트를 떠올려 보세요. 행 저장소는 각 행을 하나의 폴더로 보관하는 것과 같습니다: 주문 #123에 대한 "모든 것"이 필요하면 한 폴더를 꺼내면 끝입니다. 칼럼 저장소는 열별로 보관하는 것과 같아서, "order_total" 서랍, "order_date" 서랍, "customer_region" 서랍이 따로 있습니다.

분석에서는 전체 폴더가 거의 필요하지 않습니다—보통 "지난 분기 지역별 총수익은 얼마였나?" 같은 질문을 던지죠. 이런 쿼리는 수백만 건의 레코드에서 몇 개의 필드만 건드립니다.

왜 분석 워크로드가 칼럼을 좋아하는가

분석 쿼리는 대개:

• 테이블의 많은 부분을 스캔
• 소수의 칼럼만 사용
• 강한 집계(SUM/AVG/COUNT)와 필터링을 사용

칼럼형 저장소를 사용하면 엔진은 쿼리에서 참조된 칼럼만 읽을 수 있으므로 나머지는 건너뜁니다. 디스크에서 읽는 데이터가 줄고(메모리로 옮기는 데이터도 줄어들어) 성능이 크게 향상됩니다.

압축은 단순한 공간 절약이 아니다

칼럼 데이터는 반복 값(지역, 상태, 카테고리 등)이 많아 압축에 유리합니다—이로 인해 읽는 바이트 수가 줄고 때로는 압축된 상태로 연산을 수행할 수 있어 속도가 더 빨라집니다.

더 큰 변화

칼럼 저장소는 OLTP 우선 데이터베이스에서 분석 우선 엔진으로의 전환을 표시합니다. 이들은 스캔, 압축, 빠른 집계를 설계 목표로 두며, 이러한 특성은 이후 주요 설계 고려사항이 되었습니다.

Vertica와 MPP 분석: 대규모 쿼리를 위한 SQL 확장

Vertica는 스톤브레이커의 분석 데이터베이스 아이디어가 운영 환경에서 실행 가능한 제품으로 바뀐 대표적 예입니다. 칼럼 저장소의 교훈을 받아 분산 설계와 결합해 하나의 문제를 겨냥했습니다: 데이터 볼륨이 단일 서버를 넘어서도 큰 분석 SQL 쿼리를 빠르게 답하는 것.

MPP의 의미(쉬운 설명)

MPP는 여러 머신이 하나의 SQL 쿼리를 동시에 처리하게 하는 방식입니다.

하나의 데이터베이스 서버가 모든 데이터를 읽고 그룹화·정렬하던 대신, 데이터는 노드들에 나뉘어지고 각 노드는 자신의 파티션을 병렬로 처리한 뒤 부분 결과를 합쳐 최종 답을 냅니다.

잘 분배되고 쿼리가 병렬화될 수 있다면, 한 박스에서 분 단위가 걸릴 작업이 클러스터에서는 초 단위로 줄어들 수 있습니다.

실무에서 가능한 것들

Vertica 스타일의 MPP 분석 시스템은 많은 행을 스캔하고 효율적으로 필터·집계하려는 경우에 탁월합니다. 전형적 사용 사례는:

• 대형 팩트 테이블을 읽는 대시보드(제품 분석, 마케팅 성과, 운영 메트릭)
• 예약 보고 및 ad-hoc SQL 탐색
• 큰 집계(일별 코호트, 퍼널, 다차원 집계)

거래형 데이터베이스와의 트레이드오프

MPP 분석 엔진은 거래(OLTP) 시스템을 바로 대체할 수 없습니다. 이들은 많은 행을 읽고 요약을 계산하는 데 최적화되어 있으며, 작은 단건 업데이트 처리에는 적합하지 않습니다.

일반적 트레이드오프는:

• 신선도: 데이터가 보통 배치 또는 마이크로배치로 들어옴
• 업데이트: 잦은 단건 업데이트/삭제는 느리거나 운영적으로 복잡함
• 지연: 초 단위~분 단위의 분석 쿼리에 적합; 밀리초 사용자 응답에는 부적합

핵심은 집중입니다: Vertica와 유사 시스템은 저장, 압축, 병렬 실행을 분석에 맞게 조율해 속도를 얻고, 거래형 시스템이 피하려는 제약을 받아들입니다.

분석을 더 빠르게 만든 쿼리 실행 혁신들

데이터베이스가 "저장하고 질의"할 수만 있어도 분석에서 느리게 느껴질 수 있습니다. 차이는 종종 당신이 쓰는 SQL이 아니라 엔진이 그것을 어떻게 실행하는가—페이지를 어떻게 읽고, 데이터를 CPU로 어떻게 옮기며, 메모리를 어떻게 쓰고, 불필요한 작업을 어떻게 줄이는가—에 있습니다.

스톤브레이커의 분석 중심 프로젝트들은 쿼리 성능을 저장 문제만큼 실행 문제로 보아야 한다는 생각을 밀어붙였습니다. 이 사고는 팀들이 단건 조회 최적화에서 수백만(혹은 수십억) 행의 긴 스캔·조인·집계 최적화로 관심을 옮기게 했습니다.

벡터화 실행(행 단위가 아니라 배치 단위로 작업)

많은 오래된 엔진은 쿼리를 "튜플-아-타임"(행 단위)으로 처리해 함수 호출과 오버헤드가 많습니다. 벡터화 실행은 이 모델을 뒤집어, 엔진이 값의 배치(벡터)를 조밀한 루프에서 처리하게 합니다.

비유하자면, 장보기에서 물건을 한 번에 하나씩 들고 가는 대신 카트를 쓰는 것과 같습니다. 배치는 오버헤드를 줄이고 최신 CPU가 잘하는 예측 가능한 루프와 캐시 활용을 가능하게 합니다.

메모리 친화적 분석 설계

빠른 분석 엔진은 CPU와 캐시 효율을 극대화하는 데 집착합니다. 실행 혁신은 보통 다음에 집중합니다:

• 불필요한 물리화 회피(큰 중간 테이블을 만들지 말고 스트리밍으로 결과를 전달)
• 가능하면 압축된 데이터로 작업(메모리 대역폭 절약, 적게 이동되는 바이트)
• 핫 데이터 캐시에 유지(레이아웃과 배치가 CPU 접근 패턴과 맞음)

이 아이디어들은 중요합니다. 왜냐하면 분석 쿼리는 종종 원시 디스크 속도가 아니라 메모리 대역폭과 캐시 미스에 의해 제한되기 때문입니다.

오늘날 어디에서 보는가

현대 데이터 웨어하우스와 SQL 엔진—클라우드 웨어하우스, MPP 시스템, 빠른 인프로세스 분석 도구—은 자주 벡터화 실행, 압축 인식 연산자, 캐시 친화적 파이프라인을 표준 관행으로 사용합니다.

벤더가 "오토스케일링"이나 "스토리지와 컴퓨트 분리" 같은 기능을 마케팅하더라도, 일상적 체감 성능은 여전히 이러한 실행 선택에 크게 좌우됩니다.

플랫폼을 평가할 때는 그들이 무엇을 저장하는지뿐 아니라 조인과 집계를 내부적으로 어떻게 실행하는지, 실행 모델이 트랜잭션이 아닌 분석에 맞게 설계되었는지를 물어보세요.

스트리밍 시스템: 배치 사고에서 실시간으로

스트리밍 데이터는 연속적으로 도착하는 사건들의 흐름입니다—신용카드 결제, 센서 측정값, 제품 페이지 클릭, 패키지 스캔, 로그 라인 같은 것들이 실시간으로 연속적으로 들어옵니다.

배치 DB가 실무에서 느린 이유

전통적 데이터베이스와 배치 파이프라인은 기다릴 수 있을 때 훌륭합니다: 어제 데이터를 로드하고 보고서를 돌리고 대시보드를 발행하는 식입니다. 그러나 실시간 요구는 다음 배치 작업을 기다리지 않습니다.

배치로만 처리하면:

• 지표가 오래됨(숫자가 실제 상황을 뒤처짐)
• 알림이 지연됨(문제가 난 후에야 알게 됨)
• 우회 방법이 필요함(테이블 폴링, 쿼리 재실행 등)

스트리밍 시스템은 계산이 이벤트가 도착함에 따라 계속 실행될 수 있다고 가정하고 설계됩니다.

핵심 아이디어: 연속 쿼리와 윈도우

연속 쿼리는 끝나지 않는 SQL 쿼리와 같습니다. 한 번 결과를 반환한 뒤 끝나는 대신 새로운 이벤트가 들어올 때마다 결과를 갱신합니다.

스트림은 유한하지 않으므로 스트리밍 시스템은 계산을 관리 가능하게 만들기 위해 윈도우를 사용합니다. 윈도우는 "마지막 5분", "매 분", "마지막 1,000개 이벤트" 같은 시간 또는 이벤트의 슬라이스입니다. 이를 통해 전체를 다시 처리하지 않고 롤링 카운트, 평균, top-N 같은 것을 계산합니다.

비즈니스 사례

실시간 스트리밍이 즉시 가치 있는 경우:

• 사기 탐지: 몇 초 안에 이상 결제 플래그
• 운영 알림: 에러 급증을 시작하자마자 감지
• 실시간 제품 지표: 가입, 전환, 재고 변화를 즉시 확인
• 물류 가시성: 연속 스캔으로 배송 ETA 갱신

워크로드 기반 아키텍처: 작업에 맞는 엔진 사용

스톤브레이커는 수십 년 동안 데이터베이스가 모두 범용으로 "모든 걸 하는" 방식으로 만들어져선 안 된다고 주장해 왔습니다. 이유는 단순합니다: 서로 다른 워크로드는 서로 다른 설계 결정을 보상합니다. 하나의 작업(예: 작은 트랜잭션 업데이트)에 강하게 최적화하면 보통 다른 작업(예: 수십억 행 스캔)이 느려집니다.

팀들이 여러 시스템을 갖게 되는 이유

대부분의 현대 스택은 한 종류 이상의 데이터 시스템을 사용합니다. 그 이유는 비즈니스가 여러 가지 종류의 답을 요구하기 때문입니다:

• OLTP 데이터베이스(애플리케이션 DB): 빠른 삽입/업데이트, 엄격한 정합성, 많은 동시 사용자
• 웨어하우스/분석 DB: 많은 데이터에 대한 빠른 읽기, 무거운 집계, 긴 스캔
• 캐시/키-값 저장소: "핫" 데이터에 대한 초고속 조회(세션, 카운터, 피처 플래그)
• 스트림 처리 + 로그: 연속 이벤트(클릭, 결제, IoT), 저지연 파이프라인, 실시간 메트릭

이는 실무에서 "한 사이즈가 모두에 맞지 않는다"는 것을 보여줍니다: 작업의 형태에 맞는 엔진을 선택해야 합니다.

간단한 의사결정 가이드

선택(또는 새 시스템 정당화) 시 빠른 필터링 기준:

• 많은 작은 읽기/쓰기와 트랜잭션이 필요하면(주문, 사용자 프로필): OLTP DB로 시작
• 대규모 쿼리와 집계가 필요하면(주간 매출, 코호트 분석): 분석 웨어하우스 추가
• 반복 조회에서 서브세컨드 응답이 필요하면: 캐시 도입
• 이벤트에 대한 실시간 반응이 필요하면(사기 규칙, 실시간 대시보드): 스트리밍 추가

도구 과다 사용 방지

여러 엔진은 각자 명확한 워크로드가 있을 때 건강할 수 있습니다. 새 도구는 비용, 지연, 리스크를 줄이는 명확한 근거가 있어야 자리잡을 자격이 있습니다.

운영 주체가 확실한 적은 수의 시스템을 선호하고, 명확한 목적이 없는 컴포넌트는 퇴출시키세요.

이러한 아이디어가 현대 데이터 아키텍처에 나타나는 방식

스톤브레이커의 연구 주제들—관계형 기반, 확장성, 칼럼 저장, MPP 실행, "작업에 맞는 도구"—은 현대 데이터 플랫폼의 기본 형태에서 볼 수 있습니다.

익숙한 아키텍처 패턴(그리고 그 이유)

웨어하우스는 수십 년간의 SQL 최적화, 칼럼형 저장, 병렬 실행 작업의 산물입니다. 거대한 테이블에서 빠른 대시보드를 보면 칼럼 지향 포맷과 벡터화 처리, MPP 스타일의 스케일링이 쓰인 경우가 많습니다.

레이크하우스는 웨어하우스의 아이디어(스키마, 통계, 캐싱, 비용 기반 최적화)를 오픈 파일 포맷과 오브젝트 스토리지 위에 얹은 것입니다. "저장소는 싸고 컴퓨트는 탄력적"이라는 변화는 새롭지만, 그 아래의 쿼리와 트랜잭션 사고는 새롭지 않습니다.

MPP 분석 시스템(셰어드-낫팅 클러스터)은 데이터를 파티셔닝하고 계산을 데이터 쪽으로 이동시키며 조인·집계 시 데이터 이동을 세심히 관리하면 SQL을 확장할 수 있다는 연구의 직접적 후계자입니다.

오늘날 SQL의 위치

SQL은 웨어하우스, MPP 엔진, 심지어 레이크 쿼리 레이어 전반에서 공통 인터페이스가 되었습니다. 팀들은 SQL을:

• BI 도구와 분석가를 위한 안정된 계약으로
• 엔진이 바뀔 때 이식성 레이어로
• 뷰, 권한, 감사 접근 같은 거버넌스 표면으로 사용합니다

실행이 배치, 대화형, 스트리밍 등 다른 엔진에서 일어나더라도 SQL은 사용자-facing 언어로 남는 경우가 많습니다.

데이터 모델링과 거버넌스: 스키마는 여전히 중요

유연한 저장 방식이 구조 필요성을 없애진 않습니다. 명확한 스키마, 문서화된 의미, 통제된 진화는 다운스트림의 붕괴를 줄여줍니다.

좋은 거버넌스는 관료주의가 아니라 데이터를 신뢰 가능하게 만드는 것—일관된 정의, 소유권, 품질 검사, 접근 제어—에 가깝습니다.

과대광고를 배제한 실용적 체크리스트

플랫폼을 평가할 때 물어볼 것:

1. 워크로드 적합성: 주로 BI 대시보드, 탐색, ML 피처 생성, 운영 워크로드 중 무엇인가?
2. 지연 요구: 초, 분, 시간 단위인가? 스트리밍 신선도가 필요한가?
3. 데이터 형태: 넓은 이벤트 로그(칼럼형에 적합)인지, 많은 포인트 조회인지?
4. 동시성: 동시에 몇 명/몇 쿼리가 예상되는가? 예측 가능한가?
5. 정합성 요구: 강한 트랜잭션이 필요한가, 결국 일관성으로도 괜찮은가?
6. 운영 현실: 누가 운영할 것인가, 어떤 기술이 있으며, 새벽 2시에 실패 모드는 무엇인가?

벤더가 자신의 제품을 이 기본 항목들에 평이한 언어로 매핑하지 못하면, 그 "혁신"은 포장에 불과할 수 있습니다.

플랫폼을 구축하거나 구매하는 팀을 위한 핵심 시사점

스톤브레이커의 일관된 메시지는 단순합니다: 데이터베이스는 특정 작업을 위해 설계될 때 가장 잘 작동하며, 그 작업이 바뀔 때 진화할 수 있어야 한다는 점입니다.

1) 시스템을 워크로드에 맞춰라(하나의 엔진이 모든 걸 이기길 기대하지 마라)

기능 비교 전에 실제로 무엇을 해야 하는지 적어보세요:

• 분석: 긴 스캔, 대규모 집계, 많은 읽기
• 트랜잭션: 많은 소규모 업데이트, 엄격한 정합성, 빠른 응답 시간
• 혼합 워크로드: 둘 다 필요하지만 면밀한 튜닝과 우선순위가 요구됨
• 실시간 피드: 연속적인 수집과 증분 계산

유용한 규칙: 워크로드를 몇 문장으로 설명할 수 없다면, 유행어에 끌려 도구를 사게 될 가능성이 큽니다.

2) 오늘의 스키마만이 아니라 변화를 설계하라

팀들은 요구가 얼마나 자주 바뀌는지 과소평가합니다: 새로운 데이터 타입, 새 지표, 규정 준수 변경, 새로운 소비자들 등.

변화를 일상적이고 위험이 적게 만드는 플랫폼과 데이터 모델을 선호하세요:

• 저장, 쿼리, 확장 포인트의 분리
• 스키마 진화와 새 로직 롤아웃의 안전한 방법
• 유기적 성장에도 무너지지 않는 측정 가능한 성능

3) 올바름(정합성)은 제품 기능이다

빠른 답은 옳은 답일 때만 가치가 있습니다. 옵션을 평가할 때 시스템이 다음을 어떻게 다루는지 물어보세요:

• 동시 쓰기(둘 이상의 프로세스가 같은 레코드를 업데이트하면 어떻게 되는가?)
• 격리와 정합성(어떤 보장이 있고, 그것을 얻기 위해 무엇을 포기하는가?)
• 운영 실패 모드(재시작, 부분 장애, 백필(backfill))

4) 비전문가를 위한 실용적 평가 체크리스트

데모만 보지 말고 작은 "자체 데이터로 검증"을 하세요:

• 대표 쿼리 3–5개를 실행해 시간과 비용 측정
• 최고 동시성(예: 월요일 아침 스파이크) 테스트
• 데이터 신선도, 복구 절차, 누가 일상적으로 운영할지 검증

5) 아키텍처 결정을 실행 가능한 소프트웨어로 바꾸기

많은 데이터베이스 조언은 "올바른 엔진을 선택하라"에서 끝나지만, 팀은 그 엔진 주위에 어드민 패널, 메트릭 대시보드, 수집 서비스, 백오피스 워크플로우 같은 앱과 내부 도구들을 배포해야 합니다.

스키마 설계를 빠르게 반복하거나 작은 내부 "데이터 제품"을 반복 검증하려면, 채팅 기반 워크플로로 React 웹앱, 백엔드 서비스(Go + PostgreSQL), 모바일 클라이언트(Flutter)를 빠르게 생성해 주는 vibe-코딩 플랫폼 같은 도구(예: Koder.ai)가 유용할 수 있습니다. 이는 장기 인프라를 결정하기 전에 워크로드가 실제로 어떻게 작동하는지 검증할 때 특히 도움이 됩니다.

더 읽을 거리(직관을 키우기 위해)

더 깊이 들어가고 싶다면 칼럼형 저장소, MVCC, MPP 실행, 스트림 처리를 찾아보세요. 추가 설명 글들은 /blog에 있습니다.