[유데미x스나이퍼팩토리] 프로젝트 캠프 : Next.js 2기 - 프로젝트주차 7주차 후기

마지막 주와 성과발표회를 보면서 느낀점을 작성해보고자 한다.

 

1. Algolia 적용 실패

이번 프로젝트에서 검색기능을 구현하면서 Algolia라는 검색 라이브러리를 추가하려고 시도했다.

데이터베이스로 사용한 firebase의 검색기능은 두가지 문제점을 가지는데, 첫번째는 prefix(접두어) 검색밖에 지원되지 않고 두번째 문제는 fulltext검색/멀티 필드 검색이 안된다는 것이다. 일단 우리가 검색해야하는 데이터는 크롤링한 기사이기에 검색기능을 높일 필요가 있었다. 단순히 쿼리로 구현한 검색은 제목을 대상으로한 접두어 검색만 되었고 검색의 정밀도가 부족하다고 느꼈다.

firebase가 추천하는 추가 검색엔진은 elasticsearch, algolia, typesense였는데, 그 중 블로그 글을 보고 algoria를 선택했다.

사실 elasticsearch도 고려했지만 vercel로 배포하기로 정해진 프로젝트 특성상 도커를 쓰거나 서버를 추가해야하는 이것은 사용할 수 없었다.

그래서 선택한 것이 algolia였다. 자료를 찾아가며 구현하고 테스트는 성공했다. 하지만, 큰 문제에 부딪혔다. 기사 데이터의 길이가 너무 길어 firebase에서 algolia로 인덱싱이 안되는 것이다. algolia는 인덱싱이 가능한 용량을 제한하고 있었고, 데이터의 크롤링 결과도 정제되지 않은 부분이 있어 너무 길었던 것이다. algolia와 firebase에 추가요금을 내면 길이를 늘릴 수 있었지만, 애초에 algolia에서 인덱싱 효율과 검색 기능의 열화를 방지하기 위해 제한한 것이라 잃는 것이 많다는 생각이 들었다.

 

백엔드에서 데이터를 다룰 수 있다면 쉽게 구현할 수 있는 문제겠지만, Next.js 특성상 쉽지 않은 문제였다. 이번 기회에 firebase의 검색 기능이 부실하다는 것을 알았고, 만약 서버없이 구현하는 프로젝트라면 선택하지 않는 것이 좋겠다는 생각을 했다. firebase를 사용하는 많은 앱들이 왜 제목검색만 지원하는지도 알게 되었다.

게다가 fulltext검색은 검색의 정밀도는 높일 수 있지만 그만큼 속도를 잃게 된다. 구현을 위해 들인 시간은 아쉽지만, 포기할 수 밖에 없었다. 성과발표회의 다른 조를 보니 include 메소드를 이용해 접두어 검색만 지원하는 단점을 해결한 것으로 보였다. 그 방식이 맞다고 생각한다.

데이터를 다시 패칭해야 한다면 모르겠지만, 우리는 이미 노출하고 있는 기사가 있었고 그것을 필터링하면 될 일이기에 그 방식이 현명한 것 같았다. 물론, 이부분도 캐싱이나 렌더링 최적화가 수반될 때 가질 수 있는 이점이라고 생각한다. 검색 결과를 유지하려면 쿼리스트링으로 데이터를 보내야하고 페이지 이동이 강제되므로, 캐싱이 없다면 재렌더링이 일어날 것이기에 600개의 기사를 불러오고 그중에 필터링을 하게 되겠지만 쿼리 검색을 사용한다면 그 결과만 렌더링하게 되므로 어느정도 유리한 점이 있을 것 같다. 그 부분을 테스트해보지 않았고 데이터가 많지 않아 눈에띄는 속도차이는 없을 것이지만 CDN까지 동원한다면 include를 사용하는 것이 유리한 것이라고 본다.

 

2. 메인페이지 최적화

우리 메인페이지를 lighthouse로 분석했을 때 이상하게 퍼포먼스 점수가 낮게 나왔다. 일단 bg에 img태그를 쓰고 있는 경우도 있었고 적절한 lazy loading이 안 되었기에 효율이 안 났던 것이다. 그래서 Next/Image로 전환하고 loading="lazy"를 적용하니 10점이상 점수가 올랐다. 하지만 그 이상은 높일 수 없었는데, 메인페이지에서 사용중인 react/swiper가 좀 무거웠던 것으로 보인다.

물론 대중적인 라이브러리고 다른 최적화를 한다면, 라이브러리를 유지해도 되겠지만 다른 조의 코드를 참고해서 Marquee로 변경하니 80점을 넘길 수 있었다.

다른 조는 별다른 최적화를 하지 않았는데 점수가 잘 나왔다고 하기에 우리 코드에 근본적인 문제가 있는 것 같아 고민했지만 뾰족한 수를 찾지 못했다. 그래도 이번에 공부하면서 bundle-analyzer도 사용해봤는데, 번들의 크기를 눈으로 확인해서 번들링을 할 수 있어 최적화에 도움이 될 것 같았다. 하지만, 적당한 방법을 공부하지 못해 프로젝트에 적용하진 않았다. 블로그에서 찾아볼 수 있는 번들링 방법인 dynamic import는 최적화 초기부터 적용하려고 노력했지만 눈에 띄는 변화를 주지 못한 것이다. 이 부분은 따로 공부가 필요할 것 같다.

 

3. 성과발표회 느낀점

역시 성과발표회에 뽑힌 조들은 뭐가 달라도 다르다는 것을 느꼈다. 현직에 있다가 오신 분도 있었고 뛰어난 역량을 가진 분을을 보니 나도 더 깊이 공부해야 겠다는 생각이 들었다. 올해 전반기엔 백엔드를 하다보니 퍼블리싱 속도나 프론트에 대한 감이 조금 줄었다는 것을 체감했다. 프론트로 가기로 맘먹은만큼 저분을들 따라가려면 더 노력해야겠다.

가장 부러웠던 조는 UI 라이브러리를 제작해 npm에 올린 조였다. 현직에 있던 2분이 활약했다는 소식을 듣고 얼마나 부러웠는지 모른다. 저런 경험은 쉽게 할 수 있는 것이 아니기에 그 분들의 성과물이 좋아보였다. 물론 우리도 7쥬라는 시간동안 열심히 달려왔지만, 루즈하게 진행된 부분이 있었던만큼 아쉬움이 남았다.

 

본 후기는 본 후기는 [유데미x스나이퍼팩토리] 프로젝트 캠프 : Next.js 2기 과정(B-log) 리뷰로 작성 되었습니다.