[GN#36] CTO/VPE 가 첫 90일 동안 해야할 일

2020-03-09 ~ 2020-03-15 사이의 주요 뉴스들
창업에 대한 가이드는 많이 있습니다만, CTO나 VPE가 되는 방법을 알려주는 곳은 많지가 않습니다. 특히나 기존 조직에 들어가서 기술책임자가 되어야 하는 개발자들을 위해 첫 90일간 해야 할 일을 정리한 글을 추천합니다. 또한 이 글은 반대로 CEO를 비롯한 경영진들에게 CTO가 하는 일을 알려주는 가이드가 될 수도 있습니다.

많은 회사가 기술 블로그를 운영합니다. 매력적인 기술 블로그의 공통점은 "승인 절차가 단순하고 경영진 또는 문화적인 지원"이라고 합니다. 앞에서 얘기한 CTO가 해야 할 일에도 기술 블로그 운영이 잠깐 나오는데요. 기업들의 개발자 채용을 위해서 기술 블로그는 필수 항목이고, 이는 기술 브랜드 수립으로 이어지게 됩니다.

이번 주에는 국내 개발자분들이 만드신 것이 몇 가지 있습니다.
- "종단암호화 지원하는 무제한 용량 실시간 파일전송 서비스"
- "just-news - 국내 언론사 뉴스 사이트에서 본문만 보기"
많은 응원 부탁드립니다.

"코로나19 공공데이터 핸드북" 은 코로나19 관련해서 국내 개발자들이 시빅 해킹(Civic Hacking)을 위해 만든 문서입니다. 정부는 데이터를 공개하고, 민간과 기관들이 협력해서 누구나 편하게 참여해 개발하는 과정을 보실 수 있습니다. 한번 둘러보시고 힘을 보태 주세요.

✓ 슬랙을 쓰신다면 GeekNews SlackBot 을 설치하고 편하게 새 글을 받아보세요
✓ 주위분들께 https://news.hada.io/weekly 를 추천해 주세요.
✓ 스팸함에 들어가지 않게 news@hada.io 를 주소록에 추가해주세요.
Twitter , Facebook 에서도 긱뉴스를 받아 보실 수 있습니다.

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


CTO/VPE 가 첫 90일동안 해야할 일

조직에 CTO 또는 VPE로 조인했을 때 해야 할 일과 수행 방법들을 분야별로 상세히 정리
0 우선순위 와 목표
1 조직을 이해하고 신뢰 쌓기
2 지원 시스템 구축
3 조직 건강 및 프로세스 챙기기
4 채용
5 실행
6 기술
7 읽을거리

아래는 제목과 주요 문장들만 간단히 번역한 것이라, 상세 내용들까지 보시길 추천드립니다.

새 조직에 와서 하지 말아야 할 표현들이 확 와닿네요
"아.. 이 기술은 끔찍한데, 어떤 바보가 이런 결정을 했나요"
"이전 직장에서 '우리'는.."

~~~

# 우선 순위 및 목표
1. 비즈니스가 어떻게 돌아가는가
2. 회사의 문화는?
3. 동료 및 이해관계자와의 건강한 관게
4. 팀이 올바른 작업을 효과적으로 수행하는지
5. 기술품질은 높은지
6. 팀의 모두가 참여하고, 사기가 높은지
7. 장기적으로 지속가능한 페이스인지

우선순위와 목표를 정했다고 바로 뛰어들어서 변화시키지 말것.
지속적으로 개선하는 것이 중요.
변화가 중요한게 아니라 '올바른' 변화를 만들어 내야함

### 90일간 해야할 일들 ###

- 첫 90일은 91일차부터 측정 가능하고,효율적인 실행을 하기위한 공부를 하는 것
- 배우는 도중에 맘에 안드는 부분을 발견하면, 고치는데 시간을 할애 가능. 그러면 아래 권장사항들을 3달 대신 9달에 걸쳐서 하는 것도 괜찮음
- 비상 사태에 신경을 쓰더라도 모든 시간을 할애하지는 말 것. 경영자로서 장기/단기 모두 성공 하도록 이끌어야 함
- 이 90일은 회사의 크기에 따라 다를수 있음

# 조직을 이해하고 신뢰 쌓기
1. CEO 혹은 CTO가 당신에게 원하는 것을 명확히 하기
2. 정말 잘못된거라 바로 신경써줘야 할 것을 파악
3. 리스닝 투어(각 개인과 개인적으로 만나서 듣기)
4. 정기 1:1 미팅 잡고, 어떤 레벨(직위)까지 진행하고 나머지는 스킵할지 결정
5. 관찰한것을 공유 (주간 이메일, 월간 올핸즈 미팅 등)
6. 정기 포럼/미팅 참석
7. 고객지원팀으로 들어오는 티켓들을 쉐도잉(같이 보기)
8. 고객미팅/파트너미팅/사용자 테스팅도 쉐도잉 해서 참석
9. 비즈니스 분석도구 찾고 질의하기

# 지원 시스템 구축
1. 비슷한 직무를 가진 사람들로 구성된 외부 서포트 그룹을 만들기 : 조직내에서는 당신과 같은 롤을 하는 사람이 아마도 없으니, 외부에서 찾아보세요.
2. 경영자 코칭 받기
3. 자기 관리를 위한 공간 만들기

# 조직 건강 및 프로세스
1. 조직의 기존 프로세스 문서화
2. 한두개의 변화만 적용하고 개선
3. 내년 조직의 성장 목표를 계획
4. 소통 채널 수립
5. 조직내의 비기술직군들에도 신경 쓸것
6. 모두 참여하는지 체크

# 채용
1. 기존 면접/온보딩 등에 쉐도잉해서 보기
2. 점검이 필요한지 결정
3. 3개 이하의 꼭 채용해야 할 주요 직무를 결정
4. 채용 퍼널과 채용 파이프라인을 트래킹
5. 기술 브랜드를 수립하기 위한 노력 시작 (기술블로그 개설, 컨퍼런스 발표)

# 실행
1. 현재 시스템이 어떻게 동작하고 확장가능한지 확인
2. 엔니지어링 속도의 내부 측정치 설정
3. 외부 속도 설정
4. 아주 약간의 프로세스와 제어 추가

# 기술
1. 기존 기술들이 효율적인가 ?
2. 기술적으로 중요한 것들은 어떻게 결정되는가
3. 사소한 변경을 빌드하고 배포해보기
4. 온콜 로테이션에 합류
5. 사고 리뷰에 참석
6. 기술 이력을 기록
7. 현재 기술전략을 문서화

 
좋은 회사 기술 블로그는 어떻게 운영되는가

매력적인 기술 블로그의 공통점
- 승인이 쉽거나 거의 필요없음
- 승인/편집 절차는 엔지니어들에게 게시물을 더 매력적으로 만듬
- C수준의 지원
매력없는 기술 블로그의 공통점
- 느리고 많은 승인 절차
- 기술 직군의 아닌쪽의 승인도 필요
- 승인/편집 절차는 주로 위험을 제거하거나, 특정내용 레퍼런스를 제거하거나, 게시물을 모호하게 만들어 엔지니어들에게 재미없게 만듬
- 하이레벨 지원 없음

인터뷰를 통해 정리한 잘 운영되는 회사 3곳의 프로세스

Heap
ㅤ▪ 누군가 글을 쓸 아이디어가 있다면
ㅤ▪ 작성자(엔지니어)는 글을 편집하고 승인해주는 "버디"와 페어링
ㅤㅤ▫ 버디는 좋은 글쓰기를 한 경력이 있는 엔지니어
ㅤㅤ▫ 몇번의 라운드를 거치면서 글의 요점(thrust)이 변경될 수도 있음
ㅤ▪ CTO가 읽고 승인
ㅤㅤ▫ 보통 마이너한 피드백
ㅤㅤ▫ "디자이너가 이 그래프 좀 더 보기 좋게 만들수 있겠는데요" 수준의 제안
ㅤ▪ 글 발행

ㅤ* 첫번째 편집단계에 초안을 슬랙채널에 공유하고 누구나 피드백 할수 있었는데,
ㅤㅤ별로 좋은 경험이 아니어서 이런 단계로 "너무 많은 피드백"을 받지 않도록 절차를 설계

Segment
ㅤ▪ 누군가 글을 쓸 아이디어가 있다면
ㅤㅤ▫ 종종 내부 문서, 외부 발표, 배포한 프로젝트, 자체 개발한 오픈소스 등에서 가져옴
ㅤ▪ 작성자(엔지니어) 가 초안을 작성
ㅤㅤ▫ 시니어 엔지니어가 초안 작업을 도와주기도 함
ㅤ▪ 최근까지는 피드백 프로세스가 없었음
ㅤㅤ▫ 코파운더와 엔지니어링 매니저가 주로 피드백
ㅤㅤ▫ 매니저 및 기술리드들로 부터 피드백
ㅤㅤ▫ 보통 3번째 드래프트 정도면 완성
ㅤㅤ▫ 풀타임 편집자가 편집을 시작
ㅤ▪ 기술팀에 알리고, 15-20 명 정도로부터 피드백 받음
ㅤ▪ PR이랑 법무팀이 보고, 가벼운 승인단계

ㅤ* 일주일간 블로그 쓰는 시간을 가지는 "Blogging Retreat" 제도
ㅤ* Writing 과 Speaking이 성과평가 및 캐리어 Ladder 에서 보상받을 수 있도록 명시적 기준을 수립

CloudFlare
ㅤ▪ 누군가 글을 쓸 아이디어가 있다면
ㅤㅤ▫ 내부 블로깅이 사내 문화중 하나, 몇몇 포스팅은 내부 블로그에서 가져옴
ㅤ▪ CTO는 모든 글을 읽고, 다른 사람들도 읽고 코멘트
ㅤㅤ▫ CTO가 글을 승인
ㅤ▪ CEO가 블로깅의 후원자
ㅤ▪ "매우 빠른" 법무 승인 절차, 1시간 이내의 SLO
ㅤㅤ▫ 너무 라이트해서 실제로 있는지도 모를 정도

3개의 회사만으로 적은글이라 이걸로 일반화 하기는 위험, 하지만 경영진 지원은 중요

국내에선 마켓컬리가 최근에 적어주신 글이 있는데 긱뉴스에 없네요. 연관해서 같이 보시면 좋습니다.
"기술 블로그를 다시 디자인하며" https://helloworld.kurly.com/blog/redesign-tech-blog/

스타트업 기술블로그 모음 개발 후기 https://news.hada.io/topic?id=1536
만드신 국내 스타트업 기술블로그 모음 사이트 주소가 바뀌었네요
https://metapost.dev/

 
종단암호화 지원하는 무제한 용량 실시간 파일전송 서비스

쑥쓰럽지만 올려봅니다.
대기시간을 없애고 빠르게 공유한다는 한가지 목표만 가지고 만들었습니다.
-업로드중 다운로드 가능, mp4는 바로 재생도 됨
-종단암호화
-무가입
-웹폴더 방식으로 공동업로드 가능

코로나19 기간동안 완전 무료로 제공합니다.

그러고 보니 단순하게 P2P로 대용량/다수의 파일을 직접 전송하는 것만 하면 되는 경우, 서비스 자체는 여럿 있지만 의외로 쓸만한 서비스는 많지가 않습니다. 제 경우 맥북에서 네이버 무료영화를 다운로드받을 방법이 마땅치 않아 어쩔 수 없이 VMware에 윈도우를 띄워서 그 안에서 영화를 다운받는데, 이걸 맥북으로 빼내는 게 의외로 쉽지 않더라고요. VMware의 드래그 앤 드롭은 용량 때문인지 버벅이기만 하고, 맥북에서 쓰는 외장하드를 VM에 연결해 봤지만 이것도 뭔가 호환성 문제가 있는지 윈도우에는 붙었다 말았다 합니다. 그래서 P2P 파일 전송 서비스/프로그램을 사용하는데, 웹 페이지에서 바로 파일 전송이 가능하다는 서비스 대부분이 제대로 작동하지 않는 경우가 대다수더군요. 아예 작동이 안 되거나, 수십에서 수백 메가바이트쯤 전송한 상태에서 일방적으로 연결이 끊겨 버립니다. 그나마 겨우 찾아낸 솔루션이 [Send Anywhere]인데, 전송속도가 빠르고 전송실패율이 꽤 낮긴 하지만 어째 이 서비스도 운영회사가 새로 만든 [Sendy]라는 유료 서비스로 전환을 유도하는 것을 봐서는 언제까지 존속할지 슬슬 불안해지더군요. 이 서비스는 과연 빠르고 안정적인 대용량 파일 전송이 가능할지 기대됩니다.

p.s.
가능하면 나중에는 스마트폰 앱도 제공되었으면 좋겠습니다. 안드로이드 폰의 MTP는 상당히 구려서, 사진을 다량 옮기거나 할 때 USB를 연결하는 방법보다 파일 전송 앱을 쓰는 편이 더 빠르더라고요.

우와.. 제가 만들게 된 이유가 여기 다 있군요.
가정용 네트워크로 수십기가를 전송하면 결국 한번은 네트워크가 잠깐 이상해지곤합니다.
서비스 사업자는 네트워크 문제라고 말하면 끝이라고 하지만, 사실 현실적으로 불가능한 기능인거죠. 파일키위도 물리적인 네트워크문제를 해결할수는 없어요. 그러나 대신 이어받기를 해줍니다.
아직 불안정한때가 있어서 내세우고 있지는 않는데요. 무설치 이면서 이어받기를 지원하는 것은 파일키위가 유일할 겁니다.
앞으로도 써보시고 충고부탁드립니다.

 
레거시 코드를 점진적으로 개선한 경험

어떤 분께서 이직한 후 미완성 상태였던 Java/Spring 4/Mybatis 기반의 관리자용 시스템을 넘겨받아 점진적으로 리팩토링한 경험을 공유하는 글입니다. (한국어) 테스트 코드가 하나도 없던 것을 조금씩 추가하고, SonarQube를 이용해 코드 품질을 정량적으로 점검하고, Java와 Spring의 Best practice를 점진적으로 적용해 나간 경험이 담겨 있습니다. 특히 자신이 적용한 Best practice에 대해 레퍼런스를 링크로 달아두셔서 참고하기가 편하게끔 되어 있습니다.

 
HSLuv - 개발자 친화적인 색 공간

RGB는 밝은지,탁한지 어떤 색인지 사람이 알기 어려움
HSL은 밝기나 채도가 균등하지 않음
HSLuv는 균등하면서도 편함
- 브랜드 컬러에서 테마 색상 팔레트를 자동 생성 가능
- 사용자가 쓰기 좋은 컬러만 추천 가능

저도 색상은 잘 모르는데 ( 여기 페이지 보시면 아시겠지만.. )
해당 글에 팔레트를 프로그래밍적으로 뽑아내는 부분이 맘에 들더군요.

- 바로 테스트 해볼수 있는 팔레트는 HSLuv 공식 사이트에서 https://www.hsluv.org/
- 대부분의 프로그래밍 언어 구현체가 있습니다 https://www.hsluv.org/implementations/
- 2012년에 처음 HSLuv 를 제안한 글이 조금 더 읽기 편합니다 https://www.boronine.com/2012/03/26/Color-Spaces-for-Human-Beings/
- Human Friendly Colours using HSL https://medium.com/samsung-internet-dev/…
- 읽기 쉬운 HSL 컬러 https://hyeonseok.com/soojung/dev/2017/10/14/827.html
"HSL은 색조(hue), 포화(saturation), 밝기(lightness)로 컬러를 표현하는 방법인데 사람이 색을 묘사하는 방법과 유사한 속성을 사용하기 때문에 비슷한 색이나 약간의 변화가 필요한 색을 조합할 때 직관적으로 색을 만들어낼 수 있다."

 
Cumulative Layout Shift (CLS)

이미지/광고의 느린 로딩, 비동기 동작, 동적 DOM변경등으로
웹 페이지의 레이아웃이 얼마나 변하는 지를 측정하여
사용자가 잘못된 클릭을 유발하게 되는 시각적 불안정성을 체크하는 사용자 중심 성능 지표
"좋은 CLS 점수는 0.1 이하"
~~~
Layout Instability API 로 Layout Shift Score 라는 측정값을 제공
- Layout Shift Score = impact fraction ( 어느 정도 크기의 객체가 이동 하는가 ) * distance fraction ( 얼마나 많이 이동하는가 )
- 사용자의 행동으로 레이아웃이 변하는 것은 괜찮음 - 500ms 이내에 사용자 입력이 있었다면 hadRecentInput 이 설정되므로 계산에서 제거가능
- height/width 바꾸는 것 대신, transform:scale() 사용
- top,right,bottom,left 바꾸는 것 대신, transform: translate() 사용

CLS를 개선하는 방법
- 이미지/비디오에 항상 사이즈 지정하거나 CSS Aspect Ratio Boxes 등으로 위치를 선점해 둘 것
- 사용자 인터랙션을 제외하고는 콘텐츠 위에 새로운 콘텐츠를 추가하지 말 것
- 상태간의 변화에 CSS Transform 등으로 애니메이션 처리 할 것

사용자 중심 성능 지표들
https://web.dev/user-centric-performance-metrics
https://developers.google.com/web/fundamentals/…

기존의 load, DOMContentLoaded 는 좋은 지표가 아님

First contentful paint (FCP): 화면에 첫번째 콘텐츠가 표시되기 시작할 때
Largest contentful paint (LCP): 페이지의 가장 큰 텍스트블럭 또는 이미지가 표시될 때
First input delay (FID): 사용자 입력이 가능해 진뒤 실제로 브라우저가 그에 반응하는데 걸리 시간
Time to Interactive (TTI): 로딩부터, 사용자 인터랙션이 가능해 지는데 까지 걸리는 시간
Total blocking time (TBT): FCP 와 TTI 간의 총 시간
Cumulative layout shift (CLS): 레이아웃 변화 지표

 
RedwoodJS - 풀스택 개발 가능한 JAMStack

- React + GraphQL + Prisma2 + Babel + webpack + CDN + Functions + DB
- JAMstack 철학을 따르지만 DB백엔드 지원
- 프론트/백엔드 코드를 한개의 Repo에 : /web & /api
- API에서 GraphQL로 데이터 가져오는 Cells
- 비즈니스 로직은 Services 에 담아서 GraphQL API가 사용
- Cell/Page/Layout/Service 및 CRUD scaffold 를 생성해주는 Generator 제공

개발자가 좀 더 쉬운 형태로 RedwoodJS를 소개한 트윗 쓰레드
https://twitter.com/mojombo/status/1237441122097487873
- 모든게 잘 연동되어있어서 React에 다른 기술들 엮느라 고생할 필요 없음
- 웹 클라이언트는 CDN에 배포, 비즈니스 로직은 Lambda, DB는 Yugabyte,AWS Aurora,Google Spanner 에 올려서 스케일링이 준비되어있음
- 백엔드가 GraphQL 이라 멀티 클라이언트 기본 대응 : Web, Mobile, Desktop, CLI, Kiosk, Tesla 및 모든 것
- Boilerplate 를 없애고 가능한 선언적으로. VSCode , eslint, prettier 를 적극 활용. Babel/Webpack 이 무거운 작업들을 수행하게 하고 앱 만드는데만 집중
- MIT 라이센스

이 트윗에 대한 누군가의 답글

"이거 마치 Javascript 용 Rails 같네" REST => GraphQL, Sprockets => Babel/webpack, VM => Lambda, Caching => Static site, ERb => React, Active Record => Prisma, Rspec => Jest, routes.rb => Routes.js

"2006년에 dhh 가 Rails로 블로그 만들기 튜토리얼 만들기 를 처음 공개할때를 보는 듯한 느낌이야"

튜토리얼이 환상적이라는 평이 많네요

 
DataSchool - ChartIO의 무료 온라인 DB 학교

· Cloud Data Management
· 대쉬보드 디자인 하는법
· 사람들에게 SQL을 가르치는 법
· SQL 배우기
· 잘못된 데이터 해석 피하기
· SQL 최적화
· 분석의 기초

 
GitLab 의 2020년 글로벌 원격근무 리포트

- 3000+명 응답자
- 사무실없이 모든 직원이 원격인 회사가 증가중
- 장점 : 유연한 스케줄 > 통근시간 없음 > 지출감소
- 회사측 : 생산성 증가 > 효율성 증가 > 사기 진작 > 로열티증가 > 좋은 사람 채용 쉬워짐
- 86% "원격근무가 Future of Work"
- 62% "원격근무 회사로 이직하겠다"
- 회사가 원격근무 중단시 남는다 48%, 퇴사 36%

 
코로나19 공공데이터 핸드북

"시빅해킹을 통해 더 안전한 사회를 만들어 나갑니다."
1. 공적마스크 판매처, 재고 조회 API
2. 선별진료소 API
3. 국민 안심 병원 API
4. 클라우드 무상지원 안내
5. 지도 API 쿼터 상향 지원
6. 원스토어 등록시 심사 생략 지원
7. 식품의약품안전처 마스크 사용 권고사항(3월3일 개정)
8. 관련 애플리케이션 모음
9. 함께 하시는 분

오늘 공적마스크 판매처 알려주는 앱들이 한꺼번에 올라오는데 기여한 핸드북.
훌륭하네요. 민관 협동으로 이루어지는 시빅해킹의 좋은 사례로 기록되었으면 합니다.

 
1:1 미팅을 GitHub Actions로 자동화 하기

- 회사에서 진행하는 1:1 미팅을 GitHub에 기록하는 아이디어
- 템플릿을 클론해서 Private Repo를 만들고 매니저와 IC를 Assignee에 지정
- 월요일마다 Actions가 "이번 주에 대한 질문"을 담은 PR을 자동 발행
- 1:1 미팅 시에 해당 내용을 참고하고 메모 및 To-Do를 추가한 뒤 리뷰하고 머지

IC(Individual Contributor) - (부하 직원이 없는) 특정 업무를 담당하는 개별 기여자
이 단어에서 보듯 매우 미국식이긴 합니다만.. 재미난 아이디어네요.

매니저와 IC가 둘만 볼 수 있는 Hidden Repo로 기록하고 관리.
혹시나 매니저가 바뀌는 상황에 새 매니저에게 내 허락하에 예전 기록을 넘겨주면, 내가 지금까지 해온 일에 대해서 쉽게 전달할 수 있다는 장점.
매니저들에게 중요한 업무 중 하나는 1:1 미팅을 통한 피드백인데, 이걸 프로세스 화 해서 기록하는 조금 라이트한 방식이라고 생각됩니다.

 
JavaScript: The First 20 Years

자바스크립트의 아버지 Brendan Eich 와 ECMAScript 2015 표준의 편집자 Allen Wirfs-Brock 이 직접 적은 자바스크립트의 역사 [190P PDF]
언어의 생성과 디자인, 발전 및 표준화에 이르는 모든 기술적인 내용을 비롯해서, 어떻게 많은 사람과 단체들이 현재 웹의 주요언어가 되도록 경쟁하고 협력해 왔는지를 기록한 방대한 문서

넷스케이프 에서 10일간 해킹으로 만든 Java의 보조언어가 어떻게 웹을 지배하는 언어가 되었을까?
Netscape, Mocha, MS JScript, SpiderMonkey, 왜 이름이 JavaScript 와 ECMAScript 가 되었나,
AJAX의 등장, Flash 와 ActionScript, 크롬과 V8, CommonJS 와 Node.js, ES1 ~ ES6(ECMA2015) 까지의 내용을 정말 상세히 다룬 언어 발전사

136페이지 부터 1989 ~ 2016 주요 이슈들만 정리한 연대기를 보실 수있습니다. 4개로 구분해서 이야기 하네요.
1989~1997 Part 1: The Origins of JavaScript
1995~2000 Part 2: Creating a Standard
1997~2015 Part 3: Failed Reformations
2006~2016 Part 4: Modernizing JavaScript

 
Google Open Source Code Search

구글이 공개한 오픈소스 코드들을 검색 하는 도구
Android 부터 Flutter, Tensorflow, Kaggle Dataset 까지 약 2000개의 프로젝트

사내에 비슷한걸 도입한다면 다른 것들을 이용해서 비슷하게 사용가능합니다.

유료인 SourceGraph https://about.sourcegraph.com/
SourceGraph 가 사용하는 Zoekt https://github.com/google/zoekt

OpenGrok https://github.com/oracle/opengrok
Kythe https://kythe.io/

 
GitLab의 완전원격근무(All-Remote) 가이드

깃랩은 65개국 1200명이 모두 All-Remote 인 세계 최대의 완전 원격 근무 회사
장점과 단점 부터 팀을 구성하는 방법, 문화로 만들기, 매니저를 위한 가이드, 채용과 보상, 핸드북 기반 문서화, 커뮤니케이션 방법 등
원격근무를 시작하는 회사를 위한 대부분의 내용이 담긴 가이드

 
just-news - 국내 언론사 뉴스 사이트에서 본문만 보기

- 뉴스 본문 이외의 정보를 전부 제거한뒤 페이지를 재구성하는 스크립트
- Tampermonkey 플러그인을 사용해서 크롬,파이어폭스,엣지,사파리 웹브라우저에서 사용가능

 
첫 2년 반 동안 스타트업이 걸어야 할 여정 (요약 번역)

- 창업자들이 잘 깨닫지 못하는 사실
- 왜 그리고 어떻게 펀딩을 할 것인지에 대해서 이해하는 것이 필요
- 지난 10년간 스타트업 투자에 자금이 더 많이 몰리면서 투자 라운딩의 정의가 다소 변화해 옴
- 이상적인 매출 성장세 : 창업 연차에 따라 3배, 3배, 2배, 2배, 그리고 2배 성장하는 것이 이상적
- 모든 투자 유치 단계에서는 5개의 중요 요소를 염두에 두어야 함