[javascript] 새로운 자바스크립트가 이전 자바스크립트와 다른 11가지 이유

자바스크립트는 세계에서 가장 성공적이고 다재다능한 프로그래밍 언어 중 하나지만 처음부터 그랬던 것은 아니다. 지금의 자바스크립트는 자바스크립트를 만든 사람들이 원래 구상했던 언어와 완전히 다른 언어다. 그 11가지 이유를 살펴보자.

1995년 큰 꿈을 갖고 모인 소수의 프로그래머들이 자바스크립트를 출범했다. 원래 이들이 생각했던 이름은 모카(Mocha)나 라이브스크립트(LiveScript)였지만 유행에 밝았던 몇 사람이 이미 상당한 인기를 끌고 있던 자바 언어의 시류에 올라타기로 했다.
 

새로운 스크립팅 언어의 처음 목표는 단순해서, 정적 웹 페이지에 생명력을 좀 불어넣자는 것이었다. (당시 웹 페이지에서 움직이는 부분은 <blink> 태그밖에 없었다. 이 태그는 오래전에 사라졌지만 아직 기억하는 사람이 있을 것이다.) 그때 자바스크립트 개발자는 양식 요소를 이중으로 확인하기 위해 만들어진 아주 작은 레이어 하나가 이후 소프트웨어 배포의 주된 방식이 될 것이라고는 꿈에도 생각하지 못했을 것이다.
 
현재의 자바스크립트 버전에서는 이 1세대 스크립팅 언어의 흔적을 거의 찾아볼 수 없다. 오래된 코드도 대부분 웹사이트에서 여전히 실행되지만 초창기부터 지금까지 수많은 기능과 레이어가 추가됐다. 자바스크립트의 역할과 책임의 범위도 훨씬 더 커졌다. Node.js 덕분에 자바스크립트는 웹 페이지 전용을 넘어 서버측 스택의 큰 부분을 차지하면서 이제 <blink> 태그 또는 고양이 밈과는 아무런 관계도 없는 코드를 실행하고 있다. 암호화폐 애플리케이션, 의료, 주식거래 봇을 비롯한 수많은 작업이 자바스크립트에 의존한다.
 
30주년을 눈앞에 둔 자바스크립트 언어가 그 사이 얼마나 변했는지 돌아보자. 지금 우리가 사용하는 자바스크립트는 다음과 같은 11가지 측면에서 이 언어를 만든 이들과 초기 도입자들이 상상했던 언어와 완전히 다르다.
 

더 이상 자바스크립트로 불리지 않음

처음에는 모두가 자바스크립트라고 불렀다. 지금도 대부분의 개발자가 이 이름을 사용한다. 그러나 표준을 만드는 사람들이 공식적으로 사용하는 이름은 ECMA스크립트다. 일부는 규범적 언어 사양의 공식 버전 번호(최대 14)까지 명시한다. ECMA스크립트는 입에 잘 붙지 않고 따뜻한 커피를 연상시키지도 않지만 자바스크립트를 자바와 확실히 구분해준다. 이 이름을 사용함으로써 자바스크립트 개발자는 자바 상표, 로고 또는 기타 트레이드 드레스에 대해 걱정할 필요가 없다. 단, 이 사양을 유지관리 주체인 ECMA 인터내셔널(ECMA International)은 이름 옆에 작은 등록 상표 기호를 붙이는 것을 좋아한다는 점만(ECMAScript®) 예외적으로 주의하면 된다.
 

너무 방대해서 특정 부분의 전문화 필요

지금의 자바스크립트는 너무 방대해서 누구도, 심지어 매일 자바스크립트를 사용하는 개발자라 해도 모든 부분을 아는 것은 불가능하다. 서버 측 옵션과 동형(isomorphic) 코드의 등장으로 새로운 에너지가 유입되고 많은 개발이 이뤄져 한 사람이 브라우저 또는 서버를 위한 코드 작성의 세세한 부분을 모두 알기가 극히 어려워졌다. 

