[GN#80] 회의도, 데드라인도, 풀타임 직원도 없는 회사

2021-01-11 ~ 2021-01-17 사이의 주요 뉴스들
지난 몇십 년간의 근무환경 변화 중에 가장 큰 것은 주5일 근무제의 정착이었던 것 같아요. 이미 유럽이나 미국에서는 주4일제를 시행하는 회사들도 꽤 있고, 국내에서는 조금 늦었지만 52시간 근무제 도입을 통해서 근무시간이 점점 단축되고 있는데요. 전 세계적으로 코로나 때문에 반강제적으로 WFH/Remote/재택근무라고 부르는 업무방식을 급격히 도입하게 되면서 또 다른 변화들이 일어나고 있습니다. 이번 주의 메인 뉴스는 풀타임 직원 없이 운영되는 회사 Gumroad의 업무 방식 이야기 입니다. 긱뉴스를 통해서 여러 번 소개해 드린 Gumroad 는 창작자들을 위한 이커머스 플랫폼 회사인데요. 이 회사는 대표를 포함해서 총 25명 모두가 일주일에 일정 시간만 일하는 방식으로 자유롭게 일을 하고 있습니다.. 이 회사에만 잘 어울리는 방식일 수도 있지만, 회의보다 비동기식 소통, 분기별 목표 대신 북극성 지표, 일년에 하나씩의 핵심 런치(Tentpole) 등 배울 게 많은 것 같습니다.

회사를 그만두는 것은 굉장히 중요한 일임에도 불구하고, 우리는 다소 감정적으로 즉흥적으로 결정을 하게 되기도 하는데요. "나는 왜 회사를 그만두고 싶어졌는가?" 글에서는 왜 퇴사가 하고 싶은지에 대한 이유를 나열하고 이걸 도표로 만들어서 "1) 도피욕구 점검 → 2) 분노 원인 분석 → 3) 한계 상황 분석 → 4) 목표 상실" 의 총 4단계로 분류하고, 각 단계에서 고민할 질문들을 통해서 좀 더 이성적으로 자신의 퇴사 결정을 냉정하게 분석해보라고 설명하고 있습니다.

아마존이 어떻게 AWS를 만들게 되었는가에 대해서는 다양한 전설 같은 이야기들이 전해지는데요. 킨들팀의 첫 번째 멤버였던 Dan Rose는, 아마존이 예전에 사용하던 장비를 Linux 장비로 교체한 것이 AWS의 시작이 되었다는 것을 트윗 쓰레드를 통해서 얘기를 풀어냈습니다. 위기를 기회로 풀어낸 상세 과정도 재미있지만 그 글의 결론에 쓰여 있는 문장이 중요한 것 같아요.
"좋은 위기를 낭비하지 마세요."
"최고의 기업은 모든 도전을 기회로 보고, 그 사고방식을 그들의 문화에 새깁니다"


✓ 사내에서 슬랙을 쓰신다면 뉴스채널에 GeekNews SlackBot 을 추가하여 편하게 새 글을 받아보시고, 멤버들에게도 공유해주세요.
✓ 주위분들께 긱뉴스 위클리 - https://news.hada.io/weekly 를 추천해 주세요.
Twitter , Facebook 에서도 긱뉴스를 받아 보실 수 있습니다.
✓ 긱뉴스를 팟캐스트로 들어보세요 : 애플, 유튜브, 팟티, 팟빵, 구글, 네이버 오디오클립
✓ GeekCast : 최신 데이터 인프라 이해하기 (시리즈) , 실패하지 않는 뉴욕타임즈 - NYT는 어떻게 디지털화에 성공했나 (48분)

매주 월요일 아침, 지난 일주일간의 GeekNews 중 엄선한 뉴스들을 이메일로 보내드립니다.


회의도, 데드라인도, 풀타임 직원도 없는 회사

- 창작자를 위한 플랫폼 Gumroad의 일하는 방식 이야기
- 총 25명이 일하지만, 대표 포함 누구도 풀타임으로 일하지 않음
ㅤ→ 하지만, YoY로 85% 성장, 년 매출 120억달성, 창작자들은 1900억원을 벌었음
- 우리가 일하는 방식을 카피하길 바라지 않음. 우린 큰 계획에 의한게 아니라 우연히 이렇게 되었음
ㅤ→ 그래도 다른 사람들 또는 그들의 고객에 도움이 될거 같아서 정리해 봄

[ Freedom at all costs, 무엇보다도 자유 ]

- 2015년에 정리해고를 했지만, Gumroad 는 계속 성장
- 그렇지만 풀타임(상근) 직원을 고용하고 샌프란시스코에 사무실을 두는 것은 불가능했음
- BigBinary라는 인도 회사를 통해서 계약직을 고용
- 이 계약직들이 회사를 살렸음. 내가 기능을 설계하고, 서포트 티켓에 답변하고, 새로운 걸 만드는 동안 그들이 버그를 잡고 사이트를 유지보수함
- 정리 해고 했던 고객지원 담당 직원을 시간당 계약으로 재고용했음
- 그러면서 Utah 로 옮기고, 풀타임 창작자가 되어보기로 함
- Gumroad는 이제 1조 회사가 되지 못하지만, 나는 중요한 "시간"을 얻었음. 이것으로 글을 쓰고 그림을 그리는 수업을 들음
- 난 번아웃 상태였고, 필요이상으로 일하는 것에 대해 생각하고 싶지 않았기에, 난 "미팅 과 데드라인 없는 문화"를 도입했음
- "어떤 대가를 치르더라도 성장" 대신 "어떤 대가를 치르더라도 자유(Freedom at all costs)"
- 이 방식으로 Gumroad 는 수익을 유지하면서도, 취미를 위해 적절한 휴식을 취할수 있고, 시간이 지나면서 제품은 계속 개선 되었음

[ How we work, 우리가 일하는 방식 ]

- Gumroad 에서 일하는 것은 Rails같은 오픈소스 프로젝트에 일하는 것과 비슷. 하지만 오픈소스가 아니고, 돈을 받는다는 차이가 있음

- 회의가 없는 대신, GitHub/Notion 그리고 가끔 Slack으로 얘기를 함. 24시간내에 답변을 받길 기대하며
- 스탠드업 및 "동기화(sync)"가 없기 때문에 명확하고 사려깊은 의사소통 방식이 필요
ㅤ→ 모든 사람이 글(문서)을 잘 써야하고, 많이 써야함

- 데드라인도 없음. 점진적으로 ship하고, 개발중인게 현재 프로덕션보다 좋을때 마다 배포함
- 물론 세금처럼 특정 기한을 가지는 것들이 있긴 하지만, 원칙적으로 누구에게도 뭘 해야하는지, 얼마나 빨리해야 하는지 말하지 않으려고 노력함
- 새로 누군가 조인하면, 다른 사람들이 하는 일을 함 : Notion 대기열에 가서 작업을 선택하고 일을 시작, 필요할때는 설명을 요청

- 분기별 목표나 OKR을 사용하는 대신, 하나의 목표(북극성 지표)를 가지고 움직임 : "창작자의 수익을 극대화 하는 것"
- 이건 간단하고 측정가능하므로 회사의 모든 사람이 기능이나 버그수정의 가치를 계산할 수 있음

- 하지만, 무자비하게 우선 순위를 정하진 않음
- 사람들은 재미있는 일을 하거나 직관에 의존할 수 있음. 우리가 수익성을 유지하고 배포를 계속하는 한, 결국 중요한 것을 해내게 되기 때문
- 공개된 로드맵은 창작자들이 우리가 이것을 책임지도록 함(accountable)
ㅤ→ https://www.notion.so/gumroad/Roadmap-ce2ad07c483046e7941227ad7810730d

- 거대한 제품들도 이런 방식으로 ship(배포)함
- 2020년 11월에, 1년간 준비한 정기결제 모델인 Gumroad Membership을 런칭했고, 현재 수백명의 창작자가 월 150만불 이상을 벌고 있음
ㅤ→ Gumroad, Membership 서비스 공개 https://news.hada.io/topic?id=3232

- 멤버쉽 서비스를 개발한 엔지니어 Helen Hood 가 말하길,

"내 경력에서 가장 큰 제품 출시였고, 한번의 회의나 화상회의 없이 출시를 진행했어요.
나는 개방형 사무실과 칠판,스탠드업 미팅 및 스프린트 계획이 있는 일반적인 스타트업에서 일해봤고,
의사소통이 거의 없이 자신의 프로젝트만 보는 원격팀에서도 일해봤지만,
Gumroad 에서 일하는 방식이 가장 이상적이에요.
내 생산 시간을 극대화 하도록 해주고, 내 한계에 도달 하면 쉴수 있습니다."

이 말은 좀 광범위 하니까, 이걸 각각의 문서로 정리해보면
( 각 링크의 문서도 굉장히 재미납니다 )

• 다음에 뭘 할지 어떻게 결정하나요? https://notion.so/gumroad/…
ㅤ→ "하루가 끝나갈때쯤 Gumroad에 다양한 감정이 듭니다. 예술 프로젝트와 별반 다르지 않아요. 우린 때때로 재미있고 일하기 좋은걸 선택합니다. 창작자들이 말하는 걸 듣는걸 좋아합니다. 어떤 일이 가치가 있는지 결정하기 위해 수많은 데이터 분석을 하지는 않습니다."

• 어떻게 의사소통 하나요? https://notion.so/gumroad/…
ㅤ→ "폰의 모든 알림을 끄세요"

• Gumroad에서 일하는건 어떤 느낌인가요? https://notion.so/gumroad/…
ㅤ→ "우린 점진적,반복적으로 Ship하고 1년에 한번 대규모 핵심출시(tentpole launch)를 합니다. 매월 창작자가 얼마나 많은 수익을 얻었는지 확인하고 계속 진행합니다. 여행 자체가 재미난 것이지, 목적지에 도착하는 것을 기다리지 않습니다."

• Gumroad에서 안좋은 점은 ? https://notion.so/gumroad/…
ㅤ→ "성장의 여지가 많지 않습니다. 수익성을 유지하고 있고, 내년에 팀을 두배로 늘릴 계획같은건 없습니다. 몇가지 리더십 역할이 있을수 있지만, 그 수가 많지 않고 Gumroad의 커리어 패스에 포함되어 있지 않습니다"

- Gumroad 의 Chris Maximin 이 말하길,

ㅤ"이렇게 일하는 방식은 제가 경함한 최고 수준의 생산성을 보여줍니다.
ㅤ실제 업무에만 집중할수 있도록 하기에 회사와 근로자 모두에게 이익이 되는 선순환을 만듭니다.
ㅤ1) 회사는 끝없이 쓸모없는 회의에 참석하기 위해 값비싼 엔지니어를 고용할 필요가 없고
ㅤ2) 엔지니어가 더 많은 일을 하고 배우게 됩니다.
ㅤ이게 장기적으로는 그들에게 더 이득입니다"

