[번역] 서버 사이드 자바스크립트에 필요한 것

본 포스팅은 What Server Side JavaScript needs 글을 번역한 것입니다.
오역, 잘못된 내용이 있을 경우 댓글로 알려주시면 감사하겠습니다 🙏

 

---

 

서버 사이드 자바스크립트 기술은 오랫동안 존재해 왔습니다. 1996년, Netscape는 서버 소프트웨어에서 서버 사이드 자바스크립트를 제공했으며, Helma도 상당한 기간동안 존재해 왔습니다.[1] 그러나 지난 몇 년 동안 서버 사이드 개발은 크게 변화했습니다.

Aptana의 Jaxer는 클라이언트와 서버 양쪽에서 실행되는 자바스크립트 환경이라는 혁신적인 관점을 제시합니다. 매우 편리한 커뮤니케이션과 클라이언트와 서버 사이에서 편하게 코드를 공유할 수 있는 점은 서버에서 자바스크립트를 실행하는 것의 큰 이점입니다.

 

Jaxer와 Helma는 흥미로운 프로젝트입니다. 하지만 제가 생각하는 서버 사이드 자바스크립트에 부족한 것은 흥미로운 프로젝트가 아닌 유용한 생태계입니다. 파이썬으로 작업하기 좋아하는 사람들은 웹 프레임워크의 단편화(fragmentation) 등을 이야기하기도 하지만, 이것은 자바스크립트의 단편화에 비하면 아무것도 아닙니다.

예를 들어, 자바스크립트는 교차 인터프리터 표준 라이브러리가 필요합니다. 다행히 일부 표준 라이브러리가 존재합니다(브라우저로부터 상속된 부분). 따라서 정규 표현식과 날짜를 사용할 수 있습니다. 그러나 파일과 디렉토리는 어떨까요? Rhino, Spidermonkey, V8, JSCore에서 같은 API를 동작시킬 수는 없을까요?[2]

일부 표준 인터페이스가 필요합니다. 데이터베이스에 연결하고 쿼리를 실행하는 것은 이해되기 쉽고 흔한 문제입니다. Rhino에서는 JDBC를 사용합니다. 하지만 자바스크립트는 Python의 DBAPI와 같은 교차 인터프리터 표준을 가질 필요가 있습니다. 또한 웹 서버/웹 앱 인터페이스의 표준을 통해 Apache 모듈 뒤에서 Spidermonkey로 실행되던 웹앱을 Jetty로 옮길 수 있어야 합니다.

자바스크립트에는 다른 모듈을 포함하는 표준적인 방법이 필요하며, 이러한 모듈은 개별적인 네임스페이스에서 존재해야 합니다. 네임스페이스를 사용하는 쉬운 방법은 있지만, 모듈을 (한 번만!) 로드하는 표준 프로그래밍 방법은 없습니다. 서버 사이드 앱들은 많은 코드를 포함할 수 있고, 표준 인터페이스를 충족하는 부분들을 혼합할 가능성이 높기 때문에 이것은 매우 중요합니다.

 

배포 및 배포용으로 코드를 패키징하고 설치하는 방법이 필요합니다. Linux 사용자들은 "apt get" (또는 yum 또는 기타)를 입력하기만 하면 작업이 끝납니다. 그러나 맥과 윈도우를 사용하는 많은 사람들에게는 개발 환경을 편리하게 설정하고 작성한 코드를 패키징하고 다른 사람들이 사용할 수 있게 하는 방법이 필요합니다.

배포 및 설치 문제 중 일부는 패키지 저장소입니다. JSAN이 그 답인지는 모르겠지만, 패키지와 해당 종속성(dependencies)을 쉽게 설치하는 방법이 사람들이 앱에 얼마나 많은 라이브러리를 사용할 것인지에 있어 큰 차이를 만든다는 것은 알고 있습니다.

 

그리고 이 모든 것들 위에 템플릿 엔진, 객체 관계 매퍼, 미들웨어, 패키지화된 앱 등이 있을 것입니다. 사실, 이것들 중 많은 것들이 이미 존재합니다. 그러나 문제는 그들이 서로 공통적인 기초를 가지고 있지 않다는 것입니다. 그리고 바로 이 점이 생태계의 성장을 방해하는 지점입니다.

만약 파이썬 패키지 인덱스에서 WSGI(웹 앱과 웹 서버를 연결하는 파이썬 표준)를 검색하면 오늘날 180개의 패키지가 나옵니다... 서버, 미들웨어, 완전한 애플리케이션들이 말이죠. 그리고 그것들은 단지 "WSGI"를 리스트에 포함시킨 패키지들뿐입니다. 이것이 생태계가 어떻게 보이는지입니다. 자바에도 있고, 루비에도 있고, 자바스크립트에도 필요한 것입니다.

 

