true-false

OS 4편 - 실무 병목 찾기

isTrue — Wed, 8 Apr 2026 00:18:53 +0900

에러 로그도 없는데 특정 시간대에 API가 느려진다. 이걸 어떻게 찾아야 할까. 지금까지 배운 OS 개념을 전부 연결하는 파트다.

1. 전형적인 장애 패턴

스케줄러 대용량 쿼리 실행
└── DB 커넥션 오래 점유
    └── HikariCP 커넥션 풀 소진
        └── 일반 API 요청들이 커넥션 대기
            └── 스레드 점유 시간 길어짐
                └── Tomcat Thread Pool 소진
                    └── 전체 API 느려짐 (에러는 없음)

에러가 없으니 로그만 봐선 원인을 못 찾는다. 스레드와 커넥션 풀 상태를 직접 봐야 한다.

2. Tomcat 스레드 풀 확인

Spring Actuator로 현재 스레드 상태를 볼 수 있다.

yaml

# application.yml
management:
  endpoints:
    web:
      exposure:
        include: metrics

GET /actuator/metrics/tomcat.threads.busy
GET /actuator/metrics/tomcat.threads.config.max

busy / max = 0.9 이상 → 스레드 풀 거의 소진

3. 스레드 덤프 - 스레드가 뭘 하다 묶였나

스레드 풀이 소진됐다면, 스레드가 정확히 어디서 대기 중인지 찍어봐야 한다.

bash

jps                  # 실행 중인 Java 프로세스 PID 확인
jstack {PID}         # 스레드 덤프 출력

결과에서 이런 게 보이면 DB 커넥션 대기 중인 거다.

"http-nio-8080-exec-1" - WAITING
    at sun.misc.Unsafe.park
    at HikariPool.getConnection   ← DB 커넥션 못 잡고 대기 중

4. HikariCP 커넥션 풀 확인

GET /actuator/metrics/hikaricp.connections.active
GET /actuator/metrics/hikaricp.connections.pending

pending > 0 → 커넥션 기다리는 스레드 있음

5. Tomcat 스레드 vs HikariCP 커넥션 비율

여기서 중요한 포인트가 있다.

Tomcat 스레드 200개
HikariCP 커넥션 10개 (기본값)

→ 요청 200개가 와도 DB 작업은 10개씩만 처리
→ 나머지 190개 스레드는 커넥션 기다리며 대기
→ 스레드 200개가 있어도 의미 없음

두 풀은 항상 같이 봐야 한다. 둘 중 하나만 크다고 해결이 안 된다.

HikariCP 권장 설정은 이렇다.

커넥션 수 = (CPU 코어 수 * 2) + 유효 디스크 수
ex) 4코어 서버 → 약 10개

커넥션 수를 무조건 늘린다고 좋은 게 아니다. DB 서버가 감당할 수 있는 커넥션 수에 한계가 있고, 무리하게 늘리면 DB 서버 부하가 증가해서 오히려 전체가 느려진다.

6. 모니터링 순서 정리

특정 시간대에 API가 느려지면 이 순서로 확인한다.

1. 해당 시간에 도는 스케줄러 있는지 확인
2. tomcat.threads.busy → 스레드 풀 얼마나 찼나
3. hikaricp.connections.pending → DB 커넥션 대기 있나
4. jstack으로 스레드 덤프 → 스레드가 정확히 뭘 하다 묶였나

OS 3편 - Race Condition, synchronized (feat. volatile)

isTrue — Tue, 7 Apr 2026 23:57:01 +0900

여러 스레드가 같은 메모리를 동시에 건드릴 때 생기는 문제다.
로컬에선 안 터지다가 운영에서 트래픽 몰릴 때 갑자기 데이터가 이상해지는 버그의 주범이다.

1. Race Condition이란

count++ 한 줄처럼 보이지만 CPU 입장에선 3단계다.

1. count 값을 메모리에서 읽어옴  (READ)
2. 1을 더함                      (ADD)
3. 결과를 메모리에 저장           (WRITE)

스레드 2개가 동시에 실행되면 이 사이에 끼어들 수 있다.

스레드 1                  스레드 2
READ  → count = 0
                          READ  → count = 0
