Juicycrunch Carrot Blog | 물류 자동화 개발자는 어떤일을 할까?

물류 자동화를 진로로 고민하는 분들께

안녕하세요. 물류자동화 분야에서 소프트웨어 엔지니어로 약 6년간 일해온 Moo입니다.

저는 처음 이 분야를 진로로 선택할 때 현업에서 일하고 있는 사람의 이야기를 솔직하게 들어보고 싶었습니다. 실제로 어떤 일을 하는지, 어떤 어려움이 있는지, 반대로 어떤 매력과 장점이 있는지 궁금했습니다.

무엇보다 이 길을 계속 따라간다면 미래의 나는 어떤 모습일까 하는 생각을 많이 했습니다. 그래서 이 글에서는 제가 약 6년간 물류자동화 개발자로 일하며 직접 경험한 이야기를 솔직하게 이야기해보려고 합니다.

물류 자동화란?

물류자동화란

물류의 흐름을 자동화하기 위해 설비와 소프트웨어를 연결하고 이를 통해 물류를 효율적으로 운영하는 분야.

ERP와 같은 일반적인 업무 시스템에서는 전산상의 데이터가 변경되는 것만으로도 하나의 업무가 완료될 수 있습니다. 예를 들어 실제로 물건이 움직이지 않았더라도 전산상으로는 상품 하나가 출고된 것으로 처리할 수 있습니다.

물류자동화에서는 실제 세계와 좀더 가깝습니다. 상태만 바꾸는것이 아니라 컨베이어, 소터, 셔틀, AGV와 같은 실제 설비의 동작으로 이어져야 합니다.

데이터 상태를 바꾸는 것에서 끝나는 것이 아닌 소프트웨어가 현실 세계의 움직임을 만들어낸다는 것.

저는 이것이 물류자동화의 가장 큰 특징이라고 생각합니다.

개발자가 하는 일

WES(Warehouse Execution System), WCS(Warehouse Control System), ECS(Equipment Control System) 라는 용어와 관련하여 당시 물류 업계에서는 여러 업체가 혼용해서 사용하고 있었습니다.

이 글에서는 용어의 혼선을 줄이기 위해 WES와 WCS를 구분하고 WCS와 ECS는 동일한 의미로 사용하겠습니다.

---
config:
  layout: elk
---
flowchart TD
    ERP["ERP"]
    WMS["WMS"]
    WES["WES"]
    USER["Operator"]

    subgraph scope["WCS (ECS), Field App"]
        WCS1["ACS (AGV Control System)"]
        WCS2["ASRS Controller"]
        WCS3["SMS (Sorter Management System)"]
        FIELD_APP["Field App"]
    end

    PLC1["PLC"]
    PLC2["PLC"]
    PLC3["PLC"]

    DEVICE1["설비"]
    DEVICE2["설비"]
    DEVICE3["설비"]

    ERP --> WMS --> WES

    USER --> WES
    USER --> FIELD_APP
    FIELD_APP --> WES

    WES --> WCS1
    WES --> WCS2
    WES --> WCS3

    WCS1 --> PLC1 --> DEVICE1
    WCS2 --> PLC2 --> DEVICE2
    WCS3 --> PLC3 --> DEVICE3

대부분의 물류자동화 프로젝트에서 역할을 계층별로 나누어 시스템을 구축해왔습니다. ERP와 WMS에서 물류 업무와 데이터를 관리하고 WES와 WCS가 물류의 흐름을 판단하고 제어합니다. 그리고 WCS의 명령은 PLC를 거쳐 실제 설비의 동작으로 이어집니다. 이 수많은 시스템이 하나의 물류 흐름을 만들어내기 위해 연결되어 있습니다.

WES 는 무엇일까?

WES (Warehouse Execution System) 는 사람으로 치면 두뇌 입니다. 대개 설비를 직접제어 하기보단 일종의 지휘관 역할을 합니다.

말 그대로 위의 추상적인 역할을 할 수 만 있으면 무엇으로 만들든 상관 없습니다. 저는 주로 Web Application 으로 많이 구성했었습니다.

