UI5 모드
BTP

Joule 도입 전 금지 실수 5가지 #shorts #SAP #Joule

수정: 2026년 8월 25일 👁 0 · ♥ 0

이 글에서 얻어갈 것

Joule은 SAP가 제공하는 생성형 AI 코파일럿이자, 업무를 대신 수행하는 AI 에이전트 플랫폼으로 확장되고 있습니다. 그런데 실제 도입 프로젝트를 보면 기술 설정보다 조직 차원의 준비 부족에서 실패가 시작되는 경우가 훨씬 많습니다. 이 글은 가상의 기업 사례(한올물류, 세빛제조)를 통해 도입 프로세스 단계별로 "하지 말아야 할 것"을 정리한 실전 예제입니다.

  • 권한 설계를 뒤로 미루면 왜 파일럿이 통째로 멈추는지 이해한다
  • 프롬프트·에이전트 거버넌스 정책을 문서가 아닌 설정으로 강제하는 방법을 익힌다
  • 파일럿 범위 설계와 KPI 측정, 변화관리 체크리스트를 확보한다
  • 데이터 소스 검증 없이 연결했을 때의 리스크와 회피법을 파악한다

이 글을 보기 전에

SAP BTP 서브어카운트와 롤 컬렉션 개념, S/4HANA Cloud의 비즈니스 역할(Business Role)이 무엇인지 정도만 알면 충분합니다. 코드는 JSON/YAML 수준이며 ABAP 지식은 필요하지 않습니다. Joule을 한 번도 켜보지 않았더라도, "AI 비서에게 회사 데이터를 열어준다"는 관점에서 읽으면 이해할 수 있는 입문 난이도입니다.

테스트 환경

이 글은 다음 환경을 기준으로 합니다. 버전에 따라 메뉴 명칭이 다를 수 있습니다.

  • SAP S/4HANA Cloud Public Edition 2508 이상 (Joule 기능 활성화 대상)
  • SAP BTP 서브어카운트 + SAP Cloud Identity Services(IAS/IPS) 연동 완료
  • Joule 구독 및 SAP Build의 Joule Studio(에이전트/스킬 빌더) 접근 권한
  • AI 사용량 단위인 AI Units 계약 여부 확인 — 일반적으로 파일럿 전에 소진 계획을 세우는 것이 권장됩니다
  • 거버넌스 문서 초안(허용 업무 범위, 금지 데이터 목록)을 담을 저장소

중요한 점은, 위 목록에서 기술 항목보다 마지막 항목(거버넌스 초안)이 먼저 준비되어야 한다는 것입니다.

핵심 개념 — 에이전트 도입은 "신입사원 온보딩"이다

Joule 에이전트를 이해하는 가장 좋은 비유는 권한이 아주 강한 신입사원입니다. 신입사원에게 첫날부터 전사 데이터베이스 관리자 계정을 주는 회사는 없습니다. 그런데 AI 에이전트 도입에서는 이 상식이 자주 무너집니다.

Joule의 동작 구조를 단순화하면 세 층입니다.

  • 대화 층 — 사용자의 자연어 요청을 해석하는 LLM 기반 오케스트레이션
  • 스킬/에이전트 층 — 요청을 실제 기능 호출로 변환. 표준 제공 기능(Navigational, Transactional, Informational)과 Joule Studio로 만드는 커스텀 에이전트로 구성
  • 데이터·권한 층 — 호출 시점에 사용자의 기존 권한을 그대로 상속하여 백엔드에 접근

여기서 핵심 원리가 나옵니다. Joule은 일반적으로 사용자가 원래 볼 수 없는 데이터를 보여주지 않습니다. 즉 기존 권한 설계가 부실하면 그 부실함이 AI를 통해 증폭됩니다. 평소에는 아무도 열어보지 않던 과잉 권한을, 에이전트는 "질문 한 줄"로 즉시 활용해버리기 때문입니다.

