SQL tuning 작업은 이제 불필요하다?

 

아마존 창업자 제프 베이조스(Jeff Bezos)의 고객 경험 전략

1) 사람이 인간으로서 가지고 있는 본능에 응답하는 것
2) 기술의 진화로 일어나는 문제와 스트레스를 해결하는 것
3) 사용자 한 명 한명에 맞춘 권유와 추천으로 '빅데이터 AI'가 실시간으로 일대일 마케팅을 실행하는 것
4) 고객이 거래하고 있다고 느끼지 않게 하는 것

- 트랜드코리아2020 중에서 -

 

  판매 시장 경쟁이 심화되면서 판매업체들의 마케팅 전략이 바뀌어가고 있다고 한다.
  과거에는 단순히 제품에 대한 장점을 내세운 광고를 통해 다수의 고객의 시선을 사로 잡기 위한 전략이 주를 이뤘다.
  하지만, 날로 경쟁이 치열해지면서 개인만을 위한 마케팅이 부각되고 있다.
  여기서 더 나아가 시시각각 변화하는 고객의 심리를 분석하는 초개인화 마케팅으로 고객의 구매도를 높이는 전략을 사용한다고 한다.

 

  이러한 초개인화 마케팅이 가능한 이유가 무엇일까?
  현대의 소비자들은 네트워크 접점에서 수많은 데이터를 생산해내고 있다. 기업들은 고객이 생산한 데이터들을 수집하여 자신들의 데이터베이스에 차곡차곡 쌓아두게 된다. 이렇게 저장된 다양한 데이터를 기반으로 각 고객의 소비 패턴을 분석하고 소비자의 심리를 파악하여 향후의 소비를 예측할 수 있게 되었다.
  데이터 수집/분석으로 초개인화 마케팅을 위한 발판을 마련할 수 있게 된 것이다.
  이러한 사업 생태계에 적응하기 위해 기업들은 데이터의 중요성을 인식하고 최대한 다양하고 많은 데이터를 수집하려고 한다.

 

  하지만, 수많은 데이터를 무조건 수집한다고 경영진이 원하는 매출을 높일 수 있는 고품질의 마케팅 재료가 될 수는 없을 것이다.
  IT업계에서 오래전부터 명언으로 여겨지는 한 문장이 있다. 'Garbege In, Garbege Out.'. 프로그램의 입력 데이터가 쓰레기이면 결과도 쓰레기라는 뜻이다. 데이터 분석에도 당연히 적용되는 문장이다.

  만약, 고객의 사용 구매 패턴을 분석하여, 정기적으로 의류를 구매하던 고객의 구매 주기가 점점 길어지게 되자 캠페인의 일환으로 쿠폰을 제공해주게 되었다고 하자.
  쿠폰 발급을 알리기 위해 고객에게 전화로 Outbounding(외부 영업. 텔레마케팅도 이에 속한다. 반대로 Inbounding은 고객이 고객센터에 문의하는 경우라 생각하면 된다.) 실시하였다.
  "사랑합니다. OOO고객님. ***쇼핑몰입니다."
  이에 대한 고객의 반응.
  "전화 잘못 거셨습니다. 저는 OOO가 아니고요. ***쇼핑몰은 처음 들어보는데요."
  어디서부터 문제였을까?
  물론 고객이 최근에 전화번호를 변경했을 수도 있다. 하지만, 시스템 운영의 에러로 고객 데이터가 Garbege로 전락해버리는 경우가 전혀 발생하지 않는다고 장담할 수 없다는 게 현실이다.

 

  위의 경우에서 알 수 있듯이, 데이터를 활용하기 위해서는 우선 데이터의 품질을 믿을 수 있어야한다. 다른 말로 표현하면 데이터의 가치를 높이기 위해서는 기본적으로 데이터의 무결성이 보장되어야 한다는 것이다. 그리고 그 배경에는 무결점인 데이터를 양산해내는 정확하고 유연하게 설계된 시스템이 존재해야 한다.
  원론적인 이야기이지만, 모든 일에 기초가 중요하듯이 가치있는 데이터를 수집하기 위해서는 기초 작업인 데이터베이스 설계가 중요하다는 뜻이다. RDBMS를 기준으로는 데이터 표준을 준수하여 정규화된 데이터 모델을 설계하는 작업이 중요한 초석이 된다는 것이다.

 

  여기에서 한걸음 더 나아가 생각해보자.
  데이터를 활용하기 위해서는 데이터의 품질도 중요하지만, 다양하고 많은 데이터가 필요하다. 빅데이터의 특징인 3V(Volume: 규모, Variety: 다양성, Velocity: 속도)에 충족하는 데이터가 준비되어야 한다는 뜻이다. 고객의 구매 패턴을 분석하고자 하는데, 비회원으로 1개의 상품을 주문한 기록만으로는 구매 패턴을 유추할 수는 없는 노릇이다.

  그러면 어떤 방식으로 더 다양한 데이터를 많이 수집할 수 있을까?
  최근에는 사용자의 성향을 파악하기 위해 다양한 데이터를 수집을 한다고 한다.
  예를 들어, '장바구니에 보관된 상품은 무엇인가?', '검색이나 문의사항에 대한 텍스트 마이닝 결과는 무엇인가?', '목록을 스크롤 하다가 정지한 시점에 표출된 게시물은 무엇인가?', '유입 경로는 어떻게 되는가?' 등 이러한 질문의 결과를 파악할 수 있는 백데이터도 중요한 수집대상이 되고 있다고 한다. 이러한 데이터를 수집하기 위해서는 당연히 아이디어가 선행되어야 하고, 그에 따른 데이터를 수집할 수 있는 환경을 사용자에게 제공해줘야 한다.

  사용자 활동 분석을 위해 사용자의 스크롤 이벤트를 저장한다고 가정을 해보자. 이 작업을 위해서는 스크롤 이벤트에 관한 정보를 실시간으로 저장하는 기능을 구현해야 하는 것은 기본이다. 더 나아가 사용자가 마음껏 스크롤을 할 수 있는 환경을 제공해줘야 한다. 사용자가 원하는 물품을 찾고자 상품 목록을 스크롤 중인데, 상품 정보가 스크롤 후 1초 뒤에나 표시된다면 사용자의 스크롤 액션은 이어짐 없이 매 순간마다 끊김이 발생할 것이다. 더 아나가 인내심이 부족한 사용자는 검색을 포기하고 다른 사이트를 찾아갈 것이다.

  시스템의 느린 성능으로 더 많은 데이터를 수집 할 수 있는 기회를 놓쳐버린 것이다. 역으로 이야기하면 다양하고 많은 데이터를 수집하기 위해서는 고성능의 서비스를 제공할 수 있는 시스템이 구축되어야 한다는 것이다.

 

  지금까지 설명한 데이터를 제대로 활용하기위한 2가지 전제 조건은 다음과 같다.

