오픈소스 기여모임 8기 오프라인 밋업 참석 후기

 

인제님이 운영하시는 오픈소스 모임 오프라인 밋업에 참석했다. 나는 이번 기수에도 저번에 했던 것과 동일하게 spring-cloud-aws에 기여했다. 저번에는 오류 픽스와 간단한 파라미터 추가였다면 이번엔 조금 난이도가 있는 피쳐 개발로 넘어왔다. 이 소개는 다음에 하고 이번 모임에는 이미 각자가 기여한 오픈소스에 PR을 하고, 머지까지 하신 분들이 발표를 진행해 주셨다.

 

스무명 남짓 모여서 아담하게 한 밋업이라 꽤 재밌게 진행됐다.

---

첫 발표 

스프링 카프카와 아파치 카프카에 기여하신 분이 발표를 해주셨다. 5월에만 7건 PR 처리를 하셨는데, 피쳐랑 버그 픽스를 다양하게 진행하셨다. 특이한 건 이슈를 만들기도 하고, 이슈를 진행하다 별도의 버그를 찾아 기여하기도 하셨다. 현재 spring-cloud-aws에서 sqs 위주로 작업 중인데, 언젠가 카프카로 넘어갈 계획이 있어서 꽤 재밌게 들었다.

 

기여할 때 배운 점들

- 커밋 메시지를 작성하고 PR을 차라리 간단히 작성해라. 리뷰어가 편함

- 기술문서는 최대한 중립적으로 작성(You, I, we, Please 같은 문구 제외)

- 프레임워크 기여 할 때, 내부 구현은 블랙박스 처리하는게 좋다.

- 새로운 의존성을 추가하는 것을 신중해야함. 스프링 카프카의 경우 아파치 카프카에 의존 중인데, 이럴 경우 의존성 패키지의 버전도 잘 봐야한다.

 

그리고 기여했던 것 중 몇 가지를 소개해주셨다. 그 중에 익셉션 로그만으로 이슈를 트래킹했는데, 결론은 코드 한줄로 이슈가 해결됐다. 구체적인 사례없이 익셉션 로그만으로 이슈에 근본적인 문제를 찾기는 정말 어려운 일었을텐데 디버깅으로 하나 하나씩 파보고 의존성 코드(차파치 카프카)까지 올라가는 과정이 있었다고한다. 

 

짧은 기간 안에 카프카를 디깅할 수 있었던 방법? 하나의 레포에서 기여를 오래하고 목표를 잡고 하면(커밋 등수 안에 들기 등) 좋다.

---

두번째 발표

휴학 중인 대학생 분이었다. 기술적인 주제보다는 소프트하게 진행. tldraw 라는 디자인 시스템 관련 툴에 기여함.

 

- 쉽고 작은 작업이라도, 그것이 모이면 큰 스노우볼

- 평소 못한 경험을 오픈소스로 경험할 수 있다(국제화, 디자인시스템 등).

- 내 코드가 수만명에게 선한 영향력을 미칠 수 있다

- 생각보다 별거 없다. 메인테이너가 문제를 제기하고 기여자는 보조자일 뿐..

 

발표자 분이 대학생인데, 이런 인사이트를 가질 수 있다는게 꽤나 놀라웠다. 자신이 성장할 수 있는 환경을 만들어 두는 게 정말 중요한데 벌써 그런 발판을 만들어 둔 것 같아 대단하다는 생각을 했음.

 

오픈소스를 기반으로 채용 제안이 올 정도이니 적극적으로 해보면 좋을 듯? geek 한 취미로! 

---

세번째 발표

인사담당자에서 2020년에 당근 백엔드 개발자로 전향하신 분.

 

오픈소스 컨트리뷰터의 7단계

기여 자체가 막막 - 도큐먼트성 이슈 - 누군가가 방향성 잡아준 이슈 기여 - 스스로 기여 - 직접 논의 - 스스로 이슈 등록 - 메인테이너

 

좋은 이슈를 선점하겠다는 목표 : 공급이 많거나 수요가 적어야함 ! > 이제는 이슈들이 많이 소진되었다. 그래서 대안은?

2순위를 노리자 - 공급과 수요가 둘다 많은 경우

