taek2-0310 님의 블로그

브라우저 렌더링 과정과 DOM

taek2-0310 — Mon, 1 Jun 2026 13:07:20 +0900

1. 브라우저 렌더링 과정 개요

[요청] → [HTML 파싱 → DOM] → [CSS 파싱 → CSSOM]
       → [렌더 트리 생성] → [레이아웃] → [페인트]

단계설명

1. 요청/응답	DNS를 통해 IP 주소를 확인하고 서버에 리소스 요청
2. DOM 생성	바이트 → 문자 → 토큰 → 노드 → DOM 트리
3. CSSOM 생성	CSS 파일을 동일한 파싱 과정으로 CSSOM 트리 생성
4. JS 실행	자바스크립트 엔진이 AST 생성 → 바이트코드 실행
5. 렌더 트리	DOM + CSSOM 결합 (화면에 표시되는 노드만 포함)
6. 레이아웃	각 요소의 위치와 크기 계산
7. 페인트	픽셀로 화면에 그리기

2. 요청과 응답

브라우저 주소창에 URL을 입력하면:

URL의 호스트 이름이 DNS를 통해 IP 주소로 변환된다.
해당 IP 주소의 서버에 GET 요청을 전송한다.
루트 요청(/)의 경우 서버는 기본적으로 index.html을 응답한다.

https://www.example.com:80/docs/search?category=js#intro
   │           │          │      │           │        │
 scheme      host        port   path        query  fragment

핵심: index.html을 파싱하는 중 <link>, <img>, <script> 태그를 만나면 해당 리소스를 서버에 추가로 요청한다.

3. HTTP 1.1 vs HTTP 2.0

구분HTTP/1.1HTTP/2.0

요청/응답	커넥션당 하나씩 처리	커넥션당 다중 처리 가능
전송 방식	순차적 (개별 전송)	동시 전송
속도	느림	약 50% 빠름

4. HTML 파싱과 DOM 생성

서버에서 HTML을 바이트로 응답받아 다음 과정을 거쳐 DOM 트리를 생성한다.

바이트(2진수)
    ↓ (meta charset 기준 디코딩)
문자열
    ↓ (어휘 분석 · Lexical Analysis)
토큰 (문법적 의미를 가지는 코드의 최소 단위)
    ↓
노드 (문서 노드 / 요소 노드 / 어트리뷰트 노드 / 텍스트 노드)
    ↓
DOM 트리

DOM 트리 예시

<!DOCTYPE html>
<html>
  <head>
    <meta charset="UTF-8">
    <link rel="stylesheet" href="style.css">
  </head>
  <body>
    <ul>
      <li id="apple">Apple</li>
      <li id="banana">Banana</li>
    </ul>
    <script src="app.js"></script>
  </body>
</html>

document
  └── html
        ├── head
        │     ├── meta [charset="UTF-8"]
        │     └── link [rel="stylesheet" href="style.css"]
        └── body
              ├── ul
              │    ├── li [id="apple"] → "Apple"
              │    └── li [id="banana"] → "Banana"
              └── script [src="app.js"]

5. CSS 파싱과 CSSOM 생성

렌더링 엔진이 <link> 또는 <style> 태그를 만나면:

DOM 생성을 일시 중단한다.
CSS 파일을 서버에 요청한다.
HTML과 동일한 파싱 과정(바이트 → 문자 → 토큰 → 노드)을 거쳐 CSSOM 트리를 생성한다.
CSS 파싱 완료 후 HTML 파싱을 재개한다.

6. 렌더 트리 생성

DOM + CSSOM을 결합하여 렌더 트리를 생성한다.

렌더 트리에서 제외되는 노드:

<meta>, <script>, <head> 같은 화면에 표시되지 않는 노드
CSS display: none이 적용된 노드

visibility: hidden은 공간은 차지하지만 보이지 않으므로 렌더 트리에 포함된다.

렌더 트리 완성 후:

레이아웃(Layout): 각 요소의 위치(x, y)와 크기(width, height) 계산
페인트(Paint): 계산된 정보로 픽셀을 화면에 그리기

7. 자바스크립트 파싱과 실행

HTML 파싱 중 <script> 태그를 만나면:

DOM 생성을 일시 중단한다.
자바스크립트 파일을 서버에 요청한다.
자바스크립트 엔진에 제어권을 넘긴다.
JS 엔진이 코드를 파싱하여 **AST(Abstract Syntax Tree)**를 생성한다.
AST를 기반으로 바이트코드를 생성하고 실행한다.
실행 완료 후 렌더링 엔진으로 제어권 반환 → HTML 파싱 재개

8. 리플로우와 리페인트

자바스크립트에서 DOM API로 DOM이나 CSSOM을 변경하면 렌더 트리가 재생성되며 다음이 발생한다.

구분설명발생 조건

리플로우(Reflow)	레이아웃 계산을 다시 수행	요소 추가/삭제, 크기/위치 변경, 창 리사이징
리페인트(Repaint)	재결합된 렌더 트리로 다시 페인트	리플로우 이후, 또는 색상 등 레이아웃 영향 없는 변경

중요: 레이아웃에 영향을 주지 않는 변경(색상, 투명도 등)은 리페인트만 발생한다. 리플로우 + 리페인트는 비용이 크므로 가급적 최소화해야 한다.

9. script 태그 위치와 async/defer

문제: <head> 안에 <script> 배치 시

<head>
  <script src="app.js"></script>  <!-- DOM이 완성되기 전에 실행! -->
</head>
<body>
  <div id="app">...</div>
</body>

// app.js
const $app = document.getElementById('app'); // null → 에러 발생!
$app.style.color = 'red'; // TypeError

해결책 1: </body> 직전에 배치

<body>
  <div id="app">...</div>
  <script src="app.js"></script>  <!-- DOM 완성 후 실행 -->
</body>

해결책 2: async / defer 어트리뷰트

<script async src="app.js"></script>
<script defer src="app.js"></script>

구분HTML 파싱JS 로드JS 실행 시점

기본	중단	순차	로드 즉시
async	병렬	병렬	로드 완료 즉시 (순서 보장 X)
defer	병렬	병렬	HTML 파싱 완료 후 (순서 보장 O)

권장: DOM 조작이 필요한 스크립트는 defer 사용

10. DOM이란?

**DOM(Document Object Model)**은 HTML 문서를 파싱한 결과물로, 브라우저가 이해할 수 있는 트리 자료구조다.

노드의 4가지 핵심 타입

노드 타입설명

문서 노드	DOM 트리 최상위 루트. document 객체. 다른 노드에 접근하는 진입점
요소 노드	HTML 요소를 나타냄. 문서의 구조를 표현
어트리뷰트 노드	HTML 요소의 어트리뷰트. 부모 노드 없이 요소 노드에만 연결됨
텍스트 노드	HTML 요소의 텍스트. 리프 노드(자식 노드 없음). 문서의 정보를 표현

노드 상속

Object
  └── EventTarget
        └── Node
              ├── Document → HTMLDocument
              ├── Attr
              ├── CharacterData → Text / Comment
              └── Element → HTMLElement
                              ├── HTMLInputElement
                              ├── HTMLDivElement
                              └── ...

11. 노드 취득 메서드 비교

id로 취득

// 단 하나의 요소 반환. 없으면 null
document.getElementById('apple');

태그 이름으로 취득

// HTMLCollection 반환 (live)
document.getElementsByTagName('li');

// 특정 요소의 자손 중에서만 탐색
$ul.getElementsByTagName('li');

class로 취득

// HTMLCollection 반환 (live)
document.getElementsByClassName('fruit');

CSS 선택자로 취득 ✅ 권장

// 첫 번째 요소 하나 반환
document.querySelector('.banana');

// 조건을 만족하는 모든 요소 반환 → NodeList (non-live)
document.querySelectorAll('ul > li');

HTMLCollection vs NodeList 비교

구분HTMLCollectionNodeList

반환 메서드	getElementsByTagName, getElementsByClassName	querySelectorAll, childNodes
live 여부	항상 live (실시간 반영)	대부분 non-live (childNodes는 live)
순회 시 주의	for 문 순회 중 변경되면 오작동 위험	비교적 안전
권장 사용법	배열로 변환 후 사용 [...$elems]	배열로 변환 후 사용 권장

// HTMLCollection 순회 시 주의사항
const $elems = document.getElementsByClassName('red'); // live!

// ❌ 위험: 순회 중 DOM이 변경되어 일부 요소가 건너뛰어짐
for (let i = 0; i < $elems.length; i++) {
  $elems[i].className = 'blue';
}

// ✅ 안전: 배열로 변환 후 순회
[...$elems].forEach(elem => elem.className = 'blue');

12. DOM 조작

텍스트 조작

// nodeValue: 텍스트 노드의 값을 직접 변경
const $text = document.getElementById('foo').firstChild;
$text.nodeValue = 'changed!';

// textContent: 요소의 모든 텍스트 취득/변경 (HTML 마크업 무시)
document.getElementById('foo').textContent = 'Hello World';

innerHTML vs insertAdjacentHTML vs createElement

방법장점단점

innerHTML	간단, 직관적	XSS 취약, 기존 자식 노드 전부 제거 후 재생성
insertAdjacentHTML	기존 노드 유지, 빠름	XSS 취약
createElement + appendChild	안전, XSS 위험 없음	코드 복잡

// insertAdjacentHTML 위치 옵션
element.insertAdjacentHTML('beforebegin', '<p>앞</p>');  // 요소 앞
element.insertAdjacentHTML('afterbegin',  '<p>첫째</p>'); // 첫 자식 앞
element.insertAdjacentHTML('beforeend',  '<p>마지막</p>');// 마지막 자식 뒤
element.insertAdjacentHTML('afterend',   '<p>뒤</p>');   // 요소 뒤

노드 생성 및 추가

// 여러 노드 추가 시 DocumentFragment 사용 → DOM 변경 1회로 최소화
const $fragment = document.createDocumentFragment();

['Apple', 'Banana', 'Orange'].forEach(text => {
  const $li = document.createElement('li');
  $li.textContent = text;
  $fragment.appendChild($li);
});

document.getElementById('fruits').appendChild($fragment);
// DOM 변경은 단 1회!

주요 노드 탐색 프로퍼티

// 자식 탐색
node.childNodes          // NodeList (텍스트 노드 포함)
element.children         // HTMLCollection (요소 노드만)
element.firstElementChild
element.lastElementChild

// 부모 탐색
node.parentNode

// 형제 탐색
element.previousElementSibling
element.nextElementSibling

자바스크립트 객체와 프로토타입 — 언제, 왜 쓰는 걸까?

taek2-0310 — Mon, 25 May 2026 11:36:22 +0900

객체는 흔히 우리가 너무 많이 쓰지만 프로토타입은 경험할 기회가 흔치 않아요. 저는 항상 무언가를 배우게 되면 “그래서 언제 쓰는데?”라는 생각이 들기 때문에 이 블로그에도 그런 생각을 담아 작성해보았습니다. 혹시 사용하는 상황이라도 기억해둔다면 “아, 이런 상황에서 프로토타입을 쓰던데?” 하며 다시 돌아와 개념을 다지고 사용할 수 있지 않을까요?

1부. 객체 리터럴 — 객체를 만드는 가장 쉬운 방법

객체가 뭔지부터

자바스크립트에서 원시값(숫자, 문자열, 불리언 등)을 제외한 거의 모든 값은 객체입니다. 함수도, 배열도, 정규표현식도 객체예요.

객체는 키(key)와 값(value)으로 이루어진 프로퍼티의 집합입니다. 그 중에서 값이 함수인 프로퍼티는 특별히 메서드라고 부릅니다.

