Joule 프롬프트 실수 금지 — 패턴 3가지 #shorts #SAP #Joule

개요: 왜 Joule에게 같은 질문을 해도 결과가 다를까

SAP Joule은 S/4HANA Cloud, SuccessFactors, SAP Build 등 SAP 애플리케이션 전반에 탑재되는 AI 코파일럿입니다. 그런데 실무에서 Joule을 도입한 팀들이 공통적으로 겪는 문제가 있습니다. "분명히 되는 기능인데 Joule이 엉뚱한 화면을 열어준다", "어제는 됐는데 오늘은 안 된다"는 불만입니다. 이 중 상당수는 Joule의 한계가 아니라 프롬프트 작성 방식에서 비롯됩니다. 이 글에서는 실전에서 반복적으로 관찰되는 세 가지 잘못된 프롬프트 패턴을 분석하고, Joule의 내부 처리 방식을 근거로 개선 방법을 제시합니다.

Joule이 프롬프트를 해석하는 단계(라우팅 → 스킬 매칭 → 파라미터 추출)를 이해한다
모호한 지시어, 다중 의도, 비표준 용어라는 3대 실수 패턴을 구분한다
각 패턴을 개선 전/후 프롬프트로 비교하며 교정 요령을 익힌다
Joule Studio 커스텀 스킬 설계 시 프롬프트 실패를 줄이는 방어적 설계를 적용한다

시작 전에 갖추면 좋은 배경

이 글은 중급자 대상입니다. SAP BTP 계정 구조(글로벌 계정/서브계정)와 Fiori Launchpad 사용 경험이 있고, Joule을 최소 한 번이라도 활성화해 본 독자를 가정합니다. Joule Studio로 커스텀 스킬을 만들어 본 경험이 있다면 3번째 패턴을 더 깊이 이해할 수 있지만, 필수는 아닙니다. LLM의 일반적인 동작(토큰, 의도 분류) 개념을 알고 있으면 도움이 됩니다.

테스트 환경

이 글의 내용은 다음 환경을 기준으로 작성되었습니다.

구성 요소	버전/에디션	비고
SAP S/4HANA Cloud Public Edition	2508 기준	Joule 내장 시나리오
SAP BTP	Multi-Environment 서브계정	Joule 활성화 및 Unified Customer Landscape 연결
Joule Studio (SAP Build)	2025년 하반기 기능 세트	커스텀 스킬 제작
Identity Authentication (IAS)	테넌트 연동 완료 상태	Joule SSO 전제 조건

Joule은 클라우드 제품이라 기능이 분기마다 업데이트됩니다. 특히 자연어 이해 품질과 지원 시나리오 범위는 릴리스마다 달라질 수 있으므로, 실제 적용 전 자신의 테넌트 릴리스 노트를 확인하는 것이 권장됩니다. 언어 설정도 중요합니다. Joule의 다국어 지원 범위는 시나리오별로 다르며, 일반적으로 영어 프롬프트의 스킬 매칭 정확도가 가장 안정적입니다.

Joule은 프롬프트를 어떻게 읽는가

개선 방법을 이해하려면 먼저 Joule이 일반 챗봇과 어떻게 다른지 알아야 합니다. ChatGPT 같은 범용 LLM은 프롬프트 전체를 하나의 생성 요청으로 처리하지만, Joule은 디스패처(교환원) 구조에 가깝습니다. 회사 대표전화에 전화를 걸면 교환원이 용건을 듣고 담당 부서로 연결해 주는 것과 같습니다. 용건이 모호하면 엉뚱한 부서로 연결되고, 용건이 두 개면 한 부서로만 연결됩니다.

Joule의 처리 흐름을 단순화하면 다음 세 단계입니다.