이론적으로는 브라우저와 서버에서 모두 실행되는 코드를 쓸 수 있지만 현실에서 개발자는 브라우저 또는 서버 하나에 대한 전문성을 갖추는 데 집중한다. 개발자는 흔히 자신이 브라우저 기반 자바스크립트 프레임워크, 서버 측 자바스크립트, 또는 데이터베이스 측 자바스크립트를 다룬다고 구분해서 말한다. 자바스크립트 세계는 방대하다.
 

관건은 프레임워크

서버 세계와 브라우저 세계로 나누는 것 외에도 자바스크립트 개발자는 프레임워크 단위로 자신의 전문 분야를 좁히는 경향이 있다. 많은 구인 공고는 "자바스크립트" 프로그래머를 구하지 않는다. 이들은 리액트, 앵귤러를 비롯해 많이 사용되는 10여 개의 자바스크립트 프레임워크를 다룰 줄 아는 사람을 찾는다. 실용적인 결정이다. 

프로그래머는 성공하려면 이러한 프레임워크의 세세한 특성에 정통해야 한다. 물론 자바스크립트의 기본도 알아야 한다. 그러나 앵귤러가 HTML 속성을 어떻게 사용하는지 모른다면 자바스크립트 전문 지식을 아무리 많이 갖고 있어도 도움이 되지 않는다. 앵귤러, 리액트와 같은 대형 프레임워크도 너무 커지고 복잡해져서 일부 프로그래머는 상태 관리 툴(리덕스(Redux), 몹액스(MobX)) 또는 기본 모델 옵션과 같은 자바스크립트의 하위 영역에 집중하는 더 작은 툴에 대한 전문성을 키우고 있다.
 

동형

자바스크립트의 인기가 큰 폭으로 늘어난 계기 중 하나는 Node.js를 통해 서버에서 실행되는 자바스크립트 코드를 작성할 수 있게 된 것이다. 한 팀이 브라우저 소프트웨어를 처리하고 다른 팀이 서버 측을 관리할 필요가 갑자기 사라졌다. 동일한 코드를 두 위치에서 동형으로 실행할 수 있게 되면서 자바스크립트 개발자는 브라우저에서 서버로, 다시 브라우저로 훨씬 더 쉽게 함수를 옮길 수 있게 됐다. 

잠깐, 조금 전에 자바스크립트 세계가 두 갈래, 세 갈래 또는 그 이상으로 분화되고 있다고 말하지 않았던가? 맞다. 그러나 동형성은 여전히 가치 있다. 암호화와 같은 작업을 위한 많은 기본적인 함수는 다양한 영역에서 동일하게 실행이 가능하다. 물론 프로그래머는 한 틈새 영역에 대한 전문성을 키울 수 있지만 코드 자체는 모든 틈새 간에 아무런 제한 없이 흐를 수 있다.
 

다수의 새로운 연산자

원래의 자바스크립트에는 데이터 객체를 다루기 위한 간단한 기능이 몇 가지 있었다. 최신 버전은 데이터 구조를 분할하고 쪼개고 확장하고 변경할 수 있는 스프레드 연산자(…), map과 같은 추가 기능을 지원한다. 그 결과 매우 간결하면서도 매우 강력한 코드를 얻을 수 있다. 프로그래머는 복잡한 데이터 구조를 포장하고 풀기 위한 끝없는 루틴을 쓰지 않고도 손쉽게 이러한 구조를 제공할 수 있다. 코드는 더 간소하고 빠르며, 새로운 구문을 안다면 읽기도 더 쉽다.
 

모든 곳에 있는 JSON

초기 자바스크립트 프로그래머는 데이터를 공유하려면 파싱하고 직렬화할 수밖에 없었다. 이후 어느 영리한 사람이 네이티브 자바스크립트 객체 형식(JavaScript Object Notation, 즉 JSON)이 효율적인 동시에 속도도 빠르다는 사실을 발견했다. 자바스크립트 스택은 JSON을 사용해 저장된 데이터를 다른 대부분의 형식보다 더 빠르게 파싱할 수 있었다. 지금은 자바스크립트 코드를 쓰지 않는 프로그래머도 유연성과 효율성을 이유로 JSON 형식의 데이터를 사용한다. JSON은 모든 곳에 사용되지만, JSON을 빠르게 파싱하고 객체로 변환하는 자바스크립트 환경에 사용될 때 가장 잘 맞는 느낌이다.
 