const person = {
  name: 'Lee',        // 프로퍼티: 상태를 나타냄
  age: 20,
  sayHello() {        // 메서드: 동작을 나타냄
    console.log(`Hi, ${this.name}!`);
  }
};

핵심은 상태(데이터)와 동작(행동)을 하나의 단위로 묶는다는 겁니다. 관련 있는 것들을 한 곳에 모아 관리하는 거죠.

객체를 만드는 방법은 5가지

자바스크립트는 클래스 없이도 객체를 만들 수 있습니다. 방법이 다섯 가지나 있어요.

방법코드 예시

객체 리터럴	const obj = { name: 'Lee' }
Object 생성자 함수	const obj = new Object()
생성자 함수	const obj = new Person('Lee')
Object.create	const obj = Object.create(proto)
클래스(ES6)	class Person { }

그럼 각각 언제 쓸까요?

✅ 객체 리터럴 — 단순하고 일회성인 데이터 묶음

// 딱 한 번만 쓸 설정값, 옵션 객체, 반환값 등
const config = {
  host: 'localhost',
  port: 3000,
  debug: true
};

// API 응답 데이터 임시 가공
const user = {
  id: response.userId,
  name: response.userName,
};

같은 구조의 객체를 여러 개 만들 필요가 없을 때 가장 편합니다. 코드가 짧고 직관적이에요.

✅ 생성자 함수 / 클래스 — 같은 구조의 객체를 여러 개 만들 때

// 같은 구조의 객체가 여러 개 필요할 때
function Person(name, age) {
  this.name = name;
  this.age = age;
}

const lee = new Person('Lee', 20);
const kim = new Person('Kim', 25);

lee, kim 처럼 같은 틀(구조)의 인스턴스를 찍어낼 때 씁니다. 객체 리터럴로 하면 같은 코드를 반복 작성해야 하니까요.

✅ Object.create — 프로토타입을 직접 지정할 때

const animal = {
  breathe() { console.log('숨 쉰다'); }
};

const dog = Object.create(animal); // animal을 프로토타입으로 지정
dog.bark = function() { console.log('멍!'); };

dog.breathe(); // 숨 쉰다 (animal에서 상속)
dog.bark();    // 멍!

상속 관계를 매우 명시적으로 설정하고 싶을 때, 또는 null 프로토타입 객체(순수한 데이터 저장용 객체)가 필요할 때 씁니다.

// 프로토타입 체인이 없는 순수 객체 (Map 대신 쓸 때)
const dict = Object.create(null);
dict['hello'] = '안녕';
// toString, hasOwnProperty 같은 기본 메서드가 없어서 키 충돌 걱정 없음

솔직히 ✅ Object.create 같은 건 본 적이 없어서 알아봤는데 예전에는 자바스크립트에서 class를 표현할 방법이 없어 사용했었다고 해요. 그런데 자바스크립트에 class 문법이 생기면서 잘 사용되지 않게 되었다고 합니다. 그마저도 요즘은 class 대신 객체 리터럴을 사용하는 경우도 많아서 그냥 이런 게 있구나 정도로만 알아두시면 될 것 같아요.

ES6 축약 문법

프로퍼티 축약

const name = 'Lee';
const age = 20;

// 변수명과 키 이름이 같으면 생략 가능
const person = { name, age };
// { name: 'Lee', age: 20 } 과 동일

함수에서 객체를 반환하거나 상태를 모아서 넘길 때 자주 씁니다.

function getUser(id) {
  const name = fetchName(id);
  const email = fetchEmail(id);
  return { name, email }; // 축약 표현
}

메서드 축약

// 예전 방식
const obj = {
  greet: function() { ... }
};

// ES6 방식
const obj = {
  greet() { ... }
};

단순히 짧아진 것이 아니라 ES6 메서드 축약으로 정의한 메서드는 내부 동작이 다릅니다(non-constructor, super 사용 가능). 클래스 메서드처럼 동작한다고 이해하면 됩니다.

AI에게 물어본 "내부 동작이 다릅니다(non-constructor, super 사용 가능)."이 뭘 의미할까?
1. non-constructor — "이건 생성자로 못 써"

new로 호출할 수 없다는 뜻이에요.

// 일반 function으로 정의한 메서드
const obj1 = {
  greet: function() { return 'hi'; }
};

// ES6 축약으로 정의한 메서드
const obj2 = {
  greet() { return 'hi'; }
};

// 일반 function → new로 호출 가능 (constructor)
new obj1.greet(); // ✅ 되긴 됨 (빈 객체 생성됨)

// ES6 축약 → new로 호출 불가 (non-constructor)
new obj2.greet(); // ❌ TypeError: obj2.greet is not a constructor

근데 솔직히 객체 안에 있는 메서드를 new로 호출할 일은 현실에서 없어요. 그래서 이 차이가 실무에서 체감되는 경우는 거의 없고, "아 그런 차이가 있구나" 정도로만 알면 충분해요.

2. super — 이게 실제로 중요한 차이

super는 부모 클래스의 메서드를 호출할 때 쓰는 키워드예요.

class Animal {
  speak() {
    return '소리를 냅니다';
  }
}

class Dog extends Animal {
  speak() {
    const parent = super.speak(); // 부모의 speak() 호출
    return `멍! (${parent})`;
  }
}

const d = new Dog();
d.speak(); // "멍! (소리를 냅니다)"

여기까진 자연스럽죠. 문제는 객체 리터럴 안에서 super를 쓰고 싶을 때 발생해요.

const animal = {
  speak() {
    return '소리를 냅니다';
  }
};

// ❌ 일반 function으로 정의하면 super 못 씀
const dog1 = {
  speak: function() {
    return super.speak(); // SyntaxError!
  }
};

// ✅ ES6 축약으로 정의하면 super 사용 가능
const dog2 = {
  speak() {
    return super.speak(); // 정상 동작
  }
};

Object.setPrototypeOf(dog2, animal);
dog2.speak(); // "소리를 냅니다"

super를 쓰려면 ES6 축약 메서드 문법으로 정의해야 한다는 게 핵심이에요.

근데 실무에서 객체 리터럴에 super 쓸 일이 있나?

솔직히 클래스 쓰면 해결되는 경우가 대부분이라 자주 보이진 않아요.

그나마 쓰이는 경우는 Vue 옵션 API나 믹스인 패턴처럼 객체를 조합하는 상황 정도인데, 현대 코드에선 이것도 클래스나 컴포지션 패턴으로 대체되는 추세라서요.

결론적으로 이 두 차이는 "ES6 메서드 축약은 그냥 짧은 게 아니라 내부적으로 다르게 동작한다" 는 걸 알려주는 포인트예요. 실무 체감보다는 동작 원리 이해 쪽에 가깝습니다.

계산된 프로퍼티 이름

const prefix = 'btn';

const ui = {
  [`${prefix}-primary`]: '#3b82f6',
  [`${prefix}-danger`]: '#ef4444',
};
// { 'btn-primary': '#3b82f6', 'btn-danger': '#ef4444' }

키를 동적으로 결정해야 할 때 유용합니다. 팩토리 패턴이나 설정 객체를 생성할 때 자주 쓰입니다.

2. 프로토타입 — 자바스크립트 상속의 실체

왜 프로토타입이 필요한가?

생성자 함수로 객체를 여러 개 만들다 보면 문제가 생깁니다.

function Circle(radius) {
  this.radius = radius;
  this.getArea = function() {  // ❌ 문제!
    return Math.PI * this.radius ** 2;
  };
}

const c1 = new Circle(1);
const c2 = new Circle(2);
const c3 = new Circle(3);

c1, c2, c3가 가진 getArea는 내용이 완전히 동일한데 3개가 따로 만들어집니다. 인스턴스가 1000개면 같은 함수가 1000개 생기는 거예요. 메모리 낭비이고 성능에도 악영향을 줍니다.

console.log(c1.getArea === c2.getArea); // false — 다른 함수 객체!

프로토타입으로 해결하기

공통 메서드는 프로토타입에 한 번만 정의하고, 모든 인스턴스가 그걸 공유하면 됩니다.

function Circle(radius) {
  this.radius = radius; // 인스턴스마다 다른 값 → 각자 소유
}

// 공통 동작은 프로토타입에 한 번만
Circle.prototype.getArea = function() {
  return Math.PI * this.radius ** 2;
};

const c1 = new Circle(1);
const c2 = new Circle(2);

console.log(c1.getArea === c2.getArea); // true — 같은 함수 공유!

원칙: 인스턴스마다 달라지는 값(상태)은 직접 소유하고, 모든 인스턴스가 똑같이 하는 행동(메서드)은 프로토타입에서 공유한다.

프로토타입 체인 — 어떻게 찾아가는가

객체에서 프로퍼티를 찾을 때 자바스크립트는 이렇게 동작합니다.

me.hasOwnProperty('name') 호출 시:

1. me 객체 안에서 hasOwnProperty 찾음 → 없음
2. me.__proto__ (= Person.prototype) 에서 찾음 → 없음
3. Person.prototype.__proto__ (= Object.prototype) 에서 찾음 → 있음! 실행

이것이 프로토타입 체인입니다. 최상위는 항상 Object.prototype이고, 거기서도 없으면 undefined를 반환합니다.

function Person(name) { this.name = name; }
Person.prototype.sayHello = function() {
  console.log(`Hi, ${this.name}!`);
};

const me = new Person('Lee');

me.sayHello();              // 'Hi, Lee!'  ← Person.prototype에서 상속
me.hasOwnProperty('name'); // true         ← Object.prototype에서 상속
me.foo;                    // undefined    ← 체인 끝까지 없으면 undefined

3각 관계: 생성자 함수 ↔ 프로토타입 ↔ 인스턴스

function Person(name) { this.name = name; }
const me = new Person('Lee');

// 세 가지가 서로 연결되어 있음
Person.prototype.constructor === Person;  // true
me.__proto__ === Person.prototype;        // true
me.constructor === Person;               // true (프로토타입 통해 상속)

이 3각 관계를 알아야 프로토타입 교체나 instanceof 동작을 이해할 수 있습니다.

정적 메서드 vs 프로토타입 메서드 — 언제 뭘 쓸까?

function MathUtils() {}

// 프로토타입 메서드 — 인스턴스가 있어야 호출 가능
MathUtils.prototype.double = function(n) {
  return n * 2;
};

// 정적 메서드 — 인스턴스 없이 바로 호출 가능
MathUtils.square = function(n) {
  return n * n;
};

const util = new MathUtils();
util.double(5);    // 10 ✅
MathUtils.square(5); // 25 ✅
util.square(5);    // ❌ TypeError

판단 기준: 메서드 내부에서 this(인스턴스)를 참조하는가?

this 참조 필요 → 프로토타입 메서드
this 참조 불필요 → 정적 메서드로 만드는 게 더 명확

실제 예시로 보면:

// Object.create — 정적 메서드 (인스턴스 없이 씀)
const obj = Object.create(null);

// obj.hasOwnProperty — 프로토타입 메서드 (인스턴스가 씀)
obj.hasOwnProperty('key');

프로퍼티 섀도잉 — 오버라이딩의 실체

Person.prototype.sayHello = function() {
  console.log(`Hi, ${this.name}`);   // 프로토타입 메서드
};

const me = new Person('Lee');

// 인스턴스에 같은 이름의 메서드 추가
me.sayHello = function() {
  console.log(`Hey! ${this.name}`);  // 인스턴스 메서드
};

me.sayHello(); // "Hey! Lee" — 인스턴스 메서드가 우선