조직 차원에서 자주 발생하는 실수는 다섯 가지로 요약됩니다.

  1. 권한 설계 후행 — "일단 켜고 나중에 조이자"
  2. 프롬프트·에이전트 거버넌스 부재 — 누가 어떤 에이전트를 만들 수 있는지 규칙 없음
  3. 데이터 소스 무검증 연결 — 오래된 문서 저장소를 그라운딩 소스로 연결
  4. 파일럿 범위 과다 — 첫 파일럿에 부서 5개, 시나리오 20개
  5. 변화관리 소홀 — 사용자 교육 없이 배포 후 "아무도 안 씀"

실전 예제 — 3단계로 보는 회피 설계

1단계: 최소 권한 파일럿 롤 만들기 (기본)

가상의 한올물류는 창고 출고 지연 문의 대응에 Joule 파일럿을 시작했습니다. 첫 실수 회피는 "파일럿 전용 최소 권한 롤 컬렉션"을 분리하는 것입니다. 전체 사용자에게 열지 말고, 조회 전용 범위로 시작합니다.

{
  "roleCollection": "JOULE_PILOT_OUTBOUND_READ",
  "description": "Joule 파일럿 - 출고조회 전용 (2026 Q3, 만료일 명시)",
  "roles": [
    "hanol_wh_shipment_display",
    "hanol_wh_stock_display"
  ],
  "userGroups": ["PILOT_WAVE1_LOGISTICS"],
  "excluded": ["급여/인사 데이터 롤은 파일럿 그룹에서 명시적으로 제외"]
}

포인트는 두 가지입니다. 롤 컬렉션 이름에 PILOT과 기간을 넣어 임시성을 드러내고, 파일럿 사용자 그룹을 IAS에서 별도로 관리해 종료 시 일괄 회수할 수 있게 하는 것입니다.

2단계: 거버넌스를 설정으로 강제하기 (실무 시나리오)

세빛제조는 초기에 현업 누구나 Joule Studio에서 에이전트를 만들 수 있게 했다가, 검증되지 않은 에이전트가 난립하는 문제를 겪었습니다. 회피법은 거버넌스 정책을 워드 문서가 아니라 기계가 읽는 정책 파일 + 승인 파이프라인으로 만드는 것입니다. 아래는 에이전트 등록 요청서를 검증하는 정책 예시입니다.

# agent-governance-policy.yaml — 에이전트 배포 전 필수 통과 항목
agent_registration:
  required_fields: [owner_team, business_purpose, data_scope, expiry_review_date]
  data_scope:
    forbidden_categories: [salary, personal_id, medical]   # 연결 금지 데이터
    grounding_sources:
      require_freshness_days: 180        # 180일 이상 미갱신 문서는 소스 제외
      require_owner_signoff: true        # 소스 소유 부서 승인 필수
  deployment:
    approvers_min: 2                     # IT 보안 1 + 현업 오너 1
    log_all_actions: true                # 감사 로그 활성화 확인
on_violation:
  action: reject_and_notify
  channel: "governance-review@sebit.example"

에러 처리 관점에서, 승인 파이프라인은 거절 사유를 반드시 로깅해야 합니다. "누가, 어떤 데이터 범위 때문에 반려됐는지"가 쌓이면 그 자체가 조직의 거버넌스 학습 데이터가 됩니다. 특히 require_freshness_days는 세 번째 실수(데이터 소스 무검증 연결)를 막는 장치입니다. 5년 전 단종 제품 매뉴얼이 그라운딩 소스에 섞여 있으면, 에이전트는 그럴듯한 말투로 낡은 답을 합니다.

3단계: 파일럿 KPI·감사 로그·보안 점검 (프로덕션 준비)

파일럿 범위 과다를 막는 실무 기준은 "부서 1개, 시나리오 3개 이하, 4~6주"입니다. 그리고 확장 여부는 감(感)이 아니라 측정으로 결정합니다. 아래는 파일럿 종료 시 감사 로그를 집계해 KPI를 뽑는 예시입니다.

