체계적 도메인 관리로 혼란을 질서로 바꾸는 방법
서론: “zeus.company.com이 다운됐어요!”
월요일 아침, 급하게 달려온 직원이 외쳤습니다. “IT팀장님, zeus가 다운됐어요! 회계 프로그램이 안 돼요!”
여러분도 이런 상황 겪어보셨나요? zeus, apollo, hercules… 그리스 신 이름으로 된 서버들 중에서 어떤 게 회계 시스템인지, 어떤 게 메일 서버인지 헷갈려서 장애 대응이 늦어진 적 말입니다.
이런 혼란은 회사가 성장하면서 더욱 심해집니다. 처음에는 귀여웠던 mickey, donald 같은 이름들이 수십, 수백 개로 늘어나면서 관리 불가능한 상황이 되는 거죠.
현실: 대부분 회사의 도메인 명명 현황
실제로 많은 기업들이 이런 방식으로 서버를 명명하고 있습니다:
창의적(?) 명명 방식들:
- 그리스 신화:
zeus,apollo,athena,poseidon - 디즈니 캐릭터:
mickey,donald,goofy,pluto - 스타워즈:
luke,vader,yoda,obiwan - 포켓몬:
pikachu,charizard,blastoise - 심지어:
server1,server2,my-server,test-box
처음에는 재미있고 기억하기 쉬워 보입니다. “pikachu가 메일 서버고, charizard가 데이터베이스야”라고 말하면 모두 웃으면서 기억하죠.
문제점: 확장성 없는 명명이 가져오는 혼란
하지만 회사가 성장하면서 다음과 같은 문제들이 발생합니다:
1. 이름 부족 문제
포켓몬이 800마리 넘는다고 해도, 서버가 1000대가 되면? 그리스 신이 몇 명이나 될까요? 결국 pikachu2, pikachu-backup, pikachu-new 같은 괴상한 이름들이 등장합니다.
2. 정보 부족 문제
apollo라는 이름만 봐서는 알 수 없는 것들:
- 이게 운영 서버인가, 테스트 서버인가?
- 어느 지점에 있는가?
- 무슨 용도인가?
- 물리 서버인가, 가상 서버인가?
3. 인수인계 문제
기존 관리자가 퇴사하면? apollo가 뭘 하는 서버인지, zeus가 왜 중요한지 아는 사람이 없어집니다.
4. 확장성 문제
새로운 지점이나 부서가 생기면? 부산 지사의 서버도 apollo라고 할 건가요? apollo-busan? apollo2?
5. 법적 문제
실제로 어떤 회사는 디즈니에서 상표권 침해로 경고를 받기도 했습니다. 사내에서만 쓴다고 해서 면책되는 건 아니거든요.
해결책 미리보기: 체계적 접근의 힘
대신 이렇게 명명한다면 어떨까요?
srv-mail-prod-seoul.company.internal
vm-web-dev-cloud.company.internal
db-mysql-prod-dc1.company.internal
한눈에 보이는 정보들:
srv-mail-prod-seoul: 서울의 운영 환경 메일 서버vm-web-dev-cloud: 클라우드의 개발 환경 웹 가상머신db-mysql-prod-dc1: 데이터센터1의 운영 환경 MySQL 데이터베이스
체계적 명명의 이점:
- 직관성: 이름만 봐도 용도를 알 수 있음
- 확장성: 새로운 환경이나 지점 추가 시 일관된 패턴 적용
- 관리성: 자동화 스크립트나 모니터링 도구 연동 용이
- 인수인계: 명명 규칙만 알면 모든 서버의 역할 파악 가능
업계 표준과 권장사항
Microsoft 공식 권장사항
마이크로소프트는 Active Directory 환경에서 다음을 권장합니다:
- 실제 소유한 도메인의 서브도메인 사용 (
internal.company.com) - 또는 별도로 등록한 도메인 사용 (
company.net) .local도메인 사용 지양 (Apple Bonjour와 충돌)
RFC 표준 가이드라인
.test: 테스트 전용 (RFC 6761).internal: 내부 사용 권장.corp: 기업용으로 많이 사용되나 ICANN에서 판매 가능성 있음
Fortune 500 기업 사례
대부분의 글로벌 기업들은 다음과 같은 패턴을 사용합니다:
{기능}-{환경}-{위치}-{번호}.internal.company.com- 15자 이내 NetBIOS 호환성 고려
- 하이픈(-) 사용, 언더스코어(_) 지양
내부 도메인 선택 가이드
안전한 선택지
- 가장 권장:
internal.yourcompany.com(실제 도메인의 서브도메인) - 차선:
yourcompany.internal(내부 전용) - 대안:
corp.yourcompany.com(기업용 서브도메인)
피해야 할 선택지
.local: mDNS 충돌 위험.home: 라우터 기본값과 충돌.corp,.lan: ICANN 판매 가능성- 타사 도메인:
google.com,microsoft.com등
시작하기 전 고려사항
1. 조직 규모 평가
- 50명 이하: 간단한 4레벨 구조로 충분
- 500명 이하: 부서/환경 구분 추가 고려
- 2000명 이상: 복합적인 계층 구조 필요
2. 성장 계획 반영
- 향후 3-5년 내 예상 규모
- 새로운 지점이나 사업부 계획
- 클라우드 전환 계획
3. 기존 시스템과의 호환성
- 현재 사용 중인 도메인 체계
- 기존 애플리케이션의 하드코딩된 도메인
- 인증서 및 보안 정책
다음 편에서는…
2편에서는 실제로 확장 가능한 도메인 명명 체계를 설계하는 방법을 다룰 예정입니다:
- 기본 4레벨 구조:
{자산유형}-{기능}-{환경}-{위치} - 자산 유형별 카테고리 분류 (물리장비, 네트워크, 보안, 클라우드 등)
- 환경 코드와 위치 코드 체계
- 실제 명명 예시와 패턴
더 이상 apollo가 무슨 서버인지 헤매지 않는 그날까지, 함께 체계적인 도메인 관리의 여정을 시작해봅시다!
다음 편: “[2편] 확장 가능한 도메인 명명 체계 설계하기”에서 계속됩니다.
“[1편] 기초편: 내부 도메인 명명, 왜 중요한가?”에 대한 1개의 생각