# 자, Postgres를 직접 호스팅해 보세요 > Clean Markdown view of GeekNews topic #25219. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=25219](https://news.hada.io/topic?id=25219) - GeekNews Markdown: [https://news.hada.io/topic/25219.md](https://news.hada.io/topic/25219.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2025-12-21T09:46:45+09:00 - Updated: 2025-12-21T09:46:45+09:00 - Original source: [pierce.dev](https://pierce.dev/notes/go-ahead-self-host-postgres#user-content-fn-1) - Points: 5 - Comments: 5 ## Summary **Postgres 자가 호스팅**은 더 이상 복잡하거나 위험한 선택이 아닙니다. 최근 **관리형 서비스의 가격 상승**으로 동일한 비용에 훨씬 높은 사양의 서버를 직접 운영할 수 있게 되면서, 중간 규모 팀에게 현실적인 대안이 되고 있습니다. 표준 Postgres에 약간의 자동화만 더하면 수천만 건의 쿼리를 안정적으로 처리할 수 있으며, 유지보수 시간도 월 수십 분 수준으로 제한됩니다. 클라우드 의존이 당연시되던 흐름 속에서, 인프라를 직접 다루는 선택이 다시 합리적인 계산으로 돌아오고 있습니다. ## Topic Body - **Postgres 자가 호스팅**은 복잡하거나 위험하지 않으며, **관리형 서비스보다 저렴하고 성능 조정이 자유로운 방식**임 - 대부분의 **클라우드 데이터베이스 서비스는 오픈소스 Postgres를 약간 수정한 형태**로 운영되며, 실질적 차이는 운영 자동화 수준에 있음 - 실제 운영 사례에서 **자가 호스팅 Postgres는 수천 명의 사용자와 수천만 건의 쿼리를 안정적으로 처리**하며, 유지보수 시간도 매우 적음 - **AWS RDS 등 관리형 서비스의 가격 상승**으로 인해, 동일 비용으로 훨씬 높은 사양의 서버를 직접 운영할 수 있음 - 인프라 관리가 복잡하지 않은 중간 규모 팀에게 **자가 호스팅이 비용 효율성과 성능 면에서 현실적 대안**이 됨 --- ### 클라우드 중심 서사의 변화 - 과거에는 대부분의 기업이 **자체 서버에서 데이터베이스를 직접 운영**했으며, 이는 네트워크 지연이 적고 빠른 구조였음 - 1980~2000년대에는 애플리케이션 서버와 데이터베이스 서버가 같은 물리 장비에 위치하는 경우가 많았음 - **Amazon RDS(2009)** 출시는 백업, 패치, 모니터링을 자동화해주는 매력적인 제안으로 받아들여졌음 - 초기에는 전용 서버와 비슷한 가격으로 운영 부담을 줄일 수 있었음 - 2015년 이후 클라우드 도입이 가속화되면서, **직접 인프라를 관리하는 행위가 비효율적이라는 인식**이 확산됨 - AWS가 인프라를 대신 관리하고, 개발자는 애플리케이션 로직에 집중하는 구조가 표준으로 자리잡음 - 2025년 현재 **RDS 가격이 크게 상승**하며, 동일 비용으로 훨씬 높은 사양의 전용 서버를 임대할 수 있는 상황이 됨 - 예: db.r6g.xlarge 인스턴스(4 vCPU, 32GB RAM)는 월 $328로, 32코어·256GB RAM 서버 임대가 가능 ### 관리형 서비스의 실제 구성 - **AWS RDS**는 기본적으로 **표준 Postgres에 AWS 전용 모니터링과 백업 시스템을 추가한 형태**임 - EBS 스냅샷 기반 백업, Chef/Puppet/Ansible을 통한 구성 관리, PgBouncer 연결 풀링, CloudWatch 모니터링, 자동 장애 조치 스크립트 포함 - 이러한 구성은 기술적으로 복잡하지 않으며, **운영 자동화와 초기 배포 편의성**이 핵심 가치임 - 동일 사양의 서버로 RDS에서 자가 호스팅으로 마이그레이션한 결과, **성능은 동일하거나 오히려 향상**됨 - RDS에서 제한된 파라미터를 직접 조정할 수 있게 되어 성능 최적화 가능 ### 자가 호스팅의 운영 복잡도 - DigitalOcean의 **16 vCPU / 32GB RAM / 400GB 디스크 서버로 마이그레이션**에 약 4시간이 소요되었으며, 이후 안정적 운영 확인 - **고가용성 제품군**은 월 30분 정도의 관리 시간이 필요하며, 트래픽이 적은 서비스는 완전 자동화 가능 - 정기 관리 주기 - **주간(10분)** : 백업 검증, 느린 쿼리 로그 검토, 디스크 용량 확인 - **월간(30분)** : 보안 업데이트, 백업 보존 정책 점검, 용량 계획 - **분기별(2시간)** : 모니터링 대시보드 갱신, 설정 최적화, 복구 테스트 - **장애 대응은 직접 책임**이지만, RDS도 장애가 발생하며 결국 개발자가 대응해야 함 - 직접 운영 시 **업데이트 시점과 위험 구간을 스스로 조정 가능**, 안정성 확보 용이 ### 자가 호스팅이 부적합한 경우 - **초기 개발자**가 빠르게 프로토타입을 만들 때는 관리형 서비스가 더 간편함 - **대규모 기업**은 전담 데이터베이스 엔지니어를 두거나, 인건비 절감을 위해 클라우드에 위탁하는 것이 효율적일 수 있음 - **규제 산업(PCI-DSS, HIPAA 등)** 은 인증된 관리형 플랫폼 사용이 요구될 수 있음 ### 주요 설정 포인트 - **메모리 설정**: 하드웨어에 맞게 `shared_buffers`, `effective_cache_size`, `work_mem`, `maintenance_work_mem` 등을 조정해야 함 - 예: `shared_buffers`는 RAM의 25%, `effective_cache_size`는 75% 설정 - **연결 관리**: `pgbouncer`를 사용해 연결 풀링 구성, Python asyncio 환경에서 효율적 동작 - `max_connections = 200`, `log_connections = on` 등 기본 설정 예시 제공 - **스토리지 튜닝**: NVMe SSD 환경에서는 `random_page_cost = 1.1`, `effective_io_concurrency = 200` 등으로 조정 - 무작위 읽기 속도가 향상되어 쿼리 계획 최적화 - **WAL 설정**: 내구성과 성능을 위한 `wal_level = replica`, `max_wal_size = 2GB`, `checkpoint_completion_target = 0.9` 등 조정 ### 결론 - 모든 인프라를 직접 운영할 필요는 없지만, **Postgres는 자가 호스팅이 합리적인 영역에 속함** - 월 $200 이상을 RDS에 지출 중이라면, **비핵심 데이터베이스를 테스트 서버로 이전해볼 가치** 있음 - 향후 인프라는 **관리형 서비스와 자가 호스팅이 혼합된 하이브리드 형태**로 발전할 가능성 - Postgres는 **비용 대비 효율이 높은 자가 호스팅 후보**로 평가됨 ## Comments ### Comment 48176 - Author: yangeok - Created: 2025-12-23T11:18:06+09:00 - Points: 1 스토리지도 11나인을 보장해주니 클라우드를 쓰는 것처럼 운영이 어려우니 클라우드를 쓰는거죠 ㅎㅎ ### Comment 48132 - Author: kaydash - Created: 2025-12-22T16:12:32+09:00 - Points: 1 실제로는 3 node 클러스터 운영이 그렇게 쉽지는않을거에요. ### Comment 48069 - Author: neo - Created: 2025-12-21T09:46:45+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46336947) - 나는 **self-hosting**을 책임의 문제로 봄 SaaS 제품 몇 개를 직접 호스팅 중인데, AWS보다 훨씬 저렴하면서도 성능이 훨씬 좋음 다만 클라이언트 프로젝트에서는 AWS 비용을 지불하도록 설득함. 하드웨어 가용성 책임을 다른 쪽으로 넘길 수 있기 때문임 예산이 제한된 경우엔 RDS 비용이 부담스러움. Hetzner의 3노드 **Galera 클러스터**를 몇 달러로 운영하는 게 훨씬 경제적임 하지만 Cloudflare나 SQS 같은 **관리형 서비스**도 종종 장애가 발생함. 결국 완벽한 안정성은 어디에도 없음 - “왜 NoNameCMS에서 Salesforce로 바꾸나요?”라고 물었더니, “Salesforce가 다운되면 WSJ에 기사 나니까”라는 답을 들음. **책임 전가**의 현실적인 이유임 - 클라이언트의 고객 입장에서는 “Ikea랑 Disney도 다운됐다”는 말이 통하지 않음. 결국 자기 서비스가 멈췄다는 게 전부임 - **AWS Serverless PG**가 있는데 굳이 직접 관리할 이유가 없음. 저트래픽 환경에서는 거의 무료 수준이고, 보안·백업·통합성 면에서 훨씬 우수함 [AWS Aurora Serverless](https://aws.amazon.com/rds/aurora/serverless/) - VM 수준까지만 외주화하고 나머지는 직접 관리하는 절충도 가능함. 기술 스택의 **운영 오버헤드**에 따라 달라짐 - 20년간 수많은 클라이언트의 **self-hosted SQL**을 운영했는데, SQL 서버가 다운된 적은 한 번도 없음 클라우드 SQL은 오히려 **비용 구조가 복잡**하고, 백업 설정만 한 번 해두면 끝임 - 나는 self-hosting이 대부분에게 맞는 선택이라는 주장에 동의하지 않음 오히려 **예산이 빠듯하거나**, 혹은 **전담 엔지니어를 둘 만큼 큰 규모**일 때만 직접 호스팅이 합리적이라 생각함 소규모 기업은 클라우드에 맡기는 게 현실적임. 셋업 후 월 30~120분 관리면 충분하다는 계산이 나옴 - 대부분의 회사는 클라우드를 써도 여전히 **인프라 엔지니어**를 고용함. “클라우드가 인건비를 줄인다”는 건 거짓임 Heroku나 Render 같은 PaaS는 일반 개발자도 다룰 수 있지만 훨씬 비쌈 결국 애플리케이션 복구 자동화가 안 되어 있으면 새벽 3시에 깨는 건 똑같음 - 대부분의 서비스는 **고가용성**이 필요하지 않음. 토요일에 다운돼도 월요일에 고치면 됨 내부 툴이라면 Docker에 Postgres 하나 추가하는 데 5분이면 충분함 - 클라우드도 월 1~2시간 정도는 관리 시간이 들어감. self-hosting과 큰 차이 없음 - RDS를 쓰면 오히려 **가시성**과 **제어권**이 떨어져서 디버깅이 더 어려움 - 논점은 효율이 아니라 **문제가 생겼을 때 누가 욕을 먹느냐**임. 클라우드면 책임을 돌리기 쉬움 - ‘관리형 데이터베이스’의 정의가 혼란스러움 나에게 기본 요건은 **자동 백업, 인덱스 최적화, 멀티데이터센터 장애조치, 포인트인타임 복구, 슬로우쿼리 분석, 스토리지 예측**임 이런 걸 월 요금으로 제공한다면 self-hosting 논쟁은 의미가 없어짐 - 문제는 **전문 인력**을 고용해야 한다는 점임. Postgres 담당자가 휴가 가면 **버스 팩터** 문제가 생김 결국 두 명을 두게 되고, 일이 심심하니 불필요한 개선을 시도하다가 6개월을 날리는 경우도 있음 - self-hosting의 이유는 결국 **지연시간(latency)** 임. 백업이나 분석은 기본이고, 직접 구축해야 가장 빠름 - 셋업만 잘 하면 백업이나 멀티리전 장애조치도 **자동화** 가능함 - 새벽 3시에 전화 안 올 서비스만 self-hosting함. 로그나 내부 분석용은 괜찮지만, **DB는 절대 아님** - **Yugabyte 오픈소스**가 이런 기능 대부분을 커버함 - 관리형 DB가 **VPS 대비 너무 비쌈** 편의성 프리미엄을 기대했지만 실제로는 몇 배나 더 비쌈. 그래서 큰 프로젝트 외엔 쓰지 않음 - 스스로 못한다고 믿게 만들고, 그 사이에 **가격을 계속 올림**. 옮길 기술이 없으니 종속됨 - 글에서 언급된 **고가용성(HA)** 부분이 부족함. WAL 설정만으로는 설명이 안 됨. 복제는 비용이 큼 - Postgres가 HN에서 과대평가된 이유를 모르겠음 MongoDB처럼 **자동 장애조치가 되는 HA 클러스터**를 쉽게 구성할 방법이 없음. 실서비스에서는 어떻게 해결하는지 궁금함 - PostgreSQL 커뮤니티도 이 문제를 인식하고 있음. MongoDB의 **내장 복제 안정성**을 부러워함 관련 논의: [PostgreSQL 메일링리스트](https://www.postgresql.org/message-id/0e01fb4d-f8ea-4ca9-8c9b-79264ce11993%40postgrespro.ru) - Kubernetes를 쓴다면 **CloudNativePG**가 사실상 표준 HA 솔루션임 - SQL 진영은 진짜 HA 대신 **빠른 복구(Disaster Recovery)** 에 익숙함 실제로는 모든 연결이 끊기고, 캐시가 초기화되며, 업그레이드 시엔 서비스 중단이 필수임 **Oracle RAC**만이 예외이고, PostgreSQL은 그런 구조가 아님. **YugabyteDB**가 그나마 대안임 대부분의 앱은 몇 시간의 다운타임을 감수함. 대기업만이 복잡한 자동화를 감당할 수 있음 - 가장 흔한 방법은 **Patroni**를 쓰는 것임. 간단히 하려면 [Autobase](https://autobase.tech) 사용 Kubernetes 환경이라면 [CloudNativePG](https://cloudnative-pg.io)도 좋음. **pg_auto_failover**는 단순하지만 제약이 있음 - 사실 대부분의 비즈니스는 그런 복잡한 HA가 **필요 없음**. 비용 대비 효과가 낮음 - [Autobase](https://github.com/vitabaks/autobase)를 보면 self-hosting 시 필요한 작업을 자동으로 처리해줌 - README를 훑어봤는데 **커넥션 풀링**은 범위 밖인 듯함 - 다른 self-hosted PaaS와도 잘 연동되는지 궁금함. Docker 컨테이너 형태로 동작하는 듯함 - 멋진 프로젝트라 감사함 - 15년 동안 Postgres를 **항상 self-hosted**로 써왔지만, 문제를 겪은 적은 거의 없음 유일한 고민은 ORM 업그레이드에 맞춰 **PG 버전 마이그레이션**을 해야 할 때였음. 신중한 **시스템 관리**로 해결 가능했음 - Fly.io에서 **비관리형 Postgres**를 직접 돌렸는데, 정말 고생했음 노드가 자주 죽어서 수동으로 **repmgr**로 복구해야 했고, 결국 내부 위키에 절차를 정리함 클러스터의 목적이 고가용성인데 왜 **좀비 프라이머리**를 자동으로 처리하지 않는지 이해가 안 됐음 결국 **관리형 Postgres**로 옮겼고, 장애 시 다른 사람이 처리해주는 게 정말 편함 - 지금은 Fly의 **Managed Postgres**를 쓰고 있음 - 이 스레드의 많은 댓글이 **규모, 워크로드, 인력, 시간, 비즈니스 단계, 확장성 요구** 같은 현실적 요소를 무시함 self-hosting이 맞을 수도, 아닐 수도 있는데 논의가 너무 단순함 - 엔지니어들은 이런 요소를 거의 고려하지 않고, 상사가 승인할 **가장 비싼 솔루션**을 택하는 경향이 있음 ### Comment 48143 - Author: sinbumu - Created: 2025-12-22T19:45:01+09:00 - Points: 1 - Parent comment: 48069 - Depth: 1 개발자들 고민은 저런걸 셀프 호스팅 해줄때 그런 요소를 인정받냐도 중요할듯 클라우드 비용이 더 나가도 셀프 호스팅으로 비용절감한걸 인정 못받으면 그냥 클라우드 서비스 쓰고 커버해야 항 영역 줄이는게 속편함