실시간 분석: 최신 데이터에서 더 빠른 의사 결정까지

실시간 분석은 흔히 지연 시간을 줄이기 위한 경쟁으로 여겨집니다. 하지만 모든 워크로드에 1초 미만의 지연 시간이 필요한 것은 아니며, 쿼리 속도는 전체 요소 중 일부에 불과합니다. 데이터가 여전히 오래된 상태일 수 있고, 동시성이 최대치에 이르면 성능이 저하될 수 있으며, 다운스트림 처리로 인해 결과가 유용한 시점을 넘겨 지연될 수도 있습니다.

진짜 핵심은 전체 분석 경로(새로운 데이터가 시스템에 유입되는 시점부터 사람, 애플리케이션 또는 에이전트가 결과를 활용하는 시점까지)가 해당 워크로드를 지원할 만큼 빠르게 진행되는지 여부입니다. 실시간 분석을 실용적인 관점에서 보려면 단순한 속도를 넘어, 충분히 최신이고 신뢰할 수 있는 결과를 만들어 내는 아키텍처까지 살펴봐야 합니다.

실시간 분석은 이벤트가 발생하는 즉시 또는 직후에 데이터를 분석하고 처리하여 사람이나 시스템이 현재 상황을 파악할 수 있도록 지원합니다. 실시간 분석의 핵심 특징은 동일한 쿼리 환경 내에서 최신 이벤트를 과거 데이터와 함께 분석할 수 있다는 점입니다. 예를 들어 사기 탐지 모델은 현재 트랜잭션을 수개월간의 계정 활동과 비교하여 이상 여부를 표시합니다. 정확한 지연 시간 요구 사항은 워크로드에 따라 달라집니다. 사기 검사는 밀리초 또는 초 단위로 결과가 필요할 수 있지만, 재고 대시보드는 몇 분마다 업데이트되어도 충분히 제 역할을 할 수 있습니다.

전체 경로는 일반적으로 다음과 같습니다.

각 스테이지는 전체 소요 시간에 영향을 미칩니다. 데이터 수집은 새로운 이벤트나 소스 시스템의 변경 사항이 분석 환경에 얼마나 빠르게 유입되는지를 결정합니다. 데이터 변환은 해당 데이터를 사용할 수 있도록 준비합니다. 데이터 거버넌스는 정의, 액세스 제어 및 기타 정책을 저지연 경로에 그대로 적용합니다. 서빙 계층은 결과를 소비하는 애플리케이션이나 사용자에게 충분히 빠르게 결과를 반환해야 하며, 대응은 정보가 아직 유용할 때 이루어져야 합니다.

이러한 경로를 살펴보면 쿼리 속도만으로는 시스템이 실시간으로 작동하는지 판단할 수 없는 이유를 알 수 있습니다. 예를 들어 대시보드는 몇 분 전의 데이터를 쿼리하면서도 200밀리초 만에 결과를 반환할 수 있습니다. 반대로 테이블이 지속적으로 업데이트되더라도 다운스트림 애플리케이션이 너무 느리다면 정반대의 문제가 발생할 수 있습니다.

지연 시간은 세 가지 지표로 구분하여 설명할 수 있습니다.

• 데이터 최신성은 사용 가능한 분석 데이터가 소스 이벤트나 소스 시스템보다 얼마나 뒤처져 있는지를 나타냅니다. 예를 들어 트랜잭션이 10:00:00에 발생하고 10:00:08에 쿼리할 수 있게 되었다면, 분석 쿼리를 시작하기도 전에 데이터는 이미 8초 뒤처진 상태입니다.

• 쿼리 지연 시간은 필요한 데이터가 서빙 계층에서 사용 가능해진 후 쿼리가 결과를 반환하기까지 걸리는 시간을 측정합니다. 선택적 조회는 거의 즉시 결과를 반환할 수 있지만, 대규모 과거 데이터 세트 전반에 걸친 광범위한 집계는 더 오래 걸릴 수 있습니다.

• 엔드투엔드 의사 결정 지연 시간은 이벤트 발생부터 데이터 가용성과 분석을 거쳐 사람이나 기계가 대응하기까지 걸리는 전체 소요 시간을 살펴봅니다. 아키텍처에 따라 일부 스테이지는 순차적으로 실행되지 않고 서로 겹칠 수도 있습니다.

