[프로젝트 기록] Next.js 의 SSG 는 너무 느려서 못써먹겠다.

프로젝트 기록입니다.

 

배경 지식 

23년도에서 24년 넘어가던 때에 저희 회사에서 모든 부동산 자산에 대한 어떤 정보를 제공하기 위한 페이지를 기획했었습니다.

저는 이것이 마케팅 비용이 없이도 효과적으로 검색 유입을 늘릴 수 있는 수단으로 생각하여 SEO에 신경써서 개발하였고.

이런 것들을 이미 염두하여 Next.js 로 개발하고 있었기 때문에 SSR, SSG 를 적극 검토했었습니다.

 

자산의 종류는 토지(땅만), 토지건물(땅과 건물. 그러나 동,호는 없음), 집합건물(동,호가 존재) 이렇게 3종류가 있습니다.

각 자산은 고유 번호인 pnu 를 붙여서 관리하고 있고. 

집합건물은 pnu + 각 동에 대해 dongBpk, 각 동의 호에 대해 hoBpk 를 가집니다.

 

사실 SSR 를 쓰면 정말로 뭘 할 것도 없이 간단한데요.

SSG를 검토했던 이유는 사용자가 폭발적으로 늘어날 것을 기대하여 불필요한 API 요청들을 줄여보고자 하는 노력이었습니다.

또한 검색엔진에 전달해야하는 주소가 매우매우 많았기 때문이기도 하고요.

 

테스트 결과

Next.js v13으로 서울지역의 토지, 토지건물, 집합건물 각 100개를 SSG(Static Site Generation) 정적페이지 생성을 했을때

300건에 대해서 대략 1분이 걸렸습니다. 3만건만 해도 100분이었습니다.

 

계획 변경하기

일단 맛보기로 SSG 이 얼마나 끔찍하게 느린지 체감하였습니다. 그래서 대부분은 SSR로 대응하는 방향으로 계획을 변경했습니다.

 

토지 : SSG(정적페이지 생성) 으로 대응 합니다.

사용자 또는 크롤링 봇이 페이지 접속시 이미 빌드 단계에서 SSG로 만들어둔 html 파일을 즉시 보여줍니다. 그리고 바로 이어서 나머지 내용들을 채워서 화면을 업데이트 합니다.

SSG 로는 꼭 필요한 데이터만 담아서 html 파일을 만들어둡니다. 페이지 안에 들어가는 모든 내용을 담아서 페이지를 만들게 되면 SSG 에 너무 많은 시간이 들기 때문입니다. 대략 1만건에 대해서 15분 정도 소요 예상됨. (추측이기 때문에 빌드 타임이 짧을 수도 있음. 운영배포시 확인하여 스크린샷 남기기)

(2023년 11월 6일 기록) SEO 에 대해서는 SSR 로도 충분히 대응이 가능하지만, 사람들이 페이지 접속할 때마다 아래 이미지와 같이 API 를 최소 2~3번 호출해야 하고, SSG로 만들어둔 html 파일을 바로 건네주는게 압도적으로 응답속도가 빠르기 때문에, 한마디로 최적화를 위해 SSG 로 일부분 작업해둔 것이었습니다.

 

토지건물 : 서울시 1만 건에 대해 빌드시 SSG + 페이지 접속시 SSG 으로 대응 합니다.

(2023년 11월 6일 기록) 아무래도 처음 시도하는 것이다보니, 실험적인 시도가 많이 담겨있습니다. SSR vs SSG 의 싸움이라고 볼 수 있습니다. “페이지 접속시” SSG 로 대응하게 되면, 처음 접속시 html 파일을 만들고, 그 다음번 접속시 html 파일을 재활용할 수 있다는 이점이 있어서 시도해본 것이었습니다. 실제로 운영 배포후에 SSR, SSG 비교해보고 어느 쪽으로 갈 지 정해질 것 같습니다.

 

집합건물 : SSR(서버사이드 랜더링) 으로 대응 합니다.

(2023년 11월 6일 기록) 전국에 엄청나게 많은 자산이 있고. 그 집합건물(아파트)자산의 모든 호실(hoBpk) 에 대한 정적페이지 만드는 건 불가능에 가깝기 때문에 SSR 로 대응하기로 결정했습니다.

 

결론

그 뒤로 선별된 몇 만건의 자산에 대해 SSG를 시도해보았지만. 너무나 느린 생성 속도로 인해서 도저히 못쓰겠다는 판단을 했습니다.

SSR 로도 충분히 대응이 되는 상황에서 내가 이렇게 공수를 들여서 굳이 SSG을 해서 큰 이점을 얻는것도 아닌데 해야할까 그런 생각이 들었고. 결국에는 모든 자산의 꼭 필요한 정보만 SSR 로 렌더링해서 검색엔진에 제공하도록 했습니다.

 

 

