표준단어사전 만드는 법 — 항목 구성부터 운영까지

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

공유 드라이브 어딘가에 표준단어사전_v2.3_최종.xlsx가 있는 조직이 많습니다. 수천 행짜리 시트이고, 몇 년 전 표준화 사업 때 만들어졌고, 마지막 수정일은 담당자가 바뀌기 전입니다. 그리고 지난달에 만들어진 테이블의 컬럼명은 그 시트를 열어 보지 않고 지어졌습니다.

이 글은 그 시트를 다시 만드는 법에 대한 글입니다. 다만 “다시 만들기”의 대부분은 항목을 채우는 일이 아니라 결정을 내리는 일이라서, 어떤 항목이 필요한지보다 어떤 순서로 결정해야 하는지에 지면을 더 씁니다. 표준단어사전이 데이터 표준화 전체에서 어떤 위치인지는 데이터 표준화란 무엇인가에서 다뤘고, 이 글은 그중 단어사전 하나를 깊게 들어갑니다.

표준단어사전이 하는 단 하나의 일

표준단어사전은 업무에서 쓰는 낱말 하나를 물리명에서 쓸 표준 약어 하나에 대응시키는 표입니다. 공공 부문 데이터 표준화 지침들이 말하는 “표준단어”가 이것이고, 원칙은 하나뿐입니다. 한 낱말에 약어는 하나다.

원칙이 하나뿐인데 지켜지지 않는 이유도 하나입니다. 약어는 만드는 순간이 아니라 찾아보지 않는 순간에 갈라집니다. “번호”의 약어가 NO로 정해져 있어도, 마감에 쫓기는 개발자가 사전을 열어 보지 않으면 그날 NUM이 하나 태어납니다. 그래서 사전의 품질은 행 수가 아니라, 컬럼명을 짓는 순간에 사전이 개입하는가로 결정됩니다. 이 문제는 글 마지막에 다시 다루고, 먼저 사전 자체를 제대로 만드는 법부터 보겠습니다.

항목 구성 — 여섯 칸이면 충분합니다

표준단어사전 양식은 조직마다 다르지만, 실제로 일을 하는 칸은 여섯 개입니다.

영문명은 생략되기 가장 쉬운 칸인데, 약어의 근거가 되는 칸입니다. CUST는 Customer의 약어라는 기록이 있어야 나중에 CSTM 같은 변종이 제안됐을 때 무엇이 기준인지 말할 수 있습니다.

동의어는 삭제 대상이 아니라 등록 대상입니다. “거래처”를 사전에서 지운다고 현장에서 그 말이 사라지지 않습니다. 대표어 “고객” 아래에 동의어로 묶어 두면, 누가 어떤 낱말로 찾아도 같은 약어에 도달합니다. 동의어를 지우는 사전은 검색에 실패하고, 검색에 실패한 사용자는 새 단어를 등록합니다.

만드는 순서 — 백지에서 시작하지 않습니다

1. 현행 스키마에서 역추출합니다. 빈 시트에 “우리가 쓸 단어”를 상상해서 채우는 방식은 실패합니다. 지금 운영 중인 DB의 테이블·컬럼명을 구분자 기준으로 낱말 단위로 쪼개고, 빈도순으로 정렬하는 것이 첫 작업입니다. 이 목록이 곧 “우리 조직이 실제로 쓰는 어휘”이고, 상위 수백 개가 사전의 초안입니다. 이 과정에서 NUM·NBR·NO가 몇 벌씩 공존하는 현실이 수치로 드러나는데, 그 목록이 다음 단계의 재료입니다.

2. 동의어를 먼저 정리합니다. 약어를 정하기 전에, 추출된 낱말 중 같은 대상을 가리키는 것들을 묶고 대표어를 정합니다. “고객”과 “회원”이 같은가 다른가는 약어 문제가 아니라 업무 정의 문제이고, 여기서 결정을 미루면 사전이 갈등을 봉인한 채 두 항목을 다 갖게 됩니다. 다르다면 왜 다른지 정의 칸에 한 줄 적어 두는 것까지가 이 단계입니다.

3. 약어를 정합니다 — 이미 굳은 것부터. 새 약어 생성 규칙(모음 제거, 앞 네 글자 등)을 먼저 정하고 전 단어에 일괄 적용하고 싶은 유혹이 있는데, 권고는 반대입니다. NO, DT, AMT, YN처럼 업계에서 이미 굳은 관용 약어를 먼저 그대로 채택하고, 생성 규칙은 관용이 없는 새 단어에만 씁니다. 규칙의 일관성보다 현장에서 이미 통용되는 표기와의 일치가 사전의 수용도를 결정합니다. 약어 길이는 2~4자 안에서, 정한 약어끼리 충돌(서로 다른 단어가 같은 약어)이 없는지는 이 단계에서 전수 확인합니다.

4. 금칙어와 폐기어를 등록합니다. DB 예약어(ORDER, GROUP, LEVEL 등)와 이번 정리에서 버린 옛 약어(NUM, NBR)를 기록합니다. 폐기어를 기록하지 않으면 다음 담당자가 선의로 되살립니다. 사용 여부 칸이 있는 이유입니다.