1) 데이터 무결성을 보장할 수 있는 정확하고 유연한 시스템 설계
2) 사용자가 제약없이 마음껏 이용할 수 있는 고성능의 시스템 제공

  이 2가지 전제 조건 중에서 두 번째 조건인 고성능의 시스템, 그중에서도 데이터베이스의 성능 향상에 대해 이야기를 해보고자 한다.

 

 

  필자는 신규 시스템을 구축하는 SI(System Integration) 프로젝트 중심으로 업무를 진행해왔다. SI 프로젝트의 특징 상 여러 사이트를 돌아다니면서 업무를 수행하였고, 다양한 사이트에서 근무를 하다 보니 많은 사람들을 만나게 되었다. 다수의 분들은 데이터 설계와 성능의 중요성을 정확히 인지하고 계셔서 고품질의 결과물을 생산하기 위해 적극적으로 협력하고자 하였다.

  하지만, 아쉽게도 데이터베이스 성능에 대한 오해를 하시는 분들도 간혹 만나기도 하였다. 그분들이 갖고 있는 데이터베이스 성능에 대한 오해의 예는 다음과 같다.

'Optimizer가 자동 SQL튜닝을 수행하는데요. 정규화나 SQL 튜닝 작업이 왜 필요한 거죠?'
'디스크/메모리가 부족하면 추가하면 돼요. 하드웨어 가격이 저렴 하잖아요.'

  위 정보가 100% 잘못된 것은 아니다. 

  자동 SQL 튜닝을 자사 제품의 특징으로 내세우는 RDBMS가 존재하고, Optimizer의 기능을 향상하기 위해 RDBMS 솔루션 업체들이 연구/개발을 하고 있는 것은 사실이기 때문이다. 필자도 Query rewrite 기능에 의해 쿼리 성능이 좋아진 경우도 실제로 확인한 적도 있었다.

  하지만, 필자가 SQL 튜닝 업무를 담당했을 때 검출되었던 악성 쿼리들을 보고 나면 데이터베이스 최적화라는 업무 영역은 앞으로도 영원히 살아남을 수밖에 없겠다는 생각을 하게 되었다. 불필요하게 중복 액세스 하는 쿼리, 개발상 편의를 이유로 Select절에서 사용자 정의 함수를 과도하게 호출하는 복잡한 쿼리들을 보면 RDBMS의 자동 튜닝 기능의 한계도 같이 보이는 것 같았다. 어차피 Optimizer와 자동 SQL 튜닝 기능도 인간의 작품이라는 한계점이 있을 것이다.
  인공지능이 발달한다 해도 이 세상의 SQL을 모두 다 최적화하지는 못할 것이다.  SQL이 정해진 문법이라는 공식을 준수하여 작성되지만, 작성 패턴에는 공식이 없으며 다수의 개발자들 각각의 스타일대로 작성되기 때문이다. 그리고 개발 기간이라는 시간적 제약에 의해 깊이 생각하지 못하고 빠르게 결과물을 출력하기 위해 절차적인 방식으로 쿼리를 작성하여 쿼리 문장이 더 복잡해지는 경우가 많기 때문이다.

 

  빅데이터 시스템의 경우도 생각해보자. 대표적인 빅데이터 시스템인 하둡은 분산 저장하고 분산 처리하여 대용량의 데이터를 빠르게 처리하는 시스템이다. 작업을 분산 처리하는 방식이니 자원이 부족하면 데이터 노드를 추가하여 성능을 높여주면 된다고 한다.
  하지만, 고사양(RAM 256GB에... 더 이상 기억 안 난다. 나는 숫자 외우는 거에 약하다...) 데이터 노드가 30개 이상이었던 시스템에서 쿼리 하나가 실패되어 후속 배치 작업도 도미노처럼 줄줄이 실패되는 현상을 목격했었다. 데이터 노드가 고사양이어도, 하둡에서 Fail 된 Task를 일정 횟수만큼 Retry 하더라도 최적화가 안된 악성 쿼리는 결국 실패할 가능성이 존재하는 것이다.

 

 

  앞에서도 잠깐 언급했지만, 힘들게 구축된 시스템이 최적의 성능을 내지 못하는 가장 큰 이유는 촉박한 개발 일정으로 결과물을 빨리 보여주는 것에만 집중할 수밖에 없는 현실 때문이라고 본다. 장인 정신으로 시스템의 최적화를 고려해보는 것은 시간적 사치라고 생각하시는 분들도 더러 있을 수도 있다.

  시간에 쫓겨 급하게 처리해서 대충 마무리 짓는 쳇바퀴 도는듯한 업무 방식에 익숙해져 있다면, 본인의 업무 역량의 한계점을 정해놓고 앞으로 달려가고 있는 것이 아닐까? 

  "대학 경 1장"에서는 멈추고 생각을 한 후에야 얻을 수 있다고 하였다. 잠시 여유를 가지고 본인이 담당하고 있는 시스템의 최적화를 고민해보는 시간을 갖는다면 본인의 역량을 키우는 또 다른 첫걸음을 내딛을 수 있을 것이다.

 

  SQL 튜닝은 어렵다? 데이터 아키텍처 최적화가 가능한가? 처음부터 이런 의문으로 최적화에 대한 두려움을 느끼시는 분들도 있을 수 있다. 무엇이든 방향성 없이 시작하는 것은 어렵게 느껴지니까 말이다. 그럴 때 가장 좋은 방법은 따라 하기라고 생각한다. 다양한 케이스의 예제를 접해보고 이해한다면 언젠가는 직접 적용해보고 응용해 볼 수 있는 기회를 만날 수 있을 것이다.

 

  필자는 앞으로 이 블로그에서 SQL 튜닝 & 데이터 아키텍처에 대한 최적화 예제를 포스팅하려고 한다. 미리 예고하지만 빠른 시간 내에 많은 예제를 보여줄 수 있다는 자신감은 없다. 이렇게 글을 쓰고 있지만 나에게는 아직도 글쓰기가 힘들게 느껴지는 일이다. 그리고, 보여줄 수 있는 소재의 한계도 있으니까 말이다.

  그래도 SQL 튜닝에 대한 성취감을 많은 분들이 느낄 수 있도록 최선을 다해 포스팅해보도록 하겠다. 글을 쓰는 나에게도 다시 한번 정리의 기회가 되고, 다른 분들한테도 영감을 줄 수 있는 즐거운 일이 될 테니까 말이다.