- 이것은 꼭 엔지니어에게만 해당하는 것은 아님
ㅤ→ 고객지원, 위험관리, 콘텐츠, 성장, 제품 우선순위 결정, 디자인 피드백 등이 다 이런 방식으로 처리됨

[ Minimum Viable Culture, 최소 실행 가능 문화 ]

- 이렇게 일하는 방식은 모두에게 맞지는 않음
- Retreat(휴양,수련회 등의 의미)도 없고, 슬랙에 소셜 채널도 없음. 성장의 기회도 제한적임. 큰 회사들이 제공하는 보상패키지 들과는 경쟁할 수 없음
- 하지만 우린 유연성(flexibility)에서 경쟁하고 이길수 있음
- Teachable 의 제품담당 부사장이었던 Sid Yadav는 2018년에 Gumroad에 조인했음. 그가 말하길

ㅤ"대부분의 기업가들은 두가지 옵션이 있습니다.
ㅤ풀타임 직업을 가지고 밤/주말에도 일하거나,
ㅤ직장을 그만두고 회사를 시작하는 위험을 감수하기.
ㅤGumroad는 세번째 방법을 제공합니다.
ㅤ난 일주일에 20~35시간만 계약해서 일하고,
ㅤ일주일에 이틀정도는 내 새로운 일을 위해 아이디어를 키울수 있었습니다."

