웨어하우스 네이티브 대 앱 네이티브 수익 툴링

모든 수익 툴링 결정에는 평가 과정에서 거의 언급되지 않지만 이후 수년간 소유권, 비용, 유연성을 좌우하는 갈림길이 있습니다. 그 툴이 여러분이 이미 가진 데이터 웨어하우스 위에서 실행되어, 여러분이 소유하고 통제하는 데이터로 계산하는가? 아니면 벤더의 환경 안에서 실행되어, 여러분이 들여다볼 수 없는 시스템으로 데이터 사본을 끌어가는가? 이것이 웨어하우스 네이티브 대 앱 네이티브 질문이며, 현대적 수익 플랫폼을 위한 레퍼런스 아키텍처에서 더 중대한 선택 중 하나입니다.

어느 쪽 답도 항상 옳지는 않습니다. 하지만 그 트레이드오프는 예측 가능하며, 이를 이해하는 평가자들은 데모에 휩쓸린 사람들보다 더 나은 장기적 결정을 내립니다.

두 가지 아키텍처

앱 네이티브 툴링은 자체 데이터 저장소를 유지합니다. 여러분은 소스를 연결하고, 벤더는 사본을 자신들의 인프라로 수집하며, 모든 계산이 그곳에서 일어납니다. 자체 데이터베이스, 컴퓨팅, UI를 가진 독립형 애플리케이션입니다. 대부분의 오래된 수익 툴은 이런 방식으로 작동합니다. 벤더가 구축하고 운영하기 더 단순하기 때문입니다.

웨어하우스 네이티브 툴링은 여러분이 이미 가진 클라우드 웨어하우스, 즉 Snowflake, BigQuery, Databricks, Redshift 위에서 실행됩니다. 데이터를 밖으로 복사하는 대신 로직을 안으로 밀어 넣고 데이터가 이미 있는 곳에서 모델을 실행합니다. 이는 "데이터 앱" 또는 "웨어하우스 퍼스트"라고 불립니다. 이 패턴이 등장한 이유는 점점 더 많은 회사가 이미 웨어하우스를 분석의 중심으로 삼고 있었고, 그것에서 데이터를 복사해 내는 것이 정확히 웨어하우스가 해결하려던 사일로 문제를 재현했기 때문입니다.

이는 사소한 차이가 아닙니다. 누가 원시 데이터를 보유하는지, 누가 컴퓨팅 비용을 지불하는지, 벤더가 제공한 것 너머로 시스템을 얼마나 확장할 수 있는지를 결정합니다.

트레이드오프가 좌우되는 지점

대체로 다섯 가지입니다.

데이터 소유권. 웨어하우스 네이티브는 여러분의 환경에 하나의 표준 사본을 유지합니다. 앱 네이티브는 벤더의 시스템에 두 번째 사본을 만들어내며, 이는 동기화 상태를 유지해야 하고 결국 어긋나게 됩니다. 이는 공유 데이터 계층이 방지하고자 하는 바로 그 발산을 재도입합니다.

확장성. 웨어하우스 네이티브에서는 벤더의 출력이 테이블입니다. 이를 조인하고, 확장하고, SQL로 자체 모델을 구축할 수 있습니다. 앱 네이티브 출력은 벤더의 UI와 API 뒤에 있으며, 그들이 노출하는 것만 얻을 수 있습니다.

컴퓨팅 비용과 통제. 웨어하우스 네이티브는 여러분이 보고, 측정하고, 조율할 수 있는 웨어하우스 컴퓨팅에서 실행됩니다. 비용은 투명하며 여러분의 것입니다. 앱 네이티브는 컴퓨팅을 구독료에 번들로 묶는데, 이는 더 단순하지만 불투명합니다.

거버넌스. 웨어하우스 네이티브는 여러분이 이미 웨어하우스에 설정한 접근 제어, 행 수준 보안, 감사를 그대로 물려받습니다. 이는 들리는 것보다 훨씬 중요하며, 거버넌스와 접근 제어가 그 이유를 다룹니다. 앱 네이티브는 별도로 설정하고 첫 번째와 조화시켜야 하는 두 번째 거버넌스 경계를 의미합니다.

가치 실현까지의 시간. 앱 네이티브는 대개 구축이 더 빠르고 웨어하우스가 전혀 필요 없습니다. 성숙한 데이터 인프라가 없는 팀에게는 실질적인 이점입니다. 웨어하우스 네이티브는 여러분이 이미 웨어하우스를 능숙하게 운영하고 있다고 가정하며, 그렇지 않다면 그저 여러분이 감당할 수 없는 복잡성을 이동시킬 뿐입니다.