ADD   → 0 + 1 = 1
                          ADD   → 0 + 1 = 1
WRITE → count = 1
                          WRITE → count = 1

최종 결과: count = 1  (원래 2가 되어야 함)

실행 순서에 따라 결과가 달라지는 이 상황이 Race Condition이다.

실무에서 주로 터지는 상황

├── 재고 차감 (동시에 마지막 1개 주문)
├── 포인트 / 잔액 업데이트
├── 좋아요 / 조회수 카운터
└── 선착순 쿠폰 발급

로컬 테스트에선 요청이 1~2개라 안 터지다가, 운영에서 트래픽 몰릴 때 갑자기 숫자가 안 맞는다. 로그엔 에러도 없다.

2. 해결 방법

synchronized

한 번에 스레드 하나만 이 메서드에 들어올 수 있게 막는다.

public synchronized void like() {
    count++;
}

나머지 스레드는 밖에서 대기한다. Race Condition은 잡히지만, 읽기까지 전부 직렬화되니 트래픽 많을 때 성능이 떨어진다.

AtomicInteger

READ-ADD-WRITE를 CPU 레벨에서 하나의 원자적 연산으로 처리한다. synchronized보다 훨씬 빠르고, 단순 카운터엔 이걸 쓰는 게 맞다.

AtomicInteger count = new AtomicInteger(0);

public void like() {
    count.incrementAndGet();
}

3. volatile - 가시성 문제

CPU는 메모리에서 매번 읽으면 느리니까 캐시에 값을 복사해서 쓴다.

문제는 스레드 1이 값을 업데이트해도 스레드 2가 CPU 캐시에서 오래된 값을 읽을 수 있다는 거다.

실무에서 직접 겪다가 발견한 volatile 키워드!

메모리: count = 5

CPU 1 캐시: count = 5    CPU 2 캐시: count = 5

스레드 1이 count = 6으로 업데이트
→ CPU 1 캐시엔 6
→ 메모리엔 아직 5
→ 스레드 2는 캐시에서 5를 읽음 (오래된 값)

volatile은 캐시를 우회해서 항상 메모리에서 직접 읽고 쓰게 강제한다.

volatile int count = 0;

단, volatile만으로는 Race Condition이 안 잡힌다

volatile이 해결하는 건 가시성(Visibility) 문제다. READ-ADD-WRITE 사이에 다른 스레드가 끼어드는 건 여전히 막지 못한다.

volatile count = 0

스레드 1: READ  → 0 (메모리에서 직접 읽음)
스레드 2: READ  → 0 (메모리에서 직접 읽음)
스레드 1: ADD, WRITE → 1
스레드 2: ADD, WRITE → 1  ← 여전히 Race Condition

4. 실무 케이스 - Map 참조 교체

@Component에서 여러 빈이 공유하는 Map을 주기적으로 새 버전으로 교체하는 구조라면 volatile이 정확한 선택이다.

@Component
public class SomeComponent {
    private volatile Map<String, String> cache = new HashMap<>();

    public void update() {
        Map<String, String> newMap = new HashMap<>();
        newMap.put("key1", "value1"); // 다 채우고
        newMap.put("key2", "value2"); // 다 채우고
        cache = newMap;               // 마지막에 참조 교체
    }

    public String get(String key) {
        return cache.get(key);
    }
}

여기서 위험한 건 Race Condition이 아니라 스레드가 CPU 캐시에서 이전 참조를 읽는 가시성 문제다.

volatile이 참조 교체를 모든 스레드에 즉시 보이게 해준다.

단, 반드시 새 맵을 완전히 채운 다음에 참조를 교체해야 한다!!

빈 맵으로 먼저 교체하고 채우면, 그 사이에 읽는 스레드가 빈 맵을 보게 된다.

만약 맵 내부를 직접 수정하는 구조로 바뀐다면 그때는 ConcurrentHashMap을 써야 한다.

private Map<String, String> cache = new ConcurrentHashMap<>();

5. 서버가 2대 이상이면?

synchronized와 volatile은 같은 JVM 안에서만 유효하다. 서버가 2대면 JVM도 2개고 메모리도 따로다.

서버 1 (JVM 1)          서버 2 (JVM 2)
재고 = 1                재고 = 1

