네이밍 규칙
개요
네이밍 규칙(Naming Convention)은 소프웨어 개발 및 문서 관리 분야에서 파일, 변수, 함수, 클래스, 디렉터리 등의 이름을 체계적으로 지정하기 위한 규칙입니다. 특히 문서 관리 측면에서 네이밍 규칙은 정보의 접근성, 검색 용이성, 버전 관리, 협업 효율성 등을 크게 향상시키는 핵심 요소로 작용합니다. 조직 내에서 일관된 네이밍을 적용하면 문서의 정체성을 명확히 하고, 중복 생성을 방지하며, 장기적인 아카이빙과 검색을 용이하게 합니다.
본 문서에서는 문서 관리 분야에서 사용하는 네이밍 규칙의 목적, 구성 요소, 대표적인 패턴, 적용 사례 및 모범 사례를 다룹니다.
네이밍 규칙의 목적
문서 관리에서 네이밍 규칙을 도입하는 주요 목적은 다음과 같습니다:
- 일관성 유지: 모든 사용자가 동일한 형식으로 문서를 명명함으로써 혼란을 방지합니다.
- 검색 용이성 향상: 키워드 기반 검색이나 필터링이 쉬워집니다.
- 버전 관리 지원: 문서의 최신 버전과 이전 버전을 쉽게 구분할 수 있습니다.
- 협업 효율성 증대: 팀원 간의 커뮤니케이션 오류를 줄이고 문서의 목적을 빠르게 파악할 수 있습니다.
- 자동화 지원: 스크립트나 문서 관리 시스템(DMS)이 파일을 자동으로 분류하거나 처리할 수 있게 합니다.
네이밍 규칙의 구성 요소
효과적인 문서 네이밍 규칙은 일반적으로 다음 요소들을 포함합니다:
| 요소 |
설명 |
| 프로젝트/부서 코드 |
문서가 속한 프로젝트나 부서를 식별합니다. 예: HR, FIN, PROJ-2024 |
| 문서 유형 |
문서의 종류를 나타냅니다. 예: 보고서, 회의록, 계획서, 양식 |
| 주제 또는 제목 |
문서의 핵심 내용을 간략히 표현합니다. 예: 연말정산, Q3_성과분석 |
| 날짜 |
작성일 또는 수정일을 포함합니다. 형식은 YYYYMMDD 또는 YYYY-MM-DD 권장 |
| 버전 정보 |
v1.0, v2.1 등으로 버전을 표시하여 이력을 관리합니다. |
| 작성자 또는 팀 |
필요 시 작성자를 약어로 포함할 수 있습니다. 예: _JYK |
대표적인 네이밍 패턴
다음은 네이밍 규칙의 대표적인 패턴 예시입니다.
1. 기본 형식 (권장)
[프로젝트]_[문서유형]_[주제]_[날짜]_[버전].확장자
예:
HR_보고서_연말정산안내_20241201_v1.0.pdf
2. 간소화 형식
예:
Q3_성과분석_2024-09-30_v2.0.xlsx
3. 팀 기반 형식
[팀]_[문서유형]_[날짜]_[주제]_[작성자].확장자
예:
마케팅_기획서_20241115_크리스마스캠페인_JYP.docx
적용 사례
사례 1: 회의록 관리
- 규칙:
MTG_[부서]_[날짜]_[주제].docx
- 예시:
MTG_FIN_20241205_예산심의.docx
이 경우 회의록은 부서별로 분류되며, 날짜 기반 정렬이 가능해 회의 이력을 쉽게 추적할 수 있습니다.
사례 2: 프로젝트 문서
- 규칙:
PROJ-[번호]_[문서유형]_[날짜]_[버전].pdf
- 예시:
PROJ-2024-001_요구사항정의서_20241120_v1.2.pdf
프로젝트 번호를 기반으로 문서를 체계화하면, 여러 프로젝트 간 혼동을 방지할 수 있습니다.
모범 사례 (Best Practices)
- ✅ 공백 대신 언더스코어(
_) 또는 하이픈(-) 사용: 공백은 시스템 간 호환성 문제를 일으킬 수 있습니다.
- ✅ 대문자와 소문자 일관성 유지: 일반적으로 모두 소문자 또는 스네이크 케이스(snake_case)를 권장합니다.
- ✅ 날짜 형식 통일: ISO 8601 표준(
YYYYMMDD 또는 YYYY-MM-DD) 사용을 권장합니다.
- ✅ 버전 번호 포함:
v1, v1.1, final, draft 등은 혼란을 초래할 수 있으므로 정형화된 버전 체계 사용.
- ✅ 너무 긴 이름 피하기: 50자 이내 유지하여 시스템 호환성 및 가독성 확보.
참고 자료 및 관련 문서
결론
문서 관리에서 네이밍 규칙은 단순한 이름 지정 이상의 의미를 갖습니다. 이는 정보의 구조화, 검색 최적화, 협업 효율성 향상, 그리고 장기적인 지식 자산 관리의 기반이 됩니다. 조직은 자체적인 네이밍 표준을 수립하고, 구성원 전원이 이를 준수하도록 교육 및 정책화하는 것이 중요합니다. 잘 정의된 네이밍 규칙은 디지털 문서 환경에서 혼란을 줄이고, 생산성을 극대화하는 핵심 도구입니다.
리소스 유형별 명명 전략
디지털 에셋(Digital Assets)은 파일의 성격과 용도가 다양하므로, 파일명 앞에 리소스의 유형을 나타내는 접두사(Prefix)를 붙여 분류 효율성을 높입니다.
리소스별 접두사 예시
| 리소스 유형 |
접두사(Prefix) |
예시 |
설명 |
| 이미지 (Image) |
img_ |
img_main_banner.jpg |
일반 사진, 그래픽 이미지 |
| 아이콘 (Icon) |
ic_ |
ic_nav_home.svg |
UI 아이콘, 심볼 |
| 비디오 (Video) |
vid_ |
vid_tutorial_01.mp4 |
영상 콘텐츠, 모션 그래픽 |
| 폰트 (Font) |
ff_ |
ff_pretendard_bold.otf |
서체 파일 (Font Family) |
| 배경 (Background) |
bg_ |
bg_login_dark.png |
배경 이미지 및 패턴 |
| 일러스트 (Illustration) |
ill_ |
ill_welcome_guide.png |
삽화 및 벡터 일러스트레이션 |
리소스 상태 및 속성 표기법
리소스의 제작 단계나 특정 속성을 구분하기 위해 파일명 끝에 식별자(Suffix)를 추가하여 관리합니다.
상태 및 용도 식별자
- 제작 상태:
_draft: 초안 단계의 리소스_final: 최종 확정된 리소스_rev1, _rev2: 수정 버전 (Revision)
- 속성 및 용도:
_thumb: 썸네일용 저해상도 이미지_bg: 배경 전용 리소스_mask: 마스킹 처리를 위한 리소스_opt: 최적화(Optimized) 완료된 리소스
적용 예시: ic_nav_home_draft.svg $\rightarrow$ ic_nav_home_final.svg
리소스 관리 상세 구성 요소
효과적인 에셋 관리를 위해 기존 문서 구성 요소 외에 다음과 같은 기술적 항목을 추가하여 정의합니다.
| 추가 요소 |
설명 |
예시 |
| 에셋 유형 (Asset Type) |
리소스의 물리적/기능적 분류 |
icon, logo, photo, video |
| 해상도/사이즈 (Size) |
리소스의 크기 또는 배수 표기 |
_2x, _3x, _1080p, _small |
| 색상/테마 (Color/Theme) |
적용된 색상 값이나 테마 구분 |
_dark, _light, _blue, _gold |
케이스 스타일 및 다국어 표기 가이드
리소스의 사용 환경(OS, 개발 언어, 플랫폼)에 따라 적절한 케이스 스타일을 선택하고, 다국어 리소스의 일관성을 유지해야 합니다.
케이스 스타일별 적용 대상
| 스타일 |
표기법 |
적용 권장 대상 |
예시 |
| kebab-case |
소문자 + 하이픈 |
URL, HTML/CSS 클래스, 웹 파일명 |
main-banner-image.jpg |
| snake_case |
소문자 + 언더스코어 |
DB 필드, Python 변수, 일반 파일명 |
user_profile_thumb.png |
| camelCase |
소문자 시작 + 대문자 |
JavaScript 변수, Java 메서드 |
userProfileThumb.png |
| PascalCase |
대문자 시작 + 대문자 |
클래스명, 컴포넌트 파일명 |
UserProfileCard.jsx |
다국어 리소스 표기 원칙
- 영문 표기 원칙: 모든 리소스 파일명은 시스템 호환성을 위해 영문 표기를 기본으로 합니다.
- 언어 코드 추가: 다국어 지원 리소스의 경우 ISO 639-1 표준 언어 코드를 접미사로 추가합니다. (예:
_ko, _en, _jp)
- 권장 사전: 정확한 영문 명칭 선정을 위해 아래의 전문 사전을 활용하는 것을 권장합니다.
# 네이밍 규칙
## 개요
**네이밍 규칙**(Naming Convention)은 소프웨어 개발 및 문서 관리 분야에서 파일, 변수, 함수, 클래스, 디렉터리 등의 이름을 체계적으로 지정하기 위한 규칙입니다. 특히 **문서 관리** 측면에서 네이밍 규칙은 정보의 접근성, 검색 용이성, 버전 관리, 협업 효율성 등을 크게 향상시키는 핵심 요소로 작용합니다. 조직 내에서 일관된 네이밍을 적용하면 문서의 정체성을 명확히 하고, 중복 생성을 방지하며, 장기적인 아카이빙과 검색을 용이하게 합니다.
본 문서에서는 문서 관리 분야에서 사용하는 네이밍 규칙의 목적, 구성 요소, 대표적인 패턴, 적용 사례 및 모범 사례를 다룹니다.
---
## 네이밍 규칙의 목적
문서 관리에서 네이밍 규칙을 도입하는 주요 목적은 다음과 같습니다:
- **일관성 유지**: 모든 사용자가 동일한 형식으로 문서를 명명함으로써 혼란을 방지합니다.
- **검색 용이성 향상**: 키워드 기반 검색이나 필터링이 쉬워집니다.
- **버전 관리 지원**: 문서의 최신 버전과 이전 버전을 쉽게 구분할 수 있습니다.
- **협업 효율성 증대**: 팀원 간의 커뮤니케이션 오류를 줄이고 문서의 목적을 빠르게 파악할 수 있습니다.
- **자동화 지원**: 스크립트나 문서 관리 시스템(DMS)이 파일을 자동으로 분류하거나 처리할 수 있게 합니다.
---
## 네이밍 규칙의 구성 요소
효과적인 문서 네이밍 규칙은 일반적으로 다음 요소들을 포함합니다:
| 요소 | 설명 |
|------|------|
| **프로젝트/부서 코드** | 문서가 속한 프로젝트나 부서를 식별합니다. 예: `HR`, `FIN`, `PROJ-2024` |
| **문서 유형** | 문서의 종류를 나타냅니다. 예: `보고서`, `회의록`, `계획서`, `양식` |
| **주제 또는 제목** | 문서의 핵심 내용을 간략히 표현합니다. 예: `연말정산`, `Q3_성과분석` |
| **날짜** | 작성일 또는 수정일을 포함합니다. 형식은 `YYYYMMDD` 또는 `YYYY-MM-DD` 권장 |
| **버전 정보** | `v1.0`, `v2.1` 등으로 버전을 표시하여 이력을 관리합니다. |
| **작성자 또는 팀** | 필요 시 작성자를 약어로 포함할 수 있습니다. 예: `_JYK` |
---
## 대표적인 네이밍 패턴
다음은 네이밍 규칙의 대표적인 패턴 예시입니다.
### 1. 기본 형식 (권장)
```
[프로젝트]_[문서유형]_[주제]_[날짜]_[버전].확장자
```
예: `HR_보고서_연말정산안내_20241201_v1.0.pdf`
### 2. 간소화 형식
```
[주제]_[날짜]_[버전].확장자
```
예: `Q3_성과분석_2024-09-30_v2.0.xlsx`
### 3. 팀 기반 형식
```
[팀]_[문서유형]_[날짜]_[주제]_[작성자].확장자
```
예: `마케팅_기획서_20241115_크리스마스캠페인_JYP.docx`
---
## 적용 사례
### 사례 1: 회의록 관리
- **규칙**: `MTG_[부서]_[날짜]_[주제].docx`
- **예시**: `MTG_FIN_20241205_예산심의.docx`
이 경우 회의록은 부서별로 분류되며, 날짜 기반 정렬이 가능해 회의 이력을 쉽게 추적할 수 있습니다.
### 사례 2: 프로젝트 문서
- **규칙**: `PROJ-[번호]_[문서유형]_[날짜]_[버전].pdf`
- **예시**: `PROJ-2024-001_요구사항정의서_20241120_v1.2.pdf`
프로젝트 번호를 기반으로 문서를 체계화하면, 여러 프로젝트 간 혼동을 방지할 수 있습니다.
---
## 모범 사례 (Best Practices)
- ✅ **공백 대신 언더스코어(`_`) 또는 하이픈(`-`) 사용**: 공백은 시스템 간 호환성 문제를 일으킬 수 있습니다.
- ✅ **대문자와 소문자 일관성 유지**: 일반적으로 모두 소문자 또는 스네이크 케이스(snake_case)를 권장합니다.
- ✅ **날짜 형식 통일**: ISO 8601 표준(`YYYYMMDD` 또는 `YYYY-MM-DD`) 사용을 권장합니다.
- ✅ **버전 번호 포함**: `v1`, `v1.1`, `final`, `draft` 등은 혼란을 초래할 수 있으므로 정형화된 버전 체계 사용.
- ✅ **너무 긴 이름 피하기**: 50자 이내 유지하여 시스템 호환성 및 가독성 확보.
---
## 참고 자료 및 관련 문서
- [ISO 8601 – 날짜 및 시간 표현 표준](https://www.iso.org/iso-8601-date-and-time-format.html)
- [DAMS (Digital Asset Management System) 네이밍 가이드라인](https://www.damfoundation.org)
- [Google Drive 문서 관리 가이드](https://support.google.com/a/users/answer/9310284)
---
## 결론
문서 관리에서 **네이밍 규칙**은 단순한 이름 지정 이상의 의미를 갖습니다. 이는 정보의 구조화, 검색 최적화, 협업 효율성 향상, 그리고 장기적인 지식 자산 관리의 기반이 됩니다. 조직은 자체적인 네이밍 표준을 수립하고, 구성원 전원이 이를 준수하도록 교육 및 정책화하는 것이 중요합니다. 잘 정의된 네이밍 규칙은 디지털 문서 환경에서 혼란을 줄이고, 생산성을 극대화하는 핵심 도구입니다.
## 리소스 유형별 명명 전략
디지털 에셋(Digital Assets)은 파일의 성격과 용도가 다양하므로, 파일명 앞에 리소스의 유형을 나타내는 접두사(Prefix)를 붙여 분류 효율성을 높입니다.
### 리소스별 접두사 예시
| 리소스 유형 | 접두사(Prefix) | 예시 | 설명 |
| :--- | :--- | :--- | :--- |
| **이미지 (Image)** | `img_` | `img_main_banner.jpg` | 일반 사진, 그래픽 이미지 |
| **아이콘 (Icon)** | `ic_` | `ic_nav_home.svg` | UI 아이콘, 심볼 |
| **비디오 (Video)** | `vid_` | `vid_tutorial_01.mp4` | 영상 콘텐츠, 모션 그래픽 |
| **폰트 (Font)** | `ff_` | `ff_pretendard_bold.otf` | 서체 파일 (Font Family) |
| **배경 (Background)** | `bg_` | `bg_login_dark.png` | 배경 이미지 및 패턴 |
| **일러스트 (Illustration)** | `ill_` | `ill_welcome_guide.png` | 삽화 및 벡터 일러스트레이션 |
## 리소스 상태 및 속성 표기법
리소스의 제작 단계나 특정 속성을 구분하기 위해 파일명 끝에 식별자(Suffix)를 추가하여 관리합니다.
### 상태 및 용도 식별자
- **제작 상태**:
- `_draft`: 초안 단계의 리소스
- `_final`: 최종 확정된 리소스
- `_rev1, _rev2`: 수정 버전 (Revision)
- **속성 및 용도**:
- `_thumb`: 썸네일용 저해상도 이미지
- `_bg`: 배경 전용 리소스
- `_mask`: 마스킹 처리를 위한 리소스
- `_opt`: 최적화(Optimized) 완료된 리소스
**적용 예시**: `ic_nav_home_draft.svg` $\rightarrow$ `ic_nav_home_final.svg`
## 리소스 관리 상세 구성 요소
효과적인 에셋 관리를 위해 기존 문서 구성 요소 외에 다음과 같은 기술적 항목을 추가하여 정의합니다.
| 추가 요소 | 설명 | 예시 |
| :--- | :--- | :--- |
| **에셋 유형 (Asset Type)** | 리소스의 물리적/기능적 분류 | `icon`, `logo`, `photo`, `video` |
| **해상도/사이즈 (Size)** | 리소스의 크기 또는 배수 표기 | `_2x`, `_3x`, `_1080p`, `_small` |
| **색상/테마 (Color/Theme)** | 적용된 색상 값이나 테마 구분 | `_dark`, `_light`, `_blue`, `_gold` |
## 케이스 스타일 및 다국어 표기 가이드
리소스의 사용 환경(OS, 개발 언어, 플랫폼)에 따라 적절한 케이스 스타일을 선택하고, 다국어 리소스의 일관성을 유지해야 합니다.
### 케이스 스타일별 적용 대상
| 스타일 | 표기법 | 적용 권장 대상 | 예시 |
| :--- | :--- | :--- | :--- |
| **kebab-case** | 소문자 + 하이픈 | URL, HTML/CSS 클래스, 웹 파일명 | `main-banner-image.jpg` |
| **snake_case** | 소문자 + 언더스코어 | DB 필드, Python 변수, 일반 파일명 | `user_profile_thumb.png` |
| **camelCase** | 소문자 시작 + 대문자 | JavaScript 변수, Java 메서드 | `userProfileThumb.png` |
| **PascalCase** | 대문자 시작 + 대문자 | 클래스명, 컴포넌트 파일명 | `UserProfileCard.jsx` |
### 다국어 리소스 표기 원칙
- **영문 표기 원칙**: 모든 리소스 파일명은 시스템 호환성을 위해 **영문 표기를 기본**으로 합니다.
- **언어 코드 추가**: 다국어 지원 리소스의 경우 ISO 639-1 표준 언어 코드를 접미사로 추가합니다. (예: `_ko`, `_en`, `_jp`)
- **권장 사전**: 정확한 영문 명칭 선정을 위해 아래의 전문 사전을 활용하는 것을 권장합니다.
- [네이버 영어사전](https://en.dict.naver.com/) / [구글 번역](https://translate.google.com/)
- [Cambridge Dictionary](https://dictionary.cambridge.org/) (비즈니스/기술 용어 검증용)