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

한 줄 요약

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

왜 이게 필요했나

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

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

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

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

흐름 강조 재생 · 다시 보려면 해제 후 선택

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

여기서 구분할 것 네 가지라는 구성은 본문의 정리이고 공식 문서가 정한 정의가 아니다. 연결한 Backstage 문서는 템플릿으로 서비스의 저장소를 만드는 도구의 설명이다.

잠깐, 예측해 보세요 새 서비스 템플릿이 저장소와 파이프라인과 기본값은 만들어 주지만 소유 팀을 카탈로그에 기록하는 일은 하지 않는다. 본문 기준으로 이 템플릿은 골든 패스일까?

설명 확인 · 채점 없는 자가 점검

아니다. 본문은 네 가지가 한 몸이어야 하고 하나라도 빠지면 예제 저장소로 전락한다고 말한다. 소유권이 빠지면 몇 달 뒤 이 서비스가 누구 것인지 묻는 문제가 다시 생긴다.

근거 문서

어떻게 동작하나

골든 패스의 최소 구성

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

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 로는 tlsroutes 와 referencegrants 가 v1 이 아니어서 Cilium 게이트웨이 컨트롤러가 기동을 거부했습니다. KubeVirt 는 containerDisk 경로에 결함이 있어 DataVolume(PVC) 경로로 우회해야 Fedora VM 이 부팅했습니다. GPU Operator 는 containerd 런타임 설정에서 사고가 났습니다.

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

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

• 지식이 사람 머릿속에만 있을 때필요한 CRD 버전이 맞지 않아 게이트웨이 컨트롤러가 기동을 거부했고, KubeVirt 는 containerDisk 경로의 결함 때문에 DataVolume 경로로 우회해야 했으며, GPU Operator 는 런타임 설정에서 사고가 났다. 한 번 밟으면 다시 밟지 않을 함정이지만 다음 사람이 똑같이 밟는다.
• 템플릿의 기본값과 문서로 굳혔을 때플랫폼 팀이 대신 밟은 함정을 기본값과 문서로 굳히면 다른 사람은 밟지 않는다. 나쁜 기본값을 나중에 고치는 것보다 처음부터 좋은 기본값으로 생성되게 하는 편이 언제나 싸게 먹힌다고 본문은 말한다.

여기서 구분할 것 이 사례는 저자 홈랩의 서술이 근거이고 공식 문서가 보증하는 것이 아니다. 구체적인 버전 숫자는 공식 문서로 확인하지 못해 옮기지 않았다. 지운 것과 처음부터 만들지 않은 것이 다르다는 본문의 감각이 요점이다.

잠깐, 예측해 보세요 플랫폼 팀이 어려운 설치 함정을 겪고 해결 방법을 사내 위키에 정리해 두었다. 본문의 기준으로 이것만으로 다음 팀이 같은 함정을 밟지 않는다고 말할 수 있을까?

설명 확인 · 채점 없는 자가 점검

말하기 어렵다. 본문은 지식이 사람 머릿속에만 있으면 다음 사람이 똑같이 밟는다고 한다. 해결이 템플릿의 기본값과 문서로 굳어 있어야 새 서비스가 처음부터 그 함정을 피해서 생성된다.

근거 문서

다음 실습에서 할 것

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