Skip to the content Skip to the Navigation

EDB 코리아 블로그

  • 공식웹사이트US Website
  • EDB 제품Products
  • 블로그KR Blog
  • 고객사례Customer Stories
  • EDB 문서US Docs
  • 국내 EDB 파트너KR Partners
  • 문의Contact
  • 02.501.5113Top Page

Grace

  1. HOME
  2. Grace
2026-08-05 / Last updated : 2026-08-05 Grace 블로그

🚀 [사전등록 오픈] EDB Postgres AI Summit Seoul 2026: 데이터와 AI로 비즈니스의 판을 바꾸다

2026. 09. 03 (목) 오전 10시 시작  |  서울 송파구 EDB Postgres AISummit Seoul 2026 Change the Game  |  판을 바꾸다 사전 등록하기 ※ 행사장 상세 정보는 최종 참석 승인 메일을 통해 안내해 드립니다. 세션 라인업 전격 공개 삼성전자 · IBK기업은행 · 교보문고,판을 바꾼 기업들이 직접 말합니다 올해 EDB Postgres AI Summit Seoul 2026의 세션 라인업이 공개되었습니다. 국내 대표 금융, 제조, IT 기업들이 PostgreSQL과 AI로 어떻게 비즈니스의 판도를 바꾸고 있는지, 발표 자료가 아닌 직접 겪은 현장의 이야기로 들려드립니다. AI와 데이터로 '검토'가 아닌 실제 성과를 만들어야 한다면, 9월 3일 이 자리에 답이 있습니다. ※ 본 행사는 대한민국 Top-tier 기업의 C-Level 및 IT 의사결정권자 300명을 모시는 프라이빗 행사로, 등록 후 심사를 거쳐 […]

2026-06-26 / Last updated : 2026-06-26 Grace EDB Lab

데이터 분석에서 AI의 역할: 과대광고를 넘어 ‘고옥탄’ 실용성으로

Dunith Danushka · 2026년 6월 25일 “AI 거품” 피로감을 넘어서 솔직해집시다. **”AI 기반 분석(AI-powered analytics)”**이라는 말은 너무 남발된 나머지 의미를 잃어가고 있습니다. 마케팅 브로슈어 속 AI는 프롬프트 한 줄로 모든 데이터 사일로와 예측 난제를 풀어내는 마법봉처럼 보입니다. 반면 데이터 엔지니어나 분석가의 하루하루를 들여다보면, AI는 종종 “환각(hallucination)”으로 만들어진 코드나 손이 많이 가는 모델의 또 다른 출처일 뿐입니다. 우리는 지금 거대한 실용성 간극(utility gap)을 건너고 있습니다. 한쪽에는 전통적인 데이터 분석의 검증된 신뢰성이 있습니다. SQL 쿼리, ETL 파이프라인, 그리고 우리 비즈니스를 돌리는 BI 대시보드 말이죠. 다른 한쪽에는 생성형 AI와 에이전틱 시스템의 전례 없는 잠재력이 있고요. 진짜 마법은 전자를 후자로 갈아치우는 데 있지 않습니다. 둘을 통합하는 데 있습니다. 거품을 넘어서려면, AI를 데이터 실무자의 대체재로 […]

2026-06-26 / Last updated : 2026-06-26 Grace Product Updates

데이터에서부터 쌓아 올리다: 에이전틱 시대를 위한 신뢰할 수 있는 기반 | EDB Postgres® AI Q2-2026 릴리스

데이터에서부터 쌓아 올리다: 에이전틱 시대를 위한 신뢰할 수 있는 기반 | EDB Postgres® AI Q2-2026 릴리스 Lizzy Nguyen · 2026년 6월 23일 이 글은 Lizzy Nguyen, Maeve Sullivan, Jack Christie가 함께 작성했습니다. 에이전틱 시대는 데이터 계층에 더 많은 것을 요구합니다 오늘날 모든 기업이 똑같은 질문을 던지고 있습니다. AI 에이전트를 어떻게 실험 단계에서 프로덕션으로, 안전하게 그리고 대규모로 옮길 것인가? 이 에이전트들은 사람을 대신해 거의 실시간 속도로 추론하고, 판단하고, 행동합니다. 그만큼 그 아래 모든 것의 기준이 높아집니다. 믿을 수 있는 데이터, 흔들리지 않는 성능, 그리고 그 속도를 따라잡을 만큼 빠른 거버넌스가 필요해지죠. 고객들과 이 이야기를 나누면 늘 같은 긴장이 떠오릅니다. 하나는 인프라가 충분히 민첩하지 못하다는 점입니다. 다른 하나는 자기 데이터에 대한 통제권을 […]

