Hacker News 2026.04.05 78

Linux 7.0으로 올렸더니 PostgreSQL 성능이 반토막? AWS 엔지니어가 발견한 심각한 문제

무슨 일이 일어났나요?

Linux 커널을 최신 버전인 7.0으로 업그레이드했더니 PostgreSQL의 성능이 거의 절반 가까이 떨어졌다는 보고가 나왔어요. 이 문제를 발견한 건 AWS에서 일하는 엔지니어인데요, 단순한 벤치마크 오류가 아니라 실제로 재현 가능한 성능 저하라서 업계에서 꽤 심각하게 받아들이고 있어요.

커널 업그레이드가 데이터베이스 성능에 이 정도 영향을 준다는 건 흔한 일이 아니거든요. 보통은 커널이 올라가면 성능이 조금 좋아지거나, 적어도 비슷하게 유지되는 게 일반적이에요. 그런데 이번엔 정반대 상황이 벌어진 거죠.

기술적으로 뭐가 문제인가요?

이번 성능 저하의 핵심은 Linux 커널의 메모리 관리나 스케줄링 쪽에서 변경된 부분이 PostgreSQL의 동작 방식과 충돌하고 있다는 점이에요. PostgreSQL은 "공유 버퍼(shared buffers)"라는 구조를 통해 디스크에서 읽어온 데이터를 메모리에 캐싱하는데요, 이게 뭐냐면 자주 쓰는 데이터를 매번 디스크에서 읽지 않고 메모리에 올려놓는 거예요. 마치 자주 보는 책을 책장에서 꺼내놓고 책상 위에 두는 것과 비슷하죠.

문제는 커널 7.0에서 이 메모리 영역을 다루는 방식이 바뀌면서, PostgreSQL이 데이터를 읽고 쓸 때마다 이전보다 더 많은 오버헤드가 발생하게 됐다는 거예요. 오버헤드란 쉽게 말해 "원래 할 일 외에 추가로 드는 비용"이에요. 책상 위에 책을 꺼내놨는데, 누군가가 매번 "이 책 여기 놔둬도 되는 거 맞아?"라고 확인하는 절차를 추가한 것과 비슷해요.

AWS 엔지니어의 테스트에 따르면, pgbench라는 PostgreSQL 표준 벤치마크 도구를 돌렸을 때 Linux 6.x 대비 7.0에서 TPS(초당 트랜잭션 수)가 거의 절반으로 줄어들었어요. 특히 읽기 작업이 많은 워크로드에서 성능 하락이 두드러졌고요.

더 걱정되는 건, 이 문제의 수정이 쉽지 않을 수 있다는 점이에요. 커널 쪽에서 변경된 부분이 단순한 버그가 아니라 설계적인 변경일 가능성이 있어서, 되돌리기가 간단하지 않다는 이야기가 나오고 있거든요.

왜 이런 일이 반복될까요?

사실 Linux 커널 업데이트가 특정 워크로드의 성능을 떨어뜨리는 일은 이전에도 있었어요. 대표적으로 2018년에 Spectre/Meltdown 보안 패치가 적용됐을 때, CPU 성능이 최대 30%까지 떨어지는 경우가 있었죠. 보안을 위해 성능을 희생한 케이스였는데요.

이번 경우는 보안 패치와는 성격이 다르지만, 커널 개발자와 데이터베이스 개발자 사이의 커뮤니케이션 갭이 근본 원인이라는 점에서 비슷한 패턴이에요. 커널 개발자들은 전체 시스템의 효율성을 기준으로 변경을 하고, 데이터베이스처럼 메모리를 아주 특수하게 쓰는 애플리케이션의 사정은 충분히 고려하지 못하는 경우가 있거든요.

MySQL이나 MariaDB 같은 다른 데이터베이스에서도 비슷한 영향이 있을 수 있어서, PostgreSQL만의 문제로 한정짓기는 이른 상황이에요.

한국 개발자에게 어떤 의미가 있을까요?

당장 실무에서 중요한 건, Linux 7.0으로의 업그레이드를 서두르지 말라는 거예요. 특히 PostgreSQL을 프로덕션에서 운영하고 계신 분들은 이 이슈가 해결될 때까지 기존 커널 버전을 유지하는 게 안전해요.

클라우드 환경에서 일하시는 분들은 좀 더 주의가 필요한데요, AWS나 GCP 같은 클라우드 서비스에서 제공하는 기본 이미지의 커널 버전이 자동으로 올라가는 경우가 있거든요. 커널 업데이트 정책을 확인해보시고, 자동 업데이트가 설정돼 있다면 한번 점검해보시는 걸 추천해요.

또 하나 배울 점은, 인프라 변경 전에 반드시 벤치마크를 돌려보는 습관이에요. pgbench 같은 도구로 업그레이드 전후 성능을 비교하는 건 어렵지 않은데, 이걸 빼먹으면 프로덕션에서 갑자기 성능이 떨어져도 원인을 찾기 힘들어요.