Governance as Infrastructure: AWS가 본 에이전트 확산 조건과 독일 은행의 대출 프로세스 재설계

에이전트를 넓게 쓰는 회사는 규칙을 문서로만 두지 않고 에이전트가 도는 플랫폼에 경계로 심어 둔 회사라는 것이 AWS Matthias Patzak의 진단입니다. 결정을 다시 짜는 범위는 현업 한 팀의 엑셀 대체부터 주택담보대출 같은 핵심 프로세스를 처음부터 다시 그리는 일까지 셋으로 나뉩니다. 따라 하려면 지켜야 할 규칙 목록과 점검 역할의 에이전트를 먼저 준비해야 합니다.

요약

TechTarget의 Esther Shittu 기자는 2026년 11월 4일 보스턴에서 열린 AWS 미디어 행사에서 AWS executive in residence(고객 현장 경험을 가진 상주 임원) Matthias Patzak을 인터뷰했습니다. Patzak은 애자일 전환과 조직 재설계, AI 기술을 오래 다뤄 온 독일 출신 기술 리더로, 9월에 나온 AWS 리포트 「Reimagine: Turning AI into Value」의 내용을 바탕으로 답했습니다. 그는 주로 자동차 회사와 은행을 만나 소프트웨어 개발, 에이전트 구축, 업무 프로세스에 AI를 쓰는 일을 돕습니다. 책에서 배운 지식보다 자신이 고객 입장에서 같은 문제를 풀어 본 경험이 쓸모 있다고 말합니다. 인터뷰는 고객의 걱정, 업종별 거버넌스, 결정을 다시 짜는 방법, 에이전트끼리 일을 나누는 방법을 차례로 다룹니다.

고객이 가장 많이 꺼내는 걱정은 거버넌스와 책임 있는 AI 사용이고 둘째는 가치가 보이지 않는다는 점입니다. 조직에 따라 비용이나 사내 확산이 더 큰 걱정인 곳도 있습니다. Patzak은 규칙과 정책이 모호한 조직일수록 에이전트를 통제하지 못한다고 봅니다. 의외로 금융업이 AI 확산에서 가장 앞선 이유도 여기서 찾습니다. 금융사에는 이미 글로 적어 둔 통제가 많아서 에이전트에게 무엇을 지켜야 하는지 알려 줄 재료가 있다는 것입니다. 그는 거버넌스를 에이전트가 배포되는 플랫폼, 곧 인프라로 만들라고 권합니다. 결정을 다시 짜는 범위는 세 가지로 나눴습니다. 현업 전문가가 엑셀을 에이전트로 바꾸는 방식, 업무 흐름 전체를 에이전틱 AI로 최적화하는 방식, 독일 대형 은행처럼 프로세스를 처음부터 다시 그리는 방식입니다. 에이전트는 반드시 실수하므로 점검 역할의 에이전트를 함께 두고 조율 에이전트로 묶어야 한다는 권고로 인터뷰가 끝납니다. 아래에서 다섯 가지 생각을 풀고 사례와 함께 실제로 돌릴 때 필요한 기술·현업 디테일을 붙입니다.

핵심 메커니즘

Governance as Infrastructure: 정책 문서가 아니라 실행 플랫폼에 경계를 넣는다

Patzak이 말하는 거버넌스는 위원회나 지침서가 아니라 에이전트가 들어가 도는 그릇입니다. 플랫폼이 에이전트마다 접근할 수 있는 데이터, 부를 수 있는 도구, 넘지 말아야 할 한도를 정해 두면 에이전트를 몇 개 더 만들어도 경계는 그대로 따라갑니다. 작동은 네 단계입니다. 정책 문서에서 에이전트가 지켜야 할 규칙을 골라냅니다. 그 규칙을 플랫폼의 권한과 한도로 옮깁니다. 에이전트는 그 안에서만 움직이고 모든 동작은 기록됩니다. 금융사는 지침 문서를 에이전트에게 문맥으로 넘기는 방식으로 빠르게 출발했습니다. 다만 Patzak은 이것이 모범 사례는 아니라고 덧붙입니다. 문서를 통째로 읽히는 것만으로는 에이전트가 어떤 규칙을 반드시 지켜야 하는지 알 수 없기 때문입니다. 에이전트가 한두 개인 실험 단계라면 문서를 문맥으로 주는 방식도 쓸 만합니다. 부서마다 에이전트가 생기는 확산 단계에는 플랫폼 경계가 필요합니다.