2020년에 Sid는 Gumroad를 떠나서 자신의 창작자 이코노미 회사인 Circle https://circle.so/ 을 차림. 다른 Gumroad 동료와 함께
ㅤ→ Circle은 회원제 유료 커뮤니티 플랫폼

- Gumroad 에서 일하는 것은 누군가의 정체성의 전부가 아님
ㅤ→ 자신의 시간과 에너지를 쓸 삶의 다른 부분( 창의적인 부업, 가족, 그외 많은 것들)을 위해서 필요한 만큼만 Gumroad 에서 일함

- Gumroad 엔지니어인 Nathan Chan이 말하길,

ㅤ"나는 내 경력에 있어 다른 어떤 회사보다, 내 시간으로 더 많은 가치를 만들고 있음.
ㅤ육아에 완전히 참여하고 내 아이가 자라는 것을 볼수 있음"

- 이것엔 나도 포함됨(창업자인 Sahil)
ㅤ→ 2011년부터 2016년까지 Gumroad를 구축하는 것이 인생의 유일한 목표였음
ㅤ→ 요즘은 취미처럼 내 삶의 일부임
ㅤ→ 예를 들어 요즘은 재미로 그림을 그리고, 가끔씩 그림을 판매함

[ Company of Creators, 창작자들의 회사 ]

- 어느날 Daniel Vassallo로부터 이메일을 받음. 그는 Gumroad 에서 1년에 25만불(2.8억)을 버는 창작자였기에 이미 누군지 알고 있었음
- 그가 우리 서비스를 이미 사용하고 있었기에, 다음에 해결할 문제가 뭐고, 자신이 뭘 도울수 있을지에 대한 아이디어가 있었음

ㅤ"저는 Gumroad를 사랑해요(이걸로 살아가고 있죠!).
ㅤ제품의 범위와 전략을 좋아하고 있어서, 내가 PM 작업을 맡을수 있다고 생각합니다.
ㅤ하루에 평균 2시간 정도만 할애 할 수 있겠지만, 매일 가능해요.
ㅤ이게 당신들이 원하는 방식의 Commitment인지는 모르겠지만, 이게 가능한 곳이 Gumroad라고 생각합니다."

- 이건 완벽하게 잘 맞았고, Daniel 은 우리의 Head of Product 가 되었음.
- Gumroad 에도 큰 도움이 되는게, Daniel 이 Amazon 에서 그만두기 전에 그는 일년에 40만불을 벌었지만, 우린 그에게 일년에 12만불만 지불합니다.
- "어떻게 그렇수 있냐구요? 그는 일주일에 10시간만 일합니다"

[ Getting Paid, 급여 받기 ]

- 실제로 우린 각자의 Role에 따라 시간당 비용을 지불합니다. 범위는 시간당 $50(고객 지원) 에서 $250(Head of Product) 까지 다양합니다.
ㅤ→ ( 그러니까 Daniel은 하루에 2시간 500달러씩 일년에 240일 = 12만불 받고 일하는 것 )

- 최근에 나는 전세계적으로 급여를 표준화 했습니다.
ㅤ→ 근무자가 샌프란시스코, 방갈로(인도), 라고스(나이지리아) 등 위치에 상관없이 동일한 급여

- 이 급여는 인터뷰 프로세스 중에 서로 협의.

ㅤ1. 양식을 통해서 지원
ㅤ2. 급여를 받지 않는, 몇시간 짜리 챌린지를 진행
ㅤㅤㅤ→ Gumroad 에서 실제 일하는 상위 레벨 업무와 비슷.
ㅤㅤㅤ→ 큰 배포를 쪼개거나, 새 기능의 스키마를 디자인하거나, 고객센터의 아티클을 작성하거나)
ㅤ3. 급여를 받는, 몇주짜리 Trial 기간을 거침.
ㅤㅤㅤ→ Gumroad 에서 매일 진행하는 업무와 비슷
ㅤㅤㅤ→ 버그 수정, 기능 배포, 고객 지원 티켓 답변

- 회사내에 모든 사람의 평균 근무시간과 받는 급여를 정리한 문서가 있음. 이걸 통해서 각 팀이 보상결정을 할때 대표만큼 정보를 가질수 있음

- "잔업 방지(anti-overtime)" 비율이 있어서, 일주일에 20시간이 넘어가면 급여의 50%만 받으며 더 일할수 있음.
ㅤ→ 이걸 통해서 가장 높은 레버리지 작업에 대해 높은 시간당 레이트를 가질수 있고, 사람들이 원하면 주당 더 많이 일할수 있음.

- 이 유연성과 현금 외에는 어떤 종류의 특전도 없음
- 분명히 말해두지만, 의료서비스를 제공하지 않음. 모든 직원은 자신의 건강관리에 대해 책임이 있고, 자신의 전화/노트북/인터넷 및 기타 필요한 것을 모두 각자 지불해야함.
- 이 시스템에는 단점이 있음. 사람들은 자신이 일하는 시간을 추적해야함. 어떤 사람들은 일이 조금 더 많거나 적더라도 그냥 일주일에 20시간만 청구하기도 하고, 어떤 사람들은 15분단위로 부지런히 추적해서 매우 자세한 청구서를 보내기도 함

- Daniel 이 Quater-time(하루 8시간중 2시간만 일하는) Head of Product로 합류한 후, Randall Kanna도 Head of Community 로, Philip Kiely 도 Head of Marketing 으로 모두 2시간만 일하는 형태로 합류했음. Randall,Philip 역시 모두 Gumroad 창작자 이기도 함.

- 창작자들은 자신이 뭔가를 만들어서 돈을 버는데, Gumroad 도 똑같이 할수 있지 않을까요 ?
ㅤ→ 이게 바로 Creator Economy(창작자 경제)에서 일하는 느낌이어야 합니다.

