[2편] 설계편: 확장 가능한 도메인 명명 체계 설계하기

---

체계적인 4레벨 구조로 혼란을 질서로

들어가며: 설계의 중요성

1편에서 apollo와 zeus 같은 창의적 명명이 왜 문제가 되는지 살펴봤습니다. 이번에는 실제로 확장 가능하고 직관적인 도메인 명명 체계를 설계해보겠습니다.

좋은 명명 체계는 마치 잘 정리된 도서관 같습니다. 분류 체계만 알면 누구나 원하는 책을 쉽게 찾을 수 있죠. 서버도 마찬가지입니다.

기본 4레벨 구조 소개

가장 검증된 구조는 다음과 같습니다:

{자산유형}-{기능/용도}-{환경}-{위치}.company.internal

실제 예시:

srv-mail-prod-seoul.company.internal     # 서울 운영 메일서버
vm-web-dev-cloud.company.internal       # 클라우드 개발 웹 가상머신
db-mysql-test-busan.company.internal    # 부산 테스트 MySQL DB

이 구조의 장점:

• 직관성: 한눈에 파악 가능
• 확장성: 새로운 요소 추가 용이
• 일관성: 모든 자산에 동일한 규칙 적용
• 자동화 친화적: 패턴 기반 스크립트 작성 가능

1단계: 자산 유형별 카테고리 분류

물리 장비 (Physical Devices)

코드	자산 유형	설명	예시
srv	물리서버	베어메탈 서버	srv-mail-prod-seoul
pc	개인PC	워크스테이션, 데스크톱	pc-kim-hr-seoul
nb	노트북	랩톱 컴퓨터	nb-park-sales-busan
pr	프린터	네트워크 프린터	pr-hp-floor2-seoul

네트워크 장비 (Network Equipment)

코드	자산 유형	설명	예시
fw	방화벽	네트워크 방화벽	fw-main-prod-seoul
sw	스위치	네트워크 스위치	sw-floor3-prod-seoul
rt	라우터	네트워크 라우터	rt-gateway-prod-seoul
ap	무선AP	WiFi 액세스 포인트	ap-lobby-prod-seoul
lb	로드밸런서	부하분산 장비	lb-web-prod-seoul

가상화 환경 (Virtualization)

코드	자산 유형	설명	예시
vm	가상머신	가상화된 서버	vm-web-dev-seoul
ct	컨테이너	Docker/K8s 컨테이너	ct-api-prod-k8s
k8s	K8S클러스터	Kubernetes 클러스터	k8s-prod-cluster-cloud

클라우드 서비스 (Cloud Services)

코드	자산 유형	설명	예시
aws	AWS인스턴스	AWS EC2 등	aws-web-prod-apse1
azure	Azure서비스	Azure VM 등	azure-app-dev-koreacentral
gcp	GCP인스턴스	Google Cloud	gcp-db-test-asia-northeast3

애플리케이션 서비스 (Application Services)

코드	자산 유형	설명	예시
web	웹서비스	웹 애플리케이션	web-intranet-prod-seoul
api	API서버	REST/GraphQL API	api-auth-prod-cloud
db	데이터베이스	DB 서비스	db-mysql-prod-seoul
cache	캐시서버	Redis/Memcached	cache-redis-prod-seoul

2단계: 환경 코드 체계

기본 환경 구분

코드	환경	설명	사용 예시
prod	운영환경	실제 서비스 환경	srv-mail-prod-seoul
dev	개발환경	개발자용 환경	vm-api-dev-seoul
test	테스트환경	QA/테스트용 환경	db-mysql-test-seoul
stg	스테이징환경	운영 전 검증 환경	web-crm-stg-seoul

특수 환경 구분

코드	환경	설명	사용 예시
dmz	DMZ구간	외부 연결 구간	srv-proxy-dmz-seoul
mgmt	관리환경	시스템 관리용	srv-monitor-mgmt-seoul
bak	백업환경	백업 전용	st-backup-bak-seoul

3단계: 위치 코드 체계

지역별 분류

코드	위치	설명
seoul	서울본사	서울 사무실
busan	부산지사	부산 지사
dc1	데이터센터1	주 데이터센터
dc2	데이터센터2	보조 데이터센터
cloud	클라우드	AWS/Azure 등

건물/층별 분류

코드	위치	설명
floor1	1층	1층 사무실
floor2	2층	2층 사무실
lobby	로비	로비/접수 구역
meeting	회의실	회의실 구역

부서별 분류

코드	부서	설명
hr	인사팀	인사/총무
sales	영업팀	영업/마케팅
dev	개발팀	개발/IT
finance	재무팀	재무/회계

4단계: 기능/용도별 명명

서버 기능

기능명	설명	예시
mail	메일서버	srv-mail-prod-seoul
file	파일서버	srv-file-prod-seoul
web	웹서버	srv-web-prod-seoul
dns	DNS서버	srv-dns-prod-seoul
dhcp	DHCP서버	srv-dhcp-prod-seoul
backup	백업서버	srv-backup-prod-seoul

웹서비스 기능

기능명	설명	예시
intranet	사내 인트라넷	web-intranet-prod-seoul
crm	고객관리시스템	web-crm-prod-seoul
erp	전사자원관리	web-erp-prod-seoul
wiki	위키시스템	web-wiki-prod-seoul