둘 다 동시에 차감 시도
→ 둘 다 성공
→ 재고 -2 되어야 하는데 -1

분산 환경에서는 DB 레벨 락이나 Redis 분산 락으로 해결한다. 이건 Redis 챕터에서 제대로 다룬다.

6. 정리

	해결하는 문제	한계
synchronized	Race Condition 방지	같은 JVM 안에서만, 성능 저하
volatile	CPU 캐시 가시성 문제	Race Condition은 못 막음
AtomicInteger	Race Condition 방지	단순 연산에만 적합
ConcurrentHashMap	맵 내부 동시 수정	-
DB / Redis 락	분산 환경 Race Condition	네트워크 비용 발생

OS 2편 - 동기 vs 비동기, 그리고 언제 써야 하는가

isTrue — Tue, 7 Apr 2026 23:41:06 +0900

스레드가 "기다리는 시간"을 어떻게 쓰느냐의 차이다. 단순히 빠르고 느린 게 아니라, 상황에 따라 골라 써야 한다.

1. 동기(Synchronous)란

동기 방식에서 스레드는 작업이 끝날 때까지 그 자리에서 기다린다. DB 쿼리를 날리면 응답이 올 때까지, 외부 API를 호출하면 결과가 올 때까지 스레드는 아무것도 못 하고 점유만 한다. 이걸 블로킹(Blocking) 이라 한다.

스레드 1
├── 요청 받음
├── DB 쿼리 날림
├── ⏳ DB 응답 기다리는 중... (CPU 안 씀, 스레드 점유 중)
├── ⏳ 기다리는 중...
├── DB 응답 옴
├── 결과 가공
└── 응답 반환

DB 쿼리 100ms 중 실제 CPU를 쓰는 시간은 5ms 정도다. 나머지 95ms는 그냥 대기다. 그런데 스레드는 그 시간 내내 자리를 차지한다.

Tomcat 스레드 풀이 200개인데 동시 요청이 몰리면? 200개 스레드가 전부 DB 기다리느라 멈춰있고, 201번째 요청부터 큐에서 대기하게 된다.

2. 비동기(Asynchronous)란

비동기 방식에서는 I/O 작업을 던져놓고 스레드를 즉시 반납한다. 응답이 오면 이벤트가 발생하고, 그때 스레드를 다시 꺼내 나머지 처리를 한다.

스레드 1
├── 요청 받음
├── DB 쿼리 날림
├── "응답 오면 알려줘" 등록하고 → 스레드 즉시 반납
│
│   (스레드 1은 이미 다른 요청 처리 중)
│
├── DB 응답 도착 (이벤트 발생)
└── 스레드 꺼내서 결과 처리 → 응답 반환

기다리는 시간에 스레드가 다른 일을 할 수 있다. 같은 스레드 풀로 더 많은 요청을 처리할 수 있게 된다.

Spring에서 비동기 사용법

@Async를 붙이면 호출한 스레드와 별도의 스레드 풀에서 메서드가 실행된다.

@Service
public class SubtitleService {

    @Async
    public CompletableFuture<List<Subtitle>> findSubtitles(Long callId) {
        List<Subtitle> result = subtitleRepository.findByCallId(callId);
        return CompletableFuture.completedFuture(result);
    }
}

단, @EnableAsync를 설정 클래스에 추가해야 하고, Thread Pool 설정도 함께 잡아줘야 제대로 동작한다.

3. 그럼 항상 비동기가 좋은가?

아니다. 비동기가 효과 있는 상황과 없는 상황이 명확하게 갈린다.

효과 있는 경우 - 여러 I/O를 병렬로 날릴 때

두 API 결과가 서로 의존하지 않는다면 동시에 날리면 된다.

// 동기 - 순차 실행 (총 500ms)
User user = userApi.getUser(id);       // 200ms 기다림
Payment pay = paymentApi.getPay(id);   // 300ms 기다림

// 비동기 - 병렬 실행 (총 300ms)
CompletableFuture<User> userFuture = userApi.getUserAsync(id);
CompletableFuture<Payment> payFuture = paymentApi.getPayAsync(id);
CompletableFuture.allOf(userFuture, payFuture).join();

효과 없는 경우 - A 결과로 B를 해야 할 때

