ddal-ggak/ddal-ggak-fe

딸깍 DDAL-GGAK

👉🏻 프로젝트 소개

"딸깍, 간편한 업무 관리로 시간과 노력을 절약하세요."

>

🟢 JIRA의 Ticket 시스템과 Github의 Commit 로그 시스템을 합친 업무 관리 시스템

• Task : 하나의 Task에서 팀별 카테고리(마케팅팀, FE팀, BE팀, UI/UX팀) 생성이 가능하고, 각 카테고리의 관리자가 Task를 이행하기 위한 Ticket을 생성합니다.
• Ticket 시스템 : 팀원은 원하는 티켓을 가져가 이를 이행합니다. 관리자의 Ticket 리뷰가 끝날 경우, 개인의 티켓로그에 반영됩니다.
• Ticket 점수 시스템 : 중요도, 난이도 등에 따라 점수가 매겨져있고 사용 끝난 티켓로그에 반영됩니다.

업무 수행을 체계적으로 관리하고 성과를 측정할 수 있습니다.

🖱️딸깍 서비스 이용하기

🖱️딸깍 노션

🗓️ 프로젝트 운영 기간

💻개발 기간: 2023년 3월 10일 ~ 2023년 4월 20일

👩‍💼운영 기간: 2023년 4월 17일 ~ 2023년 4월 29일

🛠️ ERD

---

🛠️ 프로젝트 아키텍처

---

📚 기술 스택

⭐Front-End
>

⭐Back-End

⭐Dev Tools

📝 기술 채택 이유

React

도입 사유
1. State 변경에 따른 반응성 유지. 2. 함수 컴포넌트를 사용한 컴포넌트 재사용성 증대.

Redux

도입 사유
클라이언트의 state 관리 및 Provider pattern을 이용한 컴포넌트 간 불필요한 의존성을 제거하고 재사용성 확보.

redux, recoil, zustand 등
• 현재 프로젝트 상태만 보면 recoil을 사용하는 것이 맞으나, 최종적으로 만들고자 하는 프로덕트는 B2B SaaS이기 때문에 결국 프로덕트의 규모는 굉장히 커질 예정입니다. 따라서, 초반에 작성해야 할 코드가 좀 있겠지만, 나중의 스케일업에 대한 유동성을 고려해본다면 redux로 상태를 관리하는 것이 옳다고 판단했습니다.

Typescript

도입 사유
1. type을 통한 안정성 확보.
2. 미처 잡아내지 못한 에러 디버깅.
3. 자동완성 기능.

styled-components

도입 사유
1. 외부 환경변화에 따른 유동적 대처가 가능.
2. 함수 컴포넌트에 여러 props를 전달하더라도 복잡한 optional rendering을 제어할 수 있음.
3. 전역적으로 스타일링에 대한 책임을 담당하고 책임을 부여.

TailwindCSS

기본적으로 적용된 CSS 프리셋이 있어 간편하다는 장점이 있지만, props를 통해 optional하게 CSS를 적용할 경우, 가독성이 크게 떨어진다는 문제점이 있습니다. 또한, 이것과 더불어 전역적인 style 적용에도 어려움이 있습니다. 결국, 외부환경의 변화에 유동적으로 대처하며, 복잡하고 상세한 CSS를 적용하고자 styled-components를 채택하였습니다.

react-hook-form

도입 사유
1. 간편한 커스텀 validation 및 errorMessage 렌더링.
2. 압도적으로 짧아지는 코드 길이와 높아지는 함수 컴포넌트의 가독성 확보.

Prettier + ESLint (CodeConvention)

도입 사유
1. 형상관리툴을 이용하며, 팀원과 코드를 동기화하는 과정에서 conflict를 최소화하고자 함입니다.
2. conflict의 문제를 떠나, 타인과 협업을 하는 상황에선, codeConvention을 통일해야합니다. 해당 코드의 유지보수와 확장성을 보장하기 위해, 최소한의 “가독성”과 규칙이 전제되어야 하기 때문입니다. 나아가, 더 나은 변수명을 고민하고, 꾸준한 클린코드와 리팩터링을 진행하는 것을 습관화 해야합니다. 내가 작성하는 코드는 부채가 아닌 기술이 되어야합니다.

husky (CommitConvention)

도입 사유
- 커밋 로그만 보더라도, 어떤 작업을 했는지 알 수 있어야 합니다. 특히, 타인과의 협업에서 commit convention을 지키고, 실제 commit 내역과 commit 메시지를 일치해야 함을 인식해야합니다.

Vercel (Deploy)

도입 사유
- 원래 계획에는 AWS S3로 배포 후, github action을 이용해 CI/CD를 구축하고자 하였습니다. 다만, 여러가지 문제점이 발생하여, 자체적으로 CI/CD 및 deploy를 제공하는 Vercel을 채택하였습니다. 추후, 위의 환경으로 migration 예정입니다.

JEST + rtl

도입 사유
- PR을 날리기 전, 본인이 작성한 코드의 sideEffect를 알 수 있는 도구입니다. 위와 같은 이유로, testCode를 많이 작성하지는 못했지만, 추후 컴포넌트 단위의 테스트코드를 전부 작성할 예정입니다.

JWT + Redis 토큰 방식

도입 사유
- 한 회원의 다중 클라이언트를 이용한 동시접속 제어를 하기 위해서 세션을 도입할 것인가, 말 것인가에 대해 회의를 해야 했습니다.

