자바스크립트는 어떻게 지금의 언어가 됐을까: Underscore, CoffeeScript, Backbone이 남긴 것

지금 자바스크립트에서 map, 클래스, 화살표 함수, 구조 분해, 프런트엔드 컴포넌트 구조를 자연스럽게 쓴다면 2009년의 불편함을 알아둘 필요가 있다. 그 시절의 문제는 "문법 취향"이 아니라, 실무 앱을 만들 때 계속 발목을 잡는 빈칸이었다.

그 빈칸을 브라우저와 표준이 바로 메워 준 것은 아니었다. 먼저 움직인 것은 라이브러리, 트랜스파일러, 작은 프레임워크였다. 그중 Jeremy Ashkenas가 공개한 Underscore.js, CoffeeScript, Backbone.js는 오래된 도구처럼 보이지만, 지금 자바스크립트의 기본 감각을 이해하는 데 꽤 좋은 지도다.

이 글의 핵심은 간단하다. 세 도구는 모두 "지금은 직접 쓰지 않아도 되는 것"이 됐지만, 사라진 이유가 같지는 않다. 일부는 표준 기능으로 흡수됐고, 일부는 더 강한 프레임워크에 밀렸고, 일부는 트랜스파일이라는 개발 방식 자체를 익숙하게 만들었다.

 

오래된 자바스크립트 개발 환경의 혼란이 유틸리티, 컴파일, 앱 구조를 거쳐 현대적인 웹 앱 구조로 정리되는 모습.

 

2009년 자바스크립트의 문제는 "취향"이 아니었다

옛날 자바스크립트가 불편했다는 말은 흔한 농담처럼 들린다. 하지만 당시의 문제는 단순히 문법이 못생겼다는 수준이 아니었다. 브라우저마다 지원 기능이 달랐고, 언어 자체에도 현대적인 앱을 만들기에는 빈칸이 많았다.

실제로 개발자가 자주 부딪히던 마찰은 이런 것들이었다.

• 배열과 객체를 다루는 표준 유틸리티가 부족했다.
• 클래스 문법이 없어 prototype 기반 상속을 직접 다뤄야 했다.
• var 중심의 함수 스코프와 호이스팅을 계속 의식해야 했다.
• ==의 암묵적 타입 변환 때문에 의도하지 않은 비교 결과가 나오기 쉬웠다.
• 함수를 조금만 많이 쓰면 function이라는 단어가 코드 곳곳을 뒤덮었다.
• 클라이언트 앱이 커지면 데이터, DOM 조작, 이벤트 핸들러가 한 파일에 뒤엉켰다.

 

지금은 각각의 문제에 익숙한 해결책이 있다. 배열 메서드를 쓰고, let과 const를 쓰고, 클래스를 쓰고, 모듈과 프레임워크로 나눈다. 하지만 당시에는 그 해결책이 기본값이 아니었다.

그래서 개발자는 불편함을 참고 직접 다루거나, jQuery 같은 추상화 뒤에서 브라우저 차이를 피하는 방식에 기대곤 했다. Ashkenas의 세 도구는 여기서 한 걸음 더 나아갔다. 없는 표준 라이브러리, 불편한 문법, 무너지는 앱 구조를 각각 다른 방식으로 먼저 메웠다.

JavaScript라는 이름과 ECMAScript 표준의 관계가 헷갈린다면, 이 블로그의 JavaScript 상표권과 ECMAScript 표준 정리를 함께 보면 맥락이 더 잘 이어진다.

 

 

Underscore.js: 표준 라이브러리가 없으면 직접 가져온다

Underscore.js가 해결한 문제는 화려하지 않았다. 배열을 돌리고, 객체를 변환하고, 값을 걸러내고, 함수를 묶고, 템플릿을 처리하는 일. 지금 기준으로는 너무 기본이라 라이브러리의 존재 이유로 보이지 않을 수 있다.

하지만 브라우저 지원이 들쑥날쑥하던 시절에는 이 기본 작업이 오히려 반복적인 마찰이었다. 어떤 브라우저에서는 되는 배열 헬퍼가 다른 브라우저에서는 안 되기도 했다. 오래된 환경까지 챙기려면 폴리필을 넣거나, 검증된 유틸리티 라이브러리에 기대는 편이 현실적이었다.

Underscore의 실전 가치는 "함수 몇 개를 모아 둔 편의 도구"보다 컸다. 반복문과 조건문으로 흩어지던 작업에 이름을 붙였고, 덕분에 코드는 구현 방식보다 의도를 먼저 드러내기 시작했다.

예를 들어 조건에 맞는 값만 모으는 코드는 직접 for문으로도 쓸 수 있다. 하지만 filter라는 이름이 있으면 읽는 사람은 "어떻게 돌렸나"보다 "무엇을 골랐나"를 먼저 본다. 규모가 커질수록 이 차이는 단순 취향이 아니라 유지보수 비용으로 돌아온다.

