기술 스택에 대한 의문
바이럴 컨텐츠를 준비하기 앞서 막상 두려웠다. 그럴 일은 없겠지만, 사용자가 엄청 많아져서… 컴퓨터나 클라우드가 뻗기라도 한다면?? 비용의 문제를 뒤로하고도, 사용자가 많은 서비스는 항상 느려질 수 있는 서버 상황에 대비해야 한다는 것을 너무나 두려워했다.
그래서, 가장 중요한 지표 중 하나는 “속도”였다. 막연하게 검색을 시작했고 아래와 같은 기술 스택별 속도 비교 결과를 알려주는 사이트를 찾았다.
TechEmpower Web Framework Performance Comparison
위 사이트에 들어가면, 각 백엔드 언어별로 어떤 프레임워크를 사용했을 때 가장 빠른지를 요청 종류에 따라 구분하여 결과 지표를 작성해 놓은 것을 알 수 있다.
실제 서비스로 인한 수익 구조를 바라지 않기 때문에 해당 결과 지표가 어떻게 분석되었는지 등에 대한 꼼꼼한 분석은 하지 않고 막연하게 내가 사용할 수 있는 언어 부분에서 지표를 확인해보았다. 사실 요청하는 타입도 다양하고, (싱글 쿼리, JSON serialize, plain text 등..) 너무 새로운 프레임워크도 많아서 정리된 내용을 찾아보았다.
내가 사용할 수 있거나(spring, php, node) 친숙한 python 언어를 사용하는 프레임워크들 중 주로 사용되는 것들로만 나타난 지표이다. 정말 의외인 것은, 전체 프레임워크(속도만을 위해서 개발된 잘 알려지지 않거나 특화된 프레임워크를 포함한)를 포함한 50%에 가까운 성능지표를 php + nginx 가 갖는다는 점이었다.
그렇지만 커리어적인 측면이나 경험적인 측면 등 여러가지를 포함하였을 때 이 지표는 내가 선택한 typescript + node 가 괜찮은 지에 대해서 알고 싶었던 것 뿐이었다. 만약 두 체제 사이에 큰 걸림돌이 없다면 함께 사용하는 것이 문제가 되지 않을 것이라고 생각했기 때문이다. 보다시피, nodejs + typescript 가 없는 상황에서 나는 자연스럽게 node와 typescript 의 관계를 알고 싶었고, 검색결과 다음과 같은 내용을 찾을 수 있었다.
타입스크립트로 작성된 코드를 컴파일 하여 자바스크립트 코드로 변환할 수 있다. 이를 노드로 실행하는 것. (https://nodejs.dev/learn/nodejs-with-typescript)
위와 같이 컴파일을 할 수 있고, 그 과정의 다양한 옵션을 json 파일로 관리하는 시스템으로 확인할 수 있었다. nginx 를 사용하고자 한 것은 LB 를 적용할 수 있다는 점 뿐이었기에 구현하며 바뀔 수도 있다는 것을 정확히 하고 간다.
