Stop Thinking, Just Do!

1990년대 후반 오픈 소스 관계형 데이터베이스[Strozzi NoSQL]의 이름으로 처 음 등장한 ‘NoSQL’이란 용어는 멋진 반어법이라 할 수 있다. 카를로 스트로치 (Carlo Strozzi)가 주도한 이 데이터베이스는 테이블을 아스키 파일에 저장했고 각 튜플은 탭으로 분리된 필드의 행으로 표현했다. 이 데이터베이스에서는 질의어로 SQL을 사용하지 않는다는 이유로 NoSQL이라는 이름이 붙었다. 이 데이터 베이스에서는 유닉스 파이프라인으로 조합할 수 있는 셸 스크립트를 통해 조작이 이루어졌다. 용어가 우연히 일치한 것을 제외하면, 스트로치의 NoSQL은 빅데이터에서 다루는 NoSQL과는 관련이 없다.

우리가 인식하는 NoSQL이란 용어 사용의 기원은 런던 출신 소프트웨어 개발자 조핸 오스카슨(Johan Oskarsson)이 2009년 6월 11일 샌프란시스코에서 조직 한 비공식적 모임으로 거슬러 올라간다. 빅 테이블과 다이나모의 예는 대안 데이터 저장소를 실험하는 여러 프로젝트에 영감을 주었고, 이에 대한 논의는 당시 좋은 소프트웨어 컨퍼런스의 특징이 되기도 했다.

조핸은 하둡 서밋을 위해 샌프란시스코에 와 있는 동안 이런 새로운 종류의 데이터베이스에 대해 더 많이 알고 싶었다. 그는 시간이 많지 않았기 때문에, 그들을 모두 방문하는 것은 어렵다고 생각했다. 그래서 그는 관심 있는 사람은 누구나 참석해 한자리에 모여 자신의 작업을 발표할 수 있도록 비공식적 모임을 주관하기로 했다. 조핸은 모임을 위한 이름을 짓고 싶었는데, 트위터 해시 태그로 쓰기 좋고, 짧 고 기억하기 쉽지만, 구글 검색 결과가 너무 많지 않아 검색하면 빠르게 찾을 수 있는 그런 이름을 원했다. 그는 #cassandra IRC 채널에 제안을 요청해 몇 가지 안을 받았고, 그중 에릭 에반스(랙스페이스에서 일하는 개발자로 DDD 에릭 에 반스와는 무관)가 제안한 ‘NoSQL’을 선택했다. 부정적으로 보이고 이런 시스템을 제대로 표현하지 못한다는 단점이 있었지만 해시 태그 조건에는 딱 맞았다. 그 당시는 그저 모임 이름을 생각했을 뿐이었고, 기술 동향 전체를 나타내는 이름으로 유행하리라고는 예상하지 못했다.

NoSQL이란 용어는 들불처럼 퍼져나갔지만 정확하게 정의된 적은 없었다. 모임을 위한 원래의 요청은 ‘오프 소스, 분산, 비관계형 데이터베이스’를 위한 이름이었다. 이 모임에 볼드모트, 카산드라, 다이노마이트, H베이스, 하이퍼테이블, 카우치DB, 몽고DB가 참석했지만, NoSQL이 란 용어는 결코 초기 7인조에 국한되지 않았다. 일반적으로 통용되는 정의도 없고, 정의를 내리는 권위자도 없기 때문에 할 수 있는 일이라고는 NoSQL이라 부르는 데이터베이스의 공통 특성을 논의하는 것뿐이다.
분명한 점 한 가지는, NoSQL 데이터베이스는 SQL을 사용하지 않는다는 것이다. 일부 NoSQL 데이터베이스는 질의어를 지원한다. 질의어를 배우기 쉽게 하려면 SQL과 비슷하게 하는 것이 타당하다. 카산드라의 CQL이 이런 경우로

SQL이 아니라는 점만 빼면 SQL과 거의 비슷하다.

