공급망 제어탑은 가시성만으로는 움직일 수 없다: AI 에이전트로 가시성을 행동으로 바꾸는 3가지 설계 포인트

공급망 제어탑(Control Tower)은 ERP, WMS, TMS 등의 데이터를 통합하여 지연이나 재고 부족을 가시화합니다. 하지만 많은 현장에서는 '문제가 보이는 것'과 '해결이 따라잡지 못하는 상태'가 지속되고 있습니다.

본 기사에서는 이 '가시성과 행동의 격차(Gap)'를 메우기 위해, **3가지 종류의 AI 에이전트(감시・계획・조정)**를 어떻게 설계하고 통합하며 거버넌스해야 하는지를 시스템 아키텍처, API 연동, 권한 통제, 감사 관점에서 설명합니다. 경영론이 아닌, 엔지니어가 구현 판단을 내릴 수 있는 수준의 내용으로 작성되었습니다.

공급망은 선형적이지 않고 역동적인 네트워크입니다. 어느 한 거점의 지연이 공급업체, 공장, 창고, 운송회사, 고객에게 파급됩니다. 문제는 '파도를 감지하는 것'이 아니라, '파도가 도달하기 전에 대응하는 것'입니다.

기존 제어탑은 **상황 인식(Situational Awareness)**에 머물러 있습니다. 대시보드가 빛남 → 사람이 원인을 조사함 → 여러 시스템을 가로지름 → 이메일이나 전화로 조정함 → 이 과정은 변하지 않았습니다. 이 조정 비용이 복잡한 네트워크에서는 지수 함수적으로 증가합니다.

'데이터를 더 많이 확보하면 해결된다'는 생각은 잘못입니다. 필요한 것은, 감지를 **규율 있는 행동(Disciplined Action)**으로 전환하는 메커니즘입니다.

에이전트형 제어탑은 플래너나 물류 리더를 대체하는 것이 아닙니다. 그들이 반복적으로 수행하는 크로스 시스템 조정 작업을 자동화합니다. 구현상, 다음 3가지 에이전트가 핵심이 됩니다.

단순한 알림 발송에 그치지 않습니다. 다음과 같은 '맥락이 부여된 감지'를 수행합니다.

• '이 지연은 우선 고객 대상의 출하이다.'
• '해당 부품의 재고는 다음 보충 전에 0이 된다.'
• '이 공급업체에는 과거 3회 같은 패턴의 지연이 있다.'

설계상의 포인트:

• 이벤트 스트림(TMS의 ETA 업데이트, WMS의 재고 변동)을 실시간으로 구독합니다.
• 규칙 엔진(예: Drools / 커스텀 Python)으로 중대도 및 영향 범위를 평가합니다.
• 결과를 구조화된 예외 객체로 다음 에이전트에게 전달합니다.

# 의사 코드: 감시 에이전트의 판단 로직
def evaluate_exception(shipment, inventory, customer_priority):
if shipment.eta_delay > 4 and inventory.days_until_zero < 3:
...

예외를 감지한 후, 사람이 가장 많은 시간을 쓰는 것은 '어떻게 대응할 것인가'에 대한 비교 검토입니다. 계획 에이전트는 다음과 같은 대안을 자동으로 생성하고 트레이드오프를 제시합니다.

• 긴급 배송 (비용 증가)
• 거점 간 재고 재배치
• 대체 공급업체로 전환
• 생산 우선순위 변경

설계상의 포인트:

• 비용 모델, 서비스 수준 계약(SLA), 재고 정책을 명시적으로 모델링합니다.
• 제약 만족 문제(CSP) 또는 최적화 엔진(OR-Tools / CP-SAT)으로 해를 탐색합니다.
• 각 대안에 '비용 영향', '서비스 수준 영향', '정책 위반'을 태그로 지정합니다.

