[토이 프로젝트] 솔로몬 Day 3

도깨비젤리

·

2021. 6. 18. 13:43

들어가는 말


이때까지 열심히 달려온 결과, 기능 구현뿐만 아니라 배포까지 완료했다. 따로 서버를 돌리는 프로젝트가 아니였기에, 배포는 간단히 깃허브 페이지로 뿌려주는 것으로 완료했다. 오히려 배포하는 것보다 이걸 자동배포로 바꾸는게 더 어려웠다...

 

아무튼, 이제 ui만 꾸며주면 정말로 프로젝트가 끝나게 된다. 주말에 빡세게 달려서 끝매듭을 짓고 싶은 마음이 굴뚝 같은데, 나랑 A 둘 다 이번 주말에 코테가 있어서.... 마무리 짓는 건 조금 나중으로 미뤄둬야할 것 같다.

 

현재 프로젝트은 이런 모습이다.

 

검색 조건에 들어맞는 게임이 있는 경우

 

사용자의 입력과 완벽히 일치하지 않는 경우, 비슷한 장르의 게임을 추천해준다.

 

 

 

TIL


1. 프로그램을 미리 예상하지 마라.


추천 페이지의 댓글 시스템을 짜고 있을 때였다. 나는 문득 "나중에 이 앱에 사용자들이 많이 몰리게 되면, 댓글도 많이 달릴텐데, 모든 댓글이 한 페이지 주르륵 나오면 보기도 안 좋고, 댓글 달려는 사용자들도 스크롤을 이빠이 내려야하니까, 사용자 경험이 떨어지지 않을까?" 라는 생각을 하게 되었다.

 

그래서 나는 댓글 창에 페이지네이션을 달아서, 댓글의 일부만 화면에 표시되게 만들기로 하였다. 그런데 여기서 문제가 발생하였다.

 

 

Dynamo DB에 댓글 조회를 요청했을 때의 응답

 

여태까지 나는 댓글들을 그냥 땡겨온 다음에 JSON.parse로 읽어낸 다음 양식에 맞게 뿌려줬는데, 자세히 보면 저장되어있는 댓글들이 시간순대로 정렬되어 있지 않다. 자세한 동작 방식은 모르지만, 서버에 POST 요청을 날리면 body에 마지막 부분에 push 되는 것이 아니라, 마치 파이썬의 set 자료형 처럼, 추가된 댓글을 포함하여 임의로 재구성하는 것으로 보였다.

 

그래서 서버에 체계 있게 저장하는 방안을 A랑 같이 찾아봤는데, 명쾌한 방법을 찾지 못했다.

결국, 저장되어 있는 댓글을 땡겨온 다음, pagenation 을 적용할 수 있도록 프론트 단에서 자료를 가공하기로 하였다.

 

지금 다시 생각해보면 이 때부터 뭔가 잘못되었던 것 같다. 

 

 

아무튼, 디테일 페이지에서 pagenation은 다음과 같이 구현되었다.

 

 

위에서부터 순서대로 1,2,3

 

1. 서버에서 댓글 전체를 땡겨온 다음, 배열에 저장한다

2. _.chunk()를 이용하여 댓글을 n개 단위로 자른다. (여기서는 3개 단위)

3. 그 자른 배열을 adjustedReviews라는 객체로 다시 저장한 다음, 현재 페이지의 댓글 state를 adjustedReviews.pageReviews[현재 페이지 - 1] 로 설정한다.

 

 

 

현재 페이지도 useState를 이용해 관리하였다

4. Material-ui의 Pagination 컴포넌트에 onChange 이벤트를 달아 pagenumber가 변경될때마다 현재 페이지 = pagenumber가 되도록 하였다.

 

 

 

이렇게 임시변통으로 페이지네이션을 구현하고 뿌뜻해하고 있을 무렵, 우리의 삽질을 지켜보고 있던 친구 B (a.k.a MS에 미친남자) 가 말했다.

 

 

B : "야 젤리야, 너 이거 왜 만든거냐??"

나 : "응?? 아니 이거 나중에 사용자 많아지면 댓글 많아질텐데, 그 때 댓글 드르륵 달려있는 모습 보면, 사용자들이 불편해할거 같아서, 페이지네이션 달아서 좀 편의성을 높인거지.

B : "그래? 그럼 뭐 사이트 성능과는 무관한 기능이라는거지?? 너 지금 짜는거 보니까 그런거 같은데"

나 : "그렇...지? 일단 페이지 랜더되면 댓글 전체를 땡겨오고 그걸 가공하는거니까, 오히려 비용이 더 들지?? 필요한 부분만 받아올수가 없으니까 어쩔 수 없는거지"

B : "그렇지?? 그럼 페이지네이션 없애라."

나 : "???????"

 

실컷 열심히 만들었는데, 이걸 없애라고?? 이게 왠 홍두깨 같은 소리인가...했는데, 요지는 이거였다.

 

절대 프로그램을 예상하고 코딩하지 마라. 필요하다면, 필요한 시점에 만들어라.


 

나 : "야 근데 그 얘기는 내가 배웠던 내용이랑 완전 다른데?? 설계와 구현을 할 때 이후의 확장성까지 고려해서 코딩하라고 배웠단 말이야"

B : "그치 그건 맞지. 근데 확장성을 고려해서 설계하는거랑 실제로 기능을 확장해버리는거랑은 달라. 너 애초에 이 프로젝트 시작한 이유가 뭐야. A랑 쿵짝 빠르게 맞춰서 배포해보고, 나아가서 포폴로 쓸라고 했던거 아니야? 그럼 거기에 집중을 해야지. 벌써부터 서비스 커졌을때를 생각하면 안된다고. 너 지금이야 이 정도 기능이야 라고 생각하는데, 나중에 회사에서도 그런다고 생각해봐라. 얼마나 리소스 낭비야 이게.. 처음에 구현하려고 하는 기능만 구현하는게 리소스 측면에서 더 효율적이라 이거지."

 

 

듣고보니 일리가 있습니다??

 

 

 

 

그렇게 pagination 기능을 제외하기로 하고, 따로 브랜치로 빼버려 추후 서비스가 진짜로 대박을 쳤을때 도입하기로 결심했습니다.

 

 

🔥Day 3을 마치며🔥


pagination 때문에 삽질하는거 빼면 구현상의 어려움은 따로 없었습니다. 오히려 깃허브 페이지 자동배포 하는게 더 정신 없었습니다. 단계 하나하나 넘어갈때마다 얼마나 조마조마했는지ㅋㅋㅋ

 

제발 빌드 되라 제발

 

 

 

이렇게 자동배포까지 완료했으니, 이제는 스타일만 이쁘게 꾸며주면 될 거 같습니다. 아마 다음주 중으로 진짜진짜 마무리가 되지 싶은데, 이번주는 UI 설계하는 것보다는 주말에 있을 코테에 집중해야겠습니다.