쿠다의 공부 블로그

📝 들어가며이전 글에서 응급실 반경 검색을 손봤습니다.공간 인덱스로 사각형 안의 응급실을 먼저 찾고, ST_Distance_Sphere로 실제 거리를 계산하는 방식이었습니다. 원형 버퍼로 찾을 때 30km에서 빠졌던 응급실 3곳도 이걸로 찾았습니다.이번에는 병원과 약국 데이터를 넣을 차례였습니다. 같은 쿼리를 그대로 쓰면 되겠다 싶었는데, 위치를 저장한 POINT를 보다가 문득 이런 생각이 들었습니다.어차피 우리가 찾는 건 점인데, 사각형 안에 있는지는 위도랑 경도 숫자만 비교해도 되지 않나?병원과 약국은 100,676곳이고 검색 반경은 최대 10km입니다.솔직히 공간 인덱스가 더 빠를 거라고 생각했습니다. R-tree까지 쓰는데 숫자 비교가 이길까 싶었죠. 그래도 궁금해서 BETWEEN 쿼리를 만들어..

목차들어가며왜 이 기능을 넣었을까?대중교통 시간표를 탐색할 수 있는 노선망으로 바꿨습니다목적지에서 거꾸로 탐색합니다탐색 자료구조를 바꿔 Young GC 멈춤 시간 합을 94% 줄였습니다동네별 월세 시세를 붙이고 중복 정류장을 정리했습니다마치며📝 들어가며자취선배는 처음 자취하는 사람이 집을 고르고 비교하도록 돕는 서비스입니다. 얼마 전 회사나 학교를 입력하면 대중교통으로 출퇴근할 수 있는 동네를 보여 주는 '생활권 탐색' 기능을 만들었습니다. 매물 몇십 건을 다루던 서버가, 하루아침에 수도권 정류장 약 5만 8천 개짜리 노선망을 떠안게 된 셈입니다.이 글에서는 그 과정에서 고민하고 부딪힌 것들을 순서대로 이야기하려고 합니다.프로토타입 인터뷰로 기능의 가치를 확인한 과정대중교통 시간표(GTFS)를 수도권 ..

이전 글에서는 병원·약국 CSV 갱신 중 발생한 Java heap space 오류와 active 배치 방식으로 바꾼 과정을 적었습니다. 전체 데이터를 Java 메모리에 올리지 않도록 바꾼 뒤에는 다른 질문이 남았습니다.기존 병원·약국 데이터를 새 CSV로 최신화할 때, 변경 판단과 쓰기를 어디에서 처리하는 편이 적합할까?기준 데이터는 100,676건, 새 2026.6 CSV는 105,448건입니다. AWS에서 JPA, 이전 active 배치, Java 스테이징, DB 스크립트를 비교했습니다. 핵심은 단순한 속도 순위가 아니라, 24시간 조회를 제공하는 애플리케이션의 메모리 부담을 제한하면서 실제 변경분을 정확히 반영하는 방법을 고르는 것이었습니다.📝 갱신 방식은 어떻게 달랐나?JPA: 애플리케이션에서 ..

PlusKM의 주변 의료기관 검색에 맞는 MySQL 공간 쿼리를 비교했습니다. DB 선택 과정은 이전 글에 있습니다.지정 반경 안의 의료기관을 가까운 순서로 보여주려면 어떤 쿼리가 적합할까?필요한 것은 인덱스로 후보를 줄이면서도, 실제 반경 안에 있는 병원을 가까운 순서대로 돌려주는 쿼리였습니다.📝 무엇을 기준으로 평가할까?대상은 SRID 4326 POINT로 저장한 응급실 좌표입니다. 이 글의 반경은 ST_Distance_Sphere의 구면 거리로 정의했습니다. MySQL 문서먼저 병원 ID와 정렬 순서를 확인했습니다. 그다음 100 VU에서 초당 처리 건수를 비교했습니다. 이때 p95는 DB 실행 시간만이 아니라 연결 풀에서 기다린 시간까지 포함합니다.📝 공간 함수 중 무엇을 후보로 남길까?MyS..

저는 개인 프로젝트로 응급실 검색 애플리케이션을 제작했습니다.주변 의료기관을 조회하는 기능에서는 사용자의 위치를 기준으로 가까운 장소를 검색해야 합니다.기존 프로젝트에서는 MySQL을 사용하고 있었지만, 공간 검색이 주요 기능이라면 MySQL을 그대로 사용하는 것이 적절한지 확인해보고 싶었습니다.비교 대상은 세 가지로 정했습니다.MySQLPostgreSQL + PostGISMongoDB단순히 가장 빠른 DB를 찾기보다는 다음 질문에 답하는 것을 목표로 했습니다.약 10만 건의 공간 데이터를 검색하는 현재 서비스에서 DB를 변경할 만큼 의미 있는 차이가 있을까?📝 같은 공간 검색인데 어떻게 다를까?세 DB 모두 공간 인덱스를 제공하지만 검색 방식에는 차이가 있습니다.PostGISPostGIS에서는 GiS..

자취선배의 백엔드 기술 스택을 정하면서 JPA와 Spring Security를 사용하지 않기로 했습니다.둘 다 Spring 기반 프로젝트에서 자주 사용되고, 팀원들도 사용 경험이 있는 기술입니다.그럼에도 익숙한 기술을 먼저 선택하기보다 다음 기준을 세웠습니다.현재 발생한 문제를 먼저 확인하고, 그 문제를 해결하기 위해 기술을 도입한다.이번 글에서는 이 기준으로 JPA와 Spring Security를 사용하지 않은 이유와, 어떤 상황에서 다시 도입을 고려할지 정리합니다.📝 익숙한 기술이라고 반드시 필요할까?프로젝트를 시작하면서 사용할 기술을 정리했습니다.구분선택LanguageJava 21FrameworkSpring Boot 3.5PersistenceSpring JDBC / JdbcTemplateDatab..