[FitTrip] 캡스톤 프로젝트 / 함께하는 운동 커뮤니티 FitTrip 회고록

 

GIT Repository 주소

https://github.com/hobbytrip/hobbytrip

GitHub - hobbytrip/hobbytrip: 함께하는 운동 커뮤니티 FitTrip repo

---

서론

FitTrip은 2024년도 03월부터 06월까지 총 3~4개월간 진행된 2024 강원대학교 캡스톤 프로젝트 헬스 중심의 커뮤니티 플랫폼 프로젝트입니다.

 

저는 스프링부트를 간단하게 학습만 해보고, 스프링부트를 이용하여 팀원들과 프로젝트를 진행한 것이 처음이었어서 부족한 점이 많았고, 그만큼 배운 점도 많았습니다.

 

앞으로 해당 캡스톤 프로젝트를 진행하면서 생겼던 트러블 슈팅, 기획, 서비스 개발 등에 대한 포스팅을 이어나갈 생각입니다.  회고가 많이 늦었지만, 현재와 비교하여 이때 부족했던 점에 대해서 다시한번 학습하는 계기가 될 것이라고 생각합니다. 그리고 프로젝트를 진행하면 제때 회고와 포스팅을 작성하지 않음에 반성중입니다.................

 

---

 

FitTrip 의 탄생 배경

기존의 아이디어 방안

https://cyclic-concrete-369.notion.site/3608e5f044784973961ea032b93b5d3a?pvs=73

캡스톤 디자인 아이디어 | Notion

 

저는 편입생으로서 전적 대학교에서 캡스톤 프로젝트를 진행한 경험이 있기 때문에 기획을 할 때 "차별성" 을 가장 중요하게 생각했습니다. 위에 사이트는 당시 제가 기획했던 아이디어 입니다.

 

아이디어를 구상하던 중에 팀원분께서 캡스톤 프로젝트가 거의 3개월안에 배포까지 끝내야 하는 상황이기에 기획을 확 줄이자는 얘기를 제시하셨습니다. 그러던 중 디스코드 기능을 클론하여서 클론 프로젝트를 진행해보자고 제안하셨고, 다른 팀원분들도 기획이 오래 걸릴 것이라고 생각하여 디스코드 기능을 클론하기로 했습니다.

 

하지만 역시나 "차별성"을 중요시하는 캡스톤 프로젝트이기에 단순하게 디스코드를 클론한다는 얘기를 했을 때, 교수님에게 반려당했습니다.

 

 

채택된 아이디어 방안

그렇게 다시 한번 아이디어를 고안하게 되면서 디스코드의 기능을 활용한 저의 아이디어 2가지가 채택되었습니다.

당시 스크럼 회의때 제시했던 아이디어는 아래 링크 내용과 같습니다.

https://cyclic-concrete-369.notion.site/3-20-86e5aa846c1e43d495830963b4ea59c0

3월 20일 스크럼 | Notion

 

차별성을 위해서 기존의 플랫폼을 찾다가 취미 관련한 플랫폼은 존재하였지만, 헬스 관련 커뮤니티가 현저히 적다는 것을 알게 되었습니다.

 

주변의 헬스를 하고 있는 지인들에게 물어보았을 때도 유튜브와 같은 플랫폼이나 헬스 용품을 사는 곳에서 커뮤니티가 이루어진다는 것을 깨달았습니다.

 

디스코드의 기능을 클론하면서 포럼기능, 화상통화, 음성통화, 커뮤니티 등 다양한 기능을 헬스 커뮤니티에도 충분히 접목 시킬 수 있다고 생각하였고, 저희는 헬스인들을 위한 온라인 커뮤니티를 아이디어로 채택하게 되었습니다.

 

---

프로젝트 구성

FitTrip은 앞서 얘기한 것처럼 디스코드 기능을 가져온 헬스인들을 위한 운동 커뮤니티입니다.

 

MSA 아키텍처

