산업 참고 가이드

법률 문서 명명 규칙

UTBMS 코드, Bates 번호, EDRM 통합, 특권 보호, 분야별 명명 패턴까지 — 법률 운영 담당자, 패러리걸, 또는 로펌 관리자가 방어 가능한 문서 명명 시스템을 구현하는 데 필요한 모든 내용을 담았습니다.

6개 실무 분야 다룸35 UTBMS codes 수록EDRM 9단계 매핑됨판례 검증됨

법률 명명 표준

방어 가능한 법률 문서 명명 규칙은 이 패턴을 사용합니다: {MatterNumber}_{DocumentType}_{Date}_{Version}.{ext}

사건 번호를 먼저 — DMS(iManage, NetDocuments)와 정렬되고, 윤리 장벽 시행을 가능하게 하며, UTBMS 청구 코드에 매핑됩니다.
UTBMS에 맞춘 문서 유형 — 일관된 약어(MSJ, Memo, DepTranscript, Complaint)를 UTBMS 작업 범주에서 도출해 사용하면 모든 팀원이 같은 방식으로 분류합니다.
ISO 8601 날짜 + 버전 — YYYY-MM-DD는 모든 OS와 DMS에서 시간순으로 정렬됩니다. 버전 접미사(v1, v2, DRAFT, FINAL)는 "final_FINAL(2)" 문제를 방지합니다.

iManage를 통해 AmLaw 100 로펌의 90%가 사용합니다. UTBMS (ABA/ACC, 1995) 및 EDRM 프레임워크 (2005)와 정렬됩니다.

표준 법률 규칙Naming pattern

{MatterNo}_{DocType}_{Court}_{Date}_{Version}.{ext}

Result2024-1547_MSJ_SDNY_2026-03-15_v2.docx

중요한 이유

명명 규칙은 정리 문제가 아니라 컴플라이언스 문제입니다

대부분의 산업에서 일관성 없는 파일명은 불편한 문제에 그칩니다. 그러나 법률 실무에서는 책임 문제를 만듭니다. 잘못 이름 붙여진 문서는 특권 검토 중 누락되거나, 실수로 상대방 변호사에게 제출되거나, 법적 보존 중 간과될 수 있으며, 이 모든 경우는 제재, 과실 책임 청구, 또는 변호사-의뢰인 특권 포기로 이어질 수 있습니다.

그 위험은 수치로 확인할 수 있습니다. Qualcomm Inc. v. Broadcom Corp.에서는 문서 관리 실패로 인해 850만 USD의 제재와 6명의 변호사에 대한 State Bar 회부가 있었습니다. 법원은 이를 "중대하고 의도적인 증거개시 위반"이라고 했습니다.

이 가이드의 대상

법률 운영 담당자, 패러리걸, 소송 지원 관리자, 로펌 관리자, 그리고 로펌 또는 기업 법무 부서에서 문서 명명 표준을 구현하거나 평가하는 모든 분을 위한 가이드입니다.

분류 표준

UTBMS 작업 코드

Uniform Task-Based Management System (UTBMS)는 1995년에 ABA Section of Litigation, Association of Corporate Counsel (ACC), 그리고 PricewaterhouseCoopers (PwC)가 법률 업무를 예산 및 청구용으로 분류하는 방식을 표준화하기 위해 개발했습니다. 원래 Litigation Code Set은 1997년에 5개 단계와 29개 작업 코드로 발표되었습니다. 2011년에는 LEDES Oversight Committee (LOC)가 e-Discovery를 위한 여섯 번째 단계(L600)를 비준했습니다.

문서 명명에서 UTBMS 코드는 파일명 규칙의 문서 유형 구성요소에 대해 통제된 어휘를 제공합니다. 이를 통해 모든 팀원이 문서를 같은 방식으로 분류하고, 파일명이 사건 예산 및 e-billing 요구사항과 일치하도록 합니다.

L100 — 사건 평가, 개발 및 관리

코드	작업
L110	사실 조사/개발
L120	분석/전략
L130	전문가/컨설턴트
L140	문서/파일 관리
L150	예산 수립
L160	합의/비구속 ADR
L190	기타 사건 평가

