쿠다의 공부 블로그

📝 들어가며이전 글에서 응급실 반경 검색을 손봤습니다.공간 인덱스로 사각형 안의 응급실을 먼저 찾고, 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을 사용하고 있었지만, 공간 검색이 주요 기능이라면 다른 DB를 사용하는 편이 나을지 확인해 보고 싶었습니다.비교 대상은 MySQL, PostgreSQL + PostGIS, MongoDB로 정했습니다.병원과 약국 약 10만 건을 검색하는 지금 서비스에서 DB를 바꿀 만큼 차이가 있을까?MySQL 쿼리는 이후 개선한 BETWEEN + Haversine으로 바꿔 다시 측정했습니다. 아래 표는 2026년 11월 10일에 새로 측정한 결과입니다.📝 같은 공간 검색인데 어떻게 다를까?세 DB에 같은 데이터를 넣었지..

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

이전 글에서는 부하 테스트의 합격 기준과 실행 계획을 정리했습니다.이번 글에서는 실제 테스트를 진행하며 겪은 시행착오와 설정 변경, 그리고 측정 결과를 성능과 비용 기준으로 나눠 해석한 과정을 기록합니다.📝 CloudShell 결과를 신뢰할 수 있을까?처음에는 AWS CloudShell에서 k6를 실행했습니다. 별도의 인스턴스 없이 애플리케이션 서버와 부하 발생기를 분리할 수 있어 간편했습니다. 하지만 부하를 높이자 목표 RPS에 도달하지 못하고 Dropped Iteration이 발생했습니다.관찰 결과판단목표 RPS 미달부하 발생기 성능 확인 필요Dropped Iteration 발생대상 서버의 실패로 단정하기 어려움반복 시험의 결과 편차시험 조건 점검 필요 Dropped Iteration은 계획된 it..

📝 배경개발자라면 자신이 만든 서버가 얼마나 버티는지 알아야 하지 않을까? 팀원들과 논의해 정해진 예산 안에서 인프라를 구성했습니다. 그러던 중 이런 질문을 받았습니다.“현재 프로젝트의 서버는 어느 정도의 트래픽까지 버틸 수 있나요?” 서버가 실행된다는 사실만으로는 답하기 어려웠습니다. 처리 가능한 요청량뿐만 아니라 응답시간과 오류율, 병목이 발생하는 지점도 함께 확인해야 했습니다.막연하게 추측하는 대신 측정값으로 답하기 위해 부하 테스트를 계획했습니다.📝 부하 테스트란 무엇일까요?처음에는 부하 테스트를 단순히 많은 요청을 보내 서버가 죽는지 확인하는 작업이라고 생각했습니다.하지만 서버가 살아 있어도 응답에 몇 초씩 걸리거나 요청 일부가 누락된다면 정상적으로 서비스를 제공했다고 보기 어렵습니다.부하 ..