“오픈소스에선 커뮤니티 직책이 우선” 레드햇 직원에게 듣는 쿠버네티스 커뮤니티의 문화

오픈소스에서 정체성이 중요하지만, 일반적으로 생각하는 방식과는 다를 수 있다. 예를 들어, 릴리 코식은 레드햇에서 일하지만 쿠버네티스 커뮤니티 내에서 kube-state-metrics를 담당하는 유지관리자이기도 하다. 레드햇은 코식의 쿠버네티스 작업을 독려할 뿐, 코식의 개입에 대해 가타부타 통제하지 않는다. 오픈소스는 회사와는 별개의 개인적인 부분이기 때문이다. 코식은 이런 상황을 인터뷰에서 “회사의 직책과 유지관리자의 직책을 둘 다 가지고 있는 셈이지만, 두 역할을 항상 구분하는 것이 좋다”고 설명했다.

코식이 오픈소스에 참여한 시점은 13살 무렵이다. 부모님이 사준 컴퓨터로 스크립트나 웹페이지 등의 소소한 것들을 개발하기 시작했는데, 코식의 코딩은 거기서 멈추지 않았다. 코식이 쿠버네티스 유지관리자가 된 과정과 그것이 레드햇에서의 일과 어떻게 관련되는지 알아보자.

오픈소스 기여의 핵심은 일관성

코식의 첫 오픈소스 기여에는 딱히 특별한 점은 없었다. 코식은 오픈소스 경험의 첫 걸음은 오자였다면서, “도커 ReadMe 문서에 오자를 수정하려고 풀 요청을 열었다. 대부분이 같은 경험을 했을 것이라고 생각한다. 대부분 어디선가 오자를 하나 발견하는 것부터 시작한다”고 말했다. 참여해서 프로젝트를 개선할 수 있다는 사실에 고무된 코식은 그 이후 더욱 적극적으로 기여에 나섰다. 

코식의 기여는 쿠버네티스나 다른 프로젝트의 주요 기능은 아니었다. 사실 코식의 말에 따르면, 주요 기능 기여는 이상적인 기여 방법은 아니다. 다음은 코식의 설명이다. 

일관성이 핵심이다. 기여하는 코드가 많든 적든 꾸준히, 일정하게 기여하는 것이 중요하다. 보통 최소한 몇 개월 동안은 꾸준히 기여해야 한다. 여기에는 풀 요청 검토, 깃허브 이슈나 메일링 리스트, 또는 슬랙 emd의 질문에 답하기 등이 포함된다. 여러 개의 작은 조각을 기여해서 전체 코드 베이스를 익혀 나가는 것이 좋다. 큰 기능 하나만 기여하면 전체 코드 베이스를 알 수 없다. 해당 기능의 유지관리 담당자가 될 수 있지만, 전체 프로젝트의 유지관리 담당자는 될 수 없다.

코식의 기여에 대한 관심은 커뮤니티에 대한 쿠버네티스의 접근 방식과도 잘 맞아떨어졌다.

쿠버네티스 커뮤니티가 제대로 하는 것

쿠버네티스는 많은 면에서 다르다. 리눅스는 종종 커뮤니티 분위기가 살벌한 것으로 알려져 있는데, 코식은 쿠버네티스의 분위기가 온화하다고 표현한다. “완벽하지는 않지만, 쿠버네티스 커뮤니티는 분위기가 좋은 오픈소스 커뮤니티 중 하나”라고 말했다.

이유를 묻자 코식은 구글을 언급하며 “구글 서머 오브 코드(Google Summer of Code: GSoC)의 멘티 중 여성이 많았다는 사실과 관계된 것 같다. 예를 들어, 현재 쿠버네티스 운영 위원회의 일원인 니키타[Rahunath]는 2017년 GSoC에 참가했다. 물론, 비율로 치면 아직 많지 않지만 고무적인 현상”이라고 말했다.

