□ 공통 응답 리팩토링

  ▷ 수행 내역

1. 썸네일 응답 종류
2. 공통 응답 클래스 생성
3. Header, Response Body 설정 클래스

  ▷ 수행 결과

1. 응답 일관성
2. 재사용성 및 중복 코드 제거
3. 에러 및 성공 응답의 표준화

□ 커스텀 예외 리팩토링

  ▷ 수행 내역

1. 도메인별 인터페이스 정의 (ErrorCode 상속) → 타입 안전성, 가독성, 확장성
2. RuntimException 을 상속한 CustomException
3. 예외 핸들링

         •에러 코드 인터페이스 → 에러의 처리 로직을 중앙에서 관리

         • 에러 코드에 정의된 HttpStatusCode, message 를 응답 값으로 설정한다.

  ▷ 수행 결과

1. 에러의 의미 명확화
2. 일관된 에러 처리 로직 구현
3. 예외 메시지와 상태 코드를 일관되게 관리
4. 디버깅과 로그 분석에 용의

□ 서비스 레이어 분리 리팩토링

  ▷ 수행 내역

1. 인터페이스 : 서비스가 제공하는 기능 정의
2. 비즈니스 로직을 Controller 에서 서비스 레이어로 이동 (책임 분리)

  ▷ 수행 결과

1. 단일 책임 원칙 준수 : 코드의 모듈화
2. 로직 복잡성 완화
3. 유지보수성과 코드 재사용성 향상

□ DTO 사용 리팩토링

  ▷ 수행 내역

1. 문제 상황

         • 여러 API 에서 하나의 DTO 를 통합해서 사용한다.

            : DTO 필드가 어느 API에서 사용되는지 명확히 알기 어렵다.

         • 중간에 Map 에 값을 넣어서 DB 접근시 재사용 한다.

            : 예상치 못한 데이터의 변경이 있을 수 있고, 데이터의 출처나 상태를 정확히 파악하기 힘들다

→ 요청별 DTO 를 생성한다.

  ▷ 수행 결과

1. 다른 서비스나 API에서도 재사용
2. 명확한 요청 데이터 알 수 있음
3. 가독성
4. 타입 안전성 확보

□ 로그 설정 리팩토링

  ▷ 수행 내역

      : 기존의 System.out.println 으로 사용하거나 단순 값을 출력하는 로그를 아래와 같이 구분해 처리한다.

1. 기본 로그

          중간 처리 → logger.info("[Processing] ...: {}", request.toString());

          성공 처리 → logger.info("[Success] ... : {}", result);

          실패 처리 → logger.info("[Fail] ... : {}", result); / logger.info("[DB Error] ... : {}", errMsg);

       2. 추적용 로그

           logger.info("[1] Processing ... = {}", request.toString());

           ...

           logger.info("[6] Processing ... = {})", result);

           logger.info("[Success] Processing ... : {}", result);

  ▷ 수행 결과

1. 중간/성공/실패 처리 등의 단계별 로그를 나누어 각 처리 단계를 쉽게 식별 가능
2. 번호를 통해 처리 과정의 각 단계를 상세히 추적 가능

                                                                                                                                                         ⭐발표자 : 이현진님