Outsider's Dev Story

Stay Hungry. Stay Foolish. Don't Be Satisfied.

기술 뉴스 #133 : 19-09-02

웹개발 관련

  • Google Is Tightening Its Grip on Your Website : Google이 AMP를 통해서 웹사이트의 통제권을 강화하고 있다고 비판하는 글이다. AMP의 장점이 있고 AMP를 쓰면 구글이 검색에서 이점을 제공하므로 실제로 꽤 많은 트래픽을 얻을 수 있기 때문에 퍼블리셔 입장에서는 AMP를 단순히 선택사항이라고 말하기 어려운 부분이다. 실제로 실수로 AMP가 깨졌을 때 트래픽이 엄청나게 떨어졌다고 한다. 구글은 계속 AMP는 좋은 기술이라고 얘기하지만 "구글이 정말 신경 쓴다면 HTML의 특수한 형식 때문이 아니라 속도만으로 페이지의 순위를 정해야 한다.(If Google genuinely cared, it would rank pages based on speed alone, not whether they use some special format of HTML.)"는 부분에 동의한다. 비슷한 글을 종종 공유하는데 Google이 AMP를 통해 웹을 독점하려고 한다고 생각해서 자꾸 비슷한 내용을 공유하게 된다.(영어)
  • GraphQL is not just a network protocol : GraphQL을 단순히 RESTful API를 대체하는 방식이 아니라 프론트엔드의 상태관리까지 해주는 GraphQL의 관점을 설명하는 글이다. SDL로 스키마를 정의하고 이를 더 쉽게 사용하기 위해서 리졸버를 구현하는 과정을 설명하면서 이 리졸버를 서버뿐 아니라 클라이언트에서도 실행하는 Apollo Client를 설명하고 있다. 보통 API가 데이터베이스를 다루는 서버의 관점과 프론트엔드의 글로벌 상태관리의 관점이 어긋나는 부분을 해결하기 위해 GraphQL이 API부터 프론트엔드의 상태관리까지 한꺼번에 관리해서 신경 쓰지 않도록 하고 있다고 한다. GraphQL을 자세히 보고 있지 않았는데 이런 부분까지 확장하고 있는 점이 흥미롭다.(한국어)
  • Building a more private web : 프라이버시 침해를 걱정할 정도로 웹사이트들이 사용자 정보를 가져갈 수 있는 시대에서 Google이 더 프라이버시가 보호되는 Privacy Sandbox를 제안했다. 사용자가 제어하지 못하는 핑거프린팅 같은 기법을 차단해서 사용자 정보를 보호하면서도 광고는 여전히 타게팅해서 할 수 있도록 하기 위해 만들었으며 여러 브라우저 간에 표준으로 만들기 위해 제안으로 올리고 사용자의 피드백을 기다리고 있다. 상세 요약은 Potential uses for the Privacy Sandbox에 나와 있다.(영어)
  • 안티 패턴으로서의 CSS background-image 속성 : CSS background-image는 SEO와 접근성에도 좋지 않고 성능도 좋지 않아서 정말 배경으로 쓸 때만 사용하고 <picture>를 사용하라고 설명하는 글이다. <picture> 태그로 cover 효과를 낼 수 있고 srcset 속성을 사용하면 스크린 사이즈 별로 다른 이미지를 사용할 수 있고 브라우저가 지원하면 지연 로딩도 할 수 있다고 한다. 몇 년 전에 <picture>sreset은 못 써서 background-image를 사용할 수밖에 없는데 SEO가 되지 않아서 고민했던 기억이 나서 더 공감되었다.(한국어)
  • GitHub supports Web Authentication (WebAuthn) for security keys : GitHub이 WebAuthn을 사용해서 시큐리티 키를 등록할 수 있도록 지원하기 시작했다. WebAuthn을 사용하면 기기에서 사용할 수 있는 Touch ID 등을 통해서 지문 등을 2차 보안키로 등록해서 사용할 수 있다.(영어)

