프로젝트 회고 (feat. KPT)

HYUK·2023년 6월 7일
0

1. 프로젝트 안내

1-1. 개요

  • 캠핑은 많은 사람들이 자연과의 소통과 모험을 즐기는 인기 있는 활동입니다. 하지만 캠핑은 혼자서 즐기는 것이 아니라 다른 사람들과 함께 공유하는 것이 더욱 즐거운 경험이라고 생각합니다.
    모닥불이 캠핑지에서 사람들을 모아 따뜻한 분위기를 조성하는 것처럼, '모닥불' 플랫폼을 통해 사용자들이 모여서 자연과 캠핑에 관한 이야기를 나누며 따뜻한 분위기를 형성할 수 있는 공간을 마련하고자 했습니다.
    TwoPlusOne 팀의 첫 토이 프로젝트이자, 자연과 소통하는 캠핑 경험을 사진 및 지도 위치 공유 기능을 통해 업로드하고 서로 소통할 수 있는 플랫폼 '모닥불'을 소개드리고자 합니다.

1-2. 담당페이지

  • 로그인 페이지 (Google API 로그인)
  • 마이 페이지
  • Naver Map API 기능
  • 포스팅 디테일 페이지

1-3. 적용기술

  • React.js, TypeScript, Styled-components, Prettier, Eslint
  • 협업 및 일정관리 : Git, GitHub, Slack, Trello, Notion, postman

2. 구현페이지 안내

2-1. 로그인 페이지 (Google API 로그인)

1). 로그인 페이지 영상

  • Google Login API를 이용하여 진행하였습니다.

  • 구현시 @react-oauth/google라이브러리를 사용하여 구현하였습니다.

  • 구글로그인 버튼을 커스터마이징 하여 로그인버튼 디자인을 새롭게 디자인하였습니다.

  • 구글로그인을 통해 받은 token을 백엔드로 POST하여 jwt 로그인 방식으로 구현하였습니다.

2-1-1. 구현중 어려웠던 부분과 새롭게 배운부분

  • Google Login API
    처음 시작할때는 다양한 참고자료와 공식문서가 비교적 이해하기 쉽게 정리가 되있어서 호기로운 마음가짐으로 시작하였고 그렇게 어렵지 않을거라 생각하였습니다. 그러나 진행중 한기지 문제가 생겼던것이 지금까지 대부분의 구글로그인 구현시 사용해왔던 react-google-login라이브러리가 3월 이후로 이용이 중단된다고 하여 더 이상 사용하기 어려웠고 대부분의 참고자료가 react-google-login이 대부분이다 보니 참고자료 부분에서도 많은 어려움이 있었습니다. 여러가지 방법을 찾던 중 @react-oauth/google라이브러리를 찾을 수 있었고 라이브러리 관련문서 및 github에 오픈되있는 코드등을 참고하여 구현할 수 있었습니다.
    아래 링크는 위내용을 구현하면서 구현과정에 대한설명을 기술하였습니다.

    * 구글 소셜로그인 기능 구현과정 링크

2-2. 마이 페이지

1). 마이 페이지 영상

  • 스크랩, 좋아요, 포스팅 게시물의 항목에 대해서는 상수데이터로 작성하였습니다.
  • 각각의 리스트 항목의 layout이 모두 같고 내용만 다르다는점을 이용해 컴포넌트 재사용을 활용하여 구현하였습니다.
  • 컴포넌트 재사용시 중첩삼항연산자를 사용하여 구현하였습니다.
  • 리스트에 표출되는 항목들을 클릭시 해당 게시물로 이동할 수 있게 구현하였습니다.
  • 리스트에 출력할 게시물내용이 없을시 user가 게시물을 작성 혹은 스크랩을 유도할 수 있게 UI를 구성하였습니다.
  • 빈 리스트의 아이콘을 클릭시 해당 내용과 연관된 페이지로 각각 Link를 걸어놔 user가 조금 더 쉽고 적극적이게 이용할 수 있게 구성하였습니다.

