Joule vs T-Code — 승인 자동화 3가지 #shorts #SAP #Joule

📖 개요: 자연어 한 문장으로 SAP 업무를 움직이기

SAP 업무 자동화라고 하면 지금까지는 트랜잭션 코드(T-Code)를 외우고, 배치 잡을 걸고, 필요하면 ABAP 커스텀 개발까지 하는 그림이 일반적이었습니다. 이 글은 SAP의 생성형 AI 코파일럿인 Joule을 SAP BTP 환경에 연동해, 승인·데이터 조회·워크플로우 트리거 같은 업무 프로세스를 자연어 대화로 자동화하는 방법을 기존 방식과 비교하며 다루는 실전 예제입니다. 초급자 기준으로 다음을 얻어갈 수 있습니다.

• 기존 수동 트랜잭션/커스텀 개발 방식과 Joule 방식의 구조적 차이 이해
• BTP에서 Joule을 활성화하고 백엔드 시스템과 연결하는 큰 흐름 파악
• Joule Studio 커스텀 스킬로 판매 오더 조회·승인 워크플로우를 트리거하는 3단계 구현
• 연동 시 자주 만나는 오류(IAS 신뢰 설정, 권한, 스킬 미노출)의 해결 방향

📚 미리 알고 있으면 좋은 것

깊은 개발 경험은 필요 없지만, SAP BTP 서브어카운트와 구독(Subscription) 개념, REST API와 JSON의 기본 구조, 그리고 SAP Build(Process Automation 포함)가 무엇을 하는 도구인지 정도는 알고 있으면 흐름을 따라오기 수월합니다. ABAP 지식은 이 글에서는 필수가 아닙니다. Joule 연동의 대부분은 코딩보다 설정과 연결에 가깝기 때문입니다.

🔧 환경 구성과 준비물

이 글의 시나리오는 2026년 기준 다음 구성 요소를 전제로 합니다. Joule은 라이선스 정책과 지원 범위가 제품·에디션별로 다르므로, 실제 적용 전 계약 범위 확인이 권장됩니다.

• SAP BTP 서브어카운트 — Joule 애플리케이션 구독(Entitlement의 Joule application 플랜 필요)
• SAP Cloud Identity Services (IAS) — Joule은 IAS 기반 인증을 전제로 하며, 서브어카운트와 신뢰(Trust) 구성이 필수
• 백엔드 시스템 — 예제에서는 SAP S/4HANA Cloud Public Edition을 가정 (SuccessFactors 등 다른 제품도 유사한 패턴)
• SAP Build Process Automation — 승인 워크플로우를 담당
• Joule Studio — SAP Build 로비에서 커스텀 스킬을 만드는 디자인타임 도구

백엔드와 Joule의 연결은 일반적으로 SAP for Me / 시스템 랜드스케이프의 포메이션(Formation) 구성 또는 BTP 데스티네이션을 통해 이뤄집니다.

💡 핵심 개념: 창구 방문과 개인 비서의 차이

기존 SAP 업무 처리를 비유하면 은행 창구 방문과 같습니다. 어느 창구(T-Code)로 가야 하는지 사용자가 알아야 하고, 양식(선택 화면)을 정확히 채워야 하며, 창구가 없으면 새로 만들어 달라고(ABAP 커스텀 개발) 요청해야 합니다. 반면 Joule은 업무를 아는 개인 비서에 가깝습니다. "지난주 미결 판매 오더 보여줘"라고 말하면, 어느 창구에 가서 어떤 양식을 쓸지는 비서가 알아서 처리합니다.

동작 원리를 단순화하면 다음 흐름입니다.

1. 의도 분석 — 사용자의 자연어 입력에서 의도(intent)와 파라미터(오더 번호, 기간 등)를 추출
2. 스킬 매칭 — 화면 이동(내비게이션), 데이터 조회(정보성), 처리 실행(트랜잭션성), 분석성 패턴 중 적합한 스킬 선택
3. 실행 — 스킬에 연결된 API·Action·워크플로우를 사용자의 권한 범위 안에서 호출
4. 응답 생성 — 결과를 대화형 카드나 텍스트로 요약해 반환

두 방식의 차이를 정리하면 이렇습니다.

구분	기존 방식 (수동/커스텀 개발)	Joule Copilot 연동
진입점	T-Code, Fiori 앱을 사용자가 직접 탐색	자연어 한 문장
승인 처리	인박스 접속 → 건별 확인 → 클릭	"내 승인 대기 건 처리해줘" 대화로 처리
신규 자동화 추가	ABAP/Fiori 커스텀 개발 (주 단위)	Joule Studio 스킬 + Action 구성 (일 단위)
권한 통제	역할별 T-Code 권한	기존 사용자 권한을 그대로 상속

