PostgreSQL 속은 사실 도시였다 — 심시티처럼 구경하는 DB 내부, PGSimCity

PostgreSQL, 다들 한 번쯤은 써보셨을 텐데요. 그런데 정작 쿼리를 날렸을 때 그 안에서 무슨 일이 벌어지는지 설명할 수 있는 분은 의외로 많지 않아요. 데이터베이스라는 게 워낙 블랙박스처럼 느껴지다 보니, '잘 돌아가면 됐지' 하고 넘어가기 쉽거든요. 그런데 이 블랙박스를 심시티 같은 도시 시뮬레이션에 빗대어 눈으로 구경할 수 있게 만든 프로젝트가 나왔어요. 이름도 재치 있는 PGSimCity인데요, PostgreSQL의 내부 구조를 도시의 건물과 일꾼들에 비유해서, 데이터베이스가 살아 움직이는 모습을 게임 화면 보듯 이해할 수 있게 해줍니다.

데이터베이스는 사실 하나의 도시예요

이 비유가 꽤 잘 맞는 이유가 있는데요, PostgreSQL이 실제로 여러 프로세스(독립적으로 돌아가는 작은 프로그램들이라고 생각하시면 돼요)가 역할을 나눠 맡아 협업하는 구조거든요. 도시로 치면 이런 느낌이에요. 먼저 postmaster라는 총괄 프로세스가 있어요. 도시의 시청 같은 존재인데, 클라이언트가 접속해 오면 그 손님을 전담할 백엔드 프로세스를 하나씩 새로 만들어 붙여줍니다. 민원인이 오면 담당 공무원이 한 명씩 배정되는 셈이죠. 그래서 PostgreSQL에 접속이 1,000개 생기면 프로세스도 1,000개가 생겨요. 커넥션 풀러(PgBouncer 같은 도구)가 왜 필요한지, 이 구조를 알면 바로 이해되죠. 공무원을 무한정 채용할 수는 없으니까요.

데이터가 오가는 길목도 도시 인프라랑 똑같아요. 디스크에 있는 데이터를 매번 직접 읽으면 너무 느리니까, 자주 쓰는 데이터를 메모리에 올려두는 공유 버퍼(shared buffers)가 있어요. 도시 한가운데 있는 물류 창고라고 보시면 되는데요, 창고에 물건이 있으면 바로 꺼내 쓰고, 없으면 멀리 있는 항구(디스크)까지 다녀와야 하는 거예요. 그리고 뭔가를 변경할 때는 WAL(Write-Ahead Log)이라는 장부에 먼저 기록해요. '창고 물건을 바꾸기 전에 장부부터 쓴다'는 원칙인데, 이 덕분에 서버가 갑자기 꺼져도 장부를 다시 읽으면서 데이터를 복구할 수 있는 거거든요. 체크포인터라는 일꾼은 주기적으로 창고의 변경 사항을 디스크에 확정 반영하는 역할을 맡고요.

도시에 청소부가 없으면 어떻게 될까요? PostgreSQL에서 그 역할을 하는 게 autovacuum이에요. PostgreSQL은 데이터를 수정하거나 삭제할 때 원본을 바로 지우지 않고 '죽은 버전'으로 표시만 해두거든요. 이걸 MVCC(다중 버전 동시성 제어)라고 하는데, 쉽게 말하면 여러 사람이 동시에 읽고 쓸 때 서로 방해하지 않도록 데이터의 여러 버전을 잠시 같이 보관하는 방식이에요. 문제는 이 죽은 버전들이 쓰레기처럼 쌓인다는 건데, autovacuum이 돌아다니면서 치워주는 거죠. 이 청소가 밀리면 테이블이 뚱뚱해지고(블로트), 쿼리가 느려지고, 최악엔 장애까지 가요. 실무에서 autovacuum 튜닝이 그렇게 중요한 이유입니다.

눈으로 배우는 학습 자료의 계보

사실 PostgreSQL 내부를 공부할 자료가 없었던 건 아니에요. 공식 문서도 방대하고, 《The Internals of PostgreSQL》 같은 명저도 있고요. 그런데 이런 자료들은 진입장벽이 꽤 높아요. 글과 다이어그램만으로 여러 프로세스가 '동시에' 움직이는 모습을 머릿속에 그리는 건 쉽지 않거든요. 그래서 최근 몇 년 사이 인터랙티브 시각화로 개념을 가르치는 흐름이 커지고 있어요. 정렬 알고리즘 시각화나 CPU 동작을 애니메이션으로 보여주는 사이트들이 꾸준히 사랑받는 것도 같은 맥락이고요. PGSimCity는 그 흐름을 데이터베이스 내부라는, 유난히 추상적이던 영역으로 가져온 시도라고 볼 수 있어요.

한국 개발자에게 주는 시사점

요즘은 대부분 RDS나 Aurora 같은 매니지드 서비스로 PostgreSQL을 쓰니까 '내부까지 알 필요 있나' 싶을 수 있는데요, 오히려 반대예요. 평소엔 몰라도 되지만, 슬로우 쿼리가 터지거나 커넥션이 고갈되거나 디스크가 갑자기 차오를 때, 내부 구조를 아는 사람과 모르는 사람의 대응 속도는 하늘과 땅 차이거든요. shared_buffers를 왜 그 값으로 잡는지, 커넥션 풀을 왜 앞에 두는지, VACUUM 경고가 왜 무서운 건지 — 전부 오늘 이야기한 도시 구조에서 자연스럽게 답이 나오는 질문들이에요. 주니어 분들이라면 면접에서도 자주 나오는 주제이니, 이런 시각화로 큰 그림부터 잡고 공식 문서로 깊이를 더하는 순서를 추천해요.

한 줄로 정리하면, PostgreSQL은 여러 일꾼이 분업하는 도시이고, PGSimCity는 그 도시를 구경시켜주는 전망대 같은 프로젝트예요. 여러분은 매일 쓰는 데이터베이스의 내부를 얼마나 알고 계신가요? 내부 구조를 몰라서 고생했던 장애나 튜닝 경험이 있다면 댓글로 공유해 주세요.