조직 규모별 권장 구조

스타트업 (50명 이하) – 심플 구조

{자산유형}-{기능}-{환경}.company.internal

예시:
srv-mail-prod.company.internal
vm-web-dev.company.internal
db-mysql-test.company.internal

중소기업 (500명 이하) – 기본 구조

{자산유형}-{기능}-{환경}-{위치}.company.internal

예시:
srv-mail-prod-seoul.company.internal
vm-web-dev-cloud.company.internal
db-mysql-test-busan.company.internal

중견기업 (2000명 이하) – 확장 구조

{자산유형}-{기능}-{환경}-{위치}-{번호}.company.internal

예시:
srv-mail-prod-seoul-01.company.internal
vm-web-dev-cloud-02.company.internal
db-mysql-prod-dc1-primary.company.internal

실제 명명 예시와 패턴

서버 인프라 예시

srv-mail-prod-seoul.company.internal          # 서울 운영 메일서버
srv-file-prod-dc1.company.internal            # 데이터센터1 파일서버
srv-dns-prod-busan.company.internal           # 부산 DNS 서버
srv-backup-mgmt-dc2.company.internal          # 데이터센터2 백업서버
srv-monitor-mgmt-seoul.company.internal       # 서울 모니터링 서버

가상화 환경 예시

vm-web-prod-cloud.company.internal            # 클라우드 운영 웹 VM
vm-app-dev-seoul.company.internal             # 서울 개발 앱 VM
ct-nginx-prod-k8s.company.internal            # K8S Nginx 컨테이너
k8s-cluster-prod-cloud.company.internal       # 클라우드 K8S 클러스터

사용자 기기 예시

pc-kim-hr-seoul.company.internal              # 서울 인사팀 김○○ PC
nb-park-sales-busan.company.internal          # 부산 영업팀 박○○ 노트북
pc-shared-meeting-floor3.company.internal     # 3층 회의실 공용PC

네트워크 장비 예시

fw-main-prod-dc1.company.internal             # 데이터센터1 메인 방화벽
sw-core-prod-floor1.company.internal          # 1층 코어 스위치
ap-lobby-prod-seoul.company.internal          # 서울 로비 무선AP
lb-web-prod-dc1.company.internal              # 데이터센터1 웹 로드밸런서

번호 체계와 역할 구분

순차 번호 방식

srv-web-prod-seoul-01.company.internal        # 첫 번째 웹서버
srv-web-prod-seoul-02.company.internal        # 두 번째 웹서버
srv-web-prod-seoul-03.company.internal        # 세 번째 웹서버

역할 기반 방식

db-mysql-prod-dc1-primary.company.internal    # MySQL 주 데이터베이스
db-mysql-prod-dc2-secondary.company.internal  # MySQL 보조 데이터베이스
srv-dns-prod-seoul-master.company.internal    # DNS 마스터 서버
srv-dns-prod-busan-slave.company.internal     # DNS 슬레이브 서버

명명 규칙 가이드라인

필수 규칙

• 모든 도메인명은 영문 소문자 사용
• 단어 구분은 하이픈(-) 사용
• 언더스코어(_) 사용 금지
• 최대 길이 63자 이내 (DNS 표준)
• 숫자로 시작 불가

권장사항

• 축약어보다는 명확한 단어 사용
• 일관된 명명 규칙 준수
• 예약어 사용 금지 (www, mail, ftp 등)
• 혼동 가능한 문자 조합 피하기 (l과 1, o와 0)

구현 전 체크리스트

1. 요구사항 분석

• [ ] 현재 자산 규모 파악
• [ ] 향후 3-5년 성장 계획 반영
• [ ] 기존 시스템과의 호환성 검토
• [ ] 팀원들의 기술 수준 고려

2. 도메인 선택

• [ ] 내부 도메인 후보 선정
• [ ] DNS 서버 구성 계획
• [ ] 인증서 전략 수립
• [ ] Split DNS 구성 여부 결정

3. 명명 규칙 확정

• [ ] 자산 유형 코드 정의
• [ ] 환경 코드 정의
• [ ] 위치 코드 정의
• [ ] 기능 코드 정의

4. 문서화 및 교육

• [ ] 명명 가이드라인 문서 작성
• [ ] 팀원 교육 계획 수립
• [ ] 변경 관리 프로세스 정의
• [ ] 정기 검토 일정 수립

마치며: 완벽함보다는 일관성

완벽한 명명 체계는 없습니다. 중요한 것은 일관성입니다.

• 처음에는 간단하게 시작하세요
• 조직 성장에 맞춰 점진적으로 확장하세요
• 모든 팀원이 이해하고 따를 수 있는 규칙을 만드세요
• 정기적으로 검토하고 개선하세요

다음 편에서는…

3편에서는 더 복잡한 환경을 위한 고급 명명 전략을 다룰 예정입니다:

• 5-8레벨 확장 구조 옵션들
• 글로벌 기업, 다사업부 환경 대응
• 계층적 서브도메인 구조
• 클라우드 네이티브 환경 고려사항

체계적인 명명으로 더 이상 apollo가 뭘 하는 서버인지 고민하지 않는 그날까지!

---

다음 편: “[3편] 복잡한 환경을 위한 고급 명명 전략”에서 계속됩니다.