Joule vs SAP AI Core 진짜 차이 #shorts #SAP #Joule

1. Joule과 SAP AI Core — 이름만 봐서는 뭐가 다른지 모른다

SAP의 AI 소식을 따라가다 보면 두 이름이 계속 등장합니다. Joule과 SAP AI Core. 둘 다 "SAP의 생성형 AI"로 소개되다 보니, 처음 접하는 분들은 "같은 것의 다른 이름인가?" 혹은 "Joule을 쓰려면 AI Core를 먼저 사야 하나?" 같은 질문을 하게 됩니다. 결론부터 말하면 Joule은 최종 사용자가 대화로 쓰는 AI 어시스턴트(코파일럿)이고, SAP AI Core는 개발자가 AI 모델과 LLM을 배포·운영하는 BTP의 기술 플랫폼입니다. 하나는 완성된 제품, 하나는 제품을 만드는 공장에 가깝습니다.

이 글을 읽고 나면 아래를 스스로 판단할 수 있게 됩니다.

• Joule과 SAP AI Core가 각각 어떤 계층에서 어떤 문제를 푸는지 구분
• Generative AI Hub·AI Launchpad 등 주변 용어의 위치 정리
• SAP AI Core로 LLM 배포(Deployment)를 만드는 기본 흐름 이해
• Joule이 S/4HANA에서 업무 요청을 처리하는 방식 이해
• 우리 프로젝트에 둘 중 무엇이(혹은 둘 다) 필요한지 의사결정

시작 전에 필요한 배경은 많지 않습니다. BTP 서브어카운트·서비스 인스턴스 개념과 REST API 호출 경험(curl 또는 Postman)이 있으면 충분하고, Joule 파트는 코드 없이 읽을 수 있습니다.

2. SAP AI Core: LLM을 서비스로 배포하는 기술 플랫폼

SAP AI Core는 SAP BTP(Cloud Foundry 환경, Multi-Cloud) 위에서 제공되는 AI 런타임 서비스입니다. 원래는 머신러닝 모델의 학습(Training)과 서빙(Serving)을 쿠버네티스 기반으로 실행해 주는 인프라였는데, 생성형 AI 시대에 들어서며 Generative AI Hub라는 기능이 얹혔습니다. Generative AI Hub를 통해 Azure OpenAI 계열(GPT-4o 등), Anthropic Claude, Google Gemini, 오픈소스 모델 등 여러 벤더의 LLM을 하나의 통합 API로 배포하고 호출할 수 있습니다.

환경·준비물 기준은 다음과 같습니다(2025년 이후 기준으로 일반적인 구성입니다).

• BTP 글로벌 어카운트 + 서브어카운트: Cloud Foundry 환경, AI Core 지원 리전(예: eu10, us10 계열)
• SAP AI Core 서비스 플랜: Generative AI Hub는 extended 플랜에서 사용 가능한 것이 일반적입니다. Free tier(free 플랜)로는 기본 기능 학습은 가능하지만 상용 LLM 소비에는 제약이 있습니다.
• 관리 UI: SAP AI Launchpad(선택) — AI Core를 화면으로 관리하는 별도 서비스
• 도구: curl 또는 Postman, 서비스 키(clientid/clientsecret/AI API URL)

핵심은 AI Core가 모델 자체를 소유하지 않는다는 점입니다. AI Core는 하이퍼스케일러의 모델을 "배포 단위(Deployment)"로 감싸서, 인증·과금·로깅·모델 교체를 SAP 계약과 BTP 권한 체계 안에서 일원화해 주는 게이트웨이이자 런타임입니다.

3. Joule: SAP 업무 맥락을 아는 AI 어시스턴트

Joule은 S/4HANA Cloud, SuccessFactors, Ariba, SAP Build 등 SAP 애플리케이션에 내장되는 대화형 AI 코파일럿입니다. 사용자가 화면 우측 패널에서 "지난주 지연된 구매 오더 보여줘"라고 입력하면, Joule이 질문 의도를 파악해 해당 앱의 데이터와 기능(이를 capability라 부릅니다)에 연결해 답을 돌려줍니다.

