최근 몇 년간 프론트엔드 웹 개발 기술 혁신이 일어나다 보니 백엔드 기술에 다소 소홀해진게 사실이다.

과거 CTO Staff으로 있을 때 전사 개발 플랫폼에 신경을 쓰던 때와 비교해 볼 때 특히 그렇다.

얼마 전 HTML5 오픈 콘퍼런스 강의를 준비하면서 웹 개발 플랫폼의 변화를 생각하는 도표를 만든 적이 있다. 사실 프론트엔드 뿐만 아니라 백엔드 부분의 변화도 크다.

사용자 삽입 이미지

웹 표준(구조/표현/동작분리)기반 프론트엔드와 가벼운 MVC 프레임웍이 지배하던 웹 2.0시대가 지나고 웹 애플리케이션과 소셜웹 시대가 접어들면서 HTML5기반 프론트엔드와 데이터 읽고/쓰기(I/O) 위주의 단순한 백엔드 시대가 접어들었다.

백엔드 기술 플랫폼의 변화
페이스북이나 트위터 같은 데이터 조각(piece)를 다루는 웹 사이트들 그리고 읽기(Read) 만큼 쓰는(Update) 소셜 웹 서비스 데이터 증가 때문에 특히 그렇다.


대개 이런 경우 거의 비슷한 종류의 해법을 찾게 되는 데, 바로 빠른 데이터 접근을 위한 분산 데이터 스토어와 메모리 캐시 같은 방법들이다. 과거 MVC(Model-View-Controller) 기반의 백엔드와 확연히 다르다.

과거 웹 2.0 시대에 Ruby on Rails, CakePHP 같은 빠르고 가벼운 개발 MVC 프레임웍이 각광을 받았으나, 서비스의 형태에 따라 점점 변화하고 있는 상태이다.

따라서, 백엔드 서버가 과거의 웹 문서 배포를 벗어나서 Ajax나 WebSocket을 통해 구조적 데이터 서비스 혹은 실시간 데이터 교류로 변화될 것으로 보인다. 이는 웹이 문서 기반에서 애플리케이션 플랫폼으로 가는 데 있어 필연적인 변화가 아닐까 싶다.

NoSQL의 급속한 성장
상황이 이러니 관계형 DB의 역할이 많이 약화 되고 있다. 읽기 만큼 쓰기가 늘어나면서 DB Pool이 병목 구간이지만 실제 업데이트 되는 데이터들이 늘어나면서 이른바 NoSQL이라고 불리는 분산형 데이터 스토어들이 각광을 받기 시작했다.

특히, 페이스북과 트위터에서 사용하기 시작해서 매우 인기가 높은 카산드라(Cassandra)와 Hadoop기반의 HBase와 같은 분산형 데이터 스토어가 그렇다. 이들은 오픈 소스이면서 최근 소셜 웹 기반 서비스에 많이 차용되고 있다. 또한, RDB와 중간 사이에 CouchDB와 MogoDB같은 것도 있다.

분산 스토리지와 RESTful API를 통한 데이터 접근 방식은 복잡성으로 인한 개발 비용을 줄여 준다. Ranging Query 때문에 RDB를 쓸 필요가 있긴 하지만, 서버 운영, 모니터링, 데이터 중복성 모든 관점에서 데이터베이스 수업에서 배운 것을 다 버려야 할 지경이 되었다.


물론 아무때나 이들을 쓰는 게 좋은 건 아니다. 먼저, 데이터 업데이가 매우 빈번하고 비교적 데이터 형식이 단순하며 휘발성인 로그(log)처럼 쌓는 경우가 좋다. Yahoo! Research에서 조사한 분산 DB 성능에 대한 논문에 따르면 읽기(Read)인 경우 기존 MySQL이 성능이 더 낫다.

NoSQL 접근 방식
NoSQL이 시대 변화를 따르는 멋진 방법이긴 하지만 어설프게 적용했다가 RDB로 돌아가는 사례도 생기고 있다. 그러다 보니 NoSQL에 대한 논쟁이 뜨겁다.

물론 대안이 있다. 일반적으로 memcached 같은 메모리 캐시를 이용하는 방법이나 기존 DB Replication을 잘 활용하는 것이다.  전 MySQL 개발자들이 만들고 있는 Drizzle이라는 것도 있다.

NoSQL이 단순한 유행이 아닌 이유는 앞서 말한 대로 기존 RDB가 설계에 대한 비용을 높히 주고도 업데이트가 많은 환경에서 적합한 해법을 주지 못하고 있기 때문이다. 설계 비용도 적고 확장성도 높으며 데이터 저장 방식도 효율적이다.

분산 환경에서 더욱 잘 동작하고 클라우드 컴퓨팅 환경에도 적합하다는 장점이 있다. 또한 대용량 데이터를 처리하기 위한 Map/Reduce와도 궁합이 잘 맡는다.
사용자 삽입 이미지
따라서, 소셜 네트웍의 친구들간의 메시지 교환이나 댓글 처리, 방문자 업데이트 같은 경우에 사용되고 있긴 하지만 가령 학교의 수강 신청 시스템이나 은행의 일별/주별/월별 결산, 빌링 데이터 처리 같은 BI(Business Intelligence)에 적극 활용할 수 있을지 모른다.

물론 이 영역은 이미 대형 벤더들에 의해 구축되고 있는 곳이긴 하지만 온라인 기반 웹 비지니스를 하는 e-Commerce 업체들 위주로 바뀔 가능성도 있다.

무엇보다 내가 하고 있는 웹 서비스에서 적용할 수 있는지 면밀히 검토해 보는 것이 좋겠고, 개발자들이라면 개인 프로젝트나 프로토타입에서 한번쯤 직접 개발 해보는 것을 추천한다.

p.s. 개인적으로는 RDB에 익숙한 사람이 NoSQL을 접근하는데는 MongoDB가 가장 좋은 것 같다. Hadoop과 M/R 작업에 익숙한 사람은 Hbase를 해보는 게 좋다. 또한, 업데이트 쳐야할 일이 많은데 Scalability가 걱정되면  Cassandra를 써 보길 추천한다.

더 읽어 볼 글