물리 모델 품질과 구현 가능성 검토

핵심 요약

물리 모델은 DDL이 문법적으로 실행된다고 완성되는 것이 아니다. 논리-물리 매핑, 명명·타입, 키·제약, 관계 선택성, 이력 경계, 인덱스·저장 고려, 보안·보존, 전환·배포 가능성, 모델과 실제 DDL의 일치를 점검해야 한다. 특히 모델 문서에는 존재하지만 DDL에서 빠진 UK·FK·CHECK, 또는 DDL에만 추가된 컬럼·인덱스는 추적성 결함이다.

학습 목표

• 물리 모델 품질 기준과 논리 모델 품질의 차이를 설명한다.
• DBMS 데이터 타입·제약·명명·키·인덱스·DDL을 체크리스트로 검증한다.
• 핵심 SQL·데이터 규모·배포 시나리오로 구현 가능성을 판정한다.
• 모델·DDL·운영 객체 사이의 불일치를 찾아 수정한다.

1. 품질 검토 영역

1.1 논리 규칙 보존

• 모든 논리 엔터티·속성·식별자·관계에 물리 대응이 있는가?
• 주식별자뿐 아니라 대체식별자의 유일성이 구현되었는가?
• 필수 속성·관계가 NOT NULL과 FK로 일치하는가?
• 도메인 범위·코드·기간 경계·업무 규칙이 CHECK·FK·서비스 통제로 구현되는가?
• 구현하지 못한 규칙은 책임 시스템과 검증 방법이 문서화되었는가?

1.2 명명과 데이터 타입

타입 변환은 현재 데이터뿐 아니라 최대값·증가량·외부 연계·계산 결과를 포함해 검증한다.

1.3 키·제약·관계

• PK 컬럼이 최소·안정·필수이며 실제 생성 방식이 있는가?
• UK가 NULL을 포함할 때 DBMS별 중복 처리 차이를 고려했는가?
• FK 컬럼의 수·순서·타입이 부모 키와 일치하는가?
• 삭제·변경 동작이 업무 생명주기와 맞는가?
• 1:1 관계에 유일성 제약이 있는가?
• 복합 FK 일부 NULL, 자기참조 순환, 기간 중복 같은 예외를 검토했는가?

1.4 접근·저장 구조의 적정성

• 핵심 SQL 조건·조인·정렬과 인덱스 후보가 연결되는가?
• 중복·미사용 인덱스가 DML 비용을 과도하게 늘리지 않는가?
• 대용량 객체의 행 길이·증가·보존·유지보수 창을 고려했는가?
• 파티션 필요성은 데이터 생명주기와 접근 범위 근거로 검토되었는가?
• LOB·임시 작업·인덱스·로그 증가가 용량에 반영되었는가?

이 단원은 “고려 여부와 구현 가능성”을 검토하며 파티션·성능 튜닝의 세부 기법은 후속 범위에 둔다.

1.5 보안·운영·배포 가능성

• 민감정보 컬럼의 접근·마스킹·암호화 요구와 타입·인덱스가 충돌하지 않는가?
• 보존 만료 데이터의 삭제·아카이빙이 FK 구조에서 가능한가?
• 대용량 DDL이 허용 배포창 안에 실행되는가?
• 제약·인덱스 생성 순서와 초기 적재·검증 전략이 있는가?
• 롤백·하위 호환·복제 지연·백업 영향이 검토되었는가?

2. 물리 모델 검토 체크리스트

3. 검토 절차

논리-물리 매핑 완전성 검사
  ↓
명명·타입·NULL·기본값 정적 검사
  ↓
PK·UK·FK·CHECK 및 업무 통제 검사
  ↓
핵심 SQL·데이터량으로 접근·용량 검증
  ↓
전환·배포·보안·보존 시나리오 리허설
  ↓
모델 ↔ DDL ↔ 실제 DB 카탈로그 대조
  ↓
