자바스크립트의 과거와 오늘

들어가며

이 글은, 자바스크립트를 이제 막 공부하기 시작했거나 아니면 휘발성 이론만 공부한 저 같은 초보들을 위해 작성된 글이며 자바스크립트의 문법을 공부하기 전에 자바스크립트는 어떻게 만들어졌고 어떤 과정을 거쳐 오늘날 이렇게 많이 쓰이는 언어가 된 것일까에 대해서 가볍게 훑고 공부하면 좋을 것 같아서 정리한 내용입니다.

빠른 요약

• 자바스크립트는 웹 페이지에 생동감을 불어넣기 위해 가볍게 만들어진 프로그래밍 언어입니다
• 가벼운 목적으로 만들어진 자바스크립트는 TC39와 ECMA에 의해 표준 명세가 관리되면서 점차 보완되고 있습니다.
• TC39와 ECMA는 엄격한 기준을 정하고 통과해야 표준 명세에 등록이 되는데 그 이유는 자바스크립트는 하위호환성을 보장하기 때문입니다.
• 오늘날의 자바스크립트는 웹 개발뿐만 아니라 서버 개발(Node.js), 모바일 애플리케이션 개발(React Native 등), 데스크톱 애플리케이션 개발(Electron) 등 많은 분야에서 다양하게 활용되고 있습니다.

자바스크립트란?

자바스크립트는 객체지향 프로토타입 기반 언어로 멀티 패러다임 프로그래밍 언어입니다. 와 같은 무슨 말인지 모르겠는 용어들을 제외하고 쉽게 정의하면, 자바스크립트는 웹페이지에 생동감을 불어넣기 위해 만들어진 프로그래밍 언어입니다.

자바스크립트의 탄생은 정말로 단순했습니다.
넷스케이프(Netscape)에 재직 중이던 브랜던아이크(Brendan Eich)가 자바스크립트를 만든 초창기의 목적은 웹페이지에서 단순한 기능을 수행하기 위한 스크립트 언어로 만들었고 이름이 자바스크립트로 지어진 것 또한 자바 개발자들에게 어필하기 위한 마케팅 목적으로, 스크립트(script)가 그 당시 가벼운 프로그램이라는 뜻으로 유행해서 자바스크립트라는 이름으로 만들어지게 되었습니다.

이렇게 가벼운 목적으로 만들어진 자바스크립트는 다른 프로그래밍 언어에 비해서 부족한 점이 많은 상태로 탄생하였고 현재의 자바스크립트는 부족했던 점들을 점점 보완해나가면서 이제 웹 개발에서는 필수 언어로 자리 잡게 되었습니다

브라우저 전쟁과 크로스 브라우징

브랜던아이크가 넷스케이프 재직 중이던 시절은 브라우저 전쟁이 일어나던 시대였습니다.
브라우저 전쟁은 웹 브라우저의 점유율을 두고 여러 회사가 벌인 치열한 경쟁을 말하며, 1990년대 후반에 마이크로소프트(인터넷 익스플로러)와 넷스케이프의 1차 브라우저 전쟁이 시작되었습니다.

이때 마이크로소프트는 JScript라 이름 붙인 자바스크립트의 방언을 개발했습니다.
이렇게 각 대형 기업들이 자체적으로 스크립트를 구현함으로 브라우저 간의 구현 차이가 다르게 되어 개발 프로세스를 통합할 수 있는 표준, 즉 크로스 브라우징(Cross Browsing)이 필요해졌고 이후 표준 기관인 Ecma International 에 표준화를 주관해달라고 요청했고, 1997년 6월 ECMA 회의에서 채택되면서 JavaScript와 ECMA를 합쳐서 ECMAScript의 이름이 붙여졌습니다.

1차 브라우저 전쟁은 마이크로소프트사의 인터넷 익스플로러가 웹 브라우저 시장을 독점했습니다.
이후 2차 브라우저 전쟁은 1차 전쟁에서 패한 넷스케이프를 이후 모질라재단(오라클)이 인수하면서 (정확히는 썬 마이크로 시스템즈가 넷스케이프를 먼저 인수했고, 이후 오라클이 썬 마이크로 시스템즈를 인수하였습니다) 2004년에 파이어폭스 브라우저를 발표하고, 구글이 이후에 크롬을 발표하면서 2차 브라우저 전쟁이 시작되었습니다. 구글이 전체 시장의 대부분을 차지하면서 2차 브라우저의 승리자가 되었습니다.

TC39와 ECMA

