Nangman Infra Naming & Tagging Guide v1.0

유정빈·2026년 3월 12일

AWS & On-premise Naming and Tagging Convention

1. 개요 및 목적

1.1 아키텍처 관점: 왜 일관된 네이밍 규칙이 필요한가?

클라우드와 온프레미스 리소스가 혼재된 하이브리드 인프라에서는 리소스의 맥락(Context)을 소실하는 것이 가장 큰 맹점입니다.

조직이 커지고 MSA(Microservices Architecture) 등으로 네트워크 엔드포인트가 폭발적으로 증가하게 되면, 원칙 없는 명명은 엔지니어의 "인지 부하(Cognitive Load)"를 극단적으로 상승시킵니다.

"이 자산이 운영망(Prod)에 속해 있는가?"
"장애 발생 시 당장 프로세스를 Kill 해도 안전한가?"

이러한 필수적인 질문의 답을 찾기 위해 매번 콘솔이나 콘피그 파일을 열어봐야 한다면, 이는 곧 장애 복구 시간(MTTR)의 치명적 지연과 유령 자산(Zombie Resources) 방치로 인한 클라우드 비용 누수로 직결됩니다.

따라서 인프라의 이름 자체를 하나의 '고유한 식별 메타데이터'로 기능하게 만드는 작업이 필수적입니다.

1.2 식별 체계를 구축

① 예측 가능성(Predictability) 확보

자산의 이름만으로 배포 위치, 환경, 속한 도메인을 즉시 유추할 수 있도록 일정한 템플릿으로 패턴화했습니다.

② Naming과 Tagging의 철저한 구조적 역할 분리

과거에는 이름표 하나에 소유자나 세부 용도까지 모두 욱여넣으려다 규칙이 무너지는 경우가 많았습니다.
본 설계에서는 Naming은 '물리 및 논리적 고유 자산 식별'으로만 그 임무를 엄격하게 한정합니다.
반면 Tagging은 '비용 정산(Billing), 권한 제어(IAM/RBAC), 자동화 운영 훅(Ops Hook)'으로 역할을 완전히 분리하여, 데이터 파편화와 관리 복잡성을 원천적으로 해소했습니다.

③ 하이브리드 환경의 모델 단일화

AWS 위치 기반의 네이밍(예: apn2)과 On-prem의 물리적 거점 기반 네이밍(예: wisoft)을 동일한 추상화 선상에 배치했습니다.
이를 통해 엔지니어가 클라우드와 물리 서버라는 위치의 제약에 구애받지 않고, 단일화된 멘탈 모델로 전체 인프라를 일관성 있게 다룰 수 있습니다.

2. Naming Standard (명명 표준)

2.1 Naming Format

자산이 배포된 물리적 위치에 따라 아래의 형식을 엄격히 따릅니다.

AWS 클라우드 환경

{resource}-nangman-{env}-{service}-{loc}[-{suffix}]

On-premise 시스템 환경

{platform}-nangman-{env}-{service}-{site}[-{suffix}]

2.2 필드 정의 (Field Definitions)

필드명	설명 및 역할
resource	AWS 리소스 약어 (ec2, rds, alb 등)
platform	On-prem 자산 유형 (vm, phy)
nangman	환경 전체를 묶는 고정 네임스페이스
env	배치 환경 (dev, tst, prd, ops)
service	해당 자산이 기여하는 시스템 식별 도메인
loc	AWS 배포 위치 코드 (apn2, apn2a, apn2b, apn2c)
site	On-prem 운영 거점 (wisoft, seokchon, goyang, daejeon)
suffix	동일 자산 N대 배포 시 넘버링 용도 (01, 02 순으로 사용)

2.3 제약 및 통제 규칙 (Naming Rules)

문자열 제한: 모든 이름은 소문자만을 사용하며, 단어 구분자는 하이픈(-)만 허용합니다. 공백 및 기타 특수문자는 어떠한 예외도 없이 금지합니다.
무의미한 단어 배제: server, instance, ubuntu, test, temp 등 의미를 알 수 없거나 리소스 타입 자체를 재차 뜻하는 낭비성 단어의 결합을 금지합니다.
글자 수 최적화: AWS 통합 명칭 기준으로 단일 이름이 최대 32자를 초과하지 않는 것을 목표로 합니다. On-prem 자산 역시 가급적 짧은 식별자를 유지합니다.
Suffix(순번) 생략: 환경 내에서 단독으로 돌고 있는 단일 자산일 경우, 불필요한 suffix(01, 02)는 붙이지 않고 생략합니다.

