Signal to Lever: Heineken이 품절 같은 신호를 조치로 바꿔 거래 시스템에 심는 법

Heineken은 데이터를 보고서로 끝내지 않습니다. 운영 문제의 신호와 회사가 당길 수 있는 조치를 짝지어 거래 시스템에 직접 넣고 실제로 문제가 줄었는지 보며 고칩니다. 따라 하려면 모델 선택보다 온톨로지 계층과 "조치에 연결된 최신 데이터"를 먼저 갖춰야 합니다.

요약

CIO Dive의 Paige Gross는 2026년 11월 2일, Heineken의 미국 CIO 겸 디지털·기술 담당 SVP인 Frank Iannella가 10월 Gartner IT Symposium/Xpo에서 발표한 내용을 전했습니다. Iannella는 지난 2년 동안 회사의 AI 전략을 다듬었습니다. 뼈대는 네 단계입니다. 먼저 바꿀 수 있는 운영 문제의 signal(신호)을 찾습니다. 예를 들어 어떤 제품이 자주 품절되는 현상입니다. 다음으로 회사가 취할 lever(조치 수단)를 정합니다. 이 경우는 배송을 앞당기는 일입니다. 세 번째로 이 판단을 거래 시스템에 기능으로 써 넣고 마지막 learning phase(학습 단계)에서 자동화가 품절을 실제로 막았는지 보고 조정합니다. 처음에는 이 일을 사람이 손으로 했고 AI를 붙인 뒤에는 신호와 조치를 더 빨리 찾아 실행합니다.

기사에 나온 네 단계와 품절 예시

Iannella는 이 과정을 제대로 잡는 데 2년 넘게 걸렸다고 말합니다. 기존 도구에 새 AI stack을 더했고 그 stack에서 이름이 나온 구성 요소가 ontology layer(온톨로지 계층)입니다. AI 시스템에 연결점과 맥락을 주는, 구조화된 기계 판독형 모델이며 AI 의사결정 설정 작업의 대부분이 여기서 이뤄집니다. 데이터는 깨끗한지보다 세 가지를 봅니다. 신호를 잡을 만큼 최신인지, 주문·배송 같은 조치와 이어지는지, 행동할 만큼 품질이 되는지입니다. 사내 확산은 Microsoft Copilot 배포와 사용자 커뮤니티로 이끌되, 민감 데이터·외부 대상 업무·의사결정 자동화·고객 영향 업무에는 통제를 더 겁니다. 아래에서는 이 운영 방식을 여섯 가지 장치로 나누고 실제로 만들 때 필요한 기술·현업 디테일을 덧붙입니다.

기사에 나온 decision-ready data의 세 질문

핵심 메커니즘

Signal과 Lever: 문제 신호와 조치 수단을 한 쌍으로 정의

Signal은 회사가 손쓸 수 있는 운영 문제가 데이터에 드러난 모습입니다. Lever는 그 신호를 봤을 때 회사가 실제로 할 수 있는 행동입니다. 둘을 따로 두지 않고 처음부터 짝으로 정의하는 것이 이 틀의 출발점입니다. 신호만 있고 조치가 없으면 대시보드에서 끝나고 조치만 있고 신호가 없으면 언제 당길지 모릅니다. 원문의 예는 자주 품절되는 제품(신호)과 배송 앞당기기(조치)입니다. 반복해서 일어나고 대응 행동이 정해져 있는 운영 문제에 맞고 대응이 매번 달라지는 전략 판단에는 맞지 않습니다. 가상 예시로, 식품 유통사라면 “특정 지역 편의점 3곳 이상에서 같은 SKU 재고가 이틀 연속 안전재고 아래”를 신호로, “다음 배송 회차에 해당 SKU 우선 배정”을 조치로 묶을 수 있습니다.

Signal과 Lever의 입력→처리→출력

Operationalize: 판단을 거래 시스템 안에 기능으로 넣기

신호와 조치 쌍을 찾았으면 Heineken은 그 판단을 transactional system(주문·배송처럼 실제 거래를 처리하는 시스템)에 기능으로 써 넣습니다. 사람이 보고서를 읽고 다시 시스템에 입력하는 단계를 없애, 신호가 뜨면 조치가 거래 흐름 안에서 바로 실행되게 하는 구조입니다. Iannella는 AI가 규모와 추천, 실행을 제공한다고 봅니다. 다만 어떤 결정은 아직 사람이 확인해야 하므로, 실행 방식은 자동 실행과 사람 승인 뒤 실행으로 나뉩니다. 처음에는 손으로 하던 신호 찾기와 조치를 AI가 더 빠르게 하게 된 것이 이 단계의 변화입니다.