L200 — 재판 전 소장 및 신청

코드	작업
L210	소장
L220	가처분/임시 구제수단
L230	법원 명령 회의
L240	종국적 신청
L250	기타 서면 신청/제출
L260	집단소송 인증 및 통지

L300 — 증거개시

코드	작업
L310	서면 증거개시
L320	문서 제출
L330	증언 녹취
L340	전문가 증거개시
L350	증거개시 신청
L390	기타 증거개시

L400 — 재판 준비 및 재판

코드	작업
L410	사실 증인
L420	전문가 증인
L430	서면 신청/제출
L440	기타 재판 준비 및 지원
L450	재판 및 심리 출석
L460	재판 후 신청 및 제출
L470	집행

L500 — 항소

코드	작업
L510	항소 신청 및 제출
L520	항소 이유서
L530	구두변론

L600 — e-Discovery

코드	작업
L600	식별
L610	보존
L620	수집
L630	처리
L650	검토
L660	분석
L670	제출
L680	프레젠테이션
L690	프로젝트 관리

비소송 코드 세트

UTBMS는 Bankruptcy (B-codes), Counseling (C-codes), Project (P-codes)용 코드도 정의합니다. 원칙은 동일합니다 — 각 코드는 청구 범주에 매핑되며, 이는 명명 규칙에서 문서 분류 태그로도 사용할 수 있습니다.

제출 표준

Bates 번호

Bates 번호(Bates stamping이라고도 함)는 문서 제출의 모든 페이지에 고유한 순차 식별 번호를 부여합니다. 이름은 Edwin G. Bates에서 유래했으며, 그는 19세기 말 Bates Automatic Numbering Machine을 발명했습니다. 이는 손잡이를 누를 때마다 자동 증가하는 네 자리 숫자(0000–9999)를 찍는 휴대용 장치였습니다.

Bates 번호 형식Naming pattern

{Prefix}-{SequentialNumber}

ResultSMITH-000001

형식 규칙

알파벳 접두사는 제출 당사자를 식별합니다(SMITH, DEF, ACME_PI). 0으로 채운 순차 번호(6–9자리)를 사용합니다. 스탬프는 각 페이지의 오른쪽 아래에 배치합니다. District of Maryland ESI Principles는 4자리 영숫자 접두사와 9자리 숫자 값을 권장합니다.

필요한 경우

사실상 모든 미국 민사소송에서 표준 관행입니다. 법원 ESI 프로토콜은 제출 전에 당사자들이 Bates 형식에 합의할 것을 요구합니다. 증언 전시물, 재판 전시물, 공식 문서 제출에 필요합니다. 정확한 인용이 가능해집니다: "See DEF-004523."

파일명과 Bates 번호

내부 파일명과 Bates 번호는 별도의 시스템이며 서로 조정되어야 합니다. 파일명은 제출 전 문서를 정리하고, Bates 번호는 제출 시점에 적용됩니다. 제출 과정에서 문서는 Bates 범위로 이름이 변경됩니다(예: DEF-000001.tif). 로드 파일(.dat)은 Bates 번호를 원래 파일명 및 메타데이터에 다시 매핑합니다.

eDiscovery 프레임워크

EDRM — eDiscovery에서 명명의 위치

2005년에 George Socha와 Tom Gelbmann이 만든 Electronic Discovery Reference Model (EDRM)은 생성부터 법정 프레젠테이션까지 ESI를 관리하는 9단계를 정의합니다. 소송 전에 구조화된 명명을 구현한 로펌은 전체 모델 전반의 비용을 줄이며, 특히 Processing(더 저렴한 중복 제거), Review(더 빠른 검토자 이해), Production(더 적은 명명 충돌)에서 효과가 큽니다.

Information Governance

소송 전에 명명 정책을 수립합니다. 일관된 규칙은 문서를 더 쉽게 식별하고 분류할 수 있게 하여 후속 eDiscovery 비용을 줄입니다.

Identification

설명적인 파일명은 custodian 인터뷰에 도움이 됩니다. "2024-1547_MSJ_SDNY_2026-03-15.docx"는 "Document1_final_FINAL(2).docx"보다 즉시 식별할 수 있습니다.

