[메인터뷰] 는 오픈소스를 하는 누구나 메인이 되는 인터뷰로, 클라우드브로 커뮤니티가 오픈소스 빌더들의 이야기를 기록하는 시리즈의 일곱 번째 편입니다.
이성진 님은 CNCF 인큐베이팅 프로젝트 Cortex의 메인테이너입니다. 한국에서 이 자리에 있는 사람을 찾기가 쉽지 않습니다. 무엇이 그를 메인테이너로 만들었느냐고 물었을 때, 돌아온 답은 담백했습니다.
“결정적인 포인트가 있다기보다는, 그냥 계속 PR을 많이 올렸어요.”
화려한 기능 하나로 올라선 게 아니라는 이야기였습니다. 실제로 그가 걸어온 길은 계단에 가까웠습니다.
메인테이너까지는 세 단계, 한 단계에 6개월
많은 사람이 오픈소스에는 기여자와 메인테이너 두 단계만 있다고 생각합니다. 그렇지 않습니다. CNCF 프로젝트 대부분은 그 사이를 여러 층으로 나눠 둡니다.
컨트리뷰터로 시작해, 활발히 활동하는 기여자를 뜻하는 트리아저(Triager)를 거쳐 메인테이너에 이릅니다. 프로젝트에 따라 단계를 더 세분화해 둔 곳도 있습니다.
“컨트리뷰터랑 메인테이너는 갭이 워낙 커서, 이렇게 세분화해 두는 것 같더라고요.”
이성진 님은 이 계단을 한 칸씩 올랐습니다. 한 단계에 대략 6개월이 걸렸습니다. 그렇게 작년에 메인테이너가 됐습니다.
메인테이너가 되면 권한과 함께 규칙이 따라옵니다. 일반 기여자의 PR은 메인테이너의 승인 두 개를 받아야 병합되지만, 메인테이너의 PR은 하나면 승인된 것으로 봅니다. 코드에 대한 책임의 무게가 자리마다 다르게 매겨져 있는 셈입니다.
4년을 쓰던 도구를 고치면서 기여가 시작됐다
시작은 거창하지 않았습니다. 회사에서 인프라의 메트릭을 모으는 데 Cortex를 쓰고 있었고, 그는 4년 넘게 그 코드베이스를 읽어왔습니다.
“쓰다 보니까 자연스럽게, 이건 진짜 필요한데 싶어서 PR을 몇 번 올렸어요. 그게 다 받아들여지니까, 아 이렇게 올리면 되는구나 싶어서 계속 올리게 됐죠.”
일하다 필요해진 기능을 만들려면 Cortex의 구조를 손봐야 했습니다. 그는 그 변경을 올리면서, 이 수정이 자기 회사만이 아니라 공개된 사용자 모두에게 도움이 된다는 점을 적극적으로 설명했습니다. 사내의 필요를 프로젝트의 필요로 번역한 것입니다. 그렇게 첫 기여가 받아들여졌습니다.
PR이 쌓이자 커뮤니티가 먼저 그를 알아봤습니다. 기존 메인테이너가 링크드인으로 연락을 해왔고, 슬랙으로 이어지며 자연스럽게 커뮤니티 안쪽으로 들어갔습니다.
여기서 그가 짚은 조건이 있습니다. 깊이 파고들려면 실제로 돌아가는 환경이 필요하다는 것입니다.
“프로덕션에서 트래픽을 받아봐야 안 보이던 이슈가 보이거든요. 개발 환경에서만 만졌으면 아마 한계가 있었을 거예요.”
오픈소스가 성장하려면 실제로 쓰는 사람이 있어야 하고, 그것도 무겁게 쓰는 사용자가 있어야 한다는 이야기이기도 했습니다.
회사 지원 없이 올린 100개의 PR
회사가 이 활동을 지원했느냐고 묻자 답은 짧았습니다.
“그런 건 진짜 전혀 없습니다.”
업무 시간 일부와 퇴근 후, 그리고 주말이 그의 시간이었습니다. 그렇게 1년 남짓 동안 100개가 넘는 PR을 올렸습니다. 보상은 없었습니다. 그가 아쉬워한 것도 이 대목이었습니다. 해외 기업들은 오픈소스 기여를 회사 차원에서 장려하고 이끄는 경우가 많은데, 한국에는 그런 회사를 찾기 어렵다는 것입니다.
“한국은 어떻게 보면 코드의 소비 국가라고 생각해요.”
쓰기는 많이 쓰는데 만드는 쪽으로는 잘 가지 않는다는 뜻이었습니다. 그가 아는 한, 일반적인 IT 회사에서 CNCF 프로젝트에 기여하는 사람은 좀처럼 보이지 않았습니다.
새벽 세 시의 회의, 그리고 물어볼 사람이 없다는 것
한국에서 글로벌 프로젝트의 메인테이너로 활동하는 데 걸림돌이 무엇이었는지 물었습니다. 시차와 언어, 그리고 물어볼 사람이 없다는 것. 그는 셋 다 해당된다고 했습니다.
가장 실질적인 건 시차였습니다. 함께 일하는 사람들이 대부분 미국의 빅테크에 있다 보니, 월례 회의가 한국 시간으로 새벽 세 시에 열립니다. 그는 그 회의에 참석하지 못합니다. 대신 슬랙으로 비동기 소통을 이어가고, 회의 내용은 뒤늦게 따라가는 식으로 메웁니다.
물어볼 사람이 없다는 것도 컸습니다. 사내에 같은 일을 하는 사람이 없어서, 막혔을 때 얼굴을 맞대고 물어볼 상대가 없었습니다.
언어는 의외로 덜했습니다. 문서와 텍스트 중심의 소통이라 기술 영어로는 큰 문제가 없었다고 했습니다. 다만 말하기는 어렵다고 솔직히 덧붙였습니다.
리뷰가 일이 된 자리에서 겪는 AI의 두 얼굴
메인테이너가 되고 나서 무엇이 달라졌느냐고 묻자 리뷰 이야기가 나왔습니다. 코드를 짜는 시간보다 남의 코드를 보는 시간이 훨씬 많아졌습니다. 그리고 그 자리에서 AI의 두 얼굴을 동시에 겪고 있었습니다.
먼저 좋은 쪽입니다.
“AI가 PR의 컨텍스트를 잘 알려주니까, 리뷰하는 시간이 확실히 많이 줄어서 요즘은 편하게 하고 있어요.”
동시에 나쁜 쪽도 그의 몫이었습니다.
“아님 말고 식의 PR이 많이 올라와요. 진짜 AI만 돌려서 낸 것들이요. 리뷰하는 입장에서는 그게 좀 그렇죠.”
코드베이스를 읽기 쉬워진 덕에 참여의 문턱이 낮아진 건 분명한 이득입니다. 그런데 같은 이유로, 본인도 이해하지 못한 코드가 그대로 올라옵니다. 문턱이 낮아진 대가를 리뷰어가 치르고 있는 셈입니다.
그럼에도 그는 AI에 거부감이 없었습니다. 자기 코드가 학습되는 게 불안하지 않으냐는 물음에도 마찬가지였습니다.
“저는 그런 불안감은 없어요. AI가 짜준 코드 한 줄 한 줄을 본인이 이해하고 올린다는 책임감만 있으면, 저는 진짜 좋다고 생각해요.”
도구를 쓰느냐 마느냐가 아니라, 올린 코드를 자기가 책임지느냐가 기준이라는 이야기였습니다.
주말을 써가며 1년을 버티게 한 동기
무엇이 그를 계속하게 했느냐고 물었습니다. 주말을 써가며, 새벽 회의를 놓쳐가며 1년을 버틴 힘이 궁금했습니다. 답은 사명감이 아니었습니다.
“커리어적으로 내세울 만한 게 있었으면 좋겠다는 생각이 들어서 했던 것 같아요. 남들과 차별화될 수 있는 뭔가가 있어야 하지 않을까 하는.”
솔직한 답이었습니다. 그리고 그 동기는 지금 형태를 바꿨습니다. 처음에는 일이었는데 이제는 자기를 설명하는 것이 됐다고 했습니다. 실제로 그가 올린 PR의 대부분은 회사 일과 무관하게 스스로 하고 싶어서 올린 것들이었습니다.
Cortex 말고도 그는 Thanos에 기여하고, Prometheus의 Alertmanager와 PromQL 엔진도 손봅니다. Cortex가 다른 프로젝트를 라이브러리로 가져다 쓰다 보니, 코드를 읽다 보면 자연스럽게 그쪽 문이 열립니다. 전부 관측성 영역입니다.
회사 일만 하면 갇힌다
후배가 이 길을 가겠다고 하면 권하겠느냐고 물었습니다. 답은 분명했습니다.
“저는 진짜 적극 장려하는 편이고요.”
이유가 흥미로웠습니다. 오픈소스가 숭고해서가 아니라, 회사 안에만 있으면 갇히기 때문이라고 했습니다.
“회사 일만 하면 무한 단순 반복 루프에 빠지기 쉽거든요. 외부적으로 나를 평가받을 창구가 있어야 하지 않나 싶어요.”
바깥에서는 냉정한 평가가 돌아옵니다. 회사에서는 얼굴을 보며 하기 어려운 말도, 그곳에서는 그대로 날아옵니다. 그 날카로움이 그를 키웠다고 봤습니다.
“이걸 안 했으면 글로벌 빅테크 개발자들이랑 일을 어떻게 해봤겠어요. 그 사람들이 볼 때 내 코드가 과연 좋을까, 그런 걸 객관적으로 평가받을 수 있으니까요.”
잘하는 사람들의 코드를 곁에서 보는 것 자체가 성장이었습니다. 그가 닮고 싶다고 꼽은 사람도 Cortex에서 가장 자주 함께 일하는 시니어 개발자였습니다. 코드도 잘 짜고, 문서도 잘 쓰고, 소통도 잘하는 사람. 어느 하나가 아니라 전부를 하는 엔지니어가 되고 싶다고 했습니다.
메인테이너에게 물어본 것들
한국에서 CNCF 프로젝트의 메인테이너를 만나기가 어렵다 보니, 정작 궁금한 것들을 물어볼 데가 마땅치 않습니다. 이성진 님에게 들은 실무적인 답들을 따로 모았습니다.
1. 메인테이너가 되기까지 몇 단계를 거치나요
Cortex의 경우 컨트리뷰터, 트리아저, 메인테이너로 나뉩니다. 트리아저는 활발히 활동하는 기여자를 가리킵니다. 프로젝트에 따라 단계를 더 세분화해 둔 곳도 있으며, 각 프로젝트의 문서에 공식적으로 명시되어 있습니다. 이성진 님의 경우 한 단계에 약 6개월이 걸렸습니다.
2. PR은 어떻게 병합되나요
다수결이 아니라 규칙이 있습니다. 일반 기여자의 PR은 메인테이너의 승인 두 개 이상을 받아야 병합됩니다. 메인테이너 본인의 PR은 하나면 승인된 것으로 봅니다.
3. 기여가 거절되는 이유는 무엇인가요
코드 품질보다 방향의 문제인 경우가 많습니다. 메인테이너마다 설계에 대한 생각이 달라서, 프로젝트가 향하는 방향과 맞지 않으면 받아들여지기 어렵습니다. 코드베이스가 워낙 커서 전체 맥락을 모르고 올렸다가 반려되는 일도 흔합니다.
4. 메인테이너가 되면 무엇이 달라지나요
코드를 짜는 시간보다 남의 코드를 리뷰하는 시간이 훨씬 많아집니다.
5. 회사 일과 무관하게 시작해도 가능한가요
가능하지만 훨씬 어렵습니다. 코드베이스 전체를 이해하는 데만 엄청난 시간이 들기 때문입니다. 무엇보다 프로덕션에서 실제 트래픽을 받아봐야 보이는 문제들이 있어서, 개발 환경에서만 만져서는 깊이 들어가기 어렵습니다. 개인의 호기심으로 시작한다면 끈기와 노력이 필요하고, 요즘은 AI로 코드베이스를 학습하는 방법이 그 문턱을 조금 낮춰줍니다.
6. 한국에서 활동할 때 무엇이 걸림돌인가요
시차가 가장 실질적입니다. 월례 회의가 한국 시간으로 새벽 세 시에 열립니다. 슬랙 비동기 소통으로 메우게 됩니다. 사내와 국내에 같은 일을 하는 사람이 없어 얼굴을 맞대고 물어볼 상대가 없다는 점도 큽니다. 언어는 문서와 텍스트 중심이라 기술 영어로는 큰 문제가 되지 않습니다.
7. 오픈소스를 프로덕션에 도입할 때 무엇을 봐야 하나요
쓰는 쪽에서는 라이선스 확인과 보안 취약점 점검이 기본입니다. 만드는 쪽에서는 사용성, 라이선스 정책, 보안이 축입니다. 라이선스는 Apache 2.0을 쓰는 경우가 많습니다. CNCF 프로젝트는 정기적으로 보안 점검을 받습니다. 버그가 많은 프로젝트가 실제로 적지 않아서, 기업이 믿고 도입하려면 이 부분이 중요합니다.
8. AI로 만든 코드를 기여해도 되나요
도구를 쓰느냐가 기준이 아니라, 올린 코드를 자기가 책임지느냐가 기준입니다. AI가 짜준 한 줄 한 줄을 본인이 이해하고 올린다면 문제될 게 없습니다. 반대로 이해하지 못한 채 AI만 돌려서 낸 PR은 리뷰어의 시간을 그대로 가져갑니다.
9. 어디서부터 시작하면 좋을까요
이성진 님은 자기가 실제로 쓰는 도구에서 시작했습니다. 4년 넘게 코드베이스를 읽어온 프로젝트였고, 쓰다 보니 필요한 것이 보였습니다. Cortex 하나에 머물지도 않았습니다. Cortex가 다른 프로젝트를 라이브러리로 가져다 쓰기 때문에, 코드를 읽다 보면 Thanos, Prometheus의 Alertmanager, PromQL 엔진처럼 연결된 프로젝트로 문이 열립니다. 하나를 깊게 파면 그 주변으로 길이 생기는 구조입니다.
메인테이너가 메인이 되는 [메인터뷰] 의 일곱 번째 이야기는, 6개월씩 계단을 밟아 올라간 한 엔지니어의 이야기로 채웠습니다.
[메인터뷰] 는 클라우드브로 커뮤니티가 오픈소스 빌더들의 이야기를 기록하는 시리즈입니다. 다음 편에서 또 다른 빌더를 소개할게요!