표 설계도(스키마)

손님 정보를 어떤 칸에 나눠 담을지 미리 정하는 표의 도면이에요. 엑셀로 치면 첫 줄에 머리글을 정하는 일이고, 데이터가 쌓인 뒤에 고치면 그때가 제일 비싸요.

쉽게 말하면

새 손님 명부를 엑셀로 만든다고 해 보세요. 값을 적기 전에 첫 줄부터 정하죠. 이름, 연락처, 첫 방문일, 메모. 그 첫 줄 머리글이 스키마예요. 데이터베이스도 똑같아요. 표마다 어떤 칸을 둘지, 각 칸에 글자가 들어갈지 숫자가 들어갈지 날짜가 들어갈지를 미리 정해요. 그 도면이 스키마고, 손님 한 명 한 명은 그 아래에 한 줄씩 쌓여요.

왜 "설계도"라고 부르냐면, 건물 도면과 성질이 같아서예요. 도면은 벽돌을 쌓기 전에 그려요. 벽돌이 다 올라간 뒤에 "방을 하나 나누자"고 하면 그때부터는 공사예요. 스키마도 데이터가 들어오기 전에 그리는 것이고, 데이터가 쌓인 뒤에 바꾸는 일은 공사가 돼요.

설계 없이 적은 명부

메모 = "김OO 010-1234 3월쯤 옴, 단골, 견과류 알레르기" (한 칸에 전부)

적을 땐 편해요. 그런데 "단골만 뽑아서 문자 보내 줘"가 불가능해요. 컴퓨터는 뭉친 글에서 단골을 못 골라내요.

머리글을 정한 명부

이름 | 연락처 | 첫 방문일 | 단골 여부 | 알레르기 메모

칸이 나뉘어 있으면 뽑고, 세고, 정렬하고, 문자를 보낼 수 있어요. 나중에 하고 싶은 일이 전부 여기서 갈려요.

엑셀로 번역하면

개발자 용어가 어렵게 들리는 건 단어가 낯설어서지, 개념이 어려워서가 아니에요. 사장님이 이미 아는 엑셀에 전부 대응돼요. 이 표 하나면 AI와 개발자의 말이 들리기 시작해요.

개발자 말	엑셀로 치면	뜻
테이블(표)	시트 한 장	같은 종류의 정보 묶음이에요. 손님 시트, 주문 시트, 예약 시트
행(row, 레코드)	한 줄	손님 한 명, 주문 한 건이에요. 데이터가 쌓인다는 건 줄이 늘어난다는 뜻이에요
열(column, 컬럼·필드)	칸 하나	이름 칸, 금액 칸처럼 세로로 같은 성격의 값이 모이는 칸이에요
스키마	첫 줄 머리글 + 각 칸의 규칙	어떤 칸을 두고 무엇을 넣을지에 대한 약속 전체예요
자료형(타입)	셀 서식(텍스트·숫자·날짜)	이 칸엔 숫자만, 저 칸엔 날짜만 들어가게 하는 규칙이에요
기본키(id)	줄마다 붙는 고유번호	주문번호 같은 거예요. 동명이인 손님이 있어도 절대 헷갈리지 않게, 모든 줄에 자동으로 붙어요

엑셀과 다른 점이 하나 있어요. 엑셀은 머리글이 없어도 아무 셀에나 적을 수 있지만, 데이터베이스는 스키마에 없는 칸에는 아예 적을 수 없어요. 답답해 보여도 그게 안전장치예요. 아무 데나 적을 수 있는 명부는 결국 아무도 못 읽는 명부가 되거든요.

왜 처음 설계가 제일 싼가

같은 수정인데 시점에 따라 값이 완전히 달라져요. 개업 전 인테리어와 영업 중 인테리어의 차이라고 보면 정확해요. 순서대로 볼게요.

