Summary

• 단일 default-pool에 섞여 있던 워크로드를 api-pool, worker-pool, ops-pool로 분리하고 nodeSelector로 배치 위치 고정
• ArgoCD App of Apps 패턴으로 여러 Application을 중앙 관리하고 Sync Wave로 설치 순서 제어
• Namespace, RBAC, ResourceQuota 기반 멀티 테넌시 구성과 Enterprise 전용 API 배포
• settings.local.json의 allow, ask, deny 권한 규칙을 통한 자연어 가드레일의 기술적 보완

Thoughts

• 정의된 가드레일 외의 작업시에도 질문>탐색>실행의 구조 필요
  • 실습 도중 기존 helm cli로 설치된 패키지 또한 App of Apps 패턴의 관리범위에 넣도록 지시
  • 사전에 별도의 작업 영향도 분석 및 방법 확인 없이 단순히 전환하라는 프롬프트 전달
  • 실제 작업시 2가지 이슈로 인한 일부 서비스 중단 발생
    • 1) helm release name 차이로 인한 리소스 중복 생성 > 리소스 부하 및 RBAC 꼬임
    • 2) (Valkey) helm chart의 무작위값이 보존되지 않아 (auth-secret) 재생성 > api서비스 중단
• AI의 문제라기보다는 기존에 사람이 작업할때도 비슷한 문제 종종 발생
  • 직접 작업할때도 놓친 부분이 있으면 마무리 보완작업
  • 상황 분석, 원인 파악 및 대응 제시는 AI가 더 빠르니 그래도 장점이지 않나
• AI시대의 사람 관리자의 역할은 이러한 작업내용을 예상하고 디렉팅 해줄 수 있는 사람
  • AI가 제안하는 부분 외의 부분을 파악하고 적절할때 제시할 수 있을 것
  • 작업 순서 (argocd auto-sync 임시 비활성화, 등) 및 작업 영향도 (실제 서비스 중단 여부)
  • 지침만 내려주면 직접 YAML작성, 커밋명고민, 푸시이후 확인 등은 이전보다 빠르게 진행 가능

---

7장. 규모 확장

• 엔터프라이즈 고객의 전용 환경 요구
• 현재는 2개의 노드에 API,Valkey,Monitoring,ArgoCD혼재/단일네임스페이스 > 요구 충족 불가
• 멀티노드풀: 워크로드별 노드 분리, App of Apps: 늘어나는 앱 체계적관리, 멀티 테넌시: 고객별 격리 환경

7.1 성장통: SMB 구조의 한계

• 현재구조의 2가지 문제점
  • 리소스 경합: 프로메테우스가 메트릭을 수집하며 CPU 과다사용시 동일 노드의 API 응답 지연
  • 격리 불가: 고객사의 데이터 및 성능 분리 요청
• 해결 방향
  • 노드풀 분리: API, 모니터링 등 역할별 노드 분리
  • 테넌트 분리: 고객별로 네임스페이스 구분 및 리소스 격리
• 추후 추가될 구성요소(테넌트, 카프카 등)의 용이한 관리를 위해 ArgoCD AppofApps 패턴 구축

7.2 워크로드별 노드 배치: 멀티 노드풀

• 워크로드 성격에 맞는 머신 유형과 자원 한도를 적용하고 장애, 부하 영향을 분리하기 위한 멀티 노드풀 구성

7.2.1 클로드 코드에게 노드 분리 방법 물어보기

• cc에게 다수pod가 노드에서 실행 중, 역할에 따라 노드 분리방법 질문
  • nodeSelector, taint/toleration, node affinity, topology spread 방식 제시
  • 현재 규모에서는 가장 단순하고 명시적인 nodeSelector 우선 추천

7.2.2 다른 도구는 없는지 비교해보기

• cc에게 nodeSelector 외의 워크로드 배치 방식과 장단점 비교 요청
  • taint/toleration은 전용 노드 보호, node affinity는 선호/필수 조건 조합, topology spread는 영역별 분산
  • 현재 규모에서는 nodeSelector와 replicas 조합을 사용하고 복잡한 정책은 성장 후 검토하는 방향 추천

7.2.3 멀티 노드풀 생성하기

• cc에게 멀티 노드풀 적용 지시
  • api-pool은 e2-medium, worker-pool은 Kafka용 e2-standard-2, ops-pool은 e2-small Spot 노드로 생성

7.3 다수 앱 관리: App of Apps 패턴 + Sync Wave

• 늘어나는 ArgoCD Application을 하나씩 적용하지 않고 루트 Application 아래에서 선언적으로 통합 관리
  • App Of Apps Pattern(ArgoCD), 개념/구현예시 등
  • Sync Phases and Waves(ArgoCD), 다수 앱을 동기화시 작업 순서에 대한 단계 및 설정

7.3.1 클로드 코드에게 여러 앱 관리 방법 물어보기

• cc에게 Notiflex, 모니터링, Kafka처럼 ArgoCD Application이 계속 늘어날 때 한곳에서 관리할 방법 질문
  • 다른 Application을 관리하는 루트 Application을 두는 App of Apps 패턴 추천
  • argocd/root-app.yaml이 argocd/apps/의 하위 Application 정의를 반복적으로 읽는 구조 제안
  • Application 추가, 변경 누락을 줄이고 Git에서 전체 앱 구성을 확인할 수 있다는 응답

7.3.2 다른 도구는 없는지 비교해보기

• cc에게 App of Apps외의 다른 방법들 비교 요청
  • 개별 수동관리(kubectl apply)는 단순하지만 앱 수만큼 수동 작업과 누락 가능성 증가
  • ApplicationSet은 유사한 앱, 환경을 대량 생성할 때 유리하지만 현재 규모에는 과도한 추상화
  • App of Apps는 명시적인 YAML과 계층 구조가 장점이며 구성이 서로 다른 현재 환경에 적합

