제품 질문마다 데이터 구조가 달라져야 하는 이유는 전체 사용자의 분포, 몇 분 전 장애 추이, 확정 결제, 한 사용자의 사건 순서가 서로 다른 접근 방식과 정확도를 요구하기 때문입니다. 모든 질문을 하나의 실시간 테이블이나 거대한 대시보드로 풀면 속도·정확도·비용 중 무엇도 책임지기 어렵습니다. 질문별로 단위, 지연, 원천과 조회 경로를 정한 데이터 경로표가 필요합니다.
핵심 데이터 구조는 유행하는 기술에서 고르는 것이 아니라 질문의 범위와 시간 제약, 필요한 정확도, 수정 가능성, 조회 비용을 함께 따져 가장 단순한 경로로 설계해야 합니다.
먼저 보면 좋은 점
- 질문의 단위·시간·정확도·비용을 먼저 분류합니다.
- 분포·추이·거래·개별 조사를 서로 다른 경로로 둡니다.
- 한 구조가 모든 질문을 맡기 시작하면 분리합니다.
질문을 네 가지 접근 패턴으로 나눈다
“지난달 검색 실패는 어떤 질의에 몰렸나”는 전체 분포를 집계하는 질문입니다. “지금 검색 오류가 늘었나”는 빠른 추이, “이 주문은 환불됐나”는 확정 거래, “고객 한 명이 왜 결제 화면을 두 번 봤나”는 사건 순서 조사입니다. 같은 검색이라는 제품 영역이어도 읽는 범위와 허용 지연이 다릅니다.
데이터 경로표에 질문, 분석 단위, 기간, 목표 응답 시간, 허용 오류, 최종 원천, 예상 조회 빈도와 담당자를 적습니다. 기술 이름을 먼저 넣지 않습니다. 질문이 모호해 같은 칸에 전체 집계와 개인 조사가 함께 쓰이면 두 질문으로 나눠야 비용과 접근 범위를 판단할 수 있습니다.
전체 분포는 넓게 읽고 반복 계산을 줄인다
상품 앱에서 90일간 5천만 건의 검색 중 빈 결과 질의 상위를 찾는다면 행 하나씩 화면에 보여줄 필요가 없습니다. 필요한 차원으로 집계하고 반복 조회할 결과를 미리 계산하면 비용과 응답 시간을 줄일 수 있습니다. 원자료 보존 범위와 집계 정의가 달라질 때 재계산할 방법을 함께 둡니다.
예를 들어 상위 100개 질의가 실패의 38퍼센트를 차지한다면 사전어 개선 후보가 됩니다. 그러나 자유 입력값을 그대로 넓게 수집하거나 개인별 검색 이력을 기본 화면에 노출할 필요는 없습니다. 질문에 필요한 최소 수준으로 집계할 수 없다면 수집과 접근 설계를 멈추고 목적을 좁힙니다.
실시간 추이는 유실 허용 범위를 명시한다
배포 직후 오류율이 2퍼센트에서 12퍼센트로 뛰었는지는 빠르게 봐야 하므로 스트림이나 짧은 시간 창의 집계가 유용합니다. 이 경로는 늦게 온 사건이나 재전송으로 값이 바뀔 수 있음을 표시하고, 복구 판단에 필요한 정밀도만 요구합니다.
빠른 경로를 확정 KPI에 재사용하는 것이 반례입니다. 실시간 가입이 950건이고 다음 날 서버 계정이 1,000건이라면 장애 탐지에는 충분했을 수 있지만 획득비 계산에는 부족합니다. 차이가 사전 허용치보다 크면 알림 원인은 조사하되 확정 보고는 원천 집계를 기다립니다.
확정 거래는 상태 이력과 원장을 따른다
결제와 환불, 게임 재화는 현재 상태만 덮어쓴 표로는 왜 잔액이 달라졌는지 재구성하기 어렵습니다. 구매 사건과 환불 사건을 별도 사건으로 남기고 서버 원장의 주문 식별자, 금액, 상태 변경 시각을 기준으로 연결합니다. 클라이언트 사건은 사용 흐름을 설명하지만 최종 진실을 대신하지 않습니다.
한 사용자의 결제 버튼 클릭이 두 번 보여도 서버 승인은 한 건일 수 있고, 반대로 클릭 사건이 없어도 서버 정기 결제가 성립할 수 있습니다. 분석 로그 합계로 원장을 보정하지 않습니다. 대조 불가능한 식별 구조이거나 부분 환불을 표현하지 못한다면 재무성 제품 판단을 중단하고 원장 모델부터 보강합니다.
개별 조사는 좁고 감사 가능한 경로로 둔다
지원 문의를 해결하려고 한 계정의 최근 사건 순서를 볼 때 전체 분석가가 모든 원자료를 탐색할 필요는 없습니다. 대상과 기간, 조회 목적을 좁히고 필요한 서버 상태와 사건을 시간 순서로 연결하는 조사 경로를 둡니다. 전체 대시보드와 다른 접근 책임과 보존 정책을 적용합니다.
개별 사례 한 건에서 발견한 원인을 전체 사용자에게 일반화하지 않습니다. 먼저 동일 오류 코드나 버전 조건으로 영향 범위를 집계합니다. 한 사람을 찾기 위해 데이터 복제본을 여러 도구에 계속 늘려야 하거나 누가 조회했는지 알 수 없다면 편의 기능 추가를 멈추고 통제 가능한 조사 절차를 선택합니다.
오늘 반복 질문 네 개의 경로를 그린다
제품 회의, 장애 대응, 거래 확인, 고객 문의에서 실제 질문을 하나씩 가져오세요. 각 질문의 단위와 필요한 답변 시간, 틀렸을 때 비용, 최종 원천을 한 표에 씁니다. 같은 데이터셋 이름이 네 줄에 반복되더라도 조회 방식과 완료 조건이 다르면 별도 경로로 표시합니다.
그다음 가장 비싼 쿼리와 가장 위험한 임시 집계를 하나씩 고릅니다. 자주 보는 분포는 집계로 줄이고, 확정 거래가 실시간 로그에 의존하면 서버 원장 대조로 바꿉니다. 새 기술 도입은 현재 경로가 목표 지연이나 정확도를 못 맞춘다는 수치가 있을 때만 검토하며 그렇지 않으면 단순한 구조를 유지합니다.
메모
- 질문의 단위·지연·허용 오류·최종 원천을 적었는가?
- 실시간 추이와 확정 거래가 서로 다른 경로를 쓰는가?
- 오늘 줄일 비싼 조회와 원장으로 옮길 위험한 집계는 무엇인가?