Semantic Layer와 No-Code AI: P&G 창고 교대 계획을 8시간에서 20분으로, 감독자는 앱 약 500개를 직접 만들었다

P&G 제조 캠퍼스 창고는 플래너가 교대마다 8시간 들여 짜던 계획을 20분짜리 자동 계획으로 바꿨습니다(벤더 설명). 어느 창고에나 있는 결정은 공통 로직으로 자동화하고 그 창고에만 있는 결정은 현장 감독자가 노코드 도구로 앱을 만들어 처리하도록 나눴습니다. 따라 하려면 데이터 정리보다 먼저 누가 어떤 결정을 무엇을 보고 내리는지 목록으로 만들어야 합니다.

요약

IIoT World의 Paul Viorel이 2026년 11월 6일 AutoScheduler.AI CEO Keith Moore의 CxO Series 영상 인터뷰(진행 Lucian Fogoros)를 기사로 정리했습니다. 무대는 P&G(Procter & Gamble) 제조 캠퍼스의 창고입니다. 이곳 플래너는 팀보다 일찍 나와 입고 배송, 출고 트럭, 생산 일정, 변동 인력을 맞춰 하루 교대 계획을 짰는데 교대 하나에 8시간이 걸렸습니다. 건물 사이를 오가는 셔틀이 제때 움직여야 생산 라인이 서지 않으니 계획은 촘촘해야 했습니다. AutoScheduler.AI는 6년 동안 Semantic Layer(창고가 가장 잘 돌아가는 방식을 구조화해 담은 지식 계층)를 만들었습니다. 여기에 WMS(창고 관리 시스템)와 ERP(전사 자원 관리) 데이터를 넣고 설비 능력과 도크 일정을 모델링한 알고리즘을 얹었습니다. 그 위에서 P&G의 교대 계획은 20분으로 줄었습니다.

시간 단축만큼 중요한 변화는 계획이 틀어진 뒤에 일어납니다. 예전 계획은 교대가 시작되고 10분이 지나기 전에 설비 고장, 결근, 트럭 지연으로 무너지기 일쑤였고 그때마다 처음부터 다시 짰습니다. 플랫폼은 창고 운영의 약 80%를 차지하는 공통 결정을 자동화하고 남은 약 20%의 시설 고유 결정을 현장 감독자에게 넘겼습니다. 코딩 경험이 없는 감독자들이 노코드 AI 빌더로 만든 맞춤 앱이 약 500개입니다. 결품 대응 앱 하나는 두 사람이 하던 일을 대신해 배포 이틀 만에 15만 달러를 아꼈다고 합니다. 수치는 모두 벤더 CEO의 설명이며 기사에 P&G 측 발언은 없습니다. 아래에서 네 가지 작동 원리와 두 사례를 본 뒤 따라 할 때 필요한 기술·현업 디테일을 붙입니다.

핵심 메커니즘

Semantic Layer: 따로 놀던 시스템의 결정을 한 지식 계층에 묶는다

Semantic Layer는 창고가 어떻게 돌아가야 가장 좋은지를 구조화된 지식으로 담은 공통 계층입니다. 출발점은 소프트웨어 구조였습니다. 인력 효율은 LMS(인력 관리 시스템)가, 재고 위치는 별도 slotting(재고를 어느 로케이션에 둘지 정하는 일) 솔루션이 맡았고 둘은 거의 대화하지 않았습니다. 그런데 작업자 효율은 재고가 어디 놓였는지, 입고 트럭이 언제 오는지에 달려 있습니다. Semantic Layer는 WMS·ERP 데이터를 받아 설비 처리 능력과 도크 일정 모델과 함께 계산해 인력·재고·도크를 한 번에 놓고 결정해 교대 계획을 내놓습니다. 결정끼리 얽혀 있는데 시스템이 나뉜 곳에서 효과가 크고 시스템 하나로 끝나는 단일 결정에는 과한 설계입니다. 가상 예시로, 입고 트럭이 40분 늦는다는 정보가 들어오면 도크 배정, 지게차 인력, 그 SKU를 잠시 둘 위치가 함께 다시 계산되는 식입니다.

