LINE 오픈소스 매니저 이서연 님을 만나보았습니다!

안녕하세요! 🙂 오늘은 지난 4월에 공개된 ‘LINE 오픈소스 매니저 이서연 님과 오픈소스 얘기 시원하게 풉니다‘ 인터뷰에서 나눈 이야기를 전해드리려고 합니다.

 

오픈소스 매니저가 하는 일

Q. 안녕하세요! 반갑습니다. LINE에서 어떤 일을 하고 계신지 소개해 주시겠어요?

A. 네! 안녕하세요. LINE 오픈소스 매니저 이서연이라고 합니다. 저는 LINE에서 진행되는 다양한 오픈소스 관련 업무에 일관되게 적용할 수 있는 가이드를 만들고, 그 가이드에 따라 오픈소스화를 진행하는 과정을 안내하고 관리하는 일을 맡고 있습니다. 경우에 따라 오픈소스를 널리 알리는 마케팅 일도 하고요.

Q. 직무 이름이 ‘오픈소스 매니저’라고 말씀해 주셨는데요. 한국에 오픈소스 매니저 역할을 하시는 분들이 많이 계신가요?

A. 별로 없는 것 같다고 이야기하면 오픈소스 매니저이신 분들이 슬퍼하실 것 같은데… 조금 적은 편이라고 생각합니다. 제가 외부에 나가서 저랑 비슷한 일을 하시는 분들을 만나 보면 대부분 두 명 이상의 팀으로 구성되어 있더라고요. 그런데 또 그 팀 이름이 ‘오픈소스 팀’이라고 지어져 있지는 않은 것 같아요. 아직까지는, 한국에서 오픈소스를 담당한다고 하시는 분들은 보통 오픈소스 컴플라이언스 관련 업무를 하고 계시는 것 같습니다.

Q. 오픈소스 컴플라이언스가 무엇인가요?

A. 오픈소스 라이선스를 보면 오픈소스를 재배포(오픈소스를 사용한 프로그램이 제3자에게 넘어가는 것)할 때 ‘이 프로그램을 내가 혼자서 만들었다’라고 자신의 크레디트만 넣지 말고, ‘이 안에 들어간 수많은 오픈소스 개발자들의 크레디트를 함께 넣고 그들의 공로를 알려라’라는 규칙이 있거든요. 그런 규칙을 지키는 일이에요. 한국뿐만 아니라 전 세계적으로도 오픈소스 컴플라이언스와 관련해선 이게 제일 주요한 업무인 것 같습니다.

Q. 그런 게 오픈소스 컴플라이언스군요. 제가 보기에는 오픈소스를 공개하는 데에도 많은 공수가 들 것 같아요.

A. 어떨 때는 공수가 많이 들다가도, 어떨 때는 또 굉장히 빨리 끝나는 경우도 있는데요. 저희가 오픈소스를 공개하는 과정을 설명하자면, 일단 개발자가 오픈소스 공개 신청서를 간략하게 작성합니다. 신청서에는 프로젝트의 개요와 함께 어떤 문제의식을 바탕으로 이걸 만들게 되었는지 적는데요. 여기서 문제의식이 뭐냐면, 사실 개발자분들이 만들려는 것과 비슷한 기능을 가진 오픈소스들이 이미 시중에 많거든요. 그래서 그것들과 비교해 어떤 차별점을 가지는지, 왜 이미 있는 걸로 문제가 해결되지 않았는지에 대해 물어보고요. 그다음에 어떤 사람이 이 오픈소스를 계속 유지 보수할 것인지, 장기적, 그리고 단기적인 마일스톤이 있는지에 대해서도 물어봅니다. 대부분의 개발자분들은 일단 당장 필요해서 만들기 때문에 장기 계획까진 없는 경우도 많은데요. 오픈소스를 꾸준히 유지해 나가기 위해서 그런 부분을 좀 더 구체적으로 생각해볼 수 있는 시간을 드리는 거죠.

 

LINE의 오픈소스

Q. 위에서 설명하신 것 같은 노력을 들여서 회사에서 오픈소스를 공개하면 어떤 점이 좋은가요? 

A. 예를 들어, 어떤 개발자가 업무에 필요해서 플러그인을 만들어서 혼자 쓰고 있었다고 생각해 볼게요. 그런데 다른 분들이 보고 ‘이거 뭐예요? 되게 좋아 보인다~’라고 해서 같이 쓰게 되는 거예요. 그럼 이 플러그인이 점점 퍼지겠죠? 근데 이런 상황에선 다른 사람들이 쓰다 궁금한 게 있으면 플러그인을 만든 사람에게만 질문을 하게 되잖아요. ‘이렇게 했는데 이게 안돼요’, ‘이런 기능도 있었으면 좋겠어요.’ 등등. 그러면 이 플러그인을 오픈소스로 공개해서 사용하는 것과 별다를 바가 없는 거죠. 게다가 회사 안에서 이렇게 인기가 많으면 오픈소스로 공개했을 때 회사 바깥의 다른 사람들에게도 분명 필요하고 도움이 될 테니까요. 회사 입장에서도 개발 생태계에 기여할 수 있는 부분이고요.