순서가 정해진 흐름은 비동기로 바꿔도 결국 기다리는 건 똑같다. 코드만 복잡해진다.

// 어차피 순서가 있으면 동기로 충분
User user = userApi.getUser(id);         // 이 결과로
Payment pay = paymentApi.getPay(user);   // 이걸 해야 함

	동기	비동기
코드 복잡도	단순	복잡
디버깅	쉬움	어려움 (스택 트레이스 추적 힘듦)
효과적인 상황	순차 의존 흐름	독립적인 I/O 병렬 처리
Spring 기본	✓	별도 설정 필요

4. 기다리는 시간이 생기는 I/O 상황들

비동기를 고려해야 하는 건 전부 I/O 대기 상황이다.

I/O 대기 상황
├── DB 쿼리 대기
├── 외부 API 호출 대기  (RestClient, RestTemplate, WebClient)
├── 파일 읽기 / 쓰기 대기
└── 메시지 큐 대기      (Kafka, RabbitMQ 등)

공통점은 CPU가 아니라 네트워크나 디스크에 던져놓고 기다리는 것들이라는 점이다. CPU 입장에선 전부 낭비되는 시간이다.

5. 외부 API 호출 시 반드시 해야 할 것 - 타임아웃

외부 API가 느려지는 날, 타임아웃이 없으면 내 서버 스레드들이 전부 거기서 묶인다. 외부 서비스 장애가 내 서비스 장애로 전파되는 것이다.

RestClient.builder()
    .baseUrl("https://payment-api.com")
    .requestFactory(factory -> {
        factory.setConnectTimeout(Duration.ofSeconds(3));
        factory.setReadTimeout(Duration.ofSeconds(5));
    })
    .build();

비동기 여부와 상관없이, 외부 API 호출엔 타임아웃 설정이 필수다. 이게 없으면 외부 의존성 하나가 전체 서비스를 잡아먹을 수 있다.

6. 판단 기준 정리

외부 API나 DB 호출이 있을 때 이 질문을 먼저 해보자.

이 결과가 나와야 다음 걸 할 수 있나?
├── Yes → 동기로 충분, 타임아웃만 잘 설정
└── No  → 병렬 처리 가능, 비동기 고려

비동기는 무조건 좋은 게 아니다. 병렬로 처리 가능한 I/O가 있을 때 쓰는 것이고, 괜히 전부 비동기로 바꾸면 디버깅이 훨씬 어려워진다.

OS 1편 - 프로세스, 스레드, Thread Pool

isTrue — Tue, 7 Apr 2026 23:26:19 +0900

프로세스 vs 스레드

프로세스는 OS가 프로그램 실행 시 만드는 독립된 단위다. 각자 메모리 공간을 가지고 있어서 서로 침범하지 못한다. java -jar로 Spring 앱을 띄우면 프로세스 1개가 생긴다.

스레드는 프로세스 안에서 실제로 코드를 실행하는 단위다. 같은 프로세스 안의 스레드끼리는 메모리를 공유한다. Tomcat은 HTTP 요청이 들어오면 스레드 1개를 할당해서 처리한다.

컨텍스트 스위칭

CPU는 한 번에 스레드 하나만 실행한다. "동시에 처리"처럼 보이는 건 CPU가 스레드들을 극도로 빠르게 오가기 때문이다. 이 전환 과정 자체가 CPU 자원을 소모한다.

스레드가 많아질수록 전환 비용이 증가해서, 일정 수를 넘으면 오히려 전체 처리 속도가 떨어진다.

Thread Pool

스레드를 매번 만들고 없애는 건 비용이 크다. 그래서 Tomcat은 스레드를 미리 만들어두고 재사용한다.

server:
  tomcat:
    threads:
      max: 200        # 최대 스레드 수
      min-spare: 10   # 최소 대기 스레드
    accept-count: 100 # 대기 큐 크기

요청이 들어오면 풀에서 스레드를 꺼내 쓰고, 처리가 끝나면 반납한다. 풀이 꽉 차면 큐에서 대기하고, 큐도 꽉 차면 에러를 반환한다.

실무 연결 포인트

"배포 후 전체 API가 갑자기 느려졌다" → 원인을 DB에서 찾아라

