DevLog
2022.02.11
Today's contribution
- Client Flowchart, Requirements, Todolist
Today's problems
소셜 로그인 || 자체 회원가입 || 둘다?
고려해야 했던 부분들
- 토론사이트이기 때문에 본인인증이 필수인 점
- 자체 회원가입으로 할거면 비밀번호 암호화 필수인 점, 그러나 First Project에서 비밀번호 암호화 작업에서 에러문제로 제대로 구현을 못했기 때문에 이번에도 완벽히 구현해 낼 것이라는 확신이 없는 점
- 소셜 로그인과 자체 회원가입 둘 다 도입할 경우, 회원탈퇴 시 사용자가 직접 소셜과 자체의 연동을 끊지 않는 경우 한쪽에만 db가 살아있는 상태가 생길 수 있어 로직이 복잡해져 해결이 어렵다는 점
- 자체 회원가입을 이미 했는데, 소셜로 연동하면 db에서 어떻게 처리할건지 정해야 해서 복잡한 점. 같은 email일 경우엔 한 사람으로 간주하고 소셜 정보로 덮어씌우면 되지만 (그러나 자체회원가입한 '비밀번호'는 암호화 때문에 살아있어서 이것 또한 문제), 같은 email이 아닐 경우에는 한 사람이 계정 여러개를 만들게 되니 문제. 토론사이트라는 특성을 감안해 1인 1계정, 1인 1투표가 이뤄져야 하기 때문이다.
- 정보검색결과, 요즘에는 소셜로그인만 만드는 게 트렌드. 간단한 인증수단으로 작용하기 때문.
- 소셜계정이 없는 사람이 있을수도 있는데? -> 이 경우에 우리 사이트는 문제되지 않음. 주 타켓층이 학생이거나 젊은층인 10~30대이므로 대다수가 소셜계정 보유할 것을 예상.
결국엔 소셜 로그인
- 자체 회원가입을 도입하려면 비밀번호 암호화가 필수인데, 비밀번호 암호화를 100% 완벽하게 구현해낼 수 없다면, 어설프게 정보망이 뚫리는 바에야, 고객들의 정보를 지키기 위해 안전을 택했다.
- +설득력 높이기 위해, 소셜로그인만 도입한 사이트가 유저 가입율이 증가했다는 증거자료 있으면 좋을 듯)
- 개발자 입장에서 로그인 구현에서 시간절약하고, 다른 부가기능을 개발하는 데 시간할애를 더 하는 효율성도 고려했다. (주어진 시간은 한달이므로. 실질적으로는 2주.)
Today I Learned
- Page : 주소를 가지는 애 -> 'Forum' (http://localhost:3000/debateducks/forum)
- Component : Forum 페이지에 나오는 debates list -> 'Debates'
- Component와 Page의 경계가 모호할 수 있는데, Component 는 상위, Page 는 하위로 생각하기 -> Main에는 Forum, Ranking, Community 등의 component가 있는데, Forum을 클릭하면 Forum Page로 이동하므로.
소소한 소감
- 확실히 하루 날 잡고 Flowchart를 작성해보았더니 사이트 전반적 로직이 정리가 되었다. First Project 때는 팀원분들이 설명해주시는 flow도 이해를 잘 못했던 경우가 많았는데, 지금은 혼자 Flowchart를 작성할 수 있고 애매한 부분은 메모를 남겨 함께 논의를 시작해 볼 정도의 수준으로 발전을 했다는 게 느껴진다.
- 아직도 부족한 점은 많지만 풍월을 읊는 서당개가 될 수도 있겠다는 희망이 보인다.