중요한 점은 Joule이 권한을 우회하지 않는다는 것입니다. 사용자가 원래 볼 수 없는 데이터는 Joule에게 물어봐도 볼 수 없습니다. 즉 Joule 연동은 보안 모델을 새로 만드는 작업이 아니라, 기존 프로세스 위에 대화형 진입점을 얹는 작업입니다.

💻 실전 구현: 판매 오더 조회부터 승인 자동화까지 3단계

1단계 — 기본: 판매 오더 조회 스킬 만들기

Joule Studio에서 커스텀 스킬을 만들 때, 백엔드 호출은 SAP Build의 Action 프로젝트로 연결하는 방식이 일반적입니다. 먼저 판매 오더 상태 조회 API의 OpenAPI 스펙을 Action 프로젝트로 가져옵니다.

{
  "openapi": "3.0.0",
  "info": { "title": "SalesOrderStatusAPI", "version": "1.0.0" },
  "paths": {
    "/salesOrders/{orderId}": {
      "get": {
        "operationId": "getSalesOrderStatus",
        "parameters": [
          { "name": "orderId", "in": "path", "required": true,
            "schema": { "type": "string" },
            "description": "판매 오더 번호 (예: SO-2026-0815)" }
        ],
        "responses": {
          "200": {
            "description": "오더 상태",
            "content": { "application/json": { "schema": {
              "type": "object",
              "properties": {
                "orderId":       { "type": "string" },
                "customerName":  { "type": "string" },
                "netAmount":     { "type": "number" },
                "overallStatus": { "type": "string" }
              } } } }
          }
        }
      }
    }
  }
}

Joule Studio에서 새 스킬을 만들고 이 Action을 연결한 뒤, 스킬 설명에 "판매 오더의 처리 상태를 조회한다"처럼 의도를 잘 드러내는 문장을 적어야 합니다. Joule은 이 설명을 근거로 사용자 발화와 스킬을 매칭하기 때문에, 설명 품질이 곧 인식률입니다. 배포 후 "SO-2026-0815 오더 상태 알려줘"라고 입력하면 Joule이 orderId를 추출해 API를 호출하고 결과를 요약해 줍니다. 기존 방식이라면 사용자가 앱을 찾아 들어가 검색 조건을 입력했을 작업입니다.

2단계 — 실무: 승인 워크플로우 트리거 + 오류 처리와 로깅

조회를 넘어 처리를 자동화해 봅니다. 고액 오더에 대해 "이 오더 승인 프로세스 시작해줘"라고 하면 SAP Build Process Automation의 승인 워크플로우가 트리거되는 시나리오입니다. Action만으로 부족한 전처리(금액 검증, 로깅)가 필요하면 중간에 경량 서비스를 두는 패턴을 씁니다.

// BTP 상의 중계 서비스: Joule 스킬 → 이 엔드포인트 → SPA 워크플로우
const DEFINITION_ID = "us10.acme-spa.salesorderapproval.highValueApproval";

async function triggerApprovalProcess(req, res) {
  const { orderId, netAmount, requesterEmail } = req.body;

  // 1) 입력 검증 — Joule이 추출한 파라미터도 항상 재검증한다
  if (!orderId || typeof netAmount !== "number") {
    console.warn(`[JouleSkill] invalid payload: ${JSON.stringify(req.body)}`);
    return res.status(400).json({ message: "오더 번호와 금액이 필요합니다." });
  }
  if (netAmount < 50000) {
    return res.status(200).json({
      message: "5만 달러 미만 오더는 승인 없이 자동 처리 대상입니다." });
  }

  try {
    const spaResponse = await fetch(
      `${process.env.SPA_API_URL}/workflow/rest/v1/workflow-instances`,
      {
        method: "POST",
        headers: {
          Authorization: `Bearer ${await getOAuthToken()}`,
          "Content-Type": "application/json"
        },
        body: JSON.stringify({
          definitionId: DEFINITION_ID,
          context: { orderId, netAmount, requesterEmail }
        })
      }
    );
    if (!spaResponse.ok) {
      throw new Error(`SPA returned ${spaResponse.status}`);
    }
    const instance = await spaResponse.json();
    console.info(`[JouleSkill] approval started: ${instance.id} for ${orderId}`);
    return res.status(201).json({
      message: `승인 프로세스가 시작되었습니다. (인스턴스 ${instance.id})` });
  } catch (err) {
    // Joule 사용자에게는 친절한 문장, 로그에는 원인 전체를 남긴다
    console.error(`[JouleSkill] trigger failed for ${orderId}:`, err);
    return res.status(502).json({
      message: "승인 시스템 연결에 실패했습니다. 잠시 후 다시 시도해 주세요." });
  }
}

