SQL의 길이에 따른 분석시간

언제부터인가 복잡한 업무의 배치작업에 한방 SQL이 유행하기 시작했다. 좋은 현상이다. 하지만 이제 정도가 지나친 SQL들이 가끔 눈에 뛴다. 한방 SQL을 사용하지 말아야 할 때와 사용해야 할 때를 구분할 줄 알아야 한다. SQL이 어느 정도 길어지면 PL/SQL 이나 PRO*C 등을 이용하여 절차형으로 바꾸어야 한다. 이렇게 하더라도 Bulk CollectFor all 등으로 처리하거나 배열처리를 병행한다면 만족할 만한 속도를 낼 수 있다..

 

아래는 SQL의 길이와 SQL을 전체적으로 이해하는데 걸리는 시간을 조합한 그래프이다.

사용자 삽입 이미지

SQL이 길어지면 이해하기 힘들어

이 그래프를 본다면 SQL을 길게 작성하는 것이 얼마나 위험한지 알 수 있다. SQL의 길이가 짧으면 짧을수록 그것을 이해하는 데 걸리는 시간은 얼마 되지 않음을 알 수 있다. 반대로 SQL의 길이가 길수록 이해하는 데 걸리는 시간은 무한대로 늘어난다. 누구도 위의 그래프에 예외일 수 없다.

만약 여러분이 업무 인수인계를 받는 입장인데 SQL 하나가 A4 용지 기준으로 40페이지 라면? 아마 인수인계 받는데 한달이 걸려도 전체 SQL을 이해하기 힘들 것이다. 하지만 1페이지짜리 SQL 40개 라면 웃으며 차근 차근 인수인계를 받을 수 있다. 하루에 SQL 3~4개 혹은 그 이상도 인수인계 받을 수 있다. 하루에 4개씩 인수 인계 받는다면 10일 이면 인수 인계가 끝난다. 40 페이지나 되는 한방 Query는 유지보수 하기가 대단히 어려움을 알아야 한다.

 

이제 위의 그래프에 근거하여 한방 SQL을 사용해도 되는 경우와 사용하지 말아야 할 경우를 구분해 보자.

 

한방 SQL을 사용해도 되는 경우

첫 번째, SQLA4 용지 기준으로 4페이지 이하인 경우.

4페이지라고 한 것은 꼭 정해진 것은 아니다. 하지만 유지보수의 관점에서 가독성이 좋아야 한다. 4페이지면 조금 길어서 가독성이 낮아진다고 생각할 수 있지만 필자의 경우 SQL을 출력할 때 한 면에 인쇄할 페이지 수를 2로 설정하면 2페이지만 보면 전체 SQL이 출력 되므로 4페이지 까지는 조금만 노력해도 분석이 용이했다. 하지만 한면에 인쇄할 페이지 수를 4로 하자 글자가 너무 작아져서 볼 수 없는 수준이었다. 필자의 경우 기준은 4페이지 이지만 개인에 따라 기준은 2페이지 일 수도 있고 6페이지 일 수도 있다. 하지만 아무리 SQL에 능통한 사람도 SQL의 길이가 A4 용지 기준으로 8페이지 이상이 된다면 분석시간이 급속도로 늘어날 것이다..

 

두 번째, SQL5페이지가 넘어 가더라도 Union 혹은 Minus 등으로 명확히 구분되거나 누가 보더라도 이해가 빠른 SQL인 경우.

이 경우는 5페이지가 넘어가지만 빠른 시간에 분석할 수 있으므로 5페이지가 넘어 가더라도 유지보수가 용이하다. 하지만 이 경우에도 8페이지가 넘어간다면 고민해야 한다.

 

세 번째, SQL5페이지가 넘어 가고 업무의 변경이 있더라도 SQL을 변경하는 것이 아니라 SQL을 새로 작성하기로 합의하거나 혹은 이러한 정책이 수립된 경우.

이 경우는 SQL을 수정할 일이 없으므로 길어도 상관없다. 하지만 SQL을 새로 작성하는 사람이 모델과 업무를 잘 알고 있고 튜닝을 할 줄 알아야 고품질의 SQL을 작성할 수 있다.

 

네 번째, 유지보수의 중요성 보다 성능이 더 중요한 경우.

