홈 AI 서버는 각 사용자의 컨텍스트를 어떻게 분리하나요?

홈 AI 서버는 동일한 모델을 공유하면서도 각 사용자의 컨텍스트를 분리할 수 있지만, 그 분리는 모델 자체에서 오는 것이 아닙니다. 모든 채팅, 메모리 기록, 검색된 문서, 캐시 항목 및 도구 호출을 인증된 사용자와 연결한 후에야 그 정보가 프롬프트에 도달하기 때문입니다.

두 사람이 별도로 로그인할 수 있는데 한 사용자의 질문이 다른 사람의 노트를 검색한다면, 실패는 보통 모델 주변 애플리케이션에 있습니다. 유용한 테스트는 신원이 전체 요청 경로를 통과하는지 여부입니다. 이 글은 그 경로를 따라가며 격리가 반드시 시행되어야 하는 곳, 흔히 깨지는 곳, 그리고 더 강력한 경계가 정당화되는 시점을 보여줍니다.

모델은 공유할 수 있지만 개인 컨텍스트는 공유할 수 없습니다

모델 가중치는 공통 추론 엔진입니다. 모델이 일반 추론 요청을 처리할 때 가족 구성원이나 동료마다 별도의 복사본이 필요하지 않습니다. 반드시 분리되어야 하는 것은 특정 요청을 위해 그 가중치 주변에 조립된 정보입니다.

그 정보에는 현재 채팅, 저장된 대화 기록, 사용자 환경 설정, 검색된 파일 구절, 벡터 검색 결과, 도구 출력, 임시 캐시 및 자격 증명이 포함됩니다. 이 계층들이 모여 개인 컨텍스트를 형성합니다. 두 요청이 동일한 모델 프로세스를 거치더라도 다른 사용자는 다른 컨텍스트 패키지를 받아야 합니다.

이 구분은 아키텍처를 실용적으로 유지합니다. 홈 서버는 여러 개의 동일한 모델 복사본을 로드하지 않으면서도 각 어시스턴트를 개인화하는 데이터를 격리할 수 있습니다. 격리 경계는 신원, 저장, 검색, 세션 및 도구 접근에 속하며, 단순히 모델에게 프라이버시를 존중하라고 지시하는 프롬프트에 있지 않습니다.

신원은 요청 전 과정을 따라야 합니다

별도의 로그인 화면은 첫 번째 단계일 뿐입니다. 인증은 요청하는 사람이 누구인지 확인하고, 권한 부여는 그 신원이 접근할 수 있는 채팅, 파일, 메모리 및 작업을 결정합니다. 효과적인 격리는 사용자가 인터페이스를 열 때뿐만 아니라 모든 데이터 경계에서 인증 후 권한 부여를 필요로 합니다.

서버는 검증된 세션 또는 액세스 토큰에서 안정적인 사용자 ID를 도출해야 합니다. 폼 필드, URL 매개변수 또는 채팅 메시지에서 전송된 사용자 ID를 신뢰해서는 안 됩니다. 그렇지 않으면 클라이언트가 제어하는 값을 하나만 변경해도 다른 사람의 기록을 요청할 수 있습니다.

서버에서 파생된 신원은 이후 모든 조회의 일부가 됩니다. 대화 쿼리, 벡터 검색, 파일 경로, 캐시 키, 도구 자격 증명 모두 동일한 신뢰된 사용자 범위를 필요로 합니다. 하위 서비스 중 하나가 이를 잃으면, 시스템은 프런트엔드가 여전히 별도의 계정을 표시하더라도 조용히 공유 컨텍스트로 돌아갑니다.

내구성 메모리는 저장소 수준의 경계가 필요합니다.

장기 메모리는 보통 관계형 데이터베이스, 문서 저장소 또는 디스크의 파일에 저장됩니다. 각 레코드에는 소유자 또는 테넌트 식별자가 필요하며, 모든 읽기, 업데이트, 삭제 작업은 해당 신원으로 제한되어야 합니다. 광범위한 쿼리 후에 데이터를 필터링하는 것은 너무 늦습니다.

데이터베이스 정책은 애플리케이션 코드 아래에서 두 번째 집행 지점을 제공할 수 있습니다. 데이터베이스가 레코드를 반환하기 전에 현재 사용자를 평가하면, 한 애플리케이션 경로에서 필터가 누락되어도 교차 사용자 노출 가능성이 줄어듭니다.

