레코드 식별 필드

상태: 공통 표준 — 2026-10-07 KST 사용자 결정

적용 대상: company-wide — 직원이 다루는 Leysys 제품·서비스의 업무 레코드(고객·멤버·차량·계약·파트너·상품 등)의 식별·분류 필드와 삭제 규칙

정본 분류: 이 페이지는 leysys-design의 결정 기록 RECORD-IDENTITY-FIELDS-2026-10-07을 회사 공통 표준으로 공개합니다. 규칙을 바꿀 때는 결정 기록과 이 페이지를 함께 고칩니다. 화면 표현(머리글·요약·목록)의 구현 정본은 leysys-design이, 각 제품의 레코드 종류·접두어·상태 흐름·채택 현황·의도적 편차는 해당 제품 저장소와 제품 Docs가 소유합니다. 문서 변경은 런타임 채택을 증명하지 않습니다.

레코드를 알아보는 정보는 여섯 가지입니다. 고유코드, 관리코드, 등록번호·등록코드, 유형, 상태, 이름입니다. 모든 레코드가 여섯 가지를 다 갖지는 않습니다. 그 정보가 있으면 이 이름과 이 규칙으로 다룹니다.

원칙

• 고유코드만 모든 레코드에 있습니다. 나머지 다섯 가지는 그 정보가 실제로 있는 레코드에만 둡니다.
• 정보가 없는 레코드에 빈 필드나 가짜 값을 만들지 않습니다. 예를 들어 차량처럼 번호로 식별하는 대상에 이름을 만들지 않습니다.
• 같은 역할의 정보는 제품이 달라도 같은 이름·같은 규칙으로 다룹니다.

필드

필드	정하는 쪽	중복	바꾸기	데이터 이름
고유코드	시스템	불가(전역)	불가	id
관리코드	시스템 자동 채번, 등록할 때 직접 입력 가능	불가(레코드 종류별, 소유 범위 안)	불가	managementCode
등록번호·등록코드	사용자(자동완성 가능)	허용	정정으로만	종류별(businessRegistrationNumber 등)
유형	정해진 목록에서 선택	—	등록번호와 묶이면 정정으로만	type
상태	정해진 흐름	—	흐름대로만	status
이름	사용자	허용	편집	name · shortName

고유코드

• 시스템이 만들고, 전역에서 유일하며, 바뀌지 않습니다. 데이터 이름은 id입니다.
• 다른 레코드는 이 값으로 연결합니다. URL과 연동에도 이 값을 씁니다.
• 화면의 식별 정보로 보여 주지 않습니다. 고유코드 자체가 목적인 화면(전자서명 문서 검증 등)만 예외입니다.
• 사람이 읽는 번호(관리코드·등록번호·방 번호 등)를 고유코드로 겸하지 않습니다. 그 번호의 형식이나 범위가 바뀌면 모든 연결이 흔들립니다.

관리코드

• 고객이 쥐는 안정된 식별 번호입니다. 등록할 때 정하고, 한 번 정하면 바꿀 수 없습니다. 정정 기능도 없습니다.
• 시스템이 자동으로 채번합니다. 등록하는 사람은 원하면 직접 입력할 수 있고, 비워 두면 자동 번호가 됩니다. 제품은 조직이 레코드 종류별로 직접 입력을 막는 설정을 둘 수 있습니다.
• 자동 번호는 저장할 때 확정합니다. 입력 화면에 미리 보여 준 번호는 확정 값이 아닙니다.
• 레코드 종류마다, 그 레코드를 소유하는 범위(워크스페이스 또는 조직) 안에서 유일합니다. 다른 조직의 코드와는 겹쳐도 됩니다. 비교할 때 앞뒤 공백과 대소문자를 무시합니다.
• 오타는 삭제 후 다시 등록합니다(아래 「삭제·사용 중지·취소」). 삭제할 수 없는 레코드(다른 기록이 참조함, 확정 기록)는 사용 중지·취소한 뒤 새로 등록하거나, 오타라도 그 코드를 계속 씁니다.
• 바뀔 수 있는 값(유형·상태·담당·지역 등)을 코드에 넣지 않습니다. 넣으면 그 값이 바뀔 때 코드가 틀린 정보가 됩니다.
• 자동 채번의 기본 형식은 「접두어-일련번호」입니다(예: CUS-000123). 접두어는 레코드 종류를 나타냅니다. 일련번호는 늘어나기만 하고, 삭제로 빈 번호를 채우지 않습니다. 사람이 읽고 부르기 어려운 무작위 문자열이나 시각 값은 쓰지 않습니다.
• 자동 번호가 이미 있는 코드(삭제한 코드 포함)와 겹치면 그 번호를 건너뜁니다.
• 직접 입력은 영문·숫자·하이픈(-)만 받고 대문자로 저장합니다. 바코드·연동·대소문자 혼동을 피하려는 것입니다.
• 법령이 번호 규칙을 정한 문서(세금계산서 등)는 그 법령을 따릅니다. 이 표준은 그런 문서 번호를 다루지 않습니다.