Operationalize 전후

Learning Phase: 조치가 실제로 문제를 줄였는지 보고 고치기

거래 시스템에 넣은 뒤에도 일은 끝나지 않습니다. Learning phase에서 팀은 신호와 조치를 자동화한 결과 품절이 실제로 줄었는지 확인하고 결과가 나아질 때까지 조정합니다. Iannella가 2년 넘게 걸렸다고 한 부분이 바로 데이터를 결정으로 바꾸는 이 전체 과정입니다. 이 단계가 있어야 AI 과제가 측정 가능한 결과와 이어집니다. 조치가 비용을 쓰는 경우(배송 앞당기기는 물류비가 듭니다)에는 효과를 재지 않으면 조치를 늘릴지 줄일지 판단할 근거가 없습니다.

Learning phase 루프

Ontology Layer: AI가 읽는 업무 구조와 맥락

Iannella가 설명한 ontology layer는 구조화된 기계 판독형 모델로, AI 시스템이 연결점을 찾고 맥락을 얻는 곳입니다. 쉽게 말해 “제품, 재고, 주문, 배송이 서로 어떻게 이어지는가”를 사람의 머릿속이 아니라 기계가 읽을 수 있는 형태로 적어 둔 층입니다. 그는 AI 의사결정 설정 작업 대부분이 이 층에 있다고 말합니다. 신호가 어떤 조치와 이어지는지, 조치가 어느 거래 시스템의 어떤 기록을 바꾸는지가 여기서 정해지기 때문입니다. 원문은 이 계층이 무엇을 연결하는지 구체적으로 밝히지 않았습니다. 아래 기술 디테일의 객체 구성은 가상 예시입니다.

Ontology layer의 위치 (원천 데이터 칸은 가상 예시)

Decision-ready Data: 깨끗함보다 조치 가능성을 묻기

Heineken은 데이터가 결정에 쓸 준비가 됐는지를 세 질문으로 가립니다. 낮은 재고 같은 신호를 잡을 만큼 최신인가, 주문과 배송 같은 조치와 연결되는가, 행동해도 될 만큼 품질이 되는가입니다. Iannella는 이 질문들이 AI를 측정 가능한 결과에 묶는 데 도움이 된다고 봅니다. 데이터 정비 범위를 “전사 데이터 정제”가 아니라 “이 신호와 이 조치에 필요한 데이터”로 좁히는 효과가 있습니다. 가상 예시로, 재고 데이터가 하루 한 번만 갱신된다면 당일 품절 신호에는 쓸 수 없고 주간 보충 계획에만 쓸 수 있습니다.

왼쪽은 흔한 질문, 오른쪽은 기사의 세 질문

Guided Democratization: Copilot은 넓게, 위험 구간은 좁게

ChatGPT 등장 뒤 생성형 AI 물결에 CIO들이 대응해야 했고 Iannella는 이를 막기보다 이끄는 쪽을 택했습니다. Heineken은 직원에게 Microsoft Copilot을 배포하고 기능 부서를 가로질러 쓰임새를 나누는 사용자 커뮤니티를 만들었습니다. 일부 부서에서는 마음껏 실험하게 둡니다. 반면 민감 데이터, 외부 대상 업무, 의사결정 자동화, 고객에게 영향을 주는 업무에는 통제를 더 겁니다. AI가 스스로 결정하고 행동하는 단계에 대해 그는 아직 그 수준에 이르지 않았다고 봅니다. 그의 말로는 “There’s still trust to be earned.”입니다.

기사에 나온 사용 범위와 통제 구간

통념과 다른 주장

흔히 이렇게 봅니다AI를 쓰려면 먼저 전사 데이터를 깨끗하게 정제해야 합니다.

Iannella는 이렇게 봅니다깨끗함만으로는 부족하고 신호를 잡을 만큼 최신인지와 조치에 연결되는지를 함께 봐야 결정에 쓸 수 있습니다.

근거Heineken은 최신성, 주문·배송 조치와의 연결, 행동 가능한 품질이라는 세 질문으로 데이터를 판단하고 이 질문이 AI를 측정 가능한 결과에 묶는다고 설명합니다.

흔히 이렇게 봅니다AI 의사결정 프로젝트의 핵심 작업은 모델을 고르고 학습시키는 일입니다.

Iannella는 이렇게 봅니다설정 작업 대부분은 AI에 연결점과 맥락을 주는 ontology layer에서 일어납니다.