즉 웨어하우스 네이티브는 편의성을 통제와 확장성으로 맞바꿉니다. 앱 네이티브는 통제를 단순함과 속도로 맞바꿉니다.

각각이 옳은 선택인 경우

앱 네이티브는 성숙한 웨어하우스나 이를 운영할 팀이 없을 때, 빠른 가치 실현을 원하고 이 사용 사례에서는 벤더가 데이터 계층을 소유하는 것이 괜찮을 때, 또는 사용 사례가 자기완결적이고 그 툴의 출력 위에 무언가를 구축할 계획이 없을 때 적합합니다.

웨어하우스 네이티브는 웨어하우스가 이미 여러분의 진실 공급원이고 수익 툴링이 그것을 깨뜨리기보다 강화하기를 원할 때 적합합니다. 확장성이 중요할 때, 즉 그 출력을 다른 데이터와 조인하거나 자체 모델에 공급하고 싶을 때 적합합니다. 데이터 거주지, 거버넌스, 보안이 벤더의 클라우드로 데이터를 복사하는 것을 비싸거나 불가능하게 만들 때 적합합니다. 그리고 장기적으로 생각하며 데이터 계층에서의 종속을 피하고 싶을 때 적합합니다.

우리가 사용하는 경험칙은 이렇습니다. 웨어하우스가 이미 회사 운영의 중심에 있을수록, 웨어하우스 네이티브를 선택할 근거는 더 강해집니다. 여러분이 투자한 웨어하우스에서 데이터를 복사해 내는 것은, 그 툴의 데모가 아무리 훌륭해 보여도 퇴보입니다.

대부분의 실제 아키텍처는 하이브리드다

현장에서는 그 경계가 흐려지며, 최고의 구성은 종종 둘 다 사용합니다. 플랫폼은 무거운 모델링을 웨어하우스 네이티브로 수행하여 데이터가 있는 곳에서 어트리뷰션과 스코어링을 계산하고, 워크플로, 활성화, 그리고 결과를 사람들이 일하는 시스템으로 라우팅하는 라이트백 계층을 위한 애플리케이션 계층을 제공할 수 있습니다. 데이터 집약적인 부분에서는 웨어하우스 네이티브의 소유권과 확장성을, 워크플로 부분에서는 앱과 같은 사용성을 얻는 것입니다.

벤더의 마케팅이 무엇을 말하든, 세 가지를 물어보십시오. 내 원시 데이터는 물리적으로 어디에 있고 어디서 계산되는가? 정직한 답이 "우리 클라우드의 사본"이라면, 브로슈어와 상관없이 여러분은 앱 네이티브를 쓰고 있는 것입니다. 벤더의 출력을 내가 통제하는 데이터로 얻을 수 있는가, 아니면 그들의 UI와 API를 통해서만 얻을 수 있는가? 그리고 그것에 대한 접근을 누구의 거버넌스가 집행하는가?

솔직한 답변은 실제 아키텍처를 드러냅니다. 그로부터 선택은 여러분의 데이터 성숙도, 시스템을 얼마나 확장해야 하는지, 데이터 계층을 소유하는 것에 얼마나 가치를 두는지에 달려 있습니다. 같은 답들이 API 우선 플랫폼이 여러분이 구매하는 것을 의미 있게 확장할 수 있는지를 결정합니다.

핵심 요약

• 앱 네이티브는 여러분의 데이터를 벤더 환경으로 복사해서 그곳에서 계산합니다. 웨어하우스 네이티브는 여러분이 이미 소유한 웨어하우스에서 계산합니다.
• 트레이드오프는 한쪽의 통제와 확장성, 다른 쪽의 단순함과 속도입니다.
• 성숙한 웨어하우스가 없거나 자기완결적인 사용 사례라면? 앱 네이티브. 웨어하우스가 진실 공급원이거나 거버넌스가 중요하다면? 웨어하우스 네이티브.
• 가장 강력한 구성은 대개 하이브리드입니다. 웨어하우스 네이티브 모델링에 워크플로와 라이트백을 위한 애플리케이션 계층을 더한 것입니다.
• 세 가지 질문이 마케팅을 꿰뚫습니다. 데이터가 어디에 있는지, 출력을 데이터로 얻을 수 있는지, 누구의 거버넌스가 적용되는지.

이 갈림길을 알면 데모의 화려함이 아니라 아키텍처로 수익 툴링을 판단할 수 있으며, Revnewo와 같은 플랫폼도 같은 세 가지 질문으로 평가받아야 합니다. 여러분의 웨어하우스가 이미 중심에 있다면, 새로운 툴이 그 투자를 존중하는지 깨뜨리는지 저울질해 보십시오.