의도 분류(라우팅): 프롬프트가 트랜잭션형(무언가를 실행), 정보형(무언가를 조회), 분석형(수치를 집계), 내비게이션형(화면 이동) 중 어디에 해당하는지 판단합니다.
스킬 매칭: 분류된 의도를 현재 사용자에게 활성화된 스킬(내장 시나리오 + Joule Studio 커스텀 스킬) 목록과 대조합니다. 이때 사용자의 권한(Role)과 스코프가 필터로 작동합니다. 권한이 없는 스킬은 후보에서 아예 제외됩니다.
파라미터 추출(슬롯 채우기): 매칭된 스킬이 요구하는 입력값(날짜, 코드, 수량 등)을 프롬프트에서 추출합니다. 추출에 실패하면 되묻거나, 더 나쁜 경우 잘못된 기본값으로 진행합니다.

여기서 핵심 통찰이 나옵니다. 프롬프트 실패의 대부분은 3단계가 아니라 1~2단계에서 발생합니다. 사용자는 "Joule이 내 질문을 이해 못 했다"고 느끼지만, 실제로는 질문을 이해하고도 잘못된 스킬로 라우팅했거나, 매칭 가능한 스킬을 찾지 못해 일반 지식 응답(그라운딩되지 않은 답변)으로 폴백한 경우가 많습니다. 이 폴백 응답은 그럴듯해 보이지만 실제 시스템 데이터와 무관할 수 있어, 실무에서는 가장 위험한 실패 유형입니다.

비유하자면, Joule에게 보내는 프롬프트는 "대화"가 아니라 "작업 지시서"에 가깝습니다. 지시서에 담당 부서(의도), 대상(엔티티), 조건(파라미터)이 명시될수록 라우팅 정확도가 올라갑니다.

실전: 자주 틀리는 프롬프트 패턴 3가지와 교정

이제 가상의 물류 회사 시나리오로 세 가지 패턴을 살펴봅니다. 이 회사는 S/4HANA Cloud에서 입고 검수를 관리하고, Joule Studio로 커스텀 스킬 DockReceiptCheck(입고 검수 조회)와 ReorderDraftCreate(재주문 초안 생성)를 배포해 운영 중이라고 가정합니다.

패턴 1 — 기본: 지시 대상이 없는 모호한 프롬프트

가장 흔한 실수입니다. 사람끼리는 통하는 생략 화법을 Joule에게 그대로 씁니다.

잘못된 프롬프트:
"어제 그거 처리 안 된 것들 보여줘"

개선된 프롬프트:
"어제(2026-08-12) 입고된 검수 대기 상태의 입고 문서 목록을 보여줘.
플랜트는 KR01, 상태는 '검수 미완료' 기준으로."

왜 틀렸는가: "그거"와 "처리 안 된 것"은 의도 분류 단계에서 어떤 스킬과도 강하게 매칭되지 않습니다. Joule은 세션 내 직전 대화 맥락을 일부 참조하지만, 새 세션이거나 앞선 대화가 다른 주제였다면 참조할 맥락 자체가 없습니다.

Joule의 오해석 방식: 매칭 신뢰도가 낮으면 Joule은 (a) "무엇을 도와드릴까요?"라고 되묻거나, (b) 가장 신뢰도가 높은 엉뚱한 스킬로 라우팅하거나, (c) 일반 지식 응답으로 폴백합니다. (b)의 경우 "처리"라는 단어 때문에 결재 관련 스킬이 열리는 식의 오작동이 발생합니다.

교정 요령: 프롬프트에 비즈니스 객체명 + 상태 + 기간 + 조직 단위 네 가지를 명시합니다. 특히 "어제", "최근" 같은 상대 날짜는 세션에 따라 해석이 흔들릴 수 있으므로, 정확성이 중요한 업무에서는 절대 날짜를 병기하는 습관이 권장됩니다.

패턴 2 — 실무: 한 프롬프트에 두 개 이상의 의도 섞기

업무가 바쁘면 사람은 지시를 묶어서 던집니다. 하지만 Joule의 라우팅은 일반적으로 프롬프트당 하나의 스킬을 선택합니다.

잘못된 프롬프트:
"KR01 플랜트 검수 미완료 건 보여주고, 3일 넘은 건은
재주문 초안 만들어서 담당자한테 알려줘"

개선된 프롬프트 (순차 분리):
1단계: "KR01 플랜트의 검수 미완료 입고 문서 중
        입고일이 3일 이상 경과한 건을 보여줘"
