[포스코x코딩온] 풀스택 부트캠프 4차 프로젝트 -1

이제 4차 프로젝트다.

프로젝트 컨셉은 날씨에 맞는 옷을 추천해주는 옷장이다.

spring boot (REST API)와 next.js를 이용한 프로젝트가 될 것 같다.

 

그래서 날씨에 맞는 옷을 추천해주는 방식에 대해서 생각한 결과 요즘 핫한 chat gpt api를 활용해 보자는 의견이 있어서 그렇게 진행하기로 하였다.

 

근데 생각보다 gpt가 똑똑하지는 않은 것 같다. 그래서 거의 가스라이팅 수준으로 조건을 주니까 그래도 의도에 맞는 답변을 하는 것을 확인하였다. 그래서 이런 방식으로 진행하게 되었다.

 

나는 그중에서도 일단은 DB를 비롯한 백엔드 전체를 담당하게 된 것 같다.

회의하던 도중 db는 NOSQL인 몽고 db를 사용하기로 하고 repository와 service, document, controller 등을 짜는데 커뮤니티와 댓글 entity를 짜려고 하는데, 몽고 db는 그냥 다 때려박을 수 있다는 것이 장점이기 때문에 그러한 방식으로 DB를 짰다. 

하지만 한 가지 생각이 머리를 스쳤다. 만일 댓글을 post 안의 Array로 담게 된다면 댓글을 수정할 시에 댓글을 특정할 수 있는 어떤 특정한 unique한 값이 필요한데. array의 index말고는 없었다. 또한 접근할 때도 게시글 > 댓글 이런식으로 접근해야 해서 비효율적이라는 생각이 들었다.

그래서 게시글의 objectID를 담는 구조로 만드려고 했는데, 그렇게 되면 관계형 데이터베이스와 다를 것이 없었다.

지금 강의들으면서 알게 된건데 uuid + timeStamp로 유니크한 값을 만들 수 있다. 그렇게 된다면 객체로 넣어주면 될 것 같다. (HashMap으로)

 

게다가 개인 옷장과 별도로 지금까지 등록된 모든 옷이 등록되는 전체 옷 정보 테이블이 필요한데, 만약 NOSQL이라면 개인 옷장에도 옷 정보가 들어가야 하고 옷장에도 옷 정보가 들어가야 한다. 

그래서 RDBMS가 더 나을 것 같다는 생각을 하였고 결국 MYSQL로 바꾸었다.

그래서 미리 짜놓은 몽고 DB는 시원하게 삭제했다.

 

음.. 그래도 도커로 db 두개 짜는거는 해봐야하나.. 싶기도 하다

 

바꾸는 도중 예상 외의 복병을 만났다.

옷 정보의 경우 상분류 (TOP, OUTER, PANTS) 이런 식의 ENUM으로 나뉘는데, 중분류에서는 (TOPMIDDLE, OUTERMIDDLE, PANTSMIDDLE)에 해당하는 ENUM이 따로 존재했다.

그래서 등록할 때 MiddleCategory라는 interface를 하나 만들고 그 것을 implement하는 TopMiddleCategory 같은 ENUM을 여러 개 만들었다. 그렇게 정보를 insert 할 때 type을 정할 수 있었는데,

이게 JPA에서는 enum 타입인데 interface로 받는다고 해서 타입이 다르다고 오류가 발생했다.

그래서 혹시 enum에도 extends가 가능한가 해서 해보니까 안된다고 한다.

(당연히 enum은 열거형 상수니까 안된다.... 이때는 개념이 잘 안잡혀서 몰랐나보다. extends는 class만 된다)

이유는 이렇다고 한다. 솔직히 이젠 gpt가 신빙성 없는 소리를 할 확률이 높다는 것을 알고 있지만, 이 건 맞는 것 같다.

 

 

 

 

그리고 다른 방법을 알려줘서 이걸 실험해봤는데...

안된다.

 

이건 완전 똑같이 보여주고 있지만 아마도 MiddleCategory에 다른 값이 들어있고, OuterMiddleCategory에는 또 다른 값이 들어가는 구조를 의도했으리라.

하지만 이렇게 해도 MYSQL에서는 객체 자체를 저장할 수가 없는 구조이기 때문에 조금 이상하다는 생각을 했고, 이게 맞았다.

이렇게 하면 제일 위 ENUM만 들어간다. 나의 경우는 MiddleCategory를 완전히 비우고 나서 안에 ENUM을 넣었기 때문에 MYSQL이 ENUM을 설정했는데 그에 대한 데이터가 들어오지 않아서 계속 오류를 반환했다. 그래서 결국에는 하나의 미들 카테고리에 다 넣기로 했다. 유저 측에서도 어차피 select로 받을 거니까 top - slacks와 같은 이상한 조합이 나오지 않는다고 생각하면 될 것 같다.

 

 

또한 실무에서는 유저 데이터가 삭제된다고 해도 물리삭제가 아닌 논리삭제로 구현한다는 듯 하다. 거의 모든 자료를 모아두는 것 같다. 그래서 사람들이 개인정보에 민감해지는 것 같기도 하다.

그래서 이런 식으로 진행하게 될 것 같다.

아이디 회원탈퇴를 해도 예전 아이디로 새로 회원가입이 불가능했던 이유가 바로 여기 있었던 것 같다.

그러면 내가 이상한 글을 쓰고 바로 삭제한다고 해도 DB에는 남아있는 것이 된다...

무섭다

그나저나 진짜 스프링부트 1주일하고 프로젝트 하는건 너무 빡세다.. 공부만이 살길이다...