2026-06-22 / Last updated : 2026-06-22 Grace Technical Blog

CloudNativePG 레플리카 클러스터의 스위치오버와 스위치백 (K8s 분산 토폴로지) – 2부

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-06-08 / Last updated : 2026-06-08 Grace EDB Lab

VM에서 쿠버네티스로: 글로벌 대형 은행 DBA의 여정

Kim Kaluba · 2026년 5월 19일 세계 최대 금융기관 중 하나가 PostgreSQL을 쿠버네티스에 네이티브로 들여오며 데이터베이스 운영을 어떻게 다시 설계했는지, 그리고 모든 엔터프라이즈 DBA가 여기서 무엇을 배울 수 있는지 살펴봅니다. 글로벌 은행 규모로 데이터베이스를 운영한다는 것은, 지구상에서 가장 엄격한 수준의 가동률(uptime), 컴플라이언스, 보안 요구사항 아래에서 일한다는 뜻입니다. 그래서 한 대형 금융기관의 팀이 기존 VM 기반 PostgreSQL 배포를 버리고 쿠버네티스로 옮기기로 결정했을 때, 그 과정에 따르는 기술적·문화적 도전은 결코 가벼운 것이 아니었습니다. 그럼에도 더 안정적이고, 더 확장 가능하며, 더 안전한 환경이라는 가능성은 모든 망설임을 넘어설 만큼 매력적이었습니다. 여기서 얻은 교훈은, 같은 전환을 고민하는 모든 기업에게 값을 매길 수 없을 만큼 귀중합니다. 객석을 기립하게 만든 발표 이 이야기는 Data on Kubernetes Day에서 […]

2026-06-08 / Last updated : 2026-06-08 Grace Technical Blog

AIDB로 구현하는 AI 데이터 파이프라인 자동화

Dr. Sala Muthukrishnan · 2026년 5월 18일 AIDB는 청킹(chunking), 임베딩(embedding), 벡터 인덱싱(vector indexing)으로 이어지는 AI 데이터 준비 파이프라인 전체를 자동화하는 EDB의 Postgres 익스텐션입니다. 새로운 데이터가 들어오는 바로 그 순간, 데이터베이스 내부에서 실시간으로 동작합니다. 실제로 어떻게 작동하는지 보여드리기 위해, 이번 글에서는 수사 스토리 PDF를 활용했습니다. 등장인물과 사건, 그리고 그들 사이의 관계가 빼곡히 담긴 실제 문서를, 별도의 수작업 데이터 가공 없이 쿼리 가능한 지식 베이스로 바꿔 보겠습니다. AIDB가 자동화하는 것, 그리고 그것이 중요한 이유 비정형 문서를 다루는 모든 AI 파이프라인에는 눈에 잘 띄지 않는 공통 비용이 있습니다. 바로 데이터 준비(data preparation)입니다. 단 하나의 쿼리에 답하기 위해서도, 원시 텍스트를 정제하고, 모델이 다루기 좋은 크기로 쪼개고(청킹), 벡터 임베딩으로 변환한 뒤, 검색을 위해 인덱싱하는 과정을 […]

2026-04-24 / Last updated : 2026-04-24 Grace Technical Blog

CloudNativePG 환경에서 Barman Cloud 플러그인을 활용한 PostgreSQL 복제 클러스터 배포 – 1부

Swapnil Suryawanshi 2026년 4월 15일 이 블로그에서는 백업 및 WAL 아카이빙을 위해 Barman Cloud 플러그인을 사용하여 CloudNativePG용 EDB Postgres® AI 복제 클러스터(Replica Cluster)를 설정하는 단계별 프로세스를 설명합니다. 📌 환경 세부 정보 1. 사전 요구 사항: 네임스페이스 및 자격 증명 생성 먼저 프라이머리(Primary) 및 레플리카(Replica) 클러스터를 위한 별도의 네임스페이스를 생성하고, Barman 플러그인이 오브젝트 스토어에 액세스하는 데 필요한 S3 자격 증명을 저장합니다. Bash 프라이머리 네임스페이스에 동일한 AWS 자격 증명을 생성합니다. Bash 레플리카 네임스페이스에 동일한 AWS 자격 증명을 생성합니다. Bash 2. Barman 플러그인 설정 Barman 플러그인은 안전한 통신을 위해 cert-manager가 필요합니다. cmctl 설치를 확인하고 cert-manager를 설치한 후 Barman Cloud 플러그인을 배포합니다. Bash Bash Bash 오퍼레이터의 네임스페이스에 플러그인 매니페스트를 적용합니다. Bash 3. ObjectStore 리소스 […]

