프로젝트 관련 문서 및 배포 주소
프로젝트에서 담당한 파트
- 회원 CRUD 기능
- 토큰을 이용한 인증
- 회원가입 유효성 체크
- 댓글 CRUD 기능
- DB 삽입
발생한 이슈
- 헤더에
userId전달
토큰을 통해 로그인을 진행을 했다. 각 이메일에 해당하는 유저의 userId 를 알 수 없는 상황이 발생했다. 각 유저의 유저페이지에 진입하기 위해서는 userId 가 필요한 상황이었다.
인증에 성공시, 응답 헤더에 userId 가 포함되도록 설정하여 프론트 측에서 로그인하면 userId 값을 알 수 있게 되었다.
- 중복 로그인
사실 중복 로그인에 대해서는 전혀 생각하지 못했었다. 테스트를 진행하던 와중에 문득 이 부분에 대한 생각이 들었고, 하나의 아이디로 각자 로그인을 시도해보았다. 결과는 당연히 중복 로그인이 되었다는 점이다. (중복 로그인에 대해 아무런 설정을 하지 않았기 때문에 되는게 당연한 일이긴 하다.) 그제서야 중복 로그인을 방지 해야한다는 생각이 들었고 maximumSessions , HttpSesstionListener , sessionRegistry 등을 사용해서 방지할 수 있다는 것을 알게 되었다.
하지만, 중복 로그인을 방지하는 것이 무조건적으로 옳은 것인가? 에 대한 의문을 품게 되었는데, 정답은 아니다 라는 것이다. 나는 1차원적으로 중복 로그인? 당연히 안되는게 맞지 않나? 라는 생각을 했었는데, 생각해보면 우리는 이미 여러 서비스에서 중복 로그인을 사용하는 것을 알 수 있었다.
- 쇼핑몰에서의 웹, 앱을 통한 동시 로그인
- 인터넷 강의 사이트 동일 ID를 이용한 동시 로그인
결론적으로, 동시 접속 로그인 자체는 문제가 아니다. 하지만 서비스마다 중복 아이디 사용에 대한 제한을 두는 방법이 존재할 것이다. 인터넷 강의 사이트가 좋은 예시가 될 것 같다. 중복 로그인까지는 허용이 되나, 학습 콘텐츠를 이용할 때 제한을 받게 되어 이용에 제한을 받는 경우다.
현재 프로젝트에서는 중복 로그인에 관한 설정을 하지 않았다. 하지만, 나중에 다른 프로젝트나 현업에서 이 부분에 대해 고민하고 진행해야 된다는 것을 느꼈기 때문에 좋은 경험이 된 것 같다.
- DB 삽입
결론부터 말하자면, DB에 대한 지식이 너무 부족했다는 것이다. 우리 조가 설계한 ERD의 한 테이블에는 7개의 외래키가 존재했다. SQL 쿼리문을 작성해서 DB에 데이터를 INSERT 할 때 외래키로 인한 에러가 계속 발생했다.
도저히 해결이 되지 않아서, 내가 사용한 방식은 EC2로 서버를 배포한 후 Postman 으로 DB 값을 넣었다. (물론 좋은 해결책이 아니지만, 프론트 측과 통신 테스트를 위해서 당장 DB 값이 필요했고, 이 방법을 사용했다.)
ORM 방식으로 프로젝트를 진행했는데, 어쩌다보니 ORM의 맹점을 직접 경험하는 순간이었다. 설계할 때 DB를 삽입하는 부분에 대한 고려를 못했고, 문제가 발생했던 것이다. 프로젝트에서 경험한 것이 오히려 다행이라는 생각이 들었다.
No Silver Bullet 이라는 말처럼 ORM에도 단점이 존재한다. 다른 기술에 대한 공부도 해야겠다고 느끼게 되었다.