그 밖의 개발 관련

  • Unit Test (단위 테스트) 에 관한 생각 : 조직에 유닛 테스트를 도입하는 과정을 설명하는 글이다. 유닛 테스트의 장점을 먼저 설명하고 테스트를 작성하도록 할 때 보통 겪게 되는 레거시 코드의 문제나 테스트로 인해 작업 시간이 증가하는 문제 등을 어떻게 해결하는 좋을지 설명하고 있다. 이후 실제로 도입할 수 있도록 초기의 속도 저하를 감수하고 테스트의 작성 원칙 등을 정하면 좋고 이렇게 작성한 유닛 테스트가 지속하도록 코드를 계속 리팩토링하면서 자동화를 도입하는 것을 권장하고 있다.(한국어)
  • Flutter, 왜 선택하지 못했나 : Line에서 Pay 앱을 따로 만들기로 하면서 Flutter를 검토했다가 결국 사용하지 못하고 네이티브 개발을 하게된 과정을 설명한 글이다. Flutter는 1.0이지만 아직 다른 플러그인은 0.x 버전으로 완성도가 부족한 플러그인이 많았고 필요한 관련 개발 정보를 많이 얻기도 힘들었다고 한다. 결국 Pay 앱에서는 Flutter의 장점을 얻을 수 없다고 판단해서 안 쓰기로 했다고 한다.(한국어)
  • The GitHub Student Developer Pack is back : 학생들에게 GitHub Pro 기능과 5천만 원 상당의 유료 서비스를 무료로 제공하는 GitHub Student Developer Pack에 20개의 새로운 파트너가 추가되어 더 강력해졌다. 회사에서도 많이 쓰는 상당수의 유료 서비스가 포함되어 있고 개발에 필요한 대부분 영역의 도구가 포함되어 있어서 개발 공부에 상당히 도움이 될 것 같다.(영어)
  • Redis 버그 – Dataset 사이즈가 200GB가 넘어가면 죽는다구요? : 얼마 전 Coupang 장애의 원인으로 알려진 Redis 버그가 어떤 내용인지 정리한 글이다. 아이템이 21억 개가 넘어가게 되면 int의 범위를 초과해서 발생하는 문제로 Redis 4.0.8부터는 해결이 되었다고 한다.(한국어)
  • Introducing Cloud Run Button: Click-to-deploy your git repos to Google Cloud : GCP의 서버리스 서비스인 Cloud Run에 바로 배포할 수 있는 버튼을 공개했다. 이런 버튼은 보통 GitHub의 README 등에 연결해 놓고 사용자들이 바로 배포할 수 있게 하는 용도로 쓰인다.(영어)

인프라 관련

  • Boosting your kubectl productivity : Kubernetes의 CLI인 kubectl의 편리한 팁을 정리한 글이다. 초반에는 Kubernetes와 kubectl이 어떻게 동작하는지 설명하고 이후 자동완성, 출력 시 커스텀 칼럼 지정, 컨텍스트와 네임스페이스를 쉽게 변경하는 플러그인, 플러그인을 직접 만드는 방법 등이 설명되어 있다.(영어)
  • Kubernetes Failure Stories : Kubernetes에서 실패한 이야기를 모아놓은 사이트다.(영어)
  • CNCF Archives the rkt Project : CNCF에서 CoreOS가 만든 컨테이너 엔진인 rkt를 아카이빙하기로 결정했다.(영어)
  • AWS 도쿄 리전 운영장애 복구…냉각장치 오작동이 원인 : 지난 24일 AWS 도쿄리전에서 6시간 동안 발생했던 장애는 냉각장치의 오작동 때문에 발생했다고 한다.(한국어)

볼만한 링크

  • I Visited 47 Sites. Hundreds of Trackers Followed Me. : 웹사이트를 방문할 때 얼마나 많은 정보가 추적되고 있는지 정리한 기획 기사이다. 온종일 검색과 뉴스 사이트들을 돌아다니면서 각 사이트에서 Facebook, Google, Amazon 등에 얼마나 정보가 추적되고 있고 사이트 간에 공유되는지를 시각화해서 잘 보여주고 있다. 개인 식별 코드와 핑거프린트, 위도/경도 등이 모두 추적되고 있는 것을 알 수 있다.(영어)
  • Twitter CEO Jack Dorsey’s account was hacked : Twitter의 CEO인 Jack Dorsey의 계정이 Chuckle Squad라는 그룹에 해킹당해서 문제의 소지가 있는 트윗이 여러 차례 올라왔고 트위터의 조치로 곧 삭제되었다. 이후 트위터에 따르면 트위터 자체가 뚫린 것은 아니고 계정에 폰을 연결해서 폰으로 문자를 보내서 트윗을 올리는 기능이 있는데 통신사 쪽 보안이 뚫리면서 잭의 계정으로 트윗을 올릴 수 있게 되었다고 한다.(영어)
  • WEWORK S-1 요약 정리 : WeWork이 상장을 위해 제출한 S-1 문서의 내용을 분석한 글이다. 직접 S-1 문서를 보고 이해하기는 힘든데 비슷한 공용오피스 패스트파이브와 비교하면서 WeWork의 수익 구조와 성장, 비용지출 비중 등이 정리되어 있어서 대략적인 구조를 이해할 수 있다.(한국어)