2-2-1. 구현중 어려웠던 부분과 새롭게 배운부분

  • 조건부랜더링을 이용한 컴포넌트 재사용
    마이페이지의 스크랩, 좋아요, 포스팅 개시물 이렇게 3가지의 리스트 항목이 있었고 3항목의 layout이 동일하니 조건부랜더링으로 컴포넌트를 재사용해서 사용하면 코드양도 줄어들고 상당히 효율적일거라는 생각이 들어서 컴포넌트 재사용을 하기로 생각하고 구현을 시작하였습니다. 처음 시작전에는 단순히 지금까지 삼항연산자를 써오던것처럼 분기처리를 통하여 UI를 표현하면 될거라 생각하였는데 여러가지 조건이 맞물리다보니 생각보다는 쉽지 않았습니다. 그렇다보니 컴퓨팅 사고과정에 있어서 미스가 발생하는 상황이 생기고 거기에 잘사용하지 않던 중첩삼항연산자를 사용하여 구현하다보니 사고과정에 있어서 간단한 부분인데도 나도모르게 햇갈리는 상황이 발생하곤 하였습니다.
    그래도 다시 사고과정을 하나하나 작은단위로 쪼개서 생각하고 하나하나 조건을 맞춰주니 생각한대로 화면이 렌더링이 되었습니다.
    이번 컴포넌트 재사용을 통해 지금까지 간단하게만 생각해왔던 조건부렌더링에 대해서 다시한번 심도있게 고민해볼 수 있는시간을 가질수 있어서 좋은기회가 되었던것 같습니다.
    아래 링크는 위내용을 구현하면서 구현과정에 대한설명을 기술하였습니다.

    * 조건부 렌더링을 통한 컴포넌트 재사용 링크

2-3. Naver Map API 기능

1). Naver Map API 기능 영상

  • 단순히 사진과 글만 포스팅하는것이 아닌 캠핑장소도 함께 공유함으로써 다양하게 커뮤니티를 형성할 수 있도록 구현하였습니다.
  • 지도는 naver map api를 이용하여 구현하였으며 첫화면 지도 렌더링 위치는 현위치의 좌표를 가져오게 하였습니다.
  • 마커버튼을 찍어 위치를 공유할 수 있게 하였으며 마커버튼은 한 개만 찍을 수 있게 구현하였습니다.
  • 찍은 마커버튼의 위도, 경도값은 게시물 포스팅시 데이터베이스로 전달 됩니다.

2-3-1. 구현중 어려웠던 부분과 새롭게 배운부분

  • 저번 구글 api처럼 많이 해매지 않을까하는 걱정을하며 여러가지 막연한 걱정을하며 시작을 하였습니다. 그래도 걱정과달리 대한민국 한정 naver 지도 api는 가장많이 사용되는 지도 api중 하나이기 때문에 역시나 참고할 자료와 공식문서도 비교적 설명이 쉽게 되있어서 비교적 빠른시간안에 구현에 성공할 수 있었습니다. 우선 일단 다른사람들이 구현한 코드내용을 참고로 일단 이해가 안가더라도 따라서 입력한뒤 다시 공식문서를 읽어 내려가며 네이버 지도 api에서 제공하는 요소에 대해서 하나하나 확인하면서 내가 따라서 입력 코드에 어떠한 요소가 어떻게 입력되었고 어떻게 가져다 쓰는지 하나하나 찾아가며 구현해 나아갔습니다. 따라친 코드에서 이것저것 연습삼아 이것저것 지워도보고 추가도 해보면서 매커니즘에 대해서 조금씩 익혀나가며 하나하나 구현해 나아갔고 그 결과 원하는 결과대로 하나의 오차없이 구현되어 작동되는 모습을 보며 상당한 만족감을 느껴습니다.
    저번 구글 api때도 그랬고 이번 naver map api도 마찬가지로 공식문서를 천천히 읽어내려가면 많은 힌트를 얻을 수 있다는걸 다시한번 느꼇습니다.
    아래 링크는 위내용을 구현하면서 구현과정에 대한설명을 기술하였습니다.

    * Naver Map API 링크

