AI가 만든 스키마를 리뷰하는 체크리스트

AI 코딩 도구는 데이터베이스 스키마를 빠르게 만들어준다.

요구사항을 입력하면 테이블을 제안하고, 컬럼을 만들고, 외래키를 연결하고, SQL DDL이나 ORM 모델, 마이그레이션 코드까지 생성한다. 간단한 서비스라면 몇 분 안에 꽤 그럴듯한 초안이 나온다.

이 속도는 분명히 강력하다.

하지만 빠르게 만들어진 스키마가 곧 좋은 스키마라는 뜻은 아니다.

AI가 만든 스키마는 시작점일 수 있다.

 하지만 그대로 제품에 반영하기 전에는 반드시 검토해야 한다.

중요한 질문은 이것이다.

AI가 만든 데이터베이스 스키마를 리뷰할 때 무엇을 봐야 할까?

1. 핵심 엔티티가 명확한가

가장 먼저 볼 것은 테이블 개수가 아니다.

핵심 엔티티가 무엇인지 봐야 한다.

사용자.

 조직.

 프로젝트.

 주문.

 결제.

 권한.

 콘텐츠.

 이벤트.

서비스마다 중심이 되는 데이터가 있다. 좋은 스키마는 이 핵심 엔티티가 명확하다.

AI가 만든 스키마는 종종 필요한 테이블을 많이 만들어내지만, 어떤 테이블이 서비스의 중심인지 흐릿할 때가 있다. 테이블 이름은 많지만 구조의 중심이 보이지 않으면, 이후 기능이 붙을수록 설계가 흔들릴 수 있다.

리뷰할 때는 먼저 물어봐야 한다.

• 이 서비스의 핵심 엔티티는 무엇인가?
• 각 핵심 엔티티가 별도 테이블로 잘 표현되어 있는가?
• 너무 많은 개념이 하나의 테이블에 섞여 있지 않은가?
• 반대로 하나로 충분한 개념이 불필요하게 쪼개져 있지 않은가?

스키마 리뷰는 컬럼을 보기 전에 엔티티를 보는 일에서 시작한다.

2. 테이블의 책임이 분리되어 있는가

좋은 테이블은 책임이 명확하다.

users는 사용자 정보를 담는다.

 teams는 팀 정보를 담는다.

 projects는 프로젝트 정보를 담는다.

 project_members는 프로젝트와 멤버의 관계를 담는다.

이처럼 테이블마다 맡은 역할이 분명해야 한다.

AI가 만든 스키마에서는 한 테이블이 너무 많은 책임을 갖는 경우가 있다. 예를 들어 users 테이블에 프로필 정보, 권한 정보, 결제 정보, 조직 정보, 초대 상태가 모두 섞일 수 있다.

처음에는 편해 보인다.

하지만 시간이 지나면 문제가 된다.

컬럼이 계속 늘어난다.

 nullable 값이 많아진다.

 특정 기능만을 위한 예외 컬럼이 생긴다.

 한 테이블을 수정할 때 여러 기능이 함께 영향을 받는다.

반대로 너무 잘게 나눠도 문제다. 단순한 상태값 하나를 별도 테이블로 만들거나, 초기 제품에 필요 없는 복잡한 관계 테이블을 만들면 쿼리와 로직이 불필요하게 복잡해진다.

리뷰할 때는 이렇게 물어봐야 한다.

• 이 테이블은 하나의 명확한 책임을 갖는가?
• 서로 다른 도메인 개념이 한 테이블에 섞여 있지 않은가?
• 불필요하게 잘게 쪼개진 테이블은 없는가?
• 나중에 컬럼이 계속 늘어날 위험이 있는 테이블은 없는가?

AI가 만든 스키마에서 가장 흔한 문제 중 하나는 “동작은 하지만 책임이 흐릿한 테이블”이다.

3. 관계가 실제 도메인 규칙과 맞는가

데이터베이스 설계의 핵심은 관계다.

테이블 이름과 컬럼은 비교적 쉽게 만들 수 있다. 하지만 테이블 사이의 관계가 실제 제품 규칙과 맞는지는 별개의 문제다.

사용자는 여러 팀에 속할 수 있는가.

 팀은 여러 프로젝트를 가질 수 있는가.

 프로젝트는 여러 명의 관리자를 가질 수 있는가.

 댓글은 게시글에만 달리는가, 파일이나 태스크에도 달리는가.

 결제는 주문과 1:1인가, 여러 번 나뉘어 처리될 수 있는가.

