ERD란 무엇인가 — 바이브코더가 몇 달 뒤 자기 서비스를 다시 읽는 지도

ERD는 몇 달 뒤의 나를 위한 중간 문서다

강의는 바이브코더의 개발 방식에서 출발한다. 아직은 코드를 직접 읽기보다, 코드 바깥의 중간 문서를 활용해 시스템을 최대한 자기가 이끄는 상태로 개발을 이어 가자는 것이다. 중간 문서는 코드가 무엇을 하는지를 사람의 글과 그림으로 옮겨 적은 문서라고 보면 된다.

강의가 꼽은 중간 문서는 셋이다. 첫째는 PRD로, 무엇을 왜 만드는지 글로 적은 기획 문서다. 둘째는 화면 문서다. 사용자가 어떤 화면을 어떤 순서로 거쳐 가는지 그린 유저 플로우, 화면의 뼈대만 선으로 그린 와이어프레임, 실제 모습에 가깝게 그린 목업을 하나로 묶었다. 셋째가 ERD다.

앞의 둘은 글과 그림이라 따로 배우지 않아도 읽힌다. ERD는 다르다. 개념 없이 보면 네모와 선뿐이라 「그래서 이걸 어디에 쓰라는 건가」 싶어진다. 강의가 ERD 하나에 시간을 따로 들인 이유다.

두 번째 이유가 더 실용적이다. 처음에는 대개 꼭 필요한 기능만 담은 첫 버전을 가장 간단한 방식으로 만든다. 한참 뒤 기능을 더 붙이려고 다시 열면 그때의 맥락이 기억나지 않는다. 강의는 그 순간 「내가 어떻게 만들었지」를 빠르게 되살려 주는 것이 ERD라고 말한다.

엔티티·테이블·행·열 — 네 낱말이면 읽힌다

ERD는 Entity Relationship Diagram의 앞 글자다. 엔티티들이 서로 어떤 관계를 맺는지 그린 그림이라는 뜻이다. 관계는 다음 편부터 다루고, 이 글은 그림 속 네모 하나를 읽는 데까지 간다.

엔티티는 서비스가 관심을 두고 관리해야 할 대상이다. 모바일 청첩장 서비스라면 관리자와 청첩장이 그렇다. 엔티티가 데이터베이스로 넘어가면 테이블이 된다. 데이터베이스는 서비스의 데이터를 쌓아 두는 곳이고, 열어 보면 엑셀 표처럼 생겼다. 그 표 하나가 테이블이다.

테이블 아래로 한 줄씩 쌓이는 데이터 한 건을 행(row)이라고 한다. 청첩장 한 장이 한 줄이다. 아이디·이름처럼 그 테이블이 갖는 속성 하나하나는 열(column)이라고 한다. 세로로 한 칸씩 나뉜 자리라서 열이고, 영어로 컬럼이다.

같은 것을 코드에서는 다른 이름으로 부르기도 한다. 강의의 정리로는 엔티티를 오브젝트(객체), 행 하나를 인스턴스라고 부른다. AI가 짠 코드나 설명에 이 두 말이 나오면 각각 테이블 하나와 그 안의 한 줄을 떠올리면 된다.

모바일 청첩장으로 엔티티와 컬럼 가르기

강의는 모바일 청첩장 서비스를 예로 든다. 요구 사항은 단순하다. 관리자가 로그인한다. 관리자가 모바일 청첩장을 만든다. 청첩장에는 제목·날짜·장소·메시지가 들어간다. 템플릿은 세 가지쯤 정해 두고 그중 하나를 골라 쓴다.

여기서 엔티티는 무엇일까. 강의의 답은 둘이다. 먼저 관리자다. 아무나 들어오는 서비스가 아니라 로그인한 관리자가 청첩장을 만들기 때문에, 관리자라는 대상을 따로 관리해야 한다. 다음은 그 관리자가 만드는 청첩장이다. 청첩장 테이블에는 누가 만들었는지 적는 admin_id 칸을 두는데, 두 테이블을 잇는 이런 칸은 다음 편부터 자세히 본다.

제목·날짜·장소·메시지는 엔티티가 아니다. 청첩장이 갖는 성질이라 청첩장 테이블의 컬럼으로 들어간다. 신랑 이름·신부 이름도 마찬가지다. 가르는 질문은 하나다. 따로 두고 관리할 대상인가, 아니면 무언가에 딸린 속성인가.

자기 서비스에도 그대로 해 볼 수 있다. 서비스가 다루는 명사를 전부 적고 하나씩 이 질문을 던진다. 앞쪽이면 테이블, 뒤쪽이면 그 테이블의 컬럼이다. 어느 쪽인지 헷갈리는 명사가 남는다면, 그것이 대상끼리의 관계를 따져 봐야 하는 자리다.

invitations (청첩장)
────────────────────────────────────────
id           한 장마다 붙는 아이디
admin_id     만든 관리자
title        제목
date         예식 날짜
place        장소
message      메시지
groom_name   신랑 이름
bride_name   신부 이름
template     템플릿 1·2·3 중 하나

행 한 줄 = 청첩장 한 장

칸마다 데이터 타입을 정한다

컬럼을 정했으면 칸마다 어떤 형태의 값이 들어갈지 정한다. 이것이 데이터 타입이다. 숫자 칸에 글자가 들어가거나 날짜 칸에 아무 문장이나 들어가지 않도록 미리 못 박아 두는 것이다. 강의가 짚은 타입은 아래 표와 같다.

대부분은 이름만 봐도 짐작이 간다. 헷갈리기 쉬운 것은 둘이다. decimal은 숫자라서 integer와 비슷해 보이지만, 강의는 결제 잔액처럼 돈과 관련된 값에 주로 쓴다고 정리한다. vector는 RAG에 쓰는 타입이다. RAG는 AI가 답하기 전에 관련 문서를 먼저 찾아 읽게 하는 방식이고, 문서의 뜻을 숫자 목록으로 바꿔 두면 비슷한 내용을 찾을 수 있는데, 그 숫자 목록을 담는 칸이 vector다.

enum은 정해 둔 값만 받는 타입이다. 로그인 수단을 카카오·구글·애플 중 하나로만 받거나, 템플릿을 1·2·3 중 하나로만 받는 식이다. 목록 밖의 값이 들어오면 에러가 나도록 해 둔다.

청첩장에 대 보면 이렇다. 강의는 아이디를 UUID로, 장소·신랑 이름·신부 이름을 varchar로, 템플릿을 enum으로 정했다. 나머지도 같은 기준으로 고르면 된다. 제목은 짧은 글이라 varchar, 메시지는 길어질 수 있으니 text, 예식 날짜는 date 계열이다.

지금 만들고 있는 서비스가 있다면 아래 요청문을 AI에게 그대로 주면 된다. 테이블과 컬럼, 타입을 한 표로 받아 두면 몇 달 뒤 다시 열어 볼 기록의 출발점이 된다. 다음 편에서는 청첩장에 축하글 기능을 붙이면서, 어떤 값은 컬럼으로 두고 어떤 값은 테이블로 빼야 하는지를 본다.

이 프로젝트의 데이터베이스 테이블을 전부 찾아서,
테이블마다 컬럼 이름 · 데이터 타입 · 한 줄 설명을 표로 정리해 줘.
enum 컬럼은 허용하는 값 목록도 같이 적어 줘.
코드는 고치지 말고 읽기만 해.