Preservation

법적 보존 통지는 사건 번호로 문서를 참조합니다. 일관된 명명은 DMS, 이메일, 클라우드 스토리지 전반에서 자동 보존 스캔을 가능하게 합니다.

Collection

구조화된 이름의 파일은 사건 번호나 날짜 범위로 선별 수집할 수 있어 과잉 수집 및 관련 비용을 줄입니다.

Processing

검토 플랫폼에 수집할 때 원래 파일명은 메타데이터 필드가 됩니다. 구조화된 이름은 더 나은 중복 제거와 family grouping을 가능하게 합니다.

Review

문서는 플랫폼이 부여한 ID로 추적되지만, 원래 파일명은 검토 인터페이스에 표시되어 검토자의 이해와 코딩 정확도에 도움이 됩니다.

Production

문서는 Bates 번호를 부여받고 제출 체계에 맞게 이름이 변경됩니다(예: DEF-000001.tif). 로드 파일은 Bates 번호를 원래 파일명에 다시 매핑합니다.

Presentation

재판에서는 전시물이 Bates 번호로 참조됩니다. 명확한 원래 명명은 시연 자료를 준비할 때 원본 문서를 더 쉽게 찾게 해줍니다.

EDRM은 반복적이고 비선형적입니다 — 팀은 자주 이전 단계로 되돌아갑니다. edrm.net에서 관리합니다.

위험 완화

변호사-의뢰인 특권 보호

특권 문서를 부주의하게 제출하면 특권 포기로 이어질 수 있으며, 이는 소송에서 가장 심각한 위험 중 하나입니다. Federal Rule of Evidence 502(b)는 "clawback" 메커니즘을 제공하지만, 법원은 검토 프로세스의 적절성을 평가합니다. 명명 규칙은 그 평가의 일부입니다.

특권 표시 파일명

변호사-의뢰인 커뮤니케이션의 파일명에 _PRIV 또는 _AC를 포함합니다. 자동 사전 제출 필터링이 가능해집니다. _PRIV가 표시된 문서는 모든 제출 실행 전에 의무적인 수동 검토를 유발합니다.

work product 지정

변호사 work product에는 _WP를 사용합니다. work product를 일반 비즈니스 문서와 분리합니다 — 특히 법률 분석과 비즈니스 권고가 모두 포함된 혼합 목적 문서에서 중요합니다.

특권 로그 생성

문서 유형, 날짜, 작성자, 수신자가 포함된 구조화된 파일명은 특권 로그의 자동 생성을 가능하게 하여 수천 개의 보류 문서를 기록하는 수작업 부담을 줄입니다.

제출 전 QC

_PRIV, _AC, 또는 _WP를 포함하는 모든 파일에 플래그를 지정하는 파일명 기반 필터는 문서가 로펌을 떠나기 전 마지막 방어선 점검을 제공합니다.

대체가 아닌 보완

파일명의 특권 플래그는 eDiscovery 플랫폼의 특권 검토를 대체하는 것이 아니라 보완합니다. 일부 특권 문서는 생성 시점에 플래그되지 않을 수 있습니다. 명명 규칙은 명백한 항목을 잡고, 검토 플랫폼은 나머지를 잡습니다.

이해상충 관리

윤리 장벽과 정보 차단

윤리 장벽(정보 차단)은 상반되거나 잠재적으로 충돌하는 이해관계를 대리하는 변호사들 사이에서 기밀 의뢰인 정보가 흐르는 것을 막습니다. ABA Model Rule 1.10 (이해상충의 전가) 및 Rule 1.0(k) ("screened"의 정의)에 의해 규율되며, 윤리 장벽에는 4가지 요소가 필요합니다: 적시성, 차단된 사건으로부터의 금전적 이익 없음, 의뢰인 통지, 지속적인 준수 보고.

사건 기반 명명이 기본이 되는 이유

자동 접근 통제