1손님이 0명일 때 칸 추가. 머리글 하나 더 적는 일이에요. 1초 걸리고, 아무것도 잃지 않아요.
2손님이 1,000명일 때 칸 추가. 칸 자체는 추가돼요. 그런데 기존 1,000줄의 그 칸은 전부 비어 있어요. 빈칸을 어떻게 볼지, 채울지 말지를 정해야 해요. 그래도 이건 양반이에요.
3손님이 1,000명일 때 칸을 쪼개거나 합치기. "이름과 연락처를 한 칸에 적어 뒀는데 나누고 싶다" 같은 경우예요. 1,000줄을 전부 변환해야 하고, 변환 중에 실수하면 손님 정보가 상해요. 이게 제일 비싼 수정이에요.
4그래서 운영 중인 서비스의 스키마 수정은 스키마 변경이라는 별도 절차를 밟고, 시작 전에 반드시 백업을 떠요.

그래도 완벽주의는 금물이에요

"처음 설계가 중요하다"를 "모든 칸을 미리 완벽하게 예측해야 한다"로 읽으면 안 돼요. 그러다 시작을 못 하는 게 더 흔한 실패예요. 핵심 칸만 제대로 잡고 시작하세요. 칸 추가는 나중에 해도 싸요. 비싼 건 잘못 뭉쳐 놓은 칸을 나중에 쪼개는 일이에요.

사장님이 실제로 겪는 장면

장면 1 · AI에게 예약 앱을 주문했더니 되물어 온다

“예약 정보에 어떤 항목을 저장할까요? 이름, 연락처, 날짜, 인원 정도로 시작할까요?”

이 질문이 바로 스키마를 정하는 순간이에요. 지나가는 확인 절차가 아니라 도면에 서명하는 자리예요. 대충 "응 그렇게 해" 하지 말고 내 가게 하루를 떠올려 보세요. 노쇼 손님을 표시하고 싶다면, 요청사항 메모가 필요하다면, 지금 말하는 게 제일 싸요.

장면 2 · 단골에게 감사 문자를 보내려는데

“석 달 넘게 운영한 예약 앱인데, "3번 이상 온 손님만 뽑아 줘" 했더니 방문 횟수를 저장한 적이 없다고 해요.”

스키마에 없는 정보는 세상에 없는 정보예요. 손님이 실제로 3번 왔어도, 적어 둔 칸이 없으면 컴퓨터에게 그 사실은 존재하지 않아요. 과거는 못 채우지만 지금부터는 셀 수 있어요. AI에게 "오늘부터 방문 기록이 쌓이게 해 줘"라고 말하면 돼요. 이 아까움이 설계를 배우는 수업료예요.

증상이 보이면, 이렇게 말하세요

스키마 문제는 "스키마"라는 단어로 나타나지 않아요. 아래 같은 증상으로 나타나요. 증상만 알아보면, AI에게 할 말은 정해져 있어요. 그대로 말하면 돼요.

이런 증상이면	AI에게 이렇게 말하세요
저장할 때 자꾸 오류가 나요. 형식이 안 맞는대요	"이 칸에 어떤 형식의 값이 들어가야 하는지 알려 줘. 그리고 손님이 잘못 입력하면 저장 전에 친절한 안내가 뜨게 해 줘"
새로 적고 싶은 항목(알레르기 메모 등)의 자리가 없어요	"손님 표에 알레르기 메모 칸을 추가해 줘. 기존 손님들은 비워 두면 돼"
한 칸에 여러 정보가 뭉쳐 있어요	"이름과 연락처가 한 칸에 들어 있어. 두 칸으로 나누고, 기존 데이터도 나눠서 옮겨 줘. 옮기기 전에 백업부터 해 줘"
같은 손님이 자꾸 두 번 등록돼요	"연락처가 같으면 같은 손님으로 취급하게, 중복 등록을 막아 줘"
주문이 어느 손님 것인지 연결이 안 돼요	"주문 표에 어느 손님의 주문인지 연결되게 해 줘. 손님 표와 주문 표를 이어 줘"
전화번호 맨 앞의 0이 자꾸 사라져요	"전화번호 칸이 숫자 형식인 것 같아. 글자 형식으로 바꾸고, 기존 번호의 앞자리 0도 되살려 줘"
월 매출 합계가 계산이 안 돼요	"금액 칸이 글자로 저장되고 있는지 확인해 줘. 숫자 형식으로 바꾸고 기존 값도 변환해 줘"

