[구름톤 트레이닝 풀스택 1기] 24~27주차 회고 - 마지막 프로젝트 결과 발표, 우수 플레이어 선정

들어가기 전에

매주 작성해오던 회고록을 이번 달에는 그렇게 하지 못했다.

나 자신에게, 정말 바빴음에도 불구하고 "이거 때문에 바빴으니까" 라는 말을 하는 게
방어기제로 밖에 안보인다.

쉬는 시간을 줄이거나 잠을 줄이면 할 수 있는 일인데..

계획 했던 일을 하지 못할 때마다 나약하구나 싶다..

2023년 11월 28일, 어제 구름톤 트레이닝 풀스택 1기 과정을 수료했다.

먼저 파이널 프로젝트인 운동일지 및 루틴 추천 커뮤니티 서비스, 근근근
결과 발표에 대해서 남겨보려고 한다.

운동일지 및 루틴 추천 커뮤니티 서비스 - 발표

풀스택 과정 뿐만 아니라 정보보호 과정과 함께 발표가 진행됐으며
발표는 다른 회차, 과정분들이 볼 수 있도록 생중계 되었다.
그래서 좀 많이 떨렸다..

이전 발표에서 팀의 개발 프로세스와 시퀀스 다이어그램을 통해
기능 동작 흐름을 자세하게 발표를 했었다.

이번엔 기술 혹은 코드 구조를 왜, 어떻게 사용했는지에 대해
중점을 둬서 발표를 구성해봤다.

아래는 발표 내용 일부이다.

수행 절차

API 문서

기획 기간이 포함된, 5주 동안
총 74개의 API 를 구현했다.
매번 그랬듯 개발에 돌입하기 이전에 필요한 API 목록들을 정리했다.

그리고 상세 보기에 Method, 간단할 설명, 관련 페이지,
담당자, 완료 여부 등을 작성해서 관리했다.

기능 개발 팀 스프린트

지난 Web IDE 프로젝트에서 사용했던 프로세스와 동일한 프로세스이다.

매 프로젝트 마다 새로운 것을 시도해보려고 했는데
이번엔 그러지 못했다.

안정적 스프린트이긴 했으나 그래도 분석해보면 개선할게 분명히 있었을 테데
회고해보니 이 부분에선 좀 아쉽다.

기능

gif 파일로 바꿀 예정

로그인 및 회원가입

루틴 목록 보기

추천 알고리즘

추천 루틴의 서버 아키텍처이다.
추천 루틴은 스프링 프레임워크 기반의 API 외에도
파이썬 기반의 레디스 데이터 처리 로직으로 구성되어 있다.

추천 시스템의 특성상 많은 데이터를 조회하고 선별해야 하는 작업이 필요하기 때문에
빠른 성능을 가진 레디스를 통해 데이터를 처리하고,
전문화된 라이브러리와 도구를 포함하고 있는 파이썬을 사용해
효과적으로 기능을 구현할 수 있었다.

추천 알고리즘에서 유클리디안 거리 유사도 방식을 사용했다.

유클리디안 거리 유사도란 좌표의 두 점 사이의 거리를 통해 유사도를 측정하는 방식으로,
골격근량, 체지방률, 체중, 기초대사량을 통해 좌표를 설정했다.

유클리디안 유사도 방식으로 사용자와 유사한 인바디를 가진 사용자들을 조회하고,
유사한 사용자들의 다음 측정한 인바디의 결과에서 성장했다면
그 사용자가 사용하고 있는 루틴을 반환한다.
성장 유무는 인바디 점수의 벡터를 통해 판단했다.

유저가 추천 루틴 버튼을 클릭하게 되면
스프링 서버의 추천 루틴 조회 API로 요청합니다.
그리고 스프링 서버는 레디스에 메세지를 발행하게 되는데,
파이썬은 이 메세지를 수신하고 메세지에 맞는 로직을 실행하게 된다.

추천 알고리즘을 통해 결과 값을 생성한 뒤에는
다시 레디스를 통해 메세지를 발행한다.

스프링 서버는 결과를 받기 위해 대기하다가 메세지를 받게 되면
반환된 값을 통해 루틴을 조회하여 프론트에 반환하게 된다.
UUID를 통해 요청한 작업의 메세지인지 판별을 진행하고
렌더링을 통해 유저에게 결과를 보여줍니다.

무한 스크롤

루틴 목록을 가져올 때 성능 측면을 고려해서
Intersection Observer를 이용한 무한 스크롤을 구현했다.

스크롤 이벤트로 무한스크롤을 구현하게 된다면
스크롤이 발생할때 마다 콜백함수가 실행되기 때문에
성능적으로 불리하다.

Intersection Observer 방식은
스크롤 이벤트와 달리 특정 컴포넌트 요소가
화면에 보일때만 콜백 함수가 실행되기 때문에 성능을 향상 시킬 수 있다.

루틴 상세보기

루틴 작성하기

복잡한 상태 구조 제어

루틴은 트리 구조로 복잡한 구조를 가지고 있다.

일반적으로는 이 데이터를 조작하기 위해서
setState의 콜백 함수 로직를 모든 파일에서 매번 구현해야 한다.

그래서 상태 조작 로직 일관화와
개발 시간 단축을 위해서
useReducer를 사용한 커스텀 훅을 만들었다.

useReducer를 사용하면 setter 함수를 모듈화할 수 있기 때문에
가독성을 높일 수 있다.

