EDB, 포스트그레스로 업무 DB·분석·AI까지 한 번에 묶겠다고 나섬

• EDB가 기업용 DB 시장에서 포스트그레스 기반 통합 플랫폼으로 판을 넓히겠다고 나섬

  • 기존 업무 처리용 DBMS만 파는 게 아니라, 데이터 분석과 AI 운영까지 한 프로그램 안에서 처리하겠다는 전략임
  • 이름은 에이전틱 레이크하우스이고, 핵심은 업무 데이터, 분석 데이터, AI 추론 데이터를 따로 흩어놓지 않는 것임

• EDB가 밀고 있는 메시지는 꽤 직설적임. “데이터를 복사해서 AI로 보내지 말고, AI를 데이터가 있는 곳으로 가져오자”는 얘기임

  • 기존 구조에서는 운영 DB에서 분석 DB로 데이터를 복사하거나 옮기는 데 수 시간이 걸릴 수 있음
  • AI가 고객 응대나 거래 판단을 하려면 어제 만들어진 복사본이 아니라 지금 이 순간의 실제 데이터가 필요하다는 논리임
  • 그래서 EDB는 트랜잭션 처리, 분석, AI 추론을 하나의 포스트그레스 플랫폼에서 처리하는 방향을 제시함

• 벤더 종속 탈피도 EDB가 강하게 미는 포인트임

  • 허베 팀싯 EDB 최고수익책임자(CRO)는 기업들이 자기 데이터로 다른 회사 AI를 학습시킨 뒤 그 결과를 다시 사는 구조를 원치 않는다고 말함
  • 오라클이나 스노우플레이크처럼 자사 생태계 중심으로 돌아가는 상용 소프트웨어 시장을 겨냥한 발언임
  • EDB는 포스트그레스를 기반으로 내부 서버, 국내 데이터센터, 해외 클라우드 어디서든 같은 방식으로 쓸 수 있다는 점을 강조함

• 국내 도입 사례로는 현대자동차, 교보문고, 신한EZ손해보험, IBK기업은행, 카카오 등이 언급됨

  • EDB에 따르면 국내에서 1000여 개 기업이 포스트그레스를 운영 중임
  • EDB는 이 사례들을 앞세워 “오픈소스 DB는 불안하다”는 기업 시장의 우려를 줄이려는 분위기임
  • 팀싯 CRO도 EDB 선택에는 기술력뿐 아니라 “이 기술을 써도 안전하다”는 믿음이 크게 작용한다고 설명함

• 성능 사례로 가장 눈에 띄는 건 음원 결제업체 샵캐스트임

  • 샵캐스트는 유튜브와 음악 스트리밍 서비스에서 발생하는 저작권료 정산 시스템을 운영함
  • 기존에는 한 번 정산하는 데 최대 18시간이 걸렸고, 처리할 때마다 전담 직원 3명이 붙어야 했음
  • EDB 제품으로 바꾼 뒤 정산 처리 시간은 55분으로 줄었고, 18시간 기준으로 95% 단축된 셈임
  • 운영 비용은 60% 줄었고, 실시간 집계는 5초 안에 끝난다고 함
  • AI가 잘못된 정산을 사전에 잡아내는 비율은 99.2%였고, 저작권 분쟁 해결 기간도 21일에서 3일로 줄었다고 밝힘

• 교보문고 사례는 “업무 DB와 분석 DB를 합치면 뭐가 좋아지냐”를 보여주는 쪽임

  • 기존에는 기간계 업무용 DB와 분석용 DB를 따로 운영했음
  • EDB 전환 뒤 두 시스템을 하나로 합쳤고, 비용은 절반으로 줄었다고 함
  • 처리 속도도 50% 빨라졌다는 게 EDB 측 설명임

• EDB가 보는 AI 도입의 병목은 모델보다 데이터 플랫폼 쪽에 가까움

  • 기업 경영진의 95%가 AI 시스템을 내부에 구축하려 하지만, 실제 운영 단계까지 간 기업은 13%에 불과하다고 EDB는 설명함
  • 이유로는 복잡한 데이터 구성과 큰 초기 비용이 꼽힘
  • EDB는 통합 패키지인 시그니처 익스피리언스로 이 복잡성을 줄이겠다고 밝힘

• 다음 관전 포인트는 6월 25일 글로벌 행사임

  • EDB는 이 자리에서 10개의 시그니처 익스피리언스 제품을 공개할 예정임
  • 지금 발표가 비전과 국내 사례 중심이었다면, 실제 제품 구성이 얼마나 구체적인지가 다음 체크포인트가 될 듯함

---

기술 맥락

• 여기서 EDB가 고른 기술적 선택은 포스트그레스 위에 업무 처리, 분석, AI 추론을 함께 올리는 방식이에요. 왜냐면 기업 데이터는 보통 운영계, 분석계, AI용 벡터 스택으로 찢어져 있고, 그 사이를 복사하고 동기화하는 데 시간과 비용이 계속 새거든요.

• 특히 AI 에이전트가 고객 응대나 거래 판단을 한다면 데이터 신선도가 중요해요. 어제 밤 배치로 복사한 데이터는 리포트용으로는 괜찮을 수 있지만, 실시간 판단에는 늦을 수 있어요. EDB가 “데이터를 옮기지 않는다”를 반복해서 말하는 이유가 여기에 있어요.

• 샵캐스트 사례의 18시간에서 55분 단축은 단순 튜닝 성과라기보다 아키텍처 변경의 결과로 보는 게 맞아요. 하둡식 배치 처리나 분리된 분석 구조에서는 큰 작업을 모아서 돌리지만, 통합 플랫폼에서는 정산과 집계, 이상 탐지를 더 가까운 데이터 경로에서 처리할 수 있거든요.

• 한국 기업에는 벤더 종속 이슈도 꽤 현실적이에요. 오라클 같은 상용 DB를 오래 쓴 조직은 라이선스, 감사, 마이그레이션 리스크가 다 비용으로 돌아오는데, 포스트그레스 기반 전환은 그 압박을 줄이면서 AI용 데이터 기반까지 같이 손보겠다는 선택지로 포장되고 있어요.