7.3.3 App of Apps 패턴 적용하기

• cc에게 App of Apps 패턴 적용 지시
  • 루트 Application에서 argocd/apps 경로를 재귀 탐색하고 sync-wave, prune, self-heal 활성화
  • 개별 application 단위가 아닌 root-app 등록과 변경에 따른 하위요소 동기화

7.3.4 Sync Wave로 설치 순서 정하기

• cc에게 설치할 앱들 간 우선 순위 적용 지시
  • Namespace, Gateway, CRD 같은 기반 리소스를 먼저, 모니터링을 다음, Notiflex, Valkey, Kafka를 마지막에 배포하는 순서 정의

7.4 멀티 테넌시: 네임스페이스 격리

• SMB와 Enterprise 워크로드를 별도 Namespace로 분리
• 같은 클러스터, Valkey를 사용하되 배포와 자원 경계를 독립 관리

7.4.1 클로드 코드에게 멀티 테넌시 방법 물어보기

• cc에게 특정고객용 별도환경 구성 및 관리방법 질문
  • 별도의 ns로 구분하고 RBAC으로 접근제어 권고

7.4.2 다른 도구는 없는지 비교해보기

• cc에게 Namespace 격리, vCluster, 별도 GKE 클러스터 방식의 차이 비교 요청
  • Namespace+RBAC는 비용과 운영 복잡도가 낮은 기본 논리 격리
  • vCluster와 별도 클러스터는 격리가 강하지만 자원, 운영 비용 증가

7.4.3 멀티 테넌시 구성하기

• cc에게 멀티 테넌시 환경으로 구성 요청
  • enterprise Namespace와 Rollout 생성, tenant: enterprise 라벨과 api-pool 배치, valkey secret 생성
  • App of Apps가 k8s/enterprise를 관리하도록 notiflex-enterprise Application 추가

7.5 마무리: settings.local.json으로 권한 분리 체험

• CLAUDE.md의 자연어 행동 규칙을 넘어 Claude Code가 실행하려는 Bash 명령을 권한 정책으로 직접 제어

7.5.1 자연어 규칙의 한계

• CLAUDE.md의 ‘직접 kubectl apply/delete 금지’등의 규칙은 모델이 따르는 지침일 뿐 기술적 강제 장치가 아닌 상태
• 표현이 모호하거나 컨텍스트가 누락되면 위험 명령이 실행될 수 있어 실행 단계의 별도 통제 필요

7.5.2 settings.local.json 만들기

• cc에게 위험한 명령>차단, 비용 관련 명령>승인이 필요한 settings.local.json 생성 요청
  • .claude/settings.local.json에 명령 패턴별 allow, ask, deny 정책 설정
  • 조회성 kubectl get/logs는 허용, Helm 설치, 업그레이드와 노드풀 삭제는 승인 요청, 직접 apply, delete는 차단

7.5.3 차단(deny) 체험

• cc에게 enterprise ns의 notiflex를 kubectl 명령어로 제거 요청
  • kubectl delete deployment notiflex-api -n enterprise 요청 시 승인 창 없이 즉시 차단
  • 위험 명령을 모델의 판단에 맡기지 않고 패턴 수준에서 실행 불가로 만드는 효과 확인

7.5.4 승인(ask) 체험

• cc에게 worker-pool 노드는 불필요한거 같은데 제거 요청
  • gcloud container node-pools delete worker-pool 요청 시 바로 실행하지 않고 사용자 승인 요구
  • 반드시 금지할 명령은 deny, 상황에 따라 필요한 고위험 명령은 ask로 분리

7.5.5 CLAUDE.md에서 settings.local.json으로

• CLAUDE.md는 프로젝트의 원칙, 이유, 권장 절차를 설명하고 settings.local.json은 실제 도구 권한 집행
• 자연어 지침과 기계적 권한 정책을 함께 사용해 의도 전달과 실행 통제를 분리

7.5.6 체험 정리

• /update-docs로 멀티 노드풀, App of Apps, 멀티 테넌시 변경을 JOURNEY.md, ADR, claude-context/architecture.md에 반영
• API는 api-pool, Kafka는 worker-pool에 배치되고 Enterprise Namespace가 cross-namespace DNS로 Valkey를 공유하는 최종 상태 기록
• settings.local.json은 개인, 환경별 권한 설정, CLAUDE.md와 저장소 문서는 팀 전체의 지속 가능한 지식으로 구분

7.6 7장 가드레일 살펴보기

세부챕터	유형	참조 파일	역할
7.2 탐색/비교	탐색과 비교	decision-guides/ch7/7.2-node-scheduling.md	nodeSelector 추천 + taint/affinity 비교
7.2 실행	실행	prompt-guardrails/ch7/7.2-multi-nodepool.md	노드풀 3개 생성 + nodeSelector 설정
7.3 탐색/비교	탐색과 비교	decision-guides/ch7/7.3-multi-app-management.md	App of Apps 추천 + ApplicationSet 비교
7.3 실행	실행	prompt-guardrails/ch7/7.3-app-of-apps.md	루트 Application + 디렉터리 구조
7.4 탐색/비교	탐색과 비교	decision-guides/ch7/7.4-multi-tenancy.md	Namespace 분리 추천 + vCluster 비교
7.4 실행	실행	prompt-guardrails/ch7/7.4-multi-tenancy.md	enterprise 테넌트 생성 + App of Apps 연동
7장 마무리 체험	실행	prompt-guardrails/ch7/settings-local-example.md	settings.local.json 생성 → deny 체험 → ask 체험 → 되돌림