Namsang Labs
Field Notes · #open-source #opentelemetry #flink #governance

오픈소스에도 투표가 있다

· Sangkyoon Nam

밤 책상 앞에 앉은 캐릭터. 노트북에 OpenTelemetry 거버넌스 위원회 투표 화면이 떠 있고 책상에 VOTE라고 적힌 카드 세 장이 놓여 있다

오픈소스에 본격적으로 참여한 건 올해 하반기부터다. 오래되지는 않았지만 관심 있는 분야가 분명해서 꽤 열심히 이슈를 읽고 PR을 냈다. 그러던 중 10월에는 OpenTelemetry 거버넌스 위원회 선거에 투표하라는 메일을 받았다. 회사도 나라도 아닌 오픈소스 프로젝트에 선거가 있다는 것도, 기여를 시작한 지 얼마 안 됐어도 꾸준히 활동한 덕에 내게도 표가 생겼다는 것도 그때 처음 알았다.

OpenTelemetry 커뮤니티 저장소의 선거 안내 이슈에 달린 댓글이 메일로 온 화면. 지난 1년 동안 GitHub에서 20건 넘게 기여한 사람들을 투표에 초대한다는 문장 아래 내 아이디가 다른 기여자들 사이에 있다

10월 22일에 받은 투표 초대 메일. 지난 1년 동안 GitHub에서 댓글과 코드 리뷰, PR 등으로 20건 넘게 기여한 사람들을 부른다고 적혀 있다.

찾아보니 오픈소스에는 투표가 생각보다 많았고, 10월 한 달 동안 세 종류를 만났다. 새 커미터를 뽑는 투표와 릴리스를 정식으로 낼지 묻는 투표, 프로젝트 운영을 맡길 사람을 고르는 선거다. 이 가운데 커미터 투표는 결과 공지로만 봤고, 나머지 두 투표에는 직접 표를 던졌다. 거버넌스 위원회 선거는 이번에 처음 투표해 봤다.

#커미터를 정하는 투표

Flink 같은 Apache 재단의 프로젝트에서 커미터는 코드를 직접 병합할 권한을 가진 사람이고, 누가 커미터가 될지도 투표로 정한다. 다만 이 투표는 밖에서 보이지 않는다. Flink 규약으로는 프로젝트 관리 위원회(PMC)가 비공개 메일링 리스트에서 3일 이상 투표한다. 활동 중인 PMC 위원의 찬성이 세 표 이상이고, 이들 가운데 타당한 이유를 갖춘 반대가 한 표도 없어야 통과한다. 그런 반대라면 한 표만으로도 거부권이 되는 셈이다.

밖에서 보이는 건 결과뿐이다. 10월 21일에 Flink 개발자 메일링 리스트로 새 커미터를 알리는 [ANNOUNCE] 메일이 왔고, 사람들이 축하 답장을 이어 붙였다. 나도 앞선 답장들의 형식을 보고 짧은 축하와 이름을 적어 보냈다.

Flink 개발자 메일링 리스트의 새 커미터 공지 스레드. PMC를 대표해 Ramin Gharib가 커미터 초대를 수락했다는 소식을 알리는 첫 메일 아래 축하 답장이 이어지고, 맨 아래에 내가 보낸 짧은 축하 답장이 있다

10월 21일에 온 새 커미터 공지와 다음 날 새벽 내가 보낸 축하 답장.

#릴리스를 결정하는 투표

릴리스를 낼지 묻는 투표는 공개된 곳에서 열린다. 릴리스 담당자가 정식 배포 전에 검증할 배포본인 후보판을 올리고 개발자 메일링 리스트에 제목이 [VOTE]로 시작하는 메일을 보내면, 사람들이 후보판을 직접 받아 확인한 뒤 +1이나 -1로 답한다. Flink 규약으로는 투표를 3일 이상 열어 두는데, 통과 여부를 따질 때 세는 표는 활동 중인 PMC 위원의 표뿐이고 이를 binding 표라고 부른다. binding 찬성이 세 표 이상이고 binding 반대보다 많아야 통과하며, 그 밖의 사람도 검증 결과를 남기며 표를 던질 수 있다.

