잔디 컨퍼런스

잔디콘

올해 코로나 때 참가하고 있던 개발자 커뮤니티에서 컨퍼런스를 개최하였다. 이때 발표 세션으로 참가하여 취준 때 인생을 갈아넣은 오픈소스 관한 이야기에 대해 세션을 맡았다. 코드 병합부터 Release 배포까지 많은 과정을 어떻게 간단하게 진행할 수 있었고 Git을 어떻게 하면 편리하게 최대한 활용할 수 있는지 정리하여 요약하는 세션도 가질 수 있었다. 처음으로 가져보는 발표 세션이라 조금 긴장했지만 개발 컨퍼런스라 재밌는 내용으로 구성되었다.

간단하게 요약하자면 코드에 개선 사항을 Pull Request로 보내면서 하나씩 수정사항을 리뷰한 끝에 병합되었고 결국 코드 메인테이너 권한까지 획득한 배우고 느낀 점을 나눠보았다.

오픈소스를 도전하고 그 열매를 맺기까지 걸린 시간과 노력 그리고 거기서 얻은 유대감 등 많은 이야기를 다뤘다.

참석 전에 다른 약속 시간과 겹쳐서 시간을 놓칠 뻔 했는데 다행히 늦지 않게 잘 도착하였다. 코드 컨트리뷰션을 진행할 때 코드리뷰와 PR을 보내게 되는데 몇번의 과정을 거치면서 어떤 것이 코드를 깔끔한 방식인지 알 수 있게 된다. 우리가 커밋할 때 남기는 메세지나 코드 라인 diff는 단순하게 장난 반 진심 반으로 저장_수정최종2_수정 이런 불상사를 막고자 하는 취지도 있지만 가장 큰 이유는 우리가 컨트리뷰션할 때 변경 사항을 가장 정확하고 군더더기 없이 관리하기 위함이 가장 큰 것으로 여겨진다.

PR을 남길 때 우리는 흔히 Update Readme 이런 식으로 파일의 변경 사항이 어떻게 변경되었는지 두리뭉실하게 기입하곤 한다. 이때 훗날 제 3가 볼 때 어떤 변경 사항이 있었는지 메세지만 보고서는 알 수 없으며 추후 유지보수 할 때 난관이 지속된다.

또한 커밋할 때 데드코드를 같이 커밋하는 상황이 빈번할 수 있는데 이때 이러한 코드를 같이 커밋하는 것 역시 git을 쓰는 이유가 무의미해지게 만든다.

if (test_value != null){
  // sample();
  run();
}

위에 예시처럼 주석처리해서 올라가는 경우가 있는데 이때 코드 관리와 시각성을 해치게 된다. 커밋하는 목적은 어떤 시점에 어떤 변경 사항이 생겼는지 제 3자가 깨끗하게 보게 하기 위함이다.

데드코드를 커밋하는 것은 이후 코드를 볼 때 시각성과 가독성을 해치는 원인이 될 수 있다. 만약에 데드코드를 만들지 않으려면 어떻게 해야 할까

if (test_value != null){
  sample();
}

만약 위와 같이 이러한 코드가 있다고 가정한다면 아래 코드로 바꾼다고 가정해보자

if (test_value != null){
  run();
}

sample()이라는 함수 대신 run()이라는 함수로 대체하였다.

추후 sample()이라는 함수를 다시 복구하고 싶을 수 있지 않냐고 한다면 diff로 확인해보면 된다.

if (test_value != null){
-  sample();
+  run();
}

위와 같이 커밋을 하면 어떤 변경사항이 생겼는지 코드 단위로 글자 단위로 커밋된다.

추후 이전 커밋으로 해당 코드를 복구하면 깨끗하게 데드코드 없이 원하는 코드만 확인할 수 있는 셈이다.

또한 커밋메세지 역시 단순하게 Update new file 이런식으로 하면 어떤 변경 사항이 있는지 확인하기 어렵다.