모든 주문에 붙이는 한마디

표의 구조를 바꾸는 요청 앞에는 "먼저 지금 데이터를 백업해 줘" 를 습관처럼 붙이세요. 잘 되면 백업은 쓸 일이 없고, 잘못되면 백업이 가게를 살려요. 밑질 게 없는 한마디예요.

지금은 신경 쓰지 않아도 되는 때

데이터 얘기만 나오면 긴장하는 사장님이 많은데, 스키마는 항상 신경 쓸 일이 아니에요. 신경 써야 하는 순간은 딱 정해져 있고, 그 전까지는 틀려도 아무 비용이 없어요.

지금 내 상황이	신경 쓸 일인가
소개 페이지만 있어요. 저장 기능이 없어요	아니요. 저장할 것이 없으면 스키마도 없어요. 이 문서는 나중에 다시 오세요
만드는 연습 중이에요. 진짜 손님 데이터가 없어요	아니요. 지금 틀리면 그냥 새로 만들면 돼요. 공사비가 0원인 유일한 기간이라 오히려 마음껏 틀려 볼 때예요
템플릿으로 시작했어요	아니요. 설계가 이미 들어 있어요. 내 가게에 안 맞는 칸이 눈에 걸릴 때만 고치면 돼요
진짜 손님 정보가 쌓이기 시작했어요	네. 오늘부터예요. 구조를 바꿀 땐 백업이 먼저고, "나중에 세고 싶은 것"이 칸으로 있는지 한번 훑어보세요
예약·주문·결제가 서로 얽히기 시작했어요	네. 표와 표 사이에 연결이 생기는 시점이라, 설계를 한 번 점검받기 제일 좋은 때예요

한 줄로 줄이면 이래요. 스키마 걱정은 데이터가 진짜가 되는 날 시작하면 돼요. 그 전의 모든 실수는 무료 연습이에요.

겁이 나는 게 정상이에요

데이터는 잘못 만지면 잃는 것이라서 겁나는 게 맞아요. 그런데 그 겁의 대부분은 백업 습관 하나로 해소돼요. 공사 전에 복사본을 떠 두면 최악의 경우에도 어제로 돌아갈 수 있어요. 겁은 조심성으로 바꿔 쓰고, 시작을 미루는 이유로는 쓰지 마세요.

설계를 검토하는 눈, 세 가지

도면은 AI가 그려요. 사장님이 직접 그릴 일은 거의 없어요. 대신 그려 온 도면을 검토하는 눈은 필요해요. 세 가지만 보면 돼요.

1한 칸에는 한 가지만. "김OO / 010-1234 / 단골" 같은 만능 메모 칸은 적을 땐 편하고 뽑을 땐 불가능해요. 나중에 골라내고 싶은 정보는 반드시 제 칸을 줘야 해요.
2나중에 세고 싶은 건 지금부터 적게 해요. 방문 횟수, 첫 방문일, 어떤 경로로 왔는지. 스키마에 없는 정보는 과거로 돌아가서 채울 수 없어요. "언젠가 통계 보고 싶은 것"을 미리 말해 두세요.
3종류가 다르면 표를 나눠요. 손님 정보와 주문 정보를 한 표에 우겨 넣으면, 손님이 주문할 때마다 이름과 연락처가 복사돼요. 손님 표 따로, 주문 표 따로 두고 둘을 연결하는 게 정석이에요.

자료형도 한 줄만 알아 두세요. 칸마다 서식이 있어요. 날짜 칸에는 "3월쯤"이라고 못 적게 하고, 금액 칸에는 숫자만 들어가게 하는 규칙이에요. 금액 칸이 숫자여야 월 매출 합계가 나와요. 글자로 적힌 "만오천원"은 더할 수가 없거든요.

