“30년 전에 자바스크립트가 웹에 활기를 불어넣는 방법을 가르쳤다”라고 말하면 정확하다고 할 수는 없더라도 대충 맞는 말이다. 자바스크립트 프로그래밍 언어는 1995년 브라우저 개발사인 넷스케이프의 한 프로젝트로 시작됐다. 모카(Mocha), 라이브스크립트(LiveScript) 등 여러 이름으로 불리다가 최종적으로 자바스크립트라는 이름으로 세상에 나왔다.

원래 자바스크립트의 목표는 그다지 크지 않았다. 넷스케이프는 개발자가 웹 페이지에 약간의 논리를 집어넣어 가령 양식 요소를 확인하거나 뭔가를 번쩍거리게 만들 수 있는 방법을 제안했다. 당시 웹은 온통 텍스트였으므로 웹 페이지에 이미지를 넣는 것만으로도 고급 작업으로 간주되던 시기였다.

그로부터 약 30년 후, 자바스크립트는 최종 사용자에게 소프트웨어를 제공하는 지배적인 방식으로 자리매김했다. 웹 페이지는 소량의 텍스트와 많은 이미지, 그리고 더욱 많은 소프트웨어 로직을 갖춘 웹 애플리케이션으로 바뀌었다.

이 과정에서 자바스크립트는 더 빠르고 더 매끄럽고 더 강력해지는 동시에 더 복잡해지기도 했다. 자바스크립트를 좋아하는 사람들은 클릭 또는 탭 한 번으로 온갖 문제를 해결할 수 있게 해주는 강력함, 세련됨, 그리고 정교한 인프라에 몰입한다.

맹목적인 애정과 거리를 두는 사람도 있다. 이들은 복잡성에는 버그가 따르며, 강력할수록 더 위험한 버그가 발생한다는 사실을 알고 있다. 자바스크립트로 인해 발생한 문제를 해결하느라 주말을 바쳐봤던 이들은 누가 말만 걸어주면 그 경험에 대해 기꺼이 밤새도록 이야기할 것이다.

여기서는 길고 흥미진진한 자바스크립트의 역사를 기념하기 위해 이 언어를 좋아하는 다양한 이유와 싫어하는 다양한 이유를 살펴본다. 같은 기능이 강력한 동시에 위험하고, 유용한 동시에 문제가 되기도 하고, 좋은 동시에 나쁘기도 하기 때문에 많은 이유가 서로 뒤얽혀 있다.

좋은 이유 1 : 동형 코드

오래전, 브라우저에서 실행되는 코드는 자바스크립트로 작성됐고 서버 코드는 자바, PHP, 콜드퓨전, SQL, C를 비롯한 여러 옵션이 뒤섞여 있었다. 노드.js가 부상하면서 브라우저와 온갖 계층의 서비스 및 마이크로서비스에서 동일한 코드를 실행할 수 있게 됐다. 이런 일이 생각만큼 자주 일어나지는 않을 수 있지만 필요에 따라 기능을 서버에서 브라우저로, 다시 서버에서 브라우저로 옮길 수 있다는 점은 매우 유용하다.

싫은 이유 1 : 그다지 동형적이지 않은 현실

어디서나 동일한 코드를 실행할 수 있다고 해서 삶이 편해지는 것은 아니다. 개발자은 여전히 프론트엔드와 백엔드, 클라이언트 측과 서버 측 중 어느 쪽에 전문화되어야 하는지에 대해 이야기한다. 이론적으로 동일한 코드를 작성할 수는 있지만 현실적으로 프레임워크와 API의 많은 차이점으로 인해 활용하기는 어렵다. 개발자는 이런 차이점을 알기 위해 전문화되어야 한다.

좋은 이유 2 : 표준 구문

코딩 세계의 많은 부분은 C 프로그래밍 언어 구문으로 수렴됐다. 예를 들어 중괄호로 블록을 구분하고 각 줄의 끝에 세미콜론을 입력한다. 자바스크립트도 매우 일반적이고 실용적인 이 접근 방식을 수용했고, 덕분에 많은 사람들은 C, C++, 자바, 자바스크립트, 스위프트, 고 등 여러 언어를 손쉽게 전환하며 사용할 수 있다. 차이점은 있지만 적어도 기본적인 부분은 서로 통한다.

싫은 이유 2 : 구두점

현재 자바스크립트의 가장 큰 경쟁 언어는 파이썬인데, 파이썬을 개발한 사람들은 구두점에 대해 전혀 다른 접근 방식을 취했다. 세미콜론이나 중괄호 키를 누르느라 새끼손가락을 혹사할 필요가 없다. 그런 것 없어도 파이썬은 잘 작동한다. 물론 파이썬 사용자는 보이지 않는 공백 문자를 세느라 많은 시간을 들이곤 하지만, 적어도 화면에 표시되는 코드는 더 간결하고 깔끔하다.

좋은 이유 3 : 클로저

