이 시리즈는 You Don't Know JS Yet (1판인 You Don't Know JS의 개정판) 을 가지고 스터디를 진행하면서 요약 정리한 글입니다. 내용에 대한 퀴즈도 깃헙 리포지토리에 올리고 있으니 참고하시면 더 도움이 되실 것 같습니다. 내용에 대해 오류가 있거나 궁금하신 점이 있다면 댓글 달아주세요!
What's With That Name?
'Javascript'라는 이름 자체는 잘못 지어지고 혼동하기 쉬운 언어라고 한다. 익숙한 Java 사용자들을 끌어들이기 위해서, 가벼운 프로그래밍 언어라고 생각이 드는 접미사 'script'를 붙어서 이름을 지었다고 한다. 다만 다른 기본적인 언어들(Java나 C)과 뼈대는 같아 이를 유추할수 있다고 한다. 요즈음엔 JS specs를 정하는 TC39의 소속단체인 ECMA를 따 ECMAScript라고도 부른다.
Language Specification
위에서 언급한 TC39에선 매년 새로운 스펙을 내놓은데, 올해의 경우 ES2020이 나온 상황입니다. 스펙에 대한 제안은 누구나 가능하며, 제안된 스펙에 대해 깃헙에서 활발하게 의견을 공유하고 있습니다. 다만 이 스펙이 실제 ES에 올라가는 것은 TC39 위원회에서 결정합니다. 제안된 스펙은 Stage 0부터 시작해 논의를 통해 Stage 4까지 가게 된다면 공식적인 스펙으로 들어가게 됩니다.
JS는 다른 언어와 다르게 단 하나의 공식 표준인 ECMA만 존재합니다. 이렇기 때문에, 스펙 걱정 없이 하나의 스펙으로 JS를 작성할 수 있습니다. 다만, 이를 활용하는 환경에 따라 추가되는 스펙이 다릅니다. 대표적으로, console.log() 함수는 JS 스펙에 적혀있지 않습니다. 이를 확장해서 생각한다면, 많은 개발자들이 이야기하는 'JS는 일관성이 없어!' 라는 말은 환경에 따라 달라지는 JS를 이해한다면 더이상 말하지 않아도 될 것 같습니다 😉
환경에 대해서라면, 개발자분들은 브라우저에서 제공하는 콘솔(대표적으로 크롬 개발자 툴)을 생각하실 겁니다. 다만 콘솔은 스펙을 100프로 지키는 툴이 아니라, 편의를 위해 존재하는 툴입니다. 스코프나 var 변수, use strict, 호이스팅 등을 사용한다면 기존 스펙과 다르게 작동할수 있다는 것을 생각해야 합니다.
Many Faces
JS는 다양한 페러다임을 제공합니다. 대표적으로 순차적(Procedural), 객체지향, 함수형 프로그래밍이 있습니다. 다른 언어들은 이러한 패러다임 중 한가지만 구현 가능하게 만들어져있는데, JS는 다양한 패러다임을 구현할 수 있도록 도와줍니다.
Backwards & Forwards
JS는 하위호환(Backwards Compatibility)를 지원하지만, 상위호환(Forwards Compatibility)를 지원하지 않습니다. 두 용어가 정리할 때에도 햇갈리는데, 이번에 마지막으로 정리하고 더 이상 햇갈리지 말도록 합시다!
하위호환이란 이전 버젼에 구현된 스펙들에 대해 다음 버젼에서도 정상 작동된다는 것을 보장한다는 것입니다. 예전 ES6에 작성해놓은 (에러가 없는) 코드들을 ES2020로 돌란다고 해서 에러가 나지 않는다는 것입니다. 그렇기 때문에 TS39에서도 스펙을 공식 승인하는 것을 여러 절차를 통해 진행되는 것입니다. 한번 정해진 스펙은 변경되면 안되고, 수정도 안되기 때문입니다.
반대로 상위호환은 새로운 버젼에 들어간 스펙을 사용한 코드를 이전버젼으로 돌려도 에러 없이 돌아간다는 것입니다. 다시 한번, JS는 상위호환을 지원하지 않습니다. 상위호환을 지원한다는 것이 구 버젼에서도 신 버젼의 기능이 작동되는 것은 아닙니다. 대표적으로 HTML과 CSS는 상위호환을 지원하는데, 신 스펙을 구 버젼에서 돌릴 때 이 기능은 작동되는 것이 아니라 하지만 아직 생략해 작동됩니다. 반대로 JS에서는 ES6에서 ES2020에 추가된 BigInt를 사용한 코드를 돌린다고 하면, 돌아가지 않고 에러가 발생하게 됩니다.
그렇다면 상위호환을 지원하지 않는 JS에서 이와 비슷한 (하위 버젼에서 돌려야 하는) 상황이 온다면 어떻게 해결해야 할까요? 이런 상황을 겪은 많은 개발자들이 다양한 해결책을 내놓았는데, 대표적으로는 Transpiling과 Polyfill이 있습니다. Transpiling은 작성한 코드를 변환해, Polyfill은 스펙을 비슷하게 구현해 코드에 추가해 구 버젼에서 신 스펙을 사용할 수 있습니다.
반대로 생각한다면, 그냥 구 스펙을 사용해 위 방법을 사용하지 않아도 되지 않을까 생각이 들기도 했고 저도 이 책을 읽기 전에는 같은 생각을 했었습니다. 이에 대해 책에서는 코드가 클린하고 최대한 유용하게 소통하기 위해 JS는 항상 최신 스펙을 사용해야 된다라고 이야기하고 있습니다. 위 방식을 불편해 하지 않고, 최신 스펙을 사용해 더욱 생산적으로 코드를 작성할 수 있다고 합니다.
What's in an Interpretation?
JS가 컴파일 언어인지 인터프리터 언어인지 항상 논란거리입니다. 이를 이해하기 위해 두 언어의 실행 방식을 비교해봅시다.
인터프리터 언어의 경우 다음 그림과 같이 작동하게 됩니다. 주로 'top-down', 'line-by-line' 방식이라고도 하며, 한줄한줄 실행하며 결과물을 만들어냅니다. 다른말로는, 5번째 줄에 에러가 존재해도 1~4번째 줄에 영향을 끼지치 않고 작동됩니다.
반대로 컴파일 언어의 경우에는 바이너리 파일로 만드는 과정 중 코드를 파싱(Parsing)해 추상 문법 트리 (Abstract Syntax Tree)로 변환하는 과정을 거칩니다. 아까 5번째 줄에 에러가 존재하는 상황이 컴파일 언어에 발생된다면, 파싱 과정에서 에러가 발생합니다.
그렇다면 JS의 작동 방식을 보면서 비교해볼까요? 그림을 보면 컴파일 언어와 비슷한 방식으로 작동되고, AST도 만들게 됩니다. 다만, 실행 과정에서 JS M을 사용해 작동해 이를 인터프리팅하고 있지 않나 생각할 수 있습니다. 그러나 Java도 역시 VM을 사용해 작동이 되기 때문에 VM을 사용한다고 해서 인터프리팅 언어라고 정할 수는 없습니다. 그러기 때문에 책에서는 JS는 컴파일 언어다 라고 주장하고 있습니다.
Strictly Speaking
2009년에 출시된 ES5에서 strict 모드가 추가되었습니다. strict 모드를 사용하는 가장 큰 이유는 최고의 코드를 작성하기 위해 추가해야 합니다. 모드를 켜 놓으면 에러들도 사전에 방지할 수 있고 성능상으로도 좋은 코드를 작성할 수 있다는 것입니다.
이 모드는 파일 전체적으로 사용할 수 있고, 함수 스코프 내에서도 사용할 수 있습니다. 함수 스코프 내에서 사용하는 유일한 이유는 이전에 strict 모드가 없는 코드에서 약간의 수정이 필요할 경우에만 사용합니다. 그러므로 strict 모드를 주로 전체 파일에 사용하는 것을 추천합니다.
