#Agent 아키텍처: 실행 Agent에게는 거부권이 있어야 한다

← 전체 목차 · 이전: 프롬프트를 가득 채우지 마라 — 점진적 공개의 3층 깔때기 · 다음: 사용자가 중간에 목표를 바꾸면 이전 단계는 어떻게 폐기 판정하는가

멀티 Agent 시스템에서 실행 Agent가 Planner와 의견이 다를 때 시키는 대로 해야 하는가, 거부해야 하는가. 답은 실행 Agent는 실행기가 아니라 시스템의 두 번째 관문이다.

계획을 받았다고 바로 실행하면 안 된다. 먼저 **3층 검증(실행 가능성 / 권한 / 안전)**을 하고, 문제를 발견하면 거부하며, 구조화된 사유를 Planner에게 피드백해 재계획하게 만들어 클로즈드 루프를 형성한다.

원칙 한 줄: 계획은 가설일 뿐이고, 실행 전 검증이 사실이다. Planner는 가설을 생성하고, 실행 Agent는 사실을 검증하며, 검증에 실패하면 사유를 되돌려 보낸다. 안전하게 돌아가는 멀티 Agent 시스템에 필요한 능력 세 가지는 거부할 줄 알고, 피드백할 줄 알고, 루프를 닫을 줄 아는 것이다.

#왜 이 검증층이 반드시 필요한가

많은 팀의 멀티 Agent에서 실행 Agent는 무뇌 실행기다. Planner가 동쪽으로 가라면 동쪽으로 가고, 계획에 "DROP DATABASE"가 쓰여 있으면 그대로 실행한다. 사고가 나고 나서야 시스템에 차단 장치가 하나도 없었다는 것을 알게 된다.

논증 사슬은 이렇다.

1. Planner는 생성자이고, 생성자는 본질적으로 틀린다.
2. Planner가 보는 세계는 컨텍스트에서 추론해낸 것이지 실제 환경의 권한 테이블, 도구 시그니처, 리소스 목록이 아니다.
3. Anthropic의 멀티 Agent 리서치 시스템도 각 하위 작업마다 **목표(Goal), 출력 포맷(Format), 도구 경계(Boundary)**를 명확히 하라고 강조한다.
4. 그러나 경계를 아무리 명확히 써도 계획이 실제 환경에 떨어지면 여전히 권한 없는 DB를 건드리고, 금지된 도구를 호출하고, 존재하지도 않는 중간 결과에 의존할 수 있다.
5. 결론: 대규모 모델의 계획은 확률적 생성이지 "컴파일 통과 = 안전"이 아니다. 이 검증은 생략할 수 없다.

#Agent와 순수 워크플로의 본질적 차이

워크플로의 안전성은 코드 안에 쓰여 있지만, Agent의 안전성은 실행 측 검증으로 보충해야 한다. Agent의 경로가 하드코딩되어 있지 않기 때문에 스스로 검증층을 길러내야 하는 것이다.

#구현 3단계

#1단계 · 정적 검증

• 도구가 허용 목록에 있는가
• 파라미터 포맷이 맞는가
• 대상 리소스가 실행 측의 권한 테이블에 있는가

#2단계 · 동적 검증 (실제 자격증명으로 사전 점검)

권한이 있는지를 모델이 판단하게 하지 않고 실제 자격증명으로 사전 점검한다는 점이 핵심이다. 자격증명의 마운트 범위가 곧 그 Agent의 능력 경계다.

#3단계 · 사유를 구조화해 되돌려 보내기

Planner에게 통보:
  실패 사유:   재무 DB 읽기 권한 없음
  실패 위치:   2단계에서 막힘
  대안 제안:   재무 읽기 전용 뷰로 우회 / 또는 임시 권한을 먼저 신청
    ↓
Planner가 피드백을 받아 재계획
    ↓
1회 클로즈드 루프 완성

#프로덕션에서 자주 밟는 함정 두 가지

#받쳐주는 장치 3종

1. 재계획 상한 — 최대 3라운드, 초과하면 사람에게 넘긴다.
2. 코드 레벨 관문 — 고위험 동작은 이 경로로. 거부 규칙이 언제나 허용 규칙보다 우선하며 모델의 자각에 기대지 않는다.
3. 구조화된 거부 — 거부 사유는 반드시 구조화 필드여야 한다: 실패 단계 / 결손 / 대안 제안. 그래야 기계가 읽을 수 있다.

#4층 답변 프레임

1층 · 실행 Agent
   계획을 받으면 먼저 3층 검증: 실행 가능성 / 권한 / 안전

2층 · 거부와 피드백
   문제 발견 시 실행 거부, 구조화된 사유 피드백
   (실패 단계, 결손, 대안 제안 포함)

3층 · Planner 재계획
   피드백을 받아 재계획
   재계획 상한 설정, 초과 시 사람에게 전환

4층 · 코드 레벨 안전 백스톱
   고위험 동작은 코드 레벨 안전 콜백으로 받침
   거부 규칙이 언제나 허용 규칙보다 우선
   안전이 모델의 자각에 의존하지 않도록 보장

#핵심 통찰

