60대 부하 테스트와 MAPF 안정화 추진

왜 중요한가

확장 전에 운영 가능 기준을 수치로 정의하지 못하면, 병목을 버그 단위로만 보게 되어 규모 확대 판단이 흔들리기 때문이다.

60대 규모 확장 전, 운영 가능 기준을 수치로 정의하고 MAPF·제어·상태 전이 전반의 공통 병목을 식별해 안정화 우선순위를 다시 세운 사례.

배경

이 사례는 단순 성능 테스트 사례가 아니라, 운영 규모 확대 직전 시스템 공통 병목을 수치 기준으로 식별하고 우선순위를 재설계한 PO 사례로 정리돼 있다. 핵심 목표는 로봇 60대 / 시간당 송장 2,000 수준의 운영 가능성을 판단하는 것이었다. 주요 근거 문서는 제품 대시보드, RobotController + MAPF Regression Test, SGTC & MAPF Regression Test, [멀티오더] [1219테스트-1] 로봇 3대 태스크 속도 테스트다. 기준값 예시로 첫 태스크 20초 미만, 피킹/하차/복귀 5초 미만이 확인돼 있다.

문제 정의

핵심 문제는 “성능 테스트를 해야 한다”가 아니라, 확장 직전 시스템이 어느 수준까지 운영 가능한지 판단 기준이 불명확했다는 점이다. review note는 이를 RobotController + MAPF + Task 상태 전이 전반의 공통 병목으로 설명한다. 운영 규모를 60대로 확장하기 전에 기준 없이 테스트만 반복하면, 무엇이 blocker인지 정의되지 않은 채 QA와 개발 리소스가 분산될 위험이 있었다.

가설

먼저 “운영 가능 수준”을 수치로 정의해야 병목을 올바르게 식별할 수 있다.
60대 부하 테스트, MAPF 회귀, SGTC 회귀, 소규모 속도 테스트를 하나의 근거 체계로 묶으면 공통 병목을 더 정확하게 볼 수 있다.
기능별 버그 분류보다 상태 전이·제어 구조·병렬 처리 병목 관점으로 문제를 재구성하면 실제 우선순위가 선명해진다.
이 케이스의 review note는 테스트 자체보다 운영 가능 수준 정의를 먼저 둔 것이 핵심이라고 명시한다.

실행

로봇 60대 / 시간당 송장 2,000을 목표 scale로 두고 안정화 판단 기준과 연결했다.
첫 태스크 20초 미만, 피킹/하차/복귀 5초 미만과 같은 threshold를 판단 기준으로 활용했다.
3대 테스트에서도 20~30초 지연, 무한로딩이 드러난 점을 주요 경고 신호로 사용했다.
60대 부하 테스트, MAPF 회귀, SGTC 회귀를 하나의 안정화 근거 체계로 묶었다.

검증

제품 대시보드는 운영 상태와 이상 징후를 보는 근거로 연결됐다.

RobotController + MAPF Regression Test, SGTC & MAPF Regression Test는 시스템 병목을 재현·확인하는 핵심 검증 축이었다.
[멀티오더] [1219테스트-1] 로봇 3대 태스크 속도 테스트는 작은 규모에서도 병목이 이미 존재했다는 조기 경고 근거였다.
테스트 기준값과 실제 관측값의 차이를 통해, 문제를 개별 이슈가 아니라 확장 전 구조적 blocker로 해석할 수 있었다.