로직 ) 로그인, 메일 인증

사용자들이 처음으로 마주할 서비스, 로그인.

로그인이 기초이자, 보안이 걸려 있고, 완성도를 좌우한다.

 

학부시절엔 그냥~ input으로 생 텍스트를 넣고, 대충 인증받아 했지만, 실제 서비스는 달랐다. 사용자 정보를 받아 보관하는 만큼, 중요한 공지를 날려야 하기 때문에 연락처, 메일 등은 유요해야 하고, 암호화 해야했다. 또, 서비스를 배포하면서 개인정보보호법도 신경서야 했다. 아무튼, 개발을 진행하면서 내 생각이외로 더욱 디테일한 개발이 필요했다.

 

핸드폰 인증은 사전에 sdk를 신청해야하고, sms 비용을 부담하기 때문에 다음에 정리하기로 했다.

메일인증을 처음 할땐 조금 헤맸는데, 로직이 정리되고 나니 비교적 간단한 방법이었다.

이때 크게 두가지 갈래로 나뉜다. 메모리 시스템(Like Redis...)을 사용하는지 / 바로 DB에 저장하는지

 

{ 메일과 관련된 서비스 }

• 회원 가입 메일 인증
• 메일 인증 시간 초과시 데이터 삭제
• 비밀번호 수정

 

{ 방법 A }

• 회원 가입 요청
• 서버 메모리에 회원가입 요청한 사용자 정보 저장 (이때 key값 정의)
• 암호화된 인증용 링크 메일에 삽입
• 인증용 링크 접속 → 메모리에 저장된 사용자 정보 DB에 저장
• 시간 초과 → 메모리에 저장된 사용자 정보 삭제

 

{ 방법 B }

• 회원 가입 요청
• DB에 원가입 요청한 사용자 정보 저장 (key 값 정의/인증여부 False 처리)
• 암호화된 인증용 링크 메일에 삽입
• 인증용 링크 접속 → DB에 저장된 회원 정보 수정 (인증여부 True 처리)
• 시간 초과 → DB에 저장된 회원 정보 삭제

 

{ 방법A } 처럼 메모리로 데이터를 관리하면 불필요한 DB 쿼리문을 줄일 수 있다는 장점이 있다. 대규모 트래픽에서 DB Lock이 걸릴 확률이 완존 완존 줄어들고, DB 서버와의 트래픽 비용도 감소시킬 수 있다. 하지만 메모리 시스템을 넣을 여건이 안되면 B로 가야한다.

난... 메모리 시스템을 추가하기 너무 멀리와버려서 { 방법 B }를 선택했다. 

 

---

메일 인증 개발을 진행하면서 기획자와 소통하기 어려웠던 부분이 하나 있었다. 서로 플로우가 뭔지 정의가 되지 않아 각자 다른 이야기를 하기도 했었다. 그래서 정리한 예시 이미지다... 하하

개발-기획자 회의에선 [ 개발에 필요한 단계 간략한 설명 + 예시 이미지 / 기획에서 구현 불가능한 부분 설명 & 대안 / 명확한 요구 ] 이 세 가지가 중요한 것 같다. 이래야 서로 싸움 없이 그나마,,, 원활하게 진행되는 듯.

 

이미지 출처1

 

회원 가입 → 아이디 중복 여부 체크 → 메일 발송 성공 여부 → 사용자 메일함 → 메일 인증 버튼 클릭 → 유효성 확인 → 회원가입 실패/성공 표시

 

 

 

개발 로직 도식화