대용량의 복잡한 업무를 처리하는데 일주일이 넘어간다면 견딜 수 없을 것이다. 예를 들면 요금청구 작업의 성능은 기업의 흥망을 좌우할 수 있다. 이런 경우는 유지보수를 희생하더라도 한방 Query를 사용할 수 있다.

 

다섯 번째, SQL5페이지가 넘어 가지만 업무의 변경이 전혀 없어 SQL을 수정 할 일이 없는 경우.

유지보수를 할 필요가 없는 경우이다. 하지만 이런 상황은 아주 예외적인 경우일 것이다.

 

위의 5가지 경우가 아니라면 한방 SQL을 작성해서는 안 된다.

한방 Query와 관련한 유명한 일화

HR(인적자원 관리) 프로젝트에서 급여를 계산하는 프로그램을 한방 SQL로 개발하였고 40페이지가 넘는다고 했다. 급여계산은 한방 Query의 성능이 빨라 Open을 성공적으로 했다고 한다. 하지만 문제는 Open2년 뒤에 찾아왔다. 업무가 변경되어 급여계산의 SQL을 수정해야 하는데 아무도 SQL을 수정할 수 있는 사람이 없었다. 조직내부에서 몇 주간 고민해 보았으나 결국 분석을 포기하고 원작자를 불렀다.  

 

핵심은 이렇다. 돈을 많이 쳐줄 테니 SQL을 고쳐달라는 것이었다. 하지만 누가 그랬던가? 사람은 망각의 동물이라고...... 결국 원작자도 2년이 지난 이상 40페이지가 넘는 SQL을 외우고 다닐 수는 없는 노릇이 아닌가? 그는 분석을 포기하였다고 한다. 아래는 원작자가 분석을 포기한 이유이다.

 

원작자: 돈을 아무리 준다고 해도 그 기간 내에는 할 수가 없습니다. 인라인 뷰가 80개가 넘는데 분석하는 데만 2~3달 걸릴 것 같습니다.

요청자:  두달 안에 변경된 업무를 반영해야 하는데 큰일 났네....

 

결국 원작자는 돌려보내고 급여 담당자가 프로그램을 절차형으로 모두 새로 작성했다고 한다. 새로 작성하는데 꼬박 한달이 걸렸다고 한다. 위의 원작자는 분석하는데만 두 달이 넘는다고 하였다. 하지만 급여담당자는 한달안에 모든 프로그램이 작성 완료되었음을 주목하라. 담당자는 한방 Query 보다 성능은 떨어졌지만 상관이 없다고 하였다. 아래는 급여 담당자의 이야기이다.

 

급여 담당자: 급여 배치가 30분 정도 결렸는데 절차형으로 바꾸니 두 시간이 걸리네요. 하지만 상관 없습니다. 오늘 저녁에 급여 배치를 돌리고 내일 급여가 지급되기 때문에 내일 오후 1시까지 배치가 끝나면 됩니다.

원작자는 유지보수의 중요성을 무시한채 Critical 하지도 않은 성능만 고려한 것이다. 아무리 좋은것 이라도 지나치면 괴로워진다. 이제는 한방 Query를 남발하지 않았으면 한다.


Posted by extremedb

