한 번에 일어난 세 가지의 변화
문제는 데이터베이스가 오래되었다는 점이 아닙니다. 기반 플랫폼이 변화에 대응하는 속도보다 워크로드의 형태와 요구사항이 더 빠르게 달라지고 있다는 점입니다.
1. 정책만의 문제가 아닌 소버린티(Sovereignty)
데이터가 어디에 저장되는지, 누가 접근할 수 있는지, 어떤 국가의 법률과 규제를 적용받는지는 더 이상 단순히 조달 관련 서류에서 확인하는 사항이 아니라 시스템 아키텍처를 설계할 때 반드시 고려해야 하는 핵심 요소입니다.
EDB의 글로벌 조사에 따르면, 현재 기업의 24%가 데이터 주권을 비즈니스 운영에 필수적인 요소로 인식하고 있으며, 61%는 향후 3년 이내에 데이터 주권이 필수 요소가 될 것으로 예상하고 있습니다.
이제 워크로드를 실행할 수 있는 위치를 제한하는 플랫폼은 기업의 비즈니스 운영과 성장 가능성까지 제약하는 요인이 되고 있습니다.
2. 데이터 플랫폼과 AI 플랫폼의 통합
AI 에이전트는 운영 데이터를 읽고 쓰며, 벡터 검색은 별도의 시스템이 아닌 트랜잭션 처리 환경과 함께 실행됩니다.
정보 검색 및 검색 증강 생성(RAG)에 필요한 데이터 조회 역시 기업의 공식 원천 데이터 시스템(System of Record)을 기반으로 이루어집니다.
이러한 융합을 배경으로 기업의 95%가 향후 3년 이내에 자체 AI 및 데이터 플랫폼을 구축할 계획이라고 응답했습니다.
하지만 이를 실현하기 위해 요구되는 기술적 요건은 대부분의 기존 데이터베이스 운영 환경이 설계될 당시 고려했던 요구사항과는 다릅니다.
3. 새로운 영역으로 이동하는 컴퓨터 환경
이식성(Portability)은 더 이상 솔루션 도입 시 고려하는 선택 사항이 아니라 필수적인 운영 요건이 되었습니다.
하이브리드 운영 환경, 데이터 주권 요건을 충족하는 리전, 그리고 최근 부상하고 있는 네오클라우드(Neocloud)까지 다양한 환경을 지원해야 합니다.
특히 네오클라우드는 AI 워크로드의 실행 비중이 점차 높아지고 있는 GPU 특화 클라우드 서비스 제공업체를 의미합니다.
이러한 환경이 확대됨에 따라 데이터 계층 역시 워크로드가 실행되는 위치에 맞춰 유연하게 이동하고 운영될 수 있어야 합니다.
하나의 플랫폼이 아닌, 하나의 패턴
데이터베이스 마이그레이션을 계획하는 것이 이례적인 일처럼 느껴진다면, 실제로는 그렇지 않습니다. 서로 다른 4개 공급업체에서 3년도 채 되지 않는 기간 동안 발생한 다음 네 가지 공개 사례를 살펴보세요.
시기 | 플랫폼 | 주요 변화 |
|---|---|---|
2024. 05 | Greenplum® | Broadcom의 Tanzu는 향후 출시되는 Greenplum 버전을 비공개 소스(Closed Source) 모델로 전환하고, 공개 코드 저장소를 읽기 전용으로 보관 처리했습니다. 2023년 9월에 출시된 Greenplum 7.0.0이 마지막 주요 오픈소스 릴리스입니다. |
2025. 09 | MySQL® | Oracle®은 MySQL 핵심 개발팀의 시니어 엔지니어 약 70명을 감원했습니다. 이후 2026년 2월, Percona가 주도한 공개서한을 통해 Oracle에 독립적인 MySQL 재단 설립을 요청했습니다. |
2026 | Crunchy Data | Snowflake®에 인수되면서 독립적인 Postgres 공급업체 한 곳이 시장에서 사라졌습니다. |
2027. 12 | SAP® ASE 16.0 | SAP가 공식 발표한 일정에 따라 일반 유지보수(Mainstream Maintenance)가 종료될 예정입니다. ASE 16.1의 유지보수는 2030년 12월까지 제공됩니다. |
이러한 사례는 모두 공급업체가 공식적으로 발표한 조치이거나 제3자가 보도한 사건으로, 미래에 대한 예측이 아닙니다. 각각의 사례만 놓고 보면 IT 업계에서 흔히 발생하는 변화입니다. 그러나 이러한 변화가 누적되면서 데이터베이스 마이그레이션 계획은 더 이상 특정 시점에 추진하는 일회성 프로젝트가 아니라, 기업이 지속적으로 검토하고 관리해야 하는 상시 과제가 되었습니다.
Start where you are.
현재 어떤 플랫폼에서 마이그레이션을 계획하고 계신가요? 아래 링크를 통해 자동으로 변환할 수 있는 항목과 공식 문서에 명시된 제약 사항, 예상 소요 시간, 마이그레이션에 필요한 엔지니어링 작업량을 확인해 보세요.
Oracle®
패키지, 예외 처리, 커서 및 데이터 딕셔너리 뷰를 EDB Postgres AI(EDB PG AI)에서 네이티브로 실행할 수 있습니다. 미국 연방수사국(FBI)과 미 해군을 포함해 고객사가 공개된 5건의 마이그레이션 사례를 확인할 수 있습니다.
MySQL®
스키마와 데이터는 마이그레이션 도구를 활용해 변환할 수 있습니다. 다만 뷰, 트리거, 저장 프로시저는 전환에 필요한 작업량을 산정할 때 주요 검토 대상입니다. 또한 커뮤니티 버전의 Postgres와 EDB PG AI 중 어떤 플랫폼을 마이그레이션 대상으로 선택할지도 신중하게 결정해야 합니다.
Sybase/SAP® ASE
EDB PG AI Migration Toolkit은 SAP ASE 15.7 및 16.0 버전을 공식적으로 지원합니다. 스키마와 데이터는 마이그레이션 도구를 활용해 이전할 수 있지만, T-SQL 기반 저장 프로시저와 트리거는 재작성해야 합니다. 허용 가능한 서비스 중단 시간에 따라 마이그레이션 계획과 예상 작업 범위가 달라집니다.
Greenplum
Greenplum 7.x는 바이너리 호환성을 기반으로 직접 교체할 수 있으며, 6.x는 2단계 전환 절차를 거쳐야 합니다. 데이터 이동이나 스키마 변경은 필요하지 않습니다. Euronext FX는 수개월간의 사전 준비를 거쳐 단 몇 시간 만에 시스템 전환을 완료했습니다.
MariaDB 또는 Percona Server 배포판을 사용하고 계신가요? MySQL 페이지에서 동일한 마이그레이션 변환 범위와 고려 사항을 확인할 수 있습니다. 해당 페이지를 먼저 살펴본 후, 현재 사용 중인 배포판과 버전을 알려주세요.
One methodology, whatever the source.
The same five stages, in the same order, wherever code and schema have to be converted. Greenplum is the exception—a binary-compatible swap skips the Transform and Move stages entirely.
Assess
Object inventory, complexity, application SQL
Transform
Schema and procedural code conversion
Remediate
The edge cases conversion leaves behind
Move
Coordinated transfer, reconciliation, sync
Validate
Integrity, correctness, performance under load
The first deliverable is a costed backlog, not a completed migration. Object counts, an application SQL classification, and the specific behavioral differences your estate will hit. That backlog is the project plan, and it is what an assessment produces, on every platform above.
The same four things on every platform page
Resources
Product
Information
Product
Information
Start with the estimate
An EDB migration architect works through your object inventory, application SQL, downtime tolerance, and target architecture. You come out with a costed backlog and a scoped timeline—which is what a budget conversation actually needs.