인스턴스 메서드가 프로토타입 메서드를 가립니다(섀도잉). 프로토타입 메서드가 덮어써지는 게 아니라 체인에서 먼저 발견되는 인스턴스 메서드가 실행되는 겁니다.

인스턴스 메서드를 삭제하면 다시 프로토타입 메서드가 보입니다.

delete me.sayHello;
me.sayHello(); // "Hi, Lee" — 이제 프로토타입 메서드 호출

instanceof와 프로퍼티 확인

instanceof — 프로토타입 체인 확인

me instanceof Person  // Person.prototype이 me의 체인에 있는가?
me instanceof Object  // Object.prototype이 me의 체인에 있는가?

constructor 프로퍼티가 아니라 프로토타입 체인 상에 존재하는지를 확인하는 거라는 점이 중요합니다.

프로퍼티 존재 확인

const person = { name: 'Lee', address: 'Seoul' };

// in 연산자: 프로토타입 체인 전체에서 확인
'name' in person       // true
'toString' in person   // true (Object.prototype에 있으니까!)

// hasOwnProperty: 자기 자신의 프로퍼티만 확인
person.hasOwnProperty('name')      // true
person.hasOwnProperty('toString')  // false

상속받은 것까지 포함해서 볼 때는 in, 자기 것만 볼 때는 hasOwnProperty.

프로퍼티 열거 — for...in의 함정

const person = {
  name: 'Lee',
  address: 'Seoul',
  __proto__: { age: 20 }  // 상속받은 프로퍼티
};

// for...in: 상속받은 것까지 열거
for (const key in person) {
  console.log(key); // name, address, age 모두 출력!
}

// 자기 것만 열거하려면 hasOwnProperty 필터링 필요
for (const key in person) {
  if (!person.hasOwnProperty(key)) continue;
  console.log(key); // name, address만 출력
}

이런 번거로움 때문에 보통 아래를 더 권장합니다.

Object.keys(person)    // ['name', 'address'] — 자신의 열거 가능한 키만
Object.values(person)  // ['Lee', 'Seoul']
Object.entries(person) // [['name', 'Lee'], ['address', 'Seoul']]

배열 순회에는 for...in 대신 for, forEach, for...of를 씁니다. 배열도 객체라서 for...in으로 돌리면 숫자 인덱스 외에 추가 프로퍼티도 딸려 나올 수 있거든요.

3부. 정리 — 언제 무엇을 쓸 것인가

객체 생성 방법 선택 기준

단순 데이터 묶음, 한 번만 씀
  → 객체 리터럴 { }

같은 구조의 객체를 여러 개 만들어야 함
  → 생성자 함수 / 클래스

프로토타입을 직접 지정하고 싶음
  → Object.create()

순수한 데이터 저장소 (메서드 없는 맵처럼)
  → Object.create(null)

메서드 정의 위치 선택 기준

인스턴스마다 다르게 동작해야 함 (this 참조 필요)
  → 프로토타입 메서드

인스턴스와 무관한 유틸성 기능 (this 참조 불필요)
  → 정적 메서드

프로퍼티 열거/확인 선택 기준

프로토타입 체인 포함해서 확인
  → in 연산자

자기 자신 것만 확인
  → hasOwnProperty

자기 자신 것만 열거
  → Object.keys / Object.values / Object.entries

상속 포함 열거 (드물게)
  → for...in (hasOwnProperty 필터링 병행)

this, 클로저 사실 나도 잘 몰라...ㅡJavaScript 완전 정복

taek2-0310 — Fri, 22 May 2026 16:53:32 +0900

this란?

this는 자신이 속한 객체 또는 자신이 생성할 인스턴스를 가리키는 자기 참조 변수다. 가장 일반적으로는 객체의 메서드 안에서 사용되며 이를 통해 동일한 메서드를 서로 다른 객체에서 재사용할 수 있다.

일반 변수는 선언된 위치(렉시컬 스코프)에 의해 값이 결정되지만 this는 다르다. 함수가 어떤 방식으로 호출(바인딩)되었는지에 따라 가리키는 값이 동적으로 결정된다.

쉽게 비유하자면 "나"라는 단어와 같다. "나는 밥을 먹었다"에서 '나'가 누구인지는 그 말을 누가 했느냐에 따라 달라지는 것처럼 this도 누가(어떤 컨텍스트가) 함수를 호출했느냐에 따라 달라진다.

this가 결정되는 4가지 규칙

1. 기본 바인딩

아무런 컨텍스트 없이 함수를 단독 호출하면 this는 전역 객체를 가리킨다. 그리고 이 this는 브라우저에서 window 객체가 된다.

function greet() {
  console.log(this); // window (브라우저)
}

greet();

2. 암시적 바인딩

객체의 메서드로 호출되면 this는 그 객체를 가리킨다.

const user = {
  name: '철수',
  greet() {
    console.log(this.name); // '철수'
  }
};

user.greet(); // this === user

3. 명시적 바인딩

함수가 호출될 때 apply, call 또는 bind가 사용되었다면 첫번째 인자로 전달하는 값에 this 를 바인딩 한다.

bind는 새로운 함수를 반환하며 this를 영구 고정한다는 점에서 call/apply와 다르다.

jsfunction greet() {
  console.log(this.name);
}

const user = { name: '철수' };

greet.call(user);        // '철수'
greet.apply(user);       // '철수'
const bound = greet.bind(user);
bound();                 // '철수'

4. new 바인딩

new 키워드로 생성자 함수를 호출하면, this는 새로 생성되는 인스턴스 객체를 가리킨다

function Person(name) {
  this.name = name; // 새 인스턴스에 바인딩
}

const p = new Person('민준');
console.log(p.name); // '민준'

❗️우선순위: new > 명시적(bind) > 암시적(메서드) > 기본❗️

화살표 함수의 this — 완전히 다른 규칙❓

화살표 함수는 this를 아예 갖지 않는다. 대신 자신이 선언된 위치의 외부 스코프 this를 그대로 캡처한다.(클로저)

const person = {
	name : 'Seo',
    sayName : function() {
    	innerFun = function() {
        	return `안녕하세요 ${this.name}님`
         }
       console.log(innerFun())  /// 안녕하세요 ''님
    }
 }
 
 person.sayName()

innerFun 함수 앞에 마침표(.) 을 붙여서 호출하지도 않았고, bind, call, apply 를 사용하지도 않았다. 일반 함수 호출 되었기 때문에 여기서 this 는 window가 된다.

const person = {
	name : 'Seo',
    sayName : function() {
    	innerFun =() => {
        	return `안녕하세요 ${this.name}님` /// 안녕하세요 Seo님
         }
       console.log(innerFun())
    }
 }
 
 person.sayName()

여기서도 innerFun 은 일반함수로 호출 되었으나 innerFun 이 화살표 함수로 선언이 되어 있다. 화살표 함수에서의 this 는 자신의 상위 스코프를 따르기 때문에 여기서 this 는 person 객체 안에 선언된 name 이 된다.

클로저 - 기억하는 함수

클로저의 정의

MDN은 클로저를 이렇게 정의한다.

"A closure is the combination of a function and the lexical environment within which that function was declared." 클로저는 함수와 그 함수가 선언된 렉시컬 환경의 조합이다.

풀어 말하면 외부 함수가 종료된 후에도 내부 함수가 외부 함수의 변수를 참조할 수 있는 현상이다.

이게 왜 가능하냐면 함수 객체는 생성될 때 [[Environment]]라는 내부 슬롯에 자신이 정의된 위치의 상위 스코프 참조를 저장한다.(함수가 살아있는 한 유지)

const x = 1;

function outer() {
  const x = 10;
  const inner = function() { console.log(x); }; // [[Environment]] = outer의 렉시컬 환경
  return inner;
}

const innerFunc = outer(); // outer 실행 컨텍스트는 스택에서 제거
innerFunc(); // 10 — 그러나 x는 여전히 참조 가능

outer의 실행 컨텍스트가 콜 스택에서 제거되어도 inner의 [[Environment]]가 outer의 렉시컬 환경을 참조하고 있기 때문에 가비지 컬렉션의 대상이 되지 않는다.

클로저라고 부르는 기준

상위 스코프의 식별자를 참조한다
외부 함수보다 더 오래 유지된다 (외부로 반환된다)

function foo() {
  const x = 1;

  // 클로저 — 상위 스코프 참조 + 외부로 반환
  function bar() {
    console.log(x);
  }
  return bar;
}

클로저 왜 쓰지?

클로저의 핵심 활용: 상태 은닉

클로저를 실전에서 가장 많이 쓰는 이유는 외부에서 접근할 수 없는 private 상태를 만들기 위해서다.

// 전역 변수 방식 — 누구나 변경 가능한 취약한 구조
let num = 0;
const increase = function() { return ++num; };

// 클로저 방식 — num은 외부에서 직접 접근 불가
const increase = (function() {
  let num = 0;
  return function() {
    return ++num;
  };
}());

increase(); // 1
increase(); // 2
increase(); // 3

즉시 실행 함수(IIFE)로 num을 감싸면 외부에서 직접 접근이 불가능해진다. 반환된 함수만이 num을 변경할 수 있다.

증가와 감소 모두 필요하다면 메서드를 가진 객체를 반환하면 된다:

const counter = (function() {
  let num = 0;

  return {
    increase() { return ++num; },
    decrease() { return num > 0 ? --num : 0; }
  };
}());

counter.increase(); // 1
counter.increase(); // 2
counter.decrease(); // 1

장점은

전역변수 사용의 최소화
데이터 보존 가능
모듈화를 통한 코드 재사용에 편리
정보의 접근 제한 (캡슐화)

	this	클로저
결정 시점	함수 호출 시점	함수 정의 시점
핵심 질문	누가 이 함수를 호출했나?	어디서 이 함수가 정의됐나?

useRef와 함께 알아야 할 React 훅들

taek2-0310 — Sun, 17 May 2026 22:48:26 +0900

1. useRef — "렌더링 없이 값을 기억하고 싶을 때"

useRef는 두 가지 역할을 한다.

① 렌더링을 유발하지 않는 변경 가능한 값 저장소

const countRef = useRef(0);

const handleClick = () => {
  countRef.current += 1;
  console.log(countRef.current); // 렌더링 없이 값 업데이트
};

구분useStateuseRef

값 변경 시 렌더링	O	X
렌더링 간 값 유지	O	O
용도	UI에 반영할 상태	내부적으로만 필요한 값

② DOM 엘리먼트 직접 참조

const inputRef = useRef(null);

const focusInput = () => {
  inputRef.current.focus(); // DOM API 직접 호출
};

return <input ref={inputRef} />;

언제 useRef를 쓸까?

이전 렌더링의 props/state 값을 기억할 때
setInterval / setTimeout ID 저장할 때
애니메이션 프레임 ID 관리할 때
DOM 엘리먼트에 직접 접근해야 할 때

2. useCallback — "함수 참조가 바뀌면 안 될 때"

useCallback은 함수를 메모이제이션한다. 의존성 배열이 바뀌지 않으면 이전 렌더링에서 생성된 동일한 함수 참조를 반환한다.

// ❌ 매 렌더링마다 새로운 함수 생성
const handleSubmit = () => {
  sendData(inputValue);
};

// ✅ inputValue가 바뀔 때만 새로운 함수 생성
const handleSubmit = useCallback(() => {
  sendData(inputValue);
}, [inputValue]);

useRef와의 관계: useCallback은 내부적으로 useRef와 유사한 메커니즘으로 이전 값을 기억한다. 직접 조합하면 의존성 없이 최신 값을 참조하는 안정적인 콜백을 만들 수 있다.

