본문으로 건너뛰기
피드

EDB, 포스트그레스 기반 ‘에이전틱 레이크하우스’로 기업 DB 시장 확장

backend 약 6분
vote
0
댓글
북마크

EDB가 포스트그레스 기반 통합 플랫폼으로 업무 처리, 분석, 인공지능 추론까지 한 환경에서 처리하겠다는 전략을 공개했다. 핵심은 데이터를 분석용 저장소나 벡터 스택으로 복사하지 않고, 운영 데이터가 있는 자리에서 바로 분석과 인공지능 워크로드를 돌리겠다는 점이다. 샵캐스트는 정산 시간을 18시간에서 55분으로 줄였고, 교보문고는 비용을 절반으로 낮췄다고 밝혔다.

  • 1

    EDB가 포스트그레스 기반 ‘에이전틱 레이크하우스’ 전략을 공개함

  • 2

    업무 처리, 분석, 인공지능 추론을 하나의 플랫폼에서 처리하는 구조를 내세움

  • 3

    샵캐스트는 정산 시간을 18시간에서 55분으로 줄이고 운영 비용을 60% 절감함

  • 4

    교보문고는 기간계 데이터베이스와 분석용 데이터베이스를 통합해 비용을 절반으로 낮춤

  • 5

    경영진의 95%는 내부 인공지능 시스템을 원하지만 실제 운영 단계까지 간 기업은 13%에 그침

  • EDB가 기업용 데이터베이스(DB) 사업을 ‘업무 처리용 DB’에서 ‘분석·인공지능까지 품는 통합 플랫폼’으로 넓히겠다고 나섬

    • 5일 서울 삼성동 아셈타워 기자간담회에서 ‘에이전틱 레이크하우스’ 전략을 공개함
    • 기반은 포스트그레스(Postgres) 오픈소스 데이터베이스고, 업무 처리·데이터 분석·인공지능 추론을 한 프로그램에서 처리하는 그림임
  • EDB가 찌르는 지점은 명확함. 기업들이 상용 벤더 종속에 꽤 지쳤다는 것

    • 허베 팀싯 EDB 최고수익책임자는 기업들이 “자기 데이터로 다른 회사 인공지능을 학습시킨 뒤 그 결과를 되사는 구조”를 원치 않는다고 말함
    • 오라클, 스노우플레이크처럼 자사 시스템 중심으로 묶는 상용 소프트웨어 구조와 대비해, EDB는 내부 서버·국내 데이터센터·해외 클라우드 어디서든 같은 포스트그레스 기반으로 운영할 수 있다는 점을 강조함

중요

> EDB의 핵심 주장은 “데이터를 옮기지 말자”임. 인공지능 에이전트가 고객 응대나 거래 판단을 하려면 어제 복사한 분석용 데이터가 아니라 지금 운영 중인 실제 데이터가 필요하다는 논리임.

  • 기존 기업 데이터 구조에서는 운영 DB와 분석 DB가 따로 놀면서 데이터 복사 시간이 병목이 됨

    • 업무용 DB에서 분석용 DB로 데이터를 복사·이동하는 데만 수 시간이 걸릴 수 있음
    • EDB는 이 구조를 없애고, 원본 데이터가 있는 자리에서 분석과 인공지능 추론을 같이 돌리는 쪽으로 플랫폼을 구성하겠다는 입장임
  • 숫자로 가장 세게 나온 사례는 음원 결제업체 샵캐스트임

    • 유튜브·음악 스트리밍 서비스 저작권료 정산 시스템에서 기존에는 한 번 정산하는 데 최대 18시간이 걸렸음
    • EDB 제품으로 바꾼 뒤 정산 처리 시간이 55분으로 줄어 95% 단축됐다고 밝힘
    • 운영 비용은 60% 줄었고, 실시간 집계는 5초 안에 끝난다고 함
    • 인공지능이 잘못된 정산을 사전에 잡아내는 비율은 99.2%, 저작권 분쟁 해결 기간은 21일에서 3일로 줄었다고 제시함
  • 국내 대기업 레퍼런스도 꽤 공격적으로 꺼냈음

    • EDB는 국내에서 1000여 개 기업이 포스트그레스를 운영 중이라고 설명함
    • 오픈소스 전환을 완료했거나 추진 중인 대표 사례로 현대자동차, 신한EZ손해보험, IBK기업은행, 교보문고, 카카오를 언급함
    • 팀싯 최고수익책임자는 기술력만큼이나 “이 기술을 써도 안전하다는 믿음”이 선택에 크게 작용한다고 말함
  • 교보문고 사례는 ‘DB 두 벌 살림’을 줄인 케이스로 소개됨

    • 기존에는 기간계 업무용 DB와 분석용 DB를 따로 운영했음
    • EDB 전환 뒤 두 시스템을 하나로 합쳤고, 비용은 절반으로 줄었으며 처리 속도는 50% 빨라졌다고 함
    • 김희배 EDB코리아 지사장은 기업이 결국 원하는 건 데이터 통합과 비용 절감이라고 정리함
  • 인공지능 도입 의지는 큰데 실제 운영까지 가는 기업은 아직 적다는 수치도 나옴

    • EDB에 따르면 기업 경영진의 95%가 인공지능 시스템을 내부에 구축하려 함
    • 하지만 실제 운영 단계까지 간 기업은 13%에 그침
    • 이유는 데이터 구성이 복잡하고 초기 비용이 크기 때문이라고 봄
  • EDB는 이 간극을 ‘시그니처 익스피리언스’라는 통합 패키지로 공략할 계획임

    • 인공지능을 원하는 기업은 많지만, 운영까지 가는 과정의 복잡성이 발목을 잡는다는 설명임
    • EDB는 오는 25일 글로벌 행사에서 10개의 시그니처 익스피리언스 제품을 공개할 예정임

