삼성전기 SAP SCM 챗봇 구축 참여

고객

삼성전기

분야

전자부품 제조 · SCM

역할

데이터 계층 설계 · 구현, 챗봇 연동 · 유지보수

상태

2026년 9월 구축 · 유지보수 중

생산계획·목표·재공·실적 같은 SCM 데이터가 여러 입력과 서로 다른 단위에 흩어져 있었습니다. 질문 하나에도 담당자가 여러 조회를 알맞게 조합해야 해서 현업은 담당자를 기다려야 했고, 사람마다 조합이 달라 같은 질문에 다른 숫자가 나올 수 있었습니다. 챗봇이 정확히 답하려면 먼저 ‘어디서 무엇을 읽을지’가 하나로 정해져야 했습니다.

1. 01 통합 조회 창구

   기존 문제

   데이터마다 필드와 기간 형식, 단위가 달라서 목표와 실적을 비교하려면 서로 다른 조회를 맞춰 붙여야 했습니다. 하루에도 여러 번 올라오는 계획은 잘못 합치면 두 번 더해질 수 있었습니다.

   구현한 기능

   흩어진 SCM 데이터를 같은 필드·기간 형식·단위로 맞춰 한 모양으로 묶은 통합 조회 창구를 만들었습니다. 한 번의 조회로 목표와 실적을 나란히 비교하고, 계획은 최신 버전만 읽습니다. 챗봇은 이 창구 하나만 읽습니다.

2. 02 챗봇이 조회할 항목과 기준

   기존 문제

   챗봇이 원천 데이터와 중간 처리 단계까지 볼 수 있으면 어떤 항목을 읽어야 할지 혼동할 수 있습니다. 항목 설명과 실제 계산이 어긋나면 그럴듯하지만 틀린 숫자로 답하게 됩니다.

   구현한 기능

   챗봇이 조회할 수 있는 항목과 각 항목의 뜻을 정해 데이터 구조 사전으로 만들었습니다. 원천 데이터와 중간 처리 단계는 직접 보여 주지 않고, 정해진 범위를 벗어난 항목을 조회하려 하면 차단합니다.

3. 03 조회 규칙과 실행 전 안전장치

   기존 문제

   문법이 맞는 조회도 틀린 답을 낼 수 있었습니다. 먼저 거른 뒤 묶으면 다른 종류의 행이 사라져 실적이 비어 나왔고, 챗봇이 평균 단가를 곱하면 금액 기준이 어긋났습니다. AI가 만든 조회를 그대로 실행하면 데이터 변경이나 주입 공격도 막을 수 없습니다.

   구현한 기능

   데이터 구조에서 나온 조회 규칙(묶은 뒤에 거르기, 금액은 다시 계산하지 않고 합산만 하기)을 챗봇에 넣고, 모든 조회에 실행 전 안전장치를 걸었습니다. 읽기만 허용하고, 사업장·제품·기간 값은 먼저 검증하며, 반환 행 수와 실행 시간에 상한을 두고, 질문 원문부터 결과까지 기록합니다.

4. 04 재공 조회 2.5초

   기존 문제

   재공 조회 한 번에 13~19초가 걸려 대화하듯 묻고 답하기 어려웠습니다. 조회와 관계없는 입력까지 함께 실행되는 것이 원인이었습니다.

   구현한 기능

   실행 계획을 측정해, 데이터 종류를 먼저 지정하면 관계없는 입력이 실행에서 빠진다는 것을 확인하고 챗봇 조회 규칙으로 고정했습니다. 재공 조회가 2.5초로 줄었고, 개선 전후 결과 차이가 0행인지 확인한 뒤 채택했습니다.

5. 05 단가 집계 배치

   기존 문제

   금액은 수량에 단가를 곱해야 나오는데, 조회할 때마다 단가를 붙이면 느려지고 계산하는 곳마다 기준이 다르면 같은 질문에 다른 합계가 나올 수 있었습니다.

   구현한 기능

   단가를 ABAP 배치로 미리 집계해 금액이 필요한 계획·목표에만 붙였습니다. 금액 기준을 한 곳에서 정하므로 같은 질문에는 같은 합계가 나옵니다.

원천 데이터에서 챗봇 답변까지 네 계층으로 나누고, 그중 챗봇이 읽는 데이터 계층과 조회 규칙을 설계하고 구현했습니다. 보안을 위해 실제 데이터 구조의 이름과 규모는 적지 않습니다.

• 데이터

  흩어진 입력을 창구 하나로

  • 한 행에는 자기 데이터만 담아 목표와 실적을 합계가 섞이지 않게 나란히 비교
  • 빈 칸은 0이 아닌 ‘없음’으로 두어, 데이터가 없으면 없다고 답하게 함
  • 단가는 필요한 경로에만 붙이고 금액 기준을 한 곳에서 정해 같은 질문에는 같은 합계
  • 하루 여러 번 올라오는 계획은 최신 버전만 읽어 이중 합산을 막음

