이것은 SIG Architecture 스포트라이트 시리즈의 다섯 번째 인터뷰로, 다양한 하위 프로젝트들을 다루며, 이번에는 SIG Architecture: API 거버넌스를 다룰 것입니다.
이번 SIG Architecture 스포트라이트에서는 API 거버넌스 하위 프로젝트의 리더인 Jordan Liggitt와 이야기를 나누었습니다.
서론
FM: 안녕하세요, Jordan. 시간 내주셔서 감사합니다. 본인 소개, 역할, 그리고 쿠버네티스에 어떻게 참여하게 되셨는지 말씀해 주시겠어요?
JL: 제 이름은 Jordan Liggitt입니다. 저는 기독교인이자 남편, 네 아이의 아버지이며, 낮에는 Google에서 소프트웨어 엔지니어로 일하고, 몰래 아마추어 음악가 활동도 합니다. 저는 텍사스에서 태어났고 (여전히 그곳을 제 고향이라고 말하고 싶지만), 대부분의 삶을 노스캐롤라이나에서 보냈습니다.
저는 2014년부터 쿠버네티스에서 일했습니다. 그 당시 저는 Red Hat에서 인증 및 권한 부여 작업을 하고 있었는데, 쿠버네티스에 보낸 제 첫 번째 풀 리퀘스트는 쿠버네티스 API 서버에 OAuth 서버를 추가하려는 시도였습니다. 이 PR은 작업 진행 중 상태를 벗어나지 못했습니다. 결국 저는 다른 프로젝트에서 핵심 쿠버네티스 API 서버 위에 계층화하는 다른 접근 방식을 택했고(스포일러 경고: 이것은 복선입니다), 6개월 후에 머지하지 않고 닫았습니다.
그 시작에 흔들리지 않고, 저는 계속 참여하여 쿠버네티스 인증 및 권한 부여 기능을 구축하는 데 도움을 주었고, v1beta3에서 v1과 같은 초기 베타 API부터 핵심 쿠버네티스 API의 정의 및 발전에 관여했습니다. 이러한 기여를 바탕으로 2016년에 API 리뷰어로 지정되었고, 2017년에는 API 승인자로 추가되었습니다.
현재 저는 SIG Architecture의 API 거버넌스 및 코드 조직 하위 프로젝트를 이끄는 데 도움을 주고 있으며, SIG Auth의 기술 리더입니다.
FM: 그렇다면 API 거버넌스 프로젝트에는 언제부터 구체적으로 참여하게 되셨나요?
JL: 2019년경입니다.
API 거버넌스의 목표와 범위
FM: 이 하위 프로젝트의 주요 목표와 개입 영역을 어떻게 설명하시겠습니까?
표면 영역에는 쿠버네티스가 가지고 있는 모든 다양한 API가 포함되며, 사람들이 항상 API라고 인식하지 못하는 API도 있습니다: 명령줄 플래그, 구성 파일, 바이너리가 실행되는 방식, 컨테이너 런타임과 같은 백엔드 구성 요소와 통신하는 방식, 그리고 데이터가 지속되는 방식 등이요. 사람들은 종종 "API"를 REST API로만 생각합니다... 그것이 가장 크고 명백하며 가장 많은 사용자를 가진 API이지만, 이 모든 다른 표면들도 API입니다. 이들의 사용자층은 더 좁기 때문에 더 많은 유연성이 있지만, 여전히 고려가 필요합니다.
목표는 혁신을 가능하게 하면서도 안정성을 유지하는 것입니다. 아무것도 변경하지 않으면 안정성은 쉽지만, 이는 진화와 성장의 목표와 상충됩니다. 따라서 우리는 "안정성 유지"와 "변화 허용" 사이에서 균형을 맞춥니다.
FM: 변화에 대해 말씀드리자면, 일관성과 품질을 보장하는 측면에서 (이는 분명 이 프로젝트가 존재하는 이유 중 하나입니다), 쿠버네티스 변경의 수명 주기에서 특정 품질 게이트는 무엇인가요? API 거버넌스는 릴리스 주기 중, 가이드라인을 통한 사전 단계, 또는 그 중간 어느 시점에 관여하나요? 어떤 시점에서 의도된 역할이 충족되도록 보장하나요?
JL: 우리는 일반적인 API와 API 변경 방법에 대한 가이드라인 및 규칙을 가지고 있습니다. 이들은 새로운 시나리오에 직면할 때마다 업데이트하는 살아있는 문서입니다. 길고 내용이 많기 때문에, 설계 단계 또는 구현 단계에서 참여하여 이를 지원합니다.
때로는 대역폭 제약으로 인해 팀이 API 검토 피드백 없이 설계 작업을 진행하기도 합니다. 괜찮지만, 이는 구현이 시작될 때 API 검토가 진행되며 상당한 피드백이 있을 수 있음을 의미합니다. 따라서 우리는 새로운 API가 생성되거나 기존 API가 변경될 때, 설계 또는 구현 단계에서 관여합니다.
FM: 이것이 쿠버네티스 개선 제안(KEP) 프로세스 중에 이루어지나요? KEP가 개선을 위한 필수 사항이므로, 작업의 일부가 API 거버넌스와 교차한다고 가정해도 될까요?
JL: 그럴 수 있습니다. KEP는 얼마나 상세한지에 따라 다릅니다. 일부는 문자 그대로의 API 정의를 포함하기도 합니다. 그럴 경우, 우리는 설계 단계에서 API 검토를 수행할 수 있습니다. 그러면 구현은 설계에 대한 충실도를 확인하는 문제가 됩니다.
일찍 참여하는 것이 이상적입니다. 그러나 일부 KEP는 개념적이며 세부 사항은 구현에 맡깁니다. 그것이 잘못된 것은 아니지만, 구현이 더 탐색적일 것임을 의미합니다. 그러면 API 검토는 나중에 개입하여 구조적 변경을 권고할 수 있습니다.
어쨌든 절충점이 있습니다: 사전에 상세한 설계를 할 것인가, 아니면 구현 중에 반복적인 발견을 할 것인가. 사람과 팀은 다르게 일하며, 우리는 유연하게 초기 또는 구현 시점에 상담할 수 있습니다.
FM: 이 말씀은 Fred Brooks가 "미신적인 맨먼스(The Mythical Man-Month)"에서 개념적 무결성이 제품 품질의 핵심이라고 썼던 것을 떠올리게 합니다... 프로세스를 어떻게 구성하든, 누군가가 들어오는 것을 보고 개념적 무결성을 보장하는 지점이 있어야 합니다. 쿠버네티스는 외부 및 내부적으로 API를 모든 곳에서 사용하므로, API 거버넌스는 그러한 무결성을 유지하는 데 매우 중요합니다. 이것은 어떻게 포착되나요?
JL: 네, 규칙 문서에는 우리가 시간이 지남에 따라 학습한 패턴들이 담겨 있습니다: 다양한 상황에서 무엇을 해야 하는지 말이죠. 또한 spec/status 의미론과 같은 패턴 주변의 정확성을 보장하기 위해 자동화된 린터와 검사 도구도 있습니다. 이러한 자동화된 도구는 사람이 놓칠 수 있는 문제까지 잡아내는 데 도움이 됩니다.
새로운 시나리오가 발생하면 (그리고 이는 끊임없이 발생합니다) 우리는 그것들을 어떻게 접근할지 고민하고 그 결과를 문서와 도구에 다시 통합합니다. 때로는 잘 작동하는 접근 방식에 정착하기까지 몇 번의 시도가 필요하기도 합니다.
FM: 맞습니다. 새로운 상호 작용이 있을 때마다 가이드라인이 개선되는군요.
JL: 맞습니다. 그리고 때로는 첫 번째 접근 방식이 틀린 것으로 판명되기도 합니다. 견고한 것에 도달하기까지 두세 번의 반복이 필요할 수 있습니다.
Custom Resource Definitions의 영향
FM: 귀하의 경험상 특별히 주목할 만하거나 복잡하거나 흥미로웠던 특정 변경 사항, 에피소드 또는 도메인이 있나요?
JL: 전환점은 Custom Resources였습니다. 그 전에는 모든 API를 우리가 직접 만들고 완전히 검토했습니다. 불일치는 있었지만, 모든 유형과 필드를 우리가 이해하고 통제했습니다.
Custom Resources가 등장했을 때, 누구든지 무엇이든 정의할 수 있었습니다. 첫 번째 버전은 스키마조차 요구하지 않았습니다. 이는 즉시 변화를 가능하게 하여 매우 강력했지만, 안정성과 일관성 측면에서 우리가 따라잡아야 할 과제를 남겼습니다.
Custom Resources가 General Availability (GA)로 승격되었을 때, 스키마가 필수가 되었지만, 하위 호환성을 위한 탈출구는 여전히 존재했습니다. 그 이후로 우리는 CRD 작성자에게 내장 API와 유사한 유효성 검사 기능을 제공하기 위해 노력해왔습니다. CRD를 위한 내장 유효성 검사 규칙은 최근 몇몇 릴리스에서야 GA에 도달했습니다.
따라서 CRD는 '무엇이든 가능한' 시대를 열었습니다. 내장 유효성 검사 규칙은 일관성을 되찾게 한 두 번째 주요 이정표입니다.
세 가지 주요 주제는 스키마 정의, 데이터 유효성 검사, 그리고 기존의 유효하지 않은 데이터 처리였습니다. 래칫(ratcheting) 유효성 검사(기존 객체를 손상시키지 않으면서 데이터를 개선할 수 있도록 허용)를 통해 우리는 이제 CRD 작성자가 세상을 망가뜨리지 않고 규칙을 따르도록 안내할 수 있습니다.
API 거버넌스의 맥락
FM: API 거버넌스는 SIG Architecture 및 API Machinery와 어떤 관련이 있나요?
JL: API Machinery는 사람들이 API를 구축하는 데 사용하는 실제 코드와 도구를 제공합니다. 이들은 스토리지, 네트워킹, 스케줄링 등의 API를 검토하지 않습니다.
SIG Architecture는 전체 시스템 방향을 설정하고 API Machinery와 협력하여 시스템이 그 방향을 지원하도록 합니다. API 거버넌스는 그 기반 위에서 구축하는 다른 SIG들과 협력하여 규칙과 패턴을 정의하고, API Machinery가 제공하는 것을 일관되게 사용하도록 보장합니다.
FM: 감사합니다. 덕분에 흐름이 명확해졌습니다. 다시 릴리스 주기로 돌아가서: 릴리스 단계, 즉 개선 사항 동결(enhancements freeze), 코드 동결(code freeze)이 작업량에 변화를 주나요? 아니면 API 거버넌스는 대부분 지속적으로 이루어지나요?
JL: 우리는 두 가지 영역, 즉 설계와 구현에 관여합니다. 개선 사항 동결 전에 설계 참여가 증가하고, 코드 동결 전에 구현 참여가 증가합니다. 그러나 많은 노력이 여러 릴리스에 걸쳐 진행되므로, 미래 릴리스를 목표로 하는 작업이라 할지라도 항상 일부 설계와 구현이 이루어지고 있습니다. 그러한 집중적인 기간 사이에는 장기적인 설계 작업을 할 시간을 갖곤 합니다.
우리가 보는 안티 패턴은 팀이 몇 달 동안 큰 기능을 고민하다가 개선 사항 동결 3주 전에 '여기 설계가 있으니 검토해 주세요'라고 말하며 제시하는 것입니다. API에 영향을 미치는 큰 변경 사항의 경우, API 거버넌스를 일찍 참여시키는 것이 훨씬 좋습니다.
그리고 주기에 좋은 시기가 있습니다. 동결 기간 사이에 사람들이 대역폭을 가질 때죠. 그때가 장기적인 검토 작업에 가장 적합한 때입니다.
참여하기
FM: 명확하네요. 이제 팀 역학과 새로운 기여자들에 대해 질문입니다. 누군가가 API 거버넌스에 어떻게 참여할 수 있을까요? 무엇에 집중해야 할까요?
JL: 한꺼번에 모든 것을 배우려 하기보다는 특정 변경 사항을 따라가는 것이 보통 가장 좋습니다. 다른 사람이 만들고 있거나 본인이 만들고 싶은 작은 API 변경 사항을 선택하여 설계, 구현, 검토의 전체 프로세스를 관찰해 보세요.
높은 대역폭을 사용하는 검토, 즉 화상 통화를 통한 실시간 논의는 종종 매우 효과적입니다. 변경 사항을 만들거나 따라가고 있다면, 설계나 PR을 함께 검토할 시간이 있는지 물어보세요. 그러한 논의를 관찰하는 것은 매우 교육적입니다.
작은 변경 사항부터 시작하세요. 그런 다음 더 큰 것으로 이동하고, 어쩌면 새로운 API로 나아가세요. 그렇게 하면 실제 적용되는 규칙에 대한 이해가 쌓입니다.
FM: 훌륭합니다. 마지막으로 하고 싶은 말씀이나 빠진 부분이 있나요?
JL: 네... 우리가 호환성과 안정성에 그렇게 많은 관심을 기울이는 이유는 사용자들을 위해서입니다. 기여자들에게는 그러한 요구 사항이 정리 작업을 방해하거나 지루한 작업을 필요로 하는 고통스러운 장애물로 보일 수 있습니다... 하지만 사용자들은 우리 시스템과 통합되어 있으며, 우리는 그들에게 약속했습니다. 우리는 그들이 우리가 그 계약을 깨뜨리지 않을 것이라고 믿기를 바랍니다. 그래서 더 많은 작업이 필요하고, 더 느리게 진행되거나, 중복이 발생하더라도 우리는 안정성을 선택합니다.
우리는 방해가 되려 하는 것이 아닙니다. 우리는 사용자들의 삶을 좋게 만들려고 노력하는 것입니다.
우리의 많은 질문은 미래에 초점을 맞춥니다. 지금 무언가를 하고 싶다면... 나중에 그것을 깨뜨리지 않고 어떻게 발전시킬 것인가? 우리는 미래에 더 많은 것을 알게 될 것이라고 가정하며, 설계가 그것을 위한 여지를 남겨두기를 바랍니다.
우리는 또한 실수를 할 것이라고 가정합니다. 그렇다면 질문은 이겁니다: 호환성 약속을 지키면서도 개선할 수 있는 길을 어떻게 남겨둘 것인가?
FM: 맞습니다. Jordan, 감사합니다. 모든 것을 다 다룬 것 같습니다. 이번 인터뷰는 API 거버넌스 프로젝트와 더 넓은 쿠버네티스 프로젝트에서의 역할에 대한 통찰력 있는 견해였습니다.
JL: 감사합니다.