DMS 플랫폼(iManage, NetDocuments, Worldox)은 파일명의 사건 코드를 기준으로 접근을 제한합니다 — 차단된 변호사는 제한된 사건 접두사가 있는 문서를 볼 수도, 검색할 수도, 접근할 수도 없습니다.

이해상충 확인

새 사건이 열리면 시스템이 파일명과 메타데이터를 스캔하여 기존 사건과의 잠재적 이해상충을 표시합니다.

감사 추적

일관된 명명은 모든 접근 시도(거부된 접근 포함)의 로깅을 가능하게 하며, 이의가 제기될 경우 screen 준수를 입증하는 데 필요합니다.

시스템 간 시행

사건 정보는 이메일, DMS, 실무 관리 소프트웨어, 클라우드 스토리지 전반에 존재합니다. 사건 번호 기반 명명은 모든 시스템에서 동시에 시행을 가능하게 합니다.

주의 사례

Qualcomm Inc. v. Broadcom Corp.

No. 05-cv-1958-B (BLM), S.D. Cal. | Sanctions Order: Jan. 7, 2008

Qualcomm은 H.264 비디오 코딩 표준과 관련한 특허 침해를 이유로 Broadcom을 제소했습니다. Broadcom의 방어 논리는 Qualcomm이 특허를 공개하지 않은 채 Joint Video Team (JVT) 표준 제정 기구에 참여함으로써 특허 집행 가능성을 포기했다는 것이었습니다.

증거개시 과정에서 Qualcomm은 JVT 참여를 보여주는 수만 건의 관련 이메일을 제출하지 못했습니다. 이 위반은 한 변호사가 재판을 위해 증인을 준비하던 중 2002년 8월의 미공개 이메일을 발견하면서 드러났습니다. 이후 검색에서 추가로 21개의 미공개 이메일이 확인되었습니다. 재판팀은 이를 제출하지 않기로 했습니다.

재판 후 증거개시에서는 단 21명의 직원 이메일 파일에서 제출되었어야 할 46,000건이 넘는 문서이 드러났습니다.

$8,568,633

인정된 변호사 비용

6명의 변호사

State Bar 회부

46,000+

미공개 문서

교훈

Qualcomm의 실패는 주로 기술적 문제가 아니라 조직적 문제였습니다. 사건 관리와 연결된 일관된 명명 시스템이 없었기 때문에 관련 문서가 custodian들의 개인 이메일 저장소에 흩어져 있었고, 이를 체계적으로 식별, 수집, 제출할 방법이 없었습니다. 사건 중심 명명 규칙이 의도적 은폐 자체를 막지는 못했겠지만, 최초 수집 단계에서 간과된 46,000건 이상의 문서를 발견 가능하게 만들었을 것입니다.

보존 의무

법적 보존 의무와 FRCP Rule 37(e)

2015년 12월 개정된 Federal Rule of Civil Procedure 37(e)는 ESI 보존 실패에 대한 제재를 규율합니다. 이 규칙은 2단계 프레임워크를 수립합니다:

Tier 1 — Rule 37(e)(1)

당사자가 이를 보존하기 위한 합리적인 조치를 취하지 못해 ESI가 손실되고, 그 손실이 불이익를 초래한 경우 법원은 필요한 범위를 넘지 않는 치유 조치를 명할 수 있습니다. 객관적 기준입니다.

Tier 2 — Rule 37(e)(2)

당사자가 박탈하려는 의도로 행동한 경우에만 법원은 불리한 추정 지시, 기각, 또는 궐석 판결을 내릴 수 있습니다. 주관적 기준으로, 과실보다 훨씬 높은 문턱입니다.

이름 변경이 보존 의무와 상호작용하는 방식

파일 이름 변경은 파일명만 바꾸며 — 파일 내용, 메타데이터 해시, 생성일, 수정일은 바꾸지 않습니다. Rule 37(e)에서 쟁점은 ESI가 "손실"되었는지 여부이며 — 이름 변경은 문서를 파기하지 않습니다. 그러나 방어 가능한 이름 변경 프로세스에는 다음이 필요합니다:

감사 추적 유지

모든 이름 변경을 기록합니다: 이전 파일명, 새 파일명, 타임스탬프, 그리고 이름을 변경한 사람(또는 시스템). 이 추적 기록은 Rule 37(e)에 따른 "합리적인 조치"의 증거입니다.