1. 생성과 검증은 서로 다른 역할이 맡아야 한다 — Planner는 생성자이고 그 세계 모델은 실제 환경이 아니라 컨텍스트 추론에서 온다. 생성자가 자기를 검증하게 하는 것은 검증이 없는 것과 같다. 실행 Agent가 거부권을 가져야 하는 이유는 그것이 시스템에서 유일하게 실제 자격증명·실제 도구 목록·실제 권한 테이블을 보유한 역할이기 때문이다.
2. "계획은 가설일 뿐, 실행 전 검증이 사실"이 이 문서의 골격이다 — Planner의 출력을 "가설"로 강등시키면 가설은 반증 메커니즘에 둘러싸여야 한다는 결론이 자연히 따라온다. 이 강등 동작이 멀티 Agent를 데모급에서 프로덕션급으로 넘기는 분수령이다.
3. 확률적 생성은 컴파일 통과가 아니다 — 대규모 모델의 계획에는 타입 시스템이 오류를 막아주지 않는다. 엔지니어링에서 유일한 대체재가 명시적 검증층이며, "검증층 설계를 답하지 못하면 실제 프로젝트 경험이 없다"는 판별 기준이 여기서 나온다.
4. 안전 능력은 코드에 써야지 프롬프트에 쓰면 안 된다 — 프롬프트 속 "거부해도 된다"는 선택지이고, 모델이 망설이면 통과시킨다. 코드 레벨 관문은 강제 차단이다. 이 구분이 곧 "거부 규칙이 언제나 허용 규칙보다 우선"의 구현 전제다.
5. 거부 자체는 가치를 낳지 않고, 기계가 소비 가능한 거부라야 가치를 낳는다 — 거부 사유가 자연어 산문이면 Planner는 그 자리에서 재시도할 수밖에 없다. 실패 단계 / 결손 / 대안 제안 세 개의 구조화 필드로 쪼개야 정보 증분이 있는 재계획을 구동할 수 있다.
6. 모든 자동 재시도 루프에는 차단기가 내장되어야 한다 — 거부 + 재계획은 루프를 이루며, 상한이 없으면 Token을 태우는 무한 루프가 된다. "최대 3라운드, 초과 시 사람에게 전환"이 클로즈드 루프를 이론에서 운영 가능한 시스템으로 만드는 결정적 한 획이다.
7. Agent와 워크플로의 차이가 각자의 안전 전략을 결정한다 — 워크플로는 경로가 사전 정의되어 코딩 시점에 안전성을 일괄 보장할 수 있다. Agent는 실행 피드백으로 경로를 동적 조정하므로 안전성은 런타임에 매번 검증할 수밖에 없다. 워크플로의 사고방식으로 Agent를 만들면 검증층 전체를 누락한다.
8. 좋은 답변은 개방형 문제를 구조화한다 — "시키는 대로 vs 거부"는 양자택일 선택지이며 어느 쪽을 골라도 깊이가 드러나지 않는다. 계층 프레임과 각 층의 명확한 산출물, 백스톱 방안을 제시하면 엔지니어링 문제로 바뀐다.

#엔지니어링 실전 Tips

• 자격증명이 곧 사실의 출처: 동적 검증의 신뢰도는 "실제 자격증명으로 사전 점검"에서 오지, 모델이 스스로 권한이 있는지 판단하는 데서 오지 않는다. 자격증명의 마운트 범위가 그 Agent의 능력 경계다.
• 거부가 허용보다 우선: 거부 규칙과 허용 규칙이 동시에 적중하면 언제나 거부로 집행한다. 이 우선순위는 코드에 하드코딩해야지 모델 중재에 맡기면 안 된다.
• 프롬프트는 경향만 만들고, 코드가 제약을 만든다: "거부해도 된다"를 프롬프트에 넣는 것은 거부 확률을 높일 뿐이다. 프로덕션 월권 사고는 거의 모두 "모델이 잠깐 망설이고 그냥 실행한" 틈에서 발생한다.
• 재시도 루프에 카운터를 달 것: Agent ⇄ Planner의 왕복에는 반드시 라운드 상한과 사람 출구가 있어야 한다. 그렇지 않으면 실패가 Token 소모의 형태로 무한 증폭된다.
• 대안 제안이 클로즈드 루프의 연료: 거부에 "재무 읽기 전용 뷰로 우회 / 임시 권한 신청" 같은 선택 가능한 경로가 실려 있지 않으면 Planner는 똑같이 실행 불가능한 계획을 다시 만들어낼 가능성이 크다.
• 하위 작업 정의에 도구 경계를 포함시킬 것: 각 하위 작업마다 목표·출력 포맷·도구 경계를 명확히 하면 검증층이 발동되는 횟수를 줄일 수 있다. 다만 검증층을 대체하지는 못한다.
• 아키텍처 리뷰를 체크리스트로 만들 것: "실행 Agent에게 거부권이 있는가 / 검증은 어느 층에 있는가 / 거부 후 클로즈드 루프는 어떻게 보장하는가 / 누가 백스톱인가" 네 질문을 리뷰 체크리스트로 그대로 쓸 수 있다.