몇 주전 페이스북 "OSS 개발자포럼" 그룹의 주최로 이희승님이 오픈소스 제대로 활동하기를 주제로 발표하신다는 걸 알고는 냅다 신청해서 지난 토요일(25일)에 갔다가 왔다. 이희승님은 Mina, Infinispan, Netty 프로젝트를 만드신 분으로 현재는 트위터에서 일하고 계시고 국내에서 오픈소스쪽 활동으로는 가장 활발하다고 할 수 있다. 이희승님은 이름 정도만 알고 있다가 지난번 Deview에서 Netty 발표를 발표도 참 잘하신다는 것을 알게 되어서 이번에는 망설일 이유가 없었다. 오픈소스에 최근 관심도 더 커지기도 했고...


오픈소스 활용 vs. 활동
처음에는 가볍게 오픈소스의 활용과 활동에 대해서 얘기하셨다. 가장 간단한 것은 오픈소스를 단순히 이용하는 것이고 내부적으로 수정해야 할 부분이 있어서 수정해서 사용(internal fork)하기도 하는데 이런 경우 점점 원 프로젝트와 달라지는 부분이 커지기 마련이라 관리가 쉽지 않다. 수정한 내용을 단순히 공개하기도 하는데(external fork) 다른 사람이 사용할 수 있으므로 좀 더 나은 방법이기는 하지만 원 프로젝트에 적용된다는 보장이 없으므로 해당 프로젝트에서 직접 활동하는 것이 더 낫다.

블로그나 강연을 통해서 오픈소스에 대한 경험을 공유할 수 있다. 상용 소프트웨어의 경우 동작하는 부분은 그대로 놔두는 경향이 있지만 오픈소스에서는 디자인등을 적극적으로 변경해 나가므로 문서에 제때 반영되지 못하는 경우가 많은데 실 사례를 많이 공유함으로써 사람들이 더 쉽게 사용할 수 있게 된다. 이는 오픈소스 프로젝트와 느슨하게 연결되어 있지만 중요한 부분이고 그 외에 버그리포팅이나 기능추가 요청, 토론참여 등이 있다.


오픈소스 활동의 목적
그럼 오픈소스 활동을 왜 해야하는것인가? 활동하기 전에 목적을 확실히 할 필요가 있다.

가장 많이 사용하는 웹서버를 만드는 것을 가정했을 때 (물론 재미난 과정이겠지만) 스펙 준수나 호환성 테스트를 다 하는 것은 무척 시간이 많이 들기 때문에 이러한 부분 오픈소스를 사용하고 핵심 역량에 집중해서 개발할 수 있다. 그리고 오픈소스에 직접 참여하면 사용하는 오픈소스에 변경해야 할 부분이 생겼을 때 직접 참여해서 적극적으로 변경할 수 있다. 그렇지 않으면 기다리거나 내부적으로만 수정하게 되서 관리가 어려워진다. 적극적으로 참여해서 오픈소스 로드맵에 직접 참여할 수 있고 설사 의견이 반영되지 않는다고 하더라도 그 토론에서 얻을 수 있는 것이 많다.

그리고 활동 자체에도 큰 의미를 둘 수 있다. 보통 오픈소스 프로젝트는 다양한 나라에서 다양한 사람들이 참여를 하게 되므로 사람의 성품이나 치적에 대한 편견없이 코드에만 집중해서 커뮤니케이션할 수 있는 능력을 기를 수 있다. 많은 사람이 온라인으로 협업하는 법을 배우게 되므로 얼굴보고 협업하는 것도 한결 쉬워진다. 사람에 대한 비난 보다는 코드가 중요하다는 것을 많이 배울 수 있다. 최근에 많아지고 있는데 오픈소스 활동을 채용절차의 일부로 활용하기도 한다. 물론 이는 좋은 코드를 작성했을 때의 이야기이지만 오픈소스 활동 자체가 좋은 코드로 발전하는 하나의 과정이라고 할 수 있다.


오픈소스 제대로 활동하기

