고객 문제가 제품을 만든다: Oxide 위에서 Kubernetes 운영하기
2024년 말, Oxide 컴퓨트 플랫폼 위에서 Kubernetes를 실행하고 싶은 고객은 많았지만, 이를 공식적으로 지원하는 통합(integration)은 전혀 없었다. Kubernetes는 인프라 동작을 표준 확장 포인트로 정의하고, Oxide는 그 동작을 구현할 수 있는 API 프리미티브를 제공하기 때문에 두 기술은 본질적으로 잘 맞는다. 토대는 있었지만, 그 사이를 잇는 소프트웨어와 "어떤 통합이 실제로 필요한가"에 대한 이해가 비어 있었다.
추상이 아닌 실제 문제에서 출발한 설계
Oxide의 첫 번째 Solutions Software Engineer로 합류한 Matthew Sanabria는 첫 주에 두 가지 자료를 건네받았다. 고객이 직접 제출한 Rancher 노드 드라이버 Pull Request, 그리고 Kubernetes 통합의 초기 방향을 담은 내부 문서 초안이었다. 이 두 리소스가 팀 전체의 작업 방향을 결정짓는 출발점이 되었다.
핵심은 피드백 루프였다. 추상적인 설계를 먼저 그리고 개발하는 방식 대신, 고객이 클러스터를 프로비저닝하고 워크로드를 운영하면서 실제로 부딪히는 문제를 따라가는 방식으로 통합을 설계했다. 각 단계에서 드러난 문제가 다음 단계의 작업 범위를 결정했다.
Kubernetes 라이프사이클 전반을 따라간 문제들
Kubernetes 운영은 단일 단계의 문제가 아니다. Oxide 팀이 경험한 문제는 라이프사이클 단계별로 명확하게 구분되었다.
- 프로비저닝: 고객마다 다른 워크플로우는 Rancher, Omni, Cluster API 등 여러 통합의 필요성으로 이어졌다. 가장 먼저 Rancher 노드 드라이버 PR을 제출한 고객의 유즈케이스를 해결하는 것이 최우선이었다.
- 클러스터 운영: 클러스터를 띄운 이후에는 인프라 조정(reconciliation) 문제가 드러났다.
- 애플리케이션 노출: 외부로 서비스를 노출하는 과정에서 네트워킹 레이어의 공백이 확인되었다.
- 스테이트풀 워크로드: 상태를 가진 워크로드를 실행하자 스토리지 제약이 수면 위로 올라왔다.
각 단계의 문제는 다음 단계의 갭을 드러냈고, 그 갭이 다시 팀이 무엇을 만들어야 할지를 정의했다.
Customer Problem → Integration Gap → Platform Work → Next Problem
이 흐름은 단순한 개발 순서가 아니라, 실무 중심의 제품 설계 철학을 그대로 보여준다.
실무에서 얻을 수 있는 시사점
백엔드 개발자 관점에서 이 사례가 중요한 이유는 기술 선택 자체보다 통합 설계의 접근 방식 때문이다. Kubernetes와 Oxide의 통합은 미리 완성된 설계를 구현한 것이 아니라, 고객 워크플로우가 드러내는 문제를 반복적으로 해결하면서 형태를 갖춰나갔다.
이는 API 설계, 플랫폼 통합, 인프라 자동화를 담당하는 개발자라면 익숙하게 마주치는 상황이다. 어떤 시스템이든 실제 사용자의 워크플로우를 따라가면 설계 단계에서는 보이지 않던 제약과 공백이 반드시 등장한다. Cluster API 같은 표준 확장 포인트를 활용하는 전략도, 그 선택이 추상적인 아키텍처 고민이 아니라 구체적인 고객 문제에서 비롯되었다는 점에서 의미가 있다.
정리
- 통합 설계는 추상적인 아키텍처보다 실제 고객 워크플로우 기반의 피드백 루프로 시작할 때 더 현실적인 결과를 낸다.
- Kubernetes 라이프사이클(프로비저닝 → 운영 → 네트워킹 → 스토리지)의 각 단계는 독립적인 기술 문제가 아니라 연쇄적으로 드러나는 갭의 연속이다.
- 표준 확장 포인트(Cluster API 등)를 활용한 통합 전략은 특정 툴 의존도를 낮추고 다양한 고객 워크플로우를 수용하는 데 유리하다.