“ 코드 리뷰에 대한 사항 ”

• 프론트에서 만료 5분 전 전달 (토큰 생성 시 만료값 tmi) O

  • 로그인 시 토큰에 대한 만료시간은 프론트 측에 전달되지 않도록 재설정

• 소셜 회원가입과 로그인은 하나의 과정으로 처리 가능 (O)

  • 분기를 통해 소셜 유저 있는지 조회
    • 없다면 회원가입 처리
    • 있다면 로그인 후 토큰 발급
    • oAuthSignUp쪽에 oAuthSignIn로직을 합치는 방안을 선택 (소셜 ‘로그인’ 시 처리 하는 것이기에)

• 쓸데없는 코드 삭제 - 안쓰는 코드, 이중 중복 체크 (O)

  @Override
  	@Transactional // 회원가입 시 유저db에 값 저장 필요
  	public void signUp(SignUpRequestDto loginRequestDto) {
  		log.info("사용자 가입 시도: 로그인 ID = {}", loginRequestDto.getLoginId());
  
  		String createdUuid = "normal-"+ UUID.randomUUID().toString();
  
  		while (authRepository.existsByUuid(createdUuid)){
  			createdUuid = "normal-"+ UUID.randomUUID().toString();
  		}
  		// 여러 스레드가 동시에 signUp 메서드를 호출할 경우, Race Condition이 발생할 수 있음
  		// @Transactional 사용 시, 중복 UUID가 발생할 경우 전체 작업이 롤백되므로 데이터의 일관성을 유지할 수 있지만 회원가입 시 튕기는 현상또한 옳지 않다고 판단
  
  		authRepository.findByLoginId(loginRequestDto.getLoginId()).ifPresent(user -> {
  			log.warn("중복된 사용자 발견: 로그인 ID = {}", loginRequestDto.getLoginId());
  			throw new BaseException(BaseResponseStatus.DUPLICATED_USER);
  		});
  
  		authRepository.findByUserEmail(loginRequestDto.getEmail()).ifPresent(user -> {
  			throw new BaseException(BaseResponseStatus.DUPLICATED_EMAIL);
  		});
  
  		// 외부 api에 값 전달
  		writeUserProfile(createdUuid, loginRequestDto.getNickname());
  
  		authRepository.save(loginRequestDto.toEntity(passwordEncoder, createdUuid));
  
  	}
  

→ 아이디 중복 체크와 이메일 중복 체크는 프론트 단에서 api 호출 통해 먼저 처리 가능하기에 회원가입 로직시때까지 처리될 필요는 없음