WMS 연동

기준정보 연동 (아이템 마스터 등)
입고 예정정보 연동 or 입고 가능 품목 확인
출고 데이터 배치 데이터 처리
출고 결과 연동

WCS(ECS) 연동

사용자의 명령 (Command) 전송
설비 상태 공유

유저 인터페이스

로그인, 권한 등
현황 모니터링 (SCADA 와 유사)
입⋅출고, 알람등 각종 이력
출고 배치 생성 (출고 주문 데이터를 묶어서 처리)
리포팅

물류 서비스

박스⋅팔레트 목적지 판단
화물 로드 밸런싱
적재 위치 결정 (등급, 무게 기반, 랜덤 등)
출고⋅피킹 시 대상 재고 판단
재고 수량 관리
분류 목적지 판단
분류 결과 처리

위의 기능들은 어느 센터든 기본으로 들어갑니다. 당연히 센터별로 운영의 디테일이 다르기에 커스텀 기능들이 추가됩니다.

WCS(ECS) 는 무엇일까?

WCS(Warehouse Control System), ECS(Equipment Control System) 는 사람으로치면 손과 발 입니다. WES 의 Command 를 해석해 장비를 제어하는 PLC 가 이해할수있도록 번역하는 역할을 합니다.

WES는 물류의 흐름을 기준으로 어떤 작업을 수행할 것인지를 전달하고 WCS(ECS)는 이를 실제 설비가 이해할 수 있는 형태로 변환합니다. 그리고 설비와 직접 연결되는 만큼 안정적인 PLC 연결 관리 (Serial, Socket 등) 와 장애 상황에 대한 메시지 유실 방지가 기본입니다.

저는 주로 백그라운드에서 동작하는 서비스앱으로 제작하였고 필요에 따라 수동 조작, 통신 상태를 확인할 수 있는 간단한 UI를 함께 제공하기도 했습니다.

WES 연동

WES와의 통신 및 작업 정보 연동
WES에서 전달된 Command 해석
WES의 명령을 PLC가 이해할 수 있는 형태로 변환
설비 상태 및 처리 결과를 WES에 전달
통신 실패 시 재전송 및 버퍼 관리

PLC 연동

PLC 메모리 Read / Write
설비와의 사용자 정의 프로토콜 연동
안정적인 Socket 연결 및 재연결 처리
PLC 통신 장애 및 예외 상황 처리

성능에 민감한 물류자동화 시스템

물류자동화 시스템은 다른 시스템과 마찬가지로 안정성이 중요하지만 성능에도 상당히 민감한 분야입니다. 물류센터에서는 수많은 상품이 동시에 이동하기 때문에 작은 지연이 반복되면 전체 처리량에 영향을 줄 수 있습니다.

예를 들어 불필요한 Disk IO, 쿼리 하나가 오래 걸리면 개별 작업의 지연으로 끝나는 것이 아니라 컨베이어나 소터의 흐름에 영향을 주고 결국 센터 전체의 출고 처리 능력(Capacity) 까지 떨어질 수 있습니다.

일하면서 겪는 고충

어느 분야나 그 나름의 고충이 있습니다. 물류자동화 역시 마찬가지입니다.

물류자동화 분야를 선택하기 전에 현실적으로 고려해봐야 할 부분들이 있습니다. 직접 경험하면서 느꼈던 점을 솔직하게 이야기해보겠습니다.

타지 생활

물류자동화 프로젝트는 실제 물류센터나 공장에서 설비를 설치하고 개별 설비부터 전체 시스템까지 운영을 테스트하는 과정이 필요합니다. 따라서 개발자 역시 프로젝트 일정에 따라 현장에 장기간 머물러야 하는 경우가 많습니다.

문제는 이러한 현장이 도심과 떨어진 외진 곳에 있는 경우가 많다는 것입니다.

그리고 출장 기간이 짧게 끝나지 않는 경우도 많습니다. 프로젝트에 따라 몇 주에서 몇 달 동안 타지에서 생활해야 할 수도 있습니다.

