데이터 엔지니어 기술 면접 이후, 나갔다 돌아온 멘탈을 가다듬으며 보는 데이터 베이스 발전 과정과 미래의 양상에 대해 정리하기
어느 정도 규모로 자리 잡은 스타트업의 데이터 엔지니어 직군 기술 면접을 볼 수 있는 기회를 갖게 되었고, 나름대로 열심히 준비해서 갔지만 아무래도 해당 분야에 대해 아직 지식이 많이 부족한 편이라 결국에는 탈락의 고배를 마시게 되었다.
그 동안 단순하게 코드만 짜는 업무만을 맡다가 드디어 알고리즘 테스트를 통과하고 보니 본격적으로 기술적인 부분에 대해 물어보는 상황이 많이 만들어지고 있다.
결국 업무를 하기 위해서는 개발자들과 소통을 해야하니, 근본적인 기술 면접에 대한 준비는 필수라 생각하게 되었고, 집 나갔던 멘탈을 붙잡고 데이터베이스의 발전 과정에 대해 정리하는 글을 쓰게 되었다.
데이터 베이스 관리 시스템은 현재까지도 진화를 거듭하고 있다.
개발하면서는 단순하게 관계형 또는 비관계형 DBMS에 대해서만 알고 있지만, 사실 DBMS는 네트워크 DBMS, 계층 DBMS, 관계 DBMS, 객체지향 DBMS, 객체 관계 DBMS로 구분할 수 있다.
구분의 근거는 데이터를 데이터베이스에 저장하는 구조에 따라 분류하며, 이 분류 기준을 데이터 모델 Data Model이라 한다.
1. 1세대 : 네트 워크, 계층 DBMS
일반적으로 1세대 DBMS라고 하며, 계층 DBMS도 1세대로 구분한다.
네트워크 DBMS는 위의 그림처럼 단순화했지만, 사실 실제로는 훨씬 복잡하며 간선을 이용하는 데이터 간의 관계 표현은 데이터베이스의 구조가 복잡하고 변경이 어렵다는 특징이 있다. 대표적인 네트워크 DBMS 시스템은 1960년대 초에 개발된 IDS(Integrated Data Store)가 있다.
동일한 1세대 DBMS인 계층형은 구조는 네트워크형보다 단순하지만, 현실 세계의 다양한 데이터들을 단순하게 부모 — 자식 관계를 이루는 트리 형태로만 표현하기 어렵다는 단점이 있어 문제가 되었다. 마찬가지로 60년대에 개발된 IMS(Information Management System)이 있다.
2. 2세대 : 관계 DBMS
1980년대부터 발전해오기 시작했으며 우리가 익히 알고 있는 엑셀 형태의 테이블 형태로 관계형 데이터 모델을 사용한다.
단순하고 이해하기 쉬워서 오늘날까지 활용하고 있고, 관련 제품들도 많다 (MySQL, MS SQL, Oracle 등)
단순하게 이 DBMS로 SQL 쿼리 몇 개 날리는 게 문제가 아니다.
데이터 베이스의 효율성을 극한으로 높이기 위해 튜닝하는 다양한 방법들을 함께 이해하고 있어야하며, 오늘 날까지도 이론적으로 연구가 많이 이뤄지고 있다.
무엇보다 인공지능 학습에 이러한 테이블 형태의 데이터 저장 방식이 상당히 주목을 받는 것 같다.
3. 3세대 : 객체 지향, 객체관계 DBMS
1980년대 후반에 등장한 객체 지향 프로그래밍에서 객체라는 개념을 데이터 베이스에 사용한 형태가 객체지향 DBMS이고 객체 관계 DBMS는 관계형 데이터 모델에 객체 지향 개념을 도입한 것이다.
책에 언급된 내용 외의 구글링을 좀 해보니 오늘날에 관계 DBMS와 객체 관계 DBMS, 그리고 객체 지향 DBMS를 서로 구분하는 게 이론적으로 크게 의미가 있어보이지는 않는다.
대표적인 객체지향 DBMS에는 오투 (O2), 온투스 (ONTOS), 젬스톤 (GemStone)이라는 것들이 있지만 대부분의 서비스는 사실 내 입장에선 들어본 적도, 사용해본 적도 없다.
다만, 2세대 데이터베이스 관리 시스템들이 발전하면서 3세대의 특징을 반영한 것 같다.
그리고 엄밀히 말하면 관계형 DBMS의 각 테이블을 모두 객체로 볼 수 있는 것이 아닌가?
그냥 발전하는 과정에서 3세대 특징을 2세대에 거의 대부분 반영했다고 봐도 무방할 것 같다.
4. 4세대 : NoSQL & NewSQL DBMS
이 데이터 베이스가 사실상 가장 최근인데, 오늘날 SNS가 폭발적으로 발전하면서 사진, 동영상, 구글 검색 기록과 같이 정형화해서 저장할 수 없는 데이터들이 함께 대량으로 생성된 것이 발단이 되었다. (소위 비정형 데이터라 하는 것들)
관계형 DBMS는 이러한 빠르게 생성되는 비정형 데이터를 처리하는데 매우 비효율적이고 (애초에 정형화를 시켜 저장하는 것이 맞는가에 대한 의문도 있다) CPU, Memory 등 하드웨어 성능을 끌어올려 해결할 수 있는 문제로 볼 수 없다는 게 판단인 것 같았다.
따라서 이 문제를 해결하기 위해 관계형 데이터베이스가 주는 안정성과 일관성 유지의 장점을 포기하고, 데이터 구조를 “미리 정해놓지 않는” 형태로 처리하는 게 적합하다고 생각해 생겨난 것이 NoSQL DBMS이다.
처음 언급된 것은 1998년이나 2009년부터 주목을 받기 시작했고, 구글, 페이스북, 트위터 같은 기업들이 필요성을 갖오하면서 주목이 커지기 시작했다.
대표 서비스에는 MongoDB, Redis, Cassandra 등이 있고, MongoDB의 경우 Javascript로 빌드되어 있어 웹 프로젝트를 할 때, React.js(또는 Vue.js || Angular.js) + Node.js로 통일해 사용하는 경우가 많아졌다.
그러나 NoSQL은 RDB(관계형 DBMS)를 완벽하게 대체할 수 없어서 새롭게 NewSQL DBMS라는 것도 등장했지만, 2011년에 처음 언급되었고, 아직 많은 연구가 필요한 단계라고 한다.
데이터베이스를 세대별로 구분하는 게 꼭 전차 & 전투기를 세대별로 구분하는 것과 비슷한 것 같다.
분명 시대별로 발전하는 데이터의 형태가 각각 다르다보니, 그에 맞춘 데이터베이스 관리 시스템도 발전하는 거라 보면 될 것 같은데, 이렇게 개념적으로 보니 결과적으로 데이터베이스를 기업의 서비스 형태에 따라 커스터마이징하고, 정규화 & 반정규화, 쿼리 최적화 등의 일을 독자적으로 진행하는 것이 얼마나 중요한 일인지 새삼 깨닫게 된다.
지금 중요하게 보는 데이터가 사진, 영상, 검색이라면 앞으로 미래에 산업적으로 중요하게 생각하는 데이터가 DBMS 산업의 판도를 바꾸게 될 것이다.
무엇보다 데이터베이스 관련 포지션 중 데이터베이스 아키텍처들의 연봉이 상당히 높은데, 이들이 하는 일이 얼마나 고숙련 노동인지 이해할 수 있다.
정규화 관련 글은 블로그와 지금 읽은 책에도 언급이 되어 있지만, 반정규화의 중요성을 언급하는 책은 아직까지 확인을 못해봤다.
이 글을 쓰기 위해 참고한 책도 정규화의 중요성에 대해서는 여러 장에 걸쳐 설명하지만, 반정규화의 개념에 대한 설명은 빠져있다.
이전에 면접 본 면접관님이 얘기하길
“데이터 무결성이 깨질 수 있는 위험을 무릅쓰고 데이터를 중복하여 반정규화를 적용하는 이유(즉, 정규화로 데이터 중복 값을 최소로 했던 과정을 되돌리는 것?)는 데이터를 조회할 때 디스크 I/O량이 많아서 성능이 저하되거나 경로가 너무 멀어 조인으로 인한 성능저하가 예상되거나 칼럼을 계산하여 읽을 때 성능이 저하될 것이 예상되는 경우 반정규화를 수행”
한다고 구글 블로그에 언급된 내용을 그대로 말해줬었다. 워낙 쿼리 효율성을 따지는 직군이라 반정규화를 잘 이해하는 것이 중요하다고…
천리 길도 한 걸음부터 시작한다지만, 갈 길이 멀어보여 막막하기는하다.
하나씩 막막함을 해결해보자
참조
한빛교재시리즈 — MySQL 이론
Ryan