# 의사 코드: 계획 에이전트의 트레이드오프 제시
options = planning_agent.evaluate(
exception=critical_delay,
...

많은 예외는 '무엇을 해야 할지 알고 있지만, 조정이 늦어져서' 실패합니다. 조정 에이전트는 의사결정 이후를 자동화합니다.

• 공급업체에게 알리는 메일 작성 및 전송
• 창고팀에 작업 태스크 발행
• 영업 부문에 영향 통지
• 승인 워크플로우 시작
• 액션 완료 추적

설계상의 포인트:

• 각 액션에 고유한 트랜잭션 ID를 부여하고 감사 로그에 기록합니다.
• 승인이 필요한 액션은 워크플로우 엔진(Temporal / Camunda)으로 관리합니다.
• 미완료 태스크는 에스컬레이션 규칙에 따라 재통지합니다.

에이전트는 그 아래의 데이터와 통합의 질에 의존합니다. SOP 문서나 채팅 인터페이스만으로는 불충분합니다.

• 재고 업데이트가 1시간 지연되면, 에이전트는 '더 이상 불필요한 재고 재배치'를 권장한다
• 출하 ETA가 15분 지연되면, 완화 트리거가 지연된다
• 수요 예측은 일별 배치로 충분하다 (전략적 판단을 위해)

SKU의 불일치, 거점 코드의 변동성, 공급업체 계층의 모호함—이것들은 기존의 제어탑에서는 사람이 암묵적으로 보정했습니다. 에이전트형 시스템에서는 즉시 잘못된 권장 사항으로 표면화합니다.

확인 관점:

• 제품 마스터에 명확한 소유자가 있는가
• 거점 코드가 모든 시스템에서 통일되어 있는가
• 공급업체 ID에 중복이나 이력의 불일치가 없는가

높은 자율성을 목표로 하기 전에, 이러한 데이터 품질을 확보해야 합니다.

공급망 의사결정에는 재무, 계약, 평판의 무게가 있습니다. 거버넌스는 나중에 추가하는 것이 아니라, 설계의 일부로서 통합되어야 합니다.

이 프레임워크는 두 극단을 피합니다:

• 에이전트가 수동적이어서 가치를 창출하지 못함
• 제어가 갖춰지지 않은 상태에서 자율성이 너무 높음

에이전트의 판단은 기술적인 임계치뿐만 아니라, 다음 요소들을 고려해야 합니다.

# 정책 정의 예시 (YAML)
policy_gates:
- condition: "supplier_switch AND material.regulated == true"
...

감사 관점:

• 모든 에이전트 판단(권장/실행/거부)을 불변의 감사 로그에 기록 - 정책 위반이 발생한 경우, 즉시 알림 및 에스컬레이션
• 정기적인 정책 검토 프로세스 (분기별)

에이전트형 제어탑은 만능이 아닙니다. 다음 조건들이 갖춰지지 않은 경우에는, 먼저 기반을 다진 후에 고려해야 합니다.

기본 프로세스가 불안정함- 계획 수립의 규율이 약함

• 마스터 데이터가 혼란스러움
• 예외의 소유권이 불분명함

→ 에이전트는 혼란을 가속화할 뿐입니다.

핵심 시스템과의 통합이 미비함- ERP, WMS, TMS, 계획 시스템에 대한 신뢰성 있는 접근이 없음

→ 에이전트는 '통찰'에서 멈추고, '오케스트레이션'에 이르지 못합니다.

• ERP, WMS, TMS, 계획 시스템에 대한 신뢰성 있는 접근이 없음

조직이 정책 기반 의사결정에 익숙하지 않음- 많은 기업은 공급망에서 개인의 영웅주의에 의존하고 있습니다

→ 에이전트에게는 일관된 운영 역할이 필요합니다.

• 많은 기업은 공급망에서 개인의 영웅주의에 의존하고 있습니다

교차 기능적 거버넌스가 존재하지 않음- 공급망의 예외는 조달, 제조, 물류, 영업, 재무에 걸쳐 발생합니다

→ 국지적으로 올바른 권장 사항이라도 조직적으로 실행할 수 없습니다.

현재의 제어탑은 문제를 더 빨리 보여줄 수 있게 되었습니다. 그러나 그 이후의 조정 비용은 변하지 않았습니다. 다음 단계는 다른 대시보드가 아니라, 감시/계획/조정의 3가지 에이전트로 제어탑을 오케스트레이션 레이어로 재설계하는 것입니다.

엔지니어가 파악해야 할 포인트:

• API 연동: 각 시스템의 데이터 지연 시간 요구 사항을 명확히 -
• 데이터 품질: 마스터 데이터의 소유권을 확립 -
• 거버넌스: 3단계 액션 레벨과 정책 게이트를 설계 -
• 감사: 모든 판단을 불변하게 기록

가시성을 속도로 바꾸는 것—그것이 차세대 공급망 제어탑의 본질입니다.