Open-smartwatch 릴리즈하기

Open-smartwatch 회고

OSW팀에 정식으로 합류한 지 얼마 안 되었지만 컨트리뷰션을 시작한 후 1년이라는 시간이 지났다.

그간 얼마나 성장을 했을지 그리고 더 많이 배울 수 있는 장을 넓힐 수 있었는지 기록해보려고 한다.

이 인연은 SNS에서 관심 있는 분야를 태그해서 구독하면서 시작했다. IOT나 웨어러블 등 디바이스 같은 것에 관심이 많아 태그를 했었고 언젠가부터 손목시계를 하드웨어부터 빌드하는 게시글이 눈에 들어왔다.

이는 호기심을 사기에 충분했고 바로 프로젝트에 참여하고자 정보를 수집하였다.

그 전에 한가지 설명하고자 하는게 있는데 개인 손목시계 프로젝트를 진행했었다. 하드웨어는 기성품을 사용했었으나 코드는 처음부터 작성하였다.

지금 생각하기로 가장 어려웠던 부분은 GUI 부분과 블루투스 개발 부분이었다.

추후 손목시계를 앱이랑 연동하여 알림을 알려주는 용도로 확장하였다.

이러한 프로젝트를 하고 느낀 것은 혼자서 하는 것도 같이 하는 프로젝트 속에서 더 성장할 수 있다는 믿음이 생겼다 혼자서 개발을 진행하니 코드나 아키텍쳐나 올바르게 진행하고 있는지 확신이 생기지 않았다.

협력자로 함께하면서 코드를 좀 더 자유롭게 병합할 수 있었고 본격적인 개발을 시작할 수 있었다.

지난 1년동안 프로젝트를 사용하면서 개선하고 필요한 기능들을 구체화하였다. 사용자 입장에서 그리고 개발자 입장 한 층 더 다가갈 수 있었다.

컨트리뷰터를 시작하면서 코드 분석 또한 어렵고 이 팀에서 내가 무엇을 할 수 있을지 고민을 했었는데 1년 동안 컨트리뷰터로 활동하면서 코드 기여 방법, 코드 분석, 개선 방향 등 다각도로 분석할 수 있었다.

개발자 입장에서 끊임없이 기능을 추가하는 것도 좋지만 사용지의 의견을 귀 기울이면서 사용자 입장에서 프로젝트를 바라보는 것에 중요성을 알게 되었다.

Contributor에서 Collaborator

오픈소스 활동을 하면 컨트리뷰션을 하게 되고 협력자로 업그레이드(?)할 수 있었다.

지나온 시간을 기록해보면서 어떻게 컨트리뷰션을 진행하고 어떻게 콜라보레이터로 함께할 수 있었는지 되돌아본다.

컨트리뷰션 방법

오픈소스 컨트리뷰션에는 여러가지 방법이 있어서 아래 링크를 참고하기 바란다.

Reference : Contribution type

컨트리뷰션은 대부분 시작하는 개발자나 Github를 하는 사람이라면 한 번은 해보고 싶은 활동이다. 본인 역시 해당하였고 어떻게 시작하고 어떻게 확장해 나갈지 고민이 궁금했다. 시작은 가장 가볍게 시작한다. 대부분 공통적으로 시작한 컨트리뷰션 2가지를 소개한다.

오타찾기(Typo)

가장 쉽게 그리고 가볍게 접근할 수 있지만 프로젝트나 문화에 따라 받아들여지지 않는 저장소도 있다. 본인의 경우 가장 즐겨 사용하던 오픈소스 하드웨어 플랫폼 공식 문서에서 오타를 찾거나 교정하는 작업을 시작으로 컨트리뷰션을 진행했다. 오타를 찾는 컨트리뷰션을 꾸준히 진행하여 탑 컨트리뷰터로 자리 잡을 수 있었고 이를 계기로 소스코드나 문서를 볼 때 자세하고 상세하게 보는 습관을 가질 수 있었다. 또한 공식 문서를 보는 습관을 들여 어떤 프로젝트를 진행할 때 항상 레퍼런스를 참고하여 개발에 원만한 진행을 도모했다. 개발자의 컨트리뷰션은 단연 기능개선이나 기능추가 등 소스코드를 작업하는 부분이라 생각한다. 추후 관심있는 저장소를 찾아 프로젝트를 사용하면서 기능추가/개선/성능향상 및 발견되지 않은 버그를 찾는데 주력을 가하고 있다.

번역하기(Translate)

국제적인 저장소이며 문서나 사용자와 커뮤니케이션이 있는 저장소라면 없을 수 없는 컨트리뷰션이다. 이는 로컬 사람만 할 수 있는 컨트리뷰션으로 꼽힌다. 공식 문서, 사용법 등 다양한 국적을 가진 사람들을 서포트하기 위한 프로젝트라면 꼭 존재하고 꼭 필요한 컨트리뷰션이다.

소의 꼬리만 보기

누구나 타인의 코드를 보면 이해하기까지 짧지 않은 시간이 걸린다. 그것이 규모가 커지면 커질수록 코드를 이해하는데 어느정도의 노하우를 요구하게 된다. 본인 같은 경우 규모 있는 프로젝트에 참여하려고 시도했다가 포기한 적이 몇 번 있다.

