연차가 쌓일수록 중요해지는 것
개발 조직의 규모가 크면 할당된 예산이나 리소스가 비교적 여유로우며. 서비스 개선을 위한 경우라면 더욱 넉넉히 할당하는 경우가 많다.
이런 규모의 조직에서는 비용보다는 기술적인 가치에 중점을 두고 업무를 진행하고 평가도 그 기준에 따른다. 그렇다 보니 개발자 개개인도 더욱 더 기술 중심으로 경력을 발전시키려는 생각을 하게 된다.
예를 들면 근래에 소개된 기술 스택들을 빠르게 습득하고 서비스에 적용하는 방향으로 업무를 계획하고. 경우에 따라서 불필요하게 예산을 사용하게 되는 식으로 업무 방향을 이끌게 된다.
회사 입장에서는 직원에게 기술의 발전과 충분한 예산을 제시하였으므로 딱히 문제 될 것이 없긴 하다. 하지만, 그런 업무 방향은 나한테도 회사에게도 장기적으로는 전혀 도움이 되지 않는다.
이런 부류의 오류들 중. 가장 흔한 형태의 오류를 꼽자면 서비스 SSR 적용이 있다.
Next.js를 필두로 SSR이 프론트엔드 개발의 트렌드가 되었으며, 이제 개발자들에게 CSR은 이전 세대의 기술이 되어 가고 있다.
그런데, 서비스를 왜 Next.js로 개발해야 하는지. SSR을 적용해야 하는지. 기술적, 환경적 측면에서 깊게 고려해본 적이 있는지 묻고 싶다. 반대로 Next.js를 SSR를 적용하였기 때문에 잃는 것은 없는가?
다시 한 번 강조하지만 “기술적”, “환경적” 두 가지 측면의 고려이다. 환경적 측면을 고려하지 못 하면 영원히 주니어 개발자에 머무를 수 밖에 없다.
이 글은 SSR에 대한 고찰이 아니므로. 기술적인 내용에 대해 깊게 설명하지는 않는다.
무엇을 고려해야 하는가
이제 “SSR적용” 이라는 주제로 고려할 수 있는 내용에 대해 이야기 해 보자. 먼저 보면서 생각할만한 내용이 필요하므로 각 방식의 장단점을 정리한다.
“SSR의 장단점”을 구글링하면 정말 많은 글을 볼 수 있다. 일부 글에서는 SSR을 php같은 전통적인 방식으로 설명하는 경우도 있고. 부정확하거나 모호하게 정리한 경우가 대부분이긴 하나. 대략 정리해보면 아래와 같다.
단점은 장점들의 반대이므로 따로 적지 않았다. 또 SSG나 iSSG(Next.js에서는 ISR이라 함)은 사실 SSR을 사용할 때 경우에 따라 적용할 수 있는 기법이므로 따로 구별하지 않는다.
CSR
- 인프라 구성이 비교적 단순하고 저렴하다.
- INP가 짧다.
SSR
- SEO에서 조금 더 유리하다.
- FCP가 짧다.
기술적 측면
주니어~중니어 즈음에 집착하는. 사실 그 시절에는 올바른 집착과 고집이 필요하지만 어쨋든 기술 중심의 고민들이다.
- CSR은 INP가 짧은가? 반대로 SSR은 INP가 길 수밖에 없나?
- SSR은 FCP가 짧은가? 반대로 CSR은 FCP가 길 수밖에 없나?
- SSR의 TTFB는 CSR에 비교해 길 수밖에 없나? 반대로 CSR은 TTFB가 짧나?
- CSR은 Waterfall Request에 취약한가? 해결책이 정말 SSR, Suspense 뿐인가?
- SEO의 적용이 서비스에 어떤 이득을 주는가?
- CSR은 UI/UX측면에서 제한되는가? 반대로 SSR은 제한이 없는가?
- CWV는 어떠한가? 모바일의 경우 클라이언트 측에 전송되는 전체 리소스 크기는 어떠한가?
- 빌드 속도는 어떠한가?
환경적 측면
조직과 회사 입장에서의 고민이 중심이다.
- CSR의 기술 및 인프라 구성이 단순한가? 단순함의 기준이 무엇인가?
- 조직 내 모든 구성원이 이해할 수 있을 정도로 단순한가? (쉽나)
- 반대로 SSR의 기술 및 인프라 구성은 어려운가? 어려움의 기준은 무엇인가?
- 도입 후 유지보수는 어떠한가? 새로운 비즈니스의 빠른 실현에 발목을 잡지는 않는가?
- 클라우드 쓰면 된다고? 비용은 공짜인가?
- CSR의 인프라 구성이 정말로 저렴한가? 반대로 SSR은 비용이 높을 수 밖에 없나?
- SSR도입 대비 얻을 수 있는 이득을 돈으로 환산하면 얼마나 될까? 혹시 마이너스가 되지는 않는가?
- CSR(혹은 SSR)도입이 개발자 커리어와 회사 모두에게 이득이 되는가?
- CSR(혹은 SSR)도입이 협업에 도움이 되는가?
정말 중요한 것
역량을 인정받아 팀 내에 키맨이 되거나, 연차가 쌓여 기술에 대한 결정권을 갖게 될수록. 위의 CSR vs SSR외에도 디자인 시스템의 자체 개발 여부 등 다양한 선택들에서도 깊은 고민이 필요하다.
기술 트렌드를 쫓는것이 중요하긴 하다. 새 기술이 만들어지고 유행을 타는 것은 대부분 개발자들의 고민을 해결해 주거나 해결을 위한 아이디어를 떠오르게 해 줄수 있기 때문이다.
중요한 것은. 그런 기술이나 방법론을 무작정 따르기 보다, 해당 기술의 탄생 배경에 대한 이해. 그리고 현재 서비스에 제공할 수 있는 기회 혹은 기회비용을 정확히 파악하고. 필요에 따라 적용하는 것이다. 충분한 이해 후에는 단순 도입 뿐만 아니라 아이디어만 차용하는 등 여러 선택지도 생기기 마련이다.
또. 지금 타이핑중인 소스코드 포함하여 회사 뿐만 아니라 개발자 본인도 영원하지 않다. 언제까지 지금 둘러진 울타리 안에서 풍족한 리소스 (사람, 비용, 기타등등)를 소비해가며 서비스를 개발하고 운영할 수 있을까?
어디에 가더라도 꼭 필요한 개발자가 되어 보도록 하자.