@AutoApiResponse 및 ApiResponseAdvice 제거 제안

[Kimgyuilli]

현재 프로젝트에서는 응답을 통일된 형식으로 반환하기 위해 두 가지 방식이 혼재되어 있습니다:

1. ApiResponseAdvice (자동 래핑 방식)
   - @AutoApiResponse 어노테이션이 붙은 컨트롤러의 응답을 자동으로 CommonApiResponse로 래핑
   - ResponseBodyAdvice 인터페이스를 구현하여 응답 전처리
2. Controller 수동 래핑 (현재 실제 사용 중)
   - 모든 Controller 메서드에서 CommonApiResponse.success() 직접 호출
   - 명시적으로 응답 객체 생성

@AutoApiResponse // ← 어노테이션은 있지만
@GetMapping("/{id}")
public CommonApiResponse getUser(@PathVariable Long id) {
return CommonApiResponse.success(SuccessCode.SUCCESS, response); // ← 수동 래핑
}

결과: ApiResponseAdvice의 래핑 로직이 실행되지만, 이미 CommonApiResponse로 래핑되어 있어 아무 작업도 하지 않고 통과만 합니다.

---

🚨 문제점

1. 개발 과정에서 혼란 유발

최근 PR 작업 중 @AutoApiResponse를 빠트리는 실수가 반복적으로 발생했습니다.

• 본인과 서영님 모두 PR에서 해당 어노테이션을 누락
• 어노테이션이 있어야 하는지, 없어야 하는지 명확하지 않음
• 실제로는 없어도 동작하지만, 있어야 할 것 같은 느낌
• → 일관성 없는 코드 작성을 하게 됨

2. 복잡도만 증가, 실질적 이점 없음

복잡도 증가:

• ApiResponseAdvice 클래스 추가
• @AutoApiResponse 어노테이션 관리
• Controller에 어노테이션 + 수동 래핑 중복 작성
• ResponseBodyAdvice 인터페이스 이해 필요

기대했던 이점:

• Controller 코드 간소화 → 실제로는 수동 래핑 사용 중
• 일관된 응답 형식 → 수동 래핑으로도 충분히 달성
• 가독성 향상 → 오히려 흐름이 암묵적이 되어 가독성 저하

실제 상황:
// 기대: DTO만 반환
public UserResponseDto getUser(@PathVariable Long id) {
return userService.getUser(id);
}

// 실제: 수동 래핑 사용
public CommonApiResponse getUser(@PathVariable Long id) {
return CommonApiResponse.success(SuccessCode.SUCCESS, response);
}

3. 커스터마이징 오히려 불편

현재 방식의 제약:

• 모든 성공 응답이 동일한 구조 (SuccessCode.SUCCESS)
• 특정 엔드포인트에서 다른 응답 형식이 필요할 경우 Advice 우회 필요
• beforeBodyWrite() 메서드에서 조건 분기 추가 필요

수동 래핑 시의 장점:

• 각 엔드포인트별로 유연하게 응답 커스터마이징 가능
• 명시적이고 직관적
• 필요시 CommonApiResponse 상속/확장 용이

---

💡 제안

@AutoApiResponse와 ApiResponseAdvice를 완전히 제거하고, Controller에서 명시적으로 CommonApiResponse를 반환하는 방식으로 통일

변경 사항

삭제할 파일:

• ApiResponseAdvice.java
• AutoApiResponse.java

Controller 수정:

• @AutoApiResponse
  @RestController
  public class UserController {

• import com.sopt.cherrish.global.annotation.AutoApiResponse;                                                                                                                                      
  
  @GetMapping("/{id}")
  public CommonApiResponse<UserResponseDto> getUser(@PathVariable Long id) {
      return CommonApiResponse.success(SuccessCode.SUCCESS, response);
  }
  

  }

유지되는 부분

• ✅ CommonApiResponse 클래스 (응답 래퍼)
• ✅ SuccessCode enum (성공 코드)
• ✅ GlobalExceptionHandler (에러 처리는 독립적)
• ✅ @ApiExceptions (Swagger 문서화는 독립적)

---

✨ 기대 효과

1. 명확성 향상

• 응답 처리 흐름이 명시적으로 드러남
• "어노테이션을 빠트렸나?" 고민 불필요
• 신규 개발자도 쉽게 이해 가능

2. 복잡도 감소

• 불필요한 추상화 레이어 제거
• ResponseBodyAdvice 동작 원리 이해 불필요
• Dead Code 제거

3. 유연성 증가

• 엔드포인트별로 자유롭게 응답 커스터마이징
• 필요시 쉽게 확장 가능
• 디버깅 용이

4. 일관성 확보

• 팀원 모두가 동일한 방식으로 코드 작성
• PR 리뷰 시 체크 포인트 감소

---

📊 Before / After 비교

항목	Before (Advice 방식)	After (수동 래핑)
코드 명확성	낮음 (암묵적 처리)	높음 (명시적 처리)
학습 곡선	높음 (Spring Advice 이해 필요)	낮음 (직관적)
실수 가능성	높음 (어노테이션 누락)	낮음 (컴파일 타임 체크)
커스터마이징	어려움 (Advice 수정)	쉬움 (메서드별 수정)
디버깅	어려움 (흐름 추적 복잡)	쉬움 (직접적 흐름)

---

🤔 의견 부탁드립니다

이 제안에 대해 팀원 분들의 의견을 듣고 싶습니다:

• 현재 방식(Advice)을 유지해야 할 이유가 있을까요?
• 제거 시 예상되는 문제점이 있을까요?
• 더 나은 대안이 있을까요?

---

참고: 실제 동작 분석

현재 ApiResponseAdvice의 실제 동작:
public Object beforeBodyWrite(Object body, ...) {
if (body instanceof CommonApiResponse) {
return body; // ← 항상 여기서 그냥 통과!
}
// 아래 코드는 실행되지 않음
return CommonApiResponse.success(SuccessCode.SUCCESS, body);
}

결론: 복잡도만 추가하고 실제로는 아무 역할도 하지 않는 상태입니다.

[ssyoung02]

만약 DTO만 리턴하고 Advice가 래핑하는 방식으로 바꾸려면 모든 컨트롤러 코드를 고쳐야 하는데 현재 구조에서는 기술적으로 큰 이점이 없다고 생각합니다. 그리고 이미 모든 컨트롤러에서 CommonApiResponse.success 구조를 사용 중이기 때문에 리팩토링 리스크도 낮다고 생각해 제거하는게 맞는 것 같습니다.