// 안정적인 콜백 패턴 (useRef + useCallback 조합)
const callbackRef = useRef(callback);
callbackRef.current = callback;

const stableCallback = useCallback((...args) => {
  return callbackRef.current(...args);
}, []); // 의존성 배열이 비어있어도 항상 최신 callback 호출

언제 useCallback을 쓸까?

React.memo로 감싼 자식 컴포넌트에 함수를 prop으로 전달할 때
useEffect의 의존성 배열에 함수가 들어갈 때
함수 생성 비용이 클 때 (드문 경우)

남용 주의: 단순한 함수에 useCallback을 무조건 감싸면 오히려 메모리와 성능에 부담이 된다.

3. useMemo — "계산 결과를 재사용하고 싶을 때"

useMemo는 값을 메모이제이션한다. useCallback이 함수를 캐싱한다면, useMemo는 함수의 반환값을 캐싱한다.

// ❌ 렌더링마다 무거운 계산 반복
const sortedList = items.sort((a, b) => b.score - a.score);

// ✅ items가 바뀔 때만 재계산
const sortedList = useMemo(() => {
  return items.sort((a, b) => b.score - a.score);
}, [items]);

useCallback vs useMemo 비교:

// 아래 두 표현은 동일하다
const memoizedFn = useCallback(fn, deps);
const memoizedFn = useMemo(() => fn, deps);

구분useCallbackuseMemo

메모이제이션 대상	함수 자체	함수의 반환값
반환 타입	함수	임의의 값
주요 용도	콜백 안정화	계산 최적화

언제 useMemo를 쓸까?

큰 배열의 필터링/정렬 같은 무거운 연산을 캐싱할 때
객체/배열을 생성해 자식 컴포넌트에 prop으로 전달할 때 (참조 동일성 유지)
파생 상태(derived state)가 복잡한 계산을 필요로 할 때

실행 컨텍스트 ㅡ 호이스팅만 알아서 뭐할래? 먼저 근본을 알아야지!

taek2-0310 — Sun, 10 May 2026 22:07:43 +0900

당신이 이미 겪어본 이상한 동작

아래 코드를 보자.

console.log(name); // undefined... 왜?
var name = '철수';
console.log(name); // '철수'

에러가 아니다. undefined다. 선언도 하기 전에 변수를 참조했는데 에러가 나지 않는다. 대부분의 개발자는 이걸 "호이스팅 때문"이라고 설명하고 넘어간다. 하지만 호이스팅은 현상의 이름이지, 원인이 아니다.

이번 글에서는 이 현상이 왜 생기는지를 JS 엔진이 코드를 처리하는 방식 즉 실행 컨텍스트 수준에서 완전히 해부한다.

1. JS 엔진은 코드를 두 번 훑는다

JS 엔진은 코드를 실행하기 전에 반드시 평가 단계를 먼저 거친다. 이 평가 단계와 실제 실행 단계, 총 두 번의 훑기가 일어난다.

Creation phase (평가 단계) — 코드를 실행하기 전, 엔진이 실행 환경을 세팅하는 단계
Execution phase (실행 단계) — 코드를 위에서 아래로 한 줄씩 실제로 실행하는 단계

var name이 undefined로 찍히는 이유가 바로 여기 있다. Creation phase에서 엔진은 var name이라는 선언을 미리 발견하고, name이라는 식별자를 등록해둔다. 단 값은 아직 undefined로만 초기화된다. Execution phase가 되어서야 = '철수' 부분이 처리된다.

코드가 올라가는 게 아니다. 엔진이 먼저 한 번 훑고 준비를 마친 다음 실행에 들어가는 것이다.

이 준비 단계의 결과물이 바로 실행 컨텍스트(Execution Context) 다.

따라서! 소스코드 평가 과정이 끝나면 비로소 선언문을 제외한 소스코드가 순차적으로 실행되기 시직한다. 즉 런타임이 시작된다. 이때 소스코드 실행에 필요한 정보’ 즉 변수나 힘수의 침조를 실행 컨텍스트가 관리히는 스코프에서 검색해서 취득한다. 그리고 변수 값의 변경 등 소스코드의 실행 결괴는 다시 실행 컨텍스트가 관리하는 스코프에 등록된다

2. 실행 컨텍스트 안에는 무엇이 있는가

실행 컨텍스트는 코드가 실행되기 위해 필요한 환경 정보를 담은 객체다. 내부에는 세 개의 슬롯이 있다.

Variable Environment

식별자 등록 장부다. var로 선언된 변수와 함수 선언문이 이 단계에서 등록된다. Creation phase에서 var 변수는 undefined로, 함수 선언문은 함수 객체 전체로 초기화된다. 이것이 함수 선언문과 함수 표현식의 동작 차이를 만드는 이유다.

// 함수 선언문 — Creation phase에서 함수 전체가 등록됨
hello(); // 'Hello!' — 정상 작동

function hello() {
  console.log('Hello!');
}

// 함수 표현식 — var greet는 undefined로만 등록됨
greet(); // TypeError: greet is not a function

var greet = function() {
  console.log('Hi!');
};

Lexical Environment

스코프 체인의 실체다. 두 가지 컴포넌트로 이루어진다.

Environment Record — 현재 스코프에서 선언된 식별자들을 실제로 저장하는 공간
Outer Lexical Environment Reference — 상위 스코프를 가리키는 참조. 이것이 스코프 체인을 만든다.

식별자를 검색할 때 엔진은 현재 Environment Record를 먼저 찾고 없으면 Outer Reference를 따라 상위 스코프로 올라간다. 전역 스코프까지 올라갔는데도 없으면 ReferenceError가 발생한다.

ThisBinding

현재 실행 컨텍스트에서 this가 가리키는 값이다. this는 선언 위치가 아닌 실행 컨텍스트가 생성되는 시점에 결정된다. 이 슬롯이 있기 때문에 같은 함수도 어떻게 호출하느냐에 따라 this가 달라진다.

3. 콜 스택 — 실행 컨텍스트의 생명주기

실행 컨텍스트는 스택 구조로 관리된다. 이를 실행 컨텍스트 스택 흔히 콜 스택(Call Stack) 이라고 부른다.

동작 원리는 단순하다.

전역 코드 평가 → Global EC 생성 → 스택에 push
함수 호출 → 새 EC 생성 → 스택에 push (현재 실행 중인 EC는 일시 중단)
함수 실행 완료 → 해당 EC를 스택에서 pop → 이전 EC 재개

다음 코드를 기준으로 이 흐름을 따라가 보자.

var x = 1;

function foo() {
  var y = 2;

  function bar() {
    var z = 3;
    console.log(x + y + z); // 6
  }

  bar();
}

foo();

단계별 흐름

① 전역 코드 평가

엔진이 전역 코드를 처음 만나면 Global Execution Context를 생성한다. Creation phase에서 x와 foo가 등록된다. x는 undefined, foo는 함수 객체로 초기화된다. 이 EC가 스택의 맨 아래에 놓인다.

[ Global EC ]  ← 현재 실행 중

② 전역 코드 실행

Execution phase가 시작되면서 x = 1 할당이 처리된다. foo() 호출 라인에 도달하면 Global EC는 일시 중단되고, foo의 EC 생성이 시작된다.

③ foo 함수 코드 평가

foo의 EC가 생성된다. Creation phase에서 y와 bar가 등록된다. Outer Lexical Environment Reference는 Global EC의 Lexical Environment를 가리킨다.

[ foo EC      ]  ← 현재 실행 중
[ Global EC   ]

④ foo 함수 코드 실행

y = 2 할당이 처리되고, bar() 호출에 도달한다. foo EC는 일시 중단된다.

⑤ bar 함수 코드 평가

bar의 EC가 생성된다. z가 등록된다. Outer Reference는 foo EC의 Lexical Environment를 가리킨다.

[ bar EC      ]  ← 현재 실행 중
[ foo EC      ]
[ Global EC   ]

⑥ bar 함수 코드 실행

z = 3이 처리된다. console.log(x + y + z)를 실행하기 위해 식별자를 검색한다.

z → bar EC의 Environment Record에서 발견 → 3
y → bar EC에 없음 → Outer Reference 따라 foo EC로 이동 → 발견 → 2
x → foo EC에도 없음 → 다시 Outer Reference 따라 Global EC로 이동 → 발견 → 1

결과: 1 + 2 + 3 = 6

⑦ 함수 종료 — 스택에서 pop

bar 실행 완료 → bar EC pop → foo EC 재개 foo 실행 완료 → foo EC pop → Global EC 재개 전역 코드 실행 완료 → Global EC pop → 스택 비워짐

(시각화자료 ⬇️ 다음 단계 버튼을 누를 때마다 foo/bar 예제 기준으로 실행 컨텍스트가 콜 스택에 push/pop되는 걸 실시간으로 보여줘요)

https://claude.ai/public/artifacts/809f7f50-2cf3-40bd-a992-b79bf6f5abd8

callstack-visualizer.html

claude.ai

5. 마무리 — 그래서 클로저는 왜 동작하는가

지금까지 살펴본 내용을 정리하면 이렇다.

JS 엔진은 코드를 실행하기 전에 Creation phase를 통해 실행 컨텍스트를 먼저 준비한다
실행 컨텍스트는 Variable Environment, Lexical Environment, ThisBinding 세 슬롯으로 구성된다
실행 컨텍스트는 콜 스택으로 관리되며, 함수 호출 시 push, 반환 시 pop된다
let/const의 TDZ는 버그를 명시적 에러로 드러내기 위한 언어 설계 의도다.

여기서 한 가지 질문이 남는다.

함수가 실행을 마치고 실행 컨텍스트가 스택에서 pop되면, 그 함수의 Lexical Environment도 사라져야 한다. 그런데 클로저는 이미 종료된 외부 함수의 변수에 접근할 수 있다. 어떻게?

실행 컨텍스트가 사라지는 것과 Lexical Environment가 사라지는 것은 다르다. 클로저가 내부 함수의 [[Environment]] 슬롯을 통해 외부 함수의 Lexical Environment를 참조하고 있는 한, 가비지 컬렉터는 그 객체를 수거하지 않는다.

이것이 클로저의 실체다.

HTTP 클라이언트 라이브러리 ky ㅡ 키 크다~라는 말은 기분이 나쁘다! 나 (번들 사이즈)작거든!

taek2-0310 — Fri, 8 May 2026 16:27:24 +0900

ky란?

ky는 브라우저 내장 fetch API를 기반으로 만든 경량 HTTP 클라이언트입니다. sindresorhus가 만들었고 순수 ESM 패키지로 배포됩니다.

pnpm install ky

import ky from 'ky';

const data = await ky.get('https://api.example.com/users').json();

딱 이게 전부입니다. fetch를 직접 쓸 때처럼 response.json()을 따로 호출하거나 Content-Type 헤더를 매번 설정할 필요가 없어요.

axios 대신 ky를 써야 하는 이유⭐️

1. 성능차이에 비해 번들 사이즈가 압도적으로 작다.

단일 GET 요청: Axios가 약 3% 빠름
POST 요청: Ky가 약 3% 빠름
동시 요청: Axios가 약 3% 빠름

번들 사이즈에 민감한 프로젝트라면 이 수치가 전부를 말해줍니다.

axios	~13 KB
ky	~4 KB

KY(3KB)와 Axios(13KB)가 번들 차이가 약 4배 차이 발생합니다. axios는 XMLHttpRequest 기반으로 브라우저/Node.js 호환성을 위한 어댑터 레이어가 포함돼 있어서 무겁습니다. ky는 브라우저 네이티브 fetch만 씁니다. 이미 브라우저에 내장된 걸 쓰니까 번들에 실어야 할 게 없어요.

