Shine A Light

애시당초 SNS서비스를 많이 사용하고 Facebook이나 Twitter에서 Cassandra에서 MongoDB로 넘어가기 시작했다는 글들을 보면서 우리 역시 NoSQL에 관심을 가지게 되었고, 이번에 도입하기로 결정하면서 결국 MongoDB를 선택했다. 아직 회사내에서도 이렇다하게 사용해본 개발자도, 적극적으로 NoSQL을 도입하여 사용하고 있는 부서도 거의 없었기에 많은 부분 맨땅에 헤딩을 하면서 프로젝트를 진행할 수 밖에 없었다.

이를 통해 느끼게 된 점이 생각보다 꽤 많은 것 같다. 다른 기술적인 문제는 나중에 차차 다른 포스팅을 통해 다루도록 하고 이번 포스팅에서는 직접 사용해보면서 느끼게 된 점을 위주로 포스팅 하려 한다.

과연 NoSQL은 현 웹서비스에 있어 우수한 솔루션일 수 있을까? 

답 : Yes or NO

이번에 우리가 준비하는 신규서비스는 SNS를 빗댄 개인화적인 서비스였다. 그러기에 더더욱 NoSQL을 도입하고자 하였고, 프로젝트 초기엔 우리의 선택이 옳았다고 생각했다. 하지만 점점 진행될 수록 나 개인적으로는 무엇인가 문제가 있다는 생각이 들었다. 그 이유로는 바로 RDBMS가 가지는 Join의 개념이었다. NoSQL은 Schemeless인 형태로서 Join의 개념이 없다. 이것이 항상 문제가 되지는 않는데, 우리의 경우엔 문제가 될 수 있었다. 그 이유는 바로 페이지의 구성 내용이다. 한 페이지에 다양한 종류의 데이터를 노출시켜줄 필요가 있다면 이 경우에는 문제가 될 수가 있다. Join자체가 없기 때문에 매번 해당 정보를 가져오기 위해 각각의 Collection을 조회하여 데이터를 가져와야하는 단점이 생기기 때문이다. 가령 예를 들어, 우리나라 포탈사이트들의 메인화면과 트위터를 비교해보자. 우리나라 포털 사이트들의 메인은 거의 백화점 수준으로 다양한 종류의 데이터를 한번에 노출시키고 있다. 이 경우 NoSQL은 한 페이지를 띄우기 위해 해당 종류 만큼의 Collection에 쿼리를 날려 데이터를 가져와야 한다.(물론 메인화면 자체를 통으로 NoSQL로 저장하고 있다면야 문제될 것이 없다...) 하지만 트위터의 경우 페이지에 노출시켜야 할 정보의 종류가 극히 제한적이며 명확하다. 이 경우 NoSQL에 해당 종류에 따라 Collection을 구성하고 사용하여도 하등의 문제가 없다...

아마 우리가 NoSQL에 기본적인 개념에 대해 많은 부분 습득하지 못한채 진행하기에 발생하는 문제였을지도 모른다. 아무래도 수년간 RDBMS 시스템에 익숙해져 있던터라 Schemeless의 개념에 충실하지 못했을 수도 있고, 필요이상으로 Collection을 여러개로 쪼개서 사용했을 수도 있다..(사실 막상 생성하여 사용한 Collection은 6개 밖에 되지 않기는 하다 -_-;;;) 하지만 분명한 건 기존의 RDBMS의 성향을 완전히 버리지 못하거나, 아예 필요가 없을 법한 Log성 데이터에 기반한 서비스나 시스템이 아니라면, 분명 이러한 문제에 직면할 수 있다라는 것이다. 특히 우리나라 웹환경 처럼 한 페이지에 백화점식으로 다양한 데이터를 노출시켜주어야 하고, 서로 다른 데이터를 서로 Mesh하여 또 다른 새로운 데이터를 생성하여 보여주는 구조에 있어서는 분명 NoSQL은 명확한 해답은 아니라는 생각이다. 물론 설계를 어떻게하고, 어떠한 부분에 있어서 적용할 것인지에 대한 고민과 설계에 따라 그 결과는 뒤집힐 수 있겠지만, 결국 태생적으로 안고 있는 구조적인 차이는 쉽게 극복되지 못하리라는 생각이다.

우리 역시 NoSQL이 완벽하게 기존의 RDBMS 시스템을 대체할 수 있으리라 생각하지 않는다. 분명 두 시스템의 컨셉자체가 완연하게 다르고 NoSQL 진영에서도 자신들이 RDBMS의 완벽한 대체자가 될 수 있다고 생각하지도 않는다. 특히 Replica Set에서의 Failover 구조나, Sharding구조는 기존 RDBMS가 가지기 힘든 가장 매력적인 요소 중에 하나이다. 이렇듯, 아마도 이 서로 다른 시스템을 어떻게 조화롭게 잘 적용하느냐에 따라 더욱 시스템을 강건하게 만들어 줄 수 있음은 분명하다. 향후 NoSQL을 적용하는데 있어서 단순히 기술적인 이슈만이 아니라, 페이지 구성이나 서비스 자체에 대한 근본적인 고찰과 고민이 분명 동반되어야 가장 효과적으로 NoSQL을 사용할 수 있다는 생각이 든다.

부디 NoSQL의 도입을 준비하는 많은 개발자분들께 조금이나마 도움이 되었기를....