3-1. 축약어 사용의 함정

과거 DBMS는 이름 길이가 8자, 16자로 제한되는 경우가 많아서 축약어 사용이 거의 필수였다. 지금은 이름 길이 제한이 거의 없고, IDE의 자동완성 기능도 매우 강력하다.

그럼에도 "타이핑이 귀찮다"는 이유로 의미가 모호한 축약어를 쓰면, 시간이 지날수록 의미를 해석하는 비용이 커지고 유지보수성이 떨어진다.

대표적인 문제는 다음과 같다.

• 새로운 개발자가 축약어 의미를 이해하느라 시간을 낭비한다.
• 축약어를 오해하면 잘못된 쿼리를 작성해 버그로 이어진다.
  • 예: auth_status가 인증 상태인지, 권한 상태인지 모호하다.

3-2. 좋은 축약어의 조건

모든 축약어가 나쁜 것은 아니다. 다음 조건을 만족하면 좋은 축약어라고 볼 수 있다.

1. 보편성(Universality)
   • 업계에서 널리 사용되고, 대부분의 개발자가 바로 이해할 수 있어야 한다.
   • 예: id, avg, max, min, qty 등
2. 비모호성(Unambiguity)
   • 하나의 의미로만 해석되는 축약어여야 한다.
   • 예: desc는 설명(description)과 내림차순(descending)을 모두 떠올리게 하므로 피한다.
   • auth도 author, authentication, authorization 등으로 해석될 수 있어 모호하다.
3. 일관성·문서화(Consistency & Documentation)
   • 도메인 특화 약어를 사용한다면, 반드시 용어 사전/데이터 사전에 등록해 의미를 문서화한다.
   • 예: 금융의 pnl(profit and loss), 쇼핑몰의 sku(Stock Keeping Unit) 등

핵심 원칙은 "의심스러우면 축약하지 않는다" 이다.

3-3. 균형을 찾는 실무 가이드

현실에서는 명확성과 편의성 사이의 균형을 잡는 것이 중요하다.

1. 테이블 이름으로 컨텍스트를 파악할 수 있다면 접두사를 과감히 생략한다.
   • member 테이블 안에서 member_name, member_email 대신 name, email로 충분하다.
   • 다만 너무 많은 테이블에서 같은 컬럼 이름을 사용할 경우, 조인 시 혼동이 잦다면 접두사를 고려한다.
2. 보편적인 축약어는 적극적으로 활용한다.
   • 예: id, qty, avg, no, dt 등
   • 예: product_average_rating_point → product_avg_rating 정도로 줄여도 의미가 잘 전달된다.
3. 이름이 너무 길다면 모델링 자체를 의심한다.
   • primary_shipping_address_street_and_postal_code 같은 컬럼은, 사실 "주소"라는 개념을 별도 테이블 또는 복수 컬럼으로 분리했어야 할 가능성이 크다.
   • 긴 이름을 억지로 줄이기보다, 구조 자체를 개선해야 한다.

3-4. 테이블 이름: 단수 vs 복수

테이블 이름을 단수(singular)로 할지, 복수(plural)로 할지는 오래된 논쟁이다.

• 복수형 주장
  • 예: members, products, orders
  • 테이블이 동일한 구조의 여러 행(row) 집합이므로 복수형이 자연스럽다는 의견이다.
  • SELECT * FROM members처럼 문장이 자연스럽게 읽힌다는 장점이 있다.