80/20 Split: 공통 결정은 자동화하고 시설 고유 결정은 현장에 남긴다

Moore는 창고 결정을 둘로 나눕니다. 어느 창고에서나 같은 공통 결정이 약 80%이고 시설마다 다른 제약 때문에 표준화할 수 없는 결정이 약 20%입니다. 기사가 든 예는 특정 적재 규칙이 걸린 sorter(물품 자동 분류기)와 정해진 요일에만 도는 cross-dock(입고 물품을 보관 없이 바로 출고로 넘기는 방식) 흐름입니다. 80%는 플랫폼이 공통 로직으로 처리합니다. 20%를 IT가 하나씩 개발하면 약 6개월짜리 개발 주기를 기다려야 하므로, 이 부분은 현장으로 넘깁니다. 시설 고유 결정이 아주 적거나, 안전·규제와 묶여 현장이 바꾸면 안 되는 결정이라면 공통 로직 쪽에 두고 통제하는 편이 맞습니다.

No-Code AI Builder: 감독자가 IT 대기 없이 앱을 만든다

플랫폼은 현장 감독자에게 노코드 AI 빌더를 줬습니다. 감독자는 언제 움직일지(결품 같은 현장 이벤트), 무엇을 읽을지(SAP·ERP 데이터), 무엇을 추천할지를 코드 없이 조립합니다. 기사가 든 앱은 원자재를 특정 생산 라인으로 보내는 납품 일정 앱, 맞춤 보충(replenishment) 흐름, 결품 대체 추천 앱입니다. 코딩 경험이 없는 감독자들이 이렇게 만든 앱이 약 500개라고 합니다. 현장 규칙을 가장 잘 아는 사람이 직접 만들기 때문에 요건을 IT에 설명하고 기다리는 단계가 사라집니다. 빌더가 내부에서 어떤 모델이나 LLM을 쓰는지는 기사에서 밝히지 않았습니다.

Transparent Decision Agent: 계산 근거를 평이한 말로 남겨 베테랑이 따지게 한다

기사는 이 AI를 “transparent decision agent”라고 부릅니다. 추천을 낼 때 수학적 추론과 로직을 평이한 말로 기록합니다. 20년 차 도크 감독자는 이 기록으로 추천 이유를 끝까지 따라가 보고, trade-off(하나를 얻으려 다른 것을 포기하는 선택)에 이의를 걸고, 현장 상황에 맞게 파라미터를 고칠 수 있습니다. 베테랑 감독자가 믿지 않으면 시스템은 쓰이지 않으므로, 이 설계는 채택의 조건입니다. 가상 예시로, “3번 도크를 비워 둔 이유: 14시 트레일러 도착 예정, 지게차 2대 대기” 같은 설명이 붙으면 감독자는 트레일러가 이미 늦어졌다는 현장 정보로 바로 반박하고 계획을 고칠 수 있습니다.

통념과 다른 주장

저자가 든 사례

P&G 교대 계획: 8시간 수작업이 20분 자동 계획으로

• 상황: P&G 제조 캠퍼스 창고의 플래너가 입고·출고·생산 일정·변동 인력을 맞춰 교대마다 8시간 들여 계획을 짰습니다. 계획은 교대 시작 10분 안에 설비 고장, 결근, 트럭 지연으로 틀어지기 일쑤였습니다.
• 한 일: WMS·ERP 데이터와 설비·도크 모델을 묶은 Semantic Layer로 공통 결정을 자동화했습니다.
• 결과: 교대 계획이 20분으로 줄었습니다(벤더 설명). 적용 사이트 수, 도입 기간, 재계획 빈도는 기사에서 밝히지 않았습니다.
• 연결: Semantic Layer, 80/20 Split.

