MBSE 기반 지하물류 요구사항 관리와 추적성 확보

지하물류 시스템은 도시철도, 역사 시설, 물류거점, 자동이송장비, 정보통신망, 작업자, 최종 배송수단이 하나의 운영목표를 중심으로 연결되는 복합 시스템이다. 이러한 시스템을 구축할 때 가장 어려운 문제는 특정 장비의 성능을 높이는 것이 아니라 서로 다른 기관과 기술이 요구하는 조건을 하나의 구조로 정리하는 일이다.

 

철도 운영기관은 열차의 안전과 정시성을 최우선으로 고려한다. 물류기업은 처리량, 배송시간, 운영비를 중요하게 생각한다. 역사 관리자는 승객 동선과 피난 안전을 보호해야 하며, 로봇 운영사는 자동이송장비의 안정적인 이동환경을 요구한다. 지방자치단체는 도심 교통량과 탄소배출 감소라는 공공적 성과를 기대한다.

 

이러한 요구사항은 서로 충돌할 수 있다. 화물 운송량을 늘리면 물류 효율은 높아질 수 있지만 열차 정차시간과 역사 혼잡도가 증가할 가능성이 있다. AGV의 이동속도를 높이면 처리시간은 단축되지만 승객과의 충돌 위험은 커질 수 있다. 물류공간을 확대하면 보관능력은 증가하지만 승객 편의공간이나 시설관리 공간이 줄어들 수 있다.

 

따라서 지하물류 시스템에서는 요구사항을 문서로 정리하는 수준을 넘어 요구사항과 기능, 시스템 구성요소, 인터페이스, 시험항목, 운영데이터를 하나의 모델로 연결해야 한다. 이를 가능하게 하는 방법이 모델기반 시스템엔지니어링, 즉 MBSE다.

MBSE라 불리는 모델기반 시스템엔지니어링 통한 통합되고 일관된 결과를 산출한다.

문서 중심 관리의 한계

전통적인 시스템 개발에서는 요구사항, 설계도, 운영절차, 시험계획을 서로 다른 문서로 관리하는 경우가 많다. 요구사항은 한글이나 워드 문서에 작성되고, 시스템 구조는 별도의 도면으로 표현되며, 시험결과는 엑셀 파일이나 보고서에 정리된다.

 

소규모 시스템에서는 이러한 방식도 일정 수준까지 작동할 수 있다. 그러나 지하물류처럼 여러 조직과 시스템이 참여하는 사업에서는 문서 사이의 관계를 파악하기 어렵다. 요구사항이 변경됐을 때 어떤 설계와 시험항목을 수정해야 하는지 즉시 확인하기 힘들다.

예를 들어 ‘열차 정시 운행에 영향을 주지 않아야 한다’는 요구사항이 변경돼 화물 적재 허용시간이 3분에서 2분으로 단축됐다고 가정해 보자. 이 변경은 하역장비 성능, AGV 이동계획, 화물용기 규격, 작업자 수, MFC 보관계획에 영향을 줄 수 있다.

 

그러나 관련 내용이 여러 문서에 흩어져 있으면 일부 항목이 누락될 가능성이 있다. 시험계획에는 기존 3분 기준이 남아 있고 운영절차만 2분으로 변경되는 상황도 발생할 수 있다. 이러한 불일치는 실증 현장에서 작업 지연이나 안전 문제로 이어질 수 있다.

 

MBSE는 문서를 없애는 방법이 아니라 문서에 분산된 정보를 하나의 시스템 모델로 연결하는 접근이다. 요구사항과 시스템 구조 사이의 관계를 명시하고, 변경이 발생했을 때 영향을 받는 요소를 추적할 수 있도록 한다.

이해관계자의 요구를 운영 가능한 조건으로 바꿔야 한다

지하물류 사업 초기에 제시되는 요구는 대부분 추상적이다. 대표적으로 ‘안전하게 운영해야 한다’, ‘승객에게 불편을 주지 않아야 한다’, ‘물류 효율을 높여야 한다’, ‘친환경적인 시스템을 구축해야 한다’와 같은 표현이 사용된다.

 