그러나 지금까지 어떤 NoSQL 데이터베이스도 표준 SQL 개념보다 융통성 있는 것을 만들어내지 않았다. NoSQL 데이터베이스가 자리를 잡고 나서 표준 SQL을 지원하기로 결정한다면 어떤 일이 일어날지 흥미롭다. 이런 만일의 사태가 발생한다면 엄청난 논쟁이 생길 수밖에 없다. NoSQL 데이터베이스의 또 다른 주요 특징은 보통 오픈 소스 프로젝트라는 점이다. NoSQL이란 용어는 비오픈 소스 시스템에도 자주 사용되지만, NoSQL은 오픈 소스 현상이라는 견해가 많다.
NoSQL 데이터베이스는 대부분 클러스터에서 실행할 목적으로 만들어졌으며, 최초 모임에서 논의된 데이터베이스에 대해서는 확실히 맞는 말이었다. 이는 일관성에 대한 접근 방법뿐 아니라 데이터 모델에도 영향을 끼쳤다. 관계형 데이터베이스에서는 데이터베이스 전반에 걸쳐 일관성을 유지하려고 ACID 트랜잭션(transaction)을 사용한다. 이는 클러스터 환경과 본질적으로 맞지 않으므로 NoSQL 데이터베이스는 일관성과 분산에 관해 여러 종류의 선택 사양을 제공한다.
그러나 모든 NoSQL 데이터베이스가 클러스터에서 실행되도록 맞춰지지는 않았다. 그래프 데이터베이스는 NoSQL 데이터베이스의 한 형태로 관계형 데이터 베이스와 비슷한 분산 모델을 사용하지만 복잡한 관계의 데이터 처리에 유리한 다른 데이터 모델을 제공한다.

NoSQL 데이터베이스는 보통 21세기 초반 웹 환경의 필요에 기초를 두고 있어서, 이 시기에 개발된 시스템만을 NoSQL이라 부른다. 따라서 코드(Codd)1 이전은 물론이고 새 천년 이전에 만들어진 데이터베이스도 NoSQL에 포함되지 않는다. NoSQL 데이터베이스는 스키마 없이(schemaless) 동작하며, 구조에 대한 정의를 변경할 필요 없이 데이터베이스 레코드에 자유롭게 필드를 추가할 수 있다. 이런 특징은 균일하지 않은 데이터나 커스텀 필드를 다룰 때 특히 유용하다. 관계형 데이터 베이스에서는 customField6 같은 이름을 사용하거나 처리하기도, 이해하기도 어려운 커스텀 필드 테이블을 사용해야 했다.
앞에서 설명한 모든 것은 NoSQL 데이터베이스라고 설명한 것들의 공통 특징이다. 이 중 어느 것도 명확하지 않으며, NoSQL에 대한 일관성 있는 정의는 나오지 않을 것 같다.
우리가 이 주제에 열광하는 주된 이유는 NoSQL의 출현으로 데이터 저장소 선택 범위가 늘어났다는 데 있다. 따라서 넓어진 선택 범위가 NoSQL 저장소로 국한되어서는 안된다. NoSQL 이전의 데이터 저장소를 포함한 다른 데이터 저장소 역시 검토 범위에 포함되어야 한다.

