[REFACTOR] 브랜드 조회 api 수정

[yerimi00]

리팩토링 대상

브랜드(feat/33-brand) 브랜치에서 개발한 기능 코드와, 기존 공통/다른 도메인 코드가 서로 의존/참조가 꼬여 충돌이 발생하는 부분을 분리 및 정리하려고합니다.

현재 상태

• 브랜드 브랜치에서 작성한 코드가 다른 도메인(혹은 공통 모듈)과 서로 참조가 뒤엉켜 머지/빌드/테스트 과정에서 충돌 가능성이 큼
• 기능 수정 시 영향 범위가 커져 회귀(Regression) 위험이 높고, 문제 원인 파악이 어려움
• 코드 책임 경계가 불명확해져 유지보수 비용 증가

리팩토링 목표

• 코드 가독성 향상
• 성능 개선
• 중복 코드 제거
• 디자인 패턴 적용
• 테스트 용이성 향상
• 기타 : 브랜드 기능의 의존성/책임 경계 명확화, 안전한 병합을 위한 임시 브랜치 기반 정리

변경 계획

1. 임시 브랜치 생성

• 브랜치명: feat/[번호]-brand-tempo
• 목적: 브랜드 관련 변경사항을 다른 변경사항과 분리해 충돌 최소화 및 정리 작업의 안전성 확보

2. 충돌 지점 식별

• 브랜드 코드가 참조하는 공통/타 도메인 클래스, 유틸, DTO, 설정(Security/Swagger 등) 의존 관계를 목록화

3. 중복 제거 & 네이밍 통일

• 중복 DTO/응답 포맷/에러 코드 정리

영향 받는 파일/모듈

예: src/main/java/com/example/RealMatch/brand/...
예: src/main/java/com/example/RealMatch/common/...
예: src/main/java/com/example/RealMatch/config/...

예상 결과

브랜드 기능 코드가 다른 도메인/공통 코드와 명확히 분리되어 충돌 감소

테스트 계획

• ./gradlew clean build
• ./gradlew checkstyleMain checkstyleTest
• ./gradlew test
• Swagger/로컬 실행으로 브랜드 API 주요 플로우 검증
• 브랜드 목록/상세/조회 관련 API 200 응답 확인
• 예외 케이스(없는 ID 등) 응답 포맷 확인

추가 정보

• 이번 리팩토링은 **기능 추가보다 “코드 충돌/의존성 꼬임 해소”**가 우선 목표입니다.
• 정리 작업은 임시 브랜치 feat/[번호]-brand-tempo에서 진행한 뒤, 안정화 후 브랜드 브랜치 또는 메인 개발 브랜치로 단계적 반영합니다.