변수의 범위를 유연하게 관리하기 위한 이러한 똑똑한 메커니즘을 사용하면 공유하기 쉬운 간결한 코드를 작성할 수 있다. 언어 자체가 데이터에 대한 참조를 정리하고 보존하는 작업을 수행한다. 대부분의 현대적 비동기 코드는 데이터를 명확하게 유지하기 위해 클로저에 의존한다.

싫은 이유 3: 클로저

클로저는 복잡하며 간혹 혼란스럽기도 하다. 클로저가 잘못되면 디버깅이 거의 불가능한 이상한 결과가 발생할 수 있다. 많은 메모리 누수의 원인이 클로저로 인해 대용량 데이터 객체가 정리되지 않는 데 있는데, 이러한 현상은 기약 없이 대기하는 참조에 의해 발생한다.

좋은 이유 4 : 프레임워크

주요 자바스크립트 프레임워크만 해도 수십 개가 있고, 사용자가 적은 프레임워크까지 합하면 수백 개에 이를 것이다. 웹 애플리케이션 개발자는 앵귤러(Angular), 리액트(React), 뷰(Vue), 스벨트(Svelte), Node.js, 데노(Deno), 네스트(Nest), 번(Bun)과 같은 풍부한 기능을 갖춘 옵션을 활용해서 많은 시간을 절약할 수 있다. 당황스러울 만큼 풍족하다.

싫은 이유 4 : 프레임워크 선택지

선택의 폭이 넓다는 것이 나쁘다고 할 수는 없지만 프로젝트를 시작하는 많은 개발자에게는 어려운 과제를 안겨준다. 적절한 프레임워크를 찾기가 어렵고 오히려 그 과정이 큰 장애물이 될 수도 있다. 프레임워크의 폭발적 증가는 개발자 커뮤니티가 그만큼 잘게 쪼개진다는 것을 의미한다. 잘 지원되는 소수의 접근 방식이 아니라, 많은 개발자가 각자 자기만의 방법을 만들어내고 있는 듯하다. 필자는 창의성을 좋아하지만 단 하나만 선택해야 하는 어려움은 싫다. 조직이 두 개 이상을 도입한다면 상황은 더 악화된다. 필자가 일했던 한 회사는 리액트 하나에 전념했다. 몇 년 전에 앵귤러로 작성된 중요한 서비스가 하나 있었는데 아무도 그 코드의 문제를 해결하고 싶어 하지 않았다. 앵귤러에 대해 제대로 알고 있는 사람이 없었기 때문이다. 문제의 서비스는 그 상태로 계속 방치됐다.

좋은 이유 5 : 살아있는 언어

ECMAScript 위원회는 새로운 기능과 구문 확장을 계속 추가하고 있다. 스프레드 연산자(…) 또는 파이프라인 연산자(=>)와 같은 유용한 단축 기호는 코드를 간결하게 해준다. 개발진은 이러한 기능을 추가하면서 현대적인 사용법과 데이터 구조에 맞춰 자바스크립트의 변화를 이끌고 있다.

싫은 이유 5 : 따라잡기

그 구두점 조합은 오타인가, 아니면 새로운 기능인가? 많은 개발자들은 서로 다른 시대에 나온 자바스크립트를 이해하는 데 애를 먹을 수 있다. 여기서 “시대”는 불과 몇 년의 기간을 의미한다. 코드를 줄여주는 새로운 연산자를 발견하고 기뻐하는 개발자가 있다면, 그 반대쪽에는 도대체 어떻게 된 일인지 알아보기 위해 AI를 찾는 개발자도 있다.

좋은 이유 6 : 브라우저에서 실행되는 코드

오래전에는 소프트웨어를 설치하려면 파일을 복사하고 로컬 코드를 실행해야 했지만 지금 대부분의 소프트웨어는 웹 페이지를 여는 것만으로 간단히 “설치”된다. 훨씬 쉬워졌다. 또한 웹 애플리케이션의 역량이 폭발적으로 성장했다. 사진 편집이나 영화 편집과 같은 작업은 한때 OS에서 네이티브 코드로 실행해야만 가능했지만 이제는 더 나은 JIT(Just-In-Time) 컴파일 덕분에 브라우저에서 원활하게 실행된다.

싫은 이유 6 : 브라우저에서 실행되는 코드

컴퓨터가 왜 이렇게 느려졌을까? 방금 연 브라우저 탭 때문일까, 아니면 오늘 아침에 연 후 그대로 둔 탭 때문일까? 백그라운드에서 누군가 비트코인을 채굴하고 있을까, 아니면 그보다 더 나쁜 일이 있는 걸까? 현대 브라우저는 너무 많은 일이 일어나는 혼란 덩어리다. 아무도 볼 일이 없는 웹 페이지를 렌더링하는 데 막대한 여유 사이클이 투입된다.

좋은 이유 7 : 동적 타입

