HomeAboutMeBlogGuest
© 2025 Sejin Cha. All rights reserved.
Built with Next.js, deployed on Vercel
♥️
2기 최종 프로젝트 팀별 공간
/
🌳
[팀 05] Forest
/
🏢
최종프로젝트 제출
/
🏦
고용노동부 제출용
🏦

고용노동부 제출용

공통 입력 사항 Until 08:15월 14:00
담당자
자체 평가 의견
역할
담당 업무
📄
자체평가 - 이한빈
팀원
ERD 설계, 사용자 정보 수정 및 조회 기능 개발, 이미지 업로드 기능 개발
자체평가
팀원
백엔드 CI/CD 파이프라인 구축 및 관리, Riding 댓글 API 구현, 배포 환경 이슈 트러블 슈팅
✅
자체 평가
팀원
Riding 생성 및 수정, 평가 기능
자체평가
팀장
User 회원 가입 및 Kakao Oauth 연동
✅
자체평가
팀원
라이딩 조회, 라이딩 조건별 검색, 알림 서비스
🌱
자체평가
팀원
회원 (인증 및 인가, kakaoOauth), 마이페이지(라이딩 조회 및 유저평가)
자체평가
팀원
라이딩 입력 및 수정 페이지, 프로필 수정 페이지
✅ 자체평가
✅ 자체평가
팀장
공통 컴포넌트 개발, 라이딩 리스트(필터, 무한스크롤 등), 라이딩 디테일 페이지 개발, 댓글 기능 구현 ,알림 기능 개발

프론트엔드 제출 사항(Tree)

활용 장비 및 재료(개발환경)

✅ 프론트 개발환경 정리
배포
  • Netlify
개발
  • Typescript , React , Recoil ,React-Query , React-hook-form, Webpack
코드관리
  • ESLint, Prettier
스타일
  • Figma , Emotion , Material-UI
소통
  • GitHub, Notion, Discord, Slack

프로젝트 구조

✅ 페이지 구조 (UserFlow)
notion image
✅ 폴더구조
  • ducks pattern의 응용
    • 페이지별(도메인) compoenets, hooks, -service를 독립적으로 구상
      • 공통부분 생겨날 때 계층을 올려 common으로 묶어 줌

프로젝트 수행 과정(프론트엔드만 수행한 작업들)

✅ 브랜치 전략 및 컨벤션
[브랜치 컨벤션]
main: 최종 배포 브랜치
develop: 개발용 배포 브랜치
  • 실제 코드 작업이 이루어지는 브랜치는 이슈번호와 브랜치를 연동하여 사용
    • feat/[이슈번호] : 기능개발용 브랜치 ⇒ ex.feat/012
      fix/[이슈번호] : 코드 수정을 위한 브랜치 → ex. fix/017
[커밋 컨벤션]
  • [Action] [commit 내용]
    • [feat] 알람 기능 구현
    • [fix, style] 메인 페이지 레이아웃 수정
[코드 컨벤션]
esLint ⇒ “airbnb룰”을 최대한 사용
prettier
✅  기능별 설명 (기술적 설명)
  • 인증 및 인가
    • 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 사용
 

프로젝트 구조

아키텍처
notion image
  • 서버에서 발생한 에러에 대한 메시지를 slack으로 전달하여 확인할 수 있습니다.
  • nGrinder, PINPOINT를 사용하여 부하 테스트를 진행, 서버의 요청 처리 성능을 모니터링합니다.
배포 아키텍처
notion image
  • Github Actions를 통한 CI/CD 를 진행하고, 이를 통과해야만 PR이 merge됩니다.
  • build된 Docker image를 dockerhub으로 push하고, EC2 서버의 docker에서 이를 pull받아 실행하는 방식으로 배포를 진행합니다.
 
패키지 구조
notion image
notion image
헥사고날 아키텍처를 사용하여, domain 로직이 infrastructure에 의존하는 것을 최소화하는 걸 목표로 하였다.
erd
notion image
 

프로젝트 수행 과정(백엔드만 수행한 작업들)

  • 컨벤션
    • 커밋 메시지 컨벤션
      • 참고 링크 (태그를 사용한 메시지 컨벤션)
        • 예시 : [setting] init project
    • 코드 컨벤션
      • naver Java Coding Convention
    • Git 브랜치 전략 : Git-Flow
      • main : EC2서버로 배포되는 브랜치
      • develop : 배포되기 위한 타깃 브랜치
      • feature : 기능 개발 브랜치
      • hotfix : main에서 발생한 버그를 해결하기 위한 브랜치
      • release : 추후 추가된 브랜치로, 배포 전용 브랜치
        • 1 issue == 1 feature == 1 PR
    • 테스트 데이터 전략
      • 각 테스트 클래스에서 java 코드를 통하여 생성, rollback을 통하여 지우기
      • 단, 변경될 일이 적은 다음과 같은 데이터는 sql을 통하여 데이터를 생성, 공통으로 사용함
        • address_code.sql
        • bicycle.sql

자체 평가 의견(백엔드 내부) : 팀 단위로 간략하게 추가할만한 것

  • 프로젝트 기획
    • 🔥
      빠르고 편리하게 자전거 모임을 주최, 참여할 수 있는 서비스
    • 기존 자전거 커뮤니티의 문제점
        1. 레거시 서비스의 노후화
        1. 간편, 편리한 라이딩 모집 기능의 부재
         
  • 프로젝트 결과물에 대하여
    • 기획
    • 기획과 얼마나 부합하는가
    • 실무와 얼마나 맞닿아 있는지(얼마나 실무에 적용할 만한지)
    • 달성도
    • 완성도 등
  • 팀 차원에서 느낀 점을 특히 작성해주시면 됩니다.
 
[백엔드 입장 완성도 ⇒ ??/100]
  • 코드 완성도
    • 일관성
      • 프로젝트 후반부로 갈수록 코드 리뷰에 시간을 할애하지 못 해, 세부적인 네이밍 등에 있어서 일관성이 떨어지는 부분이 있었다.
        • DTO 필드 네이밍, 메서드명, 400 에러 메시지 등에서 차이가 발생
        • 역할 및 책임에 따라 분리 및 결합을 적극적으로 시도하여, 관리 포인트를 줄이고, 재사용성이 좋은 코드를 만들었음
        • 500에러 공통 처리, 이미지 저장 처리 등
    • 견고함
      • 방어적 코드 작성(null, 기본값 등)에 있어 경험 및 시간 부족으로 놓치는 부분이 있었음
      • Edge Case에 대한 테스트 코드가 부족하여, 검증이 부족한 코드가 발생, 잦은 트러블 슈팅이 발생하게 만들었음
 
 
📦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
{ "printWidth": 120, "tabWidth": 2, "singleQuote": true, "trailingComma": "all", "bracketSpacing": true, "semi": true, "useTabs": true, "arrowParens": "avoid", }