에이전트에게 쓸 권한이 아니라 요청할 권한만 준다
삼성계정(약 21억 사용자)이 Bedrock AgentCore 위에 프로덕션 멀티 에이전트 AIOps 시스템을 구축했고, 하중을 받는 선택은 모델이 아니라 권한 경계입니다 — 에이전트는 쓰기 권한이 없고 정확한 커맨드를 **제안**만 하며, 사람이 검토한 뒤 별도의 **결정적 스케줄러가 승인된 산출물을 그대로 실행**합니다. 분석은 틀려도 다시 검증하면 되지만, 실행이 틀리면 돌이킬 수 없습니다. "프롬프트가 아닌 무언가로 판단과 실행을 분리하라"의 실제 배포판입니다.
이 페이지는 카드에 적힌 내용을 펼쳐 보여줄 뿐입니다 — 돌아가는 코드도, 열어볼 데모도 아직 없습니다. 무엇을 왜 만들려는지가 아래에 있습니다.
아직 범위 미정 — 프로덕션을 건드리는 모든 에이전트에 적용할 수 있는 설계 패턴 연구입니다. 먼저 에이전트의 행동을 읽기(분석)와 쓰기(실행)로 나누고, 쓰기 경로가 LLM 을 아예 거치지 않는지 확인합니다. 그다음 제안/실행 분리를 구현합니다 — 에이전트는 *무엇을 실행할지*(정확한 커맨드·코드)를 등록하고, 사람이 그 산출물을 그대로 검토하고, 결정적 실행자가 승인된 산출물을 재생성 없이 **그대로** 실행합니다. 그들이 쓰는 성숙도 사다리를 더합니다 — Level 1 은 읽기 전용 교차 도메인 분석(위험 낮고 시간 가장 많이 잡아먹음), Level 2 는 계획 → 승인 → 실행이고, 게이트는 정확히 읽기/쓰기 선에 있습니다. 단일 입구 가드레일을 얹습니다 — 모든 요청이 수렴하는 Orchestrator 하나에 PII 마스킹·라우팅·장기 메모리가 한 번 적용 — 그래서 에이전트를 늘려도 경계가 흩어지지 않습니다. 측정 가능한 질문: 당신의 운영 잡무 중 읽기 전용 분석(오늘 안전히 자동화 가능) 대 쓰기 행동(게이트)의 비중은 얼마이고, 자동화는 *에이전트* 권한이 아니라 *실행자* 절차를 더해 자라는가? 출처: AWS 블로그, 삼성계정 SRE, "삼성계정 AIOps" Part 1, 2026-09-03 — AgentCore 벤더 쇼케이스; 제품 프레이밍은 가중하되 패턴이 요점.
기술 노트
각 항목이 실제로 무엇을 보여주고 어떻게 동작하는지 — 위 카드보다 자세한 기술 설명입니다.
목적: **한 문장이 설계 전체를 나릅니다 — 분석은 틀려도 사람이 검증하지만 실행이 틀리면 돌이킬 수 없으므로, 에이전트에게는 요청할 권한만 주고 쓸 권한은 주지 않는다.** 에이전트는 정확한 커맨드·코드를 제안하고, 별도의 결정적 스케줄러가 승인된 산출물을 그대로 실행하며, LLM 은 쓰기 경로를 결코 건드리지 않습니다. 승인 게이트 뒤에서 비결정적 판단과 결정적 실행을 떼어놓는 것. 이 목록이 사방에서 도달했던 원칙의 프로덕션 형태입니다 — `agentic-intent-veto`(모델 밖에 사는 거부권), `simulate-before-sign`(돌이킬 수 없는 행동 전 검사), 그리고 `constraint-was-the-product` 의 마무리 — untrusted 입력을 읽으면서 중대한 행동도 할 수 있는 에이전트는 그 둘을 *프롬프트가 아닌 무언가*로 분리해야 한다. 여기서 그 무언가는 스케줄러 + 정확한 산출물에 대한 사람의 승인입니다. **확장 방식이 반직관적이고, `constraint-was-the-product` 와 같은 교훈입니다.** 더 많이 자동화하려 에이전트에게 더 큰 권한을 준 게 아니라, 에이전트를 요청-전용으로 얼리고 *실행자*가 안전히 돌릴 수 있는 절차 목록을 늘렸습니다. 자동화는 검증된 실행 경로를 더해 넓어지지, 에이전트 권한을 풀어 넓어지지 않으므로, 커버리지가 커져도 사람이 통제하는 안전선은 제자리입니다. 그리고 3계층 구조 — Orchestrator → 도메인 Supervisor → Sub-agent — 는 GitHub 가 Copilot 도구를 40 → 13 으로 줄인 그 이유로 존재합니다: 단일 에이전트의 판단은 도구·도메인이 늘수록 나빠지므로, 책임을 도메인으로 나눠 각 에이전트가 작고 검토 가능한 표면만 봅니다. 에이전트당 도구가 적을수록 판단이 낫다 — 한 조직 건너 같은 발견. **거버넌스는 의도적으로 단일 지점이고, 이것이 소프트웨어로 구현된 `the-boundary-is-the-unit` 입니다.** 모든 요청이 Orchestrator 하나로 수렴해 거기서 가드레일(PII 마스킹)·라우팅·메모리가 한 번 적용되므로, N 개 에이전트가 N 개 경계가 되지 않습니다 — 에이전트를 더해도 거버넌스는 움직이지 않습니다. 감사 로그마저 자기 자신이 유출 경로가 되지 않게 단단히 합니다 — 탐지된 PII 는 원본이 아니라 마스킹·해시로 저장되며, 정확히 관측 계층에 적용된 `what-encryption-does-not-hide` 입니다. 그 아래에는 정직한 전제 하나가 있습니다 — LLM 은 비결정적이고, 만 번의 좋은 실행이 만한 번째를 증명하지 않는다, `a-boolean-hides-a-state-machine` 의 경고를 운영 형태로. 답은 더 나은 프롬프트가 아니라 구조입니다 — 비결정적 부분은 자문으로 두고, 되돌릴 수 없는 것은 결정적이고 사람이 게이트하는 실행자에게 맡긴다.
동작 방식: ### 모든 것을 조직하는 선: 읽기 대 쓰기 | | Level 1 — 분석(읽기) | Level 2 — 실행(쓰기) | | --- | --- | --- | | 위험 | 낮음 — 틀린 답은 다시 검증 | 높음 — 틀린 행동은 돌이킬 수 없음 | | 누가 결정 | 에이전트들이 도메인 넘어 병렬로 | 사람이 승인; 그다음 결정적 실행자가 수행 | | 먼저 자동화? | 예 — 시간 최다, 위험 최소 | 승인 게이트 뒤에서만 | ### 제안 대 실행 — 안전하게 만드는 분리 | | 에이전트 | 스케줄러 | | --- | --- | --- | | 권한 | 요청만 — 쓰기 없음 | 승인된 산출물을 실행 | | 생산물 | 정확한 커맨드/코드 제안 | 변경을, 그대로, 재생성 없이 | | 성격 | 비결정적(LLM) | 결정적 | | 사람 위치 | 실행 전 정확한 산출물 검토 | — | ### 안전선을 옮기지 않고 자동화를 넓히는 법 | 솔깃한 수 | 대신 한 것 | | --- | --- | | 에이전트에 쓰기 권한 부여 | 에이전트를 요청-전용으로 유지 | | 더 많은 작업 위해 제한 완화 | **실행자**의 검증된 절차 목록을 늘림 | | 모든 도구를 가진 큰 에이전트 하나 | 3계층(Orchestrator → Supervisor → Sub-agent), 각자 작은 표면 | | 에이전트마다 가드레일 | Orchestrator 하나, 가드레일/라우팅/메모리 한 번 적용 | ### 관련 카드 `agentic-intent-veto`·`simulate-before-sign`(돌이킬 수 없는 행동 전, 모델 밖의 검사/거부권), `constraint-was-the-product`(경계로서의 "프롬프트 아님"; 도구 적을수록 판단 나음), `the-boundary-is-the-unit`(단일 지점 거버넌스), `a-boolean-hides-a-state-machine`(비결정성: 한 번 잘 됐다고 증명 아님), `what-encryption-does-not-hide`(자기 유출 경로가 아닌 마스킹·해시 감사 로그).