• 챗봇

  질문을 검증된 조회로

  • 용어 정규화 → 정의·유사 사례 검색(RAG) → 검증된 예시(Few-shot) → 조회 생성 → 안전 검사 후 실행
  • 조회를 쓰는 습관은 LoRA로 학습하고, 업무 정의는 실행할 때마다 사전에서 붙임
  • 업무 정의가 바뀌면 모델을 다시 학습하지 않고 사전만 고침
  • 답마다 해석한 조건과 실행한 조회를 함께 보여 줌

• 품질

  측정한 것만 채택

  • 같은 데이터라도 조건을 거는 방식에 따라 5~8배 차이가 나는 것을 측정해 챗봇 규칙으로 고정
  • 모든 개선안은 기준선 측정 → 한 가지만 변경 → 결과 차이 0행 확인 뒤 채택. 실측이 느리면 되돌림

실제 흐름을 따른 질문 예시입니다. 보안을 위해 수치는 가공했고 제품군·사업장 이름은 가렸습니다.

• 목표 + 실적

  “8월 제품군별로 목표 대비 생산실적 달성률 보여줘”

  목표와 실적처럼 서로 다른 데이터를 한 번의 조회로 나란히 묶어, 전체 달성률과 가장 낮은 제품군, 목표를 넘은 제품군을 함께 답합니다.

• 한·영 혼용

  “A사업장 26년 8월 production plan 주차별로 알려줘”

  용어 사전이 ‘production plan’과 ‘prod plan’을 생산계획으로 해석하고, 사업장·기간·묶음 기준을 조회 조건으로 바꿉니다.

• 되묻기

  “지난주 실적 어때?”

  기준이 모호하면 추측하지 않습니다. 수량·금액·달성률 중 무엇을, 어느 범위로 볼지 되물은 뒤 조회합니다.

• 속도

  “이번 달 재공 지금 얼마나 있어?”

  데이터 종류를 먼저 지정하는 조회 규칙 덕분에 관계없는 입력은 실행 계획에서 빠져 2.5초 안에 답합니다. 같은 대상을 기존 방식으로 조회하면 13~19초가 걸렸습니다.

챗봇이 만든 조회는 모두 실행 전에 같은 안전장치를 거칩니다. 실제로 겪은 오류도 규칙으로 고정했습니다.

조회 전용

읽기만 허용하고 변경·삭제 문장은 막습니다.

창구 하나

승인된 조회 창구 하나만 이용하고 원천 데이터에는 직접 접근하지 않습니다. 미리 정한 범위를 벗어난 항목은 조회할 수 없습니다.

입력 검증

사업장·제품은 허용 목록으로, 기간은 형식으로 먼저 검증한 뒤 넣어 주입 공격을 막습니다.

틀린 합계 방지

먼저 거르면 다른 종류의 행이 사라지므로 묶은 뒤에 거릅니다. 금액은 다시 계산하지 않고 합산만 합니다.

과부하 · 감사

반환 행 수와 실행 시간에 상한을 두고, 질문 원문부터 결과까지 전 과정을 기록합니다.

원천 데이터 분석부터 구축 후 유지보수까지 맡고 있습니다.

1. 01 원천 데이터 분석
2. 02 데이터 계층 설계
3. 03 입력 · 통합 뷰 구현
4. 04 단가 집계 배치
5. 05 조회 항목과 기준 정의
6. 06 챗봇 조회 규칙
7. 07 성능 개선
8. 08 인계
9. 09 구축 후 유지보수

1. 2026.07.23

   AI 챗봇 기획

   챗봇이 읽을 데이터의 범위와 형태부터 정의

2. 2026.08.23

   통합 구조 확정

   흩어진 데이터를 한 모양으로 묶는 구조 확정

3. 2026.08.27

   단가 로직 현업 확인

   금액 기준과 단가 경로를 현업과 확인

4. 2026.09.04

   입력을 함수로 전환

   조건이 원천 가까이 전달되도록 입력을 함수로 전환

5. 2026.09.16

   재공 조회 2.5초

   데이터 종류 조건을 공개하고 챗봇 조회 규칙으로 연결

6. 2026.09.17

   마무리 · 인계

   설계 문서와 함께 현업에 인계

7. 현재

   유지보수

   구축 이후에도 유지보수를 이어가고 있습니다.

• SAP HANA
• SQLScript
• ABAP
• Llama 3.1 + LoRA
• RAG · Vector DB
• Few-shot