JYP Garden

에이전트 정보 경계 관리 (Agent Information Boundary)

Properties1
tagsconcept, agentic-architecture, knowledge

9 min read

에이전트 정보 경계 관리 (Agent Information Boundary)

에이전트를 분리한 이후에도 두 에이전트가 같은 팀으로 운영되려면 정보 경계를 매일 관리해야 한다. 핵심: 일방향 자동 동기화(본체→external) + 민감정보 추출 스크립트 + 에스컬레이션 경로 + 오탐 관리. 분리는 시작일 뿐이다.

문제: 분리 후 정보 구버전 문제

agent-security-design에서 정의한 에이전트 분리는 보안 구조를 설계한다. 그러나 분리 후에는 새로운 운영 문제가 발생한다:

원본이 업데이트되면 external의 복사본이 구버전으로 멈춘다.

수동으로 external 워크스페이스에 정보를 넣어줬다면 → 원본이 바뀔 때마다 수동으로 맞춰야 한다 → 반드시 빠뜨리는 경우가 생긴다.

해결: 자동화된 일방향 동기화 구조.

일방향 동기화 원칙

방향: 항상 본체 → external. 역방향은 없다.

external은 스스로 정보를 생성하거나 본체에 쓰지 않는다. 정보 흐름의 단방향성이 보안과 일관성을 모두 보장한다.

원본 단일화: 운영정보를 수정할 때 본체 문서만 고치면, 자동으로 external에 반영된다. agent-skill-ecosystem-trust의 SSOT(Single Source of Truth) 원칙과 동일하다.

매일 밤 sync 스크립트 (cron 기반)

본체 워크스페이스
   ├─ SOUL.md / IDENTITY.md  ──→ 그대로 복사
   ├─ 정책 문서 (policies.md) ──→ 그대로 복사
   ├─ 템플릿 / 공유 폴더 ──────→ 전체 동기화
   │
   └─ 운영정보.md (원본)
         ↓ [민감정보 추출 스크립트]
         ↓ 최저가·쿠폰·연락처·감사료 제거
         CS용 편집본 (61% 축소)
         ↓
   external 워크스페이스

(출처: bbojjak-openclaw-information-boundary-lesson20)

민감정보 추출 스크립트 패턴

민감정보를 “넣지 않는다”가 아니라 “자동으로 제거한다”는 접근이 핵심이다.

장점:

  • 원본 문서는 그대로 유지 (본체 운영에 편리)
  • 제거 규칙이 코드에 명시적으로 선언됨 → 사람 실수 없음
  • 원본 변경 → 자동 재추출 → external에 반영

제거 대상 카테고리:

  • 가격/비용 정보 (최저가, 쿠폰 전략, 할인율, 감사료)
  • 개인정보 (연사 연락처, 팀원 이메일/ID)
  • 시스템 정보 (Airtable 연동정보, API 토큰)
  • 내부 운영 기록 (발송 기록, 매출 데이터)

자동화/수동 균형

모든 것을 자동 동기화할 수는 없다.

항목방식이유
정책 문서, 정체성 파일자동 동기화내용 변경 없이 그대로 복사 가능
운영정보 (민감정보 제거 후)자동 추출+동기화규칙 기반 필터링 가능
MEMORY.md (현황 스냅샷)수동 관리상태 변화·맥락 판단 필요

MEMORY.md는 “개강이 완료됐는지”, “수강변경 마감이 임박했는지” 같은 상태 변화를 사람이 판단해서 기록해야 한다.

에스컬레이션 패턴

external은 공개 정보를 안내하고, 처리 불가한 요청은 본체로 위임한다.

external이 처리 불가한 요청
    ↓
Slack에 자동 보고 (message(action='send') + 멘션)
    ↓
본체가 에스컬레이션 받아 처리

에스컬레이션 경로 설계 체크리스트:

  • external이 처리 불가한 케이스가 명확히 정의되어 있는가?
  • 본체가 에스컬레이션을 수신하는 채널이 있는가?
  • 에스컬레이션 후 처리 결과를 사용자에게 다시 전달하는 경로가 있는가?

오탐(False Positive) 관리

보안 규칙이 너무 엄격하면 정상 사용을 차단한다. 이를 오탐(False Positive)이라 한다.

사례: 팀원의 일반 운영 질문 → prompt-guard가 인젝션으로 오탐 → 팀원 당황.

근본 원인: 내부 Slack 채널에 외부 사용자 대상 보안 규칙을 그대로 적용.

채널별 보안 차별화:

채널보안 수준이유
내부 Slack완화신뢰된 팀원만 접근
외부 웹훅 (채널톡, 커뮤니티)강화 유지불특정 외부 사용자

오탐 관리 사이클:

  1. 오탐 발생 기록 (learnings/prompt-injection.md §6에 append)
  2. 원인 분석 (어떤 패턴이 트리거됐는가?)
  3. 채널별 규칙 차별화 적용
  4. 화이트리스트 예외 처리 추가
  5. 다음 세션에서 패턴 반영 (즉시 학습 구조)

agent-error-learning-loop의 “사고→원인분석→규칙 추가” 루프와 동일한 패턴이 보안 오탐에도 적용된다.

분리 운영 체크리스트

분리 설계 시

  • 외부 에이전트 매핑 채널 결정 (채널톡, 커뮤니티 등)
  • 공개/비공개 정보 목록 명시
  • 민감정보 추출 스크립트 작성
  • 동기화 스케줄 설정 (cron 기반)
  • 에스컬레이션 경로 설계

운영 중 점검

  • 원본 변경 시 편집본에 자동 반영되는가?
  • 오탐/미탐 사례가 기록·분석되고 있는가?
  • external의 답변 품질이 유지되고 있는가?
  • MEMORY.md(수동 관리 항목)가 최신 상태인가?

관련 개념

엔터프라이즈 AI 데이터 주권 제어 (Cloud Next ‘26 사례)

google-workspace Cloud Next ‘26에서 발표한 데이터 주권 제어는 에이전트 정보 경계 관리를 엔터프라이즈 레이어에서 구현한 사례다:

  • 데이터 처리 위치 고정: 미국·EU 내에서만 데이터 처리 및 저장 (GDPR 준수; 독일·인도 예정)
  • Client-side encryption: 가장 민감한 데이터에 대해 모든 에이전트 및 Google 자체 접근까지 차단 — “권위적으로 거부” 가능한 암호화 레이어
  • Workspace AI 데이터 정책: 고객 데이터는 사람이 검토하지 않으며, 허락 없이 Gemini 모델 학습에 활용되지 않음

(출처: google-workspace-next-2026-10-announcements, cloocus-google-workspace-ai, valid_as_of: 2026-04-22)

이는 OpenClaw의 에이전트 분리·민감정보 추출 원칙과 동일한 철학을 플랫폼 레벨 암호화·위치 고정으로 구현한 것이다.

소스

그래프 뷰