[메인터뷰] 는 매주 월요일마다 찾아오는 오픈소스 빌더 인터뷰입니다. 클라우드브로 커뮤니티가 기록하는 여덟 번째 이야기입니다.
“개발 생태계에 기여하는 엔지니어가 되고 싶습니다.”
최재우 님이 면접 자리에서 늘 하던 말입니다. 본인 표현으로는 면접 때마다 습관처럼 하던 말이었습니다. 그런데 같은 말을 반복하다 보니 어느 순간 그 말이 진짜가 되어야 할 것 같았고, 실제로 진짜가 됐습니다. 지금 그는 쿠버네티스 배포의 사실상 표준인 Argo CD의 메인테이너(리뷰어)입니다. 올해 2월에 선임됐고, 한국에서 이 자리에 있는 사람은 손에 꼽습니다.
문서 오타에서 크래시 버그까지
시작은 아주 작았습니다. 문서의 오타를 고치는 수준의 기여였습니다. 그 작은 수정이 리뷰를 받고 병합되는 과정 자체가 재미있었다고 했습니다.
본격적인 계기는 이전 직장에서 왔습니다. Argo CD로 배포를 운영하다 로그를 확인할 때 크래시가 나는 문제를 만났습니다. 코드베이스를 뒤져보니 이미 고쳐져 있었습니다. 버전을 올리면 해결될 일이었지만, 코드를 들여다본 김에 생각이 하나 더 따라왔습니다.
“나도 다른 거 고쳐볼까.”
여기에 무료로 받아 쓴 것을 돌려준다는 마음이 더해졌습니다. 불편함을 해결하는 일을 넘어, 도움받은 만큼 갚는 선순환으로 기여를 이해하게 됐다는 것입니다.
기여 열 개를 쌓고, 직접 슬랙 DM을 보냈다
Argo CD는 기여자의 신뢰도에 따라 역할을 나눕니다. 컨트리뷰터에서 멤버가 되고, 그 위의 메인테이너 그룹은 리뷰어, 어프루버(Approver), 프로젝트 리드로 세분화됩니다. 리뷰어가 메인테이너의 첫 단계입니다.
멤버가 되려면 기존 리드나 어프루버의 스폰서십이 필요합니다. 최재우 님은 기여를 열 개쯤 쌓은 뒤, 직접 슬랙 DM으로 스폰서십을 요청했습니다. 그렇게 멤버가 되는 데 약 3개월. 놀라운 건 그다음이었습니다. 다시 3개월쯤 지났을 때, Argo CD 프로젝트 리드가 먼저 연락해 리뷰어 승격 신청을 권했습니다. 본인이 요청한 게 아니었습니다.
“어떤 트리거보다 계속 꾸준하게 하면, 프로젝트 리드나 어프루버들이 좋게 봐주고 먼저 연락이 오는 것 같아요.”
큰 기여 한 번이 아니라 매주 한두 개씩의 작은 기여가 신뢰를 쌓았다는 이야기입니다.
외국인 메인테이너들 사이에서 친분도 기여도도 부족하다고 스스로 생각했지만, 중요한 PR의 리뷰를 요청받을 때마다 신뢰가 쌓였음을 체감한다고 했습니다.
수천 개의 애플리케이션을 돌려본 사람의 리뷰
최재우 님은 여러 회사를 거치며 배포 인프라를 운영해 왔고, 지금도 Argo CD를 비롯한 DevOps 도구들을 관리합니다. 수천 개의 애플리케이션이 돌아가는 환경입니다. 이 운영 경험이 리뷰어의 자리에서 어떻게 작동하는지 물었습니다.
답은 예상을 비껴갔습니다. 운영 경험은 이상한 PR을 걸러내는 눈이라기보다, 필요한 PR을 알아보고 밀어주는 눈에 가까웠습니다. 수천 개의 애플리케이션을 관리하면 UI 렌더링이 눈에 띄게 느려지는데, 그 고통을 아는 사람에게는 어떤 PR이 급한지가 보입니다. 카카오 플랫폼 팀이 올린 RBAC 패턴 캐싱으로 로딩 속도를 개선하는 PR, 서버 응답 패키지 데이터를 줄이는 외부 컨트리뷰터의 PR. 그는 이런 성능 개선 기여들이 빨리 병합되기를 바라며 적극적으로 리뷰에 참여했습니다.
사용자와 메인테이너의 시각 차이도 여기서 나옵니다. 사용자는 자기 조직의 운영 방식 안에 갇혀 편협해지기 쉽습니다. 메인테이너는 이 변경이 프로젝트의 방향과 맞는지, 전체 사용자에게 도움이 되는지를 먼저 봅니다.
리뷰에서 확인하는 것은 세 가지라고 했습니다. 제보된 이슈가 실제로 재현되는가. 해결 방향이 타당한가, 그러니까 기능을 제거할 일인지 임시로 우회할 일인지 근본적으로 고칠 일인지. 그리고 엣지 케이스를 빠뜨리지 않았는가.
의견을 내는 방식은 조심스러웠습니다. 단정적인 승인보다 좋아 보인다는 정도의 유보적인 표현을 선호하고, 동의하지 않을 때는 코멘트로 반대 의견을 남기되 다른 메인테이너들이 동의하면 따릅니다. 직설적으로 거절하고 대화를 끝내는 메인테이너도, 성능 데이터를 더 가져오라는 메인테이너도 있다며, 성향의 차이로 받아들이고 있었습니다.
AI는 코드를 고치고, 사람은 맥락을 본다
리뷰어의 자리에서 그는 AI의 쓸모와 한계를 동시에 봅니다. 코드를 변경하는 일 자체는 AI가 잘합니다. 문제는 그다음입니다.
오픈소스는 단순한 코드베이스가 아니라 하나의 커뮤니티입니다. Argo CD는 7년 된 프로젝트라 레거시 코드는 물론, 그 위에 켜켜이 쌓인 의사결정 구조도 복잡하게 얽혀 있습니다. AI가 제안한 수정이 의도한 엣지 케이스를 다 덮지 못하는 일이 생기고, 예전 슬랙 대화나 오래된 GitHub 이슈에서 이미 논의되고 정해진 방향성을 AI가 놓치는 경우도 있습니다. 언젠가는 AI가 이런 맥락까지 따라잡을 수도 있겠지만, 적어도 아직까지는 코드와 테스트만으로는 이런 맥락을 전부 커버할 수 없다는 것이 사람 리뷰가 남는 이유였습니다. 그래서 그는 자기 PR을 올릴 때도 스스로 엣지 케이스를 찾아 검증하고, 관련된 과거 논의까지 확인한 결과를 리뷰어와 공유합니다. 빨리 병합되게 하는 그만의 방법입니다.
이 주제로 그는 곧 무대에 섭니다. 8월 12일 오픈소스 서밋에서 LLM을 활용한 오픈소스 기여 방법을 발표합니다.
특정 툴이 표준이 되어서는 안 된다
여러 조직이 함께 쓰는 배포 플랫폼을 표준화하는 일에 대해 물었을 때, 그의 답은 뜻밖에 단호했습니다.
“특정 툴 하나를 표준으로 정의하는 것은 맞지 않다고 생각해요.”
조직마다 VM 배포가 필요한 곳이 있고, Argo CD가 불편한 환경이 있고, 보안 요건이 다릅니다. 도구 하나를 표준으로 강제하는 대신, 도구가 전체 파이프라인에 자연스럽게 녹아들게 하는 것이 표준이 되어야 한다는 입장입니다. 플랫폼 엔지니어링의 본질도 거기 있다고 봤습니다. 개발자가 CI/CD 내부의 도구를 몰라도 기능 개발과 릴리스에만 집중할 수 있는 환경을 만드는 일이라는 것입니다.
이전 직장에서의 경험이 그 생각을 뒷받침합니다. 저장소마다 파이프라인 설정이 흩어져 있어 하나를 고치려면 전부를 손대야 했던 환경을, 공통 템플릿을 상속하는 구조로 바꿨습니다. 공통 단계를 한 곳에서 수정하면 전체에 적용되는 구조가 되면서 운영 부담이 절반 가까이 줄었습니다.
회사보다 오픈소스가 더 투명했다
한국 오픈소스 생태계를 물었을 때 그의 진단은 앞선 인터뷰이들과 겹쳤습니다. 쓰는 것은 활발한데 기여는 소극적이고, 업무에서 얻은 지식을 개인 메모장에만 쌓아두는 폐쇄적인 문화가 있다는 것입니다.
흥미로운 건 그가 오픈소스를 권하는 이유였습니다. 회사에서는 의견을 내면 비공개 피드백이나 정치적인 요소가 끼어드는 경우가 많습니다. 오픈소스 커뮤니티는 반대입니다. 모든 논의가 GitHub 이슈와 PR에 공개되고, 누구나 의견을 낼 수 있고, 그 의견이 모두에게 평가받습니다. 반대 의견에 심리적 부담을 느끼는 일도 있지만, 그 소통 자체가 성장의 훈련이 된다고 봤습니다.
완벽한 해결책을 만든 뒤에만 공유해야 한다는 부담도 내려놓으라고 했습니다. 해결책을 찾기 전이라도 문제 상황 자체를 공유하는 것만으로 다른 사람에게 통찰을 줄 수 있다는 것입니다. 후배들에게 권하는 시작점도 같은 자리였습니다. 지금 쓰는 도구에서 불편함을 발견하면 PR을 올려 피드백을 받아보라는 것.
그를 계속 움직이게 하는 힘은 소박했습니다. 얼굴도 모르는 사용자가 남기는 감사 인사와 태그. 외부 활동을 줄곧 망설여 왔다고 스스로 말한 사람이, 그 피드백의 힘으로 무대 앞까지 나아갔습니다. 회사 밖 개인 환경에서도 K3s로 클러스터를 직접 꾸려 돌리고, Backstage 같은 플랫폼 엔지니어링 프로젝트를 눈여겨보고 있습니다. 특정 프로젝트에 묶이기보다, 도움받은 만큼 자기가 쓰는 도구에 돌려주는 방식으로 계속 가겠다고 했습니다.
리뷰어에게 물어본 것들
Argo CD 안쪽의 규칙이 궁금한 분들을 위해, 실무적인 답들을 따로 모았습니다.
1. Argo CD의 기여 단계는 어떻게 되나요
컨트리뷰터, 멤버, 그리고 메인테이너 그룹으로 나뉩니다. 메인테이너 그룹 안은 리뷰어, 어프루버(Approver), 프로젝트 리드로 세분화됩니다. 리뷰어가 메인테이너의 첫 단계입니다.
2. 승급은 어떻게 이뤄지나요
기존 리드나 어프루버의 스폰서십이 필요합니다. 최재우 님은 기여 약 10개를 쌓은 뒤 슬랙 DM으로 직접 멤버 스폰서십을 요청해 약 3개월 만에 멤버가 됐고, 다시 3개월쯤 뒤 프로젝트 리드가 먼저 연락해 리뷰어 승격을 권했습니다.
3. 리뷰에서는 무엇을 보나요
세 가지입니다. 이슈가 실제로 재현되는가, 해결 방향이 타당한가(제거, 우회, 근본 수정 중 무엇이 맞는가), 엣지 케이스를 커버하는가.
4. 거절은 어떻게 하나요
코멘트로 반대 의견을 남기되, 최종 판단은 어프루버 이상의 메인테이너들에게 맡깁니다. 직설적으로 거절하는 메인테이너도, 데이터를 더 요구하는 메인테이너도 있어 성향 차이가 큽니다.
5. 논의는 어디에서 이뤄지나요
GitHub 이슈와 PR 코멘트가 기본이고, 수천 명이 있는 슬랙 채널에 주요 주제가 공유됩니다. 매주 화상 컨트리뷰터 미팅도 열립니다. 다만 한국 시간으로 자정에서 새벽 1시 무렵이라, 그는 태그되거나 요청받을 때 참여하는 방식을 취합니다.
6. 영어는 얼마나 필요한가요
문서와 텍스트 중심이라 GitHub와 슬랙의 비동기 소통으로 대부분 해결됩니다. 미팅에서 아젠다를 직접 주도하기보다, 이슈에 해결 방향을 먼저 글로 제시하는 방식으로 협업합니다.
7. 메인테이너가 받는 것은 무엇인가요
보수는 없습니다. 대신 GitHub Copilot 무제한 라이선스, CNCF 컨퍼런스 지원, 프로젝트 이슈를 통합 관리하는 Jira 서비스 데스크 접근을 받습니다.
8. Argo CD는 누가 유지하나요
초기 개발팀의 스타트업을 인수한 Intuit에 전담 팀이 있고, Red Hat, Akuity, Octopus Deploy 등 기업 소속 메인테이너들이 핵심 기여를 맡습니다. 최재우 님처럼 소속 업무와 무관하게 개인으로 기여하는 메인테이너도 있습니다.
9. 기업이 Argo CD를 도입할 때는 무엇을 봐야 하나요
이 도구가 왜 필요한지부터 명확해야 합니다. 규모가 작거나 개발자가 직접 빌드와 배포를 하는 환경이라면 도입이 오히려 관리 부담이 될 수 있습니다. 기능보다 운영 주체와 거버넌스를 먼저 정하라는 것이 그의 답이었습니다.
매주 월요일마다 찾아오는 [메인터뷰] 의 여덟 번째 이야기는, 면접 때마다 하던 말을 진짜로 만든 한 엔지니어의 이야기로 채웠습니다.
[메인터뷰] 는 매주 월요일마다 찾아오는 오픈소스 빌더 인터뷰입니다. 다음 주 월요일, 또 다른 빌더로 찾아올게요!