📚 미션소개
1단계 - 상품 관리 기능
이 미션은 Spring Web MVC를 이용하여 쇼핑몰의 상품 관리 기능을 구현하는 미션입니다.
상품 관리 페이지를 Thymeleaf를 이용하여 확인할 수 있도록 코드를 제공합니다.
이를 위해 상품 관리 CRUD API를 구현하고 사용자를 위한 상품 목록 페이지와 어드민을 위한 상품 관리 페이지를 연동해야 합니다.
요구사항
- 상품 목록 페이지 연동
- 상품 관리 CRUD API 작성
- 관리자 도구 페이지 연동
2단계 - 장바구니 기능
이 미션은 장바구니 기능을 구현하는 미션입니다.
이번 단계는 크게 인증과 장바구니 기능 구현으로 나눌 수 있습니다.
어떤 사용자의 장바구니에 상품을 추가하거나 제거할 것인지에 대한 정보는 Basic Auth를 이용하여 인증을 하도록 합니다. 사용자 설정은 설정페이지에서 다룹니다.
장바구니 기능은 인증 기반으로 기능을 구현하고 장바구니에 상품 추가, 제거, 목록 조회가 가능해야 합니다. 이 때 필요한 도메인 설계와 DB 테이블 설계 그리고 이에 맞는 패키지 설계에 유의해주세요.
요구사항
- 사용자 기능 구현
- 사용자 설정 페이지 연동
- 장바구니 기능 구현
- 장바구니 페이지 연동
🔍 질문했던 내용들
1. DAO의 반환값
정해진 건 없다. 정하기 나름.
나의 리뷰어의 경우
- save: id 또는 저장된 object
- find~ : Optional 또는 List
- update : void
- delete : void
2. update&delete 에 대한 예외처리
3. API의 반환값 - HttpStatus
나의 리뷰어의 경우
- create : 201(created)
- read : 200(ok)
- update : 200(ok)
- delete : 204(no content)
chatgpt의 추천
- Create: 새로운 자원을 생성하는 경우, 일반적으로 상태 코드 201 Created를 반환합니다. 이는 서버가 새로운 자원을 생성하였음을 의미하며, 응답 헤더에는 생성된 자원의 위치를 포함시키는 것이 좋습니다.
- Read: 자원을 조회하는 경우, 일반적으로 상태 코드 200 OK를 반환합니다. 이는 요청한 자원이 성공적으로 반환되었음을 의미합니다. 요청한 자원이 존재하지 않는 경우 상태 코드 404 Not Found를 반환할 수 있습니다.
- Update: 자원을 업데이트하는 경우, 일반적으로 상태 코드 200 OK나 204 No Content를 반환합니다. 전자는 업데이트된 자원을 반환하는 것이며, 후자는 업데이트된 자원이 본문에 없음을 나타내는 것입니다.
- Delete: 자원을 삭제하는 경우, 일반적으로 상태 코드 204 No Content를 반환합니다. 이는 서버가 자원을 성공적으로 삭제하였음을 의미합니다.
4. 예외가 발생했을 경우
Q. 예외가 발생했을 경우 4xx 5xx 이런 상태코드만 제대로 설정해주는 것이 좋은지 또는 적절한 예외 관련 메시지도 body에 넣어주는 것이 좋은지 궁금합니다!
A.
- bad request 같은 경우 : 클라이언트에게 무엇이 잘못되었는지 정확하게 알려주는 게 좋다(예시: 비밀번호는 문자 숫자 특수문자의 조합으로 8 이상으로 입력해주세요) 그러나 이 부분은 프론트와도 조율이 필요한 부분이라 프로젝트 또는 팀마다 정책이 달라질 수 있다.
- internal server error 등의 5xx 에러 : 에러 메세지를 그대로 내보낼 경우 내부 정보(디비, 테이블명, 필드 변수 등)가 유출되어 보안에 문제가 생길 여지가 있기 때문에 클라이언트 쪽엔 알 수 없는 에러가 발생했다고 하고 로그로 남기는 게 좋다.
📍 리뷰
1. Entity
답변)
엔티티는 도메인 영역의 일부이기 때문에 DTO와는 목적이 다릅니다. 도메인+데이터베이스의 테이블과 매칭되는 객체라고 생각해주시면 됩니다!
쉽게 말하자면 DTO는 웹, 서비스 레이어를 오가는 기차 같은 거고, 엔티티는 데이터베이스 내 테이블의 분신(?)과 비슷한 개념이라고 보면 됩니다ㅎㅎ
2. 로그 레벨
로그 레벨 : 소프트웨어에서 발생한 이벤트를 기록하는 로그의 중요도를 나타내는 단계
(디버깅, 모니터링 및 분석을 위해 로그를 사용하는 개발자나 운영자에게 중요)
- DEBUG: 디버깅을 위한 상세한 정보를 제공 -> 주로 개발 환경에서 사용
- INFO: 시스템이 정상적으로 작동하는지를 확인하는 정보를 제공
- WARNING: 잠재적인 문제가 발생할 수 있는 경고 메시지를 제공 (이벤트가 발생했지만 시스템이 여전히 작동 중인 경우)
- ERROR: 심각한 문제가 발생하여 시스템이 작동을 멈추거나 중단되는 경우
- CRITICAL: 매우 심각한 문제가 발생하여 시스템이 완전히 멈추는 경우(이러한 경우는 드물지만, 대응이 즉시 필요)
4. VARCHAR vs TEXT
5. @Valid vs @Validated
- @Validated 는 스프링 전용 검증 애노테이션
- @Valid 는 자바 표준 검증 애노테이션
- @Validated는 @Valid의 기능을 포함하고 있으며, 추가적으로 유효성을 검증할 옵션에 대한 그룹을 지정할 수 있는 기능이 있다.
6. 수정을 할 때에는 PUT, PATCH
- PUT : 리소스가 있으면 대체, 해당 리소스가 없으면 생성 (쉽게 이야기해서 덮어버림)
- PATCH : 리소스 부분 변경
+) PUT와 PATCH 둘 다 클라이언트가 리소스를 식별한다(클라이언트가 리소스 위치를 알고 URI 지정) <- POST와의 차이점
7. 엔드 포인트가 다르면 dto도 따로 만드는 것이 유지보수에 도움이 된다
8. Interceptor vs Argument Resolver
9. PK 지정 관련
pk를 지정하지 않으면 인덱싱이 되지 않아 조회 성능이 떨어질 수 있다.
- 대표 id를 pk로 사용할 경우 : 간단하며 성능과 인덱스 관리도 용이
- 복합키를 pk로 사용할 경우 : 대부분의 경우 더욱 유연한 데이터 모델링이 가능하다 but 성능과 인덱스 관리 측면에서 추가적인 고려 사항이 많아진다
10. FK를 설정하지 않으면 생기는 문제점
- 데이터 일관성이 깨질 수 있음
부모 테이블에서 데이터가 삭제되거나 변경될 경우, 자식 테이블에 있는 해당 데이터를 참조하고 있는 레코드들의 데이터 일관성이 깨질 수 있다. 즉, 부모 테이블에서 삭제된 데이터에 대해 자식 테이블에서 여전히 참조하는 레코드가 있을 수 있다. - 데이터 무결성이 보장되지 않음
자식 테이블에 부모 테이블에 존재하지 않는 데이터가 삽입될 수 있다.
11. 복합키를 어떻게 설계해야 성능이 잘 나올까?
12. RESTApi
13. Entity에서 id는 래퍼 클래스를 사용해야 한다
이유 : Entity의 ID 값이 null인 경우를 처리하기 위해서
기본 데이터 타입의 경우 null 값을 가질 수 없기 때문에, ID 값이 null인 경우 0과 같은 특정 값을 사용해야 한다.
그러나 이렇게 특정 값을 사용하게 되면, 실제 데이터베이스에서 해당 ID 값이 존재하는지 여부를 판단할 때(실제로 ID가 0인지, 없어서 0으로 세팅된건지) 문제가 발생할 수 있다.
14. interceptor에서 return false?
🛁 회고
- 레벨2 두번째 미션인 장바구니 미션을 끝냈다!
- 사실 첫번째 미션때는 너무 일찍 머지되어버려서, 미션 그 자체보다는 스프링 공부에 시간을 좀 더 쏟은 것 같다(미션<공부). 근데 스프링을 아무것도 모르는 상태였기 때문에, 공부에 시간을 많이 쏟았던 것이 좋은 선택인듯. 매우 만족 굿굿.
- 반면 이번 미션에는 공부보다 미션에 시간을 많이 쏟았다(미션>공부). 그리고 지금까지 모든 미션 중 가장 열심히 리뷰어와의 소통?질의?에 참여한 것 같다! 레벨2 목표 중 하나가
코드리뷰를 적극적으로 활용하자였는데, 이번 미션에서 그 목표를 잘 이룬 것 같아서 뿌듯하다ㅎㅎ - 드디어 테코톡을 끝냈다! 나의 테코톡 주제는
Spring vs Spring Boot였다. 하 .. 테코톡은 정말 그 존재만으로 엄청난 스트레스를 받고 있었는데, 어찌저찌 잘 끝내서 정말 다행이다 🤣- 이번 발표를 준비하면서 spring의 목적?에 대한 긴 글을 읽었는데, 뭔가 spring이라는 프레임워크의 전반적인 지향점(개발 목적)을 어느정도 알게 된 것 같다. 정말 잘 만들어진 프레임워크이다.. 인정..
- spring boot에 대한 자료가 많지 않아서, 김영한님의 강의를 수강했다. 내장 톰캣 관련 강의가 너무 인상깊었다... 아직도 기억이 생생해. 선릉 캠퍼스 회의실에서 강의듣다가 커다란 충격을 받았다😱 그런거였구나...
- spring framework도 아직 잘 모르는데 ㅋㅋ spring boot 공부를 하는게 맞나? 싶었지만, 결론만 말하자면 정말 좋은 시기에 좋은 공부를 한 것 같다. 뭔가 spring의 세부 기능을 떠나서 spring이라는 기술에 대한 커다란 맥락에서의 이해가 생긴 느낌!!
- 발표 전전날엔가 소코스 멤버 앞에서 시연했는데 다들 왜이리 잘했냐고 칭찬해줘서 고마웠다 ><
- 아 그리고 주변 크루들이 spring boot 관련 질문을 하면 내가 대답해주는게 신기했다 ㅎㅎㅎ (내가 말랑의 궁금증을 해소해주다니?)
- 하지만.. 이번 미션 키워드에 대한 공부는 좀 부실했던 것 같다😞
- 이번 미션 기간에는 휴일이 많았다(5월1일 근로자의 날, 5월5일 어린이날). 막 3일 연속 쉬는날 이래버리니까 나도 모르게 마음이 해이해졌나봐..ㅎ 아무래도 다음부터는 연휴라고 집에서 공부하겠다고 까불지 말고, 적어도 3일 중 하루는 캠퍼스에 가는게 좋을 것 같다. 의지를 믿지 말고 환경을 만들자^^
- 물론 이번엔 테코톡 이슈가 있었기 때문에 공부에만 집중할 수는 없는 상황이긴 했다. 그래도.. 휴일에 정신차리고 빠딱빠딱 했으면 부족한 공부량을 채울 수 있었을텐데 라는 아쉬움이 남는다.
- 근데 사실 공부를 아예 안한건 아니지만, 첫미션때에 비해서 정말 부실했다. 글을 하나도 못 쓰다니 흑흑..
- mvc 구조나 mvc config에 등록할 수 있는 애들(interceptor, argument resolver, view controller)이나 테스트 더블에 대해서는 얼추..? 아는 것 같고, 여러가지 테스트나 스프링 관련 테스트도 오늘 우테코 브레인들(허브,말랑,하입보이,글렌) 덕분에 많은 깨달음을 얻었는데..! 인증은 잘 모른다 >< 근데 뭔가 다음미션 키워드가 엄청 많지는 않은 것 같아서 다음 미션 때 좀 더 공부하려한다ㅎㅎ
- 소소한 코드 리뷰 스터디에 (드디어) 제대로 참여할 수 있게 되었다..! ㅋㅋㅋㅋㅋ 저번 미션때는 진짜 아는게 없어서 맨날 질문 폭탄이나 던지고, (리뷰 스터디인데) 리뷰를 제대로 못 달았었는데 ㅠㅠ 이제 좀..! 뭔가..! 달 수 있다..!ㅋㅋㅋㅋㅋ 😎
- 오늘(230508) 두번째 레벨 인터뷰 스터디를 진행했다. 이번 팀은 땡칠, 라온, 코코닥 이었다(근데 코코닥은 아파서 오늘 불참했다ㅠㅠ 얼른 나았으면 좋겠다.. 아픈건 너무 힘들자나ㅠㅠ). 이번 미션은 저번 미션에 비해 정말 공부량이 부족했기 때문에, 제대로 대답할 수 있는 질문이 별로 없을 것 같아서 걱정했는데..! 의외로 대답 잘했다 킥킥. 말을 막힘없이 술술 똑부러지게 한다고 칭찬받았다ㅎㅎㅎ 고마워요 😋
- 결론만 말하자면, 레벨2 두번째 미션 기간은 좀 아쉽다! 하지만 매우 큰 이벤트였던 테코톡을 큰 문제없이 마무리 했기 때문에! 다행이라고 생각! 이제는 정말 순수하게 미션 키워드 공부에만 집중할 수 있을 것 같다! 다음 미션 아자뵤👊👊👊👊👊
- 아 그리고 chatgpt를 요새 아주 잘 쓰고 있다! 사실 chatgpt를 통한 학습에 좀 회의적이었는데, (물론 100%신뢰할 수는 없겠지만) 빠르게 특정 지식에 대한 개괄적인 정보를 제공한다던가, 특정 문제 상황에서의 보편적인 해결방법을 추천받는다던가, 영어로 작성된 글의 요약 번역본을 얻는다던가(stackoverflow 링크 넣었더니 정말 일목요연하게 정리해줘서 깜짝 놀랐다..) 등등 매우 유용하더라..! 나도 이제 gpt쌤을 옆구리에 꽉끼고 마구마구 똑똑해져야겠다 우하하!!!
