본문 바로가기

FrontEnd 공부/JS와 관련된 고찰

‘자바스크립트는 왜 프로토타입을 선택했을까’를 읽고 느낀점와 그 문제의 해답에 관하여

이글은 ‘자바스크립트는 왜 프로토타입을 선택했을까’라는 아티클을 읽고 작성한 글입니다.
아티클은 아래 링크로 들어가 확인하실 수 있습니다. 자바스크립트를 사용하는 개발자 / 개발 지망생 이라면 한번 쯤 읽어보시는 것을 추천드립니다.

 자바스크립트는 왜 프로토타입을 선택했을까

느낀점 

: 이 글을 통해 프로토타입기반의 언어가 클래스 지향언어와는 객체를 바라보는 방식이 전혀 다르다는 것을 알게되었다.

클래스

글에서 나온 클래스란 이분법적 사고 방식에서 나온 객체를 바라보는 방식이다

여기서 말하는 이분법적 사고방식이란

  • 남자 / 여자
  • 밖 / 안
  • 낮/밤

위의 예시처럼 대상을 두가지로 나누는 사고 방식을 뜻한다.

그래서 클래스 타입의 객체는 실존 하는 것 / 실제 하지 않는 것 으로 나누는 것이다. 실존하지 않는 클래스를 new를 통해 객체를 생성 하는 것으로 실존하는 것으로 만드는 것이 클래스 지향 언어인 것이다.

 

예를들어

곰은 새끼를 낳고 수유를 한다. 개는 새끼를 낳고 수유를 한다

라는 두 개체에 대한 설명이 있을 때, '새끼를 낳고 수유를 한다'는 두 공통된 특성을 ‘포유류’ 라는 하나의 범주로 묶는 것과 같이 개체와 속성이 동일한 경우 개체 그룹이 같은 범주에 속하는 것이 클래스 지향 언어의 특성이다

 

이와는 다른 방식으로 객체를 바라보는 것이 바로 프로토타입 기반의 언어이다.

프로토타입

프로토타입 기반 언어는 위의 클래스 기반 언어와 달리 가족 유사성을 기반으로 개체를 분류한다.

즉, 클래스처럼 공통된 특성을 정해두고 객체를 분류하는 것이 아니라, 전형적인 특징을 통해 분류하는 가족 유사성을 기반으로 개체를 분류한다

쉬운 설명을 위해 아티클에서 나온 가족 유사성에 대한 부분을 가져와보았다.

(본문)

위 그림처럼 가족이 있을 때 이 가족이 모두 공유하는 공통 속성은 없다. 갈색 머리, 안경, 수염, 큰 코가 가족의 전형적인 특징이라고 하더라도 모든 가족 구성원에게 적용되는 공통된 특성(속성)은 없을 수 있다.
그런데도 우리는 이 그림을 보고 전형적인 특징을 통해 ‘가족'으로 분류한다. 이런 분류 방식을 ‘가족 유사성' 에 의한 분류라고 한다.

 

글속에 나온 가족 유사성을 보고 한가지 예시가 생각이 났다.

그것은 바로 인공지능의 기계학습 부분에서 수박을 정의하기 어렵다는 글이다.

한번 수박을 모르는 사람들에게 수박에 대해 설명 하라고 하면 어떻게 할 것인가⁉️

 

우리가 기계한테 수박에 대한 특징을 알려줄때, 흔히들

크기가 크고 타원형 형태에, 겉은 초록색에 검은 줄무늬가 있으며, 안에는 붉은 과육이 존재하고, 씨가있다.

 

라고 설명을 한다.

 

그렇지만 현재는 겉이 노란 수박이 있고, 줄무늬가 없는 수박, 씨없는 수박, 과육이 노란 수박, 크기가 작은 수박 등등 굉장히 많은 종류가 존재한다.

그렇다고 이 수박들이 수박이 아닌 것인가? 그건 아니다. 그렇지만 위와같이 특정한 형태로 수박을 정의한다면 위의 여러가지 수박들은 수박이 아니게 되는 것이다.

그렇기에 기계는 이것들을 수박이 아닌 것으로 판단하지만 사람은 자연스레 가족 유사성을 통해 같은 것이라 판단한다.

