Andrew Dunstan · 2026년 6월 11일 얼마 전 한 동료가 PostgreSQL Buildfarm 데이터베이스를 조회할 수 있는 API가 있느냐고 물었습니다. 없다고 답했죠. 그동안 여러 사람이 데이터를 얻으려고 웹 페이지를 스크래핑해 왔다는 걸 알고 있었기에, 더 나은 방법이 필요하다는 생각이 들었습니다. 그래서 claude code의 도움을 조금 받아 하나 만들었습니다. 지금 바로 쓸 수 있습니다. 전체 설명은 https://github.com/PGBuildFarm/server-code/blob/main/API.md 에 있습니다. 이걸 어떻게 더 유용하게 확장할 수 있을지, 여러분의 의견을 특히 듣고 싶습니다. 다음은 사용 예시로, master 브랜치에서 crake 멤버의 최신 상태를 가져오는 경우입니다. EDB Postgres AI와 PostgreSQL 커뮤니티, 더 알아보기 EDB의 오픈소스 기여나 EDB Postgres AI가 궁금하시다면 EDB Korea로 문의해 주세요. 원문: Buildfarm Query API (EDB Blog)

Jaime Arze · 2026년 6월 5일 보안팀은 새로운 기술을 일단 의심하도록 훈련받습니다. 그게 우리 일이니까요. 위험을 따지고, 떠오르는 위협을 그려보고, 최악을 가정해 대비합니다. 그래서 AI가 등장했을 때도 첫 반응은 똑같았습니다. “또 하나의 방어할 공격 표면(attack surface)이 생겼군.” 맞는 직감입니다. 그런데 그게 전부는 아니죠. 대부분의 팀은 당장의 위협을 막는 전술 업무에 매달립니다. 그 와중에도 보안팀은 늘 일에 파묻혀 삽니다. 처리해도 줄지 않는 알림 큐. 끝없이 쏟아지는 새 시그널과 분류해야 할 CVE들. 일일이 끌어와야 하는 증거 자료들. 그런데 우리가 매일 의심스럽게 들여다보는 그 기술이, 한편으론 한 주에 몇 시간을 되돌려줄 수도 있습니다. 길게는 며칠씩요. 그래서 우리는 갑론을박을 멈췄습니다. 그냥 해커톤을 열었죠. 하루, 네 개 팀, 슬라이드 없음. 규칙은 하나였습니다. “지금 당신을 괴롭히는 […]

