[GN#105] SQLite의 알려지지 않은 이야기

2021-07-05 ~ 2021-07-11 사이의 주요 뉴스들
현재 거의 모든 스마트폰, 웹브라우저, TV, 자동차에는 SQLite DB가 들어있습니다. 실제로 운영 중인 SQLite는 1조 개가 넘는다고 하는데요. zlib, libpng, libjpeg 등과 함께 가장 많이 설치된 소프트웨어 모듈이기도 합니다. SQLite의 최초 설계자이자 개발자인 Richard Hipp이 팟캐스트 인터뷰를 통해서 SQLite가 처음에 어떻게 만들어졌고, 발전해 왔는지를 상세히 얘기했습니다. 진정한 자유를 위해서 Parser부터 버전관리시스템(Fossil)까지 모든걸 직접 개발했고, 100% MCDC 테스트 커버리지를 구현해서 8년 넘게 버그가 없었다는 것도 정말 놀라웠는데요. 인터뷰에서 얘기가 안 된 중요 포인트 중 하나는 SQLite의 라이센스가 Public Domain이라는 것입니다. 누구나 코드를 복사하고, 수정하고, 사용하고, 심지어 팔 수도 있고, 마음대로 배포할 수도 있다는 거죠. 긱뉴스에서 SQLite로 검색해보니 175개의 뉴스가 나오는데요. SQLite를 확장한 분산DB RQLite & DQLite, JS로 컴파일된 SQL.js, 공간DB를 구현한 SpatiaLite, 서버리스로 구현한 Edge-SQL, Graph DB로 이용하는 Simple-Graph 등.. 이 개발자의 코드에 대한 믿음이 지금 우리가 편하게 어디서나 사용할 수 있는 SQLite 와 그 확장들이 나오게 했다고 생각이 듭니다. 많은 영감을 주는 인터뷰이니 제가 요약한 부분을 보시고 꼭 영상도 한번 보시길 추천해 드립니다.

아마존 창업자 제프 베조스가 7/6일 자로 공식 CEO를 사임했습니다. CNBC가 제프 베조스가 27년간 CEO로서 성공을 거둘 수 있었던 최고의 교훈들을 "위험을 감수하라 / 빠른 결정을 내려라 / 천직을 찾아라 / 방황의 비효율성을 수용하라 / 개성을 잃지 마라" 이렇게 5개로 정리했는데요. 테크니들 에서 잘 요약 번역 해주셨습니다. 전 이 중에서 "천직을 찾아라 (Finding your calling)" 와 "방황의 효율성을 수용하라(Embrace the inefficiency of wandering)" 가 가장 마음에 듭니다. 자신이 열정을 가질 수 있는 천직은 찾는 데 오래 걸리고, 바뀔 수 도 있습니다. Calling이라는 표현을 통해서 나를 부르는 게 바뀔 수 있다는 표현으로 이해하면 좋을 것 같아요. 베조스가 아마존에서 우주로 바뀐 것처럼요. 탐색과 실험 하는 것을 "비효율적인 방황"이라고 표현했는데, 저는 이걸 "창의적인 잉여" 라고 부르고 싶습니다. 흥미를 가지고 다양하게 방황하고 실험하는 잉여로운 짓들을 통해서 우린 직선이 아닌 길로도 성공에 다다를 수 있을 거라고 봅니다. "잉여는 잉여라고 판단될 때까지는 잉여가 아니다"

YC창업자 폴 그레이엄은 자신의 블로그를 통해서 다양한 글들을 적고 있는데요. 글이 길고 어렵기도 하고, 산문 형태의 글이라 읽기가 편하지는 않습니다. 최근에 올라온 "How to Work Hard" 글을 뉴스페퍼민트에서 잘 번역해주셔서 편하게 읽을 수 있었습니다. 위대한 일을 하기 위해서는 재능, 연습, 노력 세가지가 모두 필요하다는 얘기로 시작해서 어떻게 최선을 다할 수 있는지를 설명하고 있습니다. 꼭 읽어보시기 바랍니다.

긱뉴스에 새로운 뉴스가 등록되면 스팸을 피하고자 특정 조건을 만족할 때만 페이스북, 트위터, Slack으로 전송이 되는데요. 트위터 팔로워는 약 6000명이고, Slack 봇은 약 700개 워크스페이스에서 이용중입니다. 사내 커뮤니케이션 도구로 잔디, MS Teams, Discord 를 이용중이신 분들을 위해 새로운 긱뉴스 봇들을 추가했습니다. WebHook 형태로 구성되어 있어서 큰 권한을 요구하지 않습니다. WebHook URL 을 서버쪽에서 삭제하면 자동으로 연동이 해지 됩니다. 많은 이용 바랍니다.


✓ 주위분들께 긱뉴스 위클리 - https://news.hada.io/weekly 를 추천해 주세요.

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


SQLite의 알려지지 않은 이야기

- SQLite 개발자 Richard Hipp의 인터뷰 팟캐스트 요약(38분, 스크립트 있음)
- 본업은 미국 해군의 구축함에 들어가는 소프트웨어 개발자
ㅤ→ 함선 내부에서 사용하는 Informix가 에러가 잦고, 서버가 죽고 연결이 끊어지곤 했음
ㅤ→ 전함이기 때문에 전투중에 피해를 입어도 “DB에 연결할 수 없습니다” 팝업 안보이고 튼튼하게 잘 동작해야 함.
ㅤㅤ트랜잭션도 필요 없고, 어떤 상황에서도 데이터를 램에 읽어들여야 했음
ㅤ→ 서버 없이 실행되는 SQL DB 엔진을 찾아봤는데 없어서, 직접 만들기로 함

SQLite V1 (2000년)
- SQL문을 프로그램으로 생각해서 쿼리를 컴파일하고 실행하는 바이트 코드 엔진을 작성
- 실제로 프로젝트에서 사용되지는 않음 (고객이 Informix를 쓰기 원함)
- 개발 용도로 쓰면서, 인터넷에 공개했고 그걸 사람들이 쓰기 시작
- "Palm Pilot에서 SQL DB를 실행했어요" 같은 말들을 보게 되고 사람들의 주목을 끌었음. 그래서 더 작업을 진행하도록 격려받음.

Motorola
- 2001~2002년 사이, 모토로라가 자신들의 새로운 전화 OS에 SQLite를 넣겠다고 전화가 옴
- 필요한 기능을 지원해주면 비용을 내겠다는 것
- 오픈소스로 돈을 벌 수 있다는 사실을 그때 처음 알게 됨
- 약 $80,000로 요즘에 비하면 많지 않은 돈이었지만, 본인한테는 굉장히 놀라운 금액이었음.
- 같이 일하던 세명과 함께 프로젝트를 진행했고 그게 시작이었음

America Online Phones
- 그 다음으로 연락이 온 것은 AOL 이었음
- CD를 우편으로 보내던 시절이었는데, 그 CD 안에는 Database 가 필요했음
- 즉 CD 안에 SQLite를 넣기를 원했고 새로운 기능을 필요로 했음

Symbian OS 와 Nokia
- 추수감사절에 런던으로 가서 미팅을 진행(영국은 추수감사절이 없으니까)
- Symbian OS를 위한 DB를 원했고, 다른 DB들과 경쟁을 벌임(2개의 오픈소스,7개의 상용)
- 다른 9개 DB에 튜닝할 기회를 주었지만, SQLite가 최종 승리

Bus Factor [1] 와 콘소시엄
- 버스팩터는 몇명이 버스에 치이면 개발이 중단되는 지를 의미하는 지표
- 본인은 풀타임으로 여럿과 함께 일을 하고 있었지만, Symbian 쪽에서 버스 팩터를 높여야 한다고 얘기가 나왔음
- SQLite 컨소시엄을 시작해서 프로젝트에 자금을 지원하고 더 많은 사람들이 장기적으로 참여하도록 하자는 것
- 모든 컨소시엄 멤버들이 투표권을 가지게 하는 것 같은 미친 아이디어를 내었음
- 모질라 재단의 Mitchell Backer가 이걸 어디선가 듣고 전화를 걸어옴
ㅤ→ "리차드, 당신은 완전히 잘못하고 있어요. 컨소시엄을 만드는 법을 알려줄께요"
ㅤ→ 그녀가 규칙을 만들기 시작
ㅤ→ "개발자들이 통제권을 가져야 해요. 그들의 결정이 최종입니다. 들어간다는 것 만으로 투표권을 가지면 안돼요."
ㅤ→ "이걸 이용하는 회사들은 돈을 기부하는 명예를 얻지만, 최종 결정은 당신이 해야합니다."
ㅤ→ 그녀는 매우 단호했고, 모든 걸 정리했음. 그녀는 변호사임
- 리차드는 "어떻게 사람들이 참여하게 하죠? 인센티브는 뭐구요?" 라고 얘기하자,
ㅤ→ "걱정하지 마세요. 그들은 참여할 겁니다. 그리고, 실제로 이렇게 하면 Mozilla가 창립 멤버가 될 겁니다."
- Mozilla, Symbian 및 Adobe의 지원을 받고, 세 회사와 컨소시엄을 시작
ㅤ→ 처음에 심비안이 콘소시엄이 필요하다고 얘기했을 때 어찌 해야 할지 몰랐음. 어떻게 미첼베이커가 이걸 듣고 전화했는지는 모르지만, 이 모든게 놀라운 여정.

Enter Android : 안드로이드의 시작
- 모든 스마트폰이 SQLite를 사용하고 있기 때문에, 리차드는 초기 스마트폰 개발을 모든 측면에서 볼 수 있었음
- 2005년에 안드로이드와 회의를 진행. 그때는 안드로이드도, 아이폰도 나오기 전
- 상단에 작은 디스플레이와 풀 QWERTY 키보드를 가진 블랙베리와 비슷한 폰에 연결해서 SQLite를 디버깅 했음
- 실제 동작하는 전화망에 붙은 폰에서 GDB로 디버깅하는 것은 놀라운 경험이었음
- 그때는 모토로라, 심비안, 노키아의 누구도 그런 걸 하지 않았을 때였고, 이때 안드로이드가 거대해질 것이라는 걸 알았음

Guy, This Is Important : 여러분, 이게 정말 중요해요
- 그 시절 다른 업체들은 하드웨어와 소프트웨어 업데이트 주기가 30일 정도로 굉장히 길었는데, Android는 실제 망에 붙은 전화기에 하루에 몇 번씩 새로운 OS를 넣었음.
- NDA 하에 받은 프로토타입 안드로이드 폰은 3D 프린트 된 것 같은 케이스였지만, 휴대는 가능할 정도 였음.
ㅤ→ 다른 회사의 것들은 큰 브레드보드 & 프로토타입에, 망에도 붙어 있지 않아서 폰으로 쓸 수도 없었음
- 모토로라, 심비안 사람들에게 "이거 중요하니까 이걸 해결해야 한다고 말하고 싶었지만 말할 수 없었음" (NDA 때문에) 그리고 그게 차이를 만듦

Testing and Aviation Standards : 테스팅과 항법 표준
- Adam(인터뷰어) : "지금 리차드의 DB는 정말 활기찬 상태임. 재능 있고 팀도 능력 있지만, 모든 안드로이드폰에 들어가는 DB를 지원하는 1~4명의 소프트웨어 컨설팅 회사임. 개발자들은 DB에 굉장히 열심이고, 데이터에 문제가 생기는 걸 싫어합니다"
- 우리는 모든 사람에게 Naive하게 SQLite 는 버그가 없다고 자랑하고 있었지만, 안드로이드는 확실히 우리가 틀렸다는 것을 증명했음.
- 버그없이 소프트웨어를 만들수 있을거라 생각했지만, 소프트웨어가 수백만개의 장비에 설치될 때 얼마나 버그가 많이 날 수 있는지 놀라울 정도임.
- 그때쯤에 항공전자공학(Avionics) 회사인 Rockwell Collins와 일을 하고 있었는데, 그들이 DO-178B [2] 개념을 소개해줬음.
ㅤ→ DO-178B는 안전이 중요한 항공 제품들의 품질 표준에 관한 것인데, 다른 품질 표준과 달리 "읽을 수 있음(readable)"
ㅤ→ 몇백달러 쯤 하는데 얇으니까 꼭 읽어보기를 권함
- 실제로 DO-178B의 프로세스를 따르기 시작했고, 그중 하나가 100% MCDC Test Coverage
- MCDC(Modified Condition / Decision Coverage) [3] 는 테스트가 개별 분기를 적어도 한번 이상 통과해야 하는 것
- SQLite 가 MCDC 100% 가 되는데 주당 60시간 기준으로 1년이 걸렸음. 정말 정말 어려웠음. 매일 12시간을 해야 했고 정말 피곤.
- 90~95% 의 테스트 커버리지는 쉬운데 나머지 5%가 정말 어려움. 하지만 1년간 그렇게 해서 최종적으로 100%에 도달하자 Android 에서 버그리포트가 오지 않게 되었음
- 그때부터 작동하기 시작했고, 큰 차이를 내었음. 그 이후 8~-9년동안 버그가 없었음.

수십억개의 테스트
- 첫번째는 TCL(Tool Command Language)로 작성되었고, 일반적인 개발자 테스트 였음
- 아직도 첫번째 TCL테스트는 유지 보수하고 있고 공개되어 있음. 100%는 아니지만 SQLite 의 모든 기능을 상세 테스트 함.
- MCDC 100% 커버리지는 TH3 라고 부르고 공개하지 않음 (proprietary)
- 이걸 항공회사에 팔아서 돈을 벌어보려고 했지만 한개도 못팔았으니 효과는 없었음..
- 하지만 우리 제품을 정말 견고하게 유지하고 새로운 기능 과 버그 수정을 빠르게 해볼 수 있게 해줌
- 테스트 갯수를 세기는 어렵지만 10만개의 개별테스트가 매개 변수화 되어서 수십억개의 테스트가 실행 됨
- 체크리스트가 있고, 릴리즈전 최소 3일 동안 테스트를 진행함
- 의도적으로 여러 개의 OS에서 테스트를 진행함
ㅤ→ 요즘은 모든 장비들이 리틀 엔디안이지만 예전엔 빅엔디안들도 많았음. 그래서 PowerPC iBook 에서 빅엔디안 테스트를 진행
ㅤ→ 32비트 플랫폼과 ARM 과 Intel, 64 Bit 플랫폼, 윈도우, 리눅스, 맥, OpenBSD 등 우리가 할수 있는 모든 플랫폼과 OS에서 테스트를 진행
ㅤ→ 여러개의 다른 테스트 스윗이 있고, 원래 TCL도 있고, TH3도 있음. 지속적으로 실행되는 Fuzzer(퍼지 테스팅)도 있음.
- SQL Logic 테스트도 있음
ㅤ→ 10년전에 Shane Harrelson 이 만든 엄청난 더미의 SQL 문장
ㅤ→ 손댈 수 있는 모든 DB에서 테스트 했는데 모든 DB엔진이 답을 못내고, 세그멘테이션 폴트를 내었음. SQLite 포함. 단, Postgres 만 빼고.
ㅤ→ Postgres 만 항상 결과를 내었고 결점을 찾을수 없었음. Postgres 개발자들은 우리가 충분히 노력하지 않은거라고 했지만.. Postgres에 에러를 내는 것은 가능은 했겠지만, 우린 매우 감동했음
ㅤ→ 상용 버전 Oracle도 크래시 내었고, DB2도 크래시 냄
ㅤ→ 중요한 포인트는 SQLite가 이 모든 쿼리들에 대해서 동일한 답을 내도록 했다는 것

Building From First Principles
- 처음에 작성을 시작했을 때, 어떻게 SQL DB 엔진을 만드는지 레퍼런스가 있는지 찾아보려고 했는데 없었음. 그래서 직접 만들어야 했고, 완전히 독립적인 임무였음.
- 많은 이론들이 MIT, 하바드, 버클리에서 일어나고 있었지만 그 학교들에 가지 않으면 이론이 존재한다는 사실조차 몰랐고, 찾는 방법도 없었음.
- Postgres 가 사용하는 Volcano 모델과 SQLite 가 사용하는 Byte Code 모델은 살펴보면 우린 모두 같은 아이디어로 수렴됨
- 위에서 보면 매우 다른 곳에서 시작하지만, 우린 어떻게 그걸 더 빠르게 하는가에서 같은 영역에 수렴함
- 이게 이론적으로 일종의 검증이라고 생각함. 두개의 독립적인 개발라인이 동일한 답을 내놓는 것
- 예를 들어서, 나는 Covering Index에 대해서는 전혀 몰랐는데, 독일에서 열린 PHP 컨퍼런스에 참석했을 때, MySQL의 David Axmark도 참여해서 강연을 했음
ㅤ→ 그 강연에서 MysQL 이 어떻게 Covering Index를 만들었는지 설명함
ㅤ→ DB의 인덱스에 어러개 컬럼이 있을때, 인덱스의 앞쪽 컬럼에 대해서만 쿼리하고 답이 나머지 컬럼에 있다면 DB는 원본 테이블 조회없이 인덱스만으로도 사용 가능해서 작업이 빨라짐
ㅤ→ 그래서 집으로 돌아오는 비행기에서 사람이 별로 없길래, 랩탑을 열고 대서양 상공에서 SQLite 의 커버링 인덱스를 구현했음

B-Trees and The Art of Computer Programming
- 많은걸 직접 만들어야 했음. 아무도 나에게 B Tree를 가르쳐 준적이 없음. 그냥 들어봤을뿐.
- 직접 B트리를 개발하려고 할때, 책장에서 Don Knuth의 TAOCP 가 있어서 B트리를 찾았고 그가 알고리듬을 설명해줬음
- 재미난건, 책에는 B트리 검색과 삽입 알고리듬은 자세히 설명하지만, 삭제하는 알고리듬은 제공하지 않음. 그건 챕터 끝 연습문제에 있어서, 나만의 B 트리를 만들기 전에 문제를 풀어야 했음. "고마워요 Don, 정말 감사해요."
- 현 시대의 사람들은 적어도 TAOCP 를 읽거나 훑어보기라도 해야함

Freedom to Build It Yourself : 직접 만들 수 있는 자유
- SQLite 는 Richard 가 직접 만든 것 외에는 아무것에도 의존성이 없음 (C 컴파일러와 libc 제외하고). 직접 버전관리 시스템도 만들고 버그 트래커도 만듬. 이게 리차드에게 자유를 줌
- 자유(Freedom)라는 것은 자신을 스스로 돌보는 것을 의미
- 배낭여행 가는 사람들이 필요한 모든 것을 등에 지고 가면서 자유롭다고 하는 것은 그들이 직접 자신을 케어하기 때문
- 모든 것을 직접 만든다면 누군가에게 묶여있지 않기 때문에 그 안에 자유가 있음
- 만약 SQLite 2의 스토리지 엔진으로 Berkeley DB를 선택했다고 가정해보면
ㅤ→ 그 당시엔 Berkeley DB는 오픈소스 였지만 나중에 Oracle 에 매각되어서 듀얼 소스 독점 모델이 되어서 라이선스 비용을 내지 않고는 최신 버전의 소스코드를 얻지 못하게 되었음
- 지금 SQLite 의 Parser Generator는 Yak 나 Bison 을 사용하지 않고 Lemon 이라 불리는 직접 작성한 것인데, 그래서 새로운 언어 기능이 필요할 때 그것들에 묶이지 않고 수정할 수 있었음
- 2000년대 초에는 모든 프로젝트 CVS를 사용하기에 그걸 썼지만, 2000년대 중반이 되면서 분산 버전 관리 아이디어가 나오기 시작

Fossil 구축
- Git 과 Mercurial 을 보고 요구사항을 정리한뒤 직접 버전관리 시스템을 개발하기로 함
- 이제 Fossil 은 잘 동작해서, 자체 프로젝트가 되었음
- 토발즈가 Linux Kernel 개발을 지원하기 위해 Git을 만들었기에, Linux Kernel 관련 일을 한다면 Git 이 완벽한 버전관리 시스템
- Fossil 은 SQLite 작업을 하기위해 딱 맞는 버전 관리 시스템임. 내가 직접 만들었기에 내 요구사항을 정확히 충족
- 직접 개발함으로써, 자신의 운명을 통제하고, 더 많은 자유를 가지고, 제3자에게 의존하지 않게 됨

자급자족하기
- 도시를 벗어나서 직접 식량을 키우고 사는 사람을 뭐라고 할까요? Survivalist (생존주의자) ? 또는 Prepper (준비자)
"당신과 연락하는 동안에도 봤듯이 제 Gmail 이 조금 이상해요. 메일이 자꾸 리턴됩니다. 그래서 내 메일 서버를 만들려고 해요. 우리가 이 미팅을 셋업하는 중에도 관련 노트를 작성하고 있었어요. DB 엔진을 작성하는 것보다 어렵지는 않겠지만 Gmail 에 얽매이고 싶지는 않아요. 그들이 내 운명을 통제하는 것을 원하지 않아요. 그들이 내 모든 대화의 기록을 제어하는 것을 원하지 않아요. 내가 직접 통제하고 싶고, 그래서 고통스럽고 할일이 많겠지만 직접 통제할 해결책을 찾기위해 노력하려고 합니다. 클라우드에서 가상머신을 임대해서 실행해서 제3자에 의존하지 않아도 됩니다."
- 누군가 찾아와서 당신의 문제를 해결해 주겠어요 한다면, 그들이 당신의 자유를 빼앗아 갈거라는 것을 알아야 합니다. "자유롭고 싶다면 직접 해야 해요"

다른 사람을 위한 조언
- 저는 서버가 필요없이 직접 디스크에서 읽고 쓰는 DB 엔진을 만들겟다는 미친 아이디어로 시작했습니다.
- 전문가들에게 물어보면 "그건 불가능해요. 절대 동작하지 않을꺼에요. 멍청한 아이디어 입니다."라고 할겁니다.
- 다행스럽게도 난 그런 전문가들을 몰라서 그냥 했고, 이런 일들이 일어났습니다.
- 전문가들의 말을 많이 듣지 말고, 말이 되는 일을 하세요. 당신의 문제를 해결하세요

--

[1] Bus Factor : 팀원이 버스에 치어서 팀이 위기에 빠질 수 있는 위험도.
- 팀 멤버 간에 정보 및 기능들이 공유되지 않아서 생길수 있는 위험을 말하는 지표.
- 이 지수를 높여야 정보가 공유되고, 특정인에게 업무가 집중되지 않음.

[2] DO-178B : 항공기 시스템과 장비 인증에 관한 소프트웨어 고려사항 (Software Considerations in Airborne Systems and Equipment Certification )
- 미연방항공국(FAA)에 의해 항공용 소프트웨어 인증을 위한 적합성 입증 방법으로 채택

[3] MCDC : Modified Condition / Decision Coverage
- 여러 개의 조건식이 있을 때, 각 개별 조건식이 다른 조건식에 영향을 받지 않고 전체 조건식의 결과에 독립적으로 영향을 주도록 테스트 케이스를 설계하는 방법

현재 전세계에서 운영중인 SQLite는 1조개가 넘습니다.

- 40억대가 넘는 모든 스마트폰(Android,iOS)
- 맥/윈도우
- FF/크롬/Safari 브라우저
- PHP/Python
- Skype/iTunes/Dropbox/Turbotax
- 대부분의 셋탑박스와 TV
- 대부분의 자동차의 멀티미디어 시스템

https://www.sqlite.org/mostdeployed.html

 
제프 베조스가 CEO로서 전한 최고의 교훈들

- Take risks : 위험을 감수하라.
- Make good decisions - fast : 빠른 결정을 내려라.
- Finding your calling : 천직을 찾아라.
- Embrace the inefficiency of wandering : 방황의 비효율성을 수용하라.
- Don’t lose your distinctiveness : 개성을 잃지 마라.

 
최선을 다한다는 것

- YC 창업자 폴 그레이엄의 How to Work Hard 글 번역
- 위대한 일을 해내기 위해서는 재능, 연습, 노력 세 가지가 모두 필요
- 두 가지만 만족 시켜도 어떤 일이든 잘할 수 있지만, 최고의 결과를 위해선 세가지 모두가 필요
- 엄청난 재능과, 수많은 연습, 그리고 그 일에 최선을 다해야 함
- 이 말은 당연해 보이지만, 실제로 이를 깨닫는 것은 쉽지 않음
ㅤ→ 재능과 노력이 마치 반대인 것처럼 보이기 때문
- 목표가 명확하지도 않으며, 외부에서 어떤 목표가 주어지지도 않았을 때 최선을 다하기 위해서는 어떻게 해야하는가
ㅤ→ 다른 사람이 당신에게 요구하지 않아도 스스로 일을 하는 마음가짐을 가지는 것이 기본
- 흥미로운 사실은, 무언가에 최선을 다하게 만드는데 가장 큰 방해가 되는 것이 바로 학교
ㅤ→ 학교는 학생이 해야 할 일인 공부를 지루하고 무의미한 것으로 보이게 만듬
ㅤ→ 나는 진짜 일이란게 어떤 건지 알고 나서야 비로소 최선을 다해 일할 수 있게 되었음
- 진짜 일이란 어떤 것인지를 이해하기 위해서는 먼저 두 가지 사실을 깨달아야 함
ㅤ→ 학교에서 배우는 과목은 아이들에게 쉽게 가르칠 수 있도록 손질된 것이며, 때로 진짜 학자들이 한 일과는 전혀 다른 모습으로 바뀌어 있다는 것
ㅤ→ 어떤 종류의 일은 본질적으로 가짜이며, 잘 해야 소일거리에 불과하다는 것
- 진짜 일에는 어떤 확실성이 있음. 적어도 그 일이 반드시 필요한 일이라는 느낌
- 최선을 다한다는 것은 가장 가운데를 향한다는 것이며, 가장 위대한 문제에 도전한다는 것
- 이 일에 당신이 계속 매달려야 할지를 말해주는 가장 좋은 기준은 바로 당신이 그 문제를 흥미롭게 생각하는가
- 매 순간 당신이 스스로에게 정직하고 스스로를 잘 판단할 수 있다면, 당신은 저절로 최적의 상태에 돌입하게 되며, 이 세상에 얼마 없는 생산적인 사람이 될 수 있을 것

폴 그레이엄이 쓰고 뉴스페퍼민트에서 번역한 이 글도 매우 좋았습니다.
https://newspeppermint.com/2020/04/23/m-test1/

매우 요약하기 어려운 산문성 글이네요. 근데 주루룩 읽기엔 좋습니다.
뉴스페퍼민트에서 장문을 잘 번역해주셨으니 꼭 원 링크의 번역문을 읽어보시기 바랍니다.

2부 링크 : https://newspeppermint.com/2021/07/08/workhard2/

 
GeekNews 잔디,Teams,Discord 봇 추가

- 긱뉴스에 새로운 뉴스가 올라오면 알려주는 웹훅(WebHook) 봇들 신규 추가
ㅤ→ 잔디(Jandi)
ㅤ→ MS Teams
ㅤ→ Discord
ㅤ→ Slack
- 서버에서 웹훅을 제거하면 자동 연결해제
- 웹훅 생성 및 연결을 위한 권한 필요

 
Microsoft, ML for Beginners 강의 공개

- MS Azure Clouds Advocates 팀이 만든 12주, 24강짜리 커리큘럼
- Scikit-learn을 이용한 클래식 머신러닝 강의 (딥러닝은 별도 AI 강의로 나올 예정)
- 한글화 및 여러 언어로 번역 작업 진행중 (지원자)
- 이용 방법
ㅤ→ Repo를 포크
ㅤ→ 강의전 퀴즈 풀기
ㅤ→ 강의 읽고, 활동들 완료하고, 프로젝트 코드 작성해보기
ㅤ→ 강의 후 퀴즈 풀기
ㅤ→ 도전 과제 및 숙제
ㅤ→ Discussion 보드에 PAT Rubric 남겨서 소리내어 배우기 "Learn out loud"

https://github.com/microsoft/ML-For-Beginners/issues/71
위 링크에 보니 minwook-shin 님이 자원해서 번역을 진행중이시네요. 응원합니다!

 
엔터프라이즈 프론트엔드 애플리케이션 아키텍쳐

- 코드베이스가 커진다는 것 = 이해하기도, 수정하기도 어려워진다는 것
- 해결 방법은? 코드베이스를 작게 유지하면 됨.
- 도메인 별 코드베이스 분리 & 마이크로 프론트엔드 to rescue!
- 모노레포 안에서 라이브러리의 의존 관계 설정 & 의존성 확인 등의 니즈는 [Nx](https://nx.dev/)를 도입하여 해결
- 애플리케이션과 라이브러리로 코드를 분리
- 애플리케이션은 의존성 및 설정 주입의 역할
- 라이브러리에 대부분의 기능을 구현
- 라이브러리에는 범용적으로 사용할 수 있는 디자인 시스템, 국제화, 서드파티 모듈 뿐만 아니라 홈 페이지의 히어로 배너, 상품 상세 페이지, 주문 내역 등 재사용하지 않는 코드까지 작성.

### Feature 라이브러리

- 기본적으로 한 페이지에서 사용되는 모든 컴포넌트들은 같은 이름의 Feature 라이브러리에 작성
- ex) `account` 도메인의 `SignInPage` 페이지의 모든 컴포넌트들은 `account/feature-sign-in` 라이브러리에 작성
- 같은 도메인의 둘 이상의 페이지에서 공유하는 컴포넌트는 해당 도메인 내 별도의 feature로 분리
- ex) `account` 도메인의 `SignInPage`와 `SignUpPage`에서 `KakaoLoginButton` 컴포넌트를 공통으로 사용한다면 해당 컴포넌트는 `account/feature-social-login` 라이브러리에 작성
- 서로 다른 도메인의 페이지들에서 공유하는 컴포넌트는 공용 도메인 내 별도의 feature로 분리
- ex) `landing` 도메인의 `HomePage`와 `classroom` 도메인의 `LecturePage`에서 공유하는 `GlobalNavigation` 컴포넌트는 `shared/feature-navigation` 라이브러리에 작성