근거Heineken은 기존 도구에 새 AI stack을 더했고 그 stack에서 기계 판독형 모델인 ontology layer에 설정 작업이 몰려 있다고 말합니다.

흔히 이렇게 봅니다생성형 AI는 위험하니 사내 사용을 막거나 최소한으로 묶어 둡니다.

Iannella는 이렇게 봅니다막기보다 이끄는 쪽을 택해 넓게 배포하고 위험한 구간에만 통제를 더합니다.

근거Copilot을 직원에게 배포하고 사용자 커뮤니티를 만들되, 민감 데이터·외부 업무·결정 자동화·고객 영향 업무는 따로 통제합니다.

왼쪽은 흔한 통념, 오른쪽은 Iannella의 시각

저자가 든 사례

사례 1. 자주 품절되는 제품과 배송 앞당기기

상황	한 일	결과	연결
어떤 제품이 자주 품절됨	품절을 신호로, 배송 앞당기기를 조치로 짝짓고 거래 시스템에 기능으로 넣음. 처음엔 수작업, 이후 AI로 더 빠르게	자동화가 품절을 막았는지 learning phase에서 확인·조정. 품절 감소 수치는 원문에서 밝히지 않음	Signal과 Lever, Operationalize, Learning Phase

사례 1. 품절 신호와 배송 조치

사례 2. 2년 넘게 걸린 decision intelligence 기반

상황	한 일	결과	연결
데이터를 결정으로 바꾸는 방법을 찾아야 함	기존 도구에 새 AI stack을 더하고 ontology layer에 설정 작업을 모음	2년 넘게 걸려 네 단계 틀을 정리. Iannella는 이를 decision intelligence의 기본 블록이라 부름	Ontology Layer, Decision-ready Data

사례 2. AI stack과 ontology layer

사례 3. Copilot 배포와 사용자 커뮤니티

상황	한 일	결과	연결
ChatGPT 이후 생성형 AI 물결에 대응해야 함	직원에게 Microsoft Copilot 배포, 부서를 넘나드는 사용자 커뮤니티 구성, 위험 구간 통제	일부 부서는 자유 실험, 민감·외부·자동화·고객 영향 업무는 통제. 사용자 수는 원문에서 밝히지 않음	Guided Democratization

사례 3. Copilot과 사용자 커뮤니티

기술 디테일: 같은 구조를 직접 만든다면

아래 필드명, 설정값, 숫자는 모두 원문에 없는 가상 예시입니다. 기사가 밝힌 네 단계와 ontology layer를 실제로 돌릴 때 필요한 것을 정리했습니다.

Signal과 Lever를 코드로 관리하려면 쌍마다 등록부 한 행을 만듭니다. 신호는 LLM이 아니라 쿼리나 규칙으로 계산해 같은 데이터면 늘 같은 결과가 나오게 합니다. LLM은 새 신호 후보를 찾거나 조치 근거를 설명하는 데 씁니다. 후보 탐지에 LLM을 쓸 때는 temperature 0으로 같은 입력을 3회 돌려 3회 모두 같은 후보가 나온 것만 사람 검토로 보냅니다. 후보는 signal_name, rule_draft, evidence_query, linked_lever 네 필드의 JSON으로 받아, 조치와 이어지지 않는 후보는 검토 전에 걸러 냅니다. 등록부에는 신호가 기대는 데이터의 허용 지연(max_staleness_hours)과 조치의 실행 방식(execution)을 함께 적어 Decision-ready Data와 통제 구간이 한 행에서 보이게 합니다.

{
  "pair_id": "SL-STOCKOUT-017",
  "signal": {
    "name": "repeat_stockout",
    "rule": "최근 14일 중 결품일 3일 이상, 같은 SKU·같은 거래처",
    "sources": ["inventory_snapshot", "orders"],
    "max_staleness_hours": 6
  },
  "lever": {
    "name": "expedite_delivery",
    "target_system": "order_management",
    "action": "다음 배송 회차로 앞당김",
    "cost_per_action_usd": 40
  },
  "execution": "human_approval",
  "outcome_metric": "stockout_days_per_14d",
  "owner": "수요공급계획팀",
  "version": 3
}

signal-lever 등록부의 실행 흐름 (가상 예시)