주의할 점
자주 있는 경우는 아니지만 초기에 소위 찍히면 그 뒤에는 여러가지로 열심히 해도 잘 안되는 경우가 있으므로 처음부터 잘 해야 한다. 버그리포팅을 하는 입장에서는 하나의 이슈이지만 커미터들 입장에서는 수십,수백개의 이슈가 올라오므로 단순 리포팅 자체는 큰 의미가 없다. 이해하기 어려운 영어나 불충분한 설명으로 버그리포팅을 하게 되면 우선순위가 낮아져서 처리되지 않으므로 최대한 자세하고 명확하게 리포팅해야 하고 서로의 시간을 소중하게 생각할 수 있어야 한다. 특히 "언제 해결되냐는 식"의 재촉은 찍히는 지름길이고 공식 채널이 아닌 비공식 채널(메일링, IRC , 이슈트래커가 아닌 개인 메일이나 전화)로 연락하면 무조건 공식채널로 연락하라고 하기 마련이다. IRC도 공식 채널이기는 하지만 기록으로 남고 누군가 다시 검색해 볼 수 있는 메일링이나 Stackoverflow를 이용하는 것도 좋은 방법이다.

버그 리포트
버그리포팅은 jira나 github 이슈등의 공식 이슈 트랙커를 사용한다. 버그 리포트를 올리기 전에 유사한 이슈가 있는지 필히 확인해야 하고 이미 존재한다면 기존 이슈에 보충할 내용만 추가하고 vote나 watch 등으로 관심을 표현하는 것이 좋다. 그리고 리포팅을 할 때는 사용 버전, OS나 VM등의 환경, 재현방법등을 자세하면서 깔끔하게 적는 것이 좋고 좀더 나아간다면 왜 이런 문제가 발생했다고 생각하는지를 찾아서 같이 올리거나 의심가는 부분의 소스코드를 알려준다면 처리되는 우선순위를 높힐 수 있다.

기능 제안
기능제안도 버그리포팅과 유사하게 이슈트래커를 사용한다. 마찬가지로 중복 등록이 되지 않도록 기존 이슈들을 검색해봐야 하고 기능을 요청하게 된 배경이나 어떤 효과가 있는지, 잠재적으로 예상되는 위험성, 구체적인 구현방법등을 함께 제안하면 좋다.

패치 보내기
이슈에 패치를 첨부하면 커미터들이 리뷰를 하게 된다. 코드가 너무 맘에 들어서 한번에 적용되는 경우는 흔치 않다. 보통은 관례를 맞춰달라거나 자세한 내용을 물어보거나 일부를 바꿔 달라고 하는 경우가 많다.(물론 때로는 칭찬도 듣는다.) 이러한 리뷰에 따라 패치를 다시 첨부하면 되고 해당 프로젝트에 개발자 가이드가 존재한다면 미리 숙지해 두는 것이 빨리 적용되는데 도움이 된다. 이렇게 리뷰하는 과정에서 포기하면 참여할 수 있는 좋은 기회를 놓치는 것이므로 끈기있게 해야 하고 커미터의 의견이라고 너무 끌려다니지만 말고 자신의 의견을 개진하는 것이 좋다.

Pull Request
Github가 사실상 오픈소스 코드 저장소의 표준이 되었기 때문에 요즘은 패치를 보내는 일은 많지 않고 대부분 Github의 Pull Request를 이용한다. DVCS의 장점을 이용해서 각 저장소의 변경사항을 자동으로 보여주고 개발자가 리뷰하면 원 저장소에 적용되는 방식으로 모두에게 편리해 졌다.

일원이 되기
프로젝트의 일원이 되는 경우는 패치를 하는 과정에서 커미터가 얘기가 잘 통한다고 느끼거나 좋은 코드를 항상 작성해서 굳이 매번 리뷰를 하지 않아도 되겠다고 느껴서 믿을 만한 수준이 되면 일원이 될 수 있다.


새로운 오픈소스 프로젝트 시작하기
새로운 오픈소스 프로젝트를 시작하기 전에 "기업과 개인의 이익을 넘어설 수 있는지" 고민해 볼 필요가 있다. 자신이 다른 사람에게 "믿을만한 개발자"라고 말할 수 있는 자격이 있는지 먼저 봐야 하고 내가 하고 싶어서 또는 회사가 원해서가 아니라 실제로 추구하는 가치가 무엇인지를 고민해 볼 필요가 있고 이는 생색내기가 아닌 진짜 오픈소스를 하고 싶다면 고민해 볼만한 일이다. 그리고 이러한 가치가 있다면 장기간 유지해야하고 회사외부로 오픈할 때도 편협하게 외부사람이라고 권한은 안주는 등의 결정에 영향을 줄 수 있고 진정으로 열린 프로젝트인지도 고민해 봐야 한다.