### Shell 라이브러리

- Feature, UI 라이브러리의 컴포넌트들을 조합해 페이지들을 만듦
- ex) `SignInPage` 컴포넌트는 account/shell-kr-web 라이브러리의 컴포넌트. 여기에는 `SignUpPage`, `PhoneVerificationPage` 등이 있음.
- Shell 라이브러리는 애플리케이션에 제공되는 특정 도메인의 진입점
- 애플리케이션 별로 다른 진입점을 제공할 수 있음
- 예를 들어..
- `HomePage` 컴포넌트에서 사용하는 컴포넌트들은 `landing/feature-home` 라이브러리에 작성되어 있음.
- 하지만 같은 `HomePage`라도 미국 사이트의 `HomePage`인지, 일본 사이트의 `HomePage`인지, 한국 사이트의 `HomePage`인지에 따라 그 구성이 다를 것.
- 따라서 `landing` 도메인에 접근하는 각각의 애플리케이션을 위한 `shell` 라이브러리를 만들 수 있음. (`shell-us-web`, `shell-jp-web`, `shell-kr-web`)

### Provider 라이브러리

- 둘 이상의 Feature 라이브러리에서 공유하는 상태를 관리하는 라이브러리
- ex) 로그인 상태를 관리하는 `shared/provider-auth-state`

