엔티티 해결이 AI 에이전트의 핵심 문제인 이유

저희 Revo AI는 이메일 위에 앰비언트 AI 에이전트를 구축하고 있습니다. 이메일이 AI 에이전트의 콜드 스타트 문제를 해결하는 이유에 대해 이미 다룬 바 있습니다. 이번 포스트는 이를 구축하면서 발견한 가장 어려운 엔지니어링 문제와 이것이 앰비언트 AI 전반에서 가장 어려운 문제라고 생각하는 이유에 관한 것입니다.

화려하지 않아서 아무도 말하지 않는 문제

AI 대화는 모델에 관한 것입니다. 추론 품질, 컨텍스트 윈도우, 도구 사용, 추론 속도. 이 모든 것이 중요합니다. 하지만 프로덕션 에이전트가 실제로 고장나는 곳은 이런 것들이 아닙니다.

에이전트는 엔티티 해결에서 고장납니다.

동일한 사람이 Slack에서는 이름으로, 계약서에서는 전체 이름으로, 스레드에서는 이메일 도메인으로, CRM 레코드에서는 회사명으로, 지원 티켓에서는 계정 ID로 나타납니다. 전문적인 컨텍스트에서 작동하는 에이전트는 이 모든 신호를 보고 환각 없이 이들이 동일한 엔티티를 지칭하는지, 그리고 해당 엔티티가 알고 있는 다른 모든 것과 어떤 관계인지 결정해야 합니다.

이를 잘못 처리하면 에이전트가 조용히 실패하는 것이 아닙니다. 잘못된 거래의 언어를 사용해 응답을 작성합니다. 잘못된 연락처에 후속 조치를 합니다. 민감한 대화를 봐서는 안 되는 사람과 연결합니다. 앰비언트 에이전트의 엔티티 해결 실패는 UX 문제가 아닙니다. 관계 위험이자 잠재적인 프라이버시 침해입니다.

이것이 Revo AI에서 다른 무엇보다 많은 시간을 할애한 문제입니다. 아직 완전히 해결되지 않았습니다 — 관리되고 있을 뿐입니다. 우리가 배운 것은 다음과 같습니다.

왜 엔티티 해결이 검색이나 CRM보다 에이전트에서 구조적으로 더 어려운가

엔티티 해결은 새로운 문제가 아닙니다. 검색 엔진, CRM, 데이터 웨어하우스는 수년간 이 문제의 여러 버전을 다뤄왔습니다. 하지만 에이전트는 세 가지 이유로 더 어려운 버전에 직면합니다.

오류 비용이 비대칭적입니다. 일반 이메일 클라이언트의 잘못된 자동완성은 성가실 뿐입니다. 대신 초안을 작성하고 전송하는 에이전트의 잘못된 엔티티 매칭은 관계 위험입니다. 오류에 대한 허용 범위가 수동 도구보다 한 자릿수 낮습니다.

신호가 더 시끄럽습니다. 이메일은 비공식적이고 일관성이 없으며 인간적입니다. 사람들은 수천 개의 메시지에서 동일한 엔티티를 수십 가지 다른 방식으로 언급합니다. 스키마가 없습니다. 강제된 명명 규칙이 없습니다. 에이전트는 대규모로 구조화되지 않은 신호에서 구조를 추론해야 합니다.

그래프가 동적입니다. 엔티티는 변합니다. 사람들은 역할을 바꿉니다. 회사는 인수되고 도메인이 변경됩니다. 엔티티 그래프는 한 번 구축하고 캐시할 수 없습니다 — 새 메시지가 도착할 때마다 지속적으로 업데이트되어야 하고, 새로운 신호가 알고 있던 것과 모순될 때 충돌을 표시해야 합니다.

Revo AI에서 실제로 구축한 것

우리는 처리되는 모든 메시지와 함께 업데이트되는 살아있는 엔티티 그래프를 유지합니다. 이 그래프는 사람, 회사, 거래, 스레드, 도구를 연결하며 — 다양한 명명 규칙과 데이터 소스에 걸쳐 동일한 엔티티를 실시간으로 해결합니다.

그래프가 충돌하는 신호를 만나면 — 같은 회사의 James라는 이름의 두 연락처, 인수 후 변경된 도메인, 두 명의 다른 사람을 지칭할 가능성이 있는 이름 — 추측하는 대신 모호함을 표시합니다. 우리는 해결되지 않은 모호함을 억제할 오류가 아닌 일급 상태로 취급합니다.

