오픈소스 응애의 험난한 컨트리뷰션 후기

대형 오픈소스에 컨트리뷰터가 되는 것은 언젠가 꼭 한번 쯤 해보고 싶다는 욕망과 함께 마음속 한켠에 고이 간직해 놓고, 오랫동안 외면해 왔던 도전 중 하나였다.
사실 오픈소스에 컨트리뷰션을 한다는 행위 자체는 누군가에겐, '엥 그게 뭐가 어려워? 그거 그냥 문서 번역이나 오탈자 기여만 해도 쉽게 해볼 수 있는건데?' 라고 말할 수 있을지도 모르는 그런 일인지도 모른다.
애초에 의미적으로만 따지자면, 코드가 공개되어 있는 레포라면 어디든 내가 PR을 올려서 머지가 되기만 한다면 그게 어떤 프로젝트이든 결과적으론 '오픈소스에 기여했다'고 할 수 있을테니까 말이다.

하지만, 내가 마음속에 품고 그리던 '컨트리뷰터'라는 단어가 가진 의미는 조금 달랐다. (컨트리뷰터의 사전적 의미를 재정의 하고 싶은 것이 아니다. 그저 내가 가지고 있었던 욕망에 대한 표현으로 봐주었으면 좋겠다.)
내가 해보고 싶었지만 그동한 해내지 못했던 컨트리뷰션은 이러했으면 했다.

• 대형 오픈소스 재단에 속하여 관리되고 있는 프로젝트
• '나 여기에 컨트리뷰션 해봤어!' 라고 했을 때, '오, 나 그거 아는데' 싶을 프로젝트
• 기여한 코드가 해당 소프트웨어의 동작에 관여하는 기능적인 코드일 것
  명확하게 생각하고 있었던 건 아니지만, 글을 쓰는 시점에 내가 왜 '컨트리뷰터'가 된다는 것에 그렇게 심리적으로 어렵게 생각하고 있었는지 고민해보니, 위와 같은 조건들을 은연중에 생각하고 있었다고 느꼈다.

이 글은 상상만 하던 오픈소스 컨트리뷰터가 된 후의 생생한 후기를 스스로 기록하면서, 혹시 나와 비슷한 심리적 어려움을 가지고 시작하지 못했던 사람들에게 용기가 되었으면 하는 마음을 담아 남기는 기록이다.

어디에 뭘 어쩌다 했냐

• TL;TR
  한줄 요약하자면, Argo Workflows의 LifeCycleHook에 있는 버그를 수정하는 기여를 했다.

내가 이번에 기여하게 된 프로젝트는 Argo Workflows라는 프로젝트였다.
Argo Workflows는 CNCF라는 쿠버네티스, 프로메테우스와 같은 클라우드 네이티브한 프로젝트들이 속한 재단의 프로젝트 중 하나인데, 컨테이너 기반으로 동작하는 workflow엔진이다.

쉽게 설명해서, Job간에 종속성을 부여하여 순서대로 실행하거나, 병렬적으로 실행될 수 있도록 보장하는 툴인데, 컨테이너 기반이며 쿠버네티스에서 동작한다는 특징을 가지고 있다.
나는 회사에서 배포시스템을 개발하고 있는데, 이 때 배포에 관한 작업을 처리할 때 엔진으로 Argo Workflows의 기능을 적극적으로 활용하고 있다.

Argo Workflows를 개발하는 시스템과 연동하기 위해서 LifeCycleHook이라는 기능을 활용했는데, LifeCycleHook은 Job들의 상태(Running, Succeeded, Failed..)가 바뀔 때 마다 일정 조건에 따라 예약 된 Job을 트리거 할 수 있는 기능인데, 나는 각각의 Job들이 끝날 때 마다 webhook을 날려서 workflow의 동작 상태를 확인하기 위한 용도로 활용했다.

그런데, 기능을 활용하다 보니 해당 기능에 버그가 있다는 사실을 발견하게 되었다. 발견한 버그는, 특정 상황에 LifeCycleHook의 Running 상태에 대한 hook이 동작하지 않는 버그였다.