이 질문들은 단순한 기술 문제가 아니다.

제품의 동작 방식이다.

AI는 일반적인 패턴을 바탕으로 관계를 제안한다. 하지만 일반적인 관계가 지금 만들고 있는 제품의 관계와 같지는 않다.

리뷰할 때는 모든 주요 관계에 대해 확인해야 한다.

• 이 관계는 실제 서비스 규칙과 일치하는가?
• 관계가 빠진 테이블은 없는가?
• 불필요한 관계가 추가된 곳은 없는가?
• 관계가 코드 관습으로만 존재하고 DB에는 표현되지 않은 곳은 없는가?
• 관계를 설명했을 때 PM, 디자이너, 개발자가 같은 의미로 이해하는가?

관계가 틀리면 이후 코드는 계속 우회로를 만들게 된다.

4. Cardinality가 올바른가

1:1, 1:N, N:M 관계는 작은 차이처럼 보이지만, 실제로는 큰 차이를 만든다.

예를 들어 사용자가 하나의 조직에만 속할 수 있는지, 여러 조직에 속할 수 있는지에 따라 구조가 완전히 달라진다.

users.organization_id 하나로 충분한 경우도 있다.

 하지만 여러 조직에 속해야 한다면 organization_members 같은 관계 테이블이 필요하다.

태스크 담당자도 마찬가지다.

담당자가 한 명이면 assignee_id로 충분할 수 있다.

 하지만 여러 명이 담당할 수 있다면 별도의 관계 테이블이 필요하다.

AI가 만든 스키마는 이 부분을 자주 단순화한다. 가장 흔한 구조를 제안하거나, 반대로 불필요하게 복잡한 관계를 만들기도 한다.

리뷰할 때는 다음 질문을 던져야 한다.

• 이 관계는 1:1인가, 1:N인가, N:M인가?
• 지금은 1:N처럼 보이지만 곧 N:M이 될 가능성은 없는가?
• N:M 관계가 필요한데 단일 외래키로 처리된 곳은 없는가?
• 단순한 1:N 관계인데 과하게 관계 테이블을 만든 곳은 없는가?
• cardinality가 바뀌면 어떤 API와 화면이 영향을 받는가?

Cardinality는 나중에 바꾸기 어렵다.

그래서 AI가 만든 스키마에서 가장 먼저 확인해야 할 항목 중 하나다.

5. 외래키가 누락되지 않았는가

AI가 만든 스키마에는 테이블 이름과 컬럼은 있는데, 외래키가 충분히 명시되지 않는 경우가 있다.

예를 들어 project_id, user_id, team_id 같은 컬럼은 있지만 실제 foreign key constraint가 빠져 있을 수 있다.

이러면 애플리케이션 코드에서는 관계처럼 보이지만, 데이터베이스는 그 관계를 보장하지 않는다.

문제는 나중에 생긴다.

존재하지 않는 사용자를 참조하는 데이터가 생긴다.

 삭제된 프로젝트에 연결된 태스크가 남는다.

 관계가 끊어진 데이터가 쌓인다.

 데이터 정합성을 애플리케이션 코드가 전부 책임져야 한다.

리뷰할 때는 주요 관계마다 확인해야 한다.

• 외래키가 필요한 곳에 실제 FK constraint가 있는가?
• 의도적으로 FK를 두지 않은 곳이라면 이유가 명확한가?
• 부모 데이터가 삭제될 때 자식 데이터는 어떻게 되는가?
• 관계가 끊긴 orphan record가 생길 가능성은 없는가?
• DB가 보장해야 할 관계를 애플리케이션 코드에만 맡기고 있지 않은가?

모든 곳에 무조건 FK를 걸어야 한다는 뜻은 아니다.

하지만 FK가 없는 관계는 반드시 이유가 있어야 한다.

6. Unique, Not Null, Check 조건이 충분한가

좋은 스키마는 잘못된 데이터가 들어오는 것을 막는다.

AI가 만든 스키마는 동작하는 구조는 만들지만, 데이터 품질을 지키는 제약조건을 놓칠 때가 있다.

