표·행·열

쉽게 말하면

그래서 데이터 얘기는 겁낼 이유가 없어요. 개발자나 AI가 "테이블", "행", "열" 같은 말을 쓰면, 머릿속에서 엑셀 화면을 떠올리고 단어만 바꿔 들으면 돼요. 이 문서가 그 단어 변환표예요.

가게 장부로 옮겨 보면

말로만 들으면 헷갈리니, 예약을 받는 가게의 표를 하나 그려 볼게요. 아래가 데이터베이스 안에 실제로 들어 있는 "예약" 표의 모습이에요.

가로로 읽으면 행이에요. 첫째 줄 전체가 손님 A의 예약 한 건이에요. 손님이 새로 예약하면 줄이 하나 늘어나요. 예약을 취소하면 그 줄이 지워지고요. 행이 늘어나는 건 장사가 잘된다는 뜻이라 아무리 늘어도 좋은 일이에요.

세로로 읽으면 열이에요. "전화번호" 칸을 위에서 아래로 쭉 읽으면 모든 손님의 전화번호가 나와요. 열은 표를 처음 만들 때 정하고, 그 뒤로는 잘 안 바뀌어요. "요청사항" 칸을 새로 만들고 싶다면 그건 열을 추가하는 일이고, 표의 구조를 바꾸는 일이라 행 추가보다 조심스러운 작업이에요.

그럼 엑셀 쓰면 되지, 왜 데이터베이스인가요

모양이 같은데 왜 굳이 데이터베이스를 쓰는지 궁금할 거예요. 차이는 표의 모양이 아니라 표를 다루는 방식에 있어요.

정리하면 이래요. 엑셀은 사람이 손으로 쓰는 표이고, 데이터베이스는 내 서비스가 스스로 쓰는 표예요. 손님이 회원가입을 하면 회원 표에 행이 하나 생기고, 주문을 하면 주문 표에 행이 하나 생겨요. 사장님이 밤에 자는 동안에도요.

그리고 데이터베이스는 규칙을 지켜 줘요. 엑셀은 전화번호 칸에 "나중에 확인"이라고 글자를 적어도 말리지 않지만, 데이터베이스는 칸마다 "여긴 숫자만", "여긴 비우면 안 됨" 같은 규칙을 정해 두면 어긋나는 값을 받지 않아요. 손님 데이터가 수천 건이 돼도 깨끗하게 유지되는 비결이 이거예요.

행 하나의 일생

표·행·열이 머리에 잡혔으면, 이번엔 행 하나가 태어나서 사라질 때까지를 따라가 볼게요. 손님 한 명이 내 서비스에 회원가입을 했다고 해요.

1. 1태어나요. 가입 버튼을 누르는 순간 회원 표에 행이 하나 생겨요. 이름 칸, 이메일 칸에 손님이 적은 값이 들어가고, 가입일 칸은 서비스가 알아서 채워요.
2. 2자라나요. 손님이 예약을 하고 주문을 하면, 예약 표와 주문 표에 이 손님과 연결된 행들이 쌓여요. 회원 표의 행 자체는 그대로인데, 다른 표에서 이 손님을 가리키는 줄이 늘어나는 거예요.
3. 3바뀌어요. 손님이 전화번호를 바꾸면 새 행이 생기는 게 아니라, 있던 행의 전화번호 칸만 고쳐져요. 엑셀에서 셀 하나 고치는 것과 같아요.
4. 4떠나요. 손님이 탈퇴하면 그 행을 지우거나, 지운 것처럼 표시만 해 두거나 둘 중 하나예요. 개인정보는 지워야 하지만 거래 기록은 법으로 남겨야 하는 경우가 있어서, 실제 서비스들은 둘을 나눠서 처리해요.

이 흐름을 알면 데이터 얘기의 대부분이 이 네 가지 중 하나라는 게 보여요. 생기고, 쌓이고, 고쳐지고, 지워지고. 개발자가 어떤 말을 해도 "지금 행이 생기는 얘기인가, 고쳐지는 얘기인가"로 분류해 들으면 길을 잃지 않아요.

사장님이 실제로 겪는 장면

증상이 보이면 이렇게 말해요

표·행·열이라는 단어를 알면 좋은 진짜 이유는 이거예요. 문제가 생겼을 때 AI에게 정확히 주문할 수 있게 돼요. 자주 겪는 증상과 그때 쓰는 문장을 짝지어 둘게요. 그대로 복사해서 써도 돼요.

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

이 문서를 읽었다고 해서 표를 직접 설계하러 갈 필요는 없어요. 다음에 해당하면 지금은 이 주제를 덮어 두셔도 돼요.

