[회고📓] 우당탕탕 💨 2차 프로젝트를 돌아보며

힘들지 않아 거친 세상 속에 뛰어든 건 나니까 암오케

 
1차 프로젝트를 마치고 잠깐의 휴식 기간(a.k.a 공부시간)을 가진 이후에 바로 2차 프로젝트에 돌입했다

순탄했던 1차 프로젝트와는 달리 2차는 정말 우당탕탕 고난의 연속이었는데...

단기간에 고생도 많이 하고 새로 배운 것도 많은 프로젝트였기에 회고를 남겨본다
 
 

---

목차

• '매화를 찾아서' 프로젝트
  • 프로젝트 소개
  • 개발 기간 및 인원
  • Jira & Figma
• 2차 프로젝트를 마치며
  • 잘한점 / 아쉬운점
  • 마무리

 

---

'매화를 찾아서' 프로젝트

 

 

🏃 '매화를 찾아서'는 어떤 서비스일까?

이번에 참여한 프로젝트 '매화를 찾아서'는 지도로 내 주변 화장실을 발견하고 필터링이나 리뷰를 통해 나에게 더 맞는 장소를 찾을 수 있는 서비스이다. 에어비엔비의 지도 및 필터링, 리뷰 기능을 벤치마킹하되 새로운 기획을 더해 구현되었다. 화장실을 찾는 유저 특성상 이동하면서 서비스를 이용할 것임을 감안하여 모바일 레이아웃으로 구성되었다. 

• '매화를 찾아서' 프로젝트가 궁금하다면? 깃허브 바로가기

 

📅 개발 기간 및 인원

 2주 동안, 2명의 백엔드와 3명의 프론트엔드 총 5명의 팀원이 함께 하나의 서비스를 구현했다. 
지난 번에 PM(Product Manager)를 이미 맡았기에 이번에는 다른 분께 양보하고자 했으나... 다른 분들의 추천으로 재차 같은 PM을 맡게 되었다. 프론트엔드 역할과는 별개로 PM을 하면서 지난 번보다 훨씬 구체적인 기획을 통해 서비스의 방향성을 잡고, 구현 프로세스를 총괄하고, 발표를 진행하는 역할을 담당했다.

 

 

⏳ 할 일은 다 했는 Jira ? 

우리 팀이 사용한 Jira의 타임라인 대시보드

 

지난 프로젝트에 비해 팀원 수도 더 많아지고, 기획한 부분도 더 많아지면서 일정을 더 체계적으로 관리할 필요성을 느꼈다. 저번에 사용했던 Trello의 경우 직관적으로 일정을 관리하기 쉬웠던 점은 좋았지만 다소 심플한 감이 있어서 타임라인이 있는 서비스를 찾던 중, Jira를 발견했다. 다른 팀원들 역시 실무에서 Jira가 많이 쓰인다는 사실로 인해 도입을 찬성했기에 바로 해당 툴을 채택하게 되었다. 

 

백로그에 할 일을 세분화된 티켓으로 나눠놓고, 레이블로 프론트엔드와 백엔드를 구분했다. 그리고 할 일, 진행중, 리뷰중(In PR), 완료(merged) 네 가지를 기준으로 분류해서 태그를 달아 현재 진행사항을 보드에서 한 눈에 볼 수 있도록 했다.

 

유용했던 기능은 에픽인데, 전체적인 프로젝트의 타임라인을 설정해서 파트별로 확인할 수 있다. 우리는 세 명의 프론트엔드가 다양한 기능을 짧은 기간동안 동시에 구현해야 했으므로, 다소 타이트한 일정을 잘 소화하기 위해 타임라인을 가시화해서 작성했다. 추가로 중반에 중간 점검 시간을 넣어 진행사항을 체크할 수 있는 시간도 할당해두었다. 

 

 

 

🎨 Figma, 더 잘써보자!

같은 기수 분들께 늘 피그마를 영업하던 나,, 결국 빛을 보았다✨
1차 프로젝트에서 눈에 보이는 시안이 없어서 디자인이 서로 달라졌거나 다소 헤맸던 부분이 있는 분들께서 내게 피그마 사용법에 대해 물어오셨고.. 어느새 돌아보니 대부분의 팀에서 피그마를 사용하고 있었다! (피그마 직원도 아니지만 괜히 뿌듯 👀) 

 

물론 이전에 피그마를 무리 없이 잘 쓰고 있는 편에 속했으나 이번에는 더 잘 사용해보고 싶은 욕심이 생겼다.