예를 들어 이메일은 유니크해야 할 수 있다.

 팀 안에서 프로젝트 이름은 중복되면 안 될 수 있다.

 가격은 음수가 되면 안 된다.

 상태값은 정해진 값 중 하나여야 한다.

 필수 컬럼은 null이 되면 안 된다.

이런 규칙을 애플리케이션 코드에서만 처리하면 위험하다.

코드 경로가 여러 개가 되면 누락될 수 있다.

 관리자 도구나 배치 작업에서 우회될 수 있다.

 마이그레이션이나 외부 연동에서 잘못된 값이 들어올 수 있다.

리뷰할 때는 다음을 확인해야 한다.

• 유니크해야 하는 값에 unique constraint가 있는가?
• 필수 값에 not null이 설정되어 있는가?
• 허용 범위가 있는 값에 check constraint가 필요한가?
• 상태값을 enum으로 둘지, 별도 테이블로 둘지 기준이 있는가?
• DB가 막아야 할 데이터 오류를 코드에만 맡기고 있지 않은가?

제약조건은 나중에 붙이는 장식이 아니다.

스키마의 신뢰도를 만드는 핵심이다.

7. 인덱스가 실제 조회 패턴과 맞는가

AI가 만든 스키마에는 인덱스가 없거나, 일반적인 기준으로만 붙어 있을 수 있다.

하지만 인덱스는 컬럼이 중요해 보인다고 붙이는 것이 아니다.

실제 조회 패턴과 맞아야 한다.

사용자별 프로젝트 목록을 자주 조회하는가.

 팀별 멤버 목록을 자주 조회하는가.

 상태별 주문 목록을 자주 필터링하는가.

 생성일 기준 정렬이 많은가.

 복합 조건 검색이 필요한가.

이런 질문에 따라 인덱스가 달라진다.

AI는 요구사항에 명시되지 않은 조회 패턴을 안정적으로 알기 어렵다. 그래서 인덱스가 과소 설계되거나, 반대로 의미 없는 인덱스가 붙을 수 있다.

리뷰할 때는 이렇게 확인해야 한다.

• 자주 조회되는 조건은 무엇인가?
• foreign key 컬럼에 인덱스가 필요한가?
• 정렬과 필터 조건이 함께 쓰이는 쿼리는 무엇인가?
• 복합 인덱스가 필요한 곳은 없는가?
• 쓰기 성능을 해칠 만큼 과한 인덱스는 없는가?

초기 단계에서 모든 인덱스를 완벽하게 잡을 필요는 없다.

하지만 주요 조회 흐름을 전혀 고려하지 않은 스키마는 나중에 성능 문제로 돌아올 수 있다.

8. 삭제, 복구, 변경 이력을 고려했는가

AI가 만든 스키마는 CRUD를 기준으로 단순하게 설계되는 경우가 많다.

생성한다.

 조회한다.

 수정한다.

 삭제한다.

하지만 실제 제품에서는 삭제가 그렇게 단순하지 않다.

정말 데이터를 지워도 되는가.

 사용자에게는 삭제된 것처럼 보이지만 내부적으로는 보관해야 하는가.

 복구가 필요한가.

 감사 로그가 필요한가.

 변경 이력을 추적해야 하는가.

 법적 보관 기간이 있는가.

이 질문을 놓치면 나중에 구조 변경 비용이 커진다.

예를 들어 deleted_at이 필요한 서비스인데 물리 삭제만 고려했다면, 나중에 복구 기능이나 감사 기능을 붙이기 어렵다.

상태 변경 이력이 중요한 서비스인데 현재 상태만 저장하면, 나중에 “언제 누가 무엇을 바꿨는지” 알 수 없다.

리뷰할 때는 다음을 확인해야 한다.

• 삭제는 hard delete인가, soft delete인가?
• 복구가 필요한 데이터인가?
• 변경 이력을 남겨야 하는가?
• 누가 변경했는지 추적해야 하는가?
• audit log가 필요한가?
• 개인정보나 민감 데이터의 보관 정책은 고려되었는가?

AI가 만든 스키마는 현재 기능 중심으로 잘 작동할 수 있다.

하지만 운영 조건을 놓치면 실제 서비스에서는 부족할 수 있다.

9. 권한과 소유권이 구조에 반영되어 있는가

권한은 나중에 붙이는 기능이 아니다.

데이터 구조 안에 들어가야 하는 핵심 규칙이다.

