AI 코딩 에이전트가 데이터베이스 설계에서 자주 실패하는 이유

AI 코딩 에이전트는 점점 더 많은 개발 작업을 대신하고 있다.

이제 개발자는 Cursor, Claude Code, GitHub Copilot 같은 도구에 기능 요구사항을 설명하고, API 코드와 서비스 로직, 테스트 코드, 데이터베이스 스키마까지 한 번에 생성하게 할 수 있다.

간단한 기능을 만들 때는 매우 강력하다.

로그인 기능.

 게시판 기능.

 예약 기능.

 관리자 페이지.

 간단한 SaaS 백엔드.

이런 작업은 AI와 몇 번 대화하는 것만으로도 빠르게 시작할 수 있다.

하지만 데이터베이스 설계에서는 이야기가 조금 다르다.

AI는 스키마를 만들 수 있다.

 하지만 좋은 데이터베이스 구조를 설계하는 일은 단순히 테이블과 컬럼을 나열하는 일이 아니다.

그래서 중요한 질문은 이것이다.

AI 코딩 에이전트는 왜 데이터베이스 설계에서 자주 실패할까?

데이터베이스 설계는 코드 생성보다 맥락 의존적이다

코드는 비교적 작은 단위로 나누어 만들 수 있다.

함수 하나.

 API 핸들러 하나.

 폼 컴포넌트 하나.

 테스트 케이스 하나.

이런 작업은 입력과 출력이 비교적 명확하다. 요구사항이 충분히 좁으면 AI도 꽤 안정적으로 결과를 만든다.

하지만 데이터베이스 설계는 다르다.

데이터베이스는 기능 하나를 위한 코드가 아니라, 서비스 전체의 구조를 담는다.

사용자와 팀은 어떤 관계인가.

 프로젝트는 누가 소유하는가.

 권한은 사용자 단위인가, 팀 단위인가.

 결제는 주문과 분리되어야 하는가.

 초대받은 사용자는 언제부터 리소스에 접근할 수 있는가.

 삭제된 데이터는 정말 지워지는가, 아니면 복구 가능해야 하는가.

이런 질문은 코드 문법의 문제가 아니다.

제품의 규칙, 운영 방식, 팀의 판단, 앞으로의 확장 방향이 섞여 있는 문제다.

AI 코딩 에이전트가 데이터베이스 설계에서 자주 흔들리는 이유는 여기에 있다.

스키마는 만들 수 있지만, 그 스키마가 어떤 제품 맥락 위에서 오래 버텨야 하는지는 충분히 알기 어렵다.

AI는 이름을 잘 붙이지만, 관계를 항상 잘 이해하지는 못한다

AI가 만든 스키마를 보면 처음에는 꽤 그럴듯하다.

users 테이블이 있다.

 projects 테이블이 있다.

 tasks 테이블이 있다.

 comments 테이블이 있다.

이름만 보면 자연스럽다.

하지만 데이터베이스 설계에서 중요한 것은 테이블 이름보다 관계다.

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

 프로젝트는 팀에 속하는가, 사용자에게 직접 속하는가.

 태스크 담당자는 한 명인가, 여러 명인가.

 댓글은 태스크에만 달리는가, 프로젝트에도 달리는가.

 권한은 역할 테이블로 분리해야 하는가, 단순 enum으로 충분한가.

AI는 일반적인 패턴을 바탕으로 관계를 추론한다.

하지만 실제 제품의 관계는 일반적인 패턴만으로 결정되지 않는다. 같은 “프로젝트 관리 SaaS”라도 팀 협업 중심인지, 개인 생산성 중심인지, 클라이언트 협업이 포함되는지에 따라 구조가 달라진다.

AI는 가장 흔한 구조를 제안할 수 있다.

하지만 가장 흔한 구조가 지금 만들고 있는 제품에 맞는 구조라는 보장은 없다.

cardinality는 작은 차이처럼 보이지만 큰 문제를 만든다

데이터베이스 설계에서 1:1, 1:N, N:M 관계는 매우 중요하다.

하지만 AI가 만든 스키마에서는 이 관계가 애매하게 잡히는 경우가 많다.

예를 들어 사용자가 여러 조직에 속할 수 있는 서비스인데, AI가 users 테이블에 organization_id 하나만 넣을 수 있다. 처음에는 문제가 없어 보인다. 하지만 나중에 사용자가 여러 조직에 참여해야 하는 순간 구조가 막힌다.

반대로 단순히 하나의 소유자만 있으면 되는 리소스를 불필요하게 N:M 구조로 만들 수도 있다. 그러면 쿼리와 권한 처리가 불필요하게 복잡해진다.

cardinality는 처음에는 작은 설계 선택처럼 보인다.

하지만 나중에는 API 구조, 권한 모델, 화면 흐름, 테스트 케이스까지 영향을 준다.

AI가 이 부분에서 실패하는 이유는 단순하다.

관계의 수는 문법으로 정해지는 것이 아니라, 제품의 실제 사용 방식으로 정해지기 때문이다.

