Enterprise Agents Have a Structure Problem - Ishita Daga, Tesla
📺 원본 영상: Enterprise Agents Have a Structure Problem - Ishita Daga, Tesla
🎙️ 채널: AI Engineer
📅 정리 일자: 2026-07-20
⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료(차트, 코드, 슬라이드 등)는 포함되지 않을 수 있습니다.
개요
Tesla에서 Machine Learning Engineer로 일하며 조직 내부의 엔터프라이즈 에이전트를 구축하고 있는 Ishita Daga는, 기업용 데이터 에이전트가 실패하는 이유를 단순히 모델 성능 부족으로 설명해서는 안 된다고 말한다. 더 큰 모델, 더 긴 컨텍스트, 더 많은 문서와 MCP 서버를 붙이는 방식은 겉보기에는 자연스러운 해법처럼 보이지만, 실제 실패의 핵심은 에이전트가 조직 지식의 구조를 이해하지 못한다는 데 있다.
강연의 중심 주제는 엔터프라이즈 에이전트의 문제를 모호성(Ambiguity), 최신성(Staleness), 선호도(Preference)라는 세 가지 축으로 나누어 보는 것이다. 이 세 문제는 서로 분리된 버그라기보다, 기업 데이터 환경이 본질적으로 복잡하고 계속 변하며 팀마다 의미 체계가 다르다는 사실에서 비롯된다. 따라서 강연자는 에이전트를 개선하려면 모델을 교체하는 것보다 먼저 데이터 소스의 위계, 컨텍스트 갱신 주기, 평가 루프, 팀별 메트릭 사용 방식의 구조화를 고민해야 한다고 주장한다.
더 큰 모델이 아니라 더 나은 구조가 필요하다
기업용 에이전트가 잘못된 답을 내놓을 때 가장 흔한 반응은 더 큰 모델을 써야 한다는 것이다. 최신 모델을 도입하고, 더 긴 컨텍스트 윈도우를 확보하고, 더 많은 Markdown 문서, 내부 문서, MCP 서버, 플러그인을 붙이면 문제를 해결할 수 있을 것처럼 보인다. 그러나 Ishita Daga는 이런 접근이 “명백한 해결책”처럼 보일 수는 있어도, 데이터 에이전트 자체의 정확도를 근본적으로 높이는 답은 아니라고 설명한다.
그 이유는 에이전트가 단순히 정보가 부족해서 틀리는 것이 아니라, 정보 사이의 우선순위와 신뢰도를 판단하지 못해서 틀리는 경우가 많기 때문이다. 기업 내부에는 같은 개념을 설명하는 여러 문서, 여러 테이블, 여러 쿼리, 여러 팀의 관행이 동시에 존재한다. 이때 에이전트가 모든 지식 베이스를 동일한 가중치로 취급하면, 최신이 아닌 정의를 사용하거나, 특정 팀에만 맞는 필터를 전체 조직의 기준처럼 적용하거나, 가장 신뢰할 수 있는 데이터 소스를 놓칠 수 있다.
따라서 이 강연에서 말하는 “구조 문제”는 에이전트 아키텍처의 추상적인 설계 문제가 아니라, 기업 지식이 어떤 순서로 참조되어야 하는지 정의되지 않은 현실적인 문제에 가깝다. 에이전트가 어떤 테이블을 써야 하는지, 어떤 컬럼이 맞는지, 어떤 지식 베이스가 Source of Truth인지, 어떤 문서는 유연하지만 덜 정제된 정보인지 알지 못한다면, 모델이 아무리 좋아져도 답변 품질은 불안정할 수밖에 없다.
첫 번째 문제 - 모호성은 Source of Truth의 부재에서 시작된다
강연자가 첫 번째로 지적한 문제는 모호성(Ambiguity)이다. 데이터 에이전트는 사용자의 질문을 받았을 때 어떤 테이블이 맞고, 어떤 컬럼을 참조해야 하며, 어떤 데이터 소스가 가장 신뢰할 만한지 판단해야 한다. 하지만 실제 기업 환경에서는 여러 지식 베이스가 동시에 존재하고, 각각의 지식 베이스가 서로 다른 목적과 신뢰도를 갖고 있음에도 그 차이가 에이전트에게 명시적으로 전달되지 않는 경우가 많다.
Ishita Daga는 Source of Truth를 하나의 평면적인 목록이 아니라 위계(Hierarchy)로 보아야 한다고 말한다. 이 위계는 가장 깨끗하고 덜 유연한 정보에서 시작해, 점점 더 지저분하지만 더 유연하고 동적인 정보로 내려가는 구조를 가진다. 즉, 에이전트는 질문을 받았을 때 처음부터 모든 문서와 데이터베이스를 뒤지는 것이 아니라, 가장 정제된 의미 계층에서 출발해 필요할 때 더 유연한 데이터 구조로 이동해야 한다.
이 관점은 기업용 데이터 에이전트를 설계할 때 매우 중요하다. 많은 팀이 RAG(Retrieval-Augmented Generation)나 툴 호출을 붙이면 에이전트가 “알아서” 올바른 정보를 찾을 것이라고 기대하지만, 기업 데이터는 검색 엔진처럼 작동하지 않는다. 같은 KPI라도 팀마다 정의가 다를 수 있고, 같은 테이블이라도 운영 목적과 분석 목적이 다를 수 있으며, 어떤 데이터는 공식 보고용이고 어떤 데이터는 탐색용일 수 있다. 이 차이를 구조화하지 않으면 에이전트는 결국 그럴듯하지만 틀린 답을 만들 가능성이 높아진다.
Semantic Layer - 가장 깨끗한 출발점
강연자는 Source of Truth의 첫 번째 계층으로 Semantic Layer(시맨틱 레이어)를 제시한다. Semantic Layer는 KPI 정의, 메트릭 계산 방식, 비즈니스 정의, 주요 쿼리 등을 큐레이션한 계층이다. 에이전트는 사용자의 질문을 받으면 먼저 이 계층에서 가장 가까운 KPI나 비즈니스 정의를 찾고, 그 정의에 연결된 데이터 포인트를 참조해 답변을 구성한다.
03:31 - Semantic Layer를 Source of Truth의 첫 번째 계층으로 설명하며 KPI 정의, 메트릭 계산 방식, 비즈니스 정의를 다루는 구간
Semantic Layer가 중요한 이유는 에이전트에게 “무엇이 공식적인 의미인가”를 알려주기 때문이다. 예를 들어 매출, 전환율, 평균 처리 시간, 완료율 같은 메트릭은 표면적으로는 단순해 보이지만, 실제 조직에서는 계산식과 제외 조건, 기간 기준, 필터 조건에 따라 전혀 다른 숫자가 된다. 이때 Semantic Layer는 에이전트가 매번 원천 테이블 구조를 추론하지 않아도 되도록, 조직이 합의한 의미 체계를 먼저 제공한다.
이 방식은 유연성은 낮지만 정확성과 관리 가능성이 높다는 장점이 있다. 모든 질문을 Semantic Layer만으로 처리할 수는 없지만, 반복적으로 묻는 핵심 KPI와 비즈니스 정의를 이 계층에 정리해두면 에이전트의 답변 안정성이 크게 높아진다. 강연자의 관점에서 이는 기업용 데이터 에이전트가 가장 먼저 구축해야 할 기반에 해당한다.
Canonical Tables - 유연성을 조금 더 허용하는 두 번째 계층
두 번째 계층은 Canonical Tables(정준 테이블) 또는 파라메트릭 쿼리 계층이다. 이 계층에서는 에이전트에게 특정 질문에 사용할 수 있는 대표 테이블이나 파라미터화된 쿼리 목록을 제공한다. Semantic Layer가 이미 합의된 KPI와 정의를 중심으로 한다면, Canonical Tables는 에이전트가 더 넓은 범위의 질문에 답할 수 있도록 제한된 유연성을 제공한다.
04:22 - Canonical Tables와 파라메트릭 쿼리를 통해 에이전트가 더 넓은 질문에 답하는 방식을 설명하는 구간
이 접근은 에이전트가 직접 쿼리를 구성하거나 필터를 선택할 여지를 준다. 다만 완전히 자유롭게 데이터베이스 전체를 탐색하게 하는 것이 아니라, 조직이 신뢰할 만하다고 판단한 테이블과 쿼리 패턴 안에서 선택하도록 만드는 것이 핵심이다. 이렇게 하면 에이전트는 Semantic Layer만으로 답하기 어려운 질문에도 대응할 수 있으면서, 동시에 잘못된 테이블을 무작위로 선택할 위험을 줄일 수 있다.
기업 환경에서 이 계층은 실용적인 절충안이 된다. 모든 메트릭을 완벽한 Semantic Layer로 관리하는 것은 시간이 오래 걸리고, 반대로 데이터베이스 전체를 에이전트에게 맡기는 것은 위험하다. Canonical Tables는 이 둘 사이에서, 데이터팀이 자주 쓰는 분석 경로와 안전한 쿼리 패턴을 에이전트에게 전달하는 역할을 한다.
Database Graph - 강력하지만 유지보수가 어려운 마지막 계층
세 번째 계층은 Database Graph(데이터베이스 그래프)다. 강연자는 이 계층이 가장 까다롭지만, 답변 가능한 질문의 범위를 크게 넓혀준다고 설명한다. 이 방식에서는 각 테이블을 컬럼과 연결하고, 테이블을 해당 테이블로 답할 수 있는 메트릭과 연결하며, 반대로 메트릭에서 관련 테이블로 이동할 수 있도록 거대한 그래프 구조를 만든다.
05:01 - Database Graph에서 테이블, 컬럼, 메트릭을 연결하는 구조를 설명하는 구간
Database Graph는 에이전트가 데이터베이스의 구조적 관계를 더 잘 탐색하도록 도와준다. 단순히 테이블 목록을 제공하는 것보다, 어떤 테이블이 어떤 컬럼을 갖고 있고 어떤 메트릭과 연결되는지 명시적으로 알려주기 때문에 복잡한 질문에 대응할 수 있는 여지가 커진다. 그러나 그만큼 구축과 유지보수 비용이 크다. 테이블이 바뀌고 컬럼이 추가되며 메트릭 정의가 변경될 때마다 그래프도 함께 갱신되어야 하기 때문이다.
그래서 강연자는 기업이 Source of Truth 계층을 추가할 때 Semantic Layer와 Canonical Tables를 먼저 구축하는 편이 낫다고 본다. 이 두 계층만으로도 상당수의 문제를 해결할 수 있고, 나머지 더 복잡한 롱테일 질문에 대해서 Database Graph가 보완적으로 쓰일 수 있다는 판단이다. STT상 “80%의 문제와 20%는 Database Graph로 해결”처럼 들리는 발언은, 문맥상 Semantic Layer와 Canonical Tables로 약 80%의 질문을 처리하고 나머지 20%의 복잡한 질문에 Database Graph를 활용한다는 일반적인 80/20 접근을 말한 것으로 이해할 수 있다.
두 번째 문제 - 최신성은 컨텍스트 생명주기의 문제다
강연자가 두 번째로 제시한 문제는 최신성(Staleness)이다. STT에는 “tail-less”처럼 들리는 부분이 있으나, 문맥상 “staleness”로 교정하는 것이 타당하다. 기업의 컨텍스트는 빠르게 낡는다. 의사결정이 바뀌고, KPI 정의가 바뀌고, 프로세스가 업데이트되며, 문서와 스킬에 적어둔 정보는 어느 순간 현재 조직의 실제 운영 방식과 어긋나기 시작한다.
이 문제는 단순히 문서를 더 자주 업데이트하자는 수준으로는 해결하기 어렵다. Markdown 파일이나 에이전트 스킬에 최신 정보를 계속 수동 반영하는 방식은 조직 규모가 커질수록 유지하기 힘들어진다. 데이터 에이전트가 정확하려면 컨텍스트를 일회성으로 주입하는 것이 아니라, 생성되고 검증되고 갱신되는 생명주기(Context Lifecycle)로 관리해야 한다.
Ishita Daga가 제안하는 컨텍스트 생명주기는 크게 두 요소로 구성된다. 첫째는 항상 최신 상태를 유지하는 라이브 데이터 소스나 지식 소스를 에이전트에 연결하는 것이다. 둘째는 사용자의 피드백과 오류 이벤트를 기록하고, 이를 평가와 업데이트로 이어지게 하는 피드백 루프를 만드는 것이다. 이 두 가지가 결합되어야 에이전트는 한 번 만들어진 지식에 갇히지 않고 조직 변화에 맞춰 움직일 수 있다.
Live Knowledge Source - 죽은 문서 대신 살아 있는 시스템을 연결한다
강연자는 최신성 문제를 줄이기 위해 GitHub, CRM 도구, Tableau, dbt Semantic Layer 같은 라이브 데이터 소스를 연결하는 방식을 제안한다. 여기서 “라이브”란 단순히 API로 접근 가능하다는 뜻이 아니라, 조직 안에서 지속적으로 갱신되고 검토되며 큐레이션되는 데이터 소스를 의미한다. 에이전트가 참조하는 정보가 낡은 문서가 아니라 실제 업무 흐름 속에서 유지되는 시스템이라면, 답변의 최신성을 확보하기가 훨씬 쉬워진다.
06:40 - GitHub, CRM, Tableau, dbt Semantic Layer 같은 라이브 지식 소스를 컨텍스트 생명주기에 포함하는 방식을 설명하는 구간
예를 들어 개발 조직에서는 GitHub가 실제 코드와 변경 이력을 반영하는 살아 있는 지식 소스가 될 수 있다. 영업 조직에서는 CRM이 고객 상태와 영업 파이프라인의 최신 정보를 담고 있을 수 있으며, 분석 조직에서는 Tableau나 dbt Semantic Layer가 공식 지표와 모델 정의를 제공할 수 있다. 중요한 것은 어떤 도구를 쓰느냐가 아니라, 그 도구가 조직에서 가장 자주 업데이트되고 검토되는 필수 데이터 소스인지 여부다.
이 접근은 에이전트 컨텍스트 관리의 책임을 문서 작성자 개인에게만 맡기지 않는다는 점에서도 의미가 있다. 지식이 이미 업무 시스템 안에서 갱신되고 있다면, 에이전트는 그 시스템을 참조함으로써 최신 정보를 따라갈 수 있다. 반대로 오래된 문서를 계속 컨텍스트로 주입하는 방식은, 겉으로는 많은 정보를 제공하는 것처럼 보여도 실제로는 에이전트의 오류 가능성을 높일 수 있다.
Feedback Loop - 로그, 평가, 업데이트가 연결되어야 한다
최신성 문제를 해결하는 두 번째 축은 피드백 루프다. 강연자는 많은 엔터프라이즈 데이터 에이전트가 이 부분을 놓친다고 지적한다. 사용자가 “이 데이터베이스는 틀렸다”, “이 정의는 업데이트되었다”, “이 메트릭은 새로운 방식으로 계산해야 한다”, “이 필터를 추가해야 한다”고 말하는 순간은 모두 중요한 이벤트지만, 이런 이벤트가 기록되지 않으면 에이전트는 같은 실수를 반복한다.
따라서 모든 오류와 수정 신호는 로그로 남아야 한다. 그러나 로그를 남기는 것만으로는 충분하지 않다. 기록된 이벤트는 평가(Evaluation)와 컨텍스트 업데이트로 이어져야 한다. 강연자는 사람이 주석을 단 질문으로 평가 세트를 만들거나, 최근 며칠 동안 실제로 들어온 질문과 답변을 바탕으로 자동 평가를 구성하는 방법을 언급한다. 핵심은 에이전트가 시간이 지남에 따라 나아지고 있는지, 혹은 특정 영역에서 계속 실패하고 있는지를 추적하는 것이다.
07:42 - 휴먼 평가와 자동 평가를 포함한 에이전트 평가 루프를 설명하는 구간
이 지점은 엔터프라이즈 AI 시스템에서 특히 중요하다. 많은 팀은 데모 단계에서 에이전트가 몇 가지 질문에 잘 답하면 충분하다고 생각하지만, 실제 운영 환경에서는 질문 유형이 계속 바뀌고 데이터 정의도 계속 변한다. 평가 루프가 없다면 에이전트의 성능 저하는 조용히 누적되고, 사용자는 점점 시스템을 신뢰하지 않게 된다. 강연자의 메시지는 명확하다. 컨텍스트는 넣고 끝나는 것이 아니라, 로그를 통해 관찰하고 평가를 통해 측정하며 업데이트를 통해 다시 정렬해야 한다.
세 번째 문제 - 선호도는 아직 풀리지 않은 문제다
세 번째 문제는 선호도(Preference)다. 강연자는 이 문제가 앞의 두 문제보다 더 주관적이며, 아직 업계에 명확한 해답이 없다고 본다. 같은 메트릭이라도 팀마다 계산 방식이 다르고, 같은 쿼리를 사용하더라도 필터 조건이 다를 수 있다. 따라서 에이전트가 정확한 답을 하려면 단순히 공식 정의를 아는 것만으로는 부족하고, 질문한 사람이 속한 팀이나 개인이 어떤 정의를 선호하는지도 이해해야 한다.
강연자가 든 예시는 평균 마일스톤 시간 계산이다. Team A는 이전 마일스톤의 완료 시점부터 현재 마일스톤의 완료 시점까지를 기준으로 평균 시간을 계산할 수 있다. 반면 Team B는 현재 마일스톤의 시작 시점부터 다음 마일스톤의 시작 시점까지를 기준으로 계산할 수 있다. 두 방식 모두 특정 업무 맥락에서는 올바를 수 있지만, 결과는 서로 다르게 나온다.
09:28 - Team A와 Team B가 평균 마일스톤 시간을 서로 다른 방식으로 계산하는 선호도 문제 예시를 설명하는 구간
이 사례가 보여주는 문제는 “정답”이 하나가 아닐 수 있다는 점이다. 에이전트가 평균 마일스톤 시간을 묻는 질문에 답할 때, 어떤 팀이 질문했는지 모른다면 두 계산 방식 중 하나를 임의로 선택해야 한다. 그 선택이 논리적으로 틀린 것은 아니더라도, 질문자의 기대와 다르면 실무적으로는 틀린 답이 된다. 이것이 선호도 문제가 어려운 이유다.
Semantic Layer와 Agent Memory만으로는 충분하지 않다
강연자는 선호도 문제를 해결할 수 있는 후보로 두 가지 접근을 언급한다. 첫 번째는 여러 계산 방식을 Semantic Layer에 저장해두고, 사용자가 프롬프트에서 어떤 방식을 사용할지 명시하도록 하는 것이다. 이 방법은 적어도 여러 정의를 체계적으로 보관할 수 있다는 장점이 있지만, 사용자의 선호도를 자동으로 저장하거나 적용하지는 못한다. 결국 사용자가 매번 어떤 계산 방식을 원하는지 알려주어야 하므로, 모호성 문제로 다시 돌아가게 된다.
두 번째 접근은 Agent Memory(에이전트 메모리)를 사용하는 것이다. 강연자는 Mem0나 memory.md 파일 같은 방식을 예로 든다. 이런 방식은 사용자의 선호를 저장할 수는 있지만, 두 메트릭 사이의 의미 차이를 깊이 이해하고 상황에 따라 어떤 것을 써야 하는지 판단하는 데에는 한계가 있다. 즉, 메모리는 선호의 흔적을 보관할 수 있지만, 선호의 적용 조건을 안정적으로 모델링하는 구조는 아직 충분하지 않다는 뜻이다.
10:40 - Agent Memory와 memory.md 방식이 선호도 저장에는 도움이 되지만 메트릭 구분에는 한계가 있음을 설명하는 구간
강연자가 궁극적으로 원하는 것은 사용자의 팀이나 개인 정체성에 따라 에이전트를 올바른 메트릭으로 라우팅하는 방식이다. 이는 단순한 개인화 기능보다 훨씬 어렵다. 개인이나 팀의 선호는 고정된 설정값이 아니라 업무 맥락, 질문 목적, 보고 대상, 시간에 따라 달라질 수 있기 때문이다. 그래서 강연자는 이 문제를 아직 열린 연구 과제로 보고, 업계와 frontier labs가 더 깊이 연구해야 할 주제라고 말한다.
엔터프라이즈 에이전트 설계에 주는 실무적 함의
이 강연의 실무적 가치는 에이전트를 “모델 중심 제품”이 아니라 “조직 지식 시스템”으로 바라보게 만든다는 데 있다. 모델은 질문을 이해하고 답변을 생성하는 핵심 엔진이지만, 기업 환경에서 답변의 품질은 어떤 정보를 어떤 우선순위로 참조하는지에 크게 좌우된다. 따라서 엔터프라이즈 에이전트를 만들 때는 모델 선택만큼이나 Source of Truth 설계, Semantic Layer 관리, 평가 루프, 피드백 기록 체계가 중요하다.
특히 데이터 에이전트의 경우, 잘못된 답변은 단순한 UX 문제가 아니라 의사결정 리스크로 이어질 수 있다. 에이전트가 낡은 KPI 정의를 사용하거나, 다른 팀의 필터 조건을 적용하거나, 공식 테이블 대신 임시 테이블을 참조하면 사용자는 잘못된 수치를 기반으로 판단할 수 있다. 이런 위험은 더 큰 모델을 쓴다고 자동으로 사라지지 않는다. 오히려 더 유창한 모델일수록 잘못된 답을 더 그럴듯하게 설명할 수 있기 때문에, 구조적 통제가 더 중요해진다.
강연자의 프레임워크는 완성된 제품 아키텍처라기보다 설계 원칙에 가깝다. 먼저 Semantic Layer와 Canonical Tables로 신뢰 가능한 출발점을 만들고, 필요할 때 Database Graph로 확장하며, 라이브 지식 소스와 피드백 루프를 통해 컨텍스트를 계속 갱신해야 한다. 그리고 마지막으로, 아직 명확한 해법이 없는 선호도 문제를 장기적인 연구 과제로 남겨두어야 한다. 이 순서는 기업이 에이전트 도입을 실험에서 운영으로 옮길 때 특히 유용한 기준이 된다.
마무리 / 핵심 정리
Ishita Daga의 결론은 간단하지만 무겁다. 엔터프라이즈 에이전트가 실패하는 핵심 이유는 모델이 충분히 크지 않아서가 아니라, 기업 내부 지식이 에이전트가 사용할 수 있는 형태로 구조화되어 있지 않기 때문이다. 모호성은 Source of Truth의 위계를 요구하고, 최신성은 컨텍스트 생명주기와 평가 루프를 요구하며, 선호도는 팀과 개인의 의미 체계를 반영하는 더 정교한 라우팅을 요구한다.
이 강연은 기업용 AI 에이전트를 구축하는 팀에게 중요한 경고를 던진다. 에이전트에 더 많은 문서를 넣고 더 많은 툴을 붙이는 것만으로는 신뢰할 수 있는 시스템이 되지 않는다. 오히려 정보가 많아질수록 어떤 정보를 우선해야 하는지에 대한 구조가 더 절실해진다. 결국 좋은 엔터프라이즈 에이전트는 단순히 똑똑한 모델이 아니라, 조직의 데이터 정의, 업무 맥락, 피드백, 선호도를 지속적으로 관리하는 지식 운영 시스템 위에서 만들어진다.
📚 출처 및 참고
| 구분 | 내용 |
|---|---|
| 원본 영상 | Enterprise Agents Have a Structure Problem - Ishita Daga, Tesla |
| 채널 | AI Engineer |
| 리포트 작성 | 2026-07-20 |
| 작성 방식 | YouTube 영상 STT 변환 후 에디팅 |
💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용은 원본 영상을 참조해 주세요.