AI 시대에도 ERD가 여전히 필요한 이유

AI 코딩 도구는 소프트웨어 개발의 시작 방식을 바꾸고 있다.

이제 개발자는 자연어로 요구사항을 설명하고, AI에게 데이터베이스 스키마, API, 서비스 로직, 마이그레이션 코드까지 빠르게 만들게 할 수 있다.

예전에는 며칠이 걸리던 초기 구조가 몇 번의 대화로 만들어지기도 한다.

이 변화는 분명히 강력하다.

하지만 구조가 더 빨리 만들어질수록, 팀은 더 중요한 질문을 마주하게 된다.

이 구조를 모두가 같은 방식으로 이해하고 있는가?

AI가 코드를 빠르게 만들 수 있는 시대에도 ERD가 여전히 필요한 이유는 여기에 있다.

ERD는 오래된 산출물이 아니다

ERD는 오래된 데이터베이스 설계 문서처럼 보일 수 있다.

프로젝트 초기에 한 번 그리고, 개발이 진행되면서 업데이트되지 않는 그림.

 실제 코드와 점점 달라지는 문서.

 나중에는 아무도 열어보지 않는 산출물.

많은 팀이 ERD를 이런 방식으로 경험했다.

그래서 어떤 개발자에게 ERD는 “느린 문서 작업”처럼 느껴질 수 있다.

하지만 AI 코딩 시대에는 ERD를 다시 볼 필요가 있다.

ERD는 단순한 산출물이 아니다.

데이터 구조를 이해하기 위한 언어다.

 테이블 간 관계를 검토하기 위한 화면이다.

 팀이 같은 구조를 보고 대화하기 위한 공통 기준이다.

 AI가 만든 결과물을 사람이 다시 해석하기 위한 중간 레이어다.

AI가 구조를 더 빠르게 만들수록, 사람은 그 구조를 더 빠르게 이해해야 한다.

그때 필요한 것이 ERD다.

SQL은 정확하지만, 구조를 공유하기에는 어렵다

SQL은 데이터베이스 구조를 표현하는 정확한 언어다.

테이블을 만들고, 컬럼을 정의하고, 제약조건을 선언하고, 외래키를 연결한다. 실제 데이터베이스에 반영되는 구조는 결국 SQL, ORM 모델, 마이그레이션 코드로 표현된다.

하지만 정확하다는 것과 함께 이해하기 쉽다는 것은 다르다.

SQL을 읽으면 테이블과 컬럼은 알 수 있다.

 외래키도 찾을 수 있다.

 인덱스와 제약조건도 확인할 수 있다.

하지만 전체 구조를 한눈에 파악하기는 어렵다.

어떤 엔티티가 중심인지.

 어떤 테이블이 보조 역할인지.

 관계가 어디에서 복잡해지는지.

 N:M 관계가 어떻게 풀려 있는지.

 권한이나 소유권 구조가 어디에 걸려 있는지.

이런 것들은 SQL만으로는 빠르게 보이지 않는다.

특히 AI가 만든 스키마라면 더 그렇다.

작성 과정이 보이지 않기 때문에, 사람은 결과물만 보고 구조를 다시 이해해야 한다.

이때 ERD는 SQL을 대체하는 것이 아니라, SQL을 이해 가능한 형태로 바꾸는 역할을 한다.

SQL은 구현 언어에 가깝다.

ERD는 이해와 대화의 언어에 가깝다.

AI가 만든 구조에는 공통 화면이 필요하다

사람이 직접 데이터베이스를 설계할 때는 설계 과정에서 많은 판단이 일어난다.

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

 이 관계를 왜 1:N으로 잡았는지.

 이 값을 왜 별도 테이블로 뺐는지.

 이 권한 구조를 왜 이렇게 모델링했는지.

 삭제와 복구 정책을 왜 이렇게 정했는지.

개발자는 이런 판단을 하면서 구조를 이해한다.

하지만 AI가 만든 구조는 다르다.

결과는 빠르게 나온다.

하지만 그 결과가 어떤 판단을 거쳐 만들어졌는지는 항상 분명하지 않다.

