2025년 5월 14일·7분
왜 OLTP와 OLAP 워크로드를 하나의 데이터베이스에 두지 않는가
트랜잭션(OLTP)과 분석(OLAP)을 한 데이터베이스에 섞으면 앱이 느려지고 비용이 늘며 운영이 복잡해집니다. 왜 문제가 생기는지와 대신 어떤 아키텍처를 택해야 하는지 알아보세요.
트랜잭션(OLTP)과 분석(OLAP)을 한 데이터베이스에 섞으면 앱이 느려지고 비용이 늘며 운영이 복잡해집니다. 왜 문제가 생기는지와 대신 어떤 아키텍처를 택해야 하는지 알아보세요.
사람들이 “OLTP”와 “OLAP”이라고 말할 때, 데이터베이스가 사용되는 두 가지 아주 다른 방식에 대해 말하는 것입니다.
**OLTP (Online Transaction Processing)**는 매번 빠르고 정확해야 하는 일상적 작업 뒤의 워크로드입니다. 생각해보세요: “지금 이 변경을 저장해라.”
전형적인 OLTP 작업에는 주문 생성, 재고 업데이트, 결제 기록, 고객 주소 변경 등이 포함됩니다. 이런 작업은 보통 작은 규모(몇 행), 빈번하며 사람이거나 다른 시스템이 기다리기 때문에 밀리초 단위 응답이 필요합니다.
**OLAP (Online Analytical Processing)**는 무슨 일이 일어났는지, 왜 그런지 이해하기 위해 사용하는 워크로드입니다. 생각해보세요: “많은 데이터를 스캔해서 요약해라.”
전형적인 OLAP 작업에는 대시보드, 추세 보고서, 코호트 분석, 예측 및 “슬라이스 앤 다이스” 질문(예: “지난 18개월 동안 지역과 제품 카테고리별 매출은 어떻게 변했나?”)이 포함됩니다. 이 쿼리들은 종종 많은 행을 읽고, 무거운 집계를 수행하며, 몇 초(혹은 몇 분) 동안 실행되더라도 ‘틀렸다’고 볼 수 없습니다.
핵심 아이디어는 간단합니다: OLTP는 빠르고 일관된 쓰기와 작은 읽기를 최적화하고, OLAP는 대규모 읽기와 복잡한 계산을 최적화합니다. 목표가 다르기 때문에 최적의 데이터베이스 설정, 인덱스, 저장 레이아웃, 확장 방식도 달라집니다.
또한 표현에 주목하세요: **드물게(rarely)**이지 **절대(never)**가 아닙니다. 작은 팀은 데이터량이 적고 쿼리 규율이 엄격하다면 한 데이터베이스를 공유할 수 있습니다. 이후 섹션에서는 먼저 깨지는 부분, 일반적인 분리 패턴, 프로덕션에서 안전하게 리포팅을 옮기는 방법을 다룹니다.
OLTP와 OLAP는 둘 다 "SQL을 사용"할 수 있지만, 각각 다른 작업에 최적화되어 있으며 이는 성공을 측정하는 방식에서 드러납니다.
OLTP(트랜잭션) 시스템은 체크아웃 흐름, 계정 업데이트, 예약, 지원 도구 같은 일상 작업을 구동합니다. 우선순위는 명확합니다:
성공은 종종 p95/p99 요청 시간, 오류율, 최대 동시성에서 시스템의 동작 같은 지표로 추적됩니다.
OLAP(분석) 시스템은 “이번 분기에 무엇이 바뀌었나?” 또는 “새 가격 정책 이후 어떤 세그먼트가 이탈했나?” 같은 질문에 답합니다. 이 쿼리들은 종종:
성공은 보통 쿼리 처리량, 인사이트 도달 시간, 복잡한 쿼리를 매번 수동 튜닝 없이 실행할 수 있는 능력으로 나타납니다.
두 워크로드를 하나의 데이터베이스에 강제로 얹으면, 시스템에게 아주 작은 고빈도 트랜잭션과 큰 탐색형 스캔을 동시에 잘하라고 요구하는 셈입니다. 결과는 보통 타협입니다: OLTP는 지연이 불규칙해지고, OLAP는 프로덕션을 보호하기 위해 제한되며, 팀은 누구의 쿼리가 ‘허용되는가’를 두고 논쟁합니다. 서로 다른 목표는 별도의 성공 지표를 요구하며, 보통 별도의 시스템을 요구합니다.
OLTP(앱의 일상적 트랜잭션)와 OLAP(리포팅·분석)이 같은 데이터베이스에서 실행되면 동일한 한정된 자원을 놓고 경쟁합니다. 결과는 단순히 “리포팅이 느려지는 것”이 아니라 종종 체크아웃 지연, 로그인 지연, 예측 불가능한 앱 장애로 나타납니다.
분석 쿼리는 오래 걸리고 무겁습니다: 큰 테이블 간 조인, 집계, 정렬 및 그룹화. 이들은 CPU 코어와 해시 조인·정렬 버퍼 같은 메모리를 독점할 수 있습니다.
반면 트랜잭션 쿼리는 보통 작지만 지연에 민감합니다. CPU가 포화되거나 메모리 압박으로 빈번한 이젝트(eviction)가 발생하면, 작은 트랜잭션도 큰 쿼기 뒤에서 기다리기 시작합니다—각 트랜잭션이 실제로는 몇 밀리초의 작업만 필요하더라도.
분석은 종종 큰 테이블 스캔을 트리거하고 많은 페이지를 순차적으로 읽습니다. OLTP는 반대로 많은 작은 랜덤 읽기와 인덱스·로그에 대한 지속적인 쓰기를 수행합니다.
이 둘을 합치면 스토리지 서브시스템이 호환되지 않는 접근 패턴을 동시에 처리해야 합니다. OLTP에 도움이 되던 캐시가 분석 스캔에 의해 ‘씻겨’가고, 리포트를 위한 스트리밍 데이터 때문에 쓰기 지연이 급증할 수 있습니다.
몇몇 분석가가 광범위한 쿼리를 몇 분간 실행하면 연결을 점유합니다. 애플리케이션이 고정 크기 풀을 사용한다면, 요청이 빈 연결을 기다리며 큐에 쌓입니다. 이 큐잉은 평균 지연은 괜찮아 보이게 만들지만, 꼬리 지연(p95/p99)을 고통스럽게 만듭니다.
외부에서 보면 이는 타임아웃, 느린 체크아웃 흐름, 지연된 검색 결과, 일반적으로 불안정한 동작으로 나타나며—종종 “리포팅 중에만” 또는 “월말에만” 발생합니다. 앱 팀은 오류를 보고하고, 분석 팀은 느린 쿼리를 보고하며, 실제 문제는 그 아래에 있는 공유된 자원 경쟁입니다.
OLTP와 OLAP는 단순히 "데이터베이스를 다르게 사용"하는 것이 아니라, 물리적 설계에서 정반대의 보상을 줍니다. 둘 다를 만족시키려 하면 보통 비싸고 여전히 성능이 부족한 타협안이 됩니다.
트랜잭션 워크로드는 하나의 주문을 불러오거나 하나의 재고 행을 업데이트하거나 특정 사용자에 대한 최근 20개의 이벤트를 조회하는 등 작은 데이터 조각을 자주 건드립니다.
이로 인해 OLTP 스키마는 행 지향 저장과 포인트 룩업 및 작은 범위 스캔을 지원하는 인덱스(주로 기본 키, 외래 키, 몇몇 고가치 보조 인덱스)에 기울어집니다. 목표는 예측 가능한 낮은 지연, 특히 쓰기입니다.
분석 워크로드는 종종 많은 행과 소수의 열만 읽습니다: “주별 지역별 매출”, “캠페인별 전환율”, “마진별 상위 제품”.
OLAP 시스템은 컬럼형 저장(필요한 열만 읽도록), 파티셔닝(오래된/무관한 데이터를 빨리 프루닝), 사전집계(물리화 뷰, 롤업, 요약 테이블)에서 이점을 얻어 리포트가 반복해서 같은 합계를 재계산하지 않게 합니다.
흔한 반응은 모든 대시보드를 빠르게 하기 위해 인덱스를 잔뜩 추가하는 것입니다. 그러나 추가 인덱스마다 쓰기 비용이 증가하고 저장공간이 늘며 유지관리 작업이 느려집니다.
데이터베이스는 플래너가 필터에 맞는 행 수, 인덱스의 선택도, 데이터 분포 같은 통계를 바탕으로 쿼리 계획을 선택합니다. OLTP는 데이터를 끊임없이 변경합니다. 분포가 바뀌면 통계가 흐트러지고 플래너는 어제는 좋았던 계획을 오늘은 선택할 수 있습니다.
여기에 무거운 OLAP 쿼리가 스캔과 조인을 섞으면 더 많은 변동성이 생깁니다: “최적의 계획”을 예측하기 어려워지고 한 워크로드에 맞춘 튜닝이 다른 워크로드를 악화시킵니다.
데이터베이스가 "동시성 지원"을 한다고 해도 무거운 리포팅과 라이브 트랜잭션을 섞으면 예측하기 어렵고 설명하기도 어려운 미묘한 성능 저하가 발생합니다.
OLAP 스타일 쿼리는 많은 행을 스캔하고 여러 테이블을 조인하며 몇 초 또는 몇 분 동안 실행됩니다. 이 동안 스키마 객체에 대한 잠금이 걸리거나 정렬/집계를 임시 구조에 쓰면서 간접적으로 잠금 경쟁을 증가시킬 수 있습니다.
MVCC(멀티버전 동시성 제어)가 있더라도 데이터베이스는 읽기와 쓰기가 서로를 막지 않도록 여러 버전의 행을 추적해야 합니다. 이는 도움이 되지만, 트랜잭션이 지속적으로 업데이트하는 핫 테이블을 쿼리가 건드릴 때 경쟁을 완전히 없애지 않습니다.
MVCC는 오래된 행 버전이 데이터베이스가 안전하게 제거할 때까지 남아있게 합니다. 장시간 실행되는 리포트는 오래된 스냅샷을 열어두어 정리가 공간을 회수하지 못하게 할 수 있습니다.
영향:
결과는 이중 타격입니다: 리포팅이 데이터베이스를 더 열심히 일하게 하고 또한 시간이 지남에 따라 시스템을 느리게 합니다.
리포팅 도구는 종종 더 강한 격리 수준을 요청하거나 실수로 긴 트랜잭션을 실행합니다. 높은 격리는 잠금 대기를 늘리고 엔진이 관리해야 할 버전 수를 증가시켜 대기 시간을 늘립니다. OLTP 관점에서는 대부분의 주문은 빠르게 기록되지만 일부가 갑자기 지연되는 것을 보게 됩니다.
월말에 재무팀이 한 달치 주문과 품목을 스캔하는 “제품별 매출” 쿼리를 실행하면, 그 동안 새로운 주문 쓰기는 계속 받아들이지만 vacuum이 오래된 버전을 회수하지 못하고 인덱스가 어지러워집니다. 주문 API는 때때로 타임아웃을 경험합니다—시스템이 "다운"해서가 아니라 경쟁과 정리 오버헤드가 조용히 지연을 초래하기 때문입니다.
OLTP 시스템은 예측 가능성이 생명입니다. 체크아웃, 지원 티켓, 잔액 업데이트는 ‘대부분 빠르다’는 수준으로는 충분하지 않습니다—사용자는 느린 순간을 기억합니다. OLAP은 반대로 버스티(또는 스파이크)합니다: 몇몇 무거운 쿼리가 몇 시간 동안 조용하다가 갑자기 많은 CPU, 메모리, I/O를 소비합니다.
분석 트래픽은 보통 루틴 주위에 몰립니다:
반면 OLTP 트래픽은 보통 더 안정적입니다. 두 워크로드가 동일 DB를 공유하면 분석 스파이크가 트랜잭션에 예측 불가능한 지연으로 전이됩니다—타임아웃, 느린 페이지 로드, 재시도가 발생해 더 많은 부하를 만듭니다.
리포트를 야간에 돌리거나 동시성을 제한하고 statement timeout을 강제하거나 쿼리 비용 상한을 설정하는 식의 전술로 피해를 줄일 수 있습니다. 이는 특히 "프로덕션에서의 리포팅"에 유용한 가드레일입니다.
하지만 이들은 근본적인 긴장 관계를 제거하지 않습니다: OLAP 쿼리는 큰 질문에 답하기 위해 많은 자원을 사용하도록 설계되었고, OLTP는 하루 종일 작은 자원 조각을 필요로 합니다. 예기치 못한 대시보드 새로고침이나 애드혹 쿼리, 백필(backfill)이 끼어들면 공유 데이터베이스는 다시 위험에 노출됩니다.
공유 인프라에서 한 사용자의 ‘시끄러운’ 분석 작업이 캐시를 독점하거나 디스크를 포화시키거나 CPU 스케줄링을 압박할 수 있습니다. OLTP 워크로드는 피해를 입게 되고 문제는 랜덤한 지연으로 보입니다—명확하고 반복 가능한 오류가 아니라 지연의 스파이크가 발생합니다.
OLTP와 OLAP를 섞으면 성능 문제뿐 아니라 일상 운영도 더 어려워집니다. 데이터베이스가 단일 "만물 상자"가 되고 모든 운영 작업이 두 워크로드의 위험을 함께 떠안게 됩니다.
분석 테이블은 넓고 빠르게 성장하는 경향이 있습니다(더 많은 히스토리, 더 많은 열, 더 많은 집계). 이 추가 볼륨은 복구 시나리오를 바꿉니다.
전체 백업은 더 오래 걸리고 저장공간을 더 소비하며 백업 창(window)을 놓칠 가능성을 높입니다. 복원은 더 심각합니다: 신속히 복구해야 할 때도 트랜잭션에 필요한 데이터뿐 아니라 분석용 대규모 데이터셋까지 복원해야 합니다. 재해 복구 테스트도 오래 걸려 자주 하지 않게 되고, 이는 바람직하지 않습니다.
트랜잭션 성장은 보통 예측 가능합니다: 고객 수 증가, 주문 증가, 행 수 증가. 반면 분석 성장은 울퉁불퉁합니다: 새 대시보드, 보존 정책 변경, 한 팀이 ‘원시 이벤트를 한 해 더 보관’하기로 결정하는 경우.
두 워크로드가 함께 있으면 다음을 쉽게 판단할 수 없습니다:
그 불확실성은 과다 프로비저닝(불필요한 여유에 비용 지불)이나 과소 프로비저닝(깜짝 중단)으로 이어집니다.
공유 데이터베이스에서는 ‘무해한’ 쿼리 하나가 사고로 이어질 수 있습니다. 쿼리 타임아웃, 워크로드 쿼터, 예약된 리포팅 창, 워크로드 관리 규칙 같은 가드레일을 추가하게 됩니다. 이것들은 도움이 되지만 취약합니다: 앱과 분석가가 같은 한계를 두고 경쟁하게 되고 한 그룹을 위한 정책 변경이 다른 그룹을 망칠 수 있습니다.
애플리케이션은 보통 좁고 목적에 맞는 권한을 필요로 합니다. 분석가는 종종 탐색하고 검증하기 위해 광범위한 읽기 권한을 필요로 합니다. 둘을 같은 DB에 두면 리포트가 작동하게 하기 위해 더 넓은 권한을 부여하려는 압박이 생기고, 실수의 폭발 반경이 커지며 민감한 운영 데이터에 접근할 수 있는 사람이 늘어납니다.
OLTP와 OLAP를 같은 데이터베이스에서 운영하려하면 처음에는 더 싸게 보일 수 있지만—확장하면서 문제가 드러납니다. 문제는 단지 성능이 아니라 각각의 워크로드를 “옳게” 확장하는 방식이 다른 인프라를 요구하고, 이를 결합하면 비싼 타협을 하게 된다는 점입니다.
트랜잭션 시스템은 많은 작은 업데이트, 엄격한 지연, 즉시 흡수해야 하는 버스트에 의해 제약받습니다. OLTP 확장은 보통 수직 확장(더 큰 CPU, 더 빠른 디스크, 더 많은 메모리)으로 시작합니다. 쓰기 중심 워크로드는 쉽게 팬아웃되지 않습니다.
수직 확장의 한계에 도달하면 샤딩이나 다른 쓰기 확장 패턴을 고려하게 됩니다. 이는 엔지니어링 오버헤드를 증가시키고 애플리케이션 변경이 필요할 수 있습니다.
분석 워크로드는 긴 스캔, 무거운 집계, 높은 읽기 처리량으로 확장됩니다. OLAP 시스템은 보통 분산 컴퓨트를 추가해 확장하고, 현대적 구성에서는 컴퓨트와 스토리지를 분리해 쿼리 연산을 독립적으로 늘릴 수 있습니다.
OLAP이 OLTP DB를 공유하면 분석을 독립적으로 확장할 수 없습니다. 전체 데이터베이스를 확장해야 합니다—트랜잭션이 괜찮더라도 말입니다.
리포트를 돌리면서 트랜잭션 성능을 유지하려면 팀은 프로덕션 DB를 과다 프로비저닝합니다: 여분의 CPU, 고성능 스토리지, 더 큰 인스턴스 등. 이는 OLAP 동작을 지원하기 위해 OLTP 비용을 지불하는 결과를 낳습니다.
분리를 하면 각 시스템을 그 목적에 맞게 사이징할 수 있어 과다 프로비저닝을 줄입니다: OLTP는 예측 가능한 저지연 쓰기를 위해, OLAP는 버스티한 대규모 읽기를 위해. 결과적으로 전체 비용이 더 저렴해지는 경우가 많습니다—비록 시스템이 두 개가 되더라도—프로덕션에서 리포팅을 계속 돌리기 위해 프리미엄 트랜잭션 자원을 사지 않기 때문입니다.
대부분의 팀은 트랜잭션 워크로드(OLTP)를 분석 워크로드(OLAP)와 분리하기 위해 두 번째 “읽기 지향” 시스템을 추가합니다. 하나의 DB에 억지로 둘을 얹지 않습니다.
첫 단계로 흔한 방법은 OLTP DB의 읽기 복제본에 BI 도구를 연결해 쿼리하게 하는 것입니다.
장점: 애플리케이션 변경 최소, 익숙한 SQL, 빠른 설정.
단점: 여전히 동일 엔진과 스키마를 사용하므로 무거운 리포트가 복제본의 CPU/I/O를 포화시킬 수 있고, 일부 리포트는 복제본에서 지원되지 않는 기능을 요구할 수 있으며 복제 지연으로 수치가 몇 분(또는 그 이상) 뒤처질 수 있습니다. 지연은 사건 조사 시 혼란을 만듭니다.
적합한 경우: 소규모 팀, 적당한 데이터 볼륨, “준실시간”이 좋지만 필수는 아니고 리포트 쿼리가 통제되는 경우.
여기서는 OLTP는 쓰기와 포인트 조회에 최적화된 상태로 유지하고, 분석은 스캔, 압축, 대규모 집계에 적합한 데이터 웨어하우스로 보냅니다.
장점: 예측 가능한 OLTP 성능, 빠른 대시보드, 분석가 동시성 향상, 성능·비용 튜닝의 명확한 분리.
단점: 추가 시스템 운영이 필요하고 분석 친화적인 데이터 모델(보통 스타 스키마)을 만들어야 합니다.
적합한 경우: 데이터가 성장하고 이해관계자가 많으며 리포팅이 복잡하거나 OLTP 지연 요구사항이 엄격한 경우.
주기적 ETL 대신 OLTP 로그에서 CDC로 변경을 스트리밍해 웨어하우스로 보냅니다(종종 ELT와 함께 사용).
장점: OLTP에 미치는 부하를 줄이면서 더 신선한 데이터, 점진적 처리, 감사 가능성 개선.
단점: 구성 요소 증가와 스키마 변경 처리에 주의 필요.
적합한 경우: 대규모 볼륨, 높은 신선도 요구, 데이터 파이프라인을 운영할 준비가 된 팀.
트랜잭션 DB(OLTP)에서 분석 시스템(OLAP)으로 데이터를 옮기는 것은 단순한 “테이블 복사” 이상의 일입니다. 신뢰할 수 있고 프로덕션에 영향을 덜 주는 파이프라인을 구축하는 것이 목표입니다.
**ETL(추출·변환·적재)**은 데이터를 웨어하우스로 적재하기 전에 정리하고 변형합니다. 웨어하우스에서 계산 비용이 비싸거나 저장할 것을 엄격히 통제하고 싶을 때 유용합니다.
**ELT(추출·적재·변환)**은 먼저 원시에 가까운 데이터를 적재한 뒤 웨어하우스 안에서 변환합니다. 설정이 빠르고 진화하기 쉬워 요구사항이 바뀔 때 재작업이 줄어듭니다.
실용 규칙: 비즈니스 로직이 자주 바뀌면 ELT가 재작업을 줄이고, 거버넌스상 큐레이션된 데이터만 저장해야 하면 ETL이 더 맞습니다.
**CDC(Change Data Capture)**는 OLTP 로그로부터 삽입/갱신/삭제를 스트리밍해 분석 시스템으로 보냅니다. 큰 테이블을 반복 스캔하는 대신 변경된 것만 옮기는 방식입니다.
가능하게 하는 것들:
신선도는 기술적 비용이 수반되는 비즈니스 결정입니다.
이해관계자에게 "신선함"의 SLA(예: “데이터는 15분 이내 지연”)를 정의하세요.
파이프라인은 보통 조용히 고장납니다—누군가 수치가 틀렸다고 알아차릴 때까지요. 다음 같은 가벼운 검사를 추가하세요:
이런 안전장치는 OLAP를 신뢰할 수 있게 하고 OLTP를 보호합니다.
OLTP와 OLAP를 같이 유지하는 것이 무조건 잘못된 건 아닙니다. 애플리케이션이 작고 리포팅 요구가 좁으며 분석이 고객에게 영향을 주지 않도록 엄격한 경계가 유지된다면 합리적 임시 선택일 수 있습니다.
소규모 앱에 경량 분석과 엄격한 쿼리 제한이 있는 경우 하나의 DB로 충분할 수 있습니다—특히 초기 단계에서. 여기서 핵심은 ‘경량’의 정의에 정직한 것입니다: 소수의 대시보드, 적당한 행 수, 쿼리 실행 시간 및 동시성에 대한 명확한 상한.
제한된 반복 리포트에는 물리화 뷰나 요약 테이블이 많은 도움이 됩니다. 원시 거래를 스캔하는 대신 일별 합계나 주요 요약을 미리 계산해 두면 대부분의 쿼리를 짧고 예측 가능하게 유지할 수 있습니다.
지연된 수치를 사용자가 허용할 수 있다면 비업무 시간 리포팅 윈도우도 도움이 됩니다. 리포팅 전용 역할과 더 엄격한 권한 및 자원 제한을 고려하세요.
트랜잭션 지연 상승, 리포트 실행 시 반복되는 사건, 커넥션 풀 고갈, 또는 “한 쿼리가 프로덕션을 다운시켰다”는 이야기가 들리면 안전지대를 벗어났습니다. 그때는 데이터베이스 분리(혹은 최소한 읽기 복제본 사용)가 최적화가 아니라 기본적 운영 위생이 됩니다.
분석을 프로덕션 DB에서 분리하는 작업은 대개 큰 리라이트가 아니라 보고를 가시화하고 목표를 설정하며 통제된 단계로 이전하는 일입니다.
가정이 아닌 증거로 시작하세요. 다음을 추출하세요:
BI 도구의 애드혹 SQL, 예약된 내보내기, CSV 다운로드 같은 ‘숨은’ 분석도 포함하세요.
최적화할 목표를 문서화하세요:
이렇게 하면 “느리다” vs “괜찮다” 같은 논쟁을 줄이고 올바른 아키텍처를 선택할 수 있습니다.
목표를 만족하는 가장 단순한 옵션을 고르세요:
복제 지연/파이프라인 지연, 대시보드 실행 시간, 웨어하우스 비용을 모니터링하세요. 쿼리 예산(타임아웃, 동시성 한도)을 설정하고 사건 대응 매뉴얼을 마련하세요: 신선도가 떨어지거나 로드가 급증하거나 핵심 지표가 일치하지 않을 때 무엇을 할지 명확히 하세요.
초기에 빠르게 가는 상황에서 가장 큰 위험은 핵심 트랜잭션 경로에 분석이 은연중에 섞여 들어가는 것입니다(예: 대시보드 쿼리가 조용히 ‘프로덕션 중요’가 되는 경우). 이를 피하는 한 가지 방법은 분리를 초기 설계에 포함시키는 것입니다—작은 읽기 복제본으로 시작하더라도 아키텍처 체크리스트에 분리 지점을 명시하세요.
플랫폼 예: Koder.ai 같은 플랫폼은 OLTP 측(React 앱 + Go 서비스 + PostgreSQL)을 프로토타입하고 계획 단계에서 리포팅/웨어하우스 경계를 스케치해 실제 배포 전에 검증할 수 있게 도와줍니다. 제품이 성장하면 소스 코드 내보내기, 스키마 진화, CDC/ELT 구성 요소 추가를 통해 “프로덕션에서의 리포팅”이 영구적 습관이 되는 걸 막을 수 있습니다.
**OLTP (Online Transaction Processing)**는 주문 생성, 재고 업데이트, 결제 기록 같은 일상적 작업을 처리합니다. 우선순위는 낮은 지연(latency), 높은 동시성, 그리고 정확성입니다.
**OLAP (Online Analytical Processing)**는 대규모 스캔과 집계를 통해 비즈니스 질문(대시보드, 추세, 코호트 분석 등)에 답합니다. 우선순위는 처리량, 유연한 쿼리, 빠른 요약이며 밀리초 응답시간을 요구하지 않습니다.
두 워크로드가 같은 자원을 놓고 경쟁하기 때문입니다:
결과적으로 핵심 사용자 동작에 대한 p95/p99 지연이 예측 불가능하게 증가합니다.
대부분의 경우 아닙니다. 대시보드를 빠르게 하려고 인덱스를 추가하면 오히려 역효과가 납니다:
분석에는 보통 파티셔닝, 컬럼형 저장소, 사전집계(물리화 뷰, 롤업, 요약 테이블) 같은 기법이 더 효과적입니다.
MVCC는 읽기와 쓰기를 막지 않도록 돕지만 혼합 워크로드를 ‘공짜’로 만들지는 않습니다. 현실적 문제는 다음과 같습니다:
따라서 명백한 블로킹이 없어도, 무거운 분석 작업은 시간이 지남에 따라 성능을 악화시킵니다.
다음과 같은 증상이 보이면 분리할 때입니다:
대시보드 새로고침 때 시스템이 ‘무작위로 느려진다’면 혼합 워크로드의 전형적인 신호입니다.
읽기 복제본은 보통 첫 단계로 적합합니다:
데이터 볼륨이 적고 '몇 분 지연'이 허용될 때 좋은 브리지 솔루션입니다.
다음 상황에서 데이터 웨어하우스가 더 적합합니다:
일반적으로 분석에 친화적인 모델(스타/스노우플레이크 스키마)과 데이터를 적재하는 파이프라인이 필요합니다.
**CDC (Change Data Capture)**는 OLTP 로그에서 삽입/갱신/삭제를 스트리밍해 분석 시스템으로 전달합니다.
장점:
단점은 구성 요소가 늘어나고 스키마 변경·정렬(ordering) 같은 문제를 신중하게 처리해야 한다는 점입니다. 전통적인 대규모 ETL 쿼리를 프로덕션에서 돌리는 것보다 보통 더 나은 선택입니다.
선택은 비즈니스 로직 변경 빈도와 저장하려는 데이터 성격에 달려 있습니다:
실무적으로는 빠르게 시작하기 위해 ELT로 시작한 뒤, 핵심 지표가 안정되면 거버넌스(테스트·큐레이션)를 추가하는 접근이 흔합니다.
예—일시적으로는 가능합니다. 조건은 분석이 정말 가볍고 강력한 가드레일이 있어야 한다는 것뿐입니다:
리포팅이 반복적으로 지연을 유발하거나 풀 고갈·프로덕션 장애가 발생하면 즉시 분리해야 합니다.