Joule vs 챗봇 — 다른 점 3가지 #shorts #SAP #Joule

이 글이 답하는 질문

"Joule도 결국 ChatGPT 같은 챗봇 아닌가요?"라는 질문을 현장에서 정말 자주 받습니다. 결론부터 말하면, 겉모습(채팅 UI)만 비슷할 뿐 설계 목적과 아키텍처가 근본적으로 다릅니다. 이 글에서는 그 차이를 아키텍처 관점에서 뜯어봅니다. 다 읽고 나면 아래 항목에 스스로 답할 수 있게 되는 것이 목표입니다.

• Joule이 일반 LLM 챗봇과 다른 3가지 핵심 지점(컨텍스트, 권한, 실행)을 설명할 수 있다
• Joule이 SAP 시스템 데이터에 접근하는 흐름(그라운딩/RAG)을 그림으로 그릴 수 있다
• SAP BTP에서 Joule을 활성화하고 커스텀 스킬의 뼈대를 잡을 수 있다

이 글을 보기 전에

SAP BTP 서브어카운트 개념(글로벌 어카운트, 엔타이틀먼트, 롤 컬렉션)과 REST API 기초를 알고 있다고 가정합니다. LLM/프롬프트 관련 배경지식은 없어도 됩니다. 실습 환경으로는 SAP BTP(엔터프라이즈 어카운트), SAP Cloud Identity Services(IAS), 그리고 Joule을 지원하는 SAP 애플리케이션(예: S/4HANA Cloud Public Edition, SuccessFactors) 중 하나가 필요합니다. Joule은 BTP Trial에서는 일반적으로 제공되지 않고, 제품/릴리스별로 지원 범위(capability)가 다르므로 SAP Discovery Center와 각 제품의 What's New에서 가용 여부를 먼저 확인하는 것을 권장합니다.

Joule이 뭔지 한 줄로

Joule은 SAP 애플리케이션 전반에 내장되는 생성형 AI 코파일럿으로, 사용자의 권한 범위 안에서 실제 비즈니스 데이터를 조회하고 트랜잭션까지 실행해 주는 어시스턴트입니다. 비유하자면 ChatGPT가 "무엇이든 아는 도서관 사서"라면, Joule은 "우리 회사 시스템 계정과 결재 권한을 가진 신입 동료"에 가깝습니다. 사서는 일반 지식을 잘 알지만 우리 회사의 이번 달 미결 판매오더는 모릅니다. Joule은 정확히 그걸 알기 위해 만들어졌습니다.

일반 챗봇과 근본적으로 다른 지점

세 가지만 기억하면 됩니다. 첫째, 비즈니스 컨텍스트. Joule은 "판매오더 4500012345 배송 상태 알려줘"라는 질문에 대해 모델이 외운 지식이 아니라 연결된 시스템의 실제 데이터를 API로 조회해 답합니다. 둘째, 권한 상속. 같은 질문이라도 영업 담당자와 인사 담당자가 받는 답이 다릅니다. 조회 권한이 없는 데이터는 Joule도 보여주지 않는 구조가 기본 설계입니다. 셋째, 실행(Transactional). "휴가 신청해 줘", "이 오더 승인 화면 열어 줘"처럼 대화가 실제 업무 액션으로 이어집니다. 일반 챗봇은 방법을 설명하고, Joule은 그 일을 수행합니다.

동작 원리: capability와 그라운딩(RAG)

Joule의 답변은 크게 네 패턴으로 나뉩니다. 화면 이동(Navigational), 데이터 조회(Informational), 트랜잭션(Transactional), 분석(Analytical)입니다. 각 SAP 제품은 자신이 지원하는 기능을 capability라는 단위로 Joule에 등록하고, 사용자의 발화가 들어오면 대략 이런 흐름이 진행됩니다.

1. 사용자가 SAP 앱의 Joule 패널에 자연어로 질문
2. Joule 서비스(BTP)가 발화 의도를 분석해 매칭되는 capability/스킬 선택
3. 필요 시 RAG 방식으로 SAP 문서·사내 문서를 검색해 근거(grounding) 확보
4. 비즈니스 데이터가 필요하면 사용자 인증 토큰을 전달해 해당 시스템 API 호출
5. LLM이 조회 결과를 바탕으로 답변을 생성하되, 근거 없는 내용은 생성하지 않도록 제약

핵심은 4번입니다. Joule과 백엔드 시스템은 SAP Cloud Identity Services를 축으로 신뢰 관계를 맺고, 사용자 신원이 끝까지 전파(principal propagation)됩니다. 그래서 "AI가 권한을 우회하는" 상황이 구조적으로 차단됩니다. 또 하나, 매칭되는 capability가 없으면 Joule은 그럴듯한 답을 지어내는 대신 처리 불가를 알리는 쪽으로 동작하는데, 이것이 일반 LLM 챗봇과의 환각(hallucination) 리스크 차이를 만듭니다.

직접 해보기: 실전 예제 3단계