파일 기반 메모리도 동일한 규율이 필요합니다. 각 사용자에게 전용 디렉터리를 제공하고 소유권 및 접근 제어 규칙을 유지하며, 애플리케이션이 인증된 신원에서 경로를 해석하도록 해야 합니다. 브라우저에서 제공된 폴더 이름은 권한 경계가 아니며, 무제한 파일 시스템 접근 권한을 가진 공유 서비스 계정은 신중하게 구성된 디렉터리를 우회할 수 있습니다.

프롬프트가 생성되기 전에 검색 범위가 지정되어야 합니다.

RAG는 검색된 구절이 모델의 작업 컨텍스트에 직접 삽입되기 때문에 가장 중요한 격리 지점 중 하나를 만듭니다. 다른 사용자의 문서가 프롬프트에 도달하면 모델에게 이를 공개하지 말라고 요청하는 것은 신뢰할 수 있는 해결책이 아닙니다. 검색 계층에서 먼저 제외해야 합니다.

권한 인식 RAG 계층은 문서 접근 권한에 따라 검색 결과를 필터링할 수 있으며, 이는 어떤 구절도 프롬프트에 들어가기 전에 이루어져야 합니다. 권한 결정은 질문에 제공된 신원이 아니라 검증된 세션을 사용해야 합니다.

벡터 데이터베이스는 사용자별로 하나의 네임스페이스 또는 컬렉션을 분리하거나, 공유 인덱스 내에서 필수 메타데이터 필터를 사용하여 레코드를 분리할 수 있습니다. 격리를 위한 네임스페이스 또는 컬렉션은 쓰기, 검색, 삭제 작업의 범위를 쉽게 지정할 수 있게 하며, 메타데이터 필터링은 가정이나 팀이 공통 문서를 공유할 때 제어된 공유를 지원할 수 있습니다.

애플리케이션은 프롬프트에서 받기보다는 검증된 세션에서 네임스페이스를 선택해야 합니다. 동일한 규칙은 개인 문서에 대한 의미 검색에도 적용됩니다: 신원 필터링은 결과 반환 후 정리 단계가 아니라 유사도 순위 지정 전에 쿼리 경로에 있어야 합니다.

공유 문서에도 명확한 모델이 필요합니다. 기록은 한 사용자, 가구 그룹 또는 작업 공간에 속할 수 있지만, 해당 범위는 권한 데이터로 저장되고 일관되게 평가되어야 합니다. 문서를 여러 개인 인덱스로 복사하는 것이 작은 시스템에는 더 간단할 수 있지만, 사용자와 공유 폴더가 늘어날수록 그룹 기반 권한이 유지 관리하기 더 쉬워집니다.

세션과 캐시는 우연히 데이터를 다시 연결할 수 있습니다

데이터베이스는 완벽하게 필터링할 수 있지만 캐시는 여전히 컨텍스트를 유출할 수 있습니다. 채팅 기록이 `conversation_id`만으로 캐시되면 충돌이나 예측 가능한 식별자를 가진 두 사용자가 동일한 항목에 접근할 수 있습니다. 더 안전한 키는 신뢰된 사용자 ID와 대화 ID를 모두 포함합니다.

동일한 경계는 프롬프트 캐시, 검색된 청크 캐시, 임시 업로드 디렉터리 및 메모리 내 세션 객체에도 적용됩니다. 테넌트 인식 캐시 키는 신뢰된 사용자 ID를 캐시 읽기와 쓰기 모두에 적용하여 사용자 간 노출을 줄입니다.

로그아웃은 올바른 상태를 제거하거나 무효화해야 합니다. 서버 측 세션, 임시 파일 또는 캐시된 프롬프트를 남겨둔 채 브라우저 쿠키만 지우면 공유 컴퓨터에서 이전 사용자의 컨텍스트가 노출될 수 있습니다. 만료, 삭제 및 계정 제거는 개인 데이터를 보유한 모든 저장소에 전파되어야 합니다.

도구 호출에는 동일한 사용자 경계가 필요합니다

어시스턴트는 캘린더를 읽거나, 이메일을 검색하거나, NAS 폴더를 열거나, 자동화를 실행할 수 있습니다. 이러한 도구는 채팅 데이터베이스보다 더 많은 정보를 노출할 수 있으므로, 각 호출은 AI 서비스가 가진 단일 관리자 자격 증명 대신 요청하는 사용자의 권한을 사용해야 합니다.

