전체 글64 매칭 지도 구현기 (2) 지도 API 호출 최소화 들어가며매칭 지도 구현기(1)에서는 사용자 증가에 대비한 마커 클러스터링을 다뤘습니다. 이번 글은 지도 API 조회 구조를 손보면서 따라온 질문들에 대한 이야기입니다.원래는 전국 단위 유저 목록을 한 번에 받아오던 구조였는데, 사용자가 늘어났을 때를 대비해 뷰포트 기반 조회로 바꾸게 되었습니다. 이 전환을 계기로 "카메라가 움직일 때마다 API를 쳐야 하나?", "필터 조작마다도 API를 쳐야 하나?" 같은 질문이 생겼고, 각각에 대한 답을 찾는 과정을 정리해보려 합니다.1. 뷰포트 기반 조회로 전환처음에 매칭 회원을 지도에 표시하는 방식은 단순했습니다. 앱 진입 시 전국 단위 유저 목록을 한 번 받아와 메모리에 캐싱해두고, 이후 카메라 이동에 대해서는 로컬 데이터만으로 대응했습니다. 사용자 수가 많지 .. 2026. 5. 3. 매칭 지도 구현기 (1) 마커 클러스터링 들어가며매칭 기능을 지도 기반으로 구현하면서 지도 성능과 관련해 크게 두 가지 작업을 진행했습니다. 두개의 글에 걸쳐 그 이야기를 정리해보려 합니다.이번 글은 카카오맵에 외부 라이브러리를 사용해서 마커 클러스터링을 구현한 과정을 정리한 것입니다. 왜 필요했고, 어떤 구조로 구현했는지 순서대로 짚어보겠습니다.1. 마커가 많아지면 생길 문제이 작업을 시작할 당시 서비스의 실사용자 수는 많지 않았습니다. 그래서 지도에 마커를 모두 찍어도 당장 체감되는 성능 문제는 없었는데요.다만 매칭 기능의 특성상 사용자가 늘어나면 같은 영역에 마커가 빠르게 밀집될 수 있고, 그 시점에 가서 대응하면 이미 사용자 경험이 망가진 뒤가 되기 쉽습니다. 그래서 아래 리스크를 미리 정리해두고, 문제가 생기기 전에 구조를 잡아두기로 .. 2026. 4. 22. Polling에서 WebSocket으로의 전환기 들어가며운다방 서비스에서 채팅 기능은 매칭된 사용자 간의 소통을 위한 핵심적인 기능입니다. 처음에는 빠른 개발과 안정성을 위해 Polling 방식으로 구현했지만, 실시간 통신에서의 한계를 느끼게 되었고, 결국 WebSocket으로의 전환을 결정했습니다.이 글에서는 전환 과정에서의 설계 결정과 기술적 문제 해결 경험을 공유하고자 합니다.1. Polling에서 WebSocket으로초기에 채팅 기능 설계에 두 가지 선택지를 검토했습니다.방식장점단점Polling- 구현이 단순- 기존 REST API 인프라 활용 가능- 불필요한 API 호출- 실시간성 저하WebSocket- 진정한 실시간 통신- 효율적인 리소스 사용- 연결 관리 복잡함- 백그라운드 처리 필요- 서버 인프라 구축 필요- 서버 리소스 점유당시 우리 .. 2026. 3. 24. 에러 처리를 하나로 통합하기 앱의 기능이 늘어나고 Repository 파일이 많아지면서 구조적인 아쉬움이 눈에 띄기 시작했습니다. 이 글은 반복되는 네트워크 에러 처리를 효율화하기 위해 여러 접근법을 검토한 과정과, 최종적으로 apiCallBuilder라는 함수형 파이프라인을 선택하게 된 이유를 공유합니다.1. 파편화된 에러 처리초기에는 API를 호출하는 Repository 메소드마다 일일이 try-catch를 작성하고 응답 코드를 확인하는 방식을 사용했습니다. 하지만 코드가 많아지며 다음과 같은 문제들이 드러났습니다.보일러플레이트 코드의 증가: 모든 API 호출마다 네트워크 연결 상태 확인, 4xx/5xx 에러 파싱, 예외 처리 로직이 중복 작성되었습니다.휴먼 에러 발생 위험: 스레드 전환을 위한 Dispatcher 지정 누락이나.. 2026. 3. 12. 이전 1 2 3 4 ··· 16 다음
