boradora

묵시적 커밋과 AUTO COMMIT | TRUNCATE와 DELETE 차이, 롤백 안 되는 자리

boradora — Fri, 7 Aug 2026 09:41:01 +0900

작업일2026. 07

트랜잭션 AUTO COMMIT 묵시적 커밋 DDL TRUNCATE

SQL 문법은 익숙해도 커밋이 정확히 언제 일어나는지 놓치기 쉽습니다. 그런데 데이터를 되돌릴 수 없게 만드는 사고는 대개 문법이 아니라 이쪽에서 납니다.

BEGIN을 안 적고 UPDATE를 실행하면 어떻게 될까요?
대부분의 DBMS에서 그 문장은 이미 확정된 상태입니다. ROLLBACK을 칠 기회가 없습니다.

WHERE를 빼고 UPDATE를 날린 이야기는 실수담처럼 돌아다닙니다. 그게 왜 되돌릴 수 없는 사고가 되는지는 AUTO COMMIT을 알아야 설명이 됩니다. 그리고 트랜잭션을 제대로 열었는데도 중간에 조용히 끊기는 경우가 있는데, 그것이 묵시적 커밋입니다.

AUTO COMMIT

DELETE와 TRUNCATE는 둘 다 데이터를 삭제하지만, DML과 DDL이라는 점에서 근본적으로 다릅니다. 이름만 보면 TRUNCATE가 DELETE의 빠른 버전처럼 보이지만, 트랜잭션과 롤백, 트리거 동작까지 모두 다릅니다.

AUTO COMMIT은 각 SQL 문장이 끝날 때마다 자동으로 COMMIT하는 설정입니다. 기본적으로 켜져 있으면 각 SQL 문장이 하나의 트랜잭션으로 처리되고, 실행이 성공적으로 끝나면 자동으로 COMMIT됩니다.

BEGIN 없이 실행하면

UPDATE students SET grade = 1;

즉시 COMMIT

이 뒤에 ROLLBACK 을 쳐도 되돌아오지 않습니다. 되돌릴 트랜잭션이 이미 없습니다

BEGIN 으로 명시적으로 열면

BEGIN;

UPDATE ...

확인 후 결정

몇 행이 바뀌었는지 보고 COMMIT 이나 ROLLBACK 을 고를 수 있습니다

DBMS마다 기본값과 트랜잭션 시작 방법이 다릅니다.

DBMS	기본 AUTO COMMIT	트랜잭션 시작	DDL 실행하면
PostgreSQL	ON	`BEGIN;`	트랜잭션 안에서 실행되고 롤백됩니다
MySQL (InnoDB)	ON	`START TRANSACTION;`	묵시적 커밋 (`ALTER`·`CREATE`·`DROP`·`TRUNCATE`)
Oracle	OFF	DML을 시작하면 자동으로 열립니다	DDL 전후로 자동 커밋
SQL Server	ON	`BEGIN TRANSACTION;`	트랜잭션 안에서 실행되고 롤백됩니다

Oracle만 기본 AUTO COMMIT이 OFF입니다. 그래서 Oracle을 쓰다 MySQL이나 PostgreSQL로 옮기면 실수가 자주 발생합니다. Oracle에서는 UPDATE 후 COMMIT을 해야 변경이 최종 확정되므로 ROLLBACK으로 되돌릴 수 있습니다. 반면 MySQL이나 PostgreSQL은 기본 AUTO COMMIT이 켜져 있어, 명시적으로 트랜잭션을 시작하지 않았다면 문장이 성공적으로 실행되는 즉시 자동으로 COMMIT됩니다.

강의자료 표에는 PostgreSQL의 묵시적 커밋 칸에 "DDL 실행"이 적혀 있는데 괄호에는 "대부분 트랜잭션 내 허용"이 함께 적혀 있습니다. 두 설명이 서로 반대라서 여기서는 실제 동작인 롤백 가능 쪽으로 적었습니다. BEGIN; CREATE TABLE ...; ROLLBACK; 을 돌려보면 테이블이 사라지는 것을 확인할 수 있습니다.

묵시적 커밋

묵시적 커밋(implicit commit)은 COMMIT을 적지 않았는데 DBMS가 커밋을 실행해 버리는 것입니다. 주로 DDL에서 일어납니다. MySQL과 Oracle에서는 테이블 구조를 변경하는 DDL은 진행 중인 트랜잭션을 자동으로 COMMIT합니다.

MySQL 에서 위에서 아래로 실행했다면

1

START TRANSACTION;

2

DELETE FROM orders WHERE id = 101;

3

CREATE INDEX idx_tmp ON orders (created_at);
← 여기서 2번이 묵시적으로 커밋됩니다

4

ROLLBACK;
오류 없이 실행되지만 되돌릴 것이 없습니다

삭제한 주문은 이미 COMMIT되어 되돌릴 수 없습니다. ROLLBACK 이 아무 경고 없이 성공하기 때문에, 되돌렸다고 믿고 넘어가면 나중에 데이터가 왜 사라졌는지 원인을 찾느라 시간을 쓰게 됩니다.

그러므로 DML과 DDL을 같은 트랜잭션 안에서 실행하지 않는 것이 기본 원칙입니다. 스키마를 바꾸는 작업과 데이터를 바꾸는 작업은 따로 실행해야 합니다.

궁금!묵시적 커밋과 묵시적 트랜잭션은 같은 말인가요?

다른 말입니다. 트랜잭션의 어느 쪽 끝이 자동이냐가 갈립니다. 묵시적 커밋은 끝이 자동입니다. COMMIT 을 적지 않았는데 커밋이 일어나며, 위에서 본 DDL 이 여기 해당합니다. 묵시적 트랜잭션은 반대로 시작이 자동입니다. BEGIN 없이 트랜잭션이 열리는 대신 커밋은 직접 해줘야 하고, SQL Server 의 SET IMPLICIT_TRANSACTIONS ON 이 이 동작을 켭니다. 이름은 비슷한데 방향이 반대라, 묵시적 트랜잭션을 켜는 쪽은 오히려 AUTO COMMIT 을 끄는 것에 가깝습니다.

DELETE와 TRUNCATE 차이

같은 함정이 TRUNCATE에도 있습니다. 이름만 보면 DELETE를 더 빠르게 수행하는 명령처럼 보이지만 분류가 다릅니다.

구분	`TRUNCATE`	`DELETE`
분류	DDL	DML
속도	빠릅니다	행마다 처리하므로 느립니다
롤백	MySQL·Oracle에서는 불가 (자동 커밋)	가능합니다
트리거	실행되지 않습니다	실행됩니다
`WHERE`	쓸 수 없습니다 (전체 삭제)	조건을 걸 수 있습니다

트리거가 안 돈다는 점이 특히 위험합니다. 삭제될 때 이력을 남기거나 관련 데이터를 정리하는 트리거를 걸어뒀다면, TRUNCATE로 삭제하면 그 트리거는 전혀 실행되지 않습니다.

정리하면

AUTO COMMIT은 대부분 켜져 있습니다. Oracle만 기본이 OFF라, DBMS를 옮길 때 여기서 실수가 자주 발생합니다.
묵시적 커밋은 DDL에서 일어납니다. MySQL과 Oracle에서는 ALTER·CREATE·DROP·TRUNCATE가 진행 중인 트랜잭션을 끝냅니다
ROLLBACK은 되돌릴 것이 없어도 성공합니다. 오류가 안 났다고 되돌아간 것은 아닙니다
TRUNCATE는 DDL입니다. 빠른 DELETE가 아니라 롤백도 안 되고 트리거도 안 도는 다른 문장입니다

한 줄 정리: 커밋은 내가 입력하지 않아도 일어날 수 있고, ROLLBACK은 되돌릴 것이 없어도 성공합니다. 그래서 트랜잭션을 명시적으로 열고, 그 안에 DDL을 섞지 않습니다.

참고

MySQL 공식 문서: Statements That Cause an Implicit Commit
PostgreSQL 공식 문서: BEGIN
PostgreSQL 공식 문서: TRUNCATE

트랜잭션 격리 수준과 MVCC | ACID, WAL, Dirty Read와 Phantom Read

boradora — Wed, 5 Aug 2026 08:51:54 +0900

작업일2026. 07

트랜잭션 ACID 격리 수준 MVCC WAL PostgreSQL

혼자 테스트할 때는 문제없던 코드도 사용자가 동시에 몰리면 예상치 못한 문제가 발생합니다. 같은 데이터를 여러 트랜잭션이 동시에 수정하면서 합계가 달라지거나, 방금 조회한 결과가 다시 조회했을 때 달라지는 현상이 생길 수 있습니다. 이처럼 여러 작업이 동시에 실행되는 환경에서는 데이터의 일관성을 어떻게 보장할지가 중요합니다. 트랜잭션은 이러한 문제를 포함해 데이터의 정확성을 보장하기 위한 기본 단위입니다.

같은 조회를 두 번 했는데 결과가 다르면 버그일까요?
격리 수준을 어디에 두었느냐에 따라 정상 동작일 수 있습니다. 무엇까지 허용할지 정하는 것이 격리 수준입니다.

SQL을 공부할 때는 쿼리를 하나씩 순서대로 실행하므로 동시성 문제를 체감하기 어렵습니다. 그런데 실제 서버에서는 같은 쿼리가 동시에 수십 개씩 들어오고, 그중 일부는 같은 행을 건드립니다. 이때 무엇을 어디까지 허용할지 정해 두지 않으면 계산은 전부 맞는데 결과만 틀리는 상황이 생깁니다.

ACID와 WAL

트랜잭션은 하나로 묶여서 전부 성공하거나 전부 취소되어야 하는 작업 단위입니다. 계좌 이체가 출금과 입금 두 개로 나뉘어 있어도 둘 중 하나만 반영되면 안 되는 것과 같습니다. 트랜잭션이 지켜야 하는 네 가지 성질을 앞글자만 따서 ACID라고 합니다.

속성	내용
Atomicity 원자성	모든 작업이 전부 수행되거나 전혀 수행되지 않습니다. 출금과 입금은 둘 다 성공하거나 둘 다 취소됩니다.
Consistency 일관성	트랜잭션 전후로 데이터베이스가 정해진 규칙을 만족하는 상태를 유지합니다.
Isolation 격리성	동시에 실행되는 트랜잭션끼리 서로 간섭하지 않습니다. 이 글의 대부분이 여기에 해당합니다.
Durability 지속성	커밋이 끝난 결과는 장애가 나도 남아 있습니다.

이 중 지속성을 구현하는 방식이 WAL(Write-Ahead Logging)입니다. 이름 그대로 데이터 파일을 수정하기 전에 변경 내용을 로그에 먼저 기록하는 방식입니다.

BEGIN;
  UPDATE account SET balance = balance - 10000 WHERE id = 'A';
  -- 1. WAL 버퍼에 변경 내용을 먼저 기록
  -- 2. 메모리(Shared Buffer)의 페이지를 변경
  -- 3. 디스크 데이터 파일에는 아직 기록 안 함 (dirty page)
  UPDATE account SET balance = balance + 10000 WHERE id = 'B';
COMMIT;
-- COMMIT 로그를 WAL에 기록한 뒤 fsync 로 디스크에 동기화
-- 데이터 파일 반영은 이후 Checkpoint 시점에

커밋 직후 서버가 꺼져도 데이터 파일에는 아직 반영이 안 되어 있을 수 있습니다. 그래도 WAL에는 기록이 남아 있기 때문에, 재기동할 때 로그를 순서대로 재실행해 복구합니다. 커밋되지 않은 트랜잭션은 되돌립니다.

PostgreSQL의 synchronous_commit을 off로 두면 커밋 응답이 빨라지는 대신 장애 시 최대 200ms 분량이 사라질 수 있습니다. 성능과 안전 중 무엇을 택할지 정하는 설정입니다.

동시성에서 생기는 세 가지 현상

격리 수준을 이해하려면 무엇을 막으려는 것인지부터 봐야 합니다. 트랜잭션이 겹칠 때 생기는 대표적인 이상 현상이 세 가지입니다.

Dirty Read

아직 커밋되지 않은 값을 읽었기 때문에, 상대가 롤백하면 존재한 적 없는 값을 읽게 됩니다.

Non-Repeatable Read

같은 행을 두 번 읽었는데 값이 달라집니다. 그 사이 다른 트랜잭션이 UPDATE·DELETE 했기 때문입니다.

Phantom Read

같은 조건으로 두 번 조회했을 때 행의 개수가 달라집니다. 그 사이 조건에 맞는 행이 INSERT 됐기 때문입니다.

Non-Repeatable Read와 Phantom Read를 헷갈리기 쉽습니다. 값이 변한 것이 Non-Repeatable Read, 조건에 맞는 행의 개수가 변한 것이 Phantom Read입니다. 실제로 세션 두 개를 띄워 보면 차이가 분명해집니다.

-- Session 1
BEGIN;
SELECT COUNT(*) FROM orders WHERE amount >= 100;   -- 결과: 5

-- Session 2 (동시에)
BEGIN;
INSERT INTO orders(id, amount) VALUES (999, 150);
COMMIT;

-- Session 1 에서 같은 쿼리를 한 번 더
SELECT COUNT(*) FROM orders WHERE amount >= 100;   -- 결과는?

Read Committed: 5에서 6으로 늘어납니다. 팬텀이 발생합니다.
Repeatable Read: 5로 유지됩니다. 같은 트랜잭션 안에서는 같은 스냅샷을 보기 때문입니다.
Serializable: Session 2의 INSERT가 대기하거나 충돌로 롤백되어 팬텀 자체가 생기지 않습니다.

격리 수준 네 단계

격리 수준은 위의 세 현상 중 무엇까지 허용할지 정하는 설정입니다. 엄격해질수록 정확해지고 느려집니다.

격리 수준	Dirty Read	Non-Repeatable	Phantom	기본값인 DBMS
Read Uncommitted	허용	허용	허용	거의 쓰지 않음
Read Committed	차단	허용	허용	PostgreSQL, Oracle, SQL Server
Repeatable Read	차단	차단	원칙적 허용	MySQL(InnoDB)
Serializable	차단	차단	차단	성능 저하 주의

표에서 Repeatable Read의 Phantom이 "원칙적 허용"인 이유가 있습니다. ANSI 표준은 허용한다고 정의했지만 실제 DBMS는 구현에 따라 막습니다. 표준만 외우고 있으면 실제 동작과 어긋나기 때문에, 쓰는 DBMS의 구현을 확인해야 합니다.

DBMS	기본값	구현 방식
PostgreSQL	Read Committed	MVCC. Repeatable Read는 스냅샷 격리라 같은 트랜잭션 안에서 새 행을 보지 않습니다. 완전한 직렬성이 필요하면 Serializable(SSI)을 쓰고, 충돌 시 롤백됩니다.
MySQL InnoDB	Repeatable Read	일반 SELECT는 같은 스냅샷을 보므로 팬텀이 사실상 없습니다. 다만 `FOR UPDATE`나 범위 UPDATE·DELETE에서는 next-key lock으로 막아서 대기가 늘어날 수 있습니다.
Oracle	Read Committed	MVCC로 문장 단위 일관성을 줍니다. Serializable은 충돌 시 `ORA-08177`이 나므로 재시도가 필요합니다.
SQL Server	Read Committed (락 기반)	`READ_COMMITTED_SNAPSHOT`을 켜면 행 버전을 읽습니다. Serializable은 범위 잠금으로 팬텀을 막습니다.

MVCC

PostgreSQL과 MySQL InnoDB, Oracle이 공통으로 쓰는 방식이 MVCC(Multi-Version Concurrency Control)입니다. 값을 덮어쓰지 않고 새 버전을 하나 더 만드는 방식이라고 보면 됩니다.

덮어쓰지 않기 때문에 이전 버전이 그대로 남아 있고, 읽는 쪽은 자기 트랜잭션이 시작될 때의 버전을 봅니다. 그래서 읽기가 쓰기를 막지 않고, 쓰기가 읽기를 막지 않습니다. 조회 쿼리가 UPDATE를 기다리며 멈추는 일이 없는 이유가 여기 있습니다.

UPDATE 는 값을 고치지 않고 새 버전을 추가합니다

구버전 (dead tuple 이 됨)

stock = 10
xmin=100   xmax=205

→

신버전 (지금 보이는 값)

stock = 9
xmin=205   xmax=

xmin 은 이 행을 만든 트랜잭션 번호, xmax 는 이 행을 지우거나 고친 트랜잭션 번호입니다. 트랜잭션 번호 150번이 지금 조회하면 xmax=205 가 아직 자기보다 뒤이므로 구버전인 stock = 10 을 봅니다.

남은 구버전을 dead tuple이라고 하고, VACUUM이 주기적으로 회수합니다. 여기서 실무에서 자주 겪는 문제가 나옵니다.

오래 열려 있는 트랜잭션 하나가 테이블을 부풀립니다. VACUUM은 어떤 트랜잭션도 더 이상 보지 않는 구버전만 지울 수 있습니다. 트랜잭션 하나가 몇 시간째 열려 있으면 그동안 쌓인 구버전을 전부 지우지 못하고 테이블이 계속 커집니다. 트랜잭션을 열어 둔 채로 외부 API를 호출하거나 파일을 읽지 않아야 하는 이유가 여기 있습니다.

MySQL InnoDB는 구버전을 테이블이 아니라 별도의 Undo Log에 두고 Purge Thread가 정리합니다. 구현은 다르지만 버전을 저장하는 공간이 늘어나고, 긴 트랜잭션이 정리를 막는다는 비용은 같습니다.

여기까지가 읽기와 쓰기 사이의 충돌입니다. MVCC가 이 부분을 없애 줍니다. 남는 것은 쓰기끼리의 충돌인데, 같은 행을 두 트랜잭션이 동시에 고치려는 상황은 버전을 늘리는 것으로 해결되지 않습니다. 이쪽은 Lock으로 다루고, 분량이 있어서 Lock과 데드락에서 따로 정리했습니다.

정리하면

작업 성격별로 어떤 격리 수준을 쓰는지 정리해보겠습니다.

작업	권장 격리 수준	확인할 것
단순 조회, 캐시 워밍업	Read Committed	읽는 값이 조금 달라져도 되는지
보고서, 반복 집계	Repeatable Read	Phantom이 결과를 바꾸는지
계좌 이체, 재고 차감	Serializable	성능 저하와 충돌 재시도를 감당할 수 있는지
장바구니, 좌석 예약	Serializable	충돌 시 재시도할 준비가 되어 있는지

격리 수준을 높이면 정확해지고 처리량이 떨어집니다. 전부 Serializable로 두면 값은 안 틀리지만 충돌과 재시도가 늘어납니다.
표준과 실제 구현이 다릅니다. ANSI 표준은 Repeatable Read에서 Phantom을 허용하는데, PostgreSQL과 InnoDB는 스냅샷으로 실질적으로 막습니다.
MVCC 덕분에 읽기와 쓰기가 서로를 막지 않습니다. 대신 구버전이 쌓이므로 긴 트랜잭션이 테이블을 부풀립니다.
WAL은 로그를 데이터 파일보다 먼저 씁니다. 커밋 직후 서버가 꺼져도 로그를 재실행해 복구할 수 있는 이유입니다.

한 줄 정리: 트랜잭션이 겹치면 Dirty · Non-Repeatable · Phantom 세 가지가 생기고 → 격리 수준으로 어디까지 허용할지 정하며 → MVCC가 버전을 여러 개 두어 읽기 충돌을 없앱니다. 남은 쓰기 충돌은 Lock의 몫입니다.

참고

PostgreSQL: Transaction Isolation
PostgreSQL: Concurrency Control (MVCC)
PostgreSQL: Write-Ahead Logging (WAL)
MySQL: InnoDB Transaction Isolation Levels

PostgreSQL 쿼리 튜닝 | EXPLAIN ANALYZE, Buffers, Nested Loop·Hash·Merge

boradora — Tue, 4 Aug 2026 09:04:37 +0900

작업일2026. 07

EXPLAIN ANALYZE 실행계획 Seq Scan 복합 인덱스 Hash Join Materialized View 안티패턴 pg_stat_statements

인덱스를 걸었는데도 쿼리가 그대로 느릴 때가 있습니다. 인덱스가 없어서가 아니라 만들어 둔 인덱스를 쿼리가 안 타서 생기는 일입니다. 탔는지 안 탔는지는 추측할 필요 없이 실행계획에 그대로 적혀 있습니다.

이 쿼리가 왜 느린지 어떻게 알 수 있을까요?
실행계획에서 버려진 행의 개수를 먼저 확인합니다. 5만 행을 읽어 4만 행을 버리고 있다면 대부분의 비용이 불필요한 행을 읽는 데 사용되고 있는 것입니다.

느린 쿼리를 고치는 순서는 정해져 있습니다. 어떤 쿼리가 느린지 찾고, 실행계획으로 왜 느린지 확인하고, 원인에 맞는 방법으로 고칩니다. 실행 계획을 확인하지 않고 인덱스를 추가하면 쓰기 비용만 증가하고 실행 계획은 그대로인 경우가 있습니다.

실행계획

실행계획은 옵티마이저가 쿼리를 실행하기 전에 정한 실행 방법입니다. 어떤 순서로 테이블을 읽을지, 어떤 인덱스를 쓸지, 어떤 조인 방식을 택할지가 여기 적혀 있습니다.

명령	하는 일	주의
`EXPLAIN`	추정 계획만 보여줍니다. 쿼리를 실행하지 않습니다	추정값이라 실제와 다를 수 있습니다
`EXPLAIN ANALYZE`	실제로 실행하고 걸린 시간과 행 수를 측정합니다	DML이면 실제로 반영됩니다
`EXPLAIN (ANALYZE, BUFFERS)`	메모리에서 읽었는지 디스크에서 읽었는지까지 보여줍니다	캐시 히트율을 볼 때 씁니다

EXPLAIN ANALYZE는 쿼리를 진짜로 실행합니다. UPDATE나 DELETE에 붙이면 데이터가 실제로 바뀝니다. DML을 측정할 때는 트랜잭션으로 감싸고 마지막에 롤백합니다.

BEGIN;
EXPLAIN ANALYZE UPDATE orders SET status = 'DONE' WHERE id = 1;
ROLLBACK;                -- 측정만 하고 되돌립니다