누가 이 리소스를 소유하는가.

 누가 볼 수 있는가.

 누가 수정할 수 있는가.

 팀 단위 권한인가, 프로젝트 단위 권한인가.

 역할은 전역 역할인가, 특정 공간 안에서만 유효한 역할인가.

AI가 만든 스키마에서는 이 부분이 자주 단순화된다.

user_id 하나로 소유자를 표시한다.

 role 컬럼 하나로 권한을 처리한다.

 is_admin 하나로 관리자 여부를 끝낸다.

하지만 실제 제품에서는 더 복잡해질 수 있다.

사용자가 여러 팀에 속할 수 있다.

 팀마다 다른 역할을 가질 수 있다.

 프로젝트마다 권한이 다를 수 있다.

 초대 중인 사용자가 있을 수 있다.

 공유 링크나 외부 협업자가 생길 수 있다.

리뷰할 때는 다음을 봐야 한다.

• 소유권이 명확하게 표현되어 있는가?
• 권한 범위가 사용자, 팀, 프로젝트 중 어디에 걸려 있는가?
• 한 사용자가 여러 역할을 가질 수 있는가?
• 초대, 탈퇴, 비활성화 상태가 고려되었는가?
• 관리자 권한이 너무 단순하게 처리되어 있지 않은가?
• 권한 검사가 애플리케이션 코드에만 흩어져 있지 않은가?

권한 모델이 약하면 기능이 늘어날수록 예외가 많아진다.

그리고 예외가 많아진 권한 모델은 나중에 가장 고치기 어려운 부분 중 하나가 된다.

10. 확장 가능성과 과설계 사이의 균형이 맞는가

스키마를 리뷰할 때 미래를 고려해야 한다.

하지만 모든 미래를 미리 반영하면 과설계가 된다.

이 균형이 중요하다.

AI가 만든 스키마는 두 방향으로 모두 실패할 수 있다.

너무 단순해서 금방 막힐 수 있다.

 또는 너무 일반화되어 초기 제품에 비해 과하게 복잡할 수 있다.

예를 들어 당장 개인 사용자만 필요한 제품인데 처음부터 복잡한 조직, 팀, 역할, 권한 구조를 모두 넣으면 개발 속도가 느려진다.

반대로 가까운 미래에 팀 기능이 필요한 제품인데 사용자 단일 소유 구조로만 설계하면 곧 구조를 갈아엎어야 한다.

리뷰할 때는 이렇게 물어봐야 한다.

• 가까운 미래에 추가될 가능성이 높은 기능은 무엇인가?
• 지금 반드시 열어둬야 하는 확장 지점은 어디인가?
• 지금은 단순하게 유지해도 되는 부분은 어디인가?
• 과하게 일반화된 테이블이나 관계는 없는가?
• 나중에 바꾸기 어려운 결정을 너무 빨리 고정하지 않았는가?

좋은 스키마는 모든 미래를 예측하지 않는다.

하지만 바꾸기 어려운 부분은 신중하게 결정한다.

체크리스트는 속도를 늦추는 장치가 아니다

AI가 만든 스키마를 리뷰하는 일은 개발을 늦추기 위한 절차가 아니다.

오히려 반대다.

잘못된 구조 위에 빠르게 코드를 쌓으면, 처음에는 빨라 보여도 나중에 더 느려진다.

API가 꼬인다.

 권한 예외가 늘어난다.

 쿼리가 복잡해진다.

 테스트가 어려워진다.

 기능을 추가할 때마다 기존 구조와 충돌한다.

이것은 데이터베이스 영역에서 드러나는 AI Coding Debt다.

빠르게 만들어졌고, 그럴듯해 보였지만, 충분히 검토되지 않은 구조가 시간이 지나 비용으로 돌아오는 것이다.

AI가 만든 스키마는 좋은 출발점이 될 수 있다.

하지만 좋은 출발점이 좋은 설계가 되려면 리뷰가 필요하다.

엔티티를 확인하고, 관계를 검토하고, 제약조건을 점검하고, 권한과 소유권을 따져보고, 변경 가능성을 생각해야 한다.

AI 시대의 데이터베이스 리뷰는 무거운 절차가 아니다.

빠르게 만든 구조를 실제 제품에 넣어도 되는 구조로 바꾸는 과정이다.