김신건의 로그

파일 디스크립터부터 소켓까지, 하나로 이어지는 흐름

koa (김신건) — Wed, 15 Jul 2026 00:00:00 GMT

시작 의문

Unix 계열 (Linux, macOS, BSD) 에서 파일도, 소켓도, 파이프도, 심지어 터미널도 같은 함수로 읽는다.

char buf[1024];
read(fd, buf, sizeof(buf));  // 파일이든 소켓이든 이걸로 다 읽힘

fd 자리에 어떤 자원이 오든 동작한다. 처음 보면 좀 신기하다. 파일은 디스크에 있고 소켓은 네트워크를 지나오는 완전히 다른 물건인데 왜 같은 API 가 통할까.

답은 세 계층을 순서대로 이해하면 자연스럽게 풀린다.

파일 디스크립터 (fd), 사용자 공간이 커널 자원을 가리키는 정수 번호표.
저수준 파일 I/O, fd 로 커널에 요청하는 시스템 콜 (open, read, write, close, lseek).
소켓, 네트워크 연결이지만 결국 fd 하나로 감싸져 있어 위의 API 가 그대로 통하는 것.

이 순서로 하나씩 풀어보자.

1. 파일 디스크립터, 정수 하나로 자원을 가리키다

프로세스마다 자기만의 “표” 를 가지고 있다. 파일 디스크립터 테이블 (file descriptor table) 이다.

각 슬롯은 정수 인덱스 (0, 1, 2, 3, …) 이고, 커널이 관리하는 자원 (파일, 소켓, 파이프, …) 을 가리키는 포인터가 들어있다. 사용자 공간에서는 그 정수만 보인다.

프로세스가 시작될 때 3개는 이미 열려 있다.

fd	이름	기본 연결
0	`stdin`	키보드 (또는 리다이렉트된 입력)
1	`stdout`	터미널 (또는 리다이렉트된 출력)
2	`stderr`	터미널 (에러용)

open() 을 호출하면 커널이 가장 작은 빈 슬롯 을 골라 새 fd 를 할당하고 그 번호를 돌려준다. 그래서 첫 open 은 보통 fd 3 을 준다.

{}

애니메이션에서 왼쪽 상자가 프로세스의 fd 테이블, 오른쪽이 커널이 관리하는 자원이다. open 이 호출되면 커널이 File Object 를 만들고 fd 3 슬롯에 그 참조를 꽂아준다. 사용자 코드는 그 정수 3 만 들고 다니면서 read(3, ...) 같은 시스템 콜을 부른다.

왜 그냥 포인터가 아니라 정수인가?

두 가지 이유가 있다.

격리. 사용자 공간이 커널 포인터를 직접 만지면 위험하다. 잘못 건드리면 커널 메모리를 오염시킬 수 있다. 정수 인덱스는 그런 위험 없이 “너의 3번 슬롯” 을 안전하게 가리킨다. 커널은 시스템 콜이 들어올 때마다 fd 를 인덱스로 자기 테이블을 찾아본다.

fork/exec 상속과 리다이렉트. 자식 프로세스는 부모의 fd 테이블을 복사받는다. 슬롯 번호까지 그대로. 이 규칙 덕에 셸의 ls > out.txt 가 우아하게 동작한다.

1. 셸이 fork()
2. 자식이 fd 1 (stdout) 을 close()
3. 자식이 open("out.txt", O_WRONLY|O_CREAT|O_TRUNC)
   → open 이 "가장 작은 빈 슬롯" 규칙으로 fd 1 을 할당
4. 자식이 exec("ls")
   → ls 는 자기가 stdout 에 쓴다고 생각하지만
     실제로는 out.txt 로 나간다

ls 는 자기가 리다이렉트됐다는 걸 전혀 모른다. 파일에 쓴다는 것도, 원래 터미널에 나갈 데이터라는 것도 신경 안 쓴다. 그냥 fd 1 에 write 할 뿐이다. 이 무지 (無知) 가 곧 Unix 파이프라인의 재사용성이다.

fd 는 프로세스 지역이다

fd 3 은 어느 프로세스의 fd 3 이라는 문맥이 있어야 의미가 있다. 프로세스 A 의 fd 3 과 프로세스 B 의 fd 3 은 완전히 다른 자원이다.

커널은 각 프로세스마다 별도의 fd 테이블을 유지한다 (task_struct.files 안의 fdtable). 그래서 /proc/<pid>/fd/ 를 살펴보면 그 프로세스가 무엇을 열고 있는지 다 보인다.

$ ls -l /proc/self/fd
lrwx------ 1 me me 0  0 -> /dev/pts/1
lrwx------ 1 me me 0  1 -> /dev/pts/1
lrwx------ 1 me me 0  2 -> /dev/pts/1
lr-x------ 1 me me 0  3 -> /proc/12345/fd

2. 저수준 파일 I/O, 다섯 개의 시스템 콜

fd 하나만 있으면 파일을 다룰 수 있는 시스템 콜은 사실상 다섯 개다. open, read, write, close, lseek.

open(), fd 얻기

#include <fcntl.h>

int fd = open("/tmp/data.txt", O_RDONLY);
if (fd < 0) {
    perror("open");
    return 1;
}

성공: 새 fd (>= 3 이면 사용자가 연 것)
실패: -1, errno 세팅

플래그로 열기 모드를 지정한다.

플래그	의미
`O_RDONLY`	읽기 전용
`O_WRONLY`	쓰기 전용
`O_RDWR`	읽기/쓰기
`O_CREAT`	없으면 생성 (mode 인자 필요)
`O_APPEND`	쓰기가 항상 파일 끝에
`O_TRUNC`	열면서 파일 내용을 0 으로 잘라냄
`O_NONBLOCK`	논블로킹 모드 (뒤에서 다시 나온다)

O_CREAT 를 쓸 땐 파일 권한을 명시해야 한다.

int fd = open("out.txt", O_WRONLY | O_CREAT | O_TRUNC, 0644);

read(), write(), 실제 IO

char buf[1024];
ssize_t n = read(fd, buf, sizeof(buf));
// n > 0: 읽은 바이트 수
// n == 0: EOF (더 읽을 것 없음)
// n < 0: 에러, errno 확인

ssize_t written = write(fd, "hello\n", 6);

여기서 자주 실수하는 함정 하나. read/write 는 요청한 만큼 다 처리한다는 보장이 없다. 짧게 반환하는 게 오히려 흔하다.

파일: 대부분 요청한 만큼 오지만, 시그널이 끼어들면 짧게 반환할 수 있다.
소켓/파이프: 자주 짧게 반환한다. TCP 는 스트림이라 “여기까지 왔음” 이 임의다.
논블로킹 fd: 지금 당장 처리 가능한 만큼만.

그래서 실무 코드는 loop 를 돌려야 한다.

ssize_t write_all(int fd, const void *buf, size_t len) {
    const char *p = buf;
    size_t remaining = len;
    while (remaining > 0) {
        ssize_t n = write(fd, p, remaining);
        if (n < 0) {
            if (errno == EINTR) continue;  // 시그널이 끼어들면 재시도
            return -1;
        }
        p += n;
        remaining -= n;
    }
    return len;
}

read 도 마찬가지 패턴이 필요하다.

close(), fd 반환

close(fd);

fd 슬롯을 해제한다. 커널 안의 자원 (File Object) 은 참조 카운트가 0 이 되면 함께 해제된다.

close 를 안 부르면 어떻게 될까? fd leak 이다. 프로세스마다 열 수 있는 fd 개수에 상한이 있다 (ulimit -n, 보통 1024 에서 65535 사이). 장시간 도는 서버가 매 요청마다 fd 를 열고 닫지 않으면 결국 open 이 EMFILE (Too many open files) 로 실패하기 시작한다. 파일뿐 아니라 소켓 leak 도 같은 이유로 서버를 죽인다.

lseek(), 파일 커서

파일은 “지금 어디까지 읽었는지” 를 나타내는 커서를 가진다. 커널이 File Object 안에 offset 을 유지한다. read 하면 그만큼 앞으로 나가고, write 하면 그만큼 앞으로 나가면서 덮어쓴다.

lseek(fd, 0, SEEK_SET);   // 처음으로
lseek(fd, 0, SEEK_END);   // 끝으로 (파일 크기 반환값으로 얻음)
lseek(fd, 100, SEEK_CUR); // 현재 위치에서 100 앞으로

[!NOTE] 소켓/파이프에는 커서가 없다. lseek 를 소켓에 호출하면 ESPIPE (Illegal seek) 로 실패한다. 파일이라는 “위치가 있는 자원” 에만 의미가 있는 연산.

stdio (fopen/fread/…) 는 위의 wrapper 다

C 표준 라이브러리의 fopen, fread, fwrite, fclose 는 위 저수준 API 위에 버퍼링 을 얹은 것이다. FILE* 는 실체가 이렇게 생겼다.

FILE {
    int fd;               // 안에 파일 디스크립터가 있음
    char *buffer;         // 사용자 공간 버퍼
    size_t buf_pos;
    int mode;
    ...
}

버퍼 크기만큼 시스템 콜을 모아서 한 번에 처리하므로 매번 write 하는 것보다 빠르다. 필요할 때 fileno(fp) 로 안의 fd 를 꺼낼 수도 있다.

버퍼링의 함정은 flush 를 안 하면 데이터가 아직 커널로 안 갔을 수 있다 는 점. printf 뒤에 크래시가 나면 그 로그가 안 남기도 한다. fflush(stdout) 또는 setvbuf 로 버퍼 정책을 바꿀 수 있다.

3. 소켓, 결국 fd 다

여기서 이 글의 핵심 반전이 나온다. 네트워크 소켓도 결국 fd 하나다.

#include <sys/socket.h>

int sfd = socket(AF_INET, SOCK_STREAM, 0);

socket() 은 새 파일 디스크립터를 반환한다. 커널이 내부적으로 sock 구조체를 만들고, 프로세스 fd 테이블의 빈 슬롯에 그 참조를 꽂는다. 파일 열 때와 완전히 같은 패턴.

인자는 세 개.

AF_INET: 주소 체계 (IPv4). IPv6 는 AF_INET6, 로컬 유닉스 소켓은 AF_UNIX.
SOCK_STREAM: 연결 기반 스트림 (TCP). 데이터그램은 SOCK_DGRAM (UDP).
프로토콜: 대부분 0 (기본값) 이면 알아서.

클라이언트 흐름

int sfd = socket(AF_INET, SOCK_STREAM, 0);

struct sockaddr_in addr = {
    .sin_family = AF_INET,
    .sin_port = htons(8080),
};
inet_pton(AF_INET, "93.184.216.34", &addr.sin_addr);

connect(sfd, (struct sockaddr *)&addr, sizeof(addr));

// 여기서부터 파일이랑 100% 동일한 인터페이스
write(sfd, "GET / HTTP/1.1\r\nHost: example.com\r\n\r\n", 39);

char buf[4096];
ssize_t n = read(sfd, buf, sizeof(buf));

close(sfd);

connect 로 TCP 3-way handshake 가 끝나고 나면 그 뒤엔 그냥 read/write/close. 파일과 다른 API 를 배울 필요가 없다.

send/recv 라는 소켓 전용 함수도 있지만, 인자에 플래그 하나 더 붙는 것 (MSG_DONTWAIT, MSG_NOSIGNAL 등) 말고는 read/write 와 사실상 같은 함수다.

서버 흐름

int listener = socket(AF_INET, SOCK_STREAM, 0);
bind(listener, ...);       // 로컬 주소:포트 잡기
listen(listener, 128);     // 백로그 큐 크기

while (1) {
    int client = accept(listener, NULL, NULL);  // ← 새 fd 하나 반환
    write(client, "HTTP/1.1 200 OK\r\n\r\nhi", 22);
    close(client);
}

accept() 가 새 클라이언트 연결마다 새 fd 를 하나씩 만들어준다. listener fd 는 그대로 두고, 각 클라이언트는 별도의 fd 로 다룬다. 100 클라이언트가 동시에 붙어있으면 fd 가 101 개 열려 있는 상태 (listener 1 + 클라이언트 100).

여기서 아까 얘기한 fd 상한 이 서버의 동시 접속 상한을 결정한다. ulimit -n 65535 같은 튜닝이 필요한 이유.

왜 파일 API 가 소켓에 그대로 통하나?

커널이 fd 뒤의 자원을 다형적 으로 다루기 때문이다. Linux 커널에서는 각 자원 (파일, 소켓, 파이프, …) 이 자기만의 함수 테이블을 갖는다.

// 개념적 스케치 (실제 Linux 커널의 struct file_operations)
struct file_operations {
    ssize_t (*read)(struct file *, char __user *, size_t, loff_t *);
    ssize_t (*write)(struct file *, const char __user *, size_t, loff_t *);
    int (*release)(struct inode *, struct file *);   // close
    ...
};

파일이면 ext4/xfs 의 read 함수, 소켓이면 소켓 서브시스템의 read 함수, 파이프면 파이프의 read 함수가 이 테이블에 꽂혀 있다. 시스템 콜 read(fd, ...) 가 들어오면 커널은:

현재 프로세스의 fd 테이블에서 fd 번호로 struct file * 을 찾는다.
그 file->f_op->read 를 부른다.

사용자 공간에서 봤을 때 인터페이스가 하나 (read) 지만, 커널 내부에서는 자원마다 다른 구현이 호출된다. 객체지향의 다형성 (polymorphism) 이 C 로 구현된 셈. 이게 Unix 의 “Everything is a File” 철학의 실체다.

“모든 게 파일이다” 는 은유가 아니라 “모든 자원을 fd 로 접근한다, 그리고 fd 뒤에는 read/write/close 같은 공통 인터페이스를 구현한 커널 객체가 있다” 는 뜻이다.

4. 통합의 보너스, select / poll / epoll

fd 가 통합돼 있어서 얻는 아주 실용적인 보너스가 하나 있다. 여러 종류의 자원을 한꺼번에 감시할 수 있다는 것.

한 프로세스가 다음 세 개를 동시에 봐야 한다고 하자.

표준 입력에서 사용자 명령이 들어오는지 (fd 0)
파일 하나가 갱신됐는지 (fd 3)
소켓 하나에 응답이 도착했는지 (fd 4)

원래 문제였다면 세 개 감시 API 를 따로 배웠어야 한다. 그런데 셋 다 fd 이므로 하나의 API 로 다룰 수 있다.

#include <poll.h>

struct pollfd fds[3] = {
    { .fd = 0,       .events = POLLIN },  // stdin
    { .fd = file_fd, .events = POLLIN },
    { .fd = sock_fd, .events = POLLIN },
};

int n = poll(fds, 3, -1);  // 셋 중 하나라도 read 준비되면 즉시 리턴

for (int i = 0; i < 3; i++) {
    if (fds[i].revents & POLLIN) {
        char buf[1024];
        read(fds[i].fd, buf, sizeof(buf));  // fd 로 다형 dispatch
        // ... 처리
    }
}

Linux 의 epoll, BSD 의 kqueue, 오래된 select 도 정확히 같은 원리로 fd 를 감시한다. fd 통합이 없었다면 이 API 들이 존재할 수 없다. nginx, Node.js, Nginx event loop, Go 의 netpoller, 전부 이 위에 세워진 구조다.

5. 정리, 한 그림으로

여섯 문장으로 요약한다.

프로세스는 fd 테이블 을 갖는다. 각 슬롯은 정수 인덱스이고, 커널이 관리하는 자원을 가리킨다.
open 은 파일을 열고 가장 작은 빈 fd 를 돌려준다. 0/1/2 는 이미 stdin/stdout/stderr 에 쓰인다.
저수준 파일 I/O (read, write, close, lseek) 는 그 fd 하나로 파일을 다룬다. 언제나 짧은 반환에 대비한 loop 가 필요하다.
socket() 도 새 fd 를 준다. connect 로 연결한 뒤엔 파일과 완전히 같은 read/write/close API 가 통한다.
이게 가능한 이유는 커널이 fd 뒤에 다형적 함수 테이블 (파일이면 ext4 함수, 소켓이면 소켓 함수) 을 두고 시스템 콜을 dispatch 하기 때문이다.
통합의 보너스로 poll/epoll 이 파일, 소켓, 파이프, 터미널을 한 번에 감시할 수 있다.

fopen("data.txt") 한 줄, socket(AF_INET, SOCK_STREAM, 0) 한 줄 뒤에는 이 fd 테이블이 조용히 움직이고 있다. Python 의 open, Go 의 os.File, Node.js 의 fs.createReadStream, Java 의 FileInputStream 도 결국 안에서는 저수준 시스템 콜을 통해 fd 를 열고 그 정수를 감싼 객체를 돌려준다. 언어가 다를 뿐 커널이 보는 그림은 같다.

그러니 다음에 write(1, "hi\n", 3) 를 볼 때, “저 1 이 fd 1, 즉 stdout 이고, 커널의 file 객체를 거쳐 실제 터미널 드라이버로 흘러가는구나” 하고 한 걸음 뒤로 보면 좋겠다. 그 관점 하나가 파일, 네트워크, 파이프, 리다이렉트, 이벤트 루프까지 전부 같은 언어로 설명해준다.

지식 그래프가 너무 빽빽했다: D3 force simulation 재튜닝

koa (김신건) — Thu, 02 Jul 2026 00:00:00 GMT

/graph/ 페이지를 열 때마다 신경이 쓰였다. 노드들이 화면 가운데에 몰려서 라벨이 서로 겹치고, 400개까지 잘라 보여주는데도 “이게 지식 그래프인지 별똥별인지” 같은 상태가 자주 나왔다. 그날 하루를 잡고 원인을 정리하면서 파라미터부터 초기 뷰까지 손봤다. 그 과정을 기록해 둔다.

어떤 상태였나

측정을 시작할 시점의 콘텐츠 규모.

컬렉션	개수
wiki	853
posts	79
notes	10
tags (파생 노드)	상당수

전체 노드는 940개를 넘고, 여기에 태그 노드가 붙는다. /graph/ 페이지는 MAX_GRAPH_NODES = 400 로 잘라서 연결도 상위 400개만 표시한다. 그래도 400개가 560px 세로 캔버스 안에 힘 시뮬레이션으로 배치되니, 라벨이 나란히 뜨면 서로 물리는 게 당연했다.

밀도만 다시 계산해 봐도 답이 나온다.

캔버스 넓이 ~ 1024 × 560 = 573,440 px²
노드당 평균 면적 = 1,433 px²
√ 값 ≈ 38 px

노드 하나가 차지할 정사각형이 대략 38 × 38 픽셀. 원 크기(반경 7 px)만 놓고 보면 여유가 있어 보이지만, 라벨 문자열은 짧게는 60 px, 길면 200 px 을 넘는다. 라벨을 고려하는 순간, 최적 배치라 해도 서로 밀 수밖에 없는 크기다.

진단: 원래 파라미터 뽑아 보기

[[D3|d3-force]] 시뮬레이션의 기존 설정은 다음과 같았다.

d3.forceSimulation<SimNode>(simNodes)
  .alpha(0.6)
  .force('link',
    d3.forceLink<SimNode, SimLink>(simLinks)
      .id((d) => d.id)
      .distance(80)
      .strength(0.4),
  )
  .force('charge',
    d3.forceManyBody<SimNode>()
      .strength((d) => (d.kind === 'tag' ? -260 : -160))
      .distanceMax(400),
  )
  .force('center', d3.forceCenter(width / 2, height / 2).strength(0.05))
  .force('collide',
    d3.forceCollide<SimNode>().radius((d) => (d.kind === 'tag' ? 10 : 28)),
  );

for (let i = 0; i < 30; i++) simulation.tick();

이 상태에서 밀도 문제가 나오는 요인을 하나씩 꼽아 봤다.

linkDistance = 80 이 400개 노드에 비해 짧다. 링크로 연결된 두 노드는 80 px에 안착하려 하고, 링크가 많을수록 서로를 끌어당긴다.
chargeStrength = -160 는 노드 수가 커질수록 상대적으로 약해진다. 반발력을 나눠 갖는 대상이 늘어나기 때문이다.
distanceMax = 400 이 반발 사거리를 제한한다. 400 px 밖의 노드는 서로 밀지 않으니, 큰 그래프에서는 국소 뭉치를 없애기 어렵다.
forceCenter(cx, cy).strength(0.05) 는 이름과 달리 “무게중심을 정확히 (cx, cy) 로 옮기는” 힘이다. chargeStrength 로 벌려 놓은 걸 매 tick 마다 다시 안쪽으로 눌러 담는다.
collideRadius = 28 (문서 노드) 은 원 반경 7 px 대비 넉넉해 보이지만, 라벨 폭을 반영하지 못한다.
preTicks = 30 은 초기 정렬에 부족하다. 시뮬레이션이 자리를 못 잡은 상태로 첫 프레임이 나오면 사용자는 그 첫인상을 기억한다.

이 여섯 개 중, 사실상 모두 대형 그래프에서 밀도를 키우는 방향으로 걸려 있었다.

후보 해법 네 가지

머릿속에서 굴려본 접근이 몇 가지 있었다.

A. 파라미터를 노드 수에 따라 스케일링한다. 50개용과 400개용을 하나의 상수 세트로 맞추기는 어렵다. n 이 커지면 자동으로 linkDistance, charge, collide 를 키우는 함수를 두는 게 자연스럽다.

B. 캔버스를 키운다. height = 560 을 700, 800 로 늘리면 여유는 생긴다. 하지만 그건 문제 자체를 옮길 뿐, 700 개 노드가 들어오면 다시 좁아진다.

C. 노드를 더 잘라낸다. MAX_GRAPH_NODES = 400 을 250 정도로 낮추면 시야가 확 밝아지긴 한다. 대신 그래프의 원래 목적 (연결의 전체 지형을 보여주기)이 훼손된다. 최후 수단으로 남겨 둔다.

D. 초기 뷰포트를 바깥으로 잡는다. 시뮬레이션이 얼추 자리 잡으면, 그때 bounding box 를 잡아서 그 안이 화면에 들어오도록 zoom transform 을 걸어 준다. 사용자는 처음부터 “전체가 다 보이는” 상태로 시작한다.

A 와 D 를 조합하고, 라벨 가시성을 zoom 레벨에 걸어 두는 방향으로 진행했다. B 는 필요할 때 열어 두기로 하고, C 는 손대지 않았다.

파라미터를 함수로 바꾸기

먼저 노드 수에 따라 힘을 재조정할 함수를 추가했다.

function computeForceParams(n: number) {
  const sizeFactor = Math.max(1, Math.sqrt(n / 60));
  return {
    linkDistance:  Math.round(Math.max(80,  60 * sizeFactor)),
    docCharge:    -Math.round(Math.max(200, 220 * sizeFactor)),
    tagCharge:    -Math.round(Math.max(300, 330 * sizeFactor)),
    docCollide:    Math.round(Math.min(50, Math.max(28, 24 * sizeFactor))),
    centerStrength: Math.max(0.03, 0.08 / sizeFactor),
    preTicks:      Math.min(80, 30 + Math.floor(n / 10)),
  };
}

기준을 n = 60 근처로 잡은 이유는, 개인 위키 페이지 하나의 인접 그래프(LocalGraph)가 대략 그 규모이기 때문이다. 그 아래에서는 기존 값과 거의 같게, 그 이상에서는 √(n / 60) 로 완만하게 늘어난다.

몇 가지 노드 수에 대한 결과를 계산해 봤다.

n	linkDistance	docCharge	docCollide	preTicks
50	80	-220	28	35
100	80	-284	31	40
200	110	-402	44	50
400	155	-568	50	70

400 노드 케이스에서 링크가 두 배 가까이 벌어지고 반발력이 3배 넘게 세진다. preTicks 도 두 배로 늘려서 첫 프레임의 안정성을 확보한다.

forceCenter 대신 forceX / forceY

파라미터 다음으로 손댈 곳은 어떻게 가운데로 모을 것인가 다.

forceCenter 는 매 tick 마다 노드들의 무게중심을 정확히 (cx, cy) 로 옮기는 병진 힘이다. 개별 노드가 어디에 있는지와 상관없이 통째로 밀어서 위치를 맞춘다. 겉으로는 “중앙 정렬” 처럼 보이지만, 반발력으로 벌려 놓은 뭉치를 무게중심 기준으로 다시 원위치로 데려온다. 결과적으로 뭉침이 잘 안 풀린다.

forceX(cx).strength(s) + forceY(cy).strength(s) 는 성격이 다르다. 각 노드에 대해 “네 좌표를 (cx, cy) 방향으로 살짝 밀어라” 라고만 얘기한다. 강도가 낮을수록 자유롭게 벌어질 수 있고, 반발력과 정면 충돌하지 않는다.

.force('x', d3.forceX(width / 2).strength(params.centerStrength))
.force('y', d3.forceY(height / 2).strength(params.centerStrength))

centerStrength 도 n 이 커질수록 약해진다 (0.08 / sizeFactor). 큰 그래프일수록 중앙으로 덜 당기고, 자연스럽게 퍼지도록 놓아 준다.

charge 사거리 제한을 풀기

.distanceMax(400) 은 반발력의 사거리를 제한한다. Barnes-Hut 근사가 이미 성능을 잡아 주고 있으니, 이 제한을 굳이 둘 필요가 없다. 제거하니 서로 반대편에 있는 뭉치도 아주 약하게나마 서로를 인식하고, 두 뭉치가 겹쳐 뜨는 현상이 줄었다.

.theta(0.9) 로 근사 강도만 명시해 뒀다. 기본값과 같지만 향후 튜닝 지점을 눈에 띄게 해 둔다.

forceCollide 는 strength(0.9) + iterations(2) 로 조금 세게 밀었다. 라벨을 완전히 겹치지 않게 만드는 건 어렵지만, 원 자체는 겹치지 않도록.

초기 layout 을 넓게 뿌리기

seedInitialLayout 은 원래 반지름 0.4 × min(width, height) 안에 골든 스파이럴로 노드를 뿌려 준다. 여기에 밀도 스케일을 추가했다.

const densityScale = Math.max(1, Math.sqrt(n / 80));
const maxRadius = Math.min(width, height) * 0.45 * densityScale;

n = 400 이면 densityScale ≈ 2.24, 즉 초기 뿌림 반지름이 두 배 이상 넓어진다. 노드가 처음부터 화면 바깥까지 나가는 게 오히려 좋다. 시뮬레이션이 안쪽으로 압축하기보다 바깥에서 안쪽으로 정리하는 방향으로 작동한다.

Zoom-to-fit: 첫 프레임을 “다 보이는” 상태로

파라미터를 아무리 튜닝해도, 초기 뷰포트가 노드 구름의 일부만 잡고 있으면 사용자는 여전히 “복잡하다” 고 느낀다. 그래서 preTicks 로 안정화한 뒤 bounding box 를 잡아 초기 zoom transform 을 계산해서 넣어 줬다.

if (simNodes.length > 20) {
  // 노드 좌표의 min/max 로 bbox 계산
  let minX = Infinity, maxX = -Infinity, minY = Infinity, maxY = -Infinity;
  for (const node of simNodes) {
    const x = node.x ?? 0;
    const y = node.y ?? 0;
    if (x < minX) minX = x;
    if (x > maxX) maxX = x;
    if (y < minY) minY = y;
    if (y > maxY) maxY = y;
  }
  const bboxW = maxX - minX;
  const bboxH = maxY - minY;
  if (bboxW > 0 && bboxH > 0) {
    const labelOverhang = 160;
    const padding = 32;
    const kx = (width - padding * 2) / (bboxW + labelOverhang);
    const ky = (height - padding * 2) / bboxH;
    const k = Math.max(0.25, Math.min(1, kx, ky));
    if (k < 1) {
      const centerX = (minX + maxX) / 2;
      const centerY = (minY + maxY) / 2;
      const tx = width / 2 - centerX * k;
      const ty = height / 2 - centerY * k;
      const initialTransform = d3.zoomIdentity.translate(tx, ty).scale(k);
      svg.call(zoom.transform, initialTransform);
    }
  }
}

labelOverhang = 160 은 문서 노드 라벨이 노드 중심에서 오른쪽으로 얼마나 뻗는지를 반영한 값이다. 최대 라벨 길이를 재서 나온 실측 근사치.
최소 스케일을 0.25 로 잡아서 아주 큰 그래프에서도 완전히 짓눌리진 않게 했다. scaleExtent 하한도 0.3 → 0.2 로 살짝 넓혀 뒀다.
if (k < 1) 로 감쌌기 때문에 작은 그래프 (LocalGraph 처럼 20 개 이하) 에서는 zoom 이 걸리지 않고 자연 크기로 뜬다.

라벨은 zoom 이 낮으면 숨긴다

zoom 이 낮은 상태에서 400개 라벨이 다 떠 있으면 여전히 어지럽다. 그래서 라벨 가시성을 스케일에 걸어 두었다.

const LABEL_ZOOM_THRESHOLD = 0.55;

const zoom = d3.zoom<SVGSVGElement, unknown>()
  .scaleExtent([0.2, 4])
  .on('zoom', (event) => {
    root.attr('transform', event.transform.toString());
    const showLabels = event.transform.k >= LABEL_ZOOM_THRESHOLD;
    root
      .selectAll<SVGTextElement, SimNode>('.graph-nodes text')
      .style('display', showLabels ? '' : 'none');
  });

0.55 미만이면 라벨을 감춰서 구조 (원, 색, 링크) 만 보이게 한다. 사용자가 궁금한 영역으로 zoom-in 하면 라벨이 자연스럽게 나타난다. 초기 zoom-to-fit 이 이 임계값 밑이라면 곧바로 라벨 없는 상태로 시작하므로, 첫인상이 훨씬 깨끗해진다.

이 방식의 좋은 점은 코드 한 조각으로 두 가지를 동시에 잡는다는 것이다.

대형 그래프의 초기 뷰: 라벨 없이 지형만
사용자의 zoom-in: 관심 영역만 라벨 노출

전역 상태를 따로 두지 않고 zoom 이벤트 하나로 처리했다.

3D 뷰도 살짝

3D Graph3D 는 Fibonacci sphere 로 초기 위치를 잡는다. 반지름 스케일이 Math.max(80, 14 × ∛n) 이었는데, 400개면 반지름 103. 3D 인 만큼 부피 배분이 유리하지만 그래도 좁았다. 계수를 올려서 Math.max(120, 22 × ∛n) 로 바꿨고, 400개에서 반지름은 162 정도가 된다. 3D 는 원래 시각적으로 여유가 있어서 이 정도만으로 눈에 띄게 깔끔해졌다.

되돌아보기

이 튜닝은 전형적인 “d3 힘 시뮬레이션은 마법이 아니다” 이야기다. 잘 안 되면 원인은 대부분 몇 가지로 좁혀진다.

링크 거리와 반발력이 노드 수에 비해 작다.
중앙 정렬 힘이 반발력과 정면으로 싸운다.
초기 뷰포트가 노드 구름 대비 좁다.
라벨을 다 보여 주려고 하다가 시각 정보가 오히려 사라진다.

n 기반 스케일링 + forceX/forceY + zoom-to-fit + zoom 게이팅. 이 네 가지는 개인 지식 그래프 스케일에서는 거의 항상 통하는 조합이었다. 다음에 또 비슷한 문제를 만나면 아마 같은 순서로 열게 될 것 같다.

남은 아이디어는 두 가지.

연결도 기반 라벨 필터: 저 zoom 상태에서도 “허브 노드” 라벨은 남겨서 지형 파악을 돕는다.
커뮤니티 감지 후 클러스터 색상: 카테고리가 아니라 실제 연결 구조에 따라 뭉치별로 색을 부여.

둘 다 재미있지만 이번 문제의 표층은 대체로 해결됐으니, 그 두 개는 다음 반복으로 넘긴다.

Rails 에서의 Read/Write Database 분리

koa (김신건) — Mon, 29 Jun 2026 00:00:00 GMT

시작 의문

서비스 트래픽이 늘어나면 가장 먼저 부담을 느끼는 곳은 데이터베이스입니다. 특히 읽기 쿼리가 무거운 서비스라면, 단일 인스턴스로 모든 부하를 감당하는 것이 점점 어려워집니다. 이때 자연스럽게 떠오르는 대안은 읽기와 쓰기를 다른 인스턴스로 분리하는 것입니다.

Rails 는 6.0 부터 이 패턴을 공식 기능으로 지원합니다. 기본 정책은 단순합니다.

GET / HEAD 요청은 reading role 로 라우팅 → replica 에 SELECT 가 발행됩니다.
POST / PATCH / PUT / DELETE 요청은 writing role 로 라우팅 → primary 에 INSERT/UPDATE/DELETE 가 발행됩니다.

직관적입니다. 하지만 실제 서비스를 운영하다 보면 곧 다음과 같은 질문에 부딪힙니다.

GET 요청인데 데이터를 써야 한다면? 예를 들어 조회수 카운터를 올리거나, OAuth 콜백을 GET 으로 받아 토큰을 저장해야 한다면 어떻게 해야 할까요?
POST 직후의 GET 은 replica 에서 stale 한 데이터를 읽지 않을까요? Replication lag 때문에 방금 만든 레코드가 안 보이는 경우는?
force_write { ... } 같은 블록을 코드 곳곳에 흩뿌리지 않고 깔끔하게 추상화할 방법은 없을까요?

한 줄로 답하면 “DatabaseSelector 미들웨어 + ForceWrite concern” 조합으로 풀립니다. 다만 왜 그 조합이 되는지를 이해하려면 한 단계 더 들어가야 합니다. 이 글에서는 읽기 부하 분산이 가능한 이유, HTTP 메서드 기반 자동 라우팅의 동작, GET 안에서 쓰기가 필요한 케이스의 패턴화, 그리고 실전에서 마주치는 함정들을 차례로 풀어 보겠습니다.

먼저 가장 기초적인 곳부터 시작하겠습니다.

한 단계 뒤로, 왜 읽기와 쓰기를 분리하는가

Primary-Replica 복제 구조

DB 를 분리한다는 말은 보통 다음 구조를 의미합니다.

{}

Primary: 쓰기(INSERT/UPDATE/DELETE) 와 읽기 모두 가능한 메인 인스턴스입니다.
Replica: primary 의 변경 사항을 비동기적으로 받아 동기화하는 읽기 전용 복제본입니다. PostgreSQL 이라면 WAL streaming, MySQL 이라면 binlog replication 으로 동작합니다.

App 서버는 쓰기 트래픽을 primary 에 보내고, 읽기 트래픽을 replica 에 분산합니다. Replica 는 여러 개 둘 수 있어 수평 확장이 가능합니다.

분리해서 얻는 것

읽기 부하 분산: 리포트 / 검색 / 통계처럼 무거운 SELECT 를 replica 로 보내면 primary 부하가 줄어듭니다.
장애 격리: replica 가 죽어도 쓰기는 살아 있고, primary 가 죽어도 읽기는 살아 있어 부분적으로 서비스를 유지할 수 있습니다.
장기 트랜잭션 격리: 분석성 쿼리가 primary 의 락을 잡지 않으므로 OLTP 성능이 안정됩니다.

분리해서 잃는 것

공짜는 아닙니다.

Replication lag: primary 에서 쓰기가 완료된 직후 replica 에는 아직 그 변경이 반영되지 않은 상태가 있습니다. 보통 수십 ms 에서 길게는 수 초까지 갈 수 있습니다. 이 동안 같은 데이터를 replica 에서 읽으면 stale read 가 발생합니다.
일관성 모델 복잡화: 트랜잭션이 두 연결에 걸치면 일관성을 보장하기 어렵습니다.
운영 복잡도: replica 의 lag 모니터링, failover, 백업 등 운영 부담이 늘어납니다.

이 글의 후반부에서 보겠지만, Rails 의 DatabaseSelector 는 stale read 문제를 부분적으로 해결합니다. 다만 완전히 해결하지는 않으니 트레이드오프를 기억해 두는 것이 좋습니다.

Rails 설정, `database.yml` 과 `connects_to`

두 connection 정의

config/database.yml 에 primary 와 replica 두 connection 을 정의합니다.

production:
  primary:
    database: my_app_production
    adapter: postgresql
    host: <%= ENV["DB_PRIMARY_HOST"] %>
    username: <%= ENV["DB_USER"] %>
    password: <%= ENV["DB_PASSWORD"] %>
  primary_replica:
    database: my_app_production
    adapter: postgresql
    host: <%= ENV["DB_REPLICA_HOST"] %>
    username: <%= ENV["DB_USER"] %>
    password: <%= ENV["DB_PASSWORD"] %>
    replica: true

replica: true 옵션은 마이그레이션 대상에서 이 connection 을 제외하라는 표시입니다. Replica 는 primary 의 복제본이므로 별도로 스키마를 변경하면 안 됩니다.

모델에서 role 매핑

ApplicationRecord 에서 두 connection 을 role 에 묶어 줍니다.

# app/models/application_record.rb
class ApplicationRecord < ActiveRecord::Base
  primary_abstract_class

  connects_to database: {
    writing: :primary,
    reading: :primary_replica
  }
end

여기서 두 가지가 중요합니다.

primary_abstract_class: 모든 모델이 이 추상 클래스를 통해 connection 을 공유하도록 만듭니다. 이게 없으면 모델마다 connection 풀이 따로 잡혀 메모리를 낭비합니다.
connects_to database: { ... }: writing 과 reading 이라는 role 이름에 실제 connection 을 매핑합니다. 이 이름은 자유롭게 정할 수 있지만 writing / reading 이 관례입니다.

이제 모델 입장에서는 “지금 어느 role 인가” 에 따라 어느 connection 으로 쿼리가 발행될지가 결정됩니다.

자동 라우팅, `DatabaseSelector` 미들웨어

미들웨어 활성화

config/environments/production.rb 에 다음을 추가합니다.

config.active_record.database_selector = { delay: 2.seconds }
config.active_record.database_resolver = ActiveRecord::Middleware::DatabaseSelector::Resolver
config.active_record.database_resolver_context = ActiveRecord::Middleware::DatabaseSelector::Resolver::Session

이 세 줄이 DatabaseSelector 미들웨어를 Rack 스택에 끼워 넣습니다. 모든 요청은 이 미들웨어를 거치면서 role 이 결정된 다음 컨트롤러로 전달됩니다.

동작 방식

{}

미들웨어가 보는 것은 두 가지입니다.

HTTP 메서드: GET 또는 HEAD 면 reading role, 그 외면 writing role.
세션의 마지막 쓰기 시각: 같은 세션에서 최근에 쓰기가 있었다면, delay 윈도우 안의 모든 GET 도 writing role 로 강제됩니다.

두 번째가 핵심입니다. 사용자가 게시글을 작성한 직후 (POST), 페이지를 새로고침해서 자기 글을 확인하면 (GET) replica 의 lag 때문에 게시글이 안 보일 수 있습니다. delay: 2.seconds 는 “쓰기 후 2 초 동안은 같은 세션의 GET 도 primary 로 보내라” 는 뜻입니다. Replica lag 가 1 초 이내라면 이 윈도우 안에서 stale read 가 거의 사라집니다.

[!NOTE] delay 는 세션 단위 입니다. 다른 사용자의 GET 은 영향을 받지 않습니다. 즉, 자기가 방금 쓴 글은 자기에게 즉시 보이지만, 다른 사용자에게는 lag 만큼 지연되어 보일 수 있습니다. 이 정도면 대부분의 서비스에서 받아들일 만한 일관성 수준입니다.

미들웨어가 컨트롤러 액션 전체를 감싼다

여기서 미묘한 함정이 하나 있습니다. DatabaseSelector 는 컨트롤러 액션이 시작되기 전 에 role 을 결정 합니다. 그리고 액션이 끝날 때까지 그 role 을 유지합니다. 즉, GET 요청으로 들어온 액션 내부에서는 모든 쿼리가 reading role 로 가게 됩니다.

문제는 GET 요청이라고 해서 항상 읽기만 하는 것이 아니라는 점입니다.

문제: GET 인데 쓰기가 필요한 경우

자동 라우팅의 한계가 드러나는 케이스들입니다.

케이스	예시
조회수 / 카운터 증가	`GET /posts/:id` 에서 `post.increment!(:view_count)`
Lazy migration	첫 GET 때 누락된 메타 데이터를 채워 넣기
검색 로그 기록	`GET /search?q=...` 에서 검색 기록 INSERT
OAuth / Webhook 콜백	외부 서비스가 `GET` 으로 콜백, 내부에서 토큰 저장
마지막 접근 시각 갱신	`GET /me` 에서 `current_user.touch(:last_seen_at)`

이런 액션 내부에서 그냥 post.increment!(:view_count) 를 호출하면 어떻게 될까요? Reading role 의 connection 은 replica 를 가리키고 있고, 대부분의 replica 는 read-only 로 설정되어 있습니다. 결과는 다음과 같습니다.

class PostsController < ApplicationController
  def show
    @post = Post.find(params[:id])
    @post.increment!(:view_count)
    # => ActiveRecord::ReadOnlyError:
    #    Write query attempted while in readonly mode
  end
end

명시적으로 예외가 발생합니다. 친절하지만 막막합니다. “그러면 이 액션 전체를 POST 로 바꿔야 하나?” 라고 묻고 싶지만, REST 의 관점에서 조회 는 GET 이 맞고 카운터는 사이드이펙트일 뿐입니다. 그렇다고 컨트롤러 전체를 writing role 로 묶어 버리면 읽기 부하 분산 효과가 사라집니다.

필요한 것은 쓰기가 발생하는 그 블록만 writing role 로 일시 승격 시키는 방법입니다.

`connected_to` 로 role 수동 전환

ActiveRecord 는 connected_to 라는 메서드를 통해 role 을 수동으로 전환할 수 있게 해 줍니다.

ActiveRecord::Base.connected_to(role: :writing) do
  @post.increment!(:view_count)
end

블록 안에서 발행되는 모든 쿼리는 writing role 의 connection 을 사용합니다. 블록이 끝나면 원래 role 로 돌아갑니다. 이게 핵심 메커니즘입니다.

다만 매번 ActiveRecord::Base.connected_to(role: :writing) do ... end 를 적는 것은 길고 노출이 잦아집니다. 컨트롤러 곳곳에 흩어져 있으면 의도가 잘 안 보이기도 합니다. 이걸 한 줄로 줄이는 것이 다음 단계입니다.

ForceWrite Concern

Rails 의 관용구를 따라 [[rails-concerns|concern]] 으로 추출합니다.

# app/controllers/concerns/force_write.rb
module ForceWrite
  extend ActiveSupport::Concern

  def force_write(&block)
    ActiveRecord::Base.connected_to(role: :writing, &block)
  end
end

ApplicationController 에 include 하면 모든 컨트롤러에서 force_write 메서드를 쓸 수 있습니다.

# app/controllers/application_controller.rb
class ApplicationController < ActionController::Base
  include ForceWrite
end

블록 안에서 일어나는 일

{}

GET 요청이 들어오면 처음에는 reading role 입니다. Post.find(1) 같은 SELECT 는 replica 로 갑니다. force_write do ... end 블록 안으로 들어가는 순간 role 이 writing 으로 승격되면서, 그 안의 모든 쿼리는 primary 로 발행됩니다. 블록이 끝나면 다시 reading role 로 복귀합니다.

타임라인으로 보면 한 GET 요청 안에서 role 이 reading → writing → reading 으로 두 번 전환됩니다. 이 전환 자체에는 거의 비용이 없습니다. ActiveRecord 의 connection handler 가 thread-local 변수로 현재 role 을 추적할 뿐입니다.

실전 패턴

세 가지 대표적인 사용 예시를 보겠습니다.

예시 1: 조회수 증가

class PostsController < ApplicationController
  def show
    @post = Post.find(params[:id])    # replica 에서 SELECT

    force_write do
      @post.increment!(:view_count)   # primary 에 UPDATE
    end

    # render 는 그 다음, delay 윈도우 안이라면 primary 유지
  end
end

가장 흔한 케이스입니다. 조회수가 정확히 +1 일 필요는 없으니 카운터 손실에 관대해도 되고, 매 GET 마다 UPDATE 하는 비용이 부담이라면 [[Redis|Redis]] 의 INCR 로 버퍼링한 다음 주기적으로 flush 하는 패턴도 자주 씁니다. 다만 그 flush 도 결국 writing role 에서 일어나야 합니다.

예시 2: 검색 로그 기록

class SearchController < ApplicationController
  def index
    @results = Post.search(params[:q])    # replica

    force_write do
      SearchLog.create!(query: params[:q], user: current_user)
    end
  end
end

검색 자체는 replica 에서 수행하지만, 검색 기록은 primary 에 남깁니다. 검색 기록을 잃어도 비즈니스에 큰 영향이 없으면 이 기록도 비동기 job 으로 보내는 것이 더 낫습니다.

예시 3: OAuth 콜백

class CallbacksController < ApplicationController
  # OAuth provider 가 GET 으로 redirect 보내는 경우
  def oauth
    token = exchange_code(params[:code])

    force_write do
      current_user.update!(oauth_token: token)
    end

    redirect_to root_path
  end
end

외부 OAuth provider 가 GET 으로 콜백을 보내는 경우입니다. 우리 도메인에서는 분명히 쓰기 동작이지만 HTTP 메서드로는 GET 으로 들어옵니다. 이런 케이스는 force_write 로 명시적으로 감싸는 것이 자연스럽습니다.

모델 / 서비스 객체에서도 쓰기

컨트롤러를 거치지 않는 코드 (콜백, ActiveJob, Service Object 등) 에서도 같은 패턴이 필요합니다. 모델용 concern 도 같은 방식으로 만들 수 있습니다.

# app/models/concerns/force_write.rb
module ForceWrite
  extend ActiveSupport::Concern

  module ClassMethods
    def force_write(&block)
      ActiveRecord::Base.connected_to(role: :writing, &block)
    end
  end

  def force_write(&block)
    self.class.force_write(&block)
  end
end

class Post < ApplicationRecord
  include ForceWrite

  def record_view
    force_write { increment!(:view_count) }
  end
end

함정과 주의사항

1. 블록 안의 모든 쿼리가 writing 으로 갑니다

force_write do
  log_view(post)               # SearchLog INSERT (의도)
  post.related_posts.to_a      # 이것도 primary 로 감 (의도 아닐 수 있음)
end

force_write 블록 안에서는 SELECT 까지 모두 primary 로 갑니다. 블록의 범위를 최소한의 쓰기 한두 줄 로 좁혀 두는 것이 안전합니다.

2. 트랜잭션 경계와 role 은 별개입니다

# 위험한 패턴
ActiveRecord::Base.transaction do
  force_write do
    user.save!
  end
end

트랜잭션은 열린 시점 의 connection 에 묶입니다. Reading role 로 transaction 을 연 다음 안에서 writing role 로 전환하면 트랜잭션이 두 connection 에 걸쳐 일관성이 깨질 수 있습니다.

# 올바른 순서
force_write do
  ApplicationRecord.transaction do
    user.save!
    post.save!
  end
end

force_write 가 항상 트랜잭션을 감싸는 바깥 에 있어야 합니다.

3. GET 의 멱등성

HTTP/1.1 명세상 GET 은 멱등 (idempotent) 이어야 합니다. 즉 같은 GET 을 여러 번 보내도 서버 상태가 같은 결과로 수렴해야 합니다. force_write 로 사이드이펙트를 만드는 순간 이 약속이 깨집니다. 브라우저 prefetch, 검색 엔진 크롤러, retry 로직이 의도치 않게 카운터를 여러 번 증가시킬 수 있습니다.

이런 경우에는 다음 중 하나를 고려하는 것이 좋습니다.

세션 / IP 단위 dedup: 같은 사용자가 짧은 시간 안에 여러 번 GET 해도 한 번만 카운트.
HyperLogLog 같은 근사 자료구조: 정확한 카운트가 아니어도 되는 케이스.
비동기 job 으로 분리: GET 응답에서는 큐에 넣고 워커가 실제 쓰기 수행.

4. Delay 윈도우 안의 후속 GET

delay: 2.seconds 를 잡았다면, 쓰기 직후 2 초 안에 들어온 같은 세션의 GET 은 모두 primary 로 갑니다. 이 GET 의 컨트롤러 액션 안에서 SELECT 가 100 개 발행되면 그 100 개도 primary 에 부담을 줍니다.

Delay 는 replica lag 의 상한보다 살짝 크게 잡는 것이 좋습니다. Lag 이 보통 200ms 라면 1초, 가끔 1초까지 튀면 2~3초 정도가 적절합니다. 무작정 크게 잡으면 분리 효과가 약해집니다.

5. 미들웨어 우선순위

DatabaseSelector 는 Rack 미들웨어 스택의 특정 위치에 끼워집니다. 다른 커스텀 미들웨어를 추가할 때 순서가 꼬이면 role 이 결정되기 전에 컨트롤러 코드가 실행될 수 있습니다.

rails middleware

명령으로 현재 스택을 출력해서 ActiveRecord::Middleware::DatabaseSelector 의 위치를 확인하는 것이 좋습니다.

6. 테스트 환경에서의 분기

테스트 환경에서는 보통 single DB 로 돌리므로 connects_to 를 환경별로 분기하는 것이 편합니다.

class ApplicationRecord < ActiveRecord::Base
  primary_abstract_class

  if Rails.env.production? || Rails.env.staging?
    connects_to database: { writing: :primary, reading: :primary_replica }
  end
end

또는 테스트 환경의 database.yml 에 replica 를 정의하지 않으면 reading role 도 primary 로 fallback 하므로 그대로 두는 방법도 있습니다.

자동 라우팅 vs 수동 전환, 언제 무엇을 쓸까요

지금까지 본 도구들을 정리하면 다음 표가 됩니다.

기준	자동 (`DatabaseSelector`)	수동 (`connected_to` / `force_write`)
HTTP 메서드가 의도와 일치	적합합니다	불필요합니다
GET 에서 쓰기 일부	자동 + `force_write` 보조	모든 쓰기 직접 감싸야 합니다
컨트롤러 외부 (Job, Service)	동작하지 않습니다	필수입니다
모든 요청을 writing 으로 고정	미들웨어를 제거합니다	항상 `connected_to(:writing)` 으로 감쌉니다

대부분의 Rails 앱은 자동 라우팅 + 예외 케이스만 force_write 조합이 균형점입니다. 자동 라우팅이 80% 이상의 케이스를 처리하고, 나머지 사이드이펙트 케이스만 명시적으로 표시하는 식입니다.

마무리

읽기와 쓰기를 분리한다는 결정은 단순히 “replica 를 띄우면 끝” 이 아닙니다. 다음 세 가지가 함께 와야 합니다.

인프라 레벨: primary-replica 복제 구성, replication lag 모니터링, failover 자동화.
앱 레벨: connects_to 로 role 매핑, DatabaseSelector 미들웨어 활성화, delay 윈도우 설정.
코드 레벨: GET 의 사이드이펙트를 force_write 같은 concern 으로 명시적으로 표시.

세 번째가 흔히 빠뜨리는 부분입니다. 미들웨어만 켜 두고 코드는 그대로 두면, 어딘가에서 ActiveRecord::ReadOnlyError 가 터지거나 카운터가 안 올라가는 미묘한 버그로 이어집니다. GET 안의 쓰기를 의도적으로 만든다면, 그 의도를 코드에 남기는 것이 결국 가장 중요합니다.

추가로 깊이 들어가고 싶다면 다음을 참고하시면 좋습니다.

공식 가이드: Multiple Databases with Active Record
미들웨어 API: ActiveRecord::Middleware::DatabaseSelector
관련 [[rails-activerecord-basics|Rails ActiveRecord 기초]]
관련 [[rails-concerns|Rails Concerns]]
관련 [[redis|Redis]] (카운터 버퍼링용)

글 쓰는 즐거움을 위해 직접 만든 세 개의 도구: 에디터, 스튜디오, 차트 에디터

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

왜 도구부터 만들었나

이 블로그를 시작할 때, 머릿속에 가장 먼저 떠오른 건 “어떻게 글을 쓸까” 가 아니라 “어떻게 보여줄까” 였다. 시각화 자료, 다이어그램, 다양한 형태의 소개 자료를 한곳에 모으는 공간이 갖고 싶었고, 그러려면 단순히 마크다운만 잘 렌더링하는 정적 사이트로는 부족했다.

그래서 두 가지 방향으로 도구를 키워나갔다.

글 쓰는 과정 자체를 쉽게 만들기, 매번 VSCode 를 열고 frontmatter 를 손으로 채우고 이미지 경로를 신경 쓰는 건 곧 피로가 된다. 글이 잘 써지지 않는 가장 큰 이유는 영감 부족이 아니라 마찰이다.
시각화·애니메이션·차트를 일급 시민으로, 그래야 같은 주제도 더 직관적으로 설명할 수 있고, 위키 페이지를 점진적으로 키워나가는 흐름과도 맞다. 위키는 내가 모르는 분야라도 AI 의 도움으로 작은 조각을 모으고, 시각 자료를 곁들여 키워가고 싶었다.

그 결과 [[Astro]] 기반 블로그 안에 세 가지 개발 모드 전용 도구 가 자라났다.

도구	라우트	역할
콘텐츠 에디터	`/_editor`	마크다운 작성, 미리보기, 자산 관리, Git
애니메이션 스튜디오	`/_studio`	SVG 기반 인터랙티브 애니메이션 제작
차트 에디터	`/_chart-editor`	Chart.js 차트 시각 편집 + MDX 코드 추출

[!NOTE] 세 도구 모두 bun dev 로컬 개발 환경에서만 동작한다. Astro 플러그인이 command === 'dev' 일 때만 라우트를 주입하므로 프로덕션 빌드에는 단 한 줄도 섞이지 않는다.

세 도구 모두 같은 모토를 공유한다, “도구가 글의 모양을 결정한다”. 좋은 도구는 새로운 형태의 글을 쓰게 만든다.

1. 콘텐츠 에디터 (`/_editor`)

가장 자주 쓰는 도구. 글, 위키, 노트, 출처 자료를 모두 여기서 작성한다.

화면을 펼치면 세 칸이다. 왼쪽은 컬렉션별 파일 트리, 가운데는 마크다운 작성 영역과 툴바, 오른쪽은 분할 미리보기. 글이 자라는 모양을 실시간으로 보면서 쓸 수 있다.

1.1 파일 트리, 단순한 탐색기가 아니다

좌측 사이드바는 posts, wiki, notes, sources 네 컬렉션을 그대로 보여준다. 폴더는 펼치고 접을 수 있고, 그 상태는 localStorage 에 저장돼서 다음번 페이지를 열어도 유지된다.

검색 입력 : 파일 이름으로 즉시 필터, ESC 로 초기화
우클릭 메뉴 : 새 파일, 새 폴더, 이름 변경, 삭제, 이동
드래그-드롭 이동 : 폴더 사이로 파일을 끌어서 옮길 수 있다
세션 복원 : 마지막으로 열었던 파일을 자동으로 다시 열고, 커서/스크롤 위치까지 복원

1.2 마크다운 툴바, 37개 버튼의 의미

툴바는 “마크다운 문법을 외우지 않아도 글을 쓸 수 있게” 가 목표였다. 그래서 자주 쓰는 모든 형태를 버튼으로 빼놓았다.

그룹	버튼
텍스트 포맷	굵게 (⌘B), 기울임 (⌘I), 취소선, 인라인 코드
링크·미디어	링크 (⌘K), 이미지, URL 미리보기, URL ↔ 카드 토글
헤딩	H1, H2, H3
리스트·인용	목록, 번호 목록, 할 일, 인용
코드·표	코드 블록, 표, 구분선
콜아웃 ▾	Note, Tip, Important, Warning, Caution
CodeWithOutput ▾	단일 언어, 멀티 언어 (variants)
Mermaid ▾	Flowchart, Sequence, State, Class, ER Diagram
🎬 Animation ▾	스튜디오에서 만든 애니메이션 검색·삽입
Frontmatter ▾	커버·썸네일·시리즈·카테고리·태그·출처 관리
위키링크	이중 대괄호 문법의 위키 페이지 링크 삽입

콜아웃 드롭다운을 열면 GitHub 스타일 5종이 한눈에 들어온다.

Mermaid 드롭다운도 마찬가지다. Flowchart 부터 ER Diagram 까지 자주 쓰는 다섯 가지가 템플릿으로 들어있다.

Frontmatter 드롭다운은 글 메타데이터를 본문 위로 끌어오지 않고 바로 편집할 수 있게 해준다. 커버 이미지, 썸네일, 시리즈, 카테고리, 태그, 출처를 하나의 메뉴에서 다룬다.

1.3 이미지 다이얼로그, 모든 경로를 한 곳에서

이미지 버튼을 누르면 다음 옵션을 한 화면에서 정리한다.

용도 : 본문 삽입 / 커버 이미지 / 썸네일
이미지 소스 : 파일 업로드 (or 클립보드 붙여넣기) / 외부 URL 다운로드 저장 / 외부 URL 그대로 사용
대체 텍스트 : a11y/SEO 를 위해 필수
너비 : 원본·25%·50%·75%·100% 또는 직접 입력
정렬 : 기본 (인라인) / 왼쪽 / 가운데 / 오른쪽

업로드한 파일은 public/uploads/ 에 타임스탬프 + 랜덤 슬러그로 저장되고, frontmatter 의 커버를 고르면 자동으로 cover / coverAlt 가 채워진다.

1.4 Git 패널, 에디터를 떠나지 않는다

상단 ”🌿 Git” 버튼을 누르면 변경 사항을 그대로 다룰 수 있다. 브랜치를 갈아끼우거나 stash 를 관리하는 일까지 모두 같은 화면에서 끝낸다.

지원하는 작업은 아래와 같다.

현재 브랜치 표시, 앞/뒤 커밋 카운트 (↑/↓)
파일별 상태 배지 : 수정 / 추가 / 삭제 / 이름변경 / 추적 안 됨 / 충돌
체크박스로 스테이징, amend 옵션 포함 커밋
브랜치 전환 / 새 브랜치 생성
Stash 목록 보기·적용
Push / Pull
파일별 diff 보기

1.5 자주 쓰는 단축키

단축키	동작
⌘S	파일 저장
⌘B / ⌘I / ⌘K	굵게 / 기울임 / 링크
⌘F	현재 파일 안에서 찾기·바꾸기 (정규식/대소문자 지원)
⌘⇧F	전체 컬렉션 grep 검색
⌘Z / ⌘⇧Z	실행 취소 / 다시 하기
`[[`	위키링크 자동완성 (최대 12개 결과)
ESC	검색 초기화, 메뉴 닫기

[!TIP] 자동 저장은 2초마다 localStorage 에 백업된다. 디스크 저장은 ⌘S 로 명시적으로. 두 레이어가 있어서 실수로 탭을 닫아도 직전 상태로 복원된다.

1.6 잘 안 보이지만 매일 도움되는 것들

드래그-드롭 이미지 : Finder 에서 textarea 위로 끌어오면 자동 업로드
클립보드 붙여넣기 이미지 : 스크린샷 직후 ⌘V 한 번으로 본문에 삽입
자동 리스트 계속 : 리스트 안에서 Enter 치면 다음 줄도 같은 들여쓰기
스크롤 동기화 : 편집 영역과 미리보기 영역이 함께 스크롤
.md ↔ .mdx 토글 : 차트 같은 JSX 가 필요한 순간 한 번에 변환

2. 애니메이션 스튜디오 (`/_studio`)

말로 설명하기보다 움직임으로 보여주는 게 빠른 개념들이 있다. BFS 의 큐가 어떻게 비워지는지, async 콜백이 어떤 순서로 큐를 옮겨다니는지, TCP 핸드셰이크의 세 메시지가 어떻게 오가는지. 그런 장면을 위해 만든 SVG 애니메이션 에디터다.

화면은 네 구역으로 나뉜다.

왼쪽, 요소 추가 패널 + 캔버스 크기 프리셋
가운데, 800×500 기본 캔버스 (프리셋으로 변경 가능)
오른쪽, 선택한 요소의 속성 패널 (선택 없으면 애니메이션 메타)
아래, 챕터 / 키프레임 / 요소별 트랙이 있는 타임라인

2.1 요소 타입 9종

캔버스에 그릴 수 있는 모든 도형이다. 모두 SVG 로 직접 렌더링되므로 결과물은 어디서든 깨지지 않는다.

타입	핵심 속성	비고
Rect	x / y / width / height / cornerRadius	라벨 텍스트 내장, 모서리 라운드
Circle	cx / cy / r	라벨 텍스트 내장
Line	x1 / y1 / x2 / y2	양 끝점을 요소에 sticky 가능
Arrow	x1 / y1 / x2 / y2 + arrowHead	앵커 시스템으로 요소 연결
Text	x / y / content / fontSize / color	캔버스에서 더블클릭으로 inline 편집
Image	x / y / width / height / src	업로드·드래그-드롭·붙여넣기로 추가
Path	d (SVG path)	임의 곡선·다각형
Polygon	points	정다각형/꼭지점 직접 지정
Group	childIds	여러 요소를 하나로 묶음 (⌘G / ⌘⇧G)

2.2 요소 추가, 한 번의 클릭

좌측 패널의 버튼을 누르면 해당 타입의 요소가 캔버스 중앙에 즉시 생성되고, 타임라인에 자동으로 트랙이 깔린다. 새로 추가된 요소는 곧바로 선택 상태가 되어 우측 속성 패널에서 바로 다듬을 수 있다.

2.3 속성 패널, 모든 디테일을 한 곳에서

요소를 선택하면 우측 패널이 그 요소 전용 속성으로 바뀐다. Rect 라면 위치·크기·코너 라운드·채우기·테두리·라벨·회전이 한 화면에 들어온다.

값을 바꾸면 캔버스가 즉시 갱신된다. 색상 같은 시각 속성은 패널 안의 컬러 픽커로 다루고, 결과는 한 박자도 늦지 않게 반영된다.

타입별로 노출되는 속성도 의도적으로 다르다. Circle 은 cx/cy/r, Line/Arrow 는 x1/y1/x2/y2, Text 는 content/fontSize/color/fontWeight/textAnchor. 굳이 안 보이는 속성을 보여주지 않는 쪽이 잘못 누를 일이 적다.

2.4 캔버스, 그리는 공간

캔버스 자체에도 사소하지만 자주 쓰이는 도구가 붙어 있다.

프리셋 6종 캔버스 크기 : 8:5 (800×500), 16:9 (1280×720), 4:3 (1024×768), 1:1 (600×600), 3:1 (1200×400), 모바일 9:19 (375×812)
격자 + 스냅 : G 키로 토글, 8px 단위
줌 : ⌘ + 휠 스크롤로 캔버스 자체를 확대 / 축소
팬 : Space + 드래그 (Figma 와 같은 손바닥 도구)
선택 핸들 : 8방향 리사이즈 + 위쪽 회전 핸들 + 앵커 포인트
인라인 텍스트 편집 : 텍스트 요소를 더블클릭하면 캔버스 위에서 바로 타이핑
드래그-드롭 이미지 : Finder 에서 캔버스로 끌어오면 자동 업로드 후 배치

2.5 다중 선택과 정렬·분배

여러 요소를 한 번에 다루는 일이 잦아서 별도 도구 모음을 붙였다. ⌘ + 클릭이나 마퀴 드래그로 2개 이상을 골라두면 속성 패널이 다중 선택 모드로 바뀐다.

정렬 6종 : 왼쪽 / 가운데(수평) / 오른쪽 / 위 / 가운데(수직) / 아래
분포 2종 : 가로 간격 균등 / 세로 간격 균등 (3개 이상 선택 시)
함께 이동 : 캔버스 드래그나 화살표 키 한 번으로 선택된 모든 요소가 같은 양만큼 이동

2.6 그룹화, 함께 움직이는 요소

여러 요소를 ⌘G 로 묶으면 하나의 group 요소로 합쳐진다. 그룹은 자체적으로 위치/크기가 없는 대신 자식 요소들의 bounding box 를 따라간다.

그룹 / 그룹 해제 : ⌘G / ⌘⇧G
드릴 인 : Alt+클릭으로 그룹 안의 개별 자식을 직접 선택
그룹 단위 이동 : 화살표 키 / 드래그가 자식 전체에 동일하게 적용
자식 목록 : 속성 패널에서 직접 확인하고 클릭으로 점프

2.7 타임라인과 챕터, 시간의 모양

스튜디오의 두 번째 본체는 타임라인이다. 모든 요소는 시간축 위에 트랙으로 존재하고, 그 위에 챕터·이펙트·키프레임이 얹힌다.

Chapter : 의미 단위로 시간을 자른다. 라벨 + 시간 + 길이를 가지며, 선택 후 ←/→ 로 ±100ms, Shift + 로 ±1000ms 미세 조정
Effect 3종 : highlight, pulse, flow 로 특정 시점에 요소를 강조
Keyframe Track : 요소 속성별로 시간축에 키프레임을 찍고 드래그로 타이밍 조정
재생 컨트롤 : Play/Stop, Reset, 0.25 ~ 3x 속도 슬라이더
타임라인 줌 : ⌘ + 휠 로 pxPerMs 조정 (값은 localStorage('studio.timeline.pxPerMs') 에 저장)

2.8 재생, 의도한 움직임을 확인

Play 버튼을 누르면 캔버스가 정의된 순서대로 요소를 등장시킨다. Entry/Exit 모드는 instant, fade, slide-left/right/up/down, zoom, pop 8종이 기본 제공되고, 각각 등장 시간을 따로 줄 수 있다.

만든 애니메이션은 loop, autoplay, showCaption, showChapterList 같은 메타 설정과 함께 JSON 으로 저장돼, 블로그 본문 어디에든 한 줄로 끼워 넣을 수 있다.

2.9 아이콘 라이브러리, 1856개

처음에 아이콘이 필요할 때마다 svg 를 손으로 가져다 붙였는데, 그게 쌓이다 보니 결국 카테고리별 아이콘 라이브러리가 됐다.

분류는 클라우드 (AWS / GCP / Azure / Cloud), 데이터 (DB), 언어 (Lang), 프론트·백 (FE / BE / Tool / Net), 모델링 (ERD / Arrow / Doc / Device), 의사소통 (Comm), 행위 (Action), 도형 (Chart / Shape), 사람 (User), 미디어 (Media), 금융 (Finance / Crypto), 기호 (Symbol), 그리고 외부 아이콘 세트인 Tabler 166개와 Lucide 294개.

검색창에 키워드만 넣으면 즉시 필터된다.

선택한 아이콘은 SVG path 로 캔버스에 들어가서, 색상·크기·회전 같은 일반 도형 속성을 그대로 받는다.

2.10 명령 팔레트, ⌘K

자주 쓰는 명령을 손 가까이 두고 싶어서 만든 작은 검색 인터페이스. 명령 / 요소 / 태그 / 도움말 네 종류를 한 입력창에서 다룬다.

명령 : 라이브러리 열기, 새 애니메이션, 저장, 삭제, 실행 취소 / 다시 실행, 작업 이력, 재생 / 정지, 격자 토글, 단축키 보기
요소 검색 : 캔버스에 있는 요소의 이름·라벨·id·타입을 한 번에 훑어서 즉시 선택
태그·도움말 : 보다 가벼운 검색을 위한 채널

2.11 작업 이력, 시간을 되돌리는 길

⌘⇧H 를 누르면 작업 이력 패널이 열린다. 단순한 undo/redo 보다 한 단계 위, 모든 변경 사항이 의미 단위로 라벨링돼 있어서 과거의 한 시점을 골라 거기로 점프할 수 있다.

현재 위치 : 패널 상단에 분명한 구분선 + 라벨
과거 항목 : 클릭하면 그만큼 undo 된 상태로 이동
미래 항목 : 클릭하면 redo (현재가 미래의 한 시점이라면)
라벨링 규칙 : 이동: client, Chapter 추가: ..., 요소 추가: rect 식으로 도메인 + 대상 + 키
HistoryKind : 메타 / 추가 / 삭제 / 이동 / 스타일 / 회전 / 리사이즈 등 12 종으로 색상 구분

2.12 단축키와 도움말

? 키를 누르면 자주 쓰는 단축키가 한 화면에 모인다.

전체 단축키 요약 :

단축키	동작
⌘S	저장
⌘Z / ⌘⇧Z	실행 취소 / 다시 하기
⌘C / ⌘V / ⌘X	복사 / 붙여넣기 / 잘라내기
⌘D	복제
⌘A	전체 선택
⌘G / ⌘⇧G	그룹화 / 그룹 해제
⌘K	명령 팔레트
⌘⇧H	작업 이력
G	격자 토글
Space + 드래그	캔버스 팬
⌘ + 휠	캔버스 줌
방향키	±1px 이동 (Shift 와 함께 ±10px)
Tab / ⇧Tab	요소 순환
Delete / Backspace	선택 요소 삭제
? / ⇧?	도움말

2.13 데이터 모델

스튜디오에서 만든 모든 애니메이션은 결국 하나의 JSON 으로 직렬화된다.

type AnimationDef = {
  id: string;
  title: string;
  description: string;
  duration: number;       // ms
  canvas: { width, height, background };
  settings: {
    loop, autoplay,
    showCaption, showChapterList
  };
  elements: AnimationElement[];   // rect | circle | ... | group
  chapters: Chapter[];
  effects: AnimationEffect[];     // highlight | pulse | flow
  version: 3 | 4;
};

public/animations/*.json 에 저장된 파일은 본문에서 다음과 같이 호출한다.

```anim:bfs
{}
```

version 을 두 가지로 유지하는 건 의도적이다. v3 시절 만든 29개 파일이 그대로 로드되고, v4 에서 추가한 group 타입은 옵셔널이라 옛 파일을 깨뜨리지 않는다. 새 타입이 더해질 때마다 union 에 한 줄 더하고, 마이그레이션 헬퍼를 옆에 두는 식으로 키워간다.

3. Chart.js 에디터 (`/_chart-editor`)

벤치마크 결과, 성능 비교, 분포 같은 글에서는 차트 한 장이 표 열 개보다 빠르다. 그래서 Chart.js 차트를 만들어 MDX 본문에 붙여넣을 수 있는 작은 에디터를 따로 만들었다.

좌측에서 값을 바꾸면 우측 미리보기가 200ms 디바운스 후 다시 그려지고, 동시에 아래쪽 MDX 코드 패널에 본문에 붙여넣을 수 있는  스니펫이 갱신된다.

3.1 지원 차트 타입

내장 컴포넌트 () 는 Chart.js 의 8종 차트를 모두 지원하고, 에디터 UI 는 그중 자주 쓰는 6종을 드롭다운으로 제공한다.

차트	에디터	축
Bar	✅	✅
Line	✅	✅
Pie	✅	-
Doughnut	✅	-
Radar	✅	-
Scatter	✅	✅
Bubble	(수동 작성)	✅
Polar Area	(수동 작성)	-

3.2 5개 내장 템플릿

처음부터 빈 JSON 을 채우는 건 피곤하다. 그래서 자주 쓰던 형태 다섯 가지를 템플릿 버튼으로 빼놨다.

템플릿	용도 예시
Line (기본)	시계열, 단순 트렌드
Bar (비교)	A vs B 처럼 두 값 비교
Line (Log Scale)	자릿수가 큰 값 비교 (`scales.y.type: 'logarithmic'`)
Horizontal Bar	라벨이 긴 값들의 순위 비교 (`indexAxis: 'y'`)
Pie	비율 표시

Pie 템플릿을 누르면 즉시 미리보기와 MDX 코드가 함께 바뀐다.

3.3 자동으로 신경 써주는 것들

테마 자동 대응 : <html class="dark"> 가 토글되면 MutationObserver 가 감지해서 축 라벨·그리드 색상을 즉시 갱신
자동 옵션 병합 : responsive, maintainAspectRatio: false, 범례 위치·폰트, 그리드 색상 등은 컴포넌트가 자동으로 채움
인스턴스 재사용 : 타입이 바뀔 때만 차트 인스턴스 재생성, 나머지는 chart.update() 로 부드럽게 갱신
JSON 파싱 에러 표시 : data 와 options 각각 별도 에러 메시지

3.4 본문에서 사용하기

MDX 파일에서는 import 없이 바로 사용할 수 있다 (astro-auto-import 가 모든 MDX 에 자동 주입).

<!-- mdx-component: ChartJs -->

[!IMPORTANT] client:visible 디렉티브를 빠뜨리면 SSR 시점에 렌더되면서 차트 라이브러리가 실행되지 않는다. 차트는 무조건 클라이언트 hydration 후에 그려야 한다.

[!CAUTION] Pie, Doughnut, Radar, Polar Area 같은 radial 차트에는 scales 옵션이 없다. 넣으면 Chart.js 가 무시하지만, 헷갈리지 않게 빼두는 게 깔끔하다.

3.5 실제 사용 예

차트 에디터로 만든 차트가 실제로 들어가 있는 글들 :

[[CPU vs GPU vs TPU vs NPU, 네 종류 프로세서의 원리와 최근 동향|CPU vs GPU vs TPU vs NPU]] : 수평 막대 + 로그 스케일
[[UNION vs OR vs IN 벤치마크 (1), 실험 설계와 결과|UNION vs OR vs IN 벤치마크 (1)]] : 다중 시리즈 선 차트
[[브라우저 기반 통신 총정리, HTTP부터 WebRTC까지, 어디에 부하가 가는가|브라우저 기반 통신 총정리]] : 수평 막대 차트

도구가 자라는 방향

세 도구는 모두 “필요해서 만든다 → 자주 쓰니 다듬는다 → 다듬다 보니 새로운 기능이 생긴다” 의 사이클로 자라왔다.

에디터 는 단순한 textarea + preview 에서 시작해서 Git 패널, 위키링크 자동완성, 전체 파일 grep 까지 도달했다.
스튜디오 는 [[BFS|너비 우선 탐색]] 한 장면을 그리려고 만든 SVG 손그림 에디터에서 시작해서, 지금은 타임라인·키프레임·그룹·작업 이력까지 갖춘 작은 모션 도구가 됐다.
차트 에디터 는 글 안에 차트를 넣을 때마다 JSON 을 손으로 쓰다가 지쳐서 만든, 가장 늦게 합류한 도구다.

다음에 손볼 부분도 비슷한 결로 정해둔다. 위키와의 연동을 더 깊이 가져가는 일 (AI 가 모은 초안을 에디터 안에서 곧장 다듬기), 스튜디오에서 만든 애니메이션의 한 프레임을 차트 에디터로 보내거나, 반대로 차트의 한 상태를 애니메이션 키프레임으로 묶는 일 같은.

[!TIP] 이 글에 등장한 모든 스크린샷도 /_editor 의 이미지 다이얼로그를 거쳐 본문에 자동 삽입됐다. 도구가 도구 자신을 소개하는 글의 자료가 되는 작은 자기 참조.

도구를 만든 후 가장 크게 달라진 건, 글을 시작하는 속도와 글을 끝내지 못하는 빈도 둘 다 줄었다는 점이다. 마찰을 줄이는 일이 결국 더 많은 글을 남긴다, 라는 가설을 매일 검증하는 중이다.

[Leetcode] 2804 Array Prototype ForEach

koa (김신건) — Thu, 18 Jun 2026 05:00:00 GMT

문제 요약

2804. Array Prototype ForEach

표준 Array.prototype.forEach 의 동작을 직접 구현하는 문제다. 두 인자를 받는다.

callback(value, index, array) 가 배열의 각 요소마다 호출된다.
두 번째 인자 context 가 주어지면, callback 내부의 this 가 context 를 가리켜야 한다.

표준 메서드를 쓰지 말고 직접 구현하라는 제약이 붙는다.

Array.prototype.forEach = function (callback, context) {
  for (let i = 0; i < this.length; i++) {
    // 여기서 callback 을 호출하면서 this 를 context 로 바꾸어야 한다
  }
};

표면적으로는 단순한 반복문이다. 다만 “함수의 this 를 외부에서 지정한다” 는 요건이 [[function]] 의 this 동적 바인딩, [[arrow function]] 의 lexical this, 그리고 call / apply / bind 까지 한 자리에 모이는 좋은 출발점이라 정리할 가치가 있다.

검증용 예시:

같은 결과를 만들어내는 다섯 가지 길을 차례로 본다.

1. call 사용 (정석)

구현

Array.prototype.forEach = function (callback, context) {
  for (let i = 0; i < this.length; i++) {
    callback.call(context, this[i], i, this);
  }
};

동작 원리

Function.prototype.call(thisArg, ...args) 는 함수를 즉시 실행하면서 this 를 thisArg 로 지정 한다. 인자는 일반 호출처럼 콤마로 나열한다.

forEach 구현에 그대로 옮기면 매 반복마다 callback 을 호출할 때 this 가 context 로 묶인다. 표준 명세 Array.prototype.forEach 도 내부적으로 Call(callbackfn, T, ...) 형태, 즉 같은 방식으로 정의돼 있다.

{}

장단점

표준 동작과 가장 닮았다.
반복문 안이 한 줄로 끝나 읽기 쉽다.
매 반복마다 call 한 번씩의 호출 비용이 있지만 실측으로 드러나는 수준은 아니다.

면접/코딩 테스트에서 기대되는 답이 보통 이 형태다.

2. apply 사용

구현

Array.prototype.forEach = function (callback, context) {
  for (let i = 0; i < this.length; i++) {
    callback.apply(context, [this[i], i, this]);
  }
};

동작 원리

Function.prototype.apply(thisArg, argArray) 는 call 과 동일하게 함수를 즉시 실행하면서 this 를 지정한다. 차이는 인자를 배열로 전달 한다는 것뿐이다.

장단점

인자가 동적으로 정해지는 (이미 배열 형태로 들고 있는) 경우 편리하다.
이 문제처럼 인자 개수가 고정 (3 개) 이라면 매 반복마다 임시 배열을 새로 만드는 비용 만 더해진다.

[!TIP] ES6 의 ...spread 이후로 apply 의 쓰임이 많이 줄었다. fn.apply(ctx, args) 는 fn.call(ctx, ...args) 로 대체할 수 있기 때문이다.

3. bind 사용

구현

Array.prototype.forEach = function (callback, context) {
  const bound = callback.bind(context);
  for (let i = 0; i < this.length; i++) {
    bound(this[i], i, this);
  }
};

동작 원리

Function.prototype.bind(thisArg) 는 함수를 실행하지 않는다. 대신 this 가 미리 묶인 새 함수 객체 를 반환한다.

장단점

반복문이 그냥 bound(...) 가 되어 가장 깔끔해 보인다.
매 반복마다 call 을 부르지 않아도 된다.
대신 새 함수 객체를 한 번 생성 한다. 반복 호출이 많다면 절약이 되지만, 한 번 쓰고 버리는 경우에는 오히려 손해다.
만약 bound 를 반복문 안에서 만들면 (callback.bind(context) 를 매 반복마다 호출) 가장 비싼 선택이 된다.

4. 객체 메서드 방식 (call 의 내부 구현)

구현

Array.prototype.forEach = function (callback, context) {
  const key = Symbol();
  context[key] = callback;
  for (let i = 0; i < this.length; i++) {
    context[key](this[i], i, this);
  }
  delete context[key];
};

동작 원리

JavaScript 에서 함수 호출 구문 obj.fn() 의 this 는 호출 직전에 . 좌측이 무엇이었는지 로 결정된다 ([[function]] 의 this 동적 바인딩). 즉,

context.temp = callback;
context.temp(); // 이 호출 시점에 this === context

이렇게 임시로 객체의 메서드로 만든 뒤 호출하면 call 없이도 this 를 바꿀 수 있다.

이 방식은 사실 Function.prototype.call 을 직접 구현해야 하는 면접 문제의 표준 해법으로 자주 등장한다. Symbol() 로 고유 키를 만들어 기존 속성과의 충돌을 막고, 끝난 뒤 delete 로 흔적을 지운다.

{}

장단점

this 바인딩의 메커니즘을 가장 노골적으로 보여준다.
인자로 받은 context 객체를 직접 변형 한다. 호출 도중 throw 가 나면 delete 까지 도달하지 못해 키가 남는다 (try / finally 로 보완 필요).
frozen 객체 (Object.freeze), Proxy, getter/setter 가 걸린 객체에는 통하지 않는다.
실무에서는 거의 쓰지 않는다. “원리를 설명할 때” 용도.

[!CAUTION] 입력으로 받은 객체를 임의로 수정하는 것은 사이드 이펙트의 원천이다. 라이브러리/표준 메서드 구현에서는 피해야 할 패턴이다.

5. 화살표 함수 (Arrow Function) 주의사항

위 네 가지 방식 모두 한 가지 가정에 기대고 있다. callback 이 일반 함수일 것 이다.

[[arrow function]] 은 자체 this 를 가지지 않는다. 자신이 선언된 위치의 [[Lexical Environment]] 에 있는 this 를 그대로 본다. call / apply / bind 모두 화살표 함수의 this 를 바꿀 수 없다.

<CodeWithOutput title=“화살표 함수의 this 는 call 로도 안 바뀐다” language=“javascript” code={`const fn = () => { console.log(this); };

fn.call({ name: ‘Tom’ });} output={(전역 객체 또는 상위 스코프의 this, strict 모듈에서는 undefined)`} />

즉, 문제의 검증 케이스가 callback 으로 화살표 함수를 넘긴다면 어떤 구현을 써도 context 가 반영되지 않는다.

같은 lexical vs dynamic this 차이는 [[arrow function]] 의 setInterval 예시에서도 동일하게 드러난다.

{}

[!IMPORTANT] LeetCode 의 채점 케이스도 이 차이를 노린다. (val, i, arr) => arr[i] = this 같은 화살표 콜백을 넘겼을 때 this 가 정의 시점의 모듈 스코프 (테스트 러너가 화살표 함수를 평가한 환경) 로 묶이는 것을 확인하는 식이다. 구현이 잘못된 게 아니라, 화살표 함수의 정의 그 자체가 그렇게 동작한다.

call / apply / bind 는 모두 일반 함수에만 의미가 있다. 이 사실을 모르고 forEach 의 callback 으로 화살표 함수를 쓰면 디버그하기 까다로운 버그가 된다.

각 방식 비교

방식	즉시 실행	this 지정	함수 객체 생성	입력 객체 변형
`call`	O	O	X	X
`apply`	O	O	X	X
`bind`	X	O	O (한 번)	X
객체 메서드	O	O	X	O (Symbol 키)

call 과 apply 는 호출 시 비용 외에 부산물이 없다. bind 는 함수 객체 하나를 새로 만들지만 반복 호출 비용은 가장 적다. 객체 메서드 방식은 호출 비용 자체는 가장 적지만 입력 객체를 변형한다는 점에서 사이드 이펙트가 가장 크다.

결론, 무엇을 골라야 하는가

Array.prototype.forEach = function (callback, context) {
  for (let i = 0; i < this.length; i++) {
    callback.call(context, this[i], i, this);
  }
};

이 풀이가 가장 무난한 선택이다.

명세 Array.prototype.forEach 의 내부 알고리즘이 사실상 Call(callbackfn, thisArg, ...) 라, 그것과 가장 가깝다.
코드가 짧고 읽기 쉽다.
입력 객체를 변형하지 않는다.
새로운 함수 객체를 만들지 않는다.

bind 는 같은 callback 을 여러 곳에서 재사용할 때 의미가 있다. 객체 메서드 방식은 call 의 동작 원리를 묻는 면접에서 별도로 등장한다. 둘 다 이 문제의 정답으로는 과한 선택이다.

화살표 함수에 관한 함정은 forEach 만의 문제가 아니다. setTimeout 의 콜백, 이벤트 리스너, Promise.then 의 핸들러 등 외부에서 this 를 지정하려는 모든 API 와 화살표 함수는 어울리지 않는다. 이 부분의 메커니즘은 [[비동기와 타이밍, 콜백부터 async/await까지의 발전사]] 의 콜백 절에서도 같은 언어로 설명된다.

브라우저 기반 통신 총정리, HTTP부터 WebRTC까지, 어디에 부하가 가는가

koa (김신건) — Tue, 16 Jun 2026 00:00:00 GMT

시작, 왜 이렇게 많은 통신 방식이 있나

웹은 처음엔 단순했다. 브라우저가 페이지를 요청하면 서버가 HTML을 돌려주는 것. 요청 한 번, 응답 한 번. HTTP/1.0의 모든 것.

그런데 시간이 흐르며 요구사항이 늘어났다.

“여러 자원을 동시에 받고 싶다” → HTTP/1.1 keep-alive, HTTP/2 multiplexing
“서버가 먼저 알려주고 싶다” → Long Polling, Server-Sent Events
“양쪽이 자유롭게 주고받고 싶다” → WebSocket
“서버를 거치지 말고 둘이 직접 연결되고 싶다” → WebRTC
“HTTP/3 위에서 더 가볍게 양방향 stream이 필요하다” → WebTransport

각 통신 방식은 직전 방식의 한계를 푸는 한 걸음씩이다. 이 글에서는 각 방식의 통신 주체·프로토콜·내용·리소스 사용량 을 차례로 보고, “부하는 어디에 가는가” 라는 질문에 답하는 한 장의 표와 실측 차트로 정리한다.

먼저 모든 선택의 첫 단추인 Stateless vs Stateful 부터.

한 단계 뒤로, Stateless vs Stateful 이라는 첫 단추

[[Stateless]] vs [[Stateful]] 의 선택은 통신 방식 선택보다 먼저 와야 한다. 이 결정이 수평 확장 전략·인프라 복잡도·운영 비용을 결정하기 때문이다.

측면	Stateless	Stateful
서버 메모리	요청 처리에만 필요	활성 세션마다 메모리
수평 확장	매우 쉬움, 어느 서버든 OK	[[Sticky Session]] 필요
장애 복원	서버 교체 무영향	세션 손실 (외부 store 시 완화)
로드밸런서	단순 round-robin	client → server 일관 라우팅
캐싱	URL 기반 캐시 효율적	캐시 효율 낮음

각 통신 방식의 상태성:

방식	Stateless / Stateful
HTTP (1.1/2/3)	Stateless
HTTP + 쿠키/JWT	상태를 클라이언트 에 위임한 Stateless
Long Polling	Stateless (각 요청 독립)
Server-Sent Events	Stateful (지속 연결, 단방향)
WebSocket	Stateful (지속 연결, 양방향)
WebRTC	Stateful (P2P 세션)

[!IMPORTANT] “Stateful 한 통신을 쓰겠다”는 결정은 곧 “서버 메모리에 연결 상태가 N개 쌓일 것을 감수하고, [[Sticky Session]] 또는 외부 라우팅 인프라를 운영하겠다” 는 결정과 같다. 단순히 “기능적으로 필요하다”는 이유만으로 가볍게 선택하면 운영 비용이 따라온다.

이 관점을 가지고 HTTP부터 보자.

기본 HTTP, Stateless 의 정수

HTTP/1.1: [[TCP]] 한 연결 위에서 순차적 요청·응답

가장 익숙한 형태. 브라우저가 GET/POST 등의 요청을 보내면 서버가 응답한다.

GET /api/users HTTP/1.1
Host: example.com
Accept: application/json

---
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 42

{"users":[{"id":1,"name":"alice"}]}

{}

Keep-Alive, 연결을 재사용하는 첫 번째 시도

HTTP/1.0 의 큰 문제는 요청마다 [[TCP]] 연결을 새로 맺는 것이었다. TCP 3-way handshake에 1 RTT, [[TLS]] handshake에 1-2 RTT, 모바일 네트워크에서 100~300 ms 가 매 요청마다 추가됐다.

HTTP/1.1 은 기본적으로 Connection: keep-alive 를 활성화해 한 TCP 연결을 여러 요청에 재사용한다.

GET /api/users HTTP/1.1
Host: example.com
Connection: keep-alive    ← (HTTP/1.1 기본값이라 생략 가능)

GET /api/orders HTTP/1.1
Host: example.com
Connection: keep-alive    ← 같은 TCP 연결로 다음 요청

서버는 응답 후 연결을 닫지 않고 일정 시간 대기 (Keep-Alive: timeout=5 같은 헤더로 표현). 이 시간 내에 같은 클라이언트가 또 요청하면 핸드셰이크 비용 없이 처리.

한계 1, Pipelining 의 실패: HTTP/1.1 의 pipelining (응답을 기다리지 않고 다음 요청 보내기)은 거의 모든 프록시에서 비활성화됨. 실무에선 같은 연결의 다음 요청은 이전 응답을 기다려야 한다.

한계 2, [[Head-of-Line Blocking]]: 한 연결 안에서는 응답이 순서대로 와야 한다. 첫 응답이 5초 걸리면 그 연결의 두 번째 응답은 5초 뒤에야 시작.

한계 3, 도메인당 6 연결: 브라우저는 같은 호스트에 최대 6~8 개의 TCP 연결만 동시에 유지한다. 자원이 많은 페이지(이미지 100장)는 6 줄 줄로 받아야 함.

이걸 푸는 게 HTTP/2.

HTTP/2: 한 연결에서 multiplexing

{}

HTTP/2 는 단일 [[TCP]] 연결 안에서 여러 stream 을 동시에 주고받는다. 단순히 “효과”를 외우기보다 각 기능이 무엇을 하는지 부터 보자.

Multiplexing, frame 단위 인터리브

한 TCP 연결을 여러 stream 으로 나누고, 각 stream 의 데이터를 잘게 frame 으로 쪼개 인터리브해 전송한다. 각 frame 헤더에 stream ID 가 붙어 어느 stream 의 것인지 식별한다.

1 TCP 연결
  ├ Stream 1 (CSS):   frame ─ frame ─ frame
  ├ Stream 3 (JS):    frame ─ frame
  └ Stream 5 (Image): frame ─ frame ─ frame ─ frame

서버는 빠른 응답(작은 CSS)을 먼저 보내고, 느린 응답(이미지)을 그 사이사이에 끼워 보낼 수 있다.

→ 효과: HTTP/1.1 의 도메인당 6 연결 한계 + 연결 내 HOL Blocking 모두 해소. 동시 요청이 많은 페이지에서 큰 이득.

[[HPACK]] 헤더 압축

HTTP/1.1 은 매 요청마다 같은 헤더(User-Agent, Cookie, Accept-Encoding 등)를 텍스트로 반복 전송. 한 페이지 로드에 헤더만 수십 KB.

HPACK 은 두 단계로 압축한다.

Static Table: :method GET, :path / 같은 자주 쓰이는 헤더를 미리 정의된 인덱스(1~61) 로 치환
Dynamic Table: 처음 본 헤더는 인덱스에 등록 → 다음부터는 인덱스만 송신
Huffman 인코딩: 텍스트 부분도 Huffman 코드로 압축

→ 효과: 페이지 로드 시 헤더 크기 80~95% 절약. 모바일 (TCP slow start 단계) 에서 특히 큼.

Stream Priority

각 stream 에 우선순위와 의존 관계를 부여 (PRIORITY frame). 서버는 우선순위 높은 stream 의 frame 부터 송신.

브라우저:
  - main.css (priority 256, blocking)
  - app.js (priority 220, blocking)
  - hero.png (priority 100, dependent on main.css)

→ 효과: 같은 대역폭에서 critical rendering path 가 먼저 도착 → First Contentful Paint 가 빨라진다.

Server Push, 왜 deprecated 되었나

서버가 클라이언트가 요청하지 않은 자원도 미리 push 하는 기능이었다.

GET /index.html
  → 서버: "어차피 main.css 도 곧 요청할 거잖아? 미리 보낼게"
  → PUSH_PROMISE frame + main.css 내용 함께 송신

이론상: HTML 파싱 → CSS 발견 → 요청 → 응답 의 RTT 한 번을 절약.

실제로 deprecated 된 이유:

캐시 미스를 모름: 서버는 클라이언트가 이미 캐시에 main.css 를 가지고 있는지 알 수 없다 → 불필요한 중복 전송이 빈번
우선순위 충돌: push 된 자원이 실제 critical 자원의 대역폭을 빼앗는 경우 발생
구현 복잡도: 서버가 “어떤 자원을 push 할지” 정확히 판단하기 어려움
103 Early Hints 가 더 나음: 같은 효과를 캐시 친화적으로 달성

Chrome 은 2022년 (M106) HTTP/2 Server Push 지원을 제거했다. 대신 103 Early Hints 를 권장한다, 서버가 최종 응답 전에 “곧 필요할 자원 URL 목록”을 미리 알려주면 브라우저가 자기 캐시 상태를 보고 직접 요청하는 방식.

남은 한계: TCP HOL Blocking

HTTP/2 가 HTTP 레벨 의 [[Head-of-Line Blocking]] 을 풀었지만, TCP 레벨 의 HOL Blocking 은 그대로다. 한 TCP 패킷이 손실되면, 그 패킷이 어느 stream 에 속하든 [[TCP]] 는 순서 유지를 위해 모든 stream 의 후속 패킷을 대기시킨다.

흥미로운 실측: 요청 수가 적을 때 HTTP/2 가 HTTP/1.1 보다 오히려 느릴 수 있다. 단일 대용량 요청은 HTTP/1.1 의 한 연결이 HTTP/2 의 multiplexing 오버헤드보다 가볍다. 100개 동시 요청 같은 시나리오에서 HTTP/2 의 진가가 발휘된다.

HTTP/3: [[QUIC]] 위에서

{}

HTTP/3 는 [[TCP]] 가 아니라 [[UDP]] 기반의 [[QUIC]] 프로토콜을 쓴다.

Stream 격리: 한 stream 의 패킷 손실이 다른 stream 에 영향 안 줌, TCP HOL Blocking 의 본질적 해결
0-RTT resumption: 재접속 시 첫 패킷에 데이터 동봉
Connection migration: 와이파이 → 셀룰러 전환 시 IP 가 바뀌어도 같은 연결 유지
[[TLS]] 1.3 통합: 핸드셰이크에 보안 내장 (1 RTT)

브라우저 코드는 그대로다.

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

어떤 프로토콜 버전이 사용되는지는 서버 설정과 네트워크 환경이 결정한다. 개발자 도구 Network 탭 Protocol 열에 h2, h3 으로 표시된다.

HTTP 통합 비교, 어디에 부하가 가나

HTTP 자체는 [[Stateless]] 다. 서버가 stateless 라는 건 수평 확장이 매우 단순하다는 뜻이다. 트래픽 증가 시 서버 인스턴스를 늘리고 로드밸런서가 round-robin 분배하면 끝.

버전	클라이언트	서버	네트워크
HTTP/1.1	6 연결 관리, 핸드셰이크 다수	Stateless, 매우 가벼움	헤더 반복 + HOL 영향
HTTP/2	1 연결 + stream 관리	Stateless, 가벼움	멀티플렉싱 효율적
HTTP/3	QUIC stack (CPU 약간 더)	Stateless, 가벼움	UDP 차단 환경에서 폴백

REST API, 정적 자원 fetch, 일회성 폼 제출 등 거의 모든 비실시간 요청이 HTTP 로 충분하다.

문제는 “서버가 알려주고 싶을 때”다. HTTP의 요청-응답 모델은 클라이언트가 먼저 요청해야만 응답이 가능하다. 그래서 등장한 첫 번째 우회 방법이 polling.

Polling, HTTP 위에서 실시간 흉내내기

Short Polling: 매 N초마다 묻기

setInterval(async () => {
  const res = await fetch('/api/notifications');
  const events = await res.json();
  events.forEach(showNotification);
}, 3000);

구현 간단, HTTP 그대로 (여전히 Stateless 서버)
단점: 대부분의 요청은 빈 응답. 매 요청마다 TCP 핸드셰이크(또는 keep-alive 점유) + 헤더 비용
부하: 클라이언트 1000명이 5초마다 polling → 서버는 초당 200 RPS 처리. 빈 응답이 대부분

Long Polling: 서버가 응답을 보류

async function longPoll() {
  while (true) {
    const res = await fetch('/api/notifications/wait');
    const event = await res.json();
    if (event) showNotification(event);
  }
}
longPoll();

서버는 새 이벤트가 발생할 때까지 응답을 잡고 있다가, 발생하면 즉시 응답한다.

장점: 빈 응답 거의 없음
단점: 서버가 connection 을 길게 점유 → 연결 수 = 동시 클라이언트 수
상태: HTTP 의미상 Stateless 지만, 운영 입장에선 TCP 연결 점유가 Stateful 과 비슷한 부담

{}

위 애니메이션이 Short Polling, Long Polling, 그리고 다음에 볼 SSE, WebSocket 의 메시지 흐름 차이를 한눈에 보여준다.

Polling 의 부하 특성

c5.xlarge EC2 (4 vCPU, 8GB RAM) 에서 10K 동시 연결 측정 (BirJob 2026):

Long Polling 메모리: 1.8 GB (연결당 ~180 KB)
Long Polling CPU: 45% (constant 재연결 처리)

이 수치를 다음 절들의 SSE/WebSocket 수치와 비교하면 차이가 명확해진다.

Server-Sent Events, 서버가 스트림으로 push

SSE 는 사실상 하나의 HTTP 응답이 영원히 끝나지 않는 방식이다. HTTP/1.1 위에서 동작하지만 [[Stateful]] 한 연결을 유지한다.

const es = new EventSource('/api/stream');

es.onmessage = (e) => {
  console.log('event:', e.data);
};

es.addEventListener('user-joined', (e) => {
  const user = JSON.parse(e.data);
  showUser(user);
});

es.onerror = () => {
  // 자동으로 재연결 시도됨
};

서버 측 응답 포맷:

HTTP/1.1 200 OK
Content-Type: text/event-stream
Cache-Control: no-cache

event: user-joined
data: {"id": 1, "name": "alice"}
id: 42

data: hello
id: 43

retry: 5000

각 이벤트는 data: , event: , id: , retry: 같은 필드로 구성되고 빈 줄로 구분된다.

SSE 의 자동 재연결 + Last-Event-ID

가장 큰 장점이다. EventSource 는 연결이 끊어지면 자동으로 재시도하고, 마지막으로 받은 이벤트 ID 를 Last-Event-ID 헤더로 보낸다. 서버는 그 ID 이후의 이벤트만 다시 보내면 된다.

// Node.js + Express 예시
app.get('/api/stream', (req, res) => {
  res.setHeader('Content-Type', 'text/event-stream');
  res.setHeader('Cache-Control', 'no-cache');
  res.setHeader('Connection', 'keep-alive');

  const lastId = parseInt(req.header('Last-Event-ID') ?? '0', 10);
  const events = getEventsSince(lastId);
  events.forEach((evt) => {
    res.write(`id: ${evt.id}\n`);
    res.write(`event: ${evt.type}\n`);
    res.write(`data: ${JSON.stringify(evt.payload)}\n\n`);
  });

  const onNewEvent = (evt) => {
    res.write(`id: ${evt.id}\n`);
    res.write(`data: ${JSON.stringify(evt.payload)}\n\n`);
  };
  eventBus.on('new', onNewEvent);

  req.on('close', () => eventBus.off('new', onNewEvent));
});

이 자동 재연결 + 상태 복원이 WebSocket 에는 없어서 직접 구현해야 하는 부분이다.

SSE 의 부하 특성 (실측)

연결당 메모리: ~1.2 KB (Ark Protocol 2026) ~ ~60 KB (Wolf-tech 2026, Node.js net layer 포함)
10K 동시 연결 총 메모리: ~600 MB (BirJob 2026)
CPU idle: 8% (BirJob 2026)
연결당 idle 대역폭: ~0.1 KB/keepalive
메시지 지연 p50/p99: 12ms / 45ms

WebSocket 보다 SSE 가 메모리 35-40% 적은 이유: SSE 는 HTTP 스택을 그대로 쓰므로 WebSocket 의 frame buffer + state machine + protocol framing metadata 같은 추가 자료구조가 필요 없다. 구조적으로 가벼움이지 최적화 결과가 아니다.

SSE 가 잘 맞는 시나리오

실시간 알림 (새 메시지, 댓글)
진행률 표시 (파일 처리, 빌드 로그)
주가/스코어 ticker
LLM 응답 스트리밍 (ChatGPT, Claude, Gemini 모두 SSE)

도메인당 6개 연결 한계의 메커니즘

브라우저는 같은 호스트(도메인+포트 조합)에 대해 동시 [[TCP]] 연결을 6~8개로 제한한다. 이 숫자는 표준이 아니라 브라우저 구현 기본값 (Chrome/Edge 6, Firefox 6, Safari 6).

이 한계가 SSE 에 특히 치명적인 이유:

SSE 한 stream = TCP 연결 1개를 영구 점유. 응답이 끝나지 않으므로 연결이 자유롭게 되지 않는다.
같은 호스트에 SSE 6개를 열면 7번째부터 다른 모든 요청 (이미지, API call, 다른 SSE) 도 큐에서 대기.
사용자가 같은 사이트를 여러 탭에 열면 각 탭이 자기 SSE 를 열려고 시도 → 7번째 탭부터 영구 대기 (탭이 안 보일 정도).

왜 6개 제한이 존재하나, 역사적 이유. HTTP/1.x 는 연결당 동시 하나의 요청만 처리 가능 (pipelining 실패). 만약 무제한이면 한 사용자가 서버 자원을 독점할 수 있어 RFC 2616 권장은 2개, 실무 브라우저는 6~8개로 절충.

해결책 3가지:

HTTP/2 이상으로 운영, 단일 TCP 연결에서 multiplexing 으로 6개 한계 완전 우회. 가장 권장.
여러 서브도메인 분산, sse1.example.com, sse2.example.com 등 (구식 해결책, 인증서/CORS 부담)
SharedWorker, 모든 탭이 공유하는 단일 worker 가 SSE 연결 1개만 유지, 메시지를 각 탭에 분배

[!TIP] 대부분의 모던 인프라(Cloudflare, AWS CloudFront, Vercel 등) 는 HTTP/2 또는 HTTP/3 를 기본 제공하므로 이 한계는 실무에서 거의 만나지 않는다. 단 사내 레거시 서버 / 일부 프록시 / Nginx 미튜닝 환경에서는 여전히 발생.

SSE 의 한계는 명확하다, 단방향이다. 양방향이 필요하면 다음 단계.

WebSocket, 한 번 열고 양방향

WebSocket 은 HTTP 핸드셰이크로 시작해서 프로토콜을 통째로 바꾸는 방식이다. 명확히 [[Stateful]] 통신.

핸드셰이크: HTTP Upgrade

GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

---
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

101 Switching Protocols 이후로는 같은 TCP 연결을 WebSocket frame 형식으로 사용한다. 더 이상 HTTP 가 아니다.

브라우저 API

const ws = new WebSocket('wss://example.com/chat');

ws.onopen = () => {
  ws.send('hello');
  ws.send(new Uint8Array([1, 2, 3]));
};

ws.onmessage = (e) => {
  if (typeof e.data === 'string') {
    console.log('text:', e.data);
  } else {
    console.log('binary:', e.data);
  }
};

ws.onclose = () => {
  // 자동 재연결 없음, 직접 처리
  setTimeout(connect, 1000);
};

Frame 구조

WebSocket 메시지는 frame 이라는 단위로 송수신된다. 한 frame 헤더는 2~14 bytes 로 매우 작다 (HTTP 헤더 수백 바이트와 대조). 작은 메시지를 자주 주고받기에 최적.

WebSocket 이 직접 처리해야 하는 것들

기능	SSE	WebSocket
자동 재연결	✓	✗ (직접 구현 또는 라이브러리)
마지막 이벤트 복원	✓ (Last-Event-ID)	✗
Heartbeat / Keep-alive	별도 ping 불필요	필요 (proxy timeout 방지)
메시지 직렬화	자동 (text)	직접 (JSON.stringify 등)

이래서 실무에서는 Socket.IO 같은 라이브러리를 자주 쓴다. 재연결, 룸/네임스페이스, 폴백, 메시지 ACK 등을 제공.

서버 구현 예시


const wss = new WebSocketServer({ port: 8080 });

wss.on('connection', (ws) => {
  ws.on('message', (data) => {
    wss.clients.forEach((client) => {
      if (client !== ws && client.readyState === ws.OPEN) {
        client.send(data);
      }
    });
  });

  // Keep-alive ping (proxy idle timeout 방지)
  const pingInterval = setInterval(() => {
    if (ws.readyState === ws.OPEN) ws.ping();
  }, 30000);
  ws.on('close', () => clearInterval(pingInterval));
});

WebSocket 의 부하 특성 (실측)

측정	값	출처
연결당 메모리 (raw ws)	~3.5 KB	Ark Protocol 2026
연결당 메모리 (Socket.IO)	~60-90 KB	Wolf-tech 2026
10K 동시 연결 총 메모리 (raw)	~400 MB	BirJob 2026
5K 동시 연결 (Socket.IO)	~400-500 MB	Wolf-tech 2026
100K 연결 (raw)	~342 MB	Ark Protocol c5.2xlarge
CPU idle (10K 연결)	5%	BirJob 2026
메시지 지연 p50/p99	8ms / 22ms	BirJob 2026

[[Stateful]] 의 진짜 비용은 메모리가 아니라 운영 복잡도다. 수평 확장하려면:

[[Sticky Session]]: 로드밸런서가 같은 클라이언트를 같은 서버로
[[Pub/Sub Bus]]: 서버 간 메시지 라우팅 (Socket.IO + Redis adapter)
Backpressure: 클라이언트가 느릴 때 서버 send buffer 가 차오름 → 명시적 관리

WebSocket 시나리오

채팅
협업 도구 (커서 위치, 실시간 편집)
게임 (실시간 입력)
거래 시스템

[!CAUTION] “양방향이니까 그냥 WebSocket 쓰자”는 흔한 함정이다. 단방향이면 SSE 가 훨씬 단순하고 부담이 적다. WebSocket 의 stateful 특성은 인프라 복잡도를 크게 늘린다.

WebRTC, 서버를 거치지 않는 P2P

WebRTC 는 두 브라우저가 서로 직접 연결되는 방식이다. 단, 만남 자체는 서버를 한 번 거쳐야 한다.

{}

세 가지 서버 역할

Signaling Server: 두 피어가 서로의 정보(SDP)를 주고받기 위한 통로
STUN Server: 각 피어가 자기의 공인 IP/포트를 알아내는 데 사용
TURN Server: 직접 연결 실패 시 데이터 중계

STUN 은 가볍지만 TURN 은 모든 데이터가 통과하므로 비용이 크다.

SDP Offer/Answer 교환

// Peer A (Caller)
const pc = new RTCPeerConnection({
  iceServers: [
    { urls: 'stun:stun.l.google.com:19302' },
  ],
});

const dataChannel = pc.createDataChannel('chat');
dataChannel.onopen = () => dataChannel.send('hello!');
dataChannel.onmessage = (e) => console.log('peer:', e.data);

const offer = await pc.createOffer();
await pc.setLocalDescription(offer);
signaling.send({ type: 'offer', sdp: offer });

signaling.on('answer', async ({ sdp }) => {
  await pc.setRemoteDescription(sdp);
});

pc.onicecandidate = (e) => {
  if (e.candidate) signaling.send({ type: 'ice', candidate: e.candidate });
};
signaling.on('ice', ({ candidate }) => pc.addIceCandidate(candidate));

DataChannel: SCTP over DTLS over UDP

RTCDataChannel 은 SCTP 를 사용한다. SCTP 는 다음을 설정할 수 있다:

ordered: 순서 보장 여부 (기본 true)
maxRetransmits: 재전송 횟수 (UDP 스타일은 0)
maxPacketLifeTime: 패킷 유효 시간

게임처럼 “약간 잃어도 좋으니 빠르게” 가 필요하면 unordered + maxRetransmits 0 (사실상 UDP)으로 설정. 파일 전송처럼 정확성이 중요하면 기본값.

모든 통신은 [[DTLS]] 로 자동 암호화된다, [[UDP]] 위에서 동작하는 [[TLS]] 변형.

WebRTC 부하 특성

시그널링 서버: 만남 단계만 부담 (수 kB SDP + 수 십개 ICE candidate 메시지)
STUN 서버: 매우 가벼움 (단순 응답)
TURN 서버: 통화 1쌍에 양방향 대역폭, 가장 비싼 인프라
클라이언트: ICE 후보 수집, 암호화/복호화, 미디어 인코딩

[!IMPORTANT] TURN 의존도가 높으면 서버 부담이 다시 커진다. 모바일 사용자가 많고 NAT 가 엄격한 환경(통신사망 뒤)에서는 50~80% 가 TURN 을 거친다는 보고도 있다. WebRTC 가 서버 비용을 0 으로 만들지는 않는다.

WebRTC 시나리오

영상/음성 통화
화면 공유
파일 직접 전송 (대용량을 서버 거치지 않고)
P2P 게임

WebTransport, HTTP/3 위의 양방향 stream (미래)

WebTransport 는 HTTP/3 [[QUIC]] 위에서 양방향 stream + datagram 을 제공하는 새 API.

const wt = new WebTransport('https://example.com/wt');
await wt.ready;

const stream = await wt.createBidirectionalStream();
const writer = stream.writable.getWriter();
await writer.write(new TextEncoder().encode('hello'));

const datagramWriter = wt.datagrams.writable.getWriter();
await datagramWriter.write(new Uint8Array([1, 2, 3]));

WebSocket 대비:

다중 stream: 한 연결에서 여러 독립 stream
Datagram: UDP 스타일 unreliable 전송도 가능
연결 마이그레이션: QUIC 의 성질 그대로

브라우저 지원이 아직 부분적이지만, WebSocket 의 후속으로 자리잡을 가능성이 크다.

벤치마크, 실측 차트

여기까지 본 부하 수치를 한눈에. 데이터는 BirJob 2026 c5.xlarge 10K 측정 + Ark Protocol 2026 c5.2xlarge 100K 측정 + Wolf-tech 2026 Next.js production 의 종합.

10,000 동시 연결에서 서버 메모리

연결당 메모리 오버헤드

CPU 사용량 (10K idle 연결)

메시지 지연 (p50 / p99)

차트의 한 줄 결론

메모리: Long Polling >> WebSocket(Socket.IO) > SSE > WebSocket(raw)
CPU: Long Polling >> SSE > WebSocket
지연: Long Polling은 사실상 실시간 X. SSE/WebSocket 만 실시간

벤치마크 코드는 별도 프로젝트로 분리, /Users/[user]/0099-web-comm-bench (Node.js + ws + 모든 4 가지 엔드포인트 + 5초 메모리 스냅샷).

종합 비교, 어디에 부하가 가나

방식	통신 주체	프로토콜	상태	클라이언트	서버	네트워크	부하 위치
HTTP/1.1/2/3	Client ↔ Server	TCP/UDP	[[Stateless]]	낮음	낮음	헤더 + RTT	서버 분산
Short Polling	Client → Server	HTTP	Stateless	낮음	중간	낭비 큼	서버 분산 (빈 응답)
Long Polling	Client → Server	HTTP	Stateless*	낮음	높음	효율적	서버 연결 풀
SSE	Server → Client	HTTP	[[Stateful]]	낮음	중간	효율적	서버 연결 + 6 연결 한계
WebSocket	Client ↔ Server	TCP frame	[[Stateful]]	중간	높음	매우 효율적	서버 메모리 + [[Sticky Session]]
WebRTC	Peer ↔ Peer	SCTP/DTLS/UDP	Stateful	높음	시그널링만	P2P 직접	클라이언트 + P2P, TURN 시 서버
WebTransport	Client ↔ Server	QUIC	Stateful	중간	중간	HTTP/3 효율	HTTP/3 인프라

*Long Polling 은 HTTP 의미상 Stateless 지만 운영상 연결 점유가 Stateful 과 비슷.

시나리오별 선택 가이드

시나리오	권장
REST API · 정적 자원	HTTP/2 또는 HTTP/3
알림 push (한쪽 방향)	SSE, 단순 + 자동 재연결
LLM 응답 스트리밍	SSE, 사실상 표준
채팅 (양방향)	WebSocket + 라이브러리
실시간 협업 (Figma, Notion)	WebSocket, CRDT/OT 메시지
게임 (실시간 입력)	WebSocket 또는 WebRTC DataChannel
영상/음성 통화	WebRTC
대용량 파일 P2P	WebRTC DataChannel
미래 지향 양방향 + datagram	WebTransport

잘못된 선택이 비용이 되는 패턴

“알림 받아야 하니까 WebSocket” → SSE 면 충분한데 인프라 복잡도 늘림
“채팅이니까 polling” → 클라이언트 100명 × 1초 polling = 서버 6000 RPS 빈 응답
“P2P니까 WebRTC” → 시그널링 + STUN/TURN 인프라가 의외로 큰 비용
“HTTP/3이 좋다니까 무조건 HTTP/3” → 사내망/특정 환경에선 UDP 가 막혀 fallback

정리

브라우저 통신은 한 방향으로 발전해왔다.

“요청-응답”이라는 HTTP의 본질적 제약을 어떻게 우회하느냐, 그리고 “서버에 얼마나 의존하느냐”

방식	우회 방법	서버 의존도
HTTP	우회 안 함	모든 트래픽
Polling	자주 요청	모든 트래픽 (낭비 많음)
Long Polling	응답 보류	모든 트래픽 (효율적)
SSE	응답을 영원히 안 끝냄	모든 트래픽 (단방향)
WebSocket	HTTP 졸업, 양방향 프로토콜	모든 트래픽
WebRTC	만남만 서버, 데이터는 P2P	시그널링만
WebTransport	HTTP/3 위 다중 stream	모든 트래픽 (효율적)

선택은 결국 “부하를 어디에 두고 싶은가”의 문제다.

[!IMPORTANT] “최신이니까 좋다”는 함정이다. WebSocket 한 줄로 끝낼 알림을 WebRTC 로 만들면 운영 비용이 10 배로 늘 수 있다. 반대로 영상 통화를 WebSocket 으로 만들면 서버 대역폭이 폭발한다.

요구사항 → [[Stateless]] vs [[Stateful]] 결정 → 데이터 흐름 방향 → 부하 위치 선택 → 통신 방식 결정 순서로 생각하면 거의 틀리지 않는다.

ℹ️ 이 글은 MDN Web Docs, RFC (HTTP/2 RFC 7540, HTTP/3 RFC 9114, WebSocket RFC 6455, [[QUIC]] RFC 9000, [[HPACK]] RFC 7541), web.dev 의 WebRTC 문서, 그리고 2026년 실측 벤치마크 자료(BirJob, Ark Protocol, Wolf-tech)를 참조하여 AI(Claude)와 함께 작성 되었습니다.

참고 자료

비동기와 타이밍, 콜백부터 async/await까지의 발전사

koa (김신건) — Mon, 15 Jun 2026 00:00:00 GMT

시작 의문

다음 코드의 출력 순서를 맞춰보자.

console.log('A');

setTimeout(() => console.log('B'), 0);

Promise.resolve().then(() => console.log('C'));

console.log('D');

직관적으로는 A B C D 일 것 같다. setTimeout(fn, 0) 은 “0 밀리초 뒤”라고 했으니 바로 다음 줄로 가야 자연스럽다. 그런데 실제 출력은:

A
D
C
B

B 가 가장 늦게 찍힌다. Promise.then 으로 등록한 C 가 setTimeout 0 으로 등록한 B 보다 먼저다. 그리고 동기 코드인 A, D 는 둘 다 비동기보다 먼저다.

세 가지 질문이 떠오른다.

JavaScript 는 싱글 스레드라는데, 어떻게 setTimeout 과 Promise 가 “동시에” 진행되는가?
setTimeout(fn, 0) 은 왜 즉시가 아닌가? 0 밀리초인데도 왜 그렇게 느린가?
같은 비동기인데 왜 Promise 가 setTimeout 보다 항상 먼저 실행되는가?

답을 한 줄로 던지면 “이벤트 루프와 두 종류의 큐 때문” 으로 끝난다. 하지만 어떻게 그렇게 되는지를 이해하려면 한 단계 더 들어가야 한다. 이 글은 콜 스택·Web API·태스크 큐·마이크로태스크 큐 네 개념을 쌓아 세 질문 모두에 답하고, 거기서 자라난 콜백 → Promise → async/await 의 발전사와 fetch + AbortController, Generator/AsyncIterator, queueMicrotask/requestAnimationFrame 같은 현대적 도구까지 한 흐름으로 풀어보는 것을 목표로 한다.

먼저 가장 기초적인 곳부터.

한 단계 뒤로, JavaScript 는 왜 비동기가 필요한가

싱글 스레드의 본질

JavaScript 엔진은 한 번에 한 줄씩만 실행한다. 함수 호출 하나가 끝나야 다음 줄이 진행된다. 이를 싱글 스레드 (single-threaded) 라고 한다. 이는 V8, SpiderMonkey, JavaScriptCore 모든 주류 엔진의 공통 약속이다.

왜 싱글 스레드인가? JavaScript 가 1995 년 Brendan Eich 에 의해 10 일 만에 만들어졌을 때 주된 용도는 “브라우저에서 사용자 클릭에 반응하기” 였다. 화면 갱신과 동시에 두 스크립트가 같은 DOM 노드를 수정한다면 결과가 비결정적 (race condition) 이 된다. 단순함과 안전을 위해 의도적으로 싱글 스레드를 선택했다.

이게 무슨 뜻인지 코드로 보자.

function blocking() {
  const start = Date.now();
  while (Date.now() - start < 3000) {
    // 3초간 CPU 점유
  }
  console.log('done');
}

console.log('A');
blocking();
console.log('B'); // 3초 뒤에 찍힘

blocking() 이 도는 3 초 동안 그 어떤 코드도 실행되지 않는다. 브라우저 환경이라면 페이지가 얼어붙는다. 클릭, 스크롤, 애니메이션 모두 멈춘다.

그런데 우리는 동시에 여러 일을 본다

브라우저를 켜면 다음이 동시에 일어난다.

네트워크에서 데이터 받기 (수십~수천 밀리초)
사용자가 스크롤 / 클릭 / 타이핑
매 16ms 마다 화면 다시 그리기 (60fps)
타이머 카운트다운
백그라운드 작업

JavaScript 가 진짜로 한 번에 한 줄만 한다면 이게 가능할 리 없다. 어디서 이 동시성이 나오는가?

답은 JavaScript 엔진은 싱글 스레드지만, 그것을 실행하는 호스트 환경 (브라우저, Node.js) 은 멀티 스레드 라는 것이다. 엔진은 “지금 당장 실행할 코드 한 줄” 만 처리하고, 시간이 걸리는 작업 (네트워크, 타이머, 파일 I/O) 은 호스트 환경이 백그라운드 스레드로 처리한 뒤 결과만 큐에 넣어준다.

엔진은 그 큐를 무한 루프로 감시하다가, 자기가 한가해지면 큐에서 하나씩 꺼내 실행한다. 이 무한 루프가 곧 [[이벤트 루프]] (Event Loop) 다.

차근차근 그림으로

이게 우리가 곧 만나게 될 그림이다. 익숙해질 때까지 머릿속에 두자.

{}

네 개의 구성요소가 있다.

구성요소	역할	누가 관리?
Call Stack (콜 스택)	지금 실행 중인 함수들	JavaScript 엔진
Web API (또는 Node.js API)	타이머, fetch, DOM 이벤트 등	호스트 환경 (브라우저 / Node)
Task Queue (매크로태스크 큐)	`setTimeout`, DOM 이벤트, `setInterval` 콜백	호스트 + 이벤트 루프
Microtask Queue (마이크로태스크 큐)	`Promise.then`, `queueMicrotask`, `MutationObserver`	JS 엔진 (ECMAScript 명세)

이벤트 루프의 알고리즘은 단순하다.

while (true) {
  if (콜 스택이 비어있으면) {
    마이크로태스크 큐를 비울 때까지 전부 실행
    태스크 큐에서 한 개 꺼내서 실행
    (필요하면 렌더링)
  }
}

이 5 줄짜리 루프가 JavaScript 의 모든 비동기 동작을 떠받친다. 세 질문의 답도 여기서 자라난다.

타이밍의 시작, setTimeout 과 setInterval

비동기를 가장 먼저 만나는 곳은 타이머 API 다. [[setTimeout]], [[setInterval]] 두 함수를 보자. (문법과 함정에 대한 상세는 각 위키 페이지 참고.)

setTimeout, 한 번만 실행

setTimeout(callback, delay) 은 “최소 delay 밀리초 뒤에 callback 을 태스크 큐에 넣어달라” 는 요청이다.

<CodeWithOutput title=“setTimeout 기본 동작” language=“javascript” label=“브라우저 콘솔” outputLabel=“출력” code={`console.log(‘A’);

setTimeout(() => { console.log(‘B’); }, 1000);

console.log(‘C’);} output={A C B // 약 1초 뒤`} />

{}

세 가지 포인트:

“최소” 다. 정확히 delay 밀리초가 아니라 “최소 그만큼 뒤” 다. 콜 스택이 비어있어야만 실행된다. 콜 스택에 무거운 작업이 있으면 5초 지연으로 등록한 타이머도 10 초 뒤에야 실행될 수 있다.
반환값은 타이머 ID. clearTimeout(id) 로 취소 가능.
콜백은 그 자체가 [[클로저]]. 등록 시점의 변수를 들고 다닌다.

setTimeout(fn, 0) 은 즉시가 아니다

{}

가장 헷갈리는 부분이다.

<CodeWithOutput title=“setTimeout 0 의 진실” language=“javascript” code={`console.log(‘1’); setTimeout(() => console.log(‘2’), 0); console.log(‘3’);

// 동기 코드를 무겁게 만들면? const start = Date.now(); while (Date.now() - start < 100) {}

console.log(‘4’);} output={1 3 4 2 // 100ms+ 뒤에 출력`} />

setTimeout(fn, 0) 의 fn 은 즉시가 아니라, 현재 동기 코드가 모두 끝나고, 마이크로태스크 큐도 다 비고, 그 다음 태스크 큐 차례가 와야 실행된다.

여기에 더해 HTML 명세는 중첩 5회 이상의 setTimeout 에 대해 최소 4ms 지연 을 강제한다 (WHATWG HTML §8.1.7.4). 즉 setTimeout(() => setTimeout(() => setTimeout(...))) 처럼 깊게 중첩되면 자동으로 4ms 가 깔린다.

[!IMPORTANT] setTimeout(fn, 0) 의 진짜 의미는 “다음 이벤트 루프 틱에 양보하라” 다. 즉시 실행이 아니라 “동기 작업을 먼저 끝내고 큐에 다시 들어가라” 라는 스케줄링 힌트.

이 트릭은 무거운 동기 작업을 잘게 쪼개 UI 가 응답하게 만드는 데 자주 쓰인다.

// 1억 번 루프, 한 번에 돌리면 UI 멈춤
function processInChunks(items, processor) {
  let i = 0;
  function next() {
    const start = Date.now();
    while (i < items.length && Date.now() - start < 50) {
      processor(items[i++]);
    }
    if (i < items.length) {
      setTimeout(next, 0); // 50ms 마다 UI 에 양보
    }
  }
  next();
}

setInterval, 반복 실행

setInterval(callback, delay) 은 “매 delay 밀리초마다 callback 을 태스크 큐에 넣어달라” 는 요청이다.

<CodeWithOutput title=“setInterval 기본” language=“javascript” code={let count = 0; const id = setInterval(() => { console.log(\tick ${++count}`); if (count === 3) clearInterval(id); }, 1000);} output={tick 1 // 1초 뒤 tick 2 // 2초 뒤 tick 3 // 3초 뒤 (이후 멈춤)`} />

문제는 콜백 실행 시간이 interval 보다 길어지면 큐에 쌓인다는 점 이다.

setInterval(() => {
  // 1500ms 걸리는 작업
  const start = Date.now();
  while (Date.now() - start < 1500) {}
  console.log('done');
}, 1000);
// → 1초마다 큐에 등록되지만 한 번에 1.5초 걸림
// → 큐가 무한히 쌓이거나, 브라우저가 자동으로 누락

{}

이를 피하려면 setTimeout 으로 자기 자신을 재호출하는 패턴이 더 안전하다.

function poll() {
  doWork();
  setTimeout(poll, 1000); // 작업 끝난 뒤 다음 호출 예약
}
poll();

이 패턴은 [[Polling]] 의 기본 형태이기도 하다.

정리, 타이머가 던지는 두 가지 메시지

“즉시” 라는 단어는 존재하지 않는다. 모든 비동기 콜백은 큐를 거쳐 콜 스택이 빌 때까지 기다린다.
타이머는 정확한 시각을 보장하지 않는다. 최소 지연을 보장할 뿐.

이 두 메시지가 비동기의 모든 함정의 출발점이다.

콜백, 첫 번째 시도

타이머처럼 비동기 결과를 받는 가장 원시적인 방법은 콜백 함수 (callback) 다.

콜백이 뭐다?

함수를 다른 함수의 인자로 넘기면, 받은 쪽이 “내가 끝나면 너를 호출할게” 라고 약속한다. 이때 넘긴 함수가 [[콜백]] 이다. 일급 함수 ([[일급 함수]]) 가 JS 의 기본이라 자연스럽게 가능한 패턴.

// 비동기 작업: 1초 뒤에 데이터 전달
function loadUser(userId, callback) {
  setTimeout(() => {
    const user = { id: userId, name: 'Alice' };
    callback(null, user); // (error, result) 관행
  }, 1000);
}

loadUser(42, (err, user) => {
  if (err) {
    console.error(err);
    return;
  }
  console.log(user.name); // 'Alice'
});

{}

Node.js 가 채택한 “에러 우선 콜백 (error-first callback)” 규칙은 첫 인자가 에러, 두 번째가 결과. 같은 약속을 모두가 지키면 코드를 읽을 수 있다.

그런데 두 개를 순서대로 하려면?

사용자를 받아오고, 그 사용자의 게시물을 받아오고, 게시물에 달린 댓글을 받아오고, 댓글 작성자 프로필을 받아오고…

<CodeWithOutput title=“콜백 지옥 (callback hell)” language=“javascript” code={loadUser(42, (err, user) => { if (err) return console.error(err); loadPosts(user.id, (err, posts) => { if (err) return console.error(err); loadComments(posts[0].id, (err, comments) => { if (err) return console.error(err); loadProfile(comments[0].authorId, (err, profile) => { if (err) return console.error(err); console.log(profile.name); }); }); }); });} output={(4단계 모두 성공 시 profile.name 출력)} />

{}

들여쓰기가 오른쪽 끝까지 밀려난다. [[콜백 지옥]] 으로 불리는 이 문제는 단순히 가독성만의 문제가 아니다.

[!CAUTION] 콜백 지옥의 진짜 문제는 에러 처리 다. 매 단계마다 if (err) return 을 빠뜨리면 그대로 무시된다. try/catch 도 통하지 않는다, 콜백이 호출되는 시점에는 등록한 콜 스택이 이미 사라졌기 때문이다.

콜백이 가진 또 다른 함정, 인버전 오브 컨트롤

콜백을 넘기는 순간, 호출자는 제어권을 상대 함수에게 넘긴다.

thirdPartyApi.fetch(url, (data) => {
  saveToDb(data);
});

thirdPartyApi.fetch 는 콜백을:

호출하지 않을 수도 (조용히 실패)
여러 번 호출할 수도 (saveToDb 가 두 번 실행됨)
즉시 동기로 호출할 수도 (콜 스택 상태가 호출자 기대와 다름)
너무 늦게 호출할 수도

이 모든 불확실성을 호출자가 흡수해야 한다. 약속 (promise) 이 더 강한 보장을 줄 수 있다면 좋을 텐데, 라는 갈증이 다음 발전의 동기가 된다.

resolve 와 reject, 봐도 봐도 헷갈리는 그것

Promise 본격 도입 전에, 가장 헷갈리는 부분을 먼저 정리하자. resolve, reject 가 누구 손에 있는가 의 문제다.

velog 의 한 글 (봐도 봐도 헷갈리는 resolve, reject) 이 잘 표현한 것처럼, 비동기 코드에는 두 입장이 공존한다.

두 입장

요청하는 쪽: 비동기 결과를 기다리는 입장. loadUser(42, callback) 의 callback 을 쓰는 쪽.
처리하는 쪽: 비동기 작업을 수행하고 결과를 알려주는 입장. loadUser 내부 구현.

콜백 패턴에서는 이 두 입장이 같은 함수 인자 (callback(err, data)) 로 표현된다. 위치가 곧 의미였다, 1번 자리는 에러, 2번 자리는 데이터.

Promise 는 이 둘을 명시적으로 분리 한다.

function loadUser(userId) {
  // 처리하는 쪽
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      if (!userId) {
        reject(new Error('userId 필수'));    // 실패
      } else {
        resolve({ id: userId, name: 'Alice' }); // 성공
      }
    }, 1000);
  });
}

// 요청하는 쪽
loadUser(42)
  .then((user) => console.log(user.name))
  .catch((err) => console.error(err));

{}

처리하는 쪽이 보는 것: resolve / reject 두 함수. 둘 중 하나를 호출하면 자기 일은 끝.

요청하는 쪽이 보는 것: .then / .catch 두 메서드. 결과가 오면 이 두 곳 중 하나로 흘러온다.

[!TIP] resolve = “이게 결과야”, reject = “이게 사유야”. 둘 중 하나만 호출하면 된다. 둘 다 호출해도 두 번째 호출은 조용히 무시 된다 (한 번 정착된 Promise 는 상태가 바뀌지 않는다).

처리하는 쪽 / 요청하는 쪽 분리의 가치

콜백에서는 호출자 가 “에러 위치를 첫 번째 인자로 받겠다” 같은 관행을 기억해야 했다. Promise 에서는 언어 차원에서 두 경로가 분리 된다. 잘못 쓸 수가 없다.

이게 Promise 가 단순히 콜백 지옥을 푸는 도구를 넘어, 에러 처리의 기본 구조를 바꾼 진짜 이유다.

Promise, 상태 기반 처리

이제 Promise 자체를 들여다보자.

Promise 의 세 가지 상태

{}

[[Promise]] 객체는 단 세 가지 상태 중 하나에 있다.

상태	의미	어떻게 들어가는가
pending	대기	`new Promise(...)` 직후
fulfilled	이행 (성공)	executor 가 `resolve(value)` 호출
rejected	거부 (실패)	executor 가 `reject(reason)` 호출, 또는 예외 throw

핵심 규칙: 한 번 fulfilled 또는 rejected 가 되면 다시는 바뀌지 않는다. 이 불변성을 [[settled]] 라고 부른다. Promise 가 콜백보다 안전한 핵심 이유다, 한 번 정착하면 끝, 두 번 호출되거나 호출 안 되는 일이 없다.

직접 만들어보기

<CodeWithOutput title=“Promise 생성과 사용” language=“javascript” code={`function loadUser(userId) { return new Promise((resolve, reject) => { console.log(‘Promise 생성, 상태: pending’); setTimeout(() => { if (userId > 0) { resolve({ id: userId, name: ‘Alice’ }); } else { reject(new Error(‘Invalid ID’)); } }, 500); }); }

const p = loadUser(42); console.log(‘p =’, p);

p.then((user) => { console.log(‘상태: fulfilled, value =’, user); });} output={Promise 생성, 상태: pending p = Promise { } 상태: fulfilled, value = { id: 42, name: ‘Alice’ }`} />

new Promise(executor) 의 executor 는 동기적으로 즉시 실행 된다. 그 안에서 setTimeout 같은 비동기 작업을 시작하고, 결과가 나오면 resolve / reject 를 호출한다.

[!IMPORTANT] .then 의 콜백은 결코 동기적으로 실행되지 않는다. 이미 fulfilled 된 Promise 에 .then 을 붙여도, 그 콜백은 마이크로태스크 큐를 거쳐 다음 틱에 실행된다. 이 보장 덕에 “어떨 땐 동기, 어떨 땐 비동기” 같은 인버전 오브 컨트롤이 사라진다.

.then, .catch, .finally 세 가족

메서드	받는 콜백	반환	언제 호출?
`.then(onFulfilled, onRejected?)`	두 개 (선택적)	새 Promise	fulfilled 시 1번, rejected 시 2번 (있다면)
`.catch(onRejected)`	한 개	새 Promise	rejected 시 (사실은 `.then(undefined, fn)` 의 별칭)
`.finally(onFinally)`	한 개 (인자 없음)	새 Promise	fulfilled/rejected 모두

.then 이 항상 새 Promise 를 반환 하기 때문에 체이닝이 가능하다.

loadUser(42)
  .then((user) => user.id)         // 다음 then 에 42 전달
  .then((id) => fetchPosts(id))    // Promise 반환 → 자동 unwrap
  .then((posts) => posts.length)
  .then((count) => console.log(count))
  .catch((err) => console.error(err))
  .finally(() => console.log('done'));

{}

콜백 지옥의 들여쓰기가 사라지고 평탄한 (flat) 흐름 으로 바뀐다.

catch vs then 의 두 번째 인자

.then 은 두 번째 인자로도 에러 핸들러를 받지만, 함정이 있다.

<CodeWithOutput title=“.then(onFulfilled, onRejected) 의 함정” language=“javascript” code={Promise.resolve('hi') .then( (value) => { console.log(value); throw new Error('oops'); }, (err) => { console.log('잡힘?', err); // ← 잡힐까? } );} output={hi (Uncaught Promise Error: oops) // 두 번째 인자는 같은 then 의 onFulfilled 에서 던진 에러를 못 잡는다} />

onRejected 는 이전 단계 의 에러만 잡는다. 자기 자신과 짝지어진 onFulfilled 에서 던진 에러는 못 잡는다.

.catch 는 별도 단계이므로 이전 모든 .then 의 에러를 모두 잡는다.

[!TIP] .catch 가 권장된다. 자기 단계의 에러도, 이전 모든 단계의 에러도 잡을 수 있다. 캡틴판교 (Promise 쉽게 이해하기) 의 결론도 같다.

체이닝의 진짜 메커니즘

.then 의 콜백이 반환하는 값에 따라 다음 단계에 들어가는 값이 결정된다.

반환	다음 then 의 입력
일반 값 `x`	`x` 를 fulfilled value 로 가진 새 Promise
Promise `p`	`p` 가 정착할 때까지 기다린 뒤 그 값으로
Thenable 객체	Promise 처럼 풀어서 처리
예외 throw	rejected Promise

이게 인파님이 정리한 “프로미스 체이닝” 의 핵심 메커니즘이다, .then 의 반환값은 자동으로 Promise 로 감싸진다. 그래서 .then().then().then() 이 평탄하게 이어진다.

Promise 도 지옥이 될 수 있다

장점만 있을 리 없다.

fetch('/api/users')
  .then((r) => r.json())
  .then((users) => {
    return fetch(`/api/posts?user=${users[0].id}`)
      .then((r) => r.json())
      .then((posts) => {
        return fetch(`/api/comments?post=${posts[0].id}`)
          .then((r) => r.json())
          .then((comments) => {
            console.log(comments);
          });
      });
  });

.then 안에서 또 .then 을 중첩하면 결국 콜백 지옥의 사촌인 Promise 지옥 이 된다. 평탄하게 펴는 게 핵심.

fetch('/api/users')
  .then((r) => r.json())
  .then((users) => fetch(`/api/posts?user=${users[0].id}`))
  .then((r) => r.json())
  .then((posts) => fetch(`/api/comments?post=${posts[0].id}`))
  .then((r) => r.json())
  .then((comments) => console.log(comments));

그래도 가독성이 100% 만족스럽진 않다. 이 마지막 한 걸음이 async/await 이다.

async/await, Promise 의 문법 설탕

한 키워드로 동기처럼

ES2017 이 도입한 async, await 키워드는 Promise 기반 코드를 마치 동기 코드처럼 쓸 수 있게 해준다. 본질은 동일한 Promise, 문법만 다르다.

<CodeWithOutput title=“Promise vs async/await” variants={[ { language: ‘javascript’, label: ‘Promise 체이닝’, code: fetch('/api/users') .then((r) => r.json()) .then((users) => fetch(\/api/posts?u=${users[0].id}`)) .then((r) => r.json()) .then((posts) => console.log(posts)) .catch((err) => console.error(err)); }, { language: 'javascript', label: 'async / await', code:async function loadData() { try { const userRes = await fetch(‘/api/users’); const users = await userRes.json(); const postRes = await fetch(`/api/posts?u=${users[0].id}`); const posts = await postRes.json(); console.log(posts); } catch (err) { console.error(err); } } loadData(); } ]} outputLabel="동작" output={(둘 다 동일하게 동작, 에러는 catch 에서 잡힘)`} />

{}

세 가지 규칙:

async 함수는 항상 Promise 를 반환. 명시적으로 return 한 값이 resolve 된다.
await 는 오른쪽 Promise 가 정착할 때까지 함수 실행을 일시정지. 단, 함수 밖의 동기 코드는 계속 실행된다.
에러는 try/catch 로. Promise 의 .catch 와 정확히 같은 의미.

await 의 진짜 동작

await 는 사실 .then 의 문법 설탕이다. 다음 두 코드는 동치.

// async/await
async function foo() {
  const a = await loadA();
  const b = await loadB(a);
  return b;
}

// Promise 로 풀어보면
function foo() {
  return loadA().then((a) => {
    return loadB(a).then((b) => {
      return b;
    });
  });
}

엔진 안에서 await 는 이렇게 동작한다.

오른쪽 표현식을 평가, Promise 가 아니면 Promise.resolve 로 감싼다.
함수 상태 (지역 변수, 다음 실행 위치) 를 [[Lexical Environment]] 에 저장.
Promise 가 정착하면 마이크로태스크 큐에 “함수 재개” 를 등록.
이벤트 루프가 그 마이크로태스크를 꺼내 함수를 이어 실행.

[!IMPORTANT] await 는 “Promise 의 마이크로태스크 등록 + 함수 일시정지” 다. 그래서 await 이후 코드는 항상 다음 마이크로태스크 틱에 실행 된다. 동기 코드보다 늦고, setTimeout 보다 빠르다.

async 함수도 항상 Promise

async function answer() {
  return 42;
}

const p = answer();
console.log(p);          // Promise { 42 }
console.log(await p);    // 42

이 보장이 좋은 점은 모든 async 함수가 동일한 타입을 반환 한다는 것이다. 호출자는 “이게 Promise 일까 값일까” 를 고민하지 않아도 된다.

한 가지 함정, 순차 vs 병렬

// 순차, 총 2초
const a = await fetch('/a'); // 1초
const b = await fetch('/b'); // 1초

// 병렬, 총 1초
const [a, b] = await Promise.all([
  fetch('/a'),
  fetch('/b'),
]);

await 를 무지성으로 줄 세우면 병렬로 할 수 있는 일도 순차 가 된다. 의존성이 없는 작업은 Promise.all 로 묶자.

동시성 제어, Promise 의 정적 메서드 네 형제

여러 Promise 를 한꺼번에 다룰 때 쓰는 네 메서드를 차례로 보자.

Promise.all, 모두 성공해야 성공

배열의 모든 Promise 가 fulfilled 되면 그 값들의 배열로 fulfilled. 하나라도 rejected 되면 즉시 rejected.

<CodeWithOutput title=“Promise.all” language=“javascript” code={const results = await Promise.all([ fetch('/api/users').then(r => r.json()), fetch('/api/posts').then(r => r.json()), fetch('/api/comments').then(r => r.json()), ]); // results = [users, posts, comments] console.log(results[0].length);} outputLabel=“동작” output={(3개 fetch 가 병렬로 시작, 모두 끝나면 결과 배열) (하나라도 실패하면 즉시 throw)} />

{}

[!CAUTION] Promise.all 은 일찍 끝난 성공을 버린다. 두 번째 fetch 가 실패하면 첫 번째와 세 번째가 성공했어도 결과를 받을 수 없다. “전부 또는 무” 의미가 필요할 때만 쓰자.

Promise.allSettled, 결과를 다 보고 싶을 때

ES2020 에 추가된 신상. 모든 Promise 가 정착할 때까지 기다린 뒤, 각 결과의 상태와 값 을 담은 배열을 반환.

<CodeWithOutput title=“Promise.allSettled” language=“javascript” code={`const results = await Promise.allSettled([ fetch(‘/api/users’), fetch(‘/api/posts’), fetch(‘/broken-url’), ]);

results.forEach((r, i) => { if (r.status === ‘fulfilled’) { console.log(`${i}: ok`); } else { console.log(`${i}: failed -`, r.reason.message); } });} outputLabel="출력" output={0: ok 1: ok 2: failed - fetch failed`} />

각 항목은 { status: 'fulfilled', value } 또는 { status: 'rejected', reason } 형태. 부분 실패가 자연스러운 작업 (배치 알림 발송, 여러 API 동시 시도) 에 적합.

Promise.race, 가장 먼저 정착한 것

성공/실패 무관하게 가장 먼저 정착한 Promise 의 결과를 그대로 반환.

// 타임아웃 패턴
function timeout(ms) {
  return new Promise((_, reject) => {
    setTimeout(() => reject(new Error('timeout')), ms);
  });
}

const result = await Promise.race([
  fetch('/api/slow'),
  timeout(3000),
]);
// 3초 안에 fetch 가 끝나면 result, 아니면 throw

{}

Promise.any, 하나만 성공하면 OK

ES2021. 하나라도 fulfilled 되면 그 값으로 fulfilled. 모두 rejected 되면 AggregateError 로 rejected.

// 여러 CDN 미러 중 하나라도 응답하면 OK
const data = await Promise.any([
  fetch('https://mirror1/data'),
  fetch('https://mirror2/data'),
  fetch('https://mirror3/data'),
]);

{}

네 형제 비교

메서드	언제 fulfilled	언제 rejected	결과
`Promise.all`	모두 fulfilled	하나라도 rejected	값 배열 / 첫 rejection
`Promise.allSettled`	모두 정착 (성공/실패 무관)	절대 안 됨	`{ status, value/reason }` 배열
`Promise.race`	가장 먼저 fulfilled	가장 먼저 rejected	가장 먼저 정착한 값/사유
`Promise.any`	하나라도 fulfilled	모두 rejected	첫 fulfilled / AggregateError

[!TIP] 실무에서 가장 자주 잘못 쓰는 게 Promise.all 이다. 일부 실패를 허용해야 한다면 allSettled, 응답이 빠른 쪽이 중요하다면 race 또는 any 를 떠올리자.

마이크로태스크 vs 매크로태스크, 우선순위의 비밀

이제 글머리의 첫 질문으로 돌아갈 차례. 왜 Promise.then 이 setTimeout 0 보다 항상 먼저 인가?

{}

이벤트 루프의 한 틱

이벤트 루프가 한 사이클 (틱) 을 도는 알고리즘을 좀 더 정확하게 보자.

한 틱:
  1. 태스크 큐에서 한 개 꺼내 실행 (예: setTimeout 콜백)
     - 콜 스택이 빌 때까지 계속
  2. 마이크로태스크 큐를 비울 때까지 *전부* 실행
     - 마이크로태스크 안에서 새 마이크로태스크를 등록해도 같은 틱 안에서 실행
  3. 필요하면 렌더링 (브라우저)
  4. 다음 틱으로

핵심: 한 틱에 태스크 큐는 한 개 만 처리하지만, 마이크로태스크 큐는 완전히 비울 때까지 처리한다. 그래서 마이크로태스크가 항상 다음 매크로태스크보다 먼저다.

실제로 분석해보기

처음의 코드를 다시 보자.

<CodeWithOutput title=“시작 의문의 코드, 다시” language=“javascript” code={console.log('A'); setTimeout(() => console.log('B'), 0); Promise.resolve().then(() => console.log('C')); console.log('D');} output={A D C B} />

이벤트 루프의 눈으로 한 줄씩 따라가보자.

단계	상태	출력
1. `console.log('A')`	콜 스택, 동기 실행	A
2. `setTimeout(B, 0)` 등록	Web API → 0ms 뒤 태스크 큐에 B
3. `Promise.resolve().then(C)` 등록	즉시 마이크로태스크 큐에 C
4. `console.log('D')`	콜 스택, 동기 실행	D
5. 동기 코드 종료, 콜 스택 빔	,
6. 마이크로태스크 큐 비우기	C 실행	C
7. 태스크 큐에서 한 개 꺼냄	B 실행	B

[!IMPORTANT] 마이크로태스크는 “이번 동기 작업이 끝나자마자 즉시”, 매크로태스크는 “다음 이벤트 루프 틱에 한 개씩”. 그래서 Promise.then 이 setTimeout 0 보다 항상 빠르다.

await 도 마이크로태스크다

async function chain() {
  console.log('1');
  await Promise.resolve();
  console.log('2'); // 마이크로태스크
  await Promise.resolve();
  console.log('3'); // 또 마이크로태스크
}

console.log('start');
chain();
console.log('end');
// → start, 1, end, 2, 3

await 가 만나면 함수 실행이 일시정지되고, “재개” 가 마이크로태스크 큐에 들어간다. 그래서 end 가 먼저, 그 다음 2, 3 이 차례로 찍힌다.

마이크로태스크의 폭주 함정

마이크로태스크는 “큐를 완전히 비울 때까지” 처리하기 때문에, 마이크로태스크 안에서 또 마이크로태스크를 무한히 등록하면 렌더링과 매크로태스크가 영원히 못 돈다.

매크로태스크로 같은 일을 하면 매 틱마다 한 번씩만 실행되므로 렌더링이 끼어들 수 있다.

function loop() {
  setTimeout(loop, 0); // 매 틱마다 한 번씩
}
loop();
// → CPU 는 바쁘지만 렌더링과 이벤트는 동작

{}

이게 무거운 작업을 잘게 쪼갤 때 setTimeout 을 쓰는 이유이기도 하다.

queueMicrotask, 직접 등록하기

ES2020 에 추가된 queueMicrotask(fn) 은 Promise 없이 마이크로태스크를 등록할 수 있게 해준다.

queueMicrotask(() => console.log('이번 동기 작업 끝나면 즉시'));

Promise.resolve().then(fn) 보다 의도가 명확하고, Promise 객체 생성 비용도 없다. 라이브러리 내부에서 “다음 마이크로태스크에 실행” 을 명시할 때 쓴다.

fetch 와 AbortController, 비동기 작업의 취소

Promise 와 async/await 가 자리 잡으면서 자연스럽게 마주치는 다음 문제는 취소 다. 사용자가 검색어를 빠르게 입력하면 이전 fetch 요청은 더 이상 필요 없다. 어떻게 멈출까?

AbortController 의 기본

ES2017 (DOM 표준) 에 도입된 [[AbortController]] 는 비동기 작업에 취소 신호 (signal) 를 전달하는 표준 메커니즘이다.

<CodeWithOutput title=“fetch + AbortController” language=“javascript” code={`const controller = new AbortController(); const signal = controller.signal;

// 5초 뒤 자동 취소 setTimeout(() => controller.abort(), 5000);

try { const res = await fetch(‘/api/slow’, { signal }); const data = await res.json(); console.log(data); } catch (err) { if (err.name === ‘AbortError’) { console.log(‘취소됨’); } else { console.error(err); } }} outputLabel="시나리오별" cases={[ { label: '5초 내 응답 옴', output: (data 출력)}, { label: '5초 넘김', output:취소됨` }, ]} />

{}

구조 는 단순하다.

new AbortController() 로 컨트롤러 생성.
controller.signal 을 비동기 함수에 전달.
취소가 필요하면 controller.abort() 호출.
받는 쪽은 AbortError (혹은 DOMException) 로 reject.

검색 자동완성에 적용

가장 흔한 사용 사례. 사용자가 타이핑할 때마다 이전 요청을 취소.

let currentController = null;

async function search(query) {
  // 이전 요청 취소
  if (currentController) currentController.abort();

  currentController = new AbortController();
  try {
    const res = await fetch(`/api/search?q=${query}`, {
      signal: currentController.signal,
    });
    showResults(await res.json());
  } catch (err) {
    if (err.name !== 'AbortError') throw err;
    // AbortError 는 정상, 더 새로운 요청이 있다는 뜻
  }
}

input.addEventListener('input', (e) => search(e.target.value));

[!TIP] AbortController 는 fetch 전용이 아니다. 모든 비동기 API 가 받을 수 있는 표준 이다. Node.js 의 fs/promises, setTimeout (Node 16+), EventTarget.addEventListener 등 점점 더 많은 곳에서 { signal } 을 받는다.

setTimeout 도 취소할 수 있다 (Node 16+)


const controller = new AbortController();
setTimeout(() => controller.abort(), 1000);

try {
  await setTimeout(5000, undefined, { signal: controller.signal });
  console.log('5초 후 도착');
} catch (err) {
  if (err.name === 'AbortError') console.log('1초 뒤 취소됨');
}

타이머도 Promise 기반 + 취소 가능한 시대.

Generator 와 AsyncIterator, 흐름을 일시정지하는 또 다른 길

Promise 와 async/await 외에도 JS 에는 비동기 흐름을 다루는 다른 도구가 있다. Generator 와 AsyncIterator 다.

Generator, 한 번에 한 값씩

function* 으로 선언한 함수 ([[function]] 의 확장 문법) 는 호출 시 즉시 실행되지 않고, 이터레이터 를 반환한다. yield 키워드로 실행을 일시정지하고 값을 흘려보낸다.

일반 [[function]] 과 [[arrow function]] 의 본질적 차이 (특히 this 바인딩) 는 비동기 콜백에서 자주 함정이 된다. 두 형태의 정확한 차이는 각 위키 참고.

Generator 가 흥미로운 점은 무한 시퀀스를 메모리 효율적으로 표현할 수 있다는 것.

function* naturals() {
  let n = 1;
  while (true) yield n++;
}

const g = naturals();
g.next().value; // 1
g.next().value; // 2
// ... 무한히 가능

(자세한 메커니즘은 [[Lexical Environment 와 클로저]] 글의 naturals 예제 참고)

AsyncIterator, 비동기 버전

ES2018 이 도입한 async function* 은 비동기 결과를 차례로 흘려보낸다.

{}

페이지네이션 API, 스트림 처리, WebSocket 메시지 순차 처리 같은 곳에서 빛난다. Promise.all 로 한 번에 받을 수 없는 “차례로만 알 수 있는 비동기 시퀀스” 를 표현하는 정통 도구.

Node.js ReadableStream 과의 조합

Node.js 에서 파일을 한 줄씩 읽는 모던한 방법.



async function* lines(path) {
  const rl = createInterface({
    input: createReadStream(path),
  });
  for await (const line of rl) yield line;
}

for await (const line of lines('huge.log')) {
  if (line.includes('ERROR')) console.log(line);
}
// → 메모리에 전체 파일을 올리지 않고 한 줄씩

for await...of 와 async function* 의 조합이 백프레셔 (backpressure) 를 자연스럽게 처리한다. 소비가 느리면 생산도 멈춘다.

requestAnimationFrame, 화면 갱신과 발 맞추기

타이머와 Promise 외에 브라우저가 제공하는 또 하나의 비동기 스케줄링이 [[requestAnimationFrame]] (rAF) 이다.

매 프레임마다 실행

requestAnimationFrame(callback) 은 “다음 화면 다시 그리기 직전에 콜백을 실행” 한다. 60fps 환경에서 약 16.67ms 마다 호출된다.

let lastTime = performance.now();
function animate(now) {
  const dt = now - lastTime;
  lastTime = now;

  // dt 만큼 위치 갱신
  ball.x += velocity * dt / 1000;
  render();

  requestAnimationFrame(animate);
}
requestAnimationFrame(animate);

setInterval(animate, 16) 과의 차이가 결정적이다.

항목	`setInterval(fn, 16)`	`requestAnimationFrame(fn)`
호출 시점	16ms 마다 (큐가 비어있을 때)	다음 paint 직전
브라우저 탭이 백그라운드일 때	계속 호출 (~1Hz 로 throttle)	호출 안 됨
모니터 주사율	무시	적응 (60Hz, 120Hz 등)
프레임 누락	자주	드묾

rAF 는 렌더링 사이클과 동기화 되므로 같은 CPU 비용에서 훨씬 부드러운 결과를 낸다.

이벤트 루프와의 관계

rAF 콜백은 마이크로태스크도 매크로태스크도 아니다. 이벤트 루프 한 틱의 마지막 단계, “렌더링” 단계에 끼어든다.

한 틱:
  1. 매크로태스크 1개 실행
  2. 마이크로태스크 전부 실행
  3. 렌더링 단계:
     - requestAnimationFrame 콜백 실행
     - 스타일 계산 → 레이아웃 → 페인트
  4. 다음 틱으로

이 위치 덕분에 rAF 콜백 안에서 DOM 을 수정하면 같은 프레임에 반영 된다. 매크로태스크에서 수정하면 다음 프레임이 되어야 보인다.

정리, 비동기 스케줄링의 위계

다섯 개의 큐 / 단계를 시간 순으로 정리하면.

우선순위	종류	예시	언제
1	동기 코드	`console.log`, 함수 호출	지금
2	마이크로태스크	`Promise.then`, `await`, `queueMicrotask`	동기 끝나자마자, 전부
3	렌더링 단계	`requestAnimationFrame`	paint 직전
4	매크로태스크	`setTimeout`, `setInterval`, DOM 이벤트	다음 틱에 한 개씩
5	I/O (Node.js)	`fs`, `net` 콜백	poll 단계

이 위계는 암기보다 메커니즘 이해가 더 안전 하다. “마이크로태스크 큐가 비어야 다음 매크로로 간다” 는 원칙 하나만 잡으면 어떤 코드 출력도 추론 가능하다.

콜백 → Promise → async/await, 한 줄로 보면

시대	도구	해결한 것	남긴 문제
~ES5	콜백	일급 함수로 단순 비동기	콜백 지옥, 인버전 오브 컨트롤, 에러 처리
ES6 (2015)	Promise	상태 불변성, 평탄한 체이닝, 에러 통합	`.then().then()` 의 가독성
ES2017	async / await	동기처럼 읽히는 비동기	순차/병렬 구분 의식 필요
ES2018	AsyncIterator	비동기 시퀀스 표현	학습 곡선
ES2020	`queueMicrotask`, `Promise.allSettled`	명시적 스케줄링, 부분 실패	,
ES2021	`Promise.any`, `AggregateError`	첫 성공만 필요한 패턴	,

각 단계는 직전 단계가 남긴 문제를 한 걸음씩 푼 결과다. 콜백은 사라지지 않았다. 이벤트 리스너, DOM API, 일부 Node.js API 는 여전히 콜백 기반이다. 다만 비동기 흐름의 주축 이 Promise / async-await 로 옮겨갔을 뿐.

실무 선택 가이드

상황	추천
HTTP 한 번 호출	`await fetch()`
여러 호출, 전부 필요	`Promise.all`
여러 호출, 부분 실패 OK	`Promise.allSettled`
타임아웃 / 가장 빠른 응답	`Promise.race` 또는 `Promise.any`
페이지네이션 / 스트림	`for await...of` + `async function*`
사용자 입력에 반응하는 fetch	`AbortController`
무거운 작업 잘게 쪼개기	`setTimeout(fn, 0)` 또는 `queueMicrotask`
부드러운 애니메이션	`requestAnimationFrame`
한 번만 미루기	`queueMicrotask` (Promise 객체 생성 비용 ↓)

세 질문의 답을 한 줄로 정리하면:

Q1. 어떻게 동시에 처리되나? → 호스트가 백그라운드 처리, 엔진은 이벤트 루프로 큐를 처리.
Q2. setTimeout(fn, 0) 이 왜 즉시가 아닌가? → 모든 비동기는 큐를 거쳐야 하며, 4ms 최소 지연이 누적 가능.
Q3. 왜 Promise 가 setTimeout 보다 먼저인가? → 마이크로태스크 큐가 매크로태스크 큐보다 먼저 비워진다.

비동기는 마법이 아니다. 싱글 스레드 + 호스트의 백그라운드 처리 + 두 종류의 큐 + 이벤트 루프, 이 네 가지 조합이 만들어내는 결정론적 시스템이다.

이 그림을 한 번 머릿속에 두면 React 의 useEffect 가 왜 그 시점에 호출되는지, Vue 의 nextTick 이 정확히 무엇을 미루는지, Express 의 미들웨어 체인이 어떻게 흐르는지가 모두 같은 언어로 설명된다.

ℹ️ 이 글은 ECMAScript 명세 (ECMA-262), MDN Web Docs, HTML 명세 (WHATWG), 그리고 캡틴판교·인파·rejoelve 의 한국어 자료를 참조하여 AI(Claude)와 함께 작성 되었습니다. 마이크로태스크 정확한 처리 순서는 V8 / SpiderMonkey 등 엔진별로 미세한 차이가 있을 수 있으나, 명세 동작은 모두 동일합니다.

참고 자료

ECMA-262, Jobs and Host Operations
ECMA-262, Promise Objects
WHATWG HTML, Event loop
WHATWG HTML, Timers (§8.1.7.4)
MDN, Promise
MDN, async function
MDN, AbortController
MDN, for await…of
Philip Roberts, What the heck is the event loop anyway? (JSConf EU 2014)
캡틴판교, 자바스크립트 Promise 쉽게 이해하기
인파, 자바스크립트 Promise 개념 & 문법 정복하기
rejoelve, 봐도 봐도 헷갈리는 resolve, reject

CPU vs GPU vs TPU vs NPU, 네 종류 프로세서의 원리와 최근 동향

koa (김신건) — Sun, 14 Jun 2026 00:00:00 GMT

시작, 왜 네 종류의 프로세서가 필요한가

2010년대 중반까지는 단순했다. CPU 가 있고, 게임이나 그래픽이 필요하면 GPU 가 있었다. 그게 다였다.

지금은 다르다. 데이터센터에는 TPU(Tensor Processing Unit), 스마트폰에는 NPU(Neural Processing Unit) 가 들어있다. 같은 회사의 같은 제품군에 네 종류의 프로세서가 동시에 동작하는 경우도 흔하다. 예를 들어 최신 노트북:

CPU: 운영체제, 브라우저, 일반 앱 실행
GPU: 게임, 비디오 인코딩
NPU: 화상 회의 배경 흐림, on-device LLM (Copilot+)
(TPU 는 데이터센터 쪽)

왜 이렇게 분화되었나? 답은 단순하다. 하나의 프로세서로는 모든 워크로드를 효율적으로 처리할 수 없게 되었다. 특히 AI 워크로드 (행렬 곱셈 위주) 가 폭증하면서 범용 CPU 의 한계가 명확해졌고, 각 워크로드에 특화된 가속기가 등장한 것이다.

이 글에서는 네 프로세서의 원리, 메모리 사용 방식, 강약점, 최근 동향, CS 에 미친 영향 을 차례로 살펴본다. 각 프로세서의 내부 구조는 매우 다르며, 각자 자기 섹션에서 애니메이션과 함께 확인할 수 있다.

먼저 가장 기본적인 질문, “프로세서가 하는 일은 무엇인가” 부터.

기초, 프로세서의 본질

프로세서는 단 두 가지 일을 한다.

명령어 fetch + decode + execute (Von Neumann 사이클)
데이터를 메모리에서 가져와서 처리하고 다시 쓰기

{}

위 4단계가 모든 현대 컴퓨터의 가장 기본적인 동작 단위. CPU 든 GPU 든 모두 이 사이클을 변형해 진화시킨 것이다.

이 두 일을 얼마나 빨리, 어떤 패턴으로 하느냐가 모든 차이를 만든다.

축	변형
명령어 다양성	적음 (특화) ↔ 많음 (범용)
동시 실행 단위 수	적음 (직렬) ↔ 많음 (병렬)
메모리 접근 패턴	무작위 (캐시 의존) ↔ 순차/규칙적
분기 처리	복잡한 분기 잘 ↔ 분기 없는 코드만
수치 정밀도	64 bit 부동소수 ↔ 4 bit 정수

CPU 는 모든 축에서 “왼쪽”에 가깝고, NPU 는 모든 축에서 “오른쪽”에 가깝다. GPU 와 TPU 는 중간의 다른 지점들. 이제 각각을 보자.

CPU, 범용성의 정수

{}

동작 원리

CPU 는 어떤 코드든 실행할 수 있는 범용 프로세서다. 그 대가로 한 코어가 매우 복잡하다.

한 CPU 코어 안에는:

명령어 디코더: x86, ARM 등 수백 개 명령어를 해석
분기 예측기: if 의 결과를 미리 추측해 파이프라인 채움
out-of-order 실행 엔진: 명령어를 의존성 그래프대로 재정렬해 동시 실행
수십 단계 파이프라인: 하나의 명령어를 fetch → decode → execute → writeback 등으로 쪼개 cycle 마다 다른 명령어가 다른 단계
L1/L2/L3 캐시: 메모리 지연을 숨기기 위해 최근 데이터 보관

{}

위 애니메이션이 5단계 파이프라인의 동작을 보여준다. 매 cycle 다른 명령어가 다른 단계에서 동시 진행되고, 데이터 의존성이 있으면 bubble (idle) 이 삽입된다. 분기 예측이 실패하면 in-flight 명령어가 모두 폐기되는 큰 손실. 현대 CPU 는 이 5단계 모델을 확장해 14~20 단계 파이프라인 + superscalar (cycle 당 4 명령) + OoO 까지 발전.

이 모든 회로가 코어 면적의 큰 비율을 차지한다. 그래서 같은 다이 면적에 CPU 코어는 8~16개 정도밖에 들어가지 않는다.

메모리 계층

CPU 는 캐시 위주 메모리 시스템이다.

Register: ~0.3 ns (1 cycle)
L1 Cache: ~1 ns (4 cycles), 32~64 KB/core
L2 Cache: ~3 ns (12 cycles), 256 KB~1 MB/core
L3 Cache: ~10 ns (40 cycles), 수십 MB (모든 코어 공유)
DRAM:    ~100 ns (400 cycles), 16~256 GB

이 계층이 잘 작동하면 평균 메모리 접근 시간이 L1 수준에 가까워진다. CPU 가 “복잡하지만 빠른” 이유.

대역폭은 보통 50~100 GB/s (DDR5 듀얼 채널 기준).

강점과 약점

강점	약점
어떤 코드든 실행	병렬 코어 수 적음
복잡한 분기 잘 처리	행렬 곱셈 비효율
큰 캐시로 낮은 지연	메모리 대역폭 한계 (DDR5: ~89 GB/s)
OS, 시스템 콜, 인터럽트	AI 워크로드 효율 낮음

최근 동향

AMX (Advanced Matrix Extensions): Intel Sapphire Rapids 부터 CPU 에 행렬 곱셈 가속 회로 통합 (mini-TPU)
Apple Silicon (M4): ARM 기반 + LPDDR5X unified memory (546 GB/s) 로 GPU 메모리 격차 일부 축소
이종 코어: P-core (성능) + E-core (효율) 조합이 표준화 (Intel 12세대 부터)

CPU 는 죽지 않는다. 다만 AI 워크로드는 다른 프로세서에 위임하고, 시스템 오케스트레이션 역할로 진화하고 있다.

GPU, 병렬성의 도약

{}

그래픽에서 AI 로

GPU 는 원래 게임 그래픽 렌더링용이었다. 픽셀 100만 개를 동시에 계산해야 하는 작업이라 자연스럽게 “많은 단순한 코어” 구조가 되었다.

GPU 의 본래 임무는 3D 그래픽 파이프라인이다.

Vertex Shader: 3D 모델의 꼭짓점 (vertex) 변환, 카메라 시점 적용
Rasterization: 삼각형들을 화면의 픽셀로 변환
Fragment Shader: 각 픽셀의 색을 결정 (조명, 그림자, 텍스처 등)
Texture Mapping: 2D 이미지를 3D 표면에 매핑
Output Merger: 최종 픽셀 출력 + 깊이 테스트

각 단계가 수백만 ~ 수천만 개의 독립적인 픽셀/vertex 에 대해 같은 연산을 적용해야 한다. 그래서 GPU 는 “같은 연산을 다른 데이터에 동시 적용” 하는 구조로 진화했다.

이 구조가 우연히 딥러닝과 완벽히 맞았다. 신경망의 행렬 곱셈도 결국 수백만 번의 독립적인 곱셈이고, GPU 가 이를 동시에 처리할 수 있었다. 2010년대 초 NVIDIA 가 CUDA 를 일반 컴퓨팅에 개방하면서 게임 GPU 가 AI 컴퓨팅의 표준이 된 것.

SIMT 실행 모델

단계 1, 왜 thread 가 많아야 하는가

GPU 가 “수천 개 코어” 라고 부르는 건 사실 단순한 ALU (산술 연산 회로) 수천 개를 의미한다. CPU 처럼 한 코어가 분기 예측, 캐시, OoO 같은 복잡한 회로를 다 가진 게 아니다.

그렇다면 이 수천 개 ALU 에게 일을 어떻게 시킬까? 각 ALU 한 개 한 개를 “thread” 라고 부르면 5,000 개의 thread 가 동시에 돌아야 한다. 이게 GPU 가 그래픽에서 출발한 이유와 자연스럽게 맞아떨어진다. 1920x1080 화면의 200만 픽셀이 각자 자기 색을 계산해야 하니까.

단계 2, 각 thread 마다 모든 회로를 두면 너무 비싸다

문제는 thread 마다 명령어 디코더 + Program Counter (PC) 를 가지면 회로가 너무 커진다. 5,000 개의 thread × 디코더 = 5,000 개의 디코더. 이건 칩 면적의 대부분을 디코더가 차지하는 비효율적 설계.

CPU 가 한 코어에 디코더 1개 두는 것과 정반대.

단계 3, NVIDIA 의 트레이드오프, warp

NVIDIA 의 해결: 32 thread 를 묶어 같은 디코더를 공유시킨다. 이 묶음이 “warp”.

한 SM (Streaming Multiprocessor):
  - 디코더 1개 (또는 몇개)
  - 32 thread = 1 warp 가 같은 명령을 동시에 실행
  - 64 warp 까지 동시 보유 (서로 다른 warp 는 다른 명령 실행 가능)
  - 한 cycle 마다 어떤 warp 의 명령을 실행할지 warp scheduler 가 선택

비유: 줄 서 있는 32명에게 “왼쪽 발 든다” 한 번 외치면 모두 왼쪽 발을 든다. 한 명 한 명에게 따로 외치지 않아도 됨.

같은 명령을 받지만 각자 자기 데이터로 처리. Thread 0 은 픽셀 0, Thread 1 은 픽셀 1을 처리. 같은 “픽셀 색 계산” 명령이지만 결과는 다른 픽셀에 저장.

단계 4, 이게 바로 SIMT

이 모델 이름이 SIMT (Single Instruction, Multiple Threads). 한 명령으로 여러 thread 가 다른 데이터를 처리.

{}

비슷한 개념으로 [[SIMT|SIMD (Single Instruction, Multiple Data)]] 가 있다. CPU 의 AVX-512 같은 벡터 명령. 차이는:

SIMD: 컴파일러가 “한 번에 16개 float 더해” 같은 벡터 명령을 명시적으로 만들어야 함
SIMT: 프로그래머는 그냥 “thread 마다 a[i] + b[i] 한다” 라고 짜면, 하드웨어가 알아서 32개씩 묶어 같은 명령으로 처리

SIMT 가 프로그래밍이 훨씬 자연스럽다. CUDA 가 인기를 끈 핵심 이유.

단계 5, 분기가 갈리면 어떻게 되나, warp divergence

문제는 같은 명령을 32 thread 가 모두 실행한다는 가정. 그런데 if (x > 0) 같은 분기에서 일부 thread 만 if 경로, 나머지가 else 경로를 타면?

if (data[threadIdx.x] > 0) {
  result = sqrt(data[threadIdx.x]);  // 일부 thread 만
} else {
  result = data[threadIdx.x] * 2;    // 나머지 thread 만
}

해결: 두 경로를 직렬로 실행.

Cycle 1: warp 의 (x > 0) thread 만 활성, 나머지는 idle. sqrt(x) 실행
Cycle 2: warp 의 (x ≤ 0) thread 만 활성, 나머지는 idle. x * 2 실행
결과적으로 같은 warp 의 활용률이 50% 로 떨어짐. 이게 warp divergence.

GPU 코드 최적화의 핵심은 같은 warp 의 thread 들이 같은 분기를 타도록 데이터를 정렬하는 것. 예) 정수 양수/음수가 섞인 배열이면 미리 정렬해서 warp 안에서 분기가 안 갈리게.

단계 6, 규모

NVIDIA H100:

132 SM × 64 warp × 32 thread = 약 27만 thread 동시 활성 이론상
실제로는 메모리 대역폭, divergence, warp 간 의존성으로 활용률 일부

이 정도 thread 가 동시에 같은 행렬 곱셈 명령을 실행하면 LLM 학습/추론이 빠를 수밖에 없다.

단계 7, [[SPMD]] 와의 관계

SIMT 모델은 사실 [[SPMD]] (Single Program Multiple Data) 의 GPU 하드웨어 구현이다. MPI 같은 분산 컴퓨팅에서 모든 노드가 같은 프로그램을 실행하되 다른 데이터를 처리하는 패턴. GPU 의 thread = MPI 의 노드, warp = 같은 명령 broadcast 단위.

분산 학습 코드를 작성해본 사람이라면 CUDA 코드가 익숙하게 느껴지는 이유.

메모리 계층

CPU 와 결정적으로 다르다.

HBM (High Bandwidth Memory): 칩 옆에 수직 적층된 DRAM, [[HBM]] 참조
L2 cache (40~60 MB) + L1 per SM (128 KB)
캐시는 지연 감소보다 대역폭 압력 완화 가 목적

대역폭 비교:

H100: HBM3 5 stack = 3,350 GB/s
B200: HBM3e 8 stack = 8,000 GB/s
(CPU DDR5: 89 GB/s)

GPU 가 CPU 대비 30~90 배 메모리 대역폭. 이게 딥러닝 학습/추론에서의 격차를 만든다.

강점과 약점

강점	약점
대규모 병렬 처리	분기 많은 코드 (warp divergence)
행렬/텐서 연산 빠름	단일 thread 성능 낮음
HBM 으로 메모리 대역폭 압도	비싼 가격 (H100 ~$30K)
CUDA 생태계 성숙	전력 소모 큼 (700W+)

최근 동향 (Blackwell)

NVIDIA Blackwell 아키텍처 (B200, GB200):

HBM3e 12-stack 으로 4 TB/s 대역폭
FP6, FP4 새 수치 포맷 지원 (모델 양자화 가속)
다중 다이 패키지 (multi-chip module)
Transformer Engine 2세대, LLM 추론 30 배 가속 주장

CUDA 의 락인 효과는 여전히 강력하지만 AMD ROCm, Intel oneAPI 도 추격 중.

TPU, 행렬 곱셈에 회로를 고정시키다

{}

왜 TPU 가 필요한가, GPU 가 있는데도

GPU 가 AI 에 잘 맞는다는 게 알려졌지만, Google 은 이를 자체 데이터센터에 도입하기 어려웠다. 이유 3가지:

그래픽 회로의 낭비: GPU 면적의 상당 부분 (RT Core, ROP, rasterizer 등) 이 게임용. AI 워크로드에는 죽은 면적
CUDA 락인: NVIDIA 의 비싼 가격을 NVIDIA 가 결정. 대안 부재
워크로드 특화 효율의 한계: 범용 GPU 의 SIMT 는 행렬 곱셈에 최적은 아님

Google 의 답: 자체 ASIC. 2015년 첫 TPU. 목표는 단 하나, 행렬 곱셈만, 가장 효율적으로.

TPU 가 GPU 대비 가지는 구체적 강점

측면	GPU (H100)	TPU (v6 Trillium)
행렬 곱셈 효율	Tensor Core 가 보조	MXU 전용 회로, 한 cycle 65,536 MAC
메모리 접근	SIMT, 매 명령마다 메모리	Weight Stationary, 가중치 1번 적재
전력 효율	700W	200W (3.5배 효율)
그래픽 회로	30% 면적	0%
컴파일러 통합	CUDA (low-level)	XLA (high-level), Python 그대로
확장성	8 GPU per node (NVLink)	256 chip per pod (ICI), pod 간 광통신

TPU 의 진정한 강점은 데이터센터 스케일. 한 pod 에 256 chip, 그 pod 가 수백 개 모인 cluster 가 13 Pbps 데이터센터 네트워크로 연결. 하나의 거대한 컴퓨터처럼 학습 가능.

Systolic Array

TPU 의 핵심은 [[Systolic Array]] 다. MXU (Matrix Multiply Unit) 라고 부른다.

{}

핵심 아이디어 3가지:

Weight Stationary: 가중치는 PE 에 미리 적재되어 움직이지 않음
Activation Flow: 입력이 격자를 박동(systolic)처럼 흐르며 곱셈+누적
메모리 접근 최소화: 한 가중치가 N x N 번의 곱셈에 재사용

256x256 MXU 한 cycle 에 65,536 번의 MAC 동시 수행.

메모리

GPU 의 HBM 과 유사하지만:

Unified Buffer (24~32 MB on-chip SRAM): layer 간 활성화 보관 → DRAM 접근 최소화
HBM: TPU v6 에서 32 GB / 1,640 GB/s

복잡한 캐시 계층 없이 큰 SRAM + HBM 의 단순한 구조. Systolic array 가 메모리 접근을 적게 하니까 가능한 설계.

TPU 의 진화

세대	출시	주요 변화
TPU v1	2015	추론 전용, 8-bit INT
TPU v2	2017	학습 지원, bf16
TPU v3	2018	액체 냉각
TPU v4	2021	SparseCore (embedding 가속)
TPU v5e/v5p	2023	비용 최적화, 대규모 학습
TPU v6 (Trillium)	2024	918 TFLOPs bf16, 4.7x v5e

Trillium 의 의미: v5e 대비 4.7x 컴퓨트, 67% 에너지 효율 개선, 한 pod 에 256 chip = 234.9 PFLOPs.

강점과 약점

강점	약점
행렬 곱셈 최고 효율	TensorFlow/JAX 외 생태계 약함
전력 효율 우수 (TPU v6 67% 개선)	Google Cloud 외 사용 불가
HBM + 대용량 SRAM	행렬이 아닌 워크로드는 느림
대규모 pod 확장 (10,000+ chip)	가격 정보 불투명

NPU, 디바이스 위 AI 의 핵심

{}

왜 NPU 가 필요한가, GPU 가 있는데도

스마트폰에도 GPU 가 있다. Adreno (Qualcomm), Mali (ARM), Apple GPU. 그런데도 별도의 NPU 가 생긴 이유는 명확하다.

모바일에서 GPU 의 한계

전력 예산: 스마트폰 전체 SoC 가 5~10W 가 한계. GPU 를 켜면 게임/그래픽으로 거의 다 씀
AI 추론은 게임과 동시에 필요: 화상 통화 중 배경 흐림 (GPU 가 영상 인코딩 중) + 카메라 객체 인식 + 음성 비서 등 동시 실행 시 GPU 만으론 부족
양자화 효율: GPU 는 FP16 위주 회로. INT4 같은 극한 양자화에는 회로 활용률이 떨어짐
항상 켜진 워크로드: 음성 비서 (“Hey Siri”), 항상 동작하는 카메라 보호, 손동작 인식 등은 GPU 깨우기엔 전력 낭비

NPU 의 구체적 강점

측면	모바일 GPU	NPU (Hexagon, Apple NE)
와트당 효율 (INT4)	~0.5 TOPS/W	15+ TOPS/W (30배)
수치 정밀도	FP32/FP16	INT4/INT8 native
항상 켜진 추론	어려움 (전력 큼)	가능, 마이크로와트
메모리	GPU 전용 일부	SoC LPDDR 공유, 작지만 충분
부팅 시간	수십 ms	수 ms (인터럽트 응답급)

실제 사용 시나리오

Hey Siri: 음성 비서 detection. CPU 를 깨우지 않고 NPU 가 1mW 로 항상 listening
카메라 객체 인식: 동영상 녹화 중 GPU 는 인코딩, NPU 는 얼굴/물체 인식
on-device LLM: Apple Intelligence, Snapdragon AI Hub 가 7B~10B 모델을 INT4 로 실행
배경 흐림 (Zoom/Teams): 화상 통화 중 NPU 가 segmentation, GPU 는 영상 인코딩

NPU 가 없는 폰에서도 가능하지만, 배터리가 빠르게 닳거나 발열로 throttling 발생.

양자화의 중요성

NPU 의 핵심 특기는 [[양자화]] 다. 데이터센터 TPU 는 bf16 (16 bit) 정밀도가 일반적이지만, NPU 는 더 공격적으로 줄인다.

정밀도	비트수	메모리 절약	정확도 손실
FP32	32	1x	0
FP16 / bf16	16	2x	거의 없음
INT8	8	4x	`<1%` (대부분의 모델)
INT4	4	8x	2~5% (LLM 정량화 가능)

NPU 는 INT8, INT4 연산을 하드웨어 회로로 가속한다. 같은 모델을 4-bit 로 돌리면 메모리 8x 절약 + 처리량 4x.

모바일 SoC 의 NPU 경쟁 (2025-2026)

제품	NPU	TOPS	비고
Apple A19 Pro / M4	Neural Engine	38	16-core, on-device 모델 (Apple Intelligence)
Snapdragon 8 Elite	Hexagon NPU	75	INT4 native, on-device LLM
Snapdragon 8 Gen 4	Hexagon NPU	80+	2025 출시
MediaTek Dimensity 9500	APU	60+	2nm 공정
Samsung Exynos 2400	NPU	34.7	Galaxy S24+
Intel Lunar Lake	NPU 4	48	Windows Copilot+ 자격 (40 TOPS 이상)
Qualcomm Snapdragon X Elite	Hexagon	45	Copilot+ PC

Copilot+ PC 인증 = NPU 40 TOPS 이상이 표준 기준이 되면서 NPU 가 데스크톱/노트북에도 의무화되는 추세.

강점과 약점

강점	약점
와트당 효율 최고 (TOPS/W)	학습 불가, 추론 전용
SoC 통합으로 추가 칩 불필요	메모리 작음 (디바이스 RAM 공유)
INT4/INT8 양자화 우수	모델 변환 + 양자화 필요
항상 사용 가능, 저전력	새 아키텍처 모델 지원 늦음

한 그림 비교

측면	CPU	GPU	TPU	NPU
코어 수	4~64	수천~수만	수만 PE	수천 PE
한 코어 복잡도	매우 높음	낮음	매우 낮음	매우 낮음
메모리 시스템	큰 캐시 + DRAM	HBM + 작은 캐시	SRAM + HBM	SoC 공유 메모리
메모리 대역폭	50~100 GB/s	1~8 TB/s	1~3 TB/s	~100 GB/s
주 워크로드	범용	그래픽, AI 학습	AI 학습/추론	디바이스 AI 추론
수치 정밀도	FP64/FP32/INT	FP32/FP16/INT8	bf16/INT8	INT8/INT4
전력	15~250W	300~1000W	200~500W	1~10W
사용처	서버, PC, 모바일	데이터센터, PC	Google Cloud	모바일, edge, PC
가격	$200~$5,000	$1,000~$30,000	(Cloud)	SoC 통합

메모리 대역폭 시각화

HBM 세대별 대역폭 진화

모바일 NPU TOPS 비교 (2025 플래그십)

최근 동향 (2024 ~ 2026)

1. 학습은 GPU 와 TPU, 추론은 NPU 로 분화

대규모 학습 (LLM, 비전 모델) 은 NVIDIA H100/B200 또는 Google TPU 가 거의 독점. 반면 추론 (이미 학습된 모델로 응답 생성) 은:

데이터센터 추론: 여전히 GPU/TPU
on-device 추론: NPU 가 빠르게 점유 (Apple Intelligence, Snapdragon AI Hub, Windows Copilot+)

이유: 학습은 막대한 메모리/연산이 필요하지만, 추론은 양자화 + 작은 모델 (3B~10B) 이면 NPU 로 충분히 빠름.

2. 양자화 포맷의 폭증

전통적 FP32 만 쓰던 시절은 지났다. 2024-2026 에는:

FP16, bf16: 학습 표준
INT8: 추론 가속, 거의 모든 모델 지원
INT4: LLM 추론, 메모리 8x 절약
FP8 (NVIDIA H100): 학습 + 추론 양쪽
FP6, FP4 (NVIDIA B200): 새 표준
MXFP4 (Microsoft scaled FP4): 미세 양자화

각 정밀도마다 하드웨어 회로가 필요. NPU 는 INT4 native 지원 (Snapdragon 8 Gen 2+).

3. 메모리 대역폭이 진짜 병목

대형 LLM 의 inference 시간은 모델 가중치를 메모리에서 가져오는 시간이 dominant. 그래서:

HBM4 가 2026년 약 2 TB/s 로 등장
NVIDIA Rubin (HBM4 기반) 예정
SK Hynix HBM 점유율 75%+, AI 메모리 시장 폭증

4. heterogeneous computing 의 표준화

한 SoC 안에 CPU + GPU + NPU + 메모리 + 보안 가속기가 모두 통합. 워크로드별로 가장 적합한 코어로 자동 라우팅:

사진 촬영 → ISP + NPU (HDR, 객체 인식)
브라우저 → CPU + GPU (렌더링)
화상 회의 → NPU (배경 흐림) + GPU (인코딩)
게임 → CPU + GPU
LLM 응답 → NPU (작은 모델) or 클라우드 GPU (큰 모델)

OS 가 작업 스케줄러가 되는 시대. Apple, Qualcomm, Intel 모두 비슷한 방향.

5. 새 가속기 카테고리의 등장

Cerebras WSE-3: wafer-scale (한 wafer 가 한 chip), 4 trillion transistor
Groq LPU: 결정론적 LLM 추론 가속, 초당 수천 토큰
Tenstorrent Wormhole: 오픈소스 RISC-V 기반 AI 칩

NVIDIA 독점 구도에 균열이 보이는 시점.

CS 에 미치는 영향

네 종류 프로세서의 등장이 컴퓨터 과학 패러다임 자체를 바꿨다.

1. 알고리즘 설계의 transformation

전통적 알고리즘 평가 기준은 시간 복잡도 O(n). 이제는 부족하다.

메모리 접근 패턴: 캐시 친화적인가? coalesced 인가?
병렬화 가능성: 데이터 의존성이 적은가?
수치 정밀도 허용 범위: 4-bit 로도 충분한가?

같은 O(n) 알고리즘이라도 GPU 에서 30 배 빠를 수 있고, 캐시 미스 패턴에 따라 같은 CPU 에서도 100 배 차이가 난다.

알고리즘 책의 “RAM 모델” (균일한 메모리 접근 가정) 은 이제 거의 허구.

2. 모델 [[양자화]] 의 부상

ML 연구에서 새 분야로 자리잡은 post-training quantization (PTQ), quantization-aware training (QAT). 같은 모델을 4-bit 로 만들면서 정확도 손실을 최소화하는 게 활발한 연구 주제.

[[양자화|GPTQ, AWQ, GGUF (llama.cpp), QLoRA]] 같은 기법들이 단 1-2년 사이에 표준이 됨. 양자화 덕분에 ChatGPT 급 모델을 24 GB RTX 4090 한 장 또는 CPU 만으로 실행 가능해졌다.

3. 시스템 소프트웨어의 재편

컴파일러: PyTorch 2.0 의 torch.compile, JAX 의 jit, TensorFlow 의 XLA, MLIR 같은 ML 컴파일러 인프라
런타임: ONNX Runtime, TensorRT, Core ML, Hexagon SDK 같은 디바이스별 추론 런타임
OS 차원의 통합: Windows Copilot+ Runtime, macOS Apple Intelligence Framework

전통적 OS 의 스케줄러가 CPU thread 만 다뤘다면, 이제는 NPU 워크로드 라우팅 까지 책임.

4. 데이터센터 설계 변화

NVIDIA DGX, Google TPU Pod 같은 AI 슈퍼컴퓨터가 표준이 됨. 단순한 서버 rack 이 아니라:

액체 냉각 (수냉)
50+ kW per rack (일반 서버 5~10 kW 대비)
광 통신 (NVLink, ICI)
HBM 의 비싼 가격이 전체 비용의 1/3

데이터센터 건축, 전력 인프라, 네트워크 설계 모두 AI 가속기 중심으로 재편.

5. [[분산 학습]] 의 일반화

한 GPU 에 안 들어가는 모델 (LLM 100B+) 을 학습시키는 게 일상화. 그래서 다양한 [[분산 학습|병렬화 전략]] 이 표준이 됨:

Data Parallelism (DP): 같은 모델 복제, 다른 배치
Tensor Parallelism (TP): 한 layer 의 행렬을 여러 GPU 에 분할
Pipeline Parallelism (PP): 모델 layer 를 GPU 들에 수직 분배
ZeRO / FSDP: 모델 parameter/gradient/optimizer state 자체를 sharding
3D / 4D Parallelism: 위 전략들의 조합 (Megatron-LM 표준)

Llama 3.1 405B 학습에는 TP=8, PP=16, DP=125 조합 16,000 H100 GPU 가 사용됨.

분산 시스템 설계가 ML 연구자의 필수 지식이 되었고, [[SPMD]] (Single Program Multiple Data) 같은 전통 HPC 개념이 ML 영역의 표준이 됨.

6. AI-first 사용자 경험

NPU 가 있는 디바이스에서:

항상 켜진 음성 비서 (전력 거의 안 씀)
실시간 카메라 객체 인식
오프라인 번역, 음성 인식
개인정보 누출 없는 on-device LLM

클라우드에 의존하지 않는 AI 가 가능해진 게 NPU 덕분.

정리

네 종류의 프로세서가 공존하는 이유는 단순하다.

	CPU	GPU	TPU	NPU
존재 이유	범용 명령 실행	대규모 병렬	행렬 곱셈 회로화	디바이스 AI 효율
희생한 것	병렬성	단일 thread 성능 + 분기	워크로드 유연성	학습 능력
얻은 것	모든 코드 실행	30~90배 대역폭	행렬 효율 극대화	와트당 효율

[!IMPORTANT] “가장 좋은 프로세서” 는 없다. 워크로드에 맞는 프로세서를 고르는 것이 중요하다. 그리고 현대 시스템은 거의 모든 경우 여러 종류를 동시에 사용한다 (heterogeneous computing).

향후 5~10년 동안은 더 분화될 가능성이 크다. Quantum Processing Unit, Optical Computing, In-Memory Computing 같은 새 카테고리가 실험되고 있고, 일부는 상용화될 것이다. 그러나 핵심 원리, “같은 일을 다른 방식으로 더 효율적으로”, 는 그대로다.

ℹ️ 이 글은 Google Cloud TPU v6 문서, NVIDIA Blackwell 발표, Qualcomm Hexagon NPU 백서, EigenState/L-P 의 2026년 AI 하드웨어 가이드, 그리고 2025 플래그십 SoC 비교 논문을 참조하여 AI(Claude)와 함께 작성되었습니다.

참고 자료

함수는 끝났는데 변수가 살아있다, Lexical Environment와 클로저의 메커니즘

koa (김신건) — Sat, 13 Jun 2026 00:00:00 GMT

시작 의문

다음과 같은 무한 자연수 이터레이터를 만든다고 하자.

function naturals(end = Infinity): Iterator<number> {
  let n = 1; // ← 어디에 사는 변수?
  return {
    next(): IteratorResult<number> {
      return n <= end
        ? { value: n++, done: false }
        : { value: undefined, done: true };
    },
  };
}

const it = naturals(5);
it.next(); // { value: 1, done: false }
it.next(); // { value: 2, done: false }
it.next(); // { value: 3, done: false }

naturals(5) 함수 호출은 첫 줄에서 끝났다. 그런데 it.next()를 호출하면 n이 살아있고, 호출할 때마다 1씩 증가한다.

세 가지 질문이 떠오른다.

n은 정확히 어느 메모리 영역에 사는가?
함수가 종료됐는데 왜 GC되지 않는가?
외부에 let n = 100이 있으면 어느 쪽이 이긴다고 보장할 수 있는가?

답을 바로 던지면 “클로저 때문이다” 한 줄로 끝난다. 하지만 그게 어떻게 가능한지를 이해하려면 한 단계 더 들어가야 한다. 이 글은 스코프·Environment·참조 사슬·스코프 체인 워킹 네 개념을 차례로 쌓아 세 질문 모두에 답하는 것을 목표로 한다.

먼저 가장 기초적인 곳부터.

한 단계 뒤로, 스코프와 Environment 가 왜 필요한가

코드는 명령어, 데이터는 값

JavaScript 엔진이 let x = 5를 만나는 순간 두 가지 일이 동시에 일어난다.

이름 x 라는 식별자가 등록된다.
값 5 가 어딘가 메모리에 자리잡고, x 와 묶인다(binding).

이 “이름 → 값” 묶음이 binding이다. 함수 코드 자체는 그저 명령어 덩어리지만, 함수가 실행되는 동안 만들어지는 binding 들은 어딘가 별도의 저장소에 보관되어야 한다. 그 저장소를 ECMAScript 명세는 Environment Record 라고 부른다.

같은 이름이 여러 곳에 있을 때, 스코프

다음 코드를 보자.

let x = 10;

function outer() {
  let x = 20;
  function inner() {
    let x = 30;
    console.log(x); // 어느 x?
  }
  inner();
}

outer();

세 군데에 x 가 있다. inner() 안의 console.log(x) 는 어떤 x 를 가리키는가? 인간이 보기엔 “가장 가까운 30”이 답이지만, 엔진은 어떻게 이 규칙을 구현하는가?

답은 스코프(scope) 라는 개념이다. 코드의 각 함수·블록은 자기만의 스코프를 가지고, 안쪽 스코프에서 변수를 찾다가 못 찾으면 바깥 스코프를 본다. 스코프들이 부모-자식 관계로 사슬을 이루고, 이 사슬을 스코프 체인 이라 한다.

여기서 한 가지 결정이 필요하다, 어떤 함수가 “바깥”인가? 정의 시점의 위치인가, 호출 시점의 위치인가?

Lexical(어휘적) 스코프: 정의 시점 기준. 코드를 쓴 자리가 바깥을 결정한다.
Dynamic(동적) 스코프: 호출 시점 기준. 어디서 호출됐는지가 바깥을 결정한다.

JavaScript는 Lexical 스코프를 선택했다. 그래서 정확한 명세 이름이 “Lexical Environment”다. 호출 위치가 어디든, 정의 위치의 바깥 스코프가 영원히 바깥이 된다.

호출마다 새 영역이 필요한 이유

마지막 기초 한 조각. 같은 함수가 여러 번 호출되면 어떻게 되는가?

function counter() {
  let n = 0;
  n++;
  console.log(n);
}

counter(); // 1
counter(); // 1 (1이 또!)

counter() 두 호출은 각자 자기 n 을 가져야 한다. 만약 같은 n 을 공유했다면 두 번째 호출은 2 를 출력했을 것이다.

재귀 호출은 더 명확하다.

function factorial(n) {
  if (n <= 1) return 1;
  return n * factorial(n - 1);
}

factorial(3);
// factorial(3) 의 n = 3
// factorial(2) 의 n = 2  ← 동시에 살아 있어야 함
// factorial(1) 의 n = 1

세 호출의 n 은 동시에 메모리에 살아 있어야 한다. 함수 호출 한 번당, 그 호출만을 위한 독립된 변수 저장소가 만들어진다. 이게 [[Lexical Environment]] 가 “호출마다 새로 생성”되는 이유다.

종합, Lexical Environment 가 답하는 것

지금까지 본 것을 한 줄로 묶으면:

Lexical Environment 는 “이 호출의 변수들이 어디 살고, 바깥 스코프가 어디인지” 를 기록하는 객체다.

이게 우리가 곧 만나게 될 LE의 두 필드, 변수 저장소(Environment Record) + 외부 Environment 링크, 의 의미다.

왜 클로저가 필요한가

기초 한 가지가 더 남았다. 위 이야기까지는 “함수가 실행되는 동안 변수가 살아있어야 한다”였다. 그런데 우리의 시작 질문은 그 반대다, 함수가 끝났는데 변수가 살아있다. 이건 왜 필요한가?

다음 패턴들을 보자.

// (1) 이터레이터/제너레이터
function naturals() {
  let n = 1;
  return { next: () => n++ };
}

// (2) 카운터/누적기
function makeCounter() {
  let count = 0;
  return () => ++count;
}

// (3) 사적 상태(private state)
const account = (() => {
  let balance = 0;
  return {
    deposit: (amt) => (balance += amt),
    balance: () => balance,
  };
})();

// (4) 콜백이 외부 컨텍스트를 기억
function attachLogger(label) {
  return (event) => console.log(`[${label}]`, event);
}
const log = attachLogger('user');
button.onclick = log; // log는 호출 시 label='user' 를 기억

이 네 패턴 모두 “바깥 함수가 끝난 뒤에도 안쪽 함수가 바깥 변수를 기억” 해야 동작한다. 이게 안 되면 JavaScript에서:

이터레이터 같은 상태 보존 패턴이 불가능
사적 상태(#private 필드의 정신적 조상)가 불가능
콜백 함수가 자기 컨텍스트를 들고 다닐 수 없음
고차 함수(Higher-order Function) 표현력의 큰 손실

이 능력, 함수가 자기 정의 시점의 외부 변수들을 계속 참조할 수 있는 성질, 이 바로 [[클로저]] 다. 즉 클로저는 “있어서 좋은 기능”이 아니라 JavaScript의 표현력의 절반을 떠받치는 토대다.

이제 진짜 메커니즘으로 들어가자.

결과적 정의, 클로저

흔히 쓰는 한 줄 정의:

[[클로저|클로저(Closure)]]: 함수가 자신이 정의된 시점의 외부 변수들을 계속 참조할 수 있는 성질.

naturals 의 next() 함수는 자신을 감싸고 있던 naturals 의 변수 n, end 를 “닫아서 들고 다닌다(close over)”. 그래서 naturals 가 반환된 후에도 n 이 유효하다.

여기까지가 흔한 설명이다. 이제 세 질문을 차례로 풀어가자.

Q1. `n`은 어디 사는가?, Lexical Environment 의 구조

앞 절에서 우리는 Lexical Environment 가 “변수 저장소 + 외부 스코프 링크” 두 가지를 담는다고 말했다. 이걸 명세 수준에서 더 정확하게 보자.

LE 의 두 필드

ECMAScript는 함수가 호출될 때마다 Lexical Environment 객체를 하나 만든다. 그 LE는 단 두 개의 필드를 가진다.

필드	역할
Environment Record	이 스코프에서 선언된 식별자(`n`, `end`, 함수 이름 등)의 실제 binding 저장소
외부 Environment 참조 (Outer)	자기를 감싸는 바깥 LE 에 대한 참조. 없으면 `null`

이 단순한 구조가 스코프 체인 자체다. LE들이 outer 포인터로 연결되어 사슬을 이룬다.

{}

Environment Record 의 5 가지 종류

스펙 (ECMA-262 §9.1)은 Environment Record 를 다섯 가지로 분류한다.

Declarative: 일반 함수 스코프, 블록 스코프. let/const/함수 선언이 여기 산다.
Function: Declarative 의 특수화. this, super, new.target 을 추가로 갖는다.
Object: with 문 같은 곳에서 객체를 스코프 대상으로 쓸 때.
Global: 가장 바깥. 전역 객체(globalThis)와 묶여 있다.
Module: 모듈 최상위. import 바인딩이 여기 산다.

naturals(5) 를 호출하면 Function Environment Record 가 만들어진다. 그 안에:

Environment Record:
  n        → 1
  end      → 5
  this     → undefined  (strict)

외부 Environment 참조: → Module/Global Environment

함수 객체에 박힌 Environment 슬롯

여기가 클로저의 진짜 정체다.

ECMAScript에서 함수 객체 자체가 내부 슬롯으로 “Environment 슬롯” (스펙 정식 이름은 [[Environment]] 슬롯이지만, 그냥 Environment 슬롯이라 부르자) 을 가진다. 이 슬롯은 그 함수가 정의된 시점의 LE 를 가리킨다.

function naturals(end = Infinity) {
  let n = 1;
  return {
    next() {          // ← 이 함수 객체가 만들어질 때
      return n++      //   .Environment 슬롯 = naturals 의 LE
    }
  };
}

next 함수 객체는 생성될 때 자기를 감싼 LE(naturals 의 LE)를 자기 Environment 슬롯에 박제한다. 이후 next 가 어디서 어떻게 호출되든, 호출 시 만들어지는 next 자신의 새 LE 의 outer 참조는 항상 박제된 Environment 슬롯이 된다.

이게 “Lexical Environment” 라고 부르는 이유다. 호출 위치가 아니라 정의 위치가 외부 스코프를 결정한다.

Q1 의 답

n 은 콜 스택의 Execution Context 가 아니라, 힙(heap) 에 만들어진 Function Environment Record 의 binding 으로 산다. 처음부터 끝까지 힙에 있다. 함수 호출이 끝나는 순간이 아니라, 그 LE 를 더 이상 누구도 참조하지 않을 때까지 산다.

Q2. 함수가 끝났는데 왜 GC되지 않는가?, 참조 사슬

가장 흔한 오해를 먼저 깬다

많은 글이 이렇게 말한다, “함수의 로컬 변수는 함수가 끝나면 사라진다, 단 클로저로 잡힌 것은 예외.” 정확하지 않다.

정확한 그림은 이렇다.

함수가 종료되면 콜 스택에 있던 Execution Context 만 사라진다. 변수가 실제로 사는 LE 는 처음부터 힙에 있는 객체 다. 누군가 참조하고 있는 한 끝까지 살아남는다.

{}

참조 사슬 추적

naturals(5) 가 반환된 시점에서 일어나는 일을 추적해 보자.

naturals 의 Execution Context 가 콜 스택에서 pop 된다.
그러나 그 Execution Context 가 사용하던 Lexical Environment 자체 는 콜 스택에 없었다. 처음부터 힙에 있는 객체다.
힙에는 다음 객체들이 남는다: naturals LE, 반환된 객체 { next: ... }, next 함수 객체.
사용자 코드에는 const it = naturals(5), 변수 it 이 GC Root 다.

이제 GC 가 Root 부터 도달 가능한 객체를 마킹한다.

it (Root)
  ↓
반환 객체 { next: <fn> }
  ↓ .next
next 함수 객체
  ↓ Environment 슬롯
naturals 의 LE
  ↓ Environment Record
n: 1, end: 5

체인 끝의 LE 까지 도달 가능 → 회수 불가. 따라서 n, end 도 살아남는다.

변수의 수명 = 클로저 함수의 수명

이 사슬이 끊어지면 어떻게 될까?

{
  const it = naturals(5);
  it.next();
}
// 블록 종료 → it 사라짐 → 반환 객체 사라짐
//           → next 사라짐 → LE 사라짐 → n, end 회수됨

이때서야 비로소 GC가 LE 까지 회수한다. 클로저로 잡혀 있던 변수의 수명은 클로저 함수의 수명과 일치한다 는 게 핵심 규칙이다.

Q2 의 답

GC는 마법이 아니다. it → 반환 객체 → next → Environment 슬롯 → LE → n, end 라는 도달 가능 경로가 살아있는 한, GC는 LE 를 회수하지 않는다.

Q3. 외부에 `let n = 100`이 있어도 안전한가?, 스코프 체인 워킹

그림

let n = 100; // 전역

function naturals(end = Infinity) {
  let n = 1; // 로컬 (전역 n과 완전히 별개)
  return {
    next() {
      return { value: n++, done: false };
    },
  };
}

const it = naturals(5);
it.next();      // { value: 1, done: false }
console.log(n); // 100, 영향 없음

직관과 일치한다. 그런데 왜 그렇게 동작하는지 를 메커니즘으로 보면 클로저 이해가 단단해진다.

{}

한 단계씩 따라가기

it.next() 안에서 n 을 만나는 순간 엔진은 다음을 수행한다 (스펙 함수: ResolveBinding).

next 자신의 LE 의 Environment Record 에서 n 찾기 → 없음.
next 자신의 LE 의 외부 Environment 참조 로 이동 → 이게 next 의 Environment 슬롯이 가리키던 naturals 의 LE.
그 LE 의 Environment Record 에서 n 찾기 → 있음! 값 1. 여기서 멈춤.
발견한 binding 으로 읽기/쓰기 수행.

전역의 n = 100 은 4단계까지 가지도 못한다. 가장 가까운 binding 이 이긴다 (lexical shadowing).

정의 위치 기준이라는 게 강력한 보장이다

[!IMPORTANT] next 의 Environment 슬롯은 정의 위치 에 박제된다. next() 를 다른 모듈로 옮겨 거기서 호출해도, 호출 위치의 변수들이 끼어들 수 없다. 외부 격리가 어휘적으로 보장된다.

Q3 의 답

안전하다. 변수 조회는 항상 정의 시점에 박제된 Environment 슬롯부터 시작하여 외부 참조를 따라 바깥으로 진행 한다. 전역의 n=100 은 가장 가까운 n=1 이 가려버리기 때문에 닿을 수 없다.

만약 로컬 let n = 1 이 없었다면 한 단계 더 올라가서 Global Environment 의 n=100 을 썼을 것이다. 이 케이스가 가장 흔한 클로저 버그다.

한 그림으로, 세 질문, 세 메커니즘

질문	답	메커니즘
Q1. `n` 은 어디 사는가?	힙 에 있는 Function Environment Record 의 binding	LE = Environment Record + 외부 Environment 참조
Q2. 왜 GC 되지 않는가?	`it → 객체 → next → Environment 슬롯 → LE` 사슬이 살아있어서	함수 객체의 Environment 슬롯
Q3. 외부 `n=100` 이 있어도 왜 안전한가?	정의 시점에 박제된 Environment 슬롯부터 외부 참조를 따라가니까	ResolveBinding 의 스코프 체인 워킹

JavaScript 의 클로저는 마법이 아니다. 함수 객체에 박힌 Environment 슬롯, 힙에 떠 있는 Lexical Environment, 외부 Environment 참조로 이어지는 체인, 이 세 가지의 조합이다.

이 그림을 한 번 머릿속에 새겨두면 this, 화살표 함수, 모듈, 이터레이터, async/await 의 동작이 모두 같은 언어로 설명된다.

더 들어가기, 흔한 패턴과 함정

각 호출은 독립된 클로저를 만든다

const a = naturals(3);
const b = naturals(3);

a.next(); // { value: 1, done: false }
a.next(); // { value: 2, done: false }
b.next(); // { value: 1, done: false }, b의 n은 별개!

왜? naturals(3) 을 호출할 때마다 새로운 Function Environment Record 가 힙에 만들어진다. 같은 함수 코드가 실행되더라도, 호출 한 번당 LE 하나. 두 LE 는 메모리상 완전히 별개의 객체이며 서로 간섭하지 않는다.

함수형 모듈 패턴의 기반이기도 하다. 같은 팩토리를 여러 번 호출하면 매번 독립된 “private state” 가 만들어진다.

`for` 루프와 `var` 의 악연

const fns = [];
for (var i = 0; i < 3; i++) {
  fns.push(() => console.log(i));
}
fns[0](); // 3
fns[1](); // 3
fns[2](); // 3

var i 는 함수 스코프이므로 LE 가 루프 전체에 단 하나 만 존재한다. 세 콜백 모두 같은 LE 를 Environment 슬롯으로 가진다. 루프가 끝났을 때 그 LE 의 i 는 3.

let 은 이를 해결한다.

const fns = [];
for (let i = 0; i < 3; i++) {
  fns.push(() => console.log(i));
}
fns[0](); // 0
fns[1](); // 1
fns[2](); // 2

스펙 (ECMA-262 §14.7.4.3) 상 for 문은 let 변수의 경우 매 iteration 마다 별도 Lexical Environment 를 만들어 직전 값을 복사한 뒤 진입한다. 그래서 세 콜백이 가리키는 LE 가 셋 다 다르고, 각자 0, 1, 2 를 가진다.

let 이 단순히 “블록 스코프” 라는 것 이상의 의미를 갖는 지점.

클로저 메모리 누수

DOM 이벤트 핸들러나 setTimeout 콜백에 클로저를 넣을 때 흔히 발생한다.

function attachHandler() {
  const hugeData = new Array(1_000_000).fill('x');

  document.getElementById('btn').addEventListener('click', () => {
    console.log('clicked'); // hugeData를 직접 쓰지 않음
  });
}

hugeData 를 콜백 본문에서 쓰지 않으므로 GC 된다고 생각하기 쉽다. 실제 엔진 동작은 다음과 같다.

V8 등 대부분의 모던 엔진: escape analysis 로 클로저가 실제로 참조하는 변수만 보관 → hugeData 는 회수됨.
그러나 같은 LE 안에서 eval() 이나 new Function() 이 가능할 가능성이 있으면 엔진은 안전을 위해 LE 전체를 통째로 보존 한다.

큰 객체는 명시적으로 끊자.

function attachHandler() {
  let hugeData = new Array(1_000_000).fill('x');
  process(hugeData);
  hugeData = null; // 명시적 해제

  document.getElementById('btn').addEventListener('click', () => {
    console.log('clicked');
  });
}

모듈 패턴, JS 의 진짜 private

ES Modules 이전에 “사적 변수” 를 만드는 정통 패턴이었고, 지금도 유효하다.

const counter = (function () {
  let count = 0; // ← 외부에서 절대 접근 불가
  return {
    inc: () => ++count,
    get: () => count,
    reset: () => (count = 0),
  };
})();

counter.inc();  // 1
counter.inc();  // 2
counter.get();  // 2
counter.count;  // undefined, 직접 접근 불가

count 는 IIFE 호출 시 만들어진 LE 의 Environment Record 에만 존재한다. 반환된 객체의 메서드들이 그 LE 를 Environment 슬롯으로 가지므로 동작은 하지만, 외부에는 노출되지 않는다. 타입스크립트의 #private 필드가 등장하기 전부터 JavaScript 는 이미 진짜 사적 상태를 가지고 있었다.

정리

기초 개념부터 쌓아 다시 보면, 세 질문은 결국 클로저의 세 면이었다.

n 이 어디 사는가 는 Lexical Environment 의 구조 문제다. 호출마다 새로 만들어지는 변수 저장소 + 외부 링크.
왜 GC 되지 않는가 는 함수 객체의 Environment 슬롯 과 힙 참조 사슬 의 문제다. 콜 스택 pop ≠ 객체 회수.
외부 변수와 어떻게 격리되는가 는 ResolveBinding 의 스코프 체인 워킹 이 정의 위치 에 박제된 외부 Environment 참조를 따라가는 메커니즘이다.

세 메커니즘을 한 그림으로 머릿속에 두면, “this 가 왜 이렇게 동작하는지”, “화살표 함수와 일반 함수의 차이”, “async 함수 안에서 await 후에 변수가 어떻게 보존되는지” 같은 후속 질문에도 같은 언어로 답할 수 있게 된다.

ℹ️ 이 글은 ECMAScript 명세(ECMA-262 §9.1, §10.2, §14.7) 및 MDN 자료를 참조하여 AI(Claude)와 함께 작성 되었습니다. 핵심 메커니즘 설명은 명세 기준이며, V8 의 escape analysis 동작은 엔진 구현 디테일이므로 버전에 따라 다를 수 있습니다.

참고 자료

ECMA-262 §9.1 Environment Records
ECMA-262 §10.2 ECMAScript Function Objects
ECMA-262 §9.4 Execution Contexts
ECMA-262 §14.7.4.3 for statement, per-iteration bindings for let
MDN, Closures
MDN, Scope
V8 Blog, JavaScript engine internals

정렬·해시는 메모리가 부족하면 어디로 새는가, PGA, work_mem, Workspace Memory

koa (김신건) — Sat, 13 Jun 2026 00:00:00 GMT

한 문장에서 시작된 의문

“SQL 레벨업”을 읽다가 다음 문단이 눈에 들어왔다.

Oracle에서는 정렬 또는 해시를 위해 PGA라는 메모리 영역을 사용합니다. 이때 PGA 크기가 집약 대상 데이터양에 비해 부족하면, 일시 영역(저장소)을 사용해 부족한 만큼 채웁니다.

저자주: PostgreSQL에서는 work_mem, Microsoft SQL Server에서는 Workspace Memory라는 메모리 영역이 정렬 또는 해시에 사용됩니다. 모두 메모리 영역이 부족해지면 부족한 만큼 보충하고자 일시 영역(물리적으로는 저장소의 파일)을 사용합니다.

세 개의 DBMS, 세 개의 다른 이름. 책은 “부족한 만큼 채운다”는 결과만 말하고 그 사이의 메커니즘은 다루지 않는다.

이 글에서는 다음을 차례로 풀어본다.

정렬·해시는 왜 그렇게 메모리에 욕심을 부리나? → 알고리즘
메모리가 부족할 때 정확히 무엇이 어떻게 디스크로 흘러가나? → 3-tier 모델
Oracle·PostgreSQL·SQL Server는 이 문제를 각각 어떻게 다르게 다루나? → 구현 비교

한 층씩 내려가자.

정렬·해시·Spill의 알고리즘적 본질

대부분의 SQL 연산은 스트리밍으로 동작한다. WHERE 필터, 단순 Index Scan, Nested Loop Join은 한 번에 한 행씩 흘려보내며 처리한다. 입력이 1억 건이든 한 행씩만 메모리에 두면 끝난다.

정렬과 해시는 다르다. 블로킹(blocking) 연산자라고 부른다. 입력 한 쪽(또는 양쪽)을 전부 모은 뒤에야 첫 출력을 낼 수 있다.

왜 그런지 직관적으로 보자.

ORDER BY value, 마지막 행이 들어오기 전까진 어떤 행이 첫 번째인지 알 수 없다.
GROUP BY user_id, 같은 user_id가 흩어져 있을 수 있어 다 모아야 그룹이 완성된다.
Hash Join의 빌드 쪽, 작은 테이블 전체를 해시 테이블로 만들어둬야 큰 테이블 행이 들어올 때 즉시 매칭 검색이 된다.

이 “전체를 모아야 한다”는 요구가 메모리 압박의 근원이다. 그리고 메모리가 부족할 때 두 알고리즘이 어떻게 변신하는지가 이 글의 핵심 주제다.

정렬: Quicksort → External Merge Sort

메모리에 다 들어가는 작은 데이터라면 RDBMS는 [[Quick Sort|Quicksort]] (또는 LIMIT N 최적화 시 [[Heap Sort|Heapsort]]) 를 쓴다. O(n log n) 시간, 디스크 I/O 0. (정렬 알고리즘 전반의 비교는 [[정렬 알고리즘]] 참고.)

문제는 메모리에 안 들어가는 큰 데이터다. 이때 [[External Merge Sort]] 가 등장한다. 직역하면 “외부(=디스크) [[Merge Sort|머지 정렬]]” 이다.

{}

알고리즘은 두 단계다.

1단계, Run 생성(Run Generation): 데이터를 메모리 크기만큼 청크로 잘라 각 청크를 메모리에서 Quicksort한 뒤 디스크에 “Run”이라는 이름의 정렬된 파일로 쓴다. 메모리는 비우고 다음 청크를 받는다.

2단계, K-way Merge: 모든 Run이 만들어지면, 각 Run의 첫 행만 메모리에 둔 채(이게 핵심이다) 가장 작은 값을 골라 출력한다. 출력한 Run의 다음 행을 가져와서 다시 비교. 입력 Run이 K개라면 K개의 작은 “head 버퍼”만 메모리에 두면 된다.

이 두 단계가 외부 정렬의 정체다. 메모리는 청크 정렬용으로 한 번, 머지 head 버퍼용으로 또 한 번 재사용된다.

해시: In-memory Hash → Grace Hash → Hybrid Hash

Hash Join도 비슷하다. 메모리에 들어가는 작은 빌드 테이블이면 그냥 메모리 해시 테이블 하나 만들고 끝. 큰 빌드 테이블이면 어떻게 할까?

답이 Grace Hash Join이다.

{}

핵심 아이디어: 두 테이블을 같은 해시 함수로 N개 파티션으로 나눠 디스크에 쓴다. 같은 키는 같은 번호의 파티션에 들어간다. 그러면 R의 i번째 파티션은 S의 i번째 파티션과만 조인해야 한다. R의 i번째 파티션이 메모리에 들어가는 크기가 되도록 N을 정한다. 그 뒤 i=1,2,…,N에 대해 (Ri, Si) 쌍을 메모리에서 in-memory Hash Join한다.

큰 빌드 전체를 메모리에 못 올려도, N등분된 조각은 메모리에 올라간다.

Hybrid Hash Join은 한 가지 최적화다. 첫 번째 파티션(R1)을 디스크에 쓰지 않고 메모리에 그대로 보관한다. S 행이 들어올 때 첫 번째 파티션이면 메모리의 R1과 즉시 조인, 나머지 파티션이면 디스크로 spill. 빌드가 메모리에 살짝만 초과하는 경우 디스크 I/O를 절반 가까이 절약한다. PostgreSQL과 SQL Server가 모두 이 방식을 쓴다.

두 알고리즘의 공통 메시지

연산	충분할 때	약간 부족할 때	심하게 부족할 때
Sort	Quicksort (I/O 0)	External Merge Sort, 1 머지 패스	External Merge Sort, 다중 머지 패스
Hash	단일 메모리 해시	Hybrid Hash (일부만 spill)	Hash Recursion (파티션을 또 분할)

핵심: 메모리가 부족하면 단순히 느려지는 게 아니라 알고리즘이 통째로 바뀐다. 이 표가 다음 절의 3-tier 비용 모델의 본질이다.

3-tier 모델: Optimal · One-pass · Multi-pass

알고리즘 본 절 뒤끝에 본 세 단계, “충분/약간 부족/심하게 부족”, 에 이름을 붙여보자. Oracle은 명세적으로 이 세 모드를 정의했고, 우리는 그 용어를 보편 모델로 빌려 쓸 수 있다.

{}

Optimal, “그냥 메모리에 들어간다”

가장 빠른 모드. 디스크 I/O가 0이다.

정렬: Quicksort, O(n log n) CPU만 사용
해시: 단일 해시 테이블, Probe는 평균 O(1)
요건: Work Area ≥ 입력 데이터 + 보조 구조(해시 버킷 헤더, 정렬 비교 버퍼 등)

OLTP의 거의 모든 쿼리가 여기 해당한다.

One-pass, “한 번만 디스크 왕복”

이 모드의 비용을 정확히 따져보면 왜 “꽤 저렴하다”는 평이 가능한지 보인다.

정렬: 청크를 메모리에서 정렬해 Run으로 디스크에 쓴다(데이터 1× write). 마지막에 모든 Run을 한 번의 머지 패스로 읽어 출력한다(데이터 1× read). 추가 I/O = 2 × 데이터 크기.
해시: Hybrid Hash로 빌드와 프로브를 한 번씩 디스크 왕복한다.

이게 One-pass라는 이름의 의미다, “한 번의 머지 패스로 끝남”.

그런데 왜 1 GB 정렬이 22 MB 메모리로 충분한가

Oracle 공식 문서가 든 예시가 처음 보면 비현실적으로 들린다. 1 GB 정렬에 22 MB 메모리만 있어도 One-pass로 처리 가능하다고 말한다. 1/45 크기로 어떻게? 외부 정렬의 머지 단계가 무엇을 필요로 하는지 한 번 더 들여다보면 답이 나온다.

K-way Merge 단계의 메모리 요구를 식으로 적어보자.

입력 데이터 크기 = D
가용 메모리 = M
1단계에서 만들어지는 Run 개수 = K = D / M (각 Run 크기는 M)

2단계 머지 시 필요한 메모리:
  각 Run 당 한 페이지 분량의 "head 버퍼" + 출력 버퍼 1개
  머지 메모리 = (K + 1) × 페이지 크기
              ≈ (D / M) × 8 KB

One-pass 가능 조건은 “이 머지 메모리가 가용 메모리 M에 들어맞아야 한다”이다.

(D / M) × 8 KB  ≤  M
→ M² ≥ D × 8 KB
→ M  ≥ √(D × 8 KB)

D = 1 GB로 넣으면 M ≥ √(1 GB × 8 KB) = √(8 × 10¹²) ≈ 약 2.8 MB. 수학적 하한은 3 MB도 안 된다.

Oracle이 보수적으로 22 MB라고 말하는 건 보조 구조와 안전 마진을 합친 실용값일 뿐이다. 같은 식에 D = 10 GB를 넣으면 √(10 GB × 8 KB) ≈ 9 MB → Oracle은 40 MB를 권장한다.

[!TIP] K-way Merge의 메모리는 데이터 크기에 비례하지 않는다. 데이터 크기 D, 페이지 크기 P일 때 √(D × P)에 비례한다. 그래서 한 자릿수 GB의 정렬도 수십 MB로 충분히 처리된다. 외부 머지 정렬의 가장 우아한 성질.

Multi-pass, “여러 번 디스크 왕복”

메모리가 너무 작아 머지 단계조차 한 번에 못 끝낼 때다.

정렬: Run의 일부만 머지해 더 큰 중간 Run을 만들고 다시 디스크에 → 그걸 또 머지 → … 패스 수 K번.
- 추가 I/O = K × 2 × 데이터 크기
해시: Hash Recursion. 파티션 하나가 여전히 메모리에 안 들어가면 그 파티션을 더 잘게 나눠 다시 spill.

10 GB를 5 MB 메모리로 정렬한다고 가정해보자. Run은 √(D × P) 식에서 벗어나 머지 패스가 둘 이상 필요해진다. 패스 수가 K일 때 비용은 K × 2 × 데이터 크기, 즉 K가 2만 돼도 디스크 I/O가 4배다. K=3이면 6배. 응답 시간이 메모리 부족량에 대해 거의 지수적으로 증가한다.

그래서 왜 “Optimal > 90%, One-pass < 10%, Multi-pass = 0%“인가

비용 비대칭을 보면 답이 나온다.

모드	추가 디스크 I/O	운영 정책
Optimal	0	표준 케이스로 만들어야 함
One-pass	2 × 데이터	가끔(대용량 보고서 등) 허용 가능
Multi-pass	K × 2 × 데이터 (K ≥ 2)	거의 모든 경우 SLO 파괴, 절대 피해야 함

One-pass는 평소 0이던 디스크 I/O가 2배로 갑자기 늘어나니까 한 자릿수 초로 끝날 쿼리가 두 자릿수 초로 늘어난다. 가끔이라면 수용 가능하다. Multi-pass는 K가 늘어날 때마다 2배씩 곱해진다. 응답 시간 SLO를 즉시 깨뜨린다.

운영의 안전 목표 “Optimal > 90%, One-pass < 10%, Multi-pass = 0%“는 이 비용 함수에서 자연스럽게 도출된 임계값이다. 가끔 비싼 건 받아들이고, 통제 불능으로 비싼 건 금지한다.

세 DBMS는 같은 문제를 다르게 푼다

여기까지가 보편 이론이다. 이제 각 DBMS가 이 보편 모델을 어떻게 구체화했는지 본다. 세 가지 결정 축이 있다.

메모리 할당 단위: 연산자당? 노드당? 쿼리당?
예약 시점: 실행 중 동적으로? 컴파일 시점에 정적으로?
모니터링 인터페이스: 전용 뷰? 실행 계획 출력? 이벤트?

Oracle, PostgreSQL, SQL Server는 이 세 축에서 모두 다른 답을 선택했다. 그 차이가 실무에서 만나는 함정의 차이로 이어진다.

먼저 가장 성숙한 자동 관리를 가진 Oracle부터.

Oracle, PGA와 자동 관리

왜 SGA가 아니라 PGA인가

Oracle의 메모리는 두 영역으로 깔끔하게 나뉜다.

SGA (System Global Area): 인스턴스 시작 시 잡히는 공유 메모리. Buffer Cache, Shared Pool, Redo Log Buffer 등.
PGA (Program Global Area): 사용자가 접속할 때마다 spawn되는 서버 프로세스마다 사적인 메모리.

{}

정렬·해시 같은 메모리 집약 연산이 SGA를 쓰지 않는 이유는 단순하다. SGA는 모든 세션이 공유하는 자원이라 한 세션이 거대한 정렬을 돌리면 나머지 모든 세션에 영향이 간다. PGA는 사적이라 한 세션이 욕심을 부려도 격리된다. 가격, 더 정확히는 메모리 할당량 관리, 을 분리하기에 자연스럽다.

Work Area의 4개 영역

PGA 안의 Work Area는 메모리 집약 연산자별로 다음 하위 영역을 가진다.

영역	사용 연산자
Sort Area	`ORDER BY`, `DISTINCT`, sort-based `GROUP BY`, `ROLLUP`, 윈도우 함수
Hash Area	Hash Join
Bitmap Merge Area	여러 비트맵 인덱스 결합 (`BitmapAnd`, `BitmapOr`)
Bulk Load Buffer	`INSERT /+ APPEND /` 같은 Direct Path Load

각 영역이 독립적으로 Optimal/One-pass/Multi-pass 상태를 가진다는 점이 중요하다. 같은 쿼리 안에서 Hash Join은 One-pass인데 Sort는 Optimal일 수 있다.

Auto PGA Management, 옛 SORT_AREA_SIZE의 졸업

Oracle 10g 이전엔 SORT_AREA_SIZE, HASH_AREA_SIZE를 DBA가 직접 잡았다. 너무 크게 잡으면 동시 세션이 많을 때 OS 메모리 고갈, 너무 작게 잡으면 모든 쿼리가 Multi-pass.

10g 이후 PGA_AGGREGATE_TARGET 파라미터 하나로 자동 관리된다. 옵티마이저가:

활성 Work Area의 메모리 수요를 추적
개별 Work Area 최대치(global memory bound)를 실행 중 동적으로 조정
가능한 한 많은 작업을 Optimal로 실행

DBA의 일은 이제 “PGA에 얼마를 줄 것인지” 하나로 축소됐다. 이게 Oracle이 가장 성숙한 자동 관리라고 평가받는 이유다.

Spill의 물리적 위치

Optimal을 못 맞춰 spill이 발생하면 데이터는 TEMP 테이블스페이스의 sort segment로 간다. Sort segment는 임시 표공간 안에 자동으로 만들어지고 세션이 끝나면 자동으로 회수된다. DBA가 별도로 정리할 필요가 없다.

그래서 실제로 확인하려면, V$ 뷰

자동 관리는 좋지만 “지금 잘 동작하는지”는 별도로 확인해야 한다. Oracle은 풍부한 동적 성능 뷰를 제공한다.

V$PGASTAT, 인스턴스 전체의 PGA 상황:

지표	의미
`aggregate PGA target parameter`	`PGA_AGGREGATE_TARGET` 현재 값
`global memory bound`	개별 Work Area 최대 크기, < 1 MB이면 적신호
`over allocation count`	PGA가 target을 초과 할당한 횟수 (target 부족 신호)
`cache hit percentage`	Optimal 비율의 종합 지표

cache hit percentage의 계산식이 흥미롭다.

BP  = 처리한 전체 바이트
EBP = 추가 패스에서 다시 읽고 쓴 바이트 (One-pass + Multi-pass의 extra I/O)

cache hit % = BP × 100 / (BP + EBP)

100%면 모든 Work Area가 Optimal. Multi-pass가 많아지면 EBP가 BP를 압도하면서 비율이 급락한다. 앞 절의 비용 모델이 그대로 메트릭에 박혀있다.

V$WORKAREA_ACTIVE, 지금 실행 중인 Work Area들:

PASS 컬럼이 3-tier 모델 그 자체다: 0이면 Optimal, 1이면 One-pass, ≥ 2면 Multi-pass. TSIZE는 temp segment 사용량.

운영 룰: PASS ≥ 2가 하나라도 보이면 PGA_AGGREGATE_TARGET을 다시 보자.

PostgreSQL, work_mem과 단위의 함정

Oracle은 자동 관리가 매력이었다. PostgreSQL은 정반대 철학이다, 단순하고 예측 가능하지만, 단위가 작아서 위험하다.

”쿼리당”이 아니라 “노드당”이다

PostgreSQL 공식 문서의 한 문장:

Sets the base maximum amount of memory to be used by a query operation (such as a sort or hash table) before writing to temporary disk files.

“per query operation”, 쿼리 하나가 아니라 실행 계획의 연산 노드 하나가 사용할 수 있는 양이다.

예를 들어 다음 쿼리:

SELECT u.name, COUNT(*) FROM users u
JOIN orders o ON u.id = o.user_id
JOIN payments p ON o.id = p.order_id
WHERE u.region = 'KR'
GROUP BY u.name
ORDER BY 2 DESC;

실행 계획에는 보통 Sort 1개 + HashAggregate 1개 + Hash Join 2개 = 노드 4개가 등장한다. 각각이 따로 work_mem을 받아 쓸 수 있다. 즉 한 쿼리가 최대 4 × work_mem까지 메모리를 차지한다. 거기에 parallel worker마다 같은 양이 곱해진다.

기본값 work_mem = 4 MB. 별것 아닌 듯하지만 동시 세션 100개 × 노드 4개 = 1.6 GB. parallel worker 4개라면 6.4 GB가 정렬·해시에만 잡힌다.

[!CAUTION] 흔한 실수: “쿼리가 느리니 work_mem을 256 MB로 올리자.” 동시 세션 100 × 노드 4 × parallel 4 = 400 GB. OOM 직행.

Oracle이 PGA 총량 하나만 잡으면 옵티마이저가 알아서 분배하는 방식이라면, PostgreSQL은 노드 하나 노드 하나에 정적인 상한을 거는 방식이다. 그래서 work_mem 값 자체보다 **“동시에 얼마나 많은 노드가 활성화되는가”**가 실제 메모리 압력을 결정한다.

hash_mem_multiplier, 해시만 따로 챙기기

해시는 보통 정렬보다 메모리에 더 민감하다. 한 번 한도를 넘으면 Hash Recursion으로 비용이 급증하기 때문이다. PostgreSQL 13부터 별도 곱셈을 도입했다.

Sort 한도   = work_mem
Hash 한도   = work_mem × hash_mem_multiplier  (default 2.0)

해시 한도가 정렬 한도의 2배. 공식 문서는 spill이 빈번하면 multiplier를 2.0 ~ 8.0 범위로 올리라고 권장한다.

EXPLAIN ANALYZE에서 spill 신호 읽기

Oracle은 별도 뷰가 있었지만, PostgreSQL은 모든 정보를 EXPLAIN ANALYZE 출력에 박아둔다. 다른 곳을 볼 필요가 없는 대신, 출력을 정확히 읽을 줄 알아야 한다.

Sort 노드:

Sort  (cost=713.05..713.30 rows=100 width=488)
  Sort Key: t1.fivethous
  Sort Method: quicksort  Memory: 74kB

Sort Method가 3-tier의 어느 모드인지 알려준다.

quicksort Memory: NN kB → Optimal (메모리 내 정렬)
top-N heapsort Memory: NN kB → LIMIT N 최적화, 여전히 Optimal
external merge Disk: NN kB → Spill 발생! 디스크에 NN kB 사용 (One-pass 또는 Multi-pass)

Hash 노드:

Hash  (cost=224.98..224.98 rows=100 width=244)
  Buckets: 1024  Batches: 1  Memory Usage: 35kB

Batches가 Grace/Hybrid Hash Join의 파티션 개수다.

Batches: 1 → 빌드 전체가 메모리 (Optimal)
Batches: 2 이상 → Hybrid Hash로 spill (One-pass에 해당)
실행 중 Batches가 power-of-2로 점점 커지는 EXPLAIN → 빌드 추정이 틀려 runtime에 추가 분할 (Multi-pass의 일종)

[!IMPORTANT] PG 공식 문서가 짚는 디테일: “If the number of batches exceeds one, there will also be disk space usage involved, but that is not shown.” 즉 디스크 사용량은 EXPLAIN 기본 출력에 안 찍힌다. EXPLAIN (ANALYZE, BUFFERS)를 쓰면 temp read=NN written=MM 카운터로 간접 확인 가능하다.

시스템 차원의 spill 추적

-- 모든 임시 파일 생성을 로그에 기록
SET log_temp_files = 0;

-- 데이터베이스별 누적 통계
SELECT datname, temp_files, pg_size_pretty(temp_bytes) AS temp
FROM pg_stat_database
WHERE temp_files > 0;

물리적 spill 파일은 $PGDATA/base/pgsql_tmp/에 만들어진다. temp_file_limit(기본 -1 = 무제한)으로 프로세스당 한도를 줄 수 있다.

PG 13의 결정적 변화

PostgreSQL 13 이전까지 HashAggregate는 work_mem을 초과해도 메모리에서 끝까지 처리하려 했고, 종종 OOM을 유발했다. 13부터 disk-based hash aggregation이 도입되어 정상적으로 spill한다. 13으로 올린 직후 “메모리 사용량이 줄어든 것 같은데 EXPLAIN에 temp가 보인다”고 놀라는 경우가 많은데, 이게 정상 동작이다.

SQL Server, 정적 예약과 적응형 학습

Oracle도 PostgreSQL도 실행 중에 메모리를 동적으로 할당한다. SQL Server는 이 부분에서 근본적으로 다른 길을 택했다, 쿼리 시작 전에 필요량을 다 예약한다.

컴파일 타임에 모든 메모리를 예약한다

쿼리가 컴파일될 때 옵티마이저가 다음을 추정한다.

정렬에 NN MB 필요
해시 빌드에 MM MB 필요
→ Memory Grant(요청 메모리)로 합산

쿼리 실행이 시작되려면 먼저 Resource Semaphore라는 게이트에서 grant를 받아야 한다. grant가 부족하면 RESOURCE_SEMAPHORE 대기 상태로 대기열에 줄을 선다.

이 메모리는 buffer pool 내 한 영역, Workspace Memory에서 떼어진다. max server memory로 제어되는 동일한 풀이다.

Row mode vs Batch mode, Spill의 결정적 분기

이 정적 예약이 만든 한 가지 잔혹한 규칙이 있다.

Row mode (전통적 실행)

Microsoft 공식 문서:

For row mode execution, the initial memory grant can’t be exceeded under any condition. If more memory than the initial grant is needed to execute hash or sort operations, then the operations spill to disk.

initial grant는 절대 초과할 수 없다. 컴파일 타임 추정이 틀려서 실행 중 메모리가 모자라도 즉시 tempdb로 spill한다. Oracle/PG처럼 “조금만 더”가 불가능하다. SQL Server에서 통계가 낡았을 때 spill이 폭주하는 이유다.

Batch mode (컬럼스토어 + 2019부터 rowstore도 가능)

For batch mode execution, the initial memory grant can dynamically increase up to a certain internal threshold by default.

Batch mode에서는 grant가 실행 중 동적으로 확장될 수 있다. Row/Batch mode의 차이가 SQL Server를 다른 두 DBMS와 결정적으로 갈라놓는다.

Spill의 두 종류

Microsoft는 정렬과 해시의 spill 저장 형태를 따로 부른다.

Sort Spill, Worktable in tempdb (Sort Warning 이벤트)
Hash Spill, Workfile in tempdb (Hash Warning 이벤트)

Hash spill에는 두 하위 케이스가 있다.

Hash Recursion: 빌드가 메모리에 안 들어가서 파티션으로 쪼개고, 그 파티션이 또 안 들어가면 더 잘게 쪼개고… (앞 절의 Hash Recursion과 동일)
Hash Bailout: 최대 재귀 깊이에 도달했을 때 다른 plan으로 폴백. 이때부터는 거의 sequential 스캔에 가까운 비용으로 떨어진다.

Memory Grant Feedback, SQL Server만의 적응형 학습 (2017+)

SQL Server는 정적 예약의 약점을 자체 학습 메커니즘으로 보완했다. 같은 쿼리가 반복 실행될 때 실제 사용량을 plan cache에 기록해서 다음 컴파일 시 grant를 조정한다.

Row mode(2019+)에도 도입되어, “통계가 틀려서 spill하던 쿼리가 두세 번 실행 후 spill이 사라지는” 자동 학습이 가능해졌다. 정적 예약 + 사후 피드백이라는 하이브리드 전략이다.

DMV로 grant 추적

-- 진행 중인 grant들
SELECT session_id,
       requested_memory_kb,
       granted_memory_kb,
       used_memory_kb,
       ideal_memory_kb,
       wait_time_ms
FROM sys.dm_exec_query_memory_grants
ORDER BY requested_memory_kb DESC;

해석:

requested >> used → grant 과대 추정 (통계 부정확 또는 grant feedback이 학습 중)
granted < requested로 대기 누적 → 동시성에 비해 grant가 너무 후함
RESOURCE_SEMAPHORE 대기 비율 상승 → 큰 쿼리들이 grant 가뭄으로 줄 서는 중

Extended Events에서 sort_warning, hash_warning을 활성화하면 spill이 발생할 때마다 이벤트가 떨어진다.

같은 그림, 다른 이름, 한 장 비교표

세 DBMS가 같은 3-tier 비용 모델을 어떻게 다르게 구체화했는지 한 표로:

측면	Oracle	PostgreSQL	SQL Server
메모리 영역 이름	PGA Work Area	work_mem	Workspace Memory (Memory Grant)
할당 단위	연산자당 (Work Area)	노드당 (per plan node)	쿼리당 (사전 합산)
예약 시점	동적 (실행 중 조정)	동적 (실행 중 조정)	정적 (Row mode) / 동적 (Batch mode)
임시 영역 위치	TEMP의 sort segment	`base/pgsql_tmp/`	tempdb의 Worktable(Sort)·Workfile(Hash)
3-tier 신호	`V$WORKAREA_ACTIVE.PASS` (0/1/≥2)	`Sort Method: external merge`, `Batches: N`	Spill 경고, XEvent (`sort_warning`, `hash_warning`)
적응형 학습	Auto PGA Management	,	Memory Grant Feedback (2017+)
주요 튜닝 파라미터	`PGA_AGGREGATE_TARGET`, `PGA_AGGREGATE_LIMIT`	`work_mem`, `hash_mem_multiplier`, `maintenance_work_mem`	`min memory per query`, `max server memory`

세 가지 인사이트:

PostgreSQL은 단위가 작아 (per node × per worker) 곱이 무서움. work_mem을 함부로 못 올리는 이유.
SQL Server는 컴파일 타임 예약이라 통계 부정확이 spill로 직결됨. Grant Feedback이 이 약점을 보완.
Oracle은 자동 관리가 가장 성숙하지만 PGA_AGGREGATE_TARGET이 너무 작으면 multi-pass 전체로 무너짐.

정리

책의 한 문장 “메모리가 부족하면 일시 영역을 쓴다”의 안쪽에는 알고리즘 차원, 모드 차원, 구현 차원의 세 층이 숨어 있었다.

알고리즘 차원: 정렬·해시는 본래 메모리 내 알고리즘(Quicksort, In-memory Hash)으로 설계되었지만, 메모리가 부족해지면 External Merge Sort · Hybrid Hash Join 같은 다른 알고리즘으로 통째로 전환된다. 단순히 “조금 느려진다”가 아니라 다른 알고리즘이 돌아간다.

모드 차원: 그 전환의 비용은 메모리가 얼마나 부족하냐에 따라 단계가 있다. Optimal → One-pass → Multi-pass. K-way Merge의 메모리 요구는 √(D × P)에 비례하므로, 1 GB 정렬에 22 MB 정도면 One-pass로 충분히 처리된다. 하지만 Multi-pass에 빠지면 비용이 K배수로 곱해진다.

구현 차원: 세 DBMS가 같은 문제를 다른 방식으로 해결한다.

Oracle: 자동 관리, V$ 뷰로 명시적 추적, PGA per-process 격리.
PostgreSQL: 노드당 메모리, EXPLAIN ANALYZE에 모든 정보, parallel 곱셈의 함정.
SQL Server: 정적 예약 + 적응형 피드백, Row/Batch mode 분기, tempdb spill.

[!IMPORTANT] 가장 위험한 실수는 셋 다 공통이다, “안 보이니 없는 줄 안다.”

EXPLAIN / 동적 뷰 / XEvent에 external merge Disk, Batches: N (N>1), PASS >= 1, Sort Warning 같은 신호가 보이면 메모리 부족이 발생한 것이고, 이건 단순한 느려짐이 아니라 알고리즘 모드 전환이라는 점을 기억하자.

익숙한 DB일수록 EXPLAIN 한 줄을 더 자세히 읽을 가치가 있다.

ℹ️ 이 글은 “SQL 레벨업”의 한 문단을 출발점으로 삼아, 공식 문서(Oracle Database Performance Tuning Guide, PostgreSQL Docs, Microsoft Learn)를 참조하여 AI(Claude)와 함께 작성되었습니다. 알고리즘 설명과 비교표의 사실 관계는 아래 참고 자료 기준으로 검증했으나, 운영 환경에서 적용할 때는 각 DBMS의 해당 버전 문서를 다시 확인하길 권합니다.

참고 자료

Oracle Database Performance Tuning Guide, Tuning the Program Global Area
PostgreSQL Docs, 19.4. Resource Consumption (work_mem, hash_mem_multiplier)
PostgreSQL Docs, 14.1. Using EXPLAIN (Sort Method, Buckets/Batches)
Microsoft Learn, Memory Management Architecture Guide (SQL Server)
Microsoft Learn, Memory Grant considerations
External Merge Sort, Grace Hash Join, Hybrid Hash Join, Database Systems: The Complete Book (Garcia-Molina, Ullman, Widom) §15

UNION vs OR vs IN 벤치마크 (1), 실험 설계와 결과

koa (김신건) — Sat, 13 Jun 2026 00:00:00 GMT

동기: “OR은 인덱스를 못 탄다”는 게 진짜일까?

“SQL 레벨업”이라는 책을 읽다가 UNION을 사용할 수밖에 없는 경우로 소개되는 사례가 눈에 들어왔다.

서로 다른 테이블이라면 당연히 UNION을 사용해야 한다. 하지만 같은 테이블에서도, 서로 다른 컬럼에 대한 OR 조건이 걸리면 인덱스를 활용할 수 없으므로 UNION ALL로 분리해야 한다.

PostgreSQL을 주로 쓰는 입장에서 두 가지 의문이 생겼다.

IN으로 쓰면 오히려 더 빠르지 않을까?, (col_a, col_b) IN ((v1, v2)) 형태가 옵티마이저에게 더 많은 정보를 줄 것 같았다.
OR도 생각보다 괜찮지 않을까?, PostgreSQL은 뭔가 다르게 처리하는 것 같은 느낌이 있었다.

추측만으로 판단하긴 싫어서, Docker Compose로 PostgreSQL 3개 버전(13/15/17)과 MySQL 3개 버전(5.7/8.0/8.4)을 띄우고 직접 벤치마크를 돌려보기로 했다.

실험 설계

테이블 구조: Sparse Multi-Column

하나의 행에 50개의 (date_N, bool_N) 쌍이 있되, 정확히 하나의 쌍만 값이 있고 나머지는 NULL인 구조다. 현실에서 이벤트 타입별 메타데이터가 다른 테이블을 하나로 합친 것, 또는 다형성을 가진 엔티티 테이블과 유사하다.

CREATE TABLE bench_target (
    id BIGSERIAL PRIMARY KEY,
    date_1 DATE, bool_1 BOOLEAN,   -- 쌍 1
    date_2 DATE, bool_2 BOOLEAN,   -- 쌍 2
    ...
    date_50 DATE, bool_50 BOOLEAN, -- 쌍 50
    payload TEXT
);

-- 각 쌍에 복합 인덱스
CREATE INDEX idx_pair_1 ON bench_target (date_1, bool_1);
CREATE INDEX idx_pair_2 ON bench_target (date_2, bool_2);
...
CREATE INDEX idx_pair_50 ON bench_target (date_50, bool_50);

핵심은 각 행이 50개 쌍 중 딱 하나에만 데이터를 가진다는 점이다. 따라서 date_1 = '2024-03-15' AND bool_1 = TRUE를 찾으면 idx_pair_1이 매우 효율적으로 동작해야 한다. 문제는 이런 조건을 여러 쌍에 대해 동시에 걸 때 발생한다.

세 가지 쿼리 변형

같은 데이터를 조회하는 세 가지 SQL 문법:

재현성을 위한 환경 통제

Docker Compose로 각 버전을 격리 (CPU/mem pinned)
Prepared statement 미사용 → 파싱 비용까지 포함하여 통일
동일 시드로 데이터 생성 → 동일 조건으로 비교
Cross-DBMS 절대 비교 금지: 같은 DB 내에서 변형 간 비교만 유효

결과 요약

PostgreSQL: 세 변형 모두 비등

쌍 수 (n)	Tuple IN	OR 조건	UNION ALL	Plan
1	0.002 ms	0.003 ms	0.002 ms	Index Scan
3	0.004	0.005	0.005	BitmapOr / Append
5	0.007	0.007	0.007	BitmapOr / Append
10	0.013	0.014	0.018	BitmapOr / Append
20	0.031	0.023	0.036	BitmapOr / Append
50	0.066	0.077	0.096	BitmapOr / Append

[!NOTE] 모든 수치가 0.1ms 이하. 변형 간 차이는 stddev 범위 내에 있어 유의미하지 않다.

MySQL: UNION ALL 압승, IN/OR는 Full Table Scan

쌍 수 (n)	Tuple IN	OR 조건	UNION ALL	IN/OR Plan	UNION Plan
1	0.002	0.002	0.002	ref (인덱스)	ref
3	40.35	40.35	0.006	ALL (풀스캔)	ref
5	45.10	44.55	0.013	ALL	ref
10	56.05	56.15	0.028	ALL	ref
20	77.50	80.50	0.055	ALL	ref
50	148.0	147.0	0.158	ALL	ref

[!CAUTION] 쌍이 2개 이상이면 IN/OR 모두 Full Table Scan으로 퇴화. n=50에서 UNION ALL 대비 약 900배 느리다.

MySQL 버전별 비교: 5.7 → 8.0 → 8.4

버전 업으로 해결되지 않는다. 5.7/8.0/8.4 모두 동일하게 Full Table Scan을 선택한다.

I/O 블록 비교

의외의 발견: IN과 OR의 성능이 같다

실험 전에는 “OR은 느리고 IN은 빠를 것”이라고 예상했다. 튜플 IN이 옵티마이저에게 더 구조화된 정보를 줄 거라 생각했기 때문이다.

하지만 결과는:

PostgreSQL: IN과 OR 모두 동일한 BitmapOr 플랜. 플래너가 내부적으로 같은 형태로 변환.
MySQL: IN과 OR 모두 동일하게 Full Table Scan. 둘 다 “여러 컬럼에 걸친 OR”로 인식됨.

(col_a, col_b) IN ((v1, v2)) 는 결국 col_a = v1 AND col_b = v2로 해석되므로, 최종적으로 OR로 연결된 것과 동일하게 처리된다. “IN이 OR보다 빠르다”는 통념은 이 패턴에서는 맞지 않는다.

[!TIP] “IN이 OR보다 빠르다”가 유효한 경우는 같은 컬럼에 대한 여러 값 (WHERE id IN (1,2,3) vs WHERE id=1 OR id=2 OR id=3)일 때다. 서로 다른 컬럼에 걸친 OR과는 완전히 다른 시나리오.

실무 적용

상황	PostgreSQL	MySQL
1개 쌍 조회	아무 방식 OK	아무 방식 OK
2개+ 서로 다른 컬럼 쌍	아무 방식 OK	반드시 UNION ALL
50개 쌍 조회	0.07~0.10 ms	UNION: 0.16 ms / IN·OR: 148 ms

[!IMPORTANT] MySQL 사용자라면 서로 다른 컬럼에 걸친 OR/IN 조건이 2개 이상일 때 반드시 UNION ALL로 분리해야 한다. ORM이 자동으로 OR을 생성한다면 raw query로 UNION을 직접 작성하자.

벤치마크 코드: 쿼리 생성기

실험의 핵심인 쿼리 생성 로직을 공유한다. 세 변형을 동일한 조건에서 생성하는 Python 코드:

class QueryGenerator:
    """각 쌍에 대해 세 가지 SQL 변형을 생성."""
    TABLE = "bench_target"

    def generate_conditions(self, count: int) -> list[tuple[int, str]]:
        """count개의 서로 다른 쌍 인덱스와 날짜를 결정론적으로 생성."""
        available_pairs = list(range(1, 51))
        self._rng.shuffle(available_pairs)
        pairs = available_pairs[:count]
        conditions = []
        for pair_idx in pairs:
            days_offset = self._rng.randint(0, DATE_RANGE_DAYS - 1)
            d = BASE_DATE + timedelta(days=days_offset)
            conditions.append((pair_idx, d.isoformat()))
        return conditions

    def _build_or(self, conditions, engine):
        """OR 방식: (date_N='X' AND bool_N=TRUE) OR ..."""
        bool_val = "TRUE" if engine == "postgres" else "1"
        clauses = " OR ".join(
            f"(date_{idx} = '{dt}' AND bool_{idx} = {bool_val})"
            for idx, dt in conditions
        )
        return f"SELECT id, payload FROM {self.TABLE} WHERE {clauses}"

    def _build_union(self, conditions, engine):
        """UNION ALL 방식: 각 조건을 독립 SELECT로."""
        bool_val = "TRUE" if engine == "postgres" else "1"
        queries = [
            f"SELECT id, payload FROM {self.TABLE} "
            f"WHERE date_{idx} = '{dt}' AND bool_{idx} = {bool_val}"
            for idx, dt in conditions
        ]
        return " UNION ALL ".join(queries)

    def _build_tuple_in(self, conditions, engine):
        """Tuple IN 방식: (date_N, bool_N) IN (('X', TRUE)) OR ..."""
        bool_val = "TRUE" if engine == "postgres" else "1"
        clauses = " OR ".join(
            f"(date_{idx}, bool_{idx}) IN (('{dt}', {bool_val}))"
            for idx, dt in conditions
        )
        return f"SELECT id, payload FROM {self.TABLE} WHERE {clauses}"

핵심 포인트:

동일한 conditions 를 세 변형에 모두 전달하여, 정확히 같은 데이터를 조회
시드 고정(seed=42)으로 재현성 보장
50개 쌍 중 랜덤하게 n개를 선택하여 각각에 대한 날짜 조건 생성

다음 글에서

결과는 확인했다. 그런데 왜 이런 차이가 발생하는 걸까?

PostgreSQL에서 세 변형이 모두 빠른 이유는 Bitmap Scan이라는 고유한 메커니즘 때문이다. 다음 글에서는 BitmapOr가 어떻게 여러 인덱스를 하나로 합치는지, TID Bitmap의 내부 구조는 어떤지, 그리고 MySQL은 왜 이를 할 수 없는지를 깊이 다룬다.

참고

측정: EXPLAIN ANALYZE actual time, warmup 3회 + 10회 반복, p50/p95/p99/stddev

UNION vs OR vs IN 벤치마크 (2), PostgreSQL BitmapOr 완전 해부

koa (김신건) — Sat, 13 Jun 2026 00:00:00 GMT

왜 “전통적 Index Scan”으로는 부족한가

일반적인 Index Scan의 동작을 먼저 이해하자.

인덱스 리프 노드에서 TID를 하나 꺼냄
  → 해당 TID가 가리키는 테이블 페이지로 이동
  → 행을 읽음
  → 다음 TID를 꺼냄
  → 또 다른 테이블 페이지로 이동
  → ...

여기서 TID란 Tuple ID = (페이지 번호, 페이지 내 오프셋)으로, 행의 물리적 위치를 가리키는 주소다.

이 방식에는 두 가지 한계가 있다:

Random I/O: 결과가 여러 페이지에 흩어져 있으면, 매번 다른 페이지로 점프해야 함
단일 인덱스 제약: 하나의 인덱스에서만 TID를 가져올 수 있음. 서로 다른 인덱스의 결과를 “합칠” 방법이 없음

우리 벤치마크의 상황을 생각해보자:

WHERE (date_1 = 'X' AND bool_1 = TRUE)    -- idx_pair_1 사용
   OR (date_5 = 'Y' AND bool_5 = TRUE)    -- idx_pair_5 사용
   OR (date_12 = 'Z' AND bool_12 = TRUE)  -- idx_pair_12 사용

세 조건은 각각 다른 인덱스를 타야 한다. Index Scan은 하나의 인덱스만 선택할 수 있으므로, 나머지 두 조건은 필터로 처리하거나 포기해야 한다. 이것이 MySQL이 Full Table Scan을 선택하는 이유이기도 하다.

Bitmap Scan: 중간 추상 계층의 도입

PostgreSQL은 이 문제를 Bitmap이라는 중간 자료구조를 도입하여 해결한다.

핵심 아이디어: 인덱스 결과를 즉시 행으로 가져오지 않고, “어떤 페이지를 방문해야 하는지”를 먼저 메모리에 기록한 뒤, 나중에 한 번에 읽는다.

이 아이디어 덕분에:

여러 인덱스의 결과를 비트 연산으로 합칠 수 있고 (BitmapOr / BitmapAnd)
페이지를 물리적 순서대로 방문하여 I/O를 최적화할 수 있다

{}

3단계로 이해하는 Bitmap Scan

1단계: BitmapIndexScan, 비트맵 생성

각 인덱스를 B-tree로 탐색하여 조건에 맞는 행들의 **위치(TID)**를 비트맵으로 수집한다.

이 비트맵은 행 자체가 아니라, “테이블의 몇 번 페이지에 결과가 있다”는 위치 정보를 담는다.

idx_pair_1에서 date_1='2024-03-15' AND bool_1=TRUE 스캔 결과:
  → Bitmap A: 페이지 42에 행 3개, 페이지 156에 행 1개

idx_pair_5에서 date_5='2024-07-01' AND bool_5=TRUE 스캔 결과:
  → Bitmap B: 페이지 12에 행 1개, 페이지 42에 행 2개

idx_pair_12에서 date_12='2024-11-20' AND bool_12=TRUE 스캔 결과:
  → Bitmap C: 페이지 200에 행 1개, 페이지 891에 행 1개

이 단계에서는 테이블 데이터를 전혀 읽지 않는다. 인덱스만 탐색한다.

2단계: BitmapOr, 비트맵 합치기

여러 비트맵을 메모리 내 비트 OR 연산으로 합친다.

Bitmap A:  {42, 156}
Bitmap B:  {12, 42}
Bitmap C:  {200, 891}

OR 결과:   {12, 42, 156, 200, 891}

이 연산은:

순수 메모리 내 비트 연산이므로 디스크 I/O가 0
시간 복잡도는 비트맵 크기에 비례 (보통 수십~수백 KB)
페이지 42가 A와 B 모두에 있지만, 결과에는 한 번만 등장 → 중복 제거 자동

3단계: BitmapHeapScan, 페이지 순서대로 읽기

합쳐진 비트맵의 페이지를 물리적 번호 순서대로 방문한다.

페이지 12  → 읽고 → 조건 Recheck → 매칭 행 반환
페이지 42  → 읽고 → 조건 Recheck → 매칭 행 반환
페이지 156 → 읽고 → 조건 Recheck → 매칭 행 반환
페이지 200 → 읽고 → 조건 Recheck → 매칭 행 반환
페이지 891 → 읽고 → 조건 Recheck → 매칭 행 반환

물리적 순서대로 방문하므로:

HDD에서는 디스크 헤드 이동 최소화
SSD에서도 OS read-ahead(선읽기) 효과 활용 가능
결과적으로 Sequential I/O에 가까운 효율

실제 EXPLAIN으로 확인

해석:

Bitmap Index Scan × 5: 5개의 서로 다른 인덱스를 각각 스캔. 인덱스 2블록씩 = 10블록
BitmapOr: 5개의 비트맵을 OR로 합침 (I/O 0, 시간 0.003ms 미만)
Bitmap Heap Scan: 합쳐진 비트맵 기준 3개 페이지만 방문 = 3블록
총 I/O: 13블록. 10만 행 테이블에서 13블록만 읽고 완료.

UNION ALL vs BitmapOr: 같은 비용, 다른 경로

	UNION ALL (Append)	OR (BitmapOr)
총 I/O 블록	13	13
Planning Time	0.134 ms	0.042 ms
Execution Time	0.008 ms	0.007 ms
페이지 방문 순서	보장 없음	물리적 순서
중복 페이지 제거	불가능	자동

실행 시간 차이는 무시할 수준. Planning Time은 UNION ALL이 약간 더 높은데, 각 SELECT를 개별 최적화해야 하기 때문이다.

TID Bitmap의 내부 구조

여기서부터가 핵심이다. PostgreSQL의 비트맵(src/backend/nodes/tidbitmap.c)은 단순한 bit 배열이 아니라, 메모리 효율을 위한 정교한 구조를 가지고 있다.

”비트맵”이란 정확히 무엇인가

PostgreSQL에서 테이블은 8KB 페이지의 연속이다. 각 페이지에는 여러 행(tuple)이 담긴다. TID Bitmap은 이 구조를 이용한다.

비유하자면:

테이블 = 거대한 책
페이지 = 책의 쪽
행 = 쪽 안의 특정 줄
TID Bitmap = “몇 쪽의 몇 번째 줄을 읽어야 하는지” 표시한 메모

두 가지 해상도: Exact vs Lossy

비트맵은 메모리 사정에 따라 두 가지 모드로 동작한다.

Exact 모드 (기본)

페이지 번호 + **해당 페이지 내 행의 정확한 위치(offset)**를 비트로 기록한다.

페이지 42: [bit 3 = ON, bit 7 = ON, bit 9 = ON]  → 3번, 7번, 9번 행만 해당
페이지 156: [bit 1 = ON]                          → 1번 행만 해당

8KB 페이지에는 보통 수십~수백 행이 들어가므로, 한 페이지당 약 226행(MaxHeapTuplesPerPage) = 226비트 ≈ 29바이트의 비트맵이 필요하다.

장점: 페이지를 읽을 때 정확히 어떤 행이 필요한지 알므로, 불필요한 행을 건너뛸 수 있다.

Lossy 모드 (메모리 부족 시)

페이지 번호만 기록한다. “이 페이지 어딘가에 결과가 있다”만 아는 상태.

페이지 42: [전체 페이지 표시]  → 어딘가에 결과가 있음 (정확히 어디인지는 모름)
페이지 156: [전체 페이지 표시]

장점: 한 페이지당 1비트만 필요. 메모리 극적으로 절약. 단점: 페이지를 읽을 때 모든 행에 대해 조건을 다시 확인(Recheck)해야 함.

전환 메커니즘

비트맵 크기가 work_mem을 초과하면, 가장 행이 많은 페이지부터 Lossy로 전환한다.

flowchart TD
    A[BitmapIndexScan 시작] --> B[TID를 비트맵에 추가]
    B --> C{"비트맵 크기 > work_mem?"}
    C -->|No| D[Exact 모드 유지]
    C -->|Yes| E["Lossy 모드로 전환<br/>(행 offset 비트 삭제)"]
    D --> F[Heap Scan 시 해당 행만 반환]
    E --> G["Heap Scan 시 페이지 전체 읽고<br/>조건 Recheck"]

EXPLAIN 결과에서 이를 확인할 수 있다:

Heap Blocks: exact=1234 lossy=56

exact=1234: 1,234개 페이지는 행 단위 정밀도 → Recheck 불필요 (정확한 행만 반환)
lossy=56: 56개 페이지는 페이지 단위만 알고 있음 → 해당 페이지의 모든 행을 조건으로 다시 필터

메모리 효율 계산

Exact 모드: 1페이지 당 ~29바이트 → 1GB 테이블(131,072 페이지) ≈ 3.6MB 비트맵
Lossy 모드: 1페이지 당 1비트 → 1GB 테이블 ≈ 16KB 비트맵
64GB 테이블 전체를 Lossy에서 약 1MB로 표현 가능

대부분의 실무 쿼리에서는 결과가 테이블의 극히 일부이므로, 비트맵은 수십~수백 KB 수준이다. work_mem의 기본값(4MB)으로도 충분한 경우가 대부분.

왜 “Recheck Cond”가 항상 출력되는가

EXPLAIN에서 Bitmap Heap Scan의 Recheck Cond 표시를 본 적 있을 것이다:

Bitmap Heap Scan on bench_target
  Recheck Cond: ((date_1 = '2024-03-15') AND (bool_1 = true)) OR ...

이것은 “이 조건으로 Recheck합니다”라는 의미인데, 항상 표시된다. Exact 모드에서도 표시되지만, 실제로는 Exact 페이지에서는 Recheck를 건너뛸 수 있다. PostgreSQL은 “혹시 Lossy 페이지가 있을 수 있으니” 항상 준비해두는 것이다.

실제로 Lossy가 발생했는지는 Heap Blocks: exact=... lossy=...에서 확인한다.

BitmapAnd, 교집합도 가능하다

BitmapOr가 합집합(OR)이라면, BitmapAnd는 교집합(AND)이다.

-- 복합 조건이 각각 다른 단일 컬럼 인덱스에 걸릴 때
WHERE col_a = 'x' AND col_b = 'y'
-- idx_a의 비트맵 AND idx_b의 비트맵 → 교집합 페이지만 방문

비트맵이라는 중간 계층 덕분에 OR/AND 어떤 조합이든 여러 인덱스를 자유롭게 결합할 수 있다.

플래너는 언제 Bitmap Scan을 선택하는가

PostgreSQL 플래너는 비용 모델을 기반으로 세 가지 스캔 방식 중 하나를 선택한다:

상황	Index Scan	Bitmap Scan	Seq Scan
결과 행 수	소수 (수십 이하)	중간 (수십~수만)	대량 (>10-20%)
결과 분포	한 곳에 집중	여러 페이지에 분산	-
OR 조건	같은 인덱스 내	다른 인덱스에 걸침	-
I/O 특성	Random (허용)	Sequential-like	Sequential

우리 벤치마크에서도 확인된다:

n=1: 결과가 극소수 + 단일 인덱스 → Index Scan 선택
n≥3: 여러 인덱스 필요 + 결과가 분산 → BitmapOr 선택

비용 계산:

Bitmap Scan 비용 = Σ(인덱스 스캔) + 비트맵 OR 비용(거의 0) + 방문 페이지 × seq_page_cost
Index Scan 비용 = 인덱스 탐색 + 결과 행 × random_page_cost

페이지를 순서대로 읽으므로 seq_page_cost(기본 1.0)가 적용되는 반면, Index Scan은 random_page_cost(기본 4.0)가 적용된다. 결과가 많을수록 Bitmap Scan이 유리해진다.

왜 MySQL은 이것을 할 수 없는가

MySQL에도 Index Merge Union이라는 유사한 기능이 존재한다. 하지만 근본적인 차이가 있다.

MySQL Index Merge의 동작 방식

-- MySQL에서 Index Merge가 작동하는 경우
WHERE col_a = 1 OR col_b = 2
-- idx_a 스캔 → rowid 목록A
-- idx_b 스캔 → rowid 목록B
-- 목록A ∪ 목록B → 행 fetch

핵심 제약: “각 OR 브랜치가 단일 인덱스로 완전히 해결 가능해야”

-- ❌ MySQL에서 Index Merge 불가
WHERE (date_1 = 'X' AND bool_1 = TRUE)
   OR (date_5 = 'Y' AND bool_5 = TRUE)

MySQL 옵티마이저는 이 구조를 만나면:

“WHERE 전체를 커버하는 단일 인덱스가 있는가?” → 없음
“Index Merge로 처리할 수 있는가?” → 복합 조건(AND)이 포함된 OR은 인식 못함
포기 → Full Table Scan

구조적 차이 정리

	PostgreSQL	MySQL
중간 자료구조	TID Bitmap (범용)	없음
여러 인덱스 합치기	BitmapOr/BitmapAnd	Index Merge (제한적)
복합 조건 OR	각 인덱스 → 비트맵 합치기 ✓	인식 불가 → Full Scan ✗
메모리 관리	work_mem 기반, Lossy 전환	N/A
페이지 방문 순서	물리적 순서 (sequential-like)	보장 없음

PostgreSQL의 핵심 설계: B-tree 결과를 즉시 행으로 가져오지 않고, 비트맵이라는 중간 계층을 두어 여러 인덱스 결과를 합친 뒤 한 번에 읽는다.

MySQL은 이 중간 계층이 없으므로, 인덱스에서 결과를 가져오면 바로 행을 fetch해야 한다. “여러 인덱스 결과를 먼저 모아놓고 합치기”가 구조적으로 제한된다.

정리

개념	역할
TID	Tuple ID = (페이지 번호, 오프셋). 행의 물리적 주소.
TID Bitmap	”방문할 페이지 목록”을 비트로 표현한 메모리 내 구조
BitmapIndexScan	인덱스를 스캔하여 TID Bitmap 생성
BitmapOr	여러 비트맵의 합집합 (비트 OR 연산)
BitmapAnd	여러 비트맵의 교집합 (비트 AND 연산)
BitmapHeapScan	합쳐진 비트맵의 페이지를 순서대로 방문
Exact 모드	페이지+행 위치 기록. Recheck 불필요.
Lossy 모드	페이지만 기록. 읽을 때 조건 Recheck 필요.
work_mem	비트맵 최대 크기 결정. 초과 시 Lossy 전환.

참고 자료

UNION vs OR vs IN 벤치마크 (3), 전체 데이터와 실무 권고

koa (김신건) — Sat, 13 Jun 2026 00:00:00 GMT

전체 성능 데이터

PostgreSQL (전 버전)

PostgreSQL 전 버전 상세 테이블 (접기/펼치기)

DB	방식	n	p50 (ms)	p95 (ms)	I/O 블록	Plan
pg13	Tuple IN	1	0.001	0.002	2	index_scan
pg13	UNION ALL	1	0.001	0.002	2	index_scan
pg13	OR 조건	1	0.002	0.002	2	index_scan
pg13	OR 조건	3	0.004	0.005	6	bitmap_heap_scan
pg13	Tuple IN	3	0.004	0.009	6	bitmap_heap_scan
pg13	UNION ALL	3	0.005	0.006	6	append
pg13	UNION ALL	5	0.007	0.007	13	append
pg13	OR 조건	5	0.008	0.011	13	bitmap_heap_scan
pg13	Tuple IN	5	0.008	0.010	13	bitmap_heap_scan
pg13	Tuple IN	10	0.015	0.023	29	bitmap_heap_scan
pg13	UNION ALL	10	0.017	0.023	29	append
pg13	OR 조건	10	0.024	0.041	29	bitmap_heap_scan
pg13	OR 조건	20	0.032	0.043	55	bitmap_heap_scan
pg13	Tuple IN	20	0.032	0.033	55	bitmap_heap_scan
pg13	UNION ALL	20	0.032	0.032	56	append
pg13	OR 조건	50	0.085	0.101	140	bitmap_heap_scan
pg13	UNION ALL	50	0.087	0.103	142	append
pg13	Tuple IN	50	0.102	0.164	140	bitmap_heap_scan
pg15	OR 조건	1	0.002	0.002	2	index_scan
pg15	Tuple IN	1	0.002	0.005	2	index_scan
pg15	UNION ALL	1	0.002	0.004	2	index_scan
pg15	Tuple IN	3	0.004	0.005	6	bitmap_heap_scan
pg15	UNION ALL	3	0.004	0.009	6	append
pg15	OR 조건	3	0.005	0.008	6	bitmap_heap_scan
pg15	UNION ALL	5	0.007	0.007	13	append
pg15	OR 조건	5	0.008	0.011	13	bitmap_heap_scan
pg15	Tuple IN	5	0.008	0.013	13	bitmap_heap_scan
pg15	Tuple IN	10	0.014	0.020	29	bitmap_heap_scan
pg15	OR 조건	10	0.015	0.017	29	bitmap_heap_scan
pg15	UNION ALL	10	0.015	0.022	29	append
pg15	OR 조건	20	0.027	0.032	55	bitmap_heap_scan
pg15	Tuple IN	20	0.028	0.037	55	bitmap_heap_scan
pg15	UNION ALL	20	0.035	0.044	56	append
pg15	Tuple IN	50	0.081	0.104	140	bitmap_heap_scan
pg15	OR 조건	50	0.086	0.092	140	bitmap_heap_scan
pg15	UNION ALL	50	0.098	0.106	142	append
pg17	Tuple IN	1	0.002	0.005	2	index_scan
pg17	UNION ALL	1	0.002	0.003	2	index_scan
pg17	OR 조건	1	0.003	0.006	2	index_scan
pg17	Tuple IN	3	0.004	0.007	6	bitmap_heap_scan
pg17	OR 조건	3	0.005	0.007	6	bitmap_heap_scan
pg17	UNION ALL	3	0.005	0.008	6	append
pg17	OR 조건	5	0.007	0.009	13	bitmap_heap_scan
pg17	Tuple IN	5	0.007	0.014	13	bitmap_heap_scan
pg17	UNION ALL	5	0.007	0.012	13	append
pg17	Tuple IN	10	0.013	0.021	29	bitmap_heap_scan
pg17	OR 조건	10	0.014	0.020	29	bitmap_heap_scan
pg17	UNION ALL	10	0.018	0.029	29	append
pg17	OR 조건	20	0.023	0.025	55	bitmap_heap_scan
pg17	Tuple IN	20	0.030	0.044	55	bitmap_heap_scan
pg17	UNION ALL	20	0.036	0.041	56	append
pg17	Tuple IN	50	0.066	0.088	140	bitmap_heap_scan
pg17	OR 조건	50	0.077	0.090	140	bitmap_heap_scan
pg17	UNION ALL	50	0.096	0.184	142	append

MySQL (전 버전)

MySQL 전 버전 상세 테이블 (접기/펼치기)

DB	방식	n	p50 (ms)	p95 (ms)	I/O 블록	Plan	판정
mysql57	Tuple IN	1	0.084	0.105	9	ref	✓
mysql57	UNION ALL	1	0.118	0.129	9	ref	✓
mysql57	OR 조건	1	0.128	0.166	9	ref	✓
mysql57	UNION ALL	3	0.111	0.174	26	ref	✓
mysql57	Tuple IN	3	549.0	559.6	850,026	ALL	✗
mysql57	OR 조건	3	552.1	556.4	850,026	ALL	✗
mysql57	UNION ALL	5	0.195	0.221	68	ref	✓
mysql57	OR 조건	5	557.0	563.5	850,026	ALL	✗
mysql57	Tuple IN	5	560.3	569.1	850,026	ALL	✗
mysql57	UNION ALL	10	0.459	1.0	162	ref	✓
mysql57	Tuple IN	10	579.4	623.5	850,026	ALL	✗
mysql57	OR 조건	10	619.4	754.0	850,026	ALL	✗
mysql57	UNION ALL	20	0.730	0.948	306	ref	✓
mysql57	OR 조건	20	603.6	611.2	850,026	ALL	✗
mysql57	Tuple IN	20	680.4	710.8	850,026	ALL	✗
mysql57	UNION ALL	50	1.3	1.4	782	ref	✓
mysql57	OR 조건	50	691.3	700.3	850,026	ALL	✗
mysql57	Tuple IN	50	693.6	697.7	850,026	ALL	✗
mysql80	UNION ALL	1	0.002	0.002	119	ref	✓
mysql80	OR 조건	1	0.002	0.002	119	ref	✓
mysql80	Tuple IN	1	0.002	0.003	119	ref	✓
mysql80	UNION ALL	3	0.006	0.006	153	ref	✓
mysql80	OR 조건	3	37.2	37.9	1,700,153	ALL	✗
mysql80	Tuple IN	3	37.5	38.0	1,700,153	ALL	✗
mysql80	UNION ALL	5	0.014	0.017	238	ref	✓
mysql80	Tuple IN	5	41.9	44.6	1,700,153	ALL	✗
mysql80	OR 조건	5	43.3	46.8	1,700,153	ALL	✗
mysql80	UNION ALL	10	0.028	0.042	425	ref	✓
mysql80	OR 조건	10	51.8	60.0	1,700,153	ALL	✗
mysql80	Tuple IN	10	52.4	53.3	1,700,153	ALL	✗
mysql80	UNION ALL	20	0.055	0.067	714	ref	✓
mysql80	Tuple IN	20	71.2	72.1	1,700,153	ALL	✗
mysql80	OR 조건	20	72.1	77.0	1,700,153	ALL	✗
mysql80	UNION ALL	50	0.158	0.178	1,666	ref	✓
mysql80	Tuple IN	50	131.0	134.1	1,700,153	ALL	✗
mysql80	OR 조건	50	133.0	138.8	1,700,153	ALL	✗
mysql84	UNION ALL	1	0.002	0.002	221	ref	✓
mysql84	Tuple IN	1	0.002	0.002	221	ref	✓
mysql84	OR 조건	1	0.002	0.002	221	ref	✓
mysql84	UNION ALL	3	0.006	0.008	255	ref	✓
mysql84	Tuple IN	3	40.3	41.1	1,700,255	ALL	✗
mysql84	OR 조건	3	40.4	41.1	1,700,255	ALL	✗
mysql84	UNION ALL	5	0.013	0.014	340	ref	✓
mysql84	OR 조건	5	44.5	45.6	1,700,255	ALL	✗
mysql84	Tuple IN	5	45.1	46.5	1,700,255	ALL	✗
mysql84	UNION ALL	10	0.028	0.034	527	ref	✓
mysql84	Tuple IN	10	56.0	57.0	1,700,255	ALL	✗
mysql84	OR 조건	10	56.1	59.0	1,700,255	ALL	✗
mysql84	UNION ALL	20	0.055	0.064	816	ref	✓
mysql84	Tuple IN	20	77.5	79.8	1,700,255	ALL	✗
mysql84	OR 조건	20	80.5	81.5	1,700,255	ALL	✗
mysql84	UNION ALL	50	0.158	0.174	1,768	ref	✓
mysql84	OR 조건	50	147.0	149.0	1,700,255	ALL	✗
mysql84	Tuple IN	50	148.0	148.6	1,700,255	ALL	✗

실무 권고

PostgreSQL 사용자

편한 문법을 쓰면 된다. 플래너가 BitmapOr로 최적화한다.
“OR은 느리니 UNION으로 분리해라”는 조언을 맹목적으로 따를 필요 없다.
work_mem이 너무 작으면 Lossy 비트맵이 많아져 Recheck 비용이 증가할 수 있다. 대규모 쿼리에서 EXPLAIN (ANALYZE, BUFFERS)의 Heap Blocks: lossy=를 확인하자.
PG 13 이상이면 모두 동일하게 동작한다.

MySQL 사용자

서로 다른 컬럼에 대한 OR/IN이 2개 이상이면 반드시 UNION ALL로 분리.
이 제약은 MySQL 5.7 → 8.0 → 8.4에서 변하지 않았다.
ORM 생성 쿼리를 확인하라. 자동으로 OR을 생성하고 있다면 raw query로 교체.
IN이 OR보다 안전하다는 생각도 버리자. 둘 다 동일하게 퇴화한다.

책의 조언은 틀렸나?

“SQL 레벨업”의 UNION 권장은 범용적으로 안전한 조언이다. MySQL에서는 여전히 유효하고, Oracle에서도 비슷한 제약이 있을 수 있다.

다만 PostgreSQL이라면 이미 자유롭다. 불필요하게 UNION ALL로 쿼리를 복잡하게 만들 필요 없다. 쓰는 DB의 옵티마이저를 이해하고, EXPLAIN으로 확인하는 습관이 가장 중요하다.

참고 자료

IaC 튜토리얼 (1)

koa (김신건) — Fri, 12 Jun 2026 00:00:00 GMT

IaC란?

[!NOTE] 한줄 정리 서버·네트워크·DB 같은 인프라를 사람이 손으로 클릭해 만드는 대신, 버전 관리되는 코드(설정 파일) 로 정의하고 자동으로 프로비저닝하는 방식

어떻게 만들지(절차)가 아니라 무엇을 원하는지(상태)를 적는 선언형 방식이 IaC의 주류다.

요약 정리

IaC는 인프라의 “원하는 상태(desired state)” 를 텍스트 파일로 기술하고, 도구가 그 정의대로 실제 클라우드/온프레미스 자원을 만들고 변경·삭제하도록 하는 운영 패러다임입니다.

콘솔에서 수동으로 만든 자원은 누가/언제/무엇을 바꿨는지 추적이 어렵고, 재현이 불가능합니다. IaC는 이 과정을 코드로 옮겨 Git으로 이력을 남기고, 코드 리뷰를 거치고, 동일한 정의로 몇 번이든 같은 환경을 재생산할 수 있습니다.

결과적으로 인프라가 소프트웨어 개발의 모범 사례(버전 관리·테스트·CI/CD· 리뷰)를 그대로 누리게 됩니다.

코드로 정의하면 따라오는 것들

Single Source of Truth : 실제 인프라의 구조는 코드 저장소가 말해줍니다.
리뷰 가능성: 인프라 변경이 PR로 들어와, 동료의 검토를 받습니다. (이제 AI의 작성과 리뷰도 받을 수 있습니다.)
자동화: apply 한번으로 수십 개의 자원을 일관되게 생성합니다.

IaC의 이점

이점	무엇을 해결하는가?	구체적인 효과
재현성 / 멱등성	환경 간 불일치, 재해 복구	동일 코드로 dev-alpha-production 등의 환경에 동일하게 생성 가능. 여러 번 apply해도 결과가 동일함
버전 관리	”누가 이걸 지웠는가?”	Git Diff로 변경 추적이 가능함
협업 / 리뷰	사일로화된 인프라 지식	인프라 변경이 코드 리뷰 대상이 되어 지식이 팀에 공유된다.
속도 / 자동화	느린 수동 프로피저닝	CI/CD 파이프라인에서 plan / apply를 자동 실행
일관성	휴먼 에러, Contribution Drift	클릭 실수 제거, 정책을 코드로 강제할 수 있음
문서화	오래된 위키	코드 자체가 항상 최신 인프라를 명세하는 명세서 역할을 함
비용 / 보안 가시성	유령 자원, 미흡한 점검	정적 분석 (tfsec, Checkov) 으로 배포 전에 위험, 낭비를 탐지할 수 있음

IaC에서 멱등성은 매우 중요합니다. 명령형 스크립트를 통해 인프라 생성시, 단순하게 두 번 실행하면 자원을 2개 만들어낼 수 있습니다. 선언형 IaC는 “이미 원하는 상태” 라면 아무 일도 하지 않습니다. 이 성질로 “안전하고 다시 돌릴 수 있는” 자동화를 가능하게 만들어줍니다.

명령형 vs 선언형 그리고 state에 대해

명령형(imperative)

“EC2 인스턴스를 생성하라 → 보안그룹을 붙여라 → 태그를 달아라”처럼 수행할 단계를 순서대로 기술합니다. (예: 셸 스크립트, AWS CLI 나열) 다시 실행하면 중복 생성·오류가 날 수 있어 멱등하지 않습니다.

선언형(declarative)

“t3.micro EC2가 1대, 이 보안그룹과 함께, 이 태그로 존재해야 한다”처럼 결과만 기술합니다. 도구가 현재와 비교해 필요한 동작을 스스로 도출합니다. (ex. Terraform, CloudFormation, Kubernetes manifest)

선언형 IaC 도구가 동작하는 방식

선언형 도구는 세 가지를 비교합니다.

코드에 적힌 목표 상태(desired)
도구가 기억하는 마지막 상태(state file)
클라우드의 실제 상태(real)

plan 단계에서 이 셋을 대조하여 “무엇을 만들고/바꾸고/지울지”를 실행 계획으로 보여줍니다. apply 단계에서 그 계획만큼만 실제 API를 호출합니다. 코드와 실제가 어긋나는 현상을 드리프트(drift)라 하며, 도구는 이를 감지해 다시 코드 기준으로 맞춰 줍니다. 이 “목표-현재 차이 계산” 모델이 IaC가 멱등하고 안전한 이유입니다.

멀티 패러다임 프로그래밍 책을 읽으며 끄적이기

koa (김신건) — Thu, 04 Jun 2026 00:00:00 GMT

각 챕터별 인상적이거나 기억에 남기고 싶은 구문

1장 - 멀티패러다임이 현대 언어를 확장하는 방법

ArrayLike의 이터레이터에서의 reverse 구현
“언어를 만든 사람이 아닌, 언어의 사용자가 언어를 발전시킨 것입니다.” (p.48)

지연 평가

필요한 시점까지 계산을 미루어 메모리 사용량과 연산 비용을 쥴여 향상하는 기법

generator

이터레이터를 생성하는 문법적 장치로서 명령형 스타일로도 Iteration 로직을 구현할 수 있게 합니다.
function*, yield 키워드를 사용하여 값을 하나씩 반환함으로써 지연 평가가 필요한 로직을 간결하고 명확하게 표현할 수 있습니다.

Iteration에 대한 정리

Iterator: { value: T, done: boolean } 객체를 반환하는 next() 메서드를 가진 객체
Iterable: Iterator를 반환하는 [Symbol.iterator]() 메서드를 가진 값
IterableIterator: Iterator이자 Iterable인 값
Iteration Protocol: Iterable을 for … of 문, 전개 연산자 등과 함께 동작하도록 하는 규약

인터페이스와 클래스 상속

인터페이스는 규약을 제시하여 다양한 클래스가 동일한 형식의 동작을 구현하도록 유도합니다.
상속은 공통 기능을 직접 구현한 뒤, 적절히 확장하는 데 초점을 둡니다.
인터페이스는 언어나 표준 라이브러리 설계 단계에서 주로 사용됩니다.
상속은 주로 SDK나 애플리케이션 레벨에서 사용됩니다.

2장 - 함수형 프로그래밍과 타입 시스템 그리고 LISP

아래와 같은 함수 타입 별칭을 정의할 수 있다.

type FN = (a: number, b: number) => number;

const add: FN = (a, b) => a + b;
const subtract: FN = (a, b) => a - b;

console.log(add(5, 3)); // 8
console.log(subtract(5, 3)); // 2

이터레이션 프로토콜 복습 체크리스트 내용

for … of 문으로 순회할 수 있는 값은 오직 Iterable입니다.
전개 연산자로 배열을 만들 수 있는 값은 오직 Iterable입니다.
IterableIterator를 만드는 함수를 구현할 때 반환값을 { next() {...}, [Symbol.Iterator]() {...} } 형식으로 구현할 수 있으며, 이 객체는 이터레이터이자 동시에 이터러블입니다.

Map을 Generator와 Iterable 패턴으로 구현하기

function* map<A, B>(f: (a: A) => B, iterable: Iterable<A>): IterableIterator<B> {
  for (const a of iterable) {
    yield f(a);
  }
}

// 예제 1
const arr = ['1', '2', '3'];
const mapped = map(x => parseInt(x), arr);
const array2: number[] = [...mapped];
console.log(array2); // [1, 2, 3]

// 예제 2
const [head] = map(a => a.toUpperCase(), ['a', 'b', 'c']);
console.log(head); // 'A'

2.3

Meta Programming 이란 프로그램이 자기 자신이나 다른 프로그램을 데이터처럼 바라보며 분석, 번형, 생성하거나 실행하는 프로그래밍 기법을 의미한다.
LISP의 가장 큰 특징: “코드가 데이터이고, 데이터가 코드이다”라는 개념

CodeWithOutput 컴포넌트 데모

koa (김신건) — Tue, 26 May 2026 00:00:00 GMT

이 글은 <CodeWithOutput> 컴포넌트의 모든 표현 가능한 형태를 한 화면에서 확인하기 위한 데모입니다.  는 astro-auto-import 로 글로벌 등록되어 있어 글마다 import 문을 추가할 필요가 없습니다. 새 케이스가 추가될 때마다 이 페이지에 예시를 같이 추가하면 미리보기·실제 빌드·반응형 동작을 한 번에 점검할 수 있습니다.

1. 기본, 코드 + 결과

가장 단순한 형태입니다. 코드 한 덩어리 + 결과 한 덩어리.

2. STDIN + STDOUT 한 쌍

input 을 함께 넘기면 결과 패널 위에 stdin 섹션이 추가됩니다.

3. 여러 테스트 케이스 (`cases`)

알고리즘 문제처럼 입력·출력 쌍이 여러 개 필요한 경우 cases 배열을 사용합니다. 모든 케이스가 한 번에 보이도록 세로로 쌓이고, 케이스 사이는 굵은 경계선으로 구분합니다. 라벨을 생략하면 예제 N 으로 자동 부여됩니다.

4. 사용자 지정 케이스 라벨

각 케이스에 label 을 명시하면 자동 번호 대신 사용자 라벨이 보입니다.

5. 다중 언어 코드 (`variants`)

같은 문제를 여러 언어로 풀이할 때 variants 로 코드 패널에 탭을 만들 수 있습니다. 오른쪽 패널의 결과는 모든 변형이 공유합니다.

6. 다중 언어 + 다중 케이스

variants 와 cases 는 함께 쓸 수 있습니다. 코드는 탭으로, 케이스는 세로 stack 으로.

7. 케이스마다 입력 유무가 섞여 있을 때

cases 안에서 어떤 케이스는 입력이 있고 어떤 케이스는 없는 경우. 각 케이스는 독립적으로 stdin 섹션을 표시/숨김.

8. 타이틀과 커스텀 라벨

title, outputLabel, 케이스별 inputLabel / outputLabel 까지 모두 지정한 풀 옵션 예시.

9. 좌우 비율 조절 (`codeWidth`)

codeWidth prop 으로 초기 좌측 코드 패널 너비를 조절할 수 있습니다 (사용자가 splitter 를 드래그하면 localStorage 에 저장됨).

10. 긴 코드 / 긴 출력 (스크롤 확인)

코드와 출력이 패널 높이를 넘으면 각 패널 내부에서 독립 스크롤됩니다.

11. 긴 한 줄 (가로 스크롤 확인)

긴 단일 라인은 패널 안에서 가로 스크롤이 동작해야 합니다.

12. 다양한 언어 하이라이팅

shiki 가 인식 가능한 언어라면 자동으로 색상이 적용됩니다.

<CodeWithOutput language=“rust” label=“Rust” outputLanguage=“text” code={fn main() {\n let v: Vec<i32> = (1..=5).collect();\n let sum: i32 = v.iter().sum();\n println!("sum = {}", sum);\n}} output={sum = 15} />

확인 포인트

좌우 splitter 드래그로 비율 조절이 동작하는가
더블클릭 시 50% 로 리셋되는가
화살표 키로 미세 조정되는가
모바일 폭 (640px 이하) 에서 splitter 가 사라지고 세로 stack 으로 전환되는가
다크/라이트 모드 전환 시 코드 색상이 따라가는가
다중 케이스에서 케이스 간 경계선이 명확한가
미리보기 (에디터) 와 실제 렌더링이 시각적으로 동일한가

[Leetcode] 192 Word Frequency

koa (김신건) — Mon, 25 May 2026 09:35:44 GMT

문제 요약 및 풀이

file.txt가 주어질 때, 각 단어의 빈도수를 계산하여 단어와 빈도수를 출력하는 한 줄짜리 [[Shell Script]]를 작성해야 한다.

이때 빈도수에 따라 내림차순으로 정렬해야 하고, 빈도수가 같은 경우는 주어지지 않는다고 가정한다.

스크립트로 작성하려면 어떻게 해야하나 고민하다가 sort + uniq -c 조합으로 단어의 빈도수를 계산 할 수 있다고 생각했고, 실행해보았다. 근데 빈도수의 오름차순으로 정렬이 되어서 sort -r 옵션을 추가해서 내림차순으로 정렬하도록 했다.

풀이 코드

[Leetcode] 195 Tenth Line

koa (김신건) — Mon, 25 May 2026 09:14:23 GMT

문제 요약 및 풀이

file.txt가 주어질 때, 정확하게 10번째 줄에 있는 텍스트를 출력하는 한 줄짜리 [[Shell Script]]를 작성해야 한다.

처음에는 head와 tail로 바로 간단하게 할 수 있을 것 같았다.

아래와 같이 10줄 미만의 입력이 주어지면 정확하게 10번째 라인이 아닌 마지막 라인을 출력하게 됨을 놓쳤다.

이를 수정하기 위해서 sed를 사용했고, 다음과 같은 풀이를 작성했다.

풀이 코드

sed -n '10p' file.txt

[Leetcode] 193 Valid Phone Numbers

koa (김신건) — Mon, 25 May 2026 08:14:00 GMT

문제 요약 및 풀이

file.txt가 주어질 때, (xxx) xxx-xxxx or xxx-xxx-xxxx 형태의 전화번호를 모두 출력하는 한 줄짜리 [[Shell Script]]를 작성해야 한다.

신경써야했던 부분은

괄호가 있는 경우와 없는 경우의 두 케이스를 구분해야 한다.
앞, 뒤에 의미없는 문자들이 들어오는 케이스가 있을 수 있다.
숫자가 아닌 문자들이 들어오는 케이스가 있을 수 있다.
각 숫자의 개수도 정확히 맞아야 한다.

풀이 코드

grep -E '(^[0-9]{3}-[0-9]{3}-[0-9]{4}$)|^(\([0-9]{3}\) [0-9]{3}-[0-9]{4}$)' file.txt

캐시 적용이 적절한 상황

koa (김신건) — Sun, 24 May 2026 09:26:00 GMT

다음과 같은 조건이라면 캐시를 적용해보자

원본 데이터 저장소에서 원하는 데이터를 찾기 위해 검색하는 시간이 오래 걸린다.
원본 데이터 저장소에서 매번 계산을 통해 데이터를 가져와야 한다.
캐시에서 데이터를 가져오는 것이 원본 데이터 저장소를 통해 요청하는 것보다 빨라야 한다.
캐시에 저장된(저장할) 데이터가 잘 변하지 않는 데이터다.
캐시에 저장된 데이터는 자주 검색되는 데이터다.

마크다운 문법 종합 테스트

koa (김신건) — Sat, 23 May 2026 00:00:00 GMT

이 글은 새 블로그에서 지원하는 마크다운 문법을 한눈에 확인하기 위한 페이지입니다.

1. 기본 텍스트 강조

굵게 · 기울임 · 굵게+기울임 · ~~취소선~~ · 인라인 코드 · 밑줄(HTML)

자동 링크: https://astro.build 일반 링크: Astro 공식 문서 위키 링크: [[Astro]] · 별칭 [[Astro|Astro JS]] · 깨진 링크 [[존재하지않는위키]]

2. 헤딩 계층

3단계 헤딩

4단계 헤딩

5단계 헤딩

6단계 헤딩

3. 인용과 콜아웃

평범한 블록 인용:

“단순함이 궁극의 정교함이다.”, 레오나르도 다 빈치

GitHub 스타일 콜아웃 (5종):

[!NOTE] 정보, 가볍게 알아두면 좋은 부가 설명을 적습니다.

[!TIP] 팁, 더 쉽게 일을 처리하기 위한 조언입니다.

[!IMPORTANT] 중요, 목표 달성에 꼭 필요한 핵심 정보입니다.

[!WARNING] 경고, 문제를 피하기 위해 즉시 주의해야 할 내용입니다.

[!CAUTION] 주의, 특정 행동으로 인한 위험이나 부정적 결과를 알립니다.

4. 리스트

순서 없는 리스트:

첫 번째 항목
두 번째 항목
- 중첩 항목
- 다른 중첩
  - 더 깊은 중첩
세 번째 항목

순서 있는 리스트:

패키지 설치
설정 추가
빌드 확인

체크리스트 (GFM):

Astro 프로젝트 셋업
BrainDB 대체 remark 플러그인 작성
다크/라이트 모드 구현
1만 글 마이그레이션

5. 코드 블록

인라인 코드: const greeting = "안녕"

TypeScript:

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

export async function getUser(id: string): Promise<User | null> {
  const response = await fetch(`/api/users/${id}`);
  if (!response.ok) return null;
  return response.json() as Promise<User>;
}

Python:

from dataclasses import dataclass
from typing import Optional

@dataclass
class User:
    id: str
    name: str
    email: Optional[str] = None

async def get_user(id: str) -> Optional[User]:
    async with httpx.AsyncClient() as client:
        r = await client.get(f"/api/users/{id}")
        if r.status_code != 200:
            return None
        data = r.json()
        return User(**data)

Bash:

#!/usr/bin/env bash
set -euo pipefail

for file in src/content/posts/*.md; do
  echo "Processing $file"
  pnpm exec markdownlint "$file"
done

JSON + diff + plain text:

{
  "name": "shinkeonkim-log",
  "version": "0.1.0"
}

- 안녕하세요
+ 안녕하세요, 김신건입니다.

순수 텍스트 블록은 하이라이팅이 없습니다.
어떤 언어인지 명시하지 않으면 이렇게 보입니다.

6. 표

항목	설명	상태
다크/라이트 모드	localStorage + prefers-color-scheme	✅
위키링크	자체 remark 플러그인	✅
그래프 뷰	D3 force simulation	✅
통합 검색	Pagefind 빌드 후 인덱싱	✅
페이지네이션	Astro `paginate()`	✅

정렬 옵션:

왼쪽 정렬	가운데 정렬	오른쪽 정렬
left	center	right
짧은 텍스트	중간 길이 텍스트	더 긴 텍스트

7. 이미지

public/ 디렉토리에 둔 이미지 (절대 경로):

리모트 이미지:

8. 푸트노트

푸트노트도 지원합니다¹. 본문이 길어질 때 출처를 정리할 때 유용합니다².

9. 구분선과 줄바꿈

위는 구분선입니다. 줄바꿈 두 칸으로
강제 줄바꿈도 됩니다.

10. HTML 직접 삽입

마크다운 안에서 필요할 때 HTML 을 직접 쓸 수 있습니다:

접었다 펼치는 영역

이 안에 마크다운은 동작하지 않습니다 (raw HTML). 그래도 텍스트와 일반 HTML 은 잘 들어갑니다.

⌘ + K 같은 단축키 표기도 가능합니다.

11. 코드 + 실행 결과 패널 (`<CodeWithOutput>`)

좌측에 입력 코드, 우측에 그 결과를 나란히 보여주는 컴포넌트. 화면이 좁아지면 자동으로 위아래로 쌓입니다 (lg breakpoint 기준). 실제로 실행하는 게 아니라 글쓴이가 결과를 직접 적어 둡니다, 그래서 셸, REPL, DB CLI, HTTP API 등 어떤 환경의 입출력이든 그대로 옮길 수 있습니다.

11.1 Bash

11.2 Redis CLI

11.3 PostgreSQL (psql)

11.4 HTTP, curl + JSON 응답

11.5 Python REPL

<CodeWithOutput language=“python” label=“python” outputLanguage=“text” outputLabel=”>>>” title=“dataclass 한 입” code={`from dataclasses import dataclass

@dataclass class Note: id: str body: str

n = Note(id=“2026-05-23”, body=“hello”) print(n) print(n.body.upper())} output={Note(id=‘2026-05-23’, body=‘hello’) HELLO`} />

11.6 멀티 언어 탭, 같은 출력, 여러 구현

variants prop 에 언어별 구현을 나열하면 좌측에 탭으로 묶이고, 우측 결과는 공유됩니다. “같은 문제를 어떤 언어로도 풀 수 있다” 를 보여줄 때 유용합니다.

<CodeWithOutput outputLanguage=“text” outputLabel=“stdout” title=“피보나치 첫 10개” variants={[ { label: ‘python’, language: ‘python’, code: `def fib(n): a, b = 0, 1 out = [] for _ in range(n): out.append(a) a, b = b, a + b return out

print(fib(10)), }, { label: 'typescript', language: 'ts', code: function fib(n: number): number[] { const out: number[] = []; let [a, b] = [0, 1]; for (let i = 0; i < n; i++) { out.push(a); [a, b] = [b, a + b]; } return out; }

console.log(fib(10));, }, { label: 'rust', language: 'rust', code: fn fib(n: usize) -> Vec { let mut out = Vec::with_capacity(n); let (mut a, mut b) = (0u64, 1u64); for _ in 0..n { out.push(a); let next = a + b; a = b; b = next; } out }

fn main() { println!(”{:?}”, fib(10)); }, }, { label: 'go', language: 'go', code: package main

import “fmt”

func fib(n int) []int { out := make([]int, 0, n) a, b := 0, 1 for i := 0; i < n; i++ { out = append(out, a) a, b = b, a+b } return out }

func main() { fmt.Println(fib(10)) }, }, ]} output={[0, 1, 1, 2, 3, 5, 8, 13, 21, 34]`} />

11.7 너비 조절

codeWidth prop 으로 좌측 코드 패널 너비(%)를 정합니다. 사용자는 가운데 핸들을 드래그 (또는 화살표 키) 로 임의 조정할 수 있고, 너비가 100% 가 되면 자동으로 상하 배치로 전환됩니다. 조정값은 컴포넌트 단위로 localStorage 에 저장됩니다.

더블클릭 / Enter: 50% 로 리셋
화살표 키: 2% 씩 (Shift+화살표: 10%)
End 키: 100% (상하 배치)

<CodeWithOutput language=“bash” label=”$ bash” outputLanguage=“text” outputLabel=“stdout” title=“긴 코드, 코드 영역 넓게 (codeWidth=75)” codeWidth={75} code={# 디스크 사용량 큰 디렉토리 상위 5개 du -h --max-depth=1 . 2>/dev/null \\ | sort -hr \\ | head -6 \\ | awk 'NR>1 {printf "%-8s %s\\n", $1, $2}'} output={189M ./dist 42M ./node_modules/.bin 12M ./node_modules/three 8.4M ./src 2.1M ./public 1.2M ./_posts} />

12. Mermaid 다이어그램

```mermaid 코드 블록은 자동으로 Mermaid 다이어그램으로 렌더링됩니다. CDN ESM 으로 lazy import 되므로 이 페이지에서만 ~수백KB 로드되고, 다른 글에는 부담이 없습니다. 다크/라이트 모드 토글 시 자동으로 다시 그려집니다.

12.1 Flowchart

flowchart LR
    A[글쓴이] -->|마크다운 작성| B(.md / .mdx)
    B --> C{remark 파이프라인}
    C -->|wikilink| D[[Wiki 페이지]]
    C -->|callout| E[Alert]
    C -->|mermaid| F[다이어그램]
    D & E & F --> G((정적 HTML))
    G -->|Pagefind 인덱싱| H[검색 가능]

12.2 Sequence, 빌드 파이프라인

sequenceDiagram
    participant Dev as 개발자
    participant CI as GitHub Actions
    participant Build as Astro Build
    participant PF as Pagefind
    participant Pages as GitHub Pages

    Dev->>CI: git push main
    CI->>Build: bun install + bun run build
    Build->>Build: remark plugins (wikilink/alert/mermaid)
    Build->>Build: Shiki + Content Layer
    Build-->>CI: dist/
    CI->>PF: index dist/**/*.html
    PF-->>CI: dist/pagefind/
    CI->>Pages: upload artifact
    Pages-->>Dev: https://shinkeonkim.com

12.3 State diagram, 사이드 드로어 상태

stateDiagram-v2
    [*] --> Closed
    Closed --> Opening: 햄버거 클릭
    Opening --> Open: transition 끝
    Open --> Closing: 백드롭/ESC/링크 클릭
    Closing --> Closed: transition 끝
    Open --> Closed: viewport >= md

12.4 ER diagram

erDiagram
    POST ||--o{ TAG_LINK : has
    TAG ||--o{ TAG_LINK : tagged
    POST {
        string slug PK
        string title
        date published_at
    }
    TAG {
        string name PK
    }
    TAG_LINK {
        string post_slug FK
        string tag_name FK
    }

18. 인터랙티브 애니메이션

본문 중간에 dev-only 스튜디오 (/_studio/) 에서 만든 애니메이션을 삽입할 수 있습니다. 전체 카탈로그: /animations/ · 만들기 가이드: manual-docs/animation-studio-guide.md

18.1 HTTP 요청 / 응답

가장 기본적인 패턴, Client 가 Server 에 요청, Server 가 응답.

{}

18.2 Redis 캐시 적중 (HIT)

캐시에 데이터가 있어 빠르게 응답하는 경우. DB 조회가 없어서 ~6ms.

{}

18.3 Redis 캐시 미스 (MISS)

캐시에 없어서 DB 까지 다녀와야 하고, 이후 캐시도 갱신해야 함. ~72ms.

{}

18.4 DB Primary-Replica 복제

쓰기는 Primary 에만, Read replica 들에는 WAL 스트림으로 비동기 복제.

{}

18.5 Load Balancer Round-Robin

요청들을 서버 풀에 순회하며 분산.

{}

18.6 TCP 3-way Handshake

SYN → SYN+ACK → ACK 로 연결 수립 (각 노드의 상태 전이 함께 표시).

{}

18.7 OAuth 2.0 Authorization Code Flow

User → App → Auth Server → token → API. 표준 OAuth 시퀀스.

{}

19. 인터랙티브 퀴즈 (Quiz)

quiz 코드 fence 로 4 가지 유형의 문제를 만들 수 있습니다.

{
  "title": "이 데모 페이지 확인 문제",
  "items": [
    {
      "type": "multiple-choice",
      "question": "이 블로그가 사용하는 정적 사이트 생성기는?",
      "options": ["Astro", "Next.js", "Hugo", "Jekyll"],
      "correct": 0,
      "explanation": "Astro + MDX + GitHub Pages 로 배포됩니다."
    },
    {
      "type": "multiple-select",
      "question": "본 페이지에서 다룬 marks 다운 확장 문법은? (여러 개)",
      "options": ["위키링크", "수식(KaTeX)", "Mermaid 다이어그램", "React 컴포넌트"],
      "correct": [0, 1, 2, 3],
      "explanation": "모두 지원됩니다."
    },
    {
      "type": "true-false",
      "question": "em-dash (\u2014) 는 이 블로그에서 허용되지 않는다.",
      "correct": true,
      "explanation": "prebuild 단계에서 U+2014 사용 시 빌드가 실패합니다."
    },
    {
      "type": "short-answer",
      "question": "이 블로그가 검색 인덱스로 사용하는 도구 이름은?",
      "correct": "Pagefind",
      "explanation": "정적 사이트에 최적화된 클라이언트 사이드 검색 라이브러리입니다."
    }
  ]
}

Astro 5의 기본 remark 설정은 remark-gfm 과 remark-smartypants 를 포함합니다. ↩
한국어 콘텐츠에서도 푸트노트 마커가 정상 동작합니다. ↩

1만 개의 글에서도 빠르게: 블로그 빌드 성능 최적화 회고

koa (김신건) — Sat, 23 May 2026 00:00:00 GMT

새 블로그를 막 띄운 다음, 곧바로 한 가지가 신경 쓰였다.

지금은 글이 몇 개뿐이지만, 1만 개로 늘어나면 빌드와 검색이 버틸까?

오래 운영할 블로그라면 답은 “버텨야 한다” 다. 마침 더미 글을 잔뜩 만들어 빌드를 돌려본 김에, 어떤 함정에 빠졌고 어떻게 빠져나왔는지 기록해 둔다.

어쩌다 1만 개를 측정하게 되었나

새 [[Astro]] 블로그에 다음 기능을 차례대로 붙였다.

마크다운 + 위키링크 + 백링크
D3 기반 [[D3|지식 그래프]]
다크/라이트 모드
[[Pagefind]] 통합 검색
paginate() 로 글/노트/위키 페이지네이션
react-force-graph-3d 로 3D 그래프 뷰

여기까지는 글이 두세 개뿐이라 모든 게 즉시 끝났다. 그래도 1만 개 시나리오에서 어떻게 되는지 보기 위해 10,000 개의 더미 마크다운을 생성하고 pnpm build 를 돌렸다.

[!WARNING] 빌드가 돌아오지 않았다. 몇 분이 지나도 끝날 기미가 안 보였다. 강제로 종료.

여기서 “그래도 1만 개면 좀 오래 걸리겠지” 하고 그냥 기다리는 건 위험하다. 정상적으로 끝날 수 없는 코드일 가능성이 더 크기 때문이다.

진단: 무엇이 폭주했는가

빌드 단계별 로그를 보니 각 글 페이지를 그릴 때마다 몇십 ms씩 추가로 시간이 늘어났다. 진짜 범인은 Backlinks.astro 였다.

---

const { slug, collection } = Astro.props;
const candidates = [slug, slug.toLowerCase()];

for (const col of ['posts', 'notes', 'wiki'] as const) {
  const entries = await getCollection(col);
  for (const entry of entries) {
    const body = entry.body ?? '';
    const re = /\[\[([^\]|#]+)(?:#[^\]|]+)?(?:\|[^\]]+)?\]\]/g;
    let m;
    while ((m = re.exec(body)) !== null) {
      const target = m[1].trim();
      if (candidates.includes(target) || candidates.includes(target.toLowerCase())) {
        matches.push({ ... });
      }
    }
  }
}
---

이 컴포넌트는 글 페이지 한 장을 그릴 때마다 모든 컬렉션의 모든 본문을 정규식으로 스캔한다.

한 페이지당 비용: O(N × 평균 본문 길이)
페이지 수: N
전체 비용: O(N²)

1만 글, 평균 본문 500자라면 어림 잡아 50억 회의 정규식 매칭. JS 정규식이 초당 1억 문자를 처리한다고 가정하면 50초가 아니라, 매 페이지가 그 비용을 통째로 다시 치르므로 누적되어 수십 분에서 시간 단위까지 늘어난다.

[!IMPORTANT] 빌드 타임에 O(N²) 가 들어와 있으면 N 이 두 자리 수일 때까지는 눈에 보이지 않는다. 100 → 1만으로 N 이 100배 커지면 작업은 1만 배가 된다. 처음부터 빌드 시점 비용은 페이지당이 아니라 프로젝트당 으로 가져가는 편이 안전하다.

설계: 콘텐츠 그래프를 한 번만 만든다

해결 방향은 단순했다.

전체 컬렉션을 딱 한 번 순회하면서 {nodes, links, backlinks, slugMap} 인덱스를 만든다.
그 인덱스를 모듈 레벨 Promise 에 캐시한다, 모든 페이지 렌더가 같은 인덱스를 본다.
백링크는 Map 조회 한 번으로 끝낸다.

// src/lib/content-graph.ts (요약)
let cache: Promise<ContentGraph> | null = null;

export function getContentGraph(): Promise<ContentGraph> {
  if (!cache) cache = build();
  return cache;
}

async function build(): Promise<ContentGraph> {
  const [posts, notes, wiki] = await Promise.all([
    getCollection('posts', ({ data }) => !data.draft),
    getCollection('notes'),
    getCollection('wiki'),
  ]);

  const slugMap = new Map<string, ContentNode>();
  const backlinks = new Map<string, ContentNode[]>();

  for (const entry of [...posts, ...wiki, ...notes]) {
    /* 모든 별칭/제목/슬러그 → 노드 매핑 추가 */
  }

  for (const entry of [...posts, ...wiki, ...notes]) {
    /* body 한 번 스캔, 위키링크 → backlinks 에 누적 */
  }

  return { nodes, links, backlinks, slugMap };
}

그리고 백링크 컴포넌트는 이렇게 단순해진다.

---

const { slug, collection } = Astro.props;
const graph = await getContentGraph();
const matches = graph.backlinks.get(canonicalId(collection, slug)) ?? [];
---

복잡도가 O(N²) 에서 O(N) + O(1) 조회 × N 페이지 = O(N) 으로 떨어졌다.

[!TIP] Astro 의 페이지 컴포넌트는 모듈처럼 평가된다. Astro:content 의 getCollection 호출 결과도 동일 빌드 내에서는 캐시되지만, 거기서 파생된 계산은 따로 캐시되지 않는다. 위처럼 직접 만든 인덱스를 모듈 변수에 담아두면 자연스러운 메모이제이션이 된다.

그래프 페이지에도 같은 함정이 있다

src/pages/graph.astro 도 비슷한 스캔을 하지만 그쪽은 한 번만 렌더링되는 페이지라 O(N) 으로 끝났다. 다만 클라이언트에서 1만 노드를 D3 force simulation 으로 돌리면 브라우저가 사실상 멈춘다. 빌드는 살아도 사용자 경험이 죽는다.

MAX_GRAPH_NODES = 400 상한을 두고, 초과 시 연결도(degree) 상위 N 개만 그리며 안내한다.

const degree = new Map<string, number>();
for (const link of graph.links) {
  degree.set(link.source, (degree.get(link.source) ?? 0) + 1);
  degree.set(link.target, (degree.get(link.target) ?? 0) + 1);
}

const truncated = graph.nodes.length > MAX_GRAPH_NODES;
const sortedNodes = truncated
  ? [...graph.nodes]
      .sort((a, b) => (degree.get(b.id) ?? 0) - (degree.get(a.id) ?? 0))
      .slice(0, MAX_GRAPH_NODES)
  : graph.nodes;

연결이 많은 허브 노드부터 보여주는 편이 첫 인상에서 더 의미 있다. 작은 위성 노드들은 그래프에서 어차피 정보량이 적다.

측정: 10,531 페이지 / 34.57 초

수정 후 같은 시나리오로 다시 빌드.

지표	값
빌드된 페이지 수	10,531
전체 빌드 시간	34.57s
정적 페이지 생성 단계	14.31s
Pagefind 인덱싱	~10s
`dist/` 총 크기	189 MB
Pagefind 인덱스 크기	42 MB (페이지당 ~4.2 KB)
Pagefind 검색 (일반 쿼리)	< 100 ms
Pagefind 검색 (10K 매치 쿼리)	~1.2 s
그래프 페이지 SSR	< 50 ms (400 노드 상한)
페이지네이션 페이지 응답	< 10 ms

“무한정 → 35 초” 변화의 거의 전부가 백링크 인덱스를 모듈 캐시로 옮긴 것 에서 왔다.

[!NOTE] 검색 응답이 가끔 1 초가 넘는 케이스는 “성능” 처럼 더미 글 1만 개에 거의 모두 들어 있는 단어를 검색했을 때다. 1만 개 결과를 점수 매기느라 시간이 든다. 실제 운영에서는 한 쿼리가 1만 개 결과를 반환하는 일이 거의 없으므로 무시 가능한 코너 케이스.

같이 손본 자잘한 것들

Pagefind 메타데이터: 본문에만 인덱스가 잡히도록 data-pagefind-body 를 글/위키/노트 컨테이너에만 붙이고, 헤더·푸터·페이지네이션·홈·소개·그래프 페이지에는 data-pagefind-ignore="all" 을 달았다. 검색이 더 정확해지고 인덱스 크기도 줄었다.
Section 필터: data-pagefind-filter="section:posts/notes/wiki" 로 검색 UI에서 컬렉션별 필터를 쉽게 제공.
3D 그래프 lazy import: react-force-graph-3d 와 three 는 무겁다. 2D 가 기본이고, 3D 토글을 누른 순간에만 React.lazy() 로 코드를 가져온다.
GitHub 스타일 콜아웃: > [!NOTE] > [!TIP] > [!IMPORTANT] > [!WARNING] > [!CAUTION] 5종, 지금 이 글에 시연되어 있다.
Shiki dual-theme: 같은 코드 블록이 github-light 와 github-dark 모두로 토큰화되고, CSS 변수로 테마를 갈아끼우니 다크 모드 토글이 코드 색까지 자연스럽게 따라온다.

얻은 교훈

1. 빌드 시점 비용은 프로젝트 단위 로 묶는다

페이지 컴포넌트 안에서 “전체 콘텐츠를 한 번 훑는” 코드가 보이면, 그건 거의 항상 잘못 둔 자리다. 그 페이지가 K 개 렌더되면 K 번 훑게 된다. 같은 일이라면 빌드당 한 번만 끝내고 결과를 공유해야 한다.

2. 모듈 레벨 `Promise` 는 단순하지만 강력하다

복잡한 빌드 캐시 인프라 없이도 됐다. ESM 모듈은 한 빌드 안에서 한 번만 평가되므로, 다음 한 줄이면 메모이제이션이 끝난다.

let cache: Promise<X> | null = null;
export function get() {
  if (!cache) cache = build();
  return cache;
}

추상화 단계가 적을수록 디버깅이 쉽다. [[BrainDB]] 같은 외부 도구를 쓸 수 없었던 게 오히려 단순한 해법으로 이끌었다.

3. 작은 N 으로 측정하면 함정을 못 본다

글 5 개일 때는 백링크 컴포넌트가 25 회 스캔을 했다. 눈에 띄지도 않는다. 안전하게 가려면 의도적으로 큰 N 을 만들어 한 번쯤 돌려봐야 한다. 더미 글 생성 스크립트는 30 줄 정도면 충분하다.

// scripts/generate-dummy-posts.mjs (요약)
for (let i = 0; i < COUNT; i++) {
  const rand = rng(i + 1);
  fs.writeFileSync(
    path.join(OUT_DIR, `stress-${String(i + 1).padStart(5, '0')}.md`),
    `---\ntitle: "${title}"\ndate: ${date}\n---\n\n${body}\n`,
  );
}

이 한 번의 부하 테스트가 운영 단계에서의 미래의 한 시간짜리 장애를 사전에 막아 준다.

4. 빌드를 살려도, 런타임이 살아야 한다

이번에는 그래프 페이지가 좋은 예시였다. 빌드 자체는 1만 노드를 무리 없이 직렬화하지만, 그 데이터를 받은 브라우저는 D3 force tick 첫 번째 프레임에서 죽는다. 빌드 결과를 소비하는 쪽 의 한계도 같이 봐야 한다.

5. 검색은 Pagefind 가 “그냥 동작” 한다

Pagefind 는 빌드된 HTML 을 후처리로 인덱싱한다. 1만 페이지에 대해서도 인덱스가 42 MB, 클라이언트는 청크 단위로만 받아오므로 초기 로드도 가볍다. 한국어 토크나이징도 별도 설정 없이 <html lang="ko"> 만으로 잘 동작했다.

[!CAUTION] Pagefind 인덱스는 빌드된 HTML 을 읽기 때문에 HTML 에 보이지 않는 내용은 검색되지 않는다. 백링크 같은 동적 영역이 SSR 단계에서 잘 렌더되어 있는지 확인하는 게 중요하다. 클라이언트 hydration 으로 채워지는 영역은 검색에 빠진다.

마무리

이번 라운드의 변화는 결국 한 가지 룰로 요약된다.

빌드 시점에 전체를 훑는 일은, 빌드당 한 번만 한다.

이 규칙 하나가 1만 페이지 빌드를 못 끝남 에서 35 초 안에 끝남 으로 바꿨다. 같은 규칙이 위키링크 인덱스(remark-wikilink.mjs)에도, 그래프 데이터(content-graph.ts)에도, 태그 인덱스에도 적용된다.

앞으로 콘텐츠가 늘어나면서 새로운 병목이 또 보이겠지만, 이번 회고로 일단 만 단위까지는 안심하고 글을 쌓을 수 있게 됐다. 늘 그렇듯, 일단 기록을 하자.

2025년 회고록 - 개발자에서 학생으로 돌아가서, 2025년을 정리하며

koa (김신건) — Wed, 31 Dec 2025 04:30:00 GMT

개요

2025년… 굉장히 많은 일이 있었던 것 같습니다.

퇴사부터, 대학교 복학, 멋쟁이사자처럼과 SIPE 동아리 활동 그리고 여러 프로젝트와 자격증 취득까지 정말 다양한 활동을 했습니다.

이전에도 써왔던 회고글들처럼, 2025년 한 해 동안 있었던 일들을 회고하고자 합니다. 다만 여러 종류의 일들이 있었던지라, 카테고리별로 정리해보려 합니다.

1. 퇴사와 복학

올해 3월에 퇴사와, 대학교 복학을 같이 했습니다. 이전 글 에서 퇴사에 대한 이야기를 다루기도 했습니다.

퇴사를 하고 나서도 뭘 해야 할지 여러 고민을 했습니다. 어떤 도전들을 해야 할지, 어떤 공부들을 해야 할지에 대해서. 그래서 여러 도전적인 활동을 해보려고 했고, 더 다양한 분야의 공부도 해보려고 했습니다.

2. 동아리 활동

2.1. 멋쟁이사자처럼 국민대학교 운영진

멋쟁이사자처럼 국민대학교 동아리에서 백엔드 파트장을 맡아 1년간 활동했습니다. 그리고 올해를 마지막으로 더 이상 멋쟁이사자처럼 동아리에서 활동은 하지 않기로 했습니다.

생각해 보면, 멋쟁이사자처럼 국민대학교 동아리와의 인연이 제 커리어패스에 많은 영향을 주었던 것 같습니다.

2020년에 멋쟁이사자처럼 국민대학교 동아리에 아기사자로 참여하기 시작했습니다. 그리고 2021년, 2022년, 2024년, 2025년까지 운영진을 맡았습니다.

아기사자로 들어갔을 때는 처음으로 django 프레임워크를 접했고, 웹 개발에 대한 기초적인 지식을 쌓을 수 있었습니다. 그리고 운영진으로 활동하면서는 여러 사람들에게 저의 지식을 전파하는 경험을 했고, 누군가를 가르쳐야 한다는 생각에 더 많은 지식을 습득하려고 노력하는 과정도 있었습니다.

올해는 특히나 백엔드 파트장을 맡으면서, django와 drf에 대한 세션 커리큘럼을 구성하고, 직접 세션도 진행했습니다. 거기에 더해 마지막 활동이라고 생각했기 때문에, 프로젝트에 참여도 하고, 프로젝트를 심사하는 경험을 다 해보면서 마무리하고 싶었습니다.

그래서 대학생 참가자로, 4호선톤이라는 연합 해커톤 대회에도 참여를 했습니다. (비록 수상은 못했지만, 프로젝트 결과물은 괜찮게 나왔습니다.) 또, 교내 해커톤에서는 심사위원으로 프로젝트 심사도 하게 되었습니다.

2.2. SIPE 4기

SIPE는 제가 뭘 도전해야 할지 고민하던 시기에 알게 된 동아리입니다.

SIPE는 다른 개발자 동아리나 스터디 그룹과는 다르게, 개발자들이 모여 경험을 서로 공유하고 네트워킹을 하는 데에 중점을 둔 동아리입니다.

그래서 제가 고민하던 “새로운 도전과 다양한 경험”에 대해서, 간접적으로 다른 사람들의 경험으로 배울 수 있는 좋은 기회였습니다. 그리고 어쩌면 몇 개의 다리를 거쳐서 알아야 하는 사람들을 바로 알게 되는 좋은 기회이기도 했습니다.

거기에 더해, SIPE에서는 미션을 수행하는 활동이 있었는데, 그 중 “AI가 나를 소개해줘요” 미션과 “자라나는 새싹 키우기” 미션을 진행했습니다.

“AI가 나를 소개해줘요” 미션은 제가 AI 기술에 관심을 가지고 있었고, LLM이 마치 나처럼 나를 소개하는 경험을 해보고 싶어서 발제했습니다. 많은 사이퍼들이 관심을 가져주셨고 좋은 결과물을 낼 수 있었습니다. -> 관련 페이지

“자라나는 새싹 키우기” 미션은 개발자를 꿈꾸는 고등학생들에게 멘토링을 해주는 미션이었습니다. 이전부터 교육에 관심이 많았던 터라, 이 미션도 흥미롭게 참여했습니다. 좀더 다양한 기술을 알려주고 싶었지만, 고등학생들의 수준에 맞추다보니 기본적인 내용 위주로 알려줄 수 밖에 없었던 점이 아쉬웠습니다. 그리고 교육 분야나 기술 전파에 관심을 가지고 있는 상황이니 더욱더 교안이나 장표들을 미리 많이 준비해놓아야겠다는 생각이 들었습니다.

SIPE 5기에도 참여할까 고민하였지만, 2026년에는 졸업을 앞두고 캡스톤 프로젝트를 진행해야 하고 새로운 직장을 찾는 여정을 시작해야 해서 참여하지 않기로 했습니다. 6기에는 다시 참여할 수도 있을 것 같은데, 어떤 다양한 분들과 네트워킹을 할 수 있을지 기대가 벌써 되면서, 5기에 참여하지 못하는게 아쉽기도 합니다.

3. 대학교 3학년 생활

이번에 대학교 복학 후 공부를 하면서 세상이 많이 바뀌었다고 느꼈습니다. 19학번으로 입학핵서 학교를 다녔던 때는 AI 기술 자체가 발전되어있지 않았고 LLM도 없었으며 무조건 직접 공부하고 찾아보고 암기하는 방식이었습니다.

하지만 지금은 LLM이 있고, 다양한 AI 서비스와 도구가 있습니다. 그래서 공부하는 방식도 달라져야 한다고 생각했습니다. 제가 공부하는 방식에다가 AI 도구들을 적절히 활용하게 되었고, 이에 대한 공부 결과, 공부 방식에 대해서 정리해 보겠습니다.

3.1. 두근두근, 나의 학점은?

1학기와 2학기 모두 좋은 학점을 받았습니다.

3.2. 어떻게 공부하고 있는가? 그리고 왜 이렇게 공부해야 하는가?

우선 굿노트로 강의 내용들을 한 판에 정리했습니다. 저는 공부하는 내용이 제대로 구조화되어 있지 않으면 머릿속에 잘 들어오지 않습니다.

그래서 일부러 강의 내용을 정리할 때, 계층 구조를 나누거나 서열을 나누는 방식을 적용합니다. 그리고 연관된 개념과 상반된 개념이 한 번에 다 보이도록 합니다.

이 정리 방식은 시험을 보거나 복습을 할 때도 훨씬 도움이 됩니다. “그 개념이 어디에 있더라?” 혹은 “그건 무슨 개념이랑 연관이 있지?”라는 생각이 들면, 그 개념이 어디에 있었는지를 떠올리면서 쉽게 기억할 수 있기 때문입니다.

아래 이미지들은 제가 굿노트로 정리했던 내용들 중 일부입니다.

하나하나가 작은 그림 또는 픽셀처럼 보이지만, 각각 PPT 슬라이드 한 장이거나 강의 필기 내용을 정리한 것들입니다.

그러면 끝일까요? 아닙니다.

위의 방식은 한 번씩 개념을 정리한 것뿐이고 아직 제 머리에는 다 들어가 있지 않은 상태입니다.

여기에서 AI 도구 중 하나인 notebooklm을 활용합니다.

notebooklm은 구글에서 제공하는 LLM 기반의 도구입니다. 여기에 제가 정리해 놓은 시험 범위 .md 또는 .txt 파일을 업로드하고, 강의 교안도 같이 업로드합니다.

그러고 나서 notebooklm에서 제공하는 퀴즈 기능, 플래시카드 기능을 활용해서 무한 반복하며 복습 및 암기합니다. 만약 모르는 내용이 나오거나, 틀린 문제가 나오면, notebooklm에서 자연스럽게 해설 제공 기능을 이용하여 개념을 다시 이해할 수 있도록 했습니다.

이런 방식을 통해서, 머릿속에 구조화된 개념을 넣었고 그 개념을 복습하는 과정까지 거쳤습니다.

여기서 끝일까요? 만약 특정 강의나 특정 개념이 코드를 작성하는 것과 관련되어 있거나 설계를 해야 하는 것을 공부해야 한다면, notebooklm 만으로는 부족합니다.

그래서 저는 Claude Code, Cursor, Antigravity와 같이 IDE에서 코딩 에이전트가 동작하는 것을 프로젝트에 적용하는 것과는 또 다른 방식으로 활용해 봤습니다.

위의 이미지에서와 같이 특정 기술의 다양한 예제 혹은 어떤 프로그래밍 언어의 문법에 대한 실습 등을 프롬프트를 통해 구성하도록 했고, 결과물들을 확인하고 다르게 변주해보면서 이해하는 과정을 거쳤습니다.

4. 일정 관리

올해는 todomate라는 일정 관리 도구를 활용했습니다. 2026년까지는 그대로 쓰지 않을까 싶습니다만.. 그 이후에는 다른 도구를 쓸 수도 있겠다는 생각이 듭니다.

아무튼, 올해 2월에 친구의 추천으로 쓰기 시작했던 todomate 사용은 아주 성공적이었던 것 같습니다.

처음에는 단순히 루틴적으로 해야하는 일들만 관리하려고 사용했습니다. 예를 들어, BOJ 문제 풀이, 운동, 청소 등이요. 하지만 점점 사용하면서 그냥 무작정 떠오르는 일들도 적어두고, 장기적으로 해야하는 일들은 세세하게 쪼개서 적어두는 방식으로 활용하기에는 괜찮았습니다.

그래서 매일 아침마다 todomate를 켜서 오늘 할 일들을 확인하고, 자기 전에는 오늘 했던 일들을 다시 체크하는 방식으로 활용했습니다.

다만, 프로젝트 단위로 일을 관리해야 하거나, 팀 단위로 관리해야 하는 일이 있다면 매우 적합하지 않았습니다.

제가 해야 하는 개인 일정 관리에는 좋았지만 팀 단위의 일을 같은 곳에서 보고 싶어서 중복으로 관리하다 보니 오히려 번거로울 때도 있었습니다.
프로젝트 단위로 일을 관리하기에는 각 할 일마다의 순서나 의존성 관리를 할 수 없다 보니 계속해서 수작업으로 일의 순서를 조정해야 했습니다.

이 때문에 좀 더 좋은 일정 관리 도구를 찾으면 바로 다른 도구로 바꾸어 사용해 보면서 실험을 해보려고 합니다.

그래도 이 덕분에 올해는 일정 관리가 꽤 잘 된 한 해였던 것 같습니다. 예를 들어, 백준 스트릭 기록도 12월 31일 기준으로 729일째 이어지게 되었습니다.

5. 프로젝트

올해는 적당한 수의 프로젝트를 진행했던 것 같습니다. 다만 이 프로젝트들을 동시에 진행했던 적도 있어서 조금은 버거웠던 감도 있었습니다. 내년에는 동시에 최대 2개 정도로, 1개는 큰 볼륨의 프로젝트, 1개는 작은 볼륨의 프로젝트로 진행하는 게 좋을 것 같습니다.

5.1. 코드.kr

코드.kr 이라는 Obsidian 기반의 웹 블로그 프로젝트를 진행했습니다. 만드는 데에는 몇 시간 들지도 않았고, 점차 글들을 추가하면서 발전시켜 나가는 방식으로 진행하고 있습니다.

먼저 obsidian에서 글을 작성하고, 이 내용을 Github repo에 올립니다. 그리고 자동으로 Cloudflare Pages에서 이 Repo를 빌드하여 정적 웹사이트로 배포하는 방식입니다. 이때 Obsidian Quartz 테마를 사용했습니다.

이후에는 테마를 제 입맛에 맞게 수정하고, 디자인을 바꾸면서 더 꾸며나가려고 합니다. 그리고 글도 꾸준히 올리려고 합니다.

5.2. 깜빡이

깜빡이 프로젝트는 4호선톤에 참가하여 진행했던 프로젝트입니다. 좋은 팀원들을 만나서, 색다른 아이디어를 접할 수 있었던 경험이었습니다.

만 5~10세 아동의 집중력 향상을 목표로 하는 아동 교육 서비스이며, 게이미피케이션 요소를 도입하여 아이들이 즐겁게 게임을 하면서도 집중력을 기르고, 그 결과에 대한 리포트를 부모님께 제공하는 서비스입니다.

저는 인프라 및 백엔드 개발을 담당해서 진행했습니다.

처음에는 홈랩에 있는 K8s 클러스터를 통해 배포하였지만, 나중에는 AWS로 이전하여 배포했습니다. (개발 과정 중에 한번 홈랩 k8s 클러스터가 돌아가는 미니 PC가 전원이 꺼지는 등의 이슈가 있었고 해커톤 진행 중에 서비스가 다운되면 복구하기가 어렵기 때문에 이런 결정을 했습니다.)

인프라 구성은 이곳에서 다루고 있습니다.

그리고 백엔드는 django, drf, postgresql, redis, celery를 활용하여 개발했습니다. 제가 굉장히 애용하는 기술 스택이을 거의 그대로 활용했고 개발의 속도를 빠르게 낼 수 있었습니다.

이 프로젝트를 진행하면서 가장 신경 쓴 점은 PDF 리포트 생성 및 메일 발송 부분이었습니다.

PDF로 변환해야 하는 리포트 페이지는 프론트엔드에서 구현되어있고, 이 페이지는 사용자 로그인 후 접근해야 하는 페이지였습니다. 그래서 단순히 해당 페이지의 HTML을 가져오거나, URL에 접근하는 방식으로는 PDF를 생성할 수 없었습니다.

단순하게 제가 떠올린 해결책은 일회용 토큰이었습니다. 백엔드에서 PDF 생성 과정 중에 일회용 토큰을 발급하고 첨부하여 해당 페이지에 접근하게 했습니다. 프론트엔드 로직에서는 해당 토큰을 Header에 담아 백엔드 API에 요청을 보내면 이를 통해 User 인증을 처리했고, 인증이 완료된 상황에서 페이지를 렌더링 하여 PDF로 변환하는 방식을 적용했습니다. (약간 회사에서 경험했던 내용을 간단하게 해커톤 프로젝트에 적용해본 셈이었는데, 나름 잘 동작해서 다행이었습니다.)

이 과정에서 celery를 활용하여 비동기적으로 PDF 생성 작업을 처리했고, PDF를 첨부하여 메일을 발송했습니다.

이 프로젝트에 대한 자세한 내용은 이곳에서 확인할 수 있습니다.

5.3. Athena 프로젝트

Athena 프로젝트는 1학기에 수강한 웹서버컴퓨팅 과목의 AD 과제 겸 SIPE 미션에서 AI를 활용하는 프로젝트로 진행했습니다. 저 혼자 프로젝트 설계와 개발을 모두 진행했습니다.

이 프로젝트는 알고리즘 문제 풀이를 도와주는 AI 기반의 웹 서비스입니다. 백준 온라인 저지 문제를 기반으로 사용자가 코드를 제출하면, 먼저 코드를 실행하고 테스트케이스를 통과하는지 확인합니다. 만약 테스트케이스를 통과하지 못한다면 반례를 찾아냅니다. 반례가 없었다면 AI 모델을 활용하여 코드의 문제점을 분석하고 사용자에게 피드백을 제공합니다.

사용자는 계속해서 피드백을 적용하면서 코드를 개선할 수 있게 됩니다. 이 과정에서 반례 데이터나 피드백 데이터가 계속 수집되게 되고, 이를 통해 AI 모델이 점점 더 정확한 피드백을 제공할 수 있도록 합니다.

이 프로젝트에서는 docker-compose와 Docker를 기반으로 로컬에서 동작하는 환경까지만 구축했습니다. 이후에는 k8s 클러스터에서 동작하는 과정으로 확장할 수도 있지만, 마이크로서비스에 대해서 좀 더 경험을 쌓으면서 진행하는 게 좋을 것 같아서 일단은 여기서 마무리했습니다.

이 프로젝트는 아래와 같이 여러 개의 서비스들로 나누어 구성되어 있습니다.

웹앱은 django의 MTV 패턴을 그대로 사용하여 구성했습니다. 코드 실행은 Rust로 작성된 code-executor 서비스에서 처리했습니다. 그리고 이 서비스를 활용하여 코드 채점을 처리하는 code-judger 서비스를 구성했으며, 테스트케이스 생성을 위해 LLM 서비스와 채점 기능을 활용하는 code-testcase-generator 서비스를 구성했습니다. 그리고 이 모든 서비스들은 Docker container로 구성되었고, grpc를 통해 서로 통신하도록 설계했습니다.

완성도가 높지 않았다고 생각했고 실제로 서비스가 운영되기에는 어려운 점이 있었던 것 같습니다. 그래도 국민대학교 2025학년도 1학기 소프트웨어융합대학 크리에이터 경진대회에서 1등을 수상하는 성과를 거두기도 하면서 나름 의미 있는 프로젝트였던 것 같습니다. 그리고 혼자서 진행한 프로젝트였지만, 여러모로 배운 점도 많았기에 재미있게 진행했던 것 같습니다.

5.4. Palette

Palette 프로젝트는 사주 기반의 소개팅 서비스입니다. 아직 실제 사용자에게 배포가 되지는 않았습니다.

이 프로젝트에서는 실제 사용자들의 사주 데이터를 기반으로, 사주 궁합이 좋은 사람에 대해 매칭을 해주는 기능을 제공하고 있고, LLM을 활용하여 사주 궁합을 설명해 주는 기능도 제공합니다.

PASS 인증이나 토스 페이먼츠 등을 활용해서 인증 및 결제 기능까지 구현해 두었고, k8s 클러스터 배포 및 CI/CD 파이프라인도 구축했습니다. 이후에 실제 사용자가 사용하고 여러 피드백과 이슈를 처리하면서 내용을 정리하여 다시 글을 작성해 보겠습니다.

6. 자격증

올해도 마찬가지로 자격증 시험들을 치렀습니다.

정보처리기사, ADsP, 제한무선통신사, PCCP, 운전면허를 취득했습니다. 그리고 리눅스마스터 필기시험도 통과했지만, 실기 시험은 미루다가 결국 2026년으로 넘어가게 되었습니다.

정보처리기사 : 미루고 미루다가 무난하게 합격했습니다. 공부 기간이 그렇게 길지는 않았고 전공 개념을 복습하는 느낌으로 공부했습니다.
ADsP : 데이터 분석에 대한 기초적인 개념들을 공부했습니다. 실제 업무를 진행하는 과정에서 데이터 분석 업무를 진행하시는 분들과 협업하거나 소통할 때 도움이 되지 않을까 싶어서 취득했습니다. 이후에 인공지능 공부나 데이터 용어를 접하면서 도움이 되었습니다.
제한무선통신사 : 군대에서 무선 통신을 옆에서 지켜보면서 관심을 가지게 되어 취득하게 되었습니다. 단순히 기초 개념 강의를 듣고 간단한 문제 풀이로 취득할 수 있는 자격증이었습니다. 이후에 아마추어무선기사 자격증 쪽으로도 도전해 볼까 생각 중입니다. 취미로도 괜찮을 것 같고, 무선 통신에 대한 이해도를 높이는 데에도 도움이 될 것 같습니다.
PCCP : 국민대학교 내에서 해당 자격증의 점수가 필요한 경우가 있어서 취득하게 되었습니다. 코딩테스트는 평소에 미리 계속 연습해 오던 터라, Lv4로 무난하게 취득했습니다. 시간 관리를 신경 쓰면서 풀었으면 Lv5도 가능했을 것 같다는 생각이 듭니다.
운전면허: 너무 오랫동안 미루다가 취득하게 되었습니다. 1종 보통 면허를 취득했고, 클러치 조작이 처음에 너무 어려웠는데, 연습하다 보니 금방 적응했던 것 같습니다. 하지만 자동 차량을 운전할 것 같고.. 장롱면허가 될 것 같기도 합니다.

결론

올해는 많은 사건, 사고가 있었습니다. 그 속에서 다양한 경험을 했고, 많은 사람을 만났습니다. 그리고 개발자로서의 커리어를 쌓다가 학생으로 돌아가서 다시 공부에 전념하기도 했습니다.

내년에는 진짜 졸업을 앞두고 있습니다. 캡스톤 프로젝트를 진행해야 하고, 새로운 직장을 찾아야 합니다. 그래서 2026년에는 좀 더 집중해서 공부하고, 준비를 해야 할 것 같습니다.

Java / Spring 공부, Golang, Django와 Rails 근본 파헤치기, 캡스톤 프로젝트 등등. 할 게 많이 떠오릅니다. 어찌 되었든 2026년에도 열심히 달려보려고 합니다.

모두 좋은 한 해를 보내셨길 바라며, 그리고 2026년에도 좋은 일들만 가득하시길 바랍니다.

저의 넋두리같은 글을 읽어주셔서 감사합니다!

Atcoder Beginner Contest 399 후기

koa (김신건) — Sun, 30 Mar 2025 10:00:00 GMT

개요

대회 링크

어제 (03/29) 저녁 9시부터 10시 40분까지 진행된 [[Atcoder]] Beginner Contest 399 후기입니다.

총 7문제 중 4문제를 풀었습니다.

A번부터 D번까지 풀이하는데 19분을 소모했습니다. 이후 E번과 F번을 풀기 위해서 대회 종료시각까지 트라이를 했지만 풀이하지 못했습니다. rating이 떨어지나 걱정했지만, 다행히도 rating이 약간 올라서 안심했습니다.

공식 에디토리얼 (해설)

풀이

해설은 꼭 문제를 한번 읽고 확인해주세요.

A - Hamming Distance

문제 내용

두 문자열이 주어진다.

두 문자열의 해밍 거리 (서로 다른 문자의 개수)를 구하면 된다.

풀이

문자열을 순회하면서 서로 다른 문자의 개수를 구하면 됩니다.

B - Ranking with Ties

문제 내용

N 개의 score가 주어집니다.

각 score마다 RANK() 를 구하면 됩니다. (sql의 RANK()와 같이)

풀이

정렬을 사용하거나, map을 사용하거나 기타 등등 RANK()를 구현하기만 하면 됩니다.

C - Make it Forest

문제 내용

무향 그래프 F가 주어집니다.

간선을 지워 cycle이 없는 그래프가 만드려고 합니다. 이때, 지워야 하는 간선의 최소 개수를 구해야 합니다.

풀이

처음에 이렇게 풀어도 되는건가? 좀 헷갈렸다. 몇 가지 그래프를 그리다보니 확신을 하게 되었고, 아래와 같이 구성을 했다.

1 ~ N 까지 정점을 탐색하는데, 각 정점이 방문되지 않은 경우 DFS 탐색을 한다.
그리고, 만약 이전에 방문했음에도 다시 방문하게 되면 카운팅한다. 

단, 부모로 다시 탐색을 하러 돌아가는 경우는 배제해야 한다.

D - Bonfire

문제 내용

같은 숫자임에도 서로 인접하지 않은 두 숫자를 고른다.
두 숫자의 위치를 서로 바꾸어봤을 때, 각 숫자가 인접하게 된다면 카운팅한다.

풀이

솔직히 이 문제가 D번이 맞나? 싶었다. 생각보다 너무 쉽게 풀리는 문제였다.

그냥 각 숫자마다 위치 2개를 따로 hash 또는 배열에 저장해둔다.

그리고 앞에서부터 순회하면서 인접한 두 숫자에 대해서 저장해둔 위치로 조건을 판단해보면 된다.

E - Replace

문제 내용

문자열 S와 T가 주어진다.

문자열 S를 T로 바꾸길 원한다.

다만, 문자열 S에 존재하는 임의의 문자를 모두 하나의 문자로 바꾸는 연산만 가능한 상황이다.

이때, S를 T로 바꾸는 것이 가능한지, 가능하다면 최소 연산의 수가 어떻게 되는지 구해야 한다.

풀이

결국 풀이하지 못한 채로 대회가 종료되었다.

내 접근은 S->T로 가기 위한 과정을 유향 그래프화 시키는 것이었다. 만약 ab -> cb 라면 a -> c 라는 간선을 추가하는 것처럼 말이다.

이 과정에서 cycle이 없다면 간선의 수가 답이었고, cycle이 있다면 cycle로 변하는 과정에서 임의의 temp 문자로 변환되었다가 맨마지막에 변환되는 식이 되지 않을까 해서 간선의 수 + 1 을 더하는 방식이었다.

다만 이 과정을 구하는게 까다로웠고, 현재 temp 문자로 사용할 수 있는 문자가 있는지 등을 체크하기 위해 SCC와 위상정렬을 막 적용하다가 시간이 끝났다…

결론

7문제 중 4문제를 풀이하고 끝나서 굉장히 찝찝한 contest였다. 트리나 그래프 문제가 나오면 아직도 망설임이 좀 있는 것 같다. 관련 문제와 아이디어들을 좀 더 접할 필요가 있는 것 같다.

Atcoder Beginner Contest 398 후기

koa (김신건) — Sun, 23 Mar 2025 02:20:00 GMT

개요

대회 링크

어제 (03/22) 저녁 9시부터 10시 40분까지 진행된 [[Atcoder]] Beginner Contest 398 후기입니다.

총 7문제 중 6문제를 풀었습니다.

A번부터 D번까지 풀이하는데 20분을 소모했고, E번이 interactive 문제였고, 아이디어가 떠오르지 않아 F번 먼저 풀이하였고 이때 20분 정도 시간이 걸렸습니다. 그 이후, E번 풀이를 떠올리고 풀이하는데 25분 가량 걸렸습니다. 그리고도 시간이 남아서 G번을 확인하였습니다. 다만, 이때까지도 모든 문제를 풀이한 사람이 없던 상황이었고, G번의 난이도가 쉽지 않다는 것을 알게 되었습니다. 여러 접근을 했지만 풀이를 알아내지 못하고 대회가 종료되었습니다.

공식 에디토리얼 (해설)

풀이

해설은 꼭 문제를 한번 읽고 확인해주세요.

A - Doors in the Center

문제 내용

- 와 = 로 구성된 팰린드롬 문자열을 만드는 문제이다.

풀이

주어지는 N이 홀수인지, 짝수인지에 따라 문자열을 구성하면 된다.

B - Full House 3

문제 내용

7개의 숫자가 주어진다. 이 숫자를 조합하여 풀하우스를 만들 수 있는지 구하면 된다.

풀이

서로 다른 숫자 a, b에 대해, a의 개수는 3개 이상, b의 개수는 2개 이상인지 검사하면 된다.ㄴ

C - Uniqueness

문제 내용

1 ~ N 번 사람이 각자 숫자를 가지고 있다.

다른 사람들이 가지고 있지 않는 사람들 중에, 가지고 있는 숫자가 가장 큰 사람의 번호를 반환해야 한다.

풀이

솔직히 지문을 읽고, 뭔 이상한 소리인가 싶었고, 예제 또한 이상하게 주어져있어서 조금 당황했다. discussion에서 다른 사람들도 헷갈릴 여지가 있었던 것으로 보인다.

위에 문제 내용을 그대로 구현하면 된다.

D - Bonfire

문제 내용

모닥불에서 연기가 생성된다.
각 시간(틱)마다 바람이 분다. 이때 특정 (R, C)에 있는 사람에게 연기가 닿았는지 확인하여 모든 시간마다의 결과를 출력한다.

풀이

원래라면 모닥불로 하여금 생긴 연기를 계속 움직여가며 판단할 수 있다. 하지만 연기의 최대 개수가 200,000 개 이기 때문에 N^2이 되는 순간 해결할 수가 없다. 그래서 문제를 보자마자 바로 구현하기 시작한건 연기를 고정시키고 모닥불(0, 0)과 사람 (R, C)을 계속 이동시키자였다.

아래와 같이 구현했다. 다만 좌표를 저장할때 특정 int value로 담아두고 싶어서 좌표를 변환하여 했다. 지금 생각해보면 그냥 tuple로 저장해도 되었을 텐데라는 아쉬움이 남는다.

DIFF = 400000
K = 10000000

def to_axis(y, x):
  return y * K + x

def solve():
  n, r, c = mii()
  s = inp()

  maker = [DIFF, DIFF]
  dy = { 'N': 1, 'S': -1, 'W': 0, 'E': 0 }

  dx = { 'N': 0, 'S': 0, 'W': 1, 'E': -1 }
  r += DIFF
  c += DIFF

  smokes = {}

  ans = ""

  for i in range(n):
    direction = s[i]

    axis = to_axis(*maker)
    smokes[axis] = True
    maker[0] += dy[direction]
    maker[1] += dx[direction]

    r += dy[direction]
    c += dx[direction]

    if smokes.get(to_axis(r, c), False):
      ans += "1"
    else:
      ans += "0"

  print(ans)

E - Tree Game

문제 내용

트리가 주어진다. 이때 트리에 간선을 추가하는 액션을 각 턴마다 진행한다.
단, 간선을 추가함으로서 홀수개의 노드로 구성된 cycle이 생기면 안된다.
더이상 추가할 수 있는 간선이 없는 경우 패배한다.

상대와 게임을 진행함에 있어서, 선공/후공을 정하여 승리해야 한다.

풀이

처음에는 인터랙티브 문제이기도 하고 풀이가 잘 떠오르지 않았다. 그러던 중 예시를 여러 개 만들어보다가 떠오른 생각이 있었다.

처음에 주어지는 트리 상에서, 서로의 거리가 홀수로 떨어져 있는 경우면서 바로 이어지지 않은 경우가 결국 간선을 만들어낼 수 있는 경우 아닌가?

정점의 개수 N이 최대 100까지였기 때문에 구현을 빠르고 쉽게하기 위해, 플로이드-와샬로 미리 거리를 구했고, 서로의 거리가 홀수로 떨어져 있는 경우면서 바로 이어지지 않은 경우 == ar[x][y] % 2 == 1 && ar[x][y] > 1에 대한 간선을 미리 구해두었다.

그래서 이 간선들을 토대로 내 턴에는 아무거나 출력하고, 상대 턴에는 주어지는 간선을 제거하면서 처리해봤다.

ll ar[110][110];

void solve() {
  ll N;

  cin >> N;

  for(int i = 0; i <= N; i++) {
    for(int j = 0; j <= N; j++) {
      ar[i][j] = INF;
    }
    ar[i][i] = 0;
  }

  for(int i = 1; i < N; i++) {
    int a, b;
    cin >> a >> b;

    ar[a][b] = 1;
    ar[b][a] = 1;
  }

  for(int z = 1; z <= N; z++) {
    for(int x = 1; x <= N; x++) {
      for(int y = 1; y <= N; y++) {
        if(ar[x][y] > ar[x][z] + ar[z][y]) {
          ar[x][y] = ar[x][z] + ar[z][y];
        }
      }
    }
  }

  vector <pii> ans_list;
  for(int x = 1; x <= N; x++) {
    for(int y = x + 1; y <= N; y++) {
      if(ar[x][y] % 2 == 1 && ar[x][y] > 1) ans_list.push_back({ x, y });
    }
  }

  if(ans_list.size() % 2 == 0) {
    cout << "Second" << endl;
  } else {
    cout << "First" << endl;

    cout << ans_list[0].first << " " << ans_list[0].second << endl;
    ans_list.erase(ans_list.begin());
  }

  while(1) {
    int a, b;

    cin >> a >> b;

    if(a == -1 && b == -1) return;

    if (a > b) {
      swap(a, b);
    }

    for(int i = 0; i < ans_list.size(); i++) {
      pii current = ans_list[i];

      if(current.first == a && current.second == b) {
        ans_list.erase(ans_list.begin() + i);
        break;
      }
    }

    cout << ans_list[0].first << " " << ans_list[0].second << endl;
    ans_list.erase(ans_list.begin());
  }
}

F - ABCBA

문제 내용

문자열 S가 주어졌을 때, 문자열 S를 prefix로 하는 팰린드롬을 만들어야 한다.

풀이

보자마자 manacher 알고리즘이 떠올랐다. manacher 알고리즘은 특정 위치를 중심으로 팰린드롬의 길이를 구할 수 있는 알고리즘이다. 만약 이렇게 어떤 위치에서 구한 팰린드롬이 문자열 끝까지 도달할 수 있다면, 문제에서 원하는 문자열 S를 prefix로 하는 팰린드롬을 만들 수 있는 상황일 것이다. 따라서 앞에서부터 순차적으로 확인하다가 해당 경우인경우 바로 출력하게 했다.

단, 이때 홀수 길이의 팰린드롬과 짝수 길이의 팰린드롬인지에 따라 약간의 구현 처리가 필요하다.

아래 코드는 manacher 알고리즘의 일부 구현 내용을 생략하여 문제에 맞게 활용한 코드이다.

vector<int> manacher(string& s){
    int n = s.size(), R = -1, p = -1;
    vector<int> A(n);
    for(int i=0; i<n; i++){
        if(i <= R) A[i] = min(A[2*p-i], R-i);
        while(i-A[i]-1 >= 0 && i+A[i]+1 < n && s[i-A[i]-1] == s[i+A[i]+1]) A[i]++;
        if(i+A[i] > R) R = i+A[i], p = i;
    }
    return A;
}

string space(string& s){
    string t;
    for(char c: s) t+= c, t+= ' ';
    t.pop_back();
    return t;
}

void solve() {
  string s, o;

  cin >> s;
  o = s;

  int n = s.length();
  s = space(s);
  vector <int> ret_1 = manacher(s);

  int k = ret_1.size();
  int ans = ret_1.size() - 1;

  for(int i = 0; i < k; i++) {
    if (i + ret_1[i] == k - 1) {
      ans = i;
      break;
    }
  }

  if(ans % 2 == 0) {
    int org_idx = ans / 2;

    for(int i = 0; i <= org_idx; i++) {
      cout << o[i];
    }
    for(int i = org_idx - 1; i >= 0; i--) {
      cout << o[i];
    }
  } else {
    int org_idx = ans / 2;
    
    for(int i = 0; i <= org_idx; i++) {
      cout << o[i];
    }
    for(int i = org_idx; i >= 0; i--) {
      cout << o[i];
    }
  }
}

G - Not Only Tree Game

문제 내용

E번에서 주어지는 문제 조건과 유사하다.
단, 해당 문제에서는 트리가 아닌 그래프가 주어진다.
심지어 서로 연결되어 있지 않는 경우도 존재한다.

이때 2명의 플레이어가 게임을 진행한다고 했을 때 어떤 플레이어가 이기는지 출력해야 한다.

풀이

풀이가 전혀 떠오르지 않았다. 에디토리얼은 여기 있다.

결론

그래도 7문제중 6문제를 무난하게 풀이한 contest 였다. 오랫동안 굳었던 머리가 다시 풀리는 느낌이라 좋았던 대회지만, 대회 자체의 문제 난이도와 배치는 조금 이상했던 것 같다.

Atcoder Beginner Contest 396 후기

koa (김신건) — Sun, 09 Mar 2025 09:20:00 GMT

개요

대회 링크

어제 (03/08) 저녁 9시부터 10시 40분까지 진행된 [[Atcoder]] Beginner Contest 396 후기입니다.

총 7문제 중 5문제를 풀었습니다. A ~ D번까지 문제를 보자마자 바로 풀이하였고, 21분 소요했습니다. 여전히 구현이 느립니다. 더 땡겨야 합니다. E번 문제를 대강 풀이하고 제출했는데, 최적화된 해답을 출력하지 않았고, 이를 해결하는데 시간을 오래 사용했습니다. 마지막 제출을 대회 종료 5초전에 했고, 대회가 종료된 후 AC를 확인했습니다.

공식 에디토리얼 (해설)

풀이

해설은 꼭 문제를 한번 읽고 확인해주세요.

A - Triple Four

3번 연속된 숫자가 있는 경우, Yes 아니면 No를 출력한다.

문제에 주어지는대로 바로 구현하면 됩니다.

B - Card Pile

스택에 카드를 넣는 연산과 맨 위의 카드를 확인한 후, 빼는 연산 구현

문제에서 주어지는대로 스택을 사용하면 됩니다. 단, 100개의 0을 이미 넣어놓은채 시작하는 전제조건을 확인해야 합니다.

C - Buy Balls

검정색 공들과 흰색 공들이 숫자가 적혀진 채로 주어진다.

각 공을 고르고, 고른 공의 숫자들을 합쳤을 때 최대가 되도록 해야 한다. 단, 고른 검정색 공의 수가 흰색 공의 수보다 크거나 같아야 한다.

아래와 같이 그리디하게 최대한 검정, 흰색을 동시에 선택하다가, 흰색공을 선택하지 않아도 되는 경우에는 검정색만 고르도록 했다.

def solve():
  B = sorted(B, reverse=True)
  W = sorted(W, reverse=True)

  s = 0
  for i in range(min(n, m)):
    if B[i] + W[i] > 0 and W[i] > 0:
      s += B[i] + W[i]
    elif B[i] > 0:
      s += B[i]
  
  for i in range(min(n, m), n):
    if B[i] > 0:
      s += B[i]
  
  return s

D - Minimum XOR Path

그래프가 주어진다. 그래프의 간선에 가중치가 주어진다.

다만, 해당 가중치를 더하는 연산이 아닌, XOR 연산을 수행했을 때, 1 ~ N 까지 단순 경로로 도달했을 때 최소 값을 구하라

N이 크지 않게 주어졌다. DFS로 모든 단순 경로를 탐색하도록 했다. 아래에 일부 코드를 적어두었다.

n = m = 0
edges = []
mn = []
chk = []

def dfs(node, label):
  global n, m, edges, mn, chk

  if chk[node]:
    return
  
  chk[node] = True
  mn[node] = min(mn[node], label)

  for edge in edges[node]:
    dfs(edge[0], label ^ edge[1])
  
  chk[node] = False


def solve():
  global n, m, edges, mn, chk

  dfs(1, 0)
  print(mn[n])

E - Min of Restricted Sum

문제가 복잡하게 주어졌지만, 요약하자면 다음과 같다.

노드 번호1, 노드번호2, 두 노드 사이의 가중치가 나열된다.

각 노드마다의 값을 구해야 한다. 이때 각 노드 사이의 값 끼리 XOR연산을 했을 때 주어지는 가중치와 동일하도록 해야 한다.

문제를 보다보니, XOR 연산의 특성을 고민해보다 결국 시작 노드에서 아무 값으로 시작해도 그래프가 정상적으로 주어졌다면 어떻게든 값이 나온다는 사실을 알았다. 그래서 무작정 각 노드마다 탐색을 해서, 탐색이 되지 않은 경우 0으로 시작해서 그래프를 탐색하도록 했다.

하지만, 이는 틀린 답이었고, 이유를 찾지 못하다가 뒤늦게 문제 상 주어진 조건을 놓쳤음을 알게 되었다.

If there are multiple good sequences with the same minimum sum, printing any of them is accepted.

그럼 최소를 어떻게 찾아야할까를 계속 고민하다가, 각 그래프 탐색을 하면서 탐색이 된 노드들을 그룹지어놓고, 각 그룹마다 1, 2, 4, 8, 16, … 를 모든 노드값에 XOR 연산을 하면서 최소값이 된 경우 갱신을 하는식으로 구현을 추가했다.

해당 구현을 하다가 조금 구현 실수를 하면서 WA를 계속 맞았지만, 대회 종료 직전에 제출한 코드가 AC를 받으면서 종료되었다.

결론

이번에는 E번 문제를 좀 쉽게 접근하고나서, 더 생각이 떠오르지 않아 망설임이 많았습니다. XOR 연산에 대해서 좀더 잘 알게 된 competition이었던 것 같습니다.

Atcoder Beginner Contest 395 후기

koa (김신건) — Sun, 02 Mar 2025 02:50:00 GMT

개요

대회 링크

어제 (03/01) 저녁 9시부터 10시 40분까지 진행된 [[Atcoder]] Beginner Contest 395 후기입니다.

총 7문제 중 5문제를 풀었습니다. A ~ E번까지 문제를 보자마자 해답은 바로 떠올랐지만, 코드를 작성하는 시간이 오래 걸렸습니다. F번, G번 문제를 읽고나서 도저히 바로 해답이 안떠올라서 대회를 그대로 종료했습니다.

공식 에디토리얼 (해설)

풀이

해설은 꼭 문제를 한번 읽고 확인해주세요.

A - Strictly Increasing?

N 개의 숫자가 주어집니다.
N 개의 숫자들이 엄밀하게 증가하는 수열로 주어졌는지 판단하면 됩니다.

그냥 구현하면 됩니다.

B - Make Target

자연수 N이 주어집니다.

문제 규칙에 맞게 `#`과 `.`을 찍으면 됩니다.

수식으로 바로 해결해도 되고, N의 범위가 작기 때문에 반복문으로 돌려도 충분히 해결됩니다.

C - Shortest Duplicate Subarray

N 개의 숫자가 주어집니다.

주어지는 수열에서 `중복되는 숫자가 있는 부분 수열 중 최소 길이`를 구해야 합니다.

언뜻보면 브루트포싱으로 할 수 있겠다 싶지만, 숫자 범위가 그렇지 않습니다. 곧바로 각 숫자마다 분류하여 index를 저장했고, 각 index를 훑으면서 최소 격차를 가진 곳을 찾아 반환했습니다.

(처음에 문제를 잘못 읽어서 중복된 숫자가 없는 수열로 보았다가 시간 낭비를 했습니다.)

D - Pigeon Swap

해당 문제에서는 3가지의 연산이 있습니다.

1. 비둘기 한 마리가 이동한다.
2. 두 둥지에 있는 비둘기들이 서로 다 바꾼다.
3. A번 비둘기가 어디있는지 출력한다.

저는 이 문제를 보자마자, 그냥 어? 둥지 안에 있는 비둘기를 서로 바꾸는게 아니라 둥지에 가상의 라벨이 붙어있다고 생각하고, 그 라벨을 바꿔 붙였다고 생각하면 되는거 아닌가? 라고 생각을 했습니다.

그래서 비둘기마다 위치하는 둥지 위치, 각 둥지(번호를 매겨놓은)마다 붙어 있는 라벨, 각 라벨마다 붙어있는 둥지 원래 번호를 각각 저장했고 제 연산마다 적재적소로 활용해서 문제를 풀이했습니다.

어찌보면 포인터를 활용했다고 할 수 있겠네요.

아래는 코드의 일부 내용입니다

def solve():
  N, Q = mii()

  pigeon_place = [i for i in range(0, N)]
  place_label = [i for i in range(0, N)]
  place_label_rev = {}
  
  for i in place_label:
    place_label_rev[i] = i

  for _ in range(Q):
    commands = mii()

    if commands[0] == 1:
      a, b = commands[1:]
      a -= 1; b -= 1
      pigeon_place[a] = place_label_rev[b]

    elif commands[0] == 2:
      a, b = commands[1:]
      a -= 1; b -= 1

      A = place_label_rev[a]
      B = place_label_rev[b]

      place_label[A], place_label[B] = place_label[B], place_label[A]
      place_label_rev[a], place_label_rev[b] = B, A
    else:
      a = commands[1]
      a -= 1
      print(place_label[pigeon_place[a]] + 1)

E - Flip Edge

그래프가 주어집니다.
이때 1번 노드에서 N번 노드로 이동하면서 최단 거리를 알아내야 합니다.

단, 각 간선의 길이는 무조건 1입니다.
그리고 모든 간선의 방향을 뒤바꾸는 연산을 하면서 X 비용을 낼 수도 있습니다.

저는 문제를 보고, 이건 무조건 다익스트라 알고리즘으로 하면 되겠다 였고, 단 거리를 저장하는데 있어서 Distance[어느 방향으로 이 노드에 도달했는가? (0: 정방향, 1: 역방향)][노드 번호]와 같이 거리를 저장하기로 했고 각 노드에서 다시 방향을 유지하여 갈때는 원래 비용인 1을 사용하고, 방향을 바꿔서 갈때는 X + 1을 사용하여 가기로 설정했습니다.

아래는 코드의 일부 내용입니다.

struct Edge {
  ll node;
  ll cost;
  ll direction;
  Edge(ll node, ll cost, ll direction) : node(node), cost(cost), direction(direction) {}

  bool operator<(const Edge &to) const {
    return cost > to.cost;
  }
};

ll N, M, X;
vector<vector<vector<Edge> > > edges;
ll dist[2][220000];

ll dijkstra(ll s) {
  priority_queue<Edge> pq;

  pq.push(Edge(s, 0ll, 0));
  pq.push(Edge(s, X, 1));
  dist[0][s] = 0;
  dist[1][s] = X; // 모든 엣지를 역방향으로 바꾸면서 시작하는 경우

  while (!pq.empty()) {
    Edge cur = pq.top();
    pq.pop();
    
    if (cur.cost > dist[cur.direction][cur.node]) continue;
  
    // 만약 정방향으로 간다면
    for(auto nxt : edges[cur.direction][cur.node]) {
      if (dist[cur.direction][nxt.node] > cur.cost + nxt.cost) {
        dist[cur.direction][nxt.node] = cur.cost + nxt.cost;
        pq.push(Edge(nxt.node, dist[nxt.direction][nxt.node], cur.direction));
      }
    }

    // 만약 역방향으로 바꿔서 간다면
    for(auto nxt : edges[1 - cur.direction][cur.node]) {
      if (dist[1 - cur.direction][nxt.node] > cur.cost + X + nxt.cost) {
        dist[1 - cur.direction][nxt.node] = cur.cost + X + nxt.cost;
        pq.push(Edge(nxt.node, dist[1 - cur.direction][nxt.node], 1 - cur.direction));
      }
    }
  }

  return min(dist[0][N], dist[1][N]);
}

void solve() {
  for1(0, M) {
    ll a, b; cin >> a >> b;
    edges[0][a].push_back(Edge(b, 1, 0));
    edges[1][b].push_back(Edge(a, 1, 1));
  }

  cout << dijkstra(1);
}

F - Smooth Occlusion

풀이 X..

G - Minimum Steiner Tree 2

풀이 X..

결론

무난하게 5문제를 풀이하고나서, F, G번을 트라이할만한 시간이 남은 competition이었습니다. 다만, 오랜 기간동안을 손을 놓아서인지 구현 속도가 느리기도 했고 조금이라도 어려운 요소가 섞이니 접근이 잘 안되고 있습니다. 백준에서 골드/플레 문제 풀이를 해야할 것 같습니다..

새로운 시작을 준비하며, 그렙을 떠나 다시 학교로 돌아갑니다

koa (김신건) — Wed, 26 Feb 2025 04:25:00 GMT

새로운 시작을 준비하며, 그렙을 떠나 다시 학교로 돌아갑니다

안녕하세요, 백엔드개발자 김신건, Koa 입니다. 저는 2019년부터 함께한 그렙(Grepp)을 떠나, 다시 대학교로 돌아가기로 결심했습니다.

오랜 시간 인턴부터 정직원까지 쌓아온 경험과 애정이 깊은 회사지만, 지금은 제 자신을 더 깊이 탐구하기 위해 돌아가야 할 시점이라 느끼게 되었습니다. 이 결정은 분명 쉽지 않았습니다. 이 결정이 또 다른 성장의 기회가 될 거라 믿습니다.

그렙과의 지난 여정을 정리하면서, 저의 지난 발자취에 대해서도 공유해보고자 합니다.

C 언어 하나로 바뀐 꿈

저는 개발자를 꿈꾸던 사람이 아닙니다.

저는 어릴 적부터 기계공학자를 꿈꾸었고, 기계나 로봇을 설계하고, 설계한 것이 실제로 움직이는 걸 보면 가슴이 뛰는 아이였습니다. 하지만 “과연 내가 기계를 아주 잘 설계하고, 활용할 수 있는 사람인가?” 하는 근본적인 의문이 늘 따라다녔습니다. 그런 고민을 품고 지내던 중, 고등학교(한민고등학교) 방과 후 수업에서 C 프로그래밍을 처음 접했습니다.

처음에는 그저 호기심으로 시작했던 C 언어 공부였지만, 코드업(CodeUp) 사이트의 기초 100제를 풀어나가는 과정이 꽤 재미있었습니다. “나, 이거 꽤 잘하는 것 같은데?” 라는 작은 자신감이 쌓인 후, 300문제, 400문제를 연달아 풀었습니다. 그리고 곧장 정보선생님에게 찾아가 지금 당장 해야하는 공부에 댈해서 질문했습니다. 그렇게 알고리즘과 자료구조에도 본격적으로 입문했습니다. (그렇게 내신 성적은 점점 떨어졌지만요)

이때부터 여러 알고리즘 대회에 참가하기 시작했습니다. 다른 대회 참가자들에 비해 늦게 출발한 만큼 화려한 수상 성적을 거두진 못했습니다. 그래도 꾸준히 노력한 덕분에 가끔씩 장려상이나 동상을 받았고, 그 경험들이 저에겐 큰 동기부여가 되었습니다. 그리고 그 많은 대회 속에서 프로그래머스(Programmers) 사이트를 통해 대회가 진행되었는데, 이 플랫폼을 운영하는 기업이 바로 그렙이라는 사실을 훗날 알게 됩니다.

소프트웨어 특기자 전형으로 대학에 입학하다

고등학교 시절 학업 성적은 점점 떨어졌지만, 그동안 쌓아온 대회 수상 기록, 소논문 등으로 소프트웨어 특기자 전형에 도전했습니다. 6개의 대학에 지원했지만 그 중 5개는 고배를 마셨고, 마지막 한 곳에서 극적으로 합격 통지를 받았습니다. 그렇게 대학교에 입학해, 1학년 1학기를 보내며 여러 수업을 들었고, 방학 시즌에 현장실습을 하면 학점과 인턴 월급을 함께 받을 수 있다는 사실을 알게 되었습니다.

당시 여러 회사에 지원했지만, 최종적으로 그렙의 알고리즘 콘텐츠 제작 인턴으로 합격하여 방학을 그렙에서 보내게 되었습니다. 이 시기가 저와 그렙의 인연이 본격적으로 시작된 때입니다.

1학년 1학기 방학, 그렙에서 첫 인턴십

처음 회사로 출근하여, “내가 지금까지 공부해온 게 실제로 이렇게 쓰이는구나!”라는 사실이 무척 신기했습니다. 특히 제가 대회에서 사용했던 프로그래머스 서비스 내의 알고리즘 콘텐츠/문제들을 제작하는 과정에 기여할 수 있었다는 점이 큰 보람으로 다가왔습니다.

그래서 저는 최대한 열심히 업무를 수행했고, 저 스스로의 최대한의 역량을 발휘했습니다. 그리고 그렙에서 인연을 이어가며, 2학년 1학기 방학 때까지 알고리즘 콘텐츠 제작자로 계속 근무할 기회를 얻었습니다.

2학년 이후, 웹 개발로 시야를 넓히다

1학년에서 2학년 사이 기간 동안 스스로 한계를 느끼기도 했습니다. “내가 잘하는 건 알고리즘 문제 풀이뿐인가?”라는 생각이 들었습니다.

1학년의 저는 알고리즘만 아는 코더였던거죠. 그냥 문제 풀이만 할 줄 아는 사람이었습니다. 그것도 깊게 하지 못하는. 굉장히 스스로 부끄러웠고, 발전이 되고 있지 않았다는 것을 느꼈습니다. 마침 주변 지인들의 조언으로 웹 개발 동아리에 들어가게 됐고, 그곳에서 처음 웹 프레임워크와 프로젝트 구축 방법을 익혔습니다. 2학년 2학기가 끝나갈 즈음, “알고리즘 관련 말고, 웹 개발로 인턴을 할 수 있는 곳이 없을까?” 고민하던 차에, 그렙에서 개발 인턴으로 근무해볼 생각이 없는지 제안을 받았습니다. 덕분에 그렙과의 인연은 또 다른 국면에 접어들었습니다.

정직원으로 그렙에 합류, 그리고 군 복무

방학 인턴으로 웹 개발에 본격 뛰어들면서, 제가 실제로 사용하던 프로그래머스 서비스를 직접 개발하게 된다는 점이 참으로 매력적이었습니다. Ruby on Rails를 처음 접했고, Vue.js도 함께 다루면서 프론트엔드와 백엔드 양쪽을 모두 맛볼 수 있었습니다.

방학이 끝난 후 선택지가 생겼습니다. “계속 학교를 다닐까, 아니면 휴학 후 정직원으로 일하며 더 빠르게 성장할까?” 고민 끝에 저는 그렙에서 정직원으로 근무하기로 했습니다. 이후 2021년, 2022년에 걸쳐 채용사업부의 개발자로서 프로그래머스 채용 서비스와 비즈니스 서비스를 구축하고 개선하는 업무를 맡았습니다. 점차 백엔드 분야에 더 흥미를 느끼게 되어 서버 쪽을 심도 있게 파고들면서, 개발자로서의 시야를 넓혀갔습니다.

그러나 그 시기에 산업기능요원 제도가 바뀌면서, 저처럼 현역 판정인 사람은 산업체 복무가 불가능해졌습니다. 결국 군대를 더 이상 미룰 수 없다고 판단해 갑작스럽게 군대를 가게 되었습니다. 인생 계획이 어그러진 느낌이었지만, 한편으로는 “군대에서 조금이라도 휴식과 함께 생각을 정리할 수 있는 기회가 있겠지?”라는 희망도 있었습니다. (물론 자대 배치 이후의 현실은 그렇게 간단하지 않았지만요. 군 복무 이야기)

전역 후, 다시 그렙으로 복직 … 그리고 또 한 번의 고민

군 복무를 마치고 2024년 7월, 다시 그렙에 복직했습니다. 이번에는 교육솔루션팀에 합류해 교육 서비스를 개발하는 일을 맡았습니다. 8개월 정도 근무하면서, 안정적인 루틴과 급여 덕분에 편안함을 느꼈지만, 그 편안함 한편에서 “내가 진짜 하고 싶은 건 뭘까?”라는 고민이 점점 커졌습니다.

계속해서 새로운 기능을 만드는 데도 점차 흥미를 잃어가고, 동시에 사적인 프로젝트나 지식 탐구에도 예전 같은 열정을 쏟지 못하고 있다는 걸 깨달았습니다. 군대에 가기 전, “나는 성장하고 싶어!”라고 불타올랐던 그 마음이 어딘가 녹슬어버린 느낌이었습니다. 그러다 보니, "알고리즘만 아는 코더" 시절처럼 정체된 제가 부끄러웠습니다. “안정감만 쫓고 있으면, 결국 제자리걸음 아닌가?”라는 생각과 후회감이 들었고, 이번에는 스스로를 다시 새로운 환경에 던져 몰아붙여야겠다는 결심을 하게 되었습니다.

그래서 2025년 2월을 기점으로, 저는 그렙을 떠나 다시 대학으로 복학하기로 마음먹었습니다. 학교에서 좀 더 이론적인 공부를 보완하고, 새롭게 떠오르는 기술들에 집중해보고 싶습니다. 그 이후, 또 새로운 곳에 뛰어들어 가보고 싶습니다.

모든 선택에는 리스크가 따르지만, 지금이 아니면 안 될 것 같습니다. 물론 이 선택이 나중에 후회로 남을 수도 있습니다. 하지만 지금 이 시점에서 “기회비용을 감수하면서도 성장을 택하겠다”라는 다짐이, 오히려 저에겐 강력한 동력이 될 것 같다는 생각이 듭니다.

떠남은 끝이 아니라 또 다른 도약

저는 아직도, 계속해서 제 자신을 “부족한 개발자”라고 생각합니다.

특별히 잘하는 한 분야가 확고하게 잡혀 있는 것도 아니고, 일에 완전히 몰입하는 것도 잠시 주춤했던 때가 있었습니다. 그럼에도 "스스로를 몰아붙이고, 낯선 환경에서 새로운 경험에 뛰어드는 것" 만큼은 잘한다고 단언할 수 있습니다.

이번 결정이 누군가에게는 이해되지 않을 수도 있고, 저조차 훗날 후회할지 모릅니다. 하지만 그 후회조차도 분명 저를 더 나은 길로 이끄는 "새로운 동기부여"가 될 것이라 믿습니다.

그렙에서 함께했던 동료들, 그리고 프로그래머스를 통해 만났던 많은 분들께 감사 인사를 전합니다. "새로운 도전에 뛰어들려는 지금 이 순간"이 훗날 제가 더 큰 성장을 할 시작점이 되리라 믿습니다.

감사합니다.

Atcoder Beginner Contest 394 후기

koa (김신건) — Sun, 23 Feb 2025 05:00:00 GMT

개요

대회 링크

어제 (2/22) 저녁 9시부터 10시 40분까지 진행된 [[Atcoder]] Beginner Contest 394 후기입니다.

총 7문제 중 5문제를 풀었습니다. A ~ D까지 4문제는 대회 시작후 13분 안에 풀이했지만 E번 정확한 풀이를 생각해내는데 60분을 썼고, F번 문제를 읽고 끝났습니다.

공식 에디토리얼 (해설)

풀이

A - 22222

단순히 주어지는 숫자 문자열에서 2의 개수만큼 다시 2를 출력하는 문제입니다. 빠르게 구현하면 됩니다.

B - cat

주어지는 문자열을 문자열의 길이를 기준으로 정렬 후 차례대로 붙여 출력하는 문제입니다. 빠르게 구현하면 됩니다.

C - Debug

주어지는 문자열에서 WA 라는 문자열을 AC 라는 문자열로 계속해서 대체할 때, 최종 문자열을 구하는 문제입니다.

예를 들어, WWA 라는 문자열이 있으면 WWA → WAC → ACC 로 변합니다.

저는 단순히 처음에는 스택을 활용할까 생각했지만, 문자가 변하는 양상을 보니 W*X개+A*1개 의 형태를 갖춰야만 바뀐다는 걸 캐치하고, W의 개수를 세다가 A 문자가 등장하면 대체하는 식으로 코드를 구성했습니다.

D - Colorful Bracket Sequence

전형적인 안정적인 괄호 문자열 문제입니다. 다만, 괄호의 종류를 (), <>, [] 로 해두었습니다. 따라서, 관련 처리를 하면서 스택으로 해결하면 됩니다.

E - Palindromic Shortest Path

그래프가 주어집니다. 단, 정점이 아닌 “간선”마다 문자가 기록되어 있는 그래프입니다. 이때 모든 정점 사이의 페어마다, 간선의 문자열을 나열해서 팰린드롬이 되도록 하는 경로의 최소 길이를 구해야 합니다.

처음에 저는 BFS로 정점마다 출발하여 팰린드롬인지 파악하는 완전탐색으로도 1억 내외로 연산 수가 떨어지면 시간안에 들지 않을까라는 생각으로 트라이했습니다. 하지만 TLE가 나왔고, 다른 방법을 생각해야 했습니다.

이때 굳이 간선의 정보가 주어지고 있는데, 정점 기준으로 탐색할 필요가 있을까 생각이 들었습니다. 그래서 모든 간선은 일단 문자가 1개로 구성된 팰린드롬이고, 양 옆에 같은 문자를 이어 붙이면 팰린드롬이 되지 않을까 라는 생각으로 알고리즘을 구성했습니다.

먼저 정방향 간선 정보와 역방향 간선 정보를 저장한다.
모든 간선을 큐에 넣는다. (해당 간선은 길이가 1인 팰린드롬이기 때문에, { 시작점, 끝점, 길이=1 }) 와 같이 넣는다.
아래에서 설명 추가 과정 필요
큐의 맨 앞에 있는 간선에서 정방향 간선 정보와 역방향 간선 정보를 참조해, 앞 뒤로 같은 문자을 붙일 수 있느지, 붙일 수 있다면 그것이 현재 최소 길이인지 확인해서 갱신 후 큐에 다시 넣는다.
갱신된 모든 길이를 출력한다.

이 방법의 이점은 일단 간선의 정보만 다룬다는 것이고, 만들어진 문자열들이 팰린드롬인지를 체크할 필요가 없다는 것입니다.

그리고 이 방식은 홀수 길이인 경우만 알아낼 수 있는데 따라서 3번 과정에서 모든 i에 대해 i → i 로 가는 가상의 경로에 현재까지의 팰린드롬 길이가 0이다를 집어넣어놓으면 됩니다. { 출발점=i, 끝점=i, 길이=0} 과 같이 말입니다.

F - Alkane

그래프 정보가 주어집니다. 이때 아래 조건을 만족하는 부분 그래프의 최대 크기를 구합니다.

해당 그래프는 무향 그래프다.
모든 정점의 차수는 1 또는 4이다. (해당 정점에 이어지는 간선 수)

딱히 떠오르는 해답이 없었습니다…

G - Dense Buildings

문제조차 읽지 못했습니다.

결론

7문제 중 5문제를 풀이하면서 점차 예전의 실력을 되찾아가는 느낌이 들었습니다. 언젠가 모든 문제를 막힘없이 자연스럽게 다 푸는 실력까지 도달하고 싶습니다.

2022년 11월부터 시작된 1년 6개월 회고록

koa (김신건) — Tue, 28 May 2024 06:00:00 GMT

길면서 짧았던 군 생활을 마무리하며, 회고록을 작성한다.

서론

2022년 11월 28일, 논산 훈련소로 입대했습니다.

같이 오신 부모님과 되게 쿨한 작별 인사를 하고, 터벅 터벅 들어갔습니다. 이전에는 입소식도 했다고 하지만, 저는 코로나 막바지라 그런 행사 없이 바로 입소 관련 절차를 시작했습니다.

훈련소 내에서도 여러 일이 있었지만.. 시간이 바로 흘러 어느덧 수료식이었습니다. 수료식이 끝나고 부모님과 외출/면회를 하면서 저의 자대 배치 결과를 확인했습니다.

특전사령부.

????????? 저는 굉장히 당황스러웠고, 왜? 내가 어째서? 이게 맞아?

일단 특전사령부는 어디있지 하고 찾아보았고, 경기도 이천에 있다는 것을 확인했습니다. 와, 그래도 집 앞에 있는 부대로 가는구나 싶어서 신났습니다. (본가가 이천입니다)

그렇게 외출에서 복귀하고 자대 배치일을 기다려서, 그날이 왔습니다.

하지만 뭔가 이상했습니다. 이천으로 가는 길이라고 하기엔 너무 멀었고, 담당 간부님은 제가 전남 담양으로 간다고 말씀하셨습니다. 거기는 어디지..? 하고 물어보니 11공수특전여단이었고, 특전사령부의 예하 여단으로 가는 것이었습니다. 아.. 예하 부대는 표기가 안되는 거였구나 싶었고, 그렇게 전남 담양에서의 군 생활이 시작되었습니다.

자대 배치 후, 군 생활이 새로 시작되었다 할만큼 굉장히 많은 업무와 생활 룰(?)을 배웠고, 숙지했습니다.

그 이후, 여러 훈련도 하고, 업무/공부/운동을 반복하다 보니 1년 반이 흘렀습니다. (자세한 내용은 스킵. 알고 싶으면 술 사주면서…ㅎㅎ)

이제 한번 어떤 걸 공부했었는지 정리해보려 합니다. (군 관련 내용은 일부러 안 적었습니다.)

군대에서 공부하기

자격증을 땄다.

네트워크관리사 2급 자격증을 군생활 막바지에 땄습니다.

사실 필기 시험은 진작에 통과했었습니다. 나중에 따야지..따야지 하다가 막바지에 진짜 이제는 해야한다는 생각을 가지고 나중에서야 땄습니다..

그리고 전역 이틀 전에 SQLD 시험을 응시했고, 아마.. 합격이지 않을까 생각합니다.

백준 문제라도 풀자.

입대 전(2451문제) → 24.05.01(4034문제)로 약 1500문제 이상을 풀었습니다. 그리고 군생활 도중에 다이아5에서 다이아4로도 승급했습니다.

뭐.. 최대한 많은 문제와 할 수 있는 공부는 다 해보자라는 생각으로 계속 했던 것 같습니다. 그 덕분에 시간도 금방 간 것 같습니다.

강의를 듣자.

code.plus 사이트(스타트링크)에서 제공하는 알고리즘 고급으로 가는 연결고리 강의를 들었습니다.

인프런 - 외워서 끝내는 네트워크 핵심 이론 - 기초, 외워서 끝내는 네트워크 핵심 이론 - 응용 강의를 수강했습니다. 네트워크 관리사 자격증을 따면서 더 좋은 지식을 얻을 수 있을까 싶어 강의를 들었습니다. 상당히 좋은 강의였고 추천합니다.

인프런 - 외워서 끝내는 SSL과 최소한의 암호기술 강의를 수강했습니다. 위 네트워크 강의와 이어지는 부분이 많았고, 아직도 다시 찾아보면서 내용을 흡수하고 있습니다.

생활 코딩 - 정규표현식, Web2 : Oauth 2.0 강의를 수강했습니다. 이전부터 조금씩 내가 제대로 알고 있는 게 맞나 싶었던 부분을 긁어주었던 강의였습니다. 전역 후 다시 TIL 글로 정리해보려고 합니다.
인프런 - [그림으로 이해하는] 동기 비동기의 개념에 대한 가장 직관적인 이해라는 강의를 수강했습니다. 사실 거의 아는 내용이 나왔고, 조금 아쉬웠습니다. 차라리 이 강의를 몇 년 전에 비동기에 대한 이해가 없었을 때 봤다면 더 좋았겠다 싶습니다.
인프런 - SVG 마스터 강의를 수강했습니다. 뭔가 유익했지만 군대라는 현실에 실습을 거의 못해봤습니다. 조금 아쉽기에 이걸 활용한 사이드 프로젝트를 진행할 수 있을까 고민해봅니다.

앞으로는 뭘 하지?

남은 2024년 동안에는 아래 목표를 하나씩 차근차근 해보려 합니다.

일간 목표

아침 또는 저녁마다 운동을 한다. (안 되면 산책이라도)
매일 백준 문제 풀기 (적어도 1문제)

월간 목표

적어도 2권의 책을 읽는다. (종류 상관 X)
매주 일요일 혹은 매달 마지막에 무엇을 했는지 간단하게 정리하자.
TIL Repo에 꾸준히 기록물을 남긴다.

연간 목표

회사를 재밌게 다닌다.
연간 백준 500 AC를 도전한다.
자격증 / 운전 면허증 등의 자격증을 꾸준히 딴다.
Codeforces / Atcoder Contest에 주기적으로 참여한다. (Blue를 계속 유지할 수 있는 실력이 될 수 있도록)
Kaggle을 시작한다.
간단한 사이드 프로젝트를 적어도 2개 진행한다.
Spring과 K8s를 공부한다.
재미있는 자취 생활을 한다.

아무튼

드디어 끝났습니다.

제가 거창하게 나라를 지켰다고는 못하겠습니다.

저는 누군가가 계속 이어서 지켜오던 한 자리를 지켰고, 자리를 지키는 것 만큼은 최선을 다했다 생각합니다.

저는 앞으로 좀 더 다양한 경험을 사회에서 하면서 저의 길을 다시 걸어 가보겠습니다.

지금까지, 그리고 앞으로 나라와 각자의 자리를 지켜주시는 군인 여러분 감사합니다.

단결.

김신건의 로그

파일 디스크립터부터 소켓까지, 하나로 이어지는 흐름

시작 의문

1. 파일 디스크립터, 정수 하나로 자원을 가리키다

왜 그냥 포인터가 아니라 정수인가?

fd 는 프로세스 지역이다

2. 저수준 파일 I/O, 다섯 개의 시스템 콜

open(), fd 얻기

read(), write(), 실제 IO

close(), fd 반환

lseek(), 파일 커서

stdio (fopen/fread/…) 는 위의 wrapper 다

3. 소켓, 결국 fd 다

클라이언트 흐름

서버 흐름

왜 파일 API 가 소켓에 그대로 통하나?

4. 통합의 보너스, select / poll / epoll

5. 정리, 한 그림으로

지식 그래프가 너무 빽빽했다: D3 force simulation 재튜닝

어떤 상태였나

진단: 원래 파라미터 뽑아 보기

후보 해법 네 가지

파라미터를 함수로 바꾸기

forceCenter 대신 forceX / forceY

charge 사거리 제한을 풀기

초기 layout 을 넓게 뿌리기

Zoom-to-fit: 첫 프레임을 “다 보이는” 상태로

라벨은 zoom 이 낮으면 숨긴다

3D 뷰도 살짝

되돌아보기

Rails 에서의 Read/Write Database 분리

시작 의문

한 단계 뒤로, 왜 읽기와 쓰기를 분리하는가

Primary-Replica 복제 구조

분리해서 얻는 것

분리해서 잃는 것

Rails 설정, database.yml 과 connects_to

두 connection 정의

모델에서 role 매핑

자동 라우팅, DatabaseSelector 미들웨어

미들웨어 활성화

동작 방식

미들웨어가 컨트롤러 액션 전체를 감싼다

문제: GET 인데 쓰기가 필요한 경우

connected_to 로 role 수동 전환

ForceWrite Concern

블록 안에서 일어나는 일

실전 패턴

예시 1: 조회수 증가

예시 2: 검색 로그 기록

예시 3: OAuth 콜백

모델 / 서비스 객체에서도 쓰기

함정과 주의사항

1. 블록 안의 모든 쿼리가 writing 으로 갑니다

2. 트랜잭션 경계와 role 은 별개입니다

3. GET 의 멱등성

4. Delay 윈도우 안의 후속 GET

5. 미들웨어 우선순위

6. 테스트 환경에서의 분기

자동 라우팅 vs 수동 전환, 언제 무엇을 쓸까요

마무리

글 쓰는 즐거움을 위해 직접 만든 세 개의 도구: 에디터, 스튜디오, 차트 에디터

왜 도구부터 만들었나

1. 콘텐츠 에디터 (/_editor)

1.1 파일 트리, 단순한 탐색기가 아니다

1.2 마크다운 툴바, 37개 버튼의 의미

1.3 이미지 다이얼로그, 모든 경로를 한 곳에서

1.4 Git 패널, 에디터를 떠나지 않는다

1.5 자주 쓰는 단축키

1.6 잘 안 보이지만 매일 도움되는 것들

2. 애니메이션 스튜디오 (/_studio)

2.1 요소 타입 9종

2.2 요소 추가, 한 번의 클릭

2.3 속성 패널, 모든 디테일을 한 곳에서

2.4 캔버스, 그리는 공간

2.5 다중 선택과 정렬·분배

2.6 그룹화, 함께 움직이는 요소

2.7 타임라인과 챕터, 시간의 모양

2.8 재생, 의도한 움직임을 확인

2.9 아이콘 라이브러리, 1856개

Rails 설정, `database.yml` 과 `connects_to`

자동 라우팅, `DatabaseSelector` 미들웨어

`connected_to` 로 role 수동 전환

1. 콘텐츠 에디터 (`/_editor`)

2. 애니메이션 스튜디오 (`/_studio`)

3. Chart.js 에디터 (`/_chart-editor`)