오타를 정정 기능 대신 삭제 후 다시 등록으로 고치는 이유

• 「아직 안 쓰였을 때만 관리자가 정정」하려면 아직 안 쓰였다는 확인이 필요합니다. 시스템은 시스템 안의 참조만 확인할 수 있고, 출력물·메일·전화로 이미 밖에 알려졌는지는 아무도 확인할 수 없습니다.
• 삭제 후 다시 등록하면 그 확인이 필요 없습니다. 삭제할 수 있는지는 시스템이 확인할 수 있는 참조만으로 정해집니다. 지운 코드를 다시 쓰지 않으니, 밖에 알려진 옛 코드가 다른 대상을 가리키는 일도 없습니다.
• 관리코드에는 예외 없는 「수정 불가」만 남습니다. 정정 권한이나 정정 절차를 따로 만들 필요가 없습니다.

등록번호·등록코드

• 대상을 알아보는 데 쓰는 번호입니다(준식별). 외부 기관이 준 번호(사업자등록번호·법인등록번호·자동차등록번호 등)와, 조직이 정해 고객에게 보여 주는 코드(제품등록코드 등)가 있습니다.
• 화면 이름에는 종류와 「등록」을 넣습니다(사업자등록번호, 제품등록코드). 「등록번호」라고만 쓰거나 「○○코드」로 쓰지 않습니다. 관리코드는 별도 체계라 「등록」을 붙이지 않습니다.
• 사용자가 입력합니다(자동완성 가능). 중복을 허용합니다. 같은 대상을 두 번 등록해야 할 때가 있고, 둘은 관리코드로 구분합니다. 같은 번호가 이미 있으면 알려 줄 수 있지만 막지 않습니다.
• 바꿀 수 있지만 일반 편집으로는 바꾸지 않습니다. 등록한 뒤에는 「정정」으로 바꾸고, 이전 값·새 값·사유·정정 주체를 이력에 남깁니다. 연동·회계·감사가 이 번호를 쓰기 때문입니다.
• 종류마다 형식을 확인합니다. 국내 등록번호(주민등록번호·외국인등록번호·법인등록번호·사업자등록번호·고유번호)는 검증 숫자로 저장을 막지 않습니다(2026-10-10 KST 개정). LEI처럼 국제 표준이 검증 숫자를 유효성 요건으로 정한 번호는 그 표준을 따릅니다.
  • 법인등록번호는 2025-01-31 KST 이후 부여분에 검증 숫자가 없습니다.
  • 사업자등록번호의 검증번호 계산식은 국세청이 공개하지 않습니다. 업계에서 쓰는 검증식은 경고로만 씁니다.
  • 공식 확인은 발급 기관의 확인 수단(국세청 진위확인 등)으로 합니다. 번호별 규칙은 당사자와 사업자를 따릅니다.
• 다른 기록과 연결하는 키로 쓰지 않습니다. 연결은 고유코드로 합니다.
• 데이터 이름은 종류별(businessRegistrationNumber 등)입니다. 다만 한 레코드가 여러 종류 중 하나를 가지면(사업자등록번호 또는 고유번호 등) 중립 이름과 종류(registrationNumber + registrationType)를 씁니다(2026-10-10 KST 개정, 사업자).
• 주민등록번호처럼 법이 수집을 제한하는 번호는 법령 근거가 있을 때만 받고, 화면에서는 가려서 보여 줍니다.

유형