### UI 라이브러리

- 둘 이상의 라이브러리에서 공유하는 Presentational 컴포넌트의 모음.

### Utility 라이브러리

- 위 4가지 분류에 해당하지 않는 모든 모듈들
- 클래스101의 도메인 모델과 무관하게 테스트 및 배포가 가능한 수준으로 독립적인 기능을 제공해야 함.
- ex) `shared/utils-apollo-client`, `shared/utils-i18n`

### 애플리케이션

- 설정 및 의존성 관리의 역할만 담당하게 됨 = 애플리케이션의 코드는 거의 없음

 
Music for 프로그래밍

- 개발할 때 집중도와 생산성을 올려 주는 음악 믹스
- 현재 총 62개의 에피소드
- 한 에피소드당 1~2시간 분량의 곡들을 큐레이션 해서 통합 mp3로 제공
ㅤ→ 페이지에서 직접 재생 또는 mp3 다운로드 가능
ㅤ→ RSS 및 팟캐스트로도 제공

function musicForProgramming(task)
{
ㅤtask = (task === undefined) ? 'programming' : task;
ㅤreturn 'A series of mixes intended for listening while '+task+' to aid concentration and increase productivity (also compatible with other activities).';
}

 
Transfer.sh - 쉘에서 쉽게 파일 공유하기