기술 맥락

  • 이번 얘기의 핵심은 데이터베이스를 단순 저장소로 보지 않는다는 점이에요. 예전에는 운영 DB에서 데이터를 뽑아 분석 DB나 데이터 웨어하우스로 옮긴 뒤 리포트나 모델 입력에 쓰는 식이 많았거든요. 그런데 인공지능 에이전트가 실시간 판단을 하려면 그 지연이 바로 품질 문제로 이어져요.

  • EDB가 포스트그레스를 앞세우는 이유도 여기 있어요. 기업 입장에서는 오라클 같은 상용 DB를 완전히 버리는 게 무섭지만, 벤더 락인과 비용 압박도 계속 커져요. 포스트그레스 기반이면 기존 트랜잭션 업무를 유지하면서 분석과 인공지능 쪽 확장을 같은 생태계 안에서 가져갈 수 있다는 계산이에요.

  • 샵캐스트 사례가 중요한 건 숫자가 꽤 구체적이기 때문이에요. 정산 시간이 18시간에서 55분으로 줄고, 실시간 집계가 5초 안에 끝난다는 건 단순한 비용 절감이 아니라 업무 운영 방식 자체가 바뀐다는 뜻이거든요. 저작권 분쟁 해결 기간이 21일에서 3일로 줄었다는 대목도 데이터 처리 지연이 실제 비즈니스 리스크였다는 걸 보여줘요.

  • 다만 이런 통합 플랫폼은 만능 스위치가 아니에요. 운영 DB, 분석 워크로드, 벡터 데이터, 인공지능 추론을 한 플랫폼에서 다루려면 성능 격리와 장애 대응 설계가 더 중요해져요. 그래서 EDB가 국내 대기업 레퍼런스를 계속 강조하는 것도 “포스트그레스로 미션 크리티컬 업무가 되느냐”는 시장의 의심을 먼저 걷어내려는 움직임으로 보면 돼요.

기업 데이터베이스 시장에서 오픈소스 전환은 이제 비용 절감 얘기만은 아님. 인공지능 에이전트가 실제 업무 데이터를 바로 써야 하는 상황이 오면서, 데이터 이동을 줄이는 아키텍처가 꽤 현실적인 경쟁 포인트가 됐음.

댓글

댓글

댓글을 불러오는 중...

backend

Elixir 1.20, 이제 점진적 타입 언어로 한 발 들어감

Elixir 1.20은 타입 애노테이션 없이 모든 Elixir 프로그램에 타입 추론과 점진적 타입 검사를 적용하는 첫 개발 마일스톤을 담았음. 목표는 기존 동적 코드베이스에서 거짓 양성을 낮게 유지하면서, 실제 런타임에서 터질 버그와 죽은 코드를 잡아내는 것임.

backend

Gleam 1.17.0, 단일 파일 BEAM 실행 파일과 IDE 편의 기능을 잔뜩 추가했다

Gleam 1.17.0이 공개되면서 Erlang VM용 단일 파일 실행 배포 방식인 escript export를 공식 지원한다. 여기에 변수 참조 하이라이트, todo 상수 표현식, import 제안, 패턴 매칭 최적화, 여러 언어 서버 코드 액션, 보안 수정까지 포함됐다.

backend

인텔, 클라우드·통신사·에이전틱 AI용 제온6+ 정식 출시

인텔이 E코어 기반 서버 프로세서 제온6+를 정식 출시했다. 인텔 18A 공정, 리본펫, 파워비아, 포베로스 3D, EMIB까지 파운드리 기술을 총동원해 소켓당 최대 288코어를 밀어 넣은 제품이다. 인텔은 오래된 제온 서버를 제온6+로 바꾸면 랙과 서버 수를 크게 줄이고, 확보한 전력·공간을 AI 인프라로 돌릴 수 있다고 강조한다.

backend

내구성 있는 워크플로, 꼭 거창한 DB가 필요할까? SQLite로도 충분하다는 주장

Obelisk 글은 내구성 있는 실행에서 정말 중요한 건 비싼 인프라가 아니라 워크플로 상태를 오래 보존하는 것이라고 주장한다. 많은 AI 에이전트나 실험성 워크플로에서는 SQLite 파일과 Litestream 백업만으로도 충분하고, 고가용성 공유 DB가 필요한 시점에 Postgres로 가면 된다는 얘기다.

backend

DBOS 주장: Durable Workflow, 오케스트레이터 말고 Postgres로 충분하다

DBOS는 durable workflow를 구현할 때 Temporal, Airflow, AWS Step Functions 같은 외부 오케스트레이터가 꼭 필요하지 않다고 주장한다. 핵심 아이디어는 워크플로우 상태를 어차피 데이터베이스에 체크포인트로 저장한다면, Postgres 자체를 오케스트레이터처럼 쓰는 편이 더 단순하다는 것이다. 확장성, 가용성, 관측성, 보안까지 Postgres 운영 경험을 그대로 활용할 수 있다는 게 글의 논지다.