'우리는, 방구석에서 여행한다' 프로젝트 리뷰

jh_leitmotif·2022년 1월 23일
0

Projects

목록 보기
2/2
post-thumbnail

숨 가쁘게 달려온 지난 2주였습니다.

사실은 썸네일의 치즈덕처럼 욕심이 그득그득했던, 팀원들과 함께 벼랑 끝에 서고 싶었던 프로젝트였지만 항상 그렇듯 걷어내고 또 덜어냈습니다.

그렇지만 '이 정도면 됐지...'라는 마인드없이 모든 팀원이 그 때 그 때 최선을 다했다는 점은 굉장히 만족스럽습니다.

특히 발표 중 꼭 사이트를 배포해달라는 멘토님의 채팅을 보며

아, 그래도 내가 쳇바퀴만 돈 것은 아니었구나.

라는 생각을 하며 안도하기도 하고, 더 잘할 수 있었던 것들에 대한 아쉬움을 곱씹어보기도 했습니다.

잘했던 것도 있고 두고두고 아쉬운 것도 있던 프로젝트 리뷰, 시작합니다.


📺 Demo

Thanks to Cullen, 녹화해줘서 고마워요!

📋 Info

Repo : https://github.com/KimJeongHyun/28-2nd-BANGGUSEOK-Traveller-frontend
Figma : https://www.figma.com/file/8hd0ZB7Bu6606dcG4ZYilq/BANGGUSEOK-Traveller

본 포스팅에서는 프로젝트를 진행하며, 강한 인상으로 느낀 것과 반성점을 기록합니다.

기술적인 내용은 Repo의 README.md를 참고해주시기 바랍니다.


🙌 What 'We' Did.

https://www.awwwards.com/

  • 저작권 문제가 있을 수 있으므로, 링크로만 첨부합니다.
어떤 프로젝트가 하고 싶어요?

라는 물음에, 제가 내놓은 레퍼런스 사이트였습니다.

기본적인 기능들은 모두 내포하고 있으면서도, 쉽게 접해보지 못했을 법한 애니메이션들이 많아 맘에 들었습니다.

무엇보다도 많이 복잡해보이는 쿼리스트링은 꼭 해보고 싶은 분야였는데다가, 백엔드와 소통할 때 어떤 방식으로 대화를 나눠야 그것이 배려가 될까? 라는 고민을 해결해줄 수 있을 것 같았습니다.

다만 사실 저작권 문제가 컸고, 난이도도 매우 어려워 기대하지 않았지만 아이고, 오히려 '기획도 해보라!' 라는 취지로 선정이 되고야만 것입니다.

같은 팀이 된 팀원분들께는 미안했지만... 뭐 어쩌겠는가!

어렵겠지만... 제가 미친듯이 끌고 갈게요! 각오하세요 ㅋㅋ

기획

코로나 끝나면.... 다들 어딘가 여행은 갈거잖아요?

마스크가 어느새 너무나 정상스러워진 지금, 다들 마음 한 구석에는 '휴양지 가고 싶다...' 이런 생각을 하고 있지 않을까? 라는 발상이 있었습니다.

또한 그저 코딩하고...이런 거 했어요!!! 라고 자랑하며 끝내는 것이 아니라 관객들과 서로 소통할 수 있는 하나의 '서비스' 를 만들고 싶었던 우리 팀은

각자의 카카오 계정으로 로그인할 수 있고, 여행지에 대한 투표도 해볼 수 있는 그것.
'방구석 Traveller' 를 만들었습니다.


🤚 What 'I' Did

역할 : Project Manager

구현 사항
 재사용 컴포넌트
  1. 커스텀 페이지네이션 버튼
  2. 카카오 소셜 로그인 기능 구현 with Kakaotalk login REST API
  3. Not Found 페이지
  4. 별점 서클
  5. 네비게이션 바, 로그인 여부에 따른 버튼 전환 with Recoil
  6. 네비게이션 바, 푸터 Outlet을 통한 선택적 적용
  7. 스켈레톤 UI
  8. 경로 이동시 자동 스크롤 업

 필터 페이지
  1. 커스텀 쿼리 조합기
  2. 커스텀 페치 훅 ( 미사용으로 Deprecated )
  3. 백엔드와의 쿼리 통신
  4. Nested Routing with react-router-dom v6

 최종 발표 전, 전체 리팩토링 진행
  1. Link가 되지 않는 요소들 전체 수정
  2. 정상적이지 않은 동작을 일으키는 로직 삭제
  3. 완성에 저해될 가능성이 있는 기능 배제