2. fetch 기반 — 폴리필이 필요 없다

axios는 내부적으로 XMLHttpRequest를 씁니다. 최신 브라우저 환경에서는 굳이 XHR을 쓸 이유가 없죠. ky는 fetch를 그대로 활용하기 때문에 추가 폴리필 없이 현대 브라우저에서 바로 동작합니다.

Node.js 18+도 fetch가 내장돼 있어서 서버 사이드에서도 별도 설정 없이 씁니다.

(최근 pwa에 관심이 생겨 찾아보던 중 pwa에 핵심 기능들이 대부분 Service Worker 를 통해 구현된다는 사실을 알게 되었습니다. XHR 기반의 axios를 서비스 워커 내에서 사용하려면 별도의 폴리필이나 특수 구성이 필요하고 이로 인해 번들 크기를 증가시킬 수 있다는 것을 알게 습니다.)

3. 더 직관적인 API

// axios — HTTP 에러(4xx, 5xx)는 catch로 떨어짐
try {
  const res = await axios.get('/api/user');
  console.log(res.data); // 한 번 더 .data를 벗겨야 함
} catch (err) {
  if (axios.isAxiosError(err)) {
    console.log(err.response?.status);
  }
}

// ky — 훨씬 깔끔
try {
  const data = await ky.get('/api/user').json();
  console.log(data); // 바로 데이터
} catch (err) {
  if (err instanceof HTTPError) {
    console.log(err.response.status);
  }
}

ky는 4xx, 5xx 응답을 자동으로 HTTPError로 throw합니다. fetch의 가장 큰 함정인 "에러 응답도 resolve된다"는 문제를 해결해줘요.

4. 내장 retry

const data = await ky.get('/api/data', {
  retry: {
    limit: 3,
    methods: ['get'],
    statusCodes: [408, 500, 502, 503, 504],
  },
}).json();

네트워크 불안정 상황에서 재시도 로직이 필요할 때, axios는 직접 구현하거나 라이브러리를 추가해야 합니다. ky는 옵션 하나로 끝납니다.

5. Tree-shakeable ESM

ky는 순수 ESM 패키지입니다. 번들러가 실제로 사용하는 코드만 포함시킬 수 있어요. axios는 CommonJS 기반이라 이 이점을 활용하기 어렵습니다.

보통 이렇게 사용해요

공통 인스턴스 설정

매 요청마다 baseURL, 헤더를 반복하지 않도록 인스턴스를 만들어 씁니다.

import ky from "ky";

export const api = ky.create({
  prefix: import.meta.env.VITE_BASE_URL,
  retry: 0,
});

인증 토큰 자동 주입 (hooks)

axios의 인터셉터에 해당하는 게 ky의 hooks입니다.

// lib/api.ts
import ky from 'ky';

export const authApi = ky.create({
  prefixUrl: process.env.NEXT_PUBLIC_API_URL,
  hooks: {
    beforeRequest: [
      request => {
        const token = localStorage.getItem('access_token');
        if (token) {
          request.headers.set('Authorization', `Bearer ${token}`);
        }
      },
    ],
  },
});

토큰 만료 시 자동 갱신

액세스 토큰이 만료됐을 때 리프레시 토큰으로 재발급하고 원래 요청을 재시도하는 패턴입니다.

import ky, { HTTPError } from 'ky';

export const authApi = ky.create({
  prefixUrl: process.env.NEXT_PUBLIC_API_URL,
  hooks: {
    beforeRequest: [
      request => {
        const token = localStorage.getItem('access_token');
        if (token) {
          request.headers.set('Authorization', `Bearer ${token}`);
        }
      },
    ],
    afterResponse: [
      async (request, options, response) => {
        if (response.status === 401) {
          // 토큰 갱신 시도
          const refreshToken = localStorage.getItem('refresh_token');
          const refreshed = await ky
            .post('/auth/refresh', { json: { refreshToken } })
            .json<{ accessToken: string }>();

          localStorage.setItem('access_token', refreshed.accessToken);

          // 원래 요청 헤더 업데이트 후 재시도
          request.headers.set('Authorization', `Bearer ${refreshed.accessToken}`);
          return ky(request);
        }
      },
    ],
  },
});

공통 에러 처리

import ky, { HTTPError } from 'ky';

export const api = ky.create({
  prefixUrl: process.env.NEXT_PUBLIC_API_URL,
  hooks: {
    afterResponse: [
      async (_request, _options, response) => {
        if (!response.ok) {
          const error = await response.json<{ message: string }>();
          // 전역 토스트 알림 등
          showToast(error.message ?? '요청에 실패했습니다.');
        }
      },
    ],
  },
});

특정 요청에서만 에러를 직접 처리하고 싶다면 throwHttpErrors: false를 쓰면 됩니다.

TypeScript와 함께 쓰기

.json<T>()에 제네릭을 넘기면 타입이 바로 붙습니다.

interface User {
  id: number;
  name: string;
  email: string;
}

// GET
const user = await api.get('users/1').json<User>();

// POST
const created = await api.post('users', {
  json: { name: '홍길동', email: 'hong@example.com' },
}).json<User>();

// 배열
const users = await api.get('users').json<User[]>();

마치며

ky가 axios보다 무조건 낫다고 말하기는 어렵습니다. axios는 Node.js 구버전 지원, 업로드 진행률 추적 등 ky가 지원하지 않는 기능이 있고, 생태계도 훨씬 넓어요.

하지만 모던 브라우저 환경, 번들 사이즈 최적화, ESM 기반 프로젝트라면 ky는 충분히 설득력 있는 선택입니다. axios를 관성적으로 써왔다면 한 번 전환을 고려해볼 만해요.

참고

https://github.com/team-kareer/kareer-client/pull/21

Init(web): Ky 세팅 by huniversal · Pull Request #21 · team-kareer/kareer-client

Summary [Init] Ky 서버 통신 라이브러리 세팅 #16 Tasks Ky 라이브러리 세팅 JSONPlaceholder Test 코드 실행 KY란? 네이티브 Fetch API를 기반으로 하는 가벼운 HTTP 클라이언트 라이브러리 핵심 특징 Fetch

github.com

https://velog.io/@antisdun/axios-vs-ky-%EC%9D%B8%EC%8A%A4%ED%84%B4%EC%8A%A4-%EA%B5%AC%ED%98%84

axios vs ky 인스턴스 구현

ky를 사용한 이유 PWA 프로젝트를 진행하면서 서비스 워커에 대해 찾아보던 중, XHR 기반의 axios를 서비스 워커 내에서 사용하려면 별도의 폴리필이나 특수 구성이 필요하고 이로 인해 번들 크기를

velog.io

변수, 함수, 스코프 — 엔진이 코드를 읽는 방식

taek2-0310 — Sun, 3 May 2026 21:02:14 +0900

선언과 할당이 분리되는 순간, 호이스팅이 시작된다. var부터 let/const까지, 자바스크립트 실행 컨텍스트의 작동 원리를 파헤쳐보자.

변수 선언과 할당, 그리고 호이스팅

자바스크립트 엔진은 코드를 실행하기 전, 컴파일 단계에서 먼저 변수 선언을 스캔한다. 이때 var로 선언된 변수는 스코프 최상단으로 "끌어올려진다(hoisted)". 그러나 선언만 올라갈 뿐, 할당은 원래 자리에 그대로 남는다.

호이스팅

인터프리터가 코드를 실행하기 전에 함수, 변수, 클래스 또는 임포트(import)의 선언문을 해당 범위의 맨 위로 끌어올리는 것처럼 보이는 현상을 뜻합니다.

var의 호이스팅

// 우리가 작성하는 코드
console.log(name); // 에러가 아니라 undefined
var name = "Alice";
console.log(name); // "Alice"

엔진이 실제로 처리하는 순서
[컴파일] var name; // 선언만 최상단으로 끌어올림, 값은 undefined
[런타임] console.log(name); // → undefined
[런타임] name = "Alice"; // 이제서야 할당
[런타임] console.log(name); // → "Alice"

이처럼 var는 선언 전에 접근해도 ReferenceError가 아닌 undefined를 반환한다. 의도치 않은 동작을 유발하기 쉬운 이유다.

let의 호이스팅 처리 순서
[컴파일]name 선언 인식 // 초기화는 아직 안 함
[TDZ]console.log(name); // → ReferenceError!
[런타임]let name = "Alice"; // 이 시점에 초기화 + 할당
[런타임]console.log(name); // → "Alice"

let 은 호이스팅되지만 TDZ에 갇힘

선언은 컴파일 단계에 인식되지만, 초기화는 실행 흐름이 선언문에 도달할 때까지 이루어지지 않는다. 그 사이 구간이 TDZ(Temporal Dead Zone)이고, 이 구간에 접근하면 ReferenceError가 발생한다.

const x; // SyntaxError: Missing initializer
const y = 1; // OK
y = 2;      // TypeError: Assignment to constant variable

const은 let과 동일하지만 선언 시 반드시 할당

TDZ 동작은 let과 동일하다. 단, 선언과 동시에 반드시 값을 할당해야 하며, 이후 재할당이 불가능하다.

셋 다 호이스팅은 일어난다. 차이는 초기화 시점이다. var는 컴파일 단계에 undefined로 초기화되고, let/const는 런타임에 선언문에 도달해야 초기화된다.

함수 선언과 함수 표현식의 차이⚓️

함수도 호이스팅된다. 그런데 함수 선언문과 함수 표현식은 완전히 다르게 동작한다. 함수 선언문은 함수 전체가 올라가고, 표현식은 변수 선언부만 올라간다. 표현식을 어떤 키워드(var, let, const)로 선언하느냐에 따라 동작이 또 달라진다.

var — undefined 반환
greet();
// TypeError:
// greet is not a function

var greet = function() {
  console.log("Hi");
};

let — TDZ 에러
greet();
// ReferenceError:
// Cannot access
// before initialization

let greet = function() {
  console.log("Hi");
};

const — TDZ 에러
greet();
// ReferenceError:
// Cannot access
// before initialization

const greet = function() {
  console.log("Hi");
};

에러 종류가 다르다

var 표현식은 undefined로 호이스팅되어 TypeError, let/const 표현식은 TDZ에 걸려 ReferenceError가 발생한다.

sayHi(); // TypeError: sayHi is not a function

const sayHi = () => console.log("Hi");
// const는 아예 TDZ(일시적 사각지대)에 걸린다 (4섹션 참고)

화살표 함수도 동일하다.

console.log(typeof foo); // "function" (함수가 우선)

var foo = "bar";
function foo() {}

console.log(typeof foo); // "string" (할당 후엔 변수값)

또한 네이밍을 같을 경우 호이스팅 우선 순위는 변수보다 함수가 우선이다.

스코프: 변수가 살아있는 범위

스코프는 변수가 접근 가능한 유효 범위다. 자바스크립트는 렉시컬(정적) 스코프를 따른다. 함수가 어디서 호출되느냐가 아니라 어디서 정의되었느냐가 스코프를 결정한다.

var의 스코프 누출

for, if, while 블록 안의 var는 블록을 벗어나도 살아있다. 함수 경계만 스코프로 인정하기 때문이다.

for (var i = 0; i < 3; i++) {}
console.log(i); // 3 — 블록 밖에서도 살아있음!

for (let j = 0; j < 3; j++) {}
console.log(j); // ReferenceError — 블록 안에서만 유효

스코프 체인

변수를 찾을 때 엔진은 현재 스코프에서 시작해 상위 스코프로 거슬러 올라간다. 이 탐색 경로를 스코프 체인이라 한다.

const a = "전역";

