1. 체형을 ENUM으로? 테이블로?
   • ENUM으로 가져가면 간단하고 가벼움 → 하지만 확장이 불가능
   • 테이블로 가져간다면 확장성이 높고, 체형 기준이나 설명 등 다른 컬럼이 추가될 수 있음
   • 체형이 확장될 수 있는가?
   • 체형이 세분화되어서 새로운 체형이 나온다면? → ENUM으로도 해결 가능
   • 하지만 기준 같은걸 보여주려면? 컬럼에 값을 가지고 있는게 편하긴함
   • 만약 ENUM으로 한다면 체형을 결정하는 로직에서는? 그냥 코드상에서 하드코딩
   • 만약 테이블로 한다면 체형을 결정하는 로젝에서는? 테이블에서 체형 정보를 빼와서 그 체형 범위 컬럼 내에 포함된다면 그 체형으로 설정가능
   • 하지만 이 작업을 위해 DB에 접근해서 가져오는게 오버헤드가 크지는 않나?

• 이에 대한 gpt 답변

1. 본인 데이터 처리 요청을 받았을 때 아이디를 같이 받을 것인가 jwt에서 유저 정보를 빼와서 사용할 것인가 고민
2. dto 자체에 객체를 넣어서 전달해도 되나??
3. → 이 고민이 이어져 굳이 User 객체를 조회해야하나 라는 생각을 하게되고 결국은 SecurityContextHolder에 저장된 User를 가져오면 되는게 아닌가? 라는 생각에 도달

→ 근데 User를 들고있어도 되나?

1. 기준표를 db에 저장하고 있을 것이냐

db에 저장하는 것이 확장성에 더 좋다.

1. SecurityContextHolder에 유저 객체를 들고있어도 되나?

2. 회원 디테일 페이지에서 필요한건 회원 테이블에 있는 정보보다는 운동 기록과 크루에 관한 내용이었다. 이러한 부분을 어떻게 해결할 것인가? 회원 서비스에서 다른 서비스의 메서드를 불러와 사용할 것인가? 이렇게 되면 서비스 간의 의존성이 늘어나고 잘못하면 뭐냐 그거 순환 참조의 위험이 늘어남 그러면 어떻게 할 것인가?

3. CrewMember를 조회하는 로직을 어떻게 구현할 것인가

   → Crew서비스에서 하려다보니 User에 대한 정보가 더 많이 필요함. 이게 문제가 되는 이유는 유저의 일주일동안의 운동 시간을 가져와야하는데 운동시간에 대한 정보는 ExerciseHistory라는 테이블에 존재함. 그럼 결국 ExerciseHistory의 레포지토리에서 검색해야하는데 Crew에서 회원을 거쳐 ExerciseHistory까지 가게되면 서비스 간의 의존성이 생기게됨. 이 문제를 어떻게 해결해야할까?

   해결: userId를 list로 만들어서 포함하고있는 ExerciseTime을 모두 구하도록 로직 구성 결국은 user와 exercisehistory를 각각 구하는 로직으로 만든건데 user는 이미 usercrew 구할 때 있으니까 exercisehistory만 userid를 통해 구함. 위에서 고민했던 문제와는 다르게 해결 왜 고민했나 싶은 정도