초기 MVP에서 데이터베이스 테이블 분리 실패 사례와 교훈

MVP 데이터베이스 테이블 분리, 어디서부터 잘못됐나

스타트업 초기에 빠르게 MVP(Minimum Viable Product)를 만들다 보면, 데이터베이스 설계에서 ‘일단 합치고 보자’, ‘일단 쪼개고 보자’ 같은 극단적 선택을 하게 되는 경우가 많습니다. 이러한 선택이 쌓이면 금방이라도 기능 추가나 유지보수할 때 발목을 잡기 시작합니다.
실제 현장에서는 이런 식의 테이블 설계 실패가 어떤 문제로 이어지는지, 무엇을 놓쳤는지 점검하는 기준이 명확해야 합니다.

예를 들어, 사용자 계정과 회사 정보를 한 테이블에 합치는 경우를 생각해봅시다. 초기에는 사용자와 회사가 1:1 관계라 괜찮아 보이지만, 나중에 한 회사에 여러 사용자가 들어가야 하거나, 계정이 여러 회사에 소속될 수 있는 요구가 나오면 설계를 완전히 갈아엎어야 합니다.
이런 상황에서는 요구사항의 변화를 예측하지 못한 채 ‘간단하게’만 바라본 결과가 나중에 더 큰 리펙터링 비용을 부르는 셈입니다.

실제 프로젝트에서는 이런 일이 자주 발생합니다.
일단 동작만 하게 만들고, MVP가 성공적으로 돌아가면 그때 가서 테이블을 나누거나 합치면 된다고 생각하는 경우가 많습니다.
하지만 실제 운영 중에는 데이터 마이그레이션, 서비스 중단, 예상치 못한 에러 등 리스크가 기하급수적으로 늘어납니다.
따라서 초기에 테이블 분리 기준을 어떻게 잡느냐가 MVP의 생존 여부를 가르는 갈림길이 됩니다.

막히는 지점은 바로 ‘이 관계가 언제까지 단순할 것인가?’입니다.
이럴 때 점검해야 할 순서는 다음과 같습니다:

1. 각 테이블의 행이 실제로 ‘하나의 의미’만을 가지는지 확인
2. 확장될 가능성이 있는 관계(1:N, N:M 등)를 미리 도식화
3. 3개월 내 추가될 기능이나 요구사항을 팀 내부에서 시뮬레이션
4. 외부 시스템 연동(예: CRM, 마케팅툴)까지 염두에 두고 설계
5. 리팩터링 비용과 리스크를 숫자로 추산

테이블 합치기의 함정: 너무 단순하게 보면 생기는 문제

많은 개발자들이 MVP 시점에는 테이블을 합치는 것이 효율적이라고 생각합니다.
예를 들어, 주문과 주문 상세를 하나의 테이블에 담는 방식처럼요.
이렇게 하면 쿼리가 단순해지고, 코드도 간단해 보입니다.
그러나 이 방식에는 치명적인 함정이 있습니다.

첫 번째 문제는 데이터 중복과 무결성 저하입니다.
주문마다 상품 정보를 모두 복사 저장하면, 상품 가격이 바뀌었을 때 과거 주문 내역이 오염됩니다.
또한 주문 내역을 수정할 때마다 여러 행이 한꺼번에 바뀌는 문제가 발생할 수 있습니다.

두 번째 문제는 확장성의 부재입니다.
처음에는 한 종류의 주문만 지원하면 되지만, 추후 예약 주문, 취소, 환불 등 다양한 상태와 타입이 추가될 때, 테이블 구조가 이를 감당하지 못합니다.
추가 필드를 계속해서 붙이다 보면, 의미 없는 NULL 값이 늘어나고, 복잡한 쿼리와 데이터 무결성 문제가 꼬이기 시작합니다.

실제 현장에서는 다음 지점에서 막힙니다:

• ‘이 필드를 따로 빼야 하나?’라는 고민
• 중복된 데이터 구조 때문에 유지보수가 어려워지는 시점
• 새로운 요구사항이 추가될 때마다 테이블 구조를 바꾸는 부담

점검 순서는 다음과 같습니다:

1. 중복 데이터가 의도한 것인지, 아니면 설계 미숙 때문인지 구분
2. 자주 변경되는 필드와 그렇지 않은 필드 분리
3. NULL 값이 많은 필드가 왜 생기는지 분석
4. 같은 테이블에 여러 종류(타입)의 데이터가 섞여있는지 확인
5. 과거 데이터에 영향을 주지 않고 확장 가능한 구조인지 검토

쪼개기의 덫: 너무 세분화해서 오는 복잡성

반대로, 미래 확장을 과하게 의식해서 모든 엔티티를 별도 테이블로 쪼개는 것도 문제가 됩니다.
예를 들어, 이벤트 로그, 알림, 메시지, 태그 같은 부가 데이터까지 전부 별도 테이블로 나누면 초기 MVP에서는 불필요한 조인과 복잡한 쿼리만 늘어납니다.

