관리자 패널용 읽기 쉬운 데이터베이스 명명 규칙

이름이 관리자 패널을 깔끔하게 보이게 하느냐 어수선하게 보이게 하느냐를 결정한다

대부분의 관리자 패널은 데이터 모델에서 만들어집니다. 테이블과 필드 이름은 메뉴 항목, 페이지 제목, 컬럼 헤더, 필터 레이블, 심지어 사람들이 검색에 입력하는 단어로도 사용됩니다.

이름이 명확하면 관리자는 목록을 훑어보고 몇 초 안에 이해할 수 있습니다. 이름이 불분명하면 멈춰서 추측하고, 레코드를 열어보고, 되돌아가서 다시 시도합니다. 그 망설임은 누적됩니다. "어떤 고객을 찾아야 하나요?" 같은 지원 질문과 아무도 읽고 싶어하지 않는 교육 문서로 이어집니다.

개발자는 보통 빌드와 디버깅을 위해 이름을 짓습니다. 운영자는 일을 하기 위해 이름을 짓습니다. 개발자는 acct, addr1, stat를 기억하기 때문에 괜찮을 수 있지만 운영자는 디코딩 없이 "Account", "Address line 1", "Status"를 필요로 합니다.

관리 화면에서 "읽기 쉬움"은 보통 다음을 의미합니다:

• 테이블을 훑어보고 각 컬럼을 행을 열지 않고 이해할 수 있다.
• 일상 업무에서 사용하는 단어로 검색하고 필터링할 수 있다.
• 날짜는 실제 날짜로, 상태는 일관되게 등 값 비교와 정렬에서 놀라움이 없다.

만약 모델에서 화면을 생성하는 플랫폼(예: AppMaster의 Data Designer 및 관리자 스타일 뷰)을 사용한다면, 명명은 UI 디자인의 일부가 됩니다. 좋은 이름은 레이블과 레이아웃을 다듬기 전에도 처음부터 깔끔한 기본 화면을 제공합니다.

팀 전체가 따를 수 있는 간단한 명명 기준

생성된 관리자 화면이 첫날부터 깔끔해 보이길 원한다면, 아무도 첫 테이블을 추가하기 전에 기준에 합의하세요. 대부분의 명명 문제는 기술적인 문제가 아니라 일관성 문제입니다.

하나의 식별자 스타일을 선택하고 섞지 마세요. 데이터베이스에서는 snake_case가 읽고 검색하기 가장 쉬운 경우가 많습니다. 스택이 camelCase를 기대한다면(테이블, 컬럼, 외래 키, enum 모두) 프로젝트 전체에 걸쳐 그것을 사용하세요. 중간에 스타일을 바꾸면 레이블과 필터가 무작위처럼 느껴집니다.

대부분 팀에 맞는 기준:

• 전체 단어를 사용하세요: customer_id 대신 cust_id를 쓰지 마세요; description 대신 desc를 쓰지 마세요.
• 사물에는 명확한 명사, 동작에는 명확한 동사를 사용하세요: invoice, payment, refund_requested.
• 타임스탬프 이름을 일관되게 하세요: created_at, updated_at, deleted_at.
• data, info, value, type 같은 모호한 단어는 문맥을 추가하지 않는 한 피하세요(예: shipping_address, payout_method).
• 단수형 대 복수형을 일관되게 유지하세요(많은 팀은 customers 같은 복수 테이블과 customer_id 같은 단수 컬럼을 사용합니다).

작은 용어집을 작성하고 눈에 보이게 두세요. customer, client, account, user 중 무엇을 의미하는지 일찍 결정하고 한 용어만 사용하세요. "order" vs "purchase" 또는 "ticket" vs "case"도 마찬가지입니다.

간단한 확인: 두 사람이 account_status 같은 컬럼을 보고 아무 물음 없이 의미를 합의할 수 있다면 기준이 작동하는 것입니다. 합의하지 못하면 스크린과 필터를 만들기 전에 이름을 바꾸세요.

메뉴와 목록에 깔끔하게 매핑되는 테이블 명명 규칙

대부분의 관리자 패널은 테이블 이름을 메뉴 항목, 목록 제목, 브레드크럼으로 바꿉니다. 스키마는 엔지니어만을 위한 것이 아닙니다. UI의 첫 초안입니다.