1. 1아직 만들기 전이거나 만드는 중이라면 신경 쓸 일이 아니에요. 바이브캠퍼스에서 서비스를 만들면 AI가 표와 열을 알아서 설계해요. 사장님이 표를 그리는 게 아니라, 필요할 때 알아보기만 하면 돼요.
2. 2손님 데이터를 아예 안 받는 서비스라면 (소개 페이지, 메뉴판, 포트폴리오 같은 것) 표 자체가 없을 수 있어요. 그건 이상한 게 아니라 정상이에요.
3. 3서비스가 잘 돌아가고 있다면 표 구조를 궁금해서 열어 볼 필요는 없어요. 이 단어들이 필요해지는 순간은 딱 두 가지예요. 항목을 추가하고 싶을 때, 그리고 데이터가 이상하게 보일 때.

반대로 신경 써야 하는 순간은 이래요. 손님 개인정보를 담은 표가 생기는 순간부터는 개인정보 쪽 의무가 따라와요. 그리고 표의 구조를 바꾸는 큰 작업(마이그레이션)을 하기 전에는 백업부터예요. 이 두 가지만 기억하면 나머지는 그때그때 찾아봐도 늦지 않아요.

자주 묻는 것

Q. 테이블, 행, 열을 제가 직접 만들어야 하나요?

바이브캠퍼스에서는 아니에요. "손님 예약을 받고 싶어"라고 말하면 AI가 예약 표와 필요한 열들을 알아서 만들어요. 사장님의 일은 만들어진 표를 알아보고, 부족한 칸이 있으면 말로 추가를 시키는 거예요.

Q. 레코드, 필드라는 말도 들었는데 다른 건가요?

같은 거예요. 행을 레코드라고도 부르고, 열을 필드나 컬럼이라고도 불러요. 사람마다 부르는 말이 다를 뿐이라, 넷 다 들리면 "아, 줄이랑 칸 얘기구나" 하면 돼요.

Q. 표는 몇 개나 생기나요? 많으면 문제인가요?

서비스 하나에 표가 여러 개인 게 정상이에요. 회원 표, 예약 표, 주문 표, 리뷰 표처럼 주제마다 한 장씩이에요. 엑셀 파일 하나에 시트가 여러 장인 것과 같아요. 개수 자체는 걱정할 일이 아니에요.

Q. 행이 수만 개가 되면 느려지지 않나요?

수만 개 정도는 데이터베이스에게 아무것도 아니에요. 수백만 개쯤 되면 찾아보기가 느려질 수 있는데, 그때 쓰는 게 인덱스라는 색인이에요. 그 시점이 오면 그건 장사가 아주 잘된다는 뜻이니 좋은 고민이에요.

Q. 엑셀에 있던 손님 명단을 표로 옮길 수 있나요?

네, 모양이 같아서 옮기기 쉬워요. AI에게 "이 엑셀 파일의 손님 명단을 회원 테이블로 넣어 줘"라고 하면 돼요. 옮기기 전에 엑셀의 머리글(이름, 전화번호 같은 칸 이름)이 표의 열과 짝이 맞는지만 같이 확인해요.

Q. 표를 처음에 잘못 만들면 나중에 못 고치나요?

고칠 수 있어요. 열을 추가하거나 이름을 바꾸거나 표를 나누는 건 다 가능한 공사예요. 다만 행이 많이 쌓인 뒤의 공사는 이사가 커지는 것처럼 조심할 게 늘어나요. 그래서 규칙은 하나예요. 구조를 바꾸기 전에 백업 먼저. 완벽한 설계를 처음부터 하려고 애쓰기보다, 장사하면서 필요할 때 고치는 게 정상 경로예요.

Q. 손님 행은 언제까지 보관해도 되나요?

이건 법이 걸린 문제라 여기서 단정하지 않을게요. 거래 기록은 법으로 일정 기간 보관 의무가 있고, 반대로 개인정보는 목적이 끝나면 지워야 하는 의무가 있어요. 정확한 기간은 개인정보보호위원회(privacy.go.kr)와 국세청 안내에서 내 업종 기준으로 확인하는 게 안전해요. 손님 데이터 관리 문서도 같이 보세요.

헷갈리기 쉬운 것

표(테이블)와 화면에 보이는 표는 달라요. 관리자 화면에서 보는 손님 목록 표는 데이터베이스의 표를 보여 주는 창이지 표 자체가 아니에요. 화면의 표를 예쁘게 바꾸는 건 프런트엔드 일이고, 표에 칸을 추가하는 건 데이터베이스 일이에요. AI에게 말할 때 "화면의 표"인지 "데이터의 표"인지 구분해 주면 훨씬 정확하게 알아들어요.

열 추가와 행 추가는 무게가 달라요. 행 추가는 매일 수백 번 일어나는 일상이에요(손님이 늘어나는 것). 열 추가는 표의 구조를 바꾸는 공사예요. 자주 하는 일은 아니고, 할 때는 기존 행들의 그 칸이 비어 있게 된다는 것 정도만 알아 두면 돼요. 구조를 크게 바꾸는 작업은 마이그레이션 문서에서 다뤄요.