데이터 표준화란 무엇인가 — 단어사전·용어사전·도메인 정리

2026년 8월 13일 · 갱신 2026년 8월 22일

한 시스템 안에서 같은 대상이 CUST_NO, CUSTOMER_ID, MBR_NO 세 가지 이름으로 존재하는 상황을 한 번쯤 보셨을 겁니다. 조회 화면에서는 “고객번호”, 정산 배치에서는 “회원번호”, 신규 API 스펙에서는 customerId로 불립니다. 세 이름이 같은 값을 담고 있다는 사실은 문서 어디에도 적혀 있지 않고, 몇 년째 그 시스템을 만진 사람의 머릿속에만 있습니다.

데이터 표준화는 이 상황을 푸는 작업입니다. 흔히 “이름 규칙을 정하는 일”로 축소해서 이해하지만, 실제로는 세 가지 서로 다른 결정을 한꺼번에 정리하는 일입니다. 어떤 단어를 어떤 약어로 쓸 것인가, 그 단어를 조합한 업무 용어가 정확히 무엇을 뜻하는가, 그리고 그 용어가 물리적으로 어떤 타입과 길이를 갖는가. 이 셋이 각각 단어사전, 용어사전, 표준 도메인입니다.

데이터 표준화가 실제로 푸는 문제

이름이 세 개로 갈라지면 비용은 이름 자체가 아니라 그 뒤에서 발생합니다.

조인이 안 됩니다. CUST_NO가 VARCHAR(20)이고 MBR_NO가 NUMBER(10)이면 두 테이블을 붙이는 순간 형변환이 끼어들고, 인덱스는 조용히 무시됩니다.
집계가 어긋납니다. “고객 수”를 세는 쿼리가 두 벌 생기고, 두 숫자가 다르게 나옵니다. 어느 쪽이 맞는지 판단하려면 두 컬럼의 정의를 아는 사람을 찾아야 합니다.
신규 인력의 학습 비용이 누적됩니다. 새로 합류한 개발자는 스키마를 읽는 대신 사람을 붙잡고 물어봐야 합니다. 이 비용은 시스템이 커질수록 선형이 아니라 그 이상으로 늘어납니다.

그래서 표준화의 목적은 “예쁜 이름”이 아니라 예측 가능성입니다. 논리적으로 같은 대상이면 어느 테이블에서든 같은 이름, 같은 타입, 같은 의미를 갖는다는 보장을 만드는 것이 목적입니다. 국내 공공 부문에서 널리 쓰이는 데이터 표준화 지침들도, 국제 메타데이터 표준인 ISO 11179 계열도 결국 이 보장을 어떻게 만들 것인가를 다룹니다. 표현 방식은 다르지만 공통적으로 단어 · 용어 · 도메인이라는 세 층을 분리해서 관리하라고 말합니다.

단어사전 — 표준화의 최소 단위

단어사전은 업무에서 쓰는 낱말 하나를 물리명에서 쓸 표준 약어 하나에 대응시킨 표입니다. 가장 작고, 가장 먼저 만들어야 하는 자산입니다.

논리 단어	표준 약어	비고
고객	`CUST`	회원과 구분
번호	`NO`	`NUM`, `NBR` 금지
일자	`DT`	시각까지 담으면 `DTM`
금액	`AMT`
여부	`YN`

단어사전이 하는 일은 단순하지만 효과가 큽니다. 하나의 낱말에 약어가 하나만 존재하도록 강제하기 때문에, NUM·NBR·NO가 뒤섞이는 상황이 원천에서 사라집니다. 실무에서 단어사전을 만들 때 자주 걸리는 지점은 세 가지입니다.

첫째, 동의어를 먼저 정리해야 합니다. “고객”과 “회원”이 같은 대상인지 다른 대상인지 결정하지 않은 채 약어부터 정하면, 표준이 갈등을 봉인해 버립니다. 다르다면 왜 다른지 한 줄로 적어 두는 편이 좋습니다.

둘째, 금칙어를 함께 관리합니다. 예약어(ORDER, GROUP, LEVEL 등)나 이미 폐기한 옛 약어를 금칙어로 등록해 두면, 나중에 누군가 되살리는 일을 막을 수 있습니다.

셋째, 미등록 단어를 어떻게 처리할지 정해야 합니다. 사전에 없는 낱말이 나왔을 때 경고만 띄울지, 그대로 쓸지, 로마자로 옮길지에 따라 표준의 성격이 달라집니다. 경고를 택하면 사전이 계속 자라고, 그대로 쓰기를 택하면 사전은 장식이 됩니다.

단어사전을 실제로 만드는 순서 — 현행 스키마에서 역추출하고, 동의어를 먼저 정리하고, 약어와 운영 절차를 정하는 과정 — 는 표준단어사전 만드는 법에서 따로 깊게 다룹니다.

