발표 관련 정리

발표 전체 구조

참고: 프로젝트 발표에 들어가야 하는 내용 공지

• 필수 항목
• 프로젝트 개요 ✅
• 협업: 프로젝트 관리, 업무 분배, Merge 까지의 과정 등
• 기술 스택 ✅
• 서비스 소개 ✅
• 시연 영상(편집X, 실시간)
💡
시연 영상은 미리 찍어둔 영상이든, 최종 프로젝트 발표 영상 녹화 중 발표자가 실시간으로 시연을 진행하든 형식은 상관 없습니다. 여기서 핵심 포인트는 시연에는 편집이 진행되면 안 된다는 것입니다.
• 팀 소개 페이지(각 포지션 및 이름 기입)
• 각자가 담당했던 부분을 발표 혹은 리드미에 반드시 명시해 주세요!

• 선택 항목
• 디자인 시스템
• 시장 조사
• 등등

발표 순서

• 프로젝트 개요 / 서비스 소개
• 필요성
• 강점
• 기능: 한줄 요약(자세한 설명은 시연에서 수행)

• 팀 소개

• 협업 방식

• 백엔드 기술 스택

• 프론트 기술 스택

• 시연 영상 / 서비스 소개

발표 타임라인(목표)

프론트엔드 발표 준비

1. 프론트엔드 기술 스택
1. Recoil, React-router-dom, react-query, emotion, MUI, typescript, event-source-polyfill, React, dayjs
2. 기술 스택에 간단한 설명 추가

2. 프론트엔드 구조
1. 카카오맵, 다음 주소 api 연결 된 구조 그림

3. 프론트 엔드 협업 방식
1. 브랜치 전략
2. 코드 리뷰(한명이 approve 해야 머지 가능)
3. 스크럼
1. 1시 30분 시작 스크럼, 7시 종료 스크럼

4. figma 와이어 프레임
1. 와이어 프레임을 통한 feature list 산출

발표에 들어갈 내용 / 자료

백엔드 발표 준비

발표에 들어갈 내용 / 자료

프로젝트 개요 - 필요성을 중심으로

자전거에 대한 수요가 증가하고 있다.

가벼운 1회성 취미가 아니라 deep한 취미로서의 자전거를 즐기기 위한 모임을 찾기 힘들다.

기존 노후화된 서비스 / 신규 유입이 없는 자전거 라이딩 모임 서비스에 대한 대안이 되고자 한다.

• 자료
• 자전거 수요는 증가 추세임
• 특히 거리두기 해제 이후 자전거 거래액이 매우 증가했습니다.
• https://newsis.com/view/?id=NISX20220726_0001956218&cID=13001&pID=13000
• 지난해 번개장터 자전거 거래액은 전년 대비 82% 증가하며 수직 상승했다. 거리두기 해제 후 거래액도 27.5% 증가했다.
• 특히 전문적 라이딩에 대한 수요도 증가
• 자전거 연관 세부 키워드로는 '픽시 자전거'가 검색량 1위를 차지했다.

서비스 소개 - 기존 서비스에 비해 갖는 강점을 중심으로

• 논의 포인트
• 우리 서비스의 가치를 요약할만한 캐치프라이즈
• 특별히 강조하고 싶은 키워드나 가치가 있는지?
• 발표 뒷 부분에서 시연이 있는데, 여기서 어디까지 서비스에 대한 소개를 진행할 것인지
• 개인적인 의견: 종래 서비스에 비해 갖는 강점 / 핵심 서비스 정도만 사진과 함께 언급

빠르고 간단하게

라이딩 모임을 개설 / 참여할 수 있는

통합된 플랫폼 제공

• 자료
• 기존 커뮤니티에 대한 사진들
• RG와의 비교 스크린샷
 

팀 소개

• 논의 포인트
• 누가 ~ 했다 일일히 읽어 주는 것이 의미가 있을지?
• 간단하게 화면 띄워주고, 협업 방식과 엮어서 설명하는 것은 어떨지?
• 특이사항만 언급하는 게 어떨지? 예시) 백엔드의 경우 도메인 보다는 인프라 중점 담당한 기술 팀장을 선정하였고 …
• 16일에 촬영한 팀 소개 사진을 포함시켜도 괜찮을 듯
• 발표 순서 상 제일 앞으로 빼면 어떨지?
• 각자 역할을 일일히 언급하기 어려우니, 프로젝트 구조 등에서 하나씩 표시해두는건 어떨지?

협업 방식