소유권과 권한은 AI가 특히 놓치기 쉽다

데이터베이스에서 소유권과 권한은 자주 과소평가된다.

누가 이 데이터를 만들었는가.

 누가 볼 수 있는가.

 누가 수정할 수 있는가.

 팀에서 나간 사용자는 과거 데이터에 접근할 수 있는가.

 초대받은 사용자는 어떤 범위까지 접근할 수 있는가.

 관리자는 모든 데이터를 볼 수 있는가, 일부만 볼 수 있는가.

이 질문들은 단순한 컬럼 추가로 끝나지 않는다.

소유권과 권한은 데이터 구조 전체에 영향을 준다.

그런데 AI가 만든 초기 스키마에서는 이런 부분이 단순화되는 경우가 많다.

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

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

 is_admin 같은 boolean 값으로 관리자 여부를 끝낸다.

초기에는 빠르다.

하지만 팀 협업, 공유 링크, 초대, 조직 관리, 감사 로그 같은 기능이 붙으면 구조가 금방 복잡해진다.

AI 코딩 에이전트는 기능 구현을 빠르게 도와주지만, 권한 모델이 나중에 어떻게 확장될지까지 안정적으로 예측하기는 어렵다.

그래서 AI가 만든 DB 구조를 검토할 때는 반드시 소유권과 권한을 따로 봐야 한다.

제약조건은 “나중에 추가하면 되는 것”이 아니다

AI가 만든 스키마에서 자주 빠지는 것 중 하나가 제약조건이다.

외래키.

 unique constraint.

 not null.

 check constraint.

 cascade rule.

 index.

 삭제 정책.

이런 요소는 처음에는 부가적인 세부사항처럼 보일 수 있다.

하지만 실제로는 데이터 품질을 지키는 장치다.

예를 들어 이메일이 유니크해야 하는데 unique constraint가 없다면, 애플리케이션 코드에서 아무리 조심해도 중복 데이터가 생길 수 있다.

삭제 정책이 불명확하면, 부모 데이터가 삭제될 때 자식 데이터를 어떻게 처리할지 매번 코드에서 따로 판단해야 한다.

외래키가 누락되면 관계가 문서나 코드 관습으로만 남고, 데이터베이스 자체는 구조를 보장하지 못한다.

AI는 종종 “동작하는 스키마”를 먼저 만든다.

하지만 좋은 데이터베이스 설계는 단순히 동작하는 것을 넘어, 잘못된 데이터가 들어오지 못하게 막아야 한다.

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

초기 구조를 신뢰할 수 있게 만드는 핵심이다.

AI는 현재 요구사항에 맞추지만, 변경 가능성은 약하게 본다

AI 코딩 에이전트는 주어진 요구사항에 빠르게 반응한다.

“게시판을 만들어줘.”

 “예약 시스템을 만들어줘.”

 “프로젝트 관리 SaaS 스키마를 만들어줘.”

이렇게 요청하면 AI는 현재 설명된 기능을 중심으로 스키마를 만든다.

하지만 데이터베이스 설계에서는 아직 말하지 않은 미래도 중요하다.

나중에 팀 기능이 붙을 수 있는가.

 결제가 붙을 수 있는가.

 권한이 세분화될 수 있는가.

 이력 관리가 필요해질 수 있는가.

 다국어나 멀티 리전 대응이 필요해질 수 있는가.

 외부 시스템 연동이 붙을 수 있는가.

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

하지만 아무 미래도 고려하지 않으면 금방 막힌다.

좋은 데이터베이스 설계는 현재 요구사항과 미래 변경 가능성 사이에서 균형을 잡는다.

AI는 현재 요구사항에 맞는 구조를 제안하는 데는 강하지만, “어디까지 열어두고 어디서 멈출지”를 판단하는 데는 아직 약하다.

이 판단은 기술 문제가 아니라 제품 감각과 운영 경험이 함께 필요한 영역이다.

AI가 만든 스키마는 설명이 부족하다

사람이 직접 설계한 데이터베이스에는 보통 설명할 수 있는 이유가 있다.

이 테이블은 왜 분리했는지.

 이 관계는 왜 1:N인지.

 이 값은 왜 enum이 아니라 별도 테이블인지.

 이 제약조건은 왜 필요한지.

 이 인덱스는 어떤 쿼리를 위한 것인지.

물론 사람이 만든 설계도 항상 좋은 것은 아니다.

하지만 적어도 작성자에게 물어볼 수 있다.

AI가 만든 스키마는 다르다.

결과는 있지만, 판단의 흔적은 약하다.

 테이블은 있지만, 왜 그렇게 나뉘었는지 불명확하다.

 관계는 있지만, 어떤 도메인 규칙을 반영한 것인지 설명이 부족하다.

그래서 AI가 만든 데이터베이스 구조를 검토할 때는 결과만 보지 말고, 설명을 끌어내야 한다.

왜 이 구조인가.

 어떤 가정이 들어갔는가.

 대안은 무엇인가.

 어떤 변경에 취약한가.