사실 처음에는 으엑? 이게 안돼? 버그 제보 해서 고쳐달라고 해야하나? 이렇게만 생각하고 프로젝트 레포에 이슈만 제보하고 말 생각이었다.

그런데 같이 일하는 동료분이 지나가는 말로 '어? 그거 컨트리뷰션 기회 아니에요?' 라고 하는데, 그 말이 귓가에 계속 맴돌았다.
그 이야기를 해준 동료는 outsider라는 필명으로 평소 개발자 커뮤니티와 오픈소스에 많은 기여를 하시는 분이었는데, 왜인지 평소였다면 그냥 듣고 제보만 하고 말았을 일이었을텐데 그분이 그렇게 말해주니 나도 할 수 있을까? 싶은 용기가 생겼던 것 같다.

Argo 프로젝트의 멘토링 제도

하지만, 막상 컨트리뷰션을 시작하려고 하니 굉장히 막막했다. 생성되어 있는 이슈 갯수만 700여개가 가뿐히 넘고, CNCF의 슬랙 채널에 들어가 보았더니 온통 영어로 소통하고 있는데 어디서부터 시작해야 할지 가늠이 잡히질 않았다.
이런 대형 프로젝트에 컨트리뷰션을 해보는 경험이 처음이었던 나로써는 굉장히 많은 규칙들이 있을것만 같은 세상에 막막함과 함께 조금 겁이 났었던거 같다.

우선은 이슈부터 생성해 봐야겠다라는 생각이 들어서 이슈를 생성하러 들어갔더니 회사에서 작업할 때에는 보지 못했던 생소한 UI가 나를 맞이했다.
이슈를 생성할 때, 목적에 맞는 템플릿으로 분류해주기 위한 화면인듯 했는데, 이슈 생성화면을 이렇게 커스터마이징도 가능하구나, 하는 생각을 했다.
그 와중에 눈에 띄는 항목이 있었는데, 바로 Mentoring request였다!

이게 뭐지? 싶어서 들어가 봤더니, 해당 프로젝트에 컨트리뷰션이 익숙하지 않은 컨트리뷰터들을 위해서 멘토를 매칭해주는 엄청난 제도가 있다는 사실을 알게 되었다.
멘토링 요청 이슈 티켓에는 멘토링 제도에 대한 자세한 내용이 기록된 문서도 함께 링크되어 있었는데, 문서의 내용에 따르면 해당 프로젝트에 컨트리뷰션하기 위한 가이드를 해줄 뿐 아니라, 프로젝트의 코드의 주요 구조, 개발 환경을 실행하기 위한 방법들을 가이드 해줄 뿐 아니라 프로젝트를 구성하고 있는 언어인 Golang, Typescript, React에 대한 이해가 부족한 사람을 위해 가이드를 제공하고 적절한 이슈를 골라주기도 하는 매우 상냥한 제도였다!

멘토링을 요청하는 이슈 템플릿에는 Go, Kubernetes, React, TypeScript 등에 관한 숙련도를 작성하고, 개선해 보고 싶은 이슈를 함께 제출 할 수 있도록 되어 있었다.

그렇게 나의 첫 이슈 생성은 멘토링 요청과 함께 생성하게 되었다.
이슈를 생성하면서 또 하나 기억에 남았던 것은 버그 제보시에는 개선하는 사람을 위해 필요한 핵심적인 정보들을 남길 수 있도록 티켓 템플릿이 잘 만들어져 있었다는 점이었다.

Argo Workflows프로젝트의 이슈 생성 과정과 멘토링 시스템을 경험해 본 입장에서, 특별한 설명 없이도 컨트리뷰션을 처음 하는 사람이 알아야 할 정보들을 자연스럽게 수집할 수 있도록 가이드가 정말 잘 되어 있다는 느낌을 받았다.
무엇보다 멘토링 시스템은, 큰 프로젝트에 컨트리뷰션이 처음이었던 나에게 '너가 좆밥이어도 괜찮아. 우리가 도와줄테니 겁먹지 말고 시작해보렴!'과 같은 느낌을 주어서 처음 시작하는데 굉장히 큰 용기를 주었던 것 같다.

