AWS 엔지니어, Linux 7.0으로 PostgreSQL 성능 반토막 보고… 해결 쉽지 않을 수도

(phoronix.com)

Hacker News2026년 4월 5일개발자 도구

AWS 엔지니어, Linux 7.0으로 PostgreSQL 성능 반토막 보고… 해결 쉽지 않을 수도

리눅스 커널 7.0의 선점 모드 변경으로 PostgreSQL 성능이 절반 수준으로 급감하는 문제가 보고된 가운데, 이를 해결하기 위해 데이터베이스 엔진의 근본적인 구조적 수정이 요구되면서 클라우드 인프라 전반에 큰 파장이 예상됩니다.

이 글의 핵심 포인트

1AWS 엔지니어가 리눅스 커널 7.0에서 PostgreSQL 성능이 이전 버전 대비 약 0.51배 (절반 수준)로 저하된다고 보고.
2주요 원인은 리눅스 7.0의 커널 선점 모드 변경(PREEMPT_NONE 제한)과 PostgreSQL의 사용자 공간 스핀락 사용 방식 충돌.
3커널 개발자(Peter Zijlstra)는 커널 변경을 되돌리기보다 PostgreSQL이 새로운 Restartable Sequences (RSEQ) 기능을 사용하도록 수정해야 한다고 제안.
4리눅스 7.0은 약 2주 후 안정 버전으로 출시될 예정이며, Ubuntu 26.04 LTS의 기반 커널이 될 것.
5해당 문제는 Graviton4 서버에서 확인되었으며, PostgreSQL 코드 수정 없이는 안정 버전 리눅스 7.0에서 심각한 성능 저하가 예상됨.

이 글에 대한 공공지능 분석

왜 중요한가?

이 뉴스는 전 세계적으로 가장 널리 사용되는 오픈소스 관계형 데이터베이스 중 하나인 PostgreSQL의 핵심 성능이 차세대 리눅스 커널에서 치명적으로 저하될 수 있음을 시사합니다. 특히 클라우드 환경에서 PostgreSQL을 기반으로 서비스하는 수많은 스타트업과 기업들에게는 즉각적인 시스템 불안정 및 성능 저하를 의미합니다. AWS 엔지니어가 직접 문제를 제기하고, Graviton4 서버에서 50%라는 극단적인 성능 저하를 보고한 것은 이 문제가 단순한 버그를 넘어 심각한 아키텍처적 충돌임을 보여주며, 곧 출시될 Ubuntu 26.04 LTS에도 영향을 미쳐 광범위한 파장을 예고합니다.

어떤 배경과 맥락이 있나?

이 문제의 핵심은 리눅스 커널의 '선점 모드(preemption modes)' 변경에 있습니다. 리눅스 7.0에서는 커널의 복잡성을 줄이기 위해 이전의 'PREEMPT_NONE' 옵션을 제한하고 'Full & Lazy Preemption' 모델에 집중했습니다. 그러나 PostgreSQL은 사용자 공간 스핀락(user-space spinlock)을 많이 사용하는데, 새로운 커널 환경에서는 이 스핀락 사용 시 선점으로 인해 많은 시간을 허비하게 됩니다. 커널 개발자들은 PostgreSQL이 커널 7.0에 새로 추가된 'Restartable Sequences (RSEQ)' 시간 슬라이스 확장을 사용하도록 코드를 수정해야 한다고 주장하며, 이는 단순한 성능 버그 수정이 아니라 데이터베이스 애플리케이션의 근본적인 적응을 요구하는 상황입니다.

업계에 어떤 영향을 주나?

클라우드 서비스 제공업체, 특히 AWS와 같은 대규모 인프라 제공업체는 Graviton4와 같은 자체 칩셋에서 최적의 성능을 제공해야 합니다. PostgreSQL 성능 저하는 AWS RDS(Relational Database Service)와 같은 관리형 데이터베이스 서비스에 직접적인 영향을 미칠 수 있습니다. 이로 인해 많은 기업이 리눅스 7.0 또는 Ubuntu 26.04 LTS로의 업그레이드를 보류하거나, PostgreSQL 애플리케이션 코드를 수정해야 하는 추가 비용과 시간을 감수해야 할 것입니다. 이는 시스템 안정성을 중시하는 업계의 특성상 상당한 혼란과 재정적 부담으로 이어질 수 있으며, 잠재적으로는 다른 데이터베이스 솔루션으로의 전환을 고려하게 만들 수도 있습니다.

한국 시장에 어떤 시사점이 있나?

한국 스타트업과 IT 기업들은 AWS를 비롯한 클라우드 서비스를 적극적으로 활용하며 PostgreSQL을 백엔드 데이터베이스로 사용하는 경우가 많습니다. 이번 이슈는 이들에게 다음과 같은 시사점을 줍니다. 첫째, 예정된 리눅스 7.0 기반의 Ubuntu 26.04 LTS로의 업그레이드 계획을 재검토하고, 충분한 테스트 없이 적용하지 않도록 주의해야 합니다. 둘째, PostgreSQL을 사용하는 경우 RSEQ 지원 업데이트가 나오기 전까지는 기존 커널 버전을 유지하는 방안을 고려해야 합니다. 셋째, 클라우드 환경에서 데이터베이스 성능 모니터링을 강화하고, 잠재적인 성능 저하에 대비한 인프라 투자 계획을 사전에 수립하는 것이 중요합니다. 이는 한국 스타트업의 개발 및 운영 비용 상승 요인이 될 수 있습니다.

이 글에 대한 큐레이터 의견

이번 PostgreSQL 성능 저하 이슈는 단순히 기술적인 버그 보고를 넘어, 오픈소스 생태계와 상용 서비스 간의 복잡한 역학 관계를 극명하게 보여줍니다. 커널 개발자들은 자신들의 아키텍처 방향성을 고수하며 'PostgreSQL이 변화에 적응해야 한다'는 입장을 취하고 있습니다. 이는 기술 스택의 깊은 이해 없이 단순히 '최신 버전'을 좇는 스타트업들에게 심각한 운영 리스크로 다가올 수 있습니다.

스타트업 창업자들은 이러한 상황을 단순한 개발팀의 문제로 치부해서는 안 됩니다. 인프라의 핵심을 이루는 데이터베이스의 성능이 절반으로 떨어지는 것은 서비스 전체의 가용성과 사용자 경험에 직접적인 타격을 입히며, 이는 곧 비즈니스 손실로 이어집니다. 장기적으로는 오픈소스 프로젝트의 로드맵 변화가 자사 서비스에 미칠 영향을 예측하고, 이에 대한 대응 전략을 수립하는 역량이 중요해질 것입니다.

실행 가능한 인사이트는 다음과 같습니다. 첫째, 당분간 리눅스 7.0 및 Ubuntu 26.04 LTS 업그레이드를 보류하고, 철저한 테스트 환경을 구축하여 자사 서비스에 미치는 영향을 면밀히 평가해야 합니다. 둘째, PostgreSQL을 사용하는 경우, RSEQ 지원 업데이트 현황을 주시하고, 필요시 데이터베이스 코드 수정 및 튜닝에 대한 리소스를 미리 확보해야 합니다. 셋째, 클라우드 제공업체(AWS 등)가 이 문제를 어떻게 해결하고 완화할지 모니터링하고, 그들의 권고 사항에 따르는 것이 현명합니다. 이와 동시에, 비상시를 대비하여 다른 데이터베이스 솔루션으로의 전환 가능성도 열어두는 전략적 사고가 필요합니다.

원문 보기 →