[ The future of work is not working, 일의 미래는 일하지 않는 것 ]

- 최근에, 저는 풀타임 직원없이 회사가 성장하는 것이 잘못되었다고 생각해서 전체 풀타임 근무에 대해서 얘기했지만..

ㅤ"아무도 받아들이지 않았습니다."

- 그때 내가 "normal"한 방식으로 일해서 기분이 좋아지기 위해, 망가지지 않은 것을 고치려 한다는 것을 깨달았음
- 우리가 이미 하고 있는 방식이 멤버들이 우선 순위를 두고 있는 것에 더 좋음.
ㅤ"freedom over growth, sustainability over speed, life over work."
ㅤ"성장보다 자유, 속도보다 지속가능성, 일보다 삶"

- Gumroad 홈페이지에는 이걸 사용하려는 창작자에게 장점에 대해 명확히 설명.
ㅤ"9-5시 일하는 것에서 벗어나서, 양복과 넥타이를 벗고, 통근을 버리세요.
ㅤ당신의 작업물(craft)에 대한 대가를 받으세요"

- "진부하지만(cliché) 우리는 창작자를 위한 창작자의 회사가 되고자 합니다."

제가 Hada 와 GeekNews 를 만들고 운영하는 방식과 거의 비슷합니다. ㅎㅎㅎ
긱뉴스도 서두르지 않고 천천히 기능을 만들고 사용자를 늘려가고 있어요.

2015년에 정리해고를 했던 경험들을 포함한 Gumroad 창업자의 이야기는 아래 글에서 자세히 보실수 있습니다.
- 1조 회사를 만들다 실패한 경험 이야기 https://news.hada.io/topic?id=2

글에서 언급한 Head of Marketing 인 Philip Kiley 가 이 내용이 진실이라고 자신의 의견을 적었습니다.
- https://news.ycombinator.com/item?id=25674516

이 글의 제목처럼 Gumroad 와 비슷하게 회의/데드라인/상근 직원 없는 회사만 모아보는 페이지도 벌써 생겼습니다.
- https://creatorjobs.co/

 
나는 왜 회사를 그만두고 싶어졌는가

아주 예전에 북마크 했던 글인데.
좋은 글이라 올립니다.

나는 왜 회사를 그만두고 싶어졌는가

1단계 - 도피 욕구 점검 (내 안의 도망치고 싶은 심리 확인하기)
2단계 - 분노 원인 분석 :
3단계 - 한계 상황 분석 :
4단계 - 목표 상실

 
아마존이 HP/Linux로 교체한게 AWS의 시작

- 2000년 닷컴 버블 시절 아마존의 가장 큰 비용은 데이터센터의 비싼 Sun 서버들
- 1년에 걸쳐서 Sun을 걷어내고 HP/Linux로 교체한 것이 AWS의 기초가 되었음
- 그 시절 아마존의 모토는 "Get big fast". 사이트가 다운되면 바로 손실로 이어졌기에 안정성이 중요했음
ㅤ→ 그래서 Sun 장비가 비싸고 독점적이지만, 가장 신뢰할 수 있었기에 모든 인터넷 회사들이 사용했음
- 2000년도에 VC한테 투자받은 스타트업들이 사업을 중단하면서, 새 Sun서버들이 ebay 에 1달러도 안되는 가격으로 등장하기 시작
- 이때 아마존은 Sun과 더 나은 거래를 협상할 수도 있었지만, Jeff는 더 급진적인 접근방식을 택함
- 그시절 아마존의 CTO는 월마트 출신의 Rick Dalzell로, 그는 전체 기술조직을 중심으로 Sun을 HP/Linux로 대체
- 리눅스 커널은 Jeff가 아마존을 시작한 같은 해인 94년에 출시되었음. 6년이 지난뒤, 새롭고 위험한 접근 방식으로 회사를 베팅
- 전환하는 동안 제품 개발이 중단되고, 1년 이상 새로운 기능 출시를 동결했음. 엄청난 백로그가 있었지만, Linux로의 전환을 완료할 때까지 아무것도 ship 할수 없었음.
- 또한 현금소진을 줄이기 위해 가격을 올리면서 수익 성장이 둔화. 안 좋은 순환이었고, 돈이 줄어들면서 시간이 부족했음. 이러다 파산하기 몇분기 전 이었음
- 그러나 Linux 전환을 시작하자 돌아갈수 없었음. 코드베이스를 리팩토링하고, 서버를 교체하면서, 컷오버(빠른 단계 전환)을 준비함
- 작동한다면 인프라 비용이 80+% 이상 감소하고, 실패하면 웹사이트가 무너지고 회사가 망할 것
- 마침내 제 시간내에 문제없이 전환을 완료. 전체 기술팀에게 큰 성과였음. 사이트는 중단없이 계속되었고, CAPEX(설비 투자 비용)가 하루밤 새에 대폭 감소.
ㅤ→ 그리고 갑자기 무한 확장 가능한 인프라가 생김
- 그러자 더 흥미로운 일이 생김. 리테일러로서 매년 11/12월마다 트래픽과 매출이 급증하는 큰 계절적 상황을 겪고 있음
ㅤ→ Jeff는 "우린 연간 46주는 초과한 서버 용량을 보유하고 있는데, 이걸 다른 회사에 임대하는 건 어떨까 ?" 라고 생각하기 시작
- 같은 시기에 Jeff는 내부 종속성을 분리(Decoupling)해서 팀들이 다른 팀의 통제없이 개발하도록 하는데 관심이 있었음
ㅤ→ 이 느슨한 결합 모델을 활성화 하는데 필요한 아키텍처 변경이 AWS를 위한 API 기본 요소가 되었음
ㅤ→ 참고 : 아마존 역사에서 가장 중요한 제프베조스의 2002년 사내 메일 https://news.hada.io/topic?id=638
- 이것들이 AWS를 만든 기본 Insight. Jeff가 전사 미팅(All-hands)에서 전력그리드 관점에서 이 아이디어를 설명한 것을 기억함
ㅤ→ "1900년대에 기업은 상점을 열기 위해서 자체 발전기를 가져야 했습니다. 2000년대에 기업이 자체 데이터 센터를 구축해야할 이유는 뭘까요 ?"
- 클라우드 인프라는 AWS 없이도 등장 했을 것(예를 들어, Tesla 없는 전기자동차 처럼) 하지만 얼마나 후에 어떤 기회비용으로 가능 했을지는 모름
ㅤ→ AWS가 회사를 시작하는 비용을 크게 줄인 후 혁신이 폭발하고, 현대적인 VC 에코시스템이 탄생 했음
- 아마존은 2000~2003년에 거의 죽을뻔 했지만, 이런 위기가 없었다면 완전히 새로운 아키텍처로 전환하는 어려운 결정을 내리지 않았을 것
ㅤ→ 이 변화가 없었다면 AWS는 만들어 지지 않았을 것. "좋은 위기를 낭비하지 마세요"

