AI 에이전트가 그럴듯하게 틀린 답을 내는 이유와 semantic layer 대응법

무슨 일이 일어나고 있나

Salesforce가 공개한 사례가 문제를 한 장면으로 압축해요. Q1 FY27 마감 후 분기 파이프라인 리뷰를 앞두고 마케팅팀이 사내 Slackbot에 "지난 분기 MQL(마케팅 검증 리드)을 몇 개 만들었나"를 두 번 물었는데, 같은 질문에 두 번 다른 답이 나왔어요. 같은 시스템(Salesforce 내부 Sales Cloud 인스턴스 Org62), 같은 질문인데도요. 게다가 두 답 모두 공식 대시보드(Leads Tableau Dashboard) 값과 일치하지 않았죠.

원인을 뜯어보면 세 겹이에요. 첫째, 두 쿼리 모두 Org62의 Lead 오브젝트는 찾았지만 인증된 MQL 정의를 쓰지 않았어요. MQL Campaign ID와 MQL Date는 공식 정의와 정렬되지 않은 '관련 필드'일 뿐, 올바른 필드가 아니었죠. 둘째, Org62는 실시간 데이터라 리드 상태가 시간에 따라 바뀌면 Q1 FY27 수치조차 소급해서 흔들려요. 셋째, 리드가 MQL 상태를 들락날락하기 때문에 Lead 오브젝트를 직접 쿼리하는 방식 자체가 기간 대 기간 비교에는 구조적으로 부적합했어요. 챗봇이 '못 하겠다'고 멈춘 게 아니라, 확신에 찬 두 개의 서로 다른 숫자를 뱉었다는 게 핵심이에요.

같은 시기 Databricks는 Microsoft와의 10년 파트너십을 2030년대까지 확대하면서 AI 어시스턴트 Genie를 Power BI, Copilot, Teams, Microsoft 365, 그리고 Entra·OneLake·Purview·Foundry까지 직접 통합한다고 발표했어요. 자연어로 물으면 사내 데이터로 답하는 그림이죠. Databricks는 전 세계 2만 개 이상 조직, 포춘 500 기업의 70%(AT&T·Bayer·BMW·HSBC·T-Mobile 등)가 쓰고 있고, 별도로 Genie One 출시와 함께 평가액 188억 달러를 확인했어요. 즉 위 MQL 사례의 오답 메커니즘이 이제 수천 개 조인트 고객(Unilever·Electrolux·Banco Bradesco 등)의 일상 업무 화면 안으로 배포되는 국면이에요.

왜 중요한가

AI 에이전트는 데이터를 단순히 꺼내오는 게 아니라 확률적 응답을 생성해요. 같은 질문이라도 어떤 데이터 소스를 찾았는지, 어떤 로직을 적용했는지, 사전 문맥이 무엇이었는지에 따라 다른 답이 나오죠. 엔터프라이즈 환경은 이 문제가 증폭돼요. 수년간 쌓인 데이터, 들쭉날쭉한 품질, 팀마다 다른 비즈니스 정의, 일관되지 않은 필드 로직이 에이전트에게 헛디딜 공간을 잔뜩 주고, 정작 에이전트는 자기가 틀렸다는 걸 알 방법(built-in way to know)이 없어요.

무서운 건 오답의 형태예요. 문맥이 없을 때 에러 메시지가 뜨는 게 아니라 자신만만한 오답(confident, wrong answer)이 나와요. 이게 왜 더 위험하냐면, SQL을 손으로 짜던 시절엔 쿼리 자체를 읽어 검증할 수 있었지만 챗봇이 뱉은 숫자는 어떤 필드를 어떤 로직으로 골랐는지 표면에 드러나지 않아요. 검증 비용이 겉보기엔 사라졌지만 실은 사후 대조로 이전됐을 뿐이죠. 여기에 Genie가 Power BI와 Copilot 화면 안으로 들어오면, 검증되지 않은 숫자가 대시보드의 권위를 빌려 의사결정 속도만큼 빠르게 확산돼요.

그래서 승패는 모델이 아니라 Unity Catalog에 쌓인 비즈니스 맥락과 메트릭 정의의 정합성에서 갈려요. Salesforce가 내놓은 해법 세 가지도 정확히 이 지점을 겨냥해요. (1) 인증된 데이터셋 기반의 AI Skill(구조화된 지시문), (2) Tableau MCP로 의미론적 모델 연결, (3) Chief Data Office가 검증한 단일 정보 원천. 실제로 Leads Tableau Dashboard가 신뢰받은 이유는 그것이 인증된 MQL 정의 위에서 계산되기 때문이었어요. 이걸 갖추면 같은 질문에 항상 같은 답이 나오고, 비즈니스 사용자도 SQL 없이 신뢰할 지표에 접근해요.

