LabHub

CNPA — 클라우드 네이티브 플랫폼 엔지니어링 어소시에이트 · 골든 패스와 개발자 경험 · 이론

골든 패스는 강제가 아니라 가장 쉬운 길이어야 한다

LabHub 에서 이어서 보기

한 줄 요약

골든 패스(golden path)는 "이 길로만 가라"는 규정이 아니라 "이 길이 제일 편해서 굳이 다른 길을 갈 이유가 없다" 는 상태입니다. 강제로 만든 길은 골든 패스가 아니라 관문(gate)이고, 관문은 우회당합니다.

왜 이게 필요했나

플랫폼 팀이 표준을 만드는 방식은 대개 둘 중 하나입니다.

금지형 — "직접 만든 Deployment 는 배포 금지. 반드시 우리 차트를 쓸 것." 단기적으로는 규정 준수율이 오릅니다. 그런데 요구를 못 맞추는 팀이 생기면 예외 승인 프로세스가 생기고, 예외가 쌓이면 표준이 무의미해집니다. 무엇보다 플랫폼 팀이 심판이 되어 개발팀과 적대 관계가 됩니다.

골든 패스형 — "이 템플릿으로 시작하면 5 분 안에 관측·보안·배포가 다 붙은 서비스가 뜬다. 다른 방식도 가능하지만 그 경우 이 셋을 직접 챙겨야 한다." 강제가 없는데 대부분이 씁니다. 게으름이 표준 준수와 같은 방향을 향하게 설계했기 때문입니다.

핵심 통찰은 이겁니다. 사람은 규정을 따르는 게 아니라 마찰이 적은 쪽을 따릅니다. 플랫폼의 일은 옳은 길의 마찰을 0 에 가깝게 만드는 것입니다.

어떻게 동작하나

골든 패스의 최소 구성

골든 패스 하나는 다음 네 가지가 한 몸 이어야 합니다. 하나라도 빠지면 "예제 저장소"로 전락합니다.

1. 스캐폴딩 — 명령 하나 또는 폼 하나로 저장소·매니페스트·파이프라인이 생성된다.
2. 기본값 — 리소스 요청/제한, 보안 컨텍스트, 프로브, 라벨 규약, 관측 애너테이션이 이미 들어 있다.
3. 문서 — 생성된 코드 옆에 살아 있고, 템플릿이 바뀌면 같이 바뀐다.
4. 소유권 — 만든 순간 소유 팀이 카탈로그에 기록된다. 6 개월 뒤 "이거 누구 거지?"가 나오지 않는다.

문서가 왜 같은 몸이어야 하는지가 자주 과소평가됩니다. 템플릿은 진화합니다. 문서가 위키에 따로 살면 3 개월 만에 어긋나고, 어긋난 문서는 없는 문서보다 나쁩니다. 그래서 docs-as-code — 문서를 코드와 같은 저장소, 같은 PR, 같은 리뷰로 관리 — 가 골든 패스의 필수 요소입니다.

셀프서비스와 가드레일의 균형

셀프서비스는 권한을 넓히는 일이고, 가드레일은 그 넓힘이 사고로 이어지지 않게 하는 일입니다. 둘의 배치가 개발자 경험을 좌우합니다.

| 가드레일 위치 | 예 | 피드백 속도 | 개발자 경험 |
| --- | --- | --- | --- |
| 스키마(API 서버) | CRD 의 maximum: 10 | 즉시 | 최고 |
| 어드미션 정책 | 정책 엔진의 검증 웹훅 | 즉시(적용 시점) | 좋음 (메시지가 명확하면) |
| 쿼터·리밋 | ResourceQuota, LimitRange | 즉시(생성 시점) | 좋음 |
| CI 검사 | 파이프라인의 린트·정책 검사 | 수 분 | 보통 |
| 사후 감사 | 리포트, 대시보드 | 수 시간~수 일 | 나쁨 |

원칙은 가능한 한 왼쪽으로 입니다. 같은 규칙이라면 사후 리포트보다 스키마가 낫습니다. 실패는 빨리, 가까이서, 사람이 읽을 수 있는 말로 일어나야 합니다.

그리고 가드레일에는 반드시 이유 가 붙어야 합니다. "거부됨: 정책 위반"과 "거부됨: 프로덕션 네임스페이스의 컨테이너는 메모리 제한이 필요합니다. 예: resources.limits.memory: 512Mi" 사이의 차이가 곧 플랫폼의 평판입니다.

무엇을 골든 패스로 만들 것인가

전부 만들 수는 없습니다. 우선순위는 빈도 × 마찰 입니다. 한 달에 한 번 하는 어려운 일보다, 매주 하는 짜증나는 일이 먼저입니다. 전형적인 후보는 새 서비스 스캐폴딩, 새 환경 추가, 데이터베이스 붙이기, 대시보드·알림 생성, 온콜 등록 정도입니다.

그리고 골든 패스는 버전 이 있어야 합니다. v2 를 내면 v1 사용자를 어떻게 옮길 것인지가 곧바로 문제가 됩니다. 마이그레이션 계획 없는 v2 는 표준을 하나 더 만드는 것일 뿐입니다.

현장에서 만나는 모습

저자의 홈랩은 골든 패스가 없을 때 무슨 일이 생기는지를 잘 보여줍니다. Gateway API 는 CRD v1.6.1 이 필요했고 v1.2 로는 tlsroutesreferencegrants 가 v1 이 아니어서 Cilium 게이트웨이 컨트롤러가 기동을 거부했습니다. KubeVirt 는 containerDisk 경로에 결함이 있어 DataVolume(PVC) 경로로 우회해야 Fedora VM 이 부팅했습니다. GPU Operator 는 containerd 런타임 설정에서 사고가 났습니다.

이 사건들의 공통점은 한 번 밟으면 다시는 밟지 않을 함정 이라는 것입니다. 그리고 그 지식이 사람 머릿속에만 있으면 다음 사람이 똑같이 밟습니다. 골든 패스의 본질이 여기 있습니다 — 플랫폼 팀이 대신 밟은 함정을 템플릿의 기본값과 문서로 굳혀서 다른 사람은 밟지 않게 만드는 것.

또 하나 눈여겨볼 것은 kube-proxy 없는 Cilium 구성입니다. --skip-phases=addon/kube-proxy 로 아예 설치하지 않았고, 나중에 지우는 것과는 다르다는 점을 iptables KUBE- 체인 0 개 로 확인했습니다. "지운 것"과 "처음부터 만들지 않은 것"이 다르다는 이 감각은 골든 패스에도 그대로 적용됩니다. 나쁜 기본값을 나중에 고치는 것보다, 처음부터 좋은 기본값으로 생성되게 하는 편이 언제나 싸게 먹힙니다.

다음 실습에서 할 것

/root/cnpa-path/ 에 서비스 스캐폴드 한 세트(Deployment/Service/HPA/PDB/NetworkPolicy)를 만들고, 가드레일이 있는 네임스페이스에 실제로 올립니다. 이어서 helm create 로 로컬 차트를 만들어 values 로 환경을 분기하고, helm template 렌더 결과를 다시 클러스터에 적용해 봅니다.