이렇게 과도하게 쪼개면, 단순한 데이터 조회조차 복잡한 JOIN문과 트랜잭션에 의존하게 됩니다.
MVP 단계에서는 실제로 수집되는 데이터 양이 적은데, 그에 비해 관리 포인트만 늘어나게 되는 셈입니다.

두 번째 문제는, 과도한 분리로 인한 오버엔지니어링입니다.
아직 사용자가 많지 않은 MVP에서, 이중화, 아카이빙, 샤딩 같은 구조는 오히려 개발 속도만 늦추고, 장애 발생 시 원인 파악이 더 어려워질 수 있습니다.

막히는 지점은 다음과 같습니다:

• ‘이 정도 데이터도 꼭 테이블로 분리해야 하나?’라는 질문
• 조인 없이 데이터를 조회할 수 없는 상황
• 단순한 조회나 입력에도 3~4개 테이블을 건드려야 하는 불편함

점검 순서는 다음과 같습니다:

1. 한 테이블에 저장해도 데이터 무결성에 큰 문제 없는지 검토
2. 조인 횟수와 성능에 실제 영향이 있는지 프로파일링
3. 기능 출시 속도와 데이터 구조의 복잡성 균형 맞추기
4. 향후 3개월 안에 추가될 확장 요구가 실존하는지 검토
5. 실제 사용자 피드백을 받은 후 분리해도 늦지 않은 영역 찾기

MVP에서 반드시 확인해야 할 테이블 분리 기준

실무에서는 ‘언제 쪼개야 하고, 언제 합쳐야 하나?’라는 질문에 늘 명확한 답을 찾기 어렵습니다.
하지만 몇 가지 기준을 적용하면 최소한의 리스크로 MVP를 설계할 수 있습니다.

첫째, 데이터의 라이프사이클이 다르면 별도 테이블로 분리하는 것이 좋습니다.
예를 들어, 사용자 정보와 사용자 활동 로그는 보관 기간, 접근 주체, 삭제 정책이 다르기 때문에 분리하는 게 맞습니다.

둘째, 데이터의 변경 빈도와 방식이 다르면 분리합니다.
사용자 프로필은 자주 바뀌지 않지만, 사용자의 상태(로그인, 접속 이력 등)는 수시로 바뀝니다.
수정/삭제/추가가 잦은 데이터와 그렇지 않은 데이터는 구분하는 것이 유지보수에 유리합니다.

셋째, 업무 로직상 별도의 책임이 있거나, 엔티티의 의미가 명확히 다르면 분리합니다.
예를 들어, 결제와 환불, 주문과 배송 등은 비즈니스 프로세스상 독립적인 트랜잭션 단위이기 때문입니다.

넷째, 외부 연동이나 데이터 마이그레이션이 예상되는 경우도 분리합니다.
예를 들어, 회원 정보를 외부 CRM 시스템과 연동해야 한다면, 회원 테이블만 별도 관리하는 게 향후 작업에 유리합니다.

마지막으로, 실시간 트랜잭션 성능과 오프라인 분석 간 우선순위를 구분하는 것도 중요합니다.
실시간 처리가 중요한 데이터와, 배치로 분석하는 데이터가 한 테이블에 섞이면 운영 효율이 급격히 떨어집니다.

예시 코드: 사용자와 회사 관계 테이블 분리

아래 예시는 사용자와 회사가 1:N, N:M 관계로 확장될 수 있음을 감안한 분리 방식입니다.

-- 사용자 테이블
CREATE TABLE users (
  id SERIAL PRIMARY KEY,
  name VARCHAR(100) NOT NULL,
  email VARCHAR(255) UNIQUE NOT NULL,
  created_at TIMESTAMP NOT NULL DEFAULT NOW()
);

-- 회사 테이블
CREATE TABLE companies (
  id SERIAL PRIMARY KEY,
  name VARCHAR(100) NOT NULL,
  created_at TIMESTAMP NOT NULL DEFAULT NOW()
);

-- 사용자-회사 관계 테이블 (N:M 확장 대비)
CREATE TABLE user_company_relations (
  user_id INTEGER REFERENCES users(id),
  company_id INTEGER REFERENCES companies(id),
  role VARCHAR(50),
  PRIMARY KEY (user_id, company_id)
);

이렇게 하면 단일 관계(1:1)에서 추후 N:M 요구사항이 생겼을 때도 구조를 쉽게 확장할 수 있습니다.

MVP 데이터베이스 테이블 분리 적용 체크리스트

• 데이터의 라이프사이클(생성/변경/삭제/보관 정책)이 다른가?
• 자주 바뀌는 데이터와 그렇지 않은 데이터가 한 테이블에 섞여 있지 않은가?
• 조인 없이도 MVP 핵심 기능이 동작하고, 속도 저하가 없는가?
• 향후 3개월 내 확장될 가능성이 높은 요구사항은 무엇인가?
• 데이터 마이그레이션(이관) 시 중단 없이 적용 가능한 구조인가?