1억 5천만 달러짜리 핼러윈: 허쉬(Hershey)의 무리한 SAP 도입이 부른 물류 마비 사태

1999년 허쉬는 성수기를 앞두고 SAP R/3, Manugistics, Siebel의 '빅뱅(Big Bang)' 통합을 강행했습니다. 그 결과 1억 달러가 넘는 재고가 묶여버렸고, 물류 시스템은 완전히 마비되었습니다.

1999년 7월, 허쉬(The Hershey Company)는 기업 역사상 가장 악명 높은 IT 전환을 실행했습니다. Y2K 기한 전에 노후화된 인프라를 현대화하기 위해, 1억 1,200만 달러를 투입하여 SAP R/3, Manugistics, Siebel을 연결하는 거대한 통합 아키텍처의 스위치를 켰습니다.

10월이 되자, 그 디지털 전환이 초래한 물리적 결과가 북미 전역의 슈퍼마켓 진열대에서 나타났습니다. 진열대가 텅 비어버린 것입니다.

이 실패는 단일 알고리즘의 결함이나 잘못된 데이터베이스 쿼리 하나 때문이 아니었습니다. 시스템 통합과 프로젝트 관리가 연쇄적으로 무너져 내린 결과였습니다. “엔터프라이즈 21” 프로젝트는 극도로 밀접하게 결합된 핵심 인프라에서, 비즈니스 기한에 쫓겨 통합 테스트를 생략할 때 어떤 일이 일어나는지를 보여주는 완벽한 사례입니다.

---

증거가 입증하는 것:

• 엔터프라이즈 21 프로젝트의 일정이 48개월에서 30개월로 비정상적으로 단축되었음.
• 3개의 주요 벤더 플랫폼을 동시에 도입하는 ‘빅뱅(Big Bang)’ 전략을 사용했음.
• 주문 이행 마비와 직접적으로 연결된 1억 달러~1억 5천만 달러의 매출 손실.

증거가 입증하지 않는 것 (What the evidence does NOT establish):

• 실패의 원인이 SAP 또는 Manugistics 소스 코드 자체의 본질적인 버그였다는 주장.
• 특정 운영자의 의도적인 태업이나 악의적 행동.

엔터프라이즈 21 아키텍처란 무엇이었나? (What Was Enterprise 21?)

사건 이전 허쉬는 파편화된 구형 메인프레임 애플리케이션망에 의존하고 있었습니다. 엔터프라이즈 21 이니셔티브는 이 전체 기반을 최신 클라이언트-서버 아키텍처로 교체하도록 설계되었습니다. 이 거대한 기술적 발자국은 세 가지 거대한 소프트웨어 생태계를 통합해야 했습니다.

1. SAP R/3: 핵심 전사적 자원 관리(재무, 주문 처리, 청구 및 조달)를 담당하는 중앙 신경망.
2. Manugistics: 수요를 예측하고, 생산을 일정에 맞추며, 운송을 조정하는 공급망 관리(SCM) 두뇌.
3. Siebel: 고객 관계 관리(CRM) 계층.

이 시스템들은 독립적으로 작동할 때는 강력합니다. 그러나 긴밀하게 결합되면, 시스템 간에 전달되는 데이터 파이프라인(예: Siebel에서 생성된 주문이 SAP로 이동한 후 배송 라우팅을 위해 Manugistics로 전달되는 과정)은 스키마 불일치, 타이밍 문제, 데이터 무결성 오류에 극도로 취약해집니다.

포렌식 불일치 매트릭스 (The Forensic Discrepancy Matrix)

허쉬 도입 프로젝트의 붕괴는 프로젝트 계획의 ’디지털 가설’과 공급망 운영의 ’물리적 현실’을 대조할 때 명확하게 드러납니다.

