쉬운 설명
데이터를 다루다 보면 같은 정보를 부르는 이름이 시스템마다 다르거나, 어떤 필드가 비어 있을 수도 아닐 수도 있는 상황이 흔합니다. 스키마는 '이 데이터는 이렇게 생겨야 한다'를 명문화해, 모두가 같은 모양으로 일하도록 만드는 약속입니다.
왜 필요한가는 단순합니다. 스키마가 없으면 같은 'user_id'가 어떤 시스템에선 숫자, 어떤 시스템에선 문자열, 어떤 시스템에선 비어 있을 수도 있고, 같은 'amount'가 원·달러·센트 단위로 섞이기도 합니다. 이런 불일치를 사람이 매번 코드로 막으려면 시간과 버그가 폭증합니다.
스키마는 여러 곳에 존재합니다. ① 데이터베이스 스키마(테이블·컬럼·관계), ② API 응답 스키마(JSON Schema·OpenAPI), ③ 메시지 스키마(Avro·Protobuf), ④ 폼 입력 스키마. 형태는 달라도 역할은 같습니다 — '예상 가능한 모양으로 들어오고 나가게 한다.'
장기적으로 가장 중요한 사실은 '스키마는 변한다'는 점입니다. 처음부터 완벽한 스키마는 없고, 시간이 지나며 필드가 늘고 줄고 바뀝니다. 그래서 스키마 진화(schema evolution) — 이전 버전과 호환되게 바꾸는 방법 — 가 실무의 큰 화두입니다. 새 필드 추가는 보통 안전하지만, 기존 필드 삭제·이름 변경은 다른 시스템을 깨뜨릴 수 있어 단계적으로 처리합니다.
스키마를 잘 다루는 도구·문화가 있습니다. Avro·Protobuf는 메시지에 버전이 들어가 자동 호환 검증을 합니다. dbt는 데이터 웨어하우스 안의 스키마를 코드로 관리합니다. GraphQL은 API 스키마가 곧 문서가 됩니다. 어떤 형태든 '스키마가 코드처럼 관리된다'가 핵심입니다.
비유로 보면
스키마는 종이 양식(폼)과 비슷합니다. '이름(필수), 생년월일(yyyy-mm-dd), 연락처' 같이 칸이 정해져 있어 누가 작성해도 같은 모양으로 들어옵니다. 양식이 없으면 사람마다 다른 방식으로 적고, 그걸 모아 합치는 일에 엄청난 시간이 들어갑니다.
어디에서 만나나
관계형 DB의 모든 테이블, REST·GraphQL·gRPC API의 입출력, 카프카 같은 이벤트 스트림의 메시지, 사용자 입력 폼, 머신러닝 학습 데이터의 컬럼. 데이터가 시스템 경계를 넘는 모든 자리에 어떤 형태로든 스키마가 필요합니다.
작은 예시
회원 가입 API의 요청 본문이 '이름(필수, 문자열), 이메일(필수, 이메일 형식), 생년월일(선택, ISO 날짜)'라고 정해져 있다면, 그게 그 API의 스키마입니다. 다른 팀이 그 API를 쓸 때 이 스키마만 보면 어떻게 호출해야 할지가 명확해집니다.
자주 하는 오해
한 줄 정리
좋은 스키마는 '오늘의 요구'뿐 아니라 '내년에 어떻게 바뀔지'까지 고려합니다. 후속 변경을 안전하게 만드는 일이 결국 가장 중요한 설계 결정입니다.