[GN#51] 요즘 개발자들은 앱스토어가 제공하는 것들을 원하지 않는다

2020-06-22 ~ 2020-06-28 사이의 주요 뉴스들
아이폰이 등장하고 앱스토어가 나오면서 다양한 앱들이 만들어졌습니다. 애플이 자신들의 광고에서 사용하고 트레이드마크로 등록까지 해버린 "There's an App for that" 이란 문구가 말해 주듯이 우리가 생각하는 거의 모든 곳에 사용할 수 있는 앱들이 만들어져왔고 또 계속 발전을 거듭하고 있는데요. 그 앱스토어의 이면에는 항상 이슈가 되는 수수료 문제도 존재합니다. 30%라는 수수료 비율이 적절하냐 아니냐 얘기하는 것보다는 왜 이런 상황이 만들어졌고 앞으로는 어떻게 변해갈지를 얘기해보는 것이 필요할 것 같은데요. SaaS를 비롯한 이커머스와 앱스토어 모델의 수수료 비교를 통해서 관련 상황을 알아보고, 미래를 얘기하는 "요즘 개발자들은 앱스토어가 제공하는 것들을 원하지 않는다" 글을 이번주 긱뉴스 위클리의 메인 기사로 선정했습니다.

오픈소스 개발자는 어떻게 돈을 벌 수 있을까요? 큰 프로젝트는 오픈소스 재단이나 기업들의 후원을 받는 방법이 있겠지만, 1인 개발자의 오픈소스는 기업이나 사용자들의 기부를 제외하고는 알려진 방법이 많지 않았는데요. 오픈소스 LiveWire의 개발자가 자신이 GitHub Sponsors로 1.2억원을 벌은 방법을 상세히 적은 것이 화제가 되었습니다. Sponsored Screencasts라는 방식으로 자신의 오픈소스를 잘 사용하는 방법을 설명한 스크린캐스트를 후원자들에게만 공개하는 방식을 적용했는데요. 이를 위해서 본인이 GitHub Auth를 적용한 별도 앱을 만들었다는 게 재미납니다.

이번 주는 애플의 개발자 행사인 WWDC 20이 처음으로 온라인으로 개최되었습니다. 관련해서 많은 기사가 쏟아져 나왔는데요. 가장 큰 관심은 바로 Apple Silicon이라 이름 붙여진 애플 자체 칩으로의 전환이었습니다. 아이폰에서 오랫동안 갈고 닦은 ARM CPU 기술을 macOS에 적용한다고 발표하면서 큰 우려와 기대를 받고 있는데요. "Apple Silicon: Macintosh 역사상 네 번째의 아키텍처 대전환은 어떤 의미인가?" 글에서 전체 정리를 보시면 좋을 것 같고요. 개발자들이 우려하는 것 중 하나인 가상화 부분을 상세히 분석한 "ARM Mac 에서의 가상화를 우려하는 이유" 글도 참고해 주세요. iOS14 와 iPadOS14 의 변화는 사실 요즘 모바일 플랫폼들이 그러하듯 큰 변화보다는 사용성을 개선하는 것들에 초점을 맞추는지라, 다들 기대하던 "혁신은 없었던 것" 같습니다. 특히나 위젯 기능의 확장은 안드로이드 사용자분들께서는 우린 이미 다 되던건데? 하는 말씀을 올해도 또 하시더군요. 둘이 서로 배우며 발전해 나가는 듯 합니다. 저는 개인적으로 App Clips가 또 다른 생태계가 될 수 있을 거라고 기대하고 있습니다. 앱 하나가 여러 개의 App Clips를 호스팅하는 기능은 다양한 곳에서 쓰일 수 있을 것 같아요.

Node.js 의 개발자 Ryan Dahl 이 새 프로젝트 Deno 에 대해 설명한 슬라이드와 동영상은 짧지만 잘 정리되어 있어서 한번 보시길 권해드립니다. 시간이 안 되시면 내용을 요약해 두었으니 그 부분만 보셔도 좋습니다.

올해 초에 기술 전망을 말씀드리면서 한 꼭지로 소개해 드린 게 Low-Code / No-Code 였는데요. Amazon이 엑셀 같은 UI로 코딩 없이 웹&모바일 앱을 만드는 Honeycode 를 공개했습니다. 비즈니스 도구들을 누구나 쉽게 만들어서 업무 프로세스를 개선하는 제품들이 계속 나오고 있으니 관심 가지고 지켜볼 만 합니다.

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

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


요즘 개발자들은 앱스토어가 제공하는 것들을 원하지 않는다

30%수수료가 앱스토어 모델을 죽인게 아니라 SaaS가 그렇게 만든 것

* 이커머스 와 앱스토어의 수수료 비교

$10 짜리 작은 물건을 현금 받고 팔기 [수수료 = 0%]
- Shopify : 플랫폼수수료 2% + 결제수수료 2.9%+30¢ = $9.21 [8%] (스토어 유지비용 월 $29 별도)
- Ebay : 플랫폼수수료 10% + 페이팔수수료 = $8.41 [16%]
- Amazon : 추천수수료 15% + Fulfillment 수수료 2% + 아이템당 수수료 $0.99 = $5.69 [43%]

물건이 잘팔려서 그에 대한 $9.9 짜리 책을 써서 Kindle 과 Apple Books 에서 팔기
- Kindle : 책가격은 무조건 $2.99~$9.99 사이여야 하며, 인쇄본대비 20% 저렴해야 함. 다운로드 용량당 $0.15/mb 내야함 = $6.69 [30%]
ㅤ→ 위 조건에 안맞을 경우엔 수수료 [65%] 10$ 책팔아도 $3.5 들어옴

만약 사람들이 제품을 넘 좋아한다고 해도, 상품에 대한 노래를 만드는건 좋은 생각이 아님
- Spotify는 노래 한곡 재생당 0.32¢, Apple Music 은 0.56¢ 를 줌
ㅤ→ 즉 당신의 $10달러 물건이 한개 팔리는 것과 같은 금액을 벌려면 누군가 당신의 노래를 3,125번 재생해줘야 함

당신 제품의 디지털 버전을 만들어서 팔면
- Appstore 와 Google Play 는 수수료 [30%]. $10 앱은 = $7 수익

게임도 별로 다르지 않음
- Valve [30%] - 천만개 이상 팔리면 5% 할인
- Sony, MS, Nintendo 역시 [30%]

년 $10 구독모델로 간다면
- Apple/Google 은 첫해에는 $7 [30%], 다음해 부터는 $8.5 [15%]

웹에서 판다면
- Stripe 는 결제당 2.9% + 30¢ = $9.41
- Stripe 에서 구독모델을 한다면 구독 수수료 1% 추가 = $9.31

* 아이폰 이전에는.. ( Before software ate the world )

앱스토어도 처음엔 통신사들이 피쳐폰에서 자바앱 팔면서 50%~70% 이상의 매출을 가져가던걸 바꾼 것.
소프트웨어를 찾고, 다운로드 받고, 결제하고, 해적판을 막기위해 라이센스키를 발급하고, 업데이트를 배포하는 것들이 쉽지 않았고, 앱스토어는 이 모든걸 해결해 주면서 30%의 수수료를 받은 것. 통신사가 떼어가던거에 비하면 할인같은 느낌 이었음.
앱을 업로드 하면 결제 정보 입력할 필요도 없이, 누구가 구매할수 있었고 업데이트도 쉬워짐. 애플이 그냥 폰에 밀어넣어주니까.

그러다가 균열이 보이기 시작. 앱을 다운로드 하는 사람들은 실제 고객이 아님. 누가 구입했는지도 알지 못하고 직접 연락할 방법이 거의 없음. 앱스토어에서 Upgrade 를 판매하는 방법은 없었기에 앱을 최신상태로 유지하기 위해 돈을 버는게 힘들어짐. 그리고 노래,이북,비디오 등 위의 라이센스키나 업데이트 등 App Store 인프라가 필요치 않은 콘텐츠를 판매하더라도 애플에 30%의 수수료를 내야함.

그래서 웹이 복잡하긴 하지만, 더 매력적으로 보이기 시작하게 됨.
앱스토어는 소프트웨어 배포를 단순화 하는 합리적인 비용에서, 소프트웨어 가격 인플레이션에 직접 영향을 미치는 부담이 되기 시작.

이제 웹의 기능이 푸시를 비롯해서 거의 모든 기능을 수용하도록 확장되었고, Stripe 를 비롯하여 결제 방식이 많이 쉬워짐에 따라 대안이 나오기 시작.
애플이 Reader Apps 라고 부르는 계정기반으로 멀티플랫폼에서 콘텐츠를 볼수 있는 앱들이 만들어지거나, 실물 상품들을 파는 수많은 앱들 까지.

App Store 매출이 줄어들고, 웹 기반 SaaS 들이 점점 영향력을 넓히게 되면
10여년전 애플이 통신사들과 했던 일들이 앱스토어와 Web & SaaS 들간에 일어나게 될 것

네. 이제 10년이 지났으니 변화가 필요한 시점인 것은 맞는 것 같습니다.
수수료 정책은 조금씩 개선되지만, 요구사항보다 너무 느린 것도 맞죠.

글이 약간? 모호하게 단어들을 사용해서 읽느라 고생을 했는데 앱스토어의 30% 수수료에 대한 공격은 점점 날카로워 질거라고 생각합니다.
소프트웨어 구매시 결제와 업데이트가 어려웠던 10여년 전에 비해서 요즘은 상황이 그나마 좋아지긴 했어요.
다만 모바일 플랫폼을 장악한 애플/구글이 과연 수수료 정책을 어떻게 유지하는가도 관전 포인트가 되겠네요.

 
Computer Science 독학하기

- 전산 분야별로 가장 좋은 책 과 온라인 강의 한개 씩만 딱 추천
- 프로그래밍, 컴퓨터 아키텍쳐, 알고리즘과 자료구조, 전산수학, OS, 네트워킹, DB, 언어와 컴파일러, 분산시스템
- 다 보는게 어렵다면 이 2권은 꼭보는걸 추천
"Computer Systems: A Programmer's Perspective" (컴퓨터시스템:3판 - 퍼스트북)
"Designing Data-Intensive Applications" (데이터 중심 어플리케이션 설계 - 위키북스)

CS Unplugged - 컴퓨터없이 배우는 Computer Science https://news.hada.io/topic?id=1954
OSSU 오픈소스 소사이어티 대학교 - Computer Science 독학하기 https://news.hada.io/topic?id=595

 
GitHub Sponsors 로 1.2억원을 벌은 방법

- Lalavel 기반 풀스택 프레임워크인 LiveWire 개발자의 오픈소스 전업 후기
- 2019년 12월 깃헙 스폰서 등록 후 7개월만에 $100K를 넘었음(전 직장 연봉 $90K)

1단계: 처음 시작은 Good-Hearted Folks 들의 기부 → $6K
2단계: Sponsorware 를 시작 → $17K
ㅤ→ 좋은 소프트웨어를 만듬
ㅤ→ 특정 숫자가 될 때까지는 스폰서 한사람들 한테만 공개
ㅤ→ 어느 정도 숫자가 넘으면 오픈 소스로 공개
3단계 : Sponsored Screencasts → 3달만에 $40K 에서 $100K로
ㅤ→ LiveWire를 설명 하는 무료 스크린캐스트를 먼저 몇개 공개
ㅤ→ 스폰서 전용 스크린캐스트를 추가 ( 스폰서 금액은 개인당 월 $14 )
ㅤㅤ* 이걸 가능하게 하기 위해 GitHub 인증이 붙은 별도 Laravel 앱을 만듬 ( 스폰서인지 확인하기 위해 )

중요했던 것들
#1 좋은 소프트웨어를 만들 것
#2 Audience 만들기
#3 알맞은 스폰서 금액 정하기 : 너무 낮은 월 $1~5 보다 $9로 시작했고, 스크린캐스트는 $14로 설정
#4 좋은 스폰서십 티어 이름 정하기 : "Platinum" 보다는 "The Agency" 같이 회사가 스폰서링 할 때 명확한 이름을
#5 돈을 많이 번다는 것에 죄책감 느끼지 말기

https://www.patreon.com/ 을 쓰면 아마도 비슷하게 스폰서 전용으로 스크린캐스트나 자료를 공개할 수는 있는데, 여긴 수수료가 5%~8% 라서 개발자라면 깃헙 스폰서가 훨씬 좋은 선택이긴 하겠네요.

큰 오픈소스가 아니어도 돈을 벌수 있는 방법을 본인이 찾았네요.
스폰서드 스크린캐스트는 정말 좋은 방식인듯

 
Show GN: type-hangul - ⌨️ 한글 타이핑 효과 라이브러리

한글 두벌식 자판에서 한 글자씩 타이핑되는 과정을 보여줄 수 있는 라이브러리입니다.

GitHub Pages 페이지 만들 때, GeekNews에서 접한 MVP.css 활용했습니다. https://news.hada.io/topic?id=1773

 
A/B Street - 도시 교통 시뮬레이션

- 도시에 약간 변화를 주는 것이 어떻게 운전자,자전거,대중 교통 사용자 및 보행자의 움직임에 영향을 주는지 보여주는 게임
- 윈/맥/리눅스 에서 실행가능한 Rust 오픈소스
- 도로의 타입 변경, 신호등 변경, 교차로 진행 방향 변경 후의 교통 상황 변경을 보는게 가능
- 시간 조정, 특정 차량 따라가기 등으로 도시의 문제를 확인 가능
- 시애틀 지도(OpenStreetMap)를 사용하며 자동차/자전거/보행자/버스를 시뮬레이트
- OSM 지도를 임포트 해서 새로운 도시에 적용해 보는 것도 가능(아직 쉽지는 않다고)

 
2020 상반기 기술 아티클 모음

- 카카오의 프로젝트 100에서 나온 산출물
- 2020년 상반기 업계 트렌드와 이슈
- 각종 이슈에 대한 트러블 슈팅들
- 여러 언어들의 중, 상급 팁들

 
Muzli Search - 디자이너용 검색엔진

- 디자인 영감을 얻을 수 있는 결과를 보여주는 검색엔진
- 색상, 키워드, 스타일로 조합 검색 가능
ㅤ→ Landing Page, Dashboard, Icon, Logo, Pricing Page, Illustration, Mobile app 등
ㅤ→ Blue 또는 #RGB코드로 색상 검색
- 페이지 내에선 마우스 아이콘이 Color Picker로 바뀌어서 바로 해당 색상 디자인 검색 가능
ㅤ→ #1b7182 landing

 
NGINXConfig - nginx 설정파일 편하게 만들기

- 웹페이지에서 NGINX 설정을 편하게 수정하고 config 파일로 다운로드
- 웹사이트 별 / 글로벌 설정 변경
- Preset 제공 : PHP, Django, Node.jS, SPA, WordPress, Magento 등
- 더블컬럼 모드에서 설정 변경시 설정파일 변경사항을 즉시 확인 가능

 
FlexBuffers - FlatBuffers 의 Schema-less 지원 포맷

- 구글의 고성능 직렬화 라이브러리 FlatBuffers는 Schema 기반으로 동작하는데,
ㅤFlexBuffers 는 스키마 없는 데이터를 저장하고자 할 때 쓸수 있게 만든 전용 포맷
- (당연히) 타입체킹은 할 수 없지만, 파싱/복사/객체 할당 없이 효율적으로 액세스 가능
- 컴팩트한 인코딩을 구현하여 대부분의 경우 일반 FlatBuffers 보다 더 작은 바이너리를 생성
ㅤ→ 아직 속도는 FlatBuffers 보다 느림

- FlatBuffers 는 구글에서 게임이나 성능이 중요한 어플리케이션을 위해 개발된 크로스 플랫폼 직렬화 라이브러리. 대부분의 언어 지원

Data Serialization Library 들 분류
- Schema-ful, copying: Protobuf[1], Thrift[2], Parquet[3](Thrift 기반) 외 다수
- Schema-ful, zero-copy: Cap'n'proto [4], Flatbuffers[5], Apache Arrow[6](Flatbuffers 기반)
- Schema-less, copying: Json (바이너리 및 기타 변형들 포함 ), XML
- Schema-less, zero-copy: Flexbuffers ⇦ NEW!

[1] https://developers.google.com/protocol-buffers
[2] http://thrift.apache.org/
[3] https://parquet.apache.org/
[4] https://capnproto.org/
[5] https://google.github.io/flatbuffers/
[6] https://arrow.apache.org/

 
WWDC2020 간단 총정리

iOS14 에서 추가된 내용

- Widgets 기능 추가
- App Clips 기능 추가
- App Library 기능 추가
- 새로워진 Memoji 기능 추가
- Callbar 기능 추가
- PIP 기능 추가
- 실시간 번역 앱 추가
- 더욱더 새로워진 Siri UI
- 지도 & 애플 카플레이 업데이트 (스마트키)
- 자전거 경로 제공
- EV Routing 기능 추가

 
Apple, iOS 14 발표 [공식 한글 보도자료]

- 앱 보관함 : 홈 화면 페이지의 끝에서 간단하고 쉽게 탐색할 수 있는 보기 방식을 통해 모든 앱에 쉽게 접근
- App Clips : 앱의 일부를 필요로 하는 순간에 이용. 빠르고 쉽게 탐색
- 메시지 : 대화 고정, 멘션, 메시지별 답변
- 지도 : 자전거 길찾기, 전기차 경로, 주변 장소 안내 가이드 기능
- 사용자 동의 투명성 개선 및 개인정보 보호 향상
- 번역앱 제공
- Siri 개선
- 홈앱 확장 : 적응형 조명, 온디바이스 얼굴인식
- AirPods : 자동 기기 전환, 공간감 오디오 제공 ( 다이내믹 머리위치 추적 )
- 디지털 Car Keys : 자신의 차량을 열고 시동 걸기
- 건강 : 수면 관리
- 오늘부터 개발자 프리뷰 다운로드 가능. 일반 베타는 다음달 부터
- iPhone 6S 및 후속기종부터 사용 가능

 
Apple, iPadOS 14 발표

- 진행중인 작업을 방해하지 않게 간결한 디자인으로 변경 : FaceTime,전화받기,Siri,검색
- 검색을 통합 : 앱 찾기/실행, 연락처, 파일, 빠른 정보, 인물과 장소에 대한 질문의 답변까지 어디서나 검색 가능
- 사이드바 : 사진,파일,메모,캘린더,애플 뮤직 등의 앱등의 탐색 기능을 사이드바로 통합
- Apple Pencil 에 Scribble 기능 도입
ㅤ→ 손글씨→텍스트 자동 변환. 메모시에도 온디바이스 머신러닝으로 손글씨와 그림 구별
ㅤ→ 도형인식 가능 : 손으로 그린 도형을 기하학적으로 완벽한 도형으로 변환하고 이를 개체로 다른곳에도 삽입가능
- ARKit 에 새로운 Depth API 제공
- iOS14와 마찬가지로 Widget,메시지 개선, Siri,지도,Home 등 개선

 
Apple, Mac 아키텍처의 Intel에서 ARM으로 전환 발표

- Mac에 사용되는 CPU를 Intel 칩에서 ARM 기반 자체 설계 칩으로 2년안에 전환을 완료할 계획
- 노트북과 데스크탑 모두 전환 대상
- 자체 설계 칩에는 CPU, GPU, SSD 컨트롤러, 머신 러닝 앱에서 사용되는 뉴럴 엔진 등이 포함
- macOS Big Sur의 기본 앱들이 새로운 Apple 칩을 지원하도록 업데이트됨
- Adobe, Microsoft를 포함한 주요 파트너와 협력해 앱 호환성 확보 노력
- Apple 칩과 호환되지 않는 앱을 에뮬레이션하기 위한 Rosetta 2 발표

Rosetta 2 라니.. 이름 재사용 참 잘해요.
* Rosetta 는 PowerPC 에서 인텔 넘어갈 때 쓰던 프로젝트입니다. 아직 페이지도 살아있음 https://www.apple.com/kr/rosetta/

개발자들이 테스트해볼 수 있는 Developer Transition Kit 는 맥미니 형태로 생겼네요
https://theverge.com/2020/6/…
- 아이패드 프로 2020 버전에 들어있는 것과 같은 칩
- Universal App Quick Start Program 참여 비용은 $500
- 키트는 오늘부터 바로 신청할 수 있고, 끝나면 반환해야한다고

 
“Apple Silicon”: Macintosh 역사상 네 번째의 아키텍처 대전환은 어떤 의미인가

애플의 ARM칩 전환에 대한 총 정리
- 주류 플랫폼 공룡들의 탈-x86 움직임은 이미 수 년 전부터 분명했다. 단지 제대로 성공한 기업이 없었을 뿐
- “Performance per Watt”: 왜 굳이 전환하려 하는가
- Universal 2와 Rosetta 2: 한 몸, 두 머리
- 가상화와 Windows 사용
- iOS 앱 실행과 Apple Silicon에서의 신규 보안 정책
- 결론: 강력한 컴파일러, 강력한 칩, 빼앗기는 자유

 
ARM Mac 에서의 가상화를 우려하는 이유

- Docker는 5배 느려질 것
ㅤ→ 맥용 도커는 Hypervisor 기반이라 호스트에서 게스트와 동일한 아키텍처여야 함
ㅤ→ ARM Mac 에서는 ARM Linux를 돌려야 하고 그게 아닐경우 에뮬레이터로 실행되니 5x-10x 까지 속도가 느려질 것
ㅤ→ 모든 도커이미지들이 ARM을 지원하게 만드는 것은 아주 오래 걸릴 것
ㅤ→ 또한 이미지가 다른 패키지를 내려받는다면 그 역시 대부분 x86 기반일 것이라 실행자체도 어려울수도

- VirtualBox 는 동작하지 않을 것
ㅤ→ 버추얼박스 역시 Hypervisor 이고, x86 윈도우 또는 x86 리눅스는 실행불가
ㅤ→ ARM 용 윈도우즈는 실행가능하겠지만, VirtualBox 는 x86전용이고, 포팅할 생각도 없음 (VirtualBox 포럼 모더레이터의 답변)
ㅤ→ VMWare Fusion 역시 하이퍼바이저 이지만, ARM 포팅을 고려하고 있음
ㅤ→ 대신 에뮬레이터인 QEMU 를 고려할수는 있겠지만 좋은 대안은 아님

- BootCamp 역시 동작하지 않을 것
ㅤ→ ARM Mac 에서 지원하지 않을 것(크레이그 페더리기가 팟캐스트에서 말한 바 있음)
ㅤ→ 게다가 MS가 ARM Windows를 OEM으로만 판매하기 때문에 지원한다고 해도 MS가 그걸 승인해야만 가능

- ARM Mac 을 사야할까 ?
ㅤ→ 프론트엔드, 모바일, 네이티브 앱 개발자 라면 괜찮을 수 있음
ㅤ→ 가상화를 많이 써야하는 개발자라면 추천하지 않음
ㅤ→ 초기에 물론 많은 문제가 있겠지만, 해결책이 없을 수도 있음

당분간은 인텔 맥+ARM 맥 두개로 가겠지만, 언젠가는 ARM 맥으로 다 전환 될것이고,
그러면 실제로 모든 플랫폼 개발자용 필수장비처럼 인식되던 맥이 그 지위를 어느정도는 잃어버릴 수도 있겠다는 생각이 드네요.

MS가 ARM Mac 출시에 맞춰서 서피스 기기들을 대폭 할인 판매하길 기대해 봐도..

음.. 도커는 생각해볼만한 이슈네요
컨테이너들 이슈도 있을텐데 애플이 얼마나 적극적이냐에 따라 다를 것 같네요

지원하지 않아서 곤란한 시장도 있지만, 그렇기 때문에 더 바빠질 시장도 있겠군요. 어찌보면 새로운 생태계가 열리는 셈이니...

 
App Store, 인앱결제 항목에 대한 환불 알림 지원

- Consumables, Non-consumables, Non-Renewing Subscriptions 등 모든 인앱결제 항목의 환불에 대해서 알림 지원
- 구독 상태 변경을 위해 사용하던 Server-To-Server Notifications 기능을 통해서
ㅤ고객이 환불하면 거의 실시간으로 알림 전송

드디어 이 기능이 지원 되는군요.
인앱결제 항목을 사용자가 환불 받는 것들을 회사의 손실로 처리하고 있는 곳들이 많았을텐데 다행입니다

 
iOS14, 기본 이메일 & 웹 브라우저 앱 변경 가능할 예정

- 발표중에 "Set default email and browser apps" 항목을 통해 유추
- 반독점 피소에 대한 대응일 것으로 예상

소송 때문에 하긴 하지만 눈가리고 아웅 같은 느낌..
- 정작 앱스토어에 WebKit 엔진외의 것(Gecko / Blink 등)을 사용한 브라우저 등록이 금지 되어있는데 과연 허용할 지
- 지도, 음악, 팟캐스트, 달력 같은 앱들은 ?

음? 그런가요? firefox 앱도 있던데 그건 Gecko가 아니었군요.. 오호..;;

네 WKWebView 기반입니다. 앱스토어가 기본으로 별도 브라우저 엔진은 등록 못하게 되어있어서
Firefox, Chrome 다 비슷하게 껍데기만 씌워서 확장 기능만 제공중이에요

https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_for_iOS

 
iOS14, 앱이 클립보드를 억세스 할때 알리는 기능 도입

- 앱이 클립보드에서 내용을 읽을때마다 배너로 알림 메시지 표시
- 베타로 테스트 결과 엄청 많은 수의 앱들이 클립보드를 감시하고 있는 것으로 나타남
- TikTok 의 경우 1-3개의 키 입력할때마다 계속 클립보드를 읽음

이슈가 되었던 TikTok 테스트 영상 https://twitter.com/jeremyburge/status/1275896482433040386

민감한 정보 복사할 때가 종종 있는데.. 조심해야겠내요.

 
iOS14 : IDFA 시대가 저물어 갑니다

- iOS14 부터 모든앱은 IDFA를 사용하기 전에 사용자의 동의를 얻어야 합니다.
ㅤ→ 사용자가 거절하면 해당 앱은 IDFA 접근 불가능 하고 "광고 추적 차단" 이 켜있는 것과 같은 값을 받게됨
ㅤ→ 이제 IDFA를 대체할 방법을 찾아야 함
- isAdvertisingTrackingEnabled 기능 지원 중단
ㅤ→ AppTrackingTransparency 프레임워크를 이용해야 함

* IDFA : Identifier for Advertisers , 광고식별자

 
Skeuomorphisim 이 돌아오고 있다

지난 몇년간 Flat Design 에 밀려났던 스큐어모피즘이 돌아오고 있다
WWDC 20에서 애플이 보여준 새 아이콘과 디자인들이 그 한 예

사람들은 대부분 쉽게 지루해하기 때문에 트렌드는 원처럼 반복됨
플랫디자인은 더 쉬웠고, 적은 노력으로도 결과물을 만들어낼수 있었음
애플에게도 플랫 디자인은 리셋이었고 그를 통해서 일관된 시스템을 만들어냈음

하지만 이런 모던 플랫 UI들은 깔끔하고 일관성있게, 생산성과 속도를 위해 최적화 되었지만 뭔가 하나 부족했음
바로 "Soul" 을 잃어버리고 다들 비슷하게 보이고, 심지어 아이콘이 화면에 섞여버리기 시작했음
그래서 다시 스큐어모피즘을 통해서 천천히 "볼만한게 많은" 디자인으로 변경 되어 갈 것

키노트에서 맥OS의 아이콘 설명부분에서 이 글에서 주장하는 것을 엿보실 수 있습니다.
https://youtu.be/GEZhD3J89ZE?t=4270

사실 플랫디자인이 좀 심심하긴 한데 예전처럼 마구 화려하기만한 스큐어모피즘으로 간다기 보다는
플랫 디자인을 통해서 좀 더 정제되면서도 세련된 디자인들이 나오지 않을까 예상은 됩니다.

저는 "볼만한게 많은" 디자인쪽에 한표

 
Amazon Honeycode - 코드작성 없이 웹 & 모바일 앱 만들기

- 스프레드 쉬트 형태로 작성하면 코딩없이 앱을 생성하게 만들어주는 No-Code 도구
- 드래그 앤 드롭으로 비즈니스용 앱을 작성 가능
- 엑셀과 비슷한 다양한 함수들 지원 (FindRow = VLookup)
- 다양한 템플릿 : ToDo, 고객 트래커, 설문조사, 재고 관리, 콘텐츠 트래커, 이벤트 관리, 팀 태스크 관리 등
- 빌더는 Chrome 에 최적화. 생성되는 웹 앱은 대부분의 브라우저 에서 실행됨
- 모바일앱은 iOS11+ / Android 8.0+ 전용 Amazon Honeycode앱을 다운 받아 그 안에서 실행 가능

Retool https://retool.com/ 의 경쟁 제품이 되겠네요.
어찌 보면 AirTable https://airtable.com/ 하고도 겹치구요.

No Code is New Programming https://news.hada.io/topic?id=1099
위 글에서 제가 6개월전에 올해의 대세중 하나는 No-Code 가 될거 라고 말씀드리면서
구글/아마존/MS 등에서도 나올거 같다고 댓글 단 적이 있는데 역시나 아마존에서 제품을 출시 했네요 ;)