특정 API의 쿼리가 느려서 스레드를 오래 점유하면, 풀이 소진되면서 다른 멀쩡한 API까지 대기하게 된다.

원인은 DB, 증상은 전체 서비스 지연.

[실무] window.location.href vs API 호출 차이 (SSO 구현하며)

isTrue — Mon, 6 Apr 2026 22:51:12 +0900

1. 문제 상황

SSO 연동을 하면서 이런 고민이 있었다.

로그인 요청을 API로 처리할지
아니면 window.location.href로 리다이렉트할지

처음에는 그냥 API로 처리하려고 했다.

axios.get("/sso/request")

그런데 이 방식으로는 해결이 안 되는 문제가 있었다.

2. 결론 먼저

SSO는 대부분 API 호출로 처리하는 게 아니라
브라우저 리다이렉트(window.location.href)로 처리한다.

window.location.href = "/sso/request";

이게 왜 필요한지 아래에서 정리해본다.

3. API 호출 방식이 안 되는 이유

axios로 요청하면 이런 흐름이다.

JS 코드 → 서버 요청 → 응답(JSON 등)

문제는 SSO는 여기서 끝나는 게 아니라
외부 인증 서버로 이동해야 한다는 점이다.

예를 들어 서버에서 이렇게 응답을 준다고 해도

{
  "redirectUrl": "https://sso-server/login"
}

프론트에서 다시 이동을 해줘야 한다.

window.location.href = response.redirectUrl;

즉, 한 번 더 처리해야 한다.

4. window.location.href 방식

처음부터 브라우저를 이동시키는 방식이다.

window.location.href = "/sso/request";

이렇게 하면 흐름이 단순해진다.

브라우저가 /sso/request 호출
서버에서 SSO 서버로 redirect
인증 완료 후 다시 돌아옴

-> 중간에 JS 개입이 없다

5. 실제로 겪은 문제

이걸 API로 처리하려다가 막혔던 부분이 있었다.

1) 도메인 문제

프록시 환경 (Apache)
여러 도메인 사용

이 상태에서 API 호출하면
사용자가 어떤 도메인으로 들어왔는지 서버가 알기 어려웠다

반면 window.location.href는

브라우저 기준으로 이동하기 때문에
원래 도메인 흐름이 자연스럽게 유지된다

2) 쿠키 / 세션 문제

SSO는 보통 쿠키 기반 인증을 사용한다.

API 호출로 처리하면

쿠키 전달 안 되는 경우 발생
SameSite 정책 영향 받음

반면 리다이렉트 방식은

브라우저가 직접 이동하기 때문에
쿠키 흐름이 정상적으로 유지된다

3) 인증 흐름 깨짐

SSO는 기본적으로

요청
인증 서버 이동
콜백

이 흐름인데

API 호출로 중간에 끼면
흐름이 꼬이는 경우가 있었다.

6. 언제 API 방식 써도 되나

완전히 안 되는 건 아니다.

토큰 기반 인증 (JWT)
SPA 내부 인증 처리

이 경우에는 API 호출로 처리해도 된다.

하지만

외부 SSO (SAML, OAuth redirect 기반)는
거의 무조건 redirect 방식 사용

7. 정리

두 방식 차이는 이거 하나로 정리된다.

API 호출:

JS → 서버 → 응답 처리 필요
흐름 제어를 직접 해야 함

window.location.href:

브라우저가 이동
인증 흐름이 자연스럽게 이어짐

8. 결론

SSO는 “API로 로그인 처리”가 아니라
“브라우저 이동 기반 인증 흐름”이다.

그래서 대부분 구현이

window.location.href = "/sso/request";

이렇게 끝난다.

앞으로의 매력있는 사람

isTrue — Sun, 5 Apr 2026 23:57:26 +0900

https://blog.naver.com/doctordk/224241404491

앞으로 어떤 사람이 매력 있는 사람이 될까?

매일같이 시끄럽게 들리는 전쟁 이야기 말고 오늘은 모처럼 삶에 대해서 이야기를 해보고자 한다. 얼마 전 ...

blog.naver.com

우연히 이런 글을 보았다.

대략적인 내용은 AI가 발전하면서 지식의 평준화가 이루어졌고,