원본 메타데이터 보존

이름 변경 도구가 파일 메타데이터(생성일, 작성자, 최종 수정일)를 보존하도록 해야 합니다. 제자리 이름 변경 대신 복사 후 삭제하는 도구는 메타데이터를 변경할 수 있습니다.

소송 보존 기록에 문서화

법적 보존이 시행 중이라면, 모든 이름 변경 활동을 보존 준수 기록의 일부로 남깁니다. 보존 기록에는 보존 기간 중 이름 변경이 허용되는지 여부가 명시되어야 합니다.

선별적 이름 변경 위험

같은 명명 규칙을 일관되게 적용합니다. 일부 문서만 선별적으로 이름을 바꾸고 다른 문서는 그대로 두는 행위는 은폐 의도의 증거로 검토될 수 있습니다.

모든 custodian에 일관되게 적용

같은 사건의 모든 custodian에 동일한 규칙을 사용합니다. 불일치는 방어 가능성을 약화시키고 검토 및 제출 과정에서 혼란을 초래합니다.

업무 분야별

업무 분야별 명명 패턴

각 업무 분야에는 규제 프레임워크, 법원 규칙, 워크플로 규칙에 따라 서로 다른 명명 요구사항이 있습니다. 로펌과 기업 법무 부서에서 실제 운영에 사용하는 패턴입니다.

소송

소송Naming pattern

{MatterNo}_{DocType}_{Court}_{Date}_{Version}

Result2024-1547_MSJ_SDNY_2026-03-15_v2.docx

다중 관할 사건에는 법원 약어(SDNY, CDCA, EDVA)를 포함합니다. 증언 녹취록에는 증인의 이름을 포함합니다. 전시물은 제출 후 Bates 번호를 참조합니다.

기업 / M&A

기업 / M&ANaming pattern

{ProjectCode}_{DocType}_{Counterparty}_{Date}_{Status}

ResultPROJ-ACME_SPA_TargetCo_2026-03-01_EXECUTION.docx

M&A 거래는 기밀 유지를 위해 사건 번호가 아닌 프로젝트 코드를 사용합니다. 실사 문서에는 DD 범주(Financial, Legal, Tax, IP)를 포함합니다. 상태 태그: DRAFT, REVIEW, EXECUTION, FINAL, SIGNED.

지식재산 / 특허

지식재산 / 특허Naming pattern

{AppNo}_{DocType}_{JurisdictionCode}_{Date}

ResultUS17-234567_OA_Response_USPTO_2026-03-15.docx

특허 파일명에는 출원 번호(US, EP, PCT 접두사), 문서 유형(OA = Office Action, ISR = International Search Report), 관할권이 포함됩니다. 버전 추적은 매우 중요합니다 — 특허 출원 절차에는 반복적인 제출이 많습니다.

부동산

부동산Naming pattern

{PropertyID}_{DocType}_{Address}_{Date}

ResultRE-2024-089_Lease_123MainSt_2026-03-01_EXECUTED.pdf

당사자 이름 대신 부동산 식별자를 사용합니다(부동산은 소유자가 바뀔 수 있습니다). 주소는 약어로 포함합니다. 환경 및 권리 문서는 보증 청구를 위해 영구적으로 검색 가능해야 합니다.

파산

파산Naming pattern

{CaseNo}_{DocType}_{Debtor}_{Date}_{DocketNo}

ResultBK-24-12345_POR_AcmeCorp_2026-03-15_Dkt247.pdf

사건 번호와 docket 번호를 참조합니다. POR = Plan of Reorganization. 일정표는 공식 명칭(Schedule A/B, Schedule D)을 사용합니다. UTBMS B-codes가 적용됩니다: B100 (Case Administration), B200 (Asset Analysis), B300 (Relief from Stay).

규제 / 컴플라이언스

규제 / 컴플라이언스Naming pattern

{RegBody}_{MatterRef}_{DocType}_{Date}_{Submission}

ResultSEC_INV-2024-789_WellsResponse_2026-03-15_FILED.pdf