아키텍처 차원	디지털 가설	물리적 현실	증거 상태	메커니즘
통합 테스트 (Integration Testing)	개별 모듈이 제대로 작동하므로 통합 파이프라인도 성공할 것이다.	생산 부하 상태에서 통합 지점이 실패하여 주문 라우팅 데이터가 손상됨.	[DOCUMENTED]	엔드투엔드 스트레스 테스트 생략.
도입 전략 (Rollout Strategy)	‘빅뱅’ 방식의 전환을 통해 새로운 스택으로 원활하게 운영을 이전할 수 있다.	동시 출시는 오류를 증폭시켰고, 근본 원인을 격리하는 것을 불가능하게 만듦.	[DOCUMENTED]	모든 노드에 걸친 동시 배포.
주문 이행 (Order Fulfillment)	시스템이 가용 재고를 소매 파트너에게 라우팅할 것이다.	창고에는 캔디가 가득 차 있었으나, 시스템에서 디지털 방식으로 출하를 승인할 수 없었음.	[DOCUMENTED]	SAP와 Manugistics 간의 데이터 파이프라인 단절.
프로젝트 일정 (Project Timeline)	48개월의 일정을 30개월로 단축하는 것은 수용 가능한 위험이다.	단축된 교육으로 인해 작업자들이 시스템 예외를 수동으로 해결하지 못함.	[DOCUMENTED]	무리한 Y2K 기한 강행.

---

제1막: Y2K가 부른 일정 단축 (Act I: The Y2K Compression) (분석적 재구성)

재앙의 뿌리는 구조적이었습니다. 허쉬는 원래 48개월의 도입 일정을 계획했습니다. 그러나 1990년대 후반으로 접어들면서, 경영진은 기존 메인프레임의 Y2K(밀레니엄 버그) 호환성에 대해 점차 불안감을 느꼈습니다.

새로운 시스템이 2000년 1월 1일 이전에 완전히 가동되도록 보장하기 위해, 프로젝트 일정은 단 30개월로 압축되었습니다. 이 공격적인 일정은 개발팀이 치명적인 타협을 하도록 강요했습니다. 바로 테스트 단계를 심각하게 축소한 것입니다. 모의 주문이 CRM을 거쳐 ERP로, 그리고 SCM으로 전달되어 과부하 상태의 창고 현장으로 빠져나가는지를 확인하는 종합적인 ’엔드투엔드(End-to-End) 통합 테스트’는 대부분 생략되었고, 기본적인 모듈별 테스트로 대체되었습니다.

제2막: 빅뱅과 핼러윈 데드라인 (Act II: The Big Bang and the Halloween Deadline) (분석적 재구성)

압축된 일정 상황을 더욱 악화시킨 것은 배포 전략이었습니다. 새로운 아키텍처를 지역별이나 모듈별로 단계적으로 출시하는 대신, 허쉬는 1999년 7월에 전면적인 “빅뱅” 전환을 실행했습니다.

7월은 캔디 제조업체들이 핼러윈(크리스마스와 함께 연간 매출의 엄청난 비율을 차지하는 명절)을 위한 배송을 본격적으로 시작하는 바로 그 시점입니다. 스위치가 켜지자마자 시스템은 즉시 통합 오류를 일으키기 시작했습니다.

주문, 재고 위치 및 배송 일정을 설명하는 데이터가 SAP R/3와 Manugistics 간에 제대로 동기화되지 않았습니다.

제3막: 물리적 마비 (Act III: Physical Gridlock) (분석적 재구성)

이 실패의 결과는 디지털이 아니라 물리적이었습니다. 창고의 랙(Rack)에는 제품이 가득했습니다. 그러나 Manugistics의 운송 일정과 SAP의 주문 처리 모듈이 서로의 데이터를 대조하지 못했기 때문에, 창고 관리 시스템(WMS)은 필요한 픽업 리스트나 배송 매니페스트를 생성할 수 없었습니다.

디지털 원장이 팰릿이 어디로 가야 하는지 확인해 주지 못했기 때문에, 작업자들은 창고 바닥에 선 채 팰릿을 옮길 수 없었습니다. 오류가 발생했을 때, 축소된 교육 프로그램 탓에 일선 작업자들은 시스템을 수동으로 재정의하거나 예외를 해결할 지식이 부족했습니다. 디지털 마비가 물리적 마비를 낳은 것입니다.