엔티티 테이블에 한 가지 스타일을 선택하고 지키세요: 단수(user, invoice, ticket) 또는 복수(users, invoices, tickets). 단수형은 폼 제목에 더 잘 읽히는 경우가 많습니다("Edit Ticket"), 복수형은 메뉴에서 더 보기 좋을 수 있습니다("Tickets"). 둘 다 괜찮습니다. 둘을 섞으면 탐색이 일관성 없이 느껴집니다.

테이블 이름은 그 테이블이 무엇인지(사물)를 표현하세요, 무엇을 하는지(동작)를 표현하지 마세요. 테이블은 가리킬 수 있는 사물을 나타내야 합니다. payment는 사물이지만 processing은 동작입니다. 나중에 환불, 재시도, 정산을 추가하면 processing 테이블 이름은 오해를 낳습니다.

메뉴와 목록을 깔끔하게 유지하는 규칙:

• 구체적인 명사 사용(customer, subscription, invoice, ticket_message).
• 영구 데이터를 위한 버킷 테이블(settings, misc, temp, data)은 피하고 실제 엔티티로 분리하세요(notification_setting, tax_rate, feature_flag).
• 밑줄이 있는 짧고 읽기 쉬운 복합 이름을 선호하세요(purchase_order, support_ticket)—약어보다 낫습니다.
• 충돌을 방지할 때만 모듈 접두어를 추가하세요(예: billing_invoice vs invoice). 접두어를 사용하면 모듈 전반에 일관되게 적용하세요.

AppMaster로 스키마에서 직접 화면을 생성한다면, 안정적인 명사 기반 테이블 이름은 기본 메뉴와 목록 뷰를 더 적은 수정으로 깔끔하게 만들어 줍니다.

조인 테이블과 식별자: 다대다를 읽기 쉽게 유지하기

다대다 관계는 관리자 패널이 지저분해지기 쉬운 곳입니다. 조인 테이블과 그 키가 잘 이름 지어지면 생성된 화면은 수동 정리 없이도 읽기 쉬움을 유지합니다.

하나의 단순한 규칙부터 시작하세요: 모든 테이블의 기본 키 이름은 id입니다. 어떤 테이블에서는 기본 키를 user_id로 하고 다른 테이블에서는 id로 섞지 마세요. 식별자가 일관되면 관계가 예측 가능해지고 생성된 폼과 참조 필드가 일관되게 보입니다.

순수 조인 테이블은 두 엔티티의 이름을 사용해 하나의 패턴과 순서로 이름을 짓습니다. 일반적 옵션은 알파벳 순(product_tag) 또는 "주요 항목 우선"(user_role)입니다. 하나의 순서를 정하고 모든 곳에서 지키세요.

links나 mappings 같은 모호한 이름은 테이블이 진정으로 범용 교차-객체 링크를 보관하지 않는 한 피하세요. 대부분의 관리자 패널에서는 구체성이 창의성보다 낫습니다.

조인 테이블이 실제 엔티티가 될 때

관계에 추가 필드가 있다면 그것을 자체 모델로 취급하고 사람들이 이해할 수 있는 명사로 이름 지으세요: membership, assignment, subscription. 예를 들어 사용자의 역할에 starts_at, ends_at, granted_by가 있다면 user_role도 괜찮지만 UI에서는 membership이 더 읽히기 쉬울 수 있습니다.

간단한 규칙 집합:

• 모든 테이블의 기본 키로 id를 사용하세요.
• 조인 테이블은 일관된 순서로 두 엔티티 이름을 사용하세요(user_role).
• 외래 키는 user_id, role_id처럼 명확하게 만드세요.
• 현실을 반영하는 고유성 규칙을 추가하세요(예: user_id당 하나의 role_id).
• 기록을 허용하면 고유성 규칙을 "활성" 레코드에 맞추세요(예: ended_at이 null인 경우에만 고유).

이런 선택은 데이터가 성장해도 유지되며, AppMaster의 Data Designer 같은 도구와도 잘 작동해 스키마에서 곧바로 화면을 생성할 수 있습니다.

명확한 컬럼과 필터를 만들어 주는 필드 명명 패턴

필드 이름은 개발자뿐 아니라 사용자에게도 영향을 줍니다. 컬럼 헤더, 필터 레이블, 폼 필드를 결정합니다.

예측 가능한 접미사는 추측을 줄여줍니다:

• 외래 키는 _id 사용: customer_id, assigned_agent_id.
• 타임스탬프는 _at 사용: created_at, paid_at, closed_at.
• 카운터는 _count 사용: login_count, attachment_count.

