요구사항으로 테이블 구조 설계하기

1단계 전에 질문 3개가 먼저 왔다(예약을 취소하면 기록을 지우는지, 매장이 여러 곳인지, 디자이너를 손님이 고르는지). 그다음 개체 8개만 나오고 멈췄다.

customer — 앱으로 예약하는 손님, 로그인 주체 service_menu — 시술 메뉴 하나. 이름·가격·소요 시간을 가진다 no_show_record — 예약에 대해 사장님이 남기는 노쇼 표시

질문 2·3의 답에 따라 staff 개체가 빠질 수 있다고 표시해 두었다.

AI에게 데이터베이스 설계를 부탁하면 대개 완성된 테이블 정의 뭉치가 한 번에 쏟아집니다. 그럴듯해 보이지만 왜 이 열이 저 테이블에 들어갔는지 물어볼 자리가 없고, 잘못된 곳을 찾으려면 스무 개짜리 표를 처음부터 다시 읽어야 합니다.

그래서 과제를 개체 → 관계 → 테이블 정의 세 단계로 나눠 받습니다. 개체 이름만 보는 1단계에서 "예약"과 "시술 내역"이 하나로 뭉쳐 있는 것을 발견하면 그 자리에서 바로잡을 수 있고, 뒤 단계는 고쳐진 전제 위에서 진행됩니다. 각 단계 끝에서 멈추라고 못 박지 않으면 AI는 세 단계를 한 답에 몰아서 써 버립니다.

되묻기를 넣은 이유는 테이블 설계가 몇 가지 전제에 크게 흔들리기 때문입니다. 예약을 취소하면 기록을 지우는지 남기는지, 한 사람이 여러 매장을 쓸 수 있는지에 따라 테이블 개수가 달라지는데, 질문하지 않는 AI는 이런 것을 조용히 하나로 정해 버립니다. 최대 3개로 묶어 둔 것은 질문만 길게 이어지는 것을 막기 위해서입니다.

형식에서 열마다 타입과 제약을 적게 한 것은 이 표가 그대로 옮겨 적을 재료이기 때문입니다. 기본키와 외래키가 빠진 설계는 보기에 멀쩡해도 실제로 만들려는 순간 막힙니다. "목록에 없는 기능을 위한 테이블은 만들지 마세요"는 AI가 습관처럼 붙이는 알림·로그·태그 테이블을 걸러 냅니다.

테이블 열 개와 열 정의가 한 번에 나옵니다. 문제는 검증할 방법이 없다는 것입니다. 등급·포인트·쿠폰처럼 말한 적 없는 기능의 테이블이 섞여 있어도 그럴듯해서 넘어가고, 정작 노쇼 기록을 어디에 둘지는 빠집니다. 한 곳을 고치면 관계가 줄줄이 어긋나서 결국 다시 물어보게 됩니다.

단계를 나눠 받는 프롬프트라 대화가 길어집니다. 3단계에서 앞 단계와 어긋난 표가 나오면, 그때까지 확정한 개체 목록을 다시 붙여 넣고 이어 가는 편이 정확합니다. ERD 그림을 요청하면 모델에 따라 선이 어긋난 텍스트 도식이 나오니, 관계는 "한 사람이 여러 예약을 가진다"처럼 문장과 표로 받는 편이 확인하기 쉽습니다.