테크타니 LEARN — 섹션 05 · AI 협업 SQL 작성법

같은 스키마, 다른 포맷 —
AI가 가장 잘 읽는 한 가지

5-1에서 AI에게 줘야 할 3가지를 배웠죠. 그중 첫 번째인 스키마 — 무엇을 주느냐만큼 어떤 모양으로 주느냐가 의외로 중요합니다. CREATE TABLE 원문, 텍스트 표, mermaid ERD 세 가지 포맷을 비교하고, 거의 항상 정답인 하나를 추천합니다. 마지막엔 회사 DB에서 30초 만에 정리본을 뽑는 법까지.

난이도쉬움소요6분준비물5-1 완료 (3가지 원칙)도구아무 AI나 + DBeaver

이번 섹션의 여정

5-1 줘야 할 3가지

완료 ✓

→

5-2 ERD 전달 포맷

지금 여기

→

5-3 좋은 vs 나쁜 프롬프트

프롬프트 비교

→

5-4 ~ 5-5

단계 분해 · 라이브 시연 ⭐

→

섹션 6 — AI 결과 의심하기

검증 체크리스트

같은 정보, 다른 이해도

5-1의 공식, 기억나시죠 — 스키마 + 샘플 데이터 + 원하는 결과 형태. 그중 첫 번째인 스키마는 내용이 같아도 포맷에 따라 AI가 읽는 정확도와 쓰는 토큰이 달라집니다. 실무에서 쓰이는 전달 포맷은 크게 세 가지예요.

포맷 1 — CREATE TABLE 원문 : 가장 정확, 그러나 가장 깁니다
포맷 2 — 텍스트 표 : 짧고 정확 — 오늘의 주인공 ⭐
포맷 3 — mermaid ERD : 사람 보기엔 좋지만 AI에게는 비효율

시작 전 체크

5-1 완료 — AI에게 줘야 할 3가지 원칙

shop DB 적재 완료 (2-3)

AI 과외 선생님 세션 (2-4) — 실습에 활용

포맷 1 — CREATE TABLE 원문

가장 정확한 방법은 init.sql에 들어 있던 CREATE TABLE 문을 그대로 던지는 것입니다.

CREATE TABLE members (
  member_id INT PRIMARY KEY AUTO_INCREMENT,
  member_name VARCHAR(50) NOT NULL,
  gender CHAR(1) NOT NULL,
  age INT NOT NULL,
  joined_at DATE NOT NULL
);
 
CREATE TABLE orders (
  order_id INT PRIMARY KEY AUTO_INCREMENT,
  member_id INT NOT NULL,
  ordered_at DATE NOT NULL,
  FOREIGN KEY (member_id) REFERENCES members(member_id)
);

장점	단점
100% 정확 — 데이터 타입·NULL 여부·FK까지 전부	깁니다 — 테이블 10개면 200줄
AI가 추측할 게 하나도 없음	토큰 비용이 들고, 한눈에 안 들어옴

언제 쓰나

운영 DB 마이그레이션, 보안에 민감한 쿼리처럼 AI가 만든 SQL의 검증이 매우 중요한 경우. 길어도 정확성이 우선일 때의 선택지입니다.

포맷 2 — 텍스트 표 ⭐

오늘의 주인공입니다. 같은 다섯 테이블을 이렇게 적습니다.

[테이블 구조]
- members (회원): member_id PK, member_name, gender (M/F), age, joined_at
- orders (주문): order_id PK, member_id FK → members, ordered_at
- order_items (주문상세): order_id FK, product_id FK, quantity
- products (상품): product_id PK, product_name, price, category_id FK
- categories (카테고리): category_id PK, category_name

[부모-자식 관계]
- members 1:N orders
- orders 1:N order_items
- products 1:N order_items
- categories 1:N products

좋은 이유가 한 줄마다 박혀 있어요 — 한 줄에 한 테이블(짧고 명확), 컬럼명 + PK/FK 표시, gender (M/F) 같은 값 형식 힌트, 그리고 부모-자식 관계를 별도 블록으로 — 4-2에서 배운 그 관계 그대로입니다.

⭐ 오늘의 결론을 미리

