스키마
한 줄 정의
이 정보는 이런 모양이어야 한다고 미리 정해놓은 약속된 틀
1. 비유로 이해하기
학교에서 나눠 주는 신청서 양식을 떠올리면 된다.
이름: (글자로 쓰기)
나이: (숫자로 쓰기)
참가 여부: (예 / 아니오 중 하나만)
이 빈칸 양식이 바로 스키마다. 종이 자체는 내용이 아니라 “어떻게 채워야 하는지 알려주는 안내판”이다. 나이 칸에 “코끼리”라고 쓰면 잘못 채운 것이고, 안내판은 그걸 걸러내라고 있는 것이다.
여기서 한 가지만 기억하면 된다. 스키마는 빈 양식이고, 데이터는 채워진 종이다. 이 둘을 구분하는 순간 나머지는 다 따라온다.
2. 왜 필요한가
데이터베이스에서
표를 만들 때 “이 표에는 어떤 칸이 있고, 각 칸에는 무엇이 들어가는가”를 먼저 정해야 한다. 그게 CREATE TABLE이고, 그 결과물이 스키마다.
CREATE TABLE memory (
id INTEGER PRIMARY KEY, -- 번호. 자동으로 붙는 고유값
user TEXT, -- 사용자 이름. 글자
fact TEXT -- 기억할 내용. 글자
);
미리 정해 두는 덕분에, 나이 칸에 “코끼리”를 넣으려는 시도를 저장되기 전에 막을 수 있다.
에이전트가 도구를 쓸 때
에이전트는 도구(tool)를 골라서 사용한다. 그런데 AI가 “날씨 알려주는 도구를 써야지”라고 마음먹어도, 그 도구에 뭘 넣어줘야 하는지 모르면 아무것도 못 한다.
그래서 도구마다 스키마를 함께 알려준다. 이걸 입력 스키마(input schema)라고 하고, JSON Schema라는 형식으로 쓴다.
{
"name": "get_weather",
"description": "특정 도시의 날씨를 알려줍니다",
"input_schema": {
"type": "object",
"properties": {
"city": { "type": "string", "description": "도시 이름" },
"unit": { "type": "string", "enum": ["섭씨", "화씨"] }
},
"required": ["city"]
}
}
읽어 보면 이런 뜻이다.
properties— 채울 수 있는 칸의 목록type: string— 이 칸은 글자로 채운다enum— 이 중에서만 골라야 한다 (섭씨 아니면 화씨, 다른 건 안 됨)required— 도시 이름은 반드시 있어야 하고, 단위는 없어도 된다
사용자가 “부산 날씨 어때?”라고 물으면 에이전트는 이 틀에 맞춰 {"city": "부산"}을 만들어 도구를 호출한다.
정리하면 스키마는 세 가지 역할을 한다.
| 역할 | 하는 일 |
|---|---|
| 설명서 | AI에게 “이 도구는 도시 이름과 단위가 필요하다”고 알려준다 |
| 검사관 | 이상한 값이 들어오면 실행 전에 걸러낸다 |
| 번역기 | AI가 내놓은 말을 프로그램이 알아들을 깔끔한 데이터로 바꿔 준다 |
3. 어디서 만났나
두 번에 걸쳐 만났다.
6회차에서 데이터베이스를 배우며 CREATE TABLE로 표의 모양을 먼저 정하는 자리에서 처음 나왔다.
6회차 — 데이터베이스, 서비스의 기억을 어디에 어떤 모양으로 둘까
7회차에서는 같은 개념이 전혀 다른 자리에서 다시 나왔다. MCP 서버가 에이전트에게 “내 도구는 이렇게 생겼다”고 알려줄 때 쓰는 게 스키마였다.
7회차 — 에이전트, MCP, 스킬 — 범용 AI를 내 전용 조수로
4. 헷갈리는 개념
| 이 용어 | 비슷하지만 다른 것 | 차이 |
|---|---|---|
| 스키마 | 데이터 | 스키마는 빈 양식, 데이터는 채워진 종이. CREATE TABLE은 스키마, INSERT로 넣는 값은 데이터 |
| JSON Schema | JSON | JSON Schema는 “이런 모양이어야 한다”는 규칙서. JSON은 그 규칙에 맞춰 쓴 실제 값. 둘 다 생김새가 JSON이라 더 헷갈린다 |
| 스키마 | 템플릿 | 템플릿은 결과물의 초안(빈칸을 채우면 그대로 쓴다). 스키마는 검사 기준(맞는지 확인하는 용도) |
| DB 스키마 | 도구 스키마 | 쓰이는 곳이 다를 뿐 같은 개념이다. 표의 모양을 정하느냐, 도구의 입력 모양을 정하느냐의 차이 |
5. 많이들 오해하는 지점
ㄱ. “스키마가 곧 데이터다”
CREATE TABLE memory (...)를 보고 “memory라는 데이터를 만들었다”고 읽기 쉽다. 실제로 만든 건 빈 표 한 장이고, 안에는 아직 아무것도 없다. 양식을 인쇄한 것과 양식을 채운 것은 다른 일이다.
ㄴ. “JSON Schema랑 JSON은 같은 것”
둘 다 중괄호로 시작하니 구분이 잘 안 된다. 구분법은 간단하다. "type", "properties", "required" 같은 단어가 보이면 양식이고, {"city": "부산"}처럼 실제 값이 들어 있으면 채워진 종이다.
ㄷ. “description은 주석이니까 대충 써도 된다”
이게 가장 값비싼 오해다. 사람이 읽는 주석이 아니라 모델이 읽는 유일한 사용설명서다. 에이전트가 도구를 엉뚱하게 쓰거나 필요한 값을 빼먹는다면, 원인은 대개 모델이 아니라 description이 부실한 것이다. 사람에게 일을 시키면서 설명을 한 줄만 던져 준 셈이기 때문이다.