세션/ REDIS
• 세션은 stateful한 인증 방식으로 서버에 세션 정보를 저장하여 인증을 유지하기 때문에 서버의 확장성을 낮추고, 서버에 저장된 세션 정보가 많아지면 서버의 메모리 부하가 커지고 서버의 안정성에도 영향을 줄 수 있습니다.
• 프로젝트의 특성상 다수의 사용자가 동시에 접속하는 경우 서버의 부하가 크게 증가할 수 있습니다. 따라서 대규모 사용자를 처리해야 하는 경우에는 분산 캐시나 다른 기술을 이용하는 것이 더욱 효과적이라고 생각해서 redis를 선택했습니다

Redis

도입 사유
- 접속 제어를 위해 REFRESH TOKEN 관리 필요

SPRING DATA JPA / REDIS
• Spring Data JPA는 객체-관계 매핑(Object-Relational Mapping) 기술을 제공하여, 데이터베이스와 객체를 매핑하여 개발을 용이하게 해주는 프레임워크입니다. 하지만, JPA는 대량의 데이터를 처리할 때 성능 이슈가 있을 수 있습니다.
• B2B SaaS 서비스에서 접속 제어를 위해 Redis를 사용하는 것은, Refresh Token과 같이 민감한 정보를 안전하게 저장하고, 빠른 속도로 대용량의 데이터를 처리하기 위함입니다. Redis를 이용하면, Refresh Token을 안전하게 저장하고, 유효성 검사를 효율적으로 처리할 수 있으며, 성능이 뛰어나므로 사용자 경험을 향상시킬 수 있습니다.
• 또한 Redis는 높은 성능, 분산 시스템, 캐시 등의 이점을 제공해 확장가능성도 뛰어났고, 데이터 안정성과 서비스 성능 향상에 효과적이기에 선택했습니다.

NGINX

도입 사유
- CI/CD 무중단 배포
- 기술 개발과 실 서비스 이용자들이 업데이트를 할 때마다 서버가 끊어지지 않고 적용하기 위해 필요

github action, docker, jenkins, Travis s3, codeDeploy, Redis, Nginx, Apache, Load Balancing
• 이미지와 초대부분 때문에 docker container를 활용해 Elastic Clound를 적용시키려고 했으나, 한정적인 비용과 주 목적인 업무틀과 티켓 페이지에는 기본적인 CI/CD를 활용하는 것이 더 맞다고 판단하여 결정했습니다.
• jenkins, Travis는 자주 꺼진다는 이슈로 안정적인 서버 구축을 위해 CI로는 github action을 선택했습니다.
• codeDeploy배포 후 업데이트를 진행할 때마다 서버가 내려가는 부분을 고민하다, 가동성과 접근성이 좋은 Nginx를 선택하게 되었습니다.
• 로드밸런싱의 블루 그린을 이용하여 서버를 여러개 띄워서 오토스케일링을 사용하려고 했으나, 비용적인 문제로 일반을 선택하였습니다.

MapStruct

도입 사유
- 미래지향적 사고
- 프로젝트의 현재만 보고 달리지 않기 위해 지원이 오래된 라이브러리의 경우 쓰지 않기로 하였습니다.

다양한 라이브러리
• 예를 들어 Mapping framework에도 저희가 사용한 Mapstruct외에도 자바 수동 변환, ModelMapper, Orika, Dozer등과 같은 다양한 라이브러리가 있습니다. 그러나 호환성이나 리플렉션같은 기술적인 부분을 제외하고도, 지원이 오래되거나 중단된 라이브러리, 레퍼런스가 부족한 라이브러리는 장점이 많아도 사용하지 않도록 하기로 했습니다.

Git hub Action

도입 사유
- properties 관리
- 어떻게 해야 properties를 비롯한 백엔드 보안 이슈에 더 민감하게 대처할수 있을까 생각하였습니다.

GITHUB ACTION / jasypt
• 위에서 github action을 사용하기로 결정함에 따라, 인스턴스에 VM옵션을 주어서 가동해야하는 jasypt방식 대신에 깃허브 액션에서 프로퍼티를 관리하기로 하였습니다.

---

👥팀원 git hub

포지션	이름	깃허브 주소
FE	김대현	https://github.com/pengooseDev
FE	박지현	https://github.com/Taffymark1
BE	조영준	https://github.com/choincnp
BE	박현아	https://github.com/aihtnyc-h
BE	박성민	https://github.com/seongminnnn

ddal-ggak-fe's Issues

[DDA-78] GlobalCSS 재설정 및 MediaQuery 처리

_{From SyncLinear.com | DDA-78}

[DDA-72] [DDA-70] Project 페이지 구현

_{From SyncLinear.com | DDA-70}

_DDA-72

[DDA-51] [DDA-49] Nav의 width에 따라 content의 width가 계산되는 ContentWrapper 컴포넌트 구현

_{From SyncLinear.com | DDA-49}

_DDA-51

[DDA-53] SignIn 페이지 구현

_{From SyncLinear.com | DDA-53}

[DDA-71] Task 페이지 구현

_{From SyncLinear.com | DDA-71}

[DDA-52] Login 페이지 구현

_{From SyncLinear.com | DDA-52}

[DDA-48] Global Layout

_{From SyncLinear.com | DDA-48}

[DDA-69] Task 객체 생성

_{From SyncLinear.com | DDA-69}

[DDA-75] Task 페이지 구현(티켓)

_{From SyncLinear.com | DDA-75}

[DDA-49] Nav

_{From SyncLinear.com | DDA-49}

[DDA-67] ticket 객체 생성

_{From SyncLinear.com | DDA-67}

[DDA-74] [DDA-73] Ticket Detail 페이지 구현

_{From SyncLinear.com | DDA-73}

_DDA-74

[DDA-68] Project 객체 생성

_{From SyncLinear.com | DDA-68}