코식은 이어 쿠버네티스의 한 가지 이점은 지키거나 극복해야 할 역사가 있는 확립된 프로젝트가 아니라, 처음부터 새로 시작할 수 있었던 점이라고 말했다. 코식은 쿠버네티스 커뮤니티는 의도적으로 다양성을 포용한다면서 “CNCF에는 오로지 기여 환경을 개선하기 위한 목적의 팀이 따로 있다. 이들은 새로운 사람을 따뜻하게 포용하기 위해 많은 공을 들인다”고 말했다.

어느 정도의 ‘가면 증후군’을 느끼는 것은 정서적으로 건강하지만, 기술 업계에서 상대적으로 목소리가 작은 그룹에 속한다면, 이 느낌을 극복하기가 더 어려울 수 있다. 코식은 “환대하는 분위기를 형성하면 장기적으로는 더 다양한 기여자를 확보할 수 있고, 결과적으로 더 좋은 소프트웨어를 만들 수 있게 된다”고 말했다.

두 역할의 충돌

그러나 이러한 다양성은 개발자에게 급여를 지급하는 기업과는 아무런 상관이 없다. 프로젝트 내에서 인정되는 것은 개발자들 자신이다. 예를 들어, IBM에서 일하는 엔지니어라면, IBM을 위해 이곳저곳에 코드를 기여할 것이라고 생각하기 쉽다. IBM이 주도적인 역할을 하는 프로젝트에서는 그럴 수도 있지만, 오픈소스 전반적으로 보면 틀린 생각이다. 예를 들어, 아파치 소프트웨어 재단(Apache Software Foundation, 이하 ASF)은 이 점에서 매우 분명한 입장을 취한다. “우리는 역할을 확고하게 믿는다. ASF에서 여러분의 역할은 동료들이 여러분 개인에게 부여한 것이다. 여러분의 직업이나 현재 소속된 회사와는 관계가 없다.”

코식 역시 레드햇 오픈시프트에서의 직책이 쿠버네티스 작업에 어떻게 영향을 미치는지에 대한 질문에 “항상 두 가지 역할을 맡는다. 항상 회사 직원 역할과 유지관리자의 역할을 분리해야 한다. 항상 프로젝트의 이익을 위해 행동해야 한다”고 말했다.

그러나 kube-state-metrics에서의 역할은 확실히 레드햇에 유리하게 프로젝트를 변경할 수 있는 위치다. 이에 대해 코식은 다음과 같이 말했다.

유지관리자가 꼭 기능 작업을 하는 사람은 아니다. 유지관리자는 프로젝트의 상태를 건강하게 유지하는 역할을 한다. 내가 기능 측면에서 결정해야 하는 경우, 레드햇 관점에서 하지 않는다. “이것이 프로젝트의 목적에 부합하는가”를 생각한다. 최근 레드햇 중 한 명이 기능을 열었는데, 그 기능은 kube-state-metircs의 목적과 맞지 않아 거부했다. 그 기준을 지켜야 한다. 이 프로젝트는 레드햇 프로젝트가 아니라 커뮤니티를 위한 프로젝트다. 레드햇에서의 직책에 따라 내가 유지 관리하는 프로젝트가 정해지는 것이 아니다. 다만 내가 일할 수 있는 시간만 정해질 뿐이다. 레드햇에서 누군가 ‘kube-state-metrics에서 이 기능을 원한다’고 말할 때마다 나는 레드햇 직원이 아닌 유지관리자의 역할로 대응한다.
    
코식은 다른 두 kube-state-metrics 유지관리자와의 회의에서 2.0 릴리스에서 어느 벤더가 무엇을 원하는지에 대해서는 대화를 나누지 않았다. 이들은 기술 부채 없애기, 수집할 데이터의 종류 확인 등 유지관리 편의성 측면에서 프로젝트의 진전을 위해 무엇이 필요한지만 토론했다. 

오픈소스는 이렇게 움직인다. 개인이 커뮤니티에 속해 협력해서 좋은 소프트웨어를 만든다. 코식과 쿠버네티스 커뮤니티를 보면 오픈소스가 주장하는 방식대로 잘 운영되는 것으로 보인다.

[출처] IT World (http://www.itworld.co.kr/insight/159799)