Outsider's Dev Story

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

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

기술 뉴스 #132 : 19-08-15

웹개발 관련

  • Why is modern web development so complicated? A long yet hasty explanation: Part 1! : 현대 웹 개발도구가 상당히 복잡한데 왜 이렇게 복잡해졌는지의 과정을 설명하는 글이다. 모든 도구는 해결하는 문제가 있어서 그 문제점을 이해해야 도구를 이해하고 있다고 설명하면서 지금과 달리 과거에는 JavaScript의 한계가 명확했고 웹 API와의 차이점이 있었기 때문에 jQuery가 오랫동안 이 문제를 해결하였고 그사이에 ECMAScript가 발전했지만 모든 브라우저에서 같은 JavaScript 기능을 지원하지 않았기 때문에 모던 자바스크립트로 코딩하고 싶은 개발자를 위해서 Babel이 등장한 과정까지 설명하고 있다. 이미 복잡한 도구들만 접해서 사용해본 개발자들에게도 많은 도움이 될 것 같다.(영어)
  • 2019년과 이후 JavaScript의 동향 - 라이브러리와 프레임워크 1, 2 : Angular, React, Vue,js, Web Component, TypeScript, Svelte, Preact 등 대표적인 프레임워크와 라이브러리의 프로젝트 진행 상황과 최근에 추가된 기능 및 향후 계획 등을 정리한 글이다. 모든 프로젝트를 살펴보기가 어려운데 꽤 자세하게 정리되어 있어서 각 프로젝트의 상황을 살펴볼 수 있다.(한국어)
  • The New York Times is still detecting Chrome Incognito Mode after Google’s fix : Google이 Chrome 76에서 시크릿 모드를 탐지 못 하도록 수정했음에도 불구하고 뉴욕타임스가 바로 시크릿 모드를 탐지할 수 있도록 수정했다고 한다. 아직 정확히 어떤 방법으로 탐지하고 있는지는 밝혀지지 않았다.(영어)

