스키마

데이터를 아무 규칙 없이 쌓으면 넣을 때는 편하고 꺼낼 때 무너집니다. 같은 뜻의 값이 제각각 들어가기 때문입니다.

가입일을 예로 들면 어떤 줄에는 2026-03-01 이 들어가고 어떤 줄에는 3/1 이 들어가며 어떤 줄은 아예 비어 있습니다. 넣는 화면이 셋이고 만든 사람이 다르면 이런 일이 생깁니다. 한동안은 아무도 모릅니다. 문제는 석 달 뒤 "1분기에 가입한 사람이 몇 명이냐" 는 질문이 왔을 때 드러납니다. 날짜끼리 비교가 안 되니 답을 못 내고, 뒤늦게 200만 줄을 손으로 맞춰야 합니다.

스키마는 이 사고를 넣는 시점에 막으려고 씁니다. 가입일 칸에는 날짜만 들어갈 수 있다고 미리 적어 두면, 규칙에 어긋난 값은 저장 자체가 거부됩니다. 사람이 조심하는 대신 데이터베이스가 문지기를 맡는 구조이고, 덕분에 어떤 화면을 거쳐 들어와도 같은 모양으로 쌓입니다. 규칙을 문서로만 공유하면 새로 온 사람이 그 문서를 못 보는 순간 깨지지만, 스키마에 적어 두면 문서를 못 봐도 어긋난 값이 들어가지 못합니다.

스키마에 적히는 것은 네 가지입니다.

1. 표 — 무엇을 담는 테이블이 몇 개 있는지입니다. 테이블은 행과 열로 데이터를 담는 저장 단위이고, 협업 문서 서비스라면 회원 표, 문서 표, 팀 표 같은 것이 여기 들어갑니다.
2. 열과 자료형 — 표마다 어떤 칸이 있고 칸에 어떤 종류의 값이 들어갈 수 있는지입니다. 이름은 글자, 가입일은 날짜, 조회수는 정수로 정합니다. 글자 칸은 길이도 함께 정해 두어 제목에 소설 한 편이 들어오는 일을 막습니다.
3. 제약 — 칸에 걸어 두는 규칙입니다. 빈칸을 허용하지 않을지, 같은 값이 두 번 들어오는 것을 막을지, 값을 안 주면 무엇으로 채울지를 정합니다. 이메일 칸에 중복 금지를 걸면 같은 주소로 두 번 가입하는 일이 데이터베이스 선에서 막힙니다.
4. 관계 — 표끼리 어떻게 이어지는지입니다. 기본 키는 행 하나를 고유하게 가리키는 열이고, 외래 키는 다른 표의 행을 가리키는 열입니다. 문서 표의 작성자 칸을 회원 표의 기본 키에 걸어 두면 존재하지 않는 회원의 문서가 만들어지지 않습니다.

여기에 설계 방향이 얹힙니다. 정규화는 같은 사실이 두 군데 적히지 않도록 표를 쪼개는 방식이고, 비정규화는 속도를 위해 일부러 중복을 허용하는 방식입니다. 팀 이름을 문서 줄마다 적을지 팀 표에 한 번만 두고 번호로 가리킬지가 이 선택입니다. 조회를 빠르게 하려고 거는 인덱스도 보통 스키마와 같은 자리에서 함께 관리합니다. 어느 쪽을 택하든 설계도에 적히는 형태는 같아서, 표와 칸과 규칙을 읽으면 그 팀이 무엇을 우선했는지가 드러납니다.

쓰는 사람은 대체로 백엔드 개발자입니다. 기능을 만들기 전에 어떤 데이터를 어떤 모양으로 담을지 먼저 정하고, 그 내용을 코드 저장소 안의 파일로 남깁니다. 화면을 먼저 그리고 데이터를 나중에 끼워 맞추면 칸이 부족하거나 남는 상태로 굳어져서, 순서를 이렇게 잡습니다.

