2021년 11월 30일 화요일

Stored Procedure에 대한 단상

COBOL 엔지니어 몸값이 되려 귀해진다는 기사1를 보면, 최소 아직도 그 언어가 쓰이는 곳이 있다는 것을 알 수 있다. 사실 최소한이 아니라 여전히 많이 쓰이는 걸 알 수 있으며, Glassdoor를 통해 추정해보면 아마 초기 금융시스템을 구축한 영국, 싱가포르, 일본 등에서 수요가 계속 있는 것으로 보인다. COBOL이 강점이 있는 것은 부정하지 않지만, 최소한 한 번은 역사의 주역에 등장했던 기술이 쉽게 사라지지 않는다는 건 확인할 수 있다.

20~30년 후 데이터베이스 영역에서 Stored Procedure가 이에 해당할 수 있을지도 모르겠다. 최근 젊은 엔지니어들을 만나면 Stored Procedure에 대해 아는 경우가 많지 않아 전망하는 것이기도 하지만, 그게 전부는 아니다. 필자의 경우 이 기술이 충분히 대체될 수 있다는 관점을 갖고 있지만, 한 편으로는 이 기술을 떼어내기 쉽지 않을 수 있겠다는 현상들이 계속 나타나기 때문이다. 게다가 심지어 BigQuery2, Snowflake3, Vertica4 등의 최신 데이터베이스 기술들이 모두 Stored Procedure에 대한 지원을 시작 및 확장하고 있기 때문이다.

Stored Procedure는 전통적인 DBMS 회사들이 SQL만으로 하기 어려운 프로그래밍적 기능을 사용하기 위해 만들어졌으며, 전통적인 DBMS 회사라고 언급할 만큼 Oracle, MS-SQL, Teradata 등이 주도해온 영역이다. 특히 Oracle의 Stored Procedure는 PL/SQL이라고 따로 불리고 하나의 전문 기술영역으로 분류될 만큼 널리 활용되어 왔다. 가장 큰 특징은 상태 저장이 어려운 SQL을 변수 처리를 할 수 있도록 보완하는 것이며, 여기에 루프문, 조건문 등의 기초적인 프로그래밍 기법을 활용할 수 있도록 하는 것이 주요 골자이다. 물론, Cursor와 같은 Recursive 기능도 아주 많이 활용되는 기술이다. 3-tier Architecture에서 Stored Procedure를 활용하면 일부 데이터와 관계된 비즈니스 로직을 WAS단이 아닌 DB 구간에서 처리하여 효율성을 높일 수 있다는 점 때문에 널리 사용 되었다. 또한, DB 개발자나 DBA들에게 당시 한창 사용되던 Java나 C 대비 쉬운 언어였던 점도 한 몫 했다는 점도 무시할 수 없는 사실이긴 하다.

[3-tier Architecture의 예5]

활용처가 이렇게 광범위 함에도 불구하고 대체될 가능성이 높다고 생각해 온 이유는 다음과 같다. 첫 번째로는 최신 업무 설계 트렌드가 어플리케이션 중심으로 변경되면서, 이전 시대에서 DBMS에서 처리하던 구현 로직을 어플리케이션에서 수행하는 것이 훨씬 자연스러워 졌다. 두 번째, DB가 다양해지고 고객이 선택을 다양하게 함에 따라 특정 DB의 의존성을 제거할 필요성이 높아졌기 때문이다. 세 번쨰, 파일시스템 기반 오픈파일 포맷을 사용하면서 Stored Procedure 자체가 사용 불가능한 경우들이 많아졌기 때문이다. 이러한 MSA(Microservice Architecture)향으로의 트렌드 변경은 Stored Procedure를 가급적 배제하는 것이 이상적이라는 결론에 이르게 만들었고, 최근에 신규로 개발되는 프로젝트 중 이러한 요구사항을 잘 반영한 경우에는 Stored Procedure를 사용하지 않거나 일부 함수의 구현 등을 위해 External Procedure를 사용하는 정도가 대부분이다. 실제로 근 10년 내 등장한 DBMS들은 이러한 추세를 예측하기라도 하듯, Stored Procedure가 없는 경우를 종종 볼 수 있었다.

하지만, 이들이 Stored Procedure에 대한 지원을 하게 되는 이유는 결국 매우 단순하다. 기존에 만들어진 시스템의 경우라면 결국 마이그레이션을 해야하는데, Stored Procedure를 온전히 모두 다 걷어낸다는 건 사실상 불가능에 가깝다고 생각하기 때문일 것이다. 그렇다면 지금 수많은 고객사에 깔려있는 오래된 시스템을 윈백한다는 건 사용자에게 너무 큰 부담으로 작용하게 된다. 게다가, 전산 프로세싱 관점에서는 비효율적일지 몰라도 구현하는 개발자 입장에서는 Stored Procedure를 잘 활용할 수 있는 부분들이 있는데, 사용을 최소화 하는 것 대조적으로 아예 기능이 없는 제품은 도입은 상당히 꺼려질 수 밖에 없다. 그래서 Oracle이나 Teradata가 제공하는 수준의 기능은 아니더라도, Stored Procedure를 지원하는 방향으로 나갈 수 밖에 없는 것이다.

또 다른 관점에서 생각해볼 수도 있다. Databricks나 Dataiku 같은 데이터 플랫폼 서비스가 시장에 성공적으로 진입하면서, DBMS 벤더가 신규 데이터 관련 시장에서 가져갈 수 있는 파이가 기대보다 많이 줄었을 가능성이 높다. 그렇기 때문에 더욱 기존 시스템의 윈백 기회나 기존 데이터베이스 사용자를 강하게 견인하기 위해서 더욱 DBMS 전통적인 기능을 넣을 수 밖에 없었다고 볼 수도 있다.

물론, 단순히 기능 기능 지원만으로 DBMS 시장 자체를 전망하는 건 과도한 생각일 여지도 있다. 다만, 최소한 사용자 및 운영기획 담당자의 확고한 마이그레이션 의지 없이는 Stored Procedure는 장기적으로 현재의 COBOL 과 같은 유사한 입지를 차지할 가능성이 있다는 점은 무시할 수 없는 전망으로 보인다.

  1. The Inevitable Return of COBOL
  2. Command and control now easier in BigQuery with scripting and stored procedures
  3. Zero to Snowflake: Simple SQL Stored Procedures
  4. Vertica Announces Vertica 11, Delivering on Vision of Unified Analytics
  5. Multi-Tier Applications

    Related Posts

    Multi-datasource를 위한 SQL Engine
    머신러닝 모델과 데이터베이스 연계의 의미와 한계
    SQL 기반 In-Database Machine Learning의 의의

    Leave a Reply