플랫폼 엔지니어링 04 - 골든 패스 설계하기

스스로 선택하는 길

1편에서 골든 패스의 개념을 소개했다. 무언가를 수행하는 데 있어 권장되고 잘 지원되는 방법을 의미하는 것이었다. 이번 포스트에서는 실전으로 넘어간다. 골든 패스를 어떻게 설계하는지, 그리고 팀이 이탈하면 어떻게 대응해야 하는지를 다룬다.

좋은 골든 패스의 조건

모든 골든 패스가 같은 가치를 지니는 것은 아니다. 잘못 설계된 골든 패스는 관료주의처럼 느껴지고, 잘 설계된 골든 패스는 지름길처럼 느껴진다. 이 둘을 가르는 것은 세 가지 원칙이다.

첫째, 골든 패스는 선택이지 강제가 아니어야 한다. 강제하는 순간 그것은 길이 아니라 울타리가 된다. 개발자가 더 나은 선택지이기 때문에 자발적으로 따르는 것이어야 의미가 있는 것이다.

둘째, 도입이 쉬워야 한다. 골든 패스에 올라타기 위해 일주일간의 마이그레이션이 필요하다면 대부분의 팀은 시도조차 하지 않는다. 진입로가 도로 자체만큼 중요한 셈이다.

셋째, 문서가 충실해야 한다. 문서가 없는 골든 패스는 플랫폼 팀의 특정 구성원만 알고 있는 비공식 경로에 불과하다. "어떻게" 사용하는지뿐 아니라 "왜" 이렇게 설계되었는지까지 기록해 두어야 한다.

단계별 설계

먼저 워크플로를 선택한다. 빈번하게 발생하면서 고통이 큰 작업부터 시작하는 것이 효과적이며, "웹 서비스 배포"가 전형적인 첫 번째 대상이다.

다음으로 현재 상태를 파악한다. 3~5개 팀과 대화하며 지금 어떤 방식으로 작업하고 있는지, 어디에서 마찰을 경험하는지를 듣는다.

그런 다음 이상적인 경로를 설계한다. 개발자가 직접 수행해야 할 부분과 플랫폼이 자동으로 처리할 부분을 구분하는 것이 핵심이다.

경로가 정해지면 템플릿을 만든다. 레포 구조, CI 설정, Dockerfile, 배포 매니페스트, 관측 가능성 셋업을 모두 포함시킨다.

완성된 템플릿은 바로 전체 공개하지 않는다. 먼저 한 팀을 찾아서 실제로 시도해 보고, 어디에서 막히는지를 관찰한다.

마지막으로 거친 부분을 다듬고, 문서를 작성한 후 전체에 공개한다.

프로젝트 템플릿

대부분의 골든 패스에서 진입점 역할을 하는 것은 프로젝트 템플릿이다.

my-service-template/
├── src/                    # 헬스체크 엔드포인트가 포함된 시작 코드
├── Dockerfile              # 프로덕션 대응, 멀티스테이지 빌드
├── .github/workflows/      # 미리 설정된 CI 파이프라인
├── k8s/                    # 합리적 기본값의 배포 매니페스트
├── observability/           # 로깅 및 메트릭 설정
├── README.md               # "이걸 실행하면 시작됩니다"
└── Makefile                # 공통 명령: build, test, deploy

이 템플릿은 꺼내자마자 바로 동작해야 한다. git clone을 하고 make run을 실행하면 CI, 배포, 모니터링이 전부 연결된 서비스가 올라오는 것이 목표이다.

실전 예시

웹 서비스 골든 패스의 경우, 프레임워크 스캐폴딩, CI 파이프라인, Kubernetes 매니페스트, Prometheus 메트릭, 구조화된 로깅이 포함된 템플릿 레포를 제공한다. 개발자는 이를 클론하고, 서비스 이름을 변경하고, 푸시하면 몇 분 안에 스테이징 환경에 배포되는 것이다.

데이터 파이프라인 골든 패스의 경우에는 Airflow DAG 구조, 데이터 품질 검증, 웨어하우스 연결, 실패 알림이 포함된 템플릿을 제공한다. 데이터 엔지니어는 변환 로직만 채우면 되고, 나머지 인프라 구성은 플랫폼이 처리하는 구조이다.

이탈하는 팀 대응법

골든 패스에서 이탈하는 팀은 반드시 발생한다. 선택이지 강제가 아닌 이상 이는 자연스러운 현상이다. 다만 왜 떠나는지를 파악하는 것은 중요하다.

여기서 최악의 대응은 채택을 강제하는 것이다. 가장 효과적인 대응은 골든 패스를 충분히 좋게 만들어서 이탈하는 것이 오히려 수고처럼 느껴지게 하는 것이다.

실체가 되는 지점

골든 패스는 플랫폼 엔지니어링이 추상적인 개념에서 벗어나 실체를 갖게 되는 지점이다. 아키텍처 다이어그램이나 전략 문서가 아니라, 개발자가 매일 접하고 사용하는 실제 결과물이기 때문이다.

잘 설계된 골든 패스는 이를 채택하는 모든 팀의 생산성을 배가시킨다. 반면 잘못 설계된 골든 패스는 회고에서 불만의 대상이 되는 장식품으로 전락하게 된다.

다음 포스트에서는 IaC를 다룬다. 골든 패스가 그 위에 서 있는 기반이 되는 인프라 코드이다.