공통 입력 사항 Until 08:15월 14:00
프론트엔드 제출 사항(Tree)
활용 장비 및 재료(개발환경)
✅ 프론트 개발환경 정리
배포
Netlify
개발
Typescript
,React
,Recoil
,React-Query
,React-hook-form
,Webpack
코드관리
ESLint
,Prettier
스타일
Figma
,Emotion
,Material-UI
소통
GitHub
,Notion
,Discord
,Slack
프로젝트 구조
✅ 페이지 구조 (UserFlow)

✅ 폴더구조
- ducks pattern의 응용
- 페이지별(도메인) compoenets, hooks, -service를 독립적으로 구상
- 공통부분 생겨날 때 계층을 올려 common으로 묶어 줌
📦src ┣ 📂@types // 전역에서 사용되는 interface 정의 ┣ 📂api ┣ 📂assets ┣ 📂components // 전역에서 사용되는 공통 컴포넌트 ┣ 📂constants ┣ 📂hooks // 전역에서 사용되는 공통 Hooks ┗ 📂pages // Page단위로 components/hooks/common 폴더 만들어 분리 ┃ ┣ 📂MainPage ┃ ┃ ┣ 📂components ┃ ┃ ┣ 📂constants ┃ ┃ ┣ 📜index.tsx ┃ ┃ ┗ 📜mainpageService.ts ┃ ┣ 📂MyPage ┃ ┃ ┣ 📂components ┃ ┃ ┃ ┣ 📂EvaluateTab ┃ ┃ ┃ ┣ 📂MainTab ┃ ┃ ┃ ┣ 📂Profile ┃ ┃ ┃ ┣ 📂RidingTab ┃ ┃ ┃ ┣ 📂SideNavigation ┃ ┃ ┃ ┗ 📂common ┃ ┃ ┃ ┃ ┃ ┃ ┣ 📂hooks ┃ ┃ ┣ 📜index.tsx ┃ ┃ ┗ 📜mypageService.tsx ┃ ┗ ...[-Page] ┣ 📂recoil ┃ ┣ 📂actions ┃ ┗ 📂state ┣ 📂routes // 인증,인가를 위한 route ┣ 📂stories ┣ 📂styles ┣ 📂utils ┣ 📜App.tsx ┣ 📜global.d.ts ┗ 📜index.tsx
프로젝트 수행 과정(프론트엔드만 수행한 작업들)
✅ 브랜치 전략 및 컨벤션
[브랜치 컨벤션]
main
: 최종 배포 브랜치develop
: 개발용 배포 브랜치- 실제 코드 작업이 이루어지는 브랜치는 이슈번호와 브랜치를 연동하여 사용
feat/[이슈번호]
: 기능개발용 브랜치 ⇒ ex.feat/012fix/[이슈번호]
: 코드 수정을 위한 브랜치 → ex. fix/017[커밋 컨벤션]
[Action] [commit 내용]
- [feat] 알람 기능 구현
- [fix, style] 메인 페이지 레이아웃 수정
[코드 컨벤션]
esLint ⇒ “airbnb룰”을 최대한 사용
prettier
{ "printWidth": 120, "tabWidth": 2, "singleQuote": true, "trailingComma": "all", "bracketSpacing": true, "semi": true, "useTabs": true, "arrowParens": "avoid", }
✅ 기능별 설명 (기술적 설명
)
- 인증 및 인가
- kakaoOauth 기능 구현
인증
- AuthRoute를 통한 토큰 체크 및 로그인 유지
인증
- jwt 토큰 관리 전략 구상
인증
- PrivateRoute를 통한 권한에 따른 페이지 접근 제어
인가
- 공통 컴포넌트 개발
- MUI 기반으로 custom 가능한 공톰 컴포넌트 제작
- 스토리북 활용을 통한 테스트 환경 제공
- 라이딩 개설 Form
- React-hook-form 과 MUI를 통한 Form 구성
- 카카오 API를 통한 주소 검색 연동
- 이미지 등록 / 수정 / 삭제 처리
- 라이딩 리스트
- 캐루셀을 통한 배너 구현
- 무한 스크롤 Module 구현
- react-query를 활용한 Filter 구현
- 기타
- SSE를 통한 알림 기능 구현
✅ 자체 평가 의견(프론트엔드 내부) : 팀 단위로 간략하게 추가할만한 것
[ 기획과 얼마나 부합하는가 ⇒ 90/100
]
- 우리 기획의 목표는 기존 자전거 취미 플랫폼이 가지고 있는 기본적인 문제를 해결함에 있었다.
- (1) 라이딩 검색 및 신청내역/현황 관리의 어려움 ( 기존: 게시글과 댓글로의 신청 )
- (2) 멤버를 모집하는 게시글의 표준 양식이 존재하지 않음
- 우리의 결과물은 아래와 같이 2가지 문제를 해결하였다.
- 라이딩 검색 > 필터를 통한 쉽고 효율적인 검색
- 신청내역/현황 관리 > 마이페이지를 통한 신청내역 확인 / 최소
- 표준양식 > 인풋에 따라 원하는 값들을 선택하고, 최소한으로 글을 작성하게 함
[ 실무와 얼마나 맞닿아 있는지(얼마나 실무에 적용할 만한지) ⇒ 70/100
]
- 종합적인 큰 관점에서 실무에서 경험할 수 있는 사이클을 모두 경험함
- 브레인스토밍을 통한 주제 선정, 활발한 토의를 바탕으로한 기획 구체화
- Figzam브레인스토밍, Moscow 선정 , Figma 와이어프레임)
- 커뮤니케이션을 위한 협업 툴 사용 및 문서화
- (노션, zenHub, 슬랙, discord)
- 유저스토리, API명세서, 이슈리포트, 화이트보드
- API 문서기반으로 백엔드와의 협업
- 실무에서 충분히 사용되고 있는 기술 선정
- typescript, react-query, storybook, recoil 등 다수의 안정된 기술 스택 사용
- 하지만, 실무에서 사용할 수 있을 정도로의 가독성과 퀄리티를 가진 코드를 작성하지 못함
- 시간의 한계가 가장 컸으며, 부족한 프론트 내부 리뷰도 영향
[달성도 ⇒ 90/100
]
- 유저스토리 기준 22개의 MUST 작업 모두 구현 완료
- Should에 해당하는 작업은 시작하지 못한 점과 Q/A 중 일부 해결되지 않는 문제 존재
[완성도 ⇒ 70/100
]
- 서비스 완성도
- 서비스의 관점에서 하나의 일련의 과정이 매끄럽게 진행될 수 있다.
- 코드 완성도
- 단일책임원칙에 의거하여 작성되었느냐라고 생각했을 때 높은 점수를 줄 수 없다.
- 컴포넌트들간의 분리와 책임이 명확하지 않았다.
- 디자인 완성도
- 디자이너의 부재로 인해 UX, UI 적으로 미적 감각이 떨어진다.
- MUI를 최대한 활용하여, 기본은 갈 수 있도록 노력하였다.
백엔드 제출 사항(Didi)
활용 장비 및 재료(개발환경)
Bob(초안)
Infra
- AWS RDS
- 운영 환경 데이터베이스
- AWS EC2
- 운영 환경 API 서버
- PINPOINT, nGrinder
- 운영 환경 모니터링 및 부하 테스트
- Slack
- 배포 환경 로그 모니터링
- Github
- API 서버 소스 코드 저장
- 새로운 feature 소스 코드 리뷰
- GIthub Action
- CI/CD 파이프라인
- Github Secret
- 각종 서비스 API key 보관
- DockerHub
- API 서버 애플리케이션 컨테이너 이미지 보관
- 배포 서버의 docker에서 이미지 pull 및 실행
Spring
- Spring Boot
- Java 11
- Gradle
- API 서버 빌드
- Spring Security(JWT, OAuth)
- 간편 회원가입/로그인을 위해 OAuth 도입.
- 사용자 인증을 위하여 JWT Token 사용
프로젝트 구조
아키텍처