2026-04-24 / Last updated : 2026-04-24 Grace EDB Lab

세계에서 가장 안정적인 OS에 고성능 데이터 기반이 필수적인 이유블로그 번역

Ava Chawla 2026년 4월 6일 ITIC(Information Technology Intelligence Consulting)의 글로벌 서버 하드웨어 및 OS 신뢰성 보고서에 따르면, 시스템 중단(Outage)으로 인한 재정적 손실이 임계점에 도달했습니다. 현재 기업의 98%가 단 1시간의 다운타임으로 10만 달러 이상의 비용을 지불하고 있으며, 40%의 조직은 이 비용이 시간당 100만 달러를 훌쩍 넘는다고 보고했습니다. 이러한 막대한 손실을 방지하기 위해서는 인프라에 걸맞은 EDB Postgres와 같은 고성능 데이터 기반이 즉각적으로 마련되어야 합니다. 이러한 위험을 완화하기 위해 조직들은 기술 갱신 주기를 활용하여 RHEL(Red Hat Enterprise Linux)로 인프라를 표준화하고, 기존 가상화(VMware) 환경에서 KubeVirt로의 전환을 가속화하고 있습니다. 하지만 여기서 매우 위험한 사각지대가 발생하고 있습니다. 바로 ‘엔터프라이즈 OS 지원이 데이터베이스까지 자동으로 연장될 것’이라는 착각입니다. 지원의 사각지대: RHEL의 지원이 끝나고 EDB Postgres가 필요한 시점 VMware […]

2026-04-02 / Last updated : 2026-04-02 Grace EDB Lab

에이전트의 혼란: 내가 Postgres 컨트롤 플레인을 결정론적으로 유지하는 이유

작성자: Chris Chiappone 작성일: 2026년 3월 31일 우리는 ‘에이전트 시대’에 살고 있습니다. 매주 새로운 프레임워크가 등장합니다. 이들은 인프라를 자율적인 지능 계층으로 감싸주겠다고 약속합니다. 그 제안은 꽤 매력적입니다. 스크립트 작성은 멈추고 목표만 설정하라는 것입니다. ‘어떻게’ 할지는 AI가 알아서 하도록 놔두라고 말합니다. 하지만 최근 저는 장벽에 부딪혔습니다. Hybrid Manager로 관리되는 EDB Postgres AI 환경의 자동화를 설계하던 중이었습니다. 부하에 따라 클러스터를 자율적으로 확장하는 ‘에이전틱 DB(Agentic DB)’ 아키텍처를 구상하고 있었습니다. 그때 무언가 잘못되었다는 것을 깨달았습니다. 실제 요구사항을 들여다볼수록 ‘에이전트’ 패턴은 문제에 대한 억지 해결책처럼 느껴졌습니다. 핵심 데이터베이스 운영에 있어서는 오히려 퇴보하는 것 같았습니다. 이 글은 제가 왜 그 방향을 철회했는지에 대한 이야기입니다. 또한 Postgres를 위한 가장 강력한 아키텍처가 “모든 것을 에이전트에게 맡기는 것”이 아니라, […]

2026-04-02 / Last updated : 2026-04-02 Grace EDB Lab

EDB Postgres AI Factory 차세대 버전: 에이전트(Agent) 시대를 위한 완벽한 대비