Zenhub를 이용하여 프론트엔드 / 백엔드의 진행 상황을 일목요연하게 파악하였음 코드리뷰를 통과한 코드만 merge함으로써 Notion을 통해 프로젝트 관련 사항들을 문서화 / 소통 → API 문서(요청/응답 스펙), 유저스토리(비즈니스) Slack을 통해 비동기적으로 소통, 긴급한 사안의 경우 Discord를 이용하여 이슈를 공유하였음 온라인 협업이 기본이지만, 필요할 때마다 오프라인을 통해 빠르게 소통하였음: 브레인 스토밍, 주간 회의 Pigjam을 이용한 브레인 스토밍

• 논의 포인트
• 프론트와 백 협업 방식에 차이가 있음.
• Git
• 같이 다룰 것인지, 따로 다룰 것인지?
• 같이 다룬다면: 시간 절약하지만 각 팀만의 컨벤션은 설명하기 애매
• 따로 다룬다면: 시간 소모가 크지만 팀별 강조 포인트 부각

• 들어갈만한 자료
• 오프라인 모임 사진
• 필요에 따라 / 정기적으로 오프라인에서 모여서 작업하였음
• 브레인스토밍 등 공통 작업이 필요한 경우 모임이 필요
• 온라인 소통의 한계로 인해 일정 시간마다 조율하는 시간이 필요했기에 정기 모임
• 노션 문서
• 노션을 이용한 문서 기반 소통으로 효율적 의사 전달
• 노션 메인 페이지나 유저 스토리 / API 페이지 등을 보여주면 될 듯
• 피그잼
• 피그마의 경우 프론트에서 이야기하기로

🙌 협업 방식

Git 컨벤션(백)

• 백 / 프론트 따로

• Git-Flow 사용
• main : EC2서버로 배포되는 브랜치
• develop : 배포되기 위한 타깃 브랜치
• feature : 기능 개발 브랜치
• hotfix : main에서 발생한 버그를 해결하기 위한 브랜치
• release : 추후 추가된 브랜치로, 배포 전용 브랜치

백엔드 기술 스택

⚒ 기술스택

• Java 11

• Gradle

• Spring Data JPA, QueryDSL

• Spring Security, JWT, OAuth

• Spring RestDocs

• Mysql

• aws - EC2/RDS/S3

• Github Actions

• Docker

• Slack

• PINPOINT, nGrinder

• JUnit5

• Mockito

백엔드 세부 설명 사항

💬 아키텍처

• 백엔드 인프라 및 배포 프로세스
• Github Actions 이용 CI/CD workflow 통과 → PR merge
• build된 Docker Image를 EC2 서버에서 실행하는 방식으로 배포 진행
• 서버에서 발생된 에러 데이터 경우 로그 파일을 남기고 있으며, Slack 채널을 통해 에러 트레이스 확인 가능
• nGrinder, PINPOINT를 사용하여 부하 테스트를 진행, 서버의 요청 처리 성능을 모니터링할 수 있음

• 헥사고날 아키텍처 DDD
• 관심사의 분리, 객체지향적 설계
• JPA 엔티티 설계
• 주요 도메인 엔티티를 설계할 때 VO(Embeddable)을 활용하여 Validation 로직 등을 관심사에 따라 분리하고자 하였음
• 분리로 인해 비즈니스 중요성이 높은 도메인 모델의 코드의 가독성을 높임

• SSE 알림
•  라이딩 참가, 라이딩 취소가 발생하면 라이딩 리더에게 실시간으로 알려줄 필요가 있었음
• 실시간 알림을 구현할 기술 후보로 웹 소켓, server side events가 있었음
• 현재 프로젝트 상황에서는 클라이언트-서버간 양방향 통신이 아닌 서버→ 클라이언트 단방향 소통으로도 충분한 상황이었음
• 또한 기존 http 프로토콜에서 동작하는 SSE와 다르게 웹 소켓을 사용할 경우 ws 프로토콜에 대한 처리와, 실시간 세션 관리가 필요했기 때문에 개발 복잡도가 늘어날 가능성이 있었음
• 위와 같은 이유로 알림 푸시 기술로 SSE를 채택!
 

발표 스크립트