메인테이너가 자주 이슈를 등록하거나 태깅을 달아주는 프로젝트도 좋다. 그러나 메인테이너가 태깅을 안하는 경우가 있는데, 이럴 때는 athor를 검색해서 자주 등록하거나 메인테이너가 작성한 이슈를 위주로 찾아서 하는것도 방법

 

신선한 이슈를 빨리 캐치하기 - 분류되자마자(자주 들어가기) or 분류되기전에(이름 익히기)

묵은 이슈 줍기 - 할당받은 사람이 잠수한 이슈, 뒤늦게 논의가 진전되는 이슈

미래 이슈를 잘 확인하기 - 의존성의 특정 버전까지 기다려야하는 경우

 

별도의 notion을 만들고 이슈와 PR 상태를 관리하면 좋다고 하심.

---

네번째 발표

오픈소스 선정기준 : 내가 관심이 있거나 사용자가 많은 오픈소스 위주로 한달 기준으로 메인테이너의 관심사가 있어보이는 이슈

첫 기여여서 쉽고 명확한 이슈를 선정하려고 했음

 

프론트 쪽 오픈소스는 라이브러리 버전이 맞지 않는 이슈가 많아보인다..

테스트쪽에선 사용자의 로케일에 관련된 이슈도 있을 수 있음

 

2번의 메인테이너와 22번의 채팅 후 느낀점 : Why - How - What(Gloden Circle)이 중요.. Why가 가장 중요하다.

---

다섯번째 발표

비전공자에서부터 개발자를 시작해 오픈소스 기여를 많이한 실제 지인의 발표.

 

- 오픈 소스의 변경은 작으면 작을수록 좋다.

 

FE는 픽셀하나 정렬하나도 이슈가 되고, 컨벤션이 있을 수 있으니 조심해야한다.

 

오픈소스 기여를 통해 느낀 것들 : 한달간의 이슈를 다뤘는데 Closed 됐을 때 내가 기여한게 정말 없을까?를 고민해봐야한다. PR을 수십개 다뤘지만, 보여지는 것 외에 Closed도 많으니 이를 통해 배우는 것들이 중요하다. 오픈 소스에 기여하고 있다는 자체에 대한 고민을 해야함. -> PR이 목적이 아니라 이슈를 닫는게 목적, 팀의 이슈를 줄이는게 목적이 될 수 있다.

 

PR이 Closed 됐다고, 머지가 되지 않았다고 단순히 멈추지 말고 경험은 남으니 꾸준히 기여하는 것을 목표로 하는게 좋을 것 같다. 

---

여섯번째 발표

log4j2에 기여하신 분. PR 10개를 만들기가 본인의 목표를 두고 멘토링을 진행했다고 하심. 한달동안 정말 10개 PR를 만드셨음 

10개 중 절반 이상이 머지된 상태라고 하셨다.

 

인터페이스를 수정할 때, 하위 호환성을 반드시 고려하자.

 

오픈소스는 막상해보면 어렵지 않으니 꾸준히 하는게 중요!

---

일곱번째 발표

PR 눈치게임. 몇 달 씩 밀리는 오픈소스들은 뺏어가도 되는 경우가 종종 있다. 할당받은 사람이 하고 있다고 계속 하고 있다고 댓글을 달아도 PR 먼저 올리면 리뷰를 먼저 받는게 어찌보면 당연하다. 눈치를 잘 보다가 쫄지말고 PR을 올려보면 머지가 될 수 있다.

 

정말 짧지만 임팩트 있던 발표였다.

---

여덟번째 발표

spring-ai에 기여를 많이 하시고, 발표도 많이하시는 종훈님의 발표.

 

AI 부분이 파이썬에서 강세이지만, 요새는 API로 제공되는 AI 기능들이 많기 때문에 스프링에서도 충분히 핸들링 할 수 있다!

이번에는 RAG에서 사용되는 Vector Database와 관련된 이슈를 주제로 발표를 진행해주셨음

 

임베딩 필드가 고정적인 이슈에 대응하기 위해 Record 객체를 Map으로 변경했는데, 기존 프로젝트가 깨지는 일이 발생한다는 연락이 와서 놀랬다. 알고보니 변경된 Map에 의한 문제가 아닌 추상화된 클래스에 의한 하위호환성 문제였음

 

