[TIL, 일일 회고] 2024.09.04 - Spring 심화 AI 비즈니스 검증 프로젝트 트러블 슈팅

 

서론

Spring 심화과정의 첫 번째 프로젝트가 끝났습니다.

 

짧은 기간이었지만, 계획했던 기능을 1가지 제외하고 모두 구현을 해서 아쉽기도하지만 만족스러운 프로젝트였습니다.

 

본글에서는 프로젝트에서 제가 맡은 도메인의 트러블 슈팅에 대해서 정리하고자 합니다.

 

 

트러블 슈팅 1

문제 발생

 

@EntityListeners(AuditingEntityListener.class)를 사용하여 Timestamped 클래스를 통해 생성 및 수정 시간 정보를 자동으로 관리하고, @MappedSuperclass를 통해 공통 매핑 정보를 자식 클래스에서 상속받아 사용하고 있었습니다.

 

 그러나 updateBy와 deleteBy 필드가 업데이트되지 않는 문제가 발생했습니다.

 

문제 원인

문제를 조사한 결과, @Column(updatable = false) 설정이 원인임을 확인했습니다.

 

초기 계획에서는 updateBy와 deleteBy 필드에 대해 @Column(updatable = false)를 설정했으나, 계획 변경과 팀원의 코드 수정 과정에서 rebase 시 실수로 이 설정이 제거되지 않았습니다. 이로 인해 필드 값이 자동으로 업데이트되지 않았습니다.

 

해결 과정

 

1. 문제 식별
   • @Column(updatable = false)설정이 원인이라는 것을 확인했습니다.
2. 코드 검토 및 수정
   • 해당 설정을 제거하고, 필드 값이 자동으로 갱신되도록 코드 수정을 진행했습니다.
3. 재테스트
   • 문제 해결 후, 필드 값이 정상적으로 업데이트되는지 확인하기 위해 추가 테스트를 실시했습니다.

교훈

프로젝트 초기에 이슈 생성, 커밋 컨벤션, 및 코드 리뷰 절차를 명확히 정립했기 때문에 문제를 빠르게 식별하고 해결할 수 있었습니다.

 

이러한 사전 준비와 명확한 절차 설정이 문제 발생 시 신속하고 효과적으로 대응할 수 있는 기반이 되었음을 깨달았습니다.

 

 

트러블 슈팅 2

문제 발생

 

@EntityListeners(AuditingEntityListener.class)를 사용하여 Timestamped 클래스를 통해 생성 및 수정 시간 정보를 자동으로 관리하고, @MappedSuperclass를 통해 공통 매핑 정보를 자식 클래스에서 상속받아 사용하고 있었습니다.

 

그러나 회원가입 과정에서 다른 createAt, updateAt, updateBy는 문제가 없이 정상적으로 저장되었으나, createBy 필드가 null로 설정되는 상황이었습니다.

 

이는 기본적으로 UserAuditorAware에서 인증된 사용자의 정보를 얻어와야 하는데, 회원가입 시 인증된 사용자가 없기 때문에 createBy 필드가 설정되지 않는 문제가 발생했습니다. 이로 인해 createBy 필드에 null이 들어가며, 데이터의 생성자 정보가 누락되고있었습니다.

 

문제 원인

• 인증 문제
  • UserAuditorAware는 현재 인증된 사용자의 ID를 createBy필드에 자동으로 설정하도록 설계되었습니다.
  • 그러나 회원가입 과정에서는 인증된 사용자가 없으므로 UserAuditorAware가 createBy필드를 설정하지 못합니다.
• 설계 의존성
  • createBy필드를 설정하기 위해 UserAuditorAware에 의존하는 설계에서 인증된 사용자가 없는 경우를 고려하지 못했습니다.

해결 과정

1. 문제 확인

• 회원가입 시 createBy필드가 null로 설정되는 문제를 확인합니다.
• UserAuditorAware에서 createBy필드를 설정하지 못하는 이유를 파악합니다.

2. 해결 방안 결정

• 문제를 해결하려면 회원가입 시 createBy필드를 별도로 설정하거나, 회원가입 요청이 인증된 사용자와 관련이 없으므로 createBy필드를 null로 두는 것이 적절할 수 있습니다.
• createBy를 null로 두는 것은 적절하지 않다고 판단했으므로, 별도로 회원가입 로직에서 createBy필드를 별도로 설정하기로 결정합니다.

3. 코드수정

• 회원가입 로직에서 createBy 필드를 명시적으로 설정하도록 코드를 수정합니다.
• 회원가입 시 인증된 사용자가 없으므로, 이 값을 별도로 설정하여 데이터 생성자의 정보를 올바르게 기록할 수 있도록 합니다.

4. 테스트

• 수정된 회원가입 로직을 테스트하여 createBy 필드가 올바르게 설정되는지 확인합니다. 3번의 그림에서 확인할 수 있듯이 createdBy필드가 정상적으로 저장되고 있도록 수정이 완료되었습니다.

교훈

• 유연한 설계 필요
  • 인증된 사용자와 관련된 필드를 자동으로 설정하는 로직은 인증 상태와 관계없이 동작할 수 있도록 유연하게 설계해야 합니다.
• 명시적 설정
  • 인증되지 않은 상태에서도 필요한 필드를 명시적으로 설정할 수 있도록 처리하여, 데이터의 무결성을 유지합니다.
• 시나리오 고려
  • 다양한 시나리오(예: 인증된 사용자와 비인증 사용자)를 고려하여 설계하고, 예외 상황에 대한 처리를 명확히 합니다.