마음가짐의 문제

사실 이슈 생성과 멘토링을 요청한 뒤에도 한참동안 나는 컨트리뷰션 활동에 뛰어들지 못했다.
핑계를 대자면 멘토링 요청을 한 뒤에 무려 한달동안이나 내 멘토링 요청 티켓은 외면당하고 있었고,
감히 나 따위가 PR을 올려도 되는걸까?
PR 제목은 어떻게 해야하지? 커밋 메시지는?
아직 개발환경 띄울줄도 모르는데, 의존성이 많아서 엄청 복잡해 보이고 잘 안되네... 어떻게 해야하지?
멘토가 배정되면 개발환경 띄우는 방법도 다 알려준다고 하던데 멘토가 배정될 때까지 그냥 기다릴까?
와 같은 질문들을 스스로 삼키다가 결국 시작도 하지 못했었다.

그렇게 작업에 뛰어들 엄두도 내지 못하고 기다리기를 무려 한달, 이슈를 제보하고 멘토링 요청을 했었다는 것도 잊어가고 있을 즈음, 나에게 드디어 멘토가 배정되었다.

나는 멘토가 배정되면 나에게 이것 저것 알려주는 건줄 알았는데, 배정된 맨토는 다짜고짜 draft PR부터 생성하라고 했다... ㅋㅋㅋㅋㅋ
처음에는 이럴거면 멘토링 왜하는거야? 하는 생각도 했지만 생각해보니, 내가 어느정도 수준인지도 모르는데 마냥 알려주는 것 보다는, 내가 뭐라도 시도해보고 모르는 부분을 물어봐야 멘토도 알려줄 수 있겠구나 싶어서 우선 개발환경을 띄우는 것 부터 해보기로 했다.

막상 등떠밀려서 해보기 시작하니, 컨트리뷰터를 위한 가이드도 굉장히 잘 써져 있어서 조금만 삽질해보면 생각보다 쉽게 개발환경을 띄울 수 있었다.
(상당히 많은 의존성에도 불구하고 개발환경을 쉽게 띄울 수 있었던 이유는 dev container라는 장치 덕분이었는데, 글 마지막에 컨트리뷰션 과정에서 기억에 남았던 장치들을 정리하면서 소개하겠다.)

시도해 보고 막히는 부분이 있으면 질문하려고 가이드를 보며 더듬더듬 하나씩 해보았는데, 개발환경을 띄워보고, 로직을 분석하고, 개선 방법을 고민하고, 형식에 맞는 커밋을 작성하고, PR을 생성하는 것 까지 또 한달정도가 걸리긴 했지만 결국 가이드의 도움만으로 별다른 질문 없이 성공적으로 해낼 수 있었다.

지나고 보니 나 혼자 지레 겁먹고 어렵게 생각한 나머지 시작하지 못했을 뿐, 충분히 나 혼자 시도할 수 있는 일이었던 것이었다는 것을 깨닳게 되고 머리가 띵 했다.

보이지 않는 서열

지금와서 보면 멘토는 아무 쓰잘데기가 없었다.

(장난이다)

정작 나는 이슈 올리고 PR을 올리기까지 무려 두달이나 소비해 놓고선, 막상 PR을 생성해 놓고 나니까 왜 이렇게 리뷰를 안해주는지 애가 탔다.

내가 이 프로젝트에 컨트리뷰션하면서 느낀 것은, 어자피 언젠가는 되니까 너무 조급해 하지 않고 메인테이너들의 손길이 닿기를 기다려야 한다는 것이다. (내가 아무리 재촉해도 결국 자기들이 보고 싶을 때 본다 ㅋㅋㅋㅋ)

내가 배정 받았던 멘토는 나를 굉장히 방치형으로 키웠는데(사실 이게 나에게 굉장히 도움이 되었다), 심지어는 리뷰도 직접 해주지도 않고 리뷰를 하청 때렸다.