세 가지 지표를 모두 살펴보면 지연이 실제로 어디에서 발생하는지 더 쉽게 파악할 수 있습니다. 준실시간 워크로드의 경우, 팀은 허용 가능한 지연 수준도 명확하게 정의해야 합니다. 예를 들어 ‘새 레코드는 5분 이내에 분석에 사용할 수 있어야 한다’와 같은 기준은 아키텍트, 애플리케이션 팀, 비즈니스 사용자에게 설계의 구체적인 기준점을 제공합니다.

실시간 분석은 저지연 분석 결과를 의미하는 포괄적인 용어입니다. 스트리밍 분석과 준실시간 분석은 모두 실시간 분석의 하위 유형입니다. 두 방식은 데이터가 시스템에 유입되는 방식과 이동 중에 변환되는지 여부에서 차이가 있습니다. 

스트리밍 분석에서는 데이터가 지속적으로 수집되며, 필요에 따라 이동 중에 처리된 후 저지연 쿼리를 위해 서빙 계층에 랜딩됩니다. 반면 배치 분석은 최신성이 주요 제약이 아닌 워크로드에 적합합니다. 

이는 일반적인 범위일 뿐 엄격한 경계는 아닙니다. 실질적인 차이는 데이터가 파이프라인을 통해 이동하는 방식(지속적 이동, 짧은 간격의 이동, 예약된 작업을 통한 이동)에 있습니다. 이것이 바로 데이터 최신성에 해당하는 요소입니다. 

쿼리 속도는 서빙 계층이 결정합니다. 실시간 분석에는 충분히 최신인 데이터와 충분히 빠른 쿼리가 모두 필요합니다. 따라서 처리 패턴은 쿼리가 얼마나 빠르게 결과를 반환해야 하는지보다 데이터가 얼마나 최신이어야 하는지에 따라 선택해야 합니다. 서빙 계층이 빠르고 워크로드가 배치 간격만큼의 지연을 허용한다면, 배치로 로드된 데이터로도 실시간 분석을 구현할 수 있습니다. 

지연 시간을 줄이는 데 드는 비용은 결과를 기다리는 동안 조직이 해당 결과로 해야 할 일을 하지 못하게 되는 경우에만 정당화됩니다. 정확한 지연 시간 목표는 사용 사례에 따라 다르지만, 판단 기준은 비슷합니다. 더 빨리 대응해서 얻는 가치가 지연 시간을 줄이는 데 드는 비용보다 큰가?

손실 방지

실시간 분석은 손실을 아직 피할 수 있을 때 팀이 대응할 수 있도록 지원합니다. 사기 감지에서는 권한 부여 전에 트랜잭션을 분석함으로써 시스템이 트랜잭션이 완료되기 전에 이를 중단하거나 검토할 수 있습니다. 제조 산업에서는 장비 텔레메트리를 통해 비정상적인 온도, 진동 또는 압력 수치를 신속하게 파악하여, 이상 상태가 다운타임으로 이어지기 전에 점검이나 유지 보수를 진행할 수 있습니다. 보안 팀도 인증, 엔드포인트 또는 네트워크 이벤트를 빠르게 분석하여 의심스러운 활동을 차단할 때 동일한 접근 방식을 활용합니다.

기회 포착

개인화, 추천, 차선책 제안(next-best action)에서는 최근 행동에 따라 시스템이 다음에 제시해야 할 내용이 달라질 수 있습니다. 예를 들어 리테일 기업은 현재 브라우징 활동을 제품 가용성 및 구매 이력과 결합하여 세션 중에 추천 내용을 업데이트할 수 있으며, 가격 책정 시스템은 수요나 재고 변화에 따라 오퍼를 조정할 수 있습니다.

운영 개선

운영 의사 결정은 작업 경로를 변경할 시간이 아직 남아 있을 때 변화를 파악할 수 있는지에 따라 좌우되는 경우가 많습니다. 공급망에서는 재고, 배송 또는 공급업체 업데이트를 예측 모델이나 리스크 모델에 반영할 수 있습니다. 이를 통해 팀은 재고를 재배치하거나 라우팅을 변경하고 공급 차질에 대응할 수 있습니다. 컨택 센터에서는 실시간 대화 기록이나 상호작용 데이터를 활용해 대화 중에 의도 분석이나 감성 분석을 수행할 수 있습니다. 덕분에 상담원은 상호작용이 끝나기 전에 바로 활용할 수 있는 가이드를 얻을 수 있습니다. 서비스 수준, 캠페인 최적화 및 기타 운영 워크플로우에도 유사한 패턴이 적용됩니다.