처음에는 단순히 ‘출장을 가는 것’이라고 생각할 수 있습니다. 하지만 장기간 타지에서 생활하다 보면 생각보다 많은 것들이 달라집니다.

개인의 생활

가장 먼저 영향을 받는 것은 개인의 생활입니다.

집에서 기르던 반려동물을 돌보기 어려워집니다. 가족이나 지인의 도움이 필요하고 여의치 않다면 애견호텔과 같은 방법을 이용해야 합니다. 평소 당연하게 누리던 가족·연인·친구와의 만남도 어려워지고 취미활동에도 제약이 생깁니다.

단순히 일하는 장소가 바뀌는 것이 아닙니다. 장기간 타지에서 생활하다 보면 개인의 일상 상당 부분을 내려놓고 프로젝트 일정에 맞춰 생활해야 하는 상황이 생깁니다. 현장 중심의 프로젝트가 많은 만큼 장기 출장과 타지 생활을 감수해야 하는 경우가 있다는 점은 이 분야를 진로로 고민한다면 미리 진지하게 생각해볼 필요가 있습니다.

주말이 어디로갔지

주말은 온전히 쉬어도 항상 빠르게 지나갑니다. 출장 중에는 주말마저 온전히 쉬지 못하는 경우가 종종 있습니다.

예를 들어 금요일 저녁에 현장에서 집으로 올라와 일요일 밤 다시 현장으로 내려가야 한다면 실제로 제대로 쉴 수 있는 날은 토요일 하루 정도입니다. 이동에 걸리는 시간까지 생각하면 주말이 휴식이라기보다는 다시 현장으로 돌아가기 위한 짧은 공백처럼 느껴질 때도 있습니다.

아쉬운 이야기지만 주말근무도 꽤 잦은 편입니다. 물류자동화 프로젝트는 일정에 여유가 있는 경우가 많지 않습니다. 프로젝트에는 정해진 오픈 일정이 있습니다. 그런데 소프트웨어는 대부분 후공정에 해당합니다. 건설, 전기, 기계 설비가 먼저 들어오고 기계 단동까지 끝난 뒤에야 연동 테스트와 통합 테스트가 본격적으로 진행됩니다.

앞선 공정에서 일정이 지연되더라도 마지막 오픈 일정까지 함께 미뤄지는 것은 아닙니다. 오픈 일정에 맞춰 WMS, ERP와 같은 타 시스템 및 작업자 투입 일정까지 이미 잡혀 있기 때문입니다. 결국 앞선 공정에서 발생한 일정 지연은 후공정인 소프트웨어 개발 일정에 직접적인 영향을 끼칩니다.

개발자 입장에서는 테스트할 수 있는 시간이 줄어들지만 오픈 일정은 그대로인 상황이 발생합니다. 부족한 시간을 맞추기 위해 야근이나 주말근무가 발생하는 것도 이런 구조적인 이유가 큽니다.

사무실과는 다른 환경

사무실에서 개발하는 것과 현장에서 개발하는 것은 생각보다 큰 차이가 있습니다. 개인적으로는 사무실에서 자신의 개발 역량을 100이라고 한다면 현장에서는 40도 제대로 나오기 어렵다고 생각합니다.

소음, 추위와 더위, 먼지, 불편한 작업 환경은 물론이고 간이 책상과 의자는 필수로 챙겨가야합니다. 현장에서는 흔히 개발자들이 말하는 ‘좋은 환경’ 을 기대하기는 현실적으로 어렵습니다.

소프트웨어는 물리적 한계를 넘지못한다

WES 는 설비 레이아웃 위에서 운영을 소프트웨어로 녹여냅니다. 여기서 중요한건 레이아웃 입니다. 아쉽게도 소프트웨어는 레이아웃에 없는 길을 창조하지 못하고 설비가 할 수 없는 기능을 만들어낼 수 없습니다.

설비의 처리 속도가 초당 10개라면 소프트웨어가 아무리 빠르게 동작하더라도 그 이상의 물량을 처리할 수 없습니다. 결국 물류자동화 분야에서 소프트웨어의 역할중 하나는 이 레이아웃이 낼 수 있는 최고의 퍼포먼스를 만들어주는 것입니다.