제4막: 1억 5천만 달러의 대가 (Act IV: The $150 Million Reckoning) (분석적 재구성)

늦여름 무렵, 소매업체들은 배송 누락에 대해 항의하기 시작했습니다. 핼러윈이 다가오는데도 진열대에는 허쉬 제품이 비어 있었고, 소매업체들은 황금 진열 공간을 Mars나 Nestlé 같은 경쟁사에게 내어주어야 했습니다.

재정적 타격은 파괴적이고 즉각적이었습니다.

• 허쉬는 약 1억 달러에서 1억 5천만 달러의 매출 손실을 입은 것으로 추정됩니다.
• 3분기 수익은 19% 급감했습니다.
• 실적 경고 이후 회사 주가는 약 8% 하락했습니다.

허쉬가 통합 지점을 안정화하고 정상적인 주문 이행 작업을 복원하기까지 수개월의 시간, 대규모 컨설팅 지원, 그리고 새로운 CIO 임명을 포함한 리더십 개편이 필요했습니다.

---

시스템 예방 플레이북 (Systems Prevention Playbook)

허쉬 사건은 대규모 시스템 통합 과정에서 비즈니스 데드라인이 엔지니어링 안전 프로토콜을 무시할 때 어떤 일이 일어나는지를 보여주는 결정적 템플릿입니다. 현대 아키텍처는 세 가지 클래스의 제약을 통해 이를 방어합니다.

1. 마찰 방어 (테스트 게이트 / Friction Defenses)

복잡한 통합에는 생략할 수 없는 의무적인 테스트 게이트를 강제해야 합니다. 모의 최대 부하 상태에서의 엔드투엔드(End-to-End) 통합 테스트는 프로덕션 전환 전의 엄격한 요구 사항이어야 합니다. 통합 테스트에 실패하면 Y2K와 같은 외부 비즈니스 기한에 관계없이 배포가 차단되어야 합니다.

2. 경계 제약 (단계적 롤아웃 / Boundary Constraints)

3개의 개별 엔터프라이즈 시스템을 동시에 배포하는 “빅뱅” 방식은 ’격리된 장애 도메인(Isolated failure domains)’의 원칙을 위반합니다. 배포는 반드시 단계적으로 이루어져야 합니다(예: SAP를 먼저 배포하여 안정화한 후 Manugistics를 통합). 이를 통해 장애 발생 시 근본 원인을 특정 아키텍처 경계 내로 격리할 수 있습니다.

3. 비상 브레이크 (수동 재정의 / Emergency Brakes)

물류 시스템에는 설계된 “우아한 기능 저하(Graceful degradation)” 모드가 있어야 합니다. 자동화된 운송 라우팅 시스템(Manugistics)이 실패하더라도, 창고 실행 시스템에는 작업자가 오프라인 매니페스트를 사용하여 팰릿을 물리적으로 스캔하고 배송할 수 있도록 하는 국지적인 수동 재정의(Override) 기능이 있어야 합니다. 이는 업스트림 데이터 파이프라인이 복원될 때까지 물류 마비를 막아줍니다.

---

왜 테스트 단계에서 발견하지 못했는가? (Why Testing Missed It)

허쉬 프로젝트에 테스트 자체가 없었던 것은 아닙니다. 그들에게 부족했던 것은 통합 테스트였습니다. 개별 모듈(SAP, Siebel, Manugistics)은 격리된 상태에서 올바르게 기능했습니다. 그러나 일정이 30개월로 압축되었기 때문에, 모의 최대 부하 상태에서 이 시스템들을 연결하는 데이터 파이프라인을 테스트하는 복잡하고 시간 소모적인 과정을 건너뛰었습니다. 그들은 노드(Node)는 검증했지만 엣지(Edge)는 무시했습니다.

시스템이 핼러윈을 앞둔 대규모 트랜잭션 볼륨에 부딪혔을 때, 검증되지 않은 통합 지점이 무너지면서 데이터가 유실되고 ERP와 공급망 간의 상태(State)가 손상되었습니다.

