Skip to main content
스코핑 은 한 사용자의 메모리가 다른 사용자에게 누출되지 않게 하는 방법입니다. 모든 메모리 읽기/쓰기는 스코프 키 를 가짐. 읽기는 매치되는 스코프의 항목만 보고; 쓰기는 현재 스코프로 태깅됨.

​
스코핑이 왜 중요한가

스코핑 없으면 Alice 를 돕는 Agent 가 Bob 에 대해 쓴 노트도 봄. 이것은:
  • 프라이버시 문제.
  • 품질 문제 (Bob 의 컨텍스트가 Alice 의 답변을 오염).
  • 컴플라이언스 문제 (GDPR, HIPAA).
스코핑이 하나의 설정으로 셋 다 해결.

​
스코프 모양

스코프 키는 JSON 유사 객체. 흔한 모양:
여러분이 모양을 고름. Nora 는 키를 강제하지 않음 — 단지 동등성만 강제.

​
런타임에 스코프 설정

두 가지:

​
Trigger 로부터

Trigger 가 실행에 스코프 키를 전달. 그 실행의 모든 메모리 작업이 자동으로 사용. 채팅 트리거의 경우 스코프 기본값은 { conversation_id: <session> }. Trigger 블록 설정에서 오버라이드. 웹훅 트리거는 페이로드에서 추출:

​
도구별 오버라이드

도구가 실행 기본값을 오버라이드하는 명시적 스코프로 메모리를 호출할 수 있음. 드묾 — 보통 냄새. Agent 가 정당하게 크로스-스코프 데이터를 읽어야 할 때만 (예: 지원 에이전트가 모든 고객에 걸친 자체 지식을 읽음).

​
스코프 계층

스코프는 중첩 가능. 더 넓은 스코프로 쓰면 항목이 모든 좁은 스코프에서 보임. 예:
  • { tenant: "acme" } 에 쓰기 — Acme 안의 모두가 봄.
  • { tenant: "acme", user: "alice" } 에 쓰기 — Alice 만 봄.
  • Alice 의 읽기는 자신 항목과 테넌트 전체 항목 둘 다 봄.
Space settings → Scope schema 에서 계층 설정 — 어느 키가 어느 것 아래 중첩되는지 선언.

​
크로스 스코프 접근 (주의!)

일부 Agent 는 정당하게 크로스 스코프 읽기 필요 — 지원 에이전트, 관리자 대시보드. 스페이스별 부여:
  • Cross-scope read — Agent 가 어느 스코프든 읽을 수 있음. 쓰기는 여전히 현재 스코프 존중.
  • Cross-scope everything — 읽기·쓰기. 관리자 유스케이스에만.
둘 다 스페이스에서 명시적 옵트인 필요. 기본 오프.

​
스코프 격리 테스트

Space settings → Test isolation. 두 스코프 키와 쿼리 입력. Nora 가 각 스코프에서 쿼리 실행하고 항목이 서로 누출 안 됨을 보여줌. 격리가 깨지면 시끄럽게 실패. 멀티유저 메모리를 가진 Flow 를 배포하기 전 권장.

​
누출 디버깅

Agent 가 알아서는 안 되는 것을 아는 것 같으면:
  1. 트레이스의 메모리 작업 확인 — 모든 읽기·쓰기가 스코프와 함께 로깅됨.
  2. 의도한 것보다 넓은 스코프로 쓰인 항목 찾기.
  3. 우발적 크로스 스코프 도구 호출 찾기.
가장 흔한 버그: Trigger 에서 스코프 설정 잊어서 모든 것이 단일 전역 스코프에 착지. 격리 테스트가 이걸 잡음.