IT 업계 뉴스

프로젝트

  • Element : Vue 2.0 기반 컴포넌트 라이브러리.
  • Chart.xkcd : xkcd 스타일로 차트를 그려주는 라이브러리.
  • Memento : HTTP 요청을 캐시했다가 반복할 수 있게 해주는 개발용 도구.
  • npkill : node_moudles 폴더를 찾아서 용량을 확인하고 쉽게 삭제 할 수 있는 도구.

버전 업데이트

2019/09/02 01:59 2019/09/02 01:59

PyCon 2019 스프린트 후기

스프린트는 오픈소스 프로젝트의 메인테이너들이나 많이 참여해 본 사람들이 새로 참여해 보고 싶은 사람들을 도와주어 기여해 볼 수 있게 해주는 행사이다. 내가 처음 스프린트에 대해서 들은 것은 PyCon 후기를 들으면서 알게 되었고 PyCon Korea에서도 몇 년 전부터 콘퍼런스와 함께 스프린트를 진행하고 있다. Node.js에는 Code + Learn이라는 비슷한 행사가 있다.

PyCon 스프린트에 한 번도 참여해 본 적이 없지만, 작년부터 lqez님과 scari님이 SprintSeoul이라는 행사를 만들어서 격월로 스프린트 행사를 진행하고 있다.(SprintSeoul도 그렇지만 PyCon도 Python으로만 스프린트를 하는 것은 아니다.) 나는 올 2월부터 mocha로 참여하기 시작했고 그렇게 보면 이번 PyCon 스프린트는 4번째 참석하는 행사이다.

스프린트에 참여하는 것은 다른 사람이 기여할 수 있도록 돕는 것도 있지만 어쩌다가 mocha의 메인테이너가 되었음에도 여전히 mocha 코드 대부분을 아는 것도 아니고 나도 겨우 해나가고 있다. 그런데도 mocha란 이름으로 자꾸 뭔가 하는 것은 mocha를 더 열심히 해야겠다는 자극을 받으려고 하는 이유가 크다.(일종의 벼랑 끝 전술이랄까...)

사실 스프린트에 대해서 잘 몰랐기에 처음 참여할 때부터 가서 무엇을 해야 하지 걱정하면서 참여를 했다. 지난 SprintSeoul에서는 항상 mocha는 1~2명의 참여자분들만 있었기 때문에 이슈고르는 것을 도와주고 실행 방법이나 테스트 방법 등을 도와주는 정도였고 머지까지는 안되더라도 대부분 PR 올리는 데까지는 성공하셨다. 나도 어떻게 도와드려야 하는지 몰라서 어정쩡하게 있었던 것도 있었고 알아서 작업을 잘하셔서 크게 뭔가 한 것은 없었다.

PyCon 스프린트 참석

원래는 다른 언어도 되는지 몰랐다가 mocha로 참여해도 된다는 걸 알게 되었지만 참여할지 말지를 좀 고민했다. PyCon이란 것을 망각하고 몇 번 해본 SprintSeoul 느낌으로만 참여 여부를 고민하고 있었기에 내 고민은 주말 포함 2일동안 스프린트를 하고 2일 PyCon 콘퍼런스를 참여하고 나면 너무 피곤하지 않을까 따위의 일이었다. 심지어 2일 스프린트지만 평일인 둘째 날은 사람이 없을 수도 있는데 휴가를 쓰지 말까? 같은 생각을 하고 있었다. 그러다가 요즘 코딩 많이 못 하는데 이틀 열심히 코딩이나 하고 오지라는 생각에 느지막이 참가를 신청했다.

그러고 스프린트 행사가 다가오면서 참석자가 18명까지 늘어나는 것을 보고 엄청나게 놀랬다. 18명이면 교육을 해도 적지 않은 숫자인데 어떻게 도와드리지? 스프린트를 도와줄 다른 사람이라도 구해야 하나 하는 걱정을 하다가 당일이 되었고 어떻게 되겠지 하는 마음으로 참석했다.(pandas는 참석자가 70명이나 되었기에 난 그나마 괜찮지 하고 은근 안심했는지도 모르겠다.)

