"삐빅, 삐빅." 1분 1초가 급박하게 돌아가는 물류센터. 이곳에서 현장 작업자의 손에 들린 PDA(산업용 단말기)의 작은 화면은 전쟁터의 레이더와 같습니다. 하지만 이 레이더가 낡고 해상도가 낮다면? 브라우저 툴바가 화면의 10% 이상을 차지하고, 키패드로 다음 단계를 넘어가려 해도 아무 반응이 없다면? 버튼이 작아서 장갑 낀 손으로는 화면 버튼이 제대로 안 눌린다면? 실제로 저희가 마주한 현실이었습니다.

이는 단순한 불편함을 넘어 물류 전체의 속도와 정확성을 저해하는 심각한 문제이자 저희가 개발하고 있는 WMS(Warehouse Management System) 의 사용자 경험(UX)에 대한 중요한 질문이기도 했습니다.

저희 조직은 이러한 문제를 해결하기 위해, 네이티브 앱이 아닌 웹 기술이라는 현실적인 선택을 했습니다. 그리고 PWA(Progressive Web App) 도입과 키패드 이슈 해결 등 현장 피드백을 통해 시스템을 개선하여 이번에 저 무계획이 대표로 올리브영 테크팀이 물류 현장의 '진짜' 목소리를 듣고, 이를 기술적으로 해결해 나간 생생한 여정을 담아 보았습니다.

포스트 작성은 처음이지만 비슷한 고민을 안고 있는 개발팀에게는 이 여정에서 얻은 인사이트가 분명 도움이 될 것이라 생각해 기록을 공유하니 많은 관심 부탁드립니다.

우리가 마주한 올리브영 물류 현장의 현실적 제약사항

물류센터 운영에는 다양한 프로세스가 존재합니다. 각 프로세스는 단일 시스템을 통해 관리되지만, 각 파트의 담당자들은 서로 다른 역할을 수행하며 지속적으로 데이터를 업데이트합니다. 그리고 그 프로세스는 다양한 형태의 인터페이스를 통해서 진행됩니다.

본격적인 진행에 앞서서 이번 프로젝트 진행시 존재했던 제약 조건들을 먼저 살펴보겠습니다.

1. 하드웨어의 한계: PDA 단말기는 일반 스마트폰에 비해 해상도, 처리 속도, 메모리 용량 등에서 제약이 많습니다. 이러한 제약은 복잡한 UI나 무거운 애플리케이션을 실행하는 데 어려움을 줍니다.
2. 사용 상황의 특성: 장갑을 끼고 한손으로 작업하는 경우가 많아, 작은 버튼이나 복잡한 인터페이스는 사용하기 어렵습니다. 또한, 물건을 이동하거나 들고있는 상황에서 빠르게 작업을 처리해야 합니다.
3. 개발 리소스 및 일정의 한계: 네이티브 앱 개발 및 운영을 위한 리소스가 부족했으며, 개발 일정 또한 넉넉하지 않았습니다.

PDA 단말을 통한 물류 작업

올리브영 물류센터의 상품관리 시스템은 PDA 디바이스를 핵심 인터페이스로 활용합니다. PDA의 내장 스캐너는 바코드(또는 QR코드)를 인식하여 시스템에 필요한 입력 데이터를 만들어냅니다. 이러한 스캔 데이터를 통해 작업자는 재고 관리, 상품 이동, 분류 등 다양한 물류 작업을 수행합니다.

물류센터 내 모든 상품은 물론, 물품 보관 설비인 랙(Rack)의 위치를 나타내는 로케이션까지 바코드로 관리하고 있습니다. 이를 스캔할 수 있는 PDA는 상품관리 영역 전반에서 정확한 데이터 입력을 위한 핵심적인 역할을 수행합니다.

PDA 디바이스에 최적화된 클라이언트를 제공하기 위해 네이티브 앱과 웹 앱 사이에서 많은 고민이 있었습니다. 하지만 개발 리소스 및 일정의 제약과 PDA의 단순 작업 위주 운영이라는 현실을 고려했을 때, 웹 기반 시스템이 가장 합리적인 선택이었습니다.

물론, 웹 기반으로 구현할 경우 PDA의 스캐너 기능을 웹에서 인식해야 한다는 기술적인 도전 과제가 남아 있었습니다. 그럼에도 불구하고 우리는 웹의 유지보수 용이성과 높은 개발 생산성이라는 장점을 극대화하기로 결정했습니다.

다음 표는 당시 우리가 고려했던 두 가지 방식의 장단점을 비교한 내용입니다.

1차 해결: 웹 기반 스캐너 연동 구현