- 별도 툴 설치 없이 cURL 또는 transfer 쉘스크립트 커맨드로 파일을 전송하면 파일 공유용 URL이 리턴
- 10GB 까지 14일간 암호화 해서 무료로 저장됨
- Go 오픈소스
ㅤ→ S3, 구글드라이브, Storj 및 Local 지원해서 자신의 서버 호스팅 가능
- 멀티업로드, gpg 암호화, 메일로 첨부해서 보내기, keybase 연동등 다양한 예제 제공

 
컴퓨터비전으로 회의중 딴짓하는 국회의원 잡아내기

- 벨기에 국회의원들의 회의는 유튜브를 통해 생중계되는데, 파이썬의 keras 를 이용해 회의중 휴대폰으로 딴짓하는 국회의원을 검출
- 트위터, 인스타그램과 연동해, 딴짓행위가 검출되면 해당 정치인 태그를 달고 포스팅해 박제

 
아이슬란드의 주4일 근무 시험 '압도적인 성공'

- 아이슬란드 노동 인구의 1% 이상이 전체 임금을 줄이지 않고 근무시간을 35~36시간으로 단축하는 파일럿 프로그램에 참여
ㅤ→ 2015년 부터 2019년까지 2500명 이상 (세계 최대 규모)
ㅤ→ 생산성과 웰빙 향상 시켰고, 영구적인 변화로 이어지는 중
- 아이슬란드 노조 연맹이 재판을 통해서 전체 노동 시간 단축하는 협상을 시작
ㅤ→ 전체 노동 인구의 86%가 시간을 단축하거나 단축할 수 있는 유연성을 가지게 될 것으로 예상
- 실험에 포함된 근로자는 9to5 근무자 및 비정규 교대 근무자를 포함한 사무실, 놀이학교, 병원, 사회복지 담당자 등
- 참여한 근로자들의 웰빙이 다양한 지표에 걸쳐서 좋아졌고, 스트레스 / 번아웃 / 워크 라이프 밸런스 등은 모든 그룹에서 대폭 개선 되었음