내가 머지한 코드로 인해 발생한 문제인 줄 알아서 철렁했던 경험. 롤백하려는 PR 코드도 필요 없어서, 삭제하고 추가 문서화 작업을 진행했다. 

 

다양한 상황과 다양한 사람과 일하며 다양한 해프닝이 벌어질 수 있다. 오픈 소스는 하위호환성 문제를 항상 고려해야한다. Map으로 공개할때 다양한 테스트와 케이스를 고려해줘야한다.

 

나는 AWS와 AI쪽 관심이 많아서 BedRock 부터 파보고 기여해볼 예정이다. 도움이 필요할 경우 연락을 드려봐야겠다..

---

아홉번째 발표

이번에도 학생 분이 발표했다. 

 

GC가 없는 러스트에 관심이 생겨 이슈를 보다보니 문서에 깨진 링크가 있어서 이걸 수정하는거부터 시작하게 됨.

 

러스트 이슈 중에는 이슈가 해결됐으나 테스트를 만들어야하는 이슈들이 있는데(태그가 따로 부여됨), 그 작업을 진행함.

 

릴리즈 버전과 에디션 버전이 있는데, 에디션 버전은 하위호환성을 보장하지 않는다. 에디션 버전은 배포 간격이 더 길다.

 

배운점

러스트는 독특한 머지 전략을 사용 -  여러 PR을 묶어서 한번에 머지함 > CI 자원을 절감하기 위한 방식

커밋로그 이쁘게 남기기 - 러스트 컴파일러가 꼼꼼하게 린트 체크를 하는 것 같음

주석의 필요성 - 클린코드의 폐해를 다시한번 봤음. 5~10년전 코드가 남아있는 경우가 있음. 무엇을 테스트하는지 알 필요가 있다.

러스트의 단점 ? 러스트는 무조건 빠른게 아님. 컴파일 속도가 엄청나게 느림(15~20분). 가볍게 만들기 위해 의존성을 많이 끌어오기 때문이다. 결과적으로 엄청나게 무거움.

 

오픈소스 만들기 : 깨진 링크가 있다면, PR을 자동으로 올려주는 방식의 오픈소스. 그러나 링크가 유효한지 체크해주는 서비스는 이미 여럿 존재한다 > 러스트로 쓰여진 서비스가 있는데 아이러니하게도 이 서비스가 READ.ME 링크가 깨져서 수정해달라고 PR을 올려둠... queensac 이란 오픈소스를 만들고 있으니 만괂부 : https://github.com/reddevilmidzy/queensac

---

열번째 발표

마지막 발표. 이번 발표도 spring-ai 기여한 내용이었다.

 

과학적 숫자 표기법이 NumberFormat Exception이 발생하는 이슈였는데, 메인테이너와 이야기하면서 이슈를 수정하셨다고 하심.

---

마치며

소프트웨어의 세계는 정말 넓다고 다시한번 생각하게 된 밋업이었다. 사람마다 관심있는 오픈소스가 정말 다양하고 기여하는 방식도 정말 다양했다. 학생임에도 불구하고 기여하시는 분들도 있었고, 엄청나게 많은 기여를 하신 분도 있었다.

 

오픈소스에 진심인 분들이 많아서 꽤 재밌게 들었다. 작년에 스터디를 진행하고 1년만에 다시 오픈소스를 기여하면서 느낀게 많았는데, 이번 밋업에서 다시한번 자극을 받게 되었다.

 

그래서 나도 이번에 어떻게 꾸준히 기여할 수 있는게 뭘까? 에 대한 고민을 많이했다. 내가 일단 관심이 있는건 단순 어플리케이션 개발이 아니라 인프라적 설계다. 그래서 인프라에 영향이 가는 오픈소스가 좋다는 생각을 하게됐고 AWS를 낀 오픈소스를 계속 하는게 지속 가능성이 있을 것 같았다.

 

이런저런 생각을 많이할 수 있는 밋업이었다. 인제님도 생각이 많으신 것 같은데, 나도 비슷한 고민을 많이하고 있어서 기회가 된다면 이런저런 이야기를 많이해볼 기회가 있었으면 좋겠다.