Joule이 일반 챗봇과 다른 점은 세 가지입니다.

• 업무 맥락(Business Context): 로그인한 사용자의 권한과 조직 데이터를 기반으로 답합니다. 권한 없는 데이터는 대화로도 볼 수 없습니다.
• 내비게이션·트랜잭션 실행: 단순 답변을 넘어 해당 Fiori 앱으로 이동하거나 작업 실행까지 이어집니다.
• 사전 구축된 시나리오: SAP가 제품별로 대화 시나리오를 제공하며, Joule Studio(SAP Build 기반)로 회사 고유의 커스텀 스킬을 추가할 수 있습니다.

중요한 사실 하나 — Joule 자체도 내부적으로 생성형 AI 인프라(Generative AI Hub 계열)를 사용합니다. 즉 Joule은 AI Core와 경쟁 관계가 아니라, AI Core류의 인프라 위에서 동작하는 상위 제품입니다. 다만 고객이 Joule을 쓰기 위해 AI Core 인스턴스를 직접 구성할 필요는 없고, 제품 라이선스와 BTP 서브어카운트에서의 Joule 활성화(Identity 연동 포함)로 사용하는 구조가 일반적입니다.

4. 기술 레이어 비교 — AI Core가 아래, Joule이 위에 올라탄다

전기에 비유하면 이해가 빠릅니다. AI Core는 발전소와 배전망(LLM이라는 전력을 안정적으로 공급), Joule은 완성된 가전제품(콘센트에 꽂으면 바로 쓰는 세탁기)입니다. 세탁기를 사는 사람이 발전소 운영법을 알 필요는 없지만, 새로운 가전을 직접 만들려는 개발자는 배전망(AI Core)에 접속해야 합니다.

[사용자 경험 계층]   Joule (S/4HANA·SuccessFactors 등에 내장된 코파일럿)
        │  자연어 → 의도 파악 → capability 실행
[확장 계층]          Joule Studio / SAP Build (커스텀 스킬)
        │
[AI 소비 계층]       Generative AI Hub (통합 LLM API, 프롬프트 관리,
        │            오케스트레이션: 템플릿·grounding·필터링)
[AI 런타임 계층]     SAP AI Core (배포/학습 실행, Resource Group, 과금·로깅)
        │
[모델 계층]          Azure OpenAI · Anthropic · Google 등 파트너 LLM
[플랫폼 계층]        SAP BTP (인증 XSUAA, Destination, 과금, 리전)

구분	Joule	SAP AI Core
정체	AI 어시스턴트 제품(코파일럿)	AI 런타임·배포 플랫폼(BTP 서비스)
주 사용자	현업 최종 사용자	개발자·ML 엔지니어
인터페이스	자연어 대화 패널	REST API(AI API), SDK, AI Launchpad
커스터마이징	Joule Studio 스킬	Deployment·프롬프트·오케스트레이션 직접 설계
과금 관점	제품 라이선스 연계	리소스·토큰 사용량 기반(Capacity Unit)

5. 실전 예제 A: SAP AI Core로 커스텀 LLM 엔드포인트 만들기

[1단계] 토큰 발급과 배포 생성 — 기본 흐름

흐름은 서비스 키 → OAuth 토큰 → Configuration 생성 → Deployment 생성 → 추론 호출 순서입니다. 예를 들어 사내 구매팀의 "공급사 회신 메일 요약" 기능을 만든다고 가정합니다. 먼저 토큰을 받습니다.

curl -X POST "https://mycorp-ai.authentication.eu10.hana.ondemand.com/oauth/token" \
  -d "grant_type=client_credentials" \
  -u "<clientid>:<clientsecret>"

다음으로 GPT-4o 계열 모델을 가리키는 Configuration을 만들고 Deployment를 생성합니다. Resource Group 헤더(AI-Resource-Group)는 팀·용도별 격리 단위입니다.