플랜을 읽는 방향

플랜은 트리입니다. -> 로 들여쓴 줄이 자식이고, 자식이 먼저 실행됩니다. 그래서 가장 깊이 들여쓴 줄부터 위로 올라가며 읽습니다.

실행 순서는 아래에서 위로, 결과는 위로 전달됩니다

④ Limit  100개만 반환

③ Sort  salary 내림차순

② Hash Join  departments · jobs 를 붙임

① Seq Scan on employees  여기가 문제입니다

한 줄에 들어 있는 것

모든 노드는 같은 형식을 씁니다. 괄호가 두 개인데 앞은 예측, 뒤는 실측입니다.

Limit  (cost=2386.77..2387.02 rows=100 width=30)
       (actual time=28.278..28.296 rows=100 loops=1)

값	뜻	어떻게 보나
`cost=A..B`	A는 첫 행이 나올 때까지, B는 전부 끝날 때까지의 추정 비용	단위가 시간이 아니라 상대적인 값입니다. 플랜끼리 비교할 때만 씁니다
`rows` (앞)	몇 행이 나올지 추정	뒤의 실제 `rows`와 비교합니다
`width`	행 하나의 평균 바이트	`SELECT *`로 바꾸면 이 값이 커집니다
`actual time=A..B`	실제로 걸린 밀리초	여기가 실측값입니다. 어느 노드에서 시간이 뛰는지 봅니다
`rows` (뒤)	실제로 나온 행 수	추정과 몇 배 이상 벌어지면 `ANALYZE`가 필요합니다
`loops`	이 노드가 반복 실행된 횟수	1이 아니면 시간을 곱해야 합니다. Nested Loop 안쪽에서 커집니다

loops를 놓치면 시간을 잘못 읽습니다. actual time은 1회 실행분입니다. actual time=0.5..0.8 loops=3000 이라면 실제로 쓴 시간은 0.8ms가 아니라 2,400ms입니다.

실제 사례로 읽어보기

입사 1년 이내의 재직자를 연봉순 상위 100명 뽑는 쿼리입니다. 직원 테이블에 5만 행이 있고, 부서와 직무 테이블을 붙여서 조회합니다.

SELECT e.employee_id, e.salary, d.department_name, j.job_title
  FROM employees e
  JOIN departments d ON d.department_id = e.department_id
  JOIN jobs        j ON j.job_id = e.job_id
 WHERE e.status = 'ACTIVE'
   AND e.hire_date >= CURRENT_DATE - INTERVAL '365 days'
 ORDER BY e.salary DESC
 LIMIT 100;

튜닝 전

[여기에 스크린샷 : q4_v1_before.png]

맨 아래 줄부터 올라가며 읽습니다. 가장 깊은 곳에 이 줄이 있습니다.

->  Seq Scan on employees e  (cost=0.00..1960.00 rows=9551 width=24)
                             (actual time=0.018..21.028 rows=9567 loops=1)
      Filter: ((status = 'ACTIVE'::text)
               AND (hire_date >= (CURRENT_DATE - '365 days'::interval)))
      Rows Removed by Filter: 40433
      Buffers: shared hit=960

여기서 세 가지가 보입니다.

Seq Scan입니다. 인덱스를 안 타고 employees 테이블을 처음부터 끝까지 읽었습니다.
Rows Removed by Filter: 40433. 조건에 안 맞아서 버린 행이 4만 433개입니다. 통과한 것은 9,567개입니다. 5만 행을 읽어 5분의 1만 남았습니다.
이 노드에서 21.028ms를 썼습니다. 전체가 28.353ms이니 전체 실행 시간의 대부분이 이 노드에서 소비됩니다.

Rows Removed by Filter가 크면 조건 컬럼에 인덱스를 적용할 수 있는지 확인합니다. 이 값은 읽었지만 조건을 만족하지 않아 필터 단계에서 제거된 행 수입니다. 통과한 행보다 버린 행이 훨씬 많다면, 애초에 그 행들을 읽지 않을 방법이 있다는 뜻입니다.

나머지 줄도 확인합니다. 위로 올라가면 Hash Join이 두 겹 있습니다.

->  Hash Join  (cost=8.40..2021.74 rows=9551 width=30)
               (actual time=0.223..26.226 rows=9567 loops=1)
      Hash Cond: (e.job_id = j.job_id)
...
->  Hash  (cost=4.00..4.00 rows=200 width=12)
      Buckets: 1024  Batches: 1  Memory Usage: 17kB
      ->  Seq Scan on departments d  (rows=200)

departments가 200행, jobs가 40행입니다. 이 정도로 작은 테이블은 Seq Scan이 비용이 가장 낮게 계산되는 경우가 많습니다. 전부 메모리에 올려 해시 테이블을 만드는 편이 인덱스를 타는 것보다 빠릅니다. Batches: 1이니 메모리에 다 들어갔고, 디스크로 넘치지도 않았습니다.

Seq Scan이 있다고 무조건 나쁜 것은 아닙니다. 작은 테이블이거나 전체의 상당 부분을 읽어야 하는 쿼리라면 순차 읽기가 더 빠릅니다. 문제가 되는 것은 읽은 행 대부분이Filter 단계에서 제거되는경우입니다.

무엇을 걸어야 하나

WHERE 조건이 status와 hire_date 두 개이고 AND로 묶여 있습니다. AND 조건이니 복합 인덱스가 맞습니다. 여기에 ORDER BY e.salary까지 있으니 salary도 인덱스에 포함시킵니다.

CREATE INDEX idx_emp_hire_status_salary
    ON employees (hire_date, status, salary);

ANALYZE employees;   -- 통계를 갱신해야 플래너가 새 인덱스를 고려합니다

복합 인덱스는 등호 조건을 앞에, 범위 조건을 뒤에 둡니다. status = 'ACTIVE'가 등호, hire_date >=가 범위이니 원칙대로면 (status, hire_date) 순입니다. 다만 status는 값 종류가 적어 선택도가 낮고, 이 데이터에서는 날짜로 좁히는 폭이 더 컸습니다. 순서 원칙은 출발점이고, 최종 판단은 두 순서를 다 만들어 실행계획을 비교하는 것입니다.

튜닝 후

[여기에 스크린샷 : q4_v1_after.png]

같은 쿼리를 한 글자도 고치지 않았는데 플랜이 달라졌습니다. 가장 깊은 곳이 이렇게 바뀌었습니다.

->  Bitmap Heap Scan on employees e  (cost=262.55..1412.09 rows=9477 width=24)
      Recheck Cond: ((hire_date >= (CURRENT_DATE - '365 days'::interval))
                     AND (status = 'ACTIVE'))
      Heap Blocks: exact=907
      Buffers: shared hit=948
      ->  Bitmap Index Scan on idx_emp_hire_status_salary
            (cost=0.00..260.19 rows=9477)
            Index Cond: ((hire_date >= ...) AND (status = 'ACTIVE'))
            Buffers: shared hit=41

바뀐 점을 하나씩 짚어보겠습니다.

Seq Scan이 Bitmap Heap Scan으로 바뀌었습니다. 인덱스로 읽을 행의 위치를 먼저 찾고, 그 위치만 테이블에서 읽습니다.
Rows Removed by Filter가 사라졌습니다. 조건에 맞는 행만 인덱스로 찾아 접근하므로 불필요한 행을 읽지 않습니다.
Filter가 Recheck Cond로 바뀌었습니다. 비트맵이 페이지 단위로 뭉개질 수 있어서 읽은 뒤 조건을 한 번 더 확인합니다. Heap Blocks: exact=907은 뭉개진 부분 없이 정확히 기록됐다는 뜻입니다.
인덱스를 읽는 데 41 페이지를 읽어 접근할 힙 블록을 결정했습니다. 이것으로 테이블에서 읽을 907 블록을 정했습니다.

항목	튜닝 전	튜닝 후
employees 접근 방식	`Seq Scan`	`Bitmap Heap Scan`
버린 행	40,433	0
해당 노드 소요	21.028 ms	인덱스 스캔 포함해 크게 감소
Buffers (전체)	shared hit=963	shared hit=951
Execution Time	28.353 ms	17.633 ms

28.353ms에서 17.633ms로 약 38% 줄었습니다.

남아 있는 것

여기서 짚고 갈 것이 있습니다. Sort 노드는 그대로 남아 있습니다.

->  Sort  (cost=1835.61..1859.30 rows=9477 width=30)
          (actual time=17.545..17.560 rows=100 loops=1)
      Sort Key: e.salary DESC
      Sort Method: top-N heapsort  Memory: 36kB

인덱스에 salary를 넣었는데도 정렬이 사라지지 않았습니다. 이유는 선두 컬럼에 범위 조건이 사용되면 인덱스 순서만으로 전체 정렬 순서를 보장할 수 없기때문입니다.

(hire_date, status, salary) 순서에서 hire_date에 걸린 조건이 >= 입니다. 등호가 아니라 범위이므로 여러 날짜 구간이 결과에 포함되고, 각 구간 안에서만 salary가 정렬돼 있습니다. 구간을 넘나들면 순서가 이어지지 않으니 인덱스가 전체 정렬 순서를 보장하지 못합니다. 그래서 데이터베이스는 별도의 Sort를 붙입니다.

복합 인덱스에서 범위 조건 뒤의 컬럼은 정렬에 쓸 수 없습니다. 앞에서 "등호를 앞에, 범위를 뒤에" 두라고 한 규칙이 여기서 한 번 더 나옵니다. ORDER BY까지 인덱스로 해결하려면 정렬 컬럼을 선두로 올려야 합니다.

실제로 인덱스를 이렇게 바꾸면 Sort 노드가 사라집니다.

-- 정렬 컬럼을 선두로, 값 종류가 적은 status 는 부분 인덱스 조건으로
CREATE INDEX idx_emp_salary_hire
    ON employees (salary DESC, hire_date)
 WHERE status = 'ACTIVE';

status는 값이 두 종류뿐이라 인덱스 컬럼으로 두면 좁혀지는 폭이 작습니다. WHERE 절로 옮겨 부분 인덱스로 만들면 인덱스 크기도 줄고, 선두 자리를 정렬 컬럼에 쓸 수 있습니다. 이 구성에서는 Sort가 완전히 없어지고 약 30배까지 빨라졌습니다.

앞의 Sort Method가 top-N heapsort였던 덕에 그나마 부담이 작았습니다. LIMIT 100이 있어 9,477개를 전부 정렬하지 않고 상위 100개만 유지했고, 메모리도 36kB만 썼습니다. LIMIT이 없었다면 훨씬 무거워집니다.

`Sort Method`	뜻	판단
`top-N heapsort`	`LIMIT`이 있어 상위 N개만 유지	좋습니다. 전체 정렬을 피했습니다
`quicksort`	메모리 안에서 전체 정렬	괜찮습니다
`external merge Disk: ...`	메모리가 부족해 디스크에서 정렬	느립니다. `work_mem`을 올리거나 정렬을 없애야 합니다

Buffers 읽기

BUFFERS 옵션을 붙이면 각 노드가 몇 페이지를 어디서 읽었는지 나옵니다. 페이지 하나는 기본 8kB입니다.

표기	뜻	판단
`shared hit`	메모리 캐시에서 읽음	빠릅니다. 이 비율이 높아야 합니다
`shared read`	디스크에서 읽음	느립니다. 반복 실행해도 크면 캐시가 부족한 것입니다
`temp read / written`	임시 파일 사용	정렬이나 해시가 메모리에 안 들어갔다는 뜻입니다

위 사례는 튜닝 전후 모두 hit만 있고 read가 없습니다. 데이터가 이미 캐시에 다 올라와 있었다는 뜻입니다. 측정할 때는 두 번 이상 돌려 캐시가 채워진 뒤의 값을 보는 편이 실제 운영 상황에 가깝습니다.

노드 타입

플랜에 나오는 노드 이름만 알아도 어디가 문제인지 좁혀집니다.

노드	의미	판단	조치
`Index Only Scan`	인덱스만으로 처리. 테이블 접근 없음	가장 좋음	커버링 인덱스가 걸린 상태
`Index Scan`	인덱스로 찾고 테이블에서 나머지를 읽음	좋음	인덱스 순서가 유지됩니다
`Bitmap Heap Scan`	비트맵을 만든 뒤 블록 순서로 접근	양호	대상 행이 많을 때 유리. 정렬은 유지되지 않습니다
`Seq Scan`	테이블 전체를 순차로 읽음	경우에 따라	작은 테이블이면 정상. `Rows Removed by Filter`가 크면 인덱스 검토
`Hash Join`	해시 테이블을 만들어 조인	대용량에 적합	`Batches`가 1보다 크면 디스크로 넘친 것
`Nested Loop`	바깥 행마다 안쪽을 반복 탐색	소규모에 적합	`loops`가 커지면 급격히 느려집니다
`Merge Join`	양쪽을 조인 키로 정렬한 뒤 맞물려 병합	정렬돼 있을 때만	아래에 `Sort`가 붙으면 Hash Join보다 불리합니다
`Sort`	결과를 정렬	확인 필요	`Index Scan`으로 순서를 얻으면 없앨 수 있습니다

조인 방식 세 가지

옵티마이저는 조인 방식도 비용으로 고릅니다. SQL을 한 글자도 안 바꿔도 양쪽 입력의 행 수, 조인 키 인덱스 유무, work_mem 크기, 통계 정확도에 따라 Nested Loop · Hash Join · Merge Join 중 다른 것이 선택됩니다. 플랜에 찍힌 조인 노드가 왜 그것인지 알아야 Batches나 loops 같은 숫자를 읽을 수 있습니다.

구분	Nested Loop	Hash Join	Merge Join
동작	바깥(outer) 행 하나마다 안쪽(inner)을 반복 탐색	작은 쪽으로 해시 테이블을 만들고(build) 큰 쪽을 흘리며 대조(probe)	양쪽을 조인 키로 정렬한 뒤 지퍼처럼 맞물려 병합
비용	O(N × M). inner 조인 키에 인덱스가 있으면 N × log M	O(N + M). 해시 테이블 생성 비용이 한 번	정렬돼 있으면 O(N + M), 아니면 정렬 비용 추가
유리할 때	outer 결과가 아주 적고 inner 조인 키에 인덱스가 있을 때	양쪽이 다 크고 등가(=) 조인이며 해시가 메모리에 들어갈 때	양쪽이 크고 조인 키로 이미 정렬(인덱스 순서)돼 있을 때
불리할 때	outer 행 수가 늘면 반복 횟수가 그대로 곱해집니다	`work_mem`이 부족하면 배치가 쪼개져 디스크로 넘칩니다	정렬 결과가 메모리를 넘기면 디스크 정렬로 떨어집니다
가능한 조건	등가 · 비등가 · 범위 조인 전부	등가(=) 조인만	등가 및 범위 비교 (정렬 순서 필요)
플랜 표기	`Nested Loop` 아래 `loops=N`인 Index Scan	`Hash Join` + `Hash (Buckets/Batches/Memory Usage)`	`Merge Join` + 양쪽 `Sort` 또는 Index Scan
튜닝 지점	outer를 줄이는 필터, inner 조인 키 인덱스	`work_mem`을 올려 `Batches: 1` 유지	조인 키 인덱스로 `Sort` 노드 자체를 제거

세 방식을 강제로 바꿔가며 같은 쿼리를 측정해보면 숫자가 이렇게 갈립니다. 주문 9,590건과 주문상품 28,815건을 조인해 매출을 합산하는 쿼리이고, enable_hashjoin·enable_mergejoin·enable_nestloop를 꺼서 방식을 지정했습니다.

SET enable_hashjoin = off;
SET enable_mergejoin = off;     -- 둘 다 끄면 Nested Loop 만 남습니다
EXPLAIN (ANALYZE, BUFFERS) SELECT ...;
RESET enable_hashjoin; RESET enable_mergejoin;

조인 방식	Execution Time	Buffers (hit)
Hash Join (옵티마이저 기본 선택)	6.1 ms	291
Nested Loop 강제	3.7 ms	3,758
Merge Join 강제	5.6 ms	348

Nested Loop가 시간은 제일 짧은데 Buffers는 12.9배입니다. 이 데이터는 전부 shared_buffers에 올라와 있어서 페이지를 3,758번 읽어도 전부 메모리 적중이라 빨라 보입니다. 디스크를 읽는 환경이었다면 그 반복 액세스가 그대로 랜덤 I/O 비용이 됩니다. 실행 시간만으로 조인 방식을 비교하면
메모리 캐시의 영향을 구분할 수 없습니다.가 이 표에 그대로 나옵니다.

옵티마이저가 Hash Join을 고른 것은 실행시간이 아니라 읽을 페이지 수를 기준으로 계산했기 때문입니다. 플랜에서 조인 노드를 볼 때 확인할 것은 방식 이름이 아니라 그 아래 붙은 숫자입니다. Nested Loop면 loops, Hash Join이면 Batches와 Memory Usage, Merge Join이면 Sort 노드의 유무입니다.

인덱스를 무력화하는 패턴

위 사례는 인덱스가 없어서 안 탄 경우였습니다. 그런데 인덱스가 있는데도 안 타는 경우가 더 자주 생깁니다. 인덱스는 컬럼의 값이 그대로 있을 때만 쓸 수 있습니다.

컬럼에 함수를 씌우는 경우

-- 인덱스를 못 씁니다 : 컬럼에 함수를 적용했습니다
WHERE YEAR(created_at) = 2026

-- 인덱스를 씁니다 : 컬럼은 그대로 두고 범위로 바꿉니다
WHERE created_at >= '2026-01-01'
  AND created_at <  '2027-01-01'

대소문자를 무시한 비교처럼 함수를 꼭 써야 하는 경우도 있습니다. 그때는 쿼리를 고치는 대신 함수를 적용한 결과에 인덱스를 겁니다.

CREATE INDEX idx_users_email_lower ON users (LOWER(email));
SELECT * FROM users WHERE LOWER(email) = 'a@b.com';   -- 인덱스 사용

타입이 다른 값을 비교하는 경우

user_id가 INT인데 문자열로 비교하면, 데이터베이스가 컬럼 쪽을 변환하면서 인덱스를 못 씁니다. 따옴표 하나 때문에 전체 스캔이 일어납니다.

WHERE user_id = '12345'    -- 타입 변환이 일어나 인덱스를 못 씁니다
WHERE user_id = 12345      -- 인덱스를 씁니다

LIKE 앞에 와일드카드가 붙는 경우

B-Tree 인덱스는 앞에서부터 정렬돼 있어서 앞부분이 정해져야 범위를 좁힐 수 있습니다. 앞에 %가 붙으면 시작점을 정할 수 없어 전부 읽습니다.

WHERE name LIKE '%길동%'    -- B-Tree 인덱스 사용 불가
WHERE name LIKE '홍%'       -- 앞이 고정이라 인덱스 사용 가능

중간 검색이 꼭 필요하면 pg_trgm 확장에 GIN 인덱스를 씁니다. 문자열을 세 글자 단위로 쪼개 색인하기 때문에 가운데 검색에도 인덱스가 걸립니다.

CREATE EXTENSION pg_trgm;
CREATE INDEX idx_name_trgm ON users USING GIN (name gin_trgm_ops);

SELECT * FROM users WHERE name LIKE '%길동%';   -- 이제 인덱스를 씁니다

앞이 고정된 LIKE인데도 인덱스를 안 타는 경우가 있습니다. text 컬럼의 기본 B-Tree 인덱스는 데이터베이스 로케일이 C가 아니면 LIKE에 쓰이지 않습니다. 로케일에 따라 문자 정렬 순서가 달라져서 인덱스 순서와 LIKE가 기대하는 순서가 어긋나기 때문입니다. en_US.UTF-8 환경에서 실제로 겪었고, text_pattern_ops를 지정해 해결했습니다.

-- 로케일과 무관하게 LIKE 접두사 검색에 쓰이는 인덱스
CREATE INDEX idx_emp_email_pattern
    ON employees (lower(email) text_pattern_ops);

SELECT * FROM employees WHERE lower(email) LIKE 'user123%';

인덱스를 만들었는데 플랜이 그대로라면 opclass와 로케일을 확인해봐야 합니다. SHOW lc_collate; 로 현재 로케일을 볼 수 있습니다.

OR 조건에 복합 인덱스를 거는 경우

위 사례는 AND였기 때문에 복합 인덱스가 맞았습니다. OR은 반대입니다.

WHERE department_id = 10
   OR job_id IN (3, 4, 5)

(department_id, job_id) 복합 인덱스는 앞 컬럼으로 좁힌 뒤 그 안에서 뒤 컬럼을 보는 구조입니다. OR은 둘 중 하나만 맞아도 되니 앞 컬럼으로 좁히는 것 자체가 성립하지 않습니다. 각 컬럼에 단일 인덱스를 따로 만들면 플래너가 두 인덱스를 각각 탐색한 뒤 BitmapOr로 합칩니다.

CREATE INDEX idx_emp_department_id ON employees (department_id);
CREATE INDEX idx_emp_job_id        ON employees (job_id);
ANALYZE employees;

-- 플랜에 이렇게 나옵니다
-- Bitmap Heap Scan on employees
--   ->  BitmapOr
--         ->  Bitmap Index Scan on idx_emp_department_id
--         ->  Bitmap Index Scan on idx_emp_job_id

정리하면 AND는 복합 인덱스 하나, OR는 단일 인덱스 여러 개입니다.

OR를 UNION ALL로 바꾸는 재작성은 결과를 틀리게 만들 수 있습니다. 두 조건을 각각 조회해 이어 붙이면 양쪽 조건에 모두 걸리는 행이 두 번 세어집니다. 같은 데이터에서 실제로 19건이 중복 집계됐습니다. 성능 문제가 아니라 정확성 문제입니다. UNION으로 바꿔 중복을 제거할 수는 있지만, 인덱스만 갖추면 원본 OR가 알아서 BitmapOr로 처리되므로 재작성 자체가 필요하지 않습니다.

쿼리 구조에서 생기는 문제

SELECT *

필요 없는 컬럼까지 전부 가져오면 네트워크로 오가는 양이 늘어납니다. 그리고 커버링 인덱스를 쓸 수 없게 됩니다. 인덱스에 없는 컬럼을 하나라도 요구하면 테이블에 접근해야 하기 때문입니다.

