문제 해결 포트폴리오 / 대여 서비스 / 조회 성능
측정 완료BorrowMe
상품 목록 N+1 개선 검증
상품 목록 조회의 원본 N+1 개선 기록과 현재 clean repeat3 snapshot/query-count guard를 분리해 검증했습니다.
p95
358.1088ms
HTTP failure
0
Guard
query-count
해결 키워드Query-count Guardk6Testcontainers
- 프로젝트
- BorrowMe
- 참여
- 11인 팀 프로젝트
- 기술
- Java · Spring Boot · JPA · MySQL · k6
문제 구간 아키텍처
문제
- 상품 목록 조회에서 연관 데이터 접근이 반복되며 p95 응답 시간이 1초 수준까지 늘어났습니다.
- 목록 API는 서비스 첫 화면과 가까워 조회 지연이 사용자 경험에 직접 영향을 줬습니다.
- 팀 프로젝트에서는 성능 개선과 예약 정합성 의사결정을 짧은 시간 안에 공유해야 했습니다.
해결
- 상품 목록 조회의 N+1 접근을 제거해 필요한 조회를 3회 쿼리로 줄였습니다.
- p95 응답 시간과 쿼리 수는 원본 README 기록으로 분리하고, 현재 repo에서는 query-count guard로 회귀를 막습니다.
- 동시 예약 재고 초과 방지는 별도 정합성 검증 항목으로 분리했습니다.
결과
- 원본 README 기록 기준 상품 목록 p95 응답 시간은 1,010ms에서 23ms로 개선됐습니다.
- 2026-05-23 clean repeat3 local k6 snapshot에서는 p95 358.1088ms, HTTP failure rate 0을 기록했습니다.
- 원본 README 기록과 현재 query-count guard 기준 쿼리 수는 201회에서 3회로 정리됩니다.
- 현재 repo에서는 query-count guard와 예약 정합성 테스트로 조회 경로와 재고 정합성 회귀를 검증했습니다.
검증 근거
상품 목록 현재 재측정 snapshot
측정 완료p95 358.1088ms · HTTP failure 0 · checks 10,683/10,683 (local)
상품 목록 쿼리 수 원본 기록 + 현재 guard
시나리오 검증원본 README 기록 + 현재 query-count guard: 201 queries -> 3 queries
예약 정합성
시나리오 검증동시 예약 재고 초과 방지
상품 목록 p95 원본 기록
참고 기록raw artifact 없음 · 현재 측정 완료 claim 아님
구현 포인트
- 이 사례는 백엔드 기본기인 조회 병목 발견과 N+1 제거를 대표 사례로 분리합니다.
- 팀 프로젝트 맥락은 협업과 의사결정 설명에 쓰고, 수치는 원본 기록과 현재 query-count guard의 경계를 함께 표시합니다.
- follow/ranking/Flyway guard 세부는 GitHub README/docs 근거로 분리했습니다.
세부 테스트, guard, raw artifact는 GitHub README와 docs에 정리했습니다.
GitHub 근거 보기