Howden Group의 CDO가 데이터 제품 모델이 인수 합병 속도를 따라가지 못하고 한계에 부딪히는 이유와 그 대안인 에이전트 지원(agent-ready) 데이터 레이어의 모습에 대해 설명합니다.
작성자: 앨리 맥그루
전통적인 엔터프라이즈 데이터 플레이북은 특정 속도를 전제로 합니다. 전략을 설계하고, 플랫폼을 구축하고, 체계적으로 소스를 온보딩하며, 주요 유스케이스별로 제품을 출시합니다. 계획이 곧 결과 물이며, 이 결과물은 영구적으로 지속되도록 설계됩니다.
하지만 이 플레이북은 원래 의도하지 않았던 방식으로 스트레스 테스트를 받고 있습니다. 인수를 통해 성장하고, 에이전트 기반 워크플로우를 구축하며, 새로운 데이터 소스를 빠르게 흡수하는 기업들은 느린 시대에 맞춰 수립된 전략이 비즈니스 자체의 제약 요인이 된다는 사실을 깨닫고 있습니다. 특정 속도에서 잘 작동하던 아키텍처, 분류 체계(taxonomy) 및 운영 모델이 다음 단계의 속도에서는 오히려 걸림돌이 되기 시작합니다.
Barry Panayi는 50개국 이상에서 25,000명의 직원을 두고 운영 중인 글로벌 보험 중개, 인수 및 재보험사 Howden의 그룹 최고 데이터 책임자(Group Chief Data Officer)입니다. 5년 전 이 회사의 임직원은 10,000명이었습니다. 지난해에는 매주 한 개 이상의 기업을 인수했습니다. Howden은 Databricks에서 엔터프라이즈 데이터 플랫폼을 운영하며 100개 이상의 원천 소스를 통합 아키텍처로 단일화했습니다. 이를 통해 규제 보고부터 Databricks Genie를 통한 대화형 분석에 이르기까지 모든 작업을 지원하고 있습니다.
이 블로그에서 Barry는 AI 소비가 나아가는 방향에 기존의 설계 방식이 왜 적합하지 않은지 설명합니다. 제품 모델은 번거로워지고, 데이터 대조(reconciliation) 주기는 비용이 많이 들며, 대시보드 백로그는 병목 현상이 됩니다. 아래에서 Barry는 그 대신 무엇을 구축해야 하는지 설명합니다.
Aly McGue: 유스케이스당 하나의 제품을 매핑하는 모델이 특정 시점부터 무너지기 시작한다고 말씀하셨습니다. 어떤 의미인지, 그리고 이를 대체하는 것은 무엇인지 설명해 주시겠습니까?
Barry Panayi: 저는 이 모델이 번거로워지는 것을 목격하기 시작했습니다. 데이터 레이어를 거버넌스가 적용된 개방형 서비스의 집합으로 생각하면, 다음에 어떤 AI 요구사항이 발생하더라도 훨씬 더 유연하게 적응할 수 있습니다.
우리는 비즈니스 전반에 데이터를 전달하는 에이전트에게 데이터를 제공하게 될 것이며, 이를 위해서는 다른 설계 사고방식이 필요합니다. 소비 주체가 더 이상 대시보드와 분석가에 국한되지 않는다면 모든 유스케이스를 미리 정의할 수 없습니다. 에이전트는 우리가 예상하지 못한 방식으로 데이터를 구성할 것입니다. 서비스 레이어는 이를 전제로 하지만, 제품 카탈로그는 그렇지 않습니다.
제가 사람들에게 플랫폼이 구축된 후가 아니라, 초기에 조직 내에서 프로세스 및 에이전트 기반 작업을 이끄는 담당자를 참여시키라고 말하는 이유도 바로 이 때문입니다.
Aly: Howden은 지난해 매주 한 개 이상의 기업을 인수했습니다. 이러한 속도가 데이터 조직에 어떤 영향을 미쳤으며, 아키텍처 측면에서 무엇을 변경해야 했나요?
Barry: 제가 처음 합류했을 때 수집된 데이터 소스는 약 80개였고, 인수 후 데이터를 통합하는 데 약 6개월이 걸렸습니다. 인수 속도를 감안할 때, 이는 사람들이 당장 결과가 필요했기 때문에 사일로를 만들거나 다른 곳에서 데이터를 가 져오고 있음을 의미했습니다. 데이터 커버리지가 충분하지 않았기 때문에 부서 전반에서 도입률이 저조했습니다.
이는 단순한 기술적 현대화가 아니었습니다. 파편화, 느린 통합, 중복 작업으로 인한 비용을 제거하는 것이 핵심이었습니다. 아키텍처 측면에서 우리는 다른 방향으로 전환했습니다. 이전 설정에서는 데이터 마스터링과 품질 검사를 보고 레이어에 가까운 다운스트림에서 처리했습니다. 우리는 데이터가 더 빨리 사용될 수 있도록 수집 단계에 최대한 가까운 곳에서 이 작업이 이루어지도록 해야 했습니다. 이 전환이 전체 타임라인을 바꾸어 놓았습니다.
Howden의 가장 큰 강점 중 하나는 비즈니스의 서로 다른 부서 간의 협업입니다. 그리고 이를 가능하게 하는 원동력이 바로 데이터입니다. 동료가 나에게 도움이 될 만한 어떤 데이터를 가지고 있는지, 그리고 내가 그들에게 어떻게 도움을 줄 수 있는지 알아야 합니다. 데이터를 완전히 수집하고 마스터링하지 않더라도, 단지 시각화하여 보여주는 것만으로도 확보할 수 있는 비즈니스 기회가 정말 많았습니다.
Aly: 소스가 그렇게 많으면 동일한 지표가 여러 개의 올바른 버전으로 존재할 수 있습니다. 수동 데이터 대조 작업에 팀의 시간을 낭비하는 것을 어떻게 해결하셨나요?
Barry: 동일한 데이터 포인트에 대해 최대 4가지 버전이 존재할 수 있었고, 각자의 컨텍스트에서는 모두 올바른 데이터였습니다. 공통 데이터 모델이나 분류 체계가 없었기 때문에, 저희 팀은 특정 질문에 어떤 버전이 올바른 답인지 파악하는 데 많은 노력을 기울여야 했습니다.
임원진은 항상 필요한 정보를 얻었습니다. 우리는 숫자가 일치하도록 확실히 대조했습니다. 하지만 수동 대조 작업에는 더 가치 있는 업무에 투입할 수 있었던 시간과 리소스가 소모되었습니다. 이후 저희는 플랫폼과 함께 표준 데이터 모델인 Accord 데이터 모델을 구축했습니다. 이를 통해 로직을 성문화하여 매번 사람이 확인하는 대신 대조 작업이 내장되도록 했습니다.
이것이 더 광범위한 핵심입니다. 분류 체계가 성문화되지 않으면 팀 자체가 대조 엔진이 되어 버립니다. 이는 매 보고 주기마다 지불해야 하는 세금과 같으며, 비즈니스 성장에 따라 완전히 잘못된 방향으로 늘어나게 됩니다.
Aly: 많은 기업이 확장되지 못하는 AI 파일럿 포트폴리오를 가지고 있습니다. Howden에서는 무엇이 달라졌나요?
Barry: 많은 조직과 마찬가지로 저희의 초기 단계도 탐색에 집중되어 있었기 때문에 고유한 유스케이스를 처음부터 새로 구축해야 했습니다. 가능성을 확인하기 위해 필요한 단계였지만, 진정으로 확장하기 위해서는 모든 부서에서 매번 새로 구축하는 방식에서 벗어나야 했습니다. 이제 Databricks 플랫폼을 활용하는 방식 덕분에 표준화된 파이프라인, 공유 코드, 재사용 가능한 데이터 자산을 보유하게 되었습니다. 부서별로 새로 구축하는 대신 한 번만 구축하면 고객 데이터, 리스크 데이터, 시장 데이터를 함께 혼합하여 교차 도메인 분석을 수행할 수 있습니다.
현재 저희는 그룹 전체에 걸쳐 AI 유스케이스 파이프라인을 운영하고 있습니다. 일관된 서비스로 소비될 수 있도록 모델을 프로덕션화하는 작업을 여전히 진행 중이며, 이는 솔직히 인정하는 공백이기도 합니다. 하지만 고립된 실험에서 확장 가능한 역량으로의 전환은 실재합니다. 통합된 뷰가 없었다면 이 중 어떤 것도 해낼 수 없었을 것입니다.
Aly: 리테일의 거래 속도만큼 빠르게 움직이지 않는 산업에서, 더 빠른 데이터가 실제로 결과를 바꾸는 부분은 어디인가요?
Barry: 매우 중요한 것은 제가 '인사이트 지연 시간(insight lag)'이라고 부르는 것, 즉 회사 어딘가에 데이터가 존재하는 시점과 누군가가 이를 실제로 사용할 수 있는 시점 사이의 격차를 줄이는 것입니다.
저희 비즈니스는 주로 중개 업무입니다. 즉, 브로커가 고객과 마주하기 전에 가장 최신의 인사이트를 제공하는 것을 의미합니다. 이전의 보고 방식은 느리고 배치(batch) 중심이었습니다. 데이터가 틀린 것은 아니었지만, 데이터를 볼 때쯤에는 이미 오래된 정보였습니다. 이는 신뢰의 문제를 일으키지는 않지만, 유용성의 문제를 일으킵니다. 백미러만 보면서 운전하는 꼴이 되는 것이죠.
이제 브로커가 고객을 만날 때 "이것이 현재 저희 장부 전반에서 확인되는 사항이며, 이것이 벤치마킹 결과이고, 이것이 저희의 공식 의견(house view)입니다"라고 말할 수 있습니다. 우리의 데이터가 곧 우리의 IP입니다. 저희처럼 전체 보험 가치 사슬 전반에 걸쳐 운영되는 회사는 많지 않습니다. 이러한 인사이트를 신속하게 제공하지 않는다면 어리석은 일일 것이며, 이전의 파편화된 상태에서는 이를 수행할 수 있는 방법이 전혀 없었을 것입니다.
Aly: Genie를 도입하게 된 계기는 무엇이며, 사람들이 해답을 얻는 방식은 어떻게 달라졌나요?
Barry: 제가 합류하기 전 면접 때 받았던 질문일 수도 있는데, 질문은 '왜 우리는 데이터와 그냥 대화할 수 없을까?'였습니다. 논리는 간단했습니다. 사람들은 ChatGPT를 통해 인터넷 전체와 대화하고 있습니다. 그렇다면 왜 자기 회사의 데이터에 질문하고 빠른 답변을 얻을 수는 없을까요?
여기에는 두 가지 측면이 있습니다. 하나는 말 그대로 속도입니다. 누군가 질문을 던지면 Genie가 몇 가지 숫자나 간단한 차트로 답변을 제공합니다. 다른 하나는 리소스 확보입니다. Genie가 없다면 누군가 특정 지표 기준 상위 10개 고객을 요청할 것입니다. 분석가가 이를 접수하고, 질문을 명확히 하고, 쿼리를 작성하고, 결국 필요 이상으로 복잡해지는 대시보드를 구축합니다. 이 주기는 느립니다. 제가 합류했을 때 신규 사업(greenfield)이었던 미국 리테일 비즈니스에서는 첫날부터 목표 아키텍처를 세웠습니다. 그들은 처음부터 Genie를 사용하고 있으며, 이를 통해 한 번 사용하고 잊혀졌을 수백 시간의 대시보드 구축 작업을 절약했을 것입니다.
제 동료는 'Howden Intelligence Layer'라고 부르는 개념을 가지고 있습니다. 이는 질문을 적절한 서비스로 분류해 주는 얇은 레이어입니다. 일부 질문은 리서치나 이메일을 위한 일반 모델을 거칩니다. 다른 질문은 답이 거버넌스가 적용된 데이터에 존재하기 때문에 Genie 질문이 됩니다. 사용자는 답이 어디서 오는지 신경 쓸 필요가 없어야 합니다.
Aly: 데이터 및 AI 노력을 확장하려는 C-level 리더에게 한 가지 조언을 해주 신다면 무엇인가요?
Barry: 빠르게 가려면 천천히 가세요(Go slow to go fast). 너무 느리지는 않되, 처음부터 제대로 설계해야 합니다. 플랫폼 파트너의 도움을 받아 아키텍처를 설계하세요. 많은 아키텍트들이 이전에 했던 방식의 고정관념을 그대로 가져오는 것을 너무 많이 보았기 때문입니다.
조직 내에서 프로세스 및 에이전트 기반 작업을 이끄는 담당자를 초기에 참여시키세요. 우리는 비즈니스 전반에 데이터를 전달하는 에이전트에게 데이터를 제공하게 될 것이며, 이를 위해서는 다른 설계 사고방식이 필요합니다. 그리고 단순한 데이터 제품이 아닌 데이터 서비스에 대해 생각하기 시작해야 합니다.
배리의 주장은 하우든(Howden)에 관한 것이 아닙니다. 이는 대부분의 기업이 곧 직면하게 될 설계 선택에 관한 것입니다. 대시보드 시대에 적합했던 제품 모델은 에이전트 중심의 시대에 적합한 모델이 아닙니다. 업스트림에서 분류 체계가 명확히 정의되지 않으면, 다운스트림에서 수행되는 조정 작업은 지속적인 부담이 됩니다. 대부분의 팀이 최적화하는 데이터 최신성(freshness) 지표는 비즈니스에 실제로 중요한 지표가 아닙니다. 진짜 중요한 것은 인사이트 지연(insight lag)입니다.
하우든의 인수 속도는 이러한 트레이드오프를 다른 곳보다 더 빠르게 가시화합니다. 하지만 이러한 트레이드오프는 하우든에만 국한된 것이 아닙니다. 에이전트에게 데이터를 제공하려는 모든 기업에 이러한 변화가 다가오고 있으며, 지금 이러한 소비 패턴에 맞게 설계하는 리더는 나중에 아키텍처를 재설계할 필요가 없을 것입니다.
오늘날의 속도가 아니라 앞으로 나아갈 속도에 맞춰 설계하세요.
25명 이상의 업계 전문가가 성공적인 AI 배포를 향한 경로를 어떻게 계획하고 있는지 알아보려면, Databricks의 지원으로 제작된 Economist Enterprise의 "Making AI Deliver" 보고서를 확인해 보세요.
(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)
블로그를 구독하고 최신 게시물을 이메일로 받아보세요.