저는 AI와 로봇의 발달 등으로 언젠가 주4일 근무를 넘어서 30시간 이하의 근무로 갈 수 있을 거라 봅니다.

 
Tuplex - 병렬 빅데이터 처리 프레임워크

- Apache Spark / Dask 와 비슷한 Python API 를 제공하지만
ㅤ→ 파이썬 인터프리터를 호출하지 않음
ㅤ→ 주어진 파이프라인과 입력 데이터세트에 최적화된 LLVM 바이트코드를 생성
ㅤ→ 인터프리터 대비 5~91x 빠름
- 내부적으로 데이터 드리븐 컴파일과 듀얼 모드 처리를 기반으로 해서, C++로 코딩하고 최적화된 파이프라인과 비슷한 속도를 냄
- MacOS / Linux 지원
- SIGMOD '21 에서 발표된 "Tuplex: Data Science in Python at Native Code Speed" 논문

 
Deno Deploy Beta 1

- 멀티테넌트 JavaScript 서버리스 엔진
ㅤ→ V8 및 Deno CLI를 그대로 사용
ㅤ→ 전세계 25개 데이터센터에서 실행
ㅤ→ TypeScript, JSX, ES Modules, HTTPS Imports 지원
ㅤ→ BroadcastChannel API : 탭간에 실시간 커뮤니케이션 지원
- Deploy GitHub App 으로 푸시하여 즉시 배포
- Fresh : JIT SSR for Deno, 빌드가 필요 없는 웹 프레임워크
- 2021 Q4에 GA 예정

