10 Things I Regret About Node.js - Ryan Dahl - JSConf EU

영어 공부 겸 번역. 라이언 달 나름 재밌는 사람이구나!

---

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 코드를 다운로드 받아서 내 컴퓨터와 상관없이 실행되면 좋을 텐데 말입니다. 코드 때문에 컴퓨터 권한에 대해 걱정할 필요 없이요. 그리고 그렇게 할 수도 있었지만 그러지 않았죠.

3. 빌드 시스템

아마 빌드 시스템이 가장 후회되는 부분일 거에요. 고통스럽기 짝이 없습니다. 빌드 시스템은 만들기는 진짜, 진짜 어려운데 프로젝트 빌드라는 일은 아주, 아주 중요한 일입니다.

 

노드는 GYP라는 것을 사용합니다. GYP 아시는 분? 몇분 계시네요. C 라이브러리에 링크가 걸려있는 모듈을 작성하면 GYP라는 것을 사용해 C 라이브러리를 컴파일하고 노드에 링크합니다. 맞죠? GYP은 크롬에서 사용하던 것입니다. 크롬에서는 몇년 후 GYP은 버리고 GN 이라는 다른 툴을 사용하게 됩니다.

 

이것까지는 저희가 예측하지 못했죠. 그러나 그런 일이 일어나 버렸습니다.

 

 

그 일이 있고 많은 해가 흘렀는데, 노드만이 유일한 GYP을 사용합니다. 인터페이스가 구렸어요. 마치 파이썬에서 사용하는 JSON 파일이랄까. 아주 끔찍했습니다. 노드는 GYP를 몇 겹의 래퍼(wrapper)로 감싸 사용합니다. 그 중 하나로 node-gyp가 있습니다. 레이어를 레이어로 또 감싸서 불필요하게 복잡합니다. V8은 더 이상 GYP로 빌드하지 않습니다. 노드 지원 때문에 GYP 래퍼가 있는데 이거 때문에 너무나 많은 양의 불필요하고 복잡한 기술들이 사용됩니다.

 

그리고, 여러분, 솔직히 말해 저는 이게 노드의 가장 큰 기술적인 실패 중 하나라고 생각합니다. 어떻게 손을 써야만 해요. 이 시점에서 어느 길로 가야 좋은 선택인지 잘 모르겠습니다. 난제입니다. 노드가 지원할 소프트웨어가 많을텐데, 이 모두가 각자 확장 모듈을 컴파일해야 한다고 성급하게 결정 내려 버린 것이죠. 외부 함수 인터페이스를 사용하면 불필요하게 컴파일 하지 않아도 될텐데 말입니다. 비록 의존성은 갖추어야 하겠지만요. 그러나 이렇게 했다면시스템 라이브러리 링크를 하려는 사람들에게 훨씬 더 자연스럽고 쉬운 인터페이스가 되었을 겁니다. Bryan Cantrell을 비롯한 많은 사람들이 저에게 그렇게 조언을 이미 했었어요. 그러나 완전히 무시했습니다.

 

그리고, 네, libuv는 autotools로 들어가 버렸는데 용납하기 힘들고 유감스럽습니다. 누가 했는지 알죠? 제가 안했습니다. 다른 누군가가 후회할 겁니다.

4. package.json

다른 것도 있습니다. package.json! 현재 자바스크립트의 생명줄과도 같은 것이죠. (근데, 언제는 또 그렇지 않을 때도 있습니다.)

 

package.json은 스펙이 있긴 하지만, NPM의 Isaac이 정의를 거의 다 만들었고, 제가 사용 허가를 내린 후 노드 문법 중 require로 인해 널리 알려지기 시작했습니다. 이는 package.json을 보고 파일을 찾아볼 때 사용하는 구문이죠. package.json은 노드 프로그램에 필요한 존재가 되었고, 그 전에는 아니었으나 결과적으로 npm을 노드에 포함시켰기 때문에 npm은 표준 노드 배포 서비스가 되었습니다.

 

네, 그리고 이 깜찍한 추상화에는 문제가 있습니다.

 