불행인지 다행인지 스프린트 첫날인 15일에는 비가 많이 왔고 참석자는 5명이 오셨다. 둘째 날도 5명이 오셨는데 4명은 이틀을 다 오셨기 때문에 총 참석은 6명이었다. 결론부터 말하자면 실제로 해보니 내가 하루에 도와드릴 수 있는 분은 5명 정도가 한계인 것 같다. 그 이상 오시면 제대로 못 도와드리거나 할 것 같다.(더 익숙해지면 또 모르겠지만...)

하고 나니 참여하길 참 잘했다고 생각하고 있는데 이틀을 아주 알차게 같이 오픈소스로 즐겁게 논 것 같은 기분이고 스프린트가 어떻게 진행되는지 조금 이해하게 된 것 같다. 그리고 내가 어떤 위치로 오픈소스 기여를 도와주길 원하는지도 깨닫게 되었다.

스프린트 진행

SprintSeoul에서는 안 그랬었는데 5분이나 오셨으니 전체적으로 프로젝트 설명해 드렸다. 소스 레벨에서 설명한 건 아니고(앞에도 말했지만 나도 내가 본 곳 몇 곳 외에는 잘 모른다.) 폴더 구조는 어떻게 되어 있고 관련 프로젝트 구조나 사용하는 도구들을 위주로 설명해 드렸다. 코드야 어차피 이슈 해결하면서 자세히 봐야 하는 거니 처음에 바로 파악하기 어려워 보이는 것들 위주로 설명을 했는데 막상 설명하다 보니 CI니 Lint니 실행 방법이니 설명할 게 꽤 많았다.

mocha 강의가 아니었기 때문에 설명은 간단히 끝내고 일단 이슈를 찾아야 그 부분에 대해서 더 자세히 얘기할 수 있어서 각자 이슈 찾기를 했다. SprintSeoul에서 그랬듯이 그러고 나도 내가 처리할 이슈를 작업하고 있었는데 대부분 이슈를 못 찾고 있다는 걸 깨달았다.

처음 설명해 드릴 때 교과서처럼 good-first-issue에서 먼저 보면 좋고 그렇지 않으면 confirmed-bughelp wanted처럼 작업하기로 확정된 이슈를 하시는 게 좋을 거라고 했는데 일단 good-first-issue 레이블이 제대로 관리되고 있지 않아서 실제로 작업할 만한 이슈가 내가 봐도 없었고 간단한 이슈들은 또 금방금방 이미 처리되었기 때문에 처음 오신 분들이 판단하기가 쉽지 않았다. SprintSeoul에서도 비슷한 방식으로 도와드리긴 했는데 그때는 1~2분이었기 때문에 크게 의식하고 있지 않았던 것 같다.

그래서 내가 하던 작업을 내려두고 같이 이슈를 찾아드렸다. 또 이틀 내에 처리할 수 있으면서 어느 정도는 명확한 작업이 좋다고 생각했기 때문에 이슈를 하나씩 보면서 해볼 만 한 이슈를 찾았다. 참석하신 분이 코딩 경험이나 JavaScript 이해도를 정확히 모르기 때문에 난이도를 고려하는 게 꽤 어려웠는데 어차피 그냥 쉽게 해결할 수 있는 이슈는 거의 없었기 때문에 난이도보다는 문제 상황이 명확한 이슈를 위주로 골라드렸다. 사실 내가 봤던 부분이 아니면 어디를 수정해야 하는지는 나도 찾아봐야 해서 잘 알지 못했다.

"이 이슈는 어떠한 문제를 얘기하고 있는 거고 그 문제는 발생한 이유는 무엇이고 어떤 식으로 수정하면 해결해 볼 수 있을 것 같다." 정도로만 설명해 드리고 해볼 만 할지 물어보면서 진행을 했다. 실제로 진행할 때 해결방법이 얼마나 복잡해 나도 알지 못했다. 좀 "무책임한가"라는 생각도 했지만 금세 해결할 수 있는 건 내가 했거나 이미 해결됐을 거고 당연히 뭔가 복잡한 이유가 있어서 남아있다고 생각하는 게 당연한 것 같다. 다른 팀은 어떻게 하는지 모르겠지만 메인테이너라도 어디를 어떻게 수정할지 다 알려주는 것은 원하는 것이 아니었고(실제로 몰라서 그렇게 할 수도 없다.) 오픈소스 작업할 때도 여러 시간을 작업한 뒤에도 무의미한 작업이 되는 일이 허다했기 때문에 그 작업 과정 자체가 의미 있다고 위안했다. 맘 같아서는 그렇게 작업한 PR이 다 무사히 머지가 되고 contributor에 이름을 올리게 하고 싶었지만 나 혼자 임의로 머지할 수는 없고 그 PR이 왜 필요한지를 설득하고 어떻게 수정할지 논의하는 과정도 다 오픈소스 기여의 과정이라고 생각하고 있다. 옆에서 약간 먼저 해본 사람으로서 방향만 좀 알려주는 정도가 내가 원하는 역할 정도인 것 같다.

