Agentic Banking을 위한 Authority Architecture: Gemini Enterprise Agent Platform 위의 거버넌스 계층
글 NATARAJA Team
은행들은 agentic AI를 정말 중요한 자리로 옮기고 있습니다. 여신 결정, 지급 승인, 사기 거래 보류, KYC(고객확인) 및 AML(자금세탁방지) 심사, 한도 변경, 자금 운용이 그 자리입니다. agentic banking에서 AI agent는 리스크에 점수만 매기지 않습니다. 그 리스크에 대해 직접 행동합니다. 바로 그 전환점에서 인프라 거버넌스가 끝나고 의사결정 거버넌스가 시작됩니다.
Google의 Gemini Enterprise Agent Platform은 agent 자체에 대한 강력한 거버넌스 기반, 즉 아이덴티티, 접근 제어, 정렬 검사, 감사를 은행에 제공합니다. 그 기반 위에 자연스럽게 얹히는 두 번째 계층이 의사결정 권한, 곧 decision authority입니다. 어느 agent가 어떤 은행 업무 결정을, 어떤 한도 내에서, 누구의 위임 아래, 누구에게 책임을 지며 내릴 수 있는가의 문제입니다. 그 계층이 바로 Authority Architecture에 관한 Executive Authority Brief의 주제이며, 이 계층을 플랫폼과 결합할 때 비로소 유능한 은행 agent들의 무리가 통제된 시스템으로 바뀝니다.
이 글은 세 가지를 다룹니다. 먼저 Gemini Enterprise Agent Govern을 NATARAJA의 agentic AI framework 및 주권적 의사결정의 5대 법칙(5 Laws of Sovereign Decision Making)과 비교합니다. 다음으로 agentic banking을 위한 Authority Architecture가 어떤 모습인지 제시합니다. 마지막으로 Gemini Enterprise Agent Govern 위에서 Authority Architecture를 구동하는 구현 예시를 보여드립니다.
Gemini Enterprise Agent Govern이 제공하는 것
Google의 플랫폼은 네 가지 축으로 agent를 통제하며, 각각 실질적으로 유용합니다.
- Agent Registry. 조직 전체의 agent, 도구, Model Context Protocol 서버를 저장하고 검색하고 통제하는 중앙 카탈로그입니다.
- Agent Identity와 Agent Gateway. 모든 agent가 아이덴티티를 부여받고, 트래픽은 게이트웨이를 통해 인증된 정책 기반 연결로 라우팅됩니다. 권한 위임은 IAP, Model Armor 또는 커스텀 인가 서비스를 통해 이루어집니다.
- IAM 정책과 IAM 조건, 그리고 Semantic Governance 정책. agent가 어떤 서비스를 호출할 수 있는지에 대한 세밀한 접근 제어와, agent의 행동이 사용자 의도 및 조직의 제약과 정렬되어 있는지 검사하는 의미론적 계층입니다.
- Model Armor와 감사 추적. 입력과 출력에 대한 콘텐츠 검사, 그리고 감사와 모니터링을 위한 데이터 접근 및 요청-응답 로그입니다.
요컨대 이 플랫폼은 정확하고 중요한 질문, 즉 이 agent가 이 서비스에 안전하고 관측 가능하게 도달하고 호출할 수 있는가에 답합니다. Authority Architecture는 이 글이 다루는 상호 보완적인 질문, 즉 이 agent가 어떤 결정을 내릴 수 있는가에 답합니다.
접근 권한에서 decision authority로
IAM은 agent에게 API를 호출할 권한을 부여합니다. Authority Architecture는 은행 업무 결정을 내릴 권한을 부여합니다. 두 계층은 상호 보완적이며, 이 둘을 구분해서 유지하는 것이 책임 소재를 명확하게 지키는 길입니다.
여신 agent가 approveCredit을 호출할 IAM 권한을 가질 수 있습니다. 그러나 은행이 실제로 답해야 하는 거버넌스 질문은 이것입니다. 누구의 위임된 권한 아래, 얼마까지, 어떤 고객 리스크 등급에 대해 승인할 수 있는가, 한도에 근접하면 어떻게 상신되는가, 잘못되었을 때 결과를 책임지는 실명의 사람은 누구인가. 이 가운데 어느 것도 IAM 바인딩 안에 있지 않습니다. Authority Architecture 안에 있습니다.
이것이 agentic AI framework의 핵심 논지입니다. 거버넌스는 접근 경로만이 아니라 의사결정 자체에 설계되어 들어가야 합니다. 그리고 이는 주권적 의사결정의 5대 법칙과 깔끔하게 대응됩니다.
- 구조화된 의사결정 설계(Structured Decision Design) 는 명시적이고 기계가 읽을 수 있는 권한 경계를 정의합니다. 플랫폼은 IAM 조건과 게이트웨이 인가 정책으로 그 경계를 집행하지만, 의사결정 등급, 위임 체계, 상신 임계값을 설계하는 일은 은행의 몫입니다.
- 통합된 데이터와 맥락(Integrated Data & Context) 은 의사결정이 사용하는 입력을 통제합니다. 플랫폼은 근거와 맥락을 공급하고, 프레임워크는 특정 결정에 어떤 맥락이 권위 있는 것인지 결정합니다.
- 추적 가능한 추론(Traceable Reasoning) 은 입력, 추론, 대안에 대한 검증 가능한 기록을 요구합니다. 요청-응답 로그는 그 토대이고, 의사결정 수준의 추론 추적 가능성은 그 위에 얹힙니다.
- 정렬된 실행(Aligned Action) 은 실행이 의도 및 리스크 성향과 일관되도록 유지합니다. Semantic Governance 정책은 여기서 강력한 기본 요소이며, 프레임워크는 각 은행 업무 위임(mandate)에 대해 "정렬되었다"가 무엇을 뜻하는지 정의합니다.
- 감사 가능한 영향(Auditable Impact) 은 결과를 책임 있는 소유자와 연결합니다. 감사 추적이 이를 뒷받침하지만, 책임 매핑을 설계하는 일은 은행의 몫입니다.
패턴은 일관됩니다. Gemini Enterprise Agent Govern은 집행과 관측의 평면입니다. Authority Architecture는 무엇을 집행할지 그 집행 평면에 알려주는 의사결정 거버넌스 평면입니다.
agentic banking을 위한 Authority Architecture의 모습
Authority Architecture는 누가 무엇을 결정할 수 있는지에 대한 명시적이고 통제된 지도입니다. agentic banking에서는 애플리케이션이 아니라 의사결정을 중심으로 이를 구축해야 합니다. 결과가 중대한 모든 결정에는 네 가지가 부여됩니다. 권한 등급(authority tier), 위임의 출처, 기계가 읽을 수 있는 한도, 그리고 실명의 책임 소유자가 지정된 상신 경로입니다.
은행에서 실제로 작동하는 등급 체계는 다음과 같습니다.
- Tier A: 자율. 결과가 경미하고, 되돌릴 수 있으며, 대량으로 발생하는 결정입니다. 중복 거래 탐지, 명세서 생성, 소액 사기 플래그가 여기에 해당합니다. agent가 실행하고, 사람은 집계 수준에서 검토합니다.
- Tier B: 한정된 자율. agent는 엄격한 한도 내에서 실행하고, 예외는 모두 상신됩니다. 임계값 이하의 신용 한도 변경, 일정 금액 이하의 지급 승인, KYC 재심사, 표준적인 분쟁 처리가 여기에 해당합니다.
- Tier C: 권고만 허용. 결과가 중대하거나 되돌릴 수 없는 결정입니다. 임계값을 넘는 대출 승인, 고객 거래 종료, AML 의심거래보고, 대규모 자금 운용이 여기에 해당합니다. agent는 추적 가능한 권고안을 준비하고, 책임 있는 사람이 결정합니다.
핵심은 은행 업무를 느리게 만드는 것이 아닙니다. 자율 권한과 인간 권한 사이의 경계를 명시적으로 만들고, 집행하고, 감사 가능하게 만들어, agent가 행동할 때 위임한 권한과 책임 소유자로 거슬러 올라가는 사슬이 온전히 유지되도록 하는 것입니다. 이것이 바로 Executive Authority Brief Control Note가 이사회 수준의 집행 가능한 통제로 번역해 놓은 내용입니다. 위의 등급들은 사실 하나의 경로입니다. Executive Decision Platform(경영 의사결정 플랫폼)이 의사결정을 보조 모드에서 통제된 자율 모드로 옮겨가는 과정에 대한 산업 공통의 관점은 자율적 의사결정으로 가는 여정에 관한 가이드를 참고하시기 바랍니다.
Gemini Enterprise Agent Govern 위의 구현 예시
Authority Architecture가 플랫폼에 어떻게 대응되는지 살펴보겠습니다. 아키텍처는 설계이고, 플랫폼은 집행입니다.
1. authority profile과 함께 agent를 등록합니다. Agent Registry에 각 은행 업무 agent를 등록하면서, 권한 등급, 내릴 수 있는 의사결정 유형, 금액 한도, 적용되는 고객 리스크 조건, 위임하는 역할, 상신 대상을 기록하는 메타데이터를 함께 등록합니다. 레지스트리는 단순한 agent 카탈로그가 아니라 은행의 권한 목록이 됩니다.
2. Agent Identity와 IAM으로 접근 경계를 설정합니다. 각 agent에 Agent Identity를 부여한 다음, IAM 정책과 IAM 조건으로 거친 수준의 권한 경계, 즉 해당 아이덴티티가 애초에 호출할 수 있는 도구와 서비스를 고정합니다. 한도 변경 agent는 한도 변경 도구는 호출할 수 있지만 송금 도구는 호출할 수 없으며, 조건을 통해 리소스, 환경, 시간 기준으로 접근을 더 좁힐 수 있습니다. IAM은 어떤 행동이 도달 가능한지에 답합니다. 이것이 구조화된 의사결정 설계의 가장 바깥 고리입니다.
3. Agent Gateway에서 의사결정 한도와 상신을 집행합니다. IAM은 어떤 행동이 도달 가능한지를 통제하고, 거래 금액과 같은 비즈니스 한도는 한 계층 위에 있습니다. 모든 행동을 Agent Gateway를 거쳐, 요청 자체를 검사하는 커스텀 인가 서비스로 라우팅합니다. 저위험 고객에 대한 5만 파운드 여신 승인은 통과하지만, 같은 agent가 50만 파운드를 시도하거나 Tier C 결정을 시도하면 확정 전에 IAP를 통해 인간 승인자에게 위임됩니다. 금액과 리스크 등급 한도가 실제로 검사되는 곳, 그리고 human-in-the-loop 상신이 사후 조치가 아니라 인가 위임으로 구현되는 곳이 바로 여기입니다.
4. Semantic Governance로 행동을 의도에 결속합니다. Semantic Governance 정책을 사용해 agent의 행동이 여신 위임, 리스크 성향, 고객 대우 원칙과 정렬되어 있는지 검사하고, IAM으로는 허용되지만 의도와는 어긋난 행동을 잡아냅니다. 이것이 운영 가능해진 정렬된 실행이며, 세 가지 권한 등급이 실제로 살아 움직이는 계층입니다. 등급별 정책과 구성 예시는 아래에 있습니다.
5. 검사하고 기록합니다. 입력과 출력의 콘텐츠 가드레일에는 Model Armor를 사용하고, 플랫폼의 감사 추적을 원천 기록으로 사용합니다. 그런 다음 그 위에 의사결정 수준의 추적 가능성을 얹습니다. 모든 Tier B와 Tier C 행동에 대해 입력, 추론, 검토된 대안, 그리고 어떤 권한 아래 실행되었는지를 캡처하여, 그 결정이 SRE에게 관측 가능한 수준을 넘어 감독 당국에 방어 가능한 수준이 되도록 합니다.
6. 책임으로 순환을 닫습니다. 로그를 책임 매트릭스로 흘려보내, 모든 의사결정을 실명의 인간 소유자와 상신 경로에 매핑합니다. 그것이 감사 가능한 영향이며, "로그가 있다"와 "agent가 틀렸을 때 누가 책임자였는지 입증할 수 있다"의 차이입니다.
종합하면, 플랫폼은 아이덴티티, 접근 제어, 정렬 검사, 가드레일, 로그를 제공합니다. Authority Architecture는 그 기본 요소들에게 무엇을 집행할지 알려주는 의사결정 등급, 위임 체계, 상신 임계값, 책임 매핑을 제공합니다. 둘은 상호 보완적입니다. 플랫폼은 집행하고 기록하며, Authority Architecture는 무엇을 집행하고 기록할지 결정합니다.
권한 등급별 Semantic Governance 정책
Semantic Governance 정책은 플랫폼의 정책 엔진이 도구 호출 실행 전에 LLM 심판으로 평가하는 자연어 규칙으로, 세 가지 판정 중 하나를 반환합니다. ALLOW(허용), DENY(거부), 또는 인간 확인을 요구하는 PROMPT입니다. 이 세 판정은 세 가지 권한 등급과 거의 일대일로 대응되며, 그래서 Semantic Governance는 은행 업무 agent의 위임장을 리스크 담당 임원이 읽을 수 있는 언어로 기술하기에 자연스러운 자리가 됩니다.
정책은 특정 agent 또는 특정 도구에 적용 범위가 지정되며, 제약 조건은 최대 5,000자의 평이한 영어 문장입니다. 몇 가지 agentic banking agent를 대상으로 등급별로 어떤 모습인지 살펴보겠습니다.
Tier A: 자율 agent
예시 agent: 명세서 및 알림 agent. 명세서와 소액 알림을 생성합니다. 위임 범위는 넓지만 파급 반경이 거의 없으므로, 정책은 이 agent를 그 차선 안에 확실히 묶어 둡니다.
"정상 거래 상태의 모든 계좌에 대해 명세서 생성, 잔액 요약, 거래 알림을 허용한다. 자금을 이동시키거나, 신용 한도를 변경하거나, 계좌를 개설 또는 해지하거나, 고객의 리스크 분류를 변경하는 모든 행동은 거부한다."
gcloud beta ai semantic-governance-policies create stmt-agent-scope \
--agent=statement-notifications-agent \
--natural-language-constraint="Allow statement generation, balance summaries, and transaction notifications for any account in good standing. Deny any action that moves money, changes a credit limit, opens or closes an account, or alters a customer's risk classification."
Tier A 정책은 대부분 ALLOW이되, 결과가 중대한 모든 것에는 단단한 DENY 울타리를 두릅니다. 이 agent는 상신할 일이 없습니다. 상신이 필요할 만한 결정에 애초에 도달할 수 없기 때문입니다.
Tier B: 한정된 자율 agent
예시 agent: 카드 한도 agent. 정책 범위 내에서 신용카드 한도를 조정합니다. PROMPT가 진가를 발휘하는 곳이 여기입니다. agent는 엄격한 경계 안에서 자율적으로 실행하고, 경계에 이르면 사람에게 상신합니다.
"최근 12개월간 연체가 없는 저위험 또는 중위험 등급 고객에 대해 현재 한도의 20퍼센트까지의 신용 한도 상향을 허용한다. 20퍼센트를 초과하는 상향, 고위험 등급 고객, 또는 새 한도가 25,000파운드를 초과하는 경우에는 여신 담당자의 승인을 요청한다. 사기 플래그가 설정되었거나, 채권 회수 중이거나, 채무 조정 약정 상태인 계좌의 한도 변경은 모두 거부한다."
gcloud beta ai semantic-governance-policies create card-limit-bounds \
--agent=card-limit-agent \
--natural-language-constraint="Allow credit-limit increases up to 20 percent of the current limit for customers in risk tier low or medium with no arrears in the last 12 months. Prompt for approval from a credit officer for any increase above 20 percent, for customers in risk tier high, or where the new limit would exceed GBP 25000. Deny any limit change on accounts flagged for fraud, in collections, or under a hardship arrangement."
예시 agent: 지급 승인 agent. 형태는 같고 결정만 다릅니다. 금액 구간 내에서는 ALLOW, 그 위로는 PROMPT, 제재 대상 거래상대방에게는 DENY입니다.
"기존에 검증된 수취인에 대한 5만 파운드까지의 대외 지급 승인을 허용한다. 5만 파운드를 초과하는 지급 또는 최근 24시간 이내에 추가된 수취인에 대한 지급에는 이중 승인을 요청한다. 제재 대상 기관 또는 은행의 제한 국가 목록에 있는 국가로의 지급은 모두 거부한다."
PROMPT 판정은 Authority Architecture의 상신 경로를 한 줄로 표현한 것입니다. agent가 일상 업무를 처리하고, 사람은 모든 일이 아니라 정확히 경계에서만 개입합니다.
Tier C: 권고 전용 agent
예시 agent: 여신 결정 agent. 대출 권고안을 준비합니다. Tier C의 핵심은 agent가 결정을 확정해서는 안 된다는 것이므로, 정책은 확정 행동을 아예 거부하고 agent를 초안 작성에 국한시킵니다.
"이 agent가 여신 서류를 취합하고, 상환 능력 심사를 수행하고, 서면 권고안을 작성하는 것을 허용한다. 대출을 승인, 거절 또는 실행하는 모든 행동은 거부한다. 모든 여신 결정은 실명의 인간 여신 담당자가 확정해야 한다."
gcloud beta ai semantic-governance-policies create credit-recommend-only \
--agent=credit-decision-agent \
--natural-language-constraint="Allow this agent to assemble the credit file, run affordability checks, and prepare a written recommendation. Deny any action that approves, declines, or disburses a loan. Every credit decision must be committed by a named human credit officer."
예시 agent: AML 조사 agent. 의심거래보고서 초안을 작성합니다. 감독 당국에 대한 보고는 인간의 행위이므로, agent는 준비하고 대기열에 올릴 수는 있어도 결코 직접 보고할 수는 없습니다.
"이 agent가 알림을 조사하고, 증거를 수집하고, 의심거래보고서 초안을 준법 검토 대기열에 작성해 올리는 것을 허용한다. 감독 당국에 보고서를 제출하거나 알림을 종결하는 모든 행동은 거부한다. 제출과 처분은 실명의 준법감시 담당자에게 유보된다."
Tier C 정책은 Tier A의 기본값을 뒤집습니다. 자율적으로 할 수 있는 영역은 준비 작업뿐이고, 결과가 중대한 모든 행동은 기본 거부에 인간의 확정 단계가 얹힙니다. 바로 이것이 운영자 과실인가, 설계 실패인가라는 질문에 답할 수 있게 해 줍니다. 기록이 agent는 권고했고 실명의 사람이 결정했음을 보여주기 때문입니다.
왜 이것이 IAM만이 아니라 Semantic Governance에 속하는가
IAM과 게이트웨이는 어떤 행동이 도달 가능한지, 그리고 어떤 수치 한도 내에서 가능한지를 집행합니다. Semantic Governance는 위임장처럼 읽히는 계층을 더해, 기술적으로는 허용되지만 의도와 어긋난 행동을 잡아냅니다. 예컨대 한도 아래에 있지만 해당 고객의 거래 패턴에 맞지 않는 수취인에게 향하는 지급이 그렇습니다. 위임장을 평이한 영어로 기술한다는 것은, 그 결정에 책임을 지는 사람들, 즉 여신 담당자, 준법감시 담당자, 리스크 위원회가 엔진이 집행하는 바로 그 문장을 읽고 승인할 수 있다는 뜻이기도 합니다. 그것이 운영 가능할 뿐 아니라 읽을 수 있게 된 정렬된 실행입니다.
왜 이것이 다른 어디보다 은행에서 더 중요한가
은행은 이 간극이 가장 아프게 파고드는 곳입니다. 정렬이 어긋난 agent는 단순히 나쁜 출력물을 내놓는 데 그치지 않습니다. 여신을 실행하고, 지급을 승인하고, 감독 당국에 보고서를 제출할 수 있습니다.
agentic banking의 의사결정이 손실을 초래했을 때, 감독 당국과 이사회와 법원이 가장 먼저 던질 질문은 AI 사고에 관한 Executive Authority Brief가 제기하는 바로 그 질문입니다. 운영자 과실인가, 설계 실패인가. Authority Architecture가 없으면 은행은 이 질문에 답할 수 없습니다. agent가 행동했지만, 누구의 권한 아래, 어떤 한도 내에서, 위임 범위 안에서였는지 밖에서였는지 알 수 없기 때문입니다. Authority Architecture가 있으면 답은 이미 기록에 있습니다. 정의된 agent가, 위임된 권한 아래, 집행된 경계의 안 또는 밖에서 행동했다는 것입니다. 책임이 어디에 떨어지는지를 결정하는 것이 바로 이 하나의 구분입니다.
압력은 커지기만 합니다. 경쟁 가속과 시스템 리스크 노출은 이 함정을 이렇게 설명합니다. 모든 은행이 경쟁사보다 빠르게 agentic AI를 확장해야 한다고 느끼고, 그 경주 속에서 통제되지 않은 권한이 조직 전체로 퍼지며 시스템 리스크가 조용히 누적됩니다. Authority Architecture는 은행이 시스템 리스크를 같은 속도로 키우지 않으면서 경쟁적 속도로 움직일 수 있게 하는 규율입니다. 새로 추가되는 모든 agent가 암묵적이고 무한한 경계가 아니라 명시적이고 집행되는 경계를 물려받기 때문입니다.
바로 그래서 Authority Architecture에 관한 Executive Authority Brief는 권한을 플랫폼 팀에 위임되는 기술적 세부사항이 아니라, 전략, 재무 성과, 리스크와 나란히 놓이는 이사회 수준의 독립된 영역으로 다룹니다.
자주 묻는 질문
agentic banking에서 decision authority란 무엇입니까?
decision authority(의사결정 권한)는 AI agent가 특정한 은행 업무 결정을 내릴 수 있는 통제된 권리입니다. 어떤 결정을, 어떤 한도까지, 누구의 위임 아래, 누구에게 책임을 지며 내릴 수 있는가입니다. 이는 접근 권한과 구별됩니다. 인프라 거버넌스(아이덴티티, IAM, 감사)는 agent가 서비스에 도달할 수 있는지를 통제하고, decision authority는 도달할 수 있게 된 뒤 어떤 결정을 내릴 수 있는지를 통제합니다. agent가 리스크에 점수만 매기는 것이 아니라 직접 행동하는 agentic banking에서는, 그 권한이 명시적이어야 하고, 런타임에서 집행되어야 하며, 책임 있는 사람에게까지 추적 가능해야 합니다.
IAM 권한과 decision authority의 차이는 무엇입니까?
IAM은 agent에게 API를 호출할 권한을 부여하고, decision authority는 비즈니스 결정을 내릴 권리를 부여합니다. 여신 agent가 approveCredit을 호출할 IAM 권한을 가질 수는 있지만, 거버넌스 질문(얼마까지, 어떤 고객 리스크 등급에 대해, 어떤 상신 절차로, 결과를 책임지는 실명의 사람은 누구인가)은 IAM 바인딩이 아니라 Authority Architecture 안에 있습니다. 두 계층은 상호 보완적이며, 이 둘을 구분해서 유지하는 것이 책임 소재를 명확하게 지키는 길입니다.
어느 AI agent가 어떤 은행 업무 결정을 내릴 수 있습니까?
이는 각 애플리케이션이 아니라 각 의사결정에 부여되는 권한 등급으로 정해집니다. 실제로 작동하는 등급 체계는 이렇습니다. 결과가 경미하고 되돌릴 수 있으며 대량으로 발생하는 결정에는 Tier A(자율), agent가 엄격한 한도 내에서 실행하고 예외를 상신하는 Tier B(한정된 자율), agent가 추적 가능한 권고안을 준비하고 실명의 사람이 결정을 확정하는 Tier C(권고만 허용)입니다.
agentic banking을 위한 Authority Architecture란 무엇입니까?
누가 무엇을 결정할 수 있는지에 대한 명시적이고 통제된 지도입니다. 결과가 중대한 모든 결정에는 권한 등급, 위임의 출처, 기계가 읽을 수 있는 한도, 그리고 실명의 책임 소유자가 지정된 상신 경로가 부여됩니다. 이 지도는 Gemini Enterprise Agent Govern과 같은 플랫폼 위에 얹혀, 플랫폼의 집행 기본 요소들에게 무엇을 집행할지 알려줍니다.
결론
Gemini Enterprise Agent Govern은 강력한 기반이며, 은행은 그 위에 구축해야 합니다. 플랫폼은 agent를 통제하고, Authority Architecture는 그 agent들이 내리는 의사결정을 통제합니다. 둘이 함께할 때 아이덴티티, 접근 제어, 감사는 이사회와 감독 당국과 고객이 신뢰할 수 있는 무언가로 바뀝니다. 명시적 권한, 집행되는 한도, 실질적인 상신, 그리고 결코 인간의 손을 떠나지 않는 책임입니다.
귀사의 agentic banking 체계를 Authority Architecture에 비추어 점검하고, 어떤 AI 투자가 실제로 의사결정을 개선하고 있는지 확인하고 싶다면, AI Value Realisation Review로 시작하거나 통제된 파일럿을 요청하시기 바랍니다. 전체 논증은 이 모든 것이 시작된 Executive Authority Brief 시리즈에서 보실 수 있습니다.