자바스크립트 프로그램에서 어떤 모듈을 require할 때는 이 모듈이 무엇인지 완전히 쓴 게 아닙니다. package.json에도 모듈이 정의되어 있어야 합니다. 이 파일은 resolution 알고리즘의 일부로, 어떤 버전의 모듈을 설치하고 말아야 하는지 적혀 있습니다. 그리고 node_modules 폴더도 있는데 모듈 resolution을 담당하는 폴더입니다. 보시다시피 패키지 연결하는데 시스템, 즉 컴포넌트가 많이 필요합니다.

 

자, package.json로 인해 생기는 문제는, 이 때문에 디렉토리 파일로 된 모듈 개념이 만들어졌고, 모듈이라는 것은 이전에는 정식 개념이 아니었습니다.그냥 자바스크립트 파일이 있었을 뿐입니다. 웹에서 자바스크립트를 script 태그로 여기저기에 포함시켰습니다. 그냥 그런거였죠. NPM처럼 모듈 패키지라는게 없었습니다. 필요한 추상화가 아니였죠.

 

package.json 때문에 이 모든 불필요한 잡음이 생기게 되었습니다. 라이센스, 저장소... 내가 지금 이걸 왜 작성하고 있지? 같은 느낌이죠. 마치 무슨 회계 장부 작성하는거 같습니다. 나는 그저 라이브러리 연결하고 싶은 건데, 이 모든 불필요한 일들을 해야 합니다. 이따가 상대적인 URL에서 다시 이야기 할게요.

5. node_modules

당연히 노드 모듈은 매우 커져 버립니다. 벤더링을 기본으로 하는 것 때문에도 그래요. 로컬 프로젝트 폴더에 모듈이 설치되기 때문에 프로젝트가 여러개 있으면 node_modules 폴더가 여러개 생성되기 때문에 더욱더 커집니다. 제가 제안한 아이디어였죠. 후회하고 있습니다.

 

모듈명 resolving 알고리즘은 그냥 미친 듯이 복잡합니다. 시간이 지날수록 더 그래졌기 때문에 후회스럽습니다. node_modules 폴더 뒤에 깔린 개념인 vendored-by-default(서드파티 라이브러리를 디폴트로 같이 설치하는 거)는 의도는 좋긴해요. 연결하는 상대가 어떤 것인지 정확히 알 수 있잖아요. 분명하게 명시하려는 의도였어요. 그러나 실제로는 NODE_PATH, PYTHON_PATH 같이 적는 게 나았을 겁니다. 그렇게 벤더 라이브러리를 설치 했어도 되었을 거에요. 환경 변수 설정 하듯이요.

 

지금 방식은 브라우저 작동 방식에서 크게 벗어났습니다. 그건 제 잘못입니다. 매우 미안하게 생각합니다. 그러나 불행하게도 취소할 방법이 없네요.

6. 확장자 없는 require("module")

그리고, require 모듈에 확장자 추가 안하고 있는 거를 말해야겠네요. 왜죠? 불필요하게 불분명합니다. 파일 시스템에 이리저리 이런거 저런거 캐묻고 다녀야해요. .js 말하는 거니? .ts? .어쩌구 저쩌구?

 

아니, 그냥... 좀... 확장자를 쓰란 말이에요!

 

[청중 박수] 👏 👏 👏

여러분이 제 말에 동의를 하시니 기쁘네요. 아직 이에 대해 토론이 진행 중입니다. 막 한 쪽에서 "사람들은 확장자 리스트를 좋아합니다. 더 깔끔하기 때문이죠." 이러면 다른 쪽에서는 "아닌데!" 이러고 ㅎㅎ

7. index.js

아, 그리고 index.js 죄송합니다. 이러면 귀여울 거 같았어요. 왜, index.html 있잖아요. 디렉토리 include 할 때 index.js 살펴보면 좋을 거 같았어요. 불필요한 도입 이었죠.

 

나이 들어가는 와중에 배운 게 있는데, 프로그램 설계할 때 추가하면 깜찍해 보이는 것들이 있어요. 진짜 하면 나중에 항상 후회합니다. 필요하지 않는데 그냥 좋아 보인다면, 하지 마세요.