작은 예시(가상): 대출 심사 에이전트에게 여신 규정집 PDF를 통째로 주는 대신, 플랫폼이 “담보인정비율 상한”, “본인 확인 전 금리 안내 금지”, “고객 데이터는 신청 건 범위만 조회” 같은 규칙을 권한과 한도로 걸어 둡니다. 에이전트가 규칙을 잊어도 플랫폼이 막습니다.

Value First: 가치를 먼저 보여 주면 비용 대화가 ROI 대화로 바뀐다

Patzak은 자신의 일을 혁신과 가치 창출로 정의합니다. 고객이 AI의 가치를 보지 못하면 대화는 얼마가 드느냐에 머뭅니다. 가치 문제를 먼저 풀면 질문이 얼마가 돌아오느냐로 바뀌고 ROI 논의가 훨씬 쉬워진다고 봅니다. 거버넌스 다음으로 가치를 둘째 걱정으로 꼽은 것도 같은 맥락입니다. 실제로 쓰려면 첫 과제를 고를 때 비용 절감 폭보다 경영진이 체감할 성과 지표(처리 시간, 고객 응답 속도)를 먼저 정해 두는 편이 좋습니다.

Three Scopes of Redesign: 결정을 다시 짜는 세 가지 범위

Patzak은 AI로 결정을 다시 짜는 길을 범위에 따라 셋으로 나눕니다. 첫째는 bottom-up digitization(현업이 직접 하는 디지털화)입니다. 문서화가 안 된 업무와 엑셀 시트를 현업 전문가가 AI 도구로 에이전트로 바꿉니다. 그는 이것을 국소 최적화라고 부르면서도, 예전에는 불가능했던 일이라 인상적이라고 말합니다. 둘째는 업무 흐름 하나를 끝까지 보고 에이전틱 AI로 전체를 최적화하는 방식입니다. 셋째는 프로세스를 처음부터 다시 상상하는 방식으로, 독일 대형 은행의 주택담보대출 사례가 여기에 속합니다. 세 범위는 우열이 아니라 쓰는 상황이 다릅니다. 현업 디지털화는 예산 없이 빨리 시작할 수 있고 처음부터 다시 그리는 방식은 고객이 가장 오래 기다리는 핵심 프로세스에 맞습니다.

AI Native: 사람을 최소로 둔 상태에서 설계를 시작한다

AI native라는 말이 남용되고 있다고 짚은 뒤 Patzak은 정의를 짧게 내립니다. AI native 업무 프로세스는 사람의 개입을 가능한 한 줄인 상태에서 출발해 자동화를 최대로 끌어올린 프로세스입니다. 기존 프로세스의 사람 단계를 그대로 두고 일부 작업만 AI로 바꾸면 단계 사이의 대기 시간은 남습니다. 거꾸로 사람이 없는 흐름을 먼저 그리고 꼭 필요한 판단에만 사람을 다시 넣으면, 사람의 역할이 예외 처리와 승인으로 좁혀집니다. 은행 CIO가 “처음부터” 다시 그리라고 한 지시가 이 정의와 맞닿아 있습니다.

Orchestration with Checker Agents: 에이전트가 틀린다는 전제로 역할을 나눈다

Patzak은 에이전트를 하나 만들어 두고 실수하지 않으리라 가정하는 방식은 통하지 않는다고 말합니다. 그래서 두 번째, 세 번째 에이전트를 다른 역할로 두어 첫 에이전트를 점검하게 합니다. 역할을 나누는 또 다른 이유는 context window(모델이 한 번에 읽을 수 있는 분량)의 한계입니다. 특정 역할의 에이전트는 깊은 지식이 필요한데 한 에이전트에 모든 지식을 넣을 수는 없습니다. 전체 흐름은 orchestration agent(조율 에이전트)가 맡습니다. 지금은 이 조율 계층을 회사나 개발자가 개별 소프트웨어 부품으로 직접 조립해야 합니다. Patzak은 곧 제품이 나올 것으로 봅니다. 아직 진화 중인 모범 사례라는 단서도 붙였습니다.

통념과 다른 주장

저자가 든 사례

독일 대형 은행: 50명과 1주 합숙해 주택담보대출을 처음부터

• 상황: 주택담보대출은 은행 업무 가운데 가장 복잡한 축에 듭니다. 고객은 승인 여부와 금리를 바로 알고 싶어 하지만 절차는 며칠에서 몇 주가 걸립니다.
• 한 일: 한 독일 대형 은행의 CIO가 가장 유능한 직원 50명을 사무실 밖 호텔로 1주일 데려갔습니다. 가장 복잡한 업무 프로세스를 고르게 했고 참가자들이 주택담보대출을 골랐습니다. CIO는 이 프로세스를 처음부터 다시 상상하라고 지시했습니다(“Reimagine this business process from scratch”).
• 결과: 재설계 결과와 줄어든 처리 기간은 원문에서 밝히지 않았습니다.
• 연결: Three Scopes of Redesign의 셋째 범위, AI Native.

