5-2 연습 문제 — ERD 전달 포맷,
세 포맷을 직접 변환해야 손에 남는다
이번 강의에서 배운 것 — 세 포맷 (CREATE TABLE / 텍스트 표 / mermaid) 비교, 그리고 일상 AI 작업에는 텍스트 표가 가장 효율적이라는 결론. 눈으로 비교한 포맷은 금방 흐려지지만, 직접 변환해본 포맷은 손에 남습니다. 마지막 도전 문제에서는 본인 프로젝트 DB 를 정리해 — 앞으로 모든 AI 요청에 재사용할 자산을 만듭니다.
이번 연습의 위치
완료 ✓
완료 ✓
지금 여기
프롬프트 품질 비교
섹션 5 마무리 ⭐
2-4에서 만든 AI 과외 선생님 세션을 그대로 쓰세요. 막히면 정답이 아니라 힌트만 요청하고 — 다 푼 뒤에는 본인이 변환한 포맷을 던지며 “내 답이 맞는지 검증해줘” 라고 물어보세요. 풀어본 뒤 AI 에 검증 요청 — 이 한 사이클이 이번 연습의 핵심 습관입니다.
문제 1. CREATE TABLE → 포맷 2 변환
다음 CREATE TABLE 문을 — 포맷 2 (텍스트 표) 로 변환하세요.
CREATE TABLE library_books (
book_id INT PRIMARY KEY AUTO_INCREMENT,
title VARCHAR(200) NOT NULL,
isbn VARCHAR(20) UNIQUE,
publisher_id INT,
publication_year INT,
FOREIGN KEY (publisher_id) REFERENCES publishers(publisher_id)
);
CREATE TABLE publishers (
publisher_id INT PRIMARY KEY AUTO_INCREMENT,
publisher_name VARCHAR(100) NOT NULL,
country VARCHAR(50)
);정답 보기
[테이블 구조]
- publishers (출판사): publisher_id PK, publisher_name, country
- library_books (책): book_id PK, title, isbn (UNIQUE), publisher_id FK → publishers, publication_year
[부모-자식 관계]
- publishers 1:N library_books핵심 변환:
INT NOT NULL같은 타입 정보 → 간략화 (AI 가 컨텍스트로 추측 가능)UNIQUE같은 중요 제약은 유지- FK 는 화살표 표기 (
FK → 부모) - 부모-자식 관계는 별도 블록
문제 2. 세 포맷 — 어떤 게 가장 좋은가
다음 시나리오 각각에서 — 어떤 포맷이 가장 좋을까요?
| # | 시나리오 |
|---|---|
| A | 사내 위키에 모델링 문서 작성 (사람이 볼 용도) |
| B | AI 에게 매일 SQL 작업 시킬 때 |
| C | 운영 DB 마이그레이션 — 새 컬럼 추가 SQL 검증 |
| D | 강의 / 블로그 글에서 ERD 보여줄 때 |
정답 보기
| # | 추천 포맷 | 이유 |
|---|---|---|
| A | mermaid | 사람이 시각적으로 이해하기 가장 좋음. 위키에 임베드 가능 |
| B | 텍스트 표 (포맷 2) | 짧고 명확. 토큰 효율. 매일 쓰는 작업이라 효율성 중요 |
| C | CREATE TABLE (포맷 1) | 타입·NULL·UNIQUE 등 모든 제약을 정확히 전달해야 마이그레이션 SQL 이 안전 |
| D | mermaid | 시각적 ERD 가 블로그 / 강의 자료에서 가장 어필 |
사람 → mermaid · AI (정확도 중요) → CREATE TABLE · AI (일상) → 텍스트 표
문제 3 (도전). 본인 회사 / 프로젝트 DB 정리
본인이 일하거나 관심 있는 프로젝트의 DB 를 — 포맷 2 로 직접 정리 해보세요.
DBeaver Generate DDL 또는 INFORMATION_SCHEMA 쿼리 로 테이블 정보를 추출합니다.
추출한 CREATE TABLE 문들을 AI 에 던지고 — 포맷 2 로의 변환을 요청합니다. 프롬프트는 바로 아래에서 복사하세요.
AI 가 만든 정리본을 본인이 검토 / 보완합니다 — 값 형식 힌트, 데이터 규모 추가.
완성본을 노트앱에 저장 — 앞으로 모든 AI 요청에 재사용합니다.
스텝 02 의 변환 요청 프롬프트 — 그대로 복사하세요.
다음 CREATE TABLE 문들을 — 더 간결한 형식 (테이블별 한 줄, PK/FK 표시, 부모-자식 관계 별도 블록) 으로 정리해줘:
[붙여넣기]gender (M/F)) 가 있는가?가이드
이 문제는 정답이 없습니다. 본인 도메인의 DB 를 “AI 에 던질 수 있는 형식” 으로 만들어두는 게 목적.
팁:
- 100 개 테이블이 있다면 — 자주 쓰는 20-30 개만 정리해도 충분
- 한 번 정리해두면 — 동료에게도 공유 가능. 팀 자산.
- 매월 / 분기 한 번 업데이트 (스키마 변경 반영)
예 — 잘 정리된 회사 DB 의 포맷 2 예시 (가상):
[테이블 구조 - 핵심 12개]
- users (사용자): user_id PK, email (UNIQUE), name, joined_at
- companies (회사): company_id PK, name, industry
- employees: employee_id PK, user_id FK, company_id FK, role
- projects: project_id PK, company_id FK, title, status (active/done)
- tasks: task_id PK, project_id FK, assignee FK → users, due_date, status
- ...
[부모-자식 관계]
- users 1:N employees
- companies 1:N employees, 1:N projects
- projects 1:N tasks
- users 1:N tasks (as assignee)
[데이터 규모 - 2026년 5월 기준]
- users 5,000 / companies 200 / projects 1,500 / tasks 30,000이런 블록 하나가 — AI 협업의 “기반 자료” 가 됩니다.
세 포맷을 손으로 직접 변환해봤다면 — 다음은 같은 스키마를 주고도 결과가 갈리는, 좋은 프롬프트와 나쁜 프롬프트의 차이를 실제 사례로 비교할 차례입니다.