function outer() {
  const b = "outer";

  function inner() {
    const c = "inner";
    console.log(a, b, c); // 셋 다 접근 가능
  }

  inner();
  console.log(c); // ReferenceError — 상위에선 하위 접근 불가
}
outer();

let, const와 블록 레벨 스코프

ES6에서 등장한 let과 const는 블록 {}을 스코프 단위로 인식한다. var가 함수 경계만 인정하는 것과 달리 if / for / while 블록도 독립된 스코프로 취급한다.

let — 재할당 가능
let count = 0;
count = 1; // OK
count++;   // OK

const — 재할당 불가
const MAX = 100;
MAX = 200; // TypeError!

// 단, 객체 내부는 변경 가능
const obj = { x: 1 };
obj.x = 2; // OK (참조는 유지됨)

권장 사용 전략

기본값으로 const를 쓰고, 재할당이 필요한 경우만 let을 쓴다. var는 레거시 코드 유지 외에는 사용하지 않는다.

// var: 모든 클로저가 같은 i를 참조
for (var i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 100);
}
// 출력: 3, 3, 3

// let: 각 반복마다 새로운 i가 생성됨
for (let i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 100);
}
// 출력: 0, 1, 2

var는 함수 스코프를 가지기 때문에 반복문이 끝난 후 하나의 동일한 변수 i를 참조한다. 따라서 setTimeout이 실행될 시점에는 이미 i가 3이 되어 있어 모든 출력이 3이 된다.
반면 let은 블록 스코프를 가지며, 반복문이 실행될 때마다 새로운 i가 생성된다. 이로 인해 각 setTimeout은 서로 다른 i를 참조하게 되어 0, 1, 2가 순서대로 출력된다.

내가 든 생각!❓

let과 const도 호이스팅이 일어난다고 하는데 어차피 TDZ 때문에 초기화 전에는 접근조차 할 수 없잖아?.. 그렇다면 let/const의 호이스팅은 실질적으로 어떤 의미가 있지?

딥다이브 해봤는데 let/const의 호이스팅은 "변수가 존재한다는 사실"을 미리 등록하는 것이고 중요한 것은 값을 쓰려고 호이스팅하는 게 아니라, 스코프를 확정짓기 위해 호이스팅하는 것이다.

자바스크립트는 위에서 말했듯 렉시컬(정적) 스코프를 따른다. 함수가 어디서 호출되느냐가 아니라 어디서 정의되었느냐가 스코프를 결정한다. 따라서 엔진은 실행 전에 스코프 안의 let/const 선언을 미리 인식해 "이 변수는 이 스코프 소속이다"를 확정해둔다. 그래야 렉시컬 스코프 규칙대로 올바른 스코프 체인을 구성할 수 있기 때문이다.

let x = "전역";

function foo() {
  console.log(x); // ReferenceError!
  let x = "지역";
}

foo();

만약 let이 호이스팅이 안 됐다면 console.log(x)는 스코프 체인을 타고 올라가 전역의 "전역"을 출력했을 것이다. 그러나 실제로는 ReferenceError가 발생한다. let x가 함수 스코프 안에서 호이스팅되어 "이 스코프에 x가 있다"고 이미 등록되었기 때문에, 엔진은 상위 스코프를 탐색하지 않고 현재 스코프의 x를 참조하려다 TDZ에 걸리는 것이다.

Custom Hook 그거 굳이 써야 해?? ㅡ Custom Hook 제대로 설계하기

taek2-0310 — Wed, 29 Apr 2026 11:09:21 +0900

들어가며

React를 어느 정도 써본 개발자라면 Custom Hook이 낯설지 않을 겁니다. 그런데 "잘 쓰고 있어?"라고 누군가 묻는다면, 선뜻 대답하기가 어렵습니다.

Hook을 만들어본 적 있다면 이런 고민 한 번쯤 해봤을 겁니다. "이거 굳이 Hook으로 빼야 하나?" "너무 많은 걸 한 Hook에 넣은 건 아닌가?" 그리고 더 근본적으로는 — 어떻게 해야 잘 쓰는 건지조차 잘 모르겠다는 느낌.

오늘은 그 고민을 조금 덜어보고자 합니다. Custom Hook을 언제 만들어야 하는지, 어떤 실수를 피해야 하는지, 그리고 좋은 Hook이란 어떤 모습인지를 컴포넌트의 목적과 책임이라는 관점에서 풀어보겠습니다.

Custom Hook?

커스텀 훅이란 개발자가 직접 만든 hook으로 몇가지 규칙이 존재한다. React 공식 홈페이지 내용에 따르면 hook은

1. 최상위(at the Top Level)에서만 Hook을 호출해야 한다.

반복문, 조건문 혹은 중첩된 함수 내에서 Hook을 호출하지 않아야 한다.
이 규칙을 따르면 컴포넌트가 렌더링 될 때마다 항상 동일한 순서로 Hook이 호출되는 것이 보장된다. 이러한 점은 React가 useState와 useEffect 가 여러 번 호출되는 중에도 Hook의 상태를 올바르게 유지할 수 있도록 해준다.

2. 오직 React 함수 내에서 Hook을 호출해야 한다.

이 규칙을 지키면 컴포넌트의 모든 상태 관련 로직을 소스코드에서 명확하게 보이도록 할 수 있다.

뿐만 아니라 custom hook을 사용할 때는 use로 시작해야한다는 네이밍 규칙도 존재합니다.

Custom Hook, 언제 만들어야 할까?

Custom Hook을 만드는 기준은 크게 두 가지 관점으로 나눌 수 있습니다.

1: 로직이 반복될 때

가장 직관적인 기준입니다. 같은 useState + useEffect 패턴이 두 곳 이상에서 반복된다면 Hook으로 분리할 타이밍입니다. (React 공식홈페이지 예시)

//FriendStatus : 친구가 online인지 offline인지 return하는 컴포넌트
function FriendStatus(props) {
  const [isOnline, setIsOnline] = useState(null);
  useEffect(() => {
    function handleStatusChange(status) {
      setIsOnline(status.isOnline);
    }
    ChatAPI.subscribeToFriendStatus(props.friend.id, handleStatusChange);
    return () => {
      ChatAPI.unsubscribeFromFriendStatus(props.friend.id, handleStatusChange);
    };
  });

  if (isOnline === null) {
    return 'Loading...';
  }
  return isOnline ? 'Online' : 'Offline';
}

//FriendListItem : 친구가 online일 때 초록색으로 표시하는 컴포넌트
function FriendListItem(props) {
  const [isOnline, setIsOnline] = useState(null);
  useEffect(() => {
    function handleStatusChange(status) {
      setIsOnline(status.isOnline);
    }
    ChatAPI.subscribeToFriendStatus(props.friend.id, handleStatusChange);
    return () => {
      ChatAPI.unsubscribeFromFriendStatus(props.friend.id, handleStatusChange);
    };
  });

  return (
    <li style={{ color: isOnline ? 'green' : 'black' }}>
      {props.friend.name}
    </li>
  );
}

이처럼 두 컴포넌트에서 공통으로 사용되는 로직을 분리하여 useFriendStatus 함수로 만들면 코드 재사용성을 높일 수 있습니다.

function FriendStatus(props) {
  const isOnline = useFriendStatus(props.friend.id);

  if (isOnline === null) {
    return 'Loading...';
  }
  return isOnline ? 'Online' : 'Offline';
}

function FriendListItem(props) {
  const isOnline = useFriendStatus(props.friend.id);

  return (
    <li style={{ color: isOnline ? 'green' : 'black' }}>
      {props.friend.name}
    </li>
  );
}

이렇게 공통 로직을 커스텀 훅으로 분리하면 코드 재사용성을 높일 수 있고 중복 코드를 줄여 전체 코드량을 줄일 수 있습니다.
또한 로직과 UI를 분리할 수 있어 가독성과 유지보수성이 좋아지고 여러 컴포넌트에서 동일한 로직을 일관되게 사용할 수 있다는 장점이 있습니다.

관점 2: 관심사를 분리할 때

반복이 없더라도 한 컴포넌트 안에 서로 다른 관심사의 로직이 섞여 있다면 분리할 수 있습니다. 컴포넌트가 "무엇을 렌더링하는가"에만 집중하도록 만드는 것이 목표입니다.

컴포넌트는 본래 "무엇을 렌더링할 것인가" 라는 하나의 책임을 가집니다. 그런데 데이터를 불러오는 로직, 상태를 관리하는 로직, 이벤트를 처리하는 로직이 한 컴포넌트 안에 뒤섞이다 보면 그 책임의 경계가 무너집니다. 컴포넌트가 렌더링도 하고, 데이터도 가져오고, 상태도 관리하는 모든 것을 다 떠안는 존재가 되어버리는 거죠. 또한 코드를 읽는 사람 입장에서도 "이 컴포넌트가 뭘 하는 컴포넌트지?"라는 질문에 바로 답하기 어려워집니다.

이때 Custom Hook으로 로직을 분리하면 각자의 책임이 선명해집니다. 컴포넌트는 화면을 그리는 일만, Hook은 그에 필요한 로직을 처리하는 일만 담당하게 됩니다. 책임이 나뉜 코드는 읽기도 쉽고 고치기도 쉽습니다. "UI를 바꿔야 한다"면 컴포넌트만, "데이터 처리 방식을 바꿔야 한다"면 Hook만 건드리면 되니까요.

function useInputState(
  initialValue: string = '',
  transformValue: (value: string) => string = (v: string) => v
): [value: string, onChange: ChangeEventHandler<HTMLInputElement>];

function Example() {
  const [value, onChange] = useInputState('');
  return <input type="text" value={value} onChange={onChange} />;
}

위 코드는 토스의 오픈소스 라이브러리 react-simplikit의 useInputState 입니다. 이렇게 사용했을 때 이름만 봐도 input의 상태를 관리하는 Hook임을 바로 알 수 있고 input의 상태 관리라는 하나의 책임만 가지고 있기 때문에 이를 사용하는 컴포넌트는 값을 어떻게 관리할지 고민할 필요 없이 렌더링에만 집중할 수 있습니다.

만들지 말아야 할 경우도 있다

Hook이 단순히 useState 하나만 감싸거나, 한 곳에서만 쓰이는 데 복잡하지도 않다면 굳이 Hook으로 분리할 필요가 없습니다. 추상화는 비용입니다.

흔히 하는 실수들

실수 1: 너무 많은 걸 한 Hook에 몰아넣기

Hook을 만들다 보면 "이것도 넣고, 저것도 넣고"가 되기 쉽습니다. 그러다 보면 재사용할 수 없는 Hook이 됩니다.

function useUserDashboard() {
  // 유저 정보 fetch
  // 알림 목록 fetch
  // 모달 열림 상태
  // 탭 선택 상태
  // ... 다 여기에
}

실수 2: 의존성 배열 관리 실수

Hook 내부에서 useEffect를 쓸 때 의존성 배열을 잘못 관리하면 무한 렌더링이나 오래된 값(stale closure) 문제가 생깁니다.

useEffect(() => {
  fetchData(options); // options가 객체라면?
}, [options]); // 매 렌더마다 새 객체 → 무한 호출

실수 3: 반환값 설계 실수

반환값에 이름이 없거나 일관성이 없으면 사용하는 쪽에서 혼란이 생깁니다. 다음 섹션에서 자세히 다룹니다.

좋은 Hook의 인터페이스 설계

배열 vs 객체, 언제 어떤 걸 쓸까?

useState처럼 배열을 반환하면 사용하는 쪽에서 이름을 자유롭게 지을 수 있어 여러 번 사용하기 좋습니다. 반면 반환값이 3개 이상이 되면 객체가 훨씬 읽기 편합니다.