참석자분들이 이슈를 골라서 나랑 논의하면서 그 작업 내용이 어떤지 어떤 문제인지 논의하기도 하고 내가 먼저 찾아서 알려드리기도 하면서 참석자 5분이 작업할 이슈를 다 고르고 나니 오후 3~4시쯤 되었다. 그쯤 되니 5분 정도 계시면 내 작업은 못 하는 거구나 하는 걸 깨닫게 되었다.

막히는 부분은 같이 논의했지만, 구현 방법은 각 참석자분들이 직접 고민해서 해결하셨고 나는 주로 어떤 파일의 어느 부분을 수정하면 될 것 같은지 관련 테스트는 어디 있는지 이 부분을 수정했을 때 다른 영향은 없는지나 지금 진행 중인 다른 작업과 충돌 날 게 있는지 등을 설명해 드렸다. 명확하지 않은 부분은 이슈에 댓글로 메인테이너들과 논의를 하고 좀 명확해 지면 작업하는 게 더 좋다고는 생각하지만, mocha처럼 작은 프로젝트는 모든 댓글에 대응하기 어렵기도 하고 2일 내에 집중해서 작업해야 하므로 어느 정도 내 판단으로 해보면 좋겠다고 의견 드리기도 했는데 다른 메인테이너들과는 의견이 다를 수도 있어서 좀 걱정이 되긴 했다.

억지로 고생시켜드리려는 건 아니었고 오픈소스 기여라는 것이 작업한다고 항상 의미 있게 되지는 않고 그 작업을 의미있게 만드는 과정이라고 생각해서 최대한 어떤 식으로 진행되는지 설명해 드렸는데 어떤 느낌이셨을지는 잘 모르겠다. 사실 첫 기여는 결과까지 좋으면 제일 좋기는 한데...

스프린트 결과

