롯데정보통신 현대홈쇼핑 화성 WCS 프로젝트 회고

현대홈쇼핑 화성 WCS 프로젝트는 권역분류, 반송분류 총 2개의 층에 같은 시스템을 적용하는 작은 규모의 프로젝트입니다.

작은 프로젝트

처음 프로젝트의 대략적인 개요를 들었을 때 가장 먼저 든 생각은 ‘이거 신입들 튜토리얼로 쓰면 딱이겠는데?’ 였습니다. 그만큼 규모가 크지 않았고 그만큼 물류자동화 대형 프로젝트를 하기 전 실무 맛을 볼 수 있는 알맞는 규모의 프로젝트였습니다.

물류 자동화의 전체 프로세스를 크게 보면 입고, 이송, 보관, 피킹, 분류, 합포, 출하로 볼 수 있습니다. 이번 프로젝트에서는 그 중에서도 오직 ‘분류’ 에 해당하는 영역만 담당하게됬습니다.

규모는 작은데 시간이 한 달밖에 없네

하늘은 저에게 꿀같은 프로젝트를 쉽게 허락하지 않나봅니다.

프로젝트 규모는 작았지만 개발 기간은 고작 한 달 이었습니다. 기능 자체는 크게 어렵지 않을 것 같았지만 문제는 웹 UI 였습니다.

저는 프론트엔드 개발이 가능하긴 하지만 전문적으로 많이 다뤄온 것은 아니기에 웹 UI 까지 모두 제 시간안에 완성하는 것은 조금 부담스러운 일이었습니다.

다행히 이번 프로젝트에는 고객사의 Frontend 와 BFF 서버를 담당할 개발자 두 분이 함께했습니다. 그리고 그 두 분 모두 이전에 프로젝트를 함께 진행했던 경험이 있었고 믿고 맡길 수 있는 개발자들이었습니다.

덕분에 저는 제가 맡은 영역에 집중할 수 있었습니다.

이슈가 예상되는 분류 프로세스

분류를 심플하게 바라보면 BCR 에서 바코드를 스캔하고, 스캔된 값을 바탕으로 어떤 상품인지 확인하고, 그 상품의 목적지를 판단한 다음 설비에 내려주는 과정 입니다.

대개 소터는 상당히 빠른 속도로 동작하기 떄문에 화물이 감지된 시점부터 목적지를 전달하기까지 주어지는 시간이 굉장히 짧습니다. 물류는 말 그대로 흐름 입니다. 목적지를 빠르게 판단하지 못하면 해당 화물이 분류되어야할 포인트를 지나쳐버릴 수 있습니다.

그런데 이번 프로젝트의 분류 프로세스는 조금 우려되는 부분이 있었습니다.

바코드를 읽으면 상위 WMS 에 HTTP 요청을 보내고, WMS 로부터 목적지를 응답받은 뒤 그 결과를 설비에 전달하는 구조였습니다.

이 말은 곧 상위 시스템에서 응답이 늦어지면 화물이 Reject 라인으로 빠질 수 있다는 뜻입니다. 당연히 이 프로세스에 의문을 제기한 사람이 한둘이 아니었던것 같습니다.

돌아온 답변은 간단했습니다.

2초 안에 무조건 응답을 줍니다.

조금 불안했습니다. 세상에 절대라는건 없거든요.

당장 문제가 발생하지 않더라도 상위 시스템의 응답 속도에 전체 분류 프로세스가 의존하고있는게 향후 문제될 가능성이 높아보였습니다. 그래서 혹시 모를 상황에 대비해 이 인터페이스 총 처리 및 응답 시간을 최대한 상세하게 기록해두어야겠다고 생각했습니다.

사실 일반적인 고속 소터라면 인터페이스의 레이턴시조차 아깝습니다. 빠르게 분류하기 위해 목적지 정보를 미리 하위 시스템에 전달하고, 실제 분류 시점엔 하위 시스템이 자체적으로 판단하도록 구성하는 경우가 많습니다.

