Table of Contents

• 글을 시작하며

• 현재 내가 SSR 을 구현한다면 어떤 방법을 선택할 것인가

  • 새로작성하는 프로젝트의 경우

    • 실무

      • React.js vs Next.js vs Remix.js
      • 배포 환경: Docker(ECS, K8S..) vs Serverless Framework(Lambda)

    • 개인 프로젝트

      • React.js vs Next.js vs Remix.js
      • 배포 환경: Docker(ECS, K8S..) vs Serverless Framework(Lambda)

  • 이미 작성되어 있는 프로젝트일 경우

• 마치며

글을 시작하며

안녕하세요! 기술 스택을 선택한 이유와 관련한 질문을 많이 받아 이에 대한 제 개인적인 견해에 관한 이야기를 할까 합니다. 제가 가장 많이 받은 질문. 그리고 가장 많이 읽어주신 글이 Next.js 에 관한 글인데요.

이 부분은 실무에서도 실제로 선택을 해야했던 상황이 있었고, 이때에 제가 특정 방식을 선택한 이유가 분명했기에 이를 예시로 제 기술 스택의 선택 기준을 말씀드려볼까 합니다.

기술적인 구현에 관한 이야기보다는 제가 기술을 선택하는 상황과 저의 판단의 기준에 관한 이야기가 될것 같습니다. 아울러 SSR 을 구현시 Next.js 및 React.js 를 제 기준으로 비교하고 생각한 선택기준과 기술적 관점에 대한 글은 아래 두 글의 링크를 참고해주시면 감사하겠습니다.

블로그 개발 후기 3탄: Next.js GoodBye Next.js, Hello React.js

현재 내가 SSR 을 구현한다면 어떤 방법을 선택할 것인가

사실 이부분은 실무에서 특히나 상황에 따른 선택을 할 경우가 많을것이란 생각이 드는데요. 대표적으론 아래와 같은 경우가 있을것 같습니다.

새로작성하는 프로젝트의 경우

실무

React.js vs Next.js vs Remix.js

실무의 경우라면 저는 Next.js 선택합니다. 이유는 다음과 같습니다.

1. 현재 제가 있는 팀은 모두가 SSR 을 직접 구현하는데 익숙치 않습니다.
2. 일단 수많은 레퍼런스가 있는만큼 믿을만 합니다.
3. 굉장히 잘 만들어진 프레임워크 입니다. 아울러 굉장히 훌륭한 엔지니어분들의 주도하에 관리되고 있는 프로젝트인 만큼 안정성 역시 뛰어납니다.
4. 만약 현재 모두가 직접 SSR 을 구현 하는데에 있어 장인이라 할지라도 이후에 합류하게 될 팀원이 어떤 분이 오실지 알 수 없습니다.
5. 직접 SSR 을 구현시 무언가 특별히 알아야 하는 사항이 있는경우, 이때는 이를 구현한 구성원의 도움(문서)을 받을수 밖에 없습니다. 하지만 Next.js 처럼 잘 관리되고 있는 프로젝트의 경우는 공식문서 및 github 이나 stack overflow 등 기타 여러 부분에서 문제를 해결할 방법을 찾기가 비교적 수월합니다.
6. 말인 즉슨 새로운 분이 오셔도, 혹은 기존 팀원이 와도 모두가 같은 범위 내에서의 자료를 참고하기에 드는 리소스가 비교적 적습니다.
7. 개인적으로 저는 팀이되어 움직이는 실무의 경우 가능한 줄일수 있는 리소스라면 줄이는것이 좋다고 생각하는편 입니다.
8. Remix 를 선택하지 않은 이유는 굉장히 잘 만들어진 기술같기도 하고, 좋아보이긴 하나 아직 상대적으로 젊은 녀석이기에 실무에 섣불리 도입하기엔 이른감이 있지않을까 란 생각이 들어서 입니다.

배포 환경: Docker(ECS, K8S..) vs Serverless Framework(Lambda)

이 부분은 현재 제가 속한 팀과 web 의 활용 정도, 팀의 크기에 의해 굉장히 많이 좌우될것 같습니다. 일단 전 k8s 를 사용해본 적이 없습니다. 해서 ECS 를 사용한다고 가정하겠습니다.

ECS 를 선택합니다. 이유는 다음과 같습니다.

1. 현재 제가 있는 회사의 서비스엔 웹의 SSR 을 필요로 하는 비중이 그렇게 크지 않습니다.
2. 위와 같은 이유로 Lambda 와 같은 기술을 사용한다 해도 비용적 문제가 발생할 가능성이 거의 없다고 어느정도 확신할 수 있을것 같습니다. 사실 비용적인 측면은 ECS 와 따져보았을때 어느때즈음 Lambda 가 더 큰 비용이 발생하는지는 아직 경험해 본 바가 없으나 현시점 Lambda 가 무료로 제공하는 request 의 양을 고려 해 본바 충분히 감당 가능합니다.
3. ECS 의 경우 아무리 관리를 안한다 하여도 관리가 필요합니다. 이를테면 트래픽이 확 치솟을 경우 컨테이너를 더 띄운다던지, 혹은 환경을 처음 구성할 때 역시 cloudformation 이나 terraform 등으로 이미 iac 구성이 되어있는 조직을 제외 직접 해주어야 하는 작업의 가짓수가 더 많습니다. 물론 Lambda 역시 동시성 요청에 limit 을 늘리려면 따로 요청을 해야하는 것으로 알고 있으나, 이역시 저희가 아닌 AWS 에 요청을 하면 해결되는 부분으로 알고 있습니다.
4. 위와 같은 이유라면 Lambda 를 선택할것 같지만, 실제 저희 조직내 SSR 이 처음 필요 할때 제가 초기 프로젝트의 구조 및 인프라 환경을 구축 하였는데요. 이때 ECS 를 선택한 이유는 다음과 같습니다.
5. 이미 회사의 모든 ServerSide 프로젝트가 ECS 위에서 돌아가고 있었습니다.
6. 아무리 작업할 사항이 적다고 하여도 팀원들이 비교적 새롭게 알아야 하는 사항이 늘어납니다. (S3, cloudfront, apigateway ...)
7. 하여 저는 팀원들의 의견을 물어보고 ECS 위에 SSR 을 구축했습니다.
8. 이미 팀원들이 익숙한 기술이 있고, 해당 기술을 선호한다면 선택하지 않을 이유가 크게 없다 생각합니다.

