Static Site Geneartion / ISR

D+46

해본다 next.js

Static Site Genration(SSR)

영어 단어에서 말하듯, SSR은 정적인 페이지를 만드는 것이다. 정적인 페이지를 만든다는 뜻은 말그대로 컨텐츠가 변하지 않는 페이지를 만든다는 뜻이다. 아무런 데이터 업데이트도 되지 않는 웹페이지를 상상하면 된다. 누군가 어떤 홈페이지의 랜딩페이지(최초에 접속하면 나오는 페이지)의 내용물을 한번 만들면 변하지 않도록 설정했다면 그런 경우 SSR의 예시로 볼  수 있다. 정적인 페이지가 만들어지기 때문에 빠르고 효율적이다. 그리고 보안상 더 유리하다. 보안상 유리하다는 뜻은 정적인 페이지의 경우 따로 요청을 어디론가 보내지 않기 때문이다. 하지만 정적인 페이지를 만들면 단점이 있다. 내용을 업데이트 하려면 앱 자체를 다시 배포해야 하는 것이다. 

가령 나는 obsidian기반의 웹페이지 생성기인 quartz(https://quartz.jzhao.xyz/)를 쓰고있다. 이 프레임워크의 원리는 옵시디언의 md파일을 html로 바꿔주는 것이다. html로 바꾼 후 github등을 통해 배포할 수 있다. 이렇게 해보면 장점이야 있겠지만, 관리하는 입장에선 단점이 눈에 띈다. 글자 하나라도 틀리면 매번 배포를 진행해야한다. 그런것이 참 번거롭다. 이런 경우가 SSR방식의 단점이다.

Incremental Static Regeneration(ISR)

개발자들은 참 대단한 집단이다. 무슨 문제가 있으면 반드시 해결하고야 만다. next.js에서 ISR은 SSR의 불편한 업데이트 방식을 개선한 방식이다. 정적인 페이지와 동적인 페이지의 장점을 결합한 방식이다. 개발자가 설정한 특정 기간동안은 업데이트를 실행하지 않지만, 시간이 지난 후 주기적으로 업데이트를 진행하는 방식이다. 여기서 업데이트는 내용을 완전히 바꿀 수 있다기 보다는, 어딘가에서 데이터를 받아서 해당 내용이 업데이트 되는 정도로 이해하면 된다. 이렇게 하면 설정한 주기별로 서버에서 렌더링을 다시 하기 때문에 큰 부담이 없는 앱을 만들 수 있다.

끝마치며

슬슬 이론만 이야기해서 살짝 지루하다고 생각하려는 찰나, 다음 챕터부터는 본격 프로그래밍을 하도록 되어있다. 예상컨데, 너무 오래된 next.js와 씨름하느라 꽤나 어려운 시간을 보낼 것으로 보인다. 해보자