저희는 MSA 구조를 아키텍처 구조로 채택하였습니다.

MSA는 대규모 서비스에 어울리는 아키텍처 구조이지만, 서버를 담당하시는 팀원분께서 MSA를 한번 해보고 싶다하셔서 팀원분들의 동의하에 MSA 구조를 아키텍처 구조로 채택하였습니다.

 

MSA 아키텍처에 대해서 잘 알지도 못하였고, 처음 접하는 기술이었는 데 해당 아키텍처를 사용하게 되면서 Kafka 이벤트 브로커, Nginx, 도커 등 처음 접해보는 기술들을 학습할 수 있는 기회가 되어서 좋았습니다. 

 

서비스 구성

서비스는 크게 6가지로 나뉘어집니다.

• 유저 서비스
• 커뮤니티 서비스
• 알림 서비스
• 채팅 서비스
• 상태관리 서비스
• 시그널링 서비스

전체 아키텍처는 아래와 같습니다.

저는 해당 서비스에서 유저 서비스와 알림 서비스를 맡게 되었습니다.

 

기술 스택

제가 사용한 기술 스택입니다.

모든 기술에 대해서 숙지가 제대로 되어있지 않았기 때문에 이번 프로젝트를 통해서 학습한 기술이라고 생각해주시면 될 것 같습니다.

 

Spring Framework

• Springboot
• Spring Data JPA
• Spring OpenFeign
• Spring Kafka

DB

• MariaDB
• Redis

Infra

• Kafka
• Docker
• Docker-Compose

CI/CD

• Git

Object Storage

• Amazon S3

---

API 명세서

아래는 API 명세서 Git Wiki 주소입니다. 아래 사이트에서 자세하게 확인할 수 있습니다.

https://github.com/hobbytrip/hobbytrip/wiki/API-%EB%AA%85%EC%84%B8%EC%84%9C

API 명세서

 

유저서비스 명세서

 

알림 서비스 명세서

 

---

 Git Branch 전략 

브랜치	역할	규칙
main	운영 서버 배포	운영 서버에 배포되는 branch
develop	개발 서버 배포	개발 서버에 배포되는 branch
dev	신규 기능 개발	ISSUE별 기능 단위로 생성되는 branch

 

이미지 크기가 커서 해당 브랜치 전략 주소를 올려두겠습니다.

https://github.com/hobbytrip/hobbytrip/wiki/Git-Branch-%EC%A0%84%EB%9E%B5

Git Branch 전략

 

---

😊 좋았던 점

 

프로젝트를 들어가기 앞서 코드 컨벤션이나 Git 컨벤션, 전체 아키텍처 등 팀원들과 많은 고민을 통해서 채택하는 과정이 있었습니다. 이렇게 체계적으로 프로젝트를 진행한 경험이 처음이었기에 프로젝트 초반의 기획과 팀원들과의 문화가 얼마나 중요한 지 깨닫게 되어서 좋았습니다.

 

✨매주 정기회의 및 스크럼회의

저희 팀은 많지 않은 시간 내에 각자 학기 중에 프로젝트를 완성해야했기 때문에 주기적으로 소통을 하는 시간이 중요하다고 생각했습니다. 정기회의에서 한주간 진행할 개발 내용을 정리하여 공유하고, 스크럼 회의에서 해당 주차에 진행하는 개발에 어려운 점이나 소통해야 할 부분에 대해서 주기적으로 공유하였습니다. 서로의 개발 현황을 공유하는 시간을 통해서 필요한 개발만 진행하게 되고, 빠르게 바꿔야할 부분은 서로 맞춰가면서 가장 최적화 된 방식을 채택하는 등 팀원들과의 교류를 통해서 최적화한 개발을 진행해나간 것이 좋았습니다.

 

✨GIT PR 및 ISSUE 관리 

