SQL

저장한 데이터를 꺼내려면 원래는 어떻게 저장돼 있는지를 알아야 했습니다. 어느 파일의 몇 번째 줄부터 읽어 어떤 순서로 맞출지를 프로그램이 직접 지시했습니다. 이 방식에는 두 가지 대가가 붙습니다.

첫째는 저장 방식이 바뀔 때마다 꺼내는 코드를 전부 고쳐야 한다는 점입니다. 페이지덱에서 문서 표에 칸 하나를 더하는 일 때문에 조회 코드 열 곳을 같이 고친 적이 있습니다.

둘째는 성능이 사람의 판단에 달려 있다는 점입니다. 지난달에 가입한 회원 중 결제가 없는 사람을 뽑는 질문이 오면 태오가 회원 표를 먼저 읽고 결제 표를 맞추는 순서를 직접 정했습니다. 회원이 만 명일 때는 그 순서로 빨랐는데 백만 명이 되자 같은 코드가 몇 분을 썼습니다. 데이터가 늘면 유리한 순서가 바뀌는데, 코드에 순서를 박아 두었으니 사람이 다시 고르러 가야 했습니다.

이 언어가 뒤집은 것은 지시의 방향입니다. 어떻게 찾을지를 적는 대신 무엇을 원하는지만 적습니다. 지난달 가입자 중 결제 기록이 없는 사람을 달라고 쓰면, 어느 표를 먼저 읽고 어떤 방법으로 맞출지는 데이터베이스가 그때의 데이터 크기를 보고 고릅니다.

다섯 가지를 처리합니다.

1. 실행 방법을 위임합니다. 문장에는 원하는 결과만 적고, 데이터베이스가 자기 안의 통계를 보고 실행 계획을 세웁니다. 회원이 만 명에서 백만 명이 되어도 같은 문장을 그대로 쓰고, 유리한 순서가 바뀌면 데이터베이스가 알아서 바꿉니다.
2. 흩어진 표를 이어 읽습니다. 회원 정보와 결제 기록은 서로 다른 표에 있고 번호로만 연결돼 있는데, 이 둘을 붙여 한 결과로 받는 일이 한 문장에 들어갑니다. 행과 열로 데이터를 담는 테이블을 여러 개 놓고 쓰는 설계가 실용적인 이유가 여기에 있습니다.
3. 묶어 세는 일을 한 줄로 처리합니다. 플랜별 결제 건수와 합계 금액을 구하려면 프로그램에서는 반복문과 임시 변수가 필요한데, 여기서는 무엇으로 묶고 무엇을 셀지만 적습니다.
4. 제품이 달라도 통합니다. 표준이 정해져 있어서 데이터베이스 제품을 바꿔도 기본 문장은 대부분 그대로 씁니다. 다만 날짜 함수나 성능 설정처럼 제품마다 다른 부분이 남아 있어 옮길 때 손볼 것은 있습니다.
5. 사람이 읽을 수 있습니다. 문장이 영어 어순에 가까워서 개발자가 아닌 사람도 기본 형태는 며칠이면 익힙니다. 분석가를 거치지 않고 각자 데이터를 보는 셀프서브 분석 환경이 이 성질 위에 섭니다.

조심할 것도 있습니다. 같은 결과를 내는 문장이 여러 개이고 그 속도는 크게 다릅니다. 찾기를 빠르게 하려고 미리 만들어 둔 인덱스가 없는 칸으로 조건을 걸면 데이터베이스가 표 전체를 훑습니다. 무거운 질의를 고객이 쓰는 데이터베이스에서 그대로 돌리면 서비스가 함께 느려지므로, 집계는 복제해 둔 사본에서 돌립니다.

완전히 대신하는 것은 아직 없고, 자리를 나눠 쓰는 것이 셋입니다.