-- 파일럿 기간 에이전트 사용 로그 집계 (내부 로그 테이블 기준 예시)
SELECT agent_name,
       COUNT(*)                                   AS total_calls,
       SUM(CASE WHEN outcome = 'RESOLVED' THEN 1 ELSE 0 END) AS resolved,
       SUM(CASE WHEN outcome = 'ESCALATED' THEN 1 ELSE 0 END) AS escalated,
       AVG(handling_seconds)                      AS avg_seconds
FROM   zhanol_joule_usage_log
WHERE  used_on BETWEEN '2026-07-01' AND '2026-08-15'
GROUP  BY agent_name
ORDER  BY total_calls DESC;

프로덕션 전환 전 보안 점검은 최소 세 가지입니다. 첫째, BTP 감사 로그(Audit Log Retrieval)로 에이전트의 실제 데이터 접근 기록을 샘플 검토합니다. 둘째, 파일럿 롤 컬렉션의 만료 처리(1단계에서 기간을 명시한 이유). 셋째, 변화관리 — 사용률이 낮은 팀은 기능 문제보다 "무엇을 물어봐야 할지 모르는" 경우가 대부분이므로, 잘 된 질문 예시 10개를 팀 위키에 배포하는 것이 일반적으로 가장 효과가 큽니다.

삽질 노트

Q1. 파일럿 사용자가 "권한이 없다"는 응답만 받습니다. Joule 설정 문제인가요?

대부분 Joule이 아니라 백엔드 권한 문제입니다. Joule은 사용자 권한을 상속하므로, 해당 사용자가 Fiori 앱에서 같은 데이터를 직접 조회할 수 있는지 먼저 확인하세요. 앱에서도 안 되면 비즈니스 롤부터 수정해야 합니다. 이것이 "권한 설계는 파일럿 전에"라는 원칙의 실체입니다.

Q2. 에이전트가 오래된 정책 문서를 근거로 답합니다.

그라운딩 소스에 갱신되지 않은 문서가 섞인 경우입니다. 소스 연결 전 문서 최신성 검토(예: 180일 기준)와 소유 부서 승인 절차를 거치고, 이미 연결했다면 해당 소스를 분리한 뒤 재검증 후 다시 연결하는 것이 안전합니다.

Q3. 파일럿 반응이 좋아 바로 전사 확대하자는 요구가 나옵니다.

AI Units 소진 예측과 권한 검토 없이 확대하면 비용·보안 양쪽에서 문제가 됩니다. 부서 단위 웨이브 확산(1개 → 3개 → 전사)과 웨이브마다 KPI 재측정을 권장합니다.

Q4. 현업이 만든 에이전트가 너무 많아 관리가 안 됩니다.

2단계의 정책 파일처럼 등록 요건(오너, 목적, 데이터 범위, 리뷰 예정일)을 강제하고, 리뷰일이 지난 에이전트는 자동 비활성 후보로 올리는 운영 루틴을 만드세요.

더 파볼 주제

도입 프로세스가 자리잡았다면, 다음 순서로 깊이를 더할 수 있습니다. Joule Studio로 커스텀 에이전트를 직접 설계하는 실습, SAP Build Process Automation과 결합한 승인 워크플로 자동화, AI Units 사용량 모니터링 대시보드 구축, 그리고 다중 에이전트 협업 시나리오에서의 책임 추적(어느 에이전트가 어떤 결정을 했는가)이 그것입니다. 특히 감사 로그 기반 책임 추적은 규제 산업에서 도입 승인을 받는 핵심 근거가 됩니다.

더 읽어볼 자료

본 예제의 회사명·테이블명·정책 파일은 모두 설명을 위해 창작한 것이며, 실제 구현 시에는 사용 중인 에디션과 릴리스 노트를 확인하시기 바랍니다.

댓글 0

아직 댓글이 없습니다.