2.4 공통 표준 약어 사전

1. 환경 (Environment)

값	환경 의미 및 부여 용도
dev	개발 환경 및 개인 단위의 테스트 용도
tst	아키텍처 단위의 테스트 및 통합 검증 전용 환경
prd	대외 서비스가 동작하는 실제 프로덕션(운영) 환경
ops	모든 환경을 관리하는 공통 인프라 파이프라인 영역

2. AWS 리소스 (Resource)

리소스 명칭	지정 약어	리소스 명칭	지정 약어
EC2	ec2	Route Table	rt
RDS	rds	Subnet	sbn
ALB	alb	Lambda	lmbd
Security Group	seg	Bedrock	bdrk
S3	s3	IAM 역할	iam

3. On-prem 플랫폼 (Platform)

물리 리소스 명칭	지정 약어
Virtual Machine (가상머신)	vm
Physical Host (베어메탈)	phy

2.5 체계 적용 예시 (Naming Examples)

AWS 클라우드 자산 예시

ec2-nangman-prd-auth-apn2a 
ec2-nangman-prd-auth-apn2a-01
ec2-nangman-prd-auth-apn2c-02
rds-nangman-prd-mail-apn2c
alb-nangman-prd-web-apn2

On-premise 자산 예시

vm-nangman-ops-build-wisoft
vm-nangman-ops-npm-seokchon
phy-nangman-prd-storage-goyang

3. AS-IS / TO-BE 아키텍처 전환 사례

과거 편의에 기대어 직관적으로만 지어졌던 레거시 명칭들은 다음과 같이 맥락이 뚜렷한 표준 체계로 재편성됩니다.

과거 식별자 (AS-IS)	전환 후 식별자 (TO-BE)	구조적 설명 (비고)
wisoft-nangman-build-server	vm-nangman-ops-build-wisoft	빌드 전용 공용 운영 자산 (On-prem VM)
seongwon-nginx-proxy-manager	vm-nangman-ops-npm-seokchon	석촌 사이트 거점 NPM 프록시 (On-prem VM)
ec2-nangman-jungbin-ubuntu	ec2-nangman-dev-jungbin-apn2a	특정 개발자의 클라우드 개인 샌드박스 자산

4. AWS Tagging Policy

4.1 파이프라인 통제 대상

필수 태깅 대상 (Mandatory)

EC2, RDS, ALB / NLB, Security Group, VPC, Subnet, Route Table, S3, Lambda, IAM Role, CloudWatch Alarm 등

수동 태그 Best-Effort 및 예외 대상

ENI, EIP, 클라우드 자동 생성 파생 리소스, 단발성 임시 리소스 등은 인력 낭비를 초래하므로 억지로 수동 관리를 시도하지 않습니다.

4.2 필수 태그 설계: 왜 이 4가지인가?

인프라 태그는 세밀하게 많이 달수록 좋을 것 같지만, 강제해야 하는 필수 태그 값이 5개를 넘어가게 되면 작업자의 피로도가 상승합니다.

따라서 본 인프라를 운용하는 데 있어 타협 불가능한 최소한의 기준 4가지만 필수 태그로 제한하여 전사적 관리를 강제했습니다. 개인 실명 연락처(이메일 등)는 퇴사나 보직 배치 시 악성 분리 포인트가 되므로, 태그 값으로 절대 입력하지 않습니다.

Name (운영자 직접 인지 및 검색 목적)
- Naming Standard 체계로 만들어진 시스템 이름과 동일한 값입니다. AWS 콘솔 및 CLI 환경에서 가장 최우선으로 노출되며, 모든 검색 기반 자동화 파이프라인의 1차 진입점이 됩니다.
Environment (보안망 및 RBAC 격리 목적)
- 동일한 특성을 띄는 자산일지라도 dev와 prd는 접근 제어(IAM/SG) 정책 체계가 완전히 분리되어야 합니다. 이 태그는 역할 기반 로직(RBAC)과 네트워크 논리 격리의 기준점이 됩니다. 허용 규격: (dev, tst, prd, ops)
Scope (장애 파급력 및 영향도 제어 목적)
- 해당 자산에 이상이 감지되었을 때, 혹은 엔지니어가 직접 변경 작업을 수행할 때 영향을 미치는 영역망이 개인 샌드박스(personal)인지, 팀 내부망(shared)인지, 대외 퍼블릭 서비스망(public)인지 단 1초만에 즉각 파악하기 위한 시각적 제동 장치입니다.
Owner (운영 에스컬레이션 및 비용 누수 추적 목적)
- AWS Cost Explorer를 통해 조직/서비스 단위로 사용 비용 누수를 추적(Billing Tracking)하거나, 심각한 보안 및 코어 얼럿 발생 시 즉각적으로 비상 연락망을 가동할 책임 주체 조직을 명시합니다.