작성자: Jack Christie 작성일: 2026년 3월 31일 매주 새로운 AI 에이전트 데모가 쏟아져 나오지만, 실제 프로덕션 환경에 배포되는 경우는 극히 드뭅니다. 가능성 있는 프로토타입이 신뢰할 수 있는 엔터프라이즈급 에이전트로 안착하지 못하는 이 간극(Gap)에서 수많은 AI 프로젝트들이 좌초됩니다. 그리고 그 원인은 대부분 ‘데이터’에 있습니다. 오늘 EDB는 조직이 직접 통제할 수 있는 데이터를 기반으로 생성형 AI(GenAI) 추론(Inferencing) 환경을 구축하고자 하는 기업들을 위해, 이러한 간극을 완벽히 메워줄 차세대 EDB Postgres AI Factory를 선보입니다. 이러한 변화는 우연이 아닙니다. 시장은 이미 변곡점에 도달했으며, 앞서가는 기업들은 하나의 공통된 특징을 보입니다. 바로 AI를 단순한 ‘프로젝트’가 아닌 핵심 ‘인프라(Infrastructure)’로 다루기 시작했다는 점입니다. 현실화된 위협, 그리고 갈수록 벌어지는 격차 13개국 2,050명의 엔터프라이즈 리더를 대상으로 한 글로벌 연구 결과는 현재의 […]

2026-04-02 / Last updated : 2026-04-02 Grace EDB Lab

WarehousePG가 단일 클러스터로 처리하는 작업을 타 분석 DB는 여러 클러스터로 처리해야 하는 이유

작성자: Dave Stone 작성일: 2026년 3월 31일 (본 포스트는 Jack Christie와 Dave Stone이 공동 작성했으며, 2026년 3월 31일 최신 인사이트를 반영하여 업데이트되었습니다.) 비즈니스 데이터 조회가 예산 초과를 초래할 때 “50TB 규모의 클라우드 데이터 웨어하우스를 조회하는 데 드는 막대한 비용 때문에 골머리를 앓고 있습니다.” 이는 교보문고(Kyobo Book Centre) 정흥식 IT 지원팀장의 말입니다. 최근 기업들 사이에서 이와 유사한 문제가 자주 발생하고 있습니다. 클라우드 데이터 웨어하우스의 종량제(Consumption-based) 과금 모델은 데이터 엔지니어링에 매우 매력적입니다. 하지만 고도화된 동시성 BI 워크로드를 만나면 상황이 달라집니다. 수백 명의 비즈니스 사용자가 동시에 대시보드를 새로고침합니다. 리포트를 심층 분석하고 실시간 쿼리를 실행합니다. 이때 전혀 예측 불가능한 비용이 발생하게 됩니다. 교보문고의 비즈니스 데이터는 50TB를 넘었고 계속 증가 중이었습니다. 소규모 분석팀이 Tableau 사용자들을 […]

2026-03-30 / Last updated : 2026-03-30 Grace Technical Blog

미세한 변화: PostgreSQL의 NOT VALID와 NOT ENFORCED 제약 조건 이해하기

작성자: Amul Sul 작성일: 2026년 3월 27일 PostgreSQL은 뛰어난 데이터 무결성(Data Integrity)을 자랑하는 것으로 잘 알려져 있습니다. 하지만 데이터 세트가 테라바이트 단위로 커짐에 따라, 이러한 무결성을 유지하기 위한 비용이 시스템의 병목 현상(Bottleneck)을 유발하기도 합니다. 이러한 문제를 해결하기 위해 PostgreSQL은 제약 조건(Constraints)에 대한 다양한 “상태(States)”를 제공하고 있습니다. 많은 분들이 기존의 NOT VALID 옵션에는 익숙하시겠지만, 최근 SQL:2023 표준의 새로운 개념이 도입되었습니다. 바로 PostgreSQL 18에 공식적으로 추가된 NOT ENFORCED입니다. 이 두 가지는 이름만 보면 비슷하게 들릴 수 있지만, 데이터베이스의 라이프사이클 내에서 매우 다른 역할을 수행합니다. 💡 TL;DR (핵심 요약) PostgreSQL에서 제약 조건은 단순히 엄격하게 “켜짐(On)” 또는 “꺼짐(Off)” 상태로만 존재하는 것은 아닙니다. 참고: PostgreSQL 18 기준으로 NOT ENFORCED 상태는 CHECK 및 외래 키(FOREIGN KEY) […]

