[GN#58] Dropbox가 Nginx에서 Envoy로 전환한 이유, 모질라의 변화

2020-08-10 ~ 2020-08-16 사이의 주요 뉴스들
Dropbox는 2007년에도 사람들이 파일을 저장하고 공유하는데 불편한 USB를 사용하고 있다며 이를 해결하고자 나온 스타트업이었습니다. 편리한 기능으로 입소문을 끌고, 친구를 추천하면 추천자와 가입자 모두에게 용량을 더 주는 그로스해킹으로 2016년 기준 사용자의 45%가 추천으로 가입하면서 계속 성장, 2018년에는 IPO까지 성공하면서 하나의 기능에 충실한 유틸리티 스타트업의 성공 신화를 잘 보여준 기업입니다. 드롭박스도 기술 블로그를 아주 잘 운영하는 회사인데요. 최근에 올라온 "Dropbox가 Nginx에서 Envoy로 전환한 이유와 방법" 글을 간단히 요약한 뉴스가 이번주에 가장 인기가 많았습니다. Envoy는 MSA에서 필수라고 얘기되는데, 경량 스태틱파일 서빙으로 시작한 Nginx 에서 고성능 프록시로 시작한 Envoy로 이관하면서 둘의 기능을 상세히 비교한 글입니다. 약간 용도는 다르지만 Apache 와 Nginx 를 비교하던 시절이 있었는데 이제 시대가 흘러갔네요. MSA를 고려하거나 사용 중이시거나, Nginx를 프록시 용도로 사용 중이신 회사에서는 살펴봐 두시면 좋겠습니다.

Mozilla가 "변하는 세상, 변하는 모질라" 라는 글을 공식 블로그에 올리면서 새로운 비전과 함께 약 250명의 인원을 감축한다고 발표해서 큰 이슈가 되었습니다. 모질라가 Firefox 외에도 다양한 프로젝트들을 진행하고 있어서 어떤 팀들이 영향을 받는지가 많은 관심사였고요. 그들이 다른 회사로 갈 수 있도록/모셔올 수 있도록 인재 디렉토리와 Mozilla Lifeboat라고 하는 기존 모질라 재직자들이 있는 회사의 구인 글만 모인 사이트가 만들어지기도 했습니다. 거기에 추가로 예전 모질라 재직자가 현재 모질라의 상황을 잘 정리한 "모질라의 불확실한 미래"라는 글에서 왜 모질라가 이런 상황에 처했고 앞으로 어떻게 될 것인지를 얘기하기도 했습니다. 저 개인적으로도 모질라와 파이어폭스의 오랜 팬이어서 모질라가 어려운 상황을 딛고 다시 나아갔으면 합니다.

인터넷에서 함부로 이미지를 가져다 썼다가는 저작권 문제가 많기 때문에, 무료 이미지를 찾을 때 가장 유명한 사이트 중의 하나가 Unsplash 입니다. 이곳의 이미지들은 20만명이 넘는 사진작가들이 참여해서 직접 올린 무료 사진들이어서 편하게 가져다 쓸 수 있는데요. 특히나 깔끔한 API를 제공하기도 해서 개발할 때 종종 이용하는 곳이기도 합니다. Unsplash가 이렇게 올려진 많은 이미지를 모아서 머신러닝 등에 쓸 수 있도록 오픈 데이터셋을 만들어서 공개했습니다. 이미지 뿐만 아니라 상세한 메타데이터도 첨부되어 있어서 다양하게 이용이 가능합니다.

Unbundling은 기존에 다양한 일을 다 하고 있던 대기업의 기능을 세분화하여 작은 스타트업들이 더 강화하고 편하게 만들어내면서 비즈니스 모델을 혁신해 나가는 것을 얘기하면서 종종 사용되는 단어입니다. 기존의 은행, 택배, 자동차, 호텔 등이 이렇게 언번들링 되면서 다양한 회사들이 나오게 되었는데요. Jakob Freenfeld 라는 창업가가 "사업 아이디어가 필요하다면 Unbundling을 주목하세요" 라는 글을 통해서, 이런 대기업들이 아닌 인터넷 커뮤니티/특정 기술의 언번들링을 통해서도 비즈니스 아이디어를 도출할 수 있다는 글을 써서 인기였습니다. 여러분이 자주 가시는 커뮤니티에서도 한번 찾아보시는 건 어떨까요 ?


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

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


Dropbox가 Nginx에서 Envoy로 전환한 이유와 방법

수천만 동시 커넥션, 초당 수백만 리퀘스트, 테라단위 대역폭을 사용중인 드랍박스가 Nginx 대비 Envoy의 장점을 잘 설명한 글

기존 : nginx(오픈소스 버전) + python2 + Jinja2 + YAML
ㅤ→ 하나만 바뀌어도 전체 재배포 필요
ㅤ→ 동적인 부분은 Lua로 개발
ㅤ→ 복잡한 로직은 Go 기반 프록시인 Bandaid 에서 처리

근 10년간 잘 동작했지만, 현재 환경에는 잘 맞지 않음
ㅤ→ 내부 및 외부(비공개) API들은 점차 REST에서 gRPC로 전환중이어서 프록시의 트랜스코딩 기능을 필요로 함
ㅤ→ Protocol Buffers 가 내부 서비스 정의 표준으로
ㅤ→ 모든 소프트웨어들은 언어 상관없이 Bazel 로 빌드 및 테스트
ㅤ→ 주요 인프라 프로젝트들의 오픈소스 커뮤니티에 직원들이 꽤 헤비하게 참여 중

Nginx는 운영적인 면에서도 유지하기에 비쌈
ㅤ→ Config 생성 로직이 너무 유연하고 YAML, Jinja2, Python에 나눠져 있음
ㅤ→ 모니터링이 Lua / Log 파싱 / 시스템 기반 모니터링 의 믹스
ㅤ→ 써드파티 모듈에 의존성이 높아지면서, 안정성/성능에 영향을 미치고 잦은 업그레이드에 의한 비용 발생
ㅤ→ nginx 자체의 배포 및 프로세스 관리는 다른 서비스와 많이 다름. syslog, logrotate 등 기본 시스템과 전혀 다른것에 많이 의존

그래서 10년만에 처음으로 Nginx 를 대체할 것을 찾기로 함

* 왜 Bandaid(드롭박스가 자체 개발한 Go 기반 프록시)로 안가고 ?
ㅤ→ Go 는 C/C++ 보다 리소스를 많이 먹음.
ㅤ→ GO 의 TLS 스택은 FIPS 지원 안함 ( 미국의 연방 정보 처리 표준 )
ㅤ→ 내부 도구여서 외부 커뮤니티의 지원이 불가

현재 : Envoy 기반 트래픽 인프라로 전환

----- Nginx 보다 Envoy 가 더 나았던 점 ------

* 성능 *

Nginx 의 아키텍처는 이벤트 드리븐 / 멀티프로세스. SO_REUSEPORT & EPOLLEXCLUSIVE 지원
이벤트 루프 기반이지만 완전한 넌블로킹은 아님. 파일 오픈/로깅 시엔 이벤트 루프가 중단될 수 있음. (aio, aio_write 및 Threadpool 을 활성화 하더라도)
이를 통해서 테일 지연이 발생하고 몇초단위 딜레이가 생기기도

Envoy 도 비슷하게 이벤트 드리븐 아키텍쳐 이지만, 프로세스가 아닌 쓰레드 기반
SO_REUSEPORT 지원(BPF 필터 지원), libevent 를 통한 이벤트 루프 지원
이벤트 루프에서 블로킹 IO 없음. 이벤트 로깅도 넌블로킹 방식으로 구현.

이론적으로는 비슷한 성능 특징을 보일 것 같이 보였고 실제 대부분 워크로드 테스트에서도 비슷.
다만, Nginx가 롱테일에서 지연시간이 더 컸음. I/O많을때 이벤트루프가 중단되었기 때문.

통계수집 없이는 Nginx가 Envoy와 비슷한 성능을 보이지만, 내부에서 사용중인 Lua 통계 수집도구가 high-RPS 테스트에서 Nginx를 3배 느리게 만듬. (이건 뮤텍스로 동기화되는 lua_shared_dict 때문 ). 드랍박스의 통계수집 방식에 문제가 있긴 하지만 이걸 효율적으로 재개발하는 건 포기했음. (Nginx 내부에 인스트루멘테이션 하면 나중에 업그레이드가 어려울것이라고 예상했기 때문)

하여튼 이런 이슈들이 Envoy 에서는 없었기 때문에, 이전하고 나서 기존 Nginx 가 사용중이던 서버의 최대 60%를 릴리즈 할 수 있었음.

* Observability *

무료버전 Nginx 는 stub status 모듈에 7가지 stat만 제공
이걸로는 당연히 부족했으므로, log_by_lua 핸들러를 붙여서 더 많은 stat을 제공하고 있었음.
또한 error.log 파서를 통해서 에러정보를 내보내고, nginx 내부 상태값을 내보내기 위한 별도 exporter 도 존재.

기본적인 Envoy 셋업은 프로메테우스 포맷으로 수천가지 다른 메트릭들을 제공
프록시 트래픽 정보부터 서버의 내부 상태 정보,
클러스터별/업스트림별/가상호스트별 통계값과 리스너별 TCP/HTTP/TLS 다운스트림 통계 정보 등등

이런 다양한 통계와 함께, Envoy 는 Tracing Provider를 플러그인 가능.
트래픽 팀 뿐만 아니라 어플리케이션 개발자들에게도 유용함.

마지막으로 Envoy는 gRPC를 통해 액세스 로그를 스트리밍 가능.
이러면 트래픽 팀의 syslog-to-hive 브리지를 지원하는 부담이 줄어듬.
커스텀 TCP/UDP 리스너를 붙이는 것보다 일반적인 gRPC서비스를 실행하는 것이 훨씬 쉽고 안전.

* Integration *

Nginx 의 통합은 매우 유닉스 스러움. Configuration이 매우 정적.
config 파일이나 TLS 인증서, allowlist/blocklist 등을 파일에 의존.
간단하고 하위호환이 되기 때문에 몇개의 쉘스크립트로 자동화는 가능하지만,
시스템이 커짐에 따라서 테스트가능여부 및 표준화가 점점 더 중요해짐.

Envoy는 이런 통합에 대해 자신만의 방법을 가지고 있음.
xDS라고 부르는 API를 제공해서 protobuf 와 gRPC 사용을 장려.
Envoy는 이런 xDS에 쿼리를 통해서 동적 리소스를 찾음.

- 이 xDS는 이제 Envoy 를 넘어서 Universal Data Place API(UDPA) 라는 이름으로 L4/L7 로드밸런서의 de facto 표준이 되려고 진화하고 있으며, 우리 경험으로는 이게 잘 되어가고 있음. Envoy께 아닌 Katran eBPF/XDP L4 로드밸런서에도 UDPA를 사용하려고 하는 중.

드랍박스는 내부적으로 gRPC를 통해서 서비스들이 연동하고 있기때문에 훨씬 좋음.

* Configuration *

Nginx 는 사람이 읽기 쉽다는 설정파일이라는 큰 장점을 가지고 있음.
하지만 이 장점은 점점 설정이 복잡해 지고 자동 생성되면서 그 장점을 잃어버림.
드랍박스는 Python2,Jinja2,YAML 등을 통해서 생성되다 보니 그러다보니 데이터 모델도 꼬이고 복잡.

Envoy는 설정에 대한 통합된 데이터 모델을 가지고 있음. 모든 설정값은 Protocol Buffer에 정의됨. 데이터 모델링 문제가 해결되며, 설정값에 타입 정보가 추가됨.
드랍박스 내부에서 protobuf 가 많이 쓰이기 때문에 통합을 쉽게함

* Extensibility *

Nginx 의 확장성을 위해서는 C모듈 작성이 필요함. 안전한 모듈 작성을 위해서는 시니어 개발자가 필요. 좀더 가벼운 모듈 개발을 위해서 Perl / JS 인터페이스도 제공하긴 하지만 매우 제한적임. 그래서 가장 일반적으로 쓰이는 방법이 lua-nginx-module 을 통한 것.

Envoy 의 주 확장 메커니즘은 C++ 플러그인을 통해서인데 문서화는 nginx 처럼 잘 되어있지는 않지만 매우 간단함. 이건 깔끔하게 잘 코멘트된 인터페이스, C++14 언어와 표준 라이브러리 등 덕분

Envoy 가 다른 웹서버와의 큰 차별점은 바로 WebAssembly(WASM)의 지원 여부.
이를 통해 Rust 같은 다양한 언어들을 통해서 확장 개발 하는걸 지원 가능.
아직 드랍박스에서 WASM을 안쓰지만, 언젠가 Go SDK for proxy-wasm 지원이 된다면 변경될 수도 있음

* Building and Testing *

Nginx는 기본적으로 커스텀 쉘 기반 설정 과 make 기반 빌드를 사용. 간단하고 훌륭하지만 이걸 Bazel로 빌드되는 모노레포에 연동하기엔 꽤 많은 노력이 들어감
Nginx 는 펄기반 integration 테스트가 있지만 유닛테스트는 없음.

Envoy 는 이미 빌드시스템이 Bazel 기반이고 간단하게 우리 모노레포에 연동했음.
gtest/gmock 기반 유닛테스트와 integration test framework 를 지원

* Security *

Nginx 코드는 매우 작고 외부 의존성도 작아서 보안상 취약점이 많지 않음.

Envoy 는 코드가 많아서 아무래도 공격할 지점이 많아 보임. 이를 위해서 Envoy 는 현대적인 보안 프랙티스에 많의 의존. AddressSanitizer, ThreadSanitizer, , MemorySanitizer 등을 사용.

* Features *

이 부분은 주관적인 의견이 많으므로 참고 할 것

Nginx는 처음에 아주 적은 리소스로 스태틱 파일을 서비스 하는 웹서버로 시작.
즉 static serving, caching, range caching 이 주 기능
프록시 관점에선 Nginx는 요즘 인프라에서 요구하는 기능들이 많이 부족.
백엔드와의 HTTP/2접속도 안되고, 멀티연결되는 gRPC 프록시도 안됨. gRPC 트랜스코딩도 불가 등.
오픈코어 방식의 라이센스 모델이라 몇몇 주요한 기능들이 "커뮤니티 버전"엔 빠져있음

Envoy 는 에초에 ingress/egress proxy로 시작했고, gRPC 로드가 많은 환경에서 많이 사용.
웹서비스 기능은 매우 초보적인 수준. 파일 서빙도 불가, 캐슁도 아직 만드는중이고 brotli 도 미지원 등
이런 환경을 위해서는 Envoy를 업스트림 클러스터로 쓰는 Nginx 셋업도 사용중
Envoy 가 HTTP 캐쉬 가능해지면 이런 스태틱 서빙 환경도 옮길 수 있을 것으로 예상

Envoy는 gRPC 관련 기능을 많이 지원
- gRPC proxying
- HTTP/2 to backends
- gRPC → HTTP bridge (+ reverse.)
- gRPC-WEB
- gRPC JSON transcoder

또한 Envoy는 outbound proxy 로도 사용 가능
- Egress Proxy
- Third-party software service discovery with Courier gRPC 라이브러리

* Community *

Nginx 개발은 중앙방식이고 대부분 숨겨져 있음.
Envoy 개발은 열려있고 탈중앙화. GitHub 이슈/PR로 진행되며 메일링/슬랙등을 통해서도 활발

----- 드롭박스의 현재 Migration 상태 -----

Nginx 와 Envoy 를 같이 반년째 운영하며 DNS를 통해 점진적으로 트래픽 이관중
아무 문제도 없이 이관 된 것은 아니며 작은 이슈는 있었지만, 심각한 장애는 없었음.
"unusual" 하거나 "non-RFC" 적인 행동들 때문에 겪었던 문제들에 대한 해결책도 정리(본문에 상세 내용이 있으니 참고하세요)

** 앞으로 할 일들 **

- HTTP/3 : Envoy 도 실험적으로 지원하기 시작. UDP 가속을 위해 리눅스 커널을 업그레이드 하면 실험해 볼 예정
- 내부 xDS 기반 로드밸런서와 Outlier Detection
- WASM 기반 Envoy 확장
- Bandaid (Go 기반 프록시) 를 Envoy로 교체
- Envoy Mobile 로 모바일 앱에도 Envoy 적용

 
변하는 세상, 변하는 모질라. ( 모질라의 구조조정 소식. )

모질라가 250명을 해고하는 구조조정을 단행했습니다. COVID-19로 매출에 큰 타격을 입은게 주요 원인입니다. 봄 이후로 직원들과 해고 가능성과 변화의 필요성에 대해 이야기 하였고. 그럼에도 이런 결정을 내린 건 힘들었다고 전했습니다.

모질라는 이전 구조로는 브라우저를 넘어 새로운 제품과 기술을 제공하는데 적절하지 않았다고 하며. 앞으로 조직을 더 작고, 민첩하고, 빠르게 조정하는 조직이 되겠다고 하였습니다. 또한 앞으로 제품을 만들 떄, 5가지 핵심 가치를 소개하였습니다.

- 제품에 관한 새로운 초점. -> 세계적이고, 현대적인 다중 제품 인터넷 조직이 되도록.

- 새로운 사고 방식 -> 인터넷은 플렛폼화 되었기에. 기존에 인터넷에서만 머물던 사고 방식을, 더 새로운 것을 만들 수 있는 곳으로 옮길 수 있도록.

- 기술에 대한 새로운 초점 -> 리더쉽을 제공하고, 제품을 테스트하고, 기존 웹 기술이 아닌 영역으로 비지니스를 유도할 수 있도록.

- 커뮤니티에 대한 새로운 초점 -> 지금까지 오픈 소스를 기여하던 사람뿐만 아니라, 새로운 사람들에게도 열린 커뮤니티가 되도록.

- 경제에 대한 새로운 초점 -> 모든 게 무료였던 것 구형 모델의 결과를 되짚어 보고, 다양한 비지니스 기회와 대체할 수 있는 가치로 교환할 수 있는지 탐색.

저도 파폭을 메인으로 사용하고, 모질라를 좋아하는 입장이지만... 많은 고민이 필요한 시점인 것 같아요. 지난 10년 간 모질라가 파이어폭스 말고 제품이 될만한 걸 했는가라고 물으면.. 부정적인 답변이 들릴 수 밖에 없을 것 같습니다.

댓글 중에 '모질라는 아예 오픈 웹에만 초점을 맞춘 비영리 재단의 위치를 잡았어야 했고 Firefox OS, 음성인식, AI, Pocket과 통합 같은 자잘한 것들을 쳤야 한다고 생각함.' 이라는 댓글이 있는데. 회사로써의 모질라인가, 재단으로써의 모질라인가 확실히 결정해야할 때가 오고 있는 것 같네요.

계속 관련글들이 나오고 있는데, 정리해고된 팀이 좀 충격적이네요.

- devtools 팀 과 Threat managment 팀 : 개발자들이 가장 선호하던게 개발도구인데 왜 이걸?!
- MDN 팀 전체 : 요즘 웹 개발문서 중에서는 가장 볼만한 곳이었는데?!
- Servo 개발팀 : Rust로 만들어진 임베딩 적합 최신 브라우저 엔진. 이거 미래 먹거리 수준이라고 생각했는데요.

Rust 팀과 WASMTime 팀도 (WebAssembly 스탠드얼론 런타임) 도 포함이군요.
요즘 모질라에서 개발쪽에서 제일 잘나가는 부분들만 골라서 다 쳐낸 느낌..
이러다 보니 수뇌부가 무슨 생각을 하는지 모르겠다는 얘기가 나오는 거 같아요.

 
Mozilla의 불확실한 미래

모질라에 10년전 근무했던 사람이 좀 멀리서 객관적으로 바라본 모질라의 현재 상태 설명

- 모질라는 실제로 2개 : 재단과 회사
1. Mozilla Foundation(재단)
ㅤ→ 2003년에 만들어진 비영리(비과세) 재단으로 넷스케이프 브라우저 소스코드 개발을 넘겨받기 위해 설립
ㅤ→ 직원 80명, 2018년도 예산 $27M(320억원)
2. Mozilla Corporation(회사)
ㅤ→ 2005년에 만들어진 영리 회사로 모질라 재단이 전체를 소유
ㅤ→ 직원수 천명이상, 2018년도 매출 $440M(5200억원)

이 구조를 통해서 회사가 미국의 비과세 법령에 맞지 않는 일들을 할수 있게 되고, 그 수익 중 일부를 재단에 보내서 활동을 유지하게 할 수 있음. 이렇게 회사가 비영리 부모를 가지는 것은 모질라 회사의 멤버들이 재미난 일들과 적절한 연봉수준을 받으면서 활동 하는 것 자체가 재단의 공공목적을 도와주는 것이 되게 만듦.

모질라 회사의 고객은 Firefox 의 사용자가 아님. 모질라 회사의 고객은 구글같은 대기업 들로 Firefox 브라우저의 기본 검색이 Google이 되게함으로써 돈을 벌고 있음. 다르게 말하면 2억명의 파이어폭스 사용자가 제품이며, 그들은 구글같은 회사의 광고의 노출대상이 되는 것.

(구글의 크롬에 대한 경쟁자로 Firefox 가 존재하는 것 자체가 구글이 반독점에 대한 이슈를 피하는데 도움이 될 것으로 보임. 특히 MS가 자체 브라우저를 포기하고 크롬으로 넘어간 것도 있고. 하지만 이게 구글의 고위경영진에게 얼마나 중요한지는 불분명.)

이 기본 검색엔진 계약은 모질라 회사의 초기인 2004년에는 $5M(60억원)에서 2005년엔 $50M(600억원)이 되고, 2017년에는 $540M(6400억원)까지 올라갔음.

하지만, Firefox 사용자가 줄어들고(크롬 사용자 층이 더 넓어지면서), COVID-19 여파로 광고클릭양이 줄어들거나 하면서 구글과 다른 고객들이 모질라 회사에 주는 비용도 같이 줄어들게 되자, 모질라 회사는 인력의 1/4을 감축하게 된 것.

(대조적으로 모질라 재단은 아무도 해고하지 않음. 재단은 Firefox 및 Mozilla 상표의 사용, 정부 및 재단 보조금, 개인기부등에서 예산을 충당. 2018년 기준 로열티가 예산의 절반이며, 보조금과 개인기부금이 각각 1/4씩을 차지)

당신이 열성적인 Firefox 사용자여서 개발을 후원하고 싶다고 해도 직접 돈을 보낼 방법은 없음. 당신의 기부금은 재단으로 갈꺼고 그 비용은 그 재단이 하는 홍보(Outreach) 및 옹호(Advocacy) 활동을 지원하게 되는 것. "모질라 재단은 제가 알기로는 Firefox 및 어떤 소프트웨어도 개발하지 않습니다."

- 현재 모질라는 어디에 있을까 ?

모질라 회사는 왜 이런 상태가 되었을까 ? 내가 이걸 가장 잘 설명하는 방법은, 모질라 회사는 우리가 일반적으로 생각하는 비즈니스(수익에 집중하고 시장 규율을 따르는) 회사가 아니라는 것.

모질라 회사는 예전의 Bell Labs 나 Xerox PARC와 유사하다고 생각할 수 있음. 그때 이 R&D 조직들은 각 시장에서 우위를 차지한 다른 사업에서 벌어들인 끝없는 수익으로 자금을 지원 받았음. 즉, 현재의 구글과 모질라의 관계는 AT&T 와 Bell Labs, Xerox 와 Xerox PARC 의 관계와 같음. ( 구글이 낸 수익으로 모질라에게 돈을 줘서 그 R&D를 지속한다는 얘기 )

벨연구소와 제록스PARC 처럼 모질라 재단은 뛰어난 개발자들이 모여들 수 있게 했고, 유용한 프로젝트 부터 약간은 난해하고 신기한 프로젝트 까지 다양한 것들을 만들고 외부에 공공재 형태로 제공했음.

벨연구소와 제록스PARC 처럼, "Build It Yourself" 에 빠져서 수직통합을 통해 모든것을 직접 만들었음. Firefox OS 부터, Rust 언어, 브라우저 까지.

그래서 최종적으로, 벨연구소와 제록스PARC 가 했던 투쟁에 똑같이 동참. 연구중심 조직을 실제 비즈니스로 전환하고, 무료로 제공했던 것들로 부터 좀 더 가치를 끌어내려고 하는.

- 모질라는 어디로 갈까 ?

기본적으로 모질라 회사는 3가지 것을 동시에 추구했음.
1. 옹호단체(Advocacy Organization)
2. 대중을 위한 소프트웨어 및 관련 서비스의 개발자 및 배포자
3. 연구 실험실(Research Lab)

옹호단체가 되는것은 비용이 적게 들지만, 나머지 두개는 그렇지 않음. 소프트웨어 개발과 브랜딩&마케팅은 모질라 회사 및 재단 비용의 3/4를 소비(2018년 $450M). COVID-19가 발생하고 모질라 회사가 검색엔진 수익이 줄었을 때 그들의 선택은 2번과 3번 둘중의 하나를 그만두는 수 밖에 없음.

그래서 최종적으로 모질라 회사의 경영진의 선택은 2번 소비자 대상 소프트웨어 및 서비스 회사가 되고, 그 외의 연구프로젝트를 포함한 모든 활동을 다 걷어내는 것이 된 것. 그러자 여러가지 문제에 직면하게 됨

1. 모질라 정신은 사업보다는 R&D 실험실과 더 비슷한데, 모질라의 멤버들이 자신이 수익사업에 일한다고 생각하게 하는건 힘듬.

2. 모질라는 최대고객인 구글에게 필요없는 존재가 되어가고 있음. 구글은 자체 연구조직에 비용을 쓰고 싶어할 것이고, 또한 Firefox 사용자를 끌어올 능력과 기회를 둘 다 가지고 있음. 많은 Firefox 사용자는 검색엔진을 구글 대신 다른것을 사용하기도 하고, 광고차단기도 실행. 구글에게 있어서 Firefox 의 가치는 반독점 이슈도 있긴 하지만, 그렇다고 (2억명이나 되는) 사용자 기반까지는 필요없음.

3. 모질라 회사가 검색엔진 회사가 아닌 일반 사용자 대상 비즈니스를 잘 운영할 수 있을지는 회의적. 예전부터 구글 의존을 탈피하고자 했지만 성공하지 못했음.

간단하게 계산해봐도 검색엔진으로부터 들어오는 $100M 의 수익을 대체하려면, 2억명 이상의 Firefox 사용자로부터 1년에 50센트 씩만 받으면 됨. 하지만 인터넷 사용자들은 무료에 익숙해졌기 때문에, 아무리 Firefox 사용자일지라도, 저렇게 낮은 금액 마저도 지불하지는 않을 것.

만약 2%의 Firefox 사용자가 모질라 제품을 구매한다면 (일반적으로 freemium 제품군의 컨버전 레이트가 2% 정도니까), 지금 올리는 $500M 매출을 올리려면 인당 년에 $125씩 내야 한다는 것. 이건 엄청 큰 금액임.

만약 모질라 회사가 수익내는 비즈니스로 사업전환을 하지 못한다면 다른 기회는 뭘까 ?

하나는 장기적으로 지속가능한 규모로 조직을 축소하고 모질라가 비영리 미션을 잘 수행할 수 있도록 보장하는 것. 예를 들어, Firefox 자체의 기본 유지보수를 제외한 모든 개발을 중단하고, 더 큰 사용자 기반을 유지해서 모질라에 돈 내는 사람(구글같은)들에게 정당한 이유를 만들어 주는 것.

보다 과감한 방식은 몇년동안 소프트웨어 개발 사업을 다 접고 모질라 회사의 자산을 다 청산한 다음, 인터넷 및 웹 옹호(Web Advocacy)에 초점을 맞춘 순수한 비영리 조직으로 되돌리는 것. 하지만 이건 앞 시나리오보다 더 실현가능성이 적음.

마지막으로는 인터넷과 웹을 위한 "공익 R&D 연구소"가 되어, 공공재를 생산하는 연구활동을 주로하면서 여러 재단과 정부로 부터 펀딩을 받는 것도 있음. 이런방식으로 대규모 비영리 재단을 만드는 것이 가능. 예를 들어 Battelle Memorial Institute, the MITRE Corporation, Johns Hopkins University Applied Physics Laboratory 같은 것들 처럼. 물론 이들이 크게 된 것은 국방계약을 따냈기 때문인데 모질라의 멤버나 경영진이 DoD(미국 국방부)와 계약할 의사가 있는지는 미지수.

결국, 모질라 회사는 현재의 길을 계속 가면서 다양한 사용자 대상 비즈니스를 계속 시도할 가능성이 가장 높고, 그 중 성공하는 것 없이 점점 매출이 줄으면서 조직을 천천히 축소하게 될지도 모름. 10년안에 모질라 재단은 적당한 자금을 지원받는 옹호단체로 남고 모질라 회사는 그냥 추억이 될 수 있음.

모질라 회사가 15년, 모질라 재단은 17년, 모질라 프로젝트는 20년이 넘었음.
그동안 실제로 모질라는 외부에 알려진 것보다 더 큰일을 수없이 해왔음.
당장 내일 닫더라도 Bell Labs 나 Xerox PARC처럼 역사에 한 자리를 차지할 것.

HN에 모질라 직원도 현재 전체 상황설명을 잘 했다고 댓글을 달았더군요
근데 최종 결론은 모질라 회사 자체는 저렇게 없어질거라는 예언(저주? 운명?)스러운 건데..

저는 그 정도까지 가지는 않을거라 생각하고, 그렇게 안되었으면 좋겠어요.
브라우저 시장에 크롬만 남은 상황은 바라지 않아요.
사파리가 있잖아! 하기엔 애플은 너무 독단적이고요.

모질라가 시도하고 있는 다양한 비즈니스 들중 몇개는 수익화에 성공해서 오래오래 유지되기를 기원합니다.

 
Thank you MDN

모질라 구조조정 여파로 MDN(Mozilla Developer Network)팀이 모두 나가게 되자, 그동안 잘 써왔던 MDN Web Docs에 고마움을 표시하기 위해 만들어진 페이지
- 모질라 측에선 MDN사이트는 없어지지 않을 것이며, (아주 작은 인원의) 내부 팀과 외부 필자들에 의해서 계속 나아갈 것이라고 밝힘.
ㅤ→ 실제로 구글/MS에는 풀타임으로 MDN에 기여하는 직원들이 있으며, Wiki 형태이기 때문에 누구든 참여 가능

 
Mozilla Lifeboat

구조조정 된 Mozillian 들을 위해, Mozilla Alumni/컨트리뷰터/팬들이 자기 회사의 구인정보를 등록하는 사이트
- 회사소개 / 구인하는 분야 / 구인글 링크
- 그 회사에 근무하는 Mozillian 연락처가 포함된게 독특
- 하단엔 Mozilla Talent Directory도 같이

Mozilla Talent Directory : Please meet some talented people who’ve worked at Mozilla.
https://talentdirectory.mozilla.org/

 
Unsplash, 2백만개 이미지 오픈 데이터셋 공개

온라인 이미지 서비스인 Unsplash가 20만명 이상의 사진가들이 참여한 이미지들을 무료로 공개
- Lite : 550MB, 2.5만개 이미지, 키워드 2.5만개, 상용에도 무료 사용가능
- Full : 16GB, 200만개 이미지, 키워드 500만개, 검색어 2억5천만개, 비상용에만 무료 사용가능
- 다양한 메타데이터 포함 : 키워드-이미지 변환, 커뮤니티 및 AI가 생성한 키워드, EXIF(카메라 모델/렌즈/심도 등), 위치정보 및 랜드마크, 이미지 카테고리, 사용자가 만든 컬렉션 정보, 다운로드 통계

깃헙 레포 : https://github.com/unsplash/datasets

Unsplash 는 무료 이미지 사이트중 최고입니다. 깔끔한 API로 뭔가 이미지를 가져다 사용할 때도 좋지만
https://source.unsplash.com/ 를 통해서 API연동없이 랜덤 이미지를 가져다 쓰는 기능이 정말 편합니다.
여기서도 API처럼 이미지 크기 조절도 가능하고 카테고리 지정도 가능.

 
사업 아이디어가 필요하다면 Unbundling을 주목하세요

기존 대기업을 언번들링한 사례대신, 커뮤니티/특정 기술의 언번들링을 예로 들어 설명한 글
Unix, Craiglist, Spreadsheet, Hippie Culture, Reddit, Universites, Wordpress, Webhosting

- Unix 언번들링
grep → Google
rsync → Dropbox
man → Stack Overflow
cron → IFTTT
finger → Social Media

- Reddit 언번들링
r/startups → IndieHackers
r/medicine → Doximity
r/Beauty -> Supergreat
r/funny → 9gag
r/sports → StadiumLive
r/Streamers → Pipeline.gg
r/insert city → Nextdoor
r/books → Goodreads
r/digitalnomad → Nomadlist
r/fitness → Fitocracy
r/design → Designer News
r/GrowthHacking → GrowthHackers.com

- Universities
Community → PhysicsForums, Discord Servers,
Content → Udemy, Masterclass
Credentials → Coursera, edX
Network → Twitter, Clubhouse, LinkedIn
Support → StackExchange
Access to Books → Scribd, Libgen
Learning Spaces → https://www.focusmate.com/
Accountability → ???

- Wordpress
Publishing → Medium, Ghost
Ecommerce Plugins → Shopify
Buddypress → Tribe.so
Membership Plugins → Mighty Networks, Ghost
Contact Form Plugins → Typeform
Comments → Disqus

- Webhosting
Database → Cloud Firestore, FaunaDB
Authentication → Auth0
Content Delivery → Cloudflare, Netlify
Version Control → Github, Gitlab, Bitbucket
Email → Mailchimp, ConvertKit

기존 기업/산업의 언번들링 설명과 사례는 아래 글을 참고 하세요

- 스타트업에 의해 해체되는 대기업: Unbundling 현상 https://estimastory.com/2015/04/21/unbundling/
ㅤ→ 미국은행(웰스파고), 유럽은행(HSBC), P&G , Honeywell(IoT), Fedex
- 자동차 산업 언번들링 : https://cbinsights.com/research/…
- 호텔 산업 언번들링 : https://www.cbinsights.com/research/unbundling-the-hotel/

 
simdjson - JSON을 GB/초 단위로 파싱하기

- SIMD 명령어셋을 이용해서 기존 파서들보다 2.5배 빠르게 파싱
- 런타임에 CPU별 최적화된 파서 자동 선택 : 하스웰(AVX2)/웨스트미어(SSE4.2)/ARM64/기타64
- Full JSON & UTF-8 validation 지원
- 한개의 .h + .cpp 파일
- RapidJSON 대비 25%, sajson 대비 50%의 명령어 셋만 사용

다양한 바인딩 / 포트가 있네요

- ZippyJSON: Swift bindings for the simdjson project.
- libpy_simdjson: high-speed Python bindings for simdjson using libpy.
- pysimdjson: Python bindings for the simdjson project.
- simdjson-rs: Rust port.
- simdjson-rust: Rust wrapper (bindings).
- SimdJsonSharp: C# version for .NET Core (bindings and full port).
- simdjson_nodejs: Node.js bindings for the simdjson project.
- simdjson_php: PHP bindings for the simdjson project.
- simdjson_ruby: Ruby bindings for the simdjson project.
- fast_jsonparser: Ruby bindings for the simdjson project.
- simdjson-go: Go port using Golang assembly.
rcppsimdjson: R bindings.

링크된 강연 동영상의 녹취록:
https://www.infoq.com/presentations/simdjson-parser/

어떻게 이렇게 빠른 속도를 낼 수 있는지 궁금해서 읽어봤는데, 가히 온갖 흑마술의 결정체라 할 수 있을 것 같습니다. 요점을 대강 정리하면 다음과 같습니다.
----
[서론]

# 대부분의 JSON 파싱 라이브러리는 드라이브의 순차 읽기 속도보다 느리다
- 나(강연자 Daniel Lemire)의 시스템 드라이브에서 큰 텍스트 파일을 순차적으로 읽어들이는 속도는 2.2 GB/s인데, 주요 JSON 라이브러리의 파싱 속도는 이를 못 따라가더라.
- 파싱 속도가 1 GB/s를 넘기는 라이브러리가 드물길래, 우리가 작접 만들어보기로 했다.
- 그 결과, 드라이브 대역폭을 전부 쓸 수 있는 처리 속도를 달성했다. 계산해보면 입력 1바이트당 CPU를 1.5사이클밖에 쓰지 않았다. 어떻게 이를 달성했는가?

[각종 원칙들]

# 분기문을 최대한 피한다
- 예를 들어 랜덤 숫자를 배열에 집어넣는 간단한 코드에 숫자가 홀수인지 판별하는 if문 하나만 넣어도 5배로 느려진다. 이는 CPU 분기 예측이 실패할 때의 비용이 크기 때문이다.
- 위에서 제시된 코드에서 비트 연산으로 if문을 제거하면 속도가 거의 원상복구된다.
- 코드를 반복 실행하면 분기 예측의 정확도가 올라가서 성능 저하가 감소할 수 있긴 하지만, 이건 결국 비결정론적인 동작이므로 분기 예측이 작용할 때면 성능을 예측하거나 측정하기가 어려워진다.

# 더 넓은 워드를 쓰기 위해 SIMD를 적극 사용한다
- SIMD 명령을 쓰면 64비트보다 더 넓은 워드의 레지스터를 사용할 수 있어, 1사이클에 더 많은 데이터를 처리할 수 있다. (예를 들면 SSE나 NEON은 128비트, AVX는 256비트) 따라서 가능하면 SIMD를 적극적으로 사용했다. 이는 입력 데이터 1바이트에 불과 1.5사이클만 사용할 수 있었던 비결이다.
- SIMD를 쓰기 위해 특정 프로세서에 의존적인 내장 함수(Intrinsic function)를 사용했다. 어셈블리어를 직접 사용하는 것은 권장하지 않는다.

# 메모리/객체의 할당을 피한다
- simdjson에서는 JSON 데이터를 하나의 긴 테이프처럼 취급하고, 데이터를 재활용한다. 다시 말해, 문자열이나 숫자에 메모리를 따로 할당하지 않고 모든 것을 일렬로 처리한다. 이는 흔한 트릭이다.

# 성능을 계속 측정한다
- 벤치마크 주도적으로(Benchmark-driven) 개발하였다. 우리 CI에는 성능 벤치마크가 포함되어 있다.
- 참고로 뭔가 CPU 집중적인 작업을 할 때는 CPU의 작동 주파수가 계속 변한다는 점을 명심해야 한다.

[실제 사례들]

# 예시 1: 올바른 UTF-8인지 검증하기
- 입력된 임의의 데이터가 올바른 UTF-8 코드포인트인지 검증하는 작업은 일반적으로 여러 분기문이 들어가는 작업이다.
- 우리는 SIMD로 32바이트 데이터를 최대 20번의 사이클만에 분기문 없이 올바른 UTF-8인지 검증하는 방법을 만들었다.
- UTF-8의 바이트는 정수값으로 최대 244를 넘을 수 없으므로, SIMD 명령으로 데이터를 256비트 레지스터에 넣고 각 바이트마다 정수 244를 포화 연산(Saturation arithmetic: 결과값의 범위를 제한하는 연산)으로 뺀 다음 0이 아닌 값이 없는지만 확인하면 된다.
- 이 방법은 분기문을 사용하는 방법보다 20배 이상 빠르다!

# 예시 2: 글자 종류 분류하기
- JSON을 파싱하려면 콤마, 콜론, 괄호, 공백 등 각종 문자를 종류별로 분류해야 한다.
- x86-64 및 ARM NEON에는 16바이트 크기의 룩업 테이블을 단번에 찾는 명령어가 있다.
- 1바이트를 상위 4비트와 하위 4비트로 나누어, 미리 준비한 2개의 룩업 테이블을 각각 적용한 다음 그 결과를 AND 연산한다.
- 코드가 더러워 보이긴 하지만, 5개의 명령만으로 분기문 없이 16개의 글자를 분류할 수 있다.

# 예시 3: 이스케이프 문자 감지하기
- 백스페이스(\) 문자를 앞에 붙여서 표현하는 이스케이프 문자를 분기문 없이 감지할 수 있을까? 특히 백스페이스 자체를 이스케이프 처리하기 위해 백스페이스가 연달아 나오는 경우도 처리해야 한다.
- 이런 경우, 홀수번째 백스페이스만 보면 된다는 트릭이 있다.
- 짝수번째 위치와 홀수번째 위치를 나타내는 비트마스크를 상수로 두고, 복잡한 비트 연산을 거치면 분기 없이 이스케이프 문자를 걸러낼 수 있다.
- 이스케이프된 따옴표를 걸러내고 나면 남는 것은 문자열을 나타내기 위한 따옴표이다.
- 이렇게 구한 따옴표의 위치를 비트마스크로 두고 xor 비트 연산을 거듭하면 문자열의 위치를 나타내는 비트마스크를 구할 수 있다. 이 부분은 대부분의 프로세서에서 명령어 하나로 처리할 수 있다.
- 비트 집합과 문자열 위치를 대응하는 방법에도 트릭이 있지만, 시간 관계상 넘어가겠다.

# 예시 4: 숫자 파싱하기
- 숫자를 파싱하는 것은 대단히 비싼 작업이다. 잘 최적화한 C 함수로 부동소수점을 파싱하는 벤치마크를 했더니 0.09 GB/s라는 환장하는 속도가 나왔다. 명백한 병목 지점이었다.
- 숫자를 파싱하는 대부분의 코드는 한번에 바이트 단위로 작업하는 것이 보통이다. 이는 결코 빠르지 않다.
- 문자 8개를 가져와서 64비트 정수 하나로 만들고 강연자가 토요일 밤늦게 고안해낸 특정 공식에 대입하면 이 8개의 문자가 연속된 8자리 숫자인지 알 수 있다. 이는 특히 자릿수가 많은 숫자일수록 파싱하는 데 시간이 오래 걸리기 때문에 중요하다.
- 스택 오버플로우에 보니까 8자리 정수를 빠르게 파싱하는 코드 스니펫도 있더라. SIMD를 쓰면 좀 더 개선할 수 있긴 한데, 중요한 것은 이렇게 한 번에 데이터를 많이 처리하는 전략에 관한 아이디어를 얻는 것이다.

[그 외]

# 런타임 디스패치
- 하드웨어 의존적인 코드가 많이 들어가다 보니 각 프로세서별로 최적화된 함수가 나오는데, 실행할 때 프로세서 종류에 맞는 함수를 실행하게끔 하는 것이 상당히 어려웠다.
- 그게 뭐가 어려운지 이해를 못할 수도 있겠는데, 문제는 컴파일러 종류를 가리지 않는 이식성 있는 코드로 이런 것을 구현하는 것이었다. 어떤 컴파일러에는 버그가 있기도 했고, 또 언어 차원에서 이런 것을 지원하는 것도 아니다.
- 이 점은 simdjson이 다른 프로젝트에 쉽게 통합할 수 있는 단일 헤더파일 오픈소스 라이브러리라서 중요했다.

# 기타
- 여러 언어에서 쓸 수 있도록 각각 wrapper가 있다.
- Rust 포팅 버전이 있고 Go와 C# 포팅도 준비중이지만, Java 포팅은 없다.
- 이 프로젝트에서 사용된 여러 수학 공식들은 공동 저자인 Geoff Langdale과 고안한 것으로, VLDB Journal에 관련 논문을 출판하였다. ( https://doi.org/10.1007/s00778-019-00578-5 )

 
음악을 만들어봅시다

경험이나 장비 필요없이 브라우저위에서 배우는 음악 제작의 기초 [한국어]
음악 소프트웨어와 장비를 만드는 Ableton이 음악을 모르는 사람도 따라할 수 있도록 쉽게 정리한 가이드

- 비트 :
ㅤ→ 비트 만들기
ㅤ→ 사운드에 관하여
ㅤ→ 비트와 템포
ㅤ→ 템포와 장르
ㅤ→ 백 비트
ㅤ→ 마디
ㅤ→ 록과 하우스
ㅤ→ “We Will Rock You”
ㅤ→ 비트를 연주해봅시다
- 노트와 스케일
ㅤ→ 피치에 대하여
ㅤ→ 피치를 사용해 패턴을 만들기
ㅤ→ 키와 스케일
ㅤ→ 마이너 스케일
ㅤ→ 노트를 더 추가하기
ㅤ→ 노트와 스케일을 연주해봅시다
- 코드
ㅤ→ 코드 구성하기
ㅤ→ 장3화음
ㅤ→ 단3화음
ㅤ→ "떴다 떴다 비행기"
ㅤ→ 1-5-6-4
ㅤ→ 코드를 연주해봅시다
- 베이스라인
ㅤ→ 베이스라인 만들기
ㅤ→ 베이스라인을 연주해봅시다
- 멜로디
ㅤ→ 멜로디 만들기
ㅤ→ “Love Will Tear Us Apart”
ㅤ→ “Ride”
ㅤ→ “Ride”의 변주
ㅤ→ 멜로디를 연주해봅시다
- 곡의 구조
ㅤ→ 곡을 구성해봅시다
ㅤ→ “Bury It”
- 자유 연주 공간
- 상급 주제
- 레슨을 마치며

 
Teenyicons - 15x15 초소형 무료 아이콘들 587개

- 15x15 사이즈로 디자인되었지만 SVG 여서 확대 가능
- 대부분의 웹 사이트/개발자 도구에 적합한 아이콘들
- Outline / Solid 두개의 타입
- MIT 라이센스로 어디나 사용가능

비슷하게 무료이고 SVG로 16x16 정도의 작은 사이즈를 제공하는 다른 사이트들

Forge Icons (300+개) : https://icons.theforgesmith.com/
System UIcons (220개): https://systemuicons.com/

 
git switch / restore

혼합되어 사용되던 checkout 의 기능을 브랜치 변경용 switch , 파일 복원용 restore로 분리한 것
1년 전에 출시된 git 2.23 버전 부터 실험적으로 추가된 기능으로 2.28 인 현재도 마찬가지 ( 차후에 변경 가능 )
git switch : 브랜치를 변경
ㅤ-c 브랜치 생성
git restore : 작업중인 파일을 복원

이 기능이 트위터에서 얘기가 되길래 공유해봅니다.
git --help 메인 도움말에서는 이미 checkout 명령은 안보이게 변경되었습니다. ( sparse-checkout 만 남아있습니다. )

 
Best of JS : 2006 ~ 2020

JS 뉴스레터인 JavaScript Weekly 가 500호 기념으로, 지난 15년간의 중요한 자바스크립트 프로젝트 20개를 선정.
각 프로젝트에 대한 간단한 소개와 배경 설명

#1 jQuery
#2 Node.js
#3 Express
#4 D3
#5 Angular 1
#6 Ember
#7 Bootstrap
#8 Webpack
#9 TypeScript
#10 Electron
#11 React
#12 Vue.js
#13 Babel
#14 VS Code
#15 React Native
#16 Next.js
#17 Puppeteer
#18 Deno
#19 Snowpack
#20 Rome

그외 프로젝트들 : Three.js, Meteor, Jest, Redux, Gatsby, Storybook

앞의 것들은 뭐 오래전이니 그렇다 치고, Puppeteer 이후의 것들은 긱뉴스에서 소개하려고 노력했던거 같네요.
국내 개발자분들이 긱뉴스 헤드라인들만 챙겨봐도 이런 프로젝트들은 놓치지 않게 하고 싶습니다.

Deno - Rust로 개발된 Javascript/Typescript 런타임 https://news.hada.io/topic?id=1348
Deno, JavaScript와 TypeScript를 위한 Secure Runtime https://news.hada.io/topic?id=2339

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

Rome - 실험적인 자바스크립트 툴체인 https://news.hada.io/topic?id=1609
Rome - JavaScript / TypeScript Linter 베타 릴리즈 https://news.hada.io/topic?id=2621

 
지하철에서 바이러스 입자에 일어나는 일

NYT가 잘하는 영역중 하나인 인터랙티브 기사 (Snowfall*)
- 지하철 열차내부에서의 환기 시스템 과 필터에 대한 상세 설명
- 바이러스의 이동을 마스크 쓴 사람과 안 쓴 사람이 재채기 할때의 비교를 통해서 설명

* Snowfall 은 인터랙티브 기사의 시초라고 할 수 있는 기획보도

Snowfall : http://nytimes.com/projects/2012/…

 
P2 - 워드프레스가 만든 팀 협업 도구

- 2005년부터 리모트로 일해왔던 Automattic이 내부에서 사용하던 도구를 공개한 것
- 팀 협업을 위한 문서편집/프로젝트/대화를 하나로 묶은 도구
ㅤ→ 실시간 문서 동시 편집 및 메시징, 멘션 기능
ㅤ→ Private / Public 설정 및 사용자 접근 관리
- 무료. 3GB 저장 공간
- 워드프레스/블로거/Medium/Wix/Ghost/Tumblr 등에서 임포트 가능
- 커스텀 도메인 및 셀프호스팅 지원예정 ( Wordpress와 마찬가지 )

 
Kowl - 오픈소스 Kafka Web UI

- Apache Kafka 클러스터의 메시지를 확인하고 내부를 살펴보기 위한 UI도구 (예전 Kafka Owl)
- 메시지 뷰어 : JS로 필터링 가능. JSON/XML/Text 보기, Avro는 지원예정
- 컨슈머 그룹 보기 , 토픽/클러스터 오버뷰
- Business 버전에서는 구글/GitHub OAuth 및 RBAC 지원

Kafka 는 비슷한 도구가 많은데 계속 나오고 있네요.

CMAK - https://github.com/yahoo/CMAK
akhq - https://github.com/tchiotludo/akhq
kafdrop - https://github.com/obsidiandynamics/kafdrop (AVRO 및 PROTOBUF 지원)
kafkactl - https://github.com/deviceinsight/kafkactl (커맨드라인 도구)
Kafka Tool - https://www.kafkatool.com/ ( 데스크탑 클라이언트, 개인은 무료, 유료버전 별도)
Conduktor - https://www.conduktor.io/ ( 데스크탑 클라이언트, 유료 )

 
OneLook - 와일드카드로 사전 검색하기

- 1061개 사전의 1895만단어를 인덱싱
blue* → blue로 시작하는 모든 단어
*bird → bird로 끝나는 모든 단어
bl????rd → bl로 시작해서 rd 로 끝나는데, 중간에 4글자가 있는 단어들
bl*:snow → bl로 시작하는데 단어의 뜻이 snow와 관련된 단어들
*:snow → snow와 관련된 단어들
*:winter sport → winter sports 라는 컨셉에 맞는 단어들
**winter** → winter 단어가 중간에 들어간 모든 문구들
expand:nasa → n.a.s.a 라는 약어를 사용하는 모든 문구들

이거 보고 한글은 안되나 해서 네이버 사전에서 해보니 와일드카드쪽은 비슷하게 동작하네요

*레비* : https://dict.naver.com/search.nhn/…=

*바라* : https://dict.naver.com/search.nhn/…=

다음 사전은 안되는데 네이버 사전은 뭔가 기능을 많이 넣은듯 합니다.

 
YCombinator Startup Library 2.0

YC가 지난 15년간 만든 스타트업 창업자를 위한 비디오/팟캐스트/글등을 모은 라이브러리
분야별로 정리된 약 300개의 자료들
- Growth, 비즈니스 모델, 회사 카테고리별 / 스테이지별 가이드, 창업자 멘탈관리, 펀드레이징, CEO/CTO를 위한 가이드, 인력 관리, 스타트업 아이디어, 제품 설계 및 테스트 방법, MVP 와 Product Market Fit 등
이중 19개는 YC가 무료로 운영하는 스타트업 스쿨의 주요 커리큘럼 자료로 사용

 
SurveyJS - 무료 설문조사 라이브러리

- Angular2+,jQuery,React,Vue,knockout 과 사용 가능
- 다양한 질문 형식 제공
- 멀티 페이지 설문 가능
- 동적 설문조사 로직 변경(논리식,함수,필터 등 이용)
- 한국어 포함 20개 이상 언어 지원 (커뮤니티가 제공한 번역)
- 커스텀 테마 및 Bootstrap 지원
- MIT 라이센스
- Survey Creator / PDF Export / Analytics Pack 은 유료

 
Notion, 한국어 지원 시작

- 한국어를 시작으로 다양한 언어 지원할 예정
- 도움말 페이지에서 100개 이상의 한국어 가이드 제공
- 노션 한국 커뮤니티가 만든 한국어 템플릿들 제공
ㅤ→ 나만의 도서관 만들기 : 위키형식 템플릿 11종
ㅤ→ 계획을 세우는 모든이를 위해 : 플래너 형태의 템플릿 8종
ㅤ→ 선생님도 학생도 활용 가능한 : 학교에서 쓰기 좋은 템플릿 7종
- 로그인 후 설정과 멤버 -> 언어와 지역 에서 주 사용언어 변경 가능

한국어 템플릿 갤러리 : https://www.notion.so/1639712845e5473083442d3ff3be023c
노션 한국 커뮤니티 : https://notion.so/Notion-Community-in-Korea-61220f5077824ae681644cdd01…

https://www.notion.so 메인페이지도 다 로컬라이제이션 되어있는데 한국어 페이지로 가는 직접 링크가 없네요.
메인 페이지 맨 아래 좌측에 언어 선택 콤보로 한국어를 선택하면 setlocale API를 통해서 언어를 변경하는 방식입니다.
영어외에 지원되는 첫번째 언어가 한국어라니, 한국 사용자가 많기는 한가 봅니다.

오전에 이메일로 한국어 지원 시작 공지를 메일로 받았는데, CEO 이름으로 보낸 해당 메일의 마지막 문구가 인상적입니다.

"이 이메일을 읽고 계신다면 아마 이전에 Notion을 사용해 보신 적이 있을 겁니다. Notion 팀을 대표하여 여러분의 지지에 대한 큰 감사의 말씀을 전하고 싶습니다.

개인적으로 말씀드리자면, 영어는 저의 모국어가 아닙니다. 그래서 외국어로 된 소프트웨어를 사용하는 것이 얼마나 답답한 일인지 잘 알고 있습니다. 이번 한국어 버전 출시를 통해 Notion이 나만의 맞춤형 도구가 되기를 바랍니다. 여러분도 Notion으로 문제를 해결하고 일상과 업무를 정리해 생산성을 향상시켜 보세요."

 
Jupyter Book 발표

계산식 콘텐츠가 포함된 출판물 수준의 책/웹사이트/문서를 구축하기 위한 오픈소스 프로젝트
- 출판 수준의 마크다운 확장 지원
ㅤ→ MyST 마크다운 : Directive & Roles(함수 for 마크다운), 인용 및 상호참조, 수학 및 방정식, Figures
- 쥬피터 노트북으로 콘텐츠 작성 또는 마크다운으로 작성 가능
- 실행후 결과 콘텐츠를 책에 삽입 가능. 캐슁도 가능
- 인터랙티브 기능 : 쥬피터 세션 실행, Binder/Google Colab 등과 연결
- 콘텐츠+결과를 묶어서 HTML 또는 PDF로 책 만들기 가능
- Sphinx 문서화 엔진 사용 (기존 Jekyll 대신)

 
애플 앱스토어와 구글 플레이에서 Epic Fortnite 삭제

- Fortnite 가 앱스토어 수수료를 회피하기 위해 자체 결제 시스템을 도입하자 앱스토어에서 삭제
ㅤ→ 내부화폐인 V-Bucks 구입시 자체 결제를 이용하면 앱스토어 대비 20% 할인된 금액에 제공
- 애플이 앱을 삭제하자, Epic 은 이에 대응하여 애플의 유명했던 1984 광고를 패러디한 광고를 유튜브와 포트나이트에 업로드
ㅤ→ #FreeFortnite 로 팬들에게 동참을 유도
- 안드로이드에서는 이미 자체결제를 하고 있었지만, 애플이 삭제하자 오늘 구글플레이도 같이 포트나이트 앱 삭제
- Epic 은 캘리포니아 법원에 애플이 독점적 지위를 가지고 있다며, "공정한 경쟁을 허용해달라"고 고소

구글 플레이 삭제 관련 기사가 같이 떳네요.
Fortnite for Android has also been kicked off the Google Play Store
https://theverge.com/2020/8/…

Epic 이 Fortnite 의 사용자 기반 (약 7800만명) 을 가지고 한판 붙어보려는거 같은데 과연 성공할지..

한편 reddit에는 애플이 안드로이드 버전 애플 뮤직 앱에서 30% 수수료를 피하기 위해 결제정보를 요구하는 것을 꼬집는 글이 올라왔습니다.
https://reddit.com/r/apple/…

구글쪽도 고소했는데 고소장 내용에 구글이 하드웨어 벤더인 OnePlus 와 LG쪽에 런처가 앱을 사이드로딩 하지 못하게 막았다고..

이건 좀 크네요. 별도 앱스토어도 돌리는 마당에 특정 앱 설치 자체를 막았다면..

https://theverge.com/2020/8/…

 
웹 개발자가 iOS/iPadOS 14에서 고려해야할 점

현재 Safari 14 베타4 기준이며 계속 업데이트중
- 주요 변경점들 : WebAuth, PiP, WebP & HDR, HTTP/3 등
- App Gallery : WebClips(바로가기 및 PWA들) 들은 앱갤러리에 표시 안됨
- PWAs : 13과 차이없음
- News+ 웹링크 : 애플뉴스+ 지원 웹링크가 사파리대신 News+앱에서 열림
- App Clips : 사파리 앱 배너가 앱클립용으로 사용 가능
- Geolocation : 지도권한 요청시 precise on/off 가능
- 웹뷰 with ITP(Intelligent Tracking Prevention) : 웹뷰는 기본적으로 ITP 활성화. 설정에서 끌수 있지만, API로 끄는 방법은 없음
- Service Workers : 웹뷰에서 지원. App Bounds Domains 가 info.plist 에 추가되고 웹뷰에서 해당 도메인만 브라우징 가능.
- App Bound domains per app : 10개로 제한

 
Rome - JavaScript / TypeScript Linter 베타 릴리즈

컴파일러,린터,포매터,번들러,테스팅 프레임워크를 별도 의존성없이 다 TypeScript로 통합 개발하려는 프로젝트인 Rome의 첫 베타
현재 JS/TS Linter 만 개발했고, 나머지도 지속적으로 개발 예정.
Babel/Yarn 개발자가 새로 시작한 프로젝트인 Rome 은 Babel의 정신적인 계승자
Babel, ESLint, Webpack, Prettier, Jest 등을 대체할 통합 도구로 개발하는 것이 목표

 
애플, 구독 번들 Apple One 런칭 예정

차기 아이폰 발표와 함께 애플의 기존 구독서비스를 묶어서 더 저렴한 요금제를 선보일 듯
여러 레벨의 패키지가 될 것
-1. Basic : 애플 뮤직, 애플 TV+
-2. #1 + 애플 아케이드
-3. #2 + 애플 뉴스+
-4. #3 + iCloud 저장공간

또한 최상위 번들에는 펠로톤/나이키가 하는 가상 피트니스 클래스와 비슷한 구독모델도 포함될 예정
가족 대상 번들이 될 것이며 6명까지 같이 쓸 수 있을 것으로 예상

 
Twitter API v2 공개

기본 트위터 기능 외에 새로운 엔드포인트들 추가 및 개선
- 강화된 분석 기능
ㅤ→ 필터링 가능한 실시간 트윗 스트림 구독
ㅤ→ 특정 토픽/키워드에 대해 관련된 대화 검색 (위치 기반 구분 가능 / 사람들의 의견 분석)
ㅤ→ 트윗의 퍼포먼스 분석
ㅤ→ 이벤트 구독 : 해쉬태그/키워드, 리트윗 포함여부, 미디어 포함여부, 언어별
ㅤ→ 트위터의 ML모델에 의해 트윗에 Annotation이 달리고 이를 검색가능
- 3개의 접근 레벨로 분리 : basic(무료), elevated, custom
ㅤ→ Elevated 는 다시 연구목적/비즈니스/스탠다드로 구분
- V2 Elevated API셋이 완성되면 모든 기존 v1.1 엔드포인트는 중단 예정
- 현재 Early Access 신청 가능

트위터가 외부에 공개하는 Twitter Developer Platform Roadmap [트렐로]
https://trello.com/b/myf7rKwV/twitter-developer-platform-roadmap

 
아마존 Machine Learning University 일반에 공개

- 2016년에 만들어서 직원 전용으로 사용하던 MLU 학습과정을 Youtube를 통해서 일반에게도 공개
- 현재는 NLP, Computer Vision, Tabular Data 3개의 과정이 공개
- 연말까지 9개 과정을 추가로 공개하고, 내년초 부터는 모든 과정이 동영상/코딩 자료와 함께 공개될 예정

MLU 유튜브 채널 : https://www.youtube.com/channel/UC12LqyqTQYbXatYS9AA7Nuw/playlists

 
Unified Gatsby

- React + GraphQL 기반의 정적 웹 페이지 프레임워크 Gatsby가 기존 .org 와 .com 사이트를 통합해서 하나의 사이트를 오픈하고 모든 리소스를 한 곳에 모으기로
- 오픈소스 버전의 Gatsby는 계속 발전시킬 것
ㅤ→ Gatsby Recipes : 워드프레스처럼 5분안에 설치 가능하도록
ㅤ→ Gatsby Admin : 새로운 UI의 관리도구로 플러그인/테마/메타데이터등을 관리
ㅤ→ Gatsby Desktop : CLI 대신 사용가능한 네이티브 관리도구 앱
ㅤ→ 파일 시스템 기반 라우팅
ㅤ→ 그외 : 새 Route 관리 UI, 더 쉬운 GraphQL 툴킷 등
- Gatsby Cloud (무료+유료) 의 새 기능들
ㅤ→ GitLab & Bitbucket 지원
ㅤ→ Incremental Build GA
ㅤ→ PR코멘트에 라이트하우스 점수 및 Deploy Preview 링크 제공
ㅤ→ Gatsby Hosting : 더 쉽고 더 빠른 자체 호스팅
ㅤ→ 개인용 Free 버전부터 Individual / Team / Enterprise 요금제로 세분

 
PayPay, 아마존 Aurora 에서 TiDB로 이관

- PayPay는 일본 최대 모바일 결제사업자 (사용자 3천만명)
- 쓰기가 많은 Payment DB에 병목이 생겨서 Aurora 에서 오픈소스 HTAP( Hybrid Transactional/Analytical Processing) DB인 TiDB로 이관한 이유들을 정리
- TiDB: 오픈소스, 클라우드 네이티브, 분산 SQL DB
ㅤ→ MySQL과 호환
ㅤ→ Horizonal 스케일링 가능. 추가적으로 TiDB 클러스터는 여러개 인스턴스로 되어있어서 HA 가능
ㅤ→ 개발자 단에서 샤딩 처리할게 없어서 어플리케이션이 간단해 짐

- Aurora 는 Write Primary 와 Read-Only Secondary 가 기본으로 둘간의 복제 레이턴시는 매우 작긴 하지만, Write 요청이 많아지면 binlog 복제가 병목이 되기 시작.
- 내부에서 테스트 했을때 TiDB가 Aurora 보다 3배의 트랜잭션을 처리 할수 있었음

 
오라클, Autonomous JSON DB 공개

- SQL/JSON 이나 간단한 NoSQL API(SODA*)로 사용할수 있는 비용효율적인 JSON 데이터베이스
ㅤ* DBA가 필요 없는 Autonomous DB(자율 운영) 기반으로 동작되어 관리부담이 거의 없음
- 내부적으로 트리기반 바이너리 형태로 JSON을 저장. 빠른 읽기와 부분 업데이트 가능하며 ACID 보장
- 기존 NoSQL DB대비 좋은 점들
ㅤ→ 머신러닝 알고리즘 내장, 공간 쿼리
ㅤ→ 상세 접근 권한 제어같은 향상된 보안 기능
ㅤ→ 서버사이드 프로시져럴 언어 지원
ㅤ→ Low-Code 개발 환경
ㅤ→ ACID 트랜잭션(시간/크기 제한 없음)
ㅤ→ 간단하고 빠른 교차 컬렉션 조인
ㅤ→ 전제 JSON에 대한 똘똘한 검색 인덱싱
- MongoDB Atlas 대비 30%정도 저렴

* SODA ( Simple Oracle Document Access ) - Java,Python,JS,C 등에서 간단히 사용할수 있는 NoSQL 스타일 API

* Autonomous ( 자율 운영 ) DB 는 몇년전 부터 오라클이 계속 내세우는 관리 자동화된 DB 솔루션 입니다.
기존에 DBA 들이 하던 많은 영역들을 AI와 머신러닝 기술을 이용하여 프로비저닝, 보안, 업데이트, 백업 및 튜닝, 변경관리등의 기능을 자동화 해주는 것을 의미합니다. 기존의 클라우드 DB도 스케일링이 쉬워졌을뿐, DBA가 관리해줘야 할 부분이 있었는데 이걸 최대한 자동화 시켜서 개발자가 비즈니스 로직만 신경쓰도록 만드는 것이라고 보면 됩니다.

그럼 이제 DBA 없어도 되는거야? 라고 생각할 수도 있는데, DB도 점점 데이터의 종류 및 사용처가 계속 복잡해지고 있어서, 오라클은 DBA 는 DB만을 관리하는게 아닌, 기업의 전체 데이터를 아우르는 Data Dachitect 가 되어야 한다고 주장합니다. 아래 기사를 참고하세요.

"자율운영 데이터베이스, DBA 대체 아니다" https://zdnet.co.kr/view/?no=20180814122734