(위의 특징들을 모두 하나로 아우르는 공통 성질을 찾기도 어려울 것 같다. -> 이처럼 ‘클래스도 공유속성을 잡는게 어렵지 않을까’란 생각이 들었다.)

 

나는 글을 읽어 내려가면서 ‘왜 프로토타입을 선택했는가’에 대한 답을 찾으려 했다. 위와 같이 기존의 클래스에서 객체를 바라보는 관점이 다르다는 이유만으로 자바스크립트가 프로토타입을 선택한 것일까? 물론 그럴수도 있다.

객체를 바라보는 관점이 기존의 클래스 방식과 자바스크립트를 만든 사람의 입장이 달라서? 아니면 분류기반의 클래스는 최적의 클래스 설계에 한계가 존재해서일까?

그렇지만 무언가 더 본질적인 이유, 확실한 이유가 있지 않을까 싶었고 그 이유를 찾고싶었다.

 

우선, ‘왜 프로토타입을 설정 했는가?’를 알기위해 어떠한 목적으로 자바스크립트를 만들게 되었는지 찾아보게 되었다. 자바스크립트의 초기 기획에는 혹시 무언가 단서가 있지 않을까⁉️

위키백과나 다른 구글링을 통해 나오는 문서에서는 나의 궁금증을 해결하기위한 충분한 답변이 없었기에

 

‘The Past, Present, and Future of JavaScript’라는 책을 보았다.

아래는 이 책의 한 부분이다.

JavaScript was influenced by several programming languages: The Lisp dialect Scheme gave it its rules for variable scoping, including closures. The Self programming language—a Smalltalk descendant—gave it prototypal inheritance (object-based as opposed to class-based).

 

이 책에 의하면 자바스크립트는 여러 언어의 영향을 받았는데, Scheme(Lisp - 최초 mark-and-sweep모델을 기반으로 자동 가비지 콜렉팅 수행))라는 언어에서 lexical scopeclosure의 개념을 가져왔고, Smalltalk(스몰토크)라는 언어에서 프로토타입 기반 상속을 가져왔다고 기술되어있다.

 

이렇게 계속 ‘프로토타입을 왜 선택했는지’에 대해 알아 보다가 아래와 같은 글을 보게 되었다.

해석을 하면 ‘흥미로운 일화는 JavaScript의 창시자인 Brendan Eich 가 그 당시 경영진이 JavaScript에 클래스를 포함하는 것을 허용하지 않았기 때문에 언어에 프로토타입 상속을 추가했다는 것입니다.’라는 내용이었다.

딱히 큰 이유가 아닌 초기 단계에는 class가 존재하지 않아서 프로토타입을 선택한 것이라니,, 가히 충격이었다.

 

즉, 자바스크립트가 프로토타입을 선택한 이유는 초기 단계의 자바스크립트는 class가 존재하지 않아서 였다.

 

이번 아티클을 통해 문맥을 이해하는 프로토타입언어의 성격으로 인해 lexical scope라는 용어가 나온 것이 이해가갔다. 처음 lexical scope를 공부 하였을 때 검색하면 나오는 것이 ‘어휘적인 범위’라는 말이었다.

 

이 글을 읽기 전까지는 뜻이 이해가 가지 않더라도 그냥 그렇게 부르니까 라고 받아드렸고 거의 영어 문법을 외우듯이 규칙들을 외워나갔지만, 프로토타입에 관한 이야기를 알고나니 왜 lexical scope라 하는지 이해가 갔다. 해당 변수가 주변 문맥에서 같은 의미로 사용 가능한 범위가 바로 lexical scope의 본래 의미라는 것이 와 닿았다.

 뿐만 아니라 자바스크립트에서의 호이스팅, lexical scope, this 등 어렵게만 느껴졌던 것들이 원리를 이해하게 되었다.

 

자바스크립트를 2년간 사용했고, 공부했지만 이렇게 본질부터 알게되니 어렵게 느껴졌던 개념들이 왜 존재하는지 알게 되었다. 자바스크립트를 사용하기 시작한 사람, 자바스크립트를 사용하고 있는 개발자들은 이 아티클을 읽어보지 않았더라면 꼭 한번 이 아티클을 읽어보기를 바란다. 자바스크립트의 새로운 세계로 다시 초대될 것이라 확신한다.

 

Reference