이때 한 가지 분야를 정해서 파고드는 것이 도움이 된다. 전체를 파고드는 것은 추후에 진행하고 버그가 있는 부분을 찾아서 들어간 다음에 앞뒤 코드를 살피면서 어디랑 연결되었는지 하나씩 해석하면서 버그를 색출하는 것이다.

이때 필요한 부분이 2가지가 있다.

도메인 지식

언어나 프로그래밍을 위한 베이스 지식이 필요하다. 단순하게 프로그래밍 지식을 요구하는 부분도 있으나 컴퓨터공학 지식, 깊은 하드한 분야던가 아키텍쳐 등 다방면의 도메인을 알아야 잡을 수 있는 버그도 존재한다.

프로젝트 지식

해당 프로젝트가 어떻게 작동하고 어떤 Input을 Output으로 바꾸어 표시하는지 알아야한다. 보통 소스코드를 보면 직관적으로 바라보고 해석해야 한다. 각각 문법적으로 코드를 바라보면 이해하기 어려워 프로젝트가 어떻게 작동하고 구성되었는지 파악한 뒤에 역으로 코드를 분석하여야 한다. 그 뒤에 마지막에 코드를 깊게 파고들면 이해와 분석의 속도는 이전의 배가 된다.

소를 이끄는 방법

프로젝트에 발견되지 않은 버그들을 찾아 메인테이너/오너와 함께 문제들을 하나씩 바로 잡았다. 본인 같은 경우는 프로젝트를 직접 사용해보는 병적인 증세가 있다. 사용하면서 바라보는 것은 2가지 사용자 입장에서 사용하는 것과 소프트웨어 엔지니어 입장에서 사용하는 것이 있다. 사용자 입장에서 바라본다면 사용자의 니즈를 파악할 수 있고 엔지니어 입장에서 사용한다면 코드 최적화나 버그를 발견할 수 있다.

협력자가 되다.

오랜 기간 지속적인 PR과 메인테이너를 괴롭힌 끝에 협력자로 등극할 수 있었다. Merge 권한을 가질 수 있게 되었으며 또 저장소에 전반적으로 영향을 미칠 수 있게 되었다. 이 말은 나의 행동과 코드에 신중하고 책임감 있는 행동을 기대하게 만든다. 메인테이너는 지금껏 보내왔던 Pull-request를 보며 코드를 평가해줬으며 실질적으로 저장소에 기여한 수많은 버그 색출 및 성능 향상과 더불어 많은 기여를 높이 평가하여 Merge 권한을 부여했다고 한다.

사실 올해 아니 작년 목표가 컨트리뷰터 하는 것이었는데 끝내 PR을 보내어 이러한 성과를 맺게 되어 보람차다.

콜라보레이터 메인테이너 등극

지속적인 Pull-request와 동시에 수많은 버그를 찾아내고 성능을 개선한 끝에 6월 9일 오전 12시 50분 기준으로 콜라보레이터로 등극하였다.

코드리뷰를 진행할 때, git 충돌을 해결했을 때, 발견되지 않은 버그를 찾아냈을 때, 참신한 아이디어나 기능, 버그를 설명했을 때 메인테이너는 칭찬을 아끼지 않았다.

앞으로 메인테이너로 함께하면서 프로젝트를 고도화하고 코드에 책임감과 퀄리티를 가지고 개발에 집중하고자 한다.

오픈소스 프로젝트를 사용하면서 문제를 바라보는 시선은 2가지였다.

소프트웨어 엔지니어 입장

코드를 작성하고 다시 코드를 바라보면 다른 방식으로 작성할 수 있다. 이는 영화와 같다고 생각하는데 같은 영화라도 볼 때 마다 다른 인상과 감명을 주듯이 코드도 읽을 때 마다 다른 영감과 아이디어와 시선을 선사한다. 또한 이전에 찾지 못했던 발견되지 않은 버그를 찾을 수 있는 계기가 되기도 한다.

분명 개발자는 이러한 목적을 기반으로 프로그래밍 하였는데 실제로 작동하는 것은 개발자 생각과 다르게 행동이 된다. 숫자의 매개변수라던가 논리의 오류로 Output이 원하지 않는 모습으로 표시되는게 허다하다. 그렇다고 컴파일 과정에 의존하기에는 컴파일하는 과정에서 이러한 문제가 발견되는 경우는 극히 드물다.

사용자 입장

초창기 손목시계를 만들 때 이런 생각을 했었다. “사용자가 DIY를 할 수 있게 만들면 좋지 않을까”..그러나 생각을 해보면 사용자는 크게 이런 부분에 관심이 없었다. 이러한 것을 서두로 말하는 이유는 완성된 프로젝트라도 프로젝트를 사용해보면 분명 부족한 부분이 있고 부족한 부분은 채워지고 과한 부분은 다듬어지며 사용자의 요구사항에 의해 바뀔 수 있다는 것이다.

컴파일 과정에서는 문제가 없던 코드지만 실제로 써보면 코드 상에서 발견되지 않는 충돌이나 버그를 발견할 수 있었던 것 처럼 사용하다보면 이러한 기능이 있었으면 좋곘다고 느끼는 요구사항이 발생할 수 있고 다른 방식으로 고치거나 사용자 친화적으로 프로젝트를 다듬을 수 있다.

오픈소스 기여자

개발자가 코드로 세상에 기여한다는 것은 가장 큰 메리트가 아닐까 싶다.

꾸준한 오픈소스 활동을 통해 더 나은 프로젝트들을 만들고 커뮤니케이션을 진행하고자 한다.