연차가 쌓일수록 중요해지는 것

#development cost management
연차가 쌓일수록 중요해지는 것

큰 규모의 개발 조직에서는 보통 예산이나 리소스를 여유롭게 사용한다. 이런 조직은 대개 비용보다 기술적인 가치에 중점을 두고 업무를 진행하고 평가도 그 기준에 따른다.

그렇다 보니 소속 개발자들도 자연스럽게 기술 중심으로 업무를 진행하게 된다. 예를 들면 최신 기술 스택들을 빠르게 습득하여 서비스에 적용하고. 그 과정에서 경우에 따라 예산이나 리소스를 초과하여 사용하기도 한다.

회사 입장에서는 요구한 바를 충실히 이행하였고 초과분에 대한 소명도 방향성에 어긋나지 않으므로 딱히 문제 될 것이 없다. 하지만, 이런 방식은 나한테도 회사에게도 장기적으로는 전혀 도움이 되지 않을 가능성이 높다.

이런 부류의 오류들 중. 가장 흔한 형태의 오류를 꼽자면 Server Side Rendering의 적용이 있다.

서비스에 왜 SSR을 적용해야 하는지. Next.js를 사용해야 하는지 “기술적”, “환경적” 두 가지 측면의 고려가 필요하다. 기술적 측면은 익숙한 개발자들이 많지만, 환경적 측면을 고려하지 못 하면 주니어 개발자에 머무를 수 밖에 없다.

고려해야 할 사항들

이제 “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)도입이 협업에 도움이 되는가?

정말 중요한 것

연차가 쌓여 기술에 대한 결정권을 갖게 되면. 예시로 다뤘던 위의 내용 외에 디자인 시스템의 자체 개발 여부 등 다양한 선택들에서도 깊은 고민이 필요하다.

기술 트렌드를 쫓는것도 중요하다. 새 기술이 만들어지고 유행을 타는 것은 대부분 개발자들의 고민을 해결해 주거나 해결을 위한 아이디어를 떠오르게 해 줄수 있기 때문이다.

하지만. 그런 기술이나 방법론을 무작정 따르기 보다는 해당 기술의 탄생 배경에 대한 이해. 그리고 현재 서비스에 제공할 수 있는 기회 혹은 기회비용을 정확히 파악하고 필요에 따라 적용해야 한다.

충분한 이해 후에는 단순 도입 뿐만 아니라 아이디어만 차용하는 등 여러 선택지도 생기며. 그에 따라 모두에게 이득을 주는 진정한 기여에 더 가까워질 수 있다.

또. 개발중인 소스코드 포함하여 회사 뿐만 아니라 개발자 본인도 영원하지 않다는 것을 기억해야 한다. 언제까지 지금 둘러진 울타리 안에서 풍족한 리소스를 소비해가며 서비스를 개발하고 운영할 수 있을까?