Swapnil Suryawanshi · 2026년 5월 26일 이 런북은 CloudNativePG(CNPG)가 관리하는 두 개의 EDB Postgres Advanced 18 클러스터 사이에서 제어된 스위치오버(Switchover)와 스위치백(Switchback)을 수행하는 운영 절차를 자세히 다룹니다. 본 글은 시리즈의 2부입니다. 아직 분산 토폴로지를 구성하지 않으셨다면 1부: Barman Cloud Plugin을 이용한 CloudNativePG PostgreSQL 레플리카 클러스터 배포부터 시작하세요. 목표 목표는 분산 토폴로지 안에서 프라이머리 클러스터(cluster-primary)와 레플리카 클러스터(cluster-replica) 사이의 프라이머리 역할을 안전하게 교대(rotate)하는 것입니다. 이 과정은 CNPG 네이티브 승격(promotion)·강등(demotion) 워크플로를 활용해 무손실(zero data loss)을 보장합니다. 환경 정보 1단계 페이즈: 최초 스위치오버 (프라이머리 → 레플리카) Step 1: 두 클러스터의 초기 상태 확인 작업을 시작하기 전에 프라이머리와 레플리카 클러스터의 상태(health)와 LSN을 확인합니다. 프라이머리: 레플리카: Step 2: 프라이머리 클러스터 강등(Demote) 프라이머리의 replica 섹션을 변경하고 강등 토큰(demotion […]

작성일: 2026년 3월 16일 작성자: Dunith Danushka 이 핸즈온 튜토리얼은 NVIDIA RAPIDS Accelerator for Apache Spark를 사용해 EDB Postgres에서 GPU 가속 쿼리를 구현하는 방법을 소개한 [출시 블로그]의 후속 편입니다. 이 가이드는 EDB Postgres AI와 가속화된 Apache Spark 클러스터를 원활하게 통합하여 고성능 분석 환경을 구축하려는 데이터 엔지니어, 데이터 과학자, 솔루션 아키텍트를 위해 작성되었습니다. 실습을 바로 시작할 수 있도록 필요한 Docker Compose 스택과 설정이 포함된 GitHub 저장소를 함께 제공합니다. 본 가이드는 두 가지 주요 파트로 나뉩니다. Part 1: CPU 전용 스택으로 로컬 환경 검증하기 Brev 환경의 NVIDIA L40S로 확장하기에 앞서, 로컬 환경에서 구성을 먼저 검증하는 것이 가장 좋습니다. 이 “CPU 전용(CPU-only)” 단계에서는 클라우드 GPU 비용을 들이지 않고도 EDB Postgres AI와 OSS Apache […]

작성자: Mark Wong 날짜: 2026년 2월 8일 이 글은 메모리 오염(Memory Corruption) 버그를 찾기 위해 설계된 프로그래밍 도구인 AddressSanitizer(ASan)가 어떻게 실제 버그를 발견했는지에 대한 이야기입니다. 또한, AddressSanitizer를 처음 접하는 분들이 PostgreSQL 회귀 테스트(Regression Tests)와 함께 실행하는 데 어려움을 겪지 않도록 로컬 환경에서 사용하는 방법도 함께 소개합니다. 버그 발견 사례 최근 저는 몇몇 시스템 카탈로그 함수를 최신 코딩 스타일에 맞춰 옵션 파라미터를 가질 수 있도록 리팩토링하는 #PatchPositivity 패치 시리즈를 제출했습니다. 로컬에서 회귀 테스트를 수행했을 때는 문제가 없었고, Cirrus CI 테스트도 대부분 통과했습니다. 하지만 AddressSanitizer를 사용하는 테스트 단계에서만 실패가 발생했습니다. 출력 결과를 검토하는 방법은 여러 가지가 있지만, 요점만 말씀드리면 다음과 같습니다. 빨간색으로 표시된 Run test_world 섹션은 회귀 테스트 실행 중 실패가 발생했음을 […]

EDB 팀 2026년 2월 6일 AI 거버넌스(AI Governance)는 조직이 인공지능(AI) 시스템을 안전하고 윤리적이며 투명하게 운영하고, 관련 법규를 준수하기 위해 사용하는 정책, 프로세스 및 기술적 통제 수단을 의미합니다. 쉽게 말해, AI를 어떻게 책임감 있게 사용할 것인지, 그리고 문제가 발생했을 때 누구에게 책임이 있는지를 규명하는 핵심적인 체계입니다. 효과적인 AI 거버넌스는 데이터 수집과 모델 학습부터 검증, 배포, 모니터링, 그리고 최종 폐기에 이르기까지 AI 생애주기 전반에 걸쳐 적용됩니다. 이를 통해 AI 시스템이 내린 결정을 인간이 이해하고 감사(Audit)하며, 수정하거나 필요한 경우 직접 개입하여 제어할 수 있도록 보장합니다. 거버넌스는 단일 팀의 업무가 아닙니다. 다음과 같은 조직 간의 긴밀한 협업이 필요합니다: AI 거버넌스의 핵심은 결국 책임성에 있습니다. 시스템이 점점 더 자율화되더라도, 그 결과가 사람, 재정, 안전 또는 […]

EDB 팀 | 2026년 2월 6일 시계열 데이터는 시간이 지남에 따라 추적되는 데이터로, 각 값은 특정 시점과 연결되어 있습니다. 주가, 웹사이트 트래픽, 센서 판독값, 월별 매출 수치 등이 대표적인 예입니다. 시간 자체가 데이터의 일부이기 때문에, 시계열 분석은 단순히 ‘무슨 일이 일어났는가’를 넘어 ‘상황이 어떻게 변하고 있는가’를 조직이 이해하도록 돕습니다. 기업은 시계열 데이터를 분석함으로써 패턴을 식별하고, 이상 징후를 감지하며, 미래의 결과를 예측할 수 있습니다. 이러한 통찰력은 수요 계획, 시스템 모니터링, 예측 유지보수와 같은 중요한 비즈니스 케이스의 원동력이 됩니다. EDB Postgres® AI는 Postgres의 신뢰성과 확장 가능한 성능, 그리고 폭넓은 인공지능(AI) 및 머신러닝(ML) 에코시스템 통합을 결합하여 시계열 워크로드를 지원합니다. 이를 통해 기업은 시간 기반 데이터를 대규모로 효율적으로 분석하고 실행 가능한 인사이트를 도출할 수 […]

EDB 팀 2026년 2월 6일 MariaDB와 PostgreSQL은 세계에서 가장 널리 사용되는 두 가지 오픈소스 관계형 데이터베이스입니다. 두 데이터베이스 모두 소규모 웹 앱부터 대규모 엔터프라이즈 시스템에 이르기까지 다양한 산업 분야의 애플리케이션을 구동하고 있습니다. 둘 다 SQL 기반이며 오픈소스이고 매우 뛰어난 성능을 자랑합니다. 하지만 설계 철학, 기능 세트, 그리고 현대적인 워크로드에 대한 장기적인 적합성 측면에서는 중요한 차이점이 있습니다. 데이터베이스 선택은 장기적인 결과를 초래하기 때문에 이러한 비교는 매우 중요합니다. 성능, 확장성, 확장 가능성, 보안 및 라이선스는 모두 시스템이 비즈니스와 함께 얼마나 잘 성장할 수 있는지에 영향을 미칩니다. 이 가이드에서는 MariaDB와 PostgreSQL의 차이점과 공통점, 그리고 특히 데이터 신뢰성과 엔터프라이즈 지원 역량이 중요할 때 워크로드에 따라 적합한 데이터베이스를 선택하는 방법을 알아봅니다. MariaDB와 PostgreSQL의 차이점은 무엇인가요? […]

Jozef de Vries 2026년 2월 3일 지난주, OpenAI는 단일 프라이머리(Single-primary) 기반의 PostgreSQL 인스턴스를 확장하여 8억 명의 사용자를 수용했던 자신들의 설계 방식을 상세히 공개했습니다. 발표 직후, MariaDB는 자사 제품을 사용했다면 OpenAI가 겪었던 여러 ‘균열’ 없이도 충분히 동일한 규모를 처리했을 것이라 주장하고 나섰습니다. OpenAI가 보여준 방식은 분명 Postgres 설계와 운영에 대한 깊은 전문성을 입증했습니다. 하지만 동시에, 단일 쓰기(Single-writer) 아키텍처로 현대의 방대한 워크로드를 감당하기 위해 팀이 얼마나 뼈를 깎는 노력을 기울여야 하는지도 여실히 보여주었습니다. MariaDB 측의 주장은 차라리 Postgres 생태계를 아예 떠나는 것이 낫다는 의미로 들립니다. 하지만 이에 대한 반론은 명확합니다. 이미 시장의 승자는 Postgres라는 점입니다. Postgres는 전 세계에서 가장 빠르게 성장하는 데이터베이스이며, 매년 실시되는 Stack Overflow 설문 조사에 따르면 지난 10년 동안 […]

2026년 02월 04일 김명준 차장 Consultant, Professional Services | EDB 코리아 Kubernetes 환경이 성숙해지면서 PostgreSQL과 같은 전통적인 RDBMS를 Kubernetes 위에서 운영하는 사례는 더 이상 낯설지 않다. 이미 많은 조직이 프로덕션 환경에서 데이터베이스를 컨테이너 기반으로 운영하고 있다. 하지만 실제 운영 경험이 쌓일수록, “Kubernetes에서 PostgreSQL을 운영한다”는 말이 단순히 배포 방식의 변화를 의미하지 않는다는 점이 분명해진다. 이 글은 Kubernetes 환경에서 PostgreSQL을 운영하는 사람이 자연스럽게 거치게 되는 고민과 선택의 흐름을 정리한 기록이다. 1. 첫 번째 관문: “그냥 올리면 안 되는 이유” Kubernetes에 익숙해질수록, 모든 워크로드를 동일한 방식으로 다루고 싶어진다. 심지어 Postgres는 도커 허브에 공식 이미지를 제공하고 있으니 그 유혹은 더 커질 수밖에 없다. 이미지도 구했으니 그냥 올리면 될 것만 같다. 때문에 여느 프로그램들처럼 PostgreSQL […]

EDB Team (Floor Drees) 2026년 1월 14일 올해 초, 우리는 PostgreSQL 개발에 잠재력을 보이는 동료들이 실제 컨트리뷰터(Contributor)로 성장할 수 있도록 지원하는 “Developer U” 프로그램을 시작했습니다. 저는 개인적으로 개발자들의 성장 배경이나 ‘시작점’에 대한 이야기를 듣는 것을 좋아합니다. 그래서 이 프로그램에 참여한 몇몇 분들과 그들의 동기, 희망, 그리고 그들이 만든 패치(Patch)에 대해 이야기를 나누어 보았습니다. EDB에서의 역할: 성능 평가부터 커뮤니티 지원까지 EDB에서 Mark Wong은 다양한 분야를 다루고 있습니다. 그는 내부 및 외부 사용을 위해 EDB 제품의 성능을 평가하고, 다양한 엔터프라이즈 리눅스 배포판을 사용하는 다수의 빌드 팜(Build Farm) 머신들을 관리하며, 여러 PostgreSQL 행사에서 연사로 활동합니다. 특히 그는 업무 시간 중에 커뮤니티 활동과 오픈소스 기여를 할 수 있는 환경에서 일하고 있습니다. Mark는 원래 OSDL(현재의 […]

EDB Team 2026년 1월 8일 오늘날 기업 환경에서 시스템 다운타임은 수익, 평판, 그리고 비즈니스 회복 탄력성에 치명적인 타격을 입힙니다. 아주 짧은 서비스 중단이라도 수천억원에 이르는 재정적 손실로 직결될 수 있습니다. 데이터베이스(DB), 고객 포털, 혹은 내부 운영 및 온라인 트랜잭션을 처리하는 플랫폼과 같은 미션 크리티컬(Mission-Critical) 시스템이 멈추면, ‘중단 없는 서비스’를 요구하는 내부 팀과 외부 이해관계자 모두에게 즉각적인 영향을 미칩니다. 이 글에서는 다운타임으로 인해 발생하는 비용 증가를 분석하고, 조직이 이를 방어하기 위해 취할 수 있는 전략을 살펴봅니다. 특히 다운타임 완화에 있어 데이터 인프라가 수행하는 핵심적인 역할과, EDB Postgres® AI(EDB PG AI)의 고가용성(HA) 및 분산 아키텍처 지원이 어떻게 예상치 못한 장애 상황에서도 시스템을 온라인 상태로 유지하는지 알아보겠습니다. 다운타임(Downtime) 비용이란 무엇인가? 흔히 ‘다운타임’이라고 하면 […]

EDB Team | 2026년 1월 8일 오늘날 소프트웨어 환경에서 ‘복잡성’은 강력한 무기이자 동시에 취약점이기도 합니다. 현대의 애플리케이션은 오픈 소스 라이브러리, 서드파티 패키지, 플러그인, 그리고 커스텀 코드가 뒤섞인 수천 개의 컴포넌트로 구성됩니다. 이는 개발 속도를 획기적으로 높여주지만, 공급망 취약점이나 오래된 종속성(Dependency)이라는 보이지 않는 리스크를 만들어냅니다. 여기서 소프트웨어 자재 명세서(SBOM, Software Bill of Materials)가 등장합니다. SBOM은 소프트웨어를 구성하는 모든 컴포넌트의 상세 목록, 즉 소프트웨어의 ‘성분 표시 라벨’과 같습니다. 이 목록은 애플리케이션 내부를 투명하게 들여다볼 수 있는 시야를 제공합니다. 이 글에서는 SBOM이 왜 현대 엔터프라이즈에 필수적인지, 어떻게 생성하는지, 그리고 가장 가치 있게 활용되는 분야는 어디인지 살펴봅니다. 또한, EDB Postgres® AI(EDB PG AI)가 PostgreSQL 및 엔터프라이즈 데이터 스택에 대한 SBOM 도입을 어떻게 지원하는지 논의합니다. […]

2026년 01월 08일 윤명식 상무 Consultant, Professional Services | EDB 코리아 서문 2026년 새해가 밝았습니다. 새해는 새로운 시작과 기술에 대한 새로운 다짐을 하기에 더없이 좋은 시간입니다. 지난 한 해 동안 PostgreSQL 18.1이 출시되며 비동기 I/O(AIO), 네이티브 UUID v7 지원 등 개발자를 위한 주요 기능들이 대거 향상되었습니다. 이제 새로운 각오와 함께, 이 글에서는 2026년을 더욱 “PostgreSQL답게 풍요로운(PostgreSQL-prosperous)” 한 해로 만들어 줄 여섯 가지 강력한 기능을 소개하고자 합니다. 1. 시간 제약 (Temporal Constraints): 시간 기반 데이터 무결성 강화 시간 제약이란 ‘이전(before)’, ‘이후(after)’, ‘도중(during)’, ‘까지(until)’와 같이 시간을 기반으로 시스템의 동작을 제어하는 규칙을 의미합니다. PostgreSQL 18부터는 이 기능을 사용하여 시간 경과에 따른 데이터 무결성을 강화할 수 있게 되었습니다. 즉, 특정 날짜나 타임스탬프 범위 내에서만 […]

EDB는 올해 초부터 PostgreSQL 개발에 재능이 있는 동료들을 발굴해 실제 기여자로 성장시키는 ‘Developer U’ 프로그램을 운영하고 있습니다. 저는 인물들의 탄생 설화에 유독 약한 편이라, 프로그램 참가자들을 만나 그들의 동기와 꿈, 그리고 그들이 만든 패치(Patch)에 대해 이야기를 나누고 있습니다. 오늘은 그중에서도 독특한 이력을 가진 매니 우드(Manni Wood)를 소개합니다. 매니는 EDB에서 3년 동안 Go 언어로 마이크로서비스를 개발해 왔습니다. 최근에는 엔지니어링 미팅에서 발표 역량을 보여주며 솔루션 그룹에 합류했고, 현재는 기술 블로그 작성, 가이드 영상 제작, 소프트웨어 트러블슈팅 등을 담당하고 있습니다. 1. 배경: 도서관학 전공자가 컴퓨터에 빠진 이유 매니는 어릴 적부터 컴퓨터를 좋아했지만, 비싼 장비와 접근성 문제로 잠시 꿈을 접고 영문학 학사와 도서관학 석사 과정을 밟았습니다. 하지만 운명이었을까요? 컴퓨터공학 교수진이 문헌정보학 수업에 들어와 ICT를 […]

올해 초, EDB는 PostgreSQL 개발에 잠재력을 가진 동료들이 실제 기여자로 성장할 수 있도록 돕는 ‘Developer U’ 프로그램을 시작했습니다. 저는 사람들의 시작점에 관심이 많기에, 프로그램 참가자들과 만나 그들의 동기, 희망, 그리고 현재 작업 중인 패치(Patch)에 관해 이야기를 나눴습니다. <small>▲ 지난 9월 팀 오프사이트 중인 마리오(오른쪽) (Alt: PostgreSQL 컨트리뷰터 마리오 곤잘레스의 팀 워크샵 모습)</small> 칠레에 거주하며 EDB의 TPA(Trusted Postgres Architect) 팀에서 근무 중인 마리오 곤잘레스는 그간 edb-python, Barman, repmgr 등 다양한 프로젝트에 참여해 온 베테랑 엔지니어입니다. 1. 배경: 리눅스에서 포스트그레스까지 마리오는 어릴 적 Basic 언어를 시작으로 컴퓨터 공학을 전공했습니다. 과거 Mandriva Linux에서 근무하며 gdesklets 및 Gnome 프로젝트에 기여한 경험이 있습니다. PostgreSQL과의 인연은 ‘webtranslator’라는 프로젝트로 시작되었습니다. 이는 pgFoundry에 호스트된 테스트 개념의 프로젝트로, PostgreSQL의 […]

작성자: Shubam Tondare (2025년 12월 17일) 엔지니어링의 도전 과제: 데이터보다 무서운 ‘설정 관리’ 분산 모니터링 시스템에서 확장성(Scalability)을 논할 때, 보통은 “초당 얼마나 많은 메트릭을 수집할 수 있는가?”라는 데이터 수집 능력에 초점을 맞춥니다. 하지만 실제 운영 환경에서 더 큰 병목으로 다가오는 것은 바로 ‘설정 관리(Configuration Management)’입니다. 최고의 성능을 내는 모니터링 도구라도 수백 대의 서버 설정을 일일이 만져야 한다면 운영팀의 생산성은 급격히 떨어집니다. EDB PEM 팀은 최근 에이전트와 서버에 프로브(Probes) 및 알림(Alerts)을 할당하는 방식에서 발생하는 구조적인 불편함을 해결했습니다. ‘템플릿’ 방식이 가졌던 한계 (The Template Bottleneck) 기존의 PEM은 프로브와 알림을 관리할 때 서로 다른 두 가지 방식을 사용했습니다. 여기서 문제가 발생합니다. ‘알림 템플릿’은 존재했지만, 실제로 이를 활성화하려면 관리자가 특정 서버 ID마다 알림을 개별적으로 […]