그 밖의 개발 관련

  • How I side project : 사이드 프로젝트를 어떻게 진행하는지 설명하는 글이다. 작업하면서 생각난 아이디어 중 일부만 실제로 작업을 하게 되는데 아이디어가 생겼을 때가 가장 동기부여가 높을 때가 바로 작업을 시작해서 간단한 프로토타입을 만든다고 한다. 작업 흐름에 방해되는 걸 막기 위해서 익숙한 도구를 항상 반복해서 쓰고 작업하는 내용을 계속해서 공유하면서 작업한다고 한다.(영어)
  • When a rewrite isn’t: rebuilding Slack on the desktop : Slack이 오래된 데스크톱 앱을 새로운 코드 베이스로 바꾸는 과정을 설명한 글이다. 2012년과는 많이 달라졌으므로 레거시 앱은 DOM을 직접 조작하고 데이터 로딩을 초기에 많이 하면서 워크스페이스마다 프로세스를 띄웠는데 앞의 두 문제는 계속 개선하고 있었지만 워크스페이스 문제는 설계부터 바꿔야 하므로 쉽지 않은 문제였다. 오래된 코드 안에서 새로운 코드를 바꿔가면서 둘을 연결하는 방식으로 개선해 가면서 새로운 코드는 모두 React로 작성하고 데이터는 지연 로딩하면서 한 프로세스에서 여러 워크스페이스를 개선하도록 바꾸기 위해 Redux를 사용했다고 한다. 완전히 새 코드로 전환하려고 몇 가지 규칙을 정해서 개발했으면 완전히 바꾼 뒤에는 워크스페이스가 많아져도 메모리가 많이 늘지 않는 것을 볼 수 있다.(영어)
  • 좋은 git commit 메시지를 위한 영어 사전 : 영어로 커밋 메시지를 사용하는 방법을 정리한 글인데 많이 사용하는 문법들을 상황별로 정리해 놓아서 참고하기 아주 좋다.(한국어)
  • 갈피: 나의 첫 모바일 앱 개발기 : Flutter로 첫 모바일 앱을 올려서 배포한 사이드 프로젝트 경험을 정리한 글이다. 본인이 필요로 하던 독후감 앱을 만들기로 하고 React Native로 앱을 만드는 데 불편을 느껴 처음 써보는 Flutter로 앱을 만들어서 앱스토어에 배포까지 했다. 처음 Dart 언어와 Flutter를 쓰면서 느낀 장단점도 정리되어 있다.(한국어)
  • 로우 레벨로 살펴보는 Node.js 이벤트 루프 : Node.js event loop workflow & lifecycle in low level의 번역 글로 Node.js의 이벤트 루프가 어떻게 동작하는지 설명하고 있다. 이벤트 루프의 구조를 간략하게 설명한 글 때문에 오히려 오해가 많이 쌓였기 때문에 이 글에서 이벤트 루프가 어떤 식으로 동작하는지를 설명하고 진행되는 각 단계를 자세히 설명한 뒤 setTimeout, setImmediate, process.nextTick을 이용한 예제의 동작을 보여주면서 앞에서 설명한 단계에 따라 어떻게 동작하는지를 보여주는데 잘 나와 있다.(한국어)
  • 더 작은 APK를 위한 Android App Bundle에 대해서 : Android에 새로 추가된 앱 번들을 통해 패키지를 동적으로 나누어 받을 수 있게 됨으로써 안드로이드 앱의 용량을 줄인 과정을 설명하고 있다. 실제로 당근마켓 앱의 용량은 36%가 줄었고 설치된 앱의 크기도 21%가 줄었다고 한다.(한국어)
  • 리젝 없이 iOS 구독앱, 한방에 출시하기 : 앱스토어에서 구독 모델이 포함된 앱을 준비할 때 리젝되지 않도록 구독 상품을 만드는 방법부터 구독에 대한 안내에서 리젝사유가 될 수 있어서 조심해야 할 부분을 정리한 글이다. 이런 내용은 처음 해볼 때는 고생을 많이 해볼 수밖에 없어서 미리 해본 분의 정리된 글은 도움이 많이 된다.(한국어)
  • GitHub Actions now supports CI/CD, free for public repositories : 작년에 발표한 GitHub Actions에서 CI/CD를 지원한다고 발표했다. 아직 베타 상태로 11월 13일에 정식으로 이용 가능하게 될 예정이다. 발표 영상은 유튜브에서 볼 수 있다.(영어)
  • A Readable Specification of TLS 1.3 : TLS 1.3의 명세인 RFC 8446을 더 읽기 좋게 설명한 페이지이다.(영어)

인프라 관련

  • 대규모 Kubernetes 클러스터 구축기 : Line에서 4,000개의 팟을 Kuberntes로 운영하면서 점점 늘어나는 앱에 대응하기 위해서 대규모 클러스터를 구성한 과정을 설명한 글이다. Caravan이라는 Kuberntes 클러스터 프로비저닝 서비스를 만들기 위해서 처음에는 Rancher를 사용하다가 한계를 느끼고 kuberadm, ansible, CRD를 조합해서 구성했으면 테스틑 위해서 마스터 노드 20개와 워커노트 999개로 테스트를 하였고 여기서 발견된 etcd 등의 문제를 개선했다고 한다. 이정도 규모를 구성할 조직이 많지는 않겠지만 내용만으로도 흥미롭다.(한국어)

