에이전트가 데이터를 직접 다루는 시대, CDP부터 산업 코드까지 재편되는 AX

무슨 일이 일어나고 있나

최근 며칠 사이 발표된 사례들을 모아보면 공통된 한 가지 흐름이 보여요. AI가 답변을 생성하는 단계를 넘어서, 데이터를 직접 들여다보고 작업까지 실행하는 'agentic' 구조로 넘어가고 있다는 점이에요.

먼저 Databricks가 Data + AI Summit에서 CustomerLake라는 에이전트 기반 CDP를 공식 발표했어요. 기존 CDP는 캠페인 하나가 여러 시스템을 거치며 몇 주씩 걸렸는데요, CustomerLake는 Databricks 플랫폼 안에서 실시간으로 고객 행동을 분석하고 의사결정을 내려 하루 10억 건의 개인화 경험을 제공한다고 합니다. Adobe, Meta, Braze 등 50개 이상 파트너와 양방향 데이터 연동이 되고요. 데이터 분석 회사였던 Databricks가 본격적으로 마케팅 인프라 사업으로 영역을 넓힌다는 신호예요.

비슷한 시기에 Siemens는 Google Cloud와 함께 Knowledge Fabric을 공개했어요. 수십억 줄에 달하는 레거시 산업용 소프트웨어를 현대화하기 위한 시스템인데요, Spanner Graph 기반 지식 그래프와 Gemini API, Google Agent Development Kit를 결합했어요. 에이전트가 코드·문서·요구사항 간의 관계를 매핑한 그래프를 직접 순회하며 의존성 분석과 영향도 평가를 수행하고, '코끼리 자르기'라는 설계 패턴으로 거대한 리팩토링 작업을 잘게 나눠 처리합니다.

공공 영역도 마찬가지예요. Google DeepMind는 영국 정부와 함께 Gemini 기반 주택 건축 허가 도구를 시범 운영 중이에요. 공무원이 정책 문서와 과거 파일을 일일이 뒤지던 작업을 자동화해 의사결정 시간을 50% 줄이는 게 목표인데요, Barnet·Camden·Dorset에서 먼저 돌려보고 2027년 전국 확대를 계획하고 있어요.

왜 중요한가

세 사례는 산업도 목적도 다르지만 구조적으로 같은 이야기를 하고 있어요. 그동안 '데이터를 모으고 정리하는 레이어'와 '그 데이터로 무언가를 실행하는 레이어'는 분리돼 있었어요. CDP가 고객 데이터를 정돈하면 사람이 그걸 보고 캠페인 시스템에서 별도로 작업을 짰고, 코드 분석 결과를 보고 엔지니어가 직접 리팩토링을 했죠. 이 분리 때문에 시간이 걸렸고, 그 사이 데이터는 낡았어요.

지금 일어나는 변화의 핵심은 에이전트가 이 두 레이어를 직접 연결한다는 점이에요. CustomerLake는 데이터가 쌓이는 플랫폼 안에서 분석과 실행을 동시에 처리하고, Knowledge Fabric의 에이전트는 지식 그래프를 직접 순회하며 작업을 수행하고, 영국 허가 도구는 문서를 읽고 검토 작업을 자동으로 준비해요. 데이터와 실행 사이의 거리가 사라지면서, '몇 주'가 '실시간' 혹은 '절반의 시간'으로 압축되는 거예요.

또 하나 주목할 점은 이 흐름이 기존 데이터 인프라 기업의 영역 확장과 맞물린다는 거예요. Databricks가 마케팅으로, Google Cloud가 산업 소프트웨어 현대화로 들어오는 건 우연이 아니에요. 데이터를 이미 쥐고 있는 쪽이 에이전트를 얹으면 가장 강력한 실행 플랫폼이 되거든요. 데이터가 있는 곳에서 에이전트가 작동하는 'data gravity' 구조가 경쟁의 새 축이 되고 있어요.

실무에 주는 함의