이전 프로젝트는 벤치마킹할 원본 웹이 있었지만 이번에는 완전히 새로운 서비스를 만드는 것이었기에, 실제 서비스와 거의 동일한 수준의 완성도 높은 시안이 필요했다. 또, 2D 시안으로는 참고할 수 없는 유저 플로우나 액션과 같은 부분을 프로토타이핑을 통해 구현하면 팀원들의 혼란을 덜 수 있을 것이라 생각했다.

 

 

최종 시안을 만들어나가면서 프론트 팀원별로 본인의 역할을 빠르게 파악할 수 있도록 색상 영역을 통해 분리했다. 

또, 모바일 프로토타이핑을 진행해서 재생만으로 어떤 버튼을 클릭하면 어디로 가는지, 이동시 애니메이션은 어떤 방향으로 얼마나 나오는지, 유저 플로우는 어떻게 이루어져있는지 등을 쉽게 확인 가능하도록 구성했다.

---

 

구현한 서비스 소개 👀

 

🐥 카카오 소셜로그인과 씨름하기

• 전반적인 소셜 로그인 과정을 이해하는게 초반에 어려웠다
• 카카오로부터 ok를 받고 또 백엔드 서버로부터 ok를 두 번 받는 과정이 머릿속에 잘 그려지지 않아서 혼자서 그림도 여러 번 그리고 직접 손으로도 써가면서 가시화하려고 노력했다. 나중에는 사람들한테 소셜로그인 쉽게 설명하기 챌린지를 혼자 만들어서 시행하려는 단계에 이르렀을 정도... ㅋㅋㅋㅋㅋ

 

🗺 카카오맵과의 치열한 사투

• 이전에 카카오맵으로 지도를 구현한 적이 있었다. 그래서 이번에 지도를 구현할까 말까 고민하다가.. 지난 번에 내가 만든 코드를 다시봤는데 그냥 자바스크립트 코드 그대로 가져온 것이지 리액트라고 보기 어려웠다. 이번에야말로 제대로 진행해보고 싶어서 지도를 하고 싶다고 어필했고, 이전에 만들어본 적이 있으니 시간이 단축될 것 같다는 의견으로 내가 담당하게 되었다. 
• 실제로 지도를 구현해보니 리액트에 적용하기가 어려웠다. 카카오에서 제공하는 샘플 코드는 자바스크립트에다가, 예전 문법을 많이 사용하는 것처럼 보였다. 게다가 자체적인 문법도 있어서(ex. addListener) 이를 잘 활용할 줄 알아야 했다. 초반에 많이 어려웠던 것은 지도를 처음에 그릴 때 map 컴포넌트를 하나만 그리는데, 그 안에 보이지 않는 marker나 info window 등의 요소를 꺼내서 사용해야 할 때였다. 태그로 보이지 않으니 어디서 어떻게 가져와서 사용해야 할지 가늠이 되지 않았고, 자꾸만 '대상을 찾을 수 없다'던지, '해당 대상에 ref를 걸 수 없다'던지, '얘한테는 style 못 줌' 이런 식의 에러가 사방에서 펑펑 터졌다. 
• 그래서 어떻게 해결했나? 하면... 결국 힘들게 찾던 녀석들을 컴포넌트로 분리했다. 지도를 그리는 컴포넌트, 마커 컴포넌트, 네비게이터 컴포넌트 등.. 여러 개의 요소를 다 별개의 컴포넌트로 분리하여 최상단에서 state를 관리하면서 관계가 꼬이는 일이 없도록 했고, 렌더링 순서를 주의깊게 고려하면서 useEffect를 잘 활용하려고 애썼던 기억이 난다. 
• 지도를 만들면서 오히려 지난 번에는 쉽게 만들었던 기능이 이번에는 더 어렵게 느껴졌던 점이 많이 당황스러웠다. '왜 저번엔 했는데 이번엔 못하지?'라는 생각에 퇴보한 기분이 들어 좌절감이 들기도 했다. 그러나 돌아보면 이번에 지도 구현이 어려웠던 이유는 자바스크립트 샘플 코드를 그대로 가져오는 것이 아니라 리액트에 맞춰서, 직접 DOM에 접근하지 않고 효율적으로 기능을 구현하고자 하는 의지가 강했기 때문이라고 생각한다. 구현 과정에서 어려움이 많았지만 결론적으로 리액트를 구성하고 있는 여러 문법적인 부분에 대해 깊이 이해할 수 있는 기회였다고 느꼈다. 

 

 

♾️ 처음 만난 무한스크롤