SELECT * FROM users WHERE email = 'a@b.com';        -- 테이블 접근 발생
SELECT id, name FROM users WHERE email = 'a@b.com'; -- Index Only Scan 가능

NOT IN 과 NULL

NOT IN의 목록에 NULL이 하나라도 있으면 결과가 항상 비어 있습니다. NULL과의 비교 결과가 참도 거짓도 아닌 UNKNOWN이라, 조건 전체가 참이 되지 못하기 때문입니다. 에러가 안 나고 조용히 빈 결과만 나오기 때문에 원인을 찾기 어렵습니다.

-- customer_id 에 NULL 이 하나라도 있으면 결과가 항상 0건
SELECT * FROM users
 WHERE id NOT IN (SELECT customer_id FROM orders);

-- NOT EXISTS 는 NULL 이 있어도 정상 동작하고 대체로 더 빠릅니다
SELECT * FROM users u
 WHERE NOT EXISTS (SELECT 1 FROM orders o WHERE o.customer_id = u.id);

DISTINCT 남용

결과에 중복이 보인다고 DISTINCT를 붙이면 중복이 왜 생겼는지를 덮어버립니다. 대부분 JOIN 때문에 행이 불어난 것이고, 존재 여부만 확인하면 되는 경우라면 EXISTS가 맞습니다.

-- 중복 원인을 덮는 방식
SELECT DISTINCT s.name
  FROM students s JOIN enrollments e ON e.student_id = s.id;

-- 존재 여부만 확인 (행이 불어나지 않습니다)
SELECT name FROM students s
 WHERE EXISTS (SELECT 1 FROM enrollments e WHERE e.student_id = s.id);

큰 OFFSET

페이지네이션을 OFFSET으로 구현하면 뒤로 갈수록 느려집니다. 건너뛸 행을 읽고 나서 버리는 방식이라, 10,000페이지를 보려면 100,000행을 읽은 뒤 버립니다.

-- 페이지가 뒤로 갈수록 선형으로 느려집니다
SELECT * FROM orders ORDER BY id LIMIT 10 OFFSET 100000;

-- 마지막으로 본 id 부터 이어 읽습니다 (Keyset / Cursor 방식)
SELECT * FROM orders WHERE id > :last_id ORDER BY id LIMIT 10;

Keyset 방식은 특정 페이지로 바로 건너뛸 수 없다는 제약이 있습니다. 무한 스크롤에는 잘 맞고, 페이지 번호를 눌러 이동하는 화면에는 안 맞습니다.

N+1

목록 100건을 조회한 뒤 각 건마다 상세를 한 번씩 더 조회하면 쿼리가 101번 나갑니다. 개별 쿼리는 전부 빠른데 합치면 느린 형태라, 실행계획만 봐서는 찾기 어렵습니다. 쿼리 개수를 세어 봐야 보입니다. JOIN이나 IN 한 번으로 묶습니다.

실제로 12개를 튜닝해보고 알게 된 것

e커머스 스키마(주문 9,590건 · 주문상품 28,815건 · 고객 3,000건)에 분석 쿼리 12개를 짜고 문항마다 튜닝 전 실행계획 → 병목 지목 → 개선 → 튜닝 후 실행계획 순서로 측정했습니다. 가장 크게 배운 것은 인덱스로 해결되는 쿼리가 절반도 안 된다는 것이었습니다.

먼저 판단 기준부터 정리해야 했습니다. 이 규모는 테이블 전체가 shared_buffers에 올라가서 Seq Scan도 밀리초 안에 끝나고, 같은 쿼리를 두 번 돌려도 실행시간이 ±20% 흔들립니다. 그래서 실행시간은 참고로만 두고 아래 순서로 봤습니다.

순위	볼 것	의미
1	`Buffers: shared hit`	실제로 읽은 페이지 수. 튜닝 효과가 가장 정직하게 찍힙니다
2	스캔 노드 변화	`Seq Scan`이 `Index Only Scan`으로 바뀌었는가
3	`Heap Fetches`	`Index Only Scan`에서 0이면 힙 접근이 완전히 사라진 것
4	`Sort Method` · `Memory`	정렬이 없어졌는가, 정렬 메모리가 줄었는가
5	`Rows Removed by Filter`	읽고 나서 버린 행. 클수록 인덱스가 필요하다는 신호
6	`Execution Time`	참고용. 이것만 보고 결론 내지 않습니다

인덱스가 통한 쿼리

조건에 맞는 행이 전체의 일부일 때는 인덱스가 그대로 먹혔습니다. 부분 인덱스로 인덱스에 담을 행을 미리 걸러 두고, INCLUDE로 함께 읽는 컬럼을 얹어 커버링 인덱스를 만드는 조합입니다.

CREATE INDEX idx_orders_sales_ts
    ON ecom.orders (order_ts)
    INCLUDE (order_id, customer_id, coupon_code)   -- 힙 접근을 없애려고 얹습니다
 WHERE order_status IN ('paid','shipped','delivered');   -- 9,590행 → 7,241행만 색인

ANALYZE ecom.orders;   -- 통계를 갱신해야 옵티마이저가 새 인덱스를 고릅니다

여기서 놓치기 쉬운 것이 하나 있습니다. 쿼리의 WHERE 절을 부분 인덱스 정의와 같은 모양으로 써야 그 인덱스가 선택됩니다. 인덱스에 order_status IN ('paid','shipped','delivered')라고 적어 놓고 쿼리에서는 order_status != 'cancelled'처럼 다르게 쓰면 결과가 같아도 인덱스를 안 탑니다. 옵티마이저가 두 조건이 같다는 것을 증명하지 못하기 때문입니다.

인덱스로 안 되는 쿼리

월별 매출 집계처럼 조건이 order_status 하나뿐이고 대상이 전체의 75%인 쿼리가 있었습니다. 부분 인덱스를 만들고 enable_seqscan = off로 강제해봤더니 Index Scan 쪽이 오히려 느렸습니다. 읽을 양을 못 줄이는데 인덱스를 한 번 더 거치는 비용만 붙기 때문입니다. 선택도가 높으면 Seq Scan이 정답이고, 이때는 쿼리를 고쳐야 합니다.

실제 병목은 count(DISTINCT o.order_id)였습니다. 주문 1건이 주문상품 개수만큼 늘어나니 중복을 제거해야 하는데, DISTINCT가 붙으면 HashAggregate를 못 쓰고 Sort + GroupAggregate로 떨어집니다. 21,768행을 1.6MB 메모리로 정렬하고 있었습니다.

-- 튜닝 전 : 조인 결과를 한 번에 GROUP BY → Sort 1,619kB
SELECT date_trunc('month', o.order_ts)::date AS order_month,
       count(DISTINCT o.order_id) AS order_cnt,
       sum(oi.line_total)         AS revenue
  FROM orders o JOIN order_items oi ON oi.order_id = o.order_id
 WHERE o.order_status IN ('paid','shipped','delivered')
 GROUP BY 1;

-- 튜닝 후 : 주문 단위로 먼저 접고, 월 단위로 한 번 더 접습니다
WITH order_amount AS (
    SELECT o.order_id,
           date_trunc('month', o.order_ts)::date AS order_month,
           sum(oi.line_total) AS amount
      FROM orders o JOIN order_items oi ON oi.order_id = o.order_id
     WHERE o.order_status IN ('paid','shipped','delivered')
     GROUP BY o.order_id, 2          -- 여기서 중복이 사라집니다
)
SELECT order_month, count(*) AS order_cnt, sum(amount) AS revenue
  FROM order_amount
 GROUP BY order_month;               -- count(*) 라 Sort 가 필요 없습니다

count(DISTINCT)가 count(*)로 바뀌면서 Sort 노드가 통째로 사라지고 HashAggregate 두 단계로 처리됐습니다. 지금 규모에서는 31.9ms에서 25.6ms로 20% 정도 줄었을 뿐이지만, 정렬이 work_mem을 넘기면 external merge Disk로 떨어지므로 데이터가 커질수록 격차가 벌어지는 구조입니다.

쿼리를 고쳐서 얻은 것

인덱스 없이 쿼리 구조만 바꿔서 가장 크게 줄어든 것들입니다.

바꾼 것	어떻게	효과
2단계 집계	`count(DISTINCT)`를 주문 단위로 접어 `count(*)`로	`Sort` 1.6MB 소멸
조인 순서	집계·`HAVING`을 먼저 끝내고 마지막에 조인	조인 대상 600행 → 12행, 5.6ms → 0.7ms
자기조인 제거	같은 테이블 두 번 읽기를 `min(...) OVER (PARTITION BY ...)` 윈도우 함수로	198 → 38 buffers (81% 감소)
`IN` → `JOIN`	서브쿼리를 조인으로 바꿔 옵티마이저가 조인 순서를 고르게	31.2ms → 4.3ms
함수 인라인	`LANGUAGE plpgsql` → `LANGUAGE sql IMMUTABLE`	598 → 379 buffers

함수 인라인은 예상 밖이었습니다. 0으로 나눠도 에러가 안 나는 안전 나눗셈 함수를 plpgsql로 만들어 뒀는데, 행마다 함수 호출이 SPI를 거치면서 Buffers가 60% 가까이 늘어나 있었습니다. 본문이 SELECT 한 줄뿐인 함수는 LANGUAGE sql로 선언하면 옵티마이저가 본문을 쿼리 안으로 펼쳐 넣어 호출 자체가 사라집니다.

CREATE OR REPLACE FUNCTION ecom.f_safe_div(numer numeric, denom numeric)
RETURNS numeric
LANGUAGE sql IMMUTABLE PARALLEL SAFE AS $$      -- plpgsql 이 아니라 sql
  SELECT CASE WHEN denom IS NULL OR denom = 0 THEN 0 ELSE numer / denom END;
$$;

튜닝이 안 되는 쿼리도 있습니다

12개 중 2개는 무엇을 해도 숫자가 안 움직였습니다.

재고 임계치 미달 조회: WHERE qty_on_hand < reorder_point처럼 컬럼끼리 비교하는 조건은 일반 B-Tree 인덱스로는 처리할 수 없습니다. 비교 대상이 상수값이 아니라 두 컬럼의 값이라 인덱스로 탐색 범위를 만들 수 없기 때문입니다. 이 조건을 그대로
WHERE 절에 넣은 부분 인덱스를 만드는 방법이 있지만, 테이블이 600행뿐이라 옵티마이저는 Seq Scan을 선택했습니다. 값이 아니라 두 컬럼의 관계라서 색인할 키가 없기 때문입니다.
쿠폰 사용 영향 분석: 전체 주문을 다 집계하는 쿼리라 읽을 양을 줄일 방법이 없었습니다. 인덱스도 재작성도 안 통하는 유형이고, 여기서부터는 미리 계산해 두는 것 말고 답이 없습니다.

마지막 문항이 그 답이었습니다. 일자별 매출을 조회할 때마다 조인하고 집계하는 대신 Materialized View로 결과를 저장해 뒀습니다. 조회 쪽 플랜에서 Hash Join과 HashAggregate가 통째로 없어지고 3.6ms · 379 buffers가 0.06ms · 4 buffers로 바뀌었습니다. 12개 중 개선 폭이 가장 컸습니다.

CREATE MATERIALIZED VIEW ecom.mv_daily_gmv AS
SELECT date_trunc('day', o.order_ts)::date AS sales_day,
       count(DISTINCT o.order_id)          AS order_cnt,
       sum(oi.line_total)                  AS gmv
  FROM ecom.orders o JOIN ecom.order_items oi ON oi.order_id = o.order_id
 WHERE o.order_status IN ('paid','shipped','delivered')
 GROUP BY 1;

-- CONCURRENTLY 갱신을 쓰려면 UNIQUE 인덱스가 반드시 있어야 합니다
CREATE UNIQUE INDEX ux_mv_daily_gmv_day ON ecom.mv_daily_gmv (sales_day);
ANALYZE ecom.mv_daily_gmv;   -- MV 도 테이블이라 통계가 필요합니다

Materialized View는 자동으로 갱신되지 않는 스냅샷입니다. REFRESH를 걸기 전까지 데이터가 그 시점에 멈춰 있습니다. REFRESH MATERIALIZED VIEW CONCURRENTLY를 쓰면 갱신 중에도 조회가 안 잠기지만 UNIQUE 인덱스가 없으면 실행 자체가 실패하고, 일반 REFRESH보다 느립니다. 갱신 주기를 정할 때는 지표가 확정되는 단위와 사용자가 언제 보는지를 같이 봅니다. 일자별 매출은 하루 단위로 확정되고 리포트는 오후에 열리므로 매일 15시 1회로 잡았습니다.

12개 결과

쿼리	병목	적용한 개선	실행시간	Buffers
지난 한 달 매출	`Seq Scan` 후 77% 폐기	부분 + 커버링 인덱스	6.7 → 5.0 ms	376 → 291
월별 AOV	`count(DISTINCT)` Sort 1.6MB	2단계 집계	31.9 → 25.6 ms	376 (동일)
카테고리 Top 10	주문상품 전량이 3단 조인 입력	인덱스 재사용 + 필터 CTE 분리	20.4 → 15.6 ms	324 → 327
제품 매출 랭킹	순위 확정 전 600행 전부 조인	집계 → 랭킹 → 상위 20만 조인	18.8 → 17.2 ms	383 (동일)
고객 RFM	`count(DISTINCT)` Sort 1.8MB	2단계 집계	23.8 → 22.7 ms	376 (동일)
30일 내 재구매율	같은 테이블 2회 스캔 + 73% 폐기	윈도우 함수 + 복합 부분 인덱스	15.4 → 5.7 ms	198 → 38
재고 임계치 미달	컬럼 대 컬럼 비교	부분 인덱스 (미선택이 정상)	0.21 → 0.26 ms	12 (동일)
리뷰 효자상품	12행 뽑으려고 600행 조인	집계 · `HAVING` 선행	5.6 → 0.7 ms	28 (동일)
쿠폰 영향 분석	전량 집계	조회 시 계산하는 대신 Materialized View로 미리 집계	18.8 → 19.9 ms	376 (동일)
상위 1% 고객 매출	테이블 2회 읽기 + 정렬 3회	조인 제거 + `IN`→`JOIN`	31.2 → 4.3 ms	752 → 803
안전 나눗셈 함수	`plpgsql` 호출 오버헤드	`LANGUAGE sql` 인라인	소폭 단축	598 → 379
일자별 매출	열 때마다 조인 + 집계	Materialized View	3.6 → 0.06 ms	379 → 4

Buffers가 늘었는데 시간이 줄어든 경우(상위 1% 고객 매출)도 있습니다. 정렬 세 번을 없애는 대신 인덱스 페이지를 더 읽은 것이고, 이때는 시간 쪽이 맞는 판단입니다. 지표 하나를 절대 기준으로 두면 이런 경우를 놓칩니다.

느린 쿼리 찾아내기

위 패턴을 알아도 어떤 쿼리가 느린지부터 알아야 고칠 수 있습니다. PostgreSQL은 pg_stat_statements 확장이 실행된 쿼리의 통계를 모아 줍니다.

SELECT ROUND(mean_exec_time::NUMERIC, 2)  AS avg_ms,
       calls,
       ROUND(total_exec_time::NUMERIC, 0) AS total_ms,
       ROUND(shared_blks_hit::NUMERIC
             / NULLIF(shared_blks_hit + shared_blks_read, 0) * 100, 1) AS cache_hit_pct,
       LEFT(query, 100) AS query_snippet
  FROM pg_stat_statements
 ORDER BY mean_exec_time DESC
 LIMIT 10;

여기서 정렬 기준을 무엇으로 두느냐가 중요합니다.

mean_exec_time: 한 번 실행에 오래 걸리는 쿼리입니다. 개별 화면이 느린 원인입니다.
total_exec_time: 누적으로 서버 시간을 가장 많이 쓴 쿼리입니다. 한 번은 빠른데 초당 수천 번 실행되는 쿼리가 여기서 잡힙니다. 전체 부하를 줄이려면 이쪽부터 봅니다.
cache_hit_pct: 낮으면 디스크를 읽고 있다는 뜻입니다.

튜닝 전후를 비교하려면 통계를 초기화한 뒤 같은 구간을 측정합니다.

SELECT pg_stat_statements_reset();

엔진마다 다른 것

여기까지는 PostgreSQL 기준입니다. 그런데 프로젝트가 바뀌면 MySQL이나 Oracle을 만나고, 같은 SQL인데 플랜이 다르게 나오거나 PostgreSQL에서 쓰던 방법이 아예 없는 경우가 생깁니다. 네 엔진의 옵티마이저가 어디서 갈리는지 정리했습니다.

구분	PostgreSQL	MySQL (InnoDB)	Oracle	SQL Server
통계 수집	`ANALYZE`, autovacuum이 자동 갱신. 기본 100버킷 히스토그램	인덱스 카디널리티 샘플링. 8.0부터 히스토그램	히스토그램 · 확장통계 · 동적 샘플링	자동 생성 · 자동 갱신. 밀도 벡터 + 히스토그램
쓸 수 있는 조인	Nested Loop · Hash · Merge	Merge Join 없음. Hash Join은 8.0.18부터	세 가지 전부, 병렬 실행 지원	세 가지 전부
힌트	공식 힌트 없음. `enable_*` 파라미터나 `pg_hint_plan` 확장	`/+ ... /`, `USE INDEX` / `FORCE INDEX`	`/+ ... /`. 실무에서 널리 사용	`OPTION (...)` 절, Plan Guide
계획 캐시	캐시하지 않고 매번 재계산 (`PREPARE` 시 generic plan)	캐시하지 않음	공유 풀에 캐시. Adaptive Plan으로 실행 중 변경	재사용이 강해 파라미터 스니핑 발생. Query Store로 이력 관리
계획 고정	통계와 인덱스로 유도하는 방법뿐	힌트로 유도	SQL Plan Baseline	Plan Guide · Query Store 강제 계획
실행계획 확인	`EXPLAIN (ANALYZE, BUFFERS)`	`EXPLAIN ANALYZE` (8.0.18+), `EXPLAIN FORMAT=JSON`	`EXPLAIN PLAN` + `DBMS_XPLAN.DISPLAY`	실제 실행 계획(Ctrl+M), `SET STATISTICS IO ON`

네 엔진 모두 비용 기반 옵티마이저(CBO)를 사용합니다. 통계를 바탕으로 각 실행 경로의 비용을 계산해 가장 비용이 낮은 계획을 선택합니다. 따라서 통계가 실제 데이터와 어긋나면 실행계획도 달라질 수 있습니다. 인덱스를 만든 뒤 ANALYZE를 함께 실행하는 이유가 여기에 있습니다.

엔진마다 가장 큰 차이는 실행계획을 얼마나 직접 제어할 수 있는지입니다. Oracle과 SQL Server는 힌트나 Plan Baseline 같은 기능으로 특정 실행계획을 강제로 사용할 수 있습니다. 반면 PostgreSQL은 공식 힌트를 제공하지 않으므로, 인덱스를 만들거나 ANALYZE로 통계를 갱신해 옵티마이저가 원하는 실행계획을 선택하도록 유도하는 방식이 일반적입니다.

앞에서 조인 방식을 비교할 때 사용한 enable_hashjoin = off도 실행계획을 확인하기 위한 실험용 설정입니다. 세션 전체에 적용되는 옵션이라 운영 환경에서 특정 쿼리의 실행계획을 제어하는 용도로 사용하지는 않습니다.

MySQL은 오랫동안 Nested Loop만 있었고 8.0.18에서야 Hash Join이 들어왔습니다. Merge Join은 지금도 없습니다. 이 글의 실습처럼 대량 집계와 조인이 많은 분석 쿼리라면 MySQL에서는 같은 SQL이 Nested Loop로 풀려 반복 액세스가 커질 수 있습니다.

정리하면

느린 쿼리를 만났을 때의 순서입니다.

① 찾기

pg_stat_statements

→

② 원인 보기

EXPLAIN ANALYZE

→

③ 고치기

쿼리 or 인덱스

→

④ 재측정

reset 후 비교

네 단계를 다 돌렸는데도 느리다면 쿼리 문제가 아니라 테이블 크기 문제일 수 있습니다. 그때부터는 파티셔닝으로 읽을 대상을 줄이거나, 읽기 복제본으로 부하를 나누거나, 샤딩까지 가는 선택이 남습니다. 모두 시스템 구조에 영향을 주는 변경이라 실무에서 마주치는 DB 트레이드오프에서 따로 정리했습니다.

플랜에서 볼 곳과 인덱스를 무력화하는 패턴을 정리해보겠습니다.

플랜에서 볼 곳	이상하면
`Seq Scan` + `Rows Removed by Filter`가 큼	그 조건 컬럼에 인덱스 검토
추정 `rows`와 실제 `rows`가 몇 배 차이	`ANALYZE` 실행
`loops`가 1이 아님	`actual time`에 곱해서 실제 시간 계산
`Sort Method: external merge Disk`	`work_mem` 부족
`Hash`의 `Batches`가 1보다 큼	해시가 디스크로 넘친 상태
`Buffers`의 `read`가 큼	디스크를 읽고 있음

안티패턴	문제	고치는 방법
컬럼에 함수 적용	인덱스 무력화	범위 조건으로 바꾸거나 함수 기반 인덱스 생성
`SELECT *`	전송량 증가, 커버링 인덱스 불가	필요한 컬럼만 지정
타입 불일치	암묵적 변환으로 인덱스 무력화	같은 타입으로 비교
`LIKE '%키워드%'`	시작점을 못 정해 전체 스캔	prefix 검색으로 바꾸거나 `pg_trgm` GIN
`OR`에 복합 인덱스	앞 컬럼으로 좁힐 수 없음	단일 인덱스를 각각 만들어 `BitmapOr` 유도
N+1	쿼리 개수가 행 수만큼 늘어남	JOIN이나 `IN`으로 한 번에
`NOT IN` + `NULL`	결과가 항상 비어 있음	`NOT EXISTS`
`DISTINCT` 남용	중복 원인을 덮음	`EXISTS`로 존재 여부만 확인
큰 `OFFSET`	뒤 페이지일수록 느려짐	Keyset(Cursor) 방식