이는 자동화 범위를 희생시킵니다. 모호함을 표시한다는 것은 일부 작업이 자동으로 수행되지 않고 대신 사람이 검토할 수 있도록 표면화된다는 의미입니다. 우리는 의도적으로 이러한 트레이드오프를 선택했습니다. 대안 — 추측하고 틀리는 것 — 은 사용자가 에이전트를 영구적으로 끄게 만드는 종류의 실패를 초래합니다.

엔티티 해결은 또한 엄격한 프라이버시 경계 내에서 이루어져야 합니다. 전문적인 받은편지함을 읽는 에이전트는 클라이언트, 거래, 팀, 조직 계층에 걸친 민감한 정보에 액세스할 수 있습니다. 엔티티 그래프는 엔티티가 어떻게 연결되어 있는지뿐만 아니라 에이전트가 무엇을 연결할 수 있는지도 알아야 합니다. 도메인 수준 액세스 제어는 선택적 인프라가 아닙니다 — 해결 로직의 핵심 부분입니다. 프라이버시 제어가 없는 엔티티 해결은 기능이 아니라 책임입니다.

앰비언트 AI가 작동할 때 실제로 하는 일

대부분의 앰비언트 AI 제품은 "기술적으로 정확함"과 "신뢰할 수 있음" 사이의 격차에서 사라졌습니다. 어려운 부분은 행동할 수 있는 에이전트를 만드는 것이 아닙니다 — 언제 행동하지 말아야 하는지 아는 에이전트를 만드는 것입니다.

엔티티 해결이 작동할 때 화요일 아침은 다음과 같습니다:

오전 8:14. "Lisa Chen이 Meridian 계약서의 IP 조항을 플래그했습니다. Acme 거래에서 사용한 표준 언어로 응답 초안이 준비되었습니다."

오전 8:22. "James Park으로부터 2분기 예산에 대한 응답 없음 (5일). 후속 조치 초안 작성됨."

오전 9:01. "Sarah가 마이그레이션이 완료되었다고 언급했습니다. 3개의 클라이언트 티켓이 해당 버그를 참조합니다. 업데이트 초안 작성됨."

각각: 수락, 거부 또는 피드백 제공. 이것이 전체 상호작용 표면입니다. 에이전트가 작업을 계획했습니다. 사용자가 출력을 관리합니다.

UX 결과: 신뢰는 점진적으로 구축됩니다

우리는 Revo AI 에이전트가 좁게 시작해서 더 넓은 작업으로 확장되도록 설계했습니다. 첫날에는 간단한 것들을 표면화합니다: 잊어버린 후속 조치, 대기 중인 응답을 위한 초안, 표시된 충돌. 수락 또는 해제. 구성, 프롬프팅, 매뉴얼 없이.

이것이 원래 설계는 아니었습니다. 기술적으로는 정확했지만 신뢰할 준비보다 빠르게 움직이는 에이전트를 초기 사용자들이 끄는 것을 보고 대응한 것입니다. 점진적 공개는 단순한 UX 패턴이 아닙니다 — 에이전트가 더 높은 위험의 작업을 시작하기 전에 엔티티 해결이 작동하는지 확인할 충분한 시간을 사용자에게 주는 방법입니다.

이것이 에이전트 인프라에 의미하는 것

엔티티 해결은 기능이 아니라 인프라입니다. 실제 전문적인 컨텍스트에서 작동하는 AI 에이전트가 행동하도록 신뢰할 수 있는지, 아니면 데이터가 복잡해지는 순간 고장나는 정교한 데모인지를 결정하는 계층입니다.

대부분의 에이전트 프레임워크는 이를 엣지 케이스로 취급합니다. 그렇지 않습니다. 핵심 문제입니다. 장기적으로 사용되는 에이전트는 최고의 추론을 가진 것이 아니라 그래프 아키텍처, 모호함 처리, 프라이버시 제어 및 신뢰 속도의 올바른 조합으로 이를 해결하는 것입니다.

이메일은 엔티티 해결을 해결하기 가장 어려운 환경입니다. 데이터가 가장 지저분하고 오류 허용 범위가 가장 낮기 때문입니다. 그것이 바로 이메일에서 이를 해결하는 것이 일반화되는 이유이기도 합니다. Revo AI에서 전문적인 받은편지함에 걸쳐 엔티티를 해결하기 위해 구축한 인프라는 모든 앰비언트 에이전트가 구조화되지 않은 실제 데이터에서 안정적으로 작동하는 데 필요한 것과 동일한 인프라입니다.

공감하신다면 연락주세요: mehdi@revo.ai