기관명(SEC, DOJ, FTC, CFPB, OFAC)과 조사 또는 제출 참조 번호를 포함합니다. HSR = Hart-Scott-Rodino filing. CID = Civil Investigative Demand. 보존 기간은 특정 규제 요구사항을 따릅니다(대개 최소 5-7년).

실제 예시

전후 비교: 법률 문서 파일명

일반적인 법률 팀의 문서 폴더 모습과, 일관된 규칙을 적용했을 때의 모습입니다.

이전이후

scan_001.pdf

2024-1547_Complaint_SDNY_2026-01-15.pdf

Document (3).docx

2024-1547_MSJ_SDNY_2026-03-15_v2.docx

IMG_20260115_142355.pdf

2024-1547_DepTranscript_JDoe_2026-02-28.pdf

download.pdf

PROJ-ACME_SPA_TargetCo_2026-03-01_EXECUTION.pdf

final FINAL v2 (2).docx

RE-2024-089_Lease_123MainSt_2026-03-01_FINAL.docx

Copy of memo.docx

2024-1547_Memo_PrivilegeReview_2026-02-20_PRIV.docx

제출 형식

ESI 프로토콜과 제출 형식

ESI (Electronically Stored Information) 프로토콜은 전자 문서를 어떻게 증거개시, 검토, 제출할지에 대해 당사자 간에 체결하는 서면 합의입니다. FRCP Rule 34(b)(2)(E)에 따라, 제출 형식에 대한 합의가 없으면 ESI는 통상적으로 보관되는 형식(native) 또는 합리적으로 사용 가능한 형식으로 제출되어야 합니다.

Native Format

원래 애플리케이션 형식(.docx, .xlsx, .msg)입니다. 모든 메타데이터를 보존합니다. 제출 비용이 가장 저렴합니다. 표면에 Bates 스탬프를 찍을 수 없고 의도치 않게 변경될 수 있습니다.

TIFF

단일 페이지 이미지 변환 형식입니다. 복잡한 소송에서 가장 일반적입니다. Bates 스탬프, 비공개 처리, 브랜드 표시가 가능합니다. 추출 텍스트 파일 및 로드 파일(.dat, .opt)과 함께 제출됩니다.

PDF

검색 가능한 텍스트(via OCR), Bates stamping, 비공개 처리를 지원하는 정적 형식입니다. 규모가 작은 제출이나 정부 절차에서 자주 사용됩니다.

로드 파일

.opt

이미지 로드 파일— Bates 번호를 이미지 파일에 매핑합니다

.dat

데이터 로드 파일— 메타데이터 필드(custodian, 날짜, 제목, 파일 유형)를 포함합니다

.txt

추출 텍스트 파일— 문서당 1개이며, 검토 플랫폼에서 전체 텍스트 검색을 가능하게 합니다

하이브리드 제출

모범 관행: 대부분의 문서는 TIFF 또는 PDF로 로드 파일과 추출 텍스트를 함께 제출하고, 스프레드시트, 데이터베이스, 프레젠테이션은 native 형식으로 제출합니다. 한 연방 법원은 "기초 메타데이터 없이 문서를 제출하는 것은 엔진 없는 자동차를 만드는 것과 같다"고 판시했습니다.

기술 생태계

문서 관리 및 eDiscovery 플랫폼

명명 규칙은 로펌의 DMS와 통합되어야 하며, 소송 중에는 eDiscovery 플랫폼과도 통합되어야 합니다.

문서 관리 시스템

iManage

전 세계적으로 AmLaw 100 로펌의 약 90%와 4,000개 이상의 조직에서 사용합니다. 각 문서에 workspace(사건) 내 고유 번호와 버전을 부여합니다. 파일명은 workspace 명명 규칙과 일치해야 합니다.

NetDocuments

3,500개 이상의 로펌에서 사용하는 cloud-native DMS입니다. 프로필 기반 파일링 시스템이 메타데이터(사건 번호, 문서 유형, 작성자)를 각 문서와 연결합니다. 일관된 파일명은 이메일 첨부파일, 내보내기, 시스템 간 전송에서 중요합니다.