로컬 파일의 경우, 도구는 사용자의 파일 시스템 접근 권한을 상속하거나 강제해야 합니다. 연결된 애플리케이션에는 통합이 지원하는 경우 사용자 범위 토큰을 사용하세요. 전역 토큰은 테스트 중에 편리할 수 있지만, 이는 어시스턴트를 원래 서비스에서 사용자가 기대하는 권한을 우회하는 경로로 만듭니다.

도구 출력도 컨텍스트가 됩니다. 요청과 동일한 사용자 및 세션 범위에 저장하고, 일반 채팅 기록에 비밀을 두지 말며, 로그에서 민감한 필드를 편집하세요. 안전한 검색 계층은 다른 사용자의 데이터를 직접 반환하는 도구를 보완하지 못합니다.

어떤 격리 패턴이 가정용 AI 서버에 적합한가?

적절한 경계는 민감도, 사용자 수, 서버 소유자가 유지할 수 있는 관리량에 따라 다릅니다. 이 표는 공유되는 것과 실수가 가장 발생하기 쉬운 위치에 따라 일반적인 설계를 비교합니다.

대부분 가정에서는 행 수준 규칙, 사용자 범위 벡터 검색, 분리된 파일 경로, 사용자별 도구 권한이 실용적인 중간 지점을 제공합니다. 사용자가 서로를 신뢰하지 않거나 도구가 임의 코드를 실행하거나 실수의 결과가 매우 클 때는 컨테이너나 별도의 기기가 유용해집니다.

왜 별도의 계정이 여전히 컨텍스트를 유출하는가

첫 번째 실패는 권한을 인터페이스에만 적용하는 것입니다. 사이드바에서 다른 사용자의 대화를 숨겨도 API가 다른 ID를 받으면 해당 대화를 반환하기 때문에 아무 소용이 없습니다. 모든 서버 엔드포인트는 권한 결정을 반복해야 합니다.

두 번째 실패는 채팅 기록을 필터링하지만 검색은 필터링하지 않는 것입니다. 어시스턴트는 올바른 대화를 표시하지만 사용자 필터 없이 공유 벡터 인덱스를 검색합니다. 그 결과 답변에 보이지 않는 스레드에 나타나지 않은 개인 정보가 포함됩니다.

세 번째 실패는 공유 운영 데이터입니다. 디버그 로그, 추적, 프롬프트 캐시, 임시 업로드, 분석에는 최종 답변과 동일한 민감한 컨텍스트가 포함될 수 있습니다. 런타임 컨텍스트는 기본 모델이 훈련되지 않았더라도 민감한 정보를 노출할 수 있습니다.

마지막 실패는 모델을 접근 제어 계층으로 신뢰하는 것입니다. 시스템 프롬프트는 개인 정보 보호 기대치를 설명할 수 있지만, 절대 검색되어서는 안 되는 컨텍스트를 신뢰할 수 있게 되돌릴 수는 없습니다. 보안 제어는 모델에 도달하는 것을 결정해야 하며, 모델이 사용자가 검색할 수 있는 것을 결정해서는 안 됩니다.

사용자 격리가 실제로 작동하는지 테스트하는 방법

고의로 다른 테스트 데이터를 가진 두 개의 일반 계정을 만드세요. 사용자 A에게는 고유하고 무해한 문구가 포함된 문서를, 사용자 B에게는 다른 문구가 포함된 문서를 제공하세요. 두 문구 모두 테스트 코퍼스 어디에도 나타나지 않아야 합니다.

사용자 B로부터 직접 질문, 모호한 의미 검색, 추측한 대화 ID, 공유 링크, 이름이 바뀐 파일, 규칙을 무시하라는 요청을 시도하세요. 목표는 정상 인터페이스를 테스트하는 것뿐만 아니라 모든 경로가 사용자 B의 범위를 벗어난 데이터를 반환하지 않는지 확인하는 것입니다.

로그아웃, 서비스 재시작, 캐시 예열, 문서 재인덱싱, 백업 복원, 계정 삭제 후 테스트를 반복하세요. 이러한 전환은 일반 채팅과 다른 코드 경로를 사용하는 경우가 많으며, 기본 쿼리 경로가 올바르게 처리하는 오래된 컨텍스트를 다시 도입할 수 있습니다.