10월 21일에는 Flink Agents 0.4 릴리스를 앞두고 점검하다가, JDK 17로 빌드한 배포본에서 Java 쪽 채팅 호출이 실패하는 문제를 찾아 고쳤다. 27일에는 첫 후보판의 서명과 체크섬을 확인하고 소스가 태그와 같은지 비교한 뒤 직접 빌드해 봤는데, 그때 내가 고친 부분에 필요한 클래스가 배포 파일에 들어 있는지도 같이 봤다. 그런데 28일에 보니 정작 투표 메일은 스팸함에 들어가 있었다.

답장에는 통과 여부에 세지 않는 non-binding 표라고 밝힌 +1과 함께 확인한 항목을 적고, 처음부터 끝까지 돌려 보는 기능 테스트는 하지 않았다는 것도 밝혔다. 이전 버전에서 넘어올 때 진행 중이던 작업의 상태가 복원되지 않는 경우도 찾았지만, 이번 버전에서 새로 생긴 문제가 아니어서 릴리스를 막을 사안으로 올리지는 않았다. 업그레이드 안내에 한 줄을 더하자고 제안하면서 다음 버전에서 내가 고쳐 보겠다고 적었다.

투표는 반대 없이 통과했다. 결과 메일에는 찬성 일곱 표 가운데 binding 네 표가 적혀 있었고, 내 이름은 non-binding 쪽에 올라 있었다.

Flink Agents 0.4.0 첫 후보판의 투표 결과 메일. 찬성 일곱 표 중 binding이 넷이고 반대는 없다는 문장 아래 투표자 이름이 binding과 non-binding으로 나뉘어 있다

10월 29일에 받은 Flink Agents 0.4.0 첫 후보판의 투표 결과 메일.

#거버넌스 위원을 뽑는 투표

OpenTelemetry의 거버넌스 위원회는 새 프로젝트 제안을 검토해 우선순위를 정하고 공개 로드맵을 관리하는 기구이고, 이 위원을 뽑는 투표는 셋 중 가장 선거다웠다. 투표권도 내가 따로 신청해서 받은 것이 아니었다. 지난 1년 동안 OpenTelemetry 조직의 GitHub에 남긴 기여가 PR에 이슈와 코멘트까지 합쳐 20건 이상이면 투표권이 생긴다. 담당 영역의 기여를 검토하고 승인하는 approver와 하위 프로젝트의 기술 방향을 정하는 메인테이너도 투표권이 있다. 명단은 자동으로 집계되며, 기준에 들지 않는 기여자는 예외를 신청할 수 있다.

10월 21일에 반영된 공개 투표권자 명단에는 계정 837개가 적혀 있었고, 그 안에 내 아이디도 있었다. 내 아이디 옆에 집계된 기여는 29건이었다.

후보 열 명은 모두 스스로 이름을 올렸다. 자천만으로 후보가 되는 것은 아니어서 다른 두 회사의 투표권자에게 지지 코멘트를 받아야 했고, 한 회사 사람이 위원회를 채우지 못하게 하는 상한도 있었다. 선거 기간에는 후보 한 명에게서 의견을 묻는 메시지를 직접 받기도 했다.

Helios 투표 시스템의 OpenTelemetry 거버넌스 위원회 선거 페이지. 투표 시작과 마감 시각, 투표하기 버튼이 보인다

투표는 Helios라는 온라인 투표 시스템에서 한국 시각으로 10월 26일 밤 9시부터 29일 밤 8시 59분까지 열렸다.

네 자리를 채울 후보를 최대 네 명까지 고를 수 있었고, 나는 마감 몇 시간 전까지 열 편의 공약을 모두 읽었다. 거버넌스라고 해서 규칙과 투표 정도를 떠올렸는데, 공약이 다루는 범위는 설치 패키지와 데모 앱부터 모더레이션 정책과 행사, 이웃 프로젝트와의 관계까지 훨씬 넓었다.

