Postgres에서 진짜 빠른 삭제는 DELETE가 아니라 DROP TABLE이다

삭제 한 줄이 왜 이렇게 무거울까

데이터베이스 다루다 보면 「오래된 로그 1억 건만 지워줘」 같은 요청 흔하게 받잖아요. 그래서 별생각 없이 DELETE FROM logs WHERE created_at < '2024-01-01' 같은 쿼리를 날리는데, 이게 운영 중인 Postgres에서는 생각보다 무서운 작업이거든요. CPU 튀고, 디스크는 안 줄어들고, 심하면 다른 쿼리까지 느려져요. 이번에 「Postgres에서 진짜로 확장 가능한 삭제는 DROP TABLE뿐이다」라는 다소 도발적인 글이 나왔는데, 왜 그런 말이 나왔는지 차근차근 풀어볼게요.

DELETE는 사실 ‘지우는’ 게 아니다

먼저 Postgres가 데이터를 어떻게 관리하는지 알아야 해요. Postgres는 MVCC(다중 버전 동시성 제어)라는 방식을 쓰는데요, 이게 뭐냐면 한 행을 여러 버전으로 들고 있으면서 「지금 이 트랜잭션은 어떤 버전을 봐야 하는지」를 관리하는 구조예요. 그래서 우리가 DELETE를 날려도 그 행이 디스크에서 바로 사라지지 않아요. 대신 「이 행은 죽었음」이라는 표시(dead tuple, 죽은 튜플)만 붙여요.

문제는 여기서 시작돼요. 1억 건을 지우면 1억 개의 죽은 튜플이 생기는데, 디스크 공간은 그대로예요. 게다가 삭제 작업 하나하나가 WAL(Write-Ahead Log, 장애 복구용 변경 기록)에 다 쌓이거든요. 그래서 삭제인데도 디스크 쓰기가 폭발하고, 복제(replication) 지연까지 생겨요.

VACUUM과 블로트(bloat)의 굴레

그럼 죽은 튜플은 누가 치우냐? VACUUM이 치워요. autovacuum이 백그라운드로 돌면서 죽은 튜플 자리를 ‘재사용 가능’으로 표시해주는데요. 근데 함정이 있어요. VACUUM은 기본적으로 그 공간을 운영체제(OS)에 돌려주지 않아요. 테이블 내부에서 재사용할 수 있게만 만들어줘요. 즉 100GB 테이블에서 90GB를 지워도 디스크상 테이블 크기는 여전히 100GB인 거죠. 이걸 블로트(bloat, 부풀어 오름)라고 불러요.

공간을 진짜 OS에 돌려주려면 VACUUM FULL을 해야 하는데, 이건 테이블 전체에 강한 잠금(lock)을 걸어서 그동안 서비스가 멈춰요. 운영 중엔 못 쓰는 거나 마찬가지예요. 그래서 대량 삭제는 「지워도 안 줄고, 줄이려면 멈춰야 하는」 진퇴양난에 빠져요.

그래서 DROP TABLE / 파티셔닝

반면 DROP TABLE이나 TRUNCATE는 차원이 달라요. 행을 하나씩 죽었다고 표시하는 게 아니라, 테이블에 해당하는 파일 자체를 통째로 날려버리거든요. 데이터가 1건이든 100억 건이든 거의 일정한 시간에 끝나요. 이게 글 제목의 핵심이에요. 행 단위 삭제는 데이터 양에 비례해 느려지지만, 파일 단위 삭제는 양과 상관없이 빠르다는 거죠.

그래서 실무에서 추천하는 패턴이 파티셔닝(partitioning)이에요. 예를 들어 로그 테이블을 월별 파티션으로 쪼개두면, 오래된 데이터를 지울 때 DELETE가 아니라 파티션을 분리해서 DROP하면 돼요. 이건 메타데이터만 건드리는 작업이라 거의 즉시 끝나고, 블로트도 안 생기고, VACUUM 지옥도 없어요.

다른 DB는 어떨까

이건 Postgres만의 이야기는 아니에요. MySQL의 InnoDB도 비슷하게 삭제 후 공간을 바로 안 돌려주는 문제가 있어요. 그래서 대용량 시계열 데이터를 다루는 곳에서는 TimescaleDB(Postgres 확장)의 자동 파티셔닝이나, 아예 ClickHouse 같은 컬럼형 DB의 TTL 기반 자동 삭제를 쓰기도 해요. 「오래된 데이터를 어떻게 싸게 버리느냐」는 모든 DB의 공통 숙제거든요.

한국 개발자에게

당장 적용할 교훈이 명확해요. 로그, 이벤트, 세션처럼 ‘시간 지나면 버릴 데이터’가 있다면 처음 설계할 때부터 파티셔닝을 깔고 가세요. 나중에 DELETE로 지우려다 새벽에 장애 대응하는 것보다 훨씬 싸요. 이미 운영 중이라 파티션이 없다면, 배치로 나눠 지우면서 autovacuum 설정을 공격적으로 튜닝하는 게 현실적인 차선책이에요.

핵심 한 줄: 삭제는 공짜가 아니다. 버릴 데이터는 처음부터 ‘통째로 버릴 수 있게’ 설계하라. 여러분 서비스의 로그 테이블, 혹시 DELETE로 청소하고 계신가요?