같은 두 신원으로 서버 로그를 검토하세요. 각 검색, 파일 읽기, 메모리 쓰기, 도구 호출은 불필요하게 개인 프롬프트 내용을 기록하지 않고 예상된 사용자 범위를 가져야 합니다. 관리자는 모든 컨텍스트 항목이 최종 프롬프트에 포함된 이유를 설명할 수 있어야 합니다.

가정용 실용적 격리 설계

먼저 모델 실행과 데이터를 로컬에 유지한 다음, 서버가 세션에서 파생한 하나의 신원 서비스와 하나의 신뢰할 수 있는 사용자 ID를 사용하세요. 그 신원을 채팅 서비스, 메모리 저장소, 벡터 검색, 파일 게이트웨이, 도구 계층을 통해 전달하세요. 신원이나 권한 범위가 없으면 공유 기본값으로 대체하지 말고 요청을 거부하세요.

특정 위협이 별도의 런타임을 요구하지 않는 한 모델은 공유 상태로 유지하세요. 저장, 검색, 추론, 인터페이스, 권한의 주변 스택이 로컬 파일을 로컬 데이터에 기반한 개인 비서로 만듭니다. 모델 가중치를 복제하는 것만으로는 범위 없는 데이터베이스 쿼리를 해결하지 못합니다.

내구성 있는 기록에 사용자 또는 작업 공간 식별자를 사용하고, 가능하면 애플리케이션 아래에서 행 접근을 강제하며, 벡터 데이터를 사용자 범위 네임스페이스나 필수 필터 파티션에 두세요. 임시 파일과 캐시도 동일한 범위를 부여한 후 각 계층에 대해 만료 및 삭제 규칙을 설정하세요.

개인 지식과 공유 지식을 의도적으로 분리하세요. 가정 매뉴얼은 공용 작업 공간에 속할 수 있지만, 세금 기록은 비공개로 유지됩니다. 다중 역할 AI 서버에서는 그룹 멤버십이 해당 요청에 대해 사용자의 개인 컨텍스트에 어떤 공유 작업 공간이 결합되는지를 결정해야 합니다.

위협이 바뀌면 더 강력한 경계를 선택하세요. 사용자가 코드를 실행하거나 플러그인을 설치하거나 임의 폴더를 마운트하거나 강력한 도구를 연결할 수 있다면, 애플리케이션 필터만으로는 충분하지 않을 수 있습니다. 별도의 컨테이너, 가상 머신, 자격 증명, 저장소가 손상된 서비스가 접근할 수 있는 범위를 제한할 수 있습니다.

자주 묻는 질문

각 사용자마다 AI 모델의 별도 복사본이 필요한가요?

아니요. 여러 사용자가 하나의 추론 모델을 공유할 수 있는 이유는 개인 컨텍스트가 각 요청마다 별도로 조립될 수 있기 때문입니다. 별도의 모델 프로세스는 신뢰할 수 없는 사용자, 맞춤 어댑터, 엄격한 자원 제한, 또는 더 강력한 운영 경계가 필요한 작업 부하에 여전히 유용할 수 있습니다.

개인 컨텍스트를 보호하기 위해 별도의 채팅 기록만으로 충분한가요?

아니요. 채팅 기록은 컨텍스트의 한 출처일 뿐입니다. 검색된 문서, 벡터 인덱스, 업로드된 파일, 캐시, 도구 자격 증명, 로그, 임시 데이터도 동일한 아이덴티티 경계를 따라야 합니다. 하나의 범위 없는 계층이 보이는 대화 목록이 올바르더라도 정보를 노출할 수 있습니다.

가족 구성원이 일부 컨텍스트를 의도적으로 공유할 수 있나요?

네. 공유 문서와 기억은 명확한 가정이나 작업 공간 범위에 두고, 필요한 사용자에게 멤버십을 부여하세요. 개인 기록은 개별 소유 하에 유지하세요. 프롬프트 빌더는 현재 사용자의 개인 범위와 승인된 공유 범위를 모두에게 공개하지 않고 결합할 수 있습니다.

실용적인 규칙은 간단합니다: 컨텍스트 경로가 아니라 모델을 공유하세요. 아이덴티티는 데이터가 읽히거나 검색되거나 캐시되거나 도구에 전달되기 전에 제약을 가해야 합니다. 모든 계층이 어떤 사용자가 항목을 승인했는지 답할 수 있다면, 홈 AI 서버는 컴퓨팅이 공유되더라도 개인적일 수 있습니다.