결품 대체 추천 앱: 감독자 한 명이 만든 앱이 이틀에 15만 달러

• 상황: 출고 적재분에 제품이 모자라면 두 사람이 ERP를 손으로 뒤져 대응했습니다.
• 한 일: 현장 감독자가 노코드로 앱을 만들었습니다. 결품이 나면 앱이 SAP·ERP에서 같은 고객에게 나갈 향후 출하분을 찾아 대체 제품을 추천해 fill rate(주문 충족률)를 지킵니다.
• 결과: 두 사람의 수작업을 자동화했고 배포 이틀 만에 시설이 15만 달러를 아꼈다고 합니다(벤더 설명). 절감액 산정 방식은 기사에서 밝히지 않았습니다.
• 연결: No-Code AI Builder, 80/20 Split.

기술 디테일: 창고 결정 계층을 직접 만든다면

아래 필드명, 설정값, 구성은 실행 제안이자 가상 예시입니다. 기사에서 온 내용은 따로 표시했습니다.

결정 지도를 먼저 데이터로 만듭니다(Moore의 조언, Semantic Layer). 결정 하나를 레코드 하나로 적습니다. 처음 4주는 이 표가 산출물의 전부여도 됩니다. 어떤 데이터를 정리할지는 이 표의 inputs가 정합니다.

{
  "decision_id": "DOCK-ASSIGN-01",
  "question": "다음 2시간 동안 어느 트레일러를 어느 도크에 붙이나",
  "frequency": "교대 시작 + 이벤트 발생 시",
  "owner": "교대 플래너",
  "scope": "universal",
  "inputs": ["WMS.appointments", "WMS.door_status", "ERP.production_schedule", "LMS.roster"],
  "constraints": ["도크별 트레일러 규격", "셔틀 출발 시각", "지게차 대수"],
  "objective": "라인 정지 0 우선, 다음으로 fill rate",
  "today": {"tool": "스프레드시트", "minutes_per_shift": 90}
}

scope가 universal이면 공통 로직(80%)으로, site_specific이면 현장 앱 후보(20%)로 분류합니다. today.minutes_per_shift는 효과 측정의 기준선이므로 첫 주에 실측합니다.

Semantic Layer는 객체와 관계로 짭니다. 교대(Shift), 작업자(숙련·자격), 설비(시간당 처리량·상태), 도크 도어, 트레일러 예약(ETA), SKU, 로케이션, 주문·출하, 고객을 객체로 두고 “트레일러는 도어에 붙는다”, “SKU는 로케이션에 있다” 같은 관계를 정의합니다. 기사는 설비 능력과 도크 일정을 모델링한 알고리즘을 쓴다고만 밝혔습니다. 직접 만든다면 계획 생성은 정수계획법이나 제약 프로그래밍 솔버(예: OR-Tools CP-SAT)에 맡기고 LLM은 근거를 평이한 말로 바꾸는 일과 노코드 조립 보조에 쓰는 편이 안전합니다. 같은 입력이면 같은 계획이 나와야 감독자가 결과를 비교할 수 있기 때문입니다.

10분 안에 틀어지는 계획은 이벤트로 다시 짭니다(P&G 교대 계획 사례). 기사가 든 붕괴 원인 세 가지(설비 고장, 결근, 트럭 지연)를 이벤트로 받습니다. 이벤트마다 영향받는 도크·인력·SKU만 추려 부분 재계산하고 이미 실행 중인 확정 구간(예: 다음 30분)은 고정합니다. 현장 혼선을 막으려면 한 교대에 바꾸는 배정 수에 상한(예: 작업자 1명당 2회)을 둡니다.

근거 로그는 구조화해 남깁니다(Transparent Decision Agent). 평이한 설명 문장만 저장하면 나중에 집계할 수 없습니다. 아래처럼 계산 결과를 필드로 남기고 explanation_text는 그 필드로 생성합니다.

