DA가 갖춰야 할 사고 방식

DA전문가가 되기 위해서 표준화, 데이터 모델링, SQL튜닝 등 몇 가지 요소 기술들을 습득하는 것도 중요하지만, 필자가 중요하게 생각하는 사고 방식이 몇 가지 있습니다.

첫째, 집합적인 사고 방식을 갖자!

대용량 데이터베이스 튜닝 관련해서 조금 공부하셨던 분들은 많이 들어보셨을 말일 것 같습니다. 절차적인 사고 방식에서 집합적인 사고 방식으로 바꾸는 것이 하루 아침에 바뀌지 않으며, 지속적인 훈련이 필요합니다.

데이터 모델링 시에 엔티티를 선정하고, 엔티티에 대한 집합적 정의를 해두는 것이 무엇보다 중요합니다. 집합적 정의를 명확히 하지 않고 다음 단계로 넘어간다면 데이터 모델링 시에 난관에 빠지는 경우가 많습니다. 데이터 모델링 뿐만 아니라 SQL튜닝 시에도 집합적인 사고 방식은 실제로 많은 도움을 줍니다. SQL내에 존재하는 테이블, 서브쿼리, 인라인뷰 모두 하나의 집합으로 볼 줄 아는 눈이 생기면, 길고 복잡한 SQL문도 단순하게 볼 수 있는 힘이 생기며, SQL 튜닝이 쉬워지는 걸 느낄 수 있습니다.

가령, 아래 Sample SQL문의 구조를 봅시다.

SELECT ...
  FROM A,
       (
        SELECT ...
          FROM X
         WHERE ...
         UNION ALL
        SELECT ...
          FROM Y
         WHERE ...
       ) B,
 WHERE A.KEY = B.KEY
   AND A.COL1 IN ( SELECT COL1 FROM C WHERE ... )

해당 SQL 구조에서 집합은 모두 몇 개 일까요?
3개(A, B, C) 혹은 5개( A, X, Y, B, C ) 가 될 수 있습니다.
집합을 어떻게 정의하느냐에 따라 달라질 수 있습니다.
예를 들면, X 라는 집합은 개인고객, Y 라는 집합은 법인고객을 관리한다고 합시다.
B라는 집합은 개인고객과 법인고객의 합집합인 고객이라는 집합이 되겠죠.
보통은, SQL문에 UNION ALL 과 같은 문장이 많이 보이는 경우, 데이터 모델링 시에 엔티티 통합을 하지 못한 경우입니다

둘째, 분할 정복 [divide and conquer] 하자!

필자가 실무에서 SQL품질검증 업무를 하다 보면 굉장히 긴 SQL문도 많이 있습니다.
거의 매달 50건 이상씩 SQL품질검증 요청 건을 검토를 하고 튜닝이 필요한 부분은 SQL튜닝 가이드를 합니다. 대부분의 긴 SQL문들의 공통점은 UNION ALL 이나 인라인뷰가 많이 사용됩니다. SQL문이 길다고 절대로 겁먹을 필요는 없습니다.
앞서 강조했던 집합적인 사고 방식을 갖고, 집합 단위로 분할 정복을 하면 쉽게 해결이 되는 경우가 많습니다. 다만, 어느 집합을 만드는 데 비효율적이고 오래 소요되는 지 범위를 좁혀가서 해결하기 위해서는 노하우가 필요합니다.
가령, 위의 Sample SQL문의 구조에서 B라는 집합을 만드는 데 오래 소요된다고 가정합시다.
그럼 B라는 집합을 만들기 위한 특정 조건의 X 집합과 특정 조건의 Y 집합을 각각 분할해서 확인해 봅니다.
확인 결과, 특정 조건의 X 집합은 빠른 응답 속도를 보였습니다.
그럼 보나마나 특정 조건의 Y 집합을 만들기 위해 비효율이 존재하고 해당 부분에 대한 비효율 원인을 찾고, 개선하면 됩니다.

셋째, 수평적인 사고와 균형 감각을 갖자!

데이터 모델링 시에 수평적인 사고를 하는 것이 중요합니다. 데이터 모델링은 보통은 3단계로 개념 모델링, 논리 모델링, 물리 모델링으로 진행됩니다.
자칫하면, 각 모델링 단계에서 자신이 잘 알고 있는 부분에 좀 더 깊이 들어가는 오류를 범할 수 있습니다. 필자도 예전에는 DA 업무를 하기 전에 DBA 업무를 오랫동안 하면서 파티션, 인덱스 등 물리적인 것들과 친숙하다 보니 논리 모델링 단계에서도 머리속에는 테이블, PK, INDEX, PARTITION 을 어떻게 할 지 고민하는 오류를 범한 적이 있었습니다.
수평적인 사고와 균형 감각을 갖는 것은 데이터 모델링에 있어서 또 하나의 중요한 사고 방식인 것 같습니다.

마지막으로, 비지니스 관점에서 접근해라!

특히나 DA들은 IT전문 지식 뿐만 아니라 기본적으로 비지니스를 이해하는 것이 굉장히 중요합니다. 가령, 비지니스를 이해하지 못하고 IT 관점에서 SQL튜닝 기술만으로 DB 성능 개선 프로젝트를 진행하는 경우, 대부분은 자주 사용되는 SQL문 TOP-N, I/O를 많이 발생시키는 SQL문 TOP-N 을 선정해서 SQL문 튜닝 작업을 진행하고, 성능이 개선되고 DB CPU 점유율을 낮췄기 때문에 CPU 추가 시점을 늦출 수 있다는 부분을 강조합니다. 이러한 접근 방법도 비용 절감을 위해 필요하며 나쁘지는 않습니다.
하지만, 임원 분들이 더 필요로 하는 부분은 비지니스 관점에서 어떠한 가치를 줄 수 있냐는 겁니다. 동일한 일을 하더라도 잘 포장할 줄 아는 기술도 필요하다는 생각이 듭니다.
가령, 이동통신 개통업무에 관련된 SQL문을 개선했다고 가정합시다.
IT관점에서 "메모리 I/O인 consistents get 값을 800 -> 5 로 감소시켜서 5초 걸리던 SQL문을 1초 이내로 단축시켰다." 라는 표현 보다는 비지니스관점에서 "기존에는 한 대리점에서 하루에 100명 정도밖에 개통을 하지 못했는데, 개통업무와 관련된 SQL문을 개선하여 150명까지 개통이 가능하다".

동일한 SQL튜닝 업무를 수행했어도 표현하는 방식에 따라서, 비지니스관점에서 표현하는 방식이 리더나 임원 분들이 이해하기 쉽고, 중요한 가치를 줄 수 있다고 판단할 수 있게 됩니다.

이러한 사고 방식들은 갑자기 바꾸고 싶다고 해서 쉽게 바꿀 수 있는 게 아니기 때문에, 머리속에 상기시키고, 지속적인 훈련을 해보시기 바랍니다.

 

출처 :: DBGuide.net