뉴욕 할렘가에 왕관과 공룡이 담긴 화려한 낙서가 그려지기 시작했습니다. 낙서 미술의 대가, 미술계에 반항아 천재 '장 쉘 바스키아(Jean-Michel Basquiat)'는 사회에 대한 저항과 기성세대에 대한 불만을 낙서로 자유분방하게 거칠게 표현했습니다. 당시 뉴욕은 길거리에 낙서가 범람화하던 시대였습니다. 도시의 골칫거리가 되어갔지만 바스키아의 등장은 이 낙서를 예술로 승화시켰습니다.

바스키아의 작품을 보고 있으면, 예술이란 자유의 한계를 벗어나, 훨훨 날아갈 거 같은 느낌이 듭니다. 유치원생이 그릴법한 낙서는 단순해 보이지만 뛰어난 조형감각과 다양한 색채감각을 선보이고 있습니다. 바스키아의 등장은 미국 미술의 두 번째 혁신을 주었습니다. 인종주의, 해부학, 흑인 영웅, 만화, 자선적 이야기 그리고 죽음 등의 주제로 팝아트 계열의 천재적인 자유구상화가로 낙서를 예술로 승화시켰다는 평가를 받고 있습니다. 그의 등장으로 기성의 예술 표현을 뒤집는 거대한 흐름을 만들어 냈습니다.

관계형 데이터베이스의 한계

관계형 데이터베이스(Relational DataBase Management System, RDBMS)의 등장은 트랜젝션을 통한 안정적인 데이터 관리를 가능하게 한 혁신적인 정보 보관 장소였습니다. 하지만 문제가 생기기 시작했습니다. 바로 "데이터 처리 비용"입니다. 점점 더 많은 사람들이 데이터를 보관하기 시작하였고, 다양한 서비스 개발은 데이터베이스를 부하를 일으켰습니다. 그리고 자연스럽게 데이터를 처리하는 비용이 증가하기 시작했습니다. 데이터의 증가만큼 좋은 하드웨어가 필요하였습니다. 그렇게 각 기업에서는 데이터베이스를 관리하는 비용에서 한계가 오기 시작했습니다.

특히 빅데이터의 등장은 RDBMS의 한계를 앞당겼습니다. 빅데이터를 RDB 스키마에 맞게 입력하려면 매우 긴 시간의 시스템을 이용할 수 없는 다운타임(Down Time)을 일으켰습니다. 관계형 데이터베이스는 수평적으로 확장하는 것이 어려운 점이 있습니다. 이 방법은 기존 스택에 더 많은 서버를 추가하는 방식입니다. 즉 컴퓨터를 업그레이드해서 부하를 이겨내야 하는 것이 아니라, 컴퓨터를 한대 더 사서 부하를 이겨내야 하는데 이러한 수평적 증가에 있어서 확장이 어려운 점이 있습니다.

관계형 데이터 모델은 데이터의 일관성을 보장해야 합니다. 하지만 수평으로 확장하는 경우 각 서버들이 연결하여 각 데이터를 동기화하기 위해 업데이트 지연이 발생하게 됩니다. 즉 스케일 아웃을 염두에 두지 않는 설계로 인해 트랜젝션, 일관성을 유지하면서 분상 환경에서 조작이 힘든 약점이 두각 되었습니다.

"No! SQL"

거대한 공룡 기업들이 만든 관계형 데이터베이스의 세계에 악동이 나타납니다. 바로 NoSQL입니다. 이름 자체에서도 기존 RDBMS의 독점적인 지위를 반발하는 정신을 담은 이름을 가지고 데이터베이스 세계에 등장합니다. DBMS를 조작하는 데 사용되는 언어인 SQL(Structured Query Language)에 “No”를 붙여서 사용합니다. 이 약자에 대해 많은 추측이 있습니다. "Not Only SQL", "Non-Relational Operational Database SQL"등 다양한 해석이 있지만 기존 데이터 저장 방식에 저항하는 의미를 가진건 확실한 거 같습니다.

1998년 카를로 스트로찌(Carlo Strozzi)는 표준 SQL 사용하지 않는 경량화된 관계형 데이터베이스를 공개하였고, 2009년 요한 오스 칼손(Johan Oskarsson)이 NoSQL이라는 용어를 처음 사용하였습니다. 그런데 이 낯선 이름의 데이터베이스는 도대체 어디에 사용되고 있을까요? 바로 '페이스북', '인스타그램', '트위터'가 스마트폰에 설치되었다면 NoSQL을 사용 중인 유저입니다. 이미 많은 기업과 서비스에서 이 선진화된 방식을 사용 중이고, 개발자에게도 꼭 습득이 필요한 스킬입니다.