The Deno Company 발표 https://news.hada.io/topic?id=3978
예상했던 대로 Deno 회사의 첫 수익화 모델이 Deploy 서버리스가 될 것 같네요.

~~

실제 테스트 해본 후기 : https://aidangee.dev/blog/deno-deploy-beta-first-look
Deploy 공식 사이트에서 가장 빠른 서버리스 시스템이라고 홍보를 해서 TTFB(Time to First Byte) 속도 테스트를 해봤군요.

Deno Deploy
- Cold Start TTFB : 575ms
- Warmed TTFB : 44ms

Netlify Functions : https://www.netlify.com/products/functions/
- Cold Start TTFB : 812ms
- Warmed TTFB : 138ms

베타1 상태에서 이 정도면 꽤 인상적인듯
다만 CDN 엣지에서 실행되는 Lambda@Edge 나 Cloudflare Workers 와 비교하면 아직 느리긴 합니다만, 추가될 기능들이 흥미로운 것 같아요.

~~

Deno Deploy: Crazy Fast Cloud Functions - Architecture Speedun
https://www.youtube.com/watch?v=yZDvE0mP4Y4

17분짜리 영상인데, Deno Deploy 를 설명하고 BroadcastChannel API 로 채팅을 간단히 만들어보고 있네요.

 
ModernCloud - 브라우저 기반 서버리스 플랫폼

- AWS Lambda 개발을 브라우저에서 가능하게 해주는 오픈소스
ㅤ→ 로컬 개발환경 설정 필요없이 Function/Endpoint 개발
ㅤ→ 코드/테스트/배포를 브라우저만으로 (VSCode 웹, 자동완성)
- 별도 레이어 없음 : Terraform 기반 설정으로 세부 조절 가능
- GitHub 연동해서 싱크 및 CI/CD 지원
- 대시보드 제공
- Docker 로 실행 (기본 설정파일 제공)

 
Y Combinator, Co-Founder 매칭 플랫폼 오픈

