팀 어썸 오렌지가 Static Site Generation을 채택한 이유

저희 프론트엔드 메인 페이지는 Static Site Generation을 채택하고 있어요. 간략하게 말하자면, 빌드 시 html 파일의 내용을 채워서 정적으로 서빙하는 거에요. 팀 어썸 오렌지는 왜 Static Site Generation을 채택했을까요?

저희 서비스의 특징

저희 서비스는 다음과 같은 특징을 담고 있어요.

• 스크롤 기반의 싱글 페이지에요.
• 이벤트 페이지라는 속성을 가지고 있어요. 즉, 사용자를 더 많이 모아야 한다는 특징을 가져요.
• 대부분의 내용은 정적으로 채워져 있어요. 서버의 데이터 기반으로 무언가를 렌더링하는 부분은 거의 없어요.

Static Site Generation의 이점이 뭘까요?

Static Site Generation은 빌드 시에 html 파일의 내용을 미리 채워 두고, 채워진 html과 자바스크립트 코드를 정적 서버에 올린 뒤, 클라이언트가 정적 페이지를 동적으로 변경시킨다(hydration)는 기본 구조를 담고 있어요. 미리 html의 내용을 채운다는 것 때문에, 다음의 이점을 가져요.

• First Contentful Paint(FCP)를 개선할 수 있어요. html의 내용이 미리 채워져 있기 때문에, 별도의 자바스크립트 파싱 과정 없이 html의 내용을 바로 표시할 수 있어요.
• 검색 엔진 최적화(SEO)를 할 수 있어요. 내용을 시각적으로 볼 수 없는 검색 엔진은 html을 분석해서 웹 페이지의 내용을 알아내요. SSG는 html의 내용이 이미 채워진 상태기 때문에 검색 엔진이 우리 웹 서비스의 내용을 알 수 있겠죠?

Static Site Generation은 저희 서비스에 어떠한 이점을 가질까요?

• FCP가 개선되어서 저희의 서비스를 더 빠르게 볼 수 있습니다. 이벤트 정보를 전달하는 페이지의 특성상 사용자가 빠르게 이벤트의 내용을 파악하는 것이 비즈니스적으로 좋다고 판단했습니다.
• SEO로 인해, 구글 등 검색 엔진에 저희의 서비스가 '잘' 노출될 것이라고 생각했습니다. 저희의 서비스를 검색 엔진에 노출시킬 수 있으면 보다 더 많은 사람들이 저희 페이지를 유입할 수 있다고 생각했어요.

다른 방식은 없었을까요?

• 동적으로 컨텐츠 내용의 대부분이 변화하는 프로젝트가 아니므로, CSR의 이점을 가져갈 수 없다고 판단했습니다. 일부 섹션만 동적으로 돌아가게 하는 전략이 대부분의 페이지 내용이 정적이므로 유효하다고 생각했습니다.
• 서버 데이터 기반으로 무언가를 렌더링하는 부분이 거의 없으므로, SSR의 이점을 가져갈 수 없다고 판단했습니다. 대부분의 데이터는 정적으로 보여지며, 변경할 데이터가 거의 없으므로, 서버에서 데이터를 가져오는 것보다 빌드 시에 데이터를 고정시키는 것이 더 낫다고 판단했어요.