Q. 개발자들이 회사 안에서 오픈소스를 하면 직무 만족도가 좀 오르나요?

A. 사실 저는 그 부분을 중요하게 생각하고 있어요. 각 개발자들이 LINE이라는 회사에서 다양한 경험을 해보고, 회사에 대한 자부심이 커지면 좋잖아요. ‘오픈소스를 공개하는 프로세스를 거치면서 자부심을 많이 가졌으면 좋겠다’라는 생각으로 열심히 노력하고 있습니다.

Q. LINE GitHub에 오픈소스가 대략 몇 개 정도 공개되어 있나요?

A. LINE은 메신저가 메인 사업인데요. 메신저에 여러 가지 서비스를 얹을 수 있거든요. LIFF(LINE Front-end Framework)라든지, 그런 것들을 쉽게 사용할 수 있도록 Messaging API를 감싼 SDK를 오픈소스로 공개하고 있는데요. 그게 각 언어 별로 많아요. Ruby나 PHP, Java, Python 등 전부 포함해서 한 60개 정도입니다.

 

Armeria와 오픈소스 마케팅

Q. 네. 여기까지 오픈소스 매니저로 어떤 일을 하고 계신지 잘 알 수 있었습니다. 그런데 컴플라이언스나 오픈소스 공개 외에 다른 일도 하고 계시나요?

A. LINE에서 공개한 오픈소스 중 가장 대표적이라고 할 수 있는 Armeria라는 오픈소스 프로젝트 팀에서 마케팅 역할을 함께 맡고 있습니다. 

Q. 좀 더 구체적으로 말씀해 주신다면? 

A. 이 Armeria 프로젝트는 개발자 세 분이 풀 타임을 쏟아서 굉장히 열심히 만들고 계시고, 팬층도 꽤 두텁다고 생각해요. 이렇게 만들어진 프로젝트가 좀 더 빛을 발할 수 있도록 만드는 게 제 역할입니다. 구체적으로 작년에 한 일을 되돌아보면, 스티커나 머그컵 같은 굿즈를 만들어서 행사나 발표 장소에 가져가서 홍보를 하기도 하고요. 컨퍼런스에 Armeria를 소개하기 위한 부스를 열기도 해요. 네이버의 오픈소스랑 같이 부스를 연 적도 있었고, LINE 대만 오피스랑 같이 대만에서 열었던 컨퍼런스에도 부스를 열었어요. 아 참! 그리고 작년에는 사내에서 Armeria 스프린트(GitHub Contributions 그래프를 푸릇푸릇하게 만들어보아요(feat. Armeria Sprint))를 진행하기도 했었습니다.

Q. Armeria 스프린트는 무엇인가요?

A. 이건 제가 처음부터 아이디어를 낸 것은 아니고요. 스프린트 서울이라는 것을 보고 Armeria에도 이런 게 필요할 것 같아서 시작하게 되었어요. 일단 너무 재미있어 보이기도 했고요. 스프린트가 무엇이냐면요. 사람들이 오픈소스에 기여해 보고 싶다는 로망을 갖고는 있는데 혼자서 해보려면 어디서부터 시작해야 할지 잘 모를 수 있거든요. 그래서 Armeria에 기여하고 싶은 분들을 일단 모은 다음에, 저희 메인테이너 분들이 프로젝트 셋업 방법도 알려드리고, ‘이 이슈는 이런 식으로 해결할 수 있을 것 같은데 어떤 분이 해보시겠어요?’라고 제안도 해서 각자 이슈를 분배한 다음, 이제 모여서 개발을 하는 거죠. Armeria 메인테이너에게 직접 물어볼 수 있다는 게 Armeria 스프린트의 제일 큰 장점이었던 것 같아요. 

Q. 굉장히 좋은 시도네요. 혹시 스프린트에서 재미있는 일이 있었다면 한 번 소개해 주세요!

A. 재미있는 일도 많았지만 조금 안타까웠던 일이… 사실 모여서 이슈 하나를 잡고 하루 만에, 그것도 몇 시간 안에 PR을 올리는 게 쉬운 일이 아니거든요. 저희가 초심자들이 시도하기 좋은 이슈에 ‘Good-first-issue’라는 라벨을 달아 놓긴 하는데요. 이 라벨이 붙은 이슈에 도전한다고 하더라도 몇 시간 안에 끝내기엔 어려울 수 있어요. 그런데 또 어떤 분은 그중에서도 좀 괜찮은 이슈를 만나서 ‘이렇게 하면 될 것 같아’라고 금방 감을 잡고 두 시간 만에 PR을 올리시는 거에요. 그런 상황에서 쉽게 풀리지 않으셨던 분들이 그걸 보고 또 좌절하시고… 이후에 저를 막 피해 다니시는 거예요. 엘리베이터에서 눈을 안 맞추신다거나, 인사 대충하고 지나가신다거나. 막 그렇게 죄책감을 느끼시는 것 같아서 저는 조금 안타깝고 죄송스럽기도 했어요.