기술적인 이야기들은 리드미나, 이미 포스팅된 것, 그리고 추후 포스팅될 것에 담을 예정입니다.


🥺 고민들.

이번 프로젝트에서는 사실 기술적으로 크게 문제가 있었던 부분은 없었지만 Agile을 저번 프로젝트와 다르게하면서 느꼈던, Recoil을 사용해보면서 느꼈던, 그리고 백엔드와의 대형 블로커를 해결해나갈 때 했던 고민들이 제일 먼저 떠오릅니다.

Agile은 무엇일까?

전공자인 저는 학부시절, 여러 프로젝트 경험이 있었습니다.

그 때도 애자일하게... 애자일하게... 이런 얘기를 달고 살았었던 것 같은데 돌아보면 다 실력도 비슷한 사람들끼리 몰려다니니, 서로의 한계가 어느정도인지 알리도 없고 그저 말만 번지르르 했었구나 싶네요.

저번 프로젝트와 마찬가지로, 이번 프로젝트도 PM을 맡으면서 정했던 규칙이 있었습니다.

1. 어려운 것이 있다면 '무조건' 물어보고 같이 해결하세요. 
2. 회의할 때 기술적인 부분은 절대 금지! 따로 시간 내서 해주세요
3. 프론트가 백에게, 백이 프론트에게 요구해야될 것이 있다면 꼭 저를 거쳐주세요.

유일하게 3번에 대한 규칙만 달랐던 부분입니다.

학창시절과 다르게 각 팀원들의 속도에 편차가 있다는 것을 고려하여, 제 스스로 컨트롤 타워가 되어 각자의 진도를 확인하며 쳐낼 것은 쳐내고, 추가할 것은 추가하자! 라는 마인드였죠.

좋았던 것은 전체적인 흐름을 읽고 파악하기에 이 프로젝트에 온전히 내 자신이 기여하는 바가 있다는 부분에 몸은 힘들었지만 열정적으로 다가갈 수 있었다는 점입니다.

그와 동시에, 팀원이 저를 거쳐서 2중으로 소통해야된다는 부분이 오히려 어떤 부분에서는 저에게 팀원들이 의존하게 되는 형태가 만들어진 것도 같고, 어쩌면 마지막에 눈물을 머금고 삭제했던 기능도 이러한 소통 형태가 아니었다면 살릴 수 있지 않았을까... 하는 아쉬움이 남아있습니다.

결론적으로 느낀 것은, 그러므로 애자일은 빠르게 쳐낼 것은 쳐내고, 붙여야할 것은 유기적으로 붙이면서 고객의 요구사항에 다가가는 사전적인 의미와 동시에, 모든 팀원들이 서로 높고 낮음없이 동일한 책임감을 가지면서 모두가 PM으로서 나아가는 것이 아닐까? 라는 생각을 했습니다.


Recoil을 통해 했던 고민.

여러가지 컴포넌트들이 많이 분기되어 있고, 각각 공통된 props를 가질 때
Context api를 통해 각 컴포넌트에게 모두 전달할 수 있습니다.
그런데, context마저도 뚱뚱하다면 어떡해야할까?

(이건 호머 심슨도 못먹어!!!!)

멘토님이 해주신 말 중, '왠지 모르게 쎄하다면 고민해보라' 라는 이야기가 있었습니다.

일단은 기능하는지 보자...라고 해놓고 보니 운동을 시켜줘야겠다.. 라는 생각이 들었습니다. 물론 props drilling이 일어나는 것보다야 훨씬 낫지만 그것을 해결하기 위한 Context마저도 밥먹다 체할 것 같았던 겁니다.

그래서 저는 Recoil을 사용했습니다.

Context가 반쪽이 되었!!...지만 맘 구석 불편함은 가시지 않았습니다.

Recoil은 전역 상태를 관리하는 패키지인데 필터 페이지에서만 쓰일 state를 전부 다 올리는 것이 맞나..? 이거..아니지 않나? 라는 생각이 든 겁니다.