{
  "name": "procure-mail-summary-cfg",
  "executableId": "azure-openai",
  "scenarioId": "foundation-models",
  "parameterBindings": [
    { "key": "modelName", "value": "gpt-4o" },
    { "key": "modelVersion", "value": "latest" }
  ]
}

Deployment가 RUNNING 상태가 되면 고유 추론 URL(deploymentUrl)이 발급됩니다. 이 URL이 곧 "우리 회사 전용 LLM 엔드포인트"입니다.

[2단계] 실무: 오류 처리와 로깅을 포함한 호출

실무 코드는 타임아웃·429(사용량 초과)·배포 상태 오류를 반드시 다뤄야 합니다. Node.js로 요약 호출을 감싼 예입니다.

async function summarizeSupplierMail(mailBody, token) {
  const url = `${DEPLOY_URL}/chat/completions?api-version=2024-02-01`;
  try {
    const res = await fetch(url, {
      method: "POST",
      headers: {
        "Authorization": `Bearer ${token}`,
        "AI-Resource-Group": "procurement-team",
        "Content-Type": "application/json"
      },
      body: JSON.stringify({
        messages: [
          { role: "system", content: "구매 담당자를 위해 공급사 메일을 3줄로 요약한다." },
          { role: "user", content: mailBody }
        ],
        max_tokens: 400, temperature: 0.2
      }),
      signal: AbortSignal.timeout(20000)
    });
    if (res.status === 429) throw new Error("QUOTA_EXCEEDED: 토큰 한도 초과 — 재시도 백오프 필요");
    if (!res.ok) throw new Error(`AI_CORE_ERROR ${res.status}: ${await res.text()}`);
    const data = await res.json();
    console.info("[ai-core] tokens used:", data.usage?.total_tokens); // 사용량 로깅
    return data.choices[0].message.content;
  } catch (e) {
    console.error("[ai-core] summarize failed:", e.message);
    throw e; // 상위에서 폴백(원문 표시) 처리
  }
}

[3단계] 프로덕션 관점

• 보안: 서비스 키를 코드에 넣지 말고 BTP Destination 또는 Credential Store에 보관합니다. 개인정보가 포함된 프롬프트는 오케스트레이션의 데이터 마스킹 모듈 적용을 검토합니다.
• 성능·비용: 모델별 토큰 단가가 다르므로, 요약처럼 단순한 작업은 경량 모델(예: mini 계열)로 낮추는 것이 일반적으로 유리합니다. Deployment는 유휴 시 정지(Stop) 가능한지 운영 정책에 포함하세요.
• 테스트: 프롬프트 회귀 테스트(동일 입력 세트에 대한 출력 품질 비교)를 배포 파이프라인에 넣고, 모델 버전 교체는 Configuration 교체로 무중단 전환합니다.

6. 실전 예제 B: Joule로 S/4HANA 구매 오더를 조회한다면

같은 구매 업무를 Joule 관점에서 보면 코드가 사라집니다. S/4HANA Cloud(Public Edition 기준, Joule 활성화 완료 상태)에서 구매 담당자는 이렇게 씁니다.

사용자: 이번 주 납기 지연 위험이 있는 구매 오더 보여줘
Joule : 납기일이 임박했으나 입고 미완료인 구매 오더 4건을 찾았습니다.
        - 4500012811 (공급사 한빛금속, 납기 08-03) …
        [Manage Purchase Orders 앱에서 열기]
사용자: 첫 번째 건 담당 구매그룹이 어디야?
Joule : 구매그룹 P21(원자재 1팀)입니다.

이 대화가 가능한 이유는 Joule이 (1) 발화를 의도(intent)로 분류하고, (2) 해당 제품의 capability — 여기서는 구매 오더 조회 시나리오 — 에 매핑한 뒤, (3) 사용자의 권한 범위 안에서 데이터를 조회하고, (4) 후속 액션(앱 내비게이션)을 제안하기 때문입니다. 관리자가 할 일은 코드 작성이 아니라 BTP 서브어카운트에서 Joule 구독·IAS(Identity Authentication) 연동·capability 활성화라는 설정 작업입니다. 표준 시나리오에 없는 사내 고유 업무(예: 자체 협력사 포털 조회)는 Joule Studio에서 스킬을 만들어 API를 연결하는 방식으로 확장합니다.