왜 이런 문제가 발생했나?

제가 생각하는 노드의 문제점 중 IO에 관한 것은 별로 없네요. 그리고 솔직히 말해, 저는 노드가 좋습니다. 그걸로 프로그래밍하는게 좋아요. 비교적 좋다 생각해요. Unix 같은 거라 생각해요. 제가 생각하는 노드의 문제는 모듈 시스템과 사용자 코드 관리 방식에 관련된 것들입니다.

이런 문제가 발생하는 주요 원인은, 노드를 만들 당시에 제가 IO 관련한 것에 온 집중을 다하고 있었기 때문이죠. 거기에 아주 격렬하게 집중하고 있었기 때문에 모듈 시스템은 그냥 단순히 뒷전 이었던 것이죠. 나중에 사용자들이 필요하기 때문에 추가된 것입니다. 그래서 노드의 현재 작동 방식에 이런 설계가 반영되어 있는 거죠.

Deno 소개

이런 것들을 염두에 두고 이 발표 원고를 준비했습니다. 부정적인 사람 같죠. 최소한 프로토타입 같이 뭐라도 대안을 만들어서 내놓지 않고서 사람들 앞에 서서 불평을 늘어놓는 건 형편없는 일이라 생각해요. 노드를 지금 설계했다면 어떻게 다르게 동작할 수 있는지, 혹은 어떻게 달라졌을지 설명하는 프로토타입 같은 거 말이에요.

 

그리고 제가 드릴 당부의 말은 앞으로 보여드릴 코드를 어디가서 사용하지 마시라는 겁니다. 지금 시점에서는 매우, 매우 쓸모 없는 코드입니다. 하는 일이 아무것도 없어요. LLDB에 아주 조예가 깊으신 분이 아니라면 빌드하지 마세요. 그래도 혹시나, 보고 싶은 분들을 위해 Dano는 V8 위에서 돌아가는 안전한 타입스크립트 런타임입니다. tag line 위에서 돌아가나? 그건 잘 모르겠네요. 나온지 한달 된 신생 소프트웨어 입니다. 이건 그냥 제가 생각하는 요즘 방식의 좋은 서버 런타임을 주저리 주저리 써놓은 거라 생각해 주세요.

보안

EventIO는 당연히 고려 대상입니다. 하고 싶어요. 해야만 해요. 또 중요한게 뭐가 있을까요? 다른 하나로는 보안이 있습니다. 자바스크립트가 안전한 샌드박스라는 것을 이용하면 좋을거 같아요. 기본적으로는 스크립트가 네트워크나 파일 시스템 쓰기 권한이 없도록 하고 돌아게끔 만들고, 그 후에 사용자가 다양한 권한을 설정할 수 있게 하는거죠. 그래서 만약 네트워크 접근하고 싶으면 --alow-net 명령어를 사용하는 거죠. 그러면 필요한 사람들은 이렇게 하면 되구요.

메시지 패싱

그리고 생각보다 코드가 실행되는 시스템에 너무 많은 권한을 주고 싶지 않은 경우가 꽤나 흔해요. 자바스크립트가 런타임이기 때문에 할 수 있게 되는 겁니다. 시스템과 V8이 운영체제를 건드릴 수 없게 합니다. 임의의 네이티브 함수가 V8에 바인드 되지 않았으면 해요. 모든 시스템 콜은 메시지 패싱을 통해 이루어집니다. VM을 들락거리는 단일 진입점이 있는데, 여기저기 다 들락거리는 노드와는 다릅니다.

 

단일 진입점이 없기 때문에 노드에서는 내부에서 벌어지는 일을 추적하기 힘듭니다. 이 때문에 문제가 많이 발생하는 겁니다. 도메인 등을 다룰 때 말이죠. 메시지 주고받는 방법과 관련해 V8 안에는 단 두 가지 네이티브 함수가 있습니다. send, receive죠. receive는 콜백을 받고, send는 메시지를 보냅니다. 노드에서 이런 메시지 패싱 방식을 갖춘다면 좋을거라 오랫동안 생각했어요.

 

 

