EP 3. AI가 데이터베이스를 설계한다면 확인할 것

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

AI가 설계한 데이터베이스는 테이블 분리, 기본 키와 외래 키, 데이터 규칙, 수정·삭제 정책을 확인하고 잘못된 입력이 실제로 거절되는지 검증해야 한다.

📌 핵심 요점

1. 고객 정보를 주문마다 반복하면 주소나 연락처를 바꿀 때 일부 기록만 수정되는 문제가 생긴다. 고객과 주문을 역할별 테이블로 나누는 정규화가 중복과 수정 이상을 줄인다.
2. 기본 키는 각 행을 구분하는 고유한 값이며 중복되거나 비어 있으면 안 된다. 동명이인도 이름 대신 고객번호로 구분해야 한다.
3. 외래 키는 주문과 고객을 연결한다. 관계와 제약이 제대로 설정되어야 존재하지 않는 고객의 주문을 데이터베이스가 거절할 수 있다.
4. 필수값, 데이터 타입, 금액 범위, 수정·삭제 정책은 업무에 맞게 사람이 정해야 한다. 실습은 주문 금액을 0 이상으로 제한하고 주문이 남은 고객의 삭제를 막는다.
5. AI의 검증 완료 보고나 화면의 경고만으로 판단하지 않는다. 중복 기본 키, 없는 고객의 주문, 음수 금액을 직접 넣어 데이터베이스 자체의 거절 여부를 확인한다.

🧩 배경과 문제 정의

고객 관리와 주문 내역을 일반 업무용 엑셀 시트로 관리하면 같은 고객의 정보가 주문마다 반복될 수 있다. 영상은 한 고객의 주소를 일부 주문서에서만 수정해 서로 다른 주소가 남는 사례로 시작한다. AI에게 데이터베이스 생성을 맡긴다고 이런 문제가 자동으로 해결되는지 묻고, 결과를 검수하는 기준을 설명한다.

이번 편의 질문은 데이터를 어디에 저장할지가 아니라 어떤 구조와 규칙으로 정리할지다. 고객과 주문을 나누고 번호로 연결하는 관계형 데이터베이스를 살펴본 뒤, 로컬 SQLite 실습에서 잘못된 데이터와 부적절한 삭제가 실제로 차단되는지 확인한다.

🕒 시간순 섹션별 상세정리

1. 엑셀의 주소 불일치에서 출발한 설계 문제

• 같은 고객이 두 번 주문하면서 고객 정보도 반복 입력되고, 주소를 한 주문서에서만 고쳐 서로 다른 정보가 남는 상황을 제시한다. AI가 데이터베이스를 만들면 이런 문제가 저절로 해결되는지 질문한다. [00:52]
• 지난 편의 브라우저 저장소 이야기에서 데이터 구조 설계로 초점을 옮긴다. 엑셀에도 표와 관계 기능이 있으며, 이번 비교 대상은 일반 업무용 시트와 연결·규칙을 명시한 관계형 데이터베이스다. [01:41]

2. 테이블 분리로 중복과 수정 이상 줄이기

• 표는 테이블, 세로 항목은 컬럼 또는 필드, 고객 한 명의 한 줄은 행 또는 레코드라고 보여준다. 차이는 표를 어떻게 나누고 연결하며 입력 규칙을 세우는지에서 나타난다. [02:29]
• 주문마다 이름·연락처·지역을 반복하면 정보 변경 시 여러 곳을 수정해야 한다. 일부만 고치면 서로 다른 정보가 남는 중복 데이터와 수정 이상이 발생한다. [03:20]
• 고객 정보는 고객 테이블에 한 번만 저장하고 주문에는 고객번호를 넣는다. 지역 변경은 고객 테이블 한 곳에서 처리하며, 이런 역할별 분리를 정규화의 출발점으로 보여준다. [04:25]

3. 기본 키와 외래 키로 고객과 주문 연결하기

• 이름이 같은 고객을 구분하려면 고유한 고객번호가 필요하다. 각 행을 식별하는 기본 키는 같은 테이블에서 중복되거나 비어 있으면 안 된다. [05:14]
• 주문의 고객번호가 고객 테이블을 참조하는 외래 키가 된다. 규칙이 제대로 설정되어 있으면 존재하지 않는 고객번호에 주문을 연결하려는 입력을 거절할 수 있다. [05:57]
• 고객 한 명은 여러 주문을 가질 수 있고 주문이 전혀 없을 수도 있다. 이 예제에서 주문 한 건은 고객 한 명에게 속하며, 관계도는 테이블 사이의 연결 구조를 보여 준다. [06:51]

4. 데이터 타입과 제약은 업무 기준으로 정하기

• 테이블과 번호만으로 설계가 끝나지 않는다. 이름의 빈칸 허용 여부, 금액의 데이터 타입, 음수 허용 여부 같은 컬럼 규칙을 정해야 한다. [07:07]
• 실습에서는 번호와 금액을 정수로, 이름과 상품명을 문자로 관리한다. 고객 이름은 필수이고 금액은 0 이상이며, 환불에 필요한 음수는 별도 규칙으로 설계해야 한다. [07:28]
• 데이터베이스가 회사 업무를 스스로 이해하지는 않는다. 무엇을 정상 데이터로 볼지는 사람이 먼저 결정해야 한다. [07:35]

5. AI 설계안을 검토하고 로컬 SQLite로 구현하기

