테이블

데이터를 파일에 담아 두던 시절에는 모양을 만든 사람이 정했습니다. 회원 명단을 관리하는 파일이 부서마다 따로 있고, 한쪽은 이름과 연락처만 적어 두고 다른 쪽은 가입 경로까지 적어 두는 식이었습니다.

문제는 합칠 때 터졌습니다. 두 파일을 붙이면 같은 사람이 두 줄로 남는데, 한쪽에는 연락처가 있고 한쪽에는 없어서 어느 줄이 맞는지 알 수 없었습니다. 담당자가 자리를 비우면 그 파일의 두 번째 칸이 무슨 뜻인지 아무도 몰랐습니다. 값은 쌓였지만 쓸 수 있는 데이터는 아니었습니다.

테이블은 모양을 먼저 못 박고 값을 그 안에 붓는 방식입니다. 어떤 칸이 있는지를 미리 정해 두고 줄만 늘려 가니, 누가 넣었든 같은 자리에 같은 종류의 값이 들어갑니다. 그러면 합치는 일이 붙이는 일이 되고, 한 번 정한 모양이 곧 설명서 노릇을 합니다. 새로 온 사람도 열 이름만 훑으면 이 표가 무엇을 담는지 알 수 있어, 담당자의 기억에 기대지 않아도 됩니다.

열은 미리 정해 두고 행만 쌓아 올리는 구조입니다. 열은 항목 하나이고 행은 그 항목들을 채운 대상 하나입니다. 회원 표라면 이름·이메일·가입일이 열이고, 회원 한 명이 한 행입니다.

다루는 순서는 넷입니다.

1. 열을 정합니다. 무엇을 담을지와 어떤 종류의 값이 들어갈지를 함께 정합니다. 이름은 글자, 가입일은 날짜, 조회수는 정수입니다. 이 정의를 모아 적어 둔 것이 스키마입니다.
2. 행을 넣습니다. 회원이 가입할 때마다 한 줄이 늘어납니다. 열은 그대로 있고 줄만 200만 개까지 늘어납니다.
3. 행 하나를 집습니다. 동명이인이 있어 이름으로는 못 집으므로 겹치지 않는 번호를 따로 두는데, 이 열이 기본 키입니다.
4. 표끼리 잇습니다. 문서 표에 작성자 번호를 적고 그 칸을 회원 표의 기본 키에 걸어 두면 됩니다. 이렇게 거는 칸이 외래 키입니다.

한 표에 다 담지 않고 쪼개는 데는 이유가 있습니다. 회원 한 명이 문서를 300개 쓴다면 회원 표에 문서를 담을 자리가 없습니다. 담으려면 문서1·문서2 같은 칸을 300개 만들어야 하고, 301번째 문서에서 다시 막힙니다. 그래서 문서는 문서 표로 빼고 작성자 번호로 잇습니다. 하나에 여럿이 달리는 관계는 전부 이렇게 풉니다. 표가 늘어나는 것을 손해로 볼 필요는 없습니다. 표 하나가 맡는 일이 좁아질수록 그 표를 읽는 조회도 단순해집니다.

같은 사실을 두 군데 적지 않으려고 표를 더 잘게 나누는 설계가 정규화이고, 속도를 위해 일부러 중복을 남기는 설계가 비정규화입니다. 표를 몇 개로 가를지는 이 둘 사이에서 정합니다.

테이블이라는 말이 실제로 오가는 자리는 셋입니다.

1. 조회 — SQL로 데이터를 꺼낼 때 어느 표에서 꺼낼지부터 적습니다. 대시보드 숫자 하나가 표 서너 개를 맞춰 나온 값인 경우가 흔해서, 숫자가 이상하면 어느 표를 맞췄는지부터 되짚습니다. 같은 이름의 칸이 두 표에 있으면 어느 쪽을 쓴 값인지도 함께 확인합니다.
2. 설계 — 새 기능을 만들 때 표를 더 만들지 기존 표에 칸을 더할지 정합니다. 즐겨찾기 기능이라면 문서 표에 칸을 더하는 안과 즐겨찾기 표를 새로 만드는 안이 갈립니다. 기준은 그 값이 대상마다 하나씩인지, 아니면 대상 하나에 여럿이 달릴 수 있는지입니다.
3. 성능 — 표가 커지면 읽는 속도가 문제 됩니다. 인덱스는 특정 값을 빨리 찾으려고 미리 정렬해 둔 자료인데, 어느 표의 어느 열에 걸지가 그때의 논의거리입니다.

ORM을 쓰면 표가 코드에서는 객체로 보입니다. 문서 표의 한 행이 코드에서는 문서 하나에 해당하는 식입니다. 편한 대신 지금 다루는 것이 몇 개 표에 걸친 일인지가 가려져서, 화면이 느릴 때는 실제로 어느 표를 얼마나 읽었는지 확인해야 합니다.

"그 값 어느 테이블에 있어요?"

데이터가 저장되긴 하는지, 된다면 어디서 꺼내야 하는지를 묻는 말입니다.

"회원 테이블에 칸 하나만 더 붙이면 되지 않나요?"

가장 싸 보이는 안을 꺼낸 것이고, 보통 그 칸이 회원마다 하나씩인지 여럿인지를 되묻는 대화로 이어집니다.

"테이블 새로 파야 할 것 같은데요."

기존 구조에 끼워 넣을 자리가 없어서 표를 하나 더 만들어야 한다는 뜻입니다.

페이지덱에 문서 즐겨찾기를 붙일 때 이 대화가 그대로 오갔습니다. 지현은 문서 표에 즐겨찾기 칸을 하나 두면 되겠다고 생각했지만, 태오가 그러면 한 문서를 누가 즐겨찾기했는지 구분할 수 없다고 답했습니다. 즐겨찾기는 문서의 성질이 아니라 회원과 문서 사이에 생기는 관계이기 때문입니다.

결론은 회원 번호와 문서 번호를 한 줄에 적는 표를 따로 만드는 것이었습니다. 한 사람이 문서 50개를 즐겨찾기하면 50줄이 쌓이고, 해제하면 그 줄을 지웁니다. 이 모양으로 두면 "내가 즐겨찾기한 문서" 와 "이 문서를 즐겨찾기한 사람" 을 같은 표에서 양방향으로 꺼낼 수 있습니다.

테이블을 엑셀 시트와 같은 것으로 여기기 쉽습니다. 화면에 행과 열로 보이는 모양이 정말 비슷하니 그럴 만합니다. 다른 점은 규칙이 어디에 있느냐입니다. 시트는 날짜 칸에 글자를 넣어도 받아 주지만 테이블은 거부합니다. 시트는 한 사람이 열어 고치는 동안 다른 사람의 수정이 덮이지만, 테이블은 수백 명이 동시에 써도 각자의 줄이 남습니다. 시트 감각으로 표를 설계하면 칸을 자유롭게 늘리고 값도 섞어 넣게 되고, 몇 달 뒤 그 표에서는 어떤 집계도 믿을 수 없게 됩니다.

칸 하나 더 붙이는 일이 공짜라는 생각도 흔합니다. 스키마에서 한 줄이고 화면에서 입력란 하나라서 작아 보입니다. 하지만 이미 쌓인 200만 줄의 그 칸을 무엇으로 채울지 정해야 하고, 그 칸을 읽는 코드와 화면이 전부 딸려 옵니다. 회원마다 값이 여럿일 수 있는 항목을 칸으로 붙여 버리면 나중에 표로 쪼개는 훨씬 큰 작업이 기다립니다.