2-4. 포스팅 디페일 페이지

1). 포스팅 디페일 페이지 영상

  • 비회원의 경우 게시물은 확인할 수 있으나 그 외의 기능은 할 수 없게 구현하였습니다.
  • 좋아요, 스크랩 버튼을 구현하여 mypage에서 스크랩 혹은 좋아요를한 게시물을 확인할 수 있게 구현하였습니다.
  • 게시물 이미지의 경우 여러장을 나열하는것이 아닌 slick라이브러리를 이용하여 넘기면서 볼수 있게 구현하여 UI/UX적인 부분을 강조하였습니다.
  • slick으로 구현한 캐러샐 기능의 경우 다른 페이지에서도 쉽게 사용할 수 있게 컴포넌트화 시켜서 관리하였습니다.
  • 댓글 리스트영영의 경우 댓글 데이터가 없는경우 user가 댓글이 있는지의 여부를 바로 판단할 수 있게 UI를 구성함으로서 댓글 작성에 대한 유도를 하였습니다.
  • 댓글입력시간 기준으로 방금 전, ...분 전, ...시간 전, ...일 전, ...주 전, ...개월 전, ...년 전 으로 출력될 수 있게 구현하였습니다.
  • 댓글리스트의 경우 data 렌더링 효율성을 위해 무한스크롤로 구현하였으며 구현시 Intersection Observer API를 사용하여 구현하였습니다.
  • 댓글 삭제기능의 경우 본인이 입력한 댓글에 대해서만 삭제버튼이 노출되게 구현하였습니다.
  • 캠핑장소를 공유하는 항목을 추가하여 user들이 더욱 다양하게 소통할 수 있게 layout을 구성하였습니다.
  • 캠핑장소는 단순히 글로 소통하는것이 아닌 user가 더욱 쉽고 빠르게 이해할 수 있도록 naver map api를 이용하여 해당 위치를 확인할 수 있게 하였습니다.

2-4-1. 구현중 어려웠던 부분과 새롭게 배운부분

  • 타입스크립트
    먼저, 이번프로젝트의 경우 타입스크립트를 사용하다보니 지금까지 발생하지않던 다양한 에러가 발생하였었는데 특히나 많은 데이터를 불러오는 디테일 페이지의 경우 이부분에 있어서 많은 에러가 발생하였습니다. 프로젝트를 시작하기전에도 다양한 영상강의를 보며 타입스크립트에 대해서 많은 공부를 하고 시작을 했는지만 역시 프로젝트에서는 다양한 에러를 맞닥드릴수밖에 없었습니다. 그래도 프로젝트 시작전에 어느정도 공부를 하고 돌입해서그런지 마냥 낯설지만은 않았습니다. 그리고 발생하는 에러들도 여러번 보다보니 비슷한 에러가 계속해서 발생하고 익숙해지다 보니 시간이 지나고 나서는 미리예측하고 에러를 방지할 수 있었습니다. 이렇게 몸으로 직접 체득하다보니 영상만보며 공부하던것이 어떻게 쓰여지는지 몸소 느낄 수 있었습니다. 또한 지금까지 타입스크립트에대한 지식들이 조각난 지식처럼 있었다면 이번프로젝트를 통해 조금은 타입스크립트 지식의 조각들을 붙일 수 있는 좋은 기회였던것 같습니다.

  • infinite scroll
    요즘 많이 사용되는 기능중 하나인 infinite scroll을 댓글리스트에 구현해보기로 하였습니다. 일단, infinite scroll을 처음 구현하는 상황이였기 다양한 참고자료를 찾아 보았습니다. 여러가지 방법중에 Scroll Event, Intersection Observer API를 사용하는 두가지 방법을 찾게 되었는데 이 두가지중 Scroll Event는 유저의 scrolling에 따라서 이벤트가 굉장히 빈번하게 발생하기 때문에 비교적 권장하지 않는다고 하여 infinite scroll를 사용하여 구현하였습니다. 많은 참고자료가 있었지만 처음 구현하다보니 쉽게 이해되지 않는 부분이 많았고 특히나 가장 핵심인 스크롤이 최하단부를 감지했을때 어떤식으로 작동되는지 이해가 잘 되지않았으나 여러 참고자료를 통해 직접 따라쳐보고 여러 문서들을 읽어보니 조금씩 작동원리에 대해서 이해할수 있게 되었고 어떤식으로 fetch url을 작성해야될지도 머리속에 정리가 되기 시작하였습니다. 그 결과 infinite scroll을 구현할 수 있었습니다. 구현과정까지 있어서 많은 시행착오가 있었는데 이번 기회를 통해 infinite scroll의 작동원리에 대해서 알수있었던 좋은 기회가 되었던것 같습니다.
    아래 링크는 위내용을 구현하면서 구현과정에 대한설명을 기술하였습니다.

    * infinite scroll (feat. Intersection Observer API) 링크