Clio

소규모 및 중견 로펌에서 인기 있는 실무 관리 플랫폼입니다. iManage나 NetDocuments보다 명명 강제력이 약하므로, 시스템이 사람의 규율에 더 의존하기 때문에 일관된 파일명이 특히 중요합니다.

eDiscovery 플랫폼

Relativity

복잡한 소송에서 지배적인 eDiscovery 플랫폼입니다. 원래 파일명을 메타데이터로 수집하고, control number를 부여하며, 제출 중 Bates 번호를 적용합니다. 구조화된 원본 파일명은 검토 효율을 높입니다.

Everlaw

강력한 분석 기능을 갖춘 cloud-native 검토 플랫폼입니다. 예측 코딩과 개념 클러스터링은 문서 내용에 작동하지만, 파일명 메타데이터도 문서 family 이해에 기여합니다.

DISCO

속도와 단순성을 강조하는 AI 기반 eDiscovery 플랫폼입니다. 원래 파일명을 검색 가능한 메타데이터로 보존하고 제출 시 Bates 번호를 적용합니다.

정확한 포지셔닝

renamed.to와 같은 AI 명명 도구는 renamed.to를 대체하는 것이 아니라 보완합니다. 이 도구는 문서가 올바르게 이름 붙여져 사전에 iManage, NetDocuments, 또는 검토 플랫폼에 들어가도록 하는 "intake problem"을 해결합니다. DMS의 버전 관리, 접근 관리, 검색 기능을 대체하지는 않습니다.

FAQ

자주 묻는 질문

AmLaw 100 로펌은 법률 문서에 어떤 명명 규칙을 사용하나요?

대부분의 AmLaw 100 로펌은 사건 중심 명명 패턴을 사용합니다: {MatterNumber}_{DocumentType}_{Date}_{Version}.{ext}. 사건 번호는 기본 키이며, Document Management System(일반적으로 iManage 또는 NetDocuments)의 식별자와 일치합니다. 문서 유형은 UTBMS에 맞춘 범주를 따릅니다. 날짜는 시간순 정렬을 위해 ISO 8601 (YYYY-MM-DD)을 사용합니다. 버전 접미사(v1, v2, FINAL, DRAFT)는 수정 이력을 추적합니다. 예: 즉결판결 신청서(Motion for Summary Judgment)의 경우 2024-1547_MSJ_2026-03-15_v2.docx.

eDiscovery에서 Bates 번호는 문서 파일명과 어떤 관계가 있나요?

Bates 번호와 파일명은 서로 다른 목적을 가지지만 조정되어야 합니다. 파일명은 제출 전에 내부 DMS에서 문서를 식별합니다. Bates 번호는 제출 중 적용되는 순차 스탬프(예: SMITH-000001부터 SMITH-004523까지)로, 서면, 증언, 재판에서 인용하기 위한 영구적이고 모호하지 않은 페이지 단위 참조를 제공합니다. 제출 중 문서는 Bates 범위에 맞게 이름이 변경됩니다(예: DEF-000001.tif). 로드 파일(.dat)은 Bates 번호를 원래 파일명 및 메타데이터에 다시 매핑합니다. 모범 관행: 내부 파일명과 Bates 범위를 연결하는 상호참조 표를 유지합니다.

법률 문서 이름 변경은 FRCP Rule 37(e)상 spoliation 위험을 만들나요?

파일 이름 변경은 파일명만 바꾸며, 파일 내용, 메타데이터, 해시 값은 바꾸지 않습니다. FRCP Rule 37(e)에 따르면 spoliation 우려는 ESI가 "당사자가 이를 보존하기 위한 합리적인 조치를 취하지 못해 손실되는" 경우에 발생합니다. 이름 변경 자체는 문서를 파기하거나 변경하지 않습니다. 그러나 반드시 (1) 이전 이름과 새 이름을 연결하는 감사 추적을 유지하고, (2) 원래 메타데이터(생성일, 작성자, 수정일)를 보존하며, (3) 이름 변경 프로세스가 소송 보존 절차의 일부로 문서화되도록 해야 합니다. 법원은 "합리적인 조치"가 취해졌는지 검토하며, 문서화되고 일관된 이름 변경 프로세스는 방어 가능성을 뒷받침합니다.