그리고 이 모든 이점 위에 템플릿 엔진, 객체 관계 매퍼, 미들웨어, 패키지화된 앱 등이 추가될 것입니다. 실제로, 이러한 많은 기능들은 이미 존재합니다. 그러나 문제는 이러한 기능들이 공통적인 기반을 갖지 않는다는 것입니다. 이것이 생태계가 성장하는 것을 막는 요인입니다.

만약 파이썬 패키지 인덱스에서 WSGI(웹 앱과 웹 서버를 연결하는 파이썬 표준)를 검색하면 180개의 패키지를 볼 수 있을 것입니다. 서버, 미들웨어, 완전한 애플리케이션들을 말이죠. 그리고 그것들은 단지 "WSGI"를 리스트에 포함시킨 패키지일 뿐입니다. 이것이 생태계가 돌아가는 방식입니다. 자바도 루비도 그 생태계를 가지고 있고, 자바스크립트도 이러한 생태계를 필요로 합니다.

 

또한, 그 WSGI 구성 요소들 중 많은 것들은 공통 표준 라이브러리 덕분에 CPython, Jython, IronPython에서 그대로 실행될 수 있습니다. 자바스크립트는 C, 자바, .Net에서 구현된 모음이 있고, 일부 인터페이스에 대해 약간의 합의가 필요합니다. 이러한 상황에서 실행되는 라이브러리는 더 많은 사용자와, 더 많은 기여자를 모을 수 있을 것이고 희망적으로는 이러한 라이브러리들이 성장하는 데 도움이 될 것입니다.

이 글에서 설명하는 것은 기술적인 문제가 아닙니다. 사람들이 모여서 앞으로 나아가고, 함께 더 크고 더 멋진 것을 만들기로 결정하는 문제입니다.

이를 위해, 나는 관심 있는 사람들이 대화를 나누고, 얼굴을 맞대고 코드를 만들고 인터페이스를 결정하기 위해 새로운 ServerJS 그룹을 설립했습니다. 이미 많은 양의 자바스크립트 코드가 모였고, 우리가 이 모든 코드를 훨씬 더 가치 있게 만들 수 있는지 확인해봅시다.

Mozilla의 웹 개발자 도구 그룹에서는 오픈 웹을 최대한 활용하는 데 도움이 되도록 하는 넓은 토대를 가지고 있습니다. 서버 사이드 자바스크립트 커뮤니티가 성장하고 번영하도록 하는 것도 이 일부가 될 수 있을 것입니다.

("왜 루비/파이썬/자바/C#을 사용하지 않을까?"라는 질문에 대해서는 이 글에서 다루지 않겠습니다.)

업데이트: 그 그룹은 이제 CommonJS로 불리고 있습니다.

 

옮긴이 주

[1] Netscape는 웹 브라우저와 서버 소프트웨어를 개발한 회사로서, 초기 인터넷에서 중요한 역할을 한 기업이다. Helma는 웹 애플리케이션 프레임워크로서 서버 사이드 자바스크립트를 활용하여 웹 애플리케이션을 개발할 수 있게 해주는 플랫폼이다.

[2] Rhino는 Mozila Foundation에서 개발한 오픈소스 자바스크립트 엔진으로 자바 플랫폼에서 자바스크립트 코드를 실행하는 데 사용된다. Spidermonkey는 Mozilla Firefox 웹 브라우저의 자바스크립트 엔진으로 개발된 것으로 초기 버전의 자바스크립트 엔진 중 하나이다. V8은 Google에서 개발한 오픈소스 자바스크립트 엔진으로 Google Chrome 브라우저에서 사용되고 있다. JSCore는 Apple에서 개발한 오픈소스 자바스크립트 엔진으로 macOS와 iOS에서 사용된다. 웹 브라우저가 아닌 Apple의 운영 체제와 앱에서 자바스크립트를 실행하기 위해 사용된다.

---

 

CommonJS가 자바스크립트를 해치고 있습니다 글을 읽으며 같이 읽어보게 된 글이다. 2009년에 쓰여진 글인 만큼 현재는 많이 개선된 부분들에 대한 이야기도 있지만 자바스크립트의 발전 과정(?)을 이해하는 데 도움이 된 것 같다. CommonJS가 자바스크립트를 해치고 있습니다 포스팅을 같이 읽으며 CommonJS와 ESM을 이해하는 데 많은 도움을 받았다.