이게 오랜 시간 고민한 생각을 크게 적어본 것입니다. 당시 Go로 쓰인 Deno 프로세스가 있고, 그런데 이게 지금 맞는 선택인지는 아직 고민중이긴 해요. 그리고 그 안에는 실행 중인 V8이 있습니다. V8에 바운드 된 send, receive 콜이 있네요. 이를 통해 protobuf 메시지를 보내고 받을 수 있습니다. 버퍼 배열로요. 아, 배열 버퍼입니다.

 

그리고 다양한 많은 모듈에 메시지를 보내는 디스패처가 있습니다. 그래서 권한 부여 받은 모듈과 안 받은 모듈 양쪽 모두의 싱크를 맞출 수 있고, Go로 된 부분에서 시스템 콜을 처리한 후에, setTimeout 요청을 sleeper 뭐시기로 전환합니다. V8에도 비슷한 모듈 시스템이 있습니다.

타입스크립트 컴파일러

V8 내부에는 사실 타입스크립트 컴파일러가 있습니다. 실행 파일 안에 내장되어 있어요. 저는 타입스크립트를 사랑합니다. 진짜 최고에요. 마이크로소프트에서 이거 만든 줄 몰랐어요. 진짜 실용적입니다. 잘 만들었고, 사용하기도 좋고, 이미 있는 자바스크립트 코드에 슬며시 들어가 천천히 타입스크립트로 전환할 수 있다는 게 너무 맘에 들어요

 

이게 바로 Dart의 목표 중 하나였죠. Dart 아세요? 완전 망했어요! 맙소사. 의도는 엄청 좋고 쿨해 보였지만, 현재로서는 실패했다고 할 수 밖에 없습니다.

 

타입스크립트는 접근법을 완전히 달리 했어요. 자바스크립트로도 완전히 돌아가게 만들었고 많은 사람들이 흡족해 할 만한 방법을 택해 문제를 풀었습니다. 아직 타입스크립트 접하지 않았다면, 부디 한번 해 보시길 바랍니다. 저는 이 프로젝트에서 타입스크립트를 사용하고 싶었어요. 좋아서요.

모듈 시스템

그리고, deno의 모듈 시스템도 간단하게 만들고 싶었습니다. 그러니 노드 모듈 시스템을 비롯한 그런 것들은 전부집어 치우라 하세요.

아, 그런데 노드랑 비교할 수는 없겠네요. 그러다가는 또 다른 노드를 만들게 될테니깐요. deno를 현재 있는 소프트웨어와 비교하려는 시도는 하지 않겠습니다. 이건 그냥 사고 실험 입니다.

import

소스 코드 위치에서 바로 import 하면 깜찍하지 않을까 생각했어요. 웹에서 하는 것처럼요, 그죠? 소스 파일이 있다고 해봅시다. 소스 파일 연결하면 프로그램에 연결이 된 겁니다. 상대적인 경로로 include 하면 그냥 그렇게 한 거구요. 확장자는 반드시 써야 합니다. 이렇게 생각할 수도 있어요. "아, 나 이 소스 코드 나 때문에 바뀌는거 싫은데. 뭔가 구린거 같은데." 그렇지 않습니다.

 

이렇게 작성했는데 URL에 대한 파일을 로드 할 수 없다면 다운로드가 시작됩니다. 그리고 어딘가에 캐시됩니다. 그리고 다시는 업데이트 되지 않습니다. 다시 실행하면 같은 코드를 사용하게 되겠죠.그런데, 브라우저처럼 다시 불러오기를 할 수 있습니다. 네 이거는 새로고침 키를 누르는 손짓입니다. --reload를 사용하면 되어요. 캐시 파일을 전부 처음부터 다시 불러오는 용도입니다. 덧붙여 서드파티 코드는 다운로드 위치를 다르게 지정해서 분리할 수 있습니다. 잘 될 것 같아요.

 

발표에서 ctrl + R 수신호를 시연하는 라이언 달

최적화

