BE ‐ Signup Verification

• 이메일 인증을 위한 DB 설계

회원가입 시 유저가 입력한 이메일 주소로 개인 인증을 시도했습니다. 유저가 입력한 이메일로 인증 코드를 보내면, 난수를 생성하여 DB에 저장하는 동시에 유저 이메일에 해당 코드를 전송하도록 했습니다. 저장한 난수와 유저가 입력한 코드가 일치한 경우 인증 성공하도록 처리했습니다. 따라서 해당 유저 이메일과 발급한 인증코드를 저장하기 위한 DB를 설계해야 했습니다. 이를 위해 총 세 가지 방법을 고안했습니다. 첫번째는 기존 User라는 테이블에 verified 칼럼을 추가하는 것입니다. 두번째는 별도 테이블을 생성하는 것입니다. 마지막은 Redis DBMS에 저장하는 것입니다. 인증 코드는 임의로 설정한 유효 기간 동안만 필요한 데이터라는 점, 유저가 여러 번 이메일 인증을 시도할 수 있기 때문에 한 번에 여러 개 인증 코드 값을 저장해야 하는 경우가 있다는 점 등으로 Redis에 Key - Value 쌍으로 가입 시도자 이메일과 인증 코드를 저장하는 방식으로 구현하기로 결정했습니다. 모든 구현을 마치고 작동 테스트까지 완료했습니다. 문제는 Local환경에서만 잘 작동하고 CloudType을 통해 배포한 페이지에서는 정상 작동하지 않는다는 점이었습니다. Redis를 배포하기 위해서는 또 다른 배포 서버가 필요했고, 이는 팀이 주도한 환경에 맞지 않았습니다. 결국 이런 이유로 Redis DB를 포기하고 Verification이라는 별도 테이블을 생성했습니다.

• 이메일 인증 난수 설정

무작위 인증 코드를 6자리 숫자로 설정했습니다. 그런데 이는 보안에 취약한 숫자입니다. 경우의 수가 많지 않기 때문에 만약 해커가 마음만 먹는다면 모든 경우의 수를 쉽게 시도해볼 수 있기 때문입니다. 따라서 문자까지 섞어서 경우의 수를 크게 설정하는 편이 보안에 강력합니다. 이를 쉽게 하려면 UUID마지막 6자리 값을 주었습니다.

• Util 네이밍은 언제 적합할까?

@Service 어노테이션을 단 클래스에 ~Util이라는 네이밍을 했습니다. 이는 옳지 않은 네이밍입니다. Util은 어디서든 쓸 수 있는 툴이라는 뜻이기 때문입니다. 여러 곳에서 사용하는 util성 기능을 모아둔 클래스에 해당 네이밍을 합니다. 프로젝트 전역에서 사용할 수 있는 기능을 갖는 것이 특징입니다. input output이 명확한 경우에 자주 쓰입니다. 만약 ~Util 클래스를 만든다면해당 Util은 functional하게 만들어야 합니다.