용어사전 — 조합된 업무 용어와 그 정의

단어사전이 낱말 단위라면, 용어사전은 그 낱말을 조합한 업무 용어 단위입니다. “고객”과 “번호”를 합친 “고객번호”가 용어이고, 여기에는 약어 조합(CUST_NO) 외에 하나가 더 붙습니다. 바로 정의입니다.

단어사전 용어사전 차이를 한 줄로 정리하면 이렇습니다. 단어사전은 표기를 통일하고, 용어사전은 의미를 통일합니다.

이 차이가 왜 중요한지는 예를 보면 분명해집니다. “가입일자”라는 용어의 약어 조합은 JOIN_DT 하나로 결정됩니다. 그런데 이 값이 회원가입 신청을 누른 시점인지, 본인인증까지 끝난 시점인지, 관리자 승인이 떨어진 시점인지는 약어가 알려 주지 않습니다. 세 부서가 각자 다른 시점을 넣고 있어도 컬럼명은 완벽하게 표준을 지킵니다. 이름 규칙만으로는 절대 잡히지 않는 종류의 불일치입니다.

그래서 용어사전 항목에는 최소한 이 정도가 필요합니다.

용어명과 그 물리 약어 조합
정의 — 한 문장으로, 경계 사례를 포함해서. “가입일자: 본인인증이 완료되어 계정이 활성화된 시각”
연결된 도메인 — 아래에서 다룰 타입·길이 표준
사용처 — 이 용어가 실제로 쓰이는 엔터티 목록

마지막 항목이 특히 중요합니다. 용어사전이 별도 문서로 존재하면 “이 용어를 어디서 쓰고 있는가”를 아무도 답할 수 없고, 정의를 고쳐도 영향 범위를 알 수 없어 결국 아무도 고치지 않게 됩니다.

표준 도메인 — 타입·길이·형식의 묶음

표준 도메인은 같은 성격의 값이 항상 같은 물리 타입과 길이를 갖도록 묶어 둔 단위입니다. 용어 하나하나에 타입을 붙이는 대신, 성격별로 만든 도메인에 용어를 연결합니다.

도메인	타입	설명
식별번호	`VARCHAR(20)`	채번 규칙이 있는 키 값
명칭	`VARCHAR(100)`	사람이 읽는 이름
일자	`DATE`	날짜만
일시	`TIMESTAMP`	날짜와 시각
금액	`DECIMAL(15,2)`	통화 단위 별도
여부	`CHAR(1)`	`Y`/`N`

표준 도메인을 두면 얻는 것은 두 가지입니다. 하나는 일관성입니다. “명칭” 도메인에 연결된 컬럼은 전부 VARCHAR(100)이므로, 어떤 테이블에서는 50자이고 다른 테이블에서는 255자인 상황이 생기지 않습니다. 다른 하나는 변경의 국소화입니다. 명칭 길이를 200자로 늘려야 할 때 도메인 하나만 고치면 되고, 영향을 받는 컬럼 목록이 곧바로 나옵니다. 도메인 없이 컬럼마다 타입을 직접 적어 두었다면 이 작업은 전수 조사가 됩니다.

도메인을 설계할 때는 지나치게 잘게 쪼개지 않는 편이 좋습니다. 도메인이 컬럼 수만큼 늘어나면 도메인이 아니라 그냥 타입 목록입니다. 대략 십수 개에서 수십 개 사이가 관리 가능한 규모입니다.

셋이 맞물리는 방식 — 논리명에서 물리명까지

세 자산은 따로 쓰이지 않습니다. 하나의 생성 경로로 이어질 때 비로소 값을 합니다.

논리명   "고객 가입 일자"
  │
  │  단어사전:  고객→CUST · 가입→JOIN · 일자→DT
  ▼
물리명   CUST_JOIN_DT
  │
  │  명명 규칙:  대문자 · 언더스코어 구분
  ▼
용어사전  "고객가입일자" = 본인인증이 완료된 시각
  │
  │  도메인:  일시 → TIMESTAMP
  ▼
DDL      CUST_JOIN_DT  TIMESTAMP  NOT NULL

이 경로가 성립하면 사람이 물리명을 타이핑할 이유가 사라집니다. 논리명을 업무 언어로 적으면 물리명은 계산된 결과이고, 계산된 결과는 사람마다 달라지지 않습니다. 표준을 “지키는” 일이 아니라 “생성되는” 일이 되는 것, 이것이 데이터 표준화가 도달해야 할 상태입니다.

