데이터베이스 설계는 과소평가된다 — 그리고 많은 개발자들이 막히는 이유

I’m happy to translate the article for you, but I’ll need the full text of the post (the part you’d like translated). Could you please paste the article’s content here? Once I have that, I’ll provide the Korean translation while keeping the source link, formatting, markdown, and any code blocks exactly as they appear.

실제 문제

대부분의 사람들은 바로 테이블로 뛰어들어요—그게 실수입니다.
데이터베이스는 시작점이 아니라 시스템을 이해한 뒤 도착하는 곳입니다.

Source: …

실제로 작동하는 전략

현실 흐름 이해하기

테이블을 하나도 만들기 전에 스스로에게 물어보세요: “실제 상황에서는 무엇이 일어나는가?”
스토리텔러처럼 생각합니다.

예시 (우버와 유사한 시스템):

1. 라이더가 앱을 연다
2. 승차를 요청한다
3. 시스템이 운전자를 찾는다
4. 운전자가 수락한다
5. 여행이 시작된다
6. 여행이 종료된다
7. 결제가 이루어진다

시스템을 간단한 단계로 설명할 수 없으면 데이터베이스를 설계할 수 없습니다.

엔터티 추출하기

흐름에 등장하는 “것들”을 뽑아냅니다.

• 사용자(라이더)
• 운전자
• 여행
• 결제
• 위치

규칙: 시스템 내에서 독립적으로 존재한다면, 그것은 아마 엔터티일 것입니다.

관계 정의하기

스스로에게 물어보세요: “이것들 사이에는 어떤 연결이 있는가?”

• 사용자는 여러 번의 여행을 요청할 수 있다
• 운전자는 여러 번의 여행을 완료할 수 있다
• 한 여행은 하나의 사용자와 하나의 운전자에 속한다
• 한 여행은 하나의 결제를 가진다

이렇게 하면 일대다, 일대일, 다대다 관계가 도출됩니다.

상태 추가하기

실제 시스템은 시간이 지나면서 변합니다. 예를 들어, 여행은 여러 상태 중 하나에 있을 수 있습니다:

• 요청됨
• 수락됨
• 진행 중
• 완료됨
• 취소됨

상태를 저장하면 시스템이 현실적이고 확장 가능해집니다.

이벤트 추적 (메시지, 읽음, 행동)

현대 시스템은 행동을 로그로 남깁니다:

• 운전자가 10:05에 여행을 수락함
• 사용자가 10:07에 여행을 취소함
• 알림 전송됨
• 메시지 읽음

알림, 분석, 히스토리를 지원하기 위해 로그, 활동 테이블, 혹은 메시지 시스템이 필요할 수 있습니다.

다대다 관계를 초기에 처리하기

예시: 운전자는 여러 위치에서 서비스를 제공할 수 있고, 위치도 여러 운전자를 가질 수 있습니다.
조인 테이블을 만들고, 예를 들어 driver_locations 와 같이 정의합니다.

실패에 대해 생각하기

질문:

• 결제가 실패하면 어떻게 할까?
• 운전자가 취소하면 어떻게 할까?
• 사용자가 연결이 끊어지면 어떻게 할까?

데이터베이스는 재시도, 실패 상태, 로그 등을 처리할 수 있어야 합니다. 시스템은 성공 케이스가 아니라 실패 케이스 때문에 깨집니다.

모두 합치기 (Uber 예시)

Entities

• users
• drivers
• rides
• payments

Relationships

• user → rides (1‑to‑many)
• driver → rides (1‑to‑many)
• ride → payment (1‑to‑1)

States

• ride_status (요청됨, 수락됨, 완료됨, …)

Events

• ride_events (수락됨, 취소됨, 시작됨, …)

Failure Handling

• payment_status (대기 중, 실패, 성공)

시스템은 단순히 테이블의 집합이 아니라 살아있는 모델이 됩니다.

이 기술이 필요한 사람은?

• 백엔드 개발자 – 확장 가능한 시스템을 구축하기 위해
• 스타트업 창업자 – 제품을 다시 만들지 않기 위해
• 데이터 엔지니어 – 깔끔한 파이프라인을 구조화하기 위해
• 프로덕트 엔지니어 – 실제로 작동하는 기능을 설계하기 위해

실제 무언가를 만든다면, 이 기술이 필요합니다.

기업이 실제로 활용하는 방법

기업은 데이터베이스 설계를 “추측”하지 않는다. 그들은:

1. 실제 흐름을 매핑한다
2. 시스템을 엔터티로 분해한다
3. 관계를 신중히 정의한다
4. 모든 중요한 이벤트를 추적한다
5. 처음부터 실패에 대비해 설계한다

그들이 시스템을 확장할 수 있는 이유는 사고가 구조화돼 있기 때문이며, 화려한 도구를 사용하기 때문이 아니다.

사용할 수 있는 도구

수동 도구 (사고에 가장 좋음)

• Draw.io
• Whimsical
• 펜과 종이 (매우 과소평가됨)

These force you to understand before building. → 이것은 구축하기 전에 이해하도록 강요합니다.

자동 도구 (속도에 가장 좋음)

• dbdiagram.io
• Prisma ORM (auto schema generation) → Prisma ORM (자동 스키마 생성)
• Django ORM (models → database) → Django ORM (모델 → 데이터베이스)

These help you implement faster. → 이것은 더 빠르게 구현하도록 도와줍니다.

최종 인사이트

데이터베이스 설계는 테이블에 관한 것이 아니라; 다음에 관한 것이다:

• 현실 이해
• 복잡성 구조화
• 시스템적 사고

다음 절차를 따르세요:

1. 흐름
2. 엔터티
3. 관계
4. 상태
5. 이벤트
6. 다대다
7. 실패

다시는 막히는 느낌을 받지 않을 것입니다. 백엔드 엔지니어로 성장하려면, 단순히 코딩만이 아니라 이런 식으로 사고하는 연습을 하세요.

ER 다이어그램 예시