• 서비스 소개
• 안녕하세요. Team Forest의 발표자인 Kant입니다.
• 발표 순서입니다.
• 우선 팀 소개를 하겠습니다.
• 저희 팀은 8명의 성장하는 나무들이라는 의미에서 팀명을 Forest로 정했습니다: 팀원들의 역할은 위와 같습니다.
• 프로젝트 개요(Overview) / 서비스 소개
• 우선 저희 서비스에 대해 설명 드리겠습니다. 저희 서비스는 RG; Riding is Good으로 ”빠르고 간단하게 라이딩 모임을 개설 및 참여할 수 있는 통합된 플랫폼입니다.
• 최근, 자전거에 대한 관심이 증가하는 추세입니다. 2021년 번개장터 기준 자전거 거래액은 전년대비 82% 증가했습니다.
• 증가하는 수요와 달리 숙련 정도에 따라, 자전거 종류에 따라, 루트에 따라 전문적으로 자전거를 타는 모임을 갖기는 힘든 상황입니다.
• 기존 서비스의 경우 쉽게 모임을 모집하기도, 원하는 모임에 참여하기도 힘든 실정이기 때문입니다.
• 서비스 강점 / 기대 효과
• 기존 자전거 커뮤니티의 경우 일일히 글 양식을 작성해서 모임을 모집해야 했습니다. 이로 인해
• 라이딩을 주최하는 사람은 일일히 빠트린 사항은 없는지 체크해야 하는 불편함을 겪고
• 참가자는 자신이 원하는 형태의 라이딩을 찾는데 어려움이 있었습니다:
• 특정 지역에서 이뤄지거나, 일정 실력 수준이거나, 특정 자전거 종류와 관련된 라이딩을 찾고 싶은데, 찾기가 번거롭습니다.
• 반면 RG의 경우 다음과 같이
• 작성자의 경우 주어진 폼에 따라 빠르고 간단하게 모임을 개설할 수 있고
• 참가자의 경우 통합된 필터 양식에 따라 원하는 모임을 쉽게 찾고 참여할 수 있습니다.
• 구체적인 서비스 작동은 뒷 부분에서 시연 영상으로 안내드리겠습니다.
• 협업
• 서비스 시연에 앞서, 저희 팀이 이번 프로젝트를 어떻게 개발하였는가에 대해 설명드리고자 합니다. 백엔드와 프론트엔드 파트 별로 설명드리겠습니다.
• 우선 프론트 / 백과 상관 없이 팀 전체의
• 우선 협업용 툴은 다음과 같습니다.
• Zenhub: 이슈 발행
• Notion: 문서화
• Pigjam: 브레인스토밍
• 백엔드
• 백엔드의 경우 다음과 같은 프로세스로 배포를 진행했습니다.
• Issue 단위로 Zenhub에서 브랜치 생성, 작업 이후 PR을 날립니다.
• Github Actions를 이용한 CI/CD workflow 통과하고, 리뷰에서 approve를 받은 후 PR을 merge합니다.
• release 브랜치의 통합된 내용이 build된 Docker Image를 EC2 서버에서 실행하는 방식으로 배포가 자동적으로 진행됩니다.
• nGrinder, PINPOINT를 사용하여 부하 테스트를 진행, 서버의 요청 처리 성능을 모니터링할 수 있음
• Slack과 연동하여, PR 및 머지 과정이 발생하면 메시지를 전송하고 있으며
• 배포가 이루어질 때마다 애플리케이션이 정상적으로 로딩되었을 때 / 500 에러가 발생했을 때도 메시지를 전달하여 상황을 파악하고 있습니다.
• 메시지와 별개로, 서버에서 발생된 에러 데이터 경우 로그 파일을 남기고 있으며
• 위와 같이 자동화된 프로세스가 사람이 미처 잡아내지 못한 문제를 찾아 줬는데, 특히 후반부 리뷰에 소홀해질수록(일정바빠) 도움이 되었습니다.
• 기본적으로 코드 리뷰를 거친 코드만 머지될 수 있게 했는데
• 미처 보지 못한 포인트를 서로 체크하게 해주고
• 프로덕트의 품질
• 코드 컨벤션을 지키게 도왔습니다.
• 또 개인 프로젝트와 달리, 거대한 프로젝트에서 공통 작업을 수행하는 상황이기에 유지보수하기 쉽고 협업하기 좋은 코드를 위하여 다음과 같이
• 패키지 및 프로젝트 구조에 있어서 헥사고날 아키텍처를 도입하였으며
• JPA의 Embeddable을 이용해 거대 엔티티의 로직을 역할과 책임에 따라 쪼개서 관리하였습니다
• SSE 알림
•  라이딩 참가, 라이딩 취소가 발생하면 라이딩 리더에게 실시간으로 알려줄 필요가 있었음
• 실시간 알림을 구현할 기술 후보로 웹 소켓, server side events가 있었음
• 현재 프로젝트 상황에서는 클라이언트-서버간 양방향 통신이 아닌 서버→ 클라이언트 단방향 소통으로도 충분한 상황이었음
• 또한 기존 http 프로토콜에서 동작하는 SSE와 다르게 웹 소켓을 사용할 경우 ws 프로토콜에 대한 처리와, 실시간 세션 관리가 필요했기 때문에 개발 복잡도가 늘어날 가능성이 있었음
• 위와 같은 이유로 알림 푸시 기술로 SSE를 채택!