제품 가치 창출

일부 제품은 대시보드, API 또는 임베디드 경험을 통해 고객에게 분석을 직접 제공합니다. 이 경우 데이터 최신성과 쿼리 성능은 제품 그 자체의 일부가 됩니다. 고객 대상 애플리케이션은 현재 계정 활동, 운영 상태 또는 사용량 지표를 보여 줄 수 있으며, API는 최신 분석 결과를 다른 애플리케이션이나 워크플로우에 제공할 수 있습니다.

결과에 새 이벤트가 얼마나 빨리 반영되어야 하는지 파악했다면, 엔드투엔드 경로를 추적하여 지연 시간이 어디에서 누적되는지 확인할 수 있습니다.

일반적인 워크플로우는 다음과 같습니다.

1. 이벤트 또는 소스 시스템 변경 사항을 생성하거나 캡처합니다.

2. 해당 변경 사항을 수집하거나 복제합니다.

3. 필요에 따라 검증, 보강 또는 변환합니다.

4. 결과 데이터를 서빙 계층에서 사용할 수 있도록 합니다.

5. 분석 쿼리, 규칙 또는 모델을 실행합니다.

6. 결과를 사용자, 애플리케이션, 워크플로우 또는 에이전트에 전달합니다.

7. 사용 사례에서 요구하는 경우 대응 조치를 취합니다.

8. 전체 경로에서 최신성, 지연 시간, 정확성 및 장애를 모니터링합니다.

하지만 이러한 단계가 항상 순차적으로 실행되는 것은 아닙니다. 스트림 프로세서는 이벤트가 수집되는 동안 이를 변환할 수 있고, 다운스트림 연산은 증분 방식으로 실행될 수 있으며, 애플리케이션은 이벤트 간 상태를 유지할 수 있습니다. 궁극적으로 중요한 것은 엔드투엔드 소요 시간이며, 여기에 영향을 미치는 각 단계의 지연 시간과 변동성도 함께 고려해야 합니다.

사기 탐지 워크로드의 최대 응답 허용 시간이 10초라고 가정해 보겠습니다. 트랜잭션이 소스 시스템에서 쿼리 가능한 상태가 되기까지 일반적으로 6초가 걸린다면, 분석 쿼리가 시작되기도 전에 허용 시간의 절반 이상이 이미 소진됩니다. 각 스테이지에서 지연 시간을 측정하고 평균값만이 아니라 p50, p95, p99를 함께 살펴보면, 실제 프로덕션 환경에서 지연이 어디에서 누적되는지 파악할 수 있습니다.

각 스테이지의 지연 시간을 측정하면 시간이 어디에서 소요되는지 알 수 있지만, 프로덕션 환경의 동작 방식에는 또 다른 제약 조건이 따릅니다. 부하가 적을 때 양호해 보이던 쿼리 성능도 최대 동시성 상황에서는 저하될 수 있으며, 이벤트 처리량이 높다고 해서 다운스트림 데이터의 최신성이 보장되는 것은 아닙니다.

또한 파이프라인은 다운스트림 결과를 손상시키지 않으면서 불규칙한 이벤트 동작을 처리할 수 있어야 합니다. 이벤트는 늦게 도착하거나 순서가 뒤바뀌어 도착할 수 있으며, 전달 여부가 불확실한 경우 애플리케이션이 이벤트를 다시 전송할 수도 있습니다. 네트워크 중단으로 인해 데이터 누락이나 중복이 발생할 수도 있습니다. 사용하는 기술에 따라 팀은 리플레이, 중복 제거, 멱등성 쓰기, 오프셋, 이벤트 시간 처리 등을 활용해 다운스트림 상태의 일관성을 유지할 수 있습니다.

거버넌스 역시 아키텍처에 영향을 미칩니다. 최신 데이터를 별도의 서빙 시스템으로 옮기면 응답 시간은 개선될 수 있지만, 액세스 정책, 지표 정의, 계보를 다시 구현해야 하는 곳이 하나 더 늘어납니다. 

