Joule Work: Bosch가 SAP 에이전트를 전사로 넓히기 전에 따지는 조건
Bosch Digital은 2025년 초부터 SAP와 함께 Joule Work와 에이전트를 Billing·HR에서 시험해 맞춤 AI 사례 10개로 수백만 단위를 절감했습니다. 그래도 신뢰성, 응답 속도, 권한 관리, 비용 통제를 풀기 전에는 전사로 넓히지 않는다는 판단과, 표준 에이전트를 먼저 쓰는 원칙을 정리하고 확대 관문 지표를 붙였습니다.
에이전트가 돈을 아껴 준다는 사실과 전사에 깔아도 된다는 판단은 별개입니다. Bosch는 맞춤 AI 사례 10개로 이미 수백만 단위를 아꼈지만, 신뢰성·속도·권한·비용을 풀기 전까지 확대를 미룹니다. 따라 하려면 표준 에이전트를 먼저 쓰고, 이 조건을 숫자로 재는 확대 관문을 시범 단계부터 세워야 합니다.
요약
Bosch는 오래된 SAP 고객입니다. RISE with SAP(SAP의 클라우드 전환 패키지)로 클라우드 전환을 시작했고, 이 전환이 프로세스를 단순하게 만드는 바탕이 됐습니다. Bosch Digital 애플리케이션 총괄 EVP Robert Miller는 베를린에서 열린 30번째 SAP TechEd에서 그다음 단계를 소개했습니다. Bosch는 2025년 초 SAP와 공동 프로그램을 시작했습니다. 팀들은 Joule Work(SAP의 업무용 AI 작업 공간), Joule Work Studio 2.0, 초기 어시스턴트와 에이전트를 Billing(청구)과 HR 업무에서 시험하고 있습니다. Bosch의 시스템 환경은 복잡해서, Joule Work가 그 안에서 접근 권한까지 맞춰 돌아가야 합니다. 일정은 2026년 퍼블릭 클라우드 환경, 2027년 프라이빗 클라우드 환경의 Joule 가동입니다.
현재 맞춤 AI 사례 10개가 운영 중이고, 이것으로 수백만 단위를 절감했습니다. 12개는 개발 중입니다. 까다로운 사용자 그룹의 초기 반응도 긍정적이었습니다. 그런데 Miller는 아직 초기 단계라며 전사 확대 전에 풀 과제를 분명히 했습니다. 사용자가 믿을 수 있는 답, 더 빠른 응답, 일상 업무와 복잡한 시스템 환경에 자연스럽게 녹아드는 통합, 권한 관리, 그리고 그가 중요하다고 강조한 비용 통제입니다. 원칙도 하나 밝혔습니다. SAP 표준 에이전트를 최대한 쓰고 필요한 곳만 확장하며, 내부 역량은 Bosch에만 있는 요구에 씁니다. 아래에서는 이 판단을 네 가지 작동 원리로 풀고, 확대 관문을 숫자로 재는 법과 8주 일정을 덧붙입니다.
핵심 메커니즘
Critical user group 먼저: 까다로운 사용자에게 먼저 시험한다
무엇인가. 요구 수준이 높고 불만을 바로 말하는 사용자 그룹을 첫 시험 대상으로 고르는 방식입니다.
어떻게 작동하나. 쉬운 사용자에게 먼저 보여 주면 반응이 좋아도 확대 후에 문제가 터집니다. 까다로운 그룹에서 통과하면 그 결과를 더 믿을 수 있습니다. Bosch는 이 그룹의 초기 피드백을 받아 긍정적인 반응을 확인했고, 동시에 확대 전에 풀 과제 목록을 얻었습니다.
언제 쓰나. 같은 도구를 수만 명에게 넓힐 계획이 있고, 첫 인상이 사내 확산 속도를 좌우할 때 맞습니다. 사용자가 몇십 명뿐인 부서 도구라면 굳이 그룹을 고를 필요가 적습니다.
원문의 예. Bosch는 Billing과 HR에서 Joule Work와 초기 에이전트를 시험했습니다. 어떤 사용자로 그룹을 꾸렸는지는 원문에서 밝히지 않았습니다.
Standard first, extend where needed: 표준 에이전트를 먼저 쓴다
무엇인가. 벤더가 내놓은 표준 에이전트를 기본으로 쓰고, 표준으로 안 되는 부분만 확장하는 원칙입니다.
어떻게 작동하나. 업무마다 에이전트를 새로 만들면 유지보수와 업그레이드 부담이 사례 수만큼 늘어납니다. 표준을 먼저 쓰면 벤더가 업데이트를 책임지고, 사내 팀은 Bosch에만 있는 업무 규칙이나 데이터에 시간을 씁니다. 이 원칙을 따르면 개발 중인 12개 사례도 표준으로 덮을 수 있는지부터 따지게 됩니다.
언제 쓰나. ERP처럼 핵심 업무가 이미 한 벤더의 표준 프로세스 위에 있을 때 맞습니다. 업무 자체가 경쟁력의 원천이라 표준과 크게 다르면 확장 범위가 커집니다.
원문의 예. Miller는 SAP 표준 에이전트를 가능한 한 많이 쓰고 필요한 곳에서 확장한다고 밝혔습니다.
Scale gate: 효과가 나와도 조건을 먼저 푼다
무엇인가. 시범에서 효과가 나온 뒤 전사 확대를 결정하기 전에 통과해야 하는 조건 묶음입니다.
어떻게 작동하나. 시범 단계에서는 사용자도 적고 데이터 범위도 좁아서 문제가 덜 보입니다. 사용자가 늘면 틀린 답 하나가 수천 번 반복되고, 느린 응답은 업무 흐름을 끊습니다. 권한 밖 데이터가 답에 섞이거나 호출량에 비례해 비용이 불어날 수도 있습니다. 그래서 Bosch는 절감 효과와 별도로 신뢰성, 응답 속도, 업무와 시스템 환경 통합, 권한 관리, 비용 통제를 확대 조건으로 둡니다.
언제 쓰나. 시범이 성공해 경영진이 빠른 확대를 원할 때 특히 필요합니다. 성과 숫자가 조건 점검을 건너뛰는 근거가 되지 않게 막습니다.
원문의 예. Bosch는 사례 10개로 절감 효과를 확인했지만, 아직 초기 단계라며 몇 가지 과제를 푼 뒤 확대하겠다고 했습니다.
Joule Work 접점: 하나의 작업 공간에서 SAP와 non-SAP 앱을 잇는다
무엇인가. Joule Work는 사용자가 데이터에 질문하고 보고서와 Excel 파일을 바로 만들며, 여러 앱을 오가는 일을 한곳에서 하게 하는 SAP의 AI 작업 공간입니다.
어떻게 작동하나. Spaces(질문 하나를 공유 가능한 동적 대시보드로 바꾸는 기능)로 답을 팀과 나눕니다. 브라우저, macOS·Windows 데스크톱 앱, 모바일에서 쓸 수 있습니다. WalkMe 기반의 action bar가 브라우저 탭과 데스크톱 앱 위에 함께 떠서, SAP 앱과 non-SAP 앱 모두에서 작동합니다. 사용자 선호를 학습하고 A2A(에이전트끼리 통신하는 규약)와 MCP(모델이 외부 도구·데이터에 붙는 규약)를 지원합니다. 연결 범위가 넓을수록 Bosch가 꼽은 권한 관리 조건이 무거워집니다.
언제 쓰나. 직원이 SAP와 다른 시스템을 오가며 같은 데이터를 다시 찾고 옮기는 일이 많을 때 맞습니다.
원문의 예. 기사는 그때그때 Excel 파일을 만들어 주는 기능을 사용자들이 특히 반긴 기능으로 소개합니다. SAP는 자사 직원 110,000명에게 Joule Work를 시험했고, Early Adopter Care 프로그램에는 150개가 넘는 고객이 참여했습니다.
통념과 다른 주장
흔히 이렇게 봅니다시범에서 비용 절감이 확인되면 그 숫자를 근거로 빨리 전사에 깔아야 한다.
Bosch는 이렇게 봅니다절감 효과와 확대 결정은 따로 봅니다. 답의 신뢰성, 속도, 권한, 비용을 풀기 전에는 넓히지 않습니다.
근거맞춤 사례 10개로 이미 수백만 단위를 아꼈고 까다로운 사용자 반응도 긍정적이었지만, Miller는 아직 초기 단계라며 확대 조건을 먼저 꼽았습니다.
저자가 든 사례
Bosch Digital의 Joule 조기 도입
| 구분 | 내용 |
|---|---|
| 상황 | 오래된 SAP 고객으로 RISE를 통해 클라우드 전환 중. 시스템 환경이 매우 복잡해 접근 권한 관리까지 맞춰야 함 |
| 한 일 | 2025년 초 SAP와 공동 프로그램 시작. Joule Work, Joule Work Studio 2.0, 초기 어시스턴트·에이전트를 Billing·HR에서 시험. 맞춤 AI 사례 개발 |
| 결과 | 맞춤 사례 10개 운영, 수백만 단위 절감(통화와 정확한 금액은 원문에서 밝히지 않음), 12개 개발 중. 까다로운 사용자 그룹 반응 긍정적 |
| 연결 | Critical user group 먼저, Standard first, Scale gate |
기술 디테일: 확대 관문을 숫자로 재려면
신뢰성을 재려면(Scale gate 연결) 업무별 정답 세트를 먼저 만듭니다. Billing이라면 과거 청구 문의 100~200건과 실제 처리 결과를 짝지어 둡니다. 같은 질문을 3회씩 돌려 답이 흔들리는지 보고, 답마다 근거 문서나 SAP 레코드 번호를 붙이게 해서 근거 없는 답은 오답으로 셉니다. 표준 에이전트와 확장 에이전트를 같은 정답 세트로 재면, 확장이 실제로 나아졌는지도 알 수 있습니다.
응답 속도를 재려면 평균 대신 중앙값과 상위 5% 지연을 봅니다. 사용자가 불편을 느끼는 것은 느린 몇 건이기 때문입니다. 지연이 길면 어느 구간에서 시간이 드는지(모델 호출, SAP 조회, 다른 앱 연결) 나눠 기록합니다.
권한을 지키려면 에이전트가 서비스 계정의 넓은 권한이 아니라 요청한 사람의 권한으로 데이터를 읽게 합니다. 시험 세트에 권한 밖 요청(다른 부서 급여, 다른 법인 청구 건)을 일부러 섞어 모두 거절되는지 봅니다. A2A·MCP로 다른 에이전트나 도구를 부를 때도 같은 사용자 권한이 넘어가는지 확인합니다.
비용을 통제하려면 작업 1건당 비용(모델 호출, 조회, 연결 호출 합계)을 사례마다 기록하고, 그 사례의 절감액과 나란히 놓습니다. 사용자가 10배로 늘면 비용도 10배가 되는지, 캐시나 더 작은 모델로 줄일 여지가 있는지 확대 전에 계산합니다. 아래 기록 형식은 가상 예시입니다.
{
"use_case": "billing-inquiry-01",
"agent_type": "standard | extended",
"eval": {"cases": 150, "runs_per_case": 3, "accuracy": 0.94, "grounded_rate": 0.97},
"latency_ms": {"p50": 2100, "p95": 6800},
"access": {"out_of_scope_requests": 30, "blocked": 30},
"cost": {"per_task": "통화 단위로 기록", "monthly_saving": "같은 단위로 기록"},
"gate_decision": "pass | fix | hold"
}자주 막히는 경우에 대비하려면 아래 세 가지를 처음부터 시험 세트에 넣습니다(실행 제안).
| 막히는 경우 | 증상 | 대응 |
|---|---|---|
| 근거 없는 답 | 그럴듯하지만 SAP 레코드와 다른 금액·날짜 | 근거 레코드 번호가 없는 답은 표시하지 않고 사람에게 넘김 |
| 권한 우회 | 다른 에이전트·도구를 거치며 넓은 권한으로 조회 | 호출마다 요청자 ID를 넘기고 권한 밖 결과는 버림, 거절 로그 보관 |
| 비용 급증 | 확대 후 긴 대화·반복 조회로 호출량 폭증 | 사례별 월 예산 상한과 알림, 반복 조회는 캐시 |
표준과 확장을 가르려면(Standard first 연결) 사례마다 세 가지를 차례로 묻습니다. 표준 에이전트를 그대로 쓰면 정답 세트 합격선을 넘는가? 넘지 못하면 프롬프트나 설정만 바꿔서 되는가? 그래도 안 되면 Bosch 고유 데이터나 규칙을 붙이는 확장이 필요한가? 확장한 부분은 따로 기록해 두고, 벤더가 표준을 업데이트할 때마다 확장이 아직 필요한지 다시 봅니다.
현업 실행 디테일: 누가, 언제, 무엇을
| 역할 | 담당 | 하는 일 |
|---|---|---|
| 스폰서 | CIO 또는 디지털 조직장 | 확대 관문 기준 승인, 판정 회의 주재 |
| 업무 오너 | Billing·HR 등 현업 리더 | 정답 세트 제공, 합격선 결정, 까다로운 사용자 그룹 선정 |
| 플랫폼 팀 | SAP 운영·AI 엔지니어 | 표준 에이전트 설정, 확장 개발, 지표 수집 |
| 보안·권한 | 정보보호·권한 관리 담당 | 권한 밖 요청 시험 세트 작성, 차단 결과 확인 |
| 재무 | FinOps 또는 재무 담당 | 작업당 비용과 절감액 대조, 확대 시 비용 추정 |
시작 전 준비물. 운영 중인 AI 사례 목록과 사례별 절감 산식, 업무별 과거 처리 기록 100~200건, 역할별 권한 표, 지난 3개월 AI 호출 비용입니다.
| 기간 | 할 일 | 산출물 |
|---|---|---|
| 1~2주 | 사례 목록 정리, 표준·확장 구분, 정답 세트와 기준선 작성 | 사례 대장, 정답 세트 |
| 3~4주 | 신뢰성·속도·권한·비용 측정 | 사례별 관문 측정표 |
| 5~6주 | 미달 항목 보완(근거 연결, 조회 경로, 권한 위임, 모델 선택), 재측정 | 보완 내역, 재측정표 |
| 7~8주 | 판정 회의, 통과 사례만 다음 사용자 그룹으로 확대 | 확대·보완·보류 결정 |
현업에 물을 것.
- 이 업무에서 AI 답이 틀리면 누가, 얼마나 늦게 알아차리나요?
- 몇 초 이상 기다리면 사용자가 원래 방식으로 돌아가나요?
- 이 업무에서 다른 사람이 보면 안 되는 데이터는 무엇인가요?
- 지금 절감액을 계산한 산식을 재무가 인정하나요?
진행 판정 기준(예시). 네 조건을 모두 채운 사례만 넓힙니다. 정답 세트 정확도가 업무 오너가 정한 합격선(예: 95%) 이상이고, 상위 5% 응답이 대기 한도(예: 5초) 안에 들어오며, 권한 밖 요청이 모두 차단되고, 확대 후 예상 비용이 같은 기간 절감액보다 작아야 합니다.
AX 적용 제언. SAP를 쓰는 국내 제조 대기업이라면 Joule을 켜기 전에 사례 대장부터 만드는 편이 낫습니다. 사례마다 표준인지 확장인지, 절감액을 어떻게 셌는지, 네 조건을 어떻게 재는지 한 줄씩 적어 둡니다. 첫 대상은 Bosch처럼 청구나 HR 문의처럼 질문이 반복되고 정답 기록이 남는 업무가 맞습니다. 판정은 IT 혼자 하지 않습니다. 합격선은 현업 리더가, 권한 시험은 정보보호가, 비용 대조는 재무가 맡게 나눕니다.
원문 사례
| 항목 | 내용 |
|---|---|
| 출처 | diginomica, Stuart Lauchlan, 2026.10.27 (SAP는 diginomica의 프리미어 파트너라고 기사에 명시) |
| 발표 | 30번째 SAP TechEd, 베를린. Robert Miller(Bosch Digital 애플리케이션 총괄 EVP) |
| 배경 | 오래된 SAP 고객, RISE로 클라우드 전환, 매우 복잡한 시스템 환경 |
| 시험 범위 | 2025년 초 공동 프로그램 시작, Joule Work·Joule Work Studio 2.0·초기 어시스턴트와 에이전트를 Billing·HR에서 시험 |
| 성과 | 맞춤 AI 사례 10개 운영, 수백만 단위 절감, 12개 개발 중 |
| 확대 조건 | 신뢰성, 빠른 응답, 일상 업무와 시스템 환경 통합, 권한 관리, 비용 통제 |
| 원칙 | SAP 표준 에이전트 우선, 필요한 곳만 확장, 내부 역량은 Bosch 고유 요구에 |
| 일정 | 2026년 퍼블릭 클라우드, 2027년 프라이빗 클라우드에서 Joule 가동 |
| SAP 측 | Early Adopter Care 참여 고객 150곳 이상, SAP 직원 110,000명이 Joule Work 시험 |
핵심 개념
- RISE with SAP
- SAP의 클라우드 전환 패키지. Bosch는 이를 프로세스 단순화의 출발점으로 삼았습니다.
- Spaces
- 질문 하나를 팀이 함께 보는 동적 대시보드로 바꾸는 Joule Work 기능입니다.
- Early Adopter Care
- 신기능을 일찍 쓰는 고객을 SAP가 따로 지원하는 프로그램. Bosch가 참여하고 있습니다.
- A2A
- Agent-to-Agent. 서로 다른 에이전트가 작업을 주고받는 통신 규약입니다.
내 메모
TODO: 내 생각 추가
원문은 diginomica의 SAP TechEd 기사(Stuart Lauchlan, 2026.10.27)로, Bosch의 Joule Work 조기 도입을 다룹니다. 요약, 핵심 메커니즘의 원문 예, 통념과 다른 주장, 사례, 원문 사례 표는 기사 내용을 AX Review가 다시 정리했습니다. 절감 효과와 수치는 Bosch와 SAP의 설명이며, 운영 중인 사례 10개의 내용과 절감액 세부는 원문에서 밝히지 않았습니다. 기술·현업 실행 디테일, 기록 형식, 지표, 일정과 판정 기준, 인포그래픽은 원문에 없는 내용으로 새로 작성했으며 그 안의 숫자와 필드명은 가상 예시입니다. 원문 전체는 diginomica에서 볼 수 있습니다.