- PS : 아마존은 최근 Oracle을 뜯어 내는데 몇년이 걸렸음. 힘든 일을 하려면 근육이 필요하고, 힘든 일을 함으로써 근육이 만들어짐
ㅤ→ "최고의 기업은 모든 도전을 기회로 보고, 그 사고방식을 그들의 문화에 새깁니다"

관련해서 실제로 교체한 장비는 Sun이 아니라 Compaq/Digital Tru64 Alpha 서버 였다는 Peter Vosshall의 답변이 있네요.
- https://mobile.twitter.com/PeterVosshall/status/1347697560249458689
Peter는 AWS에서 은퇴한 엔지니어라 이쪽이 더 신뢰할만 합니다.
다만, 전체 흐름상 Sun인지 Alpha인지는 중요치 않아서 그냥 원문을 그대로 번역했습니다.

* 리눅스 커널은 Linus Torvalds가 만든 첫 버전은 91년에 나왔지만, 94년에 나온 1.0 기준으로 작성한듯 합니다.

AWS의 시작에 대해서는 이거 말고도 다양한 관점의 이야기들이 있습니다.
실제로 처음 시작이 EC2가 아니고, 실제 Web Service, SQS/S3 등이 먼저 였다고 얘기되기도 합니다.
https://news.ycombinator.com/item?id=25700519
역시나, 전체 글의 흐름상 중요치 않은 것 같아서 원문 그대로 옮겼으니 참고하시기 바랍니다.

이 트윗 쓰레드를 쓴 Dan Rose 는 킨들팀의 첫번째 멤버였는데, 아마존의 예전 얘기를 종종 이렇게 트윗 쓰레드로 남기곤 합니다.
- Kindle 개발 초기에 Jeff Bezos에게 배운 것 https://news.hada.io/topic?id=2602

 
Learn X by Doing Y

- 뭔가를 학습 할 때 프로젝트 기반으로 배울수 있는 자료 모음. 검색가능
ㅤ→ Project Based Learning
- 프로그램 언어 : Javascript, Python, C/C++, Rust , Go..
- 프레임워크 : Angular, Tailwind, NextJS..
- 하드웨어 : Arduino, Raspberry Pi..
- 그외 : Tensorflow, Keras, OpenCV 등
- 약 1000개 가량 ( 깃헙에 추가 가능 )

 
엔지니어링 매니저를 위한 추천 도서

개발만 하다가 관리자가 된 엔지니어들을 위한 책 7권 [원서 및 한글판]
- Manager's Path
ㅤ→ 개발 7년차, 매니저 1일차
- Thanks for the Feedback
ㅤ→ 하버드 피드백의 기술 : 밀어붙이는 피드백에서 끌어당기는 피드백으로
- The Hard Thing About Hard Things
ㅤ→ 하드씽 : 경영의 난제, 어떻게 풀 것인가?
- Accelerate : The Science of Lean Software and DevOps
ㅤ→ 디지털 트랜스포메이션 엔진 [ 고성과 기술 조직 구축 및 진화 ]
- Dare to Lead: Brave Work. Tough Conversations. Whole Hearts.
ㅤ→ 리더의 용기: 대담하게 일하고, 냉정하게 대화하고, 매 순간 진심을 다하여
- Switch: How to Change Things When Change is Hard
ㅤ→ 스위치 : 손쉽게 극적인 변화를 이끌어내는 행동설계의 힘
- Atomic Habits: An Easy & Proven Way to Build Good Habits
ㅤ→ 아주 작은 습관의 힘

ㅤ→ 개발 7년차, 매니저 1일차 - http://www.yes24.com/Product/Goods/87336637
ㅤ→ 하버드 피드백의 기술 : 밀어붙이는 피드백에서 끌어당기는 피드백으로 - http://www.yes24.com/Product/Goods/14759898
ㅤ→ 하드씽 : 경영의 난제, 어떻게 풀 것인가? - http://www.yes24.com/Product/Goods/15345272
ㅤ→ 디지털 트랜스포메이션 엔진 [ 고성과 기술 조직 구축 및 진화 ] - http://www.yes24.com/Product/Goods/90051525
ㅤ→ 리더의 용기: 대담하게 일하고, 냉정하게 대화하고, 매 순간 진심을 다하여 - http://www.yes24.com/Product/Goods/84781264
ㅤ→ 스위치 : 손쉽게 극적인 변화를 이끌어내는 행동설계의 힘 - http://www.yes24.com/Product/Goods/3776409
ㅤ→ 아주 작은 습관의 힘 - http://www.yes24.com/Product/Goods/69655504

제가 리디북스랑 알라딘 위주로 사용해서 개인적으로 정리하다가 여기도 댓글을 달아봅니다.

ㅤ→ 개발 7년차, 매니저 1일차 - https://ridibooks.com/books/443000823
ㅤ→ 하버드 피드백의 기술 - https://ridibooks.com/books/222001263
ㅤ→ 리더의 용기 - https://ridibooks.com/books/606002043
ㅤ→ 스위치 - https://ridibooks.com/books/606000997
ㅤ→ 아주 작은 습관의 힘 - https://ridibooks.com/books/1780000157

