ERFit · Technical Playbook

AI 코딩 에이전트로 데이터베이스 스키마를 설계·검토하는 방법

Database Schema Design for AI Coding Agents

AI 코딩 에이전트가 새 기능의 테이블·관계·제약조건을 제안할 때 업무 규칙, 기존 DB 구조, DDL과 마이그레이션을 어떻게 대조하고 검토할지 설명합니다.

ERFitDATABASE DESIGN04 STEPS
  1. 01
    현행 파악스키마·마이그레이션·API 대조
  2. 02
    업무 정의행·키·NULL·보존 의미 결정
  3. 03
    설계 제안모델·DDL·가정 구분
  4. 04
    격리 검증데이터 보존과 전환 경계 확인
Technical playbook · conceptual sequence
에이전트 코딩DB 스키마 설계마이그레이션 검토

nexFLOW 기술 가이드 · · 적용 방법론

개요

에이전트 코딩으로 주문, 회원, 결제 같은 기능을 구현할 때 SQL 파일을 먼저 만들면 놓치기 쉬운 문제가 있습니다. 한 행의 의미, 참조 대상, NULL과 기본값, 삭제 후 보존 정책이 정해지지 않으면 그럴듯한 테이블도 실제 업무와 어긋납니다. 이 가이드는 코딩 에이전트의 DB 설계 제안을 검토 가능한 변경안으로 만드는 절차입니다.

기존 스키마와 마이그레이션, 애플리케이션의 읽기·쓰기 경로를 먼저 확인하고, 새 기능의 불변조건을 적습니다. 에이전트에게는 확인된 사실과 미확인 가정을 구분하도록 요청한 다음 엔터티, 키, 관계, 제약조건, 전환 방법을 검토합니다. 데이터 모델을 그림으로 표현하는 일과 운영 DB에 DDL을 적용하는 일은 서로 다른 단계입니다.

ERFit으로 논리·물리 모델과 역공학 결과를 검토하고, ContextMeta로 의미·표준·품질 기준을 대조합니다. 아래 고객·주문 구조는 가상 예시입니다.

활용 목표

기존 DB와 충돌하지 않는 변경 범위 정리
키·관계·NULL·보존 규칙을 코드 생성 전에 검토
DDL·마이그레이션과 애플리케이션 변경을 함께 확인

적용 절차

1

기존 구조와 코드의 사실 수집

코딩 에이전트에게 현재 테이블·컬럼·PK·FK·인덱스·제약조건과 최근 migration을 먼저 읽게 합니다. 관련 API가 INSERT·UPDATE·DELETE 시 어떤 값을 사용하는지도 대조합니다. 컬럼 이름에서 유추한 의미는 확인된 업무 규칙으로 취급하지 않습니다.

2

한 행의 의미와 불변조건 명시

예를 들어 주문 한 행이 주문 시점의 스냅샷인지 현재 고객 상태의 반영인지 결정합니다. 고객을 삭제했을 때 주문을 보존하는지, customer_id가 NULL일 수 있는지, 상태 변경의 주체와 금액 단위가 무엇인지 확인받습니다. 모르는 사항은 생성 코드에 임의 기본값을 넣는 대신 질문으로 남깁니다.

3

에이전트에게 설계안과 근거 요청

아래는 제품별 명령이나 MCP 도구 호출이 아닌 자연어 요청 예시입니다. 실제 저장소와 DBMS에 맞게 조정하고, 운영 데이터·자격증명을 프롬프트에 넣지 않습니다.

text
가상 주문 기능의 DB 설계를 검토해줘.
1. 현재 schema-only 구조, 관련 migration, 주문/회원 API의 읽기·쓰기 경로를 먼저 정리해줘.
2. 확인된 사실·추정·담당자에게 물어볼 업무 규칙을 구분해줘.
3. 고객과 주문의 PK/FK, UNIQUE, NULL, 기본값, 금액 단위, 삭제·보존 정책을 제안하고 근거를 밝혀줘.
4. 대상 DBMS에 맞는 DDL 변경안과 기존 행 처리·인덱스·롤백 검토 사항을 따로 제시해줘.
5. SQL을 실행하거나 운영 DB를 수정하지 말고 사람의 검토를 기다려줘.
4

DDL과 모델의 일치 여부 검토

PostgreSQL 예시의 PK·FK를 확인하고, 실제 설계의 금액 단위·삭제 정책·인덱스·트랜잭션 경계와 대조합니다.

sql
-- 가상 설계 예시 · 실제 운영 DB에 실행하지 마세요.
CREATE TABLE customer (
  customer_id BIGINT PRIMARY KEY
);

CREATE TABLE orders (
  order_id BIGINT PRIMARY KEY,
  customer_id BIGINT NOT NULL REFERENCES customer(customer_id)
);
5

격리 검증 후 변경 범위 결정

기존 데이터가 있는 복원본에서 migration을 검증하고, 구조 전후의 행·제약·거래 금액 보존을 확인합니다. 애플리케이션의 새 코드와 이전 코드가 전환 시점에 어떤 스키마를 요구하는지 대조한 뒤 사람의 승인에 따라 적용합니다. ERFit 모델의 Apply나 파일 저장은 운영 DB에 SQL을 적용하는 절차가 아닙니다.

업무 흐름

1

현행 파악

스키마·마이그레이션·API 대조

2

업무 정의

행·키·NULL·보존 의미 결정

3

설계 제안

모델·DDL·가정 구분

4

격리 검증

데이터 보존과 전환 경계 확인

적용 범위와 한계

  • 에이전트가 생성한 DDL만으로 기존 데이터의 의미·개인정보 보유 정책·성능이 검증되지는 않습니다.
  • 가상 SQL은 DBMS별 마이그레이션 템플릿이나 바로 적용할 수 있는 운영 스크립트가 아닙니다.
  • ERFit의 모델 변경·저장은 운영 DB의 DDL 자동 실행 또는 Repository 업로드를 의미하지 않습니다.

자주 묻는 질문

AI 코딩 에이전트에게 DB 테이블 설계를 바로 맡겨도 되나요?

초안을 요청할 수 있지만, 기존 스키마와 코드에서 확인한 사실 및 업무 담당자에게 확인할 규칙을 먼저 분리하세요. PK·FK·NULL·보존·기존 행 전환 방식은 검토 후 확정해야 합니다.

ERFit의 MCP로 만든 모델을 Apply하면 운영 DB도 바뀌나요?

아닙니다. 연결된 ERFit 모델의 변경과 실제 DB에 대한 DDL 적용은 별개입니다. 결과를 검토하고 모델 파일을 저장한 뒤, DB 적용은 백업·복원 검증과 별도 배포 절차를 따르세요.

기존 DB에서 ERD를 먼저 만들고 싶다면 어디서 시작하나요?

기존 SQL이나 DB 구조에서 모델을 만드는 DB 역공학 가이드를 참고하세요. 추출된 관계와 코드·업무 문서에서 확인한 의미를 구분해야 합니다.