home
2023
home
참여형
체험형
오픈소스 컨트리뷰션 아카데미
참여 프로젝트
History
2ndSyndrome
Lablup
(주)두물머리
BizData
참여 후기
갤러리
동영상
About </Code>
지역 스프린트 @대구
지역 스프린트 @청주
home
📻

About </Code>

컨트리뷰션 활동을 진행하면서 있었던 나만의 “사연있는 코드”를 소개합니다.

Search
원래 프론트엔드 기술에만 관심이 있던 저는 기술 문서를 작성하는 실력을 다듬고자 백엔드 프레임워크를 사용하는 FOSSLight Hub의 테크니컬 라이터로 지원하게 되었습니다. 그러던 중 테크니컬 라이팅 외에도 개발을 통하여 기여해도 좋을 것 같다는 멘토님 말씀 덕에 컨트리뷰션을 결심하게 되었습니다.
Challenges 활동이 시작되고 할 수 있는 일부터 해보자라는 마음으로 프로젝트를 살펴보았습니다. 그러던 중 CI/CD 상에서 자주 바뀌지 않는 의존성들이 반복적으로 설치되고 있는 것을 발견하였습니다. 매번 설치마다 소요되는 시간이 아깝게 느껴져 해결 방법을 고민하던 중 GitHub Actions에서 지원하는 의존성 캐싱 기능을 알게 되었습니다. 이 기능을 활용하면 CI/CD 환경에 의존성을 캐싱하고 필요할 때 가져다 쓸 수 있어 설치 시간을 획기적으로 줄일 수 있을 것이라 생각하였습니다. 결국 의존성 캐싱을 도입함으로써 오래 걸리던 CI/CD 속도를 60초 이상 단축할 수 있었습니다.
Masters 활동을 진행하며 프로젝트 내 DevOps 관련 팀에 속하게 되어 Docker 이미지 배포를 맏게 되었습니다. 배포는 릴리즈마다 자동으로 실행되도록 GitHub Actions를 사용하여 CD 파이프라인을 구축하였습니다. 그리고 배포되는 이미지의 용량을 줄이기 위해 Dockerfile의 불필요한 레이어를 제거하고 저용량의 Base Image를 사용하도록 변경하였습니다. 이 과정에서 기존 398MB였던 이미지를 344MB로 줄이면서 약 13%의 사이즈 절감 효과를 볼 수 있었습니다.
이러한 과정을 거쳐 드디어 오늘 Docker 이미지 배포에 성공하였습니다. GitHub Actions에서 빌드되고 배포되는 과정을 보니 뿌듯함을 느낄 수 있었습니다.
[뿌듯한 코드]
[뿌듯한 코드] 프론트엔드 개발자, 데브옵스로 진화!
9월은 열정의 달이었습니다. 모든 것이 순조롭게 진행되고 있었고, 우리 모두는 불타오르는 열정으로 기능을 활발하게 개발하고 있던 시기였습니다.
그러나 그날은 유독 이상했던 날이었습니다. 멘토링 장소에 도착해보니 먼저 도착해서 작업을 하고 있던 조성수 멘토님이 멘붕에 빠져있었습니다. 자세한 사정을 들어보니, 본인의 노트북에서 실수로 서버에서 날려야 할 명령어인 rm -rf * 를 실행시켜서 회사 노트북의 모든 자료가 한 순간에 사라졌다는 것이었습니다.
그렇게 조성수 멘토님은 멘탈이 붕괴된 상태로, 노트북은 자료 복구를 시도하고 있었고, 그날 화면 공유는 제 컴퓨터로 진행했어요. 2시간에 걸친 멘토링도 잘 마무리되었고, 이제 기쁜 마음으로 집에 가면 되는 순간이 왔습니다.
집에 가기 위해 연결된 선을 뽑고 노트북 모니터를 닫는 순간, 빠지직.. 순간 망했다는 것을 느낄 수 있는 소리가 들려왔고, 주변에 있던 모든 사람들은 순간 얼음이 되었습니다. 그 순간 제 머리 속에는 노트북 위에 올려놓았던 반지가 떠올랐고, 아... 제발 반지가 부셔졌으면 좋겠다고 빌었습니다.
살포시 모니터를 올려보았는데.. 화면이 안 나옵니다.. 그렇습니다. 액정이 깨졌습니다. 이 노트북은 회사 노트북이고 수령한 지 2개월 밖에 되지 않았는데 말이죠. 그리고 전 ... 수습 기간이었습니다.
이제 멘붕은 조성수 멘토님에서 저로 옮겨왔습니다. 당장의 수리비가 걱정되기 시작하면서 오만 가지 생각이 다 들어군요. 결국 수십만 원의 수리비를 내게 되었지만, 컨트리뷰션 아카데미 기간 동안 멘티 분들에게 두 멘토의 허망한 멘탈 붕괴 일화를 선물해 드릴 수 있었다는 것으로 위안을 삼고 있습니다.
[슬픈 코드] 노트북 위에는 손가락만 올려두자
709
pull
코드를 다 작성하고 간단한 테스트를 만들었는데 통과를 하지 못했습니다. 이유를 찾기 위해 계속해서 논의를 했지만 메인테이너들도 에러를 잡지 못해 계속 삽질을 하다가 테스트 케이스를 이상하게 쓰면 통과한다는 것을 알게 되었습니다.
그 이후 왜인지는 모르겠지만 테스트가 통과할 수 있도록 코드를 수정했고 이미 작성되어있던 코드에 관한 이슈가 새로 열리게 되었습니다. 그 이후 그 이슈까지 제가 코드를 작성해 해결하였습니다.
[삽질 코드] 이미 있는 코드라고 다 믿을 순 없다
Pytorch lightning repo 내 올라온 issue를 해결하기 위해서 나름 열심히 수행해서 PR을 올렸지만, 알고보니 해당 모듈은 다음 버전에서 없어질 모듈이어서.. 제 PR은 Merge로 이어지지 못했습니다ㅠㅠ
[삽질 코드] 이제는 Merge 될 수 없는 내 PR
때는 토요일 나른한 오후였습니다. 팀원들 여럿 모여 토즈에서 모각코를 하고 집으로 가는 길이었습니다. 다들 오랜 공부로 목이 타며 집을 가는데 멘토님의 한마디.. "치맥 하실 분,,?" 모두 번뜩하며 피리 부는 사나이의 피리 소리를 들은 것 마냥 모두가 졸졸 따라갔습니다. 그때 저는 따라가지 말았어야 했습니다. 내가 맥주를 따르지 못한다는 것을 한 번 더 깨우쳤어야 했습니다. 하지만, 참새가 어찌 방앗간을 그냥 지나치랴.. 정신 차리니 이미 들어와 있었고 심지어 복도 쪽에 앉은 저는 모두에게 맥주를 따라 배포해야 하는 위치였습니다.
하지만 해보자! 하고 따르는데 거품이 차오르면 차오를수록 한 분 한 분 저의 맥주잔을 바라보았습니다. 한 분 한 분 눈이 마주칠 때마다 얼마나 부담이 되었는지 콜로세움 한가운데 맥주와 싸우는 검투사가 된 기분이었고 이러한 긴장감은 저를 더 망가뜨렸습니다. 그 결과 다음과 같은 사진이 나오게 되었고 그 뒤로 다들 모각코가 끝나면 재깍 재깍 집으로 돌아가 건강한 집 밥을 먹게 되었고 팀원 모두가 건강해져 더 많은 기여를 할 수 있는 좋은 결과가 나오게 되었습니다 ..ㅎㅎㅠ
[흑역사 코드] 나의 아저씨 이선재
야너두 오픈소스 기여할 수 있어! hub-kr 번역활동을 하다가 pytorch/hub에 5번이나 merged된 경험
3.
resnet50을 번역하다가 띄어쓰기 실수를 발견하고 PR을 적어 Merge 되었습니다. https://github.com/pytorch/hub/pull/305
4.
같은 resnet50에서 오타를 발견하고 수정하여 한번 더 Merge 되었습니다. https://github.com/pytorch/hub/pull/306
5.
tacotron2를 번역하다가 처음에 한번 읽고 이해가 안되는 부분이 있어서, 다른 분들이 이해하기 쉽도록 문장을 바꾸었습니다. https://github.com/pytorch/hub/pull/309https://github.com/pytorch/hub/pull/309/files (보통 파이토치 허브에는 문서와 함께, 대표되는 이미지들이 같이 삽입됩니다, tacotron2에서 모델의 input에서 output까지의 flow를 설명하는 구간이 있었는데, 같이 삽입된 이미지가 이를 설명해주는 이미지였고, 따라서 글에서 해당 이미지를 보라는 언급을 통해서 모델을 더 직관적이고 쉽게 이해할 수 있었습니다.)
[뿌듯한 코드] 야! 너두 오픈소스 기여할 수 있어!
약 2달간 동안 6개에 대한 이슈에 대해서 담당하였고, 처음으로 내가 만들 코드가 오픈소스에 merge 되는 뜻깊은 시간을 가질 수 있었습니다. 오픈소스에 대한 문화를 배우고 원하는 분야를 선택해 직접 기여할 수 있다는 것이 좋았습니다. 또한 단순히 혼자 개발하는 것이 아닌 협업에 대한 중요성과 오픈소스의 장점에 대해서도 배웠고, 이제는 나도 충분히 기여할 수 있다는 자신감을 얻을 수 있었습니다.
또한 감사하게도 멘토님들이 직접 피드백 해주시면서 많은 성장을 할 수 있었고, 개발자로서 지켜야 하는 규칙에 대해서도 다시 한번 생각해보고 배우는 시간을 가질 수 있었습니다. 단순히 개발하는 법을 배우는 것이 아닌 협업하는 방법에 대해서 배우는 것은 해당 활동이 아니라면 배우기 쉽지 않을 것 같다는 생각이 들었고, 해당 부분을 배울 수 있어서 좋았습니다.
•
컨트리뷰션 링크 :
[뿌듯한 코드] 개발자에서 컨트리뷰터로 성장하는 시간을 가지다!
PR 링크:
안녕하세요. yorkie팀의 멘티 김범기입니다.
저는 위 PR으 개발하면서 생겼던 삽질을 소개해보고자 합니다.
PR에 56개나 되는 코멘트에서 알 수 있듯이 전반적으로 쉽지 않았던 개발이라 생각합니다ㅎ 하지만 그중에서도 가장 당황했던 문제는 새로운 기능 추가에 맞게 추가한 테스트 코드가 제 컴퓨터에서는 문제가 없는데 깃헙에 푸쉬한뒤 Github Actions의 CI툴이 자동으로 테스트가 수행되면 테스트에 실패하는 것이었습니다.
이 문제는 처음 보자마자 거의 멘붕이었다고 생각합니다. 제 컴퓨터에서는 전혀 재현이 안 되는데 계속 문제가 생기는 원인을 도저히 파악할 수 없었기 때문입니다. 이를 해결하기 위해 정말 많은 고민을 했고 코드를 수없이 검토했는데도 문제를 알 수 없어 슬랙에 질문글을 올리기로 생각하고 질문을 작성했습니다.
슬랙에 질문글을 올린뒤 동철 멘토님께서 도움을 주셔서 문제의 원인에 대한 감을 잡을 수 있었는데, 멘토님 컴퓨터에서는 위 문제가 간헐적으로 발생했기 때문입니다. 간헐적으로 발생한다는 말씀을 듣고 바로 타이밍 문제가 아닐까 생각을 하였고 yorkie 서버와의 sync과정에서 스냅샷 생성은 goroutine에서 이뤄지기 때문에 이부분이 문제일것이라 생각했습니다.
바로 time.sleep을 사용해 명시적으로 대기 시간을 주었더니 테스트가 성공하는 것을 확인할 수 있었습니다. 하지만 sleep을 사용하는 것은 테스트가 명확하지 않다는 문제가 있었고 멘토님께서 몽키패치라는 것을 제안해 주셨습니다. 처음 알게된 개념이기에 몽키패치가 무엇인지 공부해 보았고 이를 적용해 문제를 해결할 수 있었습니다....만 사실 이 사연이 진정 삽질인 반전이 었었으니...
최근에 위와 같은 이슈가 올라왔는데 몽키패치를 적용하는데 사용한 라이브러리의 라이센스가 다른곳에서 사용하면 안된다는 것이었습니다..!!! 오픈소스 개발에서 어떠한 라이브러리를 사용할때 해당 라이브러리의 라이센스를 확인했어야 하는데 구글에 go언어 몽키패치를 검색하면 바로 나오는 라이브러리라 안일하게 사용했다고 생각합니다.ㅠㅜ 라이센스 확인의 중요성을 깨닫는 중요한 계기가 되었다고 생각하고 조만간 이를 대체할 방법에 대해 알아볼 예정입니다.
[삽질 코드] 해치웠나!?
회사에서 매주 weekly report로 주간 업무 내용을 공유하는데 githru에 내가 직접 사용할 기능을 넣으면 더 애정이 가지 않을까 싶어 직접 기획하고 코드로 구현한 PR입니다.
기존 모든 cluster가 한꺼번에 보여지는 리스트를 author 클릭 시 해당 author의 작업을 모아 보여주는 기능을 추가함으로써 본인의 작업뿐 아니라 ‘퇴사자 업무 내용 확인’, ‘일정 기간 별 세부 기여도 비교’와 같은 작업도 가능해졌습니다. 나아가 제가 실제 사용할 기능이라 생각하니 단순한 오픈소스 컨트리뷰터1의 역할이 아니라 보다 더 깊게 고민할 수 있었던 시간이었다고 생각합니다.
앞으로 githru를 사용하는 다양한 사용자들의 요구 사항에 대해서도 이 PR을 구현한 마음가짐으로 해결해주는 컨트리뷰터로 발돋움하고 싶습니다.
[뿌듯한 코드] githru 화이팅:)
챌린저스 기간이 끝나갈 무렵에 있었던 일이였습니다.
저희 팀은 라이브러리를 활용한 샘플 앱을 만들기로 하였으나, 여러 이유로 인해 마지막 날까지 제대로 된 시작도 못한 채 기간이 종료되었습니다. 이때, 마지막 주 전체 팀 회의를 오프라인으로 진행하며 각 팀마다 진행해온 내역, 결과물을 발표하는 것으로 했는데, 저희 팀은 결과물이 없어 왜 프로젝트를 실패 했는지 원인과 개선 방향 등을 발표하게 되었습니다.
사실, 발표를 준비하며 아무것도 해내지 못했다는 부끄러움이 앞서 '그냥 아프다는 핑계를 대고 안나갈까' 라는 생각이 들었으나 하기로 결정했습니다. 그렇게 발표를 하는 도중에 부끄러움을 이겨냈다는 생각에 오히려 자신감이 생겼고 무사히 발표를 마칠 수 있었습니다.
그렇게 발표를 마친 뒤 멘토님들의 피드백과, 기간 동안의 아쉬운 마음에 그동안 해보지 못했던 간단한 문서 위주의 이슈를 해결해보기 시작하였습니다. 그렇게 첫 번째 이슈를 해결하는 PR을 올렸을 때, 누구나 할 수 있는 간단한 이슈였음에도 불구하고 멘토님들이 칭찬과 피드백을 마구마구 해주기 시작했습니다! 그렇게 엄청난 칭찬과 수정 사항들을 보며 여러 개의 이슈를 해결 할 수 있었고, 이슈 하나하나를 해결할 때 마다 뿌듯함을 느끼며 오픈소스 활동을 하는 많은 이유 중 하나를 알게 되었습니다.
비록 다른 사람들이 보기엔 엄청 간단한 이슈지만, 이렇게 해결하는 과정에서의 멘토님들의 어마어마한 칭찬과 격려, 해결했을 때의 뿌듯함은 이후 활동의 원동력이 되었답니다!
[뿌듯한 코드] 칭찬은 개발자도 춤추게 한다
많은 사람들이 읽는 Kubernetes의 공식 기술 블로그 문서(영문)를 처음으로 한글화하며, PR에 80개가 넘는 리뷰 코멘트를 받았습니다. ㅎㄷㄷ 하나씩 살펴보고 논의하고 반영하는 것이 쉽지 않았지만, 결과적으로 만족스러운 한글화 기여 결과물을 만들 수 있었고, 번역 기여자에 이름을 올려서 많은 사람들에게 이름을 알릴 수 있었습니다. :)
•
Kubernetes 공식 기술 블로그 한글화 PR:
•
Kubernetes 공식 기술 블로그 한글화 결과물:
그런데.. 다음 PR에는 더 많은 131개 코멘트가 달렸다는... 웃픈 사실 ㅠㅠ
[웃픈 코드] 리뷰 코멘트 부자
어떤 파이토치 튜토리얼 문서를 번역할지 고민하던 중에 라즈베리파이에서 실시간으로 물체를 탐지하는 내용이 있었습니다. 마침 다른 프로젝트에서 비슷한걸 해본 경험이 있어서 흥미가 가길래 바로 번역을 시작했습니다. 번역을 하던 중에 opencv 파이썬 패키지를 설치하는 부분이 있었습니다.
해당 내용을 보자마자 예전에 저도 똑같은 명령어로 패키지를 설치하다가 삽질한 기억이 났습니다. opencv를 설치하는 명령어가 2가지가 있는데 하나는 필수 요소만 설치하는거라 15초만에 끝나고, 다른 하나는 모든 요소를 설치하는 명령어라 무려 2시간이 넘게 걸렸습니다. 물론 해당 내용을 몰라서 3일 정도 날렸었죠.
문서 내용에는 전체 패키지를 설치하도록 나와 있어서 다른 사람들이 저와 같은 삽질을 하지 않도록 “설치하는데 약 2시간이 걸리고 끝날 때까지 터미널에 아무런 내용도 뜨지 않습니다.” 라고 경고문을 주석으로 달아서 PR을 올렸습니다. 처음 PR을 올리고 파이토치 문서 담당자가 문서 작성자를 멘션하며 해당 내용에 대해 물어봤습니다. 멘션을 했으니 금방 답변을 달아줄 것이라고 생각했는데 답변을 받는데 4일이나 걸렸습니다. 기다리는 동안 ‘내가 뭔가 잘못했나?’, ‘영어 내용이 너무 어색한가?’ 별 생각이 다 들었습니다.
그렇게 기다려서 받은 첫 답변도 제 시스템에 뭔가 이상한게 아닌지 물어보는거였어요. 이걸 보자마자 속으로 엄청 긴장했었습니다. 다행히 얼마 뒤에 저만 겪는 문제가 아니라는걸 찾아서 올려줘서 안심했었습니다.
이후에는 제게 다른 명령어로 바꾸는게 어떤지 물어보길래 저도 동의하고 커밋을 수정해서 올렸습니다. 리뷰 요청하고 따봉을 받으니 정말 뿌듯하더라구요.
이 PR을 머지시킨걸 MSG팍팍 쳐서 “파이토치 튜토리얼 속 파이썬 패키지 설치 시간 2시간에서 15초로 단축” 이라고 주변에 자랑하고 다닙니다.
[뿌듯한 코드] "파이썬 패키지 설치시간 99.8% 감소" (MSG첨가)