SQL? NoSQL? NO!

1. SQL의 문제점

RDB에서 데이터를 계층적으로 분리하여 저장한다면 여러 개의 테이블로 구성하여 참조키(=외래키)와 조인연산(JOIN), 중첩쿼리(Nested)가 조합된 복합쿼리로 조회가 가능하다. 그런데 이 복합 쿼리라는 게 테이블 구조가 간단 할 때는 그러려니 하지만, 셋 이상의 테이블이 관계되어 구성되면 쿼리가 심각하게 복잡해진다. 이 때 부터는 사실상 데이터 조회를 위해 쿼리를 '설계'해야 하는 지경에 이르게 되는데 아무리 쿼리를 잘 설계를 해도 가독성 뿐만 아니라 성능까지 염려스러운 상황이 되어 버린다. DB를 잘 다루는 사람들은 아마 이 상황을 잘 통제하는 사람을 두고 하는 말일 것이다.

2. NoSQL의 필요성

그럼 NoSQL은 왜 나타났을까 곰곰이 생각해보면, 다른 배경도 분명 있긴 하겠지만 지극히 개발의 관점에서 복잡하게 구성된 DB의 조회를 위한 쿼리 개발의 어려움도 한 몫 하지 않았을까 한다. 실제로 NoSQL을 써보면 그 이름처럼 SQL개발에 대한 어려움은 덜 하다. 대신 데이터의 조회를 위해 응용 애플리케이션에서 로직을 구현해야 하지만, 기능 구현에 제약이 많은 SQL보다는 로직 구현이 수월한 편이다. 예를 들어, 응용 애플리케이션에서 SQL과 동일한 로직을 구현한다고 한다면 먼저는 Syntax, Runtime Error를 잡아 내기에 개발 툴 부터가 SQL 코딩 환경에 비해 훨씬 좋을 뿐더러, 데이터 처리를 위해 적용할 수 있는 내장/외부 라이브러리의 종류와 양도 크게 차이난다.

3. NoSQL 적응의 어려움

물론 NoSQL이 만능은 아니다. RDB에 익숙한 사람들이 아직 적응이 되지 않고 학습이 덜 된 시점에서는 답답해 미칠 노릇이다. 비록 언급한 바와 같은 SQL이 가진 단점에도 불구하고 비교적 간단한 테이블 구성에서의 SQL은 문법이 갖는 간결함 때문에 확실히 코딩 시간을 줄여 준다는 장점이 있는데, 실제로 이런 간결함 때문에 SQL과 유사한 문법을 가진 LINQ가 닷넷 프레임워크에 포함된 바 있다. 아직 SQL에서 탈피하지 못한 사람들은 NoSQL로 개발을 하면서 SQL과 같은 조회 방식을 할 수 있는 방법을 찾는 데 시간을 허비할 수도 있을텐데, 만약 이런 사람이 있다면 시간 낭비하고 있는 것이 아닌가 싶다. SQL이면 한 줄로 끝낼 일을 NoSQL에서는 여러 줄을 작성해야 하다 보니 개발중에도 잘하고 있는 짓인가 의문이 들테지만, NoSQL은 그게 맞는 듯. NoSQL은 SQL과 애초부터 접근 자체가 다르다.

4. NoSQL의 장점

NoSQL이 갖는 진정한 가치는 RDB가 가진 계층에 대한 집착(?)을 깨부수었다는 점이다. 스키마리스(Schemeless)인 NoSQL DB에서는 다른 데이터 간의 계층이나 관계가 매우(!) 느슨하다. 덕분에 NoSQL DB는 분산과 확장이 매우 용이하다. RDB에서는 테이블과 데이터의 참조 관계에 의한 의존과 종속이 매우 심한 탓에 수직적으로나 수평적으로나 테이블의 분리가 어렵다. 사람 간의 관계를 예를 들어 설명해보자면, 재산이나 추억을 공유하고 있는 가족 간에는 관계를 끊기란 어렵지만 그런 것들이 없는 친구나 타인과는 관계를 끊기기 상대적으로 쉽다. 이 예시가 부적절할 수도 있지만 아무튼 스키마리스의 설계에서는 상호 간 관계가 적다 보니 분리하기도 쉬움을 말하고 싶었다.

5. 상황에 따른 SQL/NoSQL 채택

NoSQL은 태생부터가 대용량 데이터를 다루기 위해 탄생했던 탓인지, 경험상 의외로 NoSQL DB를 채택해야 하는 경우는 많지 않고 명분도 부족했다. 엔터프라이즈급 이하의 작은 시스템이라면 데이터의 양도 적고 테이블 설계 역시 많이 복잡하지 않을텐데, 이정도 수준의 시스템이라면 관리와 운영 효율을 위한 써드 파티의 관리자용 애플리케이션을 개발할 여력도 없을테고, 그럴 필요도 없을 것이다. 엔터프라이즈급에서는 이미 시스템을 운영하는 비개발자 인력이 배치되므로 써드 파티 애플리케이션이 필수적이고 이를 통해 데이터를 괸리할 수 있겠지만, 써드 파티를 만들 여력이 없는 상황에서 무모하게 NoSQL DB를 채택하여 시스템을 구축한다면 이후 운용 난이도가 생각보다 만만치가 않을 것이다. 관리를 위한 전용 애플리케이션이 없다 보니 저수준의 코드를 통해 데이터를 확인하고 조작해야 할텐데, 규모가 작은 시스템에서는 SQL 코딩은 그리 어려운 일도 아니고 이때는 오히려 SQL이 갖는 편의성과 효율성은 극대화될 것이다. 생각해보면 SQL이 탄생했던 시대와 NoSQL이 탄생한 시대는 데이터와 시스템의 규모가 크게 차이가 나지 않던가?

정리하자면 무엇이든 상황과 맥락에 맞게 적용해야 한다는 것! NoSQL이 비교적 최근에 나온 기술이라 해서 모든 상황에 좋지만은 않더라.