Ontology layer를 처음 세우려면 첫 signal-lever 쌍 하나에 필요한 객체만 정의합니다. 품절 사례라면 SKU, Account(거래처), InventorySnapshot, Order, Delivery 다섯 개와 그 사이 관계(거래처가 SKU를 주문한다, 배송이 주문을 채운다)로 시작합니다. 객체마다 원천 시스템, 키, 갱신 주기를 속성으로 붙입니다. AI 에이전트나 LLM은 테이블을 직접 읽지 않고 이 객체와 관계를 도구로 조회하게 해, 같은 질문에 다른 테이블을 고르는 실수를 막습니다. 두 번째 쌍을 추가할 때는 객체를 새로 만들기 전에 기존 객체를 재사용할 수 있는지부터 봅니다. 설정 작업이 이 층에 몰리는 이유가 여기 있습니다.

품절 쌍에 필요한 최소 ontology (가상 예시)

거래 시스템에 써 넣을 때는 조치를 직접 DB에 쓰지 않고 거래 시스템의 API나 표준 인터페이스로 요청합니다. 요청마다 pair_id, 신호 계산 시각, 사용한 데이터 시각, 승인자(있으면)를 남겨 나중에 learning phase에서 어떤 조치가 어떤 결과를 냈는지 이을 수 있게 합니다. 같은 신호가 짧은 간격으로 다시 뜨면 조치가 중복되지 않게 pair_id와 SKU·거래처 조합으로 24시간 중복 방지를 겁니다.

Learning phase를 측정하려면 조치를 받은 거래처와 비슷한 조건의 비교군을 두고 outcome_metric을 2~4주 비교합니다. 조치 비용(예: 앞당김 1건당 물류비)도 함께 적어, 품절이 줄었어도 비용이 효과보다 크면 신호 기준을 올립니다. 등록부의 version을 올릴 때마다 이전 버전과 결과를 나란히 남깁니다.

실패하는 경우	대응 (가상 예시)
재고 데이터가 늦게 들어와 이미 채워진 품절에 조치가 나감	`max_staleness_hours` 초과 시 신호 보류, 데이터 지연 알림
같은 품절에 조치가 여러 번 실행됨	`pair_id`+SKU+거래처 기준 24시간 중복 방지
LLM이 매번 다른 신호 후보를 냄	신호 계산은 규칙으로 고정, LLM은 후보 제안만, 3회 일치 시 검토
조치 효과는 있는데 비용이 더 큼	조치 비용을 결과 지표와 함께 기록, 기준 상향
고객에게 영향이 가는 조치가 자동 실행됨	`execution`을 `human_approval`로 고정, 통제 구간 목록과 대조

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

Heineken처럼 신호와 조치를 짝지어 거래 시스템에 넣는다면 역할부터 나눕니다. 아래 표와 일정, 기준은 모두 가상 예시입니다.

역할	맡는 일 (가상 예시)
사업 오너(수요공급계획·영업 운영 팀장)	신호·조치 쌍 선정, 결과 지표 확정, 확대 판정
데이터 엔지니어	원천 데이터 연결, 최신성 측정, 신호 규칙 구현
온톨로지 모델러	객체·관계 정의, 원천·갱신 주기 속성 관리
거래 시스템 담당(ERP·주문관리)	조치 API 연결, 중복 방지·로그
리스크·법무	통제 구간(민감 데이터, 외부, 자동화, 고객 영향) 승인
Copilot 커뮤니티 리더	부서별 활용 사례 수집·공유, 통제 구간 안내

역할 배치 (가상 예시)

시작 전 준비물은 네 가지입니다. 품절처럼 반복되는 운영 문제 후보 5~10개 목록, 각 문제에 지금 사람이 취하는 조치와 그 비용, 관련 원천 데이터의 실제 갱신 주기표, 최근 3개월 품절 실적입니다. 원문처럼 처음에는 손으로 해 보는 기간을 두므로, 수작업 판단 기록을 남길 양식도 준비합니다.

기간	할 일	산출물
1~3주	쌍 하나 선정, 사람이 손으로 신호를 찾고 조치해 보며 판단 기록	수작업 판단 기록, 결과 지표 정의
4~6주	데이터 세 질문 점검, 최소 ontology 정의, 신호 규칙 구현	최신성 측정표, 객체·관계 정의서
7~9주	거래 시스템 연결, 사람 승인 뒤 실행으로 운영	조치 로그, 승인 기록
10~12주	비교군 대비 효과 측정, 기준 조정, 확대·보류 판정	판정 보고서, 다음 쌍 후보

12주 시범 일정 (가상 예시)