한 줄 정리: 실행계획은 예측과 실측을 나란히 보여주는 표입니다. Rows Removed by Filter가 크거나 추정과 실제 행 수가 크게 벌어진 노드가 문제의 시작점입니다.

참고

PostgreSQL: Using EXPLAIN
PostgreSQL: Combining Multiple Indexes (Bitmap Scan)
PostgreSQL: pg_stat_statements
PostgreSQL: pg_trgm
실행계획 시각화: explain.dalibo.com (FORMAT JSON 결과를 붙여넣으면 트리로 보여줍니다)

SQL JOIN 실수 패턴 | LEFT JOIN과 WHERE, 중복 행, NOT IN NULL, EXISTS

boradora — Mon, 3 Aug 2026 22:54:37 +0900

작업일2026. 07

JOIN LEFT JOIN NULL EXISTS NOT IN

JOIN 문법은 금방 익숙해지는데, 결과 행 수가 예상과 다르게 나오는 일은 계속 생깁니다. 오류가 안 나고 결과만 조용히 틀리기 때문에 찾기도 어렵습니다.

LEFT JOIN을 걸어놓고 WHERE로 조건을 하나 붙였는데, 왜 결과가 줄어들까요?
그 순간 LEFT JOIN이 INNER JOIN으로 바뀌었기 때문입니다.

문법이 틀린 것이 아니라 같은 문법이 다른 결과를 내는 자리가 몇 군데 있습니다. 전부 실행은 잘 되고 오류도 없어서, 알고 있지 않으면 그냥 지나갈 수 밖에 없죠.

ON 절과 WHERE 절

모든 학생을 보여주되 CS101 성적만 함께 보고 싶다고 해보겠습니다. 수강하지 않은 학생도 목록에는 있어야 합니다.

-- 의도와 다른 결과
SELECT s.name, e.score
FROM students s
LEFT JOIN enrollments e ON e.student_id = s.id
WHERE e.course_id = 1;      -- 수강 안 한 학생이 사라집니다

수강하지 않은 학생은 e.course_id가 NULL입니다. 그런데 WHERE는 조인이 끝난 뒤에 행을 거르므로, NULL = 1이 참이 아니라서 그 학생들이 통째로 빠집니다. LEFT JOIN으로 남겨 둔 행이 WHERE 절에서 다시 제거된 것입니다.

-- 의도대로
SELECT s.name, e.score
FROM students s
LEFT JOIN enrollments e
       ON e.student_id = s.id
      AND e.course_id = 1;   -- 조인 조건에 넣습니다

ON에 넣으면 조인하는 과정에서 조건이 적용됩니다. CS101을 안 들은 학생은 짝을 못 찾을 뿐 행은 남고, score만 NULL로 채워집니다.

ON 절에 넣으면

조인하면서 조건을 함께 본다

▼

짝이 없으면 NULL 로 채워 남긴다

LEFT JOIN 이 그대로 유지됩니다

WHERE 절에 넣으면

조인을 먼저 끝낸다

▼

NULL 인 행이 조건에 걸려 지워진다

결과가 INNER JOIN 과 같아집니다

일부러 INNER JOIN 처럼 쓰고 싶을 때는 WHERE 가 맞습니다. OUTER JOIN 결과를 유지하면서 조건을 걸고 싶을 때만 ON 에 넣습니다.

예외가 하나 있습니다. WHERE e.id IS NULL 처럼 짝이 없는 행만 찾는 경우는 WHERE에 두는 것이 맞습니다. 수강한 적 없는 학생만 뽑는 패턴이고, 이걸 Anti-Join 이라고 부릅니다.

결과 행 수 예측

JOIN을 걸기 전에 몇 행이 나올지 먼저 세어보는 습관이 실수를 많이 막아줄 수 있습니다. A가 5행, B가 3행이고 그중 2건이 매칭될 때 종류별로 이렇게 나오게 됩니다.

JOIN 종류	결과 행 수	`NULL`이 들어가는 칸
`INNER JOIN`	2행 (매칭된 것만)	없음
`LEFT JOIN`	5행 (A 전체)	B 컬럼 (3행이 `NULL`)
`RIGHT JOIN`	3행 (B 전체)	A 컬럼
`FULL OUTER JOIN`	6행 (5 + 3 − 2)	양쪽 비매칭 컬럼
`CROSS JOIN`	15행 (5 × 3)	없음
Anti-Join (`NOT EXISTS`)	3행 (5 − 2)	없음

ON 조건을 빠뜨리면 CROSS JOIN이 됩니다. 5행과 3행이면 15행이라 눈에 띄지만, 10만 행과 10만 행이면 100억 행이 됩니다. JOIN 조건이 빠지면 결과 행 수가 기하급수적으로 늘어나 실행 시간이 크게 증가합니다.

1:N 조인의 중복

고치는 방법은 두 가지입니다. 서브쿼리에서 먼저 집계한 뒤 조인하거나, 값이 하나뿐이라면 DISTINCT로 거릅니다. 합계를 계산하는 상황이라면 앞쪽이 맞습니다. DISTINCT는 실제로 같은 금액의 주문이 여러 건일 경우 그것까지 하나로 합쳐 버릴 수 있기 때문입니다.

orders (1건)

주문 101 · 5만원

order_items (3건)

키보드

마우스

모니터

JOIN 결과 (3행)

5만원

여기서 SUM(o.amount) 를 하면 5만원이 아니라 15만원이 나옵니다. 주문 금액이 상품 개수만큼 복사됐기 때문입니다.

고치는 방법은 두 가지입니다. 서브쿼리에서 먼저 집계한 뒤 조인하거나, 값이 하나뿐이라면 DISTINCT로 거릅니다. 합계를 내는 상황이라면 앞쪽이 맞습니다. DISTINCT는 같은 금액이 진짜로 여러 건일 때 그것까지 지워버립니다.

NOT IN의 NULL 함정

이건 결과가 조금 어긋나는 정도가 아니라 아예 빈 집합이 나옵니다.

-- 서브쿼리 결과에 NULL 이 하나라도 있으면 항상 0건
SELECT name FROM students
WHERE id NOT IN (SELECT student_id FROM enrollments);

enrollments.student_id에 NULL이 한 건이라도 있으면 결과가 무조건 비어버립니다. NOT IN은 내부적으로 id <> 1 AND id <> 2 AND id <> NULL 처럼 풀리는데, NULL과의 비교는 참도 거짓도 아닌 알 수 없음이 되고, AND로 묶이면 전체가 참이 될 수 없기 때문입니다.

-- NOT EXISTS 로 바꾸면 NULL 이 있어도 정상 동작
SELECT s.name
FROM students s
WHERE NOT EXISTS (
    SELECT 1 FROM enrollments e WHERE e.student_id = s.id
);

NOT EXISTS를 기본으로 사용하는 습관이 안전합니다. NOT IN은 비교 대상에 NULL이 하나라도 포함되면 예상과 다른 결과가 나올 수 있습니다. 비교 대상이 NOT NULL임을 확실히 알 때만 NOT IN을 사용하는 것이 좋습니다.

EXISTS와 Semi-Join

"90점 이상 받은 과목이 하나라도 있는 학생"을 찾는다고 해보겠습니다. JOIN으로 짜면 중복이 생깁니다.

-- 90점 이상 과목 수만큼 학생 이름이 반복됩니다
SELECT DISTINCT s.name
FROM students s
JOIN enrollments e ON e.student_id = s.id
WHERE e.score >= 90;

-- EXISTS: 하나라도 있으면 참. 중복이 생기지 않습니다
SELECT s.name
FROM students s
WHERE EXISTS (
    SELECT 1 FROM enrollments e
    WHERE e.student_id = s.id AND e.score >= 90
);

오른쪽 테이블의 존재 여부만 확인하고 값은 가져오지 않는 조인을 Semi-Join이라고 합니다. EXISTS와 IN은 많은 DBMS에서 옵티마이저가 이런 형태로 최적화합니다. 이 경우 조건을 만족하는 행을 하나 찾으면 추가 탐색을 생략할 수 있어 불필요한 작업을 줄일 수 있습니다. 또한 결과 자체가 존재 여부만 판단하므로 DISTINCT를 따로 사용할 필요가 없습니다.

IN은 비교 대상이 명확하고 목록이 작을 때 읽기 쉽습니다. 반면 서브쿼리 결과가 크거나 바깥 쿼리의 값을 참조하는 상관 서브쿼리라면 EXISTS가 더 적합한 경우가 많습니다.

정리하면

LEFT JOIN + WHERE 우측 조건 = INNER JOIN. OUTER를 유지하려면 조건을 ON에 넣습니다
짝이 없는 행만 찾을 때는 WHERE ... IS NULL이 맞습니다. 이건 Anti-Join 패턴입니다
ON을 빠뜨리면 CROSS JOIN입니다. 10만 × 10만이면 쿼리가 끝나지 않습니다
1:N 조인 뒤의 집계는 부풀려집니다. 서브쿼리에서 먼저 집계하고 조인합니다
NOT IN은 NULL 하나에 결과가 통째로 비어버립니다. NOT EXISTS를 기본으로 씁니다

한 줄 정리: ON은 조인할 대상을 고르는 조건이고, WHERE는 조인이 끝난 결과를 거르는 조건입니다. 이 순서만 기억해도 LEFT JOIN, NULL, 결과 행 수가 왜 달라지는지 대부분 이해할 수 있습니다.

참고

PostgreSQL 인덱스 설계 | 선택도, 복합 인덱스 순서, 커버링 인덱스, 쓰기 비용

boradora — Thu, 30 Jul 2026 10:32:13 +0900

작업일2026. 07

인덱스 B-Tree 선택도 복합 인덱스 커버링 인덱스 PostgreSQL

쿼리가 느릴 때 가장 먼저 나오는 답이 인덱스를 걸라는 것입니다. 그런데 인덱스를 만들면 조회는 빨라지지만 쓰기가 느려지고 저장 공간이 늘어납니다. 어느 컬럼에 걸어야 하고 어디까지 걸어도 되는지 정리해보겠습니다.

인덱스를 걸었는데 왜 더 느려졌을까요?
조건에 맞는 행이 전체의 20%를 넘으면 인덱스를 타도 순차 읽기와 속도가 비슷해집니다.

수백만 행짜리 테이블에서 조건 하나로 행을 찾는다고 해봅시다. 인덱스가 없으면 데이터베이스는 첫 행부터 마지막 행까지 전부 확인합니다. 행이 두 배가 되면 걸리는 시간도 두 배가 되는 O(N) 구조입니다.

인덱스가 있으면 탐색 횟수가 O(log N)으로 줄어듭니다. B-Tree는 노드 하나에 수백 개의 자식이 붙기 때문에, 행이 수백 배로 늘어나야 탐색 단계가 하나 늘어납니다. 그래서 100만 행이든 1억 행이든 몇 단계 안에 도달합니다.

실제로 재보면

5만 행짜리 직원 테이블에서 이메일로 한 명을 찾는 쿼리를 직접 측정해봤습니다.

EXPLAIN (ANALYZE, BUFFERS)
SELECT * FROM employees
 WHERE lower(email) = 'user1234@corp.com';

인덱스가 없을 때입니다.

Seq Scan on employees  (cost=0.00..1657.00 rows=250 width=28)
                       (actual time=13.944..13.946 rows=1 loops=1)
  Filter: (lower(email) = 'user1234@corp.com'::text)
  Rows Removed by Filter: 50000
  Buffers: shared hit=907

Execution Time: 13.968 ms

1건을 찾으려고 5만 건을 읽고 버렸습니다. Rows Removed by Filter: 50000이 그 숫자입니다. 이 한 줄이 인덱스가 필요하다는 신호입니다.

인덱스를 만들고 같은 쿼리를 실행합니다.

CREATE INDEX idx_employees_lower_email ON employees (lower(email));
ANALYZE employees;

Index Scan using idx_employees_lower_email on employees
    (cost=0.41..8.43 rows=1 width=28)
  Index Cond: (lower(email) = 'user1234@corp.com'::text)
  Buffers: shared read=3

Execution Time: 0.090 ms

인덱스 없음

Seq Scan · O(N)

5만 행을 읽고 49,999행을 버림

13.968 ms

인덱스 있음

Index Scan · O(log N)

3 페이지

0.090 ms

약 155배 차이입니다. 읽은 페이지 수는 907에서 3으로 줄었습니다.

여기서 인덱스를 email에 걸면 안 됩니다. 조건이 lower(email)이라 컬럼 값이 그대로 쓰이지 않기 때문에, email 인덱스는 타지 않습니다. 함수를 적용한 결과에 인덱스를 걸어야 위처럼 Index Cond로 잡힙니다. 이런 인덱스를 함수 기반 인덱스라고 합니다.

인덱스를 걸면 느려지는 것

여기까지만 보면 모든 컬럼에 인덱스를 걸면 될 것 같습니다. 그렇게 하지 않는 이유는 조회가 빨라지는 만큼 쓰기가 느려지고 저장 공간이 늘어나기 때문입니다.

빨라짐

조회

WHERE · JOIN · ORDER BY 가 빨라집니다

느려짐

쓰기

INSERT · UPDATE · DELETE 마다 인덱스를 재정렬합니다

늘어남

저장 공간

인덱스도 디스크를 차지합니다

인덱스가 열 개 걸린 테이블에 행 하나를 넣으면 테이블에 한 번, 인덱스에 열 번을 씁니다. 그래서 쓰기가 많은 테이블일수록 인덱스를 적게 유지해야 합니다.

이 비용은 실행계획에 안 나옵니다. EXPLAIN은 조회 쪽만 보여주기 때문에, 직접 INSERT 시간을 재봤습니다. 같은 테이블에 2만 행을 넣는 시간입니다.

인덱스 구성	INSERT 20,000행	인덱스 총 크기
기본키와 UNIQUE만	220 ms	8.77 MB
튜닝 인덱스 7개 추가	433 ms (1.97배)	22.43 MB

인덱스 일곱 개를 더 만들었더니 쓰기가 두 배 가까이 느려졌습니다. 그리고 테이블 본체가 약 7.5MB인데 인덱스 총량이 22.43MB로 본체보다 커졌습니다. 디스크 사용량의 대부분이 데이터가 아니라 인덱스입니다.

주문이 초당 수백 건씩 들어오는 테이블과, 하루에 한 번 적재하고 종일 조회만 하는 테이블은 인덱스 전략이 반대입니다.

구분	쓰기 중심 (OLTP)	읽기 중심 (OLAP)
예	주문, 결제, 로그 적재	대시보드, 리포트, 집계
인덱스 수	꼭 필요한 것만	조회 패턴마다 넉넉히
기준	쓰기 지연을 얼마나 감수할 수 있는가	조회가 얼마나 자주 반복되는가

조회에 한 번도 쓰이지 않는 인덱스는 쓰기만 느리게 만듭니다. 조회가 빨라지는 효과는 없는데 INSERT마다 갱신되고 디스크도 차지합니다. 뒤에서 이런 인덱스를 찾아내는 방법을 정리하겠습니다.

B-Tree의 구조

대부분의 인덱스는 B-Tree(Balanced Tree)입니다. 모든 리프 노드가 같은 깊이에 있어서 어떤 값을 찾든 탐색 단계 수가 같고, 그래서 O(log N)이 보장됩니다.

Root

▼

Branch

▼

Leaf

↔

Leaf

↔

Leaf

↔

Leaf

Root는 탐색의 시작점, Branch는 어느 쪽으로 내려갈지 안내하는 중간 노드, Leaf는 실제 키 값과 테이블 행의 물리 위치(ctid)를 가지고 있습니다. 리프끼리 이중 연결 리스트로 이어져 있어서 BETWEEN 같은 범위 조회가 빠릅니다.

여기서 실무에 바로 걸리는 것이 키 크기입니다. 키가 작을수록 노드 하나에 더 많은 항목이 들어가고, 그만큼 트리 깊이가 얕아져 탐색이 빨라집니다. 기본키로 UUID(16바이트)를 쓸지 BIGINT(8바이트)를 쓸지가 인덱스 크기에 그대로 반영됩니다.

컬럼 타입을 열어 두면 인덱스가 커집니다

같은 이유로 인덱스를 걸 컬럼의 길이를 정해 두는 편이 낫습니다. 아래처럼 식별자 컬럼을 TEXT로 열어 두는 설계가 자주 보입니다.

CREATE TABLE query_logs (
  id       SERIAL PRIMARY KEY,
  user_id  TEXT,          -- 길이 제한이 없습니다
  ...
);
CREATE INDEX idx_user ON query_logs (user_id);

PostgreSQL만 놓고 보면 TEXT와 VARCHAR(n)은 저장 방식이 같아서 타입만으로 공간을 더 쓰지는 않습니다. 문제는 길이를 막아 두지 않으면 긴 값이 그대로 인덱스 키로 들어간다는 점입니다. 키가 길어지면 노드에 담기는 항목이 줄고 트리가 깊어집니다. 값 하나가 인덱스 행 크기 한계(약 2,704바이트)를 넘으면 그 행은 아예 인덱스에 들어가지 못하고 에러가 납니다.

MySQL은 여기서 차이가 더 큽니다. TEXT 컬럼에는 인덱스를 통째로 걸 수 없어서 INDEX(user_id(20))처럼 앞 몇 글자만 잡는 prefix 인덱스를 써야 하고, 그만큼 선택도가 떨어집니다.

-- 값의 최대 길이를 예측해 자리수를 정해 둡니다
user_id  VARCHAR(64)  NOT NULL

실제로 들어올 값의 최대 길이를 먼저 확인하고, 여유를 조금 둔 자리수로 잡습니다. 사번이나 UUID 문자열처럼 형식이 정해진 값이라면 자리수도 같이 정해집니다.

Fill Factor는 인덱스 페이지를 몇 퍼센트까지 채울지 정하는 값으로 기본값이 90입니다. 10%를 비워 두는 이유는 나중에 값이 들어올 자리를 남겨 페이지 분할을 줄이기 위해서입니다. UPDATE가 잦은 테이블이라면 이 값을 낮춰 분할 횟수를 더 줄일 수 있습니다.

CREATE INDEX idx_orders_status ON orders (status)
  WITH (fillfactor = 70);

B-Tree 말고 다른 인덱스

B-Tree가 기본값이지만 데이터 형태에 따라 더 맞는 구조가 따로 있습니다. JSON 컬럼이나 좌표 데이터에 B-Tree를 걸면 인덱스를 만들어도 타지 않습니다.

인덱스	구조	맞는 용도	지원
B-Tree	균형 트리	`=`, `BETWEEN`, `LIKE 'abc%'`, `ORDER BY`	모든 DBMS 기본
Hash	해시 테이블	등호 비교만. 범위 조회 불가	PostgreSQL, MySQL(제한적)
GIN	역색인	JSONB, 배열, 전문검색	PostgreSQL
GiST	일반화 검색 트리	지리정보(PostGIS), 범위 타입, 벡터 유사도	PostgreSQL 확장
BRIN	블록 범위의 최소·최대	시간순으로 쌓이는 대용량 로그	PostgreSQL
Bitmap	비트 배열	고유값이 적은 컬럼 여러 개를 조합할 때	Oracle (DW용)
Clustered	데이터를 물리적으로 정렬	범위 스캔, 기본키 기반 접근	SQL Server, MySQL InnoDB

BRIN은 인덱스 크기가 B-Tree의 수백분의 일 수준입니다. 대신 물리적으로 정렬돼 쌓인 데이터에서만 효과가 나기 때문에, 시간순으로 적재되는 로그 테이블이 대표적인 대상입니다.

궁금!역인덱스는 무엇을 뒤집은 것일까?

대응 방향이 반대입니다. B-Tree는 행 하나에 키 하나를 대응시킵니다. tags = '{db, sql, index}' 라는 배열이 들어 있으면, B-Tree는 그 배열 전체를 키 하나로 봅니다. 그래서 배열이 정확히 {db, sql, index} 인 행은 찾을 수 있지만, "sql 이 들어 있는 행"은 찾을 수 없습니다.

역인덱스(Inverted Index)는 키 하나에 그 키를 포함한 행 목록을 대응시킵니다. 값을 쪼개서 조각마다 항목을 만들고, 각 항목에 행 위치를 모아 둡니다.

db → [3번 행, 7번 행, 12번 행]
sql → [3번 행, 21번 행]
index → [3번 행, 9번 행]

이제 sql 로 검색하면 3번과 21번 행만 읽으면 됩니다. 조건이 두 개면 각 목록의 교집합이나 합집합을 구합니다. "역"이라는 이름은 행에서 값을 찾는 방향을 값에서 행을 찾는 방향으로 뒤집었다는 뜻입니다.

궁금!GIN 인덱스는 어떻게 동작할까?

GIN은 Generalized Inverted Index의 줄임말입니다. 앞의 역인덱스를 특정 데이터 타입에 묶지 않고 일반화한 것이라 이름에 Generalized가 붙었습니다. 값을 어떻게 쪼갤지만 타입별로 정해주면 같은 구조를 그대로 씁니다.

쪼개는 방식이 타입마다 다릅니다.
배열은 원소 하나하나가 항목이 되고, JSONB는 키와 값이 항목이 됩니다. 전문검색은 단어 단위로 쪼개고, pg_trgm 은 세 글자씩 쪼갭니다. 'user123' 이라면 use, ser, er1, r12, 123 같은 조각이 항목이 됩니다. 그래서 LIKE '%ser%' 처럼 가운데를 검색해도 ser 항목의 행 목록을 꺼내 후보를 좁힐 수 있습니다.

내부는 두 겹입니다. 항목들은 B-Tree로 정렬해 관리하고, 각 항목에 붙은 행 목록은 개수가 적으면 배열로, 많아지면 별도의 B-Tree로 보관합니다. 같은 값이 수만 행에 나타나도 목록 탐색이 느려지지 않게 하려는 구조입니다.

대가는 쓰기 비용입니다. 값 하나를 넣을 때 항목이 여러 개 생기므로 인덱스 갱신량이 그만큼 많아집니다. 'user123' 한 건에 조각 여러 개가 들어갑니다. 그래서 GIN에는 fastupdate 옵션이 있어 새 항목을 대기 목록에 모아 두고 나중에 합칩니다. 다만 합쳐지기 전까지는 조회할 때 그 대기 목록도 훑어야 해서 조회가 일시적으로 느려질 수 있습니다.

