애플리케이션의 각 계층에서 수행되는 입력값 검증의 범위와 책임을 어떻게 나눌 것인지에 대해 설명해주세요. 특히 중복 검증을 피하면서도 안정성을 확보하는 방안과, 이와 관련된 트레이드오프에 대해 설명해주세요.

1. 각 계층별 검증 범위와 책임 분리

1.1 Controller

• 주로 컨트롤러에서는 도메인의 형식 및 필수값 검증을 담당함
• 데이터 타입, 필수 필드 존재 여부 검증
• DTO에서 Bean Validation (ex: @NotNull, @NotBlank, @Size 등)

1.2 Service

• 주로 비즈니스 로직과 연관된 도메인 규칙 검증을 담당함
• 비즈니스 규칙 위반 여부 검증
• (ex: 중복 가입 여부, 주문 가능 여부 등)

1.3 Repository

• 주로 데이터 무결성 검증 및 제약조건 관리를 담당함
• 데이터베이스 제약조건(Unique 제약, FK제약 등)
• 실제 DB 제약조건으로 강제

2. 중복 검증을 피하면서 안정성 확보 방안

2.1 계층별 책임 명확화

• Controller: 요청 데이터의 형식만 검증
  - 형식 오류는 Controller 단계에서 빠르게 실패 처리
  • (ex: @Valid 및 Bean Validation 활용)
• Service: 비즈니스 로직을 기반으로 한 검증 수행
  - 형식이 올바른 데이터에 대해서만 중복 여부나 상태 전이 등의 검증
  • (ex: 이메일 중복 가입 여부 확인)
• Repository: 데이터베이스 무결성을 위한 제약조건 설정
  - DB 자체에서 중복 방지
  • (ex: Unique 인덱스 생성)

2.2 적극적인 데이터베이스 제약조건 활용

• 최종 데이터 무결성은 반드시 데이터베이스 차원에서 강제함
• Repository에서 DB 예외 처리 후, Service로 다시 비즈니스 예외로 변환하여 전달함
  - 중복된 요청이 동시에 들어왔을 때 경쟁 상태를 방지함

3. 중복 검증을 피하기 위한 트레이드오프

3.1 Controller ↔ Service 검증 중복 문제

• 중복 발생 원인: Controller에서 비즈니스 검증까지 수행하면 로직이 중복됨
• 해결 방법:
  - Controller는 형식 검증만 명확히 한정
  • 비즈니스 로직은 Service 계층에서만 처리하여 중복 제거

3.2 Service ↔ Repository 검증 중복 문제

• 중복 발생 원인: Service에서 미리 중복 체크 후 저장을 시도했지만, DB 레벨에서 제약조건을 다시 체크하여 중복 발생
• 해결 방법:
  - 서비스는 중복 여부의 선제적 확인, Repository는 최종 방어
  • 예외 발생 시점은 Repository로 통일, 서비스는 DB 예외를 처리하여 일관된 예외로 반환.

4. 트레이드오프