이해관계·역학

벤더 발표를 액면 그대로 받으면 안 돼요. Microsoft 발표에는 차세대 Arm 인프라 Cobalt 200이 Cobalt 100 대비 최대 50% 나은 성능에 메모리 암호화 기본 탑재를 내세웠는데, 이건 두 회사가 공동으로 발표한 수치예요. 실제 워크로드의 응답속도와 비용은 자기 데이터로 PoC를 돌려야 드러나요. 흥미로운 건 발표문 구조 자체예요. Databricks가 자사 핵심 업무를 Azure Databricks로 돌린다는 대목을 Microsoft CEO(Judson Althoff)가 직접 '고객에게 엔터프라이즈 규모에서 검증된 플랫폼이라는 확신을 준다'고 인용했어요. 자기 회사가 쓴다는 사실을 신뢰 마케팅의 증거로 전환하는 전형적 수사죠.

Databricks가 Genie One을 'SQL 없이 데이터에 접근'으로 파는 진짜 유인은 도입 장벽을 낮춰 SQL을 못 다루던 마케팅·재무·영업 사용자까지 저변을 넓히는 데 있어요. 사용자가 늘수록 Unity Catalog에 데이터와 정의가 쌓이고, 그럴수록 이탈 비용이 커지죠. Salesforce가 Vibe Coding의 함정을 굳이 자사 블로그로 공개한 유인도 대칭적이에요. AI Skill·Tableau MCP·인증 데이터셋이라는 자사 거버넌스 제품군의 '필요'를 만들어내는 서사거든요. 문제를 제기한 쪽과 해법을 파는 쪽이 같다는 걸 늘 기억해야 해요.

IBM의 움직임은 다른 각도에서 이 흐름을 확인해줘요. 최고인사책임자(Nickle LaMoreaux)가 올해 미국 신입 채용을 3배로 늘리라고 전 사업부에 지시했어요. AI로 감원한다는 업계 통념과 정반대죠. 겨냥한 자리가 '최근 감원 헤드라인이 사라진다고 선언한 바로 그 역할'이라는 점이 시사적이에요. 반복 업무가 줄어든 공백을 판단·검증·프롬프트 설계가 되는 인력으로 채우겠다는 계산이거든요. Genie One이 SQL 없이 데이터에 접근하게 해줘도, 위 MQL 사례처럼 두 개의 다른 답 중 어느 것도 공식 값과 맞지 않을 때 그걸 알아채는 건 결국 사람이니까요.

실무에 주는 함의

도구를 붙이기 전에 아래부터 점검하세요.

• 핵심 지표 정의를 문서화하고 합의하기. MQL·전환·활성 사용자 같은 지표가 조직 안에서 하나의 정의로 굳어 있는지 확인해요. dbt metrics나 인증된 데이터셋처럼 지루하지만 선행돼야 하는 작업이에요. 특히 Salesforce의 Org62처럼 실시간으로 소급 변경되는 필드는 기간 대 기간 비교 지표의 근거로 쓰지 마세요. 상태가 들락날락하는 오브젝트를 직접 세는 순간 숫자는 매번 달라져요.
• 단일 정보 원천을 못 박기. Salesforce가 Leads Tableau Dashboard를 authoritative source로 삼은 것처럼, 챗봇이 뭐라 답하든 대조할 기준 대시보드를 정해두세요. AI 답과 공식 값이 어긋나면 그건 AI 성능이 아니라 정의 부재의 신호로 읽어야 해요.
• Genie·Copilot 통합 전에 semantic layer와 접근권한부터 설계하기. 통합 순서를 뒤집으면 그럴듯한 오답이 대시보드의 권위를 빌려 퍼져요. Cobalt 200의 50% 향상 같은 공동 발표 수치는 자기 워크로드로 PoC를 돌려 응답속도·비용을 직접 확인하고요.
• 검증 담당을 명시하기. 도입 검토의 초점을 '몇 명을 줄이나'가 아니라 '누가 AI 출력을 검증하고 맥락을 붙이나'에 두세요. IBM이 신입 채용을 3배로 늘려 확보하려는 게 바로 이 역할이에요.

이메일 캠페인 조언에서 나온 원칙도 같은 맥락이에요. 연례 컨퍼런스 메일에 CTA 5개(초록 제출·아젠다 보기·등록·호텔 예약·동료 추천)를 다 얹으면 무엇으로 성공을 판단할지 방이 조용해지듯, AI가 '답을 냈다'는 산출물과 그 답이 등록 완료·매출 같은 하류 지표에서 신뢰할 만하다는 성과는 전혀 다른 얘기예요.

리스크·반대 관점