• 장소 리스트에서 예정에 없던 무한스크롤을 구현하게 되었다. 백엔드 팀원과 얘기하다가 메인 페이지에서의 장소를 무한스크롤로 구성하자는 의견이 나왔다. 이 경우 백엔드에서 offset limit 값을 설정해서 한 번에 몇 가지 장소가 보일지를 설정하면, 프론트단에서 그 값을 받아서 쿼리스트링에 적용시키는 방식을 사용하기로 했다. 쿼리스트링이야 지난 프로젝트에서 필터링을 하면서 익혔기 때문에 크게 어렵지 않을거라고 생각했는데, 처음 접한 무한스크롤이 꽤나 어려웠다.
• 무한스크롤을 처음에는 easy infinite scroll을 시도해봤는데.. 역시 다들 Intersection Observer를 사용하는 데에는 이유가 있었다. 자료나 예제가 많지 않아 활용하기가 어려웠고, 공식문서도 내용이 충분하지 않아 사용하고자 하는 부분에서 막힐 때가 많았다. 반면 Intersection Observer는 처음에 낯설어서 조금 어렵긴 했지만 한 번 쓰니 넘 편했음! 그런데 Intersection Observer와 debounce를 함께 사용하려고 시도하다가 무한렌더링 문제가 발생해서 이를 해결하기가 조금 어려웠다. 나중에 확인해보니 두 가지를 같이 쓰면 문제가 발생할 수 있다고 하는데.. 이 문제에 대해서는 차차 다뤄볼 생각이다. 

 

---

 

첫 프로젝트를 마치며 

 
이곳에서는 프론트엔드 개발자로서 참여한 첫 팀 프로젝트이자 처음으로 Product Manager도 맡았는데, 좋은 기억도 많았지만 한편으로는 꽤나 아쉬움이 남는다. 어떤 점이 아쉬웠고 또 어떤 점은 스스로 칭찬해줘야 할 지 아래에 작성해본다.
 

아쉬운 점 

• 백엔드와의 소통 및 조율 (뎁스가 너무 깊어지는 점, 갑자기 api 구조가 바뀐 점..)
• 갑작스러운 변화에 당황해서 막판에 멘탈이 갈림.....  -> 침착하게 즐길 줄 알아야 함!
• 카카오맵-> 리액트 도입 과정에서 엄청 헤맸는데  kakao map react sdk 라이브러리를 나중에서야 발견했다.
• 공식 문서만을 보고 이해할 수 있는 능력을 키우자.
• 팀 작업을 할 때에는 늘 시간이 모자라다. mvp를 먼저 개발하고, 그 후에 기능을 붙여나갈 것. 시간 안배가 생명!

 

그럼에도, 잘한건

• 발표에 다른 팀원들(프론트엔드, 백엔드 모두)의 이야기를 더 녹이고자 함
• 특히 백엔드의 경우 한 명 한 명 구현한 내용에 대해 인터뷰하고 모르는 용어나 개념이 있으면 이해할 때까지 설명을 들어가면서 익힘.
• 프로젝트 기간 중 지속적으로 프론트 및 백엔드 팀원 간의 진행사항을 트래킹함
• 새로운 기획이라 고민하거나 결정해야 하는 부분이 많았지만, 순간순간의 판단이 나쁘지 않았다고 판단! (ex. 디자인 라이브러리 사용하기, recoil 도입, 팀원별 파트 분배 등)  

 

마무리 

두 번째 프로젝트에서는 주어진 레퍼런스를 참고하는 것이 아닌, 새 프로젝트를 기획하고 또 구현하는 과정을 선택했다. 그렇기 때문에 그 과정에서 참 많은 고민이 있었던 것 같다. 새로운 프로덕트를 만들 때 얼마나 시간이 소요되는지, 라이브러리나 도구는 얼마나 도입해야 도움이 될 지, 나를 포함한 우리 팀원들이 새로운 것을 받아들일 때 발생하는 러닝커브는 얼마나 있을지 등을 (기존 데이터가 적기 때문에) 정확히 파악하는 것이 꽤나 어려웠다. 그럼에도 불구하고 도전정신을 발휘해서 다른 팀과는 또 다른 길을 걸었기에, 그로 인해 남들보다 더 깨닫고 배운 것이 많지 않았을까, 라는 생각이 들었다. 용기를 내서 도전하지 않았더라면 얻기 힘들었을 경험을 할 수 있어서 좋았고, 또 그 경험에 팀원들과 함께 나아갈 수 있어서 보람찼던 프로젝트였다. 중요한 것, 한계를 뛰어넘기!