4.3 선택/내부 파이프라인 태그 (Optional)

인프라 내 특수한 파이프라인 자동화를 목적으로 사용하는 일회성 혹은 선별적 태그 규격입니다. 아래는 EC2의 일괄 OS 패치 관리를 위한 내부 분기 처리 훅(Hook) 예시입니다.

Key: Patch (EC2 자산 한정)
Value: Yes 또는 No (Patch=Yes 로 마킹된 EC2만 시스템 스크립트 실행 대상으로 처리)

4.4 표준 구성 모델 아웃풋 예시

1. 개인 클라우드 개발 인스턴스 (Personal / Dev)

Name        = ec2-nangman-dev-jungbin-apn2a
Environment = dev
Scope       = personal
Owner       = jungbin
Patch       = Yes

2. 온프레미스 통합 빌드 파이프라인 서버 (Shared / Build Server)

Name        = vm-nangman-ops-build-wisoft
Environment = ops
Scope       = shared
Owner       = wisoft

3. 온프레미스 리버스 프록시 노드 (Shared / Proxy)

Name        = vm-nangman-ops-npm-seokchon
Environment = ops
Scope       = shared
Owner       = seongwon

5. 예외 규칙

엔지니어의 제어권을 넘어서는 AWS Managed Service나 구조적인 명칭 제약이 따르는 일부 자산의 경우에는, 아키텍처 리뷰 합의 하에 부분적인 예외를 인정합니다.

S3 Bucket: 전 세계 AWS 글로벌 자산과 이름 충돌이 발생하지 않도록, 임의의 난수나 고유 시퀀스를 후단에 결합합니다. (예: nangman-prd-logs-123456)
DBMS 내부 마스킹 객체: 개발 과정의 호환성과 SQL 쿼팅 이슈를 회피하기 위해, 데이터베이스 내 스키마나 테이블 등의 정의는 snake_case 형식을 단독 허용합니다. (예: user_profile, mail_queue)
인프라 파생 컴퓨팅 리소스: EKS, ECS, AutoScaling 등을 통해 자체적으로 스케일링/파생되는 하위 컴퓨팅 리소스들은 Name 필드를 통한 제어보단 Tag를 기반으로 관리하는 것을 압도적으로 우선합니다.

6. 운영 원칙 가이드라인

표준은 타협하지 않습니다. 신규 자산을 프로비저닝할 때는 본 문서의 Naming Standard 가이드를 어떠한 예외 없이 무조건 준수해야 합니다.
독단적 행위를 배척합니다. 표준 약어 목록에 없는 신규 약어가 구조적으로 필요할 시, 엔지니어의 개인 결정이 아닌 팀 내 시스템 리뷰를 통과한 건에 대해서만 정책에 반영합니다.
명확하게 분리하십시오. Naming은 철저히 시스템 구조 중심의 '접근 식별용'으로, 의무 태그(Tagging)는 책임자와 환경을 한정하는 '운영/통제용'으로 그 역할을 결코 섞지 않고 분리 사용합니다.

7. 핵심 시스템 요약 보드 (Cheatsheet)

Naming 포맷 공식

AWS        : {resource}-nangman-{env}-{service}-{loc}[-{suffix}]
On-premise : {platform}-nangman-{env}-{service}-{site}[-{suffix}]

필수 태그 정책 (Mandatory Tags 4종)

Name: 명명 표준 규칙으로 발급된 동일 값 세팅
Environment: 배포된 환경 티어링
Scope: 비즈니스 파급 효과 및 권한 망
Owner: 이슈/비용 에스컬레이션 주체

선택 태그 통제 (Optional Tags)

Patch (선택적 EC2 패치 제어 동작용 - Yes/No)

유정빈

cloud

이전 포스트

SageMaker Anomaly Detection: 지능형 봇 실시간 차단 시스템 구축기

다음 포스트