11/04 : 3번째 멘토링 / 중간점검

전체적인 멘토링 피드백

1. 비밀번호 암호화
   비밀번호 평문으로의 저장은 보안 위험을 초래한다. 사용자의 개인 정보를 안전하게 유지할 수 있도록 비밀번호 암호화가 필요하다. 생각은 하고 있었는데 우선순위를 뒤로 미뤄놓은 상태라...전반적으로 프로젝트가 완성이 되면 꼭 구현해야겠다. 
2. 회원가입에서 전화번호의 필요성
   사실 큰 이유가 있다기보다는 기본적인 회원가입폼에 어떤 항목들이 있지..? 하고 넣은건데 딱 찝어주셨다. 핸드폰으로 회원가입 인증을 하는 것이 아닌 이상, 개인정보 보안상 굳이 필요하지 않다면 안넣는게 더 나을 수도 있다는 피드백을 받았다. 생각해보니 인증을 이메일로 구현했기 때문에 멘토님 말씀대로 핸드폰은 굳이 안넣어도 될 거 같다는 생각이 들었다.
3. 회원가입 이메일 인증 시 유효기간 설정
    ⇒ 유효기간은 보안과 사용자 경험 측면에서 균형을 맞추어야 한다. 너무 짧으면 사용자에게 충분한 시간을 주지 않을 수 있고, 너무 길면 보안 문제를 초래할 수 있다. 보통은 24~48시간 정도로 설정된다는데 사소하지만 고민해봐야할 부분이다.
   
   • 보안 강화: 이메일 인증을 통해 계정을 활성화하면 계정이 실제로 사용자의 이메일 주소에 속하는지 확인할 수 있다. 유효기간이 있는 링크를 사용하면 중요한 보안 요소 중 하나인 시간적 제한을 부여할 수 있다.
   • 계정 관리: 사용자가 이메일 인증을 통해 계정을 활성화하지 않으면, 불필요한 계정이나 쓰레기 계정이 시스템에 쌓일 수 있습니다. 유효기간을 통해 이러한 문제를 방지할 수 있다.
   • 데이터 보호
4. 일정만들기에서 페이징처리
   맛집이나 숙박 등의 정보가 페이징 처리가 안된 상태로 쭉 나오다보니 로딩 시간이 증가되고 서버 부하도 증가될 것. 그러니 페이징 처리가 필요하다.
5. 일정만들기에서 헤더부분을 반응형 페이지로 수정하는것 추천
6. 일정만들기에서 ‘추가’를 누르면 시간을 입력받는 모달창
   현재 일정만들기를 누르면 모달창을 통해 여행제목과 여행날짜를 입력받고, 그 과정에서 고유의 travelID가 저장된다. 그러고나서 일정만들기 페이지로 넘어가게되고, 그 travelID를 통해 각각의 세부일정이 1대N으로 저장되는 상태로 구현해놨다. 이렇게 했을 때의 단점을 짚어주셨는데 예를 들어 쇼핑몰에서 장바구니에만 넣어놓고 그대로 방치해놓는 사용자가 많은데 이걸 일일이 다 DB에 저장하게 되면 너무나 더미들이 많이 쌓이게 된다는 것이다. 그래서 이것을 두번의 과정을 거쳐 DB로 넘어가게 하지 않고 한번에 저장되게 하는 방법을 생각해보라고 하셨다. 
   • UUID를 방법 중의 하나로 생각해봤다.
     UUID란 "Universally Unique Identifier"의 약어로, 각각의 UUID 값이 전 세계적으로 고유하다는 특징을 가지는 식별자이다. 임의로 생성된 128비트(16바이트) 길이의 16진수 문자열로 표현되고, 이러한 식별자는 주로 정보 시스템에서 고유한 식별이 필요한 많은 상황에서 사용된다.
   • 쿠키 활용
   • 여러 가지 방법을 생각해놓고 아직 고민중인 상황이다.
7. 일정보관함 지도에 경로(화살표)를 구현못한다면, 1번 2번 숫자로 순서 표시해볼 것
   아무래도 경로까지는 구현못할거같아 고민중이었는데 그렇다면 숫자를 통해 순서 표시해볼 것을 추천해주셨다. 
8. 일정 수정하기 ⇒ 여러가지 방법 고민중
9. 게시판 ⇒ 현재는 수정 삭제 버튼이 글 목록에 다 보여지고, 글쓴이가 아닌 사람이 눌렀을땐 '작성한 사람 아니면 수정 또는 삭제 할 수 없다' 고 알림창이 뜨게 구현해놓은 상태이다. 하지만 이렇게 밖에 보여지는게 아니고, 권한이 있는 유저에게만 보이도록 구현하는 것을 추천하셨다.
10. 메인 페이지에 화면
    1. 사진 크기 수정 ⇒ 메인 페이지의 캐러셀에 세가지 사진을 셀렉해놨는데 하나만 크기가 조금 달라서 수정해야한다.
    2. top을 네비게이터처럼 창을 내리더라도 따라오게끔 해야 사용자에게 우리 사이트를 사용하도록 (일정을 만들도록) 하는 데에 도움이 될 수 있다.
11. 일정 상세보기에서 지도 연동으로 인한 서버 부하 문제를 여쭤봤는데 어느 정도의 서버 부하는 어쩔 수 없다.  유저들에게는 일정을 짰을 때 처럼 똑같이 지도로 보여지는게 가장 편할 것이기 때문에 서버 부하를 감수하고 그대로 두는 것이 좋겠다는 답변을 받았다.
12. interceptor 질문에 대한 답변이 의아했다. 스프링MVC에서는 인터셉터를 통해서 로그인 확인 여부를 체크한다고 배웠기 때문에 우리팀 뿐만 아니라 거의 전체의 팀이 인터셉터를 사용했을 것이다. 그런데 멘토님들께서는 대부분 필터를 사용한다고 하셨고... 사실 그 이후의 말씀들은 잘 이해가 안갔는데 시간이 부족해서 더 여쭤보질 못했다.

 

---

 

 

중간발표를 위한 PPT 작업

그리고 다음주 7일에는 모든 팀의 중간발표가 있어서 PPT 작업을 했다.

중간발표라니...강사님들 멘토님들 외에 다른 사람들에게 작업물을 처음 보여주는거라 괜히 긴장된다.

 

 

---

 

 

중간점검

우리끼리의 중간점검도 해봤다.

1. 프로젝트의 주요 기능들은 대체로 구현이 끝나가고 있다. 남은 시간에 추가할만한 미뤄놨던 부가 기능들을 생각해보자.

2. 똑같은 작업을 동시에 하는 데도 매일매일 각각 다른 충돌과 오류가 발생했던 지난 날들...뭐 하나 푸쉬하기가 괜히 겁날 정도였는데(ㅋㅋㅋㅋ) 이제 좀 패턴이 안정화된 것 같다. 

3. 약속했던 커밋 컨벤션도 잘 지키고 있다.

4. 훌륭한 점은 매일 각자가 담당한 부분을 코드 리뷰하고 있다는 점! 개발 역량 향상과 함께 코드의 일관성을 유지하고 잠재적인 오류를 사전에 방지하는 효과가 있는 것 같다. 훌륭한 팀워크 👏✨