시스템 소프트웨어 개발자로 딱 60살까지만 이런저런 시스템, 특히 대용량 데이터를 다루는 시스템을 직접 설계하고 만들어보고 싶은 마음은 지금도 여전하다.
그리고 그러한 미련에 들어온 DBMS 개발바닥이다. 원래 우직하니 한 우물만 파는 스타일은 아닌데.. 어찌어찌 하다보니 10년째 데이터 처리 엔진쪽으로만 일하고 있는 자신을 바라보며 기특하단 생각도 든다. 하지만 최신 유행하는 다른 분야로 발빠르게 움직이지 못한 것이 못내 아쉬울 때도 종종 있다.
이런 내 마음에는 아랑곳 없이 데이터환경이 휙휙 바뀌면서 하루가 멀다하고 새로운 모양의 시스템, DB들이 마구 쏟아져 나온다. 이런 추세속에서 여전한? 것들을 하고 있는 내 자신을 바라보고 있자면 old school에서 벗어나지 못하고 있는 듯 느껴져 왠지 마음이 급해진다. 이 글을 쓰고 있는 지금도 어디에선가는 새로운 DB(용어따지기 좋아하는 사람들을 위해 여기서 'DB'는 데이터베이스 자체가 아니라 DBMS혹은 DMS를 의미한다는 것을 밝힌다)가 글로벌 DB시장에 런칭하는 소리가 들리는 듯 하니 말이다.
그러나 이쪽 분야에서 일을 하면 할수록 데이터를 다루는 일에 신구라는 것이 없다는 생각이다. 다만 어떤 정보들을 관리할 것인가가 시스템의 선택에 중요한 역할을 하는 시대라는 것..
이젠 RDBMS(Relational Database Management System)를 두고 흔히 '전통적인 DBMS'라는 말을 쓰는 것을 자주 듣는다. 그 전통적인 DBMS의 엔진개발자로 오래 일해왔지만 보면 볼수록 공부할 부분이 많아진다는 생각엔 변함이 없다. 그와 더불어 이젠 요즘 유행하는 블록체인이나 인공지능쪽을 공부해볼까 하는 생각도 간혹 할때가 있지만 아직은 데이터를 처리하는 시스템 소프트웨어 개발자로 일하는 것이 더 즐겁다. 물론 블록체인이나 인공지능쪽이 데이터와 무관해서는 아니다. 오히려 그것들은 데이터의 처리방식보다는 데이터의 내용과 더 직접적인 관계가 있는 영역이라고 생각한다.
전통적인 RDBMS에서 데이터는 관계성을 가지며 릴레이션 혹은 테이블이라는 스키마들로 모델링 된다. 모든 데이터는 도메인을 갖고 있으며 도메인에 추가된 제약조건들을 만족하는 값으로만 그 identity를 갖는다.
E. F. Codd 박사가 'A Relational Model of Data for Large Shared Data Banks'를 통해 대용량(그 당시의) 데이터를 어떻게 다룰 것인지 릴레이션과 튜플, 그리고 정규화에 대해 이야기했던 시점으로부터 약 50년의 세월이 흘렀다. 그리고 대용량 데이터의 기준이 달라졌다. 아니 그 후로 지금까지 죽 계속 달라져왔다고 해야 맞을 것이다.
비즈니스 쪽에서 '빅데이터'를 거론하며 마치 '빅데이터 시스템'이라는 것이 존재하는 것 마냥 사람들이 '빅데이터!''빅데이터!'를 외칠 때에도 시스템 소프트웨어 개발자들은 기존과 동일한 기술기반으로 빅데이터라는 놈을 해결했다. 그러나 아직까지도 빅데이터가 하둡을 의미하는 것으로 생각하는 사람이 존재하듯 특정 시스템을 모든 빅데이터문제를 해결해줄 답안으로 생각하는 사람도 분명 있을거라 생각한다.
그러나 수많은 데이터 처리 기술들이 존재하는 이유는, 무엇을 정보로 볼 것이며 데이터를 어떻게 바라볼 것인가이다. 다시말해 정보를 어떻게 관리할 것인가가 시스템을 선택하고 설계하는데 있어 최우선적으로 고려해야 할 사항이다.
RDBMS는 릴레이션이라는 관계성을 데이터에 부여함으로써 정보를 관리하는 한 가지 효과적인 방법을 제시했을 뿐이고 지금까지도 수많은 정보들을 관리하는데 유용하게 쓰이고 있을 따름이다.
몇달 전 회사 근처에서 그래프 데이터베이스(이하 GDBMS) 관련 밋업이 있어 참석했던 적이 있다.
그 회사에서 GDBMS를 개발하고 있는 개발자의 과반수가 예전, 같은 연구실 혹은 같은 회사 동료로 함께 일했던 경험이 있다보니 그네들이 만들고 있다는 것이 도대체 무언지 더 궁금한 것도 있었지만, 예전부터 GDBMS에 조금은 관심이 있던 차에 잘됐다 싶었다.
GDBMS는 DBMS시장에서 아직까지도 전통적인 강자인 RDBMS에 비하면 아직 갈 길이 멀지만 시장 성장세가 아주 빠른 제품에 속한다.
그도 그럴것이 GDBMS는 SNS로 대변되는 '실시간으로 쏟아지는 대량의 비정형 데이터' 를 처리하기에 전통적인 RDBMS보다 우월한 면도 없지 않기 때문에, 최근 SNS를 통해 늘어나는 데이터의 처리가 곧 비즈니스가 되는 현실에선 RDBMS보다 나아보일 수도 있다.
그럼 GDBMS는 RDBMS랑 뭐가 어떻게 다른 것일까?
Graph라는 단어가 의미하듯 GDBMS는 그래프를 이용한? DBMS임에는 분명하다. '그래프'라는 용어를 수학적으로 이해하지 못하는 경우, 혹은 DBMS에 관해 전혀 지식이 없거나 데이터 관리 시스템에 대해 잘 알지 못하는 사람들은 그래프와 그래픽을 혼동하는 경우도 꽤 많다. 그래서 밋업에서 "그래픽데이터베이스라고 하는데 도대체 그래픽으로 뭘 보여준다는 건가요?" 라는 질문을 하는 경우도 봤다.
그래프는 간단히 말하면 점(vertex)과 선(edge)으로 표현된다. 여기서 점은 흔히 객체로 모델링 되고 선은 관계 내지는 행동(상태의 변경)을 표현하기 위한 수단이 된다.
GDBMS는 쉽게 말하자면 사용자에게 이러한 그래프의 개념으로 데이터를 모델링할 수 있도록 해주는 DBMS이다.
앞서 데이터를 처리하는데 있어 중요한 것은 무엇을 정보로 볼 것인가와 데이터를 어떻게 바라볼 것인가라고 썼다.
정보는 데이터 그 자체일 수도 있고 관련있는 데이터들의 집합 혹은 데이터의 위치, 데이터가 존재하는 이유, 데이터가 생성된 이력 등 무수히 많은 형태가 존재한다. 그동안 사람들, 그리고 수많은 조직들은 정말 제한적인 데이터모델 안에서 아주 많은 일들을 처리하며 살아왔다.
하지만 90년대 초반부터 꿈틀대더니 이젠 이것 없이는 못살게 된 인터넷의 발달부터 인터넷기술을 밑에 깔고 등장한 많은 문화들, 그 중에 텍스트, 이미지, 사운드를 안가리고 매초마다 엄청난 정보데이터를 양산하는 SNS라는 문화적 기재로 인해 처리해야하는 정보의 성격에 아주 큰 변화가 일어났다. 불과 20년 남짓만에 정보의 구성요소가 되는 데이터를 바라보는 뷰가 하나 더 늘어야 하는 시대가 된 것이다. 데이터를 바라보는 뷰가 바로 데이터 모델이다. RDBMS는 릴레이션이라는 뷰를 제공함으로써 데이터를 모델링하기 쉽도록 해준 것 뿐이다.
RDBMS가 주류시스템 소프트웨어가 된 당시에는 월스트리트로 대변되는 금융, 보험업무로부터 발생하는 데이터가 여러 비즈니스 영역들 가운데서도 가장 많았다. 또한 이 데이터들은 한 번 잘못 기입되거나 누락되면 엄청난 책임을 져야하는 경우가 많았기 때문에 이들에 대한 보장을 안정적으로 해줄 수 있는 시스템이 필요했다. 말로 풀어썼지만 간단히 말하자면 ACID속성을 갖는 트랜잭션 정보의 처리가 무엇보다 중요했다는 것이다. 그러한 데이터 처리환경에서 마치 자연선택설에 의한 결과인듯 DBMS는 트랜잭션처리에 특화된 성능과 안정적 우월성을 바탕으로 대부분의 데이터 처리 시스템의 기반으로 자리매김했다.
수십년의 세월동안 데이터의 속성이 바뀌어도 데이터의 양과 응용방식이 바뀌어 왔음에도 DBMS가 아직까지도 그 자리를 내어주지 않은 것은 DBMS또한 그러한 환경변화에 매우 잘 적응하며 발전해왔기 때문이다. 2000년 초반 '클라우드'라는 개념이 대두되고 5년남짓일까 너도나도 여기저기서 클라우드 클라우드할 때만해도 DBMS는 위기를 느끼지 않았던듯 하다. 그러나 뭔가 얻어맞은 듯한 느낌이 들정도로 DBMS시장의 근간을 흔든 일이 2010년 초반 '빅데이터'라는 개념의 대두와 더불어 일어났다. 바로 NoSQL 이었고 MongoDB, Cassandra 등 수많은 NoSQL 제품들이 재조명되거나 봇물터지듯 시장으로 쏟아져 나왔다. 시스템의 구상과 개발이야 이전부터 있어왔지만 NoSQL의 약진은 빅데이터의 유행과 그 근간을 함께 한다. 빅데이터가 과연 무엇이냐를 놓고 2010년 초반 그 정의나 분류에 대해 참 말이 많았다. 아니 개념조차 제대로 잡지 못한채 스스로 자신이 빅데이터 전문가라며 당시 컨설팅을 하고 다닌 사람들이 이젠 어엿하게 빅데이터 시장에서 명함만 내밀어도 인정받는 사람들이 된 2010년 말에와 회상해 보면 NoSQL은 ACID를 다 만족시키지 않아도 된다는 어찌보면 당연한 것을 '그래 난 내가 원하는 것만 보장할래'라는 배짱 튀기기로 밀고 나간 것이었다.
이래서 DBMS보다 가볍다. 그래서 DBMS보다 특정 연산에 빠르다. 저래서 DBMS보다 싸다. 그래서.. 등등
많은 이유들이 특정 트랜잭션 혹은 데이터 처리환경에서 그들의 손을 들어줬다. 그만큼 전통적인 DBMS는 비즈니스 레벨에서 데이터 처리 영역이 보다 세분화되어 대부분의 데이터 처리가 아닌 특정 데이터처리에 적합하다는 말을 들어야 하는 때가 왔다. 사실 아직도 ACID를 만족하는 트랜잭션 처리 분야는 데이터 처리 시장에서 매우 큰 부분을 차지하는 중요한 시장이다. 그럼에도 불구하고 상대적인 박탈감? 같은 것이 느껴진달까.. 예전에는 DBMS로 다 했는데 이젠 이건 뭐가 저건 뭐가 더 낫다는 결과들이 제시되며 왠지 '야 그동안 많이 해먹었으니 이젠 내려와라' 하는 느낌이다.
그러나 과연 그럴까..? 데이터 처리 엔진을 굳이 유형별로 구분하고 분류해 두고 이런 환경엔 이게 최고 저런 환경엔 저게 최고라는 식의 논리로 한 시점에 베스트인것으로 보이는? 시스템을 설계하는 것으로 다 된 것일까? 데이터의 본질을 생각하면 정보의 본질을 생각하면 정보의 사용성이 어디에서 기인하는지를 생각해보면 그리고 거기에 더해 사용자의 편의성 정보관리의 주체와 기간 데이터의 유지비용 및 데이터 흐름의 적시성 등을 생각해보면 왜 지금도 새로운 데이터 처리 시스템들이 시장에 등장하고 있는지 알 수 있다.
그럼에도 불구하고 데이터 처리의 기본은 데이터에 요구하는 속성에 기인한다.
트랜잭션에 관한 이론은 이러한 데이터 처리에 있어 가장 근본적인 문제를 다룬 것이다. 마치 경제학에서 수요와 공급이 수많은 경제이론을 설명하는 이유와 시발점이 되는 것처럼 트랜잭션은 처리할 데이터의 가장 중요한 속성을 어떻게 볼 것인가를 짚고 있는 것이다. 그리고 그러한 것을 연구하는 분야가 바로 데이터 처리 시스템 연구분야이고 DBMS는 개발이 완료된 더이상 생각할꺼리가 별로 없는 시스템이 아니라 끊임없이 발전해나가고 있고 발전해 나가야 하는 시스템이다. 그래서 DBMS는 아직도 파야할 것이 많다.
혹자들은 DBMS를 이미 legacy라 부르거나 기술하고 있을지도 모른다. 하지만 television을 레거시라 하진 않는다.
DBMS는 브라운관TV가 아니다. television이다.
CUBRID Network Diagram (CUBRID Version 9.3, 10.1)