리뷰를 하청받은 한 리뷰어는 내 코드를 리뷰 하다가 다른 암시적 버그를 발견해서 나에게 수정 요청을 했었는데, 막상 다 수정해놨더니 그새 새로운 PR을 만들어서 코드를 머지해 버려서, 덕분에 영문도 모르고 conflict난 부분을 해결하느라고 당황하기도 했다.
(나중에 알고보니 리뷰 하청을 준 것이 아니라 좀더 상위 권한을 가진 리뷰어에게 요청한 것이었다.)

그런가 하면 리뷰어로부터 기껏 승인을 받아 냈더니 갑자기 처음보는 대머리가 나타나서 테스트를 추가해 달라고 하더니 영영 나타나지 않았다.

명심하자. 만약 오픈소스 프로젝트에 기여를 하게 되었는데, Collaborator라는 딱지가 붙어있는 사람이 말을 걸었다면, 절대 그 사람에게 거역해서는 안된다. 그저 복종이 답이다. Collaborator는 그 프로젝트의 신이다.

Nobody < Contributor < Member < Collaborator 정도로 생각하면 된다.

저 때쯤 되어서 나는 지쳐서 이제 슬슬 코드가 머지 되었으면 하는 마음이었는데, 나의 멘토에게 이번 PR은 머지하고 테스트코드 추가는 다른 PR에서 하고 싶다고 징징 거렸는데, 읽씹당했다.

울면서 테스트 코드를 작성하려고 보니까, 이미 테스트가 다른 이슈로 인해 고장나서 전체 주석처리 되어 전혀 동작하지 않고 있었다. 그런김에 혹시나 해서 이거 진짜 나중에 하면 안되냐고 한번 더 징징거려 봤지만 단호히 거절 당했다.

참고로 같은 Member라도 권력은 천차만별인데, 어떤 Member는 승인(Approve)에 대한 권한이 있기도 하고 없기도 하다. 권한이 있는 Member는 걸려있는 Change Requests 딱지를 제거하고, 혼자서 코드를 머지해 버리기도 했다.

리뷰어들의 권력을 짐작해 보고 싶다면, 해당 프로젝트의 contributors 통계를 보여주는 페이지에서 commit을 많이 한 순서를 보면 대충 느낌을 알 수 있다.

참고로 의외로 하위권은 경쟁이 치열하지 않아서 PR 4개정도만 머지하면 100등 안에 들 수 있다.

얼떨결에 PR 1 + 1

테스트 코드를 추가하라는 수령님의 지령을 따라 테스트를 작성하다 보니 뜬금없이 새로운 버그를 발견헀다.
기왕 작성하는거 테스트 한번 완벽하게 짜보자! 하고 수정한 기능 뿐 아니라 lifecycle hook에 관한 모든 케이스를 커버할 수 있는 케이스를 방대하게 작성하려고 했던건데, 작성한 테스트 때문에 새로운 버그를 찾아버렸다.

진짜 이 때, 그냥 내가 수정한 부분에 대한 테스트만 코드로 올리고 모르는 척 할까 한 100번정도 고민했다.
하지만, 그러기엔 너무 멋이 없는거 같아서 버그가 있는 부분에 대한 테스트는 주석으로 올리고 솔직히 고백했다.

나보고 새로운 버그에도 관심있냐고 물어보길래 멋있어 보이고 싶어서 그렇다고 했다.

그랬더니, 새로 발견한 이슈도 어자피 니가 할꺼니까 이 PR은 새 이슈 너가 해결하고 나면 머지하는게 어떠겠냐고 물었다. 진짜 악덕 사업주가 따로 없었다.
나는 진짜 정신이 나갈 것 같았지만 선택권이 없었다. 그냥 승인해달라고 징징대도 안해줄 것 같았다.
그래서 그러겠다고 했다.

결국 덕분에 나는 첫 기여를 동시에 두개 PR로 하게 되었다.

next step?

우여곡절 끝에 길고 길었던 첫 컨트리뷰션이 끝나고나니, 그래도 내 코드를 리뷰해주고 지켜봐 주었던 사람들에게 고마운 마음이 들었다. 특별히 해준건 없었던 멘토였지만, DM으로 한번씩 응답해 주기도 하며 나와 소통해 준 것 만으로도, PR을 올려달라고 깃발을 들어준 것 만으로도 나 혼자 참여하고 있는게 아니라 누군가 이끌어 주고 있다는 느낌을 받아서 여정을 성공적으로 마칠 수 있었다고 생각했다.