- 서버에서 발생한 에러에 대한 메시지를 slack으로 전달하여 확인할 수 있습니다.
- nGrinder, PINPOINT를 사용하여 부하 테스트를 진행, 서버의 요청 처리 성능을 모니터링합니다.
배포 아키텍처

- Github Actions를 통한 CI/CD 를 진행하고, 이를 통과해야만 PR이 merge됩니다.
- build된 Docker image를 dockerhub으로 push하고, EC2 서버의 docker에서 이를 pull받아 실행하는 방식으로 배포를 진행합니다.
패키지 구조


헥사고날 아키텍처
를 사용하여, domain 로직이 infrastructure에 의존하는 것을 최소화하는 걸 목표로 하였다.erd

프로젝트 수행 과정(백엔드만 수행한 작업들)
- 컨벤션
- 커밋 메시지 컨벤션
- 참고 링크 (태그를 사용한 메시지 컨벤션)
- 코드 컨벤션
- naver Java Coding Convention
- Git 브랜치 전략 :
Git-Flow
main
: EC2서버로 배포되는 브랜치develop
: 배포되기 위한 타깃 브랜치feature
: 기능 개발 브랜치hotfix
: main에서 발생한 버그를 해결하기 위한 브랜치release
: 추후 추가된 브랜치로, 배포 전용 브랜치- 테스트 데이터 전략
- 각 테스트 클래스에서 java 코드를 통하여 생성, rollback을 통하여 지우기
- 단, 변경될 일이 적은 다음과 같은 데이터는 sql을 통하여 데이터를 생성, 공통으로 사용함
- address_code.sql
- bicycle.sql
예시 :
[setting] init project
1 issue == 1 feature == 1 PR
자체 평가 의견(백엔드 내부) : 팀 단위로 간략하게 추가할만한 것
- 프로젝트 기획
- 기존 자전거 커뮤니티의 문제점
- 레거시 서비스의 노후화
- 간편, 편리한 라이딩 모집 기능의 부재
빠르고 편리하게 자전거 모임을 주최, 참여할 수 있는 서비스
- 프로젝트 결과물에 대하여
- 기획
- 기획과 얼마나 부합하는가
- 실무와 얼마나 맞닿아 있는지(얼마나 실무에 적용할 만한지)
- 달성도
- 완성도 등
- 팀 차원에서 느낀 점을 특히 작성해주시면 됩니다.
[백엔드 입장 완성도 ⇒ ??/100
]
- 코드 완성도
- 일관성
- 프로젝트 후반부로 갈수록 코드 리뷰에 시간을 할애하지 못 해, 세부적인 네이밍 등에 있어서 일관성이 떨어지는 부분이 있었다.
- DTO 필드 네이밍, 메서드명, 400 에러 메시지 등에서 차이가 발생
- 역할 및 책임에 따라 분리 및 결합을 적극적으로 시도하여, 관리 포인트를 줄이고, 재사용성이 좋은 코드를 만들었음
- 500에러 공통 처리, 이미지 저장 처리 등
- 견고함
- 방어적 코드 작성(
null
, 기본값 등)에 있어 경험 및 시간 부족으로 놓치는 부분이 있었음 - Edge Case에 대한 테스트 코드가 부족하여, 검증이 부족한 코드가 발생, 잦은 트러블 슈팅이 발생하게 만들었음