7. 언제 AI Core, 언제 Joule인가 — 의사결정 기준과 흔한 오해

• "표준 SAP 앱 사용자 생산성을 높이고 싶다" → Joule. 개발 없이 제품 기능으로 활성화합니다.
• "우리만의 AI 기능(요약·분류·검색·에이전트)을 커스텀 앱에 넣고 싶다" → SAP AI Core + Generative AI Hub. CAP/UI5 앱에서 API로 호출합니다.
• "Joule에 사내 시스템 시나리오를 추가하고 싶다" → Joule Studio(+필요 시 백엔드 API는 BTP에서 개발).
• "자체 ML 모델 학습·서빙까지 필요하다" → AI Core의 본래 영역(커스텀 Docker 워크플로)입니다.

자주 나오는 질문 세 가지를 정리합니다.

Q1. Joule을 쓰려면 AI Core 인스턴스를 먼저 만들어야 하나요?

아닙니다. Joule은 제품 내장형 서비스라서 고객이 AI Core 배포를 직접 구성하지 않습니다. 반대로 AI Core를 쓴다고 Joule이 따라오는 것도 아닙니다. 라이선스·활성화 경로가 별개입니다.

Q2. AI Core에서 429 오류나 "deployment not RUNNING" 오류가 납니다.

429는 플랜의 토큰/용량 한도 초과가 흔한 원인으로, 지수 백오프 재시도와 사용량 모니터링(AI Launchpad)이 필요합니다. Deployment 오류는 상태 조회 API로 RUNNING 여부를 먼저 확인하고, AI-Resource-Group 헤더 누락 여부를 점검하세요 — 초심자 오류의 상당수가 이 헤더 누락입니다.

Q3. Joule이 대답을 못 하거나 "권한이 없다"고 합니다.

Joule은 사용자 권한을 그대로 따릅니다. 해당 Fiori 앱 권한(비즈니스 롤)이 없으면 대화로도 조회되지 않으며, capability 자체가 비활성 상태일 수도 있습니다. 관리자 설정과 롤 할당을 먼저 확인하는 것이 일반적입니다.

8. BTP에서 둘을 함께 쓰는 전략, 그리고 더 볼 것들

실제 기업 아키텍처에서는 둘이 자연스럽게 공존합니다. 표준 업무 화면에서는 Joule이 사용자 접점을 담당하고, 커스텀 확장 앱(CAP/RAP + UI5)에서는 AI Core의 Generative AI Hub가 백엔드 AI 엔진을 담당하는 이원 구조입니다. 여기에 Joule Studio 스킬이 커스텀 API를 호출하도록 연결하면, 사용자는 Joule 하나의 대화창에서 표준·커스텀 기능을 모두 만나게 됩니다. 즉 "Joule = 프런트 도어, AI Core = 엔진룸"이라는 역할 분담이 핵심 설계 원칙입니다.

이 글 다음으로는 Generative AI Hub 오케스트레이션(프롬프트 템플릿·grounding·콘텐츠 필터), SAP Cloud SDK for AI를 이용한 CAP 통합, Joule Studio 스킬 제작, AI Launchpad를 통한 사용량 거버넌스를 살펴보는 것을 권장합니다. 더 깊이 볼 만한 문서는 아래와 같습니다.

• SAP Help Portal — SAP AI Core 서비스 가이드
• SAP Help Portal — Generative AI Hub in SAP AI Core
• SAP Help Portal — Joule 문서
• SAP Help Portal — SAP AI Launchpad
• SAP Community — Artificial Intelligence 토픽
• SAP Discovery Center — SAP AI Core 서비스 카탈로그