백엔드 개발이나 데이터베이스 관련 직무를 준비하는 취업 준비생의 프로젝트를 점검하다 보면 ERD 이미지는 깔끔하게 정리되어 있는데, 왜 그런 구조로 설계했는지를 설명하는 단계에서 막히는 경우가 있습니다. 회원, 상품, 주문, 결제 같은 테이블을 만들고 기본키와 외래키까지 연결했지만 주문과 주문상품을 왜 분리했는지, 회원 주소를 한 테이블에 모두 넣지 않은 이유가 무엇인지, 잘못된 상태값이 들어오는 것을 데이터베이스에서 어떻게 막았는지를 질문하면 설계 도구가 자동으로 만들어준 구조 정도로 설명하는 식입니다. 반대로 SQL과 데이터베이스 기능은 많이 사용했지만 포트폴리오에서는 최종 ERD 한 장만 보여주는 경우도 있습니다. 처음에는 어떤 구조였고 실제 데이터를 넣어보니 어떤 중복이나 수정 문제가 발생했는지, 정규화를 통해 무엇을 분리했는지, 제약조건을 추가한 뒤 어떤 오류를 사전에 막을 수 있었는지가 남아 있지 않습니다. 이 상태에서는 데이터베이스를 사용한 프로젝트라는 사실은 보여도 데이터 구조를 분석하고 설계한 경험까지 전달하기는 어렵습니다. 데이터베이스 설계는 테이블을 많이 만드는 작업이 아닙니다. 서비스에서 관리해야 하는 개체를 구분하고 서로 어떤 관계를 갖는지 구조화해야 하며, 같은 정보가 여러 곳에서 반복되면서 발생하는 수정 문제를 줄이고, 애플리케이션 실수만으로 잘못된 데이터가 저장되지 않도록 데이터 자체의 규칙도 정의해야 합니다. 예를 들어 주문 프로젝트에서 회원 이름과 주소를 모든 주문 행에 반복 저장하면 조회는 단순해 보일 수 있습니다. 하지만 회원 주소가 변경되었을 때 과거 주문 주소까지 바꿔야 하는지, 배송 당시 주소는 별도로 보관해야 하는지와 같은 업무 기준을 고려하면 단순한 중복 제거만으로 해결되지 않습니다. 어떤 데이터는 현재 상태이고 어떤 데이터는 거래 시점의 기록인지에 따라 설계 판단도 달라집니다. 이런 판단 과정이 포트폴리오에 남아 있으면 ERD는 그림 한 장이 아니라 설계 사고를 보여주는 자료가 됩니다. ERD에서는 업무와 데이터의 관계를 어떻게 구조화했는지, 정규화에서는 어떤 중복과 변경 문제를 줄였는지, 제약조건에서는 데이터가 반드시 지켜야 할 규칙을 어디까지 데이터베이스에서 보장했는지를 연결해서 보여주는 것이 중요합니다.
이번 글에서는 데이터베이스 설계 경험을 포트폴리오에 보여주는 방법을 ERD, 정규화, 제약조건 세 가지 기준으로 나누어 정리하겠습니다.
ERD는 테이블을 그리는 결과물이 아니라 업무 구조를 데이터 관계로 바꾸는 과정입니다
- 좋은 ERD는 테이블 수보다 어떤 업무 개체를 구분했는지가 먼저 보여야 합니다
ERD를 작성할 때 바로 테이블과 칼럼부터 만드는 경우가 있습니다. 하지만 실제 설계에서는 서비스에서 관리해야 하는 대상이 무엇이고 각각 어떤 역할을 하는지를 먼저 구분해야 테이블 구조가 자연스럽게 만들어집니다.
ERD 프로젝트에서는 다음 내용을 연결해서 볼 수 있습니다.
- 서비스에서 독립적으로 관리해야 할 개체를 구분합니다.
- 각 개체를 식별할 기본키를 정합니다.
- 개체 사이에 어떤 관계가 존재하는지 확인합니다.
- 1:1과 1:N, N:M 관계를 구분합니다.
- 관계가 언제 생성되고 종료되는지 살펴봅니다.
- 최종 ERD와 함께 주요 설계 이유를 기록합니다.
예를 들어 온라인 쇼핑 서비스를 설계한다면 회원과 상품, 주문, 결제를 모두 하나의 테이블에 넣는 것이 아니라 각각 별도의 개체로 볼 이유가 있습니다. 특히 하나의 주문에 여러 상품이 포함될 수 있고 같은 상품도 여러 주문에 포함될 수 있기 때문에 주문과 상품 사이에는 N:M 관계가 생길 수 있습니다. 이를 주문상품 같은 연결 개체로 풀어내면 수량과 주문 당시 가격 같은 속성도 함께 관리할 수 있습니다. 포트폴리오에서는 회원 테이블 1개, 상품 테이블 1개, 주문 테이블 1개를 만들었다는 설명보다 업무 관계를 어떤 기준으로 테이블 구조로 변환했는지를 보여주는 편이 좋습니다.
- 논리 ERD와 실제 테이블 설계는 표현하려는 목적에서 차이가 있습니다
ERD를 하나의 완성된 그림으로만 생각하면 설계 과정에서 무엇을 고민했는지가 잘 드러나지 않습니다. 업무 관계를 설명하기 위한 단계와 실제 데이터베이스 구현을 위한 단계는 서로 다른 정보를 강조할 수 있습니다.
- 개념적 구조: 회원과 주문, 상품처럼 서비스에서 관리해야 하는 주요 개체와 관계를 중심으로 표현합니다.
- 논리적 구조: 각 개체의 속성과 기본키, 관계를 구체화하고 어떤 데이터를 어느 엔터티에서 관리할지 정합니다.
- 물리적 구조: 실제 DBMS에 맞춰 데이터 타입과 칼럼명, 인덱스와 제약조건 등을 구현 가능한 형태로 구체화합니다.
- 운영 관점 구조: 조회 빈도와 데이터 증가량, 변경 패턴을 고려해 실제 운영에 필요한 구조를 다시 검토합니다.
- 포트폴리오 표현: 최종 ERD만 보여주기보다 설계가 어떤 기준으로 구체화되었는지를 함께 설명합니다.
예를 들어 논리적으로는 회원과 주소를 별도 개체로 나눌 수 있지만 실제 프로젝트에서는 회원 한 명이 여러 배송지를 관리할 수 있는지와 주문 당시 주소 기록을 별도로 보존해야 하는지를 고려해야 합니다. 따라서 ERD는 정답을 그리는 작업이라기보다 서비스 요구사항을 데이터 구조로 해석한 결과라고 보는 편이 적절합니다.
- 카디널리티와 선택 관계를 설명할 수 있으면 ERD의 깊이가 달라집니다
ERD를 볼 때 선이 연결되어 있다는 사실만 확인하면 각 테이블 사이의 실제 업무 규칙을 놓치기 쉽습니다. 관계가 반드시 존재해야 하는지와 하나의 데이터가 몇 개의 다른 데이터와 연결될 수 있는지를 설명할 수 있어야 합니다.
ERD 검토에서는 다음 내용을 확인할 수 있습니다.
- 회원 한 명이 여러 주문을 가질 수 있는지 구분합니다.
- 주문은 반드시 한 명의 회원과 연결되어야 하는지 확인합니다.
- 비회원 주문을 허용한다면 관계가 어떻게 달라지는지 살펴봅니다.
- 주문 한 건에 여러 결제가 발생할 수 있는지 검토합니다.
- 상품이 아직 주문된 적이 없어도 존재할 수 있는지 확인합니다.
- 관계 변경이 발생하면 관련 데이터가 어떻게 처리되는지 정리합니다.
예를 들어 회원 1 : 주문 N이라는 관계만 적어두는 것과 주문은 반드시 회원을 가져야 하는가까지 판단하는 것은 설계 깊이가 다릅니다. 비회원 주문을 허용하는 서비스라면 주문의 회원 ID가 반드시 존재해야 하는 구조가 맞지 않을 수도 있습니다. 이런 조건을 설명할 수 있으면 ERD가 단순한 테이블 연결도가 아니라 실제 서비스 정책을 데이터 관계로 표현한 설계 자료가 됩니다.
- ERD 포트폴리오는 최종 그림보다 설계가 바뀐 이유를 보여줄 때 더 설득력이 생깁니다
처음부터 완성된 ERD만 보여주면 지원자가 직접 판단한 부분과 설계 도구가 자동으로 표현한 부분을 구분하기 어렵습니다. 초기 구조에서 어떤 문제를 발견했고 무엇을 수정했는지를 기록하면 프로젝트의 사고 과정이 더 잘 드러납니다.
- 초기 설계 상태: 회원과 주문, 배송정보를 어떤 테이블로 구성했는지 보여줍니다.
- 문제 발견 상태: 중복 데이터나 관계 표현의 한계가 어디에서 나타났는지 설명합니다.
- 설계 변경 상태: 테이블을 분리하거나 연결 테이블을 추가한 이유를 정리합니다.
- 적용 결과 상태: 실제 샘플 데이터를 넣었을 때 원하는 관계가 표현되는지 확인합니다.
- 추가 검토 상태: 새로운 요구사항이 생겼을 때 기존 구조가 얼마나 쉽게 확장되는지 살펴봅니다.
예를 들어 처음에는 주문 테이블에 상품 ID 하나만 저장했다가 한 주문에서 여러 상품을 구매해야 한다는 요구사항을 반영하면서 주문상품 테이블을 추가했다면 이 변화 자체가 좋은 설계 경험이 됩니다. 포트폴리오에서는 처음 구조 → 문제 → 변경 판단 → 최종 ERD의 흐름이 보일 때 설계 경험을 더 구체적으로 전달할 수 있습니다.
정규화는 테이블을 많이 나누는 작업이 아니라 중복과 변경 이상을 줄이는 판단 과정입니다
- 정규화는 실제로 어떤 데이터가 반복되는지를 발견하는 데서 시작할 수 있습니다
정규화를 공부하면 제1 정규형과 제2 정규형, 제3 정규형의 정의부터 외우는 경우가 많습니다. 하지만 포트폴리오에서는 정규형 이름보다 실제 테이블에서 어떤 중복과 이상현상이 발생했는지를 보여주는 편이 이해하기 쉽습니다.
정규화 과정에서는 다음 내용을 확인할 수 있습니다.
- 하나의 칼럼에 여러 값이 반복해서 들어가고 있는지 살펴봅니다.
- 동일한 회원이나 상품 정보가 여러 행에서 반복되는지 확인합니다.
- 일부 값만 수정하면 서로 다른 정보가 남을 가능성을 검토합니다.
- 새로운 데이터를 추가하려면 관련 없는 값까지 필요하지 않은지 확인합니다.
- 특정 데이터를 삭제했을 때 다른 중요한 정보까지 사라지는지 살펴봅니다.
- 테이블 분리 이후 원래 업무 관계가 유지되는지 다시 확인합니다.
예를 들어 주문 데이터마다 상품명과 상품 카테고리, 제조사 정보를 모두 반복 저장하면 상품명이 변경될 때 여러 주문 행을 수정해야 할 수 있습니다. 상품 정보가 별도 상품 테이블에 존재하고 주문에는 상품 식별자를 연결한다면 동일한 상품 정보를 반복 관리하는 문제를 줄일 수 있습니다. 이런 사례를 포트폴리오에 남기면 3NF까지 정규화했다는 한 문장보다 어떤 문제 때문에 테이블을 나누었는지가 훨씬 명확하게 보입니다.
- 정규화와 테이블 분리는 항상 같은 의미로 볼 수 없습니다
테이블을 많이 나눴다고 해서 정규화가 잘 된 것은 아닙니다. 반대로 일부 데이터를 한 테이블에 함께 둔다고 해서 무조건 잘못된 설계라고 단정하기도 어렵습니다.
- 중복 제거 목적의 분리: 동일한 데이터가 여러 곳에서 반복되면서 수정 이상이 발생하는 문제를 줄입니다.
- 독립 개체 분리: 서로 다른 생명주기와 의미를 가진 데이터를 별도의 테이블로 관리합니다.
- 관계 표현을 위한 분리: N:M 관계를 연결 테이블로 변환해 관계 속성을 함께 관리합니다.
- 이력 보존을 위한 유지: 거래 당시 가격이나 배송지처럼 현재 정보와 별도로 보관할 이유가 있는 값은 중복처럼 보여도 그대로 둘 수 있습니다.
- 조회 최적화를 위한 비정규화: 운영 목적에 따라 일부 값을 의도적으로 중복 저장할 수 있지만 그 이유와 갱신 기준이 필요합니다.
예를 들어 주문 당시 상품 가격을 주문상품 테이블에 저장하는 것은 상품 테이블의 현재 가격과 값이 중복되는 것처럼 보일 수 있습니다. 하지만 상품 가격이 나중에 변경되더라도 과거 주문금액은 유지되어야 하기 때문에 이 값은 거래 시점의 기록이라는 별도의 의미를 가집니다. 따라서 정규화 포트폴리오에서는 규칙을 기계적으로 적용했다는 설명보다 데이터가 어떤 의미를 가지기 때문에 분리하거나 유지했는지를 보여주는 것이 중요합니다.
- 삽입·수정·삭제 이상을 실제 데이터로 보여주면 정규화 판단이 더 선명해집니다
정규화의 필요성을 설명할 때 이론적인 정의만 적으면 프로젝트와 연결되기 어렵습니다. 간단한 샘플 데이터를 이용해 설계 전 구조에서 어떤 문제가 나타나는지를 보여주면 변경 이유를 구체적으로 설명할 수 있습니다.
프로젝트에서는 다음 상황을 기록할 수 있습니다.
- 동일한 고객 정보가 여러 주문 행에 반복되는 상태를 확인합니다.
- 고객 연락처를 일부 행에서만 수정했을 때 정보가 서로 달라지는 상황을 만듭니다.
- 주문이 없는 상품을 등록하기 어려운 구조가 있는지 확인합니다.
- 마지막 주문 데이터를 삭제했을 때 상품 정보까지 사라지는 구조인지 살펴봅니다.
- 테이블을 분리한 뒤 같은 문제를 다시 재현합니다.
- 변경 이후 데이터가 한 곳에서 일관되게 관리되는지 검증합니다.
예를 들어 한 테이블에 주문번호, 고객명, 고객전화번호, 상품명, 상품가격을 모두 저장했다면 동일 고객의 전화번호가 여러 행에 반복될 수 있습니다. 한 행만 수정되면 서로 다른 전화번호가 존재하게 되고 어떤 값이 최신인지 판단하기 어려워질 수 있습니다. 이 과정을 전후 비교로 보여주면 정규화가 이론 문제가 아니라 데이터 정합성을 지키기 위한 구조 개선 경험이라는 점이 드러납니다.
- 정규화 이후에는 조회와 운영 방식까지 다시 확인해야 설계가 완성됩니다
테이블을 잘 분리했다고 해서 프로젝트가 끝나는 것은 아닙니다. 정규화 이후 필요한 데이터를 조회하려면 JOIN이 늘어날 수 있고, 자주 사용하는 쿼리와 데이터 증가량에 따라 다른 설계 판단이 필요할 수도 있습니다.
- 정규화 전 확인: 어떤 데이터가 중복되고 어느 변경에서 문제가 생기는지 파악합니다.
- 정규화 적용: 독립적인 개체와 관계를 기준으로 테이블을 분리합니다.
- 데이터 이전 확인: 기존 데이터가 새로운 구조에서도 누락 없이 표현되는지 확인합니다.
- 조회 재검증: 실제 서비스에서 필요한 화면과 통계 쿼리가 정상적으로 작성되는지 확인합니다.
- 운영 검토: 조회 비용과 데이터 증가, 이력 보존 요구사항을 고려해 추가 개선 여부를 판단합니다.
예를 들어 상품 카테고리를 여러 단계로 분리했는데 실제 서비스에서는 항상 모든 카테고리 정보를 함께 조회해야 한다면 JOIN 구조와 인덱스까지 함께 검토할 수 있습니다. 필요하다면 일부 조회용 데이터를 별도로 구성하는 판단도 가능하지만 그 경우에는 데이터 일관성을 어떻게 유지할지 설명할 수 있어야 합니다. 따라서 포트폴리오에서 정규화는 테이블을 나눈 결과가 아니라 데이터 이상을 줄이고, 다시 실제 조회와 운영 조건까지 검증한 과정으로 보여주는 편이 좋습니다.
제약조건은 잘못된 데이터를 애플리케이션 코드 밖에서도 막는 데이터 품질 기준입니다
- 제약조건은 데이터가 반드시 지켜야 하는 규칙을 데이터베이스에 남기는 방법입니다
프로젝트를 만들 때 입력값 검증을 모두 애플리케이션 코드에서 처리하는 경우가 많습니다. 하지만 여러 프로그램이나 관리자 도구가 같은 데이터베이스에 접근할 수 있다면 애플리케이션 검증만으로 모든 잘못된 입력을 막는다고 보기는 어렵습니다.
제약조건 설계에서는 다음 내용을 연결해서 볼 수 있습니다.
- 각 행을 구분할 기본키를 정의합니다.
- 반드시 입력되어야 하는 값에는 NOT NULL을 적용합니다.
- 중복되면 안 되는 값에는 UNIQUE 여부를 검토합니다.
- 테이블 관계는 외래키로 표현할지 판단합니다.
- 허용 가능한 값의 범위를 제한할 필요가 있는지 확인합니다.
- 데이터 삭제와 수정이 관련 테이블에 미치는 영향을 검토합니다.
예를 들어 회원 이메일이 로그인 식별자로 사용된다면 동일한 이메일이 여러 회원에게 저장되어도 되는지부터 결정해야 합니다. 중복을 허용하지 않는 정책이라면 애플리케이션에서 한 번 검사하는 것뿐 아니라 데이터베이스에서도 UNIQUE 제약을 적용하는 구조를 고려할 수 있습니다. 이런 내용이 포트폴리오에 포함되면 데이터베이스 설계가 칼럼 정의에서 끝나지 않고 데이터가 가져야 할 규칙까지 구현한 경험으로 확장됩니다.
- 기본키·외래키·UNIQUE는 각각 막으려는 데이터 오류가 다릅니다
제약조건을 많이 적용하는 것이 목적은 아닙니다. 각 제약조건이 어떤 업무 규칙을 보호하는지 이해해야 적절한 위치에 사용할 수 있습니다.
- 기본키: 한 행을 다른 행과 명확하게 구분할 식별자를 보장합니다.
- 외래키: 연결 대상이 존재하지 않는 잘못된 관계 데이터가 저장되는 문제를 제한할 수 있습니다.
- UNIQUE: 이메일이나 외부 주문번호처럼 중복을 허용하지 않는 값의 규칙을 보장할 수 있습니다.
- NOT NULL: 업무상 반드시 필요한 값이 비어 있는 상태로 저장되는 문제를 제한합니다.
- CHECK: 수량이나 상태처럼 허용 가능한 값의 범위를 데이터베이스 수준에서 제한하는 데 활용할 수 있습니다.
예를 들어 주문상품 수량에 음수가 입력되어서는 안 된다면 애플리케이션 화면에서 숫자를 검사하는 것과 별개로 데이터베이스에서도 허용 범위를 정의할 수 있습니다. 반대로 모든 규칙을 데이터베이스 제약조건으로 표현할 수 있는 것은 아니기 때문에 애플리케이션 로직과 DB 규칙의 역할을 나누는 판단도 필요합니다. 포트폴리오에서는 제약조건 이름을 나열하기보다 어떤 잘못된 데이터를 막기 위해 그 조건을 선택했는지를 설명하는 편이 좋습니다.
- 제약조건은 정상 데이터보다 잘못된 데이터를 넣어볼 때 효과가 더 잘 드러납니다
제약조건을 설정한 뒤 정상적인 INSERT만 실행하면 해당 규칙이 실제로 필요한지 확인하기 어렵습니다. 안전한 개발 환경에서 의도적으로 잘못된 데이터를 입력해 어떤 오류를 차단하는지 검증하면 프로젝트 설명이 더 구체적이 됩니다.
검증 과정에서는 다음 내용을 확인할 수 있습니다.
- 이미 존재하는 고윳값을 다시 입력해 봅니다.
- 필수 칼럼을 비운 데이터를 저장해 봅니다.
- 존재하지 않는 부모 데이터의 외래키를 입력해 봅니다.
- 허용 범위를 벗어난 수치나 상태값을 입력해 봅니다.
- 부모 데이터를 삭제했을 때 자식 데이터가 어떻게 처리되는지 확인합니다.
- 정상적인 입력과 수정은 기존처럼 동작하는지 다시 검증합니다.
예를 들어 존재하지 않는 상품 ID로 주문상품을 만들 수 있다면 조회 과정에서 상품 정보를 찾지 못하는 고아 데이터가 생길 수 있습니다. 외래키를 적용한 뒤 같은 입력을 다시 시도해 저장 자체가 거부되는지 확인하면 제약조건이 어떤 문제를 막는지 명확하게 보여줄 수 있습니다. 이런 테스트가 포함되어 있으면 포트폴리오에서 제약조건 설정 → 오류 재현 → 차단 결과 → 정상 기능 재검증의 과정까지 설명할 수 있습니다.
- 데이터 무결성은 제약조건을 많이 넣는 것보다 업무 규칙과 삭제 정책까지 일치시키는 것이 중요합니다
제약조건을 적용할 때 가장 고민이 필요한 부분 중 하나는 데이터가 변경되거나 삭제될 때 연결된 데이터를 어떻게 처리할지입니다. 외래키가 있다고 해서 모든 관계에서 같은 삭제 정책을 사용할 수 있는 것은 아닙니다.
- 회원 삭제 상황: 실제 데이터를 물리적으로 삭제할지 비활성 상태로 보존할지 업무 정책이 필요합니다.
- 주문 삭제 상황: 회계나 거래 기록 때문에 단순 삭제를 허용하지 않을 수 있습니다.
- 상품 삭제 상황: 과거 주문에서 상품 기록이 필요하다면 연결 관계를 유지할 방법이 필요합니다.
- 하위 데이터 처리: 부모 데이터가 삭제될 때 함께 삭제할지, 삭제를 차단할지, 별도 상태로 관리할지 결정해야 합니다.
- 이력 관리 상황: 현재 데이터와 과거 시점의 데이터를 분리해 보존할 필요가 있는지 검토합니다.
예를 들어 회원이 탈퇴했다고 해서 과거 주문까지 모두 삭제하면 거래 이력이 사라질 수 있습니다. 반대로 임시 장바구니와 그 안의 상세 항목처럼 부모가 사라지면 함께 제거되어도 되는 데이터도 있을 수 있습니다. 이런 차이를 설계 문서에 남기면 제약조건을 기술 옵션으로만 사용한 것이 아니라 업무 규칙과 데이터 생명주기를 기준으로 무결성을 설계한 경험으로 보여줄 수 있습니다.
- conclusion
데이터베이스 설계 경험을 포트폴리오에 넣을 때 가장 피해야 할 방식은 완성된 ERD 한 장과 테이블 생성 SQL만 보여주고 설계를 끝내는 것입니다. 데이터베이스 설계에서 평가할 수 있는 역량은 테이블을 얼마나 많이 만들었는지가 아니라 서비스 요구사항을 데이터 구조로 바꾸고, 잘못된 구조에서 발생할 수 있는 문제를 찾아 개선하며, 데이터가 지켜야 할 규칙을 시스템 안에 남긴 과정에 있습니다. ERD에서는 회원과 주문, 상품처럼 실제 업무 개체를 어떤 기준으로 분리했고 서로 어떤 관계를 맺도록 설계했는지가 보여야 합니다. 특히 카디널리티와 선택 관계, N:M 관계를 연결 테이블로 풀어낸 이유까지 설명할 수 있다면 단순히 ERD 도구를 사용할 수 있다는 수준을 넘어 데이터 구조를 해석한 경험으로 연결됩니다. 정규화에서는 정규형 이름을 나열하는 것보다 실제 중복과 삽입·수정·삭제 이상이 어떤 상황에서 나타났고 테이블을 분리한 뒤 어떻게 개선되었는지를 보여주는 것이 중요합니다. 동시에 거래 당시 가격처럼 의도적으로 과거 값을 보존해야 하는 데이터까지 모두 중복으로 판단하지 않고 데이터 의미에 따라 유지 여부를 결정할 수 있어야 합니다. 제약조건에서는 기본키와 외래키, UNIQUE와 NOT NULL 등을 적용했다는 결과보다 무엇을 막기 위해 사용했는지가 보여야 합니다. 잘못된 데이터를 직접 입력해 제약조건이 작동하는지 확인하고, 데이터 삭제와 변경에서 업무 규칙이 유지되는지 검증하면 데이터 무결성에 대한 이해도 더 구체적으로 드러납니다.
최종적으로 확인할 항목은 다음과 같습니다.
- 주요 업무 개체와 각 테이블의 역할을 설명할 수 있는지 확인합니다.
- 테이블 사이의 1:1, 1:N, N:M 관계를 판단한 근거가 있는지 살펴봅니다.
- 중복 데이터와 수정 이상을 실제 사례로 설명할 수 있는지 확인합니다.
- 정규화 전후의 구조와 데이터 변화가 기록되어 있는지 점검합니다.
- 기본키와 외래키, UNIQUE 등 제약조건의 적용 이유를 설명할 수 있는지 살펴봅니다.
- 잘못된 입력과 삭제 상황을 테스트한 뒤 정상 데이터까지 다시 검증했는지 확인합니다.
데이터베이스 설계 포트폴리오 준비 흐름은 다음과 같이 연결할 수 있습니다.
- 서비스 요구사항 정리 → 주요 개체 도출 → 속성과 식별자 정의 → 관계와 카디널리티 설정 → 초기 ERD 작성 → 샘플 데이터 입력 → 중복·삽입·수정·삭제 이상 확인 → 정규화 → 최종 ERD 수정 → 기본키·외래키 설정 → UNIQUE·NOT NULL·CHECK 검토 → 잘못된 데이터 입력 테스트 → 삭제·변경 정책 검증 → 실제 조회 쿼리 재확인 → 설계 전후 비교 → README와 설계 근거 문서화 → 포트폴리오와 면접 연결
결국 좋은 데이터베이스 설계 포트폴리오는 ERD가 복잡한 프로젝트가 아닙니다. ERD에서는 업무를 데이터 구조와 관계로 바꾸고, 정규화에서는 중복과 변경 이상을 줄이며, 제약조건에서는 데이터가 반드시 지켜야 규칙을 데이터베이스 자체에 반영할 수 있어야 합니다. 이 세 가지가 설계 전 문제와 변경 과정, 적용 후 검증까지 하나의 흐름으로 남아 있다면 단순히 SQL과 DBMS를 사용해 본 경험을 넘어 데이터 구조를 판단하고 개선한 경험으로 포트폴리오와 면접에서 더 구체적으로 설명할 수 있습니다.