위의 내용과는 조금 반대되는 이야기입니다만 반대로 경우에 따라서는 소프트웨어가 일부러 속도를 늦춰야 할 때도 있습니다.

물류자동화 시스템에서 가장 기본적인 연동 대상 중 하나는 PLC입니다. PLC는 정해진 스캔 주기에 따라 입력을 확인하고 로직을 실행한 뒤 출력을 갱신하는 과정을 반복합니다. 그런데 연동 방식에 따라서는 소프트웨어가 PLC가 데이터를 인지하기도 전에 메모리의 값을 다시 덮어쓰는 상황이 발생할 수 있습니다.

예를 들어 소프트웨어가 어떤 상태값을 매우 빠르게 A → B → C로 변경한다고 가정해보겠습니다. PLC의 스캔 주기가 이보다 느리다면 PLC는 A나 B를 확인하지 못하고 C만 확인하게 될 수도 있습니다. 이런 경우에는 소프트웨어를 무작정 빠르게 만드는 것이 해결책이 아닙니다.

PLC의 사이클 타임과 통신 주기 등을 고려해 적절한 속도로 데이터를 전달하거나 별도의 Handshake 나 Flag 등을 이용해 서로 처리 시점을 맞춰야 합니다. 가장 빠르게만 동작하는 소프트웨어가 중요한것이 아닙니다. 설비가 인지할 수 있는 속도로 정확하게 동작하는 소프트웨어가 더 중요합니다.

새벽, 명절에도 울리는 전화

물류센터는 24시간 365일 운영되는 경우가 많습니다. 시스템이 단 1시간만 멈춰도 그에 따른 손실도 상당합니다. 때문에 물류자동화 시스템에서는 무엇보다 안정성이 중요합니다.

문제는 시스템을 멈추게 만드는 원인이 생각보다 다양하다는 것입니다. 인프라, 네트워크, 전기, 설비, PLC, 소프트웨어 등 어느 한 곳에서 문제가 발생해도 전체 시스템이 멈출 수 있습니다. 그리고 이런 문제는 이상하게도 꼭 새벽 인것 같습니다.

새벽에도 주말에도 심지어 명절에도 문제가 발생하면 누군가는 원격으로 대응을 해야합니다.

규모가 큰 기업이라면 장애 대응을 담당하는 별도의 조직이나 당직 체계가 있을 수도 있습니다. 하지만 제가 경험했던 작은 규모의 회사에서는 개발자가 직접 대응해야 하는 경우도 많았습니다.

특히 신규 시스템을 오픈한 직후 1~2개월은 비교적 힘든 시기입니다. 기존 시스템에서 새로운 시스템으로 전환하는 과정에서 작업자들이 시스템에 적응해야 하고 예상하지 못했던 버그나 운영상의 문제가 발견되기도 합니다.

재미있는 사례도 있었습니다. 어느 날부터 비가 오면 이상하게 통신이 끊기는 문제가 발생했습니다. 처음에는 소프트웨어 문제를 의심했지만 원인은 전혀 다른 곳에 있었습니다.

물류센터의 도크장이 항상 열려 있다 보니 바닷바람과 습기에 노출된 네트워크 스위치에 문제가 발생하고 있었습니다. 비가 오고 습도가 높아지는 날이면 통신 장애가 발생했던 것입니다. 이처럼 현장에서 발생하는 문제가 반드시 소프트웨어 문제인 것은 아닙니다.

하지만 고객 입장에서는 가장 먼저 눈에 보이는 것이 소프트웨어입니다. 화면에 오류가 발생하거나 설비가 동작하지 않으면 우선 핫라인으로 연락하게 됩니다. 개발자는 코드만 작성하는 사람이 아니라 시스템 전체를 바라보고 어디에서 문제가 발생했는지 찾아내야 하는 역할을 하게 되는 경우가 많습니다.

직업 윤리

프로젝트를 하면서 기술적인 문제와는 별개로 마음이 불편했던 순간도 있습니다.