마지막으로 GIN은 후보를 좁혀 주는 역할까지만 합니다. ser 조각을 가진 행이라고 해서 실제로 '%ser%' 에 맞는다는 보장은 없기 때문에, 행을 읽은 뒤 조건을 한 번 더 확인합니다. 실행계획에 Recheck Cond 가 나오는 이유가 여기 있습니다.

어떤 컬럼에 걸 것인가

인덱스를 걸 컬럼을 고르는 기준이 선택도(Selectivity)입니다. 조건 하나로 전체의 몇 분의 몇까지 좁혀지는가를 재는 값입니다.

선택도 = 고유값 수 ÷ 전체 행 수

-- 전체 5만 행일 때
gender  : 고유값 2개      →      2 ÷ 50,000 ≈ 0.00004   거의 0
email   : 고유값 50,000개 → 50,000 ÷ 50,000 = 1         1에 가까움

이 용어는 문헌마다 뒤집혀 쓰입니다. 위 공식으로는 1에 가까울수록 좋은 인덱스입니다. 반대로 "조건을 만족하는 행의 비율"을 선택도라 부르는 글에서는 0에 가까울수록 좋다고 씁니다. 부르는 이름보다 조건 하나로 몇 행이 남는지를 보면 헷갈리지 않습니다.

고유값 2개 · 인덱스 효과 낮음

gender

값이 M과 F 두 개뿐이라 조건 하나로 절반밖에 걸러내지 못합니다. 절반을 읽을 바에는 전체를 순차로 읽는 편이 빠를 수 있어서, 옵티마이저가 인덱스를 건너뛰기도 합니다.

고유값이 행 수만큼 · 인덱스 효과 큼

email

값이 거의 전부 다르기 때문에 조건 하나로 행 하나까지 좁혀집니다.

조건이 전체의 20%를 넘게 남기면 인덱스를 타도 이득이 거의 없습니다. 이메일 도메인이 gmail인 직원을 찾는 쿼리로 재봤더니, 선택도가 25%인 구간에서 Bitmap Index Scan(2.73ms)과 Seq Scan(2.83ms)이 거의 같았습니다. 읽어야 할 행이 그만큼 많으면 인덱스를 거쳐 흩어진 위치를 찾아가는 비용이 순차 읽기와 비슷해집니다.

선택도 외에 실무에서 함께 보는 기준이 네 가지 더 있습니다.

WHERE에 자주 등장하는 컬럼을 먼저 봅니다. 쿼리 로그를 뒤져 실제로 어떤 조건이 반복되는지 확인합니다.
외래키 컬럼에는 반드시 인덱스를 겁니다. JOIN 성능뿐 아니라 부모 행을 지우거나 고칠 때 하는 참조 검사에도 쓰입니다. 없으면 자식 테이블을 전부 훑습니다.
쓰기 중심인지 읽기 중심인지에 따라 개수를 조절합니다.
쓰이지 않는 인덱스는 지웁니다. 남겨 둘 이유가 없습니다.

복합 인덱스의 컬럼 순서

컬럼 두 개 이상을 묶은 인덱스를 복합 인덱스라고 합니다. 여기서는 어떤 컬럼을 앞에 두느냐에 따라 성능이 갈립니다. 규칙은 하나입니다. 등호 조건을 앞에, 범위 조건을 뒤에 둡니다.

SELECT * FROM orders
 WHERE status = 'A'
   AND created_at > '2024-01-01';

INDEX (status, created_at)

status = 'A' 로 범위를 먼저 좁힌 뒤, 그 안에서 날짜 범위를 훑습니다. 읽는 양이 두 단계에 걸쳐 줄어듭니다.

INDEX (created_at, status)

날짜 범위로 넓게 잡아 놓고 그 안에서 status 를 하나씩 걸러냅니다. 먼저 읽어야 하는 양이 훨씬 많습니다.

범위 조건을 앞에 두면 그 뒤 컬럼은 정렬 순서를 잃어서 인덱스로 좁히지 못하고 필터로만 쓰입니다. 등호를 앞에 두는 이유가 여기 있습니다.

커버링 인덱스

인덱스를 타고 행을 찾아도 작업이 한 번 더 남습니다. 인덱스에는 키 값과 행의 위치만 있기 때문에, 나머지 컬럼을 읽으려면 테이블(Heap)에 접근해야 합니다. 이 추가 접근을 Heap Fetch라고 합니다.

커버링 인덱스는 쿼리가 필요로 하는 모든 컬럼을 인덱스 안에 넣어 테이블 접근을 없앤 인덱스입니다. PostgreSQL과 SQL Server에서는 INCLUDE 절로 만듭니다.

-- 일반 인덱스 : 인덱스를 탄 뒤 테이블을 한 번 더 읽습니다
CREATE INDEX idx_email ON users (email);
SELECT id, name FROM users WHERE email = 'a@b.com';
-- Index Scan using idx_email  +  Heap Fetch

-- 커버링 인덱스 : 반환할 컬럼까지 인덱스에 담습니다
CREATE INDEX idx_email_cover ON users (email) INCLUDE (id, name);
SELECT id, name FROM users WHERE email = 'a@b.com';
-- Index Only Scan using idx_email_cover

INCLUDE에 넣은 컬럼은 탐색에는 쓰이지 않고 반환에만 쓰입니다. 그래서 트리 깊이를 늘리지 않으면서 테이블 접근만 없앨 수 있습니다. 적용됐는지 확인하려면 실행계획에서 Heap Fetches 값을 봅니다.

EXPLAIN (ANALYZE, BUFFERS)
SELECT id, name FROM users WHERE email = 'a@b.com';

Index Only Scan using idx_email_cover on users
  Heap Fetches: 0        ← 테이블 접근 0번

Heap Fetches가 0이 아니면 Index Only Scan이 반쪽만 동작한 것입니다. PostgreSQL은 해당 행이 모든 트랜잭션에 보여도 되는지를 Visibility Map으로 판단하는데, 이 정보가 낡아 있으면 결국 테이블을 확인합니다. VACUUM이 오래 실행되지 않았는지부터 확인하면 됩니다.

안 쓰는 인덱스 찾아내기

인덱스는 만들 때보다 지울 때 판단이 어렵습니다. PostgreSQL은 인덱스가 몇 번 쓰였는지를 pg_stat_user_indexes에 기록하기 때문에, 감이 아니라 횟수로 판단할 수 있습니다.

-- 사용 횟수가 적은 인덱스부터 (제거 후보)
SELECT indexrelname AS index_name,
       relname      AS table_name,
       idx_scan     AS scan_count,
       pg_size_pretty(pg_relation_size(indexrelid)) AS index_size
  FROM pg_stat_user_indexes
 ORDER BY idx_scan ASC
 LIMIT 20;

-- 한 번도 안 쓰인 인덱스 (기본키 제외)
SELECT indexrelname, relname,
       pg_size_pretty(pg_relation_size(indexrelid))
  FROM pg_stat_user_indexes
 WHERE idx_scan = 0
   AND indexrelname NOT LIKE 'pk_%'
 ORDER BY pg_relation_size(indexrelid) DESC;

idx_scan이 0이면 통계를 모으기 시작한 뒤로 한 번도 쓰이지 않았다는 뜻입니다. 크기가 큰 것부터 제거를 검토하면 쓰기 비용과 디스크를 함께 줄일 수 있습니다.

인덱스를 오래 쓰면 삭제와 갱신이 쌓여 실제 데이터보다 부풀어 오릅니다. 이때는 재구성을 하는데, CONCURRENTLY를 붙이면 재구성 중에도 읽기와 쓰기가 계속 됩니다. 다만 완전히 잠금이 없는 것은 아니고, 마지막에 인덱스를 교체하는 짧은 순간에는 배타적 잠금이 필요합니다. PostgreSQL 12부터 쓸 수 있습니다.

REINDEX INDEX CONCURRENTLY idx_orders_cust_date;
REINDEX TABLE CONCURRENTLY orders;

MySQL에서는 information_schema.STATISTICS의 CARDINALITY로 각 인덱스의 고유값 추정치를 확인합니다. 값이 낮으면 선택도가 낮다는 뜻입니다.

SELECT TABLE_NAME, INDEX_NAME, CARDINALITY
  FROM information_schema.STATISTICS
 WHERE TABLE_SCHEMA = 'mydb'
 ORDER BY CARDINALITY ASC;

정리하면

인덱스를 걸기 전에 확인할 것을 순서대로 정리해보겠습니다.

이 컬럼의 선택도가 얼마인가. 고유값이 두세 개뿐이라면 인덱스를 만들어도 옵티마이저가 쓰지 않을 수 있습니다.
이 테이블은 쓰기가 많은가 읽기가 많은가. 쓰기가 많으면 인덱스 하나가 늘어날 때마다 INSERT가 느려집니다.
복합 인덱스라면 등호 조건이 앞에 있는가. 순서만 바꿔도 읽는 양이 달라집니다.
외래키에 인덱스가 있는가. 없으면 JOIN과 참조 검사에서 전체 스캔이 일어납니다.
지금 있는 인덱스 중 안 쓰이는 것은 없는가. idx_scan = 0이면 조회에는 안 쓰이면서 쓰기만 느리게 만드는 상태입니다.

한 줄 정리: 인덱스를 걸면 조회가 빨라지고 쓰기가 느려집니다. 몇 개까지 걸어도 되는지는 그 테이블에 INSERT가 얼마나 들어오는지로 정해집니다.

참고

PostgreSQL: Indexes
PostgreSQL: Index-Only Scans and Covering Indexes
PostgreSQL: The Statistics Collector
MySQL: Optimization and Indexes

데이터 모델링 핵심 정리 | 정규화, 외래키, ERD, PostgreSQL 설계

boradora — Thu, 30 Jul 2026 08:48:36 +0900

작업일2026. 07

데이터 모델링 외래키 정규화 교차 테이블 ERD PostgreSQL

SQL 문법은 비교적 금방 익힐 수 있습니다. 하지만 테이블을 어디까지 나눌지, 부모를 삭제했을 때 자식 데이터를 어떻게 처리할지, 컬럼 타입을 무엇으로 선택할지 같은 설계는 훨씬 오래 고민하게 됩니다. 데이터가 쌓인 뒤에는 바꾸기 어렵기 때문이죠.

고객을 삭제하면 그 고객의 주문은 어떻게 되어야 할까요?
같이 지울지, 삭제를 막을지, 주문은 남기고 고객만 비울지를 설계할 때 정해 둡니다.

CREATE TABLE 문법과 SELECT 기본 형태는 여기서 다루지 않습니다. 대신 설계 단계에서 실제로 결정해야 하는 것들을 순서대로 정리해보겠습니다.

테이블을 나누는 이유

고객 이름과 주문 내역을 한 테이블에 같이 담으면 세 가지 문제가 생깁니다. 이상 현상(Anomaly)이라고 부르고, 정규화는 이 셋을 막기 위한 규칙입니다.

삽입 이상

아직 주문한 적 없는 고객을 등록하려는데 주문 정보 칸을 비워 둘 수 없어 넣지 못합니다. 넣고 싶은 것만 넣을 수 없는 상태입니다.

삭제 이상

마지막 주문 한 건을 취소했더니 그 고객의 이름과 연락처까지 함께 사라집니다. 지우고 싶지 않은 것까지 지워지는 상태입니다.

갱신 이상

고객이 이메일을 바꿨는데 주문 50건 중 30건만 고쳐졌습니다. 어느 값이 맞는지 알 수 없는 상태가 되어 가장 위험합니다.

세 가지 이상 현상의 원인은 같습니다. 성격이 다른 정보가 한 테이블에 섞여 있기 때문입니다. 고객은 customers에, 주문은 orders에 나눠 담고 주문 쪽에서 고객을 가리키게 하면 셋 다 사라집니다.

외래키를 걸 때 정하는 것

외래키를 선언하면 데이터베이스가 참조 무결성을 지켜 줍니다. 없는 고객 번호를 주문에 넣으려 하면 거부되고, 주문이 남아 있는 고객을 지우려 할 때도 막힙니다.

여기서 결정해야 하는 것이 부모를 지울 때 자식을 어떻게 할지입니다. 기본값에 맡기지 않고 업무 규칙에 맞게 골라야 합니다.

옵션	동작	쓰는 상황
`ON DELETE CASCADE`	부모를 지우면 자식도 함께 삭제	주문을 지우면 주문 항목도 같이 사라져야 할 때. 주문 없이 존재할 이유가 없는 데이터
`ON DELETE RESTRICT`	자식이 있으면 부모 삭제를 차단	카테고리를 지우기 전에 그 안의 상품을 먼저 정리하게 만들 때
`ON DELETE SET NULL`	부모를 지우면 자식의 외래키를 `NULL`로	담당 직원이 퇴사해도 고객 정보는 남기고 담당자만 비울 때
`ON DELETE NO ACTION`	RESTRICT와 거의 같고 검사 시점이 다름	Oracle과 SQL Server의 기본값
`ON UPDATE CASCADE`	부모 키가 바뀌면 자식도 따라 변경	학번 같은 자연키가 바뀔 때. 애초에 대체키를 쓰는 편이 낫습니다

CREATE TABLE order_items (
  order_id   BIGINT NOT NULL,
  product_id BIGINT NOT NULL,
  quantity   INT    NOT NULL,
  unit_price NUMERIC(10,2) NOT NULL,
  PRIMARY KEY (order_id, product_id),
  FOREIGN KEY (order_id)   REFERENCES orders(order_id)     ON DELETE CASCADE,
  FOREIGN KEY (product_id) REFERENCES products(product_id) ON DELETE RESTRICT
);

같은 테이블 안에서도 옵션이 갈립니다. 주문이 사라지면 그 주문 항목은 남을 이유가 없으니 CASCADE이고, 상품은 주문 기록이 남아 있는 한 함부로 지우면 안 되니 RESTRICT입니다.

CASCADE는 연쇄됩니다. 부모의 부모까지 이어져 있으면 한 번의 DELETE로 예상보다 많은 행이 사라집니다. 삭제 대신 deleted_at 컬럼을 두고 지운 것으로 표시만 하는 방식(소프트 삭제)을 쓰는 경우가 많은 이유가 여기 있습니다.

관계와 교차 테이블

관계는 한쪽 행이 반대쪽 행 몇 개와 연결되는지로 세 가지로 나뉩니다. 이 중 실제로 설계 판단이 필요한 것은 N:M입니다.

N:M 관계는 외래키만으로 표현할 수 없어서 가운데 테이블이 반드시 들어갑니다. 주문 하나에 상품이 여러 개 담기고 같은 상품이 여러 주문에 들어가는 구조가 그렇습니다. order_items 같은 교차 테이블을 두면 다대다가 1:N 두 개로 풀립니다.

orders

PK order_id

1 → N

order_items

PK (order_id, product_id)
quantity · unit_price

N ← 1

products

PK product_id

가운데 교차 테이블에는 그 연결에만 붙는 정보를 함께 담습니다. 수량과 구매 시점 단가가 여기 들어가는데, 상품 가격은 나중에 바뀌어도 지난 주문의 결제 금액은 바뀌면 안 되기 때문입니다.

교차 테이블의 기본키는 두 외래키를 묶은 복합키로 두거나, 별도의 일련번호를 두는 방식 중에 고릅니다. 복합키로 두면 같은 조합이 두 번 들어가는 것을 데이터베이스가 막아 줍니다.

조회 방향이 양쪽 다 있다면 인덱스도 양방향으로 만들어 둡니다. 수강 테이블이라면 INDEX(student_id, course_id)와 INDEX(course_id, student_id)를 함께 두는 식입니다. 학생으로도 찾고 과목으로도 찾기 때문입니다.

약한 엔티티

약한 엔티티는 자기만의 기본키가 없어서 부모 없이는 구분되지 않는 테이블입니다. 주문 항목은 몇 번째 항목인지만으로는 식별되지 않고, 어느 주문의 몇 번째인지가 있어야 구분됩니다.

부모의 기본키와 자신의 부분키를 묶어 복합 기본키를 만듭니다.
부모가 사라지면 존재할 이유가 없으므로 ON DELETE CASCADE를 겁니다.

정규화를 어디까지

정규화 단계는 여러 단계로 나뉘지만, 내용은 전부 한 테이블에 성격이 다른 정보를 섞지 말라는 말입니다.

정규형	조건	없애는 것	예
1NF	한 칸에 값 하나만	반복 그룹, 다중값 속성	`과목 = 'DB, 네트워크'` 를 두 행으로 분리
2NF	1NF + 부분 함수 종속 제거	복합키의 일부에만 딸린 속성	(학번, 과목코드)가 키인데 학생 이름은 학번에만 딸림
3NF	2NF + 이행적 종속 제거	키가 아닌 속성끼리의 종속	학번 → 학과코드 → 학과명 사슬을 끊음
BCNF	3NF + 모든 결정자가 후보키	후보키가 아닌 결정자	3NF를 만족해도 남는 예외를 정리

실무에서는 보통 3NF 또는 BCNF까지 적용합니다. 더 나눌수록 중복은 줄지만 조회할 때 이어 붙일 테이블이 늘어나 JOIN 비용이 커지기 때문입니다.

그래서 조회가 아주 잦은 곳에서는 일부러 중복을 남기는 반정규화를 검토합니다. 다만 순서가 있습니다. 정규화가 기본이고, 반정규화는 측정한 근거를 갖고 되돌리는 선택입니다. 처음부터 반정규화된 구조로 시작하면 갱신 이상을 애플리케이션이 전부 떠안게 됩니다.

개념 · 논리 · 물리 세 단계

모델링은 한 번에 끝나지 않고 추상적인 것에서 구체적인 것으로 세 단계를 거칩니다. 각 단계에서 정하는 것이 다르고, 앞 단계를 건너뛰면 뒤에서 되돌아오게 됩니다.

① 개념적

요구사항에서 명사를 뽑아 엔티티를 찾습니다.
관계와 카디널리티를 정하고 ERD를 그립니다.
DBMS와 무관합니다.

→

② 논리적

엔티티를 테이블로 옮깁니다.
PK와 FK를 정하고 정규화를 적용합니다.
아직 DBMS와 무관합니다.

→

③ 물리적

쓰는 DBMS에 맞춥니다.
데이터 타입과 인덱스를 정합니다.
여기서 제품별 차이가 나옵니다.

타입을 정할 때 걸리는 것

물리 설계에서 자주 실수하는 세 가지가 있습니다. 전부 나중에 바꾸기 어려운 항목입니다.

금액은 NUMERIC(10,2)로 둡니다. FLOAT이나 DOUBLE은 이진 부동소수점이라 0.1 + 0.2가 정확히 0.3이 되지 않습니다. 합계가 1원씩 어긋나는 정산 문제가 여기서 나옵니다.
시각은 TIMESTAMPTZ로 둡니다. 타임존 없이 저장하면 서버 지역이 바뀌거나 사용자가 해외에 있을 때 시각이 어긋납니다.
문자열은 최대 길이를 정해 둡니다. PostgreSQL에서 TEXT와 VARCHAR(n)은 저장 방식이 같지만, 인덱스를 걸 컬럼이라면 길이를 막아 두는 편이 낫습니다. 긴 값이 그대로 인덱스 키가 되면 트리가 깊어집니다.

정리하면

설계할 때 명시적으로 정하고 넘어가야 하는 것들입니다. 기본값에 맡기면 나중에 문제가 됩니다.

외래키마다 삭제 옵션을 정합니다. 함께 지울지(CASCADE), 막을지(RESTRICT), 비울지(SET NULL).
N:M은 교차 테이블로 풀고, 그 연결에만 붙는 값을 함께 담습니다. 구매 시점 단가가 대표적입니다.
정규화는 3NF까지 가고, 반정규화는 측정한 뒤에 합니다. 순서를 바꾸면 갱신 이상을 코드가 떠안습니다.
금액은 NUMERIC, 시각은 TIMESTAMPTZ. 데이터가 쌓인 뒤에는 바꾸기 어렵습니다.
카디널리티는 업무 규칙으로 정합니다. 지금 하나인 것과 앞으로도 하나여야 하는 것은 다릅니다.

한 줄 정리: 모델링에서 어려운 것은 문법이 아니라 되돌리기 어려운 결정들입니다. 삭제 옵션, 정규화 수준, 컬럼 타입, 카디널리티 네 가지는 설계할 때 근거를 갖고 정해 둡니다.

참고

PostgreSQL: Constraints (외래키 옵션)
PostgreSQL: Numeric Types
PostgreSQL: Date/Time Types
ERD 작성 도구: dbdiagram.io (DBML 문법으로 텍스트를 쓰면 ERD가 그려집니다)

ERD와 SQL 기초: 데이터 모델링부터 JOIN까지

boradora — Tue, 28 Jul 2026 12:15:22 +0900

작업일2026. 07

ERD SQL SELECT WHERE JOIN DBeaver

데이터 모델을 설계한 뒤에는 테이블 관계를 ERD로 문서화하고, SQL로 필요한 데이터를 조회합니다.

고객 이름과 주문 상품처럼 여러 테이블에 나뉜 데이터를 함께 조회하려면 어떻게 할까요?
JOIN은 공통 키를 기준으로 여러 테이블의 데이터를 결합합니다.

기본키와 외래키로 테이블을 분리하면 데이터 중복과 불일치를 줄일 수 있습니다. 조회 시에는 필요한 데이터를 결합해야 합니다. 예를 들어 고객 이름은 customers에, 주문 상품은 orders에 있으므로 두 테이블을 연결하는 조건이 필요합니다.

이 글에서는 설계를 표현하는 ERD와 데이터를 조회하는 SQL의 기본 문법을 정리합니다. 문법 자체보다 쿼리가 처리되는 순서를 이해하는 것이 중요합니다.

ERD

ERD(Entity-Relationship Diagram)는 테이블과 테이블 사이의 관계를 시각적으로 표현한 설계 문서입니다. 테이블을 생성하기 전에 데이터 구조를 검토할 수 있으며, 구현 전 변경 비용을 줄이는 데 도움이 됩니다.

ERD는 개발·기획 등 여러 역할이 동일한 데이터 구조를 공유하는 기준이기도 합니다. 개발자는 테이블 구조로, 기획자는 업무 흐름으로 해석할 수 있습니다.

