스키마는 빈 양식이지, 그 양식에 적히는 답이 아니에요. 데이터가 반드시 맞춰야 하는 모양을 미리 정해놓은 거예요.
칸마다 이름이 붙어 있고 모양이 제각각인 인쇄된 주문서를 상상해보세요. 동그란 칸, 네모 칸, 숫자만 받는 칸. 양식은 비어 있어요. 아직 주문이 하나도 담기지 않은 상태죠. 이 양식이 하는 일은 유효한 주문이 어떤 모습이어야 하는지 정의하는 거예요. 이 항목은 필수고, 저 항목은 반드시 숫자여야 하고, 이 항목은 예 또는 아니오만 허용해요. 동그란 칸에 별 모양 답을 쑤셔 넣으면 양식이 튕겨내요. 모양이 안 맞으니까요.
스키마가 바로 그거예요. 데이터가 따라야 하는 합의된 구조. 어떤 필드가 존재하고, 각각이 어떤 종류인지(텍스트, 숫자, 날짜, 참 또는 거짓), 무엇이 필수이고 무엇을 비워둘 수 있는지를 정해요.
데이터베이스와 나란히 놓고 보면: 스키마는 그 거대한 스프레드시트의 열 이름과 그 뒤에 있는 규칙이에요. "고객 행마다 이메일이 있어야 하고 텍스트여야 해요. 가입일이 있어야 하고 실제 날짜여야 해요. '언젠가' 같은 말은 안 돼요." 스키마는 스프레드시트 모양에 대한 규칙집이에요. 데이터는 그 안에 부어 넣는 것이고요.
스키마가 하루를 투자할 가치가 있는 이유: 구조가 있어야 소프트웨어가 자기 데이터를 믿을 수 있어요. 모든 주문의 "합계" 칸에 진짜 숫자가 보장된다면, 코드는 천 개의 합계를 일일이 확인하지 않고 한 번에 더할 수 있거든요. 스키마는 모양이 유지된다는 약속이에요. 약속이 깨지면, 필드가 빠지거나 숫자 자리에 텍스트가 들어오면, 튕겨나요.
이 말이 나오는 상황:
- "그거 스키마가 어떻게 돼?"는 "그 데이터 모양이 어때요? 필드가 뭐고 타입이 뭐예요?"라는 뜻이에요.
- "스키마를 바꿨어"는 "양식 자체를 바꿨다"는 말이에요. 칸을 추가하거나 어떤 항목을 필수로 만든 거죠. 항목 하나를 수정하는 것보다 훨씬 큰 변경이에요. 기존 레코드 전체가 새 양식에 맞아야 하니까요.
AI 관점에서 보면: 다른 도구가 소화할 수 있는 데이터를 AI가 반환하게 하려면, 스키마를 먼저 줘요. "정확히 이 모양으로 답해라." 이렇게 해야 AI가 필요한 건 채워진 양식인데 친근한 단락 글을 써오는 일을 막을 수 있어요.
스키마는 빈 양식이에요. 데이터는 그 답이고요. 모양을 먼저 정해두면, 그 아래 모든 것이 그 모양을 믿을 수 있어요.