테이블명 단수형 vs 복수형 장단점 및 선택 가이드

데이터베이스 테이블명을 지을 때 “단수형이 맞을까, 복수형이 맞을까?”
이 간단한 선택이 ORM 프로젝트에서는 꽤 중요한 결정이 됩니다.

이번 글에서는 테이블명 단수형 vs 복수형의 차이와,
혼용으로 인한 실제 문제 사례, 그리고 실무에서 쓰이는 해결 방법까지
개발자 시선으로 쉽게 정리했습니다.

테이블명 단수형 vs 복수형 핵심 비교표

구분	단수형 예: user, order	복수형 예: users, orders
가독성	클래스명(User)과 일관됨	실제 데이터 집합 의미에 부합
ORM 매핑	별도 설정 없이 자동 매핑 용이	@Table 등 추가 설정 필요
유지 보수	단일 규칙으로 간결	s, es, ies 등 예외 많음
영어 문법 부담	거의 없음	단어별 복수형 규칙 달라 혼란 가능
추천 상황	JPA, Hibernate 등 ORM 프로젝트	SQL 중심 수동 쿼리 환경

테이블명 복수형을 쓸 때 생기는 영어 문법 문제

영어의 복수형 규칙은 생각보다 복잡합니다. 단순히 s만 붙는 게 아닙니다.

단어	복수형	비고
user	users	일반적인 경우
category	categories	y → ies 변환
analysis	analyses	단어 형태가 완전히 바뀜
sheep	sheep	변하지 않는 경우

이 때문에 팀 내에서 규칙이 명확하지 않으면,
테이블명 오타, 매핑 실패, 코드 일관성 붕괴 같은 문제가 실제로 발생합니다.

혼용이 문제의 시작이다

단수형이든 복수형이든 정답은 없습니다.
문제는 ‘혼용’입니다.

예를 들어 일부 테이블은 user, 일부는 orders처럼 섞여 있으면,
엔티티 매핑 시 혼란이 커지고 쿼리 작성 시 일관성이 깨집니다.
특히 ORM은 네이밍 매핑을 기반으로 자동화가 이뤄지기 때문에 일관성이 유지되지 않으면 개발자의 불필요한 고민이 많아지고, 생산성도 급격히 떨어집니다.

해결 방법 정리

1. 클래스/테이블명을 모두 단수로

• 예시:
  • 클래스: User, 테이블: user
• 예약어 충돌 시: app_user, member 등 다른 이름으로 회피
• 장점:
  • 네이밍이 단순하고 직관적
  • ORM 자동 매핑에 가장 적합
• 단점:
  • 회피할 단어를 선택할 때 고민이 많아짐

2. 클래스는 단수, 테이블은 복수로 하고 @Table로 매핑

@Entity
@Table(name = "users")
public class User {
    ...
}

• 장점: 데이터 집합 의미를 명확하게 표현 가능
• 단점: 모든 엔티티마다 @Table 설정이 필요

3. 클래스/테이블명을 모두 단수로, globally_quoted_identifiers 설정 사용 (비추천)

Hibernate에서는 아래 설정으로 테이블명을 자동으로 따옴표(")나 백틱(“)으로 감싸기를 할 수 있습니다.

hibernate.globally_quoted_identifiers=true

이 설정을 사용하면 예약어(order, group, user 등)와의 충돌을 자동으로 회피할 수 있습니다.

• 장점: 예약어 문제 자동 해결
• 단점: 로그에서 쿼리를 확인할 때 따옴표나 백틱이 포함되어 가독성이 다소 떨어질 수 있음, DB 툴에서 직접 확인할 때도 예약어와 충돌되는 테이블은 따옴표나 백틱을 붙여줘야 하는 불편함이 있음

🔗 공식 문서 참고: Ctrl + F로 globally_quoted_identifiers를 검색하면 찾을 수 있음
Hibernate ORM User Guide

결론: 핵심은 단수형이냐? 복수형이냐? 가 아닌 일관성

정답은 단수형도, 복수형도 아닙니다.
중요한 건 팀 전체가 하나의 원칙으로 통일하는 것입니다.

테이블명 혼용은 장기적으로 기술 부채(technical debt)로 쌓입니다.
초기 설계에서 한 번 명확히 정하고, 팀 컨벤션 문서로 고정하는 것이 가장 중요합니다.

자주 묻는 질문 (FAQ)