표기 요소

ERD는 개체, 속성, 관계, 카디널리티로 구성됩니다. 각 요소는 데이터 대상, 세부 정보, 연결 방식, 관계의 수를 나타냅니다.

개체 (Entity)

테이블이 될 대상

고객, 주문, 상품

속성 (Attribute)

개체가 갖는 정보. 테이블의 열이 됩니다

고객의 이름, 이메일

관계선 (Relationship)

개체 사이를 잇는 선

고객이 주문을 생성

카디널리티

관계의 개수 표기

1, N

개체는 테이블, 속성은 열로 구현됩니다. ERD를 기준으로 CREATE TABLE 문을 작성할 수 있어 설계와 구현의 대응 관계를 확인하기 쉽습니다.

실제로 그려보면

고객·주문 구조에 상품 테이블을 추가한 예시입니다. 주문 하나에는 여러 상품이 포함될 수 있고, 하나의 상품은 여러 주문에 포함될 수 있으므로 연결 테이블 order_items를 둡니다.

customers

PK customer_id

name

joined_at

1  :  N

주문한다

orders

PK order_id

FK customer_id

ordered_at

1  :  N

담는다

order_items

PK item_id

FK order_id

FK product_id

quantity

N  :  1

가리킨다

products

PK product_id

name

price

점선으로 그린 order_items 가 주문과 상품의 다대다를 1:N 두 개로 풀어주는 연결 테이블입니다. FK 가 붙은 열이 옆 테이블의 PK 를 가리킵니다.