// 2개 이하 → 배열도 괜찮음 (useState 패턴)
const [isOpen, setIsOpen] = useToggle(false);

// 3개 이상 → 객체로
const { data, loading, error, refetch } = useFetch(url);

네이밍 컨벤션

Hook 이름은 use로 시작하는 건 기본이고, 그 다음이 중요합니다. 무엇을 하는지가 이름에 드러나야 합니다.

// 모호한 이름
useData(), useHandler(), useHelper()

// 명확한 이름
useFetch(url)
useLocalStorage(key, defaultValue)
useIntersectionObserver(ref, options)

재사용성과 유연성의 트레이드오프

Hook을 너무 유연하게 만들려다 보면 옵션 파라미터가 폭발적으로 늘어납니다. 반대로 너무 구체적으로 만들면 재사용이 어렵습니다.

좋은 기준은 지금 필요한 것만 파라미터로 나중에 필요해지면 그때 확장하는 것입니다. 미리 유연하게 만들어둔 Hook은 대부분 복잡도만 높아집니다.

Hook의 파라미터가 5개를 넘어간다면, 객체 하나로 받는 것을 고려하세요. 그리고 정말 이게 하나의 Hook이어야 하는지 다시 생각해보는 것도 좋습니다.

마치며 — 체크리스트

Custom Hook을 만들기 전후로 이 체크리스트를 확인해보세요.

이 Hook이 하나의 관심사만 다루고 있는가?
Hook 이름만 보고 무엇을 하는지 알 수 있는가?
반환값이 3개 이상이면 객체로 반환하고 있는가?
useEffect 의존성 배열에 객체나 함수를 직접 넣지 않는가?
이 Hook 없이도 간단하게 해결되는 문제는 아닌가?

참고

https://leego.tistory.com/entry/React-Custom-hook%EC%9D%84-%EB%A7%8C%EB%93%A4%EA%B8%B0-%EC%A0%84%EC%97%90-%EA%B3%A0%EB%A0%A4%ED%95%B4%EC%95%BC-%ED%95%A0-%EA%B2%83%EB%93%A4

[React] Custom hook을 만들기 전에 고려해야 할 것들

들어가면서 Building your own Hooks lets you extract component logic into reusable functions. 최근 내가 컴포넌트를 설계할 때 가장 중요하게 생각하는 것은 컴포넌트의 역할이 명확하게 나타나는가 이다. 예를

leego.tistory.com

https://ko.legacy.reactjs.org/docs/hooks-rules.html

Hook의 규칙 – React

A JavaScript library for building user interfaces

ko.legacy.reactjs.org

https://ko.legacy.reactjs.org/docs/hooks-custom.html

자신만의 Hook 만들기 – React

A JavaScript library for building user interfaces

ko.legacy.reactjs.org

https://velog.io/@oka1313/React-Custom-Hooks

[React] Custom Hooks

Custom Hooks이란 개발자가 스스로 커스텀한 훅을 의미한다. 이를 이용해 반복되는 로직을 함수로 뽑아내어 재사용할 수 있다.

velog.io

나는 누구? 여긴 어디? — JavaScript this 완전 정복

taek2-0310 — Tue, 21 Apr 2026 22:42:46 +0900

this란?

this가 결정되는 4가지 규칙

1. 기본 바인딩

아무런 컨텍스트 없이 함수를 단독 호출하면 this는 전역 객체를 가리킨다. 그리고 이 this는 브라우저에서 window 객체가 된다.

function greet() {
  console.log(this); // window (브라우저)
}

greet();

2. 암시적 바인딩

객체의 메서드로 호출되면 this는 그 객체를 가리킨다.

const user = {
  name: '철수',
  greet() {
    console.log(this.name); // '철수'
  }
};

user.greet(); // this === user

3. 명시적 바인딩

함수가 호출될 때 apply, call 또는 bind가 사용되었다면 첫번째 인자로 전달하는 값에 this 를 바인딩 한다.

bind는 새로운 함수를 반환하며 this를 영구 고정한다는 점에서 call/apply와 다르다.

jsfunction greet() {
  console.log(this.name);
}

const user = { name: '철수' };

greet.call(user);        // '철수'
greet.apply(user);       // '철수'
const bound = greet.bind(user);
bound();                 // '철수'

4. new 바인딩

new 키워드로 생성자 함수를 호출하면, this는 새로 생성되는 인스턴스 객체를 가리킨다

function Person(name) {
  this.name = name; // 새 인스턴스에 바인딩
}

const p = new Person('민준');
console.log(p.name); // '민준'

❗️우선순위: new > 명시적(bind) > 암시적(메서드) > 기본❗️

화살표 함수의 this — 완전히 다른 규칙❓

화살표 함수는 this를 아예 갖지 않는다. 대신 자신이 선언된 위치의 외부 스코프 this를 그대로 캡처한다.(클로저)

const person = {
	name : 'Seo',
    sayName : function() {
    	innerFun = function() {
        	return `안녕하세요 ${this.name}님`
         }
       console.log(innerFun())  /// 안녕하세요 ''님
    }
 }
 
 person.sayName()

const person = {
	name : 'Seo',
    sayName : function() {
    	innerFun =() => {
        	return `안녕하세요 ${this.name}님` /// 안녕하세요 Seo님
         }
       console.log(innerFun())
    }
 }
 
 person.sayName()

그래서 this 왜 써? — this vs 일반 변수

일반 변수(클로저)

function makeUser(name) {
  let _name = name; // 그냥 변수

  return {
    getName() { return _name; },
    setName(n) { _name = n; }
  };
}

const user1 = makeUser('철수');
const user2 = makeUser('영희');

위 코드는 문제없이 작동한다.

const users = Array.from({ length: 1000 }, (_, i) => makeUser(`user${i}`));

근데 유저가 1000명이면? 함수 내용은 완전히 똑같은데 getName, setName 함수가 1000개 메모리에 생긴다.

function User(name) {
  this.name = name;
}

User.prototype.getName = function() {
  return this.name; // this가 각 인스턴스를 가리킴
};

const users = Array.from({ length: 1000 }, (_, i) => new User(`user${i}`));

getName 함수는 메모리에 딱 1개만 존재하고, 1000개의 인스턴스가 공유한다. this 덕분에 "내가 지금 어느 인스턴스인지"를 호출 시점에 알 수 있다.

또한 일반 함수(클로저 방식)은 확장이 매우 어렵다.

// 클로저 방식 — Admin을 만들려면?
function makeAdmin(name) {
  let _name = name;
  return {
    getName() { return _name; },
    kickUser() { console.log(`${_name}이 유저를 추방`); }
    // getName을 또 써야 함 — 재사용 불가
  };
}

// this 방식 — 상속으로 깔끔하게 확장
class User {
  constructor(name) { this.name = name; }
  getName() { return this.name; }
}

class Admin extends User {
  kickUser() { console.log(`${this.name}이 유저를 추방`); }
  // getName은 그냥 물려받음
}

this가 단점이 존재하지 않는건 아니다.

1. 콜백 지옥에서의 바인딩 소실

2. 이벤트 리스너로 넘기면 this가 소실

3. 같은 함수라도 호출 방식에 따라 this가 달라지기 때문에, 코드를 처음 보는 사람은 this가 무엇인지 추적하기 어렵다.

그래도 메서드를 효율적으로 재사용할 수 있고, 객체 단위로 상태를 관리할 수 있다는 점에서 충분히 사용할 가치가 있는 개념이라고 생각한다.

DOM 이벤트 핸들러에서의 this

이번 주차의 내용과 과제가 이벤트 핸들러와 깊이 관련되어 있어, 이에 대해 조금 더 딥다이브해보았다.

이벤트 핸들러로 함수를 등록하면, 그 함수 안의 this는 이벤트가 등록된 DOM 요소 자체를 가리킨다.

button.addEventListener('click', function() {
  console.log(this); // <button> 요소
});

this	리스너가 등록된 요소
e.currentTarget	리스너가 등록된 요소 (this와 항상 같음)
e.target	실제로 클릭된 요소 (다를 수 있음)

e.currentTarget vs e.target 차이

<div id="outer">   <!-- 리스너가 등록된 곳 -->
  <button>클릭</button>  <!-- 실제 클릭한 곳 -->
</div>

outer.addEventListener('click', function(e) {
  console.log(e.currentTarget); // div — 리스너가 등록된 요소
  console.log(e.target);        // button — 실제로 클릭된 요소
  console.log(this);            // div — currentTarget과 항상 같음
});

우리가 이걸로 뭘 할 수 있느냐??⭐️⭐️⭐️

"여러 요소에 같은 함수를 쓰되, 클릭된 그것만 다루고 싶을 때" 이벤트 핸들러의 this가 빛을 발한다.

1. 클릭한 요소만 스타일 변경

const buttons = document.querySelectorAll('.btn');

buttons.forEach(btn => {
  btn.addEventListener('click', function() {
    // 클릭한 버튼만 active 클래스 추가
    buttons.forEach(b => b.classList.remove('active'));
    this.classList.add('active'); // 클릭된 그 버튼
  });
});

탭 UI, 토글 버튼, 네비게이션 메뉴에서 "선택된 것만 강조" 할 때 쓰는 패턴.

2. 클릭한 요소의 데이터 읽기

document.querySelectorAll('.product-card').forEach(card => {
  card.addEventListener('click', function() {
    const id = this.dataset.id;       // data-id 속성
    const name = this.dataset.name;   // data-name 속성
    console.log(`${name} 상품 클릭됨`);
    fetchProductDetail(id);
  });
});

같은 함수 하나로 어떤 카드를 클릭했는지 this로 구분.

3. 폼 입력 유효성 검사

document.querySelectorAll('input').forEach(input => {
  input.addEventListener('blur', function() {
    if (this.value.trim() === '') {
      this.classList.add('error');         // 빈 input에만 에러 표시
      this.placeholder = '필수 입력입니다';
    }
  });
});

모든 input에 같은 리스너를 달아도, this가 지금 포커스 벗어난 그 input을 가리켜서 각각 따로 처리

4. 이벤트 위임

document.querySelector('.menu').addEventListener('click', function(e) {
  const clicked = e.target.closest('.menu-item');
  if (!clicked) return;

  // this가 진짜 필요한 순간
  // 부모 안의 모든 형제를 한 번에 리셋
  this.querySelectorAll('.menu-item').forEach(item => {
    item.classList.remove('active');
  });

  // 클릭된 것만 active
  clicked.classList.add('active');
});

◆가장 중요한 이벤트 위임◆

리스트 아이템이 100개면 리스너를 100개 달아야 할까? 아니다.

this → 리스너 등록된 .menu e.target → 실제 클릭된 .menu-item

이 패턴은 동적으로 추가되는 요소에도 자동으로 동작해서 굉장히 많이 사용된다.

참고

https://velog.io/@o1011/JavaScript-this-%EB%9E%80

[JavaScript] this 란

this 란 무엇인가요 ? 자바스크립트에서의 this 는 현재 실행 중인 코드에서 자신이 속한 객체 또는 자신이 생성할 인스턴스를 가리키는 자기 참조 변수입니다. 단 this가 가리키는 값, 즉 this 의 바

velog.io

https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Operators/this

this - JavaScript | MDN

developer.mozilla.org

CSS의 원칙을 깨는 Tailwind, 정말 괜찮은 걸까?

taek2-0310 — Mon, 6 Apr 2026 22:06:57 +0900

