오픈소스 DBMS 검토

DBMS를 포함하여 전체 소프트웨어 시장에서 일부 상용 소프트웨어 제품에 지나치게 의존적이 되고 그에 따라 그들의 유지보수 비용, 기술지원 방식 및 라이선스 정책들이 싫어도 사용할 수밖에 없는 소위 락인(Lock-In) 현상(참고1-2)을 극복하기 위한 대안으로 공개 소프트웨어(오픈스소 SW)가 수년 전부터 뜨겁게 떠오르고 있다.

• [참고 1-2] Lock In(출처 : 위키피디아)

• In economics, vendor lock-in, also known as proprietary lock-in or customer lock-in, makes a customer dependent on a vendor for products and services, unable to use another vendor without substantial switching costs.

  경제학에서 “독점 락인(proprietary lock-in) 혹은 고객 락인(customer lock-in)” 이라고도 불리는 제조사 락인(Lock-In)은 고객을 특정 제조사(제품 혹은 서비스를 제공하는)에 의존적으로 만들어 막대한 전환 비용 없이는 다른 제조사를 사용하는 것이 불가능해지는 현상이다.

그 중에도 2016년 8월 DB-Engines Ranking이 발표한 전세계 RDBMS 인기순위 4위를 차지한 PostgresSQL(표1-1) 오픈소스 DBMS는 ㈜다우기술(참고1-3)이 EnterpriseDB사와 손잡고 PPAS(Postgres Plus Advanced Server)(참고1-4) 형태로 국내에도 다양한 서비스를 제공함으로써 외산 상용 DBMS들의 전환 대상으로 급부상하고 있다.

• [표 1-1] DB-Engines Ranking(출처 : 검색엔진 언급 횟수, 기술토론 빈도수 등을 고려하여 월별로 인기 순위를 발표한다)
• 

• [참고 1-3] 다우기술, EDB와 손잡고 국내 오픈소스 DB 시장에 210만 달러 투자 (출처 : 다우기술 보도자료)

• 다우기술과 엔터프라이즈DB(EDB)*가 오픈소스 데이터베이스(DB) 시장 확산을 위해 200만 달러 이상 투자한다. 교육센터와 기술지원센터를 설립해 국내 오픈소스 소프트웨어(SW) 인재 양성에 나선다.

  EnterpriseDB(엔터프라이즈DB)사는 “오픈소스 DBMS” PostgreSQL을 개선하여 오라클의 대부분 문법을 제공하는 ‘상용 오픈소스 DBMS’PPAS(Postgres Plus Advanced Server)를 출시하였고 다우기술과 함께 국내 오픈소스 DBMS 확산에 힘쓰고 있다. 해당 보도자료에 링크된 기사원문에 따르면 세계 2,700여 기업과 정부 기관이 사용 중이며 국내에는 KT, 다음카카오, LG전자 등 50여개 고객사를 확보했다고 한다. 또한 Oracle, DB2등과 같은 외산 상용 RDBMS와 높은 호환성 강조하고 해당 DBMS들과의 성능비교 기술백서를 제공하는 등 기존 DBMS 전환을 통한 국내시장 진입계획을 밝히고 있다.

• [참고 1-4] PPAS(Postgres Plus Advanced Server)

• PPAS(Postgres Plus Advanced Server)는 ‘오픈소스 DBMS’를 보다 사용하기 쉽게 만든 ‘상용 오픈소스 DBMS’로써 오픈소스 DBMS에 비해 사용 비용이 추가될 수 있지만 계속적인 기술지원, 제품개선, 교육 서비스 등을 제공받을 수 있다.

정부 또한 공개 소프트웨어 도입을 촉진할 수 있는 다양한 정책을 검토/시행하고 있는데 이는 특정 소프트웨어 의존성을 극복하고 국가정보화 사업의 경제성을 제고하기 위함임을 밝히고 있다(출처 : 대한민국 정부 3.0(2015년도 국가정보화에 관한 연차 보고서)).

이러한 오픈소스 SW의 대세적 흐름에도 불구하고 소속 회사는 오픈소스 DBMS를 현재 사용 중인 DBMS의 전환 대상으로 선택하지 못했는데, 이는 1.1장에서 언급했던 오픈소스 전환에 따른 어플케이션의 위험성을 수치적으로 정확하게 측정하거나 대비할 수 없었기 때문이었다.

신규 프로젝트라면 어떤 종류의 DBMS를 기반으로 어플리케이션 개발을 진행하든 해당 DBMS에서 최적화된 성능이 발휘되도록 구현할 것이므로 DBMS 종류는 큰 문제가 되지 않을 것이다(물론 기본적인 엔진의 신뢰도는 높아야 하겠지만).

그러나 많은 어플리케이션이 이미 운영 중인 DBMS라면 전환 이후 문법적/성능적 이슈로 인해 원활하게 동작하지 않을 SQL들을 수치적으로 정확히 파악하고 어플리케이션 담당자들과 협의할 수 있어야 프로젝트 기간 및 계획 수립이 가능하다.

더불어 파악된 이슈가 수천수만 개의 SQL을 수정해야 한다면 한정된 시간동안 어플리케이션의 안정을 보장하며 일일이 수정하는 것은 불가능하므로 DBMS 제조사에서 엔진의 성능 개선/추가 기능 등을 통해 1차적으로 해결하고 도저히 엔진 차원에서 불가능한 소수의 SQL들만 어플리케이션에서 수정해야만 안정적인 전환이 가능하다고 판단하였는데 이러한 관점에서 오픈소스 DBMS는 적절한 대안이 될 수 없었다.

그리고 현재 비용/성능 면에서 만족하며 원활하게 사용 중인 상용 3rd Party 제품들(모니터링, 암호화, 통제/감사, 백업 등)과의 호환성도 정해진 시간 안에 100% 호환 상태로 업그레이드가 될지 의문이었다.