2019년, 서던 캘리포니아에서 아웃도어 용품을 판매하는 제 고객이 세 번째 창고를 열었습니다. 그가 전화를 걸어 물었습니다. "Lao Mi, 이미 쓰고 있는 WMS에 사이트 두 개만 추가하면 안 돼?" 저는 대답하지 않았습니다. 대신 세 가지 질문을 던졌습니다. 세 창고가 같은 고객에게 서비스합니까? 네트워크가 끊기면 창고가 멈춥니까? 성수기에 세 사이트의 주문 규칙이 얼마나 다릅니까? 그가 답을 마치자 이미 알고 있었습니다.
창고 하나에서 세 개, 다섯 개로 늘어나는 거의 모든 회사가 정확히 이 벽에 부딪힙니다——특히 자체 운영 사이트와 3PL 파트너를 섞어 쓰는 경우가 흔합니다. 결국 결정을 내려야 합니다. 네트워크 전체를 하나의 시스템으로 돌릴 것인가, 창고마다 하나의 시스템으로 돌릴 것인가. 잘못 고르면 앞으로 3년 동안 그 대가를 치르게 됩니다.
두 갈래 길, 솔직하게 말하자면
중앙집중식 싱글 인스턴스란 하나의 시스템, 하나의 논리 데이터베이스로 네트워크 전체를 운영하는 것입니다. 각 창고는 그 안의 "사이트"일 뿐입니다. 장점은 분명합니다. 네트워크 전체의 재고 가시성은 그냥 따라옵니다. 사이트 간 이송, 가장 가까운 사이트에서 출고, 재고 있는 사이트에서의 자동 소싱——데이터를 이리저리 옮기는 인터페이스가 필요 없습니다. 리포팅도 쉽습니다. 사장이 네트워크 전체 재고 보고서를 원하면 바로 있습니다.
대가는? 운명 공동체입니다. 한 번의 업그레이드가 네트워크 전체에 배포되고, 특정 사이트의 프로세스 변경 하나가 네트워크 전체를 회귀 테스트에 끌어들입니다. 더 심각한 건 네트워크 의존성입니다. 창고와 중앙 데이터센터 사이의 링크가 잠깐만 흔들려도 피킹과 입고가 바로 영향을 받습니다. 그리고 데이터 격리——한 시스템에서 열 개가 넘는 고객사를 돌리는 3PL은 권한과 논리적 분리에 전적으로 의존합니다. 감사인을 납득시키는 건 고된 작업이 됩니다.
멀티 인스턴스는 이 교환을 뒤집습니다. 각 창고가 물리적으로 격리된 데이터로 각자의 시스템을 돌립니다. 사이트끼리 간섭하지 않습니다. 사이트 A가 업그레이드하는 동안 사이트 B는 계속 일하고, 사이트 A가 연결을 잃어도 사이트 B는 알아채지 못합니다. 3PL에게 고객사 격리는 자연스럽게 깔끔합니다——고객사당 하나의 환경, 감사 설명도 쉽습니다.
비용은 네트워크 수준의 장님 상태입니다. "네트워크 전체에 재고가 얼마나 있지?" 하려면 각 사이트의 데이터를 한 곳으로 모아 엮는 인터페이스가 필요하고, 실시간성은 타격을 입습니다. 사이트 간 이송과 가장 가까운 사이트에서의 출고에는 추가 통합 계층이 필요합니다. 그리고 업그레이드는 사이트별로 진행됩니다. 시스템 다섯 개는 업그레이드 다섯 번, 테스트 다섯 번을 의미합니다.
여섯 가지 기준——계약하기 전에 점수를 매기세요
선정 회의에서는 고객에게 이 여섯 가지를 하나씩 짚어보게 합니다. 벤더의 슬라이드 듣는 것보다 낫습니다.
첫째, 사이트 수와 사업의 이질성입니다. 같은 상품을 같은 프로세스로 파는 창고 세 곳과, 하나는 소형 택배 이커머스, 하나는 대형·부피 상품, 하나는 도매를 하는 세 사이트는 완전히 다른 동물입니다. 사업이 비슷할수록 싱글 인스턴스의 효율이 크고, 다를수록 멀티 인스턴스의 독립성이 값어치를 합니다.
둘째, 네트워크 전체 재고 가시성입니다. 귀사의 비즈니스에 사이트 간 이송과 가장 가까운 사이트에서의 출고가 필요합니까? 옴니채널 리테일에서는 고객이 주문하는 순간 어느 창고가 출고할지 정해야 하고, 네트워크 재고는 실시간이어야 합니다. 싱글 인스턴스는 여기서 타고난 승자입니다. 멀티 인스턴스에는 동기화 계층이 필요하고, 지연과 정합 비용은 직접 부담합니다.
셋째, 컴플라이언스와 고객사 격리입니다. 식품·제약·위험물을 취급하는 3PL——혹은 자사 상품과 고객사 상품을 한 시스템에 섞어 쓰는 경우——는 엄격한 데이터 분리 요건에 직면합니다. 멀티 인스턴스의 물리적 격리가 쉬운 답입니다. 싱글 인스턴스도 가능하지만, 권한 모델과 감사 추적은 철옹성처럼 탄탄해야 합니다.
넷째, 네트워크와 오프라인 리스크입니다. 자문해 보세요. 창고 하나가 연결을 잃으면 네트워크까지 같이 쓰러집니까? 싱글 인스턴스 아키텍처에서는 창고와 센터 사이의 링크가 생명줄입니다. 미국의 외딴 지역 창고 중에는 연결이 정말 불안정한 곳이 있습니다. 30분 오프라인이 창고 중단을 의미한다면 그 리스크를 미리 가격에 반영하세요——로컬 캐싱과 페일오버를 구축하거나, 멀티 인스턴스로 가세요.
다섯째, 업그레이드와 유지보수 비용입니다. 싱글 인스턴스는 모두를 한 번에 업그레이드합니다——하지만 한 번의 업그레이드 리스크도 모두가 함께 집니다. 멀티 인스턴스는 다섯 번 업그레이드하지만 사이트별로 순차 배포할 수 있고, 실패한 업그레이드는 격리됩니다. 적은 인원은 싱글 인스턴스로 인건비를 아낍니다. 다운타임을 용납 못하는 운영은 멀티 인스턴스 격리에 더 마음이 놓입니다.
여섯째, 구축 비용과 일정입니다. 싱글 인스턴스에서는 사이트 2와 사이트 3은 보통 "사이트 설정 복사"——몇 주면 되고, 몇 달이 아닙니다. 멀티 인스턴스는 사이트마다 전체 구축입니다. 벤더 견적은 이 부분에서 천차만별이므로, 협상 전에 3년 안에 실제로 몇 개의 창고를 열지 정하세요.
벤더에 대해: Manhattan, Blue Yonder, Korber 같은 주류 제품은 멀티사이트 아키텍처와 배포를 다루는 방식이 각각 다릅니다——결정 전에 벤더의 최신 자료를 확인하고, 3년 된 백서만 보고 결정하지 마세요.
계산: 창고 다섯 개, 싱글 인스턴스가 실제로 얼마나 절약하나
이론은 여기까지. 계산해 봅시다. 규모감을 잡기 위한 추정치입니다——실제 숫자는 최신 벤더 견적으로 받으세요.
중규모 창고 다섯 개라고 하죠. 싱글 인스턴스 방식: 라이선스는 사이트 수에 따라 스케일되고, 두 번째 사이트부터는 보통 첫 사이트의 30–50% 수준으로 책정됩니다. 구축은 사이트 1이 풀 스코프, 나머지 네 사이트는 사이트 복제와 델타 설정으로, 각 사이트가 사이트 1 비용의 약 30–50% 수준입니다. 3년——라이선스, 구축, 운영——싱글 인스턴스는 보통 독립 인스턴스 다섯 개 대비 30–40%를 절약합니다. 수십만 달러 규모의 이야기입니다.
좋아 보이죠. 이제 반대쪽도. 싱글 인스턴스의 가장 큰 리스크는 네트워크 전체 장애입니다. 실패한 업그레이드, 혹은 중앙 링크 다운으로 창고 다섯 곳이 함께 멈춥니다. 성수기, 하루 20,000건의 주문, 창고 하나가 네 시간 다운——백로그, 잔업, 출고 지연 패널티, 이탈 고객. 하룻밤의 실패로 3년치 절약이 날아갑니다. 저는 실제로 봤습니다. 실패한 업그레이드로 창고 세 곳이 거의 하루 종일 다운됐습니다. 사장은 나중에 이렇게 말했습니다. "성수기 2주 전에는 다시는 시스템에 손대지 않겠다"고.
그러니 계산은 절약액만의 이야기가 아닙니다. 극단적 사건의 비용 × 발생 확률의 이야기입니다. 싱글 인스턴스는 리스크를 집중시킵니다. 절약은 확실하고, 베팅은 저확률·고임팩트 손실입니다.
제 결론: 아낄 때, 아끼지 말 때
결론부터, 돌려 말하지 않겠습니다.
창고 세 곳 이하, 사업이 매우 유사, 고객 기반이 단일, 모두 미국 국내——싱글 인스턴스로 가세요. 깊이 고민하지 마세요. 이 단계에서는 네트워크 전체 재고와 낮은 비용이 실제 돈이고, 멀티 인스턴스가 사주는 격리는 쓰지도 않을 겁니다. 그냥 과소비입니다.
다음 중 하나라도 해당되는 순간, 멀티 인스턴스로 가고 아끼지 마세요. 사업이 진짜로 다른 사이트들——프로세스, 주문 유형, 고객 기반이 다른. 고객사 데이터 분리의 엄격한 요건을 가진 3PL 운영. 국경을 넘는 창고들로, 시간대, 언어, 컴플라이언스 체계, 데이터 주권이 얽혀 있는 경우. 또는 "한 번의 장애가 네트워크를 죽인다"는 생각에 밤잠을 설치는 네트워크 조건.
대부분이 놓치는 한 가지 더. 3년 사이트 계획입니다. 3년 안에 여덟 개, 열 개의 창고가 될 것이 확실하다면, 지금 싱글 인스턴스를 고르면 나중에 멀티 인스턴스로의 이전 비용이 끔찍해집니다. 그 경우 첫날부터 멀티 인스턴스로 구축하세요——적어도 나중에 분리할 수 있는 아키텍처를 고르세요. 오늘의 창고 수에 맞춰 고르는 게 아닙니다. 3년 후의 창고 수에 맞춰 고르는 겁니다.
회의에 바로 가져갈 수 있는 체크리스트입니다. 출력해서 순서대로 확인하세요.
- 3년 안에 최대 몇 개의 창고? 사업 이질성을 1–5로 평가.
- 실시간 네트워크 재고가 필요합니까? 사이트 간 이송과 가장 가까운 사이트에서의 출고가 비즈니스의 핵심입니까?
- 고객사 격리나 업계 컴플라이언스의 엄격한 요건이 있습니까? 감사인이 논리적 분리를 받아들입니까?
- 각 사이트의 연결 상태는? 오프라인 30분에 창고가 멈추는 걸 감당할 수 있습니까?
- 시스템을 운영하는 인원은? 팀이 사이트별 업그레이드를 감당할 수 있습니까?
- 성수기에 창고 하나가 네 시간 다운되는 비용은? 추정 발생 확률을 곱해서——그래도 가치가 있습니까?
내일 할 수 있는 일: 먼저 사내에서 이 여섯 가지 질문에 의견을 맞추고, 한 페이지로 정리한 뒤 벤더에게 가져가세요. "네트워크가 끊기면 어떻게 됩니까", "업그레이드는 어떻게 단계적으로 배포됩니까"에 답하지 못하는 영업——그 제안은 거르셔도 됩니다. 아키텍처 선정은 기능 목록으로 이기는 게 아닙니다. 최악의 날이 어떤 모습인지로 이깁니다.
영어판 번역본입니다. 내용이 다를 경우 영어판을 우선합니다.