스스로 내린 결론은 아래와 같았습니다.

예를 들어, user token은 유저의 '인증서'의 효과를 보이기에
전역에서 관리되는 것에 일리가 있다.

그러나 위와 같이 Filter와 관련된 state들은 다른 컴포넌트에는 쓰이지 않을텐데
'굳이' Recoil을 사용해서 그것들을 분리해야했을까?

고작 코드 한 조각 깔끔하자고, 그 컴포넌트의 의도를 저해하는 것이 옳은 방향인가?

멘토님과도 이 주제로 거의 30분 정도 대화를 나누었는데 역시 제 생각과 거의 유사한 방향으로 말씀을 해주셨습니다.

알고 있다고 해서 남발하진 않잖아요.
우리가 닭 잡을 때 소 잡는 칼을 쓰던가요?
오히려 방법을 알고 있다면, 담백하게 가지 치는 것도 필요한 것 같아요.

관연 내가 하려는 것이 이 컴포넌트에서 충분히 일리가 있는 것인가?
선언한 state나 상수가 꼭 필요한지, 그리고 그에 대한 side effect는 일어나야만 하는 것인지에 대해서. 제 자신이 쓴 코드가 과연 맞는 방향인가? 에 대해서 계속 의구심을 품고 가야겠다.

라고 생각했던, 어떻게 코딩해야하는가? 에 대해 한 발 더 나아간 Recoil 사용기였습니다.


나는 백엔드를 배려했을까?

프로젝트가 시작한지 1주일이 지나고, 2주차에 접어들었을 때.

어떤 팀보다도 빠르게 소셜 로그인 통신에 성공했기에 어쩌면 목표를 초과달성할 수 있지 않을까? 라는 기대에 부풀었습니다.

그러나, 주력 서비스에서 가장 큰 힘을 발휘해야했던 저의 영역인 필터 페이지에서 제가 생각했던 요청데이터와 백엔드에서 생각했던 자료형태가 전혀 달랐던 것입니다.

내가 생각했던 쿼리
?conti=아시아&area=강&theme=휴양&person=가족여행
백엔드 팀원이 생각했던 쿼리
?tagcategory=대륙&tag=아시아

나름 SQL 쿼리를 사용해본 경험이 있던 저는 머릿속으로,

SELECT * FROM products 
WHERE (category='conti' or category='area')
and
(tag='아시아' or tag='강')

이러한 생각에 이르렀고, 실제 레퍼런스 사이트에서도 위의 움짤에서 보여지듯 key=value& 패턴이 반복되는 형태였습니다.

쿼리를 조합하는 것은 커스텀 훅으로 구현했습니다.
자세한 설명은 여기 에 정리했습니다!

하지만 백엔드의 영역에서는 이것이 꼭 올바른 표현은 아니었던 것입니다.

사실, 키를 하나하나 받아와서 or에...and에...or에... 이러한 표현은 생각해보니 지양해야 할 법한 하드코딩의 영역이라고 생각이 듭니다.

덕분에 제 짝지였던 백엔드 팀원분의 크나큰 블로커가 시작됐고, 다행히도 모델링을 건드리지 않고도 가능한 방법이 찾아 원만히 합의(?!)를 보게 됐지만 애초에 찰떡같이 목업데이터가 구성됐다면 어땠을까 라는 아쉬움이 남은 겁니다.

너무나 고통스러웠던... 오전 10시부터 오후 10시까지 해결이 안되서, 집에가서도 했던 이것은 결국 그 다음 날 오전 1시가 되서야 해결됐습니다.

결국 저의 자료 형태에 따라 쿼리를 날리도록 결정됐지만, 백엔드 쪽 멘토님과 이에 대해서 의견을 나누어 보았습니다.

Me 
 : 어.. 생각해보니 로우 쿼리 단 시점에서 하드코딩스러운 자료형태였네요.
차라리 tagcategory와 tag라는 키는 그대로 두고 제가 리스트로 값을 전달하는 건 어떨까요?
그렇다면 서로 키/값을 엄격하게 맞출 필요없이, 어떻게 보면 리스트의 인덱스로만 제어가 가능하니까요.
또 카테고리와 태그마다 고유한 id가 있을테고, 
그것을 프론트엔드에서 정렬 등을 이용해 미리 처리해서 넘겼다면
이렇게 하루가 날아가버릴만큼의 블로커는 없지 않았을까요?