타입스크립트는 바로 사용 가능 해야 합니다. 자바스크립트는 명백하게 그럴 수 있죠. 음 근데 타입스크립트는 자바스크립트의 확대 버전이니 이건 그렇게 중요한 말은 아닙니다. 현재는 서버 시동 시간이 1초로 꽤 긴데, 완전 곤란한 상태죠. 그래서 V8 스냅샷을 사용해 전체 컴파일러 스냅샷을 뜨려고 작업하는 중입니다. 그리고 다른 최적화 작업도 해야만 하죠. 개선이 기가 막히게 되리라 확신합니다.

단일 실행 파일 with parcel

아, 그리고 저는 파일을 전부 실어 나르는거 싫어해요. 진짜 싫어요. 단일 실행 파일로 만들어야 할거 같아요. 그래서 다른 것과 너무 많이 연결하지 않은 실행 파일로 만들어 그냥 그 파일 다운로드 받고 실행 하게끔 만들어야 합니다.지금 우리는 미래에 살고 있으니 미래의 장점을 사용해 보자 구요. 훌륭한 것들 사용해서요. 예를 들어 노드의 빌드 프로세스는 파일 require 정의 설정해서 그 파일들을 또 번들링 하는 과정이 복잡해요. 그리고 또 그거를 전부 V8에 로드해야 하잖아요.

 

그러나 이제 우리에게는 진짜 훌륭한 parcel이 있습니다. 그러니 이제 해야 할 일은 일반 노드 프로그램 구조를 deno의 내부 시스템으로 만들고 parcel을 그 위에서 돌려 하나의 파일로 컴파일 하는 겁니다. 결과물은 노드의 모듈 resolution scheme을 사용하겠지만 자바스크립트 번들 파일이 이제 하나가 될 수 있습니다. 그거를 V8에 부으면 됩니다. 이렇게 하면 전체 빌드 과정이 훨씬 간단해 질거에요.

브라우저

그리고 훌륭한 인프라가 네이티브 코드에 있어요. 지금은 노드 코드로 웹 서버를 작성하고 있잖아요. HTTP parser 작성하는 데 시간을 많이 쓰죠. 이제 그렇게 할 필요가 없습니다. 이제 끝난 일이에요. Go로 만들어서 겁나 좋은 Go HTTP 루틴을 연결하면 됩니다. 아니면 Rust나 C++을 쓰던가요. 둘 중 하나를 사용하면 하이 레벨 코드에 쉽게 링크를 걸 수 있습니다. 하이 레벨 네이티브 코드죠. 덕분에 지금 하는 일들이 매우 쉬워질 거 같아요.

기타 등등

이제 살짝 잡다한 것들인데, 프로미스 처리 안하면 바로 죽어버리는 것 있잖아요. 아니 누가 "catch 핸들러 나중에 추가할까? 지금 당장은 죽지 않으면 좋겠어!"라고 생각하겠어요? 아니죠, 에러가 나는 즉시 죽어야 합니다. 최상단 await를 지원해야 할텐데. 지금 작업 중이에요. 어렵지 않습니다.

 

그리고 브라우저와 호환 가능하도록 만드는 거에요. 한때 노드 하면서 window는 전역 변수 이름으로 사용하기 진짜 멍청한 이름같다고 생각한 적이 있어요. 왜 윈도우라 하죠? 윈도우라 하면 안되고, "global"이라 불러야 해요. 이렇게 생각했죠. 왜 그랬나 모르겠네요. 지금 브라우저와 호환 문제가 있으니 그렇게 생각하는 건 실수였어요. Deno가 브라우저와 사용될 때는 브라우저 문법을 따라야 합니다. 브라우저 함수, 브라우저 변수명, 기타 등등.

마무리

시간 되면 여기 한번 봐주세요. 잘 모르겠지만, 여튼 프로토타입 입니다. 현재까지는 살짝 만족스러워요. 생각이나 질문이 있다면 지금 질문 못해도 이메일로 보내주세요. HTTP 서버 처음으로 구현하시는 분께 별을 드리겠습니다!

 

이제 할 말이 바닥났어요. 아직도 3분이나 남았네.

 

네, 여러분, 이 자리에 저를 불러 주셔서 감사합니다.