{
  "recommendation_id": "R-2026-11-07-0412",
  "decision_id": "DOCK-ASSIGN-01",
  "binding_constraints": ["도어 3: 14:00 트레일러 예약", "지게차 가용 2대"],
  "tradeoffs": [{"gave_up": "출고 B 15분 지연", "gained": "라인 2 원자재 정시 투입"}],
  "alternatives": 3,
  "parameters": {"line_stop_weight": 10, "fill_rate_weight": 3},
  "data_snapshot_at": "2026-11-07T13:20:00",
  "explanation_text": "라인 2 정지를 막으려고 출고 B를 15분 늦췄습니다.",
  "supervisor_action": "override",
  "override_reason": "트레일러가 이미 30분 지연"
}

supervisor_action이 override인 건을 주 단위로 모으면, 어느 파라미터가 현장과 어긋나는지 보입니다. 같은 이유의 override가 반복되면 파라미터 기본값을 고칩니다. explanation_text를 LLM으로 만든다면 temperature 0으로 두고 로그 필드만 입력으로 줍니다. 생성된 문장의 숫자와 시각이 필드 값과 다르면 버리고 템플릿 문장으로 대신합니다.

노코드 앱에는 가드레일을 둡니다(No-Code AI Builder). 앱을 읽기 전용(조회·추천)과 쓰기(SAP·WMS에 반영)로 나누고 쓰기 앱은 IT 검토를 거쳐야 배포되게 합니다. 앱마다 소유자, 버전, 트리거, 읽는 테이블, 효과 측정 필드(절감 시간, 막은 결품 건수)를 카탈로그에 등록합니다. 앱이 수백 개로 늘면 같은 일을 하는 앱이 겹치므로, 트리거와 읽는 테이블이 같은 앱을 월 1회 묶어 봅니다.

결품 대체 앱을 재현한다면(결품 대체 추천 앱 사례). 트리거는 적재 확정 시점의 수량 부족입니다. 앱은 같은 고객의 향후 출하 오더를 SAP에서 찾아 고객이 허용한 대체 SKU 목록과 맞춰 후보를 만든 뒤 재고 위치와 출하일 여유로 순위를 매깁니다. 감독자가 확인하면 실행하고 대체 내역을 고객 서비스에 알립니다. 고객별 대체 허용 목록은 기사에 나오지 않은 전제 조건입니다. 목록이 없으면 앱이 잘못된 대체를 추천합니다.

막히는 경우	증상	대응
공통 로직과 현장 앱이 같은 결정을 건드림	앱이 계획을 덮어써 배정이 흔들림	결정 지도에서 결정마다 주인을 하나로 지정
실시간 데이터 지연	WMS 상태가 10분 늦게 반영돼 재계획이 늦음	data_snapshot_at을 화면에 표시, 지연 허용치 초과 시 경고
감독자가 추천을 계속 무시	override 비율이 높게 유지	override 사유를 모아 파라미터 수정, 사유 없는 무시는 교육 대상
앱 남발	같은 기능의 앱 여러 개	카탈로그 중복 점검, 사용 없는 앱 90일 뒤 보관 처리
대체 추천이 고객 계약과 충돌	허용되지 않은 SKU로 출하	고객별 대체 허용 목록을 필수 입력으로, 없으면 추천 중지

현업 실행 디테일: 누가, 언제, 무엇을

기사는 플래너가 교대 계획을 짜고, 현장 감독자가 노코드 앱을 만들고, 도크 감독자가 추천 근거를 따진다고 전합니다. 아래 역할, 일정, 기준은 이를 바탕으로 새로 짠 가상 예시입니다.