2026-03-30 / Last updated : 2026-03-30 Grace EDB Lab

[웨비나 다시보기] 실전! PostgreSQL 기반 AI & 벡터 DB 완벽 가이드 (pgvector, VectorChord, AIDB)

AI와 결합된 애플리케이션을 개발하고 계시나요? 최근 생성형 AI와 RAG(검색 증강 생성) 기술이 대세로 떠오르면서, 방대한 벡터 데이터를 어떻게 효율적으로 관리하고 검색할 것인지가 핵심 과제가 되었습니다. 하지만 복잡한 파이프라인 구성과 외부 연동 때문에 막막함을 느끼셨다면, 이번에 공개된 ‘PostgreSQL 기반 AI & 벡터 DB’ 웨비나를 반드시 확인해 보세요. 단순한 이론 설명을 넘어 실무에 즉시 적용할 수 있는 강력한 인사이트를 담았습니다. 🎥 웨비나 다시보기 영상 아래 영상에서 오픈소스 pgvector를 활용한 시맨틱 검색부터 초고속 VectorChord, 그리고 All-in-one 솔루션인 AIDB까지 직접 확인해 보세요! 💡 이번 영상에서 다루는 핵심 내용 본 웨비나에서는 텍스트, 이미지 등 다양한 형태의 데이터를 벡터로 변환하고 검색하는 과정을 실제 데모와 함께 상세히 설명합니다. 👨‍💻 이런 분들께 강력히 추천합니다!

2026-03-23 / Last updated : 2026-03-23 Grace Technical Blog

[실전 가이드] EDB Postgres® AI와 NVIDIA RAPIDS 가속기를 활용한 GPU 가속 쿼리 실행

작성일: 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 […]

2026-03-23 / Last updated : 2026-03-23 Grace EDB Lab

에이전틱 분석(Agentic Analytics)을 위한 대규모 확장성과 예측 가능한 성능 달성