지금 새 유틸리티 라이브러리를 볼 때도 이 기준은 유효하다. 단지 코드를 짧게 만드는가보다, 반복되는 실무 의도를 제대로 이름 붙이는가를 봐야 한다. 좋은 유틸리티는 편의 함수 묶음이 아니라 팀의 공통 언어가 된다.

 

 

CoffeeScript: 언어가 늦게 바뀌면 바깥에서 먼저 실험한다

CoffeeScript가 건드린 것은 더 민감한 층이었다. 자바스크립트에 라이브러리를 얹는 대신, 더 쓰기 좋은 언어로 작성한 뒤 자바스크립트로 컴파일하자는 접근이었다.

오늘날 TypeScript, Babel, 빌드 도구를 쓰는 개발자에게는 자연스럽다. 하지만 당시에는 중요한 전환이었다. 브라우저가 실행하는 언어는 자바스크립트여도, 사람이 반드시 그 문법 그대로 작성할 필요는 없다는 감각을 넓혔기 때문이다.

CoffeeScript가 인기를 얻은 이유는 단지 짧게 쓸 수 있어서가 아니다. 개발자가 매일 부딪히던 문법 피로를 직접 줄였다.

• 반복되는 function을 줄이는 짧은 함수 문법
• 클래스에 가까운 표현
• 문자열 보간
• 기본 매개변수
• 구조 분해
• 배열과 객체를 다루기 쉬운 표현

 

여기서 선을 그어야 한다. 오늘날 자바스크립트의 모든 문법이 CoffeeScript에서 그대로 왔다고 말하면 과장이다. 표준화는 여러 언어, 커뮤니티, 브라우저 구현, TC39 논의를 거쳐 만들어진다. 다만 CoffeeScript는 "이런 문법 방향이 실제 개발자에게 먹힌다"는 것을 넓게 보여 준 사례였다.

ECMAScript 2015 사양을 보면 이후 자바스크립트에 클래스, 화살표 함수, 템플릿 리터럴, 구조 분해 같은 문법이 들어온 흐름을 확인할 수 있다. CoffeeScript가 모든 것을 만든 것은 아니지만, 그런 방향의 필요성을 개발자 경험으로 먼저 보여 준 것은 분명하다.

실무적으로 더 중요한 교훈은 따로 있다. 언어의 변화가 느릴 때 좋은 아이디어는 표준 바깥에서 먼저 검증될 수 있다. 충분히 많은 사람이 그 방식을 쓰고, 장점과 단점이 드러나면 나중에 표준이나 도구 체인이 그 방향을 흡수한다.

CoffeeScript는 지금 주류 선택지가 아니다. 그렇다고 단순히 유행이 끝난 도구로만 보면 놓치는 것이 있다. 이 도구가 익숙하게 만든 "작성 언어와 실행 언어를 분리하는 사고방식"은 이후 자바스크립트 개발 환경에서 훨씬 자연스러운 것이 됐다.

 

 

Backbone.js: DOM 조작이 앱 구조를 대신할 수 없다는 사실

세 번째 문제는 더 지저분했다. 표준 라이브러리와 문법을 보완해도, 클라이언트 앱이 커지면 코드가 무너지기 쉬웠다.

초기 프런트엔드 코드는 종종 이런 식으로 커졌다. 서버에서 받은 데이터를 변수에 넣고, jQuery로 DOM을 직접 바꾸고, 버튼 클릭 이벤트를 붙이고, 그 안에서 다시 데이터를 수정한다. 처음에는 빠르다. 문제는 화면과 상태가 늘어나는 순간부터다.

실패 지점은 꽤 구체적이다. 데이터가 어디서 바뀌었는지 찾기 어렵다. 같은 이벤트가 여러 번 붙는다. DOM은 바뀌었는데 내부 상태는 예전 값을 들고 있다. 렌더링 타이밍이 꼬이면 버그를 재현하기도 어렵다. 이 정도가 되면 "코드를 정리하자"는 말만으로는 해결되지 않는다. 앱을 보는 구조 자체가 필요하다.

Backbone.js는 여기에 최소한의 뼈대를 넣었다. 데이터를 담는 Model, 모델 묶음인 Collection, 화면과 이벤트를 다루는 View, 변경을 서로 알리는 Events를 제공했다. 지금 기준으로 보면 작고 느슨하지만, 당시 많은 개발자에게는 브라우저 안의 코드를 앱처럼 나눠 볼 수 있게 만든 전환점이었다.

Backbone은 React처럼 화면을 선언적으로 다시 그리는 완성형 해답은 아니었다. 그래서 이후 Angular, Ember, React 같은 도구가 더 강한 구조와 렌더링 모델을 들고 나왔고 Backbone의 자리를 밀어냈다.

그럼에도 Backbone의 의미는 남는다. DOM 조작과 이벤트 핸들러만으로는 커지는 앱을 감당하기 어렵고, 데이터와 화면을 분리해서 생각해야 한다는 문제의 모양을 넓게 보여 줬기 때문이다.

 

 