• 레코드 종류마다 정해진 목록에서 고릅니다. 조직이 목록을 관리하면, 항목은 바뀌지 않는 key와 바꿀 수 있는 이름을 가지고, 쓰인 항목은 지우지 않고 숨깁니다.
• 유형이 등록번호 형식·증빙·필수 항목을 정하면(개인·법인 구분 등) 등록번호와 함께 잠그고 정정으로만 바꿉니다. 그렇지 않은 분류(회의 종류 등)는 일반 편집으로 바꿀 수 있습니다.
• 유형을 바꿔도 관리코드는 그대로입니다.

상태

• 상태 값과 바꿀 수 있는 흐름은 레코드 종류마다 제품이 정합니다. 화면은 지금 상태에서 갈 수 있는 상태만 보여 줍니다.
• 저장하는 값은 key이고, 라벨은 화면에서만 씁니다. 한국어 라벨 같은 표시 문자열을 값으로 저장하지 않습니다.
• 조직이 상태 목록을 관리하면 key는 바뀌지 않고 이름은 바꿀 수 있으며, 쓰인 상태는 지우지 않고 숨깁니다.
• 상태 변경은 이력에 남깁니다. 사유를 받을지는 제품이 정합니다.

이름

• 사용자가 입력하고 바꿀 수 있으며, 중복을 허용합니다. 이름이 같은 고객은 관리코드로 구분합니다. 이름이 같은 레코드가 있으면 알려 줄 수 있지만 막거나 자동으로 합치지 않습니다.
• 이름으로 식별하는 레코드에서는 필수입니다.
• name·displayName은 줄이지 않고, shortName·shortDisplayName만 전각 7칸(7ic)에서 줄입니다.
• 법인·사업자는 화면 라벨을 「상호」로 쓸 수 있습니다. 데이터 이름은 name 하나입니다.

삭제·사용 중지·취소

• 삭제는 다른 기록이 참조하지 않는 레코드에만 됩니다. 판정은 시스템(데이터베이스 참조 제약 또는 서버 확인)이 합니다. 사람이 「아직 안 쓰였다」를 판단하지 않습니다.
• 참조가 있으면 삭제하지 않고 상태를 바꿉니다(사용 중지·보관 등). 그러면 새로 고르는 목록에서 빠지고, 이미 연결된 기록에는 그대로 보입니다.
• 확정 기록(발송된 고지서, 확정된 투표 결과, 서명이 끝난 문서 등)은 삭제하지 않고 취소하거나 정정합니다. 삭제는 복구할 수 있는 삭제이고, 영구 삭제는 관리자가 보존 기한을 확인하고 사유를 남긴 뒤에만 합니다 (접근 역할 체계).
• 관리코드는 다시 쓰지 않습니다. 복구하면 같은 코드로 돌아옵니다. 영구 삭제한 뒤에도 코드와 삭제 시각·삭제 주체 (deletedAt·deletedBy)는 남깁니다.
• 삭제·사용 중지·취소는 이력에 남깁니다.

화면 표현

• 고유코드는 보이지 않습니다.
• 관리코드는 상세 머리글 우측 상단에 작게 둡니다. 요약·식별 카드·목록 열 등 다른 곳에 두지 않습니다. 목록 검색은 관리코드로도 찾을 수 있게 합니다.
• 등록번호와 이름은 목록과 상세의 주요 식별 정보입니다. 목록은 주 식별자를 첫 열에 두고, 상세는 머리글 아래 요약에 둡니다. 값이 없으면 —를 표시합니다.
• 관리코드 입력란은 만드는 화면에만 둡니다(비워 두면 자동). 편집 화면에는 두지 않습니다.
• 편집 화면에서 등록번호와 묶인 유형은 읽기 전용이고, 바꾸는 길은 「정정」입니다.

다루지 않는 것

• 관리코드 정정 기능: 위 이유로 두지 않습니다.
• 레코드 병합(중복 등록된 두 레코드를 하나로 합치기): 필요해지면 따로 정합니다.
• 법령이 정한 문서 번호(세금계산서 등)의 연속 번호 규칙.
• 접두어 목록과 일련번호 자릿수: 제품이 레코드 종류마다 정합니다.

관련 문서

• 접근 역할 체계 — 삭제·영구 삭제 권한, 행위 주체 필드({동사}edAt·{동사}edBy)
• leysys-design docs/decisions/RECORD-IDENTITY-FIELDS-2026-10-07.md — 결정 근거와 제품 현황