창고 자동화에는 반복적으로 등장하는 장면이 있다. 신규 설비의 테이프 커팅식이다. AS/RS 크레인은 세워졌고, 컨베이어에는 전원이 들어오고, AMR이 처음으로 자율 주행을 해낸다――그러면 사업주는 안도의 한숨을 쉬며 가장 어려운 부분은 끝났다고 생각한다. 프로젝트 회고를 보면 대개 정반대가 사실이다. 기계 설치가 완료된 뒤에도 시설이 진짜 가동에 들어가는 데까지는 아직 몇 개월이 남아 있고, 그 기간 동안 노동 시간의 최대 소비자는 더 이상 설비 벤더가 아니라 소프트웨어와 커미셔닝 팀이다. WCS 구축 일정은 모든 자동화 프로젝트에서 가장 만성적으로 과소평가되는 구간으로 남아 있다.
업계 자체가 공표한 벤치마크를 생각해보자. 자동화 통합 업체 DNC Automation의 공개 WCS 구축 FAQ에 따르면 일정은 세 구간으로 나뉜다. 단순한 컨베이어 시스템용 기본 WCS는 6주에서 12주 만에 구축된다. 여러 설비 유형을 갖춘 중간 복잡도의 시설은 3개월에서 5개월이 필요하다. 광범위한 자동화를 갖춘 대규모 구축은 6개월에서 12개월이 걸리며, 설계, 구성, 통합, 테스트, 커미셔닝을 포함한다. 주목할 것은 이 구간들이 실제로 무엇을 재는가이다. 설비가 이미 설치되어 있고 기계 설치가 완료되었다는 가정 위에서, 소프트웨어와 통합 작업 그 자체다. 그 가정을 두더라도 상위 구간은 꼬박 1년을 소모한다. 탄력성은 엄청나다――그리고 프로젝트가 어느 구간에 들어가는지를 결정하는 것은 코드의 양인 경우가 드물다.
다섯 단계: 시간이 어디로 사라지는가에 대한 회계
여러 통합 업체의 회고를 종합하면, WCS 구축 노력은 대략 다음과 같이 분배된다. 1단계인 요구사항과 인터페이스 동결은 전체 노력의 약 15에서 20퍼센트를 차지한다. WMS와 WCS 사이의 모든 메시지, PLC 텔레그램의 모든 포맷, WCS와 각 설비 사이의 모든 예외 코드 표를 문서화하고 양쪽에 서명받는 일이다. 2단계인 구성과 개발은 20에서 25퍼센트. WCS 플랫폼에 프로세스 로직을 구성하고, 디바이스 드라이버를 쓰고, 오프라인 에뮬레이션을 돌린다. 3단계인 현지 통합과 커미셔닝은 보통 가장 큰 블록으로 30에서 40퍼센트. 설비가 한 대씩 전원이 들어오고, WCS가 구역별로 연결되고 가동된다. 4단계인 시운전과 램프업은 15에서 20퍼센트. 실제 물량으로 돌리고, 택트타임을 조정하고, 코너 케이스를 고친다. 마지막으로 검수와 인수는 약 5퍼센트. 문서화, 교육, 보증 이전이다.
구조적으로 주목할 점은 3단계다. 왜 현지 커미셔닝은 항상 블랙홀인가. 한 가지 이유는 PLC와 WCS가 근본적으로 다른 두 가지 시간 개념에 살고 있기 때문이다. PLC는 밀리초 단위 스캔 사이클로 생각한다――50밀리초 늦게 도착한 광센서 신호는 인시던트다. WCS는 트랜잭션으로 생각한다――팔레트가 A 지점에서 B 지점까지 거치는 완전한 여정이다. 이 두 시간 개념이 현지에서 처음으로 만나면, 사무실 에뮬레이션으로는 결코 드러나지 않았을 문제들이 나타난다. 센서 지터, 팔레트 자세 편차, 네트워크 지연 스파이크다. 각각은 단독으로는 작아 보이지만, 하나하나에 대해 양쪽이 함께 앉아 재현하고, 국한시키고, 누구 잘못인지 확정해야 한다. 시간은 그렇게 소모된다. 한 번의 붕괴가 아니라 수백 번의 작은 인출로.
현장에서 온 두 장면: 시간은 이렇게 논쟁으로 사라진다
2024년, 미국 중서부의 제3자 물류 회사가 크로스벨트 소터 라인을 가동했다. WCS는 소터와 WMS 사이의 소팅 스케줄링을 맡았다. 커미셔닝 3주차에 문제가 표면화되었다. 오소트율이 0.3퍼센트 안팎을 맴돌고 있었다. 설비 벤더는 WCS가 결함 있는 소트 계획을 발행하고 있다고 주장했다. 통합 업체는 로그를 제시했다. 계획은 올바르고 텔레그램은 PLC 실행 측에서 떨어지고 있음을 증명하는 로그였다. 대치는 꼬박 2주간 이어지다가 근본 원인이 드러났다. PLC 프로그램 버전 불일치였다. 벤더는 현지에서 버전 3.2를 플래시했는데, 통합 업체는 버전 3.1용 인터페이스 문서를 보고 개발했었다――그리고 두 버전 사이에서, 소트 확인 텔레그램의 바이트 오프셋이 하나 어긋나 있었다. 프로젝트는 5주 늦게 가동되었다. 실제 코드 수정은 2일 걸렸다. 나머지는 전부 "문제는 우리 쪽이 아니다"를 증명하는 데 들어갔다.
두 번째 사례는 2022년 유럽이다. 전자상거래 풀필먼트 센터가 AS/RS를 설치했다. 사업주는 성수기 마감일을 좇느라 크레인 기계 설치가 6주 뒤처져 있는데도 WCS를 원래 일정대로 시운전에 넣으라고 고집했다. 제어 로직은 그 때문에 2개월간 절반만 설치된 설비를 상대로 조정되었다. 로직의 분기가 통째로 전혀 테스트되지 못했다. 하드웨어가 거기 없었으니 당연하다. 기계 설치가 마침내 완료되자, 그때까지 조정한 파라미터의 거의 전부를 다시 손봐야 했다. 실제 크레인의 가속 프로파일이 시뮬레이션과 달랐기 때문이다. 그 교훈은 나중에 그 사업주의 모든 그린필드 프로젝트용 계약 템플릿에 기록되었다. 기계 설치와 설비 단독 테스트가 완료되기 전에는 WCS 팀을 현지에 동원하지 않는다. 겉보기에는 일정을 늦추는 듯한 이 규칙이, 이후 프로젝트들의 커미셔닝 기간을 거의 3분의 1로 줄였다.
지연을 부르는 세 가지 함정
첫 번째 함정은 인터페이스 문서가 동결되기 전에 작업을 시작하는 것이다. WMS-WCS와 WCS-PLC 인터페이스가 프로젝트 중반에 바뀌기 시작하면, 변경 때마다 양쪽에 재작업이 발생한다. 더 나쁜 것은 인터페이스가 그레이존이라는 점이다――어느 쪽의 산출물 목록에도 속하지 않는다――그래서 변경 비용은 깔끔하게 협상되는 일이 없다. 성숙한 관행은 인터페이스 동결을 계약상 마일스톤으로 만드는 것이다. 동결일 이후에는 모든 인터페이스 변경이 정식 변경 절차를 거치고, 일정과 비용은 별도로 처리된다.
두 번째 함정은 "잘 돌아간다"의 정의를 계약에서 빼는 것이다. 시운전 합격이란 무엇인가――72시간 연속 무고장 가동인가, 설계 택트의 90퍼센트인가. 실제 주문인가, 테스트 데이터인가. 이 기준들이 계약 체결 시 정의되어 있지 않으면 검수는 끝없는 협상이 된다. 나는 시운전 검수의 문자 그대로의 정의를 놓고 6주간 다투는 것을 본 적이 있다――그 사이 양쪽 모두 내심으로는 시스템이 이미 쓸 만하다는 데 동의하면서 말이다. 처방전은 검수 기준을 계약 부속서에 정량화하는 것이다. 연속 가동 시간, 택트 달성률, 오소트 상한.
세 번째 함정은 WCS 검수를 기계 검수와 같은 날짜에 묶는 것이다. 기계가 하루 늦어질 때마다 소프트웨어 팀은 현지 비용을 하루씩 태운다――그리고 손 놓고 기다리는 데서 오는 사기 손상은 금전적 비용을 웃돈다. 분리하는 접근법은 단계별 검수다. WCS는 먼저 가상 설비에 대한 "에뮬레이션 검수"를 통과하고, 다음에 "현지 검수"를 통과한다. 에뮬레이션 검수를 통과하면 소프트웨어 팀은 동원을 해제하고 현지에 최소한의 지원 인력만 남길 수 있다.
반직관적인 발견: 코드를 쓰는 것이 가장 싸다
WCS 프로젝트의 초과를 연구하면 반직관적인 결론이 반복적으로 나타난다. 총비용에서 WCS 로직을 실제로 쓰는 일은 가장 작은 비중을 차지한다. 대부분은 세 항목으로 사라진다――대기, 재작업, 논쟁이다. 대기: 설비, 인터페이스, 상대방 일정을 현지에서 기다리는 소프트웨어 팀의 유휴 시간. 재작업: 요구사항이 동결되지 않아 뜯어고치는 일. 논쟁: 그레이존에서 책임을 확정하는 일. 셋 중 어느 것도 한 줄의 코드도 만들지 않지만, 함께 가장 많은 예산과 일정을 소모한다.
두 번째 반직관적인 발견은 정반대를 찌른다. 요구사항을 너무 일찍 동결하면 재작업이 줄어들기는커녕 늘어난다. 하드웨어가 완성되기 전에 제어 로직을 동결하는 것은 가상의 기계에 대한 가정을 동결하는 것일 뿐이다. 정말로 시간을 절약하는 접근법은 그 반대다――인터페이스 테스트 벤치(에뮬레이션)를 앞당기는 것. 설비가 현지에 도착하기도 전에 WCS 로직의 모든 분기를 가상 PLC에 대해 수천 번씩 돌린다. 실제 설비가 도착하면 커미셔닝은 디버깅이 아니라 검증이 된다. 가상 커미셔닝을 철저히 할수록 현지의 블랙홀은 작아진다.
트렌드: 가상 커미셔닝이 일정을 다시 쓰고 있다
WCS와 WES(창고 실행 시스템)의 경계가 흐려지고 있다. 더 많은 WCS 플랫폼이 오케스트레이션 기능을 흡수하고 있고, 한편 가상 커미셔닝 도구는 한때 현지에서 해야 했던 일을 사무실로 되돌려 놓고 있다. 통합 작업의 60퍼센트 이상을 설비 도착 전에 완료할 수 있다면, 공표된 세 구간――6주에서 12주, 3개월에서 5개월, 6개월에서 12개월――은 향후 몇 년 안에 각각 한 단계씩 아래로 내려갈지도 모른다.
하지만 거기에는 멈춰 서서 생각해볼 만한 질문이 있다. 커미셔닝이 더 이상 대규모 엔지니어링 팀의 수개월 현지 상주를 필요로 하지 않게 되면, 통합 업체의 비즈니스 모델은 어떻게 되는가. 일당 과금 모델이 먼저 무너질 것인가, 아니면 사업주가 먼저 절약된 일정의 가격 인하 전환을 요구할 것인가. WCS 구축 일정은 애초에 순수한 엔지니어링의 문제였던 적이 없다――그 밑에는 자동화 가치 사슬 전체의 이익 분배가 놓여 있다. 다음에 "소프트웨어 부분은 빨라요, 몇 주면 돼요"라고 들으면, 세 가지 질문을 던져보라. 인터페이스는 동결되었는가, 검수 기준은 계약서에 있는가, 에뮬레이션 환경은 구축되었는가. 그 답은 어떤 간트 차트보다 정확하게 진짜 가동일을 예측한다.
Dr. Chen, 공급망 연구원 지음
영어판 번역본입니다. 내용이 다를 경우 영어판을 우선합니다.