작성자: Dunith Danushka 작성일: 2026년 3월 16일 EDB Postgres® AI 소개: NVIDIA RAPIDS 가속기를 통한 Apache Spark 기반 GPU 성능 최적화 에이전틱 워크포스 시대의 분석 환경 EDB의 ‘소버린(Sovereignty)의 중요성‘ 연구에 따르면, 엔터프라이즈 기업 중 단 13%만이 생성형 AI 파일럿 단계를 넘어 실제 운영 규모의 에이전틱 배포를 성공적으로 완료했습니다. 이는 자율형 업무(Autonomous work)를 확장하는 것이 얼마나 어려운 과제인지를 여실히 보여줍니다. 이러한 에이전틱 워크포스(Agentic Workforce) 시대에 기업이 직면한 핵심 과제는 바로 데이터베이스 관리의 한계입니다. 자율 AI 에이전트는 인간 기반의 워크로드보다 훨씬 더 가변적이고 예측 불가능한 대규모 쿼리 패턴을 지속적으로 생성합니다. 이로 인해 인프라 팀은 OLTP(트랜잭션 처리)와 OLAP(분석 처리) 수요를 동시에 충족해야 한다는 엄청난 압박을 받게 됩니다. 결국 비용이 많이 드는 ETL(추출, 변환, […]

2026-03-18 / Last updated : 2026-03-18 Grace Technical Blog

JSON 데이터의 구조를 완벽하게 검증하는 방법

작성자: Andrew Dunstan 작성일: 2026년 3월 10일 PostgreSQL jsonb 타입의 가장 큰 장점은 유연성입니다. 열(Column)을 미리 정의하지 않고도 필요한 구조를 무엇이든 저장할 수 있죠. 하지만 이러한 유연성에는 대가가 따릅니다. 잘못된 데이터가 들어오는 것을 막을 방법이 마땅치 않다는 점입니다. jsonb 컬럼에 **CHECK 제약 조건(CHECK constraint)**을 걸 수는 있지만, 단순한 구조를 넘어선 검증 로직을 SQL이나 PL/pgSQL로 작성하다 보면 코드가 금세 복잡하고 지저분해지기 일쑤입니다. 필자는 이 문제를 해결하기 위해 **json_schema_validate**라는 PostgreSQL 확장 모듈을 개발해 왔습니다. 이 모듈을 사용하면 데이터베이스 내에서 직접 JSON 및 JSONB 데이터를 JSON 스키마(JSON Schema) 규격에 맞춰 검증할 수 있습니다. 애플리케이션 코드에서 JSON 스키마를 사용해 보셨다면 익숙한 개념일 것입니다. 그 로직이 이제 PostgreSQL 내부에서 실행되는 것입니다. 왜 데이터베이스에서 검증해야 할까요? […]

2026-03-18 / Last updated : 2026-03-18 Grace Technical Blog

Postgres Distributed: OpenAI 데이터베이스 계층을 위한 네이티브 진화 경로

작성자: Anil Kumar 작성일: 2026년 3월 5일 OpenAI의 PostgreSQL 확장성 트레이드오프 OpenAI는 현재 8억 명 이상의 사용자를 지원하는 데이터베이스 아키텍처를 운영하며, 지속적인 글로벌 수요에 대응하기 위해 PostgreSQL의 한계를 넓혀가고 있습니다. OpenAI 팀은 Azure Flexible Server 환경에서 싱글 프라이머리(Single Primary) 아키텍처를 유지하며 “엄격한 SQL 리뷰”, “5초 스키마 타임아웃”, 그리고 쓰기 부하가 큰 데이터를 Azure CosmosDB로 분산하는 “폴리글랏(Polyglot)” 접근 방식을 통해 이른바 ‘운영의 기적*을 일구어냈습니다. 하지만 이러한 복잡성은 물리적 스트리밍 복제(Physical Streaming Replication, PSR)의 구조적 한계에서 기인합니다. PSR은 유연한 수평 확장을 제한하며, 장애 조치(Failover) 시 시스템을 취약하게 만듭니다. 또한 블록 수준의 일관성에 의존하기 때문에 복제 지연을 동적으로 제어하거나 서비스 중단 없는 DDL 변경이 사실상 불가능합니다. 이는 결국 엔지니어링 팀이 SEV-0 장애를 막기 […]

2026-03-03 / Last updated : 2026-03-03 Grace 고객사례

DBaaS의 함정에서 벗어나기: PostgreSQL의 운영 독립성 확보 전략

작성자: Gabriele Bartolini 작성일: 2026년 2월 26일 오늘날 우리가 마주한 VUCA(P) 세상(변동성, 불확실성, 복잡성, 모호성 및 역설)에서 디지털 주권(Digital Sovereignty)은 더 이상 이론적인 논의에 그치지 않습니다. 이는 기업의 생존을 위한 필수 요건이 되었습니다. 변화에 적응하는 것만이 유일한 상수인 이 환경에서 데이터는 AI 혁명의 핵심 연료이며, 데이터를 제어하는 능력은 곧 해당 기업이 AI의 미래를 소유할 수 있는 능력과 직결됩니다. 글로벌 불확실성을 헤쳐나가고자 하는 기업들에 있어 그 여정은 스택의 가장 중요한 계층인 데이터베이스에 대한 통제권을 되찾는 것에서 시작됩니다. 오늘은 EDB가 20년 이상 구축과 발전을 도와온 데이터베이스, PostgreSQL에 대해 이야기하고자 합니다. 소버린티(주권)의 역설 탐구 VUCA(P)에서 ‘P(Paradox, 역설)’는 현대 기술 전략의 핵심 동인입니다. 이는 빠른 혁신에 대한 요구와 완벽한 데이터 통제권이라는, 겉으로 보기에는 상충하는 […]

2026-03-03 / Last updated : 2026-03-03 Grace 📬EDB 엔지니어링 뉴스레터

DB 엔지니어링 뉴스레터 #16

발행일: 2026년 3월 2일 작성자: EDB 엔지니어링 팀 열여섯 번째 뉴스레터가 도착했습니다. 아이디어 구상 단계부터 실제 코드 구현에 이르기까지, 지난 한 달간 EDB 엔지니어링 팀이 쏟은 고민과 성과를 여러분께 공유합니다. 🔍 업계가 주목하는 기술 뉴스 ggml.ai, Hugging Face와 손잡다 Georgi Gerganov의 ggml.ai가 Hugging Face의 가족이 되었습니다. 누구나 개인 하드웨어에서 로컬 AI를 더 쉽고 효율적으로 실행할 수 있게 하겠다는 공동의 목표를 위해서입니다. 그동안 Llama 3나 Gemma 같은 새로운 모델이 출시되면, 커뮤니티 개발자들이 일일이 llama.cpp로 포팅할 때까지 기다려야 했습니다. 하지만 이번 합병으로 transformers 라이브러리가 ggml 생태계와 직접 호환되면서, 모델 지원까지 걸리는 대기 시간이 며칠에서 몇 시간 단위로 획기적으로 줄어들 전망입니다. 자세한 사항은: https://github.com/ggml-org/llama.cpp/discussions/19759 코딩 에이전트를 위한 ‘제대로 된’ CLAUDE.md 작성법 코딩 에이전트의 […]

2026-02-25 / Last updated : 2026-02-25 Grace EDB Lab

소버린티 갭(Sovereignty Gap): SaaS 중심 Postgres에서 벗어나 EDB와 Red Hat으로 현대화해야 하는 이유

작성자: Jeff Gowan 작성일: 2026년 2월 24일 데이터베이스 시장이 거대한 변곡점을 맞이하고 있습니다. 지난 수년간 시장의 담론은 “어떤 비용을 치르더라도 클라우드로(Cloud at all costs)”였습니다. 하지만 많은 대기업, 정부 기관, 그리고 금융 기관이 직면한 현실은 다릅니다. 인프라, 보안, 데이터 거주지에 대한 절대적인 통제권을 유지하는 데이터 주권(Data Sovereignty)은 선택이 아닌 필수이기 때문입니다. 최근 Postgres 생태계에서 눈에 띄는 변화가 일어나고 있습니다. Crunchy Data와 같은 전문 프로바이더들이 자사의 관리형 서비스인 “Crunchy Bridge”로 급격히 피벗(Pivot)하고 있습니다. 물론 SaaS는 일부에게 유효한 경로일 수 있지만, 가장 복잡하고 미션 크리티컬한 요구사항을 가진 온프레미스(On-premises) 고객들을 소외시키는 결과를 초래하기도 합니다. 만약 여러분의 데이터베이스 벤더가 여러분이 사용할 수 없거나 사용하지 않으려는 클라우드로 자꾸만 등을 떠밀고 있다면, 이제 주권을 되찾아야 할 때입니다. […]

2026-02-25 / Last updated : 2026-02-25 Grace EDB Lab

하이퍼바이저 그 이후: Broadcom/VMware 변화가 데이터베이스 현대화의 결정적 순간인 이유

작성자: Jeff Gowan 작성일: 2026년 2월 24일 엔터프라이즈 IT 환경에서 인프라의 거대한 변화는 대개 마이그레이션과 예산 재할당이라는 고통스러운 과정으로 여겨집니다. 하지만 최근 Broadcom의 VMware 인수가 촉발한 변화는 단순히 불편함을 넘어, 아키텍처를 근본적으로 혁신할 수 있는 절호의 기회를 제공하고 있습니다. VMware의 가격 모델 변경과 구독제로의 강제 전환은 단순한 비용 문제를 넘어, 기업들이 전체 소프트웨어 스택을 처음부터 다시 고민하게 만드는 기폭제가 되고 있습니다. 현재 가상화 전략을 전면 수정해야 하는 상황에 놓이셨다면, 여러분은 매우 드문 ‘플랫폼 전환의 분기점’에 서 계신 것입니다. 이제 질문의 방향을 바꿔야 합니다. “VM을 어디로 옮길까?”가 아니라, “인프라의 뿌리를 바꾸는 이 마당에, 왜 여전히 비싼 레거시 DB에 종속되어 있어야 하는가?”를 물어야 합니다. 단순한 서버 이전이 아닌 ‘현대화’를 추진하십시오 Broadcom이 VMware를 […]

2026-02-25 / Last updated : 2026-02-25 Grace Technical Blog

모놀리식 이미지의 종말: PostgreSQL 18과 쿠버네티스의 동적 확장(Dynamic Extensions)

작성자: Ramalingam Srinivasan 작성일: 2026년 2월 23일 EDB는 데이터베이스 서버, 특히 AI 분야에서 가능한 기술적 한계를 끊임없이 넓혀가고 있습니다. 조직이 확장됨에 따라 거대한 워크로드를 처리할 뿐만 아니라 불변성(Immutability), 선언적 관리(Declarative Management), 분리된 아키텍처(Decoupled Architecture)라는 클라우드의 핵심 원칙을 수용하는 시스템이 필요합니다. 하지만 지난 수년 동안 쿠버네티스 환경에서 AI/벡터(Vector) 서비스와 같은 현대적이고 복잡한 워크로드를 도입하는 데 있어 하나의 고질적인 운영 장애물이 있었습니다. 바로 ‘강력한 확장성’과 ‘엄격한 불변성’ 사이의 충돌입니다. 오늘 포스팅에서는 곧 출시될 PostgreSQL 18과 EDB Postgres® AI (EDB PG AI)에서 이 문제를 해결한 근본적인 기술적 돌파구를 소개하고자 합니다. 데이터베이스 코어와 쿠버네티스 오케스트레이션 계층 모두를 아우르는 이중 혁신을 통해, 이제 확장 모듈(Extensions)을 동적이고 안전하며 진정한 클라우드 네이티브 방식으로 사용할 수 있는 새로운 […]

2026-02-19 / Last updated : 2026-02-19 Grace Technical Blog

Visual Studio 2026 기반 PostgreSQL 확장(Extension) 컴파일 가이드

작성자: Xavier Fischer (공동 저자: Craig Ringer) 작성일: 2026년 2월 17일 Windows 환경에서 PostgreSQL 확장을 직접 빌드하는 과정이 복잡하다고 느끼셨나요? Visual Studio 2026 커뮤니티 에디션을 사용하면 생각보다 간단하게 해결할 수 있습니다. 이번 포스팅에서는 간단한 예제 확장을 직접 컴파일하며 그 과정을 살펴보겠습니다. 1. 사전 준비 사항 시작하기 전에 아래 항목들이 준비되었는지 확인해 주세요. 참고 및 주의사항: > 본 가이드는 Windows 11, PostgreSQL 18.2 64비트, Visual Studio 2026(v145 툴체인) 환경에서 테스트를 마쳤습니다. 최신 환경에서는 과거에 번거로웠던 64비트 툴체인 설정이나 libintl.h 누락 오류 없이 훨씬 매끄럽게 진행됩니다. 2. 단계별 빌드 절차 단계 1: 프로젝트 생성 단계 2: 소스 파일 추가 C 처음에는 헤더 파일 경로가 잡혀있지 않아 코드에 빨간색 에러 밑줄이 표시됩니다. 이제 […]

2026-02-19 / Last updated : 2026-02-19 Grace Technical Blog

AddressSanitizer와 PostgreSQL: 스택 버퍼 오버플로 해결 사례

작성자: Mark Wong 작성일: 2026년 2월 8일 개발자에게 메모리 오염(Memory Corruption) 버그는 가장 까다로운 숙제 중 하나입니다. 이번 포스팅에서는 메모리 오류 탐지 도구인 **AddressSanitizer(ASan)**가 어떻게 실제 버그를 찾아냈는지, 그리고 PostgreSQL 회귀 테스트(Regression Tests) 환경에서 이를 처음 접하는 분들이 로컬에서 어떻게 실행할 수 있는지 간단한 가이드를 소개합니다. 1. 사건의 발단: “내 로컬에선 잘 되는데?” 최근 저는 최신 코딩 스타일을 적용하기 위해 몇 가지 시스템 카탈로그 함수를 리팩토링(Refactoring)하는 패치를 제출했습니다. 선택적 매개변수(Optional parameters)를 추가하는 작업이었죠. 제 로컬 환경에서 수행한 회귀 테스트는 모두 통과했습니다. 심지어 Cirrus CI의 대부분의 테스트 항목도 모두 통과했죠. 하지만 딱 하나, AddressSanitizer를 사용하는 테스트 세션에서만 빨간불이 들어왔습니다. 테스트 결과를 분석하는 방법은 여러 가지가 있지만, 간단히 말씀드리면 빨간색으로 표시된 Run […]

2026-02-13 / Last updated : 2026-02-13 Grace EDB Lab

AI 붐의 정점? 아니, 이제 겨우 시작일 뿐입니다

These Enterprise Leaders’ View of the AI Boom Is That It’s Just Starting, Not Peaking Contributor Content ByMatthew Kayser 현대 기업 AI 아키텍처에서 ‘데이터 주권’이 갖는 의미 최근 언론에서는 전 세계적인 3조 달러 규모의 AI 투자 붐이 비극적인 결말로 끝날 수 있다고 경고합니다. 데이터 센터와 컴퓨팅 인프라에 쏟아 부은 막대한 자본이 결코 회수되지 못할 것이라는 논리죠. “만약 AI 거품이 터진다면?”이라는 질문은 충분히 던질 수 있는 의문입니다. 하지만 이 질문은 현재 전 세계 이사회가 직면한 더 큰 진실을 놓치고 있습니다. 글로벌 기업들은 현재의 상황을 거품이 아닌, 도약을 위한 활주로로 보고 있습니다. 오픈 소스 포스트그레스(PostgreSQL) 기반의 AI 및 데이터 플랫폼 전문 기업인 EDB의 최신 연구에 따르면, 전 세계 리더의 97%가 향후 3년 […]

2026-02-11 / Last updated : 2026-02-19 Grace EDB Lab

특정 벤더의 함정 탈출: 진정한 오픈소스가 데이터 주권을 위한 최선의 길인 이유

Kim Kaluba February 09, 2026 단일 벤더의 함정 극복: 진정한 오픈 소스가 데이터 주권으로 가는 최선의 길인 이유 오픈 소스의 약속은 언제나 명확했습니다. 바로 ‘전략적 자유’입니다. 하지만 오늘날 그 약속이 위협받고 있습니다. MySQL과 같은 많은 기초 오픈 소스 기술들이 단일 벤더의 통제 아래 놓이면서, 로드맵이 억제되고 배포 옵션이 제한되는 ‘벤더 함정’에 빠지고 있기 때문입니다. 이러한 현상은 세계에서 가장 인기 있는 두 오픈 소스 데이터베이스인 MySQL과 PostgreSQL의 서로 다른 행보에서 극명하게 드러납니다. 벤더 주도형 혁신의 쇠퇴 특정 기업이 오픈 소스 솔루션을 독점적으로 제어하게 되면, 혁신은 커뮤니티의 필요가 아닌 기업의 이익과 우선순위에 따라 결정됩니다. 데이터가 이를 증명합니다. 2006년에서 2025년 사이, MySQL의 커밋(Commit) 횟수는 최고치인 26,748개에서 4,725개로 급감했습니다. 이러한 기여도의 감소는 기술적 허들에 […]

2026-02-11 / Last updated : 2026-02-11 Grace Technical Blog

PostgreSQL과 AddressSanitizer를 활용한 스택 버퍼 오버플로우 탐지 실습

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

2026-02-10 / Last updated : 2026-02-10 Grace Technical Blog

AI 거버넌스란 무엇인가?

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