멀티테넌시(Multi-Tenancy)가 에이전트 플랫폼의 진짜 문제입니다

대부분의 에이전트 데모가 잘 작동하는 이유는 사용자가 단 한 명뿐이기 때문입니다.

사용자가 한 명이라는 것은 메모리 저장소, 도구 세트, 그리고 해피 패스(happy path)가 하나뿐임을 의미합니다. 분리해야 할 대상이 전혀 없는 것이죠.

데모를 플랫폼으로 전환할 때, 어려운 점은 프롬프트가 아닙니다. 진짜 어려운 점은 격리(isolation)입니다.

모든 데이터베이스 쿼리, 캐시 키, 스트림, 도구 호출, 메모리 조회가 어느 테넌트에 속하는지 증명할 수 있습니까? 단 하나라도 그렇지 못하다면, 데이터 유출 사고가 발생할 위험이 있습니다.

많은 팀이 모델 선택이나 메모리 품질에 집중합니다. 하지만 한 테넌트의 데이터와 비용이 다른 테넌트와 분리되어 있는지 묻는 것을 잊곤 합니다.

격리는 마지막에 추가하는 작업이 아닙니다. 그것은 플랫폼의 형태 그 자체여야 합니다.

진정한 에이전트 플랫폼을 구축하려면 다음과 같은 메커니즘을 살펴보십시오:

  • 그래프로 전달되는 타입이 지정된(typed) 요청 컨텍스트(request context).
  • 모든 경계에서의 스코프가 지정된(scoped) 접근 제어.
  • 사고로 이어지기 전에 테넌트 유출을 잡아내는 테스트.

단일 사용자 에이전트는 보안을 무시하면서도 인상적으로 보일 수 있습니다. 테넌트 필터 없이 검색 도구를 호출하거나 단순한 ID 아래에 히스토리를 저장할 수도 있죠. 데모에서는 작동할지 몰라도, 플랫폼에서는 실패합니다.

플랫폼에서 에이전트는 모든 단계에서 경계를 유지해야 합니다. 만약 에이전트가 그 경계를 놓친다면, 잘못된 사람에게 완벽한 답변을 제공할 수도 있습니다. 그것은 실패입니다.

데이터, 도구 또는 메모리에 접근하는 모든 작업은 모델이 동작하기 전에 반드시 테넌트별로 스코프가 지정되어야 합니다. 이는 에이전트 런타임에 적용되는 표준 백엔드 보안 원칙입니다.

아키텍처를 위한 실질적인 단계:

  • 느슨한 파라미터 대신 단일 RequestContext 객체를 사용하십시오.
  • 모든 경계가 컨텍스트를 수락하거나, 그렇지 않으면 실패하도록 만드십시오.
  • 모델이 도구 카탈로그를 보기 전에 필터링하십시오.
  • 벡터 필터링을 권한 부여(authorization)의 필수 요소로 사용하십시오.
  • 트레이스와 로그가 민감한 데이터 대신 불투명한(opaque) 테넌트 태그를 사용하도록 하십시오.

모델에게 테넌트를 기억해 달라고 요청하지 마십시오. 모델은 데이터에 대해 추론할 수는 있지만, 그 데이터의 소유자가 누구인지 결정해서는 안 됩니다.

스코프가 지정된 경로가 가장 쉬운 경로가 되도록 구축하십시오. 단일 사용자 모델을 기반으로 플랫폼을 구축한다면, 첫 번째 실제 조직이 가입하는 날 전체를 다시 작성해야 하는 상황에 직면하게 될 것입니다.

하나의 에이전트 흐름을 추적하는 것부터 시작하십시오. HTTP 요청부터 최종 도구 호출까지 테넌트 컨텍스트를 따라가 보십시오. 해당 컨텍스트가 복사되거나 누락되는 모든 지점을 매핑하십시오. 그 매핑 결과가 바로 여러분의 진짜 리스크가 존재하는 곳입니다.

Source: https://dev.to/luffy_14/multi-tenancy-is-the-real-agent-platform-problem-1dh2

Optional learning community: https://t.me/GyaanSetuAi