이러한 중복은 아키텍처가 확장될수록 관리하기 더 어려워집니다. Snowflake Interactive Analytics 수석 프로덕트 매니저인 Will Xu는 이렇게 말합니다. “데이터가 다른 곳에서 변환되기 위해 보안 환경을 벗어날 때마다 보안 규칙을 다시 만들고, 두 번 모두 제대로 설정했기를 바랄 수밖에 없습니다. 다섯 개의 도구를 이어 붙인 파이프라인에는 다섯 개의 장애 지점이 생기며, 업스트림의 사소한 변경이 다운스트림 대시보드를 소리 없이 망가뜨릴 수 있습니다.” 현재 데이터와 과거 데이터를 동일한 거버넌스 모델로 관리하면 액세스 제어 공백, 지표 불일치, 계보 단절의 위험을 줄일 수 있습니다.

최신 데이터는 다양한 방식으로 시스템에 유입될 수 있습니다. 일부 워크로드는 명시적인 이벤트 스트림에서 시작하는 반면, 다른 워크로드는 변경 데이터 캡처나 복제를 통해 운영 시스템의 삽입, 업데이트, 삭제 내용을 가져옵니다.

새 이벤트나 데이터베이스 업데이트가 분석 환경에 도달하면, 낮은 지연 시간 경로에는 즉각적인 분석 결과에 필요한 준비 작업만 포함되어야 합니다. 증분 처리를 활용하면 소스 데이터의 일부만 변경될 때 불필요한 재계산을 줄일 수 있습니다. 그렇다고 해서 반드시 이벤트 단위 스트리밍을 의미하는 것은 아닙니다. 증분 시스템도 일정에 따라 또는 최신성 목표에 맞춰 새로 고침할 수 있습니다.

많은 워크로드에서는 최신 이벤트와 함께 과거 컨텍스트도 필요합니다. 트랜잭션 금액, 센서 측정값, 고객 행동은 이전 행동, 확립된 기준선 또는 거버넌스가 적용된 비즈니스 정의와 비교할 수 있을 때 더 큰 의미를 갖는 경우가 많습니다.

데이터가 준비되면 서빙 계층은 사용자와 애플리케이션이 데이터를 얼마나 빨리 조회할 수 있는지를 결정합니다. 적합한 선택은 워크로드의 특성에 따라 달라집니다. 즉, 무엇을 쿼리하는지, 동시에 얼마나 많은 요청이 들어오는지, 과거 컨텍스트가 얼마나 필요한지, 데이터를 사용하는 환경에서 어느 수준의 지연 시간을 유지해야 하는지 등을 고려해야 합니다.

기술을 비교하기 전에 다음과 같이 요구 사항을 정리하는 것부터 시작하는 것이 좋습니다.

꼬리 지연 시간에는 특히 주의를 기울여야 합니다. 예를 들어 평균 쿼리 시간이 300밀리초라고 해도, p99 기준으로 요청에 3초씩 걸리는 사용자가 겪는 경험에 대해서는 많은 것을 알려 주지 못합니다. 인터랙티브 애플리케이션에서는 이처럼 느린 요청이 프로덕션 부하 상황의 사용자 경험을 좌우하는 경우가 많습니다.

인메모리 처리와 캐싱은 일부 액세스 패턴에서 조회 지연 시간을 줄일 수 있지만, 어느 쪽도 엔드투엔드 경로 전체의 문제를 해결하지는 못합니다. 캐시에도 여전히 최신성 정책과 무효화 로직이 필요합니다. 캐시에 업데이트가 늦게 반영되면, 매우 빠른 읽기는 단지 오래된 데이터를 더 효율적으로 반환할 뿐입니다.

일부 아키텍처에서는 이벤트 전송, 스트림 처리, 분석 서빙, 캐싱, 프레젠테이션에 각각 별도의 시스템을 사용해 이 문제를 해결합니다. 하지만 시스템이 하나 추가될 때마다 고유한 장애 모드, 거버넌스 경계, 운영 오버헤드가 생깁니다. 따라서 경로의 더 많은 부분을 단일 플랫폼으로 통합하면 복잡성과 리스크를 모두 줄일 수 있습니다.

데이터가 서빙 계층에 도달하면, 다음으로 고민할 문제는 사람과 애플리케이션이 데이터를 어떻게 사용할 것인가입니다. 대시보드, 고객 대상 애플리케이션, API, 대화형 인터페이스는 모두 동일한 낮은 지연 시간 아키텍처 위에서 작동할 수 있지만, 각각 성능 및 동시성 요구 사항이 다릅니다.

