AutoScheduler.AI는 2026년 9월 21일 AI 앱 빌더를 발표하면서 이 기능이 Warehouse AI Platform에서 일반적으로 이용 가능하다고 밝혔다. 물류창고 직원은 플랫폼에 연결된 운영 데이터와 최적화 도구를 이용해 일상적인 언어로 애플리케이션을 설명한다. 회사는 적합한 앱이 작업을 실행하도록 창고 관리 시스템(WMS)에 업무를 보낼 수도 있다고 말한다. 자세한 내용은 회사 발표에서 확인할 수 있다
현장 관리자에게는 근무 중 발견한 문제의 세부 사항이 아직 생생할 때 이를 유용한 도구로 바꿀 기회다. 그 도구가 경고를 표시할지, 변경을 권고할지, 작업을 생성할지는 별도의 운영상 결정이다. 애플리케이션이 재고 이동에 영향을 주면 오류로 귀중한 공간과 현장 직원의 시간이 소모될 수 있다.
큰 변화
- 무엇이 바뀌었나: AutoScheduler는 이제 물류창고 팀이 연결된 플랫폼 안에서 자연어 요청을 사용해 애플리케이션을 만들 수 있다고 밝혔다. 이는 발표된 기능이지, 운영 개선을 독립적으로 측정한 결과는 아니다.
- 왜 중요한가: 현장 지식이 더 빨리 유용한 소프트웨어가 되어 일반 화면에서는 놓치는 예외를 팀이 찾아내도록 도울 수 있다. 작업을 생성하는 앱은 기존 계획과 권한도 존중해야 한다.
- 지켜볼 점: 앱이 불필요한 재고 이동이나 피할 수 있는 취급 작업, 교대 근무 중 다른 문제를 만들지 않으면서 특정 지연을 줄이는지 확인해야 한다.
물류창고의 의미 체계는 화면만큼 중요하다
AutoScheduler의 현재 구현 안내서는 기존 시스템의 읽기 권한, 공통 물류창고 개념에 맞춘 데이터 매핑, 현장 규칙을 아는 운영자와의 검증을 설명한다. 또한 앱 구축과 전체 운영을 모델링하고 최적화하는 별도 범위의 작업을 구분한다. 이는 공급업체가 설명한 절차이지 우리가 설치된 시스템을 평가한 결과는 아니다. 자세한 내용은 플랫폼 구현 안내서에서 확인할 수 있다
재고를 공통 기준으로 정의하는 일은 특히 중요하다. ‘사용 가능’이라고 표시된 수량은 실제로 현장에 있는 재고, 특정 주문에 사용할 수 있는 재고, 아직 입고를 기다리는 재고를 뜻할 수 있다. 앱이 필드를 읽을 수 있다고 해서 이런 의미를 서로 바꿔 써도 되는 것은 아니다.
Microsoft의 재고 문서는 구체적인 사례를 보여 준다. Microsoft 시스템은 이미 보유한 재고와 주문했지만 아직 입고되지 않은 재고를 예약할 수 있다. 또한 특정 판매 주문을 위해 예약한 재고는 해당 예약을 취소하지 않는 한 다른 주문에 쓰이지 않도록 보호한다. 이는 Dynamics 365에 문서화된 동작이지 AutoScheduler와의 연동을 입증하는 자료는 아니다. 자세한 내용은 재고 예약 문서에서 확인할 수 있다
앱 빌더가 얻을 교훈은 물류창고의 전문 지식이 데이터 모델에 반영돼야 한다는 것이다. 직원은 계산에 어떤 수량을 사용할지, 그 상태가 어떤 조치를 허용하는지 합의해야 한다. 여러 종류의 재고를 합산하는 화면은 안심을 줄 수 있지만 피킹 위치에서는 필요한 재고를 사용할 수 없을 수 있다.
숙련된 계획 담당자는 유용한 조기 경보와 불필요한 추적 업무를 자주 일으키는 수치를 구분할 수 있다. 그 담당자가 애플리케이션을 직접 설계하는 데 참여하면 팀은 문제를 설명하고 오해를 바로잡는 시간을 줄일 수 있다. 이점은 기록으로 검증할 수 있는 구체적인 차이를 정확히 포착하는 데서 나온다.
이미 보충 작업이 등록된 품절 위험
의도적으로 단순화한 사례를 보자. 피킹 위치에 사용할 수 있는 상자는 18개다. 출고 마감 전에 주문을 처리하려면 42개가 필요하다. 다른 24개를 보충하는 작업이 이미 등록돼 있고 위치의 수용량은 48개다. 모든 수량의 단위는 같다. 이는 설명을 위한 예시 수치이지 고객 사례나 신제품 테스트 결과가 아니다.
현재 재고와 수요만 비교하는 앱은 24개가 부족하다고 판단한다. 자동으로 24개를 더 요청하면 이미 계획된 작업이 중복된다. 두 보충 물량이 피킹이 시작되기 전에 모두 도착하면 결과적으로 66개가 되어 위치의 수용량 48개를 초과한다. 계산 자체는 맞지만, 기존 약속과 실제 이동 시점을 고려하지 않은 결정이다.
더 유용한 모니터는 부족분과 함께 아직 처리되지 않은 보충 작업도 보여 줄 것이다. 그다음 작업이 재고가 필요해지기 전에 끝날 가능성이 있는지 확인할 수 있다. 작업이 늦어지면 계획 담당자는 이유를 조사하거나 승인된 우선순위 변경을 요청할 수 있다. 재고 이동을 하나 더 만드는 것이 반드시 지연을 해결하지는 않는다.
기존 물류창고 소프트웨어에는 이미 관련 계획 로직이 들어 있다. Microsoft의 보충 문서는 템플릿을 통해 설정하는 수요 기반 전략과 최소·최대 전략을 설명한다. 특정 설정에서는 수요에 따라 보충할 때 기존 보충 작업에 예약되지 않은 수량을 반영할 수 있다. 이는 WMS 주변에 두 번째 의사결정 도구를 추가하기 전에 WMS 설정을 확인하라는 뜻이다. 자세한 내용은 보충 개요에서 확인할 수 있다
앱은 예외 상황을 명확히 보여 줄 수 있다. 주문에 필요한 보충 작업이 예상대로 진행되지 않았다는 점이다. 이 관계를 표시하면 계획 담당자가 여러 화면을 대조하는 일을 줄일 수 있다. 관련 기록이 얼마나 최근에 갱신됐는지도 보여 줘야 한다. 이동 완료를 확인하는 정보가 도착하지 않았다고 해서 이미 끝난 작업을 조용히 누군가를 다시 보내야 할 이유로 삼아서는 안 된다.
수용량 때문에 보충 작업이 대기하는 것은 타당할 수 있다. Dynamics 365는 위치의 수용량을 넘어서는 작업을 만들되 재고가 충분히 줄어들 때까지 완료 처리를 보류하는 기능을 문서화한다. 계획 수요가 특정 시점의 공간을 초과할 수 있다. 자세한 처리 방식은 위치 수용량 관련 안내서에서 확인할 수 있다
그러므로 이 사례에서 미처리 작업은 먼저 상태를 살펴봐야 할 이유다. 대기 중인 작업을 모두 실패로 표시하는 앱은 직원에게 합리적인 제약을 무시하도록 압력을 줄 수 있다. 경고와 함께 제공되는 설명은 그 운영상 가치의 일부다.
앱을 게시할 권한과 작업을 생성할 권한은 다르다
AutoScheduler의 구현 안내서는 별도의 접근 권한, 지정된 운영 책임자, 실제로 보내지 않고 작업을 시험하는 방법을 설명한다. 자주 묻는 질문에서는 연결된 시스템에서 동작을 실행하려면 사전에 승인된 작업에 대해 해당 기능을 의도적으로 켜야 한다고 밝힌다. 이런 문서화된 통제는 제품을 평가할 때 중요하지만, 특정 현장의 설정과 실제 존재 여부는 따로 확인해야 한다. 자세한 내용은 작업 및 거버넌스 안내에서 확인할 수 있다
보충 모니터의 초기 범위는 위험이 있는 작업을 표시하고 계획 담당자에게 알리는 정도로 정할 수 있다. 그러면 현장에 재고 이동을 추가하지 않고도 로직이 의미 있는 예외를 찾아내는지 확인할 수 있다. 이후 현장에서 작업 생성이나 우선순위 변경을 승인한다면, 어떤 조치가 허용되는지와 WMS에 지시가 도착할 때에도 어떤 조건이 충족돼야 하는지 명시해야 한다.
요청을 받는 시스템도 중요하다. 애플리케이션이 앞서 관찰한 상태는 지시를 보낼 때 이미 오래된 정보일 수 있다. 다른 사용자가 작업을 바꾸거나 재고를 예약했을 수도 있다. 연동 시스템은 현재 상태를 확인하고 요청이 승인됐는지, 거부됐는지, 추가 확인이 필요한지 알려야 한다. 요청을 성공적으로 제출했다는 사실만으로 물류창고에서 재고 이동이 실제로 이뤄졌다고 볼 수 없다.
애플리케이션을 꺼도 한계가 있다. 설계에 따라 이후의 요청은 막을 수 있지만 이미 이동한 상자를 물리적으로 되돌릴 수는 없다. 배정이 끝난 작업은 현장의 통상적인 운영 절차에 따라 조율해 결정해야 한다. 앱 책임자는 특히 앱을 만든 사람이 자리에 없을 때 누가 그 결과를 처리하는지 알고 있어야 한다.
현장 개선책은 같은 자원을 놓고 경쟁할 수 있다
이 도구가 반복해서 나타나는 명확한 누락을 다룬다면 낙관적인 전망이 가장 설득력 있다. 계획 담당자가 일반 대시보드에 분명하게 표시되기 전에 특정 유형의 보충 작업이 긴급해지는 것을 발견한다고 하자. 집중된 모니터는 반복 조사를 줄일 수 있도록 충분한 맥락과 함께 이를 더 일찍 보여 줄 수 있다. 예외를 잘 아는 직원은 근무 중 사용하는 정보를 더 직접적으로 개선할 방법을 얻을 수 있다.
비관적인 경우는 각각 그럴듯한 앱들이 우선순위를 계속 바꾸는 상황이다. 하나는 보충을 앞당기고, 다른 앱은 출고 작업을 가속하며, 세 번째는 입고를 우선시한다. 각 앱이 같은 인력이나 장비를 사용할 수 있다고 가정한다면 하나의 대기열을 개선해도 다른 작업은 계속 기다릴 수 있다. 공통 데이터 원천만으로는 서로 경쟁하는 목표가 해결되지 않는다.
현장 책임자는 여러 애플리케이션 사이의 충돌을 누가 해결할지 정해야 한다. 더 넓은 계획이 더 중요한 마감 기한을 위해 자원을 남겨 두는 동안 한 도구는 이동을 앞당기라고 권할 수 있다. 이런 불일치에는 운영상의 설명이 필요하다. 직원은 어떤 권고가 왜 현장에서 실행하기 어려웠는지 알릴 수 있어야 한다. 그래야 현지에는 유용했던 예외가 계속 오해를 일으키는 규칙으로 굳어지지 않는다.
앱이 줄이려는 지연을 측정하라
출시는 제품의 기능에 관한 주장을 뒷받침할 뿐 다른 물류창고에서 얻을 이익의 규모를 입증하지는 않는다. 관리자는 더 좁은 질문으로 보충 앱을 평가할 수 있다. 재고가 늦게 도착해 생기는 피킹 중단을 줄였는가? 다른 곳에서 불필요한 취급 작업이나 놓친 약속을 늘리지는 않았는가?
그런 평가에는 어떤 경고가 개입으로 이어졌는지, 관련 작업에 무슨 일이 있었는지, 개입이 유용했는지에 관한 기록이 필요하다. 앱이 조용하다고 해서 문제를 놓치고 있을 수 있고, 경고가 잦다고 해서 작업을 불필요하게 만들고 있을 수 있다. 승인된 권고뿐 아니라 무시된 경고도 표본으로 검토하고, 수요와 인력 차이를 고려해 여러 교대 근무를 비교해야 한다.
데이터 매핑, 권고 검증, 도구 유지 비용과 함께 앱을 만드는 데 쓴 시간도 비용 계산에 포함해야 한다. 첫 버전이 가시성만 높이더라도 더 빠르게 만들 가치가 있을 수 있다. 그러나 그 지속 비용을 정당화할 만큼 누군가가 더 나은 물류창고 결정을 자주 내리도록 도와야 한다.
다음 시연에서는 보충 작업이 이미 진행 중인 품절 사례를 앱 빌더에 제시하라. 그 작업이 지연되거나 완료되거나 수용량 제약에 막혔을 때 어떻게 해야 하는지 설명하게 한다. 그러면 세련된 화면을 얼마나 빨리 만드는지보다 실제 유용성을 더 잘 알 수 있다.