리스 부서와 자동차 공장: 현업 전문가가 만든 에이전트를 200명이 쓴다

• 상황: 리스 부서와 자동차 공장에는 문서화가 덜 된 업무와 엑셀 시트가 많았습니다. 왜 진작 바꾸지 않았느냐고 묻자 예산이 없었다는 답이 돌아왔습니다. 예산 신청 절차가 복잡하고 오래 걸린다는 것입니다.
• 한 일: 리스 부서의 현업 전문가와 공장의 현업 전문가가 각자 AI 도구로 에이전트를 만들었습니다.
• 결과: 그중 한 에이전트는 동료 200명이 씁니다. 처리 시간 같은 효과 수치는 원문에서 밝히지 않았습니다.
• 연결: Three Scopes of Redesign의 첫째 범위(bottom-up digitization), Governance as Infrastructure(현업이 만든 에이전트도 같은 경계 안에서 돌아야 함).

독일 자동차 업계: 비용 압박이 업무 재설계를 밀어붙인다

• 상황: 독일 자동차 회사들은 높은 비용 압박과 중국 업체와의 경쟁을 동시에 겪고 있습니다.
• 한 일: 직원용 챗봇에 그치지 않고 업무 프로세스를 다시 짜는 데 AI를 쓰려고 합니다. AI 거버넌스 자체도 개선해야 할 업무 프로세스로 다루기 시작했습니다.
• 결과: 개별 회사명과 수치는 원문에서 밝히지 않았습니다. Patzak은 제조·자동차·금융을 고객을 위한 거버넌스 구축이 가장 앞선 업종으로 꼽았습니다.
• 연결: Governance as Infrastructure, Three Scopes of Redesign의 둘째 범위.

기술 디테일: 거버넌스를 플랫폼에 넣고 점검 에이전트를 붙이려면

아래 필드명, 설정값, 기준은 실행을 위한 가상 예시이며 원문이 밝힌 구현이 아닙니다. 원문의 권고(플랫폼에 경계, 점검 에이전트, 조율 에이전트)를 실제로 돌릴 때 필요한 것을 정리했습니다.

정책 문서를 규칙으로 옮기려면(Governance as Infrastructure) 문서를 통째로 프롬프트에 넣지 않고 조항 단위로 쪼개 규칙 목록을 만듭니다. LLM에게 조항 하나씩 주고 “에이전트가 지켜야 할 규칙인가, 그렇다면 어디에서 막을 수 있나”를 구조화 출력으로 받게 합니다. 같은 조항을 3회 추출해(temperature 0~0.2) 세 번 모두 같은 규칙이 나온 것만 후보로 올리고 나머지는 준법 담당자가 직접 읽습니다. 규칙마다 막는 위치를 정합니다. 데이터 범위는 조회 권한으로, 금액·비율 한도는 도구 호출 전 검사로, 절차 순서는 조율 에이전트의 상태 전이로 막습니다. 문맥으로만 줄 수 있는 규칙은 따로 표시해 점검 에이전트의 확인 목록에 넣습니다.

{
  "rule_id": "MTG-LTV-001",
  "source": {"doc": "여신 규정", "clause": "4.2", "version": "2026-09"},
  "statement": "담보인정비율이 상한을 넘는 한도 초안은 자동 통과 금지",
  "enforce_at": "tool_precheck",
  "applies_to": ["mortgage-draft-agent"],
  "on_violation": "route_to_underwriter",
  "owner": "여신정책팀",
  "log_fields": ["application_id", "ltv", "limit", "agent_version"]
}

점검 에이전트를 붙이려면(Orchestration with Checker Agents) 실행 에이전트와 점검 에이전트에 서로 다른 문맥을 줍니다. 실행 에이전트는 업무 지식과 입력 서류를, 점검 에이전트 1은 위 규칙 목록만, 점검 에이전트 2는 원본 수치와 근거 문서만 받습니다. 가능하면 점검 에이전트는 실행 에이전트와 다른 모델을 써서 같은 실수를 반복할 확률을 낮춥니다. 점검 결과는 pass, reject, hold 세 값과 근거 규칙 ID로만 받습니다. 조율 에이전트는 상태(접수, 초안, 점검 1, 점검 2, 판정)를 저장합니다. 반려되면 실행 에이전트에게 사유와 함께 최대 2회 되돌리고 그래도 실패하면 사람에게 넘깁니다. 운영 전에는 결과를 아는 과거 신청 50건으로 평가 세트를 만들어 같은 입력을 3회씩 돌립니다. 그리고 판정이 회차마다 엇갈리는 건의 비율과 점검 에이전트의 반려 정확도를 함께 봅니다.