ERD 도구에서는 관계선 끝이 갈라진 형태로 표시되기도 합니다. 이를 까마귀발 표기법(Crow's Foot)이라고 하며, 갈라진 쪽은 여러 개(N), 선 하나로 끝나는 쪽은 하나(1)를 의미합니다.

읽는 순서

ERD를 검토할 때는 다음 항목을 순서대로 확인합니다. 다른 사람이 작성한 ERD를 이해하거나 설계를 점검할 때 동일하게 적용할 수 있습니다.

이 개체는 무엇을 나타내는가. 테이블 이름과 속성을 보고 어떤 데이터를 담는지 파악합니다
기본키는 무엇이고 유일성이 보장되는가. 각 행을 구분하는 값이 명확한지 확인합니다
어떤 외래키가 어떤 테이블을 참조하는가. 관계선을 따라가며 연결을 추적합니다
카디널리티가 1:1, 1:N, N:M 중 무엇인가. 실제 업무 상황과 맞는 관계인지 검토합니다

카디널리티는 요구사항 변경에 영향을 크게 받습니다. 예를 들어 고객과 주소를 1:1로 모델링하면 여러 배송지를 저장해야 하는 요구가 생겼을 때 구조를 변경해야 합니다. 관계는 현재 데이터가 아니라 업무 규칙을 기준으로 정합니다.

SQL

SQL(Structured Query Language)은 관계형 데이터베이스의 구조와 데이터를 정의·조회·조작하는 표준 언어입니다. PostgreSQL, MySQL, Oracle 등 DBMS마다 세부 문법은 다르지만 SELECT, JOIN 같은 핵심 구문은 공통으로 사용됩니다.

네 가지 분류

SQL 문장은 대상에 따라 네 가지로 분류합니다. 데이터베이스 구조, 데이터, 권한, 트랜잭션 제어가 기준입니다.

DDL

Data Definition Language

테이블 구조를 정의합니다

CREATE ALTER DROP

DML

Data Manipulation Language

데이터를 조회하고 조작합니다

SELECT INSERT UPDATE DELETE

DCL

Data Control Language

권한을 관리합니다

GRANT REVOKE

TCL

Transaction Control Language

작업을 확정하거나 취소합니다

COMMIT ROLLBACK

실습에서는 DML, 특히 SELECT를 가장 자주 사용합니다. 데이터 조회는 애플리케이션과 운영 환경에서 반복적으로 수행되는 작업입니다.

SELECT

SELECT는 조회할 열과 대상 테이블을 지정하는 구문입니다.

SELECT name, email
FROM ecom.customers;

위 쿼리는 customers 테이블에서 name과 email 열을 조회합니다. ecom.은 스키마 이름입니다. 스키마는 데이터베이스 객체를 논리적으로 구분하고, 이름 충돌과 권한 관리를 지원합니다.

SELECT *는 모든 열을 조회합니다. 운영 코드에서는 필요한 열만 명시하는 편이 좋습니다. 스키마 변경에 따른 결과 변화를 줄이고, 불필요한 데이터 전송을 피할 수 있습니다.

SELECT name

무엇을

FROM customers

어디서

WHERE ...

어떤 행만

ORDER BY ...

어떤 순서로

LIMIT 10

몇 개만

세미콜론(;)은 SQL 문장의 끝을 나타냅니다. 도구 설정에 따라 단일 문장은 생략할 수 있지만, 여러 문장을 실행할 때는 구분자로 필요합니다.

WHERE로 조건 걸기

WHERE는 조건에 맞는 행만 조회하도록 필터링합니다.

SELECT name, email
FROM ecom.customers
WHERE joined_at >= '2025-01-01';

위 쿼리는 2025년 1월 1일 이후에 가입한 고객을 조회합니다. 비교 연산자(=, >, <, >=, <=, <>)와 논리 연산자(AND, OR, NOT)를 조합할 수 있습니다.

문자열과 날짜 리터럴은 홑따옴표로 감쌉니다. PostgreSQL에서 겹따옴표는 식별자에 사용하므로 값에 사용하면 오류가 발생할 수 있습니다.

조건	쓰는 법	뜻
범위	`BETWEEN 10 AND 20`	10 이상 20 이하 (양 끝 포함)
목록	`IN ('서울', '부산')`	둘 중 하나와 같음
부분 일치	`LIKE '김%'`	김으로 시작 (`%`는 아무 글자 여러 개)
빈 값	`IS NULL`	값이 없음

= NULL은 NULL 값을 비교하는 방식으로 사용할 수 없습니다. NULL과의 비교 결과는 참이나 거짓이 아닌 UNKNOWN이므로 조회 결과가 0건이 될 수 있습니다. NULL 값을 찾을 때는 IS NULL, NULL이 아닌 값을 찾을 때는 IS NOT NULL을 사용합니다.

해석되는 순서

SQL의 작성 순서와 논리적 처리 순서는 다릅니다. 처리 순서를 이해하면 별칭과 집계 관련 오류를 분석하는 데 도움이 됩니다.

FROM

WHERE

GROUP BY

SELECT

ORDER BY

LIMIT

SELECT 가 네 번째로 처리되는 것이 중요합니다. SELECT 에서 붙인 별칭은 그때까지 존재하지 않으므로 WHERE 에서 쓸 수 없고, ORDER BY 에서는 쓸 수 있습니다.

JOIN

JOIN은 공통 열을 기준으로 두 개 이상의 테이블을 하나의 결과 집합으로 결합하는 구문입니다. 정규화로 분리한 데이터는 조회 목적에 따라 JOIN으로 결합합니다.

SELECT c.name, o.item
FROM ecom.customers c
JOIN ecom.orders o
  ON c.customer_id = o.customer_id;

customers 뒤의 c와 orders 뒤의 o는 별칭입니다. 두 테이블에 customer_id처럼 같은 이름의 열이 있으면 c., o.로 소속 테이블을 명시해야 합니다.

ON에는 테이블을 연결할 조건을 지정합니다. 위 쿼리는 같은 customer_id를 가진 행을 결합하므로, 고객 정보는 해당 고객의 주문 건수만큼 결과에 나타납니다.

customers

customer_id

name

보라

도라

orders

customer_id

item

키보드

마우스

ON c.customer_id = o.customer_id

▼

JOIN 결과

name

item

보라

키보드

보라

마우스

보라의 이름은 주문이 두 건이므로 두 행에 나타납니다. 도라는 주문이 없으므로 INNER JOIN 결과에 포함되지 않습니다.

JOIN의 종류

주문이 없는 고객까지 조회해야 한다면 다른 JOIN 유형을 사용해야 합니다. JOIN 유형은 어느 테이블의 행을 결과에 유지할지에 따라 구분됩니다.

종류	남는 행	쓰는 상황
`INNER JOIN`	양쪽에 짝이 있는 행만	기본값. `JOIN`만 적으면 이것입니다
`LEFT JOIN`	왼쪽 테이블은 전부, 오른쪽은 짝이 있을 때만	주문이 없는 고객도 목록에 넣을 때
`RIGHT JOIN`	오른쪽 테이블은 전부	`LEFT`로 순서를 바꿔 쓰는 경우가 많습니다
`FULL OUTER JOIN`	양쪽 전부	어느 쪽에만 있는 데이터를 찾아낼 때

-- 주문이 없는 고객도 함께 조회
SELECT c.name, o.item
FROM ecom.customers c
LEFT JOIN ecom.orders o
  ON c.customer_id = o.customer_id;

LEFT JOIN을 사용하면 도라도 결과에 포함되고, 주문이 없는 경우 item은 NULL입니다. 후속 집계나 계산에서는 NULL 값을 고려해야 합니다.

실습 환경

실습에서는 PostgreSQL을 데이터베이스로, DBeaver를 클라이언트 도구로 사용합니다. PostgreSQL은 데이터를 저장하고 SQL을 처리하는 서버이며, DBeaver는 서버에 접속해 SQL을 실행하고 결과를 표시하는 클라이언트입니다.

PostgreSQL: 오픈소스 관계형 DBMS입니다. 표준 SQL 지원이 넓어 학습과 실무 환경에서 많이 사용됩니다
DBeaver: 여러 DBMS에 연결할 수 있는 데이터베이스 클라이언트입니다. ERD 생성 기능으로 테이블 관계를 확인할 수 있습니다

오류 메시지에는 원인 분석에 필요한 정보가 포함됩니다. SQL 오류는 대개 오류 위치와 토큰을 알려줍니다. column "x" does not exist는 열 이름을, relation "y" does not exist는 테이블 이름과 스키마 접두어를 확인해야 한다는 의미입니다.

정리하면

ERD: 개체·속성·관계선·카디널리티 네 가지로 그립니다. 개체가 테이블, 속성이 열이 되니 그림과 코드가 그대로 대응합니다
SQL 분류: 구조는 DDL, 데이터는 DML, 권한은 DCL, 확정과 취소는 TCL
SELECT: 적는 순서와 처리 순서가 다릅니다. FROM → WHERE → SELECT → ORDER BY
JOIN: 짝이 있는 행만 볼 때는 INNER, 한쪽을 전부 남길 때는 LEFT
NULL: = NULL은 조용히 0건을 돌려줍니다. IS NULL을 씁니다

한 줄 정리: ERD로 데이터 구조를 설계하고, DDL로 테이블을 생성합니다. SELECT와 WHERE로 데이터를 조회하고, JOIN으로 여러 테이블의 데이터를 결합합니다.

참고

PostgreSQL 공식 문서: Queries (SELECT · JOIN)
PostgreSQL 공식 문서: Comparison Functions and Operators
PostgreSQL 공식 문서: Schemas
DBeaver: ERD 기능 문서

다음 글에서는 서비스 규모에서 관계형 데이터베이스의 한계를 검토하고, 벡터 DB 같은 대안을 선택하는 기준을 정리합니다.

JavaScript 비동기 처리| 이벤트 루프, Promise, async/await, Fetch

boradora — Sun, 26 Jul 2026 20:56:38 +0900

작업일2026. 07

이벤트 루프 Promise async / await Fetch JSON 모듈

서버가 하는 일의 대부분은 기다리는 것입니다. DB 응답을 기다리고, 외부 API 응답을 기다리고, 모델 추론 결과를 기다립니다. 그 기다림을 어떻게 다루느냐가 서버가 버티는 요청 수를 결정합니다.

비동기와 모듈은 직무를 가리지 않고 필요한 부분입니다.
화면을 만들든 서버를 만들든, 무언가를 기다렸다가 결과를 받아 처리하는 일은 똑같이 일어납니다.

JavaScript를 브라우저에서 화면 움직이는 언어로만 알고 있으면 이 부분이 왜 중요한지 잘 안 보입니다. 그런데 비동기 처리와 모듈 시스템은 언어를 옮겨도 그대로 따라오는 개념입니다. Python의 asyncio나 Java의 CompletableFuture로도 같은 문제를 풀 수 있습니다. JavaScript는 그 개념이 문법에 가장 노골적으로 드러나 있어서 처음 이해하기에 좋습니다.

그래서 이 글에서는 화면을 다루는 부분은 빼고, 서버에서 데이터를 주고받을 때 쓰는 것을 중심으로 정리했습니다. DOM 조작이나 브라우저 저장소는 다루지 않겠습니다.

앞 글에서 정리한 HTTP 요청과 응답을 이번엔 코드로 직접 주고받아 보겠습니다.

왜 비동기인가

JavaScript는 한 번에 하나의 작업만 실행하는 싱글 스레드입니다. 만약 DB 조회나 외부 API 호출처럼 시간이 오래 걸리는 작업을 끝날 때까지 기다린다면, 그 동안 다른 요청은 처리하지 못합니다. 서버에서 오래 걸리는 작업 대부분은 CPU 연산이 아니라 I/O를 기다리는 시간입니다. 비동기 처리는 이런 작업을 요청한 뒤 기다리지 않고 다른 작업을 먼저 수행하며, 작업이 완료되면 이벤트 루프가 다시 실행 순서를 조정해 이어서 처리합니다.

동기: 앞 작업이 끝나야 다음 작업이 시작됩니다

요청 A

DB 대기 200ms

요청 B

DB 대기 200ms

요청 C

DB 대기 200ms

총 600ms

비동기: 기다리는 동안 다음 요청을 받습니다

요청 A

DB 대기 200ms

요청 B

DB 대기 200ms

요청 C

DB 대기 200ms

총 200ms

동기 방식은 요청마다 대시 시간이 누적되지만, 비동기 방식은 기다리는 시간을 겹쳐 사용해 다른 요청을 처리합니다.

이벤트 루프

그럼 기다리던 작업이 끝났을 때 결과는 어떻게 돌아올까요. 이 흐름을 관리하는 것이 이벤트 루프입니다.

① 콜 스택

지금 실행 중인 코드가 쌓이는 곳. 한 번에 하나만 처리합니다.

→

② 백그라운드

DB 조회·네트워크 요청·타이머를 대신 기다려 주는 곳. 여기서 시간이 흐릅니다.

→

③ 큐

끝난 작업의 후속 코드가 줄을 서는 곳.

이벤트 루프: 콜 스택이 비면 큐에서 하나를 꺼내 스택으로 올립니다. 이 확인을 계속 반복합니다.

여기서 비동기의 핵심을 이해할 수 있습니다. 콜 스택이 비어야 큐의 작업이 들어옵니다. 비동기는 시다리는 시간을 다른 요청 처리에 사용할 순 있지만, CPU가 수행하는 연산은 끝날 때까지 콜 스택을 점유하므로 다른 작업을 처리할 수 없습니다.

순서 따라가 보기

이벤트 루프를 코드로 확인해봅시다. 아래가 어떤 순서로 찍힐지 먼저 예상해 보세요.

console.log("1");
setTimeout(() => console.log("2"), 0);      // 0초인데도 바로 안 나옵니다
Promise.resolve().then(() => console.log("3"));
console.log("4");

결과는 1 → 4 → 3 → 2 입니다.

콜 스택에서 console.log("1") 을 바로 실행합니다.

출력: 1

setTimeout 과 Promise.then 은 지금 실행하지 않고 넘깁니다.

둘 다 큐에서 대기. 이때 console.log("4") 가 실행됩니다 → 출력: 4

콜 스택이 비었습니다. 큐에서 꺼낼 차례인데, Promise 쪽 줄이 먼저입니다.

출력: 3

Promise 줄이 다 비면 그제야 타이머 줄을 처리합니다.

출력: 2

처음 보면 2가 먼저 출력될 것 같지만, setTimeout(fn, 0) 은 "지금 실행"이 아니라 "나중에 실행해 달라"고 등록만 합니다. Promise 쪽 줄이 타이머 줄보다 우선입니다.

Promise

먼저 어떤 문제를 푸는지부터 보겠습니다. 함수가 DB 조회를 시작했다고 해봅시다. 결과는 200ms 뒤에나 나옵니다. 그럼 이 함수는 지금 당장 무엇을 반환해야 할까요. 빈손으로 돌려보낼 수도 없고, 200ms 동안 붙잡아 둘 수도 없습니다.

그래서 나온 답이 "결과를 담을 빈 상자를 먼저 준다"입니다. 그 상자가 Promise입니다. 호출한 쪽은 일단 상자를 받아 들고 자기 할 일을 합니다. 나중에 결과가 채워지면 그때 꺼내 쓰면 됩니다.

Promise는 비동기 작업의 결과를 나중에 알려주겠다고 약속하는 객체입니다. 결과는 아직 없습니다. 언젠가 성공하거나 실패한다는 사실만 먼저 받아 쥐는 셈입니다.

상태는 세 가지이고, 한 번 정해지면 바뀌지 않습니다.

Pending

대기

시작은 했고 아직 끝나지 않은 상태

Fulfilled

이행

성공. 결과값을 들고 있습니다

Rejected

거부

실패. 에러를 들고 있습니다

직접 만들 때는 resolve와 reject를 받습니다. 성공하면 resolve, 실패하면 reject를 부릅니다.

const myPromise = new Promise((resolve, reject) => {
  // 시간이 걸리는 작업
  if (성공) resolve(값);     // → .then() 으로 감
  else      reject(에러);    // → .catch() 로 감
});

myPromise
  .then(value => console.log(value))
  .catch(error => console.log(error));

resolve는 return이 아닙니다. 상태와 결과값만 정해 둘 뿐, 함수의 실행 흐름을 끊지 않습니다. resolve() 아래에 코드를 두면 그 코드도 실행됩니다. 끊고 싶으면 return resolve(값)처럼 직접 return을 써야 합니다.

체인을 만들 때는 return이 필요합니다

비동기 작업 세 개를 순서대로 실행해야 하면 .then()을 이어 붙입니다. 이때 안에서 return을 빼먹으면 순서가 보장되지 않습니다.

step1()
  .then(value => { return step2(value); })   // return 필수
  .then(value => { return step3(value); })
  .then(value => console.log(value))
  .catch(error => console.log(error));       // 앞의 어느 단계에서 터져도 여기로

왜 return이 있어야 하는지 짚고 가겠습니다. .then()은 앞 단계가 돌려준 값을 다음 단계로 넘겨주는 역할을 합니다. 이때 넘어온 것이 Promise면, 그게 끝날 때까지 기다렸다가 다음 .then()을 실행합니다.

return을 빼면 넘어가는 값이 undefined가 됩니다. step2()는 시작만 된 채 아무도 기다려주지 않고, 다음 .then()이 바로 실행됩니다. 그래서 step3이 step2보다 먼저 끝나는 일이 생깁니다.

.then() 안에 .then()을 중첩하는 방식은 피합니다. 들여쓰기가 깊어지고 에러 처리가 어려워집니다. 이 문제를 문법 차원에서 없앤 것이 다음에 나올 async와 await입니다.

async와 await

Promise를 사용하면 비동기 작업을 처리할 수 있지만, .then() 이 계속 이어지면 코드가 길어지고 읽기 어려워집니다.

이 문제를 해결하기 위해 나온 것이 async와 await입니다.

await는 Promise가 끝날 때까지 기다렸다가 결과값을 꺼내 줍니다. 덕분에 비동기 코드를 위에서 아래로 자연스럽게 작성할 수 있습니다.

// .then() 체인
function getUser() {
  return fetchUser()
    .then(res => res.json())
    .then(user => fetchOrders(user.id));
}

// async / await : 같은 동작
async function getUser() {
  const res  = await fetchUser();
  const user = await res.json();
  return await fetchOrders(user.id);
}

규칙은 두 가지입니다. await는 async가 붙은 함수 안에서만 쓸 수 있고, async 함수는 무엇을 반환하든 항상 Promise를 반환합니다.

async function getNumber() {
  return 42;                    // 숫자를 반환한 것 같지만
}

const result = getNumber();
console.log(result);            // Promise { 42 }   ← 숫자가 아닙니다

const value = await getNumber();
console.log(value);             // 42               ← await 를 붙여야 꺼내집니다

그래서 async 함수를 부를 때는 await가 거의 항상 붙어 다닙니다. 이 규칙 하나만 잡고 있으면 바로 아래 함정도 같이 풀립니다.

기다리는 동안 서버는 뭘 하나

여기서 헷갈리기 쉽습니다. await를 만나면 그 자리에서 멈춘다고 했는데, 그럼 서버 전체가 멈추는 걸까요. 아닙니다. 멈추는 것은 그 함수 하나뿐입니다.

조금 더 정확히 말하면 이렇습니다. await를 만나는 순간 JavaScript는 그 함수의 남은 부분을 "결과 오면 이어서 할 일"로 접어서 큐에 맡겨 두고, 콜 스택에서 빠져나옵니다. 스택이 비었으니 그 사이에 들어온 다른 요청을 처리할 수 있습니다. 그러다 결과가 도착하면, 접어뒀던 나머지가 큐에서 꺼내져 멈췄던 자리부터 이어집니다.

앞에서 본 이벤트 루프가 하는 일이 바로 이겁니다. await는 문법만 동기처럼 보일 뿐 하는 일은 여전히 비동기입니다. 읽기 쉬우라고 모양만 바꾼 것이지, 서버를 멈춰 세우는 게 아닙니다.

에러 처리

.catch() 대신 try / catch를 씁니다. 동기 코드와 같은 방식이라 읽기 편합니다.

async function getUser(id) {
  try {
    const res  = await fetch(`/api/users/${id}`);
    const user = await res.json();
    return user;
  } catch (error) {
    console.error("사용자 조회 실패:", error);
    throw error;             // 삼키지 말고 위로 올립니다
  }
}

await를 빼먹으면 조용히 망가집니다. await 없이 부르면 결과값이 아니라 Promise 객체가 그대로 들어옵니다. 에러도 try / catch에 안 잡힙니다. undefined가 찍히는데 원인을 못 찾겠다면 await부터 확인해 보세요.

동시에 실행하기

await를 줄줄이 쓰면 앞의 것이 끝나야 다음이 시작됩니다. 서로 관계없는 작업이라면 이건 시간 낭비입니다. 백엔드에서 외부 API 여러 개를 부를 때 특히 그렇습니다.

// 순차 : 300ms (100 + 100 + 100)
const a = await fetchA();
const b = await fetchB();
const c = await fetchC();

// 병렬 : 100ms (셋을 동시에 시작하고 다 끝나기를 기다림)
const [a, b, c] = await Promise.all([fetchA(), fetchB(), fetchC()]);

순차 await 세 번

A 100ms

B 100ms

C 100ms

300ms

Promise.all 로 병렬

A 100ms

B 100ms

C 100ms

100ms

메서드	동작	쓰는 곳
`Promise.all`	하나라도 실패하면 즉시 전체 실패	전부 성공해야 의미 있을 때
`Promise.allSettled`	실패해도 끝까지 기다리고 결과를 모두 반환	일부 실패를 감수할 때
`Promise.race`	가장 먼저 끝난 하나만 반환	타임아웃 걸 때

외부 API 세 곳 중 하나가 죽어도 나머지는 보여줘야 하는 상황이라면 Promise.allSettled가 맞습니다. Promise.all을 쓰면 하나 때문에 전부 날아갑니다.

Fetch로 API 호출하기

fetch()는 서버에 HTTP 요청을 보내는 함수입니다. 비동기라서 Promise를 반환합니다. 2편에서 표로 봤던 요청과 응답이 여기서는 코드로 나옵니다.

async function loadData() {
  const response = await fetch("https://api.example.com/data");
  const data     = await response.json();
  console.log(data);
}

await가 두 번 나오는 이유가 있습니다. 첫 번째는 응답 헤더가 도착할 때까지, 두 번째는 본문을 다 받아 JSON으로 파싱할 때까지 기다립니다. 2편에서 본 헤더와 바디가 따로 오는 구조가 여기 그대로 드러납니다.

404가 나도 catch로 안 갑니다

이게 fetch의 가장 헷갈리는 동작입니다.

성공으로 침

서버가 응답을 보내기만 하면 전부

404 Not Found, 500 Internal Server Error 포함

실패로 침

응답 자체가 오지 못한 경우

네트워크 끊김, DNS 조회 실패, CORS 차단

서버가 "그런 주소 없다"고 답한 것도 서버는 제대로 답한 것이라는 관점입니다. 그래서 상태 코드는 response.ok로 직접 봐야 합니다.

async function getUser(id) {
  const res = await fetch(`/api/users/${id}`);

  if (!res.ok) {                                  // 이 줄이 없으면 404를 그냥 지나칩니다
    throw new Error(`요청 실패: ${res.status}`);   // res.status 에 404, 500 이 들어옵니다
  }

  return await res.json();
}

2편에서 본 상태 코드가 res.status에 그대로 들어옵니다. 4xx면 내가 보낸 요청을, 5xx면 상대 서버를 의심하세요.

POST로 보낼 때

기본값은 GET입니다. 데이터를 보내려면 옵션을 넘깁니다.

const res = await fetch("/api/users", {
  method: "POST",
  headers: { "Content-Type": "application/json" },   // 바디 형식을 알려줍니다
  body: JSON.stringify({ name: "보라도라", role: "backend" })
});

body에 객체를 그대로 넣으면 안 됩니다. 네트워크로는 문자열만 오갑니다. 그래서 JSON.stringify()로 바꿔서 실어 보내고, 받는 쪽은 JSON.parse()로 되돌립니다.

함수	방향	결과
`JSON.stringify(obj)`	객체 → 문자열	`'{"name":"보라도라"}'`
`JSON.parse(str)`	문자열 → 객체	`{ name: "보라도라" }`

res.json()이 이 JSON.parse를 대신 해줍니다. 응답이 JSON이 아니면 파싱에 실패하며 에러가 발생합니다.

모듈

코드가 늘어나면 파일을 나누게 됩니다. 모듈은 파일마다 독립된 공간을 주고, 필요한 것만 export와 import로 주고받게 하는 방식입니다. ES6부터 표준입니다.

// math.js : 내보내기
export function add(a, b) {
  return a + b;
}

// main.js : 가져오기
import { add } from './math.js';
const result = add(2, 3);

파일 분리와 모듈의 차이

예전처럼 <script src="file.js">로 파일만 나누면 모든 파일이 전역 공간을 같이 씁니다. 파일은 분리했지만 변수는 한 통에 담겨 있는 셈이라, 이름이 겹치면 그대로 충돌합니다.

일반 외부 JS 전역 공유

// a.js
const count = 10;

// b.js
const count = 20; ← 충돌

모듈 파일마다 격리

// a.js
const count = 10;

// b.js
const count = 20; ← 문제 없음

구분	일반 외부 JS	모듈
스코프	전역 공유	파일마다 격리
이름 충돌	위험 (같으면 버그)	없음
소통 방식	전역 변수를 통해 간접적으로	`import` / `export`로 명시적으로
실행 시점	태그를 만나는 즉시	문서를 다 읽은 뒤 (defer)

Named와 Default

내보내는 방식은 두 가지입니다. 섞어 쓸 수도 있습니다.

방식	문법	특징
Named	`export const foo = ...` `import { foo } from './m.js'`	여러 개 내보낼 수 있고 이름이 명확합니다. 대신 이름을 정확히 써야 합니다.
Default	`export default foo` `import 아무이름 from './m.js'`	가져올 때 이름을 자유롭게 붙일 수 있습니다. 대신 한 파일에 하나만 가능합니다.

// 섞어 쓰기 : 주요 기능은 default, 보조 기능은 named
export const helper = () => {};
export default mainFunction;

import mainFunction, { helper } from './module.js';

둘 중 어느 쪽을 쓸지는 파일의 역할에 따라 결정하면 됩니다. 로그인만 처리하거나 데이터베이스 연결처럼 하나의 대표 기능을 담은 파일이라면 Default, 반면 날짜 변환, 문자열 처리 등 여러 함수나 변수를 함께 관리하는 파일이라면 Named 를 사용하는 경우가 많습니다.

정리하면

서버에서 데이터를 다룰 때 기준으로 골라 담으면 이렇습니다.

비동기가 벌어주는 건 기다림(I/O)입니다. CPU를 오래 사용하는 작업은 async를 붙여도 다른 요청을 막습니다.
await를 줄줄이 쓰면 그 시간이 전부 더해지기 때문에, 서로 상관없는 호출이라면 Promise.all로 함께 실행하세요.
fetch는 HTTP 404나 500을 받아도 성공적으로 응답을 받은 것으로 처리합니다. res.ok로 직접 확인해야 합니다.
네트워크로는 문자열만 오갑니다. 보낼 땐 JSON.stringify, 받을 땐 res.json().
모듈은 파일을 나누는 게 아니라 공간을 나눕니다. 그래서 같은 이름을 써도 안 부딪힙니다.

한 줄 정리: 서버는 기다리는 시간이 대부분이고 → 이벤트 루프가 그 시간을 겹쳐 쓰게 해주며 → Promise와 async/await로 그 흐름을 코드에 적고 → fetch와 JSON으로 주고받고 → 모듈로 파일을 나눕니다.

참고

웹 개발을 위한 네트워크 기초

boradora — Sun, 26 Jul 2026 15:54:40 +0900

작업일2026. 07

TCP/IP HTTP DNS IP 주소 URL HTTPS

주소창에 주소를 치고 엔터를 누르면 1초도 안 돼서 페이지가 뜹니다. 그 짧은 사이에 컴퓨터들끼리 어떤 대화가 오가는지, 순서대로 따라가 보려고 합니다.

주소창에 URL을 입력하고 엔터를 누르면 무슨 일이 일어날까요?
이 질문 하나를 따라가다 보면 네트워크 기초를 이해할 수 있습니다.

요즘은 AI에게 시켜서 코드를 만드는 바이브 코딩이 흔해졌습니다. 덕분에 화면 하나 띄우는 일은 확실히 빨라졌지만 막상 에러가 나면 어디부터 봐야 할지 막막할 때가 있습니다. 404와 500이 무엇이 다른지, 주소창의 https는 어떤 역할을 하는지조차 헷갈리는 경우가 많습니다.

웹 개발은 보통 HTML부터 배웁니다. 하지만 그 HTML 파일이 어떻게 서버에서 브라우저까지 전달되는지는 쉽게 지나치곤 합니다. 프론트엔드든 백엔드든 결국 우리가 만드는 것은 네트워크를 통해 오가는 데이터입니다. 그래서 이번 글에서는 웹 개발을 위해 꼭 알아야할 네트워크 기초를 정리해보겠습니다.

인터넷과 웹

인터넷은 전 세계 컴퓨터를 연결한 물리적인 통신망입니다. 케이블, 광섬유, 공유기, 라우터 같은 장비로 이루어진 실제 네트워크를 말합니다. 웹, 이메일, 파일 전송 모두는 이 인터넷 위에서 동작하는 서비스입니다. 즉, 웹(WWW)은 인터넷 자체가 아니라 인터넷을 이용하는 여러 서비스 중 하나입니다.

서비스 (Application)

웹 (WWW)

HTTP

이메일

SMTP · IMAP

파일 전송

FTP

원격 접속

SSH

▼

인프라 (Infrastructure)

인터넷

케이블 · 라우터 · 스위치 · 컴퓨터

인터넷은 깔려 있는 망이고, 웹은 그 위에서 도는 서비스 중 하나입니다.

구분	인터넷 (Internet)	웹 (World Wide Web)
정체	컴퓨터를 연결한 통신망 (인프라)	정보를 공유하는 공간 (서비스)
구성	케이블, 라우터, 스위치 (하드웨어)	HTML, HTTP, URL, 브라우저 (소프트웨어)
기준 계층	하위 계층 (인터넷·전송 계층)	최상위 계층 (응용 계층)
관계	웹을 포함한 모든 서비스의 기반	인터넷 위 수많은 서비스 중 하나

흐름을 보면 이렇습니다

지금의 인터넷이 어떻게 만들어졌는지도 간단히 짚고 가겠습니다.

1960년대

미국 국방부 ARPANET 프로젝트

떨어진 연구소 컴퓨터를 연결해 본 것이 시작

1970~80년대

TCP/IP 프로토콜 개발

서로 다른 망을 하나로 묶는 공통 규칙이 생김

1990년대

WWW 등장 → 대중화

1989년 팀 버너스리가 www를, 1991년 HTML을 만듦

2000년대~

모바일 · 클라우드 · IoT

연결되는 기기의 종류가 폭발적으로 늘어남

웹을 이루는 세 가지

웹은 크게 세 가지로 이루어져 있습니다. 어떻게 보낼지, 어디로 보낼지, 무엇을 보낼지입니다. 앞의 두 가지가 이번 글의 내용이고, 마지막 HTML은 다음 글에서 정리하겠습니다.

어떻게 보낼까

HTTP

브라우저와 서버가 대화하는 규칙

어디로 보낼까

URL

자원이 어디 있는지 가리키는 주소

무엇을 보낼까

HTML

다음 글에서 다룹니다

인터넷을 이루는 세 가지

그럼 인터넷이라는 망은 무엇으로 만들어져 있을까요. 크게 세 가지입니다.

종단 시스템: 데이터를 만들거나 소비하는 양 끝의 기기. 요청하는 쪽이 클라이언트(노트북, 스마트폰), 응답하는 쪽이 서버입니다. 각각 IP 주소를 받아 식별됩니다.
전송 매체: 신호가 실제로 지나가는 길. 광케이블·LAN선 같은 유선과 Wi-Fi·5G 같은 무선이 있습니다.
네트워크 장비: 데이터를 다음 목적지로 넘겨주는 중계기. 라우터가 서로 다른 네트워크를 잇고 경로를 정하며, 스위치가 한 네트워크 안의 기기들을 연결합니다.

통신을 계층으로 나눈 이유

프로토콜은 데이터를 주고받기 위해 미리 정해둔 규칙입니다. 그런데 이 규칙을 하나로 묶어버리면 문제가 생기게 됩니다. 전기 신호를 보내는 방식, 데이터를 목적지까지 전달하는 방식, 오류를 복구하는 방식이 전부 얽혀 있으면 한 부분만 바뀌어도 전체를 수정해야 하기 때문입니다.

그렇기 때문에 기능을 계층(Layer)으로 나눴습니다. 각 계층은 자신의 역할만 수행하고, 다른 계층의 동작 방식은 신경 쓰지 않습니다. 계층 구조를 이해하기 위해 사용하는 것이 OSI 7계층이고, 실제 인터넷은 TCP/IP 4계층을 기반으로 동작합니다.

계층	하는 일	대표 프로토콜	데이터 단위(PDU)
Application	사용자 앱과 직접 대화	HTTP, DNS, FTP, SMTP	Message
Transport	목적지까지 정확하게 전달	TCP, UDP	Segment / Datagram
Internet	최적 경로를 찾고 IP 주소 부여	IP, ICMP	Packet
Network Access	케이블·랜카드로 비트 단위 전송	Ethernet, Wi-Fi	Frame → Bit

맨 아래 Network Access 계층은 OSI 모델의 물리 계층과 데이터 링크 계층을 하나로 합친 것입니다. 유선 Ethernet과 무선의 Wi-Fi(IEEE 802.11)가 여기에 속하며, 데이터를 실제 케이블이나 무선 신호를 통해 전송하는 역할을 합니다.

층마다 붙는 헤더, 캡슐화

데이터는 위에서 아래로 내려가면서 각 층의 헤더(Header)가 하나씩 붙는데, 이 과정을 캡슐화라고 합니다. 계층마다 헤더가 달라지기 때문에 데이터를 부르는 이름도 달라지는데, 이 이름을 PDU라고 합니다. 받는 쪽에서는 아래 계층부터 헤더를 하나씩 제거하면서 원래 데이터만 남게 됩니다.

Application

데이터

Message

Transport

TCP

데이터

Segment

Internet

TCP

데이터

Packet

Network Access

Ethernet

TCP

데이터

Frame

▼ 마지막엔 0과 1의 전기 신호 (Bit) 로 케이블에 실립니다

보내는 쪽은 헤더를 붙이며 내려가고, 받는 쪽은 벗기며 올라갑니다.

IP 주소와 MAC 주소

네트워크에서는 IP 주소와 MAC 주소를 함께 사용합니다. IP 주소는 어느 네트워크에 연결되어 있는지를 타나내는 논리적 주소이고, MAC 주소는 장치 자체를 식별하는 물리적 주소입니다.

IP 주소는 인터넷에서 장치를 식별하는 논리적 주소입니다. 네트워크가 바뀌면 IP 주소도 바뀔 수 있습니다.

IPv4: 192.168.0.1처럼 점으로 구분된 32비트 주소입니다.
IPv6: 2001:0db8:85a3:0000:0000:8a2e:0370:7334처럼 콜론으로 구분된 128비트 주소로, IPv4 주소 부족 문제를 해결하기 위해 만들어졌습니다.

반면 MAC 주소는 랜카드에 부여된 영구히 기록된 물리적 주소입니다. 일반적으로 48비트, 16진수 12자리로 표기하고, 네트워크가 바뀌어도 값이 변하지 않습니다.

구분	IP 주소	MAC 주소
성격	논리적 주소 (소프트웨어가 부여)	물리적 주소 (하드웨어에 기록)
변경	네트워크가 바뀌면 같이 바뀜	바뀌지 않음
계층	Internet Layer	Network Access Layer

공인 IP와 사설 IP

집에 있는 노트북, 폰, TV가 각각 전 세계에서 유일한 주소를 가질 필요는 없습니다. 그래서 주소를 두 겹으로 씁니다. 집 안에서는 사설 IP를 쓰다가, 밖으로 나갈 때 공유기가 하나의 공인 IP로 바꿔 주는 방식입니다. 이 변환 기술을 NAT이라고 합니다.

우리 집 안 (LAN) · 사설 IP

노트북192.168.0.5

스마트폰192.168.0.6

TV192.168.0.7

공유기

NAT

→

인터넷 (WAN) · 공인 IP

203.0.113.7

밖에서 보이는 우리 집 대표 주소 하나. 세 기기가 이 주소를 나눠 씁니다.

Windows는 ipconfig /all, macOS는 ifconfig를 터미널에 입력해보면 확인해볼 수 있습니다.

$ ifconfig en0

en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	ether ba:91:a7:**:**:**                    ← MAC 주소 (물리)
	inet 192.168.219.46 netmask 0xffffff00     ← 사설 IP (논리)
	status: active

ether 옆이 랜카드에 박혀 있는 MAC 주소이고, inet 옆이 공유기가 나눠준 사설 IP입니다. 이 사설 IP는 카페 와이파이로 옮기면 바뀌지만, MAC 주소는 그대로입니다.

여기서 한 번 더: 이 상태로 브라우저에 "what is my ip"를 검색해 보세요. 거기 뜨는 숫자가 공인 IP입니다. 터미널에서 본 192.168.x.x와 값이 전혀 다를 텐데, 그 사이에서 변환을 해주고 있는 것이 바로 NAT입니다.

궁금!사설 IP는 왜 하필 192.168로 시작할까?

아무 주소나 내부용으로 쓰면 진짜 공인 IP와 겹치기 때문에, 처음부터 내부 전용으로 떼어 둔 대역이 있습니다. 10.0.0.0~, 172.16.0.0~, 192.168.0.0~ 세 덩어리입니다.

이 중 192.168로 시작하는 대역이 가장 작아서 가정용 공유기 기본값으로 굳어졌습니다. 큰 회사나 학교에서는 기기가 많아 10.으로 시작하는 대역을 쓰는 경우가 많습니다.

URL 구조

URL은 자원이 어디에 있는지를 알려주는 주소 규약입니다. 그냥 한 줄처럼 보이지만, 뜯어보면 다섯 조각으로 나뉩니다.

https://

프로토콜

www.example.com

도메인

:443

포트

/blog/post.html

경로

?id=1

쿼리

프로토콜: 어떤 방식으로 통신할지 (http / https)
도메인: 서버의 위치. DNS가 IP 주소로 바꿔 줍니다.
포트: 서버의 어느 문으로 들어갈지. HTTP는 80, HTTPS는 443이 기본이라 보통 생략합니다.
경로: 서버 안에서 자원이 있는 위치
쿼리: 서버에 넘기는 값 (key=value)

맨 뒤의 쿼리, 즉 물음표(?) 뒤에 붙는 부분이 GET 방식이 데이터를 실어 보내는 자리입니다. 뒤에서 한 번 더 다루겠습니다.

궁금!포트 번호 80과 443은 누가 정한 걸까?

포트 번호는 IANA라는 기관에서 등록·관리합니다. HTTP는 80번, HTTPS는 443번처럼 서비스별 기본 포트가 정해져 있어, 브라우저는 URL에 포트 번호가 없으면 이를 자동으로 사용합니다.

다만 강제 규칙은 아니므로 서버는 다른 포트도 사용할 수 있습니다. 예: https://example.com:8443

이름을 주소로 바꾸는 DNS

우리는 naver.com을 기억하지 223.130.192.247을 외우지 않습니다. 하지만 컴퓨터는 IP 주소로만 통신합니다. 이 간극을 메우는 것이 DNS(Domain Name System)입니다.

DNS는 사람이 읽는 도메인 이름을 컴퓨터가 쓰는 IP 주소로 번역해 주는 시스템입니다. 브라우저는 URL에 접속하기 전, 먼저 DNS를 통해 해당 도메인의 IP 주소를 찾습니다.

nslookup 명령어로 직접 확인할 수 있습니다. Windows와 macOS 모두 같습니다.

$ nslookup naver.com

Server:		203.248.252.2
Address:	203.248.252.2#53

Non-authoritative answer:
Name:	naver.com
Address: 223.130.192.248
Name:	naver.com
Address: 223.130.200.219
Name:	naver.com
Address: 223.130.200.236
Name:	naver.com
Address: 223.130.192.247

위쪽 Server는 DNS 조회를 처리한 서버의 주소이고, 아래쪽 Address는 naver.com의 IP입니다. IP가 여러개인 이유는 트래픽을 분산하기 위해 서버를 여러 대 운영하기 때문이며, 접속을 할 때마다 다른 IP로 연결될 수 있습니다.

궁금!DNS 서버는 누가 관리할까?

최상위인 루트 DNS는 ICANN이라는 국제기구가 총괄하고, 실제 서버는 전 세계 12개 기관이 나눠 운영합니다. 그 아래 .com, .kr 같은 최상위 도메인은 각각 담당 기관이 따로 있습니다. .kr은 한국인터넷진흥원(KISA)이 맡고 있습니다.

우리가 평소에 질의하는 것은 이 서버들이 아니라, 통신사가 자동으로 물려주는 DNS 서버입니다. 구글의 8.8.8.8이나 클라우드플레어의 1.1.1.1로 직접 바꿔 쓸 수도 있는데, 이걸 바꾸면 접속 속도가 달라지기도 합니다.

TCP와 UDP

주소를 찾았다면 이제 데이터를 보낼 차례입니다. Transport 계층에는 성격이 다른 프로토콜 TCP와 UDP가 있습니다.

TCP는 연결 지향적입니다. 데이터를 보내기 전에 양쪽이 먼저 연결을 확립하는 3-Way Handshake를 거칩니다.

클라이언트

서버

SYN (연결 요청)

SYN + ACK (수락 응답 + 연결 요청)

ACK (연결 확립)

클라이언트

서버

연결 확립: 이제 데이터를 주고받습니다

TCP는 연결을 맺은 뒤 데이터 유실 시 재전송하고, 전달 순서도 보장합니다. 대신 확인 절차가 있어 UDP보다 느리고 오버헤드가 큽니다.

반대로 UDP는 비연결형입니다. 별도 합의 없이 데이터를 보내며, 수신 여부나 순서를 보장하지 않습니다. 그만큼 가볍고 빠르지만 데이터 유실이나 순서 변경은 직접 처리해야 합니다.

구분	TCP	UDP
연결	연결 지향 (핸드셰이크 O)	비연결형 (핸드셰이크 X)
신뢰성	높음 (재전송·순서 보장)	낮음 (유실돼도 그대로)
속도	느리고 오버헤드 큼	빠르고 가벼움
쓰는 곳	웹(HTTP), 파일 전송(FTP), 이메일(SMTP)	실시간 스트리밍, 온라인 게임

영상 통화에서 한 프레임이 유실되더라도 그냥 넘어가는 편이 낫습니다. 그 프레임 하나를 재전송받느라 통화가 1초 밀리면 더 불편하기 때문입니다. 이러한 실시간 통신에는 UDP가 적합한 것이죠.

현재 내 컴퓨터의 네트워크 연결과 열린 포트는 다음 명령어로 확인할 수 있습니다.

Windows는 netstat -an, macOS는 lsof -i TCP -P -n입니다.

$ lsof -i TCP -P -n

COMMAND     PID   FD   TYPE   NAME
rapportd    668   10u  IPv4   TCP *:62753 (LISTEN)
Google      921   45u  IPv4   TCP 192.168.219.46:51234->142.250.76.100:443 (ESTABLISHED)

LISTEN은 그 포트를 열어두고 요청을 기다리는 상태입니다. ESTABLISHED는 실제로 연결이 맺어져 데이터를 주고받는 상태입니다. 두 번째 줄은 내 사설 IP가 구글 서버의 443번 포트에 연결된 것을 보여 줍니다, 즉 TCP의 3-Way Handshake가 끝난 상태입니다.

HTTP 요청과 응답

DNS로 주소를 찾고, TCP로 연결도 맺었다면 이제 서버에 원하는 자원들 달라고 말할 차례입니다. 이때 사용하는 규칙이 바로 HTTP입니다.

HTTP는 브라우저와 서버가 자원(HTML, CSS, JS, 이미지)을 주고받기로 약속한 규칙입니다. 클라이언트가 요청을 보내면 서버가 응답을 돌려주는 구조입니다.

요청 (Request) 클라이언트 → 서버

Request Line

GET /index.html HTTP/1.1

Headers

Host: example.com
User-Agent: Mozilla/5.0

Body

서버로 보낼 데이터 (GET은 보통 비어 있음)

응답 (Response) 서버 → 클라이언트

Status Line

HTTP/1.1 200 OK

Headers

Content-Type: text/html
Server: nginx

Body

<html>...</html>

요청과 응답 모두 첫 줄 · 헤더 · 바디의 세 부분으로 되어 있습니다. 첫 줄에는 요청의 목적이나 응답 결과, 헤더에는 부가 정보, 바디에는 실제 데이터가 담깁니다.

메서드: 무엇을 하고 싶은지

요청 첫 줄의 메서드는 요청 목적을 나타냅니다.

구분	GET	POST
목적	자원을 조회	자원을 생성·수정
데이터 위치	URL 뒤 쿼리스트링에 노출	Body에 담김
예	검색 결과 보기, 게시글 읽기	회원가입, 글쓰기, 로그인

이 외에 PUT, PATCH, DELETE, HEAD, OPTIONS 등이 있으며, REST API에서 자주 사용합니다.

상태 코드: 결과가 어땠는지

응답 첫 줄에는 상태 코드가 붙습니다. 앞자리 숫자만으로도 응답 결과를 대략 알 수 있습니다.

1xx

정보

처리 중

2xx

성공

200 OK
201 Created

3xx

리다이렉션

304 Not Modified

4xx

클라이언트 잘못

400 Bad Request
404 Not Found

5xx

서버 잘못

500 Internal
Server Error

404와 500을 구분하면 디버깅이 빨라집니다. 404는 요청한 주소가 없다는 뜻이므로 내가 보낸 URL을 확인하고, 500은 서버 내부의 오류이므로 서버 로그를 봐야 합니다.

웹 서버

요청을 받아 HTML·CSS·JS·이미지를 돌려주는 프로그램을 웹 서버라고 합니다. 대표적으로 다음 세 가지를 많이 사용합니다.

웹 서버	특징
Apache	1995년 등장. 오픈소스이고 모든 운영체제에서 동작합니다.
Nginx	이벤트 기반 비동기 처리로 가볍고 빠릅니다. 지금 가장 많이 쓰입니다.
Microsoft IIS	Windows 전용. Windows 생태계에 최적화돼 있습니다.

HTTP와 HTTPS

HTTPS는 HTTP에 SSL/TLS 암호화를 적용한 것입니다. 다만 모든 정보가 암호화되는 것은 아니므로, 무엇이 보호되고 드러나는지 알아둘 필요가 있습니다.

공개됨

목적지 주소: 도메인과 IP

어떤 사이트에 접속했는지는 드러납니다

암호화됨

요청·응답의 헤더와 바디 전부

그 안에서 무엇을 주고받았는지는 가려집니다

오늘날 HTTPS는 웹의 기본 표준입니다. 적용하지 않으면 Chrome 같은 브라우저에서 "안전하지 않음" 경고가 표시될 수 있습니다.

엔터를 누르면 일어나는 일

이제 처음의 질문으로 돌아가겠습니다. 주소창에 URL을 입력하고 엔터를 누르면, 브라우저는 다음 순서로 동작합니다.

사용자

브라우저

DNS 서버

웹 서버

URL 입력 (www.example.com)

DNS 요청 (www.example.com)

IP 주소 응답 (93.184.216.34)

TCP 연결 수립 요청 (3-Way Handshake)

TCP 연결 수립 승인 (3-Way Handshake)

HTTP 요청 전송 (GET / HTTP/1.1)

HTTP 응답 (HTML / CSS / JS)

HTML / CSS / JS 렌더링

웹 페이지 표시

사용자

브라우저

DNS 서버

웹 서버

직접 확인: 크롬에서 F12 → Network 탭을 열고 아무 사이트나 들어가 보세요. 요청 하나를 클릭하면 지금까지 이야기한 Request Header, Response Header, 상태 코드를 확인할 수 있습니다.

정리하면

마지막으로 상황에 따라 무엇을 고르면 되는지 정리하겠습니다.

TCP vs UDP: 정확한 전달이 중요하면 TCP, 실시간성이 중요하면 UDP.
HTTP vs HTTPS: 실제 서비스라면 HTTPS. 로그인·결제가 있다면 필수
GET vs POST: 조회는 GET, 값을 바꾸거나 생성·전송할 떄는 POST. ( 민감한 정보는 POST여부와 관계없이 반드시 HTTPS로 보호)

한 줄 정리: URL을 입력하면 → DNS가 IP를 찾고 → TCP가 연결을 맺고 → HTTP로 요청과 응답을 주고받아 → 브라우저가 화면에 그립니다. 웹 통신은 이 다섯 단계입니다.

참고

MDN: HTTP 개요
MDN: DNS
W3Schools: HTTP Methods
roadmap.sh: Frontend Beginner Roadmap

다음 글에서는 이렇게 받아온 HTML·CSS·JavaScript가 각각 무슨 일을 하는지 정리해보겠습니다.

[개발 기초 정리] HTML·CSS·JavaScript

boradora — Thu, 23 Jul 2026 09:45:24 +0900

작업일2026. 07

HTML CSS JavaScript 박스 모델 Flexbox / Grid DOM 이벤트

웹페이지는 HTML, CSS, JavaScript가 함께 구성합니다. HTML은 문서 구조를 만들고, CSS는 화면 표현을 정의하며, JavaScript는 사용자 입력과 상태 변화에 대응합니다. 프론트엔드의 기본 구성을 정리했습니다.

한 줄로 먼저: HTML은 문서 구조, CSS는 화면 표현, JavaScript는 동작과 상태 처리를 담당합니다.

웹 개발을 시작하면 이 셋을 거의 동시에 배우게 됩니다. 그래서 각 기술의 역할 범위가 헷갈리기 쉽습니다. 역할을 구분해두면 React 같은 프레임워크를 배울 때도 도움이 됩니다.

HTML: 문서의 구조

HTML(HyperText Markup Language)은 태그로 문서의 구조를 정의하는 마크업 언어입니다. 프로그래밍 언어가 아니라 "이건 제목이고 저건 문단이다"라고 표시(markup)해주는 언어입니다. 브라우저는 이 표시를 읽어 화면을 그립니다.

요소와 속성

HTML의 기본 단위는 요소(Element)입니다. 시작 태그, 내용, 끝 태그로 이루어집니다.

<h1>가장 큰 제목</h1>
<p>평범한 문단입니다.</p>
<br>                    <!-- 내용이 없는 요소는 끝 태그도 없습니다 -->

요소 안에 요소를 중첩할 수 있고, 속성(Attribute)으로 추가 정보를 줍니다. 속성은 항상 시작 태그 안에 들어갑니다.

<a href="https://example.com">링크</a>
<img src="cat.jpg" alt="고양이 사진">

alt는 이미지를 표시할 수 없을 때 대체로 제공할 텍스트입니다. 스크린 리더도 이 값을 읽으므로 접근성과 SEO에 영향을 줍니다. 의미 있는 이미지는 작성하는 것이 좋습니다.

id와 class

속성	의미	개수	주 용도
`id`	고유 식별자	문서에 하나만	특정 요소를 콕 집을 때
`class`	공유 가능한 이름	여러 개 가능	같은 스타일을 묶을 때

문서의 기본 뼈대

<!DOCTYPE html>              <!-- HTML5 문서라는 선언 -->
<html lang="ko">
  <head>                     <!-- 화면에 안 보이는 문서 정보 -->
    <meta charset="UTF-8">
    <title>페이지 제목</title>   <!-- 브라우저 탭에 뜨는 이름 -->
  </head>
  <body>                     <!-- 실제로 화면에 보이는 내용 -->
    <h1>안녕하세요</h1>
  </body>
</html>

역할별 태그

분류	대표 태그	쓰임
텍스트	`h1~h6`, `p`, `span`, `strong`, `a`	제목·문단·강조·링크
목록	`ul`, `ol`, `li`	순서 없는/있는 목록
표	`table`, `thead`, `tbody`, `tr`, `th`, `td`	행과 열 데이터
폼	`form`, `input`, `label`, `button`	사용자 입력받기
미디어	`img`, `video`, `audio`	이미지·영상·소리
시맨틱	`header`, `nav`, `main`, `section`, `footer`	의미를 가진 구획

시맨틱 태그를 쓰는 이유: <div>만으로도 화면은 구성할 수 있습니다. 다만 <header>, <nav>를 사용하면 검색엔진과 스크린 리더가 콘텐츠의 역할을 더 정확히 해석할 수 있습니다. 화면은 같아도 문서의 의미 정보가 달라집니다.

Block과 Inline

요소마다 기본 배치 방식이 있습니다. 이를 알아야 width와 height의 적용 결과를 예측할 수 있습니다.

구분	Block 요소	Inline 요소
배치	혼자 한 줄 차지 (세로로 쌓임)	다른 요소와 한 줄에 나란히
크기	가로 폭을 최대로	내용 크기만큼만
width / height	적용됨	무시됨
예	`div`, `p`, `h1`, `ul`	`span`, `a`, `strong`, `img`

주의: <span> 같은 inline 요소에는 width: 200px이 적용되지 않습니다. 크기를 지정하려면 display: block 또는 inline-block으로 변경해야 합니다.

CSS: 보이는 모습

CSS(Cascading Style Sheets)는 HTML 요소를 화면에 어떻게 보여줄지 정의하는 스타일시트 언어입니다. 색, 글꼴, 간격, 위치, 레이아웃이 전부 CSS의 영역입니다.

문법과 적용 방법

p {                    /* 선택자: 누구에게 */
  color: red;          /* 속성: 값 */
  text-align: center;
}

적용 방법은 세 가지입니다. 일반적으로는 스타일과 구조를 분리하기 위해 외부 파일(External) 방식을 사용합니다.

<link rel="stylesheet" href="style.css">   <!-- 권장 -->
<style> p { color: red; } </style>         <!-- 문서 안에 -->
<p style="color:red;">…</p>                <!-- 태그에 직접, 지양 -->

선택자: 누구에게 스타일을 줄까

선택자	예시	의미
요소	`p { }`	모든 p 태그
id	`#header { }`	id가 header인 요소
class	`.menu { }`	class가 menu인 요소
자식	`div > p { }`	div의 바로 아래 p
후손	`div p { }`	div 안의 모든 p
의사 클래스	`a:hover { }`	마우스를 올린 상태

우선순위: 스타일이 안 먹을 때

여러 규칙이 같은 요소를 가리키면 충돌합니다. 이때 명시도(Specificity)가 높은 쪽이 이깁니다.

인라인 스타일  >  id  >  class · 속성 · 의사클래스  >  요소

명시도가 높은 규칙이 우선합니다. class 선택자 하나는 요소 선택자 여러 개보다 우선합니다.
명시도가 같으면 나중에 작성한 규칙이 적용됩니다. 이것이 "Cascading"의 의미입니다.

!important는 예외적으로만 사용합니다. 우선순위 문제를 임시로 덮을 수 있어 유지보수가 어려워집니다. 먼저 선택자와 적용 순서를 확인하는 편이 좋습니다.

박스 모델

CSS 레이아웃의 기본 개념입니다. 모든 HTML 요소는 네 영역으로 구성됩니다.

margin 바깥 간격

border 테두리

padding 안쪽 여백

content

실제 내용이 들어가는 자리

width 는 맨 안쪽 content 의 너비만 가리킵니다

계산 시 주의: 기본값에서 width는 content 영역만의 너비입니다. width: 300px; padding: 25px;이면 실제 차지하는 너비는 300 + 25×2 = 350px가 됩니다.

보통은 box-sizing: border-box;를 사용합니다. padding과 border를 width에 포함하므로 지정한 값으로 전체 너비를 관리할 수 있습니다.

position: 위치 잡기

값	동작	자주 쓰는 곳
`static`	기본값. 문서 흐름 그대로	거의 지정하지 않음
`relative`	원래 위치 기준으로 살짝 이동 (자리는 유지)	미세 조정, absolute의 기준점
`absolute`	가장 가까운 위치 지정 조상 기준 (문서 흐름에서 빠짐)	배지, 툴팁, 닫기 버튼
`fixed`	화면 기준 고정 (스크롤해도 안 움직임)	플로팅 버튼
`sticky`	스크롤하다 특정 지점에서 고정	상단 헤더, 목차

Flexbox와 Grid

과거에는 float로 레이아웃을 구성했지만, 현재는 Flexbox와 Grid를 주로 사용합니다.

구분	Flexbox	Grid
차원	1차원 (가로 또는 세로)	2차원 (행 과 열)
잘하는 것	한 줄 안에서 정렬·간격 배분	페이지 전체를 격자로 나누기
쓰는 곳	내비게이션 바, 카드 안 요소 정렬	전체 레이아웃, 갤러리, 대시보드

/* Flexbox: 가운데 정렬 */
.container {
  display: flex;
  justify-content: center;   /* 메인 축(가로) 정렬 */
  align-items: center;       /* 교차 축(세로) 정렬 */
}

/* Grid: 2열 레이아웃 */
.layout {
  display: grid;
  grid-template-columns: 1fr 2fr;   /* 1:2 비율로 두 열 */
  gap: 20px;
}

둘은 함께 사용할 수 있습니다. 예를 들어 페이지 레이아웃에는 Grid, 내부 요소 정렬에는 Flexbox를 사용할 수 있습니다.

JavaScript: 페이지의 동작

JavaScript는 웹페이지의 동작과 로직을 구현하는 프로그래밍 언어입니다. HTML 콘텐츠와 CSS 스타일을 변경하고, 사용자 입력에 반응할 수 있습니다.

먼저 세 가지 성격을 알아두면 쉽게 이해할 수 있습니다.

인터프리터: 컴파일 없이 브라우저가 한 줄씩 읽으며 바로 실행합니다.
동적 타입: 변수를 만들 때 타입을 정하지 않습니다. 값이 들어가는 순간 결정됩니다.
싱글 스레드: 한 번에 하나씩만 처리합니다. 그래서 비동기가 중요해집니다.

변수: var, let, const

키워드	스코프	재선언	재할당	지금 쓰나?
`var`	함수	가능	가능	❌ 쓰지 않습니다
`let`	블록 `{ }`	불가	가능	⭕ 값이 바뀔 때
`const`	블록 `{ }`	불가	불가	⭕ 기본값

권장 방식: 기본적으로 const를 사용하고, 재할당이 필요할 때만 let을 사용합니다. 새 코드에서는 var를 피하는 편이 좋습니다.

호이스팅(Hoisting)은 JS가 변수 선언을 스코프 맨 위로 끌어올리는 동작입니다. var는 값이 없는 채로 올라가서 선언 전에 접근해도 에러 대신 undefined가 나옵니다. 이게 조용한 버그의 원인이 되며, let·const가 권장되는 이유 중 하나입니다.

데이터 타입

구분	원시형 (Primitive)	객체형 (Object)
종류	number, string, boolean, null, undefined	object, array, function
저장 방식	값 자체를 저장	값이 있는 주소를 저장
변경	불변	가변

객체를 복사한 뒤 원본 변경이 함께 반영되는 문제가 생길 수 있습니다. 객체 변수는 값 자체가 아니라 참조를 복사하기 때문입니다.

DOM: HTML을 객체로 다루기

DOM(Document Object Model)은 브라우저가 HTML 문서를 트리 구조의 객체로 표현한 것입니다. JavaScript는 DOM을 통해 페이지 콘텐츠와 상태를 변경합니다. 즉 JavaScript는 HTML 소스 자체가 아니라 브라우저가 구성한 DOM을 조작합니다.

// ① 요소를 찾고
const el = document.getElementById("demo");

// ② 내용을 바꾸고
el.innerHTML = "안녕하세요";

// ③ 스타일도 바꿉니다
el.style.color = "red";

요소를 찾는 방법은 여러 가지입니다. CSS 선택자를 사용할 수 있는 querySelector()가 자주 쓰입니다.

document.getElementById("demo");      // id로
document.querySelector(".menu");      // CSS 선택자로 (첫 번째 하나)
document.querySelectorAll(".menu");   // CSS 선택자로 (전부)

이벤트

클릭, 입력, 스크롤처럼 페이지에서 발생하는 일이 이벤트입니다. 이벤트 등록에는 여러 방법이 있지만, 일반적으로 addEventListener를 사용합니다.

<!-- 비권장: HTML에 JS를 섞으면 관리가 안 됩니다 -->
<button onclick="doSomething()">클릭</button>

// 권장: 핸들러를 여러 개 달 수 있고, HTML과 완전히 분리됩니다
const btn = document.getElementById("myBtn");

btn.addEventListener("click", () => {
  document.getElementById("demo").innerHTML = "눌렸습니다!";
});

이벤트 전파: <div> 안의 <button>을 클릭하면 이벤트는 요소 계층을 따라 전달됩니다. 전달 방향에는 두 가지가 있습니다.

구분	버블링 (Bubbling)	캡처링 (Capturing)
방향	자식 → 부모 (안에서 밖으로)	부모 → 자식 (밖에서 안으로)
설정	기본값	`addEventListener(t, fn, true)`
활용도	높음 (이벤트 위임의 원리)	낮음

자주 쓰는 제어 두 가지도 알아두면 좋습니다.

event.preventDefault(): 태그의 기본 동작을 막습니다. 폼 제출 시 새로고침되는 걸 막을 때 거의 항상 씁니다.
event.stopPropagation(): 부모로 전파되는 걸 중단합니다.

비동기

JavaScript는 싱글 스레드로 실행됩니다. 네트워크 요청처럼 시간이 걸리는 작업을 동기적으로 처리하면 UI 응답이 지연될 수 있습니다. 이런 작업을 기다리는 동안 다른 코드를 실행하도록 처리하는 방식이 비동기입니다.

비동기 처리 방식은 다음과 같이 발전해 왔습니다.

세대	방식	특징
1세대	Callback	중첩이 깊어지면 코드 흐름을 파악하기 어려움
2세대 (ES6)	Promise	상태를 객체로 만들어 `.then()` / `.catch()`로 연결
3세대 (ES8)	async / await	비동기 코드를 동기 코드처럼 읽을 수 있음. 현재 널리 사용

Promise는 비동기 작업의 완료 또는 실패 결과를 나타내는 객체입니다. 세 가지 상태를 가집니다.

Pending: 아직 진행 중
Fulfilled: 성공, 결과값이 있음
Rejected: 실패, 에러가 있음

// async/await: Promise를 훨씬 읽기 쉽게 쓴 것
async function getData() {
  const res  = await fetch("https://api.example.com/data");
  const data = await res.json();
  console.log(data);
}

셋이 함께 일하는 모습

버튼을 클릭하면 문구가 바뀌는 예제입니다. HTML, CSS, JavaScript가 각각 무엇을 처리하는지 확인할 수 있습니다.

<!-- HTML : 무엇이 있는가 -->
<button id="btn">클릭</button>
<p id="msg" class="greeting">안녕하세요</p>

<!-- CSS : 어떻게 보이는가 -->
<style>
  .greeting { color: navy; font-size: 20px; }
</style>

<!-- JavaScript : 어떻게 움직이는가 -->
<script>
  document.getElementById("btn").addEventListener("click", () => {
    document.getElementById("msg").innerHTML = "반갑습니다!";
  });
</script>

HTML이 버튼과 문단을 만들고, CSS가 색과 크기를 정의하며, JavaScript가 클릭 이벤트에 따라 내용을 변경합니다. 세 파일로 분리해도 동일하게 동작합니다. 역할을 분리하면 코드 관리가 쉬워집니다.

정리하면

한 줄 정리: HTML은 구조, CSS는 표현, JavaScript는 동작과 로직을 담당합니다. 역할을 분리하는 것이 유지보수 가능한 프론트엔드 코드의 기본입니다.

처음부터 모든 태그와 속성을 외울 필요는 없습니다. 문법은 필요할 때 문서를 참고하면 됩니다. 대신 block과 inline의 차이, 박스 모델의 계산 방식, DOM의 개념은 반드시 이해해두는 것이 좋습니다. 이 세 가지를 기준으로 나머지 개념을 확장해 나갈 수 있습니다.

참고

MDN Web Docs: HTML · CSS · JavaScript
W3Schools: 예제를 바로 돌려볼 수 있어 처음 배울 때 좋습니다
roadmap.sh: Frontend

앞 글에서는 이 파일들이 서버에서 브라우저까지 어떻게 도착하는지(HTTP·DNS·TCP/IP) 정리했습니다.