위에서 말한 물류 현장의 현실적 제약사항들 앞에서, 저희가 가장 먼저 부딪힌 벽은 바로 '스캔 기능'이었습니다. 물류 작업의 핵심인데, 웹에서는 하드웨어 제어가 쉽지 않다는 딜레마가 있었습니다.

무엇보다 PDA 디바이스의 스캐너 기능을 웹에서 활용하려면 몇 가지 기술적 제약을 극복해야 했습니다. 웹 기반 시스템은 하드웨어와 직접적으로 연결되지 않아 스캔 이벤트를 감지하거나 입력 필드의 포커스를 세밀하게 제어하기 어렵기 때문입니다.

그럼에도 불구하고 저희는 개발 생산성과 유지보수의 용이성을 위해 웹 기반 시스템을 선택했고, 이 잠재적인 단점을 극복하는 데 집중했습니다.

가장 먼저 해결해야 할 문제는 스캔 데이터 처리였습니다. PDA 스캐너는 바코드를 인식한 후 그 결과값을 키보드 입력처럼 전달합니다. 저희는 이 특성을 활용해 특정 input 요소에 포커스를 유지시키고, 스캔된 문자열을 바로 처리하는 로직을 구현했습니다.

하지만 여기서 예상치 못한 문제가 발생했습니다. 일부 기기에서는 스캔 후 엔터(Enter) 입력이 누락되어 이벤트가 트리거되지 않았습니다. 이를 해결하기 위해 PDA 단말기 자체의 설정을 변경해, 스캔이 완료되면 항상 엔터 입력을 보내도록 구성했습니다.

더 나아가, 사용자가 손을 최소한으로 움직이도록 하기 위해 포커스 관리 로직을 고도화했습니다. 상위 컴포넌트에서 keydown 이벤트 리스너를 활용해 앱 전반에서 스캔 기능을 즉시 사용할 수 있게 했고, 각 비즈니스 로직에 맞춰 input을 유기적으로 초기화하도록 구현했습니다.

2차 해결: PWA 도입으로 사용성 극대화

서비스를 모바일 웹으로 제공하다보니 또 다른 불편사항이 존재했습니다. PDA 디바이스 특성상 화면의 크기와 해상도에 한계가 있습니다. 현장에서 사용하는 디바이스는 일반적으로 우리가 사용하는 스마트폰보다 해상도 사양이 더 좋지 않습니다. 이런 제한사항은 사용자들에게 보여줄 수 있는 영역을 더 좁게 만들었습니다. 특히 모바일 브라우저를 사용하기 때문에 상단의 툴바 영역을 추가적으로 제외해야 하므로 어플리케이션 노출 영역은 더더욱 좁아졌습니다.

이러한 제약을 해결하기 위해 PWA (Progressive Web App) 기술을 도입했습니다. 네이티브 앱 수준의 기능이 꼭 필요한 상황이 아니라면, PWA는 충분한 대안이 될 수 있습니다. 아래에서 PWA의 일반적인 장점을 살펴보겠습니다.

• 앱 설치한 후 캐싱으로 인한 데이터와 시간을 절약
• 변경한 콘텐츠만 업데이트할 수 있음
• 홈 화면에 앱 아이콘 적용 가능
• 전체화면으로 앱 실행 가능
• 시스템 알림 및 푸시 메시지 활용 가능

PWA 적용을 위해 다음과 같은 작업들을 진행했습니다.

1. Manifest 파일 생성: PWA의 메타데이터를 정의하는 manifest.json 파일을 생성했습니다. 이 파일에는 앱 이름, 아이콘, 시작 URL, 디스플레이 모드 등을 정의합니다. GMS는 vite 번들러를 사용하고 있어서 아래와 같이 vite.config.js에 작성했습니다.

// vite.config.js
   {  
      plugins: [
       VitePWA({
         registerType: 'autoUpdate',
         manifest: {
           name: '',
           short_name: 'GMS',
           start_url: '/',
           display: 'standalone',
           orientation: 'portrait-primary',
           background_color: '#fafafb',
           theme_color: '#000000',
           icons: [
             {
               src: '/icon_192x192.png',
               sizes: '192x192',
               type: 'image/png',
             },
             {
               src: '/icon_512x512.png',
               sizes: '512x512',
               type: 'image/png',
             },
           ],
         },
       }),
      ]
   }

2. 아이콘 이미지 등록: PWA 적용을 위해 특정 사이즈(192x192, 512x512)의 PNG 파일이 필수적입니다. 규격에 맞지 않는 경우 PWA가 올바르게 동작하지 않을 수 있습니다.

3. 홈 화면 설치 유도: 사용자에게 브라우저를 통해 앱 설치를 유도하고, 바탕화면에 바로가기 아이콘을 추가했습니다.