불리언은 문장처럼 읽히도록 하세요. is_와 has_를 선호하면 체크박스가 한눈에 이해됩니다: is_active, has_paid, is_verified. is_not_approved 같은 이중 부정은 피하세요. "아님" 상태가 필요하면 긍정형을 모델링하고 코드에서 논리를 반전하세요.

금액 필드는 관리자 그리드에서 혼란의 원인이 됩니다. 한 가지 접근을 선택하고 지키세요: 정수로 소수 단위(예: 센트)를 저장하거나 고정 소수의 소수로 저장하세요. 필드 이름으로 단위를 분명히 하세요. 예: total_amount_cents + currency_code 또는 total_amount + currency_code. price, amount, total을 임의로 섞지 마세요—각각 다른 개념이면 이름으로 구분하세요.

텍스트 필드는 용도를 구체적으로 명시하세요. description은 사용자용, internal_comment는 내부용입니다. notes는 잡다한 용도로 남겨두지 말고 신중히 사용하세요. 여러 개의 노트가 있다면 대상에 따라 이름을 지으세요: customer_note, agent_note.

연락처 필드는 빠른 필터가 되는 경우가 많으니 명확하게 쓰세요: website_url, contact_email, billing_email. AppMaster로 생성된 관리자 화면에서는 이런 이름이 보통 깔끔한 기본 레이블로 바뀝니다.

관계와 외래 키: 데이터 모델을 설명하는 이름

좋은 관계 이름은 평범한 영어처럼 읽힙니다. 데이터베이스에서 관리자 패널을 생성하면 외래 키 이름이 컬럼 제목, 필터, 폼 레이블로 자주 노출됩니다.

하나의 규칙을 지키세요: 외래 키 컬럼은 참조 테이블 이름에 _id를 붙인 형태입니다. customer.id가 있으면 customer_id를 사용하세요. order.id가 있으면 order_id를 사용하세요. 이 일관성은 컬럼이 무엇을 가리키는지 명확하게 합니다.

자기 자신을 참조하는 관계(self-relation)는 나중에 오해하기 쉬우니 더 명확히 하세요. related_id 같은 일반명은 피하고 방향성과 의미를 설명하는 이름을 사용하세요: 트리 구조에는 parent_id, 조직도에는 manager_id, 중복 합치기에는 merged_into_id 등.

조인 테이블과 관련된 관계는 문장처럼 읽히도록 이름을 지으세요. 예를 들어 역할이 "assignee"라면 ticket_assignee.user_id가 ticket_user.user_id보다 더 명확합니다(역할이 "reporter"나 "watcher"일 수도 있기 때문).

실무적 점검:

• owner_id를 여러 테이블에서 다른 의미로 재사용하지 마세요. created_by_user_id, account_manager_user_id, billing_contact_id처럼 구체적으로 만드세요.
• 같은 테이블을 여러 번 참조하면 역할을 포함하세요: requested_by_user_id, approved_by_user_id.
• 하나의 소프트 삭제 표시자를 선택하고 지키세요. deleted_at은 널리 이해되며 필터와 잘 맞습니다.

나중에 AppMaster에서 화면을 만들면 이런 이름들이 곳곳에 표시되므로 초기에 신경을 쓰면 UI 정리에 드는 노력을 크게 줄일 수 있습니다.

시간이 지나도 이해되는 enum과 상태 필드

데이터베이스에서 관리자 화면을 생성할 때 가장 빠르게 화면을 지저분하게 만드는 방법은 많은 작은 플래그에 의미를 흩어놓는 것입니다. 주요 라이프사이클에는 하나의 명확한 상태 enum을 사용하고, 정말 별개의 동작을 위한 플래그만 추가하세요.

유용한 규칙: 사용자가 "이 항목은 여정의 어느 단계에 있나?"라고 묻는다면 그건 상태입니다. "숨겨야 하나?" 또는 "잠겨 있나?" 같은 질문이면 별도 불리언입니다.

하나의 상태가 다섯 개의 불리언보다 낫다

is_new, is_in_progress, is_done, is_cancelled 대신 ticket_status 하나를 사용하세요. 목록 컬럼, 필터, 벌크 액션에서 읽기 쉽고, done + in_progress 같은 불가능한 조합을 피할 수 있습니다.