대부분의 경우, 포맷 2(텍스트 표)가 정답입니다. AI가 정확하게 이해하면서 토큰도 가장 적게 듭니다.

작은 디테일 하나 더 — 컬럼 형식 힌트입니다.

- members: gender (M/F)              ← 값 종류 명시
- products: price (정수, 원 단위)     ← 단위 명시
- orders: ordered_at (DATE 형식)      ← 타입 명시

힌트 한 줄의 효과

이런 괄호 한 줄이 AI의 “이 컬럼이 뭔지 헷갈리는데” 하는 추측을 미리 막아줍니다. 5-1에서 샘플 데이터를 주는 이유와 같은 원리예요 — 값의 생김새를 알려주는 것.

포맷 3 — mermaid ERD

설계 문서에서 자주 보는 mermaid ERD도 후보입니다.

사람 눈에는 이게 제일 좋아 보이죠. 그런데 AI에게 줄 때는 이야기가 다릅니다.

✕ AI에게 mermaid를 주면

다이어그램 파싱에 토큰을 씁니다

AI는 그림을 보는 게 아니라 mermaid 기호를 텍스트로 풀어 읽습니다. 같은 정보를 덜 효율적으로 전달하는 셈인데, 그렇다고 정확도가 더 오르지도 않아요.

✓ AI에게는 텍스트 표

테이블명 + 컬럼명 + 관계면 충분

AI에게 필요한 건 도형이 아니라 텍스트입니다. 포맷 2 한 블록이 mermaid보다 짧고, 더 정확하게 읽힙니다.

mermaid가 나쁜 게 아닙니다

팀 위키·설계 문서·블로그처럼 사람에게 보여줄 때는 mermaid가 최고예요. 용도가 다를 뿐입니다 — mermaid는 사람용, 텍스트 표는 AI용. 의외로 많이들 모르는 포인트입니다.

세 포맷 비교

5초 정리입니다.

포맷	정확도	길이	AI 효율	언제
1. CREATE TABLE	★★★	김	보통	검증이 중요할 때
2. 텍스트 표 ⭐	★★★	짧음	최고	거의 항상
3. mermaid ERD	★★	중간	낮음	사람용 · 문서용

대부분의 경우 — 포맷 2(텍스트 표)를 쓰세요. 이게 이번 강의에서 가져갈 단 하나의 결론입니다.

회사 DB 정리본 — 30초 추출법

남은 문제는 하나 — 본인 회사 DB의 테이블을 손으로 다 적기는 힘들다는 것. 추출 → 변환 → 저장, 3단계면 끝납니다.

구조 추출01 / 03

방법 1 — DBeaver에서 테이블 우클릭 → Generate SQL → DDL. CREATE TABLE 문이 클립보드로 복사됩니다.

방법 2 — 아래의 INFORMATION_SCHEMA 쿼리로 전체 테이블 구조를 한 번에 조회.

DBeaver: 테이블 우클릭 → Generate SQL → DDL

AI에게 변환 요청 ⭐02 / 03

추출 결과를 포맷 2로 정리하는 건 사람이 아니라 AI의 일입니다. 결과를 통째로 붙여넣고 “포맷 2로 정리해줘” 라고 요청하세요.

추출 결과 + 변환 프롬프트 함께 전송

정리본 저장 → 재사용03 / 03

AI가 돌려준 텍스트 표를 노트앱에 저장해두세요. 한 번 만들면 계속 재사용합니다.

노트앱에 저장 — 모든 AI 요청에 붙여넣기

방법 2의 쿼리는 이겁니다 — shop 자리에 본인 DB 이름을 넣으면 어디서든 동작해요.

SELECT
  TABLE_NAME,
  COLUMN_NAME,
  DATA_TYPE,
  COLUMN_KEY        -- PRI(기본키) / MUL(FK 인덱스)
FROM
  INFORMATION_SCHEMA.COLUMNS
WHERE
  TABLE_SCHEMA = 'shop'
ORDER BY
  TABLE_NAME,
  ORDINAL_POSITION;

DBeaver — INFORMATION_SCHEMA 조회

