PC 1대로 로봇 20대를 움직이다: 지속 가능한 E2E 테스트 인프라 구축기

물류 로봇 서비스를 개발하다 보면 가장 큰 벽에 부딪히는 지점이 있습니다. 바로 '실제로 로봇 수십 대가 동시에 움직일 때도 잘 작동할까?'라는 의문입니다.

로봇 한두 대를 테스트하는 건 어렵지 않습니다. 하지만 현장 환경, 로봇 설정, 시나리오가 제각각인 상황에서 수십 대의 로봇이 얽히며 발생하는 변수들을 사람이 일일이 확인하기란 불가능에 가깝습니다. 실제 로봇 수십 대를 매번 나열해두고 테스트할 수도 없는 노릇이고요.

이 고민 끝에 탄생한 '통합 시스템 연동 검증 플랫폼' 구축 과정을 나누어보려 합니다.

---

1. 왜 굳이 E2E 테스트였을까?

유닛 테스트나 통합 테스트는 각 부품이 고장 나지 않았음을 증명합니다. 하지만 로봇 서비스는 로봇 클라이언트 - 관제 서버 - 물류 서비스 서버 - 관리자 UI가 하나의 유기체처럼 움직여야 합니다.

API 하나가 정상이라도, 전체 흐름에서 타이밍이 어긋나면 로봇은 멈춥니다. 그래서 우리는 실제 사용자의 끝과 끝(End-to-End)을 연결해 '진짜로 동작하는지'를 확인해야만 했습니다. 연결 부위에서 발생하는 예상치 못한 균열을 찾는 것이 우리에겐 가장 중요한 숙제였기 때문입니다.

2. Playwright: 가장 빠르고 가벼운 선택

도구를 고를 때 가장 중요하게 본 것은 '병렬성'과 '격리성'이었습니다.

우리가 선택한 Playwright는 브라우저 컨텍스트를 활용해 세션을 매우 가볍게 분리해줍니다. 덕분에 10코어 남짓한 PC 한 대에서도 20개 이상의 로봇 세션을 안정적으로 띄울 수 있었습니다. 특별한 유료 서비스 없이도 워커(Worker)를 통해 병렬 처리를 극대화할 수 있다는 점은, 적은 자원으로 큰 효과를 내야 하는 우리 팀에게 최적의 선택지였습니다.

3. 시나리오가 아닌 '상태'에 반응하기

처음에는 고정된 순서의 스크립트를 짰지만, 금방 한계가 왔습니다. 네트워크 지연이나 예상치 못한 팝업 하나에 테스트가 깨지기 일쑤였죠.

그래서 우리는 '현재 화면 상태'를 보고 대응하는 동적 핸들러 방식을 택했습니다. 로봇 세션이 스스로 화면을 인식하고, "지금은 피킹 대기 중이니 피킹 작업을 하자", "지금은 이동 중이니 도착할 때 까지 기다리자"라고 판단하게 만든 것입니다.

graph TD
    A[테스트 실행: 로봇 세션 생성] --> B{화면 상태 체크 Loop}
    B -->|피킹 대기 화면| C[피킹 작업 핸들러 실행]
    B -->|이동 화면| D[이동 중 핸들러 실행]
    B -->|에러 화면| E[에러 데이터 수집 핸들러 실행]
    B -->|기타 상태| F[조건 대기 및 재시도]
    C --> B
    D --> B
    E --> B
    F --> B

이 방식은 테스트를 훨씬 유연하게 만들었습니다. 시나리오 순서가 조금 뒤섞여도 테스트는 멈추지 않고 계속됩니다. 덕분에 단순한 기능 확인을 넘어, 실제 로봇이 현장에서 겪을 법한 불규칙한 상황들을 미리 시뮬레이션해볼 수 있었습니다.

4. 테스트실을 넘어 '실제 현장'으로

이 도구의 진정한 가치는 예상치 못한 곳에서 발견되었습니다. 바로 신규 고객사 현장 구축 단계였습니다.

실제 로봇 수십 대를 현장에 풀기 전, 서버 설정이 올바른지 혹은 현장 네트워크 환경에서 다수의 연결이 원활한지 확인해야 하는 순간들이 있습니다. 이때 우리는 이 플랫폼을 활용해 수십 개의 세션을 실제 현장 서버에 한꺼번에 접속시켰습니다.

