Introduction
- 나는 2022 오픈소스 컨트리뷰션 아카데미(이하 OSSCA)를 통해 처음 Backend.AI를 접하고 다루게 되었다. 프로그램 진행 이후 좀 더 제대로 프로젝트에 참여해보고 싶었고, 그렇게 나는 OSSCA 기업 연계 인턴십을 지원하여 Lablup에서 약 2달간 인턴십을 진행하였다. 그 과정에서, 이런 큰 프로젝트에 막 발 담근 초심자가 코드에 기여하기란 그리 쉽지만은 않았다. 그런데도 조금씩 해낼 수 있었던 기여 경험과 그것을 통해 얻었던 것들에 관해 얘기해보려 한다.
Technical Challenges
- On-boarding
프로젝트에 기여하기 위한 과정에서의 첫 번째 난관이 있었다. 나는 OSSCA기간 동안 Backend.AI팀에서 멘토링 프로그램을 진행했기 때문에, 나름 어느 정도 구조 파악은 된 채로 인턴십을 할 수 있겠다고 생각했다. 하지만, 여태 본 것들은 정말 일부 중의 일부라고 여겨질 정도로 새로 알아가야 할 것들이 많았다. 각각의 컴포넌트가 하는 역할은 이해하고 있었지만, 그 내부에 활용된 기술 스택들이 다양했기에 코드를 읽기도 그리 쉽지만은 않았다. 그렇게 여겨질 때쯤, 온보딩의 일환으로 한가지 과제를 받게 되었는데, 바로 비동기 웹 채팅 프로그램을 작성하는 것이었다. 그리하여 python asyncio, aiohttp, redis 등등 몇 가지 도구를 활용해 약 일주일간의 기간 과제를 진행하였는데, 그 과정에서 프로젝트에 사용된 툴들을 활용하려 노력하다 보니 자연스레 그것에 대한 이해가 조금씩 생기게 되었다. 그렇게 과제를 통해 얻을 것을 바탕으로 코드를 보고서 이 코드가 어떤 역할을 하는지 베이스 코드를 어느 정도 읽을 수 있게 되었다.
- Development environment setting
- 두 번째 난관은 환경 세팅이었다. OSSCA때도 겪었던 것이었지만, 인턴십 중에도 자연스레 직면하게 되었는데 아무래도 코드 기여를 위해서는 안정된 버전이 아닌, 항상 최신 버전을 업데이트해서 작업을 진행하게 되기 때문에 한번 환경을 제대로 세팅한다고 해도 업데이트 때 새로운 에러를 직면하게 되기도 한다. 하지만 조금 발전하게 된 부분이 있었다. 인턴십 이전에는 에러가 발생해도 언제 어디서 터진 건지 파악이 어려웠다면, 이제는 어느 정도 사용된 라이브러리, 도구, 기술 스택이 어떤 것인지 알게 된 이후였기 때문에 어떤 컴포넌트에서 어떤 역할을 하는 부분이 제 기능을 못 하고 있는지 혹은 어떤 곳에서 충돌이 발생했는지 알 수 있게 되었다. 비유하자면 이전에는 엉킨 실타래를 풀기 위해 무엇을 해야 할지 몰랐다면, 이제는 엉킨 실타래의 시작 부분을 찾아내어 조금씩 조금씩 실타래를 푸는 방법을 터득한 느낌이었다.
Task
- Good first issue
- 온보딩 기간이 지난 후에, 흔히들 good first issue라고 하는 간단하거나 신경 쓸 것이 많지 않은 이슈를 세 개 정도 할당받게 되었다. 그중 하나가, agent에 구현되어있는 ‘플러그인을 선택적으로 로드하는 기능’을 manager 쪽에도 똑같이 구현하는 것이었다. 그래서 차근차근 뜯어보기 시작했다. toml 형식으로 된 configuration 파일이 무엇을 전달할 수 있는지, 어느 지점에서 메모리에 올라가는지, 타입 체크는 어디서 하게 되는지를 살펴보았고. 또 어떠한 로직으로 플러그인이 로드되고 블록 되는지 이전에 다른 분들이 작성해놓으신 이슈와 코드를 참고해서, manager 측에 어떻게 적용하면 될지를 고민하여 조금씩 코드를 작성해 나갔었다. 아무래도 Backend.AI는 사용되고 있는 실제 제품이기 때문에 처음엔 한줄 한줄 작성할 때도, 상당히 조심스러웠고 내가 작성한 코드보다 조금 더 나은 코드가 있진 않을까 혹은 가독성이 떨어져서 다른 분들이 읽기에 어렵진 않을까 조심스러운 마음이 많이 들었었다. 그렇지만 이 이슈를 진행하며 몇백 줄이 넘는 코드 속에 직접 작성한 코드도 끼워 넣어보고, 리뷰어님 께서 코드 리뷰를 해주신 것을 바탕으로 코드를 수정 및 개선해 보기도 하면서 merge 되는 과정까지 쭈욱 거쳐 보니 그런 과정이 좀 더 자연스럽게 느껴지게 되었다.
- Monitoring
그렇게 good first issue를 끝내고 나서, 새롭게 무엇을 개선할 수 있을까 찾아보던 와중에 모니터링 관련한 인프라를 개선하는 이슈를 보고서 흥미를 느껴 주제를 잡게 되었다. 내가 인턴십을 하기 전에는 현업에서의 일을 상상해 보았을 때, 엄청나고 복잡한 코드를 뚝딱 작성해내는 장면을 떠올리곤 했는데, 실제로는 기존 코드의 문맥을 읽기 위해 코드를 뜯어보거나 혹은 해당하는 부분에 사용된 기술적인 부분을 이해하기 위해 자료를 조사해보고 공부하는 과정에 상당한 시간이 소모된다는 것이었다. 나도 새롭게 정한 이슈를 위해서 모니터링 인프라에 대한 조사와 기존 코드를 읽는 데에 꽤 많은 시간이 소모되었다. 그러한 과정을 거친 후, 프로세스의 자원 사용량을 모니터링 하기위해서 cgroup 혹은 docker API를 활용해 컨테이너 내부에서 돌아가고 있는 프로세스 리스트를 얻고 그것과 서드파티 모듈을 이용해 CPU, memory 등등의 자원 사용량 측정 메트릭을 수집하는 agent backend코드를 작성했다. 예상했던 것보다 코드의 양도 많아지고 작성할 로직도 많아져 기존 인프라와 잘 융합되도록 하기 위해 고민을 거듭했고, 그 이후 받은 리뷰를 바탕으로 수정을 진행하기도 하였다. 그 과정에서 프로그램 모니터링에 관심이 깊어져서 이후에는 이슈로 발행되어 있지 않은 주제였던, agent에서 쿠버네티스 노드의 자원 사용량을 모니터링하는 코드를 만들어 PR을 보내기도 했다.
Conclusion
- 그렇게 인턴십을 진행하고 직접 일을 해보면서 얻은 간단하고도 궁극적인 한 가지 인사이트는 ‘아! 결국 좋은 코드는 혼자 끙끙대며 작성하는 게 아니구나!’라는 것이었다. 아무리 고민을 많이 하거나 조사를 많이 하더라도 결국 한 사람이 작성하는 코드는 그 사람의 관점과 시야 내에 머물게 된다. 하물며 정말 대단한 천재가 작성한 프로그램이라도 오타 한 줄은 존재하기 마련이다. 다른 동료들과 소통하고 의견을 나누면서 부족했던 부분을 채우고 개선해나가는 과정이 필요하다. 가독성이 좋은 코드가 강조되는 이유가 여기에 있다고 본다. 나도, 남들도 꾸준히 프로그램을 발전시킬 수 있도록 읽기 쉬운 코드를 작성하는 것 그리고 조금은 부끄러운 날 것의 아이디어 혹은 코드이더라도 다른 동료들에게 도움을 구하고 함께 고민해서 만들어낸 결과물이 조금이라도 더 낫다는 것.
- 처음 직장을 다녀본 나로서도 래블업은 놀라울 정도로 수평적이고 구성원 간에 소통이 자유로운 곳이었다. 매일 이루어지는 전체 미팅을 통해 회사의 사업 진행 과정을 모두가 알 수도 있었고, 어떤 문제가 발생했을 때는 메신저를 통해 직책에 상관없이 사람들이 서로 도움을 주기도 하고 새로운 의견을 내어 문제를 개선하기도 했었다. 그런 곳에서 두 달간 함께 하며 프로젝트에 참여할 수 있었던 것은 매우 소중하고 값진 경험이었다고 생각한다.