멘토는 DM으로 기여한 내용들이 꽤 좋았고, 다음 단계를 위한 논의를 zoom으로 이야기 나누어 보자고 미팅을 요청했는데, 이번주에 예정되어 있다.

기억에 남는 장치들

프로젝트가 꽤나 복잡한 구조를 하고 있었음에도 불구하고, 컨트리뷰션을 하는 과정 내내 여러 시스템들 덕분에 크게 해매거나 불안해 하지 않고 참여할 수 있었다.
컨트리뷰션 가이드에서 원하지 않는 변경사항들은 가능한 자동화된 시스템들에 의해 미리 감지되어 내가 실수하지 않도록 방지해 주었기 때문이다.
그래서 이 글의 마무리로 기여하는 과정에서 인상 깊었던 몇가지 장치들을 소개해 보려고 한다.

devcontainer

MS쪽에서 만들고 관리하는 듯한 이 기술은 이름에서도 유추할 수 있듯이 개발환경을 컨테이너를 활용해 편리하게 격리하기 위한 기술적인 스펙을 제공한다.

.devcontainer/devcontainer.json 경로에 설정 파일을 생성하여 관리할 수 있고, 이 설정을 통해 vscode나 github codespace에서 개발을 수행할 때 아주 편리하게 개발환경을 의존성들과 함께 격리하여 구성할 수 있다.

원리는 간단한데, 개발환경의 베이스 이미지가 될 환경을 기준으로 repo의 코드와 연관된 디렉토리를 컨테이너 내부로 마운트하고, 개발 과정에서 필요한 의존성들을 사전에 준비된 스크립트에 따라서 몽땅 설치해주는 방식이다. 설정파일도 굉장히 단순해서 한번 보면 바로 의미를 파악할 수 있다.

내가 기여했던 Argo Wokrflows를 기준으로 예시를 보여주자면 .devcontainer 폴더는 이렇게 두개의 파일로 구성이 되어있다.

가장 중요한 devcontainer.json 파일을 보면 처음 생성될 때 pre-build.sh를 실행한다는 내용과, 개발환경에 포함될 go, node, python 등의 버전을 명시하여 제공한 것을 볼 수 있다.

{
  "image": "mcr.microsoft.com/vscode/devcontainers/base:ubuntu",
  "features": {
    "ghcr.io/devcontainers/features/go:1": {
      "version": "1.19"
    },
    "ghcr.io/devcontainers/features/node:1": {
      "version": "16"
    },
    "ghcr.io/devcontainers/features/docker-in-docker:2": {},
    "ghcr.io/devcontainers/features/python:1": {}
  },
  "hostRequirements": {
    "cpus": 4
  },
  "onCreateCommand": ".devcontainer/pre-build.sh",
  "workspaceMount": "source=${localWorkspaceFolder},target=/home/vscode/go/src/github.com/argoproj/argo-workflows,type=bind",
  "workspaceFolder": "/home/vscode/go/src/github.com/argoproj/argo-workflows"
}

pre-build.sh에는 개발 과정에서 반드시 필요한 의존성(k3s, kubectl ...)들을 설치하는 쉘스크립트가 들어있다.

#!/usr/bin/env sh
set -eux

# install kubernetes
wget -q -O - https://raw.githubusercontent.com/k3d-io/k3d/main/install.sh | bash
k3d cluster get k3s-default || k3d cluster create --wait
k3d kubeconfig merge --kubeconfig-merge-default

# install kubectl
curl -LO https://dl.k8s.io/release/v1.26.0/bin/linux/amd64/kubectl
chmod +x ./kubectl
sudo mv ./kubectl /usr/local/bin/kubectl
kubectl cluster-info

# install kit
curl -q https://raw.githubusercontent.com/kitproj/kit/main/install.sh | sh

# download dependencies and do first-pass compile
CI=1 kit pre-up

kitproj/kit

