프로젝트 소개
주제
자신의 목표, 일정을 친구들과 공유하고 참여할 수 있는 서비스
목적
해야할 일, 목표와 같은 목적이 있는 일정을 공유하여 동기 부여를 하며 사람들과 체계적으로 목표를 관리하기 위한 목적을 가진 서비스입니다.
🚀 Tech Stack
- Back-End
- Java17
- Spring
- Boot
- Security
- JPA
- Web
- Mysql
- OAuth2
- SSE - Front-End
- Thymeleaf
- JQuery
- Javascript
- Bootstrap
🔥 Infra
- Git
- Actions - Docker
- AWS
- EC2
- S3
- Code Deploy - Slack
백엔드 기술 선정의 각각의 이유가 있지만 Java17이 가장 주요하게 와닿은 것 같습니다.
이유는 Java의 경우 8, 11, 17, 21로 변경 사항이 눈에 띄게? 있는 걸로 알고 있는데 그 중 record 형식이 17부터 등장하였습니다. Kotlin의 DataClass에 익숙해져 있고 Java의 최신버전들이 점점 Kotlin을 닮아가는 것 같아 버전 호환까지 고려하여 17로 선택하게 되었습니다.
알림 같은 경우 Firebase, WebSocket 등과 같은 서비스들이 있었으나 Firebase는 앱에 중점적으로 이루어져있다는 느낌을 받았고 WebSocket은 양방향 통신이 알림에 필요가 없다고 판단하여 Polling 방식을 사용하는 SSE를 채택하였습니다.
나머지의 백엔드 부분의 기술스택은 프로젝트 주제에 필요한 기능을 사용하기 위한 설정들로 선정하게 되었습니다.
프론트엔드 같은 경우 가장 입문하기 좋다고 판단한 Thymeleaf, Bootstrap를 사용하였습니다. 하지만 Thymeleaf의 경우 단순하게 데이터를 읽어오는 것에는 편하지만 redirect, post와 같은 기능을 하는 것에 한계와 어려움을 느껴 javascript와 jquery를 사용하였습니다. javascript라는 언어를 처음 사용해도 Thymeleaf 보다 훨씬 편하였고 기술 선정의 중요성을 많이 깨달았습니다.
인프라의 경우 정말 아무것도 모르는 상태에서 기술을 선정하려고 하니 막막하였습니다. 개발을 할 때 어떤 환경을 가져가야 할지 원하는 대로 명세를 하였습니다. 명세한 내용은 특정 branch에 push 명령이 되면 자동으로 배포가 되었으면 좋겠다는 생각을 하였고 생각한 기능을 구현하기 위해 Github Actions, EC2, S3, CodeDeploy라는 것들이 구현하는 과정에서 필요하여 자연스럽게 사용하게 되었습니다.
Slack도 마찬가지로 pull_request, issue와 같은 특정 트리거에 대한 알림을 받고 싶어 사용하게 되었습니다.
기능
어드민 관련 기능
- redash를 사용한 통계 지표 확인
- 악성 유저 차단
- 가입한 회원 명단 확인 가능
로그인 - Spring Security Form Login
- OAuth2 Kakao Login
- 회원 가입
일정 게시판 - 참여중인 일정 목록 조회
- 내가 생성한 일정 목록 조회
- 완료한 일정 목록 조회
- 나와 연관된 전체 일정 목록 조회
- 상세조회
- 일정 참여 인원 조회 및 초대
- 할일 조회 및 생성 ,수정
친구 - 친구 목록 조회
- 친구 추가, 삭제
알림 - 일정 게시판에 초대한 경우 알림 송신 / 초대 받은 인원 알림 수신
- 친구 요청한 유저에게 알림 송신 / 초대 받은 인원 알림 수신
회고
아쉬운 점
디자인
BootStrap를 사용하였지만 전반적인 HTML, CSS, Javascript를 사용해보지 않았고 개발 입문을 앱으로 하여 웹개발과는 많이 다르고 고려사항이 다르다는 사실을 인지 한 경험이었습니다.
알림
SSE방식을 사용하여 백엔드에서 구현했지만 프론트에 대한 지식이 없어 구현하지 못한 것이 아쉬웠습니다.
채팅
Slack처럼 각 일정 게시판에 자유롭게 소통할 수 있는 채팅 기능을 구현하려고 하였으나 시간과 그 밖의 고려사항들이 많이 생겨 구현하지 못한 부분이 많이 아쉬웠습니다.
느낀점
첫 백엔드 프로젝트를 진행하고 첫 팀장을 해본 결과는 처참했다고 생각합니다. 개발에 앞서 설계와 명세에 시간을 많이 투자하고 집중해야 했지만 그러지 못하여 개발 방향이 중간에 길을 잃었다는 느낌을 받았습니다.
기능을 명세한 다음 와이어프레임을 작성한 후 워크플로우를 구체적으로 확인할 수 있게끔 해야 했는데 기획 부분에 있어 처참한 능력을 보여주었고 해당 부분은 팀원들에게 미안했습니다.
배우고 싶은 점
명세
저의 결함과 밑바닥을 보게 되는 프로젝트였고 자아성찰을 많이 하게 되는 계기가 되었습니다. 개발을 진행할 때 명확한 목표를 정하고 작업한 내용을 명세하는 것에 대한 필요성을 많이 느꼈습니다. 명세를 잘하면 개발을 잘한다는 생각을 가지게 되어 많이 배우고 싶습니다.
설계
개발을 진행하면서 설계된 내용이 부실하다보니 한번만 진행하면 되는 작업을 수정 또 수정을 계속 반복하였습니다. 물론 기능이 추가됨에 따라서 수정은 당연한 수순이지만 불필요하게 코드를 수정하는 일이 반복되고 시간이 낭비된다는 느낌을 너무 많이 받았습니다. 원인은 설계라고 생각되며 고려해야 할 사항들을 고려하지 않았기 때문에 무지성 코딩을 했다고 생각이 들었고 개선하고자 하는 의지가 강하게 들었습니다.
요약
한달동안 백엔드 프로젝트를 진행하면서 많은 기능 구현과 경험들을 하며 스스로 인지하지 못했던 개선 사항들을 많이 느끼면서 개발하였다.