Git 을 다양하게 활용하고 싶었습니다. PR을 진행한 적은 있지만, Issue를 관리하는 것은 처음이였기에, 각자 구현할 기능 단위로 Issue를 관리하고 해당 이슈를 함께 PR을 통해서 dev에 merge하는 과정에서 굉장히 편리하고, 체계적이라는 생각을 했습니다. 또한, Issue를 기능 단위로 관리하면서 개발을 진행하면서 놓치는 부분들을 한눈에 볼 수 있음이 좋았습니다. Git에 대한 이해도가 높아졌고, Git을 더 잘 활용할 수 있게 되었습니다.

 

✨OpenFeign & Kafka & S3 Storage 

이번 프로젝트에서 다양한 기술 스택을 사용하면서 얻어간 것이 많았습니다.  OpenFeign을 사용해 인터페이스와 어노테이션 기반으로 HTTP 클라이언트와 통신하면서 간편하게 통신할 수 있다는 점을 체감했고, Kafka 이벤트 브로커를 통해 비동기 데이터를 하는 방식을 경험했습니다. 또한, S3 Storage에 데이터를 안전하게 저장하고 관리하는 방법을 익혔습니다. 무엇보다 앞선 기술을 효과적으로 사용하는 방법에 대한 학습도가 크게 향상되었습니다.

 

😂 아쉬웠던 점 

✨코드의 일관성

Spring Boot 프로젝트가 처음이다 보니, 기능 구현에 집중하면서 코드 스타일과 일관성 유지를 다소 소홀히 했던 부분이 아쉽습니다. 다양한 레퍼런스를 참고하며 여러 방식으로 코드를 작성하게 되었고, 이로 인해 코드의 일관성이 떨어지거나 코드 컨벤션을 일관되게 지키지 못한 부분도 있었습니다. 다음 프로젝트에서는 코드 컨벤션에 대해 더 깊이 이해하고, 코드의 일관성을 유지하며 협업할 수 있도록 개선하고 싶습니다.

 

✨테스트코드 작성

테스트 코드의 중요성을 알고 있음에도, 이번 프로젝트에서 빠듯한 일정과 경험 부족으로 인해 테스트 코드를 작성하지 못한 점이 아쉽습니다. 특히 비즈니스 로직을 검증하거나 코드 변경 시 발생할 수 있는 오류를 사전에 잡아낼 수 없었고, OpenFeign 에서도 테스트 도구를 제공하지 않음으로서, 테스트를 진행할 때 항상 팀원들과 만나서 해야하는 것이 많이 불편했던 거 같습니다. 다음 프로젝트에서는 테스트 코드를 작성하는 법을 먼저 학습하고, TDD 개발방법론을 적용하고 싶습니다.

 

✨ DIP(Dependency Inversion Principle) , OCP(Open-Closed Principle) 법칙 위배 

이번 프로젝트에서 서비스 레이어에 인터페이스를 두지 않고, 직접 구현 클래스를 사용했습니다. 이로 인해 DIP(Dependency Inversion Principle, 의존성 역전 원칙)과 OCP(Open-Closed Principle, 개방-폐쇄 원칙)을 준수하지 못한 점에서 아쉬움이 남습니다. 

 

• DIP 위배 서비스 구현에 인터페이스가 없으면 클라이언트 코드가 구체적인 구현체에 직접 의존하게 되면서 DIP를 위배하게 되었습니다.
• OCP 위배 인터페이스 없이 서비스를 구현함으로써 기능을 확장할 때 클라이언트가 의존하고 있는 기존 클래스를 수정해야 하는 상황이 발생했습니다. 이러한 방식은 코드의 유연성을 떨어뜨리고, OCP를 위배하게 되었습니다.

---

마치며

오랜만에 FitTrip의 코드를 보고, 내용을 정리하면서 부족한 점들을 다시한번 복기하는 시간이 된 것 같습니다. 

해당 프로젝트의 회고가 많이 늦었지만, FitTrip과 관련된 포스팅을 주기적으로 올리려고 합니다. 앞으로 회고와 포스팅은 제때 적을 수 있도록 습관을 기르겠습니다 !