먼저 눈에 띈 건 AI였다. 내가 세어 보니 소개와 공약에서 AI나 에이전트를 언급한 후보가 열 명 중 여섯이었고, 메인테이너의 시간을 지키겠다는 약속은 내 기준으로 다섯 명의 공약에 들어 있었다. 엔드유저의 도입을 돕겠다는 공약도 여러 편이었는데, 미국 적십자에서 일하는 후보는 미국 혈액 공급의 40% 정도를 맡는 혈액 사업에 OpenTelemetry가 핵심 구성 요소로 들어가 있다고 소개했다.

가장 오래 남은 건 리뷰 이야기였다. 한 후보는 자기가 이끄는 그룹의 월간 PR이 올여름 네 배 가까이 늘어 리뷰가 따라가지 못했다고 적었고, 메인테이너 번아웃을 첫 줄에 둔 후보는 공용 도구와 자동 점검으로 반복 업무를 줄이자고 했다.

#투표를 마치고

OpenTelemetry 거버넌스 위원회 선거의 공식 결과 글은 미국 날짜로 29일에 올라왔고, 나는 한국 시각으로 30일 아침에 확인했다. 투표권자의 41%가 표를 냈고, 득표 상위 네 명이 새 임기를 맡게 됐다. 그렇다고 표를 많이 받은 순서대로 무조건 뽑히는 것은 아니다. 헌장은 같은 회사 소속 위원을 동시에 두 명까지로 제한하고, 이 한도는 임기가 남은 위원까지 합쳐 센다. 한도를 넘는 후보는 득표가 높아도 건너뛰고 다음 순위 후보가 자리를 잇는다. 이번에는 상위 네 명의 회사가 서로 달랐고 임기가 2027년까지 남은 위원들의 회사와도 겹치지 않아, 득표순 그대로 정해졌다.

누가 뽑혔는지와 별개로, 공약에 나온 리뷰 이야기는 요즘 여러 오픈소스 프로젝트가 함께 겪는 현실이기도 하다. 올해 6월 Kubernetes 블로그에 실린 글도 AI로 코드를 만드는 일은 빨라졌지만 코드베이스를 유지하는 일은 거의 나아지지 않았다고 짚었다. OpenTelemetry에서도 PR이 늘어나는 속도를 리뷰가 따라가지 못한다고 적은 후보가 있었고, 프로젝트의 생성형 AI 정책은 메인테이너와 approver의 시간을 몹시 부족한 자원이라고 적는다. 그렇다고 AI를 쓰지 말라는 정책은 아니다. 잘 쓰면 코드와 문서, 테스트를 쓰는 데 유용한 도구라고 하면서, 모델이 만든 내용만 옮기기보다 영어가 완벽하지 않더라도 기여자 자신의 생각을 들려 달라고 한다.

실제로 나도 AI의 도움을 받아 기여한다. 영어로 이슈를 쓰고 처음 보는 큰 코드를 읽는 일을 AI가 많이 덜어 준다. PR을 올릴 때는 무엇을 직접 돌려 봤고 무엇은 확인하지 못했는지를 본문에 적는데, 릴리스 투표 답장에 확인한 항목과 하지 않은 항목을 나눠 적은 것도 같은 습관이다. 공약들을 읽고 나니 이 습관이 오픈소스에서는 더 중요하다는 생각이 든다. 회사에서는 리뷰어와 맥락을 나누고 옆자리에서 물어볼 수 있지만, 오픈소스의 리뷰어는 처음 보는 사람의 PR을 자기 시간을 내어 읽는다. 그래서 코드와 PR 설명만으로 변경 의도를 이해할 수 있도록, 처음부터 리뷰하는 사람을 위해 써야 한다.

#참고 자료

Share this post