데이터 타입을 알아서 추적하는 변수를 사용할 때 얻는 유연성은 초보 개발자와 숙련된 개발자를 가리지 않고 모두에게 유익하다. 물론 프로그래머가 정의하는 강한 타입을 사용할 만한 근거도 충분하다. 이게 필요하다면 언제든 타입 시스템과 타입 검사를 갖춘 자바스크립트의 상위 집합인 타입스크립트를 사용하면 된다. 그 외의 시간에는 변수를 선언하고 백엔드가 변수 타입의 세부 사항을 알아서 처리하도록 두는 데서 오는 편리함을 즐기면 된다.

싫은 이유 7 : 동적 연산

안타깝지만, 동적 타입 변수의 간편함에는 납득하기 어려운 이상한 규칙과 혼란도 따라온다. 더하기 기호(+)가 오버로드되고, 이것이 특이 사례에서 이해할 수 없는 결과로 이어질 수 있다. 두 정수의 더하기와 같은 표준적인 방정식은 충분히 예측 가능하겠지만 문자열에 객체를 추가하는 경우 버전과 컴파일러마다 다른, 예상치 못한 결과가 나올 수 있다.

좋은 이유 8 : 타입 변환

정수가 포함된 문자열과 다른 정수를 비교하려는 경우를 생각해 보자. 프로그래머가 “if x > y…” 이상의 일을 왜 해야 하는가? 엄격한 타입의 언어를 사용하는 바보들은 모든 변환을 직접 처리해야 한다. 이를 위해 더 많은 코드를 쓰고 부가적인 변수를 더 선언해야 한다. 자바스크립트는 이 모든 작업을 백그라운드에서 알아서 해준다.

싫은 이유 8 : 타입 변환

타입 변환은 좋다. 아무 말도 없이 갑자기 멋대로 움직이기 전까지는 말이다. “02” > “1” 식은 거짓(false)이다. 사전적 순서에 따라 비교가 이뤄지기 때문이다. 여기서 값은 문자열로 비교된다. 그러나 “02” > 1은 참(true)이다. 자바스크립트가 도움을 준답시고 “02”를 정수로 변환하기 때문이다. 자바스크립트는 이 모든 타입 변환을 프로그래머에게는 아무 말도 하지 않고 수행한다. 프로그래머를 도와주는 것이 아니라 오히려 방해가 되고 코드 디버깅을 더 어렵게 한다.

좋은 이유 9 : 기발한 트릭

자바스크립트는 C의 후손이며 간단한 코드를 작성하기 위한 재미있는 몇 가지 방법은 그대로 이어진다. 자바스크립트는 프로그래머가 매우 간단하고 효과적인 코드를 작성할 수 있도록 자동으로 타입 변환을 처리해 준다. if-then-else 문은 부울 값만 고집하지 않으며 정수, 문자열 또는 객체를 사용해 결정을 내릴 수도 있다. 결과적으로 매우 짧고 간결한 코드를 얻게 된다.

싫은 이유 9 : 참 판단하기

부울 식은 가장 간단한 컴퓨팅 형태 중 하나이지만 이상하게 동작할 수도 있으므로 프로그래머는 특이한 많은 조건들을 일일이 기억해야 한다. 예를 들어 if 문은 변수가 부울 값인 참 또는 거짓으로 평가되지 않는 경우에도 결정을 내린다. 다양한 정수, 문자열, 배열, 객체는 서로 다른 값을 갖고, 이로 인해 혼란이 발생할 수 있다. 빈 문자열은 거짓이지만 빈 객체는 참이다. 정수 1은 참이지만 정수 0은 거짓이다. 이와 같은 규칙을 외우고, 버전에 따라 그 규칙이 바뀌지 않기를 바라는 수밖에 없다.

좋은 이유 10 : 트랜스파일러

자바스크립트를 좋아하지 않는다 해도 자바스크립트 세계에서 사는 데 지장은 없다. 거의 모든 언어를 변환하는 수백 개의 트랜스파일러가 있기 때문이다. 그중에는 타입스크립트 또는 커피스크립트와 같이 자바스크립트의 단순한 확장 또는 변형도 있고 파이썬, 자바, C#, SQL 등 전혀 다른 언어를 완전히 변환하는 트랜스파일러도 있다. 비교적 오래된 언어 중 리스프, 코볼 등은 현대의 최적화된 JIT 인프라를 통해 원활하고 빠르게 실행이 가능하다.

싫은 이유 10 : 명명

자바스크립트인가, ECMAScript인가? 상표의 소유권은 오라클에 있는가, 자바스크립트를 만든 사람들에게 있는가? 아니면 일반적인 용어가 되었는가? 자바와 연관성이 있는가? 법적 계약서에 어떻게 써넣어야 하는가? 그냥 노드(Node)라고 불러야 하는가? 질문은 많은데 답은 하나같이 불분명하다. 결국 이름을 하나 고르고, 글을 쓸 때 한 단락 안에서는 일관되게 그 이름을 사용하도록 노력하는 수밖에 없다.
dl-itworldkorea@foundryco.com