- 무료 온라인 프로그램/커뮤니티인 스타트업 스쿨을 통해서 서비스 제공
- 베타기간 동안 약 9천번(4500명)의 매치 성사
- 공동창업자가 중요하다는 것은 데이터로 검증됨
ㅤ→ Top 100 YC 회사중 4개만 공동창업자가 없었음
- 찾고 있는 공동 창업자의 관심사, 위치, 기술 등에 대해서 적으면 매칭되는 프로필을 찾아주고 메시지 가능
ㅤ→ 심사과정을 거쳐서 등록
ㅤ→ 마치 온라인 데이트 같은 형태의 프로그램

 
Flicking v4 - 오픈소스 캐로셀 라이브러리

- 네이버 FE팀의 Carousel 오픈소스
- 사용자의 UI를 그대로 유지 : Flexbox 기반
- SSR(Server-Side Rendering) 지원
- 더 쉬운 커스터마이징 : 프레임워크별 튜토리얼, 내부 컴포넌트 정보 제공
- Vue3 추가 지원 : 기존 React, Angular, Preact 지원 포함, Svelte 지원 예정
- 새로운 Arrow, Pagination 플러그인

 
BitTorrent 20 주년 : 파일공유 혁명의 시작

- 2001/07/02에 Bram Cohen이 야후 게시판에 BitTorrent를 공개
- Napster 같은 다른 경쟁자들이 있었지만, 속도와 탈 중앙화로 차별화. 더 많은 사람이 참여하면 다운로드 속도가 증가
ㅤ→ 그 시절엔 소셜미디어도 없고, PR팀도 없었지만 널리 퍼짐

Embracing the Web
- BitTorrent가 공개되고 나서 몇달 뒤, 토렌트 사이트들이 생겨 나기 시작
ㅤ→ 음악,사진,소프트웨어,영화들 (종종 불법복제된)을 대중에게 공개하는 것은 이전에는 대역폭과 스토리지 때문에 불가능했음
ㅤ→ BitTorrent를 사용하면 작은 .torrent 파일만 호스팅하면 되므로 이게 게임 체인저가 됨
- Bram Cohen은 이런 논쟁의 여지가 있는 사이트들과는 거리를 두었지만, 일반적인 미디어 공유 기능은 수용
ㅤ→ etree 는 2001년말 BitTorrent 프로토콜을 채택한 최초의 사이트중 하나
ㅤㅤ라이브 콘서트 녹음을 온라인으로 배포하는 사람들로 구성된 커뮤니티
ㅤㅤ20년이 지난 지금도 운영중
- BitTorrent의 초기 성공은 대용량 파일을 빠르게 공유할 수 있는 비용절감 때문. 유튜브가 등장하기도 전이고, 인터넷도 전화 접속을 하던 당시에는 혁명적이었음.
- 웹과 빗토렌트 의 심리스한 연결은 검색이 가능하다는 장점도 있음
ㅤ→ 검색엔진의 도움으로 토렌트 사이트가 빠르게 성장
ㅤ→ 형사 기소된 The Pirate Bay 는 아직도 운영중 (전세대 최대 규모의 공개 토렌트 사이트)

토렌트 트래픽
- 2004년엔 인터넷 트래픽의 1/3 이 빗토렌트 였음
- 인터넷 업체들의 인프라에 부담이 되었고, 많은 ISP들이 토렌트 트래픽을 쓰로틀링하기 시작
- 쓰로틀링이 망 중립성 논쟁을 유발하는 시발점이 됨
- 쓰로틀링을 하는 ISP들을 정리해서 공개하기도 하고, 빗토렌트는 쓰로틀링을 하지 못하도록 프로토콜 헤더 암호화 기능을 추가
- uTP 기능은 ISP의 부하를 줄이기 위해 추가되기도.

BitTorrent, Inc
- 빗토렌트 프로토콜의 업데이트는 개발자인 Cohen이 모니터링했고, 그는 BitTorrent, Inc로 스타트업을 설립하고 투자를 받음
- BitTorrent, Inc는 해적 사이트들과는 전혀 관련 없고, 아티스트 및 권리 보유자들이 콘텐츠를 공유하는데 도움을 주도록 BitTorrent 개발에 집중
- 2007년에는 자체 비디오 스토어인 "torrent Entertainment Network"를 런칭했으나 1년후 폐쇄
- 최고의 결정 중 하나는 2006년에 스웨덴 개발자 Ludvig Strigeus 로부터 uTorrent 클라이언트를 구입한 것. 현재 시장 지배적인 클라이언트
- Ludvig Strigeus은 Spoitfy의 초기 개발자중 한명임
- uTorrent의 수익은 회사를 유지하는데 도움이 되었지만, 다른 프로젝트는 실패
- 2018년에 BitTorrent, Inc 는 TRON 재단에 인수되고, Bram Cohen은 회사를 떠남
- 최근 몇 년간 빗토렌트는 'Crypto'에 중점을 두었고, TRON 에서 BitTorrent Token(BTT)를 출시
- Bram Cohen은 Chia 코인을 개발 (제공하는 하드용량 기반으로 채굴이 되는 암호화폐)

BitTorrent ≠ Piracy
- 미디어에서는 빗토렌트는 불법 복제와 관련지어 얘기하지만, 빗토렌트는 그 이상이라는 걸 강조할 필요가 있음
- 트위터, 구글, 페이스북, NASA 를 포함한 많은 조직이 빗토렌트 기술을 활용해 왔음
- 많은 리눅스 배포판과 OpenStreetMap은 토렌트 피드를 제공
- 네트웍 밴드위스 비용이 줄어들면서 빗토렌트가 그 엣지를 좀 잃기는 했지만, 아직도 우수한 기술이자 혁신의 원천
- 빗토렌트의 미래가 어떻든 간에 인터넷 역사에는 한 자리를 차지했음

예전에 WoW (월드 오브 워크래프트) 클라이언트가 초기에 빗토렌트 프로토콜로 다운로드를 받게 했던게 생각이 나네요.
대용량의 데이터를 서버 비용 줄이면서 배포하는 데에는 분명 강점이 있지만, 불법복제 용도로 너무 널리 쓰여서 다들 오해하는 기술이 아닐까 합니다.

- Academic Torrents - 토렌트로 연구자료 공유하는 사이트 https://news.hada.io/topic?id=1291

 
페이스북의 GraalVM 도입기

- Facebook이 Spark를 가속하고 메모리&CPU 사용량을 줄이기 위해 GraalVM을 도입
- 페북은 Java를 빅데이터,백엔드,모바일 등 몇몇 주요 분야에서 사용중
- GraalVM으로 교체전에는 Oracle JDK 와 Open JDK Java 8/11 을 사용했음