→ 하드씽(절판) - https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=49591677
→ 디지털 트랜스포메이션 엔진 - https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=238215326

 
Bubbles - 화면/영상에 댓글로 원격 협업하는 도구

- 화면/앱을 녹화/캡쳐한뒤 URL로 팀원들과 공유하는 협업 툴
ㅤ→ 작성자만 크롬 확장 설치 필요, 수신자는 툴 설치 필요 없음
- 화면의 특정 위치 또는 녹화한 영상의 특정 시간대에 댓글 달기
ㅤ→ 다른 사람이 답변 남기거나, Resolve 눌러서 확인 가능
- 별도 가입 필요없음. 무료.

 
Backslide - HTML 발표자료 쉽게 만들기

- Remark.js 와 Markdown을 이용한 HTML 슬라이드 만들기
- CLI 로 간단히 기본구조 생성하고 마크다운 편집
- Sass 템플릿 생성기
- 개발 서버 내장
- CSS/JS까지 하나로 묶은 HTML 또는 웹사이트 로 Export해서 서비스 가능
- 자동 PDF 변환 (Decktape 이용)

개발관련 발표자료 만들기에 딱 좋네요.
마크다운 편집하면, 개발서버가 브라우저에서 자동으로 리로드해서 보여주니 후다닥 만들수 있군요

https://marpit.marp.app

마크다운으로 슬라이드를 만드는 도구하면 이런 것도 있고,
mdx-deck 도 좋은 대안 중 하나입니다.

https://github.com/jxnblk/mdx-deck

 
Extension·dev - 크롬 확장으로 도구 만들기

- Contextual Internal Tools : 특정 페이지 위에서만 동작하는 확장 도구 만들기
ㅤ→ 회사 내부용 도구를 크롬 확장으로 만들고, 기능 추가를 도와주는 개발 툴
- 웹페이지에 버튼을 넣거나 설명을 넣는 등의 조작 가능
- 웹페이지의 데이터를 추출해서 API호출하거나 처리
- 접근 권한 관리
- DB 및 API, SaaS 도구 접근 가능

아직 개발자 프리뷰 단계인데, 재미난 아이디어 같아요.
회사에서는 수많은 사내용 도구들(백오피스 라고 부르는)이 필요한데
크롬 확장으로 그거를 더 편하게 만들거나, 다른 기존 도구를 확장하는게 가능하겠네요.

Google Analytics 에 뭔가 사내 데이터를 조합해서 보이는 기능을 추가 한다거나
실제 서비스 사이트를 사내용 확장 깔고 들어가면 별도의 메뉴를 보여주고 사용할수 있게 하는 것이 가능해 질 듯.

 
10기가비트 홈 네트워크 구축하기

일반 사용자용 10기가비트 인터넷이 2018년 상용화된 이후, 지역 전화국에 10기가 장비가 들어오기 전 미리 10기가비트 홈 네트워크를 구축해보며 어떤 고민을 했고 어떤 장비를 어떤 이유로 선택했는지, 실제 구성 시 어떤 부분을 고려해야 하는지 등에 대한 내용을 정리해서 올렸습니다.

Fun fact: Cat.5e 케이블을 이용해 10Gbps throughput이 나오는지도 테스트해 보았는데 아무런 문제가 없었습니다.

SOHO 수준으로는 Ubiquiti로 충분히 차고 넘칠 정도로 사용이 가능한 것 같습니다. 무엇보다 SW(UniFi OS)가 애플이 네트워크 사업에 진출했다면 이렇게 만들지 않았을까 싶을 정도로 UI/UX/반응성이 훌륭합니다. ㅎㅎ

10Gbe 구축시 고려해야할 점을 조목조목 설명해 주셔서 좋네요.
특히 Cat 케이블 말고 DAC케이블 쓰라는 점은 저도 처음에 구축할때 몰랐다가 큰일 날 뻔했던 사항이네요.

저는 극한의 가성비를 위해서 미크로틱 CRS305-1G-4S+IN 에다가 원래 쓰던 DIY NAS에 라우터용 OS인 opnsense (pfsense의 포크) 가상머신을 돌리고 있는데 성능 괜찮게 나오네요. 다만 Ubitquiti 의 이쁜 웹GUI는 부럽네요 ㅠ

2020년 들어서 웬만한 새 보급형 메인보드에도 2.5기가 이더넷을 탑재하고 출시하기 시작해서, 얼마 안가서 가정용 가성비 10/5/2.5Gbe 장비들이 많이 출시하지 않을까 생각합니다.

 
Rewatch - 팀/회사를 위한 비디오 공유

- 회사내에서 진행되는 모든 회의/교육/발표 비디오를 저장 및 공유
ㅤ→ 교육 세션, 주간 회의, 제품 개발 회의, 타운 홀..
- 모든 음성 내용은 자동으로 Transcribe(받아쓰기) 되고 검색 가능
ㅤ→ 인식된 텍스트에 대해서 코멘트 달고, 팀원 멘션 가능
- 누가 무엇을 봤는지 공유
- Zoom/Meet 회의 영상을 자동으로 동기화 & 임포트
- Dropbox/Google Drive 에 저장된 비디오 동기화
- Slack 으로 알림
- Okta 로 접근관리
- 현재 얼리 억세스중

 
최소한의, 그리고 안전한 Bash 스크립트 템플릿.

" 자전거를 타는 거랑 비슷해의 반대말은 '배시에서 프로그래밍하는 거 같아' 입니다.

아무리 몇 번이나 무슨 짓을 하던 할 때마다 처음부터 다시 배워야 한다는 뜻입니다."

이 문구로 시작하는 이 글은, 여타 다른 프로그래밍 언어와 다르게 고개만 돌리면 까먹는 Bash 스크립트의, 작고 안전한 템플릿을 소개합니다.

 
개발자를 위한 애플 실리콘 M1 맥 세팅

- iTerm2 설치
- Oh my zsh 설치
- zsh 꾸미기
- homebrew 설치
- go 언어 설치하기
- 도커(프리뷰) 설치

 
Google의 Go 팀 리드 spf13과의 인터뷰