Sitemap 

(이건 순수 경험으로 작성된 내용입니다. 100%맞다고 볼 수는 없고 참고만..)

어쨌든 SEO 는 SSR 로 대응했다고 치는데. 이번엔 수만개의 사이트 맵을 만들어야 했습니다.

 

사이트 맵 용량이 크면 검색엔진이 잘 안읽는가?

-> 사이트맵 읽는 날짜가 제각각인것 보면 딱히 그런건 없었습니다. 그리고 Next 에서는 기본적으로 gzip 압축해서 보내주고 있었습니다.

 

사이트 맵 파일에 너무 많은 주소가 들어있으면 잘 안읽는가?

꼭 그렇다고 보기는 어려워보이지만 권장 개수는 10000개라고 합니다.

그래서 저희도 하나의 사이트맵 파일에 35000개의 주소를 포함시키던 것을 권장 개수인 10000개로 줄이고. 파일 개수를 늘렸습니다.

그런데 나중에 알게 되었지만. 등록된 지 얼마 안된 사이트에 대해 검색엔진이 읽을 수 있는 파일의 개수가 정해져있는듯 했습니다.

45개였습니다. 약 450000개의 주소 정도였다고 보면 됩니다.

어떻게 해서 구글서치콘솔에 사이트맵 등록을 완료했는데요... 문제가 많았습니다. 이어서 보시죠.

 

문제발생

구글서치앤진에서 파이퍼 sitemap 파일의 일부 지역(부산, 충청도)만 읽는 문제가 있었습니다.

기존에는 sitemap/index.xml 파일 아래에 모든 지역의 사이트맵 파일이 포함되었는데

기존에 올려둔 사이트맵 파일 모두 지우고 sitemap/index.xml 파일 하나만 등록하는 방식으로 바꿔서 테스트 해보았습니다.

그런데 달라지는 건 없었습니다.

 

이 문제의 원인은 방금 위에 적어놓은것 처럼 등록된 지 얼마 되지 않은 사이트에 대해서는 읽을 수 있는 파일 개수가 제한되어있었기 때문이었고.

파일 이름이 알파벳 순서대로 B로 시작되는 부산, C로 시작되는 충청도가 먼저 읽혀졌던 것이었습니다.

저희는 S로 시작되는 서울 지역이 가장 우선순위가 높았기 때문에 서울앞에 0- 이런식으로 정렬 순서가 가장 앞설 수 있게 고쳤고.

그 결과 서울 지역이 읽히게 되었습니다.

 

(서울지역이 가장 앞페이지에 나타나는것을 보여주는 캡쳐 이미지)

 

이렇게 하고나서 보니 오히려 파일을 쪼개기 보다는 합치는게 답이었을까 그런 생각도 들었는데요.

한번 변경하고 반영하기 까지 몇 달이나 소요되기 때문에 현실적으로 모두 다 테스트 해볼 수는 없었습니다.

그러나 만약에 또 다시 사이트맵을 건드려야 하는 일이 생긴다면, 저는 다시 파일 당 포함 주소를 1만개에서 3만5천개로 되돌려서 해볼 거 같습니다.

 

물론 이렇게 서울지역이 먼저 읽히게 했지만. 읽을 수 있는 파일은 45개가 맞다는 것을 확실히 알 수 있었습니다.

• 변경 전 : 부산(24개) + 충청북도(21개) = 45개
• 변경 후 : 서울(50개) 중 44개 + /sitemap-0.xml 파일 1개 = 45개

 

구글서치엔진의 색인 제거하기

이런저런 고생을 했지만 지금은 이 페이지가 기획에서 제외되었는데요...

그래서 구글서치엔진의 색인을 다시 지워주는 과정이 필요했습니다.

 

robots.txt 에서 disallow 를 하여 접근을 막으면 되는거 아닌가 라고 쉽게 생각할 수 있는데요.

오히려 그 반대로 접근을 막아버리면 색인에서 제거할 수 없게 되기 때문에 그러면 안되었습니다.

검색봇이 사이트에 접근할 수 있게 열어두고.

<meta name="robots" content="noindex"> 테그를 추가함으로써 검색봇이 이 테그를 읽고는 색인을 하지 않게끔. 색인이 있으면 삭제하게끔 해야만 색인이 제거되었습니다.

 

저희는 색인을 제거해야하는 페이지를 아예 걷어낼 계획이었기 때문에

page 경로 상에서도 제거했었고. 접속시 404 경로로 이동되는데. 404 페이지에 저 테그를 심어둠으로써

색인이 제거될 수 있었습니다.

 

정말 길고 긴 시간이 지나서야 색인이 모두 제거될 수 있었네요.