반대 시나리오도 짚어야 공정해요. semantic layer 정비가 만병통치는 아니에요. 정의를 합의하는 데 걸리는 시간과 정치적 비용이 커서, 완벽한 거버넌스를 기다리다 도구 도입 자체가 몇 분기씩 지연되는 함정도 흔해요. 인증 데이터셋은 유지보수가 지속 비용이라, 조직이 커지면 정의가 다시 갈라지고요. 즉 'MQL을 한 번 정의하면 끝'이 아니라, 정의를 계속 강제하고 감사하는 운영 체계가 없으면 반년 뒤 같은 두 개의 답 문제가 재발해요.

벤더 종속도 놓치기 쉬운 함정이에요. Genie를 Unity Catalog에, MQL 정의를 특정 벤더 semantic layer에 묶으면 이전 비용이 커져요. Nvidia·Microsoft·Meta가 오픈 웨이트 모델 규제 강화에 반대하며 경고한 논리가 여기에도 그대로 적용돼요. 그들의 주장에 따르면 규제로 개방형 생태계가 축소되면 사용자가 특정 회사에 종속되고 가격 인상으로 이어져요. 원자료 표현대로 '의존 관계가 굳어지는 순간 터무니없는 수준까지 수익을 뽑아낼' 수 있다는 거죠. 다만 이 세 회사의 옹호도 명분이 아니라 손익 계산임을 함께 봐야 해요. Nvidia는 모델이 많을수록 GPU가 팔리고, Microsoft·Meta는 폐쇄 모델에서 뒤처진 후발주자라 오픈 진영을 키우는 게 유리하거든요. 실무자 입장에선 이 이해관계 지형을 읽고, 계약 단계에서 데이터 이전 가능성과 표준 API 준수를 못 박고, Llama·DeepSeek 같은 오픈 웨이트를 미리 검증해두는 게 진짜 리스크 헤지예요.

마지막으로, 자연어 인터페이스가 오히려 검증을 어렵게 만든다는 역설. 챗봇 답만 보면 어떤 데이터 소스를 찾아 어떤 로직을 탔는지 보이지 않아요. 도구가 편해질수록 실무자의 SQL·데이터 독해 역량을 유지하는 게 결국 비용을 가른다는 숙제가 남아요.

자주 묻는 질문

agentic ai란 무엇인가요

목표를 주면 실행 방법을 스스로 조정하는 AI예요. 데이터 분석 맥락에선 자연어 질문을 받아 어떤 데이터 소스를 쓸지, 어떤 로직을 적용할지 스스로 판단해 답을 생성해요. 문제는 이 판단이 확률적 응답이라, 문맥이 없으면 같은 질문에 다른 답이 나오고 에러 대신 그럴듯한 오답을 낸다는 점이에요.

AI 마케팅 실패 사례로 뭘 조심해야 하나요

대표적인 게 Salesforce의 MQL 사례예요. 인증된 정의 없이 Org62 Lead 오브젝트를 쿼리한 챗봇이 같은 질문에 두 번 다른 답을 냈고, 둘 다 공식 Leads Tableau Dashboard 값과 달랐어요. 지표 정의를 조직이 합의하지 않은 채, 그것도 실시간으로 소급 변경되는 데이터 위에서 AI 분석 도구를 붙이면 틀린 의사결정만 빨라져요.

agentic ai와 ai agent 차이가 뭔가요

AI agent는 특정 작업을 대신 실행하는 개별 주체에 가깝고, agentic AI는 목표를 주면 여러 단계를 스스로 계획하고 조정하는 자율성에 방점이 있어요. 데이터 분석에선 둘 다 semantic layer 같은 문맥 기반이 없으면 신뢰할 수 없는 답을 내는 한계가 똑같이 적용돼요.

마케팅 AI 툴을 도입하기 전에 뭘 준비해야 하나요

핵심 지표 정의 합의, 단일 정보 원천 지정, semantic layer와 접근권한 설계가 먼저예요. Genie나 Copilot 통합은 그다음이에요. 순서를 뒤집으면 그럴듯한 오답이 대시보드의 권위를 빌려 퍼져요. Cobalt 200의 50% 향상 같은 벤더 공동 발표 수치는 자기 데이터로 PoC를 돌려 검증하세요.

AI가 데이터 분석을 대신하면 사람은 필요 없어지나요

반대예요. IBM은 올해 미국 신입 채용을 3배로 늘렸어요. 반복 업무가 줄어든 자리를 AI 출력을 검증하고 맥락을 붙일 인력으로 채우려는 거죠. 두 개의 다른 답 중 어느 것도 공식 값과 맞지 않을 때 그걸 알아채는 건 결국 사람이라, 자연어 도구가 편해질수록 검증 역할이 더 중요해져요.