같이 작업하신 분들을 생각해 보면...

  • 테스트 커버리지 관련 이슈를 알려드렸는데 오랫동안 해결이 안 되어서 간단한 이슈라고 생각하진 않았지만, 생각보다 훨씬 복잡한 이슈였던 것 같다. 이를 처리하는 이슈가 이미 올라왔다가 마지막까지 작업이 안 되고 닫힌 상황이라(메인테이너가 리젝한게 아니라...) 참고해서 하면 되지 않았을까 생각했지만, 옆에서 좀 보니 생각보다 복잡한 게 많은 문제였던 것 같다. 옆에서 너무 고생하시는데 진행이 잘 안되시는 것 같아서 걱정되었다.
  • 플래그의 기본값을 바꾸는 이슈는 처음 알려드릴 때는 꽤 간단히 생각했는데 이틀 동안 계속 얘기하다 보니 생각보다 복잡한 문제였다. 물론 문제만 해결하려면 어떻게든 되긴 하겠지만 깔끔한 형태로 들어가야 했기 때문에 여러 가지를 많이 논의했다. CI라는 개념에 익숙하지 않아서 그 부분에 설명을 많이 드렸었는데 내가 직접 수정해보면서 해결방법을 논의한 게 아니라서 중간에 잘못 생각한 것도 있고 그랬다. 이분하고 이틀 동안 제일 많이 얘기한 것 같은데 어떻게 수정하면 좋을지? 어떤 부분이 문제인지? 왜 이렇게 동작하는지? 등 많이 얘기했고 최종 구현은 2~3줄로 나왔다.(2~3줄 고치기에도 많은 시간이 걸리는게 대부분이다) 테스트까지 수정해서 올렸는데 미처 생각지 못한 영향받는 테스트가 있는데 시간이 끝나서 좀 걱정이다.
  • 한 분은 diff 성능 개선 쪽이었는데 난이도는 꽤 있어 보였지만 댓글에서 대안 라이브러리에 대한 얘기와 임시 수정 코드도 올라와 있었기에 구현 방향을 잡기가 좋아 보였다. 열심히 작업하셔서 diff 자체는 성능 개선이 되었지만, diff 결과를 리포트 하는 방식이 기존과 다른데 기존 방식이 훨씬 좋아 보여서 판단하기가 어려웠다. 나도 실제로 해볼 시간은 없어서 WIP로 PR을 올리고 구현한 부분과 막힌 부분을 설명하고 의견을 구하는 쪽으로 안내해 드렸다. 이슈에서 논의해도 되긴 하지만 코드를 올려서 논의를 시작하면 메인테이너들도 얘기하기 더 좋기 때문에 실제로도 괜찮은 방법이라고 생각한다.(물론 이런 경우 논의가 항상 활발히 되는 것은 아니다.)
  • 한 분은 리팩토링 이슈를 직접 찾아오셔서 해볼 만한지를 얘기하셨다. 이런 부분은 나도 약한 부분이라서 정확히 판단은 안 되었지만 최근 올라온 PR에 충돌 날 부분이 보이는 게 있어서 그 부분을 설명해 드렸고 그분이 변경하고자 하는 부분이 나쁘지 않아 보여서 해보면 좋겠다고 말씀드렸다. 중간중간도 몇 번 말씀드렸는데 그 부분 코드는 내가 깊게 봤던 코드는 아니라서 자세히 말씀드리지는 못했다. 다른 PR과의 충돌이 좀 걱정되긴 했지만 오픈소스에서 아직 머지되지 않은 PR과의 관계를 고려해서 작업하기는 쉽지 않은 일이고 둘 다 머지되어도(늦은 쪽은 충돌을 처리해야겠지만) 충분히 의미 있어 보였다. 하지만 나중에 댓글 보니 다른 메인테이너는 다르게 생각하고 있었고 충돌나는 PR도 아직 깊게 리뷰를 못 한 상태라 그분께 죄송했는데 오늘 보니 다른 PR을 또 올리셨다!
  • 다른 분은 오래도니 이슈를 먼저 찾아오셨는데 오래된 이슈라 처음보는 거였지만 여전히 유효한 이슈였고 난이도도 그리 높지 않아보였다. 어디를 수정해야 하는지 모르겠다고 하셔서 한참을 찾아서 위치와 테스트를 알려드리고 나중에 수정된 코드에 몇가지 리뷰를 해드렸다.
  • 둘째날 늦게 오신 분은 시간이 많지 않아서 간단한 홈페이지 쪽 이슈를 드렸는데 해보시던 작업이 아니라 문서를 보면서 해야해서 고생하시는 것 같았다. CSP 관련인데 세세하게 어느 부분을 넣어야 하는지는 테스트하면서 해봐야 알 수 있어서 직접 CSP로 컨텐츠가 대부분 나오게 작업까지는 하셨는데 가실 시간이 되어서 마무리를 잘 하실 수 있었으면 좋겠다.

어쨌든 4개의 PR이 올라왔고 둘째 날은 나도 틈이 좀 나서 웹사이트 관련 간단한 PR을 올렸다.

이틀 동안 꽤 즐거웠는데 다들 좋은 경험이셨으면 좋겠다. 이렇게 밀착되어 작업하면서 스프린트에 대해서 이해를 하게 되었고 사람들이 어떤 부분에서 막히는지도 알게 되었다.

mocha 쪽의 레이블이 제대로 안 되어 있거나 작업에 대한 설명이 명확하지 않아서 이런 부분에도 신경 써야겠다는 생각도 했고 PR 올릴 때도 내용을 어떻게 정리해서 올리는지도 꽤나 어려워 하셔서 이 부분도 "PR 올리시면 돼요"로 끝낼 얘기가 아니라는 걸 알게 되었다. CLA 같은 것도 처음 하시는 분들에게 장벽이 상당히 많다는 것을 알게 되었다. 다음 달에는 컨트리뷰톤에 mocha로 참가하게 되었는데 이날의 경험은 이때에도 도움이 많이 될 것 같다.

도움 된 것도 그렇지만 오픈소스 기여를 한팀처럼 작업한 것은 빡세면서도 아주 재미있었다. 좋은 행사 준비해주신 PyCon 준비위원회 분들과 참석해서 열심히 같이 코딩해 주신 분들에게 감사드립니다.

2019/08/23 04:15 2019/08/23 04:15