엔지니어링의 진화: 과거와 현재 (Engineering Evolution: Then vs. Now)

기능	1999년 (허쉬 엔터프라이즈 21)	최신 도입 방식
배포 전략 (Deployment)	고위험 “빅뱅(Big Bang)” 동시 전환.	카나리아 릴리스, 블루/그린 배포, 단계적 롤아웃.
통합 아키텍처 (Integration)	포인트-투-포인트(Point-to-point) 일괄 데이터 전송.	강력한 메시지 브로커(예: Kafka) 및 데드 레터 큐(Dead-letter queue)가 있는 이벤트 기반 마이크로서비스.
테스트 체계 (Testing)	단축된 모듈별 테스트; 엔드투엔드 부하 테스트 생략.	의무적인 스테이징 환경 스트레스 테스트를 포함한 자동화된 CI/CD 파이프라인.

---

아키비스트의 판결

아키비스트의 분석: 엔터프라이즈 21 재난은 임의적인 달력상의 날짜(Y2K)가 엔지니어링 현실을 지배하도록 허용하는 것에 대한 전형적인 경고입니다. 경영진은 48개월이 걸리는 통합을 30개월 안에 완료할 것을 요구했습니다. 테스트되지 않은 인터페이스가 프로덕션 부하에 노출되었을 때, 소프트웨어는 컴퓨터 과학의 법칙이 지시하는 정확히 그대로 작동했습니다. 즉, 실패한 것입니다. 허쉬 사건의 궁극적인 아이러니는 2000년 1월 1일에 발생할지도 모르는 ’가상의 디지털 실패’를 막기 위해 서두르다가, 결국 1999년 10월에 ’극도로 현실적인 물리적 실패’를 보장해 버렸다는 점입니다.

---

공식 1차 출처

• Pemeco Consulting: Hershey’s ERP Implementation Failure Case Study
• ERP Perspective: The 1999 Hershey ERP Disaster
• 1999년 3분기 실적 발표 이후의 공식 내부 감사 및 공급망 검토 보고서.

---

FAQ: 허쉬 ERP 재난 설명

허쉬는 왜 ERP 도입을 서둘렀나요?

이 프로젝트는 원래 48개월에 걸친 단계적 도입으로 계획되었습니다. 그러나 경영진은 Y2K(밀레니엄 버그) 기한 전에 모든 시스템을 완전히 가동하기 위해 일정을 30개월로 단축했습니다.

“빅뱅(Big Bang)” ERP 도입이란 무엇인가요?

빅뱅 도입은 기존 시스템을 일제히 종료하고 전사적으로 새로운 소프트웨어 모듈을 동시에 가동하는 방식입니다. 허쉬는 1999년 7월에 이 고위험 전략을 실행했습니다.

ERP 실패로 인해 허쉬는 얼마의 손실을 입었나요?

허쉬는 가장 중요한 핼러윈 및 연말 판매 시즌 동안 약 1억 달러에서 1억 5천만 달러의 매출 손실을 입었습니다. 3분기 수익은 19% 하락했습니다.

SAP 소프트웨어가 실패의 원인이었나요?

단일 소프트웨어 패키지의 문제가 아니었습니다. 이 실패는 SAP, Manugistics, Siebel 간의 데이터 파이프라인이 부하 상태에서 테스트되지 않은 시스템 통합 및 프로젝트 관리의 총체적 재난이었습니다.

창고 현장에서는 즉각적으로 어떤 운영상 문제가 발생했나요?

창고 직원들은 재고 위치를 확인하거나 배송 문서를 처리할 수 없었습니다. 팰릿 위에 물리적 캔디가 존재함에도 불구하고 디지털 시스템이 출하를 승인할 수 없었기 때문입니다.

엔지니어링 리더가 얻어야 할 핵심 교훈은 무엇인가요?

임의적인 달력 마감일이 근본적인 시스템 통합 테스트를 무시하도록 허용해서는 안 됩니다. 출시 지연은 관리 가능한 운영 과제이지만, 성수기 동안의 고장 난 시스템 출시는 파멸적인 기업 재난입니다.