자연어 분석과 대화형 분석을 포함한 인터랙티브 분석의 경우, 팀은 최대 수요를 포함한 예상 동시성과 함께 허용 가능한 응답 시간을 정의해야 합니다. 개발 단계의 적은 트래픽에서 확인한 성능은 수백, 수천 명의 사용자나 애플리케이션이 동시에 요청을 보낼 때 상당히 달라질 수 있습니다.

쿼리 패턴도 예측 가능성에 영향을 미칩니다. 일반적으로 선택도가 높은 요청은 대량의 데이터를 스캔하는 개방형 작업보다 지연 시간이 더 일관적입니다. 비용이 많이 드는 쿼리가 유용한 경우, 데이터를 사용하는 애플리케이션에는 대체 방안(비동기 처리, 덜 세분화된 결과, 요청 처리에 시간이 더 걸린다는 명확한 안내 등)이 필요할 수 있습니다.

최신성 정보 역시 사용자가 필요로 하는 곳에 표시되어야 합니다. 예를 들어 ‘데이터 기준 시점’ 표시는 최신성에 따라 유용성이 달라지는 대시보드나 운영 화면을 해석하는 데 도움이 됩니다. 반면 애플리케이션과 API는 다운스트림 시스템이 프로그래밍 방식으로 평가할 수 있는 최신성 메타데이터를 제공할 수 있습니다.

Snowflake의 Will Xu는 이렇게 설명합니다. “실시간 수치와 최종 수치를 같은 것으로 취급해서는 안 됩니다. 실시간 수치에는 장중에 변동하는 주가처럼 ‘현재 기준’이라는 표시가 눈에 보이게 붙어 있어야 하고, 마감 수치는 감사를 거쳐야 합니다. 속도를 위해서는 팀에 라이브 데이터를 제공하되, 신뢰를 위해서는 최종 경계를 확정해야 합니다.” 

거버넌스가 적용된 정의는 이러한 모든 인터페이스에서 그대로 유지되어야 합니다. 매출, 활성 고객, 매출 총이익과 같은 지표는 결과가 대시보드, 애플리케이션, 자연어 응답 중 어디에 표시되든 동일한 의미를 가져야 합니다. 액세스 제어와 계보 정보도 데이터가 각 소비 계층에 도달할 때 함께 전달되어야 합니다.

예측 분석에서는 관리해야 할 시간 요구 사항이 여러 가지 있습니다. 팀은 세 가지 시간을 추적해야 합니다. 모델 입력 데이터의 최신성, 예측 생성에 걸리는 시간, 그리고 예측 이후 후속 조치가 이루어지기까지의 시간입니다.

피처 최신성은 모델 입력이 얼마나 최신 상태인지를 나타냅니다. 추론 지연 시간은 모델이 예측을 생성하는 데 걸리는 시간을 측정합니다. 액션 지연 시간은 예측 이후 그에 따른 대응이 이루어지기까지의 시간을 의미합니다.

이러한 단계가 반드시 같은 주기로 실행되는 것은 아닙니다. 일부 워크로드는 온라인 스코어링을 사용합니다. 이 방식에서는 이벤트가 발생하는 즉시 모델이 개별 이벤트를 평가합니다. 또 다른 워크로드는 새로운 피처 값이 제공될 때마다 몇 분 간격으로 예측을 갱신합니다. 이벤트 트리거 추론도 하나의 방법입니다. 대부분의 소스 이벤트는 새 예측을 유발하지 않지만, 특정 변경이 발생하면 새로운 예측이 수행됩니다. 어떤 패턴이 가장 적합한지는 예측이 얼마나 오랫동안 유효한지에 따라 달라집니다. 

피처가 더 최신이라도 일반적인 모델 관리는 여전히 필요합니다. 팀은 드리프트, 레이블 지연, 피드백 루프, 유입 데이터의 분포 변화를 고려해야 합니다. 

추천 시스템, 애플리케이션, AI 에이전트에서는 최신 데이터가 옵션 순위 지정, 작업 선택, 응답 생성에 사용되는 컨텍스트를 바꿀 수 있습니다. 예를 들어 추천 시스템은 현재 세션 액티비티를 구매 이력, 제품 가용성, 과거 선호도와 결합할 수 있습니다. 이벤트 캡처는 새로운 행동을 수집하고, 피처 업데이트는 이를 관련 컨텍스트에 반영합니다. 이어서 의사 결정 단계에서 출력을 선택하고, 피드백 신호를 통해 그 이후의 결과를 확인할 수 있습니다.