이러한 문장은 사업의 방향을 설명하는 데는 도움이 되지만 실제 설계와 검증에는 바로 사용할 수 없다. 시스템엔지니어링에서는 이를 측정하고 시험할 수 있는 요구사항으로 구체화해야 한다.

 

‘승객에게 불편을 주지 않아야 한다’는 요구는 다음과 같이 분해할 수 있다. 물류장비는 승객 혼잡도가 정해진 기준 이상일 때 운행을 중지해야 하고, 승객용 통로의 최소 폭을 침범해서는 안 되며, 물류작업은 지정된 비첨두시간에 수행해야 한다.

 

‘열차 운행에 영향을 주지 않아야 한다’는 요구는 화물 적재와 하역이 지정된 정차시간 안에 완료돼야 하고, 작업이 지연될 경우 자동으로 중단돼야 하며, 열차 출발 신호보다 물류작업이 우선할 수 없다는 조건으로 구체화할 수 있다.

 

‘친환경적이어야 한다’는 요구도 단순한 선언에 그쳐서는 안 된다. 기존 화물차량 운행거리 대비 감소율, 화물 한 개당 에너지 사용량, 탄소배출 절감량, 전기 배송수단 전환 비율과 같은 지표로 표현해야 한다.

 

요구사항은 명확하고 검증 가능해야 한다. 누가 읽더라도 같은 의미로 이해할 수 있어야 하며 충족 여부를 시험이나 분석으로 판단할 수 있어야 한다.

요구사항을 계층적으로 분해하는 과정

MBSE에서는 상위 수준의 사업목표를 하위 수준의 시스템 요구사항으로 단계적으로 분해한다. 이를 요구사항 계층구조라고 볼 수 있다.

 

가장 상위에는 도시물류 문제 해결이라는 사업목표가 있다. 그 아래에는 도심 화물차량 감소, 철도 유휴용량 활용, 배송 정시성 확보, 승객 안전 보호, 물류비 절감과 같은 주요 목표가 배치된다.

 

이러한 목표는 다시 시스템 요구사항으로 나뉜다. 배송 정시성을 확보하려면 열차 출발시간과 화물 적재계획이 연계돼야 한다. 화물이 출발역에 지정된 시간까지 도착해야 하며, 도착역에서는 정해진 시간 안에 하역과 분류가 완료돼야 한다.

 

승객 안전을 보호하려면 승객과 물류 동선을 분리해야 한다. 분리가 불가능한 구간에서는 시간대 분리, 속도 제한, 장애물 감지, 비상정지와 같은 보완수단을 적용해야 한다.

 

하위 요구사항은 다시 열차, AGV, 엘리베이터, MFC, 관제시스템, 통신망 등 각 시스템 구성요소에 할당된다. 이 과정을 통해 어떤 시스템이 어떤 요구를 책임지는지 명확해진다.

 

요구사항을 지나치게 세분화하면 관리가 복잡해질 수 있고, 반대로 너무 포괄적으로 작성하면 검증이 어려워진다. 따라서 설계와 시험에 직접 연결할 수 있는 적정 수준으로 분해해야 한다.

요구사항과 기능을 연결해야 한다

요구사항이 정의됐다고 해서 시스템 구조가 자동으로 결정되는 것은 아니다. 시스템이 요구사항을 충족하기 위해 어떤 기능을 수행해야 하는지 분석해야 한다.

 

지하물류의 주요 기능에는 화물 접수, 분류, 보관, 이송, 열차 적재, 철도 운송, 하역, 최종 배송 인계, 상태 추적, 장애 대응이 포함된다.

 

예를 들어 ‘화물 오배송률을 줄여야 한다’는 요구사항은 화물 식별, 목적지 확인, 적재 위치 기록, 하역 검증 기능과 연결된다. ‘열차 지연 시 물류운영을 재계획해야 한다’는 요구사항은 열차 지연정보 수신, 영향 분석, AGV 작업 재배정, 배송기사 도착시간 조정 기능과 연결된다.

 