PWA 적용의 효과는 기대 이상이었습니다. 가장 큰 변화는 화면 활용도의 극적인 개선입니다.

기존 모바일 웹 환경에서는 브라우저 상·하단 UI가 약 10%의 화면을 차지했지만, PWA의 전체 화면 모드(display: 'standalone') 덕분에 이 영역을 모두 콘텐츠 표시 영역으로 활용할 수 있게 되었습니다. 저해상도 PDA 환경에서 이는 체감 성능을 높이는 매우 유효한 개선이었습니다. 또한, 홈 화면에 추가된 앱 아이콘은 작업자들이 매번 URL을 입력하거나 북마크를 찾아 헤맬 필요 없이, 터치 한 번으로 시스템에 바로 진입할 수 있게 하여 작업 시작 시간을 눈에 띄게 단축시켰습니다.

3차 해결: 현장 테스트를 통한 키패드 이슈 해결

PWA 도입으로 기술적 문제는 어느 정도 해결했다고 생각했습니다. 하지만 진짜 시험대는 따로 있었습니다. 바로 현장이었죠. 사실 서비스 개발 과정에서 실제 사용자의 목소리를 가까이에서 들을 기회는 쉽게 찾아오지 않는데, 이번 프로젝트에서는 작업자의 생생한 피드백을 들을 수 있는 귀중한 기회가 있었습니다. 특히 현장 테스트를 통해 PDA 시스템의 사용성을 크게 개선할 수 있는 핵심 인사이트들을 발견할 수 있었죠.

그 중 의미 있던 개선을 이룬 케이스를 다루려합니다. 화면에 input이 여러 개가 있는 경우 키패드 버튼을 통해서 next step으로 넘어가는 부분에 대한 개선이 필요했습니다.

PDA 작업자들은 주로 한 손으로 작업하며 빠르게 입력을 진행합니다. 그러나 기본 PDA에서 제공하는 키패드의 다음(→|) 버튼이 의도한대로 동작하지 않거나, 포커스가 엉뚱한 위치로 이동하는 경우가 있었습니다.

디바이스에 따라 결과가 다를 수 있지만, 일부 기기에서는 화면에 다중으로 input이 존재하는 경우 키패드의 다음(→|) 버튼이 submit이 아니라 다음 탭으로 이동으로 작동됩니다. 실 사용자는 submit이 적용되는 것을 원하기 때문에 이를 해결할 방법을 찾기 시작했습니다.

다양한 옵션과 함수를 사용해 보았지만 원하는 방향으로 작동하지 않았고, 시행착오를 거쳐서 방법을 찾아냈습니다. 특정 input에 포커스가 있는 경우 다른 input을 disabled 처리해서 다음(→|) 버튼을 submit으로 작동시켰습니다. 구현은 간단했지만, 그 효과는 명확했습니다. 이 로직을 적용한 후, 현장 작업자의 불편함은 해소되었습니다. 작은 아이디어 하나가 현장의 작업 효율에 미치는 긍정적인 영향을 직접 확인할 수 있었던 의미 있는 개선이었습니다.

프로젝트를 통해서 배우다

개선 작업 이후, 연속된 로케이션 조회시 초기화 프로세스 단계 제외할 수 있어 25% 이상의 작업 시간이 단축되었습니다. 또한 "PDA를 사용하는데 불편한 부분이 있다"라는 현장의 피드백이 사라졌습니다.

PDA 시스템 최적화 여정을 통해 저희는 다음과 같은 교훈을 얻었습니다. 이 글을 읽는 개발자분들 중 비슷한 고민을 안고 있는 분들께도 저희의 경험이 실질적인 도움이 되기를 바랍니다.

1. 현장으로 목소리를 들어봅시다: 완벽한 이론을 적용하는것도 필요하지만, 때에 따라 '왜 안 돼요?' 같은 현장의 목소리를 직접 듣는 것이 더욱 중요할 수 있습니다.
2. 작은 개선부터 적용합시다: 완벽한 솔루션을 기다리지 말고, 작은 불편함이라도 즉시 해결하며 시스템을 발전시켜 나가봅시다.
3. 현실적인 솔루션을 선택합시다: 저희가 네이티브 앱이 없어도 웹과 PWA만으로 충분히 문제를 해결할 수 있었던 것처럼, 주어진 제약 속에서 가장 효율적인 기술을 찾아야 집중합시다.

이렇게 만들어진 저희 GMS에 관심있는 분들은 시나브로우님의 아래 포스팅도 참고 부탁드립니다.

👉 제로베이스 WMS 구축기: Kafka 기반 분산 물류 시스템 설계와 Out-of-Order Events 해결