개발하다 보면 종종 "쿼리가 x백줄이야" 같은 자랑 아닌 자랑을 듣곤 한다. 심지어는 만줄이 넘는 원쿼리도 봤었는데, 그게 정말 어쩔 수 없는 선택이었는지는 몰라도 유지보수 하는 입장이 되면 "이런 ㅆㅂ 어떤 ㅅㄲ가 이따위 ㅈ같은..." ☜ 이런말 나온다. (내가 그런건 아니고 옆 팀 사람이 갑자기 욕하길래 가서 보니 쿼리가 15,000여줄 이었더라는.)
SQL은 너무도 심플하다 보니(그래서 이름도 Simple Query Language다) 배우기는 쉬운데 조금 복잡한 조건이 생기면 상당한 삽질을 하게 만든다. for도 없고 if도 없다. (삽질로 구현할 수는 있다.) 에러가 발생해도 짧은 에러메시지와 코드만 던져줄 뿐이라 디버깅으로도 최악. 프로그래밍하기 편한 PLSQL 이라는 것도 있지만 이것 역시 SQL의 확장일 뿐이라 개발도, 디버깅도 썩 괜찮은 환경이 없다.
종종 DB 신봉자들이 "프로그램은 인터페이스하는 껍데기로만 사용하고 모든건 DB에서 처리하는게 낫다"고 말하는걸 듣는데, 나는 그 말에 100% 동의하지 않는다. 따지고 보면 프로그램도 DB에서 자료를 가져와 가공하므로, 아예 DB에서 원쿼리 혹은 최소쿼리로 처리하는게 더 퍼포먼스가 높을수는 있다. 하지만 문법오류 하나 제대로 잡아주지 못하는 허접한 환경에서 여러 테이블 JOIN이나 여러 SQL이 UNION으로 연결되고 온갖 SUBQUERY가 난무한 수백~수천줄의 쿼리에서 어떤 데이터가 오류인지 하나하나 분리해서 추적해가며 디버깅하는건 즐겁지 않은 일이다. 특히 오라클은 몇번째 데이터를 fetch하다가 오류가 발생한건지, 에러 데이타는 무엇인지 정확하게 알려주지 않는데다가 (fetch 중 break를 걸고 trace할 수 없어 데이터를 일일히 눈으로 검사하면서 찾아야 한다. 어떻게 편하게 할 방법 아시는분?), 에러위치마저 틀리게 알려주는 경향이 있어서 삽질을 가중시킨다. 다른 DB는 다뤄볼 기회가 없어 잘 모르겠지만, 오라클은 사용자로 하여금 무한한 삽질을 하게 만드는 능력이 있다.
퍼포먼스보다는 코드의 가독성, 유지보수성이 중요시 되는 추세에서 SQL, PLSQL에만 의존하는 것은 좋은 점수를 받기 어렵다.
그렇다면 그 반대는 어떨까?
현재 있는 회사의 시스템을 납품한 신X이라는 회사는, 구성원이 DB에 그리 뛰어나진 않았다. 물론 당시 재직중이었던 나도 마찬가지. PLSQL 문법은 거의 전무했으며 복잡한 쿼리는 JOIN이나 SUBQUERY, UNION이 고작이었다. 그래서 그 회사의 제품은 "DB는 ISAM CRUD(create, read, update, delete) 수준으로만 활용하고, 모든 것을 외부 프로그램(Cobol, Java 등)에서 해결"했다.
프로그램에 의존하게 되면 SQL/PLSQL보다 강력한 언어적 지원과 모듈별로 기능분리가 가능해져서 개발 및 디버깅이 비교적 수월해 지지만, 모듈간 넘나드는 변수가 복잡해지고 변수 값이 valid한지 늘 check하고 logging해야 한다. 또한 쿼리가 자잘하게 분리되어 있어 쿼리 비용도 많이 든다. (프로그램 위주로 구현할때 원쿼리는 재사용을 못하므로 각각의 서브쿼리들을 분리하는 편이 좋다.) 이런 것들이야 감수할 수 있지만 딱 한가지 심각한 문제는 바로 집계성 업무다. 집계성 업무는 많은 데이터를 가공해야 하는데 프로그램에서 일일히 FETCH 해서 가공하고 있다보면 응답시간 초과로 실시간 거래가 불가능한데다가 DB 부하도 심하다. 다행히 이런 업무는 그리 많지 않아서 배치로 만들어 하루 업무가 끝난 후 "2~3시간동안" 생성해서 다른 테이블에 결과를 INSERT 했다가 비실시간으로 참조하도록 되어 있다. 그리고 매일매일 아침저녁으로 데이터가 어긋나지 않았는지 검사하고 다시 만들어준다. (일찍 끝나더라도 집에 늦게 들어가는게 이것 때문임.)
그건 그렇고, 앞으로 목표는 집계성 업무를 손봐서 DB에도 일 좀 시키고 시간도 절약하고 자동화 하는 것. 최근 PLSQL 보고 있다. 어느 쪽에 의존하던 복잡하기는 마찬가지지만 최대한 줄여봐야지.
