멀티 에이전트를 짤 때 각 에이전트에게 자기 일에 필요한 권한을 다 주는 건 자연스러워 보인다. 콘텐츠 기획자 에이전트가 조사한 내용을 파일로 남기려면 쓰기 권한이 필요하지 않나. 그런데 보안 실무자의 설계는 반대였다. 매니저 에이전트에게만 권한을 주고, 나머지 서브 에이전트에게는 읽기만 줬다. 쓰기가 필요한 순간에는 매니저에게 보고하게 하고, 매니저가 판단해 대신 권한을 행사한다.
근거
역할별로 필요한 권한을 따져 보면 대부분의 에이전트는 읽기만으로 자기 일을 끝낼 수 있다. 쓰기가 필요한 건 결과를 확정하는 마지막 한 걸음뿐이고, 그 한 걸음을 한 곳으로 모으면 감시 대상이 N개에서 1개로 줄어든다.
애초에 각각이 쓰기 권한을 다 가져 버리면 관리하기가 너무 어렵거든요. 권한을 가지고 있는 에이전트가 매니저 하나로 모이니까 관리해야 되는 범위가 줄어들게 되는 거죠.
내가 흥미롭게 본 건 이게 성능 최적화가 아니라 감사 가능성(auditability)의 설계라는 점이다. 여기에 두 겹이 더 붙는다. 하나는 에이전트 간 대화에 이상 신호가 없는지 상시 관찰하는 감시 에이전트다. 사람이 계속 들여다볼 수 없는 자리를 대신 지킨다. 다른 하나는 로깅 원칙 — 권한을 가진 에이전트는 언제, 어떤 권한을, 왜 썼는지를 전부 남긴다. 목적은 실시간 차단이 아니라 사고 후 추적이다.
권한 집중은 병목처럼 보이지만, 사고가 났을 때 되짚을 지점을 하나로 만들어 준다는 점에서 오히려 속도를 지킨다. 어디서 무엇이 잘못됐는지 모르는 시스템이 진짜 느린 시스템이다.
연결된 생각
- 20260612-main-worker-agent-architecture — 메인-워커 구조가 보안 관점에서 갖는 이점
- 20260608-multi-agent-effectiveness-conditions — 멀티 에이전트를 나누는 기준이 페르소나가 아니라 구조라는 논지의 연장
- 20260814-blast-radius-over-prevention-in-agent-security — 권한 최소화가 왜 실질적 방어선인지
- 20260814-irreversible-action-list-precedes-approval-gate — 매니저에게 모인 권한 중 사람이 개입할 지점을 고르는 기준