볼만한 링크

  • 하지만, 야크 털 깎기는 재미있다 : 자신의 블로그를 직접 만든 경험을 얘기하면서 개발자들 사이에서 야크 털 깎기(Yak shaving)이 어떻게 유래되었고 야크 털 깎기로 TeX가 어떻게 탄생했는지를 설명하고 있다. 적절함이 필요하지만 야크 털 깎기가 재밌고 의미 있다는데 동의한다.(한국어)
  • 한국 해커톤의 한 걸음 정도의 발전을 위한 제언 1/3 : 해외에서 일하시다가 한국에서 해커톤에 멘토로 참여해 보시고 해커톤을 어떻게 하면 더 나은 행사로 만들 수 있을지에 대한 연재글의 첫 글이다. 이 글에서는 단기간에 제품을 만드는 해커톤에서 PM의 역할이 아주 중요하기 때문에 목적을 이해하고 시장 요구사항을 이해하고 상호 간의 경계선과 협력선을 설정하고 MVP 스코프를 결정하고 팀원의 커뮤니케이션을 향상시키고 초기 테스트에 참여하고 우선순위를 갱신하며 팀원을 응원하는 7가지 PM의 기술을 활용하라고 하고 있다. 실제로 이렇게 되면 꽤 의미 있을 것 같고 여기에서 PM의 기술은 확대해서 회사에서도 충분히 의미가 있을 것 같다.(한국어)
  • 테크니컬 라이팅 컨퍼런스: API the Docs Chicago 2019 방문기 : API The Docs 2019에 참여하고 주요 2개의 세션의 내용을 정리한 글이다. 문서화에 관심은 있지만, 항상 맘에 들게는 못 만들곤 하는데 문서화 쪽을 주 업무로 하는 테크니컬 라이터들이 API 문서를 어떻게 생각하는지 볼 수 있고 Ford에서 DocOps로 사내에 API 문서를 개발자들에게 잘 제공하기 위해 노력한 과정이 잘 나와 있다. "많은 회사가 서드파티 개발자 대상 문서에는 집중하고 노력하는 반면, 내부 개발자용 문서에는 그만큼의 노력을 기울이지 않으리라 추측"한다는 부분에 공감이 간다.(한국어)
  • [플랫폼의 생각법] 우버가 수익을 내기 힘든 몇 가지 이유 : 플랫폼 사업은 안정성을 높고 규모가 커질수록 독점에 이르게 되는 특성이 있지만 우버의 플랫폼은 다른 프로랫폼과는 달리 기사나 승객이 락인될 요소가 없고 네트워크의 규모도 지역적으로 분리되어 규모의 이점을 누리기 어려우며 자율주행도 현재의 핵심인 기사를 퇴출하는 방법인 데다가 연구 결과도 긍정적으로 보기 어렵다고 얘기하고 있다. 이렇게 깊게 생각해 본 적이 없어서 흥미로운 분석이었다.(한국어)
  • 2019년 상반기 회고 : 개발도 잘하시면서 공부랑 공유도 열심히 하시는 이동욱 님의 상반기 회고 글인데 회사와 개인적인 학습, 활동을 너무 열심히 하셔서 글만 봐도 자극될 정도이다.(한국어)

IT 업계 뉴스

  • The LLVM Project is Moving to GitHub : LLVM이 SVN에서 GitHub으로 갈아타기로 했다고 한다. 지난 9개월의 작업으로 2019년 10월 마이그레이션을 완료한다고 한다.(영어)
  • The We Company S-1 : WeWork이 상장을 위해 증권거래소에 S-1 문서를 제출했다.(영어)
  • Automattic + Tumblr : Wordpress를 만드는 Automattic이 블로그형 서비스인 Tumblr를 버라이즌으로부터 인수했다.(영어)
  • 한국 벤처 역사 이민화 이사장 별세…향년 66세 : 한국 벤처-스타트업 생태계 조성에 힘을 쏟아온 창조경제연구회 이민화 이사장님이 지난 3일 별세하셨다. 삼가 고인의 명복을 빕니다.(한국어)

프로젝트

  • NoHQ : 리모트 업무에 도움이 되는 도구를 정리해 놓은 페이지.
  • Glimps : 최근 성장하는 회사, 제품, 분야를 알려주는 서비스. 이 링크에는 레퍼럴 링크가 포함되어 있습니다.

버전 업데이트

2019/08/15 22:37 2019/08/15 22:37