댓글을 달아 주세요

  1. feelie 2010.02.19 17:21  댓글주소  수정/삭제  댓글쓰기

    잘봤습니다...

  2. Favicon of https://blog.hyeonsig.ml BlogIcon 천사마음 2010.02.19 17:35 신고  댓글주소  수정/삭제  댓글쓰기

    좋은 정보 고맙습니다. 앞으로 자주 찾아뵐께요.
    좋은 글 많이 부탁드립니다.

  3. Favicon of http://smallhuman.egloos.com BlogIcon 긁적 2010.02.19 21:11  댓글주소  수정/삭제  댓글쓰기

    오오.... 모든 프로그래머가 명심해야 할 만한 내용입니다.
    잘 읽었습니다. ^^

  4. baind 2010.02.21 01:55  댓글주소  수정/삭제  댓글쓰기

    와..한방SQL버전...무조건 좋은 것 만도 아니군요!
    정말로...잘봤습니다.
    감사합니다~~

  5. 혈기린 2010.02.22 10:36  댓글주소  수정/삭제  댓글쓰기

    예전 엔코아에서모델링 교육들을때 강사가 했던말이 기억나는군요 자기는 자기가100점이라고 생각한 모델이 최고인줄 알았는데 그모델을 인수받는 고객이 그모델을 이해못하면 50점짜리가 된다 인수받는 고객을 자기수준으로 끌어올리지 못하면 그 고객이 이해할수 있는 100점짜리 모델을 만들어야 한다고 했는데 비슷한 맥락일까요 ㅎㅎ
    어김없이 좋은글로 한주를 시작하네요 감사드려요 ^^

  6. Favicon of http://oraclepro.pe.kr BlogIcon davidkim 2010.02.22 13:45  댓글주소  수정/삭제  댓글쓰기

    한번쯤 생각해보게 만드는 글인것 같습니다.
    매번 좋은 글 잘 읽고 갑니다. 행복한 한주가 되시길~ ^^

    • Favicon of https://scidb.tistory.com BlogIcon extremedb 2010.02.22 19:06 신고  댓글주소  수정/삭제

      반갑습니다.
      사실 이 문제로 사람들이 고통받고 있지만 One Query가 대세처럼 되어있기 때문에 말도 못꺼내는 사람들이 지금도 있습니다.^^

  7. Favicon of http://www.soqool.com BlogIcon 쏘쿨 2010.02.22 15:43  댓글주소  수정/삭제  댓글쓰기

    한가지 질문을 할까 합니다.
    위에 올리신 'SQL길이에 따른 분석시간' 그래프는 어떻게 얻어진 건가요?
    그래프를 만들기 위해 사용된 통계치나 혹은 수식을 가지고 계신가요?
    알려주신다면 원글을 이해하는데 더 많은 도움이 될듯 합니다.

    • Favicon of https://scidb.tistory.com BlogIcon extremedb 2010.02.22 15:53 신고  댓글주소  수정/삭제

      X 와 Y 축에 대한 방정식은 가지고 있지 않습니다.
      통계는 가지고 있습니다. 통계는 SQL 분석에 일주일 이상 걸리거나 분석에 실패한 것들을 모아서 공통점을 분석한 것입니다.
      하지만 공개하지는 않습니다.
      그 소스로 저희 회사에서 DBA나 개발자들의 약한 부분에 대해서 책도 쓰고 교육도 하므로 일종의 밥줄(대외비) 입니다.
      양해해 주시기 바랍니다.
      지금부터 쏘쿨님께서 분석시간에 대한 통계를 내어본다면 같은 결과를 얻을수 있을 것 입니다.
      만약에 이글에 대해 반대의견을 가지고 계시다면 무엇 때문인지 말씀해 주시기 바랍니다.

  8. Favicon of http://www.soqool.com BlogIcon 쏘쿨 2010.02.22 15:53  댓글주소  수정/삭제  댓글쓰기

    답변 감사합니다.

  9. 로또 2010.05.15 19:22  댓글주소  수정/삭제  댓글쓰기

    매우 좋은 내용이고, 글 전체의 취지에 적극 동감합니다.
    이런거 신경쓰는 사람이 의외로 드문데 중요한걸 지적해주셨습니다.

    헌데, 한방으로 해도 된다고하신 다섯번째는
    끝부분에 소개하신 일화와 약간 다르네요.

    지금으로 봐선 업무변경이 없을것 같아 보이지만
    정말로 미래에 변경이 있을지 없을지는 노스트라다무스가 오면 모를까,
    당장 눈앞에 얻는것보다 미래에 잃을것이 더 많을듯합니다.
    그래서 변경될 가능성이 없더라도 가독성은 항상 중요하다고 보여집니다.

    원 저작자도 분석을 포기했다는건 많은걸 시사합니다.
    전에 decode 한개만 한페이지가 넘어가는걸 봤는데 개발했던 담당자도 이해를 못한다고 합니다. ㅎㅎ
    (select 절의 많은 컬럼중 decode 한개만 한페이지씩)

  10. KIDO 2011.08.18 15:03  댓글주소  수정/삭제  댓글쓰기

    네 공감이 가는 글입니다.

    역시 맹신은 위험한 생각 방식임을 다시한번 깨닫게 됩니다.

    적시 적소 라는 말이 생각이 나네요 `^^

    감사합니다.