개인 프로젝트

React.js vs Next.js vs Remix.js

이부분은 정말정말 굉장히 많은 요소가 결정을 짓게 할것 같습니다만. 결론부터 말씀드리자면 저는 React.js 는 빼고 선택할것 같습니다. 이유는 다음과 같습니다.

1. 상대적으로 React.js 에 비해 Next.js 나 Remix.js 를 Deep 하게 다루어 본적이 없습니다. 개인프로젝트는 또 새로운거 써보는 맛이 있지 않겠습니까.
2. 현재 진행중인 개인 프로젝트에선 그냥 React.js 로 프로젝트를 진행중인데 SSR 을 구현할 생각이 없어서 입니다만. 만약 후에 구현이 필요타면 이땐 코스트를 따져보고 직접 구현하거나 Next.js vs Remix.js 둘중 하나를 선택할것 같네요.
3. 여담으로 이번엔 RTK query 를 사용하는 중인데 회사에서 React Query 는 사용해봤고, 개인적으로 SWR 도 사용해 봤습니다. 아울러 이 블로그는 Apollo client 를 사용해 작성했기에 경험해보지 않은 기술을 써보고 싶었습니다.

배포 환경: Docker(ECS, K8S..) vs Serverless Framework(Lambda)

저는 AWS Lambda 를 선택할것 같습니다.

1. 비용적으로 굉장히 이득을 보는 부분이 많습니다.
2. 이미 사용해봤기에 상대적으로 익숙합니다.
3. 트래픽 관리가 거의 필요 없습니다.
4. 이번에 진행하는 개인프로젝트의 서버사이드를 컨테이너로 관리할 예정인데 이부분에서 컨테이너에 대한 경험은 충분히 키울 수 있을것 같습니다.
5. 함께 사용하려고 생각중인 CloudFront 등과 연동이 굉장히 수월합니다.
6. 즉, 저 혼자 모든걸 관리해야 하는 프로젝트이기에 이번 프로젝트에서 제가 공부하고자 하는 부분을 얻을 수 있다면 ops 의 영역을 최대한 배제할 수 있는 스택을 선택할 것 같습니다.

이미 작성되어 있는 프로젝트일 경우

이때는 저는 실무이든, 개인 프로젝트이든, 어떤 기술을 선택할 것이다 란 대답을 현재로선 드리지 못할것 같습니다. 기존 프로젝트가 어떤 스택을 사용해 작성되어있는지 모르기 때문에 어떤 방식으로 옮겨가는 것이 코스트를 줄이는 방향인지 현재로선 대답하기가 힘들기 때문이지요.

1. 어떨땐 프로젝트 전체를 새로 파서 작성하더라도 코스트가 적을 수 있습니다.
2. Next.js 가 모두들 익숙하더라도, 이미 기존에 있던 프로젝트가 마이그레이션을 하기에 힘든 상황이 있다면 직접 SSR 을 구현하는 것이 나을 수도 있습니다.
3. 제일 중요한것은 함께 만드는 동료가 있다면 이들의 공감을 얻어내는 것이라 생각하는데, 동료들과 합의된 어떠한 의견을 도출해 내는것에 가장 신경을 쓸 것 같습니다.
4. 다만 전적으로 모든 선택의 권한이 제게 있다면 저는 제가 판단하기에 코스트가 가장 적어보이는 부분을 선택할 가능성이 큽니다.

여기서 중요한 것은 예외의 경우가 있을 수 있는데. 이를태면 지금 너무너무 예전 스택을 사용하고 있어서, 조금만 바꿔서 이를 해결하는 경우 새로운 개발자가 오면 적응하기 힘들다 란 판단이 들 때가 있습니다. 그럴땐 시간만 주어진다면 어쩌면 대공사를 할지도 모르겠습니다. (그래서 리펙터링과 이런 대공사엔 잘 작성되어있는 테스트 코드가 정말 큰 힘이 된다 생각합니다...)

마치며

제가 이 글을 작성하는 가장 큰 이유는 Next.js 로 작성되어 있는 블로그를 React.js 로 바꾼 이유에 대한 질문을 종종 들을때. 무조건 이게 옳은 선택은 아니고, 저역시 다른 선택을 하는 경우가 굉장히 많다는 이야기를 하는데 그 이유를 말씀드리고 싶었습니다.

상황에 따라 늘 선택은 달라질 수 있고, 실무라면 나와 함께 코드를 작성해야 하는 팀원. 그리고 앞으로의 채용과 새로운 개발자를 맞이하기에 좋은 방향은 무엇인가를 고민하는것이 가장 중요하다 생각하는 편입니다.

여러분은 어떠신가요? 행여 제 생각과 기준이 궁금하셨던 분들이 계시다면 도움이 되셨기를 바라며, 코딩이 늘 재밌으셨으면 좋겠습니다. 감사합니다.