열거값은 안정적으로 유지하세요. UI 텍스트는 바꿀 수 있지만 저장된 값은 바꾸지 않는 것이 좋습니다. waiting_for_review 대신 pending을, rejected_by_manager 대신 rejected를 저장하세요. 표시 레이블은 나중에 바꿀 수 있습니다.

자세한 정보가 필요하면 상태를 과부하시키지 말고 두 번째 필드를 추가하세요. 예: payment_status를 라이프사이클로 유지하고 필요하면 failure_reason(텍스트)을 추가합니다.

도메인별로 enum 이름을 붙이세요 (그래야 필터가 말이 된다)

여러 모델에 "status"가 있을 때 화면이 읽히도록 도메인 접두어를 사용하세요:

• payment_status (결제 흐름)
• ticket_priority (지원 우선순위)
• user_role (접근 레벨)
• invoice_status (청구 흐름)
• delivery_status (배송 흐름)

라이프사이클과 운영 플래그는 분리하세요. 예: status는 워크플로에서 위치를 설명하고, is_archived는 일상 목록에서 숨겨야 함을 의미합니다.

각 enum 값의 한 줄 설명을 팀 노트에 적어 두세요. 미래의 당신은 cancelled와 voided의 차이를 잊어버릴 수 있습니다. AppMaster를 사용하면 이러한 짧은 정의가 웹과 모바일 화면에서 일관된 드롭다운과 필터를 유지하는 데도 도움이 됩니다.

예외 상황: 날짜, 감사 필드, 그리고 type 컬럼

명명 가이드는 보통 테이블과 기본 필드를 다루지만, 관리자 패널은 예외 상황에서 지저분해집니다. 날짜, 감사 필드, type 컬럼이 혼란스러운 화면으로 이어지는 곳입니다.

날짜와 타임스탬프는 이름으로 상황을 알려야 합니다: 예정인지(actual vs planned), 또는 알림인지. 간단한 패턴은 동사 의미와 명확한 접미사 조합입니다. 예: 예정된 마감은 due_at, 실제 완료는 completed_at처럼요. 실제로 start_date와 end_date가 scheduled_at과 finished_at를 의미한다면 후자가 더 명확합니다.

선택적 관계(optional relation)는 또 다른 함정입니다. 테이블마다 새로운 패턴을 발명하지 마세요. 관계 이름은 고정하고 선택 여부는 null 허용으로 표현하세요. manager_id는 선택적이어도 여전히 manager_id로 남겨두세요.

주소는 코드에서는 괜찮아 보여도 그리드에서는 지저분할 수 있습니다. 줄 번호는 팀 전체가 무엇을 의미하는지 합의했을 때만 괜찮습니다. 명확하게 유지하세요:

• address_line1, address_line2, city, region, postal_code, country_code
• address1, address2는 피하세요(읽기 어려움과 중복 위험).

감사 필드는 일부러 단조롭게 하세요:

• created_at, updated_at
• created_by_id, updated_by_id(정말 사용자 추적이 필요할 때만)

type은 거의 항상 너무 광범위해서 시간이 지나면 엉망이 됩니다. type 대신 의미를 드러내는 이름을 사용하세요: payment_method, ticket_channel, customer_tier. 스키마 기반 관리자 화면(예: AppMaster)에서는 이 한 가지 선택이 명확한 필터와 혼란 없는 드롭다운의 차이를 만듭니다.

예시: 관리자에서 보기 좋은 지원 티켓 모델 이름짓기

작고 현실적인 지원 설정: 고객이 문의를 보내고, 직원이 답장하며, 티켓에 태그를 달 수 있습니다. 명명 규칙은 자동 생성된 메뉴, 목록 화면, 필터가 직관적으로 느껴지게 만드는 요소입니다.

사이드바의 명사처럼 읽히는 테이블 이름부터 시작하세요:

• customer
• ticket
• ticket_message
• ticket_tag
• ticket_tag_link

대부분의 관리자 패널에서 이들은 "Tickets"나 "Ticket Messages" 같은 레이블이 되고, 조인 테이블은 눈에 띄지 않게 됩니다.

티켓 목록 화면을 위해 컬럼 헤더와 필터로 명확하게 보일 필드 이름을 고르세요:

• subject, status, priority
• assigned_to_id(스태프 사용자 참조)
• last_message_at(최근 순 정렬에 사용)
• created_at(표준적이고 예측 가능)

Enum은 나중에 읽기 쉽지 않게 깨지기 쉬우니 값 집합은 안정적이고 단순하게 유지하세요:

• ticket_status: new, open, pending_customer, resolved, closed
• ticket_priority: low, normal, high, urgent

항상 혼동을 막는 한 가지 선택: "customer"를 과부하시키지 마세요. 요청자는 항상 고객이 아닐 수 있습니다(동료가 대신 제출할 수 있음). 제출한 사람을 저장한다면 requester_id로 명명하고, 티켓이 관련된 계정을 별도로 customer_id로 저장하세요. 그 구분은 처음부터 폼과 필터를 사실대로 유지합니다.

단계별: 스크린을 만들기 전에 새 모델의 이름을 어떻게 정할까

화면을 이미 만들고 있을 때 이름을 짓지 말고, 일상 언어로 생각하고 있을 때 이름을 정하면 스크린을 읽기 쉽게 유지하는 가장 쉬운 방법입니다.

모든 기능에 적용 가능한 반복 가능한 프로세스

1. 미니 용어집(5~10개)을 만드세요. 비기술 동료가 회의에서 쓸 단어들을 적고, 각 개념에 대해 하나의 기본 용어를 선택하세요(예: "customer" vs "client").

2. 예상되는 화면들을 스케치하세요: 목록, 상세, 생성, 편집. 목록 뷰에서 즉시 명확해야 하는 5~8개의 컬럼을 결정하세요. 컬럼 헤더로 이상하게 보일 필드명은 수정이 필요합니다.

3. 테이블과 관계를 설계한 뒤 접미사 규칙(*_id, *_at, is_*, *_count)을 사용해 필드 이름을 정하세요. 나중에 관리자 화면을 생성하면(예: AppMaster) 이러한 패턴이 깔끔한 레이블과 예측 가능한 필터를 만들어 줍니다.

진행하기 전에 스타일을 섞고 있지 않은지 확인하세요(customer_id가 한 테이블에 있고 다른 테이블에 clientId가 섞여 있는지 등). 일관성이 창의성보다 낫습니다.

4. enum을 UI가 생기기 전에 미리 정의하세요. 각 값의 한 줄 의미를 적으세요(지원팀에게 설명하듯이). 변화에 잘 견디는 값(pending, active, archived)을 선호하세요(예: new, newer, newest는 피함).

5. "컬럼 헤더 읽기 통과(column header read-through)"를 하세요. 관리자 사용자가 테이블을 훑는다고 상상하고 읽어보세요:

• "Created At", "Updated At", "Status", "Assigned To", "Total Amount" 같은 헤더가 교육 없이도 의미가 통하나요?
• 어떤 필드가 내부 코드(tmp_flag, x_type, data1)처럼 들리나요?
• 단위가 분명한가요(amount_cents vs amount, duration_seconds vs duration)?

말해 보았을 때 이상하게 들리는 것이 있으면 지금 이름을 바꾸세요. 나중에 바꾸는 것은 가능하지만 보고서, 필터, 사용 습관에 스며들기 쉽습니다.

관리자 패널을 사용하기 어렵게 만드는 흔한 명명 실수

스키마가 지저분하면 UI가 아무리 좋아도 화면은 지저분해집니다. 명명 규칙은 "스타일" 문제가 아니라 일상적 사용성 문제입니다.

첫 번째 함정은 용어 혼용입니다. 한 테이블은 client라고 하고 다른 테이블은 customer라고 하면 메뉴, 필터, 검색 결과가 서로 다른 것을 설명하는 것처럼 느껴집니다. 핵심 개념마다 한 단어를 선택하고 관계 이름까지 포함해 일관되게 사용하세요.

두 번째 흔한 문제는 과도한 축약입니다. addr, misc, info 같은 약어는 몇 글자를 아끼지만 테이블과 내보내기에서 가독성을 크게 떨어뜨립니다.

세 번째 실수는 UI 흐름을 데이터베이스에 굽어넣는 것입니다. new_customer_wizard_step 같은 필드는 출시 시에는 의미가 있지만 흐름이 바뀌거나 두 번째 온보딩 경로가 생기면 혼란을 줍니다. 비즈니스 사실을 저장하세요(예: onboarding_status)—UI가 사용자 안내를 결정하게 하세요.

불리언 과다도 조심하세요. is_new, is_open, is_closed를 추가하면 결국 충돌(두 개가 동시에 true)이 생기고 필터가 불분명해집니다. 작은 잘 정의된 값 집합을 가진 단일 상태 필드를 선호하세요.