Argo Workflows 프로젝트의 개발 환경을 구성할 때 활용되는 pre-build.sh의 내용은 이상하리만치 짧았는데, 왜 그런가 했더니 프로젝트의 메인테이너중 한명이 만든 것으로 보이는 kit 라는 툴을 통해 의존성들을 설치하는 스크립트 대부분을 대신했던 것이었다.
이 툴은tasks.yaml 이라는 별도의 스펙을 통해 컨테이너들을 의존적으로 실행할 수 있도록 하는데, docker-compose와 같은 툴의 컨셉에서 영감을 받아 만들었다고 한다.

아래와 같이 쉘 명령들을 의존관계에 따라 실행하도록 선언파일을 제공하는데, 쉘스크립트를 보다 체계적인 방식으로 관리할 수 있다는 느낌이 들어서 마음에 들었다.

apiVersion: kit/v1
kind: Tasks
metadata:
  annotations:
    help: |
      Install `kit` by following https://github.com/kitproj/kit#install.

      Run `kit up` to start argo.
      - `env PROFILE=mysql kit up` to start with MySQL.
      - `env PROFILE=plugins ARGO_EXECUTOR_PLUGINS=true kit up` to start with plugins.
      - `env PROFILE=sso ARGO_AUTH_MODE=sso kit up` to start with SSO.

      The app will be up-and-running between 15s and 1m later (if hot compiled or cold). 
      Any changes made to the source code will be automatically recompiled and the app restarted, typically within a few seconds.
  name: argo-workflows
spec:
  tasks:
    - name: go-deps
      command: go mod download
      mutex: downloads
    - name: install
      command: sh -c "make install PROFILE=$PROFILE"
      env:
        - PROFILE=minimal
      dependencies: go-deps
      watch: manifests
      mutex: docker
    - name: build-controller
      command: make ./dist/workflow-controller
      watch: cmd/workflow-controller config errors persist pkg util workflow
      dependencies: go-deps
      mutex: build
    - name: port-forward
      command: ./hack/port-forward.sh
      ports: 9000
      dependencies: install
    - name: controller
      command: ./dist/workflow-controller
      dependencies: install build-controller port-forward
      env:
        - ARGO_EXECUTOR_PLUGINS=false
        - ARGO_NAMESPACE=argo
        - ARGO_NAMESPACED=true
        - ARGO_MANAGED_NAMESPACE=argo
        - ARGO_LOG_LEVEL=info
        - ARGO_REMOVE_PVC_PROTECTION_FINALIZER=true
        - ARGO_PROGRESS_PATCH_TICK_DURATION=7s
        - DEFAULT_REQUEUE_TIME=1s
        - LEADER_ELECTION_IDENTITY=local
        - ALWAYS_OFFLOAD_NODE_STATUS=false
        - OFFLOAD_NODE_STATUS_TTL=30s
        - WORKFLOW_GC_PERIOD=30s
        - UPPERIO_DB_DEBUG=1
        - ARCHIVED_WORKFLOW_GC_PERIOD=30s
      ports: "9090"
#...이하 생략

stale 봇

일정 기간동안 pr이나 이슈가 방치되면 경고를 하고 자동으로 close 시키는 정리 봇이다.
github marketplace에서 무료로 설치하여 사용할 수 있다.

DCO 봇

Developer Certificate of Origin(DCO)라는 개발자 원산지 증명(?)을 위한 방식이 있는데, 쉽게 설명해서 해당 기여를 내가 했다는 사실을 간편하게 증명하고 보장하기 위한 간편 인증이다.

DCO에 따라 내 흔적을 남기고 싶다면 Signed-off-by로 시작하는 메시지를 커밋 메시지의 첫줄에 붙여줘야한다.

Signed-off-by: GeunSam2 <rootiron96@gmail.com>
This is my commit message.

git cli에서는 -s 옵션을 줘서 DCO를 위한 커밋메시지를 쉽게 생성할 수 있도록 아에 기능도 제공한다.

뿐만 아니라 DCO봇도 무료로 설치해서 사용할 수 있는데, PR이 머지 되기 전에 필수 체크 항목으로 commit 메시지가 DCO를 위한 형태를 하고 있는지 검사할 수 있다.