테이블은 있지만 이유가 약할 수 있다.

 관계는 있지만 의도가 보이지 않을 수 있다.

 제약조건은 있지만 어떤 규칙을 반영한 것인지 모호할 수 있다.

 반대로 중요한 제약조건이 빠져 있어도 쉽게 지나칠 수 있다.

그래서 AI가 만든 구조는 팀이 함께 볼 수 있는 형태로 다시 펼쳐져야 한다.

ERD는 그 공통 화면이 된다.

테이블과 관계를 시각적으로 펼쳐놓으면, 팀은 같은 구조를 보며 질문할 수 있다.

“이 관계가 정말 필요한가?”

 “이 테이블은 책임이 너무 많지 않은가?”

 “권한은 어디에서 결정되는가?”

 “이 구조로 나중에 팀 기능을 붙일 수 있는가?”

AI가 만든 구조를 이해하려면, 먼저 그 구조를 함께 볼 수 있어야 한다.

ERD는 백엔드 개발자만을 위한 도구가 아니다

데이터베이스 구조는 백엔드 개발자만의 문제가 아니다.

프론트엔드 개발자는 API 응답 구조를 이해해야 한다.

 PM은 기능 흐름과 데이터 관계를 이해해야 한다.

 디자이너는 화면에 필요한 상태와 정보를 이해해야 한다.

 QA는 어떤 데이터 조건에서 문제가 생길 수 있는지 알아야 한다.

 신규 합류자는 서비스의 핵심 구조를 빠르게 파악해야 한다.

하지만 SQL이나 ORM 코드는 모든 사람에게 같은 방식으로 읽히지 않는다.

백엔드 개발자에게는 익숙한 구조도, 다른 직군에게는 추상적인 코드 조각으로 보일 수 있다.

반면 ERD는 더 넓은 팀이 함께 볼 수 있다.

물론 ERD만으로 모든 것을 설명할 수는 없다.

하지만 데이터 구조에 대해 이야기할 때, ERD는 같은 화면을 놓고 대화하게 해준다.

이 점이 중요하다.

AI가 만든 코드와 스키마가 늘어날수록, 팀은 더 많은 결과물을 더 빠르게 이해해야 한다.

그런데 팀원 각자의 머릿속에 서로 다른 구조가 들어 있으면 협업 비용이 커진다.

ERD는 그 구조를 밖으로 꺼내는 역할을 한다.

한 사람이 이해한 구조를 팀이 공유 가능한 구조로 바꾼다.

ERD는 리뷰를 빠르게 만든다

AI가 만든 스키마를 리뷰할 때 가장 위험한 것은 “겉보기에는 괜찮아 보이는 구조”다.

테이블 이름은 자연스럽다.

 컬럼도 그럴듯하다.

 기본적인 외래키도 들어 있다.

 created_at, updated_at도 있다.

그래서 빠르게 넘어가기 쉽다.

하지만 ERD로 보면 다른 문제가 보일 수 있다.

관계가 빠져 있는 테이블.

 불필요하게 많은 책임을 가진 테이블.

 N:M 관계가 애매하게 표현된 구조.

 권한이나 소유권이 불명확한 흐름.

 특정 테이블에 의존성이 과도하게 몰린 구조.

이런 문제는 SQL을 위에서 아래로 읽을 때보다, 관계를 그림으로 볼 때 더 빨리 드러난다.

ERD는 정답을 자동으로 알려주는 도구가 아니다.

하지만 검토해야 할 지점을 더 빨리 보이게 한다.

AI가 만든 구조가 실제로 괜찮은지 판단하려면, 사람이 검토할 수 있는 형태로 구조를 펼쳐야 한다.

ERD는 그 검토 시간을 줄여준다.

ERD는 코드 이전과 이후 모두 필요하다

ERD는 프로젝트 초기에만 필요한 것이 아니다.

AI 코딩 시대에는 코드가 만들어지기 전에도, 만들어진 후에도 ERD가 필요하다.

코드가 만들어지기 전에는 요구사항을 구조로 정리하는 데 도움이 된다.

자연어 요구사항을 바로 코드 생성으로 보내기 전에, 어떤 엔티티와 관계가 필요한지 먼저 확인할 수 있다.

