《You Don't Know JS》 스터디를 마치며
타입과 강제변환부터 스코프·클로저·this·프로토타입·성능까지 여러 장에 흩어진 JavaScript 스터디 노트를 핵심 질문 중심으로 합쳤습니다.
- 작성일
- 업데이트일
JavaScript를 사용한 지 4년쯤 되었을 때 이 책을 읽기 시작했습니다. 매년 책을 볼 때마다 새롭게 보이는 내용이 있었고, 정확히 설명하지 못하면서 습관처럼 쓰는 개념도 많았어요. 혼자 읽는 대신 매주 두 장씩 정리하고 발표하는 스터디에 참여했습니다.
기존에는 각 장을 거의 책의 순서대로 옮겨 적었지만, 이번에는 오래 다시 볼 수 있도록 네 개의 질문으로 묶었습니다. 책의 상세 내용을 대신하기보다 읽으며 무엇을 의심하게 되었는지를 남깁니다.
값은 어떤 타입을 가지는가
첫 번째 묶음은 타입, 값, 네이티브와 강제변환이었습니다.
| 주제 | 읽으며 확인한 질문 |
|---|---|
| 타입 | typeof가 보여주는 결과와 실제 값의 성질은 언제 어긋나는가 |
| 값 | 배열·문자열·숫자를 같은 방식으로 다룰 때 무엇이 달라지는가 |
| 특수 값 | undefined, 선언되지 않은 식별자, NaN, -0을 어떻게 구분할까 |
| 복사 | 원시 값과 객체를 함수에 넘길 때 무엇이 복사되는가 |
| 강제변환 | 명시적 변환과 암시적 변환의 결과를 코드 독자가 예측할 수 있는가 |
책은 “JavaScript는 타입이 없다”는 단순한 설명에서 벗어나게 했습니다. 변수보다 값이 타입을 가지며, 연산 과정의 추상 변환 규칙을 모르고 있으면 짧은 코드도 예상과 다르게 동작할 수 있습니다.
강제변환을 모두 금지하는 것으로 끝내기보다 팀이 읽고 예측할 수 있는 표현을 고르는 편이 중요했습니다. 특히 느슨한 동등 비교나 문자열·숫자 혼합 연산은 입력 값의 범위를 먼저 확인해야 해요.
스코프는 어디에서 결정되는가
두 번째 묶음은 렉시컬 스코프, 함수와 블록 스코프, 호이스팅과 클로저였습니다.
스코프는 식별자를 어디서 찾을지를 정합니다. 코드를 작성한 구조에 따라 검색 경로가 생기고, 안쪽 선언이 바깥 이름을 가릴 수 있어요. eval이나 with처럼 이 구조를 흐리는 기능은 이해와 최적화를 어렵게 만듭니다.
호이스팅은 선언문이 문자 그대로 위로 이동한다기보다, 실행 전에 선언과 스코프가 준비되는 과정을 설명하는 모델로 받아들였습니다. 함수 선언과 변수 선언, let·const의 접근 가능 시점이 다르기 때문에 “위로 올라간다”는 한 문장만 외우면 예외를 설명하기 어려웠어요.
클로저는 함수가 자신이 만들어진 렉시컬 환경에 계속 접근하는 현상입니다. 반복문에서의 비동기 콜백, 모듈의 비공개 상태처럼 실무에서 이미 자주 쓰고 있었지만, 이름을 붙이고 나니 상태가 언제 살아남고 해제되는지 질문할 수 있었습니다.
this와 객체는 어떻게 연결되는가
세 번째 묶음은 this, 객체, 클래스, 프로토타입과 작동 위임이었습니다.
this는 함수가 작성된 위치만으로 고정되지 않고 호출 방식에 따라 바인딩됩니다. “이 함수가 누구의 메서드처럼 보이는가”보다 실제 호출 지점을 보는 습관이 필요했어요. 화살표 함수는 자신만의 this 바인딩을 만들지 않는다는 점도 함께 연결됩니다.
객체 장에서는 속성 기술자, getter와 setter, 열거, 불변성을 살펴봤습니다. 이후 큰 JSON의 키를 지연 변환하는 문제에서 Object.defineProperty를 떠올릴 수 있었던 것도 이 장 덕분이었습니다. 다만 책에서 본 기능을 쓸 수 있다는 사실과 그 기능이 가장 단순한 해결책이라는 판단은 별개였습니다.
JavaScript의 객체 관계를 전통적 클래스 복제 모델로만 설명하면 프로토타입 연결과 위임을 놓치기 쉽습니다. 책은 상속을 흉내 내는 방식과 객체가 다른 객체에 동작을 위임하는 방식을 비교하게 했어요. ES6 class 문법도 편리한 표현이지만 그 아래의 객체 연결까지 다른 체계로 바뀌는 것은 아니라는 점이 남았습니다.
빠른 코드보다 올바른 측정
마지막 묶음은 다양한 실행 환경, 웹 워커와 성능 측정이었습니다. 미세한 문법 차이를 반복 측정해 승자를 고르는 벤치마크는 실제 서비스의 병목을 설명하지 못할 수 있습니다.
- 같은 코드를 다른 엔진과 데이터 크기에서 실행해보기
- 워밍업과 최적화가 결과에 미치는 영향 확인하기
- 단일 연산보다 전체 사용자 흐름의 시간을 보기
- 측정 오차보다 작은 차이를 결론으로 확대하지 않기
- 가독성과 정확성을 희생할 만큼 의미 있는 차이인지 묻기
성능은 엔진을 이기는 요령보다 맥락을 재현하는 테스트를 만드는 문제에 가까웠습니다.
스터디 방식에서 배운 것
혼자 읽을 때보다 속도는 느렸지만, 꾸준히 읽고 서로 다른 실무 사례를 들을 수 있었습니다. 알고 있다고 생각한 내용을 질문받는 순간 설명이 막히기도 했어요. 그 경험 덕분에 “사용할 수 있다”와 “설명할 수 있다” 사이의 간격을 확인했습니다.
지금 이 기록을 다시 보며 남길 독서 방법은 단순합니다. 장별 요약을 많이 쌓기보다 개념 하나를 실제 코드와 연결하고, 반례를 만들어보고, 다른 사람의 질문에 답해보는 것. 완독보다 그 과정을 반복하는 일이 더 깊이 남았습니다.
이어 읽기
- 웹 개발 공부에서 남은 연결고리 — JavaScript 개념을 Next.js, Electron과 실제 성능 문제에 연결한 기록입니다.
- 함수형 프로그래밍을 이해하기 위한 첫 질문 — 함수와 상태를 다루는 학습이 함수형·반응형 관점으로 이어진 과정입니다.
- 개발자로 성장하며 남긴 질문들 — 이 스터디를 시작하게 된 커리어 배경과 2020년 회고를 함께 읽을 수 있어요.