엔터프라이즈 데이터를 다루는 에이전트에게는 전달받은 컨텍스트가 요청된 작업을 수행하기에 충분히 최신인지 판단할 수 있는 방법이 필요합니다. 또한 액세스 정책이 적용되어야 하며, 필요한 정보가 오래되었거나 사용할 수 없는 경우에 대비해 관찰 가능한 대체 동작이 시스템에 마련되어 있어야 합니다.

이러한 워크로드에서 최신성은 애플리케이션이 이미 활용하고 있는 컨텍스트와 결합할 수 있을 때에만 유용합니다. 추천 엔진은 현재 세션 행동을 구매 이력과 함께 사용할 수 있습니다. AI 에이전트에게는 최신 운영 데이터와 더불어 거버넌스가 적용된 비즈니스 정의 및 권한이 필요할 수 있습니다.

실시간 분석은 단순히 이벤트를 더 빠르게 수집하는 것에 그치지 않습니다. 실시간 분석의 진정한 가치는 실시간 신호를 신뢰할 수 있는 의사 결정과 고객 경험으로 전환하는 데 있습니다. Snowflake는 연결되고 거버넌스가 적용된 하나의 플랫폼에서 실시간 분석 수명 주기 전체를 통합합니다.

Snowpipe Streaming을 사용하면 데이터가 도착하는 즉시 애플리케이션이 행을 Snowflake 테이블에 직접 기록할 수 있습니다. 테이블당 최대 20GB/s(비압축 기준)의 총 처리량과 최소 5초의 지연 시간을 지원하며, 수집량 기반의 단일 요금 가격 모델이 적용됩니다. Named Channels를 사용하면 각 채널 내에서 행이 전송한 순서대로 유지됩니다. 또한 내장형 오프셋 토큰을 활용해 애플리케이션이 재시작된 후에도 정확히 한 번(exactly-once) 전달을 구현할 수 있습니다. Elastic Channels를 사용하면 수천 개의 디바이스나 서비스가 자동으로 확장되는 하나의 공유 엔드포인트를 통해 단일 테이블로 데이터를 스트리밍할 수 있습니다. 최소 한 번(at-least-once) 전달을 지원하므로 하나의 연결 지점만 관리하면 됩니다. 

데이터 변환 측면에서는 Dynamic Table을 통해 다운스트림 대시보드, 애플리케이션, 사용자에게 필요한 분석용 변환 테이블을 정의할 수 있습니다. 구성된 새로 고침 모드와 지원되는 쿼리 작업에 따라 Dynamic Table은 전체 결과를 다시 계산하는 대신 변경된 행만 처리할 수 있습니다.

지연 시간에 민감한 쿼리 서빙의 경우, Interactive Analytics는 낮은 지연 시간과 높은 동시성이 요구되는 분석 워크로드에 맞게 설계된 Interactive Warehouse를 사용합니다. Interactive Warehouse는 표준, 동적, 인터랙티브 및 Iceberg 테이블을 지원합니다. 

Snowflake를 사용하면 별도의 실시간 데이터 스택을 구축하거나 분리된 서빙 시스템으로 데이터를 복제하지 않고도, 거버넌스가 적용된 하나의 플랫폼에서 데이터 수집부터 분석용 테이블, 실행 가능한 인사이트까지 연결할 수 있습니다. 실시간 데이터가 컨텍스트 및 거버넌스와 연결된 상태로 유지되므로, 팀은 운영 복잡성을 줄이고 비용 절감 가능성을 높이면서 이벤트에서 인사이트를 거쳐 실행으로 나아갈 수 있습니다.

유용한 실시간 아키텍처는 워크로드가 최신 데이터로부터 무엇을 필요로 하는지(실시간 뷰, 사람의 의사 결정, 애플리케이션 응답 또는 자동화된 작업)를 파악하는 데서 출발합니다. 이를 바탕으로 팀은 새 이벤트를 얼마나 빨리 사용할 수 있어야 하는지, 소비 전에 어느 정도의 변환이 필요한지, 서빙 계층이 유지해야 하는 쿼리 지연 시간은 얼마인지, 사용 사례가 p95 또는 p99에서 어느 정도의 변동성을 허용할 수 있는지 결정할 수 있습니다.

아키텍처는 현재 상황에 대한 뷰, 의사 결정 또는 응답을 지원할 수 있을 만큼 빠르게 새 정보를 시스템 전반으로 전달해야 합니다.