[코드스테이츠 Main-Project] 매일메일 회고

이창훈·2022년 10월 13일
0

회고

목록 보기
2/9
post-thumbnail

매일 메일

깃허브 : 링크
S3배포링크 : 링크 서버가 유효하지않아 현재기능X

프로젝트 선정이유

  • 획기적인 기능 혹은 서비스를 우리가 만들려고 하지 말고 주니어 개발자의 포트폴리오에 들어갈 프로젝트에 걸맞는 기술 스택과 기능에 충실한 프로젝트를 제작하는 것을 목표로 하였습니다.
  • 최초에는 반려동물 SNS를 하려고 하였다.

    이에 따라 여러 아이디어가 나왔다.

    • 당근마켓처럼 지역 커뮤니티기능을 넣고 지역을 기반으로 하면서 반려동물과 관련된 기능을 생각하다보니 산책한 코스를 기록하여 우리 동네 산책 코스 추천 기능을 생각했다. 이에 따라 프로젝트의 방향성에 대해서 다시 고민하게 되었다.
    • 반려 동물 SNS 라고 했지만 산책 코스 추천 기능을 넣게 된다면 산책을 하는 반려동물인 강아지만을 다루자.
    • 그래서 우리는 반려 동물 SNS에서 강아지를 키우는 사람들의 SNS로 주제를 바꿨다.
    • 하지만 산책기능을 넣자니 우리가 만드는게 웹 어플리케이션인데 모바일 어플리케이션의 성질을 가지고 있다. 웹 사이트를 켜놓고 산책을 기록하는게 어색하지 않느냐는 생각에 부딪혔다.
    • 또한 우리가 만들려고 하는 것이 SNS인지 웹 커뮤니티인지 정체성을 잃고 있었다.

위와 같은 이유로 우리는 주제를 다시 선정하기로 하였다.

프로젝트 설명

  • 구독을 하면 매일 아침 자신의 메일로 구독한 카테고리의 면접 질문을 받을 수 있는 서비스
  • 질문의 댓글로 자신의 면접 답변을 작성할 수 있고 그 답변의 댓글을 달 수 있다.
  • 답변과 댓글에 좋아요를 누를 수 있고 답변과 댓글은 좋아요가 많은 순으로 정렬된다.
  • 자유게시판에는 게시글을 작성할 수 있다.
  • 자유게시판 게시글에는 댓글을 달 수 있으며 마찬가지로 댓글은 좋아요가 많은 순으로 정렬된다.

구체적인 설명

  • 회원가입시 이메일 인증을 하며 가입한 이메일로 매일 8시(메일 받는 시간을 일괄적으로 정해져있다.) 면접 질문을 받는다.
  • 준비된 면접 질문이 모두 메일로 발송되면 더 이상 메일이 가지 않는다.
  • 카테고리를 구독하여 면접 질문을 받다가 구독을 취소하고 다시 구독할 경우 앞에서 받은 면접 질문은 메일로 다시 받지 않는다.

개발 기간 및 인원

개발 기간

2022년 09월 07일(수) ~ 2022년 10월 12일(수) 5주

개발 인원

Front-end : 한정윤, 이창훈
Back-end : 김충섭, 김수빈

구현 항목

  • 회원가입
    -이메일, Password 유효성검사
    -이메일 인증번호검사

  • 로그인/로그아웃

  • 토큰을 이용한 유저 판별

  • 프로필 사진, 프로필 닉네임, 비밀번호 수정

  • 유저 CRU

  • 질문 CRUD

  • 답변 CRUD

  • 댓글 CRUD

  • 게시판 페이징

  • 게시글 검색

  • Light/Dark 모드

  • 질문, 답변 좋아요

  • 회원 구독 카테고리 메일 전송

내가 구현한 부분

  • 회원가입
    -이메일, Password 유효성검사
    -이메일 인증번호검사
  • 질문 CRUD
  • 답변 CRUD
  • 댓글 CRUD
  • Light/Dark 모드
  • 질문, 답변 좋아요

기능 외적인 부분

  • 클라이언트 배포 : AWS S3
  • 로고 디자인
  • 랜딩페이지, 로그인,회원가입 화면 디자인

기술 스택

Front-end : React, Redux Toolkit, Styled Components, Axios, react-toastify, React Scroll Motion

클라이언트 배포 : AWS S3

문서/협업

  • Github Projects
    - Issue
    - Milestones
  • Git
  • Slack
  • Zoom

KPT

Keep

  • 랜딩페이지
    -방문객분들로 부터 랜딩페이지를 어떻게 만들었는지에 대한 질문을 가장 많이 받았다.

  • 로고 디자인 링크
    -누군가는 해야 하는 일이지만 우선 순위가 아닌 일이었다.
    -여러 가지를 미리 만들어가 이런식으로 하는게 어떤지 의견을 물었고 팀원들에게 피드백을 받아 로고를 만들었다.
    -시안을 만든 다음 구체적인 논의를 이어가니 의견을 모으는데 수월했다.

  • 반응형 웹 어플리케이션제작
    -웹 어플리케이션일지라도 모바일 환경에서 접속했을 때 화면 비율이 깨지지 않고 모바일 어플리케이션을 사용하고 있다는 사용자경험을 주고 싶었다.

    • 미디어쿼리와 %를 사용하여 CSS를 제작하였다.
  • AWS S3로 클라이언트 배포에 성공한 것