이렇게 라이브러리화 함으로써 다른 개발자는 Setter 의 내부 로직을 몰라도 되며
데이터 조작에 필요한 피연산자만 알면 되게 해서 개발 효율성을 높였다.

알림

운동 일지 목록 보기

운동 일지 상세 보기

운동 계획 작성 시작

운동 계획 시작 - 타이머

운동 일지 작성하기

마이 페이지 - 보관함

마이 페이지 - 인바디

마이 페이지 - 프로필 편집

관리자 페이지 - 트레이너 승인

Pagenation

페이지네이션을 사용하면 데이터를 분할해서 받아올 수 있기 때문에
데이터 베이스 조회 및 DOM 생성 시 성능을 향상 시킬 수 있었다.

무한스크롤을 사용해도 같은 효과를 볼 수 있긴하나
페이지네이션을 사용하면 Ramdom Access가
가능해져서 관리자가 특정 정보를 빠르게
찾을 수 있기 때문에 페이지네이션을 채택하였다.

다른 팀 발표의 피드백 내용을 들으면서 알게 된 사실인데
페이지네이션 특정 부분의 데이터를 가져올 때,
_DB 테이블을 보면서 그 부분을 찾아야하기 때문에
성능적 이슈가 있다고 한다.

이 부분을 개선해볼 필요가 있을 것 같다.

유저 찾기

onChange - Debounce

input - Uncontrolled Component

근근근을 사용하고 있는 카카오톡 친구

채팅

코드 품질

FE - 디자인 시스템 구축

과거 프로젝트에서 R&R을 할때 페이지별로 역할을 나눴다.

그래서 배경색, 테두리 부분에서 비슷한 디자인의 컴포넌트를
매번 처음부터 다시 제작해야했다.

이러한 문제로 패딩 같은
디테일적인 css 차이가 발생했다.

이러한 점을 개선하기 위해서 재사용가능한 컴포넌트를 고도해서
디자인도 바꿀수 있도록 디자인 시스템을 구축했다.

결과적으로 개발시간을 단축시킬 수 있었고
유지보수성 및 디자인 일관성을 높일 수 있었다.

다른 팀에서는 스토리북을 사용한 디자인 시스템을 구축했다.
까먹지 말고 다음번에 사용해보자

FE - useAxios(Axios Instance)

JWT 토큰 방식을 이용한 로그인 기능이여서
API 요청 시 AccessToken을 반드시 함께 넘겨주어야 한다.

Axios 라이브러리를 직접적으로 사용하면
모든 요청 시 header를 세팅해줘야해서 코드 중복이 생기는 문제점이 있다.

Axios Instance를 커스텀 훅으로 구축해서
매번 header를 설정하지 않아도 되도록 했다.

응답 인터셉터에서는
서버로 부터 AccessToken이 만료되었다는 응답을 받은 경우
AccessToken을 재발급 받은 후 원본 요청을 다시 보내는 로직과

RefreshToken이 만료되었다는 응답을 받은 경우
로그인 페이지로 리다이렉트하는 로직을 구현했다.

이 방식을 사용함으로써,
매번 header 설정 로직과 토큰 만료 시 에러 처리 하는 코드의 중복을 줄일 수 있었다.

BE - HelperClass

왼쪽에 두 이미지를 보시면 여러 서비스에서 같은 조회 로직이
반복적으로 나타난다.

중복 코드를 제거하기 위해 서비스간 참조를 사용한다면,
순환참조의 가능성이 생긴다.

이를 해결하기 위해 헬퍼클래스를 만들어 조회 로직을 중앙화 시켰다.

이에 따라 코드의 재사용성, 유지보수성, 가독성이 향상되며, 단위테스트가 용이해졌다.
또한 순환참조 위험을 줄일 수 있었다.

발표 제한시간이 15분이었는데
전날 새벽까지 대본 수정을 했으나 분량 조절에 실패해서 여기까지하고 발표가 끊겼다..

그래서 이 뒷 내용은 발표하지 못했다.

우리 팀원 중 한 분이 정기 멘토링 시간 이외에도 찾아가서 멘토링을 받고 오셨었다.

말렸는데 말릴 수 없었다.. 그는 굉장한 사람이었기 때문에..

근데 이 덕분에 살았다...ㅋㅋㅋ

발표가 끝나고 평가자님께서 하시는 말씀이

이 팀은 정기 멘토링 시간 이외에도 찾아와서
뭐 다 알기 때문에 어차피 뒷 내용은 안 궁금합니다.

안도감과 함께 실소가 터져나왔었다 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

그리고 다른 팀 발표 질문 시간과 다르게 공격적인 질문이 들어오지 않았다.

많은 고민을 한 흔적인 보이고 멘토링을 통해서도 이미 알고 있었다라는 평을 들었다.

새로운 발표 전략이 잘 통했던 것 같다.

BE - Exception 전략

우수 프로젝트 선정

팀원 중 한 분이 장문의 톡을 남겨주셨는데 보고 좀 울컥했다..ㅎ

옹기종기 여러분들 고맙고 감사했습니다..

우수 플레이어 선정

[구름톤 트레이닝 풀스택 1기] 지원 그리고 합격 내용 중 일부이다.

이 시리즈의 첫 글이자 각오글이었는데ㅠㅠ
이 글 다 쓰고 성지 순례하러 가야겠다..

추가적으로 구름 인턴 지원 서류 면제권을 받게 되어 바로 면접을 보게 되었다.
잘 준비해서 좋은 결과로 이어질 수 있게 최선을 다 할 예정이다.