이처럼 요구사항과 기능을 연결하면 시스템이 왜 특정 기능을 가져야 하는지 설명할 수 있다. 필요성이 불분명한 기능을 줄이고 핵심 기능에 자원을 집중하는 데도 도움이 된다.

 

기능 분석에서는 정상적인 운영뿐 아니라 비정상 상황에서 필요한 기능도 포함해야 한다. AGV 고장, 통신 단절, 화물 오분류, 엘리베이터 운행 중단, 열차 지연, 화재경보 발생 상황에서 시스템이 무엇을 해야 하는지를 정의해야 한다.

기능을 실제 시스템에 할당하는 방법

기능이 정의되면 이를 수행할 시스템 구성요소를 결정해야 한다. 이를 기능 할당이라고 한다.

 

화물 위치 추적 기능은 물류관리시스템만의 역할이 아니다. 화물에 부착된 식별장치, AGV 관제시스템, 열차 적재정보, MFC 입출고 기록이 함께 연결돼야 한다. 비상정지 기능도 AGV 자체 장치, 역사 관제시스템, 작업자 제어장치가 함께 작동할 수 있다.

 

하나의 기능이 여러 시스템에 분산되면 인터페이스가 중요해진다. AGV가 화물을 엘리베이터로 운반하려면 엘리베이터 호출, 탑승 권한, 목적층 입력, 도착 확인정보를 교환해야 한다.

 

기능 할당 과정에서는 자동화 수준도 결정해야 한다. 모든 판단을 인공지능이나 자동시스템에 맡길 것인지, 운영자의 승인을 거치게 할 것인지 구분해야 한다.

 

예를 들어 열차 지연 시 화물 운송계획을 자동으로 다시 계산할 수 있지만 실제 운송 취소는 운영자가 승인하도록 설계할 수 있다. 승객 밀집도가 증가하면 AGV가 자동으로 정지하되 운행 재개는 관제자의 확인 후 이루어지도록 설정할 수도 있다.

 

자동화 수준은 효율성만으로 결정해서는 안 된다. 안전성, 책임소재, 장애 대응능력, 운영자의 상황 인지능력을 함께 고려해야 한다.

인터페이스 요구사항을 별도로 관리해야 한다

지하물류 시스템의 문제는 개별 장비보다 시스템 사이의 경계에서 발생할 가능성이 높다. 따라서 인터페이스 요구사항을 별도로 정의하고 관리해야 한다.

 

물리적 인터페이스에는 화물용기와 열차 적재공간의 규격, AGV와 엘리베이터의 탑승 조건, MFC 출입구의 폭과 높이가 포함된다. 정보 인터페이스에는 열차 운행정보, 화물 위치정보, AGV 상태정보, 시설 장애정보의 데이터 형식과 전송주기가 포함된다.

 

운영 인터페이스도 중요하다. 화물을 누가 열차에 적재하고 누가 하역하는지, 장애 발생 시 어느 기관이 우선 대응하는지, 승객 안전과 물류운영이 충돌할 때 누가 작업중단을 결정하는지를 명확하게 정의해야 한다.

 

예를 들어 철도 운영기관과 물류기업이 서로 다른 장애등급 기준을 사용하면 동일한 상황에 대해 다른 판단을 내릴 수 있다. 이를 방지하려면 경보단계, 대응시간, 책임기관, 보고절차를 공통으로 설정해야 한다.

 

MBSE 모델에서는 시스템 구성요소 사이의 연결관계를 표현하고 각 연결에 필요한 요구사항을 배치할 수 있다. 특정 시스템이 변경됐을 때 영향을 받는 인터페이스를 빠르게 찾을 수 있다는 장점이 있다.

추적성은 요구사항에서 운영결과까지 이어져야 한다

추적성이란 하나의 요구사항이 어디에서 시작됐고 어떤 설계와 기능, 시험항목으로 연결됐는지를 확인할 수 있는 능력이다.