세 도구가 해결한 문제를 지금 기준으로 다시 보면

세 도구는 자바스크립트의 서로 다른 층을 건드렸다. Underscore는 기본 작업을, CoffeeScript는 문법 피로를, Backbone은 앱 구조를 다뤘다. 나란히 보면 자바스크립트 생태계가 어디서 어디로 이동했는지 보인다.

 

도구	당시의 실무 마찰	오늘날 흡수된 형태	남긴 판단 기준
Underscore.js	배열·객체 처리와 브라우저별 기능 차이	표준 배열 메서드, 더 나은 브라우저 구현, 일부 유틸 라이브러리	반복 코드를 이름 붙은 연산으로 바꾸면 유지보수가 쉬워진다
CoffeeScript	장황하고 실수하기 쉬운 문법	ES2015 이후 문법, Babel/TypeScript식 컴파일 사고	표준 바깥 실험이 언어의 미래를 먼저 보여 줄 수 있다
Backbone.js	데이터, DOM, 이벤트가 섞이는 클라이언트 스파게티	React, Angular, Vue 등 앱 프레임워크의 구조화 방식	클라이언트 코드도 모델과 상태 관리가 필요하다

 

여기서 중요한 것은 "무엇이 살아남았나"보다 "무엇이 기본값이 되었나"다. 도구 이름은 사라졌지만, 해결하려던 마찰은 지금도 프런트엔드 설계의 기준으로 남아 있다.

핵심은 오래된 도구 이름을 외우는 것이 아니다. 그 도구가 어떤 실무 마찰을 먼저 드러냈고, 그 해결 방식이 지금 어디에 흡수됐는지를 보는 것이다.

 

 

오래된 라이브러리에서 지금의 도구 선택 기준을 얻는 법

기술사를 볼 때 가장 쉬운 오해는 사용량만 보고 성공과 실패를 판단하는 것이다. 지금 쓰이지 않는 도구는 실패했고, 지금 쓰이는 도구만 중요하다고 생각하기 쉽다.

하지만 개발 도구는 그렇게만 움직이지 않는다. 어떤 도구는 오래 살아남아서 성공한다. 어떤 도구는 좋은 방향을 보여 준 뒤, 그 방향이 표준과 다음 세대 도구에 흡수되는 방식으로 성공한다. Underscore, CoffeeScript, Backbone은 후자에 가깝다.

이 관점은 지금 새 도구를 볼 때도 쓸 수 있다. "이 도구가 10년 뒤에도 그대로 살아남을까?"만 묻는 것은 부족하다. 대신 이런 질문이 더 실전적이다.

• 이 도구가 어떤 반복 불편을 이름 붙이고 있는가?
• 지금 표준이나 주류 프레임워크가 해결하지 못한 빈칸은 무엇인가?
• 도구가 사라져도 남을 만한 사고방식이 있는가?
• 나중에 기본값이 될 가능성이 있는 방향을 먼저 보여 주는가?

 

이 질문에 답할 수 있으면, 오래된 자바스크립트 라이브러리 이야기는 단순한 회고가 아니다. 지금의 프런트엔드 도구를 평가하는 기준이 된다.

 

 

FAQ

 

CoffeeScript를 지금 배워야 하나요?

새 프로젝트를 위해 깊게 배울 필요는 거의 없습니다. 다만 오래된 Rails나 초기 스타트업 코드베이스를 읽어야 하거나, TypeScript와 Babel 이전의 트랜스파일 흐름을 이해하고 싶다면 역사적 맥락으로 볼 가치는 있습니다.

 

Underscore.js나 Backbone.js를 새 프로젝트에 써도 되나요?

대부분의 새 프로젝트라면 표준 자바스크립트, TypeScript, React/Vue/Angular 같은 현대 도구를 먼저 검토하는 편이 낫습니다. 다만 기존 코드베이스가 이 도구들 위에 있다면 "낡은 코드"로만 보지 말고, 당시 어떤 문제를 해결하려 했는지부터 파악해야 유지보수가 쉬워집니다.

 

 

정리

2009년 전후의 자바스크립트는 지금처럼 앱 개발의 중심 언어로 대접받지 못했다. 표준 라이브러리는 부족했고, 문법은 장황했으며, 클라이언트 앱을 구조화하는 방법도 아직 널리 자리 잡지 못했다.

Jeremy Ashkenas가 공개한 세 도구는 이 문제를 각각 다른 층에서 건드렸다. Underscore.js는 없는 표준 라이브러리를 메웠고, CoffeeScript는 자바스크립트 바깥에서 더 나은 문법을 실험했으며, Backbone.js는 브라우저 안의 코드를 앱처럼 구조화하게 만들었다.

지금은 이 도구들을 직접 쓸 일이 많지 않다. 그래도 우리가 쓰는 현대 자바스크립트의 많은 감각은 그들이 먼저 확인한 문제와 해결 방향 위에 있다. 도구는 사라졌지만, 아이디어는 기본값이 됐다.