Low-Code / No-Code 개발 플랫폼들 리뷰 https://news.hada.io/topic?id=1799

 
Node 개발자를 위한 Rust 가이드

- JavaScript / TypeScript 에 익숙한 개발자를 위해 유닉스 wc 명령어를 Rust로 만들어가면서 설명하는 가이드
- 특정 함수/개념들을 비슷한 문법들을 들어 비교하면서 설명
생성 : cargo new miniwc --bin
→ cargo ≒ npm
ㅤ→ cargo.toml ≒ package.json
ㅤ→ cargo.lock ≒ package-lock.json
→ cargo run start ≒ npm run start
→ struct ≒ Object
→ std::env::args() ≒ process.argv
→ std::fs::read_to_string ≒ fs.readFile
→ split_whitespace() ≒ split()

 
OneSignal의 Rust 4년 실전 사용기

- 2016년부터 프로덕션에서 Rust 이용중
ㅤ→ 메인 푸시 딜리버리 서비스부터, 분석데이터 처리를 위한 Kafka Consumer 들까지
- 2016년 초당 12.5만개, 주당 20억개 푸시 → 2020년 현재 초당 1.75백만개, 일 70억개로 24x 커지는데 Rust가 큰 도움

Pros and Cons
- Rust 는 여전히 안전에 대한 오버헤드 없이 강력하고 성능이 뛰어난 시스템을 만들수 있게함
- 2015년에 비해서 많이 성숙했지만 아직도 언어가 변화중
- Rust-Analyzer가 매우 발전해서 자동완성, 리치 툴팁, 정의로 이동, 오류/경고/린팅 표시 및 리팩토링 지원까지 추가됨
- 컴파일속도 개선을 위해 인크리멘탈 컴파일이 추가되었으나, 아직 Go가 컴파일속도는 빠름. 하지만 Rust가 매 릴리즈마다 빨라지는 중
- HTTP 에 대한 문제는 Future 와 async/await 덕분에 많이 사라짐
ㅤ→ 2016년 부터 많은 향상이 있었지만 그중 가장 유용한 변화는 바로 비동기 프로그래밍의 도입
- Rust가 엄청 새로운 것들이 많이 추가되어 왔지만 아직도 많은 재미난 변화가 있을것으로 예상
ㅤ→ Generic Associated Types (#1598)
ㅤ→ Custom Test Frameworks (#2318)

 
Deno, JavaScript와 TypeScript를 위한 Secure Runtime

- Ryan Dahl 이 Deno의 현재에 대해서 OpenJS World 2020 에서 발표한 슬라이드 & 동영상 [12장, 27분]

- C++, Rust, Go가 컴파일 언어들을 향상시키고 있지만,
ㅤ근래의 많은 소프트웨어 작업들은 Python, Ruby, JavaScript 같은 동적 언어들에 의해서 진행되어 왔음.

- Node.js 가 JavaScript 를 서버에서 가능하게 했음
ㅤ→ 2010년대의 PHP
ㅤ→ 여러 클라우드 벤더들이 지원
ㅤ→ 모든 프론트엔드 프레임워크들(React, Vue, Angular)이 Node를 이용해서 번들링

- JS Ecosystem의 큰 변화
ㅤ→ ArrayBuffer, async / await , ES Modules, WASM, TypeScript

- Deno
ㅤ→ Node 처럼, JavaScript를 브라우저 밖에서 실행 가능하게 함
ㅤ→ Node 처럼, 크롬의 V8 JavaScript VM을 이용
ㅤ→ Node 처럼, 오픈소스이고 MIT 라이센스
ㅤ→ C++ 대신 Rust로 작성됨
ㅤ→ Testing, Linting, Formatting, 문서 생성등 도구를 내장
ㅤ→ 다른 소프트웨어에 임베드 가능 : deno_core , rusty_v8
ㅤ→ 웹 표준 API를 이용해서 가장 많은 수의 개발자들이 이용할수 있도록 타겟하여 설계됨

- Deno 는 커맨드 라인 스크립트를 위한 브라우저
ㅤ→ 인터넷에서 코드를 직접 임포트 하고 실행할수 있게 하여 프로그래밍을 쉽게 만들어 줌
ㅤㅤㅤimport { serve } from "https://deno.land/std@0.56.0/http/server.ts";;
ㅤ→ Deno는 사용자 동의하에서만 OS에 접근할수 있는 안전한 샌드박스

- Deno 임베드 하기 : deno_core
ㅤ→ 스탠드얼론 실행파일로 릴리즈 되었지만, Rust Crate 로 임베드도 가능
ㅤ→ 가능한 유스케이스
ㅤㅤ- DB가 Map Reduce 함수를 위해 JavaScript 를 사용
ㅤㅤ- Lambda@Edge 나 Cloudflare Workers 등의 서버리스 제품군
ㅤㅤ- Electron 스타일의 GUI 어플리케이션 등

- Roadmap
ㅤ→ 버그 픽스, 버그 픽스, 버그 픽스
ㅤ→ Deno API 안정화
ㅤ→ 미래 작업들
ㅤㅤ→ deno_core 를 좀더 유용하게 만들기
ㅤㅤ→ GPU API 를 지원해서 머신러닝 지원
ㅤㅤ→ deno compile 을 통해서 JS를 binary executable 로 만들기

Deno 1.0 릴리즈 - https://news.hada.io/topic?id=2075
Deno의 오픈소스 개발과정 비주얼라이제이션 - https://news.hada.io/topic?id=361
From Node to Deno - https://news.hada.io/topic?id=2103

 
마켓플레이스 비즈니스 모델을 평가하는 방법

비즈니스를 평가할 때 봐야할 7가지
1. Product-Market-Fit : 사람들이 정말 이걸 원하나 ?
2. Why Now : 왜 지금? 뭐가 바뀌었나
3. Market : 충분히 많은 사람들이 이걸 필요로 하나 ?
4. Distribution : 그 사람들을 사용자로 끌어들일수 있나 ?
5. Team : 우리 팀이 이걸 만들기에 적합한가 ?
6. Moat : 우리가 1등을 하고 그걸 지킬수 있을까 ?
7. Business Model : 이 비즈니스가 빠르게 성장하는 효율적인 것일까 ?

마켓플레이스 비즈니스를 평가할 때 추가로 봐야할 7가지
1. Demand Product-Market-Fit : 소비자들이 정말 이걸 원하나 ?
2. Supply Product-Market-Fit : 판매자들이 정말 이걸 원하나 ?
3. Scalability with Quality : 훌륭한 품질을 유지한 채로 성장 가능한가 ?
4. High frequency and average order value : 재구매율, 평균 주문금액, 잠재 매출은 ?
5. Reasons to stay on-platform : 판매자들이 우리 플랫폼에 남아 있어야만 할 이유는 ?
6. Non-monogamous : 고객들이 꼭 다시와야 할 이유는 ?
7. Fragmentation : 정말로 소비자/판매자 양쪽이 서로를 만나기 어려운가 ? (우리가 없다면)

 
Quora 도 Remote First 로 전환

- 트위터, Shopify에 이어 영구적 재택근무(WFH) 회사로 전환
- 실제로 코로나 기간동안 원격근무를 진행해보니 더 생산적이었음
1. 출퇴근 스트레스가 없고
2. 사무실보다 집에서 더 집중도가 높고, 많은 일을 하는게 가능
3. Bay지역의 주택값이 너무 상승해서, 집이 멀어지고 통근시간이 더 길어짐
4. 미국의 비자 및 이민 상황 등으로, 원격에서 더 좋은 인재들을 고용하기 쉬움
5. 원격작업이 사무실근무보다 모든면에서 나은건 아니지만 점점 개선되어 갈 것

- 사내 조사 결과 COVID-19 이후에도 60% 의 직원이 사무실 근무를 선택하지 않음

- Remote First 가 의미하는 것
1. 모든 직원은 (몇몇 예외를 제외하고는) 어디서든 근무 가능
2. 마운틴뷰 사무실은 유지하지만, 코워킹 플레이스로 변경
3. 대표도 사무실 근무를 안할 것이고, 한달에 한번 이내로 출근할 예정. 경영진들도 모두 리모트
4. 모든 미팅은 화상으로

- 다른 All-Remote 회사들과는 다르게 업무시간은 동기화 할 예정 ( PST 9AM ~ 3PM )

단순히 우리 Remote 할꺼에요! 하고 자랑하는 글이 아니라
이외에도 가정소득, 파트너(Significant Other)와의 근무 위치 문제, 노동의 도시 집중현상 등 다양한 부분에 대해서 깊이 있는 고민을 한 글이네요.

혹시나 All-Remote 하겠다는 회사들은 공지글 쓸때 참고해서 읽어볼만 합니다 ;)

한국만 해도 강남, 판교에 집중된 IT 회사들은 이런 업무동기화 시간만 맞춰준다면 리모트로 지방에서 일하는게 가능해지지 않을까요. 집값때문에 서울에서 월세나 전세로 올라오는 것보다 더 나은 상황을 마련할 수 있을 것 같다는 생각이 듭니다.

 
Perl 버전 7 발표

Perl이 버전 7에 관해 발표했습니다. (영어) Perl 7은 내년(2021년)에 나올 것입니다.

Perl은 래리 월(Larry Wall)이 1987년에 처음 발표한 동적 타입의 고수준 인터프리터 언어입니다. 이식성이나 하위호환성이 좋으며, 문자열 처리능력이 뛰어나서 각종 스크립트를 만들거나 언어학·생물정보학 등에서 사용하기도 하지요. 2000년대 초반까지는 웹 프로그래밍에도 많이 사용되었습니다. 그 시절에는 CGI(Common Gateway Interface)라는 용어가 마치 Apache HTTP 서버와 Perl 언어의 조합을 가리키는 것처럼 잘못 사용되기도 했던 기억이 나네요. 대부분의 리눅스 시스템 및 macOS에는 Perl이 기본적으로 설치되어 있으므로 곧바로 사용할 수 있습니다. 지금 확인해보니 제 맥북의 macOS 10.15에는 Perl v5.18.4가, 라즈베리 파이 4에서 돌아가는 Ubuntu 20.04에는 Perl v5.30.0이 설치되어 있군요.

Perl 6는 하위 호환성을 포기하고 역사적 이유로 쌓여 있던 불합리한 점을 모두 털어내는 것을 목표로 Perl 5.6이 발표되던 2000년부터 설계되기 시작했었지만, 아주 오랫동안 출시가 늦어진 끝에 결국 2019년에 Raku라는 별개의 언어로 아예 분리되었습니다. 그런 연유로, Perl은 6이라는 버전을 건너뛰고 바로 버전 7로 넘어갑니다. 또한 Perl 7은 기본적으로 현재의 최신 안정 버전인 5.32와 크게 다르지 않되, 더 현대적이고 안전한 기본 설정값을 사용할 것이라고 합니다. 만약 이 설정 때문에 호환성 문제가 발생한다면 Perl 5의 설정값을 대신 사용하는 호환성 모드를 사용할 수 있다는군요. 이는 기존에 잘 사용하던 Perl 스크립트나 CPAN(Comprehensive Perl Archive Network)에 올라와 있는 방대한 기존 코드를 최소한의 수정만으로 Perl 7에서도 계속 사용할 수 있을 것이라는 점을 의미합니다.

정리감사합니다. 제가 아는것과 조금 다른 부분이 있어서 코맨트 합니다.

1. perl6의 설계목표는 perl5에 불합리성을 털어내는것이 아니었습니다 perl6는 perl5의 기본 정신위에 좀 더 현대적인 프로그래밍 페러다임과 런타임구조를 언어 코어에 기본적으로 반영하는 형태를 지향했기때문에 perl6가 perl5를 대체할 목표를 가진것이 아닙니다. 따라서 python 3와 python 2의 관계보다는 C와 C++의 관계로 봐야합니다.

2. perl6는 출시가 늦어졌기때문에 raku로 이름변경한것이 아닙니다. perl6년 2015년 크리스마스에 정식출시되었으며 여러VM과 런타임이 존재합니다. 2019년에 이름을 변경한것은 위에 말한것 같이 perl5와 perl6 간의 독립적인 관계를 좀 더 부각하기 위한 선택이었습니다.

감사합니다.

 
Apple, Hey의 iOS앱 업데이트 승인

- 애플이 리젝했던 1.0.2 버전의 업데이트를 승인
- Hey 는 1.0.3 업데이트에서 iOS 전용 게스트 사용자 기능을 추가
ㅤ→ 임시로 랜덤 이메일 계정을 만들어서 14일간 사용해 볼수 있음
- 회사가 비용을 지불하는 HEY for Work 개발에 속도를 낼 것 ( 이미 수천개 회사들이 Waitlist에 등록 )

* 필 쉴러 한테는 평생 무료 계정 발급해 줄테니 연락하라는 유머스런 메시지가 마지막에..

 
Amazon, 자율주행 회사 Zoox 인수

- 가격은 비공개지만 약 1.2조($1B) 예상
- Zoox는 처음부터 자율주행만이 아니라 완전히 통합된 차량을 개발하려고 계획한 야심찬 회사
ㅤ→ 자율주행 기술 개발후, 차를 만들고, 로보택시 서비스 까지 계획
ㅤ→ 자동차 개발에는 수조원 이상이 들어가므로, 아마존은 계속 더 투자를 해야할 것
ㅤ→ 아마존이 Zoox의 기술로 정확히 뭘 하고 싶은지는 불분명. 창고 로봇이나 배송차량등에 일부를 적용하거나 그냥 프로젝트 전체를 계속 진행시키거나 할 듯

- The Information이 처음으로 보도
ㅤ→ Zoox 는 약 천명의 직원이 있는 자율주행 스타트업
ㅤ→ 지난 6년간 "운전대가 없는" 자율주행 양방향 자동차를 만들어 왔음
ㅤ→ 이 차는 앞뒤도 없어서 양쪽으로 갈수 있음. 막히거나 장애물을 만나면 코스를 빠르게 변경 가능
ㅤ→ 아마존은 다른 자율주행차 개발회사인 Aurora Innovation 에도 투자했고, 또한 전기자동차 회사인 Rivian 에도 투자한 바 있음

아마존, Rivian 에 10만대의 배달용 전기트럭 주문 https://news.hada.io/topic?id=563

아마존이 자율주행 + 전기차에 다양하게 베팅하고 있는 듯.
애플도 분명히 하고 있긴 할텐데, 어떤식으로 진행될지 궁금하네요.

 
Relay - 이벤트 기반 인프라 자동화 도구

- Puppet 이 만든 "Zapier for DevOps"
1. Git, Cloud, Security, Ticket, Monitoring 등의 이벤트 를 받아서
2. 인스턴스 중단/재시작, Terraform Apply, JIRA 이슈 업데이트, 슬랙에 알림등으로 클라우드 인프라 관리를 자동화
- 모든 동작에 대해서 기록하여 Audit 가능
- Workflow 는 YAML 로 작성되어 쉽게 편집 및 관리 가능
- 다양한 도구들과 이벤트 및 기능 연동
ㅤ→ Bolt, GitHub, GCP, Docker Hub, Datadog, PagerDuty, Kubernetes, EC2, Azure VM, Terraform, VictorOps, Jira 등