자동화가 진행되면 기존에 사람이 담당하던 업무가 줄어들거나 없어지는 경우가 있습니다. 무인지게차가 도입되는 프로젝트에 참여했을 때 기존에 지게차를 운전하시던 기사분들이 자동화 도입에 반대하는 시위를 하는 모습을 마주한 적이 있습니다.

물류자동화 시스템을 도입하며 생기는 효율이 누군가에게는 곧 자신의 일자리가 사라지는 이유가 될 수도 있다는 생각이 들었습니다.

물론 자동화가 반드시 누군가의 일자리를 없애는 것만을 의미하는 것은 아닙니다.

위험하거나 반복적인 작업을 기계가 대신하고 사람이 더 안전하고 가치 있는 업무에 집중할 수 있도록 만드는 것도 자동화의 중요한 목적입니다.

머리로는 알고있지만 실제로 마주하고나면 말로 표현하기 힘든 불편함이 있습니다.

아직도 정답이 무엇인지 모르겠습니다.

그럼에도 물류자동화는 매력이 있다!

물류 자동화는 제가 오랜시간 몸을 담아온 분야입니다. 분명 힘든일은 맞지만 그럼에도 불구하고 매력적인 분야입니다. 사람마다 원동력이 되는 포인트는 다르겠지만 저는 주로 오픈 성취감이 컸습니다.

실제로 움직이는 센터

오픈 당일 모든 엔지니어들이 모이고 VIP 도 지켜봅니다. 운영을 시작하고 로직에 따라 설비가 움직이고 컨베이어 위로 박스가 하나둘 흘러가는 모습을 보고 있으면 묘한 뿌듯함이 있습니다.

연동 테스트나 통합 테스트에서도 비슷한 장면을 볼 수 있습니다. 하지만 오픈 당일에 보는 모습은 어딘가 다르게 느껴집니다. 수개월 동안 설비와 씨름하고 예상하지 못한 문제를 해결하고 때로는 밤늦게까지 테스트했던 결과물이 실전에서 동작하는 것입니다.

코드로만 존재하던 것이 실제 세계에서 움직이는 모습은 꽤 매력적입니다.

해외로 나가볼 수 있는 경험

물류센터는 국내에만 있는 것이 아닙니다. 중국, 베트남, 미국, 유럽 등 세계 곳곳에 물류센터가 있고 그만큼 해외 프로젝트를 경험할 기회도 있습니다.

저 역시 물류자동화 프로젝트를 하면서 해외 현장을 경험할 수 있었습니다. 현지에 있는 개발자나 엔지니어를 직접 만나 서로 다른 시스템 사이의 인터페이스를 맞추며 협업하기도 합니다. 물론 해외 출장이 항상 즐겁기만 한 것은 아닙니다. 향수병에 고생하는 사람들도 있었습니다. 앞서 이야기한 것처럼 장기간 타지에서 생활해야 하는 부담도 있습니다.

하지만 프로젝트 일정에 여유가 있을 때는 현지 음식을 먹어보거나 주변을 둘러볼 수도 있습니다. 평소라면 쉽게 가볼 수 없는 나라에서 생활하고 그곳에서 사람들을 만나며 일할 수 있다는 것은 물류자동화 분야에서 얻을 수 있는 특별한 경험이라고 생각합니다.

일 때문에 방문했던 나라가 어느 순간 내 인생에서 특별한 추억이 있는 장소가 되어 있기도 합니다.

마치며

물류자동화는 힘든 만큼 얻는 것도 많은 분야라고 생각합니다. 저 역시 이 일을 하면서 힘든 순간이 많았습니다.

직접 설비가 움직이는 모습을 보고 해외 현장에서 사람들과 함께 일하고 하나의 물류센터가 완성되는 과정을 경험하면서 다른 분야에서는 쉽게 얻기 어려운 경험을 하는건 정말 큰 매력입니다. 물류자동화 개발자를 고민하고 있다면 장점과 단점 모두를 살펴보셨으면 합니다.

이 글이 물류 자동화 개발자로서의 진로를 고민하는 모든 분들께 조금이나마 도움이 되었으면 합니다.