사례 소개 : open source @ twitter
많이 알려졌다 시피 오픈소스에 적극적인 트위터를 사례로 소개해 주셨다. 트위터는 현재 내부에서 개발한 프로젝트를 오픈소스로 공개해서 지속적으로 유지하고 대표적으로는 Bootstrap, finagle, ostrich, zipkin, twemproxy, mysql fork 등이 있다. 그리고 블로그를 통해서 기술을 공유하고 있고 내부에서 많이 사용하는 스칼라의 전파를 위해 Scala School이나 Effective Scala등의 문서도 공개하고 있다. 그 외에도 netty, apache hedwig, mesos, pig등의 오픈소스에 적극적으로 참여하고 개발자를 직접 고용해서 오픈소스개발을 하게 하고 있으며 Apache Software Foundation, Linux Foundation, Travis-CI등에 재정적인 지원을 하고 있다.



Epilogue
아주 긴 시간은 아니었지만 여러 오픈소스를 진행하면서 쌓인 실 경험에 바탕해서 얘기해 주셨기 때문에 알고 있던 내용이라고 하더라도 그 무게가 달랐고 시스템 적인것 외에 실제적인 부분은 잘 몰랐기에 느끼는 부분도 많고 오픈소스에 대한 꿈을 더 크게 품을 수 있었다.(올해 어느정도 발이라도 걸쳐보려는게 목표이긴 한데 ㅠ) Github 덕분에 오픈소스에 참여할 수 있는 기회는 무한하게 열린 상황이지만 가끔 간단한 거라도 리포팅이나 패치를 보내다가 무시당하거나 하면 맘이 상하는 경우가 많았는데 커미터의 입장에서의 이야기를 들어보면서 그런거에 일일이 맘상하면 안되겠다는 생각이 들었다.(뭐 대단한거 보낸것도 아니고...) 질문시간에도 여러 질문이 오갔는데 굳이 여기에 정리하진 않겠다. (궁금한 사람은 Insane님이 정리한 오픈소스 제대로 활동하기 멘토링 후기 참고)

마지막으로 원래도 그런 생각을 좀 하고 있어서 인지는 몰라도 이번 세미나를 들으면서도 사람들이 뭔가 과정을 뛰어넘어서 결과만 바라는 것 같은 느낌이 들었다. 직접적으로 말하면 오픈소스를 개발하고 사람들과 의견을 나누고 실력을 쌓는 과정을 생략하고 유명프로젝트의 커미터를 좀 더 쉽게 될 수 있는 방법이 없나? 하는 생각을 하고 있는 듯하게 느껴졌다.(편견일지도...) 내가 생각하기에 오픈소스에서 가장 중요한 것은 결국 실력이고 사실 실력만 있으면 그외에것은 다 무시할만한 수준이라고 생각한다. 이희승님이 나누어 주신 얘기도 실력은 제외하고 초기에 모를 수 있는 팁을 알려 주신 것이지 저런걸 다 지킨다고 커미터가 되는게 아니라 일단 해당 프로젝트를 직접 개발하고 멋진 코드를 작성할 수 있는 능력이 되야 하는데 그런 과정은 쉽게 넘어가고 싶은게 아닐까 하는 느낌이 들었다.(물론 나도 그런 능력이 아직 안되는데 잘하시는 분들을 얘기한건 아니다.)

이희승님이 얘기하셨듯이 오픈소스에 참여하는 과정은 아주 다양하다. 내가 아직 코드를 막 짤 수준이 아니라면 버그 리포팅을 할 수도 있고 질문에 답변을 열심히 달아줄 수도 있고 가이드 같은걸 만들어서 제공할 수도 있다. 몰론 패치를 보낼 수 있다면 더욱 좋겠지만... netty에 올라오는 이슈나 패치에 한국사람이 거의 없다는 이희승님의 얘기에 약간의 안타까움을 느끼면서 어떻게 커미터가 되느냐 마느냐 보다는 그냥 자신이 할 수 있는 부분에서 오픈소스 활동을 다양하게 하는 사람들이 많아졌으면 좋겠다. 그런 가운데서 커미터들도 더 나오고 그러겠지. 내 생각에는 오픈소스는 그게 더 좋은 방법이고 즐거운 방법이기에 그렇게 개발하면서 명예가 따라오는 것이지 명예를 얻기 위해서 오픈소스를 하는건 아니라고 생각한다. 국내 회사들의 오픈소스들을 개발자들이 거의 신경도 안쓰는 이유도 질답중에 이희승님이 비슷한 얘기하셨듯이 오픈만 했다고 다 오픈소스가 아니기 때문이 아닐지...


덧) 막판에 좀 흥분한 경향이 있지만 수정할까 하다가.. 그냥... 놔두기로 했다. 보충삼아 약간 관련된 얘기로 전에 올렸던 사내 프레임워크 만들지 말자를 링크걸어 본다.