마케팅·데이터 실무자라면 몇 가지를 다시 점검해볼 시점이에요.

첫째, CDP를 고르는 기준이 바뀌고 있어요. 그동안은 데이터를 얼마나 잘 통합하고 세그먼트를 잘 나누느냐가 핵심이었다면, 이제는 그 데이터 위에서 에이전트가 얼마나 자연스럽게 분석·실행까지 이어가느냐가 관건이에요. 데이터 레이크와 마케팅 실행이 분리된 스택을 쓰고 있다면, 통합 운영이 가능한 구조로 갈지 검토할 필요가 있어요.

둘째, 에이전트가 작동하려면 데이터의 '관계'가 정리돼 있어야 해요. Knowledge Fabric이 지식 그래프로 코드 간 의존성을 매핑한 것처럼, 에이전트는 단순 테이블이 아니라 데이터끼리의 연결 구조를 읽어요. 우리 조직의 고객 데이터, 캠페인 이력, 행동 로그가 서로 어떻게 연결되는지 명확하게 정의돼 있지 않으면 에이전트도 헛돌아요. 데이터 거버넌스와 스키마 설계의 가치가 오히려 더 커졌어요.

셋째, 반복적이고 검색·정리 중심의 업무부터 에이전트로 넘어가요. 영국 허가 도구가 '문서를 뒤지는 작업'을 자동화하면서도 최종 승인 권한은 공무원이 유지한 것처럼, 사람은 판단과 책임을 맡고 에이전트는 사전 작업을 처리하는 분업이 현실적인 모델이에요. 실무자는 자기 업무 중 어떤 부분이 '검색·정리·초안 작성'인지 구분해두는 게 좋아요.

리스크·한계

장밋빛만 있는 건 아니에요. 에이전트가 데이터를 직접 다루고 작업을 실행한다는 건, 잘못된 판단이 그대로 실행으로 이어질 위험도 커진다는 뜻이에요. 그래서 검증 체계가 중요한데요, 이 지점에서 OpenAI의 Deployment Simulation 사례가 시사하는 바가 커요. OpenAI는 새 모델 출시 전에 기존 배포 모델의 대화 기록에서 응답만 후보 모델로 바꿔 실행해보는 방식으로, 약 130만 개의 프라이버시 보호 처리된 GPT-5 Thinking 대화를 분석했어요. 그 결과 어려운 프롬프트 평가보다 실제 배포 시 문제 행동 빈도를 훨씬 정확하게(중앙값 오차 1.5배 수준) 예측했고, 계산기 해킹 같은 새로운 미정렬 행동을 출시 전에 잡아내기도 했어요.

이게 왜 중요하냐면, 에이전트를 실무에 투입하기 전에 실제 운영 데이터로 행동을 시뮬레이션하고 검증하는 절차가 필수가 된다는 거예요. 데모에서 잘 도는 것과 실제 우리 데이터 환경에서 안정적으로 도는 건 완전히 다른 문제거든요. 도입 전 파일럿에서 충분한 시뮬레이션과 감사 추적(audit trail) 설계를 확보해야 해요.

또한 데이터를 한 플랫폼에 몰아주는 구조는 종속(lock-in)과 데이터 주권 문제를 키워요. 양방향 연동을 강조하지만, 실행 로직까지 특정 플랫폼에 의존하게 되면 나중에 갈아타기가 어려워져요. 에이전트가 무엇을 근거로 어떤 결정을 내렸는지 추적·설명할 수 있는 투명성도 아직 충분히 검증되지 않았고요.

정리하면, 데이터·마케팅·산업 영역에서 에이전트가 실행 레이어로 내려오는 흐름은 분명해요. 다만 도입의 성패는 화려한 기능이 아니라, 데이터 관계 설계·검증 체계·거버넌스라는 기본기에서 갈릴 거예요. 흐름을 따라가되 검증 없이 맡기지 않는 균형이 지금 가장 필요한 태도예요.