역할	맡는 일
사이트 운영 책임자	시범 범위와 목표 확정, 진행 판정, 현장 스폰서
교대 플래너 1~2명	결정 지도 작성, 수작업 기준선 측정, 자동 계획 검증
현장·도크 감독자 3~5명	시설 고유 결정 목록, 노코드 앱 제작, 추천에 대한 override와 사유 기록
IT·WMS 담당	WMS·ERP·LMS 데이터 연결, 쓰기 권한 통제, 앱 카탈로그 관리
데이터·최적화 엔지니어	Semantic Layer 객체 정의, 솔버·재계획 로직, 근거 로그
고객 서비스	고객별 대체 허용 목록 제공, 대체 출하 통보

준비물. 최근 4주의 교대 계획표와 실제 실행 기록, 플래너가 계획에 쓰는 스프레드시트 전부, 도크 예약과 트레일러 도착 실적, 설비별 처리 능력과 고장 이력, 교대별 출근·결근 기록, 결품 발생 건과 대응 기록이 필요합니다. 스프레드시트에 숨은 규칙(예: “금요일엔 3번 도크 비움”)을 찾는 데 가장 오래 걸리므로 첫 주에 플래너 인터뷰로 시작합니다.

기간	할 일	산출물
1~2주	플래너·감독자 인터뷰, 결정 지도 작성, 교대 계획 시간 실측	결정 목록(공통·시설 고유 구분), 교대당 계획 시간 기준선
3~4주	데이터 연결, 공통 결정 2~3개(도크 배정, 인력 배치)부터 자동 계획	자동 계획 초안, 근거 로그
5~7주	병행 운영(플래너 계획과 자동 계획 비교), 감독자가 현장 앱 2~3개 제작	계획 시간, 재계획 횟수, override 비율, 앱 효과 기록
8주	판정 회의, 확대 범위 결정	진행·보완·중단 결정서

현장에 물을 것.

1. 교대 계획을 짤 때 가장 먼저 확인하는 숫자는 무엇이고 어느 화면이나 파일에서 보나요?
2. 지난달 계획이 무너진 날은 며칠이고, 원인은 설비, 결근, 트럭 중 어느 쪽이 많았나요?
3. 이 창고에만 있는 규칙은 무엇이고 다른 창고로 옮기면 안 맞는 이유는 무엇인가요?
4. 지금 스프레드시트나 메모로 버티는 일 가운데 앱이 있으면 가장 먼저 만들 것은 무엇인가요?
5. AI 추천을 따르지 않을 때 그 이유를 어디에 남기고, 누가 보나요?

진행 판정 기준(예시). 병행 운영에서 교대당 계획 시간이 기준선보다 70% 이상 줄고, 감독자 override 비율이 20% 아래로 내려가며, 라인 정지나 출고 지연이 기준선보다 늘지 않으면 다음 결정과 다른 창고로 넓힙니다. 시간은 줄었는데 override가 40%를 넘으면 파라미터와 결정 지도를 고쳐 3주 더 봅니다. 시간 절감이 30%에 못 미치면 데이터 연결이나 결정 범위를 다시 잡습니다.

AX 적용 제언. 이 사례는 창고에만 해당하지 않습니다. 생산 계획, 정비 일정, 배차처럼 매일 반복되고 여러 시스템에 걸친 결정에는 같은 구조가 들어맞습니다. 순서는 결정 지도, 공통 결정 자동화, 현장 앱 순입니다. 결정 지도로 공통과 시설 고유를 먼저 가르고 공통 결정 두세 개를 근거 로그와 함께 자동화해 신뢰를 쌓은 뒤, 현장 감독자에게 노코드 도구를 엽니다. 첫 대상은 담당자가 매일 몇 시간씩 쓰고 결과가 라인 정지나 출고 지연으로 바로 드러나는 결정이 좋습니다. 현장 스폰서는 공장장이나 물류센터장이 맡아야 감독자가 시간을 냅니다. 벤더 수치는 도입 전 자사 병행 운영으로 다시 재야 합니다.

원문 사례