상위 요구사항이 하위 요구사항으로 어떻게 분해됐는지 추적하는 것을 하향 추적성이라고 할 수 있다. 반대로 특정 장비나 기능이 어떤 요구사항을 충족하기 위해 존재하는지 확인하는 것은 상향 추적성이다.

 

추적성이 확보되면 불필요한 기능을 식별할 수 있다. 어떤 기능도 요구사항과 연결되지 않는다면 그 기능의 필요성을 다시 검토해야 한다. 반대로 어떤 요구사항도 기능이나 시스템에 할당되지 않았다면 설계 누락 가능성을 확인해야 한다.

 

지하물류에서는 요구사항과 시험항목 사이의 추적성이 특히 중요하다. ‘AGV는 승객과 최소 안전거리를 유지해야 한다’는 요구사항이 있다면 실제 시험에서 안전거리를 측정해야 한다. 디지털트윈 시뮬레이션과 현장 실증 데이터를 이용해 다양한 혼잡조건에서도 기준이 지켜지는지 검증해야 한다.

 

‘화물 하역은 열차 정차시간 안에 완료돼야 한다’는 요구사항은 반복적인 하역 시험과 운영데이터로 검증할 수 있다. 평균시간뿐 아니라 최대시간과 실패율도 함께 확인해야 한다.

디지털트윈을 이용한 지속적 요구사항 검증

기존 시스템 개발에서는 구축 완료 전 시험단계에서 요구사항을 검증하는 경우가 많다. 그러나 지하물류는 물동량, 승객 수요, 열차 운행조건이 계속 달라지기 때문에 초기 시험만으로는 안정성을 보장하기 어렵다.

 

디지털트윈을 활용하면 운영 중에도 요구사항 충족 여부를 지속적으로 확인할 수 있다. 실제 AGV 위치정보와 승객 혼잡도 데이터를 분석해 안전거리 기준이 지켜졌는지 확인할 수 있다.

 

열차 운행정보와 화물 적재기록을 연결하면 물류작업이 정차시간에 영향을 주었는지도 분석할 수 있다. MFC 재고량과 반출시간을 이용하면 화물 적체 기준을 초과했는지 확인할 수 있다.

 

이러한 구조에서는 요구사항이 정적인 문장이 아니라 운영데이터와 연결된 관리기준으로 작동한다. 기준을 초과하면 경보를 발생시키고, 반복되는 문제는 시스템 설계나 운영절차 개선으로 이어질 수 있다.

 

디지털트윈 모델에서 새로운 운영조건을 먼저 시험할 수도 있다. 화물량을 늘리기 전에 열차 정차시간과 AGV 처리능력에 미치는 영향을 시뮬레이션하고 요구사항 위반 가능성을 확인하는 방식이다.

요구사항 변경관리가 필요한 이유

지하물류 시스템은 실증과 운영과정에서 계속 변경된다. 새로운 역사로 노선이 확대되거나 화물 종류가 추가될 수 있다. AGV 성능이 개선되고 열차 운행계획이 변경되며 새로운 안전기준이 적용될 수도 있다.

 

변경 자체보다 위험한 것은 변경이 전체 시스템에 미치는 영향을 충분히 분석하지 않는 것이다. AGV 속도를 높이는 변경은 처리량을 증가시킬 수 있지만 안전거리, 제동거리, 통신주기, 배터리 사용량에 영향을 줄 수 있다.

 

MBSE에서는 요구사항이나 시스템 요소를 변경할 때 연결된 기능, 인터페이스, 시험항목을 함께 확인할 수 있다. 변경 사유, 승인자, 적용시점, 재시험 결과를 기록하면 시스템의 구성 상태를 체계적으로 관리할 수 있다.

 

중요한 변경은 디지털트윈에서 먼저 검증하는 것이 바람직하다. 실제 운영에 적용하기 전에 다양한 물동량과 혼잡조건에서 안전성과 효율성을 비교할 수 있다.

실증사업의 평가체계와 연결해야 한다