AI에게 다시 물어볼 수도 있고, 팀이 직접 검토할 수도 있다.

중요한 것은 스키마를 “생성된 결과물”로만 두지 않는 것이다.

이해 가능한 설계로 바꿔야 한다.

실패는 문법 오류가 아니라 구조적 비용으로 나타난다

AI가 데이터베이스 설계에서 실패해도, 그 실패는 즉시 보이지 않을 수 있다.

SQL 문법이 맞으면 마이그레이션은 실행된다.

 테이블이 만들어지면 API도 붙일 수 있다.

 데이터가 저장되면 화면도 동작한다.

그래서 처음에는 문제가 없어 보인다.

하지만 시간이 지나면 다른 형태로 나타난다.

권한 예외가 계속 늘어난다.

 쿼리가 점점 복잡해진다.

 테이블 책임이 섞여서 변경이 어려워진다.

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

 테스트 데이터는 만들기 어려워지고, 버그는 재현하기 어려워진다.

이것은 데이터베이스 영역의 AI Coding Debt다.

빠르게 만들어졌고, 처음에는 맞아 보였지만, 충분히 검토되지 않은 구조가 나중에 비용으로 돌아오는 것이다.

AI가 만든 스키마를 검토해야 하는 이유는 단순히 “더 좋은 설계”를 위해서가 아니다.

나중에 갚아야 할 비용을 줄이기 위해서다.

AI 코딩 에이전트를 쓰지 말자는 말이 아니다

AI 코딩 에이전트가 데이터베이스 설계에서 자주 실패한다는 말은, AI를 쓰지 말자는 뜻이 아니다.

오히려 반대에 가깝다.

AI는 초안을 만드는 데 매우 유용하다.

아이디어를 빠르게 구조화할 수 있다.

 놓친 테이블 후보를 제안할 수 있다.

 SQL이나 ORM 모델을 빠르게 작성할 수 있다.

 기존 스키마를 설명하게 할 수도 있다.

 대안 구조를 비교해보는 데도 도움이 된다.

문제는 AI가 만든 첫 구조를 그대로 최종 설계로 믿는 것이다.

AI는 설계자의 대체재라기보다 설계 초안을 빠르게 만들어주는 도구에 가깝다.

좋은 팀은 AI가 만든 결과를 버리지 않는다.

하지만 그대로 믿지도 않는다.

이해하고, 질문하고, 검토하고, 수정한다.

좋은 사용법은 생성보다 검토에 있다

AI 코딩 에이전트를 데이터베이스 설계에 잘 쓰려면, 프롬프트를 던지고 결과를 받는 데서 끝나면 안 된다.

오히려 중요한 작업은 그 다음부터다.

AI에게 가정을 설명하게 한다.

 테이블 간 관계를 다시 정리하게 한다.

 권한과 소유권 모델을 따로 검토하게 한다.

 누락된 제약조건을 찾게 한다.

 N:M 관계가 필요한 곳을 확인하게 한다.

 삭제, 복구, 변경 이력 정책을 점검하게 한다.

 미래 확장 시나리오에서 구조가 버티는지 물어본다.

즉, AI를 “생성기”로만 쓰지 않고 “검토 파트너”로 써야 한다.

하지만 그 검토가 제대로 되려면 사람이 먼저 구조를 이해할 수 있어야 한다.

SQL만으로는 부족할 수 있다.

 코드만으로는 전체 관계가 잘 보이지 않을 수 있다.

 AI의 설명만으로는 충분하지 않을 수 있다.

그래서 AI가 만든 데이터베이스 구조는 사람이 보고 판단할 수 있는 형태로 바뀌어야 한다.

다음 개발 경쟁력은 AI를 믿는 능력이 아니라 검토하는 능력이다

AI 코딩 에이전트는 앞으로 더 좋아질 것이다.

더 긴 맥락을 읽고, 더 많은 파일을 수정하고, 더 정교한 코드를 만들 것이다. 데이터베이스 설계도 지금보다 훨씬 나아질 것이다.

하지만 그렇다고 검토가 사라지지는 않는다.

오히려 결과물이 더 그럴듯해질수록, 무엇이 맞고 무엇이 위험한지 판단하는 능력은 더 중요해진다.

AI가 만든 스키마를 빠르게 받아들이는 팀과, AI가 만든 스키마를 제대로 이해하고 검토하는 팀은 시간이 지나며 다른 결과를 맞게 된다.

처음에는 둘 다 빨라 보일 수 있다.

하지만 몇 달 뒤에는 코드베이스의 복잡도, 권한 처리의 안정성, 기능 확장 속도, 버그 수정 비용에서 차이가 난다.

AI 시대의 데이터베이스 설계에서 중요한 것은 AI를 무조건 믿는 능력이 아니다.

AI가 만든 구조를 이해하고, 의심하고, 필요한 곳을 고치는 능력이다.

AI 코딩 에이전트가 만든 데이터베이스는 출발점일 수 있다. 하지만 좋은 설계가 되려면, 반드시 사람의 검토를 통과해야 한다.