1. 객체 관계 매핑. 코드에서 데이터를 객체처럼 다루면 도구가 문장을 자동으로 만들어 줍니다. 한 건을 읽고 쓰는 일은 이쪽이 편하고 실수도 적습니다. 다만 표 네 개를 잇고 묶어 세는 질의는 도구가 만든 문장이 느려지는 일이 잦아서, 결국 문장을 직접 쓰게 됩니다.
2. 표 구조에 매이지 않는 NoSQL 계열의 질의 방식. 한 덩어리를 통째로 꺼내는 일에 맞고, 표를 잇는 일은 프로그램이 직접 합니다. 구조가 자주 바뀌는 데이터에 유리합니다.
3. 화면에서 끌어다 놓는 분석 도구. 사용자는 문장을 쓰지 않지만 도구가 내부에서 이 언어의 문장을 만들어 보냅니다. 대안이라기보다 껍데기입니다.

대안으로 보이지만 아닌 것도 있습니다. 자연어로 물으면 결과를 내주는 도구는 문장을 쓰는 수고를 줄여 주지만, 그 결과가 맞는지 확인하려면 만들어진 문장을 읽어야 합니다. 특히 조건이 겹칠 때 무엇을 제외했는지가 문장에만 적혀 있어서, 숫자를 보고할 사람은 여전히 읽을 줄 알아야 합니다.

고르는 기준은 데이터의 모양입니다. 표끼리 관계가 많고 묶어 세는 일이 잦으면 이 언어가 붙은 쪽이 유리하고, 기록마다 든 항목이 다르고 한 덩어리를 통째로 읽는 일이 대부분이면 다른 계열이 편합니다.

"그 숫자 쿼리 좀 공유해 주세요. 조건을 확인하고 싶어서요."

결과가 아니라 무엇을 세었는지를 문장으로 확인하자는 요청입니다.

"이거 인덱스 없이 돌려서 3분 걸리는 거예요."

문장 자체보다 데이터베이스 쪽 준비가 문제라는 진단입니다.

"집계는 사본에서 돌립시다. 운영에 걸면 같이 느려져요."

무거운 질의를 고객이 쓰는 쪽에서 돌리지 말자는 말입니다.

페이지덱에서는 태오가 자주 쓰는 질의를 저장해 두고 이름을 붙여 공유합니다. 같은 숫자를 두 사람이 다르게 세는 일을 막는 것이 목적입니다. 가입자 수를 세는 문장이 두 벌 돌아다니면 회의에서 숫자가 안 맞는 일이 생깁니다.

지현도 이 언어를 씁니다. 화면에서 고를 수 없는 조건을 확인해야 할 때 직접 써서 봅니다. 다만 쓰기를 바꾸는 문장은 권한에서 막아 두고 읽기만 열어 둡니다. 조회만 하려던 문장이 표 하나를 지우는 일은 실제로 일어납니다.

이 언어와 관계형 데이터베이스를 같은 말로 쓰는 경우가 많습니다. 거의 항상 함께 나오니 자연스러운 오해입니다. 하지만 하나는 언어이고 다른 하나는 데이터를 저장하고 꺼내 주는 시스템입니다. 같은 문장을 여러 제품이 받아 주고, 표 구조가 아닌 저장소에도 이 언어와 비슷한 문장을 받는 층이 붙어 있습니다. 둘을 한 덩어리로 알면 저장소를 바꿀 때 질의도 처음부터 다시 배워야 한다고 여기게 됩니다.

개발자만 쓰는 것이라고 보는 것도 흔합니다. 코드처럼 생겼으니 그렇게 보입니다. 그런데 조회만 하는 문장은 구조가 단순해서 며칠이면 익힙니다. 마케터가 캠페인별 가입자 수를 직접 세고 프로덕트 매니저가 화면에 없는 조건을 직접 확인하면, 질문 하나에 이틀씩 걸리던 왕복이 사라집니다. 막아야 하는 것은 배우는 일이 아니라 권한입니다.