물리적인 로봇을 일일이 옮기거나 사람이 개입하지 않고도, 현장 환경 기반의 다수 로봇 주행 테스트와 동작 테스트를 앉은 자리에서 수행할 수 있게 된 것입니다. 이 과정을 통해 현장 투입 초기의 시행착오를 크게 줄일 수 있었고, 이는 곧 팀의 운영 효율로 이어졌습니다.

5. 병렬 테스트의 난제: 동시성 제어 서버 구축

테스트 규모가 커지고, 여러 대의 PC를 넘나들며 로봇을 제어해야 하는 상황이 오면서 새로운 기술적 난관에 부딪혔습니다. 수십 대의 로봇이 각기 다른 PC 환경에서 동시에 작업을 수행하다 보니, 한정된 자원(예: 바코드)을 중복으로 점유하려는 동시성 문제가 발생한 것입니다.

처음에는 로봇별로 사용할 데이터를 사전에 수동으로 나누어 할당했지만, 여러 PC에서 병렬로 로봇을 돌리며 동일한 바코드 풀(Pool)을 공유해야 하는 상황에서는 이 방식이 더 이상 통하지 않았습니다. 이를 해결하기 위해 우리는 NestJS와 PostgreSQL, TypeORM 기반의 전용 관리 서버를 구축했습니다.

• 중앙 데이터 스케줄링: 각 로봇 세션이 필요한 데이터를 서버에 실시간으로 요청하면, 서버가 가용한 자원을 할당해주는 구조로 전환했습니다.
• 트랜잭션과 락(Lock): 여러 로봇이 동시에 요청을 보낼 때 데이터가 겹치지 않도록, TypeORM의 트랜잭션 격리 수준과 DB 락을 활용해 동시성 이슈를 해결했습니다.

단순히 '바코드 할당'에서 시작한 이 서버는 점차 확장되어, 사람이 일일이 만들기 어려운 대규모 시뮬레이션용 목데이터(엑셀 작업 파일 등)를 자동으로 생성해주는 유틸리티 서버 역할까지 수행하게 되었습니다.

6. 데이터가 알려주는 시스템의 건강 상태

동시성 제어를 위해 구축한 서버는 점차 우리 팀의 통합 데이터 분석 플랫폼으로 진화했습니다. 각 로봇 세션이 서버와 통신하며 작업을 할당받는 구조가 갖춰지자, 이를 활용해 테스트 과정에서 발생하는 수많은 지표를 실시간으로 수집할 수 있게 된 것입니다.

테스트가 끝난 뒤 단순히 '성공' 메시지만 보고 넘어가는 것이 아니라, 서버에 쌓인 데이터를 통해 시스템의 미세한 징후들을 기록하기 시작했습니다.

• 에러 UI 포착: Playwright 세션이 화면을 탐색하다가 클라이언트가 정의한 에러 문구를 발견하면, 이를 서버로 전송해 즉시 데이터로 기록했습니다.
• 네트워크 복기: 문제가 생기면 당시의 HAR 로그와 통신 내역을 서버에 연동하여 무엇이 꼬였는지 추적했습니다.
• 지표 대시보드: 수집된 데이터를 바탕으로 기간별 에러 발생 추이를 시각화했습니다. 이를 통해 우리가 놓치고 있던 고질적인 문제들을 객관적인 데이터로 마주하게 되었습니다.

---

마치며: 품질은 '자유로움'에서 온다

이번 프로젝트를 통해 얻은 가장 큰 인사이트는 "테스트 인프라가 견고할수록 개발자는 더 자유롭게 도전할 수 있다"는 점입니다.

하드웨어가 없어도, 현장에 가지 않아도 내가 짠 코드가 수십 대의 로봇 사이에서 어떻게 작동할지 미리 알 수 있다는 확신. 그 확신이 팀의 개발 속도를 높이고 서비스의 품질을 단단하게 만들었습니다. PC 1대로 시작한 이 작은 플랫폼은 이제 우리 팀이 품질을 지키는 가장 든든한 동료가 되었습니다.