왜 GraalVM을 선택?
- 성능이 주요 고려사항이었음. 전환하는 것 만으로 성능이 향상.
- GraalVM 이 Java로 작성되었기 때문에 유지 보수및 성능개선이 쉬워서, 장기적인 투자상대로 적합했음
- 휼륭한 커뮤니티를 가지고 있음

- OpenJDK를 GrallVM으로 대체하는건 매우 쉬웠고, GraalVM의 최적화 때문에 별도 튜닝없이 바로 성능이 향상됨
- 빅데이터 처리용 Spark를 GraalVM 위에서 실행해서 성능 향상
ㅤ→ 커뮤니티 버전은 1.1배, 엔터프라이즈 버전은 1.42배 향상
ㅤ→ 어떤 벤치마크에서는 4.84배까지 빨라졌음
ㅤ→ CPU 부하도 10% 줄어듬
ㅤ→ Polymorphic inlining, Partial escape analysis, Advanced speculative optimizations
ㅤ→ 단순히 GraalVM 으로 교체하는 것 만으로 Spark Workload 가 10% ~ 42% 속도가 개선

- 트위터도 GraalVM으로 교체하고 P99 Latency가 19.99% 까지 개선

 
JVM 에코시스템 보고서 2021

- AdoptOpenJDK 44% > Oracle (OpenJDK 28%, JDK 23%) > Azul 16% > Amazon Corretto 9%
- 60%가 이미 Java SE 11 사용중, Java 15 도 12%
- JVM 언어 : Java 91% > Kotlin 18% > Groovy 13% > Scala 10% > Clojure 8%
- IDE : IntelliJ IDEA 70% > Eclipse 25% > VS Code 23%
- 빌드 : Maven 76% > Gradle 38% > Ant 12%
- 프레임워크 : Spring Boot 58% > Spring MVC 29% > Java EE 24% > Jakarta EE 13%
* 2021년 2~3월에 2000명의 Java 개발자 대상으로 조사

 
Weferral - 레퍼럴 & 어필리에이트 오픈소스

- Affiliate (추천 & 제휴를 통해서 보상을 주는 프로그램)를 구현하기 위한 JS 오픈소스
- 커스터마이징 가능한 포털 과 대시보드
- 자동 트래킹 시스템
- 이메일 자동화
- 초대 기능
- 다양한 보상 체계 구현 : 반복/평생(인플루언서), 1회성(이커머스), 월 커미션(구독/SaaS), 고정/변동 퍼센트 기반 커미션
- REST API 제공
- Webhook 으로 자동화 가능
- 플러그인 프레임워크 및 RBAC(역할 기반 접근 제어) 추가 예정

 
리눅스재단에 게임엔진(Lumberyard)을 기부한 AWS

- 리눅스재단이 3D그래픽스, 렌더링, 저작, 개발에 연관된 프로젝트를 지원하는 Open 3D Foundation 설립
- 첫번째 프로젝트로 O3DE 엔진 개발을 추진. 아파치2.0 라이센스. https://o3de.org
- O3DE의 초기 코드베이스는 AWS가 개발한 Lumberyard 게임엔진. AWS가 기부함.
- Lumberyard는 AWS가 크라이텍사의 크라이엔진을 구매하여 추가 개발한 엔진으로 자사 스튜디오에서 사용 및 외부에 공개한 게임엔진.

 
AWS InfiniDash 이야기

- 가짜 제품인 AWS InfiniDash가 바이럴 된 현상을 정리
- Twilio의 개발자 Joe Nash가 가짜로 만든 InfiniDash 가 언젠가 JD에 포함될 수 있을것이라고 트윗
- 여기저기 퍼지다가 AWS의 CTO인 Werner Vogels도 이 농담에 참여해서 "Infinidash 의 GA Launch는 정말 중요하다"고 트윗
- @_skris가 InfiniDash 의 오픈소스 대체제인 OpenDash 를 발표, @DataMiller는 이 라이센스가 별로라고 다시 Fork한 DashIO를 멘션
- Signal 메신저가 AWS InifiniDash 경력을 가진 사람을 찾는다는 구인공고를 냄. (OpenDash 경력도 가능하다는 문구와 함께)
ㅤ→ 작년에 IBM이 나온지 6년밖에 안된 쿠버네티스의 최소 12년 경력자를 찾는다는 구인공고를 냈던 것을 놀리는 것
- 그외에 온라인 튜토리얼 "How to use AWS Infinidash with Node JS" 이나, "Advanced Infinidash: The Definitive Guide" 같은 가짜 책이 만들어짐
- 원 트윗한 Joe Nash는 깃헙의 CoPilot에 대해서 생각하다 나온 것이라고
ㅤ→ "많은 개발자들이 온라인에서 본 글들을 통해서만 기술에 대해 알게 될 것"
- AWS는 공식적으로는 대답하지 않았는데, 이에 대해서 한 연구자는 "아마존에는 제품이 너무 많이 때문에 이게 공식적으로 그들의 제품이 아닌지 확인하는데 오래 걸릴 것" 이라고..

 
Miniflare - CloudFlare Workers 로컬 시뮬레이터

- 서버리스인 Workers를 로컬에서 쉽게 개발할 수 있게 해주는 오픈소스
ㅤ→ 상세 로깅, 파일 감시, 보기 쉬운 에러페이지 제공
- Workers의 대부분 기능 지원
ㅤ→ Events : Fetch / Scheduled (수동/크론)
ㅤ→ KV, Cache, Durable Objects, WebSockets, Modules
ㅤ→ WebAssembly 지원
ㅤ→ Source Map 지원
ㅤ→ 웹표준 : Base64, Timers, Fetch, Encoding, URL, Streams, Crypto
- TypeScript 오픈소스

 
Prebid - 오픈소스 헤더(광고) 비딩 플랫폼

- Header Bidding : 퍼블리셔(웹,앱)가 광고 노출전에 여러 Ad Exchange / Ad Network에 인벤토리를 열어 입찰하게 해서 가장 높은 광고료를 비딩한 곳의 광고를 노출하는 방식
ㅤ→ 광고 노출자의 수익을 극대화
ㅤ→ 다양한 광고 포맷 지원 (Display,Video,Native)
- Prebid.js (웹), Prebid Server (클라우드), Prebid Mobile(iOS,Android) 등 자신의 플랫폼에 맞게 선택 가능
ㅤ→ 오픈소스
ㅤ→ 비동기 처리로 사용자 경험 향상
ㅤ→ 200개 이상의 광고 파트너 아답터, 15개 Analytics 어댑터
ㅤ→ 통화(Currency) 변환, GDPR 지원

- https://adop.cc/헤더비딩이-뭘까요/