07 — 의사결정 매트릭스 (Decision Matrix)
한 줄 답: ORM 선택은 4축 × 5도구의 매트릭스로 한 페이지에서 결정 가능하다. 축은 팀 규모, 타입 정확도 요구, SQL 친밀도, 마이그레이션 빈도 — 도구는 TypeORM · Prisma · Drizzle · MikroORM · Sequelize. 이 페이지가 결정 회의의 단일 자료다.
Why — 왜 결정 매트릭스가 필요한가
ORM 선택 회의는 한 시간 안에 결정나야 한다. 그러지 못하면 결정이 한 주를 넘어가고 결국 default로 묻힌다. 매트릭스의 역할:
- 모든 후보 도구를 같은 축에서 비교
- 팀의 현재 상태를 축에 점찍기
- 축의 합으로 도구가 자동 추천
- 판단 근거를 나중에 검증 가능하도록 기록
How — 4축의 정의
축 1 — 팀 규모
| 단계 | 정의 | 함의 |
|---|---|---|
| S (1-3명) | 솔로/소규모 | 단순함과 생산성이 매출. 학습 곡선 비싸다. |
| M (4-10명) | 중간 팀 | 코드 일관성과 onboarding이 중요. |
| L (10-30명) | 큰 팀 | 패턴 일관성, 도메인 분리, type-safety가 매출. |
| XL (30+명) | 다중 팀/플랫폼 | DDD, Bounded Context, 도구의 철학까지 중요. |
축 2 — 타입 정확도 요구
| 등급 | 정의 | 도메인 예 |
|---|---|---|
| 낮음 | 런타임 에러 허용, any OK | 내부 도구, 어드민, 프로토타입 |
| 중간 | TS strict 모드만 충족 | SaaS CRUD, 콘텐츠 사이트 |
| 높음 | 모든 필드의 부분 select까지 정확 | 결제, 핀테크, 헬스, 거래 시스템 |
축 3 — SQL 친밀도
| 등급 | 정의 | 함의 |
|---|---|---|
| 낮음 | SQL 거의 모름 | ORM 추상이 필수. raw SQL은 마지막 수단. |
| 중간 | 기본 SQL OK, JOIN 까지는 | TypeORM의 QueryBuilder 정도면 충분. |
| 높음 | 윈도우 함수·CTE·MATERIALIZED VIEW까지 | SQL DSL (Drizzle, Kysely)이 바로 읽힌다. |
축 4 — 마이그레이션 빈도
| 등급 | 정의 | 함의 |
|---|---|---|
| 낮음 | 월 1~2회 | 도구 무관. CLI만 있으면 됨. |
| 중간 | 주 1~2회 | 자동 generate 안정성이 생산성. |
| 높음 | 매일/MR마다 | 안정적 generate가 매출. Prisma 우세. |
What — 매트릭스
5도구 × 4축 적합도 (10점 만점)
| 축 | TypeORM | Prisma | Drizzle | MikroORM | Sequelize |
|---|---|---|---|---|---|
| 팀 규모 S | 7 | 9 | 8 | 5 | 6 |
| 팀 규모 M | 8 | 9 | 7 | 7 | 6 |
| 팀 규모 L | 7 | 9 | 7 | 8 | 5 |
| 팀 규모 XL | 6 | 8 | 6 | 9 | 4 |
| 타입 낮음 | 8 | 7 | 7 | 7 | 7 |
| 타입 중간 | 7 | 9 | 8 | 7 | 5 |
| 타입 높음 | 5 | 10 | 8 | 6 | 3 |
| SQL 낮음 | 8 | 8 | 4 | 7 | 7 |
| SQL 중간 | 8 | 8 | 7 | 7 | 6 |
| SQL 높음 | 6 | 7 | 9 | 6 | 5 |
| 마이그레이션 낮음 | 7 | 8 | 8 | 7 | 6 |
| 마이그레이션 중간 | 6 | 9 | 8 | 7 | 5 |
| 마이그레이션 높음 | 5 | 10 | 8 | 6 | 4 |
시나리오별 추천
| 시나리오 | 추천 |
|---|---|
| 솔로 개발자, MVP, 빠른 검증 | Prisma — 타입·DX·자료 풍부. Drizzle도 OK. |
| 중간 팀, NestJS 모놀리스, CRUD 위주 | TypeORM — NestJS 통합·자료·익숙함. |
| 중간 팀, SaaS, 강한 타입 필요 | Prisma — 타입 정확도가 압승. |
| 큰 팀, 결제·핀테크 | Prisma — 타입 정확도가 매출. |
| 큰 팀, DDD/CQRS, 복잡 도메인 | MikroORM — 진짜 UoW와 IdMap. |
| 서버리스/엣지, Vercel/Cloudflare | Drizzle — cold start 0, ESM 우선. |
| OLAP·분석 대시보드 | Drizzle 또는 Kysely — SQL DSL. |
| 레거시 JS 코드베이스 | Sequelize 유지 — 점진 TS 이주. |
| Rails 출신 팀 | Sequelize (ActiveRecord) 또는 TypeORM (BaseEntity 모드). |
| 데코레이터 + Hibernate 경험자 | MikroORM — 익숙한 패러다임. |
한 페이지 결정 흐름도
What-if — 매트릭스를 무시하면
1) “유행을 따라” Drizzle 선택했는데 팀이 SQL을 모른다
→ Drizzle의 SQL DSL이 그대로 노출되어 모든 쿼리에서 헤맨다. 생산성 50% 떨어진다. 대응: 매트릭스의 SQL 친밀도 축을 솔직히 평가. 낮으면 TypeORM 또는 Prisma.
2) “타입이 더 정확하니까” Prisma 선택했는데 NestJS의 모든 모듈을 쓴다
→ @nestjs/typeorm이 들어간 third-party 모듈 5개를 다시 짜야. 3주 추가.
대응: NestJS 통합도 매트릭스에 추가. 본질이면 TypeORM 유지.
3) “DDD니까” MikroORM 선택했는데 팀이 ORM 경험이 없다
→ Unit of Work·Identity Map의 학습 곡선만 지불하고 가치를 못 본다. 대응: 팀 ORM 경험도 매트릭스에 추가. 처음이면 TypeORM 또는 Prisma.
4) “TypeORM이 사실상 표준이니까” 선택했는데 서버리스로 갈 계획
→ 1년 후 Vercel/Lambda로 이주 시 cold start 손해. Drizzle로 재이주 비용 발생. 대응: 향후 배포 모델을 지금 결정에 반영.
5) 매트릭스 없이 “익숙함”만으로 선택
→ 6개월 후 후회의 issue가 Slack에 매일 쌓인다. 근거 없는 결정은 책임 추적 불가. 대응: 결정 근거를 매트릭스로 기록하고 PRD에 첨부.
Insight — 흥미로운 이야기
”결정 매트릭스가 결정을 자동화하진 않는다”
매트릭스의 진짜 가치는 답을 자동으로 주는 것이 아니라 결정 근거를 명시적으로 만드는 것이다.
매트릭스 없이 결정하면 *“왜 TypeORM이지?”*에 *”…그게 익숙해서요”*라는 답밖에 안 나온다. 6개월 뒤 후회하면 원인 추적이 불가능하다.
매트릭스가 있으면 *“팀 규모 M + 타입 중간 + SQL 중간 + 마이그레이션 중간 → TypeORM 적합 7점, Prisma 9점. Prisma를 골랐다”*는 명확한 추적 가능 결정이 남는다. 나중에 검증할 수 있다.
”State of JS 2023의 실측 결정”
State of JS 2023 설문은 18,000명 개발자의 실제 도구 선택을 보여준다. ORM 부문:
| 도구 | ”사용 중” 비율 | ”다시 쓸 것” 비율 |
|---|---|---|
| Prisma | 36% | 92% |
| TypeORM | 33% | 60% |
| Sequelize | 24% | 51% |
| Drizzle | 11% | 88% |
| MikroORM | 4% | 78% |
“다시 쓸 것” 비율이 진짜 신호다. Prisma 92%, Drizzle 88%, MikroORM 78% — 모두 TypeORM의 60%보다 높다. 시장이 매트릭스로 결정한 결과.
”한 회사가 여러 도구를 동시에”
Vercel은 내부에 Prisma + Drizzle을 동시에 쓴다. 서비스의 영역에 따라:
- 제품 핵심 (대시보드, 빌링) — Prisma (타입 정확도)
- 서버리스 함수, 엣지 API — Drizzle (cold start)
이게 현실의 정답이다. 한 도구로 통일하지 않는다. 각 자리에 가장 적합한 도구.
”ORM 자체가 도구다 — Strangler Fig”
매트릭스의 최종 교훈은 *“ORM 자체가 도구”*라는 것. 종교가 아니다. 언제든 갈아탈 수 있다. Strangler Fig 패턴으로 부분 이주가 가능하다. 한 번 결정해도 영원하지 않다.
6개월 뒤 팀 규모가 커지고 타입 정확도 요구가 올라가면 — 매트릭스를 다시 그려 재결정한다. 이게 살아 있는 결정 프로세스다.
요약 + 다이어그램
ORM 선택은 4축 × 5도구 매트릭스로 한 페이지 결정. 축은 팀 규모 · 타입 정확도 · SQL 친밀도 · 마이그레이션 빈도. 결정 근거를 매트릭스로 기록하고 PRD에 첨부해 나중 검증 가능하게 한다. Strangler Fig로 부분 이주가 가능 — 결정은 영원하지 않다.
챕터 완료. 다음 챕터(
09-real-world-cases)는 이 매트릭스를 실제 회사들이 어떻게 적용했는지를 본다.