실시간으로 움직이는 게임 데이터를 제대로 담아내려면, 시스템은 탁월한 흡수력과 정확한 기억력을 동시에 갖춰야 한다. 리그 오브 레전드의 경기 흐름은 초 단위로 급변하고, 패치마다 메타가 뒤집힌다. 이런 환경에서 롤토토나 롤배팅 같은 도메인의 분석 수요는 “지금” 무슨 일이 일어나는지, 그리고 “곧” 무엇이 일어날지를 묻는다. 데이터베이스와 파이프라인을 똑바로 설계하지 않으면 신뢰도는 바닥을 친다. 반대로, 정돈된 로그와 탄탄한 스키마가 뒷받침되면, 작은 신호에서 큰 인사이트를 끌어낼 수 있다. 이 글은 현장에서 실제로 부딪히며 쌓은 경험을 토대로, 롤실시간 로그를 활용한 데이터베이스 구축의 관점과 방법론, 그리고 그 사이에 존재하는 윤리, 법적 쟁점과 운영상의 함정을 정리한 기록이다.
합법과 윤리의 경계부터 정리하기
데이터를 수집하기 전에 가장 먼저 해결해야 할 문제는 “할 수 있는가”가 아니라 “해도 되는가”다. Riot Games의 API 사용 정책, 라이선스, 레이트 리밋, 상업적 이용 가능 범위를 꼼꼼히 확인해야 한다. 비공식 클라이언트 훅킹, 메모리 스캔, 안티 치트 우회, 이용자 동의 없는 개인정보 수집은 모두 금지 대상이다. 실시간 분석을 하려면 Spectator API, Live Client Data API, Match-v5와 Timeline 같은 공인 인터페이스를 중심으로 설계를 잡고, 필요한 경우 사용자 명시 동의를 받는 보조 채널을 붙인다.
국가별로 온라인 베팅과 정보제공 서비스의 법적 지형이 다르다. 특정 사설 베팅을 조장하거나, 먹튀검증을 빙자해 불법 사이트로 유도하는 행위는 문제가 된다. 반대로, e스포츠 데이터의 통계 분석, 합법 사업자를 위한 공정성 모니터링, 지표 기반의 콘텐츠 제작 같은 용도는 합법적 프레임에서 충분히 가능하다. 시스템을 구축할 때부터 접근권한, 로그 마스킹, 보존 기간, 옵트아웃 경로를 설계에 녹여두면 나중에 발목 잡히지 않는다.
롤실시간 로그의 실체를 이해하는 데서 출발
롤실시간 데이터라고 하면 두 가지 결을 구분하는 게 중요하다. 하나는 경기 중 관전과 이벤트 스트림이다. Spectator v4로 프로 경기나 일반 게임을 관전하면 1초 단위의 스냅샷과 키 이벤트를 받을 수 있다. 다른 하나는 경기 종료 후 제공되는 Match-v5와 Timeline이다. Timeline은 오브젝트 처치, 킬, 아이템 구매 등 이벤트가 순서대로 정리되어 있어 피처 엔지니어링에 유용하다. 두 채널은 성격이 다르다. 실시간성을 원하면 전자는 중요하지만, 품질 높은 라벨과 정제를 원하면 후자가 안정적이다.
문제는 레이트 리밋과 지연이다. 공용 키 기준으로 초당 수십 회, 분당 수백 회 수준의 호출 한도가 걸려 있으며, 지역별 엔드포인트를 나눠야 한다. 전 세계 판수와 큐 타입까지 욕심을 내면 금방 한도에 부딪힌다. 그래서 토픽을 잘게 나누고, 단계별 캐시를 둬야 한다. 예를 들어 소환사 인적 정보는 하루 캐시, 랭크 정보는 10분 캐시, 관전자 프레임은 1초 캐시처럼 수명과 갱신 주기를 분리하면 무리 없이 따라갈 수 있다.
시스템 골격: 스트림 우선, 배치 보완
데이터베이스 자체만으로는 실시간 분석을 감당하기 어렵다. 골격은 스트리밍 파이프라인이 담당하고, 데이터베이스는 용도에 따라 분화한다. 운영 환경에서 성과를 낸 조합은 대략 이런 구조다.
- 인제션 레이어에서 HTTP 풀러가 Riot API를 콜하고, 큐에 넣는다. 레이트 리밋을 지키는 토큰 버킷을 각 엔드포인트별로 둔다. 메시지 브로커는 Kafka 또는 Redpanda를 사용한다. 토픽은 region.queueType.granularity로 나눈다. 예: na.ranked.spectator, kr.normal.timeline. 스키마는 Avro나 Protobuf를 쓰고, 스키마 레지스트리로 진화를 관리한다. Riot API 필드가 패치마다 추가되거나 타입이 바뀌는 문제에 대비해야 한다. 스트림 프로세싱에는 Flink, Kafka Streams, 또는 ksqlDB를 쓴다. 여기서 세션 윈도, 조인, 피처 계산을 수행한다. 저장소는 역할을 분할한다. 원시 이벤트 로그는 S3 호환 객체 스토리지, 시계열 쿼리는 ClickHouse나 TimescaleDB, 키 밸류 캐시는 Redis, 정규화된 참조 데이터는 PostgreSQL 또는 MySQL로 보관한다.
실시간과 배치를 섞는 이유는 품질과 비용의 균형 때문이다. 경기 중에는 대략적 확률과 템포를 빠르게 추정하고, 경기 종료 후 배치로 고정 라벨과 오류 수정, 결측 채우기를 하게 된다. 이 이중 경로를 전제로 라벨 파이프라인을 분리해두면 롤배팅 같은 민감한 분석에 사용되는 피처의 신뢰도를 유지할 수 있다.
토픽과 스키마: 나중을 위해 처음부터 단단하게
운영을 하다 보면 “처음에 통일성을 좀 더 챙겼어야 했다”는 후회가 쌓인다. 필드명, 타입, 널 허용 여부를 엄격하게 정해두면, 나중에 스트림 조인과 다운스트림 모델 업데이트가 훨씬 수월하다. 예를 들어 participantId는 문자열로 통일하고, region과 platformId를 별도 필드로 적어두는 식이다. 타임스탬프는 반드시 UTC 기준의 밀리초 정수로 저장하고, 수신 시간과 원천 발생 시간을 분리해두면 지연 측정과 순서 보정이 가능하다.
또 하나, 상세 데이터와 요약 데이터를 같은 토픽에 뒤섞지 않는다. 퍼포먼스와 가독성 모두 망가진다. Spectator.frame와 spectator.event를 분리하고, timeline.event와 match.summary를 분리해두면 컨슈머가 가벼워진다. 특히 확장 시 파티션 키를 어떻게 잡느냐가 비용과 품질을 가른다. 보통 matchId를 파티션 키로 쓰면 같은 경기의 이벤트가 같은 파티션에 머물러 순서 보장이 쉬워진다. 반대로 소환사 단위 집계를 우선한다면 puuid를 파티션 키로 쓰되, 재정렬 비용을 감수해야 한다.
레이트 리밋과 캐싱: 격자처럼 쌓아 올리기
레이트 리밋 초과는 단순한 에러가 아니라 시스템 전체 리듬을 무너뜨리는 일이다. 백오프가 중첩되면 큐는 빠르게 불어나고, 이후의 데이터는 신선도를 잃는다. 해결책은 다층 캐시다. 장기 캐시는 사용자 프로필, 챔피언 데이터, 룬과 아이템 메타데이터를 담당한다. 중기 캐시는 랭크, 최근 경기 리스트, 매치 요약을 맡는다. 단기 캐시는 관전자 프레임과 타임라인 스냅샷이 대상이다. 각 캐시마다 TTL을 명확히 정하고, 캐시 키에 버전 태그를 붙여 패치 전후의 혼란을 줄인다. 챔피언 리워크가 있었던 주에는 버전 태그가 특히 중요하다.
실무에서 많이 쓰는 트릭이 두 가지 있다. 첫째, 동일 matchId에 대한 중복 호출과 저장을 전부 idempotent 하게 만든다. 키 충돌을 허용하고 덮어쓰게 하면, 실패 복구가 빠르다. 둘째, API 응답을 바이트 스트림으로 그대로 객체 스토리지에 적재하는 원본 스냅샷을 유지한다. 나중에 스키마가 변했을 때 재처리의 기준점이 된다.
저장소 선택: 쿼리 패턴이 답을 알려준다
데이터베이스는 “무엇을 자주, 어떻게” 묻는가에 맞춰 고른다. 실시간 확률 업데이트 같은 짧고 빈번한 읽기, 쓰기는 인메모리 캐시가 좋다. 대용량 집계와 히스토리컬 분석은 열 지향 데이터베이스가 낫다. 다음의 세 가지 패턴이 특히 자주 등장한다.
첫째, 초 단위 시계열. 예를 들어 골드 격차, 오브젝트 타이밍, KDA의 시간 추이. ClickHouse는 초당 수만 건의 인서트를 견디면서도 대시보드에서 빠르게 차트를 그려준다. 머지트리 엔진에 파티션을 patch_version 단위로 끊으면 패치일 정비가 편하다. TimescaleDB로도 충분히 소화할 수 있는데, PostgreSQL 생태계의 장점을 그대로 가져갈 수 있어 운영 복잡도가 낮다.
둘째, 조인 많은 조회. 예를 들어 특정 소환사의 최근 50경기 전적, 각 경기의 챔피언 메타데이터, 팀 조합 맥락. 이건 관계형 데이터베이스가 편하다. 정규화를 과하게 하면 읽기 성능이 무너진다. 실무에서는 3정규형과 디노말라이즈드 서머리 테이블을 혼용한다. 변경 데이터 캡처로 스트림에서 서머리를 유지하면 배치 리빌드를 줄일 수 있다.
셋째, 로그 원본의 보관. 객체 스토리지에 압축한 JSONL을 두고, Athena나 DuckDB, Spark로 애드혹 질의를 처리한다. 원본을 언제든 재해석할 수 있다는 게 큰 장점이다. 모델이 바뀌거나, 먹튀검증 같은 리스크 분석 로직을 강화할 때, 과거 사건을 다시 돌려보는 데 요긴하다.
실시간 피처 엔지니어링: 경기의 맥락을 숫자로 바꾸기
수치만 모으면 통찰이 생길 것 같지만, 실제로는 피처를 어떻게 조립하느냐가 성패를 좌우한다. 예를 들어 12분 전령, 20분 용 스택, 14분 골드 격차 같은 절대값은 의미가 제한적이다. 맥락이 들어가야 한다. 챔피언 조합의 파워 스파이크 타이밍, 한타 지향과 철거 지향의 전략 차이, 시야 점수와 오브젝트 시퀀싱의 관계처럼, 팀별 스타일을 반영한 파생 변수를 만든다. 프로 경기에서는 라인 스왑이나 역갱 빈도가 승패에 미치는 영향이 큼에도 일반 큐에서는 약하다. 데이터베이스는 이런 맥락의 분류 기준을 담을 수 있어야 한다. 그래서 팀, 리그, 큐 타입, 패치 버전, 지역을 기본 차원으로 잡고, 각 차원값의 의미가 바뀌면 버전업을 한다.
실시간 예측을 염두에 두면, 피처 계산의 지연을 500밀리초 안에 유지하고, 누락 데이터를 대비해 안전한 대체치를 준비한다. 예를 들어 관전자 API가 일시적으로 멈추면, 마지막 프레임을 기준으로 선형 보간을 하거나, 업데이트 타임스탬프가 오래되면 모델 입력을 중지한다. 억지로 결측을 채워 넣으면 예측이 요동친다.
품질 관리: 의심이 생기면 데이터를 이긴다
데이터는 늘 어딘가가 망가져 있다. 패치 당일에는 챔피언 아이디가 바뀌기도 하고, 특정 지역에서 일시적으로 타임라인이 늦게 도착한다. 이런 현실을 전제로 품질 관리 루틴을 세워야 한다. 다음은 짧은 점검표다.
- 소스 신뢰도 점수: 엔드포인트별 지연, 실패율, 필드 결측 비율을 지표화한다. 타임스탬프 검증: 이벤트 순서 역전, 중복, 스킵 구간을 탐지한다. 스키마 호환성: 새 필드 추가, 타입 변경, 삭제를 자동 감지해 알림을 보낸다. 레퍼런스 데이터 일치: 챔피언, 아이템, 룬 메타데이터 버전과 이벤트 데이터를 교차 확인한다. 모델 헬스체크: 예측 분포의 드리프트와 잔차 변화를 상시 모니터링한다.
이 체크리스트를 데일리 배치와 스트림에 동시에 얹으면 문제를 조기에 잡아낼 수 있다. 특히 롤배팅 같은 민감한 영역에서 데이터 품질은 신뢰와 직결된다. 신뢰가 무너지면 다시 쌓는 데 몇 배의 시간이 든다.
스케일 추정: 숫자에 속지 않으려면
초기에는 쿼리 몇 개, 시각화 몇 개로도 버틸 수 있다. 하지만 실시간 구독자가 늘고, 커버리지와 보존 기간이 확장되면 기하급수적으로 자원이 필요해진다. 대상 지역 4개, 큐 타입 3개, 동시 추적 경기 8천 건을 가정해 보자. 관전자 프레임이 초당 1건, 타임라인 이벤트가 경기당 평균 120건이라고 치면, 초당 8천에서 12천 사이의 메시지가 들어온다. 압축을 적용한 JSON 이벤트의 평균 크기가 600바이트라면, 인제션 레이어에서 초당 5에서 8MB, 하루에 400에서 700GB의 원시 로그가 쌓인다. 30일 보존만으로도 수십 테라바이트다. 이 규모에서 객체 스토리지는 비용 최적화가 결정적이다. S3 IA나 Glacier로 신속하게 티어링하고, 자주 쓰는 최근 3일만 핫 스토리지에 둔다.
스트림 프로세싱은 CPU보다는 네트워크와 디스크 I/O가 병목이 된다. 브로커 파티션을 충분히 쪼개고, 컨슈머 그룹을 수평 확장해야 한다. 실험상, 파티션당 초당 2천에서 5천 메시지가 안정 구간이었고, 컨슈머는 1 vCPU, 1GB 메모리당 800에서 1500 메시지를 무리 없이 처리했다. 물론 이벤트 크기와 연산량에 따라 달라진다.
보안과 프라이버시: 기본에 충실할수록 오래 간다
소환사명과 puuid는 민감하지 않은 식별자로 보이지만, 여러 소스가 결합되면 개인을 특정할 위험이 생긴다. 최소 수집, 최소 보존, 가명처리가 그래서 중요하다. API 키는 별도의 비밀 관리 서비스에 보관하고, 컨테이너 환경변수로 주입한다. 데이터베이스 접근은 역할 기반 권한과 감사 로그를 기본값으로 둔다. 대시보드나 API를 외부에 제공한다면, 레이트 리밋과 요청 검증을 붙여 과도한 쿼리가 백엔드를 무너뜨리지 않게 한다.
먹튀검증 같은 리스크 탐지 기능을 만들더라도, 특정 개인이나 팀을 부당하게 낙인찍는 방식은 피해야 한다. 지표와 증거, 재현 가능한 절차로 판단하고, 반론과 정정 경로를 열어두는 것이 장기적으로도 유리하다.
장애는 피할 수 없다, 복구는 설계할 수 있다
브로커 장애, 스키마 충돌, 외부 API 단절, 대시보드 폭주, 저장소 용량 초과, 이 모든 일이 언젠가는 터진다. 복구를 빨리 하려면 두 가지 원칙을 지킨다. 첫째, 변환 파이프라인은 언제든 재처리 가능해야 한다. 오프셋 관리를 잘해 특정 시간대만 리플레이하거나, 객체 스토리지의 원본에서 대상을 추출해 재주입한다. 둘째, 읽기 전용 모드가 있어야 한다. 신규 데이터 유입이 막히더라도, 기존 데이터를 통해 사용자 경험을 유지한다. 대시보드의 최근 5분 뷰를 비활성화하고 1시간 뷰로 자동 전환하는 식의 폴백이 유용하다.
대시보드와 알림: 실시간의 의미를 살리려면
실시간을 표방하는 서비스가 사실은 어제 데이터를 보여주는 경우가 많다. 사용자 체감은 잔인하다. 대시보드에는 신선도를 드러내는 지표를 넣어야 한다. 예를 들어 “마지막 업데이트 12초 전” 같은 안내를 상단에 두고, 30초가 넘어가면 색을 바꿔 경고한다. 내부 운영자에게는 레이트 리밋 임박, 스키마 드리프트, 이벤트 지연, 컨슈머 랙 증가 같은 알림을 Slack이나 PagerDuty로 보낸다. 알림은 적을수록 효과적이다. 거짓 양성이 많으면 아무도 보지 않는다.
UI 차원에서 과감하게 정보를 덜어내는 것도 중요하다. 숫자를 늘어놓기보다, 경기 흐름을 읽는 데 필요한 핵심 피처 몇 개만 강조한다. 예를 들어 12분 이전 전령 확보 여부, 14분 타워 격차, 20분 드래곤 스택, 상대 정글과의 골드 차, 이런 것들이 경기의 결을 설명한다.
모델과 예측: 겸손함이 정확도를 높인다
실시간 확률 모델을 돌리면 유혹이 커진다. 숫자를 앞세워 과도한 확신을 표방하기 쉽다. 하지만 롤은 혼돈이 많다. 패치 하나, 메타 전환 하나에 성능이 요동친다. 그래서 모델 운영에는 다음 장치들이 필요하다. 데이터베이스와 피처 저장소의 스냅샷 버전 태깅, A/B 혹은 챔피언 풀 단위의 슬라이스 평가, 패치일 자동 다운웨이트, 불확실성의 수치화가 그 핵심이다. 예측 확률 옆에 신뢰 구간이나 변동성 지표를 함께 보여주면 사용자가 해석하기 쉬워진다.
모델 성능이 떨어지는 구간을 발견하면, 원인을 세 갈래로 추적한다. 데이터 핸들링 오류, 피처 표현의 부적합, 레이블의 문제. 피처만 손보면 해결되는 경우가 대부분이다. 예를 들어 시간 기반 피처의 누적/증분값 혼용이 엉킨 경우, 단정한 누적 정의와 파생지표를 새로 짜면 성능이 돌아온다.
테스트 전략: 빠른 실패가 빠른 회복을 만든다
테스트는 개발 편의가 아니라 운영 먹튀검증 안전장치다. 스트림 처리 코드는 단위 테스트만으로 부족하다. 리플레이 테스트 벤치를 만들어, 특정 매치의 원본 로그를 정해진 피처와 결과로 가공하는 전 과정을 재현한다. 패치 전후, 리그별 샘플, 극단적 경기 길이 같은 경계값을 넣어두면 좋다. 인제션 레이어는 레이트 리밋 시뮬레이션을 포함해, 응답지연, 500 에러, 필드 누락, 스로틀링을 모사한다.
또한 운영 환경에서 카나리 릴리즈를 적극 활용한다. 토픽 일부, 지역 일부에만 새로운 파서를 적용해 이상 유무를 확인한다. 스키마 레지스트리는 호환성 룰을 엄격히 잡고, 컨슈머가 구버전을 이해하지 못해도 중단되지 않게 한다.
비용과 최적화: 화려함보다 일관성
처음에는 모든 걸 실시간으로 만들고 싶다. 하지만 돈은 현실을 직시하게 만든다. 비용을 줄이면서 품질을 지키는 요령은 단순하다. 가장 자주 보는 뷰와 쿼리부터 빠르게 만들고, 나머지는 배치와 캐시로 감싼다. 이벤트 압축은 lz4로도 충분히 이득이 크고, ZSTD는 저장비를 크게 줄여준다. Storage-tiering과 파티션 프루닝을 적극 활용하고, 오래된 데이터는 집계본만 남긴다. 스트림 윈도는 짧게, 서머리는 거칠게. 사용량이 늘어날수록 단순한 설계가 살아남는다.
먹튀검증과 공정성: 필요한 만큼만, 증거 기반으로
데이터베이스가 탄탄해지면, 자연스럽게 리스크 탐지 수요가 붙는다. 먹튀검증을 표방하는 서비스가 무분별한 폭로와 클릭베이트로 흘러 문제를 키운 사례를 여러 번 봤다. 실무에서 유효했던 원칙은 세 가지다. 첫째, 금전 거래나 보증과 관련된 판별은 외부 감사 기준에 맞춘다. 논리와 로그, 계정 흐름, 사용자 알림 기록까지 감사 가능한 형태로 남긴다. 둘째, 이상 징후는 지표와 임계치로만 말한다. 특정 팀이나 개인에 대한 가치판단을 섞지 않는다. 셋째, 정정과 이의 제기를 위한 채널을 상시 연다. 잘못된 판별을 신속히 되돌리는 능력이 신뢰를 만든다.
실시간 엔진을 이런 목적으로 쓸 때도, 개인정보와 위치 정보, 비공개 통신 같은 금지 영역을 넘지 않아야 한다. 합법과 윤리의 경계에서 시스템은 절제와 검증의 방식을 갖춰야 한다.
현장에서 배운 함정 다섯 가지
- 패치일 무시하기: 패치 직후 24시간은 모델 가중치를 낮추고, 스키마와 메타데이터를 먼저 동기화한다. 단일 진실의 원천 부재: 원시 로그, 정제본, 서머리를 명확히 구분하고 참조 우선순위를 정한다. 파티션 키 선택 오류: matchId, region, 시각을 상황에 맞게 조합하고, 재파티셔닝 비용을 계산한다. 모니터링의 과잉: 알림은 적고 정확해야 한다. 거짓 양성은 팀을 마비시킨다. 법적 검토의 후순위화: 초기에 변호사와 정책 담당자의 리뷰를 거쳐 쟁점을 미리 해소한다.
예시 설계: KR 서버 랭크 게임, 실시간 전황 요약
구체성을 위해 단일 사례를 상상해 보자. 대상은 KR 서버의 솔로랭크 게임. 목표는 경기 시작 10분 내 전황 요약을 대시보드에 표시하는 것이다. 인제션 레이어에서 소환사 큐를 통해 활성 매치를 탐색하고, Spectator API로 초당 프레임을 받아온다. 이벤트 파서는 프레임에서 골드, 경험치, 오브젝트 체력, 시야 점수 등 필요한 필드만 뽑는다. Kafka 토픽 kr.ranked.spectator.frame에 압축해 싣고, Flink 잡이 이 토픽을 읽어 30초 단위 세션 윈도에서 팀 단위 피처를 만든다. 예를 들어 8분 전령 여부, 10분 미드 1차 포탑 체력, 양 팀 정글러의 6레벨 도달 시간 차 같은 피처다.
이 피처 스트림은 ClickHouse의 분산 테이블에 들어가고, 대시보드는 최근 2분 데이터를 딥링크로 가져온다. 업데이트는 2초 주기, 사용자는 신선도를 상단에서 확인한다. Spectator 지연이 10초를 넘으면 대시보드가 자동으로 업데이트 주기를 늘리고, “지연 경고”를 시각적으로 전달한다. 경기 종료 후 Match-v5와 Timeline이 들어오면, 동일 matchId를 키로 배치 잡이 피처 정합성 검사를 돌린다. 관전자 기반 추정치와 타임라인 사실값이 일정 임계치 이상 어긋나면 피처 생성 로직을 알림 대상으로 올린다. 이렇게 실시간과 배치가 상호 보정되면, 초기의 불안정이 자연스럽게 줄어든다.
운영 조직과 문화: 도구보다 사람이 만든다
좋은 데이터베이스는 팀이 만든다. 인제션, 스트림, 스토리지, 모델링, 프론트엔드, 그리고 정책과 법무까지 사람과 역할이 엮인다. 모든 사람에게 공통 언어가 필요하다. 스키마 변경은 RFC 형태로 공유하고, 패치 노트를 팀 전체가 읽는 문화가 있으면 오류가 준다. 장애 보고서는 비난 없는 회고로 끝나야 한다. 특정인의 실수에 포커스를 두지 말고, 시스템이 그런 실수를 허용한 이유를 찾는다. 주간 리뷰에는 숫자뿐 아니라, 현장에서 만난 엣지 케이스를 기록으로 남기는 습관이 중요하다. 그 기록이 다음 문제의 예방 주사가 된다.
마지막으로, 롤토토 맥락에서 신중함을 더한다
이 생태계에서는 유혹이 많다. 롤배팅이나 실시간 확률 피드가 주는 자극은 강력하지만, 과신과 과장으로 이어지기 쉽다. 모델의 한계를 투명하게 드러내고, 합법과 윤리의 가드레일을 스스로 강화하는 게 장기적으로도 이익이다. 먹튀검증 같은 민감한 영역을 다룰수록, 증거 중심과 절제의 원칙은 더 단단해야 한다. 데이터베이스의 임무는 사실을 잊지 않게 하는 일이다. 그 사실을 축적하고, 되짚고, 맥락을 더하는 과정 속에서 서비스는 신뢰를 얻는다.
실시간 로그가 주는 속도의 쾌감은 크다. 하지만 오래 가는 시스템은 속도만으로 완성되지 않는다. 정직한 스키마, 다층 캐시, 재처리 가능한 파이프라인, 절제된 대시보드, 그리고 책임 있는 운영. 이 다섯 가지가 맞물릴 때, 롤실시간 데이터는 비로소 통찰로 변한다.