법률 운영 팀은 문서 분류에 어떤 UTBMS 코드를 사용해야 하나요?

UTBMS Litigation Code Set(1995년에 ABA Section of Litigation, ACC, PwC가 개발)은 표준화된 코드를 제공합니다: L100 (Case Assessment), L200 (Pre-Trial Pleadings), L300 (Discovery), L400 (Trial Preparation), L500 (Appeal), L600 (e-Discovery, 2011 추가). 이 중에서 L140 (Document/File Management), L320 (Document Production), L650 (Review)가 명명 규칙과 가장 관련이 있습니다. 파일명이 사건 예산 및 e-billing 요구사항과 일치하도록 문서 유형을 이 코드에 매핑합니다. 비소송 코드 세트는 Bankruptcy (B-codes), Counseling (C-codes), Project (P-codes)용으로도 존재합니다.

문서 명명 규칙은 로펌의 윤리 장벽을 어떻게 지원하나요?

사건 기반 명명 규칙은 정보 차단의 기초입니다. 파일명에 사건 번호가 접두사로 포함되면(예: 2024-1547_Memo_2026-03-15.docx), DMS가 자동으로 접근 제한을 시행할 수 있습니다 — 차단된 변호사는 해당 사건 접두사가 있는 어떤 문서도 볼 수 없고, 검색할 수 없고, 접근할 수 없습니다. 이는 전가된 이해상충 심사를 위한 ABA Model Rule 1.10에 따라 요구됩니다. 일관된 명명은 iManage/NetDocuments의 자동 접근 통제, screen 준수를 입증하는 감사 추적, 새 사건 개설 시 이해상충 확인, 충돌하는 사건 간 부주의한 공개 방지를 가능하게 합니다.

EDRM이란 무엇이며, 문서 명명은 eDiscovery에서 어떤 역할을 하나요?

2005년에 George Socha와 Tom Gelbmann이 만든 Electronic Discovery Reference Model (EDRM)은 9단계를 정의합니다: Information Governance, Identification, Preservation, Collection, Processing, Review, Analysis, Production, Presentation. 문서 명명은 여러 단계와 맞닿아 있습니다: Processing 중에는 파일이 고유 식별자로 인덱싱되고, Review 중에는 Relativity 같은 플랫폼에서 문서 ID로 추적되며, Production 중에는 문서에 Bates 번호가 부여되고 제출 번호 체계에 맞게 이름이 변경됩니다. 소송 전부터 일관된 명명 규칙을 사용하면 문서를 더 쉽게 식별, 중복 제거, 분류할 수 있어 이후 모든 단계의 비용이 줄어듭니다.

AI 도구가 DMS 요구사항을 준수하는 법률 문서 파일명을 생성할 수 있나요?

예. renamed.to와 같은 AI 문서 처리 도구는 OCR 및 자연어 처리를 사용해 PDF 내용에서 사건 번호, 의뢰인명, 문서 유형, 날짜를 추출한 뒤, 로펌의 규칙에 맞는 파일명을 생성할 수 있습니다. 핵심 요구사항은 명명 템플릿을 DMS 프로필 형식(예: iManage의 {MatterNumber}_{DocType}_{Date} 패턴)에 맞게 구성하는 것입니다. 다만 AI가 생성한 이름은 적용 전에 검토해야 합니다 — 자동 적용보다 confidence preview와 일괄 승인 워크플로를 제공하는 도구가 법률 용도에 더 안전합니다. AI는 사전 처리 단계이며, DMS는 여전히 system of record입니다.

AI 기반 법률 문서 명명 사용해보기

몇 개의 법률 문서를 업로드하고 AI가 사건 번호, 날짜, 문서 유형을 추출해 일관된 파일명을 생성하는 방식을 확인해 보세요. 무료 이름 변경 50회, 신용카드 필요 없음.

Renamed.to 무료로 사용해보기

파일 크레딧 50개 무료 · 신용카드 불필요 · 이후 $0.009/파일