확인 질문은 이렇게 준비합니다. 이 문제가 생겼을 때 지금 누가 무엇을 보고 알아차립니까? 알아차린 뒤 취하는 조치는 무엇이고 그 조치는 어느 시스템에서 실행됩니까? 신호에 쓰는 데이터는 실제로 몇 시간마다 들어옵니까? 조치 한 번에 드는 비용은 얼마입니까? 이 조치가 고객이나 외부 거래처에 바로 보입니까?

진행 판정 기준은 쌍마다 다시 정하되 출발점은 셋입니다. 신호 데이터의 최신성이 허용 지연 안에 들어오는 비율 95% 이상, 비교군 대비 결과 지표 개선, 사람이 승인 단계에서 조치를 뒤집은 비율 10% 이하입니다. 셋을 모두 넘으면 같은 쌍을 더 많은 거래처로 넓히고 승인 단계를 줄일지는 고객 영향 여부를 보고 리스크·법무와 따로 정합니다.

진행 판정 기준 (가상 예시)

AX 적용 제언. 국내 제조·유통 기업이 이 사례에서 가져갈 것은 “데이터 플랫폼부터 다 만들고 AI를 붙인다”는 순서를 뒤집는 일입니다. 품절, 납기 지연, 클레임처럼 반복되고 대응 조치가 정해진 운영 문제 하나를 고르고 그 조치가 실행되는 거래 시스템까지 이어지는 데이터만 먼저 갖춥니다. 과제의 주인은 IT가 아니라 그 조치를 실제로 당기는 현업 팀장으로 두고 성과는 품절일 수처럼 그 팀이 이미 쓰는 지표로 봅니다. Ontology는 첫 쌍에 필요한 객체만으로 시작해 쌍이 늘 때마다 넓히면, 두 번째 쌍부터 설정 시간이 줄어듭니다. 생성형 AI 도구는 따로 넓게 배포하되, 결정 자동화와 고객 영향 업무는 처음부터 통제 구간으로 분리해 두면 두 흐름이 서로 막지 않습니다.

원문 사례

항목	내용
원문	CIO Dive, Paige Gross, 2026.11.2
인물	Frank Iannella, Heineken 미국 CIO 겸 디지털·기술 담당 SVP
발표	2026년 10월 Gartner IT Symposium/Xpo (사진 설명 기준 10월 20일 세션)
틀	신호 찾기 → 조치 정하기 → 거래 시스템에 기능으로 반영 → learning phase
예시	자주 품절되는 제품(신호), 배송 앞당기기(조치)
기간	AI 전략을 2년간 다듬음. 데이터를 결정으로 바꾸는 방법을 잡는 데 2년 넘게 걸림
기술	기존 도구 + 새 AI stack. ontology layer에 설정 작업 대부분
데이터 판단	최신성, 주문·배송 조치와의 연결, 행동 가능한 품질
확산	직원에게 Microsoft Copilot 배포, 부서 간 사용자 커뮤니티
통제	민감 데이터, 외부 대상, 의사결정 자동화, 고객 영향 업무. 일부 결정은 사람 검증

핵심 개념

decision intelligence: 데이터 분석에서 그치지 않고 결정과 실행, 결과 확인까지 하나의 흐름으로 설계하는 접근입니다. Iannella는 네 단계 틀을 그 기본 블록이라 부릅니다.
transactional system: 주문, 배송, 재고 이동처럼 실제 거래를 기록하고 처리하는 운영 시스템입니다.
stockout: 판매처에 제품 재고가 떨어져 팔 수 없는 상태입니다.
AI stack: 데이터, 모델, 온톨로지, 도구 연결처럼 AI를 돌리는 데 필요한 기술 층의 묶음입니다.
Gartner IT Symposium/Xpo: Gartner가 해마다 여는 CIO·IT 리더 대상 행사입니다.
Microsoft Copilot: Microsoft 업무 도구 안에서 쓰는 생성형 AI 비서입니다.

내 메모

TODO: 내 생각 추가

원문은 CIO Dive의 「Heineken CIO uses AI to operationalize data-driven decisions」(Paige Gross, 2026.11.2 게재)입니다. 요약, 핵심 메커니즘의 기사 내용, 통념과 다른 주장, 사례, 원문 사례 표는 기사 내용을 AX Review가 다시 정리했습니다. 핵심 메커니즘의 작은 예시, 기술·현업 실행 디테일, JSON 예시, ontology 객체 구성, 실패 대응 표, 역할·일정·판정 기준, 인포그래픽은 원문에 없는 내용으로 새로 작성했고 그 안의 필드명과 숫자는 가상 예시입니다. 기사 전문은 원문 페이지에서 볼 수 있습니다.