흉악한 신호(관리자 화면을 보기 어렵게 만드는 것들):

• 같은 것을 다른 이름으로 부름(client_id와 customer_id 혼용)
• 잡다한 데이터를 담는 칼럼(notes, misc, extra)
• 캠페인 이름처럼 시간 의존적인 필드(summer_campaign_*)
• 하나의 상태를 설명하려다 여러 불리언이 생김
• 마이그레이션 계획 없이 캐주얼하게 이름 변경

이름 변경은 단순한 찾기-치환이 아닙니다. customer_phone을 phone_number로 바꾼다면 마이그레이션을 계획하고 생성된 화면들을 업데이트하며 다른 시스템이 API를 읽는 경우 호환성을 유지해야 합니다. AppMaster에서는 깨끗한 이름이 즉시 보상을 줍니다: 목록, 폼, 필터가 모델에서 라벨을 상속하므로 수정할 부분이 줄어듭니다.

관리자 패널을 배포하기 전 빠른 체크리스트

스키마를 "완료"로 부르기 전에 매일 관리자 패널에서 살 사람의 관점에서 한 번 검토하세요.

• 테이블이 실물을 나타내는가. 동료가 테이블이 무엇을 나타내는지(ticket, customer, invoice) 추측 없이 말할 수 있는가?
• 핵심 필드가 예측 가능한 접미사를 따르는가. 사람들이 한눈에 인식하는 패턴: *_id(참조), *_at(타임스탬프), *_amount(또는 *_amount_cents)(금액), is_*(불리언).
• Enum이 안정적이고 단순한가. pending, paid, failed 같은 값을 저장하고 UI 문구는 나중에 바꿀 수 있도록 하세요.
• 새 동료가 의미를 유추할 수 있는가. 생성된 목록 뷰에 도움말 없이도 의도가 명확한가?
• 모호한 단어를 제거하거나 구체화했는가. data, value, type, info 같은 쓰레기 서랍 이름을 status, source, category, notes, external_reference 같은 구체적 이름으로 교체하세요.

AppMaster의 Data Designer로 스키마에서 관리자 스타일 뷰를 생성한다면 이 체크리스트는 즉시 실용적입니다: 명확한 이름은 명확한 컬럼과 필터로 이어지고, 사용자들이 시스템을 실제로 사용하면서 레이블을 패치하는 시간을 줄입니다.

다음 단계: 명명 습관을 만들고 화면을 일관되게 유지하세요

좋은 명명은 일회성 정리가 아닙니다. 스키마가 성장할 때마다 관리자 UI를 읽기 쉽게 유지하는 작은 루틴입니다.

기존 모듈 하나를 선택하고 다음 새 테이블에만 규칙을 적용해 보세요. 대규모 리팩토링을 피하면서 연습할 실제 장소를 마련할 수 있습니다. 예를 들어 다음 기능이 주문 시스템에 "returns"를 추가한다면 테이블, 외래 키, 상태를 처음부터 규칙에 맞춰 이름 짓고 다음 기능에도 같은 접근을 재사용하세요.

스키마 작업 옆에 한 페이지 분량의 명명 가이드를 두세요. 짧게 유지하세요: 테이블, 기본 키, 외래 키, 타임스탬프, 상태 enum을 어떻게 이름 지을지. 목표는 긴 논쟁이 아니라 빠른 결정입니다.

AppMaster로 빌드한다면 Data Designer에 이러한 패턴을 설정한 다음 UI 화면을 건드리기 시작하세요. 이름을 바꿀 때는 앱을 재생성해서 화면, API, 로직이 흩어지지 않도록 하세요.

배포 전 가벼운 리뷰 단계만 있으면 충분할 때가 많습니다:

• 테이블과 필드 이름이 메뉴 항목, 컬럼 헤더, 필터로 읽히는가?
• 상태와 enum이 추가 설명 없이도 명확한가?
• 관계와 외래 키가 스스로 설명하는가(미스터리 약어 없음)?
• 유사 모델이 일관된 이름 규칙을 따르는가(같은 단어, 같은 순서)?

시간이 지나며 진짜 이득은 일관성입니다. 모든 새 모델이 같은 규칙을 따르면 자동 생성된 화면도 설계된 것처럼 보이기 시작합니다. 레이블과 목록이 일관된 제품처럼 읽히기 때문입니다.