이론적으로 "SSR을 하면 SEO가 좋아진다" 정도로만 SSR를 이해하고 있었다.
그러나, 실제로 서비스를 제작하다보니, 단순히 SEO만을 위해 SSR을 사용하지 않는다는 것을 알았다..!

결론부터

브라우저에 보여주기 싫은(안되는) 비즈니스 로직을 숨기기 위해서 SSR를 사용한다

SSR의 원리는 브라우저에 뭐가 도달하기 전에, 서버와 서버끼리 데이터를 주고받아 그 결과물만을 브라우저로 보내주는 것이다.
그렇기 때문에 브라우저에는 서버와 서버가 주고받은 내용이 기록되지 않는다.

이 특징을 이용하여 각종 결제서비스, ID/비밀번호 찾기 서비스에 활용할 수 있다.
CSR로 위의 서비스를 만들 경우, 브라우저에서 서버로 전달되는 주요 데이터(예) 카드 번호, 이름, 핸드폰 번호 등..)가 외부에 노출이 되지만,
SSR를 사용할 경우 다 처리하고 난 결과값만 브라우저에 띄우기 때문에 어떤 로직으로 어떤 데이터를 주고받는지 client는 알 수가 없다.

그렇기때문에, 보안이 필요한 주요 비즈니스 로직은 가급적 SSR로 구현할 필요가 있다.

SSR이 잘 되는지 어떻게 알까

SSR를 이론적으로만 배웠을 때 가장 이해가 안되었던 것이 SSR로 통신이 잘 되는지는 어떻게 알지..였다.
답부터 말하면, 네트워크 통신 내역이 브라우저 개발자 도구 network에 잡히지 않으면 성공이다.

사실 이렇게 말로만 적어놓으니까 와닿지 않지만..getServerSideProps() 한번만 사용해보면 어떤 느낌인지 금방 감이 온다

SSR 단점

디버깅에 많이 사용되는 console.log()나, window객체에 접근할 수 없다..!
고로 디버깅이 상당히 어려운데 보통 우선 CSR로 만들면서 로직을 안정화 한 다음에 SSR로 바꾸는 식으로 작업을 진행하는 경우가 종종 있는 것 같다.