- Golang이 공개된지 13년이 지난 현재, Google Go 팀에서 Product & Strategy 리드를 맡고 있는 spf13을 infoq에서 한 인터뷰

- Go의 심플함 덕분에, 빠르게 Go를 시작해볼 수 있다. 반나절이면 Go의 전체를 훑어볼 수도 있다.

- Go가 오늘날 최고의 모던-언어라고 생각한다.(Dart+Flutter, Rust와 함께)

- Go의 미래는 모든 기능 제안에 대해 논의하고 토론하는 오픈소스 커뮤니티에 의해 형성된다. 명확한 합의에 도달하지 않으면 기능이 구현되지 않는다.

- Go 사용자 커뮤니티의 크기는 약 18 개월마다 두 배로 커지고 있다.

- 처음에는 Python이나 Ruby 같은 다이나믹 언어를 사용하던 유저들이 Go를 선택했지만, 이제는 언어가 성숙해지면서, Java, .Net과 C++를 사용하는 프로그래머도 GO를 사용하기 시작했다.

- 어려운 날들 속에서, 커뮤니티는 서로를 돕도록 적응했고, 많은 밋업이 열렸으며, 새로운 리소스들이 있었다.

---

spf13은?

- 현재 Google 소속으로 Golang의 개발을 리드하고 있으며, MongoDB의 Chief Developer Advocate, Docker의 COO 등을 경험했다.

- Golang 커뮤니티에서 가장 유명한 라이브러리를 다수 작성했다. Hugo, cobra, viber, ...

 
Linksys WRT54G의 역사

실수로 오픈소스가 되고 유명해져버린 공유기 이야기

- Linksys 는 대만 출신 미국 이민자 둘이 설립한 회사
- 1990년대엔 가정용 네트워크/공유기 시장은 거의 존재하지 않았음
- 90년대초엔 링크시스 장비들은 자체 네트워크 드라이버를 제공해야 해서 불편했지만,
ㅤ→ 윈도우95가 네트워크 드라이버를 내장하면서 쉬워지고, 수요가 증가
- 90년대말 가정용 브로드밴드 인터넷이 들어오면서 라우터 시장이 생겨남
- 설치가 쉽고 사용하기 편한 파랑/검정색으로 디자인된 $199짜리 라우터를 만들어 큰 성공
ㅤ→ 100메가 비트, 4개의 포트로 가정용에 합리적인 가격
- 2003년 Cisco 가 5억달러에 Linksys를 인수
- 인수하기 몇달 전 발표한 WRT54G 라우터 모델이 특히나 인기를 끌게 됨. "전혀 예상하지 못했던 이유로"
ㅤ→ 이 라우터는 Linux 기반이었고, 사용된 무선 펌웨어 코드 때문에 GPL 로 소스코드를 공개해야 했음
ㅤ→ 하지만 개발한 Linksys도 인수한 Cisco도 이에 대해 잘 몰랐음.
ㅤ→ Broadcom 칩셋을 썻고, 칩셋 펌웨어는 해외 개발자에게 아웃소싱했기 때문
ㅤ→ 이에 대해 슬래시닷에서 논란이 있고 나서, Cisco가 오픈소스 버전 펌웨어를 발표
- 해커들이 뛰어 들어서 기능을 추가하기 시작
ㅤ→ FTC가 제한하는 세기보다 더 세게 무선 시그날을 쏘게 하거나
ㅤ→ VPN을 추가하거나, 로봇의 두뇌로 활용하기도
- 이 기반으로 OpenWrt 와 Tomato 같은 오픈소스 펌웨어들이 만들어짐
- 시스코는 이 성공을 그다지 좋아하지 않았고, 리눅스를 제거한 버전을 출시했지만 환영받지 못함
ㅤ→ 끝내 다시 리눅스 버전의 WRT54GL 을 출시했고 이것은 아직도 팔리고 있음
ㅤ→ Linksys WRT54GL $39.99 https://amazon.com/Linksys-WRT54GL-Wireless-G-Broadband-Router/dp/…

"WRT54G 는 무선공유기의 NES(Nintendo Entertainment System)"

 
GCP Sketchnote - 그림으로 배우는 구글 클라우드

- Google Cloud Platform 의 여러 개념들을 이해하기 쉬운 스케치로 설명
ㅤ→ Compute Engine, Cloud Run, Cloud Functions, GKE, GCS, Cloud SQL
ㅤ→ Data Analytics Pipeline, Redshift to BigQuery
ㅤ→ Cloud Composer, Dataflow, Dataproc, Pub/Sub, Armor, CDN, Load Balancing, Build
ㅤ→ Contact Center AI
- 구글의 Developer Advocate인 Priyanka Vergadia 의 개인 저장소

 
Google’s recommended architecture for Android apps

Android Architecture 그림과 설명이 잘 요약되어 있습니다.
아주 자세하지는 않으나 한번 쓱 훝어보기에는 괜찮은 것 같습니다.

 
JuiceFS - Redis와 S3를 이용한 분산 POSIX 파일시스템

- POSIX 완전 호환으로 기존 어플리케이션들도 모두 사용가능
- 몇ms단위 레이턴시로 훌륭한 성능
- BSD 락(flock) 과 POSIX 레코드 락(fcntl) 모두 지원
- LZ4로 기본 압축(ZStandard도 선택가능)
- Redis를 파일시스템 메타데이터 저장소로 활용
- 클라우드 객체 저장소를 활용해서 무한 확장 가능한 공유 드라이브처럼 사용
ㅤ→ 로컬디스크, Amazon S3, Google Cloud Storage, Azure Blob Storage 및 알리바바/텐센트 등도 지원
- 차후 로드맵
ㅤ→ 쿠버네티스 CSI 드라이버
ㅤ→ Hadoop SDK
ㅤ→ S3 gateway
ㅤ→ Windows 클라이언트
ㅤ→ Redis 외에 다른 DB지원

 
2020 JavaScript Rising Stars