백엔드 멘토님
 : 정현님이 생각한 부분이 일리가 있어요. 현재 형태로 SQL에 조회를 한다고 한다면
결국 Q객체의 Q객체의...Q객체의...Q객체의... 이런식으로 체이닝이 일어나기 때문에 비효율적이죠.
말씀하신대로 리스트 형태로 자료를 전달한다면, 
또 전달된 자료가 sorting되어서 몇 번째 인덱스가 어떤 카테고리이며
어떤 태그가 선택되었는지를 알 수 있도록 합의가 되었다면 좀 더 깔끔했을 것 같습니다.

분명 초기에 서로 맞춰보면서 잘 해보자! 라고 말했던 기억이 있지만
부끄럽게도 그러지 못했던 부분이었습니다.

서로 할 일이 너무나 많았기 때문이라는 명목은 있으나,
앞으로의 수 많을 프로젝트에선 정신 똑바로 차리자, 좀 더 공부해서 상대를 배려할 줄 아는 개발자가 되어야겠다 라고 생각하게된 이번 프로젝트의 가장 큰 고비였습니다.


🙅‍♂️나는 '명치맨'이었다.

차근차근 정리하며 되돌아보니 팀원들에게 비수를 꽂은 때가 많았다, 라는 생각도 듭니다.

어... xx님. 이거는 이렇게 구현하는게 아니라, 어쩌구...저쩌구...
xx님! 너무 잘해주시긴 했는데, 의도와 맞지 않는 것 같습니다..
제가 생각하는 부분은 이러한데 만약 바꿔야한다면 가능하시겠어요??
xx님, 혹시 이거 언제 되는 거에요?
아니 이거... 이렇게 쓰지 말라 했잖아요 ;;;

원래 오전 10시부터 오후 7시까지 달리는 스케줄이지만 거의 항상 집에 와선 새벽 서너시까지는 꼭 무언가 팀원과 이야기하면서 의견을 나누곤 했습니다.

언젠가 한 번은 백엔드분이 열심히 구현해둔 로직이 기능은 하지만 생각과 다르다는 이유로 멈추고 다른 방향으로 말씀드렸던 적이 있었습니다.

마찬가지로 최종 발표 전날, 테스트해보니 잘못 동작하는 기능이 있었는데... 해당 팀원의 컴포넌트 설계 미스로 단기간에 리팩토링이 불가능한 상태라 따로 공부해서 수정하라고 말씀드리고 일단 보여질 수 있는 방향으로 바꿔버린 경우도 있었습니다.

더군다나 막바지에 다다랐을 땐 잠을 잘 못자다보니 최종 리팩토링을 하다가... import 순서나 컨벤션이 정한 것과 약간 틀려도 예민하게 군 것 같기도 합니다.

어떡하지, 저는 저도 모르게 명치를 꽂고 다닌 것은 아니었을까요?


🎯 그럼에도 불구하고...

일단.. 저번 프로젝트 때 담당하셨던 멘토님께서 지나가다 대뜸

정현님 엄청나게 많이 늘은 거 스스로 느껴지세요?

라고 들었을 때 느꼈던 출처를 알 수 없었던 희열감.

또 항상 위의 사진처럼 긍정적으로 피드백해주시면서도 마냥 좋다는 것이 아니라, 중간중간 놓쳤거나 몰랐기에 쓰지 않았던 것을 잘 잡아주셨던 이번 프로젝트 담당 멘토님의 리뷰들.

이미 기간이 지나버려서... 하나의 DM 밖에 남지 않았지만 팀원분들이 꼭 커피 한 잔씩 내 자리에 갖다두곤 했던 배려들.

그런 것들이 하나하나 모여서, 물론 처음 욕심 가득히 생각했던 그것과는 차이가 있는 결과였을지라도 소중히 얻어간 것이 많은 프로젝트, '방구석 Traveller' 였습니다.

이런 기억들을 꾹꾹 담아, 더욱 좋은 개발자가 되어야겠습니다.

profile
Define the undefined.

0개의 댓글