문득 궁금해졌다. 난 왜 node를 좋아할까? 뭐가 좋아서 node를 쓰고, 다른사람에게 node가 좋다 얘기하고 있었을까? 내가 왜 node를 좋아하게 되었는지 되짚어보기로 했다. 물론 "감정"이기 때문에, 개인적 경험을 토대로 한다. (때문에 잘못된 내용이 포함됐을 수 있다. 언젠가 이불킥의 원인이 되지 않을까?)
내 주변 사람들은 보통 java로 객체지향에 입문했다. 그래서일까? 객체지향을 얘기하면서도, Object가 아닌 Class에 집중해 혼란스러워하는 모습을 자주 볼 수 있었다. 물론 시간이 흐르고 이해가 깊어지면서 금방 사라진 성장통이지만, class 기반의 언어가 가지는 모순을 보여주는 좋은 예시라고 생각한다.
객체지향은 "객체"를 통해 프로그램이 동작하게 한다. 객체란건 굉장히 "구체적"이다. 각각이 모든 다른 상태를 가지고, 이 상태에 따라 행동의 결과가 달라져야 한다. 하지만 class 기반의 언어를 사용하게 되면, 당장 사용할 객체가 아닌 추상화된 class를 먼저 설계해야만 한다. 필요한게 무엇인지 이미 확실한 상황에서, 미래를 생각하며 보다 일반적인 성질을 끌어내는 불필요한 과정을 거치는 것이다.
하지만 js는 prototype 기반의 언어다. 객체가 필요한 상황이 오면, 객체를 만들어 쓰면 그만이다. 좋은 프로그램을 작성한다는 건, 좋은 구조를 생각한다는거고, 직관적인 구조가 좋은 구조라고 생각한다. 생각나는, 눈에 보이는, 떠오르는 그대로 프로그램을 작성할 수 있다는건 매우 큰 장점이다.
class 기반의 언어는 객체를 만들때, class를 "복제"한다. 때문에 class의 property는 instance 개수만큼 있다. 하지만 prototype 기반의 언어는 원본(prototype)을 참조한다. 때문에 모든 instance가 공유하는 속성은 원본 속에 존재한다. 그만큼 메모리를 절약할 수 있다.
맞다. class 기반 언어에 비해 안전성이 떨어진다는 사실을 부정할 수 없다. runtime에 prototype chain이 변경될 수 있기 때문에, 객체의 field를 확신할 수 없다. 하지만 그게 걱정할 정도로 심각할까? 내 짧은 경험으로는 초기화를 제외하고 runtime에 prototype chain을 수정해 본 적도, 그런 코드를 본 적도 없다. prototype이기에 불안하다는 말은, 추락이 두려워 비행기를 타지 못하겠다는 말처럼 느껴진다.
php의 등장으로 서버는 multi-process로 동작하기 시작했다. 그리고 java spring의 등장으로 multi-thread로 동작하며 메모리를 아꼈다. 이제 서버는 nodejs의 non-blocking으로 더 빨라졌다. 대부분의 시간이 DB I/O와 같은 CPU를 사용하지 않는 job으로 소요되는 Web Server의 특성 상, non-blocking으로 동작하는 nodejs의 성능은 훌륭하다.
맞다. AOT(Ahead of Time) Compiler 만큼 최적화할 수 없고 runtime에 interpreting 혹은 compile한다. 하지만 JIT(Just in Time) Compiler 또한 충분히 빠르다. JIT를 사용하기 때문에 Platform에 구애받지 않고, Hot Re-loading이 가능해진다. 앞으로 기술이 발전하다보면, JITC가 AOTC보다 빨라지는 날이 올지도 모른다.
또, 계산(CPU)집중적 job을 수행한다 하더라도, Hidden Class와 Adative JITC와 같은 개념을 알고 있다면 성능을 끌어올릴 수 있다. 개발자의 역량으로 어느정도 메꿀 수 있다는 것이다.
절차지향을 강요하거나, 객체지향을 강요하는 다른 언어와 비교했을 때, javascript는 굉장히 자유롭다. 함수가 일급 시민이기 때문에, 함수형 패러다임으로도 설계할 수 있다. (pipe operator도 지원한다!)
엄격하지 않은 문법은 때론 조롱의 대상이 되지만, 그만큼 새로운 기법을 도입하는 문턱을 낮춰준다. 가독성을 굉장히 신경쓰는 내게 있어서 새로운 문법을 추가해주는 js는 너무 고맙다.