읽는 사람은 그보다 넓습니다.

1. 다른 개발자 — 어떤 칸이 있는지 알아야 조회문을 씁니다. SQL은 관계형 데이터베이스에 무엇을 원하는지 적어 보내는 표준 언어인데, 칸 이름과 자료형을 모르면 문장을 시작할 수 없습니다. ORM을 쓰는 팀은 코드 안의 선언이 곧 스키마 역할을 하기도 합니다.
2. 데이터 분석가 — 지표를 뽑으려면 어떤 칸에 무엇이 들어 있는지부터 확인합니다. 상태 칸에 들어갈 수 있는 값이 다섯 가지라는 사실을 모르면 활성 사용자 수를 잘못 셉니다.
3. 기획자 — 기능을 제안하기 전에 지금 쌓이는 데이터로 그것이 가능한지 봅니다. 마지막 접속 시각을 안 쌓고 있다면 휴면 안내 기능은 데이터를 쌓기 시작한 뒤에야 만들 수 있습니다.

한번 정한 스키마를 바꿀 때는 마이그레이션을 씁니다. 구조를 옮기는 작업이고, 코드 배포와 달리 이미 쌓인 데이터를 어떻게 처리할지까지 함께 정해야 합니다. 칸을 새로 더하면 기존 200만 줄의 그 칸을 무엇으로 채울지 답해야 합니다.

"이 기능 스키마부터 보고 얘기하죠."

화면이나 로직을 논하기 전에 데이터가 어떤 모양으로 쌓이는지 먼저 맞추자는 뜻입니다.

"그 값 스키마에 없어요. 칸을 새로 만들어야 합니다."

지금 구조로는 저장할 자리가 없으니 마이그레이션이 필요하다는 말입니다.

"스키마상으로는 한 회원이 팀 여러 개에 속할 수 있어요."

설계도에 적힌 관계가 그렇다는 뜻이고, 화면이 아직 그걸 못 보여 주더라도 데이터는 이미 감당한다는 의미입니다.

페이지덱이 기업 고객을 받기로 했을 때 첫 회의 주제가 스키마였습니다. 그때까지 회원 한 명은 팀 하나에만 속했는데, 기업 고객은 한 사람이 부서 여러 곳을 오갑니다. 태오는 회원 표에 팀 번호 칸을 두는 대신 회원과 팀을 잇는 표를 따로 만드는 안을 냈습니다.

지현이 물은 것은 기존 12만 명이었습니다. 새 표로 옮기는 동안 서비스를 멈출지, 옛 칸과 새 표를 한동안 같이 두고 천천히 옮길지가 그 자리의 결정이었습니다. 스키마 회의가 일정 회의로 이어지는 이유가 여기 있습니다. 구조를 바꾸는 비용은 대부분 이미 쌓인 데이터에서 나옵니다.

스키마를 개발자끼리 보는 내부 문서로 여기는 경우가 많습니다. 파일이 코드 저장소 안에 있고 읽으려면 표기법을 알아야 하니 자연스러운 오해입니다. 하지만 지표의 정의가 사실상 여기 붙어 있습니다. 활성 사용자를 어떻게 세는지는 상태 칸에 어떤 값이 들어가느냐로 결정되고, 그 칸을 모르는 채 합의한 지표는 뽑을 때 말이 달라집니다. 기획과 분석이 스키마를 안 보면 같은 단어를 서로 다른 뜻으로 쓰는 상태가 오래갑니다.

반대로 한번 정하면 바꾸기 어렵다는 이유로 처음부터 모든 경우를 담으려는 경우도 있습니다. 나중에 쓸지 모를 칸을 스무 개 만들어 두면 대부분 비어 있는 채로 남고, 그 칸이 무엇이었는지 아는 사람이 회사를 떠나면 지우지도 못합니다. 지금 필요한 것만 담고 필요해질 때 마이그레이션으로 더하는 편이 관리하기 쉽습니다.