4주 팀 프로젝트 질문답변 정리

Suxxzzy.log·2022년 5월 15일
0

프로젝트

목록 보기
2/2

소셜계정 로그인 기능 구현 시, DB의 사용자 테이블은 어떻게 구성하셨나요?

  1. 사용자 테이블은 하나로 관리하였습니다.
    사용자 테이블을 소셜 계정별로 두는 방향도 고려하였으나, 그렇게 할 경우, 테이블 관계 설정이 복잡해지고 관리가 어려워 질 것이라 판단하여 하나의 테이블로 만들었습니다.

  2. 비밀번호 컬럼에는 null값을 허용해 주었습니다.
    자체 회원가입과 달리, 회원가입 시 비밀번호가 필요하지 않기 때문입니다.

  3. 이어서 자체회원과 소셜회원을 구분하는 platformtype 칼럼을 추가하였습니다.
    소셜회원의 경우 비밀번호가 없기 때문에 마이페이지에서 비밀번호 변경 기능을 보여줄 필요가 없다고 판단하였습니다.
    비밀번호의 유무로 소셜회원을 구분하기에는 보안상 위험하다고 생각했습니다. 이에 클라이언트 단에서 두 회원을 구분하기 위한 별도의 기준으로 platformtype을 추가하였습니다.

  4. 닉네임의 경우, 소셜계정에서 직접 가지고 오기 때문에 일반 사용자 또는 다른 소셜 계정 사용자의 닉네임과 겹치지 않도록 하는 과정이 필요했습니다. 동일한 닉네임을 가진 사용자가 이미 존재하는 경우, 현재 사용자의 닉네임에 임의의 숫자 2를 붙여 가입을 하도록 하였습니다.
    하지만 현재 닉네임의 최대 길이는 12자이므로 만일 12자의 닉네임을 가진 기존 회원이 존재하고, 동일한 닉네임을 가진 소셜회원이 가입하고자 할 경우, 가입이 불가능한 문제가 생길 수 있습니다.
    프로젝트 당시에는 닉네임의 최대 여유를 좀 더 늘리는 방향으로 잡는 방향으로 해결했지만, 이는 일시적인 해결 방안에 불과하다고 생각합니다. 현재는 이보다 더 나은 해결책이 있을 것이라고 생각하며, 이에 대한 부분은 추후 개선해 나가도록 하겠습니다.

이미지 업로드 로직은 어떻게 구현하셨나요?
[서버] multer-s3를 사용하여 S3에 이미지를 저장하고, DB에는 S3상의 해당 이미지 주소를 저장하는 방식으로 구현했습니다.
form data 형식으로 전달된 이미지는 DB 상에 직접 저장하기에는 용량이 크며, 로딩 속도도 느리다는 문제가 있어 url주소만 저장한 것입니다.
클라이언트 측에서 이미지를 form data 형태로 서버에게 보내주면, 서버는 자신이 접근할 수 있는 S3 버킷에 이미지를 올립니다. 이때, 클라이언트에서 서버로의 이미지 전달을 위해 multer를, 서버가 S3 버킷에 접근하고 객체를 다루는 것을 허용하기 위해 multer-s3, aws-sdk를 사용하였습니다.
S3에 이미지가 업로드되면, multer-s3에 의해 S3상의 이미지 주소가 반환됩니다.
서버는 이 주소를 DB에 저장하고, 클라이언트에게 주소를 응답하게 됩니다.
클라이언트는 해당 주소로 접근하여 이미지를 화면에 렌더링할 수 있습니다.

이미지 수정 및 삭제에서는 S3 버킷에 남아있는 기존 이미지를 삭제하는 과정이 필요했는데, 어떻게 구현을 해야 할지 고민을 많이 했습니다.
게시물의 id값을 사용하여 테이블에서 이미지의 주소를 알아낸 다음, S3에서 제공하는 s3.deleteObject API에 삭제할 이미지 주소를 전달하여 삭제가 되도록 구현하였습니다.
(추가적으로 이미지 업로드 로직을 조사 중 presignedUrl이 있다는 것을 알게 되었습니다. multer-s3 방식과 달리 이미지 파일이 서버측을 거치는 번거로움이 없다는 점에서 해당 스택을 사용해보려 했으나, 이해할 시간이 부족하여 multer-s3를 선택했습니다. 해당 부분에 대해서는 좀 더 공부해 보고 추후 개선해 나가도록 하겠습니다.)

profile
몫을 다하는 사람

0개의 댓글