예를 들어 “팀 기반 프로젝트 관리 도구”라는 요구사항이 있을 때, 바로 코드를 만들기보다 먼저 사용자, 팀, 프로젝트, 멤버십, 권한, 초대 관계를 구조로 확인할 수 있다.

코드가 만들어진 후에도 ERD는 필요하다.

AI가 이미 생성한 SQL이나 ORM 모델을 시각화해, 구조가 실제 의도와 맞는지 확인할 수 있다.

즉 ERD는 두 방향에서 모두 의미가 있다.

요구사항에서 구조로 가는 길.

 생성된 코드에서 구조를 다시 이해하는 길.

AI 코딩이 빨라질수록, 이 두 길은 더 중요해진다.

좋은 ERD는 개발 속도를 늦추지 않는다

어떤 사람은 ERD를 그리는 일이 개발 속도를 늦춘다고 생각할 수 있다.

하지만 문제는 ERD 자체가 아니다.

문제는 ERD를 무겁고 오래 걸리는 문서 작업으로 다루는 방식이다.

AI 시대의 ERD는 빠르게 생성되고, 빠르게 수정되고, 빠르게 공유되어야 한다.

완벽한 설계 문서를 만드는 것이 목적이 아니다.

지금 팀이 이해해야 할 구조를 명확히 보여주는 것이 중요하다.

좋은 ERD는 개발을 멈추게 하지 않는다.

오히려 불필요한 재작업을 줄인다.

 리뷰 시간을 줄인다.

 신규 팀원의 온보딩을 돕는다.

 AI가 만든 구조를 더 안전하게 받아들이게 한다.

 팀이 같은 구조를 보고 더 빠르게 결정하게 한다.

ERD가 느린 이유는 다이어그램이기 때문이 아니다.

업데이트되지 않고, 공유되지 않고, 실제 코드와 연결되지 않기 때문이다.

AI 코딩 시대의 ERD는 살아 있어야 한다.

ERD는 AI Coding Debt를 줄이는 데 도움이 된다

AI가 만든 구조를 충분히 이해하지 않고 그대로 개발을 진행하면, 나중에 비용으로 돌아올 수 있다.

처음에는 빠르다.

스키마가 만들어지고, API가 붙고, 화면이 만들어지고, 테스트가 추가된다.

하지만 데이터 구조 안에 숨어 있던 잘못된 관계나 불명확한 책임은 시간이 지나며 점점 더 비싸진다.

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

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

ERD는 이 부채를 완전히 없애지는 못한다.

하지만 적어도 부채가 쌓이기 전에 구조를 볼 수 있게 해준다.

팀이 같은 구조를 보고 질문할 수 있게 해준다.

 잘못된 관계나 애매한 책임을 더 일찍 발견하게 해준다.

 코드가 쌓이기 전에 구조를 다시 생각할 기회를 준다.

AI 시대의 ERD는 “예쁜 다이어그램”이 아니다.

검토 비용을 앞당기는 장치에 가깝다.

개발팀에는 구조를 보는 눈이 필요하다

AI는 더 많은 코드를 만들 것이다.

더 많은 스키마를 만들고, 더 많은 API를 만들고, 더 많은 테스트와 문서를 만들 것이다.

하지만 생성된 결과물이 늘어난다고 해서 팀의 이해가 자동으로 늘어나지는 않는다.

오히려 이해해야 할 구조는 더 많아진다.

그래서 개발팀에 필요한 것은 단순히 더 빠른 코드 생성 능력이 아니다.

AI가 만든 구조를 보고, 이해하고, 검토하고, 팀과 공유하는 능력이다.

ERD는 그중 가장 현실적인 출발점이다.

데이터베이스는 서비스의 구조가 가장 먼저 드러나는 곳이고, ERD는 그 구조를 사람이 볼 수 있는 형태로 바꿔준다.

AI가 만든 코드를 더 빨리 받아들이기 전에, 그 코드가 기대고 있는 구조를 먼저 이해해야 한다.

AI 시대에도 ERD가 여전히 필요한 이유는, 결국 소프트웨어는 코드만으로 이해되지 않기 때문이다.