1년간 받은 깃헙 Star 기준으로 뽑은 JS 관련 도구 순위
- 인기 프로젝트 : Deno > Vue.js > React > Playwright > VS Code > esbuild > Vue Element Admin > eDEX-UI > Next.js > Tailwind CSS
- 프론트엔드 프레임워크 : Vue.js > React > Angular > Svelte > Alpine.js
- Node.js 프레임워크 : Next.js > Strapi > Next > Nuxt > Blitz
- React 에코시스템 : Next.js > React Query > Recoil > Ant Design > React Hook Form
- Vue 에코시스템 : Vue Element Admin > Vite > Nuxt > Element Plus > vue-next
- Angular 에코시스템 : ngx-admin > Material Design for Angular > Scully > Angular CLI > NG-ZORRO
- Build Tools : esbuild > Rome > Vite > Snowpack > Webpack
- CSS 프레임워크 : Tailwind CSS > Bootstrap > Bulma > new.css > Halfmoon
- CSS in JS : Styled Components > Twin > Emotion > Linaria > Theme UI
- 테스팅 : Playwright > Storybook > Puppeteer > Cypress > Headless Recorder
- 모바일 : React Native > Expo > Quasar > Ionic > Sonar
- JS Flavors/Compilers : TypeScript > swc > Babel > Reason > Flow
- State Management : Recoil > XState > Immer > Zustand > Redux
- GraphQL : Gatsby > Hasura GraphQL Engine > Redwood > Prisma > Apollo Client
- 교육 자료 : JS Algorithms & Data Structures > Node.js Best Practices > You Don't Know JS > Clean Code > 30 seconds of code

State of JS 2020 [한국어] - https://news.hada.io/topic?id=3586

이거랑 비교하면서 보니 재미나네요.
Next.js 와 esbuild, snowpack 이 눈에 띕니다.

작년 버전 : 2019년 한해동안 받은 GitHub Star갯수로 알아본 JavaScript 프로젝트 순위 https://news.hada.io/topic?id=1268

 
State of JS 2020 [한국어]

- 137개국, 23765명 설문조사, 영어가 82%
- 연봉$ : 50~100K 29.9% > 100~200K 20.7%
- 경력 : 5~10y 30% > 2~5y 27.9% > 10~20y 24.2%
- 남성 91% 여성 5.8%
- 풀스택 엔지니어 44.1% > 프론트엔드 33.6% > 웹개발자 12.1% > CTO 5.6% > 백엔드 3.7%
- 숙련도 : JS전문가 52.6% , CSS전문가 43.1%

- JS : Typescript 93% > PureScript 72% > Reason 71% > Elm 63% > ClojureScript 59%
- 프론트엔드 프레임워크 : Svelte 89% > React 88% > Vue.js 85% > Alpine.js 82% > Preact 78% > LitElement 78% > Stimulus 67% > Angular 42% > Ember 27%
- 데이터 레이어 : GraphQL 94% > Apollo 88% > Vuex 88% > XState 87% > Redux 67% > MobX 64% > Relay 56%
- 백엔드 프레임워크 : Next.js 92% > Express 92% > Fastify 89% > Nuxt 88% > Nest 87% > Strapi 79% > Koa 76% > Gatsby 70% > Hapi 60% > Meteor 28%
- 테스팅 : Testing Library 97% > Jest 96% > Cypress 94% > Playwright 93% > Storybook 91% > Puppeteer 88% > Mocha 74% > Jasmine 62%
- 빌드도구 : esbuild 94% > Snowpack 94% > TypeScript 92% > Webpack 88% > Parcel 85% > Rollup 85% > SWC 80% > Rome 60% > Gulp 35%
- 모바일&데스크탑 : Electron 89% > Capacitor 84% > React Native 82% > Native Apps 80% > Expo 76% > Quasor 70% > Ionic 52%

- 기타 라이브러리 : Axios, Lodash, Moment, date-fns, RxJS, jQuery, Underscore, Day.js > Immer , Ramda, Luxon..
- 에디터 : VS Code 18061명 > Vim 4196 > WebStorm 3888 > Sublime Text 2591 > Notepad++ 1715
- 브라우저 : Chrome 18733 > Firefox 10619 > Safari 4782 > Edge 3508
- JS 이외의 사용언어 : Python 6664 > PHP 5760 > Java 4209 > C# 3535 > Go 2501

- 가장 많이 보는 사이트 : CSS-Tricks > Medium > Dev.to > Smasing Magazines > JavaScript Weekly > Kent C. Dodds
- 즐겨듣는 팟캐스트 : Syntax 2916명 > Full Stack Radio 1165 > The Changelog 1074 > JS Party 921

 
Snowpack 3.0 릴리즈

- 스트리밍 import 지원 : 미리 설치하지 않고 필요할 때 자동으로 모듈을 설치
- 빌드 최적화 : Go로 작성된 초고속 번들러 esbuild 활용
- 새로운 JS API 로 빌드 파이프라인을 상세 관리 및 외부 연동 지원
- 새로운 Node.js 런타임

출시 1년만에 3.0 찍고 꽤 잘 성장하네요.
긱뉴스 통해서 계속 알려드리고 있어서 나름 뿌듯(?)

Snowpack - 웹앱을 번들러 없이 빠르게 빌드해주는 도구 https://news.hada.io/topic?id=1267
Snowpack 2.0 릴리즈 https://news.hada.io/topic?id=2174

 
Lutris - 리눅스용 게임 런처

- GOG, Steam, Battle.net, Origin, Uplay 의 각종 게임을 리눅스에서 실행하게 해주는 오픈소스 게임 플랫폼
- Wine, RetroArch, Dosbox, ScummVM 등 20종 이상의 Runner를 이용해서 윈도우 및 콘솔 게임을 최적화 해서 실행
ㅤ→ 윈도우, Sony PS2/PS3, Atari, Commodore, Web, MSDOS, Nintendo(3DS, Wii, Gameboy, NES, Switch)

리눅스에서 게임하려면 Wine 부터 설치할게 많았는데 가장 편한 방식인듯 합니다.