5. 규모를 욕심내지 않습니다. 공공 부문의 공통 표준단어 목록처럼 수천 행짜리 기성 사전을 통째로 들여오는 방식은, 우리 업무에 없는 단어 수천 개 속에 우리 단어 수백 개가 묻히는 결과가 됩니다. 1번에서 추출한 실사용 어휘를 기준으로 시작하고, 기성 사전은 약어를 정할 때 참조하는 사전(辭典)으로 쓰는 편이 낫습니다. 몇백 행이면 대부분의 조직에서 실질 커버리지가 나옵니다.

운영 — 사전은 완성되는 문서가 아닙니다

만드는 것보다 유지가 어렵습니다. 세 가지가 정해져 있어야 합니다.

추가 절차. 새 단어가 필요한 사람이 어디에 어떻게 요청하고, 누가 승인하는지가 정해져 있지 않으면 두 가지 중 하나가 됩니다 — 요청이 막혀서 사전 밖에서 이름이 지어지거나, 아무나 추가해서 사전이 다시 갈라지거나. 제안과 승인이 분리된 한 갈래 경로가 있어야 합니다.

개정 시 소급 범위. 약어를 바꾸면 이미 배포된 스키마는 어떻게 할 것인가. 권고는 명명 규칙 글과 같습니다 — 신규부터 적용하고, 기존은 어차피 손댈 때 함께 고치되, 낡았다는 사실은 기록합니다.

소유자. “표준화 담당”이 조직도에서 사라지는 순간 사전은 갱신이 멈춥니다. 팀이 바뀌어도 역할이 승계되도록, 사전의 소유자를 사람이 아니라 역할로 지정해 두는 편이 안전합니다.

엑셀로 관리할 때 부딪히는 벽

여기까지 잘 만들어도, 사전이 엑셀 파일이면 구조적인 문제 세 개가 남습니다.

첫째, 사본이 갈라집니다. 메일에 첨부되는 순간 사전은 두 개가 되고, _최종과 _진짜최종이 나란히 존재하게 됩니다. 어느 쪽이 진실인지는 파일이 답해 주지 않습니다.

둘째, 검색은 되지만 강제는 안 됩니다. 엑셀은 “번호의 약어가 무엇인가”에는 답하지만, 개발자가 NUM이라고 타이핑하는 것을 막지 못합니다. 성실한 사람이 찾아볼 때만 작동하는 표준은, 글 앞에서 말했듯 마감 앞에서 무너집니다.

셋째, 사전과 스키마의 거리를 아무도 모릅니다. 사전이 개정된 뒤 실제 DB가 얼마나 벌어져 있는지는 사람이 전수 대조하기 전에는 알 수 없고, 그래서 대조는 분기 점검 때나 한 번 일어납니다. 위반이 만들어지는 시점과 발견되는 시점 사이가 석 달이면, 그 표준은 규칙이 아니라 사후 보고서입니다.

셋의 공통점은 사전의 내용이 아니라 사전이 놓인 위치가 문제라는 점입니다. 사전이 모델과 다른 곳에 있는 한, 둘 사이를 잇는 것은 사람의 성실함뿐입니다.

사전이 모델 안에 있으면 달라지는 것

Sqemo는 단어사전이 별도 파일이 아니라 ERD 모델과 같은 곳에 있는 도구입니다. 위에서 말한 항목 구성이 그대로 들어 있습니다 — 논리 단어, 표준 약어, 영문명, 설명, 동의어, 사용 여부.

그리고 위치가 바뀌면 동작이 바뀝니다.

• 엔터티나 속성에 논리명을 적으면 사전과 명명 규칙에 따라 물리명이 생성됩니다. “고객 번호”라고 적으면 CUST_NO가 계산되어 나오고, 사람이 약어를 타이핑할 자리가 없으니 NUM이 태어날 자리도 없습니다. 아래는 같은 엔터티의 논리 뷰와 물리 뷰입니다 — 사람이 적은 것은 왼쪽 한글 논리명뿐이고, 오른쪽 물리명은 전부 위 사전에서 계산된 결과입니다.

  

  

• 동의어도 같은 약어로 수렴합니다. “거래처”를 동의어로 등록해 두면, 논리명에 어느 낱말을 쓰든 대표 약어로 변환됩니다.

• 사전에 없는 낱말은 그 자리에서 미등록 경고가 뜹니다. 분기 점검이 아니라 이름을 짓는 순간이 검사 시점입니다.

• 쓰던 엑셀 사전은 CSV로 저장해서 그대로 가져올 수 있습니다(logicalWord, physicalWord, abbreviation, englishName, description, enabled, synonyms 헤더). 역추출로 만든 초안을 붙여 넣는 자리이기도 합니다.

• CI에서는 npx sqemo-mcp lint schema.erd.json이 프로젝트 파일의 미등록 낱말과 물리명 드리프트를 검사해, 위반이 있으면 빌드를 실패시킵니다.

단어사전·명명 규칙·물리명 생성은 무료 기능이고 가입 없이 로컬 파일로 바로 쓸 수 있습니다. 팀 전체가 하나의 사전을 공유하고 단어 추가를 제안·승인 절차로 관리하는 기능은 요금제에서 확인하실 수 있습니다. 동작 세부는 Naming Standards 문서 (영문)에 있습니다.

엑셀 사전을 다시 정비할 계획이라면, 정비한 결과를 다시 엑셀에 담을지부터 생각해 보시길 권합니다. 같은 자리에 두면 같은 이유로 낡습니다. 브라우저에서 바로 열어 지금 쓰는 사전 CSV를 가져와 보면, 사전이 이름을 생성하는 쪽이 어떤 느낌인지 몇 분 안에 확인하실 수 있습니다.