여러 브라우저 탭이 서로 상호작용하는 Cross-tab Animal Club 구현기
·
Project
브라우저에서 같은 HTML 파일을 여러 탭이나 창으로 열었을 때, 각 창이 서로의 존재와 위치를 알고 상호작용한다면 꽤 재미있는 장난감을 만들 수 있다. Cross-tab Animal Club은 이 아이디어를 바탕으로 만든 작은 브라우저 실험이다. 각 탭에는 동물 캐릭터가 하나씩 배정되고, 여러 창을 열면 서로의 위치를 기준으로 선이 연결된다. 여기에 술래잡기, 간식 폭죽, 우다다 모드, 특정 친구에게 별 던지기 같은 상호작용을 추가했다. 이 프로젝트에서 중점적으로 봐야 할 기술적 포인트는 다음과 같다.서버 없이 탭 간 상태를 동기화하는 BroadcastChannel브라우저 창 위치를 기준으로 한 전역 좌표계 설계canvas 기반 애니메이션 루프탭 생존 여부 관리특정 탭 A가 특정 탭 B에게 별을 던지..
[배송 권역 시스템 4편] 새벽 배송 알림 설계 — 기사 위치를 직접 노출하지 않는 이유
·
Project/배송 권역 시스템
음식 배달 앱처럼 기사 위치를 실시간으로 보여주면 되지 않을까? 새벽 배송에서는 그렇지 않다. 사용자 압박으로 인한 CS 폭주, 새벽 시간대의 안전 이슈, 기사 개인 위치 정보의 민감성. 이 세 가지가 위치 직접 노출을 어렵게 한다. 그래서 이 프로젝트에서는 위치 좌표 대신 "원 영역"으로 추정 영역만 표시하고, AND 조건 트리거로 false positive 를 차단했다.사용자는 "곧 도착" 신호만 받고, 기사는 본인 좌표 노출 없이 동선 자유도를 유지한다.요약음식 배달 앱은 사용자가 "조금만 더 빨리" 욕구가 강해도 동선 변경 여지가 적다 (식어버리는 음식 + 짧은 거리). 새벽 배송은 다르다.새벽 배송에서 기사 위치를 직접 노출하면 (1) 사용자 압박 CS, (2) 새벽 시간대 안전, (3) 기사 ..
[배송 권역 시스템 3편] 강남 1권역에서는 괜찮았던 V1, 6개 권역에선 왜 깨졌는가
·
Project/배송 권역 시스템
"balance 0.51 — 양호해 보였던 결과"가 함정이었다.강남 1권역에서 괜찮아 보이던 V1을 6개 권역에 동일하게 적용하니, 권역 모양에 따라 결과 품질이 최대 4배까지 떨어졌다. 이 글은 그걸 어떻게 측정으로 드러냈고, 그 측정이 V2 작업(일반화와 3단계 검증)의 출발점이 됐는지에 대한 이야기다. 요약V1 은 강남 1 권역 측정 결과 (balance 0.51, span 1.89km) 만으로 채택했다.6 권역 × 5 회 = 30 시나리오로 다시 측정하니 권역 모양에 따라 결과가 갈렸다.길쭉 권역(강남·수원)은 공간 outlier, 작은 조밀 권역(부천)은 건수 불균형, 중간 둥근 권역(관악)은 우연히 잘 동작."한 권역에서 잘 동작" ≠ "알고리즘이 일반화됨". 이 차이를 인지한 게 V2 작업의..
[배송 권역 시스템 2편] 수도권 새벽 배송 자동 배차 시스템 – 구현을 하면서 깨달은 것들
·
Project/배송 권역 시스템
1편에서는 “수도권 새벽 배송 3만 건을 어떻게 배정·경로화할 것인가”를 문제 정의와 전체 구조 중심으로 정리했다. 이번 2편에서는 구현을 진행하면서 실제로 무엇을 했고, 무엇을 배웠고, 앞으로 어떻게 개선할 생각인지를 가볍게 정리해 보려고 한다.세부 구현(점수 함수 상수, 실제 코드, 쿼리 등)은 일부러 추상화해서 적었다.아직 개선점이 많고 부족하기 때문에, 설계·아이디어 수준까지만 먼저 공유한다. 1. 이번에 실제로 무엇을 했나큰 틀에서 이번 프로젝트에서 한 일은 세 가지로 정리할 수 있다.1-1. CVRP를 현실적으로 풀기 위해 2단계로 분리했다“기사 수백 명 + 배송 3만 건 + 시간/케파 제약”은 학술적으로 CVRP(Capacitated VRP)에 해당한다.이걸 한 번에 풀려고 하면 다음 문제가..
[배송 권역 시스템 1편] 배송 권역 시각화 시스템을 설계하며 고민한 것들
·
Project/배송 권역 시스템
이 글에서 다루는 데이터와 영상에 등장하는 모든 주소·주문·고객 정보는 실제 서비스와 무관한 더미 데이터입니다. 문 앞까지 가져다주는 새벽배송·문전 서비스에 관심이 많다. 마켓컬리, 런드리고, 커버링 같은 서비스를 사용하다 보면 “이 많은 주문이 밤사이에 어떻게 공간 상에서 배치되고 움직이는지 ”가 항상 궁금했다. 그래서 수도권을 기준으로, 실제 서비스에서 다루게 될 만한 스케일의 배송 데이터를 지도 위에서 시각화하고, 운영자가 바로 쓸 수 있는 형태로 정리하는 시스템을 개인 프로젝트로 구현해 보았다.이 글은 수도권 66개 권역, 1,187개 행정동, 일 3만 건 규모의 배송 데이터를 지도 위에서 실시간으로 다루는 시스템을 설계하고 구현하면서 내렸던 판단들을 정리한 기록이다. 무엇을 만들었는가보다 왜 ..