기존 방식이라면 사용자가 승인 요청 화면을 열고 결재선을 지정했겠지만, 여기서는 대화 한 번으로 워크플로우 인스턴스가 생성됩니다. 핵심 실무 포인트는 두 가지입니다. Joule이 추출한 파라미터도 서버 측에서 반드시 재검증할 것, 그리고 사용자 응답 메시지와 내부 로그를 분리해 장애 추적이 가능한 로깅을 남길 것.

3단계 — 프로덕션: 인증·보안·테스트 체계화

운영 전환 시에는 하드코딩된 인증 대신 BTP 데스티네이션에 OAuth 2.0 Client Credentials를 위임하는 구성이 권장됩니다.

{
  "Name": "SPA_APPROVAL_DEST",
  "Type": "HTTP",
  "URL": "https://spa-api-gateway.cfapps.us10.hana.ondemand.com",
  "ProxyType": "Internet",
  "Authentication": "OAuth2ClientCredentials",
  "tokenServiceURL": "https://acme-prod.authentication.us10.hana.ondemand.com/oauth/token",
  "clientId": "sb-salesorder-approval!b1234|xsuaa!b5678",
  "clientSecret": ""
}

운영 체크리스트는 다음과 같습니다.

• 보안 — 시크릿은 데스티네이션/자격 증명 저장소에 보관하고 코드·환경 변수 노출 금지. 트랜잭션성 스킬(승인 시작 등)은 역할 컬렉션으로 사용 가능 사용자를 제한
• 성능 — Joule 응답 체감을 위해 백엔드 API는 수 초 내 응답이 바람직. 무거운 처리는 워크플로우로 비동기 위임하고 "시작되었습니다"만 즉시 반환
• 테스트 — 발화 변형 테스트가 중요. "승인 올려줘", "결재 시작", "approve this order"처럼 표현을 바꿔가며 스킬 매칭과 파라미터 추출을 검증하고, 미매칭 발화 사례를 스킬 설명 개선에 반영
• 감사 추적 — 누가 어떤 발화로 어떤 프로세스를 트리거했는지 로그로 남겨 기존 변경 이력 관리 수준을 유지

⚠️ 자주 겪는 문제와 해결 방향

Q1. Joule 아이콘은 보이는데 아무 응답이 없거나 로그인 오류가 납니다.
대부분 IAS 신뢰 구성 문제입니다. Joule을 구독한 서브어카운트와 백엔드 제품이 같은 IAS 테넌트를 바라보는지, 사용자 이메일이 양쪽에서 동일 식별자로 매핑되는지 확인하세요. 포메이션 구성 누락도 흔한 원인입니다.

Q2. Joule Studio에서 만든 스킬이 대화에서 인식되지 않습니다.
스킬은 저장만으로는 노출되지 않고 배포(릴리스)까지 완료되어야 합니다. 배포했는데도 매칭이 안 되면 스킬 설명이 너무 모호한 경우가 많습니다. "오더 처리"보다 "판매 오더 번호로 배송·청구 상태를 조회한다"처럼 구체적으로 쓰면 인식률이 눈에 띄게 달라집니다.

Q3. 조회는 되는데 워크플로우 트리거만 403 오류가 납니다.
Action이 사용하는 기술 사용자(또는 전달된 사용자 토큰)에 SPA 측 트리거 권한이 없는 경우입니다. XSUAA 스코프와 역할 컬렉션 할당을 확인하세요. Joule은 권한을 우회하지 않으므로, 화면에서 못 하는 작업은 대화로도 실패하는 것이 정상 동작입니다.

Q4. 한국어로 물어봐도 되나요?
Joule의 지원 언어는 지속 확대되고 있으나 제품·시점별로 범위가 다릅니다. 운영 적용 전 해당 제품 문서에서 언어 지원 현황을 확인하는 것이 안전합니다.

🚀 여기서 더 확장해 볼 주제

조회·트리거 자동화가 손에 익었다면, 여러 단계를 자율적으로 수행하는 Joule 에이전트(Joule Studio의 에이전트 빌더), SAP Task Center와 연계한 크로스 시스템 승인 통합, SAP Build Apps로 만든 커스텀 앱에 Joule을 임베드하는 패턴으로 확장할 수 있습니다. btpstacks의 기존 글 중 Joule의 ABAP 코딩 지원, Joule과 SAP AI Core 비교 글을 함께 보면 개발 지원과 프로세스 자동화라는 두 축이 어떻게 나뉘는지 그림이 완성됩니다.

📚 더 읽어볼 문서

• SAP Help Portal — Joule 제품 문서
• SAP Help Portal — SAP Build Process Automation
• SAP Help Portal — Joule Studio (SAP Build)
• SAP Help Portal — SAP Cloud Identity Services (IAS)
• SAP Discovery Center — Joule 서비스 카탈로그
• SAP Community — Joule 토픽