https://youtu.be/M3BM9TB-8yA

안녕하세요. 음, 네, 원래는 다른거 이야기 하려고 했는데 준비가 안되었네요. 그래서 대신에 이 이야기를 하려고 합니다. 노드가 나온지 꽤 되었네요. 안정화도 되었고, 널리 알려지기도 했고. 발전하는 듯한 모양새를 보였죠. 이제는 노드에 대해 다시 생각해 보고 그 생각을 여러분께 공유해야 할 때인 것 같습니다.

배경 설명

저는 노드를 만들었고, 초기 개발 단계부터 참여해 몇 년간 운영했습니다. 그리고, 이미 아시는 분도 있을테지만, 저는 IO, 자바스크립트로 이벤트 주도 IO를 만드는데 상당히 많은 심혈을 기울였습니다. 2009년 당시 저는 이 목표가 매우 중요하다고 생각했습니다. 서버사이드 자바스크립트를 제대로 만드려면 말이죠.왜냐하면, 우리가 알다시피, 자바스크립트는 싱글 스레드이기 때문에, 그리고, 아 죄송합니다. 그리고, 아 미안해요. 생각의 흐름을 놓쳐 버렸네요.

네, 다시. 자바스크립트는 싱글 스레드고, 어쩌고 저쩌고... 대충 뭐 이런저런 일을 거쳐서 노드가 성공할 수 있었답니다. 2012년에 떠날 당시, 저는 노드가 IO 분야에서 잘할 거라 생각했어요.

HTTP, HTTPS와 같은 프로토콜도 지원했고, 무지막한 노력을 들인 끝에 IOCP라는 훌륭한 시스템 콜도 사용해 윈도우즈에도 노드를 포팅했고, 리눅스, 맥에서도 돌아가고, 무엇보다 코어 크기가 상대적으로 작았습니다. 제 말은, 아주 살짝 감당할 수 없을 정도이긴 했지만 봐 줄만 했다는 거죠. API도 안정적이고, NPM도 등장했을 뿐더러 거기다 사람들이 모듈도 추가하고 있었습니다.

저는 이렇게 생각했죠. "프로젝트 완료."... 완전 틀렸죠!

누가 봐도 모든 장비에서 노드가 돌아가게끔 만들려고 엄청나게 노력했다는 것이 보여요. 지금 하는 것 처럼요. 자바스크립트에 발맞추어 개선도 하고, 이슈도 고치고, 아주 많은 분들이 힘 써주셨고 이 분들 중 일부는 지금 이 자리에 와 계십니다. 제가 중요한 역할을 하신 분들을 깜빡하고 언급하지 않았다면 사과 드립니다.

동적 언어

이제 노드는 충분히 했다 생각해 다른 것을 하기 시작했습니다. 다시 노드를 많이 사용하게 된지 6개월 밖에 안되었어요. 왜냐하면 Go가 등장했고, 이거로 빠른 서버를 만드는데 관심이 있었습니다. Go는 빠른 서버를 만들기 더 적합한 언어입니다. 노드는 사용해야 할 이유가 없었습니다.

그래도 노드는 꽤나 좋다 생각합니다. 자바스크립트도 정말 정말 좋구요. 동적 언어는 특정한 용도에 매우 좋습니다.서버를 만들 때 진정으로 모든 부분을 통제하고 싶다면 정적 타이핑이 필요하겠죠. 그러나 예를 들어, 과학 분야의 컴퓨팅의 경우 일회성의 계산이 많습니다. Jupyter notebook에 코드를 타이핑 하는데 타입 에러를 보고 싶어 하는 사람은 없겠죠. 이 때는 그냥 뭔가 그래프를 그리려고 하는 거잖아요, 맞죠?

동적 언어가 필요한 경우가 따로 있습니다. 프로토타이핑도 그 예가 되겠네요. 정말 빠르게 뭔가를 만들고 싶을 때는 추상화 같은건 신경쓰고 싶지 않고 그냥 만들고 싶잖아요. 아마 많은 분들은 동의하지 않을지 몰라도, 제가 보기에 자바스크립트는 이럴 때 사용하면 좋습니다. 최고의 동적 언어죠.

따라서, 노드를 사용한다는 것은 때때로 손톱으로 칠판을 긁는것 같다고 생각해요. 내가 뭔가 버그를 만든게 보이는데 지금 당장은 그게 버그 같지 않아 보이고 동작하는 것처럼 보이지만, 버그는 버그인거죠. 그리고 설계상의 결함이 있더라도 지금은 그것을 고칠 수가 없습니다. 너무 많은 소프트웨어에서 사용하고 있기 때문입니다. 모르겠네요, 이런 현실을 보면 가슴이 아픕니다. 애초에 더 좋게 만들 수도 있었을 텐데.

후회들

1. 프로미스

자, 그래서 첫째 후회는 계속해서 프로미스를 사용하지 않았다는 겁니다. 프로미스는 노드 매우 초기에 사용했는데, 바보같게도 얼마 지나지 않아 제거했습니다. 사용하지 않는 편이 더 간단해 보이고, 프로미스를 사용하면 콜백마다 객체를 추가로 사용 하기 때문에 당시에는 그게 옳다 생각했으나, 상황은 다르게 흘러가 버렸고, async/await 생태계가 더 빠르게 도입될 수도 있었지만 불확실하게 되어 버렸죠. 그 이야기는 이제 우리가 절대 알 수 없을 다른 차원의 역사가 되어 버렸습니다.

아마 프로미스가 제거 된 것은 좋은 일일지도 몰라요. 왜냐하면 생태계에서 사용할 툴이 독자적으로 개발되도록 만들었을 뿐더러 옳은 추상화 방식도 찾아냈기 때문입니다. 그러나 종종 그때 당시 그냥 프로미스를 나뒀으면 좋았을텐데 생각합니다. 경솔한 선택이었어요.

2. 보안

다음 후회는 보안에 관한 것입니다. 자바스크립트는 파이썬과는 달리 매우 안전한 샌드박스이니깐요, 맞죠? 불행하게도 노드는 모든걸 그대로 보여주기 때문에 보안이라고는 1도 없습니다. 노드 프로그램을 실행하면 모든 시스템 콜에 접근할 수 있습니다. 안전한 서버사이드 런타임을 만들 기회였는데 그러지 못했습니다. 일부 상황에서 보안을 제공해 줄 수 있었는데 말이죠.

누구나 알다시피 디스크에 접근 권한을 주면 누군가 그 디스크를 악용할 수도 있습니다. 하지만 때로는 프로그램을 웹 브라우저 밖에서 돌리는데, 디스크나 네트워크에 접근을 원하지 않는 경우도 있죠. 예를 들어 린터(linter)가 있습니다. 규모가 큰 eslint 코드를 다운로드 받아서 내 컴퓨터와 상관없이 실행되면 좋을 텐데 말입니다. 코드 때문에 컴퓨터 권한에 대해 걱정할 필요 없이요. 그리고 그렇게 할 수도 있었지만 그러지 않았죠.