ASUG Tech Connect: Agilent 관세 에이전트와 SAP 고객의 에이전트 운영 규칙
SAP 사용자 단체 ASUG 행사에서 Agilent는 외부 관세 데이터를 사내 제품 카탈로그와 실시간으로 대조하는 에이전트를 소개했고 현업은 이 도구 없이 일하기 어렵다고 했습니다. 거버넌스 세션은 LeanIX 에이전트 등록부, 범위가 바뀌면 재승인하는 배포 명세서, 시스템 카드, 저위험 작업에만 둔 완전 자율과 감사 로그를 운영 규칙으로 제시했습니다.
SAP 고객들이 내놓은 답은 두 갈래입니다. 가치 있는 에이전트는 Agilent의 관세 에이전트처럼 사내 기준 데이터 밖의 정보를 실시간으로 끌어와 맞춰 봅니다. 그만큼 위험도 커지므로 에이전트마다 등록부, 배포 명세서, 시스템 카드, 감사 로그를 붙여 관리합니다. 따라 하려면 규칙으로 충분한 일은 규칙 기반 자동화에 맡기고 가장 위험한 에이전트 하나부터 이 틀에 넣어 봐야 합니다.
요약
diginomica의 Jon Reed가 2026년 11월 5일 SAP 사용자 단체 ASUG의 Tech Connect 행사를 고객 쪽에서 정리했습니다. Tech Connect는 SAP TechEd와 함께 열리는 행사로, SAP 리더와 엔터프라이즈 아키텍트 같은 실무자가 모입니다. 저자는 벤더의 AI 발표보다 고객 세션과 커뮤니티 피드백에 무게를 둡니다. 눈에 띈 고객 사례는 Agilent의 관세 에이전트입니다. 이 에이전트는 외부 관세 데이터를 실시간으로 받아 사내 제품 카탈로그와 바로 대조합니다. 쓰는 현업은 이제 이 도구 없이 일하기 어렵다고 했습니다. Hershey’s의 clean core(표준 코어를 깨끗하게 유지하는 방식)·RISE 전환 세션은 행사에서 가장 붐볐고 AI 준비도를 위해 SAP Business Data Cloud(BDC)를 써 본 경험을 나눴습니다. 거버넌스 쪽에서는 SAP의 Srinivas Nandiwada가 진행한 「Guardrails for Genius」 세션이 실무 틀을 내놓았습니다.
저자는 Gartner 조사로 출발합니다. AI에서 의미 있는 가치를 봤다는 CIO는 13%뿐이고 2025년에는 생성형 AI 과제 절반 이상이 PoC 뒤에 멈췄습니다. 저자는 지금을 전환점으로 봅니다. 데이터 문맥과 에이전트 harness(에이전트를 감싸는 실행·통제 틀) 같은 guardrail을 갖추면 에이전트를 핵심 업무 깊숙이 넣을 수 있게 됐다는 것입니다. 대신 위험이 커지고 에이전트에게 얼마나 자율을 줄지 정해야 합니다. 그래서 고객들은 보안과 거버넌스를 막는 장치가 아니라 이 단계로 가는 조건으로 다뤘습니다. 저자의 결론은 AI first가 아니라 business first입니다. 규칙 기반 자동화로 충분한 일에는 AI를 쓰지 않고 벤더가 문맥과 틀을 대더라도 AI 전략과 데이터의 주인은 고객이라는 것입니다. 아래에서 다섯 가지 작동 원리, 원문이 든 사례, 실제로 돌릴 때 필요한 기술·현업 디테일을 차례로 봅니다.
핵심 메커니즘
Beyond System of Record: 사내 기준 데이터 밖의 정보와 실시간으로 맞춰 본다
에이전트의 가치는 ERP 같은 system of record(업무 기준 데이터를 보관하는 시스템)만 읽을 때보다, 바깥 정보와 사내 데이터를 이어 붙일 때 커집니다. 작동 방식은 단순합니다. 에이전트가 외부 원천에서 바뀐 정보를 실시간으로 가져오고 사내 기준 데이터와 맞춰 영향을 받는 대상을 찾아 사람에게 보여 줍니다. Agilent의 관세 에이전트는 외부 관세 데이터를 받아 사내 제품 카탈로그와 실시간으로 대조합니다. 쓰는 사람들은 이제 이 도구 없이 일하기 어렵다고 했고 저자는 이런 반응을 가치의 증거로 봅니다. 그러면서도 “even if agentic costs still require monitoring”이라고 단서를 붙입니다. 외부 정보가 자주 바뀌고 사내 마스터와 연결해야 의미가 생기는 일(관세, 제재 명단, 원자재 시세)에 맞습니다. 사내 데이터만으로 답이 나오는 조회에는 에이전트를 둘 이유가 작습니다. 작은 예시(가상): 한 나라가 특정 품목의 세율을 올리면 에이전트가 해당 품목 코드를 쓰는 제품 목록과 원산지를 찾아 무역 담당자에게 넘깁니다.
Layered Governance: 만들 때부터 통제하고 층마다 위로 올리는 길을 둔다
Nandiwada는 에이전트 거버넌스를 여러 층으로 설명했습니다. 층마다 다음 층으로 올리는 에스컬레이션 경로가 있고 각 층은 EU AI Act 같은 현행 규제와 연결됩니다. 핵심은 순서입니다. 통제를 배포 뒤가 아니라 만드는 단계부터 겁니다. 운영에 들어간 뒤에는 에이전트마다 모니터링 틀을 둡니다. 저자는 이렇게 하는 조직이 아직 소수라고 짚습니다. 프라이버시도 같은 층에서 다룹니다. 에이전트로 들어오고 나가는 모든 데이터 흐름을 프라이버시 노출면으로 봅니다. 마지막으로 오늘의 규제에만 맞춘 틀이 아니라 새 규제가 나와도 흡수할 수 있는 절차를 만들라고 권했습니다. 저자는 여기에 하나를 더 바랐습니다. Joule Studio 같은 에이전트 빌드 환경 안에서, 만드는 사람에게 지금 부르는 기능의 위험 수준을 바로 알려 주는 능동 통제입니다. 층의 개수와 이름은 원문에서 밝히지 않았습니다.
Agent Registry, Deployment Manifest, System Card: 에이전트마다 신분증과 허가증을 붙인다
세 문서가 짝을 이룹니다. Agent registry(에이전트 등록부)는 회사에 어떤 에이전트가 있는지 적은 살아 있는 목록입니다. 세션은 SAP LeanIX(기업 아키텍처 관리 도구)에 등록부를 두라고 권했고 한 고객은 아직 내가 통제하지 못하는 부서의 에이전트까지 목록에 올리라고 덧붙였습니다. Deployment manifest(배포 명세서)는 에이전트가 무엇을 해도 되는지 적은 허가증입니다. 에이전트의 범위는 재승인 없이 바뀔 수 없습니다. System card(시스템 카드)는 에이전트마다 위험 노출 영역과 범위를 정의한 문서입니다. 세 문서를 모두 갖추면 “누가 만든 무엇이, 어디까지 해도 되고 무엇이 위험한가”에 문서로 답할 수 있습니다. 에이전트가 두세 개일 때는 번거로워 보여도, 부서마다 따로 만들기 시작하면 등록부가 없는 조직은 무엇이 돌고 있는지 모르게 됩니다.
Autonomy by Risk와 Audit Log: 완전 자율은 좁게, 기록은 전부
세션의 마지막 권고가 가장 논쟁적이었다고 저자는 적습니다. 완전 자율 에이전트는 위험이 낮고 경계가 분명한 작업에만 두고 사람에게 영향을 주는 결정에는 쓰지 않습니다. 그리고 에이전트가 한 모든 행동을 감사 로그로 남깁니다. 저자는 이 권고가 EU AI Act와 같은 방향이라고 봅니다. 순서도 정했습니다. 가장 위험한 에이전트를 먼저 이 틀에 통과시킵니다. 쉬운 에이전트로 틀을 시험하면 정작 위험한 곳에서 틀이 버티는지 알 수 없기 때문입니다. 한 고객은 동료들에게 에이전트 보안을 객관적으로 보여 주려면 감사(audit)를 돌리라고 했습니다. 작은 예시(가상): 관세 에이전트가 영향 품목 목록을 만드는 일은 자율로 돌려도 되지만 고객 가격을 바꾸는 일은 사람이 승인합니다. 두 경우 모두 로그는 남습니다.
Right-sized AI: 규칙으로 충분하면 규칙 기반 자동화를 쓴다
smartShift의 제품 담당 부사장 Christopher Hanshew는 SAP 전환 때 골칫거리인 커스텀 코드 정리를 자동화하는 발표에서 자동화 플랫폼을 AI 수준별로 나눈 그래픽을 보여 줬습니다. 저자는 이를 근거로 결정론적인 규칙 기반 기술이 AI보다 싸고 안정적이라고 정리합니다. 원칙은 과제마다 필요한 수준까지만 AI를 쓰는 것입니다. 입력이 같으면 결과가 같아야 하는 변환, 조건이 문서로 정리된 판정은 규칙이 맡고 해석이나 예외 판단이 필요한 구간에만 모델을 부릅니다. 저자는 이렇게 하는 파트너가 자기 추론 비용을 낮추고 그 투명성 덕분에 고객도 AI 결정을 더 잘 내린다고 봅니다. 그래픽의 단계 이름은 원문 본문에 나오지 않아 옮기지 않았습니다.
SAP Context Strategy: 벤더는 문맥을 대고 전략과 데이터는 고객이 쥔다
저자는 SAP의 문맥 전략을 벤더 가운데 가장 야심 찬 편으로 평가합니다. SAP Company Memory, 표 데이터용 기반 모델 SAP-RPT-2, Knowledge Graph, 그리고 고객 고유 온톨로지로 SAP Knowledge Graph를 넓히는 BDC Ontology Manager가 Joule 에이전트의 추론에 들어갑니다. 저자는 이 구성이 범용 LLM 에이전트보다 나은 결과를 낼 것으로 보고 SAP가 이를 입증할 자료를 모으고 있다고 전합니다. 그래도 고객이 자기 전략과 데이터를 소유해야 한다는 선은 분명히 긋습니다. RISE(SAP 운영 대행 private cloud)에서는 고객이 AI 서비스를 세밀하게 통제하려는 요구와 SAP의 인프라 관리가 부딪친다는 고객 발언도 있었습니다. 일부 고객은 지금 Claude를 쓰면서 앞으로 도입할지를 보려고 Joule 에이전트와 비교 평가하고 있었습니다. 저자는 둘의 성능을 판정하지 않았습니다.
통념과 다른 주장
흔히 이렇게 봅니다보안과 거버넌스는 에이전트 도입 속도를 늦추는 관문이고 규제를 받는 회사만 제대로 챙기면 된다.
저자는 이렇게 봅니다보안과 거버넌스는 막는 장치가 아니라 에이전트를 핵심 업무로 넣게 해 주는 조건입니다. 규제 대상이 아니어도 다른 신규 규제나 지금의 책임 노출로 필요성을 설명할 수 있습니다.
근거기조연설의 주제가 아니었는데도 보안·거버넌스·AI 윤리 세션에 사람이 몰렸고 커뮤니티 피드백에서 고객이 거듭 꺼냈습니다. EU AI Act 대상이 아니라 보안 투자 동의를 못 얻던 고객에게 저자는 책임 노출을 근거로 삼으라고 답했습니다.
흔히 이렇게 봅니다AX는 AI first여야 하고 자동화할 수 있는 곳에는 가장 강한 AI를 넣는 편이 낫다.
저자는 이렇게 봅니다AI first가 아니라 business first입니다. 결정론적 규칙으로 충분한 곳은 규칙 기반 자동화가 더 싸고 안정적이므로, 과제마다 필요한 수준까지만 AI를 씁니다.
근거smartShift의 AI 수준별 자동화 그래픽과, 생성형 AI 과제 절반 이상이 PoC 뒤 멈췄다는 Gartner 수치를 듭니다. 저자는 결과가 데이터, 프로세스, 거버넌스, 사람의 역량에 달려 있고 지름길은 없다고 봅니다.
저자가 든 사례
Agilent 관세 에이전트: 외부 데이터와 사내 카탈로그를 실시간으로 잇다
| 항목 | 내용 |
|---|---|
| 상황 | 관세 정보는 회사 밖에서 바뀌고 영향은 사내 제품 단위로 확인해야 함 |
| 한 일 | 외부 관세 데이터를 실시간으로 받아 사내 제품 카탈로그와 실시간 대조하는 에이전트를 운영 |
| 결과 | 접근 권한이 있는 현업이 이 도구 없이 일하기 어렵다고 평가. 정량 효과, 사용 모델·도구, 발표자 직함은 원문에서 밝히지 않음 |
| 연결 | Beyond System of Record. 저자는 비용 관찰이 계속 필요하다고 덧붙임 |
거버넌스 세션의 고객들: 목록화, 감사, 설득 논리
| 항목 | 내용 |
|---|---|
| 상황 | 보안·거버넌스·AI 윤리 세션이 붐볐고 고객들이 실무 질문을 냄 |
| 한 일 | 한 고객은 LeanIX로 통제 밖 부서 에이전트까지 목록화하라고 권함. 다른 고객은 에이전트 보안 감사로 동료에게 객관적 근거를 주라고 함 |
| 결과 | EU AI Act 대상이 아닌 고객은 보안 투자 동의를 얻기 어려웠고 저자는 다른 신규 규제나 현재 책임 노출로 설득하라고 제안 |
| 연결 | Agent Registry, Autonomy by Risk와 Audit Log |
smartShift 커스텀 코드 정리: 규칙으로 되는 구간은 규칙으로
| 항목 | 내용 |
|---|---|
| 상황 | SAP 전환 때 커스텀 코드 정리는 흔한 골칫거리 |
| 한 일 | smartShift가 AI 수준을 나눈 자동화 플랫폼으로 이 작업을 자동화 |
| 결과 | 저자는 결정론적 규칙 기반 기술이 더 싸고 안정적이라고 정리. 정량 효과는 원문에서 밝히지 않음 |
| 연결 | Right-sized AI |
기술 디테일: 등록부와 감사 로그를 실제로 돌리려면
Agilent식 대조 에이전트를 만들려면(Beyond System of Record) 대조 자체는 결정론적 조인으로 두고 모델은 매핑이 안 되는 품목 설명을 해석할 때만 부릅니다. 외부 관세 피드는 출처 URL과 확인 시각을 함께 저장해야 나중에 어느 시점 데이터로 판단했는지 보여 줄 수 있습니다. 출력은 사람이 바로 검토할 수 있게 구조화합니다. 아래 필드는 실제로 돌릴 때의 가상 예시입니다.
{
"change_id": "TAR-2026-1107-014",
"source": {"url": "<관세 고시 주소>", "fetched_at": "2026-11-07T09:12:00+09:00"},
"tariff": {"hs_code": "9027.80", "country": "XX", "old_rate": 0.0, "new_rate": 10.0, "effective": "2026-12-01"},
"affected_items": [{"material_id": "M-10432", "origin": "XX", "match": "exact"}],
"unmatched_descriptions": 3,
"llm_used": true,
"needs_human_review": true
}
match가 exact가 아니거나 unmatched_descriptions가 0보다 크면 사람 검토로 보냅니다. 모델이 매핑을 제안할 때는 temperature 0으로 같은 입력을 3회 돌려 답이 갈리면 자동 확정하지 않습니다. 에이전트별 호출 수와 건당 비용을 주 단위로 모으면, 저자가 말한 비용 관찰을 숫자로 할 수 있습니다.
배포 명세서와 재승인을 자동으로 걸려면(Deployment Manifest) 명세서를 코드 저장소에 두고 배포 파이프라인이 승인본과 비교하게 합니다. 범위 필드가 하나라도 바뀌면 배포를 멈추고 재승인을 요청합니다. 가상 예시 필드는 다음과 같습니다.
{
"agent_id": "tariff-matcher",
"owner": "무역관리팀",
"registry_ref": "LeanIX:<팩트시트 ID>",
"scope": {"systems": ["제품 카탈로그(읽기)"], "actions": ["목록 생성"], "write_access": false},
"data_flows": [{"in": "외부 관세 피드"}, {"out": "무역 담당자 알림"}],
"autonomy": "full",
"risk_tier": "low",
"affects_people": false,
"system_card": "cards/tariff-matcher-v3.md",
"approved_by": ["업무 오너", "보안"],
"version": "3"
}
시스템 카드에 넣을 항목(System Card) 목적, 범위, 연결 시스템, 들어오고 나가는 데이터와 개인정보 포함 여부, 알려진 실패 유형, 위험 노출 영역, 사람 개입 지점, 모니터링 지표, 마지막 검토일을 한 쪽에 적습니다. 원문은 위험 노출 영역과 범위를 정의하라고만 했으므로 나머지 항목은 실제로 돌릴 때의 제안입니다.
자율 수준과 감사 로그를 연결하려면(Autonomy by Risk와 Audit Log) 자율 수준을 몇 단계로 나누고 명세서의 autonomy 값과 맞춥니다. 아래 표는 가상 예시입니다.
| 수준 | 에이전트가 하는 일 | 사람 | 조건 |
|---|---|---|---|
| L0 | 정보 조회·요약 | 결과를 보고 판단 | 제한 없음 |
| L1 | 초안·목록 생성 | 승인 후 반영 | 쓰기 권한 없음 |
| L2 | 시스템에 반영 | 사후 표본 검토 | 저위험, 사람 영향 없음, 되돌릴 수 있음 |
| L3 | 연쇄 실행까지 완전 자율 | 예외만 처리 | 저위험·경계 있음, 사람 영향 없음, 최고위험 에이전트 검증을 마친 틀 |
감사 로그는 행동마다 한 줄씩 남깁니다. 시각, agent_id, 명세서 version, 호출한 도구, 입력·출력 참조, 결과, 사람 승인자(있으면)를 넣습니다. 명세서 버전이 로그에 있어야 범위가 바뀐 뒤의 행동만 골라 볼 수 있습니다. 로그는 에이전트가 고칠 수 없는 저장소에 둡니다.
규칙과 AI를 나누려면(Right-sized AI) 과제를 단계로 쪼갠 뒤 단계마다 묻습니다. 입력이 같으면 결과가 같아야 하는가, 조건이 문서로 정리돼 있는가. 둘 다 예면 규칙으로 만들고 AI 호출을 뺍니다. 해석이 필요한 단계만 모델을 부르고 그 단계의 비용과 오류율을 따로 잽니다.
Joule과 다른 모델을 비교하려면(SAP Context Strategy) 같은 업무 질문 30~50건과 정답을 준비해 두 후보에 똑같이 돌리고 정확도, 근거 제시, 건당 비용, 응답 시간을 봅니다(가상 예시). SAP 데이터 문맥이 필요한 질문과 일반 질문을 나눠 보면 문맥 계층의 효과가 드러납니다.
현업 실행 디테일: 누가, 언제, 무엇을
| 역할 | 맡는 일 |
|---|---|
| AX 추진 리더 | 등록부 운영 책임, 최고위험 에이전트 선정, 4주 판정 |
| 엔터프라이즈 아키텍트 | LeanIX에 에이전트 팩트시트 등록, 연결 시스템 표시 |
| CISO·보안 담당 | 시스템 카드 검토, 자율 수준 승인, 감사 실행 |
| 법무·개인정보 담당 | 데이터 흐름별 개인정보 검토, 적용 규제 목록 |
| 업무 오너(예: 무역관리팀) | 범위 정의, 사람 개입 지점 결정, 결과 검토 |
| 내부 감사 | 로그 표본 점검, 재승인 이력 확인 |
시작 전 준비물은 부서별로 이미 쓰고 있는 에이전트·자동화 목록(통제 밖 것 포함), 에이전트가 닿는 시스템과 권한 목록, 적용 가능한 규제 목록입니다.
| 기간 | 할 일 | 산출물 |
|---|---|---|
| 1주 | 부서별 설문과 IT 로그로 에이전트를 찾아 등록부에 올림 | LeanIX 등록부 초안, 오너 지정 |
| 2주 | 위험이 가장 큰 에이전트 하나의 명세서와 시스템 카드 작성 | 명세서 v1, 시스템 카드 v1, 자율 수준 결정 |
| 3주 | 그 에이전트에 감사 로그와 재승인 게이트 연결 | 로그 대시보드, 배포 파이프라인 점검 결과 |
| 4주 | 운영 결과를 보고 다음 대상 선정 | 판정 메모, 다음 3개 에이전트 목록 |
부서 인터뷰에서는 이렇게 묻습니다. 지금 쓰는 에이전트나 자동화는 무엇이고 누가 만들었나. 그 에이전트가 쓰기 권한을 가진 시스템은 어디인가. 결과가 사람(직원, 고객, 협력사)에게 영향을 주나. 지난달에 범위가 바뀐 적이 있나, 그때 누가 승인했나. 같은 일을 규칙으로 처리할 수는 없나.
진행 판정 기준(가상 예시)은 네 가지입니다. 등록부에 오너가 없는 에이전트가 0개일 것, 최고위험 에이전트의 행동 100%가 로그에 남을 것, 명세서 변경이 재승인 없이 배포된 건이 0건일 것, 사람에게 영향을 주는 결정을 자율로 처리한 에이전트가 0개일 것. 넷을 넘으면 다음 3개 에이전트로 넓힙니다.
AX 적용 제언: SAP를 쓰는 제조·유통 고객이라면 관세·제재·원자재처럼 외부 변동을 사내 마스터에 대조하는 과제를 첫 에이전트 후보로 잡기 좋습니다. 효과가 현업 반응으로 바로 보이고 쓰기 권한 없이 목록만 만들게 하면 자율 수준을 높게 둬도 위험이 작습니다. 거버넌스는 별도 과제로 미루지 말고 첫 에이전트와 함께 등록부, 명세서, 로그를 붙여 시작합니다. 이미 LeanIX를 쓰는 회사는 새 도구 없이 등록부를 만들 수 있습니다. 규칙으로 충분한 단계를 걸러 내는 작업은 비용 논의 때 CFO를 설득하는 근거가 됩니다.
원문 사례
| 항목 | 내용 |
|---|---|
| 원문 | diginomica, Jon Reed, 2026.11.5 게재 |
| 행사 | ASUG Tech Connect 2026, SAP TechEd 동반 행사. 날짜와 장소는 원문에서 밝히지 않음 |
| 인용 수치 | Gartner: 의미 있는·혁신적 AI 가치를 보고한 CIO 13%, 2025년 생성형 AI 과제 절반 이상 PoC 뒤 포기 |
| 고객 사례 | Agilent 관세 에이전트, Hershey’s clean core·RISE 전환(BDC 경험), Bristol Myers Squibb 팀 발표(세부 없음), ECC 고객의 현대화·보안 고민 |
| 거버넌스 세션 | Srinivas Nandiwada(SAP), 「Guardrails for Genius」 |
| 권고 | 빌드 단계 통제, 에이전트별 운영 모니터링, LeanIX 등록부, 배포 명세서와 범위 변경 시 재승인, 시스템 카드, 데이터 흐름 = 프라이버시 노출면, 새 규제 흡수, 최고위험 에이전트부터, 완전 자율은 저위험·경계 있는 작업만, 사람 영향 결정 금지, 전체 행동 감사 로그 |
| SAP 문맥 자산 | SAP Company Memory, SAP-RPT-2, Knowledge Graph, BDC Ontology Manager, Joule |
| 파트너 | smartShift(Christopher Hanshew, 커스텀 코드 정리 자동화), Basis Technologies(변화·AI 패널), SAP 가치 자문(Todd Hassell, IT와 현업 정렬) |
| 기타 | 일부 고객이 Claude와 Joule 에이전트를 비교 평가 중, RISE에서 AI 서비스 통제와 인프라 관리 사이 긴장 |
| 저자 결론 | business first, 지름길 없음, 고객이 AI 전략·데이터 소유, ECC 고객에게 더 분명한 길 필요 |
| 고지 | ASUG와 SAP는 diginomica의 프리미어 파트너이며 ASUG가 저자 참가 경비 대부분을 부담 |
핵심 개념
- ASUG
- Americas' SAP Users' Group. 미주 지역 SAP 고객이 모인 사용자 단체입니다.
- ECC
- SAP ERP Central Component. S/4HANA 이전 세대의 SAP ERP로, 많은 고객이 아직 이 위에서 운영합니다.
- RISE with SAP
- SAP가 클라우드 인프라와 운영을 묶어 제공하는 전환 계약 방식입니다. 이 노트에서는 private cloud 형태를 말합니다.
- Clean core
- ERP 표준 코어에 직접 수정한 코드를 두지 않고 확장 기능을 바깥에 두어 업그레이드를 쉽게 하는 방식입니다.
- SAP Business Data Cloud
- SAP 업무 데이터와 외부 데이터를 업무 의미와 함께 모아 분석과 AI에 쓰게 하는 데이터 서비스입니다.
- SAP LeanIX
- 애플리케이션과 시스템 구성을 목록으로 관리하는 기업 아키텍처 도구입니다.
- Joule Studio
- SAP의 AI 비서 Joule 위에서 돌아갈 에이전트와 기능을 만드는 빌드 환경입니다.
- EU AI Act
- AI 시스템을 위험 수준별로 나눠 의무를 매기는 EU 법입니다.
내 메모
TODO: 내 생각 추가
원문은 diginomica의 「The ASUG Tech Connect review - vendors had their AI moment. Now SAP customers have their say.」(Jon Reed, 2026.11.5)입니다. 요약, 핵심 메커니즘의 원문 설명, 통념과 다른 주장, 사례, 원문 사례 표는 원문 내용을 AX Review가 다시 정리했습니다. Agilent 사례의 정량 효과와 사용 도구는 원문에 없습니다. ASUG, ECC, RISE, clean core, BDC, LeanIX, Joule Studio, EU AI Act의 뜻풀이와 system of record·harness 풀이는 일반적인 정의로 보탰습니다. JSON 예시, 자율 수준 표, 시스템 카드 항목, 재승인 흐름, 비교 평가 방법, 역할·일정·판정 기준, 인포그래픽은 원문에 없는 내용으로 새로 작성했고 그 안의 필드명과 숫자는 가상 예시입니다. 전체 내용과 행사 사진은 원문 페이지에서 볼 수 있습니다.