조회와 AI 응답, 두 종류의 대기가 사용자 흐름을 막았습니다.

• 생성 데이터 총 500만 건 환경에서 1:N JOIN과 DISTINCT로 중간 결과 행 수와 정렬 비용이 증가해 목록 조회에 평균 14.2초 소요
• 와일드카드 검색과 첫 페이지 반복 조회가 DB 비용을 지속적으로 발생
• 매 면접 턴의 상세 점수 계산과 반복 LLM 호출로 다음 턴 응답에 평균 8.5초 소요
• 외부 LLM 지연·실패와 트랜잭션 커밋 전 이벤트 실행이 서비스 흐름에 전파

대용량 조회와 AI 면접 흐름의 지연을 직접 개선했습니다.

• 커뮤니티 목록·검색·상세 조회의 쿼리 구조와 캐시 전략 개선
• AI 모의면접의 점수 계산·LLM 호출 흐름과 외부 API 장애 경계 구현
• 데이터 규모와 동시 요청 조건을 정해 성능 개선 결과 검증

인덱스를 더하기 전에 쿼리 구조와 계산 시점을 바꿨습니다.

• 1:N JOIN을 스칼라 서브쿼리로 바꾸고 DISTINCT를 제거한 뒤 실행계획 기반 복합 인덱스 재설계
• 검색·첫 페이지·상세에 Cache-Aside를 적용하고 생성·삭제·수정별 무효화 범위를 분리
• 매 턴 상세 점수 계산을 면접 종료 후 일괄 평가로 이동하고 작업별 출력 토큰 한도 조정
• Gemini와 OpenAI의 기능 범위를 분리
• 텍스트 검수·대화 10초, 이미지 검수 15초 Timeout과 Retry 2회, 실패율 60% Circuit Breaker 기준 적용
• 콘텐츠 검수를 Spring Event와 AFTER_COMMIT으로 분리해 실행 시점 제어

빠른 해결보다 원인 순서가 중요하다고 판단했습니다.

잘못된 JOIN 구조에 인덱스부터 추가하면 쓰기 비용만 늘 수 있어 쿼리 형태를 먼저 바꿨습니다. 캐시는 트래픽이 몰리는 첫 페이지와 비용이 큰 검색, 수정보다 조회가 잦은 상세에 한정했습니다. LLM도 모든 작업을 같은 모델과 같은 시점에 처리하지 않고 응답 속도와 평가 품질의 책임을 분리했습니다.

각 선택이 만든 차이를 단계별 수치로 남겼습니다.

• 게시글 100만 건·댓글 200만 건 등을 포함한 생성 데이터 총 500만 건 환경에서 목록 조회 14.2초 → 2.8초 → 60ms
• Redis Cache-Aside 적용 후 반복 조회 60ms → 15ms
• 면접당 LLM 호출 21회 → 11회, AI 면접 다음 턴 평균 응답 8.5초 → 2.3초

서비스 연속성과 답변 품질은 같은 문제가 아니었습니다.

모델 전환으로 요청 실패를 줄일 수는 있지만, 턴 단위 맥락과 뉘앙스까지 완전히 이어지지는 않습니다. 외부 API 장애 격리와 응답 품질 동일성을 별개 문제로 보고 이 한계를 남겼습니다.