Enterprise Agents Have a Structure Problem - Ishita Daga, Tesla

한 줄 핵심

기업용 에이전트의 실패 원인은 단순히 더 큰 모델이 아니라, 모호한 소스 선택·낡은 컨텍스트·사용자별 선호를 구조적으로 다루지 못하는 데 있으며, 이를 해결하려면 컨텍스트와 평가 체계를 먼저 설계해야 한다.

시간별 요약

1. 0:01
   기업용 에이전트가 잘못 답할 때 흔히 더 큰 모델, 더 긴 컨텍스트, 더 많은 문서나 MCP 서버를 떠올리지만, 실제 문제는 모델 성능보다 에이전트 구조에 있다. 데이터 에이전트의 실패 원인을 먼저 분해해야 해결 방향이 보인다.
2. 1:00
   핵심 문제는 ambiguity, staleness, preference의 세 가지다. 어떤 테이블·컬럼·지식베이스를 써야 하는지 모호하고, KPI와 정의가 자주 바뀌어 컨텍스트가 금방 낡으며, 팀과 개인마다 같은 지표도 다른 방식으로 계산하는 선호가 존재한다.
3. 3:01
   ambiguity는 소스 오브 트루스를 계층적으로 정리하면 줄일 수 있다. semantic layer를 최상위 기준으로 두고, canonical tables를 그다음에 배치하며, 가장 유연하지만 유지보수가 어려운 database graph는 마지막에 두는 방식이 실용적이다.
4. 6:00
   staleness는 context life cycle로 관리해야 한다. 항상 최신 상태로 유지되는 데이터 소스와 이벤트 로그·피드백 루프를 연결해 정의 변경, 잘못된 답변, 새 필터 규칙을 기록하고, 이를 평가와 업데이트에 다시 반영해야 한다.
5. 9:00
   preference는 가장 어려운 문제로, 같은 지표라도 팀마다 계산 방식이 달라 정답이 하나로 고정되지 않는다. semantic layer나 메모리 파일로 일부 해결은 가능하지만, 결국 사용자나 팀 맥락에 따라 적절한 metric으로 라우팅하는 구조가 필요하다.
6. 11:01
   결론적으로 기업용 에이전트는 더 큰 모델보다 더 나은 구조가 중요하며, 특히 컨텍스트 관리와 평가 체계를 함께 설계해야 안정적으로 동작한다. preference 문제는 아직 열린 과제로 남아 있어 추가 연구가 필요하다.

실무 인사이트

• 기업용 데이터 에이전트를 만들 때는 모델 교체보다 먼저 source of truth 계층화와 컨텍스트 업데이트 흐름을 설계하는 것이 효과적이다.
• 정의 변경과 오답 사례를 이벤트로 남기고 평가 세트에 반영하는 루프를 만들면, 에이전트 품질 저하를 조기에 감지할 수 있다.
• 지표 계산의 선호가 팀별로 다르면 단일 정답을 강제하기보다 팀·사용자별 라우팅 규칙을 두는 편이 운영에 유리하다.