02장. 자바스크립트란?

참고: 이웅모 《모던 자바스크립트 Deep Dive》 2장

보강 참고: MDN JavaScript

“JS는 웹에서 버튼 누르면 깜빡이는 거 아냐?”

예전 나였으면 그렇게 대답했을 거다.

지금은 프론트·백·CLI까지 간다. 그래서 2장은 정체성부터.

포인트

ES6 문법은 쓰는데, Ajax가 왜 혁명이었는지 / JS와 ECMAScript 차이는 흐렸다.

구현 위주로만 하다 보니 내부 원리·역사가 비었다.

이슈를 원만히 잡으려면 설계·동작원리를 알아야 한다는 생각 — Flux 노트 쓸 때랑 같은 마음이다.

탄생 — Mocha? LiveScript? JavaScript?

1995년 넷스케이프가 페이지 보조 기능을 위해 경량 언어를 만들었다.

Brendan Eich, 이름 Mocha → LiveScript → JavaScript.

Java랑 이름만 비슷하다. 혈통은 다르다.

이게 무슨 말이냐 — 마케팅 네이밍에 속지 말라는 거다.

당시 웹은 문서에 가까웠다. “조금만 살아 움직이게”가 목표였다.

그 작은 목표가 지금은 앱 전체를 프론트에서 돌리는 이야기까지 커졌다.

시작이 작았다고 지금도 작다고 생각하면 시대를 잘못 읽는다.

표준화 — 왜 ECMAScript?

JScript가 나오고 브라우저 경쟁으로 파편화.

같은 페이지가 브라우저마다 깨짐 = 크로스 브라우징 지옥.

ECMA에 표준화 요청 → ECMA-262, 이름 ECMAScript(상표 이슈).

ECMAScript가 대리자라고? 그럼 JS 대신 시키는 건가?

아니다. 표준 문서의 이름에 가깝다.

우리가 말하는 JS ≈ ECMAScript 표준 + 호스트(브라우저/Node) API.

고민 끝에 버전 감각만 표로.

ES6 이후는 “한 방에 다 외우기”보다 핵심 모델(값·스코프·this·프로토타입·비동기) 을 먼저 잡고, 신규 문법은 필요할 때 얹는 전략이 맞다.

매년 스펙이 나오니까 불안해지는데, 실무에서 매일 쓰는 핵심은 의외로 겹친다.

성장사 — 뭐가 판을 바꿨나

Ajax — 전체 HTML 재전송 대신 필요 데이터만. 구글 맵스가 “브라우저 앱 되네?”를 증명.

이게 무슨 말이냐. 새로고침 없이 지도가 움직인다 = 서버와 브라우저의 역할 분담이 바뀌었다.

jQuery — DOM·호환 고통 감소. 부작용: 원리 없이 추상화만.

나는 $()만 치다가 document.querySelector와 이벤트 버블링을 한참 뒤에야 배웠다. 빚이 이자가 되어 돌아왔다.

V8 — 성능↑, 로직이 클라이언트로.

브라우저가 “느린 스크립트 상자”가 아니라 “앱 런타임”이 된 전환점.

Node — 서버·npm. 같은 언어 풀스택 + 의존성 지옥.

프론트만 하던 내가 package.json 앞에서 처음 현기증을 느낀 곳이기도 하다.

SPA — 상태·라우팅이 프론트 중심 문제.

페이지를 서버가 조립해 주던 시대에서, 클라이언트가 상태를 들고 화면을 그리는 시대로.

판을 바꾼 축을 연도로 외우기보다 “그때 무슨 고통이 사라졌지?”로 기억한다.

Ajax → 전체 새로고침 고통, jQuery → DOM/호환 고통, V8 → 속도 고통, Node → 언어 이중생활 고통, SPA → 페이지 단위 UX 고통.

JS ≠ ECMAScript 전부

const double = n => n * 2; // 언어(ECMAScript)
if (typeof document !== 'undefined') document.title = 'DD'; // 호스트

환경이 다르면 도구가 다르다.

Node에서 document를 찾다가 멘붕한 적 있다. “JS인데 왜 없어?” — 호스트 API니까.

async function loadName(id) {
  const res = await fetch(`/api/users/${id}`);
  const data = await res.json();
  return data.name;
}

Ajax 패러다임(필요 데이터만)을 현대 fetch로 스케치한 것.

최신 문법 = 모든 사용자 지원? 아님. 트랜스파일·폴리필이 배포 현실과의 다리다.

내 크롬 최신이 전 세계 사용자 지원이 아니다.

특징을 내 말로

동적 타입 — 편한데 침묵하는 버그의 온상.

프로토타입 기반 객체 — 클래스 문법은 설탕, 뿌리는 프로토타입.

일급 함수 — 함수를 값처럼 넘긴다.

싱글 스레드 + 이벤트 루프 — 겉보기 동시성은 대개 스케줄링.

이게 무슨 말이냐.

setTimeout으로 나눠 실행한다고 진짜 두 손이 있는 게 아니다.

한 줄씩 하는 직원이 할 일 메모를 바꿔 가며 처리하는 그림에 가깝다.

헷갈리던 장면 / 함정

• Java와 JavaScript를 같은 계열로 착각
• ECMAScript와 DOM/Node API를 동일시
• ES 최신 스펙을 전부 암기해야 한다고 압박받기
• 프레임워크만 알고 런타임 원리를 비우기
• 내 PC 최신 브라우저 동작을 전체 사용자 지원으로 착각

내가 헷갈렸던 질문 모음

Q. JS를 배우면 HTML/CSS는 안 해도 되나?

A. 브라우저 앱이면 결국 세트가 필요하다.

Q. TypeScript 쓰면 2장은 스킵?

A. 아니다. TS는 타입이 얹힌 JS다. 런타임 모델은 그대로 밑에 있다.

Q. 매년 나오는 ES 문법을 다 알아야 하나?

A. 핵심 모델이 먼저고, 문법은 필요에 따라.

비유하자면, 한국어(문법)는 같은데 식당 규칙(호스트)이 다르면 주문 방법이 달라진다.

브라우저라는 식당과 Node라는 식당의 메뉴판이 다르다.

실무 체크: 1) 언어인가 호스트인가? 2) 지원 브라우저는? 3) 트랜스파일/폴리필 경계는?

역사를 “고통 → 발명” 쌍으로 기억한다.

파편화 → ECMAScript, 새로고침 → Ajax, DOM/호환 → jQuery, 속도 → V8, 이중생활 → Node, 페이지 UX → SPA.

여기서 잠깐 💁‍♂️

역사를 외우는 장이 아니다. “이 문법이 왜 생겼지?”에 답을 주는 장이다.

다음 장: 그 코드를 어디서 어떻게 실행하지? 개발 환경과 실행 환경으로.