사용자가 여행을 다니며 자신의 캐릭터와 함께 같이 성장하는 여행 SNS 웹애플리케이션
팀장(본인 웹프론트, 웹백엔드), 팀원1(인공지능), 팀원2(DB)
- 시스템 전체 설계 및 서버 구축(Synology Nas Docker)/배포
- 모든 페이지 화면 개발(FE)
- JWT를 이용한 로그인, 회원가입 기능 구현
- 비짓제주 API로 불러온 관광지들의 주소를 지도 API 위경도 변환 서비스로 변환하여 데이터베이스에 추가.
- 관광지들의 위경도 데이터를 이용하여 지도에 마커로 표시 및 관광지 데이터 출력
- 여행일지 작성 기능 구현
- 사용자 캐릭터 레벨 구현 및 경험치 습득 기능 구현
- 사용자가 올린 이미지로 랜드마크 판별 인증 기능 구현
- 사용자의 위치정보(GPS)를 받아 사용자와 관광지간의 거리를 판별하는 인증 기능 구현
- 좋아요/댓글/목록 기능 구현
- 여행지 검색 기능 구현
백엔드
https://github.com/Hchanghyeon/growing-trip-backend
프론트엔드
https://github.com/Hchanghyeon/growing-trip-frontend
[2022년 구성도]
[2024년 재배포 구성도]
학부시절 많이 부족할 때 개발했던 프로젝트로, 개선해야할 점이 많다고 생각합니다. 아래는 제가 만약 개선하고 리팩토링 한다면 어떠한 부분을 하면 좋을지에 대한 생각을 적어두었습니다.
[문제점]
- 현재 구현된 OFFSET 기반은 해당하는 페이지를 조회하기 위해서, 처음부터 해당하는 페이지까지 조회 후 해당하는 페이지 부분의 범위를 가져오기 때문에 페이지가 커지면 커질 수록 조회하는 속도가 느려짐(full scan)
- 데이터의 잦은 추가와 삭제가 있을 경우, 데이터가 중복되거나 누락이 발생될 수 있음
[개선방안]
- NO OFFSET을 이용하여 현재까지 조회했던 위치를 인자로 받아 해당하는 인자로부터 추가 개수까지만 조회하도록 WHERE 절을 이용해서 개선 -> 이때 Index가 걸려있으면 더 빠른 조회가 가능
[문제점]
- 예외에 대한 처리와 로깅이 제대로 되어있지 않아서, 예외 발생시 어디서 문제가 발생했는지 파악하기 어려울 뿐더러 서비스에 영향이 생길 수 있음
[개선방안]
- 전역 예외 처리를 하기 위한 코드를 작성하고, 예외를 커스텀해서 도메인 별로 예외를 발생시키도록 함
- 각 예외 발생과 주요 로직에 대한 로깅 처리를 통해 장애 대처를 빠르게 할 수 있도록 함
[생각해볼만한 점]
- 랜드마크 리스트는 큐레이팅처럼 운영자가 직접 골라서 선별해놓는 장소인데, 운영자가 바꾸지 않는 이상 항상 동일한 데이터를 반환 함
[개선방안]
- 항상 동일한 데이터가 반환될 경우, 데이터베이스로 나가는 쿼리가 줄어든다면 성능 개선이 될 수 있다고 생각함
- 현재는 모놀리식한 단일 서버이기 때문에 로컬 캐시로도 충분하다고 생각하여, 로컬 캐시에 저장해놓는 방식으로 사용하면 좋을 것 같음
- 하지만 캐시는 항상 메모리를 차지하기 때문에, Evict에 대한 처리도 고려해야 함 -> 별도의 데몬 스케줄링을 만들어서 조회 수가 낮은 것들을 캐시에서 삭제하는 방식으로 처리해도 좋을 듯
[문제점]
- 개발할 당시, 아키텍처에 대한 개념이 부족한 상태에서 구현하다보니 비즈니스 로직이 Controller에 있거나, Service 계층을 Util로 쓴다거나 계층에 알맞지 않은 로직을 수행하고 있음
[개선방안]
- 계층형 아키텍처 도입을 통한, Controller Service Repository 구조를 가져가고, Model에 비즈니스 로직을 수행할 수 있는 것들을 집어넣어서 도메인에 어느정도 역할을 부여하여 균형을 이루게끔 구현
[문제점]
- 현재 API 명세는 RESTFUL 하지 않음
- 예를 들어, URI에 대문자가 적혀있고 자원에 대한 행위를 메서드로 하는 것이 아닌 URI로 하고 있음
[개선방안]
- 자원에 대해 명확하게 URI로 명시하고(대문자X, 복수형으로) 행위에 대한 표현은 URI가 아닌 HTTP 메서드로 표현해야 함
- 응답의 경우 HTTP Status를 고려하여 알맞은 응답을 내려주어야 함
[문제점]
- 테스트 코드 미작성으로 인한 동작에 대한 신뢰성 저하
[개선방안]
- 추후 SpringBoot로 마이그레이션하면서 Junit을 통한 테스트 코드 작성
- 도메인에 대한 테스트와 예외 케이스, 통합 테스트 모두 구현하여 코드에 대한 신뢰성을 높임
[문제점]
- 컴포넌트가 잘게잘게 쪼개지지 않고, 공통적인 역할을 하는 컴포넌트들도 중복되어 만들어진 경우가 있음
[개선방안]
- 공통으로 사용되는 컴포넌트를 선별하여 별도로 분리하고, 책임이 너무 많은 컴포넌트들을 쪼개어 조금 더 유연하게 사용할 수 있도록 함
현재는 Node.js를 하고 있지 않기 때문에 리팩토링보다 주 기술인 SpringBoot로의 마이그레이션이 필요할 것 같습니다. 이때는 많이 부족한 상태에서 구현하다보니 부족한 점들이 많은데, 그래도 하나의 시스템을 구성해서 배포하기 위해 많은 노력을 해보아서 좋았던 프로젝트로 기억이 남습니다. 추후 기회가 된다면 SpringBoot로 마이그레이션해서 실 서비스도 해보고 싶은 마음이 있습니다.