Infra

Apr 2, 2026

Kubernetes Namespace 가이드: 리소스를 왜 나눠서 봐야 할까

쿠버네티스를 처음 배울 때는 보통 작은 예제만 다루기 때문에 Namespace의 중요성이 잘 안 느껴집니다. 리소스 수가 적으면 전부 한곳에 있어도 문제 없어 보이기 때문입니다.

하지만 서비스가 늘고 팀이 나뉘고 환경이 분리되기 시작하면, 모든 리소스를 한 덩어리로 보는 방식이 빠르게 불편해집니다. 이때 Namespace가 클러스터 안의 논리적 경계 역할을 합니다.

이 글에서는 아래 내용을 정리합니다.

Namespace가 무엇인지
왜 필요한지
환경과 팀 단위로 어떻게 나누면 좋은지

핵심은 Namespace는 클러스터를 물리적으로 나누는 것이 아니라, 리소스를 논리적으로 분리하고 관리 범위를 명확하게 만드는 도구라는 점입니다.

Kubernetes Namespace란 무엇인가

Namespace는 클러스터 안의 리소스를 그룹화하는 논리적 공간입니다. 같은 클러스터 안에서도 dev, staging, prod처럼 서로 다른 영역을 나눠 관리할 수 있습니다.

예를 들어 아래처럼 구분할 수 있습니다.

dev: 개발용 리소스
staging: 검증용 리소스
prod: 운영 리소스

이렇게 두면 같은 이름의 리소스도 Namespace가 다르면 구분해서 다룰 수 있습니다.

왜 Namespace가 필요할까

리소스가 적을 때는 잘 안 느껴지지만, 실제로는 아래 이유 때문에 중요해집니다.

환경을 분리하기 쉽다
팀별 관리 범위를 나누기 쉽다
권한 제어를 더 명확하게 할 수 있다
리소스 쿼터나 정책 적용 범위를 나누기 좋다

즉, Namespace는 단순 폴더가 아니라 운영 경계에 가깝습니다.

Namespace 는 언제 나누는 게 좋을까

보통 아래 축으로 많이 나눕니다.

1. 환경 기준

가장 흔한 방식입니다.

dev
staging
prod

이 방식은 배포 단계가 분명할 때 이해하기 쉽고 운영도 직관적입니다.

2. 팀 기준

플랫폼 팀, 백엔드 팀, 데이터 팀처럼 책임 주체가 분명할 때 자주 씁니다.

3. 서비스 기준

서비스 규모가 크고 독립성이 높은 경우에는 서비스 단위 Namespace도 고려할 수 있습니다.

하지만 처음부터 너무 잘게 나누면 오히려 관리가 복잡해질 수 있어서, 입문 단계에서는 환경 기준이 가장 이해하기 쉽습니다.

Namespace 가 나눠 주는 것과 안 나눠 주는 것

이 부분도 중요합니다. Namespace는 논리적 분리이지, 모든 것을 자동으로 완전히 격리하는 것은 아닙니다.

예를 들어:

이름 충돌 완화: 도움 됨
RBAC 범위 분리: 도움 됨
리소스 정책 구분: 도움 됨
네트워크 완전 격리: 별도 정책 필요할 수 있음

즉, Namespace만 만든다고 자동으로 모든 경계가 생기는 것은 아닙니다. 보통은 RBAC, ResourceQuota, NetworkPolicy 같은 다른 구성과 같이 봅니다.

기본 예시

apiVersion: v1
kind: Namespace
metadata:
  name: staging

이제 이 Namespace 안에 Deployment, Service, ConfigMap 같은 리소스를 배치할 수 있습니다.

같은 web-service라는 이름도 dev와 staging 안에 각각 둘 수 있기 때문에, 환경별 리소스 구분이 훨씬 명확해집니다.

작은 프로젝트에서도 필요한가

항상 그런 것은 아닙니다. 개인 학습 클러스터나 매우 작은 실습 환경에서는 기본 namespace만 써도 큰 문제는 없습니다.

하지만 아래 조건 중 하나라도 맞으면 Namespace를 도입할 가치가 커집니다.

개발/운영을 나누고 싶다
팀별 권한을 분리하고 싶다
같은 클러스터에 여러 앱을 함께 둔다
실수로 운영 리소스를 건드릴 위험을 줄이고 싶다

자주 하는 실수

1. 모든 리소스를 default 에 두기

학습 초반에는 흔하지만, 조금만 규모가 커져도 관리가 빠르게 헷갈립니다.

2. 너무 이른 시점에 과하게 잘게 나누기

namespace가 너무 많으면 오히려 사람이 이해하기 어려워질 수 있습니다.

3. Namespace가 보안 격리를 전부 해결한다고 생각하기

실제로는 권한, 네트워크, 정책을 함께 봐야 합니다.

처음 공부할 때 추천하는 실습

dev 와 staging Namespace 만들기
같은 이름의 Deployment를 각 Namespace에 하나씩 만들기
kubectl get pods -n dev 와 -n staging 차이 보기
ConfigMap 과 Secret 도 Namespace마다 따로 만들어 보기

이 실습을 해 보면 Namespace가 단순 이름 공간이 아니라, 운영 범위를 나누는 감각적 도구라는 점이 빨리 잡힙니다.

FAQ

Q. Namespace를 앱마다 하나씩 만들어야 하나요?

항상 그렇지는 않습니다. 환경 기준, 팀 기준, 서비스 기준 중 무엇이 더 자연스러운지 먼저 보는 편이 좋습니다.

Q. default namespace를 써도 되나요?

작은 실습은 가능하지만, 운영이나 협업 흐름에서는 명시적인 Namespace가 더 안전합니다.

Q. Namespace를 나누면 Secret과 ConfigMap도 따로 관리되나요?

보통 그렇습니다. 이 점 때문에 환경별 설정 분리에 특히 유리합니다.

먼저 읽어볼 가이드

검색 유입이 많은 핵심 글부터 이어서 보세요.