2026-06-26 / Last updated : 2026-06-26 Grace EDB Lab

에이전트는 결국 데이터 문제입니다 — 그리고 EDB Postgres® AI가 그 답이 되었습니다

Dave Stone · 2026년 6월 23일 우리가 만나는 모든 기업은 같은 여정의 어딘가에 서 있습니다. AI 에이전트가 진짜라고 판단을 내렸고, 파일럿을 시작했고, 그러다 벽에 부딪힙니다. 그 벽은 좀처럼 모델 때문이 아닙니다. 대개는 그 아래 깔린 데이터 기반이 문제입니다. 고객들은 자기 데이터를 두고 똑같은 질문을 던집니다. 상호작용 전반에 걸쳐 맥락을 유지할 기억(memory)을 에이전트에게 어떻게 줄 것인가? 우리 고유 데이터를 근거로 추론할 지식은? 엔터프라이즈 규모에서 안정적으로 실행할 운영 기반은? 이건 전부 데이터베이스 문제입니다. 어떤 건 이미 잘 알려져 있고, 어떤 건 제대로 해내는 데 수년의 엔터프라이즈 경험이 필요합니다. 우리가 그동안 고객을 위해 묶어 온 것이 바로 이것입니다. 데이터 자산(data estate) 전반의 AI 워크로드에서 데이터 관리의 마찰을 걷어내는 일이죠. 이 글에서는 우리가 무엇을 […]

2026-06-26 / Last updated : 2026-06-26 Grace EDB Lab

몇 분이면 될 일에 몇 시간을 쓰지 마세요: DBA를 위한 EDB Postgres® AI 에이전틱 데이터베이스 가이드

Charly Batista · 2026년 6월 23일 DBA라면 누구나 이런 아침을 겪어봤을 겁니다. 오전 9시 14분, 개발자가 슬랙으로 메시지를 보냅니다. “저기요, DB가 느려요. 결제(checkout)가 자꾸 타임아웃 나요.” 당신은 콘솔을 열고 느린 쿼리 로그를 뒤지기 시작합니다. pg_stat_statements를 띄우고, 실행 시간을 최근 스키마 변경과 맞춰보고, 통계가 오래된 건 아닌지 확인합니다. 누가 어젯밤에 인덱스를 지운 건 아닐까 의심하다가, 활성 커넥션을 보려고 터미널을 하나 더 엽니다. 그렇게 헤매다 10시 30분쯤, 드디어 범인을 찾습니다. 필터링되는 컬럼에 인덱스가 빠져 있었고, 그게 지난 배포 이후로 결제 쿼리란 결제 쿼리는 죄다 잡아먹고 있었던 거죠. 한 시간 이십 분. 그동안 개발자는 발이 묶였고 고객은 답답해했습니다. 그런데 정작 고치는 데는 10초쯤 걸렸습니다. CREATE INDEX CONCURRENTLY 한 줄이면 끝이었으니까요. 문제를 찾는 것과 […]

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

Buildfarm Query API

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)

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

딱 하루만 비워보세요: AI 보안 해커톤을 직접 열어보고 배운 것들

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

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를 […]

글 페이지 매김

  • Page 1
  • Page 2
  • …
  • Page 9
  • »

카테고리

  • EDB 제품 (10)
  • 고객사례 (9)
  • 블로그 (189)
    • EDB Lab (55)
    • Postgres Tutorials (14)
    • Product Updates (22)
    • Technical Blog (80)
    • 📬EDB 엔지니어링 뉴스레터 (11)
  • 개인정보보호
  • 문의하기

Copyright © EDB 코리아 블로그 All Rights Reserved.

Powered by WordPress with Lightning Theme & VK All in One Expansion Unit

MENU
  • 공식웹사이트
  • EDB 제품
  • 블로그
  • 고객사례
  • EDB 문서
  • 국내 EDB 파트너
  • 문의
  • 02.501.5113