막히는 경우	증상	대응
규칙이 문서에만 있음	에이전트가 같은 규정을 건마다 다르게 해석	조항을 규칙 ID로 쪼개고 막는 위치를 지정
점검 에이전트가 늘 통과시킴	반려율 0%가 몇 주 지속	일부러 틀린 초안 20건을 섞어 잡아내는지 시험
역할마다 문맥이 넘침	긴 규정집에서 답이 흔들림	역할별로 필요한 규칙만 검색해 상위 5~8건만 넣음
현업이 만든 에이전트가 경계 밖에서 돎	개인 계정·개인 파일로 운영	플랫폼 등록을 사용 조건으로 두고 권한을 플랫폼에서만 발급
조율 계층을 직접 조립한 부품이 늘어남	흐름마다 재시도·로그 방식이 다름	상태 저장, 재시도, 로그 형식을 공통 부품으로 먼저 정함

현업 실행 디테일: 누가, 언제, 무엇을

원문은 CIO가 핵심 인력 50명을 1주 동안 데려가 가장 복잡한 프로세스를 다시 그리게 했다고 밝혔습니다. 아래 역할, 일정, 질문, 판정 기준은 이 형식을 따라 새로 짠 가상 예시입니다.

역할	맡는 일
CIO 또는 사업부장(스폰서)	대상 프로세스 확정, 합숙 인력 차출, 최종 판정
현업 실무자(심사·상담·운영)	현행 흐름과 예외 사례 설명, 고객이 기다리는 지점 찾기
준법·리스크 담당	에이전트가 지켜야 할 규칙 목록, 사람이 남아야 할 판단 지정
데이터·IT 아키텍트	데이터 출처와 권한 구조, 플랫폼 경계 설계
AI 엔지니어	실행·점검·조율 에이전트 구성안, 시범 범위 산정
고객 접점 담당	고객이 원하는 답의 시점(즉시 답, 당일 답) 정의

준비물. 대상 프로세스의 현행 절차서와 결재 기준, 최근 3개월 처리 건수와 단계별 소요 시간, 반려·재작업 사례 20건, 관련 규정 문서 목록, 현업이 이미 엑셀이나 개인 도구로 돌리는 우회 업무 목록이 필요합니다.

기간	할 일	산출물
합숙 전 2주	대상 후보 3개 비교, 처리 시간 기준선 측정, 규정 문서 수집	후보 비교표, 기준선, 규정 목록
합숙 1주	현행 흐름 → 고객 순간 → 사람 최소 흐름 → 경계·점검 설계 → 시범 계획	AI native 흐름도, 규칙 목록 초안, 시범 계획서
합숙 뒤 4~6주	한 상품·한 채널로 시범, 사람 심사와 병행 비교	처리 시간, 점검 에이전트 반려율, 사람 수정률
7주	판정 회의	확대·보완·중단 결정서

현업에 물을 것.

1. 고객이 가장 오래 기다리는 단계는 어디이고 그 시간에 실제로 일하는 사람은 누구인가요?
2. 사람이 없다고 가정했을 때 반드시 남아야 하는 판단은 무엇이고 그 근거 규정은 어디에 있나요?
3. 지금 엑셀이나 개인 도구로 우회하는 업무 가운데 동료 여러 명이 함께 쓰는 것은 무엇인가요?
4. 규정 가운데 해석이 사람마다 다른 조항은 어느 것인가요?
5. 에이전트가 틀렸을 때 누가 알아채고 지금은 그런 오류를 어떻게 잡고 있나요?

진행 판정 기준(예시). 병행 시범에서 세 조건을 모두 채우면 다음 상품으로 넓힙니다. 단계별 대기 시간이 기준선보다 50% 이상 줄어야 하고 점검 에이전트가 일부러 넣은 오류 사례의 90% 이상을 잡아야 하며 사람 심사역의 수정률이 20% 이하여야 합니다. 수정률이 20~40%면 규칙 목록과 문맥을 보강해 4주 더 봅니다. 그보다 높으면 프로세스 설계부터 다시 봅니다. 어느 경우에도 원래 사람이 맡던 최종 승인 권한은 판정 회의 전까지 바꾸지 않습니다.