NoSQL이란 용어를 처음 들으면, 즉시 이 용어가 무슨 뜻일까 궁금해진다. SQL이 아니라고(no)? NoSQL에 대해 말하는 사람들은 대부분 NoSQL의 실제 뜻이 “Not Only SQL”(SQL뿐 아니라)이라고 하지만, 이런 해석에는 몇 가지 문제가 있다. 사람들은 대부분 ‘NoSQL’이라고 쓰지만, ‘Not Only SQL’이 맞다면 ‘NOSQL’로 써야 한다. 또한, ‘not only(뿐 아니라)’의 뜻으로 뭔가를 NoSQL 데 이터베이스라 부른다 한들 아무런 의미도 없다. 그런 식이라면 오라클이나 포스트그레스도 이 정의에 맞을 것이다. 이 문제를 해결하기 위해 우리는 NoSQL이 무엇의 약어인지 고민하는 대신 NoSQL이 무엇을 뜻하는지에 집중하자고 제안한다(다른 모든 약어에 대해서도 권장되는 방법이다). 따라서 NoSQL이 데이터베이스에 적용되면, 제대로 정의되지는 않았지만 대부분이 오픈 소스고 21세기 초반에 개발되었으며 SQL을 사용하지 않는 데이터베이스를 뜻하는 것이다.
‘not-only’ 해석은 많은 사람들이 생각하는 데이터베이스의 미래 생태계를 묘사하는 그 나름의 가치를 지닌다. 사실 이 점이 not-only 해석의 가장 중요한 기여라고 생각한다. NoSQL은 기술이라기보다는 동향으로 보는 것이 옳다. 관계형 데이터베이스가 사라지리라고 생각하지는 않는다. 관계형 데이터베이스는 앞으로도 가장 일반적으로 사용되는 데이터베이스가 될 것이다. 관계형 데이터베이스의 친숙함, 안정성, 다양한 기능, 기술 지원 등은 대다수 프로젝트에서 주목하지 않을 수 없는 요소다. 바뀐 것은 이제 우리가 관계형 데이터베이스를 데이터 저장소에 대한 한 가지 선택 사양으로 본다는 점이다. 이런 관점을 다중 저장소 지속성(polyglot persistence)이라 부르기도 한다. 즉 상황에 따라 다른 데이터 저장소를 사용한다는 뜻이다.

다들 사용한다는 이유로 관계형 데이터베이스를 선택하는 대신, 우리가 저장하는 데이터의 본질이 무엇인지, 이 데이터를 어떻게 조작하고 싶은 지 이해해야 한다. 그 결과 대다수 조직이 여러 기술을 혼용해 각 상황에 맞는 데 이터 저장소를 사용할 것이다. 이렇게 여러 저장소가 혼합된 세상이 동작하려면 통합 데이터베이스에서 애 플리케이션 데이터베이스로 이동해야 한다는 게 우리의 관점이다.

NoSQL 데이터베이스를 통합 데이터베이스로 사용하는 것은 일반적으로 좋은 선택이 아니라고 생각하지만, 그렇다고 이것이 NoSQL의 단점이라 생각하지도 않는다. NoSQL을 사용하지 않더라도 데이터를 서비스로 캡슐화하는 것이 좋은 방향이다. NoSQL을 사용해 개발할 때, 우리는 클러스터에서 실행되는 빅 데이터에 집중했다. 이것이 데이터베이스 세상을 넓히는 중요 요소라 생각하지만, 프로젝트 팀에서 NoSQL 데이터베이스를 고려하는 이유는 이뿐만이 아니다. 이와 동등하게 중요한 문제는 객체-관계 불일치 문제에 대한 오랜 불만이다. 빅 데이터에 대한 우려로 데이터 저장소 요건에 대해 새롭게 생각하는 사람들에게 기회가 생겼다. 어떤 개발 팀은 NoSQL 데이터베이스 사용이 (장비 한 대면 충분한 상황에서 조차) 데이터 접근을 단순화해 생산성을 높이는 데 도움이 된다고 판단한다.

NoSQL을 고려하는 데는 두 가지 주요 이유가 있음을 기억하기 바란다.

• 하나는 클러스터가 필요한 규모의 데이터 크기와 성능 요건 하에서의 데이터 접근 처리고,

• 다른 하나는 좀 더 편리한 데이 터 조작 방식을 통한 애플리케이션 개발 생산성 향상이다.

References

[1] Martin Fowler. “NoSQL Distilled: A Brief Guide to the Emerging World of Polyglot Persistence.”, Addison-Wesley, 2013.