Read Original
#Frontend

태블릿을 없애자 생긴 문제

태블릿을 없애자 생긴 문제
01

Summary

태블릿을 없애니 GPS 오차가? 무신사가 실내 위치 오차와 사투를 벌인 이야기

공용 태블릿 대신 개인 스마트폰 QR 대기를 도입하며 마주한 GPS 음영 구역 극복기와 프론트엔드 해결책

무신사 오프라인 스토어의 대기 경험을 개선하기 위해 외부 솔루션을 걷어내고 무신사 계정 연동형 QR 웨이팅 시스템을 자체 구축한 개발 여정입니다. 이 과정에서 발생한 심각한 실내 GPS 오차와 지오코딩 한계를 극복하기 위해 매장 운영자가 직접 현장 좌표를 등록하고 반경을 실시간 조정할 수 있게 한 현실적인 어드민 개선 방안과 프론트엔드 비동기 최적화 기술을 소개합니다.

  • 01공용 태블릿을 대체하는 개인 스마트폰 QR 기반 웨이팅 서비스 내재화
  • 02지오코딩 변환 주소의 한계와 실내 환경에서 수십 미터 이상 발생하는 GPS 오차 문제 분석
  • 03배포 과정 없이 실시간 현장 테스트에 유연하게 대응하기 위한 피처 플래그 도입
  • 04운영자가 현장 QR 안내판 옆에 서서 직접 정확한 좌표를 등록하고 반경을 조절할 수 있도록 어드민 고도화
  • 05비동기 위치 조회 요청이 꼬여 화면 상태가 오염되는 레이스 컨디션을 runId 체크 기법으로 해결

RECOMMENDATION

오프라인 공간과 결합된 모바일 웹 서비스를 개발 중이거나, 실내 GPS 수신 문제 및 비동기 상태 제어에서 실무적인 해결 팁을 얻고 싶은 프론트엔드 엔지니어에게 추천합니다.

The Problem

무신사 웨이팅 서비스에서 기존 공용 태블릿과 외부 솔루션 대신 무신사 계정 기반의 QR 코드 대기 접수 방식을 도입하려 했으나, 고객의 실제 매장 방문 여부를 확인하는 과정에서 실내 GPS 오차 및 지오코딩 좌표 불일치로 인해 대기 등록이 불가능한 현상이 발생했습니다.

The Solution

임시 대응으로 피처 플래그를 적용하여 프론트엔드에서 매장 좌표를 수동으로 덮어썼으며, 이후 매장 운영자가 어드민 환경에서 직접 대기 장소에 서서 GPS 좌표를 찍어 기준점을 설정하고 접수 반경을 자유롭게 커스텀할 수 있는 시스템을 구축했습니다. 비동기 위치 조회 시 발생하는 레이스 컨디션 문제는 runId와 Ref 객체를 활용한 최신 요청 검증 로직으로 제어했습니다.

The Result

개발자가 수동으로 좌표를 배포하거나 관리하는 공수 없이도 매장 운영자가 실시간 현장 상황에 맞춰 접수 반경을 유연하게 수정할 수 있게 되었으며, 오프라인 인프라 추가 설치 비용 없이 대기 서비스를 신속하게 확장할 수 있는 기반을 마련했습니다.

Trade-off

위치 정보 기반(GPS)의 근본적인 한계로 인해 통신 환경에 따른 하드웨어적 수신 편차는 완전히 극복하기 어려우며, 매장 밖에서의 어뷰징 차단과 실내 정상 고객의 접수 편의성 사이에서 반경 임계값 설정에 대한 합리적인 트레이드오프 조율이 항상 요구됩니다.

03

Key Concepts

Concept · 01

Geolocation API

사용자의 동의 하에 위도와 경도 등 지리적인 위치 정보를 브라우저 및 디바이스를 통해 조회할 수 있는 웹 표준 인터페이스입니다. 실내나 고층 빌딩 숲에서는 위성 신호 수신이 불가능해 Wi-Fi AP 및 이동통신 기지국 데이터를 기반으로 추정하므로 측정 오차가 수십 미터까지 증가할 수 있습니다.

  • 고객이 매장 현장에 실제로 방문했는지 검증하기 위한 핵심 기술로 활용되었습니다.
  • 실내 공간의 수평 오차로 인해 접수 반경 10m 기준에서 고객들이 등록에 실패하는 문제를 유발했습니다.
Concept · 02

Geocoding

텍스트 형식의 주소 정보를 컴퓨터가 인식할 수 있는 위도와 경도의 지리적 좌표로 변환하는 기술입니다. 일반적으로 주소지의 행정적 대표 중심점을 반환하기 때문에 실제 고객이 출입하고 줄을 서는 실제 접수처 위치와 어긋날 수 있습니다.

  • 초기 무신사 매장 주소를 바탕으로 접수 기준 좌표를 잡는 데 사용되었습니다.
  • 주소 기반의 한 좌표를 인접한 다수의 매장이 공유하는 문제가 발생하여 직접 입력 방식으로 변경하는 계기가 되었습니다.
Concept · 03

Race Condition Handling

여러 비동기 연산이 동시에 수행될 때 연산 완료 순서에 따라 공유 자원이나 화면 상태가 의도치 않게 오염되는 경쟁 상태를 예방하고 순서를 제어하는 기법입니다.

  • 위치 정보를 새로 요청할 때마다 runId 값을 1씩 증가시키며 최신 요청 여부를 식별했습니다.
  • 이전 요청의 응답이 늦게 도착하더라도 현재의 화면 상태를 덮어쓰지 못하도록 runIdRef.current 값을 체크해 걸러내었습니다.