1단계 — BTP에서 Joule 활성화. 서브어카운트에 Joule 엔타이틀먼트를 할당한 뒤 구독합니다. btp CLI 기준 흐름은 다음과 같습니다(콕핏 GUI로도 동일 작업 가능).

btp assign security/role-collection "Joule End User" \
  --to-user sales.manager@acme.com --create-user-if-missing

btp subscribe accounts/subaccount --to-app joule --plan default
# 이후: IAS 신뢰 설정 → S/4HANA Cloud 등 대상 시스템과
# Unified Customer Landscape에서 formation 구성

2단계 — Joule Studio로 커스텀 스킬 만들기. SAP Build의 Joule Studio에서는 표준 capability에 없는 사내 시나리오를 스킬로 추가할 수 있습니다. 아래는 판매오더 배송 상태 조회 스킬의 뼈대를 개념적으로 표현한 예시입니다(실제 화면은 로우코드 에디터이며, 구조 이해를 돕기 위한 의사 코드입니다).

skill: check-salesorder-delivery
description: >
  판매오더 번호로 배송 상태와 예상 도착일을 조회한다.
  예: "오더 4500012345 언제 도착해?"
parameters:
  - name: salesOrderId
    type: string
    required: true
    prompt_if_missing: "확인할 판매오더 번호를 알려주세요."
action:
  ref: acme-so-status-api    # SAP Build Action Project로 등록한 OData API
  on_error:
    not_found: "오더 {salesOrderId}를 찾을 수 없습니다. 번호를 확인해 주세요."
    forbidden: "이 오더를 조회할 권한이 없습니다. 담당자에게 문의하세요."
response_template: >
  {salesOrderId} 오더는 현재 {status} 상태이며,
  예상 도착일은 {estimatedArrival}입니다.

포인트는 두 가지입니다. description을 구체적으로 써야 의도 매칭 정확도가 올라가고, 오류 케이스(404/403)를 스킬 단에서 명시적으로 처리해야 사용자가 막다른 대화에 갇히지 않습니다.

3단계 — 운영 관점 마무리. 프로덕션 전 체크할 것들입니다. API 호출용 Destination에는 기술 사용자 대신 principal propagation을 사용해 권한 상속을 유지하고, 감사 로그로 누가 어떤 스킬을 실행했는지 추적 가능하게 합니다.

{
  "Name": "acme-so-status-api",
  "URL": "https://my400001-api.s4hana.cloud.sap/sap/opu/odata/sap/API_SALES_ORDER_SRV",
  "Authentication": "SAMLAssertion",
  "audit": { "logSkillInvocation": true, "retentionDays": 90 }
}

테스트는 정상 케이스뿐 아니라 "권한 없는 사용자로 같은 질문", "존재하지 않는 오더 번호", "번호 없이 질문" 세 가지를 반드시 포함하는 것을 권장합니다.

삽질 노트: 자주 만나는 함정

Q1. 구독했는데 앱에서 Joule 아이콘이 안 보여요. 대부분 롤 컬렉션 미할당 또는 IAS 신뢰 설정 누락입니다. 사용자가 Joule 관련 엔드유저 롤을 갖고 있는지, 앱과 Joule이 같은 IAS 테넌트로 인증하는지, formation이 정상 구성됐는지 순서대로 확인하세요.

Q2. 질문했더니 "지원하지 않는 기능"이라고만 답해요. 버그가 아니라 해당 제품/릴리스에 그 capability가 아직 없는 경우가 많습니다. Joule 기능은 제품별·릴리스별로 단계적으로 확장되므로, 제품 문서의 capability 목록을 먼저 대조하는 것이 좋습니다.

Q3. 커스텀 스킬이 자꾸 엉뚱하게(또는 아예 안) 호출돼요. 스킬 description이 모호하거나 다른 스킬과 표현이 겹치는 경우입니다. 사용자 발화 예시를 description에 포함하고, 파라미터 이름을 실제 업무 용어와 맞추면 매칭률이 눈에 띄게 개선됩니다.

Q4. ChatGPT처럼 일반 상식을 물으면 왜 잘 못하나요? 설계 목적이 다르기 때문입니다. Joule은 업무 범위 밖 질문에는 보수적으로 답하도록 되어 있습니다. 범용 지식 Q&A가 필요하면 일반 챗봇을, 사내 데이터·트랜잭션이 필요하면 Joule을 쓰는 것이 맞습니다.

핵심 한 줄

일반 챗봇은 "아는 것을 말하는" 도구이고, Joule은 "당신의 권한으로 시스템을 움직이는" 동료다. 차이의 본질은 UI가 아니라 컨텍스트·권한·실행이라는 세 겹의 아키텍처에 있다.

더 파볼 주제

• Joule Studio에서 다단계 자율 작업을 수행하는 AI 에이전트 만들기
• Generative AI Hub와 Joule의 관계 — 언제 어떤 걸 써야 할까
• 사내 문서를 Joule 그라운딩 소스로 연결하는 방법
• 제품별(S/4HANA, SuccessFactors 등) Joule capability 카탈로그 비교