예전에는 어떤 지식을 깊게 알고, 특정 분야의 전문가가 매력있는 사람이었다면 이젠 얕고 넓게 아는 사람

즉, 누군가와 대화 할 때 여러 방면에서 공감해주고 이야기를 이끌 수 있는 사람이 이 매력있는 사람이 아니겠냐는 글이다.

생각해보니 그런 것 같기도 하다.

요즘 누군가와 대화하는 게 점점 힘들어지고, 대화 주제를 만들어 내는게 어려워져서 이런 걸 잘 하는 사람이 부러울 지경까지 됐는데

이렇게 내가햇던 고민을 정리된 글로 보니 내가 느낀게 단순한 이상함은 아니었구나 싶었다.

최근에 뭔가 새로운 경험이 필요한가 라는 생각을 했는데 일맥상통하는 글이다.

보안 전체 구조

isTrue — Thu, 2 Apr 2026 23:08:49 +0900

암호화 — 데이터를 변환해서 숨기는 것. AES(대칭키, 빠름)랑 RSA(비대칭키, 인증/키교환에 씀)가 핵심.

해싱 — 단방향 변환. 복호화 안 됨. 비밀번호 저장에 쓰고, 솔트는 여기에 붙는 보조 개념

키 교환/인증 — SSH나 TLS처럼 "통신 시작 전 신뢰를 수립하는" 과정.

5.2 랜더트리

isTrue — Wed, 1 Apr 2026 23:38:09 +0900

DOM과 CSSOM을 합쳐서 실제로 화면에 그려질 요소만 추려낸 트리다.display: none은 렌더 트리에서 완전히 제외된다.

DOM에는 존재하지만, 렌더 트리에는 아예 노드 자체가 없다. 그래서 공간도 차지하지 않고 레이아웃 계산 대상도 아니다.

프론트엔드에서 실제로 연결되는 포인트:

Vue의 v-if는 display: none처럼 DOM 자체를 제거한다. 렌더 트리에도 없다.

v-show는 display: none 스타일만 토글한다. DOM과 렌더 트리 모두 유지하다가 스타일만 바꾸는 거다.

그래서 자주 토글되는 요소는 v-show, 거의 안 바뀌는 조건부 요소는 v-if가 성능상 낫다. 렌더 트리 재구성 비용 때문이다.

5.1 DOM

isTrue — Wed, 1 Apr 2026 23:34:49 +0900

DOM은 단순히 태그를 나열한 게 아니라 태그(+ 텍스트, 주석 등)를 객체로 만들어서 트리로 연결한 것이에요.

핵심은 "객체" 라는 점이에요. 단순한 문자열 <h1>Hello</h1>이 아니라, JS에서 조작할 수 있는 프로퍼티와 메서드를 가진 객체예요.

<h1 class="title">Hello</h1>

이게 파싱되면 이런 객체가 돼요:

{
  tagName: "H1",
  className: "title",
  textContent: "Hello",
  style: {...},
  parentNode: <body 노드>,
  children: [텍스트 노드],
  addEventListener: function() {...},
  getAttribute: function() {...},
  // ... 수십 가지 메서드
}

그래서 JS에서 이런 게 가능한 거예요:

const el = document.querySelector('h1')

el.textContent = '바뀐 텍스트'   // 프로퍼티 수정
el.style.color = 'red'           // 스타일 변경
el.addEventListener('click', fn) // 이벤트 등록
el.parentNode                    // 부모 노드 접근

HTML은 그냥 텍스트지만, DOM은 브라우저가 그걸 조작 가능한 객체 트리로 바꿔놓은 거예요.

Vue/React가 결국 하는 일도 이 DOM 객체들을 효율적으로 업데이트하는 거고요.

한 줄 요약: DOM = HTML 태그들을 JS로 조작 가능한 객체로 변환한 트리 구조

5. 서버 응답 + 브라우저 렌더링

isTrue — Wed, 1 Apr 2026 23:33:48 +0900

서버가 응답을 보내면 브라우저가 그걸 받아서 화면에 그리는 과정이에요.

이 단계가 사실 가장 프론트엔드와 직접적으로 연결돼요.

먼저 응답 구조부터 보고, 렌더링 파이프라인으로 넘어갈게요.