SELECT TABLE_NAME, COLUMN_NAME, DATA_TYPE, COLUMN_KEY FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_SCHEMA = 'shop' ORDER BY TABLE_NAME, ORDINAL_POSITION;

TABLE_NAME	COLUMN_NAME	DATA_TYPE	COLUMN_KEY
categories	category_id	int	PRI
categories	category_name	varchar
members	member_id	int	PRI
members	gender	char
order_items	order_id	int	PRI
order_items	product_id	int	PRI
orders	member_id	int	MUL
products	category_id	int	MUL
⋮

PRI = 기본키 │ MUL = FK 인덱스 — 관계 정보까지 다 들어 있습니다

17 rows fetched — 이 표를 그대로 AI에게 던지세요

이 결과(또는 방법 1의 CREATE TABLE 문)를 붙여넣으며 변환을 부탁합니다.

다음 테이블 구조를 더 간결한 형식으로 정리해줘:
- 테이블별 한 줄
- PK / FK 표시
- 부모-자식 관계 별도 블록

[추출 결과 붙여넣기]

이 3단계를 shop에 적용하면 이런 정리본이 나옵니다 — 그대로 저장해두세요.

[테이블 구조]
- members (회원): member_id PK, member_name, gender (M/F), age, joined_at (DATE)
- categories (카테고리): category_id PK, category_name
- products (상품): product_id PK, product_name, price (정수, 원), category_id FK → categories
- orders (주문): order_id PK, member_id FK → members, ordered_at (DATE)
- order_items (주문상세): (order_id FK, product_id FK) 복합 PK, quantity

[부모-자식 관계]
- members 1:N orders
- orders 1:N order_items
- products 1:N order_items
- categories 1:N products

[데이터 규모]
- members 20행, categories 5행, products 30행, orders 40행, order_items 64행

✓ 오늘의 숙제

본인 회사·프로젝트 DB를 AI가 알아들을 형식으로 한 번 정리해두세요. 그 정리본 하나만 있으면 — 앞으로 AI에게 SQL을 시키는 모든 작업이 빨라집니다.

자주 막히는 지점

① 회사 DB는 테이블이 수십 개인데 — 전부 줘야 하나요?

전부 주면 토큰만 낭비되고, AI가 엉뚱한 테이블을 끌어다 JOIN 하는 부작용도 생깁니다.

FIX ▸질문과 관련된 테이블만 추려서 주세요. 매출 질문이면 주문·상품 관련 테이블 정도 — 보통 5~10개면 충분합니다.

② 우리 팀 문서엔 mermaid ERD밖에 없어요

매번 mermaid를 주는 게 비효율이라는 뜻이지, 변환 재료로 쓰는 것까지 막을 이유는 없어요. 변환본을 저장해두고 그걸 재사용하세요.

FIX ▸mermaid를 AI에게 주면서 "이걸 텍스트 표(테이블별 한 줄, PK/FK 표시)로 변환해줘" — 변환용으로 한 번 주는 건 OK입니다.

③ 실무 DB라 FK 제약이 아예 안 걸려 있어요

성능 등의 이유로 FK 제약 없이 운영하는 DB가 실무에 꽤 많습니다. 이 경우 COLUMN_KEY에 MUL이 안 떠도 — 관계는 사람이 알고 있으니 직접 명시하면 됩니다.

FIX ▸아는 관계를 [부모-자식 관계] 블록에 직접 적어주세요. AI는 제약조건이 아니라 이 텍스트를 보고 JOIN 경로를 잡습니다.

스키마를 어떻게 전달하는지까지 챙겼으니, 다음은 프롬프트 전체입니다 — 같은 요구사항을 좋은 프롬프트와 나쁜 프롬프트로 각각 던지면 결과가 어떻게 달라지는지, 5-3에서 나란히 비교 분석합니다. 그 전에 연습 문제로 오늘 배운 포맷 변환을 손에 익혀보세요.

NEXT LESSON5-2 연습 문제

세 가지 포맷을 직접 변환해보며 — 텍스트 표 정리본 만들기를 손에 익힙니다.

GO ▸ 연습 문제 풀기

5-1 연습 문제 5-2 연습 문제