3. KPT

3-1 Keep

1).블로커에 대한 공유와 블로커 해결을 위한 집단지성

  • 데일리 미팅 진행시 회의록에 항상 블로커를 공유하곤 하였습니다. 이러한 블로커 공유를 단지 보고성에 그치는것이 아닌 다같이 공유하며 왜 이런 에러가 발생하고 어떠한 부분이 문제인지 같이 고민하였습니다. 그 결과 다양한 방법과 여러가지 의견에 대해서 공유할 수 있었고 다양한 의견공유를 통해 최선의 방법을 선택할 수 있었습니다. 개발자는 절대 혼자서하기 어렵고 여러 동료들과 함께 공동의 목표를 가지고 작업을 합니다. 그렇기 때문에 다양한 의견공유가 필요하고 이러한 의견공유를 통해 최고의 결과물을 도출하는 과정이 정말 중요하다는것을 다시한번 느끼게 되었습니다.

2). 공식문서를 읽고 해석해 나아가는 능력

  • 지금까지 공식문서하면 막연하게 어렵고 이해하기 어려운 문서라 잘 읽지 않고 원론적인 설명보다 쉽게 설명해놓은 블로그 글이나 오픈소스코드를 찾아서 해결하는등의 방식으로 많이 하였습니다. 이번 프로젝트를 하며 외부 API및 라이브러리를 사용하면서 공식문서를 천천히 읽어보면서 어떠한 기능들을 제공하고 어떠한 매커니즘으로 작동하는지 원리에 대해서 이해할수 있는 좋은기회가 되었던것 같습니다. 공식문서에는 해당기능이 어떠한 목적으로 어떠한 기능들이 제공되는지에 대해서 자세하게 설명이 되어있습니다. 다만, 내용이 길고 이해하기 어려운 내용이 많다보니 공식문서를 기피하는 경우가 종종 있었는데 앞으로도 이번 프로젝트에서의 경험처럼 공식문서에 대허서 읽고 해석하는 능력에 대해서 꾸준히 능력을 키워나아가야겠다는 생각이 들었습니다.

3-2 Problem