응답 구조:

상태줄의 숫자가 결과를 요약해줍니다.

200은 성공, 301/302는 다른 URL로 이동, 404는 없는 페이지, 500은 서버 에러

Cache-Control 헤더는 브라우저가 이 응답을 얼마나 캐싱할지 결정해요. 프론트엔드 성능 최적화에서 자주 건드리는 헤더예요.

렌더링 파이프라인:

HTML 파싱 → DOM — 브라우저가 HTML을 위에서 아래로 읽으면서 태그를 트리 구조로 변환해요.

브라우저가 서버에서 HTML을 받으면, 이 문자열을 그대로 쓸 수 없어요. JS로 조작하고 CSS를 입히려면 트리 구조로 변환해야 해요. 이 과정이 파싱이에요.

파싱 5단계:

① 바이트 수신 — 서버에서 HTML이 바이트(0101...)로 날아와요.

② 문자 변환 — Content-Type: charset=UTF-8 같은 인코딩 정보를 보고 바이트를 사람이 읽을 수 있는 문자열로 변환해요.

③ 토큰화 — 문자열을 <html>, </div>, "텍스트" 같은 의미 단위(토큰)로 잘라요. HTML 스펙에 정의된 규칙대로 파서가 문자를 하나씩 읽으면서 분류해요.

④ 노드 생성 — 토큰 하나하나를 객체(노드)로 만들어요. 요소 노드(<h1>), 텍스트 노드("Hello"), 주석 노드() 등 종류가 있어요.

⑤ DOM 트리 완성 — 노드들을 부모-자식 관계로 연결해서 트리를 만들어요. 이게 JS에서 document.querySelector()로 접근하는 그 DOM이에요.

프론트엔드 개발에서 실제로 연결되는 포인트:

script 태그 위치가 성능에 영향을 주는 이유가 바로 ③~④ 단계에서 파싱이 멈추기 때문이에요.

Vue/React 앱에서 번들 스크립트를 <body> 맨 아래나 defer로 넣는 게 이 때문이에요.

innerHTML로 DOM을 바꾸면 해당 부분을 다시 파싱해서 노드를 새로 만들어요.

그래서 루프 안에서 innerHTML 남발하면 느려져요. DocumentFragment나 createElement가 더 효율적인 이유예요.

Vue의 Virtual DOM도 이 실제 DOM 트리를 직접 건드리는 비용을 줄이기 위한 구조예요. 변경사항을 메모리상의 가상 트리에서 먼저 계산하고, 최소한의 실제 DOM 조작만 하는 거예요.

여기서 <script> 태그를 만나면 파싱을 멈추고 JS를 먼저 실행해요. -> 이게 렌더링 블로킹

CSS 파싱 → CSSOM — CSS도 별도로 파싱해서 스타일 트리를 만들어요. CSS가 다 로드되기 전까지는 렌더 트리를 못 만들어요.

렌더 트리 — DOM + CSSOM을 합쳐서 실제로 화면에 보일 요소들만 추려요. display: none 요소는 여기서 제외돼요.

레이아웃 (Reflow) — 각 요소의 정확한 위치와 크기를 계산해요. JS로 DOM을 자주 건드리면 이 단계가 반복 실행되면서 성능이 떨어져요.

페인트 + 합성 — 계산된 레이아웃대로 실제 픽셀을 그려요. GPU를 활용하는 합성(Composite) 단계까지 끝나면 드디어 화면에 보여요.

defer와 async의 차이가 바로 이 렌더링 파이프라인에서 나와요.

defer는 HTML 파싱 완료 후 실행, async는 로드되는 즉시 파싱 중단하고 실행이에요.

Vue.js나 React 번들 스크립트에 defer를 붙이는 이유가 여기 있어요.

전체 흐름 정리

URL 입력
  → DNS로 IP 조회 (캐시 계층적 확인)
  → TCP 3-way handshake (연결 수립)
  → TLS handshake (암호화 채널, HTTPS)
  → HTTP 요청 전송 (메서드 + 헤더 + 바디)
  → 서버 응답 수신 (상태코드 + 헤더 + 바디)
  → 브라우저 렌더링 (DOM → CSSOM → 렌더트리 → 레이아웃 → 페인트)