2단계: (결과 확인 후) "이 중 문서번호 5100482요 건으로
        재주문 초안을 생성해줘"
3단계: "방금 생성한 재주문 초안 번호를 알려줘"

왜 틀렸는가: 위 프롬프트에는 조회(DockReceiptCheck), 생성(ReorderDraftCreate), 알림 발송이라는 세 가지 의도가 있습니다. 알림 발송 스킬이 애초에 배포되어 있지 않다면 세 번째 의도는 매칭 대상조차 없습니다.

Joule의 오해석 방식: 다중 의도 프롬프트에서 Joule은 보통 가장 신뢰도 높은 하나의 의도만 실행합니다. 문제는 어느 의도가 선택될지 예측하기 어렵다는 점입니다. 조회만 실행되고 생성이 누락되면 사용자는 "재주문이 만들어졌겠지"라고 착각한 채 화면을 닫습니다. 이것이 실무에서 가장 뼈아픈 조용한 부분 실패(silent partial failure)입니다. 반대로 생성형 의도가 먼저 잡히면, 조건 검증 없이 재주문 초안이 만들어지는 역방향 사고도 가능합니다.

교정 요령: 조회 → 확인 → 실행의 3단계로 분리하고, 트랜잭션형 프롬프트에는 반드시 앞 단계에서 확인한 구체적 식별자(문서번호)를 넣습니다. 로깅 관점에서도 분리가 유리합니다. 단계별 프롬프트는 Joule 대화 이력에서 어떤 요청이 어떤 결과를 냈는지 1:1로 추적되므로, 문제 발생 시 원인 규명이 빨라집니다. 팀 차원에서는 "생성/변경/삭제 프롬프트는 단독 문장으로 작성한다"를 사용 가이드에 명문화하는 것이 좋습니다.

패턴 3 — 프로덕션: 사내 은어와 비표준 용어로 커스텀 스킬 호출

커스텀 스킬을 배포한 조직에서 두드러지는 패턴입니다. 현업은 시스템 용어가 아니라 사내 은어로 말합니다.

잘못된 프롬프트:
"급구건 리오더 돌려줘"   ← '급구건'은 사내에서만 통하는 긴급 발주 은어

개선된 프롬프트:
"긴급 우선순위(priority: URGENT)로 자재 RM-2044의
재주문 초안을 수량 500 EA로 생성해줘"

왜 틀렸는가: "급구건", "리오더 돌리다" 같은 표현은 스킬 정의에 등록된 발화 예시(utterance)나 설명(description)과 어휘적으로 겹치지 않습니다. LLM 기반 매칭이 어느 정도 유연성을 갖더라도, 학습 맥락에 없는 조직 고유 은어는 신뢰도를 크게 떨어뜨립니다.

Joule의 오해석 방식: 스킬 매칭 실패 후 일반 지식 폴백이 발동하면, Joule이 "재주문이란 무엇인가"류의 일반론을 답하는 황당한 상황이 벌어집니다. 더 위험한 경우는 부분 매칭입니다. "리오더"가 ReorderDraftCreate에 약하게 매칭됐지만 수량·자재코드 슬롯이 비어 있어, Joule이 되묻는 과정에서 사용자가 대충 답하면 잘못된 파라미터로 초안이 생성될 수 있습니다.

교정 요령 — 사용자 측: 커스텀 스킬을 호출할 때는 스킬 설명에 쓰인 표준 용어(자재코드, 수량+단위, 우선순위 값)를 그대로 사용합니다. 파라미터는 이름: 값 형태로 명시하면 슬롯 추출 정확도가 올라갑니다.

교정 요령 — 스킬 설계자 측(프로덕션 방어 설계): 근본 해결은 스킬 정의 단계에 있습니다. Joule Studio에서 스킬을 만들 때 발화 예시에 사내 은어 변형을 미리 등록하고, 필수 파라미터에 검증 규칙을 걸어야 합니다. 다음은 방어적으로 설계된 스킬 정의의 개념 예시입니다.