• 엑셀 주문표를 AI에 전달한 뒤 고객·주문 분리, 테이블별 고유번호, 주문과 고객번호의 연결을 먼저 점검한다. 설계가 이상하면 다시 요청하고 검수해야 한다. [08:08]
• 실습은 별도 클라우드 계정 없이 파일 하나로 시작할 수 있는 로컬 SQLite를 사용한다. customers와 orders를 만들고 각각 기본 키를 두며 주문의 고객번호가 고객 테이블을 참조하도록 설계한다. [08:38]
• 테이블·컬럼·규칙의 설계도를 스키마라고 설명하고 실제 파일에서 읽은 구조를 확인한다. 데이터베이스는 로컬에서도 사용할 수 있으며, SQLite는 파일을 읽고 쓰면서 규칙을 지키는 엔진으로 보여준다. [09:24]

6. 정상 동작과 잘못된 입력·삭제를 함께 검증하기

• 고객 네 명과 주문 네 건을 넣어 동명이인을 고객번호로 구분한다. 고객 101번의 지역을 바꿔도 주문을 일일이 수정할 필요 없이 연결 관계가 유지된다. [10:05]
• 중복 고객번호, 없는 고객 999번의 주문, 음수 금액을 차례로 입력한다. 화면 경고보다 데이터베이스 자체가 값을 거절했는지 확인해야 하며, AI의 검증 완료 보고에도 사람의 최종 확인이 필요하다. [10:56]
• 고객 삭제 시 주문 처리 방식은 서비스에 맞게 정해야 한다. 실습에서는 주문이 남은 고객의 삭제를 막고, 수정·삭제 규칙까지 포함해 데이터가 모순되지 않도록 지키는 무결성을 보여준다. [11:43]

7. 일곱 가지 점검표와 다음 편의 조회 실험

• 최종 점검표는 테이블 분리, 기본 키, 외래 키, 관계의 개수, 필수값·금액 규칙, 잘못된 입력 차단, 수정·삭제의 영향이다. 이 질문에 답할 수 있다면 SQL을 아직 몰라도 AI 설계를 평가할 수 있다. [12:36]
• 고객과 주문을 나누고 키로 연결한 뒤 잘못된 입력의 거절까지 확인했다고 정리한다. 이어 특정 고객의 주문 상품과 금액을 조회하려면 동명이인을 먼저 구분하고 데이터 관계를 따라가야 한다고 보여준다. [13:14]
• 다음 편에서는 자연어 질문을 AI가 SQL로 바꾸고 실제로 올바른 결과를 찾는지 실험할 예정이다. 이번 편의 설계를 다음 편에서 활용하겠다고 예고하며 마무리한다. [13:47]

🧾 결론

• 설계의 핵심은 표를 만드는 데서 끝나지 않고 데이터의 역할, 식별 기준, 연결 관계와 허용 규칙을 명시하는 데 있다.
• SQL 문법을 아직 몰라도 테이블 분리와 키, 관계, 제약, 수정·삭제 정책을 질문하면 AI가 만든 구조를 평가할 수 있다.
• AI는 구현을 도울 수 있지만 정상 데이터의 기준과 업무상 예외를 결정하고 최종 결과를 검수하는 책임은 사람에게 있다.

📈 투자·시사 포인트

• 업무 자동화를 도입할 때 생성된 코드의 길이보다 데이터 중복과 수정 부담을 줄이는 구조인지 평가할 필요가 있다.
• 고객과 주문의 연결 오류나 부적절한 삭제는 업무 기록에 영향을 준다. 도입 검토에는 정상 입력 시연과 함께 잘못된 입력을 차단하는 검증도 포함해야 한다.
• 영상의 SQLite 실습처럼 로컬 파일과 무료 도구로도 설계 검증을 시작할 수 있다. 별도 클라우드 계정 없이 데이터 구조와 규칙을 먼저 확인하는 접근이다.

⚠️ 불확실하거나 확인이 필요한 부분

• 제시된 고객·주문 구조는 입문용 예제다. 실제 서비스에서 필요한 테이블 구성과 관계를 이 예제만으로 확정할 수는 없다.
• 금액을 정수이자 0 이상으로 제한하는 것은 이번 실습의 규칙이다. 환불에 음수가 필요한 업무는 별도의 규칙을 설계해야 한다.
• 고객 삭제 시 주문을 함께 지울지, 남길지, 삭제를 막을지는 서비스에 따라 달라진다. 영상은 주문이 있는 고객의 삭제를 막는 방식을 선택한다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 고객 정보와 주문 정보를 구분하고, 같은 정보를 여러 주문에 반복 저장하는 부분을 찾는다.
• 각 테이블에 중복과 빈값을 허용하지 않는 기본 키가 있는지 확인한다.
• 주문의 고객번호가 고객 테이블을 참조하는지, 고객 한 명에게 주문이 없거나 여러 건일 수 있는지 확인한다.
• 필수값, 데이터 타입, 금액 범위와 환불 같은 예외 규칙을 업무 기준으로 정한다.

❓ 열린 질문

• 고객이 탈퇴해도 주문이나 회계 기록을 유지해야 한다면 고객 삭제와 주문 보존을 어떤 규칙으로 처리해야 할까?
• 환불처럼 음수 금액이 필요한 업무를 현재의 금액 제약과 어떻게 구분해 설계할까?
• 동명이인을 고객번호로 구분하면서 자연어로 질문할 때, AI가 올바른 고객과 주문을 찾아 SQL을 생성하는지 어떻게 확인할까?