빌드와 빌드 툴

초기 사람들은 텍스트 편집기로 자바스크립트를 쓰고 브라우저에서 테스트했다. 현대 자바스크립트 애플리케이션은 조금 더 복잡하다. 대부분의 경우 그런트(Grunt), 걸프(Gulp), 웹팩(Webpack)과 같이 다양한 구성요소를 최종 실행 스택으로 엮어주는 다단계 빌드 툴이 필요하다. 많은 개발자가 결국 코드를 테스트하고 충돌 가능성이 있는 버그를 확인하는 전체 CI/CD 서버를 사용하게 된다.
 
자바스크립트의 빌드 툴은 매우 강력해서 개발자와 일종의 애증의 관계에 있는 경우가 많다. 이들이 작성하는 코드는 분석을 거쳐 실제로 실행되는 형식으로 어셈블링되기 전까지는 아무 데서도 실행되지 않는다. 기술적으로 자바스크립트는 여전히 동적 스크립팅 언어지만 오래된 C 컴파일러보다 빌드에 더 오랜 시간이 걸리는 경우가 종종 있다.
 

JIT 컴파일

지금은 처리와 전처리가 스택의 위아래에서 이뤄진다. JIT(Just-In-Time) 컴파일러는 처음 등장할 때부터 자바스크립트의 잠재력을 끌어냈고 지금도 계속 개선되고 있다. 현재의 컴파일러는 코드가 실행될 때 반복적으로 이를 분석해서 대부분의 작업을 수행하는 알고리즘의 핵심 부분을 개선할 수 있을 만큼 똑똑하다. 가비지 수집에서 효과적이며 피해를 입히는 여러 가지 동작을 차단한다. 스크립팅 언어로 시작된 언어임을 감안하고 보면 자바스크립트의 JIT 레이어는 공식적으로 "컴파일되는" 언어만큼 강력해 보인다.
 

형식 안전성

자바스크립트 초창기 일부 프로그래머는 각 변수에 저장되는 데이터의 형식을 정의하기 위해 부가적인 입력이 필요하다는 점을 싫어했다. 여전히 기본 자바스크립트를 사용한다 해도 자유지만 이제는 상당히 많은 개발자가 타입스크립트와 기타 자바스크립트를 위한 형식 지정 옵션을 수용하고 있다. 이러한 프리프로세서는 형식 규칙, 그리고 이 규칙에 수반되는 모든 안전 장치를 적용한다.
 

방대한 라이브러리 생태계

오늘날 자바스크립트 생태계에는 폭과 깊이를 가늠하기 어려울 정도로 방대한 라이브러리가 번성 중이다. 수천, 수백만 가지의 애플리케이션을 위한 코드가 있다. 기본적인 프로젝트를 위한 빌드 파일도 수백 가지의 종속성을 가져올 수 있다. 자바스크립트는 깃허브, 깃랩 등의 리포지토리에서 가장 인기 있는 언어 중 하나다. 리포지토리에서 모든 경우에 맞는 코드를 며칠이고 탐색할 수 있다.
 

자바스크립트로 크로스 컴파일되는 다른 언어

자바스크립트의 최근 변화 하나를 꽂바면 다른 언어로 작성된 코드 지원이다. 자바스크립트로 크로스 컴파일해서 브라우저 또는 서버에서 실행할 수 있는 언어는 수백 가지에 이른다.

JIT 컴파일러 덕분에 이제 자바스크립트는 오래된 코볼 또는 새로운 하스켈을 어디서나 빠르게 실행하고자 하는 개발자에게 좋은 중간 지점 역할을 한다. 물론 이러한 언어를 좋아하는 사용자는 자체 컴파일러를 만들 수 있지만 자바스크립트로 크로스 컴파일해서 툴에 최적화를 맡기는 편이 더 쉽다. 결과적으로 많은 자바스크립트 코드가 완전히 다른 언어를 사용하는 프로그래머에 의해 작성됐다.

 

https://www.itworld.co.kr/news/346945

새로운 자바스크립트가 이전 자바스크립트와 다른 11가지 이유