반대 방향의 함정도 있어요. 전화번호는 숫자처럼 보여도 글자 칸에 담아요. 숫자 칸에 넣으면 맨 앞의 0이 사라져요. 엑셀에서 010이 10으로 바뀌던 그 일이 데이터베이스에서도 똑같이 일어나요. 구분법은 간단해요. 더하거나 평균 낼 일이 있으면 숫자, 없으면 번호라도 글자예요. 전화번호, 사업자번호, 우편번호는 전부 글자 칸이에요.

자주 묻는 것

Q. 스키마를 제가 직접 그려야 하나요?: 아니요. 바이브캠퍼스에서는 무엇을 만들고 싶은지 말하면 AI가 도면을 그려요. 사장님 몫은 "우리 가게는 이런 정보를 남기고 싶다"를 말하는 것까지예요. 요구는 사장님이, 도면은 AI가. 대신 그려 온 도면에 내가 원하는 칸이 있는지는 사장님이 확인해요.
Q. 이미 운영 중인데 칸을 추가하고 싶어요. 위험한가요?: 칸 추가 자체는 위험이 낮은 편이에요. 기존 줄은 그 칸이 비어 있게 될 뿐이에요. 위험한 건 칸을 지우거나, 쪼개거나, 형식을 바꾸는 쪽이에요. 어느 쪽이든 백업을 먼저 뜨고 하면 돼요.
Q. 그냥 엑셀로 관리하면 안 되나요?: 손님이 몇십 명이고 사장님 혼자 보는 명부라면 엑셀도 충분해요. 그런데 웹사이트가 스스로 읽고 써야 하는 순간, 그러니까 손님이 직접 예약을 넣고 자동으로 문자가 나가야 하는 순간부터는 데이터베이스가 필요하고, 데이터베이스를 쓰는 순간 스키마가 생겨요.
Q. 손님 정보를 언제까지 보관해야 하나요? 그것도 설계에 들어가나요?: 보관 기간은 정보의 종류마다 법이 달라서 여기서 단정할 수 없어요. 거래 기록은 법으로 정해진 보관 기간이 있고, 동의받아 모은 개인정보는 목적을 다하면 파기하는 것이 원칙이에요. 정확한 기간은 개인정보보호위원회 안내 자료나 세무사·법률 전문가에게 확인하세요. 설계 쪽에서 도울 수 있는 건 하나예요. "언제 받았는지" 날짜 칸을 두면 나중에 파기 관리가 훨씬 쉬워져요.
Q. 내 스키마가 틀렸는지 어떻게 알아요?: 증상으로 알아요. 뽑고 싶은데 못 뽑는다, 한 칸에 정보가 뭉쳐 있다, 같은 손님이 두 번 등록된다. 이 셋 중 하나가 보이면 위의 증상 표에서 해당 줄을 찾아 그대로 말하면 돼요.
Q. 표가 몇 개나 있어야 정상이에요?: 정답 개수는 없어요. 작은 예약 서비스면 손님, 예약, 메뉴 정도로 3~5개가 보통이에요. 개수보다 중요한 기준은 "종류가 다른 정보가 한 표에 섞여 있지 않은가"예요.
Q. 칸 이름이 전부 영어던데, 한국어로 바꿔야 하나요?: 그대로 두세요. 도면 위의 칸 이름(name, phone 같은 것)은 영어로 쓰는 게 오랜 관례고, 손님 화면에 보이는 라벨("이름", "연락처")은 따로 있어요. 둘은 별개라서 도면이 영어라고 화면까지 영어가 되는 게 아니에요.
Q. 개발자에게 일을 맡길 때 스키마가 왜 중요해요?: 도면이 곧 가게 구조 설명서라서요. 새로 온 개발자는 코드보다 스키마를 먼저 봐요. 표가 몇 개고 서로 어떻게 연결됐는지만 보면 서비스의 뼈대가 한눈에 들어오거든요. 인수인계 때 "스키마 문서 포함해 주세요" 한마디면 다음 사람의 일주일을 아껴 줘요.

헷갈리기 쉬운 것