Problem

  • optimistic update로 UI를 변경한 것.
    -나에게 오랜 고민이었다.
    1. useEffect를 이용해서 전역 상태로 비동기 데이터를 가져오기 위해서 Redux Thunk를 사용했다.
    2. Redux Thunk는 새로고침을 하게되면 데이터를 잃어버리게 된다.(이 순간이 되어서야 깨달았다. Redux는 순수함수를 사용하므로 상태를 예측가능하게 한다는 장점이 있지만 Props의 깊이가 깊지 않을 경우 useState만으로도 UI를 컨트롤 할 수 있었다.
    3. 서버데이터의 변경이 반영된 UI를 나타내기 위한 고민의 과정에서 키워드를 찾지 못해 부딪혔다.

1) Redux에서 비동기 데이터를 다룰 때 특별히 Redux saga 또는 Redux Thunk를 사용했으므로 그걸 사용할 경우 문제가 해결되거라 생각했다.
2) 클라이언트 데이터, 서버 데이터를 구분하지 못했다.

이후에는 서버의 상태를 관리해주는 React-Query를 통해 현재까지의 가장 자연스러운 해결방안을 찾아내었다.

  • 코드의 길이가 너무 길다. 조금 더 상세하게 분리할 수 있었을 것 같다.

  • MarkDown을 이용해서 게시글을 작성할 수 있었으면 좋았을 것 같다.

  • JWT토큰 사용에 대해서
    -jwt토큰 방식을 사용하였지만 accessToken만을 이용하여 로그인을 구현하였다.
    -accessToken이 만료되었을 경우 응답을 가로채서 RefreshToken을 통해 다시 access토큰을 발급받고 즉시, accessToken을 교체하여 요청을 보내는 방식을 적용해보고 싶었으나. RefreshToken의 인증과정과 그럴 경우의 accessToken을 새로 발급해주는 부분에서 server팀의 기능 구현이 완성되지 않아 적용하지 못했다.

  • API가 늦게 나와서 남는 시간만큼을 CSS에 투자했다.
    -덕분에 데모데이에서 'CSS에 몰빵했네'라고 지나가시면서 하시는 말씀을 듣게 되었다.
    -그 말을 들었을 때는 억울한 마음이 들기도 했지만 'msw'라이브러리를 통해 API가 나오는 동안 비동기데이터에 대한 개발을 진행할 수 있었다.

  • http로 배포한 것
    -https배포를 최종 목표로 배포를 진행했다. 프리프로젝트에서는 vercel로 클라이언트 배포를 마쳤지만 서버에서는 https와 연결할 수 없어서 http로 배포 해줄 것을 요구하였다.
    -그리고 메인프로젝트에서는 먼저 http로 연결이 잘 되는지 확인한다음 https연결에 도전해보자고 하셨다.
    -그리하여 내가 vercel이 아닌 AWS S3를 이용하여 배포를 진행하였고 서버와의 통신에 성공하였다. 하지만 끝내 https로의 연결에는 성공하지 못했다.

Try

  • DarkMode를 ThemeProvider를 사용했으면 컴포넌트들마다 themeState를 넘겨줄 필요가 없었을 것이다.
    다크모드 리팩토링

  • window.alert대신 Modal을 이용하는게 더 좋은 사용자 경험을 줄 것이다.(직접 받은 피드백), 현재 프로젝트에서 alert을 Modal로 수정하진 못 했지만 의견을 수렴하여 다른 프로젝트에서 Modal을 사용하여 상호작용하는 방법을 적용함

  • 회원가입 로그인의 경우 커스텀훅을 만들어서 사용하거나, React-hook-form 라이브러리를 사용하면 좋을 것 같다.

내가 못한 점

  • 우리 팀은 프로젝트를 진행하면서 서로 의견을 부딪히며 싸웠던 적이 전혀 없다. 프론트엔드 팀사이에서도 각자의 코드를 존중하며 갈등을 겪지 않았다.

  • 하지만 우리는 서로를 너무 존중한 예의를 갖춰서인지 자유로운 회의 분위기라고 말하기는 어려웠던 것 같다.

  • 서버분이 귀찮으실까봐 말씀을 안드리고, 듣기 싫은 말이고 잔소리처럼 들릴까봐 말하지 못하고 넘어가고, 멘토님을 들들볶아서라도 TypeScript를 사용하자고 더 큰소리 내지 않고 쉽게 수긍해버린 점이 아쉬움으로 남는다.

  • 실패를 경험하고 힘들더라도 내가 더 학습해서 결국에 성과로 나타난다면 순간의 모진 말과 이기적인 마음이 리더쉽과 도전정신으로 기억되지는 않을까 생각된다.

내가 잘한 점

  • 단기간에 핵심을 파악하고 서버분과 의견을 조율하여 기능을 구현했던 점(이메일 인증 기능 추가 할 때)
    -우리 서비스의 가장 핵심적인 기능을 이메일을 받는 것이다.
    -하지만 로그인, 게시물 CRUD, 특히 프로필사진이미지를 저장하기 위해서(AWS S3를 이용하여 이미지는 따로 저장)예상보다 많은 시간을 쓰게 되었다.
    -데모데이를 하루 앞두고 이메일 인증은 필수기능이라고 판단하여 서버분과 내가 어떤 로직으로 구현할 것인지 빠르게 결정하고 단 몇 시간만에 UI와 이메일 인증 기능을 구현하였다.

마무리

  • 협업하는 방법에 대하여 배운 점이 가장 크다고 생각한다.
    -서버분들과 소통하고 프론트엔드팀 사이에서 분업을 하고 merge하고 충돌을 해결했던 이런 협업의 과정이 가장 값진 경험이었다.
profile
실패를 두려워하지 않고 배우고 기록하여 내일의 밑거름 삼아 다음 단계로 성장하겠습니다.

0개의 댓글