앞에서 언급한 것과 같이 데드코드를 염두하고 코드 한 줄 한 줄 관리한다면 아래처럼 커밋메세지도 관리할 수 있다.

core: change function method to run()

- Change the sample() method to run() method to improve it

diff --git a/coreFile.c b/coreFile.c
index gey23e3..ie9023e 100644
--- a/coreFile.c
+++ b/coreFile.c
@@ -89,7 +89,7 @@ comments:

if (test_value != null){
-  sample();
+  run();
}

위와 같이 커밋메세지와 커밋기록을 관리한다면 추후 PR을 할 때 보다 빨리 검토할 수 있으며 잠재적인 버그도 쉽게 잡을 수 있다고 본다. 커밋은 프로젝트가 진행하면 진행할수록 애자일스러울수록 관리하기 어렵고 확인하기 번거로워진다. 이때 주기적으로 또 코드를 커밋할 때 부터 깨끗하게 관리한다면 Release 할 때 Review 및 Merge 작업이 더 수월해진다고 본다.

또 컨트리뷰션은 코드를 사랑하는 마음 아닐까 싶다. 이것에 관련해서는 Raspberry Pi 커뮤니티에서 기술 문서에 대한 Contribution을 진행하였다. 제 3자가 읽을 때 이해할 수 있게 작성하고 해당 서비스에 대해 리딩만으로 완벽하게 이해할 수 있게 하는 것이 기술 문서의 존재 이유라고 생각한다.

초기에는 리눅스 커널 빌드하는 페이지를 컨트리뷰션하였다. 검색을 할 때 중간 과정이 잘렸거나 특정 과정에 대해 자세히 언급 안 된 문서들이 대개 많다. 그리고 그 정보를 위해 또 다시 서브적으로 검색이 필요한 순간이 많다. 이러한 부분이 해당 빌드 페이지에 있었다. 물론 초보자라 발견하기 쉬웠을 수 있다. 해당 페이지에 특정 명령어를 추가하는 방식으로 PR을 보냈는데 수차례의 의견 수정 끝에 메인테이너가 방향을 제시해줬다.

이후에도 기술 문서를 보면서 부족한 내용들을 컨트리뷰션하였고 기술 문서 전반적으로 typo도 캐치하였다. 이때 가장 의미 있었던 것이 기술 문서에는 우리가 알고 모르는 다양한 typo가 숨어있다. 또한 이러한 typo를 찾기 위해 기술문서 전반을 숙지해야 하는 어려움이 있을 수 있다. 컨트리뷰션 한다는 것은 어떻게 보면 코드를 사랑하기 때문에 가능한 것이라고 본다. 수많은 코드 속에서 수정사항이 필요한 코드를 찾고 이걸 수정하여 컨트리뷰션 하는 것 까지 굉장히 귀찮은 일이 아닐 수 없다.

오픈소스 프로젝트를 보다보면 어떤 코드를 어떻게 사용해야 할지 경험해가는 것 같다. 처음부터 규모있는 서비스를 밑바닥부터 코드를 작성하는 것이 아니라 오픈소스로부터 필요한 코드를 서치하고 그걸 원하는 모습으로 현재 사용하고 있는 서비스나 모듈에 잘 이어주는 작업을 보다 손쉽게 할 수 있도록 학습할 수 있는 시간이다.

지난 시간을 돌아보면 오픈소스를 시작한 여정은 쉽지 않았다. 지구 반대편에 있는 사람들과 다른 시간대에서 얘기하는 것은 어려웠고 언어에서 원활한 소통까지 쉬운게 하나 없었다. 이 시간들을 즐기면서 할 수 있었던 이유는 그 당시에 진행했던 프로젝트를 사랑했고 또한 커뮤니티와 어울리고 싶은 마음이 어려움보다 컸기 때문에 가능했던 게 아닌가 싶다.

앞으로 로드맵이 있다면 사용하고 있는 저명한 프레임워크나 툴에 기여하고자 한다. 사용하는 소프트웨어를 계속 수정하면서 개선하고자 한다.