오늘날 자바스크립트는 TC39와 ECMA에 의해 정의됩니다.
TC39는 자바스크립트를 관리하는 기술 운영 위원회로 자바스크립트의 공식 명세를 관리하는 위원회입니다.
그리고 TC39에서 합의된 내용을 국제 표준화 기구인 ECMA에 제출하고 ECMA는 변경 사항들을 표준화로 반영하게 됩니다.
TC39 위원회는 브라우저를 만드는 조직(구글,애플,모질라)과 하드웨어 제조사(삼성 등) 같은 회사 출신이 주를 이루며 구성되어있으며, 자바스크립트는 결국 TC39 위원회들에 의해 결정되는데 이들은 0~4단계로 이루어진 절차를 통해 자바스크립트 개정안에 포함될 자격을 회의하여 결정합니다.

TC39의 회의 진행 과정을 간단히 살펴보면 아래와 같습니다.

• TC39 회원이 아닌 누군가가 소셜에 아이디어를 제안합니다.
• TC39 회원 중 한 명이 이런 아이디어 중 가치가 있다고 판단하면 0단계로 올려서 회의 안건으로 올리게 됩니다.
• 4단계까지 계속 회의를 진행하는데 이 과정은 짧게는 몇 달에서 최대 몇 년까지 걸리게 됩니다.
• 최종으로 정해진 변경 사항들을 ECMA에 전달하고 ECMA에서는 표준으로 반영합니다.
• 모든 브라우저는 ECMA에 정의된 명세서 개정안을 반영하지만 브라우저 사별로 반영되는 시기가 다릅니다.

하지만 만약 브라우저 사에서 개정안을 반영할 때 기존에 잘 보이던 콘텐츠가 깨지게 될 때에는 명세서 개정안을 반영하지 않겠다는 결정을 내릴 수 있습니다.
그리고 이렇게 불일치가 발생하면 TC39는 기존 결정을 철회하고 명세서를 웹에 맞추는 작업을 합니다.
이런 과정을 거치기 때문에 모든 주요 브라우저와 디바이스 제조사는 단 하나뿐인 명세서를 기준으로 자바스크립트 구현체를 만듭니다.

자바스크립트는 하위 호환성을 보장합니다.

이렇게 표준 명세가 되기까지 복잡한 과정을 거치게 되는데 이런 이유 중 하나로는 자바스크립트는 하위 호환성을 보장하는 기본 원칙 때문이기도 합니다.

하위 호환성이란, 단 한 번이라도 유효한 자바스크립트 문법이라고 인정된다면 명세서가 변경되더라도 절대 그 유효성이 깨지지 않는다는 것을 의미합니다.
이 말은 2000년에 작성한 코드가 시간이 흐른 지금, 2024년에도 잘 작동하게 보장한다는 의미입니다.
이런 하위 호환성을 보장하는 원칙은 현재의 우리가 작성한 코드가 브라우저 버전이 업데이트되거나 더 시간이 흐른 뒤에도 잘 작동할 거라는 안심을 갖고 작업할 수 있습니다.

간단한 예시를 들면, var 키워드로 만든 변수는 그 이후에 나온 let, const 키워드가 있음에도 var 키워드로 만든 코드들이 여전히 잘 동작한다는 것을 알 수 있습니다.
우리는 너무나 익숙하게 사용하고 있었지만 사실 하위 호환성을 보장하면서 언어를 유지 보수하는 것은 쉬운 일이 아닙니다.

하위 호환성을 보장하며 유지 보수한다는 말은, 예전에 명세서에 포함하자고 하는 문법들이 이후 실수라는 것을 깨달아도 영원히 박제되기 때문입니다.
이러한 문제점들 때문에 명세서를 바꾸거나 기능을 추가할 때 TC39와 ECMA는 엄격한 기준을 만들며 그 기준을 통과해야 합니다.
하지만 예외적으로 하위 호환성을 깨는 결정을 하기도 하는데, 이런 경우는 사용자가 눈치채지 못할 부분에만 하위 호환성을 깨며, 이런 경우는 아주 드뭅니다.

상위 호환성은 하위 호환성의 반대 개념으로 나중에 나올 버전(더 상위버전)을 위해 고안된 입력을 받는 시스템의 기능을 말하며 예를 들면 ES6에서 나온 문법으로 코드 작성을 했을 때 구형 브라우저에서 문제가 발생하지 않아야 합니다.
하지만 자바스크립트는 상위 호환성을 보장하지 않기 때문에 ES6로 작성한 코드들은 구형 브라우저에서 동작하지 않기 때문에 우리는 바벨 같은 트랜스 파일을 이용하여 하위 브라우저에서도 잘 동작하도록 바꿔주는 작업을 합니다.

오늘날의 자바스크립트

이렇게 자바스크립트는 처음에는 가볍게 나왔지만, 현재는 엄격한 기준을 통과하며 점점 보완되고 있고 웹 개발에서 필수적인 요소로 자리 잡게 되었으며 오늘날 자바스크립트는 웹 개발뿐만 아니라 서버 개발(Node.js), 모바일 애플리케이션 개발(React Native 등), 데스크톱 애플리케이션 개발(Electron) 등 많은 분야에서 다양하게 활용되고 있습니다.