Q. 그러면 그분들의 PR은 결국 어떻게 됐나요? 

A. 그 당시가 Github에 Draft PR이라는 기능이 나오기 직전이었던 것 같아요. 그래서 아예 PR이 안 열린 것도 있었고요. Armeria의 이슈들을 보면 ‘내가 할게’라고 코멘트가 달려 있는데 업데이트가 안 되고 있는 것들이 꽤 있어요. 그런데 한 분이 오랜 기간에 걸쳐서 짬짬이 시간 날 때마다 PR 업데이트를 해주셔서 결국엔 머지된 케이스도 하나 있거든요. 그분에게 정말 감사하다고 말씀드리고 싶어요.

 

오픈소스 라이선스 

Q. 오픈소스 라이선스가 굉장히 다양하잖아요. 대표적으로 GPL, BSD, MIT 등이 있는데요. 이런 라이선스들의 장단점이나 사례들을 외우고 계신 건가요?

A. 어느 정도 특징은 외우고 있어요. GPL 계열의 라이선스들은 다시 한 번 꼼꼼히 읽어봐야 하긴 하죠. 좀 편하게 볼 수 있는 라이선스들은 MIT나 BSD예요. 그 라이선스들은 길이도 되게 짧고 읽기도 쉬워요.

Q. 그러면 LINE이 오픈소스 공개할 때 주로 사용하는 라이선스는 무엇인가요?

A. Apache 라이선스입니다. Apache 라이선스 전문을 보면 굉장히 긴데요. 지적 재산권을 좀 더 중요하게 다루고 있는 것 같아요. 물론 모든 라이선스들이 지적 재산권을 중요하게 다루기는 하는데요. Apache 라이선스의 특징은 ‘사용하는 사람이 크게 지켜야 할 의무 사항’이 없어요. ‘Copyright을 지우지 말고 유지하라’, ‘라이선스 전문을 같이 배포하라’, 이렇게 크게 두 가지 정도가 중요하게 작용합니다. 

그리고 저희가 Apache 라이선스를 채택한 또 다른 이유는 특허와 관련된 내용 때문입니다. 만약에 어떤 사람이 본인이 가지고 있는 특허가 포함된 어떤 오픈소스를 공개했다고 가정해 볼게요. 이 오픈소스를 공개해서 다른 사람도 쓸 수 있게 한다면 특허권을 그냥 무료로 사용하게 해주는 거겠죠? 그런데 갑자기 어떤 사람이 나타나서 ‘이 특허, 사실 내 거다. 당신이 내 특허를 침해한 거다’라고 특허 소송을 거는 경우가 있을 수 있거든요. 그런 경우에 Apache 라이선스는 더 이상 이 오픈소스를 사용하지 못하게 라이선스를 종료할 수 있는 규칙이 있습니다. 즉, 특허 소송에 휘말렸을 때 방어할 수 있는 수단을 포함하고 있는 거죠.

Q. 기업 입장에서는 공개할 때 굉장히 사용하기 좋은 라이선스군요?

A. 네. 리스크를 확 줄여줍니다. 그리고 대부분의 오픈소스들이 그렇겠지만, 책임 소재가 없다는 것? Apache에서 중요하게 다루는 게, 오픈소스를 사용해서 뭔가 문제가 발생했을 때 ‘책임의 소재를 묻지 않겠다’라는 거에요. 만약 누군가가 기여를 했는데 그 기여 때문에 문제가 발생했어요. 그래도 그 기여자에게 ‘당신이 책임지고 고쳐라’라고 보증을 요구하지 않는다는 게 장점입니다.

 

마치며

Q. 오늘 인터뷰에 응해주셔서 감사합니다. 마지막으로 하시고 싶은 말씀이 있다면?

A. 사실 개발자분들 다 바쁘시잖아요. 그런데 그러면서도 다들 마음 한구석에는 ‘나도 언젠가 오픈소스에 기여하고 싶다’ 혹은 ‘내 이름을 저기 남겼으면 좋겠다’라는 생각을 갖고 계실 거예요. 그리고 종종 ‘주말에 어떤 오픈소스 커밋 날렸는데 되게 뿌듯했어요’라고 말씀해 주시는 분들도 계시거든요. 그런 분들을 볼 때마다 업무 중에 조금 더 자연스럽게 오픈소스에 참여하는 일이 많아졌으면 좋겠다는 생각을 해요. 이런 부분에 대해서 저도 계속 고민하고 있습니다. 아무쪼록 앞으로 LINE의 오픈소스가 더 잘 됐으면 좋겠어요.

■ 오픈소스에 관심 있는 분들께 이번 글이 많은 도움이 되었길 바랍니다. LINE의 오픈소스 관련 소식은 공식 소셜 계정을 통해서도 공유하고 있으니 많이 팔로우해 주세요! 🙂

Related Post