플레이데이터 부트캠프 데이터 엔지니어링 트랙 25주차 (11.20~11.24)

안인균·2023년 11월 26일

CSS Fragmentation Spring boot aws aws ec2 back end docker html thymleaf 뮤지컬 배포 백엔드 파이널 프로젝트 플레이데이터 회고

플레이데이터 부트캠프 회고

목록 보기

24/26

25주차가 되었습니다. 곧 학습 과정도 끝나며 이후에 무엇을 할 지가 고민인 시기입니다.
저는 요즘 취업 준비를 하면서 이력서도 업데이트도 하고 깃허브도 꾸미면서 어떤 개발자 혹은 엔지니어가 되고자 하는 지를 생각하는 것 같습니다. 또한 직무에 대한 고민도 하면서 여러 직군과 IT관련 산업을 알아보고 있습니다. 좋은 결과를 기대하며 노력해야할 것 같습니다.

이번 주는 주로 백엔드 개발(Spring boot)과 화면(html, css,..)을 만드는데 집중했습니다. 과정에서 어떤 식으로 화면에 보여줄 것이며 이에 따른 필요한 것에 대해 회의를 진행하면서 개발을 했고, 중간에 오류 혹은 부족한 부분을 얘기하면서 다른 팀원들과 협업을 이어 나갔습니다.

프로젝트 관련 깃허브 주소

✅이번 주 활용 내용✍

사용자 취향 저격 뮤지컬 찾기
- tag list 를 만들어
- 사용자가 총 세 개의 선택한 tag 값을 저장하고
- 해당 tag 값으로 선별된 과거에 공연했던 뮤지컬 리스트를 가져오고
- 그 중 하나를 골라
- 그 와 유사한 "현재 공연 중인 뮤지컬 작품" 추천.
따라서,

부족한 데이터 수를 대비해 태그를 선택할 때마다 작품 리스트 선정 
-> 원하는 작품이 없을 시 
-> 다음 태그 값 선택 후 
-> 다시 작품 리스트 출력하는 구조

로 개발을 진행했습니다.

메인 페이지(시작 페이지)에서 "뮤지컬 처음 봤을 때" 에 해당하는 버튼을 눌렀을 때, 이뤄지는 웹 서비스 페이지들을 개발했습니다.
- 순서대로, 원하는 태그 - 보고 싶어하는 유형의 뮤지컬 테마 11 개 중 하나를 골랐을 때
- 해당되는 과거의 뮤지컬 작품 리스트와 상세 설명을 보여주고,
- 만약 없다면 다음 태그를 골라, 총 3개의 태그를 고를 수 있는 작업을 이어갑니다.
- 해당 과정을 통해 웹 사용자에게 처음 보는 뮤지컬인 만큼 본인이 이러한 작품과 유사한 작품을 고를 수 있도록
- 각각의 태그를 이용해 필터링 해나가는 과정을 진행했고, 만약 없다면 다시 고르거나 이전 단계에서 작품을 고를 수 있도록 합니다.
- 작품을 골랐다면, 해당 작품의 ID 값을 ML 서버로 넘어가
- "고른 작품과 유사성이 가장 높은 순으로 현재 공연 중인 뮤지컬 작품" 을 추천하는 것까지 구현할 수 있었습니다.
  - 아직 해당되는 웹 페이지의 완성도가 낮고, 추천 작품의 ID 값을 log에서 확인하는 과정까지만 진행되었습니다.
  - 이들은 이후에 더 개발하여 완성시킬 예정입니다.
개발 과정이 어느 정도 마무리된 후 2차 임시 배포를 위해 AWS EC2 에 Dockerfile 을 통해 배포까지 완료했습니다.
다른 팀원들이 수정한 화면의 css 값들이 포함된 두개의 branch를 합친 후 새 branch 를 만들어 코드 fragmentation 을 진행했습니다.
- 기존에 여러 html 파일 에서 반복적으로 사용되었던 div class 요소들을 fragment 폴더 안에 common_.html 에 정의한 후
- 이를 해당되는 파일에 적용시켰습니다.
- 또한 변경되는 요소 값들도 정의한 후 th:if 을 통해 한 html 파일에서 T/F 결과에 따라 화면이 바뀔 수 있게 간소화하였습니다.
ML서버로부터 전달 받은 추천 뮤지컬 ID 값을 통해 결과 페이지 작성을 시작했습니다.

추가 개인 학습 내용

✅ 스프링 부트 MVC 패턴 이미지

MVC 패턴에서 Client <-> Controller 의 데이터 주고 받는 관계에서 DTO 객체가 사용되어야 합니다.
✅이미지 에서 확인할 수 있듯이 이는 Domain 과 DTO를 분리하는 과정이라고 볼 수 있습니다.
이것은 "어플리케이에 같은 영향을 미치는 코드끼리 분리한다" 라는 이념에서 발생했으며,
- 데이터를 전달하는 목적의 DTO 와 비즈니스 로직을 담은 Domain 이 서로 겹치게 된다면
- 이것은 "객체지향", "단일책임원칙" 에 위반되어 하나의 코드가 여러 책임을 다 혼잡하게 처리하게 될 수 있는 위험성이 나타날 수 있습니다.
관련 Pull request

이전에는 '이렇게 해야지 된다' 라고만 알고 있는 내용이었습니다. '왜?' 라는 질문은 생략한 채 그대로 받아들여 사용해왔는데 이번 기회에 왜 -> 대답 을 얻고자 공부를 했으며 앞으로 학습하는데 좋은 자세가 될 수 있다고 생각하기 때문에 만족스러웠습니다.

😄어려웠던 점😭

처음 Tag 값들을 어떻게 하나 씩 처리해야하는 지에 대해 고민이 많았습니다. 첫 구상은 화면에서 Tag 11개 값 중 3개를 선택하면 이를 통해 백엔드에서 Query 문을 통해 데이터를 가져올 생각이었지만 Tag1, Tag2, Tag3 로 컬럼이 나뉘어 있어 해당 방안이 불가능 했습니다.
그래도 회의를 통해 각 Tag 값을 순서대로 하나씩 선택하고 이를 Tag1, Tag2, Tag3로 하여 데이터를 가져올 수 있었습니다.
화면에서도 선택한 값에 해당되는 버튼을 사라지게 하여 중복된 값을 선택하는 것도 피할 수 있었습니다.
처음 배포를 진행하려고 할 때, 각 웹 페이지들, resources 파일들을 불러오지 못해 500에러가 나서 배포하는데 어려움을 겪었습니다.
✅이미지 1 과 같이 구현되어 있어 Controller 에서 ✅이미지 2와 같이 불렀는데, 알고 보니 처음에 작성한 '/' 인해 jar 파일에서 해당 path를 찾지 못한 것 이었고, ✅이미지3 과 같이 수정한 후에 다시 도커 테스트를 하니 잘되어 문제를 해결할 수 있었습니다.

application.propertices 파일에서 prefix를 다음과 같이 설정했는데 : spring.thymeleaf.prefix=classpath:/templates/
.jar 로 실행시 Controller 에서 "/basic/past;" 를 // 로 해석하여(//basic/past 와 같이) 경로 문제로 오류가 났던 것 이었습니다. 로컬에서 정상적으로 작동했던 이유는, IDE가 자동으로 처리해줘서 그런거였습니다.

✅ 이미지1