PROJECT DETAIL / 업무 프로젝트
배송 시스템에 연계되는 주소 정제·좌표 조회 API
표기 방식이 일정하지 않은 배송지 주소를 정제하고 좌표를 조회하는 API를 개발했습니다. 검색 쿼리와 인덱스를 개선하고 커넥션 풀 고갈 원인을 분석해 응답 지연과 타임아웃을 줄였습니다.
기존 배송 시스템에서 사용하는 주소 조회 API의 백엔드 개발과 운영을 담당했습니다. 주소 정제·파싱, 동적 검색 조건 구성, 쿼리·인덱스 개선과 커넥션 풀 문제 분석을 수행했습니다.
01 / ARCHITECTURE
02 / IMPLEMENTATION
기능별 처리 흐름과 문제 해결 과정, 설계 이유와 구현 결과를 소개합니다.
FEATURE 01 구현 완료
다양한 형식의 배송지 주소를 검색에 사용할 수 있는 형태로 정리합니다.
주소마다 공백과 기호, 번지 표기 등이 달라 입력값을 그대로 검색 조건에 사용하기 어려웠습니다.
정규식 기반 정제와 주소 요소 파싱을 구현하고, 도로명·지번 주소의 유형에 맞춰 검색 조건을 구성했습니다.
입력에서 검색 가능한 주소 요소를 추출하고 QueryDSL로 조건을 조합했습니다. 입력 패턴이 늘어날수록 정제 규칙과 검색 조건의 예외 사례를 함께 관리해야 합니다.
불규칙한 주소 표기를 정리하고 유형별 조회 조건을 적용해 배송지 좌표 조회의 정확도를 개선했습니다.
FEATURE 02 구현 완료
주소 검색 조건에 맞춰 쿼리와 인덱스를 개선했습니다.
주소 조회 요청이 집중될 때 쿼리 지연이 전체 API 응답 시간에 영향을 주었습니다.
검색 패턴과 실행 계획을 분석하고 쿼리 구조와 인덱스를 조정했습니다.
자주 사용하는 조건과 데이터 접근 경로를 기준으로 인덱스를 구성했습니다. 조회 성능을 높이는 대신 쓰기와 인덱스 유지 비용이 늘어나므로 인덱스 수보다 사용 패턴을 우선했습니다.
쿼리·인덱스 개선으로 평균 응답 시간을 약 1,200ms에서 300ms 수준으로 단축했습니다. 최근 재측정에서는 평균 200~300ms의 응답 시간을 확인했습니다.
FEATURE 03 구현 완료
커넥션 대기와 타임아웃을 분석하고 부하 조건에서 설정을 조정했습니다.
요청량이 증가하면서 DB 커넥션 풀이 고갈되고 타임아웃이 발생했습니다.
Scouter와 로그로 커넥션 사용 흐름을 분석하고 JMeter로 문제를 재현했습니다. 이후 풀 크기와 타임아웃 설정을 조정했습니다.
커넥션 수를 늘리면 대기는 줄일 수 있지만 DB의 동시 처리 부담도 커집니다. 쿼리 수행 시간과 커넥션 점유 상태를 함께 살펴 설정을 조정했습니다.
부하 테스트에서 TPS 200 수준의 안정적인 처리를 확인하고 커넥션 대기로 발생하던 타임아웃을 개선했습니다.
03 / RESULTS & TESTING
| 항목 | 결과 |
|---|---|
| 사용 규모 | 약 9,000명의 배송기사가 사용하는 시스템에 연계 |
| 응답 시간 | 쿼리·인덱스 개선 전후 평균 약 1,200ms → 300ms |
| 부하 테스트 | TPS 200 수준의 안정적 처리 및 타임아웃 개선 |
04 / REFLECTION
입력값을 정리하는 로직과 데이터베이스 조회 성능을 함께 개선해야 주소 조회 품질을 높일 수 있었습니다. 운영 장애를 분석하면서 응답 시간뿐 아니라 쿼리 수행 시간, 커넥션 점유와 요청량의 관계를 살피는 습관을 갖게 됐습니다.
다시 설계한다면 주소 정제의 예외 사례를 회귀 테스트로 축적하고, 검색 조건별 응답 시간과 커넥션 대기를 함께 관찰할 수 있도록 지표를 정리하겠습니다.