AX 적용 제언. 이 인터뷰는 에이전트 확산의 순서를 바꾸게 합니다. 많은 회사가 에이전트를 먼저 만들고 거버넌스를 뒤에 붙입니다. 이 순서로는 부서마다 생긴 에이전트를 나중에 통제하기 어렵습니다. 먼저 준법·리스크 부서와 함께 핵심 규정을 규칙 목록으로 바꾸고 이를 플랫폼 경계로 심어 둔 뒤, 그 위에서 현업 디지털화를 허용하는 편이 빠릅니다. 이미 규정이 잘 정리된 금융·보험이 첫 대상으로 좋고 제조는 품질·안전 기준서가 같은 역할을 합니다. 프로세스를 처음부터 다시 그리는 합숙은 고객이 가장 오래 기다리는 프로세스 하나에만 씁니다. 스폰서는 CIO 혼자가 아니라 그 프로세스를 가진 사업부장과 함께 서는 구조가 좋습니다.

원문 사례

항목	내용
원문	TechTarget, 2026.11.4, Q&A 형식, 보스턴 AWS 미디어 행사에서 진행
기자·화자	Esther Shittu(TechTarget AI 담당 기자), Matthias Patzak(AWS executive in residence)
바탕 자료	AWS 리포트 「Reimagine: Turning AI into Value」(9월 발간)
고객 걱정	1위 거버넌스와 책임 있는 AI 사용, 2위 가치 부족, 조직에 따라 비용·확산
거버넌스	모호한 규칙의 조직은 에이전트 통제가 어려움, 플랫폼을 인프라로 삼아 경계를 둠
앞선 업종	금융(문서화된 거버넌스), 제조·자동차(고객용 거버넌스 구축)
독일 자동차	높은 비용 압박과 중국 경쟁, 업무 재설계에 AI, 거버넌스도 개선 대상 업무로 다룸
결정 재설계	현업 디지털화(엑셀 대체), 프로세스 전체 최적화, 처음부터 다시 상상
사례	리스 부서·자동차 공장 현업 전문가의 에이전트, 그중 하나를 동료 200명이 사용
사례	독일 대형 은행 CIO, 핵심 인력 50명과 호텔에서 1주, 주택담보대출을 처음부터 재설계
AI native	사람 최소에서 출발해 자동화를 최대로
오케스트레이션	점검 역할의 두 번째·세 번째 에이전트, 조율 에이전트, 현재는 직접 조립, 곧 제품 등장 전망

핵심 개념

Executive in residence

기업이 현장 경험이 많은 전직 임원을 상주시켜 고객 자문을 맡기는 직책입니다. Patzak은 고객 입장에서 같은 문제를 풀어 본 경험으로 자문합니다.

Responsible AI

AI가 공정하고 안전하며 설명 가능하게 쓰이도록 원칙과 통제를 두는 일입니다.

Agentic AI

지시에 답하는 데 그치지 않고 도구를 부르며 여러 단계를 스스로 진행하는 AI입니다.

Context window

모델이 한 번 호출에서 읽고 고려할 수 있는 입력 분량의 상한입니다.

Local optimization

업무 흐름 전체가 아니라 한 팀이나 한 단계만 빠르게 만드는 개선입니다.

Policy as code

규정을 사람이 읽는 문서가 아니라 시스템이 실행 시점에 검사하는 규칙으로 적어 두는 방식입니다. 기술 디테일의 규칙 JSON이 이 형태입니다.

내 메모

TODO: 내 생각 추가

원문은 TechTarget의 「AWS goes inside the enterprise to find the real value of AI」(Esther Shittu, 2026.11.4)로, AWS Matthias Patzak과의 Q&A입니다. 요약, 핵심 메커니즘의 원문 설명, 통념과 다른 주장, 사례, 원문 사례 표는 원문 내용을 AX Review가 다시 정리했습니다. 은행 재설계의 결과와 에이전트의 효과 수치는 원문에 없어 싣지 않았습니다. 핵심 개념 가운데 Responsible AI, Agentic AI, Local optimization, Policy as code의 뜻풀이는 일반적인 정의로 보탰습니다. 대출 규칙 예시, 규칙 JSON, 점검 에이전트 구성, 막히는 경우 표, 역할·일정·질문·판정 기준, 인포그래픽은 원문에 없는 내용으로 새로 작성했고 그 안의 필드명과 숫자는 가상 예시입니다. 인터뷰 전문은 원문 페이지에서 볼 수 있습니다.