안녕하세요, 홉스의 강효준입니다.
홉스는 이번 파이콘 한국 2021에 후원사로 참여했는데요. 오늘은 제가 파이콘 한국 2021 후원사 세션에서 발표한 주제 "회사에서 오픈 소스 라이브러리 개발을 장려하면 좋은점"과 제가 개인으로 참여해서 발표했던 주제인 "내 파이썬 오픈 소스 연대기"에 대한 얘기를 공유하려 합니다.
오픈 소스에 대해서 얘기하게된 이유
저는 프로그래밍을 시작했을 때부터 지금까지 오픈 소스를 통해서 너무나 많은 도움을 받고 있다고 생각했고, 저와 비슷한 생각을 하시는 분들이 쉽게 오픈 소스 활동에 참여하실 수 있으면 좋겠다는 바람이 생겼습니다.
마침 파이썬이 처음 오픈 소스 라이브러리를 만들어서 배포해본 언어였습니다. 그래서 제 오픈 소스 경험을 파이콘 한국에서 발표해보면 좋을 것 같다고 생각했습니다.
제가 지금까지 경험해본 오픈 소스 경험을 통해 많은 분들이 저처럼 소소하게 오픈 소스 생태계에 참여하게 되면 좋을 것 같습니다.
그리고 이어서 다음 글로 생태계 참여에 대한 동기 부여를 더 잘해보고자 개인의 참여뿐만 아니라 회사 차원의 참여에 대해서도 얘기해보겠습니다.
나의 파이썬 오픈 소스 연대기를 소개하며
오픈 소스는 어떤 보상을 바라고 하기보다는 조금 더 나은 환경을 위한 기여에 가깝기 때문에 자신을 위한 동기 부여가 더 중요합니다. 제가 스스로 동기 부여를 할 수 있도록 유도한 방법이나 다른 분들의 도움을 받는 방법들을 소개하면서 진입 장벽을 낮추고 싶습니다.
아직 오픈 소스 기여를 시작하지 못하신 분들에게 유명한 라이브러리에 기여한다거나 큰 문제들을 해결하는 작업들이 아니어도 나를 위해 소소한 문제를 해결한다면 충분히 좋다고 얘기하고 싶습니다.
프로그래밍을 처음 배웠을 때
저는 파이썬으로 처음 오픈 소스 라이브러리를 만들었습니다. 요즘 많이 사용하는 언어들이 대부분 그렇지만 파이썬 역시 책이나 공식 문서 등 어떠한 경로를 통해 배우더라도 언어를 학습하고 사용하면서 자연스럽게 오픈 소스를 접할 수 있는 기회가 많습니다.
접할 수 있는 기회가 많은 만큼 관심도 많이 가지게되는데요. 대표적 파이썬에서 오픈 소스를 접할 기회를 살펴보면 파이썬 구현체중 가장 많이 사용되는 구현체인 CPython이 오픈 소스이고 PyPy, IronPython 같은 여러 구현체가 오픈 소스로 개발되고 있습니다.
그리고 파이썬은 오픈소스로 더 잘 개발하기 위해 Python Software Foundation(이하 PSF)에서 관리하고 있습니다. PSF에서 파이썬을 더 잘 개발하기 위해 PEP 같은 문서를 관리하기도하고 커뮤니티 발전을 위해 파이콘 US 같은 행사를 개최하고 있습니다.
파이썬으로 프로그래밍을 하면서 사용하는 도구들도 오픈 소스인데요. virtualenv나 pip같이 파이썬을 사용하면 꼭 사용하게되는 라이브러리도 오픈소스입니다.
이렇게 오픈 소스를 사용하다 보면 만들어보고 싶다는 생각도 듭니다. 그리고 프로그래밍을 하면서 라이브러리의 문제를 만나게되면 문제를 직접 해결하고 싶은 생각이 들기도 합니다. 저는 처음 그런 생각을 하고 제가 사용하고 있는 라이브러리의 리포지토리에 처음 들어갔을때 정말 막막하게 느껴졌는데요.
기여하는 방법을 알기 어렵고 코드 베이스도 커서 어떤식으로 기여해야할지 감을 잡기가 어려웠습니다. 그래서 제가 만들어야하는 프로그램들 중 회사와 관련이 있어 공개하지 못하는 경우를 제외하고 일단 코드를 공개해보며 오픈 소스 기여에 첫 발걸음을 시작했습니다.
처음 만들어본 공개되어 있는 코드
저는 2009년~2010년도쯤에 파이썬을 처음으로 배우면서 버전 관리 도구인 머큐리얼의 사용법도 같이 배웠습니다. 머큐리얼 저장소를 저장하는 서비스를 찾다가 아틀라시안이 운영하는 빗버켓에 여러개 개인 프로젝트들을 저장했었는데요. 이때는 프라이빗 리포지토리가 기본값으로 만들어지기도 했었고, 지금보니 제가 오픈해두었다고 생각한 코드들도 보이지 않더라고요.
그래서 이 시기 이후에 Git을 배우게 되면서 사용했던 GitHub에 만들었던 프로그램들을 찾아봤는데, 제가 해결하고 싶은 문제를 다른분들도 같이 해결할 수 있도록 잘 만들어두지는 못했던 것 같습니다.
README에 설치법이 없는 것을 시작으로 이 프로젝트를 시작하게 된 이유, 이 프로그램을 실행하면 어떤 일을 할 수 있는지 적어두지도 않았습니다.
물론 제가 그때 당시에 진행하고 있던 멤버쉽 프로그램 때문에 만들었던 프로그램이지만 프로그램을 설명하는 요소들이 너무나 적어서 제가 지금 이 프로그램을 고치려고해도 엄두를 낼 수 없을 것 같습니다.
이런 관점에서 보면 이 프로젝트는 코드가 공개되어 있긴하지만 오픈 소스라고 부르기는 어려울 것 같긴합니다. 그래도 이런식으로 코드를 공개하다보니 이후에 다른 문제를 해결할때도 오픈 소스로 진행해봐야 하겠다는 생각을 할 수 있었습니다.
처음 배포해본 오픈 소스 라이브러리
제가 처음 배포까지 해봤던 오픈 소스 라이브러리는 MMCQ라는 알고리즘을 구현한 라이브러리를 파이썬 버전으로 포팅했던 라이브러리입니다.
이때 제가 다니던 회사에서 사진의 대표색을 뽑아내서 백그라운드로 설정해야하는 문제를 해결하기 위해서 만들게 되었습니다.
패키징도 처음으로 하고 PyPI에 업로드했습니다. 회사 안에서 제대로 쓰이진 않았는데 그래도 PR도 몇개 받았고 최근에 제가 Python3 지원 하도록 패치를 했어요
mmcq.py를 오픈 소스로 만들게된 이유를 더 자세히 얘기해보자면 몇가지 이유가 있었는데요.
- 이때는 Private package index 운영하는 것에 대해서 잘 알지 못했고, 모듈로 떼어내서 만드는 김에 pip로 설치할 수 있게 만들면 좋겠다고 생각했습니다.
- MMCQ 알고리즘이 이미지에서 대표색을 골라내야하다보니 이미지 라이브러리를 사용해야헀는데, 같이 일하던 동료분이 이에 대해 잘 아시는 동료분에게 도움 받는게 쉬웠습니다.
- 그때 당시엔 리서치가 부족했는지 비슷한 기능을 제공 해주는 라이브러리를 찾지 못했어요.
그렇다면 내가 라이브러리로 만들어서 배포하면 비슷한 문제를 잘 해결할 수 있겠다 라는 생각을 했습니다. 그래서 야심차게 준비를 해서 오픈 소스로 만들어 공개했습니다.
그런데 라이브러리의 버그로 대표색을 일정하게 고르지도 못했고, 프로세싱의 속도가 너무 느려서 제대로 사용하지는 못했습니다. 자바스크립트 라이브러리를 기반으로 포팅한 것이었는데 잘못 옮긴 부분도 많더라고요.
이 라이브러리가 만들어지고 한 4~5개월이 지나고 문제 있는 부분을 해결해주신 PR을 받았습니다. 처음으로 제가 만들었던 오픈 소스 라이브러리에서 다른분의 PR을 받았던 경험이었기에 이 PR은 아직까지 많이 기억에 남습니다.
회사에서 사용하지 못하게된 이후에 문제 있는 부분을 이슈로 만들어뒀었는데 댓글로 문제있는 부분을 알려주시더니 패치까지 올려주시더라구요. 엄청 신났던 기억이 납니다.
결국 제가 만든 라이브러리는 사용하지 못하게 되고 리서치를 진행하다보니 ImageMagick의 기능으로 대표색을 골라내는 기능이 제공되고 있었습니다. ImageMagick의 문서를 보다보니 quantize 메서드가 있는것을 발견했습니다. 이미지의 대표색을 골라내는 문제를 해결하기 위해서는 ImageMagick의 Python 바인딩 라이브러리인 Wand에 해당 메서드 바인딩만 추가하면 된다는 사실을 알게 되었고, Python에 메서드를 바인딩 하는 코드를 추가했습니다.
해당 기능은 이전에 만들었던 라이브러리의 버그 때문에 일정이 딜레이되었기 때문에 회사 안에서만 사용한다고 급하게 PR만 올려두고 회사에서는 GitHub에서 tar.gz를 직접 받아서 빌드하고 있었는데요.
그렇다보니 PR을 올릴때 테스트가 생략되었고 테스트 구현이 미뤄지다보니 제가 퇴사할때까지 해당 PR을 머지하지 못했었습니다.
PR을 올린지 2년이 지나던 시점에서 메인테이너가 아니셨던 다른분께서 해당 기능에 대한 테스트를 같이 구현해서 제 PR의 내용을 머지할 수 있도록 해주셨습니다.
결과적으로 2년이나 걸려서 패치를 보낸셈이 되었지만 PR을 열어두니 다른분의 도움을 받을 수 있어서 좋았습니다.
이미지 대표색을 뽑아내는 기능을 만들며 얻었던 교훈
제 첫번째 오픈소스 경험에서 회사에서 해결해야했던 문제를 오픈 소스로 만들며 진행했던 점이 아주 큰 장점으로 작용했습니다.
- 첫번째로 일단 회사에서 해결해야하는 문제를 오픈소스로 하다보니 꼭 해결해야하는 일이라서 문제해결에 대한 동기부여가 토이 프로젝트를 만들때에 비해서 쉽게 생겼습니다. 토이프로젝트의 경우 본인 스스로 동기부여의 목적을 찾아야하지만 회사 일은 제품 일정 같은 외부의 요인에 의해 목적성이 뚜렷하기 때문입니다.
- 두번째로 회사 내에서 하다보니 이미 오픈소스를 해본 경험이 있으신 분들한테 쉽게 도움을 받을 수 있단 부분도 장점이었습니다. 운 좋게 회사 내에서 오픈 소스를 메인테인 해보시거나 기여해보신 분이 있으셨고 저도 처음 패키징이나 브랜칭 전략 같은 것을 동료분에게 많이 배웠습니다.
그리고 PR을 일단 만들고나면 메인테이너나 혹은 다른 제 3자에게 도움 받을 방법이 생긴다는 점도 제 첫번째 경험에서 배운점이겠네요.
내가 취미로 하는 게임을 통해 기여하기
지금부터는 제가 흥미 위주로 진행했던 프로젝트에 대해서도 소개해보고 싶습니다. 위에서는 회사 일로써 동기부여를 받았다는 언급을 했었는데요. 저는 오픈 소스를 진행하면서 가장 중요한 것 중 하나가 문제를 끊임 없이 해결하고 싶어하는 동기 부여라고 생각합니다.
이런 측면에서 자신에게 흥미 있는 주제를 선택하는것이 가장 쉬운 방법이라고 느꼈습니다.
저는 스타크래프트2라는 실시간 전략 시뮬레이션 게임(이하 RTS)을 2010년부터 플레이 해왔는데요. 이 게임은 주로 1:1 플레이로 진행이 되고 상대방보다 제가 더 많은 자원을 획득하면서 더 많은 유닛을 뽑아 상대방의 기지를 장악하면 이기는 게임입니다.
이런 RTS 게임은 보통 플레이를 하면서 어떤 점을 잘하거나 잘못했는지 볼 수 있도록 리플레이 기능을 제공해주는데 이런 리플레이를 보면서 컴퓨터가 정량적으로 분석해주면 제 게임 플레이 개선에 큰 도움이 되지 않을까 생각해서 프로그램을 만들자고 결심했습니다.
지금은 딥마인드의 AI를 적용시킨 알파스타라는 프로젝트도 있다보니 프로그램이 분석한 결과를 통해 게임 플레이를 잘할 수 있다는 것이 증명되버린 셈입니다.. 그렇지만 처음 프로젝트를 생각했을때는 알파스타도 나오기 전이었기 때문에 참신한 아이디어라고 생각했습니다.
그래서 2014년 설날에 그런 결심을 가지고 열심히 만들긴 했습니다만 설날이 끝나고 직장을 다니기 시작하면서 자연스럽게 만들지 않게 되더라고요.
그런데 5년이 지난 2019년 설날에 게임을 하다가 패배를 맛보고 다시 이 프로젝트를 만들고 싶은 욕구가 생겼고 프로젝트를 만들기 위해서 5년이 지난 코드를 이것저것 손보기 시작합니다.
린트도 달았고 간단한 테스트도 만들었어요. 원래 책상 정리가 시간이 제일 잘 간다지만 정리를 하던 중에 큰 산을 하나 만났습니다.
s2protocol Python 3 지원을 진행하면서
s2protocol은 스타크래프트2 게임의 시간열 단위로 유닛 생산, 건물 구축 등의 게임 정보를 상세하게 리플레이 파일로부터 추출하는 라이브러리입니다.
그때 당시에는 파이썬2 지원도 슬슬 종료된다고 했었고 파이썬3로 코드 베이스를 바꾸면 좋겠다는 생각이 들었습니다.
그런데 문제는 리플레이를 시간열 기준으로 해석해주는 s2protocol이 파이썬3를 지원하지 않는다는 점이었습니다. s2protocol 라이브러리의 크기가 크지 않았고 그때 당시에 회사에서도 Python2 코드와 Python 3 코드를 전부 작성하고 있었기 때문에 패치가 금방 끝날 것 같아서 한번 작업을 해보기로 결정했습니다.
어차피 이번 설날이 지나고 나면 분석 라이브러리는 또다시 만들기 어려울 것 같다는 생각을 했었거든요.
다른 부분들을 확인하지 않고 일단 PR을 만들었습니다. 그런데 그제서야 확인해보니 라이브러리의 유지보수는 로봇이 게임 패치에 따라서 실행 가능할 수 있도록 만드는 수준에서 관리하고 있더라고요. 이 PR을 리뷰해줄거라는 큰 믿음이 생기지는 않았지만 작업한게 아까워서 일단 올렸고 설날이 끝났습니다.
다행히 오랜시간이 지나지않고 메인테이너에게 답글이 달렸습니다.
이후 몇번의 핑퐁과 추가 PR을 올리는 등의 작업이 이어졌습니다. 자신이 해당 게임 팀에서 일하지 않아서 시간 여유를 쉽게 내지 못하는 상태였습니다.
더군다나 프로젝트에는 게임 패치에 따라서 라이브러리가 따라갈 수 있도록 자동으로 생성되는 부분도 있었고, 여타 제가 알 수 없는 부분들이 있어서 제가 파이썬 3패치와 동시에 유닛 테스트 같은 부분을 보강했음에도 메인테이너가 추가로 작업을 많이 진행했고 실제로 머지 되기까지 2달정도 시간이 걸렸습니다.
s2protocol 리포지토리 기여자에 이름을 올리기까지 느낀점
제 경우엔 운이 좋게 메인테이너가 엄청 적극적으로 도움을 주어서 머지를 할 수 있었는데요. 저와 소통하던 메인테이너도 그랬듯이 보통 오픈소스 메인테이너는 풀타임으로 도움을 줄 수 없는 경우가 흔하기 때문에 코드 리뷰 정도만 받을 수 있는 경우가 더 많습니다.
이런 점을 보완하고 기여를 더 잘하기 위해서 이슈를 먼저 만들거나, 혹은 리포지토리에 이미 포함되어있는 기여 가이드라인을 참고하시는 것을 추천합니다. 메인테이너가 CONTRIBUTING.md 라던가 CODE_OF_CONDUCT.md 처럼 PR올리기 전에 먼저 읽어봐야하는 문서를 미리 준비해두는 경우가 있습니다. 그러한 경우 PR을 올리기 위해선 어떻게 해야하는지를 알려주는 부분이 문서에 적혀 있으니 이를 참고하면 좋습니다.
방금 언급한 것처럼 풀타임으로 도움을 줄 수 없기에 몇몇 리포지토리는 가이드라인을 지키지 않고 PR을 올렸을때 로봇이 검사 해서 자동으로 PR을 닫아버린다거나 하는 경우도 있으니 주의하세요. 참고 자료로 많이 사용되는 웹프레임워크인 flask의 가이드 문서를 참고로 링크해두겠습니다.
다음으로 제가 다른 프로그램을 작성하기 위해 의존하고 있던 s2protocol을 고쳤던 것 처럼 자신이 사용하는 라이브러리에 대한 패치를 만들면 좋다고 생각했는데요.
자신의 프로젝트의 라이브러리에 의존성 목록을 살펴본 후 리포지토리의 이슈 트래커로 이동하면 여러 이슈들이 있을겁니다. 이중에서도 처음 기여하는 사람들을 위한 이슈들도 따로 분류해두는 경우가 있으니 만약 이런 이슈를 찾으신다면 간단하게 진행해보시면 어떨까요?
추가로 깃헙 프로필 페이지에도 피닝할 수 있어서 뿌듯합니다.
파이콘 한국을 통해 만나게된 오픈 소스 경험
파이콘 한국은 파이썬 사용자들을 위해 여러가지 프로그램을 개최하고 있는데요. 그 중에서도 오픈 소스를 만나볼 수 있는 경험에 대해 공유하겠습니다.
오픈 소스를 직접적으로 만나볼 수 있는 프로그램이 스프린트인데요. 저는 니름이라는 프로젝트로 파이콘 한국에서 스프린트에 참여해봤습니다. 니름은 마이크로서비스 개발을 위한 IDL 컴파일러 및 RPC 프레임워크이고 전 회사에서 자유 주제로 프로젝트를 할 수 있는 스프린트 데이라는 기간이 주어졌고 이 기간동안 간단하게 만들어보다가 프로젝트를 본격적으로 시작하게 되었습니다.
같이 시작했던 동료분이 잘 리딩해주신 덕분에 꽤 긴 기간동안 만들었고 그 기간동안 파이콘 한국에서 스프린트를 진행했습니다. 심지어 스프린트 참여자와 기여자를 모으기 위해서 니름에 관련한 발표를 진행하고 홍보를 하기도 했었습니다.
제 파이콘 한국에서 만나봤던 오픈 소스 경험을 더 자세히 공유하려합니다.
파이콘 한국 스프린트
파이콘 한국 스프린트는 많은 오픈 소스를 경험해볼 수 있는 프로그램인데요. 저처럼 메인테인하고 라이브러리가 있으신 경우엔 진행자로 참여할 수도 있고, 오픈 소스에 기여해보시고 싶다면 참여자로 참여해보실 수 도 있습니다.
저는 3년에 걸쳐서 진행자와 참여자 경험을 전부해봤는데요. 이런식으로 오픈소스에 기여하는 것도 꽤 재밌는 경험이 었습니다. 스프린트에 참여하면 처음부터 혼자서 오픈 소스에 기여하는 것보다 큰 장점이 있다고 생각하는데요.
- 스프린트에 참여하면 오픈 소스 메인테이너들이 직접 어떻게 기여를 시작할 수 있을지 알려주십니다.
- 아무래도 메인테이너 입장에서는 스프린트에서 오픈 소스의 홍보도 하고 기여자도 늘리는 일석 이조의 효과가 있기 때문에 적극적으로 개입해주셔서 프로젝트를 만드는 내내 상당히 즐거웠습니다.
- 저 같은 경우는 빠른 피드백을 받을 수 있어서 좋았고, 흥미 유발을 위해서 진행자분들이 꼭 1개씩은 PR을 머지할 수 있도록 도와주시기 때문에 프로젝트에 이름을 남길 수 있어서 뿌듯하기도 했습니다.
파이콘 한국 발표
또 파이콘 한국에서는 컨퍼런스인 만큼 발표를 신청하고, 연사로 파이콘 한국에 참여할 수 있습니다.
오픈 소스 라이브러리의 특정 기능에 대한 발표 주제를 등록해두고 이 발표를 위해서라도 빨리 기능을 만들고는 했습니다. 일종의 마감일을 설정하는 역할이 되었습니다. 그렇기 때문에 파이콘 한국 발표 전까지는 꼭 그 기능을 만들어야하는 나름의 동기부여가 생기기 때문에 조금이라도 더 코드를 만들게 되었었네요.
물론 발표라는 특성상 사람들 앞에 나가서 말을 해야하고 부담이 될 수 있는 방법이라고 생각합니다. 하지만 연사로 15분 ~ 25분이나 발표하기 어렵다면 가볍게 할 수 있는 라이트닝 토크도 있으니 조금은 가벼운 마음으로 참여해보셔도 좋을 것 같습니다.
자신이 만들고 있는 혹은 기여하고 있는 오픈 소스에 대해 다른 분들의 공감을 받을 수 있으니 여러 모로 좋은 방법인 것 같습니다.
저는 파이콘 한국을 2014년부터 참여했는데요. 그때마다 발표하시는 연사분들이 멋져보이더라구요. 그래서 저도 제가 만들고 있는 오픈소스를 주제로 참여해서 좋은 동기부여 방법으로 만들 수 있었던 것 같습니다.
제가 말씀드린 프로그램외에도 파이콘 한국에서는 여러 프로그램을 운영중이니 한번씩 참여해보시는 것을 추천드립니다. 내년에는 코로나 없이 대면으로 진행할 수 있었으면 좋겠네요.
결론
앞에서 다양한 얘기들을 다루었는데 정리해보면 3가지로 요약할 수 있습니다.
- 오픈 소스를 만들고 유지하기 위해 스스로 동기 부여 할 수 있는 여러가지 방법을 찾을 수 있으면 좋겠습니다.
- 자신을 위한 작은 문제부터 해결하기 시작해도 충분합니다.
- 오픈 소스와 관련되어서 도움 받을 수 있는 다양한 방법이 있습니다.
이어서 다음 글로 파이콘 한국 2021 후원사 세션에서 발표한 주제 "회사에서 오픈 소스 라이브러리 개발을 장려하면 좋은점"에 대해서 조금 더 자세히 공유 드리겠습니다.
긴 글 읽어주셔서 감사합니다.