1). 타입스크립트

  • 이번 프로젝트를 통해 타입스크립트를 처음 적용해 보았습니다. 지금까지는 아무 에러없이 잘 되엇던것이 타입스크립트를 적용하니 다양한 에러가 발생하였고 해당 에러에 대해서 처음 접하다보니 생소하고 그로인해 해결하는데 다소 시간이 평소보다 오래걸리곤 하였습니다. 하지만 여러번 같은 에러를 접하다보니 어떠한 부분에서 왜 에러가 발생하는지 알 수 있게 되었고 이후에는 미리 에러를 방지할 수 있었습니다. 프로젝트를 시작하기전 타입스크립트에 대해서 어느정도 공부를하고 시작하였지만 프로젝트에 적용할때는 역시 쉽지 않았는데 막상 이렇게 에러를 직접 경험하고 해결해 나아가는 과정을 거치니 지금까지 타입스크립트를 공부하며 조각나있던 지식들이 무언가 조금은 정리되는 느낌이 들었던것 같습니다. 지금의 프로젝트를 계속 진행해 나아가며 타입스크립트에 대한 경험을 꾸준히 쌓아나아갈 예정입니다.

2). 스케줄 관리

  • 이전까지 진행하였던 프로젝트는 온전히 모든 시간을 프로젝트에 할애하였다면, 이번에 진행한 사이드 프로젝트는 말그대로 '사이드' 프로젝트이기 때문에 개인의 일정에 따라 온전히 시간적 리소스를 투입하기 어려운 팀원들도 있었습니다. 지금의 프로젝트를 계속해서 다양한 페이지와 기능들을 추가할 예정인데 이러한 스케줄적인 측면에서도 확실하게 기한네에 끝낼 수 있도록 객관적인 판단과 의견공유가 필요할것 같다는 생각이 들었습니다.

3-3 Try

1). 반응형 웹

  • display의 사이즈에 따라 반응형 웹을 구현해야된다는 생각이 절실히 들었습니다. 우리가 사용하는 디바이스는 정말 다양하고 사이즈도 다양합니다. 그렇기 때문에 반응형 웹을 통해 디스플레이의 사이즈에 따라서 다양하게 반응할수 있게 구현해야 UI/UX측면에서 더욱 더 뛰어난 웹페이지를 구현할 수 있을거라는 생각이 들었습니다. 지금 진행된 프로젝트에서 반응형 웹 기능을 추가해 더욱 뛰어난 사용자 경험을 제공할수 있도록 보수 해 나갈 계획입니다.

4. 느낀점 및 회고정리

이번 프로젝트는 이전과 다르게 다양한 도전을 많이 해 보았습니다. 그중에서도 단연 타입스크립트를 가장 먼저 꼽고 싶습니다. 프론트엔드 개발자로서 타입스크립트가 기본소양처럼 요구되다보니 단지 해야된다는 생각만 가지고 있었고 왜 필요한지에 대해서는 프로젝트를 하기전까지는 확실하게 느끼기 어려웠습니다. 하지만 프로젝트에 직접 적용을 하다보니 왜 타입스크립트가 필요한지 알 수 있었습니다. 지금까지는 단순 javascript만 써오면서 당연하게 작동되던것들이 타입스크립트를 적용하는 순간 다양한 에러를 만나게 되었습니다. 이러한 에러들을 격으면서 타입스크립트를 통해 코드의 안정성을 확보할 수 있다는거에 대해서 가장크게 느꼇던것 같습니다.
또한 공식문서에 대한 막연한 어려움이 많았는데 이번 기회를 통해 조금더 친해질 수 있는 기회가 되었던것 같습니다. 이번경우에는 시간이 조금은 걸리더라도 공식문서를 천천히 읽어가며 구현보려 많은 노력을 하였고 이러한 과정속에서 느낀것이 공식문서에는 이 기능을 왜 제공하고 어떠한 방법으로 자동이되고 어떠한 요소들을 제공하는지 하나하나 모든 설명이 되어있다는걸 알 수 있었습니다. 그래도 아직까지는 공식문서를 읽어감에 있어서 많은 어려움을 느끼고 있지만 그래도 이번기회에 공식문서가 마냥 어렵다는 편견을 조금이나마 바꿀수 있는 좋은기회가 되었던것 같습니다. 앞으로도 계속해서 공식문서를 읽어내려가는 능력을 키워 다양한 기능을 효율성 있게 구현해보고 싶습니다.

profile
step by step

0개의 댓글