지하물류 실증사업은 기술이 작동했다는 사실만으로 성공을 판단해서는 안 된다. 초기 요구사항에서 제시한 목표가 실제로 달성됐는지를 확인해야 한다.

 

평가지표는 안전성, 운영성, 물류성능, 경제성, 환경성, 이용자 영향으로 구분할 수 있다. 안전성에는 사고 발생 여부, 비상정지 성공률, 승객과 물류 동선의 충돌 횟수가 포함될 수 있다.

 

운영성에는 열차 운행 영향, 장애 복구시간, 시스템 가동률이 포함된다. 물류성능에는 시간당 처리량, 배송시간, 오분류율, 재고 회전율을 적용할 수 있다.

 

경제성은 운영비, 인건비, 장비 유지비, 기존 배송체계 대비 절감비용으로 평가할 수 있다. 환경성은 화물차 운행거리 감소, 에너지 소비량, 탄소배출 절감효과를 분석할 수 있다.

 

이러한 지표는 사업 종료 시 새롭게 만드는 것이 아니라 초기 요구사항 단계에서 결정해야 한다. 그래야 필요한 데이터를 사전에 수집하고 객관적으로 성과를 판단할 수 있다.

MBSE는 지하물류 협업의 공통 언어다

지하물류 사업에는 철도, 물류, 로봇, 정보통신, 건축, 안전 분야의 전문가가 참여한다. 각 분야는 서로 다른 용어와 설계방식을 사용하기 때문에 의사소통 과정에서 오해가 발생할 수 있다.

 

MBSE 모델은 시스템이 어떤 목표를 가지고 어떤 기능과 구조로 작동하는지를 공통된 형태로 보여준다. 철도 전문가는 열차 운행과 안전조건을 확인하고, 물류 전문가는 화물 흐름과 처리시간을 분석할 수 있다. 로봇 전문가는 AGV의 기능과 인터페이스를 확인하고, 운영기관은 책임과 대응절차를 검토할 수 있다.

 

모든 참여자가 동일한 모델을 공유하면 변경사항과 의사결정 근거를 투명하게 관리할 수 있다. 다만 모델링 자체가 목적이 되어서는 안 된다. 지나치게 복잡한 모델은 현장 운영자가 이해하거나 활용하기 어려울 수 있다.

 

필요한 수준의 모델을 구축하고 실제 설계, 시험, 운영 의사결정에 사용하는 것이 중요하다. 모델의 정교함보다 요구사항 누락과 인터페이스 오류를 줄이는 것이 우선이다.

지하물류의 성공은 요구사항 연결에서 시작된다

지하물류는 새로운 운송수단을 추가하는 사업이 아니라 기존 철도와 도시물류체계를 다시 연결하는 사업이다. 다양한 기관과 기술이 참여하기 때문에 초기 요구사항을 명확히 정의하지 않으면 실증단계에서 충돌과 변경이 반복될 수 있다.

 

MBSE는 사업목표와 이해관계자 요구를 기능과 시스템 구조로 연결한다. 요구사항이 어느 장비와 조직에 할당됐는지 확인하고 시험과 운영데이터를 통해 충족 여부를 검증할 수 있게 한다.

 

디지털트윈이 결합되면 이러한 추적성은 운영단계까지 확장된다. 요구사항이 실제 현장에서 지켜지고 있는지 지속적으로 확인하고, 문제가 발생하면 관련 설계와 운영절차를 개선할 수 있다.

 

결국 지하물류에서 MBSE의 가치는 그림이나 모델을 만드는 데 있지 않다. 복잡한 시스템 안에서 무엇을 왜 만들어야 하는지 명확히 하고, 설계부터 운영까지 일관성을 유지하는 데 있다.

 

요구사항, 기능, 구조, 인터페이스, 시험, 운영데이터가 하나의 디지털 스레드로 연결될 때 지하물류 시스템은 일회성 실증을 넘어 확장 가능하고 관리 가능한 도시 인프라로 발전할 수 있다.