✨ 단잠 / 각기 다른 사람들이 모여 단잠에 들다 ✨
단잠은 대학교 기숙사 메이트 매칭 및 대학 생활 커뮤니티 서비스입니다.
기숙사 메이트 매칭 외에도
사용자의 성향에 맞는
다양한 운동, 산책, 공부 메이트들을
매칭시켜주고
지속적인 모임의 개설과 만남을 위한
교류 시스템을 제공해줍니다.
💭 단잠의 탄생배경
단잠은 다양한 이유로 청년들의 기숙사 선호도가 올라가면서
자연스럽게 발생하는 문제점과 요구사항에 대해 해소하고자 고안된 서비스 입니다.
발생하는 문제점
- 입주 후에서야 알 수 있는 룸메이트의 성향과 정보로 인한 트러블 발생
- 서로 상이한 생활 습관
- 기숙사 생활 전반의 편의시설, 택배, 공지부족 등의 불편함
- 기숙사 모임 시에 일정 조율의 어려움
- 기숙사 거주 중 다양한 모임을 참여하고, 지속하기 어려움
이러한 문제점들을 해결하고자 단잠 이 탄생하였습니다.
💭 들어가기에 앞서
2024.03. ~ ing
해당 프로젝트는 3월부터 기획을 시작하였고, 저는 기획과 디자인, 프로젝트 셋팅이 끝난 7월쯤에 합류하게 되었습니다. 개발이 어느정도 진행이 되고있던 시점에 합류하였기 때문에 팀과 팀 문화에 융화되려고 노력하였고, 코드를 분석하면서 기존의 형식보다 더 좋은 형식은 없는 지 팀원분들과 교류하면서 생각을 많이 하고, 여기저기 조언도 많이 구했던 거 같습니다. 그리고 이러한 시간으로 서로간의 대화가 많아지다보니 자연스럽게 개발팀에 융화가 된 것 같아서 좋았습니다.
단잠 팀은 문서작업이 잘 되어있어서, 뒤늦게 합류를 했지만 큰 어려움 없이 프로젝트의 이해가 잘 되었습니다.
이러한 점에서 문서화가 정말 중요하다고 느꼈습니다. 그리고 디자인팀과 협업을 해본 것이 처음이었어서, 정기회의때마다 피그마에서 기능별로 자잘하게 궁금한 점들이 많았었는 데 디자인팀분들께서 친절하게 설명을 해주셔서 정말 감사했습니다. 저 또한 디자인팀분들에게 직관적으로 얘기하려고 노력했고, 개발팀, 디자인팀 매주 한번씩 다같이 얘기하는 시간이 서로에게 좋은 시너지가 되었다고 생각합니다.
프로젝트는 아직 진행중이며, 앱 심사단계이지만 Fix 해야하는 부분이나 리팩토링을 해야하는 부분 등 아직까지 갈길이 먼 것 같습니다. 더 늦기전에 회고를 진행하고 싶어서 이렇게 중간 점검 차로 회고를 진행하게 되었습니다.
앞으로 단잠에 관한 포스팅은 주기적으로 올릴 것 같습니다 !
💭프로젝트 구성
디렉토리 구조
가장 먼저 디렉토리 구조입니다.
직관적으로 볼 수 있는 도메인형 구조를 사용하였습니다.
2024년도 11월 14일 기준입니다.
src
├───main
│ ├───java
│ │ └───com
│ │ └───example
│ │ └───danjamserver
│ │ ├───admin
│ │ │ ├───controller
│ │ │ ├───domain
│ │ │ ├───dto
│ │ │ ├───repository
│ │ │ ├───service
│ │ │ └───superuser
│ │ ├───chat
│ │ │ ├───controller
│ │ │ ├───domain
│ │ │ ├───dto
│ │ │ │ ├───requests
│ │ │ │ └───responses
│ │ │ ├───repository
│ │ │ └───service
│ │ ├───chatroom
│ │ │ ├───controller
│ │ │ ├───domain
│ │ │ ├───dto
│ │ │ │ ├───requests
│ │ │ │ └───responses
│ │ │ ├───listener
│ │ │ ├───repository
│ │ │ └───service
│ │ ├───common
│ │ │ ├───config
│ │ │ ├───controller
│ │ │ ├───domain
│ │ │ ├───dto
│ │ │ ├───interceptor
│ │ │ │ └───dto
│ │ │ ├───repository
│ │ │ └───service
│ │ ├───dataInitializer
│ │ ├───foodMate
│ │ │ ├───controller
│ │ │ ├───domain
│ │ │ ├───dto
│ │ │ ├───enums
│ │ │ ├───repository
│ │ │ └───service
│ │ ├───home
│ │ │ ├───controller
│ │ │ ├───domain
│ │ │ ├───dto
│ │ │ ├───repository
│ │ │ └───service
│ │ ├───mate
│ │ │ ├───controller
│ │ │ ├───domain
│ │ │ ├───dto
│ │ │ ├───repository
│ │ │ ├───service
│ │ │ └───util
│ │ ├───notice
│ │ │ ├───config
│ │ │ ├───controller
│ │ │ ├───domain
│ │ │ ├───dto
│ │ │ ├───repository
│ │ │ └───service
│ │ │ └───impl
│ │ ├───roomMate
│ │ │ ├───controller
│ │ │ ├───domain
│ │ │ ├───dto
│ │ │ ├───enums
│ │ │ ├───repository
│ │ │ └───service
│ │ ├───springSecurity
│ │ │ ├───config
│ │ │ ├───controller
│ │ │ ├───domain
│ │ │ ├───dto
│ │ │ ├───jwt
│ │ │ ├───repository
│ │ │ ├───role
│ │ │ └───service
│ │ ├───studyMate
│ │ │ ├───controller
│ │ │ ├───domain
│ │ │ ├───dto
│ │ │ ├───enums
│ │ │ ├───repository
│ │ │ └───service
│ │ ├───user
│ │ │ ├───controller
│ │ │ ├───domain
│ │ │ ├───dto
│ │ │ ├───enums
│ │ │ ├───repository
│ │ │ └───service
│ │ ├───util
│ │ │ ├───entity
│ │ │ ├───exception
│ │ │ └───response
│ │ ├───walkMate
│ │ │ ├───controller
│ │ │ ├───domain
│ │ │ ├───dto
│ │ │ ├───enums
│ │ │ ├───repository
│ │ │ └───service
│ │ └───workoutMate
│ │ ├───controller
│ │ ├───domain
│ │ ├───dto
│ │ ├───enums
│ │ ├───repository
│ │ └───service
│ └───resources
│ ├───firebase
│ ├───static
│ └───templates
└──────────────────────────────────────────
기술스택
제가 사용한 기슬들 위주로 적었습니다. 스택이라기보단 학습을 진행한 기술들이라고 생각하시면 될 것 같습니다.
Spring Framework
- Springboot
- Spring Data JPA
- Spring RestTemplate
DB
- MariaDB
- Redis
- phpMyAdmin
Infra
- Docker
- Docker-Compose
- Rabbitmq
CI/CD
- Jenkins
Object Storage
- Minio
API Documentation
- Swagger
💭 단잠 API 문서
단잠 API 작성 규칙입니다.
규칙
모든 API 요청을 전송하는 기본 URL은 ** (해당 부분은 아직 출시전 사이트 주소이기때문에 주석처리 해두었습니다) 입니다.
모든 API 요청에는 HTTPS가 필요합니다.
요청과 응답 본문은 JSON으로 인코딩됩니다.
JSON
기본적으로 카멜케이스를 따릅니다.
기본적인 api 응답은 하단의 형식을 따릅니다.(login, logout등 몇몇의 api제외)
{
"code" : 40002 ex) 특정 코드 전송. 40002 : 입력값이 없는 항목이 있습니다.
"message": "처리 메세지를 보내줍니다." ex) 성공적으로 처리되었습니다.,
"data": "실제 응답 데이터를 보내줍니다." 응답데이터가 필요하지 않는 경우 message만을 전달합니다.
}
URL 명명
RESTful한 API 설계를 위해 불필요한 동사나 행위는 넣지 않습니다.
리소스나 도메인을 명확하게 나타내고, HTTP 메서드(GET, POST, PUT, DELETE)를 통해서 행위를 표현합니다.
예시
[POST] https/단잠.site/api/도메인/{id}
[DELETE] https://단잠.site/api/도메인/{id}
다음으로 프로젝트를 진행하면서 좋았고, 아쉬웠던 점들에 대해서 회고를 진행하겠습니다.
😽 좋았던 점
✔️ 빠른 피드백 수용
매주 월요일마다 정기 회의를 진행하였고, 개발자팀끼리의 단톡방을 통해서 서로간의 문제가 생기면 빠르게 피드백이 수용되었다는 점이 좋았습니다. 바뀐 것들이 있다면 ISSUE를 열어두어 팀원들이 볼 수 있도록 공유하였고, 팀원 분의 서버를 사용하면서 실시간으로 셋팅 정보들을 문서화 해주셔서 좋았습니다. 문서화에 대해 다시금 중요성을 느끼게 된 것 같고, 빠른 피드백을 수용해주시면서 언젠가는 해결했어야 할 문제점들을 초기에 잡을 수 있었던 것 같습니다.
✔️ 함께 나아가는 팀 문화
저희 팀 모두 스프링에 익숙하다고는 할 수 없을 것 같습니다. 각자 개인이 부족하다는 것을 팀원이 모두 인식하고 있었고, 이로인해 서로간의 소통이 굉장히 많았던 것 같습니다. 팀원 한명이 해결 하지 못한 문제에 대해서 공유를 해주면 다같이 해당 문제를 해결하기 위해서 이것저것 찾아보며, 모두가 함께 나아갈 수 있었던 것 같습니다. 물론 이러한 과정이 시간이 오래 걸리는 과정이었을 수도 있겠지만, 문제를 해결해나가는 방식을 찾아가는 시간들이 저에게 있어서는 정말 좋은 학습시간이라고 생각되었던 것 같습니다. 그리고 각자가 가져오는 해결 방식이 다르면서 가장 좋은 방식을 찾기위해 서로 힘써가는 시간으로 인해 하나의 문제에 대해서도 여러 방면으로 생각하는 사고력을 기를 수 있었습니다.
✔️ 클라이언트와의 소통
저희 팀은 백엔드 개발자가 3명 앱 개발자 분이 1명이었습니다. 앱 개발자 분도 백엔드를 할 줄 아시는 분이였기 때문에 백엔드 파트에 최대한 부담을 주지 않으려고 하셨습니다. 앱과의 통신은 웹이랑은 상이한 부분들이 있어서 제가 놓치는 것들이 많았는 데, 그러한 것들을 바로바로 알려주셔서 제가 직접 찾아야하는 시간이 확연하게 줄었던 것이 정말 좋았습니다. 서버에 LOG를 남기는 것에 대해서도 피드백해주시고, 단순히 백엔드만 개발하는 것이 아닌 여러방면으로 생각하면서 개발을 진행해야한다는 것을 배웠던 것 같습니다.
😿 아쉬웠던 점
✔️ 공통응답 통일성
앱을 담당하시던 분들이 한번 바뀌게 되면서 클라이언트 단에 던져주는 응답 형식이 바뀌었습니다. 이미 구현된 기능들에 대해서 바뀐 응답 형식으로 바로 바꿨어야 했는 데 새로 구현한 기능들만 바뀐 응답 형식을 사용하고, 기존의 기능들은 예전 응답형식을 사용하였습니다. 이로인해 클라이언트 단에서 혼동이 있었습니다. 리팩토링과 기능 수정을 진행하면서 해당 공통 응답을 통일성 있게 수정하려고 합니다. 응답 방식을 바꿨던 시점에 바로 모든 응답 형식을 바꾸지 않아서 클라이언트단에 혼동을 주었던 것이 아쉽습니다.
✔️ 테스트코드 작성
시큐리티를 사용하면서 @WithMockUser를 사용한 시큐리티 테스트 설정을 진행하고, 단위 테스트 코드를 작성하려고 했습니다. 하지만 @WithMockUser가 적용되지 않으면서 시큐리티 테스트 설정에 대한 시간이 생각보다 오래 걸리게 되었고, 그로인해 전체 테스트 코드를 작성하지 못하였습니다. 이번에 앱 심사가 끝나고 리팩토링을 진행하면서 테스트 코드를 작성할 예정이지만, 해당 문제를 저때 해결하지 못한 것이 아쉽습니다.
✔️ Query문의 작성
필터링 부분을 구현하였을 때, 서비스 단에서 데이터를 조회하면서 필터링을 진행하였습니다. 이로인해 여러번 반복하여 데이터를 가져와서 비교해야했고, 더미 데이터가 많아지게 되면서 성능적으로 많은 저하를 보이게 되었습니다.
같은 팀원분께서 앞으로 Query문을 짜서 데이터를 조회하는 것이 좋을 것 같다고 얘기해주셨을 때 아차 싶었습니다. JPQL이나 QueryDsl에 대한 개념을 이때 찾아보면서 알게되었고, 데이터베이스단이 성능적으로도 고민을 가장 많이해야할 파트인데 단순히 JPA 기능에 의존해서 구현을 했다는 것에서 반성을 하는 시간을 가졌던 것 같습니다.
마치며
해당 프로젝트는 앱 출시를 앞두고 있습니다.
개인정보처리지침에 대해서 직접 작성해보고, 서비스를 직접 상용화하기 위해 고려해야할 것들을 조금이나마 알게 되었던 프로젝트 였던 것 같습니다.
아직 리팩토링을 해야할 것이 많고, 기능 테스트와 붙여야할 기능들도 많지만,
현재까지 협업을 진행하면서 배운것이 많아서 중간 점검상 회고를 작성하는 시간을 가지게 되었습니다.
앞으로 있을 포스팅은 그간의 많은 문제점들을 어떻게 해결 하였는 지, 트러블 슈팅을 주로 하여 작성하고자 합니다.
또한, FCM을 웹 단에서는 작동이 되도록 구현하였는 데 막상 앱 단에서 테스트를 진행할 때 작동이 되지 않아서 이에 대한 해결방안을 찾고, 공유하고자 합니다.
앞으로도 단잠 프로젝트를 꾸준히 진행하면서 부족한 점들을 채워나가고 싶습니다.
항상 열심히 도와주는 팀원분들에게 감사하며 포스팅 마치겠습니다.
'개발 > 프로젝트' 카테고리의 다른 글
[단잠] SSE와 RabbitMQ를 이용한 알림 도입기 [2편] (0) | 2024.11.27 |
---|---|
[단잠] 트러블슈팅: SSE(Server-Sent-Events) 첫 연결 이후 바로 Connection closed가 되는 현상 (0) | 2024.11.26 |
[단잠] 알림 도입기 (feat. AMQP, RabbitMQ, SSE) [1편] (4) | 2024.11.19 |
[FitTrip] 우리가 Setter를 지양했던 이유 (8) | 2024.11.12 |
[FitTrip] 캡스톤 프로젝트 / 함께하는 운동 커뮤니티 FitTrip 회고록 (8) | 2024.11.06 |