refactor: 매칭 API 엔드포인트 구조 개선

[23tae]

🔍️ 이 PR을 통해 해결하려는 문제가 무엇인가요?

어떤 기능을 구현한건지, 이슈 대응이라면 어떤 이슈인지 PR이 열리게 된 계기와 목적을 Reviewer 들이 쉽게 이해할 수 있도록 적어 주세요
일감 백로그 링크나 다이어그램, 피그마, 캡쳐를 첨부해도 좋아요

기존 API 구조(#219)에서는 매칭된 상대방 정보를 조회하기 위해 세 번의 API 호출이 필요했습니다:

1. /me/participations로 시대팅 신청 내역을 조회
2. 위 응답의 meetingTeamId를 사용해서 /teams/{teamId}/result로 매칭 결과 조회
3. 위 응답의 matchId를 사용해서 /{matchId}/partner로 상대방 정보 조회

기존 API 구조의 문제점은 다음과 같습니다:

• 불필요한 중복 API 호출
• 클라이언트 측의 복잡한 데이터 흐름
• REST 리소스 구조의 일관성 부족
• 시즌 정보를 받지 않아 추후 불필요한 데이터가 조회될 가능성 존재

✨ 이 PR에서 핵심적으로 변경된 사항은 무엇일까요?

문제를 해결하면서 주요하게 변경된 사항들을 적어 주세요

1. API 엔드포인트 통합

   • /{teamType}/info: 매칭 정보 조회 (성공 여부 및 상대방 정보)

2. 파라미터 변경

   • teamId → teamType으로 변경
   • matchId 의존성 제거로 API 호출 단순화
   • season 파라미터를 추가하여 특정 시즌 데이터만 조회

3. 관련 서비스 로직 개선

   • MatchService 내부 로직을 teamType 기반으로 리팩토링
   • 캐시 키 형식을 변경된 파라미터에 맞게 수정
   • 매칭된 파트너 정보 응답을 위한 새로운 DTO(MatchedPartnerInformationResponse) 생성
   • 불필요한 preference 정보 제거 및 관련 변환 로직 개선

4. 캐시 웜업 기능 구현

   • 매칭 결과 오픈 전에 관련 데이터를 미리 캐시하여 대규모 트래픽에 대비
   • 시즌별 매칭 결과 캐시 웜업 API 추가 (/api/admin/cache/warmup)
   • 비동기 처리

5. 에러 처리 개선

   • GlobalExceptionHandler에 MissingServletRequestParameterException 핸들러 추가
   • 필수 파라미터 누락 시 500 에러 대신 INVALID_INPUT_VALUE로 일관된 에러 응답 처리

🔖 핵심 변경 사항 외에 추가적으로 변경된 부분이 있나요?

없으면 "없음" 이라고 기재해 주세요

• 사용하지 않는 레거시 메서드 제거
• Swagger 문서 업데이트
• 캐시 관련 로깅 추가

🙏 Reviewer 분들이 이런 부분을 신경써서 봐 주시면 좋겠어요

개발 과정에서 다른 분들의 의견은 어떠한지 궁금했거나 크로스 체크가 필요하다고 느껴진 코드가 있다면 남겨주세요

🩺 이 PR에서 테스트 혹은 검증이 필요한 부분이 있을까요?

테스트가 필요한 항목이나 테스트 코드가 추가되었다면 함께 적어주세요

📌 PR 진행 시 이러한 점들을 참고해 주세요

• Reviewer 분들은 코드 리뷰 시 좋은 코드의 방향을 제시하되, 코드 수정을 강제하지 말아 주세요.
• Reviewer 분들은 좋은 코드를 발견한 경우, 칭찬과 격려를 아끼지 말아 주세요.
• Review는 특수한 케이스가 아니면 Reviewer로 지정된 시점 기준으로 3일 이내에 진행해 주세요.
• Comment 작성 시 Prefix로 P1, P2, P3 를 적어 주시면 Assignee가 보다 명확하게 Comment에 대해 대응할 수 있어요
  • P1 : 꼭 반영해 주세요 (Request Changes) - 이슈가 발생하거나 취약점이 발견되는 케이스 등
  • P2 : 반영을 적극적으로 고려해 주시면 좋을 것 같아요 (Comment)
  • P3 : 이런 방법도 있을 것 같아요~ 등의 사소한 의견입니다 (Chore)

---

📝 Assignee를 위한 CheckList

• To-Do Item

[seogwoojin]

몇백명이 동시에 접속했을 때를 고려해서 설계 해주시면 좋을 것 같습니다.
DB가 무조건 죽을 것 같다는 준수의 의견이 있었습니다.

[seogwoojin]

Cacheable의 동작 원리와 데이터 처리량, 처리 속도 등에 대해 알고 계신채로 사용하신 걸까요?

[23tae]

@Cacheable이 Spring AOP 기반으로 동작하여 동일 서비스 내부에서 직접 호출할 경우 캐싱이 동작하지 않는다는 점을 놓치고 있었습니다. 이 문제를 해결하기 위해 MatchingService의 캐시 적용 메서드를 외부에서 호출하도록 개선했습니다.

[seogwoojin]

재사용성을 올린 것은 좋지만 DB 커넥션이 많아서 Match Layer는 커넥션을 줄이는데 초점을 둬야할 것 같습니다