예외 승인·기술부채·개선기한 기록

자동 규칙 검사로 이름·타입·제약 누락을 빠르게 찾고, 사람의 시나리오 검토로 업무 의미와 운영 가능성을 확인한다.

4. DDL 불일치 사례

논리 규칙:

• 사용자 이메일은 필수이며 유일하다.
• 주문은 반드시 사용자에 속한다.
• 주문금액은 0 이상이다.

물리 DDL(아래 문법은 개념 설명용이며 데이터 타입·제약 문법은 DBMS별로 다를 수 있다):

CREATE TABLE APP_USER (
  USER_ID BIGINT PRIMARY KEY,
  EMAIL VARCHAR(200)
);

CREATE TABLE ORDERS (
  ORDER_ID BIGINT PRIMARY KEY,
  USER_ID BIGINT,
  ORDER_AMOUNT DECIMAL(15,2)
);

결함:

1. EMAIL의 NOT NULL과 유일성 제약 누락
2. ORDERS.USER_ID의 NOT NULL과 FK 누락
3. ORDER_AMOUNT의 0 이상 CHECK 누락
4. 모델에는 관계가 있지만 DDL은 고립 주문을 허용

보완 예:

CREATE TABLE APP_USER (
  USER_ID BIGINT PRIMARY KEY,
  EMAIL VARCHAR(200) NOT NULL,
  CONSTRAINT UK_APP_USER_EMAIL UNIQUE (EMAIL)
);

CREATE TABLE ORDERS (
  ORDER_ID BIGINT PRIMARY KEY,
  USER_ID BIGINT NOT NULL,
  ORDER_AMOUNT DECIMAL(15,2) NOT NULL,
  CONSTRAINT FK_ORDERS_USER FOREIGN KEY (USER_ID)
    REFERENCES APP_USER(USER_ID),
  CONSTRAINT CK_ORDERS_AMOUNT CHECK (ORDER_AMOUNT >= 0)
);

실제 제품에서는 이메일 대소문자·정규화·조건부 유일성 의미를 추가 검토한다.

5. 구현 가능성 사례

테이블 5억 건에 NOT NULL 컬럼과 기본값을 한 번에 추가하려 한다. 논리적으로 필요한 변경이라도 다음을 확인해야 한다.

• 기존 행 채움(backfill) 시간과 로그량
• 온라인 DDL 지원 여부와 잠금 수준
• 복제·백업·스토리지 증가
• 애플리케이션의 구버전/신버전 동시 동작
• 단계적 배포: nullable 컬럼 추가→채움→검증→NOT NULL 전환
• 실패 시 롤백과 재시도

물리 품질에는 최종 구조뿐 아니라 안전하게 그 구조에 도달할 수 있는지도 포함된다.

6. 논리 품질과 물리 품질 비교

시험 판단 포인트

• DDL 실행 성공은 물리 모델 품질의 필요조건일 뿐 충분조건이 아니다.
• 논리 모델의 대체식별자·필수 관계·도메인 규칙이 물리 제약에서 누락되기 쉽다.
• 모델, DDL, 실제 DB 객체의 세 방향 일치성을 확인한다.
• 제품 제약과 배포창 때문에 최종 구조의 단계적 구현이 필요할 수 있다.
• 물리 모델 품질은 성능뿐 아니라 무결성·운영·보안·전환 가능성을 포함한다.

자주 틀리는 부분

• PK만 존재하면 모든 업무 유일성이 보장된다고 본다.
• FK를 성능 저하 원인으로만 보고 문서 없이 제거한다.
• 모델에 정의된 NULL·기본값과 DDL의 실제 설정을 대조하지 않는다.
• 개발 환경의 빈 테이블 DDL 성공을 운영 대용량 배포 가능성으로 판단한다.
• 물리 모델에 없는 운영 인덱스·컬럼을 임의 추가하고 추적성을 갱신하지 않는다.