그렇다면 NoSQL은 무엇인가?

'NoSQL'은 기성 데이터베이스가 사용하던 관계형 데이터베이스를 벗어난 방식을 사용한 '비 관계형 데이터베이스'입니다. 예를 들어보겠습니다. 만약 뉴욕에 한 도서관에 책이 한 권 입고시켜보겠습니다. 제가 쓴 에세이 '오늘도, 우린 코딩을 합니다.'를 관계형 데이터베이스의 등록하기 위해서는 우선 저자 '고코더'는 저자를 관리하는 '저자 테이블'에 저장합니다. 그리고 책은 책 정보를 저장하는 '책 테이블'에 저장합니다. 그리고 출판사 '비제이퍼블릭'의 정보는 출판사를 관리하는 테이블 '출판사 테이블'에 저장합니다. 이렇게 3개의 테이블이 연결되어서 데이터를 관리할 때 참조 무결성을 실현하게 됩니다. 복잡하지만 확실한 데이터를 관리할 수 있는 방법입니다.

하지만 이단아 NoSQL은 이러한 기성세대 방식을 깨트렸습니다. 마치 바스키아의 낙서처럼 말이죠. 이 비 관계형 데이터베이스에 이 정보를 저장한다면 그저 서적 레코드에 한 번에 저장합니다. 좀 더 전문적으로 말하면 JSON 형식으로 문서에 저장되고 이 단일 정보 안에는 책정보, 저자, 출판사 정보까지 한 번에 저장합니다. 좀 더 직관적으로 비유하지만 방청소를 하는데 책은 책장에, 옷은 옷장에, 음식은 냉장고에 보관했다면 이 방식은 그냥 책과 옷 그리고 음식까지 네모난 상자에 한 번에 집어넣어 관리하는 방식입니다. 기존에 방식이 좀 더 우아해 보이지만, 이렇게 된 이유가 있습니다.

NoSQL 대체 뭐가 좋은데?

데이터베이스의 일관성과 확장성 사이는 상반 관계입니다. NoSQL은 이 두 요소를 적당히 붙잡았습니다. 일관성을 어느 정도 포기한 대신, 확장성으로 성능을 향상했습니다. 청소할 때 박스에 모든 물건을 집어넣으면 빠르게 청소가 끝나지만 나중에 물건을 찾기 조금은 시간이 더 걸릴 수 있을 것입니다. 이처럼 데이터 간에 정합성은 조금 포기하고, 좀 더 빠르게 데이터를 찾아낼 수 있게 되었습니다.

분산 저장이 매우 수월해졌습니다. 저비용의 서버를 여러 대 두어 수평적으로 확장하여 성능을 향상해주었습니다. 만약 방을 청소할 때 책이 많으면 책장을 더 구매해야 하지만 박스에 보관하면 책이 더 많아도 상관이 없습니다. 박스 개수만 늘리면 되니깐요. 하지만 기존의 방식은 책장이라는 수평적 확장이 필요했기 때문에 더 많은 비용이 발생하였습니다.

그리고 스키마라는 구조 없이 동작합니다. 데이터 구조를 미리 정의할 필요가 없습니다. 이런 비정형 방식은 다양한 데이터를 저장하는데 유리합니다. 앞서 말한 것처럼 책장, 옷장, 냉장고이란 공간을 분리하지 않았기 때문에 가능한 방법입니다.

틀을 벗어난 혁신

NoSQL과 바스키아를 보면서 틀을 벗어난 혁신에 대해 묵상하게 됩니다. 안전히 새로운 것을 만든다는 것은 어렵습니다. 하지만 개발자란 단어와 매우 닮아 있다는 것을 발견하였습니다. 코딩으로 무언가 새로운 것을 만드는 프로그래머도 매번 틀을 벗어난 일을 하고 있는 사람이 아닐까 생각합니다. IT도 예술가도 그리고 개발자도 틀이란 구조에서 벗어나 좀 더 자유롭고 새롭게 나설 때 혁명이 일어나지 않을까 생각합니다.