[BE] refactor: 회원 서비스 운영에 필요한 기본적인 회원 속성 추가

[Kimprodp]

• resolves [BE] 회원의 속성을 상세히 정의한다. #1099

---

🚀 어떤 기능을 구현했나요 ?

• 서비스에 회원 기능이 추가되면서, 회원 관리에 기본적으로 필요한 속성 값들을 정의했습니다.

🔥 어떻게 해결했나요 ?

• 회원 상태, 생성일, 수정일을 추가했습니다.

📝 어떤 부분에 집중해서 리뷰해야 할까요?

• 더 필요한 속성이 있는지 확인해주세요.

📚 참고 자료, 할 말

[github-actions]

Test Results

162 tests   159 ✅  5s ⏱️
 62 suites    3 💤
 62 files      0 ❌

Results for commit 72cc4fc.

[nayonsoso]

테드는 회원 탈퇴나 회원 정보 수정같은 것도 염두에 두고 있군요!

사실 처음에는 "우리 서비스에 이런 기능이 필요할까?" 싶었는데,
지선생님이 말씀하시길 개인정보 관리법에 의하면 사용자가 자신의 정보를 삭제할 수 있는 권리가 있다고 하여
회원 탈퇴는 경우 합리적인 정책이라 생각해요.

그런데 수정은~~~ 잘 모르겠어요🥲
우리는 email 만 저장할거고, githubOAuth 만 생각한다면 이메일이 바뀔일은 없고, 바뀌면 안되기도 하고요.
생성 일자도 필요한가? 싶긴 합니다🤔

그래서 왜 이런게 필요하다고 생각했는지 테드의 생각을 더 들어보고 싶어요!

[Kimprodp]

서비스에서 회원을 다루면 기본적으로 필요한 속성들이라 생각되어서 넣었어요.

회원 관련 기능을 도입하는 이상, 최소한의 관리 정보(회원 상태, 생성일, 수정일)는 기본적으로 포함하는 게 맞다고 생각해요.

당장 회원가입 일자가 필요하지 않는다고 해서 넣지 않으면 나중에 필요할 때 사용할 수 없어요.
만약 나중에 회원 정보 조회 기능을 추가한다고 했을 때, 회원 가입 일자를 표시해주어야 하는데, 그때 생성일자를 추가하면 너무 늦어요.

또한 회원 수정이 단순히 정보 수정만 있는 것이 아니라, 회원 상태의 변경도 수정에 포함이에요. 회원 정보를 수정할 일이 없다고 단정 짓기엔, 추후 회원 탈퇴(비활성화), 재가입 시 복구 여부 처리, 계정 정지 등 회원에 관한 정책이 들어올 수 있게 최소한의 상태 변경 기능은 구현해두어야 해요.

이렇게 회원 정보는 다른 엔티티 처럼 단순한 데이터 저장이 아니라, 어느정도 운영적 책임이 따르는 부분이기 때문에 관리 기준이 필요하다 생각해요. 그런 부분에서 이메일 하나만 저장하는 방식은 무책임한 접근이라고 생각해요.

---

추가로 이런 이유로 이번 일정에 포함시켜서 적용해야 한다고 생각해요! (회원을 받기 이전에)