CSS의 기본 철학은 구조(HTML)와 표현(CSS)의 분리이다. 따라서 아래와 같이 HTML은 버튼이라는 의미만을 담고, 스타일은 CSS로 분리하는 것이 일반적이다. 이러한 방식은 코드의 재사용성을 높이고, 유지보수를 용이하게 하며, 스타일을 일관되게 변경할 수 있도록 한다.

//HTML
<button class="primary-btn">확인</button>

//CSS
.primary-btn {
  background-color: blue;
  color: white;
  padding: 8px 16px;
}

또한 인라인 스타일도 존재한다. 이는 HTML 내부에 스타일을 직접 작성하는 방식으로, 구조와 표현의 분리라는 장점을 살리기 어렵기 때문에 일반적으로 지양되며 많은 개발자들이 선호하지 않는다.

<button style="background-color: blue; color: white; padding: 8px 16px;">
  확인
</button>

Tailwind

Tailwind는 HTML에 미리 정의된 작은 단위의 클래스(utility class)를 직접 적용해 스타일을 만드는 CSS 프레임워크이다. 개발자 설문에서도 사용률 상위권을 차지하며, 현재 가장 인기 있는 CSS 프레임워크 중 하나로 평가받고 있다.

<button class="bg-blue-500 text-white px-4 py-2 rounded">
  확인
</button>

그렇다면 위와 같이 인라인 스타일처럼 작성하는 Tailwind는 CSS의 기본 철학을 무시한 것일까? 만약 그렇다면, 어떻게 이렇게 많은 개발자들의 선택을 받을 수 있었을까?

작동원리⚙️

우선 기본 CSS의 작동원리는 아래와 같다.

1. 브라우저가 HTML을 로드한다.

2. HTML 을 DOM (Document Object Model) 로 변환한다.

3. 그러면 브라우저는 HTML 문서에 연결된 임베디드 이미지, 동영상, 링크된 CSS같은 대부분의 리소스들을 가져온다.

4. 브라우저는 가져온 CSS를 구문 분석하고 선택자 유형별로 다른 규칙을 다른 "버킷" 으로 정렬한다.

5. 렌더 트리는 규칙이 적용된 후에 표시되어야 하는 구조로 배치한다.

6. 페이지의 시각적 표시가 화면에 표시된다. (페인팅)

★ 쉽게 말해 ★

브라우저는 HTML을 DOM으로, CSS를 CSSOM으로 변환한 뒤 이를 결합해 화면을 그린다. 이 과정에서 CSS는 선택자(p, span)를 통해 요소를 찾고,cascade(스타일이 겹칠 때 어떤 규칙이 적용될지를 결정하는 방식), specificity(선택자의 구체성에 따른 우선순위), inheritance(부모 요소로부터 스타일이 전달되는 특성) 규칙에 따라 최종 스타일을 계산한다. 이후 박스 모델과 레이아웃 규칙에 따라 각 요소의 크기와 위치가 정해지고, 브라우저는 이를 실제 화면에 렌더링한다.

그럼 tailwind는 어떻게 동작할까?

1. 개발자가 HTML/JSX/TSX 등에 Tailwind 클래스를 작성한다.

2. Tailwind가 빌드 과정에서 이 클래스들을 분석한다.

3. 대응하는 CSS 규칙을 생성한다.

4. 브라우저는 HTML과 생성된 CSS를 읽는다.

5. DOM과 CSSOM을 만든다.

6. 클래스 선택자에 맞는 스타일을 요소에 적용한다

7.최종 레이아웃과 렌더링이 이루어진다.

겉으로 보면 HTML 안에 스타일 정보가 직접 들어가 있는 것처럼 보여 인라인 스타일과 유사해 보일 수 있다. 하지만 브라우저 관점에서 보면 이는 인라인 스타일이 아니다. Tailwind는 class 속성만을 사용하며 브라우저 입장에서는 여전히 일반적인 클래스 기반 CSS로 동작한다.

Tailwind는 프로젝트 파일을 스캔하여 어떤 클래스가 사용되었는지 분석한 뒤 해당 클래스에 대응하는 CSS 규칙만 생성해 최종 CSS 파일에 포함시킨다. 즉 Tailwind는 빌드 타임에 작동하는 도구이며 브라우저에서는 기존 CSS와 동일한 방식으로 해석되고 적용된다.

Tailwind가 많은 사랑을 받는 이유 중 하나는 JIT(Just-In-Time) 컴파일 방식을 사용한다는 점이다. 필요한 스타일을 실시간으로 생성하기 때문에 실제로 사용된 클래스만 CSS로 만들어지며 빌드 속도가 빠르고 최종 파일 크기도 줄어든다.

또한 Purge 기능을 통해 사용되지 않는 CSS를 제거함으로써 결과물의 크기를 최소화할 수 있다. 이로 인해 불필요한 스타일이 포함되지 않고 보다 가볍고 효율적인 결과물을 얻을 수 있다.

Tailwind는 왜 나왔을까❓

어느 정도 규모가 있는 개발을 진행하다 보면 CSS 파일은 점점 비대해진다. 또한 협업 과정에서는 해당 클래스가 어디에서 사용되는지 파악하기 어려워 가독성이 떨어지고, 클래스 명을 짓는 것 역시 쉽지 않다는 문제를 겪게 된다.

Tailwind는 이러한 문제를 효과적으로 해결한다. 유틸리티 클래스를 기반으로 필요한 스타일만 조합해 사용하기 때문에 CSS 파일이 불필요하게 커지는 것을 방지할 수 있으며 스타일이 HTML에 직접 드러나기 때문에 코드만 보아도 어떤 디자인이 적용되었는지 파악할 수 있다. 또한 의미를 고민해 클래스를 새로 정의할 필요 없이 미리 정의된 규칙을 조합해 사용할 수 있어 네이밍에 대한 부담도 줄어든다.

Tailwind는 기본 철학을 무시한걸까?

그렇다면 Tailwind는 CSS의 기본 철학을 무시한 것일까?

이 질문에 대해 명확하게 그렇다 혹은 아니다라고 단정 짓기는 어렵다.

전통적인 CSS는 구조와 표현을 파일 단위로 분리하는 방식으로 관심사를 나누어 왔다. 반면 Tailwind는 이러한 분리 방식을 따르기보다는 스타일을 컴포넌트 내부에서 함께 다루며 역할 단위로 응집시키는 접근을 취한다. 즉 분리의 기준이 파일에서 컴포넌트로 이동했다고 볼 수 있다.

만약 구조와 표현을 분리하는 이유가 유지보수성과 확장성을 높이기 위함이라면, Tailwind는 오히려 다른 방식으로 그 목적을 달성하고 있는 셈이다. 스타일이 HTML에 직접 드러나기 때문에 코드를 읽는 것만으로도 UI를 이해할 수 있고 어디에서 사용되는지 추적하기도 쉬워진다.

그렇다면 Tailwind는 CSS의 기본 철학을 무시한 것이라기보다 그 철학을 다른 방식으로 해석하고 적용한 도구라고 볼 수도 있지 않을까?

참고

https://velog.io/@kkang123/tailwind-CSS-%EC%9E%91%EB%8F%99-%EC%9B%90%EB%A6%AC

tailwind CSS 작동 원리

기존 프로젝트에 Tailwind CSS 사용 이유로는 디자인의 일관성을 유지하여 재활용성을 높였고, 커스텀 디자인 작업 시간을 단축하기 위해 적용했었습니다.그리고 더 풀어서 설명하자면 Tailwind CSS는

velog.io

https://developer.mozilla.org/ko/docs/Learn_web_development/Core/Styling_basics/What_is_CSS

CSS 작동 방식 - Web 개발 학습하기 | MDN

developer.mozilla.org

taek2-0310 님의 블로그

브라우저 렌더링 과정과 DOM

1. 브라우저 렌더링 과정 개요

2. 요청과 응답

3. HTTP 1.1 vs HTTP 2.0

4. HTML 파싱과 DOM 생성

5. CSS 파싱과 CSSOM 생성

6. 렌더 트리 생성

7. 자바스크립트 파싱과 실행

8. 리플로우와 리페인트

9. script 태그 위치와 async/defer

문제: <head> 안에 <script> 배치 시

해결책 1: </body> 직전에 배치

해결책 2: async / defer 어트리뷰트

10. DOM이란?

노드의 4가지 핵심 타입

11. 노드 취득 메서드 비교

id로 취득

태그 이름으로 취득

class로 취득

CSS 선택자로 취득 ✅ 권장

HTMLCollection vs NodeList 비교

12. DOM 조작

텍스트 조작

innerHTML vs insertAdjacentHTML vs createElement

노드 생성 및 추가

주요 노드 탐색 프로퍼티

자바스크립트 객체와 프로토타입 — 언제, 왜 쓰는 걸까?

1부. 객체 리터럴 — 객체를 만드는 가장 쉬운 방법

객체가 뭔지부터

객체를 만드는 방법은 5가지

✅ 객체 리터럴 — 단순하고 일회성인 데이터 묶음

✅ 생성자 함수 / 클래스 — 같은 구조의 객체를 여러 개 만들 때

✅ Object.create — 프로토타입을 직접 지정할 때

ES6 축약 문법

프로퍼티 축약

메서드 축약

AI에게 물어본 "내부 동작이 다릅니다(non-constructor, super 사용 가능)."이 뭘 의미할까?1. non-constructor — "이건 생성자로 못 써"

2. super — 이게 실제로 중요한 차이

근데 실무에서 객체 리터럴에 super 쓸 일이 있나?

계산된 프로퍼티 이름

2. 프로토타입 — 자바스크립트 상속의 실체

왜 프로토타입이 필요한가?

프로토타입으로 해결하기

프로토타입 체인 — 어떻게 찾아가는가

3각 관계: 생성자 함수 ↔ 프로토타입 ↔ 인스턴스

정적 메서드 vs 프로토타입 메서드 — 언제 뭘 쓸까?

프로퍼티 섀도잉 — 오버라이딩의 실체

instanceof와 프로퍼티 확인

instanceof — 프로토타입 체인 확인

프로퍼티 존재 확인

프로퍼티 열거 — for...in의 함정

3부. 정리 — 언제 무엇을 쓸 것인가

객체 생성 방법 선택 기준

메서드 정의 위치 선택 기준

프로퍼티 열거/확인 선택 기준

this, 클로저 사실 나도 잘 몰라...ㅡJavaScript 완전 정복

this란?

this가 결정되는 4가지 규칙

화살표 함수의 this — 완전히 다른 규칙❓

클로저 - 기억하는 함수

클로저의 정의

클로저라고 부르는 기준

클로저 왜 쓰지?

클로저의 핵심 활용: 상태 은닉

useRef와 함께 알아야 할 React 훅들

1. useRef — "렌더링 없이 값을 기억하고 싶을 때"

2. useCallback — "함수 참조가 바뀌면 안 될 때"

3. useMemo — "계산 결과를 재사용하고 싶을 때"

실행 컨텍스트 ㅡ 호이스팅만 알아서 뭐할래? 먼저 근본을 알아야지!

당신이 이미 겪어본 이상한 동작

1. JS 엔진은 코드를 두 번 훑는다

2. 실행 컨텍스트 안에는 무엇이 있는가

Variable Environment

Lexical Environment

ThisBinding

3. 콜 스택 — 실행 컨텍스트의 생명주기

단계별 흐름

5. 마무리 — 그래서 클로저는 왜 동작하는가

HTTP 클라이언트 라이브러리 ky ㅡ 키 크다~라는 말은 기분이 나쁘다! 나 (번들 사이즈)작거든!

AI에게 물어본 "내부 동작이 다릅니다(non-constructor, super 사용 가능)."이 뭘 의미할까?
1. non-constructor — "이건 생성자로 못 써"