예외가 필요한 경우도 있습니다. 외부 시스템과 맞춰야 하는 레거시 컬럼처럼 생성 결과를 쓸 수 없는 자리입니다. 이때 중요한 것은 예외를 금지하는 것이 아니라 예외를 눈에 보이게 하는 것입니다. 수동으로 지정한 물리명은 그렇게 표시되어야 하고, 단어사전이 바뀌어도 조용히 덮어써지지 않아야 합니다. 보이지 않는 예외가 쌓이는 순간 표준은 신뢰를 잃습니다.

표준이 지켜지지 않는 이유

여기까지가 교과서적인 내용이고, 대부분의 조직은 이미 이 세 가지를 어떤 형태로든 가지고 있습니다. 그런데도 현장의 스키마는 표준과 다릅니다. 이유는 하나입니다.

문서는 스스로를 강제하지 못합니다.

단어사전이 엑셀 파일로 공유 드라이브에 있고, 용어사전이 위키 페이지에 있고, 도메인 표가 표준화 산출물 PDF 안에 있다면, 이 셋과 실제 DDL 사이를 잇는 것은 개발자의 성실함뿐입니다. 성실함은 마감 앞에서 가장 먼저 양보되는 자원입니다. 구체적으로는 이런 방식으로 무너집니다.

급한 요건이 들어오고, 컬럼 하나를 손으로 추가합니다. 사전을 열어 볼 시간이 없습니다.
단어사전이 개정되지만, 이미 배포된 스키마는 개정 전 약어를 그대로 씁니다. 사전과 DB 중 어느 쪽이 진실인지 모호해집니다.
표준을 검토하는 자리는 분기에 한 번 열리고, 그 사이 석 달 치 위반이 쌓입니다. 되돌리기에는 이미 늦습니다.
표준을 잘 아는 담당자가 부서를 옮깁니다. 사전은 남지만 판단 근거는 남지 않습니다.

핵심은 검사 시점입니다. 표준 위반이 컬럼을 만드는 그 순간에 드러나지 않고 분기 점검에서 드러난다면, 그 표준은 사후 보고서일 뿐 규칙이 아닙니다. 반대로 위반을 만들 수 없게 되어 있다면 점검 자체가 거의 필요 없어집니다.

도구가 해야 할 일

그래서 데이터 표준화 지침을 실제로 작동시키려면 도구가 최소한 다음을 해야 합니다.

단어사전·용어사전·도메인이 모델과 같은 곳에 있을 것. 별도 파일로 분리되는 순간 동기화 문제가 생기고, 동기화 문제는 항상 문서 쪽이 집니다.
물리명을 생성할 것. 사람이 타이핑한 이름을 사후에 검사하는 방식은 이미 늦습니다.
예외를 표시할 것. 수동 지정은 허용하되 표시되고, 자동 재생성에서 제외되어야 합니다.
팀 전체가 같은 사전을 볼 것. 각자 로컬 사본을 들고 있으면 사전이 갈라집니다.
CI에서 검사할 것. 표준 위반으로 빌드가 깨져야 규칙이 됩니다.

Sqemo는 이 다섯 가지를 전제로 만든 ERD 도구입니다. 논리명을 적으면 단어사전과 명명 규칙에 따라 물리명이 생성되고, 용어사전 화면은 별도 문서가 아니라 모델에서 파생되어 같은 용어에 정의가 두 개 붙거나 도메인이 엇갈리는 지점을 그 자리에서 표시합니다. 도메인은 타입과 길이를 한곳에서 관리하고, 수동 오버라이드는 표시된 채 자동 재생성에서 빠집니다. CI에서는 npx sqemo-mcp lint schema.erd.json 이 프로젝트 파일의 미등록 낱말과 물리명 드리프트를 검사해 위반이 있으면 빌드를 실패시킵니다. 위에서 말한 용어 정의 충돌과 도메인 엇갈림은 앱의 용어사전 화면에서 드러나는 것이고, 이 명령의 검사 항목은 아닙니다. 명명 규칙과 용어사전의 동작 세부는 Naming Standards 문서 (영문)에 정리되어 있습니다.

단어사전·용어사전·도메인·명명 규칙은 무료 기능이고 가입 없이 로컬 파일로 바로 쓸 수 있습니다. 팀 단위로 하나의 표준을 공유하고 단어 추가를 제안·승인 절차로 관리하는 기능은 요금제 페이지에서 확인하실 수 있습니다.

표준화 문서를 다시 정비하기 전에, 지금 쓰는 도구가 위 다섯 가지 중 몇 개를 해 주고 있는지 먼저 확인해 보시길 권합니다. 문서를 아무리 잘 써도 강제하는 지점이 없으면 다음 분기에 같은 자리에 서 있게 됩니다. 브라우저에서 바로 열어 쓰던 스키마를 가져와 보시면, 지금 표준과 실제 스키마가 얼마나 벌어져 있는지 몇 분 만에 확인하실 수 있습니다.