결국 상위 시스템의 응답 속도 문제로 컨베이어 연장공사를 진행했습니다.

시스템의 구조

---
config:
  layout: elk
---
flowchart TB
    WCS["WCS Server"]

    BFF["BFF Server"]
    UI["UI"]
    DB["DB"]


    subgraph device["설비"]
        VISION_BCR["5면 BCR"]
        AUTO_LABELER["오토라벨러"]
        PLC["Conveyor PLC"]
    end

    VISION_BCR -- "Barcode Data" --> WCS
    VISION_BCR -- "Image File" --> WCS
    AUTO_LABELER -- "User Defined Protocol" --> WCS
    PLC -- "MC Protocol" --> WCS

    subgraph parent["상위"]
        SMS["롯데 SMS"]
        WMS["현대홈쇼핑 WMS"]
    end

    WCS -- "HTTP" --> SMS
    WCS -- "HTTP" --> WMS


    BFF -- "Command" --> WCS
    UI --> BFF

    BFF -- "Read Only" --> DB
    WCS --> DB

전체적인 시스템 구조는 단순합니다.

이번 프로젝트에서 우리가 담당하는 영역은 WCS Server, BFF (Backend For Frontend) Server, UI 입니다. 저는 그 중에서 WCS Server 를 담당하였습니다.

규모가 작은 프로젝트인 것은 분명했지만 그렇다고 해서 한 달이라는 일정이 여유로운 것은 아니었습니다. 오히려 짧은 기간 안에 설비부터 상위 시스템 등 여러 인터페이스를 연결해야하고 테스트해야하기때문에 꽤 부담되는 일정이었습니다.

아키텍처의 장점을 실전에서 보았다

이번 프로젝트에서는 책에서만 보던 아키텍처의 장점을 실제로 체감할 수 있는 순간이 있었습니다.

소프트웨어 아키텍처마다 세부적인 목표는 조금씩 다르지만 결국 중요한 공통점 중 하나는

의존성을 낮추는것

이라고 생각합니다.

프로젝트를 준비하면서 상위 WMS 에서 제공하는 인터페이스 중 FTP 로 데이터를 제공하는 인터페이스가 있었습니다. 그래서 FTP 로 파일을 읽고 파싱하는 로직을 준비했었습니다.

그런데 막상 현장에서는 HTTP API 방식으로 변경해달라는 요청을 받았습니다.

큰 부담이 되지 않았습니다. 우리 코어 서비스의 Infrastructure 방향의 호출은 인터페이스만 의존하도록 설계되어 있기 때문입니다.

코어 서비스 입장에서는 데이터를 FTP 를 통해 가져오든, HTTP API 를 통해 가져오든 어떻게 가져오는지는 중요하지 않습니다. 결과적으로 필요한 데이터를 반환해주기만 하면 됩니다. (DIP: Dependency Inversion Principle)

책에서 봐왔던 실제 요구사항이 바뀌는 상황이 나타나고 그걸 우리 시스템이 유연하게 바꿀 수 있어서 조금 기뻤습니다. 머리로 알고 있는것과 체감하는것은 역시 다르니까요.

마치며

이번 프로젝트를 통해 물류 시스템에서 인터페이스의 응답 속도가 얼마나 중요한지 그리고 설계 단계에서 생각했던 아키텍처의 장점이 실제 현장에서 어떻게 도움이 되는지 경험할 수 있었습니다.

책이나 문서에서 보던 내용을 실제 프로젝트에서 마주했을 때는 조금 다른 느낌이었습니다. ‘이론적으로는 이렇게 하는 게 좋다’고 알고 있던 것들이 실제 문제를 해결하는데 도움이 되는 경험을 하면서 왜 좋은 설계를 고민해야 하는지도 알 것 같았습니다.

규모는 작은 프로젝트였지만 개인적으로는 꽤 많은 것을 배울 수 있었던 프로젝트였습니다.