항목	내용
원문	IIoT World, 2026.11.6 게재, Paul Viorel 작성. CxO Series 영상 인터뷰(진행 Lucian Fogoros)를 기사로 정리
화자	Keith Moore, AutoScheduler.AI CEO(벤더). 기사에 P&G 측 발언은 없음
대상	P&G 제조 캠퍼스의 창고
이전 문제	교대 계획 교대당 8시간, 교대 시작 10분 안에 설비 고장·결근·트럭 지연으로 붕괴, 건물 사이 셔틀 시각 맞추기
원인	LMS와 slotting 솔루션 등 시스템이 따로 놀아 인력·재고·트럭 결정을 함께 풀지 못함
해법	6년 걸려 만든 Semantic Layer, WMS·ERP 데이터 + 설비 능력·도크 일정 모델
결정 분할	공통 결정 약 80% 자동화, 시설 고유 약 20%(sorter 적재 규칙, 요일별 cross-dock)는 현장
현장 앱	노코드 AI 빌더, 코딩 경험 없는 감독자가 약 500개 제작, 약 6개월 IT 개발 주기 우회
결품 앱	SAP·ERP에서 같은 고객 향후 출하분 조회, 대체 제품 추천, 2명 수작업 자동화, 배포 이틀에 15만 달러 절감
신뢰 장치	수학적 추론을 평이한 말로 기록, 추천 이유 추적, trade-off 이의, 파라미터 조정
결과	교대 계획 8시간 → 20분
도입 조언	끝없는 데이터 정리 대신 결정 지도부터, 가치 큰 영역부터 자동화, 수작업 스프레드시트 탈피

핵심 개념

WMS

Warehouse Management System. 입고, 보관 위치, 피킹, 출고 같은 창고 안 재고 이동을 기록하고 지시하는 시스템입니다.

LMS

Labor Management System. 창고 작업자의 작업량과 효율을 측정하고 작업을 배정하는 시스템입니다. 여기서는 인력 효율을 맡은 별도 시스템으로 나옵니다.

Slotting

SKU를 창고의 어느 로케이션에 둘지 정하는 일입니다. 자주 나가는 품목을 출고구 가까이 두는 식으로 이동 거리를 줄입니다.

Cross-dock

입고된 물품을 보관하지 않고 곧바로 출고 도크로 넘기는 운영 방식입니다.

Sorter

컨베이어 위 물품을 목적지별로 자동으로 나누는 설비입니다. 적재 규칙이 설비마다 다를 수 있습니다.

Fill rate

고객 주문 수량 가운데 요청대로 채워 보낸 비율입니다. 결품이 나면 떨어집니다.

Replenishment

피킹 위치의 재고가 줄면 보관 위치에서 다시 채워 넣는 작업입니다.

내 메모

TODO: 내 생각 추가

원문은 IIoT World의 「From 8 Hours to 20 Minutes: Inside P&G’s Warehouse AI Transformation」(Paul Viorel, 2026.11.6)입니다. AutoScheduler.AI CEO Keith Moore의 영상 인터뷰를 정리한 기사이고 매체는 AI 도구로 요약한 뒤 편집팀이 검토했다고 밝혔습니다. 8시간에서 20분, 약 80%, 약 500개, 15만 달러 같은 수치는 모두 벤더 측 설명이며 P&G가 직접 발표한 것은 아닙니다. 요약, 핵심 메커니즘의 원문 설명, 통념과 다른 주장, 사례, 원문 사례 표는 기사 내용을 AX Review가 다시 정리했습니다. 핵심 개념의 뜻풀이와 언제 쓰고 언제 안 쓰는지에 대한 설명은 일반적인 정의로 보탰습니다. JSON 예시, 솔버 구성, 이벤트 재계획 방식, 가드레일, 막히는 경우 표, 역할·일정·판정 기준, 인포그래픽은 기사에 없는 내용으로 새로 작성했고 그 안의 필드명과 숫자는 가상 예시입니다. 전체 내용은 원문 페이지에서 볼 수 있습니다.