스키마 = 데이터? 아니에요. 스키마는 그릇의 모양이고 데이터는 내용물이에요. 그래서 개발자에게 "스키마 좀 볼게요"라는 요청을 받아도 놀랄 필요 없어요. 도면을 보는 것이지 손님 정보를 보는 게 아니에요. 물론 내용물을 통째로 넘기는 건 전혀 다른 문제고, 훨씬 조심해야 해요.

스키마 변경 = 백업? 별개의 일이에요. 스키마 변경은 그릇 모양을 바꾸는 공사고, 백업은 공사 전에 내용물을 안전한 곳에 복사해 두는 습관이에요. 공사가 잘못됐을 때 되돌릴 수 있는 유일한 길이 백업이라서, 둘은 항상 붙어 다녀야 해요.

스키마 = SQL? 이것도 달라요. 스키마가 표의 도면이라면, SQL은 그 표에 말을 거는 언어예요. "단골만 뽑아 줘" 같은 부탁을 컴퓨터 말로 옮긴 것이 SQL이고, 그 부탁이 통하려면 도면에 단골 칸이 있어야 해요. 도면이 먼저, 말 걸기는 그다음이에요.

확인해 보세요

AI가 "예약 정보에 어떤 항목을 저장할까요?"라고 물어요. 이 순간은 어떤 순간일까요?

하나 더

손님 1,000명이 쌓인 뒤에 "이름+연락처가 한 칸"인 걸 두 칸으로 나누려면?

직접 해보기

설계 질문을 직접 받아 보세요

스튜디오에서 예약이나 주문을 저장하는 앱을 주문해 보세요. AI가 "어떤 항목을 저장할까요?" 하고 물어 오는 순간이 바로 스키마를 정하는 순간이에요. 연습 단계라 어떤 답을 해도 잃을 게 없어요.

스튜디오 열기

더 깊이 (안 읽어도 괜찮아요)

정규화라는 말을 들었다면 · 같은 정보가 두 군데 이상 적히지 않게 표를 나누는 정리법의 이름이에요. 손님 주소가 주문마다 복사돼 있으면 이사 한 번에 주문 기록 수십 줄을 고쳐야 하고, 하나라도 놓치면 두 주소가 싸워요. 교과서는 이걸 단계별로 나눠 가르치지만, 사장님은 "같은 정보가 두 군데 적혀 있으면 의심한다" 하나면 충분해요.

엑셀 비유가 어긋나는 곳 · 엑셀은 빈 셀 아무 데나 적을 수 있고 셀마다 서식이 달라도 되지만, 데이터베이스는 스키마 밖의 입력을 거부하고 한 열 전체가 같은 자료형이에요. 그리고 가장 큰 차이는 표끼리의 연결이 정식 기능이라는 점이에요. "이 주문은 이 손님 것"이라는 관계를 데이터베이스는 도면에 새겨 두고 지켜 줘요. 손님을 지우려 하면 "이 손님의 주문이 남아 있다"고 막아 주는 식으로요. 엑셀에는 그런 파수꾼이 없어요.

머리글이 없는 데이터베이스도 있어요 · NoSQL이라고 부르는 종류는 미리 정한 머리글 없이 자유 형식으로 저장할 수 있어요. 유연해 보이지만, 규칙이 사라진 게 아니라 규칙을 지키는 책임이 코드 쪽으로 옮겨 간 것뿐이에요. 규칙을 대신 지켜 주는 파수꾼이 있는 쪽, 그러니까 머리글이 있는 쪽이 처음 시작하는 사장님에게는 더 안전해요.

이것만 기억하세요

·스키마는 엑셀 첫 줄 머리글이에요. 어떤 칸에 무엇을 담을지의 약속이에요
·데이터가 없을 때 고치면 1초, 쌓인 뒤에 고치면 공사예요
·나중에 뽑고 싶은 정보는 반드시 제 칸을 줘요. 만능 메모 칸은 금물이에요
·표 구조를 만지기 전에는 "먼저 백업해 줘"부터예요
·진짜 손님 데이터가 쌓이기 전까지는 틀려도 공짜예요. 마음껏 연습하세요