# Joule Studio 커스텀 스킬 정의 (개념 예시)
skill:
  name: ReorderDraftCreate
  description: >
    자재 재주문 초안을 생성한다. 긴급 발주, 급구, 리오더,
    재발주 요청을 포함한다.          # 은어를 설명에 흡수
  sample_utterances:
    - "자재 {materialCode} 재주문 초안 만들어줘"
    - "급구건으로 {materialCode} 리오더 생성"   # 은어 변형 등록
  parameters:
    - name: materialCode
      required: true
      validation: "^RM-[0-9]{4}$"     # 형식 검증으로 오입력 차단
    - name: quantity
      required: true
      confirm_before_execute: true    # 실행 전 확인 단계 강제

보안 관점도 놓치지 마세요. 생성·변경형 스킬에는 실행 전 확인(confirmation) 단계를 넣고, 스킬 자체를 역할 기반으로 스코핑해 권한 없는 사용자의 프롬프트가 아예 매칭되지 않도록 하는 것이 일반적인 권장 사항입니다. 배포 전에는 은어·오타·다국어 혼용 프롬프트 20~30개로 구성된 테스트 세트를 만들어 매칭 성공률을 측정하고, 릴리스마다 회귀 테스트를 돌리는 운영 체계를 갖추면 프롬프트 품질 문제를 조기에 잡을 수 있습니다.

삽질 노트

Q1. 프롬프트를 정확히 썼는데도 "해당 요청을 처리할 수 없습니다"라고 나옵니다.

프롬프트 문제가 아니라 스코프 문제일 가능성이 높습니다. Joule 스킬 매칭은 사용자 권한으로 필터링되므로, 해당 시나리오의 비즈니스 역할(Business Role)이 할당되어 있는지, BTP 서브계정에서 해당 애플리케이션이 Joule에 연결(formation)되어 있는지 순서로 확인하세요. 관리자 화면에서 되고 일반 사용자 화면에서 안 되면 거의 확실히 권한 스코핑 문제입니다.

Q2. 같은 프롬프트인데 한국어로 하면 실패하고 영어로 하면 됩니다.

시나리오별 언어 지원 범위 차이 때문일 수 있습니다. 다국어 지원은 시나리오마다 롤아웃 시점이 다르므로, 중요 업무 프롬프트는 테넌트 릴리스 노트에서 해당 언어 지원 여부를 확인하고, 미지원이라면 당분간 영어 프롬프트 템플릿을 팀에 배포하는 것이 현실적입니다. 커스텀 스킬이라면 발화 예시를 한국어로도 등록했는지 점검하세요.

Q3. Joule이 그럴듯한 답을 줬는데 실제 데이터와 다릅니다.

패턴 1·3에서 설명한 일반 지식 폴백입니다. 응답에 문서번호, 실제 수치, 화면 링크 같은 시스템 근거가 없다면 그라운딩되지 않은 답변으로 의심해야 합니다. 프롬프트에 비즈니스 객체명과 식별자를 명시해 재질문하고, 그래도 반복되면 해당 조회 시나리오가 테넌트에 활성화되어 있는지 확인하세요.

Q4. 다중 의도 프롬프트를 꼭 자동화하고 싶습니다.

대화로 묶지 말고 자동화 계층으로 내리는 것이 맞습니다. Joule Studio에서 스킬이 SAP Build Process Automation 프로세스를 호출하도록 구성하면, 사용자는 단일 의도 프롬프트 하나만 던지고 조회→생성→알림의 연쇄 작업은 프로세스가 처리합니다.

더 파볼 주제

이 글에서 다룬 세 패턴은 Joule 활용의 입구에 해당합니다. 다음 주제로 확장해 보세요. 첫째, Joule Studio의 AI Agent 기능으로 다단계 추론이 필요한 작업을 위임하는 방법. 둘째, Generative AI Hub와의 연계로 커스텀 스킬 내부에서 프롬프트 템플릿을 버전 관리하는 방법. 셋째, 팀 차원의 프롬프트 가이드 문서화 — 이 글의 "객체명+상태+기간+조직단위" 공식을 조직 표준으로 정착시키면 도입 초기 혼란을 크게 줄일 수 있습니다.

댓글 0