git hook

git은 ./git/hooks/라는 디렉토리를 활용해서 특정 상황에 특정 스크립트를 실행할 수 있도록 하는 hook이라는 기능을 제공하는데, git 저장소를 생성하고 .git/hooks/ 디렉토리에 접근하여 보기만 해도 상황별 예제 파일들을 확인해 볼 수 있다.

예를 들면 pre-commit 같은 스크립트를 생성하면 커밋을 수행하기 직전에 해당 스크립트부터 실행하도록 강제해서 커밋 메시지가 DCO를 따르는지 미리 체크하고 커밋하는 행위를 방지할 수 도 있다.

영광의 순간

이제 당초에 이 컨트리뷰션을 시작했던 이유에 대한 결과를 수확할 시간이었다.

회사에서 버그가 있는 기능을 우회해서 사용하고 있었는데, 내가 컨트리뷰션한 개선이 포함된 배포버전으로 호다닥 업그레이드 해버리고 코드까지 수정해버렸다.

개선 코드가 머지될 때에는 10년 묵은 체증이 쑤욱 내려가는 기분이었다.

끝난줄 알았지?

바로 위에서 엔딩을 했으면 정말 완벽했을텐데... 사실 버그 수정으로 인해 편안해졌던 코드는 불과 하루만에 다시 원복되었다.

이유는 또다른 버그가 발생했기 때문이었는데, 예전 버그는 트리거 되어야 하는 훅이 트리거 되지 않는 종류의 버그였다면, 이번에 새로 발생한 버그는 트리거 되면 안되는 훅이 트리거 되어버리는 버그였다.
완벽하게 작성했다고 생각했던 테스트에서도 트리거가 잘 되는지만 테스트를 했지, 트리거 안되야 할게 트리거 되는건 테스트하지 못했었다.
그래서인데 아마 또 관련하여 컨트리뷰션을 하러 가야하지 싶다.

후기

어찌 되었든 쉽지 않았지만, 첫 컨트리뷰션을 성공적으로 마치고 나니 마음속에 담아두고 있었던 버킷리스트를 하나 지워낸 것 같아서 마음이 너무 후련했다.
사실 컨트리뷰션에만 적용되는 사항은 아닐 것 같지만, 막상 제대로 시작하고 나니 처음에 두려워 했던 것 보다 어렵지 않았다. 항상 새로운 도전을 마친 후에 비슷한 느낌을 느끼고 경계하려고 하면서도, 아직 모르는 영역에 대한 두려움이 나를 게으르게 만드는 것은 쉽게 이겨내기 어려운 것 같다.

하지만, 나 또한 누군가의 한마디에 용기를 얻어 이 모든 과정의 첫 계단을 밟기 시작했던 것처럼, 나도 누가 될지 모르지만 아직 마음속 한켠에 담아두고 실행에 옮겨보지 못한 누군가에게 이 글이 한발자국 내딪을 수 있는 동기가 되기를 기원하며 마무리 지어본다.

후기 뒤의 후기

글을 쓰는 시점에는 계획에 없었는데, 오픈소스 컨트리뷰션 아카데미라는 굉장히 좋은 행사에 Argo Workflows를 주제로 멘토가 되었다.
오픈소스 컨트리뷰션 아카데미는 멘토와 멘티 여러명이 짝을 지어서 합을 맞추어 오픈소스에 기여해 볼 수 있는 경험을 제공해주는 굉장히 좋은 취지를 가진 행사이다.

2년 전쯤에 멘티로 참여해서 많은 도움을 받았던 행사인데, 멘토로 다시 참여할 수 있게 되어서 정말 기쁘다.
글 올리면서 다시 글을 읽어봤는데, 컨트리뷰션이 험난했던 경험만 적혀있는데...
사실 컨트리뷰션을 쉽게하려면 얼마든지 쉽게도 할 수 있다. 문서 수정이라던지..
여튼 그래서 혹시나 이 글을 통해 올히려 겁을 먹지는 않았으면 하는 바램이다.
여튼 오픈소스 뭐시기 흥해라!